Azure의 클라우드 규모 분석을 위한 데이터 프라이버시

아티클
10/10/2023

클라우드 규모 분석을 통해 조직은 여러 수준에서 개인 데이터를 보호하면서 요구 사항에 맞는 최상의 패턴을 결정할 수 있습니다. 개인 데이터는 운전 면허증 번호, 사회 보장 번호, 은행 계좌 번호, 여권 번호, 이메일 주소 등과 같이 개인을 식별하는 데 사용할 수 있는 모든 데이터입니다. 오늘날 사용자 개인 정보를 보호하기 위한 많은 규정이 있습니다.

데이터 기밀성 분류 체계

분류	설명
공개	누구나 데이터에 액세스할 수 있으며 누구에게나 전송할 수 있습니다. 정부의 공개 데이터를 예제로 들 수 있습니다.
내부적으로만 사용됩니다.	직원만 데이터에 액세스할 수 있으며 회사 외부로 전송할 수 없습니다.
비밀	특정 작업에 필요한 경우에만 데이터를 공유할 수 있습니다. 비밀 유지 계약 없이는 회사 외부로 데이터를 전송할 수 없습니다.
중요(개인 데이터)	꼭 알아야 하는 필요가 있는 경우에 한하여 제한된 시간 동안만 마스킹되고 공유되어야 하는 비공개 정보가 포함된 데이터입니다. 권한이 없는 직원에게 또는 회사 외부로 데이터를 전송할 수 없습니다.
Restricted	해당 데이터 보호에 대한 책임이 있는 명명된 개인과만 데이터를 공유할 수 있습니다. 법적 문서 또는 영업 비밀을 예제로 들 수 있습니다.

데이터를 수집하기 전에 데이터를 기밀 이하 또는 중요(개인 데이터)로 분류해야 합니다.

사용자가 보강 또는 큐레이팅의 데이터 자산에 액세스할 수 있는 경우 데이터가 기밀 이하로 정렬될 수 있습니다. 사용자는 모든 열과 행을 볼 수 있습니다.
다른 사용자에게 표시되는 열과 행에 대한 제한이 있는 경우 데이터가 중요(개인 데이터)로 정렬될 수 있습니다.

Important

데이터가 결합되면 데이터집합이 기밀 이하에서 중요(개인 데이터)로 변경될 수 있습니다. 데이터가 영구적이어야 하는 상황에서는 데이터 기밀성 분류 및 온보딩 프로세스와 일치하는 별도의 폴더에 복사해야 합니다.

기밀 이하

온보딩된 모든 데이터 제품에 대해 보강되고 큐레이팅된 계층 에 기밀 또는 아래 와 중요한(개인 데이터)의 두 개의 데이터 레이크 폴더를 만들고 액세스 제어 목록을 사용하여 Microsoft Azure 디렉터리(Microsoft Entra ID) 통과 인증을 사용하도록 설정합니다.

데이터 애플리케이션 팀이 기밀 또는 아래 데이터 자산을 온보딩하는 경우 사용자 계정 이름 및 서비스 주체 개체를 두 개의 Microsoft Entra 그룹(읽기/쓰기 액세스용 및 읽기 전용 액세스용)에 추가할 수 있습니다. 이러한 두 Microsoft Entra 그룹은 온보딩 프로세스 중에 만들어지고 원시 및 보강된 데이터에 대한 기밀 또는 아래 컨테이너가 있는 적절한 데이터 제품 폴더에 정렬되어야 합니다.

이 패턴을 사용하면 Microsoft Entra 통과 인증을 지원하는 모든 컴퓨팅 제품이 데이터 레이크에 연결하고 로그인한 사용자를 인증할 수 있습니다. 사용자가 데이터 자산의 Microsoft Entra 그룹에 속하는 경우 Microsoft Entra 통과 인증을 통해 데이터에 액세스할 수 있습니다. 이를 통해 그룹 내의 해당 사용자는 정책 필터 없이 전체 데이터 자산을 읽을 수 있습니다. 그런 다음 적절한 로그와 Microsoft Graph를 사용하여 액세스를 자세히 감사할 수 있습니다.

데이터 레이크 레이아웃에 대한 권장 사항은 각 데이터 랜딩 존에 대해 3개의 Azure Data Lake Storage Gen2 계정 프로비전을 검토하세요.

참고 항목

