NIS2 Teknik Tedbirleri: Madde 21’i Ölçülebilir Kontrollere Eşlemek

AB’deki müşteriniz bir güvenlik anketi gönderdi ve ilk soru “NIS2 madde 21 tedbirlerini nasıl karşılıyorsunuz?” diye başlıyor. Direktif “uygun ve orantılı” teknik, operasyonel ve organizasyonel tedbir ister; hangi ürünle, hangi ayarla, hangi kanıtla karşılanacağını söylemez. Bu boşluğu sizin doldurmanız gerekir. Aşağıda madde 21’deki on başlığı somut güvenlik kontrollerine ve denetimde masaya konabilecek, sistemden alınmış kanıtlara eşliyoruz.

NIS2 kimi doğrudan, kimi dolaylı etkiler

Direktif (EU) 2022/2555, Ek I’deki “yüksek kritiklikteki” sektörler (enerji, ulaşım, bankacılık, sağlık, içme suyu, dijital altyapı, BİT hizmet yönetimi vb.) ile Ek II’deki “diğer kritik” sektörlerde (imalat, gıda, kimya, posta, atık yönetimi, dijital sağlayıcılar vb.) faaliyet gösteren orta ve büyük ölçekli kuruluşları kapsar. Kuruluşlar “temel” (essential) ve “önemli” (important) diye ikiye ayrılır. Fark esas olarak denetim yoğunluğunda ve idari para cezası üst sınırlarındadır; teknik tedbir listesi ikisi için aynıdır. Üye devletlerin direktifi iç hukuka aktarma tarihi 17 Ekim 2024’tü. Aktarma durumu ülkeden ülkeye farklı ilerlediği için müşterinizin bulunduğu ülkenin ulusal mevzuatına ayrıca bakın.

Türkiye’de yerleşik bir şirket genellikle doğrudan kapsamda değildir. Etki iki kapıdan girer:

• Tedarik zinciri yükümlülüğü: Kapsamdaki kuruluş, doğrudan tedarikçileri ve hizmet sağlayıcılarıyla ilişkisindeki güvenlik risklerini yönetmek zorundadır. Bu yükümlülük size sözleşme maddesi, güvenlik anketi ve denetim hakkı olarak geri döner.
• AB’de hizmet sunan dijital sağlayıcılar: AB’de kurulu olmayan ama AB’de hizmet veren bulut, veri merkezi, yönetilen hizmet (MSP) ve yönetilen güvenlik hizmeti (MSSP) sağlayıcıları gibi kuruluşlar için direktif, AB içinde bir temsilci atanmasını öngörür.

Otomotiv yan sanayiindeki bir firmayı düşünün: AB’deki müşterisi NIS2 kapsamına girdiği anda tedarikçiden MFA, yama süreleri, olay bildirim süresi ve yedekleme başlıklarında somut taahhüt ve kanıt ister. “Bizi ilgilendirmez” demek bu soruları ortadan kaldırmaz. Maddeleri teknik kontrollere eşlemek daha kısa yoldur.

Madde 21’in saydığı on başlık

Direktifin 21. maddesinin 2. fıkrası, tedbirlerin en az şu başlıkları kapsamasını ister:

1. (a) Risk analizi ve bilgi sistemleri güvenliği politikaları
2. (b) Olay yönetimi (incident handling)
3. (c) İş sürekliliği: yedekleme yönetimi, felaket kurtarma ve kriz yönetimi
4. (d) Tedarik zinciri güvenliği
5. (e) Ağ ve bilgi sistemlerinin edinimi, geliştirilmesi ve bakımında güvenlik; zafiyet yönetimi ve bildirimi dahil
6. (f) Tedbirlerin etkinliğini değerlendirme politika ve prosedürleri
7. (g) Temel siber hijyen uygulamaları ve siber güvenlik eğitimi
8. (h) Kriptografi ve uygun olduğunda şifreleme kullanımı
9. (i) İnsan kaynakları güvenliği, erişim kontrolü ve varlık yönetimi
10. (j) Çok faktörlü veya sürekli kimlik doğrulama, güvenli ses/görüntü/metin iletişimi ve güvenli acil durum iletişimi

