タグ別アーカイブ: CCM

CCAKの合格者経験記

コメントをどうぞ

《CCAKの合格者経験記》

2023年9月20日
三優監査法人
システム監査技術者、CCAK
堺 由美子

🔳CCAK取得の目的と経緯

クラウドセキュリティの監査について体系的に学ぶこと、「英語で勉強・英語で資格取得」に慣れることを主な目的として、新設されたCCAKに挑戦することを2021年春に決意。途中、別の資格試験を優先したり業務多忙で勉強を中断したりの後、2023年７月初旬にようやく受験、合格しました。

🔳どこからスタートだったか

  • CCAKは「CCSKをベースにして、それを補完する内容」とされていますが、CCSKは未取得（未勉強）でした。
  • システム監査やITガバナンス、情報セキュリティの知識、データセンター・クラウドの各種認証取得実務の経験がありました。
  • 技術者ではありません。
  • 英語は、読むのがそれほど苦ではない（何度も同じ単語を辞書で引いても折れずに読み続けられる）レベルでしたが、英語での勉強・受験は未経験でした。

🔳使用した教材

  • CCAK Study Guide
  • 諸角さんの講演資料（「クラウド監査人向けクラウドセキュリティ認定資格 CCAK(Certificate of Cloud Auditing Knowledge) 解説」, 2022年1月24日）。本資料はこちらからダウンロードできます。
  • CCAK Questions and Answers Collection（200問の問題集）
  • CSAおよびCSAジャパンの各種ドキュメント（セキュリティガイダンス v4.0他）
  • UdemyやLinkedIn Learningの「XX入門」講座（DevOps等、そもそも不足していた知識の補強）
  • また、会社（当時）でMicrosoft Azureの資格試験を受ける機会があったので、ボキャブラリ獲得と英語受験の練習としてMicrosoft Azure Fundamentals (AZ-900)を英語で勉強・受験しました。

🔳学習方法

当初はStudy Guideの目次と各章冒頭にあるOverviewで全体の構成を把握し、気になる箇所・知識不足の箇所を中心に読んでいこうとしましたが、”Governance”や”Compliance”がいろいろなところに出てきたりして構成があまり頭に入って来ず、捗りませんでした。

そこでQuestions and Answers Collectionに取組み、正答できなかったところをStudy Guideで確認、惨敗なところは一旦中断してCSAジャパンの翻訳資料を参照したり、Udemy等の入門講座をあたりました。Questions and Answers Collectionは3回くらい繰り返したと思います。

🔳CCAK取得に挑戦中/取得を検討中の方へのTIPS

  • Study Guide
    • PDF版がおすすめです。ダウンロードで即入手できますし、わからない単語を調べたり翻訳したりが簡単です。（読み上げツールも試しましたが、起きていられませんでした。）
      とはいえ断然紙の方が勉強しやすいので、PDFファイルを好きなところで分割し、ネットのプリントサービスで製本して利用しました。
  • Questions and Answers Collection
    • ブラウザで利用するので、ページの翻訳が使えます。英語で読んで英語で回答しないと試験対策になりませんが、解いた後の回答確認・解説は適宜翻訳して日本語で読み、脳の負担を減らしました。
    • 回答の解説は、残念ながら日本の情報処理技術者試験の問題集のようには全く充実していないです。
    • 購入すると12ヶ月間アクセス可能ですが、６ヶ月単位で延長できます（39ドルでした）。
  • 受験申込み
    • 購入すると有効期限が12ヶ月あります。準備万端となっていなくても購入し、自分を追い込むのも一手です。（有効期限が近づくと「これをもう一回受けるのはイヤだ！（受験料も高いし円安だし）」が強烈なモチベーショとなり、壮絶なまでの締切効果を得て乗り切れました。）
  • 受験当日（オンライン）
    • CCSKとは異なり、試験中は何も参照できません。
    • 試験官やカスタマーサポートも外国人で英語、本人確認に国内の免許証等は使えません。
    • （ISACAに旧姓で登録しているのにGovernment Issued ID Family Nameが空欄のままだったので、パスポートでも本人確認してもらえないことにチェックイン時になって気づき、試験直前に英語サバイバル訓練を余儀なくされてかなり消耗してしまいました。）
    • 早めにISACA Certificate Programs Exam Guideをよく読み準備しておくことをおすすめします。

🔳受験を終えて

以前から効率的な知識習得のために資格試験を利用していましたが、今回も「無知の知→勉強」を繰り返し、英語訓練もできたので、大変でしたが挑戦して良かったです。

CSAジャパンの豊富な翻訳資料・講演資料に大いに助けられました。どうもありがとうございました。

以上

データの暗号化における利用者鍵管理について

1件のフィードバック

データの暗号化における利用者鍵管理について

2022年2月9日
データセキュリティ WGメンバー：　諸角昌宏

本ブログでは、クラウド利用において必要となる利用者鍵管理について解説する。

  1. 利用者鍵管理の必要性について

    「クラウドでは共有責任モデルとしてユーザーがデータセキュリティの責任を持ちます。そのデータを保護する技術として「暗号化」が有効な技術であることが各法規制やガイドライン等で言及されており、多くの情報システムにおいて暗号技術は活用されています。
    また暗号化技術を利用する場合には「暗号鍵」もユーザーの責任で保護する必要があり、ユーザー自身の責任で鍵管理技術を理解して実装方法を選択して運用する必要があります。」（引用：　Cloud Data Protection, https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/08/Cloud_Data_Protection2_V10.pdf ）

    また、クラウドコンピューティングのためのセキュリティガイダンス V4.0（https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.2_clear_20200806.pdf）では、利用者が管理できる鍵（Customer-Managed Keys）」という手法の説明として、「利用者が管理できる鍵は、クラウド事業者が暗号化エンジンを管理するのに対して、クラウド利用者が自身の暗号鍵を管理できるようにする。例えば、SaaSプラットフォームの中でSaaSデータを暗号化するのに利用者自身の鍵を使う。クラウド事業者の多くは、デフォルトでデータを暗号化するが、事業者自らの完全な管理下にある鍵を使う。一部の事業者では、利用者が自分の鍵に差し替えて事業者の暗号化システムに組み入れることを許している。利用する事業者のやり方が利用者自身の要求条件と合致するか確認する必要がある。」と記載している。

    クラウドにデータを暗号化して保存する場合において、プロバイダーが鍵を管理すると以下のような問題が発生する可能性がある：

    • クラウド側のインサイダー（管理者）による情報侵害が発生する可能性がある
    • クラウド上に暗号化データと暗号化鍵の両方が存在するため、クラウド環境が侵害された場合（例えば、利用者間の論理境界が破られるなど）に情報漏洩につながる可能性がある
    • 召喚状等によりプロバイダーが利用者データの開示を求められた場合、クラウド上に暗号化して保存していたデータであっても、プロバイダーが復号して提供することが可能になる

