カテゴリー別アーカイブ: 未分類

クラウドにおける医療ビッグデータのプライバシー保護/セキュリティ管理(後編)

(前編)はこちら

医療ビッグデータライフサイクルとGDPRに準拠したプライバシー保護

次に本文書では、以下の6つのステージから成るクラウド環境のデータライフサイクルを提示している。

  1. 生成(Create):データが生成、獲得、修正される
  2. 保存(Store):データがストレージレポジトリに委ねられる
  3. 利用(Use):データが他の種類の活動で処理、閲覧、利用される
  4. 共有(Share):データや情報が他にアクセス可能なようにする
  5. 保管(Archive):データが長期ストレージに置かれる
  6. 破壊(Destroy):データが必要でなくなった時、物理的に破壊される

その上で、プライバシーの定義について、情報の適正なアクセス、利用、変更に関する意思決定に関係したものであり、誰が適正に情報にアクセスし変更すべきかを決定するフレームワークを確立するものとしている。

患者のプライバシーに対する侵害は、情報システムに対する持続的標的型(APT)攻撃や標的型攻撃の出現とともに、医療ビッグデータ分析における重大な課題と認識されている。医療ビッグデータの価値は、個人情報の収集に関連していることが多く、その結果が個人によく理解されていない可能性がある。従って、ビッグデータのベネフィトを享受すると同時に、各個人のプライバシーを保護することが必須の課題となる。また、プライバシー保護に際しては、個人の選択権を認めると同時に、効果的なリスク低減策を提供する必要がある。

特に、欧州連合(EU)の一般データ保護規則(GDPR)は、EUのデータ主体の個人データが保護されていることを保証し、個人データに対するEUのデータ主体の権利が拡大することを目的としている。EUのデータ主体のデータを収集、処理、保存する企業は、企業のロケーションに関わらず、GDPRを遵守しなければならない。ライフサイクル全体を通したデータ管理は、GDPR遵守に必要なだけでなく、米国の「医療保険の相互運用性と説明責任に関する法律(HIPAA)」で規定された保護対象保健情報(PHI)の要求事項をクリアするためにも有効だとしている。

また、企業に対しては、ユーザーの情報を利用目的・方法などについて説明したプライバシーポリシーを設定することが求められる。本文書では、以下のような点に留意するよう推奨している。

  • 企業およびその代表者の連絡先詳細が含まれる
  • 企業がデータを収集する理由を記述する
  • どれだけの期間、情報がファイルに保持されるかを述べる
  • ユーザーが有する権利を説明する
  • 簡単な言語で文書化する
  • 個人データの受取人の名前を明記する(企業が他組織とデータを共有する場合)

NISTプライバシーフレームワークを活用したデータリスク管理

本文書では、前述のデータライフサイクルのうち「共有」に関連して、異なる組織との間でデータが共有される方法を記述した「データ処理エコシステム」を取り上げている。このエコシステムは、複雑で多方向的な関係性を持った主体や役割から構成されており、責任共有モデルのベースとなる医療機関・クラウドサービスプロバイダー間の正式な同意書/契約書の締結が不可欠だとしている。

その上で、米国立標準技術研究所(NIST)プライバシーフレームワーク1.0版を利用したリスク管理手法を紹介している。同フレームワークでは、共通のプライバシーリスク対策の「コア」、組織が行うプライバシーリスク対策の「As Is(Current)」と「To Be(Target)」をまとめた「プロファイル」、プライバシーリスクへの対策状況を数値化し、組織を評価する基準である「インプレメンテーション・ティア」が基本概念の柱となっている。

コア機能には、「特定(Identify-P)」、「統治(Govern-P)」、「制御(Control-P)」、「通知(Communicate-P)」、「防御(Protect-P)」があるが、ここでは、特定(Identify-P)機能のうち、「ID.DE-P:データ処理エコシステム・リスクマネジメント」に従って、エコシステム内のプライバシーリスクを特定、評価、管理するプロセスを導入している。

