Bölüm 2: Bu örnek senaryoda kimlik doğrulaması gereksinimleri

Önceki bölüm: Giriş ve arka plan

Bu örnek senaryoda, ana uygulamanın üç ayrı kimlik doğrulaması gereksinimi vardır:

• Azure Key Vault

  Uygulamanın üçüncü taraf hizmeti çağırmak için gereken güvenli bir şekilde depolanan API anahtarını almak için Azure Key Vault ile kimlik doğrulaması yapması gerekir.

• Üçüncü taraf API

  Uygulama API anahtarını aldıktan sonra, dış üçüncü taraf API'siyle kimlik doğrulaması yapmak için anahtarını kullanır.

• Azure Kuyruk Depolama Hizmeti

  İstek işlendikten sonra uygulamanın zaman uyumsuz veya ertelenmiş işleme için bir iletiyi kuyruğa almak için Azure Kuyruk Depolama ile kimlik doğrulaması yapması gerekir.

Bu görevler, uygulamanın üç kimlik bilgisi kümesini yönetmesini gerektirir:

• Azure kaynakları için iki küme (Key Vault ve Depolama)

• Dış hizmet için bir küme (üçüncü taraf API)

Önemli kimlik doğrulama zorlukları

Güvenli bulut uygulamaları oluşturmak, özellikle birden çok hizmet söz konusu olduğunda kimlik bilgilerinin dikkatli bir şekilde işlenmesini gerektirir. Bu örnek senaryo birkaç kritik zorluk sunar:

• Key Vault'a döngüsel bağımlılık

  Uygulama, üçüncü taraf API anahtarları veya Azure Depolama kimlik bilgileri gibi gizli dizileri güvenli bir şekilde depolamak için Azure Key Vault kullanır. Ancak bu gizli bilgileri almak için uygulamanın önce Key Vault ile kimlik doğrulaması yapması gerekir. Bu durum döngüsel bir sorun oluşturur: Uygulamanın Key Vault erişmek için kimlik bilgilerine ihtiyacı vardır, ancak bu kimlik bilgilerini güvenli bir şekilde depolamanız gerekir. Güvenli bir çözüm olmadan bu sorun, geliştirme ortamlarında sabit kodlanmış kimlik bilgilerine veya güvenli olmayan yapılandırmalara yol açabilir.

• Üçüncü taraf API anahtarlarının güvenli işlenmesi

  Key Vault'tan API anahtarını aldıktan sonra, uygulamanın dış bir üçüncü taraf hizmeti çağırmak için bu anahtarı kullanması gerekir. Bu anahtarı son derece dikkatli kullanın:

  • Bunu kaynak kodunda veya yapılandırma dosyalarında asla sabit olarak tanımlamayın.
  • Hiçbir zaman stdout, stderr veya uygulama günlüklerine kaydetmeyin
  • Yalnızca bellekte tutun ve ona, kullanmadan hemen önce, çalışma zamanında erişin
  • İstek tamamlandıktan hemen sonra onu imha et

  Bu uygulamaların izlenememesi, kimlik bilgisi sızıntısı veya yetkisiz kullanım riskini artırır.

• Azure Kuyruk Depolama kimlik bilgilerinin güvenliğini sağlama

  Azure Kuyruk Depolama'ya ileti yazmak için uygulamanın genellikle bir bağlantı dizesine veya paylaşılan erişim belirtecine ihtiyacı vardır. Bu kimlik bilgileri:

  • Key Vault gibi güvenli bir konumda depolanmalıdır
  • Günlüklerde, yığın izlemelerinde veya geliştirici araçlarında görünmemelidir
  • Yalnızca güvenli çalışma zamanı mekanizmaları aracılığıyla erişilmelidir
  • Uygun RBAC yapılandırması, yönetilen kimlik kullanıldığında gereklidir.

• Ortam esnekliği

  Uygulamanın hem yerel geliştirme hem de bulut üretim ortamlarında aynı kod tabanını ve en düşük koşullu mantığı kullanarak güvenilir bir şekilde çalışması gerekir.

  Bu gereksinim şu anlama gelir:

  • Ortama özgü gizli dizileri koda eklemeyin
  • Kimlik bilgilerini veya mantık akışlarını manuel olarak açıp kapatmayın
  • Ortamlar arasında kimlik tabanlı kimlik doğrulamayı tutarlı bir şekilde kullanma

Microsoft Entra ID ile ilk Azure kimlik doğrulaması

Bulut uygulamalarının karmaşıklığı ölçeklendirildikçe ve daha fazla hizmetle tümleştirildikçe güvenli ve kolaylaştırılmış kimlik doğrulaması gerekli hale gelir. Azure, Microsoft Entra ID aracılığıyla Azure öncelikli bir kimlik modeli sunarak güvenli, kimlik bilgisiz kimlik doğrulaması için birleştirilmiş kimlik yönetimine ve Azure hizmetleriyle sorunsuz tümleştirmeye olanak tanır.

