다음을 통해 공유

다중 테넌트 애플리케이션을 사용하여 테넌트 간 통신 구현

  • 아티클

이 가이드에서는 다양한 Microsoft Entra 테넌트가 관리하는 Azure 구독에서 호스트되는 서비스 간의 양방향 보안 통신을 달성하는 솔루션을 제공합니다.

Azure에서 다중 테넌트 통신을 보호하는 것은 많은 서비스에 내재된 제한 사항으로 인해 어려울 수 있습니다. Azure 관리 ID를 사용하여 Microsoft Entra ID에서 토큰을 가져와서 자격 증명을 직접 관리할 필요가 없습니다. 그러나 Azure 관리 ID는 테넌트 경계에서 작동하지 않으며, 일반적인 대안은 공유 액세스 서명 URL과 같은 공유 비밀을 사용하는 것입니다. 공유 비밀을 사용하는 경우 Microsoft Entra 테넌트 경계를 넘어 비밀을 안전하게 배포하고 회전해야 합니다.

이 오버헤드를 방지하는 한 가지 옵션은 워크로드의 ID를 나타내는 다중 테넌트 애플리케이션을 만드는 것입니다. 동의 프로세스를 통해 이 워크로드 ID를 외부 테넌트에 알려서 궁극적으로 외부 테넌트에서 서비스를 인증하도록 허용할 수 있습니다.

이 문서에서는 샘플 코드를 사용하는 이 패턴의 예제 구현을 제공합니다.

이 패턴은 Microsoft Entra 테넌트 경계를 넘어 통신해야 하는 다양한 서비스가 있는 모든 다중 테넌트 시나리오에 다시 사용할 수 있습니다.

아키텍처

테넌트 간 통신 아키텍처의 다이어그램입니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

워크플로

다음 워크플로는 이전 다이어그램에 해당합니다.

  1. 공급자 쪽의 관리자는 다중 테넌트 애플리케이션 등록을 만들고 클라이언트 암호를 설정합니다.

  2. 고객 쪽의 관리자는 테넌트에 서비스 주체를 프로비전합니다. 이 서비스 주체는 공급자가 만든 다중 테넌트 애플리케이션을 기반으로 합니다. 이 단계는 여러 가지 방법으로 수행할 수 있습니다. 이 예제에서는 고객 테넌트 관리자에게 제공할 URL을 만들기로 선택했지만 대신 Microsoft Graph API를 사용할 수 있습니다.

  3. 고객은 Azure Service Bus에 액세스할 권한이 있도록 이 새 서비스 주체에 RBAC(역할 기반 액세스 제어) 역할을 적용합니다.

  4. 공급자의 함수 앱은 애플리케이션 등록의 클라이언트 ID 및 클라이언트 비밀을 사용하여 고객의 Service Bus 큐에 인증된 메시지를 보냅니다.

  5. 고객의 함수 앱은 관리 ID를 사용하여 Service Bus 트리거를 통해 큐에서 공급자의 메시지를 읽습니다.

  6. 메시지를 받은 후 고객의 함수 앱은 일반적으로 공급자에게 상태 메시지를 다시 보내기 전에 일부 작업을 수행합니다. 이 경우 데모를 위해 함수 앱은 동일한 Service Bus의 별도 큐에 있는 공급자에게 상태 메시지를 즉시 보냅니다.

  7. 이 함수 앱은 Azure Functions가 트리거하는 타이머를 통해 고객의 테넌트에서 상태 큐에서 읽습니다.

시나리오 정보

공급자에는 여러 고객이 있습니다. 공급자와 각 고객에게는 고유한 개별 Microsoft Entra ID 테넌트 및 Azure 리소스가 있습니다. 공급자와 각 고객은 Service Bus 큐를 통해 메시지를 교환할 수 있도록 안전한 양방향 통신 방법이 필요합니다. 솔루션에는 불필요한 자격 증명 또는 비밀이 도입되는 것을 방지하는 강력한 ID 스토리가 있어야 합니다.

