NIS2 Şifreleme, MFA ve Erişim Kontrolü 2026: Article 21(2)(h)–(j)
| Kontrol | NIS2 dayanağı | Pratik uygulama |
|---|---|---|
| Kriptografi/şifreleme | Article 21(2)(h) | Veri sınıfına göre şifreleme ve anahtar yönetimi |
| HR güvenliği | Article 21(2)(i) | İşe giriş, rol değişikliği, ayrılış kontrolleri |
| Erişim kontrolü | Article 21(2)(i) | En az ayrıcalık, RBAC, periyodik erişim review |
| Varlık yönetimi | Article 21(2)(i) | Donanım, yazılım, bulut ve hesap envanteri |
| MFA/sürekli auth | Article 21(2)(j) | Kritik ve uzaktan erişimlerde güçlü doğrulama |
| Güvenli iletişim | Article 21(2)(j) | Güvenli ses/video/metin ve acil iletişim |
NIS2 Article 21(2)(h)–(j) hangi kontrolleri getirir?
Directive (EU) 2022/2555 Article 21(2), siber güvenlik risk yönetiminin asgari alanlarını sayar. Bu listenin son üç alt bendi kimlik, erişim ve veri koruması bakımından özellikle önemlidir. Article 21(2)(h) kriptografi ve uygun olduğunda şifreleme kullanımıyla ilgili politika ve prosedürleri; (i) insan kaynakları güvenliği, erişim kontrol politikaları ve varlık yönetimini; (j) uygun olduğunda çok faktörlü veya sürekli kimlik doğrulama çözümlerini, güvenli ses/video/metin iletişimini ve güvenli acil iletişim sistemlerini kapsar.
“Uygun olduğunda” ifadesi MFA veya şifrelemenin isteğe bağlı olduğu anlamına gelmez. Kuruluş risk değerlendirmesi yapmalı; kontrolü uygulamıyorsa bunun neden riskle orantılı olmadığını açıklayabilmelidir. Kritik yönetici hesabında yalnız parola kullanımı gibi yüksek riskli istisnalar, denetimde özel gerekçe ve telafi kontrolü gerektirir.
Bu kontroller ayrı adalar olarak yönetilmemelidir. Kimlik sistemi, erişim yetkisi, cihaz, veri sınıfı, şifreleme anahtarı ve olay logu aynı güvenlik mimarisinin parçalarıdır.
NIS2 kriptografi politikası nasıl hazırlanır?
Kriptografi politikası hangi bilgi ve sistemlerde hangi koruma yönteminin kullanılacağını belirlemelidir. Politika; algoritma seçimi, minimum anahtar uzunluğu, sertifika yönetimi, anahtar üretimi/saklanması/döndürülmesi/imhası, istisna süreci ve sorumlulukları kapsayabilir. Teknik detaylar kurum standardında tutulurken yönetim düzeyi politika temel prensipleri belirler.
Kuruluş “TLS kullanıyoruz” diyerek Article 21(2)(h) dosyasını kapatamaz. Eski protokoller, zayıf cipher suite’ler, self-signed sertifikalar, süresi geçmiş sertifikalar ve kontrolsüz anahtar paylaşımı fiili riski artırır. Otomatik sertifika envanteri ve son kullanma izleme mekanizması kesinti ve güvenlik riskini azaltır.
Şifreleme kararları veri sınıflandırmasıyla bağlanmalıdır. Kamuya açık veri, iç kullanım verisi, kişisel veri, ticari sır ve kritik kimlik bilgileri için aynı kontrol seviyesi gerekmeyebilir.
Aktarımda ve depolamada şifreleme nasıl uygulanmalı?
Aktarım halindeki veri için TLS/VPN veya uygun güvenli kanal; depolanan veri için disk, veri tabanı, dosya, yedek veya uygulama seviyesinde şifreleme kullanılabilir. Hangi katmanın seçileceği tehdit modeline göre belirlenmelidir.
Disk şifrelemesi fiziksel cihaz kaybında güçlü koruma sağlayabilir; fakat saldırgan uygulama hesabını ele geçirmişse veri çalışır durumdayken erişilebilir olabilir. Bu nedenle kritik veri için uygulama/veri tabanı seviyesinde ek kontroller gerekebilir.
Yedekler özellikle unutulmamalıdır. Üretim verisi şifrelenirken aynı verinin yedek kopyasının açık tutulması risk transferi yaratır. Yedek anahtarlarının üretim anahtarlarıyla aynı yetki zincirinde tutulması da fidye yazılımı senaryosunda zayıflık oluşturabilir.
Kriptografik anahtar yönetiminde hangi kontroller gerekir?
Anahtar yönetimi şifrelemenin güvenlik değerini belirler. Anahtarlar güvenli ortamda üretilmeli, erişim yetkileri sınırlı olmalı, rotasyon periyotları belirlenmeli ve kullanım ömrü sona erdiğinde güvenli biçimde iptal/imha edilmelidir. Kritik anahtarlar için HSM veya yönetilen key management hizmetleri kullanılabilir.
Tek bir yöneticiye sınırsız anahtar erişimi verilmesi görev ayrılığı açısından risklidir. Üretim anahtarıyla test ortamının anahtarının aynı olması, geliştiricinin canlı müşteri verisini çözebilmesi veya anahtarın kaynak kod deposuna yazılması kontrol zafiyetidir.
Anahtar yedekleme ve kurtarma senaryosu da test edilmelidir. Anahtar kaybı, verinin kalıcı olarak erişilemez hale gelmesine yol açabilir ve iş sürekliliği riskine dönüşebilir.
NIS2 erişim kontrol politikası nasıl kurulmalı?
Article 21(2)(i) erişim kontrolünü açıkça sayar. Temel prensip en az ayrıcalıktır: kullanıcı yalnız işini yapması için gereken sisteme ve yetkiye sahip olmalıdır. Role-based access control, attribute-based control veya farklı modeller kullanılabilir; önemli olan yetkinin gerekçeli, izlenebilir ve düzenli gözden geçirilebilir olmasıdır.
Erişim taleplerinde talep eden, onaylayan ve uygulayan roller ayrılmalıdır. Kritik sisteme kendi kendine yetki verme, ortak yönetici hesabı kullanma veya ayrılan çalışanın hesabını açık bırakma ciddi kontrol zafiyetidir.
Periyodik erişim gözden geçirmesinde sistem sahibi ve iş birimi yetki listesini doğrulamalı; gereksiz, eski ve yetim hesaplar kapatılmalıdır. Kullanılmayan servis hesapları da envantere alınmalı ve sahiplik atanmalıdır.
Ayrıcalıklı hesaplar neden ayrıca yönetilmeli?
Domain admin, root, cloud global administrator, veri tabanı yöneticisi veya güvenlik sistemi admin hesabı normal kullanıcıdan daha büyük etki yaratır. Bu nedenle privileged access management süreçleriyle ayrı tutulması gerekir.
Günlük e-posta ve web kullanımı için admin hesabı kullanılmamalı; ayrı kimlik, güçlü MFA, kısa süreli yükseltilmiş yetki, oturum kaydı ve onay mekanizması uygulanabilir. Acil “break glass” hesapları sınırlı sayıda, güçlü kimlik doğrulama ve yoğun izlemeyle yönetilmelidir.
Ayrıcalıklı erişim loglarının saldırgan tarafından silinemeyecek ayrı log altyapısına gönderilmesi olay incelemesi açısından önemlidir.
NIS2 MFA’yı zorunlu tutuyor mu?
Article 21(2)(j), riskle uygun olduğu ölçüde çok faktörlü kimlik doğrulama veya sürekli kimlik doğrulama çözümlerinin kullanılmasını açıkça sayar. Bu nedenle MFA, özellikle yüksek riskli erişimlerde güçlü bir NIS2 kontrolüdür.
Öncelik; uzaktan erişim, VPN, bulut yönetim paneli, kod deposu, e-posta, ayrıcalıklı hesaplar, finansal işlem sistemleri ve kritik uygulamalara verilmelidir. SMS tabanlı ikinci faktör bazı senaryolarda hiç MFA olmamasından iyidir; ancak yüksek riskli yönetici erişimlerinde phishing-resistant yöntemler daha güçlü koruma sağlar.
MFA istisnaları kaydedilmelidir. Eski uygulama MFA desteklemiyorsa ağ segmentasyonu, erişim proxy’si, cihaz sertifikası veya geçici telafi kontrolleri uygulanmalı ve modernizasyon planı oluşturulmalıdır.
İnsan kaynakları güvenliği NIS2’de ne anlama gelir?
Article 21(2)(i), insan kaynakları güvenliğini erişim kontrolüyle birlikte sayar. İşe girişte rol ve yetki belirleme; uygun gizlilik/güvenlik yükümlülükleri; görev değişiminde erişim güncelleme; disiplin ve güvenlik farkındalığı; işten ayrılışta hesap, cihaz ve fiziksel erişimin kapatılması bu sürecin parçalarıdır.
“Joiner–Mover–Leaver” süreci HR sistemiyle kimlik yönetimini otomatik bağlayabilir. İşten ayrılan personelin hesabının günlerce açık kalması veya departman değiştiren çalışanın eski yetkilerini koruması yetki birikimine yol açar.
Kritik rollerde görev ayrılığı ve çıkar çatışması da değerlendirilmelidir. Aynı kişinin hem işlem oluşturup hem onaylaması, hem güvenlik loglarını yönetip hem kendi faaliyetini denetlemesi kontrol riskidir.
Varlık yönetimi neden erişim güvenliğinin temelidir?
Article 21(2)(i) varlık yönetimini açıkça düzenler. Kuruluş hangi sunucu, uç nokta, mobil cihaz, ağ ekipmanı, bulut kaynağı, yazılım, sertifika, API, hizmet hesabı ve veri deposuna sahip olduğunu bilmeden etkili erişim politikası kuramaz.
Envanterin sahibi, kritikliği, işletim sistemi/sürümü, internet açıklığı, veri sınıfı ve destek durumu tutulabilir. Bulut ortamlarında varlıkların hızlı açılıp kapanması nedeniyle manuel Excel envanteri yetersiz kalabilir; otomatik discovery mekanizmaları kullanılabilir.
İzinsiz “shadow IT” servisleri de envanter dışı risk yaratır. İş birimlerinin kendi kartıyla SaaS alması, veri ve erişim yönetimini merkezi güvenlikten kaçırabilir.
Güvenli ses, video, metin ve acil iletişim nasıl kurulmalı?
Article 21(2)(j), uygun olduğunda güvenli ses, video ve metin iletişimlerinin ve güvenli acil iletişim sistemlerinin kullanımını sayar. Normal kurumsal e-posta ve kimlik altyapısı siber olayda devre dışı kalabileceği için kriz ekibinin alternatif iletişim kanalı bulunmalıdır.
Acil kanal önceden belirlenmeli, katılımcılar kayıtlı olmalı ve periyodik tatbikatta test edilmelidir. Olay sırasında rastgele kişisel mesajlaşma grubu açmak; kişisel veri, delil, gizlilik ve erişim kontrolü sorunları yaratabilir.
Kritik toplantı ve mesajların saklama/erişim politikası da belirlenmelidir. Olay sonrası soruşturmada karar zincirinin kanıtlanabilmesi için uygun kayıt gerekir.
Denetimde hangi kanıtlar sunulabilir?
- kriptografi ve şifreleme politikası,
- sertifika ve anahtar envanteri,
- veri sınıflandırma ve şifreleme matrisi,
- erişim kontrol politikası ve rol matrisi,
- periyodik erişim gözden geçirme kayıtları,
- PAM raporları ve ayrıcalıklı hesap listesi,
- MFA kapsam raporu ve istisna kayıtları,
- Joiner–Mover–Leaver iş akışı,
- varlık envanteri,
- acil iletişim planı ve tatbikat sonuçları.
Bu kontrollerin Article 21’in bütünü içindeki yeri NIS2 Article 21 zorunlu 10 güvenlik tedbiri rehberinde, yönetim onayı ise Article 20 yönetim kurulu rehberinde açıklanmıştır.
Sık sorulan sorular
NIS2 şifrelemeyi açıkça sayıyor mu?
Evet. Article 21(2)(h) kriptografi ve uygun olduğunda şifreleme kullanımına ilişkin politika ve prosedürleri sayar.
NIS2 MFA’yı açıkça sayıyor mu?
Evet. Article 21(2)(j) uygun olduğunda çok faktörlü veya sürekli kimlik doğrulama çözümlerini sayar.
“Uygun olduğunda” MFA’yı hiç kullanmamak anlamına gelir mi?
Hayır. Risk değerlendirmesi gerekir. Kritik erişimlerde MFA uygulanmıyorsa gerekçe, telafi kontrolü ve iyileştirme planı belgelenmelidir.
SMS MFA yeterli midir?
NIS2 belirli bir MFA teknolojisini her kullanım için adlandırmaz. Yüksek riskli erişimlerde phishing-resistant ve güçlü yöntemler tercih edilmelidir.
İşten ayrılan kullanıcının hesabı ne zaman kapatılmalı?
NIS2 saat sayısı vermez; ancak erişim riski nedeniyle ayrılışla uyumlu, gecikmesiz ve prosedürle kontrol edilen kapatma gerekir.
Ortak admin hesabı kullanılabilir mi?
Ortak hesap izlenebilirliği azaltır. Kritik erişimlerde kişiye özgü kimlik, MFA ve ayrıcalık yönetimi daha güçlü uyum sağlar.
Varlık envanteri NIS2’de açıkça var mı?
Evet. Article 21(2)(i) varlık yönetimini zorunlu risk alanları arasında sayar.
Acil iletişim kanalı NIS2’de var mı?
Evet. Article 21(2)(j) uygun olduğunda güvenli acil iletişim sistemlerini açıkça sayar.
Şifreleme kişisel veriyle mi sınırlı?
Hayır. NIS2 ağ ve bilgi sistemi riskine odaklanır; ticari sır, kimlik bilgileri, yedekler ve kritik yapılandırmalar da risk bazlı korunabilir.
Bakırcı & Keskin Hukuk Bürosu
Bu yazı genel hukuki bilgilendirme amacı taşır; kriptografi, kimlik ve erişim mimarisi somut sistem ve tehdit modeline göre tasarlanmalıdır.
Hukuki konu hakkında iletişim
İlk iletişimde konuyu, bulunduğunuz ülke veya ili ve varsa tebliğ ya da son işlem tarihini kısaca belirtebilirsiniz. T.C. kimlik numarası, sağlık verisi veya kişisel belge göndermeyiniz. Mesajlaşma tek başına hukuki görüş veya avukatlık ilişkisi oluşturmaz.
