クラウド利用者とクラウドプロバイダ：双方の言い分

CASBワーキンググループ ・リーダー
上田光一

CSAでは定期的に「クラウド利用者会議」という会合を開催している。これはクラウド利用者側の観点でクラウドに期待すること、あるいは課題などをディスカッションするもので、CSAジャパンの本ブログでも結果を議論の内容を紹介している。

先ごろ行われた会議で、どのようにクラウドプロバイダを選択すればよいかわからない、といったコメントがあった。プロバイダの公開情報や試用する中で業務への適合性は確認できるとしても、セキュリティの観点での差分が見えないというものである。

 一方、プロバイダ側コメントとして、不確定の伝聞情報で大変恐縮ながら以下のようなコメントがあったとのことであった。

• プロバイダ側としてはセキュリティに関する情報なので非公開である
• 仮に公開したとしても普通のユーザでは適切な判断ができるか懸念がある

 確かに利用者にとっては、クラウドを利用するに際してどのようにプロバイダのセキュリティレベルを判断すれば良いのかは課題である。利用者が自力で判断しようとするとき、プロバイダが公開しているセキュリティ情報を元にこれを行うことになるが、ここで欧米と日本で大きな違いがある。欧米のプロバイダの対応は、セキュリティ情報を積極的に公開することで利用者が判断できるようにする傾向が強い。いわゆる「透明性」を高めるということである。これは、また、セキュリティをビジネス上の差別化要因にできるという利点がある。

一方、日本のプロバイダはあまりセキュリティ情報を公開しない。どちらかというと、「セキュリティ情報を公開することはリスクを高める」という考えを持っている。取得している認証の情報を公開しているが、認証ではセキュリティの成熟度を把握することは難しい。このあたりは国内事情としてはやむを得ない印象を受ける一方で、米国はじめグローバルの事情とはかなり異なっている。

CSA本部のWebサイト、https://cloudsecurityalliance.org/では、以下のような情報を提供するページがある。

 CSA Security, Trust & Assurance Registry (STAR)　https://cloudsecurityalliance.org/star/#_registry

 これはCSAが提唱する認証制度STARを一つの基準としつつ、STAR認証取得の有無に関わらずクラウドプロバイダ側が自社のセキュリティ対応状況を公開するページとなっている。クラウドプロバイダとしては、自社サービスの透明性と公正さをアピールする場にもなっている訳である。

一見して分かる通り米国プロバイダが圧倒的に多いのは当然としても、中国プロバイダも数多く登録されていることは興味深い。日本のプロバイダはごく僅かに留まっている。

 一例としてクラウドストレージのBoxをとってみると、以下で詳細情報が得られる。https://cloudsecurityalliance.org/registry/box/

 ここからCSAの提唱するクラウドプロバイダ向けセルフアセスメントのフレームワーク、CAIQ （Consensus Assessments Initiative Questionnaire） に従って、プロバイダ自身が（このケースではBox社が）自己評価をした結果が得られる。興味のある方はぜひご一読頂きたいが、なかなかの情報量である（しかも英語）。

そうなってくると、こうした情報が得られるとしても、それを利用者が正確に判断できるのか、いわゆる利用者のセキュリティ・リテラシが問題となる。

 さてここでCASBである。

 CASBの4つの柱のうち１つ目の柱である「可視性」、ここには「どのクラウドサービスを使っているか」という意味合いとともに「それはどんなクラウドサービスであるか」という観点がある。対象とするクラウドサービスがどのような種別のサービスを提供するのか、そしてどのようなセキュリティ機能を提供しているか、こういった情報を、CASBは提供する。そしてここで重要なのが、CASBはセキュリティ状況をシンプルにリスクスコアとして判定して提供してくれることということである。

例えばあるCASBでは、クラウドサービスのリスクスコアを9段階で評価してくれるため、信頼を寄せられる程度が簡単に判断できる。

 ではそれはどのような基準でスコアリングを行っているのだろうか。

 評価基準の大元としてよく使われるのが、CSAで策定しているCCM（Cloud Control Matrix）である。これはCSAジャパンで日本語版としてもリリースしているもので、下記からダウンロード可能である。
http://cloudsecurityalliance.jp/WG_PUB/CCM_WG/CSA_CCM_v.3.0.1-03-18-2016_ISO_J_Pub.pdf（注：　なお、ここで公開している日本語CCMはControlの翻訳部分のみである。CCM全体のEXCEL版は、現在CSAジャパン会員のみが利用可能となっている。）

 最新版のv3.0.1では、16ドメイン、133項目からなっていて、例えば以下のような項目がある。

