Amazon RDS for SQL Server DB 인스턴스를 기존 Active Directory 도메인에 통합하기

지난 해 부터 AWS는 SQL Server용 Amazon RDS에 대한 Windows 인증 지원을 시작했습니다. 이 기능은 꽤 많은 고객의 사랑을 받았으며, 자체 데이터 센터에서 사용하는 것과 동일한 중앙 집중식 사용자 관리 패턴(Microsoft Active Directory 활용)을 사용하여 Microsoft SQL Server 기반 워크로드를 Amazon RDS로 배포할 수 있습니다.

SQL Server용 Amazon RDS에서는 AWS Directory Service를 통해 제공되는 관리형 Active Directory 도메인에 신규 및 기존 DB 인스턴스를 연결할 수 있습니다. Amazon RDS가 완전 관리형 데이터베이스 인스턴스(SQL Server 포함)를 운영하는 기능을 제공하듯이, AWS Directory Service는 워크로드 배포 시 사용할 수 있는 완전 관리형 디렉터리를 제공합니다. 두 경우 모두 턴키 솔루션으로 제공됩니다. 서비스의 배포, 운영, 고가용성, 안정성 및 보안을 AWS가 처리하므로 고객은 자체 워크로드를 효과적으로 운영하는 가장 중요한 측면에 집중할 수 있습니다.

이 게시물에서는 포리스트 신뢰 관계를 사용하여 기존 Windows 인증 기능을 Amazon RDS를 사용하여 배포된 SQL Server 인스턴스로 확장하는 방법에 대해 설명합니다.

SQL Server용 Amazon RDS에서 AWS Directory Service 사용

AWS Directory Service는 각각 고유한 기능 세트를 포함하고 특정 사용 사례에 적합하도록 설계된 다수의 디렉터리 서비스 유형을 제공합니다. SQL Server용 RDS에서 Windows 인증 기능을 사용하려면 Microsoft AD(Active Directory) 디렉터리 서비스 유형을 사용해야 합니다.

Microsoft AD 디렉터리를 사용하면 완전 관리형 Active Directory 환경을 클라우드에 구축할 수 있습니다. 제공되는 도메인에 Amazon EC2 인스턴스를 연결하고 SQL Server용 RDS DB 인스턴스를 동일한 도메인에도 연결할 수 있습니다. 사용자, 그룹 및 정책을 관리형 도메인에서 직접 생성하고 관리할 수 있습니다. 결과적으로는 기존에 사용하던 Active Directory 환경과 매우 유사한 환경이 만들어집니다. 그러나 도메인 컨트롤러 또는 SQL Server 데이터베이스의 기반이 되는 리소스의 운영 측면을 매일 관리하는 데 시간을 허비하지 않아도 됩니다.

기존의 회사 Active Directory 도메인을 AWS의 VPC(가상 프라이빗 클라우드)에서 EC2 인스턴스를 사용하여 실행하거나, 데이터 센터에서 온프레미스로 실행하거나, 그 중간에서 확장된 상태로 실행하는 경우에도 SQL Server용 RDS와 Windows 인증을 사용할 수 있습니다. 사용자와 컴퓨터가 기존 도메인에 조인되어 있는 경우에도 마찬가지입니다.

포리스트 신뢰(Forest Trusts)

Microsoft AD 디렉터리를 사용하는 경우 포리스트 신뢰를 설정할 수 있습니다. RDS SQL Server 리소스를 AWS 관리형 Microsoft AD 디렉터리에 조인해야 하지만 해당 AWS 관리형 포리스트와 회사 도메인의 포리스트 간에 신뢰 관계를 설정할 수 있습니다. SQL Server용 RDS에서 Windows 인증이 작동하려면 AWS 관리형 포리스트가 회사 도메인 포리스트를 신뢰하는 단방향의 포리스트 신뢰만 설정하면 됩니다.

회사 도메인은 신뢰할 수 있는 도메인 역할을 하고 AWS Directory Service의 관리형 도메인은 신뢰하는 도메인의 역할을 합니다. 검증된 인증 요청은 도메인 사이에서 단일 방향으로만 이동하므로 회사 도메인의 계정을 관리형 도메인의 공유 리소스에 대해 인증할 수 있습니다. 이 경우 SQL Server용 RDS 리소스는 오로지 관리형 도메인과 상호 작용하며 관리형 도메인이 인증 요청을 회사 도메인에 전달합니다.

