Ajanlar için koşullu erişim

Aracılar için Koşullu Erişim, aracıların Microsoft Entra ID tarafından korunan kaynaklara nasıl erişildiğini denetleyerek Koşullu Erişim ilke altyapısının bir uzantısıdır. Kullanıcının ve aracının bağlamı, cihazı, konumu ve risk bilgileri gibi gerçek zamanlı sinyalleri bir araya getirerek erişime ne zaman izin verileceğini, erişimin engelleneceğini veya sınırleneceğini belirler ya da daha fazla doğrulama adımı gerektirir.

Aracının erişim desenini anlamak, doğru kimliği hedeflemenize yardımcı olur. Aracı, oturum açmış bir kullanıcı adına işlem yapabilir, kendi aracı kimliğini veya kendi aracı kullanıcı hesabını kullanabilir.

Aracılar için Koşullu Erişim hakkında bilgi edinin:

Gereksinimler ve lisanslama

Aracılar için koşullu erişim Microsoft Entra ID aşağıdaki lisans planlarından birini gerektirir:

  • Microsoft 365 E7, Agent 365 ve Microsoft Entra Paketi'i içerir.
  • En az Microsoft Entra P1 veya Microsoft 365 E3 ile eşleştirilmiş Microsoft Agent 365 lisansı.

Daha fazla bilgi için bkz. Microsoft Agent 365 planları ve fiyatlandırması.

Koşullu Erişim aracı erişimini nasıl değerlendirir?

SharePoint dosyası, MCP sunucusu veya Open API hizmeti gibi bir kaynağa erişmek için kullanıcı veya aracı Microsoft Entra ID'dan erişim belirteci ister.

Koşullu Erişim ilkesi uygulandığında, Microsoft Entra ID belirteci vermeden önce ilke gereksinimlerini değerlendirir. Gereksinimler karşılanırsa Microsoft Entra ID belirteci sağlar. Hedef kaynak, belirteci doğrular ve yetkilendirme kararları vermek için içerdiği claim'leri kullanır.

Aracı kimlikleri için veri erişim desenlerini gösteren diyagram.

Her erişim belirtecinin bir konusu ve bir hedef kitlesi vardır:

  • Konu: Belirteci alan kimlik.
    • Temsilci erişiminde belirteç, kullanıcıyı temsil ederken çağıran uygulamayı veya aracıyı da tanımlar.
    • Yalnızca uygulama erişiminde, konu aracı kimliğidir.
    • Aracı kullanıcı erişiminde, konu aracının kullanıcı hesabıdır.
  • Hedef kitle: Belirtecin yönelik olduğu hedef kaynaktır ve Entra ID’ye kaydedilmiş olması gerekir. Bir konu birden çok kaynağa erişiyorsa, genellikle her kaynak için ayrı bir belirteç gerekir.

Koşullu Erişim hem erişim isteyen konuyu hem de erişilen hedef kitleyi değerlendirir. Microsoft Entra ID bir erişim belirteci verdiğinde veya yenilediğinde ilkeleri değerlendirir. Bazı kaynaklar, belirli olaylar için neredeyse gerçek zamanlı uygulamayı tetikleyebilen Sürekli Erişim Değerlendirmesi'ni de destekler.

Koşullu Erişim kararları nasıl yapılır?

Koşullu Erişim ilkeleri if-then deyimleri olarak çalışır:

  • İlkede tanımlanan koşullar karşılanırsa, yapılandırılan erişim denetimleri uygulanır.
  • Gerekli denetimler karşılanırsa erişim verilir.
  • Gerekli denetimler karşılanmazsa erişim reddedilir.

Örneğin, bir kullanıcı bir aracıyı e-postasına erişmesi için yetkilendirmeden önce kuruluş çok faktörlü kimlik doğrulaması gerektirebilir. Benzer şekilde, bir kuruluş yüksek riskli olarak tanımlanan aracılardan erişimi engellemek için bir ilke yapılandırabilir.

Koşullu Erişim değerlendirildiğinde

