Aracılığıyla paylaş

API Management kullanarak OWASP API Güvenliği İlk 10 tehditlerini azaltmak için Öneriler

  • Makale

UYGULANANLAR: Tüm API Management katmanları

Open Web Application Security Project (OWASP) Foundation, topluluk tarafından yönetilen açık kaynak yazılım projeleri, dünya çapında yüzlerce bölüm, on binlerce üye ve yerel ve küresel konferanslar düzenleyerek yazılım güvenliğini geliştirmek için çalışır.

OWASP API Güvenlik Projesi, API'lerin benzersiz güvenlik açıklarını ve güvenlik risklerini anlamak ve azaltmak için stratejilere ve çözümlere odaklanır. Bu makalede, OWASP tarafından tanımlanan ilk 10 API tehdidini azaltmak için Azure API Management'ı kullanma önerilerini ele alacağız.

Not

Bu makaledeki önerileri izlemenin yanı sıra API güvenlik içgörüleri, öneriler ve tehdit algılama için Bulut için Microsoft Defender özelliği olan API'ler için Defender'ı etkinleştirebilirsiniz. API Management ile API'ler için Defender'ı kullanma hakkında daha fazla bilgi edinin

Bozuk nesne düzeyi yetkilendirmesi

Uygun yetkilendirme düzeyiyle korunmamış API nesneleri, zayıf nesne erişim tanımlayıcıları aracılığıyla veri sızıntılarına ve yetkisiz veri işlemeye karşı savunmasız olabilir. Örneğin, bir saldırgan yinelenebilen bir tamsayı nesne tanımlayıcısını kullanabilir.

Bu tehdit hakkında daha fazla bilgi: API1:2019 Bozuk Nesne Düzeyi Yetkilendirmesi

Öneriler

  • Nesne düzeyinde yetkilendirme uygulamak için en iyi yer arka uç API'sinin içindedir. Arka uçta, uygun olduğunda, etki alanı ve API için geçerli olan mantık kullanılarak istek (veya nesne) düzeyinde doğru yetkilendirme kararları oluşturulabilir. İstek sahibinin izinlerine ve yetkilendirmesine bağlı olarak, belirli bir isteğin yanıtta farklı ayrıntı düzeyleri oluşturabileceği senaryoları göz önünde bulundurun.

  • Güvenlik açığı bulunan geçerli bir API arka uçta değiştirilemiyorsa, API Management geri dönüş olarak kullanılabilir. Örneğin:

    • Arka uçta uygulanmadıysa nesne düzeyinde yetkilendirme uygulamak için özel bir ilke kullanın.

    • İç tanımlayıcıların kullanıma sunulmaması için, tanımlayıcıları istekten arka uça ve arka uçtan istemciye eşlemek için özel bir ilke uygulayın.

      Bu gibi durumlarda özel ilke, arama içeren bir ilke ifadesi (örneğin, sözlük) veya gönderme isteği ilkesi aracılığıyla başka bir hizmetle tümleştirme olabilir.

  • GraphQL senaryolarında, öğesini kullanarak GraphQL istek ilkesini doğrulama aracılığıyla nesne düzeyinde yetkilendirmeyi zorunlu kılınauthorize.

Bozuk kullanıcı kimlik doğrulaması

Kimlik doğrulama mekanizmaları genellikle yanlış uygulanır veya eksiktir ve saldırganların verilere erişmek için uygulama açıklarından yararlanmasına olanak sağlar.

Bu tehdit hakkında daha fazla bilgi: API2:2019 Bozuk Kullanıcı Kimlik Doğrulaması

Öneriler

