タグ別アーカイブ: ガイダンス

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

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つの代替手段と考えられる。

  • 完全準同型暗号

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

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

以上

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

コメントをどうぞ

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

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

 

 

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

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

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

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

３つのクラウドアーキテクチャ（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に沿ったセキュリティ対策を提案し実践していくことが必要だ
と感じている。

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

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

 

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

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

以上

 

日本型クラウド利用について　～　第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文化が出来上がっているとのことである。マネージド型クラウドは、決して日本独自のクラウド利用形態ということではなく、セルフサービス型クラウドとマネージド型クラウドでそれぞれ利点を生かしつつ共存していくということが言えると思われる。

以上

 

欧州の社会課題解決型イノベーションと個人データ保護　～第19回CSA勉強会

コメントをどうぞ

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

1月25日に行われた第19回CSA勉強会では、「欧州の社会課題解決型イノベーションと個人データ保護」ということで、笹原英司氏に講演していただいた。今回は、勉強会としては初めて「特定非営利活動法人横浜コミュニティデザイン・ラボ」との共同開催ということで、いつもとは違った交流を行うことができた。

ここでは、勉強会で解説された内容をいくつかトピック的に記述する。なお、内容について笹原氏にレビューしていただいた。

  1. EUにおけるeHealthの考え方
    EUにおいては、イノベーションのベネフィットと個人データ保護のリスクのバランスを図ることが政策目標となっている。EUでは、国境を超えたヘルスケアが日常的なため、複数の国で利用されることを前提としつつ、eHealthによるイノベーションの成果を社会課題解決のためのソリューションとしてパッケージ化して海外に輸出することによって、雇用創出や経済発展につなげようとする考え方が一般的だ。このようなEUの発想は、日本にとって参考になる点が多い。
  2. EUにおける個人データ保護
    EUの方が米国等に比べて、個人データの対象範囲が広く、かつ、厳しくなっている。ただし、あくまでもイノベーションと消費者保護のバランスを取りながら、時代の経済政策と共に変化している。 昨年(2015年)、新たに「EU保護規則」が合意された。従来の「指令」が「規則」に代わったことにより、すべてのEU加盟国に一律適用されるものとなった。ちなみに、「指令」の場合は、EUが定めた共通ルールに基づいて各国が具体的な対応策を決めることになる。これらの動きと同時並行で、IoTやBigDataのセキュリティ/プライバシー保護に関するルール作りも進んでいる。
  3. デンマークの医療
    デンマークは、電子政府/オープンデータ基盤を非常にうまく利用している。高い普及率の電子カルテシステムをベースに、ナショナルデータベースを構築・運用しており、これに基づいた分析データが様々に利用されている。これは、国民共通番号制に基づくデータの収集および利活用を、中央政府と地方政府、市民、企業が協働することで実現しており、その背景には、子どもの時からの教育重視の姿勢がある。デンマークの教育では、社会参加意識を非常に重視しており、市民参加を誘発するように教えられている。たとえば、デンマークで電子投票を行うと90%以上が投票するということである。また、ノーマライゼーションの原則があり、障害者と健常者が区別されることなく社会生活を共にするという意識が徹底されている。このような文化が根付いているデンマークでは、個人データの収集と利活用が全国民参加の上で実現できている。
  4. 日本におけるデジタルヘルスラボ・プロジェクト
    演者が関わっている活動の1つとして、デジタルヘルスラボ・プロジェクトがある。これは、デジタルハリウッド大学大学院と横浜市が協業して行っているもので、「デジタル」＋「医療・健康」の分野で起業またはサービス開発を支援し、その「実装」を本気で追究している。通常、ビジネスモデルの検討で行き詰るのは、お金の問題等で実装ができないということが多い。このプロジェクトでは、実装を追求することで企業およびサービス開発を支援していくということである。医療系のサービス開発に際しては、個人情報保護やセキュリティ対策が常につきまとうので、早期から取組を始める必要がある。
  5. CSAは何をやっているか？
    EUとCSAの協業活動として、以下の2つを進めている。

    1. Cloud Security Alliance Privacy Level Agreement WG
      EUのレベルでの個人情報保護のチェックリストを作成し、米国のクラウドベンダーがEUでビジネスを行うためにどうすれば良いかを記述したドキュメントを公開している。これには、従来のセーフハーバー対策も含まれており、今後は「プライバシーシールド」への対応がテーマとなる。
    2. SLA-Ready
      EUの活動の一環として、中小企業向けの振興策としてのクラウド利用に対して、どのようなSLAであればセキュリティが担保できるかの検討を行っています。SLA-Readyについては、以下のCSAジャパンブログで触れているので、こちらを参照していただきたい。 http://cloudsecurityalliance.jp/newblog/2015/02/13/sla-ready%e3%81%8c%e3%83%a8%e3%83%bc%e3%83%ad%e3%83%83%e3%83%91%e3%81%a7%e7%99%ba%e8%b6%b3/