Koşullu Erişim, Microsoft Entra ID bir erişim belirteci düzenlediğinde veya yenilediğinde değerlendirilir. Bazı kaynaklar, belirli olaylar için neredeyse gerçek zamanlı uygulamayı tetikleyebilen Sürekli Erişim Değerlendirmesi'ni de destekler.

Ajan erişim desenleri

Aracılar aşağıdaki desenlerden birini kullanarak Microsoft Entra korumalı kaynaklara erişebilir:

Aracıysa Erişim düzeni İlke hedefi Guidance
Oturum açmış bir kullanıcının aşağı akış kaynaklarına erişir On-behalf-of (OBO), diğer adıyla devredilmiş erişim Kullanıcılar ve gruplar Aracı OAuth akışları: Başkası adına
Kaynaklara kendi aracı kimliğiyle erişir ve oturum açmış kullanıcı yoktur Yalnızca uygulama erişimi, istemci kimlik bilgileri veya yalnızca uygulama erişimi olarak da bilinen Temsilci kimliği veya temsilci kimliği taslağı Koşullu Erişim ile otonom aracıların güvenliğini sağlama
Kaynaklara kendi kullanıcı hesabı üzerinden erişir Temsilci kullanıcı erişimi Ajanın kullanıcı hesabı Koşullu Erişim ile kullanıcı olarak davranan güvenli aracılar

Bir aracı, birden fazla erişim deseni kullanabilir. Ajanın kullandığı her belirteç öznesi için ayrı politikalar oluşturun. Aracı kimliğini hedefleyen bir ilke aracının kullanıcı hesabına uygulanmaz ve aracının kullanıcı hesabını hedefleyen bir ilke aracı kimliğine uygulanmaz.

Kullanıcı adına hareket eden aracılar

En yaygın erişim modeli, on-behalf-of (OBO) akışıdır. OBO akışında, bir kullanıcı aracı uygulamasında oturum açar. Aracı, kullanıcının kimliği ve devredilen izinleriyle alt akış kaynaklarına erişir. Örneğin, bir aracı e-postalarınızı okuduğunda sizin yerinize posta kutunuza erişir. OBO akışının temsilciler için nasıl çalıştığı hakkında daha fazla bilgi edinmek için bkz: Temsilci OAuth akışları: Başkası adına.

Uyarı

Adına akış süreci, yetkilendirilmiş erişim olarak da bilinir. "On-behalf-of", aracı tipi değil, kimlik doğrulama akışını tanımlar. Bu etkileşimli aracılar, insan etkileşimi için bir kullanıcı arabirimi içerir. Herhangi bir aracı, oturum açmış bir kullanıcı mevcut olduğunda ve aracının bu kullanıcının kimliği ve izinleri olan kaynaklara erişmesi gerektiğinde bu akışı kullanabilir.

Bu akışta aracı uygulama, kullanıcının orijinal belirtecini yeniden kullanamaz çünkü bu belirteç başka bir hedef kitleye yönelik olarak verilmiştir. Bunun yerine aracı uygulama, Microsoft Entra ID ile belirteç alışverişi yapmak için OBO akışını kullanır ve hedef kaynak için kapsamlandırılmış yeni bir belirteç alır. Bu belirteç değişimi, koşullu erişim tarafından da değerlendirilir ve yöneticilerin kullanıcı adına hangi kaynak aracılarının erişebileceği üzerinde ayrıntılı denetimler uygulamalarına imkan tanır.

Bu akıştaki konu kullanıcı olduğundan, Koşullu Erişim ilkeleri aracı kimliklerini değil kullanıcıları ve grupları hedefler.

Uygulama olarak davranan aracılar

Aracılar oturum açmış bir kullanıcı olmadan kaynaklara erişebilir. Bu durumda ajan kaynağa kendi kimliğiyle erişir. Bu akış, istemci kimlik bilgileri akışı veya yalnızca uygulama erişimi olarak da bilinir. Tüm ajan türleri bu akışı kullanabilir. Aracıların kendi kimlikleriyle nasıl kimlik doğrulaması yaptıkları hakkında daha fazla bilgi için bkz. Aracı OAuth akışları: Otonom uygulamalar.

