Azure Stack Hub에 대한 ID 공급자 개요

Azure Stack Hub에는 ID 공급자로 Active Directory에서 백업하는 AD FS(Microsoft Entra ID 또는 Active Directory Federation Services)가 필요합니다. 공급자 선택은 Azure Stack Hub를 처음 배포할 때의 일회성 결정입니다. 이 문서의 개념 및 권한 부여 세부 정보는 ID 공급자 중에서 선택하는 데 도움이 될 수 있습니다.

Microsoft Entra ID 또는 AD FS 중 하나는 Azure Stack Hub를 배포하는 모드에 따라 결정됩니다.

• 연결된 모드로 배포할 때 Microsoft Entra ID 또는 AD FS를 사용할 수 있습니다.
• 연결이 끊긴 모드에서 인터넷에 연결하지 않고 배포하는 경우에는 AD FS만 지원됩니다.

Azure Stack Hub 환경에 따라 달라지는 옵션에 대한 자세한 내용은 다음 문서를 참조하세요.

• Azure Stack Hub 개발 키트: ID 고려 사항.
• Azure Stack Hub 통합 시스템: Azure Stack Hub 통합 시스템에 대한 배포 계획 결정

중요

Azure AD 그래프는 더 이상 사용되지 않으며 2023년 6월 30일에 사용 중지됩니다. 자세한 내용은 이 섹션을 참조하세요.

ID 공급자에 대한 일반 개념

다음 섹션에서는 ID 공급자에 대한 일반적인 개념과 Azure Stack Hub에서의 사용에 대해 설명합니다.

디렉터리 테넌트 및 조직

디렉터리는 사용자, 애플리케이션, 그룹 및 서비스 주체에 대한 정보를 포함하는 컨테이너입니다.

디렉터리 테넌트는 Microsoft 또는 사용자 고유의 회사와 같은 organization.

• Microsoft Entra ID는 여러 테넌트 및 자체 디렉터리의 여러 조직을 지원할 수 있습니다. Microsoft Entra ID를 사용하고 여러 테넌트가 있는 경우 한 테넌트에서 동일한 디렉터리의 다른 테넌트 액세스 권한을 앱과 사용자에게 부여할 수 있습니다.
• AD FS는 단일 테넌트만 지원하며, 따라서 단일 조직만 지원합니다.

개요

사용자 계정(ID)은 사용자 ID 및 암호를 사용하여 개인을 인증하는 표준 계정입니다. 그룹에는 사용자 또는 다른 그룹이 포함될 수 있습니다.

사용자 및 그룹을 만들고 관리하는 방법은 사용하는 ID 솔루션에 따라 달라집니다.

Azure Stack Hub에서 사용자 계정은,

• username@domain 형식으로 만들어집니다. AD FS는 사용자 계정을 Active Directory instance 매핑하지만 AD FS는 \<domain>\<alias> 형식의 사용을 지원하지 않습니다.
• 다단계 인증을 사용하도록 설정할 수 있습니다.
• 처음 등록하는 디렉터리, 즉 조직의 디렉터리로 제한됩니다.
• 온-프레미스 디렉터리에서 가져올 수 있습니다. 자세한 내용은 온-프레미스 디렉터리를 Microsoft Entra ID와 통합을 참조하세요.

조직의 사용자 포털에 로그인할 때 https://portal.local.azurestack.external URL을 사용합니다. Azure Stack Hub를 등록하는 데 사용된 도메인이 아닌 다른 도메인에서 Azure Stack Hub 포털에 로그인하는 경우 Azure Stack Hub를 등록하는 데 사용된 도메인 이름을 포털 URL에 추가해야 합니다. 예를 들어 Azure Stack Hub가 fabrikam.onmicrosoft.com 등록되어 있고 사용자 계정 로그인이 admin@contoso.com인 경우 사용자 포털에 로그인하는 데 사용할 URL은 다음과 같습니다. https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

게스트 사용자

