タグ別アーカイブ: CSAジャパン

認証基盤のモダン化とCASBのValue

コメントをどうぞ

三井情報株式会社
橋本 知典

今回は、企業のデジタルトランスフォーメーション（DX）に必要な認証基盤のモダン化とCASBのValueについて説明していく。

■2025年の崖

経済産業省が2018年に公表した「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」では、DXの実現ができない場合、2025年以降最大12兆円の経済損失が生じる可能性があると推定している。2020年は新型コロナウイルスの影響でテレワークが必要になり、セキュリティ対策の不備等、企業は環境に合わせて自社のビジネスを迅速に変革しなければ生き残ることができない問題に直面した。この問題は正に「2025年の崖」問題の先触れといえる。

企業は、DXに取り組むことが求められているが、DX推進に向けた大きな課題としてレガシーシステムの刷新がある。2025年には21年以上の基幹系システムを抱える企業が6割を超える。レガシーシステムを刷新しない場合、保守切れのシステムが増え、保守運用費のコストが大きくなる。またIT人材が不足していくと予想され、多くの技術的問題を抱え、運用が困難になることが想定される。さらに、システムのサポート終了などにより、障害によるシステムトラブル、サイバー攻撃によるデータ流出等のリスクが高まる。

図1　2025年の崖

2020年12月には、経済産業省からデジタルトランスフォーメーション（DX）の加速に向けた研究会の中間報告書「DXレポート2（中間取りまとめ）」が公表された。国内223企業がDX推進状況を自己診断した結果、2020年10月時点で9割以上が未着手や一部での実施の状況であり、想定以上に進捗が悪いことが判明した。

【引用元】
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DXレポート2（中間取りまとめ）』
https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html

■認証基盤のモダン化

「2025年の崖」問題に対する打開策としては、基幹系システムなどをクラウドサービスにマイグレーションすることである。クラウドサービスを活用することで、時間や手間をかけずに基幹システムを移行でき、業務標準化による生産性向上やコストの削減を容易に実現することができる。政府から「クラウド・バイ・デフォルト原則」の方針が出て、クラウドサービスの利用に主軸を置いたITモダナイゼーションが進められ、クラウドの信頼性も大幅に向上してきている現在であれば、安心して移行できるだろう。

クラウドサービスにマイグレーションした場合、IDの認証の連携先としてSAMLなどの認証プロトコルに対応した認証基盤が必要である。多くの企業は認証基盤にオンプレミスのActive Directory（AD）を利用しているが、AD単体ではクラウドサービスとの連携ができない。

また、昨今のサイバー攻撃の多様化・高度化により社内であっても安全とは言えず、オンプレミス環境は徐々にリスクが高まっている。特にランサムウェアは従来型とは変わってきており、企業に搾取した情報を公開すると脅し、高額の身代金を要求する暴露型のものが増えてきた。実際にADの乗っ取りや個人情報が漏えいした事例もある。サイバー攻撃を検知するにもオンプレミス環境では対策ソリューションの導入コストや運用負荷が大きくなる。

これらの課題に対し、認証基盤をモダン化することで解決ができる。クラウド認証基盤であれば、クラウドサービスとも連携でき、サイバー攻撃対策の強化やクラウドサービス毎のIDを一元管理することができるなど、セキュリティ面でも対策を進めることができる。また、境界ネットワークがなくなり、いつでも、どこからでも安全にシステムが利用可能になり利便性も向上する。

図2　認証基盤のモダン化

■CASBのValue

認証基盤のモダン化が進むと、基幹系システムや多くのオンプレミスのシステムがクラウドへ移行しやすくなる。そして最終的にはオンプレミスのシステムを無くすことができ、システムの全てをクラウドサービスに移行する企業も増えてくる。そこで新たな問題として、複数のクラウドサービスの管理やセキュリティが課題になる。クラウドサービスへの統一した組織のセキュリティポリシーの適用やガバナンスの強化が必要になるだろう。

