다음을 통해 공유

Power BI 구현 계획: 테넌트 수준 감사

  • 아티클

참고 항목

이 문서는 Power BI 구현 계획 시리즈의 일부를 구성합니다. 이 시리즈는 주로 Microsoft Fabric 내의 Power BI 환경에 중점을 둡니다. 시리즈에 대한 소개는 Power BI 구현 계획을 참조하세요.

이 테넌트 수준 감사 계획 문서는 주로 다음을 대상으로 합니다.

  • Power BI 관리자: 조직의 Power BI를 감독할 책임이 있는 관리자입니다. Power BI 관리자는 IT, 보안, 내부 감사, 기타 관련 팀과 협업이 필요할 수도 있습니다.
  • 우수성 센터, IT 및 BI 팀: Power BI를 감독할 책임도 있는 팀입니다. Power BI 관리자 및 기타 관련 팀과 협업해야 할 수도 있습니다.

Important

감사 및 모니터링 기능의 향후 개선 사항에 대해 알아보려면 Power BI 릴리스 계획을 면밀히 따르는 것이 좋습니다.

테넌트 수준 감사 솔루션의 목적은 Power BI 테넌트에 배포된 모든 사용자, 활동, 솔루션에 대한 데이터를 캡처하고 분석하는 것입니다. 이 테넌트 수준 감사 데이터는 채택 노력을 분석하고, 사용 패턴을 이해하고, 사용자를 교육하고, 사용자를 지원하고, 위험을 완화하고, 규정 준수를 개선하고, 라이선스 비용을 관리하고, 성능을 모니터링하는 등 다양한 용도에 유용합니다.

안전하고 프로덕션 준비가 완료된 엔드투엔드 감사 솔루션을 만드는 것은 시간이 걸리는 중요한 프로젝트입니다. BI 위의 BI, 즉 비즈니스 인텔리전스 위에 비즈니스 인텔리전스를 구축한다고 생각하면 됩니다. 감사 데이터가 중요한 이유에 대한 자세한 내용은 감사 및 모니터링 개요를 참조하세요.

보고서 작성자를 대상으로 하는 보고서 수준 감사에 대해서는 보고서 수준 감사를 참조하세요.

데이터 작성자를 대상으로 하는 데이터 자산 감사에 대해서는 데이터 수준 감사를 참조하세요.

이 문서의 나머지 부분에서는 테넌트 수준 감사에 중점을 둡니다.

팁

이 문서의 주요 초점은 엔드투엔드 감사 솔루션을 만드는 계획을 세우는 데 도움을 주는 것입니다. 이 문서의 내용은 4단계로 구성되어 있으며 여러 단계에 걸쳐 정보가 필요합니다. 예를 들어 1단계에서는 서비스 주체 사용 계획에 대한 정보를, 2단계에서는 필수 조건 및 설정에 대한 정보를 확인할 수 있습니다.

따라서 관련 내용을 숙지할 수 있도록 먼저 전체 문서를 읽어보는 것이 좋습니다. 그런 다음 반복적인 방식으로 감사 솔루션을 계획하고 구축할 준비가 되어 있어야 합니다.

테넌트 수준 감사 솔루션을 구축하려는 경우 다음 4가지 단계에 시간을 투자하도록 계획합니다.

1단계: 계획 및 결정 사항

첫 번째 단계는 계획과 의사 결정에 중점을 둡니다. 고려해야 할 요구 사항과 우선 순위가 많으므로 이 섹션에 소개된 주제를 이해하는 데 충분한 시간을 할애하는 것이 좋습니다. 목표는 다운스트림 단계가 원활하게 실행되도록 올바른 사전 결정을 내리는 것입니다.

테넌트 수준 감사 솔루션을 빌드하기 위한 계획 및 결정에 중점을 둔 1단계를 설명하는 흐름 다이어그램.

요구 사항 및 우선 순위

초기 단계의 목표는 가장 중요한 것이 무엇인지 파악하는 것입니다. 가장 중요한 것이 무엇인지와 조직에 미치는 영향을 어떻게 측정할 것인지에 중점을 둡니다. 기술 지향 요구 사항보다는 비즈니스 지향 요구 사항을 정의하려고 노력하세요.

다음은 답변해야 할 몇 가지 질문입니다.

  • 어떤 주요 질문에 대답해야 하나요? 탐색할 수 있는 많은 양의 감사 데이터가 있습니다. 감사에 접근하는 가장 효과적인 방법은 특정 질문에 답변하는 데 집중하는 것입니다.
  • 채택 및 데이터 문화 목표는 무엇인가요? 예를 들어 조직에서 셀프 서비스 BI 콘텐츠 작성자 수를 늘리려는 목표가 있을 수 있습니다. 이 경우 콘텐츠 만들기, 편집, 게시와 관련된 사용자 활동을 측정해야 합니다.
  • 어떤 즉각적인 위험이 있나요? 예를 들어 과거에 콘텐츠가 과도하게 공유된 적이 있다는 것을 알게 될 수도 있습니다. 이후 사용자 교육이 강화되었으며 이제 보안 설정 및 활동을 지속적으로 감사하려고 합니다.
  • 현재 KPI(핵심 성과 지표) 또는 조직 목표가 있나요? 예를 들어 디지털 혁신이나 데이터 기반 조직으로의 전환과 관련된 조직 KPI가 있을 수 있습니다. 테넌트 수준 감사 데이터는 Power BI 구현이 이러한 목표에 부합하는지 여부를 측정하는 데 도움이 될 수 있습니다.

팁

경영진 스폰서 및 우수성 센터와 함께 감사 요구 사항을 확인하고 우선 순위를 설정하세요. 감사 데이터를 추출하고 많은 흥미로운 데이터를 기반으로 보고서를 작성하고 싶은 유혹이 있을 것입니다. 그러나 답변해야 할 질문과 해야 하는 작업에 기반을 두지 않으면 감사 솔루션에서 높은 가치를 이끌어낼 가능성은 거의 없습니다.

감사 데이터를 사용하는 방법에 대한 자세한 내용은 감사 및 모니터링 개요를 참조하세요.

검사 목록 - 요구 사항 및 우선 순위 식별 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 요구 사항 식별: Power BI 테넌트 감사를 위한 주요 비즈니스 요구 사항을 수집하고 문서화합니다.
  • 요구 사항 우선 순위 지정: 요구 사항에 대한 우선 순위를 즉시, 단기, 중기, 장기(백로그)로 분류하여 설정합니다.
  • 즉각적인 우선 순위에 대한 계획 수립: 필요할 때 사용할 수 있도록 데이터 수집을 시작하기 위한 계획을 수립합니다.
  • 요구 사항을 정기적으로 재평가: 정기적으로 요구 사항을 재평가하는 계획을 수립합니다(예: 연 2회). 감사 및 모니터링 솔루션이 명시된 요구 사항을 충족하는지 확인합니다. 필요에 따라 계획의 작업 항목을 업데이트합니다.

데이터 요구 사항

요구 사항과 우선 순위(이전에 설명함)를 정의하고 나면 필요한 데이터를 식별할 준비가 된 것입니다. 이 섹션에서는 네 가지 범주의 데이터에 대해 설명합니다.

필요한 대부분의 데이터는 Power BI 테넌트에 대한 다양한 메타데이터를 제공하는 관리자 API에서 제공됩니다. 자세한 내용은 이 문서의 뒷부분에 있는 사용자 API 또는 관리자 API 선택을 참조하세요.

사용자 작업 데이터

사용자 활동에 대한 데이터를 얻는 것에 우선 순위를 두세요. 이벤트 또는 작업이라고도 하는 사용자 활동은 다양한 용도로 유용합니다.

대부분 해당 데이터를 활동 로그 또는 이벤트 로그라고 합니다. 기술적으로 사용자 작업 데이터를 얻는 방법에는 여러 가지가 있습니다(활동 로그가 한 가지 방법임). 관련된 결정 사항 및 작업에 대한 자세한 내용은 이 문서의 뒷부분에 있는 사용자 작업 데이터에 액세스를 참조하세요.

다음은 사용자 작업 데이터로 답변할 수 있는 몇 가지 일반적인 질문입니다.

  • 상위 사용자 및 상위 콘텐츠 찾기
    • 가장 자주 보는 콘텐츠는 무엇이며 어떤 사용자가 보나요?
    • 콘텐츠 보기에 대한 일별, 주별, 월별 추세는 어떤가요?
    • 보고서 뷰가 증가하는 추세인가요, 낮아지는 추세인가요?
    • 활성 사용자는 얼마나 많은가요?
  • 사용자 동작 이해
    • 가장 자주 사용되는 보안 유형(앱, 작업 영역 또는 항목별 공유)은 무엇인가요?
    • 사용자가 브라우저 또는 모바일 앱을 가장 자주 사용하나요?
    • 콘텐츠를 가장 적극적으로 게시하고 업데이트하는 콘텐츠 작성자는 누구인가요?
    • 어떤 콘텐츠가 언제 어떤 사용자에 의해 게시되거나 업데이트되나요?
  • 사용자 교육 및 학습 기회 식별
    • 누가 개인 작업 영역에서 너무 많이 공유하고 있나요?
    • 누가 내보내기를 많이 하나요?
    • 누가 정기적으로 콘텐츠를 다운로드하나요?
    • 누가 많은 새로운 의미 체계 모델을 게시하고 있습니까?
    • 누가 구독을 많이 사용하고 있나요?
  • 거버넌스 및 규정 준수 노력 개선
    • 테넌트 설정은 언제 어떤 Power BI 관리자에 의해 변경되나요?
    • 누가 Power BI 평가판을 시작했나요?
    • 외부 사용자가 액세스하는 콘텐츠는 무엇이며 누가, 언제, 어떻게 액세스하나요?
    • 민감도 레이블은 누가 추가하거나 업데이트하나요?
    • 인증된 의미 체계 모델을 기반으로 하는 보고서 뷰의 비율은 어느 정도인가요?
    • 두 개 이상의 보고서를 지원하는 의미 체계 모델의 비율은 어느 정도인가요?
    • 게이트웨이 또는 데이터 원본은 언제 어떤 사용자에 의해 만들어지거나 업데이트되나요?

이 데이터를 사용하는 방법에 대한 자세한 내용은 사용 패턴 이해를 참조하세요.

Important

아직 사용자 활동 데이터를 추출하고 저장하고 있지 않다면 이를 긴급한 우선 순위로 지정하세요. 최소한 원시 데이터를 추출하여 안전한 위치에 저장해야 합니다. 이렇게 하면 데이터를 분석할 준비가 되었을 때 데이터를 사용할 수 있습니다. 기록은 사용하는 원본에 따라 30일 또는 90일 동안 사용할 수 있습니다.

자세한 내용은 이 문서의 뒷부분에 있는 사용자 작업 데이터에 액세스를 참조하세요.

테넌트 인벤토리

종종 두 번째 우선 순위는 데이터를 검색하여 테넌트 인벤토리를 만드는 것입니다. 때로는 작업 영역 인벤토리, 작업 영역 메타데이터 또는 테넌트 메타데이터라고도 합니다.

테넌트 인벤토리는 특정 시점의 스냅샷입니다. 테넌트에 게시된 내용을 설명합니다. 테넌트 인벤토리에는 실제 데이터 또는 실제 보고서가 포함되지 않습니다. 오히려 모든 작업 영역과 해당 항목(예: 의미 체계 모델 및 보고서)을 설명하는 메타데이터입니다.

다음은 테넌트 인벤토리에서 답변할 수 있는 몇 가지 일반적인 질문입니다.

  • 보유하고 있는 콘텐츠의 양과 위치 파악
    • 콘텐츠가 가장 많은 작업 영역은 무엇인가요?
    • 특히 보고 작업 영역과 데이터 작업 영역을 분리하는 경우 각 작업 영역에는 어떤 유형의 콘텐츠가 게시되나요?
    • 항목(예: 많은 의미 체계 모델을 지원하는 데이터 흐름 또는 다른 복합 모델의 원본인 의미 체계 모델) 간에 어떤 종속성이 존재하나요?
    • 데이터 계보(외부 데이터 원본을 포함한 Power BI 항목 간의 종속성)는 무엇인가요?
    • 의미 체계 모델과 연결이 끊어진 분리된 보고서가 있나요?
  • 의미 체계 모델과 보고서의 비율 이해
    • 의미 체계 모델 재사용이 얼마나 발생하고 있나요?
    • 중복되거나 매우 유사한 의미 체계 모델이 있나요?
    • 의미 체계 모델을 통합할 기회가 있나요?
  • 시점 간 추세 이해
    • 시간이 지남에 따라 보고서 수가 증가하고 있나요?
    • 시간이 지남에 따라 의미 체계 모델 수가 증가하고 있나요?
  • 사용되지 않는 콘텐츠 찾기
    • 사용되지 않거나 활용도가 낮은 보고서는 무엇인가요?
    • 사용되지 않거나 활용도가 낮은 의미 체계 모델은 무엇인가요?
    • 콘텐츠를 사용 중지할 기회가 있나요?

테넌트 인벤토리는 기록 활동을 분석할 때 현재 이름을 사용하는 데 도움이 됩니다. 테넌트 항목의 스냅샷에는 해당 시점의 모든 항목 이름이 포함되어 있습니다. 기록 보고에 현재 항목 이름을 사용하는 것이 좋습니다. 예를 들어 보고서 이름이 3개월 전에 변경된 경우 해당 시점의 활동 로그에는 이전 보고서 이름이 기록됩니다. 올바르게 정의된 데이터 모델을 사용하면 최신 테넌트 인벤토리를 사용하여 이전 이름이 아닌 현재 이름으로 항목을 찾을 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 데이터 모델 만들기를 참조하세요.

테넌트 인벤토리를 사용하는 방법에 대한 자세한 내용은 게시된 콘텐츠 이해를 참조하세요.

팁

사용자 작업 이벤트(이전 섹션에 설명됨)와 테넌트 인벤토리를 결합하여 완전한 그림을 생성하는 경우가 많습니다. 이렇게 하면 모든 데이터의 가치가 향상됩니다.

테넌트 인벤토리는 특정 시점의 스냅샷이므로 메타데이터를 추출하고 저장하는 빈도를 결정해야 합니다. 주별 스냅샷은 두 시점을 비교하는 데 유용합니다. 예를 들어 작업 영역에 대한 보안 설정을 조사하려면 이전 테넌트 인벤토리 스냅샷, 활동 로그 이벤트, 현재 테넌트 인벤토리 스냅샷이 필요합니다.

테넌트 인벤토리를 구축하는 두 가지 주요 방법이 있습니다. 관련된 결정 및 활동에 대한 자세한 내용은 이 문서의 뒷부분에 있는 테넌트 인벤토리 데이터에 액세스를 참조하세요.

사용자 및 그룹 데이터

분석 요구 사항이 증가함에 따라 엔드투엔드 감사 솔루션에 사용자 및 그룹에 대한 데이터를 포함하기로 결정하게 될 것입니다. 해당 데이터를 검색하려면 Microsoft Entra ID 사용자 및 그룹에 대한 정보에 대한 신뢰할 수 있는 원본인 Microsoft Graph를 사용할 수 있습니다.

Power BI REST API에서 검색된 데이터에는 사용자를 설명하는 메일 주소 또는 보안 그룹 이름이 포함되어 있습니다. 이 데이터는 특정 시점의 스냅샷입니다.

다음은 Microsoft Graph에서 답변할 수 있는 몇 가지 일반적인 질문입니다.

  • 사용자 및 그룹 식별
    • 사용자 프로필에서 가져온 전체 사용자 이름(메일 주소 포함), 부서 또는 위치는 무엇인가요?
    • 보안 그룹의 멤버는 누구인가요?
    • 멤버를 관리하기 위한 보안 그룹의 소유자는 누구인가요?
  • 추가 사용자 정보 얻기
    • Power BI Pro 또는 PPU(사용자 단위 Power BI Premium) 중 어떤 라이선스가 사용자에게 할당되나요?
    • 가장 자주 로그인하는 사용자는 누구인가요?
    • 최근에 Power BI 서비스에 로그인하지 않은 사용자는 누구인가요?

Warning

온라인에 광범위하게 문서화되어 있는 사용자 및 그룹 데이터에 액세스하기 위한 일부 이전 방법은 더 이상 사용되지 않으므로 사용해서는 안 됩니다. 가능하다면 Microsoft Graph를 사용자 및 그룹 데이터의 신뢰할 수 있는 원본으로 사용하세요.

Microsoft Graph의 데이터에 액세스하는 방법에 대한 자세한 내용과 권장 사항은 이 문서의 뒷부분에 있는 사용자 및 그룹 데이터에 액세스를 참조하세요.

보안 데이터

정기적인 보안 감사를 수행해야 할 수도 있습니다.

다음은 Power BI REST API가 답변할 수 있는 몇 가지 일반적인 질문입니다.

Important

때때로 이 문서는 Power BI Premium 또는 P SKU(프리미엄 용량 구독)를 언급합니다. Microsoft는 현재 구매 옵션을 통합하고 용량당 Power BI Premium SKU를 사용 중지하고 있습니다. 신규 및 기존 고객은 대신 F SKU(Fabric 용량 구독)로 구매를 고려해야 합니다.

자세한 내용은 Power BI Premium 라이선싱 관련 중요 업데이트 및 Power BI Premium FAQ를 참조하세요.

팁

보안에 대한 추가 고려 사항은 보안 계획 문서를 참조하세요.

이러한 일반적인 질문은 완전한 목록이 아니며 다양한 Power BI REST API를 사용할 수 있습니다. 자세한 내용은 Power BI REST API 사용을 참조하세요.

관리자 API와 사용자 API 사용에 대한 자세한 내용(데이터를 추출하는 사용자에게 필요한 권한에 미치는 영향 포함)은 이 문서의 뒷부분에 있는 사용자 API 또는 관리자 API 선택을 참조하세요.

검사 목록 - 감사에 필요한 데이터 식별 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 사용자 작업 데이터에 대한 특정 데이터 요구 사항 식별: 수집한 요구 사항을 확인합니다. 사용자 작업 데이터에 대한 각 요구 사항을 충족하는 데 필요한 감사 데이터를 식별합니다.
  • 테넌트 인벤토리 데이터에 대한 특정 데이터 요구 사항 식별: 수집한 요구 사항을 확인합니다. 테넌트 인벤토리를 컴파일하는 데 필요한 감사 데이터를 식별합니다.
  • 사용자 및 그룹 데이터에 대한 특정 데이터 요구 사항 식별: 수집한 요구 사항을 확인합니다. 사용자 및 그룹 데이터에 대한 각 요구 사항을 충족하는 데 필요한 감사 데이터를 식별합니다.
  • 보안 데이터에 대한 특정 데이터 요구 사항 식별: 수집한 요구 사항을 확인합니다. 보안 데이터에 대한 각 요구 사항을 충족하는 데 필요한 감사 데이터를 식별합니다.
  • 우선 순위 확인: 무엇을 먼저 개발해야 할지 알 수 있도록 우선 순위를 확인하세요.
  • 작업 캡처 빈도 결정: 작업 이벤트 캡처 빈도(예: 하루에 한 번)를 결정합니다.
  • 스냅샷 캡처 빈도 결정: 테넌트 인벤토리, 사용자, 그룹 데이터 등 스냅샷 데이터를 캡처할 간격을 결정합니다.

감사 솔루션 유형

테넌트 수준 감사는 수동으로 또는 자동화된 프로세스를 통해 수행됩니다.

대부분의 새로운 감사 프로세스는 특히 개발 및 테스트가 진행되는 동안 수동 프로세스로 시작됩니다. 수동 감사 프로세스는 자동화된 프로세스로 발전할 수 있습니다. 그러나 모든 감사 프로세스를 완전히 자동화할 필요는 없습니다.

수동 감사 프로세스

수동 감사는 사용자(일반적으로 Power BI 관리자)가 요청 시 실행하는 스크립트 및 프로세스에 의존합니다. 필요한 경우 사용자는 대화형으로 쿼리를 실행하여 감사 데이터를 검색합니다.

수동 감사는 다음과 같은 경우에 가장 적합합니다.

  • 개발 및 테스트 중인 새로운 스크립트.
  • 가끔 일회성 감사가 필요한 경우.
  • 탐색적 감사가 필요한 경우.
  • 완전한 지원이 필요하지 않은 필수적이지 않은 감사 프로세스.

자동화된 감사 프로세스

반복적으로 필요한 감사 데이터는 자동화되어야 합니다. 정기적인 일정에 따라 추출되고 처리되며 이를 자동화된 프로세스라고 합니다. 때로는 이를 무인 프로세스라고도 합니다.

자동화된 프로세스의 목표는 수동 작업을 줄이고, 오류 위험을 줄이고, 일관성을 높이고, 프로세스를 실행하는 개별 사용자에 대한 의존성을 제거하는 것입니다.

자동화된 감사는 다음과 같은 경우에 가장 적합합니다.

  • 프로덕션에서 실행되는 감사 프로세스.
  • 정기적인 일정에 따라 실행되는 무인 프로세스.
  • 완전히 테스트된 스크립트.
  • 데이터 원본으로 의존하는 다른 보고서(또는 다른 프로세스)가 있는 필수 감사 프로세스.
  • 문서화되고 지원되는 감사 프로세스.

수동 또는 자동 프로세스 유형에 따라 인증 처리 방법이 달라질 수 있습니다. 예를 들어 Power BI 관리자는 수동 감사 프로세스에는 사용자 인증을 사용하고 자동화된 프로세스에는 서비스 주체를 사용할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 인증 방법 결정을 참조하세요.

팁

현재 수동으로 처리되는 정기적이고 반복적인 감사 데이터를 가져와야 하는 경우 시간을 투자하여 자동화하는 것을 고려하세요. 예를 들어 Power BI 관리자가 매일 수동으로 스크립트를 실행하여 Power BI 활동 로그에서 데이터를 검색한다면 해당 사람이 아프거나 휴가 중인 경우 데이터가 누락될 위험이 있습니다.

검사 목록 - 개발할 감사 솔루션 유형을 고려 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 각 새로운 감사 요구 사항의 기본 목적을 결정합니다. 각 새로운 요구 사항에 대해 수동 프로세스를 사용할지 아니면 자동화된 프로세스를 사용할지 결정합니다. 해당 결정이 일시적인지 영구적인지를 고려합니다.
  • 자동화 방법에 대한 계획 수립: 특정 감사 요구 사항에 적합한 경우 자동화 방법, 시기, 대상에 대한 계획을 수립합니다.

권한 및 책임

이 시점에서는 달성하려는 작업과 처음에 필요한 데이터에 대한 명확한 아이디어가 있어야 합니다. 이제 사용자 권한은 물론 역할과 책임에 대해서도 결정을 내릴 시기입니다.

사용자 권한

엔드투엔드 감사 솔루션을 구축할 계획이라면 데이터에 액세스해야 하는 다른 사용자에 대한 사용자 권한을 고려하세요. 특히 감사 데이터에 액세스하고 볼 수 있는 사람을 결정합니다.

다음은 고려해야 할 몇 가지 사항입니다.

감사 데이터에 직접 액세스

감사 데이터에 직접 액세스할 수 있는 사용자를 결정해야 합니다. 여러 가지 방법으로 생각할 수 있습니다.

  • Power BI 관리자는 누가 되어야 하나요? Power BI 관리자는 관리자 API를 포함한 모든 테넌트 메타데이터에 액세스할 수 있습니다. Power BI 관리자가 될 사람을 결정하는 방법에 대한 자세한 내용은 테넌트 수준 보안 계획을 참조하세요.
  • 기존 서비스 주체를 누가 사용할 수 있나요? 사용자 권한 대신 서비스 주체를 사용하여 감사 데이터에 액세스하려면 권한 있는 사용자가 암호 기반 인증을 수행할 수 있도록 암호를 제공해야 합니다. 비밀(및 키)에 대한 액세스는 매우 엄격하게 제어되어야 합니다.
  • 액세스를 엄격하게 제어해야 하나요? 규제 및 규정 준수 요구 사항이 있는 특정 업계는 다른 업계보다 액세스를 더 엄격하게 제어해야 합니다.
  • 작업 데이터 볼륨이 크나요? API 제한 한도에 도달하지 않도록 감사 데이터를 생성하는 API에 직접 액세스할 수 있는 사람을 엄격하게 제어해야 할 수도 있습니다. 이 경우 중복되거나 겹치는 노력이 없는지 확인하는 것이 유용합니다.
추출된 원시 데이터에 대한 액세스

추출되어 스토리지 위치에 기록된 원시 데이터를 볼 수 있는 사람을 결정해야 합니다. 가장 일반적으로 원시 데이터에 대한 액세스는 관리자와 감사자로 제한됩니다. COE(우수성 센터)에도 액세스 권한이 필요할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 감사 데이터 저장 위치 결정을 참조하세요.

큐레이팅된 분석 데이터에 대한 액세스

분석 준비가 완료되고 큐레이팅 및 변환된 데이터를 볼 수 있는 사람을 결정해야 합니다. 이 데이터는 관리자와 감사자가 항상 사용할 수 있어야 합니다. 특히 행 수준 보안이 포함된 Power BI 의미 체계 모델을 만들 때 조직의 다른 사용자가 데이터 모델을 사용할 수 있는 경우가 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 큐레이팅된 데이터 만들기 계획을 참조하세요.

역할 및 책임

사용자 권한의 작동 방식을 결정했으면 역할 및 책임에 대해 생각해 볼 수 있는 좋은 위치에 있습니다. 특히 여러 개발자나 팀이 엔드투엔드 감사 솔루션을 구축하는 데 참여할 경우 초기에 적절한 사람들을 참여하게 하는 것이 좋습니다.

다음 활동을 담당할 사용자 또는 팀을 결정합니다.

