Microsoft Purview(이전의 Azure Purview) 배포 모범 사례

  • 아티클
  • 읽는 데 50분 걸림

이 문서는 Microsoft Purview(이전의 Azure Purview)를 데이터 자산의 프로덕션에 성공적으로 배포하기 위한 가이드입니다. 이는 연구에서 프로덕션 환경 강화에 이르기까지 배포를 전략화하고 단계적으로 수행하는 데 도움이 되며 배포 검사 목록과 함께 사용하는 것이 가장 좋습니다.

참고

이러한 모범 사례는 Microsoft Purview 통합 데이터 거버넌스 솔루션에 대한 배포를 다룹니다. Microsoft Purview 위험 및 규정 준수 솔루션에 대한 자세한 내용은 여기를 참조하세요. 일반적으로 Microsoft Purview에 대한 자세한 내용은 여기를 참조하세요.

엄격한 기술 배포 가이드를 찾고 있다면 배포 검사 목록을 사용합니다.

Microsoft Purview 배포 계획을 만들고 배포 전략을 개발할 때 모범 사례를 고려하려는 경우 아래 문서를 따릅니다. 이 가이드에서는 Microsoft Purview용 배포 프로세스를 개발하기 위해 한 달 이상 동안 단계적으로 완료할 수 있는 작업에 대해 설명합니다. Microsoft Purview를 이미 배포한 조직도 이 가이드를 사용하여 투자를 최대한 활용할 수 있습니다.

데이터 거버넌스 플랫폼의 잘 계획된 배포는 다음과 같은 이점을 제공할 수 있습니다.

  • 데이터 검색 향상
  • 분석 협업 개선
  • 투자 수익률을 최대화합니다.

이 가이드는 다음 단계에 따라 초기 계획에서 성숙한 환경에 이르기까지 전체 배포 수명 주기에 대한 인사이트를 제공합니다.

단계 Description
개체 및 목표 확인 전체 조직이 데이터 거버넌스에서 무엇을 원하고 필요로 하는지 고려합니다.
질문 수집 시작할 때 사용자와 사용자의 팀에 어떤 질문이 있을 수 있으며 어디에서 이러한 질문을 해결할 수 있나요?
배포 모델 데이터 자산에 맞게 Microsoft Purview 배포를 사용자 지정합니다.
프로덕션으로 이동하는 프로세스 만들기 조직에 맞는 단계별 배포 전략을 만듭니다.
플랫폼 보안 강화 배포가 완성될 때까지 계속 확장합니다.

많은 Microsoft Purview의 애플리케이션 및 기능에는 고유한 개별 모범 사례 페이지도 있습니다. 이 배포 가이드 전체에서 자주 참조되지만 개념과 모범 사례 및 가이드라인 아래의 목차에서 모두 찾을 수 있습니다.

개체 및 목표 확인

많은 조직이 조직 전체에서 격리된 그룹 및 데이터 도메인의 특정 요구 사항을 충족하는 개별 솔루션을 개발하여 데이터 거버넌스 경험을 시작했습니다. 경험은 산업, 제품 및 문화에 따라 다를 수 있지만 대부분의 조직은 이러한 형식의 솔루션에 대해 일관된 제어 및 정책을 유지하기가 어렵습니다.

포괄적인 데이터 거버넌스 환경을 만들기 위해 초기 단계에서 식별할 수 있는 몇 가지 일반적인 데이터 거버넌스 목표는 다음과 같습니다.

  • 데이터의 비즈니스 가치 극대화
  • 데이터 소비자가 데이터를 쉽게 찾고, 해석하고, 신뢰할 수 있는 데이터 문화권 사용
  • 일관된 데이터 경험을 제공하기 위해 다양한 사업부 간의 협업 증대
  • 데이터 분석을 가속화하여 클라우드의 혜택을 활용하여 혁신 촉진
  • 다양한 기술 그룹에 대한 셀프 서비스 옵션을 통해 데이터 검색 시간 단축
  • 고객 서비스를 개선하는 분석 솔루션 제공을 위한 시장 출시 시간 단축
  • 도메인 특정 도구 및 지원되지 않는 기술 사용으로 인한 운영 위험 감소

일반적인 방법은 이러한 중요한 목표를 다양한 범주와 목표로 분류하는 것입니다. 몇 가지 예는 다음과 같습니다.

