관리 ID 모범 사례 권장 사항

Azure 리소스에 대한 관리 ID는 Microsoft Entra ID의 기능입니다. Azure 리소스에 대한 관리 ID를 지원하는 각 Azure 서비스는 자체 타임라인을 따릅니다. 시작하기 전에 리소스의 관리 ID 가용성 상태와 알려진 문제를 검토하세요.

시스템 또는 사용자 할당 관리 ID 선택

사용자 할당 관리 ID는 시스템 할당 관리 ID보다 광범위한 시나리오에서 좀 더 효율적입니다. 사용자 할당 또는 시스템 할당에 대한 몇 가지 시나리오와 권장 사항은 아래 표를 참조하세요.

사용자 할당 ID는 여러 리소스에서 사용할 수 있으며 해당 수명 주기는 연결된 리소스의 수명 주기에서 분리됩니다. 관리 ID를 지원하는 리소스를 읽습니다.

이 수명 주기를 사용하면 리소스 생성 및 ID 관리 책임을 구분할 수 있습니다. 사용자 할당 ID 및 해당 역할 할당은 이러한 항목을 요구하는 리소스보다 먼저 구성할 수 있습니다. 리소스를 만드는 사용자에게는 새 ID 또는 역할 할당을 만들 필요 없이 사용자 할당 ID를 할당하기 위한 액세스 권한만 있으면 됩니다.

시스템 할당 ID는 리소스와 함께 생성 및 삭제되므로 역할 할당은 미리 만들 수 없습니다. 리소스를 만드는 사용자에게 역할 할당을 만들 수 있는 권한이 없는 경우 이 시퀀스를 사용하면 인프라를 배포하는 동안 오류가 발생할 수 있습니다.

인프라에서 여러 리소스가 동일한 리소스에 액세스하도록 요구하는 경우 단일 사용자 할당 ID를 할당할 수 있습니다. 관리할 고유 ID와 역할 할당이 더 적으므로 관리 오버헤드가 줄어듭니다.

각 리소스에 고유한 ID가 있거나 고유한 권한 집합이 필요한 리소스를 사용해야 하는 경우 리소스를 삭제할 때 ID도 삭제하려면 시스템 할당 ID를 사용해야 합니다.

시나리오 권장 주의
관리 ID를 사용하여 빠르게 리소스(예: 임시 컴퓨팅) 만들기 사용자가 할당한 ID 짧은 시간 안에 여러 개의 관리 ID를 만들려고 하는 경우, 예를 들어 자체 시스템 할당 ID를 사용하여 여러 가상 머신을 배포하는 경우 Azure Active Directory 개체 만들기에 대한 속도 제한을 초과하게 되어 요청이 HTTP 429 오류를 나타내며 실패합니다.

리소스가 빠르게 만들어지거나 삭제되는 경우 시스템 할당 ID를 사용하는 경우 Microsoft Entra ID의 리소스 수 제한을 초과할 수도 있습니다. 삭제된 시스템이 할당한 ID는 리소스에서 더 이상 액세스할 수 없지만 30일 후에 완전히 제거될 때까지 제한 계산에 포함됩니다.

단일 사용자 할당 ID와 연결된 리소스를 배포하려면 Microsoft Entra ID에 하나의 서비스 주체만 만들면 되며 속도 제한이 발생하지 않습니다. 또한 미리 생성된 단일 ID를 사용하면 자체 ID를 사용하여 여러 리소스를 만들 때 발생할 수 있는 복제 지연 위험이 줄어듭니다.

Azure 구독 서비스 제한에 대해 자세히 알아보세요.
복제된 리소스/애플리케이션 사용자가 할당한 ID 동일 작업을 수행하는 리소스(예: 중복 웹 서버 또는 동일한 기능을 앱 서비스 및 가상 머신의 애플리케이션에서 실행)는 일반적으로 동일한 권한이 필요합니다.

