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

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が可能)にもかかわらず、日本国内で保存や検索を行うことができないという点があったように、グローバルに展開しているクラウドに対する日本の問題として見ていく必要がある。

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

以上

 

AWS導入事例からみるクラウドの利用方法 ~ 第3回クラウド利用者会議

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

2016年11月15日
CSAジャパン 諸角昌宏

第3回クラウド利用者会議は、「AWSクラウドの進化と真価 ~クラウド利用の新しい段階~」というテーマで、渥美俊英氏に講演していただいた。会議は、9月30日(金)に開催し、クラウド利用者を中心として12名に参加いただいた。ここでは、会議の概要について記述する。

渥美氏からは、以下の3点について説明していただいた:

  1. AWSのエンタープライズ拡大と効果 - 組織・開発の在り方の変化
    AWSは、日本において20,000ユーザ、世界で100万以上のユーザを抱えている、文字通り世界のIaaS市場のリーダーである。AWSの機能は年々拡張されており、今では提供するサービスの数は70を超えている。その中で、特徴的なのは、新たに提供された機能のおよそ1/4がいわゆるセキュリティ機能で、コンプライアンス、統制、監査が含まれている点である。
    機能拡張は、基本的に利用者からの要望に基づいてAWSが自ら考えて社内実装している。これまでの他のITベンダは、事業拡大に際して買収合併を通じて新しい製品や機能を追加することが少なくない。このため必ずしも首尾一貫した製品体系でなかったり、利用者にとっては不必要な機能過多で、価格がより高額になることが現実に多い。この点、AWSの姿勢は大きく異なり、利用者が必要な機能について優先的に基本機能を早期に提供し、細かな機能は利用者からのフィードバックから次々と機能を追加し完成度の高い製品に仕上げてゆく。これを実現できるのは少数精鋭(2枚のピザを共に食べられる程度の小さなチーム)の社内開発チーム組織による。そして、このAWS自身の高速な開発を支える仕組み、開発・配備・運用のIT基盤自体も新しいサービスとして次々と提供している。利用者はこれらの様々な機能を使い自らの開発の仕方も変えてゆく段階に入っている。
    今年6月に開催されたAWSサミットでは、国内の大手企業による事例やクラウドの取組みを語る講演において、AWSは単なるIaaSとしてではなく、自社の開発やビジネスの在り方、社内組織の在り方、SIerとの付き合い方を変えてゆく段階にはいっていることが数々と語られた。
  2. AWSのセキュリティ - コンプライアンスの進化
    顧客の要求に対しては高額な対価で個別に対応するのが今までの多くのITベンダーのビジネスのやり方であった。これらは、エンジニアやコンサルタントの人手をかけた人間的な対応ということで行われていることが多い。これに対して、AWSでは、あらゆる顧客の要求というものに対して、自前でソフトウエアで対応しサービス化するという方法を取っている。これにより、重要顧客への個別対応ということではなく、すべての顧客に対して利用できるようにし、全く同じ機能をその他の顧客に対しても(個人であっても)同じプライスで提供している。金融機関や医療系、政府系などのセキュリティ、統制が厳しい利用者の要求を満たした同じサービスが、自分から要件を固めなくても安価に利用できる。小規模で資金の乏しいスタートアップ企業でも、グローバルの巨大企業と同じレベルのIT基盤サービスを利用できるわけで、これがいわゆる、ITの民主化というものを実現している。
    AWSのサービスは責任共有モデル(OSより上はユーザ責任で、仮想OS以下はAWSが責任を持つ)という考え方による。AWSにおけるセキュリティとコンプライアンスの対応は、この数年で以下のように進化してきている:

    ①   ISMS等の認証取得や業界ガイドラインへの準拠
    ②   Customer enabler docs(ホワイトペーパー等の様々な公開文書)
    ③   Customer case studies(利用者の事例と知見の共有)
    ④   Security by Design (設計にセキュリティを組み込む)

    上記の流れを説明すると次のようになる。最初は、ISMS等の認証を取得することで、安全かつ信頼できるプロバイダであることを示してきた。2番目のステージでは、その対策や管理策を文書の形で公開することで、顧客に対して透明性を保つようにした。これにより、顧客は自社のリスク管理に対して、クラウドを利用した場合のプロバイダのセキュリティ対策を判断できるようになる。さらに3番目のステージでは利用者の数々の事例が公開され、利用者側がセキュリティをどう考えてコントロールしているかなどの情報が共有される。個々の要件に対して人間系の個別対応ではなく共通のソフトウェアでサービス提供をしているので、他社の事例は具体的な実装の参考にし易い。 さて、このような流れの延長として次に進められているのが4番目のステージで、Security by Designという考え方である。これは、顧客が必要とするセキュリティ対策をAPIを用いてコントロールできるようにし、それをシステムの設計段階からアーキテクチャの中に組み込んでいくものである。AWSのインフラストラクチャーで共通の、アクセス管理、ログ記録、暗号化、鍵管理、監視、構成変更、アプリケーション配備等のサービスを組み合わせて、システム開発から運用監視、監査までも含めて一気通貫でコントロールすることが現実的なソリューションになりつつある。さらに人間系の設定ミスや考慮漏れを低減するサービスも高度化されてきている。たとえば、AWS Trusted Advisorサービスでは、利用者の現状のシステム構成や設定に関して、AWSのベストプラクティスの蓄積データから、コスト削減やセキュリティ上の警告、改善のアドバイスが人手を介さずにソフトウェアで自動的に開示される。また、Amazon Inspectorサービスでは、顧客毎にポリシーを設定し、それに反する設定はリアルタイムで通知がされる。これらは全てソフトウェアによるサービスのため、無料か、サポートに含まれるか、または極めて安価である。AWSはこのように様々なサービスを組み合わせることで、オンプレミスの代替えというIaaSの段階を越えて、システム開発から運用までを、安全に効率化、俊敏化する利用価値を持つものに進化している。今年12月に行われるAWS最大のイベント、re:Invent では毎年数多くの革新的なサービスが発表され、興味深い先進的なユーザ事例を聞くことができる。ここで新たに公開される情報に期待する。

  3. クラウドを取り巻くガイドライン、規制 - FISC安全対策基準、EUデータ保護
    AWSは、数多くの認証、国際標準や各国の業界ガイドラインを満たしてきているが、満たすだけではなくクラウド事業者の透明性として幅広くその情報を公開している(重要なものは日本語化されている)。例えば、クラウドセキュリティの統制に特化した第三者監査のSOC2対応については、利用者はNDAベースでAWSから監査レポートを取得することでセキュリティ対策についての情報を入手することができるようになっている。このように、セキュリティ監査の仕組みを取り入れて利用者に開示することで、「技術」+「監査/コンプライアンス」というAWSの保証プログラムが展開できている。 金融機関はクラウドから縁遠いと思われているが、既にソニー銀行、ジャパンネット銀行では業務システムでAWSを利用する事例が公開されており、また、今年のAWSサミットではMUFGの役員がパネル登壇してクラウドの必要性を語っている。金融機関のITシステムは、金融庁の外郭団体である金融情報システムセンター(FISC)が発行する「金融機関向け安全対策基準」を業界ガイドラインとしている。2012年のAWSサミットでは、このFISC安全対策基準にAWSが準拠しうる、というドキュメント一式がボランティアで作成され無償公開が発表された。その後、2015年の安全対策基準追補改訂においてクラウド利用の項目が追加され、AWSのようなデータセンターの訪問を認めないクラウドについて、金融機関がリスク管理する実践策の例としてSOC2監査レポートの活用が具体的に示された。このように金融業界においても金融機関が直面するグローバルな競争を鑑み、クラウド活用を推進する方向にある。
  4. また、プライバシーの観点からは、EUのデータ保護指令(2018年からデータ保護規則として施行)に対してAWSは個人データの国外移転に関してEUとの調整が完了している。これにより、AWSの利用者は一定の手続きで、EUで自社が管理する個人データをAWS上の各国のリージョンに移転が可能で、個人情報を一貫して扱うことができる(注:AWSだけでなく、マイクロソフト、セールスフォース等がこの調整を完了している)。しかしながら、日本でEUの個人情報を扱う場合には、AWSのクラウド上でデータを扱うことはできるが、日本国内の他のデータセンターにダウンロードしたりプリントしたりすることは、そのままではできないことに注意が必要である。そのほか、日本の個人情報保護法では個人データの国外移転に関してクラウド環境は念頭におかれていない。各国で定められている個人情報に関する規則のうち、日本の個人情報保護法はAWSをはじめとするグローバルなクラウド事業者との調整対象から外れているというのが現状である。

