CASBWGリレーコラム第10回「CASBはデータガバナンスの登竜門となる?」

CASBはデータガバナンスの登竜門となる?

株式会社シマンテック
高岡隆佳

クラウドで活用するデータ、どこまで許可するか

企業はCASBによってマルチクラウドの利用を一元的に可視化、制御ができることは間違いないのだが、CASB製品の評価において顕著に見られるのが、「企業として取り締まるべき情報(データ)の定義があいまい」なことだ。製造業や金融機関などにおいては、いわゆる業界ごとに定められたガイドラインや、他社に漏れては困る開発・設計データなどが明確に定められているが、そうでない場合、部署ごとにデータの機密性についての捉え方が異なっているために、企業全体としての「データ取り扱い」に関するルールが設定できないことが多い。そんな中、ややフライング気味にクラウドシフトしてしまった企業は、いざCASBで情報流出対策を打とうという時に、肝心のポリシーを策定することができないのだ。

一方の欧米諸国の現状はどうなのだろうか。「訴訟大国」とも揶揄されるアメリカでは、各業種非常にコンプライアンスに厳しく、また会社では情報の取り扱いに対する教育を徹底する文化が根付いている。取引先の情報が自社から漏れることによるリスク、インパクトが明らかに日本に比べると段違いだ。それゆえに古くからDLP(情報流出対策)の導入が自然と進んでおり、「データの棚卸し」が自動化されている。(導入比率でいうと、欧米:日本=10:1ほどだ。)もちろん「どのようなデータがどこまで活用されることが許容されるか」といったデータガバナンスが根底にあるからこそだ。

よって欧米欧州ではオンプレミスに徹底されているデータ取り扱いに関するポリシー(DLPポリシー)を、自分たちが採用したクラウドに対してはCASB経由でポリシー適用するだけでよい。日本企業の大部分は、そもそもオンプレミスにしっかりとしたDLPポリシーがないのにも関わらず、CASBによりクラウド上のデータを保護しようとしても、適切なポリシーも設定できなければ、またCASBで取り締まったところでオンプレミスの端末やメール添付、ファイル転送といったデータ流出経路はまったく可視化できないため、クラウドシフト半ばの日本企業においては、情報流出対策として十分な投資効果が出るとは思えない。

CASBとクラウドの正しい利用

仮に企業としてのクラウド活用指針(データの機微度に応じたリスク対処方法を含む)を定義できたとしよう。さて、その際にどれだけの企業が機微度の高いデータをクラウドに預ける判断を取るだろうか。CASBベンダーの提供するデータ保護機能は様々だが、機微度の高いデータだからといってオンプレミスに大量にデータをかかえてしまうのであれば、結果としてオンプレミスとクラウド、運用とサーバ費用が二重投資となる。クラウドシフトに舵を切る以上は、限りなくデータをクラウドに安心して預けられる環境を構築したいところだ。

そのためにはCASBの暗号化機能を活用することをお勧めする。

特定のクラウドサービスの暗号化を用いた場合は、暗号鍵管理がほぼクラウド側になるだけでなく、複数のクラウドサービスを利用するのであれば、それぞれ個別で暗号化設定の管理が必要となり、またクラウドサービスごとにセキュリティレベルは異なるためガバナンスは効かせづらい。CASBであれば、ブローカーとしての役割を果たすことで、どのクラウドサービスにデータを転送する際も、CASB側で一意の暗号化や匿名化を施し、また鍵管理もデータを預けるクラウドサービス側とは別で一元管理、そして暗号鍵の担保が下記のように可能だ。

1.       ユーザ側は機微度に関係なくクラウドにデータを預けることが可能となる。

2.       データの機微度に応じた制御がCASBで自動実行される。(暗号化・匿名化)

3.       利用時は本人認証などを通じて透過的に暗号鍵がロードされデータ閲覧・編集が可能となる。

4.       すべてのデータアクセスはCASB管理者側で把握でき、不正な鍵要求が見られれば該当のファイルに対して鍵を破棄し、復号できないことを担保することも可能となる。(Digital Shuredding)

