온-프레미스 데이터 게이트웨이 심층 분석On-premises data gateway in-depth

조직의 사용자는 온-프레미스 데이터(이미 액세스 권한이 있는)에 액세스할 수 있지만 그러한 사용자가 온-프레미스 데이터 원본에 연결할 수 있기 전에 온-프레미스 데이터 게이트웨이를 설치하고 구성해야 합니다.It's possible for users in your organization to access on-premises data (to which they already have access authorization), but before those users can connect to your on-premises data source, an on-premises data gateway needs to be installed and configured. 게이트웨이를 사용하면 클라우드의 사용자로부터 온-프레미스 데이터 원본으로, 다시 클라우드로 빠르고 안전하게 백그라운드에서 통신할 수 있습니다.The gateway facilitates quick and secure behind-the-scenes communication between a user in the cloud, to your on-premises data source, and then back to the cloud.

게이트웨이 설치 및 구성은 일반적으로 관리자가 수행합니다.Installing and configuring a gateway is usually done by an administrator. 온-프레미스 서버에 대한 전문 지식이 있어야 하며 일부 경우에 서버 관리자 권한이 필요할 수 있습니다.It may require special knowledge of your on-premises servers and in some cases may require Server Administrator permissions.

이 문서에서는 게이트웨이를 설치하고 구성하는 방법에 대한 단계별 지침을 제공하지 않습니다.This article doesn’t provide step-by-step guidance on how to install and configure the gateway. 이 경우에 온-프레미스 데이터 게이트웨이를 참조하도록 합니다.For that, be sure to see On-premises data gateway. 이 문서에서는 게이트웨이의 작동 방식을 깊이 있게 이해할 수 있습니다.This article is meant to provide you with an in-depth understanding of how the gateway works. 또한 Azure Active Directory 및 Analysis Services의 사용자 이름 및 보안, 클라우드 서비스에서 사용자가 로그인하는 데 사용하는 메일 주소, 게이트웨이 및 Active Directory를 사용하여 온-프레미스 데이터에 안전하게 연결하고 쿼리하는 방법에 대해 자세히 살펴봅니다.We’ll also go into some detail about usernames and security in both Azure Active Directory and Analysis Services, and how the cloud service uses the e-mail address a user sign in with, the gateway, and Active Directory to securely connect to and query your on-premises data.

게이트웨이 작동 방법How the gateway works

On-prem-data-gateway-how-it-works

먼저 사용자가 온-프레미스 데이터 원본에 연결된 요소를 조작하는 경우 어떻게 되는지 살펴보겠습니다.Let’s first look at what happens when a user interacts with an element connected to an on-premises data source.

참고

Power BI의 경우 게이트웨이에 대한 데이터 원본을 구성해야 합니다.For Power BI, you will need to configure a data source for the gateway.

  1. 쿼리는 온-프레미스 데이터 원본에 대한 암호화된 자격 증명과 함께 클라우드 서비스에 의해 생성되며 게이트웨이 처리를 위해 큐로 보내집니다.A query will be created by the cloud service, along with the encrypted credentials for the on-premises data source, and sent to the queue for the gateway to process.
  2. 게이트웨이 클라우드 서비스에서 쿼리를 분석하고 요청을 Azure Service Bus에 푸시합니다.The gateway cloud service will analyze the query and will push the request to the Azure Service Bus.
  3. 온-프레미스 데이터 게이트웨이는 보류 중인 요청에 대해 Azure Service Bus를 여론 조사합니다.The on-premises data gateway polls the Azure Service Bus for pending requests.
  4. 게이트웨이는 쿼리를 가져오고 자격 증명의 암호를 해독하며 해당 자격 증명을 사용하여 데이터 원본에 연결합니다.The gateway gets the query, decrypts the credentials and connects to the data source(s) with those credentials.
  5. 게이트웨이는 실행에 대한 데이터 원본에 쿼리를 전송합니다.The gateway sends the query to the data source for execution.
  6. 결과는 데이터 원본에서 다시 게이트웨이로, 그런 다음 클라우드 서비스에 전송됩니다.The results are sent from the data source, back to the gateway, and then onto the cloud service. 서비스는 결과를 사용합니다.The service then uses the results.

사용 가능한 데이터 원본 유형 목록List of available data source types

