Google Cloud에서 Active Directory를 실행하기 위한 권장사항

---

이 가이드는 Google Cloud에서 Active Directory를 실행하기 위한 권장사항을 제공합니다. 이 가이드는 Google Cloud 에 한정된 관행이나 Google Cloud에 Active Directory를 배포할 때 특히 중요한 관행을 중점적으로 설명합니다. 이 가이드를 Microsoft에서 게시한 일반적인 Active Directory 보안 권장사항을 보완하는 가이드로 활용하는 것이 좋습니다.

아키텍처

다음 섹션에서는 아키텍처와 관련된 권장사항을 자세히 설명합니다.

현재 요건에 가장 적합한 아키텍처 패턴을 사용합니다.

Google Cloud에 Active Directory를 배포하려면 먼저 사용할 도메인과 포리스트 아키텍처를 결정해야 합니다. 이미 Active Directory를 사용하고 있다면 두 환경을 통합할지 여부와 방법을 결정해야 합니다.

상황에 가장 적합한 디자인은 온프레미스 네트워크 설계, 온프레미스 및Google Cloud 리소스의 상호작용 방식, 가용성 및 관리 자율성 요건을 포함한 다양한 요소에 따라 결정됩니다. 이러한 요소가 설계를 결정하는 방식을 확인하려면 하이브리드 환경에서의 Active Directory 사용 패턴을 참조하세요.

Google Cloud 및 온프레미스 환경 간에 트러스트 경계를 유지하려면 리소스 포리스트 패턴을 구현합니다. 이 패턴에서는 Google Cloud 에 별도의 포리스트를 배포하고 단방향 포리스트 트러스트를 사용하여 Google Cloud 포리스트를 기존 온프레미스 Active Directory 포리스트와 통합합니다.

별도의 테스트 및 프로덕션

Active Directory 사용에 따라 애플리케이션 개발 및 테스트 중에 Active Directory를 자주 변경해야 할 수도 있습니다. 개발자는 Active Directory 계정을 생성 및 수정하고, 애플리케이션이 그룹을 사용하여 승인을 처리하거나 컴퓨터를 가입 및 제거할 경우 그룹 멤버십을 변경해야 할 수 있습니다.

개발 및 테스트 작업이 프로덕션 워크로드에 영향을 주거나 배포 보안을 방해하지 않도록 하려면 개발 및 테스트를 위해 별도의 Active Directory 도메인 또는 포리스트를 배포하세요.

별도의 개발 및 테스트 도메인 또는 포리스트가 있으면 관리 변경 사항을 프로덕션에 적용하기 전에 확인할 수 있습니다. 이러한 변경의 예시로는 그룹 정책 실험, 자동화 스크립트 테스트 또는 포리스트의 기능 수준 올리기와 같은 잠재적으로 위험한 조치가 있습니다.

Google Cloud에 Active Directory 배포 외에 Cloud ID 제휴 설정

Google Cloud 에 Active Directory를 배포하면 Google Cloud에서 Windows VM을 관리하고 사용자가 기존 사용자 계정을 사용하여 Windows VM에 로그인할 수 있으며 인증에 Kerberos, NTLM 또는 LDAP를 사용하는 애플리케이션을 지원합니다.

그러나 Google Cloud 콘솔, gcloud 명령줄 도구 또는 기타 Google 및 Google Cloud 도구를 사용하려면 Google ID로 인증해야 합니다. 따라서 사용자 관리를 위한 주도하는 시스템으로 Active Directory를 사용하려는 경우 Google Cloud 에서 Active Directory 배포는 Google Cloud와 기존 Active Directory 제휴를 대체하지 않습니다.

예를 들어 Google Cloud에 별도의 포리스트를 배포하는 경우 다음 다이어그램과 같이 온프레미스 Active Directory에 제휴를 설정할 수 있습니다. 온프레미스 Active Directory에 계정이 있는 사용자는 인증을 위해 Active Directory를 사용하는 애플리케이션뿐만 아니라 Google ID가 필요한 도구를 사용할 수 있습니다.

대신 Google Cloud에 기존 포리스트나 도메인을 확장하려는 경우 Google Cloud 에 배포된 도메인 컨트롤러와 AD FS 서버를 사용하여 제휴를 설정하는 옵션도 제공됩니다.

또한 제휴를 사용하면 Google 계정 및 Active Directory 계정에 일반적인 수명 주기를 적용할 수 있으므로 온프레미스 Active Directory에서 사용자 계정을 사용 중지하도록 설정하면 해당 Google 사용자도 정지됩니다.

네트워킹

다음 섹션에서는 네트워킹과 관련된 권장사항을 자세히 설명합니다.

공유 VPC 네트워크에 Active Directory 배포

Active Directory를 여러 프로젝트에서 사용할 수 있도록 하려면 도메인 컨트롤러를 공유 VPC 네트워크에 배포합니다. 공유 VPC 네트워크를 사용하면 다음과 같은 다양한 이점이 있습니다.

• Active Directory 액세스가 필요한 각 애플리케이션은 별도의 프로젝트에 배포할 수 있습니다. 별도의 프로젝트를 사용하면 리소스를 격리하고 액세스를 개별적으로 관리할 수 있습니다.

• Active Directory 도메인 컨트롤러에 전용 프로젝트를 사용하면 관련 Google Cloud 리소스에 액세스할 수 있는 사용자를 세밀하게 제어할 수 있습니다.