CASBは企業でクラウドサービスの活用が増えるほど真価を発揮する。もしクラウドサービス毎にセキュリティ対策を個別で行った場合、コストが高額になってしまう。CASBを導入すれば複数のクラウドサービスに対し、CASBのコストのみでセキュリティ対策が可能になる。また、CASBでは一つの管理画面から連携しているクラウドサービスのポリシー設定が可能であり、統一したポリシー管理が可能である。他にも、クラウド認証基盤と連携することで、リバースプロキシアーキテクチャによりエージェントレスで、連携したクラウドサービス内のファイルダウンロードなどのアクティビティに対し、リアルタイムでセッション制御が可能になる。例えば、社給端末以外からクラウドサービスのファイルの閲覧はできるが、機密情報のファイルのダウンロードをできないように制御が行えるなど、高度な情報漏洩対策ができる。このようにコスト面・管理面・セキュリティ面でもCASBのValueはさらに上がっていくことが想定される。

以上のように、企業は「2025年の崖」問題の対策として、認証基盤のモダン化を行い、基幹システムをクラウドサービスに刷新していくことでDXを促進できるだろう。そしてクラウドセキュリティ対策として今一度CASBの活用を検討してみてはどうだろうか。

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

クラウドコンピューティングの進化と新たな責任共有モデル

4件の返信

本ブログは、Vishwas Manral, Founder and CEO at NanoSec, CSA Silicon Valley Chapter　のブログ（The Evolution of Cloud Computing and the Updated Shared Responsibility、https://cloudsecurityalliance.org/blog/2021/02/04/the-evolution-of-cloud-computing-and-the-updated-shared-responsibility/）の日本語版で、著者の許可のもとに翻訳し公開するものです。原文と日本語版の内容に相違があった場合には、原文が優先されます。

 

クラウドコンピューティングは、過去10年間変化し続けてきた。このブログは、コンテナ、機能、ローコード、ノーコードの成長によるクラウド状況の変化の結果として、今までのサービスモデルがもはや十分ではないということの理由について説明する。

このブログでは、さまざまなパラダイムの責任共有モデルについても説明し、将来の方向性について検討する。

サービスモデル（SaaS, PaaS, IaaS）の背景

米国国立標準技術研究所（NIST）は、2011年に、3つのサービスモデル、4つの配備モデル、5つの主な特性で構成されるクラウドコンピューティングの定義を提供した（NIST Special Publication800-145）。

このドキュメントは、特にクラウドサービスとクラウド配備戦略を比較する際に、その標準とガイドラインを提供する手段として機能し、クラウドコンピューティングの最適な使用法のベースラインを提供することを目的とした。

3つのサービスモデルは、SaaS（Software-as-a-Service）、PaaS（Platform-as-a-Service）、IaaS（Infrastructure-as-a-service）である。これはすでに過去のことであり、モデルは新しいプラットフォームを包含するように進化する必要がある。

重要な変化の推進力としてのイノベーションとソフトウェア開発

市場に新しく差別化された価値をもたらすことは今や競争上の必要性であり、反復可能な方法でより迅速にイノベーションを実現するために最も組織化された企業が市場のリーダーとなる。企業におけるクラウドコンピューティングの配備は、成熟し、変化を遂げており、新しい価値をもたらし、ソフトウェアが変化の原動力となっている。

このことは、インフラストラクチャ層、サービス層、アプリケーション層に当てはまる。ここでは、急増するコンテナ、Kubernetes（K8s）の台頭、エッジコンピューティングの出現、サーバーレスアーキテクチャの幅広い採用を見ることができる。開発者に提供されるすべてのサービスが、より早く市場に価値をもたらすことを可能にしている。

新しいアーキテクチャを2011年のSaaS-PaaS-IaaSフレームワークに適合させようとすることは、丸い穴に四角いペグを適合させるようなものだ。

新しいサービスモデル

中核となるのは、*クラウド*責任共有モデルが、クラウドプロバイダ（Amazon Web Services、Microsoft Azure、Google Cloud Platform、あるいはより総称的にプラットフォームプロバイダ）とクラウド利用者またはアプリケーション所有者（エンタープライズおよびスタートアップ）の間の責任の明確な境界を提供する。

次の図は、さまざまなサービスモデル間における責任の違いを示している。

いくつかの重要なポイント：

徐々により多くの責任がプラットフォームプロバイダによって引き受けられ、アプリケーション所有者をアプリケーションロジック以外の責任から解放している。

右に移動していくと、プラットフォームプロバイダがより多くの責任を負うため、運用コストとオーバーヘッドが削減される。