데이터 원본Data source 라이브/DirectQueryLive/DirectQuery 사용자 구성 수동 또는 예약 새로 고침User configured manual or scheduled refresh
Analysis Services 테이블 형식Analysis Services Tabular Yes Yes
Analysis Services 다차원Analysis Services Multidimensional Yes Yes
파일File 아니요No Yes
폴더Folder 아니요No Yes
IBM DB2IBM DB2 아니요No Yes
IBM Informix 데이터베이스IBM Informix Database 아니요No Yes
ImpalaImpala Yes Yes
MySQLMySQL 아니요No Yes
ODataOData 아니요No Yes
ODBCODBC 아니요No Yes
OledbOledb 아니요No Yes
OracleOracle Yes Yes
PostgresSQLPostgresSQL 아니요No Yes
SAP BWSAP BW Yes Yes
SAP HANASAP HANA Yes Yes
SharePoint 목록(온-프레미스)SharePoint list (on-premises) 아니요No Yes
SnowflakeSnowflake Yes Yes
SQL ServerSQL Server Yes Yes
SybaseSybase 아니요No Yes
TeradataTeradata Yes Yes
Web 아니요No Yes

로그인 계정Sign in account

사용자는 회사 또는 학교 계정으로 로그인합니다.Users will sign in with either a work or school account. 조직 계정입니다.This is your organization account. Office 365 제품에 등록하고 실제 회사 전자 메일을 제공하지 않은 경우 nancy@contoso.onmicrosoft.com처럼 보일 수 있습니다. 클라우드 서비스 내의 계정은 AAD(Azure Active Directory)의 테넌트 내에 저장됩니다.If you signed up for an Office 365 offering and didn’t supply your actual work email, it may look like nancy@contoso.onmicrosoft.com. Your account, within a cloud service, is stored within a tenant in Azure Active Directory (AAD). 대부분의 경우에서 AAD 계정의 UPN은 전자 메일 주소와 일치합니다.In most cases, your AAD account’s UPN will match the email address.

온-프레미스 데이터 원본에 대한 인증Authentication to on-premises data sources

Analysis Services를 제외하고 게이트웨이에서 온-프레미스 데이터 원본으로 연결하는 데 저장된 자격 증명이 사용됩니다.A stored credential will be used to connect to on-premises data sources from the gateway except Analysis Services. 게이트웨이는 개별 사용자에 관계없이 연결에 저장된 자격 증명을 사용합니다.Regardless of the individual user, the gateway uses the stored credential to connect.

라이브 Analysis Services 데이터 원본에 대한 인증Authentication to a live Analysis Services data source

사용자가 Analysis Services와 상호 작용할 때마다 유효 사용자 이름은 게이트웨이에 전달된 다음 온-프레미스 Analysis Services 서버에 전달됩니다.Each time a user interacts with Analysis Services, the effective username is passed to the gateway and then onto your on-premises Analysis Services server. 클라우드에 로그인하는 UPN(사용자 계정 이름)은 일반적으로 전자 메일 주소이며 유효한 사용자로 Analysis Services에 통과됩니다.The user principal name (UPN), typically the email address you sign into the cloud with, is what we will pass to Analysis Services as the effective user. UPN은 연결 속성 EffectiveUserName에 전달됩니다.The UPN is passed in the connection property EffectiveUserName. 이 전자 메일 주소는 로컬 Active Directory 도메인 내에서 정의된 UPN과 일치해야 합니다.This email address should match a defined UPN within the local Active Directory domain. UPN은 Active Directory 계정의 속성입니다.The UPN is a property of an Active Directory account. 그런 다음 해당 Windows 계정은 서버에 액세스할 수 있도록 Analysis Services 역할에 있어야 합니다.That Windows account then needs to be present in an Analysis Services role to have access to the server. Active Directory에 일치하는 항목이 없는 경우 로그인이 성공적으로 수행되지 않습니다.The login will not be successful if no match is found in Active Directory.

Analysis Services에서도 이 계정에 따라 필터링을 제공할 수 있습니다.Analysis Services can also provide filtering based on this account. 보안 또는 행 수준 보안에 따라 한 쪽 역할에 필터링이 발생할 수 있습니다.The filtering can occur with either role based security, or row-level security.

역할 기반 보안Role-based security

모델은 사용자 역할 기반 보안을 제공합니다.Models provide security based on user roles. 역할은 SSDT-BI(SQL Server Data Tools – Business Intelligence)에서 작성하는 동안이나 모델이 배포된 후 SSMS(SQL Server Management Studio)를 사용하여 특정 모델 프로젝트에 대해 정의됩니다.Roles are defined for a particular model project during authoring in SQL Server Data Tools – Business Intelligence (SSDT-BI), or after a model is deployed, by using SQL Server Management Studio (SSMS). 역할에는 Windows 사용자 이름 또는 Windows 그룹별로 멤버가 포함됩니다.Roles contain members by Windows username or by Windows group. 역할은 사용자가 모델에서 쿼리하거나 작업을 수행하는 데 필요한 권한을 정의합니다.Roles define permissions a user has to query or perform actions on the model. 대부분의 사용자는 읽기 권한을 가진 역할에 속합니다.Most users will belong to a role with Read permissions. 다른 역할은 항목 처리, 데이터베이스 함수 관리, 기타 역할 관리 등을 수행할 권한이 있는 관리자를 위한 것입니다.Other roles are meant for administrators with permissions to process items, manage database functions, and manage other roles.