• 공유 VPC 네트워크를 사용하면 IP 주소 관리 및 방화벽 구성을 중앙화하여 여러 프로젝트에서 일관성을 유지할 수 있습니다.

VPC는 전역 리소스이므로 여러 리전에서 동일한 공유 VPC 네트워크를 사용할 수 있습니다.

도메인 컨트롤러를 외부에 노출하지 않기

Active Directory의 공격 표면을 줄이려면 외부 IP 주소를 도메인 컨트롤러에 할당하지 마세요.

외부 IP 주소가 없는 VM 인스턴스는 기본적으로 인터넷에 액세스할 수 없으므로 도메인 컨트롤러에서 Windows 정품 인증 및 Windows 업데이트가 손상되지 않도록 추가 단계를 수행해야 합니다.

Windows 정품 인증을 지원하려면 도메인 컨트롤러를 배포하려는 서브넷에서 비공개 Google 액세스를 사용 설정하고 VM 인스턴스가 kms.windows.googlecloud.com에 액세스할 수 있는지 확인하세요. 이를 통해 직접적인 인터넷 액세스 없이도 정품 인증할 수 있습니다.

Windows 업데이트를 지원하는 여러 가지 옵션이 있습니다.

• 온프레미스 WSUS 서버가 있는 경우 하이브리드 연결을 구성하고 WSUS 서버를 업데이트 소스로 사용하도록 도메인 컨트롤러를 구성할 수 있습니다.

• Cloud NAT를 배포하여 NAT 게이트웨이를 통해 인터넷 액세스를 사용 설정할 수 있습니다.

• 하이브리드 연결을 설정한 경우 온프레미스 NAT 게이트웨이나 프록시 서버를 통해 아웃바운드 트래픽을 라우팅할 수도 있습니다.

도메인 컨트롤러의 고정 IP 주소 미리 예약

도메인 컨트롤러는 DNS 서버 역할을 하므로 변경되지 않는 IP 주소를 할당해야 합니다. 이를 달성하려면 도메인 컨트롤러 VM에 고정 내부 IP 주소를 구성합니다.

IP 주소를 예약할 때 기본 동작은 사용되지 않는 주소가 자동으로 선택되는 것입니다. 도메인 컨트롤러의 IP 주소를 기억하기 쉽게 하려면 내부 고정 IP 주소를 예약하세요.

도메인 컨트롤러에서 네트워크 어댑터의 IP 주소를 동일한 주소로 설정하세요. 선택사항인 이 단계는 Active Directory가 머신의 IP 주소가 여전히 동적으로 할당될 수 있음을 나타내는 경고 메시지를 표시하지 않도록 합니다.

여러 영역에 도메인 컨트롤러 배포

가용성을 높이려면 2개 이상의 도메인 컨트롤러를 여러 영역에 분산 배포합니다. 서브넷과 IP 주소가 영역에 연결되어 있지 않기 때문에 모든 도메인 컨트롤러를 단일 서브넷에 배포할 수 있습니다.

여러 리전에 워크로드를 배포하려는 경우 각 관련 리전에 도메인 컨트롤러를 배포하는 것이 좋습니다. 서브넷은 리전 리소스이므로 추가 리전에 배포하려면 추가 서브넷이 필요합니다.

리전당 하나의 사이트 만들기

클라이언트가 도메인 컨트롤러를 찾으려고 할 때 먼저 Active Directory 사이트에서 클라이언트의 IP 주소에 해당하는 도메인 컨트롤러를 찾습니다. 이 사이트에서 사용할 수 있는 도메인 컨트롤러가 없으면 클라이언트는 계속해서 다른 사이트에서 도메인 컨트롤러를 찾습니다.

도메인 컨트롤러 또는 도메인 클라이언트를 배포하는 각 리전에 대해 별도의 사이트를 만들어 이 동작을 활용할 수 있습니다. 그런 다음 클라이언트는 같은 리전에 위치한 도메인 컨트롤러 사용을 자동으로 선호하므로 지연 시간 및 리전 간 아웃바운드 데이터 전송 비용을 줄일 수 있습니다.

도메인 컨트롤러가 없는 리전에 클라이언트가 있는 경우 리전의 지리적 근접성을 반영하도록 사이트링크 비용을 조정하고 다음으로 가장 가까운 사이트 시도 설정을 사용 설정하여 이러한 클라이언트가 선택하는 도메인 컨트롤러에 영향을 줄 수 있습니다.

여러 사이트를 사용하면 도메인 컨트롤러 간의 복제 동작에 영향을 줍니다. 여러 사이트를 사용하는 것의 한 가지 단점은 사이트 간 복제가 사이트 내 복제보다 빈도가 적게 발생한다는 것입니다.

하지만 관리형 Microsoft AD는 Active Directory 사이트 및 서비스 기능을 지원하지 않으므로 관리형 Microsoft AD에서 Active Directory 사이트를 만들 수 없습니다.

Cloud DNS 비공개 전달 영역 사용

Compute Engine에서 새 VM 인스턴스를 만들면 운영체제는 내부 DNS 및 공개 DNS에 대한 액세스를 제공하는 기본 DNS 서버를 사용하도록 사전 구성됩니다.

머신을 Active Directory 도메인에 가입시키기 전에 머신이 Active Directory에서 관리하는 DNS 레코드를 확인할 수 있는지 확인해야 합니다. Compute Engine이 VM 인스턴스에 대해 구성하는 기본 DNS 서버는 내부 DNS 및 공개 DNS에 대한 액세스를 제공하지만 Active Directory에서 관리하는 DNS 이름은 확인할 수 없습니다.