역할 책임 유형 일반적으로 수행하는 역할
관련자와 통신 커뮤니케이션 활동 및 요구 사항 수집. IT와 협력하는 COE. 주요 사업부에서 선별된 사용자도 포함될 수 있습니다.
우선 순위 결정 및 요구 사항에 대한 방향 제공 요구 사항을 충족하는 방법을 포함하여 엔드투엔드 감사 솔루션과 관련된 의사 결정 활동. COE와 같이 조직에서 Power BI를 감독하는 팀. 경영진 스폰서 또는 데이터 거버넌스 운영 위원회가 중요한 결정을 내리거나 문제를 에스컬레이션하는 데 참여할 수 있습니다.
원시 데이터 추출 및 저장 데이터에 접근하고 추출하기 위한 스크립트와 프로세스 만들기. 또한 원시 데이터를 스토리지에 쓰는 작업도 포함. 일반적으로 IT 팀에서 COE와 협력하는 데이터 엔지니어링 직원.
큐레이팅된 데이터 만들기 별모양 스키마 디자인에서 데이터 정리, 변환, 큐레이팅된 데이터 만들기. 일반적으로 IT 팀에서 COE와 협력하는 데이터 엔지니어링 직원.
데이터 모델 만들기 큐레이팅된 데이터를 기반으로 분석 데이터 모델 만들기. 일반적으로 IT 또는 COE에 있는 Power BI 콘텐츠 작성자.
분석 보고서 만들기 큐레이팅된 데이터를 분석하는 보고서 만들기. 새로운 요구 사항과 새로운 감사 데이터를 사용할 수 있게 되면 보고서를 지속적으로 변경. 일반적으로 IT 또는 COE에 있는 Power BI 보고서 작성자.
데이터 분석 및 결과에 대한 작업 데이터를 분석하고 감사 데이터에 대응하여 작업. 조직에서 Power BI를 감독하는 팀(일반적으로 COE). 감사 결과 및 조치에 따라 다른 팀이 포함될 수도 있음. 다른 팀에는 보안, 규정 준수, 법률, 위험 관리 또는 변경 관리가 포함될 수 있음.
테스트 및 유효성 검사 감사 요구 사항이 충족되고 제공된 데이터가 정확한지 테스트. Power BI 콘텐츠 작성자는 조직의 Power BI를 감독하는 팀과 협력.
데이터 보호 원시 데이터와 큐레이팅된 데이터를 포함하여 각 스토리지 계층에 대한 보안 설정 및 관리. 데이터 분석을 위해 만든 의미 체계 모델에 대한 액세스 관리. 조직에서 Power BI를 감독하는 팀과 협력하여 데이터를 저장하는 시스템의 시스템 관리자.
예약 및 자동화 솔루션을 운용하고 선택한 도구를 사용하여 프로세스 예약. 일반적으로 IT 팀에서 COE와 협력하는 데이터 엔지니어링 직원.
솔루션 지원 작업 실행, 오류 및 기술 문제에 대한 지원을 포함하여 감사 솔루션 모니터링. Power BI 시스템 지원을 처리하는 팀(일반적으로 IT 또는 COE).

위의 역할과 책임 중 다수는 동일한 팀이나 동일한 사람이 수행할 경우 통합될 수 있습니다. 예를 들어 Power BI 관리자는 이러한 역할 중 일부를 수행할 수 있습니다.

상황에 따라 다른 사람들이 다른 역할을 수행하는 것도 가능합니다. 작업은 감사 데이터 및 제안된 작업에 따라 상황에 맞게 달라집니다.

몇 가지 예를 생각해 보세요.

  • 예제 1: 감사 데이터에 따르면 일부 사용자는 데이터를 Excel로 자주 내보내는 것으로 나타났습니다. 수행된 작업: COE는 특정 사용자에게 연락하여 사용자의 요구 사항을 이해하고 더 나은 대안을 교육합니다.
  • 예제 2: 감사 데이터는 외부 사용자 액세스가 예상치 못한 방식으로 발생함을 보여 줍니다. 수행된 작업: IT 시스템 관리자는 외부 사용자 액세스에 대한 관련 Microsoft Entra ID 설정을 업데이트합니다. Power BI 관리자는 외부 사용자 액세스와 관련된 테넌트 설정을 업데이트합니다. COE는 보안을 관리하는 콘텐츠 작성자를 위한 문서 및 교육을 업데이트합니다. 자세한 내용은 외부 사용자를 위한 전략을 참조하세요.
  • 예제 3: 감사 데이터는 여러 데이터 모델이 동일한 측정값을 다르게 정의함을 보여 줍니다(상세 메타데이터 테넌트 설정에서 허용하는 경우 메타데이터 검색 API에서 사용 가능). 수행된 작업: 데이터 거버넌스 위원회는 일반적인 정의를 정의하는 프로젝트를 시작합니다. COE는 데이터 모델을 만드는 콘텐츠 작성자를 위한 문서 및 교육을 업데이트합니다. COE는 또한 콘텐츠 작성자와 협업하여 적절하게 모델을 업데이트합니다. 자세한 메타데이터 검색에 대한 자세한 내용은 이 문서의 뒷부분에 있는 테넌트 인벤토리 데이터에 액세스를 참조하세요.

참고 항목

데이터 추출 프로세스 설정은 일반적으로 일시적인 개선 및 문제 해결이 포함된 일회성 작업입니다. 데이터를 분석하고 이에 따라 작업하는 것은 지속적인 노력이 반복적으로 필요한 작업입니다.

검사 목록 - 권한과 책임 고려 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 관련된 팀 식별: 감사 솔루션의 엔드투엔드 만들기 및 지원에 참여할 팀을 결정합니다.
  • 사용자 권한 결정: 감사 데이터에 액세스하기 위해 사용자 권한을 설정하는 방법을 결정합니다. 나중에 참조할 수 있도록 주요 결정에 대한 문서를 만듭니다.
  • 역할 및 책임 결정: 특히 여러 팀이 참여하는 경우 누가 무엇을 하는지에 대한 기대치가 명확해야 합니다. 예상되는 작업을 포함한 역할과 책임에 대한 문서를 작성합니다.
  • 역할 및 책임 할당: 특정 사람이나 팀에 특정 역할과 책임을 할당합니다. 적절한 경우 인사부에 개별 직무 설명을 업데이트합니다.
  • 교육 계획 수립: 새로운 기술이 필요한 직원 교육 계획을 수립합니다.
  • 교차 교육 계획 수립: 핵심 역할에 대한 교차 교육 및 백업이 준비되어 있는지 확인합니다.

기술 결정 사항

테넌트 수준 감사 솔루션을 계획하는 경우 몇 가지 중요한 기술 결정을 내려야 합니다. 일관성을 개선하고, 재작업을 방지하고, 보안을 강화하려면 가능한 한 빨리 이러한 결정을 내리는 것이 좋습니다.

첫 번째 계획 단계에서는 다음과 같은 결정을 내립니다.

감사 데이터에 액세스할 기술 선택

가장 먼저 결정해야 할 것은 감사 데이터에 액세스하는 방법입니다.

시작하는 가장 쉬운 방법은 관리 모니터링 작업 영역에서 제공되는 사전 구축된 보고서를 사용하는 것입니다.

데이터에 직접 액세스하고 고유한 솔루션을 구축해야 하는 경우 API(애플리케이션 프로그램 인터페이스)를 사용하게 됩니다. API는 인터넷을 통해 데이터를 교환하도록 설계되었습니다. Power BI REST API는 HTTP 프로토콜을 사용하여 데이터 요청을 지원합니다. 모든 언어 또는 도구는 HTTP 요청을 보내고 JSON 응답을 받을 수 있는 경우 Power BI REST API를 호출할 수 있습니다.

팁

PowerShell cmdlet은 Power BI REST API를 사용하여 감사 데이터에 액세스합니다. 자세한 내용은 이 문서의 뒷부분에 있는 API 또는 PowerShell cmdlet 선택을 참조하세요.

이 섹션에서는 기술 선택에 중점을 둡니다. 특정 유형의 감사 데이터에 액세스하기 위한 원본에 대한 고려 사항은 이 문서 뒷부분의 데이터 원본 결정을 참조하세요.

플랫폼 옵션

감사 데이터에 액세스하는 방법에는 여러 가지가 있습니다. 선택하는 기술에 따라 기본 설정 언어가 달라질 수 있습니다. 스크립트 실행을 예약하는 방법에 대해 구체적인 결정을 내려야 할 수도 있습니다. 기술마다 학습 곡선과 시작하기 쉬운 정도가 크게 다릅니다.

Power BI REST API를 사용하여 데이터를 검색하는 데 사용할 수 있는 몇 가지 기술은 다음과 같습니다.

기술 수동 감사 프로세스에 적합한 선택 자동화된 감사 프로세스에 적합한 선택
관리 모니터링 작업 영역 관리자 모니터링 작업 영역은 수동 감사 프로세스에 적합한 선택입니다.
Try-it 사용해 보기는 수동 감사 프로세스에 적합한 선택입니다.
PowerShell PowerShell은 수동 감사 프로세스에 적합한 선택입니다. PowerShell은 자동화된 감사 프로세스에 적합한 선택입니다.
Power BI Desktop Power BI Desktop은 수동 감사 프로세스에 적합한 선택입니다.
Power Automate Power Automate는 자동화된 감사 프로세스에 적합한 선택입니다.
기본 설정 Azure 서비스 기본 Azure 서비스는 자동화된 감사 프로세스에 적합한 선택입니다.
기본 설정 도구/언어 기본 도구/언어는 수동 감사 프로세스에 적합한 선택입니다. 기본 도구/언어는 자동화된 감사 프로세스에 적합한 선택입니다.
Microsoft Purview 감사 로그 검색 Microsoft Purview 감사 로그 검색은 수동 감사 프로세스에 적합한 선택입니다.
클라우드용 Defender 앱 Defender for Cloud Apps는 수동 감사 프로세스에 적합한 선택입니다.
Microsoft Sentinel Microsoft Sentinel은 자동화된 감사 프로세스에 적합한 선택입니다.

이 섹션의 나머지 부분에서는 테이블에 제시된 각 옵션에 대해 간략하게 소개합니다.

관리 모니터링 작업 영역

관리자 모니터링 작업 영역에는 Power BI 서비스의 사전 정의된 보고서와 의미 체계 모델이 포함되어 있습니다. 이는 패브릭 관리자가 최근 감사 데이터를 보고 사용자 활동을 이해하는 데 도움이 되는 편리한 방법입니다.

API 설명서에서 사용해 보기

Try-it은 Microsoft 문서에서 Power BI REST API를 직접 경험할 수 있는 대화형 도구입니다. 다른 도구나 컴퓨터 설정이 필요하지 않으므로 API를 쉽게 탐색할 수 있습니다.

Try-it을 사용하여 다음을 수행할 수 있습니다.

  • API에 요청을 수동으로 보내 원하는 정보를 반환하는지 여부를 확인합니다.
  • 스크립트를 작성하기 전에 URL이 어떻게 구성되는지 알아봅니다.
  • 비공식적인 방식으로 데이터를 확인합니다.

참고 항목

Try-it을 사용하려면 라이선스가 있고 인증된 Power BI 사용자여야 합니다. 이는 표준 권한 모델을 따릅니다. 즉, 사용자 API는 사용자 권한에 의존하고 관리자 API에는 Power BI 관리자 권한이 필요합니다. 서비스 주체를 사용하여 Try-it으로 인증할 수 없습니다.

대화형이므로 Try-it은 학습, 탐색, 새로운 수동 감사 프로세스에 가장 적합합니다.

PowerShell 및 Azure Cloud Shell

다양한 방법으로 PowerShell 스크립트를 만들고 실행할 수 있습니다.

다음은 몇 가지 일반적인 옵션입니다.

  • Visual Studio Code: 현대적이고 가벼운 소스 코드 편집기입니다. Windows, macOS, Linux를 포함한 여러 플랫폼에서 지원되는 무료로 사용 가능한 오픈 소스 도구입니다. PowerShell(PowerShell 확장 사용)을 포함하여 다양한 언어로 Visual Studio Code를 사용할 수 있습니다.
  • Azure Data Studio: 스크립트와 Notebook을 만들기 위한 도구입니다. Visual Studio Code를 기반으로 구축되었습니다. Azure Data Studio는 독립적으로 사용하거나 SSMS(SQL Server Management Studio)와 함께 사용할 수 있습니다. PowerShell용 확장을 포함하여 다양한 확장이 있습니다.
  • Azure Cloud Shell: 로컬에서 PowerShell을 사용하는 대신 사용할 수 있습니다. 브라우저에서 Azure Cloud Shell에 액세스할 수 있습니다.
  • Azure Functions: 로컬에서 PowerShell을 사용하는 대신 사용할 수 있습니다. Azure Functions는 서버리스 환경에서 코드를 작성하고 실행할 수 있는 Azure 서비스입니다. PowerShell은 지원하는 여러 언어 중 하나입니다.

Important

모든 새로운 개발 작업에는 PowerShell(PowerShell Core)의 최신 버전을 사용하는 것이 좋습니다. PowerShell Core를 실행할 수 없는 Windows PowerShell 사용을 중단하고 대신 PowerShell Core를 지원하는 최신 코드 편집기 중 하나를 사용해야 합니다. Windows PowerShell(버전 5.1)을 사용하는 많은 온라인 예제를 참조할 때는 더 나은 최신 코드 방법을 사용하지 않을 수 있으므로 주의하세요.

여러 가지 방법으로 PowerShell을 사용할 수 있습니다. 이러한 기술적 결정에 대한 자세한 내용은 이 문서의 뒷부분에 있는 API 또는 PowerShell cmdlet 선택을 참조하세요.

PowerShell 사용을 위한 온라인 리소스가 많이 있으며 PowerShell 솔루션을 만들고 관리할 수 있는 숙련된 개발자를 찾을 수 있는 경우도 종종 있습니다. PowerShell은 수동 및 자동화된 감사 프로세스를 만드는 데 적합합니다.

Power BI Desktop

Power BI Desktop은 API에 연결할 수 있으므로 감사 솔루션을 구축하는 데 사용하고 싶을 수 있습니다. 그러나 몇 가지 중요한 단점과 복잡성이 있습니다.

  • 누적 기록: Power BI 활동 로그는 최대 30일의 데이터를 제공하므로 전체 감사 솔루션을 만들려면 모든 기록 이벤트를 저장하는 파일 집합을 시간이 지남에 따라 축적해야 합니다. 다른 도구를 사용하면 기록 파일을 축적하는 것이 더 간단합니다.
  • 자격 증명 및 키를 안전하게 처리: 커뮤니티 블로거가 온라인에서 찾는 많은 솔루션은 파워 쿼리의 쿼리 내 일반 텍스트로 자격 증명과 키를 하드 코딩하므로 안전하지 않습니다. 이 방법은 간편하지만 Power BI Desktop 파일을 가져오는 모든 사용자가 값을 읽을 수 있으므로 권장되지 않습니다. 다음을 수행하지 않는 한 암호(사용자 인증을 사용하는 경우) 또는 비밀(서비스 주체를 사용하는 경우)을 Power BI Desktop에 안전하게 저장할 수 없습니다.
    • 파워 쿼리 SDK로 개발된 사용자 지정 커넥터를 사용하세요. 예를 들어 사용자 지정 커넥터는 암호화된 값을 안전하게 저장하는 Azure Key Vault 또는 다른 서비스에서 기밀 값을 읽을 수 있습니다. 글로벌 Power BI 커뮤니티에서 사용할 수 있는 다양한 사용자 지정 커넥터 옵션도 있습니다.
    • Power BI Desktop에서 잘 작동하는 ApiKeyName 옵션을 사용하세요. 그러나 Power BI 서비스에는 키 값을 저장할 수 없습니다.
  • 요청 유형: Power BI Desktop에서 실행할 수 있는 작업에 대해 몇 가지 제한이 발생할 수 있습니다. 예를 들어 파워 쿼리는 모든 유형의 API 요청을 지원하지 않습니다. 예를 들어 Web.Contents 함수를 사용할 때는 GET 및 POST 요청만 지원됩니다. 감사를 위해 일반적으로 GET 요청을 보냅니다.
  • 새로 고침 기능: Power BI 서비스에서 의미 체계 모델을 성공적으로 새로 고치려면 특정 파워 쿼리 개발 패턴을 따라야 합니다. 예를 들어 Power BI가 Power BI 서비스에서 오류를 생성하지 않고 데이터 원본의 위치를 올바르게 확인할 수 있도록 Web.Contents를 사용할 때 RelativePath 옵션이 있어야 합니다.

대부분의 경우 두 가지 목적으로만 Power BI Desktop을 사용하는 것이 좋습니다. 다음과 같은 용도로 사용해야 합니다.

  • 처음에 감사 데이터를 추출하는 데 사용하는 대신 기존에 큐레이팅된 데이터를 기반으로 데이터 모델을 구축합니다.
  • 데이터 모델을 기반으로 분석 보고서를 만듭니다.
Power Automate

Power BI와 함께 다양한 방법으로 Power Automate를 사용할 수 있습니다. 감사와 관련하여 Power Automate를 사용하여 Power BI REST API에 요청을 보낸 다음 추출된 데이터를 선택한 위치에 저장할 수 있습니다.

팁

Power BI REST API에 요청을 보내려면 Power Automate용 사용자 지정 커넥터를 사용하여 감사 데이터를 안전하게 인증하고 추출할 수 있습니다. 또는 Azure Key Vault를 사용하여 암호 또는 비밀을 참조할 수 있습니다. 두 옵션 모두 Power Automate 흐름 내에서 일반 텍스트로 암호와 비밀을 저장하는 것보다 낫습니다.

Power Automate 사용 방법에 대한 다른 아이디어를 보려면 Power Automate 템플릿에서 Power BI를 검색하세요.

기본 설정 Azure 서비스

Power BI REST API에 요청을 보낼 수 있는 여러 가지 Azure 서비스가 있습니다. 다음과 같이 기본 설정 Azure 서비스를 사용할 수 있습니다.

대부분의 경우 데이터 추출 논리를 처리하는 컴퓨팅 서비스와 원시 데이터(및 적절한 경우 큐레이팅된 데이터)를 저장하는 스토리지 서비스를 결합할 수 있습니다. 기술 아키텍처 결정을 내릴 때 고려할 사항은 이 문서의 뒷부분에 설명되어 있습니다.

기본 설정 도구 및/또는 언어

기본 설정 도구 및 기본 설정 언어를 사용하여 Power BI REST API에 요청을 보낼 수 있습니다. 이는 팀이 다음과 같은 특정 도구나 언어에 대한 전문 지식을 보유한 경우 좋은 방법입니다.

  • Python
  • .NET 프레임워크의 C#. 일부 프로세스를 간소화하고 생산성을 높이기 위해 Power BI REST API 위에서 래퍼 역할을 하는 Power BI .NET SDK를 사용할 수 있습니다(선택 사항).
  • JavaScript

Microsoft Purview 규정 준수 포털(이전의 Microsoft 365 규정 준수 센터)에는 감사 로그를 보고 검색할 수 있는 사용자 인터페이스가 포함되어 있습니다. 통합 감사 로그에는 Power BI 및 Microsoft 365 통합 감사 로그를 지원하는 기타 모든 서비스가 포함되어 있습니다.

통합 감사 로그에 캡처된 데이터는 Power BI 활동 로그에 포함된 데이터와 완전히 동일합니다. Microsoft Purview 규정 준수 포털에서 감사 로그 검색을 수행하면 요청이 큐에 추가됩니다. 데이터가 준비되는 데 몇 분 또는 데이터 양에 따라 더 오래 걸릴 수 있습니다.

감사 로그 검색 도구를 사용하는 몇 가지 일반적인 방법은 다음과 같습니다. 다음이 가능합니다.

  • 일련의 날짜에 대한 이벤트를 보려면 Power BI 워크로드를 선택합니다.
  • 다음과 같은 하나 이상의 특정 활동을 찾습니다.
    • 삭제된 Power BI 보고서
    • Power BI의 개인 작업 영역에 대한 관리자 액세스 추가
  • 한 명 이상의 사용자 활동을 봅니다.

충분한 권한이 있는 관리자의 경우 Microsoft Purview 규정 준수 포털의 감사 로그 검색 도구는 수동 감사 프로세스에 적합한 옵션입니다. 자세한 내용은 이 문서의 뒷부분에 있는 Microsoft Purview 규정 준수 포털을 참조하세요.

클라우드용 Defender 앱 사용자 인터페이스

클라우드용 Defender 앱은 Microsoft Defender XDR(Microsoft 365 포털)의 관리자가 사용할 수 있습니다. 여기에는 Power BI를 포함한 다양한 클라우드 서비스에 대한 활동 로그를 보고 검색할 수 있는 사용자 인터페이스가 포함되어 있습니다. Microsoft Entra ID의 사용자 로그인 작업과 같은 다른 이벤트 외에도 Microsoft Purview 규정 준수 포털에서 발생하는 동일한 로그 이벤트가 표시됩니다.

클라우드용 Defender 앱의 감사 로그 인터페이스는 수동 감사 프로세스에 적합한 옵션입니다. 자세한 내용은 이 문서의 뒷부분에 있는 클라우드용 Defender 앱을 참조하세요.

Microsoft Sentinel 및 KQL

Microsoft Sentinel은 보안 인시던트 및 위협을 수집, 감지, 조사, 대응할 수 있는 Azure 서비스입니다. Power BI는 감사 로그가 Power BI에서 Microsoft Sentinel Azure Log Analytics(Azure Monitor 서비스의 구성 요소)로 스트리밍되도록 Microsoft Sentinel에서 데이터 커넥터로 설정할 수 있습니다. KQL(Kusto 쿼리 언어)을 사용하여 Azure Log Analytics에 저장된 활동 로그 이벤트를 분석할 수 있습니다.

KQL을 사용하여 Azure Monitor에서 데이터를 검색하는 것은 감사 로그의 일부를 보는 좋은 옵션입니다. 수동 감사 프로세스에도 적합한 옵션입니다. 자세한 내용은 이 문서의 뒷부분에 있는 Microsoft Sentinel을 참조하세요.

플랫폼 고려 사항

감사 데이터에 액세스하는 방법에 대한 몇 가지 고려 사항은 다음과 같습니다.

  • 수동 또는 자동화된 감사 프로세스를 구현하고 있나요? 특정 도구는 수동 처리 또는 자동화된 처리와 매우 일치합니다. 예를 들어 사용자는 항상 Try-it 기능을 대화형으로 실행하므로 이는 수동 감사 프로세스에만 적합합니다.
  • 어떻게 인증하나요? 모든 옵션이 모든 인증 옵션을 지원하는 것은 아닙니다. 예를 들어 Try-it 기능은 사용자 인증만 지원합니다.
  • 자격 증명을 안전하게 저장하려면 어떻게 해야 하나요? 기술마다 자격 증명을 저장하는 옵션이 다릅니다. 자세한 내용은 이 문서의 뒷부분에 있는 인증 방법 결정을 참조하세요.
  • 팀이 이미 능숙하게 사용하고 있는 기술은 무엇인가요? 팀이 선호하고 편안하게 사용할 수 있는 도구가 있다면 거기서부터 시작하세요.
  • 팀이 지원할 수 있는 기능은 무엇인가요? 배포된 솔루션을 다른 팀에서 지원할 경우 해당 팀에서 적절하게 지원할 수 있는지 고려하세요. 또한 내부 팀이 컨설턴트가 수행하는 개발을 지원할 수 있다는 점도 고려하세요.
  • 사용 승인을 받은 도구는 무엇인가요? 특정 도구 및 기술에는 승인이 필요할 수 있습니다. 비용 때문일 수도 있습니다. IT 보안 정책 때문일 수도 있습니다.
  • 선호하는 예약 방식은 무엇인가요? 일부 기술은 사용자를 대신해 결정을 내립니다. 다른 경우에는 또 다른 결정을 내려야 할 수도 있습니다. 예를 들어 PowerShell 스크립트를 작성하기로 선택한 경우 실행을 예약할 수 있는 다양한 방법이 있습니다. 반대로 Azure Data Factory와 같은 클라우드 서비스를 사용하는 경우 예약이 기본 제공됩니다.

감사 데이터에 액세스하는 기술을 선택하기 전에 이 문서의 나머지 부분을 검토하는 것이 좋습니다.

검사 목록 - 감사 데이터에 액세스하는 데 사용할 기술 결정 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • IT 담당자와 논의: IT 팀에 문의하여 승인 또는 선호하는 특정 도구가 있는지 확인합니다.
  • 간략한 POC(개념 증명)으로 옵션 탐색: 기술 POC를 사용하여 실험해 보세요. 처음에는 학습에 집중합니다. 그런 다음 앞으로 무엇을 사용할지 결정하는 데 집중하세요.

인증 방법 결정

인증을 어떻게 설정할 것인지는 매우 중요한 결정입니다. 이는 감사 및 모니터링을 시작할 때 가장 어려운 측면 중 하나인 경우가 많습니다. 정보에 입각한 결정을 내리려면 사용 가능한 옵션을 신중하게 고려해야 합니다.

Important

이 문제에 대해서는 IT 및 보안 팀에 문의하세요. 시간을 내어 Microsoft Entra ID의 보안 작동 방식에 대한 기본 사항을 알아보세요.

인터넷의 모든 API에 인증이 필요한 것은 아닙니다. 그러나 모든 Power BI REST API에는 인증이 필요합니다. 테넌트 수준 감사 데이터에 액세스하는 경우 인증 프로세스는 Microsoft ID 플랫폼에서 관리됩니다. 이는 업계 표준 프로토콜을 기반으로 구축된 Microsoft Entra ID 서비스의 진화한 형태입니다.

팁

Microsoft ID 플랫폼 용어집은 기본 개념을 익히는 데 도움이 되는 리소스입니다.

감사 데이터를 검색하기 전에 먼저 인증, 즉 로그인을 수행해야 합니다. 인증 및 권한 부여의 개념은 별개이지만 서로 관련되어 있습니다. 인증 프로세스는 요청을 하는 사람의 ID를 확인합니다. 인증 프로세스는 사용자 또는 서비스 주체가 무엇을 할 수 있는 권한을 가지고 있는지 확인하여 시스템 또는 리소스에 대한 액세스를 부여(또는 거부)합니다.

사용자 또는 서비스 주체가 인증하면 Power BI REST API 또는 Microsoft Graph API와 같은 리소스 서버에 Microsoft Entra 액세스 토큰이 발급됩니다. 기본적으로 액세스 토큰은 1시간 후에 만료됩니다. 필요한 경우 새로 고침 토큰을 요청할 수 있습니다.

액세스 토큰에는 두 가지 유형이 있습니다.

  • 사용자 토큰: 알려진 ID가 있는 사용자를 대신하여 발급됩니다.
  • 앱 전용 토큰: Microsoft Entra 애플리케이션(서비스 주체)을 대신하여 발급됩니다.

자세한 내용은 Microsoft Entra ID의 애플리케이션 및 서비스 주체 개체를 참조하세요.

참고 항목

Microsoft Entra 애플리케이션은 자동화된 프로세스가 Microsoft Entra ID와 통합될 수 있도록 하는 ID 구성입니다. 이 문서에서는 이를 앱 등록이라고 합니다. 이 문서에서는 서비스 주체라는 용어도 자주 사용됩니다. 이러한 용어는 이 섹션의 뒷부분에서 자세히 설명합니다.

팁

