Power Automate'te Hizmet Hesabı ve Hizmet Sorumlusu

Bir akış (flow) üretimde çalışırken, kullanılan kimliğin seçimi; bir meslektaşınız hastalandığında, bir parolanın süresi dolduğunda veya biri şirketten ayrıldığında akışın çalışmaya devam edip etmeyeceğini belirler. Power Automate'te tam olarak burada sürekli aynı soru gündeme gelir: bir akış klasik bir hizmet hesabı altında mı, yani paylaşılan bir kullanıcı hesabı altında mı çalışmalı, yoksa Microsoft Entra ID'de bağımsız, insan olmayan bir kimlik olan bir hizmet sorumlusu altında mı?

Resmi belgelerdeki kısa yanıt açıktır: Microsoft, iş açısından kritik, üretim akışları için hizmet sorumlusunu önerir ve klasik hizmet hesabını açıkça en iyi uygulama olarak nitelendirmez. Yine de her iki modele de yakından bakmakta fayda var, çünkü teknik olarak farklı çalışırlar ve farklı ön koşullar gerektirirler.

Power Automate'te hizmet hesabı nedir?

Bir hizmet hesabı, Power Automate lisanslaması hakkındaki Microsoft belgelerine göre, bir uygulama veya hizmet gibi insan olmayan bir varlığı temsil etmek amacıyla asıl amacı dışında kullanılan tamamen normal bir Microsoft Entra kullanıcı hesabıdır. Pratikte bu şu anlama gelir: bir ekip flow-uretim@sirket.com gibi bir hesap oluşturur, parolayı birden fazla meslektaşla paylaşır ve bu hesap daha sonra üretim akışlarının sahibi olur.

Microsoft sorunu doğrudan dile getirir: aynı hesaba birden fazla kişinin erişimi varsa, bir akışta hangi değişikliğin kim tarafından yapıldığını izlemek neredeyse imkânsız hale gelir. Buna ek olarak, zorunlu parola değişiklikleri veya çok faktörlü kimlik doğrulaması gibi durumlarda parola yönetimi sürekli bir konu haline gelir. Bu nedenle Microsoft, mevcut hizmet hesaplarının izinlerinin düzenli olarak gözden geçirilmesini, erişim yetkisi olan kişi çevresinin mümkün olduğunca küçük tutulmasını ve saldırı yüzeyini azaltmak için farklı senaryolar için ayrı hesaplar kullanılmasını açıkça önerir. Bazı durumlarda bir hizmet hesabı, bir akışı orijinal oluşturucusundan bağımsız hale getirmek için kullanılır. Ancak Microsoft, tam olarak bu amaç için hizmet sorumlusuna geçilmesini açıkça önerir.

Hizmet sorumlusu nedir?

Bir hizmet sorumlusu, bir hizmet sorumlusunun sahip olduğu akışların desteklenmesine ilişkin Microsoft belgelerine göre, bir uygulamayı veya hizmeti temsil eden ve Azure ile Power Platform'da bağımsız olarak kaynaklara sahip olabilen ve bunları yönetebilen, insan olmayan bir güvenlik kimliğidir. Teknik olarak arkasında bir Microsoft Entra uygulama kaydı bulunur. Bir hizmet sorumlusunun Power Platform'da akışlara sahip olabilmesi için önce Power Platform yönetim merkezi veya API üzerinden sözde bir uygulama kullanıcısı oluşturulmalıdır.

Bu uygulama kullanıcısı oluşturulduktan sonra, bir bulut akışının sahipliği ona devredilebilir: akışta Ayrıntılar bölümünü açar, Düzenle'yi seçer ve sahibi uygulama kullanıcısının adıyla değiştirirsiniz. Önemli olan şu: belgelere göre bir hizmet sorumlusu bir akışın ortak sahibi olamaz, yalnızca tek sahibi olabilir. Bir çözüm dışındaki bir akışta ayrıca kullanılan tüm bağlantıların uygulama kullanıcısıyla açıkça paylaşılması gerekir; bir çözüm akışında bu adım gerekli değildir.