행 수준 보안Row-level security

행 수준 보안은 Analysis Services 행 수준 보안과 관련됩니다.Row-level security is specific to Analysis Services row-level security. 모델은 동적 행 수준 보안을 제공할 수 있습니다.Models can provide dynamic, row-level security. 사용자가 속한 역할이 하나 이상 있어야 하는 것과 달리 동적 보안은 일부 테이블 형식 모델에 필요하지 않습니다.Unlike having at least one role in which users belong to, dynamic security is not required for any tabular model. 상위 수준의 동적 보안은 데이터에 대한 사용자의 읽기 권한을 특정 테이블에 있는 특정 행 바로 아래로 정의합니다.At a high-level, dynamic security defines a user’s read access to data right down to a particular row in a particular table. 역할과 마찬가지로 동적 행 수준 보안에서는 사용자의 Windows 사용자 이름을 사용합니다.Similar to roles, dynamic row-level security relies on a user’s Windows username.

모델 데이터를 쿼리하고 보는 사용자 권한이 Windows 사용자 계정이 멤버인 역할에 의해 먼저 결정된 다음 동적 행 수준 보안(구성된 경우)에 의해 두 번째로 결정됩니다.A user’s ability to query and view model data are determined first by the roles their Windows user account are a member of and second, by dynamic row-level security, if configured.

모델에서 역할 및 동적 행 수준 보안을 구현하는 작업은 이 문서의 범위를 벗어납니다.Implementing role and dynamic row-level security in models are beyond the scope of this article. MSDN에서 역할(SSAS 테이블 형식)보안 역할(Analysis Services - 다차원 데이터)을 자세히 알아볼 수 있습니다.You can learn more at Roles (SSAS Tabular) and Security Roles (Analysis Services - Multidimensional Data) on MSDN. 테이블 형식 모델 보안을 가장 깊이 있게 이해하려면 테이블 형식 BI 의미 체계 모델 보안 설정(영문) 백서를 다운로드하여 읽어 보세요.And, for the most in-depth understanding of tabular model security, download and read the Securing the Tabular BI Semantic Model whitepaper.

Azure Active Directory의 경우What about Azure Active Directory?

Microsoft 클라우드 서비스는 Azure Active Directory를 사용하여 사용자 인증을 수행합니다.Microsoft cloud services use Azure Active Directory to take care of authenticating users. Azure Active Directory는 사용자 이름 및 보안 그룹을 포함하는 테넌트입니다.Azure Active Directory is the tenant that contains usernames and security groups. 일반적으로 사용자가 로그인하는 전자 메일 주소는 계정의 UPN과 같습니다.Typically, the email address a user signs in with is the same as the UPN of the account.

내 로컬 Active Directory의 역할이란?What is my local Active Directory’s role?

Analysis Services에서 연결되어 있는 사용자가 데이터 읽기 권한이 있는 역할에 속하는지 확인하려면 서버가 AAD에서 전달된 유효 사용자 이름을 게이트웨이로 변환한 다음 Analysis Services 서버로 변환해야 합니다.For Analysis Services to determine if a user connecting to it belongs to a role with permissions to read data, the server needs to convert the effective username passed from AAD to the gateway, and onto the Analysis Services server. Analysis Services 서버는 유효 사용자 이름을 Windows Active Directory 도메인 컨트롤러(DC)에 전달합니다.The Analysis Services server passes the effective username to a Windows Active Directory domain controller (DC). 그러면 Active Directory DC에서 유효 사용자 이름이 유효한 UPN인지를 검사하고 로컬 계정에서 해당 사용자의 Windows 사용자 이름을 Analysis Services 서버에 다시 반환합니다.The Active Directory DC then validates the effective username is a valid UPN, on a local account, and returns that user’s Windows username back to the Analysis Services server.

도메인에 조인되지 않은 Analysis Services 서버에서는 EffectiveUserName을 사용할 수 없습니다.EffectiveUserName cannot be used on a non-domain joined Analysis Services server. 로그인 오류를 피하기 위해 Analysis Services 서버는 도메인에 조인되어야 합니다.The Analysis Services server must be joined to a domain to avoid any login errors.

