作成者別アーカイブ: 諸角昌宏

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のセキュリティ要件の違い

 

 

 

CASBWGリレーコラム(第1回)「日本企業がCASBに求めるものとは? - CASBがバズワードで終わらない理由- 」

日本企業がCASBに求めるものとは?
– CASBがバズワードで終わらない理由 –

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

注目の技術“CASB”到来

昨今のセキュリティ記事やイベントでよく耳にするようになった“CASB”。なんとなくその存在を知っているという人と、すっかりCASBの実用に向けて検討を進めている、ないしは導入済み、運用中といった企業が大きく分かれる、まさにこの新技術がブレークする直前の過渡期の様相となっている。

まだご存知ではない方にこのCASBの概略を説明すると、2013年にGartnerが提唱した技術で、“CASB = Cloud Access Security Broker”の呼び名が体を表しているように、「クラウドの利用において安全を担保してくれる仲介者」としての機能を提供する、新しいセキュリティ・レイヤーだ。管理者すら認識していない個々のユーザのクラウド利活用を「可視化」し、企業の「コンプライアンス」を満たさない脆弱なクラウドアプリを排除、SSL通信内に潜む機密情報の流れを把握しつつ、成りすましや情報流出に繋がるユーザのクラウド上の活動をふるまい分析などにより、「脅威の防御」が可能になる。併せて、クラウドに保存される機密情報を暗号化やトークン化(匿名化)、本人認証などを組み合わせて「データ保護」することで、クラウドというグレーなプラットフォームを「企業側でコントロール」することができ、結果として企業はサーバなどの投資やメンテナンスといった負担から開放されつつも、拡張性に富んだクラウド上で安全にビジネスデータを利活用できるようになる。

図1 CASBを構成する4つの柱

日本におけるCASBのニーズ

そんなCASBが日本において本格的に導入が始まったのは2015年以降、O365やBOXといった業務アプリケーションの導入が一気に進んだ頃だ。メール、そしてファイルストレージといった企業のデータ共有を主とするアプリケーションがクラウド化することにより、「安かろう悪かろう」といったクラウドの価値観は企業の中で崩壊を迎えた。

なぜなら、そもそも企業が今までセキュリティに投資してきた主たる目的は企業内の資産、すなわち「データ」を様々な脅威(標的型攻撃や内部不正など)から守ることであり、そのためにあらゆる技術を組み合わせて多層防御網を構築してきたわけで、さらにはそれらの網を健常化するための監視役として、SOCやCSIRTといった専任部隊にも投資を行ってきた。

しかしクラウドシフト、最近では「働き方改革」といったワークスタイルの変革により、「データ」自体がオンプレミスを離れ、さらにはユーザ自体が多層防御の効かない企業外から、同じアカウントを別のパソコンから(場合によってはスマートフォンから)利用することでもアクセスが可能になってしまった。

つまり、クラウドに上がってしまったデータについてはそれぞれのクラウドアプリケーション側のセキュリティに依存してしまうものの、SLA上クラウド側のデータ損失や漏洩については一般的に保証されず企業責任となってしまうにも関わらず、クラウドに上がったデータ、そして企業外からのクラウドアクセスについて何かしらの対処を打つ必要性が出てきた。それこそがCASBに対する期待値およびニーズの根源となっている。企業がオンプレで利用していたセキュリティ機能をクラウドへ適用し、SOC/CSIRTの監視対象にクラウドも巻き込めるようになるものこそがCASBなのだ。もはや企業にとってクラウドは、データ活用のためには無くてはならないプラットフォームであり、活用する以上はオンプレと同様にセキュリティ投資をすることで十分なメリットを享受し、投資効果を得るという考え方にシフトしてきているのだ。

図2 CASBとは各クラウドに対する企業のバーチャルSOC的なもの

CASBの適用方法は一つではない

クラウドを安全に活用する、というゴールは一つだが、Gartnerが定義しているCASBの適用手法としては大きく分けて以下の3通りがある。

0)    シャドーITの可視化:オンプレミスのネットワーク機器(FWやプロキシ)および端末のログをCASBプラットフォームで解析させることで、どのユーザがどのようなアプリケーションをどの程度活用しているかを可視化、いわゆる野良クラウド(シャドーIT)を制御するための情報を得る

1)        業務アプリの自動リスク制御:O365やBOXなど、企業としてアカウントを払い出している(投資している)アプリケーション毎に、外部ドメインへの機密ファイル共有といったリスクあるユーザのふるまいを検知、その都度共有解除や権限変更、またはファイル暗号化や認証といったセキュリティ制御をリアルタイム自動的ににかけていく

2)      一元的なクラウド利用ポリシーの適用:モバイルからもオンプレミスからもユーザのクラウド通信をプロキシ(ないしはクラウドプロキシ)で終端することで、リスクの高いデータの流れやユーザのアクセスをブロックし、また各クラウド利用におけるユーザの証跡(アクセセスログ)を一元的に確保することで、オンプレミスのSOC/CSIRT機能をクラウドまで含めて運用可能にする

シャドーIT可視化を0としているのは、一般的にCASB製品ベンダーが提供するサービスにおいて、企業におけるシャドーIT利用状況把握のための評価期間(通常1か月程度)を提供しているケースが多いため、CASB導入前のアセスメント的な立ち位置として捉えるケースが多いからだ。(有料サービスであれば、定常的にログを分析し、シャドーIT利用の統計を取ることも可能だ)