半面、利用者がデータを暗号化し暗号鍵を保持する場合、アプリケーション（クラウドサービス）がそのデータを処理できないという問題が発生する。IaaSにおいては、利用者がアプリケーションとデータの両方を管理できるため、利用者が暗号化鍵を管理することが可能だが、SaaS環境においてはこの問題に直面する。

そこで考えられたのが「利用者による鍵管理（以下、利用者鍵管理と呼ぶ）」という方法で、プロバイダーが暗号化エンジンを管理するのに対して、利用者が自身の暗号鍵を管理できるようにする仕組みである。本ブログでは、この利用者鍵管理についての規制等の要求事項、利用者鍵管理の手法、動作の例などについて説明していく。

  1. 利用者鍵管理に関係する規制・要求事項

    以下に、代表的な規格における利用者鍵管理の要求事項を記載する。

    • ISO/IEC 27017
      • 10.1.2:　 クラウドサービスカスタマは,自らの鍵管理を採用する場合又はクラウドサービスプロバイダの鍵管理サービスとは別のサービスを利用する場合,暗号の運用のための暗号鍵をクラウドサービスプロバイダが保存し,管理することを許可しないことが望ましい。
    • CSA CCM V4
      • CEK-08: CSPはCSCがデータ暗号鍵を管理できる機能を適用しなければならない。
    • ISMAP
      • 10.1.1.9.PB: クラウドサービス事業者は、クラウドサービス利用者に、当該利用者の管理する情報の暗号化に用いる暗号鍵を当該利用者が管理し消去する機能を提供し、または、当該利用者が暗号鍵を管理し消去する機能を実装するために必要となる情報を提供する。

  1. 利用者鍵管理（BYOK、HYOK）とは？

    利用者鍵管理の構成として、前述の「Cloud Data Protection」では以下のように2つのタイプ（BYOK、HYOK）が記述されている。

    • BYOK(Bring Your Own Key)

      • ユーザー自身が暗号鍵を作成してクラウドサービスに持ち込むシステム構成
      • 持ち込んだ後の暗号鍵はクラウドサービス事業者内で管理
      • APIが公開されることが多く、オンプレミスのHSM等で作成した鍵をアプリケーションを開発することで持ち込むことが可能

    • HYOK(Hold Your Own Key)

      • クラウド事業者のサービスがユーザーの鍵管理システムを利用
      • ユーザーの暗号鍵はクラウドサービス事業者外部で管理

ここで、BYOKとHYOKの違いを明確にすると以下のようになる：

  • BYOKは、ユーザー自身が暗号鍵の作成・管理を行うが、プロバイダー側（つまり、クラウドのアプリケーション）が復号を行うにあたって、利用者から鍵を受け取る。受け取った鍵は、プロバイダー側で管理することになる。したがって、一度プロバイダーに渡された鍵を利用者が管理することはできない。
  • HYOKでは、利用者はプロバイダーの鍵管理システムを利用するが、暗号鍵の管理は利用者自らが行い、利用者の管理のもとプロバイダーは暗号鍵を扱うことができるようになる。したがって、利用者が常に鍵を管理することが可能になる。なお、このHYOKを提供する方法は、Microsoft Azureの２重キー暗号化 (Double Key Encryption) 、 Google Cloud External Key Manager、Salesforceキャッシュのみの鍵サービス(Cache-Only Key)などがあり、主なプロバイダーが提供している。

このBYOKとHYOKを明確にすることが重要であり、ここが利用者鍵管理として混同されている点である。特に、BYOKがバズワードとなっていて、利用者鍵管理＝BYOK と扱われてしまっていることが問題となる。先に述べた様々な規格の要求事項は、HYOKが必要となることでありBYOKでは不十分であるということを理解する必要がある。

  1. 利用者鍵管理（HYOK）の動作例

    ここでは、HYOKの動作の１つの例を以下の図を使って説明する。

    まず、この図に表示されているそれぞれの鍵について説明する：

    • DEK（Data Encryption Key）: データ暗号化鍵。データを暗号化および復号に使用
    • 暗号化DEK(Encrypted DEK) ：DEKを暗号化したもの
    • KEK(Key Encryption Key)：DEKの暗号化に使用される鍵
    • マスターキー：KEKの暗号化に使用される鍵

利用者から送られたデータを暗号化してストレージに保存する手順は以下になる：
(1)　アプリケーションに利用者からデータが送られる
(2)　アプリケーションは、KMSに対して、データ暗号化用の鍵（DEK）を要求する
(3)　KMSは、DEKを作成し、KEKを使って暗号化DEKを作成し、DEKと暗号化DEKの両方をアプリケーションに送る
(4)　アプリケーションは、DEKを用いてデータを暗号化し、暗号化されたデータと暗号化DEKをストレージに送る
(5)　アプリケーションはDEKを削除する

次に、データを復号する手順は以下になる：
(1)　アプリケーションは、ストレージから暗号化されたデータと暗号化DEKを入手する
(2)　アプリケーションは、暗号化DEKをKMSに送る
(3)　KMSは、KEMを用いてDEKを作成し、アプリケーションに送る
(4)　アプリケーションは、DEKを使ってデータを復号する
(5)　アプリケーションはDEKを削除する

以上の流れにおいて、プロバイダーがDEKを保有するのは、暗号化および復号の作業を行うときのみになる。また、一連の流れとして、利用者が鍵の管理を行うことができる。

  1. 利用者鍵管理に向けての考慮事項

    • BYOK　≠　利用者鍵管理　について

      以上、説明してきたように、クラウド環境で必要とする利用者鍵管理はHYOKであり、BYOKでは不十分である。しかしながら、BYOKを利用者鍵管理として説明している資料も多数あるのも事実である。ここは悩ましいところであり、現状でこれを明確にしていくことはかなり難しいかもしれない。もちろん、BYOK、HYOKを正確に伝えることは重要であるが、ある程度BYOKとHYOKを区別せずに、HYOKとして必要な要求事項をベースにしてBYOKを説明することもやむを得ないと思われる。
      また、BYOKとHYOKを厳密に区別することが、逆に、利用者鍵管理は不要であるという印象を与えてしまっているケースもある。CSAが公開している「クラウドサービスの鍵管理（原書：Key Management in Cloud Services）」では、まとめとして、「いわゆるBYOK（Bring Your Own Key）や同様のモデルをクラウドサービスで使用したBYOKの意味は、通常期待される結果が得られないことを示しています。これらのいわゆるBYOKモデルを使用しようとしているほとんどの組織は、クラウドサービスプロバイダが利用者のデータを裁判所や法執行機関などの第三者に引き渡すことを強制できないことを期待しています。ただし、いわゆるBYOKモデルのほとんどのベンダーにおける実装では、クラウドサービスがデータ暗号化鍵を使用しているため、必要に応じてエクスポート用に暗号化されていないデータを生成できるので、実際にはその結果を防げません。」と記述している。これは、BYOKとHYOKを明確に区別した上でBYOKでは不十分であることを指摘しているのであるが、HYOKを含めた利用者鍵管理すべてが不十分であると理解されてしまっているところがある。この辺りは、CSAとしても明確に記述する必要があったと思われる。
      また、ISMAPのFAQ（https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010098&sys_kb_id=cfb60af91baebc1013a78665cc4bcb12&spa=1）において、「暗号鍵の管理に関するクラウドサービス事業者内部からの不正アクセス対策を別の手段で実現すること。… ①1.2（権限分離）、②7.2.1（従業員・契約相手へのセキュリティ）及び③9.2.3（特権的アクセス権の制限）を適切に実施…」という代替策を記述している。しかしながら、この代替案では、先に挙げたプロバイダーが鍵を管理する場合の問題点に対する対策にはならない可能性が高く、あくまでリスク管理上可能であれば取れる代替案であることを理解しておく必要がある。

    • SaaSにおける利用者鍵管理の実装について

      SaaSプロバイダーが利用者鍵管理を提供する場合、以下の2つのケースが考えられる：

      • SaaSプロバイダーが、第三者ベンダーが提供している利用者鍵管理機能を実装する。
      • SaaSプロバイダーが、インフラとして利用しているIaaS/PaaSプロバイダーが提供している利用者鍵管理を用いて実装する。

