데이터베이스 수준에서 고객 관리형 키를 사용하는 TDE(투명한 데이터 암호화)

적용 대상: Azure SQL Database

이 문서에서는 Azure SQL Database의 데이터베이스 수준에서 고객 관리형 키를 사용하는 TDE(투명한 데이터 암호화)에 대해 설명합니다.

참고 항목

데이터베이스 수준 TDE CMK는 Azure SQL Database(모든 SQL Database 버전)에서 사용할 수 있습니다. Azure SQL Managed Instance, SQL Server 온-프레미스, Azure VM 및 Azure Synapse Analytics(전용 SQL 풀(이전의 SQL DW))에서는 사용할 수 없습니다.

참고 항목

Microsoft Entra ID는 이전의 Azure AD(Azure Active Directory)입니다.

개요

Azure SQL에서는 TDE(투명한 데이터 암호화)를 통해 고객에게 미사용 데이터 암호화 기능을 제공합니다. CMK(고객 관리형 키) 기반 TDE를 확장하면 데이터베이스 암호화 키를 암호화하는 Azure Key Vault에 TDE 보호기(암호화 키)를 저정하여 미사용 데이터 보호를 사용할 수 있습니다. 현재 CMK 기반 TDE 보호기는 서버 수준에서 설정되며 해당 서버와 연결된 모든 암호화된 데이터베이스에서 상속됩니다. 이 새로운 기능을 사용하면 TDE 보호기를 서버 내 각 데이터베이스에서 개별적으로 고객 관리형 키로 설정할 수 있습니다. 비어 있지 않은 유효한 encryptionProtector 속성이 있는 모든 Microsoft.Sql/servers/databases 리소스는 데이터베이스 수준 고객 관리형 키로 구성됩니다.

이 시나리오에서 TDE 보호기라고 하는 데이터베이스 암호화 키(DEK)를 암호화하기 위해 서버 내 각 데이터베이스에서 고객 소유 및 고객 관리형 Azure Key Vault(AKV)에 저장된 비대칭 키를 개별적으로 사용할 수 있습니다. 각 데이터베이스에 대해 키를 추가하고, 키를 제거하며, 사용자가 할당한 관리 ID(UMI)를 변경하는 옵션이 있습니다. ID에 대한 자세한 내용은 Azure의 관리 ID 유형을 참조하세요.

다음 기능을 사용할 수 있습니다.

• 사용자가 할당한 관리 ID: 단일 사용자가 할당한 관리 ID를 데이터베이스에 할당할 수 있습니다. 이 ID를 사용하여 Azure Key Vault에 액세스하고 암호화 키를 관리할 수 있습니다.
• 암호화 키 관리: 데이터베이스 수준에서 하나 이상의 암호화 키를 추가하고 추가된 키 중 하나를 TDE 보호기로 설정할 수 있습니다. 추가할 암호화 키는 데이터베이스에 이미 할당된 사용자가 할당한 관리 ID를 사용하여 Azure Key Vault에 액세스합니다.
• 페더레이션된 클라이언트 ID: Azure SQL Database에서 설정된 페더레이션된 클라이언트 ID를 활용하여 다른 Microsoft Entra 테넌트의 Azure Key Vault에 있는 CMK(고객 관리형 키)를 데이터베이스 수준에서 TDE 보호기로 설정할 수도 있습니다. 그러면 다른 테넌트의 Azure Key Vault에 저장된 키를 사용하여 TDE를 관리할 수 있습니다.

참고 항목

시스템이 할당한 관리 ID는 데이터베이스 수준에서 지원되지 않습니다.

데이터베이스 수준에서 고객 관리형 TDE의 혜택

ISV(독립 소프트웨어 공급업체)라고도 하는 더 많은 서비스 제공자가 Azure SQL Database를 사용하여 서비스를 빌드함에 따라 많은 사람들이 여러 데이터베이스에서 컴퓨팅 리소스를 효율적으로 분산하는 방법으로 탄력적 풀에 의존하고 있습니다. 각 고객의 데이터베이스를 공유 탄력적 풀에 두면 ISV는 각 데이터베이스가 적절한 리소스를 보유하도록 계속 보장하는 동시에 리소스 사용률을 최적화하는 풀의 기능을 활용할 수 있습니다.

