Aracılığıyla paylaş

.NET için Azure Kimlik kitaplığı ile en iyi kimlik doğrulama yöntemleri

Bu makalede, Azure hizmetlerinde kimlik doğrulaması yaparken .NET uygulamalarınızın performansını ve güvenilirliğini en üst düzeye çıkarmanıza yardımcı olacak yönergeler sunulmaktadır. .NET için Azure Kimlik kitaplığından en iyi şekilde çıkmak için olası sorunları ve azaltma tekniklerini anlamak önemlidir.

Üretim ortamlarında belirleyici kimlik bilgilerini kullanma

DefaultAzureCredential, Azure Kimlik kitaplığını kullanmaya başlamanın en kolay yoludur, ancak bu kolaylık bazı dezavantajları da ortaya çıkartır. En önemlisi, zincirde başarıya ulaşacak ve istek kimlik doğrulaması için kullanılacak belirli kimlik bilgileri önceden garanti edilemez. Bir üretim ortamında, bu öngörülemezlik önemli ve bazen hafif sorunlara yol açabilir.

Örneğin, aşağıdaki varsayımsal olay dizisini göz önünde bulundurun:

  1. Bir kuruluşun güvenlik ekibi, azure kaynaklarında kimlik doğrulaması yapmak için tüm uygulamaların yönetilen kimlik kullanmasını zorunlu kiliyor.
  2. Aylar boyunca, Azure Sanal Makinesinde (VM) barındırılan bir .NET uygulaması yönetilen kimlik aracılığıyla kimlik doğrulaması yapmak için DefaultAzureCredential başarıyla kullanır.
  3. Destek ekibine haber vermeden, bir geliştirici Azure CLI'yi bu VM'ye yükler ve Azure'da kimlik doğrulaması yapmak için az login komutunu çalıştırır.
  4. Azure ortamındaki ayrı bir yapılandırma değişikliği nedeniyle, özgün yönetilen kimlik aracılığıyla kimlik doğrulaması beklenmedik bir şekilde sessizce başarısız olur.
  5. DefaultAzureCredential başarısız olan ManagedIdentityCredential'i atlar ve sonrasında bir sonraki kullanılabilir kimlik bilgisi olan AzureCliCredential'yi arar.
  6. Uygulama, başarısız olabilecek veya beklenmeyen yükseltme veya ayrıcalıkların azaltılmasına neden olabilecek yönetilen kimlik yerine Azure CLI kimlik bilgilerini kullanmayı başlatır.

Üretim uygulamalarındaki bu tür küçük sorunları veya sessiz hataları önlemek için DefaultAzureCredential'yi TokenCredential gibi belirli bir ManagedIdentityCredential uygulamasıyla değiştirin. Seçenekler için türetilmişlistesi bakın.

Örneğin, ASP.NET Core projesinde aşağıdaki yapılandırmayı göz önünde bulundurun. örneği DefaultAzureCredential örtük olarak oluşturulur ve tüm kayıtlı hizmet istemcileri için kullanılır:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));
});

Uygulamanın çalıştığı ortama göre bir kimlik bilgisi seçmek için yukarıdaki kodu değiştirin:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));

    TokenCredential credential;

    if (builder.Environment.IsProduction() || builder.Environment.IsStaging())
    {
        string? clientId = builder.Configuration["UserAssignedClientId"];
        credential = new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId));
    }
    else
    {
        // local development environment
        credential = new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());
    }

    clientBuilder.UseCredential(credential);
});

Bu örnekte yalnızca ManagedIdentityCredential üretimde kullanılır. Daha sonra yerel geliştirme ortamının kimlik doğrulama gereksinimleri, yan tümcesinde else tanımlanan kimlik bilgileri dizisi tarafından sağlanır.

Kimlik bilgisi örneklerini yeniden kullanma

Uygulama dayanıklılığını geliştirmek ve Microsoft Entra Id'ye verilen erişim belirteci isteklerinin sayısını azaltmak için mümkün olduğunda kimlik bilgileri örneklerini yeniden kullanın. Bir kimlik bilgisi yeniden kullanıldığında, MSAL bağımlılığı tarafından yönetilen uygulama belirteci önbelleğinden bir belirteç alınmaya çalışılır. Daha fazla bilgi için bkz. Azure Identity istemci kitaplığındaBelirteci önbelleğe alma.

Önemli

Kimlik bilgilerini yeniden kullanmayan büyük ölçekli bir uygulama, Microsoft Entra ID'den gelen HTTP 429 kısıtlama yanıtlarıyla karşılaşabilir ve bu durum, uygulama kesintilerine yol açabilir.

Önerilen kimlik bilgisi yeniden kullanma stratejisi .NET uygulama türüne göre farklılık gösterir.

Kimlik bilgisi yeniden kullanımını uygulamak için UseCredential yöntemini Microsoft.Extensions.Azure kullanın. Hem üretim hem de hazırlama ortamlarında Azure App Service'te barındırılan bir ASP.NET Core uygulaması düşünün. Ortam değişkeni ASPNETCORE_ENVIRONMENT, bu iki geliştirme dışı ortam arasında ayrım yapmak için ya Production ya da Staging olarak ayarlanır. Hem üretimde hem de test ortamında, Key Vault Gizli Anahtarları ve Blob Depolama istemcilerinin kimliğini doğrulamak için kullanıcı tarafından atanmış varyantı ManagedIdentityCredential kullanılır.

