Windows コンテナーのセキュリティ保護
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016
コンテナーはイメージのサイズが小さくなっており、ホストに依存して各種リソースに制限付きアクセスを提供するのに役立ちます。 特定の一連のアクションを実行するのに必要な機能がホストによって提供されることをコンテナー側が把握している場合、関連するソフトウェアをそのコンテナーの基本イメージに含める必要はありません。 ただし、発生するリソース共有の範囲は、コンテナーのパフォーマンスとセキュリティの両方に大きな影響を与える可能性があります。 共有されるリソースが多すぎる場合は、アプリケーションを単にホスト上のプロセスとして実行したほうがよいでしょう。 リソースの共有が少なすぎる場合、コンテナーは VM と区別できなくなります。 どちらの構成も多くのシナリオに適用できますが、コンテナーを使用するほとんどの人は、一般的にその中間を選択します。
Windows コンテナーのセキュリティは、そのホストでどの程度の共有が発生しているかに左右されます。 コンテナーのセキュリティ境界は、ホストからコンテナーを分離する分離メカニズムによって構成されます。 最も重要なのは、これらの分離メカニズムによって、コンテナー内のプロセスとホストの対話方法が定義されている点です。 管理者特権 (管理者) プロセスとホストの対話が許可されるようにコンテナーが設計されている場合、Microsoft ではこのコンテナーに堅牢なセキュリティ境界があるとは見なしません。
Windows Server コンテナーと Linux コンテナーの比較
プロセス分離された Windows Server コンテナーと Linux コンテナーでは、同じ程度の分離を共有します。 どちらの種類のコンテナーでも、開発者は、ホスト上で管理者特権プロセスを介して実行される可能性があるすべての攻撃は、コンテナー内でも管理者特権プロセスを介して実行される可能性があると想定する必要があります。 どちらも、それぞれのホスト カーネルによって提供されるプリミティブ機能を介して動作します。 コンテナー イメージは、ホスト カーネルによって提供される API を利用するユーザー モード バイナリが含まれるようビルドされます。 ホスト カーネルによって、ユーザー空間で実行されている各コンテナーに同じリソース分離機能と管理機能が提供されます。 そのカーネルが侵害を受けた場合、そのカーネルが共有されるすべてのコンテナーも侵害を受けます。
Linux コンテナーと Windows Server コンテナーの基本的な設計は、柔軟性を高めるためにセキュリティを犠牲にしています。 Windows Server コンテナーと Linux のコンテナーは、OS によって提供されるプリミティブ コンポーネントをベースに構築されています。 これにより、コンテナー間でリソースと名前空間を共有するための柔軟性が得られますが、より複雑になり侵害を受ける可能性が高まります。 大まかに言えば、Microsoft はカーネルが悪意のあるマルチテナント ワークロードに対する十分なセキュリティ境界であるとは考えていません。
ハイパーバイザー分離されたコンテナーを使用したカーネルの分離
ハイパーバイザー分離されたコンテナーには、プロセス分離された Windows Server コンテナーや Linux コンテナーよりも高度な分離が提供されており、堅牢なセキュリティ境界と見なされています。 ハイパーバイザー分離されたコンテナーは、超軽量な 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 Server コンテナーをデプロイすることを強くお勧めします。 マルチテナント環境では、攻撃者によってワークロードが侵害を受けた場合に、共有リソースと隣接するワークロードが影響を受ける可能性を低く抑えるために、常に最小限の特権の原則に従うことをお勧めします。 ContainerUser アカウントを使用してコンテナーを実行すると、環境全体が危険にさらされる可能性が大幅に減少します。 ただし、これでは堅牢なセキュリティ境界が提供されないため、セキュリティに懸念がある場合は、ハイパーバイザー分離されたコンテナーを使用する必要があります。
ユーザー アカウントを変更するために、dockerfile で USER ステートメントを使用できます。
USER ContainerUser
新しいユーザーを作成することもできます。
RUN net user username ‘<password>’ /ADD
USER username
Windows サービス
Microsoft Windows サービス (旧 NT サービス) を使用すると、Microsoft Windows サービス自体の Windows セッションで長時間にわたって実行されるアプリケーションを作成できます。 これらのサービスは、オペレーティング システムの起動時に自動的に開始したり、一時停止および再開したりできますが、ユーザー インターフェイスは表示されません。 また、ログオン ユーザーや既定のコンピューター アカウントとは異なる、特定のユーザー アカウントのセキュリティ コンテキストでサービスを実行することもできます。
Windows サービスとして実行されるワークロードをコンテナー化してセキュリティで保護する場合は、注意する必要がある追加の考慮事項がいくつかあります。 まず、サービスはバックグラウンド プロセスとして実行されるため、コンテナーの ENTRYPOINT はワークロードにはなりません。通常、ENTRYPOINT はサービス モニターやログ モニターなどのツールになります。 次に、ワークロードが動作するセキュリティ アカウントは、dockerfile の USER ディレクティブではなく、サービスによって構成されます。 Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName を実行すると、サービスが実行されるアカウントを確認できます。
たとえば、ASP.NET (Microsoft アーティファクト レジストリ) イメージを使用して IIS Web アプリケーションをホストする場合、コンテナーの ENTRYPOINT は "C:\\ServiceMonitor.exe", "w3svc" です。 このツールを使用して IIS サービスを構成し、サービスが何らかの理由で停止した場合にコンテナーを停止して、サービスが実行および終了していることを確認するためにサービスを監視できます。 既定では、IIS サービスと Web アプリケーションはコンテナー内の低い特権アカウントで実行されますが、サービス モニター ツールでは、サービスを構成および監視するための管理特権が必要です。