그러나 이 접근 방식에는 한 가지 중요한 제한 사항이 있습니다. 여러 데이터베이스가 동일한 Azure SQL 논리 서버에 호스트되는 경우 서버 수준 TDE 보호기를 공유합니다. ISV는 고객에게 진정한 CMK(고객 관리형 키) 기능을 제공할 수 없습니다. 자체 암호화 키를 관리할 수 없는 고객은 특히 규정 준수 규정에서 암호화 키를 기본 완전히 제어해야 하는 경우 중요한 데이터를 ISV의 서비스에 맡기는 것을 주저할 수 있습니다.

데이터베이스 수준 TDE CMK를 사용하면 해당 ISV 고객이 자체에서 소유하고 있는 소유한 키 자격 증명 모음에 각 데이터베이스의 TDE 보호기를 소유할 수 있으므로 ISV는 고객에게 CMK 기능을 제공하고 보안 격리를 달성할 수 있습니다. ISV 고객을 위한 보안 격리는 키 및 키에 액세스하는 데 사용되는 ID의 측면에서 모두 수행됩니다.

아래 다이어그램에서는 위에 표시된 새로운 기능을 요약하여 보여줍니다. 두 개의 개별 Microsoft Entra 테넌트가 표시됩니다. 두 개의 데이터베이스(DB 1 및 DB 2)가 있는 Azure SQL 논리 서버와 UMI 1을 사용하여 DB 1 데이터베이스에 액세스할 때 Key 1을 사용하는 Azure Key Vault 1을 포함하는 Best Services 테넌트입니다. UMI 1 및 Key 1 모두 서버 수준 설정을 나타냅니다. 기본값으로 이 서버에서 처음에 생성한 모든 데이터베이스는 CMK 기반 TDE에서 이 설정을 상속합니다. Contoso 테넌트는 이 데이터베이스에서 Key 2 및 UMI 2를 사용하여 데이터베이스 수준 CMK 교차 테넌트 지원의 일부로 테넌트에서 DB 2 데이터베이스에 액세스할 때 Key 2를 사용하는 Azure Key Vault 2를 포함하는 클라이언트 테넌트를 나타냅니다.

교차 테넌트 ID 구성에 대한 자세한 내용은 투명한 데이터 암호화에서 교차 테넌트 고객 관리형 키를 참조하세요.

지원되는 키 관리 시나리오

다음 섹션에서는 세 개의 데이터베이스(예: Database1, Database2, Database3)로 구성된 서버가 있다고 가정합니다.

기존 시나리오

Key1은 논리 서버 수준에서 고객 관리형 키로 구성됩니다. 이 서버의 모든 데이터베이스는 동일한 키를 상속합니다.

• 서버 – Key1을 CMK로 설정
• Database1 – Key1을 CMK로 사용함
• Database2 – Key1을 CMK로 사용함
• Database3 – Key1을 CMK로 사용함

지원되는 새로운 시나리오: 고객 관리형 키로 구성된 논리 서버

Key1은 논리 서버 수준에서 고객 관리형 키로 구성됩니다. 다른 고객 관리형 키(Key2)를 데이터베이스 수준에서 구성할 수 있습니다.

• 서버 – Key1을 CMK로 설정
• Database1 – Key2을 CMK로 사용함
• Database2 – Key1을 CMK로 사용함
• Database3 – Key1을 CMK로 사용함

참고 항목

논리 서버가 TDE용 고객 관리형 키로 구성된 경우 이 논리 서버의 개별 데이터베이스는 투명한 데이터 암호화에 대해 서비스 관리형 키를 사용하도록 옵트인할 수 없습니다.

지원되는 새 시나리오: 서비스 관리형 키로 구성된 논리 서버

논리 서버는 TDE용 SMK(서비스 관리형 키)로 구성됩니다. 다른 고객 관리형 키(Key2)를 데이터베이스 수준에서 구성할 수 있습니다.