データ処理エコシステム・リスクマネジメントとは、組織の優先順位付け、制約、リスクの許容範囲、仮定で、データ処理エコシステム内におけるプライバシーリスクおよびサードパーティの管理に関連するリスク意思決定を支援するために設定・利用されるものであり、以下のようなサブカテゴリーから構成される。

  • ID.DE-P1: データ処理エコシステム・リスクマネジメントのポリシーやプロセス、手順が、組織のステークホルダーによって特定、確立、評価、管理、同意される
  • ID.DE-P2: プライバシー評価プロセスを利用して、データ処理エコシステムの主体(例.サービスプロバイダー、顧客、パートナー、製品メーカー、アプリケーション開発者)が特定、優先順位付け、評価される
  • ID.DE-P3: 組織のプライバシープログラムの目的を満たすように設計された適切な遺作を展開するために、データ処理エコシステム主体との契約が利用される
  • ID.DE-P4: データ処理エコシステムのプライバシーリスクを管理するために、相互運用性フレームワークまたは同様のマルチパーティ手法が利用される
  • ID.DE-P5: 契約、相互運用性フレームワークまたはその他の責務を満たしていることを確認するために、監査、テスト結果またはその他の評価形態を利用して、データ処理エコシステム主体が日常的に評価される

プライバシーには、誰が情報にアクセスし、利用し、変更できるかに関する意思決定が含まれており、それに従って、セキュリティの選択肢や条件が展開される。セキュリティは、情報とプライバシーの間のインタフェースとなり、プライバシー権を推進して実行に移す役割を果たす。

医療機関は、大容量のデータを保存、処理、共有しており、医療産業を支援するためにビッグデータ分析で利用されている。データは重要な資産であり、データのセキュリティを維持し、医療の責務を遵守するために、医療機関は、セキュリティソリューションを展開する必要がある。米国では、HIPAAに加えて、連邦取引委員会(FTC)が所管する個人識別情報(PII)に対するセキュリティ要件も満たす必要がある。

サーバーレス環境の医療ビッグデータ基盤のリスク管理

