서비스 주체 및 키 만들기
이제 서비스 주체의 개념을 이해했으므로 이것이 Microsoft Entra ID에 대한 ID를 어떻게 증명하는지 궁금할 것입니다. 이 단원에서는 서비스 주체에 대한 인증 프로세스 및 자격 증명에 대해 알아봅니다. 또한 서비스 주체를 만들고 키를 제공하는 방법을 알아봅니다.
서비스 주체의 인증 방법 이해
서비스 주체가 Azure와 통신해야 하는 경우 Microsoft Entra ID에 로그인합니다. Microsoft Entra ID는 서비스 주체의 ID를 확인한 후 클라이언트 애플리케이션이 Azure에 요청할 때 저장하고 사용하는 토큰을 발급합니다.
대체로 이 프로세스는 사용자가 직접 Azure에 로그인 할 때 작동하는 방법과 비슷합니다. 그러나 사용자와 비교했을 때 서비스 주체는 ID를 증명하기 위해 약간 다른 유형의 자격 증명을 갖습니다. 서비스 주체는 키와 인증서의 두 가지 기본 자격 증명을 사용합니다.
참고
관리 ID는 Azure 내에서 작동하는 특수 서비스 주체입니다. 자격 증명은 다른 유형의 인증 프로세스를 가지고 있어 자격 증명을 알거나 처리할 필요가 전혀 없습니다.
구성
키는 암호와 유사합니다. 그러나 키가 훨씬 길고 더 복잡합니다. 실제로 대부분의 상황에서 Microsoft Entra ID는 다음을 보장하기 위해 자체적으로 키를 생성합니다.
- 키는 임의로 암호화됩니다. 즉, 추측하기가 매우 어렵습니다.
- 시림은 실수로 약한 암호를 키로 사용하지 않습니다.
서비스 주체는 높은 사용 권한을 가지는 경우가 많으므로 안전하게 보호하는 것이 필수적입니다. 일반적으로 서비스 주체와 파이프라인을 처음 구성할 때 키를 간단히 처리하기만 하면 됩니다. 따라서 키를 기억하거나 입력하기에 쉬울 필요가 없습니다.
단일 서비스 주체는 동시에 여러 키를 사용할 수 있지만 사용자는 여러 개의 암호를 가질 수 없습니다. 암호와 마찬가지로 키에는 만료 날짜가 있습니다. 곧 이에 대해 자세히 알아볼 것입니다.
참고
키를 스토리지 계정과 마찬가지로 매우 중요한 암호라고 생각하세요. 동일한 수준의 보안 및 주의를 기울여야 합니다.
인증서
인증서는 서비스 주체를 인증하는 또 다른 방법입니다. 매우 안전하지만 관리하기 어려울 수 있습니다. 일부 조직에서는 특정 유형의 서비스 주체에 대해 인증서를 사용해야 합니다.
이 모듈에서는 인증서에 대해 설명하지 않습니다. 그러나 인증서 인증을 사용하는 서비스 주체를 사용하는 경우에는 기본적으로 파이프라인 관리와 사용 권한 부여 측면에서 다른 서비스 주체와 동일한 방식으로 작동합니다.
참고
인증서는 사용할 수 있는 경우 좋은 옵션입니다. 공격자가 훔치기가 더 어렵습니다. 인증서를 사용하는 요청을 가로채고 수정하는 것 또한 어렵습니다. 그러나 인증서에는 더 많은 인프라가 필요하며 지속적으로 유지관리 오버헤드가 발생합니다.
서비스 주체에 대한 키로 작업하기
서비스 주체를 만들 경우, 일반적으로 동시에 키를 만들도록 Azure에 요청합니다. Azure는 일반적으로 임의 키를 생성합니다.
참고 항목
서비스 주체의 작동 방식에 대한 이전의 논의를 기억하십니까? 키는 애플리케이션 등록 개체의 일부로 저장됩니다. Azure Portal을 열고 Microsoft Entra 구성을 살펴본 다음 애플리케이션 등록으로 이동하면 거기에서도 키를 만들고 삭제할 수 있습니다.
Azure는 서비스 주체를 만들 때 키를 보여 줍니다. 이것이 Azure에서 키를 표시하는 유일한 시간입니다. 그 후에는 더 이상 검색할 수 없습니다. 파이프라인을 구성할 때 사용할 수 있도록 키를 안전하게 복사하는 것이 중요합니다. 이메일이나 다른 안전하지 않은 방법으로 키를 공유하지 마세요. 키를 분실한 경우 키를 삭제하고 새 키를 만들어야 합니다.
Azure Pipelines의 서비스 주체 관리
파이프라인의 서비스 주체에 대한 키를 만들 때 키를 파이프라인의 구성에 즉시 복사하는 것이 좋습니다. 이렇게 하면 키를 불필요하게 저장 하거나 전송하지 않아도 됩니다.
파이프라인 도구에는 서비스 주체의 애플리케이션 ID 및 키를 지정하는 안전한 방법이 포함되어 있습니다. 원본 제어에 모든 종류의 자격 증명을 절대로 저장하지 않습니다. Azure Pipelines로 작업할 때는 대신 서비스 연결을 사용합니다. 이 모듈에서는 서비스 주체 및 키를 만드는 방법에 대해서만 설명합니다. 키를 사용하여 파이프라인을 구성하는 방법은 이후 모듈에서 배우게 됩니다.
팁
Azure Pipelines는 자동으로 서비스 사용자를 만들 수 있습니다. 이 모듈에서는 서비스 주체를 수동으로 만들고 관리하여 무슨 일이 일어나고 있는지 더 잘 이해할 수 있습니다. 다른 모듈에서는 간편하게 자동 생성 방법을 사용합니다.
서비스 주체 및 키 만들기
Azure CLI를 사용하여 서비스 주체를 만들고 관리할 수 있습니다.
참고 항목
서비스 주체를 만들고 수정하려면 Microsoft Entra ID에 관련 권한이 있어야 합니다. 일부 조직에서는 관리자가 이러한 단계를 수행해야 할 수 있습니다.
서비스 주체 및 키를 만들려면 az ad sp create-for-rbac 명령을 사용합니다. 이 명령은 여러 인수를 허용하며 필요에 따라 서비스 주체에 역할을 할당할 수 있습니다. 이 모듈의 뒷부분에서 이 주체에 대해 더 자세히 알아봅니다. 지금은 Azure 역할 할당 없이 서비스 주체를 만드는 방법을 보여주는 예제를 확인하겠습니다.
az ad sp create-for-rbac --name MyPipeline
이 명령을 실행하면 Azure CLI는 password 속성을 사용하여 JSON 응답을 반환합니다. 이 속성은 서비스 주체의 키입니다. 이 키를 다시 가져올 수 없으므로, 즉시 사용하거나 안전하게 저장해야 합니다.
참고 항목
az ad sp create-for-rbac 명령은 Microsoft Entra ID에 애플리케이션 등록을 만들고, Microsoft Entra 테넌트에 서비스 주체를 추가하고, 애플리케이션 등록을 위한 키를 만듭니다. 또 다른 명령인 az ad sp create은(는) 애플리케이션 등록이 아닌 테넌트에 서비스 주체를 만듭니다. 파이프라인에 대한 서비스 주체를 만드는 경우 az ad sp create-for-rbac은(는) 일반적으로 사용하는 가장 좋은 명령입니다.
Azure PowerShell cmdlet을 사용하여 서비스 주체를 만들고 관리할 수 있습니다.
참고 항목
서비스 주체를 만들고 수정하려면 Microsoft Entra ID에 관련 권한이 있어야 합니다. 일부 조직에서는 관리자가 이러한 단계를 수행해야 할 수 있습니다.
서비스 주체 및 키를 만들려면 New-AzADServicePrincipal cmdlet을 사용합니다. 이 cmdlet은 여러 인수를 허용하며 필요에 따라 서비스 주체에 역할을 할당할 수 있습니다. 이 모듈의 뒷부분에서 이 주체에 대해 더 자세히 알아봅니다. 지금은 Azure 역할 할당 없이 서비스 주체를 만드는 방법을 보여주는 예제를 확인하겠습니다.
$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline
이 명령을 실행하면 Azure PowerShell은 키를 포함하여 서비스 주체에 관한 정보로 servicePrincipal 변수를 채웁니다.
$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText
이 키를 다시 가져올 수 없으므로 즉시 사용하거나 안전하게 저장해야 합니다.
참고 항목
New-AzADServicePrincipal cmdlet은 Microsoft Entra ID에 애플리케이션 등록을 만들고, Microsoft Entra 테넌트에 서비스 주체를 추가하고, 애플리케이션 등록을 위한 키를 만듭니다.
서비스 주체 식별
서비스 주체는 식별하고 사용하는 데 사용하는 여러 식별자와 이름을 가지고 있습니다. 가장 많이 사용하는 식별자는 다음과 같습니다.
- 애플리케이션 ID: 애플리케이션 등록에는 종종 애플리케이션 ID 또는 클라이언트 ID라고도 하는 고유 식별자가 있습니다. 일반적으로 서비스 주체가 Azure에 로그인 할 때 이를 사용자 이름으로 사용합니다.
- 개체 ID: 애플리케이션 등록 및 서비스 주체에는 Microsoft Entra ID에서 할당한 고유 식별자인 별도의 개체 ID가 있습니다. 서비스 주체를 관리할 때 이러한 개체 ID를 사용해야 하는 경우도 있습니다.
- 표시 이름: 서비스 주체를 설명하는 사람이 읽을 수 있는 이름입니다.
팁
서비스 주체에 대해 명확하고 설명이 포함된 표시 이름을 사용합니다. 사용자가 실수로 삭제하거나 사용 권한을 변경하지 않도록 팀이 서비스 주체의 역할을 이해하는 데 돕는 것이 중요합니다.
주의
표시 이름은 고유하지 않습니다. 여러 서비스 주체가 동일한 표시 이름을 공유할 수 있습니다. 서비스 주체를 식별하기 위해 표시 이름을 사용하여 사용 권한을 부여하는 경우 주의해야 합니다. 실수로 잘못된 서비스 주체에게 사용 권한을 부여할 수 있습니다. 애플리케이션 ID를 대신 사용하는 것이 좋습니다.
서비스 주체를 만들 때 일반적으로는 표시 이름만 설정합니다. Azure는 다른 이름과 식별자를 자동으로 할당합니다.
만료된 키 처리
서비스 주체는 만료되지 않지만 키는 만료됩니다. 키를 만들 때 만료 시간을 구성할 수 있습니다. 기본값으로 만료 시간은 1년으로 설정됩니다. 이 만료 시간이 지나면 키는 더 이상 작동하지 않으며 파이프라인은 Microsoft Entra ID에 로그인할 수 없습니다. 키를 정기적으로 갱신하거나 회전해야 합니다.
주의
키의 만료 시간을 길게 설정하고 싶을 수 있지만, 그렇게 해서는 안됩니다. 서비스 주체는 해당 자격 증명에 의해서만 보호됩니다. 공격자가 서비스 주체의 키를 획득하게 된다면 엄청난 피해를 일으킬 수 있습니다. 공격이 지속될 수 있는 기간을 최소화하는 가장 좋은 방법은 키를 정기적으로 변경하는 것입니다. 또한 키가 유출된 것으로 의심되는 경우 키를 삭제하고 다시 만들어야 합니다.
서비스 주체에 대한 키를 다시 설정 하려면 다음 예제와 같이 az ad sp 명령을 애플리케이션 ID와 함께 사용합니다.
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
명령을 사용하여 az ad sp credential deleteaz ad sp credential reset --append 두 단계로 서비스 주체의 키를 제거하고 다시 만들 수도 있습니다.
서비스 주체에 대한 키를 다시 설정 하려면 먼저 Remove-AzADServicePrincipalCredential cmdlet을 사용하여 기존 자격 증명을 제거합니다. 그런 다음 New-AzADServicePrincipalCredential cmdlet을 사용하여 새 자격 증명을 추가합니다. 이러한 cmdlet은 모두 서비스 주체의 개체 ID를 사용하여 식별합니다. cmdlet을 사용하기 전에 애플리케이션 ID에서이 ID를 가져와야 합니다.
$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id
Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText
팁
단일 서비스 주체는 여러 키를 사용할 수 있습니다. 이전 키가 여전히 유효할 동안 새 키를 사용하도록 애플리케이션을 안전하게 업데이트 한 후, 이전 키를 더 이상 사용하지 않는 경우 이를 삭제할 수 있습니다. 이 기술은 키 만료의 가동 중지 시간을 방지합니다.
서비스 주체의 수명 주기 관리
만드는 각 서비스 주체의 전체 수명 주기를 고려하는 것이 중요합니다. 파이프라인에 대한 서비스 주체를 빌드하는 경우 파이프라인이 결국 삭제 되거나 더 이상 사용되지 않는 경우에는 어떻게 되나요?
서비스 주체는 자동으로 제거되지 않으므로 이전 서비스 주체를 감사하고 제거해야 합니다. 이전 사용자 계정을 삭제하는 것과 동일한 이유로 이전 서비스 주체를 제거하는 것이 중요합니다. 공격자가 키에 액세스할 수 있기 때문입니다. 적극적으로 사용되지 않는 자격 증명은 사용하지 않는 것이 좋습니다.
사용자와 팀이 쉽게 액세스할 수 있는 장소에서 서비스 주체를 문서화하는 것이 좋습니다. 각 서비스 주체에 대해 다음의 정보를 포함해야 합니다.
- 이름 및 애플리케이션 ID를 비롯한 필수 식별 정보입니다.
- 서비스 주체의 목적
- 이 파일을 만들고, 해당 키를 관리하고, 문제가 있는 경우 이를 해결할 수 있는 사람
- 필요한 사용 권한 및 필요한 이유에 대한 명확한 근거
- 예상 수명
서비스 주체를 정기적으로 감사하여 계속 사용 중이고 할당된 사용 권한이 여전히 올바른지 확인해야 합니다.