日本企業はどうしてもセキュリティを「止める、縛る」ことを前提に設計しがちだが、その思想ではクラウドの最大活用を阻害してしまう。しっかりとデータガバナンスを効かせつつ、透過的にリスクを排除していくためにCASBという技術は存在する。そのためには企業の中でデータ利用、クラウド利用の指針を今一度見直し、CASBの機能で担保できるリスクが何であるのかを理解した上でクラウドシフトを正しく進めていただきたい。

CASBWGリレーコラム第9回「クラウド利用者とクラウドプロバイダ:双方の言い分」

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

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である。

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

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

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

 評価基準の大元としてよく使われるのが、CSAで策定しているCCMCloud Control Matrix)である。これはCSAジャパンで日本語版としてもリリースしているもので、下記からダウンロード可能である。
http://cloudsecurityalliance.jp/WG_PUB/CCM_WG/CSA_CCM_v.3.0.1-03-18-2016_ISO_J_Pub.pdf
(注: なお、ここで公開している日本語CCMControlの翻訳部分のみである。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という存在の登場により、ユーザ企業、クラウドプロバイダの相互理解が進むこと、ひいてはユーザ企業におけるクラウド活用の進展、そして生産性向上とともに社会の発展つながる、こういった流れをCSACASB-WGとしても独自の立場から応援していきたいと考えている。

 

CASBWGリレーコラム(第8回)「クラウドサービス利用のモニタリングとラベリング」

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

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

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

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

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

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

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

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

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

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

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

〈お断り〉

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

 

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

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

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

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

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

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

以上

 

CASBWGリレーコラム(第7回)「インテリジェンスとしてのCASB」

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

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

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

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

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

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

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

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

図 CASB製品が示すリスクスコア(Skyhighの例)

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

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

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

 

CASBWGリレーコラム(第6回)「IT規制改革を支えるCASB」

IT規制改革を支えるCASB

2018-05-08
CASBワーキンググループ
渡辺 慎太郎(個人会員)

「シャドー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を利用する方法を検討します。

 

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

 

 

 

CASBWGリレーコラム(第5回)「原則と現状のはざま」をCASBで対策できないか」

「原則と現状のはざま」をCASBで対策できないか

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

 

 

今回は趣向を変えて、CASB WG外の識者の意見を参考に筆を進めたい。

取り上げるのは、CSAジャパンの連携会員であるJNSAが発行するメルマガにて寄稿された「原則と現状のはざまで」と題するコラムである。
著者は株式会社Preferred Networks CISO, セキュリティアーキテクトを務めておられる高橋氏である。

ここで高橋氏は、IT・セキュリティに関わる原則(ポリシーやガイドライン等)の現状との乖離を指摘している。

一般的なセキュリティアーキテクチャ、セキュリティポリシーは、そもそも10~20年前に確立した原則に基づくことが多い。ところが今やクラウドサービスに代表される最新テクノロジーについて、これを採用しない(あるいは大幅遅延)ことは、逆に事業運営の観点で経営リスクともなる。
ITシステムがクラウド化することで、ベンダー、代理店やSIer、ユーザー(企業)の責任分界点が変化し、特にユーザーに求められるスキルが変わっている。
こういった変化を見落としてしまうことにより、セキュリティの原則と現状に乖離が発生しているのではないかというご指摘である。

3つのクラウドアーキテクチャ(IaaS、PaaS、SaaS)のそれぞれの責任境界については、CSA発行のガイダンスはじめ、クラウド利用の原則として良く取り上げられるところであるが、高橋氏はユーザー企業の立場によるリスク負担について言及しておられる。

さてこの状況にCASBが何か貢献できないか、いくつかケースを想定してみた。

・あるクラウドサービスが、信頼に足るかどうかを判定
(自組織の要求事項を満たすかどうかの判断)
・特定のクラウドサービス利用状況についての詳細モニタリング
・その中でも不適切と思われる操作を強制的に停止・中断

こういったケースではクラウドサービスの採用においてCASBが一定のリスクヘッジを実現し、クラウド活用を促進することができるように思われる。
以下に全文を引用するのでぜひご一読頂き、各組織においてどうなのか一度ご検討、ご判断を頂ければ幸いである。

なお、本稿の引用を快諾頂いた高橋氏、JNSA事務局にはこの場を借りて御礼申し上げます。

【引用元】
JNSAメールマガジン「連載リレーコラム」バックナンバー
www.jnsa.org/aboutus/ml-backnum.html

【連載リレーコラム No.132】

原則と現状のはざまで

株式会社Preferred Networks CISO, セキュリティアーキテクト
高橋 正和

私が強く印象に残っている発言に、「IT・セキュリティ部門は提案を止めるだけ
なので、提案の際には、IT部門やセキュリティ部門ではなく、事業部門に提案を
すべき」というものがある。衝撃的な話ではあるが、企業等の組織において、
IT部門やセキュリティ部門が邪魔になっている。本稿では、この要因と考える、
IT・セキュリティに関わる原則(ポリシーやガイドライン等)の現状との乖離
について取り上げたい。

これまで、20年近くベンダー側の立場でセキュリティに関わってきたが、昨年
10月からユーザー企業のセキュリティ担当として働き始めている。働き始めて
みると、大小のセキュリティ課題が常に存在し、セキュリティ担当は、会計担
当、法務等と同様に必要不可欠な専門職であると強く感じている。
日々、多様な判断が求められるが、十分な知見が得られないまま判断せざる得
ない場合も少なくない。適切にセキュリティ業務を行うための原則の重要性を
認識する一方で、原則と現状の乖離が深刻な阻害要因になることも実感してい
る。

原則と現状の乖離の要因として、PDCAが「Plan通りにDoが行われていることを
Checkし、必要なActを行う」として運用され、Planのチェックを行わない状況
がある。このため、優れた新たな施策があっても、これまでの原則に従い採用を
見送ることで、原則と現状の乖離が生じていく。原則の劣化を防ぐためには、
CIA(Confidentiality, Integrity, Availability)に基づいたリスク分析では
不十分で、事業リスクに基づいた「新たな施策を採用しない(事業)リスク」
についても分析する必要がある。

新たな施策の代表的な例としてクラウドサービスがある。ベンダー側の立場で
クラウドファーストという言葉を使ってきたが、市場は明らかにクラウド
ファーストになっており、新たなクラウドサービス利用の相談を頻繁に受けて
いる。その際に、セキュリティ対策状況分析を代理店に頼りたくなるが、日本
に代理店が無い場合や代理店経由では適切な回答が得られない事があり、何よ
りも、代理店に頼っていては、すぐに使い始めたいという社内の要求に応える
ことができない。結局のところ、自分でWebや試用版を使って確認し判断する
ことが求められる。ITシステムがクラウド化したことで、ベンダー、代理店や
SIer、ユーザー(企業)の責任分界点が変化し、特にユーザーに求められるス
キルが変わっている。この変化を見落とすことが原則と現状の乖離の要因と
なっている。

原則と現状の乖離の問題については、ふたつの取り組みを行っている。ひとつ
は、JNSA CISO支援ワーキンググループの活動である。活動をはじめて既に2年
が経過してしまったが、本年度中(2018年3月)のドキュメント公開を目指し
て作業を進めている。
合わせてJSSM(日本セキュリティマネジメント学会)の、学術講演会や公開討
論会でこのテーマを取り上げ、有識者の意見を伺い議論を進めており、3月17日
に開催する公開討論会でも、このテーマを取り上げていく。

第12回 JSSMセキュリティ公開討論会のお知らせ
http://www.jssm.net/wp/?page_id=2880

近年求められる情報セキュリティは、ITや経営と密接な関係にあり、その背景
には、IT環境の大きな変革がある。しかし、セキュリティ対策は10~20年前の
IT環境が前提であることも少なくない。
現在の経営やITに沿ったセキュリティ対策を提案し実践していくことが必要だ
と感じている。

連載リレーコラム、ここまで。

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

 

CASBWGリレーコラム(第4回)「アンケート調査で明らかになった、日本のシャドーIT意識の実態」

アンケート調査で明らかになった、日本のシャドーIT意識の実態

NTTテクノクロス株式会社
井上 淳

 今回は、先日NTTテクノクロスが実施した、企業におけるクラウドセキュリティに関するアンケートの結果を紹介していく。

■調査の背景

2020年までに、大企業の60%がCASBを使用※1」「クラウドセキュリティ市場は2021年に208億円に※2」など、クラウドセキュリティ分野では、これまで数多くのポジティブな市場予測が発表されてきた。また、実際にグローバル企業などのクラウドセキュリティについての意識が高いアーリーアダプターを中心に、日本でもCASB市場が大きく成長してきている。

しかし、マジョリティに当たる一般的な日本の企業におけるクラウドサービス利用の実態についての統計的な情報としては、総務省が毎年発表している情報通信白書以外にほとんど存在しないという状況であった。

日本の企業が実際にどのようなクラウドサービスを使っているのか、マルチクラウド利用は進んでいるのか、クラウドセキュリティに対する意識はどうなっているか、大企業と中小企業ではどのような違いが生じているのか。そういった生の情報が不足していたことから、今回、NTTテクノクロスではクラウドサービス利用状況の実態を調査するに至った。

1Gartner,Inc. Magic Quadrant for Cloud Access Security Brokers (2017)
2IDC Japan株式会社 国内クラウドセキュリティ市場予測、2017年~2021(2017) 

■調査結果について

回答者の属性や調査結果について、詳細についてはZDNet Japanで公開されているホワイトペーパー(URLhttps://japan.zdnet.com/paper/30001048/30002673/)を参考にされたい。本コラムでは、特徴的なポイントのみ紹介する。

■大企業と中小企業で異なる、利用しているサービスの傾向

設問2『選択肢の中にご利用中のクラウドサービス名(SaaS)があれば、教えてください』に対する回答は、1000名以上の企業と1000名未満の企業で回答の傾向に大きな差が生じた。

例えば、1,000 名未満では「GmailG Suite)」を挙げた回答者が最多であったのに対し、1,000 名以上では「Exchange OnlineOffice 365)」首位を逆転するといった具合だ。同様に、「OneDrive」「Dropbox」「Google Drive」は1,000名以下の企業での利用が多く、1,000 名以上では「Box」の回答割合が多くなるなど、類似サービスの中でも企業規模による利用傾向の違いが見える結果となった。

