Yönetilmeyen ve ifşa edilen insan olmayan kimlikler (NHI’ler) veya makineden makineye kimlik bilgileri (hizmet hesapları, sistem hesapları, sertifikalar ve API anahtarları gibi) etrafındaki abartı son zamanlarda fırladı. NHI ile ilgili ihlallerin istikrarlı akışı, NHI riski etrafındaki bazı dedikoduların FUD’ye (korku, belirsizlik ve şüphe) doğru kaymasına neden oluyor. NHI’lerin insan kimliklerini geride bırakma oranı göz önüne alındığında (bazı raporlara göre 45’e 1’e kadar) bu abartı haklı görünüyor. Ancak FUD haklı değil.
Hiç şüphe yok ki, NHI’lar ciddi bir risk vektörüdür. Ancak bu riski yönetmek ve bunu uzun vadede yapmak için uygun bir yönetişim uygulamak mümkündür. Ve unutmayalım ki, insan kimliği yönetimi asla parkta yürüyüş yapmak gibi olmamıştır: IAM araçlarının olgunlaşması onlarca yıl sürmüştür. Şirketlerin insan kimliklerini kavramasının aldığı zamanla karşılaştırıldığında, makine kimliklerini yönetme konusunda çok daha ilerideyiz.
Bununla birlikte, insan olmayan kimlikleri kullanan saldırıları engellemenin ilk adımı, kuruluşunuzdaki tüm kimlikleri, insan ve insan olmayanları envanterlemektir. Göremediğiniz şeyi güvence altına alamazsınız ve NHI’ler söz konusu olduğunda bu kesin bir gerçektir. NHI’ler genellikle uygulamalar genelinde hassas verilere ve hizmetlere erişmek için kullanıldığından, ifşa edilmiş, yönetilmeyen NHI’lerin yayılmasına izin vermek, evinizden çıktığınızda tüm kapılarınızı ve pencerelerinizi açık bırakmaya benzer. Saldırganları bir fincan çay içmeye davet edebilirsiniz.
NHI riski: “Tipik” bir senaryo
Kuruluşunuzun Github deposuna üçüncü taraf (SaaS) entegrasyonu bağlayan bir geliştiriciyi veya Google Drive’ınıza erişim izni verilen bir üretkenlik aracını düşünün. Bu durumlarda, insan kullanıcı adına erişimi devreden yeni bir NHI (erişim belirteci biçiminde) oluşturulmuş olurdu. CISO’ların bundan haberi olmaz.
Şimdi bu üçüncü taraf sağlayıcının bir veri ihlali yaşadığını ve bu erişim belirteçlerinin çalındığını hayal edin. Tehdit aktörü artık erişimi veren çalışan adına Github veya Google Drive’ınıza bağlanabilir ve tüm kodunuzu veya belgelerinizi sızdırabilir. Elbette, bazı erişim belirteçleri kısa ömürlüdür (yani, birkaç saat veya gün geçerlidir), ancak bazıları değildir ve CISO’ların bunlar üzerinde hiçbir kontrolü yoktur. Belirtecin ne kadar süreyle geçerli olduğuna karar vermek üçüncü taraf sağlayıcıya (örneğin, Github) kalmıştır.
Bu nedenle, üçüncü taraf bir sağlayıcı ihlal edildiğinde maruziyetinizin bilinmesi hayati önem taşır. Tehdit aktörlerinin çalınan kimlik bilgilerini kullanmasını önlemek için belirli kullanıcılar veya hizmetler için erişimi iptal edebilirsiniz, ancak üretim sistemlerini kırma riskiniz vardır (örneğin, Github belirteçlerini iptal etmek CI/CD boru hatlarınızı bozabilir) ve dolaşımda olan erişim belirteçlerinin çokluğu göz önüne alındığında, en iyi oyuncular bile bir tanesini kaçırabilir.
Neyin tehlikeye atıldığını bilmek ve bu erişim belirteçlerini iptal etmek – hepsini, ama sadece onları – kuruluşunuzun hem güvenli hem de işlevsel kalmasını sağlamak için önemlidir. Elbette, birden fazla bulut sağlayıcısı veya üçüncü taraf SaaS kullanıldığında böyle bir envanteri tutmak katlanarak zorlaşır, çünkü her biri farklı kimlik doğrulama mekanizmaları kullanabilir.
NHI istismarlarını önlemenin anahtarı anormallik tespitidir
Tam ve doğru bir envanterden sonraki adım, çalışma zamanında NHI anomalilerini izlemeye geçmektir.
İnsan kimlikleri için bunu yapan sistemlerimiz zaten var (“John” Pazar günü sabah 2’de Kuzey Kore’den mi bağlanıyor?), ancak NHI’lar için pek de öyle değil. NHI riskini kontrol altında tutmak için NHI anormalliklerini tespit edebilen sistemlere ihtiyacımız var. Aksi takdirde, bunların tehlikeye atılıp atılmadığını bilmenin bir yolu yok.
Bu yeteneğin henüz her yerde bulunmaması, NHI’leri bu kadar “verimli” bir saldırı vektörü yapan şeydir. Tehlikeye atılan NHI’leri tespit etmek zordur (saldırgan doğru kimlik bilgilerini kullanıyordu, bu nedenle hiçbir olay kaydedilmedi), çok büyük bir patlama yarıçapına sahiptir (büyük miktarda hassas veriyi kolayca/sessizce sızdırır) ve genellikle güvenlik ekipleri için kör bir noktadır. Ayrıca, iki faktörlü kimlik doğrulamasıyla güvence altına alınmaları imkansızdır, bu da onları ideal hedefler haline getirir.
Örneğin, bir tehdit aktörünün bulutta çalışan konteynerlerinizden (uygulamalarınızdan) birine bir şekilde erişim sağladığını ve uygulamanın bir S3 kovasına bağlanmak için kullandığı bir erişim belirtecini çıkardığını varsayalım. Tehdit aktörü daha sonra verileri sızdırmak için bu kovaya kuruluşun dışından bağlanmayı deneyebilir. Bu erişim belirtecini “yanlış konumdan” kullanmak kırmızı alarma neden olmalı ve belirteci derhal iptal etmek için işlem yapılmalıdır.
Aynısı, kuruluşunuz içinden bu S3 kovasına bağlanmak için de geçerlidir, ancak farklı bir uygulamadan: her uygulama özel, kısa ömürlü bir erişim belirteci kullanmalıdır. NHI riskini gerçekten ve etkili bir şekilde yönetmek için, şirketlerin tüm NHI yaşam döngüsünü kapsayan kapsamlı bir NHI yönetim programı oluşturması gerekecektir.
Bu nasıl görünüyor? Yüksek seviyede, bunu yapmanın süreci şu şekildedir:
1) NHI envanterlerinin oluşturulması
2) NHI ve sırların yayılmasını kontrol altına alın
3) Bulut ortamlarında temel kimlikler ve roller
4) Anormallikler açısından sürekli olarak izlenmesi
Hangi araçları kullanırsanız kullanın, NHI riskini azaltmak için sürdürülebilir bir protokol oluşturmanın adımları şunlardır. Karmaşık bir çabadır, ancak yönetişim süreci yeterince basittir ve bunu başarmak için gereken araç setleri NHI FUD’un garanti edilmeyeceği kadar yeteneklidir.