신뢰 관계 및 인증 흐름

다음 다이어그램은 SQL Server용 RDS 리소스와 회사 도메인의 사용자가 포함되는 신뢰 관계 흐름을 설명합니다.

다음은 신뢰 관계 흐름의 단계를 AWS 기반 리소스를 사용하여 설명한 것입니다.

최종 사용자가 회사 도메인에 조인된 Amazon EC2 인스턴스에 연결합니다.
인증 요청은 EC2 인스턴스에서 회사 도메인 컨트롤러로 흐릅니다.
최종 사용자가 회사 도메인 자격 증명을 사용하여 회사 도메인에 조인된 EC2 인스턴스에서 관리형 도메인에 조인된 SQL Server용 RDS DB 인스턴스에 연결합니다.
인증 요청은 RDS DB 인스턴스에서 관리형 도메인 컨트롤러로 흐릅니다.
두 개의 포리스트가 단방향 신뢰로 구성되었으므로 인증 요청은 관리형 도메인에서 회사 도메인 컨트롤러로 중계됩니다.

이 구성을 사용할 경우 회사 도메인 사용자가 관리형 도메인에 조인된 리소스에 SSO(Single Sign-On)를 사용하여 액세스할 수 있습니다. 회사 도메인의 애플리케이션 서비스 계정과 최종 사용자 계정 모두 관리형 도메인의 리소스에 인증할 수 있습니다. 따라서 애플리케이션 및 데이터베이스 관리자가 Windows 인증을 사용하여 회사 도메인의 리소스처럼 SQL Server용 RDS에 연결할 수 있습니다.

그러나 관리형 도메인에 사용자 계정을 생성하는 경우 해당 사용자는 현재의 신뢰 관계 구성을 사용하여 회사 도메인에 조인된 컴퓨터에 로그인하거나 해당 도메인의 리소스에 액세스할 수 없습니다. 그러므로 관리형 도메인에 위치한 악의적인 사용자로부터 회사 도메인이 보호됩니다.

연습: SQL Server용 RDS에서 사용할 포리스트 신뢰 관계 설정

이 연습에서는 회사 도메인이 있고 온프레미스로 배포되었거나, Amazon VPC로 확장되었거나, EC2 인스턴스의 Amazon VPC에 배포된 것으로 가정합니다.

참고: 회사 도메인에서 독립된 개념 증명을 배포하려는 경우 AWS 기반 Active Directory DS 빠른 시작의 배포를 사용하여 프로덕션 도메인과 분리된 초기 회사 도메인을 구성할 수 있습니다. 이 빠른 시작에는 상세한 배포 안내서도 포함되어 있습니다. 시나리오 1을 사용하여 이 연습의 단계를 수행할 수 있습니다.

시작하기 전에

연습을 완료하려면 AWS 환경 및 회사 도메인 배포에 최소한 다음이 포함되어야 합니다.

둘 이상의 서브넷이 서로 다른 가용 영역에 있는 VPC. 프라이빗 서브넷을 사용할 것을 권장합니다.
회사 도메인에 대한 하나 이상의 도메인 컨트롤러(도메인 전체에서 DNS 확인이 작동해야 함). 예제에서는 corp.quackynature.com 또는 QNCORP로 식별됩니다. 도메인 컨트롤러가 온프레미스로 배포된 경우 VPC에서 두 환경을 프라이빗 연결(예: VPN)로 연결하는 고가용성 구성으로 보조 도메인 컨트롤러를 배포하여 도메인을 VPC로 확장하는 것이 좋습니다.
둘 이상의 베스천 호스트(원격 데스크톱 EC2 인스턴스) 또는 회사 도메인에 연결하고 구성을 변경할 수 있도록 하는 다른 메커니즘.
도메인 컨트롤러와 도메인 멤버 EC2 인스턴스 간의 인바운드 및 아웃바운드 네트워크 액세스를 제어하는 보안 그룹.
포리스트 신뢰 관계를 설정할 수 있는 도메인 관리자 또는 엔터프라이즈 관리자 그룹의 멤버인 사용자 계정.
AWS Directory Service 리소스 및 Amazon RDS DB 리소스와 해당 환경에 없지만 여기에 언급된 추가 지원 리소스를 생성 및 관리할 수 있는 AWS Identity and Access Management(IAM) 권한.
AWS에서는 IAM을 사용하여 AWS 서비스에 대한 사용자 액세스를 제어합니다. 처음에는 작업을 수행하는 사용자에게 다음 AWS 관리형 정책을 연결하는 것이 좋습니다. 그러나 보다 제한적인 최소 권한을 고려해야 합니다.
- AmazonRDSFullAccess
- AmazonDirectoryServiceFullAccess
- IAMFullAccess
- AmazonEC2FullAccess
- AmazonVPCFullAccess