一般的にはAPI型による業務アプリケーションごとの詳細な制御や、ゲートウェイ型(プロキシ型)による横断的なクラウドの制御を行うことで継続的にクラウドアクセスを制御する手法自体が優先されるケースが多いのも日本ならではの要件かもしれない。

3  CASB実装方法

このように様々なクラウドセキュリティ要件を満たせるCASB。働き方改革やモバイルセキュリティについて検討をしている企業であれば、ぜひ一度CASBについて評価・検討してみてはいかがだろうか。

 

CASB-WG リレーコラム始めます!

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

 

今、本稿に目を通して頂いている読者の皆様は、CASBもしくはクラウドセキュリティ全般にご興味のある方と思います
CSAジャパンのCASB-WGは発足からちょうど2年、CSAグローバルに上位活動を持たないCSAジャパンとしての独自活動を展開して参りました。ちょうど1年程前には、日本国内でのCASB理解に一石を投じるべく、独自に執筆したホワイトペーパーをリリースしました。(こちらからダウンロードできます)。
それから1年、市場でもCASBに関する話題には事欠きませんでした。ホワイトペーパーのリリース前後には、CASBベンダのNetskopeが日本上陸、11月にはGartner社がCASBのMagic Quadrantの初版をリリースしました。それとほぼ同時期に、大手セキュリティベンダのMcAfeeがCASBベンダの老舗Skyhigh Networksを買収する、といったニュースが飛び込んできました。今やCASBというキーワードは一般化し、ますますホットなものになってきたと言えるでしょう
ただ悩ましいのはベンダやプレイヤーも増加する中で、当初Gartner社が提唱してきたコンセプトとは少しずつ違った切り口での情報も目に付くようになってきたことですこういった変化自体はGartner社自身が認めていることでもあり、新技術の定着過程において起こりがちなことでもありますこれは良い意味では、Gartner社のコンセプトありきという段階から、より実地に即したものに進化してきたと見ることができるでしょう。ただホワイトペーパーのような一元的情報編纂の取り組みについてはその完成時には環境変化により、あるいは物足りないものとなってしまう懸念があることも事実で
そこでCASB-WGとしては、タイムリー、コンパクトかつ多様性のある情報発信を意図し、これから数回に分けて本ブログにてリレーコラムとして記事をアップしていくことと致しました。複数のCASBベンダー、再販パートナー、利用者組織等々、様々な観点で執筆していく予定となっております。ぜひ楽しみにして頂ければと思います
なお本ページは、リレーコラムのインデックスとなるよう以下にリンクを追加していきます。

 

  1. 第1回:「日本企業がCASBに求めるものとは?- CASBがバズワードで終わらない理由- 」 株式会社シマンテック 髙岡隆佳 (2018年2月27日公開)
  2. 第2回:「CASB v.s. SWG – クラウドセキュリティ?それともウェブセキュリティ? –」 株式会社シマンテック 髙岡隆佳 (2018年3月16日公開)
  3. 第3回:「GDPRとCASB」CASBワーキンググループ 橋本知典 (2018年3月24日公開)
  4. 第4回:「アンケート調査で明らかになった、日本のシャドーIT意識の実態」 NTTテクノクロス株式会社 井上淳 (2018年4月10日公開)
  5. 第5回:「「原則と現状のはざま」をCASBで対策できないか」 CASBワーキンググループ・リーダー 上田光一 (2018年5月7日公開)
  6. 第6回「IT規制改革を支えるCASB」 CASBワーキンググループ 渡辺 慎太郎(個人会員)(2018年5月8日公開
  7. 第7回「インテリジェンスとしてのCASB」 CASBワーキンググループ 渡辺 慎太郎(個人会員)(2018年6月18日公開)
  8. 第8回「クラウドサービス利用のモニタリングとラベリング」 CASBワーキンググループ 渡辺 慎太郎(個人会員)(2018年9月8日公開)
  9. 第9回「クラウド利用者とクラウドプロバイダ:双方の言い分」 CASBワーキンググループ 渡辺 慎太郎(個人会員)(2018年9月8日公開)
  10. 第10回「CASBはデータガバナンスの登竜門となる?」株式会社シマンテック 高岡隆佳 (2018年12月6日公開)

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

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

2018年2月16日
CSAジャパン 諸角昌宏

第9回クラウド利用者会議では、IoTのセキュリティに関わる課題というテーマで笠松氏にご説明いただいた。会議は、2月5日(月)に開催し、クラウド利用者を中心として9名(内1名はオンラインでの参加)に参加いただいた。

まず、IoTのセキュリティに絡む課題として、12月の勉強会の時に参加者およびベンダーとディスカッションした内容に基づいて、以下の5点を上げた:

  • 経営陣の理解が乏しい懸念がある
  • 経営陣を説き伏せる対応が多岐にわたるため、それらへの対策を議論するが場ない
  • IoTのセキュリティについての活動を行っている他のNPO法人との協調
  • IoTの「プラットフォーム」としてのセキュリティの必要性
  • 開発・運用環境を含めて、エッジ及びクラウドのセキュリティの必要性

また、IoTのセキュリティに対する国内の政策としてIoT推進コンソーシアムがあり、官民が連携して様々な活動を行っている。IoT推進コンソーシアムは、海外との連携も進めている。しかしながら、IoT推進コンソーシアムは開発ガイドラインの策定が主な目標であり、上記の課題にある開発・運用環境、プラットフォームとしてのセキュリティには踏み込めていないという印象がある。
IoTに関する国際標準は、ISO/IEC15408として進められている。この標準は、セキュリティ製品(ハード/ソフトウェア)およびシステムの開発や製造、運用などに関する国際標準であり、情報セキュリティ評価基準(ITSEC, Common Critria等)の考え方で進められている。

このような状況を受けて、笠松氏からIoTに絡む5つの課題が説明され、今後検討しなければいけない点として上げられた。これについては、以下の笠松氏のスライドを参照していただきたい。

さて、以上の説明に基づいて、スピーカーから提示された上記の課題に対して参加者からの質問および議論が行われた。

  1.  IoTに関するIPAの取り組みについて議論となった。
    IPAでは、セキュリティとセイフティーの融合の観点から、実証検証、ケーススタディー等を通してリスクアセスメントに取り組んでいる。いわゆるSecurity-by-Designに基づくSTAMPモデルにより、システムの安全性に関するモデル化および分析方法を進めている。基本的には、開発者および利用者向けの取り組みになる。したがって、IoTの運用に関するセキュリティの課題は残ったままである。特に、IoT環境においてエッジコンピューティングとしてスマートフォンが使われるケースが増えてきている。この課題は、誰でも容易に使える反面、多くのIoTがパスワードも含めデフォルト設定のまま出荷されている点、データオーナの許可なく通信傍受が容易である点などが問題となっている。また、2016年米国FBIが個人宅で殺人事件があった際、スマートスピーカを押収した事例は、音声のオーナは誰か、スマートスピーカのオーナは誰か、スマートススピーカ(仮に音声型IoTとする)の音声データに証拠能力があるのか、など運用時のルールが不明のまま市場から受け入れられていく社会的環境が容認される点、などが重大な課題ではないか。
  2. 国境を越えるデータ流通について
    eSIM(電子的に書き換え可能なSIM)がIoT基板PCBに半田付けされている製品が出回りだしている点は、パーマネントローミング規制をEUで制定すみだが、日本国内の運用・使用ルールは見当たらない。顔認証が実用段階となった現在、このようなIoT機器のデータ流通を運用する議論の場が、CSAにあっても良いのでは。
  3. RPAの導入がセキュリティに与える影響について議論となった。
    RPAが行ったことで問題が発生した場合どうなるのかということである。RPAの利用にあたっては、監査ログが必須なるが、そもそも捜査の範囲を明確にしないと監査自体が検証可能にならないという問題になる。そうすると、RPAになんでもかんでもやらせるということでは無く、行う操作自体を明確にして、後で検証できることが重要になる。できるだけ業務を絞り込んで、監査しやすくするということが重要になるということである。という議論をしていくうちに、そもそもRPAはIoTなのかという話しになり、様々なモノをIoTでひとくくりに見ていくこと自体が無理ではないかという話しになった。モノの種類、特性ごとに個別に考えていく必要があり、RPAはRPAとして考えていかなければならないということになった。
  4. ビルや橋に埋められた100年IoT
    この部分については時間の関係で、パワポ記載内容を読み上げるに留まった。
  5. サーバレス
    この部分については時間の関係で、パワポ記載内容を読み上げるに留まった。

以上のような議論のもと、今後CSAとしてどのように取り組んでいくかという話しになった。IoTの運用面のセキュリティの課題をどうするかということは、結局どのようにガバナンスを利かすかという問題になるということになった。RPA等、新しい技術に対してどのようにガバナンスを利かすか、GRCをどのようにしていくかについて、テーマを決めながら議論していくことが大切であり、CSAとしてワークショップを開きながら議論していくことが必要ということになった。

 

以上

 

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

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

20178月30
CSAジャパン 諸角昌宏

 8回クラウド利用者会議では、CSAジャパンのCASBワーキンググループ(CASB WG)から、上田氏、露木氏、高岡氏にご講演いただいた。会議は、823()に開催し、クラウド利用者を中心として8名に参加いただいた。
今回は、「CASBはクラウドセキュリティを救えるか」というテーマで、CASBの事例を中心に講演していただくとともに議論を行った。

 まず、マクニカネットワークスの上田氏からCASBのおさらいということで、概要の説明を行っていただいた。

最初に、CASBの基本である4つの柱(可視性、コンプライアンス、データ保護、脅威からの防御)について説明していただいた。また、ガートナーが、CASBがクラウド環境におけるセキュリティ・ソリューションを補完していく可能性があるということで、SWG, SIEM, 暗号化, IDaaS, DLP, EMM, WAM, NGFWなどが挙げられていた。しかしながら、ガートナーも認めているように、実際にはこれらの融合はあまり進んでおらず、CASBは独立した製品として維持されているようである。なお、ガートナーは、2018年までに60%の企業がCASBを導入すると言っており、これは変わっていないようである。
CASBの日本国内での認知度も確実に上がっているということで、実際の導入が進んでいるということが説明された。CASBの導入に当たっては、Top Downのアプローチが多いとのことである。

 次に、SkyHigh Networksの露木氏より、主な導入事例の説明が行われた。SkyHighでは、現在、日本において23社の顧客、世界的には650社で導入されているということで、CASBが確実に導入が進んでいるということを裏付けるデータとなっている。

最初の事例として、55,000人の製造業における「大規模シャドーIT対策」が紹介された。この会社では、クラウドアクセスポリシーを作成する(既存のものはあったが、可視化が欠如していた)ために、より実用にあった形にすることが求められていた。ポリシーの作成にコンサルティングファームを利用すると、非常に高価になる。また、シャドーITをいきなり止めることは、企業においては大問題になる可能性がある。いわゆる、止めてしまう危険というものも考慮して行う必要があった。CASBを使うことで、この要件を満たしたクラウドセキュリティポリシーの作成および実際の運用が可能になったとのことでした。

その他の例として、BOXの管理、特に監査目的として導入したケース(ある部門がBOXを使用していたため、会社として全体的な監査のために導入)、Office365をすべてクラウド化した場合に、CASBで監視を行うことで、全世界のOffice365を見ることができるようになったケース、SalesForceに保存されたデータをCASBで暗号化するケースなどの紹介が行われた。

 最後に、シマンテックの高岡氏より、CASBの潜在するターゲットとして、以下の4点が挙げられた。ちなみに、シマンテックでは、米国におけるCASBのビジネスとして、昨年度900%の成長があったということで、非常に大きなポテンシャルのあるマーケットとみているとのことであった。

  • 2つ以上のクラウドサービスを正式に採用している企業。これは、CASBで一意のセキュリティレイヤーを作ることができるというメリットがある
  • クラウドアプリの正式な利活用を検討している企業
  • オフィス外でのクラウド活用(在宅、モバイル)
  • GDPR。データの棚卸と継続的なクラウド活用。特に、シャドーITによるGDPR違反を防いでいく。

また、CASBをニーズの観点から見ていくと以下の3点が考えられるとのことであった。

  • 業務アプリのセキュリティ管理としてのシャドーITの可視化。
  • インライン型に対して、業務用SaaSに対する対策としてAPI型の利用。
  • SOCとの協調等の包括的な管理として、自社運用ではなくMSSP的な利用。

最後に、CASBへの期待値として、以下の5点を挙げている。

  • 機密情報の自動認識
  • データ共有先の記録
  • シャドーなユーザ、怪しいアカウントの調査
  • クラウドアプリの利用状況の監査
  • 個人アカウントやBYOD端末に対する制御

 さて、以上の説明に基づいて、参加者からの質問および議論が行われた。

まず、CASBが行うクラウドのリスク評価について、どのように判断すべきかということが議論になった。CASB製品では、クラウドサービスに対するリスク評価を行い、安全なサービスなのか、あるいはそうでもないサービスなのかについて、利用者が判断できるようになっている。ただし、リスクをどう判断してクラウドサービスを使っていくかは、利用者の判断となる。リスクの各項目に基づいて判断するのか、あるいは、総合点で判断するかは、あくまで利用者次第ということになる。これは、第1回クラウド利用者会議で議論された内容と重なるが、CASBによるリスクの透明性に対して、利用者がどのように判断するかという、利用者のリテラシが求められるところである。CASBのリスク評価は、非常に頻繁に更新されており、通常は毎日行われる。事業者からの回答が必要なものでも、最低でも3か月に1回は更新されているとのことである。日本のサービスについても、以前はなかなか回答が得られなかったが、最近はほとんど回答が返ってくる状況となっており、リスク評価については十分信頼できるものと考えられる。

次に、GDPRCASBについての質問が出た。GDPRで我々が非常に影響を受ける域外移転に関しては、CASBで管理できるわけではないが、域外移転データの管理に関して、CASBを監査に利用できるということである。

それから、上記で紹介された事例等を見ていくと、CASBの導入は大企業に限られているのではないかということで、CASBを中小企業が積極的に利用できるようにするにはどうしたらよいかという議論になった。CASBというと、どうしてもコストの問題があり、中小企業が導入するのは厳しいということである。これについては、CASBとしての展開というよりは、中小企業向け支援サービスという展開が始まりつつあるということであった。キャリア系が進め始めている CASB as a Service により、中小企業でもCASBが利用できる道が開かれていく可能性があるということであった。

 以上のような会議となったが、CASBがクラウドセキュリティを守っていくソリューションとして、これから大きく伸びていくというのは間違いないようで、特に、クラウドアクセスポリシーの作成の観点からは、CASBが非常に強力なツールとなっていくようである。クラウドの利用については、もはや「セキュリティが不安なので導入には慎重」という時代ではなく、「クラウドを利用することを前提にセキュリティ対策を考える」という時代になっている。その中で、セキュリティを統一的に管理できる、まさにブローカーとしてのCASBは、重要な役割を担っていくということを強く感じた。今回、日本のCASBを代表する方々のお話が聞け、また、直接議論することができたことは非常に有意義であった。また、これからのCASB WGのアウトプットにも期待していきたい。

 

以上

 

 

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

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

2017年7月12日
CSAジャパン 諸角昌宏

第7回クラウド利用者会議では、BSIジャパン株式会社の中村良和氏に講演していただいた。会議は、6月27日(火)に開催し、クラウド利用者を中心として14名に参加いただいた。
今回は、「クラウドセキュリティに対する日本の認証規格」について講演していただくとともに議論を行った。

中村氏から、まず、日本の認証規格の状況について説明していただいた。

クラウドセキュリティに関する認証規格は、日本では以下の2つが展開されている。

  • ISO/IEC 27018
    27018は、パブリッククラウドにおけるプライバシのガイドラインを提供している。本規格の認証については認定機関が認証機関を認定するスキームは無く、認証機関が独自に認証サービスを提供する形しかない。認証スキームとしては、規格の適用範囲にもあるようにあくまでパブリッククラウドが対象であり、プライベートクラウドは対象とならない。また、PIIのProcessor(基本的にはプロバイダ)が対象であり、Controllerは対象にならないという規格の適用範囲となる。
  • ISO/IEC 27017
    27017は、以下の2つ構成を提供している:

    • 27002の実践規範に対する追加/拡張の管理策 27002の実践規範ではクラウド固有の要素が不足しているため、クラウド固有の要素を追加したものになっている。この際には27002も考慮した考えが必要となる。
    • クラウド独自の追加管理策(附属書A)
      27002の実践規範の項目では不足している、クラウド独自の管理策についてCLDと言う形でさらに追加の実践規範を設定している。ただし27017の本文の位置づけと同様である。

また、認証制度として以下の2つの注意点がある。

  • 認証制度
    他のクラウドを利用し、自社のクラウドサービスを提供しているクラウドサービスプロバイダーは、CSC(カスタマ)とCSP(プロバイダ)の両方の立場で見る必要がある(サプライチェーンを構成している可能性)。認証範囲はISO27001の認証している範囲内である必要があるため、クラウドサービスの提供が範囲外の場合はISO27001の適用範囲を拡大しなければならない。またISO27017の追加の管理策は原則除外ができない。
    注意点: SIerの存在で、SIer的に動いている(カスタマのクラウド環境を構築している)が、クラウドサービス自体を提供していない場合には、CSPとして認証を取ることはできない。
  • 審査員の力量
    ISMS審査員がクラウドセキュリティの審査員になるためには、追加でクラウド基盤・要素技術などの力量が必要になる。

さて、中村氏の説明の後、いつものように参加者によるディスカッションが行われた。

まず、カスタマが要求したことに対して、プロバイダは情報を提供するのか、という点が議論になった。情報の提供を契約にしておくことが望ましいが、プロバイダが個別に契約することを行わないケースもある。しかしながら、現状では、ほとんどのプロバイダが情報を提供している。たとえば、AWSでは、セキュリティ管理策について詳細に書かれた「ホワイトペーパーのどこどこの記述を見てください」というレベルの回答は必ず返ってくるようである。また、少なくとも27017に基づくクラウドセキュリティ認証を取っているプロバイダであれば、情報を提供しなければならないことになる(開示レベルは組織によって違うと想定される)。したがって、カスタマ側のリスク管理上必要となる情報はプロバイダから何らかの形で提供されると思ってよさそうである。もちろん、27017で言っているように、プロバイダが情報を出さない、あるいは、プロバイダの管理策が不十分である場合には、カスタマが追加の管理策を行わなければならないという大原則があることは理解した上で進める必要がある。

次に、27017では、対象となるのがパブリッククラウドなのかプライベートクラウドなのかが明記されていない点に議論が移った。プライベートクラウドの場合には、27017の管理策の大部分が不要になるのではないかということである。たとえば、オンプレのプライベートクラウドを考えた場合、論理境界に絡むセキュリティ対策は基本的に要らなくなるのではないかという点である。ISMS自体は、もともとオンプレを前提としているという意見もあった。そのため、クラウドに移行した場合、ユーザがコントロールできる範囲がどこまでか、また、それを超えた場合の管理をどうするかを定めたのが27017であると考えるとしっくりくる。したがって、パブリッククラウド/プライベートクラウドの利用における現実に即した管理ということをベースに考える必要がある。

また、27017の使い勝手はどうなのかということも議論された。ISMS上は、リスク管理に基づいて作成した管理策に対して、27017(27002を含む)の管理策と照らし合わせた時にギャップが存在しないかどうかを確認するというのが手順になる。しかしながら、逆に、27017をベースにして管理策を作成し、後は気になるところだけ検討していくという方が合理的ではないかという意見が出た。これについては、そもそもの認証に対する考え方の問題であり、認証を受けるという観点からするとそうなるかもしれないが、リスク管理の観点からは、まず管理策を策定するというのが必要になるということになった。27017自体は良いフレームワークとして使うことが望ましいということである。

それから、クラウド環境でのデータ削除に関する議論も行われた。プロバイダは、データにアクセスできないようにすることで削除したと判断する(判断するしかない)が、これで本当に安全な削除と言えるのかどうかという点である。そもそもオンプレでの仮想化環境ではデータが安全に削除されたかどうかを気にすることは無いのに、クラウドではなぜリスクになるのかという意見が出た。カスタマは、プロバイダのデータ削除が不十分であれば、独自に削除方法を検討するというのが基本スタンスであり、これに基づいてプロバイダを評価するのが必要という議論の結論となった。

最後に、プロバイダの管理策を実証するにはどうすればよいのかという議論になった。プロバイダを直接監査することは難しいため、プロバイダが提供する情報をもとに判断することになるが、そもそもプロバイダが提供する情報として何が必要なのだろうかというである。監査に基づく証明書では不十分であり、なんらかの報告書(アセスメントレポート)が必要になるということになった。AWSでは、SOCのレポートも開示されており、これが報告書として使えるのではないかということになった。

以上のように、クラウドセキュリティ認証というものに対して、様々な観点から議論を進めることができた。また、文章では表せない(筆者の能力は別として)ところでの議論も活発に行われたため、非常に中身の濃い会議となった。

以上

 

AWSのセキュリティ強化機能およびJAWSのセキュリティ部会の活動 ~ 第6回クラウド利用者会議

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

2017年4月27日
CSAジャパン 諸角昌宏

第6回クラウド利用者会議では、トレンドマイクロ株式会社の南原正樹氏に講演していただいた。会議は、4月17日(月)に開催し、クラウド利用者を中心として15名に参加いただいた。

今回は、AWSのセキュリティ強化機能およびJAWSのセキュリティ部会の活動について講演していただくとともに議論を行った。

南原氏から、まず、AWSのセキュリティ強化機能について説明していただいた。AWSでは、セキュリティを以下の3つの範囲に分類している。

  • AWSが責任を持つ範囲
    AWSでは、物理、論理(ハイパバイザ、ゲストOS)、また、ネットワーク(DDoS,中間者攻撃、なりすまし、盗聴、ポートスキャン等に対応)に対するセキュリティを提供している。また、法律や規則への対応、ログ管理なども提供している。
  • AWS以外のサービスを利用する範囲
    これは、IR, Forensics,セキュリティ診断、AV, IPS/IDS, WAFなどで、他社が提供している製品やソリューションを使用するケースである。
  • AWS機能を使用してユーザがセキュリティを保つ範囲
    これは、AWSが提供しているアクセス管理、暗号化WAF, DDoS対応などである。また、AWSの各セキュリティのサービスにはAPIも提供され、そのAPIを通じたセキュリティ対策を行えるようになっている。

AWSでは、ユーザからのフィードバックおよび要求に基づいて、セキュリティ機能を提供することを進めている。以前のクラウド利用者会議でも触れられていた「セキュリティをソフトウエアで解決する」ということに着実に向かっているようである。
また、AWSの提供するセキュリティ機能は、機能は提供しているが設定等は独自に行うことが必要なようである。たとえば、WAFを提供しているが、ルールの作成&カスタマイズを行わないと、そのまま使いづらい側面がある。

次に、南原氏よりJAWSユーザグループの説明が行われた。JAWSユーザグループは、基本的にコミュニティ活動であり、どのようにしてファンを増やしていくかということに貢献していくとのことである。その中で、Security-JAWSでは、講師を招いての勉強会を基本的に4半期に1回開催するようにしており、今までに4回開催している。また、過去の取り組みの中では、海外のAWSの講師をお招きして、Encryptionの話をしていただいた。 「みんなで勉強していこう」という考えの下に、AWSのサービスを深堀できるように、集まって情報交換を行っている。

さて、南原氏の説明の後、いつものように参加者によるディスカッションが行われた。

まず、AWSにおける法規制の扱いについて議論が行われた。ちょうど、4月7日に「AWSのリセラーとの契約において、準拠法を日本法、管轄裁判所を東京地方裁判所への変更を可能とした」というニュースもあり、この考え方について参加者より説明が行われた。これは、AWSは、準拠法として米国の管轄裁判所でおこなっていたが、今後は契約法に基づき管轄裁判所は所定の場所(日本でも可能)でできることになるとのことである。ただし、契約法であるため、誰がAWSにアカウントを持っているか(リセラー、カスタマ)によるようである。SIerがアカウントを持つ場合には、管轄裁判所を変更可能である。
議論の中で、そもそも何を争うのかというのが話題となった。AWSでは、停止時間に対するペナルティー等、SLAで細かく定められているため、ビジネス要件を争う余地はなさそうである。論点はかなり絞られてくると思われる。したがって、日本のリセラーにとっては、今回の準拠法は、あくまで保険みたいなものであろうということになった。

次に、Security-JAWSに議論が移った。上記で触れたように、コミュニティ的な活動を通してAWSのサービスを深堀していくことが行われている。AWSの機能・利用方法等を幅広く情報交換することでファンを増やしていくという、非常に有意義な活動となっている。 議論の中で、AWSのCompliance Quick Startの話になり、ポリシー、監査などがこのサービスを使用して簡単にできたり、ポリシーのテンプレート化のサービスなど、クラウド上でのコンプライアンス対応には非常に有意義であることが紹介された。

最後に、AWS、特にセキュリティ対応について、SIerが必須かどうかということが議論となった。AWSのセキュリティサービスは、Security-by-Designについてはよくできているが、WAFの件で触れたように、カスタマが独自に行うには難しい面があるようである。サードパーティーとの連携によるサービス提供ということが、今後も必要になってくるということであった。

以上

 

今後のクラウドの動向 ~ 第5回クラウド利用者会議

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

2017222
CSAジャパン 諸角昌宏

 5回クラウド利用者会議では、株式会社BCN週刊BCN編集長の畔上文昭氏に講演していただいた。会議は、210()に開催し、クラウド利用者を中心として10名に参加いただいた。ここでは、会議の概要について記述する。
今回は、今までのクラウド利用者会議とはちょっと趣を変え、今後のクラウドの動向に対して、どのように取り組んでいくのかという点を中心に議論を行った。 

まず、畔上氏から、IoTとクラウドの親和性の高さについて説明された。IoTと言えばクラウドということで、以下の5つの理由からIoTではクラウドが必要になっているとのことである:

  • データ量が読めない
  • 拡張性を確保したい
  • 素早く展開したい(特に、グローバルに)
  • チャレンジ領域のインフラとして有効
  • ダメなら撤退が容易

また、IoTとクラウドにより、地方の活性化が図れるとのことである。地方には工場が多く、IoT -> クラウド -> ビッグデータという流れで、地方において有効活用されていくとのことである。

さて、2017年のクラウドマーケットの動向(特にIaaS/PaaS)であるが、まず海外ベンダーの動向というか方向性について以下のようにまとめている。

  • AWS: エンタープライズのクラウド化に関する議論はもはや終了。多くの基幹システムがAWS上で稼働している(SAP HANAのように)状況で、「エンタプライズごとクラウド」という流れを作っている。
  • Azure: デジタルトランスフォーメーションがクラウドの存在を高めるという観点から、企業のデジタル化を推進している。IoTAIで存在感を示している。
  • IBM: コグニティブとクラウドの会社というイメージを作っている。Watsonを始めとする付加価値が大きな競争力となっている。「クラウドネイティブ」でない一般企業の需要に応えるようにしている。
  • Google: ビッグデータ解析、マシンラーニングで差別化を図っている。
  • Oracle: オンプレでのSI技術をそのまま生かせるクラウドということで、価格勝負に向かっている。しかしながら、Oracle自身の中でのクラウド率が低く(グローバルで10%)、なかなか難しい状況となっている。

以上のような状況であるが、AWSAzure2強の状況は崩せないだろうというのが一般的な見方となっている。 

次にAIとクラウドについてであるが、今後AIerというAIをビジネス化するSIerが生まれ、ITのゴールがAIという時代になる。その時、クラウドがAIエンジンを提供する時代になる。また、IoTとクラウドのAI活用が進み、「エンタープライズAIoT」というのが実現される時代になるようである。そのような状況で、AIとクラウドについて考えると、SaaSが面白いということになる。SaaSベンダーは、すでに(これからも)大量のデータを持っており、これをAIに活用することでSaaS自体を便利にしていくことができる。SalesforceEinsteinは、SalesForce自体を使いやすくすることに貢献している。したがって、パッケージベンダーは、SaaSに行かないと乗り遅れることが予測される。

また、RPARobotic Process Automation)のお話があった。いわゆるAIが「人間の代わりになるロボット」を求めているのに対して、RPAは「人の代わりに働くロボット」を作っていくものである。既存のシステムには手を加えずに、操作する人間をロボット化していく。既存のシステムを使うことで、AI化する必要がないし、操作する人間をロボット化することで、いわゆる「自動運転」というものはいらなくなる。人の代わりにロボットが動くことで、人的なエラーがなくなるとともに、圧倒的な速さで処理を行うことができるようになる。 