다중 테넌트 애플리케이션에 대해 알아야 할 사항

  • 애플리케이션 개체는 애플리케이션의 전역적으로 고유한 인스턴스입니다.

  • 애플리케이션이 Microsoft Entra에 등록되면 애플리케이션 개체와 서비스 주체 개체가 테넌트에 자동으로 만들어집니다.

  • 서비스 주체 개체는 애플리케이션을 사용하고 애플리케이션 개체를 참조하는 모든 테넌트에 만들어집니다. 애플리케이션 개체는 해당 서비스 주체 개체와 일대다 관계를 맺습니다.

  • 애플리케이션 개체는 애플리케이션의 전역 표현이며 모든 테넌트에서 사용됩니다. 서비스 주체 개체는 특정 테넌트에서 사용되는 로컬 표현입니다.

  • 애플리케이션이 사용되는 각 테넌트에서 서비스 주체 개체를 만들어야 테넌트가 보호하는 리소스에 액세스하는 ID를 설정할 수 있습니다. 단일 테넌트 애플리케이션에는 홈 테넌트에 하나의 서비스 주체 개체만 있습니다. 이 서비스 주체 개체는 애플리케이션 등록 중에 만들어지고 사용할 수 있습니다. 또한 다중 테넌트 애플리케이션에는 각 테넌트에서 만든 서비스 주체 개체가 있으며 해당 테넌트의 사용자가 해당 사용에 동의했습니다.

  • Microsoft Entra 테넌트가 보호하는 리소스에 액세스하려면 보안 주체가 액세스가 필요한 엔터티를 나타내야 합니다.

  • 등록 또는 동의 시 애플리케이션에 테넌트 리소스에 액세스할 수 있는 권한이 부여되면 서비스 주체 개체가 만들어집니다. 이 아키텍처는 동의 흐름을 사용하여 구현됩니다.

공급자는 고객에게 어떻게 메시지를 표시하나요?

이상적으로 공급자는 고객의 큐에 메시지를 보내는 Azure 컴퓨팅 리소스에 관리 ID를 할당할 수 있습니다. 고객의 테넌트는 공급자의 테넌트에서 관리 ID를 신뢰하도록 구성됩니다. 그러나 기본적으로 한 테넌트에서 다른 테넌트로 ID의 "공유"를 허용하는 두 Microsoft Entra 테넌트 간의 진정한 페더레이션은 현재 불가능합니다. 따라서 공급자는 고객이 인식하는 ID를 사용하여 인증해야 합니다. 공급자는 고객이 알고 있는 서비스 주체로 고객의 Microsoft Entra 테넌트에 인증해야 합니다.

공급자는 자체 테넌트에 다중 테넌트 애플리케이션을 등록한 다음 각 고객이 연결된 서비스 주체를 테넌트에 프로비전하는 것이 좋습니다. 그런 다음 공급자는 이 서비스 주체를 사용하여 고객의 테넌트 및 고객 호스팅 API에 인증할 수 있습니다. 공급자는 이 접근 방식에서 클라이언트 비밀을 공유할 필요가 없습니다. 자격 증명 관리는 공급자의 유일한 책임입니다.

고객은 공급자에게 어떻게 메시지를 표시하나요?

고객이 공급자가 읽을 수 있는 큐를 만들거나 호스트하는 것이 좋습니다. 고객이 큐에 메시지를 씁니다. 공급자는 서비스 주체 개체를 사용하여 메시지에 대한 각 고객 큐를 반복적으로 폴링합니다. 이 방법의 단점은 공급자가 메시지를 받을 때 폴링 대기 시간을 도입한다는 것입니다. 또한 코드는 이벤트가 트리거되기를 기다리는 대신 절전 모드를 해제하고 폴링 논리를 수행해야 하므로 공급자에서 더 자주 실행해야 합니다. 그러나 자격 증명 관리는 공급자의 단독 책임을 기본 보안을 강화합니다.

또 다른 가능한 해결 방법은 공급자가 각 고객에 대한 큐를 만들거나 호스트하도록 하는 것입니다. 각 고객은 자체 다중 테넌트 애플리케이션을 만들고 공급자가 테넌트에서 서비스 주체 개체로 프로비전할 것을 요청합니다. 그런 다음 고객은 이 서비스 주체 개체를 사용하여 공급자 쪽의 고객별 큐에 메시지를 보냅니다. 자격 증명 관리는 고객의 단독 책임을 기본. 이 방법의 한 가지 단점은 공급자가 고객 애플리케이션과 연결된 서비스 주체를 테넌트에 프로비전해야 한다는 것입니다. 이 프로세스는 수동이며 공급자는 수동 단계가 새 고객을 온보딩하기 위한 흐름의 일부가 되기를 원하지 않을 수 있습니다.