NoCode/SaaSのようなプラットフォームになると、開発者の責任自体が縮小する。筋金入りのプログラマではない開発者という新しいレベルの台頭につながっている。

IaaS、PaaS、SaaSに加えて、それ以降に進化した新しいサービスモデルを以下に定義する。

Managed K8s as a Service (K8s-aaS)

Managed Kubernetesは、ほとんどのクラウドプロバイダによって提供されるサービスとして最も広く使用されているManaged Service Control Plane as a service（CPaaS）である。ここでは、Kubernetesコントロールプレーンはプラットフォームプロバイダによって管理され、アプリケーション所有者がオプションで提供するコントロールプレーン（別名K8sマスターノード）構成を使用する。データプレーンのライフサイクルとその管理は、アプリケーションの所有者が行う。

これは、アプリケーションにデータプレーンからの特定のニーズがある場合、追加の運用オーバーヘッドよりもコスト最適なスケールアウトが大きな考慮事項である場合、あるいはアプリケーションがマルチクラウドに移植可能なアプリケーションであることが必要な場合に最適である。

例としては、Amazon Elastic Kubernetes Service（EKS）、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）がある。AWS Elastic Compute Service（ECS）は、Kubernetes以外のマネージドコントロールプレーンサービスの例である。

Container-as-a-Service (CaaS)

CaaSの場合、アプリケーションの所有者がアプリケーションコンテナを提供し、プラットフォームプロバイダがコントロールプレーンとデータプレーンの両方を管理する。つまり、アプリケーションユーザは、CPaaSによって提供されるすべての機能に加えて、サーバー（VM）、ホストOSのスケーリングとパッチ適用、サーバーの起動と停止を管理する必要がなくなる。

これらのサービスは、アプリケーションの所有者が多くのサーバー管理の責任から解放されるため、サーバレスとも呼ばれる。このサービスは、イベントドリブンアーキテクチャではなく、アプリケーションの所有者がスケールアウトのコストをあまり気にしない場合に最適である。

Containers-as-a-Service（CaaS）ソリューションの例としては、Amazon Web Services（AWS）Fargate（ECSFargateとEKSFargateの両方）、Azure Container Instances（ACI）、GoogleCloudRunなどのソリューションがある。

Function-as-a-Service (FaaS)

FaaSの場合、アプリケーションの所有者は、機能を実行するレイヤーとともにビジネスロジックを提供する。これらの機能は、サービスプロバイダによって構築、パッケージ化、および実行される。サービスコントロールプレーンとデータプレーンは、サービスプロバイダによってすべて処理される。

このサービスは、イベント駆動型のステートレスアプリケーションに最適である。

このサービスの例としては、AWS Lambda、Azure Functions、Google CloudFunctionsがある。

NoCode-as-a-Service (NCaaS)

NCaaSでは、コードロジックはアプリケーションの所有者によって提供される。サービスプロバイダは、仕様と構成からコードを生成し、ソフトウェアをビルド、パッケージ化、および実行する。

これと似ているがわずかに異なるもう1つのバージョンは、Low-Code-as-a-Service（LCaaS）である。

コーディングがほとんど必要ないため、これらのプラットフォームは、技術者でないユーザーでもアプリケーションを作成できるように設計されている。これは、今後数年間で驚異的な成長が見られ、ソフトウェア開発者の大幅な増加をもたらす。

このサービスの例としては、Azure Power Apps、Google AppSheet、AWSHoneycodeがある。

Serverless（サーバレス）

サーバレスプラットフォームを使用すると、開発者は開発と配備をより迅速に行うことができ、コンテナクラスタや仮想マシンなどのインフラストラクチャを管理しなくてもクラウドネイティブサービスに簡単に移行できる。

例：上記のモデルでは、CaaS / FaaSおよびNCaaSプラットフォームはサーバレスとして扱われる。

アプリケーションのプラットフォームの選択

次の図は、アプリケーションの所有者がサービスに使用するクラウドプラットフォームを決定する際にその方法の概要を示している。

 

まとめ

まとめると、アプリケーションの将来の展望は非常に多様で、高度にハイブリッドでマルチクラウドである。エンタープライズクラウドコンピューティングプラットフォームには、サーバレスアプリやサーバアプリ、オンプレミス、クラウドなど、さまざまなインフラストラクチャ、サービスレイヤー、APIが含まれる。

