Şifreleme Kontrolleri: Bekleyen ve Aktarılan Veride Uygulama

“Dizüstülerimiz şifreli” cümlesi denetimde ilk soruyu durdurmaz, başlatır: Hangi veri, hangi algoritmayla, hangi anahtar yönetimiyle korunuyor ve bunun tüm cihazlarda geçerli olduğunu nasıl ölçüyorsunuz? Uyum çerçevelerinin neredeyse tamamı şifreleme ister; kanıtı ise sizden bekler. Aşağıda uç nokta, sunucu, veritabanı ve ağ trafiği şifrelemesinin teknik uygulamasını ve her biri için doğrulama yöntemini anlatıyoruz.

Uyum çerçevelerinde şifreleme beklentisi

ISO/IEC 27001:2022 Ek A 8.24 (Kriptografi kullanımı), kriptografi kurallarının tanımlanmasını ve anahtar yönetimini kapsar. NIS2, risk yönetimi tedbirleri arasında kriptografi ve şifreleme politikalarını ayrı bir başlık olarak sayar; bu başlığın diğer tedbirlerle ilişkisi NIS2 teknik tedbirleri rehberinde eşlenmiştir. TISAX’ın dayandığı VDA ISA kataloğu ise bilgi taşıyan cihazların ve ağ üzerinden aktarılan bilginin korunmasını sorgular; yüksek koruma ihtiyacı olan bilgide beklenti yükselir. Ortak payda şu: çerçeveler belirli bir ürün istemez. Tanımlı bir standart, eksiksiz kapsam ve ölçülebilir uygulama ister.

Bu yüzden ilk iş, veri türlerini kontrollerle eşleyen bir şifreleme standardı yazmaktır:

Veri / ortam	Kontrol	Doğrulama
Dizüstü ve masaüstü diskleri	BitLocker / FileVault, TPM ile	MDM uyumluluk raporu
Sunucu diskleri, sanal makineler	BitLocker, LUKS, hipervizör VM şifrelemesi	Sunucu bazlı durum çıktısı
Veritabanı dosyaları ve yedekleri	TDE veya motorun at-rest şifrelemesi	Şifreleme durumu sorgusu
Çıkarılabilir medya	BitLocker To Go veya kullanım yasağı	Cihaz kontrol politikası
Web ve API trafiği	TLS 1.2 asgari, TLS 1.3 tercihli	TLS tarama çıktısı
Yönetim protokolleri	SSH, HTTPS, SNMPv3 authPriv	Yapılandırma denetimi

Bekleyen veri: disk, veritabanı, dosya düzeyi

Disk düzeyi şifreleme, cihaz kaybolduğunda veya disk sökülüp başka bir sistemde okunmaya çalışıldığında veriyi korur. Sistem açık ve kullanıcı oturumu etkinken çalışan bir saldırgana karşı koruma sağlamaz. Bu sınırı risk değerlendirmesine doğru yazın; denetçi sorar. Windows’ta BitLocker için asgari standart şunları içermeli: TPM tabanlı koruma, şifreleme yönteminin grup ilkesi veya Intune ile tanımlanması (örneğin XTS-AES 256), sabit veri sürücülerinin de kapsanması ve kurtarma anahtarının merkezi olarak yedeklenmesi. Linux sunucularda LUKS kullanıyorsanız açılışta parola girişinin nasıl çözüleceğini (TPM veya ağ tabanlı otomatik kilit açma) önceden planlayın. Uzak veri merkezindeki bir sunucunun yeniden başlatılıp konsolda parola beklemesi, sahada sık karşılaştığımız bir kesinti sebebidir.

# Windows: tüm birimlerin BitLocker durumu
Get-BitLockerVolume |
  Select-Object MountPoint, VolumeStatus, EncryptionMethod, ProtectionStatus, KeyProtector

# Klasik komut satırı karşılığı
manage-bde -status

# Linux: LUKS birimlerini ve başlık bilgisini görüntüle
lsblk -f
sudo cryptsetup luksDump /dev/sda3

Veritabanı şifrelemesi (örneğin Microsoft SQL Server TDE) veri ve log dosyalarını ve bunlardan alınan yedekleri korur. Disk şifrelemesinin göremediği bir riski hedefler: çalışan sistemden veritabanı dosyasının veya yedeğin kopyalanması. Sertifika ve özel anahtar yedeğini almadan TDE açmak, felaket kurtarmada başka bir sunucuya geri yüklenemeyen yedek demektir. Yedek var. Açılmıyor.

-- SQL Server: veritabanı bazında TDE durumu (3 = şifreli)
SELECT DB_NAME(database_id) AS veritabani,
       encryption_state,
       key_algorithm, key_length
FROM sys.dm_database_encryption_keys;

Sunucuda herhangi bir veritabanında TDE açıldığında tempdb de otomatik olarak şifrelenir ve sorgu çıktısında görünür; kanıt raporunda bunu ayrı bir uygulama kararı gibi yorumlamayın.

