다음을 통해 공유


Azure DevOps에서 서비스 주체 및 관리 ID 사용

Azure DevOps Services

서비스 주체 및 관리 ID는 Azure DevOps 자동화 워크플로에 대해 안전하고 확장 가능한 인증을 제공합니다. 이러한 Microsoft Entra ID 유형은 자동 자격 증명 관리, 짧은 토큰 수명 및 엔터프라이즈급 액세스 제어를 사용하여 기존의 PAT(개인용 액세스 토큰)보다 향상된 보안을 제공합니다.

서비스 주체 및 관리 ID의 이점

향상된 보안

  • 수명이 짧은 토큰: Microsoft Entra 토큰은 매시간 만료되어 PAT에 비해 노출 위험을 줄입니다(최대 1년까지 지속될 수 있습니다).
  • 자동 회전: 관리 ID가 자격 증명 회전을 자동으로 처리합니다.
  • 저장된 비밀 없음: 코드 또는 구성에 수명이 긴 자격 증명을 저장할 필요가 없습니다.

운영 우수성

  • 중앙 집중식 관리: Microsoft Entra ID 정책 및 Azure DevOps 권한을 통한 액세스 제어
  • 감사 기능: 포괄적인 로그 기록을 통해 인증 및 액세스 패턴을 추적합니다.
  • 효율적으로 크기 조정: 개별 사용자 종속성 없이 엔터프라이즈 자동화 시나리오 지원

최신 인증

  • 표준 기반: OAuth 2.0 및 OpenID Connect 프로토콜 사용
  • 다단계 인증 지원: 조직 보안 정책 상속
  • 조건부 액세스: 컨텍스트에 따라 고급 보안 정책 적용

서비스 주체 및 관리 ID 이해

서비스 프린시플

서비스 주체 는 테넌트 내의 애플리케이션을 나타내는 Microsoft Entra 개체입니다. 애플리케이션에서 수행할 수 있는 작업을 정의하고, 액세스할 수 있는 리소스와 애플리케이션을 사용할 수 있는 사용자를 정의합니다. 서비스 주체는 Microsoft Entra ID에 애플리케이션을 등록하고 애플리케이션이 리소스를 인증하고 액세스할 수 있는 안전한 방법을 제공할 때 자동으로 만들어집니다.

주요 특징:

  • Microsoft Entra ID에서 애플리케이션 등록을 통해 생성됨
  • 다중 테넌트 시나리오 지원
  • 명시적 자격 증명 관리 필요(인증서 또는 클라이언트 비밀)
  • 다양한 환경에서 인증해야 하는 애플리케이션에 적합합니다.

관리되는 아이덴티티

관리 ID 는 Azure에서 자동으로 관리하는 특별한 유형의 서비스 주체입니다. Azure 리소스에 대한 Microsoft Entra ID에 자동으로 관리 ID를 제공하여 개발자가 자격 증명을 관리할 필요가 없습니다.

관리 ID 유형:

시스템 할당 관리 ID

  • 특정 Azure 리소스를 자동으로 만들고 연결
  • Azure에서 관리하는 수명 주기(리소스가 삭제될 때 삭제됨)
  • Azure 리소스와의 일대일 관계
  • 단일 Azure 리소스에 배포된 애플리케이션에 가장 적합합니다.

사용자 할당 관리 ID

  • 독립 실행형 Azure 리소스로 만들기
  • 여러 Azure 리소스에 할당할 수 있습니다.
  • 연결된 리소스와 독립적으로 관리되는 수명 주기
  • 여러 리소스에서 실행되거나 공유 ID가 필요한 애플리케이션에 가장 적합합니다.

각 형식을 사용하는 경우:

  • 서비스 주체: 클라우드 간 배포, CI/CD 파이프라인, Azure 외부 애플리케이션
  • 시스템 할당 관리 ID: 단일 Azure 리소스 애플리케이션(Azure Functions, App Service)
  • 사용자 할당 관리 ID: 다중 리소스 애플리케이션, 공유 ID 시나리오

구현 가이드

다음 단계에 따라 Azure DevOps 인증에 대한 서비스 주체 또는 관리 ID를 구현합니다. 전체 코드 예제는 샘플 애플리케이션을 참조하세요.

1단계: ID 만들기

배포 시나리오에 따라 적절한 ID 유형을 선택합니다.

옵션 A: 서비스 주체 만들기(애플리케이션 등록)

서비스 주체는 CI/CD 파이프라인, 클라우드 간 시나리오 및 유연한 배포 옵션이 필요한 애플리케이션에 적합합니다.

  1. Microsoft Entra 관리 센터에서 애플리케이션 등록
  2. 앱 등록 새 등록으로> 이동합니다.
  3. 애플리케이션 구성:
    • 이름: 애플리케이션에 대한 설명이 포함된 이름
    • 계정 유형: 적절한 테넌트 지원 선택
    • 리디렉션 URI: 서비스 간 시나리오의 경우 비워 두세요.
  4. 인증 자격 증명 만들기:
    • 권장 사항: 향상된 보안을 위해 인증서 업로드
    • 대안: 클라이언트 암호 만들기(정기적인 회전 필요)

