Talepleri doğrulayarak uygulamaların ve API'lerin güvenliğini sağlama

Belirteçlerle etkileşim kurmak, kullanıcıları yetkilendirmek için uygulama oluşturmanın temel bir parçasıdır. En az ayrıcalıklı erişim için Sıfır Güven ilkesine uygun olarak, uygulamaların yetkilendirme gerçekleştirirken erişim belirtecinde bulunan belirli taleplerin değerlerini doğrulamaları önemlidir.

Talep tabanlı yetkilendirme, uygulamaların belirtecin belirteçte bulunan kiracı, konu ve aktör gibi şeyler için doğru değerleri içerdiğinden emin olmasını sağlar. Buna göre, talep tabanlı yetkilendirme, kullanılacak çeşitli yöntemler ve izleyebileceğiniz senaryolar göz önüne alındığında karmaşık görünebilir. Bu makale, uygulamalarınızın en güvenli uygulamalara bağlı kalmasını sağlamak için talep tabanlı yetkilendirme işlemini basitleştirmeyi amaçlıyor.

Yetkilendirme mantığınızın güvenli olduğundan emin olmak için taleplerde aşağıdaki bilgileri doğrulamanız gerekir:

  • Belirteç için uygun hedef kitle belirtilir.
  • Belirtecin kiracı kimliği, verilerin depolandığı kiracının kimliğiyle eşleşir.
  • Belirtecin konusu uygundur.
  • Aktör (istemci uygulaması) yetkilidir.

Not

Erişim belirteçleri yalnızca bir istemci tarafından alındıkları web API'lerinde doğrulanır. İstemci erişim belirteçlerini doğrulamamalıdır.

Bu makalede belirtilen iddialar hakkında daha fazla bilgi için bkz Microsoft kimlik platformu erişim belirteçleri.

Hedef kitleyi doğrulama

İddia, aud belirtecin hedef kitlesini tanımlar. Talepleri doğrulamadan önce, erişim belirtecinde yer alan talebin değerinin aud Web API'sine uygun olduğunu her zaman doğrulamanız gerekir. Değer, istemcinin belirteci nasıl istediğine bağlı olabilir. Erişim belirtecindeki hedef kitle uç noktaya bağlıdır:

  • v2.0 belirteçleri için hedef kitle, web API'sinin istemci kimliğidir. Bu bir GUID.
  • v1.0 belirteçleri için hedef kitle, belirteci doğrulayan web API'sinde bildirilen appID URI'lerinden biridir. Örneğin, api://{ApplicationID}, veya etki alanı adıyla başlayan benzersiz bir ad (etki alanı adı bir kiracıyla ilişkilendirilmişse).

Bir uygulamanın appID URI'si hakkında daha fazla bilgi için bkz . Uygulama Kimliği URI'si.

Kiracıyı doğrulama

Belirteçteki tid'nin, uygulamayla veri depolamak için kullanılan kiracı kimliğiyle eşleştiğini her zaman denetleyin. Bir uygulama için bilgiler bir kiracı bağlamında depolandığında, yalnızca daha sonra aynı kiracıda yeniden erişilmelidir. Bir kiracıdaki verilere hiçbir zaman başka bir kiracıdan erişilmesine izin verme.

Kiracının doğrulanması ilk adımdır, ancak bu makalede açıklanan konu ve aktör denetimleri hala gereklidir. Bir kiracıdaki tüm kullanıcıları yetkilendirmeyi planlıyorsanız, bu kullanıcıları bir gruba açıkça eklemeniz ve gruba göre yetkilendirmeniz kesinlikle önerilir. Örneğin, yalnızca kiracı kimliğini ve talebin oid varlığını denetleyerek, API'niz kullanıcılara ek olarak bu kiracıdaki tüm hizmet sorumlularını istemeden yetkilendirebilir.

Konuyu doğrulama

Kullanıcı (veya yalnızca uygulama belirteci için uygulamanın kendisi) gibi belirteç konusunun yetkilendirilip yetkilendirilmediğini belirleyin.

Belirli sub veya oid talepleri de kontrol edebilirsiniz.

Veya

Konunun , , , rolesscpgroups talepleri ile widsuygun bir role veya gruba ait olup olmadığını de kontrol edebilirsiniz. Örneğin, sabit talep değerlerini tid ve oid uygulama verileri için birleşik anahtar olarak kullanın ve kullanıcıya erişim verilip verilmeyeceğini belirleyin.

roles, groups veya wids talepleri, öznenin bir işlemi gerçekleştirme yetkisi olup olmadığını belirlemek için de kullanılabilir, ancak bir konuya izin verilebileceği tüm yolların kapsamlı bir listesi değildir. Örneğin, bir yöneticinin API'ye yazma izni olabilir, ancak normal bir kullanıcı olmayabilir veya kullanıcı bazı eylemler gerçekleştirmesine izin verilen bir grupta olabilir. wid talebi, Microsoft Entra yerleşik rollerinde bulunan rollerden kullanıcıya atanmış olan kiracı genelindeki rolleri temsil eder. Daha fazla bilgi için bkz. Microsoft Entra yerleşik roller.

Uyarı

Bir erişim belirtecindeki kullanıcının verilere erişimi olup olmadığını depolamak veya belirlemek için hiçbir zaman gibi emailpreferred_usernameunique_name talepleri kullanmayın. Bu talepler benzersiz değildir ve kiracı yöneticileri veya bazen kullanıcılar tarafından denetlenebilir, bu da onları yetkilendirme kararları için uygun olmayan hale getirir. Bunlar yalnızca görüntüleme amacıyla kullanılabilir. Ayrıca bu talebi yetkilendirme için kullanmayın upn . UPN benzersiz olsa da, genellikle kullanıcı asıl adının ömrü boyunca değişir ve bu da yetkilendirme için güvenilir olmamasına neden olur.

Aktörü doğrulama

Kullanıcı adına hareket eden bir istemci uygulaması (aktör olarak adlandırılır) da yetkilendirilmelidir. scp Uygulamanın bir işlem gerçekleştirme iznine sahip olduğunu doğrulamak için talebi (kapsam) kullanın. içindeki scp izinler, kullanıcının gerçekten neye ihtiyaç duyduğuyla sınırlı olmalı ve en az ayrıcalık ilkelerine uymalıdır.

Ancak, belirteçte scp'in mevcut olmadığı durumlar vardır. Aşağıdaki senaryolar için scp iddiasının yokluğunu kontrol etmelisiniz.

  • Daemon uygulamaları / yalnızca uygulama izni
  • Kimlik belirteçleri

Kapsamlar ve izinler hakkında daha fazla bilgi için Microsoft kimlik platformu kapsamlar ve izinler bölümüne bakın.

Not

Bir uygulama yalnızca uygulama belirteçlerini işleyebilir (daemon uygulamaları gibi kullanıcıları olmayan uygulamalardan gelen istekler) ve tek tek hizmet sorumlusu kimlikleri yerine belirli bir uygulamayı birden çok kiracıda yetkilendirmek isteyebilir. Bu durumda, appid konu yetkilendirmesi için talep (v1.0 belirteçleri için) veya azp talep (v2.0 belirteçleri için) kullanılabilir. Ancak, bu hak taleplerini kullanırken, uygulamanın isteğe bağlı talebi doğrulayarak belirtecin doğrudan uygulama için verildiğini kontrol etmesi gerekir. Temsilci kullanıcı belirteçleri uygulama dışındaki varlıklar tarafından edinilebileceği için yalnızca türündeki app belirteçler bu şekilde yetkilendirilebilir.

Sonraki adımlar

  • Last updated on