서비스 주체 이해
서비스 주체는 파이프라인, 애플리케이션 및 소프트웨어를 인증하는 방법을 제공합니다. 이 단원에서는 배포 파이프라인에 서비스 주체가 중요한 이유, 서비스 주체가 Azure의 보안 모델에 적합한 이유 및 작동 방식을 알아봅니다.
파이프라인을 인증해야 하는 이유는 무엇인가요?
Bicep 템플릿을 배포할 때 Azure 리소스를 효과적으로 만들거나 수정하도록 Azure Resource Manager에 요청합니다. 이 예제 시나리오에서는 Bicep 템플릿을 만들어서 토이 회사의 웹 사이트를 배포했습니다. Bicep 템플릿은 Azure App Service 계획, 앱, Application Insights 인스턴스를 포함하는 리소스를 선언합니다.
템플릿을 배포할 때 Resource Manager는 리소스가 있는지 확인합니다. 없는 경우 Resource Manager가 이를 만듭니다. 이미 있다면 Resource Manager는 해당 구성이 템플릿에서 지정한 구성과 일치하는지 확인합니다.
이러한 모든 작업에는 Azure 리소스에 액세스하고 수정하기 때문에 권한이 필요합니다. 배포에 필요한 특정 사용 권한은 템플릿에 포함된 내용에 따라 달라집니다. 장난감 회사의 웹 사이트에 대한 예제 Bicep 템플릿을 배포하려면 배포할 리소스 그룹 내에 다음 사용 권한이 있어야 합니다.
- 배포를 만들 수 있는 권한 배포는
Microsoft.Resources/deployments형식을 가진 리소스로 간주됩니다. - App Service 계획 및 앱을 만들고 수정할 수 있는 권한
- Application Insights 인스턴스를 만들고 수정하는 기능입니다.
지금까지는 Azure CLI 또는 Azure PowerShell을 사용하여 Bicep 템플릿을 직접 배포했을 것입니다. 이러한 도구를 사용하는 경우, 일반적으로 귀하의 사용자 계정을 사용하고 브라우저를 사용하여 인증합니다. 이는 사용자 고유의 ID를 사용하여 호출됩니다. 배포를 제출하면 Azure는 ID가 Bicep 템플릿이 지정한 작업을 수행하는 데 필요한 사용 권한을 가졌는지 확인합니다.
파이프라인으로 이동한 후에는 파이프라인 자체가 직접 개입 없이 배포를 실행하기 때문에 다른 유형의 ID를 사용해야 합니다.
보안 주체 유형
Microsoft Entra ID는 Azure의 ID를 관리하는 서비스입니다. Microsoft Entra ID에는 보안 주체라고도 하는 여러 형식의 ID가 있습니다.
- 사용자는 일반적으로 브라우저를 사용하여 대화형으로 로그인하는 사람을 나타냅니다. 사용자는 로그인할 때 MFA(다단계 인증) 및 해당 위치 또는 네트워크에 따른 조건부 액세스와 같은 추가 보안 검사를 수행해야 하는 경우가 많습니다.
- 그룹은 사용자 컬렉션을 나타냅니다. 그룹은 직접 인증하지 않지만 사용자 집합에 사용 권한을 함께 할당하는 편리한 방법을 제공합니다.
- 서비스 주체는 일반적으로 직접 실행하는 사람이 없는 자동화된 프로세스 또는 시스템을 나타냅니다.
- 관리 ID는 사람이 인증 프로세스에 참여하지 않는 상황을 위해 설계된 특수한 유형의 서비스 주체입니다.
서비스 주체
서비스 주체는 계정의 형식입니다. Microsoft Entra ID에 로그인할 수 있지만 로그인하고 인증 프로세스와 상호 작용하는 인간은 없습니다. 서비스 주체에는 MFA 또는 이와 유사한 보호가 없습니다. 이러한 보호는 사람이 자신의 ID를 증명하기 위해 무언가를 해야 하기 때문입니다.
Microsoft Entra ID에서 서비스 주체는 애플리케이션 ID와 자격 증명으로 식별됩니다. 애플리케이션 ID는 GUID(Globally Unique ID)입니다. 파이프라인의 경우 자격 증명은 일반적으로 키라고 하는 강력한 암호입니다. 또는 인증서를 자격 증명으로 사용할 수 있습니다.
관리 ID
다른 유형의 서비스 주체와 달리 관리 ID는 자격 증명을 알고 있거나 기본 요구하지 않습니다. 관리 ID는 Azure 리소스와 연결됩니다. Azure는 자격 증명을 자동으로 관리합니다. 리소스가 무언가에 액세스해야 하는 경우 Azure는 자격 증명을 사용하여 자동으로 로그인합니다.
관리 ID는 가상 머신 및 App Service 앱과 같은 Azure 호스트된 리소스에 사용할 수 있습니다. 이는 Azure 리소스가 Azure 관리를 자동화하고, 데이터베이스에 연결하고, Azure Key Vault의 비밀 데이터를 읽는 등의 상황에 대해 자신을 인증할 수 있는 좋은 방법입니다. 다른 시나리오에서도 Azure Arc와 함께 관리 ID를 사용할 수 있습니다.
파이프라인을 사용하는 경우 일반적으로 관리 ID를 사용할 수 없습니다. 관리 ID를 사용하려면 배포를 실행하는 Azure 리소스를 소유하고 관리해야 하기 때문입니다. Azure Pipelines를 사용하는 경우 일반적으로 Microsoft에서 제공하는 공유 인프라를 사용합니다.
참고
파이프라인이 관리 ID를 사용할 수 있는 몇 가지 상황이 있습니다. Azure Pipelines에서 사용자 고유의 Azure 기반 가상 머신을 사용하여 파이프라인의 스크립트와 코드를 실행하는 자체 호스팅 에이전트를 만들 수 있습니다. 가상 머신을 소유하고 있으므로 관리 ID를 할당하고 이를 파이프라인에서 사용할 수 있습니다.
그러나 대부분의 경우 Microsoft에서 관리하는 서버인 호스트된 에이전트를 사용하여 파이프라인을 실행합니다. 호스트된 에이전트는 현재 관리 ID와 호환되지 않습니다.
팁
솔루션의 기타 부분에서 관리 ID 사용과 일반 서비스 주체 사용 중 선택할 수 있는 경우 관리 ID를 사용하는 것이 가장 좋습니다. 작업하기 쉽고 일반적으로 더 안전합니다.
사용자 계정을 사용할 수 없는 이유는 무엇인가요?
완벽하게 작동하는 사용자 계정이 있는 경우 파이프라인을 인증하기 위해 이 완전히 새로운 유형의 개체를 만들어야 하는 이유가 궁금할 수 있습니다.
사용자 계정은 무인 용도로 디자인되지 않습니다. 사용자 계정에 대한 인증 프로세스는 사용자가 로그인을 시도하는 엔터티인지 확인하는 경우가 많습니다. 점점 더 많은 조직에서 인증 중 추가 보안 검사를 사용합니다. 이러한 검사에는 로그인 요청 적법성을 확인할 수 있도록 MFA, CAPTCHA 검사 및 사용자가 사용 중인 디바이스 및 네트워크 검사 등이 포함됩니다.
파이프라인은 아무도 배포를 적극적으로 실행하지 않는 경우에도 배포를 실행하도록 설계되었습니다. 실제로 파이프라인 혜택의 대부분은 이것이 완전히 자동화되어 있으며 사람의 상호 작용이 필요하지 않다는 점에서 비롯됩니다. 파이프라인에 사용자 이름과 암호를 저장 하고 이를 사용하여 로그인하는 경우 작동하지 않을 수 있습니다. 작동하는 것처럼 보이더라도 Microsoft Entra ID 또는 조직 관리자가 사용자 인증 프로세스에 더 많은 보안 검사를 추가하면 나중에 쉽게 손상될 수 있습니다.
Warning
다른 사용자가 액세스하고 가장하는 데 사용할 수 있기 때문에 아무 곳에나 사용자 이름과 암호를 저장하는 것도 좋지 않습니다.
이러한 이유로 Azure와 상호 작용하는 기본 제공 파이프라인 작업에서는 사용자 계정의 자격 증명을 제공할 수 없습니다. 여기에서는 서비스 주체를 사용해야 합니다.
서비스 주체는 어떻게 작동하나요?
서비스 주체 또는 Azure Portal 또는 Microsoft Graph API와 같은 도구를 사용할 때 사용 중인 몇 가지 다른 용어가 표시될 수 있습니다. 파이프라인에서 서비스 주체를 사용하기 위해 이러한 용어를 이해하는 것은 필수는 아니지만 개념에 대해 조금 아는 것이 좋습니다.
서비스 주체는 Microsoft Entra ID의 기능입니다. Microsoft Entra ID는 글로벌 ID 서비스입니다. 많은 회사에서 Microsoft Entra ID를 사용하고 있으며 각 회사를 테넌트라고 합니다.
Microsoft Entra ID에는 시스템, 소프트웨어, 프로세스 또는 기타 인간이 아닌 에이전트를 나타내는 애플리케이션이라는 개념이 있습니다. 배포 파이프라인을 애플리케이션으로 생각할 수 있습니다.
Microsoft Entra ID에서 애플리케이션은 인증 및 파이프라인 배포 범위를 넘어서는 많은 작업을 수행할 수 있습니다. 애플리케이션을 만들고 이를 Microsoft Entra ID에 알리면 애플리케이션 등록이라는 개체가 만들어집니다. 애플리케이션 등록은 Microsoft Entra ID의 애플리케이션을 나타냅니다.
서비스 주체 및 애플리케이션은 밀접하게 연결되어 있습니다. Microsoft Entra 테넌트에 애플리케이션 등록이 추가될 때마다 해당 Microsoft Entra 테넌트에 서비스 주체 개체가 만들어집니다. Azure Portal에서 서비스 주체를 살펴보면 관련이 없는 기타 기능 및 구성이 많이 표시될 수 있습니다. 이는 대부분 서비스 주체가 애플리케이션에 연결되기 때문입니다.
서비스 주체를 만들 때 사용하는 대부분의 도구는 동시에 애플리케이션 등록을 함께 만듭니다. 따라서 두 개의 서로 다른 개체가 있다는 것을 알지 못할 수 있습니다.
한 가지 유형의 서비스 주체는 애플리케이션 등록과 연결되지 않는 관리 ID입니다. 앞서 설명한 것처럼 Azure는 관리 ID에 대한 구성 및 자격 증명을 관리합니다.
참고
서비스 주체를 엔터프라이즈 애플리케이션이라고도 합니다. 일부 도구는 하나의 이름을 사용하고 다른 도구는 다른 이름을 사용합니다. 로컬 디렉터리의 관리 애플리케이션이라는 서비스 주체가 표시될 수도 있지만 관리 ID와 동일하지는 않습니다.
요약하면 서비스 주체를 만들 때 먼저 애플리케이션 등록을 만든 후 사용할 애플리케이션 등록을 위한 서비스 주체를 만듭니다. 작업하는 대부분의 도구는 자동으로 이 작업을 수행하므로 사용자는 이를 인식할 수 없습니다. 배포 파이프라인으로 작업할 때 Microsoft Entra 애플리케이션의 모든 기능을 사용하지 못할 수도 있습니다. 그럼에도 불구하고 서비스 주체는 애플리케이션과 관련되어 있으므로 동일한 Microsoft Entra 개체 구조가 적용됩니다.