ゼロ トラスト用の DevOps プラットフォーム環境をセキュリティで保護する
この記事は、DevOps チーム メンバーとして、最小限の特権 ゼロ トラスト原則を実装し、DevOps プラットフォーム環境をセキュリティで保護するのに役立ちます。 本記事は私たちのeBookエンタープライズ DevOps 環境のセキュリティを保護するのコンテンツを引用しており、中でもシークレットと証明書の管理のベスト プラクティスに焦点をあてています。
現代の企業は、開発者が生産性を考慮する必要があるパイプラインや本番環境を含め、必要な環境の展開において DevOps プラットフォームに依存しています。 従来のアプリケーション セキュリティ手法は、今日のパイプラインや本番環境が攻撃者に対してさらすことになるアタックサーフェスの増加については考慮されていませんでした。 ハッカーが攻撃標的をシフトしてより上流のツールを標的しつつある現代では、DevOps プラットフォーム環境をセキュリティで保護するための革新的なアプローチが必要です。
次の図では、DevOps プラットフォーム環境がアプリケーション環境と、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの拡張機能に接続しています。
CI/CD パイプライン拡張機能は、ハッカーにアプリケーション環境からの特権エスカレーションに関与する機会を提供します。 拡張機能と統合により、アタックサーフェス脆弱性が増加するのです。 そのため、マルウェア侵入の脅威に対する防御策を講じることが重要です。
攻撃者がパイプラインを標的にする方法と理由
パイプラインと運用環境は、標準のアプリケーションセキュリティ プラクティスとプロセスに依存しない場合があります。 通常高レベルのアクセス認証情報を必要としますが、これらはいったん攻撃者の手に渡ればシステムに深く侵入するためのアクセスの足掛かりとなってしまします。
攻撃者はシステムを侵害する新しい方法を開拓し続けてますが、パイプラインに対する最も一般的な攻撃ベクトルは次のとおりです。
- ランタイム変数と引数挿入の抽出。
- パイプラインからサービス プリンシパルまたは認証情報を取得するスクリプト。
- キーを持った者ならだれでもDevOps プラットフォーム環境にアクセスできてしまう、不正な構成のパーソナル アクセス トークン。
- コードへのアクセスを必要とする統合ツールの脆弱性と構成の誤り (多くの場合、読み取り専用ですが、書き込みアクセスの場合があります)。 統合ツールには、テスト フレームワーク、静的アプリケーション セキュリティ テスト (SAST)、動的アプリケーション セキュリティ テスト (DAST) が含まれる場合があります。
シークレットと証明書の管理のベスト プラクティス
致命的な侵害を回避する対策実施は、効果的なシークレット管理と同じくらいシンプルに行うことができます。 次の図は、有効なシークレット、パスワード、アクセス トークン、および証明書管理の例を示しています。
上の図に示すように、開発者は顧客要求のビルドを開始します。 GitHub は、Vault アプリケーション ロールのロール ID とシークレット ID を持つランナーを開始します。 信頼されたエンティティは、Vaultに対して新しいシークレット ID を定期的に要求し、GitHub から GitHub シークレット ID を取得します。 Vaultは、GitHub シークレットのロール ID とシークレット ID を使用してサインインし、コード署名アセットを取得します。 ランナーは、モバイル アプリをカスタマイズしてコード署名します。
次のベスト プラクティスは、シークレットとパラメーターの公開を最小限に抑える安全なセットアップを構築するのに役立ちます。
- アプリケーションライフサイクルの各段階で、シークレットと証明書を格納する安全なストレージを提供すること。 常にオープンソース プロジェクトであるかのような前提で開発してください。 チームメンバー全員に、コード内やチーム環境ではなくキーVault内にシークレットを格納させてください。 Azure Key Vault は、シークレットの安全な保管とアクセスを保証するクラウド サービスです。
- GitHub の OIDC をフェデレーション ID として信頼するように Azure を構成します。 OpenID Connect (OIDC) を使用すると、GitHub Action ワークフローから Azure 内のリソースにアクセスできます。このとき、Azure 認証情報を有効期間が長い GitHub シークレットとして格納する必要はありません。
DevOps 環境のセキュリティ保護のためのその他のベスト プラクティス
セキュリティ インシデントに対する防御を支援するには、DevOps プラットフォーム環境を強化するための次のベスト プラクティスを確認してください。 これらの推奨事項の詳細については、私たちのeBook エンタープライズ DevOps 環境のセキュリティ保護を参照してください。
- すべての DevOps プラットフォーム環境に監査証跡を備えます。監査ログを確認して、アクセス権を取得したユーザー、発生した変更、アクティブなシステムの日付/時刻を追跡します。 運用環境に流れ込む CI/CD パイプラインを備えた DevOps プラットフォームを具体的に含めること。 DevOps ツールの監査証跡を使用すると、潜在的な侵害や脆弱性に対する疑わしいアクティビティに対する脅威の迅速な修復、検出、アラートを行い、潜在的なデータや特権の悪用を見つけるための堅牢な方法が提供されます。 すべての環境にきめ細かなコントロールと監査証跡を整備すること。
- ソフトウェア サプライ チェーンのセキュリティ保護も確実に行ってください。 コードベースに取り込むすべてのライブラリで、ソフトウェアサプライチェーンを拡張し、各オープンソースプロジェクトまたはツールから依存関係を継承します。 不要なライブラリとオープンソース コンポーネントを慎重に削除して、ソフトウェア サプライ チェーンに存在するアタックサーフェスの縮小に努めてください。
- 「コードとしてのインフラストラクチャ 」(IaC) テンプレート スキャンを自動化すること。 IaC 環境では、不適切な構成、コンプライアンス監査、ポリシーの問題を簡単にスキャンできます。 コンプライアンスチェックとアクセス制御の実装により、インフラストラクチャ全体のセキュリティ体制を強化できます。 自動化システム要件を満たすツール統合のセキュリティを確認します。
- 承認ワークフローを自動化すること。 コードを本番環境にプッシュする承認ワークフローの場合、所定の自動または手動のチェックにより、各要求のセキュリティ、ビジネス価値、ステータス、品質を確認する必要があります。 これらのチェックは開発と本番環境間のゲートとして機能し、フラグ付けやアラートをトリガーすることなく、サービス拒否攻撃の発生やハッカーによる本番環境へのコード注入を防ぐことができます。
- 検証済みの DevOps ツール統合のみを許可すること。 開発者環境と同様に、DevOps ツールには拡張機能と統合が付属しており、DevOps チームの作業効率とセキュリティを保証してくれます。 検証済みの統合が、作業の実行に必要な最小限の特権のみを必要とするよう取り計らうこと。 可能な限り最小限の特権アクセスのみを実装し、適切なレベルの読み取り/書き込みアクセス許可を確保します。 詳しくは組織に対する GitHub アクションを無効化または制限するを参照ください。
次のステップ
- 開発者環境をセキュリティで保護することは、最小限の特権、ブランチ セキュリティ、および信頼ツール、拡張機能、統合のベスト プラクティスを使用して、開発環境にゼロ トラスト原則を実装するのに役立ちます。
- ゼロ トラスト セキュリティを開発者ワークフローに埋め込むことで、迅速かつ安全にイノベーションを行うのに役立ちます。
- ゼロ トラスト用の Secure DevOps 環境 では、ハッカーが開発者ボックスを侵害するのを防ぎ、リリース パイプラインを悪意のあるスクリプトに感染させ、テスト環境を介して運用データにアクセスすることを防ぐためのゼロ トラスト アプローチで DevOps 環境をセキュリティで保護するためのベスト プラクティスについて説明します。
- Microsoft Entra ID を一元化された ID 管理システムとして運用することで、覚書 22-09 (米国行政命令 14028「国家のサイバーセキュリティの向上」に準拠) に記載されるゼロ トラスト原則を実装します。
- クラウド エクスペリエンスに対する最も高速で最も安全なコードを開発者に提供するツールにより、Azure DevOps を使用してコードを高速化し、セキュリティで保護します。