Bu akış aşağıdaki yaygın senaryolarda geçerlidir:

  • Bağımsız olarak çalışan otonom aracılar arka planda çalışır, olaylara yanıt verir veya bir zamanlamaya göre çalışır.
    • Örneğin, günlük rapor oluşturan ve sonucu bir çalışanlar grubuna gönderen bir aracı yazılım.
    • Bu senaryoda kullanıcı yoktur ve aracı kendi başına çalışır.
  • Kendi kimliğini kullanan etkileşimli aracılar her zaman kullanıcı adına kaynaklara erişmez; bazen kendi kimliklerini kullanırlar.
    • Örneğin, aracı yazılım kullanıcıların erişimi olmayan bir arka uç SMS hizmetini çağırırsa, OBO akışı geçerli değildir ve aracı yazılım doğrudan kendisi olarak kimlik doğrulaması yapar.
  • Genel kullanım için web'de yayımlanan aracılar kullanıcının kimliğini doğrulamaz veya kullanıcının bağlamını şirket kaynaklarına devretmeyi desteklemez.

Bu senaryolarda aracı, aracı kimliği şeması aracılığıyla yönetilen kendi aracı kimliğini ve kimlik bilgilerini kullanarak bir erişim belirteci istemektedir. Belirteç, aracı kimliğine (kullanıcıya değil) verilir. Bu nedenle Koşullu Erişim ilkelerinin kapsamı kullanıcı yerine aracı kimliğine göre belirlenmiş durumdadır. Adım adım ilke yapılandırması için bkz . Koşullu Erişim ile otonom aracıların güvenliğini sağlama.

Kullanıcı olarak davranan aracılar

Bazen bir aracının bir kullanıcı adına görevler gerçekleştirmesi veya kendi kimliğiyle çalışması yeterli olmaz. Belirli senaryolarda, bir ajanın kendi posta kutusuna, sohbete erişime ve ekip üyesi olarak işbirliğine dayalı iş akışlarına katılma olanağına sahip, dijital çalışan olarak işlev gören kendi ajanın kullanıcı hesabı vardır.

Bu modelde, yönetici dizinde bir kullanıcı hesabı oluşturur ve bunu aracının kimliğine bağlar. Buradan, diğer kullanıcı hesaplarına benzer. Lisanslar, posta kutusu ve takvim gibi Microsoft 365 kaynaklara erişmek için atanabilir. Hesap, tıpkı bir insan kullanıcı hesabı gibi yönetim birimlerine ve güvenlik gruplarına eklenebilir.

Bu akışı kullanan aracılar, insan etkileşimi için kullanıcı arabirimi içermediğinden otonom aracılar olarak da kabul edilir. Bu modelde, erişim belirteci, kullanıcı hesabına (belirteç konusuna) atanır ve ilke, aracının kimliğine değil, kullanıcının hesabına göre değerlendirilir. Adım adım ilke yapılandırması için bkz. Otonom aracılar için Koşullu Erişim. Aracı kullanıcı OAuth akışı hakkında daha fazla bilgi için bkz. Aracı kullanıcı OAuth akışı.

Windows 365 Aracılar için Bulut Bilgisayarlar gibi yönetilen uç noktalarda çalışan aracılar da cihaz uyumluluğu ve uyumlu ağ denetimlerine tabi olabilir. Bu ilkeleri yalnızca uç nokta tabanlı oturumlarla kapsamak için Aracı yürütme ortamları (Önizleme) koşulunu kullanın. Daha fazla bilgi için bkz. Aracı kullanıcı hesapları için uyumlu bir cihaz gerektirme.

Koşullu Erişim ilkeleri ve aracı kimliği şemaları

Belirli aracı erişim desenlerine ek olarak, aracı kimliği şemalarını seçerek bir aracı sınıfına Koşullu Erişim ilkeleri uygulayabilirsiniz. Aracı kimliği şeması, ondan oluşturulan aracı kimlikleri için yapılandırma ve idare modelini tanımlar. Bir şemayı hedefleyen ilke, daha sonra oluşturulan aracı kimlikleri de dahil olmak üzere bu şemadan oluşturulan tüm aracı kimlikleri için geçerlidir.