컴퓨팅 제품의 예로는 Azure Databricks, Azure Synapse Analytics, Apache Spark 및 Microsoft Entra 통과 인증으로 사용하도록 설정된 Azure Synapse SQL 주문형 풀이 있습니다.

중요 데이터(개인 데이터)

중요(개인 데이터)의 경우 기업은 사용자가 정책, 데이터 복사본 또는 컴퓨팅을 통해 볼 수 있는 데이터를 제한해야 합니다. 이 경우 조직은 액세스 제어를 컴퓨팅 계층으로 이동하거나 주입하는 것을 고려해야 합니다. 클라우드 규모 분석 내에서 데이터 보안에 접근할 수 있는 옵션은 네 가지가 있습니다.

예제 시나리오

다음 예에서는 중요(개인 데이터) 보안 옵션을 설명합니다.

데이터 애플리케이션은 북아메리카 및 유럽의 HR(인적 자원) 인사 데이터 제품을 수집합니다. 사용 사례에서는 유럽 사용자가 유럽 인사 기록만 볼 수 있고 북아메리카 사용자가 북아메리카 인사 기록만 볼 수 있습니다. HR 관리자만 급여 데이터가 포함된 열을 볼 수 있도록 추가로 제한됩니다.

옵션 1: 정책 엔진(권장)

처음 두 옵션은 중요(개인 데이터)를 처리하는 방법을 제공하며, 통합 작업 및 데이터 제품 팀이 액세스를 식별하고 제한할 수 있는 제어 권한도 부여합니다. 소규모 분석 플랫폼에는 충분할 수 있지만 수백 개의 데이터 제품이 있는 대기업의 경우 정책 엔진을 데이터 관리 랜딩 존에 배치해야 합니다. 정책 엔진은 다음을 관리, 보안 및 제어하는 중앙 집중식 방법을 지원합니다.

데이터 액세스
데이터 수명 주기 관리
내부 및 외부 정책 및 규정
데이터 공유 정책
중요(개인 데이터) 식별
보호 및 규정 준수에 대한 인사이트
데이터 보호 보고 정책

일반적으로 정책 엔진은 Azure Purview와 같은 데이터 카탈로그와 통합됩니다. Azure Marketplace는 타사 공급업체 솔루션을 제공하며 일부 공급업체는 Azure Synapse 및 Azure Databricks와 협력하여 정보를 암호화 및 암호 해독하는 동시에 행 수준 및 열 수준 보안을 제공합니다. 2022년 1월, Azure Purview는 Blob 및 ADLS(Azure Data Lake Storage) Gen2에 저장된 데이터에 대한 액세스를 제어하기 위한 액세스 정책에 대한 공개 미리 보기를 출시했습니다. Azure Storage에 대한 데이터 소유자별 데이터 세트 프로비저닝(미리 보기)을 참조하세요.

정책 엔진은 Microsoft Entra 그룹을 사용하여 데이터 제품에 정책을 적용해야 합니다. 데이터 개인 정보 보호를 제공하는 모든 정책 솔루션에 대한 기대치는 중요(개인 데이터)를 토큰화하고 사용자가 액세스해야 하는 열을 토큰화 해제할 수 있도록 항상 특성 액세스 제어를 통해 확인하는 것입니다.

언급했듯이 정책 엔진이 성공하려면 데이터 카탈로그에 통합하고 DevOps가 REST API를 사용하여 새 데이터 세트를 온보딩하는 것이 중요합니다. 데이터 애플리케이션 팀이 읽기 데이터 원본을 만들 때, 이러한 원본은 데이터 카탈로그에 등록되어 중요(개인 데이터) 식별을 돕습니다. 정책 엔진은 정의를 가져와서 팀이 액세스 정책을 설정할 때까지 데이터에 대한 모든 액세스를 거부해야 합니다. 이 모든 것은 IT 서비스 관리 솔루션의 REST API 워크플로를 통해 수행되어야 합니다.

옵션 2: 기밀 이하 및 중요(개인 데이터) 버전

중요(개인 데이터)로 분류되는 모든 데이터 제품의 경우 파이프라인을 통해 복사본 2개가 만들어집니다. 복사본 하나는 기밀 이하로 분류됩니다. 모든 중요(개인 데이터) 열이 제거되었으며 데이터 제품에 대한 기밀 이하 폴더 아래에 만들어집니다. 다른 복사본은 모든 중요한 데이터가 포함된, 데이터 제품에 대한 중요(개인 데이터) 폴더에 만들어집니다. 각 폴더에는 Microsoft Entra 판독기 보안 그룹과 Microsoft Entra 기록기 보안 그룹이 할당됩니다. 사용자는 데이터 액세스 관리를 통해 데이터 제품에 대한 액세스를 요청할 수 있습니다.