동일한 사용자 할당 ID를 사용하여 역할 할당을 줄임으로써 관리 오버헤드를 줄여야 합니다. 리소스가 동일한 형식일 필요는 없습니다.
규정 준수 사용자가 할당한 ID 조직에서 모든 ID 생성이 승인 프로세스를 거쳐야 하는 경우에는 여러 리소스에 대해 단일 사용자 할당 ID를 사용하면 새 리소스가 만들어질 때 생성되는 시스템 할당 ID보다 더 낮은 승인이 필요합니다.
리소스를 배포하기 전에 액세스 필요 사용자가 할당한 ID 일부 리소스의 경우 배포의 일부로 특정 Azure 리소스에 액세스해야 할 수 있습니다.

이 경우 시스템 할당 ID를 시간 내에 만들지 못할 수 있으므로 기존 사용자 할당 ID를 사용해야 합니다.
감사 로깅 시스템이 할당한 ID ID가 아니라 동작을 수행한 특정 리소스를 기록해야 하는 경우 시스템 할당 ID를 사용합니다.
사용 권한 수명 주기 관리 시스템이 할당한 ID 리소스에 대한 사용 권한을 리소스와 함께 제거해야 하는 경우 시스템 할당 ID를 사용합니다.

사용자 할당 ID를 사용하여 관리 줄이기

다이어그램은 시스템 할당 ID와 사용자 할당 ID를 여러 가상 머신에서 두 개의 스토리지 계정에 액세스할 수 있도록 하는 데 사용할 경우의 차이점을 보여 줍니다.

다이어그램에는 시스템 할당 ID를 사용하는 네 개의 가상 머신이 표시됩니다. 각 가상 머신에는 두 개의 스토리지 계정에 대한 액세스 권한을 부여하는 동일한 역할 할당이 있습니다.

Four virtual machines using system-assigned identities to access a storage account and key vault.

사용자 할당 ID가 4개의 가상 머신과 연결된 경우 시스템 할당 ID를 사용한 8개 가상 머신과 비교할 때 역할 할당이 2개만 필요합니다. 가상 머신의 ID가 추가 역할 할당을 요구하는 경우 이 ID와 연결된 모든 리소스에 부여됩니다.

Four virtual machines using a user-assigned identity to access a storage account and key vault.

보안 그룹을 사용하여 필요한 역할 할당의 수를 줄일 수도 있습니다. 이 다이어그램에서는 시스템 할당 ID는 보안 그룹에 추가되었고 시스템 할당 ID 대신 역할 할당이 그룹에 추가된 4개의 가상 머신을 보여 줍니다. 결과가 유사하지만 이 구성은 사용자 할당 ID와 동일한 Resource Manager 템플릿 기능을 제공하지 않습니다.

Four virtual machines with their system-assigned identities added to a security group that has role assignments.

여러 관리 ID

관리 ID를 지원하는 리소스에는 시스템 할당 ID와 하나 이상의 사용자 할당 ID가 포함될 수 있습니다.

이 모델은 공유 사용자 할당 ID를 사용하고 필요한 경우 세부적인 사용 권한을 적용할 수 있는 유연성을 제공합니다.

아래 예제에서 "가상 머신 3" 및 "가상 머신 4"는 인증하는 동안 사용하는 사용자 할당 ID에 따라 스토리지 계정 및 Key Vault 모두에 액세스할 수 있습니다.

Four virtual machines, two with multiple user-assigned identities.

아래 예제에서 "가상 머신 4"에는 인증하는 동안 사용되는 ID에 따라, 스토리지 계정과 Key Vault 둘 다에 액세스할 수 있도록 하는 사용자 할당 ID가 있습니다. 시스템 할당 ID에 대한 역할 할당은 해당 가상 머신에만 적용됩니다.

Four virtual machines, one with both system-assigned and user-assigned identities.

제한

관리 ID사용자 지정 역할 및 역할 할당에 대한 제한을 확인합니다.

액세스 권한을 부여할 때 최소 권한의 원칙을 따릅니다.