Gizli dizileri el ile yönetmek veya kimlik bilgilerini uygulama koduna eklemek (güvenlik risklerine eğilimli bir uygulama) yerine Microsoft Entra ID uygulamaların yönetilen kimlikleri kullanarak güvenli bir şekilde kimlik doğrulaması yapmalarını sağlar.

Microsoft Entra yönetilen kimliklerinin başlıca avantajları şunlardır:

• Kodda sır yok

  Uygulamalar artık sabit kodlanmış bağlantı dizeleri, istemci gizli dizileri veya anahtarlar gerektirmez.

• Uygulamalar için yerleşik kimlik

  Azure, uygulamanıza otomatik olarak yönetilen kimlik atayarak ek kimlik bilgileri olmadan Key Vault, Depolama ve SQL gibi hizmetlere güvenli bir şekilde erişebilmesini sağlayabilir.

• Ortam tutarlılığı

  Aynı kod ve kimlik modeli, Azure SDK kullanarak hem yerel geliştirme hem de Azure DefaultAzureCredentialbarındırılan ortamlarda çalışır.

Çevreye özgü kimlik akışı

Kimlik doğrulaması için Microsoft Entra Id kullanan uygulamalar, hem Azure tarafından barındırılan hem de yerel geliştirme ortamlarında sorunsuz çalışan esnek bir kimlik modelinden yararlanır. Azure SDK DefaultAzureCredential ortamı temel alan uygun kimlik yöntemini otomatik olarak seçerek bu tutarlılığı sağlar.

Azure ortamı

Uygulamayı Azure dağıttığınızda:

• Uygulama otomatik olarak yönetilen bir kimlik alır.
• Azure, belirteçlerin verilmesini ve kimlik bilgilerinin yaşam döngüsünü kendi içinde yönetir; bu nedenle herhangi bir gizli bilgiyi işlemeniz gerekmez.
• Uygulama, Role-Based Access Control (RBAC) veya Key Vault erişim ilkelerini kullanarak hizmetlere erişir.

Yerel geliştirme ortamı

Yerel geliştirme sırasında:

• Hizmet sorumlusu, uygulamanın kimliği olarak görev alır.
• Geliştiriciler Azure CLI (az login ), ortam değişkenlerini veya Visual Studio/VS Code tümleştirmelerini kullanarak kimlik doğrulaması yapar.
• Aynı uygulama kodu herhangi bir değişiklik yapmadan çalışır. Yalnızca kimlik kaynağı değişir.

Her iki ortamda da Azure SDK’leri, kimlik kaynağını soyutlayan ve doğru yöntemi otomatik olarak seçen DefaultAzureCredential öğesini kullanır.

Güvenli geliştirme için en iyi yöntemler

Gizli dizileri ortam değişkenleri olarak ayarlayabilirsiniz (örneğin, Azure Uygulaması Ayarları aracılığıyla), bu yaklaşımın dezavantajları vardır:

• Gizli bilgileri yerel ortamlarda manüel olarak çoğaltmanız gerekir.
• Gizli bilgilerin sürüm kontrolüne sızma riski vardır.
• Ortamlar arasında ayrım yapmak için ek mantığa ihtiyacınız olabilir.

Bunun yerine aşağıdaki yaklaşımı kullanın:

• Üçüncü taraf API anahtarlarını ve diğer gizli dizileri depolamak için Key Vault'ı kullanın.
• Dağıtılan uygulamanıza yönetilen kimlik atayın.
• Yerel geliştirme için bir hizmet sorumlusu kullanın ve aynı erişim haklarını atayın.
• Kimlik doğrulama mantığını soyutlama amacıyla kodunuzda kullanın DefaultAzureCredential .
• Kimlik bilgilerini depolamaktan veya günlüğe kaydetmekten kaçının.

Uygulamada kimlik doğrulama akışı

Kimlik doğrulaması çalışma zamanında şu şekilde çalışır:

• Kodunuz bir DefaultAzureCredential örnek oluşturur.
• İstemci örneği oluşturmak için bu kimlik bilgilerini kullanırsınız (örneğin, , SecretClientQueueServiceClient).
• Uygulama bir yöntem çağırdığında (örneğin, get_secret()), istemci isteğin kimliğini doğrulamak için kimlik bilgilerini kullanır.
• Azure, kimliği doğrular ve işlemin gerçekleştirilmesi için doğru role veya ilkeye sahip olup olmadığını denetler.

Bu akış, uygulamanızın kod veya yapılandırma dosyalarına gizli dizi eklemeden Azure hizmetlerine güvenli bir şekilde erişebilmesini sağlar. Ayrıca, kimlik doğrulama mantığınızı değiştirmeden yerel geliştirme ve bulut dağıtımı arasında sorunsuz geçiş yapmanıza da olanak tanır.