샘플 코드 설정

다음 단계에서는 공급자와 고객 간에 테넌트 간 통신을 설정하는 프로세스를 안내합니다.

공급자 설정

공급자 설정에는 다중 테넌트 애플리케이션 서비스 주체를 생성 및 프로비전하는 단계와 고객 테넌트를 프로비전하는 단계가 포함됩니다.

  1. HTTP 트리거 함수 앱을 만들어 고객 테넌트 내에서 고객의 Service Bus 명령 큐에 쓸 메시지를 보냅니다.

  2. 고객 테넌트 내에서 고객의 Service Bus 내에서 상태 큐를 주기적으로 검사 시간 트리거 함수 앱을 만듭니다.

공급자의 테넌트 내에서 다중 테넌트 애플리케이션 만들기

먼저 공급자의 테넌트에 다중 테넌트 애플리케이션을 만들고 고객의 테넌트 내에서 해당 ID를 프로비전합니다. 이 시나리오에서 ID는 서비스 주체입니다. 이 문서의 앞부분에 있는 아키텍처에서는 공급자의 테넌트에서 고객의 테넌트에 서비스 주체를 설정하고 프로비전하는 방법을 보여줍니다. 또한 아키텍처는 여러 Microsoft Entra 테넌트로 프로비전하는 방법을 간략하게 설명합니다.

  1. 다중 테넌트 조직 옵션을 선택합니다.

  2. 리디렉션 URI https://entra.microsoft.com로 다음 웹 사이트를 추가합니다. . 비즈니스 요구에 맞게 이 URI를 변경할 수 있습니다.

  3. 애플리케이션(클라이언트) ID 값을 등록하고 기록해 둡니다.

새 클라이언트 암호 만들기

  1. 다중 테넌트 애플리케이션을 만든 후 이 서비스 주체에 대한 클라이언트 암호를 만듭니다.

  2. 생성된 비밀을 안전한 위치에 저장합니다. 비밀 및 클라이언트 ID는 코드를 교환하고, 인증 코드 흐름에서, 그리고 다음 단계에서 ID 토큰을 교환하는 데 필요한 클라이언트 자격 증명입니다.

Azure Functions - HTTP 트리거

HTTP 함수를 사용하여 고객의 Service Bus 배포 큐에 메시지를 전송하여 공급자의 테넌트에서 배포를 시작합니다. HTTP 트리거 함수를 전달 방법으로 선택하여 이 개념 증명을 시작합니다. 이전에 생성한 서비스 주체는 고객 테넌트에 액세스하고 Service Bus 내의 특정 큐에 쓰기 위한 자격 증명 역할을 합니다. 또한 이 단계가 제대로 작동하려면 고객 설정을 완료해야 합니다.

Azure Functions - 타이머 트리거

타이머 트리거 함수를 사용하여 고객의 테넌트 내에서 배포 상태 큐를 폴링합니다. 이 개념 증명에서 데모 목적으로 배포 상태 큐를 10초마다 폴링합니다. 이 방법을 사용하면 고객이 서비스 주체가 공급자의 테넌트에 액세스할 필요가 없습니다.

고객 설정

  1. 제공된 URL을 수정하고 사용하여 서비스 주체를 프로비전합니다.

  2. 적절한 RBAC 컨트롤을 사용하도록 공급자 서비스 주체의 범위를 지정합니다.

  3. Service Bus 메시지 큐에서 메시지를 읽고 메시지를 다른 큐에 배치하는 Service Bus 트리거 함수를 만듭니다. 데모를 위해 이 흐름은 기능을 테스트하는 데 최적입니다.

  4. Service Bus 트리거 함수에 대한 시스템 할당 관리 ID를 만듭니다.

  5. 시스템 할당 관리 ID Service Bus 범위를 할당합니다.

