Azure Kubernetes Service (AKS) の DevSecOps

Azure Boards

Azure DevOps

Azure Monitor

Azure Pipelines

Azure Policy

DevSecOps (Secure DevOps とも呼ばれます) は、従来の DevOps ライフサイクルのさまざまな段階でセキュリティを組み込むことによって、DevOps のプラクティスに基づいています。 DevOps プラクティスでセキュリティを構築する利点には、次のようなものがあります。

• セキュリティ上の脅威を可視化し、脆弱性がデプロイされた環境に到達するのを防ぐことで、アプリケーションとシステムの安全性を高める
• 開発チームと運用チームによるセキュリティ意識の向上
• 自動化されたセキュリティ プロセスをソフトウェア開発ライフサイクルに組み込む
• 開発および設計段階の早い段階でセキュリティの問題を見つけることで、修復コストを削減する

DevSecOps が Azure Kubernetes Service (AKS) に適用されている場合、組織の役割によって、セキュリティを実装するための考慮事項が異なる場合があります。 これらのさまざまな組織の役割の例を次に示します。

• AKS で実行されているセキュリティで保護されたアプリケーションを構築する開発者
• セキュリティで保護された AKS インフラストラクチャを構築するクラウド エンジニア
• クラスターを管理したり、セキュリティの問題を監視したりする可能性のあるさまざまな運用チーム

この記事は、セキュリティコントロールとセキュリティのベスト プラクティスを埋め込むための考慮事項と推奨事項を含む、さまざまな DevOps ライフサイクル ステージに分かれています。 このガイドには、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに組み込む一般的なプロセスとツールが含まれており、使用可能な場合は使いやすい組み込みツールを選択します。

この記事の前提条件として、 DevOps と GitOps を使用して AKS でアプリをビルドしてデプロイする方法を確認することをお勧めします。

プロセス フロー

このアーキテクチャの Visio ファイルをダウンロードします。

注

この記事では AKS と GitHub を参照していますが、これらの推奨事項は任意のコンテナー オーケストレーションまたは CI/CD プラットフォームに適用されます。 実装の詳細は異なる場合があります。各ステージで説明されている概念とプラクティスのほとんどは、引き続き関連性があり、適用できます。

1. Microsoft Entra ID は、GitHub の ID プロバイダーとして構成されます。 追加の認証セキュリティを提供するために、多要素認証 (MFA) を構成します。
2. 開発者は、セキュリティ拡張機能が有効な Visual Studio Code または Visual Studio を使用して、セキュリティの脆弱性についてコードを事前に分析します。
3. 開発者は、企業所有および管理されている GitHub Enterprise リポジトリにアプリケーション コードをコミットします。
4. GitHub Enterprise では、 GitHub Advanced Security を使用した自動セキュリティと依存関係のスキャンが統合されます。
5. プル要求は、 GitHub Actions を使用して継続的インテグレーション (CI) ビルドと自動テストをトリガーします。
6. GitHub Actions を使用した CI ビルド ワークフローでは、 Azure Container Registry に格納されている Docker コンテナー イメージが生成されます。
7. GitHub Actions の継続的デリバリー (CD) ワークフローの一部として、運用環境などの特定の環境へのデプロイに対する手動承認を導入できます。
8. GitHub Actions では、AKS に対して CD が有効になります。 GitHub Advanced Security を使用して、アプリケーション のソースファイルと構成ファイル内のシークレット、資格情報、およびその他の機密情報を検出します。
9. Microsoft Defender は、セキュリティの脆弱性について Azure Container Registry、AKS クラスター、Azure Key Vault をスキャンするために使用されます。
   1. Microsoft Defender for Containers は、 コンテナー レジストリへのアップロード時に、コンテナー イメージをスキャンして既知のセキュリティの脆弱性を検出します。
   2. Defender for Containers を使用して AKS 環境のスキャンを実行し、AKS クラスターの実行時の脅威保護を提供することもできます。
   3. Microsoft Defender for Key Vault は 、有害で異常な疑わしいキー コンテナー アカウントへのアクセス試行を検出します。
10. Azure Policy は、ポリシーのコンプライアンスと適用のために、Container Registry と Azure Kubernetes Service (AKS) に適用できます。 コンテナー レジストリと AKS の一般的なセキュリティ ポリシーは、迅速な有効化のために組み込まれています。
11. Azure Key Vault は、実行時にアプリケーションにシークレットと資格情報を安全に挿入するために使用され、開発者から機密情報を分離します。
12. AKS ネットワーク ポリシー エンジンは、Kubernetes ネットワーク ポリシーを使用してアプリケーション ポッド間のトラフィックをセキュリティで保護するように構成されています。
13. AKS クラスターの継続的な監視は、 Azure Monitor と Container Insights を使用してパフォーマンス メトリックを取り込み、アプリケーションとセキュリティ ログを分析することによって設定できます。
    1. Container Insights は、パフォーマンス メトリックとアプリケーションログとクラスター ログを取得します。
    2. 診断ログとアプリケーション ログは、ログ クエリを実行するために Azure Log Analytics ワークスペースにプルされます。
14. セキュリティ情報およびイベント管理 (SIEM) ソリューションである Microsoft Sentinel を使用すると、定義されたパターンとルールに基づいて、AKS クラスター ログを取り込んで、セキュリティの脅威をさらに分析できます。
15. Zed Attack Proxy (ZAP) (ZAP) などの Open-Source ツールを使用して、Web アプリケーションやサービスの侵入テストを行うことができます。
16. Defender for Cloud で利用できるサービスである Defender for DevOps は、セキュリティ チームが GitHub や Azure DevOps を含むマルチパイプライン環境全体で DevOps のセキュリティを管理できるようにします。

チーム メンバーの概要と責任

懸念事項の分離として、Kubernetes ベースのソリューション デプロイでの DevSecOps の複雑さを管理することを検討してください。 展開の各側面に関係する必要があるエンタープライズ環境のチームはどれですか? チームが目標を最も達成するために採用すべきツールとプロセスは何ですか? このセクションでは、開発者、アプリケーション オペレーター (サイト信頼性エンジニア)、クラスター オペレーター、セキュリティ チームの一般的な役割について説明します。

開発者

開発者は、アプリケーション コードを記述する必要があります。 また、指定されたリポジトリにコードをコミットする責任もあります。 開発者の重要な役割の 1 つに、コードが意図したとおりに動作し、アプリケーションの残りの部分とシームレスに統合されるようにするための自動テスト用のスクリプトの作成と実行も含まれます。 また、自動化パイプラインの一部としてコンテナー イメージのビルドを定義およびスクリプト化します。

アプリケーションオペレーター (サイト信頼性エンジニア)

コンテナーと Kubernetes を使用してクラウド上にアプリケーションを構築すると、アプリケーションの開発、デプロイ、スケーラビリティを簡素化できます。 しかし、これらの開発アプローチにより、管理が複雑化する分散環境も生まれます。 サイト信頼性エンジニアは、大規模なソフトウェア システムの監視を自動化するソリューションを構築します。 開発チームとクラスター オペレーター チームの間の橋渡しとして機能し、サービス レベルの目標とエラー予算の確立と監視に役立ちます。 この方法では、アプリケーションのデプロイを管理し、多くの場合、Kubernetes マニフェスト (YAML) ファイルを記述するのに役立ちます。

クラスター演算子

クラスター オペレーターは、クラスター インフラストラクチャの構成と管理を担当します。 多くの場合、コードとしてのインフラストラクチャ (IaC) のベスト プラクティスと GitOps などのフレームワークを使用して、クラスターをプロビジョニングおよび維持します。 Azure Monitor Container Insights や Prometheus/Grafana などのさまざまな監視ツールを使用して、クラスターの全体的な正常性を監視します。 クラスターに対する修正プログラムの適用、クラスターのアップグレード、アクセス許可、ロールベースのアクセス制御を担当します。 DevSecOps チームでは、クラスターがチームのセキュリティ要件を満たしていることを確認し、セキュリティ チームと協力してこれらの標準を作成します。

セキュリティ チーム