게스트 사용자는 디렉터리의 리소스에 대한 액세스 권한이 부여된 다른 디렉터리 테넌트에서 온 사용자 계정입니다. 게스트 사용자를 지원하려면 Microsoft Entra ID를 사용하고 다중 테넌트 지원을 사용하도록 설정합니다. 지원이 활성화되면 게스트 사용자를 디렉터리 테넌트의 리소스에 액세스하도록 초대할 수 있습니다. 그러면 외부 조직과의 협업이 가능합니다.

게스트 사용자를 초대하기 위해 클라우드 운영자와 사용자는 Microsoft Entra B2B 협업을 사용할 수 있습니다. 초대된 사용자는 초대한 사용자의 디렉터리에서 문서, 리소스 및 앱에 액세스할 수 있으며, 초대한 사용자는 자신의 리소스 및 데이터에 대한 제어를 유지합니다.

게스트 사용자는 다른 조직의 디렉터리 테넌트에 로그인할 수 있습니다. 이렇게 하려면 해당 조직의 디렉터리 이름을 포털 URL에 추가합니다. 예를 들어 Contoso organization 속하고 Fabrikam 디렉터리에 로그인하려는 경우 를 사용합니다.https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

앱

Microsoft Entra ID 또는 AD FS에 앱을 등록한 다음 organization 사용자에게 앱을 제공할 수 있습니다.

앱은 다음과 같습니다.

• 웹앱: 예를 들어 Azure Portal 및 Azure Resource Manager가 있습니다. Web API 호출을 지원합니다.
• 네이티브 클라이언트: 예를 들어 Azure PowerShell, Visual Studio, Azure CLI가 있습니다.

앱은 다음 두 가지 유형의 테넌시를 지원할 수 있습니다.

• 단일 테넌트: 앱이 등록된 동일한 디렉터리에서만 사용자 및 서비스를 지원합니다.

  참고

  AD FS는 단일 디렉터리만 지원하므로 AD FS 토폴로지에서 만드는 앱은 의도적으로 단일 테넌트 앱입니다.

• 다중 테넌트: 앱이 등록된 디렉터리와 추가 테넌트 디렉터리 모두에서 사용자 및 서비스를 지원합니다. 다중 테넌트 앱을 사용하면 다른 테넌트 디렉터리(다른 Microsoft Entra 테넌트)의 사용자가 앱에 로그인할 수 있습니다.

  다중 테넌시에 대한 자세한 내용은 다중 테넌트 사용을 참조하세요.

  다중 테넌트 앱 개발에 대한 자세한 내용은 다중 테넌트 앱을 참조하세요.

앱을 등록할 때 다음 두 개의 개체를 만듭니다.

• 애플리케이션 개체: 모든 테넌트에서 앱의 전역 표현입니다. 이 관계는 소프트웨어 앱과 일대일 관계이며 앱이 처음 등록된 디렉터리에만 존재합니다.

• 서비스 주체 개체: 앱이 처음 등록된 디렉터리의 앱에 대해 만들어진 자격 증명입니다. 또한 서비스 주체가 해당 앱이 사용되는 각 추가 테넌트 디렉터리에 만들어집니다. 이 관계는 소프트웨어 앱과 일대다일 수 있습니다.

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

서비스 주체

서비스 주체는 Azure Stack Hub 리소스에 대한 액세스 권한을 부여하는 앱 또는 서비스의 자격 증명 집합입니다. 서비스 주체를 사용하면 앱 사용 권한이 앱 사용자의 권한과 구분됩니다.

서비스 주체는 앱이 사용되는 각 테넌트에서 만들어집니다. 서비스 주체는 해당 테넌트에서 보호되는 리소스(예: 사용자)에 대한 로그인 및 액세스를 위한 ID를 설정합니다.

• 단일 테넌트 앱에는 서비스 주체가 하나만 있으며, 서비스 주체는 처음에 만들어졌던 디렉터리에 있습니다. 이 서비스 주체가 만들어지고 앱 등록 시 사용되는 데 동의합니다.
• 다중 테넌트 웹앱 또는 API에는 서비스 주체가 테넌트의 사용자가 앱 사용에 동의하는 각 테넌트에서 만들어집니다.