コスト面やセキュリティ面など、クラウドサービスの評価基準が企業規模によって異なるであろうことは予想できたものの、これほど如実に数字として表れたことは非常に興味深い結果となった。

 

 ■リスクは認識されつつも「自己責任」派が多数

設問6は、「利用が認められていない」クラウドサービスを、実際に社員が利用している、いわゆる「シャドーIT」が自社で発生しているという状況を認識している回答者に対して、『どうお考えですか』と質問した結果だが、「セキュリティのリスクがある」という認識を持つ回答が8割程度ではあったものの、そのうちの半分強にあたる42%の回答が「セキュリティリスクはあるが、自己責任の範囲で注意して利用すれば問題ないと考えている」と考える自己責任派であった。

CASBによるシャドーIT対策の必要性について重要なポイントの一つとして、「会社のルールでクラウドサービスの利用を禁止すると、従業員は代替のサービスや手段を探して利用する可能性があるため、さらにセキュリティリスクが増す(そのため、禁止するのではなく可視化して統制すべきである)」という考え方があるが、まさにそのような人間心理を裏付けるような結果となり、CASBが実現する「シャドーITは、可視化して統制すべきである」といった対策が有効であることが伺える結果となった。

■『CASB』の認知度はまだまだ

設問12では、直球で『クラウドセキュリティ対策の考え方の1 つである「CASB」をご存知ですか?』という質問を投げ掛けたが、63%が「知らない」という回答であり、認知している回答者は37%という結果であった。