내 UPN이 무엇인지 어떻게 확인합니까?How do I tell what my UPN is?

사용자 UPN이 무엇인지 알 수 없으며 도메인 관리자가 되지 못할 수도 있습니다.You may not know what your UPN is, and you may not be a domain administrator. 워크스테이션에서 다음 명령을 사용하여 계정에 대한 UPN을 알아볼 수 있습니다.You can use the following command from your workstation to find out the UPN for your account.

whoami /upn

결과는 전자 메일 주소와 유사하지만 로컬 도메인 계정에 있는 UPN입니다.The result will look similar to an email address, but this is the UPN that is on your local domain account. 라이브 연결을 위해 Analysis Services 데이터 원본을 사용하는 경우 게이트웨이에서 EffectiveUserName에 전달된 것과 일치해야 합니다.If you are using an Analysis Services data source for live connections, this must match what was passed to EffectiveUserName from the gateway.

Analysis Services 데이터 원본의 사용자 이름 매핑Mapping usernames for Analysis Services data sources

Power BI에서는 Analysis Services 데이터 원본의 사용자 이름 매핑이 허용됩니다.Power BI allows for mapping usernames for Analysis Services data sources. Analysis Services 연결에서 EffectiveUserName에 대해 전달되는 이름에 Power BI를 사용하여 로그인된 사용자 이름을 매핑하는 규칙을 구성할 수 있습니다.You can configure rules to map a username logged in with Power BI to a name that is passed for EffectiveUserName on the Analysis Services connection. 사용자 이름 매핑 기능은 AAD에 대한 사용자 이름이 로컬 Active Directory의 UPN과 일치하지 않는 경우 문제를 해결하는 좋은 방법입니다.The map user names feature is a great way to work around when your username in AAD doesn't match a UPN in your local Active Directory. 예를 들어 전자 메일 주소가 nancy@contoso.onmicrsoft.com인 경우 nancy@contoso.com에 매핑할 수 있으며 이 값을 게이트웨이에 전달합니다.For example, if your email address is nancy@contoso.onmicrsoft.com, you could map it to nancy@contoso.com, and that value would be passed to the gateway. 사용자 이름을 매핑하는 방법에 대해 자세히 알아볼 수 있습니다.You can learn more about how to map user names.

Azure Active Directory와 온-프레미스 Active Directory 동기화Synchronize an on-premises Active Directory with Azure Active Directory

Analysis Services 라이브 연결을 사용할 예정인 경우 로컬 Active Directory 계정을 Azure Active Directory에 일치시키려 할 수 있습니다.You would want your local Active Directory accounts to match Azure Active Directory if you are going to be using Analysis Services live connections. 계정 간에 UPN을 일치시켜야 하기 때문입니다.As the UPN has to match between the accounts.

클라우드 서비스만 Azure Active Directory 내의 계정에 대해 알고 있습니다.The cloud services only know about accounts within Azure Active Directory. 로컬 Active Directory에서 계정을 추가했는지 여부는 중요하지 않으며 AAD에 존재하지 않는 경우 사용할 수 없습니다.It doesn’t matter if you added an account in your local Active Directory, if it doesn’t exist in AAD, it cannot be used. 로컬 Active Directory 계정을 Azure Active Directory와 일치시킬 수 있는 다양한 방법이 있습니다.There are different ways that you can match your local Active Directory accounts with Azure Active Directory.

  1. Azure Active Directory에 계정을 수동으로 추가할 수 있습니다.You can add accounts manually to Azure Active Directory.

    Azure 포털 또는 Office 365 관리 포털 내에 계정을 만들 수 있으며 계정 이름은 로컬 Active Directory 계정의 UPN과 일치합니다.You can create an account on the Azure portal, or within the Office 365 Admin Portal, and the account name matches the UPN of the local Active Directory account.

  2. Azure AD Connect 도구를 사용하여 로컬 계정을 Azure Active Directory 테넌트와 동기화할 수 있습니다.You can use the Azure AD Connect tool to synchronize local accounts to your Azure Active Directory tenant.

    Azure AD Connect 도구는 디렉터리 및 암호 동기화를 위한 옵션을 제공합니다.The Azure AD Connect tool provides options for directory and password synchronization. 테넌트 관리자 또는 로컬 도메인 관리자가 아닌 경우 IT 관리자에게 이 내용이 구성되었는지 문의해야 합니다.If you are not a tenant admin or a local domain administrator, you will need to contact your IT admin to get this configured.

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

    Azure AD Connect 도구로 ADFS 서버를 AAD 테넌트에 연결할 수 있습니다.You can associate your ADFS server to your AAD tenant with the Azure AD Connect tool. ADFS는 위에서 설명한 디렉터리 동기화를 활용하지만 SSO(Single Sign-On) 환경을 사용할 수 있습니다.ADFS makes use of the directory synchronization discussed above but allows for a single sign-on (SSO) experience. 예를 들어 작업 네트워크 내에 있고 클라우드 서비스로 전환하려고 할 때 로그인하려고 하면 사용자 이름 또는 암호를 입력하라는 메시지가 표시될 수 있습니다.For example, if you are within your work network, when you to a cloud service, and go to sign in, you may not be prompted to enter a username or password. 조직에서 사용할 수 있는지를 IT 관리자와 논의해야 합니다.You will need to discuss with your IT Admin if this is available for your organization.