서비스 주체의 자격 증명은 Azure Portal을 통해 생성된 키 또는 인증서일 수 있습니다. 인증서는 키보다 안전한 것으로 간주되므로 인증서를 사용하는 것이 자동화에 적합합니다.

참고

Azure Stack Hub에서 AD FS를 사용하는 경우 관리자만 서비스 주체를 만들 수 있습니다. AD FS를 사용하면 서비스 주체는 인증서가 필요하며, PEP(권한 있는 엔드포인트)를 통해 만들어집니다. 자세한 내용은 앱 ID를 사용하여 리소스 액세스를 참조하세요.

Azure Stack Hub의 서비스 주체에 대한 자세한 내용은 서비스 주체 만들기를 참조하세요.

서비스

ID 공급자와 상호 작용하는 Azure Stack Hub 서비스는 ID 공급자에 앱으로 등록됩니다. 앱과 마찬가지로 서비스는 등록을 통해 ID 시스템으로 인증할 수 있습니다.

모든 Azure 서비스는 OpenID Connect 프로토콜 및 JSON 웹 토큰을 사용하여 ID를 설정합니다. Microsoft Entra ID 및 AD FS는 프로토콜을 일관되게 사용하므로 MSAL(Microsoft 인증 라이브러리)을 사용하여 온-프레미스 또는 Azure에 인증하는 보안 토큰을 가져올 수 있습니다(연결된 시나리오). MSAL을 사용하면 클라우드 간 및 온-프레미스 리소스 관리에 Azure PowerShell 및 Azure CLI와 같은 도구를 사용할 수도 있습니다.

ID 및 ID 시스템

Azure Stack Hub ID에는 사용자 계정, 그룹 및 서비스 주체가 포함됩니다.

Azure Stack Hub를 설치하면 여러 기본 제공 앱 및 서비스가 디렉터리 테넌트에서 ID 공급자에 자동으로 등록됩니다. 등록되는 일부 서비스는 관리에 사용됩니다. 다른 서비스는 사용자가 사용할 수 있습니다. 기본 등록은 핵심 서비스에 서로 상호 작용할 수 있고 나중에 추가되는 ID와 상호 작용할 수 있는 ID를 제공합니다.

다중 테넌시를 사용하여 Microsoft Entra ID를 설정하면 일부 앱이 새 디렉터리에 전파됩니다.

인증 및 권한 부여

앱 및 사용자별 인증

앱 및 사용자의 경우 Azure Stack Hub의 아키텍처는 4개 레이어로 설명됩니다. 이러한 각 레이어 간의 상호 작용은 서로 다른 유형의 인증을 사용할 수 있습니다.

계층	레이어 간 인증
관리자 포털과 같은 도구 및 클라이언트	Azure Stack Hub에서 리소스에 액세스하거나 수정하기 위해 도구 및 클라이언트는 JSON 웹 토큰을 사용하여 Azure Resource Manager 호출합니다. Azure Resource Manager JSON 웹 토큰의 유효성을 검사하고 발급된 토큰의 클레임을 피킹하여 사용자 또는 서비스 주체가 Azure Stack Hub에서 가지고 있는 권한 부여 수준을 예측합니다.
Azure Resource Manager 및 핵심 서비스	Azure Resource Manager는 리소스 공급자와 통신하여 사용자의 통신을 전송합니다. 전송은 Azure Resource Manager 템플릿을 통해 직접 명령적 호출 또는 선언적 호출을 사용합니다.
리소스 공급자	리소스 공급자에 전달되는 호출은 인증서 기반 인증을 사용하여 보호됩니다. 그런 다음 Azure Resource Manager 및 리소스 공급자는 API를 통해 통신을 유지합니다. Azure Resource Manager로부터 수신된 모든 호출에 대해 리소스 공급자는 해당 인증서를 사용하여 호출의 유효성을 검사합니다.
인프라 및 비즈니스 논리	리소스 공급자는 선택한 인증 모드를 사용하여 비즈니스 논리 및 인프라와 통신합니다. Azure Stack Hub와 함께 제공되는 기본 리소스 공급자는 Windows 인증을 사용하여 이 통신을 보호합니다.