범주 목표
검색 관리자는 Azure 및 Azure 이외 데이터 원본(온-프레미스 원본 포함)을 검색하여 데이터 자산에 대한 정보를 자동으로 수집할 수 있어야 합니다.
분류 플랫폼은 데이터 샘플링을 기반으로 데이터를 자동으로 분류하고 사용자 지정 분류를 사용하여 수동 재정의를 허용해야 합니다.
Consumption 비즈니스 사용자는 비즈니스 및 기술 메타데이터에 대한 각 자산에 대한 정보를 찾을 수 있어야 합니다.
계보 각 자산은 사용자가 원래 원본과 변경 내용을 이해할 수 있도록 기본 데이터 집합의 그래픽 보기를 표시해야 합니다.
협업 플랫폼은 사용자가 각 데이터 자산에 대한 추가 정보를 제공하여 협업할 수 있도록 해야 합니다.
보고 사용자는 추가 보강이 필요한 중요한 데이터 및 데이터를 포함하여 데이터 자산에 대한 보고를 볼 수 있어야 합니다.
데이터 거버넌스 플랫폼은 관리자가 액세스 제어를 위한 정책을 정의하고 각 사용자를 기반으로 데이터 액세스를 자동으로 시행할 수 있도록 허용해야 합니다.
워크플로 플랫폼에는 플랫폼 내에서 다양한 작업을 쉽게 스케일 아웃하고 자동화할 수 있도록 워크플로를 만들고 수정할 수 있는 기능이 있어야 합니다.
통합 티켓팅 또는 오케스트레이션과 같은 기타 타사 기술은 스크립트 또는 REST API를 통해 플랫폼에 통합할 수 있어야 합니다.

주요 시나리오 식별

Microsoft Purview 거버넌스 서비스를 사용하여 클라우드 및 온-프레미스 환경에 걸친 조직의 데이터 자산 전체에서 데이터 거버넌스를 중앙에서 관리할 수 있습니다. 성공적인 구현을 위해서는 비즈니스에 중요한 주요 시나리오를 확인해야 합니다. 이러한 시나리오는 사업부 경계를 넘거나 업스트림 또는 다운스트림의 여러 사용자의 가상 사용자에 영향을 미칠 수 있습니다.

이러한 시나리오는 다양한 방법으로 작성할 수 있지만, 최소 다음과 같은 5개 이상의 차원을 포함해야 합니다.

  1. 가상 사용자 – 사용자는 누구인가요?
  2. 원본 시스템 – Azure Data Lake Storage Gen2 또는 Azure SQL Database 같은 데이터 원본이란 무엇인가요?
  3. 영향 영역 – 이 시나리오의 범주는 무엇인가요?
  4. 세부 시나리오 – 사용자가 Microsoft Purview를 사용하여 문제를 해결하는 방법은 무엇인가요?
  5. 예상 결과 – 성공 조건이란 무엇인가요?

시나리오는 구체적이고 실행 가능하며 측정 가능한 결과와 함께 실행 가능해야 합니다. 사용할 수 있는 몇 가지 예제 시나리오는 다음과 같습니다.

시나리오 세부 정보 가상 사용자
중요 비즈니스용 자산 카탈로그 무엇인지 잘 이해하기 위해 각 데이터 집합에 대한 정보가 필요합니다. 이 시나리오에는 카탈로그의 데이터 집합에 대한 비즈니스 및 기술 메타데이터 데이터가 모두 포함됩니다. 데이터 원본에는 Azure Data Lake Storage Gen2, Azure Synapse DW 및/또는 Power BI가 포함됩니다. 이 시나리오에는 SQL Server와 같은 온-프레미스 리소스도 포함됩니다. 비즈니스 분석가, 데이터 과학자, 데이터 엔지니어
중요 비즈니스용 자산 검색 카탈로그에 있는 모든 메타데이터를 검색할 수 있는 검색 엔진이 있어야 합니다. 와일드카드를 사용하여 단순 또는 복잡한 검색으로 기술 용어, 비즈니스 용어를 사용하여 검색할 수 있어야 합니다. 비즈니스 분석가, 데이터 과학자, 데이터 엔지니어, 데이터 관리자
데이터를 추적하여 원본 이해 및 데이터 문제 해결 보고서, 예측 또는 모델의 데이터를 원래 원본으로 다시 추적하려면 데이터 계보가 필요합니다. 또한 데이터에 대한 변경 내용과 데이터 수명 주기 동안 데이터가 상주한 위치를 이해해야 합니다. 이 시나리오는 우선순위가 지정된 데이터 파이프라인 Azure Data Factory 및 Databricks를 지원해야 합니다. 데이터 엔지니어, 데이터 과학자
중요한 데이터 자산에 대한 메타데이터 보강 자동으로 생성되는 기술 메타데이터로 카탈로그의 데이터 집합을 보강해야 합니다. 분류 및 레이블 지정은 몇 가지 예입니다. 데이터 엔지니어, 도메인/비즈니스 소유자
친숙한 사용자 경험으로 데이터 자산 거버넌스 비즈니스 특정 메타데이터에 대한 비즈니스 용어집이 있어야 합니다. 비즈니스 사용자는 셀프 서비스 시나리오에 Microsoft Purview를 사용하여 데이터에 주석을 달고 검색을 통해 데이터를 쉽게 검색할 수 있습니다. 도메인/비즈니스 소유자, 비즈니스 분석가, 데이터 과학자, 데이터 엔지니어