포리스트 신뢰 관계 설정

이 절차에서는 Microsoft AD 디렉터리, 포리스트 신뢰 및 SQL Server용 RDS 인스턴스를 생성합니다. AWS Management Console, AWS CLI(명령줄 인터페이스), Windows PowerShell용 AWS 도구 또는 AWS SDK를 사용하여 AWS 리소스를 시작하고 관리할 수 있습니다. 다음 예제에서는 Windows PowerShell용 AWS 도구를 사용합니다. 이러한 도구의 설치 및 구성에 대한 자세한 내용은 Windows PowerShell용 AWS 도구 설정을 참조하십시오.

기존 도메인과 동일한 VPC에서 AWS Directory Service를 시작합니다. 기존 도메인 컨트롤러에 연결되어 있고 서로 다른 가용 영역에 있는 서브넷 두 개를 선택합니다. 이 예제의 값을 환경을 대표하는 값으로 바꿉니다.
```
PS C:\> New-DSMicrosoftAD `
-Name "rds.quackynature.com" `
-Description "Domain for RDS for SQL Server" `
-Password "************" `
-ShortName "QNRDS" `
-VpcSettings_SubnetId "subnet-xxxxxxxx", "subnet-yyyyyyyy" `
-VpcSettings_VpcId "vpc-xxxxxxxx"
```
Directory Service 식별자(d-xxxxxxxxxx)가 즉시 제공됩니다. 그러나 리소스를 프로비저닝하는 데 몇 분이 소요될 수 있습니다. 다음 cmdlet을 사용하여 도메인 속성을 검색할 수 있습니다.
```
PS C:\> Get-DSDirectory -DirectoryId “d-xxxxxxxxxx”
```
출력은 다음과 유사합니다.

DnsIpAddrs 값을 기록해 두십시오. 이 값은 도메인 컨트롤러 IP 주소이며 나중에 필요합니다.
두 포리스트 간에 신뢰 관계를 설정하려면 다음 사전 조건을 충족해야 합니다. 신뢰에 대한 AWS Directory Service 설명서의 종합 안내서를 참조하여 이러한 요구 사항을 해결할 수 있습니다.
1. Microsoft AD 디렉터리 서비스에서 인바운드 연결을 수신할 수 있고 회사 도메인 컨트롤러를 사용하여 Active Directory 관련 트래픽에 대한 네트워크 연결을 시작할 수 있는지 확인합니다. AWS Directory Service는 새로 생성된 리소스에 대한 보안 그룹을 자동으로 생성합니다. 회사 도메인 컨트롤러와의 통신을 허용하도록 보안 그룹을 조정해야 합니다.
2. 회사 도메인 컨트롤러에서 새 디렉터리 컨트롤러의 인바운드 연결을 수신할 수 있는지 확인합니다.
3. 회사 도메인에 새 도메인의 DNS 이름에 대한 DNS 조건부 전달자를 생성하고 디렉터리 도메인 컨트롤러의 IP 주소를 제공합니다.
모든 사전 조건이 충족되면 회사 도메인에 인바운드 포리스트 신뢰를 생성할 수 있습니다. 도메인 컨트롤러 인스턴스에 연결하거나 “AD DS 및 AD LDS 도구”와 “DNS 서버 도구” 원격 서버 관리 도구가 설치되어 있는 다른 도메인 조인 컴퓨터에 연결합니다.
1. [Active Directory Domains and Trusts]를 시작합니다.
2. 왼쪽 창의 선택기 트리에서 원하는 도메인의 상황에 맞는 메뉴(마우스 오른쪽 클릭)를 열고 [Properties]를 선택합니다.
3. [Trusts] 탭에서 [New Trust]를 선택합니다.
4. [New Trust Wizard]의 단계에 따라 다음 설정을 선택합니다.
  - 원격(AWS 관리형) 도메인의 [Name](예: rds.quackynature.com)을 제공합니다.
  - [Trust Type] 화면에서 [Forest Trust]를 선택합니다.참고: 이 옵션이 표시되지 않는 경우 네트워크 구성이 도메인 컨트롤러의 상호 연결을 차단하도록 설정되었거나 조건부 전달자가 올바르게 설정되지 않은 것입니다.
  - [Direction of Trust]에서 [One-way: incoming]을 선택합니다.
  - [Sides of Trust]에서 [This domain only]를 선택합니다. 이 마법사에서 한 단계를 수행하여 다른 도메인을 구성할 수는 없습니다.
  - [Trust Password]를 제공합니다. 나중에 관계를 완료할 때 동일한 암호가 필요합니다.
  - [Confirm Incoming Trust]에서 [No, do not confirm the incoming trust]를 선택합니다. 이 마법사에서 한 단계를 수행하여 다른 도메인의 신뢰 파트너를 확인할 수는 없습니다.