「ワンサイズですべてに対応」するモデルや経験則はない。真のクラウド方式においては、組織の変化に応じて進化するスケーラブルでセキュアな環境をサポートするための機敏で弾力的な決定が必要である。

 

SPA （Single Packet Authorization）解説

2件の返信

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からオープンソースとして提供されていますので、さらに理解を深めていただければと思います。

 

CSAジャパン関西支部、ついにキックオフ！（前編）

コメントをどうぞ

CSAジャパン関西支部、ついにキックオフ！（前編）
～キックオフセミナー概要と基調講演（データ政策とクラウド安全性評価）

CSAジャパン運営委員　有田　仁
2019年8月21日

  • はじめに

法人化から5年が経過、CSAジャパンは2019年（令和元年）度の取り組み目標の一つにWG活動等の「多拠点化へのチャレンジ」を掲げ、その第一弾として「関西支部」活動が新年度（本年6月）より本格スタートした。関西支部は、CSAジャパンの事業内容やワーキンググループ（WG）活動等に関して、関西地域における紹介や認知度向上をその活動目的とする。また関西地域のクラウドユーザーが有する潜在的交流ニーズの受け皿として、国内「面展開」の試金石となる。

図1：大阪城公園（天守閣）を一望　　図2：キックオフセミナー会場

上記を受け、7月11日（木）午後より、広大な大阪城公園と壮大な天守閣を窓から眼下に一望できる（図1）、大阪ビジネスパークのクリスタルタワー20階E会議室を会場（図2）として、関西支部キックオフセミナーが開催された。当日プログラムは以下3名の講師による講演で構成された。

  1. 【基調講演】「今後のデータ政策の展開とクラウドサービスの安全性評価について」
    経済産業省 商務情報政策局 情報経済課 課長補佐　関根 悠介氏
  2. 「CSAジャパン関西支部の立ち上げにあたり」
    一般社団法人日本クラウドセキュリティアライアンス 業務執行理事　諸角 昌宏
  3. 「CSA Japan Summit 2019: Recap」
    一般社団法人日本クラウドセキュリティアライアンス 運営委員　有田 仁（※本レポート筆者）