이렇게 하면 중요(개인 데이터) 및 기밀 이하의 구분을 수행할 수 있으며, Active Directory 통과 인증을 통해 중요(개인 데이터)에 대한 액세스 권한을 부여받은 사용자는 모든 행을 쿼리할 수 있습니다. 행 수준 보안이 필요한 경우 옵션 1: 정책 엔진(권장) 또는 옵션 3: Azure SQL 데이터베이스, SQL Managed Instance 또는 Azure Synapse Analytics SQL 풀.

옵션 3: Azure SQL Database, SQL Managed Instance 또는 Azure Synapse Analytics SQL 풀

데이터 애플리케이션은 SQL Database, SQL Managed Instance 또는 Azure Synapse Analytics SQL 풀을 사용하여 행 수준 보안, 열 수준 보안 및 동적 데이터 마스킹을 지원하는 데이터베이스에 데이터 제품을 로드합니다. 데이터 애플리케이션 팀은 다른 Microsoft Entra 그룹을 만들고 데이터의 민감도를 지원하는 권한을 할당합니다.

이 시나리오의 사용 사례의 경우 데이터 애플리케이션 팀은 읽기 전용 액세스 권한이 있는 다음 4개의 Microsoft Entra 그룹을 만들어야 합니다.

그룹	Permission
`DA-AMERICA-HRMANAGER-R`	급여 정보가 있는 북아메리카 HR 직원 데이터 자산을 봅니다.
`DA-AMERICA-HRGENERAL-R`	급여 정보가 없는 북아메리카 HR 직원 데이터 자산을 봅니다.
`DA-EUROPE-HRMANAGER-R`	급여 정보가 있는 유럽 HR 직원 데이터 자산을 봅니다.
`DA-EUROPE-HRGENERAL-R`	급여 정보가 없는 유럽 HR 직원 데이터 자산을 봅니다.

첫 번째 제한 수준은 권한이 없는 사용자로부터 중요한 데이터를 숨기는 동적 데이터 마스킹을 지원합니다. 이 방법의 한 가지 장점은 REST API를 사용하여 데이터 집합의 온보딩에 통합할 수 있다는 것입니다.

두 번째 수준은 열 수준 보안을 추가하여 비HR 관리자가 급여를 볼 수 없도록 제한하고 행 수준 보안을 추가하여 유럽 및 북아메리카 팀 구성원이 볼 수 있는 행을 제한합니다.

투명한 데이터 암호화 외에도 보안 계층은 데이터 열을 암호화하고 읽을 때 해독합니다.

테이블은 Apache Spark 커넥터: SQL Server 및 Azure SQL Database를 사용하여 Azure Databricks에서 사용할 수 있습니다.

옵션 4: Azure Databricks

네 번째 옵션은 Azure Databricks를 사용하여 중요(개인 데이터)를 탐색하는 것입니다. Fernet 암호화 라이브러리, UDF(사용자 정의 함수), Databricks 비밀, 테이블 액세스 제어 및 동적 보기 기능의 조합을 사용하면 열을 암호화하고 해독하는 데 도움이 됩니다.

블로그 게시물에서 열 수준 암호화 적용 및 데이터 중복 방지에 대해 설명합니다.

이 프로세스의 첫 번째 단계는 수집 중에 데이터를 암호화하여 데이터를 보호하는 것이며 한 가지 가능한 솔루션은 Fernet Python 라이브러리입니다. Fernet은 여러 표준 암호화 기본 요소로 빌드된 대칭형 암호화를 사용합니다. 이 라이브러리는 데이터 프레임의 주어진 열을 암호화할 수 있는 암호화 UDF 내에서 사용됩니다. 암호화 키를 저장하기 위해 데이터 수집 프로세스에서만 액세스할 수 있도록 액세스 제어가 있는 Databricks 비밀을 사용합니다. 데이터가 Delta 레이크 테이블에 기록되면 사회 보장 번호, 전화번호, 신용 카드 번호 및 기타 식별자와 같은 값이 포함된 개인 데이터 열은 권한이 없는 사용자가 읽을 수 없습니다.

