조직의 사용자는 온-프레미스 데이터(이미 액세스 권한이 있는)에 액세스할 수 있지만 그러한 사용자가 온-프레미스 데이터 원본에 연결할 수 있기 전에 온-프레미스 데이터 게이트웨이를 설치하고 구성해야 합니다. 게이트웨이를 사용하면 클라우드의 사용자로부터 온-프레미스 데이터 원본으로, 다시 클라우드로 빠르고 안전하게 백그라운드에서 통신할 수 있습니다.

게이트웨이 설치 및 구성은 일반적으로 관리자가 수행합니다. 온-프레미스 서버에 대한 전문 지식이 있어야 하며 일부 경우에 서버 관리자 권한이 필요할 수 있습니다.

이 문서에서는 게이트웨이를 설치하고 구성하는 방법에 대한 단계별 지침을 제공하지 않습니다. 이 경우에 온-프레미스 데이터 게이트웨이를 참조하도록 합니다. 이 문서에서는 게이트웨이의 작동 방식을 깊이 있게 이해할 수 있습니다. 또한 Azure Active Directory 및 Analysis Services의 사용자 이름 및 보안, 클라우드 서비스에서 사용자가 로그인하는 데 사용하는 메일 주소, 게이트웨이 및 Active Directory를 사용하여 온-프레미스 데이터에 안전하게 연결하고 쿼리하는 방법에 대해 자세히 살펴봅니다.

게이트웨이 작동 방법

on-prem-data-gateway-how-it-works

먼저 사용자가 온-프레미스 데이터 원본에 연결된 요소를 조작하는 경우 어떻게 되는지 살펴보겠습니다.

참고:

Power BI의 경우 게이트웨이에 대한 데이터 원본을 구성해야 합니다.

  1. 쿼리는 온-프레미스 데이터 원본에 대한 암호화된 자격 증명과 함께 클라우드 서비스에 의해 생성되며 게이트웨이 처리를 위해 큐로 보내집니다.

  2. 게이트웨이 클라우드 서비스에서 쿼리를 분석하고 요청을 Azure 서비스 버스에 푸시합니다.

  3. 온-프레미스 데이터 게이트웨이는 보류 중인 요청에 대해 Azure 서비스 버스를 여론 조사합니다.

  4. 게이트웨이는 쿼리를 가져오고 자격 증명의 암호를 해독하며 해당 자격 증명을 사용하여 데이터 원본에 연결합니다.

  5. 게이트웨이는 실행에 대한 데이터 원본에 쿼리를 전송합니다.

  6. 결과는 데이터 원본에서 다시 게이트웨이로, 그런 다음 클라우드 서비스에 전송됩니다. 서비스는 결과를 사용합니다.

사용 가능한 데이터 원본 유형 목록

데이터 원본 라이브/DirectQuery 사용자 구성 수동 또는 예약 새로 고침
Analysis Services 테이블 형식
Analysis Services 다차원
파일 아니요
폴더 아니요
IBM DB2 아니요
IBM Informix 데이터베이스 아니요
Impala
MySQL 아니요
OData 아니요
ODBC 아니요
Oledb 아니요
Oracle
PostgresSQL 아니요
SAP BW 아니요
SAP HANA
SharePoint 목록(온-프레미스) 아니요
SQL Server
Sybase 아니요
Teradata
아니요

로그인 계정

사용자는 회사 또는 학교 계정으로 로그인합니다. 조직 계정입니다. Office 365 제품에 등록하고 실제 회사 전자 메일을 제공하지 않은 경우 nancy@contoso.onmicrosoft.com처럼 보일 수 있습니다. 클라우드 서비스 내의 계정은 AAD(Azure Active Directory)의 테넌트 내에 저장됩니다. 대부분의 경우에서 AAD 계정의 UPN은 전자 메일 주소와 일치합니다.

온-프레미스 데이터 원본에 대한 인증

Analysis Services를 제외하고 게이트웨이에서 온-프레미스 데이터 원본으로 연결하는 데 저장된 자격 증명이 사용됩니다. 게이트웨이는 개별 사용자에 관계없이 연결에 저장된 자격 증명을 사용합니다.

라이브 Analysis Services 데이터 원본에 대한 인증

