Windows PowerShell의 원격 보안 기능 검토

완료됨

기본적으로 Windows PowerShell을 만드는 엔드포인트는 특정 그룹의 멤버에 의한 연결만 허용합니다. Windows Server 2016 및 Windows 10을 시작하여 이러한 그룹에는 원격 관리 사용자 그룹 및 로컬 관리자 그룹이 포함됩니다. AD DS(Active Directory Domain Services) 도메인에서 후자는 도메인에 가입된 모든 컴퓨터에서 로컬 관리자 그룹의 구성원이므로 Domain Admins 도메인 전역 그룹의 구성원도 포함합니다. Windows Server 2016 및 Windows 10 이전에는 기본적으로 로컬 관리자 그룹의 구성원만 PowerShell 원격을 사용할 수 있었습니다. 그러나 기본값을 변경할 수 있습니다. 각 엔드포인트에는 연결할 수 있는 사용자를 정확하게 제어하도록 수정할 수 있는 SACL(시스템 액세스 제어 목록)이 있습니다.

PowerShell Remoting 및 WinRM은 다음 포트에서 수신 대기합니다.

• HTTP: 5985
• HTTPS: 5986

기본 원격 동작은 원격 컴퓨터에 로그인 자격 증명을 위임하는 것이지만, 연결할 때 대체 자격 증명을 지정하는 옵션이 있습니다. 연결하려는 원격 컴퓨터는 해당 자격 증명을 사용하여 사용자를 가장하고 해당 자격 증명을 사용하여 지정한 작업을 수행합니다. 감사를 사용하도록 설정한 경우 수행하는 작업 외에도 PowerShell 원격에서 사용자 대신 수행하는 작업도 감사됩니다. 실제로 원격은 보안이 투명하며 환경의 기존 보안을 변경하지 않습니다. 원격을 사용하면 로컬 컴퓨터 앞에 물리적으로 있는 동안 수행하는 것과 동일한 작업을 모두 수행할 수 있습니다.

참고

개인 네트워크에서는 PowerShell Remoting용 기본 Windows 방화벽 규칙이 모든 연결을 수락합니다. 공용 네트워크에서는 기본 Windows 방화벽 규칙이 동일한 서브넷 내에서만 PowerShell 원격 연결을 허용합니다. 공용 네트워크에서 모든 연결에 대해 PowerShell Remoting을 열려면 해당 규칙을 명시적으로 변경해야 합니다.

보안 위험 및 상호 인증

자격 증명을 원격 컴퓨터에 위임하는 경우 몇 가지 보안 위험이 발생합니다. 예를 들어 공격자가 알려진 원격 컴퓨터를 성공적으로 가장하는 경우 잠재적으로 높은 권한의 자격 증명을 해당 공격자에게 전송할 수 있습니다. 그러면 악의적인 용도로 사용할 수 있습니다. 이러한 위험 때문에 원격에는 기본적으로 상호 인증이 필요합니다. 즉, 원격 컴퓨터에 자신을 인증해야 하며 원격 컴퓨터도 사용자에게 인증해야 합니다. 이 상호 인증은 의도한 정확한 컴퓨터에만 연결하도록 보장합니다.

상호 인증은 Active Directory Kerberos 인증 프로토콜의 기본 기능입니다. 신뢰할 수 있는 도메인 컴퓨터 간에 연결하면 상호 인증이 자동으로 수행됩니다. 도메인에 가입되지 않은 컴퓨터에 연결하는 경우 미리 설정해야 하는 SSL 인증서 및 HTTPS 프로토콜 형식으로 다른 형태의 상호 인증을 제공해야 합니다. 또 다른 옵션은 로컬 TrustedHosts 목록에 원격 컴퓨터를 추가하여 상호 인증 요구 사항을 해제하는 것입니다. 그러나 TrustedHosts는 서버 ID를 보장하지 않는 Windows NTLM(NT LAN 관리자) 인증을 사용합니다. 인증에 NTLM을 사용하는 프로토콜과 마찬가지로 도메인에 가입된 컴퓨터의 신뢰할 수 있는 계정에 액세스할 수 있는 공격자는 도메인 컨트롤러가 NTLM 세션 키를 만들어 서버를 가장할 수 있습니다.

참고

NTLM 인증 프로토콜은 대상 서버의 ID를 보장할 수 없습니다. 암호를 이미 알고 있는지만 확인할 수 있습니다. 따라서 PowerShell Remoting에 SSL을 사용하도록 대상 서버를 구성해야 합니다. 클라이언트가 신뢰하는 신뢰할 수 있는 인증 기관에서 발급한 SSL 인증서를 가져와 대상 서버에 할당하면 NTLM 기반 인증의 보안이 향상되어 사용자 ID와 서버 ID의 유효성을 모두 검사할 수 있습니다.

컴퓨터 이름 고려 사항