20. madde ayrıca yönetim organının bu tedbirleri onaylamasını, uygulanmasını gözetmesini ve eğitim almasını şart koşar. Yani imza yönetimde. Belirli dijital altyapı sağlayıcıları (bulut, veri merkezi, MSP, MSSP, DNS hizmetleri vb.) için Komisyon Uygulama Tüzüğü (EU) 2024/2690 bu başlıkları çok daha ayrıntılı teknik gerekliliklere böler. Kapsamınız dışında olsa bile kontrol tasarlarken elinizin altında bulunsun; neyin “yeterli” sayıldığını madde metninden çok daha net gösterir.

Başlık–teknik kontrol eşleme tablosu

Tabloda her başlık için tipik teknik kontrol ve denetçinin “uygulanıyor” diye kabul edeceği kanıt yer alıyor. Kanıt sütununu bilerek ekran görüntüsü yerine sistemden alınan tarihli rapor ve dışa aktarım üzerine kurduk. Ekran görüntüsü bir anı gösterir; rapor bir süreci.

Başlık	Teknik kontrol	Ölçülebilir kanıt
(a) Risk analizi	Varlık envanteri, kritiklik sınıfı, risk kaydı	Envanter ile ağ keşfi arasındaki fark raporu
(b) Olay yönetimi	Merkezi loglama, SIEM kuralları, EDR	Log kaynakları listesi, kural envanteri, olay kayıtları
(c) İş sürekliliği	Değiştirilemez yedek, çevrimdışı kopya, DR testi	Geri yükleme testi raporu, RPO/RTO ölçümü
(d) Tedarik zinciri	Tedarikçi erişim ayrımı, uzaktan erişim kayıt ve onayı	Tedarikçi hesap listesi, oturum kayıtları
(e) Edinim ve bakım	Zafiyet taraması, yama SLA’sı, güvenli yapılandırma	Tarama kapsamı, SLA uyum raporu
(f) Etkinlik ölçümü	Sızma testi, yapılandırma denetimi, metrikler	Test raporu ve yeniden test sonucu
(g) Siber hijyen	Sıkılaştırma temel çizgisi, phishing simülasyonu	Temel çizgi sapma raporu, eğitim kayıtları
(h) Kriptografi	Disk şifreleme, TLS standardı, anahtar yönetimi	Şifreleme durum raporu, TLS tarama çıktısı
(i) Erişim ve varlık	Rol bazlı yetki, periyodik erişim gözden geçirme	İmzalı gözden geçirme kaydı, ayrılan personel kontrolü
(j) MFA	Tüm uzak erişim ve yönetici hesaplarında MFA	MFA kayıt raporu, istisna listesi

Tablo başlangıç noktasıdır, matris değil. Her satıra “kontrol sahibi”, “kanıt kaynağı sistem” ve “kanıt üretim sıklığı” sütunlarını eklediğinizde işletilebilir bir kontrol matrisine dönüşür. Sahada en sık gördüğümüz hata, satırın dolu ama sahibinin boş olmasıdır. Sahipsiz kontrol çürür. (h) satırının ayrıntılı uygulaması şifreleme kontrollerinin bekleyen ve aktarılan veride uygulanması rehberinde, (e) satırı ise zafiyet yönetimi programı rehberinde ele alınıyor.

Ölçülebilir kanıt örneği: MFA kapsamı

“Tüm kullanıcılarda MFA var” cümlesi denetimde tek başına geçmez. Denetçi kapsam dışında kalan hesapları görmek ister. Microsoft Entra ID kullanan bir ortamda kayıt durumunu Microsoft Graph PowerShell ile dışa aktarabilirsiniz:

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { -not $_.IsMfaRegistered } |
  Select-Object UserPrincipalName, IsAdmin,
    @{n='MethodsRegistered'; e={$_.MethodsRegistered -join ';'}} |
  Export-Csv .\mfa-kayitsiz-kullanicilar.csv -NoTypeInformation -Encoding UTF8

Yöntem listesi dizi olarak döner; CSV’ye yazmadan önce birleştirmezseniz sütunda yalnızca tür adı görürsünüz. Bir uyarı daha: kayıtlı olmak, MFA’nın zorlandığı anlamına gelmez. Zorlamanın kanıtı Conditional Access politikalarının kapsamı ve oturum açma loglarındaki kimlik doğrulama gereksinimidir. Politikada “hariç tutulan” grup listesi, konsolda ilk bakılacak yerdir; acil durum hesabı dışında kimse orada uzun süre durmamalı. Kayıt raporu ile politika kapsamını birlikte saklarsanız (j) başlığı için güçlü bir kanıt setiniz olur.