Kullanıcı kimlik doğrulaması ve yetkilendirme için API Management'ı kullanın:

  • Kimlik Doğrulaması - API Management aşağıdaki kimlik doğrulama yöntemlerini destekler:

    • Temel kimlik doğrulama ilkesi - Kullanıcı adı ve parola kimlik bilgileri.

    • Abonelik anahtarı - Abonelik anahtarı, temel kimlik doğrulamasına benzer bir güvenlik düzeyi sağlar ve tek başına yeterli olmayabilir. Abonelik anahtarının gizliliği ihlal edilirse, saldırgan sisteme sınırsız erişim elde edebilir.

    • İstemci sertifikası ilkesi - İstemci sertifikalarının kullanılması temel kimlik bilgilerine veya abonelik anahtarına göre daha güvenlidir, ancak OAuth 2.0 gibi belirteç tabanlı yetkilendirme protokolleri tarafından sağlanan esnekliğe izin vermez.

  • Yetkilendirme - API Management, OAuth kimlik sağlayıcısının meta veri uç noktasından alınan bilgilere göre gelen OAuth 2.0 JWT erişim belirtecinin geçerliliğini denetlemek için JWT doğrulama ilkesini destekler. İlgili belirteç taleplerini, hedef kitleyi ve süre sonu süresini denetlemek için ilkeyi yapılandırın. OAuth 2.0 yetkilendirmesini ve Microsoft Entra Kimliğini kullanarak API'yi koruma hakkında daha fazla bilgi edinin.

Diğer öneriler:

  • Güvenliği artırmak için API Management'ta ilkeleri kullanın. Örneğin çağrı oranı sınırlaması, kimlik bilgilerini tehlikeye atmak için deneme yanılma saldırıları kullanan kötü aktörleri yavaşlatır.

  • API'ler kimlik bilgilerini veya belirteçleri korumak için TLS/SSL (aktarım güvenliği) kullanmalıdır. Kimlik bilgileri ve belirteçler sorgu parametresi olarak değil istek üst bilgilerinde gönderilmelidir.

  • API Management geliştirici portalında hesap güvenliğini artırmak için Microsoft Entra Id veya Azure Active Directory B2C'yi kimlik sağlayıcısı olarak yapılandırın. Geliştirici portalı deneme yanılma saldırılarını azaltmak için CAPTCHA kullanır.

Aşırı veri açığa çıkarma

İyi API arabirimi tasarımı aldatıcı bir şekilde zordur. Genellikle, özellikle zaman içinde gelişen eski API'lerde istek ve yanıt arabirimleri, tüketen uygulamaların gerektirdiğinden daha fazla veri alanı içerir.

Kötü bir aktör API'ye doğrudan erişmeye (belki de geçerli bir isteği yeniden yürüterek) veya sunucu ile API arasındaki trafiği algılamaya çalışabilir. API eylemlerinin ve kullanılabilir verilerin analizi, saldırgana hassas veriler verebilir ve bu veriler ön uç uygulamasına sunulmaz veya tarafından kullanılmaz.

Bu tehdit hakkında daha fazla bilgi: API3:2019 Aşırı Veri Açığa Çıkarma

Öneriler

Kaynak eksikliği ve hız sınırlama

Hız sınırlamasının olmaması, arka uç hizmetlerine veri sızdırma veya başarılı DDoS saldırılarına yol açarak tüm tüketiciler için kesintiye neden olabilir.

Bu tehdit hakkında daha fazla bilgi: API4:2019 Kaynak eksikliği ve hız sınırlama