클라이언트가 Active Directory에서 관리하는 DNS 레코드를 확인할 수 있도록 Cloud DNS에서 비공개 DNS 전달 영역을 만듭니다. Active Directory 도메인과 일치하는 쿼리를 도메인 컨트롤러에 전달하도록 영역을 구성합니다.

비공개 DNS 전달 영역을 사용하면 클라이언트가 Active Directory 도메인 컨트롤러를 DNS 서버로 직접 사용하도록 구성하는 것보다 여러 가지 장점이 있습니다.

• VM 인스턴스의 네트워킹 구성을 조정하지 않아도 됩니다. 이렇게 하면 새 VM을 만드는 과정이 간소화됩니다.

• 도메인 컨트롤러 수준을 올리거나 내리면 비공개 DNS 전달 영역의 구성 만 업데이트하면 되며 클라이언트 설정을 수정할 필요가 없습니다.

• VM 인스턴스는 여전히 내부 DNS에 액세스할 수 있습니다.

• Active Directory 도메인과 일치하지 않는 DNS 레코드는 Cloud DNS에서 처리되므로 도메인 컨트롤러의 부하가 줄어듭니다.

여러 도메인을 사용하는 경우 각 Active Directory 도메인에 대해 별도의 비공개 DNS 전달 영역을 만듭니다.

Cloud DNS 비공개 전달 영역의 범위는 단일 VPC입니다. 피어링을 사용하여 연결된 여러 VPC를 사용하는 경우 DNS 피어링을 구성하여 비공개 전달 영역을 다른 VPC에 노출할 수 있습니다.

도메인 컨트롤러에서 DNS 설정을 수동으로 구성해야 합니다. 기본 DNS 서버로 127.0.0.1을 사용하고 선택적으로 다른 도메인 컨트롤러의 IP 주소를 보조 DNS 서버로 사용합니다. 자세한 내용은 권장 DNS 설정 및 대체 옵션을 참조하세요.

하이브리드 연결

다음 섹션에서는 하이브리드 연결과 관련된 권장사항을 자세히 설명합니다.

DNS 인바운드 전달을 사용하여 온프레미스에서 Google Cloud DNS 이름 확인

온프레미스 네트워크의 클라이언트는 Google Cloud에 배포된 리소스의 DNS 이름을 확인할 수 있어야 합니다. 포리스트를 확장하거나Google Cloud에 리소스 포리스트를 배포하는 경우 DNS 인바운드 전달을 사용하여 온프레미스 클라이언트에서 Google Cloud에 배포된 리소스의 DNS 레코드를 조회하도록 허용합니다. 인바운드 전달을 사용하려면 DNS 서버 정책을 만들어 인바운드 전달자 IP 주소를 할당하고 이 주소에서 온프레미스 네트워크에 액세스할 수 있게 합니다.

Google Cloud 에서 사용되는 DNS 도메인(예: cloud.example.com)이 온프레미스에서 사용되는 DNS 도메인의 하위 도메인(예: example.com)인 경우 DNS 위임을 설정합니다. 인바운드 전달자 IP 주소를 가리키는 온프레미스 도메인에서 NS 레코드를 작성합니다. NS 레코드는 Google Cloud호스트 도메인에서 DNS 이름을 조회하려고 하는 클라이언트가 인바운드 전달자 IP 주소로 리디렉션되도록 합니다.

Google Cloud 에서 사용되는 DNS 도메인과 온프레미스 Active Directory가 다른 경우(예: cloud.example.com 및 corp.example.com) 온프레미스 도메인에서 조건부 DNS 전달을 구성하고 인바운드 전달자 IP 주소를 대상으로 사용합니다. Google Cloud호스팅 도메인에서 DNS 이름 확인을 요청하면 온프레미스 도메인 컨트롤러가 퀘스트를 인바운드 전달자 IP 주소로 전달합니다.

인바운드 DNS 전달을 사용하는 경우 방화벽이 적절하게 구성되어 있는지 확인하세요.

Active Directory로 기존 도메인을 확장하는 경우에는 DNS 인바운드 전달이 필요하지 않습니다. 이 시나리오에서 도메인의 모든 DNS 레코드는 Google Cloud 및 온프레미스 환경에 자동으로 복제되며 두 환경 모두에서 조회될 수 있습니다.

DNS 아웃바운드 전달을 사용하여 Google Cloud에서 온프레미스 DNS 이름 확인

Google Cloud 에서 실행 중인 클라이언트에서 온프레미스에 배포된 리소스의 이름을 확인할 수 있어야 합니다. Google Cloud에서 포리스트를 확장하거나 리소스 포리스트를 배포하는 경우 Cloud DNS에 비공개 전달 영역을 만들어 온프레미스 도메인에 대한 DNS 쿼리를 온프레미스 DNS 서버에 전달합니다.

아웃바운드 DNS 전달을 사용하는 경우 방화벽이 적절하게 구성되어 있는지 확인하세요.

기존 도메인을 확장하면 Active Directory에 DNS 아웃바운드 전달이 필요하지 않습니다. 이 시나리오에서 도메인의 모든 DNS 레코드는 Google Cloud 및 온프레미스 환경에 자동으로 복제되며 두 환경 모두에서 조회될 수 있습니다.