セキュリティ チームは、セキュリティ標準の開発と適用を担当します。 一部のチームは、クラスターを保持するサブスクリプションとリソース グループに適用される Azure Policy の作成と選択を担当する場合があります。 セキュリティの問題を監視し、他のチームと共に、DevSecOps プロセスのすべてのステップの最前線にセキュリティが提供されるようにします。

DevSecOps ライフサイクル ステージ

セキュリティ制御は、ソフトウェア開発ライフサイクル (SDLC) の各フェーズで実装されます。 この実装は、DevSecOps 戦略とシフト左アプローチの重要な部分です。

このアーキテクチャの Visio ファイルをダウンロードします。

計画フェーズ

通常、計画フェーズには最小限の自動化がありますが、後の DevOps ライフサイクル ステージに大きな影響を与える重要なセキュリティへの影響があります。 このフェーズでは、セキュリティ チーム、開発チーム、運用チーム間のコラボレーションが含まれます。 設計と計画のこのフェーズにセキュリティ関係者を含めると、セキュリティ要件とセキュリティの問題が適切に考慮または軽減されます。

ベスト プラクティス - より安全なアプリケーション プラットフォームを設計する

より安全な AKS でホストされるプラットフォームを構築することは、プラットフォーム自体から始めて、すべてのレイヤーでセキュリティがシステムに組み込まれるようにするための重要な手順です。 プラットフォームには、クラスター内部のコンポーネント (ランタイム セキュリティやポリシー エージェントなど) と、AKS の外部にあるコンポーネント (ネットワーク ファイアウォールやコンテナー レジストリなど) の両方を含めることができます。 詳細については、セキュリティ、ID、ネットワーク トポロジなどの重要な設計領域を含む、 アプリケーション ランディング ゾーンの AKS を参照してください。

ベスト プラクティス - 脅威モデリングをプロセスに組み込む

• 脅威のモデリングは、通常、セキュリティチームと開発チームを含む手動アクティビティです。 これは、システム内の脅威をモデル化して見つけるために使用されるため、コードの開発やシステムへの変更の前に脆弱性に対処できます。 脅威モデリングは、ソフトウェアの大幅な変更、ソリューションアーキテクチャの変更、セキュリティ インシデントなどのイベントによってトリガーされ、さまざまな時間に発生する可能性があります。
• STRIDE 脅威モデルを使用することをお勧めします。 この手法はデータ フロー図から始まり、STRIDE ニーモニック (スプーフィング、改ざん、情報漏えい、否認、サービス拒否、特権の昇格) 脅威カテゴリを使用して、チームがリスクを特定、軽減、検証できるようにします。 また、システム コンポーネント、データ フロー、およびセキュリティ境界を示し、視覚化するための モデリング ツール も含まれています。 SDLC プロセスに脅威モデリングを組み込むには、新しいプロセスと、更新された脅威モデルを維持するためのより多くの作業が導入されます。 ただし、セキュリティが早期に設定されていることを確認するのに役立ちます。これにより、後の SDLC ステージで見つかったセキュリティの問題に対処するための潜在的なコストを削減できます。

ベスト プラクティス – Azure Well Architect Framework (WAF) を適用する

• クラウド ネイティブ環境に適用される ID 管理、アプリケーション セキュリティ、インフラストラクチャ保護、日付セキュリティ、DevOps などのガイダンスを提供する WAF セキュリティの柱 のベスト プラクティスを適用します。
• DEVSecOps と運用環境の監視に適用される WAF 運用 のベスト プラクティスを適用します。

開発フェーズ

"左にシフト" は、DevSecOps の考え方の重要なテナントです。 このプロセスは、コードがリポジトリにコミットされ、パイプライン経由でデプロイされる前に開始されます。 開発フェーズ中にセキュリティで保護されたコーディングのベスト プラクティスを採用し、IDE ツールとプラグインを使用してコード分析を行うと、開発ライフサイクルの早い段階で修正が容易になった場合のセキュリティの問題に対処するのに役立ちます。

ベスト プラクティス – セキュリティで保護されたコーディング標準を適用する

• 確立されたセキュリティで保護されたコーディングのベスト プラクティスとチェックリストを使用すると、インジェクションや安全でない設計などの一般的な脆弱性からコードを保護できます。 OWASP Foundation では、コードの記述時に採用する必要がある業界標準のセキュリティで保護されたコーディングに関する推奨事項が公開されています。 これらのガイドラインは、公開 Web アプリケーションまたはサービスを開発する場合に特に重要です。
• 一般的なセキュリティのベスト プラクティスに加えて、 Java や .NET などの特定のプログラミング言語ランタイムのセキュリティで保護されたコーディングプラクティスについても確認する必要があります。
• ログ記録標準を適用して、機密情報がアプリケーション ログに漏えいしないように保護できます。 log4j や log4net などの最も一般的なログ記録フレームワークには、アカウント番号や個人データなどの機密情報をマスクするためのフィルターとプラグインが用意されています。

ベスト プラクティス – IDE ツールとプラグインを使用してセキュリティ チェックを自動化する

Visual Studio、Visual Studio Code、IntelliJ IDEA、Eclipse などの最も一般的な IDE では、アプリケーション コードの記述中に発生した可能性がある潜在的なセキュリティの問題に関するフィードバックと推奨事項をすぐに取得するために使用できる拡張機能がサポートされています。

• SonarLint は、最も一般的な言語と開発者環境で使用できる IDE プラグインです。 SonarLint は貴重なフィードバックを提供し、一般的なプログラミング エラーや潜在的なセキュリティの問題についてコードを自動的にスキャンします。
• その他の無料および商用プラグインは、OWASP の上位 10 個の一般的な脆弱性など、セキュリティ固有の項目に重点を置いています。 たとえば、 Synk プラグインでは、アプリケーション ソースとサードパーティの依存関係もスキャンされ、脆弱性が見つかった場合にアラートが表示されます。
• Visual Studio および Visual Studio Code 用 の静的分析結果交換形式 (SARIF) プラグインを使用すると、一般的な静的アプリケーション セキュリティ テスト (SAST) ツールの脆弱性を、生の JSON 出力ファイルから結果を解釈するのと比較して、直感的で読みやすい方法で簡単に表示できます。

ベスト プラクティス – ソース コード リポジトリでコントロールを確立する

• 企業全体で分岐を一貫して使用できるように、ブランチ手法を確立します。 リリース フローや GitHub フローなどの手法には、チームと並列開発をサポートするためにブランチを使用する方法に関する構造化されたガイドラインがあります。 これらの手法は、チームがコードのコミットと CI/CD ワークフローへのマージの標準と制御を確立するのに役立ちます。
• main などの特定のブランチは、アプリケーションのソース コードの整合性を維持する長期的なブランチです。 変更をマージまたはコミットする前に、これらのブランチでマージ ポリシーを確立する必要があります。 ベスト プラクティスには、次のようなものがあります。
  • 他の開発者がメイン ブランチに直接コードをコミットできないようにします。
  • ピア レビュー プロセスを確立し、変更をメイン ブランチにマージするには、承認の最小数が必要です。 GitHub では、これらのコントロールを簡単に構成して適用できます。 GitHub では、ゲート環境に必要に応じて、承認された承認者のグループを指定することもできます。
• コミット前フックを使用して、アプリケーションのソース コード内の機密情報を確認し、セキュリティの問題が見つかった場合にコミットが発生しないようにします。
  • 特定のプロジェクト用に簡単に構成できる、GitHub が提供する組み込みの事前コミット フックを使用します。 たとえば、シークレット、秘密キー、資格情報をスキャンし、これらの問題のいずれかが見つかった場合にコミットを防ぐための、あらかじめ構築されたフックがあります。
• バージョン管理システム内でロールベースのアクセス制御を確立します。
  • 最小限の特権の原則を使用して、明確に定義されたロールを作成します。 CI/CD パイプラインは、運用環境のデプロイ用のサプライ チェーンです。
  • 組織内で確立されたユーザーロールまたはグループ ロール を適用します。 管理者、開発者、セキュリティ管理者、オペレーターなどのロールは、CI/CD ワークフローに関する特定の役割と機能に基づいて個人をグループ化するために作成する必要があります。
• CI/CD パイプラインに関する構成やその他の変更に対する透明性と追跡可能性が確保されるように、ワークフローの 監査 を有効にします。