Azure Resource Manager에 인증

ID 공급자를 사용하여 인증하고 JSON Web Token을 수신하려면 다음 정보가 필요합니다.

1. ID 시스템(기관)의 URL: ID 공급자에 연결할 수 있는 URL입니다. 예: https://login.windows.net.
2. Azure Resource Manager의 앱 ID URI: ID 공급자에 등록된 Azure Resource Manager에 대한 고유 식별자입니다. 또한 각 Azure Stack Hub 설치에 대해서도 고유합니다.
3. 자격 증명: ID 공급자를 사용하여 인증하는 데 사용하는 자격 증명입니다.
4. Azure Resource Manager URL: URL은 Azure Resource Manager 서비스의 위치입니다. 예를 들어 https://management.azure.com 또는 https://management.local.azurestack.external입니다.

보안 주체(클라이언트, 앱 또는 사용자)가 리소스에 액세스하기 위해 인증을 요청하는 경우 요청은 다음을 포함해야 합니다.

• 보안 주체의 자격 증명
• 보안 주체가 액세스하려는 리소스의 앱 ID URI

자격 증명은 ID 공급자가 유효성을 검사합니다. 또한 ID 공급자는 앱 ID URI가 등록된 앱의 것인지, 보안 주체에게 해당 리소스에 대한 토큰을 얻을 수 있는 올바른 권한이 있는지 확인합니다. 요청이 유효한 경우 JSON Web Token이 부여됩니다.

그런 다음 토큰은 요청 헤더에서 Azure Resource Manager로 전달되어야 합니다. Azure Resource Manager는 다음을 수행합니다(특정 순서는 없음).

• 발급자(iss) 클레임의 유효성을 검사하여 토큰이 올바른 ID 공급자의 것인지 확인합니다.
• 대상(aud) 클레임의 유효성을 검사하여 토큰이 Azure Resource Manager에게 발급되었는지 확인합니다.
• JSON Web Token이 OpenID를 통해 구성되고 Azure Resource Manager에 알려진 인증서를 사용하여 서명되었는지 확인합니다.
• 발급 장소(iat) 및 만료(exp) 클레임을 검토하여 토큰이 활성 상태이고 수락될 수 있는지 확인합니다.

모든 유효성 검사가 완료되면 Azure Resource Manager는 개체 ID(oid) 및 그룹 클레임을 사용하여 보안 주체가 액세스할 수 있는 리소스 목록을 만듭니다.

참고

배포 후에는 Microsoft Entra 전역 관리자 권한이 필요하지 않습니다. 그러나 일부 작업에는 전역 관리자 자격 증명이 필요할 수 있습니다(예: 리소스 공급자 설치 관리자 스크립트 또는 권한을 부여해야 하는 새 기능). 계정의 전역 관리자 권한을 일시적으로 다시 설정하거나 기본 공급자 구독의 소유자인 별도의 전역 관리자 계정을 사용할 수 있습니다.

역할 기반 Access Control 사용

Azure Stack Hub의 RBAC(Role-Based Access Control)는 Microsoft Azure의 구현과 일치합니다. 사용자, 그룹 및 앱에 적절한 RBAC 역할을 할당하여 리소스에 대한 액세스를 관리할 수 있습니다. Azure Stack Hub에서 RBAC를 사용하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

• Azure Portal Role-Based Access Control 시작합니다.
• Role-Based Access Control 사용하여 Azure 구독 리소스에 대한 액세스를 관리합니다.
• Azure Role-Based Access Control 대한 사용자 지정 역할을 만듭니다.
• Azure Stack Hub에서 Role-Based Access Control 관리합니다.

Azure PowerShell을 사용하여 인증

