原文・参照先資料
DoD Enterprise DevSecOps Reference Design - DoD CIO
3.3 DevSecOpsの柱
DevSecOpsは、図4に示すように、組織、プロセス、テクノロジ、ガバナンスという4つの柱で支えられている。
各DoD組織において、DevSecOpsの実践は、組織内の上層部によるDevSecOps哲学への理解・賛同から始まる。その結果、組織文化が変化し、プロセスを自動化し、一貫したガバナンスを適用するための新しいコラボレーション・プロセス、テクノロジー、ツールが開発される。プロジェクトを成功させるには、4つのすべての分野で前進する必要があります。
3.3.1 組織
組織は、以下の理念と考えを取り入れ、日常活動やソフトウェアライフサイクルの管理プロセスに組み込む必要があります。
- 全体的な視点を持ち、ソフトウェア開発、セキュリティ、運用の責任を共有するように組織文化を変える。DevSecOpsのコンセプトと新しい技術を使ってスタッフを訓練する。すべてのステークホルダーから徐々に賛同を得る。
- 組織のサイロ化を打破する。ソフトウェアライフサイクルのすべてのフェーズで、チームのコミュニケーションとコラボレーションを強化する。
- コラボレーション・アクションを可能にするには、セキュリティ・アラートや品質保証(QA)レポートなどの実践的なセキュリティおよびQA情報を、ソフトウェアライフサイクルの各フェーズでチームが自動的に利用できるようにする必要がある。ポジティブな事象とネガティブな事象の両方に関する事後報告を組織全体で共有することにより、安全な文化を形成する。チームは、DevSecOpsプラクティスの一環として、システム設計を改善し、実装を強化し、インシデントレスポンス能力を強化するための学習機会として、成功と失敗の両方を利用すべきである。
- 大きな変更を少なく行うのではなく、小さな増分変更を多く行う。小さな変更の範囲は制限されるため、管理が容易になる。
- フィードバックとユーザー主導の変更を受け入れて、新しく出現した予期しない要件に対応する。 蓄積された技術的負債の継続的な削減を保証するために、継続的なコードのリファクタリングのための計画と予算を立てる。
3.3.2 プロセス
ミッションの環境、システムの複雑さ、システムアーキテクチャ、ソフトウェア設計の選択肢、リスク許容度、およびシステムの成熟度に応じて、各プログラムのソフトウェアライフサイクルには独自の管理プロセスがあります。
たとえば、成熟したWebアプリケーションシステムがマイクロサービス設計を採用しているとします。開発環境、プレ本番環境、本番環境は同じクラウド上にあります。試験手順は完全に自動化されています。このシステムには、開発、構築、テスト、セキュリティ、配信の各タスクを自動化するためのプロセス・フローがあり、人手を介さずに更新を迅速に本番環境にプッシュ配信できます。一方、兵器システムのような複雑なミッションクリティカルな組み込みシステムは、完全に自動化できないテストを必要とする異なるプロセスを持つ可能性があります。そのシステムのソフトウェアライフサイクルプロセスは、Webアプリケーションシステムのプロセスとは大きく異なります。
DevSecOpsプロセスをうまく採用するには、複数の反復フェーズで実装する必要があります。簡単に自動化できるいくつかのタスクから始め、徐々にDevSecOps機能を構築し、それに合わせてプロセスを調整します。図5は、この概念を示しています。開発者がコードをコミットした後でのみビルドプロセスを自動化する継続的ビルド・パイプラインでソフトウェアシステムを開始できることを示しています。時間の経過とともに、継続的インテグレーション、継続的デリバリ、継続的デプロイメント、継続的オペレーション、そして最後に継続的モニタリングへと進み、DevSecOpsの完全なクローズドループを達成することができます。プログラムは、適切なプロセスから始めて、そこから徐々に成長していきます。プロセス改善は頻繁に行われ、フィードバックに応答してアプリケーションとプロセス自体の両方を改善します。
図5:Application DevSecOpsプロセス
プロセス設計に「フリーサイズ」ソリューションはありません。ソフトウェアチームごとに固有の要件と制約があります。次に、プロセス設計の指針となるいくつかのベストプラクティスを示します。
1.プロセス設計は、学際的なチームの共同作業である。
2.ほとんどのプロセスは、ツールとテクノロジーによって自動化できる必要がある。
3.DevSecOpsのライフサイクルは反復的なクローズドループである。小さな規模から始めて、継続的な改善のために徐々に構築していく。プロセスの成熟度レベルと自動化に対するチームの信頼レベルに応じて、必要に応じてコントロールゲートに人手の介入プロセスを設定する。より多くの人の介入から始め、可能な限り徐々に減らしていく。
4.AOは、運用機関(ATO)プロセスを可能な限り自動化することを検討すべきです。
組織がDevSecOpsの能力とプロセスを進化させるのを支援するために、DoDはDevSecOps成熟度モデルを開発した。このモデルは、組織がより高いDevSecOps成熟レベルへと段階的に移行するために取ることができる多くのステップを詳述している。この成熟度モデルはDoD DevSecOpsのプレイブック [7] に示されている。
3.3.3 技術
多くのDevSecOpsツールは、ソフトウェアライフサイクルにおける多くのタスクを、人の関与なしに自動化する。コラボレーションツールやコミュニケーションツールなどの他のDevSecOpsツールは、生産性を向上させるために人との対話を促進し、刺激する。DevSecOpsツールの中には、特定のライフサイクルフェーズでの活動を支援することを目的としたものもある。たとえば、開発フェーズ用の統合開発環境(IDE)DevSecOpsプラグインや、ビルドフェーズ用の静的アプリケーション・セキュリティー・テスト（SAST）ツールなどです。ほとんどのツールは、特定のアクティビティのセットを支援します。アーティファクト・リポジトリのアーティファクトにタグを追加すると、同じアーティファクトのセットがパイプラインに沿って一緒に移動することが保証されます。第4章では、さまざまなDevSecOpsツールを紹介する。
DevSecOps環境のインスタンス化は、一度に1つのコンポーネントを手動でセットアップする代わりに、構成ファイルから組み立てることができます。インフラストラクチャー構成ファイル、DevSecOpsツール構成スクリプト、およびアプリケーション実行時構成スクリプトは、Infrastructure as Code(IaC)と呼ばれます。IaCと同じアプローチを採用して、セキュリティ・チームは、セキュリティ・ポリシーを構成コードに直接プログラミングするとともに、コードとしてセキュリティ・コンプライアンス・チェックと監査を実装します。これらのコードは、Security as Code(SaC)と呼ばれます。IaCとSaCはどちらもソフトウェアとして扱われ、設計、開発、バージョン管理、ピアレビュー、静的解析、テストなどの厳格なソフトウェア開発プロセスを経ます。
技術とツールは、ソフトウェアのライフサイクルを短縮し、効率を向上させるために、DevSecOpsの実践において重要な役割を果たしている。これにより、ソフトウェア・ファクトリの一部としてソフトウェア生産の自動化が可能になるだけでなく、オペレーションやセキュリティ・プロセス・オーケストレーションも可能になります。
3.3.4 ガバナンス
ガバナンスは、ミッション・プログラムに関連するリスクをライフサイクル全体にわたって積極的に評価し、管理します。ガバナンスアクティビティはATOの後に停止するのではなく、運用や監視を含むソフトウェアのライフサイクル全体にわたって継続します。DevSecOpsは多くのガバナンス活動を促進し、自動化することができます。
3.3.4.1マネジメント体制
DevSecOpsの管理目標は、より大きな戦略的目標のバランスを取るために、「トップダウン」と「ボトムアップ」の両方でなければならない。研究(例: [8])によると、成功にはシニアリーダーの賛同が不可欠です。しかし、オーナーシップを生み出し、ガバナンスに関連するプロセスの適切な実施を促し、チームメンバーが継続的なプロセス改善をサポートできるようにするためには、スタッフレベルでの賛同も重要です。継続的なプロセスの改善 (可能な限り、いつでも、どこでも、シンプル化と自動化の機会を探すこと) は、急速に変化する世界に対応するためのガバナンスにとって不可欠です。
[9] のようなDoDにおける初期のDevSecOpsの取り組みは、商業的なベストプラクティスを活用し、採用してきた。その文書は、次世代ガバナンスの五つの基本原則(NGG)を示している。
1. ミッション規律でITを運用:要件を組織のミッションに結び付けます。すべての行動は任務に合わせなければならない。そうでない場合は、継続的プロセス改善を用いて評価を行い、活動をミッションに結びつける方法を検討すべきです。
2. 自動化への投資:アクション、ビジネス・プロセス、意思決定、承認、文書化など、可能なすべてを自動化します。設計、インターフェース、機能テスト、セキュリティ・テスト、およびそれらの関連ドキュメントを含む自動化によって、リスクマネジメントフレームワーク(RMF)で必要とされる証拠の本体と、必要に応じた履歴監査を提供する記録の成果物が作成されます。
3. 適応性を受け入れる:いつでも変更が必要になることを受け入れ、それを実現するためのすべてのオプションを利用できます。fail fast、fail small、fail forwardの3つです。開発者がリリースが動作しないことを発見した場合は、転送に失敗します。その後、以前のソフトウェアを使用してサーバを導入前の状態にリストアするのではなく、開発者の変更は、それを修正して新しいリリースで問題に対処できるように、個別に行う必要があります。
4. 透明性の向上:自動化されたプロセス内で発生するアクティビティを表示し、自動生成されたレコードのアーチファクトを表示するために、組織全体にオープン・アクセスを提供します。透明性は、アイデアを共有し、中小企業(SME)で構成されるソリューションを開発するための環境を生み出します。また、「サイロ化」を回避するために、部門横断的なチームの形で企業全体からリードを得ます。代表的なステークホルダー全員で構成されるチームは、ミッション・システムを構築するために必要なスキルと、直面するすべての課題を克服するために必要な集合的な創意工夫を備えている。
5. 固有の責任:職責を最下位レベルにプッシュまたは委任します。
- 戦略:これは、変更管理会議(CCB)または技術検討会議(TRB)に関連しています。それは「大きな変化」構造化されていない決定を含む。これらのまれでリスクの高い決定は、組織の戦略と使命を形作る可能性がある。
- 運用:(様々なスクラム)横断的で、半構造化された意思決定。このような頻繁でリスクの高い意思決定では、さまざまなグループが連携したエンドツーエンドの意思決定プロセスの一環として、一連の小さな相互に関連した意思決定を行います。
- 戦術:(グローバルエンタープライズパートナー(GEP)/プロダクトオーナー/開発者のアクティビティによって)委任され構造化された決定事項。これらの頻繁でリスクの低い決定は、個人または作業チームによって効果的に処理され、他からの入力は制限されます。 これら5つの原則は、 [9] からの図6に要約されている。
図6:次世代ガバナンスの五つの原則
3.3.4.2公認機関
DoD Instruction(DoDI)8510.01[10]は究極のガバナンスポリシーであり、すべてのDoD情報システムおよびプラットフォーム情報テクノロジシステムが従うべきプロセスを示しています。これは改訂中であり、次のDevSecOps関連ガバナンス情報が将来のリリースに組み込まれる予定です。
新しいDevSecOpsソフトウェアファクトリインスタンスと実運用環境の初期セットアップでは、RMFプロセスはエンタープライズレベルのプロセスに従います。評価および承認(A&A)は、基礎となるインフラストラクチャ(例:DoDクラウドの暫定承認)およびDoDエンタープライズ強化コンテナの認定および承認を、再認定することなく継承する必要があります。プログラムには、どのようなサービスが含まれ、どの認証を継承できるかについて、基盤となるインフラストラクチャプロバイダとの正式なサービスレベル契約(SLA)が必要です。これは、適用可能な評価手順の状態に影響し、運用環境およびアプリケーションへの継承の段階を準備します。インスタンスが許可されて動作可能になると、機能用の特殊AOプログラムのエリアまたはローカルAOは、環境の継続認証を認識します。図7は、A&Aの継承を示しています。
機能領域のための特殊AOまたはプログラムのためのローカルAOは、ミッションアプリケーションの連続許可のための認識を持っています。
図7:評価と承認の継承
表2:DevSecOpsにおける承認担当者の役割
| 機能 | 授権官吏 |
|---|---|
| DoDエンタープライズ硬化コンテナ | エンタープライズAO(例:Defense Information Systems Agency(DISA)) |
| DevSecOpsソフトウェアファクトリインスタンス | エンタープライズAO(DISA、軍事部門(ミルデップ)CIOなど) |
| DevSecOpsソフトウェアファクトリインスタンスの継続的プロセス改善/継続的認証 | Special or Local AO(例:Program Executive Officer(PEO)) |
| ミッション用途向けAO | Special or Local AO(例:PEO) |