タグ別アーカイブ: SDP

SPA （Single Packet Authorization）解説

2019年8月27日
CSAジャパン
諸角　昌宏

本ブログは、SDP(Software Defined Perimeter)の中核の技術であるSPA （Single Packet Authorization）が、どのようにゼロトラスト環境で有効であるかについて説明します。特に、インターネット上に安全なサービスを提供するため、認証が取れるまでは全てのアクセスを拒否する”Deny-ALL”が、どのように実現できているかについて説明します。

インターネットのアクセスにおける課題とSPA

リクエスト-レスポンス型であるインターネットのアクセス方法は、クライアントからのリクエストを受け取るために必ず口（ポート）を開けて待っています。これは、正しいユーザだけでなく、悪意のある人にも開いているということで、セキュリティ上の問題を引き超す可能性を高めています。悪意のある人は、ポートスキャン等を行って、インターネット上に開いているポートを探し、それに紐づくサービスを特定し、そのサービスの脆弱性を突いて攻撃を仕掛けることができます。また、開いているポートに対してSYNフラッド攻撃によりDoS/DDoS攻撃を行い、サーバを接続不能にすることができます。
このようにインターネットがもともと抱えている課題に対して、アクセスが許可されるまでは全てのポートを閉じておくという、いわゆる”Deny-All”を実現することで対処することが求められています。このための方法として、大きく以下の2つがあります：

ポートノッキング
SPA

これらについて、以下で説明していきます。

ポートノッキング

ポートノッキングは、決められたポートを決められた順番でアクセスすることでファイアーウォールに穴を空ける仕組みです。例えば、ポート1000、2000、3000に対して順番にTCP SYNパケットを送った場合のみ、ポート22 (SSH) へのアクセスが許可されるというような設定ができる機能になります。この場合、最初の状態ではポート22は閉じられており、ポートノッキングに定義されたTCP SYNのシーケンスが来た時のみ、一定時間ポート22を開放します。クライアントは、この開放している時間内にポート22に対してアクセスすることで接続できます。これにより、通常はDeny-Allの状態を維持しつつ、決められたポート番号に決められた順番でパケットが送られてきた時のみアクセスを許可するということが実現できます。

したがって、ポートノッキングには以下のようなメリットがあります。

パケットはデフォルト・ドロップ
サーバに送られてくるパケットは、デフォルトでは全てドロップすることが可能になります。つまり、Deny-allを実現できます。これにより、サーバが提供しているサービスを非可視化することができ、サービス自体を悪意のあるアクセスから保護することができます。
ポートスキャンしても空きポートを見つけることができない
悪意のある攻撃者がポートスキャンを行っても、開いているポートや稼働しているサービスを見つけることができません。したがって、悪意のある攻撃が非常に困難になります。
DoS/DDoS攻撃を最小化できる
ポートノッキング用のシーケンスにならないパケットは全てドロップされますので、SYNフラッド攻撃のようにもともと開いているポートに対する攻撃を行うことができなくなります。

一方、ポートノッキングには以下のようなセキュリティ上の問題があります。

リプレイ攻撃に弱い
ポートノッキングに利用するパケットは、暗号化されずにそのままネットワーク上を流れます。したがって、ネットワークを盗聴し、クライアントからのパケット・シーケンスをそのまま送ることで接続できてしまいます。
悪意のある第三者によるポートノック用のシーケンスの破壊
正しいクライアントに代わってポートノック用のシーケンスの一部を送ることで、シーケンスそのものを破壊することができます。
IDSあるいはポートスキャンによるポートノック用のシーケンスの探索
ポートノック用のシーケンスは一連のパケットの流れになるので探索が可能です。

SPA

SPAは、ポートノッキングの利点を持ちながら、ポートノッキングの課題に対処したものになります。” Software-Defined Perimeter: Architecture Guide”では、SDPの最も重要な要素の1つである「接続前認証（authenticate-before connect）」を実現するために、SPAを通してこれを実現していると述べています。また、このガイドでは、SPAはデバイスまたはユーザの身元を検証し、それから追加のアクセス制御を実施するシステムコンポーネント（コントローラまたはゲートウェイ）へのネットワークアクセスを許可するだけの軽量プロトコルで、これは、TCP / IPの根本的にオープンな（そして安全でない）性質を補うものとしています。SPAにより、要求者のIPアドレスを含むリクエスト情報は、単一のネットワークメッセージの中で暗号化および認証が行われ、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができます。

