고객 관리형 키를 사용한 Azure SQL 투명한 데이터 암호화

적용 대상:Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics(전용 SQL 풀만 해당)

고객 관리형 키 기반 Azure SQL TDE(투명한 데이터 암호화)를 사용하면 미사용 데이터 보호를 위한 BYOK(Bring Your Own Key) 시나리오를 지원할 수 있으며, 조직에서는 키 및 데이터 관리에서 업무 분리를 구현할 수 있습ㄴ다. 고객 관리형 TDE를 사용하면 고객은 키 수명 주기 관리(키 만들기, 업로드, 회전, 삭제), 키 사용 권한 및 키 관련 작업 감사를 완전히 제어하며 수행할 수 있습니다.

이 시나리오에서 TDE 보호기라는 DEK(데이터베이스 암호화 키)를 암호화하는 데 사용되는 키는 클라우드 기반 외부 키 관리 시스템인 고객 소유 및 고객 관리형 AKV(Azure Key Vault)에 저장된 고객 관리형 비대칭 키입니다. Key Vault는 가용성이 우수하며 RSA 암호화 키에 대해 안전하고 확장성 있는 스토리지입니다. FIPS 140-2 수준 2 유효성 검사를 통과한 HSM(하드웨어 보안 모듈)을 선택 사항으로 지원합니다. 저장된 키에 직접 액세스할 수 없지만, 권한 있는 엔터티에 대한 키를 사용하여 암호화/암호 해독 서비스를 제공합니다. 키는 Key Vault에 의해 생성되거나, 가져오거나,온-프레미스 HSM 디바이스에서 Key Vault로 전송될 수 있습니다.

Azure SQL Database 및 Azure Synapse Analytics의 경우 TDE 보호기는 서버 수준에서 설정되며 해당 서버와 연결된 모든 암호화된 데이터베이스에서 상속됩니다. Azure SQL Managed Instance의 경우 TDE 보호기는 인스턴스 수준에서 설정되며 해당 인스턴스의 모든 암호화된 데이터베이스에 의해 상속됩니다. 서버라는 용어는 달리 명시되지 않는 한 이 문서 전체에서 SQL Database 및 Azure Synapse의 서버와 SQL Managed Instance의 관리되는 인스턴스를 모두 나타냅니다.

Azure SQL Database의 데이터베이스 수준에서 TDE 보호기를 관리할 수 있습니다. 자세한 내용은 데이터베이스 수준에서 고객 관리형 키 기반 TDE(투명한 데이터 암호화)를 참조하세요.

참고 항목

• 이 문서는 Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics(전용 SQL 풀(이전의 SQL DW))에 적용됩니다. Synapse 작업 영역 내의 전용 SQL 풀을 위한 투명한 데이터 암호화에 관한 설명서는 Azure Synapse Analytics 암호화를 참조하세요.
• Azure SQL 고객에게 미사용 데이터의 두 계층 암호화를 제공하기 위해 플랫폼 관리형 키를 사용한 인프라 암호화(AES-256 암호화 알고리즘 사용)가 출시되고 있습니다. 이는 이미 사용 가능한 고객 관리형 키가 있는 TDE와 함께 저장 시 암호화의 추가 계층을 제공합니다. Azure SQL Database 및 Azure SQL Managed Instance의 경우 인프라 암호화가 설정되면 master 데이터베이스 및 기타 시스템 데이터베이스를 비롯한 모든 데이터베이스가 암호화됩니다. 이때 고객은 이 기능에 대한 액세스를 요청해야 합니다. 이 기능에 관심이 있는 경우 AzureSQLDoubleEncryptionAtRest@service.microsoft.com에 문의하세요.

참고 항목

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

고객 관리형 TDE의 이점

고객 관리형 TDE는 고객에게 다음과 같은 이점을 제공합니다.

• TDE 보호기의 사용 및 관리를 완벽하게 세부적으로 제어,

• TDE 보호기 사용의 투명성,

• 조직 내 키 및 데이터 관리에서 업무 분리를 구현할 수 있음,

• Key Vault 관리자가 키 액세스 권한을 해지하여 암호화된 데이터베이스에 액세스할 수 없도록 설정할 수 있음,

• AKV의 키 중앙 관리,

• AKV는 Microsoft가 암호화 키를 보거나 추출할 수 없도록 디자인되었으므로 최종 고객의 신뢰가 향상됨

Important

고객 관리형 TDE 사용을 시작하려는 서비스 관리형 TDE를 사용 중인 사용자의 경우 전환하는 동안 데이터가 암호화된 상태로 유지되며 가동 중지 시간이 발생하지 않고 데이터베이스 파일도 다시 암호화되지 않습니다. 서비스 관리형 키에서 고객 관리형 키로 전환하는 경우에만 빠른 온라인 작업인 DEK를 다시 암호화해야 합니다.