2018年7月24日、米国立衛生研究所(NIH)は、商用クラウドサービスプロバイダーと提携して、生体医学の進歩を加速させるために、大規模生体医学データセットにアクセスして計算処理を行う際の経済的・技術的障害を取り除くことを目的とする「発見・実験・持続可能性のための科学技術研究インフラストラクチャ(STRIDES)イニシアティブ」を発表し、第一弾としてGoogle Cloudとの戦略的提携をスタートさせた(NIHプレスリリース参照(https://www.nih.gov/news-events/news-releases/nih-makes-strides-accelerate-discoveries-cloud))。その後NIHは、同年10月23日、Amazon Web Service (AWS)との戦略的提携を発表し(NIHプレスリリース参照(https://www.nih.gov/news-events/news-releases/amazon-web-services-joins-nihs-strides-initiative-harness-latest-cloud-technologies-biomedical-researchers))、さらに2021年7月20日には、Microsoft Azureとの戦略的提携を発表している(NIHプレスリリース参照(https://www.nih.gov/news-events/news-releases/nih-expands-biomedical-research-cloud-microsoft-azure))。

これらの医療ビッグデータベースには、サーバーレスなど最新鋭のクラウドネイティブ技術が実装されており、実際にビッグデータ分析を利用する医療エコシステムにも、位相高度なプライバシー/セキュリティリスク管理策が要求されつつある。

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の活用を検討してみてはどうだろうか。

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

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

本ブログは、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が含まれる。

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

 

SASEの登場とゼロトラストを実現するCASBのカバレッジ

タイトル:「SASEの登場とゼロトラストを実現するCASBのカバレッジ」

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

今回は、SASE(セキュア・アクセス・サービス・エッジ)の概要とCASBとの関係性、ゼロトラストを実現するCASBのカバレッジについて説明していく。

■CASBの現状

ガートナージャパンが日本におけるセキュリティ (デジタル・ワークプレース) のハイプ・サイクル:2020年を発表した。CASBについては幻滅期に入ったとされている。「過度な期待」のピーク期は過ぎたが、CASB市場規模は2018年頃より急拡大してきており、今後も市場は拡大していくと予想されている。今回の発表では新たにSASEとゼロ・トラスト・ネットワーク・アクセスが追加された。今回、SASEはCASBと関係性があるため紹介する。

図1 日本におけるセキュリティ (デジタル・ワークプレース) のハイプ・サイクル:2020年
出典:ガートナー

■SASEの登場

SASEはガートナー社が2019年に提唱した新しい概念である。SASEのコンセプトは包括的なネットワーク機能と包括的なネットワークセキュリティ機能をクラウド上で1つのサービスに統合し提供することである。デジタルトランスフォーメーション(DX)を推進する企業が安全にクラウドサービスにアクセスするニーズに対応している。このSASEのネットワークセキュリティ機能の中にCASBが含まれている。

今後SASEの需要が増加していき、2024年までに企業の40%がSASEの導入を計画することが予想されている。提供元、提供形態も別であったCASBやSD-WANなどのサービスが1つに統合されていくことにより、効率的な投資が可能になる。現状ではSASEの機能全体を提供できるようにベンダーが買収などを行いながら機能拡張に力を入れている段階である。企業のDX推進に向けて必要な企業ネットワークとネットワークセキュリティの新たな変革の機会をSASEは提供していくだろう。

図2 SASEとCASBの関係

■ゼロトラストを実現するCASBのカバレッジ

SASEはゼロトラストというセキュリティモデルを基にしている。ゼロトラストは「すべてのアクセスを、信頼されていないネットワークから発信されたものとして扱う」という考え方を根底にしたセキュリティモデルである。NIST(National Institute of Standards and Technology:米国立標準技術研究所)からは「SP 800-207 Zero Trust Architecture」がリリースされている。SP 800-207ではゼロトラストが誕生した背景や、ゼロトラストを実現する原則などの基本的な考え方が定義されている。このゼロトラストに照らした時のCASBのカバレッジについて確認していく。

ゼロトラストでは、全てのデータソースとコンピュータサービスは、リソースと見なされるとしている。クラウドサービスもリソースの1つとして考えられており、クラウドサービスの特定を行う際に、CASBの可視化機能が有用である。

ゼロトラストでは、ネットワークの場所に関係なく、通信を全て保護するべきとされている。CASBは境界ネットワークの内側、外側のどちらの場所であってもクラウドサービスへの通信の可視化や制御ができる。

ゼロトラストでは、リソースへのアクセスは、全て個別のセッションごとに許可し、ユーザやデバイスの評価、データの重要度を基にポリシーを決定するべきとされている。CASBはIDaaSと連携することができる。それにより複数のリスク要因に応じて、特定のクラウドサービスへのユーザのアクセスを細かくブロックできる。また、クラウドサービス内の機密性の高いコンテンツをスキャンし、リアルタイムでファイルダウンロードなどのアクティビティをブロックすることもできる。

ゼロトラストでは、組織が所有するシステム、ネットワーク、通信を監視して、安全な状態であることを確認し、セキュリティを高めていくことも重要とされている。CASBはクラウドサービスと、クラウドサービスへの通信の状態(トラフィック、詳細アクセスログ)を継続的に監視して情報を取得し、脅威を分析して通知できる。そして、対策をするために新たなポリシーを作成して適用し、セキュリティの改善を行っていくことができる。

以上のように、ゼロトラストにおいてCASBのカバレッジは広く、今後SASEが普及していく中でも中核の機能として取り扱われていくだろう。

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

SPA (Single Packet Authorization)解説

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パケットは、必要な情報をすべて1つのパケットの中に含めなければならない。
  • 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チェックサムを持つことで、1つ1つの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?” は、こちらを参照してください。

CASBWGリレーコラム第10回「CASBはデータガバナンスの登竜門となる?」

CASBはデータガバナンスの登竜門となる?

株式会社シマンテック
高岡隆佳

クラウドで活用するデータ、どこまで許可するか

企業はCASBによってマルチクラウドの利用を一元的に可視化、制御ができることは間違いないのだが、CASB製品の評価において顕著に見られるのが、「企業として取り締まるべき情報(データ)の定義があいまい」なことだ。製造業や金融機関などにおいては、いわゆる業界ごとに定められたガイドラインや、他社に漏れては困る開発・設計データなどが明確に定められているが、そうでない場合、部署ごとにデータの機密性についての捉え方が異なっているために、企業全体としての「データ取り扱い」に関するルールが設定できないことが多い。そんな中、ややフライング気味にクラウドシフトしてしまった企業は、いざCASBで情報流出対策を打とうという時に、肝心のポリシーを策定することができないのだ。

一方の欧米諸国の現状はどうなのだろうか。「訴訟大国」とも揶揄されるアメリカでは、各業種非常にコンプライアンスに厳しく、また会社では情報の取り扱いに対する教育を徹底する文化が根付いている。取引先の情報が自社から漏れることによるリスク、インパクトが明らかに日本に比べると段違いだ。それゆえに古くからDLP(情報流出対策)の導入が自然と進んでおり、「データの棚卸し」が自動化されている。(導入比率でいうと、欧米:日本=10:1ほどだ。)もちろん「どのようなデータがどこまで活用されることが許容されるか」といったデータガバナンスが根底にあるからこそだ。

よって欧米欧州ではオンプレミスに徹底されているデータ取り扱いに関するポリシー(DLPポリシー)を、自分たちが採用したクラウドに対してはCASB経由でポリシー適用するだけでよい。日本企業の大部分は、そもそもオンプレミスにしっかりとしたDLPポリシーがないのにも関わらず、CASBによりクラウド上のデータを保護しようとしても、適切なポリシーも設定できなければ、またCASBで取り締まったところでオンプレミスの端末やメール添付、ファイル転送といったデータ流出経路はまったく可視化できないため、クラウドシフト半ばの日本企業においては、情報流出対策として十分な投資効果が出るとは思えない。

CASBとクラウドの正しい利用

仮に企業としてのクラウド活用指針(データの機微度に応じたリスク対処方法を含む)を定義できたとしよう。さて、その際にどれだけの企業が機微度の高いデータをクラウドに預ける判断を取るだろうか。CASBベンダーの提供するデータ保護機能は様々だが、機微度の高いデータだからといってオンプレミスに大量にデータをかかえてしまうのであれば、結果としてオンプレミスとクラウド、運用とサーバ費用が二重投資となる。クラウドシフトに舵を切る以上は、限りなくデータをクラウドに安心して預けられる環境を構築したいところだ。

そのためにはCASBの暗号化機能を活用することをお勧めする。

特定のクラウドサービスの暗号化を用いた場合は、暗号鍵管理がほぼクラウド側になるだけでなく、複数のクラウドサービスを利用するのであれば、それぞれ個別で暗号化設定の管理が必要となり、またクラウドサービスごとにセキュリティレベルは異なるためガバナンスは効かせづらい。CASBであれば、ブローカーとしての役割を果たすことで、どのクラウドサービスにデータを転送する際も、CASB側で一意の暗号化や匿名化を施し、また鍵管理もデータを預けるクラウドサービス側とは別で一元管理、そして暗号鍵の担保が下記のように可能だ。

1.       ユーザ側は機微度に関係なくクラウドにデータを預けることが可能となる。

2.       データの機微度に応じた制御がCASBで自動実行される。(暗号化・匿名化)

3.       利用時は本人認証などを通じて透過的に暗号鍵がロードされデータ閲覧・編集が可能となる。

4.       すべてのデータアクセスはCASB管理者側で把握でき、不正な鍵要求が見られれば該当のファイルに対して鍵を破棄し、復号できないことを担保することも可能となる。(Digital Shuredding)

日本企業はどうしてもセキュリティを「止める、縛る」ことを前提に設計しがちだが、その思想ではクラウドの最大活用を阻害してしまう。しっかりとデータガバナンスを効かせつつ、透過的にリスクを排除していくためにCASBという技術は存在する。そのためには企業の中でデータ利用、クラウド利用の指針を今一度見直し、CASBの機能で担保できるリスクが何であるのかを理解した上でクラウドシフトを正しく進めていただきたい。

CASBWGリレーコラム第9回「クラウド利用者とクラウドプロバイダ:双方の言い分」

 クラウド利用者とクラウドプロバイダ:双方の言い分

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

CSAでは定期的に「クラウド利用者会議」という会合を開催している。これはクラウド利用者側の観点でクラウドに期待すること、あるいは課題などをディスカッションするもので、CSAジャパンの本ブログでも結果を議論の内容を紹介している。

先ごろ行われた会議で、どのようにクラウドプロバイダを選択すればよいかわからない、といったコメントがあった。プロバイダの公開情報や試用する中で業務への適合性は確認できるとしても、セキュリティの観点での差分が見えないというものである。

 一方、プロバイダ側コメントとして、不確定の伝聞情報で大変恐縮ながら以下のようなコメントがあったとのことであった。

  • プロバイダ側としてはセキュリティに関する情報なので非公開である
  • 仮に公開したとしても普通のユーザでは適切な判断ができるか懸念がある

 確かに利用者にとっては、クラウドを利用するに際してどのようにプロバイダのセキュリティレベルを判断すれば良いのかは課題である。利用者が自力で判断しようとするとき、プロバイダが公開しているセキュリティ情報を元にこれを行うことになるが、ここで欧米と日本で大きな違いがある。欧米のプロバイダの対応は、セキュリティ情報を積極的に公開することで利用者が判断できるようにする傾向が強い。いわゆる「透明性」を高めるということである。これは、また、セキュリティをビジネス上の差別化要因にできるという利点がある。

一方、日本のプロバイダはあまりセキュリティ情報を公開しない。どちらかというと、「セキュリティ情報を公開することはリスクを高める」という考えを持っている。取得している認証の情報を公開しているが、認証ではセキュリティの成熟度を把握することは難しい。このあたりは国内事情としてはやむを得ない印象を受ける一方で、米国はじめグローバルの事情とはかなり異なっている。

 

CSA本部のWebサイト、https://cloudsecurityalliance.org/では、以下のような情報を提供するページがある。

 CSA Security, Trust & Assurance Registry (STAR) https://cloudsecurityalliance.org/star/#_registry

 これはCSAが提唱する認証制度STARを一つの基準としつつ、STAR認証取得の有無に関わらずクラウドプロバイダ側が自社のセキュリティ対応状況を公開するページとなっている。クラウドプロバイダとしては、自社サービスの透明性と公正さをアピールする場にもなっている訳である。

一見して分かる通り米国プロバイダが圧倒的に多いのは当然としても、中国プロバイダも数多く登録されていることは興味深い。日本のプロバイダはごく僅かに留まっている。

 一例としてクラウドストレージのBoxをとってみると、以下で詳細情報が得られる。https://cloudsecurityalliance.org/registry/box/

 ここからCSAの提唱するクラウドプロバイダ向けセルフアセスメントのフレームワーク、CAIQ Consensus Assessments Initiative Questionnaire) に従って、プロバイダ自身が(このケースではBox社が)自己評価をした結果が得られる。興味のある方はぜひご一読頂きたいが、なかなかの情報量である(しかも英語)。

そうなってくると、こうした情報が得られるとしても、それを利用者が正確に判断できるのか、いわゆる利用者のセキュリティ・リテラシが問題となる。

 さてここでCASBである。

 CASB4つの柱のうち1つ目の柱である「可視性」、ここには「どのクラウドサービスを使っているか」という意味合いとともに「それはどんなクラウドサービスであるか」という観点がある。対象とするクラウドサービスがどのような種別のサービスを提供するのか、そしてどのようなセキュリティ機能を提供しているか、こういった情報を、CASBは提供する。そしてここで重要なのが、CASBはセキュリティ状況をシンプルにリスクスコアとして判定して提供してくれることということである。

例えばあるCASBでは、クラウドサービスのリスクスコアを9段階で評価してくれるため、信頼を寄せられる程度が簡単に判断できる。

 ではそれはどのような基準でスコアリングを行っているのだろうか。

 評価基準の大元としてよく使われるのが、CSAで策定しているCCMCloud Control Matrix)である。これはCSAジャパンで日本語版としてもリリースしているもので、下記からダウンロード可能である。