Microsoft Purview와의 통합 지점

성숙한 조직에는 이미 기존 데이터 카탈로그가 있을 가능성이 높습니다. 핵심 질문은 기존 기술을 계속 사용하고 Microsoft Purview 데이터 맵 및 Data Catalog와 동기화할지 여부를 나타냅니다. 조직의 기존 제품과의 동기화를 처리하기 위해 Microsoft Purview는 Atlas REST API를 제공합니다. Atlas API는 밀어넣기 및 끌어오기 시나리오를 모두 처리하는 강력하고 유연한 메커니즘을 제공합니다. 부트스트래핑을 위해 Atlas API를 사용하거나 다른 시스템에서 Microsoft Purview로 최신 업데이트를 푸시하기 위해 정보를 Microsoft Purview에 게시할 수 있습니다. Microsoft Purview에서 사용할 수 있는 정보는 Atlas API를 사용하여 읽을 수도 있고 기존 제품과 다시 동기화할 수도 있습니다.

티켓팅, 사용자 지정 사용자 인터페이스 및 오케스트레이션과 같은 다른 통합 시나리오의 경우 Atlas API 및 Kafka 엔드포인트를 사용할 수 있습니다. 일반적으로 Microsoft Purview에는 네 가지 통합 지점이 있습니다.

  • 데이터 자산 – Microsoft Purview는 이러한 자산이 무엇인지를 열거하고 해당 자산에 대한 즉시 사용 가능한 메타데이터를 수집하기 위해 저장소의 자산을 검사할 수 있도록 합니다. 따라서 SQL의 경우 sys.tables과 같은 위치에 보관된 DB, 테이블, 저장 프로시저, 뷰 및 구성 데이터가 나열될 수 있습니다. ADF(Azure Data Factory)와 같은 항목의 경우 모든 파이프라인을 열거하고 생성된 시점, 마지막 실행, 현재 상태에 대한 데이터를 가져올 수 있습니다.
  • 계보 – 이를 통해 Microsoft Purview는 분석/데이터 변형 시스템에서 데이터 이동 방식에 대한 정보를 수집할 수 있습니다. Spark와 같은 경우 노트북 실행에서 정보를 수집하여 노트북이 어떤 데이터를 수집했는지, 어떻게 변환했는지, 어디에서 출력했는지 확인할 수 있습니다. SQL과 같은 경우 쿼리 로그를 분석하여 실행된 변형 작업과 수행한 작업을 리버스 엔지니어링할 수 있습니다. 필요에 따라 밀어넣기 및 끌어오기 기반 계보를 모두 지원합니다.
  • 분류 – 이를 통해 Microsoft Purview는 데이터 원본에서 실제 샘플을 가져와 분류 시스템을 통해 실행할 수 있습니다. 분류 시스템은 데이터의 의미 체계를 파악합니다. 예를 들어 파일은 Parquet 파일이며 3개의 열이 있고 3번째 열은 문자열이라는 것을 알 수 있습니다. 그러나 샘플에서 실행되는 분류자는 문자열이 이름, 주소 또는 전화번호임을 알려 줍니다. 이 통합 지점을 밝히는 것은 Microsoft Purview가 Notebooks, 파이프라인, parquet 파일, 테이블 및 컨테이너와 같은 개체를 여는 방법을 정의했음을 의미합니다.
  • 포함된 경험 – “스튜디오”(예: ADF, Synapse, SQL Studio, PBI 및 Dynamics)와 같은 경험을 가진 제품은 일반적으로 사용자가 상호 작용하려는 데이터를 검색하고 출력 데이터에 대한 위치를 찾을 수 있습니다. Microsoft Purview의 카탈로그는 임베딩 경험을 제공하여 이러한 경험을 가속화하는 데 도움이 될 수 있습니다. 이 경험은 파트너의 선택에 따라 API 또는 UX 수준에서 발생할 수 있습니다. Microsoft Purview에 대한 호출을 포함함으로써 조직은 Microsoft Purview의 데이터 자산 맵을 활용하여 데이터 자산을 찾고, 계보를 보고, 스키마를 확인하고, 등급, 연락처 등을 볼 수 있습니다.

