タグ別アーカイブ: 暗号化

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

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

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の2重キー暗号化 (Double Key Encryption) 、 Google Cloud External Key Manager、Salesforceキャッシュのみの鍵サービス(Cache-Only Key)などがあり、主なプロバイダーが提供している。

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

  1. 利用者鍵管理(HYOK)の動作例

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

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

    • 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. 暗号化の代替手段

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

  • トークン化

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

  • 完全準同型暗号

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

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

以上

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

以上

 

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レポートのブログのまとめにしたいと思います。どうもありがとうございました。

 

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

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

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

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

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

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