• 서버 - TDE 보호기로 설정된 서비스 관리형 키
• Database1 – Key2를 CMK로 설정함
• Database2 – TDE 보호기로 설정된 서비스 관리형 키
• Database3 – TDE 보호기로 설정된 서비스 관리형 키

서버 수준 암호화로 되돌리기

Database1은 논리 서버가 서비스 관리형 키로 구성된 동안 TDE에 대한 데이터베이스 수준 고객 관리형 키로 구성됩니다. Database1은 논리 서버 수준 서비스 관리형 키를 사용하도록 되돌릴 수 있습니다.

참고 항목

논리 서버가 TDE용 CMK로 구성된 경우 데이터베이스 수준 CMK로 구성된 데이터베이스를 서버 수준 암호화로 다시 되돌릴 수 없습니다.

그러나 TDE를 사용할 때 되돌리기 작업은 논리 서버가 서버 관리형 키로 구성된 경우에만 지원되지만 서버가 유효한 ID로 원본 데이터베이스가 사용하는 모든 키에 액세스할 수 있는 경우 데이터베이스 수준 CMK로 구성된 데이터베이스를 CMK로 구성된 서버로 복원할 수 있습니다.

Key Vault 및 관리형 요구 사항

서버 수준 CMK(고객 관리형 키) 기능에 적용되는 ID에 부여된 키 설정 및 권한을 포함하여 Azure Key Vault(AKV) 키 및 관리 ID를 구성하기 위한 동일한 요구 사항이 데이터베이스 수준 CMK에도 적용됩니다. 자세한 내용은 CMK 기반 TDE(투명한 데이터 암호화) 및 CMK 기반 관리 ID를 참조하세요.

키 관리

데이터베이스의 TDE 보호기 순환은 데이터베이스를 보호하는 새로운 비대칭 키로 전환한다는 의미입니다. 키 회전은 온라인 작업으로 완료하는 데 몇 초면 됩니다. 이 작업은 전체 데이터베이스가 아닌 데이터베이스 암호화 키의 암호를 해독하고 다시 암호화합니다. 유효한 사용자가 할당한 관리 ID가 데이터베이스에 할당되면 데이터베이스 수준에서 키 순환은 데이터베이스의 암호화 보호기 속성 업데이트를 포함하는 데이터베이스 CRUD 작업입니다. Set-AzSqlDatabase 및 -EncryptionProtector 속성을 사용하여 키를 순환할 수 있습니다. 데이터베이스 수준 CMK로 구성된 새 데이터베이스를 생성하기 위해 New-AzSqlDatabase를 -EncryptionProtector, -AssignIdentity, -UserAssignedIdentityId 매개 변수와 함께 사용할 수 있습니다.

새 키를 추가할 수 있으며, 유사한 요청을 사용하여 데이터베이스에서 기존 키를 제거하고, 데이터베이스 리소스에 대한 키 속성을 수정할 수 있습니다. -KeyList 및 -KeysToRemove 매개 변수가 있는 Set-AzSqlDatabase를 이러한 작업에 사용할 수 있습니다. 암호화 보호기, ID 및 키 설정을 검색하기 위해 Get-AzSqlDatabase를 사용할 수 있습니다. Azure Resource Manager 리소스 Microsoft.Sql/servers/databases는 기본값으로 데이터베이스에 구성된 TDE 보호기 및 관리 ID만 표시합니다. 키의 전체 목록을 확장하려면 -ExpandKeyList 같은 다른 매개 변수가 필요합니다. 또한 -KeysFilter "current" 및 특정 시점 값(예: 2023-01-01)을 사용하여 사용된 현재 키와 과거 특정 시점에 사용된 키를 검색할 수 있습니다.

자동 키 회전

자동 키 순환은 데이터베이스 수준에서 사용할 수 있으며 Azure Key Vault 키와 함께 사용할 수 있습니다. 키의 새 버전이 감지되면 순환이 트리거되고 24시간 이내에 자동으로 순환됩니다. Azure Portal, PowerShell 또는 Azure CLI를 사용하여 자동 키 순환을 구성하는 방법에 대한 자세한 내용은 데이터베이스 수준에서 자동 키 순환을 참조하세요.