사용자가 Analysis Services와 상호 작용할 때마다 유효 사용자 이름은 게이트웨이에 전달된 다음 온-프레미스 Analysis Services 서버에 전달됩니다. 클라우드에 로그인하는 UPN(사용자 계정 이름)은 일반적으로 전자 메일 주소이며 유효한 사용자로 Analysis Services에 통과됩니다. UPN은 연결 속성 EffectiveUserName에 전달됩니다. 이 전자 메일 주소는 로컬 Active Directory 도메인 내에서 정의된 UPN과 일치해야 합니다. UPN은 Active Directory 계정의 속성입니다. 그런 다음 해당 Windows 계정은 서버에 액세스할 수 있도록 Analysis Services 역할에 있어야 합니다. Active Directory에 일치하는 항목이 없는 경우 로그인이 성공적으로 수행되지 않습니다.

Analysis Services에서도 이 계정에 따라 필터링을 제공할 수 있습니다. 보안 또는 행 수준 보안에 따라 한 쪽 역할에 필터링이 발생할 수 있습니다.

역할 기반 보안

모델은 사용자 역할 기반 보안을 제공합니다. 역할은 SSDT-BI(SQL Server Data Tools – Business Intelligence)에서 작성하는 동안이나 모델이 배포된 후 SSMS(SQL Server Management Studio)를 사용하여 특정 모델 프로젝트에 대해 정의됩니다. 역할에는 Windows 사용자 이름 또는 Windows 그룹별로 멤버가 포함됩니다. 역할은 사용자가 모델에서 쿼리하거나 작업을 수행하는 데 필요한 권한을 정의합니다. 대부분의 사용자는 읽기 권한을 가진 역할에 속합니다. 다른 역할은 항목 처리, 데이터베이스 함수 관리, 기타 역할 관리 등을 수행할 권한이 있는 관리자를 위한 것입니다.

행 수준 보안

행 수준 보안은 Analysis Services 행 수준 보안과 관련됩니다. 모델은 동적 행 수준 보안을 제공할 수 있습니다. 사용자가 속한 역할이 하나 이상 있어야 하는 것과 달리 동적 보안은 일부 테이블 형식 모델에 필요하지 않습니다. 상위 수준의 동적 보안은 데이터에 대한 사용자의 읽기 권한을 특정 테이블에 있는 특정 행 바로 아래로 정의합니다. 역할과 마찬가지로 동적 행 수준 보안에서는 사용자의 Windows 사용자 이름을 사용합니다.

모델 데이터를 쿼리하고 보는 사용자 권한이 Windows 사용자 계정이 멤버인 역할에 의해 먼저 결정된 다음 동적 행 수준 보안(구성된 경우)에 의해 두 번째로 결정됩니다.

모델에서 역할 및 동적 행 수준 보안을 구현하는 작업은 이 문서의 범위를 벗어납니다. MSDN에서 역할(SSAS 테이블 형식)보안 역할(Analysis Services - 다차원 데이터)을 자세히 알아볼 수 있습니다. 테이블 형식 모델 보안을 가장 깊이 있게 이해하려면 테이블 형식 BI 의미 체계 모델 보안 설정(영문) 백서를 다운로드하여 읽어 보세요.

Azure Active Directory의 경우

Microsoft 클라우드 서비스는 Azure Active Directory를 사용하여 사용자 인증을 수행합니다. Azure Active Directory는 사용자 이름 및 보안 그룹을 포함하는 테넌트입니다. 일반적으로 사용자가 로그인하는 전자 메일 주소는 계정의 UPN과 같습니다.

내 로컬 Active Directory의 역할이란?

Analysis Services에서 연결되어 있는 사용자가 데이터 읽기 권한이 있는 역할에 속하는지 확인하려면 서버가 AAD에서 전달된 유효 사용자 이름을 게이트웨이로 변환한 다음 Analysis Services 서버로 변환해야 합니다. Analysis Services 서버는 유효 사용자 이름을 Windows Active Directory 도메인 컨트롤러(DC)에 전달합니다. 그러면 Active Directory DC에서 유효 사용자 이름이 유효한 UPN인지를 검사하고 로컬 계정에서 해당 사용자의 Windows 사용자 이름을 Analysis Services 서버에 다시 반환합니다.