가장 쉬운 인증 방법은 Power BI 관리 모듈에서 Connect-PowerBIServiceAccount cmdlet을 사용하는 것입니다. 온라인 기사 및 블로그 게시물에서 다른 인증 관련 cmdlet을 보는 경우가 있을 수 있습니다. 예를 들어 Connect-PowerBIServiceAccount cmdlet의 별칭인 Login-PowerBI 및 Login-PowerBIServiceAccount cmdlet이 있습니다. 프로세스 종료 시 명시적으로 로그아웃하는 데 사용할 수 있는 Disconnect-PowerBIServiceAccount cmdlet도 있습니다.

다음 테이블에서는 두 가지 인증 옵션에 대해 설명합니다.

인증 유형 설명 대상 사용자 수동 감사 프로세스에 적합한 선택 자동화된 감사 프로세스에 적합한 선택
사용자 인증 사용자 계정 이름(메일 주소)과 암호를 사용하여 사용자로 로그인합니다. 가끔 대화형 사용 사용자 인증은 수동 감사 프로세스에 적합한 선택입니다.
서비스 주체 인증 앱 등록에 할당된 비밀(키)을 사용하여 서비스 주체로 로그인합니다. 진행 중인 예약된 무인 작업 서비스 주체 인증은 자동화된 감사 프로세스에 적합한 선택입니다.

각 인증 옵션은 다음 섹션에서 자세히 설명합니다.

사용자 인증

사용자 인증은 다음과 같은 상황에서 유용합니다.

  • 수동 감사 프로세스: 사용자 권한을 사용하여 스크립트를 실행하려고 합니다. 권한은 API 요청 유형에 따라 두 가지 수준 중 하나일 수 있습니다.
    • 관리자 API에 대한 관리자 권한: 관리자 API에 요청을 보내려면 Power BI 관리자 권한을 사용해야 합니다.
    • 사용자 API에 대한 사용자 권한: 사용자 API에 요청을 보내려면 Power BI 사용자 권한을 사용해야 합니다. 자세한 내용은 사용자 API 또는 관리자 API 선택을 참조하세요.
  • 대화형 로그인: 메일 주소와 암호를 입력해야 하는 대화형 로그인을 하려고 합니다. 예를 들어 Microsoft API 문서에 있는 Try-it 환경을 사용하려면 대화형으로 로그인해야 합니다.
  • 테넌트 메타데이터에 액세스한 사용자 추적: 개별 사용자와 관리자가 API 요청을 보낼 때 해당 사용자가 누구인지 감사할 수 있습니다. 서비스 주체로 인증할 때(다음에 설명) 활동 로그에 캡처된 사용자 ID는 애플리케이션 ID입니다. 여러 관리자가 동일한 서비스 주체로 인증하는 경우 어떤 관리자가 데이터에 액세스했는지 알기 어려울 수 있습니다.
  • 공유 관리자 계정: 일부 IT 팀은 공유 관리자 계정을 사용합니다. 구현 및 제어 방법에 따라 그것이 모범 사례가 아닐 수도 있습니다. 공유 계정 대신 사용자에게 간헐적인 임시 Power BI 관리자 권한을 부여할 수 있는 Microsoft Entra PIM(Privileged Identity Management) 사용을 고려해야 합니다.
  • 사용자 인증만 지원하는 API: 경우에 따라 서비스 주체에 의한 인증을 지원하지 않는 API를 사용해야 할 수도 있습니다. 문서에서 각 API는 서비스 주체가 호출할 수 있는지 여부를 기록합니다.

Important

가능하면 자동화된 프로세스에 서비스 주체 인증을 사용하는 것이 좋습니다.

서비스 주체 인증

대부분의 조직에는 하나의 Microsoft Entra 테넌트가 있으므로 앱 등록과 서비스 주체라는 용어는 같은 의미로 사용되는 경향이 있습니다. Microsoft Entra 앱을 등록하면 두 가지 구성 요소가 있습니다.

  • 앱 등록: 앱 등록은 전역적으로 고유합니다. 여러 테넌트에서 사용할 수 있는 등록된 Microsoft Entra 앱의 전역 정의입니다. 앱 등록은 클라이언트 애플리케이션 또는 작업자라고도 합니다. 일반적으로 클라이언트 애플리케이션이라는 용어는 사용자 컴퓨터를 의미합니다. 그러나 앱 등록의 경우에는 그렇지 않습니다. Azure Portal에서 Microsoft Entra 애플리케이션은 Microsoft Entra ID의 앱 등록 페이지에서 찾을 수 있습니다.
  • 서비스 주체: 서비스 주체는 특정 테넌트에서 사용할 앱 등록의 로컬 표현입니다. 서비스 주체는 등록된 Microsoft Entra 앱에서 파생됩니다. 여러 Microsoft Entra 테넌트가 있는 조직의 경우 둘 이상의 서비스 주체에서 동일한 앱 등록을 참조할 수 있습니다. Azure Portal의 서비스 주체는 Microsoft Entra ID의 엔터프라이즈 애플리케이션 페이지에서 찾을 수 있습니다.

서비스 주체는 로컬 표현이므로 서비스 주체 인증이라는 용어는 로그인을 참조하는 가장 일반적인 방법입니다.

팁

Microsoft Entra 관리자는 조직에서 앱 등록을 만들고 동의할 수 있는 사람을 알려줄 수 있습니다.

서비스 주체 인증은 다음과 같은 상황에서 유용합니다.

  • 자동화된 감사 프로세스: 일정에 따라 무인 프로세스를 실행하려고 합니다.
  • Power BI 서비스에 로그인할 필요가 없음: 데이터를 연결하고 추출하기만 하면 됩니다. 서비스 주체는 Power BI 서비스에 로그인할 수 없습니다.
  • 데이터에 대한 공유 액세스: 사용자는 개인적으로 Power BI 관리자는 아니지만 서비스 주체를 사용할 권한이 있습니다. 서비스 주체에는 관리자 API를 실행하여 테넌트 수준 데이터(또는 기타 특정 권한)를 검색할 수 있는 권한이 있습니다.
  • 여러 관리자가 사용: 여러 관리자 또는 사용자가 동일한 서비스 주체를 사용하도록 허용하려고 합니다.
  • 기술 차단기: 사용자 인증 사용을 방해하는 기술 차단기가 있습니다. 일반적인 기술 차단에는 다음이 포함됩니다.
    • 다단계 인증(MFA): 자동화된 감사 프로세스(무인 실행)는 다단계 인증이 활성화된 경우 사용자 계정을 사용하여 인증할 수 없습니다.
    • 암호 해시 동기화: Microsoft Entra ID에서는 인증할 사용자 계정에 대해 암호 해시 동기화가 필요합니다. 경우에 따라 IT 또는 사이버 보안 팀이 해당 기능을 사용하지 않도록 설정할 수 있습니다.
앱 등록 목적 및 명명 규칙

각 앱 등록에는 해당 목적과 대상 그룹(앱 등록을 사용할 수 있는 사람)을 설명하는 명확한 이름이 있어야 합니다.

다음과 같은 명명 규칙 구현을 고려하세요(예: <워크로드> - <목적> - <대상 그룹> - <개체 형식>)

다음은 명명 규칙의 일부입니다.

  • 워크로드: 일반적으로 데이터 원본(예: Power BI 데이터 또는 Microsoft Graph 데이터)과 동일합니다.
  • 용도: 권한 수준과 유사합니다(예: Read 대 ReadWrite). 아래에 설명된 대로 이 목적은 데이터 읽기만 가능한 별도의 앱 등록을 만들 때 최소 권한의 원칙을 따르는 데 도움이 됩니다.
  • 대상 그룹: 선택 사항입니다. 워크로드 및 목적에 따라 대상 그룹을 통해 앱 등록 대상 사용자를 결정할 수 있습니다.
  • 객체 유형: 명확성을 위해 EntraApp이 포함되었습니다.

여러 테넌트 또는 여러 환경(예: 개발 및 프로덕션)이 있는 경우 명명 규칙이 더 구체적일 수 있습니다.

다음 테이블에서는 테넌트 수준 감사 데이터를 추출하는 데 사용할 수 있는 앱 등록의 예를 보여 줍니다.

앱 등록 이름 용도 대상 그룹
PowerBIData-Read-AdminAPIs-EntraApp Power BI 감사 및 관리를 위해 테넌트 전체 메타데이터를 추출합니다. 관리 API는 항상 읽기 전용이며 Microsoft Entra ID에서 부여된 권한이 없을 수도 있습니다(Power BI 테넌트 설정만 해당). Power BI 관리자 및 우수성 센터
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp Power BI 테넌트를 관리합니다. 리소스를 만들거나 업데이트하려면 읽기/쓰기 권한이 필요합니다. Power BI 관리자 및 우수성 센터
GraphData-Read-PowerBIAdministrators-EntraApp Power BI 감사 및 관리를 위해 사용자 및 그룹 데이터를 추출합니다. 읽기 권한이 필요합니다. Power BI 관리자 및 우수성 센터

다양한 목적으로 여러 앱 등록을 관리하려면 더 많은 노력이 필요합니다. 그러나 몇 가지 이점을 활용할 수 있습니다.

  • 앱 등록의 용도와 그 이유 확인: 앱 등록의 클라이언트 ID가 감사 데이터에 표시되면 해당 ID가 사용된 용도와 그 이유를 알 수 있습니다. 이는 하나의 앱 등록을 모든 용도로 사용하는 것보다 별도의 앱 등록을 만들 때 얻을 수 있는 중요한 이점입니다.
  • 앱 등록을 사용하도록 의도한 사용자 확인: 앱 등록의 클라이언트 ID가 감사 데이터에 표시되면 누가 앱을 사용했는지 알 수 있습니다.
  • 권한 오버프로비전 방지: 다양한 요구 사항이 있는 다양한 사람들에게 별도의 앱 등록을 제공하여 최소 권한의 원칙을 따를 수 있습니다. 쓰기 권한이 필요하지 않은 경우 읽기 전용 앱 등록을 사용하면 권한 오버프로비전을 방지할 수 있습니다. 예를 들어 의미 체계 모델에 대한 데이터를 수집하려는 능력이 뛰어난 셀프 서비스 사용자가 있을 수 있으며, 이러한 사용자는 읽기 권한이 있는 서비스 주체에 액세스해야 합니다. 반면 프로그래밍 방식으로 의미 체계 모델을 관리하는 재무 팀을 위해 일하는 최고 전문가 조직의 위성 멤버가 있을 수 있습니다. 쓰기 권한이 있는 서비스 주체에 액세스해야 합니다.
  • 암호를 소유해야 하는 사람이 누구인지 파악: 각 앱 등록에 대한 암호는 필요한 사람에게만 공유되어야 합니다. 비밀이 순환되는 경우(이 섹션의 뒷부분에서 설명) 필요에 따라 별도의 앱 등록을 사용할 때 영향이 더 적습니다. 이는 사용자가 조직을 떠나거나 역할이 변경되어 비밀을 순환해야 하는 경우에 유용합니다.
앱 등록 권한

앱 등록이 데이터와 리소스에 액세스할 수 있는 두 가지 주요 방법이 있습니다. 여기에는 권한 및 동의가 포함됩니다.

  • 앱 전용 권한: 로그인한 사용자 없이 서비스 주체가 액세스 및 승인을 처리합니다. 해당 인증 방법은 자동화 시나리오에 유용합니다. 앱 전용 권한을 사용할 때는 권한이 Microsoft Entra ID에 할당되지 않았다는 점을 이해하는 것이 중요합니다. 대신 권한은 다음 두 가지 방법 중 하나로 할당됩니다.
    • 관리자 API를 실행하는 경우: 특정 Power BI 테넌트 설정을 사용하면 관리자 API(테넌트 전체 감사 메타데이터를 반환함)의 엔드포인트에 대한 액세스를 허용합니다. 자세한 내용은 이 문서의 뒷부분에 있는 Power BI 테넌트 설정 지정을 참조하세요.
    • 사용자 API를 실행하는 경우: Power BI 작업 영역 및 항목 권한이 적용됩니다. 표준 Power BI 권한은 API를 호출하는 사용자 또는 서비스 주체의 권한을 기반으로 감사 데이터를 반환하는 사용자 API를 실행하는 경우 서비스 주체에 반환될 수 있는 데이터를 제어합니다.
  • 위임된 권한: 범위 기반 권한이 사용됩니다. 서비스 주체는 현재 로그인한 사용자를 대신하여 데이터에 액세스합니다. 이는 서비스 주체가 로그인한 사용자가 액세스할 수 있는 범위를 넘어서는 어떤 것에도 액세스할 수 없음을 의미합니다. 이는 이전에 설명한 사용자 전용 인증과는 다른 개념입니다. 사용자 및 앱 권한의 조합을 적절하게 처리하려면 사용자 지정 애플리케이션이 필요하기 때문에 위임된 권한은 감사 시나리오에 거의 사용되지 않습니다. 이 개념은 일반적으로 오해되어 권한이 오버프로비전되는 많은 앱 등록으로 이어집니다.

Important

이 문서에서는 사용자 인증 또는 앱 전용 인증에만 중점을 둡니다. 위임된 권한(대화형 사용자 및 서비스 주체 포함)은 Power BI 콘텐츠를 프로그래밍 방식으로 포함하는 경우 중요한 역할을 할 수 있습니다. 그러나 감사 데이터 추출을 위해 위임된 권한을 설정하지 않는 것이 좋습니다. 모든 API는 실행 빈도(제한이 적용됨)를 제한하므로 여러 사용자가 원시 감사 데이터에 직접 액세스하도록 하는 것은 실용적이지 않습니다. 대신 중앙 집중식 프로세스를 통해 원시 감사 데이터를 한 번 추출한 다음 권한이 부여된 사용자가 다운스트림에서 큐레이팅된 감사 데이터를 사용할 수 있도록 하는 것이 좋습니다.

자세한 내용은 이 문서의 뒷부분에 있는 Microsoft Entra 앱 등록을 참조하세요.

앱 등록 비밀

앱 등록에는 종종 비밀이 할당되어 있습니다. 비밀은 인증을 위한 키로 사용되며 만료 날짜가 있습니다. 따라서 정기적으로 키를 순환하는 방법과 권한 있는 사용자에게 새 키를 전달하는 방법을 계획해야 합니다.

또한 비밀을 안전하게 저장할 위치에 대해서도 고려해야 합니다. Azure Key Vault와 같은 조직 암호 자격 증명 모음은 탁월한 선택입니다.

팁

비밀 사용에 대한 대안으로 관리 ID를 사용할 수 있습니다. 관리 ID를 사용하면 자격 증명을 관리할 필요가 없습니다. Azure Functions 또는 Azure Data Factory와 같은 서비스를 사용하여 데이터를 추출하려는 경우 관리 ID를 조사하는 것이 좋습니다.

자격 증명을 안전하게 관리

사용자 인증을 사용하든 서비스 주체 인증을 사용하든 관계없이 가장 큰 과제 중 하나는 암호, 비밀, 키를 안전하게 관리하는 방법입니다.

주의

첫 번째 규칙은 많은 사용자가 위반하는 규칙입니다. 즉, 암호와 키는 스크립트에서 일반 텍스트로 표시되어서는 안 됩니다. 온라인의 많은 기사, 블로그, 예제에서는 간소화를 위해 이를 수행합니다. 그러나 이는 피해야 할 좋지 않은 습관입니다. 스크립트(또는 파일)를 가져오는 모든 사용자는 작성자가 액세스할 수 있는 것과 동일한 데이터에 액세스할 수 있습니다.

다음은 암호, 비밀, 키를 관리하는 데 사용할 수 있는 몇 가지 안전한 방법입니다.

  • 가능하다면 언제든지 Azure Key Vault 또는 다른 조직의 암호 자격 증명 모음 시스템과 통합하세요.
  • PowerShell 스크립트에서 자격 증명 및 보안 문자열을 사용하세요. 자격 증명은 사용자 인증과 서비스 주체 인증 모두에 사용됩니다. 그러나 사용자 계정에 대해 다단계 인증이 활성화된 경우에는 자격 증명을 사용할 수 없습니다.
  • PowerShell 스크립트에서 암호를 묻는 메시지를 표시하거나 브라우저에서 대화형 인증을 사용합니다.
  • Microsoft에서 게시한 PowerShell용 비밀 관리 모듈을 사용하세요. 로컬 자격 증명 모음을 사용하여 값을 저장할 수 있습니다. 또한 원격 Azure Key Vault와 통합할 수도 있는데, 이는 조직에 동일한 스크립트를 사용하는 관리자가 여러 명 있는 경우에 유용합니다.
  • 자격 증명을 안전하게 처리할 수 있도록 Power BI Desktop용 사용자 지정 커넥터를 만듭니다. 일부 사용자 지정 커넥터는 커뮤니티 멤버(일반적으로 GitHub)에게서 얻을 수 있습니다.

팁

IT 및 보안 팀과 상의하여 최선의 방법을 선택하는 데 도움을 받거나 솔루션이 안전한 방식으로 자격 증명을 관리하는지 확인하는 것이 좋습니다.

Microsoft 인증 라이브러리

ADAL(Azure AD 인증 라이브러리)에 대한 지원은 2022년 12월에 종료되었습니다. 앞으로 MSAL(Microsoft 인증 라이브러리)을 사용해야 합니다. 조직의 보안 팀은 이 중요한 변경 내용을 잘 알고 있어야 합니다.

Power BI 전문가가 MSAL로의 전환을 깊이 이해하는 것은 중요하지 않지만 다음 권장 사항을 따라야 합니다.

  • Connect-PowerBIServiceAccount PowerShell cmdlet으로 인증할 때 최신 버전의 Power BI 관리 모듈을 사용하세요. 버전 1.0.946(2021년 2월 26일)에서 ADAL에서 MSAL로 전환되었습니다.
  • 스크립트에서 직접 인증하는 경우 Microsoft Entra V2 엔드포인트를 사용하세요. Microsoft Entra V2 엔드포인트는 MSAL을 사용하는 반면 Microsoft Entra V1 엔드포인트는 ADAL을 사용합니다.
  • 더 이상 사용되지 않는 API 및 모듈의 사용을 중단합니다. 자세한 내용은 이 문서의 뒷부분에 있는 사용되지 않는 API 및 모듈을 참조하세요.
  • 온라인에서 커뮤니티 솔루션을 찾는 경우 인증에 ADAL이 아닌 MSAL을 사용하고 있는지 확인하세요.

검사 목록 – 인증을 관리하는 방법 결정 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 사용할 인증 유형 결정: 만들려는 감사 솔루션 유형에 따라 사용자 인증 또는 서비스 주체 인증이 가장 적합한지 결정합니다.
  • 필요한 앱 등록 계획: 요구 사항, 워크로드, 대상 그룹(각 앱 등록 사용자)을 고려하세요. 이러한 요구 사항을 지원하기 위해 만들어야 하는 앱 등록 수를 계획하세요.
  • 앱 등록을 위한 명명 규칙 만들기: 각 앱 등록의 의도된 목적과 대상 사용자를 쉽게 이해할 수 있도록 명명 규칙을 설정합니다.
  • 자격 증명을 안전하게 관리하는 방법 계획: 암호, 비밀, 키를 안전하게 관리하는 방법을 고려하세요. 필요한 문서 및 교육을 고려합니다.
  • MSAL 사용 확인: ADAL을 사용하는 기존 수동 또는 자동화된 감사 솔루션이 있는지 확인합니다. 필요한 경우 최신 MSAL 인증 라이브러리를 사용하도록 이러한 솔루션을 다시 작성하는 계획을 수립합니다.

사용자 API 또는 관리자 API 선택

감사 데이터 검색을 계획하는 경우 올바른 유형의 API를 사용하는 것이 중요합니다.

고려해야 할 API에는 두 가지 유형이 있습니다.

  • 사용자 API: 로그인한 사용자(또는 서비스 주체)의 권한을 사용하여 API에 요청을 보냅니다. 예를 들어 작업 영역에서 의미 체계 모델 목록을 반환하는 한 가지 방법은 사용자 API를 사용하는 것입니다. 의미 체계 모델 읽기 권한은 작업 영역 역할 또는 항목별 권한을 통해 부여될 수 있습니다. 사용자 API를 실행하는 방법에는 두 가지가 있습니다.
    • 사용자 인증: 로그인한 사용자는 작업 영역이나 항목에 액세스할 수 있는 권한이 있어야 합니다.
    • 서비스 주체 인증: 서비스 주체에는 작업 영역 또는 항목에 액세스할 수 있는 권한이 있어야 합니다.
  • 관리자 API: 테넌트에서 메타데이터를 검색합니다. 때로는 조직 범위라고도 합니다. 예를 들어 테넌트의 모든 의미 체계 모델 목록을 반환하려면 관리자 API를 사용합니다. 관리자 API를 실행하는 방법에는 두 가지가 있습니다.
    • 사용자 인증: 관리 API를 실행하려면 로그인한 사용자가 Power BI 관리자여야 합니다.
    • 서비스 주체 인증: 서비스 주체에는 사용자 API와 같은 보안 권한에 의존하지 않고 관리자 API를 실행할 수 있는 권한이 있어야 합니다.

팁

모든 관리자 API는 관리 작업 그룹에 속합니다. As Admin 접미사가 있는 모든 API는 관리자 API이며, 나머지 모든 API는 사용자 API입니다.

의미 체계 모델 목록을 가져와야 하는 예제를 생각해 보세요. 다음 테이블에는 이를 수행하는 데 사용할 수 있는 6가지 API 옵션이 나와 있습니다. 네 가지 옵션은 사용자 API이고 두 가지 옵션은 관리자 API입니다. 반환되는 항목의 범위와 수는 선택한 API에 따라 다릅니다.

API 이름 API 유형 범위 의미 체계 모델 수
데이터 세트 가져오기 사용자 개인 작업 영역 1
데이터 세트 가져오기 사용자 개인 작업 영역 모두
그룹에서 데이터 세트 가져오기 사용자 단일 작업 영역 하나(로그인한 사용자에게 의미 체계 모델을 읽을 수 있는 권한이 있는 경우)
그룹에서 데이터 세트 가져오기 사용자 단일 작업 영역 모두(로그인한 사용자에게 각 의미 체계 모델을 읽을 수 있는 권한이 있는 경우)
관리자 권한으로 그룹의 데이터 세트 가져오기 Admin 단일 작업 영역 모두
관리자 권한으로 데이터 세트 가져오기 Admin 전체 테넌트 모두

참고 항목

일부 API 이름에는 작업 영역을 가리키는 용어인 그룹이 포함되어 있습니다. 이 용어는 Microsoft 365 그룹을 기반으로 한 원래 Power BI 보안 모델에서 유래되었습니다. Power BI 보안 모델은 수년에 걸쳐 크게 발전했지만 기존 솔루션이 손상되지 않도록 기존 API 이름은 변경되지 않은 상태로 유지됩니다.

테넌트 설정에 대한 자세한 내용은 이 문서의 뒷부분에 있는 Power BI 테넌트 설정 지정을 참조하세요.

검사 목록 - 사용자 API 또는 관리자 API를 사용할지 여부 선택 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 데이터 요구 사항 참조: 감사 솔루션에 대한 주요 비즈니스 요구 사항을 수집하고 문서화합니다. 필요한 데이터 형식에 따라 사용자 범위 또는 조직 범위가 적절한지 결정합니다.
  • 결과 테스트: 몇 가지 실험을 수행합니다. 다양한 API에서 반환되는 결과의 정확도를 테스트합니다.
  • 권한 검토: 기존 감사 솔루션의 경우 Power BI 관리자 및 서비스 주체에게 권한이 올바르게 할당되었는지 확인합니다. 새로운 감사 솔루션의 경우 어떤 인증 방법을 사용할지 확인합니다.

API 또는 PowerShell cmdlet 선택

중요한 결정은 검색하려는 특정 데이터에 대해 PowerShell cmdlet을 사용할 수 있을 때 이를 사용할지 여부를 결정하는 것입니다. 이 결정은 PowerShell을 감사 데이터에 액세스하는 데 사용할 기술 중 하나라고 결정한 경우에 중요합니다.

PowerShell은 작업 자동화 솔루션입니다. PowerShell이라는 용어는 스크립팅 언어, 명령줄 셸 애플리케이션, 구성 관리 프레임워크를 가리키는 집합적인 용어입니다. PowerShell Core는 Windows, Linux, macOS에서 실행되는 최신 버전의 PowerShell입니다.

PowerShell cmdlet은 작업을 수행하는 명령입니다. PowerShell 모듈은 cmdlet, 공급자, 함수, 워크플로, 변수, 별칭과 같은 PowerShell 멤버를 포함하는 패키지입니다. 모듈을 다운로드하고 설치합니다.

PowerShell 모듈은 API에 대한 추상화 계층을 만듭니다. 예를 들어 Get-PowerBIActivityEvent cmdlet은 Power BI 테넌트에 대한 감사 이벤트를 검색(또는 가져오기)합니다. 이 PowerShell cmdlet은 활동 이벤트 가져오기 REST API에서 데이터를 검색합니다. 일반적으로 cmdlet을 사용하면 기본 API에 대한 액세스가 간소화되므로 시작하기가 더 간편합니다.

API의 하위 집합만 PowerShell cmdlet으로 사용할 수 있습니다. 전체 감사 솔루션을 계속 확장하면 cmdlet과 API의 조합을 사용하게 될 가능성이 큽니다. 이 섹션의 나머지 부분은 데이터에 액세스할 방법을 결정하는 데 도움이 됩니다.

PowerShell 모듈

Microsoft는 Power BI와 관련된 cmdlet을 포함하는 두 개의 PowerShell 모듈을 게시했습니다. Power BI 관리 모듈과 데이터 게이트웨이 모듈입니다. 이러한 PowerShell 모듈은 기본 Power BI REST API 위에서 API 래퍼 역할을 합니다. 이러한 PowerShell 모듈을 사용하면 스크립트를 더 쉽게 작성할 수 있습니다.

팁

Microsoft에서 게시한 모듈 외에도 Power BI 커뮤니티 멤버, 파트너, Microsoft MVP(가장 중요한 전문가)가 게시한 무료 PowerShell 모듈 및 스크립트(일반적으로 GitHub에 게시됨)가 있습니다.

커뮤니티 솔루션으로 시작하는 것은 엔드투엔드 감사 솔루션을 구축하는 데 중요한 역할을 할 수 있습니다. 무료로 제공되는 솔루션을 사용하기로 선택한 경우 완전하게 테스트해야 합니다. 시간이 지남에 따라 솔루션을 효과적으로 관리할 수 있도록 작동 방식을 숙지하세요. IT 팀에는 공개적으로 사용 가능한 커뮤니티 솔루션을 사용하기 위한 기준이 있을 수 있습니다.

Power BI 관리 모듈

Power BI 관리 모듈은 관리, 용량, 작업 영역 등을 위한 특정 Power BI 모듈이 포함된 롤업 모듈입니다. 모든 모듈을 얻기 위해 롤업 모듈을 설치하도록 선택하거나 특정 모듈을 설치할 수 있습니다. 모든 Power BI 관리 모듈은 Windows PowerShell과 PowerShell Core 모두에서 지원됩니다.

