Aracılığıyla paylaş

Otomasyon senaryolarında çok faktörlü kimlik doğrulamasının Azure CLI üzerindeki etkisi

Bu makalede, çok faktörlü kimlik doğrulamasının (MFA) Microsoft Entra kullanıcı kimliklerini kullanan otomasyon görevlerini nasıl etkilediği açıklanır ve kesintisiz otomasyon için alternatif yaklaşımlar hakkında rehberlik sağlanır.

Önemli

Otomasyon için Microsoft Entra kullanıcı kimliklerini kullanıyorsanız eylem gereklidir. MFA gereksinimleri, otomasyon senaryolarında kimlik doğrulaması için Microsoft Entra kullanıcı kimliklerini kullanmanızı engeller. Kuruluşlar, etkileşimli olmayan otomasyon kullanım örneklerini destekleyen yönetilen kimlikler veya hizmet sorumluları gibi otomasyon için tasarlanmış kimlik doğrulama yöntemlerine geçmelidir.

Otomasyonda MFA ile kullanıcı kimliklerinin sınırlamaları

Uyarı

Şu hata iletisiyle karşılaşabilirsiniz: Otomasyon ile kullanıcı kimliği kullanılırken etkileşimli kimlik doğrulaması gerekiyor .

  • Etkileşimli kimlik doğrulaması: MFA, Microsoft Entra kullanıcı kimliği kullanılırken etkileşimli oturum açma işlemleri sırasında tetikleniyor. Kullanıcı kimliğine dayanan otomasyon betikleri için MFA, ek doğrulama adımları gerektirdiğinden süreci kesintiye uğratır. Örneğin, otomatikleştirememenizi sağlayan kimlik doğrulayıcı uygulaması, telefon araması vb. Bu doğrulama, kimlik doğrulaması, yönetilen kimlik veya hizmet ilkesi gibi etkileşim gerektirmeyen bir şekilde işlenmediği sürece otomasyonun çalışmasını engeller.

  • Betikli oturum açma hataları: Azure CLI betiklerini katılımsız çalıştırma gibi otomasyon senaryolarında, MFA özellikli bir kullanıcı kimliği kimlik doğrulaması yapmaya çalışırken betiğin başarısız olmasına neden olur. MFA kullanıcı etkileşimi gerektirdiğinden, etkileşimli olmayan betiklerle uyumlu değildir. Bu, her ikisi de etkileşimli olmayan kimlik doğrulaması kullanan yönetilen bir kimliğe veya hizmet sorumlusuna geçmeniz gerektiği anlamına gelir.

  • Güvenlikle ilgili dikkat edilmesi gerekenler: MFA ek bir güvenlik katmanı eklese de, özellikle otomasyonun el ile müdahale edilmeden çalışması gereken üretim ortamlarında otomasyon esnekliğini sınırlayabilir. Otomasyon amacıyla tasarlanmış ve MFA gerektirmeyen yönetilen kimliklere, hizmet sorumlularına veya federasyon kimliklerine geçiş yapmak, bu tür ortamlarda daha pratik ve güvenlidir.

Güncelleştirme gerektiren senaryolar

Aşağıdaki listede, müşterilerin Azure CLI ile otomasyon için Microsoft Entra kullanıcı kimliğini kullanabilecekleri örnek senaryolar verilmiştir. Bu liste tüm senaryolar için kapsamlı değildir.

Uyarı