중요합니다

애플리케이션을 등록할 때 Azure는 애플리케이션 개체와 서비스 주체 개체를 모두 만듭니다. 애플리케이션의 개체 ID가 아닌 Azure DevOps에 추가할 때 서비스 주체의 개체 ID(엔터프라이즈 애플리케이션에 있는 경우)를 사용합니다.

자세한 내용은 다음 문서를 참조하세요.

옵션 B: 관리 ID 만들기

관리 ID는 Azure 호스팅 애플리케이션에 대한 가장 간단한 인증 환경을 제공합니다.

시스템 할당 관리 ID의 경우:

  1. Azure 리소스(App Service, 함수 앱 등)로 이동합니다.
  2. Identity>시스템 할당됨으로 이동합니다.
  3. 상태를 켜기로 전환 합니다.
  4. 구성을 저장합니다.

사용자 할당 관리 ID의 경우:

  1. Azure Portal에서 관리 ID를 만듭니다.
  2. 리소스 만들기>관리형 ID로 이동합니다.
  3. 기본 설정을 구성하고 리소스를 만듭니다.
  4. 필요에 따라 리소스에 할당합니다.

자세한 내용은 다음 문서를 참조하세요.

2단계: Azure DevOps에 ID 추가

Microsoft Entra ID에서 ID를 만든 후 Azure DevOps 조직에 추가하여 리소스에 대한 액세스 권한을 부여합니다.

사전 요구 사항:

  • PCA(프로젝트 컬렉션 관리자) 역할 또는
  • 초대 정책에서 관리자가 사용자를 추가할 수 있는 경우 프로젝트 관리자 또는 팀 관리자 역할

Azure DevOps 포털을 통해 추가합니다.

  1. 조직 설정>사용자로 이동합니다.
  2. 사용자 추가를 선택합니다.
  3. 서비스 주체 또는 관리 ID의 표시 이름을 입력합니다.
  4. 적절한 액세스 수준 및 프로젝트 액세스를 선택합니다.
  5. 초대를 보냅니다.

프로그래밍 방식으로 추가:ServicePrincipalEntitlements REST API 를 사용하여 프로세스를 자동화합니다.

올바른 ID 찾기: 애플리케이션 등록의 개체 ID가 아닌 Microsoft Entra 관리 센터의 엔터프라이즈 애플리케이션 페이지에서 서비스 주체의 개체 ID를 사용합니다.

사용자 허브의 서비스 주체 및 관리 ID 스크린샷

참고

테넌트 제한 사항: Azure DevOps 조직이 연결된 동일한 테넌트에서만 ID를 추가할 수 있습니다. 테넌트 간 시나리오는 FAQ 해결 방법을 참조하세요.

3단계: 권한 구성

Azure DevOps 내에서 서비스 주체 또는 관리 ID에 대한 세부적인 권한을 구성합니다. 다른 Azure 서비스와 달리 Azure DevOps는 Microsoft Entra 애플리케이션 권한 대신 자체 권한 모델을 사용합니다.

사용 권한 옵션:

  • 직접 할당: ID에 직접 권한 할당
  • 그룹 멤버 자격: Azure DevOps 또는 Microsoft Entra 보안 그룹에 추가
  • 액세스 수준: 적절한 라이선스 수준 할당(기본, 기본 + 테스트 계획, Visual Studio 구독자)

모범 사례:

  • 최소 권한 적용: 필요한 최소 권한만 부여
  • 그룹 사용: 더 쉬운 유지 관리를 위해 그룹을 통해 사용 권한 관리
  • 정기 검토: 주기적으로 권한 점검

권한 관리 옵션:

중요합니다

Azure DevOps 및 Microsoft Entra 권한: Azure DevOps는 Microsoft Entra ID 애플리케이션 권한을 사용하지 않습니다. 모든 액세스 제어는 Azure DevOps의 자체 권한 시스템을 통해 관리되므로 세분화된 프로젝트 및 리소스 수준 권한을 허용합니다.

4단계: Microsoft Entra ID 토큰 가져오기

Azure DevOps API 및 서비스를 사용하여 애플리케이션을 인증하는 액세스 토큰을 가져옵니다.

서비스 주체의 경우

클라이언트 자격 증명 흐름 사용:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://app.vssps.visualstudio.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

인증서 인증 사용(권장):

using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithCertificate(certificate)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var result = await app
    .AcquireTokenForClient(new[] { "https://app.vssps.visualstudio.com/.default" })
    .ExecuteAsync();

