Şifreleme gizliliği, WORM ise belirli kapsam ve süre içinde değiştirme/silme korumasını ele alır. Politika checkbox’ı uçtan uca motor kabulü değildir; kurulu sürüm ve repository desteğini doğrulayın.
Ekran görüntüleri 16 Ekim 2026 tarihli gerçek laboratuvar arayüzünden alınmıştır. Arayüz İngilizcedir; açıklamalar seçtiğiniz dilde sunulur. Gösterilen kaynak adları, tarihler ve ayarlar örnektir; kendi ortamınızın değerlerini kullanın.
Görsel notu: önceki gerçek VM Advanced Settings ekranı yeniden kullanılmıştır. Encryption ve Worm Protection alanları görünür; kaydedilmemiş lab taslağı çalışma garantisi değildir. Bu rehber hazırlanırken ayar, anahtar veya koruma süresi değiştirilmedi; backup/restore ya da silme testi çalıştırılmadı.
Kurulu sürüm, motor ve repository kimliği
Yetki, anahtar ve kurtarma sorumluları
İzole test verisi ve kabul planı
Katalog kanıtı ve geri yükleme doğrulaması
01
1. Şifreleme katmanını belirleyin
TLS aktarım koruması, repository/işletim sistemi disk şifrelemesi ve backup payload şifrelemesini ayırın. Bir katmanın etkin olması diğerinin etkin olduğunu göstermez. Platform, motor, repository ve sürüm bilgilerini kaydedin.
Beklenen sonuç
Korunacak veri ve şifreleme katmanı belirlenir.
02
2. Sürüm desteğini doğrulayın
OPEN_WORK_ITEMS_20261006 belgesinde müşteri yönetimli AES-256-GCM backup şifrelemesi tasarımı onaylanmış, geliştirme bekliyor olarak işaretlidir. encryption-v1 tasarımını kurulu sürümde hazır destek saymayın; yayın ve motor kabul kanıtı isteyin.
Beklenen sonuç
Tasarım ile kurulu ürün desteği ayrılır.
03
3. Encryption alanını yöntemle eşleştirin
VM Policy Advanced Settings içindeki Encryption alanı formda encryption boolean olarak gönderilir. Bu arayüz tek başına algoritma, anahtar kaynağı veya verinin şifreli yazıldığını kanıtlamaz. Destek doğrulanmadan üretim politikasını bu ekranı izleyerek değiştirmeyin.
Gerçek VM Policy Advanced Settings ekranında Encryption ve Worm Protection seçenekleri. Önceki kaydedilmemiş lab taslağıdır; şifreli veri veya backend değiştirilemezlik kabulünü kanıtlamaz. Büyüt ↗
Beklenen sonuç
Görünen seçenek ile motor kanıtı eşleştirilir.
04
4. Anahtar sahipliği ve erişimi planlayın
Desteklenen çözüm için anahtar sahibi, erişim yetkisi, saklama ve acil kurtarma sorumlusunu belirleyin. Tasarımdaki KMS/Vault veya systemd credential referanslarını mevcut entegrasyon garantisi saymayın. Parola veya özel anahtarı rehbere, komut satırına, loga veya demo formuna koymayın.
Beklenen sonuç
Anahtar erişimi ve kurtarma sorumluluğu belgelenir.
05
5. Full ve artımlı zincir uyumunu kontrol edin
Anahtar rotasyonu, eski zincirlerin anahtar erişimi ve sürümler arası restore uyumunu doğrulayın. Tasarım her Full zinciri için yeni veri anahtarı öngörür; bunun üretimde uygulandığını varsaymayın. Politika değişikliği eski backup’ları otomatik yeniden şifreler anlamına gelmez.
Beklenen sonuç
Eski ve yeni zincirlerin kurtarma gereksinimleri kaydedilir.
06
6. İzole ortamda kabul testi planlayın
Destek doğrulanmış küçük veriyle Full/artımlı restore, hash ve uygulama kabulünü planlayın. Yanlış anahtarın hedefe veri yazmadan reddi ve değiştirilmiş chunk’ın tespiti tasarım kabul kriterleridir; bu çalışmada geçen testler olarak sunulmaz. Gerçek yedeği bozarak test yapmayın.
Beklenen sonuç
Olumlu ve olumsuz kabul senaryoları hazırlanır.
07
7. Kurtarma kanıtını ve işletimi tamamlayın
Test edilen sürüm, yöntem, anahtar referans kimliği ve restore sonucunu gizli değerleri çıkartarak kaydedin. Anahtara erişilemiyorsa veri kurtarılabilirliği riskini sorumluya iletin. TLS sertifikası ve repository erişimini de ayrı doğrulayın; şifreleme WORM veya yedek kopya yerine geçmez.
Hayır. İncelenen form boolean gönderir; müşteri yönetimli akış belgede geliştirme bekliyor durumundadır. Kurulu sürüm ve uçtan uca kabul ayrıca doğrulanmalıdır.