Linux에서 SQL Server 및 컨테이너에 대한 Active Directory 인증 이해
적용 대상: 
SQL Server - Linux
이 문서에서는 SQL Server에서 Linux 또는 컨테이너에 배포한 Active Directory 인증이 작동하는 방식에 대해 자세히 설명합니다.
개념
LDAP(Lightweight Directory Access Protocol)
LDAP는 Active Directory를 비롯한 다양한 디렉터리 서비스를 사용하기 위한 애플리케이션 프로토콜입니다. 디렉터리 서비스는 사용자 및 계정 정보를 저장하고 암호 등의 보안 정보를 저장합니다. 해당 정보는 암호화된 다음 네트워크의 다른 디바이스와 공유됩니다.
LDAP 보안에 대한 자세한 내용은 Windows Server에서 LDAP 서명을 사용하도록 설정하는 방법을 참조하세요.
Kerberos
Kerberos는 사용자 또는 호스트 컴퓨터의 ID를 확인하는 데 사용되는 인증 프로토콜입니다. 클라이언트와 서버를 확인하는 방법으로 생각할 수 있습니다.
Windows 서버와 비 Windows 서버 및 클라이언트가 있는 다른 유형(혼합)의 환경에서 작업하는 경우 Active Directory 기반 디렉터리 서비스에서 작업해야 하는 두 가지 종류의 파일이 있습니다.
- Keytab 파일(“키 테이블”의 약어)
- Kerberos 구성(
krb5.conf또는krb5.ini)
keytab 파일이란?
Linux 또는 Unix 시스템의 서버 프로세스는 Windows 서비스 계정으로 프로세스를 실행하도록 구성할 수 없습니다. Linux 또는 Unix 시스템이 시작할 때 Active Directory에 자동으로 로그인하도록 하려면 keytab 파일을 사용해야 합니다.
keytab은 KDC(키 배포 센터)에서 Kerberos로 보호된 서비스의 표현과 연결된 서비스 사용자 이름의 장기 키를 포함하는 암호화 파일입니다. 키는 암호 자체가 아닙니다.
keytab은 다음 중 하나에 사용됩니다.
- 네트워크의 다른 서비스에 서비스 자체 인증
- 서비스 인바운드 디렉터리 사용자의 Kerberos 서비스 티켓 암호 해독
krb5.conf 파일이란?
/etc/krb5.conf 파일(또는 krb5.ini)은 Kerberos v5(KRB5) 및 GNU GSSAPI(단순 인증 및 보안 계층 API) 라이브러리에 대한 구성 입력을 제공합니다.
이 정보에는 기본 도메인, 각 도메인의 속성(예: 키 배포 센터) 및 기본 Kerberos 티켓 수명이 포함됩니다.
이 파일은 Active Directory 인증이 작동하는 데 필요합니다. krb5.conf는 INI 파일이지만 키-값 쌍의 각 값은 { 및 }로 묶인 하위 그룹이 될 수 있습니다.
krb5.conf 파일에 대한 자세한 내용은 MIT Kerberos 컨소시엄 설명서를 참조하세요.
SQL Server on Linux용 Kerberos 구성
SQL Server on Linux를 실행하는 호스트 서버에서 필요한 값입니다. 동일한 호스트에서 실행되는 다른(비 SQL Server) 서비스가 있는 경우 krb5.conf 파일에 몇 가지 항목이 더 필요할 수 있습니다.
다음은 새로 고침에 대한 샘플 krb5.conf 파일입니다.
[libdefaults]
default_realm = CONTOSO.COM
[realms]
CONTOSO.COM = {
kdc = adVM.contoso.com
admin_server = adVM.contoso.com
default_domain = contoso.com
}
[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM
libdefaults-default_realm값이 있어야 합니다. 이 값은 호스트 머신이 속한 도메인을 지정합니다.realms(선택 사항) - 각 보안영역에 대해 Active Directory 계정을 조회할 때 머신에서 연결해야 하는 키 배포 센터를 지정하도록kdc값을 설정할 수 있습니다. 둘 이상의 KDC를 설정한 경우 각 연결에 대한 KDC가 라운드 로빈 방식으로 선택됩니다.domain_realm(선택 사항) - 각 보안영역에 대한 매핑을 제공할 수 있습니다. 그렇지 않은 경우 SQL Server on Linux에서는contoso.com도메인이CONTOSO.COM보안영역에 매핑된다고 가정합니다.
Kerberos 인증 프로세스
Windows Kerberos 인증과 마찬가지로 TGT(티켓 부여 티켓)를 가져오는 처음 두 단계는 동일합니다.
클라이언트는 DC(도메인 컨트롤러)에 사용자 이름 및 암호(암호화됨)를 전송하여 로그인 프로세스를 시작합니다.
내부 스토리지에 대한 사용자 이름 및 암호를 확인한 후 DC는 사용자에 대한 TGT를 클라이언트에 반환합니다.
SQL Server on Linux에서는 keytab 파일을 사용하여 SPN(서비스 사용자 이름)의 암호를 읽은 다음, 연결 권한을 부여하는 데 사용하는 암호화된 Blob의 암호를 해독합니다. 다음 단계에서는 이 프로세스를 간략하게 설명합니다.
사용자에게 TGT가 있으면 클라이언트는 SQL Server 인스턴스의 호스트 이름 및 포트를 지정하여 SQL Server에 연결하기 시작합니다.
SQL 클라이언트는 내부적으로 서비스 주체 이름을
MSSQLSvc/<host>:<port>형식으로 만듭니다. 대부분의 SQL Server 클라이언트에서 하드 코딩된 형식입니다.클라이언트는 해당 SPN의 DC에서 세션 키를 요청하여 Kerberos 핸드셰이크를 시작합니다. TGT와 SPN은 모두 DC로 전송됩니다.
- DC는 TGT 및 SPN의 유효성을 검사한 후 SQL Server SPN에 연결하기 위해 세션 키를 클라이언트로 보냅니다.
- 세션 키에서 암호화된 Blob이 서버로 전송됩니다.
SQL Server는 암호화된(SPN, 암호) 튜플을 포함하는 디스크의 파일인 keytab(
mssql.keytab)에서 SPN의 암호를 읽습니다.SQL Server는 클라이언트의 사용자 이름을 가져오기 위해 방금 조회한 암호로 클라이언트에서 암호화된 Blob의 암호를 해독합니다.
SQL Server는
sys.syslogins테이블의 클라이언트를 조회하여 클라이언트에 연결할 권한이 있는지 확인합니다.연결이 수락되거나 거부되었습니다.
SQL Server 컨테이너용 Kerberos 구성
컨테이너의 SQL Server에 대한 Active Directory 인증은 기본적으로 SQL Server on Linux와 동일합니다. 유일한 차이점은 SQL Server 호스트 SPN입니다. 이전 시나리오에서 SPN은 SQL Server 호스트의 이름을 통해 연결되었기 때문에 MSSQLSvc/<host>:<port>였습니다. 그러나 이제 컨테이너에 연결해야 합니다.
SQL Server 컨테이너의 경우 컨테이너 내에 krb5.conf 파일을 만들 수 있습니다. 컨테이너를 실행하는 호스트 노드는 도메인의 일부가 될 필요는 없지만 컨테이너가 연결을 시도할 도메인 컨트롤러에 연결할 수 있어야 합니다.
컨테이너에 연결하기 때문에 클라이언트 연결의 서버 이름은 호스트 이름과 다를 수 있습니다. 호스트 이름, 컨테이너 이름 또는 다른 별칭일 수 있습니다. 또한 SQL Server에 노출된 포트가 기본값인 1433이 아닐 가능성이 있습니다.
SQL Server 컨테이너에 연결하려면 반드시 mssql.keytab에 저장된 SPN을 사용해야 합니다. 예를 들어 mssql.keytab에 있는 SPN이 MSSQLSvc/sqlcontainer.domain.com:8000인 경우 sqlcontainer.domain.com,8000을(를) 클라이언트의 연결 문자열(sqlcmd, SQL Server Management Studio 및 Azure Data Studio 포함)로 사용합니다.
SQL Server 그룹 새로 고침
인증하기 위해 서비스 사용자 이름만 필요한 경우 keytab에 사용자 계정이 있는 이유가 궁금할 수 있습니다.
adGroup그룹의 구성원인 adUser라는 사용자가 있다고 가정해 보겠습니다. adGroup이 SQL Server에 로그인으로 추가되면 adUser도 SQL Server 인스턴스에 로그인할 수 있는 권한이 있음을 의미합니다. adUser가 여전히 SQL Server에 연결되어 있는 동안 도메인 관리자는 adGroup에서 adUser를 제거할 수 있습니다. 이제 adUser는 더 이상 SQL Server에 로그인할 수 있는 권한이 없어야 하지만 Kerberos 인증 프로세스를 이미 통과하여 연결되어 있습니다.
연결된 사용자가 더 이상 권한 있는 작업(예: 로그인 만들기 또는 데이터베이스 변경)을 수행할 수 없는 상황을 방지하기 위해 그룹 새로 고침이라는 프로세스를 주기적으로 실행합니다.
SQL Server에는 그룹 새로 고침에 사용하는 권한 있는 Active Directory 계정이 있습니다. 이 계정은 network.privilegedadaccount 설정과 함께 mssql-conf를 사용하여 구성되거나 호스트 머신(<hostname>$)의 머신 계정으로 기본 설정됩니다.
mssql.keytab에 있는 권한 있는 계정의 자격 증명은 클라이언트를 가장하는 데 사용됩니다(이 예제에서는 adUser). SQL Server는 Kerberos 핸드셰이크를 자체적으로 수행하여 그룹 멤버 자격 정보를 식별하고 이를 sys.syslogins와 비교하여 adUser에 요청된 Transact-SQL 명령을 연결하고 실행하는 데 필요한 권한이 여전히 있는지 확인합니다. adUser가 adGroup에서 제거된 경우 SQL Server에 의해 연결이 종료됩니다.
그룹 새로 고침에는 다음 두 가지 조건이 필요합니다.
- SQL Server 인스턴스와 온-프레미스 Active Directory 도메인 간의 네트워크 연결.
- SQL Server가 연결된 도메인과 온-프레미스 Active Directory 도메인 간의 양방향 트러스트입니다. 자세한 내용은 Active Directory 이해를 참조하세요.