데이터 보호

완료됨

네트워크 및 ID 액세스를 구성하여 안전한 상태가 되었으면 미사용, 이동 중 또는 사용자와 관리자가 보고 있는지 여부와 무관하게 데이터를 보호할 방법을 고려해볼 수 있습니다.

데이터 암호화

암호화된 연결은 Azure SQL Database에 의해 강제 적용되며 필요한 인바운드 TLS(전송 계층 보안)의 최소 버전(1.0, 1.1 또는 1.2보다 높은 버전)을 추가로 지정할 수 있습니다. 서버 협상을 방지하기 위해 클라이언트에서 암호화를 강제로 적용하고 서버 인증서를 모범 사례로 신뢰하지 않는 것이 좋습니다.

투명한 데이터 암호화

TDE(투명한 데이터 암호화)는 미사용 데이터에 대한 암호화를 제공하며, 모든 새 Azure SQL Database의 데이터베이스에 대해 기본적으로 설정되어 있습니다. 다음과 같이 Azure Portal에서 스위치를 사용하여 모든 배포 옵션에 대해 TDE를 구성할 수 있습니다.

TDE가 Azure Portal에 설정되어 있는지 확인하는 것을 보여 주는 스크린샷

서버 수준에서 서비스 관리형 키를 사용하거나 고객 관리 키 옵션을 사용하여 BYOK(Bring Your Own Key)를 사용하도록 선택할 수도 있습니다. 기본값은 Azure 서비스에서 키를 관리하도록 하는 것입니다. Azure는 데이터베이스를 암호화하는 키를 자동으로 생성하고 키 회전을 관리합니다. Azure Portal을 사용하여 이 작업을 수행하는 방법을 알아보았습니다. 그러나 Azure PowerShell, Azure CLI, T-SQL(Transact-SQL) 또는 REST API를 사용할 수도 있습니다.

TDE 옵션 서버 보기의 스크린샷.

TDE를 사용한 고객 관리형 키

또는 BYOK를 사용하고 Azure Key Vault를 활용할 수 있습니다. 고객 관리형 키를 사용할 때의 이점은 다음과 같습니다.

  • TDE 보호기의 사용 및 관리를 완벽하게 세부적으로 제어
  • TDE 보호기 사용의 투명성
  • 조직 내 키 및 데이터 관리에서 업무 분리를 구현할 수 있음
  • Key Vault 관리자가 키 액세스 권한을 해지하여 암호화된 데이터베이스에 액세스할 수 없도록 설정할 수 있음
  • AKV의 키 중앙 관리
  • AKV는 Microsoft가 암호화 키를 보거나 추출할 수 없도록 디자인되었으므로 최종 고객의 신뢰가 향상됨

TDE에 대한 고객 관리형 키와 함께 UMI(사용자가 할당한 관리 ID)를 사용할 수도 있습니다.

  • 서버 또는 데이터베이스가 생성되기 전에 사용자 할당 관리 ID를 만들고 키 자격 증명 모음에 대한 액세스 권한을 부여하여 Azure SQL 논리 서버에 대한 키 자격 증명 모음 액세스 권한을 미리 부여할 수 있습니다.
  • TDE 및 CMK를 사용하도록 설정된 Azure SQL 논리 서버를 만들 수 있습니다.
  • 동일한 사용자 할당 관리 ID를 여러 서버에 할당할 수 있으므로 각 Azure SQL 논리 서버에 대해 시스템 할당 관리 ID를 개별적으로 설정하여 키 자격 증명 모음에 액세스 권한을 부여할 필요가 없습니다.
  • 사용 가능한 기본 제공 Azure 정책을 사용하여 서버 생성 시 CMK를 적용하는 기능을 제공합니다.

TDE를 사용하는 고객 관리형 키에 대해 자동 키 회전이 도입되었습니다. 사용하도록 설정하면 서버는 TDE 보호기로 사용되는 키의 새 버전에 대해 키 자격 증명 모음을 지속적으로 확인합니다. 새 버전의 키가 검색되면 서버의 TDE 보호기가 60분 이내에 자동으로 최신 키 버전으로 회전됩니다.

Always Encrypted