SPAはプロトコルとして、SDP 1.0の中に仕様として記述されていますが、従わなければならないというような厳格な仕様では無いようです。したがって、SPAは実装の仕方においていくつかの異なる方法が取られています。ただし、SPAを実装するにあたっては、以下の3つの共通の原則を備えることを要求しています。

SPAパケットは、暗号化し、認証機能を持たなければならない。
SPAパケットは、必要な情報をすべて１つのパケットの中に含めなければならない。
SPAパケットを受け取ったサーバは、応答しないし、何も送信しない。

ここでは、SPAの実装方法を説明するにあたって、fwknopが提供するオープンソフトウエアを参照します。これは、LINUX JOURNAL Issue #156, April 2007 ” Single Packet Authorization fills the gaps in port knocking.”の内容を元にしてします。

SPAパケットの構成
fwknopが用いるSPAのパケットは、以下の構成になります。
- 16バイトのランダムデータ
- クライアント・ユーザ名
- クライアント・タイムスタンプ
- fwknop　バージョン
- モード (アクセス、あるいは、コマンド)
- アクセス (あるいは、コマンドストリング)
- MD5　チェックサム

これらのフィールドの内容について以下に説明します：

16バイトのランダムデータ、および、MD5　チェックサム
16バイトのランダムデータを含み、パケット全体のMD5チェックサムを持つことで、１つ１つのSPAパケットが必ずユニークになることを保証します。これにより、サーバ側では、以前来たことのあるパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
クライアント・ユーザ名、クライアント・タイムスタンプ
クライアント・ユーザ名、クライアント・タイムスタンプは、もう一段のレベルの認証・認可をサーバ側で行うのに用いられます。
fwknop　バージョン
fwknopとして、SPAのバージョン管理、特にバックワード互換性に用いられます。
モードとアクセス
サーバ側に、クライアントからの要求が、サービスへのアクセスなのかコマンドの実行なのかを示します。たとえば、SPAでコネクションが許可された後、SSH（TCPポート22）のアクセスを許可するように設定できます。アクセスの場合には、アクセス・フィールドに直接ストリングを含めます。

この例を元に、SPAの特徴をまとめると以下になります：

Deny-Allの実現
SPAパケットがクライアントからサーバに送られても、サーバがこれに応答することはありません。サーバは単にネットワーク上送られてくるパケットをスキャンする（たとえばlibpcapなど）だけで、SPAパケットでないものは全てドロップし、SPAパケットを受け取ると、その内容に基づいてクライアントとの接続を許可するかどうかを判断します。
リプレイ攻撃への対処
上記の例では、1パケットの中に16バイトのランダムデータを含み、全体のパケットのハッシュ値を入れています。これにより、SPAパケットがユニークになることを保証します。サーバ側では、今まで来たパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
DDoS攻撃への対処
Deny-Allであること、また、SPAパケットは1パケットであり、シーケンスではないことにより、DDoS攻撃の可能性を非常に下げることができます。
パケット・シーケンスの探索や破壊への対応
SPAパケットは1パケットであることから、スプーフィングしたり解析したりすることが難しくなります。
様々な認証情報の送信が可能
SPAパケットの中には、様々な情報を含めることが可能なため、クライアントのユーザ名など、ユーザに対応した追加の認証等の処理が可能になります。

以上のように、SPAは、ポートノッキングのメリットを維持しつつ、課題を解決し、ゼロトラスト環境における最適なネットワーク環境を提供できるものと考えています。また、ここでは触れませんが、SDPが他に提供している機能(mTLS等)とSPAが組み合わされることにより、ゼロトラスト環境におけるさらに強固なネットワークセキュリティが提供できます。

なお、SPAは、fwknopからオープンソースとして提供されていますので、さらに理解を深めていただければと思います。

本当のSDPよ立ち上がれ！ ~ Will the real SDP please stand up?

コメントをどうぞ

本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。

本当のSDPよ立ち上がれ！

原文：　2019年7月10日
日本語版：　2019年7月23日

