Altyapı Koruması, Segmentasyon ve Görünürlük

Ön koşul: Arven'in insan ve workload kimliklerini, erişim politikasını, ERP ve backup risk yollarını ayırabilmelisin. Bu derste yönetim, veri ve kurtarma düzlemlerini çizecek; segmentasyonun engellediği gerçek saldırı yolunu ve meşru iş üzerindeki etkisini sınayacak; host, patch, key ve log kontrollerini kanıt matrisiyle birleştireceksin. Yaklaşık 32 dakika anlatı, 20 dakika uygulama ve 13 dakika bilgi kontrolü önerilir. Network segmentasyonu yalnız subnet veya VLAN sayısı değildir. Portal müşterisinin veri trafiği, yönetici değişikliği, backup kopyası, restore ve monitoring birbirinden farklı kimlik ve trust boundary taşır. Aynı firewall üzerinden geçmeleri politikalarının aynı olmasını gerektirmez. Arven sipariş akışı için müşteri–portal–API–ERP yönünü, yönetim akışı için operatör–bastion–host/cluster yönünü, backup için üretim–repository–restore yönünü ayrı çiz. Her okta kaynak, hedef, port/protokol, kimlik, veri, owner, log ve fail-closed veya güvenli minimum hizmet davranışı yaz.

Host veya cluster güvenliği için hangi işletim sistemi, hypervisor, firmware, runtime, agent ve yönetim API'sinin gerçekten çalıştığını envanterle. Bilinmeyen cihaz yamalanamaz; 'agent kurulu' etiketi de destek ve güncelleme durumunu kanıtlamaz. Hardening baseline gereksiz servis/portu kapatır, ayrı yönetim kimliğini, dosya/secret izinlerini, secure boot veya platform kabiliyetini ve log ayarını bağlama uygun seçer. Her baseline istisnası gerekçe, owner, süre ve kompansasyon taşımalıdır. Arven ERP gateway'inde kapatılan servis üretim aktarımını bozuyorsa değişiklik güvenlik başarısı sayılmaz; test ortamı, bakım penceresi ve geri alma gerekir. NIST SP 800-40 Rev. 4 patch yönetimini belirleme, önceliklendirme, edinme, kurma ve kurulumun doğrulanması süreci olarak ele alır. Patch paketinin indirildiği değil etkinleştiği, reboot gerekip gerekmediği ve iş akışının hâlâ çalıştığı ölçülür. EOL platform için patch yoksa izolasyon, erişim daraltma, izleme ve emeklilik takvimi karara girer.

Arven sipariş verisi portalda toplanır, API ve kuyruktan ERP'ye gider, log, backup ve test ortamında kopyalanabilir. Veri sınıfı, saklama süresi, yerleşim, erişim sahibi ve silme/kurtarma beklentisi her kopyada farklıdır. Aktarım şifrelemesi yalnız transit yolu korur; kaynak veya hedefte geniş admin yetkisini ve yanlış iş kuralını düzeltmez. Disk veya veritabanı şifrelemesi medya kaybı ve yetkisiz altyapı okuması riskine karşı yararlı olabilir; uygulama hesabı açık veriye erişiyorsa o hesabın ihlali hâlâ önemlidir. Data minimization, masking ve tokenization ihtiyaçla birlikte ele alınır; test ortamına üretim kopyası taşıma varsayılan değildir. Anahtarın nerede üretildiği, kim tarafından kullanıldığı, rotate/revoke edildiği, backup ve restore edildiği, eski verinin nasıl açıldığı ve control plane kesintisindeki davranışı yazılır. KMS varlığı tek başına key separation değildir; yönetici aynı anda hem veri hem anahtarı yönetebiliyorsa ortak neden riski sürer.

Kontrol uygulanıyor iddiası için gözlem gerekir. Arven'de destek hesabı ile ERP config değişikliği; portal Pod'undan backup yönetimine istek; key export denemesi; patch başarısızlığı; log akışının durması aynı olay haritasına bağlanır. Kimlik sağlayıcı, bastion, host, firewall, API, KMS, backup ve SIEM logları farklı saat ve alan adları taşır. Ortak olay zamanı, özne ve kaynak kimliği, correlation ID, karar nedeni, değişiklik ID ve log owner tanımlanmadan olay zinciri kurulamaz. Log toplama hassas sipariş, parola veya token sızıntısına dönüşmemelidir; maskeleme, erişim, saklama ve bütünlük kontrolleri gerekir. NIST SP 800-92 log yönetimini altyapı ve işletim süreçleri olarak ele alır; NIST SP 800-137 sürekli izlemenin varlık, tehdit, zafiyet ve kontrol etkinliği görünürlüğünü vurgular. Bu kaynaklar tek bir SIEM ürünü veya otomatik detection başarısı vaat etmez.