Windows 컨테이너 보안
적용 대상: 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 컨테이너보다 높은 수준의 격리를 제공하며 강력한 보안 경계로 간주됩니다. 하이퍼바이저 격리 컨테이너는 초경량 VM에 래핑된 Windows Server 컨테이너로 구성되며 Microsoft의 하이퍼바이저를 통해 호스트 OS와 함께 실행됩니다. 하이퍼바이저는 호스트와 다른 컨테이너 사이에 매우 강력한 보안 경계를 포함하는 하드웨어 수준 격리를 제공합니다. 익스플로잇이 Windows Server 컨테이너를 빠져나가더라도 하이퍼바이저 격리 VM에 격리됩니다.
Windows Server 컨테이너 또는 Linux 컨테이너 모두 Microsoft가 생각하는 강력한 보안 경계를 제공하지 않으며 악의적인 다중 테넌트 시나리오에서 사용해서는 안 됩니다. 악성 컨테이너 프로세스가 호스트 또는 다른 테넌트와 상호 작용하지 않도록 컨테이너를 전용 VM으로 제한해야 합니다. 하이퍼바이저 격리를 통해 이러한 수준의 분리를 지원하는 동시에 기존 VM에 비해 몇 가지 성능 향상 기능을 제공합니다. 따라서 악의적인 다중 테넌트 시나리오에서는 하이퍼바이저 격리 컨테이너를 선택하는 것이 좋습니다.
컨테이너 보안 서비스 기준
Microsoft는 모든 Windows 컨테이너 유형의 설정된 격리 경계를 깨는 모든 익스플로잇 및 이스케이프를 패치하기 위해 노력하고 있습니다. 그러나 보안 경계를 깨는 익스플로잇만 MSRC(Microsoft 보안 대응 센터) 프로세스를 통해 처리됩니다. 하이퍼바이저 격리 컨테이너만 보안 경계를 제공하고 프로세스 격리 컨테이너는 제공하지 않습니다. 프로세스 격리 컨테이너 이스케이프에 대한 버그를 생성하는 유일한 방법은 비 관리자 프로세스가 호스트에 액세스할 수 있는 경우입니다. 익스플로잇이 관리자 프로세스를 사용하여 컨테이너를 이스케이프하는 경우 Microsoft는 이 프로세스를 비 보안 버그로 간주하고 일반 서비스 프로세스에 따라 패치를 적용합니다. 익스플로잇이 비 관리자 프로세스를 사용하여 보안 경계를 뚫는 작업을 수행하는 경우 Microsoft는 설정된 보안 서비스 기준에 따라 이를 조사합니다.
무엇이 다중 테넌트 워크로드를 악의적으로 만들까요?
다중 테넌트 환경은 여러 워크로드가 공유 인프라 및 리소스에서 작동할 때 존재합니다. 인프라에서 실행되는 하나 이상의 워크로드를 신뢰할 수 없는 경우 다중 테넌트 환경은 악의적인 것으로 간주됩니다. Windows Server 및 Linux 컨테이너는 모두 호스트 커널을 공유하므로 단일 컨테이너에서 수행된 모든 익스플로잇은 공유 인프라에서 실행되는 다른 모든 워크로드에 영향을 줄 수 있습니다.
예를 들어 Pod 보안 정책, AppArmor 및 RBAC(역할 기반 액세스 제어)를 사용하여 익스플로잇이 발생할 가능성을 줄이는 조치를 수행할 수 있지만 공격자에 대해 보장된 보호를 제공하지는 않습니다. 다중 테넌트 시나리오의 경우 클러스터 격리 모범 사례를 따르는 것이 좋습니다.
ContainerAdmin 및 ContainerUser 사용자 계정을 사용하는 경우
Windows Server 컨테이너는 각각 고유한 특정 목적을 가진 두 개의 기본 사용자 계정인 ContainerUser와 ContainerAdministrator를 제공합니다. ContainerAdministrator 계정을 사용하면 관리 목적으로 컨테이너를 사용하여 서비스 및 소프트웨어(예: 컨테이너 내에서 IIS 사용)를 설치하고, 구성을 변경하고, 새 계정을 만들 수 있습니다. 이러한 작업은 사용자 지정 온-프레미스 배포 환경에서 실행될 수 있는 여러 IT 시나리오에서 중요합니다.
ContainerUser 계정은 Windows에서 관리자 권한이 필요하지 않은 다른 모든 시나리오에 대해 존재합니다. 예를 들어 Kubernetes에서 사용자가 ContainerAdministrator이고 hostvolumes가 Pod에 탑재되도록 허용된 경우 사용자는 .ssh 폴더를 탑재하고 공개 키를 추가할 수 있습니다. 이 예에서 ContainerUser는 적합하지 않습니다. 이는 호스트와 상호 작용할 필요가 없는 애플리케이션만을 위해 설계된 제한된 사용자 계정입니다. ContainerUser 계정을 통해 애플리케이션을 실행하는 다중 테넌트 환경에 Windows Server 컨테이너를 배포하는 것이 좋습니다. 다중 테넌트 환경에서는 항상 최소 권한 원칙을 따르는 것이 가장 좋습니다. 공격자가 워크로드를 손상시키면 공유 리소스와 인접 워크로드가 영향을 받을 가능성도 낮아지기 때문입니다. 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 아티팩트 레지스트리) 이미지를 사용하여 IIS 웹 애플리케이션을 호스팅하는 ENTRYPOINT 경우 컨테이너는 다음과 같습니다"C:\\ServiceMonitor.exe", "w3svc". 이 도구를 사용하여 IIS 서비스를 구성한 다음 서비스를 모니터링하여 서비스가 실행 중이고 종료되는지 기본, 어떤 이유로든 서비스가 중지되는 경우 컨테이너를 중지할 수 있습니다. 기본적으로 IIS 서비스 및 웹 애플리케이션은 컨테이너 내의 낮은 권한 계정으로 실행되지만 서비스 모니터 도구에는 서비스를 구성하고 모니터링하기 위한 관리 권한이 필요합니다.