Azure Kubernetes Service (AKS) の脆弱性の管理

脆弱性の管理には、組織のシステムとソフトウェアに存在するあらゆるセキュリティ脆弱性の検出、評価、軽減、報告が含まれます。 脆弱性の管理は、お客様と Microsoft の共同責任です。

ほとんどの運用ワークロードでは、AKS Automatic が推奨される既定のクラスター エクスペリエンスです。 AKS 自動では、マネージド システム ノード プール、クラスターとノード イメージの自動アップグレード、組み込みのセキュリティ保護、運用対応の既定値を提供することで、運用上のオーバーヘッドを軽減します。 クラスター構成をより直接的に制御する必要がある場合、AKS Standard は特殊なシナリオで引き続き使用できます。

この記事では、Microsoftが AKS クラスターのセキュリティの脆弱性とセキュリティ更新プログラム (パッチとも呼ばれます) を管理する方法について説明します。 AKS 自動エクスペリエンスの概要については、「Azure Kubernetes Service (AKS) Automatic の概要」を参照してください。

AKS の自動および脆弱性の管理

AKS Automatic は、新しい AKS ワークロードの運用環境対応の既定値として設計されています。 これには、クラスターのセキュリティ体制を強化し、ワークロードを最新の状態に保つために必要な手動作業の量を減らす既定値が含まれています。次に例を示します。

• AKS が作成、スケーリング、アップグレードするマネージド システム ノード プール。
• システム ノード プールの Linux をAzureします。
• クラスターとノード イメージの自動アップグレード。
• Azure の Kubernetes 認可向けロールベースのアクセス制御 (RBAC)
• ワークロード ID と OIDC Issuer への対応。
• デプロイセーフガードとベースラインポッドセキュリティ標準。
• 未使用のイメージを削除するイメージ クリーナー。
• マネージド ネットワークの既定値により、カスタム インフラストラクチャ構成の必要性が軽減されます。

これらの既定値は、Microsoftと顧客が既知の脆弱性の露出期間を減らし、クラスターを最新の状態に保つプロセスを簡略化するのに役立ちます。 AKS Standard は、より手動またはカスタマイズ可能な運用モデルが必要な場合でも使用できます。

脆弱性の検出方法

Microsoft は、次のコンポーネントの脆弱性と不足しているセキュリティ更新プログラムを特定し、パッチを適用します。

• AKS コンテナー イメージ: Microsoftは、Kubernetes コンポーネントやその他のオープンソース ソフトウェアを含む AKS で使用されるコンテナー イメージをビルドおよび管理します。 Microsoftは、これらのイメージの脆弱性をスキャンし、必要に応じて修正プログラムを適用します。
• Ubuntu オペレーティング システム 18.04 および 22.04 ワーカー ノード: Canonical は、使用可能なすべてのセキュリティ更新プログラムが適用された OS ビルドをMicrosoftします。
• Windows Server 2022 OS ワーカー ノード: Windows Server オペレーティング システムは、毎月第 2 火曜日に修正プログラムが適用されます。 SLA は、サポート契約および重大度と同一である必要があります。
• Azure Linux OS ノード: Azure Linux は、使用可能なすべてのセキュリティ更新プログラムが適用された OS ビルドを AKS に提供します。

AKS 自動クラスターの場合、マネージド システム ノード プールは既定で Azure Linux を使用します。これは、クラスターをプラットフォームのセキュリティで強化されたマネージド オペレーティング システム モデルに合わせて調整します。 既定では、自分で行う必要があるノード レベルのパッチ管理の量が減ります。

AKS コンテナー イメージ

Cloud Native Computing Foundation (CNCF) は、AKS で実行されるほとんどのコードを所有し保守していますが、Microsoft は AKS にデプロイするオープンソース パッケージをビルドする責任を担っています。 その責任には、ビルド、スキャン、署名、検証、修正プログラムプロセスの完全な所有権の取得、コンテナー イメージ内のバイナリの制御が含まれます。 Microsoft は、AKS にデプロイされるオープンソース パッケージをビルドする責任を担うことで、バイナリによるソフトウェア サプライ チェーンを確立し、必要に応じてソフトウェアにパッチを適用することができます。  