Microsoft Entra kullanıcı kimliği kullanan tüm otomasyon senaryolarının güncelleştirilmesi gerekir.

  • Kişiselleştirilmiş veya belirli izinler: Bir kişinin rolüne bağlı eylemler veya belirli Microsoft Entra ID öznitelikleri gibi kullanıcıya özgü izinler gerektiren otomasyon görevleri.

  • OAuth 2.0 ROPC akışı: OAuth 2.0 Kaynak Sahibi Parola Kimlik Bilgileri (ROPC) belirteci verme akışı MFA ile uyumsuz. Kimlik doğrulaması için ROPC kullanan otomasyon senaryoları, MFA gerektiğinde başarısız olur çünkü MFA etkileşimli olmayan bir akışta tamamlanamaz.

  • Azure dışındaki kaynaklara erişim: Microsoft 365 kaynaklarına erişim gerektiren otomasyon senaryoları. Örneğin, SharePoint, Exchange veya tek bir kullanıcının Microsoft hesabına bağlı diğer bulut hizmetleri.

  • Active Directory'den Microsoft Entra ID'ye eşitlenen hizmet hesapları: Active Directory'den (AD) Microsoft Entra ID'ye eşitlenen hizmet hesaplarını kullanan kuruluşlar. Bu hesapların da MFA gereksinimlerine tabi olduğunu ve diğer kullanıcı kimlikleri ile aynı sorunları tetiklediğini unutmayın.

  • Denetim veya uyumluluk için kullanıcı bağlamı: Uyumluluk nedeniyle eylemlerin tek bir kullanıcı düzeyinde denetlenebilir olması gereken durumlar.

  • Küçük ölçekli veya düşük riskli otomasyon için basit yapılandırma: Küçük ölçekli veya düşük riskli otomasyon görevleri için. Örneğin, birkaç kaynağı yöneten bir komut dosyası.

  • Üretim dışı ortamlarda kullanıcı odaklı otomasyon: Otomasyon, tek bir kullanıcının bir görevden sorumlu olduğu kişisel veya üretim dışı ortamlara yönelikse.

  • Kullanıcının kendi Azure aboneliği içinde otomasyon: Kullanıcının kendi Azure aboneliğinde, kullanıcının zaten yeterli izinlere sahip olduğu görevleri otomatikleştirmesi gerekiyorsa.

Microsoft Entra kullanıcı kimlikleri için zorunlu MFA uygulaması nedeniyle otomasyon senaryolarında yönetilen kimliğe veya hizmet ilkesine geçiş yapmak gerekir.

Nasıl başlar?

Azure CLI betiklerinizi Microsoft Entra ID insan kullanıcı hesabı ve parolası ile az login kullanmaktan geçirmek için şu adımları izleyin:

  1. Hangi iş yükü kimliğinin sizin için en uygun olduğunu belirleyin.

    • Servis Principal
    • İdare edilen kimlik
    • Federasyon kimliği

  2. Yeni bir iş yükü kimliği oluşturmak için gerekli izinleri alın veya yardım için Azure yöneticinize başvurun.

  3. İş yükü kimliğini oluşturun.

  4. Yeni kimliğe roller atayın. Azure rol atamaları hakkında daha fazla bilgi için bkz. Azure rolü atama adımları. Azure CLI kullanarak rol atamak için bkz. Azure CLI kullanarak Azure rolleri atama .

  5. Hizmet sorumlusu veya yönetilen kimlikle oturum açmak için Azure CLI betiklerinizi güncelleştirin.

Hizmet ilkesi anahtar kavramları

  • Birden çok Azure kaynağına erişebilen insan dışı bir kimlik. Hizmet sorumlusu birçok Azure kaynağı tarafından kullanılır ve tek bir Azure kaynağına bağlı değildir.
  • Bir hizmet sorumlusunun özelliklerini ve kimlik bilgilerini gerektiği gibi değiştirebilirsiniz.
  • Farklı aboneliklerde birden çok Azure kaynağına erişmesi gereken uygulamalar için idealdir.
  • Yönetilen kimliklerden daha esnek ancak daha az güvenli olarak kabul edilir.
  • Genellikle bir Azure kiracısında veya Microsoft Entra Id dizininde "uygulama nesnesi" olarak adlandırılır.

Hizmet sorumluları hakkında daha fazla bilgi edinmek için bkz:

Azure CLI ve hizmet sorumlusu kullanarak Azure'da oturum açmayı öğrenmek için bkz. Azure CLI kullanarak hizmet sorumlusuyla Azure'da oturum açma