Azure AD Connect를 사용하면 UPN이 AAD와 로컬 Active Directory 간에 일치하도록 할 수 있습니다.Using Azure AD Connect ensures that the UPN will match between AAD and your local Active Directory.

참고

계정을 Azure AD Connect 도구와 동기화하면 AAD 테넌트 내에 새 계정이 만들어집니다.Synchronizing accounts with the Azure AD Connect tool will create new accounts within your AAD tenant.

이제 게이트웨이가 들어오는 위치입니다.Now, this is where the gateway comes in

게이트웨이는 클라우드와 온-프레미스 서버 사이의 브리지 역할을 합니다.The gateway acts as a bridge between the cloud and your on-premises server. 클라우드와 게이트웨이 간의 데이터 전송은 Azure Service Bus를 통해 보안이 설정됩니다.Data transfer between the cloud and the gateway is secured through Azure Service Bus. Service Bus는 아웃바운드 연결을 통해 게이트웨이에서 클라우드와 온-프레미스 서버 사이에 보안 채널을 만듭니다.The Service Bus creates a secure channel between the cloud and your on-premises server through an outbound connection on the gateway. 온-프레미스 방화벽에서 열어야 하는 인바운드 연결이 없습니다.There are no inbound connections that you need to open on your on-premises firewall.

Analysis Services 데이터 원본이 있으면 Analysis Services 서버와 동일한 포리스트/도메인에 조인된 컴퓨터에 게이트웨이를 설치해야 합니다.If you have an Analysis Services data source, you’ll need to install the gateway on a computer joined to the same forest/domain as your Analysis Services server.

게이트웨이가 서버에 가까울수록 더 빠르게 연결됩니다.The closer the gateway is to the server, the faster the connection will be. 데이터 원본과 같은 서버에서 게이트웨이 얻을 수 있는 경우 게이트웨이와 서버 간의 네트워크 대기 시간을 방지하는 것이 가장 좋습니다.If you can get the gateway on the same server as the data source, that is best to avoid network latency between the gateway and the server.

다음을 수행하려면 어떻게 합니까?What to do next?

게이트웨이가 설치된 후 해당 게이트웨이에 대한 데이터 소스를 만들려고 합니다.After you get the gateway installed, you will want to create data sources for that gateway. 게이트웨이 관리 화면 내에 데이터 소스를 추가할 수 있습니다.You can add data sources within the Manage gateways screen. 자세한 내용은 데이터 소스 관리 문서를 참조하세요.For more information, see the manage data sources articles.

데이터 원본 관리 - Analysis ServicesManage your data source - Analysis Services
데이터 원본 관리 - SAP HANAManage your data source - SAP HANA
데이터 원본 관리 - SQL ServerManage your data source - SQL Server
데이터 원본 관리 - OracleManage your data source - Oracle
데이터 원본 관리 - 가져오기/예약된 새로 고침Manage your data source - Import/Scheduled refresh

문제가 발생할 수 있는 경우Where things can go wrong

경우에 따라 게이트웨이가 설치되지 않을 수 있습니다.Sometimes installing the gateway fails. 또는 게이트웨이가 설치된 것으로 보이는데 서비스로 작업을 수행할 수 없는 경우가 있습니다.Or, maybe the gateway seems to install ok, but the service is still unable to work with it. 대부분의 경우 게이트웨이가 데이터 원본에 로그인하는 데 사용하는 자격 증명에 대한 암호와 같은 간단한 원인 때문입니다.In many cases, it’s something simple, like the password for the credentials the gateway uses to sign into the data source.

