DevSecOps (別名: Secure DevOps) は、DevOps のプラクティスに基づいて構築されており、従来の DevOps ライフサイクルのさまざまな段階にセキュリティが組み込まれています。 DevOps プラクティスでセキュリティを構築する利点には、次のようなものがあります。
- セキュリティの脅威を可視化し、デプロイされた環境に脆弱性が及ぶのを防ぐことで、アプリケーションとシステムのセキュリティを強化する
- 開発チームと運用チームのセキュリティ意識を高める
- 自動化されたセキュリティ プロセスをソフトウェア開発ライフサイクルに組み込む
- 開発および設計の早い段階でセキュリティの問題を見つけることで修復コストを削減する
DevSecOps が Azure Kubernetes Service (AKS) に適用される場合、組織の役割ごとに、セキュリティの実装に関する考慮事項が異なる場合があります。 これらのさまざまな組織の役割の例を次に示します。
- AKS で実行されるセキュリティで保護されたアプリケーションを構築する開発者
- セキュリティで保護された AKS インフラストラクチャを構築するクラウド エンジニア
- クラスターの管理やセキュリティの問題の監視などを行うさまざまな運用チーム
この記事は、DevOps ライフサイクルのさまざまなステージに分かれており、セキュリティ制御とセキュリティのベスト プラクティスを組み込むための考慮事項と推奨事項が含まれます。 このガイドには、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに組み込まれる一般的なプロセスとツールが含まれており、使用可能な場合は使いやすい組み込みツールを選択できます。
この記事の前提条件として、DevOps と GitOps を使用したアプリの構築と AKS へのアプリのデプロイに関するページを確認することをお勧めします。
プロセス フロー
このアーキテクチャの Visio ファイルをダウンロードします。
注意
この記事では AKS と GitHub を参照していますが、これらの推奨事項は任意のコンテナー オーケストレーションまたは CI/CD プラットフォームに適用されます。 実装の詳細は異なる場合がありますが、各ステージで説明されている概念とプラクティスのほとんどは関連性があり、適用できます。
- Microsoft Entra ID は、GitHub の ID プロバイダーとして構成されます。 追加の認証セキュリティを提供するために、多要素認証 (MFA) を構成します。
- 開発者が、セキュリティの脆弱性を見つけるために、セキュリティ拡張機能を有効にした Visual Studio Code または Visual Studio を使用してコードを事前に分析します。
- 開発者が、企業が所有および管理する GitHub Enterprise リポジトリにアプリケーション コードをコミットします。
- GitHub Enterprise で、GitHub Advanced Security を通じて、自動セキュリティと依存関係スキャンが統合されます。
- プル要求により、GitHub Actions を介して継続的インテグレーション (CI) のビルドと自動テストがトリガーされます。
- GitHub Actions を介した CI ビルド ワークフローにより、Azure Container Registry に保存される Docker コンテナー イメージが生成されます。
- GitHub Actions の継続的デリバリー (CD) ワークフローの一部として、運用環境などの特定環境へのデプロイに対して手動承認を導入できます。
- GitHub Actions により、AKS への CD が可能になります。 GitHub Advanced Security を使用して、アプリケーションのソース ファイルと構成ファイル内のシークレット、資格情報、その他の機密情報を検出します。
- セキュリティの脆弱性を見つけるために、Microsoft Defender を使用して Azure Container Registry、AKS クラスター、Azure Key Vault がスキャンされます。
- コンテナー イメージが Container Registry にアップロードされるとき、既知のセキュリティ脆弱性を見つけるために、Microsoft Defender for Containers によってそのコンテナー イメージがスキャンされます。
- Defender for Containers を使用して AKS 環境のスキャンを実行し、AKS クラスターに実行時の脅威保護を提供することもできます。
- Microsoft Defender for Key Vault により、キー コンテナー アカウントにアクセスするための有害な試行、異常な試行、疑わしい試行が検出されます。
- ポリシーのコンプライアンスと実施のために、Azure Policy を Container Registry と Azure Kubernetes Service (AKS) に適用できます。 Container Registry と AKS の共通のセキュリティ ポリシーは、迅速に有効化できるように組み込みとなっています。
- Azure Key Vault を使用して、実行時にシークレットと資格情報がアプリケーションに安全に挿入され、開発者から機密情報が分離されます。
- Kubernetes ネットワーク ポリシーを使用して、アプリケーション ポッド間のトラフィックをセキュリティで保護するように AKS ネットワーク ポリシー エンジンを構成します。
- パフォーマンス メトリックを取り込み、アプリケーション ログとセキュリティ ログを分析するために、Azure Monitor と Container insights を使用して AKS クラスターの継続的監視を設定できます。
- Container insights により、パフォーマンス メトリック、アプリケーション ログ、クラスター ログが取得されます。
- ログ クエリを実行するために、診断ログとアプリケーション ログが Azure Log Analytics ワークスペースにプルされます。
- セキュリティ情報イベント管理 (SIEM) ソリューションである Microsoft Sentinel を使用して、AKS クラスター ログを取り込んで詳しく分析し、定義済みのパターンとルールに基づいてセキュリティ上の脅威を検出できます。
- Zed Attack Proxy (ZAP) (ZAP) などのオープンソース ツールを使用して、Web アプリケーションとサービスに対して侵入テストを実行できます。
- 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 外部のコンポーネント (ネットワーク ファイアウォールやコンテナー レジストリなど) の両方を含めることができます。 詳細については、「AKS ランディング ゾーン アクセラレータ」を参照してください。ここには、セキュリティ、ID、ネットワーク トポロジなど、重要な設計分野が含まれます。
ベスト プラクティス – プロセスに脅威モデリングを組み込む
- 脅威モデリングは、通常、セキュリティ チームと開発チームが関連する手作業の活動です。 これを使用して脅威をモデル化し、その脅威をシステム内で見つけることで、コード開発やシステムの変更の前に脆弱性に対処できます。 脅威モデリングは、さまざまなタイミングで実行でき、たとえば、ソフトウェアの大幅な変更、ソリューション アーキテクチャの変更、セキュリティ インシデントなどのイベントによってトリガーされます。
- STRIDE 脅威モデルを使用することをお勧めします。 この手法は、データ フロー図から始まり、STRIDE ニーモニック (スプーフィング、改ざん、情報漏えい、否認、サービス拒否、特権の昇格) の脅威カテゴリを使用して、チームがリスクを特定、軽減、検証できるようにします。 また、システム コンポーネント、データ フロー、セキュリティ境界を図式化して視覚化するためのモデリング ツールも含まれます。 SDLC プロセスに脅威モデリングを組み込むと、新しいプロセスが導入され、更新された脅威モデルを維持するために作業が増えます。 ただし、これにより、セキュリティが早期に確立され、後の SDLC ステージで検出されるセキュリティの問題に対処するための潜在的なコストを削減できます。
ベスト プラクティス – Azure Well Architect Framework (WAF) を適用する
- WAF セキュリティ重要要素のベスト プラクティスを適用します。このベスト プラクティスでは、ID 管理、アプリケーション セキュリティ、インフラストラクチャ保護、データ セキュリティ、DevOps などのガイダンスが提供されています。これは、クラウド ネイティブ環境に適用されます。
- WAF 運用のベスト プラクティスを適用します。これは、運用環境の DevSecOps と監視に適用されます。
開発フェーズ
"シフト レフト" は、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 用の Static Analysis Results Interchange Format (SARIF) プラグインを使用すると、生の JSON 出力ファイルから結果を解釈する代わりに、一般的な静的アプリケーション セキュリティ テスト (SAST) ツールから、直感的で読みやすい方法で脆弱性を簡単に確認できます。
ベスト プラクティス – ソース コード リポジトリに対する制御を確立する
- ブランチ手法を確立して、企業全体でブランチが一貫して使用されるようにします。 リリース フローや GitHub フローなどの手法には、チームと並列開発をサポートするためのブランチの使用方法に関する構造化されたガイドラインがあります。 これらの手法により、チームは、コードを CI/CD ワークフローにコミットおよびマージするための標準と制御を確立できます。
- メインなどの特定のブランチは、アプリケーションのソース コードの整合性を維持する長期的なブランチです。 変更をブランチにマージまたはコミットする前に、これらのブランチでマージ ポリシーを確立する必要があります。 いくつかのベスト プラクティスを次に示します。
- 他の開発者がコードをメイン ブランチに直接コミットできないようにします。
- ピア レビュー プロセスを確立し、変更をメイン ブランチにマージする前に最小限の承認を要求します。 これらの制御は、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) ツールを使用して、コードベース内のオープンソース コンポーネントを追跡し、依存関係の脆弱性を検出する
- 依存関係を確認することで、安全でない依存関係を自分の環境に持ち込む前に見つけることができ、ライセンス、依存物、依存関係の期間に関する情報を入手できます。 Pull Requestの"Files Changed(変更されたファイル)"タブ上のリッチdiffで、依存関係の変化を理解しやすく可視化します。
- 新しいアドバイザリが GitHub Advisory Database に追加されると、またはリポジトリの依存関係グラフが変更されると、Dependabot はスキャンを実行して安全でない依存関係を検出し、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、notation を使用してコンテナー イメージにデジタル署名し、検証済みのイメージのみを許可するように AKS クラスターを構成する
- Azure Key Vault では、署名キーが保存されます。この署名キーを、notation Key Vault プラグイン (azure-kv) による notation で使用して、コンテナー イメージと他の成果物に署名し、それらを検証できます。 Container Registry では、Azure CLI コマンドを使用してこれらの署名をアタッチできます。
- 署名されたコンテナーを使用すると、ユーザーは、デプロイが信頼できるエンティティからビルドされたことを確認でき、また作成後に成果物が改ざんされていないことを確認できます。 署名された成果物により、ユーザーが任意の環境に成果物をプルする前に整合性と信頼性が確保され、攻撃の回避に役立ちます。
- Ratify を使用すると、Kubernetes クラスターで、デプロイ前に成果物のセキュリティ メタデータを検証でき、作成した許可ポリシーに準拠するデプロイのみを許可できます。
デプロイ フェーズ
デプロイ フェーズでは、開発者、アプリケーション オペレーター、クラスター オペレーター チームが協力して、継続的デプロイ (CD) パイプラインの適切なセキュリティ制御を確立し、より安全で自動化された方法でコードを運用環境にデプロイします。
ベスト プラクティス – デプロイ パイプラインのアクセスとワークフローを制御する
- ブランチ保護ルールを設定することで、重要なブランチを保護できます。 これらのルールでは、コラボレーターがブランチを削除できるかどうかや、ブランチへのプッシュを強制できるかどうかを定義します。 また、状態チェックの合格やリニア コミット履歴など、ブランチへのプッシュの要件も設定します。
- デプロイ用の環境を使用することで、保護ルールとシークレットを使用して環境を構成できます。
- 承認とゲート機能を利用して、デプロイ パイプラインのワークフローを制御できます。 たとえば、運用環境へのデプロイの前に、セキュリティ チームまたは運用チームからの手動承認を要求できます。
ベスト プラクティス - デプロイ資格情報をセキュリティで保護する
- OpenID Connect (OIDC) を使用すると、GitHub Action ワークフローで Azure 内のリソースにアクセスできます。このとき、Azure 資格情報を有効期間が長い GitHub シークレットとして保存する必要はありません。
- デプロイ用の環境を使用することで、保護ルールとシークレットを使用して環境を構成できます。
- 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 を有効にして、Container Registry で実行されているイメージの継続的スキャンを実施します。
ベスト プラクティス – 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 を使用する必要があります。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 と統合します。 Microsoft Entra ID の診断設定を作成し、監査ログとサインイン ログを Azure Log Analytics ワークスペースに送信します。 Azure Log Analytics ワークスペース内で、必要なアラート (非アクティブ化されたアカウントがサインインしようとした場合のアラートなど) を構成します。
ベスト プラクティス – Azure リソースに対する診断を有効にする
- ワークロードのすべてのリソースに対して Azure Diagnostics を有効にすると、Azure リソースの詳細な診断と監査情報を提供するプラットフォーム ログにアクセスできます。 これらのログは、セキュリティの監視とアラートのために、Log Analytics または Microsoft Sentinel などの SIEM ソリューションに取り込むことができます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Adnan Khan | シニア クラウド ソリューション アーキテクト
その他の共同作成者:
- Ayobami Ayodeji | プログラム マネージャー 2
- Ahmed Bham | シニア クラウド ソリューション アーキテクト
- Chad Kittel | プリンシパル ソフトウェア エンジニア
- John Poole | シニア クラウド ソリューション アーキテクト
- Bahram Rushenas | シニア ソリューション アーキテクト
- Abed Sau | シニア クラウド ソリューション アーキテクト
次のステップ
- Microsoft Defender for Cloud
- セキュリティで保護された DevOps
- DevOps のセキュリティ (DevSecOps)
- GitHub Advanced Security
- GitOps