Yönetilen kimlik anahtarı kavramları

  • Tek bir kaynağın diğer Azure uygulamalarına erişmesine olanak sağlayan belirli bir Azure kaynağına bağlıdır.
  • Kimlik bilgileri size görünmez. Azure gizli dizileri, kimlik bilgilerini, sertifikaları ve anahtarları işler.
  • Tek bir abonelik içindeki diğer Azure kaynaklarına erişmesi gereken Azure kaynakları için idealdir.
  • Hizmet sorumlularından daha az esnek ancak daha güvenli olarak kabul edilir.
  • İki tür yönetilen kimlik vardır:
    • Sistem tarafından atanan: Bu tür, iki Azure kaynağı arasındaki 1:1 (bire bir) erişim bağlantısıdır.
    • Kullanıcı tarafından atanan: Bu, yönetilen kimliğin birden çok Azure kaynağına erişebildiği 1:M (bir-çok) ilişkisi türüdür.

Yönetilen kimlikler hakkında daha fazla bilgi edinmek için bkz. Azure kaynakları için yönetilen kimlikler.

Azure CLI ve yönetilen kimlik kullanarak Azure'da oturum açmayı öğrenmek için bkz. Azure CLI kullanarak yönetilen kimlikle Azure'da oturum açma

Federasyon kimlik anahtarı kavramları

  • Federasyon kimliği, hizmet sorumlularının (uygulama kayıtları) ve kullanıcı tarafından atanan yönetilen kimliklerin GitHub veya Google gibi bir dış kimlik sağlayıcısından (IdP) gelen belirteçlere güvenmesine olanak tanır.
  • Güven ilişkisi oluşturulduktan sonra, harici yazılım iş yükünüz Microsoft kimlik platformundan erişim belirteçleri almak için dış IdP'den güvenilir belirteçleri takas eder.
  • Yazılım iş yükünüz, iş yüküne erişim verilen Microsoft Entra korumalı kaynaklara erişmek için bu erişim belirtecini kullanır.
  • Federasyon kimlikleri genellikle aşağıdaki senaryolar için en iyi çözümlerdir:
    • Herhangi bir Kubernetes kümesinde çalışan iş yükü
    • GitHub İşlemleri
    • Uygulama kimliklerini kullanarak Azure işlem platformlarında çalışan iş yükü
    • Google Cloud
    • Amazon Web Services (AWS)
    • Azure dışındaki işlem platformlarında çalışan iş yükü

Federasyon kimlikleri hakkında daha fazla bilgi edinmek için bkz:

Sorun giderme

ROPC hatası: Yöneticiniz tarafından yapılan yapılandırma değişikliği nedeniyle

Parola kullanarak Azure'da oturum açmaya çalıştığınızda, bu ROPC akışı (Kaynak Sahibi Parola Kimlik Bilgileri) olarak bilinir. Bu kimlik doğrulama yöntemi MFA ile desteklenmez. İşte bir örnek:

az login --username $username –password $password

Kullanıcı için MFA gerekiyorsa, yukarıdaki komut aşağıdaki hata iletisiyle başarısız olur:

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

Çözüm: MFA ile uyumlu bir kimlik doğrulama yöntemi kullanmaya geçin.

Kiracılar arası uyarı: Kiracıda kimlik doğrulaması başarısız oldu

Birkaç kiracıya erişiminiz varsa ve bunlardan biri MFA gerektiriyorsa, Azure CLI şuna benzer bir uyarı iletisi görüntüleyebilir:

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

Oturum açma aşamasında Azure CLI , bulunan ilk kiracıyla oturum açmaya çalışır. Bu sorun için bir çözüm üzerinde çalışırken, --tenant parametresiyle kullanmak istediğiniz kiracıyı belirtin:

az login --tenant 00000000-0000-0000-0000-000000000000

Çok faktörlü kimlik doğrulaması hakkında daha fazla bilgi edinin

Microsoft Entra Id belge sitesi MFA hakkında daha fazla ayrıntı sunar.

Ayrıca bakınız