• カテゴリ：データセンタセキュリティ
• 項目：コントロールされたアクセスポイント
• 説明：機微なデータ及び情報システムを保護するために、物理的なセキュリティ境界（フェンス、壁、柵、警備員、ゲート、電子的監視、物理的認証メカニズム、受付デスク、安全パトロールなど）を実装しなければならない。

 例1）

• カテゴリ：暗号化と鍵管理
• 項目：権限付与
• 説明：鍵には識別可能な所有者が存在し（つまり鍵とアイデンティティが紐付いていること）、また（組織には）鍵管理ポリシーがなくてはならない。

 例2)

• カテゴリ：脅威と脆弱性の管理
• 項目：脆弱性 / パッチ管理
• 説明：（長いので省略。ぜひCCMをご参照ください）

 CASBベンダはこういった情報を前述のCAIQやクラウドプロバイダのWebサイトによる公開情報などから入手する。公開情報がない場合は、個別にクラウドプロバイダに問い合わせることもする。クラウドプロバイダから回答が得られない場合は、その状況を踏まえCASBベンダが独自に判定することになる。

またスコアリング項目は必ずしもCCMと完全一致という訳でなく、CASBベンダ自身による重みづけや独自観点も加味する形で算出されている。また重みづけについてはユーザによるカスタマイズ機能を提供しているCASBもある。

 各クラウドプロバイダのセキュリティ対応状況も刻々変化する一方、クラウドプロバイダもサービスの数自体も増加していくので、CASBベンダはこういった状況にも追随して対応している。特定のクラウドサービスが登録されていない場合は、リクエストにより追加登録対応してもらえる。

 CASBベンダはこのような取り組みを通して、クラウドプロバイダやサービスごとのセキュリティ対応状況データベースを日夜更新しており、今や登録サービス数30,000に迫るデータベースを保持するCASBベンダもある。

従来国産クラウドサービスについては対応サービスが限られる状況があったが、対応数も順調に増加しているようである。

組織によっては申請ベースでクラウド利用を個別に許可する運用を行っていることも多いと思うが、さらに個別に個々のクラウド利用審査のための調査が大変だ、という声を聞くこともある。クラウドを使いたいのに選択の判断情報がない、あるいは調査のための労力が無視できない。これをCASBのリスク判定で代替してしまう。これは一つの有効なCASB活用事例と言えそうである。

 しかしながらそれ以上にこういったリスク評価基準の策定フェーズにおいては、企業のクラウド活用における根本命題、すなわち「企業としてどのような観点でクラウドを活用していくか」という点に向き合うこととなる。これは企業のクラウド活用戦略を立てる良い機会となるだろう。

 CASBという存在の登場により、ユーザ企業、クラウドプロバイダの相互理解が進むこと、ひいてはユーザ企業におけるクラウド活用の進展、そして生産性向上とともに社会の発展つながる、こういった流れをCSAのCASB-WGとしても独自の立場から応援していきたいと考えている。

クラウドサービス利用のモニタリングとラベリング

CASBワーキンググループ
渡辺 慎太郎（個人会員）

いわゆるシャドーIT対策機能を有するCASBを組織で導入すると、その組織内で利用されているクラウドサービスが一覧化されるとともに、利用状況が可視化されます。

あまりにたくさんのサービスが可視化されてしまい、途方に暮れてしまうかもしれません。なすべきは、可視化された各クラウドサービスにラベルを付けることです。たとえばオペレーションの観点から、「社内標準」「全社許可」「一部許可」「不許可」「判定中」「対象外」などと分けます。なぜ「対象外」があるのかというと、CASBがクラウドだと判定していても、そうとは考えられないサイトが存在するからです。

「社内標準」はいいとして、「全社許可」「一部許可」「不許可」の判断が難しいかもしれません。これは、その組織のリスク許容度に依存するからです。ここでは、クラウドサービスを通じた従業員による情報の持ち出しを脅威シナリオとして想定し、方針決定の一例をご紹介します。

方針決定の際に使える変数は、主に3種類に分かれます。それは、主体（誰が使うのか）・対象（どんな情報を取り扱うのか）・環境（サービス自身は信頼におけるか）です。

理念的には、対象（どんな情報を取り扱うか）によって方針を定めるべきです。極秘の新製品情報と一般的な社外秘情報とを同列に扱うべきではありません。ただし実運用上は、対象による方針決定はモニタリングを困難にします。通信の中身を追わなければならなくなるからです。