Aşağıdaki diyagramda yalnızca "A" şemasıyla ilişkili aracı kimliklerine erişim verildiği gösterilmektedir; diğer tüm aracılar dışlanır ve engellenir.

Bir şemadan aracı kimliklerine uygulanan Koşullu Erişim ilkesini gösteren diyagram.

Örneğin, her biri kendi amacı olan birkaç aracıya sahip olduğunuz bir proje düşünün. Bazıları bağımsız olarak çalışırken, diğerleri görevleri tamamlamak için diğer aracılarla (A2A) birlikte çalışır. Hepsi aynı şema altında oluşturulduysa, bu şemaya uygulanan tek bir ilke koleksiyonun tamamında tutarlı erişim denetimlerini zorunlu tutar.

Öznitelik Temelli Koşullu Erişim

Ajan kimliklerinin sayısı arttıkça, her politikada her birini ayrı ayrı yönetmek sürdürülemez hâle gelir. Özel güvenlik öznitelikleri, aracı kimliklerini ve kaynaklarını işletmeye özgü etiketlerle kategorilere ayırmanıza ve ardından Koşullu Erişim ilkelerindeki bu öznitelikleri hedeflemenize olanak tanır. İlkeler, gelecekte eklenenler de dahil olmak üzere eşleşen öznitelikleri olan her aracıya otomatik olarak uygulanır.

Aracı kimlikleri için Koşullu Erişim akışını gösteren diyagram.

İlke örneği için bkz. Özel güvenlik özniteliklerini kullanarak onaylı aracılara izin verme.

Sınırlar ve sınırlamalar

Koşullu Erişim ilkeleri aşağıdaki durumlarda geçerli değildir:

  • Aracı kimliği şeması, aracı kimliği veya aracının kullanıcı hesabını oluşturmak için Microsoft Graph için bir belirteç alır.
    • Aracı şemaları sınırlı işlevselliğe sahiptir. Kaynaklara erişmek için bağımsız olarak işlem yapamazlar ve yalnızca aracı kimlikleri ve aracıların kullanıcı hesaplarını oluşturmaya katılırlar.
    • Temsilci görevleri her zaman temsilci kimliği tarafından gerçekleştirilir.
  • Aracı kimliği şeması veya aracı kimliği, AAD Token Exchange Endpoint: Public uç noktasında bir ara jeton değişimi gerçekleştirir (Kaynak Kimliği: fb60f99c-7a34-4190-8149-302f77469936).
    • kapsamı AAD Token Exchange Endpoint: Public olan belirteçler Microsoft Graph çağıramaz.
    • Koşullu Erişim, belirteç edinimini aracı kimliği veya aracının kullanıcı hesabı üzerinden koruduğu için aracı iş akışları korunur.
  • Güvenlik varsayılanları etkindir.
  • Koşullu Erişim yalnızca Microsoft Entra ID tarafından güvenliği sağlanan kaynakları korur. Örneğin, bir aracı bir API anahtarı kullanarak kaynaklara erişiyorsa, Microsoft Entra ID kimlik doğrulamasını ve belirteç verme işlem hattını tamamen atlar ve Koşullu Erişim ilkeleri bunlara uygulanmaz.

Şu anda aşağıdaki yapılandırmalar desteklenmemektedir:

  • Tüm kullanıcıları hedefleyen ilkeler, aracının kullanıcı hesaplarını içermez.
  • Aracının kullanıcı hesabını grup üyeliğine göre kapsama almak veya hariç tutmak için Koşullu Erişim ilkesinin kapsamını belirleme
  • Aracı kimliklerini hedefleyen Koşullu Erişim ilkesi, aracının kullanıcı hesabına uygulanmaz.
  • Aracı kimliği şemasını kullanarak aracı kimliklerini hedefleyen Koşullu Erişim ilkesi, aracının kullanıcı hesabını değil yalnızca aracı kimliğini kapsar.

İlgili içerik

  • Last updated on