질문 수집

조직이 높은 수준의 개체와 목표에 동의하면 여러 그룹에서 많은 질문을 받게 됩니다. 모든 문제를 해결하기 위한 계획을 세우려면 이러한 질문을 수집하는 것이 중요합니다. 이러한 질문을 수집할 때 관련 그룹을 포함해야 합니다. 설명서를 사용하여 답변을 시작할 수 있습니다.

초기 단계에서 발생할 수 있는 몇 가지 예제 질문은 다음과 같습니다.

대부분의 질문에 대한 답을 바로 얻지 못하더라도 질문을 수집하면 조직에서 이 프로젝트의 틀을 잡고 모든 "필수" 요구 사항을 충족할 수 있도록 도울 수 있습니다.

올바른 관련자 포함

조직 전체에 Microsoft Purview를 성공적으로 구현하려면 올바른 관련자를 참여시키는 것이 중요합니다. 초기 단계에는 소수의 사용자만 포함됩니다. 그러나 범위가 확장됨에 따라 프로젝트에 기여하고 피드백을 제공하기 위해 더 많은 가상 사용자가 필요합니다.

포함할 수 있는 주요 관련자는 다음과 같습니다.

가상 사용자 역할
최고 데이터 책임자 CDO는 데이터 관리, 데이터 품질, 마스터 데이터 관리, 데이터 과학, 비즈니스 인텔리전스 및 데이터 작성 전략을 포함할 수 있는 다양한 기능을 감독합니다. 이들은 Microsoft Purview 구현 프로젝트의 스폰서가 될 수 있습니다.
도메인/비즈니스 소유자 도구 사용량에 영향을 주고 예산을 제어하는 비즈니스 사용자입니다.
데이터 분석가 비즈니스 문제를 해결하고 데이터를 분석하여 리더가 비즈니스 의사 결정을 내리는 데 도움을 받을 수 있습니다.
데이터 아키텍트 데이터 보안 설계 및 구현과 함께 중요 업무용 LOB(기간 업무) 애플리케이션을 위한 데이터베이스를 설계합니다.
데이터 엔지니어 데이터 스택을 운영 및 유지 관리하고, 서로 다른 원본에서 데이터를 끌어오거나, 데이터를 통합 및 준비하고, 데이터 파이프라인을 설정합니다.
데이터 과학자 분석 모델을 빌드하고 API에서 액세스할 데이터 제품을 설정합니다.
DB 관리자 SLA(서비스 수준 계약) 내에서 데이터베이스 관련 인시던트 및 요청을 소유, 추적 및 해결합니다. 데이터 파이프라인을 설정할 수 있습니다.
DevOps LOB(기간 업무) 애플리케이션 개발 및 구현 스크립트 작성 및 오케스트레이션 기능이 포함될 수 있습니다.
데이터 보안 전문가 Microsoft Purview에서 들어오고 나가는 데이터와 관련된 전체 네트워크 및 데이터 보안을 평가합니다.

배포 모델

기본 사용 사례와 함께 Microsoft Purview를 사용하는 소규모 그룹이 하나뿐인 경우 방식은 전체 그룹에 서비스를 제공하는 하나의 Microsoft Purview 인스턴스를 갖는 것처럼 간단할 수 있습니다. 그러나 조직에 둘 이상의 Microsoft Purview 인스턴스가 필요한지 궁금할 수도 있습니다. 또한 여러 Microsoft Purview 인스턴스를 사용하는 경우 직원이 한 단계에서 다른 단계로 자산을 홍보할 수 있는 방법은 무엇인가요?

Microsoft Purview 인스턴스 수 결정

대부분의 경우 전체 조직에 대해 하나의 Microsoft Purview(이전의 Azure Purview) 계정만 있어야 합니다. 이 접근 방식은 플랫폼 내부에 상주하는 데이터의 함수에 따라 플랫폼의 가치가 기하급수적으로 증가하는 "네트워크 효과"를 최대한 활용합니다.