そこで実践的には、主体に沿って方針を決定します。業務分掌が確立していれば、組織によって取り扱う情報が大まかに決まりますから、ある程度の近似になります。ただし、CASBが取得するネットワーク機器（Webプロキシーなど）のログからはアカウント名しか分からないでしょうから、組織と紐づけるためにActive Directoryなどのディレクトリーサービスと情報連携する必要があります。

L7まで見られる高機能ファイアウォールを使ってセキュリティゾーンを定義しているなら、その分類を活用するのが最善です。その際にはユーザーやセキュリティグループ単位で各ゾーンのアクセス制御を行っているでしょうから、それをクラウドサービスにも準用するのです。そうすれば、社内ネットワークと一貫性のある方針になります。

可視化されたサービスのラベリングが完了したら、定常運用に入ります。日次でモニタリングして新たに観測されたサービスをラベリングし、届け出のないサービス利用を発見したら正規手続きを促します。

最後に1点、注意すべき点があります。それは、CASBがクラウドサービスだと認識していないSaaS/ASPが、我が国にはたくさんあることです。届出制を採用している場合には、届けられたサービスがCASBに載っているかどうかをチェックし、載っていない場合には照会する手続きが発生します。CASBによってはアップロードのバイト数からSaaS/ASP候補を出力する機能がありますので、その機能を使って能動的に発見することもできるかもしれません。

〈お断り〉

本稿の内容は著者の個人的見解であり、所属企業・団体及びその業務と関係するものではありません。

第10回クラウド利用者会議　レポート

2018年8月12日
CSAジャパン　諸角昌宏

第10回クラウド利用者会議では、「RPAと法律的な問題点」というテーマで高橋氏にご説明いただいた。会議は、7月30日(月)に開催し、クラウド利用者を中心として10名に参加いただいた。

まず、ロボットにおける用語とRPAとの関係について触れられた。ロボットとして以下の2つの用語の定義を明確にしておく必要がある：

• ロボテック：　プログラムに基づいて合理化すること
• 法律的：　マニプレーターと記憶装置が必要であること

その上で、RPAはどうなるかというと、自律的な操作が表現されたエキスパートシステムであるということができる。ただし、RPA自体がバズワード化しており、実際に何を差すのかは明確にしずらい状況である。

その中で、RPAとはということでは、以下の3つの手段に分かれる：

1. 定型業務の自動化：　いわゆるRPAとしての狭義の意味になる
2. EPA（Enhanced Process Automation）とAIの使用：　大量のデータを解析し結果を出力できる機能
3. コグニティブ・オートメーション：　ディープラーニング、自然言語処理などにより、自立した結果を出力し経営意思決定に結び付ける能力

これらを踏まえてRPAを含むロボットの問題として、以下の3つの領域で考える必要がある：

• 安全/セキュリティ
  安全基準/保安基準がどうなるのか？プログラムでコントロールされるということは、保安基準の無い世界である。つまり、規定がプログラムを前提としていない。
• 自立性の限界(ロボットと操作者)
  最終的に人間がオーバーライトできる（自立の度合いによる）ことを認める必要がある。たとえば、運転所のいない場合の法律の問題など。
• 外部とのかかわり（データ保護、市場力の乱用）
  個人データ保護の問題。

さて、これらの内容に基づいて参加者による議論が行われたが、以下のような内容になる。

まず、RPAの利用範囲が様々である点が議論された。SIEM/SplunkをRPA/AIとしているケースもあり、何をもってRPAとするか、また、RPAのセキュリティ上の問題としてどう捉えるかということになる。1つの観点として、自律しているかで分けるということがあるが、自律をどのように判断するかという問題がある。プログラム化した場合に問題が発生した場合、どのように判断するかという問題となる。そうすると、プログラムのバグかどうかが分からない場合、法律的にどう判断するかという問題となる。

現状は、RPAのセキュリティ上の問題は、EUC（End User Computing）のリスク管理にならざるを得ないということになる。業務アプリのIT統制として、ユーザ自身が守っていく必要がある。アクセス制御による保護、テストがきちんと行われている、使用のルールが定められていて利用者が守っていることなどである。また、RPA自体を正式なものとして承認されていることも重要になる。なお、中国ではRPAのことを「工作自動化平台」（RPAプラットフォーム）と呼ぶらしい。現状のRPAを表す言葉として、この中国の呼び方の方が近い感じである。

また、RPAは無人化を可能にするかという議論になった。いわゆる自律できるかどうかということである。こちらは、強いAIと弱いAIということで、現状では無人化した場合のセキュリティは難しいと思われる。強いAI、つまり、自分で自分の手を考えられるという自律ということを考慮する必要があるということになる。

実際、現場では、RPAの導入においては内部統制では使用しないという推奨を行っているということも示された。RPAにおけるリスク（誤入力、架空の処理）については、確認者による二重チェックが必要である。

