Üçüncü Taraf API Güvenliğini Üç Özel Kullanım Durumuna Uyarlayın


YORUM

API güvenliği genellikle birinci taraf yerine üçüncü taraf API’leri içerir ve her kullanım durumunun farklı gereksinimleri olabilir. Güvenlik ve risk yönetimi liderleri, tek bir teknolojik yaklaşımın tüm örneklerde işe yaramasını sağlamak yerine, yaklaşımlarını belirli kullanım senaryosuna uyarlamalıdır.

Bir göre son Gartner araştırmasıBT liderlerinin %71’i kuruluşlarında üçüncü taraf uygulama programlama arayüzlerini (API’ler) kullandıklarını bildiriyor. Güvenlik ve risk yönetimi liderlerinin çoğu, birinci taraf API’lerin açığa çıkması yerine, üçüncü taraf API’lerin tüketimi ve entegrasyonu ile uğraşırken API güvenliğine odaklanmalıdır.

Ayrıca, üçüncü taraf API’ler söz konusu olduğunda, risklere karşı yama uygulanması gibi pek çok düzeltme önlemi kuruluşun doğrudan kontrolü altında değildir. Bu nedenle yaklaşımın birinci taraf API’lerle karşılaştırıldığında temel olarak farklı olması gerekecektir.

Bu güvenlik liderlerinin akıllarında üç kullanım durumu olmalıdır.

Kullanım Senaryosu 1: Üçüncü Taraf API’lere Giden Veri Akışlarını Keşfedin ve Yönetin

Bu ilk kullanım durumunda kuruluş, verileri üçüncü taraflara API’ler aracılığıyla, genellikle bunları kendi geliştirdiği uygulamalardan çağırarak gönderir. Örneğin bir e-ticaret senaryosunda API’yi sağlayan hizmet bir ödeme ağ geçidi olabilir. Bu örnekte giden trafik, bir ödemeyi işlemek için kullanılan ödeme verilerini içerecektir. API’yi uygulama içinden çağırmanın doğrudan entegrasyon, bir yazılım geliştirme kiti veya web kancası kullanma gibi farklı yolları vardır.

Ana risk, hassas verilerin API’ye gönderilebilmesidir. Bu aktivite kurumsal politikalar veya sektör düzenlemeleriyle çelişebilir. Üçüncü taraf API’ler ayrıca verileri veya müşterilerin verilerini tehlikeye atabilir. Örneğin bir saldırgan, güvenlik açığı bulunan bir ödeme API’sini kullanarak müşterilerden ödeme verilerini çalabilir. Senaryoya bağlı olarak, kötü amaçlı bir verinin enjekte edilmesi iş ortağının veritabanını da bozabilir.

Bu senaryoda, belirli üçüncü taraf API’ler kendi geliştirdiği kod yerine üçüncü taraf kitaplıkları aracılığıyla çağrılabileceğinden, güvenlik liderleri trafik denetimi, kod deposu incelemesi ve yazılım bileşimi analizi gerçekleştirerek üçüncü taraf API’leri keşfetmelidir.

Güvenlik liderleri ayrıca, hizmet olarak yazılım (SaaS) uygulamalarının incelendiğinden ve kurumsal politikalara uygun olduğundan emin olmak için kaynak bulma, satın alma ve satıcı yönetimini (SPVM) ve üçüncü taraf siber riskini yöneten ekiple birlikte hareket etmelidir.