本年は観測史上最も遅い梅雨入りとなり、あいにく当日午後の天候は小雨模様となった。それにもかかわらず、関西を地盤とするICT・電機・医療分野等の企業、監査ファーム、大学・研究機関、また官公庁関連団体などから幅広く、クラウドサービス導入やセキュリティ対策に関心をお持ちの参加者46名のご来場を得た。本稿前編では、上記講演プログラム1（基調講演：今後のデータ政策の展開とクラウドサービスの安全性評価について）に関する所感報告について以下に述べる。

  • 講演プログラム報告
  1. 【基調講演】「今後のデータ政策の展開とクラウドサービスの安全性評価について」（経済産業省 商務情報政策局 情報経済課 課長補佐　関根 悠介氏）
    本セミナーの基調講演として、経済産業省 商務情報政策局の関根氏より、データ政策とクラウドサービスの安全性評価制度の検討状況に関してご講演いただいた。これは本稿後編で述べるCSA Japan Summit 2019（本年5月15日開催／会場：東京大学伊藤謝恩ホール）の招待講演プログラムで、同省の松田洋平氏から事前に講演いただいた内容に通じ、これに近時のパブリックコメントの集約状況等をアップデートの上、関西地域のユーザーへも是非とも聴講機会を頂戴したいとの当会依頼に対し、ご快諾いただいたものである。本講演内容は2つの柱、すなわち①データ流通政策（DFFT：Data Free Flow with Trust）の展開②クラウド・バイ・デフォルト原則とクラウドサービス安全性評価制度の検討状況、からなる。
    DFFT（Data Free Flow with Trust）は、本年1月23日開催の世界経済フォーラム年次総会（ダボス会議）で日本の安倍総理により提唱された「信頼性のある自由なデータ流通」を促進するコンセプトである。すなわち国際的なデータ流通網を構築し、データの囲い込みを防止してその活用最大化を目指すものである。これは本セミナーの直前（本年6月28日・29日）に、インテックス大阪を会場に開催されたG20 Osaka Summit 2019で大阪トラック立ち上げ宣言として盛り込まれたこともあり、参加者の関心は高かった様に思われる。

    ここでの主な論点は、DFFTによる国際的なデジタル経済の成長促進とプライバシーやセキュリティの確保とのバランスをいかに図っていくかにある。これへの対策として、個人情報や知的財産等の安全性確保に向けた個人情報保護法の3年毎の見直し、現行ペナルティのあり方、外国事業者に対する法執行の域外適用や越境移転のあり方、また各国の関係法制度との相互運用性の確保等が検討されていることが説明された。

    クラウド・バイ・デフォルト原則は、2018年6月に「政府情報システムにおけるクラウドサービスの利用に係る基本方針」として採用された「クラウドサービスの利用を第一候補として政府情報システムの検討を行う」とするものである。しかしながらその一方で、適切なセキュリティ管理への懸念等から、（とりわけ）政府におけるクラウドサービス導入が円滑に進んでいない現状を鑑み、官民双方においてクラウドサービスの安全性評価の仕組みの必要性が掲げられている。また「サイバーセキュリティ戦略」（2018年7月27日閣議決定）において、政府プライベートクラウドとしての「政府共通プラットフォーム」への移行の推進が掲げられた。これらを受け、経済産業省と総務省で「クラウドサービスの安全性評価に関する検討会・WG」が2018年8月から複数回開催されるとともに、本年3月16日から4月16日にかけて、中間とりまとめ（案）のパブリックコメントが実施されている。なお同検討会WGメンバーには、当会運営委員の小川隆一氏（独立行政法人 情報処理推進機構／IPA）も名を連ねている。本評価制度は、政府調達における利⽤を第⼀に想定しつつ、民間の特に情報セキュリティ対策が重要となることが想定される重要産業分野等においても、検討結果の活用推奨が目されている。

    本講演で説明いただいた、同検討会における最新整備状況の細部について本稿で逐一再掲することは差し控えたいが、30分間用意していた質疑応答の時間帯は大いに活況を呈したことを報告させていただく。今回、中央省庁関係者からダイレクトに関西ユーザーに対して、取り組み最新状況についてお伝えいただく機会を設定できたことは幸いに思う。また、参加者からの活発な質疑に対し逐一懇切丁寧に応答いただき、セミナー後の懇親会（立食式）までお付き合いいただいた関根氏に、この場であらためて深く感謝の意を表したい。余談であるが、本セミナー開催から日を置かずに、某海外大手クラウドサービス事業者が上述の「政府共通プラットフォーム」に採用決定との報道が流れた。これに対し今後の世論において、様々な観点から議論が惹起されるであろうと予測される。
    （本講演資料は非公開）

※講演プログラム2 （CSAジャパン関西支部の立ち上げにあたり）、同3（CSA Japan Summit 2019: Recap）、及び関西支部の今後の展望について、本稿後編に続く。

以上

本当の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?” は、こちらを参照してください。

CASBWGリレーコラム（第6回）「IT規制改革を支えるCASB」

コメントをどうぞ

IT規制改革を支えるCASB

2018-05-08
CASBワーキンググループ
渡辺 慎太郎（個人会員）

「シャドー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を利用する方法を検討します。

 

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

 

 

 

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に沿ったセキュリティ対策を提案し実践していくことが必要だ
と感じている。

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

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

 

CASBWGリレーコラム（第4回）「アンケート調査で明らかになった、日本のシャドーIT意識の実態」

コメントをどうぞ

アンケート調査で明らかになった、日本のシャドーIT意識の実態

ＮＴＴテクノクロス株式会社
井上　淳

 今回は、先日NTTテクノクロスが実施した、企業におけるクラウドセキュリティに関するアンケートの結果を紹介していく。

■調査の背景

「2020年までに、大企業の60％がCASBを使用※1」「クラウドセキュリティ市場は2021年に208億円に※2」など、クラウドセキュリティ分野では、これまで数多くのポジティブな市場予測が発表されてきた。また、実際にグローバル企業などのクラウドセキュリティについての意識が高いアーリーアダプターを中心に、日本でもCASB市場が大きく成長してきている。

