SQL Server 빅 데이터 클러스터의 키 버전

적용 대상: SQL Server 2019(15.x)

중요

Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 2월 28일에 종료됩니다. Software Assurance를 사용하는 SQL Server 2019의 모든 기존 사용자는 플랫폼에서 완전히 지원되며, 소프트웨어는 지원 종료 시점까지 SQL Server 누적 업데이트를 통해 계속 유지 관리됩니다. 자세한 내용은 공지 블로그 게시물Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.

이 문서에서는 SQL Server 빅 데이터 클러스터 키 관리와 HDFS 및 SQL Server 키에 대한 키 회전에 키 버전을 사용하는 방법을 자세히 설명합니다. 이 문서에는 버전이 고객의 키를 통합하는 방법에 대한 자세한 내용이 포함되어 있습니다.

SQL Server 빅 데이터 클러스터 보안에 대한 일반적인 내용은 SQL Server 빅 데이터 클러스터 대한 보안 개념을 참조하세요.

미사용 데이터 암호화 기능을 구성하고 사용하는 방법에 대한 자세한 내용은 다음 가이드를 참조하세요.

HDFS 키

HDFS에서의 미사용 데이터 암호화 사용에는 다음과 같은 개념이 관련되어 있습니다.

  • EZ(암호화 영역): 암호화 영역은 키와 연결된 HDFS의 폴더입니다. 이 폴더의 모든 파일이 암호화됩니다. SQL Server 빅 데이터 클러스터에서 기본 프로비전된 EZ는 "securelake"라고 합니다.
  • EZ 키(암호화 영역 키): 명명된 대칭 키입니다. SQL Server 빅 데이터 클러스터에서 시스템 관리형 기본 프로비전된 키는 "securelakekey"입니다. 암호화 영역 키는 SQL Server 빅 데이터 클러스터 이름 노드 Pod 내에서 실행되는 Hadoop KMS(키 관리 서버)를 사용하여 관리됩니다. EZ 키는 controldb에 저장된 기본 암호화 키를 통해 추가로 보호됩니다(아래 섹션에서 설명). EZ 키는 기본 암호화 키의 공용 부분을 가져와 Hadoop KMS에서 암호화되고 암호 해독 요청은 컨트롤 플레인으로 전송됩니다.
  • 암호화된 데이터 암호화 키: 암호화 영역의 모든 파일은 파일에 대해 생성된 DEK(데이터 암호화 키)로 암호화됩니다. 생성된 DEK는 데이터와 함께 유지됩니다. DEK를 유지하기 위해서는 먼저 암호화 영역 키로 암호화한 다음 데이터로 유지합니다. DEK는 파일당 임의로 생성되며 대칭 DEK의 강도는 EZ 키의 강도와 동일합니다.

아래 그림은 파일이 DEK로 보호되는 방법과 DEK가 EZ 키인 securelakekey로 보호되는 방법을 설명합니다.

파일이 DEK로 보호되는 방법과 DEK가 EZ 키인 securelakekey로 보호되는 방법을 설명합니다.

SQL Server 키

시스템 관리형 기본 암호화 키와 HDFS EZ 키는 controldb 내에 저장되며 controldb-<#>(예: controldb-0)으로 이름이 지정됩니다. 자세한 내용은 빅 데이터 클러스터를 사용하여 리소스 배포를 참조하세요.

SQL Server 데이터베이스는 DEK(데이터베이스 암호화 키)라고도 하는 대칭 키로 암호화됩니다. DEK는 암호화된 형식으로 데이터베이스와 함께 유지됩니다. DEK 보호기는 인증서 또는 비대칭 키일 수 있습니다. DEK 보호기를 변경하려면 ALTER DATABASE ENCRYPTION KEY 문을 사용합니다. SQL Server의 비대칭 키에는 컨트롤 플레인 내의 키에 대한 URL 링크를 포함하는 메타데이터가 있습니다. 따라서 DEK(데이터베이스 암호화 키)의 모든 암호화 및 암호 해독 작업은 컨트롤러 내에서 수행됩니다. SQL Server는 비대칭 키를 식별하기 위해서만 퍼블릭 키를 저장하고 퍼블릭 키를 사용하여 암호화하지 않습니다.

SQL Server 키