고객 관리형 TDE의 작동 방법

Azure의 논리 서버에서 DEK 암호화를 위해 AKV에 저장된 TED 보호기를 사용하려면 키 자격 증명 모음 관리자가 고유한 Microsoft Entra ID를 사용하여 서버에 대한 다음 액세스 권한을 부여해야 합니다.

• get - Key Vault에서 키의 퍼블릭 파트 및 속성 검색

• wrapKey - DEK를 보호(암호화)할 수 있음

• unwrapKey - DEK를 보호 해제(암호 해독)할 수 있음

키 자격 증명 모음 관리자는 나중에 감사될 수 있도록 키 자격 증명 모음 감사 이벤트의 로깅을 사용하도록 설정할 수도 있습니다.

서버가 AKV에서 TDE 보호기를 사용하도록 구성된 경우 서버는 암호화를 위해 각 TDE 지원 데이터베이스의 DEK를 키 자격 증명 모음으로 보냅니다. 키 자격 증명 모음은 암호화된 DEK를 반환하며 이 DEK는 이후 사용자 데이터베이스에 저장됩니다.

필요한 경우 서버는 암호 해독을 위해 보호된 DEK를 키 자격 증명 모음으로 보냅니다.

로깅이 사용되는 경우 감사자는 Azure Monitor를 사용하여 키 자격 증명 모음 AuditEvent 로그를 검토할 수 있습니다.

참고

키 자격 증명 모음에 권한 변경 내용을 적용하는 데 10분 정도 걸릴 수 있습니다. 여기에는 AKV의 TDE 보호기에 대한 액세스 권한을 취소하는 작업이 포함되며 이 시간 프레임 내의 사용자에게는 여전히 액세스 권한이 있을 수 있습니다.

고객 관리형 TDE를 구성하기 위한 요구 사항

AKV 구성을 위한 요구 사항

• 실수로 인한 키(또는 키 자격 증명 모음) 삭제로 인해 데이터가 손실되지 않도록 키 자격 증명 모음에서 일시 삭제 및 제거 보호 기능을 사용하도록 설정해야 합니다.

• Microsoft Entra ID를 사용하여 키 자격 증명 모음(get, wrapKey, unwrapKey)에 대한 액세스 권한을 서버 또는 관리형 인스턴스에 부여합니다. 서버 ID는 시스템이 서버에 할당한 관리 ID 또는 사용자가 서버에 할당한 관리 ID입니다. Azure Portal을 사용하는 경우 서버가 만들어질 때 Microsoft Entra ID가 자동으로 만들어집니다. PowerShell 또는 Azure CLI를 사용하는 경우 Microsoft Entra ID가 명시적으로 만들어지고 확인되어야 합니다. PowerShell을 사용하는 경우 자세한 단계별 지침은 BYOK 기반 TDE 구성 및 SQL Managed Instance에 대해 BYOK 기반 TDE 구성을 참조하세요.

  • 키 자격 증명 모음의 권한 모델(액세스 정책 또는 Azure RBAC)에 따라 다르지만, 키 자격 증명 모음에 대한 액세스 정책을 만들거나 키 자격 증명 모음 암호화 서비스 암호화 사용자 역할로 새 Azure RBAC 역할 할당을 만들어 키 자격 증명 모음 액세스 권한을 부여할 수 있습니다.

• AKV와 함께 방화벽을 사용하는 경우 신뢰할 수 있는 Microsoft 서비스가 방화벽을 우회하도록 허용 옵션을 사용하도록 설정해야 합니다. 자세한 내용은 Azure Key Vault 방화벽 및 가상 네트워크 구성을 참조하세요.

AKV에 대해 일시 삭제 및 제거 보호 사용

중요

신규 또는 기존 서버 또는 관리되는 인스턴스에서 고객 관리 TDE를 구성할 때 키 자격 증명 모음에서 일시 삭제 및 제거 보호를 모두 사용하도록 설정해야 합니다.

일시 삭제 및 제거 보호를 사용하면 삭제된 자격 증명 모음 및 삭제된 키 자격 증명 모음 개체의 복구가 가능하여 사용자가 실수로 또는 악의적으로 키 또는 키 자격 증명 모음을 삭제할 위험을 줄여주는 Azure Key Vault의 중요한 기능입니다.

• 일시 삭제된 리소스는 고객이 복구하거나 제거하지 않는 한 90일 동안 보존됩니다. 복구 및 제거 작업에는 키 자격 증명 모음 액세스 정책과 연결된 고유 권한이 있습니다. 일시 삭제 기능은 새 키 자격 증명 모음에 대해 기본적으로 켜져 있으며 Azure Portal, PowerShell 또는 Azure CLI를 사용하여 사용하도록 설정할 수도 있습니다.