Olay bildirimi için teknik hazırlık

Direktifin 23. maddesi “önemli olay” için kademeli bildirim öngörür: olayın fark edilmesinden itibaren 24 saat içinde erken uyarı, 72 saat içinde olay bildirimi ve olay bildiriminden sonra en geç bir ay içinde nihai rapor. Tedarikçi konumundaysanız müşteri sözleşmeniz büyük ihtimalle daha kısa bir süre yazıyordur. Bu süreleri tutmak hukuk biriminin değil, altyapının işidir:

• Tespit zamanı ayrı kaydedilmeli: SIEM veya EDR uyarısının oluştuğu zaman ile analistin olayı kabul ettiği zaman ayrı alanlarda tutulmalı. 24 saatlik sayaç “fark etme” anında başlar.
• Zaman senkronizasyonu: Sistemlerin saatleri birbirinden kayarsa olay zaman çizelgesi kurulamaz. Tüm sunucu, ağ cihazı ve güvenlik ürünü aynı NTP hiyerarşisine bağlanmalı. Saati üç dakika geri kalan bir firewall, zaman çizelgesini bozmaya yeter.
• Log saklama derinliği: Nihai rapor kök neden ve etki alanı ister. Saldırganın ilk erişimi haftalar önceyse ve loglar 7 gün tutuluyorsa kök neden yazılamaz. Saklama tasarımı merkezi log saklama mimarisi rehberinde ayrıntılı anlatılıyor.
• Etki ölçümü verisi: Etkilenen kullanıcı sayısı, hizmet kesinti süresi ve etkilenen veri türü önemlilik değerlendirmesinin girdisidir. Varlık envanteri hangi sistemin hangi hizmeti taşıdığını bilmiyorsa bu sorular saatler içinde cevaplanamaz.
• Bant dışı iletişim: E-posta ve kimlik altyapısı etkilenmişse ekip ve yöneticiler hangi kanaldan konuşacak? Bu kanal önceden belirlenmiş ve denenmiş olmalı; (j) başlığındaki “güvenli acil durum iletişimi” tam olarak budur.

Tedarik zinciri güvenliği gereklilikleri

(d) başlığı iki yönlüdür. Siz kendi tedarikçilerinizi yönetirsiniz; aynı anda müşterinizin tedarik zincirinde bir halkasınız. Teknik tarafta en sık karşımıza çıkan açıklar şunlar:

• Kalıcı tedarikçi hesapları: Yazılım veya bakım firmasına yıllar önce açılmış, süresiz, MFA’sız VPN hesapları. Kontrol: süreli hesap, talep bazlı etkinleştirme, MFA zorunluluğu ve oturum kaydı.
• MSP’nin aşırı yetkisi: Yönetilen hizmet sağlayıcının tüm müşterilerinde ortak kullandığı yönetim aracı, sizin ortamınızda domain admin yetkisiyle çalışıyor olabilir. Kontrol: ayrı yönetim hesabı, en az yetki, aracın erişebildiği ağ bölümlerinin sınırlanması.
• Yazılım bileşeni görünürlüğü: Kritik uygulamalardaki üçüncü taraf bileşenlerin listesi (SBOM) yoksa yeni bir kütüphane zafiyeti çıktığında “etkileniyor muyuz?” sorusuna cevap veremezsiniz.
• Müşteriye yönelik kanıt: Anketlerde istenen bilgiler (MFA oranı, yama süreleri, son yedek testi tarihi) her seferinde elle toplanıyorsa iki anket arasında rakamlar tutmaz. Bu metrikleri tek ve güncel bir kaynaktan üretin; hem müşteri cevabı hem iç denetim hızlanır.

Otomotiv tedarik zincirindeyseniz TISAX değerlendirmesi için topladığınız kanıtların önemli bir kısmı NIS2 eşlemesinde de işe yarar. Ortak noktalar için TISAX hazırlık süreci ve teknik kanıtlar rehberine bakabilirsiniz.

Boşluk analizi kontrol listesi