最後にまとめとして、以下の5点を挙げた。

  • IaaS/PaaSは、各社の戦略が明確化されてきた
  • クラウド2強時代が続く
  • AIoTが実用段階に入ってきた
  • AIoTとのコラボが注目されるRPA
  • 人ロ知能(2つ目の文字は、「くち」ではなく「カタカナのロ」)が来るかも。

クラウドは、単なる基盤の置き換えではなく、新しいITの領域へのデジタルトランスフォーメーションを導くものであるということを、改めて強調された。

さて、畔上氏の講演に続いて会議での議論となった点について以下に記述する。 

まず、クラウド2強時代やIaaS/PaaS各社の戦略の明確化を受けて、国産クラウドが今後どうなっていくのかという点について議論が行われた。結論としては、国産クラウドが、IaaS/PaaS市場で勝負するというのは考えられないということであった。その状況で、国産クラウドがどのようにビジネスを組み立てていくかというと、それはSaaS市場ということになる。国産クラウドとしては、①自社でクラウドインフラも持ちその上にサービスを展開していくか、②AWS/Azure等のクラウドインフラを使ってその上にサービスを提供するか、というどちらかでSaaSビジネスを拡大していく方向に向かっていく。

また、クラウド2強のように欧米のクラウドに依存してしまうことに対するリスクの議論も行われた。ビジネスリスクはある程度やむを得ないとしても、カントリーリスクをどうするのかが問題となる。たとえば、米国の法律に縛られてくる可能性や安全保障上のリスクをどうするかなど、日本として考えていかなければいけない課題が多いということになった。国策を取る必要があるかどうかも含めて、考えなければいけない内容となった。