키 관리에 대한 권한

키 자격 증명 모음의 권한 모델(액세스 정책 또는 Azure RBAC)에 따라 다르지만, 키 자격 증명 모음에 대한 액세스 정책을 생성하거나 새 Azure RBAC 역할 할당을 생성하여 키 자격 증명 모음 액세스 권한을 부여할 수 있습니다.

액세스 정책 권한 모델

데이터베이스에서 AKV에 저장된 TDE 보호기를 DEK 암호화에 사용하려면 키 자격 증명 모음 관리자가 고유한 Microsoft Entra ID를 사용하여 데이터베이스 사용자가 할당한 관리 ID에 다음 액세스 권한을 부여해야 합니다.

• get - Azure Key Vault에서 키의 퍼블릭 파트 및 속성을 검색합니다.
• wrapKey - DEK를 보호(암호화)할 수 있습니다.
• unwrapKey - DEK를 보호 해제(암호 해독)할 수 있습니다.

Azure RBAC 권한 모델

데이터베이스에서 AKV에 저장된 TDE 보호기를 DEK 암호화에 사용하려면 고유한 Microsoft Entra ID를 사용하여 데이터베이스 사용자가 할당한 관리 ID에 대해 Key Vault Crypto Service 암호화 사용자 역할로 새로운 Azure RBAC 역할 할당을 추가해야 합니다.

교차 테넌트 고객 관리형 키

투명한 데이터 암호화에서 교차 테넌트 고객 관리형 키에서는 서버 수준 CMK에 대해 페더레이션된 클라이언트 ID를 설정하는 방법을 설명합니다. 데이터베이스 수준 CMK에 대해 유사한 설정을 수행해야 하며, 페더레이션된 클라이언트 ID는 Set-AzSqlDatabase 또는 New-AzSqlDatabase API 요청의 일부로 추가되어야 합니다.

참고 항목

필수 권한(키 가져오기, 키 래핑, 키 래핑 해제)을 사용하여 키 자격 증명 모음 액세스 정책에 다중 테넌트 애플리케이션을 추가하지 않은 경우 Azure Portal에서 ID 페더레이션에 애플리케이션을 사용하면 오류가 표시됩니다. 페더레이션된 클라이언트 ID를 구성하기 전에 권한이 올바르게 구성되었는지 확인합니다.

데이터베이스 수준 CMK로 구성된 데이터베이스는 Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert를 사용하여 서비스 관리형 키로 논리 서버가 구성된 경우 서버 수준 암호화로 되돌릴 수 있습니다.

CMK 기반 TDE(투명한 데이터 암호화)에 설명된 대로 액세스할 수 없는 TDE 보호기의 경우 키 액세스가 수정되면 Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation을 사용하여 데이터베이스에 액세스하도록 할 수 있습니다.

참고 항목

데이터베이스 수준 고객 관리 키 기반 TDE용 ID 및 키 관리에서는 Powershell, Azure CLI 및 REST API 예제와 함께 데이터베이스 수준 CMK에 대한 ID 및 키 관리 작업을 자세히 설명합니다.

추가 고려 사항

• CMK 기반 TDE가 이미 서버 수준에서 사용하도록 설정된 경우 특정 데이터베이스에 대한 CMK를 설정하면 서버 수준 CMK 설정이 재정의됩니다(데이터베이스의 DEK는 데이터베이스 수준 TDE 보호기로 다시 암호화됨).
• 논리 서버 수준 키 변경 또는 순환은 데이터베이스 수준 CMK 설정에 영향을 주지 않으며 데이터베이스는 자체 CMK 설정을 계속 사용합니다.
• 데이터베이스 수준 CMK는 T-SQL(Transact-SQL)을 통해 지원되지 않습니다.
• 논리 서버 UMI(사용자가 할당한 관리 ID)는 데이터베이스 수준에서 사용할 수 있습니다. 그러나 데이터베이스 수준 CMK에 지정된 UMI를 사용하는 것이 좋습니다.
• 서버 수준 교차 테넌트 CMK 설정은 데이터베이스 수준 CMK로 구성된 개별 데이터베이스에 영향을 주지 않으며 자체 단일 테넌트 또는 교차 테넌트 구성을 계속 사용합니다.
• 데이터베이스 수준에서는 단일 사용자가 할당한 관리 ID만 설정할 수 있습니다.