경우에 따라 사용자가 로그인하는 데 사용하는 메일 주소의 형식 문제 또는 Analysis Services에서 유효 사용자 이름을 확인할 수 없는 문제일 수 있습니다.In other cases, there might be issues with the type of e-mail address users sign in with, or Analysis Services’ inability to resolve an effective username. 트러스트 관계가 있는 여러 도메인이 있고 한 도메인에는 게이트웨이, 다른 한 도메인에는 Analysis Services가 있는 경우 몇 가지 문제가 발생할 수 있습니다.If you have multiple domains with trusts between them, and your gateway is in one and Analysis Services in another, this sometimes can cause some problems.

여기에서 게이트웨이 문제 해결을 살펴보는 대신 다른 온-프레미스 데이터 게이트웨이 문제 해결 문서를 통해 일련의 문제 해결 단계를 제공했습니다.Rather than go into troubleshooting gateway issues here, we’ve put a series of troubleshooting steps into another article; Troubleshooting the on-premises data gateway. 다행히 문제가 없을 수 있습니다.Hopefully, you won’t have any problems. 그러나 문제가 있을 경우 작동 방식 이해 및 문제 해결 문서가 도움이 될 수 있습니다.But if you do, understanding how all of this works and the troubleshooting article should help.

로그인 계정Sign in account

사용자는 회사 또는 학교 계정으로 로그인합니다.Users will sign in with either a work or school account. 조직 계정입니다.This is your organization account. Office 365 제품에 등록하고 실제 회사 전자 메일을 제공하지 않은 경우 nancy@contoso.onmicrosoft.com처럼 보일 수 있습니다. 클라우드 서비스 내의 계정은 AAD(Azure Active Directory)의 테넌트 내에 저장됩니다.If you signed up for an Office 365 offering and didn’t supply your actual work email, it may look like nancy@contoso.onmicrosoft.com. Your account, within a cloud service, is stored within a tenant in Azure Active Directory (AAD). 대부분의 경우에서 AAD 계정의 UPN은 전자 메일 주소와 일치합니다.In most cases, your AAD account’s UPN will match the email address.

Windows 서비스 계정Windows Service account

온-프레미스 데이터 게이트웨이는 Windows 서비스 로그온 자격 증명에 대해 NT SERVICE\PBIEgwService 를 사용하도록 구성됩니다.The on-premises data gateway is configured to use NT SERVICE\PBIEgwService for the Windows service logon credential. 기본적으로 여기에는 서비스로 로그온 권한이 포함됩니다.By default, it has the right of Log on as a service. 게이트웨이를 설치하는 컴퓨터의 컨텍스트입니다.This is in the context of the machine that you are installing the gateway on.

참고

개인 모드를 선택한 경우 Windows 서비스 계정을 개별적으로 구성합니다.If you selected personal mode, you configure the Windows service account separately.

온-프레미스 데이터 원본에 연결하는 데 사용하는 계정이 아닙니다.This is not the account used to connect to on-premises data sources. 또한 클라우드 서비스로 로그인하는 회사 또는 학교 계정이 아닙니다.This is also not your work or school account that you sign into cloud services with.

인증으로 인해 프록시 서버에 문제가 발생하는 경우, Windows 서비스 계정을 도메인 사용자나 관리 서비스 계정으로 변경하는 것이 좋습니다.If you encounter issues with your proxy server, due to authentication, you may want to change the Windows service account to a domain user or managed service account. 프록시 구성에서 계정을 변경하는 방법에 대해 알아볼 수 있습니다.You can learn how to change the account in proxy configuration.

포트Ports

게이트웨이는 Azure 서비스 버스에 대한 아웃바운드 연결을 만듭니다.The gateway creates an outbound connection to Azure Service Bus. 이 게이트웨이는 아웃바운드 포트 TCP 443(기본값), 5671, 5672, 9350 ~ 9354에서 통신합니다.It communicates on outbound ports: TCP 443 (default), 5671, 5672, 9350 thru 9354. 게이트웨이에는 인바운드 포트가 필요하지 않습니다.The gateway does not require inbound ports. 자세히 알아보기Learn more

방화벽에, 데이터 영역에 대한, IP 주소 허용 목록을 작성하는 것이 좋습니다.It is recommended that you whitelist the IP addresses, for your data region, in your firewall. Microsoft Azure 데이터 센터 IP 목록을 다운로드할 수 있습니다.You can download the Microsoft Azure Datacenter IP list. 이 목록은 매주 업데이트됩니다.This list is updated weekly. 게이트웨이는 정규화된 도메인 이름(FQDN)과 함께 IP 주소를 사용하여 Azure Service Bus와 통신합니다.The gateway will communicate with Azure Service Bus using the IP address along with the fully qualified domain name (FQDN). 게이트웨이가 HTTPS를 사용하여 통신하도록 강제 적용하는 경우 엄격하게 FQDN만을 사용하며 IP 주소를 사용하여 통신이 발생하지 않습니다.If you are forcing the gateway to communicate using HTTPS it will strictly use FQDN only, and no communication will happen using IP addresses.