Important

PowerShell Core를 실행할 수 없는 Windows PowerShell 사용을 중단하는 것이 좋습니다. 대신 PowerShell Core를 지원하는 최신 코드 편집기 중 하나를 사용하세요. Windows PowerShell ISE(통합 스크립트 환경)는 더 이상 업데이트되지 않는 PowerShell 버전 5.1만 실행할 수 있습니다. Windows PowerShell은 이제 더 이상 사용되지 않으므로 모든 새로운 개발 작업에 PowerShell Core를 사용하는 것이 좋습니다.

다음은 감사 데이터를 검색하는 데 사용할 수 있는 일반적으로 사용되는 몇 가지 cmdlet입니다.

관리 모듈 Cmdlet 용도
프로필 Connect-PowerBIServiceAccount Power BI 사용자 또는 서비스 주체를 인증합니다.
Admin Get-PowerBIActivityEvent 테넌트에 대한 Power BI 활동 로그 이벤트를 보거나 추출합니다.
작업 영역 Get-PowerBIWorkspace 작업 영역 목록을 컴파일합니다.
보고서 Get-PowerBIReport 작업 영역 또는 테넌트 보고서 목록을 컴파일합니다.
데이터 Get-PowerBIDataset 작업 영역 또는 테넌트용 의미 체계 모델 목록을 컴파일합니다.
프로필 Invoke-PowerBIRestMethod REST API 요청(명령)을 보냅니다. 이 cmdlet은 Power BI REST API를 호출할 수 있으므로 좋은 옵션입니다. 또한 Connect-PowerBIServiceAccount cmdlet을 사용하여 더 간단한 형식의 인증을 사용하고 해당 PowerShell cmdlet이 없는 API를 호출할 수 있는 경우에도 좋은 선택입니다. 자세한 내용은 이 섹션의 뒷부분에 있는 PowerShell cmdlet 사용 시 고려 사항을 참조하세요.

팁

콘텐츠를 관리하고 게시하는 데 사용할 수 있는 다른 cmdlet이 있습니다. 그러나 이 문서는 감사 데이터 검색에 중점을 둡니다.

PowerShell 갤러리에서 Power BI 관리 모듈을 다운로드할 수 있습니다. 모듈을 설치하는 가장 간단한 방법은 PowerShellGet을 사용하는 것입니다.

Power BI 관리 롤업 모듈을 설치하는 것이 좋습니다. 이렇게 하면 필요한 모든 cmdlet을 사용할 수 있습니다. 최소한 인증을 위한 프로필 모듈과 사용하려는 cmdlet이 포함된 특정 모듈이 필요합니다.

주의

PowerShell을 사용하는 모든 서버, 사용자 컴퓨터, 클라우드 서비스(예: Azure Automation)에서 모듈을 최신 상태로 유지해야 합니다. 모듈이 정기적으로 업데이트되지 않으면 예측할 수 없는 오류 또는 문제가 발생할 수 있습니다. 일부 도구(예: Visual Studio Code)는 모듈을 업데이트된 상태로 유지하는 데 도움이 됩니다. 또한 최신 버전을 설치하거나 업데이트하는 경우 PowerShellGet은 이전 버전의 모듈을 자동으로 제거하지 않는다는 점에 유의하세요. 이전 버전과 함께 최신 버전을 설치합니다. 설치된 버전을 확인하고 정기적으로 이전 버전을 제거하는 것이 좋습니다.

데이터 게이트웨이 모듈

데이터 게이트웨이 모듈에는 온-프레미스 데이터 게이트웨이 및 해당 데이터 원본에서 데이터를 검색하는 cmdlet이 포함되어 있습니다. 데이터 게이트웨이 모듈은 PowerShell Core에서만 지원됩니다. Windows PowerShell에서는 지원되지 않습니다.

Power BI 관리 모듈(이전에 설명함)과 달리 데이터 게이트웨이 모듈에는 관리 cmdlet이 포함되지 않습니다. 많은 cmdlet(및 해당 게이트웨이 API)을 사용하려면 사용자에게 게이트웨이 관리자 권한이 있어야 합니다.

Warning

서비스 주체를 게이트웨이 관리자로 할당하는 것은 서비스 주체가 보안 그룹의 멤버인 경우에도 불가능합니다. 따라서 데이터 게이트웨이에 대한 정보를 검색할 때 사용자 자격 증명을 사용하도록 계획합니다.

다음은 감사 데이터를 검색하는 데 사용할 수 있는 데이터 게이트웨이 모듈의 몇 가지 cmdlet입니다.

Cmdlet 용도
Connect-DataGatewayServiceAccount Power BI 사용자를 인증합니다(일반적으로 사용자가 게이트웨이 관리자 역할에 속해야 함).
Get-DataGatewayCluster 게이트웨이 클러스터 목록을 컴파일합니다.
Get-DataGatewayClusterDataSource 게이트웨이 클러스터에 대한 데이터 원본 목록을 컴파일합니다.
Get-DataGatewayInstaller 조직에 게이트웨이를 설치하고 등록할 수 있는 사용자가 누구인지 확인합니다.

PowerShell 갤러리에서 데이터 게이트웨이 모듈을 다운로드할 수 있습니다.

PowerShell을 사용하는 기법

여러 가지 방법으로 PowerShell을 사용할 수 있습니다. 사용자가 내리는 결정은 매우 중요합니다.

다음 테이블에서는 PowerShell을 사용하는 세 가지 기법을 설명합니다.

기법 설명 예제
인증을 간소화하고 API를 직접 호출하려면 PowerShell cmdlet을 사용합니다. 권장 방법 이 기법을 사용하면 단순성과 유연성의 균형이 유지됩니다. Invoke-PowerBIRestMethod cmdlet은 Power BI 관리 프로필 모듈에서 사용할 수 있습니다. 이 cmdlet은 Power BI REST API를 호출하는 데 사용할 수 있으므로 종종 스위스 군용 칼이라고도 합니다. 이 기법을 사용하면 인증을 간소화한 다음 Power BI REST API를 호출할 수 있다는 이점이 있습니다. 이 기법을 사용하는 것이 좋습니다. Connect-PowerBIServiceAccount cmdlet으로 인증한 후 Invoke-PowerBIRestMethod cmdlet을 사용하여 원하는 API에서 데이터를 검색합니다(예: 파이프라인 사용자를 관리자 권한으로 가져오기)
인증과 데이터 검색 모두에서 PowerShell의 cmdlet을 최대한 사용하세요. 이 기법을 사용하면 PowerShell이 광범위하게 사용됩니다. PowerShell은 스크립트 실행을 조정하는 데 사용되며 데이터 액세스를 위해 가능할 때마다 PowerShell 모듈이 사용됩니다. 이로 인해 여러 측면에서 PowerShell에 대한 종속성이 커집니다. Connect-PowerBIServiceAccount cmdlet으로 인증한 후 cmdlet(예: Get-PowerBIActivityEvent)을 사용하여 데이터를 검색합니다.
프로세스 실행을 조정하는 데에만 PowerShell을 사용합니다. PowerShell 모듈은 최대한 적게 사용됩니다. 이 기법을 사용하면 PowerShell의 주요 용도가 API 호출을 조정하는 것이므로 도구로서 PowerShell에 대한 종속성이 줄어듭니다. API에 액세스하는 데는 하나의 일반 PowerShell 모듈만 사용됩니다(Power BI 관리 모듈의 모듈은 사용되지 않음). MSAL(Microsoft 인증 라이브러리)를 사용하여 인증한 후 일반 Invoke-RestMethod cmdlet을 사용하여 원하는 API(예: 파이프라인 사용자를 관리자 권한으로 가져옴)를 호출하여 데이터를 검색합니다.

위의 테이블에서 첫 번째 기법은 사용 편의성과 유연성 간의 균형을 맞추는 접근 방식을 설명합니다. 이 방법은 대부분의 조직의 요구 사항에 가장 적합한 균형을 제공하므로 권장됩니다. 일부 조직에는 PowerShell 사용 방법을 결정하는 방법에 영향을 주는 기존 IT 정책 및 직원 기본 설정이 있을 수 있습니다.

팁

Invoke-ASCmd PowerShell cmdlet을 사용하여 DAX, XMLA, TMSL 스크립트를 만들고 실행할 수 있습니다. 그러나 이러한 사용 사례는 이 문서의 범위를 벗어납니다. DMV(동적 관리 뷰) 쿼리에 대한 자세한 내용은 데이터 수준 감사를 참조하세요.

기술 사용자(및 관리자)는 Power BI 관리 모듈을 사용하여 데이터를 검색하거나 콘텐츠 관리의 특정 측면을 자동화할 수 있습니다.

  • 관리자의 경우: 전체 테넌트의 항목에 액세스하려면(예: 모든 작업 영역 목록을 검색) -Scope 매개 변수를 Organization으로 설정하세요.
  • 기술 사용자의 경우: 사용자에게 속한 엔터티에 액세스하려면 -Scope 매개 변수를 Individual로 설정하거나 매개 변수를 생략합니다(예: 사용자가 에 액세스할 수 있는 권한이 있는 작업 영역의 목록을 검색).

의미 체계 모델의 목록을 가져와야 하는 시나리오를 생각해 보겠습니다. API로 직접 작업하도록 선택한 경우 호출할 API를 지정해야 합니다. 그러나 Get-PowerBIDataset cmdlet을 사용하기로 선택한 경우 -Scope 매개 변수를 설정하여 사용자별 또는 테넌트 전체 의미 체계 모델 목록을 검색할 수 있습니다. 선택은 PowerShell 사용 방법에 대한 결정에 따라 달라집니다(이전 테이블에서 설명됨).

다음 테이블에서는 PowerShell cmdlet에 사용되는 매개 변수가 API PowerShell 호출로 변환되는 방식을 설명합니다.

cmdlet 매개 변수 cmdlet에서 사용하는 API API 유형 범위 검색된 항목
-DatasetID {DatasetID}
-Scope Individual		 데이터 세트 가져오기 사용자 개인 작업 영역 하나의 의미 체계 모델
-Scope Individual 데이터 세트 가져오기 사용자 개인 작업 영역 모든 의미 체계 모델
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 그룹에서 데이터 세트 가져오기 사용자 단일 작업 영역 로그인한 사용자에게 의미 체계 모델을 읽을 수 있는 권한이 있는 경우 하나의 의미 체계 모델
-GroupID {WorkspaceID} 그룹에서 데이터 세트 가져오기 사용자 단일 작업 영역 모든 의미 체계 모델(로그인한 사용자에게 작업 영역에 액세스하고 의미 체계 모델을 읽을 수 있는 권한이 있는 경우)
-GroupID {WorkspaceID}
-Scope Organization		 관리자 권한으로 그룹의 데이터 세트 가져오기 Admin 단일 작업 영역 모든 의미 체계 모델
-Scope Organization 관리자 권한으로 데이터 세트 가져오기 Admin 전체 테넌트 모든 의미 체계 모델
PowerShell cmdlet 사용 시 고려 사항

Power BI PowerShell cmdlet은 REST API 호출의 복잡성을 일부 추상화하므로 사용하기가 더 간단합니다.

다음은 cmdlet을 통해 감사 데이터 액세스를 간소화하는 몇 가지 방법입니다.

  • 인증: PowerShell 스크립트에서 인증하는 가장 간단한 방법은 Connect-PowerBIServiceAccount cmdlet을 사용하는 것입니다.
  • 단순성: 감사 데이터를 검색하는 기법이 간단하므로 시작하기가 더 쉽습니다. Get-PowerBActivityEvent cmdlet을 사용하면 1일의 감사 데이터를 검색한다는 점을 고려하세요. 그러나 활동 이벤트 가져오기 REST API를 직접 호출하면 1시간의 감사 데이터를 검색할 수 있습니다. 따라서 REST API를 사용하여 하루의 감사 데이터를 검색하는 경우 반복을 사용하여 API를 24번 호출하고 하루의 각 시간을 추출해야 합니다.
  • 큰 결과 집합의 페이지 매김: 큰 결과 집합은 페이지 매김을 통해 효율적으로 검색됩니다. 페이지 매김에는 한 번에 한 덩어리의 결과를 검색하는 작업이 포함됩니다. cmdlet은 자동으로 페이지 매김을 관리합니다. 그러나 REST API를 직접 사용하는 경우 스크립트는 연속 토큰을 확인하여 앞으로 더 많은 결과가 있는지 확인해야 합니다. 스크립트는 연속 토큰이 수신되지 않을 때까지 계속해서 결과 덩어리를 검색해야 합니다. 연속 토큰 사용의 예제는 활동 이벤트 REST API를 참조하세요.
  • 액세스 토큰 만료: 인증 시 액세스 토큰이 반환됩니다. 기본적으로 1시간 후에 만료됩니다. cmdlet은 액세스 토큰 만료를 처리합니다. 이렇게 하면 새로 고침 토큰을 요청하는 논리를 작성할 필요가 없습니다.
  • 서식 지정: cmdlet에서 반환된 데이터는 REST API에서 반환된 데이터보다 서식이 약간 더 낫습니다. 출력이 더 사용자 친화적입니다. 자동화된 감사 프로세스의 경우 이는 문제가 되지 않을 수 있습니다. 그러나 수동 감사 프로세스의 경우 더 나은 서식 지정이 도움이 될 수 있습니다.
REST API 직접 사용 시 고려 사항

Power BI REST API를 직접 호출하면 이점이 있는 경우도 있습니다.

  • 사용 가능한 더 많은 API: PowerShell cmdlet보다 더 많은 REST API를 사용할 수 있습니다. 그러나 Power BI REST API를 호출하는 데 사용할 수 있는 Invoke-PowerBIRestMethod cmdlet의 유연성을 간과하지 마세요.
  • 업데이트 빈도: Microsoft는 PowerShell 모듈을 업데이트하는 것보다 REST API를 더 자주 업데이트합니다. 예를 들어 새 특성이 데이터 세트 가져오기 API 응답에 추가되면 Get-PowerBIDataset cmdlet의 결과에서 사용할 수 있게 되기까지 다소 시간이 걸릴 수 있습니다.
  • 언어/도구 종속성 감소: cmdlet 대신 REST API를 직접 사용하는 경우 PowerShell을 사용할 필요가 없습니다. 또는 스크립트에서 많은 API 호출을 조정하는 데에만 PowerShell을 사용하도록 선택할 수 있습니다. PowerShell에 대한 종속성을 제거(또는 방지)하여 나중에 논리를 다른 언어로 다시 작성할 수 있습니다. IT 또는 개발자 팀이 도구 및 언어에 대한 선호도가 강한 경우 종속성을 줄이는 것이 중요한 고려 사항이 될 수 있습니다.

어떤 방법을 선택하든 REST API는 시간이 지남에 따라 변경될 수 있습니다. 기술이 발전하면 API(및 PowerShell 모듈)가 더 이상 사용되지 않고 교체될 수 있습니다. 따라서 유지 관리가 간단하고 탄력적으로 변경할 수 있는 스크립트를 의도적으로 만드는 것이 좋습니다.

검사 목록 - REST API에 직접 액세스할지 또는 PowerShell cmdlet을 사용하여 액세스할지 선택 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • PowerShell 사용에 관해 IT 팀에 문의: 관련 IT 팀에 문의하여 PowerShell 사용 방법에 대한 기존 내부 요구 사항이나 기본 설정이 있는지 확인하세요.
  • PowerShell 사용 방법 결정: 사용할 PowerShell 기법과 PowerShell에 대한 종속성을 의도적으로 늘리거나 줄일 것인지 결정합니다. 내부 통신 또는 교육이 필요한지 여부를 고려합니다.
  • PowerShell Core로 업그레이드: PowerShell Core를 사용하여 조사합니다. 관리자 컴퓨터를 업데이트해야 하는지 여부를 결정합니다. 어떤 기존 스크립트를 테스트해야 하는지 고려하세요. 관리자나 개발자가 기술을 업그레이드하기 위해 추가 교육이 필요한지 여부를 결정합니다.
  • 사용할 PowerShell 모듈 결정: Power BI 관리 모듈 및/또는 데이터 게이트웨이 모듈을 사용할지 여부를 고려합니다.
  • 커뮤니티 프로젝트 허용 여부 결정: Microsoft에서 게시한 모듈과 비교하여 온라인으로 제공되는 PowerShell 모듈을 사용하는 것이 허용되는지(또는 권장되는지) 결정합니다. 온라인으로 획득한 커뮤니티 프로젝트에 대한 기준이 있는지 확인하려면 IT 팀에 문의하세요.
  • 커뮤니티 프로젝트 지원 방법 명시: PowerShell 커뮤니티 프로젝트가 허용되는 경우 프로젝트가 내부적으로 사용되면 누가 지원할 책임이 있는지 고려하세요.
  • 간단한 POC(개념 증명) 완료: 기술 POC를 실험해 보세요. 원하는 클라이언트 도구 및 데이터 액세스 방법을 확인합니다.
  • 고급 사용자 지원 방법 결정: 사용자 API를 사용하여 스스로 자동화를 생성하는 기술 사용자를 지원할 방법을 고려합니다.

감사 데이터를 저장할 위치 결정

엔드투엔드 감사 솔루션을 구축할 계획이라면 원시 데이터(및 다음 섹션에서 다루는 큐레이팅된 데이터)를 저장할 위치를 결정해야 합니다. 데이터 스토리지에 대한 결정은 데이터 통합 처리 방법에 대한 선호와 관련이 있습니다.

원시 감사 데이터를 추출하는 경우 간소화하세요. 처음 데이터를 추출하는 경우 특정 특성을 선택하거나, 변환을 수행하거나, 서식을 적용하지 않는 것이 좋습니다. 대신 사용 가능한 모든 특성을 추출하고 데이터를 원래 상태로 저장하세요.

원시 데이터를 원래 상태로 저장하는 것이 모범 사례인 몇 가지 이유는 다음과 같습니다.

  • 기록에서 사용 가능한 모든 데이터: 시간이 지남에 따라 새로운 특성과 새로운 이벤트 유형을 사용할 수 있게 됩니다. 모든 원시 데이터를 저장하는 것은 추출 시 사용 가능한 모든 데이터에 항상 액세스할 수 있는 좋은 방법입니다. 새로운 데이터 특성을 사용할 수 있다는 사실을 깨닫는 데 몇 주 또는 몇 달이 걸릴 수도 있지만 원시 데이터에서 캡처했기 때문에 기록 분석이 가능합니다.
  • 변경에 대한 복원력이 있음: 원시 데이터 형식이 변경되더라도 데이터를 추출하는 프로세스는 영향을 받지 않습니다. 일부 감사 데이터는 시간에 민감하므로 원본에서 변경이 발생할 때 실패하지 않는 데이터 추출 프로세스를 설계하는 것이 중요합니다.
  • 역할 및 책임: 다양한 팀 멤버(예: 데이터 엔지니어 또는 패브릭 관리자)가 원시 감사 데이터에 액세스하고, 추출하고, 저장하는 프로세스를 만드는 일을 담당할 수 있습니다. 데이터 추출 프로세스를 간소화하면 여러 팀이 더 쉽게 협력할 수 있습니다.

원시 데이터를 저장하기 위한 몇 가지 옵션은 다음과 같습니다.

  • 데이터 레이크 또는 개체 스토리지: 모든 구조의 파일 저장에 특화된 OneLake와 같은 클라우드 서비스입니다. 원시 감사 데이터를 저장하는 데 이상적인 선택입니다. 데이터 레이크 아키텍처에서 원시 데이터는 브론즈 레이어에 저장되어야 합니다.
  • 파일 시스템: 파일 시스템(예: Windows 또는 Linux)은 원시 감사 데이터를 저장하는 데 일반적으로 선택됩니다.
  • 데이터베이스: Azure SQL Database와 같은 관계형 데이터베이스에 JSON 데이터를 저장할 수 있습니다. 그러나 데이터 레이크 또는 파일 시스템에 데이터를 저장하는 것보다 덜 일반적입니다. 특히 데이터 볼륨이 증가함에 따라 JSON 데이터를 쿼리하고 유지 관리하는 것이 어렵고 비용이 많이 들 수 있기 때문입니다.

팁

데이터 레이크, 개체 스토리지 또는 파일 시스템을 사용하는 경우 쉽게 구성하고 보호할 수 있는 방식으로 데이터를 저장하는 것이 좋습니다. 또한 데이터가 이벤트(일반적으로 추가됨)로 구성되어 있는지 또는 특정 시점 스냅샷(분석할 날짜를 선택해야 함)인지 여부를 명확히 하는 것도 중요합니다.

데이터 레이크의 원시 데이터 영역과 관련된 예제를 생각해 보세요. 영역에는 활동 로그 데이터를 저장하기 위한 폴더 계층 구조(원시 > ActivityLog > YYYY > MM)가 있습니다. 폴더는 연도와 월별로 구분되어 있습니다. 월 폴더에 저장된 파일은 PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json 형식을 사용합니다. YYYYMMDD는 실제 데이터를 나타내고 YYYYMMDDTTTT는 추출 타임스탬프를 나타냅니다. 데이터를 다시 추출해야 하는 경우 추출 타임스탬프를 포함하면 어떤 파일이 최신인지 확인할 수 있습니다. 예를 들어 2023년 4월 23일 작업에 대해 2023년 4월 25일 오전 9시(UTC)에 데이터를 추출하는 경우 파일 이름은 PBIActivityLog-20230523-202305250900이 됩니다.

원시 데이터를 변경이 불가능한 스토리지에 기록할 수 있는 기술을 사용하는 것이 좋습니다. 변경이 불가능한 스토리지는 데이터가 일단 기록되면 덮어쓰거나 삭제할 수 없도록 보장합니다. 감사자에게 이러한 구분은 중요하며 이를 통해 원시 데이터의 신뢰성을 신뢰할 수 있습니다.

또한 원시 데이터를 안전하게 저장하는 방법도 고려해야 합니다. 일반적으로 원시 데이터에 액세스해야 하는 사용자는 거의 없습니다. 원시 데이터에 대한 액세스는 일반적으로 필요에 따라 데이터 엔지니어와 시스템 관리자에게 제공됩니다. 내부 감사자가 액세스해야 할 수도 있습니다. 큐레이팅된 데이터 만들기(다음에 설명됨)를 담당하는 팀 멤버도 원시 데이터에 액세스해야 합니다.

원시 데이터 스토리지를 선택하는 데 도움이 되는 몇 가지 고려 사항은 다음과 같습니다.

  • 수동 감사 프로세스인가요, 아니면 자동 감사 프로세스인가요? 자동화된 감사 프로세스에는 일반적으로 데이터 저장 방법과 위치에 대한 요구 사항이 더 엄격합니다.
  • 주제 영역이 특히 중요한가요? 데이터 형식과 해당 데이터의 민감도에 따라 조직에서는 해당 데이터를 저장하는 방법과 위치에 대한 요구 사항이 있을 수 있습니다. Power BI 감사 데이터에는 사용자 식별 정보와 IP 주소가 포함되어 있으므로 안전한 영역에 저장해야 합니다.
  • 기본 설정 스토리지 기술이 있나요? 조직 내에서 사용 중인 기존 스토리지 기술이 있을 수 있으므로 이는 논리적인 선택입니다.
  • 사용자가 스토리지에 직접 액세스하나요? 보안 모델은 중요한 고려 사항입니다. 일반적으로 원시 데이터에 대한 액세스 권한이 부여되는 사용자는 거의 없습니다. 큐레이팅된 데이터에 대한 액세스는 일반적으로 중앙 집중식 데이터 모델(보고를 위한 계층 역할을 하는 의미 체계 모델) 만들기를 담당하는 Power BI 콘텐츠 작성자에게 제공됩니다.
  • 데이터 상주 요구 사항이 있나요? 일부 조직에는 특정 데이터 지역에 데이터를 저장하기 위한 법적 또는 규제 데이터 상주 요구 사항이 있습니다.
  • 데이터는 어떻게 구성되나요? 메달리온 아키텍처를 사용하는 것은 특히 데이터 레이크 및 레이크하우스 구현에서 일반적인 관행입니다. 목표는 데이터를 브론즈, 실버, 골드 데이터 계층에 저장하는 것입니다. 브론즈 계층에는 원래 원시 데이터가 포함되어 있습니다. 실버 계층에는 변환에 사용되는 유효성이 검사되고 중복이 제거된 데이터가 포함되어 있습니다. 골드 계층에는 분석 준비가 되어 있는 큐레이팅되고 고도로 정제된 데이터가 포함되어 있습니다.

검사 목록 - 원시 데이터를 저장할 위치 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • IT 팀에 문의: 관련 IT 팀에 문의하여 원시 감사 데이터를 추출하기 위해 실행 중인 기존 프로세스가 있는지 확인합니다. 그렇다면 기존 데이터에 액세스할 수 있는지 여부를 확인합니다. 새로운 데이터 추출 프로세스가 필요한 경우 데이터를 저장해야 하는 위치에 대한 기본 설정이나 요구 사항이 있는지 확인합니다.
  • 원시 데이터 저장 위치 결정: 원시 데이터 저장에 가장 적합한 저장 위치와 구조를 결정합니다.
  • 데이터 상주 요구 사항 결정: 데이터를 저장할 수 있는 위치에 대한 법적 또는 규제 요구사항이 있는지 알아봅니다.
  • 폴더 구조 및 명명 규칙 만들기: 폴더 구조를 포함하여 원시 데이터 파일에 사용할 명명 규칙을 결정합니다. 기술 문서에 이러한 세부 정보를 포함합니다.
  • 원시 데이터 보안 작동 방식 고려: 원시 데이터 저장 위치를 설계하는 동안 데이터에 액세스해야 하는 사람과 액세스 권한을 부여하는 방법을 고려합니다.

큐레이팅된 데이터 만들기 계획

큐레이팅된 데이터는 분석을 지원하며 사용자 친화적으로 설계되었습니다. 큐레이팅된 데이터를 만드는 방법과 위치에 대한 몇 가지 결정을 내려야 합니다. 큐레이팅된 데이터를 저장하기 위해 선택한 기술은 이전 섹션에 나열된 기술 중 하나일 수 있습니다.

큐레이팅된 데이터의 목표는 데이터를 분석 및 보고에 최적화된 더 친숙한 형식으로 변환하는 것입니다. 이는 Power BI 데이터 모델의 데이터 원본을 형성합니다. 즉, Power BI 데이터 모델을 사용하여 조직의 Power BI 사용량을 분석한다는 의미입니다. 기본 데이터 모델 지침이 적용됩니다. 성능과 유용성에 최적화된 별모양 스키마 디자인을 채택해야 합니다.