カントリーリスクという点で、IPAが始めた産業サイバーリスクセンターの議論になった。ここでは、サイバー攻撃を防ぐ人材育成のための新組織を立ち上げ、そのアドバイザーに米国家安全保障局(NSA)のアレキサンダー元局長を迎えた。セキュリティ技術者の養成として、非常に注目される活動である。人材育成と合わせて、武器となるべく国産クラウドや国産セキュリティベンダー等の整備をどうするかも合わせて進めていく必要があるということである。

以上

 

セールスフォース、SaaS/PaaSセキュリティ ~ 第4回クラウド利用者会議 

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

201612月25
CSAジャパン 諸角昌宏

4回クラウド利用者会議は、セールスフォースから高橋悟史氏、成田泰彦氏に講演していただいた。会議は、1215()に開催し、クラウド利用者を中心として10名に参加いただいた。ここでは、会議の概要について記述する。

セールスフォースからは、SaaSIaaSの違いを中心に説明していただいた。まず、最も重要視しているのがTRUSTということで、実績として今まで一度も情報漏えいやハッカーの侵入を許していないということが挙げられた。信頼というのをどのように見せるかは非常に難しい問題であるが、実績もさることながらセールスフォースのセキュリティに対する取り組みをみると明白であるということができる。また、この大企業レベルで信頼されるシステムをそのまま一般にも提供できているということで、すべての利用者に同じレベルの信頼を与えることができるというクラウドの優位性を示している。このセキュリティを支えているのが、セキュリティ対策に対する技術面への投資だけでなく、人間系への投資、つまりセキュリティの専門家への投資を積極的に進めているということである。これは、単純に専門家の数を増やすということではない。セキュリティの専門家として本当に必要となるスキル、また、開発者に対するセキュリティのトレーニング等をきちんと実施している。