SQL Server 빅 데이터 클러스터 기본 암호화 키

암호화 영역 키를 보호하고 SQL Server에서 비대칭 키를 프로비전하기 위해 SQL Server 빅 데이터 클러스터 컨트롤 플레인에는 기본 암호화 키의 개념이 존재합니다. 두 개의 기본 암호화 키는 SQL Server용 키와 HDFS용 키입니다. 이 개념을 사용하면 SQL Server 빅 데이터 클러스터 컨트롤 플레인을 통해 기본 암호화 키도 클러스터 외부에 상주하도록 할 수 있습니다. 기본 암호화 키의 속성은 다음과 같습니다.

  1. 기본 암호화 키는 비대칭 RSA 키입니다.
  2. 기본 암호화 키는 SQL Server 마스터 인스턴스용으로, 다른 하나는 HDFS용으로 만들어집니다.
  3. 기본 암호화 키에 해당하는 공개 키는 항상 컨트롤러 데이터베이스 또는 controldb에 저장됩니다. 프라이빗 키는 시스템 관리 기본 암호화 키에 대한 컨트롤러 데이터베이스에 저장됩니다. HSM(하드웨어 보안 모듈) 또는 기타 다른 외부 공급자의 암호화 키는 프라이빗 키가 컨트롤러 데이터베이스 내에 저장되지 않습니다(외부 키에 대한 애플리케이션에서 프라이빗 키를 가져오지 않는 한). 그러나 프라이빗 키는 controldb 내에 필요하지 않으며 SQL Server 빅 데이터 클러스터에는 프라이빗 키 자료가 필요하지 않습니다.
  4. 기본 암호화 키의 공개 키를 사용하는 암호화 작업은 컨트롤러 자체 내에서 수행하거나, 컨트롤러가 Hadoop KMS에 공개 키를 배포하여 Hadoop KMS가 로컬로 암호화를 수행하도록 할 수 있습니다. 암호 해독 작업은 HSM 등의 외부 키 공급자가 처리해야 합니다. 이를 통해 비대칭 키의 중요한 부분을 클러스터 외부와 고객 보호하에 유지할 수 있습니다. 이렇게 하면 고객이 구성한 키에 대한 SQL Server 빅 데이터 클러스터 에코시스템에서 모든 데이터의 암호를 해독하는 암호화 루트를 절대 사용할 수 없습니다.

서로 다른 키의 스토리지 보호

HDFS 파일 및 SQL Server용 DEK는 DEK가 보호하는 데이터와 함께 저장됩니다. DEK는 각각 SQL Server의 HDFS EZ 키 또는 비대칭 키로 보호됩니다.

SQL Server의 비대칭 키에는 컨트롤 플레인 내의 키 URL을 포함하는 메타데이터가 있습니다. SQL Server는 컨트롤 플레인의 키와의 상관 관계를 위해 비대칭 키의 공개 키만 저장합니다.

controldb의 키 스토리지는 controldb의 열 암호화 키로 보호됩니다. controldb는 클러스터에 대한 중요한 정보를 저장하고 모든 중요한 정보는 controldb의 SQL Server 열 암호화 키로 보호되며 이는 Kubernetes 비밀에 저장된 암호로 추가로 보호됩니다. 자세한 내용은 Kubernetes의 비밀 설명서를 참조하세요.

보호는 아래 다이어그램에 요약되어 있습니다. 먼저 HDFS EZ 키의 스토리지 보호:

HDFS EZ 키의 스토리지 보호

기본 암호화 키의 스토리지 보호:

기본 암호화 키의 스토리지 보호

키 회전

HDFS 암호화 영역 키

Active Directory를 사용하여 SQL Server 빅 데이터 클러스터를 배포하는 경우 HDFS는 securelake라는 기본 암호화 영역으로 프로비저닝되고 securelakekey로 보호됩니다. 예제에서는 기본값을 사용하겠습니다. 그러나 azdata를 사용해 새 영역 및 키를 프로비전할 수 있습니다. securelakekey는 컨트롤 플레인에 저장된 HDFS에 대한 기본 암호화 키로 보호됩니다. SQL 2019 CU9부터 azdata를 사용해 HDFS용 EZ 키를 회전할 수 있습니다. EZ 키를 회전하면 "securelakekey"와 이름이 같지만 키 자료를 가리키는 새 버전의 키로 새로운 키 자료가 생성됩니다. HDFS의 모든 새 암호화 작업(예: 파일 쓰기)에서 EZ는 항상 EZ와 연결된 최신 버전의 키를 사용합니다. 이전 버전의 키로 보호되는 EZ의 파일의 경우 azdata bdc hdfs encryption-zone reencrypt 명령을 사용하여 모든 파일을 최신 버전의 EZ 키로 보호할 수 있습니다.

