Kariyerlerinin bir noktasında, herkes muhtemelen bir organizasyonda kimin kime rapor verdiğini tanımlayan operasyonel hiyerarşi şemalarından birini görmüştür. Bazen sadece aradı kuruluş şeması, insanlara kendileri için kimin çalıştığını ve patronlarının kim olduğunu bildirmek için yararlı bir araçtır. Örneğin, tipik bir kuruluş şemasında, bir kodlama grubunun başkanı, ürün geliştirme müdürüne rapor verebilir, o da inovasyondan sorumlu başkan yardımcısına rapor verebilir. Kim bu çizelgelerden birine bakmadı ki, kendi küçük bloğunu içeride bir yere yerleştirmeyi denemek ve bulmak için?
İşletmenin büyüklüğünden veya diğer faktörlerden bağımsız olarak hemen hemen her organizasyon şemasında ortak olan bir şey vardır. Çoğunlukla, bu çizelgelerdeki tüm yapı taşları insanları veya insan gruplarını temsil eder. Makinelerin insanları denetleyebileceği noktada değiliz, bu nedenle şimdilik kuruluş şemaları yalnızca insan işidir. Ancak yazılımımızın da bir organizasyon hiyerarşisine ihtiyacı var mı?
Tabii ki şirket organizasyon şemalarımıza yazılım eklememizi önermiyorum. Kimse patron için bir uygulamaya sahip olmak istemez. Onlardan nasıl zam isteyeceksin? Bununla birlikte, sıkı bir hiyerarşi içinde uygulamalarımızın ve yazılımlarımızın sorumluluklarını tanımlamaya yardımcı olarak ve bu politikaları en az ayrıcalıkla uygulayarak, onlara karşı dizilmiş yıkıcı derecede zorlu tehdit ortamına rağmen uygulamalarımızın ve yazılımlarımızın da hayatta kalmasını ve gelişmesini sağlayabiliriz.
Uygulamalara ve Yazılımlara Yönelik Saldırılar Tüm Zamanların En Yüksek Seviyesine Ulaşıyor
Bugünlerde saldırganlar ve onlar için çalışan robotlar ve otomasyona dayalı yazılımlar, savunmada istismar edilecek herhangi bir kayma olup olmadığını sürekli olarak tarıyor. Tüm yazılımlar hedef alınırken, en çok zarar veren saldırılar uygulama programlama arayüzlerine veya API’lere yapılıyor. Genellikle esnek ve benzersizdirler ve hatta bazen geliştirme sürecinde ihtiyaç duyulduğunda anında oluşturulurlar.
API’ler kesinlikle esnektir, ancak aynı zamanda genellikle aşırı izin verilmiş işlevleri için. Geliştiriciler, örneğin yönetmeye yardımcı oldukları program gelişmeye ve değişmeye devam ederken bile çalışmaya devam edebilmeleri için onlara birçok izin verme eğilimindedir. Ancak bu, bir saldırganın bunları tehlikeye atması durumunda, örneğin belirli bir veritabanının bir parçası gibi yalnızca erişim haklarından çok daha fazlasını elde ettikleri anlamına gelir. Hatta tüm ağın yöneticiye yakın haklarını bile ele geçirebilirler.
Pek çok güvenlik araştırması şirketinin, günümüzde kimlik bilgilerini çalma saldırılarının ezici çoğunluğunun API’ler gibi yazılımlara karşı yapıldığını söylemesi şaşırtıcı değil. Akamai bu sayıyı toplamın %75’iGartner da bunu söylerken API’leri içeren güvenlik açıkları en sık saldırı vektörü haline gelmiştir. Ve en son Salt Labs raporu, API’lere yönelik saldırıları gösteriyor neredeyse %700 artıyor geçen yıl ile karşılaştırıldığında.
Yazılım için Kuruluş Şeması Oluşturma
Kuruluşların kimlik bilgilerini çalma tehditlerine karşı savaşma yollarından biri, ağlarında en az ayrıcalık ve hatta sıfır güven uygulamaktır. Bu, kullanıcıları görevlerini yerine getirmek için zar zor yeterli izin almakla sınırlar. Bu erişim genellikle zaman ve yer gibi faktörlerle daha da kısıtlanır. Bu şekilde, bir kimlik bilgisi çalma saldırısı başarılı olsa bile, saldırganın yalnızca kısa bir süre için sınırlı işlevleri gerçekleştirme iznine sahip olacağından, saldırgana pek bir faydası olmaz.
En az ayrıcalık iyi bir savunmadır, ancak normalde yalnızca insan kullanıcılara uygulanır. API’lerin ayrıca yüksek ayrıcalıklara sahip olduğunu unutma eğilimindeyiz, ancak çoğu zaman neredeyse denetimli değil. nedenlerinden biri de budur bozuk erişim kontrolü Open Web Application Security Project’e (OWASP) göre artık bir numaralı halk düşmanı.
Bu kritik sorunun çözümünün, yazılıma en az ayrıcalık uygulamak olduğunu söylemek kolay. Ama uygulanması çok daha zor. İlk olarak, geliştiricilerin tehlikelerden haberdar edilmesi gerekir. Daha sonra, API’ler ve diğer yazılımlar ya resmi olarak yerleştirilmeli ya da en azından ağ içinde yer alacağı bir kuruluş şemasının parçası olarak düşünülmelidir. Örneğin, bir API’nin rezervasyon uygulamasının bir parçası olarak gerçek zamanlı uçuş verilerini alması gerekiyorsa, bunun maaş bordrosu veya finans sistemleriyle de bağlantı kurabilmesi için hiçbir neden yoktur. Yazılım kuruluş şemasında, bu sistemleri birbirine bağlayan doğrudan veya hatta noktalı çizgiler olmayacaktır.
Geliştiricilerin, kuruluşlarında çalışan binlerce hatta milyonlarca API’yi gösteren bir kuruluş şeması oluşturması muhtemelen gerçekçi değildir. Ancak, oluşturdukları tehlikenin farkında olmak ve izinlerini sadece işlerini yapmak için ihtiyaç duydukları şeylerle sınırlamak, bugünlerde herkesin karşı karşıya olduğu yaygın kimlik bilgilerini çalma saldırılarını durdurmak için uzun bir yol kat edecektir. Farkındalıkla başlar ve API’leri ve yazılımları insan kullanıcılarla aynı dikkatle ele almakla sona erer.