Authorization)が、どのようにゼロトラスト環境で有効であるかについて説明します。インターネット上に安全なサービスを提供するため、認証が取れるまでは全てのアクセスを拒否する”Deny-ALL”が、どのように実現できているかについて説明します。インターネットのアクセスにおける課題とSPAリクエスト-レスポンス型であるインターネットのアクセス方法は、クライアントからのリクエストを受け取るために必ず口(ポート)を開けて待っています。これは、正しいユーザだけでなく、悪意のある人にも開いているということで、セキュリティ上の問題を引き超す可能性を高めています。悪意のある人は、ポートスキャン等を行って、インターネット上に開いているポートを探し、それに紐づくサービスを特定し、そのサービスの脆弱性を突いて攻撃を仕掛けることができます。開いているポートに対してSYNフラッド攻撃によりDoS/DDoS攻撃を行い、サーバを接続不能にすることができます。このようにインターネットがもともと抱えている課題に対して、アクセスが許可されるまでは全てのポートを閉じておくという、いわゆる”Deny-All”を実現することで対処することが求められています。このための方法として、大きく以下の2つがあります:ポートノッキングSPAこれらについて、以下で説明していきます。ポートノッキングポートノッキングは、決められたポートを決められた順番でアクセスすることでファイアーウォールに穴を空ける仕組みです。アクセスが許可されるというような設定ができる機能になります。SYNのシーケンスが来た時のみ、一定時間ポート22を開放します。クライアントは、この開放している時間内にポート22に対してアクセスすることで接続できます。これにより、通常はDeny-Allの状態を維持しつつ、決められたポート番号に決められた順番でパケットが送られてきた時のみアクセスを許可するということが実現できます。したがって、ポートノッキングには以下のようなメリットがあります。パケットはデフォルト・ドロップサーバに送られてくるパケットは、デフォルトでは全てドロップすることが可能になります。Deny-allを実現できます。これにより、サーバが提供しているサービスを非可視化することができ、サービス自体を悪意のあるアクセスから保護することができます。ポートスキャンしても空きポートを見つけることができない悪意のある攻撃者がポートスキャンを行っても、開いているポートや稼働しているサービスを見つけることができません。したがって、悪意のある攻撃が非常に困難になります。DoS/DDoS攻撃を最小化できるポートノッキング用のシーケンスにならないパケットは全てドロップされますので、SYNフラッド攻撃のようにもともと開いているポートに対する攻撃を行うことができなくなります。ポートノッキングには以下のようなセキュリティ上の問題があります。リプレイ攻撃に弱いポートノッキングに利用するパケットは、暗号化されずにそのままネットワーク上を流れます。したがって、ネットワークを盗聴し、クライアントからのパケット・シーケンスをそのまま送ることで接続できてしまいます。正しいクライアントに代わってポートノック用のシーケンスの一部を送ることで、シーケンスそのものを破壊することができます。IDSあるいはポートスキャンによるポートノック用のシーケンスの探索ポートノック用のシーケンスは一連のパケットの流れになるので探索が可能です。SPASPAは、ポートノッキングの利点を持ちながら、ポートノッキングの課題に対処したものになります。connect)」を実現するために、SPAを通してこれを実現していると述べています。IPの根本的にオープンな(そして安全でない)性質を補うものとしています。SPAにより、要求者のIPアドレスを含むリクエスト情報は、単一のネットワークメッセージの中で暗号化および認証が行われ、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができます。1.0の中に仕様として記述されていますが、従わなければならないというような厳格な仕様では無いようです。したがって、SPAは実装の仕方においていくつかの異なる方法が取られています。SPAを実装するにあたっては、以下の3つの共通の原則を備えることを要求しています。SPAパケットは、暗号化し、認証機能を持たなければならない。SPAパケットは、必要な情報をすべて1つのパケットの中に含めなければならない。SPAパケットを受け取ったサーバは、応答しないし、何も送信しない。ここでは、SPAの実装方法を説明するにあたって、fwknopが提供するオープンソフトウエアを参照します。knocking.”の内容を元にしてします。SPAパケットの構成fwknopが用いるSPAのパケットは、以下の構成になります。チェックサム16バイトのランダムデータを含み、パケット全体のMD5チェックサムを持つことで、1つ1つのSPAパケットが必ずユニークになることを保証します。これにより、サーバ側では、以前来たことのあるパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。クライアント・ユーザ名、クライアント・タイムスタンプクライアント・ユーザ名、クライアント・タイムスタンプは、もう一段のレベルの認証・認可をサーバ側で行うのに用いられます。バージョン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からオープンソースとして提供されていますので、さらに理解を深めていただければと思います。仁2019年8月21日はじめに法人化から5年が経過、CSAジャパンは2019年(令和元年)度の取り組み目標の一つにWG活動等の「多拠点化へのチャレンジ」を掲げ、その第一弾として「関西支部」活動が新年度(本年6月)より本格スタートした。関西支部は、CSAジャパンの事業内容やワーキンググループ(WG)活動等に関して、関西地域における紹介や認知度向上をその活動目的とする。関西地域のクラウドユーザーが有する潜在的交流ニーズの受け皿として、国内「面展開」の試金石となる。上記を受け、7月11日(木)午後より、広大な大阪城公園と壮大な天守閣を窓から眼下に一望できる(図1)、大阪ビジネスパークのクリスタルタワー20階E会議室を会場(図2)として、関西支部キックオフセミナーが開催された。仁(※本レポート筆者)本年は観測史上最も遅い梅雨入りとなり、あいにく当日午後の天候は小雨模様となった。官公庁関連団体などから幅広く、クラウドサービス導入やセキュリティ対策に関心をお持ちの参加者46名のご来場を得た。本稿前編では、上記講演プログラム1(基調講演:今後のデータ政策の展開とクラウドサービスの安全性評価について)に関する所感報告について以下に述べる。商務情報政策局の関根氏より、データ政策とクラウドサービスの安全性評価制度の検討状況に関してご講演いただいた。2019(本年5月15日開催/会場:東京大学伊藤謝恩ホール)の招待講演プログラムで、同省の松田洋平氏から事前に講演いただいた内容に通じ、これに近時のパブリックコメントの集約状況等をアップデートの上、関西地域のユーザーへも是非とも聴講機会を頂戴したいとの当会依頼に対し、ご快諾いただいたものである。Trust)の展開2クラウド・バイ・デフォルト原則とクラウドサービス安全性評価制度の検討状況、からなる。Trust)は、本年1月23日開催の世界経済フォーラム年次総会(ダボス会議)で日本の安倍総理により提唱された「信頼性のある自由なデータ流通」を促進するコンセプトである。国際的なデータ流通網を構築し、データの囲い込みを防止してその活用最大化を目指すものである。2019で大阪トラック立ち上げ宣言として盛り込まれたこともあり、参加者の関心は高かった様に思われる。ここでの主な論点は、DFFTによる国際的なデジタル経済の成長促進とプライバシーやセキュリティの確保とのバランスをいかに図っていくかにある。これへの対策として、個人情報や知的財産等の安全性確保に向けた個人情報保護法の3年毎の見直し、現行ペナルティのあり方、外国事業者に対する法執行の域外適用や越境移転のあり方、また各国の関係法制度との相互運用性の確保等が検討されていることが説明された。クラウド・バイ・デフォルト原則は、2018年6月に「政府情報システムにおけるクラウドサービスの利用に係る基本方針」として採用された「クラウドサービスの利用を第一候補として政府情報システムの検討を行う」とするものである。その一方で、適切なセキュリティ管理への懸念等から、(とりわけ)政府におけるクラウドサービス導入が円滑に進んでいない現状を鑑み、官民双方においてクラウドサービスの安全性評価の仕組みの必要性が掲げられている。「サイバーセキュリティ戦略」(2018年7月27日閣議決定)において、政府プライベートクラウドとしての「政府共通プラットフォーム」への移行の推進が掲げられた。これらを受け、経済産業省と総務省で「クラウドサービスの安全性評価に関する検討会・WG」が2018年8月から複数回開催されるとともに、本年3月16日から4月16日にかけて、中間とりまとめ(案)のパブリックコメントが実施されている。情報処理推進機構/IPA)も名を連ねている。本評価制度は、政府調達における利用を第一に想定しつつ、民間の特に情報セキュリティ対策が重要となることが想定される重要産業分野等においても、検討結果の活用推奨が目されている。ダイレクトに関西ユーザーに対して、取り組み最新状況についてお伝えいただく機会を設定できたことは幸いに思う。参加者からの活発な質疑に対し逐一懇切丁寧に応答いただき、セミナー後の懇親会(立食式)までお付き合いいただいた関根氏に、この場であらためて深く感謝の意を表したい。余談であるが、本セミナー開催から日を置かずに、某海外大手クラウドサービス事業者が上述の「政府共通プラットフォーム」に採用決定との報道が流れた。これに対し今後の世論において、様々な観点から議論が惹起されるであろうと予測される。Recap)、及び関西支部の今後の展望について、本稿後編に続く。Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。Trust)モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント(PDP)とポリシー実行ポイント(PEP)モデルになります。SDPの認証プロセスにおいては、「コントローラ(Controller)」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ(Gateway)」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。Authorization(SPA)です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。こちらを参照してください。慎太郎(個人会員)「シャドーIT」という言葉を見かけることがあります。IT部門が知らぬ間に導入されるITシステムを指すようです。シャドーITを発見するための道具としてCASBが紹介されることもあります。個人的にはこの単語には違和感を覚えます。デジタルトランスフォーメーション(DX)が喧伝され、RPAなど企業活動におけるIT依存が高まる中、すべてのITシステムをIT部門が開発・調達することは現実的ではないでしょう。シャドーというと良からぬ響きを与えますが、事業部門や機能部門の自律的なIT利活用は、むしろ推奨されても不思議ではありません。政府のサイバーセキュリティ戦略本部は「サイバーセキュリティ人材育成プログラム」(2017年4月18日)の中で、「新しいITの利活用における体制例」を掲げました(p.8)。そこでは、事業部門がIT部門を介さず、直接ベンダー企業やクラウド事業者と契約してITを利活用する姿が描かれています。サイバーセキュリティ戦略本部「サイバーセキュリティ人材育成プログラム」(2017)上の文書を読んだとき、20年以上前に橋本内閣の下で「金融ビッグバン」として実行された金融規制改革を私は想起しました。旗印にして改革を推進した当時の課題意識が、現在の企業においてIT利活用を推進する際の課題意識と重なって見えたのです。デジタルトランスフォーメーションの実現には、IT規制改革が不可欠だと思わされました。規制改革の基本は、事前規制から事後チェックへとコントロールの力点を移すことです。そのためには、(裁量ではなく)明快なルールと適切な証跡とを必要とします。各部門の自律的なIT利活用が進めば、企業が利用するクラウドサービスの数は自然と増大するでしょう。CASBを追加的なセキュリティ対策とみなすよりも、事前規制を緩和してIT利活用を促進するために必要な措置だと考えるほうが適切かもしれません。次回は、事前規制の緩和にCASBを利用する方法を検討します。その業務と関係するものではありません。WG外の識者の意見を参考に筆を進めたい。取り上げるのは、CSAジャパンの連携会員であるJNSAが発行するメルマガにて寄稿された「原則と現状のはざまで」と題するコラムである。セキュリティアーキテクトを務めておられる高橋氏である。ここで高橋氏は、IT・セキュリティに関わる原則(ポリシーやガイドライン等)の現状との乖離を指摘している。一般的なセキュリティアーキテクチャ、セキュリティポリシーは、そもそも10~20年前に確立した原則に基づくことが多い。ところが今やクラウドサービスに代表される最新テクノロジーについて、これを採用しない(あるいは大幅遅延)ことは、逆に事業運営の観点で経営リスクともなる。ITシステムがクラウド化することで、ベンダー、代理店やSIer、ユーザー(企業)の責任分界点が変化し、特にユーザーに求められるスキルが変わっている。いった変化を見落としてしまうことにより、セキュリティの原則と現状に乖離が発生しているのではないかというご指摘である。3つのクラウドアーキテクチャ(IaaS、PaaS、SaaS)のそれぞれの責任境界については、CSA発行のガイダンスはじめ、クラウド利用の原則として良く取り上げられるところであるが、高橋氏はユーザー企業の立場によるリスク負担について言及しておられる。この状況にCASBが何か貢献できないか、いくつかケースを想定してみた。・あるクラウドサービスが、信頼に足るかどうかを判定(自組織の要求事項を満たすかどうかの判断)・特定のクラウドサービス利用状況についての詳細モニタリング・その中でも不適切と思われる操作を強制的に停止・中断こういったケースではクラウドサービスの採用においてCASBが一定のリスクヘッジを実現し、クラウド活用を促進することができるように思われる。以下に全文を引用するのでぜひご一読頂き、各組織においてどうなのか一度ご検討、ご判断を頂ければ幸いである。本稿の引用を快諾頂いた高橋氏、JNSA事務局にはこの場を借りて御礼申し上げます。私が強く印象に残っている発言に、「IT・セキュリティ部門は提案を止めるだけなので、提案の際には、IT部門やセキュリティ部門ではなく、事業部門に提案をすべき」というものがある。衝撃的な話ではあるが、企業等の組織において、IT部門やセキュリティ部門が邪魔になっている。本稿では、この要因と考える、IT・セキュリティに関わる原則(ポリシーやガイドライン等)の現状との乖離について取り上げたい。これまで、20年近くベンダー側の立場でセキュリティに関わってきたが、昨年10月からユーザー企業のセキュリティ担当として働き始めている。同様に必要不可欠な専門職であると強く感じている。日々、多様な判断が求められるが、十分な知見が得られないまま判断せざる得ない場合も少なくない。適切にセキュリティ業務を行うための原則の重要性を認識する一方で、原則と現状の乖離が深刻な阻害要因になることも実感している。原則と現状の乖離の要因として、PDCAが「Plan通りにDoが行われていることをCheckし、必要なActを行う」として運用され、Planのチェックを行わない状況がある。このため、優れた新たな施策があっても、これまでの原則に従い採用を見送ることで、原則と現状の乖離が生じていく。Availability)に基づいたリスク分析では不十分で、事業リスクに基づいた「新たな施策を採用しない(事業)リスク」についても分析する必要がある。新たな施策の代表的な例としてクラウドサービスがある。ベンダー側の立場でクラウドファーストという言葉を使ってきたが、市場は明らかにクラウドファーストになっており、新たなクラウドサービス利用の相談を頻繁に受けている。その際に、セキュリティ対策状況分析を代理店に頼りたくなるが、日本に代理店が無い場合や代理店経由では適切な回答が得られない事があり、何よりも、代理店に頼っていては、すぐに使い始めたいという社内の要求に応えることができない。結局のところ、自分でWebや試用版を使って確認し判断することが求められる。ITシステムがクラウド化したことで、ベンダー、代理店やSIer、ユーザー(企業)の責任分界点が変化し、特にユーザーに求められるスキルが変わっている。この変化を見落とすことが原則と現状の乖離の要因となっている。原則と現状の乖離の問題については、ふたつの取り組みを行っている。CISO支援ワーキンググループの活動である。活動をはじめて既に2年が経過してしまったが、本年度中(2018年3月)のドキュメント公開を目指して作業を進めている。論会でこのテーマを取り上げ、有識者の意見を伺い議論を進めており、3月17日に開催する公開討論会でも、このテーマを取り上げていく。JSSMセキュリティ公開討論会のお知らせhttp://www.jssm.net/wp/?page_id=2880近年求められる情報セキュリティは、ITや経営と密接な関係にあり、その背景には、IT環境の大きな変革がある。セキュリティ対策は10~20年前のIT環境が前提であることも少なくない。現在の経営やITに沿ったセキュリティ対策を提案し実践していくことが必要だと感じている。連載リレーコラム、ここまで。その業務と関係するものではありません。今回は、先日NTTテクノクロスが実施した、企業におけるクラウドセキュリティに関するアンケートの結果を紹介していく。「2020年までに、大企業の60%がCASBを使用※1」「クラウドセキュリティ市場は2021年に208億円に※2」など、クラウドセキュリティ分野では、これまで数多くのポジティブな市場予測が発表されてきた。実際にグローバル企業などのクラウドセキュリティについての意識が高いアーリーアダプターを中心に、日本でもCASB市場が大きく成長してきている。マジョリティに当たる一般的な日本の企業におけるクラウドサービス利用の実態についての統計的な情報としては、総務省が毎年発表している情報通信白書以外にほとんど存在しないという状況であった。日本の企業が実際にどのようなクラウドサービスを使っているのか、マルチクラウド利用は進んでいるのか、クラウドセキュリティに対する意識はどうなっているか、大企業と中小企業ではどのような違いが生じているのか。いった生の情報が不足していたことから、今回、NTTテクノクロスではクラウドサービス利用状況の実態を調査するに至った。Japanで公開されているホワイトペーパー(URL:https://japan.zdnet.com/paper/30001048/30002673/)を参考にされたい。本コラムでは、特徴的なポイントのみ紹介する。設問2『選択肢の中にご利用中のクラウドサービス名(SaaS)があれば、教えてください』に対する回答は、1000名以上の企業と1000名未満の企業で回答の傾向に大きな差が生じた。365)」首位を逆転するといった具合だ。名以上では「Box」の回答割合が多くなるなど、類似サービスの中でも企業規模による利用傾向の違いが見える結果となった。コスト面やセキュリティ面など、クラウドサービスの評価基準が企業規模によって異なるであろうことは予想できたものの、これほど如実に数字として表れたことは非常に興味深い結果となった。設問6は、「利用が認められていない」クラウドサービスを、実際に社員が利用している、いわゆる「シャドーIT」が自社で発生しているという状況を認識している回答者に対して、『どうお考えですか』と質問した結果だが、「セキュリティのリスクがある」という認識を持つ回答が8割程度ではあったものの、そのうちの半分強にあたる42%の回答が「セキュリティリスクはあるが、自己責任の範囲で注意して利用すれば問題ないと考えている」と考える“自己責任派“であった。CASBによるシャドーIT対策の必要性について重要なポイントの一つとして、「会社のルールでクラウドサービスの利用を禁止すると、従業員は代替のサービスや手段を探して利用する可能性があるため、さらにセキュリティリスクが増す(そのため、禁止するのではなく可視化して統制すべきである)」という考え方があるが、まさにそのような人間心理を裏付けるような結果となり、CASBが実現する「シャドーITは、可視化して統制すべきである」といった対策が有効であることが伺える結果となった。ある「CASB」をご存知ですか?』という質問を投げ掛けたが、63%が「知らない」という回答であり、認知している回答者は37%という結果であった。セキュリティ分野における専門用語の一般的な認知度としてはまずまずである、と評価する見方もあるが、職種として「情報システム関連職」が5割を超えているという回答者の属性を踏まえると、CASBというクラウドセキュリティ対策はもっと認知されるべき存在である。今後も、WGの活動等を通じてCASBを啓蒙していくことの必要性を感じる結果となった。■終わりにセキュリティ分野のもう一つのトピックとして、NTTテクノクロスでは、昨年に引き続き「サイバーセキュリティトレンド2018」(URL:https://www.ntt-tx.co.jp/products/cs-trend/)を公開した。変化し続けるサイバーセキュリティの「今」を知ることができる資料となっている。こちらも無料でダウンロード可能となっているので、是非ご一読願いたい。目を通して頂いている読者の皆様は、CASBもしくはクラウドセキュリティ全般にご興味のある方と思います。CSAジャパンのCASB-WGは発足からちょうど2年、CSAグローバルに上位活動を持たないCSAジャパンとしての独自活動を展開して参りました。1年程前には、日本国内でのCASB理解に一石を投じるべく、独自に執筆したホワイトペーパーをリリースしました。(こちらからダウンロードできます)。それから1年、市場でもCASBに関する話題には事欠きませんでした。Quadrantの初版をリリースしました。Networksを買収する、といったニュースが飛び込んできました。今やCASBというキーワードは一般化し、ますますホットなものになってきたと言えるでしょう。悩ましいのはベンダやプレイヤーも増加する中で、当初Gartner社が提唱してきたコンセプトとは少しずつ違った切り口での情報も目に付くようになってきたことです。いった変化自体はGartner社自身が認めていることでもあり、新技術の定着過程において起こりがちなことでもあります。これは良い意味では、Gartner社の「コンセプトありき」という段階から、より実地に即したものに進化してきたと見ることができるでしょう。ホワイトペーパーのような一元的な情報編纂の取り組みについては、その完成時には環境変化により、あるいは物足りないものとなってしまう懸念があることも事実です。そこでCASB-WGとしては、タイムリー、コンパクト、かつ多様性のある情報発信を意図し、これから数回に分けて本ブログにてリレーコラムとして記事をアップしていくことと致しました。観点で執筆していく予定となっております。楽しみにして頂ければと思います。本ページは、リレーコラムのインデックスとなるよう以下にリンクを追加していきます。第9回クラウド利用者会議では、IoTのセキュリティに関わる課題というテーマで笠松氏にご説明いただいた。会議は、2月5日(月)に開催し、クラウド利用者を中心として9名(内1名はオンラインでの参加)に参加いただいた。含めて、エッジ及びクラウドのセキュリティの必要性また、IoTのセキュリティに対する国内の政策としてIoT推進コンソーシアムがあり、官民が連携して様々な活動を行っている。IoT推進コンソーシアムは、海外との連携も進めている。IoT推進コンソーシアムは開発ガイドラインの策定が主な目標であり、上記の課題にある開発・運用環境、プラットフォームとしてのセキュリティには踏み込めていないという印象がある。IoTに関する国際標準は、ISO/IEC15408として進められている。Critria等)の考え方で進められている。このような状況を受けて、笠松氏からIoTに絡む5つの課題が説明され、今後検討しなければいけない点として上げられた。これについては、以下の笠松氏のスライドを参照していただきたい。以上の説明に基づいて、スピーカーから提示された上記の課題に対して参加者からの質問および議論が行われた。IoTに関するIPAの取り組みについて議論となった。IPAでは、セキュリティとセイフティーの融合の観点から、実証検証、ケーススタディー等を通してリスクアセスメントに取り組んでいる。いわゆるSecurity-by-Designに基づくSTAMPモデルにより、システムの安全性に関するモデル化および分析方法を進めている。基本的には、開発者および利用者向けの取り組みになる。したがって、IoTの運用に関するセキュリティの課題は残ったままである。IoT環境においてエッジコンピューティングとしてスマートフォンが使われるケースが増えてきている。この課題は、誰でも容易に使える反面、多くのIoTがパスワードも含めデフォルト設定のまま出荷されている点、データオーナの許可なく通信傍受が容易である点などが問題となっている。2016年米国FBIが個人宅で殺人事件があった際、スマートスピーカを押収した事例は、音声のオーナは誰か、スマートスピーカのオーナは誰か、スマートススピーカ(仮に音声型IoTとする)の音声データに証拠能力があるのか、など運用時のルールが不明のまま市場から受け入れられていく社会的環境が容認される点、などが重大な課題ではないか。国境を越えるデータ流通についてeSIM(電子的に書き換え可能なSIM)がIoT基板PCBに半田付けされている製品が出回りだしている点は、パーマネントローミング規制をEUで制定すみだが、日本国内の運用・使用ルールは見当たらない。顔認証が実用段階となった現在、このようなIoT機器のデータ流通を運用する議論の場が、CSAにあっても良いのでは。RPAの導入がセキュリティに与える影響について議論となった。RPAが行ったことで問題が発生した場合どうなるのかということである。RPAの利用にあたっては、監査ログが必須なるが、そもそも捜査の範囲を明確にしないと監査自体が検証可能にならないという問題になる。すると、RPAになんでもかんでもやらせるということでは無く、行う操作自体を明確にして、後で検証できることが重要になる。できるだけ業務を絞り込んで、監査しやすくするということが重要になるということである。いう議論をしていくうちに、そもそもRPAはIoTなのかという話しになり、様々なモノをIoTでひとくくりに見ていくこと自体が無理ではないかという話しになった。モノの種類、特性ごとに個別に考えていく必要があり、RPAはRPAとして考えていかなければならないということになった。ビルや橋に埋められた100年IoTこの部分については時間の関係で、パワポ記載内容を読み上げるに留まった。サーバレスこの部分については時間の関係で、パワポ記載内容を読み上げるに留まった。以上のような議論のもと、今後CSAとしてどのように取り組んでいくかという話しになった。IoTの運用面のセキュリティの課題をどうするかということは、結局どのようにガバナンスを利かすかという問題になるということになった。RPA等、新しい技術に対してどのようにガバナンスを利かすか、GRCをどのようにしていくかについて、テーマを決めながら議論していくことが大切であり、CSAとしてワークショップを開きながら議論していくことが必要ということになった。会議は、8月23日(水)に開催し、クラウド利用者を中心として8名に参加いただいた。今回は、「CASBはクラウドセキュリティを救えるか」というテーマで、CASBの事例を中心に講演していただくとともに議論を行った。マクニカネットワークスの上田氏からCASBのおさらいということで、概要の説明を行っていただいた。最初に、CASBの基本である4つの柱(可視性、コンプライアンス、データ保護、脅威からの防御)について説明していただいた。NGFWなどが挙げられていた。ガートナーも認めているように、実際にはこれらの融合はあまり進んでおらず、CASBは独立した製品として維持されているようである。ガートナーは、2018年までに60%の企業がCASBを導入すると言っており、これは変わっていないようである。CASBの日本国内での認知度も確実に上がっているということで、実際の導入が進んでいるということが説明された。Downのアプローチが多いとのことである。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回は更新されているとのことである。日本のサービスについても、以前はなかなか回答が得られなかったが、最近はほとんど回答が返ってくる状況となっており、リスク評価については十分信頼できるものと考えられる。次に、GDPRとCASBについての質問が出た。GDPRで我々が非常に影響を受ける域外移転に関しては、CASBで管理できるわけではないが、域外移転データの管理に関して、CASBを監査に利用できるということである。それから、上記で紹介された事例等を見ていくと、CASBの導入は大企業に限られているのではないかということで、CASBを中小企業が積極的に利用できるようにするにはどうしたらよいかという議論になった。CASBというと、どうしてもコストの問題があり、中小企業が導入するのは厳しいということである。これについては、CASBとしての展開というよりは、中小企業向け支援サービスという展開が始まりつつあるということであった。より、中小企業でもCASBが利用できる道が開かれていく可能性があるということであった。以上のような会議となったが、CASBがクラウドセキュリティを守っていくソリューションとして、これから大きく伸びていくというのは間違いないようで、特に、クラウドアクセスポリシーの作成の観点からは、CASBが非常に強力なツールとなっていくようである。クラウドの利用については、もはや「セキュリティが不安なので導入には慎重」という時代ではなく、「クラウドを利用することを前提にセキュリティ対策を考える」という時代になっている。その中で、セキュリティを統一的に管理できる、まさにブローカーとしてのCASBは、重要な役割を担っていくということを強く感じた。今回、日本のCASBを代表する方々のお話が聞け、また、直接議論することができたことは非常に有意義であった。WGのアウトプットにも期待していきたい。第7回クラウド利用者会議では、BSIジャパン株式会社の中村良和氏に講演していただいた。会議は、6月27日(火)に開催し、クラウド利用者を中心として14名に参加いただいた。今回は、「クラウドセキュリティに対する日本の認証規格」について講演していただくとともに議論を行った。中村氏から、まず、日本の認証規格の状況について説明していただいた。クラウドセキュリティに関する認証規格は、日本では以下の2つが展開されている。2701827018は、パブリッククラウドにおけるプライバシのガイドラインを提供している。本規格の認証については認定機関が認証機関を認定するスキームは無く、認証機関が独自に認証サービスを提供する形しかない。認証スキームとしては、規格の適用範囲にもあるようにあくまでパブリッククラウドが対象であり、プライベートクラウドは対象とならない。PIIのProcessor(基本的にはプロバイダ)が対象であり、Controllerは対象にならないという規格の適用範囲となる。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のレポートも開示されており、これが報告書として使えるのではないかということになった。以上のように、クラウドセキュリティ認証というものに対して、様々な観点から議論を進めることができた。文章では表せない(筆者の能力は別として)ところでの議論も活発に行われたため、非常に中身の濃い会議となった。