참고 항목

데이터베이스 이름이 바뀐 경우 데이터베이스의 관리 ID를 다시 할당해야 합니다.

기존 데이터베이스를 데이터베이스 수준 CMK로 마이그레이션

새 데이터베이스는 생성 중에 데이터베이스 수준 CMK로 구성할 수 있으며, 서비스 관리형 키로 구성된 서버의 기존 데이터베이스는 데이터베이스 수준 고객 관리 키 기반 TDE용 ID 및 키 관리에 설명된 작업을 사용하여 데이터베이스 수준 CMK로 마이그레이션할 수 있습니다. 서버 수준 CMK 또는 지역 복제로 구성된 데이터베이스를 마이그레이션하려면 다음 섹션에 설명된 대로 다른 단계가 필요합니다.

지역 복제를 사용하지 않고 서버 수준 CMK로 구성된 데이터베이스

1. 데이터베이스에 대한 sys.dm_db_log_info(Transact-SQL) - SQL Server를 사용하고 활성 상태인 VLF(가상 로그 파일)를 찾습니다.
2. 모든 활성 VLF에 대해 sys.dm_db_log_info 결과에서 vlf_encryptor_thumbprint를 기록합니다.
3. 데이터베이스에 대한 sys.dm_database_encryption_keys(Transact-SQL) - SQL Server 보기를 사용하여 encryptor_thumbprint를 검사합니다. encryptor_thumbprint를 기록합니다.
4. Get-AzSqlServerKeyVaultKey cmdlet을 사용하여 논리 서버에 구성된 모든 서버 수준 키를 가져옵니다. 결과에서 위 결과의 목록과 일치하는 동일한 지문을 포함하는 항목을 선택합니다.
5. ID 및 암호화 보호기와 함께 마이그레이션하려는 데이터베이스에 대한 데이터베이스 업데이트 API 호출을 수행합니다. Set-AzSqlDatabase 및 -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector(필요한 경우 -FederatedClientId) 매개 변수를 사용하여 위의 키를 데이터베이스 수준 키로 전달합니다.

Important

데이터베이스 업데이트 요청에 사용되는 ID는 입력으로 전달되는 모든 키에 액세스할 수 있어야 합니다.

지역 복제를 사용하여 서버 수준 CMK로 구성된 데이터베이스

1. 이전 섹션에서 언급한 (1)~(4)단계를 수행하여 마이그레이션에 필요한 키 목록을 검색합니다.
2. 데이터베이스 수준 키로 ID 및 위의 키와 함께 Set-AzSqlDatabase 및 -KeyList 매개 변수를 사용하여 마이그레이션하려는 주 및 보조 데이터베이스에 대한 데이터베이스 업데이트 API 호출을 수행합니다. 암호화 보호기를 아직 설정하지 마세요.
3. 데이터베이스에서 기본 보호기로 사용하려는 데이터베이스 수준 키를 보조 데이터베이스에 먼저 추가해야 합니다. -KeyList와 함께 Set-AzSqlDatabase를 사용하여 보조 데이터베이스에 이 키를 추가합니다.
4. 암호화 보호기 키가 보조 데이터베이스에 추가되면 Set-AzSqlDatabase를 사용하여 -EncryptionProtector 매개 변수를 사용해 기본 데이터베이스에서 암호화 보호기로 설정합니다.
5. (4)에 설명된 대로 보조 데이터베이스에서 키를 암호화 보호기로 설정하여 마이그레이션을 완료합니다.

Important

서버 수준 서비스 관리형 키 및 지역 복제로 구성된 데이터베이스를 마이그레이션하려면 이 섹션의 (3), (4), (5)단계를 따릅니다.

지역 복제 및 고가용성