참고

Azure 데이터 센터 IP 목록에 나열되는 IP 주소는 CIDR 표기법 형식입니다.The IP Addresses listed in the Azure Datacenter IP list are in CIDR notation. 예를 들어, 10.0.0.0/24는 10.0.0.0에서 10.0.0.24까지를 의미하지 않습니다.For example, 10.0.0.0/24 does not mean 10.0.0.0 thru 10.0.0.24. CIDR 표기법에 대해 자세히 알아보세요.Learn more about the CIDR notation.

게이트웨이에 사용되는 정규화된 도메인 이름의 목록입니다.Here is a listing of the fully qualified domain names used by the gateway.

도메인 이름Domain names 아웃바운드 포트Outbound ports 설명Description
*.download.microsoft.com*.download.microsoft.com 8080 설치 프로그램을 다운로드하는 데 사용하는 HTTP입니다.HTTP used to download the installer.
*.powerbi.com*.powerbi.com 443443 HTTPSHTTPS
*.analysis.windows.net*.analysis.windows.net 443443 HTTPSHTTPS
*.login.windows.net*.login.windows.net 443443 HTTPSHTTPS
*.servicebus.windows.net*.servicebus.windows.net 5671-56725671-5672 AMQP(고급 메시지 큐 프로토콜)Advanced Message Queuing Protocol (AMQP)
*.servicebus.windows.net*.servicebus.windows.net 443, 9350-9354443, 9350-9354 TCP를 통한 서비스 버스 릴레이의 수신기(액세스 제어 토큰 획득에는 443 필요)Listeners on Service Bus Relay over TCP (requires 443 for Access Control token acquisition)
*.frontend.clouddatahub.net*.frontend.clouddatahub.net 443443 HTTPSHTTPS
*.core.windows.net*.core.windows.net 443443 HTTPSHTTPS
login.microsoftonline.comlogin.microsoftonline.com 443443 HTTPSHTTPS
*.msftncsi.com*.msftncsi.com 443443 게이트웨이를 Power BI 서비스에 연결할 수 없는 경우 인터넷 연결을 테스트하는 데 사용합니다.Used to test internet connectivity if the gateway is unreachable by the Power BI service.
*.microsoftonline-p.com*.microsoftonline-p.com 443443 구성에 따라 인증에 사용됩니다.Used for authentication depending on configuration.

참고

Visualstudio.com 또는 visualstudioonline.com으로 향하는 트래픽은 App Insights용이며 게이트웨이가 작동하는 데는 필요하지 않습니다.Traffic going to visualstudio.com or visualstudioonline.com are for app insights and are not required for the gateway to function.

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

게이트웨이가 직접 TCP 대신 HTTPS를 사용하여 Azure Service Bus와 통신하도록 강제할 수 있습니다.You can force the gateway to communicate with Azure Service Bus using HTTPS instead of direct TCP. 그러면 성능에 영향을 줄 수 있습니다.This may have an impact on performance. 이렇게 하려면 이 단락 바로 다음에 나오는 코드 조각에 표시된 것과 같이 AutoDetect에서 Https로 값을 변경하여 Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config 파일을 수정합니다.To do so, modify the Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config file by changing the value from AutoDetect to Https, as shown in the code snippet directly following this paragraph. 해당 파일은(기본적으로) C:\Program Files\온-프레미스 데이터 게이트웨이 에 있습니다.That file is located (by default) at C:\Program Files\On-premises data gateway.

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

ServiceBusSystemConnectivityModeString 매개 변수의 값은 대/소문자를 구분합니다.The value for the ServiceBusSystemConnectivityModeString parameter is case sensitive. 유효한 값은 AutoDetectHttps입니다.Valid values are AutoDetect and Https.

또는 게이트웨이가 2017년 3월 릴리스로 시작하는 게이트웨이 사용자 인터페이스를 사용하여 이 동작을 채택하도록 강제 적용할 수 있습니다.Alternatively, you can force the gateway to adopt this behavior using the gateway user interface, beginning with the March 2017 release. 게이트웨이 사용자 인터페이스에서 네트워크를 선택한 다음 Azure Service Bus 연결 모드설정으로 전환합니다.In the gateway user interface select Network, then toggle the Azure Service Bus connectivity mode to On.