なお、SaaSプロバイダーが利用者鍵管理を評価・実装するには、ユースケースを含めた詳しい情報が必要であると思われる。利用者鍵管理を提供しているベンダーおよびIaaS/SaaSプロバイダーは、利用者鍵管理に関する情報を積極的に発信していただきたい。本ブログにおいても、今後、できるだけ情報発信できるようにしていきたい。

6.　暗号化の代替手段

これまで、利用者鍵管理について記述してきたが、利用者鍵管理が必要となるそもそもの暗号化について、その代替手段として以下の２つが考えられる。

  • トークン化

    トークン化はクレジットカードの保護等で実績がある仕組みであり、従来からの暗号化技術と同様検討に値する技術である。
    暗号化の問題は、アプリケーションが暗号化されたデータを処理できないという点である。利用者鍵管理の問題以前に、クラウド上のアプリケーションは、何らかの形で復号しないと処理できないという根本的な問題を抱えており、クラウドのマルチテナントを維持しなければならない環境において問題となる。トークン化されたデータは、元のデータと同じサイズ/形式で保管されるため、トークン化されたデータを保管するためにデータベースのスキーマやプロセスを変更する必要はない。データのトークン化により、クラウドやビッグデータ、外部委託環境に移行する際も、制御機能やコンプライアンスを維持することが可能である。ここでは、トークン化について詳しく述べないが、1つの代替手段と考えられる。

  • 完全準同型暗号

    アプリケーションが、暗号化データを復号せずに処理できる方法として、（完全）準同型暗号が考えられる。まだ、あまり一般に商用化されていないが、今後、幅広く利用されてくる可能性もある。今後の展開に注目したい。

以上、クラウド上のデータの暗号化として必要となる利用者鍵管理について記述した。これから先、新たな情報が得られれば、また、情報発信していきたい。

以上

日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について

1件のフィードバック

本ブログでは、STAR Level1セルフアセスメントの重要性および日本語での評価レポートの公開方法について記述します。

2021年10月２０日
CCM/STAR WGメンバー　諸角昌宏

クラウドサービスプロバイダが、提供するクラウドサービスのセキュリティ情報を公開することは非常に重要です。クラウドセキュリティにおける責任共有モデルにおいては、クラウドサービス利用者は、自身が管理するセキュリティとプロバイダが管理するセキュリティの両方を把握し説明責任を果たすことが必要で、そのためには、利用するクラウドサービスのセキュリティレベルを把握する必要があります。これは、利用者がプロバイダに直接確認することで行えますが、たくさんの利用者を抱えているプロバイダが、利用者ごとの問い合わせに対応することは非効率です。そこで、プロバイダが、提供しているクラウドサービスのセキュリティ情報をあらかじめ公開することで、利用者は公開された情報に基づいてクラウドサービスのセキュリティレベルを把握することができます。また、プロバイダは、利用者からの個別の問い合わせに対応する作業を削減することができますし、セキュリティ情報を積極的に公開することにより、セキュリティをビジネス上の差別化要因とすることができます。

STAR Level1セルフアセスメントは、CSAが提供しているCAIQ（Consensus Assessment Initiative Questionnaire）に、プロバイダが自己評価した結果を記述し、それを公開するウエブサイト（CSA STAR Registry: https://cloudsecurityalliance.org/star/registry/）を提供しています。このCSA STAR Registryには、STAR認証が提供する3つのレベルの情報が公開されていますが、CAIQの評価レポートは、STAR Level1 セルフアセスメントとして公開されています。STAR Level1 セルフアセスメントのようなセキュリティの透明性に対する取り組みは、特に欧米のプロバイダは積極的に行っています。CSA STAR Registryには、1000以上のクラウドサービスが登録されていますが、その大部分がSTAR Level1セルフアセスメントとしてCAIQ評価レポートを公開しています。

CSAジャパンでは、日本のプロバイダが積極的にセキュリティ情報を公開できるように支援していきます。以下の2つのアプローチになります。

  1. 日本語CAIQ評価レポートの登録手順を日本語で提供
    STAR Level1 セルフアセスメントの登録手続きは、英語で行う必要があります。会社名やクラウドサービス名、およびそれらの概要等は、英語で記述する必要があります。CSAジャパンでは、日本語CAIQ評価レポートの作成から、STAR Level1 セルフアセスメントの登録までの一連の手順を日本語で記述しました。以下のウエブサイトを参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005
  2. 日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開
    CSA STAR Registryには、すべてのクラウドサービスの情報がアルファベット順にリストされています。この中から、日本語CAIQ評価レポートを公開しているプロバイダ及びクラウドサービスを探すことは難しいです。そこで、CSAジャパンでは、CSAジャパンのウエブサイトから、日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開することとしました。以下のウエブサイトになります。
    https://www.cloudsecurityalliance.jp/site/?page_id=19811
    なお、日本語 CAIQ評価レポートを公開されているプロバイダ及びクラウドサービスをすべて把握することが難しく、このサイトの情報はCSAジャパンが把握できているもののみになります。日本語 CAIQ評価レポートを公開されていて、このサイトにリストされていないものがありましたら、以下のメールアドレスまでご連絡ください（注意：　@の前後のクオーテーションを削除してください）。 info’@’cloudsecurityalliance.jp

以上

CSAの認証制度：STAR認証について

コメントをどうぞ

STAR認証について

2021年10月7日
CCM/STAR WGメンバー：　諸角昌宏