• 제거 보호는 Azure CLI 또는 PowerShell을 사용하여 활성화할 수 있습니다. 제거 보호를 사용하도록 설정하면 보존 기간이 지나기 전에는 삭제된 상태의 키 자격 증명 모음이나 개체를 제거할 수 없습니다. 기본 보존 기간은 90일이지만 Azure Portal을 통해 7일에서 90일까지 구성할 수 있습니다.

• Azure SQL을 사용하려면 서버 또는 관리되는 인스턴스의 TDE 보호기로 사용되는 암호화 키가 포함된 키 자격 증명 모음에서 일시 삭제 및 제거 보호를 사용하도록 설정해야 합니다. 이렇게 하면 데이터베이스에 액세스할 수 없는 상태가 될 수 있는 우발적이거나 악의적인 키 자격 증명 모음 또는 키 삭제 시나리오를 방지하는 데 유용합니다.

• 기존 서버에서 TDE 보호기를 구성하거나 서버를 만드는 동안 Azure SQL은 사용 중인 키 자격 증명 모음에 일시 삭제 및 제거 보호가 켜져 있는지 검증합니다. 키 자격 증명 모음에서 일시 삭제 및 제거 보호를 사용하도록 설정되어 있지 않으면 오류가 표시되고 TDE 보호기 설정이 실패합니다. 이런 경우 먼저 키 자격 증명 모음에서 일시 삭제 및 제거 보호를 사용하도록 설정한 다음, TDE 보호기 설정을 수행해야 합니다.

TDE 보호기를 구성하기 위한 요구 사항

• TDE 보호기는 비대칭, RSA 또는 RSA HSM 키여야 합니다. 지원되는 키 길이는 2048비트 및 3072비트입니다.

• 키 활성화 날짜(설정된 경우)는 과거의 날짜와 시간이어야 합니다. 만료 날짜(설정된 경우)는 미래 날짜 및 시간이어야 합니다.

• 키가 사용 상태여야 합니다.

• 기존 키를 키 자격 증명 모음으로 가져올 때, 지원되는 파일 형식(.pfx, .byok 또는 .backup)으로 제공해야 합니다.

참고

이제 Azure SQL은 관리형 HSM에 저장된 RSA 키를 TDE 보호기로 사용하도록 지원합니다. Azure Key Vault 관리형 HSM은 FIPS 140-2 수준 3 유효성이 검사된 HSM을 사용하여 클라우드 애플리케이션용 암호화 키를 보호할 수 있는 완전 관리형 고가용 단일 테넌트 표준 규격 클라우드 서비스입니다. 관리형 HSM에 대해 자세히 알아봅니다.

참고

Thales CipherTrust Manager v2.8.0 이전 버전과 관련된 문제로 인해 Azure Key Vault에 새로 가져온 키는 고객 관리형 TDE 시나리오를 위해 Azure SQL Database 또는 Azure SQL Managed Instance에 사용되지 않습니다. 이 이슈에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 이러한 경우 키 자격 증명 모음으로 키를 가져온 후 24시간 동안 기다렸다가 서버 또는 관리되는 인스턴스에 대한 TDE 보호기로 사용하기 시작합니다. 이 문제는 Thales CipherTrust Manager v2.8.0에서 해결되었습니다.

고객 관리형 TDE 구성 시 권장 사항

AKV 구성 시 권장 사항

• 단일 구독에서 전체로서 최대 500개 범용 또는 200개 중요 비즈니스용 데이터베이스를 키 자격 증명 모음과 연결하여 서버가 키 자격 증명 모음의 TDE 보호기에 액세스할 때 고가용성을 보장합니다. 해당 수치는 환경에 따라 달라지며 키 자격 증명 모음 서비스 한도에 설명되어 있습니다. 해당 서버에 있는 데이터베이스 수만큼 키 작업이 자격 증명 모음에 대해 트리거되므로 여기서는 서버 장애 조치(failover) 후에 문제를 방지하기 위해서만 사용됩니다.

• 이 중요한 리소스를 삭제할 수 있는 사용자를 제어하고 실수로 인한 삭제나 무단 삭제를 방지할 수 있도록 키 자격 증명 모음에 리소스 잠금을 설정합니다. 리소스 잠금을 자세히 알아봅니다.

• 모든 암호화 키에 대한 감사 및 보고 사용: Key Vault는 다른 보안 정보 및 이벤트 관리 도구에 쉽게 삽입되는 로그를 제공합니다. Operations Management Suite Log Analytics는 이미 통합된 서비스의 한 예입니다.

• 서로 다른 지역에 있는 두 개의 키 자격 증명 모음에 각 서버를 연결하고 동일한 키 자료를 보관하여 암호화된 데이터베이스의 고가용성을 보장합니다. 키 자격 증명 모음 중 하나의 키를 TDE 보호기로 표시합니다. 첫 번째 지역에 키 자격 증명 모음에 영향을 주는 중단이 발생하면 시스템은 동일한 키 자료를 사용하여 두 번째 지역의 키 자격 증명 모음으로 자동으로 전환됩니다.