Güvenlik liderleri aynı zamanda bu API alışverişlerinde giden trafiği izleyerek hassas veri sızıntılarını da tanımlamalıdır. Bu genellikle veri kaybı önleme (DLP) yeteneklerinin uygulanmasıyla gerçekleştirilir. Farklı araçlar geçerli olabilir; örneğin, güvenlik hizmeti uç noktası (SSE), DLP ve API koruma araçlarının tümü belirli DLP özelliklerine sahiptir.

  • Farklılaştırıcı unsurlar arasında, aracın aktarım sırasında (“anında”) verileri kategorilere ayırıp sınıflandıramayacağı veya veri değişimini engelleme, anonimleştirme veya verileri şifreleme gibi iyileştirme eylemleri gerçekleştirip gerçekleştiremeyeceği yer alabilir.

  • Bazı araçlar halihazırda kurulu olabileceğinden veya şifrelenmemiş trafiğe erişime sahip olabileceğinden, izleme noktası da önemli olabilir.

  • En önemlisi, güvenlik liderlerinin bir aracı yapılandırma şekli önemlidir. Bir tıkanıklık noktası görevi görecek şekilde ayarlanmışsa, örneğin yalnızca belirli trafik türlerini veya gelen trafiği işlemek üzere yapılandırılmış bir araçtan daha iyi bir seçenek olabilir.

  • Her bir araca hangi ekibin sahip olduğu ve işlettiği gibi dahili hususlar da hangi aracın seçileceğinin belirlenmesinde rol oynayacaktır.

Son olarak güvenlik liderleri, API sağlayıcısı tarafından sunulan mekanizmaları kullanarak API istemcisinin (bu senaryoda uygulama) uygun kimlik doğrulamasını ve yetkilendirmesini uygulayabilir. Yetkilendirme için en azından API anahtarları yerine tokenları tercih edin. Opak ve sahiplik kanıtı belirteçlerinin (veya en azından sık sık döndürülen erişim kimlik bilgilerinin) ve sertifika sabitlemenin, belirli kullanım durumlarında belirteç sızıntısını ve müdahale risklerini nasıl etkili bir şekilde azaltabileceğini değerlendirin. Bunları kurmak için gerekebilecek teknik yüklere ve trafik denetimiyle ilgili sorunlara dikkat edin.

Kullanım Örneği 2: Üçüncü Taraf API’lerden Gelen Trafiğe Karşı Koruyun

Bu kullanım durumunda kuruluş üçüncü taraf API’yi kullanır ve veriler gelir. Tipik bir örnek, ticari bir SaaS sağlayıcısından veya iş ortağından veri almak için API çağrısı yapan kurumsal bir uygulama olabilir.

Bu kullanım örneğindeki risklerden biri, API’den zararlı olabilecek girdiler alınmasıdır. Üçüncü taraf API’lerden gelen kötü amaçlı girdiler, uygulamaları, kullanıcılarını veya altyapı barındırma uygulamalarını tehlikeye atabilir. Örneğin, kötü amaçlı bir veri içeren bir API yanıtı bir veritabanına gönderilirse, bu bir enjeksiyon saldırısına neden olabilir.

Veri sızması bu kullanım durumu için hala bir risktir ve ilk kullanım senaryosundaki tavsiyelerin çoğu burada da geçerlidir. Giden API isteği hassas veriler içeriyorsa bu verilere müdahale edilebilir. Örneğin, bir API çağrısı GPS koordinatlarına dayalı olarak restoranların bir listesini isterse, bağlantı güvenli değilse söz konusu GPS koordinatlarına müdahale edilebilir. En önemlisi, üçüncü taraf API, kuruluşun belirli verilerini getiriyor olabilir. (Örneğin, bir CRM SaaS uygulamasının belirli örneklerinden müşteriler hakkında veri getiren bir API’yi düşünün.)

Güvenlik liderleri giriş doğrulama işlemini gerçekleştirmelidir. Geliştiricilerden, üçüncü taraf API’lerden gelen girişler de dahil olmak üzere herhangi bir girişi alırken giriş doğrulama kontrolleri eklemelerini isteyin. Bu, SQL enjeksiyon saldırıları gibi kötü niyetli girdilerden kaynaklanan geniş bir yelpazedeki saldırıları önleyecektir. Uygulama güvenliği testi (AST) araçları bu kontrollerin otomatikleştirilmesine yardımcı olabilir.