本ブログでは、CSA（Cloud Security Alliance）が提供するSTAR（Security, Trust & Assurance Registry）認証について、その概要、特徴、利用方法、CSAジャパンの活動について説明します。特に、STARレベル1（セルフアセスメント）について、プロバイダがクラウドサービスの自己評価レポートをCSA本部のウエブサイトより公開する方法について記述します。

  1. STAR概要

    STARは、CSAが提供するクラウドセキュリティの認証制度です。大きなフレームワークは以下の図1で示すように、3つのレベルを持っています。また、それぞれのレベルに対して、「セキュリティ認証」と「プライバシー認証」の2つのカテゴリーがあります。

    図1　STARフレームワーク

まず、「STAR認証レベル」について説明します。

  • STAR Level1

    STAR Level1はセルフアセスメントです。これは、クラウドサービスプロバイダが、CSAが提供しているCAIQ（Consensus Assessment Initiative Questionaire）に基づいて、自身が提供するクラウドサービスのセキュリティを独自に評価し、CSAのウエブサイト（https://cloudsecurityalliance.org/star/registry/）から公開するものです。CAIQは、CSAが提供するクラウドセキュリティの管理策集であるCCM（Cloud Control Matrix）のそれぞれの管理策について、いくつかの質問形式にブレークダウンしたものです。質問形式になっているため、クラウドサービスプロバイダは「YES」「NO」で回答することができます。また、回答に対するコメントを入力し、追加の情報を記述することができます。
    STAR Level1の特徴は、クラウドサービス利用者が、利用しようとしているクラウドサービスが自組織のセキュリティ要求事項を満たしているかどうかを、公開されている情報をもとに確認できることです。つまり、プロバイダの透明性が実現できているということになります。また、プロバイダの立場では、セキュリティ情報を積極的に公開することで、たくさんの利用者に対して統一したメッセージを出すことができますし、この情報をビジネス上の差別化要因として利用することもできます。
    STAR Level1の登録方法について、以下のウエブサイトに日本語で記述していますので参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005

 

  • STAR Level2

    STAR Level2は、第三者評価になります。クラウドセキュリティの評価としてCCMを使用しますが、以下の示す他の業界認定や標準を基にして、クラウドセキュリティを評価しています。

    • CSA STAR CERTIFICATION:　ISO/IEC 27001
    • CSA STAR ATTESTATION:　SOC2
    • CSA C-STAR:　GB/T22080-2008

STAR Level2の特徴は、認証だけでなく成熟度も評価していることです。クラウドサービスの成熟度を「ブロンズ」「シルバー」「ゴールド」のレベルとして認定します。
以下の図はSTAR CERTIFICATIONを表しています。

図２　CSA STAR CERTIFICATION 成熟度モデル

  • STAR Level3

    STAR Level3は、継続的モニタリングです。認証取得後も、その対応状況を継続的にモニタリングし保証する制度で、FedRAMPなどのハイレベルの情報を扱う際に要求されているものです。こちらは、まだ準備中になりますので、提供され次第ご案内できると思います。

それから、Level1、Level2には、Continuous Self-assessmentがあります。これは、通常の1年に1回の認証に対して、より頻度を上げた認証を行うようにしたものです。

次に「セキュリティ認証」と「プライバシー認証」について説明します。

  • セキュリティ認証

    セキュリティ認証は、上記で記述したように、CCMあるいはCAIQを用いて認証を行うものです。

  • プライバシー認証

    プライバシー認証は、クラウド環境におけるデータ保護法令遵守に必要な要件を定義した管理策であるCode of Conduct for GDPRを使用して認証を行うものです。GDPR向けの行動規範に準拠しているかどうかを認証します。

 

  1. STAR認証の特徴

    STAR認証では、今までの認証制度の課題として以下の3点を挙げ、それぞれに対して取り組んでいます。

    • 認証の継続性

      認証は「ある時点 (point-in-time)」あるいは「ある期間 (period-of-time)」を対象とするアプローチです。これは、変化の激しいクラウド環境においては不十分であることが指摘されています。STAR Level1/Level2 Continuous Self-assessmentでは、頻度を上げた形での認証を行うことで、より現実に近い認証を行っています。これにより、クラウドサービス利用者に対して、セキュリティ管理策の実施状況に関する詳細な最新情報を提供できるようになります。また、STAR Level3が提供されるようになると、よりリアルタイムに近い認証が実現できることになります。

    • 認証の透明性

      第三者認証（STAR認証ではLevel2）では、クラウドサービスの可視化を高いレベルで確保することが難しいです。STAR認証の各レベルは、それぞれ独立して運用するのではなく、組み合わせることでより高いレベルの認証を実現できます。たとえば、Level1とLevel2を組み合わせることで、高い保証（第三者認証）と高い透明性（セルフアセスメント）の両方を実現できます。以下の図は、STAR認証の各レベルの関係を表現したものです。

      図3　保証と透明性

    • 相互認証スキーム

      STAR認証のベースになるCCMは、数多くの国単位/分野単位の基準/規格へのマッピングを提供しています。CCMでは、各規格とのマッピングとリバースマッピングを提供し、それぞれの規格との差異（ギャップ）を分析し、その情報を公開しています。理想としては、1つの認証を取得することで、その他の認証に関してはギャップ分だけやればよいことになり、1つの認証の取得から別の認証の取得までの労力を最小化することができます。あくまで最小化のレベルであり、これで相互認証できるというわけではないことは注意が必要ですが、様々な組織（EU-SECやFedRAMPなど）とのフレームワークの検討が進んでいますので、その進捗に期待したいと思います。

  2. STAR認証に対するCSAジャパンの取り組み

    CSAジャパンでは、以下の取り組みを行っています。

    • STAR認証に関する情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=429

    • CCM/CAIQの日本語化および情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=2048#ccm

    • STAR Level1(セルフアセスメント)の日本語での公開

      CAIQの評価レポートを日本語で作成し、それを公開する手順について以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=1005

    • 日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの公開

      CSAジャパンでは、STAR Level1 セルフアセスメントの登録において、日本語CAIQ評価レポートを登録されたプロバイダおよびそのクラウドサービスに関する情報を公開しています。CSA本部のSTAR Registryでは、CAIQ評価レポートとして日本語で提供されているかどうかを判断するのが難しいです。そこで、CSAジャパンでは、日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの情報を公開することで、日本の利用者が利用できるようにしています。
      公開ウエブサイトは以下になりますので参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=19811

以上

 

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

6件の返信

第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のレポートも開示されており、これが報告書として使えるのではないかということになった。

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

以上

 

CSA Japan Congress 2015 盛況裡に閉幕

コメントをどうぞ

一般社団法人日本クラウドセキュリティアライアンス　業務執行理事
勝見　勉

11月18日（水）、日本でのCongressとしては2回目の開催となるCSA Japan Congress 2015が開催されました。朝から空模様があやしく、午後からは雨になった中、140人の多数にご参加いただきました。運営スタッフ、講演者、プレス関係などを入れると170名を超え、ほぼ会場キャパシティ一杯になるという盛況でした。