VPN 터널을 사용하여 LDAP 트래픽 보안

Active Directory는 LDAP 프로토콜을 광범위하게 사용합니다. Active Directory에서 사용되는 대부분의 다른 프로토콜과 달리 LDAP는 기본적으로 암호화되지 않습니다.

Google Cloud 는 가상 머신 간의 트래픽이 암호화되도록 하므로 VPC 내에서 암호화되지 않은 LDAP를 사용할 수 있습니다. VPC를 온프레미스 네트워크에 연결하는 경우 LDAP 트래픽이 신뢰할 수 있는 채널을 통해서만 교환되는지 확인합니다.

Cloud VPN을 사용하여 Google Cloud 와 온프레미스 네트워크를 연결하면Google Cloud 및 온프레미스 VPN 엔드포인트 간의 IPSec을 통해 트래픽이 자동으로 암호화됩니다.

Cloud Interconnect 및 Partner Interconnect는 암호화를 제공하지 않습니다. 보안 통신이 강화되도록 Google Cloud Marketplace의 VPN 어플라이언스를 사용하여 Interconnect 연결을 통해 VPN 터널을 설정합니다.

포레스트 트러스트에 선택적 인증 및 AES 사용

Active Directory 포리스트 간에 트러스트 관계를 만들 때 외부 트러스트보다 포리스트 트러스트를 선호하고 다음 기능을 활용하여 보안을 강화합니다.

• 리소스 포리스트의 아웃바운드 트러스트에서 선택적 인증을 사용 설정합니다. 선택적 인증을 통해 명시적으로 권한을 부여하지 않으면 조직 포리스트의 사용자가 리소스 포리스트의 리소스에 액세스할 수 없습니다.

• 조직 포리스트의 인바운드 트러스트에서 Kerberos 전체 위임을 위한 포리스트 경계 적용을 사용 설정하세요. 이 기능은 리소스 포리스트의 리소스가 조직 포리스트의 사용자에게 TGT(Ticket Granting Tickets)를 요청하지 못하도록 하여 권한 에스컬레이션 공격을 방지합니다.

• 트러스트를 만들 때 다른 도메인이 Kerberos AES 암호화를 지원 옵션을 사용 설정합니다. 이 옵션을 사용하면 포리스트 간 인증에 사용되는 티켓이 덜 안전한 RC4 알고리즘 대신 AES를 사용하여 암호화됩니다.

보안

다음 섹션에서는 보안과 관련된 권장사항을 자세히 설명합니다.

Active Directory 보안을 방해하는 Google Cloud 보안 방지

Active Directory를 사용하면 어떤 사용자가 어떤 리소스에 액세스할 수 있는지를 세부적으로 제어할 수 있습니다. 머신이 Compute Engine에서 VM 인스턴스로 배포되고 사용자가 기본 Google Cloud프로젝트에 액세스할 수 있는 경우 사용자가 머신에 액세스할 수 있는 추가 경로를 고려해야 합니다.

• Google Cloud 프로젝트에서 Compute 인스턴스 관리자 역할이 할당된 프로젝트 구성원은 비밀번호 재설정 기능을 사용하여 로컬 관리자 계정을 만들 수 있습니다. 로컬 관리자 계정은 그룹 정책을 약화시키거나 로그온한 다른 사용자의 도메인 사용자 인증 정보를 캡처할 수 있는 악성 소프트웨어를 설치하는 데 사용될 수 있으므로 Active Directory 도메인의 보안에 위협이 됩니다.

• 권한이 있는 프로젝트 구성원은 시작 스크립트를 추가하여 다음에 머신을 재부팅할 때 악성 코드를 nt authority\system으로 실행되는 VM에 삽입할 수 있습니다.

• 권한이 있는 프로젝트 구성원은 직렬 콘솔을 사용하여 Windows 특수 관리 콘솔(SAC)에도 액세스할 수 있습니다. Windows는 SAC를 통한 로그온을 로컬 로그온으로 간주합니다. 따라서 SAC는 RDP를 통한 로그온을 거부하고 로컬 로그온 거부를 놓치는 정책을 피하는 데 오용될 소지가 있습니다.

• 권한이 있는 프로젝트 구성원은 SAC를 사용하여 crashdump 명령어를 실행할 수 있으며 메모리 덤프가 디스크에 기록될 수 있습니다. 이러한 메모리 덤프에는 민감한 정보 및 사용자 인증 정보가 포함될 수 있습니다.

• 영구 디스크를 다른 VM에 마운트하거나 스냅샷을 사용하여 권한이 있는 프로젝트 구성원은 사용자가 로그온 권한이 없는 머신에서 메모리 덤프를 포함하여 잠재적으로 디스크 콘텐츠에 액세스할 수 있습니다.

관리형 Microsoft AD를 사용하는 경우 기본적으로 이러한 추가 액세스 경로에 대한 보호 기능이 향상됩니다. 이 서비스는 프로젝트의 권한이 있는 사용자가 도메인 관리자 비밀번호를 재설정하거나 시작 스크립트를 실행하거나 AD 도메인 컨트롤러 VM의 직렬 콘솔에 액세스하는 것을 허용하지 않습니다.

이러한 위험을 추가로 완화하려면 도메인 가입 VM 인스턴스를 포함하는 프로젝트의 IAM 권한이 최소 권한 원칙에 따라 관리되어야 합니다. 조직 정책, 그룹 정책, 보안 VM 사용자가 위험을 추가로 줄일 수 있습니다.