도메인에 조인되지 않은 Analysis Services 서버에서는 EffectiveUserName을 사용할 수 없습니다. 로그인 오류를 피하기 위해 Analysis Services 서버는 도메인에 조인되어야 합니다.

내 UPN이 무엇인지 어떻게 확인합니까?

사용자 UPN이 무엇인지 알 수 없으며 도메인 관리자가 되지 못할 수도 있습니다. 워크스테이션에서 다음 명령을 사용하여 계정에 대한 UPN을 알아볼 수 있습니다.

whoami /upn

결과는 전자 메일 주소와 유사하지만 로컬 도메인 계정에 있는 UPN입니다. 라이브 연결을 위해 Analysis Services 데이터 원본을 사용하는 경우 게이트웨이에서 EffectiveUserName에 전달된 것과 일치해야 합니다.

Analysis Services 데이터 원본의 사용자 이름 매핑

Power BI에서는 Analysis Services 데이터 원본의 사용자 이름 매핑이 허용됩니다. Analysis Services 연결에서 EffectiveUserName에 대해 전달되는 이름에 Power BI를 사용하여 로그인된 사용자 이름을 매핑하는 규칙을 구성할 수 있습니다. 사용자 이름 매핑 기능은 AAD에 대한 사용자 이름이 로컬 Active Directory의 UPN과 일치하지 않는 경우 문제를 해결하는 좋은 방법입니다. 예를 들어 전자 메일 주소가 nancy@contoso.onmicrsoft.com인 경우 nancy@contoso.com에 매핑할 수 있으며 이 값을 게이트웨이에 전달합니다. 사용자 이름을 매핑하는 방법에 대해 자세히 알아볼 수 있습니다.

Azure Active Directory와 온-프레미스 Active Directory 동기화

Analysis Services 라이브 연결을 사용할 예정인 경우 로컬 Active Directory 계정을 Azure Active Directory에 일치시키려 할 수 있습니다. 계정 간에 UPN을 일치시켜야 하기 때문입니다.

클라우드 서비스만 Azure Active Directory 내의 계정에 대해 알고 있습니다. 로컬 Active Directory에서 계정을 추가했는지 여부는 중요하지 않으며 AAD에 존재하지 않는 경우 사용할 수 없습니다. 로컬 Active Directory 계정을 Azure Active Directory와 일치시킬 수 있는 다양한 방법이 있습니다.

  1. Azure Active Directory에 계정을 수동으로 추가할 수 있습니다.

    Azure 포털 또는 Office 365 관리 포털 내에 계정을 만들 수 있으며 계정 이름은 로컬 Active Directory 계정의 UPN과 일치합니다.

  2. Azure AD Connect 도구를 사용하여 로컬 계정을 Azure Active Directory 테넌트와 동기화할 수 있습니다.

    Azure AD Connect 도구는 디렉터리 및 암호 동기화를 위한 옵션을 제공합니다. 테넌트 관리자 또는 로컬 도메인 관리자가 아닌 경우 IT 관리자에게 이 내용이 구성되었는지 문의해야 합니다.

  3. ADFS(Active Directory Federation Services)를 구성할 수 있습니다.

    Azure AD Connect 도구로 ADFS 서버를 AAD 테넌트에 연결할 수 있습니다. ADFS는 위에서 설명한 디렉터리 동기화를 활용하지만 SSO(Single Sign-On) 환경을 사용할 수 있습니다. 예를 들어 작업 네트워크 내에 있고 클라우드 서비스로 전환하려고 할 때 로그인하려고 하면 사용자 이름 또는 암호를 입력하라는 메시지가 표시될 수 있습니다. 조직에서 사용할 수 있는지를 IT 관리자와 논의해야 합니다.

Azure AD Connect를 사용하면 UPN이 AAD와 로컬 Active Directory 간에 일치하도록 할 수 있습니다.

참고:

계정을 Azure AD Connect 도구와 동기화하면 AAD 테넌트 내에 새 계정이 만들어집니다.

이제 게이트웨이가 들어오는 위치입니다.