今回の「目玉」は日本情報経済推進協会（JIPDEC）・情報セキュリティマネジメントセンター、高取敏夫参事による特別招待講演「ISMSをベースにしたクラウドセキュリティ～ISO27017の最新動向」です。クラウドに特化した初めての国際標準規格であるISO/IEC27017の正式リリースがもう間もなく、という時期に、この27017に基づく、ISMSのクラウド情報セキュリティに関するアドオン認証の創設という話題を中心にお話し頂きました。このクラウドセキュリティアドオン認証は、11月16日にJIPDECから発表されたばかりの、湯気がホカホカ立っているような情報で、世界に先駆けてクラウドのISMS認証を制度化するという画期的なものでした。受講者の多くもこの解説を目当てに参加されたものと思われます。27017そのものが日本の提案を基に日本主導で開発が進められたという意味でも、ISO/IECベースの国際標準化の歴史の中では画期的なことでした。クラウドサービスの開発では世界をリード、と言えない日本も、クラウドの最大の関心事であるセキュリティに関しては世界をリードする立場に立っていると言えます。その意味で世界最先端・最新の情報に接することができて、聴衆の皆様共々、感慨深いものがありました。

Japan Congress 2015のもう一つのテーマは、新しいクラウドセキュリティ技術でした。中でも特別テーマ講演にお招きしたヤフー株式会社上席研究員の五味秀仁氏からは、「FIDO－次世代認証方式とクラウド」というタイトルで、クラウドにおけるユーザ認証に親和性の高い、パスワードレスの認証スキームであるFIDO(Fast IDentity Online)について紹介と解説を頂きました。この他にスポンサー講演、ゲスト講演、パネルディスカッション等を通じて取り上げられた新しい技術トピックとしては、CASB(Cloud Access Security Broker)、SDP(Software Defined Perimeter)、コンテナ、トランスペアレントな暗号化、27018（クラウドにおける個人情報保護）が挙げられます。

クラウドはコンピューティングプラットフォームとして広く定着する方向を見せています。昨今のサイバーセキュリティ脅威や情報漏えいに対する管理・防御を考える時、専門家により安定的・トラブルレスの運転が期待でき、セキュリティ管理も充実しているクラウド環境は、ITに多くの予算と人材を割けない中小企業こそ、積極的に活用すべき社会的リソースと言えます。そしてそのセキュリティは、技術面からも、マネジメントシステムの面からも、ますます充実していくことが期待できます。今回のCongressは、こういった流れを明確に打ち出し、理解を深めるとともに、そのための最新トピックを盛りだくさんに提供する素晴らしい機会になったと言えると思います。

更に付け加えるならば、冒頭の日本クラウドセキュリティアライアンス会長・吉田眞東大名誉教授のご挨拶では、春に開催するSummitが発信の場と位置付けられるとすれば、秋に開催するCongressは「クラウドのセキュリティについて多面的に取り上げ、最新の情報を提供し、クラウドとセキュリティのベンダ、サービスプロバイダ、インテグレータ、ユーザ、関係機関が一堂に会し、クラウドを取り巻くセキュリティ課題を議論する 」場である、と整理されました。多士済々のスピーカと、パネルも含むプログラム構成はこれを十全に体現したと言え、充実した一日を、多くの関心高い人たちと共有できたと思います。

おわりに、最後まで熱心に聴講いただいた受講者の皆さまと、設営・運営スタッフ、そしてたいへんバリューの高いプレゼンを頂いた講演者の皆さまに、この場をお借りして感謝の意を表して、Congressレポートのブログのまとめにしたいと思います。どうもありがとうございました。

 

CASB (Cloud Access Security Broker)概要、ケーススタディー（第14回CSA勉強会）

コメントをどうぞ

CASB (Cloud Access Security Broker)概要、ケーススタディー（第14回CSA勉強会）

日本クラウドセキュリティアライアンス
諸角　昌宏

7月28日に行われた第14回CSA勉強会について報告します。テーマは、「CASB (Cloud Access Security Broker)概要、ケーススタディー」ということでした。クラウドセキュリティの新たな潮流であるCASBは、あらゆるクラウドサービスの安全な利用のためのテクノロジになります。今回、日本で真っ先にCASBソリューションを展開しているマクニカネットワークスさんのみなさまに、CASBとはなにか、どのように使われるものかについて、デモを交えて説明していただきました。

まず、ブローカーという言葉とクラウドセキュリティをどのように結び付けているのか、というのがCASBという言葉を最初に聞いた時の感覚でした。ユーザの代理でクラウドセキュリティを担保してくれるようなサービスであれば、それは望ましいことですが、果たしてそんなことが可能なのでしょうか。もし、サービスを使っている状況でセキュリティ侵害が発生したら、保証問題になってしまうのでしょうか。ということで、あまりビジネスモデルが思いつかない状況で今回の勉強会を聞きました。

さて、クラウドの利用者は、どのような基準でプロバイダやクラウドサービスを選べばよいのでしょうか。CSAのガイダンスでも言っているように、基本はプロバイダとの契約にどこまで要件等を落とし込めるかになります。しかしながら、プロバイダが提供している情報でどこまでプロバイダを選定することができるか、また、クラウドの場合、サービス自体がサプライチェーンとなっている場合も多く、それらを含めてすべて理解することはほぼ不可能です。そのように考えていくと、CASBが徐々に見えてきます。CASBは、最初にガートナーが定義したところによると、「1つ以上のクラウドベースサービス全体で、単一のポリシーを適用できる」とのことです。要は、クラウドサービス(群)とユーザの間にアクセスポイントを提供し、そこでセキュリティポリシーを強化していく技術であるということになります。特に、シャドーITのように、利用者側で使われているクラウドサービスがコントロールできないような環境において、CASBが仲介することでコントロールを可能にするテクノロジになります。

CASBは、ガートナーの予想では、今年の市場規模が$100M、2018年には$400Mに達するということで、既に10社を超えるCASBベンダーが存在しているようで、この3年間で最も注目されるテクノロジとのことです。また、別のデータとして、1企業が利用しているSaaSアプリケーションの平均が1.083個であるとのことです。これは、シャドーITを含めた数字になりますが、相当数のSaaSアプリが既に使われていることがわかります。
さて、CASBですが、以下の4つの柱からできています：

  1. 可視化
  2. コンプライアンス
  3. データセキュリティ
  4. 脅威防御

この4つの柱を見ていくと、CASBの活用事例が見えてきます。まず、クラウド利用の現状を把握します。いわゆるシャドーITの実態を可視化により把握できるようにします。次に、クラウドサービスを管理された状態にします。これにより、コンプライアンス要件を満たしていくようにします。また、既存のテクノロジ（DLP等）と連携し、データ保護、脅威防御を実現し、オフプレミスでのデータ活用を促進できるようにします。最後に、クラウドサービスのライフサイクル全体を支援することで、ビジネスの俊敏性を実現していくことになります。

