Recap)に関する所感報告、及び関西支部の標榜する今後の展望について以下に述べる。Allianceとその日本支部であるCSAジャパンについて、事業内容や各WG活動に関する詳細説明が行われた。これらの具体的な内容は下記に付したURLから公開資料を参照願うものとし、本稿ではとりわけ、スライドの締めくくりで提言された「働き方改革とCSAジャパン」と題されたテーマを取り上げたい。500)企業に関して、半世紀前の1965年時点では「約75年」であった企業の平均寿命は、近年(2015年時点)ではわずか「15年」を切っているという(図1/参考:https://bizzine.jp/article/detail/2601)。我が国のビジネス環境においても終身雇用の崩壊が叫ばれて久しいが、「働ける年数」の側面からみて、「一つの会社」に閉じず、寄りかからず、オープンな「場」で第2、第3のキャリアを考えるべき時代に突入しているといえる。一つの側面に、デジタル・トランスフォーメーションの推進で浮き彫りとなる「働き方改革の本質」がある。デジタル・トランスフォーメーションの進行やAIの台頭によって今後仕事のあり方は二極化し、近視眼的に単純作業に埋没する人間は淘汰され、主体的に変化へ対応し大局的に新たな価値創造を主導できる人間が求められる。図2:CSAジャパンWG活動Webページ(出典:図1・2とも諸角昌宏氏「CSAジャパン関西支部立ち上げにあたり」より引用)筆者もこれらの要所は「いかに自己へ投資して時価総額を向上できるか」ということに尽きると認識している。これに対して、CSAジャパンはその解決策としての「場の提供」機能を有するものである。具体的には、個人会員や企業会員、あるいは連携会員としての立場で、図2に示す様な各種WGや勉強会・セミナー等の機会を積極利用して、同じ興味・関心をもつメンバーで幅広く自由にテーマを設定し、オープンな調査研究やディスカッションが可能である。(クラウドセキュリティに関するテーマが基本であるが、近年、クラウドにつながらないICT関連サービスは少なくなり、その安全利用上、セキュリティ確保は避けて通れない。Summit等のイベントでの海外ゲストとの交流機会なども活動参画いただく上でのベネフィットとなろう。した社外コミュニティにおける所属先(企業等)の異なる多様なメンバー間の交流を通じてこそ、例えば「自身の時価総額」や「キャリアの現在地」などが客観的に明確化されうるものと考える。Summit(本稿前編で既述)を取り上げ、本年度の全プログラム講演を対象にした概要紹介を逐一行った。関西地域在住のクラウドユーザーにとっては、たとえ関心をお持ちでも、これまで実際に東京会場(本稿前編で既述)まで足を運ばれることは稀であられたと推察され、それがために投影スライドに多数の会場写真(Summit各講演者の講演時の様子)を盛り込んで、少しでも会場の雰囲気がダイレクトに伝わる様努めた。Reavisによる基調講演テーマの変遷をスライド冒頭で示した。Summit開催テーマ等の変遷クラウドサービスはこれまで、実行環境上の技術進化や開発プロセスの変化の流れにおいても、アーキテクチャー上のインフラストラクチャーあるいはプラットフォーム的な意味合いで、第一義的な位置づけを保持してきたといえる。その一方でクラウドにおけるトラスト/セキュリティの流れを考えると、「ゼロトラスト」の概念モデルに行き着く。機密データの保管先としてクラウド移行が一層進み、IoT環境下、これに対して各ユーザーのもつ複数のデバイスからデータにアクセスされる状況では、従来の「ネットワーク型」のセキュリティから「アイデンティティ型」のセキュリティへの変更が余儀なくされるというものである(これに関しては、前述の「働き方改革の本質」にもつながるかもしれない)。クラウドのトラストで(クラウド上の機密データを守る上で)考えるべき「ゼロトラスト」の概念モデルについては、今後CSAジャパンのWG活動、勉強会、イベント機会などでも、さらなる議論と検討が深まるものと考えられる。Summitの大阪(関西)構想と、その「ねらいどころ」を参加者へ示した。Summitで蓄積された様式やノウハウを踏襲しつつも、それと同時にKANSAIのカラーとオリジナリティを適切に表現するものとしたい。現段階ではテーマ検討に向けたアプローチとして大きく5つ構想している。1クラウドユーザー企業の参画促進2SMEへの導入支援と情報発信3関西地域の魅力と多様性訴求4関西ユーザーの会員化と協賛ご依頼5大阪・関西万博(2025年)のフォローアップ、である。(筆者の私見で)とりわけ念頭にあるものとして、関西(近畿)地域が内包する大阪・神戸・京都をはじめとした、各エリアの「多様性」や「際立った特色・個性」といった部分を、多彩な講演プログラム構成に結び付けたい。(開催テーマ:いのち輝く未来社会へのデザイン)が社会にもたらす影響力は巨大であり、例えば「長寿・健康」等のコンセプトをクラウドセキュリティ分野の検討課題に重ね合わせ、一体的に方向性を定めていきたい。※本公開版では肖像権を考慮し、上述のSummit講演者関係写真を適宜差し替えている。商務情報政策局の関根氏、それからCSAジャパン事務局及び関西支部運営スタッフ、さらには集客面でご協力いただいた連携・関連団体の関係各位に深く感謝の意を表したい。今後も関西支部は関西地域における定例勉強会やセミナーのコンスタントな開催、またWG活動への関西メンバーの積極的参画(東京会合開催の場合、適時リモート参加を促進していきたい)等を地道に継続し、関西ネットワーク基盤の裾野拡大に努めていきたいと考える。その一方で関西地域では、クラウドサービスやセキュリティ関連のビジネス市場、またそこで活躍できる人材等の(実働的な)リソースについて、首都圏に比較して大きな規模の開きが存在するのは否めない。グローバル動向を含む業界の最新トレンド、トピック、あるいはキーマンに、直接的に触れる機会や情報入手の即時性に差分が生じているのも事実である。そのためこれらを埋める対策として、本レポート投稿を皮切りに(CSAジャパン)Webページ上での情報発信に力を入れていきたい。セミナー等の開催告知・レポート、関西支部イベントの新着情報、また各種WG活動状況のアウトプット(成果物含む)などがある。その延長線上に、関西オリジナルコンテンツのアイデア創出につなげ、CSAジャパンの本年度取り組み目標の一つでもある「ブログの活性化」に寄与できればと願うところである。※本キックオフセミナー概要と講演プログラム1(基調講演:今後のデータ政策の展開とクラウドサービスの安全性評価について)について、本稿前編をご参照。Authorization)が、どのようにゼロトラスト環境で有効であるかについて説明します。インターネット上に安全なサービスを提供するため、認証が取れるまでは全てのアクセスを拒否する”Deny-ALL”が、どのように実現できているかについて説明します。インターネットのアクセスにおける課題とSPAリクエスト-レスポンス型であるインターネットのアクセス方法は、クライアントからのリクエストを受け取るために必ず口(ポート)を開けて待っています。これは、正しいユーザだけでなく、悪意のある人にも開いているということで、セキュリティ上の問題を引き超す可能性を高めています。悪意のある人は、ポートスキャン等を行って、インターネット上に開いているポートを探し、それに紐づくサービスを特定し、そのサービスの脆弱性を突いて攻撃を仕掛けることができます。開いているポートに対してSYNフラッド攻撃によりDoS/DDoS攻撃を行い、サーバを接続不能にすることができます。このようにインターネットがもともと抱えている課題に対して、アクセスが許可されるまでは全てのポートを閉じておくという、いわゆる”Deny-All”を実現することで対処することが求められています。このための方法として、大きく以下の2つがあります:ポートノッキングSPAこれらについて、以下で説明していきます。ポートノッキングポートノッキングは、決められたポートを決められた順番でアクセスすることでファイアーウォールに穴を空ける仕組みです。アクセスが許可されるというような設定ができる機能になります。SYNのシーケンスが来た時のみ、一定時間ポート22を開放します。クライアントは、この開放している時間内にポート22に対してアクセスすることで接続できます。これにより、通常はDeny-Allの状態を維持しつつ、決められたポート番号に決められた順番でパケットが送られてきた時のみアクセスを許可するということが実現できます。したがって、ポートノッキングには以下のようなメリットがあります。パケットはデフォルト・ドロップサーバに送られてくるパケットは、デフォルトでは全てドロップすることが可能になります。Deny-allを実現できます。これにより、サーバが提供しているサービスを非可視化することができ、サービス自体を悪意のあるアクセスから保護することができます。ポートスキャンしても空きポートを見つけることができない悪意のある攻撃者がポートスキャンを行っても、開いているポートや稼働しているサービスを見つけることができません。したがって、悪意のある攻撃が非常に困難になります。DoS/DDoS攻撃を最小化できるポートノッキング用のシーケンスにならないパケットは全てドロップされますので、SYNフラッド攻撃のようにもともと開いているポートに対する攻撃を行うことができなくなります。ポートノッキングには以下のようなセキュリティ上の問題があります。リプレイ攻撃に弱いポートノッキングに利用するパケットは、暗号化されずにそのままネットワーク上を流れます。したがって、ネットワークを盗聴し、クライアントからのパケット・シーケンスをそのまま送ることで接続できてしまいます。正しいクライアントに代わってポートノック用のシーケンスの一部を送ることで、シーケンスそのものを破壊することができます。IDSあるいはポートスキャンによるポートノック用のシーケンスの探索ポートノック用のシーケンスは一連のパケットの流れになるので探索が可能です。SPASPAは、ポートノッキングの利点を持ちながら、ポートノッキングの課題に対処したものになります。connect)」を実現するために、SPAを通してこれを実現していると述べています。IPの根本的にオープンな(そして安全でない)性質を補うものとしています。SPAにより、要求者のIPアドレスを含むリクエスト情報は、単一のネットワークメッセージの中で暗号化および認証が行われ、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができます。1.0の中に仕様として記述されていますが、従わなければならないというような厳格な仕様では無いようです。したがって、SPAは実装の仕方においていくつかの異なる方法が取られています。SPAを実装するにあたっては、以下の3つの共通の原則を備えることを要求しています。SPAパケットは、暗号化し、認証機能を持たなければならない。SPAパケットは、必要な情報をすべて1つのパケットの中に含めなければならない。SPAパケットを受け取ったサーバは、応答しないし、何も送信しない。ここでは、SPAの実装方法を説明するにあたって、fwknopが提供するオープンソフトウエアを参照します。knocking.”の内容を元にしてします。SPAパケットの構成fwknopが用いるSPAのパケットは、以下の構成になります。チェックサム16バイトのランダムデータを含み、パケット全体のMD5チェックサムを持つことで、1つ1つのSPAパケットが必ずユニークになることを保証します。これにより、サーバ側では、以前来たことのあるパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。クライアント・ユーザ名、クライアント・タイムスタンプクライアント・ユーザ名、クライアント・タイムスタンプは、もう一段のレベルの認証・認可をサーバ側で行うのに用いられます。バージョンfwknopとして、SPAのバージョン管理、特にバックワード互換性に用いられます。モードとアクセスサーバ側に、クライアントからの要求が、サービスへのアクセスなのかコマンドの実行なのかを示します。SPAでコネクションが許可された後、SSH(TCPポート22)のアクセスを許可するように設定できます。アクセスの場合には、アクセス・フィールドに直接ストリングを含めます。この例を元に、SPAの特徴をまとめると以下になります:Deny-Allの実現SPAパケットがクライアントからサーバに送られても、サーバがこれに応答することはありません。サーバは単にネットワーク上送られてくるパケットをスキャンする(たとえばlibpcapなど)だけで、SPAパケットでないものは全てドロップし、SPAパケットを受け取ると、その内容に基づいてクライアントとの接続を許可するかどうかを判断します。上記の例では、1パケットの中に16バイトのランダムデータを含み、全体のパケットのハッシュ値を入れています。これにより、SPAパケットがユニークになることを保証します。サーバ側では、今まで来たパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。DDoS攻撃への対処Deny-Allであること、また、SPAパケットは1パケットであり、シーケンスではないことにより、DDoS攻撃の可能性を非常に下げることができます。パケット・シーケンスの探索や破壊への対応SPAパケットは1パケットであることから、スプーフィングしたり解析したりすることが難しくなります。様々な認証情報の送信が可能SPAパケットの中には、様々な情報を含めることが可能なため、クライアントのユーザ名など、ユーザに対応した追加の認証等の処理が可能になります。以上のように、SPAは、ポートノッキングのメリットを維持しつつ、課題を解決し、ゼロトラスト環境における最適なネットワーク環境を提供できるものと考えています。ここでは触れませんが、SDPが他に提供している機能(mTLS等)とSPAが組み合わされることにより、ゼロトラスト環境におけるさらに強固なネットワークセキュリティが提供できます。SPAは、fwknopからオープンソースとして提供されていますので、さらに理解を深めていただければと思います。仁2019年8月21日はじめに法人化から5年が経過、CSAジャパンは2019年(令和元年)度の取り組み目標の一つにWG活動等の「多拠点化へのチャレンジ」を掲げ、その第一弾として「関西支部」活動が新年度(本年6月)より本格スタートした。関西支部は、CSAジャパンの事業内容やワーキンググループ(WG)活動等に関して、関西地域における紹介や認知度向上をその活動目的とする。関西地域のクラウドユーザーが有する潜在的交流ニーズの受け皿として、国内「面展開」の試金石となる。上記を受け、7月11日(木)午後より、広大な大阪城公園と壮大な天守閣を窓から眼下に一望できる(図1)、大阪ビジネスパークのクリスタルタワー20階E会議室を会場(図2)として、関西支部キックオフセミナーが開催された。仁(※本レポート筆者)本年は観測史上最も遅い梅雨入りとなり、あいにく当日午後の天候は小雨模様となった。官公庁関連団体などから幅広く、クラウドサービス導入やセキュリティ対策に関心をお持ちの参加者46名のご来場を得た。本稿前編では、上記講演プログラム1(基調講演:今後のデータ政策の展開とクラウドサービスの安全性評価について)に関する所感報告について以下に述べる。商務情報政策局の関根氏より、データ政策とクラウドサービスの安全性評価制度の検討状況に関してご講演いただいた。2019(本年5月15日開催/会場:東京大学伊藤謝恩ホール)の招待講演プログラムで、同省の松田洋平氏から事前に講演いただいた内容に通じ、これに近時のパブリックコメントの集約状況等をアップデートの上、関西地域のユーザーへも是非とも聴講機会を頂戴したいとの当会依頼に対し、ご快諾いただいたものである。Trust)の展開2クラウド・バイ・デフォルト原則とクラウドサービス安全性評価制度の検討状況、からなる。Trust)は、本年1月23日開催の世界経済フォーラム年次総会(ダボス会議)で日本の安倍総理により提唱された「信頼性のある自由なデータ流通」を促進するコンセプトである。国際的なデータ流通網を構築し、データの囲い込みを防止してその活用最大化を目指すものである。2019で大阪トラック立ち上げ宣言として盛り込まれたこともあり、参加者の関心は高かった様に思われる。ここでの主な論点は、DFFTによる国際的なデジタル経済の成長促進とプライバシーやセキュリティの確保とのバランスをいかに図っていくかにある。これへの対策として、個人情報や知的財産等の安全性確保に向けた個人情報保護法の3年毎の見直し、現行ペナルティのあり方、外国事業者に対する法執行の域外適用や越境移転のあり方、また各国の関係法制度との相互運用性の確保等が検討されていることが説明された。クラウド・バイ・デフォルト原則は、2018年6月に「政府情報システムにおけるクラウドサービスの利用に係る基本方針」として採用された「クラウドサービスの利用を第一候補として政府情報システムの検討を行う」とするものである。その一方で、適切なセキュリティ管理への懸念等から、(とりわけ)政府におけるクラウドサービス導入が円滑に進んでいない現状を鑑み、官民双方においてクラウドサービスの安全性評価の仕組みの必要性が掲げられている。「サイバーセキュリティ戦略」(2018年7月27日閣議決定)において、政府プライベートクラウドとしての「政府共通プラットフォーム」への移行の推進が掲げられた。これらを受け、経済産業省と総務省で「クラウドサービスの安全性評価に関する検討会・WG」が2018年8月から複数回開催されるとともに、本年3月16日から4月16日にかけて、中間とりまとめ(案)のパブリックコメントが実施されている。情報処理推進機構/IPA)も名を連ねている。本評価制度は、政府調達における利用を第一に想定しつつ、民間の特に情報セキュリティ対策が重要となることが想定される重要産業分野等においても、検討結果の活用推奨が目されている。ダイレクトに関西ユーザーに対して、取り組み最新状況についてお伝えいただく機会を設定できたことは幸いに思う。参加者からの活発な質疑に対し逐一懇切丁寧に応答いただき、セミナー後の懇親会(立食式)までお付き合いいただいた関根氏に、この場であらためて深く感謝の意を表したい。余談であるが、本セミナー開催から日を置かずに、某海外大手クラウドサービス事業者が上述の「政府共通プラットフォーム」に採用決定との報道が流れた。これに対し今後の世論において、様々な観点から議論が惹起されるであろうと予測される。Recap)、及び関西支部の今後の展望について、本稿後編に続く。Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。Trust)モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント(PDP)とポリシー実行ポイント(PEP)モデルになります。SDPの認証プロセスにおいては、「コントローラ(Controller)」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ(Gateway)」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。Authorization(SPA)です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。こちらを参照してください。■クラウドで活用するデータ、どこまで許可するか企業はCASBによってマルチクラウドの利用を一元的に可視化、制御ができることは間違いないのだが、CASB製品の評価において顕著に見られるのが、「企業として取り締まるべき情報(データ)の定義があいまい」なことだ。製造業や金融機関などにおいては、いわゆる業界ごとに定められたガイドラインや、他社に漏れては困る開発・設計データなどが明確に定められているが、そうでない場合、部署ごとにデータの機密性についての捉え方が異なっているために、企業全体としての「データ取り扱い」に関するルールが設定できないことが多い。そんな中、ややフライング気味にクラウドシフトしてしまった企業は、いざCASBで情報流出対策を打とうという時に、肝心のポリシーを策定することができないのだ。一方の欧米諸国の現状はどうなのだろうか。「訴訟大国」とも揶揄されるアメリカでは、各業種非常にコンプライアンスに厳しく、また会社では情報の取り扱いに対する教育を徹底する文化が根付いている。取引先の情報が自社から漏れることによるリスク、インパクトが明らかに日本に比べると段違いだ。それゆえに古くからDLP(情報流出対策)の導入が自然と進んでおり、「データの棚卸し」が自動化されている。(導入比率でいうと、欧米:日本=10:1ほどだ。)もちろん「どのようなデータがどこまで活用されることが許容されるか」といったデータガバナンスが根底にあるからこそだ。よって欧米欧州ではオンプレミスに徹底されているデータ取り扱いに関するポリシー(DLPポリシー)を、自分たちが採用したクラウドに対してはCASB経由でポリシー適用するだけでよい。日本企業の大部分は、そもそもオンプレミスにしっかりとしたDLPポリシーがないのにも関わらず、CASBによりクラウド上のデータを保護しようとしても、適切なポリシーも設定できなければ、またCASBで取り締まったところでオンプレミスの端末やメール添付、ファイル転送といったデータ流出経路はまったく可視化できないため、クラウドシフト半ばの日本企業においては、情報流出対策として十分な投資効果が出るとは思えない。仮に企業としてのクラウド活用指針(データの機微度に応じたリスク対処方法を含む)を定義できたとしよう。その際にどれだけの企業が機微度の高いデータをクラウドに預ける判断を取るだろうか。CASBベンダーの提供するデータ保護機能は様々だが、機微度の高いデータだからといってオンプレミスに大量にデータをかかえてしまうのであれば、結果としてオンプレミスとクラウド、運用とサーバ費用が二重投資となる。クラウドシフトに舵を切る以上は、限りなくデータをクラウドに安心して預けられる環境を構築したいところだ。そのためにはCASBの暗号化機能を活用することをお勧めする。特定のクラウドサービスの暗号化を用いた場合は、暗号鍵管理がほぼクラウド側になるだけでなく、複数のクラウドサービスを利用するのであれば、それぞれ個別で暗号化設定の管理が必要となり、またクラウドサービスごとにセキュリティレベルは異なるためガバナンスは効かせづらい。CASBであれば、ブローカーとしての役割を果たすことで、どのクラウドサービスにデータを転送する際も、CASB側で一意の暗号化や匿名化を施し、また鍵管理もデータを預けるクラウドサービス側とは別で一元管理、そして暗号鍵の担保が下記のように可能だ。ユーザ側は機微度に関係なくクラウドにデータを預けることが可能となる。データの機微度に応じた制御がCASBで自動実行される。利用時は本人認証などを通じて透過的に暗号鍵がロードされデータ閲覧・編集が可能となる。すべてのデータアクセスはCASB管理者側で把握でき、不正な鍵要求が見られれば該当のファイルに対して鍵を破棄し、復号できないことを担保することも可能となる。Shuredding)日本企業はどうしてもセキュリティを「止める、縛る」ことを前提に設計しがちだが、その思想ではクラウドの最大活用を阻害してしまう。データガバナンスを効かせつつ、透過的にリスクを排除していくためにCASBという技術は存在する。そのためには企業の中でデータ利用、クラウド利用の指針を今一度見直し、CASBの機能で担保できるリスクが何であるのかを理解した上でクラウドシフトを正しく進めていただきたい。上田光一CSAでは定期的に「クラウド利用者会議」という会合を開催している。これはクラウド利用者側の観点でクラウドに期待すること、あるいは課題などをディスカッションするもので、CSAジャパンの本ブログでも結果を議論の内容を紹介している。先ごろ行われた会議で、どのようにクラウドプロバイダを選択すればよいかわからない、といったコメントがあった。プロバイダの公開情報や試用する中で業務への適合性は確認できるとしても、セキュリティの観点での差分が見えないというものである。プロバイダ側コメントとして、不確定の伝聞情報で大変恐縮ながら以下のようなコメントがあったとのことであった。プロバイダ側としてはセキュリティに関する情報なので非公開である仮に公開したとしても普通のユーザでは適切な判断ができるか懸念がある確かに利用者にとっては、クラウドを利用するに際してどのようにプロバイダのセキュリティレベルを判断すれば良いのかは課題である。利用者が自力で判断しようとするとき、プロバイダが公開しているセキュリティ情報を元にこれを行うことになるが、ここで欧米と日本で大きな違いがある。欧米のプロバイダの対応は、セキュリティ情報を積極的に公開することで利用者が判断できるようにする傾向が強い。いわゆる「透明性」を高めるということである。これは、また、セキュリティをビジネス上の差別化要因にできるという利点がある。日本のプロバイダはあまりセキュリティ情報を公開しない。どちらかというと、「セキュリティ情報を公開することはリスクを高める」という考えを持っている。取得している認証の情報を公開しているが、認証ではセキュリティの成熟度を把握することは難しい。このあたりは国内事情としてはやむを得ない印象を受ける一方で、米国はじめグローバルの事情とはかなり異なっている。CSA本部のWebサイト、https://cloudsecurityalliance.org/では、以下のような情報を提供するページがある。https://cloudsecurityalliance.org/star/#_registryこれはCSAが提唱する認証制度STARを一つの基準としつつ、STAR認証取得の有無に関わらずクラウドプロバイダ側が自社のセキュリティ対応状況を公開するページとなっている。クラウドプロバイダとしては、自社サービスの透明性と公正さをアピールする場にもなっている訳である。一見して分かる通り米国プロバイダが圧倒的に多いのは当然としても、中国プロバイダも数多く登録されていることは興味深い。日本のプロバイダはごく僅かに留まっている。一例としてクラウドストレージのBoxをとってみると、以下で詳細情報が得られる。従って、プロバイダ自身が(このケースではBox社が)自己評価をした結果が得られる。興味のある方はぜひご一読頂きたいが、なかなかの情報量である(しかも英語)。なってくると、こうした情報が得られるとしても、それを利用者が正確に判断できるのか、いわゆる利用者のセキュリティ・リテラシが問題となる。ここでCASBである。CASBの4つの柱のうち1つ目の柱である「可視性」、ここには「どのクラウドサービスを使っているか」という意味合いとともに「それはどんなクラウドサービスであるか」という観点がある。対象とするクラウドサービスがどのような種別のサービスを提供するのか、そしてどのようなセキュリティ機能を提供しているか、こういった情報を、CASBは提供する。ここで重要なのが、CASBはセキュリティ状況をシンプルにリスクスコアとして判定して提供してくれることということである。あるCASBでは、クラウドサービスのリスクスコアを9段階で評価してくれるため、信頼を寄せられる程度が簡単に判断できる。それはどのような基準でスコアリングを行っているのだろうか。Matrix)である。これはCSAジャパンで日本語版としてもリリースしているもので、下記からダウンロード可能である。ここで公開している日本語CCMはControlの翻訳部分のみである。CCM全体のEXCEL版は、現在CSAジャパン会員のみが利用可能となっている。)最新版のv3.0.1では、16ドメイン、133項目からなっていて、例えば以下のような項目がある。メカニズム、受付デスク、安全パトロールなど)を実装しなければならない。説明:鍵には識別可能な所有者が存在し(つまり鍵とアイデンティティが紐付いていること)、また(組織には)鍵管理ポリシーがなくてはならない。説明:(長いので省略。CCMをご参照ください)CASBベンダはこういった情報を前述のCAIQやクラウドプロバイダのWebサイトによる公開情報などから入手する。公開情報がない場合は、個別にクラウドプロバイダに問い合わせることもする。クラウドプロバイダから回答が得られない場合は、その状況を踏まえCASBベンダが独自に判定することになる。スコアリング項目は必ずしもCCMと完全一致という訳でなく、CASBベンダ自身による重みづけや独自観点も加味する形で算出されている。重みづけについてはユーザによるカスタマイズ機能を提供しているCASBもある。各クラウドプロバイダのセキュリティ対応状況も刻々変化する一方、クラウドプロバイダもサービスの数自体も増加していくので、CASBベンダはこういった状況にも追随して対応している。特定のクラウドサービスが登録されていない場合は、リクエストにより追加登録対応してもらえる。CASBベンダはこのような取り組みを通して、クラウドプロバイダやサービスごとのセキュリティ対応状況データベースを日夜更新しており、今や登録サービス数30,000に迫るデータベースを保持するCASBベンダもある。従来国産クラウドサービスについては対応サービスが限られる状況があったが、対応数も順調に増加しているようである。組織によっては申請ベースでクラウド利用を個別に許可する運用を行っていることも多いと思うが、さらに個別に個々のクラウド利用審査のための調査が大変だ、という声を聞くこともある。クラウドを使いたいのに選択の判断情報がない、あるいは調査のための労力が無視できない。これをCASBのリスク判定で代替してしまう。これは一つの有効なCASB活用事例と言えそうである。それ以上にこういったリスク評価基準の策定フェーズにおいては、企業のクラウド活用における根本命題、すなわち「企業としてどのような観点でクラウドを活用していくか」という点に向き合うこととなる。これは企業のクラウド活用戦略を立てる良い機会となるだろう。CASBという存在の登場により、ユーザ企業、クラウドプロバイダの相互理解が進むこと、ひいてはユーザ企業におけるクラウド活用の進展、そして生産性向上とともに社会の発展つながる、こういった流れをCSAのCASB-WGとしても独自の立場から応援していきたいと考えている。慎太郎(個人会員)いわゆるシャドーIT対策機能を有するCASBを組織で導入すると、その組織内で利用されているクラウドサービスが一覧化されるとともに、利用状況が可視化されます。あまりにたくさんのサービスが可視化されてしまい、途方に暮れてしまうかもしれません。なすべきは、可視化された各クラウドサービスにラベルを付けることです。「対象外」があるのかというと、CASBがクラウドだと判定していても、そうとは考えられないサイトが存在するからです。判断が難しいかもしれません。これは、その組織のリスク許容度に依存するからです。ここでは、クラウドサービスを通じた従業員による情報の持ち出しを脅威シナリオとして想定し、方針決定の一例をご紹介します。方針決定の際に使える変数は、主に3種類に分かれます。それは、主体(誰が使うのか)・対象(どんな情報を取り扱うのか)・環境(サービス自身は信頼におけるか)です。理念的には、対象(どんな情報を取り扱うか)によって方針を定めるべきです。極秘の新製品情報と一般的な社外秘情報とを同列に扱うべきではありません。実運用上は、対象による方針決定はモニタリングを困難にします。通信の中身を追わなければならなくなるからです。そこで実践的には、主体に沿って方針を決定します。業務分掌が確立していれば、組織によって取り扱う情報が大まかに決まりますから、ある程度の近似になります。Directoryなどのディレクトリーサービスと情報連携する必要があります。L7まで見られる高機能ファイアウォールを使ってセキュリティゾーンを定義しているなら、その分類を活用するのが最善です。その際にはユーザーやセキュリティグループ単位で各ゾーンのアクセス制御を行っているでしょうから、それをクラウドサービスにも準用するのです。すれば、社内ネットワークと一貫性のある方針になります。可視化されたサービスのラベリングが完了したら、定常運用に入ります。日次でモニタリングして新たに観測されたサービスをラベリングし、届け出のないサービス利用を発見したら正規手続きを促します。最後に1点、注意すべき点があります。それは、CASBがクラウドサービスだと認識していないSaaS/ASPが、我が国にはたくさんあることです。届出制を採用している場合には、届けられたサービスがCASBに載っているかどうかをチェックし、載っていない場合には照会する手続きが発生します。CASBによってはアップロードのバイト数からSaaS/ASP候補を出力する機能がありますので、その機能を使って能動的に発見することもできるかもしれません。その業務と関係するものではありません。第10回クラウド利用者会議では、「RPAと法律的な問題点」というテーマで高橋氏にご説明いただいた。会議は、7月30日(月)に開催し、クラウド利用者を中心として10名に参加いただいた。ロボットにおける用語とRPAとの関係について触れられた。マニプレーターと記憶装置が必要であることその上で、RPAはどうなるかというと、自律的な操作が表現されたエキスパートシステムであるということができる。RPA自体がバズワード化しており、実際に何を差すのかは明確にしずらい状況である。ディープラーニング、自然言語処理などにより、自立した結果を出力し経営意思決定に結び付ける能力これらを踏まえてRPAを含むロボットの問題として、以下の3つの領域で考える必要がある:安全/セキュリティ安全基準/保安基準がどうなるのか?プログラムでコントロールされるということは、保安基準の無い世界である。規定がプログラムを前提としていない。自立性の限界(ロボットと操作者)最終的に人間がオーバーライトできる(自立の度合いによる)ことを認める必要がある。運転所のいない場合の法律の問題など。外部とのかかわり(データ保護、市場力の乱用)個人データ保護の問題。これらの内容に基づいて参加者による議論が行われたが、以下のような内容になる。RPAの利用範囲が様々である点が議論された。SIEM/SplunkをRPA/AIとしているケースもあり、何をもってRPAとするか、また、RPAのセキュリティ上の問題としてどう捉えるかということになる。1つの観点として、自律しているかで分けるということがあるが、自律をどのように判断するかという問題がある。プログラム化した場合に問題が発生した場合、どのように判断するかという問題となる。すると、プログラムのバグかどうかが分からない場合、法律的にどう判断するかという問題となる。Computing)のリスク管理にならざるを得ないということになる。業務アプリのIT統制として、ユーザ自身が守っていく必要がある。アクセス制御による保護、テストがきちんと行われている、使用のルールが定められていて利用者が守っていることなどである。RPA自体を正式なものとして承認されていることも重要になる。(RPAプラットフォーム)と呼ぶらしい。現状のRPAを表す言葉として、この中国の呼び方の方が近い感じである。RPAは無人化を可能にするかという議論になった。いわゆる自律できるかどうかということである。こちらは、強いAIと弱いAIということで、現状では無人化した場合のセキュリティは難しいと思われる。強いAI、つまり、自分で自分の手を考えられるという自律ということを考慮する必要があるということになる。実際、現場では、RPAの導入においては内部統制では使用しないという推奨を行っているということも示された。RPAにおけるリスク(誤入力、架空の処理)については、確認者による二重チェックが必要である。Processes)に対する取り組みなどがあり、今後も伸ばしていくことがきたいされるということである。RPAと法律ということで難しいテーマであり、方向性を導くというよりは抱えている問題を出し合う会議となった。今後シンギュラリティとかも考えていくと、セキュリティ面でも法律面でもいろいろと議論が進むことになるが、我々もしっかりとらえていく必要がある。会議後のご意見として以下のような議論のポイントが指摘されました。今後、あらためて検討していきたいと思います。公開APIの様に、公共のサイバー空間において利活用が進むにつれて、RPA動作空間と、人の意思決定空間の分離が、一つの有効手段になるかと考えています。歩道と車道が分離した道路交通法や、対人・対物の自賠責保険の様な社会的保障の仕組みが参考になると考えています。RPAでなないが、自動運転車レベル4になれば、即、現実化しますね。慎太郎(個人会員)前回、事業部門や機能部門の自律的なIT利活用を推進するための規制改革において、事前規制から事後チェックへとコントロールの力点を移すことが基本だとお話ししました。事前規制を緩和する典型的な例は、「許可制」を「届出制」(もしくは「完全自由化」)に変更することです。多くの大企業で、社用PCにインストール可能なソフトウェアは厳しく制限されていることと思います。これと同様に、クラウドサービスに関しても利用許可制を敷いている企業があるかもしれません。そのような企業では、許可手続きの煩雑さゆえに「シャドーIT」が拡散していることがあるかもしれません。クラウドサービス利用において許可制をコントロールとして採用する難しさの理由はいくつかありますが、その中の1つに定義の曖昧さがあります。あるサービスに関し、ある人はクラウドサービスだと考え、別の人はそう考えないかもしれません。天気予報をクラウドサービスだと思う人は少ないでしょう。facebookはどうでしょうか。800-145の定義が著名ですが、これはIaaSにはよく妥当するものの、ASP/SaaSには必ずしも妥当しないと私は思います。いって、官民データ活用推進基本法の「インターネットその他の高度情報通信ネットワークを通じて電子計算機を他人の情報処理の用に供するサービス」は、実務で使うには広すぎます。現実的な解の1つは、そのサイトがクラウドサービスに該当するか否かの議論は脇においておき、危険なサービスをブロックしてしまうことです。ブロックの解除を許可制とするとともに、ブロックされていないサービスについては、ひとまずは使ってよいと定めるのです。多くのCASB製品は、クラウドサービス自体の安全性評価を行っています。Matrixなど、何らかの評価基準を採用しています。この尺度に従って、リスクが非常に高いとされているサービスをブロック対象とすればよいでしょう。その値を定めるには、リスク値の分布が役に立ちます。CASB製品が示すリスクスコア(Skyhighの例)CASB製品が持っているクラウドサービス情報は、脅威インテリジェンス以上に重要なインテリジェンスだと私は思います。NISTサイバーセキュリティフレームワーク1.1ではサプライチェーンのマネジメントが新たに記載されましたが、外部委託であるクラウドサービスの効率的なマネジメントに第三者評価は欠かせません。できることなら、CASBベンダーにはこの情報を格納したデータベースだけAPIで提供してほしいくらいです。次回、届出制を採用した場合の運用方法を検討します。その業務と関係するものではありません。慎太郎(個人会員)「シャドーIT」という言葉を見かけることがあります。IT部門が知らぬ間に導入されるITシステムを指すようです。シャドーITを発見するための道具としてCASBが紹介されることもあります。個人的にはこの単語には違和感を覚えます。デジタルトランスフォーメーション(DX)が喧伝され、RPAなど企業活動におけるIT依存が高まる中、すべてのITシステムをIT部門が開発・調達することは現実的ではないでしょう。シャドーというと良からぬ響きを与えますが、事業部門や機能部門の自律的なIT利活用は、むしろ推奨されても不思議ではありません。政府のサイバーセキュリティ戦略本部は「サイバーセキュリティ人材育成プログラム」(2017年4月18日)の中で、「新しいITの利活用における体制例」を掲げました(p.8)。そこでは、事業部門がIT部門を介さず、直接ベンダー企業やクラウド事業者と契約してITを利活用する姿が描かれています。サイバーセキュリティ戦略本部「サイバーセキュリティ人材育成プログラム」(2017)上の文書を読んだとき、20年以上前に橋本内閣の下で「金融ビッグバン」として実行された金融規制改革を私は想起しました。旗印にして改革を推進した当時の課題意識が、現在の企業においてIT利活用を推進する際の課題意識と重なって見えたのです。デジタルトランスフォーメーションの実現には、IT規制改革が不可欠だと思わされました。規制改革の基本は、事前規制から事後チェックへとコントロールの力点を移すことです。そのためには、(裁量ではなく)明快なルールと適切な証跡とを必要とします。各部門の自律的なIT利活用が進めば、企業が利用するクラウドサービスの数は自然と増大するでしょう。CASBを追加的なセキュリティ対策とみなすよりも、事前規制を緩和してIT利活用を促進するために必要な措置だと考えるほうが適切かもしれません。次回は、事前規制の緩和にCASBを利用する方法を検討します。その業務と関係するものではありません。