しかし、マジョリティに当たる一般的な日本の企業におけるクラウドサービス利用の実態についての統計的な情報としては、総務省が毎年発表している情報通信白書以外にほとんど存在しないという状況であった。

日本の企業が実際にどのようなクラウドサービスを使っているのか、マルチクラウド利用は進んでいるのか、クラウドセキュリティに対する意識はどうなっているか、大企業と中小企業ではどのような違いが生じているのか。そういった生の情報が不足していたことから、今回、NTTテクノクロスではクラウドサービス利用状況の実態を調査するに至った。

※1：Gartner,Inc. Magic Quadrant for Cloud Access Security Brokers (2017)
※2：IDC Japan株式会社 国内クラウドセキュリティ市場予測、2017年～2021年(2017) 

■調査結果について

回答者の属性や調査結果について、詳細についてはZDNet Japanで公開されているホワイトペーパー（URL：https://japan.zdnet.com/paper/30001048/30002673/）を参考にされたい。本コラムでは、特徴的なポイントのみ紹介する。

■大企業と中小企業で異なる、利用しているサービスの傾向

設問２『選択肢の中にご利用中のクラウドサービス名（SaaS）があれば、教えてください』に対する回答は、1000名以上の企業と1000名未満の企業で回答の傾向に大きな差が生じた。

例えば、1,000 名未満では「Gmail（G Suite）」を挙げた回答者が最多であったのに対し、1,000 名以上では「Exchange Online（Office 365）」首位を逆転するといった具合だ。同様に、「OneDrive」「Dropbox」「Google Drive」は1,000名以下の企業での利用が多く、1,000 名以上では「Box」の回答割合が多くなるなど、類似サービスの中でも企業規模による利用傾向の違いが見える結果となった。

コスト面やセキュリティ面など、クラウドサービスの評価基準が企業規模によって異なるであろうことは予想できたものの、これほど如実に数字として表れたことは非常に興味深い結果となった。

 

 ■リスクは認識されつつも「自己責任」派が多数

設問６は、「利用が認められていない」クラウドサービスを、実際に社員が利用している、いわゆる「シャドーIT」が自社で発生しているという状況を認識している回答者に対して、『どうお考えですか』と質問した結果だが、「セキュリティのリスクがある」という認識を持つ回答が8割程度ではあったものの、そのうちの半分強にあたる42%の回答が「セキュリティリスクはあるが、自己責任の範囲で注意して利用すれば問題ないと考えている」と考える“自己責任派“であった。

CASBによるシャドーIT対策の必要性について重要なポイントの一つとして、「会社のルールでクラウドサービスの利用を禁止すると、従業員は代替のサービスや手段を探して利用する可能性があるため、さらにセキュリティリスクが増す（そのため、禁止するのではなく可視化して統制すべきである）」という考え方があるが、まさにそのような人間心理を裏付けるような結果となり、CASBが実現する「シャドーITは、可視化して統制すべきである」といった対策が有効であることが伺える結果となった。

■『CASB』の認知度はまだまだ

設問12では、直球で『クラウドセキュリティ対策の考え方の1 つである「CASB」をご存知ですか？』という質問を投げ掛けたが、63%が「知らない」という回答であり、認知している回答者は37%という結果であった。

セキュリティ分野における専門用語の一般的な認知度としてはまずまずである、と評価する見方もあるが、職種として「情報システム関連職」が5割を超えているという回答者の属性を踏まえると、CASBというクラウドセキュリティ対策はもっと認知されるべき存在である。今後も、WGの活動等を通じてCASBを啓蒙していくことの必要性を感じる結果となった。

■終わりに

セキュリティ分野のもう一つのトピックとして、NTTテクノクロスでは、昨年に引き続き「サイバーセキュリティトレンド2018」（URL：https://www.ntt-tx.co.jp/products/cs-trend/）を公開した。

変化し続けるサイバーセキュリティの「今」を知ることができる資料となっている。こちらも無料でダウンロード可能となっているので、是非ご一読願いたい。

 

 

CASB-WG リレーコラム始めます！

コメントをどうぞ
CASBワーキンググループ・リーダー
上田光一

 