관리 ID를 포함하여 ID를 부여하는 경우 서비스에 액세스할 수 있는 권한은 항상 원하는 작업을 수행하는 데 필요한 최소 권한을 부여합니다. 예를 들어 관리 ID를 사용하여 스토리지 계정에서 데이터를 읽는 경우 해당 ID 권한이 스토리지 계정에 데이터를 기록하도록 허용할 필요가 없습니다. 추가 권한을 부여합니다. 예를 들어 관리 ID를 Azure 구독에 대한 기여자로 설정하는 것은 필요하지 않을 때 해당 ID와 연결된 보안 폭발 반지름이 늘어납니다. 해당 ID를 손상시키는 것으로 인해 최소 손상이 발생하도록 하기 위해 보안 폭발 반지름을 항상 최소화해야 합니다.

관리 ID를 Azure 리소스에 할당하거나 사용자에게 권한 할당을 부여하는 효과를 고려합니다.

Azure 논리 앱, Azure 함수 또는 Virtual Machine 등과 같은 Azure 리소스에 관리 ID가 할당되면 이제 관리 ID에 부여된 모든 사용 권한을 Azure 리소스에서 사용할 수 있습니다. 이는 사용자에게 이 리소스에 대한 코드를 설치하거나 실행할 수 있는 액세스 권한이 있는 경우 사용자가 Azure 리소스에 할당/연결된 모든 ID에 액세스할 수 있기 때문에 중요합니다. 관리 ID의 목적은 해당 액세스를 얻기 위해 개발자가 코드에 직접 자격 증명을 처리하거나 배치하지 않고도 다른 리소스에 대한 Azure 리소스 액세스를 실행하는 코드를 제공하는 것입니다.

예를 들어 StorageAccount7755에 대한 읽기/쓰기 액세스 권한이 관리 ID(ClientId = 1234)에 부여되고 이 관리 ID가 LogicApp3388에 할당된 경우 관리 ID 또는 스토리지 계정에 대한 직접 권한이 없지만 LogicApp3388 내에서 코드를 실행할 권한이 있는 Alice는 관리 ID를 사용하는 코드를 실행하여 StorageAccount7755에서 데이터를 읽고 쓸 수도 있습니다.

마찬가지로 Alice에게 관리 ID를 직접 할당할 수 있는 권한이 있는 경우 다른 Azure 리소스에 할당하고 관리 ID에 사용할 수 있는 모든 권한에 액세스할 수 있습니다.

security scenario

일반적으로 사용자에게 코드를 실행할 수 있는 리소스에 대한 관리 액세스 권한을 부여하고(예: 논리 앱) 관리 ID를 사용하는 경우 사용자에게 할당되는 역할에서 리소스에 대한 코드를 설치하거나 실행할 수 있으며 사용자가 필요한 경우에만 해당 역할을 할당하는 경우를 고려해야 합니다.

유지 관리

시스템 할당 ID는 리소스가 삭제될 때 자동으로 삭제되지만 사용자 할당 ID의 수명 주기는 연결된 리소스와는 별개입니다.

연결된 리소스가 없더라도 더 이상 필요하지 않은 사용자 할당 ID를 수동으로 삭제해야 합니다.

시스템 할당 또는 사용자 할당 관리 ID가 삭제되어도 역할 할당은 자동으로 삭제되지 않습니다. 이러한 역할 할당을 수동으로 삭제하여 구독당 역할 할당 제한을 초과하지 않도록 해야 합니다.

삭제된 관리 ID와 연결된 역할 할당은 포털에서 볼 때 "ID를 찾을 수 없음"으로 표시됩니다. 자세히 알아보세요.

Identity not found for role assignment.

더 이상 사용자 또는 서비스 주체와 연결되지 않은 역할 할당은 ObjectType 값이 Unknown인 상태로 나타납니다. 이를 제거하려면 여러 Azure PowerShell 명령을 함께 파이프하여 먼저 모든 역할 할당을 가져오고 ObjectType 값이 Unknown인 항목으로만 필터링한 다음 Azure에서 해당 역할 할당을 제거할 수 있습니다.

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