중요한 데이터를 작성하고 보호한 후에는 권한이 있는 사용자가 중요한 데이터를 읽을 수 있는 방법이 필요합니다. 가장 먼저 해야 할 일은 Databricks에서 실행되는 Hive 인스턴스에 추가할 영구 UDF를 만드는 것입니다. UDF가 영구적이려면 스칼라로 작성해야 합니다. 다행히도 Fernet에는 해독된 읽기에 사용할 수 있는 Scala 구현도 있습니다. 이 UDF는 암호화된 쓰기에 사용된 것과 동일한 비밀에 액세스하여 복호화를 수행하며 이 경우 클러스터의 Spark 구성에 추가됩니다. 이를 위해서는 권한이 있는 사용자와 권한이 없는 사용자가 키에 대한 액세스를 제어할 수 있도록 클러스터 액세스 제어를 추가해야 합니다. UDF가 만들어지면 권한이 있는 사용자가 해독된 데이터를 볼 수 있도록 보기 정의 내에서 사용할 수 있습니다.

동적 보기 기능을 사용하면 보기를 하나만 만들고 속해 있는 Databricks 그룹을 기반으로 암호화되거나 복호화된 값을 반환할 수 있습니다.

이전 예에서는 두 개의 동적 보기 기능(북아메리카용과 유럽용)을 만들고 이 Notebook에서 암호화 기술을 구현합니다.

북아메리카 보기:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

유럽식 보기:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

작동하려면 작업 영역에서 Azure Databricks 테이블 액세스 제어를 사용하도록 설정하고 다음 권한을 적용합니다.

보기에 대한 액세스 권한을 부여 DA-AMERICA-HRMANAGER-R 하고 DA-AMERICA-HRGENERAL-R Microsoft Entra 그룹화합니다 vhr_us .
보기에 대한 액세스 권한을 부여 DA-EUROPE-HRMANAGER-R 하고 DA-EUROPE-HRGENERAL-R Microsoft Entra 그룹화합니다 vhr_eu .

열은 암호화되고 기밀 또는 아래 작업 영역에서 암호 해독할 수 없으므로 기밀 또는 아래 작업 영역은 여전히 Microsoft Entra 통과 인증을 사용하고 사용자가 자신의 권한에 따라 레이크를 탐색할 수 있도록 할 수 있습니다.

테이블 액세스가 사용되는 경우 액세스가 필요한 팀이 Azure Databricks 작업 영역에 추가됩니다. Azure Databricks는 서비스 주체를 사용하여 Azure Data Lake Storage에 매핑하지만 데이터는 Azure Databricks 테이블 액세스 제어로 보호됩니다.

새 데이터 제품이 배포되면 DevOps 프로세스의 일부가 스크립트를 실행하여 Azure Databricks 작업 영역에서 테이블 권한을 설정하고 해당 권한에 올바른 Microsoft Entra 그룹을 추가해야 합니다.

참고 항목

Azure Databricks 테이블 액세스 제어는 Microsoft Entra 통과 인증을 결합할 수 없습니다. 따라서 Azure Databricks 작업 영역을 하나만 사용하고 대신 테이블 액세스 제어를 사용할 수 있습니다.

제한된 데이터

기밀 또는 제한된 데이터에 대한 옵션을 구현하는 것과 함께 전용 데이터 랜딩 존 및 데이터 관리 랜딩 존에서 기밀 데이터를 호스팅하는 것이 좋습니다.

JIT(Just-In-Time) 액세스, 암호화를 위한 고객 관리형 키, 랜딩 존에 적용되는 인바운드 또는 아웃바운드 제한과 같은 특정 요구 사항을 허용합니다. 지침에서는 이 유형의 데이터를 동일한 데이터 랜딩 존에 저장하지만 다른 스토리지 계정에 넣는 것을 평가했습니다. 그러나 네트워크 보안 그룹 및 기타와 같은 네트워킹 계층에서 솔루션을 복잡하게 만들 수 있습니다.

전용 '제한된' 데이터 관리 랜딩 존은 '제한된' 데이터 랜딩 존의 데이터를 카탈로그화하기 위해 연결해야 합니다. 카탈로그에서 이 데이터를 검색할 수 있는 사람을 제한해야 합니다.

다음 단계

데이터 액세스 관리를 참조하세요.

다음을 통해 공유