Windows コンテナーのセキュリティ保護
適用対象: Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016
コンテナーはイメージのサイズが小さくなっており、ホストに依存して各種リソースに制限付きアクセスを提供するのに役立ちます。 ホストが特定の一連のアクションを実行するために必要な機能を提供できることをコンテナーが認識している場合、コンテナーは基本イメージに関連するソフトウェアを含める必要はありません。 ただし、発生するリソース共有の範囲は、コンテナーのパフォーマンスとセキュリティの両方に大きな影響を与える可能性があります。 共有されているリソースが多すぎる場合は、アプリケーションがホスト上のプロセスとして実行される場合もあります。 リソースの共有が少なすぎると、コンテナーは VM と区別できなくなります。 どちらの構成も多くのシナリオに適用できますが、コンテナーを使用するほとんどのユーザーは通常、途中で何かを選択します。
Windows コンテナーのセキュリティは、ホストとの共有の度合いから派生します。 コンテナーのセキュリティ境界は、コンテナーをホストから分離する分離メカニズムによって構成されます。 最も重要なのは、これらの分離メカニズムによって、コンテナー内のどのプロセスがホストと対話できるかを定義することです。 コンテナーの設計によって管理者特権 (管理者) プロセスがホストと対話できる場合、Microsoft はこのコンテナーに堅牢なセキュリティ境界があるとは見なしません。
Windows Server コンテナーと Linux コンテナー
プロセス分離 Windows Server コンテナーと Linux コンテナーは、同様の分離度を共有します。 どちらの種類のコンテナーでも、開発者は、ホスト上の昇格されたプロセスを介して実行できる攻撃は、コンテナー内の昇格されたプロセスを介して実行することも可能であると想定する必要があります。 両方とも、それぞれのホスト カーネルによって提供されるプリミティブ機能を介して動作します。 コンテナー イメージは、ホスト カーネルによって提供される API を利用するユーザー モード バイナリを含むビルドされます。 ホスト カーネルは、ユーザー空間で実行されている各コンテナーに同じリソースの分離と管理機能を提供します。 カーネルが侵害された場合、そのカーネルを共有するすべてのコンテナーも同じになります。
Linux および Windows サーバー コンテナーの基本的な設計では、柔軟性のためにセキュリティが交換されます。 Windows Server および Linux コンテナーは、OS によって提供されるプリミティブ コンポーネントの上に構築されます。 これにより、コンテナー間でリソースと名前空間を柔軟に共有できますが、さらに複雑さが増し、悪用の扉が開きます。 大まかに言えば、カーネルは、敵対的なマルチテナント ワークロードに対する十分なセキュリティ境界であるとは見なされません。
ハイパーバイザー分離コンテナーを使用したカーネル分離
ハイパーバイザー分離コンテナーは、プロセスで分離された Windows Server または Linux コンテナーよりも高度な分離を提供し、堅牢なセキュリティ境界と見なされます。 ハイパーバイザー分離コンテナーは、Ultralight VM にラップされた Windows Server コンテナーで構成され、Microsoft のハイパーバイザー経由でホスト OS と共に実行されます。 ハイパーバイザーは、ホストと他のコンテナーの間の非常に堅牢なセキュリティ境界を含むハードウェア レベルの分離を提供します。 悪用によって Windows Server コンテナーがエスケープされた場合でも、ハイパーバイザー分離 VM 内に含まれます。
Windows Server コンテナーも Linux コンテナーも、Microsoft が堅牢なセキュリティ境界と見なしているものを提供せず、敵対的なマルチテナント シナリオでは使用しないでください。 悪意のあるコンテナー プロセスがホストまたは他のテナントと対話しないように、コンテナーを専用 VM に限定する必要があります。 ハイパーバイザーの分離により、この程度の分離が可能になり、従来の VM よりもパフォーマンスが向上します。 そのため、危険性のあるマルチテナントのシナリオでは、コンテナーとしてハイパーバイザー分離コンテナーを選択することを強くお勧めします。
コンテナー のセキュリティ サービスの条件
Microsoft は、Windows コンテナーの種類の確立された分離境界を破る、すべての悪用とエスケープにパッチを適用することに取り組んでいます。 ただし、セキュリティ境界を破る悪用のみが、Microsoft Security Response Center (MSRC) プロセスを介して処理されます。 ハイパーバイザー分離コンテナーのみがセキュリティ境界を提供し、プロセス分離コンテナーは提供しません。 プロセス分離コンテナー エスケープのバグを生成する唯一の方法は、管理者以外のプロセスがホストにアクセスできる場合です。 悪用で管理者プロセスを使用してコンテナーをエスケープする場合、Microsoft は、コンテナーをセキュリティ以外のバグと見なし、通常のサービス プロセスに従って修正プログラムを適用します。 悪用で管理者以外のプロセスを使用してセキュリティ境界に違反するアクションを実行する場合、Microsoft は 確立されたセキュリティ サービス条件に従って調査します。
マルチテナント ワークロードが敵対的になる理由
マルチテナント環境は、複数のワークロードが共有インフラストラクチャとリソースで動作している場合に存在します。 インフラストラクチャで実行されている 1 つ以上のワークロードを信頼できない場合、マルチテナント環境は敵対的と見なされます。 Windows Server コンテナーと Linux コンテナーの両方がホスト カーネルを共有するため、1 つのコンテナーで実行されるすべての悪用が、共有インフラストラクチャで実行されている他のすべてのワークロードに影響を与える可能性があります。
ポッドのセキュリティ ポリシー、AppArmor、ロールベースのアクセス制御 (RBAC) を使用するなどして悪用が発生する可能性を減らす手順を実行できますが、攻撃者に対する保護は保証されません。 マルチテナント シナリオのクラスター分離 に関する のベスト プラクティスに従うことをお勧めします。
ContainerAdmin ユーザー アカウントと ContainerUser ユーザー アカウントを使用する場合
Windows Server コンテナーには、ContainerUser と ContainerAdministrator という 2 つの既定のユーザー アカウントが用意されており、それぞれに固有の目的があります。 ContainerAdministrator アカウントを使用すると、サービスとソフトウェアのインストール (コンテナー内での IIS の有効化など)、構成の変更、新しいアカウントの作成などの管理目的でコンテナーを使用できます。 これらのタスクは、カスタムのオンプレミスのデプロイ環境で実行される可能性がある多くの IT シナリオで重要です。
ContainerUser アカウントは、Windows の管理者特権が必要ない他のすべてのシナリオに対して存在します。 たとえば、Kubernetes でユーザーが ContainerAdministrator で、hostvolumes をポッドにマウントすることが許可されている場合、ユーザーは .ssh フォルダーをマウントして公開キーを追加できます。 ContainerUser の場合、この例は不可能です。 これは、ホストと対話する必要のないアプリケーション専用に設計された制限付きユーザー アカウントです。 アプリケーションが ContainerUser アカウントを介して実行されるマルチテナント環境に Windows サーバー コンテナーをデプロイすることを強くお勧めします。 マルチテナント環境では、攻撃者がワークロードを侵害した場合、共有リソースと隣接するワークロードも同様に影響を受ける可能性が低いため、最小限の特権の原則に従うことが常に最善です。 ContainerUser アカウントでコンテナーを実行すると、環境全体が侵害される可能性が大幅に低下します。 ただし、これは依然として堅牢なセキュリティ境界を提供しないため、セキュリティが懸念される場合は、ハイパーバイザー分離コンテナーを使用する必要があります。
ユーザー アカウントを変更するには、dockerfile で USER ステートメントを使用できます。
USER ContainerUser
または、新しいユーザーを作成することもできます。
RUN net user username ‘<password>’ /ADD
USER username
Windows サービス
以前 NT サービスと呼ばれる Microsoft Windows サービスを使用すると、独自の Windows セッションで実行される実行時間の長い実行可能アプリケーションを作成できます。 これらのサービスは、オペレーティング システムの起動時に自動的に開始でき、一時停止および再起動でき、ユーザー インターフェイスは表示されません。 ログオンしているユーザーまたは既定のコンピューター アカウントとは異なる特定のユーザー アカウントのセキュリティ コンテキストでサービスを実行することもできます。
Windows サービスとして実行されるワークロードをコンテナー化してセキュリティで保護する場合は、注意する必要がある追加の考慮事項がいくつかあります。 まず、サービスがバックグラウンド プロセスとして実行されるため、コンテナーの ENTRYPOINT はワークロードになりません。通常、ENTRYPOINT は、サービス モニター) やログ モニター ) などのツールします。 次に、ワークロードが動作するセキュリティ アカウントは、dockerfile の USER ディレクティブではなく、サービスによって構成されます。 Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartNameを実行すると、サービスが実行されるアカウントを確認できます。
たとえば、ASP.NET (Microsoft Artifact Registry) イメージを使用して IIS Web アプリケーションをホストする場合、コンテナーの ENTRYPOINT は "C:\\ServiceMonitor.exe", "w3svc"。 このツールを使用して IIS サービスを構成し、サービスが何らかの理由で停止した場合にコンテナーを停止して、サービスが実行および終了していることを確認するためにサービスを監視できます。 既定では、IIS サービスと Web アプリケーションはコンテナー内の低い特権アカウントで実行されますが、サービス モニター ツールでは、サービスを構成および監視するための管理特権が必要です。