http://cloudsecurityalliance.jp/WG_PUB/CCM_WG/CSA_CCM_v.3.0.1-03-18-2016_ISO_J_Pub.pdf
(注: なお、ここで公開している日本語CCMControlの翻訳部分のみである。CCM全体のEXCEL版は、現在CSAジャパン会員のみが利用可能となっている。)

 最新版のv3.0.1では、16ドメイン、133項目からなっていて、例えば以下のような項目がある。

  • カテゴリ:データセンタセキュリティ
  • 項目:コントロールされたアクセスポイント
  • 説明:機微なデータ及び情報システムを保護するために、物理的なセキュリティ境界(フェンス、壁、柵、警備員、ゲート、電子的監視、物理的認証メカニズム、受付デスク、安全パトロールなど)を実装しなければならない。

 例1)

  • カテゴリ:暗号化と鍵管理
  • 項目:権限付与
  • 説明:鍵には識別可能な所有者が存在し(つまり鍵とアイデンティティが紐付いていること)、また(組織には)鍵管理ポリシーがなくてはならない。

 例2)

  • カテゴリ:脅威と脆弱性の管理
  • 項目:脆弱性 / パッチ管理
  • 説明:(長いので省略。ぜひCCMをご参照ください)

 CASBベンダはこういった情報を前述のCAIQやクラウドプロバイダのWebサイトによる公開情報などから入手する。公開情報がない場合は、個別にクラウドプロバイダに問い合わせることもする。クラウドプロバイダから回答が得られない場合は、その状況を踏まえCASBベンダが独自に判定することになる。