이제 새 도메인과 기존 도메인 간의 발신 포리스트 신뢰 관계를 설정할 수 있습니다.
```
PS C:\> New-DSTrust `
-DirectoryId "d-xxxxxxxxxx" `
-ConditionalForwarderIpAddr "10.0.11.10", "10.0.12.10" `
-RemoteDomainName "corp.quackynature.com" `
-TrustDirection "One-Way: Outgoing" `
-TrustPassword "************" `
-TrustType "Forest"
```
앞서 수신 신뢰 파트너를 생성할 때 사용한 동일한 신뢰 암호를 제공합니다. AWS API가 신뢰 식별자 t-xxxxxxxxxx를 반환합니다. 다음 cmdlet을 사용하여 신뢰 상태를 추적할 수 있습니다.
```
PS C:\> Get-DSTrust -DirectoryId "d-xxxxxxxxxx" -TrustId "t-xxxxxxxxxx"
```
출력은 다음과 유사합니다.

TrustState 값을 확인합니다. 이 값은 신뢰 관계 확인 상태를 나타냅니다.

SQL Server용 RDS DB 인스턴스를 프로비저닝하려면 다음 사전 조건을 충족해야 합니다.

아직 없는 경우 서로 다른 가용 영역에 있는 둘 이상의 서브넷에 걸쳐 있는 DB 서브넷 그룹을 생성합니다. 이 그룹은 DB 인스턴스를 배포할 수 있는 서브넷을 지정합니다. 다음 cmdlet을 사용하여 그룹을 생성합니다.
```
PS C:\> New-RDSDBSubnetGroup `
-DBSubnetGroupName "sql-server-subnets" `
-DBSubnetGroupDescription "Subnets for Use with RDS for SQL Server" `
-SubnetId "subnet-xxxxxxxx", "subnet-yyyyyyyy"
```

아직 없는 경우 DB 인스턴스에 대한 액세스를 제어하는 보안 그룹을 생성합니다. 최소한 이 그룹은 포트 1433 또는 알려진 소스의 데이터베이스 트래픽을 수신하도록 선택한 포트에 대한 인바운드 연결을 허용해야 합니다. 다음 예제 스크립트를 사용하여 보안 그룹을 생성합니다.

PS C:\> $groupid = New-EC2SecurityGroup `
-VpcId "vpc-xxxxxxxx" `
-GroupName "sql-server-access" `
-GroupDescription "Access RDS for SQL Server DB instances"
$rule = New-Object Amazon.EC2.Model.IpPermission
$rule.IpProtocol = "tcp"
$rule.FromPort = 1433
$rule.ToPort = 1433
$rule.IpRanges.Add("10.0.0.0/16")
Grant-EC2SecurityGroupIngress -GroupId $groupid -IpPermissions @( $rule )

DB 인스턴스에서 도메인에 조인하는 데 필요한 IAM 역할을 구성합니다. 다음 스크립트는 한 가지 예를 보여 줍니다.

PS C:\> New-IAMRole `
-RoleName "rds-ds-access-role" `
-AssumeRolePolicyDocument @”
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "rds.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
“@
Register-IAMRolePolicy `
-RoleName "rds-ds-access-role" `
-PolicyArn "arn:aws:iam::aws:policy/service-role/AmazonRDSDirectoryServiceAccess"

이제 SQL Server용 RDS 인스턴스를 프로비저닝할 수 있습니다. 다음 예제 스크립트에는 사용 가능한 몇 가지 옵션이 나와 있습니다.