さて、IaaSとの違いという点からセールスフォースを見てみる。

まず、1個のデータベースにすべての顧客データを保存している、いわゆるマルチテナントDBという形を取っている。これを個別のデータベースと比較すると、まず重要なのが、個別DBの場合には管理者が多数必要になるという点である。セキュリティの対応を一人の人間が多く持つようになるとそれだけリスクが増大するし、管理者による違反の可能性も高まってくる。マルチテナントDBでは、物理境界ではなく論理境界をどのように守るかという点が問題となるが、技術的な対策と合わせて人的な対策としての職務の分離(データの操作者とDB管理者の分離など)をおこない、論理境界を技術的/人的の両面からサポートしているということである。なお、これらのセキュリティ対策はアプリケーションサーバ側で対応しており、ユーザのIDとオブジェクトのIDがアプリケーションでしか分からないしくみを取っている。これにより、管理者に対してデータを隠ぺいすることが可能になっている。アプリケーションサーバ側で様々な対応を行うということは、データベースに対するベンダーロックインを回避するという点からも重要であり、ビッグデータ等で使われている様々なデータベースへの対応という観点からも重要になってくる。

次にソフトウエアの観点から見ると、単一ソフトウエア、単一バージョンの本番システムを実現している。常に最新の1つのバージョンのみを提供することで、信頼性および高いセキュリティを提供している。また、システムの状況をホームページですべて公開している。これにより、透明性および稼働性を実現している。監査に関しては、年2回の第三者監査を、立ち入り監査を含めて実施している。また、脆弱性診断を年4回実施しており、かつ、都度、診断に使う業者を変更して行っている。これらの観点から、ソフトウエア/サービスおよびシステムの信頼を提供している。