그러나 이 패턴에는 다음과 같은 예외 사항이 있습니다.

  1. 새 구성 테스트 – 조직은 격리된 환경에서 검사 구성 또는 분류를 테스트하기 위해 여러 인스턴스를 만들 수 있습니다. 용어집과 같은 플랫폼의 일부 영역에 “버전 관리” 기능이 있지만 “삭제 가능” 인스턴스를 사용하여 자유롭게 테스트하는 것이 더 쉬울 것입니다.
  2. 테스트, 사전 프로덕션 및 프로덕션 분리 – 조직은 서로 다른 환경에 저장된 다양한 종류의 데이터에 대해 서로 다른 플랫폼을 만들고 싶어 합니다. 이러한 형식의 데이터는 서로 다른 콘텐츠 형식이므로 권장되지 않습니다. 최상위 계층 수준 또는 범주에서 용어를 사용하여 콘텐츠 형식을 구분할 수 있습니다.
  3. Conglomerates 및 페더레이션된 모델 – Conglomerates에는 개별적으로 운영되는 많은 BU(사업부)가 있으며, 경우에 따라 다른 사용자와의 요금 청구도 공유하지 않습니다. 이러한 경우 조직은 각 BU에 대해 Microsoft Purview 인스턴스를 만들게 됩니다. 이 모델은 이상적이지는 않지만, 특히 BU가 청구를 공유하지 않기 때문에 필요할 수 있습니다.
  4. 규정 준수 – 메타데이터를 중요하게 취급하고 특정 지리에 필수적인 엄격한 규정 준수 체제가 있습니다. 회사에 여러 지역이 있는 경우 유일한 솔루션은 각 지역에 하나씩 여러 Microsoft Purview 인스턴스를 두는 것입니다.

자세한 내용은 계정 아키텍처 모범 사례 가이드 및 기본 계정 가이드를 참조하세요.

프로덕션으로 이동하는 프로세스 만들기

일부 조직에서는 Microsoft Purview의 단일 프로덕션 버전으로 작업하여 작업을 단순하게 유지하기로 결정할 수 있습니다. 발견, 검색 및 찾아보기 시나리오를 벗어날 필요가 없을 수 있습니다. 그러나 다양한 사업부에 Microsoft Purview를 배포하려는 대부분의 조직은 일종의 프로세스와 제어를 사용할 수 있습니다.

아래에는 각 단계에 대한 작업, 유용한 링크 및 수용 기준을 포함하는 잠재적인 4단계 배포 계획이 나와 있습니다.

  1. 1단계: 파일럿
  2. 2단계: 실행 가능한 최소 제품
  3. 3단계: 사전 프로덕션
  4. 4단계: 프로덕션

1단계: 파일럿

이 단계에서는 소수의 사용자를 위해 Microsoft Purview를 만들고 구성해야 합니다. 일반적으로 엔드투엔드 시나리오를 실행하기 위해 함께 작업하는 2~3명의 그룹일 뿐입니다. 그들은 조직에서 Microsoft Purview의 지지자로 간주됩니다. 이 단계의 주요 목표는 주요 기능을 충족하고 올바른 관련자가 프로젝트를 인식하도록 하는 것입니다.

완료해야 하는 작업

Task 세부 정보 Duration
요구 사항 수집 & 동의 모든 관련자와 함께 전체 요구 사항 집합을 수집하는 방법을 설명합니다. 각 가상 사용자는 프로젝트의 각 단계에서 완료할 요구 사항의 하위 집합에 동의하도록 참여해야 합니다. 1주
Microsoft Purview 거버넌스 포털 탐색 홈페이지에서 Microsoft Purview를 사용하는 방법을 이해합니다. 1일
계보용 ADF 구성 키 파이프라인 및 데이터 자산을 식별합니다. 내부 ADF 계정에 연결하는 데 필요한 모든 정보를 수집합니다. 1일
Azure Data Lake Storage Gen2 또는 SQL Server와 같은 데이터 원본을 검사합니다. 데이터 원본을 추가하고 검색을 설정합니다. 검사가 모든 자산을 성공적으로 검색하는지 확인합니다. 2일
검색 및 찾아보기 최종 사용자가 Microsoft Purview에 액세스하고 엔드투엔드 검색 및 찾아보기 시나리오를 수행할 수 있습니다. 1일

승인 기준

  • 조직 테넌트의 조직 구독에서 성공적으로 Microsoft Purview 계정을 만들었습니다.
  • 여러 역할을 가진 소규모 사용자 그룹이 Microsoft Purview에 액세스할 수 있습니다.
  • Microsoft Purview는 하나 이상의 데이터 원본을 검사하도록 구성됩니다.
  • 사용자는 다음과 같은 Microsoft Purview의 핵심 가치를 추출할 수 있어야 합니다.
    • 검색 및 찾아보기
    • 계보
  • 사용자는 자산 페이지에서 자산 소유권을 할당할 수 있어야 합니다.
  • 주요 관련자의 인식을 높이기 위한 프레젠테이션 및 데모입니다.
  • MVP 단계에 대한 추가 리소스를 승인하기 위해 경영진의 동의를 얻습니다.

2단계: 실행 가능한 최소 제품