Eşleme tablosunu kendi ortamınıza uygulamak için aşağıdaki listeyi kullanın. Her madde için “var / kısmen / yok” ve kanıt kaynağını yazmanız yeter. “Kısmen” cevabında hangi varlıkların dışarıda kaldığını ayrıca not edin; denetçinin ilk soracağı şey odur.

• Varlık envanteri son üç ayda ağ keşfiyle karşılaştırıldı mı; envanter dışı cihaz listesi var mı?
• İnternete açık tüm hizmetler ve uzak erişim yolları MFA ile korunuyor mu; istisnalar tarihli ve onaylı mı?
• Yönetici hesapları günlük kullanıcı hesaplarından ayrılmış mı?
• Kritik sunucu, firewall, kimlik ve EDR logları merkezi bir sisteme akıyor ve olay incelemesine yetecek süre saklanıyor mu?
• Olay fark etme anı ve bildirim adımları kayıt altına alınıyor mu; 24/72 saatlik akış tatbikatla denendi mi?
• Yedeklerin en az bir kopyası değiştirilemez veya çevrimdışı mı; son geri yükleme testi ne zaman yapıldı?
• Zafiyet taraması kimlik bilgili mi ve kritik bulgular için kapatma süresi tanımlı mı?
• Uç nokta disk şifrelemesi ve TLS yapılandırma standardı tanımlı ve ölçülüyor mu?
• Tedarikçi hesapları süreli mi, oturumlar kaydediliyor mu?
• Tedbirlerin etkinliği son bir yılda bağımsız bir testle (sızma testi, yapılandırma denetimi) doğrulandı mı?
• Yönetim organı tedbirleri onayladı mı ve yönetici eğitimi kayıtlı mı?

Bu listede en çok “kısmen” alan maddeler genellikle yedek testi ve tedarikçi hesaplarıdır. Kontrol vardır. Ölçümü yoktur. İş sürekliliği ve kriz yönetiminin süreç tarafı bu rehberin dışında kalıyor; yedekleme, DR ve kriz organizasyonu için NIS2 iş sürekliliği gereklilikleri rehberi tamamlayıcıdır. Boşluk analizini bağımsız bir gözle yaptırmak isterseniz kurumsal siber güvenlik danışmanlığı ve kontrol ve konfigürasyon denetimi hizmetlerimizde bu eşlemeyi kanıt toplamayla birlikte yürütüyoruz. Direktifin tam metni EUR-Lex üzerinde yer alır.

Sık sorulan sorular

Türkiye’deki bir şirket NIS2’ye uymak zorunda mı?

Türkiye’de yerleşik şirketler genellikle doğrudan kapsamda değildir. Ama AB’deki kapsamdaki müşteriler tedarik zinciri güvenliğini yönetmek zorunda olduğu için NIS2 gereklilikleri sözleşme maddeleri, güvenlik anketleri ve denetim hakkı yoluyla tedarikçiye yansır. AB’de hizmet sunan bazı dijital sağlayıcılar için AB içinde temsilci atama yükümlülüğü de doğabilir.

NIS2 belirli bir ürün veya standart şart koşuyor mu?

Hayır. Direktif risk temelli ve teknolojiden bağımsızdır; başlıkları sayar, ürün veya marka belirtmez. Neyin uygun ve orantılı olduğunu kuruluşun risk değerlendirmesi belirler. ISO 27001 gibi standartlar uygulamada eşleme referansı olarak kullanılır.

NIS2’de olay bildirim süreleri nelerdir?

Önemli bir olayda fark etmeden itibaren 24 saat içinde erken uyarı, 72 saat içinde olay bildirimi ve olay bildiriminden sonra en geç bir ay içinde nihai rapor verilir. Yetkili makam ara rapor da isteyebilir. Tedarikçi sözleşmeleri müşteriye çoğu zaman daha kısa bir bildirim süresi öngörür.

Boşluk analizinde en sık hangi teknik eksikler çıkar?

Sahada en sık gördüklerimiz: belgelenmemiş MFA istisnaları, kalıcı ve MFA’sız tedarikçi hesapları, olay incelemesine yetmeyen log saklama süreleri, kimlik bilgisi kullanılmayan zafiyet taramaları ve hiç denenmemiş geri yükleme süreçleri. Ortak nokta aynı: kontrol var, kapsamı ölçülmemiş.