PS C:\> New-RDSDBInstance `
-DBInstanceIdentifier "demo-sqlsrv" `
-DBInstanceClass "db.m4.large" `
-Engine "sqlserver-se" `
-EngineVersion "13.00.2164.0.v1" `
-AllocatedStorage 200 `
-StorageType "gp2" `
-LicenseModel "license-included" `
-MultiAZ 1 `
-AutoMinorVersionUpgrade 1 `
-BackupRetentionPeriod 35 `
-Domain "d-xxxxxxxxxx" `
-DomainIAMRoleName "rds-ds-access-role" `
-DBSubnetGroupName "sql-server-subnets" `
-VpcSecurityGroupId "sg-xxxxxxxx" `
-MasterUsername "demoadmin" `
-MasterUserPassword "************" `
-StorageEncrypted 1

DB 인스턴스가 프로비저닝되면 도메인 사용자에 대한 로그인을 생성할 수 있습니다. 먼저, SQL Server 인증을 사용하여 시작할 때 제공된 마스터 사용자 이름 및 암호로 로그인합니다.

기존 도메인 데이터베이스 관리자 로그인을 사용하여 RDS DB 인스턴스를 관리하려는 경우 다음 예제 T-SQL 스크립트를 사용하여 사용자를 구성할 수 있습니다.

CREATE LOGIN [DOMAIN\DBAdmin] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
EXEC sp_addsrvrolemember 'DOMAIN\DBAdmin', 'processadmin';
EXEC sp_addsrvrolemember 'DOMAIN\DBAdmin', 'setupadmin';   
GO
GRANT ALTER ANY CONNECTION, ALTER ANY LINKED SERVER, ALTER ANY LOGIN, ALTER ANY SERVER ROLE, ALTER SERVER STATE, ALTER TRACE, CONNECT SQL, CREATE ANY DATABASE, VIEW ANY DATABASE, VIEW ANY DEFINITION, VIEW SERVER STATE TO [DOMAIN\DBAdmin] WITH GRANT OPTION;
GO

이제 기존 도메인 자격 증명을 사용하여 사용자의 액세스 권한을 관리할 수 있습니다.

CREATE LOGIN [DOMAIN\Domain Users] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO

SQL Server용 RDS에서 포리스트 신뢰 관계 사용

포리스트 신뢰는 세그먼트형 Active Directory 인프라를 관리하는 데 유용합니다. 이러한 세그먼트를 구현하는 이유는 다양합니다. 예를 들어 특정 수준의 관리 자율화를 달성하려는 경우가 여기에 포함됩니다. 이 아키텍처를 사용할 경우 추가 도메인 및 포리스트를 운영해야 하는 복잡성이 추가되지만 AWS는 이 아키텍처를 통해 기존 도메인에 적용된 정책과의 충돌 없이 고객의 RDS DB 인스턴스를 일관적으로 운영할 수 있습니다.

보안 측면에서 이 아키텍처는 이미 회사 도메인에 대해 준수해야 하는 보안 필수 요소 및 요구 사항을 보강하는 효과가 있습니다. 고객은 관리형 도메인에도 동일한 관행을 적용할 수 있습니다. 기존 도메인에 위치한 악의적인 사용자가 관리형 도메인의 공유 리소스와 기존 도메인의 리소스에 액세스할 가능성이 있지만,

신뢰 관계 자체로 SQL Server용 RDS DB 인스턴스에 저장된 데이터에 액세스하기에는 충분하지 않습니다. SQL Server용 RDS는 관리형 서비스이기 때문에 SQL Server 서비스 자체에 대해 인증된 연결로만 액세스가 제한되며 데스크톱 또는 파일 시스템에는 액세스할 수 없습니다. 서비스에 연결하는 합법적인 사용자는 해당하는 로그인이 SQL Server에 개별적으로 또는 그룹의 일부로 구성되어 있어야 합니다.

요약하면, 포리스트 신뢰 관계는 Amazon RDS를 사용하여 배포된 SQL Server 인스턴스로 기존 Windows 인증 기능을 확장하는 데 효과적인 메커니즘입니다.

이 글은 AWS Database Blog의 Integrate Amazon RDS for SQL Server DB Instances with an Existing Active Directory Domain의 한국어 번역으로 정도현 AWS 테크니컬 트레이너가 감수하였습니다.

Amazon Web Services 한국 블로그

Amazon RDS for SQL Server DB 인스턴스를 기존 Active Directory 도메인에 통합하기

주요 링크 모음

팔로우하기