以上の渥美氏からの講演を受けて、参加者全員でディスカッションを行った。今回は、上記の講演中に突っ込んだ議論が行われたため、ディスカッションにあまり時間が割けなかった。その中で、ディスカッションの中心は、これだけ進化しているAWSを支えているAWSの文化という点になった。

まず、このように進化しているAWSを利用者側の企業が積極的に使っているのかどうかという点では、まず大局的な動向として、AWS、MSのクラウド事業は年40%以上拡大しており文字通り急成長している。この数年の利用者は先進的なユーザが多く、これからは必ずしも先進的ではないマジョリティユーザの比重が大きくなってくるため、現場では様々な考え方がでてくる。これらのユーザ企業では、社内的にAWSを積極的に利用していきたいという人とオンプレや従来の慣習にこだわる人がいて、なかなかAWSの採用に踏み切れないケースもあるということであった。AWSなのかオンプレなのか、何らかの評価方法があれば判断できるのかもしれないが、コスト比較の積み上げでも既存のデータセンターや組織維持のコストが過少になりがちであったり、適正な比較が難しいケースもある。さらに、日本では購買部署においてITベンダへの個別値引きを当然とする長年の慣習があるが、AWSでは個別値引きやパートナーの仕入れ価格という考え方は基本的に無く、定価そのものを誰に対しても共通に値下げをするというこれまでのITベンダに無い独特の考え方がある。これが理解できないと、現場部門では技術やサービス面で良い評価なのに購買規定や購買慣習で意外に手間取るケースもある。今後クラウド市場は伸びるが、CIOあるいはCISOが部長レベルである日本企業においては、企業としてAWSを採用するというような意思決定には、まだまだ様々な有形無形の抵抗要因があるようである。