さて、このようなセールスフォースの信頼に対する取り組みを受けて、利用者とのディスカッションについて以下に述べる。

まず、セールスフォースが信頼性の高いシステムであること、また、高いセキュリティを保っていることは明らかであるが、そのような状況において「利用者側のリスク」というものが何になるかということである。これについては、クライアントのセキュリティはセールスフォースでは対応できないので、利用者側できちんと管理する必要があるということになる。特に、クライアントの乗っ取りについては十分な対策を取る必要がある。

次に、AWSとの連携の話についてのディスカッションになった。セールスフォースは、もともとインフラを自前で提供している。自前で提供することで、サプライチェーンに頼らず独自にセキュリティを維持できるという強みを持っていた。その状況でAWSと連携するようにした理由は、あくまでデータセンターとしてのスピードとコストのためであるとのことであった。特に、IoT、ビッグデータ、AIのように大容量のデータを扱うものについては、AWSのスケーラビリティが必要になってくる。また、セールスフォースが提供する新しいサービスが、もともとAWSで作られているような場合には、そのまま提供するとのことである。そうすると、AWSを使った場合のセキュリティ対策をどうするかということになる。一般的に、IaaSのセキュリティ対策は利用者側の作りこみが求められる。例えば、すでにAWS上でサービスを提供しているファイルフォースでは、暗号化等を含めて独自に実装しているということである。セールスフォースでも、現段階ではAWSのセキュリティサービス機能は使用せずに独自に作りこんでいるということである。今後、どのような形でAWSのセキュリティサービスが利用されていくのかは興味深い点である。

最後に、マイナンバーに対するセールスフォースの対応についてディスカッションとなった。マイナンバーについては、セールスフォースとしては法律の要件を満たすことはできないということを明確にしている。パートナー(PaaS上にアプリを構築している)と利用者の間の契約として、マイナンバーへの対応をどうするかを考えなければならない。クラウドプロバイダとしては対応しきれない日本国内の問題ということになる。これは、前回のクラウド利用者会議で問題となった、EUの個人データをクラウド内で自由に移動できる(セールスフォース、AWSAzureが可能)にもかかわらず、日本国内で保存や検索を行うことができないという点があったように、グローバルに展開しているクラウドに対する日本の問題として見ていく必要がある。

セキュリティに関しては最先端を行くセールスフォースということで、非常に明快な説明をいただき、また、分かりやすいディスカッションを行うことができた。非常に高いセキュリティレベルを維持しながら、セキュリティに関わる人間の数はそれほど多くない(具体的な数字は出ていない)ということで、セキュリティ面でのクラウドの優位性というのを改めて感じることができた。

以上