또한 SQL Server에서와 마찬가지로 Azure SQL에서 지원되는 열 수준 암호화를 활용할 수 있습니다. 이 프로세스에는 데이터베이스 시스템에 제공되지 않는 키를 사용하는 중요한 데이터의 클라이언트 측 암호화 사용이 포함됩니다. 추가로 클라이언트 드라이버는 쿼리 매개 변수를 투명하게 암호화하고 암호화된 결과의 암호를 해독합니다. 현재 결정적인 암호화를 통한 JOIN, GROUP BYDISTINCT 연산자를 포함하여 암호화된 데이터의 같음 비교가 지원됩니다.

보안 enclave를 사용한 Always Encrypted는 바로 암호화 및 보다 풍부한 기밀 쿼리를 사용하여 Always Encrypted의 기밀 컴퓨팅 기능을 확장합니다. 보안 Enclave를 사용하는 Always Encrypted 기능은 이제 Azure SQL Database에서 사용할 수 있지만 SQL Managed Instance에서는 아직 지원되지 않습니다.

동적 데이터 마스킹

경우에 따라 권한 없는 사용자가 볼 수 없도록 특정 데이터를 마스킹 또는 수정하는 것이 좋습니다. 그러나 해당 데이터를 포함하는 쿼리를 계속 수행할 수 있습니다. 이 기능은 SQL Server에서와 마찬가지로 지원됩니다. 그러나 Azure Portal에는 마스킹할 필드의 권장 사항을 볼 수 있는 추가 기능 및 보기가 있습니다.

Azure Portal에 있는 동적 데이터 마스킹 권장 사항을 보여 주는 스크린샷.

데이터에 이름과 메일 주소와 같은 중요한 정보가 포함된 예를 살펴보겠습니다. SQL Database 구성 창의 보안에서 동적 데이터 마스킹 메뉴를 선택하거나 다음 T-SQL 명령을 사용하여 Azure Portal에서 해당 열에 마스크를 적용할 수 있습니다.

ALTER TABLE Data.Membership ALTER COLUMN FirstName
ADD MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)')

ALTER TABLE Data.Membership ALTER COLUMN Email
ADD MASKED WITH (FUNCTION = 'email()')

ALTER TABLE Data.Membership ALTER COLUMN DiscountCode 
ADD MASKED WITH (FUNCTION = 'random(1, 100)')
 
GRANT UNMASK to DataOfficers

이전 명령에서, 함수를 통해 마스크를 적용하는 여러 방법이 있음을 알 수 있습니다.

예를 들어 DataOfficers(공식 역할이 아닌 예)와 같은 역할이 할당된 사용자 중 일부는 마스킹된 데이터에 대한 보기 권한이 필요할 수 있습니다. 다음 T-SQL 명령을 사용하여 UNMASK 권한을 부여할 수 있습니다.

GRANT UNMASK TO DataOfficers

쿼리하는 사용자에 따라 결과는 다음과 같습니다.

마스크 해제가 가능한 사용자의 예시 스크린샷.

세분화된 동적 데이터 마스킹 권한이 도입되면서 데이터베이스 수준, 스키마 수준, 테이블 수준 또는 열 수준에서 데이터베이스 사용자, Microsoft Entra ID, Microsoft Entra 그룹 또는 데이터베이스 역할에 UNMASK 권한을 부여하거나 취소할 수 있습니다.

데이터 보호 작업

데이터 보호를 설정하고 구성하려면 다음을 수행해야 합니다.

  • 애플리케이션이 연결 암호화를 강제 적용하고 애플리케이션, 클라이언트 및 드라이버와 호환되는 가장 높은 TLS 버전을 사용하는지 확인합니다.
  • TDE를 평가하고 사용하도록 설정합니다. TDE는 새 데이터베이스에서는 기본 설정이지만, 마이그레이션하는 경우 사용하도록 설정해야 할 수 있습니다.
  • 동적 데이터 마스킹을 활용합니다.
  • 고급 보호의 경우 보안 Enclave로 Always Encrypted 기능을 구성할 수 있습니다.

지식 점검

1.

마스킹된 데이터를 볼 수 있는 사용자를 어떻게 관리할 수 있나요?

2.

Always Encrypted로 암호화된 데이터에 대한 같음 비교를 수행하는 경우, 현재 Azure SQL에서 지원되는 연산자는 무엇입니까?