다음을 통해 공유

.NET용 Azure ID 라이브러리를 사용한 인증 모범 사례

  • 아티클

이 문서에서는 Azure 서비스에 인증할 때 .NET 앱의 성능과 안정성을 최대화하는 데 도움이 되는 지침을 제공합니다. .NET용 Azure ID 라이브러리를 최대한 활용하려면 잠재적인 문제 및 완화 기술을 이해하는 것이 중요합니다.

프로덕션 환경에서 결정적 자격 증명 사용

DefaultAzureCredential Azure ID 라이브러리를 시작하는 가장 쉬운 방법이지만 이러한 편리성으로 인해 특정 장단점이 발생합니다. 특히 요청 인증에 성공하고 사용되는 체인의 특정 자격 증명은 미리 보장할 수 없습니다. 프로덕션 환경에서 이러한 예측 불가능성으로 인해 중요하고 때로는 미묘한 문제가 발생할 수 있습니다.

예를 들어 다음과 같은 가상의 이벤트 시퀀스를 고려합니다.

  1. 조직의 보안 팀은 모든 앱이 관리 ID를 사용하여 Azure 리소스에 인증하도록 의무화합니다.
  2. 몇 달 동안 Azure VM(Virtual Machine)에서 호스트되는 .NET 앱은 성공적으로 DefaultAzureCredential 사용하여 관리 ID를 통해 인증합니다.
  3. 개발자는 지원 팀에 알리지 않고 해당 VM에 Azure CLI를 설치하고 az login 명령을 실행하여 Azure에 인증합니다.
  4. Azure 환경에서 별도의 구성 변경으로 인해 원래 관리 ID를 통한 인증이 예기치 않게 자동으로 실패하기 시작합니다.
  5. DefaultAzureCredential 실패한 ManagedIdentityCredential 건너뛰고 사용 가능한 다음 자격 증명(AzureCliCredential)을 검색합니다.
  6. 애플리케이션은 관리 ID가 아닌 Azure CLI 자격 증명을 활용하기 시작하며, 이로 인해 실패하거나 예기치 않은 권한 상승 또는 감소가 발생할 수 있습니다.

프로덕션 앱에서 이러한 유형의 미묘한 문제 또는 무음 실패를 방지하려면 DefaultAzureCredential에서 다음 결정적 솔루션 중 하나로 강력히 전환하는 것을 고려하십시오.

  • ManagedIdentityCredential같은 특정 TokenCredential 구현입니다. 옵션은 파생 목록 참조하세요.
  • 단순화된 ChainedTokenCredential 구현으로, 이 구현은 앱이 실행되는 Azure 환경에 최적화되어 있습니다. ChainedTokenCredential 기본적으로 프로덕션용 ManagedIdentity 및 개발용 VisualStudioCredential 같은 허용 가능한 자격 증명 옵션의 특정 허용 목록을 만듭니다.

예를 들어 ASP.NET Core 프로젝트에서 다음 DefaultAzureCredential 구성을 고려합니다.

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    DefaultAzureCredential credential = new();
    clientBuilder.UseCredential(credential);
});

위의 코드를 필요한 자격 증명만 지정하는 ChainedTokenCredential 구현으로 바꿉니다.

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    clientBuilder.UseCredential(new ChainedTokenCredential(
        new ManagedIdentityCredential(clientId: userAssignedClientId),
        new VisualStudioCredential()));
});

이 예제에서는 ManagedIdentityCredential 프로덕션에서 자동으로 검색되고 VisualStudioCredential 로컬 개발 환경에서 작동합니다.

자격 증명 인스턴스 다시 사용

가능하면 자격 증명 인스턴스를 다시 사용하여 앱 복원력을 개선하고 Microsoft Entra ID에 발급된 액세스 토큰 요청 수를 줄입니다. 자격 증명을 다시 사용하면 기본 MSAL 종속성으로 관리되는 앱 토큰 캐시에서 토큰을 가져오려고 시도합니다. 자세한 내용은 Azure ID 클라이언트 라이브러리 토큰 캐싱을 참조하세요.

중요하다

자격 증명을 다시 사용 하지 않는 대용량 앱은 Microsoft Entra ID에서 HTTP 429 제한 응답이 발생할 수 있으며 이로 인해 앱이 중단될 수 있습니다.