Software Defined Perimeter（SDP）という用語は、ゼロトラスト（Zero Trust）モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス（CSA）によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント（PDP）とポリシー実行ポイント（PEP）モデルになります。SDPの認証プロセスにおいては、「コントローラ（Controller）」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ（Gateway）」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

通信前の認証

SDPのもう1つのユニークな要素はSingle Packet Authorization（SPA）です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

SDPはどのくらい強力ですか？

2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

原文 “Will the real SDP please stand up?” は、こちらを参照してください。

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

SDPと2015年度データ漏洩/侵害調査報告書の報告（第13回CSA勉強会）

コメントをどうぞ

SDPと2015年度データ漏洩/侵害調査報告書の報告（第13回CSA勉強会）

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

６月29日に行われた第13回CSA勉強会について報告します。テーマは、「SDPと２０１５年度データ漏洩/侵害調査報告書」ということで、ベライゾンジャパンの皆様に講師をやっていただきました。SDPは、Software Defined Perimeterということで、５月のCSA Summit Japan 2015でJim　Reavisが触れていたクラウドセキュリティの新しい潮流の１つです。ベライゾンは、SDP仕様書V1.0の作成を中心となって行っており、SDPに関しては事例も含めて先進的に進めている会社になります。また、ベライゾンはセキュリティの調査レポートを毎年出しており、今回は8回目として”2015 DATA BREACH INVESTIGATIONS REPORT”を公開しています。

それでは、まずSDPについて勉強会の内容を報告します。

そもそもSDPとは？ということですが、”Temporal Network”ということで「一時的なネットワーク」という表現をされています。つまり、伝統的な固定ネットワークではなく、ダイナミックに接続先が決まることで攻撃のターゲットが明確にならないようにして守っていくという手法になっています。個人的には別のスライドで使われていた” Secure Non Discoverable Network”、つまりデバイスやIDが認証されるまでネットワーク上で見ることができないという表現の方がわかり易い感じがしますが、いずれにしろ、サーバのどこにアクセスするかは認証して接続するまで決まらないことでネットワーク上のセキュリティを保つためのアーキテクチャということになります。以下のような特徴を持っています。

ネットワークベースの攻撃からアプリケーションを守るためのセキュリティ・フレームワーク
“Need-To-Know”という形で、ダイナミックなネットワーク構築に基づいた「必要な時」に接続するモデル
DNSやIPアドレスをあらかじめ見せない

また、SDPは既存の標準に基づいて設計されているため、非常に安定したものであるということが言えます。また、CSAがオープンスタンダードとして使用を公開しているため、誰でも利用することができます。

さて、実際にSDPがどのように動作するかということですが、簡単に言うと以下の流れになります：

デバイス(ブラウザなど)から、SDP Controllerにアクセス
デバイスの認証を実施
ユーザ認証および使用するアプリケーションの認可を確認
アプリケーション・サーバをダイナミックにプロビジョニング
デバイスがアプリケーションを利用

勉強会では、SDPを用いたいくつかの事例について紹介されました。また、CSA Conferenceで行われたハッカソンについての説明もあり、世界中からの150億アタックに対して、一度も破られなかったということでした。また、勉強会参加者から、SDPのユーザーズガイドやインプリメンテーションガイドが欲しいという意見、SDP Controllerでのポリシー管理に対する質問等が出され、活発なディスカッションになりました。今後、CSAジャパンを中心として幅広い情報共有や実装に向けての議論を進めることが必要であることを感じました。

次に、２０１５年度データ漏洩/侵害調査報告書について報告します。

まず、ベライゾンが強調していたのは、実際のデータに基づいたレポートとなっている点です。一般的に、このようなレポートはアンケート結果に基づくものがほとんどで、データに基づいた調査結果であり非常に信頼性が高いということができるようです。2015年の情報漏洩データとして、2,122件の漏洩事故および79,790件のセキュリティインシデントを分析したとのことで、特に今回はJPCERTのデータとして日本でのデータを含めたレポートとなっているとのことです。

この中で、いくつか特徴的な点として感じた点を以下にあげます。