Dosya ve uygulama düzeyi şifreleme (duyarlılık etiketleriyle şifreleme, uygulama içi alan şifrelemesi) yetkili bir oturum açıkken bile veriyi yetkisiz kişiye karşı korur. En ince taneli kontrol budur; karşılığında anahtar yönetimi ve kullanılabilirlik maliyeti de en yüksek olandır. Hangi veri türünün bu düzeyi gerektirdiğini risk değerlendirmesi belirler.

Aktarılan veri: TLS yapılandırma standardı

TLS standardı yazılı bir belge olmalı ve en az şunları tanımlamalı:

• Protokol sürümü: SSL 2.0/3.0, TLS 1.0 ve TLS 1.1 kapalı. TLS 1.0 ve 1.1, RFC 8996 ile resmi olarak kullanımdan kaldırılmıştır. TLS 1.2 asgari; TLS 1.3 (RFC 8446) destekleyen sistemlerde etkin.
• Şifre takımları: TLS 1.2 için ileri gizlilik sağlayan ECDHE anahtar değişimi ve AES-GCM veya ChaCha20-Poly1305 gibi AEAD şifreler. RC4, 3DES, NULL, EXPORT ve anonim takımlar kapalı.
• Sertifika: En az 2048 bit RSA veya ECDSA P-256 anahtar, SHA-256 imza, kurumsal veya kamu CA’sından imzalı sertifika.
• Kapsam: Yalnızca internete açık web sunucuları değil; iç uygulamalar, yönetim arayüzleri, LDAP (LDAPS veya LDAP imzalama ve kanal bağlama), veritabanı bağlantıları ve SMTP aktarımı.

Kapsam maddesi en çok atlanan maddedir. Dış web sitesi A notu alır, iç ağdaki switch yönetim arayüzü hâlâ TLS 1.0 konuşur. Firewall üzerinde TLS inspection yapılıyorsa istemci ile sunucu arasındaki şifreleme zinciri ikiye bölünür; sertifika ve istisna tasarımı SSL/TLS inspection tasarımı rehberinde anlatılıyor. E-posta tarafındaki seçenekler (MTA-STS, S/MIME) için e-posta şifreleme seçenekleri rehberine bakın.

Sertifika envanteri ve süre takibi

Süresi dolan sertifika hem kesintidir hem de kurumsal siber güvenlik riskidir: kullanıcılar sertifika uyarısını tıklayıp geçmeye alışır. Envanter yalnızca satın alınan kamu sertifikalarını değil, iç CA’dan verilenleri ve cihazlarda varsayılan gelen kendinden imzalı sertifikaları da kapsamalı. Envanter alanları: ortak ad ve SAN listesi, veren CA, bitiş tarihi, anahtar türü ve uzunluğu, kurulu olduğu sistem, sahibi ve yenileme yöntemi.

# Windows: 30 gün içinde süresi dolacak makine sertifikaları
Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) } |
  Select-Object Subject, NotAfter, Thumbprint

# Uzak bir hizmetin sertifika konusu ve bitiş tarihi
echo | openssl s_client -connect app.ornek.local:443 -servername app.ornek.local 2>/dev/null \
  | openssl x509 -noout -subject -enddate

CA/Browser Forum kararlarıyla kamuya açık TLS sertifikalarının azami geçerlilik süresi kademeli olarak kısalıyor; güncel takvimi CA/Browser Forum ve sertifika sağlayıcınızdan doğrulayın. Bu eğilim elle yenilemeyi sürdürülemez hale getiriyor. ACME tabanlı otomatik yenileme ve envanterin ağ taramasıyla düzenli güncellenmesi standardın parçası olmalı.

BitLocker kurtarma anahtarlarının yönetimi

Kurtarma anahtarı merkezi olarak saklanmıyorsa şifreleme, anakart arızası veya TPM sıfırlanmasından sonra veri kaybına dönüşür. Anahtar saklama hem kullanılabilirlik hem güvenlik kontrolüdür:

• Entra ID’ye katılmış cihazlarda anahtarın cihaz nesnesine yedeklenmesini Intune politikasıyla zorunlu tutun; yedekleme başarılı olmadan şifreleme başlamamalı.
• Active Directory ortamında anahtarlar bilgisayar nesnesinin altındaki msFVE-RecoveryInformation nesnelerinde saklanır; okuma yetkisini yöneticiler dışında yalnızca yetkilendirilmiş yardım masası rolüne verin.
• Anahtar görüntüleme işlemleri loglanmalı; kullanıcıya teslim edilen anahtar sonradan döndürülmeli (yeni kurtarma parolası oluşturulmalı).