またスコアリング項目は必ずしもCCMと完全一致という訳でなく、CASBベンダ自身による重みづけや独自観点も加味する形で算出されている。また重みづけについてはユーザによるカスタマイズ機能を提供しているCASBもある。

 各クラウドプロバイダのセキュリティ対応状況も刻々変化する一方、クラウドプロバイダもサービスの数自体も増加していくので、CASBベンダはこういった状況にも追随して対応している。特定のクラウドサービスが登録されていない場合は、リクエストにより追加登録対応してもらえる。

 CASBベンダはこのような取り組みを通して、クラウドプロバイダやサービスごとのセキュリティ対応状況データベースを日夜更新しており、今や登録サービス数30,000に迫るデータベースを保持するCASBベンダもある。

従来国産クラウドサービスについては対応サービスが限られる状況があったが、対応数も順調に増加しているようである。

組織によっては申請ベースでクラウド利用を個別に許可する運用を行っていることも多いと思うが、さらに個別に個々のクラウド利用審査のための調査が大変だ、という声を聞くこともある。クラウドを使いたいのに選択の判断情報がない、あるいは調査のための労力が無視できない。これをCASBのリスク判定で代替してしまう。これは一つの有効なCASB活用事例と言えそうである。

 しかしながらそれ以上にこういったリスク評価基準の策定フェーズにおいては、企業のクラウド活用における根本命題、すなわち「企業としてどのような観点でクラウドを活用していくか」という点に向き合うこととなる。これは企業のクラウド活用戦略を立てる良い機会となるだろう。

 CASBという存在の登場により、ユーザ企業、クラウドプロバイダの相互理解が進むこと、ひいてはユーザ企業におけるクラウド活用の進展、そして生産性向上とともに社会の発展つながる、こういった流れをCSACASB-WGとしても独自の立場から応援していきたいと考えている。

 