/securelake에 배치된 file2라는 파일을 고려합니다. 보호 체인은 다음과 같습니다.

보호 체인

securelakekey는 azdata bdc hdfs key roll -n securelakekey를 사용하여 새 버전으로 회전할 수 있습니다. 회전해도 파일을 보호하는 DEK가 다시 암호화되지는 않습니다. Hadoop 키 회전에 따라 새로운 키 자료가 생성되고 최신 버전의 기본 암호화 키로 보호됩니다. 다음 다이어그램은 securelakekey를 회전한 후의 시스템 상태를 보여줍니다.

회전 후 보호 체인

암호화 영역의 파일이 회전된 securelakekey로 보호되도록 하려면 azdata bdc hdfs encryption-zone -a start -p /securelake 명령을 사용합니다.

다음 다이어그램은 암호화 영역을 다시 암호화한 후의 시스템 상태를 보여줍니다.

다시 암호화 후 보호 체인

SQL Server

SQL Database를 보호하는 키는 DEK이며 다시 생성할 수 있습니다. 키를 다시 생성하면 전체 데이터베이스가 다시 암호화됩니다.

기본 암호화 키 순환

참고 항목

SQL Server 2019 CU10 이전에는 기본 암호화 키를 회전할 방법이 없었습니다. SQL Server 2019 CU10부터는 기본 암호화 키를 회전할 수 있도록 azdata 명령이 노출됩니다.

기본 암호화 키는 RSA 2048비트 키입니다. 기본 암호화 키의 회전은 키의 원본에 따라 다음 중 하나를 수행합니다.

  1. 기본 키를 시스템 관리형 키로 회전하라는 요청이 이루어진 경우 새 키를 만듭니다. 시스템 관리형 키는 컨트롤러 내부에 생성 및 저장되는 비대칭 키입니다.
  2. 외부에서 제공된 키에 대한 참조를 만듭니다. 여기에서는 비대칭의 프라이빗 키가 고객 애플리케이션에서 관리됩니다. 고객 애플리케이션에는 프라이빗 키가 필요하지 않지만 제공된 애플리케이션의 구성에 따라 프라이빗 키를 검색하는 방법을 알아야 합니다.

기본 키를 회전해도 다시 암호화되지는 않습니다. 그다음 SQL Server 및 HDFS 키를 회전해야 합니다.

  • 기본 키를 회전한 후에는 만들어진 기본 키의 새 버전으로 SQL Server 데이터베이스 DEK 보호기를 회전해야 합니다.
  • 이와 유사한 개념이 HDFS에 적용됩니다. HDFS 키를 회전하면 새 자료가 최신 버전의 기본 키로 암호화됩니다. 이전 버전의 EZ 키는 그 상태를 그대로 유지합니다. HDFS EZ 키를 회전한 후에는 EZ 키와 연결된 암호화 영역을 다시 암호화하여 최신 EZ 키 버전으로 다시 암호화되도록 해야 합니다.

HDFS에 대한 기본 키 회전

다음 다이어그램에서는 HDFS에 대한 기본 암호화 키를 회전하는 프로세스를 설명합니다. HDFS의 초기 상태:

HDFS의 초기 상태

기본 암호화 키는 azdata bdc kms set –key-provider SystemManaged를 사용하여 회전됩니다. (이 명령은 컨트롤 플레인 내에서 서로 다른 키임에도 불구하고 SQL 및 HDFS 모두에 대해 기본 암호화 키를 회전합니다.) azdata bdc kms 명령을 사용한 후:

azdata bdc kms 명령을 사용한 후

HDFS 기본 암호화 키의 새 버전을 사용하려면 azdata bdc hdfs key roll 명령을 사용할 수 있으며, 시스템은 다음 상태가 됩니다. securelakekey를 회전한 후:

securelakekey를 회전한 후

securelakekey를 회전하면 새 버전의 securelakekey가 생성되고 기본 암호화 키로 보호됩니다. securelake의 파일이 securelakekey@2로 암호화되도록 하려면 securelake 암호화 영역을 다시 암호화해야 합니다. 암호화 영역을 다시 암호화한 후:

암호화 영역을 다시 암호화한 후

SQL Server 기본 키 회전

SQL Server 기본 암호화 키는 SQL Server 마스터 인스턴스의 master 데이터베이스에 설치됩니다.

다음 다이어그램에서는 SQL Server에 기본 암호화 키를 회전하는 프로세스를 설명합니다.

SQL Server 빅 데이터 클러스터를 새로 설치하면 SQL Server에 비대칭 키가 프로비전되지 않습니다. SQL Server의 초기 상태에서는 인증서를 사용하여 데이터베이스를 암호화할 수 있지만 SQL Server 마스터 인스턴스 관리자는 이러한 측면을 제어합니다.

SQL Server의 초기 상태

기본 암호화 키는 azdata bdc kms set –key-provider SystemManaged를 사용하여 회전됩니다. (이 명령은 컨트롤 플레인 내에서 서로 다른 키임에도 불구하고 SQL 및 HDFS 모두에 대한 기본 암호화 키를 회전합니다[또는 존재하지 않는 경우 만듭니다].)

SQL Server 기본 암호화 키는 SQL Server 마스터 인스턴스의 master DB에 설치됩니다.

sys.asymmetric_keys 시스템 카탈로그 뷰에서 다음 T-SQL 쿼리를 사용하여 비대칭 키를 확인할 수 있습니다.

USE master;
select * from sys.asymmetric_keys;

비대칭 키는 “tde_asymmetric_key_<version>” 명명 규칙으로 표시됩니다. SQL Server 관리자는 ALTER DATABASE ENCRYPTION KEY를 사용하여 DEK의 보호기를 비대칭 키로 변경할 수 있습니다. 예를 들어 다음 T-SQL 명령을 사용합니다.

USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;

이제 DEK 보호기가 비대칭 키를 사용하도록 변경되었습니다.

DEK 보호기가 비대칭 키를 사용하도록 변경된 후

azdata bdc kms set 명령을 다시 실행하면 SQL Server의 비대칭 키에 해당하는 다른 항목이 sys.asymmetric_keys에 “tde_asymmetric_key_<version>” 형식으로 표시됩니다. 이 azdata 명령을 사용하여 SQL Server 데이터베이스의 DEK 보호기를 다시 변경할 수 있습니다.

고객 제공 키

기본 암호화 키는 SQL Server 빅 데이터 클러스터에서 외부 키를 가져올 수 있으므로 고객이 배포하는 애플리케이션을 사용하여 퍼블릭 키를 가져옵니다. HDFS 키를 회전하고 사용하는 경우 HDFS 키의 암호를 해독하는 호출은 컨트롤 플레인으로 전송된 다음, 고객이 제공한 키 식별자를 사용하여 애플리케이션으로 리디렉션됩니다. SQL Server의 경우 컨트롤 플레인에 퍼블릭 키가 있기 때문에 컨트롤 플레인에서 암호화 요청을 전송하고 수행합니다. SQL에서 DEK의 암호를 해독하는 요청도 컨트롤 플레인으로 전송된 다음 KMS 애플리케이션으로 리디렉션됩니다.

고객 키를 설치한 후

다음 다이어그램은 컨트롤 플레인에서 외부 키를 구성하는 동안의 상호 작용을 설명합니다.

컨트롤 플레인에서 외부 키를 구성하는 동안의 상호 작용

키를 설치한 후에는 다른 페이로드의 암호화 및 암호 해독이 기본 암호화 키로 보호됩니다. 이 보호는 시스템 관리형 키와 유사합니다. 단, 컨트롤 플레인으로 라우팅된 암호 해독 호출은 KMS 플러그 인 앱으로 라우팅됩니다. KMS 플러그 인 앱은 HSM이나 다른 제품 등의 적절한 위치로 요청을 라우팅합니다.

참고 항목