今、本稿に目を通して頂いている読者の皆様は、CASBもしくはクラウドセキュリティ全般にご興味のある方と思います。
CSAジャパンのCASB-WGは発足からちょうど2年、CSAグローバルに上位活動を持たないCSAジャパンとしての独自活動を展開して参りました。ちょうど1年程前には、日本国内でのCASB理解に一石を投じるべく、独自に執筆したホワイトペーパーをリリースしました。（こちらからダウンロードできます）。
それから1年、市場でもCASBに関する話題には事欠きませんでした。ホワイトペーパーのリリース前後には、CASBベンダのNetskopeが日本上陸、11月にはGartner社がCASBのMagic Quadrantの初版をリリースしました。それとほぼ同時期に、大手セキュリティベンダのMcAfeeがCASBベンダの老舗Skyhigh Networksを買収する、といったニュースが飛び込んできました。今やCASBというキーワードは一般化し、ますますホットなものになってきたと言えるでしょう。
ただ悩ましいのはベンダやプレイヤーも増加する中で、当初Gartner社が提唱してきたコンセプトとは少しずつ違った切り口での情報も目に付くようになってきたことです。こういった変化自体はGartner社自身が認めていることでもあり、新技術の定着過程において起こりがちなことでもあります。これは良い意味では、Gartner社の「コンセプトありき」という段階から、より実地に即したものに進化してきたと見ることができるでしょう。ただホワイトペーパーのような一元的な情報編纂の取り組みについては、その完成時には環境変化により、あるいは物足りないものとなってしまう懸念があることも事実です。
そこでCASB-WGとしては、タイムリー、コンパクト、かつ多様性のある情報発信を意図し、これから数回に分けて本ブログにてリレーコラムとして記事をアップしていくことと致しました。複数のCASBベンダー、再販パートナー、利用者組織等々、様々な観点で執筆していく予定となっております。ぜひ楽しみにして頂ければと思います。
なお本ページは、リレーコラムのインデックスとなるよう以下にリンクを追加していきます。

 

  1. 第1回：「日本企業がCASBに求めるものとは？- CASBがバズワードで終わらない理由- 」　株式会社シマンテック　髙岡隆佳　（2018年2月27日公開）
  2. 第2回：「CASB v.s. SWG – クラウドセキュリティ？それともウェブセキュリティ？ –」 株式会社シマンテック　髙岡隆佳　（2018年3月16日公開）
  3. 第3回：「GDPRとCASB」CASBワーキンググループ　橋本知典　（2018年3月24日公開）
  4. 第4回：「アンケート調査で明らかになった、日本のシャドーIT意識の実態」　ＮＴＴテクノクロス株式会社　井上淳　（2018年4月10日公開）
  5. 第5回：「「原則と現状のはざま」をCASBで対策できないか」　CASBワーキンググループ・リーダー　上田光一　（2018年5月7日公開）
  6. 第6回「IT規制改革を支えるCASB」　CASBワーキンググループ　渡辺 慎太郎（個人会員）（2018年5月８日公開）
  7. 第7回「インテリジェンスとしてのCASB」　CASBワーキンググループ　渡辺 慎太郎（個人会員）（2018年6月1８日公開）
  8. 第8回「クラウドサービス利用のモニタリングとラベリング」　CASBワーキンググループ　渡辺 慎太郎（個人会員）（2018年9月８日公開）
  9. 第9回「クラウド利用者とクラウドプロバイダ：双方の言い分」　CASBワーキンググループ　渡辺 慎太郎（個人会員）（2018年9月８日公開）
  10. 第10回「CASBはデータガバナンスの登竜門となる？」株式会社シマンテック　高岡隆佳　（2018年12月6日公開）

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

コメントをどうぞ

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

2018年2月16日
CSAジャパン　諸角昌宏

第9回クラウド利用者会議では、IoTのセキュリティに関わる課題というテーマで笠松氏にご説明いただいた。会議は、2月5日(月)に開催し、クラウド利用者を中心として9名（内1名はオンラインでの参加）に参加いただいた。

まず、IoTのセキュリティに絡む課題として、12月の勉強会の時に参加者およびベンダーとディスカッションした内容に基づいて、以下の5点を上げた：

  • 経営陣の理解が乏しい懸念がある
  • 経営陣を説き伏せる対応が多岐にわたるため、それらへの対策を議論するが場ない
  • IoTのセキュリティについての活動を行っている他のNPO法人との協調
  • IoTの「プラットフォーム」としてのセキュリティの必要性
  • 開発・運用環境を含めて、エッジ及びクラウドのセキュリティの必要性

