Varlık envanteri ve kapsama güveni

Bir elektronik tabloda yüz IP adresinin bulunması, yüz varlığın güvenilir biçimde bilindiği anlamına gelmez. Bazı adresler artık kullanılmıyor olabilir; bazıları bulutta yeni bir sisteme atanmış olabilir; tek bir adresin arkasında birden fazla uygulama veya müşteri bulunabilir. Tarama öncesinde yapılması gereken iş, ham hedef listesini sahibi ve bağlamı doğrulanmış varlık kapsamına dönüştürmektir.

Varlık ile adres aynı şey değildir

Varlık; kurum için işlev veya değer taşıyan sistem, uygulama, cihaz, servis ya da veri bileşenidir. IP adresi ve hostname bu varlığa ulaşmak için kullanılan teknik tanımlayıcılardır. Teknik tanımlayıcılar değişebilir; varlığın sahipliği ve işlevi ise güvenlik kararının bağlamını oluşturur.

Örneğin 10.20.30.12 bugün eğitim web sunucusuna atanmış olabilir. VM silinip adres havuza döndüğünde aynı adres yarın farklı bir sisteme verilebilir. Bir ay önce onaylanan IP listesini bugün doğrudan taramak, yetki sınırının değişmiş olabileceğini görmezden gelmektir.

Asgari varlık kaydı

Tarama için kullanılacak envanter, her hedefte şu alanları taşımalıdır:

• Varlık kimliği: Kurum içindeki değişmeyen veya yönetilen kayıt numarası.
• IP ve hostname: Taramada kullanılacak teknik hedefler ve çözüm zamanı.
• Sahip: İş kararını verecek kişi ile teknik operasyon irtibatı.
• Ortam: Üretim, test, geliştirme veya izole laboratuvar.
• İşlev ve kritiklik: Sistemin hangi hizmeti desteklediği ve kesintinin etkisi.
• Beklenen servisler: Normalde açık olması gereken portlar ve uygulamalar.
• Erişim yolu: İnternet, iç ağ, VPN, yönetim ağı veya yalnız yerel erişim.
• Bağımlılıklar: CDN, SaaS, yük dengeleyici, paylaşılan veritabanı veya üçüncü taraf hizmet.
• Bakım penceresi: Güvenli tarama ve olası düzeltme için uygun zaman.

“Beklenen servisler” alanı keşif sonucunu değerlendirmede özellikle değerlidir. Bir web sunucusunda 443/tcp beklenirken yeni açılmış 22/tcp, otomatik olarak zafiyet değildir. Fakat envanterle gözlem arasında araştırılması gereken bir sapmadır. Aynı şekilde beklenen bir servisin görünmemesi; firewall değişikliği, servis kesintisi veya yanlış hedef ihtimalini düşündürür.

Teknik kimliği nasıl doğrularız?

Doğrulama, mümkün olduğunca pasif ve düşük etkili kaynaklarla başlamalıdır. CMDB veya bulut envanteri, DNS kayıtları, DHCP/IPAM bilgisi, sistem sahibinin kaydı ve değişiklik yönetimi kayıtları karşılaştırılır. Amaç tek bir kaynağa körü körüne güvenmek değil, çelişkileri görünür kılmaktır.

Hostname kullanıldığında çözülen IP ve kontrol zamanı kaydedilir. Bir hostname birden fazla adrese çözülüyorsa her adresin yetki kapsamında olup olmadığı ayrıca doğrulanır. IP kullanıldığında da ters DNS tek başına sahiplik kanıtı sayılmaz. NAT, CDN ve load balancer katmanlarında görünen adres gerçek uygulama sunucusundan veya kurumun sahip olduğu sistemden farklı olabilir.

Bulut varlıklarında hesap, proje/subscription ve region bilgisi; container veya serverless yapılarda ise kısa ömürlü instance yerine hizmet kimliği önem kazanır. Paylaşılan altyapıda yalnız kendi tenant'ına ait uygulama katmanı yetkilendirilmiş olabilir; altyapı sağlayıcının ağı kapsam dışıdır.

Kapsam güven durumları

Her hedefi ikili “var/yok” yerine dört net durumla yönetmek faydalıdır:

• Doğrulandı: Sahiplik, ortam ve yetki günceldir; hedef tarama dosyasına girebilir.
• Koşullu: Hedef kapsam içindedir fakat yalnız belirli saat, port, yöntem veya kaynak IP için izinlidir.
• Kapsam dışı: Üçüncü taraf, kritik istisna veya açıkça hariç tutulan sistemdir.
• Belirsiz: Sahiplik, IP eşleşmesi ya da izin henüz doğrulanmamıştır; taranmaz.

Belirsiz hedefi dışarıda bırakmak görünürlüğü azaltıyormuş gibi gelebilir. Aslında bu, yanlış sisteme trafik gönderme riskini azaltan bilinçli bir kontroldür. Belirsizlik ayrı bir iş maddesi olarak sistem sahibine taşınır ve çözüldüğünde kapsamın yeni sürümüne eklenir.

Envanter değişimi de bir güvenlik sinyalidir

Envanter yalnız tarama öncesinde doldurulan statik bir tablo değildir. Yeni bir internet adresi, beklenmeyen hostname, sahibi değişen bir uygulama veya kaldırıldığı sanılan fakat hâlâ yanıt veren bir sistem; ayrıca araştırılması gereken değişiklik sinyalidir. Değişikliğin onaylı bir deployment ya da migration kaydıyla açıklanması gerekir.

Bu nedenle keşif sonucu mevcut envanterin üzerine sessizce yazılmaz. “Beklenen durum” ile “gözlenen durum” ayrı tutulur ve fark kaydı üretilir. Böylece yanlış bir discovery sonucu güvenilir envanteri bozmaz; gerçek ve yetkisiz bir değişiklik de normal kabul edilerek kaybolmaz. Sistem sahibi farkı doğruladıktan sonra envanterin yeni sürümü yayınlanır. Bu küçük sürüm disiplini, sonraki zafiyet sonuçlarının hangi varlık ve yapılandırmaya ait olduğunu güvenilir biçimde açıklamayı sağlar.

Onaylı hedef dosyasını üretmek

Tarama aracı doğrudan elle yazılmış CIDR ile başlatılmamalıdır. Doğrulanmış envanterden bir authorized.txt, istisnalardan da excluded.txt üretilir. Dosyalar tarih, kapsam sürümü ve onay kaydıyla ilişkilendirilir. Geniş bir aralığın gerçekten hangi hedeflere açıldığını görmek için Nmap'in list scan özelliği, DNS çözümünü kapatarak kullanılabilir:

nmap -sL -n -iL authorized.txt --excludefile excluded.txt

-sL hedefleri listeler; port taraması yapmaz. -n DNS sorgularını kapatarak beklenmeyen çözümleme trafiğini önler. Bu çıktı tarama değildir; hedef ifadesinin beklenen adreslere genişlediğini kontrol eden bir preflight kanıtıdır.

Tarama başlamadan hemen önce kapsam snapshot'ı alınır. Tarama uzun sürerse veya önemli bir altyapı değişikliği yapılırsa hedefler yeniden doğrulanır. Sonuç raporunda yalnız “şu IP tarandı” değil, hangi envanter sürümünün ve kapsam onayının kullanıldığı yazılır.

Güvenilir zafiyet yönetimi, yanlış hedef üzerinde çok ayrıntılı veri toplamaktan değil, doğru hedef üzerinde yeterli ve açıklanabilir kanıt üretmekten başlar.