勉強会では、さらにSkyHighのデモを交えて、具体的にCASBでどのようなことができるかを説明していただきました。2つのIT（シャドーITと許可されたIT（sanctioned IT））で、どのようにCASBが利用されるかというデモでした。

  1. シャドーIT
    シャドーITに対しては、CASBの持つ可視化機能によって、すべてのクラウド利用状況を把握することができるようになります。また、クラウドサービスのリスク判定を行い、リスクアセスメントポイントを設定しています。これは、SkyHighがCSAのCCMをベースに独自に調査を行ったもので、既に4,000以上のSaaSアプリケーションが登録されています。ユーザは、このポイントを基にリスクを判断し利用するかどうかを決定することができます。
  2. 許可されたIT
    ログ等を集め解析を行います。これにより、監査証跡、ポリシーの強化、コンプライアンス対応等を行うことができます。また、イベントに基づく検知や脅威防御を、DLP製品等と連携して行うことができます。

以上のように、クラウド利用において問題となるセキュリティ対策を、利用者とクラウドサービスの間に立って行うことができるということから、今後、期待されるテクノロジということができます。解決しなければならない問題、たとえば、CASB自体が単一障害点になったり、ボトルネックになったりする可能性や、モバイルを用いた外部ネットワークからのアクセスの対処などが考えられるようですが、解決が難しい問題ではないと考えられます。

最後に余談ですが、CASBとタイプしようとして、CSABとタイプしてしまうことが結構あり、職業病かなと思うところもあります。CSAB（CSA Broker）なんて存在が必要にならないよう、CSAも地に足を付けて頑張らなければと思います。

以上、概略ですが、勉強会の報告といたします。

以上

 

CSA Summit @サンフランシスコ　の報告（第12回CSA勉強会）

コメントをどうぞ

2015年5月28日
日本クラウドセキュリティアライアンス　理事
諸角　昌宏

5月26日に行われた第12回CSA勉強会について書きます。テーマは、「CSA Summit報告会」ということで、4月にサンフランシスコで行われたCSA Summitの内容を笹原英司氏に説明していただいた。Summit Japanが開かれたのが5月で、時系列的に逆になってしまったが、大変興味深い内容であった。

まず、大きなトピックとして、以下の3つであった。

  • SDP（Software Defined Perimeter)
  • STAR Watch
  • ワーキンググループの報告
    SDPは、Summit中に3回目のハッカソンが行われ、安全な環境を提供するアーキテクチャとして、着実に進んでいるようである。STAR Watchは、STARのSaaS版であり、ベータ版の公開を開始している。また、CSAの活動の中心であるワーキンググループについては、各グループから詳細な報告があった。

さて、CSAの活動の特徴として今回目立ったのは、米国とEUの協調の橋渡しとしてCSAが寄与してきているということであった。つまり、グローバルな標準化に向けて、CSAが大きな役割を担ってきているということである。典型的なのは、スノーデン事件の影響で、米国とEUの関係がぎくしゃくしている状態で、その間を取り持つ形でCSAが機能しているということである。CSAヨーロッパがEUと米国の合意形成に寄与することで、国に対する影響力も強めているということである。また、中国では、中国政府の認証機関CEPREIと共同でSTAR認証の中国版を作成している。これは、6月中には発表される予定で、米国、EU、中国という主要市場でSTAR認証の制度が確立することになる。

また、クラウドセキュリティの世界では、今まではGoogle, AWS等のビッグプレーヤーがセキュリティの標準というものを作っていたが、最近の傾向としては、プラットフォーム上で新しいセキュリティを作っていく新しい企業やベンチャー企業が進出してきているということである。いわゆる、クラウドブローカの流れで、新興企業による新しい産業の創出（Open-Innovation）が起こっているということである。日本でも、FinTechを中心に新しい企業を支援する動きがあり、これが新たな潮流になってきているとのことである。笹原氏によると、ITの定義自体が、Information TechnologyからInnovation Technologyに代わってきているというなかなか面白い表現で、これはもしかするとヒットする用語になるかもしれないと思われた。また、笹原氏はセキュリティに対する今後の日本のかかわり方として、以下の2つのアプローチがあることを強調されていた。

  • 安全を担保するための情報共有を積極的に行っていくこと
  •  Innovationを起こして、産業を創出していくこと

その他、各ワーキンググループからの報告で特に印象に残ったのは以下の点である。

  1. STAR WG
    先ほども触れたSTARWatchがアナウンスされた。STAR認証をSaaS型で実現するもので、EXCELを埋めていく従来のやり方から一歩進んだ形になっている。日本側でも、この運用をどうするかを早急に検討する必要がある。ベータ版が公開されていることから、検討を開始したい。
    また、STARへの新たなマッピングとして、FedRAMP、27018、NIST Cyber Security Frameworkが追加されることになっている。
  2. IoT WG
    モバイルワーキンググループから独立して、活動を開始していて、CSAジャパンの活動もグローバルから評価されている。新しいドキュメントとして、”New Security Guidance for Early Adopter of the IoT”がリリースされている。IoT WGの最終的なターゲットは、企業向けIoTのセキュリティであり、特にプライバシーの保護をどのように進めるかが今後の研究テーマとなっているようである。
  3. CISC（Cyber Incident Sharing Center）
    これは、以前CloudCERTと呼ばれていたものある。ホワイトハウスが進めている情報共有の動きに合わせて活動を行っている。CSAの役割としては、民間、政府などと違ってニュートラルなポジションにいることを生かして、情報を集めるときに発生する利害関係をCSAが間に入ることで円滑に進めていくということである。
    CISCは、日本企業、特に米国の日系企業にはインパクトが大きく、米国の情報をどのように本国で対応していくかなど、法的な問題も含めて見ていく必要がある。

以上、CSA Summitの報告を簡単にまとめてみた。グローバルという観点で見た場合のCSAの重要度が感じられる内容で、CSAジャパンとしてもさらに活動を活発化していく必要があることを強く感じた。

 

CSA Japan Summit 2015　を終えて

コメントをどうぞ

2015年5月25日
日本クラウドセキュリティアライアンス　理事
諸角　昌宏

CSA Japan Summit 2015が、5月20日に開催された。今後のクラウドおよびクラウドセキュリティの動向をグローバルの視点を含めて聞くことのできた講演であった。

さて、全体を通じてまず感じたことは、クラウドに対する見方が大きく変わってきているということである。つまり、「クラウドを使っても大丈夫か」ではなく、「クラウドをどのようにビジネスに活用するか」というように変化していることである。以前のCSA勉強会で渥美俊英氏が述べていたように、もはやクラウドを技術的に考えるのではなくビジネス的に考えなければいけなくなっている。また、クラウドを使わずには、企業が生き残っていくことができないという段階に来ているということを改めて感じた。今回のCSA Japan Summit 2015は、クラウドを支えるべく技術的な動向、IoT等の新たな動向、金融機関における業務のクラウド化の紹介、また、法律の観点からの考察ということで幅広くこのクラウドに対する見方の変化についてカバーしていた。