• 직렬 포트 액세스를 사용 중지하려면 조직 정책을 사용하세요.

• 계정 관리자를 사용 중지하여 로컬 관리자 계정을 작성하지 못하게 하는 그룹 정책을 적용하세요. 그룹 정책(컴퓨터 구성 > 환경설정 > Windows 설정 > Ini 파일)에서 INI 파일 환경설정을 정의하여 다음 설정을 적용하세요.

  • 작업: 업데이트
  • 파일 경로: C:\Program Files\Google\Compute Engine\instance_configs.cfg
  • 섹션 이름: accountManager
  • 속성 이름: disable
  • 속성 값: true

• VM 인스턴스에서 로컬 관리자 계정을 제거하는 그룹 정책을 적용하세요. 로컬 사용자 및 그룹 기능(컴퓨터 구성 > 환경설정 > 제어판 설정 > 로컬 사용자 및 그룹)을 사용하여 관리자 그룹 및 기타 민감한 그룹에서 그룹 멤버십을 제거하세요.

• 승인되지 않은 사용자가 영구 디스크 또는 스냅샷을 읽을 수 없도록 하려면 BitLocker 디스크 암호화와 함께 보안 VM을 사용하는 것이 좋습니다.

Google Cloud 보안을 방해하는 Active Directory 보안 방지

Active Directory 도메인에서 머신은 도메인 컨트롤러가 인증 및 승인을 대신 처리하도록 트러스트합니다. 그룹 정책, 머신의 로컬 보안 정책 또는 선택적 인증에 의해 제한되지 않는 한 도메인 컨트롤러 중 하나에 대한 ID를 성공적으로 증명한 사용자는 도메인의 모든 머신에 로그온할 수 있습니다.

Active Directory 사용자가 모든 머신에 로그온할 수 있으면 공격자가 도메인 내에서 측면 이동을 수행할 수 있습니다. 일부 VM 인스턴스가 방화벽 제한에서 제외되거나 Google Cloud 서비스 계정을 사용하는 경우 이러한 측면 이동으로 인해 권한 에스컬레이션이 발생할 수 있습니다. 즉, VM 인스턴스의 모든 프로세스와 사용자가 서비스 계정의 사용자 인증 정보에 액세스할 수 있습니다. 따라서 Active Directory를 사용하여 머신에 로그온할 수 있는 모든 사용자는 이러한 서비스 계정 사용자 인증 정보에 액세스하여 서비스 계정에 액세스 권한이 부여된 모든 Google Cloud리소스에 액세스할 수 있습니다.

관리형 Microsoft AD를 설정할 때 서비스는 특정 사용자가 RDP를 통해 도메인 가입 VM에 쉽게 연결할 수 있도록 그룹을 만듭니다.

측면 이동의 위험을 줄이려면 사용자를 관리 계층으로 구성하고 네트워크에서 이 컴퓨터에 대한 액세스 거부 및 원격 데스크톱 서비스를 통한 로그온 거부 그룹 정책을 통해 등급 수준에 따라 VM에 대한 액세스를 제한합니다.

리소스 포리스트 토폴로지에서 선택적 인증을 추가로 활용하여 VM에 로그온할 수 있는 다른 포리스트의 사용자 집합을 추가로 제한하세요. Google Cloud 및 Active Directory 리소스 구조를 조정하여 선택적 인증 권한 관리를 간소화할 수 있습니다. 즉, Active Directory 조직 단위가 Google Cloud 프로젝트에 매핑되면 사용자에게 Google Cloud 프로젝트와 일치하는 수준에서 인증할 수 있는 권한을 부여할 수 있습니다.

선택적 인증이나 그룹 정책을 모두 적용할 수 없는 경우 별도의 서비스 계정을 만들고 서비스 계정 키를 내보내고 VM 인스턴스의 로컬 디스크 또는 파일 공유에 저장한 다음 승인된 Active Directory 사용자만 키를 읽고 사용할 수 있도록 NTFS ACL을 사용하여 보호합니다.

도메인 컨트롤러 전용 프로젝트 사용

도메인 컨트롤러는 Active Directory 도메인 보안에 중요한 역할을 하며 단일 도메인 컨트롤러가 손상되면 전체 Active Directory 포레스트가 손상될 수 있습니다.

무단 액세스 위험을 줄이려면 별도의 Google Cloud 프로젝트를 사용하여 도메인 컨트롤러를 배포하고 최소 권한 원칙에 따라 이 프로젝트에 대한 액세스 권한을 부여합니다. 프로젝트를 만들 때 일부 권한은 상위 폴더에서 상속될 수 있습니다. 상속을 통해 실수로 액세스 권한을 부여하지 않으려면 일반적인 폴더 계층 구조 외부에서 프로젝트를 만듭니다.

프로젝트에 대한 IAM 정책을 구성할 때는 VM 인스턴스, ntds.dit 데이터베이스를 포함하는 영구 디스크, 백업을 포함할 수 있는 스토리지 위치에 대한 액세스를 제한할 때 특히 주의하세요.

IAM 정책을 사용하여 프로젝트에 대한 액세스 권한을 제한하는 것 외에도 실수로 인한 삭제로부터 프로젝트를 보호합니다.

Active Directory 관리에 별도의 VM 및 프로젝트 사용

