コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (後編)

コメントをどうぞ

クラウドセキュリティアライアンス(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 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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA

*