참고

고객 관리 TDE를 보다 유연하게 구성할 수 있도록 한 지역의 Azure SQL Database 및 Azure SQL Managed Instance를 이제 다른 지역의 Key Vault에 연결할 수 있습니다. 서버와 키 자격 증명 모음은 같은 지역에 함께 위치할 필요가 없습니다.

TDE 보호기 구성 시 권장 사항

• TDE 보호기의 복사본을 안전한 장소에 보관하거나 에스크로 서비스로 에스크로합니다.

• 키 자격 증명 모음에서 키를 생성하는 경우 AKV에서 키를 처음으로 사용하기 전에 키 백업을 만듭니다. 백업은 Azure Key Vault로만 복원할 수 있습니다. Backup-AzKeyVaultKey 명령을 자세히 알아봅니다.

• 키의 내용(예: 키 특성, 태그, ACL)이 변경될 때마다 새 백업을 만듭니다.

• 키를 회전할 때 키 자격 증명 모음에서 이전 버전의 키를 유지합니다. 그러면 이전 데이터베이스 백업을 복원할 수 있습니다. 데이터베이스의 TDE 보호기가 변경되면 데이터베이스의 이전 백업이 최신 TDE 보호기를 사용하도록 업데이트되지 않습니다. 복원 시 각 백업에는 만들 때 암호화한 TDE 보호기가 필요합니다. 키 회전은 PowerShell을 사용하여 투명한 데이터 암호화 방지 프로그램 회전에 나와 있는 지침에 따라 수행할 수 있습니다.

• 서비스 관리형 키로 전환한 후에도 이전에 사용한 모든 키를 AKV에서 유지합니다. 이렇게 하면 AKV에 저장된 TDE 보호기를 사용하여 데이터베이스 백업을 복원할 수 있습니다. Azure Key Vault에서 만든 TDE 보호기는 서비스 관리형 키를 사용하여 나머지 저장된 백업이 모두 만들어질 때까지 유지되어야 합니다. Backup-AzKeyVaultKey를 사용하여 이러한 키의 복구 가능한 백업 복사본을 만듭니다.

• 데이터가 손실될 위험 없이 보안 인시던트 중에 잠재적으로 손상될 수 있는 키를 제거하려면 잠재적으로 손상될 수 있는 키 제거의 단계를 따릅니다.

TDE 보호기의 회전

서버의 TDE 보호기를 회전한다는 것은 서버의 데이터베이스를 보호하는 새 비대칭 키로 전환한다는 의미입니다. 키 회전은 온라인 작업으로 완료하는 데 몇 초면 됩니다. 이 작업은 전체 데이터베이스가 아닌 데이터베이스 암호화 키의 암호를 해독하고 다시 암호화합니다.

TDE 보호기의 회전은 수동으로 또는 자동화된 회전 기능을 사용하여 수행할 수 있습니다.

서버에 대한 TDE 보호기를 구성할 때 TDE 보호기의 자동 순환을 사용하도록 설정할 수 있습니다. 자동화된 회전은 기본적으로 사용하지 않도록 설정됩니다. 사용하도록 설정하면 서버는 TDE 보호기로 사용되는 키의 새 버전에 대해 키 자격 증명 모음을 지속적으로 확인합니다. 새 버전의 키가 감지되면 서버 또는 데이터베이스의 TDE 보호기가 24시간 이내에 최신 키 버전으로 자동 순환됩니다.

Azure Key Vault의 자동화된 키 회전과 함께 사용하는 경우 이 기능을 사용하면 Azure SQL Database 및 Azure SQL Managed Instance에서 TDE 보호기에 엔드 투 엔드 제로 터치 회전을 사용할 수 있습니다.

참고 항목

키의 수동 또는 자동 순환을 사용하여 CMK로 TDE를 설정하면 항상 지원되는 최신 버전의 키를 사용합니다. 설정에서는 이전 또는 하위 버전의 키를 사용할 수 없습니다. 항상 최신 키 버전을 사용하면 손상될 수 있는 이전 키 버전을 허용하지 않는 Azure SQL 보안 정책을 준수합니다. 이전 버전의 키는 데이터베이스 백업 또는 복원을 위해 필요할 수 있으며, 특히 장기 보존 백업의 경우 이전 키 버전을 유지해야 합니다. 지역 복제 설정의 경우 원본 서버에 필요한 모든 키가 대상 서버에 있어야 합니다.

TDE 보호기의 자동화된 회전을 구성할 때 지역 복제 고려 사항

설정 또는 지역 복제 중 문제를 방지하려면 주 또는 보조 서버에서 TDE 보호기의 자동 회전을 사용하는 경우 지역 복제를 구성할 때 다음 규칙을 따르는 것이 중요합니다.