합의된 요구 사항을 확보하고 Microsoft Purview를 온보딩하기 위해 사업부에 참여한 후 다음 단계는 MVP(최소 실행 가능 제품) 릴리스를 작업하는 것입니다. 이 단계에서는 수평 및 수직으로 더 많은 요구 사항이 있는 더 많은 사용자에게 Microsoft Purview 사용을 확장합니다. 용어집 용어, 검색 및 찾아보기와 같이 모든 사용자에 대해 수평적으로 충족되어야 하는 주요 시나리오가 있습니다. 또한 Azure Data Lake Storage에서 Azure Synapse DW, Power BI로의 계보와 같은 특정 엔드투엔드 시나리오를 다루기 위해 각 사업부 또는 그룹에 대한 심층적인 요구 사항이 있습니다.

완료해야 하는 작업

Task 세부 정보 Duration
Azure Synapse Analytics 검색 데이터베이스 원본을 온보딩하고 검색하여 핵심 자산 채우기 시작 2일
사용자 지정 분류 및 규칙 만들기 자산이 검사되면 사용자는 Microsoft Purview의 기본 분류 외에 더 많은 분류를 위한 다른 사용 사례가 있음을 알 수 있습니다. 2~4주
Power BI 검색 조직에서 Power BI 사용하는 경우 스토리지 레이어의 계보를 포함해야 하는 요구 사항이 있는 데이터 과학자 또는 데이터 분석가가 사용 중인 모든 데이터 자산을 수집하기 위해 Power BI를 검사할 수 있습니다. 1~2주
용어집 용어 가져오기 대부분의 경우 조직은 이미 자산에 대한 용어집 용어 및 용어 할당 컬렉션을 개발할 수 있습니다. 이를 위해서는 .csv 파일을 통해 Microsoft Purview로 가져오기 프로세스가 필요합니다. 1주
자산에 연락처 추가 상위 자산의 경우 다른 가상 사용자가 연락처를 할당하거나 REST API를 통해 가져올 수 있도록 하는 프로세스를 설정할 수 있습니다. 1주
중요한 레이블 및 검색 추가 Microsoft 365의 레이블링 사용에 따라 일부 조직에서는 선택 사항일 수 있습니다. 1~2주
분류 및 중요한 정보 얻기 Microsoft Purview의 보고 및 인사이트를 위해 이 기능에 액세스하여 다양한 보고서를 얻고 경영진에게 프레젠테이션을 제공할 수 있습니다. 1일
Microsoft Purview 관리 사용자를 사용하여 더 많은 사용자 온보딩 이 단계에서는 Microsoft Purview 관리자가 Azure Active Directory 관리자와 함께 작업하여 Microsoft Purview에 대한 액세스 권한을 부여할 새 보안 그룹을 설정해야 합니다. 1주

승인 기준

  • 대규모 사용자 그룹을 Microsoft Purview(50+)에 성공적으로 온보딩합니다.
  • 비즈니스에 중요한 데이터 원본 검색
  • 모든 중요 용어집 용어 가져오기 및 할당
  • 주요 자산에 대한 중요한 레이블 테스트 성공
  • 참가한 사업부 사용자에 대한 최소 시나리오 충족

3단계: 사전 프로덕션

MVP 단계가 통과되면 사전 프로덕션 마일스톤 계획을 세울 시간입니다. 조직은 사전 프로덕션 및 프로덕션을 위해 별도의 Microsoft Purview 인스턴스를 갖거나 동일한 인스턴스를 유지하지만, 액세스를 제한하기로 결정할 수 있습니다. 또한 이 단계에서는 SQL Server와 같은 온-프레미스 데이터 원본에 대한 검색을 포함하는 것이 좋습니다. Microsoft Purview에서 지원하지 않는 데이터 원본에 차이가 있는 경우 Atlas API를 탐색하여 다른 옵션을 이해해야 합니다.

완료해야 하는 작업