さて、上記のようなEUにおける個人情報の扱いを踏まえて、日本が今後どうなっていくのか。グローバルの視点に立って、我々も考えていく必要がある。また、「Privacy Level Agreement WG」や「SLA-Ready」の内容については、日本にも適用できる部分も大きいので、いろいろと検討を進めていきたい。

以上

SaaS環境のクラウドセキュリティについて　～第18回CSA勉強会

コメントをどうぞ

日本クラウドセキュリティアライアンス　業務執行理事
諸角　昌宏

12月16日に行われた第18回CSA勉強会では、SaaS環境のクラウドセキュリティについてということで、セールスフォース・ドットコムの高橋悟史氏に講演していただいた。関心の高いテーマということで、多数の申込者があり、また、質疑も活発に行われて有意義な勉強会になった。また、SaaSだけではなくPaaSにも焦点を当てたクラウドセキュリティということで、非常に幅広くカバーしていただいた。

ここでは、大きく4つの点（プラットフォームセキュリティ、信頼性、セキュリティ管理機能、透明性）で勉強会の概要を説明する。

  1. プラットフォームセキュリティ
    セールスフォース・ドットコムでは、インフラ、ネットワーク、アプリケーションのすべての層においてセキュリティ対策を施している。インフラ、ネットワークでは、セールスフォース・ドットコムがセキュリティ対応をできるように24時間365日で管理を行っている。
    アプリケーションにおいては、シングルコードによる高い品質を維持し常に最新のものを使用することでセキュリティレベルを高めている。
    また、信頼を確保するために、年間数千億円の投資を行っており、外部の監査も定期的に受けている。
  2. 信頼性
    セールスフォース・ドットコムが一番強調しているのは信頼性である。稼働率はともかく、今まで一度もセキュリティ侵害を受けたことがないということはすごいことである。
    また、データのミラーリングやグローバルのデータセンターを用いたバックアップサイトを運用することでデータの可用性を高めている。
    バックアップサイトを日本に作る計画も進んでおり、これにより法域の問題やデータセンターへの立ち入り監査の問題に対応できるようになる。
    さらに、大規模マルチテナントであることから、作業できる要員の集中化を実現している。データセンターの運用に携われるのは信頼のおける人間のみとしており、プロバイダの人的な問題にも対応している。
  3. セキュリティ管理機能
    二要素認証、シングルサインオン（SAML2.0およびOpenID Connectに対応）、および、IDプロビジョニングによるID管理の安全化を行っている。
    データの暗号化については、鍵管理がサーバ側になっているが、SalesForce Shieldというオプションの暗号化機能を使うとサーバ内に鍵を保存することなく、必要なときにのみ鍵が生成されることになる。クラウドにおける鍵管理の原則は、利用者側で鍵を管理することであるが、それを実現するための1つの方法となっている。また、HSMによる厳重な鍵管理も行われており、非常に高度な暗号化と鍵管理を実現している。
    マルチテナントデータベースのセキュリティ対策として、テナント（利用者）ごとのテーブル構造が分からないようにしている。これは、メタデータによりテナントごとのマッピングを行うことで、自分のデータは自分しか見えないようにしている。これにより、データベース管理者がテーブルごとデータを抜き出したとしてもデータが漏洩することにならないようなセキュリティ対策が施されている。
    ネットワークについては、TLS1.2+AES256に対応した安全な通信を行っている。また、PCIDSS 3.1へのコンプライアンスとして、来年にはTLS1.0の接続をシャットアウトする予定とのことである。これは、利用者によっては問題になる場合もあるが、より安全なネットワーク環境の提供を行うということで進めている。
    データセンターの運用として、データセンター内にサーバにログイン可能な環境はなく、すべてリモートで運用を行っている。これにより、データセンター内で問題が起こらないように対策を取っている。また、データベースまでアクセスできる要員は少数の従業員のみとしている。
    さらに、社内にEthical Hackingチーム（redチームと呼ばれる）があり、ハッキングおよびペネトレーションの調査等を行っている。これは、独立した組織として活動しており、問題を見つけた場合にはすぐに対応を指示できるようにしている。
  4. 透明性
    http://trust.salesforce.comというウエブページに情報を公開し、稼働状況やメンテナンスのスケジュール等を公開し顧客が見える形で情報を提供している。また、もし顧客から要請があれば包み隠さず情報を提供する体制になっている。また、レギュレーションについても、要請があれば提供できる体制になっている。
    バージョンアップなどについては、顧客に事前情報提供を徹底し、できるだけ顧客に影響が出ないようにしている。