Azure PowerShell 사용하여 Azure Stack Hub로 인증하는 방법에 대한 자세한 내용은 Azure Stack Hub 사용자의 PowerShell 환경 구성에서 확인할 수 있습니다.

Azure CLI를 사용하여 인증

Azure PowerShell 사용하여 Azure Stack Hub에서 인증하는 방법에 대한 자세한 내용은 Azure Stack Hub에서 사용할 Azure CLI 설치 및 구성을 참조하세요.

Azure Policy

Azure Policy를 사용하면 조직의 표준을 적용하고 규정 준수를 대규모로 평가할 수 있습니다. 규정 준수 dashboard 통해 리소스별, 정책별 세분성으로 드릴다운할 수 있는 기능으로 환경의 전체 상태를 평가하는 집계 보기를 제공합니다. 또한 기존 리소스에 대한 대량 수정 및 새 리소스에 대한 자동 수정을 통해 리소스를 규정 준수 상태로 전환할 수 있습니다.

Azure Policy에 대한 일반적인 사용 사례에는 리소스 일관성, 규정 준수, 보안, 비용 및 관리에 대한 거버넌스 구현이 포함됩니다. 이러한 일반적인 사용 사례에 대한 정책 정의는 시작하는 데 도움이 되도록 Azure 환경에 이미 기본 제공됩니다.

참고

Azure Policy 현재 Azure Stack Hub에서 지원되지 않습니다.

Azure AD 그래프

Microsoft Azure는 2020년 6월 30일에 Azure AD Graph의 사용 중단과 2023년 6월 30일의 사용 중지 날짜를 발표했습니다. Microsoft는 이 변경에 대해 이메일을 통해 고객에게 알렸다. 자세한 내용은 Azure AD Graph 사용 중지 및 Powershell 모듈 사용 중단 블로그를 참조하세요.

다음 섹션에서는 이 사용 중단이 Azure Stack Hub에 미치는 영향에 대해 설명합니다.

Azure Stack Hub 팀은 Azure Graph 팀과 긴밀히 협력하여 필요한 경우 시스템이 2023년 6월 30일 이후에도 계속 작동하여 원활한 전환을 보장합니다. 가장 중요한 작업은 Azure Stack Hub 서비스 정책을 준수하는지 확인하는 것입니다. 고객은 Azure Stack Hub의 관리자 포털에서 경고를 받게 되며 홈 디렉터리와 온보딩된 모든 게스트 디렉터리를 업데이트해야 합니다.

마이그레이션 자체의 대부분은 통합 시스템 업데이트 환경에서 수행됩니다. 고객이 해당 애플리케이션에 새 권한을 부여하는 데 필요한 수동 단계가 있습니다. 그러면 Azure Stack Hub 환경에서 사용되는 각 Microsoft Entra 디렉터리에서 전역 관리자 권한이 필요합니다. 이러한 변경 내용이 포함된 업데이트 패키지 설치가 완료되면 관리 포털에서 다중 테넌트 UI 또는 PowerShell 스크립트를 사용하여 이 단계를 완료하도록 지시하는 경고가 발생합니다. 이는 추가 디렉터리 또는 리소스 공급자를 온보딩할 때 수행하는 작업과 동일합니다. 자세한 내용은 Azure Stack Hub에서 다중 테넌트 구성을 참조하세요.

Azure Stack Hub에서 AD FS를 ID 시스템으로 사용하는 경우 이러한 그래프 변경 내용은 시스템에 직접 영향을 주지 않습니다. 그러나 Azure CLI, Azure PowerShell 등과 같은 최신 버전의 도구에는 새 Graph API가 필요하며 작동하지 않습니다. 지정된 Azure Stack Hub 빌드에서 명시적으로 지원되는 이러한 도구 버전만 사용해야 합니다.

관리 포털의 경고 외에도 업데이트 릴리스 정보를 통해 변경 내용을 전달하고 홈 디렉터리와 온보딩된 모든 게스트 디렉터리를 업데이트해야 하는 업데이트 패키지를 전달합니다.

다음 단계

• ID 아키텍처
• 데이터 센터 통합 - ID