Azure Data Factory 및 Synapse Analytics 보안 이슈와 액세스 제어 이슈 해결
적용 대상:
Azure Data Factory Azure Synapse Analytics
팁
기업용 올인원 분석 솔루션인 Microsoft Fabric의 Data Factory를 사용해 보세요. Microsoft Fabric은 데이터 이동부터 데이터 과학, 실시간 분석, 비즈니스 인텔리전스 및 보고에 이르기까지 모든 것을 다룹니다. 무료로 새 평가판을 시작하는 방법을 알아봅니다!
이 문서에서는 Azure Data Factory 및 Synapse Analytics 파이프라인의 보안과 액세스 제어에 대한 일반적인 문제 해결 방법을 살펴봅니다.
일반적인 오류 및 메시지
클라우드 데이터 저장소의 복사 작업에서 연결 문제 발생
증상
원본 또는 싱크 데이터 저장소에서 연결 문제가 발생하는 경우 다양한 오류 메시지가 반환될 수 있습니다.
원인
이 문제의 원인은 일반적으로 다음 요인 중 하나입니다.
자체 호스팅 IR(통합 런타임)을 사용하는 경우 자체 호스팅 IR 노드의 프록시 설정
자체 호스팅 IR을 사용하는 경우 자체 호스팅 IR 노드의 방화벽 설정
클라우드 데이터 저장소의 방화벽 설정
해결
연결 문제인지 확인하려면 다음 사항을 확인하세요.
- 이 오류는 원본 또는 싱크 커넥터에서 throw됩니다.
- 복사 작업을 시작할 때 오류가 발생합니다.
- 이 오류는 노드 중 일부에만 문제가 있는 경우 다중 노드 자체 호스팅 IR에서 임의의 오류가 발생할 수 있기 때문에 Azure IR 또는 자체 호스팅 IR에서 일관됩니다.
Azure IR을 사용하는 경우 동일한 데이터 저장소에 연결할 수 있으므로 자체 호스팅 IR을 사용하는 경우 프록시, 방화벽 및 네트워크 설정을 확인합니다. 이 문제를 해결하려면 다음을 수행합니다.
Azure IR을 사용하는 경우 데이터 저장소의 방화벽 설정을 사용하지 않도록 설정해 봅니다. 이 방법은 다음과 같은 두 가지 상황에서 문제를 해결할 수 있습니다.
- Azure IR IP 주소 는 허용 목록에 없습니다.
- 신뢰할 수 있는 Microsoft 서비스가 이 스토리지 계정에 액세스하도록 허용 기능은 Azure Blob Storage 및 Azure Data Lake Storage Gen 2에 대해 해제되어 있습니다.
- Azure Data Lake Storage Gen1에 대해 Azure 서비스에 대한 액세스 허용 설정이 사용하도록 설정되어 있지 않습니다.
앞의 방법이 전혀 작동하지 않는 경우 Microsoft에 도움을 요청하세요.
삭제되거나 거부된 프라이빗 엔드포인트가 여전히 ADF에서 승인됨을 표시함
증상
ADF에서 관리형 프라이빗 엔드포인트를 만들고 승인된 프라이빗 엔드포인트를 가져왔습니다. 그러나 나중에 프라이빗 엔드포인트를 삭제하거나 거부한 후에도 ADF의 관리형 프라이빗 엔드포인트는 계속 존재하며 "승인됨"을 표시합니다.
원인
현재 ADF는 승인된 후 프라이빗 엔드포인트 상태 가져오기를 중지합니다. 또한 ADF에 표시된 상태가 부실합니다.
해결
기존 프라이빗 엔드포인트가 원본/싱크 데이터 세트에서 거부/삭제되면 ADF에서 관리형 프라이빗 엔드포인트를 삭제해야 합니다.
퍼블릭 네트워크 액세스를 사용하지 않도록 설정한 후에 올바르지 않거나 비어 있는 인증 키 문제 발생
증상
서비스에 대한 공용 네트워크 액세스를 사용하지 않으면 자체 호스팅 통합 런타임에서 The Authentication key is invalid or empty. 또는 Cannot connect to the data factory. Please check whether the factory has enabled public network access or the machine is hosted in a approved private endpoint Virtual Network. 오류가 발생합니다.
원인
퍼블릭 연결을 사용하지 않도록 설정하고 프라이빗 엔드포인트를 설정하면 다시 연결할 수 없게 되므로 DNS(Domain Name System) 확인 문제로 인해 이 문제가 발생할 수 있습니다.
서비스의 FQDN(정규화된 도메인 이름)이 공용 IP 주소로 확인되는지 여부를 확인하려면 다음을 수행합니다.
서비스의 프라이빗 엔드포인트와 동일한 가상 네트워크에서 Azure VM(가상 머신)을 만들었는지 확인합니다.
Azure VM에서 서비스 FQDN으로 PsPing 및 Ping을 실행합니다.
psping.exe <dataFactoryName>.<region>.datafactory.azure.net:443ping <dataFactoryName>.<region>.datafactory.azure.net참고 항목
PsPing 명령에 대한 포트를 지정해야 합니다. 여기에는 포트 443이 표시되지만 반드시 필요한 것은 아닙니다.
두 명령이 지정된 영역을 기준으로 하는 Azure Data Factory 공용 IP로 확인되는지 알아봅니다. IP는
xxx.xxx.xxx.0형식이어야 합니다.
해결
이 문제를 해결하려면 다음을 수행하세요.
경우에 따라 서비스의 "프라이빗 링크 DNS 영역" 아래에서 "가상 네트워크 링크"를 수동으로 추가하는 것이 좋습니다. 자세한 내용은 Azure Private Link 문서를 참조하세요. 이 지침은 서비스 FQDN을 개인 IP 주소로 확인하도록 프라이빗 DNS 영역이나 사용자 지정 DNS 서버를 구성하기 위한 지침입니다.
그러나 프라이빗 DNS 영역 또는 사용자 지정 DNS 서버를 구성하지 않으려면 다음 임시 솔루션을 시도해 보세요.
Windows에서 호스트 파일을 변경하고 개인 IP(서비스의 프라이빗 엔드포인트)를 서비스 FQDN에 매핑합니다.
Azure VM에서
C:\Windows\System32\drivers\etc로 이동한 후 메모장에서 host 파일을 엽니다. 파일의 끝에 있는 FQDN에 개인 IP를 매핑하는 줄을 추가하고 변경 내용을 저장합니다.
위의 확인 단계와 동일한 명령을 다시 실행하여 개인 IP를 포함하는 응답을 확인합니다.
자체 호스팅 통합 런타임을 다시 등록하면 문제가 해결됩니다.
프라이빗 링크로 인해 자체 호스팅 VM에 IR 인증 키를 등록할 수 없습니다.
증상
프라이빗 링크가 사용하도록 설정되어 있으므로 자체 호스팅 VM에서 IR 인증 키를 등록할 수 없습니다. 다음과 같은 오류 메시지가 표시됩니다.
"ADF 서비스에서 다음 키를 사용하여 서비스 토큰을 가져오지 못했습니다. *************** 시간 비용: 0.1250079초, 오류 코드: InvalidGatewayKey, activityId: XXXXXXX 및 자세한 오류 메시지는 클라이언트 IP 주소가 올바른 개인 IP가 아닙니다. 원인 Data Factory가 공용 네트워크에 액세스할 수 없으므로 클라우드로 연결할 수 없습니다."
원인
이 문제는 자체 호스팅 IR을 설치하려는 VM 때문에 발생할 수 있습니다. 클라우드에 연결하려면 퍼블릭 네트워크 액세스를 사용하도록 설정해야 합니다.
해결
해결 방법 1
이 문제를 해결하려면 다음을 수행하세요.
팩터리 - 업데이트 페이지로 이동합니다.
오른쪽 위에서 체험해 보기 단추를 선택합니다.
매개 변수에서 필요한 정보를 입력합니다.
본문 아래에 다음 속성을 붙여넣습니다.
{ "tags": { "publicNetworkAccess":"Enabled" } }실행을 선택하여 함수를 실행합니다.
매개 변수에서 필요한 정보를 입력합니다.
본문 아래에 다음 속성을 붙여넣습니다.
{ "tags": { "publicNetworkAccess":"Enabled" } }실행을 선택하여 함수를 실행합니다.
응답 코드: 200이 표시되는지 확인합니다. 붙여넣은 속성은 JSON 정의에도 표시되어야 합니다.
통합 런타임에 IR 인증 키를 다시 추가합니다.
해결 방법 2
이 이슈를 해결하려면 Azure Private Link로 이동합니다.
다음 스크린샷에 표시된 것처럼 사용자 인터페이스에서 퍼블릭 네트워크 액세스를 사용하도록 설정해 봅니다.
서비스 프라이빗 DNS 영역은 Azure Resource Manager DNS 확인을 재정의하므로 '찾을 수 없음' 오류가 발생함
원인
Azure Resource Manager와 서비스 모두 같은 프라이빗 영역을 사용하므로 Azure Resource Manager 레코드를 찾을 수 없는 시나리오에서 고객의 프라이빗 DNS와 충돌할 수 있습니다.
해결
- Azure Portal에서 프라이빗 DNS 영역 privatelink.azure.com을 찾습니다.
- A 레코드 adf가 있는지 확인합니다.
- 가상 네트워크 링크로 이동하고 모든 레코드를 삭제합니다.
- Azure Portal에서 서비스로 이동하고 포털의 프라이빗 엔드포인트를 다시 만듭니다.
- 프라이빗 DNS 영역으로 돌아가서 새 프라이빗 DNS 영역 privatelink.adf.azure.com이 있는지 확인합니다.
퍼블릭 엔드포인트에 연결 오류 발생
증상
Azure Blob Storage 계정 퍼블릭 액세스 권한을 사용하여 데이터를 복사하는 경우 다음과 같은 오류를 나타내며 파이프라인 실행이 실패합니다.
예를 들어, Azure Blob Storage 싱크에서 Azure IR(관리형 VNet이 아닌 퍼블릭)을 사용하며 Azure SQL Database 원본은 관리형 VNet IR을 사용하지 않습니다. 또는 원본/싱크에서는 스토리지 퍼블릭 액세스를 수행할 때만 관리형 VNet IR을 사용합니다.
<LogProperties><Text>Invoke callback url with req: "ErrorCode=AzureBlobFailedToCreateContainer,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Unable to create Azure Blob container. Endpoint: XXXXXXX/, Container Name: test.,Source=Microsoft.DataTransfer.ClientLibrary,''Type=Microsoft.WindowsAzure.Storage.StorageException,Message=Unable to connect to the remote server,Source=Microsoft.WindowsAzure.Storage,''Type=System.Net.WebException,Message=Unable to connect to the remote server,Source=System,''Type=System.Net.Sockets.SocketException,Message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond public ip:443,Source=System,'","Details":null}}</Text></LogProperties>.
원인
서비스는 관리형 VNet IR을 계속 사용할 수 있지만 관리형 VNet의 Azure Blob Storage에 대한 퍼블릭 엔드포인트는 테스트 결과를 기준으로 안정적이지 않으며 Azure Blob Storage 및 Azure Data Lake Gen2가 관리형 가상 네트워크 및 관리형 프라이빗 엔드포인트에 따라 서비스의 관리형 가상 네트워크에서 퍼블릭 엔드포인트를 통해 연결될 수 없습니다.
해결
- 관리형 VNet IR을 사용하는 경우 원본 및 싱크 쪽에서 프라이빗 엔드포인트를 사용하도록 설정합니다.
- 여전히 퍼블릭 엔드포인트를 사용하려는 경우 원본 및 싱크에 대해 관리형 VNet IR을 사용하는 대신, 퍼블릭 IR로 전환할 수 있습니다. 퍼블릭 IR로 다시 전환하더라도 관리형 VNet IR이 계속 있으면 서비스에서 관리형 VNet IR을 계속 사용할 수 있습니다.
CMK(고객 관리형 키) 및 UA-MI(사용자가 할당한 관리 ID)를 사용하여 데이터 팩터리나 Synapse 작업 영역을 삭제하려고 하는 동안 내부 오류 발생
증상
{\"error\":{\"code\":\"InternalError\",\"message\":\"Internal error has occurred.\"}}
원인
CMK와 관련된 작업을 수행하는 경우 먼저 서비스와 관련된 모든 작업을 완료한 다음, 외부 작업(예: 관리 ID 또는 Key Vault 작업)을 완료해야 합니다. 예를 들어 모든 리소스를 삭제하려면 먼저 서비스 인스턴스를 삭제한 다음, 키 자격 증명 모음을 삭제해야 합니다. 먼저 키 자격 증명 모음을 삭제하면 서비스에서 필요한 개체를 더 이상 읽을 수 없고 삭제가 가능한지 여부를 검증할 수 없으므로 이 오류가 발생합니다.
해결
다음 세 가지 방법으로 이 문제를 해결할 수 있습니다. 다음과 같습니다.
CMK 키가 저장된 키 자격 증명 모음에 대한 서비스의 액세스 권한을 취소했습니다. 키 가져오기, 래핑 해제 및 키 래핑 사용 권한에 대한 액세스를 다시 할당할 수 있습니다. 이러한 사용 권한에서 고객 관리형 키를 사용해야 합니다. 고객 관리형 키에 대한 액세스 권한 부여를 참조하세요. 사용 권한이 제공되면 서비스를 삭제할 수 있어야 합니다.
고객이 서비스를 삭제하기 전에 키 자격 증명 모음/CMK를 삭제했습니다. 서비스의 CMK에서 기본 보존 정책이 90일인 “일시 삭제”와 “제거 방지”를 사용해야 합니다. 삭제된 키를 복원할 수 있습니다.
삭제된 키 복구 및 삭제된 키 값을 검토하세요.서비스 전에 UA-MI(사용자가 할당한 관리 ID)가 삭제되었습니다. REST API 호출을 사용하여 이 문제를 복구할 수 있으며 모든 프로그래밍 언어로 선택한 HTTP 클라이언트에서 이 작업을 수행할 수 있습니다. Azure 인증을 사용하여 REST API 호출을 아직 설정하지 않은 경우 POSTMAN/Fiddler를 사용하는 것이 가장 쉬운 방법입니다. 다음 단계를 수행하세요.
https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01과 같은 GET 메서드를 사용하여 GET을 호출합니다.다른 이름으로 새 사용자 관리 ID를 만들어야 합니다(동일한 이름을 사용해도 되지만, 명확성을 위해 GET 응답에 있는 이름과 다른 이름을 사용하는 것이 더 안전함).
새로 생성된 관리 ID를 가리키도록 encryption.identity 속성 및 identity.userassignedidentities를 수정합니다. userAssignedIdentity 개체에서 clientId 및 principalId를 제거합니다.
새 본문을 전달하는 동일한 URL에 PUT을 호출합니다. GET 응답에서 얻은 모든 것을 전달하고 ID만 수정하는 것이 매우 중요합니다. 그러지 않으면 의도하지 않게 다른 설정이 재정의됩니다.
호출이 성공하면 엔터티를 다시 확인하고 삭제를 다시 시도할 수 있습니다.
자체 호스팅 통합 런타임 공유
다른 테넌트의 자체 호스팅 IR 공유는 지원되지 않습니다.
증상
UI에서 자체 호스팅 IR을 공유하려고 할 때 (다른 테넌트에 있는) 다른 데이터 팩터리를 확인할 수 있지만 다른 테넌트에 있는 데이터 팩터리에서 공유할 수는 없습니다.
원인
자체 호스팅 IR은 테넌트 간에 공유할 수 없습니다.
관련 콘텐츠
문제 해결에 대한 도움이 필요한 경우 다음 리소스를 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기