권장되는 자격 증명 재사용 전략은 .NET 애플리케이션 유형에 따라 다릅니다.

Microsoft.Extensions.Azure UseCredential 메서드를 통해 자격 증명 재사용을 구현합니다. 예를 들어 UserAssignedClientId 환경 변수가 설정된 Azure App Service에서 호스트되는 ASP.NET Core 앱을 상상해 보십시오. .NET 구성 공급자는 환경 변수의 존재를 확인하며, ManagedIdentityCredential이 Key Vault 비밀과 Blob Storage 클라이언트를 인증하는 데 사용됩니다. 그렇지 않으면 연결된 개발 시간 자격 증명 시퀀스가 사용됩니다.

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(new Uri("<key-vault-url>"));
    clientBuilder.AddBlobServiceClient(new Uri("<blob-storage-url>"));

    string? clientId = builder.Configuration["UserAssignedClientId"];

    TokenCredential credential = clientId is not null
        ? new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId))
        : new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());

    clientBuilder.UseCredential(credential);
});

이 방법에 대한 자세한 내용은 Microsoft Entra ID 사용하여인증을 참조하세요.

토큰 수명 및 캐싱 논리가 필요한 시기 이해

Azure Core 의존하는 Azure SDK 클라이언트 라이브러리를컨텍스트 외부에서 Azure ID 라이브러리 자격 증명을 사용하는 경우 앱에서 토큰 수명 및 캐싱 동작을 관리하는 것이 사용자의 책임입니다.

토큰 새로 고침을 시도할 수 있는 시기에 대한 힌트를 소비자에게 제공하는 AccessTokenRefreshOn 속성은 Azure Core 라이브러리에 의존하는 Azure SDK 클라이언트 라이브러리에서 토큰을 새로 고치는 데 자동으로 사용됩니다. 토큰 캐싱 지원하는 Azure ID 라이브러리자격 증명을 직접 사용하는 경우 RefreshOn 시간이 발생할 때 기본 MSAL 캐시가 자동으로 자동으로 새로 고쳐집니다. 이 디자인을 통해 클라이언트 코드는 토큰이 필요할 때마다 GetToken 호출하고 새로 고침을 라이브러리에 위임할 수 있습니다.

필요한 경우에만 GetToken 호출하려면 RefreshOn 날짜를 확인하고 해당 시간 이후에 토큰을 미리 새로 고치려고 시도합니다. 특정 구현은 고객에게 달려 있습니다.

관리 ID 재시도 전략 이해

.NET용 Azure ID 라이브러리를 사용하면 ManagedIdentityCredential사용하여 관리 ID를 통해 인증할 수 있습니다. ManagedIdentityCredential 사용하는 방식은 적용된 재시도 전략에 영향을 줍니다. 다음을 통해 사용할 때:

  • DefaultAzureCredential초기 토큰 획득 시도가 실패하거나 짧은 기간 후에 시간이 초과될 때 재시도가 시도되지 않습니다. 효율적인 개발 내부 루프를 위해 "빠르게 실패"하도록 최적화되어 있으므로 복원력이 가장 낮은 옵션입니다.
  • ChainedTokenCredential 또는 ManagedIdentityCredential을 직접 사용하는 다른 방법:

    • 재시도 사이의 시간 간격은 0.8초에서 시작되며, 기본적으로 최대 5번의 재시도가 시도됩니다. 이 옵션은 복원력에 최적화되어 있지만 개발 내부 루프에서 원치 않는 지연이 발생할 수 있습니다.

    • 기본 다시 시도 설정을 변경하려면 ManagedIdentityCredentialOptionsRetry 속성을 사용합니다. 예를 들어 시작 간격이 0.5초인 최대 3회를 다시 시도합니다.

      ManagedIdentityCredentialOptions miCredentialOptions = new(
        ManagedIdentityId.FromUserAssignedClientId(clientId)
    )
    {
        Retry =
        {
            MaxRetries = 3,
            Delay = TimeSpan.FromSeconds(0.5),
        }
    };
    ChainedTokenCredential tokenChain = new(
        new ManagedIdentityCredential(miCredentialOptions),
        new VisualStudioCredential()
    );

재시도 정책 사용자 지정에 대한 자세한 내용은 사용자 지정 다시 시도 정책설정을 참조하세요.