Active Directory를 관리하려면 Active Directory 사용자 및 컴퓨터 또는 Active Directory 관리 센터와 같은 도구를 사용할 수 있어야 합니다. 이러한 도구를 사용하려면 권한이 있는 도메인 계정을 사용하여 로그온해야 하므로 이러한 도구를 실행하는 머신은 사용자 인증 정보 도용 또는 키 로깅에 대한 매력적인 대상이 됩니다.

공격자가 권한이 있는 도메인 사용자 인증 정보를 얻는 위험을 최소화하려면 도메인 관리에 전용 VM 인스턴스를 사용하고 권한이 있는 액세스 워크스테이션과 같은 관리 VM을 처리하세요.

• 그룹 정책을 사용하여 선택된 일부 사용자만 관리 VM에 로그온할 수 있는 권한을 갖도록 하세요. 계층형 관리를 구현한 경우 이 사용자 그룹은 등급 0에 해당합니다.

• 도메인 컨트롤러와 유사하게, 프로젝트 구성원이 로컬 관리자 계정 생성, 직렬 콘솔을 통해 로그온 또는 영구 디스크 변조를 통해 관리 VM을 위험에 빠뜨릴 수 있습니다. 무단 액세스의 위험을 줄이려면 관리 VM에 별도의 Google Cloud 프로젝트를 사용하고 최소 권한 원칙에 따라 이 프로젝트에 대한 액세스 권한을 부여합니다.

하이브리드 연결을 사용하여 온프레미스 네트워크에서 관리 VM에 액세스하려는 경우 관리 VM을 전용 VPC 서브넷에 배포합니다. 관리 VM 전용 서브넷을 사용하면 온프레미스 방화벽을 구성할 때 관리 VM과 다른 VM을 더 잘 구별할 수 있습니다. 공유 VPC를 사용하는 경우 서브넷 수준 권한을 사용하여 권한이 있는 관리자만 VM 인스턴스를 관리 서브넷에 배포할 수 있습니다. 이 방법은 온프레미스 방화벽이 관리 VM에 다른 VM과 다른 규칙을 적용하는 경우 비 관리 VM을 관리 서브넷에 배치하여 방화벽 규칙을 피할 수 없도록 합니다.

또한 관리 VM의 로그온 제한을 관리하는 그룹 정책을 관리 서브넷으로 제한하는 것을 고려하세요. 이 방법은 로그온 제한(그룹 정책 기반)과 방화벽 규칙(서브넷/IP 주소 기반) 간의 정렬을 강제합니다.

IAM 정책을 사용하여 프로젝트에 대한 액세스 권한을 제한하는 것 외에도 실수로 인한 삭제로부터 프로젝트를 보호합니다.

방화벽 규칙을 사용하여 도메인 컨트롤러 및 서버 보안

도메인 컨트롤러는 LDAP, DNS, Kerberos, RPC를 포함한 많은 서비스를 제공합니다. 사용 사례에 따라 Google Cloud에 배포된 VM과 온프레미스에서 실행되는 머신에서 Active Directory를 활용하려면 이러한 서비스의 다른 하위 집합에 액세스해야 할 수도 있습니다.

관리형 Microsoft AD를 사용할 때 AD 도메인 컨트롤러는 전용 테넌트 프로젝트에 배포됩니다. AD 도메인 컨트롤러를 호스팅하는 네트워크는 강화된 AD 특정 방화벽 규칙으로 자동 보호됩니다.

도메인 컨트롤러와 VM의 공격 표면을 줄이려면 방화벽을 사용하여 엄격하게 요구되지 않는 네트워크 통신을 허용하지 마세요. VPC 내 또는 온프레미스 네트워크에서 Active Directory에 액세스하는 데 필요한 방화벽 구성에 대한 자세한 내용은 방화벽에서 Active Directory 사용에 대한 가이드를 참조하세요.

Active Directory 리소스 및 사용자를 관리 계층별로 정리

Active Directory 포리스트의 일부 머신은 다른 머신보다 전체 Active Directory 보안에 더 중요합니다. 도메인 컨트롤러 및 관리 VM은 특히 중요하고 잠재적 공격에 특히 민감한 머신의 두 가지 예시입니다.

각 머신의 중요도를 식별하려면 계층 분류를 사용하세요. 올바른 계층 수는 특정 설정에 따라 다르지만 다음 세 가지 계층 사이에서 구별하여 시작할 수 있습니다.

• 계층 0(매우 중요): 이 계층에는 Active Directory 포리스트의 보안에 중요한 모든 머신이 포함됩니다. 단일 계층 0 머신이 손상되면 전체 포리스트가 손상되었다고 가정해야 합니다.

• 계층 1(중요): 이 계층에는 애플리케이션 서버 및 데이터베이스 서버를 포함하여 사용자 환경의 대부분의 서버가 포함됩니다. 손상된 계층 1 서버는 비즈니스에 상당한 영향을 줄 수 있지만 전체 포리스트에 즉각적인 위협을 주지는 않습니다.

• 계층 2(일반): 이 계층에는 워크스테이션 또는 기타 범용 머신이 포함됩니다. 계층 2 머신의 손상은 비즈니스 및 전체 보안에 대한 영향은 제한적일 것으로 예상됩니다.