• 주 서버와 보조 서버 모두 주 서버의 키 자격 증명 모음(주 서버의 TDE 보호기 키를 보유하는 키 자격 증명 모음)에 대한 Get, wrapKey 및 unwrapKey 권한이 있어야 합니다.

• 자동화된 키 회전이 사용하도록 설정된 서버의 경우 지역에서 복제를 시작하기 전에 주 서버에서 TDE 보호기로 사용 중인 암호화 키를 보조 서버에 추가합니다. 보조 서버에는 (키 자료가 동일한 다른 키가 아니라) 주 서버와 함께 사용 중인 동일한 키 자격 증명 모음의 키에 대한 액세스 권한이 필요합니다. 또는 지역 복제를 시작하기 전에 보조 서버의 관리 ID(사용자 할당 또는 시스템 할당)에 주 서버의 키 자격 증명 모음에 필요한 권한이 있는지 확인합니다. 시스템에서는 보조 서버에 키를 추가하려고 시도합니다.

• 기존 지역 복제 설정의 경우 주 서버에서 자동화된 키 회전을 사용하도록 설정하기 전에 주 서버에서 TDE 보호기로 사용 중인 암호화 키를 보조 서버에 추가합니다. 보조 서버에는 (키 자료가 동일한 다른 키가 아니라) 주 서버와 함께 사용 중인 동일한 키 자격 증명 모음의 키에 대한 액세스 권한이 필요합니다. 또는 자동화된 키를 사용하기 전에 보조 서버의 관리 ID(사용자 할당 또는 시스템 할당)에 주 서버의 키 자격 증명 모음에 필요한 권한이 있는지 확인합니다. 시스템에서는 보조 서버에 키를 추가하려고 시도합니다.

• TDE에 CMK(고객 관리형 키)를 사용하는 지역 복제 시나리오가 지원됩니다. Azure Portal에서 TDE를 구성하는 경우 모든 서버에서 자동 키 순환을 사용하는 TDE를 구성해야 합니다. TDE를 사용하여 지역 복제 구성에 대한 자동 키 순환을 설정하는 방법에 대한 자세한 내용은 지역 복제 구성에 대한 자동 키 순환을 참조하세요.

액세스할 수 없는 TDE 보호기

TDE가 고객 관리형 키를 사용하도록 구성된 경우 데이터베이스를 온라인 상태로 유지하려면 TDE 보호기에 지속적인 액세스 권한이 필요합니다. 서버가 AKV에서 고객 관리형 TDE 보호기에 대한 액세스 권한을 유실하면 최대 10분 내에 데이터베이스는 먼저 해당하는 오류 메시지와 함께 모든 연결을 거부하고 해당 상태를 액세스할 수 없음으로 변경합니다. 액세스할 수 없음 상태의 데이터베이스에서 허용되는 유일한 작업은 삭제하는 것입니다.

참고

일시적인 네트워킹 중단으로 인해 데이터베이스에 액세스할 수 없는 경우에는 작업이 필요하지 않으며 데이터베이스가 자동으로 다시 온라인 상태로 전환됩니다.

키에 대한 액세스 권한을 복원한 후 데이터베이스를 다시 온라인 상태로 전환하려면 추가 시간과 단계가 필요하며, 이는 키에 액세스하지 않고 경과된 시간과 데이터베이스에 있는 데이터의 크기에 따라 달라질 수 있습니다.

참고 항목

• 키 액세스가 30분 이내에 복원되면 데이터베이스는 다음 시간 내에 자동 복구됩니다.
• 키 액세스 복원이 30분을 초과하면 데이터베이스의 자동 복구가 가능하지 않습니다. 데이터베이스를 복구하려면 Azure Portal에서 추가 단계가 필요하고 데이터베이스 크기에 따라 상당한 시간이 걸릴 수 있습니다.
• 데이터베이스가 다시 온라인 상태가 되면 탄력적 풀 구성, 읽기 확장, 자동 일시 중지, 특정 시점 복원 기록, 장기 보존 정책 등과 같은 장애 조치(failover) 그룹 구성, 태그 및 데이터베이스 수준 설정을 포함할 수 있는 이전에 구성된 서버 수준 설정이 손실됩니다. 따라서 고객은 30분 이내에 암호화 키 액세스의 손실을 식별하는 알림 시스템을 구현하는 것이 좋습니다. 30분 기간이 만료되면 복구된 데이터베이스에서 모든 서버 및 데이터베이스 수준 설정의 유효성을 검사하는 것이 좋습니다.

액세스할 수 없는 데이터베이스를 다시 온라인으로 전환하기 위해 포털에 필요한 추가 단계를 아래에서 확인합니다.

실수로 인한 TDE 보호기 액세스 해지

키 자격 증명 모음에 대한 충분한 액세스 권한을 가진 사용자가 다음과 같은 실수로 인해 키에 대한 서버 액세스 권한을 사용하지 않도록 설정하는 문제가 발생할 수 있습니다.

