적용 대상:Azure SQL 데이터베이스
Azure SQL Managed Instance
Azure Synapse Analytics(전용 SQL 풀만 해당)
CMK(고객 관리형 키)를 사용하는 Azure SQL의 TDE(투명한 데이터 암호화)를 사용하면 미사용 데이터 보호를 위한 BYOK(Bring Your Own Key) 시나리오를 사용할 수 있으며, 조직은 키 및 데이터 관리에서 업무 분리를 구현할 수 있습니다. 고객은 고객 관리형 TDE를 사용하여 키 수명 주기 관리(키 생성, 업로드, 회전, 삭제), 키 사용 권한 및 키에 대한 작업 감사를 완전히 제어할 책임이 있습니다.
이 시나리오에서는 DEK(데이터베이스 암호화 키)를 보호하는 데 사용되는 고객 관리 비대칭 키인 TDE(투명한 데이터 암호화) 보호기가 Azure Key Vault 또는 Azure Key Vault 관리형 HSM에 저장됩니다. 이러한 서비스는 고가용성 및 확장성을 위해 설계된 안전한 클라우드 기반 키 관리 서비스입니다. Azure Key Vault는 RSA 키를 지원하며 FIPS 140-2 수준 2 유효성이 검사된 HSM에서 백업할 수 있습니다. 더 높은 보증이 필요한 고객을 위해 Azure Key Vault 관리형 HSM은 FIPS 140-2 수준 3 유효성이 검사된 하드웨어를 제공합니다. 키는 서비스에서 생성되거나, 온-프레미스 HSM에서 가져오거나 안전하게 전송할 수 있습니다. 키에 대한 직접 액세스가 제한됩니다. 권한 있는 서비스는 키 자료를 노출하지 않고 암호화 작업을 수행합니다.
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 암호화를 참조하세요.
비고
Microsoft Entra ID는 이전에 Azure Active Directory(Azure AD)로 알려졌습니다.
고객 관리형 TDE의 이점
비고
이 문서에서는 CMK(고객 관리형 키) 및 BYOK(Bring Your Own Key)라는 용어가 서로 바꿔서 사용되지만 몇 가지 차이점을 나타냅니다.
- CMK(고객 관리형 키) - 고객은 키 생성, 회전 및 삭제를 비롯한 키 수명 주기를 관리합니다. 키는 Azure Key Vault 또는 Azure Managed HSM 에 저장되며 Azure SQL, Azure VM의 SQL Server 및 SQL Server 온-프레미스에서 DEK(데이터베이스 암호화 키) 암호화에 사용됩니다.
- BYOK(Bring Your Own Key) - 고객은 온-프레미스 HSM(하드웨어 보안 모듈)에서 Azure Key Vault 또는 Azure Managed HSM으로 자신의 키를 안전하게 가져오거나 가져옵니다. 이러한 가져온 키는 DEK 암호화를 위한 고객 관리형 키를 포함하여 Azure Key Vault의 다른 키로 사용될 수 있습니다. 자세한 내용은 HSM으로 보호된 키를 관리형 HSM으로 가져오기(BYOK)를 참조하세요.
고객 관리형 TDE는 고객에게 다음과 같은 이점을 제공합니다.
TDE 보호기의 사용 및 관리에 대한 전체 및 세분화된 제어
TDE 보호기 사용의 투명도입니다.
조직 내의 키 및 데이터 관리에서 업무 분리를 구현하는 기능.
Azure Key Vault 관리자는 암호화된 데이터베이스에 액세스할 수 없도록 키 액세스 권한을 취소할 수 있습니다.
Azure Key Vault에서 키의 중앙 관리.
Azure Key Vault는 Microsoft에서 암호화 키를 보거나 추출할 수 없도록 설계되었으므로 최종 고객의 신뢰도를 높입니다.
중요합니다
고객 관리형 TDE 사용을 시작하려는 서비스 관리형 TDE를 사용하는 사용자의 경우 전환 프로세스 중에 데이터가 암호화된 상태로 유지되며 데이터베이스 파일의 가동 중지 시간이나 다시 암호화는 없습니다. 서비스 관리형 키에서 고객 관리형 키로 전환하려면 빠른 온라인 작업인 DEK를 다시 암호화해야 합니다.
고객 관리형 TDE를 구성할 수 있는 권한
사용하려는 Azure Key Vault 유형을 선택합니다.
Azure의 논리 서버가 DEK 암호화를 위해 Azure Key Vault에 저장된 TDE 보호기를 사용하려면 Key Vault 관리자가 고유한 Microsoft Entra ID를 사용하여 서버에 대한 액세스 권한을 부여해야 합니다. 서버 ID는 시스템 할당 관리 ID 또는 서버에 할당된 사용자 할당 관리 ID일 수 있습니다. 키 자격 증명 모음에 대한 액세스 권한을 서버에 부여하는 두 가지 액세스 모델이 있습니다.
Azure RBAC(역할 기반 액세스 제어) - Azure RBAC를 사용하여 키 자격 증명 모음에 대한 사용자, 그룹 또는 애플리케이션 액세스 권한을 부여합니다. 이 메서드는 유연성과 세분성을 위해 권장됩니다. 키 보관소 암호화 서비스 사용자 역할은 암호화 및 암호 해독 작업에 키를 사용할 수 있도록 서버의 ID에 필요합니다.
보관소 액세스 정책 - 키 보관소 액세스 정책을 사용하여 키 보관소에 대한 서버 액세스 권한을 부여합니다. 이 메서드는 더 간단하고 간단하지만 덜 유연합니다. 서버 ID에는 키 자격 증명 모음에 대한 다음 권한이 있어야 합니다.
- get - Azure Key Vault에서 키의 공개 부분 및 속성을 검색하기 위한 것입니다.
- wrapKey - DEK를 보호(암호화)할 수 있습니다.
- unwrapKey - DEK를 보호 해제(암호 해독)할 수 있도록 합니다.
키 자격 증명 모음의 액세스 구성 Azure 포털 메뉴에서 Azure 역할 기반 액세스 제어 또는 자격 증명 모음 액세스 정책을 선택할 수 있습니다. TDE에 대한 Azure Key Vault 액세스 구성 설정에 대한 단계별 지침은 Azure Key Vault를 사용하여 SQL Server TDE 확장 가능 키 관리 설정을 참조하세요. 액세스 모델에 대한 자세한 내용은 Azure Key Vault 보안을 참조하세요.
Key Vault 관리자는 나중에 조사할 수 있도록 키 자격 증명 금고 감사 이벤트 로깅을 사용하도록 설정할 수도 있습니다.
서버가 Azure Key Vault에서 TDE 보호기를 사용하도록 구성된 경우 서버는 암호화를 위해 각 TDE 사용 데이터베이스의 DEK를 키 자격 증명 모음으로 보냅니다. Key Vault는 암호화된 DEK를 반환한 다음 사용자 데이터베이스에 저장합니다.
필요한 경우 서버는 암호 해독을 위해 보호된 DEK를 키 자격 증명 모음으로 보냅니다.
로깅을 사용하는 경우 감사자가 Azure Monitor를 사용하여 Key Vault AuditEvent 로그를 검토할 수 있습니다.
비고
키 보관소의 사용 권한 변경 사항이 적용되기까지 약 10분이 걸릴 수 있습니다. 여기에는 AKV의 TDE 보호기 액세스 권한 취소가 포함되며, 이 시간 프레임 내의 사용자에게는 여전히 액세스 권한이 있을 수 있습니다.
고객 관리형 TDE를 구성하기 위한 요구 사항
Azure Key Vault에서 일시 삭제 및 제거 보호 기능을 사용하도록 설정해야 합니다. 실수나 악의적인 키 자격 증명 모음 및 키 삭제로 인해 데이터베이스가 액세스할 수 없는 상태가 되는 것을 방지하는 데 도움이 됩니다. 기존 서버에서 또는 서버를 만드는 동안 TDE 보호기를 구성할 때 Azure SQL은 사용 중인 키 자격 증명 모음에 일시 삭제 및 제거 보호가 켜져 있는지 확인합니다. 키 볼트에서 일시 삭제 및 제거 보호가 사용되지 않으면 TDE 보호기 설정이 오류로 실패합니다. 이 경우, 먼저 키 자격 증명 보관소에서 일시 삭제 및 제거 보호를 사용하도록 설정한 다음, TDE 보호기 설정을 수행해야 합니다.
Azure Key Vault에서 방화벽을 사용하는 경우 Azure Key Vault에 프라이빗 엔드포인트를 사용하지 않는 한 신뢰할 수 있는 Microsoft 서비스가 방화벽을 바이패스하도록 허용하는 옵션을 사용하도록 설정해야 합니다. 자세한 내용은 Azure Key Vault 방화벽 및 가상 네트워크 구성을 참조하세요.
TDE 보호기를 구성하기 위한 요구 사항
TDE 보호기는 비대칭, RSA 또는 RSA HSM 키여야 합니다. 지원되는 키 길이는 2,048비트 및 3,072비트입니다.
키 활성화 날짜(설정된 경우)는 과거의 날짜와 시간이어야 합니다. 만료 날짜(설정된 경우)는 이후 날짜 및 시간이어야 합니다.
키가 사용 상태여야 합니다.
기존 키를 키 자격 증명 모음으로 가져오는 경우 지원되는 파일 형식 중 하나(예:
.pfx
.byok
또는.backup
)로 제공되는지 확인합니다. HSM 보호 키를 Azure Managed HSM으로 가져오려면 HSM 보호 키를 BYOK(관리형 HSM)로 가져오기를 참조하세요.
비고
v2.8.0 이전의 Thales CipherTrust Manager 버전과 관련된 문제로 인해 Azure Key Vault로 새로 가져온 키가 고객 관리형 TDE 시나리오에 Azure SQL Database 또는 Azure SQL Managed Instance와 함께 사용되지 않습니다. 이 문제에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 이러한 경우 Azure Key Vault로 키를 가져온 후 24시간 동안 기다렸다가 서버 또는 관리되는 인스턴스에 대한 TDE 보호기로 사용하기 시작합니다. 이 문제는 Thales CipherTrust Manager v2.8.0에서 해결되었습니다.
고객 관리형 TDE를 구성할 때 권장 사항
단일 구독 당 총 500개의 범용 데이터베이스 또는 200개의 중요 비즈니스용 데이터베이스를 키 자격 증명 모음에 연결하여, 서버가 키 자격 증명 모음의 TDE 보호기에 액세스할 때 고가용성을 보장합니다. 이러한 수치는 환경을 기반으로 하며 Azure Key Vault 서비스 제한에 설명되어 있습니다. 서버 장애 조치 후 발생할 수 있는 문제를 방지하고자 합니다. 이는 서버 내 각 데이터베이스에 대해 자격 모음에 다수의 주요 작업이 트리거되기 때문입니다.
이 중요한 리소스를 삭제할 수 있는 사용자를 제어하고 실수로 또는 무단 삭제를 방지하려면 키 자격 증명 모음에 리소스 잠금을 설정합니다. 리소스 잠금에 대해 자세히 알아봅니다.
모든 암호화 키에 대한 감사 및 보고 사용: Azure Key Vault는 다른 보안 정보 및 이벤트 관리 도구에 쉽게 삽입할 수 있는 로그를 제공합니다. Operations Management Suite Log Analytics 는 이미 통합된 서비스의 한 예입니다.
최대 가용성을 위해 콘텐츠를 페어링된 지역으로 복제할 수 있는 Azure 지역의 키 보관소를 사용합니다. 자세한 내용은 Azure Key Vault 사용 모범 사례 , Azure Key Vault 및 Azure Key Vault 가용성 및 중복성 을 참조하세요.
비고
고객 관리형 TDE를 보다 유연하게 구성할 수 있도록 한 지역의 Azure SQL Database 및 Azure SQL Managed Instance를 다른 지역의 Azure Key Vault에 연결할 수 있습니다. 서버와 키 보관소는 같은 지역에 있지 않아도 됩니다.
TDE 보호기를 구성할 때 권장 사항
TDE 보호기의 복사본을 안전한 장소에 보관하거나 에스크로 서비스에 에스크로합니다.
키가 키 자격 증명 모음에 생성된 경우 Azure Key Vault에서 키를 처음으로 사용하기 전에 키 백업을 만듭니다. 백업은 Azure Key Vault로만 복원할 수 있습니다. Backup-AzKeyVaultKey 명령에 대해 자세히 알아봅니다. Azure Managed HSM은 모든 키, 버전, 특성, 태그 및 역할 할당을 포함하여 HSM의 전체 콘텐츠에 대한 전체 백업을 만들 수 있습니다. 자세한 내용은 전체 백업 및 복원 및 선택적 키 복원을 참조하세요.
키(예: 키 특성, 태그, ACL)를 변경할 때마다 새 백업을 만듭니다.
키를 회전할 때 키 자격 증명 모음 또는 관리형 HSM에 이전 버전의 키를 유지하므로 이전 데이터베이스 백업을 복원할 수 있습니다. 데이터베이스에 대해 TDE 보호기가 변경되면 데이터베이스의 이전 백업이 최신 TDE 보호기를 사용하도록 업데이트되지 않습니다 . 복원 시 각 백업에는 만들 때 암호화한 TDE 보호기가 필요합니다. PowerShell을 사용하여 투명한 데이터 암호화 보호기 회전의 지침에 따라 키 회전을 수행할 수 있습니다.
서비스 관리형 키로 전환한 후에도 Azure Key Vault 또는 Azure Managed HSM에서 이전에 사용한 모든 키를 유지합니다. Azure Key Vault 또는 Azure Managed HSM에 저장된 TDE 보호기를 사용하여 데이터베이스 백업을 복원할 수 있습니다. Azure Key Vault 또는 Azure Managed HSM을 사용하여 만든 TDE 보호기는 나머지 모든 저장된 백업이 서비스 관리형 키로 만들어질 때까지 유지 관리되어야 합니다. Backup-AzKeyVaultKey를 사용하여 이러한 키의 복구 가능한 백업 복사본을 만듭니다.
데이터 손실의 위험 없이 보안 인시던트 중에 잠재적으로 손상된 키를 제거하려면 잠재적으로 손상된 키 제거의 단계를 수행합니다.
TDE 보호기 회전
서버에 대한 TDE 보호기를 회전한다는 것은 서버의 데이터베이스를 보호하는 새 비대칭 키로 전환하는 것을 의미합니다. 키 회전은 온라인 작업이며 완료하는 데 몇 초밖에 걸리지 않습니다. 이 작업은 전체 데이터베이스가 아닌 데이터베이스 암호화 키만 해독하고 다시 암호화합니다.
TDE 보호기의 회전은 수동으로 또는 자동화된 회전 기능을 사용하여 수행할 수 있습니다.
서버에 대한 TDE 보호기를 구성할 때 TDE 보호기의 자동화된 회전을 사용하도록 설정할 수 있습니다. 자동화된 회전은 기본적으로 사용하지 않도록 설정됩니다. 활성화되면 서버는 TDE 보호기로 사용되는 키의 새 버전에 대해 키 자격 증명 모음 또는 관리형 HSM을 계속 확인합니다. 새 버전의 키가 검색되면 서버 또는 데이터베이스의 TDE 보호기가 24시간 이내에 자동으로 최신 키 버전으로 회전됩니다.
Azure Key Vault에서 자동화된 키 회전 또는 Azure Managed HSM의 자동 회전과 함께 사용하는 경우 이 기능을 사용하면 Azure SQL Database 및 Azure SQL Managed Instance의 TDE 보호기에서 엔드투엔드 제로 터치 회전이 가능합니다.
비고
키의 수동 또는 자동화된 회전을 사용하여 CMK로 TDE를 설정하면 항상 지원되는 최신 버전의 키를 사용합니다. 설정에서는 이전 또는 하위 버전의 키를 사용할 수 없습니다. 항상 최신 키 버전을 사용하는 것은 손상될 수 있는 이전 키 버전을 허용하지 않는 Azure SQL 보안 정책을 준수합니다. 이전 버전의 키는 데이터베이스 백업 또는 복원을 위해 필요할 수 있으며, 특히 이전 키 버전을 보존해야 하는 장기 보존 백업에 필요할 수 있습니다. 지역에서 복제 설정의 경우 원본 서버에 필요한 모든 키가 대상 서버에 있어야 합니다.
TDE 보호기의 자동화된 회전을 구성할 때 지역 복제 고려 사항
설정 중 또는 지역에서 복제하는 동안 발생하는 문제를 방지하려면 주 또는 보조 서버에서 TDE 보호기의 자동 회전을 사용하는 경우 지역 복제를 구성할 때 다음 규칙을 따르는 것이 중요합니다.
주 서버와 보조 서버 모두 주 서버의 키 자격 증명 모음(주 서버의 TDE 보호기 키를 보유하는 키 자격 증명 모음)에 대한 Get, wrapKey 및 unwrapKey 권한이 있어야 합니다.
자동 키 회전이 사용하도록 설정된 서버의 경우 지역에서 복제를 시작하기 전에 주 서버에서 TDE 보호기로 사용되는 암호화 키를 보조 서버에 추가합니다. 보조 서버는 주 서버와 동일한 키 자격 증명 모음 또는 관리되는 HSM에 있는 키에 대한 액세스를 필요로 합니다 (키 자료가 동일한 다른 키가 아닌). 또는 지역에서 복제를 시작하기 전에 보조 서버의 관리 ID (사용자 할당 또는 시스템 할당)에 주 서버의 키 자격 증명 모음 또는 관리형 HSM에 대한 필요한 권한이 있는지 확인하고 시스템에서 보조 서버에 키를 추가하려고 시도합니다.
기존 지역 복제 설정의 경우 주 서버에서 자동 키 회전을 사용하도록 설정하기 전에 주 서버에서 TDE 보호기로 사용되는 암호화 키를 보조 서버에 추가합니다. 보조 서버는 주 서버와 동일한 키 자격 증명 모음 또는 관리되는 HSM에서 사용되는 키에 대한 액세스 권한이 필요하며, 동일한 키 자료를 가진 다른 키가 아닙니다. 또는 자동화된 키를 사용하도록 설정하기 전에 보조 서버의 관리 ID (사용자 할당 또는 시스템 할당)에 주 서버의 키 자격 증명 모음에 필요한 권한이 있는지 확인하고 시스템에서 보조 서버에 키를 추가하려고 시도합니다.
TDE용 CMK(고객 관리형 키)를 사용하는 지역에서 복제 시나리오가 지원됩니다. Azure Portal에서 TDE를 구성하는 경우 모든 서버에서 자동 키 회전을 사용하는 TDE를 구성해야 합니다. TDE를 사용하여 지역에서 복제 구성에 대한 자동 키 회전을 설정하는 방법에 대한 자세한 내용은 지역 복제 구성에 대한 자동 키 회전을 참조하세요.
액세스할 수 없는 TDE 보호기
TDE가 고객 관리형 키를 사용하도록 구성된 경우 데이터베이스를 온라인 상태로 유지하려면 TDE 보호기에 지속적인 액세스 권한이 필요합니다. 서버가 Azure Key Vault 또는 Azure Managed HSM에서 고객 관리형 TDE 보호기 액세스 권한을 잃으면 최대 10분 안에 데이터베이스가 해당 오류 메시지와 함께 모든 연결을 거부하고 해당 상태를 액세스할 수 없음으로 변경합니다. 액세스할 수 없는 상태의 데이터베이스에서 허용되는 유일한 작업은 삭제하는 것입니다.
액세스할 수 없는 상태
간헐적인 네트워킹 중단(예: 5XX 오류)으로 인해 데이터베이스에 액세스할 수 없는 경우 데이터베이스가 자동으로 다시 온라인 상태가 되므로 아무 작업도 필요하지 않습니다. Azure Key Vault 또는 Azure Managed HSM에서 TDE 보호기 액세스 시 네트워크 오류 또는 중단의 영향을 줄이기 위해 서비스에서 데이터베이스를 액세스할 수 없는 상태로 이동하기 전에 24시간 버퍼가 도입되었습니다. 액세스할 수 없는 상태에 도달하기 전에 장애 조치(failover)가 발생하면 암호화 캐시 손실로 인해 데이터베이스를 사용할 수 없게 됩니다.
Azure Key Vault 오류(예: 4XX 오류)로 인해 서버가 Azure Key Vault 또는 Azure Managed HSM에서 고객 관리형 TDE 보호기 액세스 권한을 잃게 되면 30분 후에 데이터베이스가 액세스할 수 없는 상태로 이동됩니다.
Azure Key Vault 또는 Azure Managed HSM 오류 후 데이터베이스 액세스 복원
키에 대한 액세스가 복원되면 데이터베이스를 다시 온라인으로 가져오려면 추가 시간과 단계가 필요하며, 이는 키가 사용할 수 없는 기간과 데이터베이스 내의 데이터 크기에 따라 달라질 수 있습니다.
키 액세스가 30분 이내에 복원되면 데이터베이스는 이후 1시간 내에 자동으로 복구됩니다. 그러나 키 액세스가 30분 이상 후에 복원되면 데이터베이스의 자동 복구가 불가능합니다. 이러한 경우 데이터베이스 복원에는 Azure Portal을 통한 추가 절차가 포함되며 데이터베이스 크기에 따라 시간이 오래 걸릴 수 있습니다.
데이터베이스가 다시 온라인 상태가 되면 장애 조치(failover) 그룹 구성, 태그 및 탄력적 풀 구성, 읽기 확장, 자동 일시 중지, 지정 시간 복원 기록, 장기 보존 정책 등과 같은 데이터베이스 수준 설정을 포함하여 이전에 구성된 서버 수준 설정이 손실됩니다. 따라서 고객은 30분 이내에 암호화 키 액세스의 손실을 감지하는 알림 시스템을 구현하는 것이 좋습니다. 30분 기간이 만료된 후 복구된 데이터베이스의 모든 서버 및 데이터베이스 수준 설정의 유효성을 검사하는 것이 좋습니다.
다음은 액세스할 수 없는 데이터베이스를 다시 온라인 상태로 만들기 위해 포털에 필요한 추가 단계를 보여줍니다.
실수로 인한 TDE 보호기 액세스 해지
키 자격 증명 모음 또는 관리형 HSM에 대해 충분한 액세스 권한이 있는 사용자가 실수로 서버에서 키에 대한 액세스를 비활성화할 수 있습니다.
서버에서 키 자격 증명 모음 또는 관리형 HSM의 get, wrapKey, unwrapKey 권한을 취소하기
키 삭제
키 볼트 또는 관리형 HSM 삭제
키 자격 증명 모음 또는 관리형 HSM 방화벽 규칙 변경
Microsoft Entra ID에서 서버의 관리 ID 삭제
데이터베이스에 액세스할 수 없게 되는 일반적인 원인에 대해 자세히 알아봅니다.
SQL Managed Instance와 Azure Key Vault 또는 Azure Managed HSM 간의 연결 차단
SQL Managed Instance와 키 자격 증명 모음 또는 관리형 HSM 간의 네트워크 연결 블록은 주로 키 자격 증명 모음 또는 관리형 HSM 리소스가 존재하지만 관리되는 인스턴스에서 엔드포인트에 연결할 수 없는 경우에 발생합니다. 키 자격 증명 모음 또는 관리형 HSM 엔드포인트에 연결할 수 있지만 연결이 거부되고 사용 권한이 누락되는 모든 시나리오에서는 데이터베이스의 상태가 액세스할 수 없음으로 변경됩니다.
Azure Key Vault 또는 Azure Managed HSM에 대한 네트워킹 연결이 부족한 가장 일반적인 원인은 다음과 같습니다.
- Azure Key Vault 또는 Azure Managed HSM은 프라이빗 엔드포인트를 통해 노출되며 Azure Key Vault 또는 Azure Managed HSM 서비스의 개인 IP 주소는 관리되는 인스턴스 서브넷과 연결된 NSG(네트워크 보안 그룹)의 아웃바운드 규칙에서 허용되지 않습니다.
- DNS 확인 오류는 키 자격 증명 모음 또는 관리형 HSM FQDN이 확인되지 않거나 잘못된 IP 주소로 확인될 때 발생합니다.
SQL Managed Instance에서 TDE 보호기를 호스팅하는 Azure Key Vault 또는 Azure Managed HSM으로의 연결을 테스트합니다.
- 엔드포인트는 자격 증명 모음 FQDN으로, <vault_name>.vault.azure.net(예를 들어, https:// 없이)와 같습니다.
- 테스트할 포트는 443입니다.
- RemoteAddress에 대한 결과가 존재하고 올바른 IP 주소여야 합니다.
- TCP 테스트의 결과는 TcpTestSucceeded: True여야 합니다.
테스트가 TcpTestSucceeded: False를 반환하는 경우 네트워킹 구성을 검토합니다.
- 확인된 IP 주소가 유효한지 검토합니다. 누락된 값은 DNS 확인에 문제가 있음을 의미합니다.
- 관리되는 인스턴스의 네트워크 보안 그룹에 포트 443에서 해결된 IP 주소를 포함하는 아웃바운드 규칙이 있는지 확인합니다. 특히, 해결된 주소가 키 자격 증명 모음 또는 관리형 HSM 프라이빗 엔드포인트에 속하는 경우에는 이러한 규칙이 적용되어야 합니다.
- 경로 테이블, 가상 어플라이언스 및 해당 구성과 같은 다른 네트워킹 구성을 확인합니다.
고객 관리형 TDE 모니터링
데이터베이스 상태를 모니터링하고 TDE 보호기 액세스 손실에 대한 경고를 사용하도록 설정하려면 다음 Azure 기능을 구성합니다.
- Azure Resource Health. TDE 보호기 액세스 권한이 손실된 액세스할 수 없는 데이터베이스는 데이터베이스에 대한 첫 번째 연결이 거부된 후 "사용할 수 없음"으로 표시됩니다.
- 고객 관리형 키 자격 증명 모음의 TDE 보호기 액세스가 실패하면 활동 로그에 항목이 추가됩니다. 이러한 이벤트에 대한 경고를 만들면 가능한 한 빨리 액세스를 복원할 수 있습니다.
- 작업 그룹은 기본 설정(예: 이메일/SMS/푸시/음성, 논리 앱, 웹후크, ITSM 또는 Automation Runbook)에 따라 알림 및 경고를 보내도록 정의할 수 있습니다.
데이터베이스 backup
및 restore
, 고객 관리형 TDE 사용
데이터베이스가 Azure Key Vault 또는 Azure Managed HSM의 키를 사용하여 TDE로 암호화되면 새로 생성된 백업도 동일한 TDE 보호기로 암호화됩니다. TDE 보호기가 변경되면 데이터베이스의 이전 백업이 최신 TDE 보호기를 사용하도록 업데이트되지 않습니다 .
Azure Key Vault 또는 Azure Managed HSM에서 TDE 보호기로 암호화된 백업을 복원하려면 대상 서버에서 키 자료를 사용할 수 있는지 확인합니다. 따라서 데이터베이스 백업을 복원할 수 있도록 모든 이전 버전의 TDE 보호기를 키 자격 증명 모음 또는 관리형 HSM에 유지하는 것이 좋습니다.
중요합니다
서버에 대해 TDE 보호기를 두 개 이상 설정할 수 없습니다. Azure portal 창에서 키를 기본 TDE 보호기로 설정하는 것으로 표시된 키가 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 또는 Azure Managed HSM에 저장된 TDE 보호기를 사용하는 경우 데이터베이스가 서비스 관리형 TDE를 사용하도록 변경된 경우에도 복원 시 이 키가 필요합니다.
고객 관리형 TDE를 사용하여 고가용성
Azure Key Vault 또는 Azure Managed HSM이 여러 계층의 중복성을 제공하는 경우 고객 관리형 키를 사용하는 TDE는 Azure Key Vault 또는 Azure Managed HSM 가용성 및 복원력을 활용하고 Azure Key Vault 또는 Azure Managed HSM 중복 솔루션에 완전히 의존할 수 있습니다.
Azure Key Vault 여러 중복 계층은 개별 서비스 구성 요소가 실패하거나 Azure 지역 또는 가용성 영역이 다운된 경우에도 키 액세스를 보장합니다. 추가 정보는 Azure Key Vault의 가용성 및 중복성을 참조하세요.
Azure Key Vault는 사용자의 개입 없이 자동으로 제공되는 다음과 같은 가용성 및 복원력 구성 요소를 제공합니다.
비고
모든 쌍 지역의 경우 Azure Key Vault 키는 두 지역에 복제되며 두 지역에는 해당 키에서 작동할 수 있는 HSM(하드웨어 보안 모듈)이 있습니다. 자세한 내용은 데이터 복제를 참조하세요. 이는 표준 및 프리미엄 Azure Key Vault 서비스 계층과 소프트웨어 또는 하드웨어 키 모두에 적용됩니다.
Azure Managed HSM 다중 지역 복제를 사용하면 Azure 관리형 HSM 풀을 한 Azure 지역(주 지역이라고 함)에서 다른 Azure 지역(확장 지역이라고 함)으로 확장할 수 있습니다. 구성되면 두 지역이 모두 활성 상태이고 요청을 처리할 수 있으며 자동화된 복제를 통해 동일한 키 자료, 역할, 권한을 공유합니다. 자세한 내용은 Azure Managed HSM에서 다중 지역 복제 사용을 참조하세요.
Geo-DR 및 고객 관리형 TDE
활성 지역 복제 및 장애 조치(failover) 그룹 시나리오 모두에서 관련된 주 서버와 보조 서버는 모든 지역에 있는 Azure Key Vault 또는 Azure Managed HSM에 연결할 수 있습니다. 서버 및 키 자격 증명 모음 또는 관리형 HSM은 동일한 지역에 배치할 필요가 없습니다. 이를 통해 단순화를 위해 기본 및 보조 서버를 동일한 키 자격 증명 모음 또는 관리형 HSM(어느 지역에서든)에 연결할 수 있습니다. 이렇게 하면 두 서버 모두에 별도의 키 자격 증명 모음 또는 관리형 HSM을 사용하는 경우 키 자료가 동기화되지 않을 수 있는 시나리오를 방지할 수 있습니다.
Azure Key Vault 및 Azure Managed HSM에는 서비스 또는 지역 오류 발생 시 키 및 키 자격 증명 모음을 계속 사용할 수 있도록 여러 계층의 중복성이 있습니다. 중복성은 쌍을 이루는 영역뿐만 아니라 쌍을 이루지 않는 영역에서도 지원됩니다. 추가 정보는 Azure Key Vault의 가용성 및 중복성을 참조하세요.
고객의 요구 사항에 따라 TDE 보호기 키를 저장하는 몇 가지 옵션이 있습니다.
Azure Key Vault와 기본 지역 쌍 복원력 또는 비쌍 지역 복원력을 활용합니다.
여러 지역에 걸쳐 각각의 별도 Azure Key Vault에서 고객 HSM을 활용하여 Azure Key Vault에 키를 로드합니다.
Azure Managed HSM 및 지역 간 복제 옵션을 활용합니다.
- 이 옵션을 사용하면 고객이 키를 복제할 원하는 지역을 선택할 수 있습니다.
다음 다이어그램은 장애 조치 그룹을 사용하여 Azure SQL의 지역 복제를 위해 설정된 Azure Key Vault의 교차 장애 조치 시 기본 및 보조 지역의 구성 방법을 나타냅니다.
쌍을 이루는 지역에 대한 Azure Key Vault 지역 간 장애 조치(failover) 지원을 보여 주는
Geo-DR 대한 Azure Key Vault 설명
Azure SQL의 주 서버와 보조 서버는 모두 주 지역의 Azure Key Vault에 액세스합니다.
Azure Key Vault 장애 조치(failover)는 고객이 아닌 Azure Key Vault 서비스에 의해 시작됩니다.
Azure Key Vault가 보조 지역으로 장애 조치가 이루어지는 경우 Azure SQL의 서버는 여전히 동일한 Azure Key Vault에 액세스할 수 있습니다. 내부적으로 Azure Key Vault 연결은 보조 지역의 Azure Key Vault로 리디렉션됩니다.
새 키 만들기, 가져오기 및 키 회전은 주 복제본의 Azure Key Vault를 사용할 수 있는 동안에만 가능합니다.
페일오버가 발생하면, 쌍을 이루는 지역의 주 지역에 있는 Azure Key Vault에 다시 액세스할 수 있을 때까지 키 회전이 허용되지 않습니다.
고객은 보조 지역에 수동으로 연결할 수 없습니다.
기본 지역의 Azure Key Vault를 사용할 수 없는 동안, Azure Key Vault는 읽기 전용 상태입니다.
고객은 Azure Key Vault가 현재 있는 지역을 선택하거나 확인할 수 없습니다.
페어링되지 않은 지역의 경우, 두 Azure SQL 서버는 첫 번째 지역의 Azure Key Vault에 접근합니다 (그래프에 표시된 대로). Azure Key Vault는 영역 중복 스토리지를 사용하여 동일한 지역 내 독립 가용성 영역에 데이터가 복제되도록 합니다.
자세한 내용은 Azure Key Vault 가용성 및 중복성 , Azure 지역 쌍 및 비계층 지역 , Azure Key Vault 대한 서비스 수준 계약참조하세요.
Geo-DR 대한 Azure SQL 설명
Azure SQL MI 및 Azure SQL DB의 영역 중복 옵션을 사용하여 복원력을 높입니다. 자세한 내용은 Azure 가용성 영역이란?을 참조하세요..
보조 지역으로 재해 복구를 위해 Azure SQL MI 및 Azure SQL DB에 장애 조치(failover) 그룹을 사용합니다. 자세한 내용은 장애 조치(failover) 그룹 개요 & 모범 사례참조하세요.
데이터베이스가 활성 지역 복제 또는 장애 조치(failover) 그룹의 일부이고 액세스할 수 없게 되면 SQL 컨트롤 플레인은 링크를 끊고 데이터베이스를 독립 실행형 데이터베이스로 변환합니다. 키 권한을 수정한 후에는 주 데이터베이스를 다시 온라인 상태로 만들 수 있습니다. Azure SQL은 의도적으로 보조 데이터베이스에 대한 전체 백업을 수행하지 않으므로 보조 데이터베이스를 다시 온라인 상태로 만들 수 없습니다. 보조 데이터베이스를 삭제하고 링크를 다시 설정하는 것이 좋습니다.
프라이빗 엔드포인트가 Azure SQL에서 사용되는 경우 구성에 더 복잡한 DNS 영역이 필요할 수 있습니다(예: 동일한 DNS 영역에서 동일한 리소스에 두 개의 프라이빗 엔드포인트를 만들 수 없음).
애플리케이션이 재시도 논리를 활용하도록 합니다.
고객이 Azure Key Vault를 통해 Azure Managed HSM 솔루션을 선택하려는 몇 가지 시나리오가 있습니다.
수동 연결이 필요한 보조 금고.
오류가 발생하더라도 금고에 대한 읽기 액세스가 필요합니다.
키 자료가 복제되는 지역을 유연하게 선택할 수 있습니다.
- 두 번째 지역에서 두 번째 Azure Managed HSM 풀을 만드는 지역 간 복제를 사용하도록 설정해야 합니다.
Azure Managed HSM을 사용하면 원본이 손실되거나 사용할 수 없는 경우 고객이 HSM에 대한 정확한 복제본을 만들 수 있습니다.
보안 또는 규정 요구 사항에 Azure Managed HSM을 사용합니다.
전체 금고를 백업할 수 있는 기능과 개별 키를 백업할 수 있는 기능 비교.
자세한 내용은 Azure Managed HSM에서 다중 지역 복제 사용 및 관리형 HSM 재해 복구를 참조하세요.
고객 관리형 TDE에 대한 Azure Policy
Azure Policy를 사용하여 Azure SQL Database 서버 또는 Azure SQL Managed Instance를 만들거나 업데이트하는 동안 고객 관리형 TDE를 적용할 수 있습니다. 이 정책을 적용하면 고객 관리형 키로 구성되지 않은 경우 Azure 또는 관리형 인스턴스 에서 논리 서버를 만들거나 업데이트하려는 시도가 실패합니다. Azure Policy는 전체 Azure 구독 또는 리소스 그룹 내에서만 적용할 수 있습니다.
Azure Policy에 대한 자세한 내용은 Azure Policy란 무엇인가 및 Azure Policy 정의 구조를 참조하세요.
다음 두 가지 기본 제공 정책은 Azure Policy에서 고객 관리형 TDE에 대해 지원됩니다.
- SQL 서버는 고객 관리형 키를 사용하여 미사용 데이터를 암호화해야 함
- 관리되는 인스턴스는 고객 관리형 키를 사용하여 비활성 데이터를 암호화해야 합니다.
고객 관리형 TDE 정책은 Azure Portal로 이동하여 정책 서비스를 검색하여 관리할 수 있습니다. 정의에서 고객 관리형 키를 검색합니다.
이러한 정책에는 다음 세 가지 효과가 있습니다.
- 감사 - 기본 설정이며 Azure Policy 활동 로그에서만 감사 보고서를 캡처합니다.
- 거부 - 고객 관리형 키를 구성하지 않고 논리 서버 또는 관리형 인스턴스 만들기 또는 업데이트 방지
- 사용 안 함 - 정책을 사용하지 않도록 설정하고, 고객 관리형 TDE를 사용하지 않고 논리 서버 또는 관리형 인스턴스를 만들거나 업데이트하는 사용자를 제한하지 않습니다.
고객 관리형 TDE에 대한 Azure Policy가 거부로 설정된 경우 Azure SQL 논리 서버 또는 관리되는 인스턴스 만들기가 실패합니다. 이 실패의 세부 정보는 리소스 그룹의 활동 로그 에 기록됩니다.
중요합니다
효과를 포함하는 AuditIfNotExist
고객 관리형 TDE에 대한 이전 버전의 기본 제공 정책은 더 이상 사용되지 않습니다. 사용되지 않는 정책을 사용하는 기존 정책 할당은 영향을 받지 않으며 이전처럼 계속 작동합니다.