一方、会議参加者の中から、クラウドプロバイダとしてAWSを採用しているファイルフォースは、その経緯について次のように説明している。IaaSを利用するにあたっていくつかのクラウドを評価した結果、AWSは他のクラウドに比べて価格は高い。しかしながら、複雑なECOシステムを構築するにあたっては、マネージドされたサービスが提供されているAWSが魅力であるということであった。クラウドをコスト削減の選択肢という観点だけで捉えるのでは不十分であり、総合的にプロバイダを評価することが重要であるとのことである。

それでは、この進化し続けるAWSを支えている要因はということであるが、以下のようなAWSの企業としての特徴によるものと考えられるということであった。

  • 徹底した顧客(エンドユーザ)志向。顧客志向という言葉はおよそどの企業でも掲げているが、従来のITベンダでは、ややもすると新製品や買収の投資回収のために、高価格、高付加価値、高機能スイート製品のまとめ買いの営業を重視することが現実だった。AWSは徹底して、低価格、ユーザが必要とする機能、革新的な製品を素早く提供することを重視し、組織もそれに特化している。
  • 従来のITビジネスの基本である仕入れ、仕切りの考え方が基本的に無い。エンドユーザもパートナーもAWS利用料は基本的に変わらない。「パートナーに与えるマージンやキックバックの余裕が少しでもあるなら、全てエンド向けの製品サービスの値下げをする」とAWSのトップは公言している。SIerの伝統的な経営には辛いスキームで、これゆえにSIer社内にはAWSビジネスへの抵抗や無関心も当然あるが、中期的にはSIerならではのソリューションに特化することが求められており、これは結局IT業界としてエンドユーザへの貢献となる。
  • AWSは従来のITベンダ(だけではないが)が常識としてきている営業接待にはコストをかけず、その余裕があれば値下げをする。前述の米国で開催されるre:Invent イベントへの日本からの参加(今年は500名以上)は、ユーザ企業もパートナー企業も開発者個人も基本的に自費である。AWS推進者の多くはAWSを追う強い熱意を持っており、このような意識の関係者がAWSを支えている。
  • AWSは他企業の買収は限られたケースだけで他のITベンダのような多数の関連買収を行わない。自前の開発にこだわっている。顧客の要望(XXに困っている、というレベルでもいい)、要件をソフトウエアでゼロから実装するため、出来上がったものの一貫性が保たれるとともに完成度も高くなる。
    AWSは顧客とのミーティングを重視している。特に米国本社のトップ、製品マネージャとのミーティングは、経営や製品開発への直接のインプットとして最大限重視している。但し、日本企業の幹部がやりがちな、いわゆる、”Say Hello”的な挨拶や面識作りだけの顧客訪問は時間の無駄として良しとされない。これは他のこれまでのITベンダの営業文化とは大きく異なる。顧客とAWSが、要望や要件をベースに真摯に話し合い、それをソフトウエアで実装していく。顧客も、エスカレーションや自分の意見を積極的に示す姿勢であることが期待されている。

