DMS를 넘어: SQL Server 로그인 및 사용자를 Cloud SQL로 마이그레이션 가속화

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

이제 데이터베이스 현대화 여정을 위한 계획을 모두 마치셨습니다. Google Cloud의 Database Migration Service(DMS)를 설정하고, 복제를 구성하여, 온프레미스 또는 클라우드 시스템의 애플리케이션 데이터베이스를 완전 관리형 SQL Server용 Cloud SQL 인스턴스에 성공적으로 동기화했습니다.

복제가 완료되어 데이터가 최신 상태로 업데이트되었으며 컷오버할 준비가 되었습니다. 하지만 애플리케이션이 새로 마이그레이션된 데이터베이스에 연결을 시도하면 다음과 같은 메시지가 표시되면서 문제가 발생합니다.

Msg 18456, Level 14, State 1, Line 1: Login failed for user 'app_user.

원인은 간단합니다. SQL Server 로그인이 데이터베이스와 함께 마이그레이션되지 않았기 때문입니다. 이 게시물에서는 이러한 격차가 존재하는 이유, 이 격차가 실제로 조직의 보안 상황을 보호하는 이유, 오랜 시간 검증된 표준 SQL Server 도구를 사용하여 격차를 얼마나 쉽게 해소할 수 있는지 살펴보겠습니다. 

DMS가 로그인을 마이그레이션하지 않는 이유: 보안 및 규정 준수

Database Migration Service(DMS)는 데이터베이스 수준 스키마와 트랜잭션 데이터를 복제하는 데 매우 효율적입니다. 그러나 시스템 master 데이터베이스나 서버 로그인, 권한과 같은 인스턴스 수준 객체는 의도적으로 마이그레이션하지 않습니다.

자칫 기능이 누락된 것처럼 보일 수 있지만, 사실 이는 세 가지 핵심 요소를 바탕으로 설계된 의도적인 디자인 옵션입니다.

1. 보안 격리 및 권한 경계: 원본 환경과 대상 Cloud SQL 환경은 서로 다른 보안 패러다임에서 작동합니다. 마스터 시스템 데이터베이스를 직접 복제하면 승인되지 않은 권한 에스컬레이션이 발생할 수 있습니다. 예를 들어 sysadmin 권한이 있는 온프레미스 로그인은 완전 관리형 Google Cloud 데이터베이스에 대한 무제한 sysadmin 액세스 권한을 가져서는 안 됩니다. 클라우드 제공업체가 물리적 백업, 패치, 보안을 관리하는 경우 올바른 운영을 보장하기 위해 기본 운영체제에 대한 액세스를 제한해야 합니다.

2. 규정 준수 및 감사 거버넌스: 명시적인 관리자 감독 없이 암호화된 비밀번호 해시와 서버 수준의 보안용 사용자 인증 정보를 자동으로 마이그레이션하면 PCI-DSS나 SOC 2와 같은 기업 규정 준수 프레임워크를 위반하는 경우가 많습니다. 보안 객체 마이그레이션을 관리자가 직접 수행하는 의도적인 단계로 유지함으로써 조직은 승인된 ID만 클라우드 시작 영역에 프로비저닝되도록 보장할 수 있습니다.

3. ID 현대화의 필요성: 클라우드 마이그레이션은 오래된 사용자 인증 정보를 업데이트하고 불필요한 계정을 정리할 수 있는 더할 나위 없이 좋은 기회입니다. 온프레미스 인스턴스에는 더 이상 사용되지 않는 legacy SQL 로그인이 포함되어 있는 경우가 많습니다. 이를 클라우드 관리형 서비스에 무작정 복제하는 것은 보안상 위험합니다. 또한 Cloud SQL로의 이전은 legacy SQL 인증에서 고객 관리형 Active Directory(CMAD)와 같은 최신 클라우드 네이티브 ID 솔루션으로 전환하는 촉매제 역할을 하는 경우가 많습니다.

로그인과 사용자의 차이 이해: SID 연결

로그인을 성공적으로 마이그레이션하기 위해 SQL Server가 보안을 관리하는 방법을 간단히 살펴보겠습니다. SQL Server는 ID를 두 개의 개별 계층으로 분리합니다.

• 로그인(서버 수준): master 데이터베이스에 저장됩니다. 로그인은 SQL Server 인스턴스에 대한 클라이언트 연결을 인증합니다.

• 사용자(데이터베이스 수준): 개별 사용자 데이터베이스 내에 저장됩니다. 사용자는 해당 특정 데이터베이스 내에서 연결을 통해 수행할 수 있는 작업을 승인합니다.

서버 로그인과 데이터베이스 사용자를 연결하는 것은 고유한 보안 식별자(SID)입니다.

데이터베이스를 백업하고 복원하거나 DMS를 사용하여 복제하면 데이터베이스 수준의 사용자(및 해당 SID)가 데이터베이스 파일 내에서 마이그레이션됩니다. 그러나 해당 서버 수준의 로그인이 대상 마스터 데이터베이스에 없거나, 존재하더라도 SID가 다른 경우 매핑이 중단됩니다. 이로 인해 데이터베이스 액세스 권한은 있지만 서버 수준에서 인증할 방법이 없는 '분리된 사용자'가 발생합니다.

