Aracılığıyla paylaş

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

  • Makale

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 bahsedilen talepler hakkında daha fazla bilgi için bkz. erişim belirteçlerini Microsoft kimlik platformu.

Hedef kitleyi doğrulama

Talep, 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}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 değerinin tid uygulamayla veri depolamak için kullanılan kiracı kimliğiyle eşleşip eşleşmediğ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ı yalnızca ilk adımdır ve bu makalede açıklanan konu ve aktör denetimleri hala gereklidir. Amacınız bir kiracıdaki tüm kullanıcıları yetkilendirmekse, 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 , , , scpgroupswids talepleri ile rolesuygun 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ştirmek için yetkilendirmesi olup olmadığını belirlemek için de kullanılabilir, ancak bir özneye 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. Talep, wid Microsoft Entra yerleşik rollerinde bulunan rollerden kullanıcıya atanan 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_username unique_name talepleri kullanmayın. Bu talepler benzersiz değildir ve kiracı yöneticileri veya bazen kullanıcılar tarafından denetlenebilir ve bu da onları yetkilendirme kararları için uygun 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ı sorumlusunun ömrü boyunca değişir ve bu da yetkilendirme için güvenilir olmasını sağlar.

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 mevcut olmayan oluşumlar scp vardır. Aşağıdaki senaryolar için talebin scp yokluğunu denetlemeniz gerekir:

  • 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 talepleri kullanırken uygulamanın isteğe bağlı talebi doğrulayarak belirtecin uygulama için doğrudan verildiğinden idtyp emin olması 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