CASBWGリレーコラム(第8回)「クラウドサービス利用のモニタリングとラベリング」

クラウドサービス利用のモニタリングとラベリング

CASBワーキンググループ
渡辺 慎太郎(個人会員)

いわゆるシャドーIT対策機能を有するCASBを組織で導入すると、その組織内で利用されているクラウドサービスが一覧化されるとともに、利用状況が可視化されます。

あまりにたくさんのサービスが可視化されてしまい、途方に暮れてしまうかもしれません。なすべきは、可視化された各クラウドサービスにラベルを付けることです。たとえばオペレーションの観点から、「社内標準」「全社許可」「一部許可」「不許可」「判定中」「対象外」などと分けます。なぜ「対象外」があるのかというと、CASBがクラウドだと判定していても、そうとは考えられないサイトが存在するからです。

「社内標準」はいいとして、「全社許可」「一部許可」「不許可」の判断が難しいかもしれません。これは、その組織のリスク許容度に依存するからです。ここでは、クラウドサービスを通じた従業員による情報の持ち出しを脅威シナリオとして想定し、方針決定の一例をご紹介します。

方針決定の際に使える変数は、主に3種類に分かれます。それは、主体(誰が使うのか)・対象(どんな情報を取り扱うのか)・環境(サービス自身は信頼におけるか)です。

理念的には、対象(どんな情報を取り扱うか)によって方針を定めるべきです。極秘の新製品情報と一般的な社外秘情報とを同列に扱うべきではありません。ただし実運用上は、対象による方針決定はモニタリングを困難にします。通信の中身を追わなければならなくなるからです。

そこで実践的には、主体に沿って方針を決定します。業務分掌が確立していれば、組織によって取り扱う情報が大まかに決まりますから、ある程度の近似になります。ただし、CASBが取得するネットワーク機器(Webプロキシーなど)のログからはアカウント名しか分からないでしょうから、組織と紐づけるためにActive Directoryなどのディレクトリーサービスと情報連携する必要があります。

L7まで見られる高機能ファイアウォールを使ってセキュリティゾーンを定義しているなら、その分類を活用するのが最善です。その際にはユーザーやセキュリティグループ単位で各ゾーンのアクセス制御を行っているでしょうから、それをクラウドサービスにも準用するのです。そうすれば、社内ネットワークと一貫性のある方針になります。

可視化されたサービスのラベリングが完了したら、定常運用に入ります。日次でモニタリングして新たに観測されたサービスをラベリングし、届け出のないサービス利用を発見したら正規手続きを促します。

最後に1点、注意すべき点があります。それは、CASBがクラウドサービスだと認識していないSaaS/ASPが、我が国にはたくさんあることです。届出制を採用している場合には、届けられたサービスがCASBに載っているかどうかをチェックし、載っていない場合には照会する手続きが発生します。CASBによってはアップロードのバイト数からSaaS/ASP候補を出力する機能がありますので、その機能を使って能動的に発見することもできるかもしれません。

〈お断り〉

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

 

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

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

2018年8月12日
CSAジャパン 諸角昌宏

第10回クラウド利用者会議では、「RPAと法律的な問題点」というテーマで高橋氏にご説明いただいた。会議は、7月30日(月)に開催し、クラウド利用者を中心として10名に参加いただいた。

まず、ロボットにおける用語とRPAとの関係について触れられた。ロボットとして以下の2つの用語の定義を明確にしておく必要がある:

  • ロボテック: プログラムに基づいて合理化すること
  • 法律的: マニプレーターと記憶装置が必要であること

その上で、RPAはどうなるかというと、自律的な操作が表現されたエキスパートシステムであるということができる。ただし、RPA自体がバズワード化しており、実際に何を差すのかは明確にしずらい状況である。

その中で、RPAとはということでは、以下の3つの手段に分かれる:

  1. 定型業務の自動化: いわゆるRPAとしての狭義の意味になる
  2. EPA(Enhanced Process Automation)とAIの使用: 大量のデータを解析し結果を出力できる機能
  3. コグニティブ・オートメーション: ディープラーニング、自然言語処理などにより、自立した結果を出力し経営意思決定に結び付ける能力

これらを踏まえてRPAを含むロボットの問題として、以下の3つの領域で考える必要がある:

  • 安全/セキュリティ
    安全基準/保安基準がどうなるのか?プログラムでコントロールされるということは、保安基準の無い世界である。つまり、規定がプログラムを前提としていない。
  • 自立性の限界(ロボットと操作者)
    最終的に人間がオーバーライトできる(自立の度合いによる)ことを認める必要がある。たとえば、運転所のいない場合の法律の問題など。
  • 外部とのかかわり(データ保護、市場力の乱用)
    個人データ保護の問題。

さて、これらの内容に基づいて参加者による議論が行われたが、以下のような内容になる。

まず、RPAの利用範囲が様々である点が議論された。SIEM/SplunkをRPA/AIとしているケースもあり、何をもってRPAとするか、また、RPAのセキュリティ上の問題としてどう捉えるかということになる。1つの観点として、自律しているかで分けるということがあるが、自律をどのように判断するかという問題がある。プログラム化した場合に問題が発生した場合、どのように判断するかという問題となる。そうすると、プログラムのバグかどうかが分からない場合、法律的にどう判断するかという問題となる。

現状は、RPAのセキュリティ上の問題は、EUC(End User Computing)のリスク管理にならざるを得ないということになる。業務アプリのIT統制として、ユーザ自身が守っていく必要がある。アクセス制御による保護、テストがきちんと行われている、使用のルールが定められていて利用者が守っていることなどである。また、RPA自体を正式なものとして承認されていることも重要になる。なお、中国ではRPAのことを「工作自動化平台」(RPAプラットフォーム)と呼ぶらしい。現状のRPAを表す言葉として、この中国の呼び方の方が近い感じである。

また、RPAは無人化を可能にするかという議論になった。いわゆる自律できるかどうかということである。こちらは、強いAIと弱いAIということで、現状では無人化した場合のセキュリティは難しいと思われる。強いAI、つまり、自分で自分の手を考えられるという自律ということを考慮する必要があるということになる。

実際、現場では、RPAの導入においては内部統制では使用しないという推奨を行っているということも示された。RPAにおけるリスク(誤入力、架空の処理)については、確認者による二重チェックが必要である。

以上のような状況であるが、RPAを含むIoTに対する安全基準は日本がリードしている、特に、電力関係の保安基準や、IPAのSTAMP(System Theoretic Accident Model and Processes)に対する取り組みなどがあり、今後も伸ばしていくことがきたいされるということである。

RPAと法律ということで難しいテーマであり、方向性を導くというよりは抱えている問題を出し合う会議となった。今後シンギュラリティとかも考えていくと、セキュリティ面でも法律面でもいろいろと議論が進むことになるが、我々もしっかりとらえていく必要がある。

なお、会議後のご意見として以下のような議論のポイントが指摘されました。今後、あらためて検討していきたいと思います。

①    定義論について
論点1)RPAを、ロボットと見做すか、Excelのマクロ関数もどきと見做すか
論点2)RPAを、開発者責任と見做すか、所有者責任と見做すか
論点3)RPAを、シーケンス型制御と見做すか、自律学習型回帰制御と見做すか

②    法的拘束力について
RPAに関するモノに物理的棄損を課した際の帰属の在り方
RPAを利活用したAPIで自動送金した際の誤送金の帰属の在り方
RPAに関する司法手続に関する法制度の在り方
RPAに関する犯罪捜査及び刑事訴訟の在り方、法廷監査の効力を含めた議論
RPAに関する民事訴訟や裁判外紛争解決の手続の在り方

➂課題解決の私見
公開APIの様に、公共のサイバー空間において利活用が進むにつれて、RPA動作空間と、人の意思決定空間の分離が、一つの有効手段になるかと考えています。例えば、歩道と車道が分離した道路交通法や、対人・対物の自賠責保険の様な社会的保障の仕組みが参考になると考えています。RPAでなないが、自動運転車レベル4になれば、即、現実化しますね。

以上