Task 세부 정보 Duration
검사 규칙 집합을 사용하여 검사 구체화 조직에는 사전 프로덕션을 위한 많은 데이터 원본이 있습니다. 분류 및 파일 확장자가 전체적으로 일관되게 적용될 수 있도록 검사에 대한 주요 기준을 미리 정의하는 것이 중요합니다. 1~2일
원본 페이지를 확인하여 각 원본에 대한 검사를 위한 지역 가용성 평가 데이터 원본의 지역과 규정 준수 및 보안에 대한 조직의 요구 사항에 따라 검색에 사용할 수 있는 지역을 고려할 수 있습니다. 1일
검색 시 방화벽 개념 이해 이 단계에서는 조직이 방화벽을 구성하는 방법과 Microsoft Purview가 검사를 위해 데이터 원본에 액세스하기 위해 자신을 인증할 수 있는 방법에 대한 탐색이 필요합니다. 1일
검색 시 Private Link 개념 이해 조직에서 Private Link를 사용하는 경우 요구 사항의 일부로 Private Link를 포함하도록 네트워크 보안의 기반을 마련해야 합니다. 1일
온-프레미스 SQL Server 검색 온-프레미스 SQL Server가 있는 경우 이 옵션은 선택 사항입니다. 검색을 수행하려면 자체 호스팅 통합 런타임을 설정하고 SQL Server를 데이터 원본으로 추가해야 합니다. 1~2주
통합 시나리오에 Microsoft Purview REST API 사용 Microsoft Purview를 오케스트레이션 또는 티켓팅 시스템과 같은 다른 타사 기술과 통합해야 하는 요구 사항이 있는 경우 REST API 영역을 탐색할 수 있습니다. 1~4주
Microsoft Purview 가격 책정 이해 이 단계에서는 조직이 결정을 내릴 수 있는 중요한 재무 정보를 제공합니다. 1~5일

승인 기준

  • 모든 사용자에게 하나 이상의 사업부를 성공적으로 온보딩
  • SQL Server와 같은 온-프레미스 데이터 원본 검색
  • REST API를 사용하는 하나 이상의 통합 시나리오 POC
  • 인프라 및 보안에 대한 주요 영역을 포함해야 하는 프로덕션으로 이동할 계획 완료

4단계: 프로덕션

더 나은 거버넌스 프로그램의 기반이 되는 효과적인 데이터 수명 주기 관리를 만들려면 위의 단계를 따라야 합니다. 데이터 거버넌스는 조직이 AI, Hadoop, IoT 및 블록체인과 같은 성장 추세에 대비하는 데 도움이 됩니다. 데이터 및 분석에 대한 많은 것의 시작일 뿐이며 더 많은 논의가 가능합니다. 이 솔루션의 결과는 다음을 제공합니다.

  • 비즈니스 중심 - 기술 요구 사항에 대한 비즈니스 요구 사항 및 시나리오에 부합하는 솔루션입니다.
  • 미래 지원 - 솔루션은 플랫폼의 기본 기능을 최대화하고 구성 또는 스크립팅 활동에 대해 표준화된 업계 사례를 사용하여 플랫폼의 발전/혁신을 지원합니다.

완료해야 하는 작업

Task 세부 정보 Duration
방화벽을 사용하는 프로덕션 데이터 원본 검색 방화벽이 있는 경우 이 옵션은 선택 사항이지만 인프라를 강화하기 위한 옵션은 탐색하는 것이 중요합니다. 1~5일
Private Link 사용 Private Link를 사용하는 경우 이 옵션은 선택 사항입니다. 비공개로 사용 설정되었을 경우 이 조건이 포함되어 있으므로 건너뛸 수 있습니다. 1~5일
자동화된 워크플로 만들기 워크플로는 승인, 에스컬레이션, 검토 및 문제 관리와 같은 프로세스를 자동화하는 데 중요합니다. 2~3주
운영 설명서 만들기 데이터 거버넌스는 일회용 프로젝트가 아닙니다. 데이터 기반 의사 결정을 수행하고 비즈니스 기회를 창출하는 지속적인 프로그램입니다. 주요 절차와 비즈니스 표준을 문서화하는 것이 중요합니다. 1주

승인 기준

  • 모든 사업부와 해당 사용자 온보딩
  • 프로덕션에 대한 인프라 및 보안 요구 사항 충족
  • 사용자에게 필요한 모든 사용 사례를 성공적으로 충족

플랫폼 보안 강화

더 많은 강화 단계를 수행할 수 있습니다.

  • 방화벽 리소스에 대한 검사를 사용하도록 설정하거나 Private Link를 사용하여 보안 상태 개선
  • 검색 성능을 향상시키기 위해 범위 검색 미세 조정
  • REST API를 사용하여 백업 및 복구를 위한 중요한 메타데이터 및 속성 내보내기
  • 워크플로를 사용하여 사용자 오류를 방지하는 티켓팅 및 이벤트 자동화
  • 정책을 사용하여 Microsoft Purview 거버넌스 포털을 통해 데이터 자산에 대한 액세스를 관리합니다.

수명 주기 고려 사항

