이 문서에서는 Active Directory를 Google Cloud에 배포할 때 고려해야 할 요구사항을 설명합니다. 또한 이 문서를 통해 올바른 아키텍처를 선택할 수 있습니다.
Active Directory를 Cloud ID 또는 Google Workspace와 페더레이션하면(관련 문서 참조) 기존 Active Directory 도메인의 사용자가 Google Cloud의 리소스를 인증하고 액세스할 수 있습니다. 또한 Active Directory를 사용하여 Google Cloud에서 Windows 서버를 관리하거나 Google Cloud에서 지원되지 않는 프로토콜을 사용하려는 경우에는 Active Directory를 Google Cloud에 배포하면 됩니다.
Active Directory를 Google Cloud에 배포하기 전에 먼저 사용할 도메인과 포레스트 아키텍처와 기존 Active Directory 포레스트와의 통합 방법을 결정해야 합니다.
요구사항 평가
Active Directory는 다양한 도메인 및 포레스트 아키텍처를 지원합니다. 하이브리드 환경에서의 한 가지 옵션은 단일 Active Directory 도메인을 여러 환경으로 확장하는 것입니다. 또는 트러스트를 사용하여 별도의 도메인이나 포레스트를 연결할 수도 있습니다. 가장 적합한 아키텍처는 요구사항에 따라 다릅니다.
최상의 아키텍처를 선택하려면 다음 요소를 고려해야 합니다.
- 기존 보안 영역과 일치
- 온프레미스 및 Google Cloud 리소스 간의 상호작용
- 관리 자율성
- 가용성
다음 섹션에서는 이러한 요소를 설명합니다.
기존 보안 영역과 일치
온프레미스 네트워크 설계 검토부터 시작합니다.
온프레미스 환경에서는 네트워크가 여러 보안 영역으로 분할되었을 수 있습니다(예: 별도의 VLAN 또는 서브넷 사용). 보안 영역으로 분할된 네트워크에서 동일한 보안 영역 내 통신은 제한되지 않거나 가벼운 방화벽 및 감사 정책이 적용됩니다. 이와 달리 서로 다른 보안 영역 간의 통신에는 엄격한 방화벽, 감사 또는 트래픽 검사 정책이 적용됩니다.
보안 영역은 네트워크 통신 제한 및 감사 이상의 용도로 사용됩니다. 하지만 보안 영역에서 트러스트 경계를 구현해야 합니다.
트러스트 경계
네트워크의 각 머신에서 여러 프로세스를 실행합니다. 이러한 프로세스는 프로세스 간 통신을 사용하여 로컬에서 서로 통신할 수 있으며 HTTP와 같은 프로토콜을 사용하여 머신 간에 통신할 수 있습니다. 이러한 통신 웹에서 피어는 항상 서로를 같은 수준으로 트러스트하지는 않습니다. 예를 들어 같은 머신에서 실행되는 프로세스가 다른 머신에서 실행되는 프로세스보다 높은 트러스트를 받을 수 있습니다. 또한 일부 머신이 다른 머신보다 더 높은 트러스트를 받을 수도 있습니다.
트러스트 경계는 한 통신 당사자 집합을 다른 당사자 집합보다 더 트러스트함으로써 통신 당사자를 구분합니다.
트러스트 경계는 공격의 영향을 억제하는 데 있어 매우 중요합니다. 시스템이 단일 프로세스인지 또는 전체 머신인지 여부에 관계없이 일단 단일 시스템이 침해되면 공격이 한 번에 끝나는 경우가 거의 없습니다. 공격자가 공격을 다른 시스템으로 확대할 가능성이 높습니다. 트러스트 경계 안에 있는 시스템은 서로를 구분하지 않으므로 트러스트 경계를 넘어 시스템을 공격하는 것보다 트러스트 경계 안에서 공격을 확산시키는 편이 휠씬 쉽습니다.
트러스트 영역 내 시스템이 침해되면 트러스트 경계 안의 다른 모든 시스템도 침해된 것으로 간주해야 합니다. 이렇게 가정하면 트러스트 경계를 식별하거나 특정 시스템 경계가 트러스트 경계인지 여부를 확인할 수 있습니다. 예를 들면 다음과 같습니다.
공격자가 대상 A에 대한 최고 수준의 액세스 권한(예: 관리자 또는 머신/애플리케이션에 대한 루트 액세스 권한)을 획득했다고 가정합니다. 공격자가 이러한 권한을 사용하여 대상 B에 대해 동일한 수준의 액세스 권한을 확보할 수 있다면 A와 B는 같은 트러스트 경계 안에 있는 것입니다. 그렇지 않으면 A와 B 사이에 트러스트 경계가 있는 것입니다.
네트워크 통신을 제한하면 보안 영역을 통해 트러스트 경계를 구현할 수 있습니다. 그러나 보안 영역이 진정한 트러스트 경계가 되려면 경계 각 측면의 작업 부하가 동일한 보안 영역에서 시작된 요청과 서로 다른 보안 영역에서 시작된 요청을 구분하고 후자를 더욱 면밀하게 조사해야 합니다.
제로 트러스트 모델
제로 트러스트 모델은 Google Cloud에서 선호하는 네트워킹 모델입니다.
트러스트 경계 안에 있는 단일 시스템이 침해되면 경계 내 모든 시스템이 침해되었다고 가정할 수 있습니다. 이 가정에 따라 트러스트 경계는 작을수록 더 좋습니다. 트러스트 경계가 작을수록 시스템이 침해될 가능성이 낮아지고 공격자가 공격을 확산시키기 위해 처리해야 할 경계 수가 많아집니다.
제로 트러스트 모델은 이러한 아이디어를 바탕으로 논리적인 결론을 도출합니다. 네트워크의 각 머신은 고유한 보안 영역과 트러스트 경계로 처리됩니다. 머신 간의 모든 통신에는 동일한 조사와 방화벽이 적용되며 모든 네트워크 요청은 신뢰할 수 없는 출처에서 발생한 것으로 처리됩니다.
방화벽 규칙을 사용하여 트래픽을 제한하고 VPC 흐름 로그와 방화벽 규칙 로깅을 사용하여 트래픽을 분석하면 네트워킹 수준에서 제로 트러스트 모델을 구현할 수 있습니다. 애플리케이션 수준에서는 모든 애플리케이션이 일관되고 안전하게 인증, 승인, 감사를 처리하도록 해야 합니다.
Active Directory의 트러스트 경계
Active Directory 도메인에서 머신은 도메인 컨트롤러가 인증 및 승인을 대신 처리하도록 트러스트합니다. 사용자가 도메인 컨트롤러 중 하나에서 자신의 ID를 확인하면 기본적으로 동일한 도메인의 모든 머신에 로그인할 수 있습니다. 도메인 컨트롤러에서 (권한 및 그룹 멤버십의 형태로) 사용자에게 부여한 모든 액세스 권한은 도메인 내 여러 머신에 적용됩니다.
그룹 정책을 사용하면 사용자가 특정 머신에 액세스할 수 없게 하거나 특정 머신에서 사용자 권한을 제한할 수 있습니다. 하지만 머신 한 개가 침해당하면 공격자는 동일한 머신에 로그인한 다른 도메인 사용자의 비밀번호, 비밀번호 해시 또는 Kerberos 토큰을 훔칠 수 있습니다. 그런 다음 이러한 사용자 인증 정보를 활용하여 공격을 포레스트의 다른 도메인으로 확산시킬 수 있습니다.
이러한 요소를 감안할 때 포레스트 내 모든 머신이 같은 트러스트 보안 경계 안에 있다고 가정하는 것이 가장 좋습니다.
복제 제어 및 관리 자율성 부여가 목적인 도메인 경계와 비교해보면 포리스트 경계가 더 강력한 격리 효과를 제공할 수 있습니다. 포레스트는 트러스트 경계 역할을 수행할 수 있습니다.
Active Directory 포레스트 및 보안 영역 일치
포레스트를 트러스트 경계로 가정하면 보안 영역 설계가 영향을 받습니다. 포레스트가 보안 영역 두 개로 확장되면 공격자가 이들 보안 영역 간의 경계를 더욱 쉽게 처리할 수 있습니다. 따라서 두 보안 영역이 효과적으로 하나가 되어 단일 트러스트 경계를 형성합니다.
제로 트러스트 모델에서는 네트워크의 각 머신을 개별 보안 영역으로 간주할 수 있습니다. 이러한 네트워크에 Active Directory를 배포하면 이 개념이 훼손되고 Active Directory 포레스트의 모든 머신이 포함되도록 유효한 보안 경계가 확장됩니다.
보안 영역을 트러스트 영역으로 사용하려면 전체 Active Directory 포레스트가 보안 영역 안에 있는지 확인해야 합니다.
Active Directory를 Google Cloud로 확장할 때의 영향
Active Directory가 필요한 Google Cloud에 배포하려는 경우 다음 두 옵션 중에서 하나를 선택하여 배포를 기존 보안 영역과 일치시켜야 합니다.
기존 보안 영역을 Google Cloud로 확장합니다. Google Cloud에서 공유 VPC를 프로비저닝하고 Cloud VPN 또는 Interconnect를 사용하여 기존 영역에 연결하면 기존 보안 영역 한 개 이상을 Google Cloud로 확장할 수 있습니다.
공통 영역을 공유하는 온프레미스 및 Google Cloud에 배포된 리소스도 공통 Active Directory 포리스트를 공유할 수 있으므로 별도의 포리스트를 Google Cloud에 배포할 필요가 없습니다.
예를 들어 개발 DMZ 및 프로덕션 DMZ가 보안 영역으로 있고 각 보안 영역마다 개별 Active Directory 포리스트가 있는 기존 네트워크가 있다고 가정합니다. 보안 영역을 Google Cloud로 확장하면 Google Cloud의 모든 배포도 이러한 두 보안 영역 중 하나에 속하며 동일한 Active Directory 포레스트를 사용할 수 있습니다.
새로운 보안 영역을 도입합니다. 보안 영역 확장이 적용되지 않을 수도 있습니다. 영역을 더 확장하지 않으려고 하거나 기존 보안 영역의 보안 요구사항과 Google Cloud 배포 요구사항과 일치하지 않기 때문입니다. Google Cloud를 추가 보안 영역으로 처리할 수 있습니다.
예를 들어 DMZ가 있지만 개발 워크로드와 프로덕션 워크로드를 구분하지 않는 온프레미스 환경이 있다고 가정합니다. Google Cloud에서 이러한 워크로드를 분리하려면 공유 VPC를 두 개 만들어 새 보안 영역으로 간주하면 됩니다. 그런 다음 보안 영역 한 개마다 Active Directory 포레스트를 두 개 추가하여 Google Cloud에 배포합니다. 필요한 경우 포레스트 간의 트러스트 관계를 설정하여 여러 보안 영역에서 인증을 사용 설정할 수 있습니다.
온프레미스 및 Google Cloud 리소스 간의 상호작용
Active Directory를 Google Cloud로 확장할 때 고려해야 할 두 번째 요소는 온프레미스와 Google Cloud 간의 사용자와 리소스의 상호작용입니다. 사용 사례에 따라 이 상호작용은 약한 상호작용, 중간 상호작용, 강한 상호작용일 수 있습니다.
약한 상호작용
Google Cloud에서 Active Directory를 사용하는 유일한 목적이 Windows 서버군을 관리하고 관리자가 이러한 서버에 로그인할 수 있도록 하는 것이라면 이는 환경 간의 약한 상호작용입니다.
- Google Cloud의 리소스와 상호작용하는 직원 집합은 관리 직원으로 제한됩니다.
- Google Cloud에 배포된 애플리케이션은 온프레미스 애플리케이션과 전혀 상호작용하지 않을 수 있고 Kerberos 및 NTLM과 같은 Windows 인증 기능을 사용하지 않고 상호작용할 수도 있습니다.
약한 상호작용 상황에서는 다음 두 가지 방법 중 하나로 온프레미스 환경과 Google Cloud 환경을 통합하는 것이 좋습니다.
분리된 Active Directory 포레스트 두 개: 트러스트 관계를 공유하지 않는 개별 Active Directory 포레스트 두 개를 사용하여 두 환경을 분리할 수 있습니다. 관리자가 인증할 수 있도록 Google Cloud 포레스트에 개별 사용자 계정 집합을 유지합니다.
중복된 사용자 계정 집합을 유지하면 관리 부담이 늘어나고 직원 퇴사 시 계정 사용 중지를 잊을 수 있는 위험이 있습니다. 보다 나은 방식은 이러한 계정을 자동으로 프로비저닝하는 것입니다.
온프레미스 Active Directory의 사용자 계정이 인사 관리 정보 시스템(HRIS)에서 프로비저닝되는 경우 이와 비슷한 메커니즘을 사용하여 Google Cloud 포레스트의 사용자 계정을 프로비저닝하고 관리할 수 있습니다. 또는 Microsoft ID 관리자와 같은 도구를 사용하여 서로 다른 환경 간에 사용자 계정을 동기화할 수도 있습니다.
포레스트 간 트러스트가 있는 Active Directory 포레스트 두 개: Active Directory 포레스트 두 개를 사용하고 포레스트 간 트러스트로 연결하면 중복 계정을 유지하지 않아도 됩니다. 관리자는 동일한 사용자 계정을 사용하여 두 환경 모두를 인증할 수 있습니다. 개별 포레스트를 사용하면 서로 다른 환경 간의 격리 수준이 약화될 수는 있습니다. 하지만 온프레미스 환경과 Google Cloud 환경 사이에 트러스트 경계를 유지할 수 있습니다.
중간 상호작용
사용 사례가 더 복잡할 수 있습니다. 예를 들면 다음과 같습니다.
- Google Cloud에 배포된 Windows 서버에 로그인하는 관리자가 온프레미스에 호스팅된 파일 공유에 액세스해야 할 수 있습니다.
- 애플리케이션에서 Kerberos 또는 NTLM을 사용하여 환경 경계를 넘어 인증하고 통신할 수 있습니다.
- 직원이 통합된 Windows 인증(IWA)을 사용하여 Google Cloud에 배포된 웹 애플리케이션을 인증하도록 허용할 수도 있습니다.
중간 시나리오에서 분리된 Active Directory 포리스트 두 개를 운영하면 제한이 너무 많을 수 있습니다. Kerberos를 사용하여 두 포리스트 간을 인증할 수 없습니다. NTLM 통과 인증을 사용하려면 사용자 계정과 비밀번호를 동기화된 상태로 유지해야 합니다.
이런 경우에는 포레스트 간 트러스트가 있는 Active Directory 포레스트 두 개를 사용하는 것이 좋습니다.
강한 상호작용
가상 데스크톱 인프라(VDI) 배포를 비롯한 특정 워크로드에서는 온프레미스 리소스와 Google Cloud에 배포된 리소스 간에 강한 상호작용이 필요할 수 있습니다. 서로 다른 환경의 리소스가 밀접하게 결합되어 있을 때 각 환경 간의 트러스트 경계 유지는 비현실적일 수 있으며, 포레스트 간 트러스트가 있는 포레스트 두 개를 사용하면 제한이 너무 많을 수 있습니다.
이런 경우에는 단일 Active Directory 포레스트를 사용하여 각 환경 간에 공유하는 것이 좋습니다.
관리 자율성
Active Directory를 Google Cloud로 확장할 때 고려해야 할 세 번째 요소는 관리 자율성입니다.
온프레미스와 Google Cloud에 워크로드를 배포하려는 경우 GCP에서 실행할 워크로드는 온프레미스에 유지되는 워크로드와 크게 다를 수 있습니다. 심지어 서로 다른 팀이 두 환경을 관리해야 할 수도 있습니다.
서로 다른 팀 간의 책임을 분리하려면 각 팀에 관리 자율성을 부여해야 합니다. Active Directory에서는 위임된 관리 또는 개별 도메인을 사용하여 팀에 리소스 관리 권한을 부여할 수 있습니다.
위임된 관리는 관리 책임을 위임하고 팀에 자율성을 부여할 수 있는 간단한 방법입니다. 단일 도메인을 유지해도 환경과 팀 전체에 걸쳐 일관성을 확보할 수 있습니다.
그러나 모든 관리 기능을 위임할 수 없으며 단일 도메인을 공유하면 팀 간 조정에 따른 관리 부담이 늘어날 수 있습니다. 이러한 경우에는 개별 도메인을 사용하는 것이 좋습니다.
가용성
Active Directory를 Google Cloud로 확장할 때 고려해야 할 마지막 요소는 가용성입니다. Active Directory 포레스트의 각 도메인에서 도메인 컨트롤러는 도메인 사용자의 ID 공급업체 역할을 수행합니다.
인증에 Kerberos를 사용할 경우 사용자는 다양한 지점에서 Active Directory 도메인 컨트롤러와 상호작용해야 합니다.
- 초기 인증(허용 티켓 수명 가져오기)
- 정기적인 재인증(허용 티켓 수명 새로고침)
- 리소스로 인증(서비스 티켓 가져오기)
초기 인증과 정기적인 재인증을 수행하려면 사용자가 속한 도메인의 도메인 컨트롤러와만 통신해야 합니다.
리소스로 인증할 때는 리소스가 있는 도메인에 따라 여러 도메인 컨트롤러와 상호작용해야 할 수도 있습니다.
- 리소스가 사용자와 같은 도메인에 있는 경우 사용자는 같은 도메인 컨트롤러(또는 같은 도메인의 서로 다른 도메인 컨트롤러)를 사용하여 인증 프로세스를 완료할 수 있습니다.
- 리소스가 다른 도메인에 있지만 사용자 도메인과 직접 트러스트 관계가 있는 경우 사용자는 리소스 도메인과 사용자 도메인에 각각 한 개씩 최소 두 개 이상의 도메인 컨트롤러와 상호작용해야 합니다.
- 리소스와 사용자가 서로 다른 도메인에 속하고 이러한 도메인 간에 간접 트러스트 관계만 있는 경우 성공적으로 인증하려면 트러스트 경로에 있는 모든 도메인의 도메인 컨트롤러와 통신해야 합니다.
서로 다른 Active Directory 도메인 또는 포레스트에서 사용자와 리소스를 찾으면 전체 가용성이 제약될 수 있습니다. 인증에는 여러 도메인과의 상호작용이 필요하므로 한 도메인의 가동이 중단되면 다른 도메인의 리소스 가용성이 영향을 받을 수 있습니다.
Active Directory 토폴로지가 가용성에 미칠 수 있는 잠재적 영향을 고려하여 Active Directory 토폴로지와 하이브리드 전략을 맞추는 것이 좋습니다.
분산된 작업 부하
각 컴퓨팅 환경의 고유한 기능을 활용하기 위해 하이브리드 방식으로 각 환경에 워크로드를 분산시킬 수 있습니다. 이러한 설정에서 Google Cloud에 배포하는 워크로드는 온프레미스로 실행되는 다른 인프라 또는 애플리케이션에 따라 다를 수 있으므로 가용성이 높은 하이브리드 연결은 중요한 요구사항이 됩니다.
개별 Active Directory 포레스트 또는 도메인을 Google Cloud에 배포하고 트러스트를 사용하여 온프레미스 Active Directory에 연결할 때는 Google Cloud와 온프레미스 환경 간에 또 다른 종속 항목을 추가합니다. 이 종속 항목은 가용성에 영향을 최소한으로 미칩니다.
중복 워크로드
비즈니스 연속성을 보장하기 위해 Google Cloud를 사용하는 경우 Google Cloud 워크로드는 온프레미스 환경의 일부 워크로드를 미러링합니다. 이러한 설정에서는 장애 발생 시 한 환경이 다른 환경의 역할을 넘겨받을 수 있습니다. 따라서 이러한 환경 간 모든 종속 항목을 살펴봐야 합니다.
개별 Active Directory 포레스트 또는 도메인을 Google Cloud에 배포하고 트러스트를 사용하여 온프레미스 Active Directory에 연결할 때는 설정 목적을 약화시키는 종속 항목을 만들 수 있습니다. 온프레미스 Active Directory를 사용할 수 없게 되면 도메인 간 또는 포레스트 간 인증을 사용하는 Google Cloud에 배포된 모든 워크로드 역시 사용할 수 없게 됩니다.
비즈니스 연속성을 보장하는 것이 목표라면 서로 연결되지 않은 각 환경에서 개별 Active Directory 포레스트를 사용하면 됩니다. 또는 기존 Active Directory 도메인을 Google Cloud로 확장할 수 있습니다. Google Cloud에 도메인 컨트롤러를 추가로 배포하고 각 환경 간에 디렉터리 콘텐츠를 복제하면 각 환경을 격리된 상태로 운영할 수 있습니다.
통합 패턴
요구사항을 평가한 후에는 다음 결정 트리를 사용하여 적합한 포레스트 및 도메인 아키텍처를 식별할 수 있습니다.
다음 섹션에서는 이러한 각 패턴을 설명합니다.
동기화 포레스트
동기화 포레스트 패턴에서는 Google Cloud에 개별 Active Directory 포레스트를 배포합니다. 이 포레스트를 사용하면 Google Cloud에 배포된 모든 리소스와 이러한 리소스를 관리하는 데 필요한 사용자 계정을 관리할 수 있습니다.
새 포레스트와 기존의 온프레미스 포레스트 사이에서 트러스트를 만드는 대신 계정을 동기화합니다. HRIS를 주도하는 시스템으로 사용하여 사용자 계정을 관리할 경우, Google Cloud 호스팅 Active Directory 포레스트에서 사용자 계정을 프로비저닝하도록 HRIS를 구성할 수 있습니다. 또는 Microsoft ID 관리자와 같은 도구를 사용하여 각 환경 간에 사용자 계정을 동기화할 수도 있습니다.
다음 중 하나 이상에 해당되는 경우 동기화 포리스트 패턴을 사용하는 것이 좋습니다.
- Google Cloud 용도가 중복 배포 패턴 중 하나에 부합되며 온프레미스 환경과 Google Cloud 간의 런타임 종속 항목을 피하려는 경우
- 특정 환경을 더 많이 트러스트하기 때문에 또는 심층 방어 수단으로 사용하기 위해 온프레미스 Active Directory 환경과 Google Cloud 호스팅 Active Directory 환경 간에 트러스트 경계를 유지하려는 경우
- 온프레미스 및 Google Cloud의 Active Directory 관리형 리소스 간의 상호작용이 약하거나 없을 것으로 예상되는 경우
- Google Cloud 호스팅 Active Directory 환경에서 필요한 사용자 계정 수가 적은 경우
장점:
- 동기화 포레스트 패턴을 사용하면 두 Active Directory 환경 간에 강력한 격리 상태를 유지할 수 있습니다. 공격자가 한 환경을 침해하는 데 성공하더라도 두 번째 환경 공격에 대한 이점을 거의 얻을 수 없습니다.
- Active Directory를 작동하기 위해 온프레미스 네트워크와 Google Cloud 네트워크 간에 하이브리드 연결을 설정할 필요가 없습니다.
- Google Cloud 호스팅 Active Directory가 온프레미스 Active Directory 가동 중단에 의한 영향을 받지 않습니다. 이 패턴은 비즈니스 연속성 사용 사례 또는 고가용성이 필요한 경우에 매우 적합합니다.
- Google Cloud 호스팅 Active Directory 포리스트 관리팀에 높은 수준의 관리 자율성을 부여할 수 있습니다.
- 이 패턴은 Microsoft Active Directory의 관리형 서비스에서 지원됩니다.
권장사항:
- 두 Active Directory 포레스트 간에 사용자 계정 비밀번호를 동기화하지 마세요. 환경 간의 격리 상태가 훼손될 수 있습니다.
- 사용자 계정 비밀번호를 동기화해야 하므로 통과 인증을 사용하지 마세요.
- 직원이 퇴사할 때 두 Active Directory 환경의 계정이 사용 중지되거나 삭제되었는지 확인합니다.
리소스 포레스트
리소스 포레스트 패턴에서는 개별 Active Directory 포레스트를 Google Cloud에 배포합니다. 이 포레스트를 사용하여 Google Cloud에 배포된 모든 리소스와 포레스트 관리에 필요한 최소한의 관리 사용자 계정 집합을 관리합니다. 기존 온프레미스 Active Directory 포레스트에 포레스트 트러스트를 설정하면 기존 포레스트의 사용자가 Google Cloud 호스팅 Active Directory 포레스트에서 관리되는 리소스를 인증하고 액세스할 수 있습니다.
필요한 경우 이 패턴을 기존 Active Directory 포레스트가 중앙에 있으면서 여러 리소스 포레스트와 연결된 허브/스포크 토폴로지로 발전시킬 수 있습니다.
다음 중 하나 이상에 해당되는 경우 리소스 포리스트 패턴을 사용하는 것이 좋습니다.
- Google Cloud 용도가 분산형 배포 패턴 중 하나에 부합되며 온프레미스 환경과 Google Cloud 간에 종속 항목이 허용되는 경우
- 특정 환경을 더 많이 트러스트하기 때문에 또는 심층 방어 수단으로 사용하기 위해 온프레미스 Active Directory 환경과 Google Cloud 호스팅 Active Directory 환경 간에 트러스트 경계를 유지하려는 경우
- 온프레미스 및 Google Cloud의 Active Directory 관리형 리소스 간에 중간 수준의 상호작용이 예상되는 경우
- Google Cloud에 배포된 리소스에 액세스해야 하는 사용자 수가 많은 경우(예: 인증에 IWA를 사용하는 웹 애플리케이션에 대한 액세스)
장점:
- 리소스 포레스트 패턴을 사용하면 두 Active Directory 환경 간에 트러스트 경계를 유지할 수 있습니다. 트러스트 관계 구성 방법에 따라 공격자가 한 환경을 침해하더라도 다른 환경에 거의 또는 전혀 액세스하지 못할 수 있습니다.
- 이 패턴은 관리형 Microsoft AD에서 완벽하게 지원됩니다.
- Google Cloud 호스팅 Active Directory 포리스트 관리팀에 높은 수준의 관리 자율성을 부여할 수 있습니다.
권장사항:
- 단방향 트러스트를 사용하여 두 Active Directory 포리스트를 연결하면 Google Cloud 호스팅 Active Directory가 기존 Active Directory를 트러스트하지만 그 반대로는 트러스트하지 않습니다.
- 선택적 인증을 사용하면 온프레미스 Active Directory의 사용자가 액세스할 수 있는 Google Cloud 호스팅 Active Directory의 리소스를 제한할 수 있습니다.
- 중복 Dedicated Interconnect, Partner Interconnect 또는 Cloud VPN 연결을 사용하면 온프레미스 네트워크와 Google Cloud 간의 가용성이 높은 네트워크 연결을 보장할 수 있습니다.
확장 도메인
확장 도메인 패턴에서는 하나 이상의 기존 Active Directory 도메인을 Google Cloud로 확장합니다. 각 도메인에서 하나 이상의 도메인 컨트롤러를 Google Cloud에 배포하면 모든 도메인 데이터와 전역 카탈로그가 복제되어 Google Cloud에서 사용할 수 있게 됩니다. 온프레미스 서브넷과 Google Cloud 서브넷에 개별 Active Directory 사이트를 사용하면 클라이언트가 자신과 가장 가까운 도메인 컨트롤러와 통신할 수 있습니다.
다음 중 하나 이상에 해당되는 경우 확장 도메인 패턴을 사용하는 것이 좋습니다.
- Google Cloud 용도가 중복 배포 패턴 중 하나에 부합되며 온프레미스 환경과 Google Cloud 간의 런타임 종속 항목을 피하려는 경우
- 온프레미스 및 Google Cloud의 Active Directory 관리형 리소스 간에 강한 상호작용이 예상되는 경우
- 인증에 LDAP를 사용하는 애플리케이션의 인증 속도를 높이려는 경우
장점:
- Google Cloud 호스팅 Active Directory가 온프레미스 Active Directory 가동 중단에 의한 영향을 받지 않습니다. 이 패턴은 비즈니스 연속성 사용 사례 또는 고가용성이 필요한 경우에 매우 적합합니다.
- 온프레미스 네트워크와 Google Cloud 간의 통신을 제한할 수 있습니다. 이렇게 하면 잠재적으로 대역폭을 절약하고 지연 시간을 단축시킬 수 있습니다.
- 전역 카탈로그의 모든 콘텐츠가 Active Directory에 복제되므로 Google Cloud 호스팅 리소스에서 효율적으로 액세스할 수 있습니다.
권장사항:
- 모든 도메인을 복제할 경우 온프레미스 네트워크와 Google Cloud 네트워크 간의 통신이 도메인 컨트롤러 간의 Active Directory 복제로 제한됩니다. 포레스트 도메인의 일부만 복제할 경우 Google Cloud에서 실행 중인 도메인 조인 서버가 복제되지 않는 도메인의 도메인 컨트롤러와 계속 통신해야 할 수 있습니다. 온프레미스와 Google Cloud 간의 통신에 적용되는 방화벽 규칙에서 모든 관련 사례를 고려해야 합니다.
- 사이트 간 복제가 특정 간격으로 수행되므로 온프레미스 도메인 컨트롤러에서 수행된 업데이트는 일정 시간 지연 후 Google Cloud에 반영됩니다(그 반대의 경우도 마찬가지임).
- 읽기 전용 도메인 컨트롤러(RODC)를 사용하면 Google Cloud에서 도메인 데이터의 읽기 전용 사본을 유지할 수 있습니다. 하지만 사용자 비밀번호 캐싱과 관련된 상쇄 효과가 있다는 점을 알고 있어야 합니다. RODC가 비밀번호를 캐시하고 비밀번호 캐시를 미리 채우도록 허용하면 Google Cloud에 배포된 리소스가 온프레미스 도메인 컨트롤러 가동 중단에 의한 영향을 받지 않습니다. 그러나 일반 도메인 컨트롤러 대신 RODC를 사용할 때의 보안상 이점이 줄어듭니다. 비밀번호 캐싱을 사용 중지하면 침해된 RODC가 나머지 Active Directory에 제한적 위험을 초래할 수 있으며 나머지 Google Cloud는 온프레미스 도메인 컨트롤러 가동 중단에 의한 영향을 받게 됩니다.
확장 포레스트
확장 포레스트 패턴에서는 새로운 Active Directory 도메인을 Google Cloud에 배포하지만 이를 기존 포레스트에 통합합니다. 새 도메인을 사용하여 Google Cloud에 배포된 모든 리소스를 관리하고 도메인 관리에 필요한 최소한의 관리 사용자 계정 집합을 유지보수합니다.
암시적 트러스트 관계를 포레스트의 다른 도메인으로 확장하면 다른 도메인의 기존 사용자가 Google Cloud 호스팅 Active Directory 도메인에서 관리되는 리소스를 인증하고 액세스할 수 있습니다.
다음 중 하나 이상에 해당되는 경우 확장 포레스트 패턴을 사용하는 것이 좋습니다.
- GCP 용도가 분산형 배포 패턴 중 하나에 부합되며 온프레미스 환경과 Google Cloud 간에 종속 항목이 허용되는 경우
- Google Cloud에 배포할 리소스에 기존 도메인에서 제공하는 것과 다른 도메인 구성 또는 구조가 필요하거나 Google Cloud 호스팅 도메인 관리팀에 높은 수준의 관리 자율성을 부여하려는 경우
- 온프레미스 및 Google Cloud의 Active Directory 관리형 리소스 간에 중간 또는 강한 상호작용이 예상되는 경우
- Google Cloud에 배포된 리소스에 액세스해야 하는 사용자 수가 많은 경우(예: 인증에 IWA를 사용하는 웹 애플리케이션에 대한 액세스)
장점:
- 전역 카탈로그의 모든 콘텐츠가 Active Directory에 복제되므로 Google Cloud 호스팅 리소스에서 효율적으로 액세스할 수 있습니다.
- 온프레미스 네트워크와 Google Cloud 간의 복제 트래픽은 전역 카탈로그 복제로 제한됩니다. 전체 대역폭 소비를 제한하는 데 유용할 수 있습니다.
- Google Cloud 호스팅 Active Directory 도메인 관리팀에 높은 수준의 관리 자율성을 부여할 수 있습니다.
권장사항:
- 중복 Dedicated Interconnect, Partner Interconnect 또는 Cloud VPN 연결을 사용하면 온프레미스 네트워크와 Google Cloud 간의 가용성이 높은 네트워크 연결을 보장할 수 있습니다.
확장 도메인을 가진 리소스 포리스트
확장 도메인을 가진 리소스 포리스트 패턴은 리소스 포리스트 패턴이 확장된 것입니다. 리소스 포레스트 패턴을 사용하면 환경 간에 트러스트 경계를 유지하면서 관리 자율성을 부여할 수 있습니다. 온프레미스 도메인 컨트롤러의 가용성과 온프레미스 데이터 센터에 대한 안정적인 네트워크 연결에 따라 결정되는 전체 가용성에 의해 리소스 포레스트 한계가 결정됩니다.
리소스 포리스트 패턴을 확장 도메인 패턴과 결합하면 이러한 한계를 해결할 수 있습니다. 도메인을 복제하면 사용자 계정이 Google Cloud에 위치하므로 온프레미스 도메인 컨트롤러를 사용할 수 없거나 네트워크 연결이 끊어져도 사용자가 Google Cloud 호스팅 리소스를 인증할 수 있습니다.
다음 중 하나 이상에 해당되는 경우 확장 도메인을 가진 리소스 포레스트를 사용하는 것이 좋습니다.
- 기본 Active Directory 포레스트와 리소스 포레스트 간에 트러스트 경계를 유지하려는 경우
- 온프레미스 도메인 컨트롤러의 가동 중단 또는 온프레미스 환경에 대한 네트워크 연결 끊김이 Google Cloud 호스팅 워크로드에 영향을 주지 않도록 하려는 경우
- 온프레미스 및 Google Cloud의 Active Directory 관리형 리소스 간에 중간 상호작용이 예상되는 경우
- Google Cloud에 배포된 리소스에 액세스해야 하는 단일 Active Directory 도메인의 사용자 수가 많은 경우(예: 인증에 IWA를 사용하는 웹 애플리케이션에 대한 액세스)
장점:
- Google Cloud 호스팅 리소스가 온프레미스 Active Directory 가동 중단에 의한 영향을 받지 않습니다. 이 패턴은 비즈니스 연속성 사용 사례 또는 고가용성이 필요한 경우에 매우 적합합니다.
- 이 패턴을 사용하면 두 Active Directory 포레스트 간에 트러스트 경계를 유지할 수 있습니다. 트러스트 관계 구성 방법에 따라 공격자가 한 환경을 침해하더라도 다른 환경에 거의 또는 전혀 액세스하지 못할 수 있습니다.
- 온프레미스 네트워크와 Google Cloud 네트워크 간의 통신이 도메인 컨트롤러 간의 Active Directory 복제로 제한됩니다. 방화벽 규칙을 구현하여 다른 모든 통신을 허용하지 않음으로써 환경 간 격리 상태를 강화할 수 있습니다.
- Google Cloud 호스팅 Active Directory 포리스트 관리팀에 높은 수준의 관리 자율성을 부여할 수 있습니다.
- 리소스 포리스트에 관리형 Microsoft AD를 사용할 수 있습니다.
권장사항:
- 확장 도메인의 도메인 컨트롤러를 개별 Google Cloud 프로젝트와 VPC에 배포하여 이러한 구성요소를 리소스 포리스트의 구성요소에서 분리합니다.
- VPC 피어링을 사용하여 VPC를 리소스 포리스트에서 사용되는 공유 VPC 또는 VPC에 연결하고, 방화벽을 구성하여 Kerberos 사용자 인증 및 포리스트 트러스트 생성에 대한 통신을 제한합니다.
- 단방향 트러스트를 사용하여 두 Active Directory 포레스트를 연결하면 Google Cloud 호스팅 Active Directory가 기존 Active Directory 포레스트를 트러스트하지만 그 반대로는 트러스트하지 않습니다.
- 선택적 인증을 사용하면 다른 포레스트의 사용자가 액세스할 수 있는 리소스 포레스트의 리소스를 제한할 수 있습니다.
- 사이트 간 복제가 특정 간격으로 수행되므로 온프레미스 도메인 컨트롤러에서 수행된 업데이트는 일정 시간 지연 후 Google Cloud에 반영됩니다(그 반대의 경우도 마찬가지임).
- 확장 도메인에 RODC를 사용하는 것이 좋습니다. 그러나 리소스 포레스트 패턴과 비교 시의 가용성 이점을 유지하려면 비밀번호 캐싱을 허용해야 합니다.
다음 단계
- 관리형 Microsoft AD 자세히 알아보기
- Google Cloud에서 Active Directory 리소스 포리스트를 배포하기 위한 권장사항 살펴보기
- 내결함성이 있는 Active Directory 환경을 Google Cloud에 배포하는 방법 알아보기
- VPC 설계 권장사항을 살펴봅니다.
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터 살펴보기