また、IoTのセキュリティに対する国内の政策としてIoT推進コンソーシアムがあり、官民が連携して様々な活動を行っている。IoT推進コンソーシアムは、海外との連携も進めている。しかしながら、IoT推進コンソーシアムは開発ガイドラインの策定が主な目標であり、上記の課題にある開発・運用環境、プラットフォームとしてのセキュリティには踏み込めていないという印象がある。
IoTに関する国際標準は、ISO/IEC15408として進められている。この標準は、セキュリティ製品（ハード/ソフトウェア）およびシステムの開発や製造、運用などに関する国際標準であり、情報セキュリティ評価基準（ITSEC,　Common Critria等）の考え方で進められている。

このような状況を受けて、笠松氏からIoTに絡む５つの課題が説明され、今後検討しなければいけない点として上げられた。これについては、以下の笠松氏のスライドを参照していただきたい。

さて、以上の説明に基づいて、スピーカーから提示された上記の課題に対して参加者からの質問および議論が行われた。

  1.  IoTに関するIPAの取り組みについて議論となった。
    IPAでは、セキュリティとセイフティーの融合の観点から、実証検証、ケーススタディー等を通してリスクアセスメントに取り組んでいる。いわゆるSecurity-by-Designに基づくSTAMPモデルにより、システムの安全性に関するモデル化および分析方法を進めている。基本的には、開発者および利用者向けの取り組みになる。したがって、IoTの運用に関するセキュリティの課題は残ったままである。特に、IoT環境においてエッジコンピューティングとしてスマートフォンが使われるケースが増えてきている。この課題は、誰でも容易に使える反面、多くのIoTがパスワードも含めデフォルト設定のまま出荷されている点、データオーナの許可なく通信傍受が容易である点などが問題となっている。また、2016年米国FBIが個人宅で殺人事件があった際、スマートスピーカを押収した事例は、音声のオーナは誰か、スマートスピーカのオーナは誰か、スマートススピーカ（仮に音声型IoTとする）の音声データに証拠能力があるのか、など運用時のルールが不明のまま市場から受け入れられていく社会的環境が容認される点、などが重大な課題ではないか。
  2. 国境を越えるデータ流通について
    eSIM（電子的に書き換え可能なSIM）がIoT基板PCBに半田付けされている製品が出回りだしている点は、パーマネントローミング規制をEUで制定すみだが、日本国内の運用・使用ルールは見当たらない。顔認証が実用段階となった現在、このようなIoT機器のデータ流通を運用する議論の場が、CSAにあっても良いのでは。
  3. RPAの導入がセキュリティに与える影響について議論となった。
    RPAが行ったことで問題が発生した場合どうなるのかということである。RPAの利用にあたっては、監査ログが必須なるが、そもそも捜査の範囲を明確にしないと監査自体が検証可能にならないという問題になる。そうすると、RPAになんでもかんでもやらせるということでは無く、行う操作自体を明確にして、後で検証できることが重要になる。できるだけ業務を絞り込んで、監査しやすくするということが重要になるということである。という議論をしていくうちに、そもそもRPAはIoTなのかという話しになり、様々なモノをIoTでひとくくりに見ていくこと自体が無理ではないかという話しになった。モノの種類、特性ごとに個別に考えていく必要があり、RPAはRPAとして考えていかなければならないということになった。
  4. ビルや橋に埋められた100年IoT
    この部分については時間の関係で、パワポ記載内容を読み上げるに留まった。
  5. サーバレス
    この部分については時間の関係で、パワポ記載内容を読み上げるに留まった。

以上のような議論のもと、今後CSAとしてどのように取り組んでいくかという話しになった。IoTの運用面のセキュリティの課題をどうするかということは、結局どのようにガバナンスを利かすかという問題になるということになった。RPA等、新しい技術に対してどのようにガバナンスを利かすか、GRCをどのようにしていくかについて、テーマを決めながら議論していくことが大切であり、CSAとしてワークショップを開きながら議論していくことが必要ということになった。

 

以上