이 페이지는 Cloud Translation API를 통해 번역되었습니다.

고객 관리 Active Directory (CMAD) 개요

MySQL | PostgreSQL | SQL Server

이 페이지에는 통합을 시작하기 전에 검토할 정보가 있습니다. 제한사항을 포함하여 다음 정보를 검토한 후 고객 관리형 Active Directory 사용을 참고하세요.

SQL Server용 Cloud SQL을 고객 관리 Microsoft Active Directory (고객 관리 AD (CMAD)라고도 함)와 통합할 수 있습니다.

CMAD를 통해 인증, 승인 등을 사용할 수 있습니다. 예를 들어 CMAD 도메인에 인스턴스를 조인하면 AD 기반 ID로 Windows 인증을 사용하여 로그인할 수 있습니다. SQL Server용 Cloud SQL을 AD 도메인에 통합하면 온프레미스 AD 도메인과 통합할 수 있다는 추가적인 이점이 있습니다. Google Cloud

시작하기 전에

CMAD와 통합하여 인스턴스에 Windows 인증 지원을 추가할 수 있습니다. 하지만 통합하려면Google Cloud 프로젝트에 다음이 필요합니다.

인증이 작동하려면 Cloud SQL 인스턴스가 모든 관련 Active Directory 도메인에 대한 네트워크 연결이 있어야 합니다. 여기에는 인스턴스가 조인하는 기본 도메인과 SQL Server용 Cloud SQL에 액세스해야 하는 사용자가 포함된 신뢰할 수 있는 도메인 또는 하위 도메인이 포함됩니다. 이를 사용 설정하려면 Cloud SQL 인스턴스와 모든 도메인 컨트롤러 간에 다음 포트 (TCP 및 UDP 모두)가 열려 있어야 합니다. 53, 88, 135, 389, 445, 464, 3268, 3269, 49152~65535
모든 관련 통합 객체를 저장하려면 조직 단위 (OU)를 만들어야 합니다.
- 이 OU 내에 다음 권한이 있는 관리자 계정도 필요합니다.
  - 컴퓨터 객체 만들기
  - 컴퓨터 객체 삭제
  - 사용자 객체 만들기
  - 사용자 객체 삭제
  - 모든 속성 작성
  - 비밀번호 재설정
  - 읽기 차단 시간, 쓰기 차단 시간
- 또한 이 관리자 계정에 DNS 레코드를 관리할 권한을 부여하는 것이 좋습니다(예: DnsAdmins 그룹에 추가).
  이러한 권한을 부여하지 않아도 통합은 성공합니다. 하지만 인스턴스에 연결하려면 사용자로 인스턴스에 연결에 설명된 대로 필요한 DNS 레코드를 수동으로 만들어야 합니다.
  
  인스턴스의 IP 주소를 사용하여 연결하는 방법도 있지만 제한사항이 있으며 신뢰할 수 있는 도메인에서 연결하는 데는 작동하지 않습니다.
다음 JSON 형식을 사용하여 Secret Manager 보안 비밀에 관리자 사용자 인증 정보를 저장해야 합니다.
```
    {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }
    
```
다음을 바꿉니다.
- VALID_AFTER_UTC_VALUE_1: 사용할 첫 번째 UTC 값입니다. YYYY-MM-DDThh:mm:ssZ 형식으로 제공됩니다. 예를 들어 2099-07-01T10:30:00Z일 수 있습니다.
- ADMINISTRATOR_LOGIN_VALUE_1: 사용할 첫 번째 관리자 로그인(예: myadmin) 값에 도메인 이름을 포함하지 마세요. myadmin@my-domain-name.com와 유사한 항목은 지원되지 않습니다.
- ADMINISTRATOR_PASSWORD_VALUE_1: 관리자 비밀번호입니다.
- VALID_AFTER_UTC_VALUE_2: 사용할 두 번째 UTC 값입니다. YYYY-MM-DDThh:mm:ssZ 형식으로 제공됩니다. 예를 들어 2099-07-01T10:30:00Z일 수 있습니다.
- ADMINISTRATOR_LOGIN_VALUE_2: 사용할 두 번째 관리자의 로그인입니다(예: myadmin2). 마찬가지로 값에 도메인 이름을 포함하지 마세요. myadmin2@my-domain-name.com와 유사한 항목은 지원되지 않습니다.
- ADMINISTRATOR_PASSWORD_VALUE_2: 두 번째 관리자의 비밀번호입니다.
이 파일에는 느린 전파 문제를 완화하거나 계획된 사전 순환을 수용하기 위해 여러 사용자 인증 정보 항목이 포함될 수 있습니다.