변경한 후에 적용(변경을 할 때만 표시되는 단추)을 선택하면 변경이 적용되도록 게이트웨이Windows 서비스 가 자동으로 다시 시작됩니다.Once changed, when you select Apply (a button that only appears when you make a change), the gateway Windows service restarts automatically, so the change can take effect.

나중에 참조하려면 서비스 설정을 선택한 다음 지금 다시 시작을 선택하여 사용자 인터페이스 대화 상자에서 게이트웨이 Windows 서비스 를 다시 시작할 수 있습니다.For future reference, you can restart the gateway Windows service from the user interface dialog by selecting Service Settings then select Restart Now.

TLS 1.1/1.2에 대한 지원Support for TLS 1.1/1.2

2017년 8월 업데이트 및 그 이후에 온-프레미스 데이터 게이트웨이는 기본적으로 TLS(전송 계층 보안) 1.1 또는 1.2를 사용하여 Power BI 서비스와 통신합니다.With the August 2017 update and beyond, the on-premises data gateway uses Transport Layer Security (TLS) 1.1 or 1.2 to communicate with the Power BI service by default. 온-프레미스 데이터 게이트웨이의 이전 버전은 기본적으로 TLS 1.0을 사용합니다.Previous versions of the on-premises data gateway use TLS 1.0 by default. 2018년 3월 15일에 TLS 1.0을 사용하는 Power BI 서비스와 상호 작용하는 게이트웨이 기능을 포함하여 TLS 1.0에 대한 지원이 종료되므로, 게이트웨이가 계속 작동하도록 하려면 그때까지 온-프레미스 데이터 게이트웨이 설치를 2017년 8월 릴리스 이상으로 업그레이드해야 합니다.On March 15th 2018, support for TLS 1.0 will end, including the gateway's ability to interact with the Power BI service using TLS 1.0, so by then you must upgrade your on-premises data gateway installations to the August 2017 release or newer to ensure your gateways continue to operate.

11월 1일 이전까지 TLS 1.0은 온-프레미스 데이터 게이트웨이로 계속 지원되며, 대체 메커니즘으로 게이트웨이에서 사용됩니다.It's important to note that TLS 1.0 is still supported by the on-premises data gateway prior to November 1st, and is used by the gateway as a fallback mechanism. 모든 게이트웨이 트래픽에서 TLS 1.1 또는 1.2를 사용하도록 하려면(및 게이트웨이에서 TLS 1.0을 사용하지 않도록 하려면) 게이트웨이 서비스를 실행하는 컴퓨터에서 다음 레지스트리 키를 추가하거나 수정해야 합니다.To ensure all gateway traffic uses TLS 1.1 or 1.2 (and to prevent the use of TLS 1.0 on your gateway), you must add or modify the following registry keys on the machine running the gateway service:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001

참고

이러한 레지스트리 키를 추가하거나 수정하면 변경 내용이 모든 .NET 응용 프로그램에 적용됩니다.Adding or modifying these registry keys applies the change to all .NET applications. 다른 응용 프로그램에 대한 TLS에 영향을 주는 레지스트리 변경에 대한 정보는 TLS(전송 계층 보안) 레지스트리 설정을 참조하세요.For information about registry changes that affect TLS for other applications, see Transport Layer Security (TLS) registry settings.

게이트웨이를 다시 시작하는 방법How to restart the gateway

게이트웨이는 Windows 서비스로 실행됩니다.The gateway runs as a windows service. Windows 서비스와 마찬가지로 시작하고 중지할 수 있습니다.You can start and stop it like any windows service. 이 작업을 수행하는 방법은 여러 가지가 있습니다.There are multiple ways to do this. 명령 프롬프트에서 이를 수행하는 방법을 다음과 같습니다.Here is how you can do it from the command prompt.

  1. 게이트웨이가 실행 중인 컴퓨터에서 관리자 명령 프롬프트를 시작합니다.On the machine where the gateway is running, launch an admin command prompt.
  2. 다음 명령을 사용하여 서비스를 중지합니다.Use the following command to stop the service.

    net stop PBIEgwServicenet stop PBIEgwService

  3. 다음 명령을 사용하여 서비스를 시작합니다.Use the following command to start the service.

    net start PBIEgwServicenet start PBIEgwService

다음 단계Next steps

온-프레미스 데이터 게이트웨이 문제 해결Troubleshooting the on-premises data gateway
Azure Service BusAzure Service Bus
Azure AD ConnectAzure AD Connect
궁금한 점이 더 있나요?More questions? Power BI 커뮤니티를 이용하세요.Try the Power BI Community