Enjeksiyon saldırılarına ve diğer kötü amaçlı giriş türlerine karşı beklenmedik durumlar eklemek için bir Web uygulamasındaki Web uygulaması güvenlik duvarı işlevini ve API koruma aracını hat üzerinde kullanın.

Son olarak, uygulamaları genellikle İnternet içerik uyarlama protokolü veya API’ler aracılığıyla bu araçların bir veya daha fazlasıyla entegre ederek bir antivirüs, korumalı alan oluşturma veya içerik devre dışı bırakma ve yeniden yapılandırma çözümüyle girişi inceleyin.

Kullanım Senaryosu 3: API’ler Aracılığıyla İletişim Kuran Üçüncü Taraf Uygulamalara İlişkin Verileri Keşfedin, İnceleyin ve Yönetin

Birçok güvenlik lideri API güvenliğine odaklanıyor ancak bir veya daha fazla SaaS uygulamasının genellikle API’ler aracılığıyla iletişim kurarak kurumsal veri alışverişinde bulunduğu bir senaryoyu tanımlıyor. Kullanıcılar yönetim ayrıcalıklarına sahip olmadan SaaS uygulamalarını birbirine bağlayabildiğinden bu sorun daha da kötüleşebilir. Temel iletişim API tabanlı olsa da bu sorunun çözümü SaaS güvenliğine yönelik en iyi uygulamalara daha yakındır.

Bu durum, yetkili bir SaaS uygulaması kullanıcısı onu API aracılığıyla yetkisiz bir SaaS uygulamasına bağladığında özellikle zorlayıcı olur. Pek çok kuruluş, bırakın bağlantı üzerinden veri aktarımını, bağlantının varlığına dair çok az görünürlüğe sahip olacak veya hiç görünmeyecek. İkincisi, hat içi kontrolün yerleştirileceği net bir yer olmadığından görünürlük, SaaS sağlayıcılarının kendi yönetim API’leri aracılığıyla ortaya çıkardıklarıyla sınırlıdır. Bu senaryodaki ana risk, SaaS uygulamasının hassas kurumsal verileri API aracılığıyla açığa çıkarabilmesi ve bu verilerin, güvenliğin incelemediği, onaylanmamış ve hatta bilinmeyen bir konuma aktarılabilmesidir.

Güvenlik liderleri bir sayım gerçekleştirerek, bir politika yayınlayarak ve trafiği denetleyerek kullanılan SaaS uygulamalarını keşfetmelidir. Kullanıcıların eriştiği SaaS uygulamalarını, özellikle de hassas verileri barındıranları belirlemek için SSE, güvenlik duvarları, SaaS yönetim platformları veya diğer araçları kullanın. Kullanıcıların hangi uygulamalara eriştiğini bilene kadar SaaS’tan SaaS’a bağlantıyı kontrol edemezler

Desteklendiği yerlerde kullanılan SaaS uygulamalarını sorgulayarak hileli SaaS erişim belirteçlerini keşfedin. Kullanıcılara, SaaS uygulamalarının OAuth aracılığıyla bağlanmasına ilişkin politika oluşturun ve tanıtın.

Önceki kullanım örnekleri için, SaaS uygulamalarının incelendiğinden ve veri güvenliği ve üçüncü taraf paylaşım politikaları gibi kurumsal politikalara uygun olduğundan emin olmak için SPVM’yi ve üçüncü taraf siber riskini yöneten ekiple irtibat kurun. Ayrıca SaaS’tan SaaS’a ara bağlantıların envanteri; SSPM teklifleri gibi otomatik araçlar bunun sürekli bir süreç olmasını sağlamaya yardımcı olabilir.

Güvenlik liderleri, yaklaşımlarını bu üç spesifik kullanım senaryosuna ve bunların olası varyasyonlarına uyarlayarak, üçüncü taraf API’lerin kuruluşları için sunduğu riskleri ortadan kaldırabilir.





Source link