AD DS 기반 인증이 작동하려면 PowerShell 원격에서 AD DS(Active Directory Domain Services) 컴퓨터 개체를 검색하고 찾을 수 있어야 합니다. 즉, FQDN(정규화된 도메인 이름)을 사용하여 대상 컴퓨터를 참조해야 합니다. 예를 들어 IP 주소 또는 DNS(Domain Name System) 별칭은 필요한 상호 인증에 원격을 제공하지 않으므로 작동하지 않습니다. IP 주소 또는 DNS 별칭으로 컴퓨터를 참조해야 하는 경우 HTTPS를 사용하여 연결해야 합니다. 즉, 원격 컴퓨터가 해당 프로토콜을 수락하도록 구성되어야 합니다. 또는 로컬 TrustedHosts 목록에 IP 주소 또는 DNS 별칭을 추가해야 합니다.

참고

컴퓨터 이름 localhost에 대해 특별한 예외가 발생하며, 이를 사용하여 다른 구성 변경 없이 로컬 컴퓨터에 연결할 수 있습니다. 로컬 컴퓨터가 클라이언트 기반 운영 체제를 사용하는 경우 WinRM을 구성해야 합니다.

TrustedHosts 목록

TrustedHosts 목록은 GPO(그룹 정책 개체)를 사용하여 구성할 수도 있는 로컬로 구성된 설정입니다. TrustedHosts 목록은 상호 인증이 불가능한 컴퓨터를 열거합니다. 컴퓨터는 실제 컴퓨터 이름, DNS 별칭 또는 IP 주소 등 연결에 사용할 이름과 동일한 이름으로 나열되어야 합니다. 와일드카드를 사용하여 SRV*를 지정할 수 있습니다. 이 경우 이름 또는 DNS 별칭이 SRV로 시작하는 모든 컴퓨터에서 연결할 수 있습니다. 그러나 이 목록에는 주의해야 합니다. TrustedHosts 목록을 사용하면 HTTPS를 설정하지 않고도 비도메인 컴퓨터에 쉽게 연결할 수 있지만 이는 중요한 보안 조치를 무시합니다. 이 기능을 사용하면 해당 컴퓨터가 실제로 연결하려는 컴퓨터인지 여부를 확인하지 않고 원격 컴퓨터에 자격 증명을 보낼 수 있습니다. TrustedHosts 목록을 사용하여 보호된 데이터 센터에 보관된 서버와 같이 손상되지 않을 것으로 알고 있는 컴퓨터만 지정해야 합니다. 또한 TrustedHosts를 사용하여 프로비저닝 프로세스를 진행 중인 새 컴퓨터와 같이 제어된 네트워크 서브넷의 비도메인 컴퓨터에 일시적으로 연결할 수 있습니다.

참고

반드시 필요한 경우가 아니면 TrustedHosts 목록을 사용하지 않는 것이 좋습니다. HTTPS를 사용하도록 비도메인 컴퓨터를 구성하는 것이 보다 안전한 장기 솔루션입니다.

개인 정보 취급 방침

기본적으로 원격은 통신 콘텐츠의 개인 정보 보호 또는 암호화를 제공하지 않는 HTTP를 사용합니다. 그러나 Windows PowerShell은 기본적으로 애플리케이션 수준 암호화를 적용할 수 있고 적용합니다. 즉, 통신이 어느 정도의 개인 정보 보호 및 보호를 받습니다. 내부 네트워크에서 이 애플리케이션 수준 암호화는 일반적으로 조직의 보안 요구 사항을 충족하기에 충분합니다.

기본 Kerberos 인증 프로토콜을 사용하는 도메인 환경에서 자격 증명은 암호를 포함하지 않는 암호화된 Kerberos 티켓 형식으로 전송됩니다.

HTTPS를 사용하여 연결하면 원격 컴퓨터의 SSL 인증서 암호화 키를 사용하여 전체 채널이 암호화됩니다. 따라서 기본 인증을 사용하는 경우에도 암호는 일반 텍스트로 전송되지 않습니다. 그러나 HTTP 및 기본 인증을 사용하여 HTTPS에 대해 구성되지 않은 컴퓨터에 연결하는 경우 자격 증명(암호 포함)이 일반 텍스트로 전송됩니다. 예를 들어 로컬 TrustedHosts 목록에 추가하는 비도메인 컴퓨터에 연결할 때 이 문제가 발생할 수 있습니다. 호스트 이름이 아닌 IP 주소를 지정하여 도메인에 가입된 컴퓨터를 사용하는 경우에도 이 문제가 발생할 수 있습니다.

자격 증명은 해당 시나리오에서 일반 텍스트로 전송되므로 새 컴퓨터 프로비저닝을 위해 특별히 지정된 것과 같이 제어되고 보호된 네트워크 서브넷에서만 비도메인 컴퓨터에 연결해야 합니다. 비도메인 컴퓨터에 정기적으로 연결해야 하는 경우 HTTPS를 지원하도록 구성해야 합니다.