ゼロ トラストのための DevOps プラットフォーム環境のセキュリティ保護

この記事は、DevOps チーム メンバーが最小特権のゼロ トラスト原則を実装し、DevOps プラットフォーム環境のセキュリティを保護するのに役立ちます。 本記事は私たちのeBookエンタープライズ DevOps 環境のセキュリティを保護するのコンテンツを引用しており、中でもシークレットと証明書の管理のベスト プラクティスに焦点をあてています。

現代の企業は、開発者が生産性を考慮する必要があるパイプラインや本番環境を含め、必要な環境の展開において DevOps プラットフォームに依存しています。 従来のアプリケーション セキュリティ手法は、今日のパイプラインや本番環境が攻撃者に対してさらすことになるアタックサーフェスの増加については考慮されていませんでした。 ハッカーが攻撃標的をシフトしてより上流のツールを標的しつつある現代では、DevOps プラットフォーム環境をセキュリティで保護するための革新的なアプローチが必要です。

次の図では、DevOps プラットフォーム環境がアプリケーション環境に接続され、さらに継続的統合および継続的デリバリー (CI/CD) パイプライン拡張機能につながっていることに注目してください。

CICD パイプライン拡張機能は、攻撃者にとってはアプリケーション環境からの特権エスカレーションにエンゲージメントするチャンスになり得ます。 拡張機能と統合により、アタックサーフェス脆弱性が増加するのです。 そのため、マルウェア侵入の脅威に対する防御策を講じることが重要です。

攻撃者がパイプラインを標的にする方法と理由

パイプラインや本番環境は、標準のアプリケーションセキュリティプラクティスやプロセスに依存しない場合があります。 通常高レベルのアクセス認証情報を必要としますが、これらはいったん攻撃者の手に渡ればシステムに深く侵入するためのアクセスの足掛かりとなってしまします。

攻撃者はシステムを侵害する新しい方法を開拓し続けてますが、パイプラインに対する最も一般的な攻撃ベクトルは次のとおりです。

• ランタイム変数と引数挿入の抽出。
• パイプラインからサービス プリンシパルまたは認証情報を取得するスクリプト。
• キーを持った者ならだれでも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 アクションを無効化または制限するを参照ください。

次のステップ

• 開発環境のセキュリティ保護は、最小特権、ブランチ セキュリティ、信頼ツール、拡張機能、統合に関するベスト プラクティスに基づいて、開発環境にゼロ トラスト原則を実装する方法を説明します。
• 開発者ワークフローにゼロ トラストセキュリティを埋め込むは、開発者が迅速かつ安全にイノベーションを推進するためのヒントを提供します。
• ゼロ トラストのための DevOps 環境のセキュリティ保護は、ゼロ トラスト原則に基づいてDevOps 環境のセキュリティを確保することにより、ハッカーが開発者ボックスに侵入したり、リリース パイプラインを有害なスクリプトに感染させたり、テスト環境を介して本番環境データにアクセスすることを防ぐためのベスト プラクティスを説明します。
• Microsoft Entra ID を一元化された ID 管理システムとして運用することで、覚書 22-09 (米国行政命令 14028「国家のサイバーセキュリティの向上」に準拠) に記載されるゼロ トラスト原則を実装します。
• クラウド エクスペリエンスに対する最も高速で最も安全なコードを開発者に提供するツールにより、Azure DevOps を使用してコードを高速化し、セキュリティで保護します。