これらは、AWSが持っている独特の文化、行動様式であり、これが続く限り、そう簡単に他社の追従を許すことはないだろうという結論になった。

最後に、これは時間が足りずに議論することができなかったのであるが、今後クラウド利用者会議で議論していきたい話題を1つあげる。それは、クラウドがセキュリティ人材の不足問題を解決するのではないかということである。セキュリティを、ソフトウエアおよびサービスで提供するAWSのアプローチは、提供されたセキュリティ機能を利用してセキュリティ対策を行うとともに、サービス化された仕組みを組み合わせて、自らのガバナンス、ポリシーを効率的に実現することができるようになる。しかも、グローバルで一貫しているので、企業の規模などにとらわれずにセキュリティ対策を取ることができるようになる。このクラウドにおけるセキュリティ対策により、有象無象なセキュリティ課題に対して一貫した対策を取ることができ、セキュリティ人材の不足をカバーすることができるのではないかと思われる。また本格的なクラウドの進展により、求められる人材像も変わってくる。これまでの個々のベンダー製品に関する製品固有の知識やコマンド操作ではなく、本来のセキュリティやネットワークの原理・原論の知識と応用、利用企業のビジネス要求の理解とコントロールのしっかりした考え方は、逆に極めて重要になってくる。さらに進んで、言われた通りのベンダー製品の導入運用監視をするだけのセキュリティ人材は、かつての電話交換手のように、いらなくなる時代が来るかもしれない。

クラウド、特にAWSのセキュリティの進化には、これからも注目していきたい。

以上

 

日本型クラウド利用について ~ 第2回クラウド利用者会議

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

2016年8月22日
CSAジャパン 諸角昌宏

第2回クラウド利用者会議は、クラウド事業者としてユニアデックス株式会社様をお招きし、クラウド利用者を中心とした11名にご参加いただき8月4日(木)に開催した。ここでは、会議の概要について記述する。

まず、ユニアデックス様が提供しているU-Cloud IaaSサービスについて説明していただいた。U-Cloud IaaSでは、所有と利用を適材適所で組み合わせた、 ハイブリッド型の企業情報システムを提供している。これにより、どうしてもクラウドを自社で所有したい場合とクラウドサービスを利用する場合との両方の要件を満たしている。また、U-Cloud IaaSを特徴づけているのは、マネージド型クラウドで、AWS等のセルフサービス型クラウドと比較して以下の特徴を持っている。

  • 運用監視、セキュリティなどをオプションで提供している
  • 障害対応など、クラウドサービスチェックリストに基づく実証報告を行い、サービスレベルを高めている

これにより、企業基幹システムをクラウド化する場合に求められる要件である、 高いサービスレベル、強固なセキュリティ、きめ細やかな 導入支援/運用サービスを提供することが可能になっている。そのほか、マネージド型とセルフサービス型の比較は以下を参照していただきたい(ユニアデックス様資料より引用)。

uniadex

さて、会議ではマネージド型クラウドに対する様々な質問が上がった。運用監視について、SEが要件を聞いた上で構築を行うということがクラウド環境で本当に必要なのかどうか、また、利用者はそこまで支援してもらえないとクラウドが使えないのかとういう問題提起がなされた。また、クラウドサービスチェックリストに基づく報告に意味があるのかどうか、特に各種ガイドラインで示されている内容で十分なのかどうかが議論された。たとえば、FISCのガイドラインを見ると、リスクの管理すべき項目をチェックしているが実装のレベルは求められていない。したがって、準拠しているかどうかの粒度は違ってくる。そもそも、準拠しているかどうかという質問自体がおかしく、○×ではなく内容の説明が必要である。利用者は、中身の精査を行うことが必要で、利用者の企業の基準に合っているかどうかをきちんと判断することが必要である。