손상된 계층 2 머신의 즉각적인 영향은 제한적인 것처럼 보일 수 있지만 다음과 같은 파급 효과가 있을 수 있습니다. 계층 0 또는 계층 1 머신에 대한 관리 액세스 권한이 있는 사용자가 손상된 계층 2 머신에 로그온하도록 유도되면, 키로거 또는 다른 형태의 사용자 인증 정보 도난에 노출될 수 있습니다. 그런 다음 캡처된 사용자 인증 정보를 사용하여 더 높은 계층의 머신을 공격하여 전체적인 영향을 확대할 수 있습니다.

이러한 파급 효과를 피하려면 머신을 분류할 뿐만 아니라 사용자 계정을 분류하고 해당 사용자가 액세스할 수 있는 머신 세트를 제한해야 합니다.

• 계층 0(매우 중요): 계층 0 머신에 액세스할 수 있는 사용자

• 계층 1(중요): 계층 1 머신에 액세스할 수 있는 사용자

• 계층 2(일반): 계층 2 머신에 액세스할 수 있는 사용자

사용자가 어떤 리소스에 액세스해야 하는지에 대한 가이드라인으로 다음 표를 참조하세요.

그룹	등급	도메인 액세스	계층 0 컴퓨터 액세스	계층 1 컴퓨터 액세스	계층 2 컴퓨터 액세스
Active Directory 관리자	0	관리자	제한된 사용자	차단됨	차단됨
관리 서버 관리자	0	제한된 사용자	관리자	차단됨	차단됨
서버 관리자	1	제한된 사용자	차단됨	관리자	차단됨
VDI 워크스테이션 관리자	2	제한된 사용자	차단됨	차단됨	관리자
VDI 워크스테이션 사용자	2	제한된 사용자	차단됨	차단됨	제한된 사용자

Active Directory에서 관리 계층 모델을 구현하는 방법에 대한 자세한 내용과 권장사항은 Microsoft 설명서를 참조하세요.

Active Directory 포리스트에서 관리 계층 모델을 사용하는 경우 포리스트 트러스트 관계로 인해 모델의 무결성이 손상되지 않아야 합니다. 트러스트 포리스트가 계층형 관리 모델도 적용하는 경우 선택적 인증을 사용하여 트러스트 포리스트의 사용자가 동일한 계층 내의 리소스에만 액세스할 수 있도록 하세요.

트러스트 포리스트가 계층형 관리를 구현하지 않으면 트러스트 포리스트를 특정 계층에 매핑하고 선택적 인증을 사용하여 트러스트 포리스트의 사용자만 해당 특정 계층의 리소스에만 액세스할 수 있도록 하세요.

온프레미스 호스트에 VPC 서비스 제어 및 비공개 Google 액세스 사용

관리형 Microsoft AD API를 사용하면 관리자 비밀번호를 재설정하고 다른 중요한 작업을 수행할 수 있습니다. 중요한 프로덕션 배포의 경우 보안을 강화하기 위해 VPC 서비스 제어를 사용 설정하고 온프레미스 호스트에 비공개 Google 액세스를 사용하는 것이 좋습니다.

관리

다음 섹션에서는 Active Directory 관리와 관련된 권장사항을 자세히 설명합니다.

Google Cloud 및 Active Directory 리소스 구조 조정

Google Cloud에 새 Active Directory 도메인이나 포리스트를 배포할 때 Active Directory 도메인으로 리소스를 구성하려면 조직 단위(OU) 구조를 정의해야 합니다. 완전히 새로운 구조를 설계하거나 온프레미스 환경에서 사용하는 구조를 적용하는 대신Google Cloud 리소스 계층 구조에 맞는 OU 구조를 만듭니다.

• 계층형 관리 모델을 사용하는 경우 최상위 OU에는 관리 계층이 반영되어야 합니다.

• 각 계층에 대해 사용자 및 그룹의 OU를 만듭니다. 다수의 사용자 및 그룹을 관리하려는 경우 적절하게 하위 OU를 만듭니다.

• 각 계층마다 Projects OU를 만들고 Active Directory 리소스가 포함된 각 Google Cloud 프로젝트에 대한 하위 OU를 만듭니다. 프로젝트별 하위 OU를 사용하여 컴퓨터 계정, 서비스 계정 또는 각 프로젝트의 Google Cloud리소스에 해당하는 기타 Active Directory 리소스를 관리합니다. OU와 프로젝트 간에 1:1 매핑이 있는지 확인하세요.

다음 다이어그램은 이러한 원칙을 따르는 예시 계층 구조를 보여줍니다.

Active Directory 리소스가 포함된 프로젝트 수가 중간이면 Projects OU 아래에서 플랫 OU 구조를 만들 수 있습니다. 다수의 프로젝트를 관리하고 여러 수준의 폴더를 사용하도록Google Cloud 리소스 계층 구조를 설계한 경우 이 폴더 구조를 Projects OU 아래에 반영하는 것이 좋습니다.

Active Directory OU 구조와 Google Cloud 리소스 계층 구조를 조정하면 다음과 같은 몇 가지 장점이 있습니다.

• IAM 정책을 사용하여 Google Cloud 프로젝트에 관리 권한을 위임할 경우 Active Directory에서 프로젝트 사용자에게 특정 권한을 부여해야 할 수도 있습니다. 예를 들어 Compute Engine 관리자가 머신을 특정 OU의 도메인에 조인할 수 있어야 합니다. OU와 Google Cloud 프로젝트를 조정하면 Active Directory에서 Google Cloud와 동일한 세부 수준으로 이러한 권한을 부여할 수 있습니다.