セールスフォース・ドットコムのセキュリティということで、非常に深く対策が取られていることがわかった。その上で、透明性を高めて利用者に対する説明責任を果たしている。このように、クラウドプロバイダとしての方向性を決めていくようなセキュリティ対策となっていると思われる。

CSAのガイダンスで述べているように、IaaSと違いSaaS/PaaSに関しては、プロバイダのセキュリティ対策に依存しなければならないところが多い。しかしながら、説明責任は利用者側に残る（セキュリティ対策はプロバイダ側に移動したとしても説明責任は利用者側に残る）ことに基づき、利用者のリスク管理の一部としてプロバイダのセキュリティレベルをきちんと確認しておくことが重要になる。セールスフォース・ドットコムのセキュリティ対策は、プロバイダが行うべきセキュリティ対策として、利用者が確認しておくべきことの指針になるものと思われる。

なお、勉強会の資料は2週間後を目途に一般公開される予定なので、詳細についてはそちらを参照してください。

IoTがもたらすさまざまな影響

コメントをどうぞ

日本クラウドセキュリティアライアンス
業務執行理事　諸角昌宏

IoTの活用がいろいろなところで語られているが、その実態はどうなのであろうか。IoTが、単なるバズワードで終わらないということは、5月に行われた「CSA Japan Summit 2015」において森川博之氏の講演でも触れられていた。森川氏によると、「データが集まれば、様々な産業が集まり、今までなかったもののデータが重要になり、これを扱うIoT自体が、産業セグメントを変えていく。特に、IoTが大きな影響を与える分野として、医療（医療に関しては、日本が世界で最大のデータを持っている）、土木系（地すべり対策としてセンサーを設置するなど）など、今までは経験と勘に頼っていたものに新たにデータが加わってくることで生産性の低い分野にチャンスを与えることになる」ということである（参照：CSAジャパンブログ）。産業セグメントを変えていくという新たな潮流をIoTが担うということで、1つの大きな変革になるということである。

9月18日に行われた「ID & IT Management Conference 2015」では、「IoT活用がもたらす産業・社会変革」というタイトルで東京大学先端科学技術研究センター特任教授 稲田修一 氏が講演を行ったが、新たなIoTの見方があって大変興味深かった。