게이트웨이는 클라우드와 온-프레미스 서버 사이의 브리지 역할을 합니다. 클라우드와 게이트웨이 간의 데이터 전송은 Azure Service Bus를 통해 보안이 설정됩니다. Service Bus는 아웃바운드 연결을 통해 게이트웨이에서 클라우드와 온-프레미스 서버 사이에 보안 채널을 만듭니다. 온-프레미스 방화벽에서 열어야 하는 인바운드 연결이 없습니다.

Analysis Services 데이터 원본이 있으면 Analysis Services 서버와 동일한 포리스트/도메인에 조인된 컴퓨터에 게이트웨이를 설치해야 합니다.

게이트웨이가 서버에 가까울수록 더 빠르게 연결됩니다. 데이터 원본과 같은 서버에서 게이트웨이 얻을 수 있는 경우 게이트웨이와 서버 간의 네트워크 대기 시간을 방지하는 것이 가장 좋습니다.

다음을 수행하려면 어떻게 합니까?

게이트웨이가 설치된 후 해당 게이트웨이에 대한 데이터 소스를 만들려고 합니다. 게이트웨이 관리 화면 내에 데이터 소스를 추가할 수 있습니다. 자세한 내용은 데이터 소스 관리 문서를 참조하세요.

데이터 원본 관리 - Analysis Services
데이터 원본 관리 - SAP HANA
데이터 원본 관리 - SQL Server
데이터 원본 관리 - Oracle
데이터 원본 관리 - 가져오기/예약된 새로 고침

문제가 발생할 수 있는 경우

경우에 따라 게이트웨이가 설치되지 않을 수 있습니다. 또는 게이트웨이가 설치된 것으로 보이는데 서비스로 작업을 수행할 수 없는 경우가 있습니다. 대부분의 경우 게이트웨이가 데이터 원본에 로그인하는 데 사용하는 자격 증명에 대한 암호와 같은 간단한 원인 때문입니다.

경우에 따라 사용자가 로그인하는 데 사용하는 메일 주소의 형식 문제 또는 Analysis Services에서 유효 사용자 이름을 확인할 수 없는 문제일 수 있습니다. 트러스트 관계가 있는 여러 도메인이 있고 한 도메인에는 게이트웨이, 다른 한 도메인에는 Analysis Services가 있는 경우 몇 가지 문제가 발생할 수 있습니다.

여기에서 게이트웨이 문제 해결을 살펴보는 대신 다른 온-프레미스 데이터 게이트웨이 문제 해결 문서를 통해 일련의 문제 해결 단계를 제공했습니다. 다행히 문제가 없을 수 있습니다. 그러나 문제가 있을 경우 작동 방식 이해 및 문제 해결 문서가 도움이 될 수 있습니다.

로그인 계정

사용자는 회사 또는 학교 계정으로 로그인합니다. 조직 계정입니다. Office 365 제품에 등록하고 실제 회사 전자 메일을 제공하지 않은 경우 nancy@contoso.onmicrosoft.com처럼 보일 수 있습니다. 클라우드 서비스 내의 계정은 AAD(Azure Active Directory)의 테넌트 내에 저장됩니다. 대부분의 경우에서 AAD 계정의 UPN은 전자 메일 주소와 일치합니다.

Windows 서비스 계정

온-프레미스 데이터 게이트웨이는 Windows 서비스 로그온 자격 증명에 대해 NT SERVICE\PBIEgwService 를 사용하도록 구성됩니다. 기본적으로 여기에는 서비스로 로그온 권한이 포함됩니다. 게이트웨이를 설치하는 컴퓨터의 컨텍스트입니다.

참고:

개인 모드를 선택한 경우 Windows 서비스 계정을 개별적으로 구성합니다.

온-프레미스 데이터 원본에 연결하는 데 사용하는 계정이 아닙니다. 또한 클라우드 서비스로 로그인하는 회사 또는 학교 계정이 아닙니다.

인증으로 인해 프록시 서버에 문제가 발생하는 경우, Windows 서비스 계정을 도메인 사용자나 관리 서비스 계정으로 변경하는 것이 좋습니다. 프록시 구성에서 계정을 변경하는 방법에 대해 알아볼 수 있습니다.

포트

