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

クラウドにおける遠隔医療のデータリスク管理

クラウドにおける遠隔医療のデータリスク管理

英語では、「遠隔医療」を意味する単語に、「Telemedicine」と「Telehealth」がある。前者は、ICTを活用した臨床診断やモニタリングなど、狭義の遠隔医療を指しているのに対して、後者は、臨床医療に限らず、健康増進や介護福祉など、幅広いサービスを包含するような広く定義を有しており、遠隔で医療提供者を患者につなげるために、キオスクや、webサイトモニタリングアプリケーション、モバイルフォン、ウェアラブル機器、ビデオ会議などの革新的な技術を利用する。

ここでは、「遠隔医療」について、情報通信技術を活用した健康増進、医療、介護に資する行為と定義する。遠隔医療を大別すると、専門医師が他の医師の診療を支援するDoctor-to-Doctor(D2D)分野と、医師が遠隔地の患者を診療するDoctor to Patient (D2P)分野が含まれる。

在宅医療の普及に伴い、D2P分野の研究開発が急展開してきたが、新型コロナウイルス感染症(COVID-19)緊急対応下における外来診療の代替手段として一気にニーズが高まり、米国政府の「コロナウイルス支援・救済・経済保障(CARES)法」に基づく遠隔医療推進目的の経済インセンティブ施策が追い風となっている。

サイバーセキュリティの領域では、米国立標準技術研究所(NIST)傘下の国立サイバーセキュリティセンターオブエクセレンス(NCCoE)が、遠隔患者モニタリング(RPM)など、遠隔医療機能を活用する医療提供組織(HDO:Healthcare Delivery Organization)が直面するセキュリティ/プライバシーリスクの研究に取り組んでいる。具体的な活動としては、2021年5月6日に「NIST SP 1800-30 遠隔医療の遠隔患者モニタリングエコシステムのセキュア化」草案第2版 (https://csrc.nist.gov/publications/detail/sp/1800-30/draft) などを公開している。

クラウドセキュリティアライアンスでは。遠隔医療のサイバーセキュリティに関連して、ヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)が、  2020年6月16日  「クラウド上の遠隔医療データ」 (https://cloudsecurityalliance.org/artifacts/telehealth-data-in-the-cloud/) を公開している。この文書は、クラウド環境上で、遠隔医療ソリューション向けに、患者データを処理、保存、転送する際のプライバシー/セキュリティ課題と対策についてまとめたものであり、以下のような構成になっている。

  • イントロダクション
  • プライバシーの懸念
  • セキュリティの懸念
  • ガバナンス
  • コンプライアンス
  • 機密性
  • 完全性
  • 可用性
  • インシデント対応と管理
  • 継続的なモニタリングプログラム
  • 結論
  • 参考文献

遠隔医療におけるクラウド利用とプライバシー/セキュリティ

このうち、プライバシーの懸念についてみると、米国の医療保険の相互運用性と説明責任に関する法律(HIPAA)と、欧州連合(EU)の一般データ保護規則(GDPR)を取り上げ、それぞれのプライバシー要求事項を挙げている。特に、遠隔医療で利用される保護対象保健情報(PHI)にアクセスする情報システムを標的にしたサイバー攻撃が急増していることから、遠隔医療のクラウドサービス利用に関する同意書について、以下のような項目に留意する必要があるとしている。

  1. 遠隔医療プロバイダー(TP)は、プライバシー通知の中で、どのPHIが収集・利用・維持・共有されるかに関する目的を記述しているか?
  2. TPは、保護対象保健情報(PHI)を含むプログラムや情報システム、技術に関する適正なプライバシー/セキュリティのコントロールを運用する、業務上のプライバシーポリシーおよび手順を保有し、広め、展開しているか?
  3. TPは、プライバシー影響度評価を実施して、それを共有する意向があるか?
  4. 医療提供組織(HDO)は、プライバシーの役割や、責任、外部委託先およびサービスプロバイダー向けのアクセス要求事項を有しているか?
  5. TPは、効果的な展開を保証するために、プライバシーコントロールおよび内部のプライバシーポリシーをモニタリングし、監査しているか?
  6. TPは、プライバシーコントロールを自動化することによって、プライバシーを支援するために、情報システムを設計しているか?
  7. TPは、コントロール下にある記録システムが保有する情報の開示について、正確な説明を維持しているか?
    1. 個々の記録の情報開示の日付や性質、目的
    2. 開示された個人または組織の名前、住所
    3. 情報開示を承認した主体
  8. TPは、既存のセキュリティコントロールを通して、PHIの完全性を保証するためのプロセスを文書化しているか?
  9. TPは、法的に権限付与された収集目的を達成するために、適切で必要な、最小限のPHI要素を特定しているか?
  10. TPは、個人が、収集前に、PHIの収集や、利用、維持、共有の権限を付与する手段を提供しているか?
  11. TPは、組織的なプライバシーのプラクティスに関する個人からの苦情や懸念、質問を受け付けて対応するためのプロセスを有しているか?
  12. TPは、公衆および個人に対して、PHIの収集や利用、共有、保護、維持、廃棄など、プライバシーに影響を及ぼす活動に関する十分な通知を提供しているか?
  13. TPは、外部とPHIを共有しているか?

他方、セキュリティの懸念についてみると、遠隔医療向けのセキュリティモデル構築時に、公衆インターネット経由でアクセスするというパブリッククラウドサービスの特徴を考慮する必要があるとしている。また、アクセスコントロールやユーザーのプロビジョニング向けの内部ポリシーなど、エンドツーエンドのセキュリティを考慮する必要があるとしている。

さらに、HIPAAセキュリティ規則の要求事項に基づくセキュリティリスク分析では、SOC2、HITRUST、FedRAMP、CSA-STARなど、クラウドサービスプロバイダーに対する第三者評価制度の活用を推奨している。その際の確認事項として、以下のような点を挙げている。

  • ガバナンス
  • コンプライアンス
  • 機密性(Confidentiality)
  • 完全性(Integrity)
  • 可用性(Accountability)
  • インシデント対応管理

遠隔医療におけるクラウド利用のガバナンス/コンプライアンス

次にガバナンスについてみると、クラウドサービスにおける責任共有モデルの観点から、以下のような確認事項を挙げている。

  1. サービスプロバイダーのサービスレベル合意書(SLA)は、サービスプロバイダーがすべての顧客情報の機密性、完全性、可用性を保護する方法を明確に定義しているか?
  2. サービスプロバイダーのSLAは、HDOがデータの所有権を保持することを特定しているか?
  3. サービスプロバイダーは、サービス提供以外の目的でデータを利用するか?
  4. サービスプロバイダーのサービスは、第三者のステークホルダーに依存しているか?

また、コンプライアンスについてみると、複数の法令遵守を前提とする遠隔医療サービスの観点から、以下のような確認事項を挙げている。

  1. クラウドサービスプロバイダーは、HDOが、サービスおよび保持するデータを保護するために設定したセキュリティ対策の展開や管理を直接監査することを許容しているか?
  2. サービスプロバイダーは、HDOが直近の監査報告書を完全にレビューすることを許容しているか?
  3. サービスプロバイダーは、HIPAAを遵守しているか?
  4. サービスプロバイダーは、GDPRを遵守しているか?

なお、クラウドサービス全般のコンプライアンス管理については、CSAの「クラウド環境におけるセキュリティリスク、コンプライアンス、設定ミスの状況」(https://www.cloudsecurityalliance.jp/site/?p=20725)で取り上げている。

遠隔医療のセキュリティリスク評価とクラウド環境のCIA

前述のHDOのセキュリティリスク分析や、クラウドサービスプロバイダーの第三者評価において、重要な役割を果たすのは、情報セキュリティの機密性(Confidentiality)、完全性(Integrity)、可用性(Accountability)である。CSAの文書では、いわゆるCIAに係る確認事項として、以下のような項目を挙げている。

[機密性に関する確認事項]

  1. 権限付与とアクセスコントロール
    1. HDOは、クラウドサービスの採用を支援するアイデンティティ管理戦略を持っているか?
    2. ライフサイクルを通じてアイデンティティが管理・保護されていることを保証する、効果的な内部プロセスがあるか?
    3. ユーザーアカウントが適切に管理・保護されていることを保証する、効果的な監査プロセスがあるか?サービスプロバイダーは、これらのコントロール要件を満たしているか?
    4. すべてのパスワード(特にシステム/サービス管理者)は暗号化されているか?
    5. 多要素認証は要求されるか、そうであれば、利用可能か?
    6. 認証やアクセスコントロールは、機器に拡張されているか?
  2. マルチテナント
    1. サービスプロバイダーは、HDOが、顧客データの仮想化や分離に関するセキュリティコントロールおよびプラクティスの評価を含む、直近の第三者監査報告書をレビューすることを許容しているか?
    2. サービスプロバイダーの顧客登録プロセスは、クラウドサービスにおける情報の重要性と機微性に基づき、適正な保証レベルを提供しているか?
  3. パッチ・脆弱性管理
    1. サービスプロバイダーは、クラウドサービスを構成するすべてのコンポーネントにパッチ当てする責任を有するか?
    2. サービスプロバイダーのSLAには、定義された最大限の露出期間を含むパッチ・脆弱性管理向けのサービスレベルが含まれているか?
    3. HDOは現在、効果的なパッチ・脆弱性管理プロセスを有しているか?
    4. サービスプロバイダーは、HDOが定期的に脆弱性評価を実行することを許容しているか?
  4. 暗号化
    1. サービスプロバイダーは、保存時および転送時双方のデータについて、クラウドサービス上にある情報を暗号化しているか?
    2. クラウドサービスは、承認済の暗号化プロトコルやアルゴリズム(連邦情報処理基準140-2で定義)のみを利用しているか?
    3. どの主体が、暗号鍵管理に責任を有するか?
    4. 各顧客向けに、別の鍵はあるか
  5. データ永続性
    1. サービスプロバイダーは、次のユーザーが利用可能になる前に、ストレージメディアのセキュアな無害化のための監査可能なプロセスを有しているか?
    2. サービスプロバイダーは、顧客データを含む装置およびストレージメディア(例.ハードディスクドライブとバックアップテープ)の安全な廃棄または破壊のための監査可能なプロセスを有しているか?

[完全性に関する確認事項]

  1. サービスプロバイダーは、データの損失や不正から保護するために提供する標準的なサービスの一部として、データバックアップやアーカイブサービスを提供しているか?
  2. データバックアップやアーカイブサービスは、どのような形で提供されているか?
  3. データバックアップやアーカイブサービスは、データ損失に対する保護に関連したビジネス要求事項を忠実に守っているか?
  4. サービスプロバイダーは、データの復元向けに、どのレベルの粒度を提供しているか?
  5. サービスプロバイダーは、データがバックアップメディアから復旧可能であることを保証するために、定期的に復元テストを実行しているか?

[可用性に関する確認事項]

  1. SLAには、明確に規定された期間中、想定された最小限の可用性パフォーマンス比率が含まれているか?
  2. SLAには、明確化、スケジュール化された停止期間が含まれているか?
  3. サービスプロバイダーは、分散型サービス妨害(DDoS)攻撃に対して保護することができるプロトコルや技術を有効活用しているか?
  4. HDOが直接管理または契約しているネットワークサービスは、充分なレベルの可用性を提供しているか?
  5. HDOが直接管理または契約しているネットワークサービスは、適切なレベルの冗長性/フォールトトレランスを提供しているか?
  6. HDOが直接管理または契約しているネットワークサービスは、適切なレベルの帯域幅を提供しているか?
  7. HDOのネットワークとサービスプロバイダーのサービスの間のレイテンシーは、望ましいユーザーエクスペリエンスを達成するために受容できるレベルにあるか?

遠隔医療に係るインシデント対応管理

本文書では、クラウドサービスを利用した遠隔医療のインシデント対応管理に関連して、以下のような確認事項を挙げている。

  1. サービスプロバイダーは、情報セキュリティインシデントを検知し、対応する方法を明確に定義した計画とともに、公式のインシデント対応および管理プロセスを有しているか?
  2. サービスプロバイダーは、定期的に、インシデント対応管理プロセスと計画を検証し、洗練しているか?
  3. サービスプロバイダーのSLAは、情報セキュリティが発生したらHDOに提供する支援を明確に定義しているか?
  4. サービスプロバイダーは、HDOが、規制当局による調査に効果的に協力できるようにするために、十分な情報を供給するか?
  5. サービスプロバイダーのインシデント対応計画は、規制上の要求事項を満たすために、報告に関する要求事項を明確に定義しているか?

なお、クラウドサービス全般のインシデント対応管理については、CSAの「「クラウドインシデントレスポンス(CIR)フレームワーク」(https://www.cloudsecurityalliance.jp/site/?p=18167)で取り上げている。また、医療機器に焦点を当てたインシデント対応管理については、CSA IoT WGの「医療機器インシデント対応プレイブック」(https://cloudsecurityalliance.org/artifacts/csa-medical-device-incident-response-playbook/)で取り上げている。

最後に、本文書では、遠隔医療向けの情報セキュリティ/プライバシー/コンプライアンス・プログラムの中に、継続的モニタリングのためのツール・管理策として、CSA-STAR認証や、クラウド・アクセス・セキュリティ・ブローカー(CASB)を挙げている。日本の医療業界ではあまりなじみがないが、米国では、今後の利活用が期待される領域となっている。

医療におけるブロックチェーン利用

2021年3月4日、米国のモデルナとIBMは、ブロックチェーン技術を利用して、新型コロナウイルス感染症(COVID-19)ワクチンのサプライチェーンおよび輸送データの共有における連携する計画を発表した。このような医療分野のブロックチェーン利活用に向けた動きは、医療機関や保健医療行政機関、医療保険者の間でも本格化している。

医療機関から見たブロックチェーン技術の機能と特徴

医療ブロックチェーンに関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2021年7月、ブロックチェーン技術を利用する医療機関を対象として、「医療におけるブロックチェーン利用」(https://cloudsecurityalliance.org/artifacts/the-use-of-blockchain-in-healthcare/)を公開している。同文書は、以下のような構成となっている。

・イントロダクション
・ブロックチェーン
・全般
・研究
・サプライチェーン
・財務管理
・施設・エネルギー管理
・遠隔医療
・患者管理
・医療のケースにおけるブロックチェーン
・ディスカッション
・結論

イントロダクションでは、遠隔医療向けブロックチェーン技術の主要機能として、以下の6項目を挙げている。

①分散化:
・電子健康記録(EHR)が、複数の場所で、保存、アクセス、管理される
・ネットワークが、多くの主体によってコントロールされる
・コンセンサスプロトコルが、ネットワークを統治する
②不変性:
・患者の電子健康記録(EHR)や個人健康記録(PHR)が変更できない
・非対称鍵暗号やコンセンサスプロトコルが医療健康記録の不変性を保証する
③透明性:
・透明性が、患者中心の共有データのコントロールと、情報ユーザーによる疑わしい行為に関する問い合わせを促進する
④オープンソース:
・アクセス・患者が、遠隔診療の予約をする前に、医師のプロファイルにアクセスできる
・規則正しい法令遵守の運用を保証するために、記録が保護される
⑤監査可能性:
・医薬品管理当局が、医薬品の来歴を追跡できる
・規則正しい法令遵守の運用を保証するために、記録が保護される
⑥匿名性:
・遠隔医療参加者のアイデンティティを匿名化する
・データや転送がセキュア化される

そして、ブロックチェーン/分散台帳技術(DLT)の特徴について、以下のように概説している。

①分散台帳技術(DLT):
・修正や複製ができないような、分散型のセキュアな形態で取引(Transaction)を記録する
・一覧の複数の複製が存在し、情報のなりすましが極めて困難になっている
②ブロックチェーン:
・“1対N”の取引を含む、物理的な固定⾧のブロックから構成されるデータベース
・「取引を追加する」または「取引を閲覧する」のみが実行可能であり、ブロックチェーンを、様々な医療アプリケーション向けに理想的なものにする
・個々のブロックチェーンには、生成されるブロックが妥当か否かを決定し、妥当なブロックだけがチェーンに追加されるという一連のルールが存在する
③スマートコントラクト:
・コードに組み込まれた自己強制的な同意書であり、監査可能で強制可能なガバナンスルールとビジネスロジックをコードに組込む、透明で検証可能な方法を提供する

医療サプライチェーンの「RegTech」として期待されるブロックチェーン

このような点を踏まえ、本文書では、医療機関の業務プロセスの中で、ブロックチェーン技術の適用が想定される分野・領域の動向について概説している。
たとえば、前述のCOVID-19ワクチンで注目される医療サプライチェーンについては、以下のようなブロックチェーン技術導入のメリットを挙げている。
・ブロックチェーンは、医療サプライチェーンのトレーサビリティに関連して、様々な主体がアクセス可能な、オープンで、安全で、改ざんを防止するシステムを提供する
・スマートコントラクトを利用したブロックチェーン技術は、リアルタイムな契約の追跡や展開を提供し、契約が成功裏に完了したかをユーザー側で判断できるようにする
・医療におけるブロックチェーンは、サプライヤー契約を自動化し、製品およびサービスに関する幅広いメタデータに分析を適用できる場合があり、その結果が生産性を改善し、費用を削減し、品質コントロールを改善する可能性がある

米国では、2013年11月27日、偽造医薬品対策を目的として「医薬品サプライチェーン安全保障法(DSCSA)」が制定されており、同法に基づいて食品医薬品局(FDA)は、医療用医薬品に商品コード、ロット番号、有効期限、ランダム番号を含む2次元バーコードを表示し、医薬品製造業者から、再包装業者、卸売業者/サードパーティーロジスティクス・プロバイダー、医療機関・薬局に至るまでのサプライチェーンの各段階で、トレーサビリティを電子的に管理するための取組を行っている。法令遵守の観点から、サプライチェーンの最下流に位置する医療機関の役割は大きく、「RegTech」(規制対応のためのITソリューション)として、ブロックチェーン技術への期待も高まっている。

ブロックチェーン固有のサイバーセキュリティ課題と管理策

このように、データ保護の観点から注目されるブロックチェーン技術であるが、過去に金融業界で続発した暗号資産・仮想通貨取引プラットフォームのサイバーインシデントを見ればわかるように、万全ではない。本文書では、ブロックチェーンのセイバーセキュリティ課題として、以下のような点を挙げている。

①ブロックチェーン技術だけでは、サイバーセキュリティのリスクを解消することができない
・ブロックチェーン技術システムのセキュリティを保証するためには、医療機関が既存の標準規格やガイドラインを遵守する必要がある(データストレージのセキュリティがブロックチェーンセキュリティの要であるため、クラウドセキュリティは特に重要となる)
②ブロックチェーン技術は、一度トランザクションが完了すると、改ざん防止上安全であるが、公開されたブロックに含まれる前に攻撃を受けると脆弱である
③ブロックチェーン技術は、時間のなりすましの影響を受ける可能性があり、スマートコントラクトにおけるトランザクションの順序やサービス拒否(DoS)攻撃に影響が及ぶ事がある
④鍵管理は、ブロックチェーンセキュリティの要であり、オンライン鍵管理サービス(KMS)やユーザーによる管理を採用する場合がある一方、管理の複雑性やユーザーエンドのセキュリティ脆弱性が課題となる

⑤その他のブロックチェーンのリスク
・ビジネスとガバナンス
・プロセス
・技術

本文書では、このような課題を解決する管理策として、以下のようなソリューションを挙げている。

①ブロックチェーンのソリューションやデータにアクセスするアイデンティティ/アクセス制御を強制する
②API機能を不適切な利用から保護し、トランザクションのスコープを制限するために、APIベースのトランザクションを保護するAPIセキュリティのベストプラクティスを利用する
③内部および外部のコンポーネント間のプラットフォームコミュニケーションが、共通または標準的なTLS(1.2以上)を利用したセキュリティの高いチャネルを介して相互作用することを保証する
④ブロックチェーン識別鍵、内部TLS認証、外部TLS認証、ドメイン認証など、ブロックチェーン鍵を管理するための強健な信頼できる鍵管理ソリューションを利用する(暗号化は、連邦情報処理システム(FIPS)140-2以上)
⑤組織のブロックチェーンソリューション展開のすべての段階で、テストを実施し、個々のコンポーネントレベルで、脆弱性評価を行い、システム全体でペネトレーションテストを実行する

中国メガ・プラットフォーム事業者のユースケースを参照

なお、本文書は北米の医療セキュリティ専門家が中心となってとりまとめられたが、医療ブロックチェーンのユースケースとして、以下のように、中国の主要プラットフォーム事業者の事例を紹介している。

①百度(Baidu):
・2020年1月、オープンネットワーク・ブロックチェーン・プロジェクトの「Xuperchain」パブリックデータ版をリリース
-目的:医療機関の処方せん、医薬品配送、収集情報を記録し、医師が薬局と遠隔で電子処方せんを処理できるようにして、患者の体験を簡素化する
-Blockchain as a Service(BaaS)やBaidu Blockchain Engine(BBE)を提供(Ethereum、Hyperledger、Fabric、Solidityスマートコントラクトをサポート)
②阿里巴巴(Alibaba):
・2017年、医療ブロックチェーンを立ち上げ、支付宝(AliPay)とともに医療IT企業の阿里健康信息技術を設立
・アリババクラウドのクラウドブロックチェーンサービス(BaaS)と支付宝のアントブロックチェーン技術をベースに、医療機関が、処方せんや薬剤師チェック、医薬品配送、医薬品支払の管理、医療プロセスの監督をすることを可能にする
③腾讯(Tencent):
・共済保険スタートアップ企業の水滴(Waterdrop)とブロックチェーン強化型医療保険ソリューション(例.効率的な請求支払いシステム、不正請求を防止する監査可能な医療情報ストレージ)の開発で提携
・2019年11月、安徽省で、医療機関向けの電子健康カード+ブロックチェーンソリューションを立ち上げる(部門や医療機関、地域の枠を越えたデータリソース統合を促進)

(関連情報)
・IBM「Moderna and IBM Plan to Collaborate on COVID-19 Vaccine Supply Chain and Distribution Data Sharing」(2021年3月4日)
https://newsroom.ibm.com/2021-03-04-Moderna-and-IBM-Plan-to-Collaborate-on-COVID-19-Vaccine-Supply-Chain-and-Distribution-Data-Sharing

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について

本ブログでは、STAR Level1セルフアセスメントの重要性および日本語での評価レポートの公開方法について記述します。

2021年10月20日
CCM/STAR WGメンバー 諸角昌宏

クラウドサービスプロバイダが、提供するクラウドサービスのセキュリティ情報を公開することは非常に重要です。クラウドセキュリティにおける責任共有モデルにおいては、クラウドサービス利用者は、自身が管理するセキュリティとプロバイダが管理するセキュリティの両方を把握し説明責任を果たすことが必要で、そのためには、利用するクラウドサービスのセキュリティレベルを把握する必要があります。これは、利用者がプロバイダに直接確認することで行えますが、たくさんの利用者を抱えているプロバイダが、利用者ごとの問い合わせに対応することは非効率です。そこで、プロバイダが、提供しているクラウドサービスのセキュリティ情報をあらかじめ公開することで、利用者は公開された情報に基づいてクラウドサービスのセキュリティレベルを把握することができます。また、プロバイダは、利用者からの個別の問い合わせに対応する作業を削減することができますし、セキュリティ情報を積極的に公開することにより、セキュリティをビジネス上の差別化要因とすることができます。

STAR Level1セルフアセスメントは、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionnaire)に、プロバイダが自己評価した結果を記述し、それを公開するウエブサイト(CSA STAR Registry: https://cloudsecurityalliance.org/star/registry/)を提供しています。このCSA STAR Registryには、STAR認証が提供する3つのレベルの情報が公開されていますが、CAIQの評価レポートは、STAR Level1 セルフアセスメントとして公開されています。STAR Level1 セルフアセスメントのようなセキュリティの透明性に対する取り組みは、特に欧米のプロバイダは積極的に行っています。CSA STAR Registryには、1000以上のクラウドサービスが登録されていますが、その大部分がSTAR Level1セルフアセスメントとしてCAIQ評価レポートを公開しています。

CSAジャパンでは、日本のプロバイダが積極的にセキュリティ情報を公開できるように支援していきます。以下の2つのアプローチになります。

  1. 日本語CAIQ評価レポートの登録手順を日本語で提供
    STAR Level1 セルフアセスメントの登録手続きは、英語で行う必要があります。会社名やクラウドサービス名、およびそれらの概要等は、英語で記述する必要があります。CSAジャパンでは、日本語CAIQ評価レポートの作成から、STAR Level1 セルフアセスメントの登録までの一連の手順を日本語で記述しました。以下のウエブサイトを参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005
  2. 日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開
    CSA STAR Registryには、すべてのクラウドサービスの情報がアルファベット順にリストされています。この中から、日本語CAIQ評価レポートを公開しているプロバイダ及びクラウドサービスを探すことは難しいです。そこで、CSAジャパンでは、CSAジャパンのウエブサイトから、日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開することとしました。以下のウエブサイトになります。
    https://www.cloudsecurityalliance.jp/site/?page_id=19811
    なお、日本語 CAIQ評価レポートを公開されているプロバイダ及びクラウドサービスをすべて把握することが難しく、このサイトの情報はCSAジャパンが把握できているもののみになります。日本語 CAIQ評価レポートを公開されていて、このサイトにリストされていないものがありましたら、以下のメールアドレスまでご連絡ください(注意: @の前後のクオーテーションを削除してください)。 info’@’cloudsecurityalliance.jp

以上

CSAの認証制度:STAR認証について

STAR認証について

2021年10月7日
CCM/STAR WGメンバー: 諸角昌宏

本ブログでは、CSA(Cloud Security Alliance)が提供するSTAR(Security, Trust & Assurance Registry)認証について、その概要、特徴、利用方法、CSAジャパンの活動について説明します。特に、STARレベル1(セルフアセスメント)について、プロバイダがクラウドサービスの自己評価レポートをCSA本部のウエブサイトより公開する方法について記述します。

  1. STAR概要

    STARは、CSAが提供するクラウドセキュリティの認証制度です。大きなフレームワークは以下の図1で示すように、3つのレベルを持っています。また、それぞれのレベルに対して、「セキュリティ認証」と「プライバシー認証」の2つのカテゴリーがあります。

    図1 STARフレームワーク

まず、「STAR認証レベル」について説明します。

  • STAR Level1

    STAR Level1はセルフアセスメントです。これは、クラウドサービスプロバイダが、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionaire)に基づいて、自身が提供するクラウドサービスのセキュリティを独自に評価し、CSAのウエブサイト(https://cloudsecurityalliance.org/star/registry/)から公開するものです。CAIQは、CSAが提供するクラウドセキュリティの管理策集であるCCM(Cloud Control Matrix)のそれぞれの管理策について、いくつかの質問形式にブレークダウンしたものです。質問形式になっているため、クラウドサービスプロバイダは「YES」「NO」で回答することができます。また、回答に対するコメントを入力し、追加の情報を記述することができます。
    STAR Level1の特徴は、クラウドサービス利用者が、利用しようとしているクラウドサービスが自組織のセキュリティ要求事項を満たしているかどうかを、公開されている情報をもとに確認できることです。つまり、プロバイダの透明性が実現できているということになります。また、プロバイダの立場では、セキュリティ情報を積極的に公開することで、たくさんの利用者に対して統一したメッセージを出すことができますし、この情報をビジネス上の差別化要因として利用することもできます。
    STAR Level1の登録方法について、以下のウエブサイトに日本語で記述していますので参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005

 

  • STAR Level2

    STAR Level2は、第三者評価になります。クラウドセキュリティの評価としてCCMを使用しますが、以下の示す他の業界認定や標準を基にして、クラウドセキュリティを評価しています。

    • CSA STAR CERTIFICATION: ISO/IEC 27001
    • CSA STAR ATTESTATION: SOC2
    • CSA C-STAR: GB/T22080-2008

STAR Level2の特徴は、認証だけでなく成熟度も評価していることです。クラウドサービスの成熟度を「ブロンズ」「シルバー」「ゴールド」のレベルとして認定します。
以下の図はSTAR CERTIFICATIONを表しています。

図2 CSA STAR CERTIFICATION 成熟度モデル

  • STAR Level3

    STAR Level3は、継続的モニタリングです。認証取得後も、その対応状況を継続的にモニタリングし保証する制度で、FedRAMPなどのハイレベルの情報を扱う際に要求されているものです。こちらは、まだ準備中になりますので、提供され次第ご案内できると思います。

それから、Level1、Level2には、Continuous Self-assessmentがあります。これは、通常の1年に1回の認証に対して、より頻度を上げた認証を行うようにしたものです。

次に「セキュリティ認証」と「プライバシー認証」について説明します。

  • セキュリティ認証

    セキュリティ認証は、上記で記述したように、CCMあるいはCAIQを用いて認証を行うものです。

  • プライバシー認証

    プライバシー認証は、クラウド環境におけるデータ保護法令遵守に必要な要件を定義した管理策であるCode of Conduct for GDPRを使用して認証を行うものです。GDPR向けの行動規範に準拠しているかどうかを認証します。

 

  1. STAR認証の特徴

    STAR認証では、今までの認証制度の課題として以下の3点を挙げ、それぞれに対して取り組んでいます。

    • 認証の継続性

      認証は「ある時点 (point-in-time)」あるいは「ある期間 (period-of-time)」を対象とするアプローチです。これは、変化の激しいクラウド環境においては不十分であることが指摘されています。STAR Level1/Level2 Continuous Self-assessmentでは、頻度を上げた形での認証を行うことで、より現実に近い認証を行っています。これにより、クラウドサービス利用者に対して、セキュリティ管理策の実施状況に関する詳細な最新情報を提供できるようになります。また、STAR Level3が提供されるようになると、よりリアルタイムに近い認証が実現できることになります。

    • 認証の透明性

      第三者認証(STAR認証ではLevel2)では、クラウドサービスの可視化を高いレベルで確保することが難しいです。STAR認証の各レベルは、それぞれ独立して運用するのではなく、組み合わせることでより高いレベルの認証を実現できます。たとえば、Level1とLevel2を組み合わせることで、高い保証(第三者認証)と高い透明性(セルフアセスメント)の両方を実現できます。以下の図は、STAR認証の各レベルの関係を表現したものです。

      図3 保証と透明性

    • 相互認証スキーム

      STAR認証のベースになるCCMは、数多くの国単位/分野単位の基準/規格へのマッピングを提供しています。CCMでは、各規格とのマッピングとリバースマッピングを提供し、それぞれの規格との差異(ギャップ)を分析し、その情報を公開しています。理想としては、1つの認証を取得することで、その他の認証に関してはギャップ分だけやればよいことになり、1つの認証の取得から別の認証の取得までの労力を最小化することができます。あくまで最小化のレベルであり、これで相互認証できるというわけではないことは注意が必要ですが、様々な組織(EU-SECやFedRAMPなど)とのフレームワークの検討が進んでいますので、その進捗に期待したいと思います。

  2. STAR認証に対するCSAジャパンの取り組み

    CSAジャパンでは、以下の取り組みを行っています。

    • STAR認証に関する情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=429

    • CCM/CAIQの日本語化および情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=2048#ccm

    • STAR Level1(セルフアセスメント)の日本語での公開

      CAIQの評価レポートを日本語で作成し、それを公開する手順について以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=1005

    • 日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの公開

      CSAジャパンでは、STAR Level1 セルフアセスメントの登録において、日本語CAIQ評価レポートを登録されたプロバイダおよびそのクラウドサービスに関する情報を公開しています。CSA本部のSTAR Registryでは、CAIQ評価レポートとして日本語で提供されているかどうかを判断するのが難しいです。そこで、CSAジャパンでは、日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの情報を公開することで、日本の利用者が利用できるようにしています。
      公開ウエブサイトは以下になりますので参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=19811

以上

 

MS、アマゾン、グーグルらがクラウドデータの保護など目指す「Trusted Cloud Principles」について

Microsoft、Amazon、Googleらが、「Trusted Cloud Principles」という新たな業界イニシアチブを発表しました。これから関わってくる可能性が高いと思われるので、その内容について翻訳してみました。なお、ここの翻訳は、あくまで個人的に行ったものであり、正式な形で翻訳の承認を取ったものではないことに注意してください。ここの訳はおかしいよというところがありましたらご指摘ください。
原文は、こちらです。

Trusted Cloud Principles(信頼できるクラウドの原則)

原則

世界中の組織は、イノベーションを推進し、セキュリティを向上させ、新しいデジタル経済で競争力を維持するためにクラウドテクノロジーを採用しています。クラウドサービスプロバイダとして、国境を越えて利用されるサービスとインフラストラクチャを運用することにより、あらゆる規模の企業、公共部門のエンティティ、非営利団体を含むこれらの組織をサポートします。

Trusted Cloud Initiativeは、イノベーション、セキュリティ、プライバシを妨げる国際的な抵触法を解決し、クラウドにデータを保存および処理する組織の基本的な保護を確立および確保するために、世界中の政府と組んでいくことを目指しています。このイニシアチブを通じて、私たちは政府と協力してデータの自由な流れを確保し、公共の安全を促進し、クラウド内のプライバシとデータセキュリティを保護することを約束します。

このイニシアチブは、社内の人権影響評価を実施するなど、この分野で各企業が行った既存の取り組みに基づいています。これは、企業が取り組むベースラインとして機能します。

クラウドプロバイダとして、以下を主張します;

  • グローバルクラウドサービスを使用する個人および組織の安全性、セキュリティ、プライバシ、および経済的活力を保護することへの世界中の政府の関心を認識します。
  • 国際人権法がプライバシの権利を大事にしていることを認識します。
  • 利用者の信頼と、利用者のデータの管理とセキュリティの重要性を認識します。これには、利用者がクラウドで所有するデータの保護と、その信頼を確立、維持、強化する製品とポリシーの作成の両方が含まれます。
  • 国際的に認められた法の支配と人権基準を遵守する透明なプロセスを通じて、政府がデータを要求できるようにする法律をサポートします。
  • データアクセス、プライバシ、および主権に関連する抵触法を解決するための国際的な法的枠組みをサポートします。
  • データアクセス、プライバシ、および主権に関連する抵触法を解決するための国際的な法的枠組みをサポートします。
  • クラウド利用者の安全性、プライバシ、セキュリティ、およびデータの所有権を保護する、国内および国際レベルでの改善された規則と規制をサポートします。
  • 政府のデータ要求に関する集計統計を詳述する透明性レポートを定期的に公開することの重要性を認識します。

私たちの目的を達成するために、私たちは世界中の技術部門、公益団体、および政策立案者と協力し、特にデータセンタとクラウドインフラストラクチャを運用または運用する予定の国で、法律とポリシーが実質的に次の原則に沿っていることを確実にします。

政府は、狭い例外を除いて、最初に利用者を関与させる必要があります。政府は、例外的な状況を除いて、クラウドサービスプロバイダではなく、企業の利用者から直接データを手に入れようとする必要があります。

利用者は通知を受ける権利を持っている必要があります。政府がクラウドサービスプロバイダから直接利用者データにアクセスしようとする場合、そのクラウドサービスプロバイダの利用者は、データへの政府アクセスの通知を事前に通知を受ける権利を有する必要があります。その通知は、例外的な状況においてのみ遅らせることができます。

クラウドプロバイダーは、利用者の利益を保護する権利を持っている必要があります。関連するデータ保護当局への通知を含め、クラウドサービスプロバイダーが利用者のデータに対する政府のアクセス要求に異議を申し立てる明確なプロセスが必要です。

政府は法の抵触に対処する必要があります。政府は、ある国でのクラウドサービスプロバイダーの法令遵守が別の国での法律違反にならないように、相互の対立を提起し解決するメカニズムを作成する必要があります。

政府は国境を越えたデータの流れをサポートする必要があります。政府は、イノベーション、効率、セキュリティのエンジンとして国境を越えたデータの流れをサポートし、データの常駐要件を回避する必要があります。

認証基盤のモダン化と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?” は、こちらを参照してください。