string accessToken = result.AccessToken;

관리 ID의 경우

Azure 리소스에서:

using Azure.Identity;
using Azure.Core;

var credential = new ManagedIdentityCredential();
var tokenRequest = new TokenRequestContext(new[] { "https://app.vssps.visualstudio.com/.default" });
var token = await credential.GetTokenAsync(tokenRequest);

string accessToken = token.Token;

AZURE IMDS(Instance Metadata Service) 사용:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://app.vssps.visualstudio.com/
Metadata: true

임시 작업을 위한 Azure CLI

일회성 작업 또는 테스트의 경우 Azure CLI를 사용합니다.

# For service principal
az login --service-principal --username {client-id} --password {client-secret} --tenant {tenant-id}
az account get-access-token --resource https://app.vssps.visualstudio.com/

# For managed identity (from Azure resource)
az login --identity
az account get-access-token --resource https://app.vssps.visualstudio.com/

자세한 지침은 Microsoft Entra 토큰 획득을 참조하세요.

5단계: Azure DevOps에서 토큰 사용

획득한 토큰을 사용하여 REST API 호출 및 기타 Azure DevOps 작업을 인증합니다.

인증된 API 호출 만들기:

using System.Net.Http;
using System.Net.Http.Headers;

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", accessToken);

var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.1");

비디오 예제:

일반적인 통합 시나리오:

전체 코드 예제는 샘플 애플리케이션을 참조하세요.

관리 고려 사항

서비스 주체 및 관리 ID는 사용자 계정에 비해 관리 특성이 다릅니다.

라이센스:

  • 각 ID에는 조인하는 모든 조직에서 라이선스가 필요합니다.
  • 다중 조직 청구는 서비스 주체에 적용되지 않습니다.
  • 그룹 기반 라이선스 규칙이 자동으로 적용되지 않음 - 라이선스를 직접 할당

ID 관리:

  • 전자 메일 주소 없음 - 전자 메일을 통해 초대할 수 없음
  • Azure DevOps에서 표시 이름 또는 아바타를 수정할 수 없습니다.
  • 표시 이름은 Microsoft Entra ID에서 상속됩니다.

그룹 멤버 자격:

  • Microsoft Entra 그룹 및 Azure DevOps 그룹에 추가할 수 있습니다.
  • 기술 제한으로 인해 Microsoft Entra 그룹 구성원 목록에 표시할 수 없습니다(UI 제한에만 해당).
  • 여전히 속해 있는 Microsoft Entra 그룹에서 사용 권한을 계속 상속합니다.

구체화:

  • 조직에 명시적으로 추가되어야 하며, 사용자와 달리 자동으로 구현되지 않습니다.
  • 서비스 주체가 대화형으로 로그인할 수 없으므로 필수

사용자 계정의 주요 차이점

서비스 주체 및 관리 ID에는 일반 사용자에 비해 특정 제한 사항이 있습니다.

기능:

  • ✅ API 액세스를 위한 Microsoft Entra 토큰 생성
  • ✅ 적절한 권한으로 Azure DevOps 리소스에 액세스
  • ✅ 보안 그룹 및 팀 가입
  • ❌ 개인용 액세스 토큰(PAT) 또는 SSH 키 만들기
  • ❌ 대화형으로 로그인하거나 웹 UI에 액세스
  • ❌ 조직 만들기 또는 소유
  • Azure DevOps OAuth 흐름 지원

과금:

  • 각 조직에서 별도의 라이선스로 계산됨(다중 조직 할인 없음)
  • 액세스 수준을 직접 할당해야 함(그룹 규칙이 자동으로 적용되지 않음)

자주 묻는 질문

Q: PAT 대신 서비스 주체 또는 관리 ID를 사용해야 하는 이유는 무엇인가요?

A: 서비스 주체 및 관리 ID는 개인용 액세스 토큰에 비해 상당한 보안 이점을 제공합니다.

보안 이점:

  • 수명 단축: Microsoft Entra 토큰은 매시간 만료되며, PAT는 최대 1년 동안 지속될 수 있습니다.
  • 자동 회전: 관리 ID가 자격 증명을 자동으로 회전합니다.
  • 공유 비밀 없음: 수명이 긴 토큰을 저장하거나 실수로 노출할 위험을 제거합니다.
  • 중앙 집중식 제어: 엔터프라이즈 보안 정책을 사용하여 Microsoft Entra ID를 통해 관리

운영상의 이점:

  • 감사 추적: 인증 및 액세스 패턴의 완전한 로깅
  • 조건부 액세스: 위치, 디바이스 및 위험 요소에 따라 정책 적용
  • 서비스 계정 없음: 자동화를 위한 개별 사용자 계정에 대한 종속성을 제거합니다.