フィッシングメールへの対応フィッシングメールの添付ファイルをクリックする確率が11%ということで、10通送れば1通は開かれるという状況とのことで、攻撃者から見ると非常に効率的な攻め方のようです。対策として最も重要なのはトレーニングで、セキュリティ対策では人が最終的な検知装置であることを認識する必要があるとのことです。
脆弱性脆弱性を突いた攻撃の97%は、わずか10個の脆弱性に対する攻撃だそうです。さらに、攻撃の99.9%が、CVEの公表から1年以上経過したものだそうです。脆弱性に関する情報をきちんと入手および管理することと、パッチ適用などの伝統的な対策をきちんと行うことが重要になります。
情報漏洩情報漏洩の原因として、Webアプリケーションを狙った攻撃はかなり少なくなっていて、反対に人をターゲットにした攻撃が増えていて、全体の90%以上を占めているとのことです。
業界業界別では、製造業、小売業に対する攻撃が目立っているとのことです。また、教育機関への攻撃も多いとのことです。

その他、実際のデータに基づく非常に詳細な分析が行われています。このレポートの日本語版も近々公開されるとのことですので、期待したいと思います。

以上、非常に概略になりますが、勉強会の報告といたします。

CSA Japan Summit 2015　を終えて

コメントをどうぞ

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

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

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

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

クラウドの利用を支える新しい技術
企業がクラウドを使っていく場合、もはや、「パブリックは危険」で「プライベートは高価」という概念を取り払う段階に来ているようである。パブリッククラウド環境にプライベートクラウドを構築するバーチャルプライベートクラウドを用いて、如何に安全にクラウドに移行するかを考えていくことが重要である。ソニー銀行の大久保光伸氏の講演では、銀行業務のかなりの部分をAWS VPCに移行させた事例を紹介していた。信頼が非常に重要な銀行業務においてクラウド化を実現した理由は、限られたIT予算内で「固定的ITコスト」を減らし「戦略的ITコスト」に振り向けることとのことであった。以前からクラウドに移行するメリットとして挙げられている理由ではあるが、銀行という業種の言葉として非常に重みを感じる。AWS VPCが信頼できるプラットフォームとして選ばれた理由は、ISO27001とFISCの安全対策基準に準拠しているということであった。どのような形でプロバイダを選定するかについて、吉井和明氏の講演では、「利用者側で、事業者側を管理することや責任を取ることはかなり難しい。利用者側ができることは、リスク軽減の考え方に基づいてクラウドの選択を行うことが重要である。経産省/金融庁等のガイドラインやCSA　STARなどを使ってプロバイダの能力を判断することが最良の策である。」とのことであった。このように、バーチャルプライベートクラウドを積極的に利用していくこと、またそのためのセキュリティ対策をきちんと行うことが今後のビジネスにおいて重要になると思われる。
クラウドセキュリティを支える新たなソリューション
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を提供しており、クラウド環境での新たなセキュリティ対策として注目していきたい。バーチャルプライベートクラウドにより、機密性の高い業務をクラウド化することが十分現実味をおびてきている。一方、クラウドに対するセキュリティ技術自体も進化している。アンテナを高く張って、クラウドを安全に使う技術を習得し続ける必要がある。
IoTの動向とセキュリティ
今回のSummitにおけるメインテーマの１つがIoTであった。IoTは、最近流行りのバズワードと思われる点もあるが、森川博之氏によると、バズワードでは終わらないということであった。それは、データが集まれば、様々な産業が集まり、今までなかったもののデータが重要になり、これを扱うIoT自体が、産業セグメントを変えていくということである。特に、IoTが大きな影響を与える分野として、医療（医療に関しては、日本が世界で最大のデータを持っている）、土木系（地すべり対策としてセンサーを設置するなど）など、今までは経験と勘に頼っていたものに新たにデータが加わってくることで生産性の低い分野にチャンスを与えることになるということである。講演タイトルの「未来を創るIoT」において必要とされることについては、「フィールド志向」と「デザイン能力」とのことであった。IoTで最も重要なのはユーザ企業。現場で使っているものを理解する必要がある。自分で飛び込んでいって解決させていく「フィールド志向」が必要になる。また、従来必要とされた能力である「考える、試す」に対して、これから必要とされる能力は、「気づく（柔軟な発想）、伝える（説明の仕方によりインパクトが違ってくる）」ということで、この「デザイン能力」を意識的に磨いていくことが重要とのことである。

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

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

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

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

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