開発セキュリティ規範を作成または最新化する際に、この記事では、セキュリティを開発プラクティスに統合することで、開発者操作 (DevOps) から開発者セキュリティ運用 (DevSecOps) への移行を可能にし、アプリケーションの配信をセキュリティで保護する方法について説明します。
最新の組織は、イノベーションを提供し、変化するビジネス要件に対応し、競争上の優位性を維持するために、迅速なソフトウェア開発に依存しています。 DevOps は、継続的インテグレーションとデリバリーを通じてこの機敏性を実現します。 ただし、速度の向上により、新しいセキュリティ リスクも発生します。
継続的リリース サイクルにより、設計上の決定と運用環境のデプロイの間の時間が短縮され、次のような弱点が運用環境に導入される可能性が高まります。
- アプリケーション設計の弱点
- 脆弱な依存関係
- 構成エラー
- インフラストラクチャ自動化の欠陥
- 不十分な秘密管理または衛生。
DevOps リスク
最新の DevOps 環境は、開発、パイプライン、運用システム全体で攻撃対象領域を拡大します。 ソース コード リポジトリ、パイプライン、自動化システムなどの DevOps ツールは、攻撃者にとって価値の高いターゲットです。
悪意のあるコードが早期に導入された場合、既存のセキュリティ チェックを通過し、運用システムに到達する可能性があります。
一般的な攻撃目標は次のとおりです。
- ビルド成果物に悪意のあるコードを挿入する。
- 開発者 ID またはサービス アカウントを侵害する。
- 運用データへのアクセスまたは流出。
攻撃者は、多くの場合、カスタム アプリケーションと開発環境をターゲットにして、以下にアクセスします。
- 機密性の高い組織または顧客データ。
- 独自のビジネス ロジックと知的財産。
- 侵害された開発システムによる運用インフラストラクチャ。
- ソフトウェア サプライ チェーンによるダウンストリームのお客様の侵害。
潜在的なセキュリティ リスクを次の図にまとめます。
アプリケーションと開発のリスク
アプリケーションワークロードは、開発中に導入された弱点や、それらを構築してデプロイするために使用されるインフラストラクチャの侵害によって侵害される可能性があります。
| リスク | ターゲット | 潜在的な結果 |
|---|---|---|
| アプリの設計/実装 | 設計または開発中に発生したセキュリティの問題により、次のような攻撃手法にワークロードが公開される可能性があります。 - 入力の検証が正しくありません - セキュリティで保護されていない認証または承認ロジック - 弱い暗号化または不適切に実装された暗号化 - アプリケーション ロジックを使用した機密データの公開 |
これらの弱点により、攻撃者は次のことができるようになります。 - アプリケーション データへのアクセスまたは操作 - 承認されていない操作を実行する - 埋め込まれたロジックの欠陥によって永続的なアクセスを維持します。 |
| 開発インフラストラクチャ/自動化 | 攻撃の対象は次のとおりです。 - ソース コード リポジトリ - パイプラインをビルドする - デプロイの自動化 - コードとしてのインフラストラクチャ (IaC) テンプレート - エンドポイントまたはサービス ID を開発する |
侵害された場合、攻撃者が次のことを実行できる可能性があります: - ビルド成果物に悪意のあるコードを挿入する - デプロイ構成を変更する - 埋め込まれたロジックの欠陥によって永続的なアクセスを維持する - 運用環境で使用される資格情報またはシークレットを取得します。 |
| 開発ソフトウェアサプライ チェーン | アプリケーションは一般的に次に依存します。 - サード パーティ製ライブラリ - オープン ソース パッケージ - コンテナ イメージ - プラットフォーム サービス |
これらの依存関係によって導入された脆弱性または悪意のあるコードは、次の影響を受ける可能性があります。 - 組織の運用ワークロード - 顧客またはパートナーの環境 |
開発プロセスにセキュリティを統合すると、これらのリスクが運用環境のリリースに伝達される可能性が低くなります。
左にシフト
左シフトは、開発ライフサイクルの早い段階でセキュリティを統合するセキュリティ エンジニアリング アプローチです。
プロセスの後半でセキュリティを検証する代わりに、組織はそれを次の内容に埋め込みます。
- 構想
- Design
- 発達
- Operations
これにより、修復コストとリスクにさらされるリスクが削減されます。
このアプローチをサポートするために、組織は
- 問題の修正に多大なコストがかかり、対応も難しくなる後工程ではなく、プロセスの早い段階で Security Development Lifecycle (SDL) のような体系化されたベストプラクティスを活用してください。
- このアプローチを維持するには、ガバナンス、リスク、コンプライアンス (GRC) を開発戦略に統合します。
DevSecOps とは
DevSecOps は、DevOps を拡張し、ソフトウェア開発ライフサイクルのあらゆる段階 (アイデアの開始から設計、開発、運用まで) にセキュリティを埋め込むことで、Shift Left アプローチを実現します。
従来の開発アプローチでは、セキュリティ検証はリリース前の最終品質ゲートとして実行されることが多かった。 これにより、遅延が発生し、修復コストが増加し、脆弱性がライフサイクルの後半まで保持される可能性があります。
DevSecOps は、セキュリティを以前に移行し、開発および運用プロセスに継続的に埋め込みます。
DevSecOps は、開発、運用、およびセキュリティ チーム間の摩擦を軽減し、イノベーションのスピード、信頼性、セキュリティの回復性という共通の目標に沿って調整し、チームが最も重要な問題に早期かつ継続的に対処できるようにします。
DevSecOps は、セキュリティを次の環境に統合します。
- 建築設計
- アプリケーションの実装
- インフラストラクチャの自動化
- デプロイと運用プロセス
Benefits
DevSecOps を使用すると、開発チーム、セキュリティ チーム、運用チームは次のことが可能になります。
- ライフサイクルの早い段階で問題を特定して修復します。
- 運用環境での露出を減らします。
- リスクを管理しながら、配信速度を維持します。
セキュリティは、配信後に適用されるコントロールではなく、ソフトウェアの構築と配信方法の一部になります。
セキュリティで保護されたイノベーションのライフサイクル
イノベーションは、通常、次の 2 つのライフサイクル ステージを経て進行します。
| ステージ | 詳細情報 |
|---|---|
| アイデアインキュベーション | 機能は、最初の運用環境で使用するために設計、実装、および検証されます。 新しいアイデアから始まる |
| 最初のリリース |
最初の生産リリースは、安全な製品使用のための製品の最小基準を満たしています。 - 開発: 機能は最小限のビジネス要件を満たしています。 - セキュリティ: 機能は、運用環境での使用に関する規制コンプライアンス、セキュリティ、および安全性の要件を満たします。 - 操作： 機能は、生産システムである最小の品質、パフォーマンス、およびサポート可能性の要件を満たしています。 |
最初のリリース後、ワークロードが次のように進化すると、開発は反復的になります。
- リスク許容度の変更
- アプリケーションの要件と成熟度
- 規制上の義務
- 脅威の状態
セキュリティを開発に統合する
従来の開発アプローチでは、設計と実装が完了した後のリリース前の最終ゲートとして、ライフサイクルの後半でセキュリティが検証されます。 最新の開発環境では、検証の遅延が増加します。
- 脆弱性の複雑さ
- 修復コスト
- 運用上の遅延と中断
- アクティブな悪用に対するリスクにさらされるリスクの増加
DevSecOps は、開発と運用を通じてセキュリティを継続的に統合し、以前の問題に対処し、リスクを軽減し、一貫性を向上させます。
主なプラクティス
効果的でスケーラブルで持続可能なセキュリティを既存の開発プロセスに埋め込む必要があります。 個別のワークフローまたは並列ワークフローに実装されるのではなく、アプリの設計、ビルド、デプロイ、運用方法に直接統合する必要があります。 以下のことが推奨されます。
- アイデアから開発、デプロイ、進行中の操作まで、エンドツーエンドのワークフローをマッピングします。
- ライフサイクルの各段階でのセキュリティに対する明確な役割、ツール、責任の定義。
- 脆弱性、欠陥、および設計の問題に対して一貫した修復パスを確立する。
ワークロードのリスクに基づいてセキュリティ プラクティスを調整します。 ビジネス クリティカルなアプリケーションでは、より厳しい作業が必要ですが、リスクの低いシナリオは合理化されたアプローチに従うことができます。
少なくとも、次のことを確認します。
- 開発ライフサイクルに関係するステージ、ユーザー、テクノロジを特定します。
- セキュリティ アクティビティを個別のチェックポイントとして扱うのではなく、各ステージに統合する方法を定義します。
- ライフサイクル全体を通じて、主要な変更と定期的な修正の両方を処理するためのプロセスを確立します。
開発とデプロイのセキュリティを自動化する
自動化は、開発と運用全体で一貫して大規模にセキュリティを適用するために不可欠です。
- セキュリティ制御とツールを CI/CD パイプラインに直接統合します。
- 脅威モデリング、コード スキャン、検証、ポリシーの適用などの主要なアクティビティを自動化します。
- コードとしてのインフラストラクチャ (IaC) を使用して、反復可能で安全なデプロイを有効にします。
Azureランディング ゾーンなどのプラットフォーム基盤では、次の方法でこのアプローチをサポートできます。
Azureランディング ゾーンなどのプラットフォーム基盤では、セキュリティ、ガバナンス、DevOps 統合のための標準化されたパターンを提供することで、このアプローチをサポートできます。
予想される結果
DevOps から DevSecOps に移行する組織は、次のことができます。
- 運用環境のワークロードに脆弱性が導入される可能性を減らす
- 開発インフラストラクチャまたは自動化を悪用する攻撃者の能力を制限する
- 進化する攻撃手法に対するアプリケーションの回復性を向上させる
- 規制と組織のコンプライアンス要件をサポートする
- 運用リスクやセキュリティ リスクを高めずにイノベーションの速度を維持する
道のりを進むためのヒント
DevSecOps を採用するには、組織とカルチャの変更が必要です。
教育と文化の変化
これらは重要な初期の手順です。 DevSecOps モデルを理解するには、新しいスキルを開発し、新しい視点を採用する必要があります。
教育と文化の変化には、時間、焦点、エグゼクティブスポンサーシップ、定期的なフォローアップが必要であり、個人が変更の価値を完全に理解して見るのに役立ちます。
文化やスキルを大きく変えると、個人の専門的なアイデンティティを活用し、強い抵抗の可能性を生み出すことがあります。 各個人とその状況の変化の理由、何、方法を理解し、表現することが重要です。
変更には時間がかかります
チームが新しい方法で物事を行うことの影響に適応できる限り速く動くことができます。 チームは、変革を行う間、既存のジョブを実行する必要があります。
最も重要なものを慎重に優先順位付けし、この変更が発生する可能性のある速度に対する期待を管理することが重要です。
最も重要で基盤となる要素から着手する「クロール、ウォーク、ラン」戦略を重視することは、組織にとって有効です。
変更により（一時的な）支障が生じる
すべての新しいテクノロジ、方法論、およびその他の変更により、摩擦と混乱が生じます。 リスクを低減するためには、批判的思考を促す健全な摩擦に注力することが重要である一方、効果やリスク低減が限定的であるにもかかわらずプロセスを遅らせる不健全な摩擦は避けるべきです。
制限付きリソース
組織が早い段階で直面する課題は、セキュリティとアプリケーション開発の両方で才能とスキルを見つけることです。
組織がより効果的に共同作業を開始すると、セキュリティの考え方を持つ開発者や、開発の背景を持つセキュリティプロフェッショナルなど、隠れた才能が見つかる可能性があります。
継続的なシフト
アプリは急速に変化しています。 新しい機能に加えて、アプリケーションの技術的な定義と構成は、クラウド、サーバーレス、AI などのテクノロジの導入によって根本的に変化しています。
この変化により、開発プラクティス、アプリケーションセキュリティが変化し、非開発者がアプリケーションを作成する権限も与えられています。
SRE モデルを検討する
DevSecOps の一部の実装では、運用とセキュリティの責任を サイト信頼性エンジニア (SRE) の 役割に組み合わせます。
このようなモデルは機能しますが、多くの場合、既存のエンタープライズカルチャとプラクティスから極端に変化します。
SRE モデルを検討している場合は、まず、このガイダンスで概説されている実用的な迅速な成果と段階的な進行状況を使用して、DevOps にセキュリティを埋め込み、投資収益率 (ROI) を適切に取得し、即時のニーズを満たすことをお勧めします。
これにより、運用および開発担当者にセキュリティの責任が段階的に追加され、チームは SRE の最終状態に近づけられます。
次のステップ
セキュリティで保護された開発のベスト プラクティスについて説明します。