ベスト プラクティス - コンテナー イメージをセキュリティで保護する

• OS フットプリントを最小限に抑えた軽量イメージを使用して、全体的な攻撃領域を減らします。 Alpine などの最小限のイメージや、アプリケーションとそれに関連付けられているランタイムのみを含むディストリビューションレス イメージを検討してください。 Microsoft オープン ソースの Linux ディストリビューションである Mariner は、コンテナー化されたワークロードをホストするために AKS 向けに設計された軽量で堅牢なディストリビューションです。
• コンテナーを構築するときは、信頼された基本イメージのみを使用します。 これらの基本イメージは、脆弱性を頻繁にスキャンするプライベート レジストリから取得する必要があります。
• 開発者ツールを使用して、イメージの脆弱性をローカルで評価します。
  • Trivy は、コンテナー イメージ内のセキュリティの脆弱性を分析するために使用できるオープンソース ツールの例です。
• イメージのルート ユーザー アクセス/コンテキストを禁止します。 既定では、コンテナーはルートとして実行されます。
  • セキュリティ強化が必要なコンテナーの場合は、Kubernetes クラスター内で AppArmor プロファイルを使用して、実行中のコンテナーのセキュリティをさらに強化することを検討してください。

ビルド フェーズ

ビルド フェーズ中、開発者はサイト信頼性エンジニアやセキュリティ チームと協力して、CI ビルド パイプライン内にアプリケーション ソースの自動スキャンを統合します。 パイプラインは、CI/CD プラットフォームのセキュリティ ツールと拡張機能を使用して、SAST、SCA、シークレットのスキャンなどのセキュリティ プラクティスを有効にするように構成されています。

ベスト プラクティス – 静的コード分析 (SAST) を実行して、アプリケーションのソース コードに潜在的な脆弱性を見つける

• コード スキャンと CodeQL には、GitHub Advanced Security のスキャン機能を使用します。
  • コード スキャン は、GitHub リポジトリ内のコードを分析してセキュリティの脆弱性とコーディング エラーを見つけるために使用する機能です。 分析によって特定された問題は、GitHub Enterprise Cloud に表示されます。
  • コード スキャンでコードに潜在的な脆弱性またはエラーが見つかると、GitHub によってリポジトリにアラートが表示されます。
  • たとえば、新しいコードをマージする前に、機能ブランチがベース ブランチと最新の状態であることを強制するために、 必要な状態チェックの分岐ルールを構成することもできます。 この方法により、ブランチは常に最新のコードでテストされます。
• kube-score などのツールを使用して、Kubernetes デプロイ オブジェクトを分析します。
  • kube-score は、Kubernetes オブジェクト定義の静的コード分析を行うツールです。
  • 出力は、アプリケーションのセキュリティと回復性を高めるために改善できる推奨事項の一覧です。

ベスト プラクティス – シークレット スキャンを実行して、リポジトリに誤ってコミットされたシークレットの不正使用を防ぐ

• リポジトリに対 してシークレット スキャン が有効になっている場合、GitHub はコードをスキャンして、多くのサービス プロバイダーによって使用されるシークレットと一致するパターンを探します。
• GitHub では、リポジトリ内の既存のコンテンツの完全な Git 履歴スキャンも定期的に実行され、アラート通知が送信されます。
  • Azure DevOps の場合、 Defender for Cloud ではシークレット スキャンを使用して、ソース コードとビルド出力内の資格情報、シークレット、証明書、およびその他の機密性の高いコンテンツを検出します。
  • シークレット スキャンは、Microsoft Security DevOps for Azure DevOps 拡張機能の一部として実行できます。

ベスト プラクティス – ソフトウェア構成分析 (SCA) ツールを使用してコードベース内のオープンソース コンポーネントを追跡し、依存関係の脆弱性を検出する

• 依存関係の確認 では、セキュリティで保護されていない依存関係を環境に導入する前にキャッチし、依存関係のライセンス、依存、および有効期間に関する情報を提供できます。 プル要求の [Files Changed]\(変更されたファイル\) タブの豊富な差分を使用して、依存関係の変更を簡単に理解できます。
• Dependabot は、セキュリティで保護されていない依存関係を検出するスキャンを実行し、新しいアドバイザリが GitHub Advisory Database に追加されたとき、またはリポジトリの依存関係グラフが変更されたときに Dependabot アラートを送信します。

ベスト プラクティス – コードとしてのインフラストラクチャ (IaC) テンプレートのセキュリティ スキャンを有効にして、運用環境に到達するクラウドの構成ミスを最小限に抑える

• 開発ライフサイクル全体を通じてクラウド リソース構成を事前に監視します。
• Microsoft Defender for DevOps では、GitHub リポジトリと Azure DevOps リポジトリの両方がサポートされています。

ベスト プラクティス – コンテナー レジストリ内のワークロード イメージをスキャンして既知の脆弱性を特定する

• Defender for Containers は、 Container Registry と Amazon AWS Elastic Container Registry (ECR) のコンテナーをスキャンして、イメージに既知の脆弱性があるかどうかを通知します。
• Azure Policy を 有効にすると、Container Registry に格納されているすべてのイメージに対して脆弱性評価を実行し、各検出に関する詳細情報を提供できます。

ベスト プラクティス – 基本イメージの更新時に新しいイメージを自動的にビルドする

• Azure Container Registry タスクは 、コンテナー イメージのビルド時に基本イメージの依存関係を動的に検出します。 その結果、アプリケーション イメージの基本イメージが更新されるタイミングを検出できます。 構成済みのビルド タスクを 1 つ使用すると、Container Registry タスクは、基本イメージを参照するすべてのアプリケーション イメージを自動的に再構築できます。

ベスト プラクティス – Container Registry、Azure Key Vault、表記を使用してコンテナー イメージにデジタル署名し、検証済みイメージのみを許可するように AKS クラスターを構成する

• Azure Key Vault には、コンテナー イメージやその他の成果物に署名して検証するために、Key Vault プラグイン (azure-kv) の 表記 で使用できる 署名 キーが格納されています。 Container Registry では、Azure CLI コマンドを使用してこれらの署名をアタッチできます。
• 署名されたコンテナーを使用すると、ユーザーは、デプロイが信頼できるエンティティからビルドされていることを確認し、作成後にアーティファクトが改ざんされていないことを確認できます。 署名された成果物は、ユーザーが任意の環境に成果物をプルする前に整合性と信頼性を確保し、攻撃を回避するのに役立ちます。
  • Ratify を使用すると、Kubernetes クラスターでは、デプロイ前に成果物のセキュリティ メタデータを検証し、作成したアドミッション ポリシーに準拠しているデプロイのみを許可できます。

デプロイ フェーズ

デプロイ フェーズでは、開発者、アプリケーションオペレーター、およびクラスター オペレーター チームが連携して、継続的デプロイ (CD) パイプラインの適切なセキュリティ制御を確立し、より安全で自動化された方法でコードを運用環境にデプロイします。

ベスト プラクティス – デプロイ パイプラインのアクセスとワークフローを制御する

• ブランチ 保護 規則を設定することで、重要なブランチを保護できます。 これらのルールは、コラボレーターがブランチを削除するか強制的にプッシュできるかを定義します。 また、状態チェックや線形コミット履歴の受け渡しなど、ブランチへのプッシュの要件も設定します。
• 環境 をデプロイ に使用することで、保護規則とシークレットを使用して環境を構成できます。
• 承認とゲート機能を利用して、デプロイ パイプラインのワークフローを制御できます。 たとえば、運用環境にデプロイする前に、セキュリティチームまたは運用チームからの手動承認を要求できます。

ベスト プラクティス – デプロイ資格情報をセキュリティで保護する

• OpenID Connect (OIDC) を使用すると、GitHub アクション ワークフローは、有効期間の長い GitHub シークレットとして Azure 資格情報を格納する必要なく、Azure 内のリソースにアクセスできます。
• 環境をデプロイに使用することで、保護規則とシークレットを使用して環境を構成できます。
  • GitOps を使用した CI/CD に対するプルベースのアプローチでは、セキュリティ資格情報を Kubernetes クラスターに移行できます。これにより、外部 CI ツールに格納される資格情報を削除することで、セキュリティとリスクの面が軽減されます。 また、許可される受信接続を減らし、Kubernetes クラスターへの管理者レベルのアクセスを制限することもできます。