활성 지역 복제 및 장애 조치(failover) 그룹 시나리오 둘 다에서, 관련된 주 데이터베이스 및 보조 데이터베이스를 (모든 지역의) 동일한 키 자격 증명 모음 또는 별도의 키 자격 증명 모음에 연결할 수 있습니다. 별도의 키 자격 증명 모음이 주 서버 및 보조 서버에 연결된 경우 해당 지역에 중단이 발생하여 주 서버에 액세스할 수 없게 되고 장애 조치(failover)가 트리거되면 지역 보조 서버가 동기화되고 연결된 키 자격 증명 모음의 동일한 키를 사용하여 주 서버 역할을 인수할 수 있도록 고객은 전체 키 자격 증명 모음에서 키 자료를 일관되게 유지해야 합니다. 최대 4개의 보조 서버를 구성할 수 있으며 체인(보조 서버의 보조 서버)은 지원되지 않습니다.

데이터베이스 수준 CMK로 구성된 데이터베이스에 대해 활성 지역 복제를 설정하려면 유효한 사용자가 할당한 관리 ID 및 주 데이터베이스에서 사용 중인 현재 키 목록을 통해 보조 복제본(replica)을 생성해야 합니다. 필요한 필터 및 쿼리 매개 변수를 사용하거나 PowerShell 및 Azure CLI를 사용하여 주 데이터베이스에서 현재 키 목록을 검색할 수 있습니다. 이러한 데이터베이스의 지역 복제본(replica)을 설정하는 데 필요한 단계는 다음과 같습니다.

1. Get-AzSqlDatabase 명령과 -ExpandKeyList 및 -KeysFilter "current" 매개 변수를 사용하여 주 데이터베이스에서 사용하는 키 목록을 미리 채웁니다. 모든 키를 검색하려는 경우 -KeysFilter를 제외합니다.
2. 사용자가 할당한 관리 ID, 그리고 교차 테넌트 액세스가 구성된 경우 페더레이션된 클라이언트 ID를 선택합니다.
3. New-AzSqlDatabaseSecondary를 사용하여 새 데이터베이스를 보조로 생성하고 -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector(필요한 경우 -FederatedClientId) 매개 변수를 사용하여 API 호출에서 원본 데이터베이스에서 가져온 미리 채워진 키 목록 및 위 ID(교차 테넌트 액세스를 구성한 경우 페더레이션된 클라이언트 ID)를 제공합니다.
4. New-AzSqlDatabaseCopy를 사용하여 이전 단계와 동일한 매개 변수를 사용하여 데이터베이스의 복사본을 생성합니다.

Important

데이터베이스 수준 CMK로 구성된 데이터베이스에는 데이터베이스 수준 CMK로 구성된 복제본(replica) 또는 복사본이 있어야 합니다. 복제본(replica)은 서버 수준 암호화 설정을 사용할 수 없습니다.

장애 조치(failover) 그룹에서 데이터베이스 수준 CMK로 구성된 데이터베이스를 사용하려면 주 복제본과 동일한 이름의 보조 복제본을 생성하는 위의 단계를 보조 서버에서 사용해야 합니다. 이 보조 복제본(replica)이 구성되면 데이터베이스를 장애 조치(failover) 그룹에 추가할 수 있습니다.

데이터베이스 수준 CMK로 구성된 데이터베이스는 장애 조치(failover) 그룹에 추가될 때 자동화된 보조 생성을 지원하지 않습니다.

자세한 내용은 데이터베이스 수준 고객 관리 키 기반 투명한 데이터 암호화에 대한 지역 복제 및 백업 복원 구성을 참조하세요. 여기에서는 REST API, PowerShell 및 Azure CLI를 사용하여 지역 복제 및 장애 조치(failover) 그룹을 설정하는 방법을 설명합니다.

참고 항목

서버 수준 CMK와 관련하여 CMK 기반 TDE(투명한 데이터 암호화)에서 강조 표시된 지역 복제 및 고가용성에 대한 모든 모범 사례는 데이터베이스 수준 CMK에 적용됩니다.

