Azure API Management’da API’ler için kimlik doğrulaması ve yetkilendirme

Makale
11/16/2023

UYGULANANLAR: Tüm API Management katmanları

Bu makale, API Management'ta kullanıcıların yönetilen API'lere erişiminin güvenliğini sağlamanıza yardımcı olan zengin, esnek bir özellik kümesine giriş niteliğindedir.

API Management’daki API kimlik doğrulaması ve yetkilendirmesi, istemci uygulamalarının API Management ağ geçidine ve arka uç API'lerine uçtan uca iletişiminin güvenliğini sağlamayı içerir. Birçok müşteri ortamı için tercih edilen API yetkilendirme protokolü OAuth 2.0'dır. API Management, istemci ile API Management ağ geçidi arasında, ağ geçidi ile arka uç API'si arasında veya her ikisi de bağımsız olarak OAuth 2.0 yetkilendirmesini destekler.

API'lerin güvenliğini sağlamaya yönelik etkileşim noktalarını gösteren diyagram.

API Management, OAuth 2.0'ı destekleyen veya API'ler için OAuth 2.0 yetkilendirmesi mümkün olmadığında yararlı olan diğer istemci tarafı ve hizmet tarafı kimlik doğrulaması ve yetkilendirme mekanizmalarını destekler. Bu seçenekler arasından seçim yapmanız kuruluşunuzun API ortamının olgunluğuna, güvenlik ve uyumluluk gereksinimlerinize ve kuruluşunuzun yaygın API tehditlerini azaltma yaklaşımına bağlıdır.

Önemli

Kullanıcıların API’lere erişimini güvenli hale getirmek, API Management ortamınızın güvenliğini sağlamada dikkat edilmesi gereken birçok noktadan biridir. Daha fazla bilgi edinmek istiyorsanız API Management için Azure güvenlik temeli makalesine bakın.

Not

Diğer API Management bileşenleri, kullanıcı erişiminin güvenliğini sağlamak ve kısıtlamak için ayrı mekanizmalara sahiptir:

API Management örneği Azure denetim düzlemi aracılığıyla yönetmek için API Management, Microsoft Entra Id ve Azure rol tabanlı erişim denetimine (RBAC) dayanır.
API Management geliştirici portalı, güvenli kullanıcı kaydolma ve oturum açma işlemlerini kolaylaştırmak için çeşitli seçenekleri destekler.

Kimlik doğrulaması ve yetkilendirme

API'lere erişim bağlamında kimlik doğrulaması ve yetkilendirmenin kısa bir açıklaması aşağıdadır:

Kimlik Doğrulaması - API'ye erişen bir kullanıcı veya uygulamanın kimliğini doğrulama işlemi. Kimlik doğrulaması kullanıcı adı ve parola, sertifika gibi kimlik bilgileri veya çoklu oturum açma (SSO) veya diğer yöntemler aracılığıyla yapılabilir.
Yetkilendirme - Genellikle OAuth 2.0 gibi belirteç tabanlı bir protokol aracılığıyla bir kullanıcı veya uygulamanın belirli bir API'ye erişme izni olup olmadığını belirleme işlemidir.

Not

Kimlik doğrulaması ve yetkilendirmeyi desteklemek için, kimlik doğrulaması veya yetkilendirme için kullanılan kimlik bilgilerini veya belirteçleri korumak amacıyla API'lere erişimin TLS kullanılarak da güvenliği sağlanmalıdır.

OAuth 2.0 kavramları

OAuth 2.0 , web API'leri gibi kaynaklara erişimin güvenliğini sağlamak için yaygın olarak kullanılan standart bir yetkilendirme çerçevesidir. OAuth 2.0, bir istemci uygulamasının kullanıcı adına kaynaklar üzerinde gerçekleştirebileceği eylemleri kullanıcının kimlik bilgilerini paylaşmadan kısıtlar. OAuth 2.0 bir kimlik doğrulama protokolü olmasa da, genellikle kullanıcı kimlik doğrulaması ve SSO işlevselliği sağlayarak OAuth 2.0'ı genişleten OpenID Bağlan (OIDC) ile kullanılır.