다양한 방법으로 큐레이팅된 데이터를 만들도록 선택할 수 있습니다. 데이터 통합을 수행하는 방법과 별모양 스키마에 로드할 데이터를 준비하는 변환을 적용할 업스트림 정도를 결정해야 합니다.

데이터 레이크

데이터 레이크에서 변환을 적용하고 큐레이팅된 데이터 파일을 만들 수 있습니다. 브론즈 계층에 저장된 원시 데이터와 논리적으로 분리되도록 큐레이팅된 데이터에는 골드 계층을 사용해야 합니다. 데이터를 계층으로 분리하면 다양한 사용자 액세스 권한 설정도 간소화됩니다.

다음과 같은 경우 데이터 레이크를 사용하여 데이터를 변환하고 큐레이팅합니다.

  • 보고를 제공하는 여러 Power BI 데이터 모델이 있을 것으로 예상합니다(중간 실버 계층 만들기를 정당화함).
  • 테넌트 수준 감사 데이터에 액세스해야 하는 여러 셀프 서비스 콘텐츠 작성자를 지원해야 합니다.
  • 데이터를 변환하고 로드하는 데 사용하려는 기존 도구와 프로세스가 있습니다.
  • 하나 이상의 Power BI 데이터 모델 내에서 수행해야 하고 잠재적으로 중복되는 데이터 준비를 최소화하려고 합니다.
Power BI 데이터 모델

Power BI에서 모든 변환 작업을 완료할 수도 있습니다. 파워 쿼리를 사용하여 데이터에 액세스하고 원시 상태에서 큐레이팅된 형식으로 변환합니다.

다음과 같은 경우 Power BI 데이터 모델을 사용합니다.

  • 엔드투엔드 아키텍처를 간소화하고 원시 데이터에서 직접 데이터 모델을 로드하려고 합니다. (증분 새로 고침은 새로 고침 기간을 줄이는 데 도움이 될 수 있습니다.)
  • 기본 설정은 데이터 모델을 로드하는 동안 모든 변환 작업을 수행하는 것입니다.
  • 테넌트 수준 감사 데이터에 대해 하나의 중앙 집중식 데이터 모델이 있을 것으로 예상합니다. 모든 보고서(또는 기타 데이터 모델)는 중앙 집중식 Power BI 의미 체계 모델을 원본으로 사용할 수 있습니다.
  • 원본 데이터가 아닌 중앙 집중식 Power BI 의미 체계 모델에만 사용자 액세스를 제공하려고 합니다.

팁

큐레이팅된 데이터를 만들 때 이전 기간에 대해 프로세스를 쉽게 다시 실행할 수 있도록 설정하세요. 예를 들어 3개월 전에 감사 로그에 새로운 특성이 나타난 것을 발견한 경우 해당 특성이 처음 나타난 이후 분석할 수 있어야 합니다. 큐레이팅된 데이터 기록을 다시 로드하는 기능은 원시 데이터를 원래 상태로 저장하는 것이 중요한 몇 가지 이유 중 하나입니다(이 문서의 앞부분에서 설명).

별모양 스키마에 포함할 수 있는 차원 테이블과 팩트 테이블에 대한 자세한 내용은 이 문서의 뒷부분에 있는 데이터 모델 만들기를 참조하세요.

검사 목록 - 큐레이팅된 데이터를 만드는 방법 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 변환을 수행해야 하는 위치 결정: 변환 작업을 어느 정도까지 업스트림으로 수행해야 하는지와 전체 아키텍처에 대한 계획에서 해당 작업이 어디에 적합한지를 고려합니다.
  • 데이터를 별모양 스키마로 변환하는 데 사용할 도구 결정: 원시 데이터를 큐레이팅된 데이터로 변환하는 데 사용할 도구와 서비스를 확인합니다.
  • 큐레이팅된 데이터를 저장할 위치 결정: 별모양 스키마 형식으로 변환된 원시 데이터를 저장하기 위한 최선의 선택을 결정합니다. 중간 실버 계층이 엔드투엔드 아키텍처에 유용한지 여부를 결정합니다.
  • 명명 규칙 만들기: 큐레이팅된 데이터 파일 및 폴더에 사용할 명명 규칙을 결정합니다(해당하는 경우). 기술 문서에 세부 정보를 포함합니다.
  • 큐레이팅된 데이터의 보안 작동 방식 고려: 큐레이팅된 데이터 저장 위치를 설계하는 동안 데이터에 액세스해야 하는 사람과 보안이 할당되는 방법을 고려합니다.

데이터 원본 결정 사항

이 시점에서는 요구 사항, 데이터 요구 사항, 권한을 명확히 해야 합니다. 주요 기술적 결정이 내려졌습니다. 이제 특정 형식의 데이터를 가져오는 방법에 대한 몇 가지 결정을 내려야 합니다.

사용자 작업 데이터에 액세스

활동 로그 또는 감사 로그라고도 하는 Power BI 사용자 작업 데이터에는 Power BI 테넌트에서 발생하는 상황을 이해하는 데 도움이 되는 풍부한 정보가 포함되어 있습니다. 데이터 요구 사항 파악에 대한 자세한 내용은 이 문서 앞부분의 사용자 작업 데이터를 참조하세요.

Power BI는 로그를 Microsoft Purview 통합 감사 로그(이전의 Microsoft 365 통합 감사 로그)와 통합합니다. 이러한 통합은 Microsoft 365 내의 모든 서비스가 고유한 로깅 방식을 구현할 필요가 없다는 점에서 이점이 있습니다. 기본적으로 사용하도록 설정되어 있습니다.

Important

아직 사용자 작업 데이터를 추출하고 있지 않다면 이를 긴급한 우선 순위로 지정하세요. 사용자 작업 데이터는 최근 30일 또는 90일 동안의 데이터를 사용할 수 있습니다(원본에 따라 다름). 심층 분석을 수행할 준비가 되지 않은 경우에도 가능한 한 빨리 데이터 추출과 저장을 시작하는 것이 중요합니다. 이렇게 하면 중요한 기록을 분석할 수 있습니다.

사용자 작업 데이터를 검색하는 몇 가지 옵션이 있습니다.

기법 설명 사용 가능한 기록의 기본 일수 수동 감사 프로세스에 적합한 선택 자동화된 감사 프로세스에 적합한 선택 알림 설정을 위한 좋은 선택 빠른 시작을 위한 좋은 선택
수동(사용자 인터페이스) Microsoft Purview 규정 준수 포털 90 Microsoft Purview 규정 준수 포털은 수동 감사 프로세스에 적합한 선택입니다. Microsoft Purview 규정 준수 포털은 빠르게 시작하는 데 적합한 선택입니다.
수동(사용자 인터페이스) 클라우드용 Defender 앱 30 Defender for Cloud Apps는 수동 감사 프로세스에 적합한 선택입니다. Defender for Cloud Apps는 경고를 설정하는 데 적합한 선택입니다.
프로그래밍 방식 Power BI 활동 로그(API 또는 PowerShell cmdlet) 30 Power BI 활동 로그(API 또는 PowerShell cmdlet)는 자동화된 감사 프로세스에 적합한 선택입니다. Power BI 활동 로그(API 또는 PowerShell cmdlet)는 빠르게 시작하는 데 적합한 선택입니다.
프로그래밍 방식 Office 365 관리 작업 API 7 Office 365 관리 작업 API는 자동화된 감사 프로세스에 적합한 선택입니다.
프로그래밍 방식 Microsoft Sentinel(Azure Monitor) 30 Microsoft Sentinel(Azure Monitor)은 자동화된 감사 프로세스에 적합한 선택입니다. Microsoft Sentinel(Azure Monitor)은 경고를 설정하는 데 적합한 선택입니다.

이 섹션의 나머지 부분에서는 테이블에 제시된 각 기법을 소개합니다.

Microsoft Purview 규정 준수 포털

Microsoft Purview 규정 준수 포털(이전의 Microsoft 365 규정 준수 센터)의 감사 검색 도구는 작업과 경고를 볼 수 있는 편리한 장소입니다. 이 도구를 사용하면 데이터를 추출하고 다운로드하기 위한 스크립트를 만들 필요가 없습니다. Power BI 워크로드를 선택하여 일정 기간 동안 모든 감사 로그 레코드를 볼 수 있습니다. 특정 활동과 사용자를 선택하여 결과의 범위를 좁힐 수도 있습니다. 예를 들어 관리자는 상황을 논의하기 위해 그 사람에게 빠르게 연락할 수 있도록 그날 일찍 작업 영역을 삭제한 사람이 누구인지 알아내라고 요청합니다.

감사(표준)를 통해 최근 90일간의 기록을 확인할 수 있습니다. 감사(프리미엄)를 사용하면 장기 보존을 통해 감사 로그를 더 오랫동안 보존할 수 있습니다(선택 사항). 장기 보존은 라이선스가 있는 E5 사용자에게만 적용되므로 E5가 아닌 사용자와 게스트 사용자에 대한 감사 기록은 제외됩니다. 따라서 모든 활동이 캡처되도록 하려면 기본 90일 기록만 사용하는 것이 좋습니다.

Microsoft Purview 규정 준수 포털의 감사 로그에 액세스하려면 라이선스 요구 사항이 있습니다. 감사 로그에 액세스하려면 높은 Exchange Online 권한도 필요합니다.

팁

기본적으로 Power BI 관리자에게는 Microsoft Purview 규정 준수 포털의 통합 감사 로그 검색에 액세스할 수 있는 권한이 없습니다. 여기에는 많은 Microsoft 365 서비스에 대한 데이터가 포함되어 있으므로 높은 권한의 역할입니다. 대부분의 조직에서 이러한 권한은 소수의 IT 관리자에게만 예약되어 있습니다. Power BI 관리자가 사용할 수 있는 다른 옵션이 있으며 이에 대해서는 이 섹션의 뒷부분에서 설명합니다.

Microsoft Purview 규정 준수 포털의 사용자 인터페이스는 수동 감사 프로세스와 사용자 활동에 대한 가끔 수행하는 조사에 유용합니다.

클라우드용 Defender 앱

클라우드용 Defender 앱의 포털은 데이터를 추출하고 다운로드하기 위한 스크립트를 만들 필요 없이 활동과 알림을 볼 수 있는 편리한 장소입니다. 또한 Power BI 활동 로그 및 사용자 로그인의 데이터를 볼 수도 있습니다.

클라우드용 Defender 앱에는 Power BI를 포함한 다양한 클라우드 서비스에 대한 활동 로그를 보고 검색할 수 있는 사용자 인터페이스가 포함되어 있습니다. 여기에는 Microsoft Purview 통합 감사 로그에서 발생한 동일한 로그 이벤트가 표시되며 Microsoft Entra ID의 사용자 로그인 활동과 같은 다른 이벤트도 포함됩니다.

Microsoft Purview 규정 준수 포털(이전 섹션에서 설명)과 마찬가지로 클라우드용 Defender 앱에는 검색 가능한 사용자 인터페이스가 있습니다. 그러나 필터 옵션은 다릅니다. 표준 30일 기록 외에도 클라우드용 Defender 앱을 사용하여 최대 6개월의 활동 로그 기록(7일 단위)을 볼 수 있습니다.

클라우드용 Defender 앱에 액세스하려면 라이선스 요구 사항이 있습니다. 별도의 권한도 필요합니다.

팁

기본적으로 Power BI 관리자에게는 클라우드용 Defender 앱에 액세스할 수 있는 권한이 없습니다. 클라우드용 Defender 앱에는 Power BI 역할이 있습니다. 이 역할에 Power BI 관리자를 추가하는 것은 제한된 데이터 세트에 대한 액세스 권한을 부여하는 좋은 방법입니다.

클라우드용 Defender 앱의 사용자 인터페이스는 수동 감사 프로세스와 사용자 활동에 대한 일회성 조사에 유용합니다.

Power BI 활동 로그

Power BI 활동 로그는 통합 감사 로그에서 시작됩니다. Power BI 서비스와 관련된 사용자 활동만 포함됩니다.

팁

사용자 활동을 추출하려는 조직의 경우 Power BI 활동 로그부터 시작하는 것이 좋습니다. 프로그래밍 방식으로 액세스할 수 있는 가장 간단한 원본입니다.

Power BI 활동 로그에 액세스하는 두 가지 옵션이 있습니다.

사용할 옵션에 대한 자세한 내용은 이 문서 앞부분의 API 또는 PowerShell cmdlet 선택을 참조하세요.

팁

PowerShell을 사용하여 Power BI 활동 로그에 액세스하는 방법에 대한 예는 Power BI 활동 로그 액세스를 참조하세요.

Power BI 활동 로그 데이터는 모든 패브릭 관리자와 Power Platform 관리자가 사용할 수 있습니다. 특정 Exchange Online 역할이 사용할 수 있는 통합 감사 로그에서 데이터에 액세스할 수 있습니다. 자세한 내용은 Power BI에서 사용자 활동 추적을 참조하세요.

Power BI 감사 로그 레코드만 검색하려는 경우 Power BI 활동 로그를 사용하는 것이 좋습니다.

참고 항목

감사 로그 데이터에서는 작업 영역을 폴더라고 합니다. Power BI REST API에서는 작업 영역을 그룹이라고 합니다.

Office 365 관리 작업 API

SharePoint Online, Teams, Exchange Online, Dynamics 365, Power BI와 같은 다른 서비스에 대한 통합 감사 로그에서 데이터를 추출할 수 있습니다. 여러 서비스에 대한 감사 및 모니터링 솔루션을 구현하는 것이 목표라면 Office 365 관리 작업 API를 사용하는 것이 좋습니다. 이 API는 여러 서비스에서 데이터를 반환하므로 통합 감사 API(또는 통합 감사 로그)라고 합니다. 이는 Office 365 관리 API 중 하나입니다.

새 솔루션을 빌드하기 전에 IT 팀에 문의하여 기존 Power BI 감사 레코드를 사용할 수 있는지 확인하는 것이 좋습니다. 프로세스가 이미 데이터를 추출하고 저장했을 수도 있습니다. 새로운 솔루션을 구축하는 대신 이 데이터에 액세스할 수 있는 권한을 얻을 수도 있습니다.

두 가지 방법 중 하나로 데이터에 액세스할 수 있습니다.

  • 원하는 도구를 사용하여 Office 365 관리 작업 API를 직접 호출합니다. 기본적으로 API는 24시간 동안의 데이터를 반환합니다. 최대 7일의 기록을 검색할 수 있습니다.
  • Search-UnifiedAuditLog PowerShell cmdlet을 사용하세요. Exchange Online PowerShell cmdlet입니다. 최대 90일의 기록을 검색할 수 있습니다.

Important

Search-UnifiedAuditLog cmdlet은 확장이 잘 되지 않으며 5,000개 행 제한을 극복하려면 반복 전략을 구현해야 합니다. 이러한 이유로 가끔 쿼리를 수행하거나 활동이 적은 소규모 조직에 적합합니다. Power BI 데이터만 필요한 경우 대신 Get-PowerBActivityEvent cmdlet을 사용하는 것이 좋습니다.

일반적으로 Office 365 관리 작업 API를 시작하는 것은 Power BI 활동 로그(이전에 설명함)를 사용하는 것보다 더 어렵습니다. 이는 API가 콘텐츠 Blob을 반환하고 각 콘텐츠 Blob에 개별 감사 레코드가 포함되어 있기 때문입니다. 대규모 조직의 경우 하루에 수천 개의 콘텐츠 Blob이 있을 수 있습니다. 고객과 타사 애플리케이션이 이 API를 많이 사용하기 때문에 Microsoft는 서비스 사용이 다른 애플리케이션에 부정적인 영향을 주지 않도록 제한을 구현합니다(시끄러운 이웃 문제라고도 함). 따라서 대규모 조직에서는 많은 양의 기록을 검색하는 것이 어려울 수 있습니다. 자세한 내용은 이 문제 해결 문서를 참조하세요.

이 API를 사용하려면 Office 365 관리 작업 API에서 데이터를 검색할 수 있는 권한이 부여된 서비스 주체로 인증해야 합니다.

팁

기본적으로 Power BI 관리자에게는 Office 365 관리 작업 API에 액세스할 수 있는 권한이 없습니다. 여기에는 많은 Microsoft 365 서비스에 대한 데이터가 포함되어 있으므로 액세스하려면 높은 권한의 관리자 또는 감사 역할이 필요합니다. 대부분의 조직에서 이러한 역할은 소수의 IT 관리자에게 예약되어 있습니다. Power BI 활동 로그는 Power BI 관리자가 사용하기 위한 것입니다.

Office 365 관리 작업 API에서 프로그래밍 방식으로 감사 데이터를 검색하는 것은 IT가 Power BI 이외의 다양한 서비스에서 감사 로그를 추출하고 저장해야 하는 경우 좋은 선택입니다.

Microsoft Sentinel

Microsoft Sentinel은 보안 인시던트 및 위협을 수집, 감지, 조사, 대응할 수 있는 Azure 서비스입니다. Microsoft Sentinel에서 Power BI를 데이터 커넥터로 설정할 수 있습니다. 연결되면 감사 로그(데이터 하위 세트 포함)가 Power BI에서 Azure Monitor의 기능인 Azure Log Analytics로 스트리밍됩니다.

팁

Azure Log Analytics는 작업 영역 수준 의미 체계 모델 이벤트 로그에서 사용되는 것과 동일한 아키텍처를 기반으로 합니다. 의미 체계 모델 이벤트 로그에 대한 자세한 내용은 데이터 수준 감사를 참조하세요.

별도의 Azure 서비스이기 때문에 KQL(Kusto 쿼리 언어) 쿼리를 실행하려는 모든 관리자 또는 사용자에게 Azure Log Analytics(Azure Monitor)에서 권한을 부여해야 합니다. 권한이 있는 경우 PowerBIActivity 테이블에 저장된 감사 데이터를 쿼리할 수 있습니다. 그러나 대부분의 경우 사용자에게 브론즈 계층의 원시 데이터가 아닌 골드 계층의 큐레이팅된 데이터에 대한 액세스 권한을 부여한다는 점에 유의하세요.

KQL을 사용하여 Azure Log Analytics에 저장된 활동 로그 이벤트를 분석합니다. SQL 경험이 있다면 KQL과 많은 유사점을 찾을 수 있습니다.

Azure Log Analytics에 저장된 이벤트에 액세스하는 방법에는 여러 가지가 있습니다. 다음을 사용할 수 있습니다.

  • 미리 빌드된 Power BI 의미 체계 모델용 Log Analytics 템플릿 앱입니다.
  • Azure Data Explorer용 Power BI Desktop 커넥터(Kusto).
  • Azure Data Explorer의 웹 기반 쿼리 환경.
  • KQL 쿼리를 보낼 수 있는 모든 쿼리 도구입니다.

주의

Power BI 활동 로그 데이터의 하위 집합만 Azure Monitor에 저장된다는 점에 유의하세요. 조직의 Power BI 사용 및 채택에 대한 포괄적인 분석을 수행하려는 경우 다른 옵션(이 섹션의 앞부분에서 설명)을 사용하여 활동 데이터를 검색하는 것이 좋습니다.

검색할 수 있는 기록 기간은 Azure Log Analytics 작업 영역의 데이터 보존 정책에 따라 다릅니다. 보존할 데이터의 양을 결정할 때 비용과 원시 데이터에 대한 액세스를 고려합니다.

Microsoft Sentinel과 Azure Monitor는 IT가 이미 Microsoft Sentinel에 투자했고, 캡처된 세부 정보 수준이 요구 사항을 충족하며, 위협 탐지와 같은 작업이 우선 순위인 경우 좋은 옵션입니다. 그러나 Microsoft Sentinel은 모든 Power BI 활동 데이터를 캡처하지 않으므로 Power BI 사용 및 채택에 대한 포괄적인 분석 수행을 지원하지 않습니다.

사용자 활동 데이터 고려 사항

다음은 사용자 작업 데이터 원본을 선택하는 데 도움이 되는 몇 가지 고려 사항입니다.

  • 수동 감사 프로세스인가요, 아니면 자동화된 감사 프로세스인가요? 사용자 인터페이스 옵션은 수동 감사 프로세스와 가끔 발생하는 일회성 쿼리, 특히 특정 작업을 조사해야 하는 경우에 적합합니다. 기록 데이터 분석을 지원하려면 일정에 따라 사용자 활동 데이터를 추출하는 자동화된 감사 프로세스도 필요합니다.
  • 사용자 활동 데이터는 얼마나 자주 필요한가요? 자동화된 감사 프로세스의 경우 현지 시간이 아닌 UTC(협정 세계시)를 사용하여 현재 날짜보다 최소 하루 전의 데이터를 추출하도록 계획합니다. 예를 들어 프로세스가 금요일 오전(UTC 시간)에 실행되는 경우 수요일부터 데이터를 추출해야 합니다. 1일 대기 시간으로 데이터를 추출해야 하는 데에는 몇 가지 이유가 있습니다.
    • 항상 24시간 전체를 한 번에 추출하면 하루의 일부분만 추출하는 것을 피할 수 있으므로 파일 작업이 더 간편해집니다.
    • 일부 감사 이벤트가 누락될 위험을 최소화할 수 있습니다. 일반적으로 감사 이벤트는 30분 이내에 도착합니다. 경우에 따라 일부 이벤트가 통합 감사 로그에 도착하는 데 최대 24시간이 걸릴 수 있습니다.
  • Power BI 데이터 이상의 것이 필요한가요? 필요한 항목에 액세스하는 가장 효율적인 방법을 고려합니다.
  • 솔루션을 개발하는 사람은 누구인가요? 솔루션을 구축하는 데 시간을 투자할 계획을 수립합니다. 프로덕션 준비 스크립트를 생성하려면 상당한 노력이 필요할 수 있습니다.

검사 목록 - 사용자 활동 데이터에 액세스하는 방법 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 필요 범위 명확히 하기: Power BI 감사 레코드에만 액세스해야 하는지 아니면 여러 서비스에 대한 감사 데이터에 액세스해야 하는지 결정합니다.
  • IT 팀에 문의: IT 팀에서 현재 감사 로그를 추출하는지와 새로운 솔루션을 구축할 필요가 없도록 원시 데이터에 액세스할 수 있는지를 알아보세요.
  • 데이터 원본 결정: 사용자 작업 데이터에 액세스하는 데 사용할 가장 적합한 원본을 결정합니다.
  • 개념 증명 완료: 간단한 기술 POC(개념 증명)를 완료할 계획입니다. 이를 사용하여 최종 솔루션 구축 방법에 대한 결정을 검증합니다.
  • 추가 데이터 요구 사항 추적: 활동 로그 데이터를 다른 원본과 연관시켜 데이터의 가치를 높일 수 있습니다. 이러한 기회가 발생할 때마다 이를 추적하여 프로젝트 범위에 추가할 수 있습니다.

테넌트 인벤토리 데이터에 액세스

테넌트 인벤토리는 성숙한 감사 및 모니터링 솔루션의 매우 중요하고 필요한 부분입니다. 이는 Power BI에 어떤 작업 영역과 콘텐츠(의미 체계 모델, 보고서, 기타 항목)가 있는지 이해하는 데 도움이 되며, 사용자 활동 데이터(이전 섹션에서 설명함)를 훌륭하게 보완합니다. 데이터 요구 사항 식별에 대한 자세한 내용은 이 문서 앞부분의 테넌트 인벤토리를 참조하세요.

이전에 설명한 사용자 활동은 감사된 이벤트입니다. 이는 사용자가 특정 날짜와 시간에 수행한 작업에 대한 기록입니다. 그러나 테넌트 인벤토리는 다릅니다. 테넌트 인벤토리는 특정 시점의 스냅샷입니다. 이는 추출 당시 Power BI 서비스에 게시된 모든 항목의 현재 상태를 설명합니다.

참고 항목

Power BI REST API 문서에서는 게시된 항목을 아티팩트라고 합니다.

팁

많은 조직에서는 매주 같은 시간에 테넌트 인벤토리를 추출하는 것이 유용합니다.

Power BI 테넌트에서 발생하는 상황을 적절하게 분석하려면 사용자 작업 데이터와 테넌트 인벤토리가 모두 필요합니다. 이를 결합하면 보유하고 있는 콘텐츠의 양과 해당 콘텐츠의 위치를 이해할 수 있습니다. 또한 사용되지 않거나 활용도가 낮은 콘텐츠를 찾을 수 있습니다(활동 로그에 해당 콘텐츠에 대한 이벤트가 없기 때문). 테넌트 인벤토리는 또한 모든 항목의 현재 이름 목록을 컴파일하는 데 도움이 되며, 이는 항목 이름이 변경될 때 유용합니다.

테넌트 인벤토리 값에 대한 자세한 내용은 이 문서의 앞부분에 있는 테넌트 인벤토리를 참조하세요.

팁

관리자 권한으로 사용되지 않은 아티팩트 가져오기 API를 사용하면 지난 30일 동안 사용자 활동이 없는 항목을 검색할 수 있습니다. 그러나 해당 기간을 사용자 지정할 수는 없습니다. 예를 들어 분기별로만 사용되는 중요한 콘텐츠가 있을 수 있습니다. 테넌트 인벤토리를 사용자 활동 데이터와 결합하면 사용자 지정할 수 있는 방식으로 사용되지 않은 항목을 찾을 수 있습니다.

두 가지 방법으로 테넌트 인벤토리 데이터를 가져올 수 있습니다.

기법 설명 가장 적합한 항목 수동 감사 프로세스에 적합한 선택 자동화된 감사 프로세스에 적합한 선택
프로그래밍 방식 Get Groups as Admin API 또는 Get-PowerBIWorkspace PowerShell cmdlet은 전체 테넌트에 대한 작업 영역 목록을 제공할 수 있습니다. 작업 영역당 개별 항목(예: 의미 체계 모델 및 보고서)을 포함할 수 있습니다(선택 사항). 소규모 조직 또는 낮은 데이터 볼륨 그룹을 관리자 API로 가져오기 또는 Get-PowerBIWorkspace PowerShell cmdlet은 수동 감사 프로세스에 적합한 선택입니다. 그룹을 관리자 API로 가져오기 또는 Get-PowerBIWorkspace PowerShell cmdlet은 자동화된 감사 프로세스에 적합한 선택입니다.
프로그래밍 방식 메타데이터 검사 API 또는 스캐너 API로 통칭되는 비동기 관리자 API 집합은 작업 영역 및 개별 항목 목록을 반환할 수 있습니다. 자세한 메타데이터(예: 테이블, 열, 측정 식)도 포함될 수 있습니다(선택 사항). 데이터 양이 많거나 자세한 결과를 얻어야 하는 조직 메타데이터 검사 API는 자동화된 감사 프로세스에 적합한 선택입니다.

이 섹션의 나머지 부분에서는 테이블에 제시된 각 기법을 소개합니다.