# AD: bir bilgisayar için kayıtlı kurtarma bilgisi (RSAT AD modülü)
$pc = Get-ADComputer "PC-0142"
Get-ADObject -Filter 'objectClass -eq "msFVE-RecoveryInformation"' `
  -SearchBase $pc.DistinguishedName -Properties whenCreated |
  Select-Object Name, whenCreated

Kanıt olarak şifreli cihaz sayısını, kurtarma anahtarı merkezi olarak kayıtlı cihaz sayısıyla karşılaştırın. Aradaki fark, kayıp riski taşıyan cihaz listenizdir. Yedek verisinin şifrelenmesi ve anahtarlarının ayrı ele alınması gereken durumlar için yedek şifreleme ve anahtar yönetimi rehberi tamamlayıcıdır.

Zayıf protokol ve şifre takımı tespiti

Standart yazıldıktan sonra uygulanıp uygulanmadığını ağ taramasıyla ölçersiniz. Tek bir uç noktada hızlı kontrol için OpenSSL, toplu tarama için Nmap’in ssl-enum-ciphers betiği yeterlidir:

# TLS 1.1 ile bağlantı kurulabiliyor mu? (Başarısız olması beklenir)
openssl s_client -connect app.ornek.local:443 -tls1_1 < /dev/null

# Alt ağdaki HTTPS ve LDAPS hizmetlerinde sürüm ve şifre takımları
nmap -p 443,636 --script ssl-enum-ciphers 10.10.20.0/24 -oA tls-tarama

# RDP güvenlik katmanı ve şifreleme düzeyi (ayrı betik)
nmap -p 3389 --script rdp-enum-encryption 10.10.20.0/24

Bazı güncel OpenSSL derlemeleri eski protokolleri istemci tarafında devre dışı bırakır. Yani “bağlanamadı” sonucu her zaman sunucunun desteklemediği anlamına gelmez; sonucu Nmap çıktısıyla teyit edin. Windows sunucularda SCHANNEL protokol ayarları kayıt defteri veya grup ilkesiyle yönetilir; Get-TlsCipherSuite cmdlet’i etkin şifre takımlarını listeler. Eski protokolleri kapatmadan önce onları hâlâ kullanan istemcileri (eski yazıcılar, gömülü cihazlar, eski uygulama sunucuları) tespit edip geçiş planına alın. Yoksa ilk şikâyette değişiklik geri alınır ve kontrol kâğıt üzerinde kalır.

Şifreleme uygulamasının kanıtlanması

Denetimde kabul gören kanıt seti genellikle şunlardan oluşur:

• Onaylı şifreleme ve anahtar yönetimi standardı (algoritmalar, sürümler, sorumluluklar)
• MDM veya yönetim aracından alınan, tarihli disk şifreleme uyumluluk raporu ve uyumsuz cihazların açıklaması
• Kurtarma anahtarı kayıt oranı raporu
• Kritik veritabanları için şifreleme durum sorgusu çıktısı
• Son TLS tarama raporu ve bulunan zayıflıklar için düzeltme kayıtları
• Sertifika envanteri ve yaklaşan bitişler için uyarı mekanizmasının kanıtı

Şifreleme ayarlarını sunucu sıkılaştırma temel çizgisine eklemek ve sürekli ölçmek için sistem ve sunucu güvenlik sıkılaştırma hizmetimize, mevcut durumu bağımsız olarak ölçtürmek için kontrol ve konfigürasyon denetimi hizmetimize bakabilirsiniz.

Sık sorulan sorular

BitLocker açıksa veri tamamen korunuyor mu?

Hayır. Disk şifreleme, cihaz kapalıyken kaybolduğunda veya disk sökülüp başka bir sistemde okunmaya çalışıldığında korur. Sistem açık ve oturum etkinken çalışan zararlı yazılıma veya yetkisiz kullanıcıya karşı korumaz; bunun için erişim kontrolü ve dosya düzeyi şifreleme gerekir.

TLS 1.2 hâlâ kabul edilebilir mi?

Evet. Güvenli şifre takımlarıyla yapılandırıldığında TLS 1.2 kabul edilen asgari sürümdür. TLS 1.0 ve 1.1 RFC 8996 ile kullanımdan kaldırılmıştır. TLS 1.3’ü destekleyen sistemlerde etkinleştirin.

BitLocker kurtarma anahtarlarını nerede saklamalıyız?

Cihazın yönetim modeline göre Entra ID’de cihaz nesnesinde veya Active Directory’de bilgisayar nesnesinin altında. Şifreleme, anahtar yedeklemesi başarılı olmadan başlamamalı; anahtar okuma yetkisi sınırlı tutulmalı ve görüntülemeler loglanmalı.

Şifrelemenin tüm cihazlarda uygulandığını nasıl kanıtlarız?

MDM veya yönetim aracından alınan tarihli uyumluluk raporu, kurtarma anahtarı kayıt oranı, veritabanı şifreleme sorgu çıktıları ve TLS tarama raporu birlikte sunulur. Kapsam dışı cihazların gerekçeli listesi de bu setin parçasıdır.