セキュリティ分野における専門用語の一般的な認知度としてはまずまずである、と評価する見方もあるが、職種として「情報システム関連職」が5割を超えているという回答者の属性を踏まえると、CASBというクラウドセキュリティ対策はもっと認知されるべき存在である。今後も、WGの活動等を通じてCASBを啓蒙していくことの必要性を感じる結果となった。

■終わりに

セキュリティ分野のもう一つのトピックとして、NTTテクノクロスでは、昨年に引き続き「サイバーセキュリティトレンド2018」(URLhttps://www.ntt-tx.co.jp/products/cs-trend/)を公開した。

変化し続けるサイバーセキュリティの「今」を知ることができる資料となっている。こちらも無料でダウンロード可能となっているので、是非ご一読願いたい。

 

 

CASBWGリレーコラム(第3回)「GDPRとCASB」

GDPRCASB

CASBワーキンググループ
橋本 知典

 EU一般データ保護規則(General Data Protection RegulationGDPR)は2018525日から施行される。今回はCASBGDPRで対応できる支援領域や機能等を紹介していく。

 GDPRは簡単に言うとEUの個人情報保護法であり、EU内だけではなく日本企業においても影響があり、EUに支店、営業所や子会社を有していたり、日本からEUにサービス(商品)提供をしている場合は対象となる。罰金が非常に高く、関連する日本企業は施行に向け対応に追われている状況である。企業が使用しているクラウドサービスプロバイダーもGDPRの範囲内となり、企業とクラウドサービスプロバイダー間のデータの安全性、情報漏えい防止対策(DLP)を実現するにあたり、CASBが監査や企業のデータ保護にどのように役立つかを紹介する

■CASBが提供するGDPR対応支援領域

  • クラウドサービスにアップされている個人情報の把握ができる。
    個人を特定することができるデータ(名前、住所、電子メール、電話番号、パスポート番号など)の保護をするために必要なのは、それがどこにあるのかを特定することである。CASBは、さまざまなクラウドアプリケーションに対して、転送中のデータと既にクラウドアプリケーションに格納されているデータの両方をスキャンできる。
  • クラウドサービス内個人情報の保護ができる。
    機密データがどこにあるのかを特定したら、機密データの制御を考える。CASBには、個人情報、アンマネージドデバイスからのアクセスの制御、外部共有の制御、ダウンロード時のデータ暗号化などのさまざまなポリシーがある。これらのポリシーはすべて、違反のリスクを軽減することが可能である。
  • 利用されているクラウドサービスとその特性の把握ができる。
    クラウドサービスプロバイダーがGDPRに対応できているか、その他コンプライアンスに準拠しているかをCASBのクラウドサービスデータベースを確認することで把握ができる。
  • 認めていないクラウドサービスへの個人情報の保存を防げる。
    組織が把握していないクラウドサービスは制御できず、GDPR違反のリスクがある。CASBを使用すると、認可されていないクラウドサービスの利用を可視化して特定し、個人情報を保存してしまうケースをリアルタイムに防いだり、監視してアラートとして検知できる。また認めているクラウドサービスから認めていないクラウドサービスへのデータの移動も脅威として検知することができる。
  • リスクのある行動の監視
    CASBではリスクの高いクラウドサービスの利用等、ユーザがリスクのある行動をした場合、分析して脅威としてアラートを通知できる。GDPRの違反に該当するような脅威の兆候を可視化し、アラートとして通知され、違反に該当する行動を監視して停止することができる。

■CASB製品での機能例

  • 通信途中、およびクラウドアプリ内保存済みデータのスキャン
  • 該当データの保護機能 (共有禁止、削除、暗号化等)
  • クラウドサービスデータベース にてクラウドサービスごとのGDPR対応能力ランクを提示
  • GDPR対象データを検出するDLPテンプレートや関連するDLPテンプレートを提供
  • その他個人情報関連テンプレートを広範に提供
  • アノマリー検知を行い、リスクを表示

1 GDPR対応能力ランク

  以上のように、GDPRCASBが対応でき、監査としての機能が備わっていることが分かる。クラウドサービスプロバイダーとクラウドサービスカスタマーは、データ管理と保護に関するGDPRの重大な影響を認識し、違反を起こさないようにしなければならない。クラウドサービスは多くの組織に存在し、個人情報の追跡、管理を困難にしている。CASBを利用してGDPRの監査や対応を進めてみてはいかがだろうか。

CASBWGリレーコラム(第2回)「CASB v.s. SWG – クラウドセキュリティ?それともウェブセキュリティ? -」

CASB v.s. SWG
– クラウドセキュリティ?それともウェブセキュリティ? –

株式会社シマンテック
高岡隆佳

現場で聞こえる混乱の声

前回紹介したCASB(クラウドアクセスセキュリティブローカー)。企業におけるセキュリティ要件としてCASBへの対応を挙げる企業が増えているのは事実だが、それと同様にCASBが満たす要件と企業側の要件についてズレが見られるケースが増えてきている。CASBはその名の通り、クラウドへのアクセスについてセキュリティを一元的に担保するための仲介者(ブローカー)となるわけだが、兎角、クラウドセキュリティと従来のウェブセキュリティの要件が曖昧な企業においては混乱を招く結果となる。当方が考える現時点において最も多い混乱の一つが、CASBとSWG(Secure Web Gateway)の領分の違いからくるものだ。

従来企業はウェブアクセスを安全に管理するための手段として、プロキシを利用し、通信先のURLカテゴリを判定し、場合によっては有名なウェブアプリケーションであれば認識した上でSSL通信内部のダウンロードコンテンツをアンチウイルスやサンドボックス処理で分析したり、また証跡をアクセスログとしてインシデント対応に役立ててきた。場合によってはプロキシでDLP連携することで所定の機密情報の流出をブロックしたり、暗号化した状態で外部へ送信するなどのコントロールポイントとして活用してきた。SWGはオンプレミスのプロキシをクラウド上のプロキシへポリシー連携させ、社員外出時やプロキシの置けない拠点であっても企業のウェブセキュリティを適用できるように考慮された、いわばハイブリッド型のウェブプロキシになる。(SWG自体は10年前にGartnerが定義した技術要項)

“Secure Web gateway solutions protect Web-surfing PCs from infection and enforce company policies. A secure Web gateway is a solution that filters unwanted software/malware from user-initiated Web/Internet traffic and enforces corporate and regulatory policy compliance. These gateways must, at a minimum, include URL filtering, malicious-code detection and filtering, and application controls for popular Web-based applications, such as instant messaging (IM) and Skype. Native or integrated data leak prevention is also increasingly included.”
引用1 Gartner IT Grossary secure web gatewayhttps://www.gartner.com/it-glossary/secure-web-gateway/)

 

企業の要件はクラウドセキュリティか

これに対してCASBは前回の記事でも整理したように、クラウドプロキシで終端したクラウドアクセスに対するセキュリティ機能の提供や、各アプリケーション提供APIによる詳細なデータアクセス制御、シャドーITと言われるリスクの高いアプリケーションに対する制御に限定されるため、CASBがクラウドアプリとして判定しなかった通信先への制御が対象外となるのはもちろん、その他インターネットサイトについての制御も、C&C通信などについても対象外となる。

一方でCASBにしかないメリットとしては、ユーザがクラウドにアップロードしてしまったデータに対して、APIを通じた何がしかの情報流出対策ポリシーが後出しでかけられる点だろう。このため一般的にはAPIを通じて企業が定めるDLPポリシーを業務SaaSに広く適用し、業務SaaS経由での情報流出リスクを低減するといった使い方が多いようだ。ただ最近ではSWG自体がCASB機能を包含してしまっているケースもあるため、厳密なCASBだけのメリットというのも定義は難しくなっているのも現場の混乱を招いている一因と言える。実はこれについてはGartner2016年のGartner Summitにおいて、CASBはやがてネットワークファイアウォール、SWGWAFなどにパッケージ化されていくだろうという予測を出しており、導入する側の企業としては、その要件について純粋なCASBが満たすのかそれともパッケージ化された既存技術が適切なのかを判断するよう説いている。

余談だが、シマンテック内部ではすでに約40種類のクラウドアプリケーションを業務で採用しており、それらのアプリケーションはSWGベースのCASBを通じて、ユーザが社内にいても出張先にいても同様のセキュリティが適用されている。もちろんクラウドだけでなく一般のウェブアクセスについても、データに対する制御や監査が適用される。採用するクラウドの数が増えれば増えるほど投資効果が出るのがCASBだが、クラウドシフトがまだ過渡期である日本企業にとって、CASBという技術が渡りに船となるかどうかは、企業がクラウドシフトをどの程度本気で検討しているかで決まるのかもしれない。

図1 CASBSWGのセキュリティ要件の違い