데이터베이스 수준에서 고객 관리형 키와 함께 TDE를 사용하여 데이터베이스 백업 및 복원

Azure Key Vault의 키를 사용하여 데이터베이스가 TDE를 통해 암호화되면 새로 생성된 모든 백업도 동일한 TDE 보호기로 암호화됩니다. TDE 보호기가 변경되면 데이터베이스의 이전 백업이 최신 TDE 보호기를 사용하도록 업데이트되지 않습니다. 데이터베이스 수준에서 구성된 Azure Key Vault에서 TDE 보호기로 암호화된 백업을 복원하려면 대상 서버에서 키 관련 자료를 사용할 수 있는지 확인합니다. 데이터베이스 백업을 복원할 수 있도록 이전 버전의 TDE 보호기를 모두 키 자격 증명 모음에서 유지하는 것이 좋습니다.

Important

데이터베이스에 대해 하나의 TDE 보호기만 설정할 수 있습니다. 그러나 여러 추가 키를 TDE 보호기로 표시하지 않고 복원 중에 데이터베이스에 전달할 수 있습니다. 해당 키는 DEK를 보호하는 데 사용되지 않지만, 백업 파일이 해당 지문을 사용한 키로 암호화된 경우 백업에서 복원하는 동안 해당 키를 사용할 수 있습니다.

특정 시점 복원

다음 단계는 데이터베이스 수준 고객 관리형 키로 구성된 데이터베이스의 특정 시점 복원에 필요합니다.

1. Get-AzSqlDatabase 명령과 -ExpandKeyList 및 -KeysFilter "2023-01-01" 매개 변수를 사용하여 주 데이터베이스에서 사용하는 키 목록을 미리 채웁니다. 2023-01-01은 데이터베이스를 복원하려는 시점의 예입니다. 모든 키를 검색하려는 경우 -KeysFilter를 제외합니다.
2. 사용자가 할당한 관리 ID, 그리고 교차 테넌트 액세스가 구성된 경우 페더레이션된 클라이언트 ID를 선택합니다.
3. -FromPointInTimeBackup 매개 변수와 함께 Restore-AzSqlDatabase를 사용하고 -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector(필요한 경우 -FederatedClientId) 매개 변수를 사용하여 API 호출에서 위 단계에서 확보한 미리 채워진 키 목록 및 위 ID(교차 테넌트 액세스를 구성한 경우 페더레이션된 클라이언트 ID)를 제공합니다.

참고 항목

모든 유효한 키를 사용하여 -EncryptionProtector 속성 없이 데이터베이스를 복원하면 서버 수준 암호화를 사용하도록 다시 설정됩니다. 이는 데이터베이스 수준 고객 관리형 키 구성을 서버 수준 고객 관리형 키 구성에 되돌리는 데 유용할 수 있습니다.

삭제된 데이터베이스 복원

다음 단계는 데이터베이스 수준 고객 관리형 키로 구성된 데이터베이스의 삭제된 데이터베이스 복원에 필요합니다.

1. Get-AzSqlDeletedDatabaseBackup 및 -ExpandKeyList 매개 변수를 사용하여 주 데이터베이스에서 사용하는 키 목록을 미리 채웁니다. 원본 데이터베이스에서 사용하던 모든 키를 전달하는 것이 좋지만, 삭제 시간에 제공된 키를 -KeysFilter로 사용하여 복원을 시도할 수도 있습니다.
2. 사용자가 할당한 관리 ID, 그리고 교차 테넌트 액세스가 구성된 경우 페더레이션된 클라이언트 ID를 선택합니다.
3. -FromDeletedDatabaseBackup 매개 변수와 함께 Restore-AzSqlDatabase를 사용하고 -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector(필요한 경우 -FederatedClientId) 매개 변수를 사용하여 API 호출에서 위 단계에서 확보한 미리 채워진 키 목록 및 위 ID(교차 테넌트 액세스를 구성한 경우 페더레이션된 클라이언트 ID)를 제공합니다.

지역 복원

다음 단계는 데이터베이스 수준 고객 관리형 키로 구성된 데이터베이스의 지역 복원에 필요합니다.