以下、私なりに3つのポイントで今回のSummitをまとめてみる。

  1. クラウドの利用を支える新しい技術
    企業がクラウドを使っていく場合、もはや、「パブリックは危険」で「プライベートは高価」という概念を取り払う段階に来ているようである。パブリッククラウド環境にプライベートクラウドを構築するバーチャルプライベートクラウドを用いて、如何に安全にクラウドに移行するかを考えていくことが重要である。ソニー銀行の大久保光伸氏の講演では、銀行業務のかなりの部分をAWS VPCに移行させた事例を紹介していた。信頼が非常に重要な銀行業務においてクラウド化を実現した理由は、限られたIT予算内で「固定的ITコスト」を減らし「戦略的ITコスト」に振り向けることとのことであった。以前からクラウドに移行するメリットとして挙げられている理由ではあるが、銀行という業種の言葉として非常に重みを感じる。AWS VPCが信頼できるプラットフォームとして選ばれた理由は、ISO27001とFISCの安全対策基準に準拠しているということであった。どのような形でプロバイダを選定するかについて、吉井和明氏の講演では、「利用者側で、事業者側を管理することや責任を取ることはかなり難しい。利用者側ができることは、リスク軽減の考え方に基づいてクラウドの選択を行うことが重要である。経産省/金融庁等のガイドラインやCSA　STARなどを使ってプロバイダの能力を判断することが最良の策である。」とのことであった。このように、バーチャルプライベートクラウドを積極的に利用していくこと、またそのためのセキュリティ対策をきちんと行うことが今後のビジネスにおいて重要になると思われる。
  2. クラウドセキュリティを支える新たなソリューション
    Jim Reavis氏の講演では、CSAにおいて以下の技術をもってバーチャルプライベートクラウドのセキュリティの研究を進め、安全なクラウドに向けての活動を行っているとのことであった：

    • 暗号化と鍵管理バーチャルプライベートクラウドにおいては、データおよび通信の暗号化は非常に重要である。CSAのSecurity as a Serviceワーキンググループでは、クラウドのセキュリティの研究において、特にこの分野にフォーカスしている。
    • CASB: Cloud Access Security Broker クラウドアクセスセキュリティブローカ （クラウドへの安全なアクセスを提供する業者） 。クラウドプロバイダのセキュリティ対策を補完し、利用者が必要とするクラウドセキュリティ対策をまさに代行して行うもので、非常に有効なクラウドのセキュリティ対策になる。
    • 仮想化バーチャルプライベートクラウドは、基本的に仮想化環境で動くことになる。仮想化のセキュリティに関しては、ガイダンスで扱っている内容であり、引き続き研究を進めていく。また、新たなコンテナ技術(Dockerなど)に対するセキュリティの研究も進めている。
    • SDP（Software Defined Perimeter） SDPは、認証ができるまでネットワークを非公開に保つことができ、ネットワークの高い安全性と信頼性を構築できるアーキテクチャとなっている。現在は、パイロットやユースケースの拡大の段階ではあるが、実用化に向けての研究を進めている。

      そのほか、プロバイダの認証としてのSTARプログラムを展開しプロバイダのレベルの透明性や認証を進め、利用者が安全なプロバイダを選定できる体制を整えている。また、利用者のリテラシーの向上に向け、クラウドの認定資格のCCSKを進めている。

      また、クラウドで重要となるID管理をSaaS化するIDaaSについて、江川淳一氏からお話があった。IDaaS自体は、4~5年前から米国で増えてきたサービスで、ID情報マスタをIDaaSで管理する。クラウドを利用する場合、オンプレミスよりID管理が面倒になる。また、利用者もクラウド事業者もどちらもID情報は預かりたくないというのが本音である。そうであれば、ID管理を専門に行っていて、信頼できるサービスを利用するというのが、セキュリティの観点からも有用になってくる。もちろん、IDaaS事業者には厳格なリスク評価が要求されるが、サプライチェーンをコントロールできる点を考えてみても有用なサービスになってくると思われる。

      もう1つ、夏目道生氏からはシャドーIT対策として、現状（利用状況）の把握、モニタリング、リスク評価、アナライズ、セキュリティ対策というサイクルでの対応が必要となるというお話があった。それを実現する製品としてSkyHighが紹介されていた。SkyHighは、Jim Reavis氏の講演でフォーカスされていたCSABを提供しており、クラウド環境での新たなセキュリティ対策として注目していきたい。バーチャルプライベートクラウドにより、機密性の高い業務をクラウド化することが十分現実味をおびてきている。一方、クラウドに対するセキュリティ技術自体も進化している。アンテナを高く張って、クラウドを安全に使う技術を習得し続ける必要がある。

  3. IoTの動向とセキュリティ
    今回のSummitにおけるメインテーマの１つがIoTであった。IoTは、最近流行りのバズワードと思われる点もあるが、森川博之氏によると、バズワードでは終わらないということであった。それは、データが集まれば、様々な産業が集まり、今までなかったもののデータが重要になり、これを扱うIoT自体が、産業セグメントを変えていくということである。特に、IoTが大きな影響を与える分野として、医療（医療に関しては、日本が世界で最大のデータを持っている）、土木系（地すべり対策としてセンサーを設置するなど）など、今までは経験と勘に頼っていたものに新たにデータが加わってくることで生産性の低い分野にチャンスを与えることになるということである。講演タイトルの「未来を創るIoT」において必要とされることについては、「フィールド志向」と「デザイン能力」とのことであった。IoTで最も重要なのはユーザ企業。現場で使っているものを理解する必要がある。自分で飛び込んでいって解決させていく「フィールド志向」が必要になる。また、従来必要とされた能力である「考える、試す」に対して、これから必要とされる能力は、「気づく（柔軟な発想）、伝える（説明の仕方によりインパクトが違ってくる）」ということで、この「デザイン能力」を意識的に磨いていくことが重要とのことである。

    また、IoTのセキュリティについて研究を行っている二木真明氏は、いろいろなデバイスがシステムとして動くようになった場合のシステムとしてのリスクとして、システム全体として障害を起こした場合の方がクリティカルになると述べていた。そのため、CSAジャパン IoTクラウドWGでは、システムの中のサービスにフォーカスして活動しているとのことである。このような状況でのセキュリティ対策として、サービス事業者はリスク評価を正しく行い、セキュリティ対策を講じることが必要ということであった。

    IoTについては、Jim Reavis氏も触れていたように、CSAとしても重要なテーマの1つとして研究を進めていくということであった。

最後に、クラウドセキュリティには直接関係しないが、飯塚久夫氏のTelecom-ISACの話は興味深かった。詳細には触れないが、「受動的な無責任を改めよ！大事なのは安全の確保であって、安心の確保ではない。日本では、自己の確立ではなく自我の確立に走っていた。また、安全・安心は誰かが与えてくれるという観念があり、リスク対応が不得手である。」ということで、リスク文化の転換が必要であるということを強調されていた。

クラウドセキュリティについて語ると、どうしてもクラウドにおけるリスク中心の話になりがちである。結果、利用者から「クラウドはやっぱり危険なんですね」という意見をいただくことが多い。クラウドセキュリティに関わるものとして、リスクを正しく伝えることは重要であるが、クラウドを安全に使うためのガイドをもっと出していかなければならない。うまく使えば、クラウドの方がセキュリティレベルは高いはずである。

その他、盛りだくさんだったSummitの内容については、後日公開される資料集を参照してください。

 

第10回CSA勉強会「ISO/IEC27001:2013とISO/IEC27017の重要なポイントの解説」

コメントをどうぞ

2015年3月27日
日本クラウドセキュリティアライアンス　理事
諸角　昌宏

第10回CSA勉強会は、工学院大学の山﨑哲氏に、ISMSの基準となるISO/IEC27001:2013の改訂における重要ポイントと、クラウドサービス事業に大きな影響を与えるクラウドセキュリティの管理策体系であるISO/IEC27017（今年秋に正式発行予定）の要点について解説していただきました。
27001については、JIS規格が出されたのが2014年3月であり約1年を経過しているにも関わらず、2013についてほとんど勉強していませんでした。したがって、今回の勉強会は私にとって非常に有意義なものとなりました。また、27017に関しては、今年の10月に規格化されるようで、また、クラウドセキュリティに関わっているものとして、こちらも有意義な最新情報をいただくことができました。
非常に中身の濃い、ボリュームのある内容でしたので、ここでは概要と印象に残ったことについて書いていきます。かなり私見も入っていますし、間違い、勘違い、認識不足もあると思います。ぜひ、このブログにコメントを書き込んでいただいて、いろいろと教えていただければと思います。よろしくお願いします。

  1. ISO/IEC27001:2013の改訂のポイント
    27001の改訂内容として、主に以下の3点があげられます。

①      ISMSの意義として、経営陣の目的・目標を要求事項とし、経営陣の方針から管理策への展開が規定されています。また、CISO(トップマネージメント)の設置も規定され、情報セキュリティを統括することが求められています。
情報セキュリティ管理は、経営陣の支持のもとに進めるというのが大原則で、これにより経営とセキュリティ管理の一体化が図られることが必要ですが、なかなか実践できている企業は少ないと思われます。セキュリティ管理プロセスにおいても、まず最初に、acknowledgementということで、経営陣の認識および支持を取りつけることが必要ですが、実際には経営陣の支持を得ることが難しい（そのための方法もあまり確立されていない）というのが現状です。これを27001:2013では、CISOを中心とした経営陣による目的・目標の設定を規定することで、経営とセキュリティが一体となった取り組みができるようになりました。セキュリティについて経営陣主導の体制が整えられることで、望ましい状況になっていくことが期待できます。

②      マネージメントシステム企画の共通化、用語の共通化が行われています
27001:2013では、マネージメントシステム（MSS）企画を共通化することで、統合的なセキュリティの構築を行えるようにしています。すべてのMSS規格に共通の目次を持たせることで統一して扱えるようになっています。また、用語の統一も図られ、27000の用語集をもとに統一させています。
この中で、リスクに対する定義が改訂され、「リスクを、目的に対する不確かさの影響」とし、組織の状況の理解に基づいてリスクアセスメントを行う形になりました。これに伴い、リスク値の定義も変更され、今までの「リスク値 = 資産ｘ脅威ｘ脆弱性」が、「リスク値 = 結果ｘ起こりやすさ」として定義されることになりました。「結果： 目的に影響を与える事象の結末」、「起こりやすさ：何かが起こる可能性」ということで、情報セキュリティの目的および計画策定に基づいたリスク判断ということになるようです。今までの定義に基づいてリスク値の説明を行ってきたものにとっては、新しい定義を腹に落とすことが必要になります。また、リスク対応も、今までの4つの手法から7つの手法に変更されており、この新しい定義の理解も必要になってきます。

③      分野別ISMSを確立するための国際規格となっています
27001:2013でもう1つの大きな点は、Sector specific control set standardということで、分野別のISMS体系にしたことです。これにより、一般的な27001と分野別の基準を合わせて、分野対応のISMS認証を行うようになりました。たとえば、後で述べますが、クラウドセキュリティに関しては、27001(generic)＋27017でクラウドセキュリティ分野のISMS認証が取得できることになります。

このように、27001:2013では、「経営陣と管理者・従業員とのパイプ役となる情報セキュリティ目的・目標を設定する」ことで、「経営陣と管理者・従業員が、情報セキュリティ目的・目標を共有することでコミュニケーションギャップをなくす」ことができるように改訂されています。今までは、このギャップがさまざまなセキュリティ問題の根底にありましたが、この改訂でかなり解消されることが期待できますし、CISOの設置により、より明確な責任のもとセキュリティプロセスが運営できることが期待できます。特に、日本においては、CISOの設置と合わせて、より経営陣の支持を得たセキュリティプロセスが展開できるようになることが期待できます。

  1. 分野別ISMS規格”ISO/IEC27017”の意義と解説
    クラウドセキュリティにおいては、「クラウドの課題を解決するためには、基準（Criteria）に基づいて、クラウドの利用者と事業者の間で、（国際環境において）共通の理解を実現するための仕組みの確立が必要である」ということから規格化が行われています。今年の10月には、公開されるということです。また、CSAもこの規格の作成には非常に協力しているということです。今後、27017、CCM（Cloud Control Matrix）との関係等、CSA、ひいては、CSAジャパンも幅広く活動していく必要があります。ここでは、27017のいくつかのポイントをあげていきます。

①      27017の適用範囲（Scope）
Cloud Service Provider(事業者)、Cloud Service Customer（利用者側組織）、および、Cloud Service User（実際にクラウドを使う人）を適用範囲とし、Cloud Service Partner（開発者、ブローカー、監査）は、今のところ適用範囲とはしないということです。

②      27001の分野別標準及び分野別管理策となります
27017は、27002をベースとしたクラウドサービスの情報セキュリティコントロールとなります。したがって、章立ては27002と同じになります。また、Annexにクラウド特有のコントロールが追加されています。

③      クラウドコンピュー ティングの用語
用語については、SC38:ISO/IEC17788を用いるということで、NISTの定義などとは違ってきています。
特に、クラウドのモデルに関しては、NISTのサービスモデルと展開モデルとは違い、Cloud Service categoryとCloud Capability Typeを用いた分類となるようです。詳細は省きますが、CSAもNISTのモデルに基づいて定義していますので、今後ガイダンスを含めて影響を受けるものと思われます。

④      クラウド利用者、クラウド事業者双方の視点
27017の管理策であるImplementation guidanceがテーブル形式となっており、それぞれの項目に対して、利用者（CSC）,事業者（CSP）のどちらあるいは両方が対応するかどうかがまとめられるようになっています。これにより、利用者、事業者双方の視点でガイダンスを見ていくことができるようになります。

以上、本当に簡単ですが、勉強会の内容の報告とさせていただきます。