• 그룹 정책 개체(GPO)를 사용하여 컴퓨터를 관리하려는 경우 Google Cloud 리소스 계층 구조를 반영하는 OU 구조를 사용하면 지정된 프로젝트나 폴더의 모든 VM에 GPO를 일관되게 적용할 수 있습니다.

• 조건부 인증으로 포리스트 간 트러스트를 사용하는 경우 Google Cloud 프로젝트에 해당하는 OU를 사용하여 프로젝트별로 인증할 수 있는 권한을 부여할 수 있습니다.

• Google Cloud에서 프로젝트를 삭제하면 연결된 OU를 삭제하기만 하면 되므로 디렉터리에 비활성 리소스가 남을 위험이 줄어듭니다.

OU 구조를 현재 프로젝트 구조에서 변경해야 한다고 생각되면 프로젝트 구조가 너무 세밀하거나 너무 대략적이라는 것을 나타낼 수 있습니다.

Google 시간 서버 사용

Kerberos 인증은 프로토콜의 일부로 타임스탬프에 의존합니다. 인증이 성공하려면 클라이언트와 서버 머신의 시계가 특정 한도 내에서 동기화되어야 합니다. 기본적으로 Active Directory는 5분의 차이를 허용하지 않습니다.

온프레미스 Active Directory 환경에서 시간 동기화를 위한 기본 구성은 다음과 같습니다.

• 도메인 가입 머신은 도메인 컨트롤러와 시간을 동기화합니다.
• 도메인 컨트롤러는 도메인의 PDC 에뮬레이터와 시간을 동기화합니다.
• 모든 도메인의 PDC 에뮬레이터는 포리스트 루트 도메인의 PDC 에뮬레이터와 시간을 동기화합니다.

이 구성에서 포리스트 루트 도메인의 PDC 에뮬레이터는 궁극적인 Active Directory 시간 소스이며 일반적으로 이 머신을 구성하여 외부 NTP 서버를 시간 소스로 사용합니다.

Compute Engine에서 Windows VM의 기본 구성은 메타데이터 서버(metadata.google.internal)를 NTP 서버로 사용하는 것이며, Google의 NTP 서버에 의존하여 정확한 시간을 얻습니다. VM을 Active Directory 도메인에 조인해도 이 기본 구성은 변경되지 않습니다.

포리스트 루트 도메인의 PDC 에뮬레이터가 Google Cloud외부에 배포되지 않는 한 Compute Engine의 기본 구성을 유지합니다.

PDC 에뮬레이터가 Google Cloud외부에 배포되면 time.google.com를 NTP 소스로 사용하도록 구성합니다. 또는 Compute Engine VM을 DOMHIER NTP 소스를 사용하도록 재구성하고 도메인 컨트롤러에 대한 인바운드 NTP 인그레스 트래픽(UDP/123)을 허용하도록 방화벽 규칙을 구성하여 PDC 에뮬레이터와 시간을 동기화하는 기본 Active Directory 동작을 복원할 수 있습니다.

감사 로그 통합 및 모니터링

Google Cloud에 Active Directory를 배포하면 Active Directory 포리스트 및 Google Cloud 프로젝트의 보안이 다른 것과 연결됩니다. 즉, Active Directory 및 Windows의 의심스러운 활동은 Google Cloud 의 의심스러운 활동이 Active Directory를 위험에 처하게 할 수 있는 것과 마찬가지로 다른 리소스의 보안을 위협할 수 있습니다.

일관된 감사 로그는 위협이나 구성 오류를 조기에 식별하고 과거 활동을 재구성하고 검토할 수 있는 중요한 도구입니다. Cloud Audit Logging을 사용하면 관리자 활동 로그 및 데이터 액세스 로그를 캡처하고 분석할 수 있습니다. 마찬가지로 방화벽 규칙 로깅 및 VPC 흐름 로그를 사용하여 네트워킹 트래픽을 분석할 수 있습니다. 하지만 이러한 플랫폼 서비스는 Active Directory에서 발생하는 보안 관련 이벤트를 인식하지 못합니다. 플랫폼 관련 감사 이벤트와 Active Directory 관련 감사 이벤트를 모두 포함하는 일관된 감사 추적을 설정하려면 도메인 컨트롤러와 도메인 가입 머신에 Cloud Logging 에이전트를 설치하여 Windows 보안 이벤트 로그를 Cloud Logging으로 내보냅니다.

기본적으로 Windows 보안 이벤트 로그는 감사 목적으로 필요한 모든 이벤트를 캡처하지 못할 수도 있습니다. 관련 감사 이벤트를 모두 캡처하려면 감사 정책 구성 및 보안 침해 신호의 Active Directory 모니터링에 대한 Microsoft 권장사항을 참조하세요.

많은 양의 이벤트를 처리할 때 중요한 이벤트를 놓치기 쉽습니다. 중요한 이벤트가 누락되지 않도록 특히 중요하거나 의심스러운 이벤트에 대해 로그 기반 측정항목을 만들고 이벤트 비율이 변경되거나 허용 가능한 임곗값을 초과할 때 알리도록 알림을 구성하는 것이 좋습니다.

다음 단계

• 현재 상황에 가장 적합한 하이브리드 환경에서 Active Directory 사용 패턴 찾기

• 자동으로 도메인에 가입하도록 VM용 Active Directory를 구성하는 방법 알아보기

• 직접 다른 Google Cloud 기능 사용해 보기. Google 튜토리얼 참조