공급자의 테넌트에서 고객의 테넌트에 서비스 주체 프로비전

  1. 쿼리 문자열 매개 변수를 사용자 고유의 client_id 클라이언트 ID https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>로 바꾼 후 다음 URL을 방문합니다.

    관리자 Microsoft Graph API 호출, Azure PowerShell 명령 또는 Azure CLI 명령을 사용하여 서비스 주체를 다른 Microsoft Entra 테넌트에 프로비전할 수도 있습니다.

  2. 고객의 테넌트에서 계정으로 로그인합니다.

  3. 동의 화면에서 수락을 선택하여 고객 테넌트에서 공급자의 애플리케이션을 프로비전합니다. URL은 결국 고객 테넌트에 ID를 프로비전하는 데 필요한 효과가 있는 상태로 리디렉션 microsoft.com됩니다.

  4. 엔터프라이즈 애플리케이션으로 이동하여 새로 프로비전된 서비스 주체를 확인하여 고객의 Microsoft Entra 테넌트 내에서 ID를 확인합니다 .

프로비전된 서비스 주체에 대한 RBAC 설정

공급자 서비스 주체 설정에서 공급자 서비스 주체의 범위를 지정하여 Service Bus에 "Service Bus 데이터 소유자" 역할을 갖습니다. 이 서비스 주체는 HTTP 트리거 함수를 사용하여 큐에 쓰고 타이머 트리거 함수에서 큐에서 읽는 데 사용됩니다. 서비스 주체에 "Azure Service Bus 데이터 소유자" 역할을 추가해야 합니다.

Azure Functions - Service Bus 트리거

ID 기반 함수 자습서의 단계에 따라 Service Bus 큐에서 함수 트리거를 정의하고 관리 ID를 설정하는 방법을 알아봅니다. 이 지침은 메시지가 큐에 추가되면 Service Bus 큐에서 함수 앱을 트리거하는 데 도움이 됩니다. 또한 다른 큐에 메시지를 배치할 때 관리 ID를 사용합니다. 데모를 위해 동일한 함수를 사용하여 메시지를 푸시합니다.

새로 만든 Service Bus 네임스페이스에서 액세스 제어(IAM)를 선택합니다. 컨트롤 플레인에서 리소스에 대한 액세스 권한이 있는 사용자를 보고 구성할 수 있습니다.

관리 ID를 사용하여 Service Bus 네임스페이스에 대한 함수 앱 액세스 권한 부여

  1. 관리 ID에 "Azure Service Bus 데이터 수신기" 역할을 추가해야 합니다.

  2. 관리 ID 선택기에서 시스템 할당 관리 ID 범주에서 함수 앱을 선택합니다. 레이블 함수 앱 옆에 괄호 안에 숫자가 있을 수 있습니다. 이 숫자는 구독에 시스템 할당 ID가 있는 앱 수를 나타냅니다.

함수 앱에서 Service Bus에 연결

  1. 포털에서 함수 앱을 검색하거나 함수 앱 페이지에서 해당 앱으로 이동합니다.

  2. 애플리케이션 설정에서 + 새로 만들기를 선택하여 테이블에 새 애플리케이션 설정을 만듭니다. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

서비스 주체 클라이언트 비밀 수명 주기 관리

테넌트 간 아키텍처에 비밀을 도입하는 경우 생성된 클라이언트 비밀의 수명 주기를 관리해야 합니다. 클라이언트 비밀을 안전하게 저장, 회전 및 모니터링하는 방법을 알아보려면 비밀 관리에 대한 모범 사례를 참조하세요.

로컬 설정

각 하위 디렉터리에는 Azure 함수를 로컬로 실행하도록 수정할 수 있는 파일의 local.settings.json 스텁 버전이 포함되어 있습니다. Azure에서 설정을 구성하려면 애플리케이션 설정 업데이트합니다.

이 DefaultAzureCredential 명령은 Azure CLI 자격 증명에 도달하기 전에 여러 설정을 열거합니다. 혼동을 방지하려면 로컬 함수를 az login -t <tenant ID> 개발할 때 올바른 자격 증명을 부여하도록 명령을 실행하는 것이 좋습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

다음 단계