그룹 API 또는 작업 영역 cmdlet

작업 영역 목록을 검색하려면 관리자 권한으로 그룹 가져오기 API(원하는 도구 사용)와 같은 여러 REST API 중 하나를 사용할 수 있습니다. 결과에는 설명 및 작업 영역이 프리미엄 용량에 저장되어 있는지 여부와 같은 추가 메타데이터가 포함되어 있습니다.

참고 항목

명명된 API에는 작업 영역에 대한 참조로 그룹이라는 용어가 포함되어 있습니다. 이 용어는 Microsoft 365 그룹을 기반으로 한 원래 Power BI 보안 모델에서 유래되었습니다. Power BI 보안 모델은 수년에 걸쳐 크게 발전했지만 기존 솔루션이 손상되지 않도록 기존 API 이름은 변경되지 않은 상태로 유지됩니다.

Get Groups as Admin REST API에는 유용한 $expand 매개 변수가 포함되어 있습니다. 이 매개 변수를 사용하면 작업 영역에 게시된 항목 목록(예: 의미 체계 모델 및 보고서)이 포함되도록 선택적으로 결과를 확장할 수 있습니다. 또한 users 데이터 형식을 $expand 매개 변수에 전달하여 작업 영역 역할에 할당된 사용자를 포함할 수도 있습니다.

Get-PowerBIWorkspace PowerShell cmdlet을 사용할 수도 있습니다. Power BI 관리 작업 영역 모듈에서 가져온 것입니다. -Scope 매개 변수 organization을 설정하면 Get Groups as Admin API처럼 작동합니다. 또한 cmdlet은 -Include 매개 변수(REST API의 $expand 매개 변수와 동일)를 허용하여 작업 영역에 게시된 항목(예: 의미 체계 모델 및 보고서)을 포함합니다.

팁

매개 변수를 전달하면 cmdlet을 다양한 방법으로 사용할 수 있습니다. 이 섹션에서는 테넌트 전체 인벤토리를 검색하는 데 중점을 둡니다. -Scope 매개 변수 사용에 대한 자세한 내용은 이 문서의 앞부분에 있는 사용자 API 또는 관리자 API 선택을 참조하세요.

사용할 옵션을 선택하는 데 도움이 필요한 경우 이 문서의 앞부분에 있는 API 또는 PowerShell cmdlet 선택을 참조하세요.

Get Groups as Admin REST API 또는 Get-PowerBIWorkspace PowerShell cmdlet은 수동 감사 프로세스 및 일회성 조사에 가장 적합합니다. 데이터 양이 많은 대규모 조직에서는 일반적으로 이러한 옵션을 사용하기가 어렵습니다. REST API 및 cmdlet은 항상 전체 데이터 세트를 추출하므로 실행하는 데 오랜 시간이 걸릴 수 있습니다. 따라서 대규모 조직에서는 시간당 허용되는 요청 수에 대한 제한(서비스 상태를 보호하기 위해 수행되는 제한이라고 함)에 직면할 가능성도 있습니다. 메타데이터 검색 API(다음에 설명함)는 보다 안정적이고 확장 가능한 대안을 제공합니다.

메타데이터 검사 API

일반적으로 검사기 API라고 불리는 메타데이터 검색 API는 작업 영역 및 해당 Power BI 항목(의미 체계 모델, 보고서, 기타 항목) 목록을 반환하는 API 세트입니다. 개념적으로 이는 이전 섹션에서 설명한 그룹 API 또는 작업 영역 cmdlet과 동일한 데이터(및 그 이상)를 제공합니다. 그러나 데이터를 검색하는 데 사용하는 방법은 다르며 테넌트 인벤토리를 추출하는 데 더 적합합니다.

참고 항목

일부 사용자가 검사기 API라는 용어나 테넌트 검색이라는 문구를 어떻게 사용하는지 살펴보세요. 이러한 용어는 종종 사용자 활동 이벤트와 구분하여 테넌트 인벤토리를 컴파일한다는 의미로 사용됩니다. 이는 말 그대로 메타데이터 검사 API의 사용을 의미할 수도 있고 그렇지 않을 수도 있습니다.

Get Groups as Admin REST API 또는 Get-PowerBIWorkspace cmdlet(이전에 설명함) 대신 메타데이터 검색 API 사용을 고려해야 하는 두 가지 주요 이유가 있습니다.

  • 증분 데이터 추출: 검사기 API는 마지막 실행 이후 변경된 데이터만 추출합니다. 반대로 Get Groups as Admin REST API와 Get-PowerBIWorkspace cmdlet은 실행될 때마다 전체 데이터 세트를 추출하는 동기 작업입니다.
  • 더 세부적인 세부 정보 수준: 자세한 메타데이터에 대한 두 테넌트 설정에 의해 권한이 부여된 경우 검사기 API는 세부적인 세부 정보(예: 테이블, 열, 측정값 식)를 검색할 수 있습니다. 반대로 Get Groups as Admin REST API 및 Get-PowerBIWorkspace cmdlet에서 사용할 수 있는 가장 낮은 세부 정보 수준은 항목 유형별입니다(예: 작업 영역의 보고서 목록).

검사기 API를 사용하려면 일련의 API를 호출해야 하므로 더 많은 노력이 필요합니다. 또한 비동기 프로세스로 실행됩니다. 비동기 프로세스는 백그라운드에서 실행되므로 완료될 때까지 기다릴 필요가 없습니다. 예약될 프로덕션 준비 스크립트를 생성해야 할 때가 되면 IT 또는 개발자와 협력해야 할 수도 있습니다.

검사기 API를 사용할 때 프로세스가 따라야 하는 일련의 단계는 다음과 같습니다.

  1. 로그인: Power BI 관리자 계정 또는 관리자 API 실행 권한이 있는 서비스 주체를 사용하여 Power BI 서비스에 로그인합니다. 자세한 내용은 이 문서의 앞부분에 있는 인증 방법 결정을 참조하세요.
  2. 작업 영역 ID 가져오기: 작업 영역 ID 목록을 검색하라는 요청을 보냅니다. 처음 실행하면 날짜가 수정되지 않으므로 작업 영역의 전체 목록이 반환됩니다. 일반적으로 수정된 날짜를 전달하여 해당 시점 이후 변경된 작업 영역만 검색합니다. 수정된 날짜는 지난 30일 이내여야 합니다.
  3. 메타데이터 검사 시작: 2단계에서 검색한 작업 영역 ID를 전달하여 작업 영역 정보 검사를 요청하는 호출을 시작합니다. 이는 (감사 데이터를 검색할 때 더 일반적으로 사용되는 GET API 대신) POST API입니다. POST API는 지정된 리소스에 대한 데이터를 만들거나 쓰는 HTTP 요청입니다. 이 쿼리는 데이터 소스 세부 정보, 의미 체계 모델 스키마, 의미 체계 모델 식 또는 사용자와 같이 추출될 세부 정보 수준을 지정합니다. 제출하면 API에서 검사 ID를 반환합니다. 또한 스냅샷 날짜로 기록해야 하는 검사 날짜와 시간도 반환됩니다.
  4. 검사 상태 확인: 3단계에서 얻은 검사 ID를 사용하여 검사 상태를 확인합니다. 이 API를 두 번 이상 호출해야 할 수도 있습니다. 반환된 상태가 성공이면 다음 단계로 진행할 수 있습니다. 검사하는 데 걸리는 시간은 요청한 데이터의 양에 따라 다릅니다.
  5. 결과 가져오기: 3단계에서 얻은 검사 ID를 사용하여 검사 결과를 얻고 데이터를 추출합니다. 4단계를 완료한 후 24시간 이내에 이 단계를 수행해야 합니다. 스냅샷 타임스탬프는 5단계(상당한 지연이 있는 경우)가 아닌 3단계와 연관되어야 한다는 점에 유의하세요. 이렇게 하면 정확한 스냅샷 타임스탬프를 얻을 수 있습니다. 원하는 데이터 스토리지 위치에 결과를 저장하세요. 이 문서에서 이미 설명한 대로 원시 데이터를 원래 상태로 저장하는 것이 좋습니다.
  6. 다음 프로세스 준비: 다음에 프로세스를 실행할 때 2단계에서 사용할 수 있도록 3단계의 검사 타임스탬프를 기록하세요. 이렇게 하면 해당 시점 이후에 변경된 데이터만 추출하게 됩니다. 앞으로 모든 후속 데이터 추출은 전체 스냅샷이 아닌 증분 변경이 될 것입니다.

검사 목록 - 테넌트 인벤토리 데이터에 대한 액세스를 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 요구 사항 확인: 테넌트 인벤토리 컴파일에 대한 요구 사항과 데이터 분석 요구 사항을 명확히 합니다.
  • 테넌트 인벤토리 추출 빈도 결정: 새 테넌트 인벤토리가 필요한 빈도(예: 매주)를 확인합니다.
  • 테넌트 인벤토리를 추출하는 방법 결정: 테넌트 인벤토리 데이터(API, cmdlet 또는 메타데이터 검사 API)를 가져오는 데 사용할 방법을 확인합니다.
  • 개념 증명 완료: 간단한 기술 POC(개념 증명)를 완료할 계획입니다. 이를 사용하여 최종 솔루션 구축 방법에 대한 결정을 검증합니다.

사용자 및 그룹 데이터에 액세스

사용자 활동 데이터에 포함된 식별 정보(예: 메일 주소) 외에도 위치, 조직 세부 정보 등의 추가 정보를 검색하는 것도 중요합니다. Microsoft Graph를 사용하여 사용자, 그룹, 서비스 주체, 라이선스에 대한 데이터를 검색할 수 있습니다. Microsoft Graph는 다양한 서비스에서 감사 데이터를 검색할 수 있는 API 및 클라이언트 라이브러리 세트로 구성됩니다.

다음은 액세스할 수 있는 Microsoft Entra 개체에 대한 몇 가지 세부 정보입니다.

  • 사용자: Microsoft Entra ID에 직장, 학교 또는 Microsoft 계정으로 존재하는 ID입니다. 도메인 사용자라는 용어는 조직 사용자를 설명하는 데 자주 사용되는 반면, 공식적인 용어는 UPN(사용자 계정 이름)입니다. UPN은 일반적으로 사용자의 메일 주소와 동일한 값입니다. 그러나 메일 주소가 변경되는 경우 UPN은 변경할 수 없으므로 변경되지 않습니다. 각 사용자마다 고유한 Microsoft Graph ID도 있습니다. 종종 사용자 계정은 한 사용자와 연결됩니다. 일부 조직에서는 자동화된 활동이나 관리 작업에 사용되는 서비스 계정인 사용자를 만듭니다.
  • 서비스 주체: 앱 등록을 만들 때 프로비전되는 다른 유형의 ID입니다. 서비스 주체는 무인 자동화 활동을 위한 것입니다. 자세한 내용은 이 문서의 앞부분에 있는 인증 방법 결정을 참조하세요.
  • 그룹: 사용자 및 서비스 주체의 컬렉션입니다. 권한 관리를 간소화하는 데 사용할 수 있는 여러 가지 그룹 유형이 있습니다. 자세한 내용은 그룹 사용 전략을 참조하세요.

참고 항목

이 문서에서 사용자 및 그룹을 언급할 때 이 용어에는 서비스 주체도 포함됩니다. 이 짧은 용어는 간결함을 위해 사용됩니다.

검색하는 사용자 및 그룹 데이터는 특정 시점의 현재 상태를 설명하는 스냅샷입니다.

팁

사용자, 서비스 주체, 그룹에 대한 자세한 내용은 Microsoft Entra ID와의 통합을 참조하세요.

분석 특성

Power BI 테넌트 수준 감사의 경우 Microsoft Graph에서 다음 특성을 추출하고 저장할 수 있습니다.

  • 사용자 전체 이름: 많은 데이터 원본에는 활동을 수행한 사용자 또는 역할에 할당된 사용자의 메일 주소만 포함됩니다. 분석 보고서에 전체 이름(표시 이름)을 표시하려면 이 특성을 사용합니다. 전체 이름을 사용하면 보고서가 더 사용자 친화적으로 작성됩니다.
  • 기타 사용자 속성: 사용자에 대한 기타 설명 속성을 Microsoft Entra ID에서 사용할 수도 있습니다. 분석 값이 있는 기본 제공 사용자 프로필 속성의 예로는 직위, 부서, 관리자, 지역, 사무실 위치 등이 있습니다.
  • 보안 그룹 멤버: 대부분의 데이터 원본은 그룹 이름을 제공합니다. 예를 들어 Power BI 활동 로그에는 보안 그룹이 작업 영역 역할에 할당되었음을 기록합니다. 그룹 멤버 자격을 검색하면 개별 사용자가 수행하거나 액세스할 수 있는 작업을 완전히 분석하는 능력이 향상됩니다.
  • 사용자 라이선스: 사용자에게 할당된 사용자 라이선스(무료, Power BI Pro 또는 PPU(Power BI Premium Per User))를 분석하는 것이 유용합니다. 이 데이터는 라이선스를 사용하지 않는 사람을 식별하는 데 도움이 될 수 있습니다. 또한 모든 사용자(라이선스가 있는 개별 사용자)와 활성 사용자(최근 활동 포함)를 분석하는 데 도움이 됩니다. Power BI Premium 라이선스를 추가하거나 확장하려는 경우 사용자 활동 데이터와 함께 사용자 라이선스 데이터를 분석하여 비용 분석을 수행하는 것이 좋습니다.
  • 관리자 역할의 멤버: Power BI 관리자 목록을 컴파일할 수 있습니다(Power Platform 관리자 포함).

Microsoft Graph의 감사 데이터에서 찾을 수 있는 Power BI 라이선스 정보에 대한 신뢰할 수 있는 참조를 보려면 라이선스에 대한 제품 이름 및 서비스 계획 식별자를 참조하세요.

팁

그룹에서 멤버를 검색하는 것은 감사 데이터를 얻는 데 있어 가장 어려운 측면 중 하나 일 수 있습니다. 모든 중첩된 멤버와 중첩된 그룹을 평면화하려면 전이적 검색을 수행해야 합니다. 그룹 멤버에 대해 전이적 검색을 수행할 수 있습니다. 이러한 유형의 검색은 조직에 수천 개의 그룹이 있는 경우 특히 어렵습니다. 이 경우 데이터를 검색하기 위한 더 나은 대안을 고려할 수 있습니다. 한 가지 옵션은 Microsoft Graph에서 모든 그룹과 그룹 멤버를 추출하는 것입니다. 하지만 Power BI 보안에 소수의 그룹만 사용되는 경우에는 실용적이지 않을 수 있습니다. 또 다른 옵션은 모든 유형의 Power BI 보안(작업 영역 역할, 앱 권한, 항목별 공유, 행 수준 보안 등)에서 사용되는 그룹의 참조 목록을 미리 작성하는 것입니다. 그런 다음 참조 목록을 반복하여 Microsoft Graph에서 그룹 멤버를 검색할 수 있습니다.

추출하고 저장할 수 있는 몇 가지 다른 특성은 다음과 같습니다.

  • 사용자 유형: 사용자는 멤버 또는 게스트입니다. 가장 일반적으로 멤버는 내부 사용자이고 게스트는 외부(B2B) 사용자입니다. 사용자 유형을 저장하면 외부 사용자의 활동을 분석해야 할 때 유용합니다.
  • 역할 변경: 보안 감사를 수행할 때 사용자가 조직에서 역할을 변경한 시기(예: 다른 부서로 이동한 시기)를 파악하는 것이 유용합니다. 이렇게 하면 Power BI 보안 설정이 업데이트되었는지 또는 업데이트되어야 하는지를 확인할 수 있습니다.
  • 사용하지 않도록 설정된 사용자: 사용자가 조직을 떠나면 일반적으로 관리자가 해당 사용자의 계정을 사용하지 않도록 설정합니다. 사용하지 않도록 설정된 사용자가 작업 영역 관리자인지 또는 의미 체계 모델 소유자인지를 확인하는 프로세스를 만들 수 있습니다.

팁

Power BI 활동 로그에는 사용자가 평가판 라이선스에 가입할 때 기록되는 이벤트가 포함되어 있습니다. 해당 이벤트를 사용자 라이선스 데이터(Microsoft Entra ID에서 제공)와 결합하여 완전한 그림을 생성할 수 있습니다.

사용자 및 그룹 데이터 검색

다양한 방법으로 사용자 및 그룹에 대한 데이터를 검색할 수 있습니다.

기법 설명 수동 감사 프로세스에 적합한 선택 자동화된 감사 프로세스에 적합한 선택
수동 그래프 탐색기 Graph 탐색기는 수동 감사 프로세스에 적합한 선택입니다.
프로그래밍 방식 Microsoft Graph API 및 SDK Microsoft Graph API 및 SDK는 자동화된 감사 프로세스에 적합한 선택입니다.
프로그래밍 방식 Az PowerShell 모듈 Az PowerShell 모듈은 자동화된 감사 프로세스에 적합한 선택입니다.

이 섹션의 나머지 부분에서는 테이블에 제시된 각 기법을 소개합니다. 더 이상 사용되지 않으며 새로운 솔루션에 사용해서는 안 되는 다른 기법은 이 섹션 마지막에 설명되어 있습니다.

참고 항목

많은 도구 이름이 유사하므로 온라인에서 정보를 읽을 때는 주의해야 합니다. Microsoft 에코시스템의 일부 도구에는 Azure Resource Graph, GraphQL, Microsoft Security Graph API와 같이 이름에 Graph라는 용어가 포함되어 있습니다. 이러한 도구는 Microsoft Graph와 관련이 없으며 이 문서의 범위를 벗어납니다.

Microsoft Graph 탐색기

Microsoft Graph Explorer는 Microsoft Graph API에 대해 알아볼 수 있는 개발자 도구입니다. 컴퓨터에 다른 도구나 설정이 필요하지 않으므로 시작하는 간단한 방법입니다. 로그인하여 테넌트에서 데이터를 검색하거나 기본 테넌트에서 샘플 데이터를 검색할 수 있습니다.

Graph Explorer를 사용하여 다음을 수행할 수 있습니다.

  • Microsoft Graph API에 수동으로 요청을 보내 원하는 정보를 반환하는지 확인합니다.
  • 스크립트를 작성하기 전에 URL, 헤더, 본문을 구성하는 방법을 알아봅니다.
  • 비공식적인 방식으로 데이터를 확인합니다.
  • 각 API에 필요한 권한을 결정합니다. 새로운 권한에 대해 동의를 제공할 수도 있습니다.
  • 스크립트를 만들 때 사용할 코드 조각을 가져옵니다.

Graph Explorer를 열려면 이 링크를 사용하세요.

Microsoft Graph API 및 SDK

사용자 및 그룹 데이터를 검색하려면 Microsoft Graph API를 사용합니다. 또한 이를 사용하여 Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook 등과 같은 서비스에서 데이터를 검색할 수도 있습니다.

Microsoft Graph SDK는 기본 Microsoft Graph API 위에서 API 래퍼 역할을 합니다. SDK는 도구와 기능을 번들로 묶은 소프트웨어 개발 키트입니다. Microsoft Graph SDK는 전체 Microsoft Graph API 집합을 노출합니다.

API에 직접 요청을 보내도록 선택할 수 있습니다. 또는 원하는 언어와 SDK 중 하나를 사용하여 간소화 계층을 추가할 수 있습니다. 자세한 내용은 이 문서의 앞부분에 있는 API 또는 PowerShell cmdlet 선택을 참조하세요.

Microsoft Graph SDK는 여러 언어를 지원하며 Microsoft Graph PowerShell 모듈도 있습니다. Python, C#, 기타 언어에 대한 다른 SDK를 사용할 수 있습니다.

Important

Microsoft Graph PowerShell 모듈은 더 이상 사용되지 않는 Azure AD PowerShell 모듈과 MSOL(MSOnline) 모듈을 대체합니다. 더 이상 사용되지 않는 모듈을 사용하여 새 솔루션을 만들어서는 안 됩니다. Microsoft Graph PowerShell 모듈에는 많은 기능과 이점이 있습니다. 자세한 내용은 Azure AD PowerShell에서 Microsoft Graph PowerShell로 업그레이드를 참조하세요.

PowerShell 갤러리에서 Microsoft Graph PowerShell 모듈을 설치할 수 있습니다. Microsoft Graph는 다양한 Microsoft 365 서비스와 함께 작동하므로 설치해야 하는 PowerShell 모듈이 많이 있습니다.

Power BI 테넌트 수준 감사의 경우 설치해야 하는 가장 일반적인 PowerShell 모듈은 다음과 같습니다.

팁

Microsoft는 Microsoft Graph PowerShell 모듈을 정기적으로 업데이트합니다. 때로는 미리 보기 모듈이 시험판 기준으로 또는 베타 엔드포인트로 제공됩니다. 모듈을 설치하고 업데이트할 때 관심 있는 버전을 지정할 수 있습니다. 또한 온라인 문서를 검토하는 경우 현재 버전 번호가 URL 끝에 자동으로 추가되므로 URL을 저장하거나 공유할 때 주의하세요.

Az PowerShell 모듈

Az PowerShell 모듈을 사용하여 사용자 및 그룹 데이터를 검색할 수도 있습니다. Azure 리소스에 중점을 둡니다.

Important

Az PowerShell 모듈은 더 이상 사용되지 않는 AzureRM PowerShell 모듈을 대체합니다. 더 이상 사용되지 않는 모듈을 사용하여 새 솔루션을 만들어서는 안 됩니다.

API에 해당하는 cmdlet이 없는 경우 Invoke-AzRestMethod cmdlet을 사용할 수 있습니다. Az PowerShell 모듈을 사용하여 Microsoft Graph API에 요청을 보낼 수 있는 유연한 방법입니다.

Az 버전 7부터 Az cmdlet은 이제 Microsoft Graph API를 참조합니다. 따라서 Az 모듈은 Microsoft Graph 위에서 API 래퍼 역할을 합니다. Az 모듈에는 Microsoft Graph API 및 PowerShell 모듈에 포함된 기능의 하위 집합이 있습니다. 새로운 솔루션의 경우 Microsoft Graph PowerShell SDK를 사용하는 것이 좋습니다.

사용되지 않는 API 및 모듈

이 섹션에 제시되지 않은 대안 옵션을 제안하는 문서와 블로그 게시물을 온라인에서 찾을 수 있습니다. 다음 API 또는 모듈을 사용하여 새 솔루션을 생성하거나 기존 솔루션을 마이그레이션하지 않는 것이 좋습니다.

  • AzureRM PowerShell 모듈: 더 이상 사용되지 않으며 사용 중지될 예정입니다. Az PowerShell 모듈로 대체되었습니다.
  • Azure AD Graph API 및 Azure AD PowerShell 모듈: 더 이상 사용되지 않으며 사용 중지될 예정입니다. 이 변경 내용은 Azure AD Graph에서 Microsoft Graph로 마이그레이션한 결과입니다(Graph는 두 이름 모두에 표시되지만 앞으로는 Microsoft Graph가 사용될 것임). 향후 모든 PowerShell 투자는 Microsoft Graph PowerShell SDK에 이루어질 예정입니다.
  • MSOL(MS Online) PowerShell 모듈: 더 이상 사용되지 않으며 사용 중지될 예정입니다. 향후 모든 PowerShell 투자는 Microsoft Graph PowerShell SDK에 이루어질 예정입니다.

주의

현재 사용 중인 더 이상 사용되지 않는 API 또는 모듈의 상태를 확인하세요. AzureRM 지원 중단에 대한 자세한 내용은 이 공지를 참조하세요.

Microsoft Entra ID 및 MSOL에 대한 자세한 내용은 이 사용 중지 공지 게시물을 참조하세요.

프로그래밍 방식 데이터 액세스의 향후 방향에 대해 질문이 있거나 설명이 필요한 경우 Microsoft 계정 팀에 문의하세요.

검사 목록 - 사용자 및 그룹 데이터에 액세스하려는 경우 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 요구 사항 확인: 사용자, 그룹, 라이선스와 관련된 데이터 수집에 대한 요구 사항을 명확하게 합니다.
  • 요구 사항 우선 순위 지정: 무엇에 가장 먼저 시간을 투자해야 할지 알 수 있도록 최우선 순위가 무엇인지 확인합니다.
  • 데이터 추출 빈도 결정: 사용자 및 그룹 데이터의 새로운 스냅샷이 필요한 빈도(예: 매주 또는 매달)를 결정합니다.
  • Microsoft Graph로 데이터를 추출하는 방법 결정: 데이터를 검색하는 데 사용할 방법을 결정합니다.
  • 개념 증명 완료: 사용자 및 그룹 데이터를 추출하기 위한 간단한 기술 POC(개념 증명)를 완료할 계획입니다. 이를 사용하여 최종 솔루션 구축 방법에 대한 결정을 검증합니다.

Power BI REST API에서 데이터에 액세스

우선 순위가 낮을 수도 있지만 Power BI REST API를 사용하여 다른 데이터를 검색할 수도 있습니다.

예를 들어 다음에 대한 데이터를 검색할 수 있습니다.

보안 감사 중에 다음을 식별할 수 있습니다.

다른 유형의 API에 대한 자세한 내용은 이 문서의 앞부분에 있는 사용자 API 또는 관리자 API 선택을 참조하세요.

검사 목록 - Power BI API에서 데이터에 액세스하려는 경우 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 요구 사항 가져오기: 분석 요구 사항이 발생하면 이를 컴파일합니다. 백로그에서 이를 추적합니다.
  • 요구 사항 우선 순위 지정: 새로 발생하는 요구 사항에 대한 우선 순위를 설정합니다.

2단계: 필수 조건 및 설정

테넌트 수준 감사 솔루션을 계획하고 구현하는 두 번째 단계에서는 솔루션 개발을 시작하기 전에 수행해야 하는 필수 조건 및 설정에 중점을 둡니다.

테넌트 수준 감사 솔루션을 빌드하기 위한 필수 조건 및 설정에 중점을 둔 2단계를 설명하는 흐름 다이어그램.

스토리지 계정 만들기

이제 원시 데이터를 저장할 위치와 큐레이팅된 데이터를 만드는 방법을 결정했습니다. 이러한 결정 사항에 따라 이제 스토리지 계정을 만들 준비가 되었습니다. 조직의 프로세스에 따라 IT에 요청을 제출해야 할 수도 있습니다.

앞서 설명한 것처럼 원시 데이터를 변경이 불가능한 스토리지에 쓸 수 있는 기술을 사용하는 것이 좋습니다. 데이터가 기록되면 변경하거나 삭제할 수 없습니다. 그러면 액세스 권한이 있는 관리자가 어떤 방식으로든 원시 데이터를 변경할 수 없다는 사실을 알기 때문에 원시 데이터에 대해 확신할 수 있습니다. 그러나 큐레이팅된 데이터는 일반적으로 변경이 불가능한 스토리지에 저장할 필요가 없습니다. 큐레이팅된 데이터는 변경되거나 다시 생성될 수 있습니다.