さて、今回の会議で大きなポイントとなったのは、日本においてはマネージド型クラウドが必要なのかどうか、また、マネージド型クラウドでないと日本の利用者はクラウドを利用することが難しいのかどうかという点である。つまり、マネージド型クラウドが日本独自のクラウド利用形態なのかどうかということである。

グローバルにクラウドの導入を行っている企業では、導入時に、海外がイニシアティブをとっているところではセルフサービス型、日本がイニシアティブをとっているところはマネージド型となっているケースが多いようである。そのようなケースを考えると、海外ではセルフサービス型クラウドが利用され、日本ではマネージド型クラウドが利用されているのはなぜかという話になってくる。その一つの状況が、企業におけるITのリテラシである。海外においてはIT部門に所属する人の70%以上が技術に詳しいエンジニアであるが、日本の場合はおそらく20%以下であろう日本においては、80%以上が外注に出している状況である。このような状況で、セルフサービス型を使った自前の実装・管理は成り立たないと言わざるを得ない。(注:ここに出ている数値は、客観的に統計データとして出ている数字ではなく、あくまで会議参加者が把握あるいは推測している内容である)。。

また、不正競争防止法があり、経営秘密に対する安全管理処置が必要になる。クラウド業者の選定に当たっては、全体としての安全措置が確保されている必要があるため、委託先の守秘義務の整備、ファシリティ対策、不正アクセス対策等を行っていくことが必要になるため、どうしてもマネージド型が必要になってくる。また、日本でAWSを使っている場合でも、ほとんどパートナーが面倒を見ており、日本の利用者が裸でクラウドを使うことはありえないとのことである。

以上のような状況ではあるが、今後この状況が変わっていく動きもある。それは、ビジネスのスタートアップ企業が増えてきている中で、ITサービスをオンプレで賄うことができなくなってきているためである。また、既存の企業においても、スタートアップ企業との競争に勝っていくためにはIT投資を抑えるための取り組みとITリテラシの向上の取り組みが進んできているということである。これらが組み合わさって、海外の企業の考え方や利用の仕方が促進されてきている傾向が見られる。

一方、マネージド型クラウドのベースにあるSIerという考え方は、日本独自というわけではなく、インド、韓国等でもSIer文化が出来上がっているとのことである。マネージド型クラウドは、決して日本独自のクラウド利用形態ということではなく、セルフサービス型クラウドとマネージド型クラウドでそれぞれ利点を生かしつつ共存していくということが言えると思われる。

以上

 

「プロバイダの透明性と利用者のリスクアセスメント」 第1回クラウド利用者会議レポート

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

2016年8月11日
CSAジャパン 諸角昌宏

第1回クラウド利用者会議は、クラウド事業者としてNTTコミュニケーションズ様をお招きし、クラウド利用者を中心とした13名にご参加いただき開催した(2016年4月21日開催)。ここでは、会議の概要について記述する。

まず、NTTコミュニケーションズ様が提供しているIaaSサービスについて説明していただいた。IaaSとしての様々なサービスに加えて、NTTコミュニケーションズ様の強みとして印象に残ったのは以下の2点であった。

  1. 日本発グローバルに展開
    日本にデータセンターを持つことを強みとするプロバイダが多い中、グローバルに展開、また、グローバルのデータセンターの面積が日本よりかなり大きい。
  2. 閉域ネットワークを利用したデータセンター間ネットワーク
    閉域ネットワークに基づいて、柔軟性およびセキュリティを考慮してグローバルのデータセンター間を閉域ネットワークで結んでいる。クラウド間通信の効率化および地点間のセキュリティを確保している。