Öneriler

  • Tüketici başına izin verilen API çağrısı veya bant genişliği sayısını denetlemek için hız sınırı (kısa vadeli) ve kota sınırı (uzun vadeli) ilkelerini kullanın.

  • OpenAPI tanımında katı istek nesnesi tanımlarını ve bunların özelliklerini tanımlayın. Örneğin, disk belleği tamsayıları için maksimum değeri, dizeler için maxLength ve normal ifadeyi (regex) tanımlayın. API Management'ta içeriği doğrulama ve parametre doğrulama ilkeleriyle bu şemaları zorunlu kılın.

  • İçerik doğrulama ilkesiyle isteğin boyut üst sınırını zorlama.

  • Yerleşik önbelleğe alma ile performansı iyileştirerek belirli işlemler için CPU, bellek ve ağ kaynaklarının tüketimini azaltabilirsiniz.

  • API çağrıları için kimlik doğrulamasını zorunlu kılma (bkz . Bozuk kullanıcı kimlik doğrulaması). Kötü amaçlı kullanıcılar için erişimi iptal etme. Örneğin, abonelik anahtarını devre dışı bırakın, arayan IP'lerini kısıtla ilkesiyle IP adresini engelleyin veya JWT belirtecinden belirli bir kullanıcı talebine yönelik istekleri reddedin.

  • API aracılığıyla sunulan kaynakları yüklemesine izin verilen web sitelerini denetlemek için bir CORS ilkesi uygulayın. Fazla izinli yapılandırmalardan kaçınmak için CORS ilkesinde joker karakter değerlerini (*) kullanmayın.

  • Arka uç hizmetinin yanıt vermesi için gereken süreyi en aza indirin. Arka uç hizmetinin yanıt vermesi ne kadar uzun sürerse, BAĞLANTı API Management'ta o kadar uzun süre meşgul olur ve bu nedenle belirli bir zaman diliminde hizmet verilebilen istek sayısını azaltır.

  • API Management arka uç hizmetlerini DDoS saldırılarına karşı koruyabilir ancak bu saldırılara karşı savunmasız olabilir. DDoS saldırılarına karşı daha iyi koruma sağlamak için API Management'ın (örneğin, Azure Uygulaması lication Gateway, Azure Front Door veya Azure DDoS Koruması) önünde bir bot koruma hizmeti dağıtın. Azure Uygulaması lication Gateway veya Azure Front Door ile WAF kullanırken Microsoft_BotManagerRuleSet_1.0 kullanmayı göz önünde bulundurun.

Bozuk işlev düzeyi yetkilendirmesi

Farklı hiyerarşilere, gruplara ve rollere sahip karmaşık erişim denetimi ilkeleri ve yönetim ve normal işlevler arasında belirsiz bir ayrım, yetkilendirme açıklarına yol açar. Saldırganlar bu sorunlardan yararlanarak diğer kullanıcıların kaynaklarına veya yönetim işlevlerine erişim elde eder.

Bu tehdit hakkında daha fazla bilgi: API5:2019 Bozuk işlev düzeyi yetkilendirmesi