검사 목록 – 스토리지 계정을 만들 때 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 스토리지 계정 만들기: 스토리지 계정 만들기를 위한 요청을 만들거나 제출합니다. 가능하면 원시 데이터에 변경이 불가능한 스토리지 설정을 사용합니다.
  • 권한 설정: 스토리지 계정에 대해 어떤 권한을 설정해야 하는지 결정합니다.
  • 액세스 테스트: 스토리지 계정을 읽고 쓸 수 있는지 확인하기 위해 간단한 테스트를 수행합니다.
  • 책임 확인: 지속적으로 스토리지 계정을 관리할 사람이 누구인지 명확히 해야 합니다.

소프트웨어 설치 및 서비스 설정

이제 감사 데이터 액세스에 사용할 기술에 대한 결정을 내렸습니다. 이러한 결정에 따라 이제 소프트웨어를 설치하고 서비스를 설정할 준비가 되었습니다.

각 관리자에 대한 기본 설정 개발 환경을 설정합니다. 개발 환경에서는 스크립트를 작성하고 테스트할 수 있습니다. Visual Studio Code는 스크립트 개발을 위한 최신 도구이므로 좋은 선택입니다. 또한 Visual Studio Code에서 작동하는 데 사용할 수 있는 다양한 확장이 있습니다.

PowerShell을 사용하기로 결정한 경우(이전에 설명함) PowerShell Core 및 필요한 PowerShell 모듈을 다음에 설치해야 합니다.

  • 감사 스크립트를 작성하거나 테스트할 각 관리자/개발자의 컴퓨터입니다.
  • 예약된 스크립트를 실행할 각 가상 머신 또는 서버.
  • 각 온라인 서비스(예: Azure Functions 또는 Azure Automation).

Azure 서비스(예: Azure Functions, Azure Automation, Azure Data Factory 또는 Azure Synapse Analytics)를 사용하기로 선택한 경우 해당 서비스도 프로비전하고 설정해야 합니다.

검사 목록 – 소프트웨어 설치 및 서비스 설정 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 관리자/개발자 컴퓨터 설정: 해당하는 경우 개발에 사용할 필수 도구를 설치합니다.
  • 서버 설정: 해당하는 경우 아키텍처에 있는 모든 서버 또는 가상 머신에 필요한 도구를 설치합니다.
  • Azure 서비스 설정: 해당하는 경우 각 Azure 서비스를 프로비전하고 설정합니다. 개발 작업을 수행할 각 관리자/개발자에게 권한을 할당합니다.

Microsoft Entra 애플리케이션 등록

이제 인증 방법을 결정했습니다. Microsoft Entra 애플리케이션(서비스 주체)을 등록하는 것이 좋습니다. 일반적으로 앱 등록이라고 하며 자동화할 무인 작업에 사용해야 합니다.

테넌트 수준 감사 데이터를 검색하기 위해 앱 등록을 만드는 방법에 대한 자세한 내용은 읽기 전용 관리자 API에 대한 서비스 주체 인증 사용을 참조하세요.

검사 목록 - Microsoft Entra 애플리케이션 등록 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 기존 앱 등록이 있는지 확인: 관리자 API 실행을 위해 기존 앱 등록이 가능한지 IT 팀에 확인합니다. 이 경우 기존 항목을 사용해야 하는지 또는 새 항목을 만들어야 하는지 여부를 결정합니다.
  • 새 앱 등록 만들기: 적절한 경우 앱 등록을 만듭니다. 목적을 명확하게 설명하는 PowerBI-AdminAPIs-EntraApp과 같은 앱 이름을 사용하는 것이 좋습니다.
  • 앱 등록을 위한 비밀 만들기: 앱 등록이 존재하면 이에 대한 비밀을 만듭니다. 비밀을 교체하려는 빈도에 따라 만료 날짜를 설정하세요.
  • 값을 안전하게 저장: 서비스 주체를 인증하는 데 필요하므로 암호, 앱 ID(클라이언트 ID), 테넌트 ID를 저장합니다. 조직 암호 자격 증명 모음과 같이 안전한 위치를 사용합니다. (IT에 앱 등록 만들기를 요청해야 하는 경우 해당 값을 반환해야 한다고 지정하세요.)
  • 보안 그룹 만들기: Power BI에 사용할 보안 그룹을 만들거나 요청합니다. 그룹이 테넌트 전체 메타데이터에 액세스하는 데 사용됨을 나타내는 Power BI 관리 서비스 주체와 같은 그룹 이름을 사용하는 것이 좋습니다.
  • 서비스 주체를 보안 그룹의 구성원으로 추가: 앱 ID(클라이언트 ID)를 사용하여 새(또는 기존) 서비스 주체를 새 보안 그룹의 멤버로 추가합니다.
  • Power BI에서 관리자 API 테넌트 설정 업데이트: Power BI 관리자 포털에서 서비스 주체가 읽기 전용 Power BI 관리자 API를 사용하도록 허용 테넌트 설정에 보안 그룹을 추가합니다.
  • Azure에서 권한 할당 건너뛰기: 앱 등록에 대한 권한을 위임하지 마세요(Power BI 서비스 주체가 읽기 전용 Power BI 관리자 API를 사용하도록 허용 테넌트 설정을 통해 Power BI 테넌트 수준 감사 데이터에 대한 액세스 권한을 얻음)
  • 앱 등록에서 자세한 메타데이터에 액세스해야 하는지 결정: 테넌트 인벤토리를 구축할 때 의미 체계 모델 테이블, 열, 측정값 식에 대한 세부 정보를 추출할지 여부를 결정합니다.
  • Power BI에서 세부 메타데이터 테넌트 설정 업데이트: Power BI 관리 포털에서 세부 메타데이터로 관리자 API 응답 향상 테넌트 설정과 DAX 및 매시업 식으로 관리자 API 응답 향상 테넌트 설정에 보안 그룹을 추가합니다.
  • 서비스 주체 테스트: 서비스 주체를 사용하여 로그인하는 간단한 스크립트를 만들고 관리자 API에서 데이터를 검색할 수 있는지 테스트합니다.
  • 앱 등록 비밀을 관리하는 프로세스 만들기: 비밀을 정기적으로 순환하는 문서와 프로세스를 만듭니다. 필요한 관리자와 개발자에게 새로운 비밀을 안전하게 전달할 방법을 결정하세요.

Power BI 테넌트 설정 준비

Power BI 관리 포털에는 테넌트 수준 감사 데이터 추출과 관련된 여러 테넌트 설정이 있습니다.

관리 API

관리자 API 실행과 관련된 세 가지 테넌트 설정이 있습니다.

Important

이러한 설정은 직접 Power BI 권한을 할당하지 않고 전체 테넌트에 대한 메타데이터 액세스 권한을 부여하므로 엄격하게 제어해야 합니다.

서비스 주체가 읽기 전용 Power BI 관리자 API를 사용하도록 허용 테넌트 설정을 사용하면 관리자 API를 호출할 수 있는 서비스 주체를 설정할 수 있습니다. 또한 이 설정을 사용하면 Microsoft Purview가 전체 Power BI 테넌트를 검사하여 데이터 카탈로그를 채울 수 있습니다.

참고 항목

다른 Power BI 관리자에게 이미 테넌트 전체 메타데이터에 대한 액세스 권한이 있으므로 서비스 주체가 읽기 전용 Power BI 관리자 API를 사용하도록 허용 테넌트 설정에 명시적으로 할당할 필요가 없습니다.

자세한 메타데이터로 관리자 API 응답 향상 테넌트 설정을 사용하면 세부 메타데이터를 검색할 수 있는 사용자와 서비스 주체를 설정할 수 있습니다. 메타데이터는 메타데이터 검색 API를 사용하여 검색되며 여기에는 테이블, 열 등이 포함됩니다. 또한 이 설정을 사용하면 Microsoft Purview가 Power BI 의미 체계 모델에 대한 스키마 수준 정보에 액세스하여 데이터 카탈로그에 저장할 수 있습니다.

DAX 및 매시업 식으로 관리자 API 응답 향상 테넌트 설정을 사용하면 세부 메타데이터를 검색할 수 있는 사용자 및 서비스 주체를 설정할 수 있습니다. 메타데이터는 메타데이터 검색 API에서 검색되며 여기에는 쿼리 및 의미 체계 모델 측정값 식이 포함될 수 있습니다.

참고 항목

서비스 주체가 읽기 전용 Power BI 관리자 API를 사용하도록 허용 테넌트 설정은 특히 관리자 API 액세스에 관한 것입니다. 해당 이름은 사용자 API(다음에 설명함)에 액세스하기 위한 테넌트 설정과 매우 유사합니다. 관리자 API와 사용자 API의 차이점에 대한 자세한 내용은 이 문서의 앞부분에 있는 사용자 API 또는 관리자 API 선택을 참조하세요.

사용자 API

사용자 API 호출에 적용되는 테넌트 설정이 하나 있습니다. 이 상황에서는 서비스 주체(예: 작업 영역 역할)에도 Power BI 권한이 필요합니다.

서비스 주체가 Power BI API를 사용하도록 허용 테넌트 설정을 사용하면 REST API를 실행하기 위해 액세스할 수 있는 서비스 주체를 설정할 수 있습니다(위에 설명된 다른 테넌트 설정에 의해 부여되는 관리자 API는 제외).

포함 API, 스트리밍 API, 내보내기 API, 쿼리 실행 API에 대한 액세스를 허용하는 API와 관련된 다른 테넌트 설정이 있습니다. 그러나 이러한 API는 이 문서의 범위를 벗어납니다.

사용 현황 메트릭의 테넌트 설정에 대한 자세한 내용은 보고서 수준 감사를 참조하세요.

검사 목록 - Power BI 테넌트 설정의 설정 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 각 서비스 주체가 올바른 그룹에 있는지 확인: Power BI 관리자 서비스 주체 그룹에 올바른 서비스 주체가 포함되어 있는지 확인합니다.
  • Power BI에서 관리자 API 테넌트 설정 업데이트: 보안 그룹을 서비스 주체가 읽기 전용 Power BI 관리자 API를 사용하도록 허용 테넌트 설정에 추가하여 관리자 API를 사용하여 테넌트 전체 메타데이터를 검색할 수 있도록 허용합니다.
  • Power BI에서 세부 메타데이터 테넌트 설정 업데이트: 필요한 경우 세부 메타데이터로 관리자 API 응답 향상 테넌트 설정 및 DAX 및 매시업 식으로 관리자 API 응답 향상 테넌트 설정에 보안 그룹을 추가합니다.
  • 액세스할 사용자 API 확인: 하나 이상의 사용자 API가 필요한지 확인합니다(관리자 API를 추가로 사용).
  • Power BI에서 사용자 API 테넌트 설정 업데이트: 사용자 API를 위한 서비스 주체가 Power BI API를 사용하도록 허용 테넌트 설정에 보안 그룹을 추가합니다.

3단계: 솔루션 개발 및 분석

테넌트 수준 감사 솔루션을 계획하고 구현하는 세 번째 단계는 솔루션 개발 및 분석에 중점을 둡니다. 이 시점에서 모든 계획과 의사 결정이 이루어졌으며 전제 조건을 충족하고 설정을 완료했습니다. 이제 분석을 수행하고 감사 데이터에서 인사이트를 얻을 수 있도록 솔루션 개발을 시작할 준비가 되었습니다.

테넌트 수준 감사 솔루션의 솔루션 개발 및 분석에 중점을 둔 3단계를 설명하는 흐름 다이어그램.

원시 데이터 추출 및 저장

이 시점에서 요구 사항과 우선 순위가 명확해야 합니다. 감사 데이터에 액세스하는 방법 및 감사 데이터 저장 위치에 대한 주요 기술 결정이 내려졌습니다. 기본 설정 도구가 선택되었으며 필수 조건과 설정이 구성되었습니다. 이전 두 단계에서 타당성을 입증하기 위해 하나 이상의 소규모 프로젝트(개념 증명)를 완료했을 수 있습니다. 다음 단계는 원시 감사 데이터를 추출하고 저장하는 프로세스를 설정하는 것입니다.

대부분의 Microsoft API에서 반환된 데이터와 마찬가지로 감사 데이터는 JSON 형식으로 지정됩니다. JSON 형식 데이터는 구조와 데이터를 포함하고 사람이 읽을 수 있는 텍스트이기 때문에 자체적으로 설명합니다.

JSON은 속성-값 쌍과 배열로 구성된 데이터 개체를 나타냅니다. 예를 들어 "state": "Active"은 상태 특성 값이 활성인 예제입니다. JSON 배열에는 쉼표로 구분되고 대괄호([ ]) 안에 묶인 요소의 정렬된 목록이 포함됩니다. JSON 결과에서 중첩 배열을 찾는 것이 일반적입니다. JSON 결과의 계층 구조에 익숙해지면 작업 영역의 의미 체계 모델 목록(배열)과 같은 데이터 구조를 이해하는 것이 더 쉬워집니다.

API에서 검색된 원시 데이터를 추출하고 저장할 때 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 어떤 명명 규칙이 사용되나요? 파일 기반 시스템의 경우 파일, 폴더, 데이터 레이크 영역에 대한 명명 규칙이 필요합니다. 데이터베이스의 경우 테이블 및 열에 대한 명명 규칙이 필요합니다.
  • 원시 데이터를 저장하는 데 사용되는 형식은 무엇인가요? Power BI가 계속해서 새로운 기능을 도입함에 따라 현재 존재하지 않는 새로운 작업이 나타날 것입니다. 이러한 이유로 원본 JSON 결과를 추출하고 유지하는 것이 좋습니다. 데이터를 추출하는 동안 데이터를 구문 분석하거나 필터링하거나 형식을 지정하지 마세요. 이렇게 하면 원본 원시 데이터를 사용하여 큐레이팅된 감사 데이터를 다시 생성할 수 있습니다.
  • 어떤 스토리지 위치가 사용되나요? 데이터 레이크 또는 BLOB 스토리지는 일반적으로 원시 데이터를 저장하는 데 사용됩니다. 자세한 내용은 이 문서의 앞부분에 있는 감사 데이터 저장 위치 결정을 참조하세요.
  • 얼마나 많은 기록을 저장하나요? 기록을 저장할 수 있는 위치로 감사 데이터를 내보냅니다. 2년 이상의 기록을 누적할 계획입니다. 이렇게 하면 기본 보존 기간인 30일 이후의 추세와 변경 내용을 분석할 수 있습니다. 조직의 데이터 보존 정책에 따라 데이터를 무기한 저장하도록 선택할 수도 있고 더 짧은 기간을 선택할 수도 있습니다.
  • 프로세스가 마지막으로 실행된 시기를 어떻게 추적하나요? 프로세스가 시작되고 완료되면 타임스탬프를 기록하도록 구성 파일 또는 이에 해당하는 파일을 설정합니다. 다음에 프로세스가 실행될 때 이러한 타임스탬프를 검색할 수 있습니다. 메타데이터 검색 API를 사용하여 데이터를 추출할 때 타임스탬프를 저장하는 것이 특히 중요합니다.
  • 제한을 어떻게 처리하나요? 일부 Power BI REST API 및 Microsoft Graph API는 제한을 구현합니다. API 요청이 제한되면 429 오류(요청이 너무 많음)가 표시됩니다. 제한은 대량의 데이터를 검색해야 하는 대규모 조직에서 흔히 발생하는 문제일 수 있습니다. 제한으로 인해 실패한 시도를 방지하는 방법은 데이터에 액세스하고 추출하는 데 사용하는 기술에 따라 달라집니다. 한 가지 옵션은 대기 시간 후 재시도하여 429 “너무 많은 요청” 오류에 응답하는 논리를 스크립트에서 개발하는 것입니다.
  • 규정 준수에 감사 데이터가 필요한가요? 많은 조직에서는 원시 감사 로그 레코드를 사용하여 규정 준수 감사를 수행하거나 보안 조사에 대응합니다. 이러한 경우에는 원시 데이터를 변경이 불가능한 스토리지에 저장하는 것이 좋습니다. 이렇게 하면 데이터가 일단 작성되면 관리자나 다른 사용자가 이를 변경하거나 삭제할 수 없습니다.
  • 요구 사항을 지원하는 데 필요한 스토리지 계층은 무엇인가요? 원시 데이터를 저장하는 가장 좋은 위치는 데이터 레이크(예: Azure Data Lake Storage Gen2) 또는 개체 스토리지(예: Azure Blob Storage)입니다. 클라우드 서비스가 옵션이 아닌 경우 파일 시스템을 사용할 수도 있습니다.

검사 목록 - 원시 데이터 추출 및 저장 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 요구 사항 및 우선 순위 확인: 먼저 추출할 데이터의 요구 사항 및 우선 순위를 명확히 합니다.
  • 추출할 데이터의 원본 확인: 필요한 각 데이터 형식의 원본을 확인합니다.
  • 데이터를 추출하고 원시 데이터 영역에 로드하는 프로세스 설정: 변환 없이 원래 상태로 원시 데이터를 추출하고 로드하는 초기 프로세스를 만듭니다. 프로세스가 의도한 대로 작동하는지 테스트합니다.
  • 프로세스 실행 일정 만들기: 추출, 로드, 변환 프로세스를 실행하기 위한 반복 일정을 설정합니다.
  • 자격 증명이 안전하게 관리되는지 확인: 암호, 비밀, 키가 안전한 방식으로 저장되고 전달되는지 확인합니다.
  • 보안이 올바르게 설정되었는지 확인: 원시 데이터에 대한 액세스 권한이 올바르게 설정되었는지 확인합니다. 관리자와 감사자가 원시 데이터에 액세스할 수 있는지 확인합니다.

시간이 지남에 따라 감사 및 모니터링 솔루션이 어떻게 성장하는지에 대한 자세한 내용은 이 문서의 뒷부분에 있는 운영 및 개선을 참조하세요.

큐레이팅된 데이터 만들기

이 시점에서 원시 데이터가 추출되고 저장됩니다. 다음 단계는 큐레이팅된 데이터에 대한 별도의 골드 데이터 계층을 만드는 것입니다. 목표는 데이터 파일을 별모양 스키마로 변환하고 저장하는 것입니다. 별모양 스키마는 차원 테이블과 팩트 테이블로 구성되며 분석 및 보고를 위해 의도적으로 최적화되었습니다. 큐레이팅된 데이터 계층의 파일은 Power BI 데이터 모델의 원본이 됩니다(다음 항목에서 설명함).

팁

둘 이상의 데이터 모델이 있을 것으로 예상되는 경우 중앙 집중식으로 큐레이팅된 데이터 계층에 투자하는 것이 특히 유용합니다.

검사 목록 - 큐레이팅된 데이터 계층을 만들 때 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 요구 사항 및 우선 순위 확인: 변환된 데이터에 중간 실버 계층을 사용하려는 경우 달성해야 하는 요구 사항과 목표를 명확히 합니다.
  • 원시 데이터를 변환하고 큐레이팅된 데이터 영역에 로드하는 프로세스 설정: 데이터를 변환하고 별모양 스키마로 로드하는 프로세스를 만듭니다. 프로세스가 의도한 대로 작동하는지 테스트합니다.
  • 프로세스 실행 일정 만들기: 큐레이팅된 데이터 영역을 채우는 반복 일정을 설정합니다.
  • 보안이 올바르게 설정되었는지 확인: 큐레이팅된 데이터에 대한 액세스 권한이 올바르게 설정되었는지 확인합니다. 데이터 모델의 개발자가 큐레이팅된 데이터에 액세스할 수 있는지 확인합니다.

데이터 모델 만들기

주제는 분석 데이터 모델 설정에 관한 것입니다. 데이터 모델은 분석에 최적화된 쿼리 가능한 데이터 리소스입니다. 때로는 의미 체계 모델 또는 간단히 모델이라고도 합니다. 감사 및 모니터링 솔루션의 경우 데이터 모델은 Power BI 의미 체계 모델로 구현될 가능성이 큽니다.

감사 및 모니터링의 컨텍스트에서 데이터 모델은 큐레이팅된(골드) 데이터 계층에서 데이터를 가져옵니다. 큐레이팅된 데이터 계층을 만들지 않도록 선택하는 경우 데이터 모델은 원시 데이터에서 직접 데이터를 가져옵니다.

Power BI 데이터 모델은 별모양 스키마 디자인을 구현하는 것이 좋습니다. 원본 데이터가 큐레이팅된 데이터 계층인 경우 Power BI 데이터 모델 별모양 스키마는 큐레이팅된 데이터 계층 별모양 스키마를 미러링해야 합니다.

팁

별모양 스키마 디자인에 대한 개요는 별모양 스키마 및 Power BI의 중요성 이해를 참조하세요.

모든 Power BI 프로젝트와 마찬가지로 데이터 모델을 만드는 것은 반복적인 프로세스입니다. 필요에 따라 새 측정값을 추가할 수 있습니다. 새 감사 이벤트를 사용할 수 있게 되면 새 테이블과 열을 추가할 수도 있습니다. 시간이 지나면 새 데이터 원본을 통합할 수도 있습니다.

다음은 데이터 모델에 포함할 수 있는 몇 가지 유용한 차원 테이블입니다.

  • 날짜: 일, 주, 월, 분기, 연도, 기타 관련 기간별로 데이터를 분석(조각화 및 분할)할 수 있는 날짜 특성 세트입니다.
  • 시간: 시간대별로 분석해야 하고 감사 데이터의 양이 매우 많은 경우 날짜와 별도로 시간 부분을 저장하는 것이 좋습니다. 이 방법은 쿼리 성능을 개선하는 데 도움이 될 수 있습니다.
  • 사용자: 감사 데이터의 여러 주제를 필터링할 수 있는 사용자(예: 부서 및 지리적 지역)를 설명하는 특성입니다. 목표는 팩트 테이블에서 모든 사용자 세부 정보를 제거하고 이를 이 차원 테이블에 저장하여 많은 팩트 테이블을 필터링할 수 있도록 하는 것입니다. 이 테이블에 서비스 주체를 저장할 수도 있습니다.
  • 활동 이벤트: 활동 이벤트(작업)를 그룹화하고 설명하는 특성입니다. 보고 기능을 향상하려면 각 활동 이벤트를 설명하는 데이터 사전을 만들 수 있습니다. 유사한 활동 이벤트를 그룹화하고 분류하는 계층 구조를 만들 수도 있습니다. 예를 들어 모든 항목 만들기 이벤트, 삭제 이벤트 등을 그룹화할 수 있습니다.
  • 작업 영역: 형식(개인 또는 표준) 및 설명과 같은 테넌트 및 작업 영역 속성의 작업 영역 목록입니다. 일부 조직에서는 작업 영역에 대한 자세한 내용을 기록합니다(SharePoint 목록 사용 가능). 이러한 세부 정보를 이 차원 테이블에 통합할 수 있습니다. 이 차원 테이블이 작업 영역의 현재 상태만 저장할지 또는 시간이 지남에 따라 중요한 작업 영역 변경 내용을 반영하는 버전이 지정된 데이터를 저장할지 여부를 결정해야 합니다. 예를 들어 작업 영역 이름이 변경되면 기록 보고에 현재 작업 영역 이름이 표시되나요, 아니면 당시의 최신 작업 영역 이름이 표시되나요? 버전 관리에 대한 자세한 내용은 느린 변경 차원을 참조하세요.
  • 항목 형식: Power BI 항목 형식(의미 체계 모델, 보고서, 기타) 목록입니다.
  • 용량: 테넌트의 프리미엄 용량 목록입니다.
  • 게이트웨이: 테넌트의 데이터 게이트웨이 목록입니다.
  • 데이터 원본: 모든 의미 체계 모델, 데이터 흐름 또는 데이터 마트에서 사용되는 데이터 원본 목록입니다.

다음은 데이터 모델에 포함할 수 있는 몇 가지 유용한 팩트 테이블(주제)입니다.

  • 사용자 활동: 원본 JSON 데이터에서 가져온 팩트 데이터입니다. 분석 값이 없는 특성은 모두 제거됩니다. 위의 차원 테이블에 속하는 모든 특성도 제거됩니다.
  • 테넌트 인벤토리: 테넌트에 게시된 모든 항목의 특정 시점 스냅샷입니다. 자세한 내용은 이 문서의 앞부분에 있는 테넌트 인벤토리를 참조하세요.
  • 의미 체계 모델: 의미 체계 모델(예: 의미 체계 모델 변경) 또는 관련 데이터 원본과 관련된 사용자 작업을 포함합니다.
  • 의미 체계 모델 새로 고침: 형식(예약 또는 주문형), 기간, 상태, 작업을 시작한 사용자에 대한 세부 정보를 포함하여 데이터 새로 고침 작업을 저장합니다.
  • 작업 영역 역할: 작업 영역 역할 할당의 특정 시간 스냅샷입니다.
  • 사용자 라이선스: 사용자 라이선스의 특정 시간 스냅샷입니다. 사용자 차원 테이블에 사용자 라이선스를 저장하고 싶을 수도 있지만, 이 방법은 시간 경과에 따른 라이선스 변경 및 추세 분석을 지원하지 않습니다.
  • 사용자 그룹 멤버 자격: 보안 그룹에 할당된 사용자(및 서비스 주체)의 특정 시점 스냅샷입니다.
  • 커뮤니티 활동: 교육 이벤트 등 커뮤니티 관련 팩트를 포함합니다. 예를 들어 교육 참석과 비교하여 Power BI 사용자 활동을 분석할 수 있습니다. 이 데이터는 우수성 센터가 잠재적인 새로운 챔피언을 식별하는 데 도움이 될 수 있습니다.

팩트 테이블에는 보고서 작성자가 필터링하는 열이 포함되어서는 안 됩니다. 대신 해당 열은 관련 차원 테이블에 속합니다. 이 디자인은 쿼리에 더 효율적일 뿐만 아니라 여러 팩트를 통해 차원 테이블의 재사용을 촉진합니다(드릴 어크로스라고도 함). 새로운 팩트 테이블(주제)을 추가할 때 확장 가능한 유용하고 사용자 친화적인 데이터 모델을 생성하려면 마지막 사항이 중요합니다.

예를 들어 사용자 차원 테이블은 모든 사실 테이블과 관련됩니다. 이는 사용자 활동 팩트 테이블(활동을 수행한 사람), 테넌트 인벤토리 팩트 테이블(게시된 항목을 만든 사람), 기타 모든 팩트 테이블과 관련되어야 합니다. 보고서가 사용자 차원 테이블에서 사용자를 기준으로 필터링하면 해당 보고서의 시각적 개체는 관련 팩트 테이블의 해당 사용자에 대한 사실을 표시할 수 있습니다.