validAfterUTC 필드는 선택사항입니다. 지정하지 않으면 사용자 인증 정보가 항상 유효한 것으로 간주됩니다. 이러한 사용자 인증 정보를 Secret Manager에서 영구적으로 사용할 수 있도록 유지하고 사용자 인증 정보를 교체하는 경우 자동화를 사용하여 비밀번호를 업데이트하는 것이 좋습니다.

인스턴스를 만든 후 보안 비밀을 삭제할 수 있지만, 복제 또는 읽기 복제본 추가와 같은 향후 작업으로 인해 새 인스턴스가 도메인에 가입되지 않습니다.

또한 원본 인스턴스를 삭제하면 컴퓨터 계정과 같은 고아 객체가 CMAD에 남게 됩니다.
고객 관리 Active Directory의 DNS 서버 IP 주소 목록이 있어야 합니다. 일반적으로 도메인 컨트롤러입니다. 이러한 서버에는 고정 IP 주소를 사용하는 것이 좋습니다.
제품별, 프로젝트별 서비스 계정을 할당합니다.

서비스 계정 만들기 및 구성

필요한 권한이 있는 서비스 계정을 만들려면 다음을 확인하세요.

Cloud SQL Admin API를 사용 설정해야 합니다.
다음 권한이 있어야 합니다.
CMAD와 통합하려는 각 프로젝트의 제품별 프로젝트별 서비스 계정이 필요합니다. gcloud CLI를 사용하여 프로젝트 수준에서 계정을 만듭니다. 제품별 및 프로젝트별 서비스 계정에는 이전 단계에서 생성된 비밀에 대한 secretmanager.secrets.getIamPolicy 및 secretmanager.secrets.setIamPolicy 권한이 부여되어야 합니다. 자세한 내용은 Secret Manager 권한을 참고하세요.

필요한 권한이 있는 맞춤 역할을 만드는 것이 좋습니다.

gcloud CLI로 서비스 계정을 만들려면 다음 명령어를 실행합니다.

  gcloud beta services identity create --service=sqladmin.googleapis.com 

      --project=PROJECT_ID

이 명령어는 서비스 계정 이름을 다음 형식으로 반환합니다.

  service-PROJECT_ID@gcp-sa-cloud-sql.iam.gserviceaccount.com

다음은 서비스 계정 이름의 예시입니다.

  service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

통합에 필요한 권한을 부여하려면 다음 명령어를 실행합니다.

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

그런 후 다음 명령어를 실행하세요.

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

자세한 내용은 gcloud beta services identity create를 참고하세요.

CMAD와의 통합을 위한 권장사항

CMAD와 통합할 때는 다음 단계를 완료하는 것이 좋습니다.

통합을 위한 기본 요건

Active Directory 진단 도구를 사용하여 Google Cloud 콘솔에서 온프레미스 도메인 및 SQL Server용 Cloud SQL 인스턴스의 AD 설정 문제 해결 Microsoft Active Directory용 관리형 서비스와 관련된 단계를 건너뜁니다.

CMAD와 통합을 위한 토폴로지

SQL Server용 Cloud SQL은 도메인 로컬 그룹을 지원하지 않습니다. 하지만 다음과 같은 대안이 있습니다.

SQL Server에서 직접 전역 그룹 또는 개별 사용자 로그인 추가
모든 그룹과 사용자가 동일한 포리스트에 속하는 경우 범용 그룹을 사용합니다.

SQL Server용 Cloud SQL은 도메인 로컬 그룹을 로그인으로 지원하지 않습니다. 도메인 사용자에게 권한을 부여하려면 이 섹션에 설명된 대로 전역 또는 범용 그룹을 대신 사용해야 합니다.

옵션 1: 사용자 계정 및 그룹을 SQL Server에 로그인으로 추가

도메인, 포레스트, 전역 그룹이 여러 개 있으면 이 모든 개별 사용자 계정과 전역 및 범용 그룹을 SQL Server에 로그인으로 직접 추가할 수 있습니다. 옵션 1의 예시로 다음 다이어그램을 참고하세요.

CMAD 토폴로지, 옵션 1

옵션 2: 도메인 중 하나에서 범용 그룹 정의