마이그레이션 예제는 PAT를 Microsoft Entra 토큰으로 바꾸기를 참조하세요.

Q: 서비스 주체 및 관리 ID에 대한 속도 제한은 무엇인가요?

A: 서비스 주체 및 관리 ID는 사용자와 동일한 속도 제한을.

Q: 이 기능을 사용하는 데 더 많은 비용이 들까요?

A: 서비스 주체 및 관리 ID는 액세스 수준에 따라 사용자와 같은 가격이 책정됩니다. 주요 차이점:

  • 다중 조직 청구 할인 없음: 각 ID는 모든 조직에서 별도의 라이선스로 계산됩니다.
  • 라이선스 할당: 액세스 수준을 직접 할당해야 함(그룹 규칙이 자동으로 적용되지 않음)
  • 동일한 가격 책정 계층: 기본, 기본 + 테스트 계획, Visual Studio 구독자 요금이 적용됩니다.

Q: 다른 테넌트에서 내 조직에 관리 ID를 추가할 수 있나요?

A: 조직의 연결된 테넌트에서만 ID를 직접 추가할 수 있습니다. 테넌트 간 시나리오의 경우 다음 해결 방법을 사용합니다.

테넌트 간 관리 ID 설정:

  1. 리소스 테넌트에서 사용자 할당 관리 ID 만들기
  2. Azure 리소스에 할당(VM, 함수 앱 등)
  3. Key Vault** 만들기 및 인증서 생성(PEM이 아닌 형식)
  4. Key Vault에 관리 ID 액세스 권한을 부여하고 비밀 정보 가져오기/나열 권한을 설정합니다.
  5. CER 형식으로 인증서 다운로드(공개 키만 해당)
  6. 대상 테넌트에 애플리케이션 등록
  7. 애플리케이션 등록에 인증서 업로드
  8. Azure DevOps 조직에 서비스 주체 추가
  9. Key Vault에서 인증서를 사용하여 인증 구성
// Example: Acquire token using managed identity certificate
public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
    var keyVaultUri = new Uri($"https://{keyVaultName}.vault.azure.net");
    var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
    var keyVaultSecret = await client.GetSecretAsync(secretName);
    return keyVaultSecret.Value.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(
    string applicationClientID, string appTenantId)
{
    byte[] privateKeyBytes = Convert.FromBase64String(await GetSecret(keyVaultName, secretName));
    var certificate = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

    var app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
        .WithCertificate(certificate)
        .WithAuthority(new Uri($"https://login.microsoftonline.com/{appTenantId}"))
        .Build();

    var result = await app.AcquireTokenForClient(
        new[] { "499b84ac-1321-427f-aa17-267ca6975798/.default" })
        .ExecuteAsync();

    return result;
}

중요합니다

보안 모범 사례를 위해 인증서를 정기적으로 회전합니다.

일반 오류 및 해결 방법

이름 또는 식별자가 있는 Git 리포지토리가 없거나 권한이 없습니다.

해결책: 서비스 프린시펄에 적어도 기본 라이선스가 있는지 확인합니다. 관련자 라이선스는 리포지토리 액세스를 제공하지 않습니다.

개체 ID를 사용하여 서비스 주체를 만들지 못했습니다.

해결책: 애플리케이션 등록의 개체 ID가 아닌 엔터프라이즈 애플리케이션에서 서비스 주체의 개체 ID를 사용하고 있는지 확인합니다.

올바른 ID를 찾습니다.

  1. Microsoft Entra 관리 센터 > 엔터프라이즈 애플리케이션으로 이동
  2. 애플리케이션 이름 검색
  3. 엔터프라이즈 애플리케이션 페이지의 개체 ID 사용

액세스 거부: 사용자 추가 권한 필요

가능한 원인 및 해결 방법:

  • 역할 부족: 초대 권한이 설정된 프로젝트 컬렉션 관리자 또는 프로젝트/팀 관리자여야 합니다.
  • 정책 제한: "팀 및 프로젝트 관리자가 새 사용자를 초대하도록 허용" 정책이 사용하도록 설정되어 있는지 확인합니다.
  • 라이선스 할당: 프로젝트 관리자는 초대 중에 라이선스를 할당할 수 없습니다. 라이선스 변경은 PCA에 문의하세요.

Azure DevOps Graphs 목록 API는 빈 목록을 반환합니다.

해결책:continuationToken를 사용하여 모든 페이지를 반복합니다. 서비스 주체는 API 페이지 매김 동작으로 인해 이후 페이지에 나타날 수 있습니다.

TF401444: 로그인 필요 오류

솔루션: 서비스 주체가 필요한 권한과 함께 조직에 올바르게 추가되었는지 확인합니다. 이 오류는 조직에서 ID가 인식되지 않음을 나타냅니다.