모델을 설계할 때 특성이 모델에서 한 번만 표시되는지 확인합니다. 예를 들어 사용자 메일 주소는 사용자 차원 테이블에만 표시되어야 합니다. 이는 모델 관계를 지원하는 차원 키로 다른 팩트 테이블에도 존재합니다. 그러나 각 팩트 테이블에서는 이를 숨겨야 합니다.

보고서와 별도로 데이터 모델을 만드는 것이 좋습니다. 의미 체계 모델과 해당 보고서를 분리하면 많은 보고서를 제공할 수 있는 중앙 집중식 의미 체계 모델이 생성됩니다. 공유 의미 체계 모델 사용에 대한 자세한 내용은 관리형 셀프 서비스 BI 사용 시나리오를 참조하세요.

우수성 센터, 감사자, 관리자 이외의 다른 사용자가 감사 데이터를 분석하고 보고할 수 있도록 RLS(행 수준 보안)를 설정하는 것이 좋습니다. 예를 들어 RLS 규칙을 사용하여 콘텐츠 제작자와 소비자가 자신의 사용자 활동이나 개발 노력에 대해 보고하도록 허용할 수 있습니다.

검사 목록 - 데이터 모델을 만들 때 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 데이터 모델 계획 및 만들기: 데이터 모델을 별모양 스키마로 설계합니다. 관계가 의도한 대로 작동하는지 확인합니다. 모델을 개발하면서 측정값을 반복적으로 만들고 분석 요구 사항에 따라 데이터를 추가하세요. 필요한 경우 백로그에 향후 개선 사항을 포함합니다.
  • RLS 설정: 다른 일반 사용자가 데이터 모델을 사용할 수 있도록 하려면 행 수준 보안을 설정하여 데이터 액세스를 제한하세요. RLS 역할이 올바른 데이터를 반환하는지 확인합니다.

데이터 모델 개선

콘텐츠 사용 및 사용자 활동을 효과적으로 분석하려면 데이터 모델을 강화하는 것이 좋습니다. 데이터 모델 개선은 기회와 새로운 요구 사항을 발견함에 따라 시간이 지나면서 점진적이고 반복적으로 수행될 수 있습니다.

분류 만들기

모델을 강화하고 데이터의 가치를 높이는 한 가지 방법은 데이터 모델에 분류를 추가하는 것입니다. 이러한 분류가 보고서에서 일관되게 사용되는지 확인합니다.

사용 수준에 따라 사용자를 분류하거나 사용 수준에 따라 콘텐츠를 분류할 수 있습니다.

사용자 사용량 분류

사용자 사용량에 대해 다음 분류를 고려합니다.

  • 자주 사용하는 사용자: 지난 주 및 지난 12개월 중 9개월 동안 활동이 기록되었습니다.
  • 활성 사용자: 지난 달에 활동이 기록되었습니다.
  • 가끔 사용하는 사용자: 지난 9개월 동안 활동이 기록되었지만 지난 1개월 동안 활동이 없습니다.
  • 비활성 사용자: 지난 9개월 동안 활동이 기록되지 않았습니다.

팁

특히 Pro 또는 PPU 라이선스(비용 포함)를 보유한 경우 가끔 사용하는 사용자 또는 비활성 사용자가 누구인지 아는 것은 유용합니다. 자주 사용하는 사용자와 가장 활동적인 사용자가 누구인지 아는 것도 유용합니다. 약식 미팅에 참가하거나 교육에 참석하도록 초대해 보세요. 가장 활동적인 콘텐츠 작성자는 챔피언 네트워크에 참가할 후보자가 될 수 있습니다.

콘텐츠 사용량 분류

콘텐츠 사용량에 대해 다음 분류를 고려합니다.

  • 자주 사용되는 콘텐츠: 지난 주 및 지난 12개월 중 9개월 동안 활동이 기록되었습니다.
  • 활발하게 사용되는 사용자: 지난 달에 활동이 기록되었습니다.
  • 가끔 사용되는 콘텐츠: 지난 9개월 동안 활동이 기록되었지만 지난 1개월 동안 활동이 없습니다.
  • 사용되지 않는 콘텐츠: 지난 9개월 동안 활동이 기록되지 않았습니다.
사용자 유형 분류

사용자 유형에 대해 다음 분류를 고려합니다.

  • 콘텐츠 제작자: 지난 6개월 동안 콘텐츠를 만들고, 게시하거나 편집한 활동이 기록되었습니다.
  • 콘텐츠 뷰어: 지난 6개월 동안 콘텐츠를 보았지만 콘텐츠 제작 활동이 없는 활동이 기록되었습니다.

사용자 또는 콘텐츠의 사용 분류가 활동이 발생한 최근 정도만을 기준으로 해야 하는지 결정해야 합니다. 시간 경과에 따른 평균 또는 추세 사용량을 고려하는 것도 생각해볼 수 있습니다.

단순한 분류 논리가 현실을 얼마나 잘못 나타낼 수 있는지 보여 주는 몇 가지 예제를 생각해 보세요.

  • 관리자가 이번 주에 하나의 보고서를 보았습니다. 그러나 해당 주 이전 6개월 동안 관리자는 어떤 보고서도 보지 않았습니다. 최근 사용량만을 기준으로 해당 관리자를 자주 사용하는 사용자로 간주해서는 안 됩니다.
  • 보고서 작성자는 매주 새 보고서를 게시합니다. 자주 사용하는 사용자별로 사용량을 분석하면 보고서 작성자의 정기적인 활동은 긍정적인 것으로 나타납니다. 그러나 추가 조사를 통해 해당 사용자가 보고서를 편집할 때마다 새 보고서(새 보고서 이름)를 다시 게시했다는 사실을 발견했습니다. 보고서 작성자가 더 많은 교육을 받는 것이 유용할 것입니다.
  • 경영진은 보고서를 간헐적으로 보기 때문에 사용량 분류가 자주 변경됩니다. 경영진과 같은 특정 유형의 사용자를 다르게 분석해야 할 수도 있습니다.
  • 내부 감사자는 1년에 한 번씩 중요한 보고서를 봅니다. 내부 감사자는 자주 사용하지 않으므로 비활성 사용자로 나타날 수도 있습니다. 누군가가 Pro 또는 PPU 라이선스를 제거하기 위해 조치를 취할 수 있습니다. 또는 보고서가 자주 사용되지 않으므로 보고서를 사용 중지해야 한다고 생각할 수도 있습니다.

팁

DAX 시간 인텔리전스 함수를 사용하여 평균과 추세를 계산할 수 있습니다. 이러한 함수를 사용하는 방법을 알아보려면 Power BI Desktop 모델에서 DAX 시간 인텔리전스 함수 사용 학습 모듈을 진행하세요.

검사 목록 – 사용량 현황 데이터 분류를 만들 때 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 분류 정의에 대한 합의 얻기: 관련자와 분류 정의에 대해 논의합니다. 결정을 내릴 때 합의되었는지 확인합니다.
  • 문서 만들기: 콘텐츠 작성자와 소비자를 위한 문서에 분류 정의가 포함되어 있는지 확인하세요.
  • 피드백 반복 만들기: 사용자가 질문을 하거나 분류 정의에 대한 변경을 제안할 수 있는 방법이 있는지 확인하세요.

분석 보고서 만들기

이 시점에서 감사 데이터가 추출되어 저장되었으며 데이터 모델이 게시되었습니다. 다음 단계는 분석 보고서를 작성하는 것입니다.

각 대상 그룹과 가장 관련성이 높은 주요 정보에 집중합니다. 감사 보고서에는 여러 대상 그룹이 있을 수도 있습니다. 각 대상 그룹은 서로 다른 정보와 서로 다른 목적에 관심을 가집니다. 보고서와 함께 사용할 수 있는 대상 그룹은 다음과 같습니다.

  • 임원 스폰서
  • 최고 전문가 조직
  • Power BI 관리자
  • 작업 영역 관리자
  • 프리미엄 용량 관리자
  • 게이트웨이 관리자
  • Power BI 개발자 및 콘텐츠 작성자
  • 감사자

감사 보고서를 작성할 때 시작할 수 있는 가장 일반적인 분석 요구 사항은 다음과 같습니다.

  • 인기 콘텐츠 조회수: 경영진 스폰서 및 리더십 팀은 요약 정보와 시간 경과에 따른 추세에 주로 관심을 가질 수 있습니다. 작업 영역 관리자, 개발자, 콘텐츠 작성자는 세부 정보에 더 관심이 있습니다.
  • 주요 사용자 활동: 우수성 센터는 누가 Power BI를 언제, 어떻게 사용하는지에 관심을 가질 것입니다. 프리미엄 용량 관리자는 상태와 안정성을 보장하기 위해 용량을 사용하는 사람이 누구인지 관심을 가질 것입니다.
  • 테넌트 인벤토리: Power BI 관리자, 작업 영역 관리자, 감사자는 어떤 콘텐츠가 존재하는지, 어디에 있는지, 계보와 해당 보안 설정을 이해하는 데 관심이 있습니다.

이 목록이 모든 것을 포괄하지는 않습니다. 특정 요구 사항을 대상으로 하는 분석 보고서를 만드는 방법에 대한 아이디어를 제공하기 위한 것입니다. 더 많은 고려 사항을 보려면 이 문서의 앞부분에 있는 데이터 요구 사항과 감사 및 모니터링 개요를 참조하세요. 이러한 리소스에는 감사 데이터를 사용하는 방법에 대한 다양한 아이디어와 보고서에 표시하기 위해 선택할 수 있는 정보 유형이 포함되어 있습니다.

팁

많은 양의 데이터를 제시하고 싶지만 작업을 할 준비가 된 정보만 포함하세요. 모든 보고서 페이지에는 목적, 해야 할 작업, 대상이 명확히 명시되어 있는지 확인합니다.

분석 보고서를 만드는 방법을 알아보려면 Power BI에서 효과적인 보고서 설계 학습 경로를 진행하세요.

검사 목록 - 분석 감사 보고서 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 검토 요구 사항: 알려진 요구 사항과 답변해야 하는 구체적인 질문에 따라 보고서 작성의 우선 순위를 정하세요.
  • 대상 그룹 확인: 감사 보고서를 사용할 사람과 그 목적이 무엇인지 명확히 합니다.
  • 보고서 만들기 및 배포: 첫 번째 핵심 보고서 집합을 개발합니다. 시간이 지남에 따라 점차적으로 확장하고 향상합니다.
  • 앱에 보고서 배포: 모든 감사 및 모니터링 보고서가 포함된 앱을 만드는 것을 고려해 보세요.
  • 보고서에 액세스할 수 있는 사람 확인: 보고서(또는 앱)가 올바른 사용자 집합에 제공되는지 확인하세요.
  • 피드백 루프 만들기: 보고서 소비자가 피드백이나 제안을 제공하거나 문제를 보고할 수 있는 방법이 있는지 확인하세요.

데이터에 따라 작업 수행

데이터 감사는 Power BI 테넌트에서 일어나는 일을 이해하는 데 도움이 되므로 중요합니다. 당연해 보이지만 감사 데이터에서 배운 내용의 명시적 실행은 쉽게 간과할 수 있습니다. 따라서 단순히 감사 보고서를 검토하기보다는 측정 가능한 개선 사항을 추적하는 담당자를 지정하는 것이 좋습니다. 이렇게 하면 Power BI 채택 및 완성도 측면에서 점진적이고 측정 가능한 발전을 이룰 수 있습니다.

목표와 감사 데이터에서 배운 내용을 기반으로 다양한 작업을 할 수 있습니다. 이 섹션의 나머지 부분에서는 몇 가지 아이디어를 제공합니다.

콘텐츠 사용량

다음은 콘텐츠 사용 방법에 따라 수행할 수 있는 몇 가지 작업입니다.

  • 콘텐츠가 자주 사용됨(매일 또는 매주): 중요한 콘텐츠가 모두 인증되었는지 확인합니다. 소유권이 명확하고 솔루션이 적절하게 지원되는지 확인합니다.
  • 많은 수의 작업 영역 보기: 많은 수의 작업 영역 보기가 발생하는 경우 Power BI 앱이 사용되지 않는 이유를 조사합니다.
  • 콘텐츠가 거의 사용되지 않음: 대상 사용자에게 연락하여 솔루션이 요구 사항을 충족하는지 또는 요구 사항이 변경되었는지 확인합니다.
  • 새로 고침 작업이 보기보다 더 자주 발생함: 콘텐츠 소유자에게 문의하여 최근에 의미 체계 모델이나 관련 보고서를 사용하지 않고 의미 체계 모델을 정기적으로 새로 고치는 이유를 알아봅니다.

사용자 활동

다음은 사용자 활동에 따라 수행할 수 있는 몇 가지 작업입니다.

  • 신규 사용자의 첫 번째 게시 작업: 사용자 유형이 소비자에서 작성자로 변경되는 시점을 식별하고 처음으로 콘텐츠를 게시할 때 이를 식별할 수 있습니다. 유용한 리소스에 대한 지침과 링크를 제공하는 표준 메일을 보낼 수 있는 좋은 기회입니다.
  • 가장 자주 활동하는 콘텐츠 제작자와의 참여: 가장 활동적인 작성자를 초대하여 챔피언 네트워크에 참여하거나 실천 커뮤니티에 참여하도록 하세요.
  • 라이선스 관리: 비활성 작성자에게 Pro 또는 PPU 라이선스가 여전히 필요한지 확인합니다.
  • 사용자 평가판 활성화: 평가판 라이선스를 활성화하면 평가판이 종료되기 전에 사용자에게 영구 라이선스를 할당하라는 메시지가 표시될 수 있습니다.

사용자 교육 기회

감사 데이터에서 식별할 수 있는 몇 가지 사용자 교육 기회는 다음과 같습니다.

  • 동일한 콘텐츠 제작자가 게시한 다수의 의미 체계 모델: 사용자에게 공유 의미 체계 모델에 대해 설명하고 중복된 의미 체계 모델 만들기를 방지하는 것이 왜 중요한지 알려줍니다.
  • 개인 작업 영역에서 과도한 공유: 개인 작업 영역에서 많은 공유를 수행하는 사용자에게 문의하세요. 표준 작업 영역에 대해 교육합니다.
  • 개인 작업 영역의 중요한 보고서 보기: 보고서 조회수가 많은 콘텐츠를 소유한 사용자에게 문의하세요. 표준 작업 영역이 개인 작업 영역보다 어떻게 더 나은지 설명합니다.

팁

또한 내부 Power BI 커뮤니티에서 답변한 질문과 지원 센터에 제출된 문제를 검토하여 교육 콘텐츠 또는 문서를 개선할 수도 있습니다.

보안

적극적으로 모니터링해야 할 몇 가지 보안 상황은 다음과 같습니다.

자세한 내용은 보안 계획 문서를 참조하세요.

거버넌스 및 위험 완화

다음은 발생할 수 있는 몇 가지 상황입니다. 감사 보고서에서 이러한 유형의 상황을 명시적으로 찾아내어 신속하게 작업할 수 있도록 준비하세요.

  • 승인되지 않은 보고서(및 기본 의미 체계 모델)에 대한 조회수가 많습니다.
  • 알 수 없거나 승인되지 않은 데이터 원본을 과도하게 사용합니다.
  • 원본 파일이 위치해야 하는 위치에 대한 거버넌스 지침과 일치하지 않는 파일 위치입니다.
  • 작업 영역 이름이 거버넌스 요구 사항에 맞지 않습니다.
  • 민감도 레이블은 정보 보호에 사용됩니다.
  • 일관된 데이터 새로 고침이 실패합니다.
  • 인쇄를 중요하고 반복적으로 사용합니다.
  • 구독을 예기치 않거나 과도하게 사용합니다.
  • 개인 게이트웨이가 예기치 않게 사용되었습니다.

각 상황에서 해야 하는 구체적인 작업은 거버넌스 정책에 따라 다릅니다. 자세한 내용은 패브릭 채택 로드맵의 거버넌스를 참조하세요.

검사 목록 - 감사 데이터를 기반으로 잠재적인 작업 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 명확한 기대치: 예상되는 작업에 대한 명확한 기대치가 포함된 감사 보고서를 작성합니다.
  • 작업 책임자를 명확히 설명: 역할과 책임이 할당되어 있는지 확인합니다.
  • 자동화 생성: 가능하면 반복 가능한 알려진 작업을 자동화합니다.
  • 추적 시스템 사용: 시스템을 사용하여 연락한 내용, 다음 계획된 작업, 책임자, 해결 방법, 상태 등 관찰된 상황을 추적합니다.

4단계: 유지 관리, 향상, 모니터링

테넌트 수준 감사 솔루션을 계획하고 구현하는 네 번째 단계는 유지 관리, 개선 사항, 모니터링에 중점을 둡니다. 이 시점에서는 감사 솔루션이 프로덕션에서 사용됩니다. 이제 주로 솔루션을 유지 관리, 향상, 모니터링하는 데 관심이 있습니다.

테넌트 수준 감사 솔루션 유지 관리, 개선 및 모니터링에 중점을 둔 4단계를 설명하는 흐름 다이어그램.

운영 및 개선

감사 프로세스는 일반적으로 초기 개발 및 테스트가 완료되고 프로세스가 자동화되면 프로덕션에서 실행 중인 것으로 간주됩니다. 프로덕션에서 실행되는 자동화된 감사 프로세스는 품질, 신뢰성, 안정성, 지원에 대해 수동 프로세스보다 더 큰 기대치를 갖습니다.

프로덕션 수준 감사 프로세스가 운영되었습니다. 운영 솔루션에는 일반적으로 다음과 같은 많은 특성이 포함됩니다.

  • 보안: 자격 증명은 안전하게 저장되고 관리됩니다. 스크립트에는 일반 텍스트로 된 암호나 키가 포함되어 있지 않습니다.
  • 예약: 안정적인 예약 시스템이 마련되어 있습니다.
  • 변경 관리: 변경 관리 방식과 다양한 환경을 사용하여 프로덕션 환경을 보호합니다. 개발 및 테스트 환경을 사용하거나 개발 환경만 사용할 수도 있습니다.
  • 지원: 솔루션을 지원하는 팀이 명확하게 정의되어 있습니다. 팀 멤버는 교육을 받고 운영 기대치를 이해합니다. 백업 멤버가 식별되었으며 적절한 경우 교차 교육이 이루어집니다.
  • 알림: 문제가 발생하면 자동으로 지원 팀에 알림이 전송됩니다. 알림에는 메일만 포함되는 것보다는 로그와 메일이 모두 포함되는 것이 좋습니다. 로그는 기록된 오류 및 경고를 분석하는 데 유용합니다.
  • 로깅: 감사 데이터가 업데이트된 시기에 대한 기록이 있도록 프로세스가 기록됩니다. 기록된 정보에는 시작 시간, 종료 시간, 프로세스를 실행한 사용자 또는 앱의 ID가 기록되어야 합니다.
  • 오류 처리: 스크립트와 프로세스는 오류(예: 즉시 종료할지, 계속할지, 기다렸다가 다시 시도할지 여부)를 적절하게 처리하고 기록합니다. 오류가 발생하면 지원 팀에 경고 알림이 전송됩니다.
  • 코딩 표준: 성능이 뛰어난 우수한 코딩 기법이 사용됩니다. 예를 들어 반복은 필요한 경우를 제외하고 의도적으로 방지됩니다. 솔루션을 더 쉽게 유지하고 지원할 수 있도록 일관된 코딩 표준, 주석, 서식 지정, 구문이 사용됩니다.
  • 재사용 및 모듈화: 중복을 최소화하기 위해 코드 및 구성 값(예: 알림을 위한 연결 문자열 또는 메일 주소)이 모듈화되어 다른 스크립트 및 프로세스에서 재사용할 수 있습니다.

팁

위에 나열된 모든 작업을 한 번에 수행할 필요는 없습니다. 경험이 쌓이면 솔루션을 점진적으로 개선하여 완전하고 강력해질 수 있습니다. 온라인에서 찾을 수 있는 대부분의 예제는 단순하고 일회성 스크립트 조각이므로 프로덕션 품질이 아닐 수 있습니다.

검사 목록 - 감사 솔루션을 운영 및 개선하려는 경우 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 기존 솔루션의 수준 평가: 자동화된 기존 감사 솔루션을 개선하고 안정화할 수 있는 기회가 있는지 확인합니다.
  • 프로덕션 수준 표준 설정: 자동화된 감사 프로세스에 대해 원하는 표준을 결정합니다. 시간이 지남에 따라 현실적으로 추가할 수 있는 개선 사항을 고려하세요.
  • 개선 계획 수립: 생산 감사 솔루션의 품질과 안정성을 개선할 계획을 수립합니다.
  • 별도의 개발 환경이 필요한지 확인: 위험 수준 및 프로덕션 데이터에 대한 의존도를 평가합니다. 별도의 개발 및 프로덕션(및 테스트) 환경을 언제 만들 것인지 결정합니다.
  • 데이터 보관 전략 고려: 일정 기간이 지난 후 또는 요청 시 데이터를 삭제하는 데이터 보관 프로세스를 구현해야 하는지 결정합니다.

문서 및 지원

모든 프로덕션 수준 솔루션에는 문서화 및 지원이 중요합니다. 대상 그룹과 목적에 따라 여러 유형의 문서를 만드는 것이 도움이 됩니다.

기술 문서

기술 문서는 솔루션을 구축하고 시간이 지남에 따라 점차적으로 솔루션을 개선하고 확장할 기술 팀을 대상으로 합니다. 이는 지원 팀에게도 유용한 리소스입니다.

기술 문서에는 다음이 포함되어야 합니다.

  • 아키텍처 구성 요소 및 필수 조건에 대한 요약입니다.
  • 솔루션을 소유하고 관리하는 사용자.
  • 솔루션을 지원하는 사용자.
  • 아키텍처 다이어그램.
  • 목표, 특정 기술 선택이 이루어진 이유 및 제약 조건(예: 비용 또는 기술)을 포함한 설계 결정 사항.
  • 보안 결정 및 선택 사항.
  • 사용된 명명 규칙.
  • 코딩 및 기술 표준과 지침.
  • 변경 관리 요구 사항.
  • 배포, 설정, 설치 지침.
  • 알려진 기술 문제 영역(기회가 있을 경우 개선할 수 있는 영역)

지원 설명서

감사 솔루션의 중요도 수준에 따라 긴급한 문제가 발생할 경우 지원 센터나 지원 팀이 있을 수 있습니다. 하루 종일, 매일 사용할 수 있습니다.

지원 문서는 기술 자료 또는 Runbook이라고도 합니다. 이 문서는 지원 센터 또는 지원 팀을 대상으로 하며 다음을 포함해야 합니다.

  • 문제가 발생하는 경우의 문제 해결 지침입니다. 예를 들어 데이터 새로 고침에 실패한 경우입니다.
  • 지속적으로 수행할 작업입니다. 예를 들어 문제가 해결될 때까지 누군가가 정기적으로 수행해야 하는 몇 가지 수동 단계가 있을 수 있습니다.

콘텐츠 작성자 문서

조직 전체의 다른 팀에 사용 및 채택 분석을 제공하여 감사 솔루션에서 더 많은 가치를 이끌어냅니다(필요한 경우 행 수준 보안 적용).

콘텐츠 작성자 문서는 큐레이팅된 감사 데이터를 제공하는 보고서 및 데이터 모델을 작성하는 셀프 서비스 콘텐츠 작성자를 대상으로 합니다. 여기에는 일반적인 데이터 정의를 포함하여 데이터 모델에 대한 정보가 포함되어 있습니다.

검사 목록 – 감사 솔루션에 대한 설명서 및 지원 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 솔루션을 지원할 것으로 예상되는 사람 확인: 프로덕션 수준으로 간주되는(또는 다운스트림 보고서 종속성이 있는) 감사 솔루션을 지원할 사람을 결정합니다.
  • 지원 팀의 준비 상태 확인: 지원 팀이 감사 솔루션을 지원할 준비가 되어 있는지 확인합니다. 해결해야 할 준비 상태 격차가 있는지 확인합니다.
  • 교차 교육 준비: 지원 팀을 위한 지식 이전 세션 또는 교차 교육 세션을 수행합니다.
  • 지원 팀의 기대치를 명확하게 설명: 응답 및 해결에 대한 기대치를 명확하게 문서화하고 전달합니다. 감사 솔루션과 관련된 문제를 신속하게 해결하기 위해 누군가 대기해야 하는지 여부를 결정합니다.
  • 기술 문서 만들기: 기술 아키텍처 및 설계 결정 사항에 대한 문서를 만듭니다.
  • 지원 설명서 만들기: 지원 센터 기술 자료를 업데이트하여 솔루션 지원 방법에 대한 정보를 포함합니다.
  • 콘텐츠 작성자를 위한 문서 만들기: 셀프 서비스 작성자가 데이터 모델을 사용하는 데 도움이 되는 문서를 만듭니다. 일반적인 데이터 정의를 설명하여 사용 일관성을 개선합니다.

경고 사용

감사 데이터의 특정 조건을 기반으로 경고를 발생시킬 수 있습니다. 예를 들어 누군가 게이트웨이를 삭제하거나 Power BI 관리자가 테넌트 설정을 변경할 때 경고를 발생할 수 있습니다.

자세한 내용은 테넌트 수준 모니터링을 참조하세요.

지속적인 관리

전체 감사 솔루션을 지속적으로 관리해야 합니다. 다음과 같은 경우 감사 솔루션을 확장하거나 변경해야 할 수 있습니다.

  • 조직에서 새로운 데이터 요구 사항을 발견합니다.
  • Power BI REST API에서 가져온 원시 데이터에 새 감사 이벤트가 표시됩니다.
  • Microsoft는 Power BI REST API를 변경합니다.
  • 직원은 솔루션을 개선하는 방법을 식별합니다.

Important

호환성이 손상되는 변경은 드물지만 발생할 수 있습니다. 필요한 경우 신속하게 문제를 해결하거나 감사 솔루션을 업데이트할 수 있는 사용자가 있어야 합니다.

검사 목록 - 감사 솔루션의 지속적인 관리 계획 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

  • 기술 소유자 할당: 전체 감사 솔루션에 대한 명확한 소유권과 책임이 있는지 확인합니다.
  • 백업이 있는지 확인: 지원에서 해결할 수 없는 긴급한 문제가 발생할 경우 참여할 수 있는 백업 기술 소유자가 있는지 확인합니다.
  • 추적 시스템 유지: 새로운 요청을 캡처하고 즉각적인 우선 순위와 단기, 중기, 장기(백로그) 우선 순위를 지정할 수 있는 방법이 있는지 확인합니다.

관련 콘텐츠

이 시리즈의 다음 문서에서는 테넌트 수준 모니터링에 대해 알아봅니다.