Öneriler

  • Varsayılan olarak, API Management'taki tüm API uç noktalarını abonelik anahtarlarıyla koruyun.

  • Bir doğrulama JWT ilkesi tanımlayın ve gerekli belirteç taleplerini zorunlu kılın. Belirli işlemler daha katı talep zorlaması gerektiriyorsa, yalnızca bu işlemler için ek validate-jwt ilkeler tanımlayın.

  • API uç noktalarını İnternet'ten gizlemek için bir Azure sanal ağı veya Özel Bağlantı kullanın. API Management ile sanal ağ seçenekleri hakkında daha fazla bilgi edinin.

  • Joker karakter API işlemlerini tanımlamayın (yani yol olarak "tümünü yakala" API'leri*). API Management'ın yalnızca açıkça tanımlanmış uç noktalar için istekler sağladığını ve tanımsız uç noktalara yönelik isteklerin reddedildiğinden emin olun.

  • Abonelik gerektirmeyen açık ürünler içeren API'leri yayımlamayın.

Toplu atama

Bir API, istemcinin belirli bir eylem için gerektirdiğinden daha fazla alan sunuyorsa, bir saldırgan veriler üzerinde yetkisiz işlemler gerçekleştirmek için aşırı özelliklere sahip olabilir. Saldırganlar, isteklerin ve yanıtların veya diğer API'lerin biçimini inceleyerek veya bunları tahmin ederek belgelenmemiş özellikleri bulabilir. Bu güvenlik açığı özellikle kesin olarak belirlenmiş programlama dilleri kullanmıyorsanız geçerlidir.

Bu tehdit hakkında daha fazla bilgi: API6:2019 Toplu atama

Öneriler

  • Dış API arabirimleri, iç veri uygulamasından ayrılmış olmalıdır. API sözleşmelerini doğrudan arka uç hizmetlerindeki veri sözleşmelerine bağlamaktan kaçının. API tasarımını sık sık gözden geçirin ve API Management'ta sürüm oluşturma özelliğini kullanarak eski özellikleri kullanımdan kaldırın.

  • API şemasında XML ve JSON sözleşmelerini tam olarak tanımlayın ve belgelenmemiş özelliklere sahip istekleri ve yanıtları engellemek için içeriği doğrulama ve parametre ilkelerini doğrulama kullanın. Belgelenmemiş özelliklere sahip isteklerin engellenmesi saldırıları azaltırken, belgelenmemiş özelliklere sahip yanıtları engellemek olası saldırı vektörlerinin tersine mühendislik işlemini zorlaştırıyor.

  • Arka uç arabirimi değiştirilemiyorsa, istek ve yanıt yüklerini yeniden yazmak ve API sözleşmelerini arka uç sözleşmelerinden ayrıştırmak için dönüştürme ilkelerini kullanın. Örneğin, verileri maskeleyin veya filtreleyin ya da gereksiz JSON özelliklerini kaldırın.

Güvenlik yanlış yapılandırması

Saldırganlar aşağıdakiler gibi güvenlik yanlış yapılandırma güvenlik açıklarından yararlanmaya çalışabilir:

  • Güvenlik sağlamlaştırması eksik
  • Gereksiz etkinleştirilmiş özellikler
  • Ağ bağlantıları gereksiz yere İnternet'e açılır
  • Zayıf protokollerin veya şifrelerin kullanımı
  • Sisteme yetkisiz erişime izin verebilen diğer ayarlar veya uç noktalar

Bu tehdit hakkında daha fazla bilgi: API7:2019 Güvenlik yanlış yapılandırması

Öneriler

  • Ağ geçidi TLS'lerini doğru yapılandırın. Güvenlik açığı olan protokolleri (örneğin, TLS 1.0, 1.1) veya şifreleri kullanmayın.

  • API'leri, örneğin HTTPS veya WSS protokolleri aracılığıyla yalnızca şifrelenmiş trafiği kabul etmek üzere yapılandırın.

  • API Management'ı özel bir uç noktanın arkasına veya iç modda dağıtılan bir sanal ağa bağlı olarak dağıtmayı göz önünde bulundurun. İç ağlarda erişim, özel ağ içinden (güvenlik duvarı veya ağ güvenlik grupları aracılığıyla) ve İnternet'ten (ters ara sunucu aracılığıyla) denetlenebilir.

  • Azure API Management ilkelerini kullanın:

    • Üst ilkeleri her zaman etiketi aracılığıyla devralın <base> .

    • OAuth 2.0 kullanırken JWT belirtecinin arka uça ulaşmadan önce varlığını ve geçerliliğini denetlemek için JWT doğrulama ilkesini yapılandırın ve test edin. Belirteç süre sonunu, belirteç imzasını ve vereni otomatik olarak denetleyin. İlke ayarları aracılığıyla talepleri, hedef kitleleri, belirteç süre sonunu ve belirteç imzasını zorunlu kılma.

    • CORS ilkesini yapılandırın ve herhangi bir yapılandırma seçeneği için joker karakter * kullanmayın. Bunun yerine, izin verilen değerleri açıkça listeleyin.

    • JSON ve XML şemalarını, üst bilgileri, sorgu parametrelerini ve durum kodlarını doğrulamak ve istek veya yanıt için en büyük boyutu zorlamak için üretim ortamlarında doğrulama ilkelerini prevent olarak ayarlayın.

    • API Management bir ağ sınırının dışındaysa, sınırlayıcı arayan IP'leri ilkesi kullanılarak istemci IP doğrulaması hala mümkündür. Blok listesi değil, izin verilenler listesi kullandığına emin olun.

    • Çağıran ve API Management arasında istemci sertifikaları kullanılıyorsa, istemci sertifikasını doğrulama ilkesini kullanın. validate-revocation, , validate-trustvalidate-not-beforeve validate-not-after özniteliklerinin olarak ayarlandığından trueemin olun.

      • İstemci sertifikaları (karşılıklı TLS) API Management ile arka uç arasında da uygulanabilir. Arka uç şu şekilde olmalıdır:

        • Yetkilendirme kimlik bilgilerinin yapılandırılması

        • Uygun olduğunda sertifika zincirini doğrulama

        • Uygun olduğunda sertifika adını doğrulayın

  • GraphQL senaryoları için GraphQL istek ilkesini doğrulayın. öğesinin authorization ve max-size max-depth özniteliklerinin ayarlandığından emin olun.

  • Gizli dizileri ilke dosyalarında veya kaynak denetiminde depolamayın. Api Management'ın adlandırılmış değerlerini her zaman kullanın veya özel ilke ifadelerini kullanarak gizli dizileri çalışma zamanında getirin.

  • Api'leri abonelik gerektiren ürünler aracılığıyla yayımlayın. Abonelik gerektirmeyen açık ürünleri kullanmayın.

  • Tüm sertifikaları yönetmek için Key Vault tümleştirmesini kullanın. Bu, sertifika yönetimini merkezileştirir ve sertifika yenileme veya iptal gibi işlem yönetimi görevlerini kolaylaştırmaya yardımcı olabilir.

  • Şirket içinde barındırılan ağ geçidini kullanırken, görüntüyü düzenli aralıklarla en son sürüme güncelleştirme işleminin yapıldığından emin olun.

  • Arka uç hizmetlerini arka uç varlıkları olarak temsil eder. Uygun olduğunda yetkilendirme kimlik bilgilerini, sertifika zinciri doğrulamayı ve sertifika adı doğrulamayı yapılandırın.

  • Geliştirici portalını kullanırken:

    • Geliştirici portalını kendi kendine barındırmayı seçerseniz, şirket içinde barındırılan portalı düzenli aralıklarla en son sürüme güncelleştirme işleminin uygulandığından emin olun. Varsayılan yönetilen sürüm için Güncelleştirmeler otomatik olarak gerçekleştirilir.

    • Kullanıcı kaydolma ve oturum açma için Microsoft Entra Id veya Azure Active Directory B2C kullanın. Daha az güvenli olan varsayılan kullanıcı adı ve parola kimlik doğrulamasını devre dışı bırakın.

    • Portalda API'lerin görünürlüğünü denetlemek için ürünlere kullanıcı grupları atayın.

  • Kaynak erişimini denetlemek için API Management kaynak düzeyi yapılandırması ve rol tabanlı erişim denetimi (RBAC) izinlerini zorunlu kılmak için Azure İlkesi kullanın. Her kullanıcıya gereken en düşük ayrıcalıkları verin.

  • API Management içeriğinin ve yapılandırma değişikliklerinin tutarlılığını sağlamak ve insan hatalarını en aza indirmek için geliştirme ortamının dışında devOps işlemi ve kod olarak altyapı yaklaşımını kullanın.

  • Kullanım dışı bırakılan özellikleri kullanmayın.

Enjeksiyon

Kullanıcı verilerini kabul eden tüm uç noktalar ekleme açıklarına karşı savunmasızdır. Örnekler şunlardır ancak bunlarla sınırlı değildir:

Bu tehdit hakkında daha fazla bilgi: API8:2019 Ekleme

Öneriler

  • Modern Web Uygulaması Güvenlik Duvarı (WAF) ilkeleri birçok yaygın ekleme güvenlik açığını kapsar. API Management'ın yerleşik bir WAF bileşeni olmasa da, API Management örneğinin bir WAF yukarı akışının (önünde) dağıtılması kesinlikle önerilir. Örneğin, Azure Uygulaması Lication Gateway veya Azure Front Door kullanın.

    Önemli

    Kötü bir aktörün WAF'yi barındıran ağ geçidini atlayıp doğrudan API Management ağ geçidine veya arka uç API'sine bağlanadığından emin olun. Olası azaltmalar şunlardır: ağ ACL'leri, istemci IP'sine göre gelen trafiği kısıtlamak için API Management ilkesini kullanma, gerekli olmayan yerlerde genel erişimi kaldırma ve istemci sertifikası kimlik doğrulaması (karşılıklı TLS veya mTLS olarak da bilinir).

  • Arka uç API hizmetine ulaşmadan önce isteği daha fazla kısıtlamak ve doğrulamak için şema ve parametre doğrulama ilkelerini kullanın.

    API tanımıyla birlikte sağlanan şemada güvenlik açığı bulunan alanlara uygulanan bir regex desen kısıtlaması olmalıdır. Her bir regex, yaygın ekleme girişimlerini azaltmak için alanı yeterince kısıtladığından emin olmak için test edilmelidir.

Yanlış varlık yönetimi

Hatalı varlık yönetimiyle ilgili güvenlik açıkları şunlardır:

  • Uygun API belgelerinin veya sahiplik bilgilerinin olmaması

  • Güvenlik düzeltmeleri eksik olabilecek aşırı sayıda eski API sürümü

Bu tehdit hakkında daha fazla bilgi: API9:2019 Yanlış varlık yönetimi

Öneriler

  • REST API'lerini içeri aktarmak için kaynak olarak iyi tanımlanmış bir OpenAPI belirtimi kullanın. Belirtim, kendi kendine belgeleme meta verileri de dahil olmak üzere API tanımının kapsüllenmesine olanak tanır.

    • Kesin yollar, veri şemaları, üst bilgiler, sorgu parametreleri ve durum kodları ile API arabirimlerini kullanın. Joker karakter işlemlerinden kaçının. Her API ve işlem için açıklamalar sağlayın ve iletişim ve lisans bilgilerini ekleyin.

    • İş hedefine doğrudan katkıda bulunmayan uç noktalardan kaçının. Saldırı yüzeyi alanını gereksiz yere artırır ve API'yi geliştirmeyi zorlaştırır.

  • API uç noktalarını yönetmek ve denetlemek için API Management'ta düzeltmeleri ve sürümleri kullanın. Güçlü bir arka uç sürüm oluşturma stratejisine sahip olup desteklenen en fazla API sürümü sayısına (örneğin, 2 veya 3 önceki sürüm) bağlanın. Eski, genellikle daha az güvenli API sürümlerini hızla kullanımdan kaldırıp kaldırmayı planlayın.

  • Ortam başına bir API Management örneği kullanın (geliştirme, test ve üretim gibi). Her API Management örneğinin aynı ortamdaki bağımlılıklarına bağlandığından emin olun. Örneğin, test ortamında test API Management kaynağı bir test Azure Key Vault kaynağına ve arka uç hizmetlerinin test sürümlerine bağlanmalıdır. Ortamlar arasında tutarlılığı ve doğruluğu korumaya ve insan hatalarını azaltmaya yardımcı olmak için DevOps otomasyon ve kod olarak altyapı uygulamalarını kullanın.

  • API'leri ve ürünleri düzenlemek ve yayımlamak üzere gruplandırmak için etiketleri kullanın.

  • Yerleşik geliştirici portalı aracılığıyla API'leri tüketim için yayımlayın. API belgelerinin güncel olduğundan emin olun.

  • Belgelenmemiş veya yönetilmeyen API'leri bulun ve daha iyi denetim için API Management aracılığıyla kullanıma sağlanmaktadır.

Yetersiz günlüğe kaydetme ve izleme

Olay yanıtıyla eksik veya etkisiz tümleştirmeyle birlikte yetersiz günlüğe kaydetme ve izleme, saldırganların sistemlere daha fazla saldırı yapmasına, kalıcılığı sürdürmesine, üzerinde oynanacak daha fazla sistemle özetlenmesine ve verileri ayıklamasına veya yok etmesine olanak tanır. İhlal çalışmalarının çoğu, bir ihlali algılama süresinin 200 günden uzun olduğunu ve genellikle iç süreçler veya izleme yerine dış taraflar tarafından algılandığını göstermektedir.

Bu tehdit hakkında daha fazla bilgi: API10:2019 Yetersiz günlüğe kaydetme ve izleme

Öneriler

Sonraki adımlar

Aşağıdakiler hakkında daha fazla bilgi edinin: