総論編(1)に引き続き、CSAのグローバル展開から生まれた知見や実績をベースとする基礎的なクラウドセキュリティプラクティスの啓発活動を紹介する。

サイバートラスト向けクラウドセキュリティ管理策の概要

前回紹介したように、シンガポールサイバーセキュリティ庁（CSA）の「CSAサイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4の間のクロスマッピング」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/cloud-security-companion-guide-cyber-trust.pdf）では、シンガポール情報通信メディア開発庁（IMDA）の「デジタルアクセラレーションインデックス（DAI）」（https://www.imda.gov.sg/how-we-can-help/digital-acceleration-index）のデジタル成熟度指標に準拠して、以下の通り、5つのサイバーセキュリティ対応準備段階を設定している。

• 「Advocate」: 先導的なデジタル成熟度を有する組織、大規模組織またはそれらで活動している人／規制セクター向けのプロバイダー
• 「Performer」: “Performer”のデジタル成熟度を有する組織、大・中堅規模組織
• 「Promoter」: “Literate”のデジタル成熟度を有する組織、中堅・大規模組織
• 「Practitioner」: “Starter” のデジタル成熟度を有する組織、中堅・小規模組織
• 「Supporter」: “Starter” のデジタル成熟度を有する組織、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズ

その上で、サイバートラスト向けコンパニオンガイドは、以下の通り、総計22のサイバーセキュリティ対応準備ドメインを設定している（*が付いている項目は、サイバーエッセンシャルズマークの管理策と共通）。

[サイバーガバナンスと監視]

1. ガバナンス
2. ポリシーと手順
3. リスクマネジメント
4. サイバー戦略
5. コンプライアンス
6. 監査

[サイバー教育]

7. トレーニングと意識向上*

[情報資産保護]

8. 資産管理*
9. データ保護とプライバシー*
10. バックアップ*
11. 私物端末の業務利用（BYOD）
12. システムセキュリティ*
13. ウイルス対策／マルウェア対策*
14. セキュアソフトウェア開発ライフサイクル（SDLC）

[セキュアなアクセスと環境]

15. アクセス制御*
16. サイバー脅威管理
17. サードパーティリスクと管理
18. 脆弱性評価
19. 物理的／環境的セキュリティ
20. ネットワークセキュリティ

[サイバーセキュリティレジリエンス]

21. インシデント対応*
22. 事業継続／災害復旧

ここで、サイバーセキュリティ対応準備ドメインとCCMv4コントロール項目をマッピングした結果を整理すると、各サイバーセキュリティ対応準備段階には、以下の数のドメインが含まれる。

• 「Advocate」（大規模組織／プロバイダー）：22ドメイン
• 「Performer」（大・中堅規模組織）：19ドメイン
• 「Promoter」（中堅・大規模組織）：16ドメイン
• 「Practitioner」（中堅・小規模組織）：13ドメイン
• 「Supporter」（小規模・マイクロエンタープライズ）：10ドメイン

サイバートラスト向けコンパニオンガイドは、より大規模またはデジタル化が進んだ組織を対象としているが、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズを対象とする「Supporter」区分も設けている。IMDAのDAIでは、「Supporter」について、「会社はまだデジタル技術を採用するための一貫した計画を定義していない。ビジネス機能とITは、デジタル関連のトピックでアドホックに協力することがあるが、プロジェクトはより大きな協力なしに独立して設計・実行されている。」と説明している。

「Supporter」の対応準備ドメインとCCMv4コントロール項目の概要

3. リスクマネジメント

・GRC-02リスク管理プログラム：クラウドセキュリティとプライバシーリスクの特定、評価、所有、処理、および受容のためのポリシーと手順を含む、正式で、文書化され、リーダーシップが支援するエンタープライズリスク管理 (ERM) プログラムを確立する。

5. コンプライアンス

・GRC-07情報システムに対する規制へのマッピング：組織に適用されるすべての関連する標準、規制、法律/契約、および法定要件を特定し、文書化する。

7. トレーニングと意識向上*

・HRS-11セキュリティ意識向上トレーニング：組織のすべての従業員に向けたセキュリティ意識向上トレーニングプログラムを確立、文書化、承認、伝達、適用、評価、維持し、定期的にトレーニングの更新を行う。

・HRS-12個人データおよび機微データの意識向上とトレーニング：従業員に、確立されたポリシーと手順、および適用される法律、法令、または規制のコンプライアンス義務の認識と、コンプライアンスを維持するための役割と責任を認識させる。

8. 資産管理*

・UEM-04エンドポイントのインベントリ：企業データの保存やアクセスに使う全てのエンドポイントをインベントリに保持する。

・DCS-01オフサイト機器の廃棄ポリシーと手順：組織の外部で使用される機器を安全に廃棄するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。機器が物理的に破壊されていない場合は、情報の回復を不可能にするデータ破壊手順が適用されるべきである。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-05資産の分類：組織のビジネスリスクに基づいて、物理的および論理的な資産（アプリケーションなど）を分類して文書化する。

・DCS-06資産のカタログ化と追跡：CSPのすべてのサイトにある関係する物理的および論理的資産を、セキュアなシステム内でカタログ化し追跡する。

・CCC-04承認されていない変更からの保護：組織の持つ資産への承認されていない追加や削除、更新、管理などを制限する。

・DSP-02セキュアな廃棄：業界で認められている方法を用いて、ストレージメディアからデータをセキュアに廃棄し、いかなるフォレンジック手段によってもデータが復元できないようにする。

9. データ保護とプライバシー*

・DSP-01セキュリティおよびプライバシーについてのポリシーおよび手順：データの分類、保護、取り扱いに関するポリシーおよび手順を、そのライフサイクルを通じて、適用されるすべての法律および規制、基準、およびリスクレベルに応じて確立し、文書化し、承認し、伝達し、適用し、評価し、維持する。少なくとも年1回、ポリシーと手順を見直し、更新する。

・DSP-03データインベントリ：少なくとも機微なデータや個人情報については、データインベントリを作成し、維持する。

・DSP-17機微なデータの保護：機微なデータをライフサイクル全体で保護するためのプロセス、手順、技術的手段を定義し、実施する。

・DSP-19データの所在地：データが処理またはバックアップされる場所を含む、データの物理的な場所を特定および文書化するためのプロセス、手順、および技術的な手段を定義し、実施する。

・UEM-11データ漏洩防止：管理対象のエンドポイントに、データ漏洩防止（DLP）技術を構成し、リスクアセスメントに従ったルールを構成する。

・SEF-07セキュリティ侵害の通知：セキュリティ侵害の通知のためのプロセス、手順、および技術的措置を定義し実装する。適用されるSLA、法令および規制に従い、関連するサプライチェーンの侵害を含む、実際のもしくは想定されるセキュリティ違反を報告する。

・STA-03 SSRMガイダンス：SSRM のサプライチェーンに対する適用可能性に関する詳細情報を 、CSC に SSRM ガイダンスとして提供する。

・STA-09主要なサービスと契約上の合意：CSP と CSC (テナント) の間のサービス契約には、少なくとも次の条項について相互に合意した内容を組み込む必要がある：

• 提供されるビジネス関係とサービスの範囲、特徴、場所
• 情報セキュリティ要件 (SSRMを含む)
• 変更管理プロセス
• ロギングおよびモニタリング能力
• インシデント管理とコミュニケーション手順
• 監査および第三者評価を行う権利
• サービスの終了条件
• 相互運用性と移植容易性の要件
• データプライバシー

10. バックアップ*

・BCR-08バックアップ：クラウドに保存したデータを定期的にバックアップする。バックアップの機密性、完全性、可用性を確保し、レジリエンスのためにバックアップからのデータ復元を検証する。

12. システムセキュリティ*

・TVM-01脅威と脆弱性管理ポリシーと手順：脆弱性の悪用からシステムを保護するために、脆弱性を特定、報告、その修復に優先順位をつけるためのポリシーと手順を策定、文書化、承認、周知、適用、評価、および維持する。少なくとも年１回、ポリシーと手順を見直して更新する。

・TVM-03脆弱性の修復スケジュール：特定されたリスクに基づいて脆弱性が特定された場合に、計画された対応と緊急時の対応の両方を可能にするためのプロセス、手順、技術的手段を定義、実施、評価する。

・CCC-01変更管理ポリシーと手順：資産が内部で管理されているか、外部で管理(例：外部委託)されているかに関わらず、アプリケーションやシステム、インフラストラクチャ、設定など、組織が持つ資産の変更に関連するリスクについて、それを管理するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、維持する。 少なくとも年1回はポリシーと手順をレビューし更新する。

・CCC-03変更管理技術：資産が内部で管理されているか、外部で管理(例：外部委託)されているかに関わらず、アプリケーションやシステム、インフラストラクチャ、設定など、組織が持つ資産の変更に関連するリスクを管理する。

・CCC-06変更管理のベースライン：組織の持つ資産に関連するすべての承認された変更について、変更管理のベースラインを確立する。

・DSP-07デザイン段階からのデータ保護とデフォルト設定：セキュリティ・バイ・デザインの原則と業界のベスト・プラクティスに基づいて、システム、製品、およびビジネス・プラクティスを開発する。

・IVS-03ネットワークセキュリティ：事業によって正当化される形態で認証、認可された接続に制限するように、環境間のコミュニケーションをモニタリング、暗号化、制限する。少なくとも年1回構成をレビューし、許可された全てのサービス、プロトコル、ポート、補完的コントロールの文書による正当性を文書化し、構成を支持する。

13. ウイルス対策／マルウェア対策*

・TVM-02マルウェア対策ポリシーと手順：管理対象資産上のマルウェアから保護するためのポリシーと手順を策定、文書化、承認、周知、適用、評価、および維持する。少なくとも年１回、ポリシーと手順を見直して更新する。

・UEM-09マルウェア対策による検知及び保護：管理対象のエンドポイントに、マルウェア対策による検知および保護に必要な技術やサービスを構成する。

・UEM-10ソフトウェアファイアウォール：管理対象のエンドポイントに、適切に設定したソフトウェアファイアウォールを構成する。

・IVS-09ネットワーク防御：ネットワークベースの攻撃に係る保護、検知、タイムリーな対応のために、プロセス、手順、多層防御技術を定義、実装、評価する。

・UEM-02アプリケーションおよびサービスの承認：組織管理のデータへのアクセスや保存の際、エンドポイントでの使用を許可する、承認済のサービス、アプリケーション、および、アプリケーションの入手先（ストア）の一覧を定義、文書化、適用、評価を行う。

・SEF-07セキュリティ侵害の通知：セキュリティ侵害の通知のためのプロセス、手順、および技術的措置を定義し実装する。適用されるSLA、法令および規制に従い、関連するサプライチェーンの侵害を含む、実際のもしくは想定されるセキュリティ違反を報告する。

15. アクセス制御*

・IAM-01アイデンティティ およびアクセス管理のポリシーと手順：アイデンティティ およびアクセス管理のポリシーと手順を確立、文書化、承認、周知、実装、適用、評価、および維持する。少なくとも年に1 回、ポリシーと手順を見直して更新する。

・IAM-02強固なパスワードポリシーと手順：強力なパスワードポリシーと手順を確立、文書化、承認、周知、実装、適用、評価、および維持する。少なくとも年 1 回、ポリシーと手順を見直して更新する。

・IAM-03アイデンティティ・インベントリ：システムアイデンティティとアクセスレベルの情報を管理、保存、およびレビューする。

・IAM-05最小権限：情報システムへのアクセスを実装するときは、最小権限の原則を採用する。

・IAM-06ユーザーアクセスのプロビジョニング：データと資産へのアクセスの変更を承認、記録、および伝達するためのユーザアクセスプロビジョニングのプロセスを定義および実装する。

・IAM-07ユーザーアクセスの変更と取り消し：アイデンティティとアクセスの管理ポリシーを効果的に採用して伝達するために、異動者/退職者のアクセスまたはシステムアイデンティティの変更をタイムリーにプロビジョニング解除または変更する。

・IAM-10特権的なアクセスロールの管理：特権的なアクセスロールと権限が限られた期間のみ付与されることを保証するためのアクセスプロセスを定義および実装し、分離された特権アクセスが極大化するのを防ぐための手順を実装する。

・IAM-14強固な認証：システム、アプリケーション、およびデータ資産へのアクセスを認証するためのプロセス、手順、および技術的手段を定義、実装、および評価する。これには、少なくとも特権ユーザーおよび機密データへのアクセスに対する多要素認証が含まれる。システムアイデンティティに対して同等レベルのセキュリティを実現するデジタル証明書または代替手段を採用する。

・IAM-15パスワード管理：パスワードのセキュアな管理のプロセス、手順、および技術的手段を定義、実装、および評価する。

・IAM-16認可メカニズム：データおよびシステム機能へのアクセスが認可されていることを確認するためのプロセス、手順、および技術的手段を定義、実装、および評価する。

・LOG-08ログの記録：関連するセキュリティ情報を含む監査記録を生成する。

・STA-12サプライチェーンにおけるサービスアグリーメント準拠：サプライ チェーン全体のすべての CSP に、情報セキュリティ、機密性、アクセス制御、プライバシー、監査、人事ポリシー、およびサービス レベル要求と適用標準規格に対して、準拠を要求したポリシーを実装する。

・HRS-10機密保持契約：計画された間隔で、データの保護と運用の詳細に関する組織のニーズを反映した非開示/機密保持契約の要件を特定、文書化、およびレビューする。

・DCS-03保護区域ポリシーと手順：オフィス、部屋、施設で安全でセキュアな作業環境を維持するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-09保護区域における認証：認可された担当者のみに保護エリアへのアクセスを許可し、すべての入口と出口のポイントを物理的なアクセス制御メカニズムによって制限し、文書化し、監視する。 組織が適切と見なす期間で定期的にアクセス制御記録を保持する。

21. インシデント対応*

・SEF-02サービス管理ポリシーと手順：セキュリティインシデントの適時な管理のためのポリシーおよび手順を確立、文書化、承認、周知、適用し評価、および維持する。少なくとも年1回、ポリシーと手順をレビューし更新する。

・SEF-03インシデントレスポンス計画：セキュリティインシデントレスポンス計画を策定、文書化、承認、周知、適用、評価、および維持する。本計画には、関連する社内部門、影響を受けるCSC、影響を受ける可能性のあるその他のビジネス上での重要な関係（サプライチェーン等）が含まれるが、これらに限定されない。

「Practitioner」の対応準備ドメインとCCMv4コントロールの追加項目

なお、「Practitioner」（中堅・小規模組織）では、上記10ドメインに、以下の3ドメインが追加される。

19. 物理的／環境的セキュリティ

・DCS-03保護区域ポリシーと手順：オフィス、部屋、施設で安全でセキュアな作業環境を維持するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-15設備の場所：ビジネス上重要な機器を、環境に関するリスクイベントの可能性が高い場所から遠ざける。

・IVS-08ネットワークアーキテクチャの文書化：高リスク環境を特定し文書化する。

・DCS-01 オフサイト機器の廃棄ポリシーと手順：組織の外部で使用される機器を安全に廃棄するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。 機器が物理的に破壊されていない場合は、情報の回復を不可能にするデータ破壊手順が適用されるべきである。 ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-02 オフサイト転送承認ポリシーと手順：ハードウェア、ソフトウェア、またはデータ/情報をオフサイトまたは代替場所に再配置または転送するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。 再配置または転送要求には、書面または暗号手法により検証可能な承認が必要である。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-03 （前掲）

・DCS-04 セキュアなメディア輸送ポリシーと手順：物理メディアの安全な輸送のためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-05資産の分類：組織のビジネスリスクに基づいて、物理的および論理的な資産（アプリケーションなど）を分類して文書化する。

・DCS-06 資産のカタログ化と追跡：CSPのすべてのサイトにある関係する物理的および論理的資産を、セキュアなシステム内でカタログ化し追跡する。

・DCS-07制御されたアクセスポイント：人員、データ、および情報システムを保護するために、物理的なセキュリティ境界を実装する。管理領域、ビジネス領域とデータのストレージおよび処理施設エリアの間に物理的なセキュリティ境界を確立する。

・DCS-08機器の識別：接続の認証方法として、機器の識別を使う。

・DCS-09保護区域における認証：認可された担当者のみに保護エリアへのアクセスを許可し、すべての入口と出口のポイントを物理的なアクセス制御メカニズムによって制限し、文書化し、監視する。組織が適切と見なす期間で定期的にアクセス制御記録を保持する。

・DCS-10監視システム：許可されていない入場および退場の試行を検出するために、外部境界およびすべての入口と出口のポイントで、データセンタ監視システムを実装、保守、および運用する。

・DCS-12ケーブルのセキュリティ：すべての施設、オフィス、および部屋において、電力および通信ケーブルを傍受、干渉、または損傷の脅威からリスクベースで保護し保証するプロセス、手順、および技術的対策を定義、実装、および評価する。

・DCS-13環境システム：温度と湿度の状態が承認された業界標準範囲内にあることを継続的に監視、維持、およびテストするデータセンタ環境制御システムを実装および保守する。

・DSP-16データの保持と廃棄：データの保持、アーカイブ、削除は、ビジネス要件、適用される法律および規制に従って管理する。

・DSP-19データの所在地：データが処理またはバックアップされる場所を含む、データの物理的な場所を特定および文書化するためのプロセス、手順、および技術的な手段を定義し、実施する。

・DCS-07（前掲）

20. ネットワークセキュリティ

・IVS-03ネットワークセキュリティ：事業によって正当化される形態で認証、認可された接続に制限するように、環境間のコミュニケーションをモニタリング、暗号化、制限する。少なくとも年1回構成をレビューし、許可された全てのサービス、プロトコル、ポート、補完的コントロールの文書による正当性を文書化し、構成を支持する。

・IVS-09ネットワーク防御：ネットワークベースの攻撃に係る保護、検知、タイムリーな対応のために、プロセス、手順、多層防御技術を定義、実装、評価する。

・IVS-07クラウド環境への移行：サーバー、サービス、アプリケーション、データをクラウド環境に移行する際、セキュアで暗号化されたコミュニケーションチャンネルを使用する。これらのチャンネルは最新の承認されたプロトコルだけを含まなければならない。

22. 事業継続／災害復旧

・BCR-11設備の冗長性：業界標準に従って、ビジネスクリティカルな機器に対して、合理的な範囲で最小限の離れた場所に独立して冗長機器を配置する。

このように、サイバートラスト向けコンパニオンガイドは、企業のデジタル成熟度や成長度に応じて、優先度の高いサイバーセキュリティ管理策を推奨する形態を採っているのが特徴だ。

サイバーセキュリティ教育面では、2024年7月15日、シンガポールサイバーセキュリティ庁（CSA）とシンガポール国立大学（NUS）が連携して、サイバーSGタレント・イノベーション・成長（TIG）コラボレーションセンターを設立したことを発表し、アカデミアとの連携を強化している（https://www.csa.gov.sg/News-Events/Press-Releases/2024/opening-of-cybersg-talent–innovation-and-growth-(tig)-collaboration-centre）。同センターは、以下のようなプログラムを提供している。

(a) SGサイバーアソシエイツ：

・サイバーセキュリティの専門家でない人々に対して、基礎レベルの特化したサイバーセキュリティトレーニングを提供し、日常業務に関連するサイバーセキュリティスキルを開発するためのプログラム

(b) SGサイバーユース：

・学生に、キャリアとしてサイバーセキュリティを探究する機会を提供し、関連する技術的知識やソフトスキルに触れることができるプログラムで、中学生および高等教育機関の学生を対象に設計されたユースサイバー探究プログラムと高度YCEPプログラムより構成される

(c) SGサイバープロフェッショナルズ：

・様々なバックグラウンドを持つミッドキャリアの転職者に対して、キャリア変換のための研修機会を提供し、それによって地元のサイバーセキュリティ人材を強化し、この重要分野における熟練した専門家の増大する需要に応える

(d) SGサイバータレント開発基金（SCTDF）：

・コミュニティ、団体、業界パートナーを奨励して、サイバーセキュリティ労働力を関与させ、スキルアップさせ、進歩させる取り組みを構築する

加えて2024年11月11日、同センターは、サイバーセキュリティ業界向けのオープンイノベーションコンテスト（CyberCall）の公募を開始した（募集期間：2025年1月10日まで）。（https://www.csa.gov.sg/News-Events/Press-Releases/2024/cybersg-tig-collaboration-centre-launched-the-cybersecurity-industry-call-for-innovation-(cybercall)-2024-november-edition）。

CyberCallは、オープン募集カテゴリーとユーザー駆動型カテゴリーから構成される。前者のテーマとしては、AI向けサイバーセキュリティ、サイバーセキュリティ向けAI利用、耐量子安全性、OT／IoTセキュリティ、クラウドセキュリティ、プライバシー強化技術（PET）がある。後者は、製造業やエネルギーなどのOT分野におけるサイバーセキュリティソリューションの効果を向上させるために、最新のAI技術を活用することを目的としており、具体的な課題は、エンドユーザー企業のYTLパワーセラヤとパナソニックから挙げられている。

CSA本部およびCSAシンガポールチャプターは、引き続きシンガポールの産官学連携エコシステムとの関係性強化に向けて取り組んでいる。

CSAジャパン関西支部メンバー

健康医療情報管理ユーザーワーキンググループリーダー

笹原英司

 

CSAジャパン関西支部および健康医療情報管理ワーキンググループでは、医療・ライフサイエンス業界を対象として、海外最新クラウド関連事例の紹介活動を行ってきたが、今回より、同様の課題をかかえる中堅中小規模の製造業やスタートアップ企業に対象を拡張して、CSAのグローバル展開から生まれた知見や実績をベースとして、基礎的なクラウドセキュリティプラクティスの啓発活動を紹介する。

シンガポール政府とCSAが企業規模別クラウドセキュリティガイドを開発

2023年10月17日、シンガポールサイバーセキュリティ庁とクラウドセキュリティアライアンスは、サイバーセキュリティ庁が開発した国家サイバーセキュリティ標準規格である「サイバーエッセンシャルズ」および「サイバートラスト」をサポートするツールとして、2種類の「クラウドセキュリティコンパニオンガイド」を策定したことを発表した。（https://www.csa.gov.sg/News-Events/Press-Releases/2023/launch-of-cloud-security-companion-guides-for-organisations）。本ガイドは、シンガポールサイバーセキュリティ庁（CSA）のWebサイトより無料でダウンロードできる。

このクラウドセキュリティコンパニオンガイドに先立ち、シンガポールサイバーセキュリティ庁は、2022年3月29日、「サイバーセキュリティ法」（2018年3月2日施行）に準拠した新しいサイバーセキュリティ認証プログラムを発表していた（https://www.csa.gov.sg/News-Events/Press-Releases/2022/csa-launches-new-cybersecurity-certification-programme-to-recognise-enterprises-with-good-cybersecurity-practices）。この認証プログラムは、サイバーハイジン対策を実施している中堅中小企業（SMB）などのクラウドユーザーを対象としたサイバーエッセンシャルズマークと、包括的なサイバーセキュリティ対策およびプラクティスを有する多国籍企業（MNC）などの大企業やクラウドサービスプロバイダーを対象としたサイバートラストマークから構成される。

二つのサイバーセキュリティ認証マークは、特定の製品・サービスのサイバーセキュリティを認証するものではなく、むしろ組織レベルで採用されたサイバーセキュリティ対策を認証するものである。これらの認証マークは、シンガポール企業の多様な組織形態や運用ニーズを考慮して、認証実務者、技術プロバイダー、業界団体などの業界パートナーとの協議を経て開発された。

これらのサイバーセキュリティ認証マークを踏まえて今回発表されたクラウドセキュリティコンパニオンガイドは、Amazon Web Services、Google Cloud、Microsoftとのパートナーシップに基づいて開発されたものであり、各プロバイダーは、顧客との体験に基づくインサイトを提供し、関連する成果や統計に寄与して、コンパニオンガイドのコンテンツを検証している。

本コンパニオンガイドは、SMBなどのクラウドユーザーがクラウド特有のリスクと責任をよく理解し、それに対する必要な対策を講じるためのアドバイスを提供している。これには、クラウドセキュリティにおける役割についての従業員のトレーニングや、クラウドで安全に操作する方法、クラウドサービスのインベントリを追跡・監視する仕組みの実装などが含まれている。

企業がクラウドを利用する際に混乱しがちなのが、クラウドユーザーとしての自身の責任とクラウドプロバイダーの責任分担である。オンプレミス型システム導入の場合、組織は自社のサイバーセキュリティに完全に責任を持つ。他方、クラウドサービス導入の場合、責任がユーザーとプロバイダーの間で共有されるが、ユーザーが責任を持つ領域を完全には把握していない可能性がある。これによって、設定ミスや悪意のある攻撃、データ侵害の可能性を高める場合があるとしている。

SMBフォーカスのサイバーエッセンシャルズ向けクラウドセキュリティ管理策

コンパニオンガイドのうち、「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/cloud-security-companion-guide-cyber-essentials.pdf）は、SMBを対象としており、責任共有モデルを使用して、ユーザー組織とプロバイダーがそれぞれクラウド環境を保護するために何を担当する必要があるかを理解するのに役立つ構成となっている。具体的には、以下のような構成となっている。

1. イントロダクション
2. 対象読者
3. 本文書のスコープ
4. 謝辞
5. サイバーエッセンシャルズ向けのクラウドの責任共有モデル (SRM)
6. 参考文献
   附表1 サイバーエッセンシャルズ向けのクラウド固有の実装に関するガイダンス

サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイドでは、「サイバーエッセンシャルズマーク向けサイバーセキュリティ認証」（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-scheme-for-organisation/cyber-essentials/certification-for-the-cyber-essentials-mark）より、以下のようなセキュリティ管理項目を採用した上で、クラウド固有の管理策（要求事項および推奨事項）を設定している。

[カテゴリー：資産]
・人々 – 従業員に、防衛の最前線となるノウハウを装備させる
・ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
・データ – 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
[カテゴリー：セキュア化／保護]
・ウイルスおよびマルウェアの保護 – ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
・アクセス制御 – 組織のデータやサービスへのアクセスを制御する
・セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
[カテゴリー：アップデート]
・ソフトウェア・アップデート – デバイスやシステム上のソフトウェアをアップデートする
[カテゴリー：バックアップ]
・不可欠なデータのバックアップ – 組織の不可欠なデータをバックアップして、オフラインに保存する
[カテゴリー：対応]
・インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする

たとえば、上記のうち、サイバーエッセンシャルズマークの「[カテゴリー：資産]・人々 – 従業員に、防衛の最前線となるノウハウを装備させる」では、以下のような要求事項が設定されている。

組織は、すべての従業員が、セキュリティプラクティスや期待される行動を意識していることを保証するために、サイバーセキュリティ意識向上トレーニングを設定すべきである。組織は、この要求事項を様々な方法で充足する可能性がある（例. 従業員または関与する外部トレーニング プロバイダー向けに自己学習教材を提供する）。

これを受けて、サイバーエッセンシャルズ向けコンパニオンガイドでは、「エンドユーザー組織(SaaSカスタマー)の責任」として、以下のような要求事項を設定している。

• エンドユーザー組織(SaaSカスタマー)は、単独で責任を負う

[なぜこれが重要か]

• ますますビジネスユーザー（IT部門と対照的に）は、SaaSアプリケーションにアクセスして管理しており、SaaSのセキュリティを管理するために、適切な装備を備えていない可能性がある。
• ヒューマンエラーは、クラウドリスクの主要な要因の一つとして広く認識されている。

[組織は何をすべきか]

• 従業員向けの一般的なサイバー意識向上トレーニングの範囲を越えて、組織は、SaaSを管理するビジネスユーザーが、なぜクラウドセキュリティにおいて重要な役割を果たすのか、どのようにしてクラウド上でセキュリティを運用できるのかについて理解するためのトピックを含めるべきである。

また、「クラウドプロバイダー（SaaSプロバイダーおよびクラウドインフラストラクチャプロバイダーの双方）」の責任として、以下のような要求事項を設定している。

• 主要クラウドプロバイダーは、ベストプラクティスを公開し、クラウドカスタマーに対してよりよいサポートを提供する。

このように、セキュリティ管理項目ごとに、責任共有モデルにおけるエンドユーザー組織(SaaSカスタマー)、SaaSプロバイダー、クラウドインフラストラクチャプロバイダーの関係性を明確化した点が、シンガポールのサイバーエッセンシャルズ向けコンパニオンガイドの特徴である。

なお、サイバーエッセンシャルズ向けコンパニオンガイドの参考文献として、以下のようなドキュメントを挙げている。

1. CIS Controls Cloud Companion Guide v8 by Center for Internet Security (CIS)
   （https://www.cisecurity.org/insights/white-papers/cis-controls-v8-cloud-companion-guide)
2. ISO/IEC 27017- Information technology – Security techniques – Code of practice for information security controls based on ISO/IEC 27002 for cloud services by ITU-T
   （https://www.iso.org/standard/43757.html）
3. Top Threats to Cloud Computing by Cloud Security Alliance
   （https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-deep-dive）
4. SaaS Governance Best Practices for Cloud Customers by Cloud Security Alliance
   （https://cloudsecurityalliance.org/artifacts/saas-governance-best-practices-for-cloud-customers）
5. Cloud Incident Response Framework – A Quick Guide by Cloud Security Alliance
   （https://cloudsecurityalliance.org/artifacts/cloud-incident-response-framework-a-quick-guide）
6. 2022 SaaS Security Survey Report by Cloud Security Alliance and Adaptive Shield
   （https://cloudsecurityalliance.org/artifacts/saas-security-and-misconfigurations-report）
7. Cloud Security Foundations, Frameworks and Beyond by SANS Institute
   （https://www.sans.org/white-papers/cloud-security-foundations-frameworks-beyond/）
8. The State of SaaS Sprawl by Productiv Inc
   （https://productiv.com/resources/the-state-of-saas-sprawl/）
9. 2023 State of SaaSOps by BetterCloud, Inc
   （https://www.bettercloud.com/monitor/the-2023-state-of-saasops-report/）
10. Cloud and Threat Report: Global Cloud and Web Malware Trends by Netskope
    （https://www.netskope.com/wp-content/uploads/2023/05/cloud-and-threat-report-global-cloud-and-web-malware-trends.pdf）

CSA CCMを適用したサイバートラスト向けクラウドセキュリティ管理策

他方、サイバートラスト向けのクラウドセキュリティコンパニオンガイドである「CSAサイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4の間のクロスマッピング」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/cloud-security-companion-guide-cyber-trust.pdf）は、より大規模またはデジタル化が進んだ組織を対象としており、サイバートラストマークの各サイバーセキュリティ対応準備ドメイン（サイバーガバナンスと監督、サイバー教育など）をクラウドセキュリティアライアンスのCloud Controls Matrix（CCM）v4にマッピングしている。このマッピングを通じて、企業がサイバートラストマークを取得するために必要な管理策の実行を容易にするためのレファレンスを提供する。

サイバートラスト向けのコンパニオンガイドでは、企業がサイバートラストマークを適用すべき理由として、以下のような点を挙げている。

• 堅牢なサイバーセキュリティを有する信頼されたパートナーとして、組織を認識するための優れたマークを意味する
• 国際的なサイバーセキュリティ基準（例：ISO/IEC 27001）への道を提供する
• 組織のサイバーセキュリティリスクと対応準備状況を評価するためのガイド付きアプローチを提供する
• 過剰投資することなく組織のニーズに応じたリスクベースのアプローチを採用する
• どのサイバーセキュリティ対応準備段階に自分の組織が属しているか？

1. そして、サイバートラスト向けコンパニオンガイドは、以下のような構成になっている。
2. イントロダクション
3. 対象読者
4. 本文書のスコープ
5. 謝辞
6. サイバートラスト向けのアプローチ

参考文献
附表I. サイバートラストマークのCCMv4へのマッピングを描写する可視化
附表II. サイバートラストマークの対応準備段階のCCMv4へのマッピングを描写する可視化
附表III. サイバートラストマークのCCMv4へのマッピング

　まずサイバートラスト向けコンパニオンガイドでは、シンガポール情報通信メディア開発庁（IMDA）の「デジタルアクセラレーションインデックス（DAI）」（https://www.imda.gov.sg/how-we-can-help/digital-acceleration-index）のデジタル成熟度指標に準拠して、以下の通り、5つのサイバーセキュリティ対応準備段階を設定している。

• 「Advocate」: 先導的なデジタル成熟度を有する組織、大規模組織またはそれらで活動している人／規制セクター向けのプロバイダー
• 「Performer」: “Performer”のデジタル成熟度を有する組織、大・中堅規模組織
• 「Promoter」: “Literate”のデジタル成熟度を有する組織、中堅・大規模組織
• 「Practitioner」: “Starter” のデジタル成熟度を有する組織、中堅・小規模組織
• 「Supporter」: “Starter” のデジタル成熟度を有する組織、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズ

その上で、サイバートラスト向けコンパニオンガイドは、以下の通り、サイバーセキュリティ対応準備ドメインを設定している。

[サイバーガバナンスと監視]

1. ガバナンス
2. ポリシーと手順
3. リスクマネジメント
4. サイバー戦略
5. コンプライアンス
6. 監査

[サイバー教育]

7. トレーニングと意識向上*

[情報資産保護]

8. 資産管理*
9. データ保護とプライバシー*
10. バックアップ*
11. 私物端末の業務利用（BYOD）
12. システムセキュリティ*
13. ウイルス対策／マルウェア対策*
14. セキュアソフトウェア開発ライフサイクル（SDLC）
[セキュアなアクセスと環境]
15. アクセス制御*
16. サイバー脅威管理
17. サードパーティリスクと管理
18. 脆弱性評価
19. 物理的／環境的セキュリティ
20. ネットワークセキュリティ

[サイバーセキュリティレジリエンス]

21. インシデント対応*
22. 事業継続／災害復旧

　上記のうち、*が付いている項目は、サイバーエッセンシャルズマークの管理策と共通である。このように、サイバートラストマークとサイバーエッセンシャルズマークは、一貫性のある管理策構成となっている。

サイバートラスト向けコンパニオンガイドでは、縦軸にサイバーセキュリティ対応準備ドメインを据え、横軸にCCMv4のコントロール項目を据えて、マッピングした結果を整理し、それらの関係性を可視化している。

なお、サイバートラスト向けコンパニオンガイドの参考文献として、以下のようなドキュメントを挙げている。

• Cloud Controls Matrix v4 by Cloud Security Alliance
  （https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4）

グローバルクラウドサービスプロバイダーとの連携による成果物

加えて、コンパニオンガイドの開発における密接なパートナーシップの一環として、Amazon Web Services、Google Cloud、Microsoftも、以下の通り、サイバーエッセンシャルズおよびサイバートラストマークに記載されている対策に基づいて構成されたプロバイダー固有のガイドを開発・公開している。

• Google Workspace Cloud Security Companion Guide for Cyber Essentials – Jointly developed with Google
  （https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/google-workspace-security-companion-guide-for-cyber-essentials.pdf?sfvrsn=a19355aa_1）
• Microsoft Cloud Security Companion Guide for Cyber Essentials – Jointly developed with Microsoft
  （https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/microsoft-cloud-security-companion-guide-cyber-essentials.pdf?sfvrsn=1d677c69_1）
• AWS Cloud Companion Guide for Cyber Trust – Jointly developed with AWS
  （https://d1.awsstatic.com/whitepapers/compliance/CSA_Cyber_Trust_mark_certification_Cloud_Companion_Guide.pdf）

シンガポールの場合、ここまで紹介した汎用的なクラウドセキュリティ関連プログラムおよび関連ツール類を踏まえた上で、金融管理庁（MAS）や保健科学庁（HAS）などが制定した業種別の法規制・ガイドライン類に対応していく必要がある。

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

クラウドセキュリティアライアンス（CSA）は、2024年7月15日、「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）を公開した。CSAガイダンスV5では、コンテナ／マイクロサービス／サーバーレスセキュリティの扱いが大幅に増えたのが特徴である。後編では、アプリケーションセキュリティに関連する新ガイダンスの追加・変更点について概説する。

クラウドネイティブ技術をベースとする米国のFedRAMP改革が本格化

2024年7月26日、米国ホワイトハウス傘下の行政管理予算局（OMB）は、クラウドサービスのセキュアな採用を加速するためのFedRAMPガイダンスを公表した（関連情報（https://www.whitehouse.gov/omb/briefing-room/2024/07/26/fact-sheet-omb-releases-fedramp-guidance-to-accelerate-the-secure-adoption-of-cloud-services/））。その中で、FedRAMPのモダナイゼーションのために、以下の3点に注力することを表明している。

• 不可欠で効率的なセキュリティにフォーカスする
• 政府機関にとってクラウド利用をより簡単で安全なものにする
• FedRAMPガバナンスを強化する

これに先立ちFedRAMPは、2024年6月27日、大統領令第14110号（人工知能の安心、安全で信頼できる開発と利用）に呼応した「新興技術優先順位付けフレームワーク」を公表していた（関連情報（https://www.fedramp.gov/2024-06-27-release-of-et-framework/））。このフレームワークでは、人工知能（AI）をトップバッターとして、重要なクラウド関連新興技術（ET）に優先順位付けを行い、それに基づいて、FedRAMPの内部業務やレビューのプロセスを行うとしている。FedRAMPは、優先順位付けの対象となるAI関連新興技術基準として、以下の3つを挙げている。

1. チャットインタフェース
2. コード生成デバッグツール
3. プロンプトベースの画像生成

FedRAMPは、今後、新興技術優先順位付けフレームワークの対象となる技術領域を定期的に見直していくとしている。

参考までに、2024年2月時点で、ホワイトハウスが重要・新興技術として指定する領域には、以下のようなものがある（関連情報（https://www.whitehouse.gov/wp-content/uploads/2024/02/Critical-and-Emerging-Technologies-List-2024-Update.pdf））。これらの領域はいずれも米国の国家安全保障の対象であり、重要インフラを支えるクラウドプラットフォームにも、強固なセキュリティ管理策が要求される。

• 先進コンピューティング
• 先進工学材料
• 先進ガスタービンエンジン技術
• 先進ネットワークセンシング・シグニチャー管理
• 先進製造
• 人工知能（AI）
• バイオテクノロジー
• クリーンエネルギー生成・保存
• データプライバシー、データセキュリティ、サイバーセキュリティ技術
• 指向性エネルギー
• 高度な自動化、自律化、無人システム（UxS）、ロボティクス
• ヒューマンマシンインターフェース
• 極超音速
• 統合型通信ネットワーク技術
• 位置、航法、時刻（PNT）技術
• 量子情報実現技術
• 半導体・マイクロエレクトロニクス
• 宇宙技術システム

また、上記のうちAIでは、以下のような技術が挙げられている。

• 機械学習
• 深層学習
• 強化学習
• 感覚的知覚認識
• AI保証評価技術
• 基盤モデル
• 生成AIシステム、マルチモーダル、大規模言語モデル
• 教育、微調整、検証向けの合成データアプローチ
• 計画、推論、意思決定
• AIの安全性、信頼性、セキュリティ責任ある利用を向上させるための技術

上記AI技術領域に関して、FedRAMPの優先順位付けフレームワークがどこまでカバーしていくのか、今後の動向が注目される。

また、ホワイトハウスの対象領域になっているデータプライバシー、データセキュリティ、サイバーセキュリティ技術に関しては、以下のような技術が挙げられている。

• 分散台帳技術（DLT）
• デジタル資産
• デジタル決済技術
• デジタルアイデンティティ技術、生体認識および関連インフラストラクチャ
• 通信ネットワークセキュリティ
• プライバシー強化技術
• データフュージョンおよびデータの相互運用性、プライバシー、セキュリティ向上のための技術
• 分散秘密計算
• サプライチェーンセキュリティ計算処理
• 人工現実（AR）／仮想現実（VR）におけるセキュリティとプライバシーの技術

上記の技術領域の中には、すでにCSAの個別WGの活動対象となっているテーマが多く含まれており、今後、FedRAMP改革への対応だけでなく、国境を越えたハーモナイゼーションが期待される。

伝統的なIaaS／PaaSを前提としてきたアプリケーションセキュリティ

ところで、CSAガイダンスV4.0では、「アプリケーションセキュリティ」の章で、PaaSおよびIaaSのクラウドコンピューティング環境のソフトウェアを構築する開発者や運用するITチームに焦点を当てていた。具体的には、以下のような構成になっていた。

10. アプリケーションセキュリティ
10.0 はじめに
10.1 概要
10.1.1 セキュアソフトウェア開発ライフサイクルとクラウドコンピューティング
10.1.2 セキュアな設計と開発
10.1.3 セキュアな配備
10.1.3.1 脆弱性診断への影響
10.1.3.2 侵入検査への影響
10.1.3.3 配備パイプラインのセキュリティ
10.1.3.4 Infrastructure as Code ”と不可変性による影響
10.1.4 セキュアな運用
10.1.5 クラウドのアプリケーション設計とアーキテクチャへの影響
10.1.6 クラウド事業者が考慮すべきその他の事項
10.1.7 DevOps の隆盛とその役割
10.1.7.1 セキュティへの波及効果とその長所
10.2 推奨事項

　そして、以下のような推奨事項を提示していた。

• 利用しているクラウド事業者の持つセキュリティに関する能力を把握すること。ベースラインのセキュリティだけでなく、複数のプラットフォームとサービスの全般にわたって把握すること。
• 初期設計のプロセスにセキュリティを組み込むこと。クラウド上のデプロイは多くの場合未経験の領域であり、早い段階でセキュリティチームを関わらせる場は広がっている。
• 形式の整ったSDLCを導入できていないときは、CDに移行してデプロイパイプラインにセキュリティの自動化を組み入れることを検討すること。
• 脅威モデリング、SAST、DAST(ファジングを含む)は全て取り入れるべきである。テストはクラウド環境で機能するように設定しなければならない。しかし同時に、クラウドプラットフォームに固有の懸念事項、例えばAPI資格情報の保存状態などをテストできる設定もしなければならない。
• 新しくクラウド内で遭遇するアーキテクチャの選択肢や要求条件を理解すること。それらをサポートするべく、自組織のセキュリティポリシーとセキュリティ基準を改定すること。決して単純に従来の基準を全く新しいコンピューティングモデルに強制的にはめ込むようなことはしないこと。
• 配備プロセスにセキュリティテストを組み込むこと。
• セキュリティコントロールを自動化するために、Software Defined Securityを活用すること。
• 可能なら、イベント駆動型セキュリティを活用し、セキュリティ事案に対する検知と修復の自動化を実現すること。
• 複数の異なるクラウド環境を利用し、管理用ダッシュボードへのアクセスの分離を改善すること。同時に、本番環境は固定しつつ、開発チームには必要な開発環境の設定を自由にさせること。

DevSecOpsの柱はセキュアソフトウェア開発ライフサイクル（SSDLC）

これに対してCSAガイダンスV5では、以下のような構成になっている。

10. アプリケーションセキュリティ
10.1 セキュアな開発ライフサイクル
10.1.1 CSAセキュア開発ライフサイクル
10.1.2 脅威モデリング
10.1.3 セキュアな設計と開発
10.1.4 テスト：デプロイ前
10.1.5 テスト：デプロイ後
10.2 セキュアなクラウドアプリケーションアーキテクチャ
10.2.1 クラウドのアーキテクチャレベルのセキュリティへの影響度
10.2.2 クラウドのアプリケーション設計とアーキテクチャへの影響度
10.2.3 Infrastructure as Codeとアプリケーションセキュリティ
10.2.4 APIセキュリティのベストプラクティス
10.3 アイデンティティ／アクセス管理のアプリケーションセキュリティ
10.3.1 アプリケーションコンポーネント上での許可の設定
10.3.2 秘密管理
10.4 DevSecOps：CI／CDとアプリケーションテスト
10.4.1 DevSecOps
10.4.2 DevSecOpsの6つの柱
10.4.3 実用的なDevSecOps
10.4.3.1 シフトレフトとセキュリティの組込
10.4.3.2 SecOps：WebアプリケーションファイアウォールとDDoS
10.5 サーバーレスとコンテナ化されたアプリケーションの考慮事項
10.5.1 サーバーレスとコンテナのアプリケーションセキュリティへの影響度
10.5.1.1 サーバーレスの考慮事項
10.5.1.2 コンテナの考慮事項

まず、「10.1 セキュアな開発ライフサイクル」において、CSA DevSecOps WGが活動の柱としてきたセキュアソフトウェア開発ライフサイクル（SSDLC）に焦点を当ている（関連情報（https://cloudsecurityalliance.org/blog/2023/03/25/the-5-stages-to-devsecops））。CSAのSSDLCは、以下の5つのステージから構成される。

• セキュアなデザインとアーキテクチャ
• セキュアコーディング（Developer IDEとCode Repository）
• 継続的なビルド、統合、およびテスト
• 継続的なデリバリーとデプロイメント
• 継続的なモニタリングとランタイムディフェンス

SSDLCは、後述の「10.4 DevSecOps：CI／CDとアプリケーションテスト」につながる重要な枠組となっている。

次に、脅威モデリングに関して、具体的なフレームワークを例示している。脅威モデリングとは、組織の資産に対する潜在的なセキュリティ脅威を特定、評価、低減するために、利用される構造化プロセスと定義している。これには、システムアーキテクチャの理解、セキュリティ目標の特定、これらの目標に影響を及ぼす可能性のある潜在的脅威の分析が含まれる。脅威モデリングを実行することによって、重大度と確率に基づいて、特定された脅威の優先順位を付けることができるとしている。

この脅威モデリングのうち、セキュリティリスクを特定・分類するフレームワークとして、以下の6つから構成されるSTRIDEフレームワークを例示している。

1. 偽造（Spoofing）：不正アクセスを行うために、ユーザーやシステムのように誰か他人のふりをする攻撃者が含まれる（例. ログイン資格情報を盗み出すために、攻撃者が合法サイトを真似たところでのフィッシング攻撃）
2. なりすまし（Tampering）：データやメッセージの不正な変更のこと。これが、転送時やストレージシステム内部で起きて、データの完全性が損なわれる可能性がある。
3. 否認（Repudiation:）：これは、そうしたにも関わらず主体が行為を否定した時に起きる。これにより、行為を正しいソースに帰するシステムの能力が弱体化して、責任が複雑化する。
4. 情報開示（Information Disclosure）：これには、機密情報への不正アクセスが含まれる。手法には、セキュアでない通信上での盗み聞き、機微データにアクセスする脆弱性の悪用が含まれる。
5. サービス拒否（Denial of Service）：これは、システムの可用性欠如につながるようなシステムリソースの消耗である。これにより、オペレーションが破壊され、重大なダウンタイムを招く可能性がある。
6. 特権昇格（Elevation of Privilege）：攻撃者が、許可されたレベル以上の高度なアクセスを取得した場合、より特権の高いアカウント用に指定した行動を実行するために、アクセス制御をバイパスする。

• クラウドアプリケーション設計のセキュリティ原則と技術的対策

その上で、CSAガイダンスV5では、「10.1.3 セキュアな設計と開発」について説明している。ここでは、クラウドアプリケーション設計時のセキュリティ原則として、以下の3点を挙げている。

• PaaSサービスは、より多くのセキュリティ上の責任をCSPに委ねて、顧客が、セキュアで、完全にパッチ当てされ、設定されたサーバーやサービスを維持する必要性を減らすか、なくす可能性がある。
• すべてのアプリケーションコンポーネントおよびPaaSサービス向けに最小特権のアイデンティティ／アクセス管理（IAM）を実装する。
• インターネットに面した露出を低減するために、ロードバランサーや非常に制限されたセキュリティグループのようなCSPサービスを利用する。

伝統的なPaaSと比較して、クラウドユーザーの負荷が低減する反面CSPの責任が重くなるサーバーレスコンピューティングのFaaS（Function as a Service）への展開を意識した内容になっている。

そして、具体的なテスト手法として、以下のような例を挙げている。

[デプロイ前テスト]

1. 静的アプリケーションセキュリティテスト（SAST）
   • 手動セキュリティコードレビュー
2. ソフトウェア構成分析（SCA）
3. 静的脆弱性スキャニング

[デプロイ後テスト]

1. 動的脆弱性スキャニング
2. 動的アプリケーションセキュリティテスト（DAST）
   • 動的分析（ファジング）
   • インタラクティブアプリケーションセキュリティテスト（IAST）
3. ペネトレーションテスト
4. バグバウンティプログラム

このように、CSAガイダンスV5では、デプロイ前およびデプロイ後に分けて、テスト手法を列挙するようになった。

加えて、技術的対策として、「10.2 セキュアなクラウドアプリケーションアーキテクチャ」において、Infrastructure as Code（IaC）やAPIセキュリティを、「10.3 アイデンティティ／アクセス管理のアプリケーションセキュリティ」において、特権アクセス管理に代表されるIAMや秘密管理を取り上げている。

クラウドネイティブアプリケーション開発を支えるDevSecOpsとシフトレフト

さらにCSAガイダンスV5で拡充されたのが、「10.4 DevSecOps：CI／CDとアプリケーションテスト」の部分である。DevSecOpsについては、SSDLCを通してセキュリティの統合を自動化するような開発、セキュリティ、運用を短縮したものであり、DevOpsパイプラインに「セキュリティ」の部分を導入するものだとしている。

そして、セキュアなソフトウェアを効率的に開発することを目的として、セキュリティをDevOpsプラクティスに統合するための包括的フレームワークとして、DevSecOpsの6つの柱を掲げている。参考までに、6つの柱については、下記のCSA DevSecOps WG発行ドキュメントで詳説している。

• 「DevSecOpsの6つの柱：集団的責任」（2020年2月21日公開）
  • （原版：https://cloudsecurityalliance.org/artifacts/devsecops-collective-responsibility）

「DevSecOpsの6つの柱：コラボレーションと統合」（2024年2月20日公開）

• （原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-collaboration-integration）

• 「DevSecOpsの6つの柱：実践的な実装」（2022年12月14日公開）
  • （原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-pragmatic-implementation）
• 「DevSecOpsの6つの柱：コンプライアンスと開発の橋渡し」（2022年2月8日公開）
  • （原版：https://cloudsecurityalliance.org/artifacts/devsecops-pillar-4-bridging-compliance-and-development）
• 「DevSecOpsの6つの柱：⾃動化」(2020年7月6日公開)
  • （原版：https://cloudsecurityalliance.org/artifacts/devsecops-automation）
  • （日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/04/DevSecOps-Automatio-ja.pdf）
• 「DevSecOpsの6つの柱：測定、監視、報告および⾏動」
  • （原版：https://cloudsecurityalliance.org/artifacts/the-six-pillars-of-devsecops-measure-monitor-report-and-action

DevSecOpsを実用的なものにするために、CSAガイダンスV5では、以下の通り、セキュリティをDevOpsプロセスに統合するための構造化アプローチを提示している。

• 検知（Detect）：警戒する見張り役のように行動するリアルタイムモニタリングシステムを実装して、セキュリティの課題や脅威、設定ミスをできるだけ早くスキャン・特定し、迅速な対応を保証する。
• 自動化（Automate）：技術を活用して、パッチのデプロイから構成管理まで、独立して運用するスマートシステムのように、繰り返されるセキュリティタスクを自動化し、セキュリティ対策が常に最新で一貫して強制されていることを保証する。
• 配備（Deliver）：馴染のツールを通して、セキュリティアラートが適切な専門家に到達することを保証する、効率的で直接の通信プロトコルを確立し、反応時間やチームの活動の効率性を最適化する。
• 修復（Fix）：ルーティンの清掃が、レストランの衛生基準を維持しているのと同じように、セキュリティの維持を毎日のルーティンに統合し、定期的でプロアクティブな運用の一部として、セキュリティ課題を解決する。

実用的なDevSecOpsと合わせて、CSAガイダンスV5では、シフトレフト戦略とセキュリティの組込を掲げている。シフトレフトは、セキュア・バイ・デザインやセキュア・バイ・デフォルトの製品であることを保証するために、SSDLCの早期フェーズに、セキュリティを移行させるべきだと示すために利用される言葉である。この手法は、SSDLCの下流フェーズの追加的セキュリティと比較して、費用対効果に優れているおり、脆弱性の早期検知に役立つとしている。

クラウドネイティブなアプリケーションセキュリティ対策としてのWAF

加えて、Webアプリケーションをデプロイ後まで保護する対策として、ゲートウェイサービスや、分散サービス拒否（DDoS）攻撃防止、Webアプリケーションファイアウォール（WAF）の実装を挙げている。これらのツールは、アプリケーションが正当なユーザーにアクセス可能であることを保証するために設計されており、効率的にWebトラフィックの流入を管理し、過負荷による潜在的クラッシュに対して保護することができる。特に、WAFは予防的防御であって、選択的制御や、貧弱に開発されたアプリケーション向けの保護策ではない点を強調している。

その上で、IaaS／PaaSサービスにおけるWAF／DDoS保護のための4つの共通デプロイシナリオを示している。

1. エージェントのデプロイ：IaaSの仮想マシンをWebサーバーとして利用する時、WAFエージェントを、OSの上位にインストールすることができる。通常、このオプションには、DDoS低減機能はない。
2. クラウドプロバイダーサービス：IaaS／PaaSプロバイダーは、通常ロードバランサーサービス上にデプロイされる、WAFとDDoS保護の統合型サービスを提供する。
3. サードパーティマーケットプレイスサービス：IaaS／PaaSマーケットプレイスは、専用VMにデプロイされた、様々なサードパーティ製商用WAFソフトウェアを提供する。WAFをデプロイし、ルーティングやリダンダンシー、ロードバランシングを保証するのは、顧客の責任である。
4. WAF／DDoS as a Service：DNSリダイレクトを利用して、消費者のトラフィックは、サードパーティWAFにルーティングされ、検証・フィルタリングした上で、クラウドプロバイダー環境にルーティングされる。

クラウドネイティブな新技術ならではの課題に注目

アプリケーションセキュリティの章の後半では、サーバーレス／コンテナの考慮事項を整理している。これらの技術はセキュリティプラクティスを変革する一方、新たなクラウドネイティブ環境ならではの課題への適応も求めている。具体的には、以下のような考慮事項を提示している。

[サーバーレスの考慮事項]

• 攻撃面の削減：サーバーレス機能の一時的な性質は、単独で、持続的なストレージのない短期運用を行い、本質的に攻撃に対する露出を抑制する。
• 依存性のリスク：製品製造時の既知の安全性記録を有するサードパーティコンポーネント利用に似たような、外部のコードまたはサービスへの依存。
• IAMの複雑性：サーバーレス機能の一時的で分散化した性質は、多数の継続的に変化するアクセスポイント全体のセキュリティ維持に匹敵する、複雑なアクセス管理を必要とする。

[コンテナの考慮事項]

• 分離のリスク：侵入者が簡単に入れる通路を可能にするコネクテッドルームの不適正な分離と同様に、コンテナ化環境における不十分な分離は、セキュリティ侵害をもたらし得る。
• 不可変インフラストラクチャ：コンテナは、デプロイ後不可変的になるように設計されており、一貫性を促進し、証拠改ざん防止パッケージのようにリスクを低減する。
• 複雑な構成管理：スケールが拡大するにつれて、コンテナの複雑なセキュリティ構成が課題となっており、複数施設に渡る先進的なセキュリティシステムの複雑なネットワークを監視するのに似ている。

最後に、アプリケーションセキュリティの章ではまとめとして、以下のような推奨事項を提示している。

[CSAセキュア開発ライフサイクル(SSDLC)]

• セキュアなデザインとアーキテクチャ：セキュリティを早期に統合するために、設計フェーズの間、技術やツールを適用して、費用の上昇や後のボトルネックを回避する。
• 継続的なビルド、統合、テスト：セキュリティ侵害を防止するため、デプロイ前に、脆弱性をテストするツールやプロセスを導入する。
• 継続的なデリバリーとデプロイ：アプリケーションがセキュアなインフラストラクチャ上にデプロイされていることを保証するために、デプロイ前安全性チェックを実行する。
• ランタイム防御とモニタリング：デプロイ前に、脆弱性や非効率性を継続的に特定・低減するためのプラクティスを実装する。

[構造化脅威モデリングの採用]

• 脅威を分類するためにSTRIDEフレームワークを適用する：偽造、なりすまし、否認、情報開示、サービス拒否、特権昇格

[セキュアなクラウド設計へのフォーカス]

• セキュリティの責任をプロバイダーに引き渡すために、PaaS（Platform as a Service）およびその他のCSPサービスを利用する。
• すべてのコンポーネントについて、最小特権およびアイデンティティ／アクセス管理（IAM）を実装する。
• インターネットへの露出を最小化するために、ロードバランサーやセキュリティグループのようなCSPサービスを利用する

[セキュリティテスト手法の統合]

静的アプリケーションセキュリティテスト（SAST）：デプロイ前に脆弱性や論理的エラーを特定するために、コードレビューを自動化する

ソフトウェア構成分析（SCA）：脆弱性やライセンシングのリスクに関して、外部コンポーネントを監査し、透明性のために、ソフトウェア部品表（SBOM）を生成する。

[包括的なデプロイ後テストの実行]

• 動的アプリケーションセキュリティテスト（DAST）：外部の観点から、アプリケーションのセキュリティポスチャーを評価するために、ブラックボックステストを実行する。
• 動的分析（ファジング）：運用中にエラーや脆弱性を特定するために、予測不能なデータを入力する。
• インタラクティブアプリケーションセキュリティテスト（IAST）：コードおよびランタイム双方における脆弱性を特定するために、SASTとDASTを組み合わせる。
• ペネトレーションテスト：既知の脆弱性を悪用して、システムのレジリエンスをテストするために、攻撃シミュレーションを実行する。
• バクバウンティプログラム：脆弱性を発見して報告するために、エシカルハッカーコミュニティを有効活用する。

[アクセス制御の強化]

• 不正アクセスを最小化するために、最小特権原則を適用する。
• 異常なアクセスパターンを検知して処理するために、継続的モニタリングを実装する。
• アクセス力を希薄化し、誤用を防止するために、職務分離を利用する。
• プラットフォーム間の相互作用を簡素化・セキュア化するために、フェデレーションを採用する。

[秘密管理]

• 人的エラーを最小化するために、資格情報を自動的に供給する。
• 金庫の貴重品のように、鍵をセキュアに保存する。
• セキュアなチャネルを介して秘密をAPIと統合する。
• 共有銀行口座のように、暴露なしの秘密の共有を促進する。

[秘密のCI／CDパイプラインへの統合]

• 組込型セキュリティチェックで、継続的な統合・デプロイを実装する。
• SSDLCにおいて早期に脆弱性を特定して処理するために、シフトレフト戦略を利用する。
• 一貫した強制と迅速なアップデートを保証するために、繰り返されるセキュリティタスクを自動化する。
• 開発、運用、セキュリティチーム間のコラボレーションを促進する。

[現代的なデプロイのためのセキュリティ戦略の適応]

• サーバーレスの考慮事項
  • 一時的なサーバーレス機能による攻撃面の削減を活用する。
  • 依存性リスクを処理し、複雑なIAM環境を管理する。
• コンテナの考慮事項
• 侵害を防止するために堅牢な分離を保証する。
  • 一貫性とセキュリティを促進するために、不変的なインフラストラクチャを利用する。
  • コンテナのデプロイの規模で複雑なセキュリティ構成を管理する。

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

クラウドセキュリティアライアンス（CSA）は、2024年7月15日、「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）を公開した。CSAガイダンスV5では、コンテナ／マイクロサービス／サーバーレスセキュリティの扱いが大幅に増えたのが特徴である。前編では、コンテナ、サーバーレス／FaaS、AIワークロードに関連する新ガイダンスの技術動向について概説する。

「仮想化とコンテナ技術」から「クラウドワークロードセキュリティ」へ

CSAガイダンスV4.0では、「仮想化とコンテナ技術」の章において、「コンピュート」、「ネットワーク」、「ストレージ」と並ぶ仮想化技術領域として「コンテナ」が取り上げられていた。そこでは、以下の通り、コンテナに係るクラウド事業者およびクラウド利用者向けの推奨事項を提示していた。

[クラウド事業者のための推奨事項]

• 仮想化に使われる基盤となるインフラの全てをそれ自体でセキュアにする
• テナント間のセキュリティ面の隔離を保証することに注力する
• 仮想化レイヤにおいて十分なセキュリティ機能を提供し、クラウド利用者がその資産のセキュリティを適切に確保できるようにする
• 物理インフォストラクチャと仮想化プラットフォームを攻撃者と内部不正に対してしっかりと防御する
• クラウド利用者が管理する全ての仮想化機能に対し、デフォルトでセキュアな設定を実装する

[クラウド利用者のための推奨事項]

• 利用しているクラウド事業者の提供する機能とセキュリティ上のギャップを確実に認識する
• 仮想化サービスを、クラウド事業者のガイダンスと業界の実践規範に沿って適切に設定する
• 利用するコンテナプラットフォームとその下のOSのセキュリティのための隔離機能を把握し、適切な設定を選択する
• コンテナ間の隔離の実施には物理マシンまたは仮想マシンを用い、同一の物理／仮想ホスト上の同一のセキュリティ要件のコンテナはグループ化する
• 配備対象となるのは、確実に、承認済みで認知済みでセキュアなコンテナのイメージかコードだけとなるようにする
• コンテナの統合化・管理およびスケジューラのソフトウェアのセキュリティを適切に設定する
• 全てのコンテナとリポジトリ管理に対して、適切なロールベースのアクセス管理と、強度の高い認証を実装する

これに対してCSAガイダンスV5では、「仮想化とコンテナ技術」から「クラウドワークロードセキュリティ」へと章の名称が変わった。参考までにCSAガイダンスV5の「8 クラウドワークロードセキュリティ」の章は、以下のような構成になっている。

8.1 クラウドワークロードセキュリティへの導入

• 8.1.1 クラウドワークロードのタイプ
• 8.1.2 クラウドワークロード：短期と長期
• 8.1.3 伝統的なワークロードセキュリティ制御への影響
• 8.1.4 ソフトウェア構成分析

8.1.5 ソフトウェア部品表（SBOM）

8.2 仮想マシン

• 8.2.1 仮想マシンの課題と低減策
  • 8.2.2 ファクトリーによるセキュアな仮想マシンイメージの生成
• 8.2.2.1 VM向けに推奨されるツールとベストプラクティス
• 8.2.3 デプロイメントパイプラインによるセキュアなイメージの生成
• 8.2.4 スナップショットと公的暴露／抽出

8.3 コンテナのセキュア化

• 8.3.1 コンテナイメージの生成
• 8.3.2 コンテナネットワーキング
• 8.3.3 コンテナオーケストレーション＆管理システム
• 8.3.4 コンテナオーケストレーションのセキュリティ
  • 8.3.4.1 アーティファクトレポジトリのセキュア化
  • 8.3.4.2 セキュアなレポジトリ利用に関するベストプラクティス
• 8.3.5 コンテナ脆弱性の管理
• 8.3.6 コンテナ向けのランタイム保護

8.4 PaaSセキュリティ

• 8.4.1 一般的なPaaS向けのセキュリティプラクティス
• 8.4.2 暗号化とアクセス制御
• 8.4.3 特定のPaaSのセキュア化

8.5 サーバーレス／FaaS（Function as a Service）のセキュア化

• 8.5.1 FaaSセキュリティの課題
• 8.5.2 サーバーレス向けIAM
• 8.5.3 ネットワーク接続とアクセスパターン
• 8.5.4 環境変数と秘密

8.6 AIワークロード

• 8.6.1 AIシステムの脅威
• 8.6.2 AI低減戦略

CSAガイダンスV5では、クラウドワークロードについて、クラウドコンピューティング環境で稼働する様々なタスク、アプリケーション、サービス、プロセスであり、仮想マシン（VMs）、コンテナ、サーバーレス／FaaS （Function as a Service）、AI、PaaS（Platform as a Service）など、幅広いリソースをカバーするものだとしている。

そして、クラウドワークロードと従来型環境の違いとして以下の3点を挙げている。

• 動的で拡張的：

データやワークロードが静的な従来型環境と異なり、クラウドは、継続的に進化する、動的で拡張的な背景を有している。このような環境の流動的な特性は、アジャイルで順応性があるセキュリティアプローチを必要とする。クラウドに挑むセキュリティ専門家にとって、これは、標準的なセキュリティ対策を再考して、関与のルールが継続的に書き換えられるような背景に適応することを意味する。

• 複雑性と多様性：

固有の要求事項を有する様々な種類のワークロードが存在するため、セキュリティに対する汎用的なアプローチは機能しない。

• 完全性、機密性、可用性：

クラウドワークロードセキュリティの中核は、データの完全性、機密性、可用性というサイバーセキュリティの基盤となる原則の維持にある。クラウドでは、データが変更できないこと（完全性）、認可されたユーザーだけがアクセスできること（機密性）、必要な時に利用可能なこと（可用性）の保証が重要である。

ガイダンスV5では、仮想マシンからコンテナ、サーバーレスアーキテクチャに至るまで、クラウドワークロードの開発・実装プロセス全体において、統合ソフトウェア構成分析（SCA）やソフトウェア部品表（SBOM）の役割を統合することによって、セキュリティだけでなく信頼性やコンプライアンスを保証できるとしている。進化するサイバー脅威動向に対してクラウド運用のセキュア化を図ろうとする組織にとって、このようなプラクティスは必要不可欠なものとなりつつある。

サーバーレス／FaaSとAIワークロードが表舞台に登場

CSAガイダンスV5では、クラウドワークロードのタイプとして、以下の5つを挙げている。

[仮想マシン（VMs）とインスタンス]

• クラウドサービスプロバイダー（CSP）が管理するハイパーバイザおよびその他の管理プレーンコンポーネントにより強制された、別個のOSを通して分離を提供する。
• ハイパーバイザは、クラウドサービスプロバイダー（CSP）が維持する重要なコンポーネントであるが、個々のVM内のゲストOSのセキュリティは、通常、クラウドサービスカスタマー（CSC）が取扱うので、周到な構成とパッチ当てが必要となる。
• さらに、VMスプロールは、重大なセキュリティリスクを示す可能性がある。
• 加えて、スナップショットやイメージの管理は、機微データの漏えいを防止するために重要であり、厳格なガバナンスを必要とする。

[コンテナ]

• コンテナは、ホストOSのカーネルを共有する、分離したランタイム環境であるが、自らのファイルシステムやライブラリ、構成を備えた別個の自己完結型プロセスとして稼働する。
• コンテナは、軽量で効率的なVMの代替品を提供するが、異なるセキュリティ課題を示す。コンテナは、ホストOSカーネルを共有するので、本質的に弱い分離を提供する。
• コンテナ化した環境におけるセキュリティは、正確にOSレベルの制御を構成し、コンテナイメージのセキュリティを維持し、コンテナのランタイム環境が適切に構成されていることを保証するように決定される。
• Kubernetesのようなオーケストレーターのセキュリティ強化における利点にも関わらず、オーケストレーターは、侵害防止のために注意深く切り抜けなければならないような追加的複雑性をもたらす。

[PaaS（Platform as a Service）]

• PaaSは、より効率的でオーバーヘッドの少ないアプリケーションの開発、実装、管理を促進するような、一連のツールおよびサービスを提供することによって、クラウドプラットフォームの機能を拡張する。
• データベースやメッセージングシステムから、コンテンツデリバリーネットワーク（CDN）に至るまで、様々なサービスに基づいたセキュリティ考慮事項を示す。

[サーバーレス／FaaS（Function as a Service）]

• FaaSは、開発者が、基盤となるインフラストラクチャの管理なしに、イベントやリクエストに対応して実行されるような個々の機能を書いてデプロイするクラウドコンピューティングモデルである。
• サーバーレスモデルは、セキュリティ責任のより多くの部分をCSPに委ねる。この信頼性の再割り当てにより、CSPの特別なセキュリティ専門知識と先進的な保護対策を活かして、攻撃表面を最小化する。CSPによる強制された分離とともに、実行環境の短期的な性質が、固有のセキュリティの利点を提供する。
• サービス拒否（DoS）攻撃や自動スケーリングによる経済的疲弊など、不正アクセスや潜在的攻撃に対するサーバーレスアプリケーションの保護のために、最小特権による秘密の管理と機能の構成が最も重要である。

[AIワークロード]

• AIワークロードは、膨大な量の学習用データを処理して、意思決定を行い、予測を提供する。敵対的攻撃に対する保護、モデルの盗難の防止、プロンプトインジェクションに対する保護を特に強調しながら、データの完全性とプライバシーを保証することが最も重要である。
• このような脆弱性にも関わらず、AIワークロードは、先進的な計算処理リソースとクラウド環境の拡張性を活用する。

一般的に、クラウドワークロードになると、特にサーバーレスコンピューティングのようなモデルにおいて、管理責任がCSP側にシフトする。攻撃表面が消失する可能性がある反面、可視性、制御、ガバナンスの課題は持続する。従って、セキュリティモニタリングやガバナンスは、すべてのクラウドワークロードに渡って堅牢なセキュリティポスチャを維持する際に重要となり、運用が妨げられることなく維持でき、データ保護規制を遵守していることを保証するとしている。

CSAガイダンスV4.0と比較すると、V5では、サーバーレス／FaaSやAIワークロードといった新トピックを網羅している点が注目される。

クラウドワークロードセキュリティの推奨事項

最後に、CSAガイダンスV5の「クラウドワークロードセキュリティ」では、以下のような推奨事項を提示している。

[クラウドワークロード管理]

• 集中型クラウドデプロイメントレジストリの生成：効率的なトラッキングと管理のために、すべてのクラウドワークロードおよびデプロイメントの包括的なインベントリを維持する
• 複数のデプロイメントを利用した組織階層の定義：セキュリティおよび管理の制御の向上のために組織ユニットを反映するクラウド環境を構築する
• 新たなデプロイメント生成のための低摩擦プロセスのサポート：運用効率性を妨げることなくセキュリティポリシーの遵守を保証するためにプロセスを簡素化する

[仮想マシンセキュリティ]

• 安全なベースVMイメージの強制：集すべてのデプロイメント向けに、中管理でバージョン化された、不変のベースイメージを利用する
• イメージファクトリーの実装：一貫性とセキュリティを保証するために、VMイメージの生成、テスト、デプロイメントを自動化する
• VMイメージの脆弱性スキャン：セキュリティリスクを低減するために、定期的にスキャンし、VMイメージをアップデートする
• 短期間稼働のVMの採用：長期間稼働のインスタンスに関連するリスクを低減するために、不変のインフラストラクチャと一時的なVMを利用する
• 構成管理とIaC（Infrastructure as Code）の利用：望ましい状態を維持し、構成ドリフトを防止する

・ホストベースのファイアウォールとSSHハードニングの実装：ネットワークアクセスを制御し、VMインスタンス上のSSH構成をセキュアにする

[コンテナオーケストレーションセキュリティ]

• オーケストレーション向けのCSPサービス利用：セキュリティ強化のためにKubernetes-as-a-Serviceのようなマネージドサービスを有効活用する
• オーケストレーションサービスのハードニング：不必要な機能を無効化し、最小特権アクセスを保証して、ネットワークポリシーおよびファイアウォールを実装する
• 定期的なパッチ当てとアップデート：コンテナ、ホスト、オーケストレーションプラットフォーム向けパッチ管理の自動化
• セキュリティポリシーの定義と強制：Kubernetes Security Policy、PodSecurityPolicy（注：Kubernetes 1.25では削除）、NetworkPolicyのようなツールを利用する
• セキュリティベンチマークとツールの有効活用：Kubernetesの安全な構成を保証するために、CISベンチマークをフォローする
• クラスターのホストとストレージの保護：ホストOSをハードニングし、保存時および転送時のデータの暗号化を適用して、アクセス制御リスト（ACL）を利用する

[モニタリングと評価]

• CSPMツールの有効活用：クラウドセキュリティポスチャー管理（CSPM）ツールを利用して、クラウドセキュリティポスチャーを継続的にモニタリングする
• 継続的モニタリングの実装：ワークロードの活動を追跡し、潜在的なセキュリティインシデントを迅速に検知するために、リアルタイムモニタリングツールを利用する
• SCAツールの利用：依存性を管理し、脆弱性を早期に特定するために、ソフトウェア構成分析（SCA）ツールをCI/CDパイプラインに統合する
• SBOMの生成と維持：透明性、セキュリティ対応、規制遵守を強化するために、すべてのワークロード向けにソフトウェア部品表（SBOM）を生成する
• エンドポイント検知・対応（EDR）エージェント：ランタイムモニタリングを実行し、脆弱性評価をサポートする
• セキュリティ情報・イベント管理（SIEM）：リアルタイムのモニタリングとレポーティングを提供する

[トレーニングと意識]

• 定期的なセキュリティ演習の実行：チームがリアルワールドインシデントの準備をするために、シナリオベースの演習や机上訓練を実行する
• 安全文化アプローチの推奨：セキュリティインシデントに関して過度の責任を負わせることなく、全体的な向上と説明責任に焦点を当てる

[PaaSセキュリティ]

• 定期的なセキュリティ監査：潜在的脅威を特定し低減するために、脆弱性評価を実行する
• 包括的なロギングとモニタリング：疑いのある行動を検知して対応する
• 最小特権の原則：ユーザーやサービスに必要最小限のアクセスレベルを付与する
• 多要素認証（MFA）：MFAでアクセス制御を強化する
• 定期的なアクセスレビュー：適正なアクセスレベルを保証するために、定期的に、アクセス許可を再評価する

[サーバーレス／FaaS（Function as a Service）セキュリティ]

• サードパーティサービスとAPIの点検：不正な構成やデータ漏えいを回避するために、それらがセキュアで信頼できることを保証する
• 脆弱な依存性の管理：脆弱性や悪意のあるコードに関して、外部ライブラリを定期的にアップデートし、チェックする
•  設定ミスの修正：セキュリティ設定が機能の展開およびアクセスを適切に制限していることを保証する
• 機能に関するアイデンティティ／アクセス管理（IAM）特権の制限：不正アクセスやデータ漏えいのリスクを低減するために、必要最小限の許可を付与する
• インターネットへの直接アクセスの制御：機能が直接インターネットにアクセスすることを防止するために、ネットワークセグメンテーションとACLを実装する

[AI低減戦略]

• データセキュリティ：データを保護するために、暗号化、差分プライバシー、セキュアなマルチパーティ計算を利用する
• モデルセキュリティ：敵対的な攻撃に対してモデルをハードニングし、堅牢なトレーニング手法を利用し、盗難防止のために固有識別子を組み込む
• インフラストラクチャセキュリティ：割当・レート制限を実装し、クラウドサービスに関するベストプラクティスをフォローする
• サプライチェーンセキュリティ：サイバーセキュリティポリシーを定義し、定期的にサードパーティの依存性を監査し、信頼されたリソースを利用する

特に、サーバーレス／FaaSセキュリティについてみると、厳格なアイデンティティ／アクセス管理（IAM）に始まるように、セキュリティへの集中的なアプローチが求められる。不正アクセスに対するAPIのエンドポイントセキュリティを強化し、高度な監視下で秘密を管理することが暴露を防止する鍵になるとしている。

後編では、CSAガイダンスV5の中でマイクロサービスのセキュリティに関連が深いアプリケーションセキュリティの新技術動向について概説する。

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

クラウドセキュリティアライアンス(CSA)では、旧アプリケーションコンテナ／マイクロサービスWGが、クラウドネイティブなコンテナ／マイクロサービスのセキュリティから、CI/CDパイプラインの自動化、DevSecOpsの発展に焦点を当てる一方、旧DevSecOps WGが、DevSecOpsによるアプリケーションの迅速なデリバリーとビジネス価値の創出（＝プラットフォームエンジニアリング）をめざすべく、AIに代表される新技術の活用に着目した活動を行っている。

コンテナ／マイクロサービスのセキュリティからDevSecOpsへの発展

旧CSAアプリケーションコンテナ／マイクロサービスWGは、米国立標準技術研究所（NIST）の「SP 800-180(Draft): NIST マイクロサービス、アプリケーションコンテナ、システム仮想マシンの定義」（2016年2月）（https://csrc.nist.gov/pubs/sp/800/180/ipd）より、以下のような定義に準拠して各文書を作成してきた。

• アプリケーションコンテナ：共有OS上で稼働するアプリケーションまたはそのコンポーネントとしてパッケージ化し、稼働するように設計された構成物
• マイクロサービス：アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに分解した結果生まれる基本的要素であり、標準的な通信プロトコルや明確に定義された API を利用して相互に通信する自己充足型サービスを構成し、いかなるベンダー、製品、技術からも独立している

CSAの「安全なアプリケーションコンテナとマイクロサービスにおける課題」（2019年7月16日）（https://cloudsecurityalliance.org/artifacts/challenges-in-securing-application-containers-and-microservices）では、「NIST SP 800-160 システムセキュリティエンジニアリング：信頼された安全なシステムのエンジニアリングにおける分野横断的なアプローチのための考慮事項」（最新版：第1巻改訂第1版（2022年11月16日）（https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final））を参照しながら、以下の通り、「開発者」、「運用者」、「アーキテクト」の観点を設定している。

• 開発者：クラウドサービス開発者は、クラウドサービス実装の設計、開発、検証、維持に責任があるようなクラウドサービスパートナーの副次的役割である。これには、既存のサービス実装からのサービス実装の構想も含めることができる。
• 運用者：ITサービスをデプロイして管理する一連のプロセスに責任を有する個人または組織。運用者は、ネットワークインフラストラクチャ、サーバーとデバイスの管理、コンピューター運用、ITインフラストラクチャライブラリ（ITIL）管理、ヘルプデスクサービスなど、内部および外部の顧客に対するアプリケーションのデプロイをサポートするようなインフラストラクチャおよび運用環境の円滑な機能を保証する。
• アーキテクト（マイクロサービス）：戦略的設計の推奨事項に責任のある個人または組織。アーキテクトは、クラウド、コンテナ、マイクロサービスのコンポーネントに関する知識をビジネス課題に適用して、ビジネスの戦略的ニーズを満たす最善のアーキテクチャを決定する。加えて、ソリューションロードマップを構築・維持し、効率的で効果的なソリューションの実装を保証するために、開発者や運用者と協働しながら採用を監督する。

その上で、信頼性のある安全なシステムのエンジニアリングにおいて、アプリケーションコンテナやマイクロサービスのセキュリティに取組む際の課題を特定している。

CSAの「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」（2019年7月26日）(日本語訳版：https://cloudsecurityalliance.org/artifacts/best-practices-for-implementing-a-secure-application-container-architecture-japanese-translation）では、開発者および運用者の観点から、アプリケーションコンテナを安全にするための課題として、以下の17項目を挙げている。

1. 環境全体のコードプロモーション
2. ホストをセキュアにする
3. プラットフォーム/ホストからのコンテナ継続性監視
4. コンテナネットワーク – ホストとコンテナ間の通信
5. コンテナネットワーク – コンテナ間通信
6. イメージの完全性とセキュリティレベルの検証
7. コンテナのフォレンジック
8. コンテナによるトラストチェーン
9. コンテナのボリューム管理
10. コンテナのシークレット管理
11. プラットフォーム管理 -ライフサイクルイベント通知
12. プラットフォーム管理 – リソース要求
13. プラットフォーム管理 – コンテナリソース管理
14. コンテナ管理 – コンテナリソースのスケーリング
15. コンテナ管理 – データのバックアップとレプリケーション
16. コンテナ管理 – CMP間のコンテナのホスト変更
17. コンテナの暗号化

この文書では、特に開発者、運用者の双方が関係する課題およびその低減策として、以下を挙げている。

5. コンテナネットワーク – コンテナ間通信
（低減策）アプリケーションは、安全なネットワーク通信プロトコルを使用する必要がある
6. イメージの完全性とセキュリティレベルの検証
（低減策）開発者は開発プロセスの一部として脆弱性スキャンツールを使用する必要がある
8. コンテナによるトラストチェーン
（低減策）開発者はイメージのビルドプロセスの一部としてイメージに署名し、イメージを使用開始前に検証すべきである
開発者は開発プロセスの一環として脆弱性スキャンツールを使用すべきである
17. コンテナの暗号化
（低減策）開発者と運用者は標準的な、一般的に利用されている認証システムを採用するべきである

このようにアプリケーションコンテナが、従来のIaaS／PaaS／SaaSに代表されるクラウドサービスと異なるのは、アプリケーションの開発とデプロイの自動化を実現するために、開発者チーム（Dev）と運用者チーム（Ops）の間の協力やコミュニケーションの強化が必要不可欠となる点である。

CSAの「クラウドコンピューティングのためのセキュリティガイダンス v4.0」日本語版1.1（2018年7月24日）（https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.1_20180724.pdf）では、「Domain 8：仮想化とコンテナ技術」において、DevOpsに関して以下のように説明している。

• アプリケーションの開発とデプロイを自動化することにフォーカスした、アプリケーション開発の新しい方法論であり考え方である
• 開発チームと運用チームの間の協力とコミュニケーションを改善してより深く結びつけることを意味し、特にアプリケーションのデプロイとインフラストラクチャの運用の自動化に焦点を当てている
• コード堅牢化、変更管理、本番アプリケーションのセキュリティを改善するだけでなくセキュリティ運用全般をも強化してくれる

そのうえで、DevOpsのセキュリティへの波及効果／長所として、以下のような点を挙げている。

• 標準化：DevOps では、本番に組み込まれるものはすべて、承認済みのコードと設定用テンプレートに基づき、継続的インテグレーション／継続的デプロイ（CI/CD）パイプラインによって生み出される。開発、テスト、本番（のコード）はすべて完全に 同一のソースファイルから派生しており、周知となっている優れた標準からの逸脱を防いでいる。
• 自動化されたテスト：広範な種類のセキュリティテストは、必要に応じて補助的に手動テストを加えることで、CI/CD パイプラインに組み込むことが可能である。
• 不可変性(immutable)：CI/CD パイプラインは、素早く確実に、仮想マシンやコンテナ、インフラストラクチャスタックのマスターイメージを生成する。これにより配備の自動化と不可変(immutable)なインフラストラクチャを実現する。
• 監査と変更管理の改善：CI/CD パイプラインはソースファイルにある 1 文字の変更に至るまでの全てを追跡調査できる。バージョン管理リポジトリに格納され たアプリケーションスタック（インフラストラクチャを含む）の全履歴と共に、その変更は変更を行った人物と紐づけられる
• SecDevOps/DevSecOps とRugged DevOps：SecDevOps/DevSecOps は セキュリティ運用を改善するために DevOps の自動化技術を使う。Rugged DevOps はアプリケーション開発過程にセキュリティテスティングを組み入れることを意味し、より強固で、よりセキュアで、より障害耐性の高いアプリケーションを生み出す。

このように、コンテナ／マイクロサービスを支えるCI/CDパイプラインをベースに、アプリケーションのデプロイとインフラストラクチャ運用の自動化をめざす中で、DevOpsからDevSecOpsへと進化していった。

CSAにおける再帰的セキュリティからDevSecOpsへの展開

他方、CSAの旧アプリケーションコンテナ／マイクロサービスWG と並行して、旧 DevSecOps WGは、2019年8月1日、「再帰的セキュリティを通じた情報セキュリティ管理」を公開している（https://cloudsecurityalliance.org/artifacts/information-security-management-through-reflexive-security ）。その中で、「再帰的セキュリティ」について、組織のセキュリティのスタンスおよび配布物を保護するために必要な、セキュリティ、開発、運用の間の相互関係に基づいた、新たなセキュリティ管理手法と定義している。

その上で、DevOpsについて、集団的コラボレーションのような開発のベストプラクティスをインフラストラクチャの運用に適用させるプラクティスであり、特にクラウド環境における開発・運用チームの効率性にポジティブなインパクトを示してきたとしている。その採用を強化するためには、情報セキュリティ自体へのインパクトを考慮し、情報セキュリティ管理領域へのプラクティスの適用に目を向ける必要があるとしている。

その直後の2019年8月7日、旧DevSecOps WGは、「DevSecOpsの6つの柱：セキュリティ、開発、運⽤の統合による再帰的セキュリティの実現」を公開している（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-of-devsecops）（日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/11/The-Six-Pillars-of-DevSecOps-Achieving-Reflexive-Security-Through-en_us-ja.pdf）。

この文書は、ソフトウェアの開発と公開における複雑さを軽減し、既知の信頼できるコンポーネントとサービスのみを使⽤するようにし、開発⼿法に直接統合されたセキュリティリソース（⾃動化されたものと⼈の⼿によるものの両⽅）をソフトウェア開発チームに提供し、セキュリティが⼗分に確保され、監視された開発環境を使⽤し、最終的に、設計どおりに、設計された機能のみを備えた最終製品を提供することを目標としている。

DevOpsは、集団的コラボレーションなどの開発のベストプラクティスをインフラストラクチャ運⽤に適⽤するプラクティスであり、特にクラウド環境において、今⽇の開発および運⽤チームの効率にプラスな影響を与えることが⽰されている。旧DevSecOps WGは、ISO/IEC 27000 ファミリー規格および前述の「再帰的セキュリティを通じた情報セキュリティ管理」を参照しながら、以下の通り、DevSecOps を実装し組織に統合するために不可⽋な、DevSecOps の6つの重点分野を定義している。

[第1の柱：集団的責任]

DevOpsにセキュリティを組み込む際の大きな課題の1つが、ソフトウェアセキュリティに関する組織のマインドセットや、アイデア、習慣、行動の変更である。セキュリティのDevOps組織への導入により、セキュリティは、他の誰かの責任としてみなすことができなくなっている。それは、誰か他の業務が完了した時のみに取組むべき補足事項と考えるべきでない。加えて、セキュリティは、ビジネス目標から切り離し、区別して見ることができない。最後に、セキュリティは、いくらか一時的なもので、進化や貢献が評価できない。

組織のセキュリティのスタンスに関して、誰もが責任を有する。CSO（クラウドセキュリティオフィサー）は、組織内の情報セキュリティに関して、リーダーおよび羊飼いの役割を果たすが、個々人は、自身のセキュリティ責任を有しており、組織のセキュリティのスタンスに対する自身の貢献を認識しなければならない。エッジのユーザーや開発者は、単に”セキュリティの認識がある”のではなく、防御の第一線にいる。これが再帰的セキュリティフレームワークの「集団的責任」に対応している。

[第2の柱：コラボレーションと統合]

開発、運⽤、セキュリティの各分野において、ソフトウェア業界には膨⼤なスキル（知識）と⼈材（リソース）のギャップが存在する。セキュリティの導⼊に関して組織全体が協⼒しなければ、成功は限られたものになる。セキュリティは、対⽴ではなく協⼒によってのみ達成できる。すべての機能チームのメンバーが潜在的な異常を報告できるようにするためには、セキュリティを意識した協⼒的な⽂化が必要です。⼈的要因はしばしば最も弱いリンクであり、実際に、セキュリティインシデントのほとんどは、単純なヒューマンエラーによって引き起こされることを覚える必要がある。これが「再帰的セキュリティ」のフレームワークの「協⼒と統合する」に対応している。

[第3の柱：実践的な実装]

DevSecOpsでは、ポイントソリューションが数多く提供されている。組織は、ソフトウェアライフサイクルの中でアプリケーションセキュリティを実装するために、さまざまなツールやソリューションを選択できる。ソフトウェアライフサイクルは、構造、プロセス、全体的な成熟度においてそれぞれ異なるため、DevSecOpsを実装するための万能なツールは存在しない。組織はしばしば、導⼊が難しく、運⽤が困難で、結局は真のセキュリティリスクの軽減に役⽴つ、実⽤的な洞察を提供しないツールやポイントソリューションの調達に終始する。

組織は、ソフトウェアのライフサイクル、組織⾃⾝のセキュリティのニーズ、そして求める将来の状態を総合的に捉え、⾼度な統合性を提供するプラットフォームソリューションを選択する必要がある。デジタル社会における安全、プライバシー、および信頼を確保するために、アプリケーション開発に焦点を当てたフレームワークにとらわれない「デジタルセキュリティとプライバシーモデル」を使⽤することで、組織はDevOpsにおけるセキュリティに実⽤的な⽅法でアプローチできる。このモデルは、すべての利害関係者（開発、運⽤、セキュリティ）を、セキュリティが、アプリケーションとアプリケーションを⽣み出すソフトウェアライフサイクルに組み込まれる形で組み込まれるという、現状では満た
されていないニーズを満たすものである。これが、「再帰的セキュリティ」の枠組みにおける「実践的な実装」に対応している。

[第4の柱：コンプライアンスと開発の橋渡し]

リスクに関連した要求事項を、時間の経過に従って容易に評価できるセキュリティ要求事項に変換することは難しい。セキュリティチームがリスクベースの⼿法をサポートするために要件を作成するとしても、コンプライアンス要件はDevOpsや製品要件にうまく変換されていない。逆に、技術的なコントロールが実装されていても、セキュリティ要件が満たされているという証拠を得ることは容易でない。

ソフトウェア開発のパラダイムとプラクティスの急速な進化を考えると、コンプライアンスとアジャイルソフトウェア開発はもはや同じ⽴場に置くことができない。規制・コンプライアンス部⾨は、その各プロセスの実⾏を実際に監査することよりも、プロセスが存在することを証明することに関⼼がある。⼀⽅で、ほとんどのDevOpsチームは、証明はコードの中にあり、プロセスの⽂書化の中にはないと考えている。

コンプライアンスと開発の間のこのギャップに対処する鍵は、適⽤可能なコントロールを特定し、それを適切なソフトウェア対策に変換し、ソフトウェアライフサイクル内の変曲点を特定し、そこでこれらのコントロールを⾃動化して測定することにより、リスク軽減の質を向上させ、その結果、コンプライアンスを改善することである。これが、「再帰的セキュリティ」の枠組みにおける「整列と橋渡し」に対応する。

[第5の柱：⾃動化]

最⼩限のコストで迅速にセキュアな配備を実現するためのソフトウェア開発⼿法を妨げている課題のいくつかは、⼿作業による⾏き当たりばったりのコーディング、テスト、デプロイ、およびパッチの適⽤である。

⾃動化された品質チェックがなければ、⼿作業によるコーディングは容易に、⼿直しが必要なパフォーマンスの低い、セキュアでないソフトウェアになる。さらに、⼿作業やタイミングの悪いテストでは、デプロイ前に脆弱性が特定される可能性を低くする。⼿作業によるデプロイとパッチの適⽤は、セキュアでないソフトウェアを本番環境にリリースする可能性がある。

⾃動化されたセキュリティ対策は、⼿作業によるプロセスを減らし、効率化して、⼿戻りを減らすことができるため、プロセス効率の中核となる。ソフトウェアの品質は、テスト／フィードバックの徹底性、適時性、および頻度を改善することによって向上できる。⾃動化できるプロセスは⾃動化し、⾃動化できないプロセスは可能な限り⾃動化するか、廃⽌を検討すべきである。⾃動化されたセキュリティチェックは、ビルドの遅延や失敗といった新たな課題を引き起こす可能性があるが、これらは通常、ワークフローの改善や半⾃動化アプローチで対処できる。ソフトウェア開発には、「同じことを3回やったら、そろそろプログラミングの時期だ」という格⾔があり、これは、再帰的セキュリティに正⾯から当てはまる。これが、再帰的セキュリティの枠組みにおける「⾃動化」に対応する。

[第6の柱：測定、監視、報告および⾏動]

「測定できない（あるいは測定しない）ものは管理できない」という格⾔は、DevSecOpsの実装と保守によく当てはまる。⼀般的なDevSecOpsイニシアチブは、スコープと複雑さにもよるが、実装に数ヶ⽉から数年を要する。実⾏可能なメトリクスがなければ、進捗を評価することはできず、失敗をタイムリーに発⾒することもできない。

DevSecOps環境で監視すべき最も重要なメトリクスには、デプロイメントの頻度、脆弱性パッチの適⽤時間、⾃動的にテストされるコードの割合、アプリケーションごとの⾃動テストがある。DevSecOpsを成功させるためには、ソフトウェア開発中だけでなく、デリバリー後の結果も、適切な⼈々によって適切なタイミングで（継続的に）測定、監視、報告、および対処される必要がある。これが、再帰的セキュリティのフレームワークの枠組みにおける「測定と改善」に対応する。

その後、旧DevSecOps WGは、以下の通り、個々の6領域に関する成果物を公開している。

• 「DevSecOpsの6つの柱：集団的責任」（2020年2月21日公開）
  （https://cloudsecurityalliance.org/artifacts/devsecops-collective-responsibility）
• 「DevSecOpsの6つの柱：コラボレーションと統合」（2024年2月20日公開）
  （https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-collaboration-integration）
• 「DevSecOpsの6つの柱：実践的な実装」（2022年12月14日公開）
  （https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-pragmatic-implementation）
• 「DevSecOpsの6つの柱：コンプライアンスと開発の橋渡し」（2022年2月8日公開）
  （https://cloudsecurityalliance.org/artifacts/devsecops-pillar-4-bridging-compliance-and-development）
• 「DevSecOpsの6つの柱：⾃動化」(2020年7月6日公開)
  （https://cloudsecurityalliance.org/artifacts/devsecops-automation）
  （日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/04/DevSecOps-Automatio-ja.pdf）
• 「DevSecOpsの6つの柱：測定、監視、報告および⾏動」
  （https://cloudsecurityalliance.org/artifacts/the-six-pillars-of-devsecops-measure-monitor-report-and-action）

この旧DevSecOps WGと前述の旧アプリケーションコンテナ／マイクロサービスWGが統合してできたのが、現在のCSA DevSecOps WGである。

なお昨今、先進的なテクノロジーを活用したプラットフォームにより、アプリケーションのより迅速なデリバリーとビジネス価値の創出を可能にする革新的な手法として、「プラットフォームエンジニアリング」への関心が高まりつつあり、ジェネレーティブAI（生成AI）の有効活用領域としても注目されている。

現在、CSA DevSecOps WGでは、機械学習モデルをビジネスに適用したMLOps関連ドキュメントの作成準備を行っている。この領域では、CSA AI組織的責任WGが、2024年5月5日に「AIの組織的責任 – コアセキュリティ責任」（https://cloudsecurityalliance.org/artifacts/ai-organizational-responsibilities-core-security-responsibilities）と第する文書を公表しており、WGの枠を越えた連携活動を展開する予定である。

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

クラウドセキュリティアライアンス（CSA）ジャパンの関西支部とDevSecOps／サーバーレスWGは、2019年から2020年までの間、以下のようなワークショップを開催してきた。

• 2019年7月16日：「アプリケーションコンテナ／マイクロサービスのセキュリティ概説」
• 2019年9月17日：「エッジ／フォグコンピューティング環境におけるコンテナ／マイクロサービスのメリットとリスク」
• 2019年11月12日：「北欧のリビングラボから俯瞰するスマートシティICTの現状と課題」
• 2020年1月10日：「世界のコンテナ／マイクロサービス技術動向から俯瞰する関西の2025年」

現在、2025年大阪・関西万博開催に向けた準備が急ピッチで進む中、CSA関西支部およびDevSecOps／サーバーレスWGは、これらクラウドネイティブ技術の有効活用および安定的なDevSecOps体制の構築・運用支援に焦点を当てた情報発信および公開ワークショップを行う計画である。今回は、コロナ禍以降のアプリケーションコンテナ／マイクロサービス／サーバーレスに係るセキュリティ動向を概観する。

コロナ禍の保健医療分野で拡大したクラウドネイティブアーキテクチャ

コロナ禍の間に、コンテナ／マイクロサービス／サーバーレスに代表されるクラウドネイティブアーキテクチャが積極的に導入された事例として、欧州連合（EU）の新型コロナウイルス感染症（COVID-19）接触追跡アプリケーション越境連携ゲートウェイサービスがある。EU傘下のeヘルスネットワークが2020年6月16日に公表した技術仕様文書では、コンテナプラットフォーム（例：KubernetesベースのOpenShift）、REST API（例：Node.jsとExpress）、分散NoSQLデータベース（例：MongoDB）、ロードバランサー（例：Docker上のHAProxy）、Webサーバ（例：Docker上のNginx）から構成されるデプロイを例示している（https://health.ec.europa.eu/publications/ehealth-network-guidelines-eu-member-states-and-european-commission-interoperability-specifications_en）。

また、EUが、2021年6月1日に正式運用を開始した域内共通の「EUデジタルCOVID証明書」の技術仕様書においても、DockerやKubernetesなど、コンテナプラットフォームによるデプロイが例示されている（https://health.ec.europa.eu/document/download/c0a07892-a01c-4bc8-8e9f-1e91d9597d17_en）。さらに欧州委員会は、2023年6月5日、世界保健機関（WHO）と共同で、グローバルモビリティを推進し、パンデミックなど現在および将来の健康脅威に対する世界中の市民の保護を支援するために、「WHOグローバルデジタルヘルス認証ネットワーク（GDHCN）」を発足させることを発表した（https://www.who.int/news/item/05-06-2023-the-european-commission-and-who-launch-landmark-digital-health-initiative-to-strengthen-global-health-security）。直後の同年7月1日には、WHOが、GDHCN向けに、EUのCOVIDデジタル証明書システムを取り入れることを表明している（https://commission.europa.eu/strategy-and-policy/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en#timeline）。

GDHCNは、医療機関の間や国境を越えて証明可能な保健医療文書のポータビリティを実現するグローバルなデジタル公共インフラストラクチャであり、2024年5月時点で、75カ国以上がネットワークに参画している、COVID-19パンデミック期間中のワクチン接種証明書の検証目的で生まれたGDHCNは、WHOを事務局として、以下のような領域にユースケースを拡大する方針である。

• 小児の予防接種記録
• 国際的な患者サマリ
• ワクチン接種または定期補充療法の国際的証明
• 保健医療従事者の資格情報（免許、登録および教育）
• 電子処方せん
• 越境遠隔診療
• 健康保険証

GDHCNは、以下のようなコンポーネントを提供している。

• 保健医療文書向けのデータ標準規格（例．LH7-FHIR）
• デジタル保健医療文書の由来を証明するために利用するコードの共有向けの公開鍵インフラストラクチャ
• 異なるシステム間での互換を可能にするような情報を有するナレッジライブラリ

なおWHOは、EUと同様に、オープンソースソフトウェアベースの概念を採用し、GitHubなどのオープンコミュニティを通じた活動を積極的に支援している（https://github.com/WorldHealthOrganization）。

ゲノムデータ研究でも浸透するクラウドネイティブアーキテクチャ

オープンソースソフトウェアベースのクラウドネイティブアーキテクチャを活用する動きは、ゲノムデータを取扱うバイオバンクの間でも広がりつつある。

たとえば欧州では、2022年までにEU域内で少なくとも100万人のシーケンスゲノムにアクセス可能にするという、EU加盟国による2018年宣言の実現をめざす組織として、2018年4月10日に「1+MGイニシアチブ」が創設された（https://digital-strategy.ec.europa.eu/en/news/eu-countries-will-cooperate-linking-genomic-databases-across-borders）。1+MGイニシアチブでは、EUの2014年～2020年研究開発促進プログラムである「ホライズン2020」の一環として、「B1MG（Beyond 1 Million Genomes）」プロジェクトが実施された（https://b1mg-project.eu/）。その後2022年より、EUのデジタルヨーロッパプログラムの支援金を受けた「欧州ゲノムデータインフラストラクチャ（GDI）」が進行中である（https://gdi.onemilliongenomes.eu/）。

GDIは、2023年6月26日、B1MGプロジェクトからの希少疾患およびがんの概念実証（PoC）をベースに、「GDIスターターキット」をリリースした（https://gdi.onemilliongenomes.eu/news/gdi-starter-kit）。このツールは、全ての国に、国境を越えて合成ゲノムデータおよび表現型データにアクセスするための技術的ケーパビリティを付与することを目的としており、GDIが共同開発したソフトウェアアプリケーションおよびコンポーネント群をソリューションパッケージとして提供している。ここでも、Dockerに代表されるクラウドネイティブなオープンソースプラットフォームが採用されている。GDIもープンソースソフトウェアベースの概念を採用し、GitHubなどのオープンコミュニティを通じた活動を積極的に支援している（https://github.com/GenomicDataInfrastructure）。

従来のバイオバンクは、クローズドなオンプレミス環境を前提とする境界型防御に依存したセキュリティ管理策をとってきた。これに対して、クラウドネイティブアーキテクチャやオープンソースソフトウェアをベースとする標準化されたプラットフォームが続々と登場しており、責任共有モデルを前提としたマルチステークホルダー型のセキュリティ管理体制へのシフトが求められつつある。

ハードウェア駆動型生成AI向けマイクロサービスの台頭

最近、コンテナを組合せたマイクロサービスの開発・提供に積極的に取り組んでいるのが、半導体業界である。たとえばNVIDIAは、2024年3月18日、独自のAIモデルと業界標準のアプリケーションプログラミングインタフェース（API）を装備したワークフローなど、クラウドネイティブアプリケーションの構築・デプロイ向けのビルディングブロックとして機能する、医療向け生成AI関連マイクロサービス群を発表している（https://nvidianews.nvidia.com/news/healthcare-generative-ai-microservices）。

元々、NVIDIAは、グラフィックス処理装置（GPU）の利点を生かしたコンテナ技術（Docker、Podman、Kubernetesなど）の開発・実装に積極的であり、開発者向けにコンテナツールキットを提供してきた（https://github.com/NVIDIA/nvidia-container-toolkit/）。NDIVIAは、今回発表したマイクロサービス群を、先進的画像処理や自然言語処理、デジタルバイオロジーの生成・予測・シミュレーションなどに提供するとしている。加えて、ドラッグディスカバリー、医用画像処理、ゲノム分析向けの医療ワークフローを加速させるために、ソフトウェア開発キット・ツールを、ソフトウェアライブラリのマイクロサービスとしてアクセスできるようにするとしている。

世界の主要半導体メーカーは、5Gネットワークやエッジコンピューティングなどの領域向けに、ハードウェア対応型セキュリティ機能の開発・実装を進めている。そのような流れに合わせて、国立標準技術研究所（NIST）も、ハードウェア対応型セキュリティにフォーカスしたNISTIR 8320シリーズのドキュメント作成・公開を行っている。参考までに現在、NISTIR 8320シリーズとして、以下のような文書が公表されている。

• 「NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日) (https://csrc.nist.gov/pubs/ir/8320/final)
• 「NIST IR 8320A ハードウェア対応型セキュリティ：コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
  (https://csrc.nist.gov/pubs/ir/8320/a/final)
• 「NIST IR 8320B ハードウェア対応型セキュリティ：信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
  (https://csrc.nist.gov/pubs/ir/8320/b/final)
• 「NIST IR 8320C ハードウェア対応型セキュリティ：マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)
  (https://csrc.nist.gov/pubs/ir/8320/c/ipd)
• 「NIST IR 8320D ハードウェア対応型セキュリティ：ハードウェアベースの秘密計算(初期公開草案)」(2023年2月23日)
  （https://csrc.nist.gov/pubs/ir/8320/d/ipd）

コンテナを利用したアプリケーションの設計・開発・運用を行うエンジニアおよびアプリケーションのユーザーは、ハードウェア側で対処可能なセキュリティ管理策について、確認しておく必要がある。

コンテナ／マイクロサービスセキュリティにおけるNISTとCSAの連携

米国では、NISTがコンテナやマイクロサービスのセキュリティに係る標準規格を策定し、CSAの旧アプリケーションコンテナ／マイクロサービスWG（現DevSecOps WG）がベストプラクティス集を提供するという形で連携してきた。参考までに、NISTは、以下のような文書を公表している。

• 「NIST SP 800-180 NISTマイクロサービス、アプリケーションコンテナ、システム仮想マシンの定義(初期公開草案)」（2016年2月18日）
  （https://csrc.nist.gov/pubs/sp/800/180/ipd）
• 「NIST SP 800-190 アプリケーションコンテナセキュリティガイド」（2017年9月25日）
  （https://csrc.nist.gov/pubs/sp/800/190/final）
  （日本語訳版：https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000085279.pdf）
• 「NIST SP 800-204 マイクロサービスベースのアプリケーションシステム向けセキュリティ戦略」「（2019年8月7日）
  （https://csrc.nist.gov/News/2019/nist-publishes-sp-800-204）
• 「NIST SP 800-240A サービスメッシュアーキテクチャを利用したセキュアなマイクロサービスベース・アプリケーション構築」（2020年5月27日）
  （https://csrc.nist.gov/pubs/sp/800/204/a/final）
• 「NIST SP 800-204B サービスメッシュを利用したマイクロサービスベースのアプリケーション向け属性ベースアクセス制御」（2021年8月6日）
  （https://csrc.nist.gov/pubs/sp/800/204/b/final）
• 「NIST SP 800-204C サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」（2022年3月8日）
  （https://csrc.nist.gov/pubs/sp/800/204/c/final）
• 「NIST SP 800-204D DevSecOps CI/CDパイプラインにおけるソフトウェアサプライチェーン統合のための戦略」（2024年2月12日）
  （https://csrc.nist.gov/pubs/sp/800/204/d/final）

コンテナ／マイクロサービスセキュリティに関連してCSAは、以下のような文書を公表している。

• 「安全なアプリケーションコンテナとマイクロサービスにおける課題」（2019年7月16日）
  （https://cloudsecurityalliance.org/artifacts/challenges-in-securing-application-containers-and-microservices）
• 「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」（2019年7月26日）
  （https://cloudsecurityalliance.org/artifacts/best-practices-for-implementing-a-secure-application-container-architecture）
  （日本語訳版：https://cloudsecurityalliance.org/artifacts/best-practices-for-implementing-a-secure-application-container-architecture-japanese-translation）
• 「安全なマイクロサービスアーキテクチャ実装のためのベストプラクティス」（2020年2月24日）
  （https://cloudsecurityalliance.org/artifacts/best-practices-in-implementing-a-secure-microservices-architecture）
  （日本語訳版：https://cloudsecurityalliance.org/artifacts/best-practices-in-implementing-a-secure-microservices-architecture-japanese-translation）
• 「マイクロサービスアーキテクチャパターン」（2021年8月31日）
  （https://cloudsecurityalliance.org/artifacts/microservices-architecture-pattern）

なお現時点で、NISTは、サーバーレスコンピューティングのセキュリティに関連した文書を策定・公表していない。CSAでは、サーバーレスWGが、下記のような文書を公表している。

• 「サーバレスアプリケーションの12の最も重大なリスク2019」（2019年2月11日）
  （https://cloudsecurityalliance.org/artifacts/the-12-most-critical-risks-for-serverless-applications）
  （日本語訳版：https://cloudsecurityalliance.org/artifacts/the-12-most-critical-risks-for-serverless-applications-japanese-translation）
• 「安全なサーバーレスアーキテクチャを設計するには 2021年版」（2021年9月14日）
  （https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021）
  （日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/01/How-to-Design-a-Secure-Serverless-Architecture-091321-J.pdf）
• 「サーバーレスアーキテクチャのセキュリティを確保するためのCレベルへのガイダンス」（2022年4月19日）
  （https://cloudsecurityalliance.org/artifacts/c-level-guidance-to-securing-serverless-architectures）
  （日本語訳版：https://cloudsecurityalliance.org/artifacts/c-level-guidance-to-securing-serverless-architectures-japanese-translation）
• 「NIST 800-53 R5のコントロールに基づくFaaSサーバーレスコントロールフレームワーク」（2023年8月30日）
  （https://cloudsecurityalliance.org/artifacts/faas-serverless-control-framework-set-based-on-nist-800-53-r5-controls）
• 「安全なサーバーレスアーキテクチャを設計するには 2023年版」（2023年10月23日）
  （https://cloudsecurityalliance.org/artifacts/how-to-design-a-secure-serverless-architecture）
  （日本語訳版：https://cloudsecurityalliance.org/artifacts/how-to-design-a-secure-serverless-architecture-japanese-translation）

サーバーレス技術を利用したクラウドサービスには、「AWS Lambda」、「Google Cloud Serverless」、「Azure Functions」などがあり、日本国内でも広く利用されているが、現時点で、公的機関によるサーバーレスセキュリティ関連文書は特に公表されていない。

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

前編では、米国食品医薬品局（FDA）が推進するレギュラトリーサイエンスのDevSecOpsを取り上げたが、後編では、クラウドセキュリティアライアンス(CSA)におけるDevSecOpsの取り組みを紹介する。

再帰的セキュリティの視点に立ったDevSecOpsの重要6領域

CSA DevSecOps WGは、2019年8月1日、「再帰的セキュリティを通じた情報セキュリティ管理」を公開した（https://cloudsecurityalliance.org/artifacts/information-security-management-through-reflexive-security ）。その中で、「再帰的セキュリティ」について、組織のセキュリティのスタンスおよび配布物を保護するために必要な、セキュリティ、開発、運用の間の相互関係に基づいた、新たなセキュリティ管理手法と定義している。

その上で、DevOpsについて、集団的コラボレーションのような開発のベストプラクティスをインフラストラクチャの運用に適用させるプラクティスであり、特にクラウド環境における開発・運用チームの効率性にポジティブなインパクトを示してきたとしている。その採用を強化するためには、情報セキュリティ自体へのインパクトを考慮し、情報セキュリティ管理領域へのプラクティスの適用に目を向ける必要があるとしている。

その直後の2019年8月7日、CSA DevSecOps WGは、「DevSecOpsの6つの柱：セキュリティ、開発、運⽤の統合による再帰的セキュリティの実現」を公開している（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-of-devsecops）（日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/11/The-Six-Pillars-of-DevSecOps-Achieving-Reflexive-Security-Through-en_us-ja.pdf）

この文書では、ソフトウェアの開発と公開における複雑さを軽減し、既知の信頼できるコンポーネントとサービスのみを使⽤するようにし、開発⼿法に直接統合されたセキュリティリソース（⾃動化されたものと⼈の⼿によるものの両⽅）をソフトウェア開発チームに提供し、セキュリティが⼗分に確保され、監視された開発環境を使⽤し、最終的に、設計どおりに、設計された機能のみを備えた最終製品を提供することを目標としている。

DevOpsは、集団的コラボレーションなどの開発のベストプラクティスをインフラストラクチャ運⽤に適⽤するプラクティスであり、特にクラウド環境において、今⽇の開発および運⽤チームの効率にプラスな影響を与えることが⽰されている。CSA DevSecOps WGは、ISO/IEC 27000 ファミリー規格および前述の「再帰的セキュリティを通じた情報セキュリティ管理」を参照しながら、以下の通り、DevSecOps を実装し組織に統合するために不可⽋な、DevSecOps の6つの重点分野を定義している。

[第1の柱：集団的責任]

DevOpsにセキュリティを組み込む際の大きな課題の1つが、ソフトウェアセキュリティに関する組織のマインドセットや、アイデア、習慣、行動の変更である。セキュリティのDevOps組織への導入により、セキュリティは、他の誰かの責任としてみなすことができなくなっている。それは、誰か他の業務が完了した時のみに取組むべき補足事項と考えるべきでない。加えて、セキュリティは、ビジネス目標から切り離し、区別して見ることができない。最後に、セキュリティは、いくらか一時的なもので、進化や貢献が評価できない。

組織のセキュリティのスタンスに関して、誰もが責任を有する。CSO（クラウドセキュリティオフィサー）は、組織内の情報セキュリティに関して、リーダーおよび羊飼いの役割を果たすが、個々人は、自身のセキュリティ責任を有しており、組織のセキュリティのスタンスに対する自身の貢献を認識しなければならない。エッジのユーザーや開発者は、単に”セキュリティの認識がある”のではなく、防御の第一線にいる。これが再帰的セキュリティフレームワークの「集団的責任」に対応している。

[第2の柱：コラボレーションと統合]

開発、運⽤、セキュリティの各分野において、ソフトウェア業界には膨⼤なスキル（知識）と⼈材（リソース）のギャップが存在する。セキュリティの導⼊に関して組織全体が協⼒しなければ、成功は限られたものになる。セキュリティは、対⽴ではなく協⼒によってのみ達成できる。すべての機能チームのメンバーが潜在的な異常を報告できるようにするためには、セキュリティを意識した協⼒的な⽂化が必要です。⼈的要因はしばしば最も弱いリンクであり、実際に、セキュリティインシデントのほとんどは、単純なヒューマンエラーによって引き起こされることを覚える必要がある。これが「再帰的セキュリティ」のフレームワークの「協⼒と統合する」に対応している。

[第3の柱：実践的な実装]

DevSecOpsでは、ポイントソリューションが数多く提供されている。組織は、ソフトウェアライフサイクルの中でアプリケーションセキュリティを実装するために、さまざまなツールやソリューションを選択できる。ソフトウェアライフサイクルは、構造、プロセス、全体的な成熟度においてそれぞれ異なるため、DevSecOpsを実装するための万能なツールは存在しない。
組織はしばしば、導⼊が難しく、運⽤が困難で、結局は真のセキュリティリスクの軽減に役⽴つ、実⽤的な洞察を提供しないツールやポイントソリューションの調達に終始する。

組織は、ソフトウェアのライフサイクル、組織⾃⾝のセキュリティのニーズ、そして求める将来の状態を総合的に捉え、⾼度な統合性を提供するプラットフォームソリューションを選択する必要がある。デジタル社会における安全、プライバシー、および信頼を確保するために、アプリケーション開発に焦点を当てたフレームワークにとらわれない「デジタルセキュリティとプライバシーモデル」を使⽤することで、組織はDevOpsにおけるセキュリティに実⽤的な⽅法でアプローチできる。このモデルは、すべての利害関係者（開発、運⽤、セキュリティ）を、セキュリティが、アプリケーションとアプリケーションを⽣み出すソフトウェアライフサイクルに組み込まれる形で組み込まれるという、現状では満た
されていないニーズを満たすものである。これが、「再帰的セキュリティ」の枠組みにおける「実践的な実装」に対応している。

[第4の柱：コンプライアンスと開発の橋渡し]

リスクに関連した要求事項を、時間の経過に従って容易に評価できるセキュリティ要求事項に変換することは難しい。セキュリティチームがリスクベースの⼿法をサポートするために要件を作成するとしても、コンプライアンス要件はDevOpsや製品要件にうまく変換されていない。逆に、技術的なコントロールが実装されていても、セキュリティ要件が満たされているという証拠を得ることは容易でない。

ソフトウェア開発のパラダイムとプラクティスの急速な進化を考えると、コンプライアンスとアジャイルソフトウェア開発はもはや同じ⽴場に置くことができない。規制・コンプライアンス部⾨は、その各プロセスの実⾏を実際に監査することよりも、プロセスが存在することを証明することに関⼼がある。⼀⽅で、ほとんどのDevOpsチームは、証明はコードの中にあり、プロセスの⽂書化の中にはないと考えている。

コンプライアンスと開発の間のこのギャップに対処する鍵は、適⽤可能なコントロールを特定し、それを適切なソフトウェア対策に変換し、ソフトウェアライフサイクル内の変曲点を特定し、そこでこれらのコントロールを⾃動化して測定することにより、リスク軽減の質を向上させ、その結果、コンプライアンスを改善することである。これが、「再帰的セキュリティ」の枠組みにおける「整列と橋渡し」に対応する。

[第5の柱：⾃動化]

最⼩限のコストで迅速にセキュアな配備を実現するためのソフトウェア開発⼿法を妨げている課題のいくつかは、⼿作業による⾏き当たりばったりのコーディング、テスト、デプロイ、およびパッチの適⽤である。

⾃動化された品質チェックがなければ、⼿作業によるコーディングは容易に、⼿直しが必要なパフォーマンスの低い、セキュアでないソフトウェアになる。さらに、⼿作業やタイミングの悪いテストでは、デプロイ前に脆弱性が特定される可能性を低くする。⼿作業によるデプロイとパッチの適⽤は、セキュアでないソフトウェアを本番環境にリリースする可能性がある。

⾃動化されたセキュリティ対策は、⼿作業によるプロセスを減らし、効率を⾼め、⼿戻りを減らすことができるため、プロセス効率の中核となる。ソフトウェアの品質は、テスト／フィードバックの徹底性、適時性、および頻度を改善することによって向上できる。⾃動化できるプロセスは⾃動化し、⾃動化できないプロセスは可能な限り⾃動化するか、廃⽌を検討すべきである。⾃動化されたセキュリティチェックは、ビルドの遅延や失敗といった新たな課題を引き起こす可能性があるが、これらは通常、ワークフローの改善や半⾃動化アプローチで対処できる。ソフトウェア開発には、「同じことを3回やったら、そろそろプログラミングの時期だ」という格⾔があり、これは、再帰的セキュリティに正⾯から当てはまる。これが、再帰的セキュリティの枠組みにおける「⾃動化」に対応する。

[第6の柱：測定、監視、報告および⾏動]

「測定できない（あるいは測定しない）ものは管理できない」という格⾔は、DevSecOpsの実装と保守によく当てはまる。⼀般的なDevSecOpsイニシアチブは、スコープと複雑さにもよるが、実装に数ヶ⽉から数年を要する。実⾏可能なメトリクスがなければ、進捗を評価することはできず、失敗をタイムリーに発⾒することもできない。

DevSecOps環境で監視すべき最も重要なメトリクスには、デプロイメントの頻度、脆弱性パッチの適⽤時間、⾃動的にテストされるコードの割合、アプリケーションごとの⾃動テストがある。DevSecOpsを成功させるためには、ソフトウェア開発中だけでなく、デリバリー後の結果も、適切な⼈々によって適切なタイミングで（継続的に）測定、監視、報告、および対処される必要がある。これが、再帰的セキュリティのフレームワークの枠組みにおける「測定と改善」に対応する。

その後、CSA DevSecOps WGは、以下の通り、個々の6領域に関する成果物を公開している。

・「DevSecOpsの6つの柱：集団的責任」（2020年2月21日公開）
（原版：https://cloudsecurityalliance.org/artifacts/devsecops-collective-responsibility）
・「DevSecOpsの6つの柱：コラボレーションと統合」（2024年2月20日公開）
（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-collaboration-integration）
・「DevSecOpsの6つの柱：実践的な実装」（2022年12月14日公開）
（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-pragmatic-implementation）
・「DevSecOpsの6つの柱：コンプライアンスと開発の橋渡し」（2022年2月8日公開）
（原版：https://cloudsecurityalliance.org/artifacts/devsecops-pillar-4-bridging-compliance-and-development）
・「DevSecOpsの6つの柱：⾃動化」(2020年7月6日公開)
（原版：https://cloudsecurityalliance.org/artifacts/devsecops-automation）
（日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/04/DevSecOps-Automatio-ja.pdf）
・「DevSecOpsの6つの柱：測定、監視、報告および⾏動」
（原版：https://cloudsecurityalliance.org/artifacts/the-six-pillars-of-devsecops-measure-monitor-report-and-action）

アプリケーションセキュリティを起点とするOWASP DevSecOpsガイドライン

他方、医療機器サイバーセキュリティやIoTセキュリティの領域において、CSAと連携してきたOWASPは、アプリケーションセキュリティの観点から、「OWASP DevSecOpsガイドライン」を作成・公表している（https://owasp.org/www-project-devsecops-guideline/）。

このガイドラインは、セキュアなパイプラインを実装し、ベストプラクティスを利用して、このような方法で利用可能なツールを導入する方法について説明している。また、このプロジェクトは、開発プロセスにおけるシフトレフトのセキュリティ文化の促進を支援するものである。重要な目標は、”できるだけ早くセキュリティ課題（バイ・デザインやアプリケーション脆弱性）を検知する”ことである。

そして、DevSecOpsの目的・意図は。必要な安全性を犠牲にすることなく、最大のコンテキストレベルを保持する人々に対して、スピードと拡張性のあるセキュリティの意思決定を安全に提供するという目標を持った”誰もがセキュリティに責任がある”というマインドセットの上に構築されている。

このガイドラインは、以下のような構成になっている。

• 0 – イントロダクション
  • 0-a – 概要
  • 0-b – 脅威モデリング
• 1 – コミット前
  • 1-a – 秘密管理
  • 1-b – コードの検査（Linting）
• 2 – 脆弱性スキャン
  • 2-a – 静的（Static）アプリケーションテスト
  • 2-b – 動的（Dynamic）アプリケーションテスト
  • 2-c – インタラクティブな（Interactive）アプリケーションテスト
  • 2-d – ソフトウェア構成分析
  • 2-e – インフラストラクチャ脆弱性スキャン
  • 2-f – コンテナ脆弱性スキャン
  • 2-g – プライバシー
• 3 – コンプライアンス監査

OWASPでは、基礎的パイプラインにおいて、以下のようなステップで実装することを考えている。

• 潜在的な資格情報の漏えいを見つけるためのgitスキャン
• SAST（静的アプリケーションセキュリティテスト）
• SCA（ソフトウェア構成分析）
• IAST（インタラクティブなアプリケーションセキュリティテスト）
• DAST（動的アプリケーションセキュリティテスト）
• IaCスキャンニング（構成ミスを見つけるためのTerraform,、HelmChartコードのスキャン）
• インフラストラクチャスキャンニング
• コンプライアンスチェック

サプライチェーンセキュリティの視点に立った米国NISTの取り組み

さらに、ソフトウェアのサプライチェーンセキュリティの視点から、DevSecOpsの標準化に取り組んでいるのが、米国立標準技術研究所（NIST）である。NIST傘下の国家サイバーセキュリティセンター・オブ・エクセレンス（NCCoE）は、2022年11月9日、「ソフトウェアサプライチェーンとDevOpsセキュリティプラクティス：DevSecOpsに対するリスクベースのアプローチ」を公開している（https://www.nist.gov/news-events/news/2022/11/software-supply-chain-and-devops-security-practices-implementing-risk-based）。

この文書は、国家サイバーセキュリティセンター・オブ・エクセレンス（NCCoE）のプロジェクトについて記述したものであり、DevSecOpsプラクティス向けに適用されたリスクベースのアプローチや推奨事項の開発および文書化に焦点を当てている。このプロジェクトでは、「DevSecOps」について、セキュリティチームが構築したセキュリティプラクティスを、既存のパイプライン（例．継続的統合／継続的デリバリー[CI/CD]）や、開発者が利用し、運用チームが管理する既存のツールチェーンに統合することとしている。NISTのアプローチは、セキュアソフトウェア開発フレームワーク（SSDF）やNISTサイバーセキュリティフレームワークで利用したものと同じである。本プロジェクトは、クラウドネイティブな方法におけるソフトウェアデリバリーの速度や容量を維持し、自動化ツールの利点を活かすことを実現するのに役立てるものだとしている。また、本プロジェクトは、NIST SSDFからのプラクティスやタスクを、DevSecOpsアプローチの一部として実装できる方法を決定するものだとしている。

NISTのこの文書は、以下のような構成になっている。

• 1 エグゼクティブサマリー
  • 目的
  • スコープ
  • 想定／課題
  • 背景
• 2 シナリオ
  • シナリオ 1：フリー／オープンソースソフトウェア（FOSS）開発
  • シナリオ 2：クローズドソース・ソフトウェア開発
• 3 ハイレベルアーキテクチャ
  • コンポーネントリスク
  • 望ましいソフトウェアのケーパビリティ
• 4 関連する標準規格およびガイダンス
  • セキュリティコントロールマップ
  • 附表A 参考文献
  • 附表B 頭字語と略語

なお、CSAと連携しているMITREや国防総省なども、DevSecOpsに関する文書やガイダンス類を作成しており、参考になる。

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

クラウドセキュリティアライアンス(CSA)では、アプリケーションコンテナ／マイクロサービスWGがDevSecOps WGに合流し、最新のクラウドネイティブ環境とDevSecOpsを前提としたソフトウェア開発ライクサイクル(SDLC)におけるベストプラクティスの集積に取り組んでいる。医療／ライフサイエンス領域では、米国食品医薬品局(FDA)が、トータル製品ライフサイクル(TPLC)やDevSecOpsを基盤とするデジタルトランスフォーメーション(DX)施策を展開しており、その影響が医療機器・医薬品の開発・運用を行う企業や医療機関にも及んできた。

トータル製品ライフサイクルを起点とする米国FDAの安全性対策

米国FDA傘下の医療機器・放射線保健センター(CDRH)は、2018年4月16日に公表した「医療機器安全性行動計画:患者の保護と公衆衛生の促進」(https://www.fda.gov/about-fda/cdrh-reports/medical-device-safety-action-plan-protecting-patients-promoting-public-health)の中で、市販前および市販後の専門性、データ、知識や、医療機器の開発・評価・マーケティングの各ステージにおけるすべてのツールを幅広く活用することにより、トータル製品ライフサイクル(TPLC)全体で、消費者や患者、介護者、医療機関が、予防、診断、治療に関する十分な情報を集めて意思決定するために、必要な情報にアクセスできることを保証しなければならないとしている。

またFDAは、「医療機器向けトータル製品ライフサイクル」(https://www.fda.gov/about-fda/cdrh-transparency/total-product-life-cycle-medical-devices)の中で、以下のようなトータル製品ライフサイクル(TPLC)アプローチのメリットを挙げている。

• CDRHのスタッフに、コミュニケーションを介した機器開発からのホリスティックな視点を提供し、機器の市販前および市販後の意思決定を導くのに役立てる
• 医療機器の市販前および市販後のレビュー活動における透明性や一貫性を促進して、機器製造業者に対する予測可能で明確な見通しを提供する
• 市販前および市販後の活動を1つのチームに組み合わせて、FDAが迅速な方法で安全上の課題に対応するのに役立てる
• 機器のライフサイクルを通じて、機器の安全性やパフォーマンスに関する透明性を保証し、CDRHが優れた内部向けおよび外部向けの顧客サービスを提供することを可能にする
• 市販前データからの知識を活用することによって、市販後およびコンプライアンスの意思決定を知らしめる
• 市販前データやコンプライアンス活動からの知識を活用することによって、よりよい情報に基づく市販前医師決定を行うのに役立てる

このような背景から、FDAは、医療機器に関する市販前データと市販後データを統合したトータル製品ライフサイクル(TPLC)データベースを構築し、オープンデータとして公開している(https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm)。TPLCデータベースには、以下のようなデータベースが収載されており、通常、月次で更新されている。

• 市販前承認(PMA)
• 人道的使用医療機器免除(HDE)
• De Novo 分類申請
• 市販前通知[510(k)]
• 有害事象(医療機器不具合情報データベース(MAUDE)
• 医療機器リコール

トータル製品ライフサイクル(TPLC)を活用した医療機器開発促進プログラム

他方、FDAは、トータル製品ライフサイクル(TPLC)アプローチを活用したイノベーション推進活動にも積極的に取り組んでいる。たとえばFDA傘下のCDRHは、2023年10月2日、トータル製品ライフサイクル諮問プログラム(TAP)パイロットおよび参加医療機器について公表した(https://www.fda.gov/medical-devices/how-study-and-market-your-device/total-product-life-cycle-advisory-program-tap)。TAPパイロットは、2023～2027会計年度医療機器ユーザー料金改定(MDUFA V)再認可の一部として、FDAと産業界が合意したコミットメントの1つであり、2023会計年度内に初期フェーズを開始する予定である。

TAPパイロットでは、公衆衛生上、安全で有効な、高品質の医療機器に対して、より迅速な開発とより迅速で幅広い患者のアクセスを奨励するのに役立てることを、長期的なビジョンとしている。FDAは、TAPパイロットを通じて、公衆衛生上必要な革新的医療機器向けに、以下のような戦略的エンゲージメントを提供するとしている。

• より迅速な市販前の相互作用のために提供することによって、参加者とFDAとの間のエクスペリエンスを向上させる
• 機器開発およびレビュープロセスを通して、FDAスタッフを含む全参加者のエクスペリエンスを強化する
• 早期段階における機器開発リスクの特定、評価、低減など、機器開発中の戦略的意思決定の向上を促進する
• 機器開発の早期段階より、FDAのレビューチーム、参加者、FDA以外のステークホルダー(例. 患者、医療機関、保険者)の間の定期的な、ソリューションに焦点を当てたエンゲージメントを促進する
• エビデンスの生成に関するよりよい期待の一致、申請品質の向上、市販前レビュープロセスの有効性の向上のために協働する

FDAは、2023会計年度中に心血管系機器室(OHT2)向けの参加受付を開始し、2024会計年度には、神経系・理学療法系機器室(OHT5)向けの参加受付を開始した。2024年4月12日現在、TAPパイロットには、総数43件の医療機器が参加を表明している。FDAは、その後2027会計年度まで、TAPパイロットの対象機器領域を拡大していく予定である。

参考までに、医療機器だけでなく医薬品においても、FDAは、トータル製品ライフサイクルを前提とする安全性対策を講じている。たとえば、FDA傘下の医薬品評価研究センター(CDER)と生物製品評価研究センター(CBER)は、2021年5月11日、「Q12 医薬品ライフサイクルマネジメントにおける技術上・規制上の考慮事項 – 産業界向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/q12-technical-and-regulatory-considerations-pharmaceutical-product-lifecycle-management-guidance)を公表している。

”DevOps”から”DevSecOps”へと進化する米国FDAのDX

FDAは、トータル製品ライフサイクル(TPLC)に基づく安全性対策と並行して、ITモダナイゼーションへの取組を推進してきた。たとえば、2019年9月18日に公表した「技術モダナイゼーション行動計画(TMAP）」(https://www.fda.gov/about-fda/reports/fdas-technology-modernization-action-plan)の中で、FDAの公衆衛生ミッションを進歩させるために、コンピュータハードウェア、ソフトウェア、データ、分析など、技術利用のモダナイゼーションに向けた短期的実行計画を示した。この計画は、以下の3要素から構成される。

• FDAの技術インフラストラクチャのモダナイゼーション
• 規制のミッションを支援する技術製品を開発するFDAの機能の強化
• システムを越えた相互運用性を有し、消費者と患者に価値を提供する技術的進歩をけん引するための、ステークホルダーとのコミュニケーションと協働

特に「FDAの技術インフラストラクチャのモダナイゼーション」は、堅牢なインフラストラクチャ、クラウド最前線の計画、明確で効率的な外部データインタフェース、サイバーセキュリティへのフォーカスなど、技術モダナイゼーション計画の最優先課題となっており、以下のような具体的アクションを掲げている。

• クラウド戦略
• ビジネス特有のニーズ向けに簡素化されたソフトウェア開発機能（DevOps）
• アプリケーションプログラミングインタフェース（API）、標準規格およびその他の交換メカニズムやツール
• データのクリーンナップとクラウド環境への移植
• as a serviceモデルの継続的採用
• サイバーセキュリティ・エクセレンスへの継続的な専念
• 科学計算のエンタープライズIT計画への統合
• エンタープライズレベルの技術組織である情報管理技術室（OIMT）内およびFDA全体にわたる組織的アラインメント
• オペレーショナル・エクセレンスと複数年に渡る技術計画
• 費用抑制と重複排除
• エンタープライズITガバナンス
• 適切な場合、レガシーシステムおよびソフトウェアアプリケーションの廃止

さらにFDAは、技術ユースケースの構築に向けて、最新技術ソリューションを生成するための技術”製品”開発ケーパビリティを構築し、情報に基づいて規制上の意思決定を行うために、新たなソリューションを効率的に評価・分類できるようにするとしている。特に、FDAが開発した技術製品は、短中期的なFDA技術ロードマップに必要なケーパビリティを証明し、実現するとともに、以下のような製品開発マインドセットを組込むとしている。

• 異なるFDAプログラム領域に採用される可能性があるような、重要なビジネスおよびデータの要求事項に取組み、重複を削減することによって、製品に焦点を当てる
• テスト向けの”最小限の実行可能な製品”の開発
• ”DevOps”のマインドセットとプラクティスの採用”
• 速く失敗する”反復と展開に対する意欲
• FDA環境向けの”プロダクトマーケットフィット”に焦点を当てる;
• 協働的な文化
• ユーザーエクスペリエンス、満足度、採択の向上;
• 短中期的に可能性があるものを紹介する機会

こうして、FDAの技術モダナイゼーション計画を担う製品開発マインドセットとして、”DevOps”の概念が組み込まれた。

さらに、米国大統領行政府が20021年5月12日に発出した「国家サイバーセキュリティに関する大統領令」(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)を受けて、2022年3月20日、FDA傘下のデジタルトランスフォーメーション室（ODT）が公表した「モダナイゼーション・イン・アクション2022」(https://www.fda.gov/news-events/fda-voices/fdas-technology-and-data-modernization-action-2022)では、前述の「技術モダナイゼーション行動計画(TMAP)」の最優先項目として「アジャイルと製品の文化」が示された。

その中で、ゼロトラストモデルや、セキュアなクラウドコンピューティング、多要素認証、暗号化、脅威検知、脆弱性管理およびその他のディフェンス機能の導入を支える標準規格・ベストプラクティスの1つとして明記されたのが、”DevSec”とセキュリティを統合した”DevSecOps” (Development, Security and Operations)である。

このようにFDAが、トータル製品ライフサイクル(TPLC)やDevSecOps、ゼロトラストモデルなどを前提とするデジタルトランスフォーメーション(DX)施策を加速させていくと、デジタル化された当局とのコミュニケーションを日常的に行う医療機器企業や、市販後対策において患者・家族との接点となる医療機関も対応せざるを得ない。

SBOMにおけるトータル製品ライフサイクル(TPLC)とDevSecOpsの融合

ここまで、米国FDAにおけるトータル製品ライフサイクル(TPLC)およびDevSecOpsの展開動向について触れてきたが、両者が融合するツールとして注目されるのが、ソフトウェア部品表(SBOM)である。

たとえば、国際医療機器規制当局フォーラム(IMDRF)が2023年4月13日に公表した「医療機器のサイバーセキュリティのためのソフトウェア部品表の原則及び実践」(https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity)では、「1. イントロダクション」の中で、SBOMが、市販前および市販後活動の双方（例. トータル製品ライフサイクル(TPLC)）におけるサイバーセキュリティリスクマネジメントを改善するために活用できるリソースだとしている。

また、「SBOM コンポーネントの種類およびツール」の「サードパーティのソフトウェアライブラリー」において、より進んだ手順の例として、既存の開発プラットフォームとDevOp環境の活用を挙げている。特に、自動化ツール／プラグインを、1つまたは複数フェーズの開発パイプライン(DevSecOps)に組み込むことが可能だとしている。また、同じ「SBOM コンポーネントの種類およびツール」の「ファームウェア、組込みソフトウェア、PLC」において、製品ライフサイクル管理ソフトウェアやERPソフトウェアを通してBOMを管理する場合、エクスポート機能を使ってソフトウェアコンポーネントを抽出することが可能である点を指摘している。

なお、クラウドセキュリティアライアンス(CSA)のDevSecOps WGでは、企業組織がDevSecOpsを導入する際に重要な領域として、以下の6つを挙げている。

1. ：集団的責任
2. ：トレーニングおよびプロセスインテグレーション
3. ：実用的な実装
4. ：コンプライアンスと開発の間の架け橋
5. ：自動化
6. ：測定、監視、報告、および行動

これらの概要については、後編で概説する。

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

後編では、クラウドネイティブ技術を支えるハードウェアセキュリティモジュール(HSM)／鍵管理やハードウェア対応型セキュリティに関連したガイダンス類の概要について紹介する。

クラウドネイティブ技術の実装を推進する米国FDA

2023年9月13日、米国食品医薬品局(FDA)は、「2024～2027会計年度FDA情報技術戦略」(https://www.fda.gov/about-fda/office-digital-transformation/fda-information-technology-strategy-fy-2024-fy-2027)を公表し、以下の6つの戦略目標を掲げた。

1. コラボレーションの強化
2. インフラストラクチャの強化
3. サービスの現代化
4. データの共有
5. AIとイノベーションの採用
6. 人材とリーダーシップの育成

このうち「2. インフラストラクチャの強化」では、以下の4つの目標を掲げている。

1. 柔軟なインフラストラクチャのオファリング提供
2. クラウド採用の加速
3. サービスの可用性の保証
4. ゼロトラストアプローチの実装

このような医薬品・医療機器行政DXの進展とともに、医療・ライフサイエンス分野でも、ゼロトラスト環境を前提としたアプリケーションコンテナやマイクロサービス、サーバーレス、DevSecOpsに代表されるようなクラウドネイティブ技術の実装が本格化している。セキュリティの領域においても、ソフトウェア主導型の新たなサービスが次々と開発・導入されている。

その一方で、ハードウェアセキュリティモジュール(HSM）やセキュアチップに代表されるような、半導体を軸とするハードウェア対応型セキュリティ技術の開発・導入も進んでいる。特に医療現場の場合、ユーザーインタフェースや業務フローに影響を及ぼす可能性があるアプリケーションソフトウェア層よりも、プラットホームハードウェア層でセキュリティ機能の実装や運用・保守を行った方がメリットのある場合も多い。

米国NISTが推進するハードウェア対応型セキュリティの標準化

このような状況下で、米国立標準技術研究所(NIST)は、クラウドネイティブ技術に係るNIST SP 800-204シリーズと並行して、ハードウェア対応型セキュリティにフォーカスしたNISTIR 8320シリーズのドキュメント作成・公開を行ってきた。。

現在、NISTIR 8320シリーズとして、以下のような文書が公表されている。

• NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日)
• 「NIST IR 8320A ハードウェア対応型セキュリティ：コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
• 「NIST IR 8320B ハードウェア対応型セキュリティ：信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
• 「NIST IR 8320C ハードウェア対応型セキュリティ：マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)

以下では、NIST IR 8320シリーズの各ドキュメントの概要について説明する。

「NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日)
(https://csrc.nist.gov/pubs/ir/8320/final)

今日のクラウドデータセンターやエッジコンピューティングにおいて、攻撃対象領域はシフトしており、場合によっては、非常に拡大している。それと同時に、ハッキングが業態化しており、大抵のセキュリティ制御の実装が理路整然としていないか、首尾一貫していない。あらゆるデータセンターやエッジコンピューティングのセキュリティ戦略の基盤は、データやワークロードが実装され、アクセスされるプラットフォームをセキュア化すべきである。物理的プラットフォームは、あらゆる階層型セキュリティアプローチにおける第一の層を表しており、ハイレベルの層のセキュリティ制御が信頼できることを保証するのに役立つような最初の保護を提供する。この文書では、クラウドデータセンターやエッジコンピューティング向けのプラットフォームセキュリティやデータ保護を改善できるようなハードウェア対応型セキュリティの技術や手法を説明している。

NIST IR 8320は、以下のような構成になっており、附属書において、インテル、AMD、Arm、シスコ、IBMの具体的な技術を例示している。

1. 序論
2. ハードウェアプラットフォームセキュリティの概要
3. プラットフォームの完全性の検証
3.1 ハードウェアセキュリティモジュール(HSM)
3.2 チェーン・オブ・トラスト
3.3 サプライチェーン保護
4. ソフトウェアのランタイム保護メカニズム
4.1 リターン指向プログラミング(ROP)とコール／ジャンプ指向プログラミング(COP／JOP)に対する攻撃
4.2 アドレス変換攻撃
4.3 メモリ安全性違反
4.4 サイドチャネル攻撃
5. データ保護と秘密計算
5.1 メモリの分離
5.2 アプリケーションの分離
5.3 VMの分離
5.4 暗号化アクセラレーション
6. 遠隔証明サービス
6.1 プラットフォーム証明
6.2 遠隔高信頼性実行環境(TEE)証明
7. ハードウェア対応型セキュリティを活用したクラウドユースケースのシナリオ
7.1 セキュリティアーキテクチャに対する可視性
7.2 高信頼性プラットフォーム上のワークロード配置
7.3 資産のタグ付けと高信頼性ロケーション
7.4　ワークロードの機密性
7.5　鍵と秘密の保護
8. 次のステップ
参考文献
附属書A – ベンダーに依存しない技術の例
A.1 プラットフォームの完全性の証明
A.1.1 UEFIセキュアブート(SB)
A.2 キーライム
附属書B – インテルの技術の例
B.1 プラットフォームの完全性の証明
B.1.1 チェーン・オブ・トラスト(CoT)
B.1.2 サプライチェーン保護
B.2 ソフトウェアのランタイム保護メカニズム
B.2.1 リターン指向プログラミング(ROP)とコール／ジャンプ指向プログラミング(COP／JOP)に対する攻撃
B.2.2 アドレス変換攻撃
B.3 データ保護と秘密計算
B.3.1 メモリの分離
B.3.2 アプリケーションの分離
B.3.3 VMの分離
B.3.4 暗号化アクセラレーション
B.3.5 技術事例の概要
B.4 遠隔証明サービス
B.4.1 Intel Security Libraries for the Data Center (ISecL-DC)
B.4.2 技術の概要
附属書C – AMDの技術の例
C.1 プラットフォームの完全性の証明
C.1.1 AMD Platform Secure Boot (AMD PSB)
C.2 データ保護と秘密計算
C.2.1 メモリの分離
C.2.2 VMの分離
附属書D – Armの技術の例
D.1 プラットフォームの完全性の証明
D.1.1 Arm TrustZone Trusted Execution Environment (TEE) for Armv8-A
D.1.2 Arm Secure Bootとチェーン・オブ・トラスト(CoT) D.1.3 Platform Security Architecture (PSA) Functional APIs
D.1.4 Platform AbstRaction for SECurity (Parsec)
D.2 ソフトウェアのランタイム保護メカニズム
D.2.1 リターン指向プログラミング(ROP)とコール／ジャンプ指向プログラミング(COP／JOP)に対する攻撃
D.2.2 メモリ安全性違反
D.2.3 サイドチャネル攻撃に対するArmの低減策
D.3 データ保護と秘密計算
D.3.1 Armの秘密計算アーキテクチャ(CCA)
D.3.2 Armの暗号化アクセラレーション
附属書E – シスコの技術の例
E.1 プラットフォームの完全性の証明
E.1.1 シスコプラットフォームのルート・オブ・トラスト
E.1.2 シスコのチェーン・オブ・トラスト(CoT)
E.2 シスコのサプライチェーン保護
E.3 シスコのソフトウェアランタイム保護
E.4 シスコのデータ保護と秘密計算
E.5 シスコの暗号化アクセラレーション
E.6 シスコのセキュリティインフラストラクチャに対する可視性
E.7 シスコの信頼されたプラットフォームへのワークロードの配置
附属書F – IBMの技術の例
F.1 プラットフォームの完全性の証明
F.1.1 ハードウェアセキュリティモジュール(HSM)
F.1.2 IBMのチェーン・オブ・トラスト(CoT)
F.2 ソフトウェアランタイム保護メカニズム
F.2.1 IBMのROPとCOP／JOPに対する攻撃への防御
F.3 データ保護と秘密計算
F.3.1 IBMのメモリ分離技術
F.3.2 IBMのアプリケーション分離技術
F.3.3 IBMのVM分離技術
F.3.4 IBMの暗号化アクセラレーション技術
F.4 遠隔証明サービス
F.4.1 IBMのプラットフォーム証明ツール
F.4.2 IBMの継続的ランタイム証明
附属書G – 頭字語と略語
附属書H – 用語集

「NIST IR 8320A ハードウェア対応型セキュリティ：コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
(https://csrc.nist.gov/pubs/ir/8320/a/final)

本文書では、マルチテナント型クラウド環境におけるコンテナデプロイメントを保護するためのハードウェア対応セキュリティの技術や手法に基づくアプローチを説明している。その中で、IaaS（Infrastructure as a Service）クラウドコンピューティング技術や、リソースアセットのタグ付けフォームにおける位置情報など、セキュリティの課題を説明した上で、これらの課題に取組むために設計された概念実証の実装(プロトタイプ)を説明している。

NIST IR 8320Aは、以下のような構成になっており、附属書において、インテル、AMI、Kubernetesの具体的な技術を例示している。また、NIST SP800-53改定第5版やNISTサイバーセキュリティフレームワーク第1.1版とのマッピングについても言及しており、これらを介してCSA STAR／CCMとの紐づけも可能になっている。

1. 序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2. プロトタイプの実装
2.1 目的
2.2. 目標
2.2.1 ステージ0：プラットフォームの証明と評価されたワーカーノードの設定
2.2.2 ステージ1：信頼されたワークロードの配置
2.2.3 ステージ2：アセットのタグ付と信頼された位置情報
3. プロトタイピングのステージ0
3.1 ソリューション概要
3.2 ソリューションアーキテクチャ
4. プロトタイピングのステージ1
4.1 ソリューション概要
4.2 ソリューションアーキテクチャ
5. プロトタイピングのステージ2
5.1 ソリューション概要
参考文献
附属書A – ハードウェアのアーキテクチャと前提条件
A.1 ハイレベルの実装アーキテクチャ
A.2 Intel Trusted Execution Technology (Intel TXT)とTrusted Platform Module (TPM)
A.3 証明
附属書B – プラットフォームの実装：AMI TruE
B.1 ソリューションアーキテクチャ
B.2 ハードウェアの記述
B.3 AMI TruEのインストールと構成
B.3.1 AMI TruE Trust Managerのインストール
B.3.2 AMI TruE Attestation Serverのインストール
B.3.3 AMI True向けファイアウォールの構成
B.3.4 デバイスアクセス鍵の構成
B.3.5 Discovery RangeとManageability Rangeの構成
B.4 信頼されたクラウドクラスターのインストールと構成
B.4.1 TruEエージェントの遠隔プロビジョニング
B.4.2 TruEエージェントの手動プロビジョニング
B.5 AMI TruEの利用
B.5.1 AMI TruEを利用した信頼状況のモニタリング
B.5.2 信頼性レポートの生成
B.5.3 AMI TruEを利用したプラットフォームのタグ付け
B.5.4 信頼性イベントアラート通知の受領
B.5.5 救済策のためのAMI TruE利用
附属書C – プラットフォームの実装：Kubernetes
C.1 プロトタイプのアーキテクチャ
C.2 ハードウェアの記述
C.3 Kubernetesのインストールと構成
C.3.1 Kubernetes Controller Nodeの構成
C.3.2 Kubernetes Worker Nodeの構成
C.3.3 Kubernetesのオーケストレーション
附属書D – NIST SP 800-53のセキュリティ制御
附属書E – サイバーセキュリティフレームワークのサブカテゴリーのマッピング
附属書F – 頭字語およびその他の略語

「NIST IR 8320B ハードウェア対応型セキュリティ：信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
(https://csrc.nist.gov/pubs/ir/8320/b/final)

本文書では、マルチテナント型クラウド環境におけるコンテナデプロイメントを保護するためのハードウェア対応セキュリティの技術や手法に基づくアプローチを説明している。また、一般的なセキュリティコミュニティ向けの青写真やテンプレートとなることを意図したアプローチのプロトタイプ実装について説明している。

NISTIR 8320Bは、以下のような構成になっており、附属書において、インテル、OpenShift、TSIの具体的な技術を例示している。また、NISTIR8320Aと同様に、NIST SP800-53改定第5版やNISTサイバーセキュリティフレームワーク第1.1版とのマッピングについても言及している。

1.序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2.プロトタイプの実装
2.1 目的
2.2 目標
2.2.1 ステージ0：プラットフォームの証明と測定されたワーカーロードの設定
2.2.2 ステージ1：信頼されたワークロードの配置
2.2.3 ステージ2：アセットのタグ付と信頼された位置情報
2.2.4 ステージ3：信頼に基づくワークロードの暗号化
2.2.5 ステージ4：信頼に基づくワークロードの情報へのアクセス
2.3 追加的リソース
3. プロトタイピングのステージ0
4. プロトタイピングのステージ1
5. プロトタイピングのステージ2
6. プロトタイピングのステージ3
6.1 ソリューション概要
6.2 ソリューションアーキテクチャ
7. プロトタイピングのステージ4
7.1 ソリューション概要
7.2 ソリューションアーキテクチャ
参考文献
附属書A – ハードウェア・ルート・オブ・トラストの実装
A.1 ハイレベルの実装アーキテクチャ
A.2 ハードウェア・ルート・オブ・トラスト：Intel TXTとTrusted Platform Module (TPM)
A.3 証明：Intel Security Libraries (ISecL)
附属書B – ワークロードオーケストレーションの実装：OpenShift
B.1 プロトタイプのアーキテクチャ
B.2 OpenShiftのインストールと構成
B.2.1 VMwareベースの管理クラスター(クラスターA)
B.2.2 KVMベースのマネージドクラスター(クラスターB)
B.2.3 MCM Pak 1.3(MCM HUB – VMware)のインストール
附属書C – ワークロード暗号化の実装
C.1 プロトタイプのアーキテクチャ
C.2 ワークロード暗号化の構成
附属書D – Trusted Service Identity(TSI)
D.1 TSIの概要
D.2 TSIのインストールと構成
附属書E – NIST SP 800-53 セキュリティ制御および発行文書のサポート
附属書F – サイバーセキュリティフレームワークのサブカテゴリーのマッピング
附属書G – 頭字語およびその他の略語

「NIST IR 8320C ハードウェア対応型セキュリティ：マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)
(https://csrc.nist.gov/pubs/ir/8320/c/ipd)

組織は、容量が拡大するマシンアイデンティティを導入しており、一組織当たり数千または数百万の数に至る場合もよくある。秘密暗号鍵のようなマシンアイデンティティは、個々のマシンにどのポリシーを強制する必要があるかを特定するために利用できる。マシンアイデンティティの中央集中型管理は、デバイスやワークロード、環境を越えたポリシー実装の簡素化に役立つ。しかしながら、利用する機微データ向けの保護策の欠如(例.メモリにおけるマシンアイデンティティ)により、リスクに晒される。本文書では、ライフサイクルを通じたマシンアイデンティティの生成、管理、保護に関するセキュリティ課題を克服するための効果的なアプローチを提示している。そして、このような課題に取り組む概念実証(PoC)の実装、プロトタイプについて記述している。本文書は、一般的なセキュリティコミュニティが、記述された実装を検証し、有効活用するために利用できるような青写真やテンプレートとなることを意図している。

NIST IR 8320C初期公開草案の構成は以下のようになっており、附属書において、Vanafi、インテルの具体的な技術を例示している。

1. 序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2. マシンアイデンティティを保護する際の課題
3. ステージ0：エンタープライズ向けマシンアイデンティティ管理
3.1 ソリューション概要
3.2 ソリューションアーキテクチャ
4. ステージ1：ハードウェアベースの秘密計算による秘密鍵利用時の保護
4.1 ソリューション概要
4.2 ソリューションアーキテクチャ
5. ステージ2：マシンアイデンティティ管理とエンドツーエンドの保護
5.1 ソリューション概要
5.2 ソリューションアーキテクチャ
附属書A – ハードウェアアーキテクチャ
附属書B – Vanafiのマシンアイデンティティ管理の実装
附属書C – インテルの利用時秘密鍵保護の実装
附属書D – マシンアイデンティティ・ランタイム保護と秘密計算との統合
D.1 ソリューション概要
D.2 ソリューションアーキテクチャ
D.3 インストールと構成
附属書E – 頭字語およびその他の略語

ここまで、NISTのハードウェア対応型セキュリティに関連した文書を紹介してきたが、業種・業界別にみると、決済系に代表される金融業界で、具体的な技術の開発・導入に関するユースケースが多く提供されており、オンプレミス環境とクラウド環境を組み合わせたハイブリッド環境におけるセキュリティ管理策の最適化に向けたソリューション開発が加速している。さらにマシンアイデンティティ管理をみると、情報技術(IT)と制御技術(OT)の融合に係るアイデンティティ管理の効率化・自動化を想定していることが伝わってくる。

元々、クローズドな境界防御を前提として情報システムが構築・運用されていた医療・ライフサイエンス業界の場合、ゼロトラストアーキテクチャやアプリケーションコンテナに代表されるクラウドネイティブ技術の導入も、ハイブリッド環境下が中心とならざるを得ない。医療機器のIoMT(Internet of Medical Things)やバイオ製造のデジタルツインを支えるセキュリティ管理策についても、ソフトウェア、ハードウェアの両面から最適化を図る必要があるだろう。

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

近年、金融決済領域を中心に普及し、医療IoT(IoMT: Internet of Medical Things)などの医療・ライフサイエンスの領域でも関心が高まっている技術に、ハードウェアセキュリティモジュール(HSM)に代表されるハードウェア対応型セキュリティ(Hardware-enabled Security)がある。クラウドセキュリティアライアンス(CSA)では、「クラウドネイティブな鍵管理サービス採用のための推奨事項」（2021年9月14日発行）(https://cloudsecurityalliance.org/artifacts/recommendations-for-adopting-a-cloud-native-key-management-service)、「鍵管理ライフサイクルのベストプラクティス」(2023年12月19日発行)( https://cloudsecurityalliance.org/artifacts/key-management-lifecycle-best-practices)、「HSM-as-a-Serviceのユースケース、考慮事項、ベストプラクティス」(2024年発行予定)など、クラウド鍵管理の観点から研究が進んでいる。 ここでは、クラウドネイティブ技術を支えるハードウェアセキュリティモジュール(HSM)や鍵管理の現状、米国立標準技術研究所(NIST)におけるハードウェア対応型セキュリティの標準化動向について概説する。

金融業界を中心に普及してきたハードウェアセキュリティモジュール(HSM)

CSAでは、ハードウェアセキュリティモジュール(HSM)について、暗号化のオペレーションを実行し、鍵を保護するために、認証された信頼されるプラットフォームと定義している。それは、改ざんに対応し、侵入を防止するデバイスであり、セキュリティ暗号化アクセラレータ、ハードウェアベースの乱数発生器、プロセッサー、RAM、ストレージ、外部インタフェース(例. ネットワーク／シリアルポート)から成る。HSMは、HSMにより生成・生産された暗号鍵として、組織インフラストラクチャのセキュリティを支えるために利用されるような信頼の起点(Root of Trust)と考えられる。通常、HSMは、強力なユーザ認証と職務分離を実装する。

HSMのタイプとしては、ユースケースに従って、一般目的のHSMと決済目的のHSMの2種類がある。双方を比較すると、以下のようになる。

[一般目的のHSM]

• 暗号化アルゴリズム: 汎用的、対称／非対称暗号化
• 管理上の柔軟性: とても柔軟
• セキュリティ機能: 汎用的
• 適用可能な標準規格: ETSI TS 419 series、CEN EN 419 221、PCI DSS & 3DS、FISMA、FedRAMP、FICAM
• ユースケース: 汎用的な暗号化署名、暗号化／復号化、TLSオフロード

[決済目的のHSM]

• 暗号化アルゴリズム: 領域固有、対称暗号化
• 管理上の柔軟性: いくらか柔軟
• セキュリティ機能: 強化型
• 適用可能な標準規格: PCI P2PE、PCI 3DS、PCI SPoC、PCI CPoC、PCI PIN
• ユースケース: カードPINライフサイクル、カードと暗号の妥当性評価、決済資格情報の発行、鍵管理向けオペレーションのポイントツーポイント暗号化(P2PE)、EMV取引処理

医療・ライフサイエンス領域は、一般目的のHSMに含まれ、標準化された暗号化アルゴリズムや業界標準のAPIをサポートする形で技術の導入が進んでいる。

加えて、HSMには、セキュアエンクレーブ(安全な飛び地)のような派生製品のケースがあり、領域固有のアルゴリズムやビジネスロジックが、セキュアで制御されたランタイム環境上に展開されることを要求する仕組みになっている。

成長するクラウド型のHSM-as-a-Service

他方、ハードウェアセキュリティモジュール・アズ・ア・サービス(HSM-as-a-Service)は、API、Web、ローカルインタフェースを介して、ハードウェアセキュリティモジュール(HSM)へのアクセスを提供するような、クラウドベースのサービスモデル／ソリューションである。HSM-as-a-Serviceは成長市場であり、多くの組織が、鍵管理や暗号化のニーズ向けにクラウドベースのソリューションを採用している。現在、HSM-as-a-Serviceソリューションは、SaaSデリバリーモデルに参入したクラウドサービスプロバイダ(CSP)およびHSMベンダーの双方が提供している。

HSM-as-a-Serviceの採用に影響を及ぼす要因として、以下のような点が挙げられる。

• クラウドベースのセキュリティソリューションに対する需要の拡大:
  組織の多くがアプリケーションやデータをクラウドに移行し、新たなアプリケーションがクラウドネイティブ環境に構築されるにつれて、低レイテンシーや統合のオプションなど、オンプレミス型ソリューションと同等レベルのセキュリティを提供できるようなクラウドベースのセキュリティソリューションに対する需要が拡大している。
• コンプライアンス要求事項:
  多くの業界、特に銀行・金融サービス・保険(BFSI)セクターや、デジタルガバメント、デジタルトラストサービス・セクターでは、国レベルの標準規格や規制により強制された、厳格なコンプライアンス／プライバシー要求事項を抱えており、機微データの保護、暗号鍵の制御、デバイスのバリデーション水準に関する特別な要求事項が見込まれる。このようなコンプライアンス要求事項は、どのHSM-as-a-Serviceのサブセットが有効活用できるかに影響を及ぼす。
• CAPEX(資本的支出)の削減:
  HSMは、通常、高額な投資と考えられている。同等のクラウドサービスは、このようなサービスの採用のために適切な計画と設計を設定する限り、実際のサービス消費量に応じた支払いを可能にすることによって、費用の削減を提供できる。
• OPEX(事業運営費)の削減:
  HSMデバイスは、その運用維持のために、熟練したエンジニアを必要とする。HSM-as-a-Serviceの提供は、維持や日々の運用をCSPやHSMベンダーに移管して、組織が業務費用を削減し、その他のタスクにリソースを再配分することを可能にする。

ハードウェアとソフトウェアが融合するHSMの技術アーキテクチャ

HSMは、機微データや暗号鍵を保護するために設計された専用デバイスであり、、セキュアな暗号化の運用を実行する。HSMは、専用の物理的デバイスまたは仮想アプライアンスとして運用することができ、暗号鍵の生成、保存、管理のために、多層型のセキュリティアプローチを導入して、物理的・デジタル的両面の脅威からの保護を保証する。HSMの論理的アーキテクチャは、セキュアな鍵ストレージ、暗号化アルゴリズム、改ざん対応モジュールなど、様々なセキュリティの階層から成る。これらのモジュールは、改ざんに対応するよう設計されることが多く、その中に保存された機微情報に対して、不正な主体がアクセスすることが極めて困難になっている。この中には、セキュアブートプロセス、暗号化ストレージ、鍵生成・保存専用ハードウェアなどの機能が含まれることが多い。

HSMには、リアルタイム改ざん検知メカニズムのような先進的セキュリティ機能が装備されており、物理的な侵害の試みに対する保護対策(例. 物理的に侵入が検知されたら鍵を消去する)の引き金となる。さらに、HSMは、アクセス制御、保存データの暗号化、セキュアな鍵のバックアップ・復旧に関するサポートなど、包括的なセキュリティ機能を提供する。このような特性により、金融取引、デジタル署名、セキュアな通信など、様々なアプリケーションの暗号化資産の機密性、完全性、可用性を保証する際、HSMは重要なコンポーネントとなる。

そして、HSM共通のフォームファクターとして、以下のようなものが挙げられる。

• トラステッドプラットフォームモジュール(TPM)または組み込み型HSM
• ローカルPCI Express(PCIe)カード
• ネットワークHSM
• スマートカード(統合型チップカード)
• USB備え付けデバイス

HSM-as-a-Serviceの場合、PCIeカードやネットワークHSMなど、特定のフォームファクターに複数のインスタンスを集約させることによって、サービスを構築することが可能である。

前述の一般目的であれ決済目的であれ、フォームファクターに関係なく、ハードウェア実装の観点から、以下のようなHSM共通の技術要素が挙げられる。

• 暗号化プロセッサー:
  暗号化オペレーションだけを実行する、専用の特別なタイプのマイクロプロセッサ。通常は、対称暗号化機能、非対称暗号化機能、ハッシュ機能、乱数発生など、固有のタイプの暗号化オペレーションを担う、より小さいプロセッシングユニットに、物理的にセグメントされる。暗号化プロセッサーは、セキュアなI/Oチャネル経由でアクセス可能であり、サーキットレベルで物理的対策により保護され、追加的なレベルの改ざん対策を提供する。
• 永続性メモリ:
  生成またはインポートされた鍵を保存するためにセキュアなスペース。永続性メモリスペースは、スロットと呼ばれる論理的パーティションに分割される。個々のスロットは、複数の鍵を保存することができる。スロットへのアクセスは、サーキットレベルでセキュア化されるだけでなく、強力な認証、アクセスと認可制御により保護される。
• I/Oモジュール:
  HSMとその他のシステムの間の通信を確立する役割を担う。フォームファクターに依存して、I/Oモジュールには、USB、PCI、UART、CPIOなど、標準的なプロトコルに応じて様々なコネクターが含まれる。

このような技術要素に基づいてHSM-as-a-Serviceを開発・提供するベンダー／サービスプロバイダーが参照すべき標準規格として、以下のようなものが挙げられる。

• FIPS(Federal Information Processing Standards)140
  • CAVP（Cryptographic Algorithm Validation Program）
  • CMVP (Cryptographic Module Validation Program)
• Common Criteria (CC) for Information Technology Security Evaluation
  • EAL (Evaluation Assurance Level)
  • PP (Protection Profile)
  • CEN EN 419 221-5
• PCI SSC (Payment Card Industry Security Standards Council) PTS (PIN Transaction Security) HSM Specification
• ISO/IEC 27001:2022
• ISO/IEC 27017:2015
• CSA STAR (Cloud Security Alliance Security Trust Assurance and Risk Framework)
• AICPA SOC (American Institute of Certified Public Accountants System and Organization Controls)
  • SOC 1: ICFR (Internal Control over Financial Reporting)
  • SOC 2: Trust Services Criteria
  • SOC 3: Trust Services Criteria for General Use

HSMの物理的・論理的セキュリティ制御と顧客の関係

上記のような標準規格をベースとして、HSM-as-a-Serviceベンダー／サービスプロバイダーに対しては、物理的セキュリティおよび論理的セキュリティの両側面から、制御策を講じることが望まれる。

HSMの物理的セキュリティ制御においては、コンスタントに、モニタリングされ、検証可能なHSMへのアクセス制御を提供することを目標としている。ベンダー／サービスプロバイダーが提供すべき物理的セキュリティ制御の基本的要素として、以下のようなものが挙げられる。

• セキュアな境界、侵入検知、論理的アクセス制御ポリシーの強制、ビジター管理、装置のingress/egressモニタリング、アクセス制御システムの保護、要員によるモニタリング、アクセス認可の強制、すべてのアクセスのログ付け。
• 出荷、試験、オペレーションの間など、HSMライフサイクルの置換と修正の制御
• HSMのアクセス、置換、修正保護におけるデュアル制御の強制など、HSMオペレーションのアクセス制御
• HSMの状態、顧客へのアロケーション、鍵のバックアップを管理するシステムに関するアクセス制御
• 遠隔管理とセキュアな鍵のバックアップに関するアクセス制御、デバイスやスマートカード向けのセキュアなストレージ、遠隔管理活動向けの施設や安全な空間、遠隔のHSMへのアクセスと鍵のバックアップ
• オペレーションや管理に関するコネクションなど、HSMに接続するネットワークの保護
• アクセス制御とビデオシステム向けのセキュアな領域、システムの可用性と完全性のモニタリングなど、アクセス制御システムの保護

なお、HSM-as-a-Serviceベンダー／サービスプロバイダーが顧客の遠隔管理デバイス利用向けに提供する場合、顧客が物理的セキュリティ上の責任を有する可能性がある。その場合、顧客は、サービス利用とストレージに関する物理的制御に責任を負うことになるので、注意が必要である。

他方、HSMの論理的セキュリティ制御においては、ベンダー／サービスプロバイダーが、顧客データの分離、従業員の顧客リソースへのアクセスの制御、最小特権アクセス、最小権限(need-to-know)アクセス、アクセスの認可とレビュー、スタッフのトレーニングなど、ISO 27001やPCI DSSなどで記述された要求事項を遵守することが前提となる。その上で、デバイスや鍵の管理で必要となるHSM固有の論理的セキュリティ制御策として、以下のようなものが挙げられる。

• 個々のHSMについて、製造からサービスにおける有効化、オペレーション、廃止・破壊に至るまでのチェーン・オブ・カストディ(CoC)の維持
• 顧客が利用可能になる前の段階におけるHSMの論理的・暗号的検証
• ライフサイクルを通してHSMに物理的なアクセスを行うすべてのスタッフに対するデュアル制御のためのプロセス、トレーニング、認可、規則
• HSM固有の物理的制御を実装するための電子アクセス制御・動画など、物理的アクセス制御に関する構成、アクセス管理、モニタリング
• 鍵管理プロセスの確立、維持、記録、モニタリング
• 鍵の管理者やカストディアンに関する認可、アクセス管理、モニタリング
• リソース管理、顧客の鍵のバックアップと復旧など、HSM管理プロセス自動化の確立、認可、管理、モニタリング
• HSM管理コネクション向けTLS認証管理など、HSMに対するネットワークアクセス制御
• HSM管理アプリケーションまたはコンソール以外のHSMへのアクセスに関するアクセス制御
• HSMサービス管理とHSMへのアクセスに関するクラウドサービスプロバイダのアイデンティティ／アクセスの構成
• クラウドサービスプロバイダのネットワークアクセスの構成
• セキュアな遠隔管理デバイスの利用

医療・ライフサイエンス領域においても、ゼロトラストアーキテクチャの導入に向けた動きが始まっており、その環境で稼働する医療IoT関連機器・サービスにも、マイクロサービスやサーバーレスアーキテクチャに代表されるクラウドネイティブ技術やDevSecOpsの波が押し寄せつつある。そのような状況に、5Gから6Gへのネットワークの進化が加わってくると、ハードウェアとソフトウェアの両面からのセキュリティ管理策実現により、さらなるイノベーションが期待される。

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