以上のような状況であるが、RPAを含むIoTに対する安全基準は日本がリードしている、特に、電力関係の保安基準や、IPAのSTAMP（System Theoretic Accident Model and Processes）に対する取り組みなどがあり、今後も伸ばしていくことがきたいされるということである。

RPAと法律ということで難しいテーマであり、方向性を導くというよりは抱えている問題を出し合う会議となった。今後シンギュラリティとかも考えていくと、セキュリティ面でも法律面でもいろいろと議論が進むことになるが、我々もしっかりとらえていく必要がある。

なお、会議後のご意見として以下のような議論のポイントが指摘されました。今後、あらためて検討していきたいと思います。

①    定義論について
論点１）RPAを、ロボットと見做すか、Excelのマクロ関数もどきと見做すか
論点２）RPAを、開発者責任と見做すか、所有者責任と見做すか
論点３）RPAを、シーケンス型制御と見做すか、自律学習型回帰制御と見做すか

②    法的拘束力について
RPAに関するモノに物理的棄損を課した際の帰属の在り方
RPAを利活用したAPIで自動送金した際の誤送金の帰属の在り方
RPAに関する司法手続に関する法制度の在り方
RPAに関する犯罪捜査及び刑事訴訟の在り方、法廷監査の効力を含めた議論
RPAに関する民事訴訟や裁判外紛争解決の手続の在り方

➂課題解決の私見
公開APIの様に、公共のサイバー空間において利活用が進むにつれて、RPA動作空間と、人の意思決定空間の分離が、一つの有効手段になるかと考えています。例えば、歩道と車道が分離した道路交通法や、対人・対物の自賠責保険の様な社会的保障の仕組みが参考になると考えています。RPAでなないが、自動運転車レベル４になれば、即、現実化しますね。

以上

インテリジェンスとしてのCASB

2018-06-18
CASBワーキンググループ
渡辺 慎太郎（個人会員）

前回、事業部門や機能部門の自律的なIT利活用を推進するための規制改革において、事前規制から事後チェックへとコントロールの力点を移すことが基本だとお話ししました。

事前規制を緩和する典型的な例は、「許可制」を「届出制」（もしくは「完全自由化」）に変更することです。多くの大企業で、社用PCにインストール可能なソフトウェアは厳しく制限されていることと思います。これと同様に、クラウドサービスに関しても利用許可制を敷いている企業があるかもしれません。そのような企業では、許可手続きの煩雑さゆえに「シャドーIT」が拡散していることがあるかもしれません。

クラウドサービス利用において許可制をコントロールとして採用する難しさの理由はいくつかありますが、その中の1つに定義の曖昧さがあります。あるサービスに関し、ある人はクラウドサービスだと考え、別の人はそう考えないかもしれません。おそらく、食べログやYahoo! 天気予報をクラウドサービスだと思う人は少ないでしょう。では、facebookはどうでしょうか。Slackは？

クラウドといえばNIST SP 800-145の定義が著名ですが、これはIaaSにはよく妥当するものの、ASP/SaaSには必ずしも妥当しないと私は思います。といって、官民データ活用推進基本法の「インターネットその他の高度情報通信ネットワークを通じて電子計算機を他人の情報処理の用に供するサービス」は、実務で使うには広すぎます。

現実的な解の１つは、そのサイトがクラウドサービスに該当するか否かの議論は脇においておき、危険なサービスをブロックしてしまうことです。そして、ブロックの解除を許可制とするとともに、ブロックされていないサービスについては、ひとまずは使ってよいと定めるのです。

多くのCASB製品は、クラウドサービス自体の安全性評価を行っています。この際、Cloud Security AllianceのCloud Control Matrixなど、何らかの評価基準を採用しています。この尺度に従って、リスクが非常に高いとされているサービスをブロック対象とすればよいでしょう。その値を定めるには、リスク値の分布が役に立ちます。

図　CASB製品が示すリスクスコア（Skyhighの例）

CASB製品が持っているクラウドサービス情報は、脅威インテリジェンス以上に重要なインテリジェンスだと私は思います。NISTサイバーセキュリティフレームワーク1.1ではサプライチェーンのマネジメントが新たに記載されましたが、外部委託であるクラウドサービスの効率的なマネジメントに第三者評価は欠かせません。できることなら、CASBベンダーにはこの情報を格納したデータベースだけAPIで提供してほしいくらいです。

次回、届出制を採用した場合の運用方法を検討します。

〈お断り〉
本稿の内容は著者の個人的見解であり、所属企業・団体及びその業務と関係するものではありません。