OAuth akışı

bir istemci uygulaması TLS ve OAuth 2.0 kullanılarak güvenliği sağlanan bir istek içeren bir API'yi çağırdığında ne olur? Aşağıda kısaltılmış bir örnek akış verilmiştir:

İstemci (çağıran uygulama veya taşıyıcı) kimlik bilgilerini kullanarak kimlik doğrulaması yapar.
İstemci, kimlik sağlayıcısının yetkilendirme sunucusundan sınırlı bir erişim belirteci (JSON web belirteci veya JWT) alır.

Kimlik sağlayıcısı (örneğin, Microsoft Entra Id) belirtecin verenidirve belirteç bir kaynak sunucusuna (örneğin, bir arka uç API'sine veya API Management ağ geçidine) erişim yetkisi veren bir hedef kitle talebi içerir.
İstemci API'yi çağırır ve erişim belirtecini (örneğin, bir Yetkilendirme üst bilgisinde) sunar.
Kaynak sunucusu erişim belirtecini doğrular. Doğrulama, verenin ve hedef kitle taleplerinin beklenen değerleri içerdiğini denetlemeyi içeren karmaşık bir işlemdir.
Belirteç doğrulama ölçütlerine göre arka uç API'sinin kaynaklarına erişim verilir.

İstemci uygulamasının ve senaryoların türüne bağlı olarak, belirteçleri istemek ve yönetmek için farklı yetkilendirme akışları gerekir. Örneğin, yetkilendirme kodu akışı ve verme türü genellikle web API'lerini çağıran uygulamalarda kullanılır. Microsoft Entra Id'de OAuth akışları ve uygulama senaryoları hakkında daha fazla bilgi edinin.

API Management'ta OAuth 2.0 yetkilendirme senaryoları

Senaryo 1 - İstemci uygulaması doğrudan arka uca yetkilendirme

Yaygın yetkilendirme senaryolarından biri, çağıran uygulamanın doğrudan arka uç API'sine erişim istemesi ve ağ geçidine bir yetkilendirme üst bilgisinde OAuth 2.0 belirteci sunmasıdır. Azure API Management daha sonra çağıran ile arka uç API'si arasında "saydam" bir proxy işlevi görür ve belirteci değiştirmeden arka uça geçirir. Erişim belirtecinin kapsamı, çağıran uygulama ile arka uç API'sinin arasındadır.

Aşağıdaki görüntüde Microsoft Entra Id'nin yetkilendirme sağlayıcısı olduğu bir örnek gösterilmektedir. İstemci uygulaması tek sayfalı bir uygulama (SPA) olabilir.

hedef kitlenin arka uç olduğu OAuth iletişimini gösteren diyagram.

HTTP isteğiyle birlikte gönderilen erişim belirteci arka uç API'sine yönelik olsa da, API Management yine de derinlemesine bir savunma yaklaşımına izin verir. Örneğin, JWT'yi doğrulamak, belirteç olmadan gelen istekleri reddetmek veya hedeflenen arka uç API'si için geçerli olmayan bir belirteç için ilkeleri yapılandırın. Api Management'ı, belirteçten ayıklanan diğer ilgi alanı taleplerini denetlemek için de yapılandırabilirsiniz.

Not

OAuth 2.0 ile Azure API Management aracılığıyla kullanıma sunulan bir API'nin güvenliğini bu şekilde sağlarsanız, API Management'ı bir Azure portalı veya geliştirici portalı test konsolu kullanıcısı adına test amacıyla geçerli bir belirteç oluşturacak şekilde yapılandırabilirsiniz. API Management örneğinize bir OAuth 2.0 sunucusu eklemeniz ve API'de OAuth 2.0 yetkilendirme ayarlarını etkinleştirmeniz gerekir. Daha fazla bilgi için bkz . OAuth 2.0 kullanıcı yetkilendirmesini yapılandırarak geliştirici portalının test konsolunu yetkilendirme.

Örnek:

Microsoft Entra ID ile OAuth 2.0 yetkilendirmesini kullanarak Azure API Management’da bir API’yi koruma

İpucu

API erişimi Microsoft Entra Id kullanılarak korunduğunda, belirteç doğrulaması için validate-azure-ad-token ilkesini yapılandırabilirsiniz.

Senaryo 2 - İstemci uygulaması API Management'ı yetkilendirir

Bu senaryoda API Management hizmeti API adına hareket eder ve çağıran uygulama API Management örneğine erişim isteğinde bulunur. Erişim belirtecinin kapsamı, çağıran uygulama ile API Management ağ geçidi arasındadır. API Management'ta, ağ geçidi isteği arka uca geçirmeden önce belirteci doğrulamak için bir ilke (validate-jwt veya validate-azure-ad-token) yapılandırın. Ayrı bir mekanizma genellikle ağ geçidi ile arka uç API'si arasındaki bağlantının güvenliğini sağlar.

Aşağıdaki örnekte, Microsoft Entra Id yine yetkilendirme sağlayıcısıdır ve karşılıklı TLS (mTLS) kimlik doğrulaması ağ geçidi ile arka uç arasındaki bağlantının güvenliğini sağlar.

hedef kitlenin API Management ağ geçidi olduğu OAuth iletişimini gösteren diyagram.

Bunu yapmanın farklı nedenleri vardır. Örneğin:

Arka uç, OAuth'u destekleyecek şekilde güncelleştirilmeyen eski bir API'dir

API Management ilk olarak belirteci doğrulayacak şekilde yapılandırılmalıdır (veren ve hedef kitle taleplerini en azından denetleme). Doğrulamadan sonra, KARŞıLıKLı TLS (mTLS) kimlik doğrulaması gibi API Management'tan gelen bağlantıların güvenliğini sağlamak için kullanılabilen çeşitli seçeneklerden birini kullanın. Bu makalenin devamındaki Hizmet tarafı seçenekleri bölümüne bakın.
Arka ucun gerektirdiği bağlamı arayandan oluşturmak mümkün değildir

API Management, çağırandan alınan belirteci başarıyla doğruladıktan sonra, kendi bağlamını veya çağıran uygulamadan türetilen bağlamı kullanarak arka uç API'sine bir erişim belirteci alması gerekir. Bu senaryo aşağıdakilerden biri kullanılarak gerçekleştirilebilir:
- Yapılandırılmış bir kimlik sağlayıcısından arka uç API'sinde geçerli olan bir ileriye doğru erişim belirteci almak için send-request gibi özel bir ilke.
- API Management örneğinin kendi kimliği: Belirteci API Management kaynağının sistem tarafından atanan veya kullanıcı tarafından atanan yönetilen kimliğinden arka uç API'sine geçirir.
Kuruluş, standartlaştırılmış yetkilendirme yaklaşımını benimsemek istiyor

API arka uçlarındaki kimlik doğrulama ve yetkilendirme mekanizmalarından bağımsız olarak, kuruluşlar ön uçta standartlaştırılmış yetkilendirme yaklaşımı için OAuth 2.0'da yakınsama yapmayı tercih edebilir. API Management'ın ağ geçidi, kuruluşun arka uçları geliştikçe tutarlı yetkilendirme yapılandırmasını ve API tüketicileri için ortak bir deneyimi etkinleştirebilir.

Senaryo 3: API Management arka ucu yetkilendirir

Yönetilen bağlantılarla (eski adı yetkilendirmeler), LinkedIn, GitHub veya diğer OAuth 2.0 uyumlu arka uçlar gibi bir veya daha fazla arka uca veya SaaS hizmetine erişimi yetkilendirmek için API Management'ta kimlik bilgileri yöneticisini kullanırsınız. Bu senaryoda, bir kullanıcı veya istemci uygulaması, kimlik sağlayıcısı veya diğer istemci tarafı seçenekleri kullanılarak ağ geçidi erişimi denetlenerek API Management ağ geçidine bir istekte bulunur. Ardından, ilke yapılandırması aracılığıyla kullanıcı veya istemci uygulaması API Management'a arka uç kimlik doğrulaması ve yetkilendirme yetkisi verir.

Aşağıdaki örnekte, istemci ile ağ geçidi arasında bir abonelik anahtarı kullanılır ve GitHub arka uç API'sinin kimlik bilgisi sağlayıcısıdır.

Kimlik bilgileri yöneticisinde yönetilen bir bağlantı kullanarak arka uç SaaS hizmetine yetkilendirmeyi gösteren diyagram.

Bir kimlik bilgisi sağlayıcısı bağlantısıyla API Management, OAuth 2.0 akışında API erişimi için belirteçleri alır ve yeniler. Bağlan ions, belirteç yönetimini birden çok senaryoda basitleştirir, örneğin:

Bir istemci uygulamasının GraphQL çözümleyicilerini kullanarak birden çok alanı çözümlemek için birden çok SaaS arka ucuna yetkilendirmesi gerekebilir.
Kullanıcılar kimlik sağlayıcılarından SSO tarafından API Management'ta kimlik doğrulaması yapar, ancak ortak bir kuruluş hesabı kullanarak bir arka uç SaaS sağlayıcısına (LinkedIn gibi) yetkilendirme yapar.
bir istemci uygulamasının (veya botun) kimliği doğrulanmış bir kullanıcı adına arka uç güvenli çevrimiçi kaynaklarına erişmesi gerekir (örneğin, e-postaları denetleme veya sipariş verme).

Örnekler:

API'lerin güvenliğini sağlamak için diğer seçenekler

Yetkilendirme tercih edilir ve OAuth 2.0 API'ler için güçlü yetkilendirmeyi etkinleştirmenin baskın yöntemi haline gelmiş olsa da, API Management istemci ve ağ geçidi (istemci tarafı) veya ağ geçidi ile arka uç (hizmet tarafı) arasındaki erişimi güvenli hale getirmek veya kısıtlamak için başka birçok mekanizma sağlar. Kuruluşun gereksinimlerine bağlı olarak, bunlar OAuth 2.0'ı desteklemek için kullanılabilir. Alternatif olarak, çağıran uygulamalar veya arka uç API'leri eskiyse veya henüz OAuth 2.0'ı desteklemiyorsa bunları bağımsız olarak yapılandırın.

İstemci tarafı seçenekleri

Mekanizma	Açıklama	Dikkat edilmesi gerekenler
mTLS	Bağlantı istemcisi tarafından sunulan sertifikayı doğrulama ve SERTIFIKA özelliklerini API Management'ta yönetilen bir sertifikaya göre denetleme	Sertifika bir anahtar kasasında depolanabilir.
Arayan IP'lerini kısıtlama	Belirli IP adreslerinden veya adres aralıklarından gelen çağrılara filtre uygulama (izin verme/reddetme).	Belirli kullanıcılara veya kuruluşlara veya yukarı akış hizmetlerinden gelen trafiğe erişimi kısıtlamak için kullanın.
Abonelik anahtarı	API Management aboneliğine göre erişimi bir veya daha fazla API ile sınırlama	Başka bir kimlik doğrulama veya yetkilendirme yöntemine ek olarak abonelik (API) anahtarı kullanmanızı öneririz. Abonelik anahtarı kendi başına güçlü bir kimlik doğrulaması biçimi değildir, ancak abonelik anahtarının kullanımı belirli senaryolarda yararlı olabilir; örneğin, tek tek müşterilerin API kullanımını izleme veya belirli API ürünlerine erişim verme.