ベスト プラクティス – 動的アプリケーション セキュリティ テスト (DAST) を実行して、実行中のアプリケーションの脆弱性を見つける

• デプロイ ワークフローで GitHub Actions を 使用して、動的アプリケーション セキュリティ テスト (DAST) テストを実行します。
• ZAP などのオープンソース ツールを使用して、一般的な Web アプリケーションの脆弱性の侵入テストを行います。

ベスト プラクティス – 信頼されたレジストリからのみコンテナー イメージをデプロイする

• Defender for Containers を使用して、Kubernetes の Azure Policy アドオンを有効にします。
• コンテナー イメージを信頼されたレジストリからのみデプロイできるように、Azure Policy を有効にします。

運用フェーズ

このフェーズでは、潜在的なセキュリティ インシデントを事前に監視、分析、アラートするために、操作の監視とセキュリティの監視タスクが実行されます。 Azure Monitor や Microsoft Sentinel などの運用監視ツールは、エンタープライズ セキュリティ標準の監視とコンプライアンスの確保に使用されます。

ベスト プラクティス - Microsoft Defender for cloud を使用して、運用構成の自動スキャンと監視を有効にする

• 継続的なスキャンを実行して、アプリケーションの脆弱性状態の誤差を検出し、脆弱な画像にパッチを適用して置き換えるプロセスを実装します。
• オペレーティング システムの自動構成監視を実装します。
  • Microsoft Defender for Cloud コンテナーの推奨事項 ([ コンピューティングとアプリ ] セクションの下) を使用して、AKS クラスターのベースライン スキャンを実行します。 構成の問題または脆弱性が見つかった場合は、Microsoft Defender for Cloud ダッシュボードで通知を受け取ります。
  • Microsoft Defender for Cloud を使用し、そのネットワーク保護に関する推奨事項に従って、AKS クラスターで使用されているネットワーク リソースを セキュリティで保護 します。
• Container Registry に格納されているイメージの脆弱性評価を実施します。
  • Defender for Containers を有効にして、コンテナー レジストリで実行中のイメージの継続的スキャンを実装します。

ベスト プラクティス - Kubernetes クラスターを最新の状態に保つ

• Kubernetes リリースは頻繁にロールアウトされます。 サポートが遅れ、サポート対象外にされないように、ライフサイクル管理戦略を策定することが重要です。 AKS は、このアップグレード プロセスを管理するためのツールと柔軟性を提供するマネージド オファリングです。 AKS プラットフォームの計画メンテナンス機能を使用して、メンテナンス期間とアップグレードをより詳細に制御できます。
• AKS ワーカー ノードは、より頻繁に アップグレード する必要があります。 毎週の OS とランタイムの更新プログラムを提供しています。自動モードまたは Azure CLI を使用して自動的に適用して、より詳細な制御と包括的な更新を行うことができます。

ベスト プラクティス – Azure Policy を使用して AKS クラスターをセキュリティで保護および管理する

• AKS 用の Azure Policy アドオンをインストールした後、個々のポリシー定義またはイニシアティブ (ポリシー セットとも呼ばれます) と呼ばれるポリシー定義のグループをクラスターに適用できます。
• 特権コンテナーの実行を防ぐ、許可リストに登録されている外部 IP のみを承認するなどの一般的なシナリオには、 組み込みの Azure ポリシー を使用します。 特定のユース ケースのカスタム ポリシーを作成することもできます。
• クラスターにポリシー定義を適用し、それらの割り当てが適用されていることを確認します。
• Gatekeeper を使用して、指定された規則に基づいてデプロイを許可または拒否するアドミッション コントローラーを構成します。 Azure Policy は Gatekeeper を拡張します。
• AKS のネットワーク ポリシーを使用してワークロード ポッド間のトラフィックをセキュリティで保護します。
  • ネットワーク ポリシー エンジンをインストールし、Kubernetes ネットワーク ポリシー を作成して、AKS 内のポッド間のトラフィックフローを制御します。 ネットワーク ポリシーは、AKS の Linux ベースまたは Windows ベースのノードとポッドに使用できます。

ベスト プラクティス - 継続的な監視とアラートに Azure Monitor を使用する

• Azure Monitor を使用して、AKS からログとメトリックを収集します。 アプリケーションとインフラストラクチャの可用性とパフォーマンスに関する分析情報を得ることができます。 また、シグナルにアクセスしてソリューションの正常性を監視し、異常なアクティビティを早期に検出することもできます。
  • Azure Monitor を使用した継続的な監視は、リリース パイプラインまで拡張され、監視データに基づいてリリースをゲートまたはロールバックします。 また、Azure Monitor はセキュリティ ログを取り込み、疑わしいアクティビティに関するアラートを生成することもできます。
  • AKS インスタンスを Azure Monitor にオンボードし、クラスターの診断設定を構成します。
    • Azure Kubernetes Service の Azure セキュリティ ベースラインを参照してください。

ベスト プラクティス - Microsoft Defender for Cloud を使用してアクティブな脅威の監視を行う

• Microsoft Defender for Cloud では、ノード レベル (VM の脅威) と内部の AKS でアクティブな脅威の監視が提供されます。
• Defender for DevOps は、包括的な可視性のために使用する必要があり、セキュリティ チームとオペレーター チームに、すべての CI/CD パイプラインの一元化されたダッシュボードを提供します。 この機能は、Azure DevOps や GitHub などのマルチパイプライン プラットフォームを使用している場合や、パブリック クラウド間でパイプラインを実行している場合に特に便利です。
• Defender for Key Vault を使用すると、キー コンテナー アカウントへの通常とは異なる疑わしいアクセス試行を検出し、構成に基づいて管理者に警告することができます。
• Defender for Containers は、Container Registry に格納されているコンテナー イメージ内で見つかった脆弱性に関するアラートを生成できます。

ベスト プラクティス - ログの一元的な監視を有効にし、SIEM 製品を使用してリアルタイムのセキュリティの脅威を監視する

• AKS 診断ログを Microsoft Sentinel に接続して、パターンとルールに基づいて一元的なセキュリティ監視を行います。 Sentinel を使用すると、 データ コネクタ経由でシームレスにアクセスできます。

ベスト プラクティス – 監査ログを有効にして運用クラスターのアクティビティを監視する

• アクティビティ ログを使用して AKS リソースのアクションを監視し、すべてのアクティビティとその状態を表示します。 リソースに対して実行された操作と実行者を決定します。
• CoreDNS カスタム ConfigMap に文書化された構成を適用して 、DNS クエリ ログ を有効にします。
• 非アクティブ化された資格情報へのアクセスの試行を監視します。
  • AKS のユーザー認証を Microsoft Entra ID と統合します。 監査ログとサインイン ログを Azure Log Analytics ワークスペースに 送信 して、Microsoft Entra ID の診断設定を作成します。 Azure Log Analytics ワークスペース内で必要なアラート (非アクティブ化されたアカウントがサインインを試みる場合など) を構成します。

ベスト プラクティス – Azure リソースで診断を有効にする

• ワークロードのすべてのリソースで Azure 診断を有効にすると、Azure リソースの詳細な診断と監査情報を提供するプラットフォーム ログにアクセスできます。 これらのログは、セキュリティの監視とアラートのために Log Analytics または Microsoft Sentinel などの SIEM ソリューションに取り込むことができます。

貢献者

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

主要な著者

• アドナン・カーン |クラウド ソリューション アーキテクト

その他の共同作成者:

• あよばみあよでじ |プログラム マネージャー 2
• アーメッド・バム |クラウド ソリューション アーキテクト
• チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス
• ジョン・プール |クラウド ソリューション アーキテクト
• バラム・ルセナス |ソリューション アーキテクト
• アベド・サウ |クラウド ソリューション アーキテクト

次のステップ

• Microsoft Defender for Cloud
• セキュリティで保護された DevOps
• DevOps のセキュリティ (DevSecOps)
• GitHub Advanced Security
• GitOps

関連リソース