게이트웨이는 Azure 서비스 버스에 대한 아웃바운드 연결을 만듭니다. 이 게이트웨이는 아웃바운드 포트 TCP 443(기본값), 5671, 5672, 9350 ~ 9354에서 통신합니다. 게이트웨이에는 인바운드 포트가 필요하지 않습니다. 자세히 알아보기

방화벽에, 데이터 영역에 대한, IP 주소 허용 목록을 작성하는 것이 좋습니다. Microsoft Azure 데이터 센터 IP 목록을 다운로드할 수 있습니다. 이 목록은 매주 업데이트됩니다. 게이트웨이는 정규화된 도메인 이름(FQDN)과 함께 IP 주소를 사용하여 Azure Service Bus와 통신합니다. 게이트웨이가 HTTPS를 사용하여 통신하도록 강제 적용하는 경우 엄격하게 FQDN만을 사용하며 IP 주소를 사용하여 통신이 발생하지 않습니다.

참고:

Azure 데이터 센터 IP 목록에 나열되는 IP 주소는 CIDR 표기법 형식입니다. 예를 들어, 10.0.0.0/24는 10.0.0.0에서 10.0.0.24까지를 의미하지 않습니다. CIDR 표기법에 대해 자세히 알아보세요.

게이트웨이에 사용되는 정규화된 도메인 이름의 목록입니다.

도메인 이름 아웃바운드 포트 설명
*.download.microsoft.com 80 설치 프로그램을 다운로드하는 데 사용하는 HTTP입니다.
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 AMQP(고급 메시지 큐 프로토콜)
*.servicebus.windows.net 443, 9350-9354 TCP를 통한 서비스 버스 릴레이의 수신기(액세스 제어 토큰 획득에는 443 필요)
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 게이트웨이를 Power BI 서비스에 연결할 수 없는 경우 인터넷 연결을 테스트하는 데 사용합니다.
*.microsoftonline-p.com 443 구성에 따라 인증에 사용됩니다.
참고:

Visualstudio.com 또는 visualstudioonline.com으로 향하는 트래픽은 App Insights용이며 게이트웨이가 작동하는 데는 필요하지 않습니다.

HTTPS가 Azure Service Bus와 통신하도록 강제 적용

게이트웨이가 직접 TCP 대신 HTTPS를 사용하여 Azure Service Bus와 통신하도록 강제할 수 있습니다. 그러면 성능에 영향을 줄 수 있습니다. 이렇게 하려면 이 단락 바로 다음에 나오는 코드 조각에 표시된 것과 같이 AutoDetect에서 Https로 값을 변경하여 Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config 파일을 수정합니다. 해당 파일은(기본적으로) C:\Program Files\온-프레미스 데이터 게이트웨이 에 있습니다.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

또는 게이트웨이가 2017년 3월 릴리스로 시작하는 게이트웨이 사용자 인터페이스를 사용하여 이 동작을 채택하도록 강제 적용할 수 있습니다. 게이트웨이 사용자 인터페이스에서 네트워크를 선택한 다음 Azure Service Bus 연결 모드설정으로 전환합니다.

변경한 후에 적용(변경을 할 때만 표시되는 단추)을 선택하면 변경이 적용되도록 게이트웨이Windows 서비스 가 자동으로 다시 시작됩니다.

나중에 참조하려면 서비스 설정을 선택한 다음 지금 다시 시작*을 선택하여 사용자 인터페이스 대화 상자에서 *게이트웨이 Windows 서비스 를 다시 시작할 수 있습니다.

게이트웨이를 다시 시작하는 방법

게이트웨이는 Windows 서비스로 실행됩니다. Windows 서비스와 마찬가지로 시작하고 중지할 수 있습니다. 이 작업을 수행하는 방법은 여러 가지가 있습니다. 명령 프롬프트에서 이를 수행하는 방법을 다음과 같습니다.

  1. 게이트웨이가 실행 중인 컴퓨터에서 관리자 명령 프롬프트를 시작합니다.

  2. 다음 명령을 사용하여 서비스를 중지합니다.

    net stop PBIEgwService

  3. 다음 명령을 사용하여 서비스를 시작합니다.

    net start PBIEgwService

참고 항목

온-프레미스 데이터 게이트웨이 문제 해결
Azure Service Bus
Azure AD Connect
궁금한 점이 더 있나요? Power BI 커뮤니티를 이용하세요.