Otomasyon senaryolarında çok faktörlü kimlik doğrulamasının Azure PowerShell ü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.

Important

Otomasyon için Microsoft Entra kullanıcı kimlikleri 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ı

Note

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

  • Interactive authentication: 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. Kimlik doğrulaması, yönetilen kimlik veya hizmet temsili gibi etkileşimli olmayan bir şekilde işlenmediği sürece bu doğrulama, otomasyonun çalışmasını engeller.

  • Scripted oturum açma hataları: Azure PowerShell betiklerini bağımsız olarak çalıştırma gibi otomasyon senaryolarında, MFA özellikli bir kullanıcı kimliği kimlik doğrulaması yapmaya çalıştığında betik başarısız 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 liste, müşterilerin Azure PowerShell ile otomasyon için Microsoft Entra kullanıcı kimliği kullanabilecekleri örnek senaryolar sağlar. Bu liste tüm senaryolar için kapsamlı değildir.

Warning

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

  • Genelleş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

  • Active Directory'den Microsoft Entra ID'ye eşitlenen hizmet hesapları: Active Directory (AD) ile Microsoft Entra ID'ye eşitlenmiş olan 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 script.

  • Ü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ğinde otomatikleştirme: Kullanıcının zaten yeterli izinlere sahip olduğu kendi Azure aboneliğindeki görevleri otomatikleştirmesi gerekiyorsa.

Microsoft Entra kullanıcı kimlikleri için zorunlu çok faktörlü kimlik doğrulama nedeniyle otomasyon senaryolarında yönetilen bir kimliğe veya hizmet sorumlusuna geçmek gereklidir.

Nasıl başlar?

Azure PowerShell betiklerinizi Microsoft Entra ID kullanıcı hesabı ve parolasıyla kullanmaktan Connect-AzAccount kullanarak geçiş yapmak 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ü atamak için Steps. Azure PowerShell kullanarak rol atamak için bkz. Azure PowerShell kullanarak Azure rollerini atama.

  5. hizmet sorumlusu veya yönetilen kimlikle oturum açmak için Azure PowerShell 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 PowerShell ve hizmet ilkesi kullanarak Azure'a nasıl oturum açacağınızı öğrenmek için bkz. Azure PowerShell kullanarak hizmet ilkesi ile Azure'a oturum açma

Yönetilen kimlik anahtarı kavramları

  • Belirli bir Azure kaynağına bağlıdır ve bu tek kaynağın diğer Azure uygulamalarına erişmesine izin verir.
  • 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:
    • System assigned: Bu tür, iki Azure kaynağı arasındaki 1:1 (bire bir) erişim bağlantısıdır.
    • Kullanıcı atandı: Bu tür, yönetilen kimliğin birden çok Azure kaynağına erişebildiği 1:M (bir-çok) ilişkisine sahiptir.

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

Azure PowerShell ve yönetilen kimlik kullanarak Azure'a nasıl giriş yapacağınızı öğrenmek için Azure PowerShell kullanarak yönetilen kimlikle Azure'a giriş yapın konusuna bakın.

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, dış IdP'den güvenilir belirteçleri Microsoft kimlik platformu erişim belirteçleriyle değiştirir.
  • 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 Actions
    • Uygulama kimliklerini kullanarak Azure işlem platformlarında çalışan iş yükü
    • Google Bulut
    • Amazon Web Services (AWS)
    • Azure dışında işlem platformlarında çalışan iş yükü

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

Ç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

  • Last updated on