保護 Windows 容器
適用於：Windows Server 2022、Windows Server 2019、Windows Server 2016
容器會將其縮減的映像大小提供給他們可以依賴主機來提供對各種資源的有限存取權。 如果容器知道主機將能夠提供執行特定動作集所需的功能，則容器不需要在其基底映像中包含相關的軟體。 不過，發生的資源分享範圍可能會對容器的效能和安全性產生重大影響。 如果共用太多資源，則應用程式可能也會像主機上的進程一樣執行。 如果資源分享太少，則容器會變得無法從 VM 中區分。 這兩個組態都適用於許多案例，但大部分使用容器的人通常會選擇中間專案。
Windows 容器的安全性衍生自其主機所發生的共用程度。 容器的安全性界限是由將容器與主機分開的隔離機制所構成。 最重要的是，這些隔離機制會定義容器中的哪些進程可以與主機互動。 如果容器的設計允許提升許可權的 （admin） 程式與主機互動，則 Microsoft 不會將此容器視為具有強固的安全性界限。
Windows Server 容器與 Linux 容器
進程隔離的 Windows Server 容器和 Linux 容器會共用類似的隔離程度。 針對這兩種容器類型，開發人員必須假設任何可透過主機上提升許可權進程執行的攻擊，也可以透過容器中的提升許可權進程來執行。 兩者都透過各自主機核心所提供的基本功能運作。 容器映像的建置包含利用主機核心所提供 API 的使用者模式二進位檔。 主機核心會將相同的資源隔離和管理功能提供給在用戶空間中執行的每個容器。 如果核心遭到入侵，則每個容器都會共用該核心。
Linux 和 Windows 伺服器容器的基本設計可讓安全性獲得彈性。 Windows Server 和 Linux 容器建置在 OS 所提供的基本元件之上。 這樣做可提供在容器之間共用資源和命名空間的彈性，但它會增加額外的複雜性，以開啟惡意探索的大門。 廣泛表示， 我們並不認為核心是惡意多租使用者工作負載的足夠安全性界限。
使用 Hypervisor 隔離的容器進行核心隔離
Hypervisor 隔離的容器提供比進程隔離的 Windows Server 或 Linux 容器更高的隔離程度，而且被視為健全的安全性界限。 Hypervisor 隔離的容器是由包裝在 Ultralight VM 中的 Windows Server 容器所組成，然後透過 Microsoft 的 Hypervisor 與主機 OS 一起執行。 Hypervisor 提供硬體層級隔離，其中包含主機與其他容器之間的高度強固安全性界限。 即使惡意探索是逸出 Windows Server 容器，它也會包含在 Hypervisor 隔離的 VM 內。
Windows Server 容器或 Linux 容器都未提供 Microsoft 認為強固的安全性界限，且不應用於惡意的多租使用者案例。 容器必須受限於專用 VM，以防止流氓容器進程與主機或其他租用戶互動。 Hypervisor 隔離可讓您進行這種程度的隔離，同時在傳統 VM 上提供數個效能提升。 因此，強烈建議在惡意的多租使用者案例中，Hypervisor 隔離容器應該是所選擇的容器。
容器安全性維護準則
Microsoft 致力於修補所有惡意探索，並逸出會中斷任何 Windows 容器類型的已建立隔離界限。 不過，只有違反安全性界限的惡意探索會透過 Microsoft 安全性回應中心 （MSRC） 程式提供服務。 只有 Hypervisor 隔離的容器提供安全性界限，而進程隔離的容器則不會。 產生進程隔離容器逸出 Bug 的唯一方法是，如果非系統管理員進程可以取得主機的存取權。 如果惡意探索使用管理程式來逸出容器，則 Microsoft 會將它視為非安全性錯誤，並且會根據一般服務程式加以修補。 如果惡意探索使用非系統管理員程式來執行違反安全性界限的動作，則 Microsoft 會根據 已建立的安全性服務準則來調查它。
多租使用者工作負載的敵意為何？
當多個工作負載在共用基礎結構和資源上作業時，就會有多租用戶環境。 如果無法信任在基礎結構上執行的一或多個工作負載，則多租用戶環境會被視為敵意。 Windows Server 和 Linux 容器都會共用主機核心，因此在單一容器上執行的任何惡意探索都可能會影響在共用基礎結構上執行的其他所有工作負載。
您可以採取步驟來減少惡意探索發生的機會，例如，使用Pod安全策略、AppArmor和角色型訪問控制 （RBAC），但不會提供對攻擊者的保證保護。 建議您遵循任何 多租使用者案例的叢集隔離 最佳做法。
使用 Container 管理員 和 ContainerUser 使用者帳戶的時機
Windows Server 容器提供兩個預設用戶帳戶 ContainerUser 和 Container 管理員 istrator，每個帳戶都有自己的特定用途。 Container 管理員 istrator 帳戶可讓您將容器用於系統管理用途：安裝服務和軟體（例如在容器內啟用 IIS）、進行設定變更，以及建立新的帳戶。 這些工作對於一些可能在自定義內部部署部署環境中執行的IT案例而言很重要。
ContainerUser 帳戶存在於不需要 Windows 中系統管理員許可權的所有其他案例中。 例如，在 Kubernetes 中，如果使用者是 Container 管理員 istrator 和 hostvolumes 可以掛接至 Pod，則使用者可以掛接 .ssh 資料夾並新增公鑰。 因為 ContainerUser 這個範例是不可能的。 這是專為不需要與主機互動的應用程式所設計的受限用戶帳戶。 強烈建議您將 Windows 伺服器容器部署到您的應用程式透過 ContainerUser 帳戶執行的任何多租用戶環境。 在多租用戶環境中，最好遵循最低許可權原則，因為如果攻擊者入侵您的工作負載，則共用資源和鄰近工作負載也有較低的影響機會。 使用 ContainerUser 帳戶執行容器可大幅降低整個環境遭到入侵的機會。 不過，這仍然不提供健全的安全性界限，因此當安全性是考慮時，您應該使用 Hypervisor 隔離的容器。
若要變更使用者帳戶，您可以在 dockerfile 上使用 USER 語句：
USER ContainerUser
或者，您可以建立新的使用者：
RUN net user username ‘<password>’ /ADD
USER username
Windows 服務
Microsoft Windows 服務 (以前稱為 NT 服務) 讓您能夠建立長時間執行的應用程式，並使其在自己的 Windows 工作階段中執行。 當操作系統啟動時，可以自動啟動這些服務、可以暫停和重新啟動，而且不會顯示任何使用者介面。 您也可以在特定使用者帳戶的安全性內容中執行服務，此使用者帳戶不同於登入的使用者帳戶或預設電腦帳戶。
當容器化和保護以 Windows 服務身分執行的工作負載時，有一些其他考慮需要注意。 首先，ENTRYPOINT容器的 不會是工作負載，因為服務會以背景進程的形式執行，通常是ENTRYPOINT服務監視器或記錄監視器之類的工具。 其次，工作負載運作的安全性帳戶將由服務設定，而不是由 dockerfile 中的 USER 指示詞所設定。 您可以執行 Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName來檢查服務將在下執行的帳戶。
例如，使用 ASP.NET （Microsoft 成品登錄） 映像ENTRYPOINT載入 IIS Web 應用程式時，容器的 是 "C:\\ServiceMonitor.exe", "w3svc"。 此工具可用來設定 IIS 服務，然後監視服務，以確保它繼續執行並結束，因此，如果服務因任何原因而停止容器。 根據預設，IIS 服務，因此 Web 應用程式會在容器內的低許可權帳戶下執行，但服務監視工具需要系統管理許可權來設定及監視服務。