さて、会議での議論は、レガシーアプリのクラウド化やそもそも何をクラウド化するかという観点から始まったが、プロバイダをどこまで信頼できるかという点に議論が移行し、最終的に主要な議論は、プロバイダの透明性と利用者のリスクアセスメントに絞られた。

  1. プロバイダの透明性
    クラウドを利用する場合に、セキュリティの責任範囲がどうなるかが問題になる。プロバイダの責任範囲は、最終的に約款に記述されている内容の範囲までとなるが、約款の内容とプロバイダの説明資料に食い違いがあったりするため、利用者が判断できないというのが現実である。プロバイダも、詳細にわたってセキュリティの責任範囲を説明しきれない。そのため最終的にはプロバイダが信頼できるかどうかで判断するしかない。
    一方、プロバイダの信頼性を判断するには、ほとんど情報が公開されていない。つまり、プロバイダの透明性が極端に低い状況では、利用者が判断するのは困難である。ここは、欧米と日本のプロバイダで大きな違いがある。欧米のプロバイダは、積極的に情報公開し、利用者がプロバイダのセキュリティレベルを判断できるようにしているが、日本のプロバイダは情報をほとんど公開しない。ちなみに、CSAのSTARレベル1では、プロバイダがCCM(Cloud Controls Matrix)あるいはCAIQ(CONSENSUS ASSESSMENTS INITIATIVE QUESTIONNAIRE)に従ってセルフアセスメントした結果を公開する場を提供している。ここの状況を見ると、グローバルでは80~100社が公開している(ただし、IaaSだけではなくSaaSプロバイダも含まれる)が、日本のプロバイダでここに情報公開しているところはない(ちなみに、CSAジャパンが仲介して日本語で公開できるサービスを提供している)。この日本のプロバイダの透明性の問題をクリアーしていくことが必要と思われる。
    なお、NTTコミュニケーションズでは、プロバイダ監査(立ち入り監査)を認めている。立ち入り監査を認めているプロバイダは欧米を含めても少ないので、透明性とは別の話になるが、非常に重要なことと考えられる。
  2. 利用者のリスクアセスメント
    仮にプロバイダが透明性をもって公開したとしても、利用者側でリスクアセスメントができていないと意味がない。利用者は、自分自身のリスクアセスメントをすべきで、欧米の企業はできているように思われる。たとえば、ドイツ系の企業では、情報源に対して質問票を送り回答を得る形でリスクアセスメントを行っている。最低限、情報公開はできているし、調査票ベースでノウハウもためている。また、リスクアセスメントは守るべき資産を重要度に応じて特定しレベル分けしていることがまず必要であるが、クラウドに移行する資産の分類をきちんと行っている日本の利用者は非常に少ないようである。
    このような状況で、仮にプロバイダが透明性の問題をクリアーしたとしても、利用者側が使えない(判断できない)ということになりかねない。
  3. プロバイダの透明性と利用者のリスクアセスメントを促進するには?
    まず、透明性の判断基準が必要で、どこまでの開示あるいは回答が必要なのかという標準的な基準が必要である。つまり、判断基準の標準ツール(ひな形)があれば、同じ基準で比較できるので、プロバイダも公開するようになり、透明性が高まるのではないか。利用者側は、自分自身のリスクアセスメントを進めるべきで、これはクラウドに限らずやっていかなければならない。コンプライアンスへの極端な依存から脱却すべきである。
    ただし、透明性とリスクアセスメントには、以下のような日本的な問題があることを理解しておく必要がある。

    • 透明性について
      透明性は記載が一杯書いてあるより、ルールを逸脱した結果の証跡性で議論すべきと考える。「主に日本型「やる事を公開」するのか?主に欧米型「やらない事」を公開するのか?」、の2通りがある。結果の例として、やる事を公開した場合、記述していない事はなんでも有りのルールとなる点に注意する必要がある。どちらのコミットメントで公開するか、利用企業側にとって防御が大いに異なると考えられる。
    • リスクアセスメントについて
      リスクアセスは、アセスの技法よりアセスした結果の有効性で議論すべきと考える。「期待する基準に到達しているかを視る「準拠性監査」にするのか?決議した指標に到達しているかを視る「妥当性監査≒絶対値監査」にするのか?」、の2通りがある。結果の例として、準拠性監査の視点でアセスした場合、PマークやISMS規格に到達する方向性が有るか否か、即ちPDCAが回っていれば到達とするので、規格を守る社員の逸脱をアセスするだけとなり、意図的に規格を無視する攻撃者に対しては有効性と効率性を大きく逸脱すると考えられる。

以上のような、日本企業のガバナンスの考え方の問題があり、文化の違いに対して、文化のグローバル化を行わないと難しいかもしれない。

今後のクラウドの利用に対するセキュリティ面の対応として透明性とリスクアセスメントが重要であることは明確である。それを踏まえて、日本でのビジネス向けクラウドをどうしていくのかを考える必要がある。

ということで、クラウド利用者会議として明確な指針を出すことはできなかったが、1つの考察とはなったものと考える。

以上