도메인이 동일한 포레스트에 있으면 도메인 중 하나에 범용 그룹을 정의할 수 있습니다. 그런 후 모든 개별 사용자 계정과 전역 및 범용 그룹을 해당 정의된 범용 그룹의 하위 항목으로 추가하고 정의된 범용 그룹을 SQL Server 로그인으로 추가할 수 있습니다. 옵션 2의 예시로 다음 다이어그램을 참고하세요.

CMAD 토폴로지, 옵션 2

제한사항 및 대안

CMAD와 통합할 때 다음 제한사항이 적용됩니다.

비공개 연결에 Private Service Connect(PSC)를 사용하는 SQL Server용 Cloud SQL 인스턴스는 지원되지 않습니다. 대신 비공개 서비스 액세스(PSA)를 사용하세요.
도메인 로컬 그룹은 지원되지 않지만 SQL Server에서 전역 그룹 또는 개별 사용자 로그인을 직접 추가할 수 있습니다. 또는 모든 그룹과 사용자가 동일한 포리스트에 속하는 경우 범용 그룹을 사용할 수 있습니다.
추가 신뢰 도메인이 있고 여기에서 사용자 이름으로 SQL Server 인스턴스에 액세스하려는 경우 양방향 트러스트를 통해 연결해야 합니다. 단방향 및 외부 신뢰는 지원되지 않습니다.
일반적으로 Google Cloud 콘솔을 통해 생성된 새 사용자에게는 SQL Server 에이전트 고정 데이터베이스 역할 SQLAgentUserRole이 포함된 CustomerDbRootRole 역할이 할당됩니다. 그러나 CMAD 사용자와 같이 SQL Server를 통해 직접 생성된 사용자에게는 이러한 역할을 부여하거나 SQL Server Agent를 사용할 수 없습니다. 이러한 역할을 부여해야 하는 MSDB 데이터베이스가 보호되기 때문입니다.
정규화된 도메인 이름 (FQDN)은 SQL Server에서 지원되지 않습니다. 따라서 SQL Server 로그인을 만들 때 FQDN 대신 도메인 이름 (닉네임)을 사용합니다. 예를 들어 도메인 이름이 ad.mydomain.com인 경우 ad.mydomain.com\user가 아닌 ad\user의 SQL Server 로그인을 만듭니다.
SQL Server 인스턴스에 액세스하려면 항상 FQDN을 사용하세요. 예를 들어 private.myinstance.us-central1.myproject.cloudsql.mydomain.com과 비슷한 FQDN을 사용할 수 있습니다. Netbios 이름은 지원되지 않으며 DNS 서픽스가 생략된 경우에는 닉네임도 지원되지 않습니다.
Google Cloud 콘솔에서는 Active Directory 사용자 및 그룹을 기반으로 한 SQL Server 로그인을 관리할 수 없습니다.
Windows 인증은 외부 트러스트에서 작동되지 않습니다. 반환된 오류는 다음과 같을 수 있습니다.
```
  "The target principal name is incorrect. Cannot generate SSPI context."
  
```
또한 Microsoft 권장사항과 관련하여 Kerberos 인증을 위한 외부 트러스트 대신 포리스트 트러스트를 사용합니다.
항상 최신 버전의 보안 비밀이 사용됩니다. 보안 비밀은 활성 상태여야 하며 삭제할 수 없습니다.

Active Directory 엔드포인트 및 TLS 연결

Windows 인증을 사용하고 서버 인증서를 신뢰하지 않고 TLS 연결을 설정하려면 인스턴스에서 Windows 인증을 사용 설정한 후 인증서를 순환해야 합니다.

연결이 실패하고 인증서 중 하나가 2025년 3월 15일 전에 생성된 경우에는 서버 인증서를 다시 순환하고 연결을 다시 시도해야 합니다.

통합 지원되지 않음

다음 기능은 CMAD와 통합할 때 지원되지 않습니다.

도메인 로컬 그룹
NTLM 인증
트러스트 관계를 통해 연결된 도메인의 IP 주소로 로그인합니다.
긴 이름의 인스턴스 (63자 이상)

모니터링

다음 측정항목을 사용하여 CMAD 상태와 상태를 모니터링할 수 있습니다.

cloudsql.googleapis.com/database/active_directory/domain_reachable

이 측정항목은 Cloud SQL 인스턴스에서 CMAD에 연결할 수 있는지 여부를 보고합니다. 네트워크 문제를 해결하는 데 유용한 도구입니다.

cloudsql.googleapis.com/database/active_directory/instance_available