권한 부여에 관리 ID 사용 제한

서비스에 대한 액세스 권한을 부여하기 위해 Microsoft Entra ID 그룹을 사용하는 것은 권한 부여 프로세스를 간소화하는 좋은 방법입니다. 개념은 간단합니다. 권한을 그룹에 부여하고, 동일한 권한을 상속하도록 ID를 그룹에 추가합니다. 이는 다양한 온-프레미스 시스템에서 잘 설정된 패턴이며 ID가 사용자를 나타낼 때 효율적으로 작동합니다. Microsoft Entra ID에서 권한 부여를 제어하는 또 다른 옵션은 앱 역할을 사용하는 것입니다. 이 옵션을 사용하면 그룹(디렉터리의 전역 개념)이 아닌 앱과 관련된 역할을 선언할 수 있습니다. 그런 다음, 관리 ID(사용자 또는 그룹)에 앱 역할을 할당할 수 있습니다.

두 경우 모두 Microsoft Entra 애플리케이션 및 관리 ID와 같이 사람이 아닌 ID의 경우 이 권한 부여 정보가 애플리케이션에 제공되는 정확한 메커니즘은 현재 적합하지 않습니다. 현재 Microsoft Entra ID 및 Azure RBAC(Azure 역할 기반 Access Control)를 사용한 구현에서는 각 ID 인증을 위해 Microsoft Entra ID에서 발급한 액세스 토큰을 사용합니다. 그룹이나 역할에 ID가 추가되면 Microsoft Entra ID에서 발급한 액세스 토큰에 클레임으로 표시됩니다. Azure RBAC는 이러한 클레임을 사용하여 액세스를 허용하거나 거부하는 권한 부여 규칙을 추가로 평가합니다.

ID의 그룹 및 역할이 액세스 토큰의 클레임인 경우 토큰을 새로 고칠 때까지 권한 부여 변경 내용이 적용되지 않습니다. 일반적으로 문제가 되지 않는 사용자라면 로그아웃했다가 다시 로그인하거나 토큰 수명(기본적으로 1시간)이 만료될 때까지 기다리는 방식으로 새 액세스 토큰을 획득할 수 있기 때문입니다. 반면, 관리 ID 토큰은 성능 및 복원력을 위해 기본 Azure 인프라에 의해 캐시됩니다. 관리 ID에 대한 백 엔드 서비스는 약 24시간 동안 리소스 URI당 캐시를 유지 관리합니다. 즉, 관리 ID의 그룹 또는 역할 멤버 자격에 대한 변경 내용이 적용되는 데 몇 시간이 걸릴 수 있습니다. 현재는 관리 ID의 토큰이 만료되기 전에 강제로 새로 고칠 수 없습니다. 관리 ID의 그룹 또는 역할 멤버 자격을 변경하여 권한을 추가하거나 제거하는 경우, 해당 ID를 사용하는 Azure 리소스에 올바른 액세스 권한이 부여될 때까지 몇 시간 동안 기다려야 할 수 있습니다.

요구 사항에 이 지연이 허용되지 않는 경우 토큰에 그룹 또는 역할을 대신 사용하는 것이 좋습니다. 관리 ID에 대한 권한 변경 내용이 빠르게 적용되도록 하려면 권한 있는 Microsoft Entra 그룹에서 관리 ID를 추가하거나 제거하는 대신 권한이 ID에 직접 적용된 사용자가 할당한 관리 ID를 사용하여 Azure 리소스를 그룹화하는 것이 좋습니다. 사용자가 할당한 관리 ID는 하나 이상의 Azure 리소스에 할당하여 사용할 수 있으므로 그룹처럼 사용할 수 있습니다. 할당 작업은 관리 ID 기여자관리 ID 운영자 역할을 사용하여 제어할 수 있습니다.