• Get-AzSqlDatabaseGeoBackup 및 -ExpandKeyList를 사용하여 주 데이터베이스에서 사용하는 키 목록을 미리 채워 모든 키를 검색합니다.
• 사용자가 할당한 관리 ID, 그리고 교차 테넌트 액세스가 구성된 경우 페더레이션된 클라이언트 ID를 선택합니다.
• -FromGeoBackup 매개 변수와 함께 Restore-AzSqlDatabase를 사용하고 -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector(필요한 경우 -FederatedClientId) 매개 변수를 사용하여 API 호출에서 위 단계에서 확보한 미리 채워진 키 목록 및 위 ID(교차 테넌트 액세스를 구성한 경우 페더레이션된 클라이언트 ID)를 제공합니다.

Important

데이터베이스를 복원하기 위해 데이터베이스에서 사용하는 모든 키를 유지하는 것이 좋습니다. 또한 이러한 모든 키를 복원 대상에 전달하는 것이 좋습니다.

참고 항목

LTR(장기 백업 보존) 백업은 백업에서 사용하는 키 목록을 제공하지 않습니다. LTR 백업을 복원하려면 원본 데이터베이스에서 사용하는 모든 키를 LTR 복원 대상으로 전달해야 합니다.

Powershell, Azure CLI 및 REST API를 사용하는 예제와 함께 데이터베이스 수준 CMK를 사용하여 SQL Database의 백업 복구에 대해 자세히 알아보려면 데이터베이스 수준 고객 관리형 키 기반 투명한 데이터 암호화에 대한 지역 복제 및 백업 복원 구성을 참조하세요.

제한 사항

데이터베이스 수준 고객 관리형 키 기능은 데이터베이스 가상 로그 파일이 데이터베이스의 현재 주 보호기와 다른 이전 키로 암호화된 경우 키 순환을 지원하지 않습니다. 이 경우 발생하는 오류는 다음과 같습니다.

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: 활성 트랜잭션이 이전 키로 암호화된 로그를 유지하는 경우 데이터베이스 수준에서 TDE 보호기 키 순환이 차단됩니다.

이 시나리오를 더 자세히 이해하기 위해 다음 타임라인 살펴봅니다.

• 시간 t0 = 암호화 없이 데이터베이스가 생성됩니다.
• 시간 t1 = 이 데이터베이스는 데이터베이스 수준 고객 관리형 키인 Thumbprint A에 의해 보호됩니다.
• 시간 t2 = 데이터베이스 보호기가 새 데이터베이스 수준 고객 관리형 키(Thumbprint B)로 순환됩니다.
• 시간 t3 = Thumbprint C로의 보호기 변경이 요청됩니다.
• 활성 VLF에서 Thumbprint A를 사용하는 경우 순환이 허용되지 않습니다.
• 활성 VLF에서 Thumbprint A를 사용하지 않는 경우 순환이 허용됩니다.

데이터베이스에 대한 sys.dm_db_log_info(Transact-SQL) - SQL Server 보기를 사용하고 활성 상태인 가상 로그 파일을 찾을 수 있습니다. 첫 번째 키(예: Thumbprint A)로 암호화된 활성 VLF가 표시됩니다. 데이터 삽입으로 충분한 로그가 생성되면 이 이전 VLF가 플러시되고 다른 키 순환을 수행할 수 있어야 합니다.

예상보다 오래 로그를 보관하고 있다고 생각되는 경우 추가 문제 해결을 위해 다음 설명서를 참조하세요.

• 가능한 log_truncation_holdup_reason 값에 대한 sys.dm_db_log_stats(Transact-SQL).
• 전체 트랜잭션 로그 오류 9002 문제 해결.

다음 단계

다양한 데이터베이스 수준 CMK 작업에 대한 다음 설명서를 확인하세요.

• 데이터베이스 수준 고객 관리형 키를 사용하는 TDE에 대한 ID 및 키 관리

• 데이터베이스 수준 고객 관리형 키를 사용하는 투명한 데이터 암호화에 대한 지역 복제 및 백업 복원 구성