Uygulama, ASPNETCORE_ENVIRONMENTDevelopment olarak ayarlandığında yerel bir geliştirme makinesinde çalışıyorsa, bunun yerine bir zincirleme geliştirici aracı kimlik bilgileri dizisi kullanılır. Bu yaklaşım, ortama uygun kimlik bilgilerinin kullanılmasını sağlayarak güvenliği artırır ve kimlik bilgisi yönetimini basitleştirir.

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));

    TokenCredential credential;

    if (builder.Environment.IsProduction() || builder.Environment.IsStaging())
    {
        string? clientId = builder.Configuration["UserAssignedClientId"];
        credential = new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId));
    }
    else
    {
        // local development environment
        credential = new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());
    }

    clientBuilder.UseCredential(credential);
});

ASP.NET Core uygulamasında bu yaklaşım hakkında bilgi için bkz. Microsoft Entra Id kullanarak kimlik doğrulaması yapma.

Belirteç ömrü ve önbelleğe alma mantığının ne zaman gerekli olduğunu anlama

Azure Core üzerine bağımlı bir Azure SDK istemci kitaplığıbağlamı dışında bir Azure Kimlik kitaplığı kimlik doğrulama bilgisi kullanıyorsanız, bu durumda uygulamanızda belirteç ömrü ve önbelleğe alma davranışını yönetmek sizin sorumluluğunuzdadır.

RefreshOnüzerindeki AccessToken özelliği, tüketicilere belirteç yenilemenin ne zaman denenebileceği konusunda bir ipucu sağlar ve belirteci yenilemek için Azure Core kitaplığına bağımlı Olan Azure SDK istemci kitaplıkları tarafından otomatik olarak kullanılır. Azure Identity kitaplığındaki ,belirteç önbelleğe almayı destekleyen kimlik bilgilerini doğrudan kullanırken, temel MSAL önbelleği RefreshOn süresi geldiğinde otomatik olarak ve proaktif bir şekilde yenilenir. Bu tasarım, istemci kodunun her belirteç gerektiğinde GetToken çağırmasına ve yenilemeyi kitaplığa devretmesine olanak tanır.

Yalnızca gerektiğinde GetToken çağırmak için, RefreshOn tarihine dikkat edin ve bu tarihten sonra belirteci yenilemeye çalışın. Belirli bir uygulama müşteriye aittir.

Yönetilen kimlik yeniden deneme stratejisini anlama

.NET için Azure Kimlik kitaplığı, ManagedIdentityCredentialile yönetilen kimlik aracılığıyla kimlik doğrulaması yapmanıza olanak tanır. Kullandığınız ManagedIdentityCredential mod, uygulanan yeniden deneme stratejisini etkiler.

Hızlı Hata Algılama modu

  • Ne zaman kullanılır: Hızlı geri bildirim almak istediğiniz yerel geliştirme senaryoları için
  • Etkinleştirme: Aşağıdaki yollardan biriyle kullanın DefaultAzureCredential :
    • Ortam değişkeni ayarlanmadan AZURE_TOKEN_CREDENTIALS
    • AZURE_TOKEN_CREDENTIALS ortam değişkeni ManagedIdentityCredential dışında bir dizeye ayarlandığında
  • Nasıl çalışır: İlk belirteç alma girişimi başarısız olduğunda veya kısa sürede zaman aşımına uğradığında yeniden deneme yapılmaz. Bu, en az dayanıklı moddur çünkü verimli bir geliştirme iç döngüsü için "hızlı hataya uğrama" şeklinde optimize edilmiştir.

Dayanıklı mod

  • Ne zaman kullanılır: Dayanıklılığın önemli olduğu üretim senaryoları için

  • Etkinleştirme: Aşağıdaki yaklaşımlardan birini uygulayın:

    • Ortam değişkeni DefaultAzureCredentialAZURE_TOKEN_CREDENTIALS olarak ayarlandığında ManagedIdentityCredential kullanın.

      Önemli

      Bu DefaultAzureCredential yaklaşım yalnızca 1.16.0 veya sonraki bir paket sürümü kullanılırken Azure.Identity dayanıklı modda çalışır. Önceki sürümlerde, bu yaklaşım "erken hata verme" modunda çalışmaktadır.

    • İçeren ChainedTokenCredential kullanın ManagedIdentityCredential

    • ManagedIdentityCredential doğrudan kullan

  • Nasıl çalışır: Yeniden denemeler arasındaki zaman aralığı 0,8 saniyede başlar ve varsayılan olarak üstel geri alma ile en fazla beş yeniden deneme denenir. Bu mod dayanıklılık için iyileştirilmiştir ancak geliştirme iç döngüsünde istenmeyebilecek gecikmelere neden olur.

    Varsayılan yeniden deneme ayarlarını değiştirmek için Retry üzerinde DefaultAzureCredentialOptions veya ManagedIdentityCredentialOptions özelliğini kullanın. Örneğin, başlangıç aralığı 0,5 saniye olacak şekilde en fazla üç kez yeniden deneyin:

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

ManagedIdentityCredential miCredential = new(miCredentialOptions);

    Yeniden deneme ilkelerini özelleştirme hakkında daha fazla bilgi için bkz. Özel yeniden deneme ilkesi ayarlama.

  • Last updated on