Hizmet hesabı mı, hizmet sorumlusu mu: karar rehberi

Günlük pratikte karar, Power Automate akışlarına erişim hakkındaki Microsoft belgelerinin de açıkladığı gibi net kriterlere dayandırılabilir:

• İş açısından kritik veya kurum genelindeki akışlar: Microsoft burada açıkça hizmet sorumlusunu önerir, çünkü akış sahipliği bu sayede tek bir kişinin yaşam döngüsünden tamamen ayrılır. Biri şirketten ayrılsa veya rolü değişse bile akış etkilenmez.
• Birden fazla ortamı kapsayan DevOps ardışık düzenleri (pipeline): akışları geliştirmeden teste, oradan da üretime otomatik olarak dağıtan kişilerin de belgelere göre hizmet sorumlusuna güvenmesi gerekir, çünkü bu, API üzerinden temiz bir şekilde yönetilebilir.
• Denetlenebilirlik: bir hizmet sorumlusu, kişiden bağımsız, net bir denetim izi bırakır. Paylaşılan bir hizmet hesabında ise kimin ne zaman neyi değiştirdiği çoğu zaman belirsiz kalır.
• Etkileşimli veya kullanıcıya özgü akışlar: bir akışın onaylar veya kişiselleştirilmiş izinler gibi bir kişinin bireysel bağlamına ihtiyacı varsa, doğru seçim hâlâ normal bir kullanıcı hesabıdır; ne hizmet hesabı ne de hizmet sorumlusu.
• Mevcut hizmet hesapları: çalışan bir akışı bir hizmet hesabından bir hizmet sorumlusuna geçirmek istiyorsanız, ayrıca lisans ve istek sınırlarını da kontrol etmelisiniz; bu konuya birazdan değineceğiz.

Lisanslama ve istek sınırlarını küçümsemeyin

Bir akışa sahip olan hizmet sorumlusu, Power Automate'te etkileşimli olmayan bir uygulama kullanıcısı olarak kabul edilir ve bu nedenle normal bir kullanıcı lisansı alamaz. Bunun yerine kendine özgü, lisanssız istek sınırları geçerlidir ve akış premium bağlayıcılar kullanmaya başladığında, bir Power Automate Process lisansına veya akış başına bir lisansa, ya da alternatif olarak uygun şekilde lisanslanmış bir akış grubuna üyeliğe ihtiyaç duyar.

Klasik bir hizmet hesabında ise, sözde çoklama (multiplexing) adı verilen duruma karşı özel bir kuralla desteklenen, kullanıcı hesapları için geçerli olan normal lisanslama mantığı uygulanır: birden fazla kişi bir hizmet hesabının kimlik bilgilerini paylaşıyorsa ve akış premium işlevler kullanıyorsa, belgeler, hesabı kullanan farklı kişi sayısı arttıkça yeni eklenen kullanıcıların otomatik olarak lisansa uygun kalması için akış için bir işlem (process) lisansı önerir. Hizmet hesabı burada, Dataverse'in veri geçişleri gibi arka plan süreçleri için öngördüğü etkileşimli olmayan kullanıcı hesaplarıyla karıştırılmamalıdır: bunlardan kiracı başına en fazla yedi tanesine izin verilir ve Power Automate'in kendisi, belgelere göre şimdilik bu özel hesap türünü akış sahibi olarak desteklememektedir.

Peki ya Yönetilen Kimlik (Managed Identity)?