• コードとしてのインフラストラクチャ用 DevSecOps (IaC)
• 左にシフト

DevSecOps (Secure DevOps とも呼ばれます) は、従来の DevOps ライフサイクルのさまざまな段階でセキュリティを組み込むことによって、DevOps のプラクティスに基づいています。 DevOps プラクティスでセキュリティを構築する利点には、次のようなものがあります。

• セキュリティ上の脅威を可視化し、脆弱性がデプロイされた環境に到達するのを防ぐことで、アプリケーションとシステムの安全性を高める
• 開発チームと運用チームによるセキュリティ意識の向上
• 自動化されたセキュリティ プロセスをソフトウェア開発ライフサイクルに組み込む
• 開発および設計段階の早い段階でセキュリティの問題を見つけることで、修復コストを削減する

DevSecOps が Azure Kubernetes Service (AKS) に適用されている場合、組織の役割によって、セキュリティを実装するための考慮事項が異なる場合があります。 これらのさまざまな組織の役割の例を次に示します。

• AKS で実行されているセキュリティで保護されたアプリケーションを構築する開発者
• セキュリティで保護された AKS インフラストラクチャを構築するクラウド エンジニア
• クラスターを管理したり、セキュリティの問題を監視したりする可能性のあるさまざまな運用チーム

この記事は、セキュリティコントロールとセキュリティのベスト プラクティスを埋め込むための考慮事項と推奨事項を含む、さまざまな DevOps ライフサイクル ステージに分かれています。 このガイドには、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに組み込む一般的なプロセスとツールが含まれており、使用可能な場合は使いやすい組み込みツールを選択します。

この記事の前提条件として、 DevOps と GitOps を使用して AKS でアプリをビルドしてデプロイする方法を確認することをお勧めします。

プロセス フロー

このアーキテクチャの Visio ファイルをダウンロードします。

注

この記事では AKS と GitHub を参照していますが、これらの推奨事項は任意のコンテナー オーケストレーションまたは CI/CD プラットフォームに適用されます。 実装の詳細は異なる場合があります。各ステージで説明されている概念とプラクティスのほとんどは、引き続き関連性があり、適用できます。

1. Microsoft Entra ID は、GitHub の ID プロバイダーとして構成されます。 追加の認証セキュリティを提供するために、多要素認証 (MFA) を構成します。
2. 開発者は、セキュリティ拡張機能が有効な Visual Studio Code または Visual Studio を使用して、セキュリティの脆弱性についてコードを事前に分析します。
3. 開発者は、企業所有および管理されている GitHub Enterprise リポジトリにアプリケーション コードをコミットします。
4. GitHub Enterprise では、 GitHub Advanced Security を使用した自動セキュリティと依存関係のスキャンが統合されます。
5. プル要求は、 GitHub Actions を使用して継続的インテグレーション (CI) ビルドと自動テストをトリガーします。
6. GitHub Actions を使用した CI ビルド ワークフローでは、 Azure Container Registry に格納されている Docker コンテナー イメージが生成されます。
7. GitHub Actions の継続的デリバリー (CD) ワークフローの一部として、運用環境などの特定の環境へのデプロイに対する手動承認を導入できます。
8. GitHub Actions では、AKS に対して CD が有効になります。 GitHub Advanced Security を使用して、アプリケーション のソースファイルと構成ファイル内のシークレット、資格情報、およびその他の機密情報を検出します。
9. Microsoft Defender は、セキュリティの脆弱性について Azure Container Registry、AKS クラスター、Azure Key Vault をスキャンするために使用されます。
   1. Microsoft Defender for Containers は、 コンテナー レジストリへのアップロード時に、コンテナー イメージをスキャンして既知のセキュリティの脆弱性を検出します。
   2. Defender for Containers を使用して AKS 環境のスキャンを実行し、AKS クラスターの実行時の脅威保護を提供することもできます。
   3. Microsoft Defender for Key Vault は 、有害で異常な疑わしいキー コンテナー アカウントへのアクセス試行を検出します。
10. Azure Policy は、ポリシーのコンプライアンスと適用のために、Container Registry と Azure Kubernetes Service (AKS) に適用できます。 コンテナー レジストリと AKS の一般的なセキュリティ ポリシーは、迅速な有効化のために組み込まれています。
11. Azure Key Vault は、実行時にアプリケーションにシークレットと資格情報を安全に挿入するために使用され、開発者から機密情報を分離します。
12. AKS ネットワーク ポリシー エンジンは、Kubernetes ネットワーク ポリシーを使用してアプリケーション ポッド間のトラフィックをセキュリティで保護するように構成されています。
13. AKS クラスターの継続的な監視は、 Azure Monitor と Container Insights を使用してパフォーマンス メトリックを取り込み、アプリケーションとセキュリティ ログを分析することによって設定できます。
    1. Container Insights は、パフォーマンス メトリックとアプリケーションログとクラスター ログを取得します。
    2. 診断ログとアプリケーション ログは、ログ クエリを実行するために Azure Log Analytics ワークスペースにプルされます。
14. セキュリティ情報およびイベント管理 (SIEM) ソリューションである Microsoft Sentinel を使用すると、定義されたパターンとルールに基づいて、AKS クラスター ログを取り込んで、セキュリティの脅威をさらに分析できます。
15. Zed Attack Proxy (ZAP) (ZAP) などの Open-Source ツールを使用して、Web アプリケーションやサービスの侵入テストを行うことができます。
16. Defender for Cloud で利用できるサービスである Defender for DevOps は、セキュリティ チームが GitHub や Azure DevOps を含むマルチパイプライン環境全体で DevOps のセキュリティを管理できるようにします。

チーム メンバーの概要と責任

懸念事項の分離として、Kubernetes ベースのソリューション デプロイでの DevSecOps の複雑さを管理することを検討してください。 展開の各側面に関係する必要があるエンタープライズ環境のチームはどれですか? チームが目標を最も達成するために採用すべきツールとプロセスは何ですか? このセクションでは、開発者、アプリケーション オペレーター (サイト信頼性エンジニア)、クラスター オペレーター、セキュリティ チームの一般的な役割について説明します。

開発者

開発者は、アプリケーション コードを記述する必要があります。 また、指定されたリポジトリにコードをコミットする責任もあります。 開発者の重要な役割の 1 つに、コードが意図したとおりに動作し、アプリケーションの残りの部分とシームレスに統合されるようにするための自動テスト用のスクリプトの作成と実行も含まれます。 また、自動化パイプラインの一部としてコンテナー イメージのビルドを定義およびスクリプト化します。

アプリケーションオペレーター (サイト信頼性エンジニア)

コンテナーと Kubernetes を使用してクラウド上にアプリケーションを構築すると、アプリケーションの開発、デプロイ、スケーラビリティを簡素化できます。 しかし、これらの開発アプローチにより、管理が複雑化する分散環境も生まれます。 サイト信頼性エンジニアは、大規模なソフトウェア システムの監視を自動化するソリューションを構築します。 開発チームとクラスター オペレーター チームの間の橋渡しとして機能し、サービス レベルの目標とエラー予算の確立と監視に役立ちます。 この方法では、アプリケーションのデプロイを管理し、多くの場合、Kubernetes マニフェスト (YAML) ファイルを記述するのに役立ちます。

クラスター演算子

クラスター オペレーターは、クラスター インフラストラクチャの構成と管理を担当します。 多くの場合、コードとしてのインフラストラクチャ (IaC) のベスト プラクティスと GitOps などのフレームワークを使用して、クラスターをプロビジョニングおよび維持します。 Azure Monitor Container Insights や Prometheus/Grafana などのさまざまな監視ツールを使用して、クラスターの全体的な正常性を監視します。 クラスターに対する修正プログラムの適用、クラスターのアップグレード、アクセス許可、ロールベースのアクセス制御を担当します。 DevSecOps チームでは、クラスターがチームのセキュリティ要件を満たしていることを確認し、セキュリティ チームと協力してこれらの標準を作成します。

セキュリティ チーム

セキュリティ チームは、セキュリティ標準の開発と適用を担当します。 一部のチームは、クラスターを保持するサブスクリプションとリソース グループに適用される Azure Policy の作成と選択を担当する場合があります。 セキュリティの問題を監視し、他のチームと共に、DevSecOps プロセスのすべてのステップの最前線にセキュリティが提供されるようにします。

DevSecOps ライフサイクル ステージ

セキュリティ制御は、ソフトウェア開発ライフサイクル (SDLC) の各フェーズで実装されます。 この実装は、DevSecOps 戦略とシフト左アプローチの重要な部分です。

このアーキテクチャの Visio ファイルをダウンロードします。

計画フェーズ

通常、計画フェーズには最小限の自動化がありますが、後の DevOps ライフサイクル ステージに大きな影響を与える重要なセキュリティへの影響があります。 このフェーズでは、セキュリティ チーム、開発チーム、運用チーム間のコラボレーションが含まれます。 設計と計画のこのフェーズにセキュリティ関係者を含めると、セキュリティ要件とセキュリティの問題が適切に考慮または軽減されます。

ベスト プラクティス - より安全なアプリケーション プラットフォームを設計する

より安全な AKS でホストされるプラットフォームを構築することは、プラットフォーム自体から始めて、すべてのレイヤーでセキュリティがシステムに組み込まれるようにするための重要な手順です。 プラットフォームには、クラスター内部のコンポーネント (ランタイム セキュリティやポリシー エージェントなど) と、AKS の外部にあるコンポーネント (ネットワーク ファイアウォールやコンテナー レジストリなど) の両方を含めることができます。 詳細については、セキュリティ、ID、ネットワーク トポロジなどの重要な設計領域を含む、 アプリケーション ランディング ゾーンの AKS を参照してください。

ベスト プラクティス - 脅威モデリングをプロセスに組み込む

• 脅威のモデリングは、通常、セキュリティチームと開発チームを含む手動アクティビティです。 これは、システム内の脅威をモデル化して見つけるために使用されるため、コードの開発やシステムへの変更の前に脆弱性に対処できます。 脅威モデリングは、ソフトウェアの大幅な変更、ソリューションアーキテクチャの変更、セキュリティ インシデントなどのイベントによってトリガーされ、さまざまな時間に発生する可能性があります。
• STRIDE 脅威モデルを使用することをお勧めします。 この手法はデータ フロー図から始まり、STRIDE ニーモニック (スプーフィング、改ざん、情報漏えい、否認、サービス拒否、特権の昇格) 脅威カテゴリを使用して、チームがリスクを特定、軽減、検証できるようにします。 また、システム コンポーネント、データ フロー、およびセキュリティ境界を示し、視覚化するための モデリング ツール も含まれています。 SDLC プロセスに脅威モデリングを組み込むには、新しいプロセスと、更新された脅威モデルを維持するためのより多くの作業が導入されます。 ただし、セキュリティが早期に設定されていることを確認するのに役立ちます。これにより、後の SDLC ステージで見つかったセキュリティの問題に対処するための潜在的なコストを削減できます。

ベスト プラクティス – Azure Well Architect Framework (WAF) を適用する

• クラウド ネイティブ環境に適用される ID 管理、アプリケーション セキュリティ、インフラストラクチャ保護、日付セキュリティ、DevOps などのガイダンスを提供する WAF セキュリティの柱 のベスト プラクティスを適用します。
• DEVSecOps と運用環境の監視に適用される WAF 運用 のベスト プラクティスを適用します。

開発フェーズ

"左にシフト" は、DevSecOps の考え方の重要なテナントです。 このプロセスは、コードがリポジトリにコミットされ、パイプライン経由でデプロイされる前に開始されます。 開発フェーズ中にセキュリティで保護されたコーディングのベスト プラクティスを採用し、IDE ツールとプラグインを使用してコード分析を行うと、開発ライフサイクルの早い段階で修正が容易になった場合のセキュリティの問題に対処するのに役立ちます。

ベスト プラクティス – セキュリティで保護されたコーディング標準を適用する

• 確立されたセキュリティで保護されたコーディングのベスト プラクティスとチェックリストを使用すると、インジェクションや安全でない設計などの一般的な脆弱性からコードを保護できます。 OWASP Foundation では、コードの記述時に採用する必要がある業界標準のセキュリティで保護されたコーディングに関する推奨事項が公開されています。 これらのガイドラインは、公開 Web アプリケーションまたはサービスを開発する場合に特に重要です。
• 一般的なセキュリティのベスト プラクティスに加えて、 Java や .NET などの特定のプログラミング言語ランタイムのセキュリティで保護されたコーディングプラクティスについても確認する必要があります。
• ログ記録標準を適用して、機密情報がアプリケーション ログに漏えいしないように保護できます。 log4j や log4net などの最も一般的なログ記録フレームワークには、アカウント番号や個人データなどの機密情報をマスクするためのフィルターとプラグインが用意されています。

ベスト プラクティス – IDE ツールとプラグインを使用してセキュリティ チェックを自動化する

Visual Studio、Visual Studio Code、IntelliJ IDEA、Eclipse などの最も一般的な IDE では、アプリケーション コードの記述中に発生した可能性がある潜在的なセキュリティの問題に関するフィードバックと推奨事項をすぐに取得するために使用できる拡張機能がサポートされています。

• SonarLint は、最も一般的な言語と開発者環境で使用できる IDE プラグインです。 SonarLint は貴重なフィードバックを提供し、一般的なプログラミング エラーや潜在的なセキュリティの問題についてコードを自動的にスキャンします。
• その他の無料および商用プラグインは、OWASP の上位 10 個の一般的な脆弱性など、セキュリティ固有の項目に重点を置いています。 たとえば、 Synk プラグインでは、アプリケーション ソースとサードパーティの依存関係もスキャンされ、脆弱性が見つかった場合にアラートが表示されます。
• Visual Studio および Visual Studio Code 用 の静的分析結果交換形式 (SARIF) プラグインを使用すると、一般的な静的アプリケーション セキュリティ テスト (SAST) ツールの脆弱性を、生の JSON 出力ファイルから結果を解釈するのと比較して、直感的で読みやすい方法で簡単に表示できます。

ベスト プラクティス – ソース コード リポジトリでコントロールを確立する

• 企業全体で分岐を一貫して使用できるように、ブランチ手法を確立します。 リリース フローや GitHub フローなどの手法には、チームと並列開発をサポートするためにブランチを使用する方法に関する構造化されたガイドラインがあります。 これらの手法は、チームがコードのコミットと CI/CD ワークフローへのマージの標準と制御を確立するのに役立ちます。
• main などの特定のブランチは、アプリケーションのソース コードの整合性を維持する長期的なブランチです。 変更をマージまたはコミットする前に、これらのブランチでマージ ポリシーを確立する必要があります。 ベスト プラクティスには、次のようなものがあります。
  • 他の開発者がメイン ブランチに直接コードをコミットできないようにします。
  • ピア レビュー プロセスを確立し、変更をメイン ブランチにマージするには、承認の最小数が必要です。 GitHub では、これらのコントロールを簡単に構成して適用できます。 GitHub では、ゲート環境に必要に応じて、承認された承認者のグループを指定することもできます。
• コミット前フックを使用して、アプリケーションのソース コード内の機密情報を確認し、セキュリティの問題が見つかった場合にコミットが発生しないようにします。
  • 特定のプロジェクト用に簡単に構成できる、GitHub が提供する組み込みの事前コミット フックを使用します。 たとえば、シークレット、秘密キー、資格情報をスキャンし、これらの問題のいずれかが見つかった場合にコミットを防ぐための、あらかじめ構築されたフックがあります。
• バージョン管理システム内でロールベースのアクセス制御を確立します。
  • 最小限の特権の原則を使用して、明確に定義されたロールを作成します。 CI/CD パイプラインは、運用環境のデプロイ用のサプライ チェーンです。
  • 組織内で確立されたユーザーロールまたはグループ ロール を適用します。 管理者、開発者、セキュリティ管理者、オペレーターなどのロールは、CI/CD ワークフローに関する特定の役割と機能に基づいて個人をグループ化するために作成する必要があります。
• CI/CD パイプラインに関する構成やその他の変更に対する透明性と追跡可能性が確保されるように、ワークフローの 監査 を有効にします。

ベスト プラクティス - コンテナー イメージをセキュリティで保護する

• OS フットプリントを最小限に抑えた軽量イメージを使用して、全体的な攻撃領域を減らします。 Alpine などの最小限のイメージや、アプリケーションとそれに関連付けられているランタイムのみを含むディストリビューションレス イメージを検討してください。 Microsoft オープン ソースの Linux ディストリビューションである Mariner は、コンテナー化されたワークロードをホストするために AKS 向けに設計された軽量で堅牢なディストリビューションです。
• コンテナーを構築するときは、信頼された基本イメージのみを使用します。 これらの基本イメージは、脆弱性を頻繁にスキャンするプライベート レジストリから取得する必要があります。
• 開発者ツールを使用して、イメージの脆弱性をローカルで評価します。
  • Trivy は、コンテナー イメージ内のセキュリティの脆弱性を分析するために使用できるオープンソース ツールの例です。
• イメージのルート ユーザー アクセス/コンテキストを禁止します。 既定では、コンテナーはルートとして実行されます。
  • セキュリティ強化が必要なコンテナーの場合は、Kubernetes クラスター内で AppArmor プロファイルを使用して、実行中のコンテナーのセキュリティをさらに強化することを検討してください。

ビルド フェーズ

ビルド フェーズ中、開発者はサイト信頼性エンジニアやセキュリティ チームと協力して、CI ビルド パイプライン内にアプリケーション ソースの自動スキャンを統合します。 パイプラインは、CI/CD プラットフォームのセキュリティ ツールと拡張機能を使用して、SAST、SCA、シークレットのスキャンなどのセキュリティ プラクティスを有効にするように構成されています。

ベスト プラクティス – 静的コード分析 (SAST) を実行して、アプリケーションのソース コードに潜在的な脆弱性を見つける

• コード スキャンと CodeQL には、GitHub Advanced Security のスキャン機能を使用します。
  • コード スキャン は、GitHub リポジトリ内のコードを分析してセキュリティの脆弱性とコーディング エラーを見つけるために使用する機能です。 分析によって特定された問題は、GitHub Enterprise Cloud に表示されます。
  • コード スキャンでコードに潜在的な脆弱性またはエラーが見つかると、GitHub によってリポジトリにアラートが表示されます。
  • たとえば、新しいコードをマージする前に、機能ブランチがベース ブランチと最新の状態であることを強制するために、 必要な状態チェックの分岐ルールを構成することもできます。 この方法により、ブランチは常に最新のコードでテストされます。
• kube-score などのツールを使用して、Kubernetes デプロイ オブジェクトを分析します。
  • kube-score は、Kubernetes オブジェクト定義の静的コード分析を行うツールです。
  • 出力は、アプリケーションのセキュリティと回復性を高めるために改善できる推奨事項の一覧です。

ベスト プラクティス – シークレット スキャンを実行して、リポジトリに誤ってコミットされたシークレットの不正使用を防ぐ

• リポジトリに対 してシークレット スキャン が有効になっている場合、GitHub はコードをスキャンして、多くのサービス プロバイダーによって使用されるシークレットと一致するパターンを探します。
• GitHub では、リポジトリ内の既存のコンテンツの完全な Git 履歴スキャンも定期的に実行され、アラート通知が送信されます。
  • Azure DevOps の場合、 Defender for Cloud ではシークレット スキャンを使用して、ソース コードとビルド出力内の資格情報、シークレット、証明書、およびその他の機密性の高いコンテンツを検出します。
  • シークレット スキャンは、Microsoft Security DevOps for Azure DevOps 拡張機能の一部として実行できます。

ベスト プラクティス – ソフトウェア構成分析 (SCA) ツールを使用してコードベース内のオープンソース コンポーネントを追跡し、依存関係の脆弱性を検出する

• 依存関係の確認 では、セキュリティで保護されていない依存関係を環境に導入する前にキャッチし、依存関係のライセンス、依存、および有効期間に関する情報を提供できます。 プル要求の [Files Changed]\(変更されたファイル\) タブの豊富な差分を使用して、依存関係の変更を簡単に理解できます。
• Dependabot は、セキュリティで保護されていない依存関係を検出するスキャンを実行し、新しいアドバイザリが GitHub Advisory Database に追加されたとき、またはリポジトリの依存関係グラフが変更されたときに Dependabot アラートを送信します。

ベスト プラクティス – コードとしてのインフラストラクチャ (IaC) テンプレートのセキュリティ スキャンを有効にして、運用環境に到達するクラウドの構成ミスを最小限に抑える

• 開発ライフサイクル全体を通じてクラウド リソース構成を事前に監視します。
• Microsoft Defender for DevOps では、GitHub リポジトリと Azure DevOps リポジトリの両方がサポートされています。

ベスト プラクティス – コンテナー レジストリ内のワークロード イメージをスキャンして既知の脆弱性を特定する

• Defender for Containers は、 Container Registry と Amazon AWS Elastic Container Registry (ECR) のコンテナーをスキャンして、イメージに既知の脆弱性があるかどうかを通知します。
• Azure Policy を 有効にすると、Container Registry に格納されているすべてのイメージに対して脆弱性評価を実行し、各検出に関する詳細情報を提供できます。

ベスト プラクティス – 基本イメージの更新時に新しいイメージを自動的にビルドする

• Azure Container Registry タスクは 、コンテナー イメージのビルド時に基本イメージの依存関係を動的に検出します。 その結果、アプリケーション イメージの基本イメージが更新されるタイミングを検出できます。 構成済みのビルド タスクを 1 つ使用すると、Container Registry タスクは、基本イメージを参照するすべてのアプリケーション イメージを自動的に再構築できます。

ベスト プラクティス – Container Registry、Azure Key Vault、表記を使用してコンテナー イメージにデジタル署名し、検証済みイメージのみを許可するように AKS クラスターを構成する

• Azure Key Vault には、コンテナー イメージやその他の成果物に署名して検証するために、Key Vault プラグイン (azure-kv) の 表記 で使用できる 署名 キーが格納されています。 Container Registry では、Azure CLI コマンドを使用してこれらの署名をアタッチできます。
• 署名されたコンテナーを使用すると、ユーザーは、デプロイが信頼できるエンティティからビルドされていることを確認し、作成後にアーティファクトが改ざんされていないことを確認できます。 署名された成果物は、ユーザーが任意の環境に成果物をプルする前に整合性と信頼性を確保し、攻撃を回避するのに役立ちます。
  • Ratify を使用すると、Kubernetes クラスターでは、デプロイ前に成果物のセキュリティ メタデータを検証し、作成したアドミッション ポリシーに準拠しているデプロイのみを許可できます。

デプロイ フェーズ

デプロイ フェーズでは、開発者、アプリケーションオペレーター、およびクラスター オペレーター チームが連携して、継続的デプロイ (CD) パイプラインの適切なセキュリティ制御を確立し、より安全で自動化された方法でコードを運用環境にデプロイします。

ベスト プラクティス – デプロイ パイプラインのアクセスとワークフローを制御する

• ブランチ 保護 規則を設定することで、重要なブランチを保護できます。 これらのルールは、コラボレーターがブランチを削除するか強制的にプッシュできるかを定義します。 また、状態チェックや線形コミット履歴の受け渡しなど、ブランチへのプッシュの要件も設定します。
• 環境 をデプロイ に使用することで、保護規則とシークレットを使用して環境を構成できます。
• 承認とゲート機能を利用して、デプロイ パイプラインのワークフローを制御できます。 たとえば、運用環境にデプロイする前に、セキュリティチームまたは運用チームからの手動承認を要求できます。

ベスト プラクティス – デプロイ資格情報をセキュリティで保護する

• OpenID Connect (OIDC) を使用すると、GitHub アクション ワークフローは、有効期間の長い GitHub シークレットとして Azure 資格情報を格納する必要なく、Azure 内のリソースにアクセスできます。
• 環境をデプロイに使用することで、保護規則とシークレットを使用して環境を構成できます。
  • GitOps を使用した CI/CD に対するプルベースのアプローチでは、セキュリティ資格情報を Kubernetes クラスターに移行できます。これにより、外部 CI ツールに格納される資格情報を削除することで、セキュリティとリスクの面が軽減されます。 また、許可される受信接続を減らし、Kubernetes クラスターへの管理者レベルのアクセスを制限することもできます。

ベスト プラクティス – 動的アプリケーション セキュリティ テスト (DAST) を実行して、実行中のアプリケーションの脆弱性を見つける

• デプロイ ワークフローで GitHub Actions を 使用して、動的アプリケーション セキュリティ テスト (DAST) テストを実行します。
• ZAP などのオープンソース ツールを使用して、一般的な Web アプリケーションの脆弱性の侵入テストを行います。

ベスト プラクティス – 信頼されたレジストリからのみコンテナー イメージをデプロイする

• Defender for Containers を使用して、Kubernetes の Azure Policy アドオンを有効にします。
• コンテナー イメージを信頼されたレジストリからのみデプロイできるように、Azure Policy を有効にします。

運用フェーズ

このフェーズでは、潜在的なセキュリティ インシデントを事前に監視、分析、アラートするために、操作の監視とセキュリティの監視タスクが実行されます。 Azure Monitor や Microsoft Sentinel などの運用監視ツールは、エンタープライズ セキュリティ標準の監視とコンプライアンスの確保に使用されます。

ベスト プラクティス - Microsoft Defender for cloud を使用して、運用構成の自動スキャンと監視を有効にする

• 継続的なスキャンを実行して、アプリケーションの脆弱性状態の誤差を検出し、脆弱な画像にパッチを適用して置き換えるプロセスを実装します。
• オペレーティング システムの自動構成監視を実装します。
  • Microsoft Defender for Cloud コンテナーの推奨事項 ([ コンピューティングとアプリ ] セクションの下) を使用して、AKS クラスターのベースライン スキャンを実行します。 構成の問題または脆弱性が見つかった場合は、Microsoft Defender for Cloud ダッシュボードで通知を受け取ります。
  • Microsoft Defender for Cloud を使用し、そのネットワーク保護に関する推奨事項に従って、AKS クラスターで使用されているネットワーク リソースを セキュリティで保護 します。
• Container Registry に格納されているイメージの脆弱性評価を実施します。
  • Defender for Containers を有効にして、コンテナー レジストリで実行中のイメージの継続的スキャンを実装します。

ベスト プラクティス - Kubernetes クラスターを最新の状態に保つ

• Kubernetes リリースは頻繁にロールアウトされます。 サポートが遅れ、サポート対象外にされないように、ライフサイクル管理戦略を策定することが重要です。 AKS は、このアップグレード プロセスを管理するためのツールと柔軟性を提供するマネージド オファリングです。 AKS プラットフォームの計画メンテナンス機能を使用して、メンテナンス期間とアップグレードをより詳細に制御できます。
• AKS ワーカー ノードは、より頻繁に アップグレード する必要があります。 毎週の OS とランタイムの更新プログラムを提供しています。自動モードまたは Azure CLI を使用して自動的に適用して、より詳細な制御と包括的な更新を行うことができます。

ベスト プラクティス – Azure Policy を使用して AKS クラスターをセキュリティで保護および管理する

• AKS 用の Azure Policy アドオンをインストールした後、個々のポリシー定義またはイニシアティブ (ポリシー セットとも呼ばれます) と呼ばれるポリシー定義のグループをクラスターに適用できます。
• 特権コンテナーの実行を防ぐ、許可リストに登録されている外部 IP のみを承認するなどの一般的なシナリオには、 組み込みの Azure ポリシー を使用します。 特定のユース ケースのカスタム ポリシーを作成することもできます。
• クラスターにポリシー定義を適用し、それらの割り当てが適用されていることを確認します。
• Gatekeeper を使用して、指定された規則に基づいてデプロイを許可または拒否するアドミッション コントローラーを構成します。 Azure Policy は Gatekeeper を拡張します。
• AKS のネットワーク ポリシーを使用してワークロード ポッド間のトラフィックをセキュリティで保護します。
  • ネットワーク ポリシー エンジンをインストールし、Kubernetes ネットワーク ポリシー を作成して、AKS 内のポッド間のトラフィックフローを制御します。 ネットワーク ポリシーは、AKS の Linux ベースまたは Windows ベースのノードとポッドに使用できます。

ベスト プラクティス - 継続的な監視とアラートに Azure Monitor を使用する

• Azure Monitor を使用して、AKS からログとメトリックを収集します。 アプリケーションとインフラストラクチャの可用性とパフォーマンスに関する分析情報を得ることができます。 また、シグナルにアクセスしてソリューションの正常性を監視し、異常なアクティビティを早期に検出することもできます。
  • Azure Monitor を使用した継続的な監視は、リリース パイプラインまで拡張され、監視データに基づいてリリースをゲートまたはロールバックします。 また、Azure Monitor はセキュリティ ログを取り込み、疑わしいアクティビティに関するアラートを生成することもできます。
  • AKS インスタンスを Azure Monitor にオンボードし、クラスターの診断設定を構成します。
    • Azure Kubernetes Service の Azure セキュリティ ベースラインを参照してください。

ベスト プラクティス - Microsoft Defender for Cloud を使用してアクティブな脅威の監視を行う

• Microsoft Defender for Cloud では、ノード レベル (VM の脅威) と内部の AKS でアクティブな脅威の監視が提供されます。
• Defender for DevOps は、包括的な可視性のために使用する必要があり、セキュリティ チームとオペレーター チームに、すべての CI/CD パイプラインの一元化されたダッシュボードを提供します。 この機能は、Azure DevOps や GitHub などのマルチパイプライン プラットフォームを使用している場合や、パブリック クラウド間でパイプラインを実行している場合に特に便利です。
• Defender for Key Vault を使用すると、キー コンテナー アカウントへの通常とは異なる疑わしいアクセス試行を検出し、構成に基づいて管理者に警告することができます。
• Defender for Containers は、Container Registry に格納されているコンテナー イメージ内で見つかった脆弱性に関するアラートを生成できます。

ベスト プラクティス - ログの一元的な監視を有効にし、SIEM 製品を使用してリアルタイムのセキュリティの脅威を監視する

• AKS 診断ログを Microsoft Sentinel に接続して、パターンとルールに基づいて一元的なセキュリティ監視を行います。 Sentinel を使用すると、 データ コネクタ経由でシームレスにアクセスできます。

ベスト プラクティス – 監査ログを有効にして運用クラスターのアクティビティを監視する

• アクティビティ ログを使用して AKS リソースのアクションを監視し、すべてのアクティビティとその状態を表示します。 リソースに対して実行された操作と実行者を決定します。
• CoreDNS カスタム ConfigMap に文書化された構成を適用して 、DNS クエリ ログ を有効にします。
• 非アクティブ化された資格情報へのアクセスの試行を監視します。
  • AKS のユーザー認証を Microsoft Entra ID と統合します。 監査ログとサインイン ログを Azure Log Analytics ワークスペースに 送信 して、Microsoft Entra ID の診断設定を作成します。 Azure Log Analytics ワークスペース内で必要なアラート (非アクティブ化されたアカウントがサインインを試みる場合など) を構成します。

ベスト プラクティス – Azure リソースで診断を有効にする

• ワークロードのすべてのリソースで Azure 診断を有効にすると、Azure リソースの詳細な診断と監査情報を提供するプラットフォーム ログにアクセスできます。 これらのログは、セキュリティの監視とアラートのために Log Analytics または Microsoft Sentinel などの SIEM ソリューションに取り込むことができます。

貢献者

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

主要な著者

• アドナン・カーン |クラウド ソリューション アーキテクト

その他の共同作成者:

• あよばみあよでじ |プログラム マネージャー 2
• アーメッド・バム |クラウド ソリューション アーキテクト
• チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス
• ジョン・プール |クラウド ソリューション アーキテクト
• バラム・ルセナス |ソリューション アーキテクト
• アベド・サウ |クラウド ソリューション アーキテクト

次のステップ

• Microsoft Defender for Cloud
• セキュリティで保護された DevOps
• DevOps のセキュリティ (DevSecOps)
• GitHub Advanced Security
• GitOps

関連リソース

• コードとしてのインフラストラクチャ用 DevSecOps (IaC)
• 左にシフト