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

 

 

 

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の件で触れたように、カスタマが独自に行うには難しい面があるようである。サードパーティーとの連携によるサービス提供ということが、今後も必要になってくるということであった。

以上