Microsoft は、広範な Kubernetes エコシステムで活動し、より広範な CNCF コミュニティでクラウドネイティブ コンピューティングの将来を構築できるよう支援しています。 この作業により、世界中のすべての Kubernetes リリースの品質が保証されるだけでなく、数年間にわたって AKS で新しい Kubernetes リリースを運用環境に迅速に移行できるようになります。 場合によっては、他のクラウド プロバイダーよりも数か月早く運用化できます。 Microsoft は、Kubernetes セキュリティ組織の他の業界パートナーと共同で作業を行っています。 たとえば、セキュリティ対応委員会 (SRC) では、一般に公開される前に、差し止められたセキュリティの脆弱性を受け取り、優先順位を付け、パッチを適用します。 この取り組みにより、Kubernetes がすべての人にとって安全であることが保証され、AKS では、脆弱性に迅速にパッチを適用して対応し、お客様の安全を維持することができます。 Kubernetes に加えて、Microsoft は Envoy、コンテナー ランタイム、その他多くのオープンソース プロジェクトなどの製品におけるソフトウェアの脆弱性に関する事前通知を受け取るよう登録しました。

Microsoft は、静的分析を使用してコンテナー イメージをスキャンし、Kubernetes コンテナーおよび Microsoft が管理するコンテナーの脆弱性と不足している更新プログラムを検出します。 修正プログラムが利用できる場合、スキャナーによって更新とリリースのプロセスが自動的に開始されます。

Microsoft では、自動スキャンに加えて、スキャナーでは認識されない脆弱性を次の方法で検出して更新します。

• Microsoft は、すべての AKS プラットフォームで独自の監査、侵入テスト、脆弱性検出を行います。 Microsoft 内部の専門チームと信頼できるサード パーティ セキュリティ ベンダーは、独自に攻撃を調査しています。
• Microsoft は、複数の脆弱性報奨プログラムを通じて、セキュリティ研究コミュニティと積極的に連携しています。 専用の Microsoft Azure 報奨金プログラムでは、毎年発見された最大のクラウド脆弱性に対して支払う多額の報奨金を用意しています。
• Microsoft では、脆弱性を一般公開する前に、脆弱性、セキュリティ研究、更新プログラムを共有する他の業界やオープンソース ソフトウェア パートナーと連携します。 この連携の目的は、脆弱性が一般に公表される前に、インターネット インフラストラクチャの大部分を更新することです。 場合によっては、Microsoft が検出した脆弱性をこのコミュニティに提供することもあります。
• Microsoft のセキュリティ コラボレーションは、さまざまなレベルで行われます。 場合によっては、組織がサインアップして、Kubernetes や Docker などの製品のソフトウェアの脆弱性に関するプレリリース通知を受け取るプログラムを通じて正式に発生することがあります。 また、Linux カーネル、コンテナー ランタイム、仮想化テクノロジなど、多くのオープン ソース プロジェクトとの連携により、コラボレーションが非公式に行われることもあります。

ワーカー ノード

Linux ノード

夜間の正規 OS セキュリティ更新プログラムは、AKS では既定でオフになっています。 これらを明示的に有効にするには、unmanagedチャネルを使用します。

unmanaged チャネルを使用している場合は、夜間の正規のセキュリティ更新プログラムがノード上の OS に適用されます。 クラスタのノードの作成に使用されるノードイメージは変更されません。 新しい Linux ノードがクラスターに追加された場合は、元のイメージを使用してノードが作成されます。 この新しいノードは、毎晩実行される自動評価中に利用可能なすべてのセキュリティとカーネルの更新プログラムを受け取りますが、すべてのチェックと再起動が完了するまでパッチは適用されません。 ノード イメージのアップグレードを使用して、クラスターで使用されているノード イメージをチェックして更新することもできます。 ノード イメージのアップグレードに関する詳細については、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」を参照してください。

以外の unmanaged を使用する AKS クラスターでは、自動アップグレード プロセスは無効になります。

AKS Automatic の場合、既定のシステム ノード プールは AKS によって管理され、NodeImage アップグレード モデルを使用して、日常的な手動介入を必要とせずにノードを最新の状態に保ちます。

Windows Server ノード

Windows Server ノードの場合、Windows Update によって最新の更新プログラムが実行されて適用されるわけではありません。 定期的なWindows更新プログラムのリリース サイクルと独自の更新管理プロセスを中心に、AKS クラスター Windows Serverノード プールのアップグレードをスケジュールします。 このアップグレード プロセスでは、最新の Windows Server イメージと修正プログラムを実行するノードが作成されて、古いノードが削除されます。 このプロセスの詳細については、AKS でのノード プールのアップグレードに関するページを参照してください。

Windows Server ノードは、主に Standard クラスターまたは特殊なワークロードの選択です。 AKS Automatic では、システム ノード プールAzure Linux が使用されます。

脆弱性の分類方法

Microsoft は、適切な既定値を設定し、セキュリティを強化した構成とマネージド コンポーネントを提供することに加えて、OS、コンテナー、Kubernetes、ネットワーク レイヤーを含むスタック全体のセキュリティ強化に多額の投資を行っています。 これらの取り組みを組み合わせることで、脆弱性の影響と可能性を軽減できます。