• 서버에서 키 자격 증명 모음의 get, wrapKey, unwrapKey 권한을 해지합니다.

• 키 삭제

• 키 자격 증명 모음 삭제

• 키 자격 증명 모음의 방화벽 규칙 변경

• Microsoft Entra ID에서 서버의 관리 ID 삭제

데이터베이스가 액세스할 수 없게 되는 일반적인 원인을 자세히 알아봅니다.

SQL Managed Instance 및 Key Vault 간의 연결이 차단됨

SQL Managed Instance에서 Azure Key Vault의 TDE 보호기에 액세스하려고 하는 동안 발생하는 네트워크 오류로 인해 데이터베이스의 상태가 ‘액세스할 수 없음’으로 변경되지 않고 나중에 인스턴스를 사용할 수 없게 됩니다. 이는 주로 Key Vault 리소스는 있지만 관리되는 인스턴스에서 해당 엔드포인트에 연결할 수 없는 경우에 발생합니다. Key Vault 엔드포인트에 연결할 수 있지만 연결이 거부되거나 사용 권한이 누락된 것과 같은 모든 시나리오에서 데이터베이스의 상태가 ‘액세스할 수 없음’으로 변경됩니다.

Key Vault에 대한 네트워킹 연결이 부족한 가장 일반적인 원인은 다음과 같습니다.

• Key Vault는 프라이빗 엔드포인트를 통해 노출되며 AKV 서비스의 개인 IP 주소는 관리되는 인스턴스 서브넷과 연결된 NSG(네트워크 보안 그룹)의 아웃바운드 규칙에서 허용되지 않습니다.
• Key Vault FQDN이 확인되지 않거나 잘못된 IP 주소로 확인되는 경우와 같은 DNS 확인 문제가 있습니다.

SQL Managed Instance에서 TDE 보호기를 호스트하는 Key Vault로의 연결을 테스트합니다.

