Azure Kubernetes Service (AKS) の脆弱性の管理
脆弱性の管理には、組織のシステムとソフトウェアに存在するあらゆるセキュリティ脆弱性の検出、評価、軽減、報告が含まれます。 脆弱性の管理は、お客様と Microsoft の共同責任です。
この記事では、Microsoft が Azure Kubernetes Service (AKS) クラスターのセキュリティ脆弱性とセキュリティ更新プログラム (パッチとも呼ばれます) を管理する方法について説明します。
脆弱性の検出方法
Microsoft は、次のコンポーネントの脆弱性と不足しているセキュリティ更新プログラムを特定し、パッチを適用します。
AKS コンテナー イメージ
Ubuntu オペレーティング システム 18.04 および 22.04 ワーカー ノード: 利用可能なすべてのセキュリティ更新プログラムが適用された OS ビルドが Canonical から Microsoft に提供されます。
Windows Server 2022 OS ワーカー ノード: Windows Server オペレーティング システムには、毎月第 2 火曜日にパッチが適用されます。 SLA は、サポート契約および重大度と同一である必要があります。
Azure Linux OS ノード: Azure Linux は、利用可能なすべてのセキュリティ更新プログラムが適用された OS ビルドを AKS に提供します。
AKS コンテナー イメージ
Cloud Native Computing Foundation (CNCF) は、AKS で実行されるほとんどのコードを所有し保守していますが、Microsoft は AKS にデプロイするオープンソース パッケージをビルドする責任を担っています。 その責任には、ビルド、スキャン、署名、検証、修正プログラム プロセスの完全な所有権と、コンテナー イメージ内のバイナリの制御権が伴います。 Microsoft は、AKS にデプロイされるオープンソース パッケージをビルドする責任を担うことで、バイナリによるソフトウェア サプライ チェーンを確立し、必要に応じてソフトウェアにパッチを適用することができます。
Microsoft は、広範な Kubernetes エコシステムで活動し、より広範な CNCF コミュニティでクラウドネイティブ コンピューティングの将来を構築できるよう支援しています。 この作業により、世界中のすべての Kubernetes リリースの品質が保証されるだけでなく、数年間にわたって AKS で新しい Kubernetes リリースを運用環境に迅速に移行できるようになります。 場合によっては、他のクラウド プロバイダーよりも数か月早く運用化できます。 Microsoft は、Kubernetes セキュリティ組織の他の業界パートナーと共同で作業を行っています。 たとえば、セキュリティ対応委員会 (SRC) では、一般に公開される前に、差し止められたセキュリティの脆弱性を受け取り、優先順位を付け、パッチを適用します。 この取り組みにより、Kubernetes がすべての人にとって安全であることが保証され、AKS では、脆弱性に迅速にパッチを適用して対応し、お客様の安全を維持することができます。 Microsoft は、Kubernetes に加えて、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 クラスターの場合、無人アップグレード プロセスは無効になっています。
Windows Server ノード
Windows Server ノードの場合、Windows Update によって最新の更新プログラムが実行されて適用されるわけではありません。 定期的な Windows Update リリース サイクルとお客様独自の更新プログラム管理プロセスの前後に、AKS クラスターでの Windows Server ノード プールのアップグレードをスケジュールします。 このアップグレード プロセスでは、最新の Windows Server イメージと修正プログラムを実行するノードが作成されて、古いノードが削除されます。 このプロセスの詳細については、AKS でのノード プールのアップグレードに関するページを参照してください。
脆弱性の分類方法
Microsoft は、適切な既定値を設定し、セキュリティを強化した構成とマネージド コンポーネントを提供することに加えて、OS、コンテナー、Kubernetes、ネットワーク レイヤーを含むスタック全体のセキュリティ強化に多額の投資を行っています。 これらの取り組みを組み合わせることで、脆弱性の影響と可能性を軽減できます。
AKS チームは、Kubernetes の脆弱性スコアリング システムに従って脆弱性を分類しています。 分類では、AKS の構成やセキュリティ強化など、多くの要因が考慮されます。 このアプローチと、AKS のセキュリティへの投資の結果として、AKS の脆弱性の分類は他の分類ソースとは異なる場合があります。
次の表では、脆弱性の重大度カテゴリについて説明します。
| 重大度 | 説明 |
|---|---|
| 重大 | 認証されていないリモートの攻撃者によってすべてのクラスターで簡単に悪用され、システム全体のセキュリティが侵害されることにつながる脆弱性。 |
| 高 | 多くのクラスターで簡単に悪用される可能性があり、機密性、整合性、可用性の損失につながる脆弱性。 |
| Medium | 一部のクラスターで悪用される可能性があり、機密性、整合性、または可用性の損失が、一般的な構成、悪用自体の難易度、必要なアクセス権、ユーザーの操作で制限される脆弱性。 |
| 低 | その他のすべての脆弱性。 悪用の可能性が低いか、悪用の結果が制限されます。 |
脆弱性の更新方法
AKS は、"ベンダーの修正プログラム" を含む共通脆弱性および露出 (CVE) に毎週パッチを適用しています。 修正プログラムがない CVE は、修復できるようになるまでベンダーの修正プログラムを待機しています。 修正されたコンテナー イメージは、次の対応する仮想ハード ディスク (VHD) ビルドにキャッシュされます。これには、更新された Ubuntu/Azure Linux/Windows のパッチが適用された CVE も含まれます。 更新された VHD を実行している限り、コンテナー イメージ CVE を 30 日以上経過したベンダーの修正プログラムで実行していないはずです。
VHD 内の OS ベースの脆弱性については、AKS では既定でノード イメージ VHD の更新プログラムも使用されるため、セキュリティ更新プログラムはノード イメージ の毎週のリリースで提供されます。 無人アップグレードは、アンマネージドに切り替えない限り無効ですが、そのリリースはグローバルであるため、推奨されません。
更新プログラムのリリース タイムライン
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 の問題の詳細を投稿し、更新しています。
セキュリティ レポート
お客様は、脆弱性レポートを作成することで、Microsoft Security Response Center (MSRC) にセキュリティの問題を報告できます。
ツールにログインせずにレポートを送信する場合は、secure@microsoft.com に電子メールをお送りください。 可能であれば、PGP キーを使用してメッセージを暗号化してください。PGP キーは、Microsoft Security Response Center の PGP キーのページからダウンロードできます。
24 時間以内に応答が返されます。 何らかの理由で応答がなかった場合、メールでフォローアップして、元のメッセージを私たちが受信したことを確認してください。 詳細については、Microsoft Security Response Center にアクセスしてください。
発生する可能性のある問題の性質と範囲をよりよく理解するために、求められている次の情報を (提供できる限り) 含めてください。
- 問題の種類 (バッファー オーバーフロー、SQL インジェクション、クロスサイト スクリプティングなど)
- イシューの兆候に関連するソース ファイルの完全パス
- 影響を受けたソース コードの場所 (タグ/ブランチ/コミットまたは直接 URL)
- イシューの再現に必要な特別な構成
- イシューを再現するための詳細な手順
- 概念実証または悪用コード (可能な場合)
- イシューの影響 (攻撃者がイシューを悪用する方法など)
この情報は、報告されたセキュリティの問題をより迅速にトリアージするのに役立ちます。
報告を行ってバグ報奨金を得るには、より詳細なレポートほど報奨金の賞金が高くなる可能性があります。 実施中のプログラムの詳細については、Microsoft バグ報奨金プログラムを参照してください。
ポリシー
Microsoft は、組織的な脆弱性の公開の原則に従っています。
次のステップ
アップグレードの概要については、「Azure Kubernetes Service クラスターとノード プールのアップグレード」を参照してください。
Azure Kubernetes Service