권장 솔루션: sp_help_revlogin을 사용하여 로그인 복제

모든 로그인을 수동으로 다시 만들고 비밀번호 해시를 추측하는 대신 Microsoft에서 제공하는 기존 스크립트인 sp_help_revlogin을 사용할 수 있습니다.

이 스크립트는 소스 인스턴스의 모든 SQL Server 인증 로그인에 대한 CREATE LOGIN 문이 포함된 T-SQL 쿼리를 생성하며, 원래의 암호화된 비밀번호 해시와 정확한 보안 식별자(SID)를 포함합니다.

1단계: 소스 인스턴스에 도우미 프로시저 만들기

SQL Server Management Studio(SSMS)를 사용하여 소스 SQL Server 인스턴스에 연결합니다. 공식 Microsoft 스크립트를 복사하고 실행하여 소스 master 데이터베이스에 필요한 두 가지 저장 프러시저인 sp_hexadecimal 및 sp_help_revlogin을 만듭니다.

2단계: 마이그레이션 스크립트 생성하기

프로시저가 생성되면 SSMS 쿼리 창에서 다음 문을 실행합니다. 출력을 깔끔하게 복사할 수 있도록 출력 설정을 Results to Text(Ctrl + T)로 전환했는지 확인합니다.

출력에는 다음과 유사한 자동 생성된 T-SQL 문이 포함됩니다.

HASHED 비밀번호 옵션과 원래 SID를 사용하여 로그인을 스크립팅하면 SQL Server에서 원래 비밀번호와 보안 링크를 그대로 유지하면서 로그인을 안전하게 다시 만들 수 있습니다.

3단계: Cloud SQL에 스크립트 적용하기

생성된 스크립트를 복사하고 대상 SQL Server용 Cloud SQL 인스턴스에 연결한 후 쿼리를 실행합니다. 클라우드에 올바른 비밀번호로 로그인이 즉시 생성됩니다.

sp_help_revlogin을 통해 생성된 스크립트를 실행하면, 정확한 보안 식별자(SID)와 비밀번호 해시를 그대로 유지한 상태로 대상 Cloud SQL 인스턴스에 로그인을 복제할 수 있습니다. 아래와 같이 이 방법을 사용하면, 데이터베이스 마이그레이션 시 데이터베이스 수준 사용자가 서버 수준 로그인에 자동으로 매핑되므 '분리된 사용자' 문제를 완전히 방지할 수 있습니다.

참고: sp_help_revlogin은 Microsoft에서 만들고 유지관리하는 저장 프러시저입니다. 최신 버전을 다운로드하고 문서를 읽어보세요. 

분리된 사용자 문제 해결

sp_help_revlogin을 실행하기 전에 대상 Cloud SQL 인스턴스에 수동으로 로그인을 만든 경우 SID가 일치하지 않아 사용자가 '분리'될 수 있습니다.

만약 분리된 사용자(예: app_user)가 발견되더라도, 단 한 줄의 명령어로 새로 생성된 서버 로그인에 간편하게 다시 매핑할 수 있습니다.

이 명령어를 실행하면 데이터베이스 사용자와 서버 로그인이 SID를 통해 즉시 다시 연결되며, 애플리케이션 연결이 완벽하게 복원됩니다.

보안을 한층 더 강화

sp_help_revlogin을 사용하여 SQL 로그인을 마이그레이션하는 것이 리프트 앤 시프트 마이그레이션의 가장 쉬운 방법이지만, 클라우드 마이그레이션을 활용하여 인증을 현대화하는 것을 고려해 보세요. SQL Server용 Cloud SQL은 고객 관리형 Active Directory(CMAD)와의 강력한 통합을 지원합니다. 대상 인스턴스를 Active Directory와 통합하면 legacy SQL 로그인을 지원 중단하고 중앙 집중식 엔터프라이즈급 Kerberos 인증을 사용할 수 있습니다.

마무리

데이터베이스 마이그레이션은 단순히 데이터 행을 옮기는 것이 아닙니다. 애플리케이션이 첫날부터 안전하고 규정을 준수하며 운영 가능한 상태를 유지하도록 보장하는 작업입니다. Google Cloud의 DMS가 데이터 복제라는 까다로운 작업을 대신 처리해 주지만, 로그인 마이그레이션 또한 단 3단계의 간단한 과정만으로 원활한 컷오버를 확실히 보장할 수 있습니다.

마이그레이션 전략을 최적화하는 방법에 대해 더 자세히 알아보려면  SQL Server용 Cloud SQL 마이그레이션 가이드를 확인해 보세요. 또한  Database Migration Service를 활용해 Google Cloud로의 이전 과정을 얼마나 간소화할 수 있는지 직접 살펴보시기 바랍니다.