• 엔드포인트는 <vault_name>.vault.azure.net(https:// 제외)과 자격 증명 모음 FQDN입니다.
• 테스트할 포트는 443입니다.
• RemoteAddress에 대한 결과가 있어야 하며 올바른 IP 주소여야 합니다.
• TCP 테스트의 결과는 TcpTestSucceeded: True여야 합니다.

테스트가 TcpTestSucceeded: False를 반환하는 경우 네트워킹 구성을 검토합니다.

• 확인된 IP 주소가 유효한지 검토합니다. 값이 누락된 경우 DNS 확인에 문제가 있음을 의미합니다.
  • 특히 확인된 주소가 Key Vault의 프라이빗 엔드포인트에 속하는 경우, 관리되는 인스턴스의 네트워크 보안 그룹에 포트 443에서 확인된 IP 주소를 포함하는 아웃바운드 규칙이 있는지 확인합니다.
  • 경로 테이블, 가상 어플라이언스의 존재 및 해당 구성 등의 기타 네트워킹 구성을 확인합니다.

고객 관리형 TDE 모니터링

데이터베이스 상태를 모니터링하고 TDE 보호기 액세스 권한 손실을 경고하기 위해 다음 Azure 기능을 구성합니다.

• Azure Resource Health. TDE 보호기에 대한 액세스 권한이 손실된 액세스할 수 없는 데이터베이스는 데이터베이스에 대한 첫 번째 연결이 거부된 후 “액세스할 수 없음”으로 표시됩니다.
• 활동 로그 고객 관리형 키 자격 증명 모음의 TDE 보호기에 대한 액세스가 실패하면 항목이 활동 로그에 추가됩니다. 해당 이벤트에 관한 경고를 생성하면 최대한 빠르게 액세스를 복구할 수 있습니다.
• 작업 그룹은 이메일/SMS/푸시/보이스, Logic App, 웹후크, ITSM 또는 자동화 런북과 같은 기본 설정에 따라 알림 및 경고를 보내도록 정의할 수 있습니다.

고객 관리형 TDE를 사용한 데이터베이스 백업 및 복원

Key Vault의 키를 사용하여 데이터베이스가 TDE를 통해 암호화되면 새로 생성된 모든 백업도 동일한 TDE 보호기로 암호화됩니다. TDE 보호기가 변경되면 데이터베이스의 이전 백업이 최신 TDE 보호기를 사용하도록 업데이트되지 않습니다.

Key Vault에서 TDE 보호기로 암호화된 백업을 복원하려면 대상 서버에서 키 자료를 사용할 수 있는지 확인합니다. 따라서 데이터베이스 백업을 복원할 수 있도록 이전 버전의 TDE 보호기를 모두 키 자격 증명 모음에서 유지하는 것이 좋습니다.

중요

언제든지 서버에 둘 이상의 TDE 보호기를 설정할 수 없습니다. Azure Portal 창에서 "키를 기본 TDE 보호기로 설정"으로 표시된 키입니다. 그러나 여러 추가 키를 TDE 보호기로 표시하지 않고 서버에 연결할 수 있습니다. 해당 키는 DEK를 보호하는 데 사용되지 않지만, 백업 파일이 해당 지문을 사용한 키로 암호화된 경우 백업에서 복원하는 동안 해당 키를 사용할 수 있습니다.

백업 복원에 필요한 키를 대상 서버에서 더 이상 사용할 수 없는 경우 복원 시도 시 다음 오류 메시지가 반환됩니다. "대상 서버 <Servername>은(는) <타임스탬프 #1> 및 <타임스탬프 #2> 사이에 작성된 모든 AKV URI에 대한 액세스 권한이 없습니다. 모든 AKV URI를 복원한 후 작업을 다시 시도하세요."

이를 완화하려면 대상 서버에 대해 Get-AzSqlServerKeyVaultKey cmdlet을 실행하거나 대상 관리 인스턴스에 대해 Get-AzSqlInstanceKeyVaultKey를 실행하여 사용 가능한 키 목록을 반환하고 누락된 키를 식별합니다. 모든 백업을 복원할 수 있도록 하려면 복원 대상 서버에서 필요한 모든 키에 액세스할 수 있는지 확인합니다. 해당 키는 TDE 보호기로 표시할 필요가 없습니다.

SQL Database의 백업 복구에 대한 자세한 내용은 SQL Database에서 데이터베이스 복구를 참조하세요. Azure Synapse Analytics의 전용 SQL 풀에 대한 백업 복구에 대한 자세한 내용은 전용 SQL 풀 복구를 참조하세요. SQL Managed Instance를 사용한 SQL Server의 기본 백업/복원은 빠른 시작: SQL Managed Instance로 데이터베이스 복원을 참조하세요.

로그 파일에 대한 또 다른 고려 사항: 백업된 로그 파일은 회전되었고 현재 데이터베이스가 새 TDE 보호기를 사용하더라도 원래 TDE 보호기로 암호화된 상태로 유지됩니다. 복원할 때 데이터베이스를 복원하려면 두 키가 모두 필요합니다. 로그 파일에서 이 Azure Key Vault에 저장된 TDE 보호기를 사용하는 동안 데이터베이스가 서비스 관리형 TDE를 사용하도록 변경된 경우에도 복원할 때 이 키가 필요합니다.

고객 관리형 TDE의 고가용성

서버의 구성된 지역 복제가 없는 경우에도 동일한 키 자료를 사용하여 서로 다른 두 지역에서 서로 다른 두 개의 키 자격 증명 모음을 사용하도록 서버를 구성하는 것이 좋습니다. 다른 지역의 보조 키 자격 증명 모음에 있는 키는 TDE 보호기로 표시되지 않아야 하며 허용되지도 않습니다. 기본 키 자격 증명 모음에 영향을 주는 중단이 발생하는 경우에만 시스템은 보조 키 자격 증명 모음에 있는 동일한 지문이 있는 다른 연결된 키로 자동으로 전환됩니다(있는 경우). 단, 해지된 액세스 권한으로 인해 또는 키나 키 자격 증명 모음이 삭제되어 TDE 보호기에 액세스할 수 없는 경우에는 전환이 발생하지 않습니다. 이는 고객이 의도적으로 서버가 키에 액세스하지 못하도록 제한하는 경우를 나타낼 수 있습니다. 다른 지역에 있는 두 개의 키 자격 증명 모음에 동일한 키 자료를 제공하려면 키 자격 증명 모음 외부에 키를 생성하고 두 키 자격 증명 모음으로 가져오는 방식으로 수행할 수 있습니다.

또는 한 지역의 기본 키 자격 증명 모음을 사용하여 키를 생성하고 다른 Azure 지역의 키 자격 증명 모음에 키를 복제하는 방법도 있습니다. Backup-AzKeyVaultKey cmdlet을 사용하여 기본 키 자격 증명 모음에서 암호화된 형식의 키를 검색한 다음, Restore-AzKeyVaultKey cmdlet을 사용하고 두 번째 지역의 키 자격 증명 모음을 지정하여 키를 복제합니다. 또는 Azure Portal을 사용하여 키를 백업하고 복원합니다. 키 백업/복원 작업은 동일한 Azure 구독 및 Azure 지리적 위치 내의 주요 자격 증명 모음 간에만 허용됩니다.

Geo-DR 및 고객 관리형 TDE

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

설정 또는 지역 복제 중에 불완전한 키 자료로 인한 문제가 발생하지 않게 하려면 고객 관리형 TDE를 구성할 때 다음 규칙을 따라야 합니다(주 서버 및 보조 서버에 별도의 키 자격 증명 모음을 사용하는 경우).

• 관련된 모든 키 자격 증명 모음에는 해당 서버의 동일한 속성 및 동일한 액세스 권한이 있어야 합니다.

• 관련된 모든 키 자격 증명 모음은 동일한 키 자료를 포함해야 합니다. 현재 TDE 보호기뿐만 아니라 백업 파일에 사용될 수 있는 모든 이전 TDE 보호기에 적용됩니다.

• TDE 보호기의 초기 설정 및 회전은 둘 다 보조 데이터베이스에서 수행한 후 주 데이터베이스에서 수행해야 합니다.

장애 조치(failover)를 테스트하려면 활성 지역 복제 개요의 단계를 따릅니다. SQL Database가 두 주요 자격 증명 모음에 대한 액세스 권한을 유지했는지 확인하기 위해 장애 조치(failover) 테스트를 정기적으로 수행해야 합니다.

이제 한 지역의 Azure SQL Database 서버 및 SQL Managed Instance를 다른 지역의 Key Vault에 연결할 수 있습니다. 서버와 키 자격 증명 모음은 같은 지역에 함께 위치할 필요가 없습니다. 따라서 단순성을 위해 주 서버와 보조 서버를 동일한 키 자격 증명 모음(모든 지역)에 연결할 수 있습니다. 이렇게 하면 두 서버에 별도의 키 자격 증명 모음이 사용되는 경우 키 관련 자료가 동기화되지 않을 수 있는 시나리오를 방지하는 데 도움이 됩니다. Azure Key Vault에는 서비스 또는 지역 오류가 발생한 경우에도 키와 주요 자격 증명 모음을 계속 사용할 수 있도록 여러 계층이 중복되어 있습니다. Azure Key Vault 가용성 및 중복성

고객 관리형 TDE에 대한 Azure Policy

Azure SQL Database 서버 또는 Azure SQL Managed Instance를 만들거나 업데이트하는 동안 Azure Policy를 사용하여 고객 관리형 TDE를 적용할 수 있습니다. 이 정책을 적용하면 고격 관리형 키를 사용하여 구성되지 않은 Azure의 논리 서버 또는 관리되는 인스턴스를 만들거나 업데이트하려는 모든 시도가 실패합니다. Azure Policy는 전체 Azure 구독 또는 리소스 그룹 내에서만 적용할 수 있습니다.

Azure Policy에 대한 자세한 내용은 Azure Policy란? 및 Azure Policy 정의 구조를 참조하세요.

Azure Policy의 고객 관리형 TDE에는 다음 두 가지 기본 제공 정책이 지원됩니다.

• SQL 서버는 고객 관리형 키를 사용하여 미사용 데이터를 암호화해야 함
• 관리되는 인스턴스는 고객 관리형 키를 사용하여 미사용 데이터를 암호화해야 합니다.

고객 관리형 TDE 정책은 Azure Portal로 이동한 후 Policy 서비스를 검색하여 관리할 수 있습니다. 정의에서 고객 관리형 키를 검색합니다.

이러한 정책에는 세 가지 효과가 있습니다.

• 감사 - 기본 설정으로 Azure Policy 활동 로그에서 감사 보고서만 캡처합니다.
• Deny - 고객 관리형 키를 구성하지 않으면 논리 서버 또는 관리되는 인스턴스를 만들거나 업데이트하지 못하게 제한합니다.
• 사용 안 함 - 정책을 사용하지 않으며, 사용자가 고객 관리형 TDE를 사용하도록 설정하지 않으면 논리 서버 또는 관리되는 인스턴스를 만들거나 업데이트하지 못하게 제한하지 않습니다.

고객 관리형 TDE에 대한 Azure Policy가 거부로 설정되면 Azure SQL 논리 서버 또는 관리되는 인스턴스 만들기가 실패합니다. 이 오류의 세부 정보는 리소스 그룹의 활동 로그에 기록됩니다.

중요

AuditIfNotExist 효과를 포함하는 고객 관리형 TDE에 대한 기본 제공 정책의 이전 버전은 더 이상 사용되지 않습니다. 더 이상 사용되지 않는 정책을 사용하는 기존 정책 할당은 영향을 주지 않으며 계속 이전처럼 작동합니다.

다음 단계

고객 관리형 TDE를 사용하여 일반적인 작업에 대해 다음 PowerShell 샘플 스크립트를 확인할 수도 있습니다.

• SQL Database의 투명한 데이터 암호화 보호기 회전

• SQL Database의 TDE(투명한 데이터 암호화) 보호기 제거

• SQL Managed Instance에서 PowerShell을 사용하여 자체 키로 투명한 데이터 암호화 관리

또한 잠재적인 데이터베이스 취약성을 검색 및 완화하고 데이터베이스에 대한 위협을 나타낼 수 있는 비정상적인 활동을 감지하는 기능이 포함된 SQL용 Microsoft Defender를 사용하여 데이터베이스와 데이터를 보호하세요.