프로덕션 프로세스에 포함해야 하는 또 다른 중요한 측면은 분류 및 레이블을 마이그레이션하는 방법입니다. Microsoft Purview에는 90개 이상의 시스템 분류자가 있습니다. 파일, 테이블 또는 열 자산에 시스템 또는 사용자 지정 분류를 적용할 수 있습니다. 분류는 주제 태그와 비슷하며 검사하는 동안 데이터 자산 내에 있는 특정 유형의 콘텐츠를 표시하고 식별하는 데 사용됩니다. 민감도 레이블은 조직 데이터 내에서 분류 형식의 범주를 식별하는 데 사용되며 각 범주에 적용할 정책을 그룹화합니다. Microsoft 365와 동일한 중요한 정보 유형을 사용하므로 전체 콘텐츠와 데이터 자산에서 기존 보안 정책 및 보호를 확장할 수 있습니다. 문서를 검색하고 자동으로 분류할 수 있습니다. 예를 들어 multiple.docx라는 파일이 있고 해당 콘텐츠에 국가 ID 번호가 있는 경우 Microsoft Purview는 자산 세부 정보 페이지에 EU 국가 식별 번호와 같은 분류를 추가합니다.

Microsoft Purview 데이터 맵에는 카탈로그 관리자가 수명 주기 동안 일관성 및 유지 관리 모범 사례를 보장해야 하는 여러 영역이 있습니다.

  • 데이터 자산 – 데이터 원본을 여러 환경에서 검색해야 합니다. 개발 중에만 검색한 다음 프로덕션 환경에서 API를 사용하여 다시 생성하는 것은 권장되지 않습니다. 주된 이유는 Microsoft Purview 스캐너가 데이터 자산의 배후에서 훨씬 더 많은 "배선"을 수행하기 때문에 다른 Microsoft Purview 인스턴스로 이동하는 것이 복잡할 수 있습니다. 프로덕션 환경에서는 동일한 데이터 원본을 추가하고 원본을 다시 검색하는 것이 훨씬 쉽습니다. 일반적인 모범 사례는 사용 중인 모든 검색, 연결 및 인증 메커니즘에 대한 설명서를 보유하는 것입니다.
  • 검색 규칙 집합 – 검색할 파일 형식 및 분류와 같은 특정 검색에 할당된 규칙의 컬렉션입니다. 검색 규칙 집합이 많지 않은 경우 프로덕션을 통해 다시 직접 만들 수 있습니다. 이렇게 하려면 내부 프로세스와 유용한 설명서가 필요합니다. 그러나 규칙 집합이 매일 또는 매주 변경되는 경우 REST API 경로를 탐색하여 해결할 수 있습니다.
  • 사용자 지정 분류 – 분류도 정기적으로 변경되지 않을 수 있습니다. 배포의 초기 단계에서 사용자 지정 분류를 만들기 위한 다양한 요구 사항을 이해하는 데 시간이 걸릴 수 있습니다. 그러나 일단 해결되면 약간의 변화가 필요합니다. 따라서 여기서 권장 사항은 사용자 지정 분류를 수동으로 마이그레이션하거나 REST API를 사용하는 것입니다.
  • 용어집 – UX를 통해 용어집 용어를 내보내고 가져올 수 있습니다. 자동화 시나리오의 경우 REST API를 사용할 수도 있습니다.
  • 리소스 집합 패턴 정책 – 이 기능은 일반적인 조직이 적용할 수 있는 고급 기능입니다. 경우에 따라 Azure Data Lake Storage에는 Microsoft Purview가 리소스 집합을 생성하는 데 문제를 일으킬 수 있는 폴더 명명 규칙과 특정 구조가 있습니다. 사업부는 비즈니스 요구 사항에 맞게 더 많은 사용자 지정을 사용하여 리소스 집합 구성을 변경하고자 할 수도 있습니다. 이 시나리오의 경우 REST API를 통해 모든 변경 사항을 추적하고 외부 버전 관리 플랫폼을 통해 변경 사항을 문서화하는 것이 가장 좋습니다.
  • 역할 할당 – 여기에서 Microsoft Purview에 액세스할 수 있는 사용자와 그들이 가지고 있는 권한을 제어할 수 있습니다. Microsoft Purview에는 사용자 및 역할의 내보내기 및 가져오기를 지원하는 REST API도 있지만 이는 Atlas API와 호환되지 않습니다. 대신 Azure 보안 그룹을 할당하고 그룹 멤버 자격을 관리하는 것이 좋습니다.

테넌트 이동

Microsoft Purview 계정이 있는 동안 Azure 구독이 테넌트로 이동하는 경우 새 Microsoft Purview 계정을 만들고 원본을 다시 등록하고 검사해야 합니다.

테넌트 이동은 현재 Microsoft Purview에서 지원되지 않습니다.

다음 단계