AKS チームは、Kubernetes の脆弱性スコアリング システムに従って脆弱性を分類しています。 分類では、AKS の構成やセキュリティ強化など、多くの要因が考慮されます。 このアプローチと、AKS のセキュリティへの投資の結果として、AKS の脆弱性の分類は他の分類ソースとは異なる場合があります。

次の表では、脆弱性の重大度カテゴリについて説明します。

脆弱性の更新方法

AKS は、"ベンダーの修正プログラム" を含む共通脆弱性および露出 (CVE) に毎週パッチを適用しています。 修正プログラムがない CVE は、修復できるようになるまでベンダーの修正プログラムを待機しています。 修正されたコンテナー イメージは、次の対応する仮想ハード ディスク (VHD) ビルドにキャッシュされます。これには、更新された Ubuntu/Azure Linux/Windows のパッチが適用された CVE も含まれます。 更新された VHD を実行している限り、コンテナー イメージ CVE を 30 日以上経過したベンダーの修正プログラムで実行していないはずです。

VHD の OS ベースの脆弱性の場合、AKS は既定でノード イメージ VHD の更新プログラムにも依存するため、セキュリティ更新プログラムには毎週のノード イメージ リリースが付属しています。 アンマネージドに切り替えない限り、無人アップグレードは無効になります。これは、リリースがグローバルであるためお勧めしません。

AKS 自動では、マネージド システム ノード プールと自動クラスター アップグレード チャネルを使用して、手動で行う必要があるパッチ管理の量を減らします。 つまり、プラットフォームは、すべてのノードとコントロール プレーンの更新を自分で調整する必要なく、クラスターを現在のサポートされているバージョンに近づける役割を担います。

更新プログラムのリリース タイムライン

Microsoft の目標は、検出された脆弱性を、それらによって生じるリスクに適した期間内に軽減することです。 Microsoft Azure FedRAMP High Provisional Authorization to Operate (P-ATO) には、監査スコープに AKS が含まれており、承認されています。 FedRAMP Continuous Monitoring Strategy Guide および FedRAMP の Low、Moderate、High の Security Control ベースラインでは、既知の脆弱性をその重大度レベルに応じて特定の期間内に是正することが求められています。 FedRAMP RA-5d に規定されているとおり。

脆弱性と更新プログラムの通知方法

通常、Microsoft では、AKS の新しいパッチ バージョンのリリースについて広くお知らせしていません。 しかし、Microsoft では、AKS でタイムリーにサポートできるように、利用可能な CVE パッチを常に監視および検証しています。 重要なパッチが見つかった場合、またはユーザー アクションが必要な場合、Microsoft は GitHub で、CVE の問題の詳細を投稿し、更新しています。

AKS Automatic の場合、クラスターはマネージド アップグレード動作と運用環境対応の既定値に従うため、これらの更新は顧客の介入を減らすことを目的とします。 AKS Standard の場合、ユーザーはアップグレードを自分で監視して適用する必要がある可能性が高くなります。

セキュリティ レポート

お客様は、脆弱性レポートを作成することで、Microsoft Security Response Center (MSRC) にセキュリティの問題を報告できます。

ツールにログインせずにレポートを送信する場合は、secure@microsoft.com に電子メールをお送りください。 可能であれば、PGP キーを使用してメッセージを暗号化してください。PGP キーは、Microsoft Security Response Center の PGP キーのページからダウンロードできます。

24 時間以内に応答が返されます。 何らかの理由で応答がなかった場合、メールでフォローアップして、元のメッセージを私たちが受信したことを確認してください。 詳細については、Microsoft Security Response Center にアクセスしてください。

発生する可能性のある問題の性質と範囲をよりよく理解するために、求められている次の情報を (提供できる限り) 含めてください。

• 問題の種類 (バッファー オーバーフロー、SQL インジェクション、クロスサイト スクリプティングなど)
• 問題の発生に関連するソース ファイルの完全なパス
• 影響を受けたソース コードの場所 (タグ/ブランチ/コミットまたは直接 URL)
• 問題の再現に必要な特別な設定
• 問題を再現する手順
• 概念実証または悪用コード (可能な場合)
• イシューの影響 (攻撃者がイシューを悪用する方法など)

この情報は、報告されたセキュリティの問題をより迅速にトリアージするのに役立ちます。

報告を行ってバグ報奨金を得るには、より詳細なレポートほど報奨金の賞金が高くなる可能性があります。 実施中のプログラムの詳細については、Microsoft バグ報奨金プログラムを参照してください。

Policy

Microsoft は、組織的な脆弱性の公開の原則に従っています。

次のステップ

ほとんどの運用ワークロードでは、AKS Automatic から始めます。