Günümüzde makineler arasındaki çoğu API iletişimi, makinelerin kimliğini doğrulamak ve aralarındaki iletişimi sağlamak için sistem parolaları gibi davranan API sırları (statik anahtarlar, belirteçler veya PKI sertifikaları) aracılığıyla güvence altına alınmaktadır. Bu makineler bulut iş yükleri, bölmeler, kapsayıcılar, sunucular, sanal makineler, mikro hizmetler veya sunucular veya Nesnelerin İnterneti cihazları gibi fiziksel makineler olabilir.
Makineler arasında kimlik doğrulamasını güvence altına alan mevcut mekanizmalarla ilgili zorluk, hepsinin bir taşıyıcı kimlik doğrulama modeli önermesidir. Bir API anahtarı, jetonu veya sertifikası geçerli olduğu sürece, herhangi bir yerden, hatta hain bir makineden bile tutulabilir ve kullanılabilir. Model, API istemcisinde güvenilir erişimi veya güveni garanti etmez. Riske ek olarak, bu API sırlarının genellikle uzun ömürlü olması ve çevrede hijyen sağlamak için külfetli olmasıdır.
Mükemmel güvenlik hijyeni, her bir API sırrının yalnızca tek bir makineye atandığı, asla paylaşılmadığı ve rutin olarak döndürüldüğü anlamına gelir. ve geliştirme ve devreye alma sistemleri aracılığıyla, ihtiyaç duyan makineye yol boyunca sızdırılma riski olmadan güvenli bir şekilde dağıtılır. Gerçek şu ki, API sırları genellikle düzinelerce veya yüzlerce makine ve iş yükü arasında paylaşılır. Nadiren rotasyona tabi tutulurlar ve farklı uygulamalar ve ortamlarda gizli dizilerin sağlanması ve yönetilmesi zorlu bir iştir.
Sırların Maliyeti
göre bir 2021 raporu 1Password ile BT ve DevOps, ABD’deki şirketler genelinde yıllık tahmini 8,5 milyar dolarlık bordro gideriyle sırları yönetmek için her gün ortalama 25 dakika harcıyor. Geliştirme ve devreye alma sistemlerinin tamamen otomatik hale getirildiği bir dünyada, sır sağlama ve döndürme, çok manuel ve zahmetli bir süreç olmaya devam ediyor.
Sızan altyapı sırlarının ölçülebilir bir maliyeti vardır. Açık kod, kimlik bilgileri1Password raporuna göre , ve anahtarlar – ister yanlışlıkla ister kasıtlı olarak açığa çıksınlar – şirketlere yılda ortalama 1,2 milyon dolar gelire mal oluyor.
Daha yakın zamanlarda, API sırlarının statik doğası, onları rakipler için olgunlaşmış hedefler haline getirdi. Parolalar gibi, sırlar da eskidikçe daha savunmasız hale gelme eğilimindedir – bu yalnızca bu sırlar düzinelerce, bazen yüzlerce farklı iş yükü arasında paylaşıldığında daha da karmaşık hale gelen bir sorundur. Bugün, kod havuzlarında, Jenkins veya Travis gibi sürekli entegrasyon (CI) sistemlerinde, Kubernetes gibi düzenleme araçlarında ve Amazon Web Services (AWS), Google Cloud Platform (GCP) gibi bulut barındırma ortamlarında sırlar endişe verici bir oranda sızdırılıyor. Microsoft Azure. Splunk ve Elastic gibi günlüğe kaydetme araçları ve hatta Slack gibi işbirliği ortamları için de aynısı. Yakın tarihli bir araştırmaya göre, kuruluşlar 2021’de 6 milyondan fazla şifre, API anahtarı ve diğer hassas verileri sızdırarak önceki yıla göre iki katına çıktı. GitGuardian incelemesi.
İşleri İyileştirmeye Yönelik Araçlar
Kuruluşlar, sırlarını daha güvende tutmak için ekstra adımlar atabilir. Kasalar veya sır yöneticileri gibi sır yönetimi çözümleri, bu sistem parolalarının düzenlenmesine ve daha iyi güvenlik altına alınmasına yardımcı olur. Ancak kuruluşunuz üç bulut sağlayıcısının tümü ile iş yükleri çalıştırıyorsa, ekibinizin bu sırları korumak için üç özel sır yönetimi sisteminden (Azure Key Vault, AWS Secrets Manager ve GCP için Secret Manager) yararlanması gerekecektir.
Kaynak kodunda, kod havuzlarında, CI ortamlarında ve kayıt sistemlerinde sabit kodlanmış sırları bulmak için ortamlarınızı tarayabilen araçlar mevcuttur. Bazı araçlar, halihazırda açığa çıkmış olabilecek sırlar için genel kişisel ve kuruluş havuzlarını da tarayabilir.
Dayanılmaz Bir Yük
Birçok mühendislik ve güvenlik ekibi için önemli bir kör nokta, API sırlarından yararlanan makinelerin, uygulamaların, hizmetlerin veya iş yüklerinin kimliklerini görebilmektir. Bu noktaya kadar zaten kırılmadıysa, bu, taşıyıcı modelin bozulmaya başladığı nokta olur.
Sır yönetiminin manuel doğası, bu statik değerlerin güvenlik açığı ve API kullanımındaki patlamanın tehlikeye atılan anahtarların, belirteçlerin ve sertifikaların miktarını önemli ölçüde artırması arasında, API sırlarından yararlanan varlıklara ilişkin görünürlüğün olmaması taşıyıcı modeli savunulamaz. CISA’nın sıfır güven çerçevesi ve NIST 800-207 Kullanıcının bir insan değil, başka bir uygulama veya hizmet hesabı olduğu durumlarda, kuruluşların makineler ve iş yükleri hakkında kişi olmayan varlıklar olarak nasıl düşündüklerine ilişkin yönergeler sağlayın.
CISA ve NIST yönergeleri, kuruluşlara kimlik ve erişimi ele alma konusunda yardımcı olurken, bu sorunun çözümü insandan makineye etkileşimler için zaten oluşturulmuştur: çok faktörlü kimlik doğrulama (MFA). İnsan kullanıcıların eriştiği uygulamalar ve hizmetlerle ilgili olarak MFA’nın doğuşunu düşünürsek, amaç, kullanıcı kimliğini bir dizi kimlik bilgisi ile doğrulamaktır. Pek çok şirket, kullanıcı kimlik bilgilerinin ele geçirilmesi ihtimaline karşı, CRM uygulamasına kullanıcı adı ve parolasıyla erişmeye çalışan kişinin gerçekten Jane olduğundan emin olmak için çalışanlarından MFA’yı etkinleştirmesini ister. Parolaların statik doğası, çoğu güvenlik yönergesini ne kadar eskittikleriyle birleştiğinde, onları düşmanlar için olgun hedefler haline getirir; bu nedenle birçok kuruluş, hassas veriler içeren uygulamalara erişim için MFA’yı zorunlu kılar.
Taşıyıcı model farklı değildir — anahtarlar, belirteçler ve sertifikalar, sistem parolası görevi gören statik değerlerdir. Pek çok kuruluşun karşılaştığı zorluk, nihayetinde bu kimlik bilgilerinden yararlanan makinelerin, uygulamaların, iş yüklerinin veya hizmetlerin kimliklerini görebilmektir.