稲田氏によると、まず、IoTの前にOT（Operational Technology）があるということである。OTは、企業間にまたがるバリューチェーンの最適化を図ることであり、いわゆるIndustry4.0の中核をなす考え方である。この最適化を行うには、企業間をまたがるデータ共有が必要であり、これがIoTにつながっていくということになる。さて、この企業間をまたがったデータ共有というものが日本でどのようになっているかというと、非常にお寒い状況のようである。まず、データの利用に対する考え方が間違っている。データは、ビジネスにおける課題の発見と解決のために使われなければならないところを、データをどのように活用するかというところに目が行っている。これは、多分に経営者の問題であり、データの利用を担当者に丸投げしているため、まったく新しいアイデアが出てこない。まさに、オペレーションとイノベーションの区別がついていない。まず、経営者が戦略・方針を示し、そのうえでデータを活用していくということが日本には求められるということである。

稲田氏は、もう1点、IoTが果たす役割について述べていた。それは、IoTが一般のインターネットと違い安全を必要とする点が重要であるということである。医療や自動車など、IoTが利用されるところでは、多くの部分で命に関わってくる。このような環境では、今までのソフトウエアのやり方を根本的に変える必要がある。バグが直接命に関わることになるので、今までのように利用者にバグ出しさせるとか、バグなのか仕様なのかがはっきりしない、はたまた、再現できないバグは修正できない（再現っていったい？？？）というようなことは許されなくなる。ソフトウエア関係者が良く使う「Best Effort」の対応などということは全く通用しない、保証「Guarantee」のある世界をIoTが作っていくことになる。つまり、IoTをきっかけにインターネットやソフトウエアの世界が大きく変わっていく可能性を秘めている。

IoTは、これからもさまざまな世界を切り開いていくことが期待できる。その中で、IoTをどのようにクラウドセキュリティに結び付けていくか。CSAジャパンのIoTワーキンググループでもいろいろと議論を進めているので、興味のある方はぜひご参加ください。

以上

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も地に足を付けて頑張らなければと思います。

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

以上

 

SLA-Readyがヨーロッパで発足

1件のフィードバック

クラウドのSLAをガイドするSLA-Readyがヨーロッパで発足

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

クラウドサービスの利用する場合、通常、SLA(Service Level Agreement)に基づく契約を行うことになります。CSAのガイダンスでは、「SLAが利用者に提示された時、サービスとプロバイダに対するサービスレベル、セキュリティ、ガバナンス、コンプライアンスおよび法的責任に対して期待される点が、契約上規定され、管理され、強制される」というように記述されています。したがって、利用者は、クラウドサービスを利用する前にプロバイダが提示するSLAを詳細に確認および理解し、クラウドサービスの利用上問題がないことを確認する必要があります。また、必要に応じてプロバイダと交渉しSLAの変更を行うことも必要になります。しかしながら、SLAを理解することは非常に難しいというのが現状です。特に、中小企業(SME)にとっては、クラウドサービスに対する専門家や知識の不足などから、SLAを理解することが難しい状況です。また、SLAの複雑で誤解を招く記述や、ワンクリックで合意しなければならないことが、中小企業のクラウドサービスの採用の足かせとなっています。

SLA-Readyは、SLAの共通の理解を働きかけ、SLAの標準化や透明性の確保を行っていくために設立されました。これにより、どのようなサービスを利用するかという企業の意思決定や信頼性についての情報を提供していくようです。

SLA-Readyは、ヨーロッパのクラウドマーケットの信頼性を構築することに貢献していくことになるようです。今後の動向に注力していきたいと思います。なお、CSAも、このコンソーシアムのメンバーですので、今後CSAがどのように関わっていくかも見ていきたいと思います。

SLA-Readyの情報は、http://www.sla-ready.eu/　で提供されていますので、今後の動向も含めて参照してください。