Azure dünyasından gelen biri, insan olmayan kimlikler denince hızla, kimlik bilgilerini tamamen gereksiz kılan, sistem veya kullanıcı tarafından atanan kimlikler olan Yönetilen Kimlikleri düşünür. Ancak Power Automate bulut akışları için bu kavram şimdilik doğrudan bir seçenek değildir: Yönetilen Kimlikler öncelikle, Azure Key Vault, Azure Blob Storage veya Azure SQL gibi belirli yerleşik ve yönetilen bağlayıcıların bunlar üzerinden kimlik doğrulaması yapabildiği Azure Logic Apps'e yerleşiktir. Power Automate'in kendisinde ise, bir akışa bireysel kişilerden bağımsız, kararlı bir kimlik verme görevini karşılaştırılabilir şekilde hizmet sorumlusu üstlenir. Akışları ve Logic Apps'i paralel olarak çalıştıranların, bu iki kavramı zihinsel olarak eşitlemek yerine bu farkı akılda tutması gerekir.

Pratikte geçiş: hizmet hesabından hizmet sorumlusuna

Geçiş üç adımda gerçekleşir: önce Microsoft Entra ID'de bir uygulama kaydı oluşturur ve bundan Power Platform'da bir uygulama kullanıcısı oluşturursunuz. Ardından, bir çözüm akışı olmadığı sürece, akışın kullandığı tüm bağlantıları bu uygulama kullanıcısıyla açıkça paylaşırsınız. Son olarak akıştaki sahibi yeni uygulama kullanıcısı olarak değiştirir ve akışı tekrar açarsınız. Üretim süreçlerinin boşa düşmemesi için, önceki hizmet hesabını devre dışı bırakmadan önce bu son adım için kısa bir test çalıştırması planlayın.

Birden fazla üretim akışının hizmet hesaplarından hizmet sorumlularına geçişini tek başına yürütmek istemeyenler, NordFlux'un Power Automate hizmetinde destek bulabilir: uygulama kaydının kurulmasından lisans ve izin yapısının güvence altına alınmasına kadar. Böylece akış ortamınız büyürken bile hangi otomasyonun kime ait olduğu ve kim tarafından işletildiği üzerindeki kontrolü elinizde tutarsınız.

Sık sorulan sorular

Üretim akışları için hizmet hesabı yasak mı?

Yasak değil, ama Microsoft bunu açıkça en iyi uygulama olarak nitelendirmiyor. İşletme açısından kritik veya uzun süre çalışan akışlar için belgeler, bunun yerine açıkça hizmet sorumlusunu öneriyor; çünkü bu, tek tek kişilere veya paylaşılan parolalara bağımlı değildir.

Bir hizmet sorumlusu bir akışın ortak sahibi olabilir mi?

Hayır. Belgelere göre bir hizmet sorumlusu uygulama kullanıcısı yalnızca bir akışın tek sahibi olabilir, ortak sahibi olamaz. Bu nedenle ortak sahip düzenleme iletişim kutusunda hiç görünmez.

Bir hizmet sorumlusunun kendi Power Automate lisansına ihtiyacı var mı?

Bir hizmet sorumlusu, etkileşimli olmayan bir uygulama kullanıcısıdır ve bu nedenle normal bir kullanıcı lisansı alamaz. Akış premium bağlayıcılar kullanmaya başladığında, bunun yerine bir Power Automate Process lisansına veya akış başına bir lisansa ya da uygun şekilde lisanslanmış bir akış grubuna üyeliğe ihtiyaç duyar.

Yönetilen Kimlik, Power Automate'te de kullanılabilir mi?

Bir bulut akışına sahip olmak için doğrudan değil. Yönetilen Kimlikler öncelikle, belirli Azure kaynaklarına karşı kimlik doğrulama için Azure Logic Apps'in bir kavramıdır. Power Automate'te, kararlı, insan olmayan bir akış kimliği sağlama görevini karşılaştırılabilir şekilde hizmet sorumlusu üstlenir.

Sahibi değiştirdiğimde mevcut bağlantılara ne olur?

Bağlantılar otomatik olarak yeni sahibe geçmez. Bir çözüm dışındaki bir akış söz konusuysa, kullanılan tüm bağlantıları ayrıca açıkça yeni hizmet sorumlusu uygulama kullanıcısıyla paylaşmanız gerekir, aksi takdirde yürütme başarısız olur. Bir çözüm akışında bu adım, belgelere göre gerekli değildir.