Güvenli Şifreleme ve Hassas Veri Depolama Standartları

Bir veriyi şifrelemek kolay görünebilir, fakat gerçekten güvenli bir sistem kurmak yalnızca AES seçmekten ibaret değildir. Güvenli Şifreleme ve Hassas Veri Depolama Standartları; veri sınıflandırmasından anahtar yönetimine, parola saklamadan TLS yapılandırmasına, yedeklerden log kayıtlarına kadar birbirine bağlı birçok kontrolü kapsar. On yıllık yazılım ve güvenlik çalışmalarımda en sık gördüğüm problem, güçlü bir algoritma kullanıldığı için sistemin bütünüyle güvende olduğunun düşünülmesidir. Oysa yanlış saklanan bir anahtar, tekrar kullanılan bir nonce veya log dosyasına yazılan erişim tokenı güçlü bir algoritmanın sağladığı korumayı etkisiz hâle getirebilir. Bu rehberde hassas veriler güvenli şekilde nasıl şifrelenir ve saklanır, kurumsal sistemlerde veri şifreleme standartları nelerdir ve AES RSA ve hashing yöntemleri hassas veri güvenliğinde nasıl kullanılır sorularını uygulama tarafından ele alacağız. Ayrıca hassas veri depolamada encryption at rest encryption in transit ve anahtar yönetimi için sürdürülebilir bir mimarinin nasıl kurulabileceğini inceleyeceğiz. Amaç yalnızca kavramları tanımlamak değil, gerçek projelerde hangi kararın neden verildiğini anlaşılır hâle getirmektir.

Hassas Veri Nedir?

Hassas veri, yetkisiz kişiler tarafından görülmesi, değiştirilmesi veya kaybedilmesi durumunda bireylere ya da kuruma zarar verebilecek bilgidir. Her hassas veri aynı risk seviyesine sahip değildir ve bu nedenle koruma yöntemi verinin işlevine göre belirlenmelidir. Bir müşterinin iletişim bilgileri ile bir sistemin master encryption key'i aynı güvenlik sınıfında değerlendirilmemelidir. İlk adım, verinin nerede üretildiğini, kim tarafından kullanıldığını ve hangi sistemlere taşındığını anlamaktır. Sağlıklı bir sınıflandırma yapılmadan seçilen şifreleme kontrolleri genellikle eksik veya gereğinden pahalı olur.

Kişisel Veri

Kişisel veri, kimliği belirli veya belirlenebilir gerçek kişiyle ilişkilendirilebilen bilgileri kapsar. İsim, iletişim bilgisi, müşteri numarası veya belirli koşullarda çevrim içi tanımlayıcılar bu kapsamda değerlendirilebilir. Bu verilerin korunmasında yalnızca veritabanı şifrelemesine güvenmek doğru değildir. Erişim yetkileri, saklama süresi, loglama ve veri aktarımı da birlikte kontrol edilmelidir. Uygulamada önce kişisel verinin gerçekten gerekli olup olmadığını sorgulamak, ardından gerekli veriye uygun koruma katmanı seçmek daha sağlıklı sonuç verir.

Özel Nitelikli Kişisel Veri

Özel nitelikli kişisel veriler, yetkisiz erişim durumunda kişi üzerinde daha ağır sonuçlar oluşturabilecek veri gruplarını kapsar. Bu tür bilgiler için erişim kapsamı mümkün olduğunca dar tutulmalıdır. Uygulama seviyesinde alan şifreleme, güçlü kimlik doğrulama ve ayrıntılı audit kayıtları birlikte değerlendirilebilir. Yedekler ve dışa aktarılan raporlar da ana veritabanı kadar önemlidir. Üretim sisteminde şifrelenen bir verinin test ortamına plaintext olarak kopyalanması yapılan bütün yatırımı anlamsız hâle getirebilir.

Finansal Veri

Finansal veriler hesap bilgileri, ödeme verileri, işlem geçmişleri ve benzeri ekonomik bilgileri içerebilir. Bu veriler saldırganlar açısından doğrudan maddi değer taşıdığı için erişim kontrollerinin güçlü olması gerekir. Gereksiz kart veya hesap verilerinin hiç saklanmaması çoğu durumda en güvenli çözümdür. Saklanması zorunlu alanlarda uygulama seviyesi şifreleme veya tokenization gibi yöntemler değerlendirilebilir. Ayrıca finansal verinin log, cache ve yedeklerde istemeden çoğalıp çoğalmadığı düzenli olarak kontrol edilmelidir.

Kimlik Bilgileri

Kimlik numarası, pasaport bilgisi ve benzeri tanımlayıcılar saldırganların hedefleyebileceği değerli veri gruplarıdır. Bu alanlar her sorguda gerekli olmadığı için açık biçimde tutulmaları çoğu zaman gereksiz risk oluşturur. Gerektiğinde field-level encryption kullanılarak yalnızca yetkili servislerin plaintext değer elde etmesi sağlanabilir. Arama gereksinimi varsa veri modelinin şifreleme yöntemiyle birlikte tasarlanması önemlidir. Bir alanı sonradan şifrelemek, indeks ve sorgu davranışını beklenmedik şekilde değiştirebilir.

Authentication Credentials

Authentication credentials kullanıcı veya servis kimliğinin doğrulanmasında kullanılan gizli değerleri ifade eder. Kullanıcı parolaları bu grubun önemli bir örneğidir ancak parola saklama yaklaşımı genel veri şifrelemesinden farklıdır. Parolalar geri çözülebilir biçimde saklanmak yerine uygun password hashing algoritmalarıyla korunmalıdır. Servis kimlik bilgileri ise secret manager gibi kontrollü sistemlerde tutulmalıdır. Bu ayrım yapılmadığında parola ile API secret aynı teknik yönteme zorlanır ve güvenlik tasarımı zayıflar.

API Keys ve Secrets

API key ve secret değerleri uygulamalar arasında yetkili erişim sağlamak için kullanılabilir. Bunları kaynak kodun içine yazmak veya Git deposuna göndermek önemli bir güvenlik hatasıdır. Secrets, erişim politikası ve audit kaydı sunan merkezi bir secret management çözümünde tutulmalıdır. Mümkün olduğunda uzun ömürlü statik secret yerine kısa ömürlü workload credentials tercih edilmelidir. Bir secret sızdığında hızlı rotation yapılabilmesi de tasarımın temel gereksinimlerinden biri olmalıdır.

Cryptographic Keys

Cryptographic key, şifrelenmiş verinin güvenliğini doğrudan belirleyen kritik materyaldir. Veriyi AES-256 ile koruyup anahtarı aynı veritabanında plaintext biçimde saklamak gerçek bir güvenlik sınırı oluşturmaz. Anahtarlar veri katmanından ayrılmalı ve erişimleri ayrı kimlik politikalarıyla yönetilmelidir. KMS veya HSM kullanımı bu ayrımı operasyonel olarak uygulanabilir hâle getirir. Anahtar yaşam döngüsü üretim, kullanım, rotation, revocation, recovery ve destruction aşamalarını kapsamalıdır.

Ticari Sırlar ve Fikri Mülkiyet

Kaynak kod, ürün tasarımı, iş stratejisi ve araştırma çıktıları gibi bilgiler kurum için yüksek ekonomik değere sahip olabilir. Bu verilerin korunması yalnızca yasal sınıflandırmaya göre değil, iş etkisine göre de planlanmalıdır. Özellikle dosya depolama, doküman yönetimi ve yedek sistemleri güvenlik tasarımına dahil edilmelidir. Kullanıcıların gereğinden geniş indirme veya paylaşma yetkisine sahip olması encryption kontrollerini zayıflatabilir. Bu nedenle veri sınıfı ile erişim modeli aynı politika içinde ele alınmalıdır.

Hassas Veriler Neden Sınıflandırılmalıdır?

Veri sınıflandırması, güvenlik yatırımını gerçek riske göre dağıtmanın temel yollarından biridir. Her veriyi en yüksek seviyede korumaya çalışmak maliyeti artırabilir ve ekipleri gereksiz operasyon yükü altında bırakabilir. Buna karşılık kritik veriyi sıradan veri gibi ele almak ciddi güvenlik açıklarına neden olur. Sınıflandırma, encryption policy, retention policy ve erişim kontrolünün ortak başlangıç noktasıdır. Kurumun veri envanteri düzenli güncelleniyorsa yeni sistemlerin hangi koruma seviyesine ihtiyaç duyduğu daha hızlı belirlenebilir.

Data Classification Nedir?

Data classification, bilgilerin hassasiyet ve iş etkisine göre kategorilere ayrılmasıdır. İsimler kurumdan kuruma değişebilir ancak yaygın yapı Public, Internal, Confidential ve Restricted seviyelerini içerir. Sınıf yalnızca etikette kalmamalı, teknik kontrollere bağlanmalıdır. Örneğin Restricted veri için field-level encryption ve dar decrypt yetkisi zorunlu tutulabilir. Böylece sınıflandırma dokümanı uygulama mimarisine doğrudan yön verir.

Public

Public sınıfındaki veriler kamuya açıklanması planlanan veya açıklanması ciddi zarar doğurmayan bilgilerdir. Buna rağmen bütünlük ve kullanılabilirlik gereksinimleri devam eder. Bir web sitesindeki herkese açık içerik gizlilik gerektirmeyebilir ancak yetkisiz değiştirmeye karşı korunmalıdır. TLS kullanımı burada da önemlidir çünkü istemciye ulaştırılan içeriğin güvenilir bir bağlantı üzerinden sunulmasını sağlar. Public etiketi, güvenlik kontrolü gerekmiyor anlamına gelmez.

Internal

Internal veri kurum içinde kullanılmak üzere tasarlanmış ancak kamuya açık olmayan bilgileri kapsar. Dahili prosedürler, bazı teknik dokümanlar veya çalışanlara yönelik operasyon bilgileri bu sınıfa girebilir. Erişim genellikle çalışan kimliği ve rol bazlı yetkilendirme ile sınırlandırılır. Depolama şifrelemesi kurumun tehdit modeline göre uygulanabilir. Ayrıca paylaşım bağlantılarının veya dışa aktarılan dosyaların kontrol edilmesi önemlidir.

Confidential

Confidential veri yetkisiz açıklanması durumunda kuruma veya kişilere önemli zarar verebilecek bilgidir. Bu sınıfta encryption at rest ve encryption in transit çoğunlukla standart kontrol hâline gelir. Erişim yalnızca iş gereksinimi bulunan kimliklerle sınırlandırılmalıdır. Decryption olaylarının kaydedilmesi ve anormal erişimin izlenmesi ek güvenlik sağlar. Backup ve snapshot kopyaları da aynı sınıflandırmayı miras almalıdır.

Restricted

Restricted sınıfı en yüksek koruma ihtiyacı bulunan veri grupları için kullanılabilir. Master keys, yüksek riskli kişisel veriler veya kritik ticari bilgiler bu sınıfta değerlendirilebilir. Sadece encryption yeterli görülmemeli, güçlü kimlik doğrulama ve görev ayrılığı uygulanmalıdır. Bazı durumlarda decrypt işlemleri yalnızca belirli servis kimliklerine açılmalıdır. Anahtarların HSM tarafından korunması da risk ve uyumluluk gereksinimine göre tercih edilebilir.

Veri Sınıfına Göre Encryption Policy

Encryption policy, hangi veri sınıfının nerede ve hangi yöntemle şifreleneceğini tanımlar. Public veri için transport encryption yeterli görülürken Restricted veri için application-level encryption ve ayrı KMS key gerekebilir. Politikanın algoritma adı vermekle sınırlı kalmaması önemlidir. Key ownership, rotation, loglama ve recovery süreçleri de aynı modelin parçasıdır. Böyle bir yaklaşım yeni projelerde kararların kişisel tercihe göre değişmesini azaltır.

Her Veriyi Aynı Anahtarla Şifrelemenin Riski

Tek anahtar kullanımı başlangıçta basit görünse de anahtar sızıntısının etki alanını büyütür. Bir master key doğrudan bütün müşteri verisini şifreliyorsa o anahtarın ele geçirilmesi bütün veri setini etkileyebilir. Tenant veya veri kategorisi bazlı DEK kullanımı blast radius değerini küçültebilir. Envelope encryption bu modeli yönetilebilir hâle getiren yaygın bir yaklaşımdır. Anahtar sayısını artırırken operasyonel yönetim için KMS gibi merkezi sistemlerden yararlanmak gerekir.

Hassas Veri Güvenliğinin İlk Kuralı: Gereksiz Veriyi Saklamamak

Bir veriyi korumanın en güvenilir yollarından biri, ihtiyaç yoksa o veriyi hiç toplamamaktır. Şifrelenmiş olsa bile saklanan her veri erişim, backup, recovery ve anahtar yönetimi yükü oluşturur. Veri minimizasyonu hem saldırı yüzeyini hem de operasyon maliyetini düşürür. Bu nedenle hassas veri güvenliği mimarisine encryption algoritması seçerek değil, veri ihtiyacını sorgulayarak başlanması gerekir. On yıllık proje deneyimimde veri azaltma çalışmalarının birçok güvenlik kontrolünden daha hızlı risk düşürdüğünü gördüm.

Data Minimization

Data minimization yalnızca iş için gerçekten gerekli olan verinin toplanması anlamına gelir. Kayıt formunda kullanılmayacak alanları istemek gelecekte gereksiz risk yaratır. Her veri alanının açık bir kullanım amacı bulunmalıdır. Amaç ortadan kalktığında alanın saklanmaya devam etmesi yeniden değerlendirilmelidir. Bu yaklaşım encryption kapsamını küçültür ve anahtar yönetimini daha sade hâle getirir.

Purpose Limitation

Purpose limitation, verinin toplandığı belirli amaçla uyumlu biçimde kullanılmasını hedefler. Bir veri setinin teknik olarak erişilebilir olması başka amaçlar için kullanılabileceği anlamına gelmez. Uygulama izinleri ve servis sınırları bu amacı desteklemelidir. Veri farklı bir iş sürecine aktarılacaksa risk ve hukuki dayanak yeniden değerlendirilmelidir. Böylece erişim yetkileri yalnızca kullanıcı rolüne değil iş amacına da bağlanabilir.

Retention Policy

Retention policy bir veri türünün ne kadar süre saklanacağını tanımlar. Süresiz saklama çoğu sistemde gereksiz saldırı yüzeyi oluşturur. Saklama süresi iş, hukuk ve operasyon gereksinimleriyle birlikte belirlenmelidir. Süresi dolan verinin ana sistemden, arşivlerden ve uygun koşullarda yedek süreçlerinden kaldırılması planlanmalıdır. Otomatik retention kontrolleri manuel unutma riskini azaltabilir.

Gereksiz PII'ın Silinmesi

PII alanları zamanla uygulama içinde kullanılmadığı hâlde kalabilir. Veri envanteri çalışması bu gereksiz alanları görünür kılar. Bir alan kaldırılırken yalnızca canlı veritabanına bakmak yeterli değildir. Cache, log, backup, analiz tabloları ve test kopyaları da incelenmelidir. Silme sürecinin doğrulanabilir olması veri yönetişimi açısından önemli bir avantaj sağlar.

Üçüncü Taraf Tokenization Hizmetleri

Tokenization, hassas değerin yerine doğrudan anlam taşımayan bir token kullanmayı sağlar. Böylece uygulamanın her bileşeninin gerçek veriyi görmesi gerekmez. Özellikle ödeme gibi belirli senaryolarda gerçek veriyi kendi sisteminizde tutmamak saldırı yüzeyini önemli ölçüde azaltabilir. Token ile gerçek değer arasındaki eşlemenin güvenliği kullanılan hizmet modeline bağlıdır. Mimari karar verirken veri akışının hangi noktalarında plaintext görüldüğü açık biçimde belgelenmelidir.

Data Disposal ve Crypto-Shredding

Data disposal, saklama süresi biten verinin kontrollü biçimde kaldırılmasıdır. Crypto-shredding ise veriyi koruyan anahtarın güvenli şekilde yok edilmesiyle ciphertext'in pratik olarak kullanılamaz hâle getirilmesini amaçlar. Bu yöntem özellikle büyük şifreli veri setlerinde operasyonel avantaj sağlayabilir. Fakat anahtarın yedek veya başka kopyalarının bulunmadığından emin olunmalıdır. Recovery gereksinimi ile kalıcı silme gereksinimi birbirine karıştırılmamalıdır.

Verinin Üç Durumu: At Rest, In Transit ve In Use

Hassas veri güvenliği tasarlanırken verinin yalnızca disk üzerinde bulunduğu an düşünülmemelidir. Veri depolanırken, ağ üzerinden taşınırken ve işlem sırasında bellekte kullanılırken farklı risklerle karşılaşır. Her durum için aynı kontrolün kullanılması mümkün değildir. Encryption at rest disk ve depolama risklerini azaltırken TLS ağ trafiğini korur. In use güvenliği ise uygulama izolasyonu, yetkilendirme, bellek koruması ve bazı özel senaryolarda confidential computing gibi ek yaklaşımlar gerektirebilir.

Data at Rest

Data at rest disk, veritabanı, object storage, backup veya snapshot üzerinde saklanan bilgidir. Full disk encryption fiziksel disk kaybına karşı koruma sağlayabilir ancak çalışan uygulamanın yetkili sorgularını engellemez. Daha hassas alanlar için database veya application-level encryption gerekebilir. Kullanılan anahtarların depolanan veriden ayrılması temel tasarım prensibidir. Backup kopyalarının da aynı güvenlik seviyesini koruması gerekir.

Data in Transit

Data in transit ağ üzerinde bir bileşenden diğerine taşınan bilgiyi ifade eder. HTTPS yalnızca kullanıcı ile web sunucusu arasındaki trafiği korumakla sınırlı düşünülmemelidir. Uygulama ile veritabanı, servisler ve message broker arasında da TLS kullanılmalıdır. Sertifika doğrulaması kapatılırsa TLS kullanımının sağladığı kimlik doğrulama güvencesi zayıflar. İç ağın güvenilir kabul edilmesi modern tehdit modellerinde yeterli bir varsayım değildir.

Data in Use

Data in use uygulama tarafından aktif olarak işlenen veridir. Şifreli veri çoğu klasik uygulamada işlem yapılabilmesi için bir noktada plaintext hâle gelir. Bu nedenle process isolation, least privilege ve bellek güvenliği önem kazanır. Hassas plaintext'in gereğinden uzun süre bellekte tutulmaması tercih edilir. Çok yüksek riskli senaryolarda donanım destekli güvenli yürütme yaklaşımları ayrıca değerlendirilebilir.

Her Veri Durumu İçin Farklı Tehdit Modeli

At rest için temel tehdit disk kopyasının veya depolama ortamının ele geçirilmesi olabilir. In transit için trafik dinleme ve man-in-the-middle riskleri öne çıkar. In use aşamasında uygulama ele geçirilmesi veya yetkili process içinden veri okunması daha önemlidir. Bu tehditler aynı algoritma seçimiyle çözülemez. Tehdit modelinin veri yaşam döngüsünü adım adım izlemesi bu nedenle önemlidir.

Uçtan Uca Veri Koruma Mimarisi

Uçtan uca koruma verinin üretildiği noktadan silindiği ana kadar güvenlik kontrollerinin birlikte tasarlanmasını gerektirir. Kullanıcı bağlantısı TLS ile korunurken backend trafiğinin açık bırakılması gerçek anlamda uçtan uca güvenlik sağlamaz. Aynı şekilde güçlü database encryption kullanıp loglara plaintext PII yazmak da zincirde zayıf halka oluşturur. Veri akış diyagramı oluşturmak bu boşlukları görmek için çok etkilidir. Mimari incelemede her adım için veri biçimi, anahtar erişimi ve loglama davranışı sorulmalıdır.

Encryption, Hashing, Encoding ve Tokenization Arasındaki Fark

Bu kavramların birbirine karıştırılması güvenlik hatalarının önemli nedenlerinden biridir. Encryption geri çözülebilir koruma sağlarken hashing genel olarak tek yönlü özet üretir. Encoding güvenlik amacı taşımaz ve veriyi başka bir gösterim biçimine dönüştürür. Tokenization gerçek değerin yerine başka bir referans kullanmayı sağlar. Doğru teknik, korunacak verinin ileride geri elde edilip edilmeyeceğine ve uygulamanın veri üzerinde hangi işlemleri yapacağına göre seçilmelidir.

Encryption

Encryption, plaintext verinin anahtar kullanılarak ciphertext biçimine dönüştürülmesidir. Yetkili taraf doğru anahtarla veriyi tekrar okuyabilir. Bu nedenle kimlik numarası veya finansal veri gibi daha sonra kullanılması gereken alanlarda uygun olabilir. Güvenlik yalnızca algoritmaya değil mode, nonce ve key management süreçlerine de bağlıdır. Modern sistemlerde authenticated encryption tercih etmek hem gizlilik hem bütünlük açısından avantaj sağlar.

Hashing

Hashing bir girdiden sabit uzunlukta özet üretir ve genel kullanımda geri dönüş işlemi sunmaz. Parola saklama için sıradan hızlı hash yerine özel password hashing algoritmaları gerekir. SHA-256 dosya bütünlüğü gibi birçok amaçta değerlidir ancak tek başına parola saklama çözümü değildir. Salt kullanımı aynı parolaların farklı hash değerleri üretmesini sağlar. Parola doğrulamada yeni hash hesaplanır ve saklanan sonuçla karşılaştırılır.

Encoding

Encoding veriyi belirli taşıma veya gösterim biçimine dönüştürür. Amaç gizlilik sağlamak değildir. Base64 bunun yaygın örneklerinden biridir ve herkes tarafından kolayca geri çevrilebilir. Bu nedenle hassas veriyi Base64 yapıp saklamak şifreleme sayılmaz. Encoding ile encryption arasındaki ayrım geliştirici eğitimlerinde özellikle vurgulanmalıdır.

Base64 Neden Encryption Değildir?

Base64 herhangi bir gizli anahtar kullanmaz. Dönüşüm algoritması açık ve deterministiktir. Bir saldırgan Base64 biçimindeki veriyi kolayca çözebilir. Bu teknik binary veriyi metin tabanlı ortamda taşımak gibi amaçlar için kullanılır. Güvenlik gerektiren veriler için Base64 tek başına hiçbir gizlilik sınırı oluşturmaz.

Tokenization

Tokenization gerçek hassas değerin yerine anlamsız veya sınırlı kullanıma sahip bir token koyar. Uygulamanın bazı parçaları yalnızca token ile çalışarak gerçek veriye ihtiyaç duymaz. Bu yaklaşım hassas verinin erişilebilir olduğu sistem sayısını azaltabilir. Token vault veya eşleme mekanizmasının kendisi güçlü biçimde korunmalıdır. Token formatı gerçek veriyi tahmin etmeyi kolaylaştırmamalıdır.

Data Masking

Data masking kullanıcıya verinin yalnızca gerekli bölümünü göstermeyi amaçlar. Kart numarasının yalnızca son birkaç hanesini göstermek tipik bir örnektir. Masking tek başına gerçek verinin depoda güvenli olduğu anlamına gelmez. Backend hâlâ tam değere erişebiliyorsa uygun encryption kontrolleri gerekebilir. Maskeleme özellikle ekran, rapor ve destek operasyonlarında gereksiz veri ifşasını azaltır.

Pseudonymization

Pseudonymization doğrudan kimliği belirleyen değerlerin başka tanımlayıcılarla değiştirilmesini sağlar. Bu yöntem analitik veya geliştirme senaryolarında risk azaltmaya yardımcı olabilir. Ancak ek bilgiler kullanılarak tekrar ilişkilendirme mümkünse veri tamamen anonim kabul edilmez. Eşleme bilgisi ayrı ve güçlü biçimde korunmalıdır. Pseudonymization veri minimizasyonu ve erişim kontrolünün yerine geçmez.

Hangi Teknik Hangi Veri İçin Kullanılır?

Geri okunması gereken hassas alanlar için encryption düşünülebilir. Kullanıcı parolaları için password hashing tercih edilmelidir. Hassas değerin uygulama içinde kullanılmasına ihtiyaç yoksa tokenization daha uygun olabilir. Görüntüleme sırasında yalnızca sınırlı bölüm gerekiyorsa masking kullanılabilir. Bu seçimleri veri sınıfı, tehdit modeli ve sorgu gereksinimi birlikte belirlemelidir.

Simetrik ve Asimetrik Şifreleme

Kriptografik sistemler çoğunlukla simetrik ve asimetrik yöntemlerin birlikte kullanılmasına dayanır. Simetrik encryption büyük miktarda veriyi hızlı biçimde korurken asimetrik yöntemler anahtar değişimi, kimlik doğrulama ve dijital imza gibi alanlarda güçlü avantajlar sunar. Birini diğerinin yerine zorla kullanmak yerine görevleri doğru biçimde ayırmak gerekir. Modern TLS bağlantıları bu birleşik yaklaşımın tanıdık bir örneğidir. Hibrit tasarım performans ile anahtar dağıtım güvenliğini dengeler.

Symmetric Encryption

Symmetric encryption aynı gizli anahtarın şifreleme ve çözme işlemlerinde kullanıldığı modeldir. AES bu kategorinin en yaygın algoritmalarından biridir. Büyük veri setlerinde performans avantajı sağlar. En önemli operasyon konusu anahtarın güvenli üretimi, dağıtımı ve saklanmasıdır. Anahtar ele geçirilirse o anahtarın koruduğu ciphertext'in gizliliği ciddi biçimde etkilenebilir.

Tek Anahtar Modeli

Tek anahtar modeli kavramsal olarak basittir. Aynı secret key hem encryption hem de decryption tarafında kullanılır. Bu durum anahtar paylaşımının güvenli yapılmasını gerektirir. Çok sayıda servis ve kullanıcı olduğunda tek global anahtar kullanımı riskli hâle gelir. KMS ve envelope encryption bu operasyon problemini azaltabilir.

Büyük Veri İçin Performans Avantajı

Simetrik algoritmalar büyük veri üzerinde asimetrik yöntemlere göre çok daha verimli çalışır. Disk, dosya ve object storage encryption bu nedenle genellikle simetrik anahtarlarla yapılır. Modern işlemciler AES için donanım hızlandırması sunabilir. Performans yine de gerçek iş yükü üzerinde ölçülmelidir. Şifreleme maliyeti yalnızca CPU değil KMS erişimi ve veri taşıma süresini de içerebilir.

Asymmetric Encryption

Asymmetric encryption birbiriyle matematiksel olarak ilişkili public ve private key kullanır. Public key paylaşılabilirken private key gizli tutulmalıdır. RSA ve eliptik eğri tabanlı yöntemler bu kategoride yer alır. Büyük veriyi doğrudan asimetrik algoritmayla şifrelemek çoğu uygulama için uygun değildir. Asimetrik kriptografi daha çok güvenli anahtar değişimi veya küçük anahtar materyallerinin korunması gibi görevlerde kullanılır.

Public Key

Public key gizli tutulması gerekmeyen anahtar bileşenidir. Şifreleme, imza doğrulama veya key agreement senaryosuna göre farklı amaçlarla kullanılabilir. Public olması kimliğinin doğrulanmasına gerek olmadığı anlamına gelmez. Sertifika sistemleri public key'i belirli bir kimlikle ilişkilendirmeye yardımcı olur. Yanlış public key'e güvenmek man-in-the-middle riskine yol açabilir.

Private Key

Private key asimetrik sistemin gizli tutulması gereken en kritik parçalarından biridir. Dosya olarak korunmasız şekilde dağıtılması büyük risk oluşturur. Yüksek güvenlik gereksinimlerinde HSM veya benzeri donanım destekli koruma değerlendirilebilir. Private key erişimi yalnızca gerekli servis kimlikleriyle sınırlandırılmalıdır. Rotation ve revocation süreci sertifika yaşam döngüsüyle birlikte planlanmalıdır.

Hybrid Cryptography

Hybrid cryptography asimetrik ve simetrik yöntemlerin avantajlarını birleştirir. Bir oturum veya data encryption key simetrik algoritmayla veriyi hızlı biçimde korur. Bu anahtar daha sonra uygun bir key wrapping veya asimetrik mekanizmayla güvenli şekilde taşınabilir. TLS protokol ailesinde benzer prensiplerden yararlanılır. Büyük ölçekli depolama sistemlerinde envelope encryption da aynı düşüncenin pratik bir örneğidir.

Modern Sistemlerde Neden İki Yaklaşım Birlikte Kullanılır?

Simetrik encryption performans açısından güçlüdür ancak anahtar paylaşımı zordur. Asimetrik yöntemler anahtar dağıtımını ve kimlik doğrulamayı kolaylaştırır ancak büyük veri için daha maliyetlidir. İki yaklaşımın birlikte kullanılması görevlerin güçlü yönlere göre ayrılmasını sağlar. Böylece büyük veri AES gibi simetrik algoritmayla korunurken anahtar materyali farklı bir mekanizmayla güvence altına alınabilir. Güvenli tasarım çoğu zaman tek algoritma seçmekten çok bu rollerin doğru ayrılmasıdır.

AES Nedir?

AES, modern simetrik şifrelemenin temel algoritmalarından biridir ve farklı anahtar uzunluklarını destekler. Güvenlik değerlendirmesinde yalnızca AES adını görmek yeterli değildir. Kullanılan cipher mode, nonce yönetimi, key generation ve anahtar saklama yöntemi en az anahtar uzunluğu kadar önemlidir. AES-GCM gibi authenticated encryption modu çoğu uygulama senaryosunda güçlü bir seçim sunar. Kurumsal sistemlerde veri şifreleme standartları nelerdir sorusunun yanıtı bu nedenle yalnızca AES-256 demekle tamamlanamaz.

AES-128

AES-128 128 bit anahtar kullanır ve güncel uygulamalarda güçlü simetrik encryption seçeneklerinden biridir. Bazı ekipler daha büyük sayı gördüğü için otomatik olarak AES-256'yı tercih eder. Oysa gerçek güvenlik farkı uygulama bağlamına göre değerlendirilmelidir. Güvenli nonce kullanımı ve anahtar yönetimi hatalıysa daha uzun key size bu sorunları çözmez. Performans, uyumluluk ve uzun vadeli veri gizliliği birlikte ele alınmalıdır.

AES-192

AES-192 192 bit anahtar uzunluğu sunar. Pratik uygulamalarda AES-128 ve AES-256 kadar sık tercih edilmez. Bunun nedeni güvenliksiz olması değil, ekosistemde diğer iki seçeneğin daha yaygın karar noktaları hâline gelmesidir. Kullanılan platform ve uyumluluk gereksinimleri seçimi etkileyebilir. Her durumda güvenli cipher mode ve anahtar yaşam döngüsü gereksinimleri devam eder.

AES-256

AES-256 256 bit anahtar kullanır ve yüksek güvenlik marjı aranan sistemlerde yaygın biçimde tercih edilir. Uzun süre saklanacak hassas veri veya kurum politikaları bu tercihi destekleyebilir. Buna rağmen AES-256 kullanmak tek başına güvenli mimari anlamına gelmez. Anahtar plaintext biçimde kodda bulunuyorsa algoritmanın gücü operasyon hatasını telafi edemez. Sistem tasarımında key management ve erişim sınırları mutlaka birlikte değerlendirilmelidir.

AES'in Kullanıldığı Alanlar

AES disk, veritabanı, dosya, backup ve uygulama seviyesi encryption gibi birçok alanda kullanılabilir. Envelope encryption içinde DEK olarak AES key kullanılması da yaygındır. Kullanım alanı değiştiğinde mode ve anahtar yönetimi gereksinimleri değişebilir. Disk encryption ile tek bir hassas alanın application-level encryption kullanması aynı tehditleri çözmez. Bu nedenle AES kullanıldığı bilgisi güvenlik mimarisini tek başına açıklamaz.

AES Donanım Hızlandırması

Modern işlemciler AES işlemlerini hızlandıran özel komut setleri sunabilir. Bu özellik yüksek veri hacminde CPU maliyetini önemli ölçüde düşürebilir. Ancak donanım desteğinin bulunduğunu varsaymak yerine gerçek ortamda benchmark yapmak gerekir. Container veya sanal makine yapılandırması kullanılabilir kapasiteyi etkileyebilir. Performans testi encryption throughput ile birlikte uygulama latency değerlerini de ölçmelidir.

Key Size ile Gerçek Sistem Güvenliği Arasındaki İlişki

Daha büyük key size her güvenlik probleminin çözümü değildir. AES-256 kullanıp aynı nonce'u tekrar etmek ciddi kriptografik risk oluşturabilir. Anahtarın erişim politikası da key size değerinden bağımsız olarak önemlidir. Gerçek sistem güvenliği algoritma, mode, key management, implementation ve monitoring bileşenlerinin birleşiminden oluşur. Bu nedenle mimari incelemede ilk soru yalnızca kaç bit kullanıldığı olmamalıdır.

Cipher Mode Nedir?

Block cipher algoritmaları gerçek uzunluktaki veriyi işlemek için bir çalışma moduna ihtiyaç duyar. Cipher mode, blokların nasıl işleneceğini ve bütünlük korumasının nasıl sağlanacağını belirler. Yanlış mode seçimi güçlü AES algoritmasının güvenliğini ciddi biçimde düşürebilir. Modern uygulamalarda authenticated encryption sunan modlar tercih edilmelidir. Library seçerken nonce ve authentication tag yönetiminin doğru API'lerle desteklenmesi de önemlidir.

AES-GCM

AES-GCM gizlilik ile bütünlük doğrulamasını bir arada sunan authenticated encryption modudur. Modern uygulamalarda sık tercih edilmesinin temel nedenlerinden biri budur. Nonce değerinin aynı anahtar altında güvenli biçimde yönetilmesi kritik öneme sahiptir. Ciphertext ile authentication tag birlikte saklanmalıdır. Uygulama decrypt işleminden önce tag doğrulamasını güvenilir library üzerinden yapmalıdır.

Confidentiality

Confidentiality yetkisiz tarafların plaintext veriyi okuyamamasını hedefler. AES-GCM ciphertext üreterek bu gizlilik katmanını sağlar. Ancak anahtarın korunması bu garantinin temel koşuludur. Key erişimi sınırsızsa ciphertext'in depoda bulunması yeterli güvenlik sağlamaz. Gizlilik kontrolü her zaman kimlik ve erişim politikasıyla birlikte düşünülmelidir.

Integrity

Integrity verinin yetkisiz biçimde değiştirilip değiştirilmediğinin anlaşılmasını sağlar. Sadece şifreleme yapmak her zaman bütünlük garantisi vermez. GCM authentication tag aracılığıyla ciphertext üzerinde değişikliklerin tespit edilmesine yardımcı olur. Uygulama tag doğrulaması başarısız olduğunda veriyi kesinlikle kullanmamalıdır. Hata davranışı da güvenlik tasarımının bir parçasıdır.

Authentication Tag

Authentication tag ciphertext'in doğruluğunu kontrol etmek için kullanılan kriptografik çıktıdır. Tag saklanırken gizli tutulmak zorunda değildir ancak değiştirilmesine karşı doğrulama mekanizmasının parçasıdır. Decryption sırasında tag doğru değilse işlem başarısız kabul edilmelidir. Tag uzunluğunun keyfi biçimde düşürülmesi güvenlik seviyesini etkileyebilir. Güvenilir library'nin önerilen varsayılanları tercih edilmelidir.

CBC

CBC geçmişte çok yaygın kullanılan bir block cipher modudur. Kendi başına modern authenticated encryption özelliği sağlamaz. Bu nedenle bütünlük ve authenticity için ek MAC tasarımı gerekir. Encrypt-then-MAC gibi desenler doğru uygulanmadığında hata yapma riski artar. Yeni sistemlerde uygun AEAD seçeneği mevcutsa daha sade ve güvenli API'ler tercih edilmelidir.

CTR

CTR block cipher'ı stream benzeri biçimde kullanmaya olanak tanır. Gizlilik sağlayabilir ancak tek başına ciphertext bütünlüğünü doğrulamaz. Nonce veya counter tekrar kullanımı ciddi risk oluşturur. Bu nedenle ek authentication mekanizması gerekir. Modern uygulamalarda hazır AEAD primitive kullanmak manuel CTR ve MAC birleşiminden daha güvenli bir yaklaşım olabilir.

XTS

XTS özellikle disk ve storage encryption senaryolarında kullanılan bir mode'dur. Sektör bazlı kullanım amacı, genel mesaj şifreleme gereksinimlerinden farklıdır. Bütünlük koruması sağlayan genel AEAD çözümünün yerine uygulama mesajlarında kullanılmamalıdır. Disk sektörlerinde aynı plaintext yapısının güvenli şekilde işlenmesine yönelik tasarlanmıştır. Kullanım bağlamı yanlış seçildiğinde mode'un güçlü olduğu alan dışına çıkılmış olur.

ECB Neden Kullanılmamalıdır?

ECB aynı plaintext bloklarının aynı anahtar altında aynı ciphertext bloklarına dönüşmesine neden olur. Bu özellik veri içindeki desenlerin görünür kalmasına yol açabilir. Özellikle yapılandırılmış veya görsel verilerde bilgi sızıntısı açık biçimde ortaya çıkabilir. Güçlü AES algoritması kullanılması bu mode problemini ortadan kaldırmaz. Genel uygulama encryption tasarımlarında ECB'den kaçınılmalıdır.

Authenticated Encryption Neden Tercih Edilmelidir?

Authenticated encryption gizlilik ile bütünlük doğrulamasını aynı primitive içinde sunar. Bu yaklaşım geliştiricinin ayrı encryption ve MAC işlemlerini yanlış sırada birleştirme riskini azaltır. AES-GCM ve ChaCha20-Poly1305 yaygın AEAD seçenekleridir. Library API'si nonce ve tag kullanımını açık biçimde yönetebilmelidir. Güvenlik açısından daha az manuel kriptografik kombinasyon genellikle daha az uygulama hatası anlamına gelir.

ChaCha20-Poly1305 Nedir?

ChaCha20-Poly1305 modern authenticated encryption seçeneklerinden biridir. ChaCha20 stream cipher gizlilik sağlarken Poly1305 authentication mekanizması bütünlük ve authenticity kontrolüne katkı verir. Özellikle donanım AES hızlandırması bulunmayan bazı platformlarda güçlü performans sunabilir. TLS gibi modern protokollerde desteklenmesi yaygınlaşmıştır. Seçim yapılırken platform performansı, uyumluluk ve kullanılan library'nin güvenilirliği birlikte değerlendirilmelidir.

ChaCha20

ChaCha20 simetrik stream cipher ailesinin modern bir üyesidir. Veriyi sabit blok cipher mantığı yerine keystream yaklaşımıyla işler. Nonce tekrar kullanımından kaçınmak burada da kritik öneme sahiptir. Tek başına bütünlük doğrulaması sağlamadığı için uygulamalarda genellikle Poly1305 ile birlikte kullanılır. Hazır ChaCha20-Poly1305 API'si manuel primitive birleştirmekten daha güvenlidir.

Poly1305

Poly1305 mesaj doğrulaması için kullanılan bir authentication mekanizmasıdır. ChaCha20 ile birlikte kullanıldığında AEAD modeli oluşturur. Amaç yalnızca ciphertext üretmek değil, değiştirilmiş verinin kabul edilmesini de engellemektir. Authentication başarısız olduğunda uygulama plaintext kullanmamalıdır. Hata mesajlarının gereksiz iç bilgi sızdırmaması da önemlidir.

AEAD Modeli

AEAD, authenticated encryption with associated data yaklaşımını ifade eder. Şifrelenen veri gizli tutulurken bazı ek metadata şifrelenmeden bütünlük korumasına dahil edilebilir. Örneğin protokol başlığının belirli alanları associated data olarak doğrulanabilir. Bu model modern güvenli protokollerde güçlü bir tasarım deseni sunar. Associated data'nın encrypt edilmediği unutulmamalı ve içine gizli bilgi konulmamalıdır.

AES-GCM ile Karşılaştırma

AES-GCM ve ChaCha20-Poly1305 modern AEAD seçenekleridir. AES donanım hızlandırması bulunan sistemlerde AES-GCM çok yüksek performans sağlayabilir. Donanım desteğinin sınırlı olduğu platformlarda ChaCha20-Poly1305 avantajlı olabilir. Güvenlik kararını yalnızca benchmark sonucu vermek yeterli değildir. Platform desteği, standardizasyon ihtiyacı ve library kalitesi de değerlendirilmelidir.

Donanım AES Desteği Olmayan Sistemlerde Kullanım

Donanım AES hızlandırması olmayan cihazlarda software AES daha fazla işlemci maliyeti oluşturabilir. ChaCha20-Poly1305 bu tür ortamlarda verimli bir alternatif sunabilir. Mobil veya düşük güçlü cihazlarda gerçek performans ölçümü önemlidir. Seçim yapılırken protokol ve karşı taraf desteği de kontrol edilmelidir. Güvenilir bir crypto library üzerinden hazır AEAD primitive kullanılmalıdır.

Nonce ve Initialization Vector (IV) Nedir?

Nonce ve IV, encryption işleminin aynı plaintext ve key kombinasyonunda güvenli çeşitlilik üretmesine yardımcı olan değerlerdir. Gereksinimleri kullanılan algoritma ve mode'a göre değişir. Bu değerlerin her zaman gizli olması gerekmez fakat tekrar kullanımı bazı modlarda ciddi güvenlik sonuçları oluşturabilir. En güvenli yaklaşım kullanılan library ve standardın nonce gereksinimini doğrudan izlemektir. Nonce yönetimi key management kadar görünür olmasa da gerçek sistem güvenliği için temel öneme sahiptir.

Nonce Neden Gereklidir?

Nonce aynı anahtar altında encryption işlemlerinin benzersiz bağlamda gerçekleşmesini sağlar. Aynı plaintext'in her seferinde aynı ciphertext üretmesini önlemeye yardımcı olabilir. Bazı AEAD modlarında nonce tekrar kullanımı güvenliği ciddi biçimde bozar. Bu nedenle nonce üretim stratejisi açıkça tanımlanmalıdır. Rastgele veya counter tabanlı yaklaşım seçimi kullanılan primitive'in gereksinimine göre yapılmalıdır.

IV Neden Tekrar Kullanılmamalıdır?

IV gereksinimi kullanılan cipher mode'a bağlıdır. Bazı modlarda benzersizlik temel güvenlik koşuludur. Aynı key ile uygun olmayan IV tekrar kullanımı plaintext hakkında bilgi sızdırabilir. Geliştiricinin kendi IV formatını tasarlaması yerine library rehberi izlenmelidir. IV'nin ciphertext yanında saklanabilmesi onun önemsiz olduğu anlamına gelmez.

Nonce Reuse Felaket Senaryosu

Nonce reuse özellikle GCM benzeri modlarda çok ciddi sonuçlara yol açabilir. Aynı key ve nonce kombinasyonunun tekrar edilmesi gizlilik ve authentication özelliklerini etkileyebilir. Bu hata yüksek trafikli dağıtık sistemlerde sayaç yönetimi yanlış tasarlandığında ortaya çıkabilir. Key rotation tek başına geçmişte oluşmuş tekrar kullanımını geri alamaz. Tasarım aşamasında nonce uniqueness gereksinimi ölçek ve concurrency dikkate alınarak test edilmelidir.

Random ve Counter-Based Nonce

Nonce üretimi rastgele veya sayaç tabanlı yöntemlerle yapılabilir. Hangi yaklaşımın uygun olduğu primitive'in nonce boyutuna ve benzersizlik gereksinimine bağlıdır. Rastgele yöntemde yeterli entropy ve çarpışma olasılığı değerlendirilmelidir. Counter yaklaşımında dağıtık süreçlerin aynı değeri üretmemesi garanti edilmelidir. Uygulama tasarımında library'nin önerdiği model öncelikli olmalıdır.

Nonce'un Ciphertext ile Birlikte Saklanması

Nonce çoğu encryption tasarımında gizli bilgi değildir. Bu nedenle ciphertext ile birlikte saklanması yaygın bir uygulamadır. Önemli olan aynı key altında gereken benzersizlik koşulunun korunmasıdır. Ciphertext metadata formatı nonce, algorithm version ve key identifier gibi alanları taşıyabilir. Versioned metadata ileride crypto migration yapılmasını da kolaylaştırır.

Güvenli Rastgele Sayı Üretimi

Kriptografik sistemler güçlü ve öngörülemez rastgele değerlere ihtiyaç duyar. Anahtar, salt, nonce ve güvenlik tokenı üretiminde genel amaçlı pseudo-random fonksiyonlara güvenilmemelidir. İşletim sisteminin veya güvenilir crypto library'nin CSPRNG mekanizması kullanılmalıdır. Rastgelelik hatası güçlü algoritmaları bile zayıflatabilir. Özellikle token üretiminde tahmin edilebilir değerler doğrudan hesap ele geçirme riskine dönüşebilir.

CSPRNG Nedir?

CSPRNG cryptographically secure pseudo-random number generator anlamına gelir. Çıktılarının saldırgan tarafından tahmin edilmesini zorlaştıracak güvenlik özellikleri hedeflenir. Modern işletim sistemleri geliştiricilere güvenli randomness API'leri sunar. Uygulamanın kendi entropy toplama mekanizmasını yazması genellikle gerekli değildir. Standard library içinde güvenlik amacıyla tasarlanmış API tercih edilmelidir.

Normal PRNG ile CSPRNG Arasındaki Fark

Genel PRNG simülasyon, oyun veya istatistik gibi amaçlar için yeterli olabilir. Güvenlik tokenı veya encryption key üretimi için ise tahmin edilebilirlik kabul edilemez. CSPRNG bu tehdit modeli için tasarlanmıştır. Programlama dilinde random isimli fonksiyonun bulunması onun kriptografik olarak güvenli olduğunu garanti etmez. Dokümantasyonda security veya cryptographic kullanım için önerilen API kontrol edilmelidir.

Key Generation

Encryption key'leri yeterli entropy ile üretilmelidir. Kullanıcı parolasını doğrudan AES key olarak kullanmak uygun değildir. Parola tabanlı anahtar gerekiyorsa uygun KDF mekanizması kullanılmalıdır. KMS ve HSM sistemleri key generation işlemini güvenli ortamda gerçekleştirebilir. Anahtar üretildikten sonra erişim, kullanım amacı ve sahiplik metadata'sı tanımlanmalıdır.

Salt Generation

Salt parola hashing işleminde her kayıt için benzersizlik sağlar. Salt gizli tutulması gereken bir secret değildir. Güvenli rastgele üretim kullanılması çakışma riskini azaltır. Modern password hashing library'leri salt üretimini çoğu zaman otomatik yönetir. Uygulama library'nin güvenli varsayılanlarını gereksiz yere değiştirmemelidir.

Nonce Generation

Nonce üretimi kullanılan cipher'ın beklediği kurala uygun yapılmalıdır. GCM gibi modlarda benzersizlik kritik güvenlik koşuludur. CSPRNG veya güvenli counter tasarımı kullanılabilir. Dağıtık node'lar aynı key altında bağımsız nonce üretirken çakışma riski ayrıca düşünülmelidir. Nonce yönetimini test senaryolarına dahil etmek önemli bir güvenlik pratiğidir.

Token Generation

Password reset, session veya API erişim tokenları tahmin edilemez olmalıdır. Token üretiminde CSPRNG kullanılmalı ve yeterli entropy sağlanmalıdır. Tokenların loglara yazılması da ayrı bir sızıntı kaynağı oluşturabilir. Mümkün olduğunda tokenlara kısa kullanım süresi ve belirli amaç sınırı verilmelidir. Token iptali ve rotation davranışı güvenlik tasarımının parçası olmalıdır.

UUID Her Zaman Güvenli Token mıdır?

UUID kullanımı tek başına güvenli token garantisi vermez. UUID sürümlerinin üretim yöntemi ve entropy özellikleri farklıdır. Bazı UUID biçimleri benzersiz kimlik üretmek için uygundur ancak authentication secret olarak tasarlanmamıştır. Güvenlik amacı varsa doğrudan CSPRNG tabanlı token üretmek daha açık bir tasarımdır. Benzersizlik ile tahmin edilemezlik aynı özellik değildir.

Parolalar Nasıl Güvenli Saklanmalıdır?

Kullanıcı parolaları geri çözülebilir encryption ile saklanmamalıdır. Sistem login doğrulaması için gerçek parolayı yeniden elde etmek zorunda değildir. Bunun yerine Argon2id, scrypt, bcrypt veya belirli uyumluluk koşullarında PBKDF2 gibi parola saklamaya uygun algoritmalar kullanılabilir. Her parola benzersiz salt ile işlenmeli ve parametreler donanıma göre ölçülmelidir. Güvenli parola saklama tasarımında amaç çevrim dışı parola tahmin saldırısını mümkün olduğunca maliyetli hâle getirmektir.

Parolalar Neden Encrypt Edilmemelidir?

Encryption geri çözülebilir olduğu için uygulamanın bir decryption key saklamasını gerektirir. Bu anahtar ele geçirilirse bütün kullanıcı parolaları toplu biçimde açığa çıkabilir. Authentication işlemi için parolanın plaintext olarak geri elde edilmesine ihtiyaç yoktur. Password hashing doğrulama için yeterlidir. Bu nedenle standart login sistemlerinde reversable password storage kullanılmamalıdır.

Password Hashing Nedir?

Password hashing parolayı özel bir tek yönlü ve maliyetli fonksiyonla saklama yöntemidir. Kullanıcı giriş yaptığında girilen parola aynı parametrelerle işlenir ve kayıtla karşılaştırılır. Algoritmanın kasıtlı olarak yavaş olması saldırganın milyarlarca tahmin yapmasını zorlaştırır. Modern seçenekler yalnızca CPU değil bellek maliyetini de kullanabilir. Hash formatında algorithm ve cost parametrelerinin saklanması ileride migration yapılmasını kolaylaştırır.

Salt Nedir?

Salt her parola kaydına eklenen benzersiz bir değerdir. Aynı parolayı kullanan iki kullanıcının farklı hash sonuçları elde etmesine yardımcı olur. Önceden hesaplanmış genel tabloların etkinliğini azaltır. Salt gizli değildir ve hash ile birlikte saklanabilir. Modern password hashing library'leri bu işlemi güvenli şekilde otomatikleştirebilir.

Pepper Nedir?

Pepper parola hash sürecine eklenen ve veritabanından ayrı saklanan gizli bir değerdir. Salt'tan farklı olarak secret kabul edilir. Pepper kullanılıyorsa secret manager veya KMS benzeri ayrı güvenlik alanında korunmalıdır. Pepper kaybı veya sızıntısı için rotation stratejisi düşünülmelidir. Bu kontrol sağlam password hashing uygulamasının yerine değil, ek savunma katmanı olarak kullanılmalıdır.

Work Factor Nedir?

Work factor bir password hashing işleminin hesaplama maliyetini belirleyen parametredir. Değer yükseldikçe hem meşru doğrulama hem saldırganın parola tahmin denemesi daha pahalı hâle gelir. Çok düşük değer saldırıları kolaylaştırır. Aşırı yüksek değer ise login performansı ve kaynak tüketimi sorunları yaratabilir. Bu nedenle gerçek sunucu donanımında benchmark yapılarak dengeli değer belirlenmelidir.

Memory-Hard Algorithm Nedir?

Memory-hard algoritmalar hesaplamanın yanında önemli miktarda bellek kullanımını da maliyetin parçası hâline getirir. Bu özellik yüksek paralellik sunan saldırı donanımlarının avantajını azaltmayı hedefler. Argon2 ailesi bu yaklaşımın önemli örneklerinden biridir. Parametre seçimi uygulama sunucusunun kapasitesine göre yapılmalıdır. Bellek maliyetini gereksiz düşük tutmak algoritmanın sağladığı avantajı azaltabilir.

Argon2id Nedir?

Argon2id modern parola saklama için güçlü seçeneklerden biridir. Argon2i ve Argon2d yaklaşımlarının özelliklerini birleştirerek farklı saldırı modellerine karşı dengeli koruma hedefler. Parametreleri memory cost, iteration count ve parallelism gibi değerlerle ayarlanabilir. Tek bir evrensel parametre yerine uygulama donanımında ölçüm yapılması önemlidir. Zaman içinde donanım hızlandıkça cost değerlerinin yeniden değerlendirilmesi gerekir.

Argon2i, Argon2d ve Argon2id

Argon2 ailesi farklı bellek erişim davranışlarına sahip varyantlar içerir. Argon2i side-channel risklerine karşı farklı tasarım tercihleri kullanır. Argon2d hesaplama saldırılarına karşı farklı özellikler sunar. Argon2id iki yaklaşımı birleştiren dengeli varyant olarak parola saklamada yaygın biçimde önerilir. Uygulama geliştiricileri güncel library ve güvenlik rehberinin önerisini izlemelidir.

Memory Cost

Memory cost hashing işlemi sırasında ayrılacak bellek miktarını belirler. Daha yüksek değer saldırganın çok sayıda paralel deneme yapmasını pahalılaştırabilir. Fakat uygulama sunucusunda eşzamanlı login trafiği de hesaba katılmalıdır. Parametre seçimi yalnızca tek bir hash benchmark'ıyla yapılmamalıdır. Gerçek concurrency altında memory pressure ölçülmelidir.

Iteration Count

Iteration count algoritmanın belirli hesaplama adımlarını kaç kez uygulayacağını etkiler. Değer artırıldığında doğrulama süresi yükselir. Amaç kullanıcı deneyimini bozmayacak fakat saldırgana anlamlı maliyet oluşturacak bir denge kurmaktır. Sunucu donanımı değiştiğinde benchmark yenilenmelidir. Cost değerleri config üzerinden yönetilebilirse ileride güncelleme daha kolay olur.

Parallelism

Parallelism Argon2 hesaplamasının paralel çalışma davranışını etkileyen parametrelerden biridir. Yüksek değer her sistemde otomatik olarak daha güvenli veya daha hızlı değildir. CPU çekirdeği, bellek bant genişliği ve eşzamanlı kullanıcı sayısı sonucu değiştirir. Üretim benzeri ortamda benchmark yapılmalıdır. Parametreler dokümante edilmeli ve güvenlik incelemesinde görünür olmalıdır.

Donanıma Göre Parametre Benchmark'ı

Password hashing parametresi geliştiricinin dizüstü bilgisayarında değil hedef çalışma ortamında ölçülmelidir. Login endpoint'i için kabul edilebilir latency aralığı belirlenebilir. Ardından memory ve CPU kullanımı eşzamanlı istek altında test edilir. Amaç saldırgan için maliyeti artırırken meşru trafiğin sürdürülebilir kalmasını sağlamaktır. Benchmark sonucu sürüm kontrolündeki güvenlik dokümantasyonuna kaydedilebilir.

Password Hash Parametreleri Zamanla Nasıl Güncellenir?

Password hash formatı kullanılan algoritma ve parametre bilgisini taşıyabilmelidir. Kullanıcı başarılı login yaptığında eski parametrelerle oluşturulan hash tespit edilebilir. Parola o anda elde olduğu için daha güçlü parametrelerle yeniden hash edilerek kayıt güncellenebilir. Böylece tüm kullanıcıların parolalarını aynı anda bilmeye gerek kalmaz. Uzun süre login olmayan hesaplar için ayrıca migration politikası belirlenebilir.

bcrypt, scrypt ve PBKDF2 Ne Zaman Kullanılır?

Parola saklama algoritması seçimi yeni sistem, legacy uyumluluğu ve regülasyon gereksinimlerine göre değişebilir. Argon2id modern sistemlerde güçlü bir varsayılan olsa da her ortamda kullanılabilir olmayabilir. scrypt bellek maliyetli alternatif sunar. bcrypt uzun yıllardır kullanılan olgun bir seçenektir ancak parola uzunluğu ve cost davranışı gibi özellikleri bilinmelidir. PBKDF2 özellikle belirli FIPS uyumluluğu gereken sistemlerde değerlendirilir.

bcrypt

bcrypt adaptif work factor sunan ve uzun süredir kullanılan password hashing algoritmasıdır. Yeni sistemlerde güncel rehberler Argon2id gibi seçenekleri öne çıkarabilir. Legacy uygulamalarda bcrypt hâlâ uygun parametrelerle kullanılabilir. Parola uzunluğu davranışı kullanılan implementation üzerinden kontrol edilmelidir. Work factor düzenli olarak benchmark edilip güncellenmelidir.

scrypt

scrypt parola türetme ve saklama için bellek maliyetini kullanan algoritmadır. Argon2id bulunmadığında güçlü bir alternatif olabilir. CPU ve memory parametrelerinin güvenli seçilmesi gerekir. Library'nin güvenli, aktif bakım gören sürümü kullanılmalıdır. Donanıma göre gerçek authentication latency ölçülmelidir.

PBKDF2

PBKDF2 iterasyon tabanlı yaygın bir password derivation algoritmasıdır. Çok sayıda platformda desteklenmesi önemli avantajdır. Memory-hard olmadığı için iteration count yeterince yüksek seçilmelidir. Özellikle FIPS gereksinimleri bazı kurumlarda PBKDF2 kullanımını gündeme getirebilir. Parametreler statik bırakılmamalı ve zaman içinde yeniden değerlendirilmelidir.

FIPS Gereksinimlerinde PBKDF2

FIPS uyumluluğu gerektiren ortamlarda yalnızca algoritma adına bakmak yeterli değildir. Kullanılan cryptographic module'un doğrulama durumu da önem taşır. PBKDF2 uygun module ve yapılandırma içinde tercih edilebilir. Organizasyonun uyumluluk kapsamı açık biçimde tanımlanmalıdır. FIPS mode açmanın bütün uygulama güvenlik kontrollerini otomatik sağlamadığı unutulmamalıdır.

Legacy Hash Migration

Eski sistemlerde MD5, SHA-1 veya düşük maliyetli eski password hash kayıtları bulunabilir. Migration sırasında kullanıcılardan tüm parolaları yeniden istemek her zaman mümkün değildir. Başarılı login sonrasında mevcut parola daha güçlü algoritmayla yeniden hash edilebilir. Kullanılmayan hesaplar için ayrı süre ve reset politikası uygulanabilir. Migration tamamlanana kadar eski hash formatına sahip kullanıcı sayısı güvenlik metriği olarak izlenmelidir.

SHA-256 Neden Password Storage İçin Yeterli Değildir?

SHA-256 güçlü ve yaygın bir cryptographic hash fonksiyonudur ancak parola saklama amacıyla tasarlanmamıştır. Çok hızlı çalışması dosya bütünlüğü gibi kullanım alanlarında avantajdır. Parola saldırısında ise aynı hız saldırganın çok sayıda tahmin yapabilmesine yardımcı olur. Salt eklemek rainbow table riskini azaltır ancak hızlı brute-force problemini çözmez. Parolalar için yavaş ve mümkünse memory-hard password hashing algoritmaları kullanılmalıdır.

Fast Hash Problemi

Fast hash algoritmaları saniyede çok yüksek sayıda hesaplama yapılabilecek şekilde verimlidir. Bu özellik saldırganın çalınmış parola hashleri üzerinde çok sayıda tahmin denemesini kolaylaştırır. Kullanıcıların zayıf veya tekrar kullanılan parolaları bu durumda daha hızlı bulunabilir. Password hashing algoritmaları bu nedenle kasıtlı maliyet ekler. Güvenlik hedefi hash hesaplamasını mümkün olduğunca hızlı yapmak değildir.

GPU Password Cracking

GPU donanımları çok sayıda paralel hesaplama yapmak için tasarlanmıştır. Hızlı hash fonksiyonları bu paralellikten ciddi ölçüde yararlanabilir. Memory-hard algoritmalar saldırganın donanım avantajını azaltmayı hedefler. Bu nedenle sadece key length veya hash output uzunluğu karşılaştırmak doğru değildir. Algoritmanın saldırı maliyeti de değerlendirilmelidir.

Rainbow Tables

Rainbow table önceden hesaplanmış parola ve hash eşlemelerinden yararlanmayı hedefleyen saldırı yaklaşımıdır. Benzersiz salt kullanımı genel tabloların doğrudan kullanılmasını zorlaştırır. Ancak salt parolayı güçlü hâle getirmez ve hızlı brute-force saldırısını durdurmaz. Bu nedenle salt ile uygun password hashing algoritması birlikte kullanılmalıdır. Modern library'ler salt yönetimini çoğu zaman otomatik gerçekleştirir.

Slow ve Memory-Hard Hashing'in Avantajı

Yavaş hashing her parola tahmininin maliyetini artırır. Memory-hard tasarım bu maliyete önemli miktarda bellek gereksinimi de ekler. Saldırgan çok sayıda paralel deneme yapmak istediğinde toplam donanım maliyeti yükselir. Meşru kullanıcı ise login başına yalnızca birkaç hash işlemi yaptığı için bu maliyeti daha kolay karşılar. Parametrelerin gerçek sunucu kapasitesine göre dengelenmesi gerekir.

HMAC Nedir?

HMAC secret key ile hash fonksiyonunu birleştirerek mesaj bütünlüğü ve kaynağın doğrulanmasına yönelik mekanizma sağlar. Normal hash'ten temel farkı hesaplama için gizli anahtar gerekmesidir. HMAC şifreleme değildir ve mesajı gizlemez. API request signing, webhook doğrulama ve bazı integrity senaryolarında kullanılabilir. Güvenliği kullanılan key'in üretimi ve saklanmasıyla doğrudan ilişkilidir.

Hash ile HMAC Arasındaki Fark

Normal hash hesaplamak için gizli anahtar gerekmez. Veriyi bilen herkes aynı hash değerini üretebilir. HMAC ise secret key gerektirdiği için mesajın yalnızca veriyi bilen biri tarafından oluşturulduğunu söylemekten daha güçlü bir doğrulama sağlar. Buna rağmen secret sızarsa bu güven kaybolur. HMAC ve encryption farklı güvenlik hedeflerine hizmet eder.

Integrity ve Authenticity

Integrity mesajın değiştirilmediğini doğrulamayı hedefler. Authenticity ise mesajın beklenen secret'a sahip taraf tarafından üretildiğine dair güvence sağlar. HMAC bu iki ihtiyaca katkıda bulunabilir. Mesaj içeriğinin gizlenmesini sağlamaz. Gizlilik de gerekiyorsa ayrıca encryption veya uygun AEAD tasarımı kullanılmalıdır.

HMAC-SHA-256

HMAC-SHA-256 yaygın kullanılan HMAC yapılandırmalarından biridir. SHA-256 burada doğrudan parola hashleme amacıyla değil HMAC yapısının parçası olarak kullanılır. Kullanılan secret key yeterli entropy ile üretilmelidir. Key rotation protokolün iki tarafında koordineli biçimde yönetilmelidir. Signature karşılaştırması mümkün olduğunda constant-time comparison API'siyle yapılmalıdır.

API Request Signing

API request signing isteğin belirli alanlarının HMAC ile imzalanmasını içerebilir. Timestamp ve nonce gibi alanlar replay riskini azaltmak için tasarıma eklenebilir. Canonical request formatı iki taraf arasında kesin olarak tanımlanmalıdır. Secret key HTTP loglarına veya uygulama config dump'larına düşmemelidir. İmza doğrulaması yapılmadan iş mantığı çalıştırılmamalıdır.

Key Management Gereksinimi

HMAC güvenliği secret key'e bağlıdır. Key source code içinde tutulmamalıdır. Merkezi secret manager veya KMS destekli mekanizma değerlendirilebilir. Rotation sırasında eski ve yeni key için kısa geçiş penceresi gerekebilir. Hangi key'in hangi entegrasyonda kullanıldığı inventory içinde izlenmelidir.

Data at Rest Encryption Nasıl Yapılır?

Data at rest encryption tek bir katmandan oluşmak zorunda değildir. Disk, volume, file, database, object storage ve backup seviyelerinde farklı koruma seçenekleri bulunur. Hangi katmanın seçileceği tehdit modeline göre belirlenmelidir. Disk encryption cihaz kaybına karşı faydalıyken application-level encryption yetkili database kullanıcısına karşı daha güçlü ayrım sağlayabilir. Katmanları birbirinin yerine değil, çözdükleri tehditlere göre değerlendirmek gerekir.

Full Disk Encryption

Full disk encryption cihaz veya fiziksel disk ele geçirildiğinde depolanan bilgileri korumaya yardımcı olur. İşletim sistemi çalışırken yetkili süreçler veriyi normal şekilde okuyabilir. Bu nedenle uygulama veya database hesabının ele geçirilmesini doğrudan engellemez. Laptop ve sunucu disk güvenliği için önemli bir temel kontroldür. Recovery key yönetimi ayrıca güvenli biçimde planlanmalıdır.

Volume Encryption

Volume encryption belirli disk veya volume üzerinde depolanan veriyi korur. Cloud block storage sistemlerinde sıklıkla platform özelliği olarak sunulur. Kullanılan encryption key'in platform managed veya customer managed olması kontrol seviyesini değiştirir. Snapshot'ların aynı encryption politikasını devam ettirip ettirmediği doğrulanmalıdır. Volume açık ve mount edilmiş durumdayken uygulama erişimi ayrı kontroller gerektirir.

File Encryption

File encryption belirli dosyaların ayrı cryptographic sınır içinde korunmasını sağlar. Paylaşılan storage veya export dosyalarında faydalı olabilir. Anahtarın dosyayla aynı klasörde plaintext tutulmaması gerekir. Dosya adı ve metadata'nın şifrelenip şifrelenmediği kullanılan çözüme göre değişebilir. Dosya silme ve key destruction politikası birlikte planlanmalıdır.

Database Encryption

Database encryption TDE, column-level veya application-level gibi farklı modelleri içerebilir. Her model farklı saldırı türlerine karşı koruma sağlar. TDE disk dosyalarını korurken yetkili SQL sorgularından gelen plaintext sonuçları engellemez. Hassas alanlar için ek field-level encryption gerekebilir. Performans ve query ihtiyacı tasarım aşamasında test edilmelidir.

Object Storage Encryption

Object storage sistemlerinde server-side encryption yaygın olarak bulunur. Hassas veri sınıfına göre customer-managed key tercih edilmesi gerekebilir. Bucket policy veya benzeri erişim politikaları unencrypted upload işlemlerini engelleyecek biçimde yapılandırılabilir. Cross-account erişim ayrıca kontrol edilmelidir. Public access ayarları encryption'dan bağımsız bir güvenlik konusudur.

Backup Encryption

Backup dosyaları üretim verisinin tam veya büyük bölümünü içerebilir. Bu nedenle ana sistem kadar güçlü encryption politikası gerektirir. Backup key'lerinin availability durumu restore işlemi açısından kritik öneme sahiptir. Anahtar yanlışlıkla silinirse yedek geri yüklenemez hâle gelebilir. Recovery tatbikatı hem veri hem key erişimini birlikte test etmelidir.

Snapshot Encryption

Snapshot kısa sürede büyük veri kopyaları oluşturabildiği için saldırgan açısından değerli hedeftir. Storage encryption politikasının snapshot'a otomatik olarak devam edip etmediği platforma göre doğrulanmalıdır. Cross-region veya başka hesaba kopyalama sırasında yeni key politikası gerekebilir. Snapshot retention süresi ana verinin retention politikasından kopmamalıdır. Yetkisiz snapshot oluşturma izni de kontrol edilmelidir.

Transparent Data Encryption (TDE) Nedir?

TDE veritabanının fiziksel dosyalarını ve çoğu uygulamada ilgili depolama bileşenlerini şifrelemeye odaklanan yöntemdir. Uygulama genellikle sorgu davranışını değiştirmeden çalışmaya devam eder. Bu kolaylık TDE'nin önemli avantajıdır. Buna karşılık database engine yetkili erişimde plaintext veriyi sunabildiği için uygulama hesabının ele geçirilmesi gibi tehditleri çözmez. TDE'nin kapsamını doğru anlatmak yanlış güven hissini önler.

Database Files

TDE temel olarak database data files üzerinde encryption sağlar. Disk veya storage kopyası ele geçirildiğinde doğrudan dosyadan veri okuma riskini azaltır. Database engine çalışırken yetkili sorgular normal biçimde sonuç alabilir. Bu nedenle erişim kontrolü gereksinimi devam eder. Encryption key'in database dosyalarından güvenli biçimde ayrılması önemlidir.

Transaction Logs

Transaction log'ları hassas verinin geçmiş değişikliklerini içerebilir. TDE çözümünün log dosyalarını nasıl koruduğu doğrulanmalıdır. Yalnızca ana data file'a odaklanmak veri sızıntısı oluşturabilir. Log backup ve replication süreçleri de aynı değerlendirmeye dahil edilmelidir. Restore senaryosunda gerekli key'lerin erişilebilir olması gerekir.

Backups

TDE kullanan sistemlerde database backup davranışı ürüne ve yapılandırmaya bağlıdır. Backup'ın şifreli olması varsayılmadan doğrulanmalıdır. Anahtar bağımlılığı restore testinde özellikle kontrol edilmelidir. Başka ortama restore yapılacaksa gerekli key materyali güvenli biçimde erişilebilir olmalıdır. Backup retention sona erdiğinde ilgili key lifecycle etkisi değerlendirilmelidir.

TDE Hangi Saldırılara Karşı Korur?

TDE özellikle disk dosyalarının veya fiziksel storage kopyalarının yetkisiz elde edilmesi riskine karşı koruma sağlar. Offline database file kopyasının doğrudan okunmasını zorlaştırır. Disk ve backup güvenliğine önemli katkı sunabilir. Fakat database engine üzerinden yapılan yetkili veya ele geçirilmiş sorgular farklı tehdit modelidir. Bu nedenle TDE defense-in-depth katmanı olarak görülmelidir.

TDE Hangi Saldırılara Karşı Koruyamaz?

TDE database engine'in plaintext erişimine izin verdiği saldırıları tek başına engelleyemez. Uygulama hesabı veya yüksek yetkili database hesabı ele geçirilirse sorgu yoluyla veri okunabilir. SQL injection açığı da uygulamanın yetkileri kapsamında sorgu çalıştırabilir. Bu nedenle query-level erişim sorunları ayrıca çözülmelidir. Field-level veya application-level encryption belirli tehditlerde ek ayrım sağlayabilir.

SQL Injection

SQL injection uygulamanın beklenmeyen database sorguları yürütmesine neden olabilir. TDE database engine'e sunulan veriyi plaintext hâlde işlediği için bu saldırıyı engellemez. Parametreli sorgular ve güvenli ORM kullanımı temel koruma yöntemlerindendir. ORM performansı ve veri erişim davranışını ayrıca incelemek için https://www.diyarbakiryazilim.com.tr/posts/orm-object-relational-mapping-araclarinin-performans-etkileri içeriği faydalı bir tamamlayıcıdır. Database encryption ile uygulama güvenliği birbirinden ayrı kontrol alanları olarak ele alınmalıdır.

Compromised Database Credentials

Database credential ele geçirildiğinde saldırgan hesabın izin verdiği sorguları çalıştırabilir. TDE bu sorguların sonucunu gizlemez. Least privilege yaklaşımı hesabın okuyabileceği veri miktarını sınırlandırmalıdır. Hassas alanlarda application-level encryption kullanılırsa database credential tek başına plaintext'e ulaşmak için yeterli olmayabilir. Bu nedenle credential yönetimi ile encryption layer birlikte düşünülmelidir.

Yetkili DBA

DBA operasyonel olarak geniş database erişimine sahip olabilir. TDE yetkili database engine erişimini engellemez. Threat model yetkili iç kullanıcı riskini içeriyorsa application-level encryption değerlendirilebilir. Decryption key erişimi database administration rolünden ayrılmalıdır. Separation of duties burada güçlü bir tasarım prensibi sağlar.

Column-Level ve Field-Level Encryption

Column-level veya field-level encryption yalnızca hassas alanları şifreleyerek daha dar bir koruma alanı oluşturur. Bu yaklaşım tüm database'i şifrelemekten farklı bir güvenlik sınırı sağlayabilir. Özellikle kimlik numarası, finansal hesap veya yüksek riskli sağlık verisi gibi alanlarda değerlendirilebilir. Ancak arama, indeks ve sıralama davranışı değişebilir. Veri modeli, query gereksinimi ve encryption tasarımı aynı aşamada ele alınmalıdır.

Hangi Alanlar Şifrelenmelidir?

Her database kolonu aynı risk seviyesinde değildir. Veri sınıflandırması hangi alanların field-level encryption gerektirdiğini belirlemelidir. Şifreleme gereksiz alanlara uygulandığında query maliyeti ve geliştirme yükü artabilir. Yetersiz kapsam ise hassas veriyi plaintext bırakabilir. Karar iş etkisi, hukuki gereksinim ve saldırı senaryosu birlikte değerlendirilerek verilmelidir.

Kimlik Numaraları

Kimlik numaraları kişiyi doğrudan tanımlayabilen hassas verilerdir. Kullanım ihtiyacı sınırlıysa plaintext sorgu erişimi gereksiz risk oluşturur. Alan şifreleme ve kontrollü decryption servisleri kullanılabilir. Arama gerekiyorsa güvenli indeksleme stratejisi ayrıca tasarlanmalıdır. Loglarda tam kimlik numarası gösterilmemelidir.

Kart Verileri

Kart verileri yüksek değerli ve özel uyumluluk gereksinimleri bulunan veri grubudur. Mümkün olduğunda gerçek kart verisini uygulamanın saklamaması tercih edilmelidir. Tokenization saldırı yüzeyini azaltabilir. Saklama zorunluysa güçlü encryption ve ayrı key management uygulanmalıdır. Görüntüleme sırasında masking de ek güvenlik sağlar.

Finansal Hesaplar

Finansal hesap bilgileri yetkisiz erişim durumunda maddi ve kişisel risk oluşturabilir. Bu alanlar için field-level encryption uygulanabilir. Decryption yetkisi yalnızca gerekli servis rolüne verilmelidir. Support ve analitik kullanıcıların gerçek değeri görmesine ihtiyaç olup olmadığı sorgulanmalıdır. Backup ve export dosyaları aynı koruma seviyesinde tutulmalıdır.

Sağlık Verileri

Sağlık verileri yüksek hassasiyet taşıyan kişisel bilgi grubudur. Erişim yalnızca açık iş gereksinimi bulunan kullanıcı ve servislerle sınırlandırılmalıdır. Field-level encryption, audit logging ve güçlü authentication birlikte kullanılabilir. Veri analizi gerekiyorsa pseudonymization gibi ek yöntemler değerlendirilebilir. Test ortamlarına gerçek plaintext sağlık verisi kopyalamaktan kaçınılmalıdır.

Randomized Encryption

Randomized encryption aynı plaintext'in her işlemde farklı ciphertext üretmesini hedefler. Bu yaklaşım veri örüntülerinin görülmesini azaltır. Buna karşılık doğrudan equality search yapmak zorlaşabilir. Uygulama decrypt etmeden database tarafında sorgu çalıştıramayabilir. Bu nedenle güvenlik ve query ihtiyacı arasında tasarım dengesi gerekir.

Deterministic Encryption

Deterministic encryption aynı plaintext ve ilgili bağlam için aynı ciphertext üretmeye yönelik kullanılır. Bu özellik equality query ve bazı indeksleme senaryolarını kolaylaştırabilir. Ancak aynı değerlerin tekrar ettiği bilgisi ciphertext üzerinden görülebilir. Düşük çeşitliliğe sahip alanlarda tahmin saldırıları daha önemli hâle gelebilir. Bu nedenle yalnızca açık query gereksinimi olduğunda ve risk değerlendirmesi yapılarak kullanılmalıdır.

Index ve Search Problemleri

Şifrelenmiş alanlarda normal database indeksleri çoğu zaman plaintext davranışını koruyamaz. Randomized encryption aynı değeri farklı ciphertext'e dönüştürdüğü için equality index kullanımı zorlaşır. Deterministic yöntemler bazı sorguları mümkün kılarken bilgi sızıntısı riski oluşturabilir. Ayrı blind index veya güvenli arama tasarımları belirli senaryolarda değerlendirilebilir. Query gereksinimi encryption kararından önce belgelenmelidir.

Database Query Performansı

Encryption database query planlarını ve CPU kullanımını etkileyebilir. Decrypt işlemi uygulama katmanına taşındığında daha fazla veri çekilmesi gerekebilir. İndeks kaybı büyük tablolarda belirgin performans sorunu oluşturabilir. Bu nedenle production benzeri veri hacmiyle benchmark yapılmalıdır. Güvenlik nedeniyle seçilen yöntem kullanıcı deneyimini bozuyorsa mimari yeniden tasarlanmalıdır.

Application-Level Encryption Nedir?

Application-level encryption verinin database'e ulaşmadan önce uygulama tarafından şifrelenmesini sağlar. Böylece database engine yalnızca ciphertext görebilir. Bu yaklaşım DBA veya database credential ele geçirilmesi gibi belirli tehditlere karşı güçlü ayrım sunabilir. Buna karşılık uygulama koduna key kullanımı ve metadata yönetimi sorumluluğu ekler. Güvenli library, KMS entegrasyonu ve açık veri modeli olmadan uygulanması zorlaşabilir.

Veri Database'e Gitmeden Encrypt Edilir

Application-level modelde plaintext uygulama process'i içinde şifrelenir. Database'e gönderilen değer ciphertext olur. Böylece storage veya database katmanı gerçek değeri bilmeden saklama görevi yapabilir. Encryption metadata'sı ciphertext ile birlikte versioned formatta tutulabilir. Uygulamanın decryption yetkisi ayrıca IAM politikasıyla sınırlandırılmalıdır.

Database'in Plaintext Görmemesi

Database yalnızca ciphertext görüyorsa DBA'nın doğrudan SQL sorgusuyla plaintext elde etmesi zorlaşır. Bu durum yüksek hassasiyetli veriler için ek güvenlik sınırı oluşturabilir. Ancak uygulama ele geçirilirse decryption işlemi yine hedef alınabilir. Dolayısıyla application-level encryption uygulama güvenliğinin yerine geçmez. Anahtar erişimi uygulama kimliğine en az yetki prensibiyle verilmelidir.

DBA Threat Model

DBA geniş yetkileri nedeniyle bazı sistemlerde ayrı tehdit modeli olarak değerlendirilir. TDE tek başına DBA'nın yetkili sorgularını engellemez. Application-level encryption key'leri DBA rolünden ayrılırsa daha güçlü görev ayrılığı sağlanabilir. Buna rağmen DBA ciphertext'i silebilir veya değiştirebilir. Availability ve integrity riskleri için ek kontroller gerekir.

Multi-Tenant Cloud Database

Multi-tenant uygulamalar aynı database altyapısında birçok müşterinin verisini tutabilir. Tenant-specific DEK kullanmak bir tenant anahtarının diğer tenant verisini açmasını engeller. Bu yaklaşım blast radius değerini küçültür. Tenant offboarding sırasında crypto-shredding gibi yöntemler de uygulanabilir. Key sayısının artması nedeniyle KMS ve automation kritik hâle gelir.

Query Yeteneğinin Kaybedilmesi

Application-level encryption database'in plaintext'i görmesini engellediği için normal sorguların bir kısmı çalışmaz. Range query, sıralama ve partial search özellikle zorlaşabilir. Deterministic encryption yalnızca belirli equality sorgularına yardımcı olabilir. Bu tasarım kararının güvenlik etkileri ayrıca değerlendirilmelidir. Ürün gereksinimleri ile güvenlik hedefleri erken aşamada birlikte ele alınmalıdır.

Uygulama Karmaşıklığı

Application-level encryption uygulamaya key fetch, ciphertext formatı ve error handling sorumluluğu ekler. Key rotation sırasında eski ve yeni ciphertext sürümlerini desteklemek gerekebilir. Test ve migration süreçleri daha fazla planlama ister. Bununla birlikte hazır encryption SDK'ları ve envelope encryption desenleri operasyon yükünü azaltabilir. Kendi cryptographic formatını sıfırdan tasarlamak yerine güvenilir primitive ve versioned metadata kullanılmalıdır.

Client-Side ve Server-Side Encryption Arasındaki Fark

Client-side ve server-side encryption arasındaki temel fark plaintext verinin hangi noktaya kadar taşındığıdır. Server-side modelde servis sağlayan altyapı veriyi alıp kendi tarafında şifreleyebilir. Client-side modelde veri karşı tarafa gönderilmeden önce istemci veya uygulama tarafından şifrelenir. Böylece storage katmanının plaintext görmesi engellenebilir. Seçim veri sınıfı, sorgu gereksinimi ve güven modeline göre yapılmalıdır.

Server-Side Encryption

Server-side encryption kullanımı genellikle kolaydır ve uygulamada az değişiklik gerektirir. Storage sistemi veriyi alır ve depolama sırasında otomatik şifreler. Anahtar platform tarafından veya müşteri kontrollü olarak yönetilebilir. Servis katmanı uygun yetkiyle plaintext'e erişebilir. Bu nedenle storage kaybına karşı güçlü olsa da servis sağlayıcı trust modelini tamamen ortadan kaldırmaz.

Client-Side Encryption

Client-side encryption veriyi storage hizmetine gönderilmeden önce ciphertext'e dönüştürür. Storage sistemi gerçek veriyi görmeden saklama yapabilir. Anahtar kullanımı uygulama veya istemci tarafında yönetilir. Bu daha güçlü veri ayrımı sağlarken query ve key recovery süreçlerini zorlaştırabilir. Anahtar kaybı kalıcı veri kaybına dönüşebileceği için recovery planı kritik öneme sahiptir.

Cloud Provider'ın Plaintext Görüp Görmemesi

Server-side encryption modelinde servis katmanı çoğunlukla plaintext'i işleyebilir. Client-side encryption doğru uygulandığında storage provider yalnızca ciphertext görebilir. Ancak uygulamanın başka yönetilen hizmetlere plaintext gönderip göndermediği ayrıca incelenmelidir. Gerçek veri akışı mimari diyagramla belgelenmelidir. Bir servisin encryption özelliği bütün sistemin end-to-end korunduğunu tek başına göstermez.

End-to-End Protection

End-to-end protection verinin yalnızca yetkili uçlarda plaintext hâle gelmesini hedefler. Aradaki depolama veya taşıma bileşenleri mümkün olduğunca ciphertext ile çalışır. Bu model güven sınırlarını küçültebilir. Buna karşılık key distribution ve recovery daha zor hâle gelir. Kullanım senaryosunun gerçekten uçtan uca gizlilik gerektirip gerektirmediği değerlendirilmelidir.

Hangi Veri Sınıfında Hangisi Kullanılmalı?

Düşük riskli veri için server-side encryption yeterli olabilir. Confidential veya Restricted veri için client-side ya da application-level encryption ek fayda sağlayabilir. Kesin seçim yalnızca sınıf adına göre yapılmamalıdır. Threat model, operasyon gereksinimi ve erişim ihtiyacı birlikte değerlendirilmelidir. Kurum bu eşlemeyi resmi encryption policy içinde tanımlayabilir.

Envelope Encryption Nedir?

Envelope encryption büyük veri setlerinde anahtar yönetimini ölçeklendirmek için yaygın kullanılan modeldir. Veri doğrudan KMS master key ile şifrelenmek yerine bir Data Encryption Key ile korunur. DEK daha sonra Key Encryption Key kullanılarak wrap edilir. Ciphertext yanında wrapped DEK saklanabilir. Böylece KMS her veri byte'ını işlemek yerine küçük key materyalini korur ve performans daha yönetilebilir hâle gelir.

Data Encryption Key (DEK)

DEK gerçek veriyi şifrelemek için kullanılan simetrik anahtardır. Farklı tenant, dosya veya veri kategorileri için farklı DEK üretilebilir. Bu yaklaşım key compromise etkisini sınırlandırabilir. Plaintext DEK mümkün olduğunca kısa süre bellekte tutulmalıdır. Kalıcı storage üzerinde wrapped biçimde saklanması tercih edilir.

Key Encryption Key (KEK)

KEK, DEK gibi veri encryption key'lerini korumak için kullanılan anahtardır. Genellikle KMS veya HSM içinde yönetilir. Uygulamanın KEK plaintext değerine doğrudan erişmesi gerekmeyebilir. Bunun yerine wrap ve unwrap işlemleri güvenli servis tarafından gerçekleştirilir. KEK rotation çoğu zaman DEK'lerin yeniden wrap edilmesiyle yönetilebilir.

Wrapped DEK

Wrapped DEK, KEK ile kriptografik olarak korunmuş data encryption key'dir. Ciphertext yanında saklanması yaygın bir tasarımdır. Saldırgan database'i ele geçirse bile KEK erişimi olmadan DEK'i kullanamamalıdır. Wrapped key metadata içinde key version ve algorithm bilgisi tutulabilir. Bu yapı rotation ve migration süreçlerini kolaylaştırır.

DEK ile Verinin Encrypt Edilmesi

Uygulama veriyi hızlı simetrik encryption kullanarak DEK ile şifreler. Büyük payload KMS'e gönderilmediği için latency ve maliyet azaltılabilir. DEK scope'u veri sınıfına göre belirlenebilir. Aynı DEK'in aşırı geniş veri alanında kullanılması blast radius değerini artırır. Encryption operation metadata'sı hangi key version'ın kullanıldığını kaydetmelidir.

KEK'in KMS/HSM'de Tutulması

KEK merkezi ve güvenli key management katmanında tutulmalıdır. KMS veya HSM key kullanımını kimlik politikaları ve audit kayıtlarıyla kontrol edebilir. Uygulama key materyalini config dosyasında taşımak zorunda kalmaz. Decrypt izni yalnızca gerçekten gerekli workload identity'lere verilmelidir. KEK erişim logları SIEM tarafından izlenebilir.

Plaintext DEK'in Sadece Memory'de Bulunması

Plaintext DEK mümkün olduğunca kalıcı storage'a yazılmamalıdır. Uygulama unwrap sonrası anahtarı kısa süre bellekte kullanabilir. Memory dump ve crash dump gibi yolların key sızıntısı oluşturabileceği unutulmamalıdır. Cache gerekiyorsa süre ve erişim kapsamı sınırlanmalıdır. Process sona erdiğinde key materyalinin gereksiz kopyaları bırakılmamalıdır.

Encryption Key Management Neden Algoritmadan Daha Önemlidir?

Güçlü algoritma kötü anahtar yönetimini telafi edemez. Anahtarın source code içinde bulunması, sınırsız decrypt yetkisi veya hiç rotation yapılmaması gerçek sistem riskini artırır. NIST key management yaklaşımı anahtar yaşam döngüsünü üretimden destruction aşamasına kadar ele alır. Kurumsal encryption programı bu yaşam döngüsünü dokümante etmelidir. Algoritma seçimi ise bu daha geniş yönetim modelinin yalnızca bir parçasıdır.

Key Generation

Key generation yeterli entropy ve güvenilir cryptographic mechanism ile yapılmalıdır. İnsan tarafından seçilen değerler encryption key olarak kullanılmamalıdır. KMS veya HSM üretimi güvenli sınır içinde gerçekleştirebilir. Key purpose ilk oluşturma anında tanımlanmalıdır. Encryption, signing ve HMAC key'leri amaç dışı kullanılmamalıdır.

Key Distribution

Key distribution anahtarın yetkili bileşenlere güvenli biçimde ulaştırılmasını kapsar. Plaintext key'i e-posta veya config dosyası üzerinden paylaşmak uygun değildir. Envelope encryption doğrudan anahtar dağıtımı ihtiyacını azaltabilir. Workload identity ile KMS erişimi daha kontrollü model sağlar. Dağıtılan anahtarların hangi servislere ulaştığı inventory içinde izlenmelidir.

Key Activation

Key activation anahtarın hangi tarihten itibaren kullanıma açık olduğunu belirler. Yeni key oluşturulduğu anda otomatik olarak bütün servislerin onu kullanması gerekmez. Deployment ve rotation planı kontrollü geçiş gerektirebilir. Active ve decrypt-only durumları ayrı tutulabilir. Böylece eski ciphertext okunurken yeni encryption yeni key ile yapılabilir.

Key Storage

Key storage anahtarın yetkisiz erişimden korunmasını hedefler. Master key'ler veriden ayrı güvenlik alanında tutulmalıdır. KMS ve HSM bu amaç için tasarlanmış kontroller sunar. Uygulama config dosyasındaki plaintext key yüksek risklidir. Backup ve recovery key kopyaları da aynı güvenlik standardına uymalıdır.

Key Rotation

Key rotation belirli cryptoperiod sonunda veya risk durumunda yeni anahtara geçiştir. Rotation yalnızca yeni key üretmek değildir. Eski ciphertext'in nasıl okunacağı, re-wrap veya re-encryption gerekip gerekmediği belirlenmelidir. Otomatik süreçler operasyon hatasını azaltır. Rotation başarısı ölçülebilir bir compliance metriği hâline getirilebilir.

Key Revocation

Revocation artık güvenilmemesi gereken key'in kullanımını durdurur. Compromise şüphesinde hızlı revocation kritik olabilir. Ancak key tamamen kapatıldığında mevcut ciphertext'e erişim etkilenebilir. Incident response planı bu operasyon sonucunu önceden değerlendirmelidir. Revoked key ile ilişkili veri seti mümkün olduğunca hızlı tespit edilmelidir.

Key Backup

Bazı key türleri recovery amacıyla yedeklenebilir. Backup kopyası ana key kadar hassas kabul edilmelidir. Yedek key plaintext biçimde sıradan dosya sunucusunda tutulmamalıdır. Backup erişimi dar yetki ve audit altında bulunmalıdır. Kullanım amacı sona erdiğinde gereksiz key kopyaları kaldırılmalıdır.

Key Recovery

Key recovery kayıp veya erişilemeyen anahtar nedeniyle verinin kalıcı olarak kullanılamaz olmasını önlemeyi hedefler. Recovery mekanizması hiç test edilmezse gerçek olay sırasında çalışmayabilir. Tatbikatlar kontrollü ortamda düzenli yapılmalıdır. Recovery yetkisi yüksek riskli olduğu için görev ayrılığı uygulanabilir. Test sonucu ve başarısızlık nedenleri audit kaydına alınmalıdır.

Key Destruction

Key destruction kullanım süresi sona eren anahtarın güvenli biçimde yok edilmesini ifade eder. Encryption key'in silinmesi bağlı ciphertext'in geri döndürülemez hâle gelmesine neden olabilir. Bu özellik crypto-shredding amacıyla bilinçli kullanılabilir. Ancak aktif backup veya hukuki saklama gereksinimi varsa erken destruction veri kaybı yaratabilir. Key silme işlemi kontrollü approval sürecine bağlanmalıdır.

Cryptoperiod Nedir?

Cryptoperiod belirli bir cryptographic key'in yetkili olarak kullanılabileceği zaman aralığını ifade eder. Tek bir evrensel rotation süresi bütün key türleri için uygun değildir. Veri hassasiyeti, encryption hacmi, key exposure ihtimali ve uyumluluk gereksinimleri süreyi etkiler. Kısa cryptoperiod risk alanını azaltabilir ancak operasyon yükünü artırabilir. Kurum her key type için karar gerekçesini resmi policy içinde tutmalıdır.

Key Lifetime

Key lifetime anahtarın oluşturulmasından kullanım dışına alınmasına kadar geçen toplam yaşam süresini kapsayabilir. Active encryption dönemi ile yalnızca eski veriyi decrypt etmek için tutulduğu dönem ayrılabilir. Anahtarın amacı bu süreyi etkiler. Signing key ile data encryption key aynı lifecycle'a sahip olmayabilir. Inventory her key'in durumunu ve yaşını izlemelidir.

Key Kullanım Süresinin Belirlenmesi

Key kullanım süresi rastgele takvim değeri olarak seçilmemelidir. Threat model ve operasyon gereksinimleri kararın temelini oluşturmalıdır. Çok yüksek veri hacmini aynı anahtarla işlemek risk değerlendirmesini değiştirebilir. Rotation operasyonunun kesintisiz yapılabilmesi de süre seçimini etkiler. Policy düzenli aralıklarla gözden geçirilmelidir.

Veri Hassasiyeti

Daha hassas veri daha sıkı key lifecycle politikası gerektirebilir. Restricted veri ile Internal veri aynı cryptoperiod'a zorlanmak zorunda değildir. Uzun yıllar gizli kalması gereken kayıtlar için uzun vadeli cryptographic strength de önemlidir. Anahtar sızıntısının etkisi veri sınıfıyla birlikte değerlendirilmelidir. Bu nedenle data classification ile key policy arasında doğrudan ilişki kurulmalıdır.

Şifrelenen Veri Hacmi

Aynı key ile işlenen veri hacmi cryptographic risk değerlendirmesinde önemli faktördür. Çok yüksek hacim belirli algoritma veya mode limitlerinin dikkate alınmasını gerektirebilir. Tenant veya dataset bazlı DEK kullanmak kapsamı küçültebilir. Hacim büyüdükçe key access loglarının izlenmesi de önem kazanır. Key kullanım metrikleri otomatik toplanabilir.

Key Exposure Riski

Key ne kadar çok servis, kullanıcı veya ortam tarafından erişilebiliyorsa exposure riski artar. Uzun ömürlü key bu erişim fırsatını daha uzun süre açık tutar. Workload identity ve short-lived credentials key erişimini daha kontrollü hâle getirebilir. Master key'in doğrudan uygulama memory'sine verilmemesi de önemli bir ayrımdır. Exposure riski arttıkça cryptoperiod ve rotation stratejisi yeniden değerlendirilmelidir.

Compliance Gereksinimleri

Bazı regülasyon veya standartlar key lifecycle konusunda belirli beklentiler oluşturabilir. Organizasyon yalnızca bir kontrol listesine göre key süresi seçmemelidir. İlgili standardın kapsamı ve kullanılan veri türü anlaşılmalıdır. Industry guidance ile risk değerlendirmesi birlikte kullanılmalıdır. Compliance kanıtları için rotation kayıtları ve key inventory düzenli tutulmalıdır.

Key Rotation Nasıl Yapılır?

Key rotation kontrollü geçiş sürecidir ve yalnızca yeni key oluşturmaktan ibaret değildir. Yeni encryption işlemlerinin hangi key ile yapılacağı, eski verinin nasıl çözüleceği ve servislerin ne zaman güncelleneceği belirlenmelidir. Envelope encryption kullanan sistemlerde KEK rotation çoğu zaman full data re-encryption gerektirmeden re-wrapping ile yapılabilir. DEK rotation ise veri yeniden şifrelemesini gerektirebilir. Zero-downtime yaklaşım için birden fazla key version'ını okuyabilen uygulama tasarımı kullanışlıdır.

Scheduled Rotation

Scheduled rotation önceden tanımlanmış cryptoperiod sonunda gerçekleştirilen planlı anahtar değişimidir. Otomasyon yanlış key seçimi veya unutma riskini azaltabilir. Deployment sırasında eski key'in bir süre decryption için tutulması gerekebilir. Monitoring rotation başarısızlığını hızlı göstermelidir. Her key type için rotation sıklığı ayrı tanımlanabilir.

Emergency Rotation

Emergency rotation key compromise şüphesi veya doğrulanmış sızıntı durumunda uygulanır. Normal takvim beklenmez. Öncelik riskli key'in kullanımını durdurmak ve etkilenen veriyi belirlemektir. Yeni key kontrollü biçimde devreye alınır. Olay sonrasında root cause ve downstream etkiler incelenmelidir.

KEK Rotation

KEK rotation envelope encryption mimarisinde key-encryption key'in değiştirilmesidir. DEK'lerin tamamını değiştirmek her zaman gerekli olmayabilir. Existing wrapped DEK yeni KEK altında re-wrap edilebilir. Böylece büyük veri setini yeniden encrypt etme maliyeti azaltılabilir. Re-wrapping süreci audit ve rollback planına sahip olmalıdır.

DEK Rotation

DEK rotation doğrudan veriyi şifreleyen key'in değiştirilmesidir. Bu işlem çoğu durumda etkilenen ciphertext'in yeniden encryption işleminden geçmesini gerektirir. Büyük veri setlerinde migration uzun sürebilir. Versioned ciphertext yeni ve eski key'lerin geçici olarak birlikte okunmasına olanak tanır. Migration tamamlandığında eski key'in erişim durumu kontrollü biçimde değiştirilmelidir.

Re-Wrapping

Re-wrapping wrapped DEK'in yeni KEK ile tekrar korunmasıdır. Gerçek payload ciphertext değişmeden kalabilir. Bu nedenle full data re-encryption'a göre çok daha düşük maliyetli olabilir. İşlem sırasında plaintext DEK güvenli boundary içinde tutulmalıdır. KMS native re-wrap özelliği varsa tercih edilebilir.

Full Data Re-Encryption

Full data re-encryption bütün verinin eski key ile decrypt edilip yeni key ile tekrar encrypt edilmesini içerir. Büyük sistemlerde yüksek IO ve CPU maliyeti oluşturabilir. Migration sırasında tutarlılık ve rollback stratejisi gerekir. Verinin bir kısmının eski, bir kısmının yeni key ile bulunduğu geçiş dönemi açık biçimde yönetilmelidir. Bu işlem performans açısından production benzeri ortamda önceden test edilmelidir.

Zero-Downtime Key Rotation

Zero-downtime rotation uygulamanın servis kesintisi olmadan yeni key'e geçmesini hedefler. Uygulama önce yeni key ile encrypt etmeye başlarken eski key'lerle decrypt yapabilmelidir. Background migration mevcut ciphertext'i aşamalı güncelleyebilir. Key version metadata bu model için önemlidir. Migration tamamlandıktan sonra eski key güvenli biçimde decommission edilebilir.

Key Compromise Durumunda Ne Yapılmalıdır?

Key compromise yüksek öncelikli security incident olarak ele alınmalıdır. İlk adım etkilenen key'in kapsamını ve hangi verileri koruduğunu belirlemektir. Key kullanımının durdurulması, yeni key üretimi ve gerekli re-encryption süreci koordineli biçimde yürütülmelidir. Audit logları saldırganın hangi decrypt işlemlerini yapmış olabileceğini anlamaya yardımcı olur. Hazır incident playbook bulunması kriz anında karar süresini azaltır.

Anahtarı Disable/Revoke Etmek

Compromised key'in yeni işlemlerde kullanılmasını mümkün olduğunca hızlı durdurmak gerekir. Disable veya revoke işleminin aktif servisleri nasıl etkileyeceği bilinmelidir. Bazı servisler key olmadan çalışamayabilir. Acil yeni key deployment planı bu nedenle önceden hazırlanmalıdır. Yapılan her key state değişikliği audit kaydına alınmalıdır.

Etkilenen Veriyi Belirlemek

Key inventory hangi key'in hangi dataset'i koruduğunu gösterebilmelidir. Bu bilgi yoksa compromise blast radius hesaplamak zorlaşır. Ciphertext metadata'da key identifier tutmak analizi hızlandırabilir. Tenant ve veri kategorisi bazlı DEK kullanımı etki alanını küçültür. Incident sırasında tahmin yerine doğrulanabilir inventory kullanılmalıdır.

Yeni Key Üretmek

Yeni key güvenilir CSPRNG, KMS veya HSM mekanizmasıyla oluşturulmalıdır. Compromised key'den türetilmemelidir. Yeni key için ayrı identifier ve lifecycle metadata oluşturulmalıdır. IAM policy yalnızca gerekli workload'lara erişim vermelidir. Deployment tamamlanmadan eski key tamamen kapatılırsa hizmet kesintisi oluşabileceği için geçiş planı dikkatle uygulanmalıdır.

Re-Encryption

Compromised data encryption key korunmuş verinin yeniden şifrelenmesini gerektirebilir. Migration önceliği veri hassasiyetine göre belirlenebilir. Büyük datasetlerde incremental re-encryption kullanılabilir. Her kaydın hangi key version ile korunduğu doğrulanmalıdır. Migration bittikten sonra eski key erişimi sonlandırılmalıdır.

Audit Log Analizi

Audit logları key'in kim tarafından ve ne zaman kullanıldığını gösterebilir. Olağan dışı decrypt hacmi compromise sinyali olabilir. Beklenmeyen region veya identity üzerinden key çağrıları da incelenmelidir. Logların değiştirilemez veya güçlü biçimde korunan merkezi sisteme gönderilmesi faydalıdır. Incident timeline oluşturmak için application ve KMS logları birlikte analiz edilmelidir.

Downstream Key Rotation

Bir key compromise başka secret veya anahtarların da etkilenmesine yol açabilir. Compromised key ile korunan API secret veya certificate private key varsa downstream rotation gerekebilir. Etki zinciri dependency inventory üzerinden takip edilmelidir. Sadece ilk key'i değiştirmek yeterli olmayabilir. Incident sonrası bütün bağlı credential'lar gözden geçirilmelidir.

Incident Response

Cryptographic incident response teknik ve operasyonel ekiplerin birlikte çalışmasını gerektirir. Key revoke, veri migration, servis recovery ve kullanıcı iletişimi farklı sorumluluklar oluşturabilir. Önceden tanımlanmış rol ve escalation yolu süreci hızlandırır. Tatbikat yapılmayan playbook gerçek olayda eksik kalabilir. Düzenli simulation key compromise senaryosunu da içermelidir.

KMS Nedir?

Key Management Service, cryptographic key'lerin merkezi biçimde oluşturulması, saklanması ve kullanımının denetlenmesini sağlayan hizmet modelidir. KMS uygulamaların master key'i config dosyasında taşımak zorunda kalmasını önleyebilir. IAM entegrasyonu hangi workload'un hangi key üzerinde hangi işlemi yapabileceğini sınırlar. Audit logging key kullanımını görünür hâle getirir. Envelope encryption ile birlikte kullanıldığında yüksek hacimli veri encryption mimarisini ölçeklendirmeyi kolaylaştırır.

Centralized Key Management

Centralized key management kurum çapındaki anahtarların ortak politika altında yönetilmesini sağlar. Dağınık config dosyalarında key tutma ihtiyacını azaltır. Rotation, revocation ve audit süreçleri tek noktadan uygulanabilir. Merkezi sistem aynı zamanda kritik bağımlılık hâline geleceği için availability tasarımı gerekir. Erişim politikası merkezi olduğu kadar dar da olmalıdır.

AWS KMS

AWS KMS cloud tabanlı key management hizmeti olarak encryption key yaşam döngüsünü yönetmek için kullanılabilir. Uygulamalar doğrudan master key materyalini almak yerine kontrollü cryptographic operations çağrıları yapabilir. IAM politikalarıyla key erişimi sınırlandırılabilir. Envelope encryption tasarımında KEK rolünü üstlenen key'ler yönetilebilir. Kullanım kararı sistemin cloud mimarisi ve uyumluluk gereksinimine göre verilmelidir.

Azure Key Vault

Azure Key Vault key ve secret yönetimi ihtiyaçları için kullanılabilen cloud hizmetidir. Encryption key erişimleri platform identity mekanizmalarıyla sınırlandırılabilir. Audit kayıtları operasyon görünürlüğü sağlayabilir. Key ve secret kavramlarının aynı şey olmadığı uygulama mimarisinde açık biçimde korunmalıdır. Kullanılan servis özellikleri proje deployment modeline göre doğrulanmalıdır.

Google Cloud KMS

Google Cloud KMS cloud ortamında cryptographic key yönetimi sağlayan hizmetlerden biridir. Key hierarchy ve IAM politikaları üzerinden kontrollü erişim uygulanabilir. Customer-managed encryption key gereksinimlerinde kullanılabilir. Audit logging key operasyonlarının izlenmesine yardımcı olur. Servis seçimi mevcut altyapı, data residency ve operasyon modeliyle birlikte değerlendirilmelidir.

IAM Entegrasyonu

KMS güvenliği doğrudan IAM tasarımına bağlıdır. Bir workload'a bütün key'ler üzerinde decrypt izni vermek least privilege prensibine uymaz. Key scope veri sınıfı ve uygulama rolüne göre daraltılmalıdır. İnsan kullanıcı ile service identity yetkileri ayrılmalıdır. Production decryption izni mümkün olduğunca kısa ve denetlenebilir olmalıdır.

Audit Logging

KMS audit logging hangi identity'nin hangi key üzerinde hangi işlemi yaptığını kaydeder. Bu kayıtlar incident response açısından çok değerlidir. Olağan dışı decrypt çağrıları SIEM alarmı üretebilir. Logların retention süresi güvenlik ve uyumluluk ihtiyacına göre belirlenmelidir. Log erişimi de sınırlı olmalıdır çünkü key kullanım pattern'i hassas bilgi içerebilir.

Automatic Rotation

Automatic rotation belirli key türlerinde planlı key değişimini kolaylaştırabilir. Ancak özelliğin aktif olması bütün ciphertext'in otomatik re-encrypt edildiği anlamına gelmeyebilir. Platformun key version davranışı anlaşılmalıdır. Application metadata ve decrypt compatibility kontrol edilmelidir. Rotation sonrası eski version'ın hangi süreyle kullanılacağı policy ile belirlenmelidir.

HSM Nedir?

Hardware Security Module cryptographic key materyalini güçlü bir donanım sınırı içinde korumak için tasarlanmış cihaz veya hizmettir. Private key veya master key'in donanım dışına plaintext olarak çıkmaması önemli avantajdır. HSM yüksek güvenlik ve belirli uyumluluk gereksinimlerinde kullanılabilir. Buna karşılık operasyon maliyeti ve yönetim ihtiyacı KMS'e göre daha yüksek olabilir. KMS ile HSM birbirini dışlayan seçenekler değildir ve bazı KMS hizmetlerinin altyapısında HSM bulunabilir.

Hardware Security Module

HSM cryptographic operations ve key storage için özel amaçlı güvenlik donanımıdır. Key üretimi cihaz içinde gerçekleştirilebilir. Uygulama private key'i dışarı almadan sign veya decrypt işlemi isteyebilir. Fiziksel ve mantıksal güvenlik kontrolleri cihaz modeline göre değişir. Kullanım öncesinde performans ve availability gereksinimi değerlendirilmelidir.

Key'in Donanım Dışına Çıkmaması

Birçok HSM tasarımında kritik private key plaintext olarak cihaz dışına çıkarılmaz. Uygulama yalnızca cryptographic operation talep eder. Bu yaklaşım memory dump veya config sızıntısı gibi bazı riskleri azaltır. Backup gerekiyorsa vendor'ın güvenli key backup mekanizması kullanılmalıdır. Exportable key politikası mümkün olduğunca dar tutulmalıdır.

Tamper Resistance

HSM cihazları fiziksel müdahale risklerine karşı özel koruma özellikleri sunabilir. Koruma seviyesi ürün ve certification düzeyine göre değişir. Fiziksel güvenlik tek başına kötü IAM politikasını çözmez. Yetkili API çağrıları hâlâ kontrol edilmelidir. Donanım güvenliği ile access control birlikte uygulanmalıdır.

Cloud HSM

Cloud HSM dedicated veya kontrollü HSM kapasitesini cloud ortamında kullanmayı sağlar. Fiziksel cihaz operasyonunun bir kısmı servis sağlayıcı tarafından yönetilebilir. Kurum yine key administration ve erişim politikalarından sorumludur. Latency, availability ve regional deployment gereksinimleri tasarıma dahil edilmelidir. Disaster recovery için ikinci region veya uygun backup planı gerekebilir.

Dedicated HSM

Dedicated HSM kuruma ayrılmış donanım üzerinde key kontrolü sağlayabilir. Çok yüksek güvenlik ve regülasyon gereksinimlerinde tercih edilebilir. Cihaz lifecycle, firmware ve fiziksel güvenlik sorumluluğu artar. Yedeklilik olmadan HSM arızası kritik servis kesintisine neden olabilir. Capacity planning ve HA tasarımı kullanım kararının parçası olmalıdır.

KMS ile HSM Arasındaki Fark

KMS daha yüksek seviyeli key lifecycle ve IAM yönetimi sunan hizmet modelidir. HSM ise key materyalinin donanım seviyesinde korunmasına odaklanır. Bir KMS hizmeti backend'de HSM kullanabilir. Her uygulamanın doğrudan HSM API'siyle çalışması gerekmez. Seçim kontrol düzeyi, compliance, performans ve operasyon kabiliyetine göre yapılmalıdır.

Platform-Managed Key, Customer-Managed Key ve BYOK

Cloud encryption tasarımında anahtarın kim tarafından üretildiği ve yönetildiği önemli bir kontrol seviyesidir. Platform-managed keys kullanım kolaylığı sağlar. Customer-managed keys kurumun lifecycle ve access policy üzerinde daha fazla kontrol sahibi olmasına imkân verir. BYOK yaklaşımı key materyalinin kurum tarafından oluşturulup platforma taşınmasını içerir. Daha fazla kontrol daha fazla operasyon sorumluluğu anlamına gelebilir.

Platform-Managed Keys

Platform-managed keys servis sağlayıcı tarafından otomatik yönetilir. Kullanıcı encryption özelliğini az operasyonla etkinleştirebilir. Birçok düşük ve orta riskli kullanım için yeterli olabilir. Buna karşılık key rotation veya access policy üzerinde sınırlı özelleştirme bulunabilir. Veri sınıflandırması hangi sistemlerde daha fazla key kontrolü gerektiğini belirlemelidir.

Customer-Managed Keys

Customer-managed keys kurumun key policy ve lifecycle üzerinde daha fazla kontrol kurmasını sağlar. Belirli workload'ların decrypt yetkisi ayrıntılı biçimde sınırlandırılabilir. Key disable işlemi veri erişimini merkezi olarak durdurabilir. Bunun yanında yanlış key silme veya policy hatası hizmet kesintisi yaratabilir. Operasyon ekibinin recovery ve rotation süreçlerini yönetebilmesi gerekir.

Bring Your Own Key

BYOK key materyalinin kurum tarafından üretilerek desteklenen hizmete aktarılmasını ifade eder. Bu model key origin üzerinde daha fazla kontrol sağlayabilir. Import edilen key'in rotation davranışı platform tarafından oluşturulan key'den farklı olabilir. Backup ve recovery sorumluluğu açıkça belirlenmelidir. BYOK yalnızca compliance etiketi için değil gerçek tehdit modeli doğrultusunda seçilmelidir.

External/Hold Your Own Key Yaklaşımları

External key modellerinde key materyali cloud hizmetinin standart KMS sınırının dışında tutulabilir. Bu daha güçlü kontrol sunarken availability bağımlılığını kurum tarafına taşır. External key service erişilemezse veri operasyonları durabilir. Network latency ve disaster recovery kritik hâle gelir. Kullanım öncesinde failure mode testleri yapılmalıdır.

Kontrol ile Operasyonel Karmaşıklık Dengesi

Daha fazla key kontrolü her sistem için otomatik olarak daha iyi sonuç vermez. Ek yönetim katmanı rotation, recovery ve on-call yükünü artırabilir. Ekibin operasyon kapasitesi gerçekçi biçimde değerlendirilmelidir. Düşük riskli data için platform-managed model yeterli olabilirken yüksek hassasiyetli data için customer-managed yaklaşım gerekebilir. Amaç güvenlik kontrolünü sürdürülebilir biçimde işletmektir.

Anahtarlar Veriden Nasıl Ayrılmalıdır?

Encryption key ile ciphertext aynı güvenlik alanında tutulursa saldırganın ikisine birlikte ulaşma ihtimali artar. Bu nedenle key ve data separation temel güvenlik prensibidir. Master key'ler KMS veya HSM gibi ayrı sistemlerde tutulabilir. Uygulama gerektiğinde kısa ömürlü yetkiyle cryptographic operation gerçekleştirebilir. Source code, container image ve sıradan environment dosyası kalıcı master key saklama alanı olarak kullanılmamalıdır.

Same-Database Anti-Pattern

Ciphertext ile plaintext encryption key'i aynı database'de saklamak güçlü separation sağlamaz. Database dump alan saldırgan anahtarı da elde edebilir. En azından master key ayrı güvenlik sisteminde tutulmalıdır. Wrapped DEK ciphertext yanında bulunabilir çünkü onu açmak için ayrı KEK gerekir. Tasarımın güvenlik sınırı açıkça belgelenmelidir.

Hard-Coded Key Anti-Pattern

Key'i source code içine yazmak en sık görülen hatalardan biridir. Repository erişimi olan herkes secret'a ulaşabilir. Kod başka ortamlara kopyalandıkça key de kontrolsüz çoğalır. Secret scanning bu tür hataları CI/CD aşamasında tespit edebilir. Key runtime sırasında güvenli identity mekanizmasıyla alınmalıdır.

Git Repository'de Key

Git history bir secret silindikten sonra bile eski commit içinde saklayabilir. Bu nedenle repository'ye yanlışlıkla gönderilen key compromised kabul edilmelidir. Sadece dosyayı son commit'ten kaldırmak yeterli değildir. Key rotate edilmeli ve repository history gerekli süreçle temizlenmelidir. Pre-commit ve CI secret scanning önleyici kontrol sağlayabilir.

Container Image'da Key

Container image içine yerleştirilen key image registry'de uzun süre kalabilir. Image farklı ortamlara dağıtıldıkça secret da yayılır. Runtime secret injection veya workload identity kullanmak daha güvenlidir. Build logları ve layer history de secret içerebilir. Image scanning yalnızca vulnerability değil secret kontrollerini de kapsamalıdır.

.env Dosyasında Master Key

.env dosyaları geliştirme kolaylığı sağlasa da master key için güvenli uzun vadeli storage değildir. Dosya yanlışlıkla repository'ye eklenebilir veya backup sistemine kopyalanabilir. Production master key mümkün olduğunca KMS veya secret manager üzerinden erişilmelidir. Environment variable kullanımı da process dump ve debug çıktısı açısından değerlendirilmelidir. Secret kaynağının erişim ve audit özelliği bulunmalıdır.

KMS/HSM Separation

KMS veya HSM key ile data arasında bağımsız güvenlik sınırı oluşturabilir. Database erişimi elde eden saldırgan otomatik olarak master key erişimi kazanmaz. IAM policy ayrı kimlik doğrulaması gerektirir. Decrypt operasyonları audit loglarına kaydedilebilir. Bu ayrım özellikle yüksek hassasiyetli sistemlerde önemli defense-in-depth sağlar.

Separation of Duties ve Dual Control

Tek bir kişinin hem veriye hem anahtara hem de audit sistemine sınırsız erişimi olması insider riskini artırır. Separation of duties kritik görevlerin farklı rollere dağıtılmasını sağlar. Dual control belirli yüksek riskli işlemlerde iki bağımsız onay veya katılım gerektirebilir. HSM administration ve root key recovery bunun tipik örnekleridir. Rol tasarımı günlük operasyonu gereksiz yere engellemeden kritik işlemleri korumalıdır.

Database Administrator

DBA database performansı, schema ve operasyon işlemlerinden sorumlu olabilir. Bu rolün otomatik olarak encryption master key erişimine sahip olması gerekmez. Application-level encryption kullanıldığında DBA ciphertext'i yönetirken plaintext göremeyebilir. Kritik export işlemleri audit altında tutulmalıdır. DBA rolü ile key administrator rolünün ayrılması insider riskini azaltır.

Key Administrator

Key administrator key lifecycle ve policy yönetiminden sorumlu olabilir. Bu rolün uygulama verisini doğrudan okuma yetkisine ihtiyacı yoktur. Key oluşturma ve policy değiştirme operasyonları audit edilmelidir. Production decrypt yetkisi key administrator'a otomatik verilmemelidir. Bu ayrım görev kötüye kullanımının etkisini sınırlar.

Application Operator

Application operator deployment ve servis sağlığıyla ilgilenebilir. Bu rolün doğrudan master key materyalini görmesi gerekmez. Workload identity uygulamanın gerekli cryptographic operation'ı kendi adına yapmasını sağlar. İnsan kullanıcı için break-glass erişim gerekiyorsa kısa süreli ve onaylı olmalıdır. Operasyon erişimi düzenli olarak gözden geçirilmelidir.

Split Knowledge

Split knowledge kritik secret'ın tek bir kişi tarafından tamamen bilinmemesini hedefler. Key component veya recovery material birden fazla custodian arasında bölünebilir. Tek kişi tek başına kritik işlemi tamamlayamaz. Bu yaklaşım özellikle yüksek değerli root key süreçlerinde kullanılabilir. Backup ve recovery prosedürü düzenli olarak test edilmelidir.

İki Kişi Kontrolü Gerektiren Kritik İşlemler

Master key destruction gibi geri döndürülemez işlemler iki kişi kontrolüne bağlanabilir. Root key import veya HSM initialization benzeri görevler de bu kapsama alınabilir. Onay mekanizması yalnızca uygulama arayüzünde görüntülenen bir kutudan ibaret olmamalıdır. İki bağımsız identity ve audit izi bulunmalıdır. Acil durum prosedürü de aynı güvenlik modelini mümkün olduğunca korumalıdır.

Encryption Key Erişim Kontrolü

Key management sisteminin güvenliği erişim politikası kadar güçlüdür. Her servis bütün key'lere erişebiliyorsa merkezi KMS kullanmanın sağlayacağı ayrım azalır. Least privilege ile yalnızca gerekli cryptographic operation yetkisi verilmelidir. Encrypt ve decrypt izinleri belirli senaryolarda birbirinden ayrılabilir. Workload identity ve short-lived credentials uzun ömürlü statik secret kullanımını azaltır.

Least Privilege

Least privilege her kimliğe yalnızca işini yapmak için gereken en düşük yetkinin verilmesini hedefler. Bir upload servisi yalnızca encrypt yapıyorsa decrypt iznine ihtiyacı olmayabilir. Tenant-specific key'lerde servis scope'u daha da daraltılabilir. Yetkiler periyodik review ile kaldırılmalıdır. Kullanılmayan permissions saldırgan için gereksiz fırsat oluşturur.

RBAC

RBAC yetkileri kullanıcı veya servis rollerine göre yönetir. Key administrator, security auditor ve application workload gibi roller ayrılabilir. Rol sayısı gereğinden fazla olursa yönetim zorlaşabilir. Her rolün amacı ve izin seti belgelenmelidir. Production key rolleri test ortamından ayrılmalıdır.

ABAC

ABAC erişim kararlarında identity attribute, resource tag veya ortam bilgisi gibi nitelikleri kullanabilir. Örneğin yalnızca production workload tag'ine sahip kimlik belirli key'e erişebilir. Bu model dinamik policy yönetimini kolaylaştırabilir. Yanlış attribute yönetimi beklenmeyen yetki genişlemesine yol açabilir. Policy testleri CI/CD sürecine eklenmelidir.

Workload Identity

Workload identity uygulama veya service'in kendi kimliğiyle cloud ve KMS kaynaklarına erişmesini sağlar. Statik access key dağıtma ihtiyacını azaltır. Credential kısa ömürlü olabilir ve otomatik yenilenebilir. Her workload için ayrı identity kullanmak audit kalitesini artırır. Ortak servis hesabı kullanımı mümkün olduğunca azaltılmalıdır.

Short-Lived Credentials

Short-lived credentials ele geçirildiğinde saldırganın kullanabileceği süreyi sınırlar. Uzun ömürlü access key'lerden daha kontrollü model sunar. Otomatik token yenileme uygulama operasyonunu kolaylaştırabilir. Credential süresi uygulamanın çalışma modeliyle uyumlu olmalıdır. Renewal failure senaryosu availability testlerine dahil edilmelidir.

Decrypt Yetkisinin Encrypt Yetkisinden Ayrılması

Bazı servisler veri üretebilir ancak gerçek veriyi tekrar okumaya ihtiyaç duymaz. Bu durumda yalnızca encrypt yetkisi vermek risk alanını küçültür. Decrypt izni daha dar bir servis grubuna bırakılabilir. Böyle bir ayrım ransomware veya compromised workload senaryolarında değerli olabilir. IAM policy doğrudan cryptographic action bazında tasarlanmalıdır.

Key Access Nasıl İzlenir?

Key access monitoring anahtarın yalnızca kimlere açık olduğunu değil gerçekte nasıl kullanıldığını görmeyi sağlar. Normal davranış baseline'ı oluşturulduğunda beklenmeyen decrypt artışı tespit edilebilir. Identity, region, saat ve operasyon türü önemli sinyallerdir. KMS audit logları merkezi SIEM sistemine aktarılabilir. Alarm üretmek kadar alarmın kimin tarafından inceleneceğinin belirlenmesi de önemlidir.

Encryption Operations

Encryption operasyon hacmi uygulamanın normal iş yükü hakkında bilgi verir. Ani artış batch işleminden kaynaklanabileceği gibi kötüye kullanım göstergesi de olabilir. Key ve workload bazında metrik tutulmalıdır. Yeni servis deployment'ları baseline değişimini açıklayabilir. Monitoring sistemi bilinen operasyonları context ile eşleştirmelidir.

Decryption Operations

Decryption operasyonları genellikle encryption'dan daha hassas izlenmelidir. Çünkü plaintext veriye erişim gerçekleşir. Kullanıcı ve servis bazında decrypt hacmi ölçülebilir. Normalde decrypt yapmayan identity'nin çağrısı yüksek öncelikli alarm olabilir. Audit kaydı veri sınıfı bilgisiyle zenginleştirilirse analiz daha anlamlı olur.

Unusual Decryption Volume

Olağan dışı decrypt hacmi veri toplama veya hesap ele geçirme belirtisi olabilir. Sabit eşik her sistem için doğru çalışmayabilir. İş günü, batch zamanı ve tenant büyüklüğü gibi bağlamlar dikkate alınmalıdır. P95 veya historical baseline üzerinden anomaly detection uygulanabilir. Alarm sonrasında ilgili workload ve database sorguları birlikte incelenmelidir.

Unexpected Identity

Beklenmeyen identity tarafından key kullanımı doğrudan yetki hatasına işaret edebilir. Yeni servis deployment'ı meşru neden olabilir ancak change record ile eşleşmelidir. İnsan kullanıcıların production decrypt çağrıları ayrıca izlenebilir. Break-glass erişim otomatik alarm üretmelidir. Identity lifecycle ile key policy review birlikte yapılmalıdır.

Unexpected Region

Key'in normalde kullanılmadığı region üzerinden çağrı alması şüpheli olabilir. Multi-region architecture varsa izin verilen region listesi belgelenmelidir. Cross-region backup veya disaster recovery operasyonları meşru istisna oluşturabilir. Geo sinyali tek başına kesin saldırı kanıtı değildir. Diğer identity ve volume sinyalleriyle birlikte değerlendirilmelidir.

SIEM Alerts

SIEM farklı sistemlerden gelen audit loglarını birleştirerek daha güçlü detection sağlayabilir. KMS decrypt çağrısı ile aynı anda gerçekleşen privileged login korelasyonu değerli sinyal oluşturabilir. Alarm kuralları düzenli test edilmelidir. Çok fazla false positive güvenlik ekibinin gerçek olayları kaçırmasına yol açabilir. Her alarm için açık investigation playbook hazırlanmalıdır.

Audit Trail

Audit trail key lifecycle ve kullanım olaylarının izlenebilir kaydıdır. Key creation, policy change, decrypt ve destruction gibi kritik olaylar bulunmalıdır. Logların sonradan değiştirilebilmesi investigation güvenilirliğini azaltır. Merkezi ve erişimi sınırlandırılmış logging altyapısı tercih edilmelidir. Retention süresi regülasyon ve incident response ihtiyacına göre belirlenmelidir.

Data in Transit Nasıl Korunur?

Ağ üzerinden taşınan hassas veri TLS ile korunmalıdır. Yalnızca internet trafiğini şifrelemek yeterli değildir. Uygulama ile database, servisler, message broker ve yönetim API'leri arasındaki bağlantılar da değerlendirilmelidir. TLS sertifika doğrulaması kapatılmamalıdır. Yüksek güven gereksinimlerinde service-to-service authentication için mTLS kullanılabilir.

TLS

TLS ağ trafiğinin gizlilik, bütünlük ve server authentication özelliklerini sağlamaya yardımcı olur. Modern sistemlerde TLS 1.3 varsayılan tercih olmalıdır. Uyum gereksinimi varsa TLS 1.2 güvenli yapılandırmayla desteklenebilir. Eski TLS ve SSL sürümleri kapatılmalıdır. Sertifika doğrulaması protokolün temel güvenlik özelliklerinden biridir.

HTTPS

HTTPS HTTP trafiğinin TLS üzerinden taşınmasıdır. Login, API ve normal web sayfaları dahil bütün uygulama trafiğinde kullanılmalıdır. Hassas sayfalarda başlayıp diğer sayfalarda HTTP'ye dönmek doğru değildir. HSTS istemcilerin HTTPS kullanımını zorlamaya yardımcı olabilir. Cookie security ayarları da HTTPS ile birlikte ele alınmalıdır.

Database TLS

Database bağlantıları internal network üzerinde olsa bile TLS ile korunmalıdır. Network segment güvenliği tek başına trafik gizliliğini garanti etmez. Database driver certificate validation yapacak biçimde ayarlanmalıdır. Encryption etkin ancak certificate verification kapalıysa man-in-the-middle riski devam edebilir. Connection string ve driver davranışı production deployment sırasında doğrulanmalıdır.

Service-to-Service TLS

Microservice trafiği hassas veri taşıyabilir. Aynı cluster veya VPC içinde olmak encryption gereksinimini ortadan kaldırmaz. TLS veya service mesh destekli mTLS kullanılabilir. Certificate lifecycle otomatik yönetilirse operasyon yükü azalır. Network policy ile TLS kimlik doğrulaması birbirini tamamlayan kontrollerdir.

Message Broker TLS

Message broker üzerinden event ve command mesajları taşınırken hassas bilgi bulunabilir. Producer, broker ve consumer bağlantıları TLS ile korunmalıdır. Authentication credential'ları da güvenli channel üzerinden gönderilmelidir. Queue veya topic authorization ayrıca uygulanmalıdır. Broker disk persistence kullanıyorsa data at rest encryption da değerlendirilmelidir.

mTLS

mTLS hem server hem client tarafının sertifika ile kimlik doğrulamasını sağlar. Service-to-service iletişimde güçlü workload identity modeli oluşturabilir. Certificate issuance ve rotation otomatikleştirilmelidir. Revoked certificate'ın kısa sürede etkisiz hâle gelmesi önemlidir. mTLS uygulama-level authorization ihtiyacını ortadan kaldırmaz.

TLS 1.3 Güvenli Yapılandırması

TLS 1.3 modern transport encryption için güçlü varsayılanlar sunar. Protokol seçimi yanında sertifika doğrulaması, HSTS, cipher policy ve library güncelliği de önemlidir. Uyumluluk nedeniyle TLS 1.2 açık tutulacaksa yalnızca güçlü suite'ler tercih edilmelidir. TLS 1.0 ve 1.1 gibi eski sürümler kapatılmalıdır. Sunucu yapılandırması otomatik scanner ve düzenli security test ile doğrulanmalıdır.

TLS 1.3 Default

Yeni uygulamalar TLS 1.3'ü varsayılan protokol olarak tercih etmelidir. Modern tarayıcı ve sunucu platformlarında geniş destek bulunur. Protokol daha sade cipher suite seçimi ve güçlü handshake özellikleri sunar. Server configuration yanlış yapılırsa yine sertifika veya application security problemleri yaşanabilir. TLS version tek başına bütün web güvenliğini çözmez.

TLS 1.2 Uyumluluğu

Eski fakat hâlen desteklenmesi gereken client'lar TLS 1.2 gerektirebilir. Bu durumda güçlü AEAD cipher suite'leri kullanılmalıdır. Legacy client ihtiyacı düzenli olarak yeniden değerlendirilmelidir. Gereksiz TLS 1.2 desteği zamanla kaldırılabilir. Uyumluluk amacıyla daha eski protokollere geri dönmekten kaçınılmalıdır.

Eski TLS Sürümlerinin Kapatılması

SSLv2 ve SSLv3 uzun süredir güvenli kabul edilmez. TLS 1.0 ve TLS 1.1 de modern uygulamalar için kullanılmamalıdır. Server configuration yalnızca güvenli protokol sürümlerini kabul etmelidir. Load balancer ve reverse proxy üzerinde de aynı policy uygulanmalıdır. Güvenlik scanner'ları eski protokol desteğini CI/CD veya sürekli monitoring sırasında tespit edebilir.

AEAD Cipher Suites

AEAD cipher suite'ler encryption ve authentication özelliklerini birlikte sunar. TLS 1.3 AES-GCM ve ChaCha20-Poly1305 gibi modern seçenekleri kullanır. Manuel olarak uzun cipher listeleri üretmek yerine güncel platform varsayılanları değerlendirilmelidir. Legacy ve zayıf suite'ler açık bırakılmamalıdır. Cipher policy düzenli security test ile doğrulanmalıdır.

Certificate Validation

TLS yalnızca trafiği şifrelemek değil karşı tarafın kimliğini doğrulamak için de kullanılır. Certificate validation kapatılırsa saldırgan kendi sertifikasıyla araya girebilir. Hostname ve trust chain kontrolleri doğru yapılmalıdır. Self-signed sertifika gerekiyorsa güven zinciri kontrollü biçimde dağıtılmalıdır. Development amacıyla kapatılan validation ayarının production'a taşınmaması gerekir.

HSTS

HSTS browser'a belirli site için yalnızca HTTPS kullanması gerektiğini bildirir. HTTP downgrade ve kullanıcıların yanlışlıkla insecure bağlantıya gitmesi riskini azaltır. Header süresi planlı biçimde artırılabilir. Subdomain kapsamı yapı değerlendirilerek seçilmelidir. HSTS etkinleştirmeden önce bütün ilgili hostların HTTPS'i doğru desteklediği doğrulanmalıdır.

Mutual TLS (mTLS) Nedir?

mTLS standart TLS server authentication modelini client certificate doğrulamasıyla genişletir. Böylece yalnızca sunucu değil istemci servis de cryptographic identity sunar. Microservice ve machine-to-machine iletişimde güçlü bir kimlik katmanı sağlayabilir. Certificate lifecycle yönetilmezse büyük sistemlerde operasyon yükü artar. Otomatik issuance, renewal ve revocation mekanizmaları bu nedenle tasarımın merkezinde olmalıdır.

Server Authentication

Normal TLS bağlantısında client server'ın sertifikasını doğrular. Bu işlem doğru endpoint'e bağlanıldığını kanıtlamaya yardımcı olur. Hostname ve trust chain kontrolü yapılmalıdır. mTLS bu server authentication davranışını korur. Buna ek olarak server da client certificate'ını doğrular.

Client Authentication

mTLS client'ın da sertifika sunmasını gerektirir. Server certificate üzerinden client identity'yi doğrulayabilir. Bu identity uygulama authorization kararlarında kullanılabilir. Shared API key ihtiyacı bazı servisler arasında azaltılabilir. Certificate private key'in güvenli saklanması yine kritik öneme sahiptir.

Service-to-Service Identity

Microservice mimarisinde her workload için ayrı kimlik oluşturmak audit ve authorization kalitesini artırır. mTLS certificate subject veya ilgili identity metadata'sı bu amaçla kullanılabilir. Ortak sertifika bütün servislerde paylaşılmamalıdır. Bir servis compromise olduğunda blast radius sınırlandırılmalıdır. Service identity düzenli olarak rotate edilmelidir.

Certificate Lifecycle

Certificate yalnızca oluşturma anında değil bütün yaşam döngüsünde yönetilmelidir. Issuance, distribution, renewal, revocation ve expiration monitoring gerekir. Süresi dolan certificate beklenmedik outage oluşturabilir. Kısa ömürlü sertifikalar güvenliği artırırken automation ihtiyacını güçlendirir. Lifecycle merkezi PKI veya service mesh mekanizmasıyla yönetilebilir.

Certificate Rotation

Certificate rotation yeni certificate'ın eski sürüm sona ermeden devreye alınmasını gerektirir. İki tarafın trust store'u geçişi desteklemelidir. Otomatik rotation manuel hataları azaltır. Rotation testleri production dışı ortamda düzenli yapılmalıdır. Expiration alarmı son gün yerine yeterli süre önceden üretilmelidir.

Zero Trust ile İlişkisi

Zero Trust yaklaşımı internal network'ü otomatik olarak güvenilir kabul etmez. Her bağlantının identity ve authorization bilgisine göre değerlendirilmesini teşvik eder. mTLS service identity sağlamaya yardımcı olabilir. Bununla birlikte sadece mTLS kullanmak Zero Trust mimarisini tamamlamaz. Resource-level authorization, device posture ve monitoring gibi ek kontroller gerekir.

Database Bağlantılarında TLS

Database bağlantıları çoğu zaman uygulama güvenliğinin gözden kaçan ağ katmanıdır. Kullanıcı ile web uygulaması HTTPS kullanırken backend ile database arasındaki trafik plaintext bırakılabilir. Bu yapı internal network üzerinde sniffing veya yanlış routing gibi riskleri artırır. Database TLS etkinleştirilmeli ve certificate verification açık tutulmalıdır. Driver configuration deployment testleriyle doğrulanmalıdır.

PostgreSQL

PostgreSQL TLS bağlantılarını destekler ve client tarafında farklı doğrulama modları kullanılabilir. Production sistemde yalnızca encryption açmak yerine server certificate doğrulaması yapılmalıdır. Connection string yanlış ayarlanırsa client beklenenden zayıf doğrulama kullanabilir. Root certificate güvenli biçimde dağıtılmalıdır. Database proxy veya pooler kullanılıyorsa her bağlantı ayağı ayrıca incelenmelidir.

MySQL

MySQL bağlantılarında TLS etkinleştirilerek client ve server arasındaki trafik korunabilir. Driver seçeneklerinin certificate verification davranışı sürüme göre kontrol edilmelidir. Sadece TLS required seçeneği her zaman hostname verification anlamına gelmeyebilir. CA ve server identity doğrulaması production standardına dahil edilmelidir. Replication trafiği de aynı güvenlik değerlendirmesine alınmalıdır.

SQL Server

SQL Server bağlantıları TLS ile korunabilir. Client'ın server certificate'ına güvenme davranışı doğru yapılandırılmalıdır. Certificate validation'ı bypass eden seçeneklerin production'da kullanılmaması gerekir. Uygulama, reporting ve admin bağlantıları aynı policy kapsamına alınmalıdır. Legacy driver'ların protocol desteği ayrıca kontrol edilmelidir.

Certificate Verification

Certificate verification olmadan encryption etkin olsa bile doğru server'a bağlanıldığı garanti edilemeyebilir. Client trust chain ve hostname kontrolü yapmalıdır. Development ortamındaki trust bypass ayarları production config'e taşınmamalıdır. Certificate renewal sonrası trust problemleri için monitoring kurulmalıdır. Bağlantı testi CI veya deployment pipeline içinde otomatikleştirilebilir.

Internal Network Trafiği de Encrypt Edilmeli mi?

Evet, hassas veri taşıyan internal network trafiği de şifrelenmelidir. Network segment içinde olmanın tek başına güvenlik garantisi olmadığı kabul edilmelidir. Compromised host veya yanlış network policy trafik izleme fırsatı oluşturabilir. TLS veya mTLS internal servisler arasında güçlü koruma sağlar. Performans etkisi gerçek sistemde ölçülebilir ancak modern altyapılarda çoğu iş yükü için yönetilebilir seviyededir.

Hassas Veri Log'larda Nasıl Korunur?

Log sistemi çoğu zaman üretim verisinin beklenmeyen ikinci kopyasına dönüşür. Debug amacıyla yazılan request body içinde parola, token veya PII bulunabilir. Bu nedenle logging policy hangi alanların hiçbir koşulda yazılmaması gerektiğini açıkça tanımlamalıdır. Structured logging ve merkezi redaction mekanizmaları uygulama ekiplerinin hata yapma riskini azaltır. Log retention ve erişim yetkisi de hassas veri politikasının parçasıdır.

Password Loglamamak

Kullanıcı parolası hiçbir log seviyesinde kaydedilmemelidir. Authentication başarısız olduğunda girilen parolayı debug amacıyla yazmak ciddi güvenlik açığıdır. Reverse proxy ve request tracing mekanizmaları da kontrol edilmelidir. Exception object'leri bazen request payload içerebilir. Security testleri loglarda password pattern'i aramalıdır.

Access Token Loglamamak

Access token çoğu sistemde bearer credential olarak çalışır. Loga yazılırsa log erişimi bulunan kişi token süresi boyunca hesabı taklit edebilir. Authorization header merkezi logging middleware tarafından redacted edilmelidir. Query string içinde token taşımaktan da kaçınılmalıdır. Incident durumunda log sızıntısı ilgili token rotation sürecini tetikleyebilir.

PII Redaction

PII redaction log mesajı kaydedilmeden önce hassas alanları kaldırır veya maskeler. Her geliştiricinin manuel olarak mask uygulamasına güvenmek hata riskini artırır. Merkezi serializer veya logging filter kullanılabilir. Field listesi data classification envanteriyle eşleştirilmelidir. Yeni PII alanı eklendiğinde redaction rule da güncellenmelidir.

Structured Logging

Structured logging log verisini tanımlı alanlarla üretir. Bu yapı hassas field'ların merkezi olarak filtrelenmesini kolaylaştırır. Serbest metin loglarda PII tespiti daha zor olabilir. Schema validation hassas alan isimlerini pipeline aşamasında engelleyebilir. Structured yaklaşım SIEM analizini de daha güvenilir hâle getirir.

Log Masking

Masking gerçek değerin tamamını göstermeden operasyon için gerekli kısmı tutabilir. Örneğin müşteri destek ekibi yalnızca belirli son karakterleri görebilir. Masked değer yine de kişisel veri sayılabilecek bağlam taşıyabilir. Bu nedenle log erişimi sınırlı olmalıdır. Masking encryption veya redaction gereksinimini otomatik olarak ortadan kaldırmaz.

Debug Mode Riskleri

Debug mode production ortamında gereğinden fazla veri kaydedebilir. Stack trace, environment variable ve request payload secret içerebilir. Production logging seviyesi açık policy ile sınırlandırılmalıdır. Debug geçici açılırsa süre ve yetkili kişi kaydedilmelidir. İşlem sonrasında oluşan loglar hassas veri açısından incelenmelidir.

Log Retention

Logları süresiz saklamak incident investigation için faydalı görünse de veri riskini artırır. Retention kullanım amacı ve compliance gereksinimine göre belirlenmelidir. Eski loglar otomatik silinmelidir. Archive edilen loglar şifrelenmeli ve erişimleri sınırlandırılmalıdır. Backup retention ile log retention birbirine karıştırılmamalıdır.

Cache ve Temporary Data Güvenliği

Hassas veriler sadece ana database içinde bulunmaz. Cache, browser storage, CDN, temporary file, swap ve crash dump gibi geçici alanlara da yayılabilir. Bu kopyalar ana veri envanterinde görünmediğinde güvenlik politikası dışında kalır. Veri akış analizi bütün geçici depolama noktalarını belirlemelidir. Gereksiz hassas cache kullanımını tamamen kaldırmak çoğu zaman en güvenli çözümdür.

Application Cache

Application cache performans için veriyi process memory veya local storage içinde tutabilir. Hassas plaintext gereğinden uzun süre tutulmamalıdır. Cache TTL ve eviction policy veri sınıfına göre ayarlanabilir. Shared cache kullanılıyorsa tenant isolation özellikle test edilmelidir. Cache debug dump'larının production dışına çıkması engellenmelidir.

Redis

Redis session ve application cache için yaygın biçimde kullanılabilir. Hassas veri tutuluyorsa network TLS ve authentication etkinleştirilmelidir. Internet'e açık Redis instance ciddi güvenlik riskidir. Disk persistence kullanılıyorsa at-rest encryption ayrıca değerlendirilmelidir. Key naming convention içinde PII kullanmaktan kaçınılmalıdır.

Browser Cache

Browser cache istemci cihazında hassas response verisini tutabilir. Finansal veya kişisel sayfalarda uygun Cache-Control header'ları kullanılmalıdır. Logout işlemi her cache kopyasını otomatik temizlemeyebilir. LocalStorage ve sessionStorage içinde uzun ömürlü secret tutmak ayrıca risklidir. Client-side storage threat model içinde açıkça değerlendirilmelidir.

CDN

CDN edge lokasyonlarında response kopyaları oluşturabilir. Hassas kullanıcıya özel içerik yanlış cache key nedeniyle başka kullanıcıya gösterilebilir. Authorization header ve cookie davranışı cache policy ile birlikte kontrol edilmelidir. Sensitive endpoint'lerde caching tamamen kapatılabilir. CDN logları da PII ve token açısından incelenmelidir.

Temporary Files

Uygulamalar upload, export veya dönüşüm işlemleri sırasında temporary file oluşturabilir. Bu dosyalar plaintext hassas veri içerebilir. Güvenli temporary directory ve doğru file permission kullanılmalıdır. İşlem bittikten sonra dosya kaldırılmalıdır. Container veya server crash olduğunda kalan dosyaların temizlenme süreci de planlanmalıdır.

Swap/Page File

İşletim sistemi memory içeriğini swap veya page file alanına yazabilir. Böylece plaintext key veya hassas veri disk üzerinde beklenmedik kopya oluşturabilir. Full disk encryption bu riski azaltmaya yardımcı olur. Çok yüksek hassasiyetli sistemlerde swap politikası ayrıca yapılandırılabilir. Memory locking gibi ileri teknikler platform desteğine göre değerlendirilebilir.

Crash Dumps

Crash dump process memory'sinin büyük bölümünü içerebilir. Bu nedenle key, password veya PII bulunma ihtimali vardır. Production dump erişimi yalnızca yetkili mühendislerle sınırlandırılmalıdır. Dump transferi ve storage encryption ile korunmalıdır. Retention süresi hata analizi ihtiyacından uzun tutulmamalıdır.

Core Dumps

Core dump native process memory'sini ayrıntılı biçimde kaydedebilir. Cryptographic key ve plaintext data dump içinde bulunabilir. Production sistemlerde core dump politikası veri hassasiyetine göre belirlenmelidir. Gerekli dump dosyaları encrypted storage üzerinde tutulmalıdır. Analiz tamamlandığında güvenli biçimde silinmelidir.

Backup ve Snapshot Encryption

Backup ve snapshot sistemleri production verisinin yüksek değerli kopyalarını içerir. Ana sistem güçlü biçimde korunurken yedeklerin zayıf bırakılması saldırgan için daha kolay hedef yaratır. Backup encryption, key lifecycle ve restore testleri birlikte planlanmalıdır. Cross-region kopyalarda key availability ayrıca önemlidir. Disaster recovery tatbikatı yalnızca dosyanın varlığını değil gerçek decryption ve restore başarısını test etmelidir.

Production Encryption Backup'a Otomatik Yansır mı?

Hayır, production verisinin şifreli olması backup'ın otomatik olarak aynı korumaya sahip olduğu anlamına gelmez. Database veya storage ürününün backup davranışı doğrulanmalıdır. Bazı sistemler backup'ı ayrı key ile encrypt eder. Export işlemleri plaintext dosya oluşturabilir. Her backup yöntemi veri akış envanterinde ayrı asset olarak değerlendirilmelidir.

Backup Key Yönetimi

Backup key'leri aktif production key'lerinden farklı lifecycle gerektirebilir. Yedek yıllarca saklanıyorsa decrypt key'in de gerekli süre boyunca erişilebilir olması gerekir. Buna rağmen key'i plaintext olarak backup yanında tutmak uygun değildir. Recovery key erişimi dar yetki ve audit altında bulunmalıdır. Key backup'larının kendisi de güvenli biçimde korunmalıdır.

Cross-Region Backup

Cross-region backup disaster recovery dayanıklılığını artırabilir. Ancak hedef region'ın key policy ve data residency gereksinimleri kontrol edilmelidir. Customer-managed key kullanılıyorsa target region'da uygun key erişimi gerekebilir. Restore sırasında cross-region KMS bağımlılığı test edilmelidir. Network ve replication trafiği de encrypt edilmelidir.

Restore Sırasında Key Availability

Backup var ancak decryption key erişilemiyorsa recovery başarısız olur. Disaster recovery tatbikatları KMS outage senaryosunu da değerlendirmelidir. Key replication veya recovery policy platform yeteneklerine göre tasarlanabilir. Çok fazla key kopyası oluşturmak güvenlik riskini artırabilir. Availability ile key exposure arasında kontrollü denge kurulmalıdır.

Backup Retention

Backup retention ana verinin retention süresiyle uyumlu olmalıdır. Silinmesi gereken verinin eski backup içinde yıllarca kalması veri minimizasyonu hedefini zayıflatabilir. Immutable backup ransomware koruması sağlarken veri silme süreçlerini etkileyebilir. Hukuki ve teknik gereksinimler birlikte değerlendirilmelidir. Retention policy otomatik uygulanmalıdır.

Key Silmenin Backup'a Etkisi

Encryption key silindiğinde ilgili backup geri yüklenemez hâle gelebilir. Bu bazen crypto-shredding için istenen sonuçtur. Yanlışlıkla key silmek ise felaket recovery planını bozabilir. Key destruction öncesinde bağlı backup inventory kontrol edilmelidir. Geri döndürülemez işlemler ek approval gerektirebilir.

Disaster Recovery Testi

Disaster recovery testi gerçek restore yolunu uçtan uca doğrulamalıdır. Backup dosyasının mevcut olması tek başına yeterli değildir. KMS access, certificate, IAM policy ve application decryption işlemleri de test edilmelidir. Recovery süresi ölçülmeli ve hedeflerle karşılaştırılmalıdır. Test sonunda ortaya çıkan key dependency sorunları dokümante edilmelidir.

Mobile Uygulamalarda Güvenli Veri Depolama

Mobil uygulamalar kullanıcı cihazında hassas veri ve credential saklayabilir. Normal preference veya plaintext local database yüksek riskli bilgiler için uygun değildir. İşletim sisteminin Android Keystore ve iOS Keychain gibi güvenli storage mekanizmaları tercih edilmelidir. Hardware-backed key seçenekleri cihaz desteğine göre ek koruma sağlar. Cache, screenshot, backup ve debug logları da mobil threat model içinde değerlendirilmelidir.

Android Keystore

Android Keystore cryptographic key'lerin uygulama tarafından güvenli biçimde yönetilmesine yardımcı olur. Key materyali desteklenen cihazlarda hardware-backed ortamda korunabilir. Uygulama key'i doğrudan export etmek yerine cryptographic operation çağırabilir. Device compatibility ve Android version farkları test edilmelidir. Root edilmiş cihaz senaryosu ayrıca threat model içinde yer almalıdır.

Hardware-Backed Keys

Hardware-backed keys secret materyalin işletim sistemi process memory'sine daha az maruz kalmasını sağlayabilir. Key belirli secure hardware içinde oluşturulabilir. Biometric veya device unlock policy ile kullanım koşulu bağlanabilir. Her cihaz aynı hardware capability'ye sahip değildir. Uygulama fallback davranışını güvenli biçimde tasarlamalıdır.

iOS Keychain

iOS Keychain password, token ve belirli secret'ların güvenli saklanması için platform mekanizmasıdır. Accessibility class seçimi verinin hangi cihaz durumunda erişilebilir olduğunu etkiler. Backup davranışı kullanım amacına göre kontrol edilmelidir. Hassas token normal user defaults içinde tutulmamalıdır. Device compromise tehdidi tamamen ortadan kalkmasa da platform storage kullanmak önemli güvenlik avantajı sağlar.

Secure Enclave

Secure Enclave belirli Apple cihazlarında cryptographic key işlemlerini izole donanım ortamında gerçekleştirebilir. Private key export edilmeden signing veya key agreement gibi işlemler yapılabilir. Her algoritma ve key türü Secure Enclave tarafından desteklenmeyebilir. Kullanım öncesinde platform API'si ve cihaz gereksinimi kontrol edilmelidir. Recovery ve device migration senaryosu tasarımın parçası olmalıdır.

Local Database Encryption

Mobil local database hassas offline veri tutuyorsa encryption değerlendirilebilir. Database key'i source code içine gömülmemelidir. Key platform secure storage üzerinden korunabilir. Query performansı ve migration işlemleri gerçek cihazlarda test edilmelidir. Uygulama uninstall ve logout davranışı local ciphertext ve key lifecycle açısından tanımlanmalıdır.

Cache Temizliği

Mobil uygulama görüntü, API response veya temporary file cache'i oluşturabilir. Logout sırasında hassas cache kaldırılmalıdır. OS backup veya share mekanizmasının cache'i dışarı taşıyıp taşımadığı kontrol edilmelidir. WebView cache ve cookie'leri ayrıca değerlendirilmelidir. Cache TTL veri sınıfına göre sınırlandırılmalıdır.

Hassas Verilerin Backup'a Dahil Edilmemesi

Mobil işletim sistemi uygulama verisini cloud backup'a dahil edebilir. Hassas local database veya secret dosyaları için bu davranış uygun olmayabilir. Platformun backup exclusion mekanizmaları kullanılmalıdır. Key ile ciphertext'in farklı backup davranışı recovery problemleri yaratabilir. Gerçek cihaz backup ve restore testi yapılmalıdır.

Cloud Ortamında Hassas Veri Depolama

Cloud platformları birçok storage hizmetinde encryption by default sunar. Bu önemli bir temel kontroldür ancak bütün veri güvenliği sorunlarını çözmez. Key ownership, cross-account access, public exposure ve IAM policy ayrı olarak yönetilmelidir. Customer-managed key gereksinimi veri sınıfına göre belirlenebilir. Cloud security posture yönetimi unencrypted veya yanlış yapılandırılmış kaynakları otomatik tespit etmelidir.

Encryption by Default

Encryption by default yeni storage kaynaklarının şifrelenmeden oluşturulmasını önler. Bu güvenli varsayılan insan hatasını azaltır. Ancak kullanılan key'in kim tarafından yönetildiği ayrıca önemlidir. Policy as code kaynak oluşturma sırasında gerekli key type'ı zorunlu kılabilir. Default encryption açık olsa bile public access riskleri devam eder.

Object Storage

Object storage büyük miktarda dosya ve backup için kullanılabilir. Bucket-level encryption zorunlu tutulmalıdır. Public access block ve IAM policy ayrıca uygulanmalıdır. Customer-managed key kullanılıyorsa object access ile key access izinleri birlikte çalışır. Cross-account replication senaryosu target key policy açısından test edilmelidir.

Managed Database

Managed database hizmetleri at-rest encryption ve TLS özellikleri sunabilir. TDE benzeri storage encryption DBA threat modelini tek başına çözmez. Sensitive column'lar için application-level encryption yine gerekebilir. Backup, replica ve snapshot encryption davranışı doğrulanmalıdır. Service account permissions least privilege ile sınırlandırılmalıdır.

Block Storage

Block storage volume encryption VM disklerinin fiziksel kopyasını korur. Snapshot'lar aynı veya farklı key kullanabilir. Volume attach permission ayrı bir erişim kontrolüdür. Root disk içinde secret bulunabileceği için image ve snapshot paylaşımı dikkatle yönetilmelidir. Customer-managed key disable işleminin VM availability etkisi önceden bilinmelidir.

Data Lake

Data lake çok farklı hassasiyet seviyesindeki verileri aynı storage mimarisinde toplayabilir. Veri sınıfına göre zone veya bucket ayrımı yapmak faydalıdır. Encryption key scope'u data classification ile eşleştirilebilir. Analytics engine ve ETL workload'larının decrypt permissions değerleri dar tutulmalıdır. PII keşfi ve classification otomatik scanner'larla desteklenebilir.

Data Warehouse

Data warehouse çok sayıda kaynaktan gelen kişisel ve ticari veriyi bir araya getirebilir. Storage encryption yanında row ve column access policy kullanılmalıdır. Export edilen CSV dosyaları yeni hassas veri kopyası oluşturur. Query loglarında plaintext PII bulunup bulunmadığı kontrol edilmelidir. Analytics kullanıcılarının doğrudan decrypt yetkisi yerine masked view kullanması tercih edilebilir.

Customer-Managed Keys

Customer-managed keys cloud storage üzerinde daha ayrıntılı kontrol sağlar. Key disable edilerek belirli asset'lere erişim merkezi biçimde durdurulabilir. Bu güç yanlış policy veya yanlışlıkla deletion durumunda availability riskini de artırır. Rotation ve recovery süreçleri otomatikleştirilmelidir. Key ownership açık bir ekip veya role atanmalıdır.

Cross-Account Access

Cross-account access cloud ortamında veri ve key trust boundary'sini genişletir. Bir hesabın storage erişimi olması key decrypt yetkisine otomatik sahip olması anlamına gelmemelidir. Resource policy ve KMS policy birlikte incelenmelidir. Geçici paylaşım izinleri süreli olmalıdır. Audit logları hesaplar arası key kullanımını açıkça göstermelidir.

Multi-Tenant Sistemlerde Encryption

Multi-tenant sistemlerde müşterilerin verileri aynı application ve database altyapısını paylaşabilir. Tek global key operasyonu basitleştirir ancak blast radius değerini büyütür. Tenant-specific DEK veya data category-based DEK daha güçlü ayrım sağlar. Bu model tenant offboarding ve crypto-shredding süreçlerini de kolaylaştırabilir. Key sayısının artması nedeniyle automation ve KMS kullanımı temel gereksinim hâline gelir.

Tek Global Key Kullanmak

Tek global key bütün tenant verisinin aynı cryptographic sınırda bulunmasına neden olur. Key compromise bütün müşteri dataset'ini etkileyebilir. Rotation sırasında da çok geniş data re-encryption ihtiyacı oluşabilir. Küçük prototype dışında bu yaklaşımın riskleri dikkatle değerlendirilmelidir. Tenant veya veri sınıfı bazlı key hierarchy daha güvenli ölçeklenebilir.

Tenant-Specific DEK

Her tenant için ayrı DEK oluşturmak müşteriler arasında cryptographic isolation sağlar. Bir tenant key compromise olduğunda diğer tenant verileri etkilenmeyebilir. KMS içinde KEK kullanılarak çok sayıda wrapped DEK yönetilebilir. Tenant metadata hangi DEK version'ın kullanılacağını göstermelidir. Rotation tenant bazında aşamalı yapılabilir.

Data Category-Based DEK

Tenant yanında veri kategorisine göre ayrı DEK oluşturmak daha küçük blast radius sağlayabilir. Örneğin financial data ve profile data farklı key ile korunabilir. Bu model key inventory sayısını artırır. Otomatik provisioning ve policy enforcement bu nedenle zorunlu hâle gelir. Hangi ayrım seviyesinin gerekli olduğu threat model ile belirlenmelidir.

Key Blast Radius

Blast radius bir key compromise olduğunda etkilenecek veri kapsamını ifade eder. Key scope küçüldükçe potansiyel zarar alanı da küçülebilir. Buna karşılık key sayısı ve yönetim yükü artar. Envelope encryption bu dengeyi yönetmek için güçlü bir yapı sunar. Mimari review sırasında her master key'in kaç tenant ve veri sınıfını etkilediği sorulmalıdır.

Tenant Offboarding ve Crypto-Shredding

Tenant hizmetten ayrıldığında verinin silinmesi gerekebilir. Tenant-specific key kullanımı ilgili key'in destruction işlemiyle ciphertext'i kullanılamaz hâle getirmeye yardımcı olabilir. Ancak backup ve key replica kopyaları ayrıca değerlendirilmelidir. İşlem geri döndürülemez olduğu için approval ve retention kontrolleri gerekir. Silme kanıtı audit sisteminde kaydedilmelidir.

Tenant-Level Audit

Encryption ve decryption olaylarını tenant kimliğiyle ilişkilendirmek investigation sürecini kolaylaştırır. Normal decrypt hacmi tenant büyüklüğüne göre farklı olabilir. Bir tenant üzerinde ani artış müşteri hesabı veya servis compromise göstergesi olabilir. Audit metadata mümkün olduğunca plaintext hassas veri içermemelidir. Tenant-level dashboard güvenlik ve support ekiplerine görünürlük sağlayabilir.

Encryption ve Database Query Performansı

Encryption güvenlik kazancı sağlarken CPU, latency ve query kabiliyeti üzerinde maliyet oluşturabilir. Bu nedenle performans etkisini varsayımla değil benchmark ile ölçmek gerekir. AES hardware acceleration çoğu modern sistemde maliyeti düşürebilir. Asıl büyük etkiler bazen index kaybı ve KMS network latency kaynaklı olur. Mimari hem güvenlik hem kullanıcı deneyimi hedeflerini ölçülebilir metriklerle değerlendirmelidir.

CPU Overhead

Encryption ve decryption işlemleri CPU kullanır. Modern AES acceleration bu maliyeti birçok iş yükünde azaltabilir. Küçük request başına KMS çağrısı yapmak ise crypto işleminden daha pahalı olabilir. Profiling gerçek bottleneck'in nerede olduğunu göstermelidir. CPU metriği p95 ve p99 latency ile birlikte değerlendirilmelidir.

AES Hardware Acceleration

Donanım AES desteği throughput değerini önemli ölçüde artırabilir. Physical server, VM ve container ortamında desteğin gerçekten erişilebilir olduğu kontrol edilmelidir. Benchmark synthetic testle sınırlı kalmamalıdır. Gerçek payload boyutları kullanılmalıdır. CPU architecture değişiklikleri performans sonucunu etkileyebilir.

Index Kaybı

Randomized encryption database'in plaintext index yapısını kullanmasını engelleyebilir. Büyük datasetlerde full scan ciddi performans sorunu yaratabilir. Deterministic encryption veya blind index belirli equality query'lerde çözüm sunabilir. Bunun güvenlik maliyeti ayrıca değerlendirilmelidir. Query gereksinimi encryption schema tasarımından önce çıkarılmalıdır.

Deterministic Encryption'ın Avantaj ve Riski

Deterministic encryption equality search ve unique constraint gibi ihtiyaçları kolaylaştırabilir. Aynı plaintext'in aynı ciphertext üretmesi query yeteneği sağlar. Ancak tekrar pattern'i dışarı sızabilir. Düşük cardinality alanlarda tahmin riski daha belirgin olabilir. Kullanım yalnızca gereksinim bulunan alanlarla sınırlandırılmalıdır.

KMS Latency

Her record için remote KMS çağrısı yapmak yüksek latency ve maliyet oluşturabilir. Envelope encryption bu nedenle büyük veri için önemlidir. KMS yalnızca DEK wrap ve unwrap gibi küçük operasyonlarda kullanılabilir. DEK cache latency'yi azaltabilir ancak memory exposure süresini artırır. Cache TTL güvenlik ve performans dengesiyle belirlenmelidir.

DEK Cache

DEK cache aynı key'in sık kullanılan işlemlerde tekrar KMS'den alınmasını azaltır. Bu throughput ve latency açısından avantaj sağlar. Buna karşılık plaintext DEK memory'de daha uzun süre kalır. Cache süresi kısa tutulmalı ve process isolation sağlanmalıdır. Key revoke sinyali cache'i hızla geçersiz kılabilmelidir.

Encryption Benchmark

Benchmark gerçek payload boyutu ve concurrency ile yapılmalıdır. Sadece tek thread üzerinde megabyte başına süre ölçmek production davranışını göstermeyebilir. KMS latency, CPU, memory ve database query süresi birlikte izlenmelidir. Encryption on ve off testleri kontrollü ortamda karşılaştırılabilir. Sonuç güvenlik gereksiniminden vazgeçmek için değil uygun mimariyi seçmek için kullanılmalıdır.

Encryption Performansı Nasıl Ölçülür?

Encryption performansı yalnızca saniyede işlenen byte sayısıyla değerlendirilmemelidir. Kullanıcı request latency, CPU kullanımı, KMS çağrı hacmi ve operasyon maliyeti birlikte ölçülmelidir. P50 ortalama deneyimi gösterirken p95 ve p99 tail latency sorunlarını görünür kılar. Cache hit rate envelope encryption tasarımının davranışını anlamaya yardımcı olur. Her metrik encryption policy değişikliğinden sonra yeniden izlenmelidir.

Encryption Throughput

Encryption throughput belirli sürede ne kadar verinin şifrelenebildiğini ölçer. Payload büyüklüğü sonucu doğrudan etkiler. Hardware acceleration bulunan ve bulunmayan ortamlar ayrı test edilmelidir. Çok küçük payload'larda function overhead daha belirgin olabilir. Throughput hedefi gerçek business transaction hacmiyle karşılaştırılmalıdır.

Decryption Throughput

Decryption throughput uygulamanın okuyabileceği şifreli veri hızını gösterir. Read-heavy sistemlerde encryption throughput kadar önemli olabilir. Authentication tag validation da işlem maliyetine dahildir. Cache ve KMS davranışı sonucu etkiler. Testler normal ve peak trafik senaryolarını kapsamalıdır.

P50/P95/P99 Latency

P50 tipik request davranışını gösterir. P95 ve p99 ise yavaş uçları görünür hâle getirir. KMS network çağrısı gibi bağımlılıklar tail latency üzerinde büyük etki oluşturabilir. Encryption rollout öncesi ve sonrası aynı workload karşılaştırılmalıdır. Sadece ortalama değer kullanmak gerçek kullanıcı sorunlarını saklayabilir.

CPU Kullanımı

Encryption CPU kullanımını artırabilir ancak miktar algoritma, hardware ve payload'a göre değişir. CPU saturation latency artışına neden olabilir. Container CPU limitleri benchmark sonucunu etkiler. Profiling ile crypto function'ların toplam CPU içindeki payı ölçülmelidir. Scaling politikası yeni kullanım seviyesine göre güncellenebilir.

KMS API Calls

KMS API çağrı sayısı latency ve maliyet açısından kritik metriktir. Her database row için çağrı yapmak genellikle verimsizdir. Envelope encryption çağrı sayısını azaltabilir. Rate limit ve quota'lar peak trafik altında test edilmelidir. KMS hata oranı da availability metriği olarak izlenmelidir.

Cache Hit Rate

DEK cache hit rate kaç operasyonun remote KMS çağrısı olmadan tamamlandığını gösterir. Çok düşük hit rate latency sorununa işaret edebilir. Çok uzun cache TTL ise key exposure riskini artırabilir. Güvenlik ve performans hedefi birlikte tanımlanmalıdır. Cache invalidation key revoke senaryosunda ayrıca test edilmelidir.

Cost per Encryption Operation

Cloud KMS hizmetleri operation bazlı maliyet oluşturabilir. Toplam transaction hacmi üzerinden aylık maliyet hesaplanmalıdır. Envelope encryption doğrudan KMS operasyon sayısını azaltabilir. Cost yalnızca para değil latency ve operational capacity açısından da değerlendirilmelidir. Güvenlik mimarisi sürdürülebilir bütçeyle birlikte tasarlanmalıdır.

Encryption Policy as Code

Encryption policy yalnızca dokümanda kalırsa zaman içinde deployment gerçekliğinden kopabilir. Policy as code güvenlik gereksinimlerini otomatik deployment kontrollerine dönüştürür. Unencrypted storage veya yanlış key type CI/CD aşamasında engellenebilir. Infrastructure drift düzenli taramalarla tespit edilebilir. Böylece güvenlik kuralı hatırlanması gereken tavsiye yerine uygulanabilir teknik kontrol olur.

Unencrypted Storage'ın Otomatik Engellenmesi

Cloud resource oluşturma policy'si encryption kapalı storage taleplerini reddedebilir. Bu yöntem insan hatasını daha resource oluşmadan önler. Exception gerekiyorsa süreli ve onaylı süreç kullanılmalıdır. Existing resource'lar ayrıca scanner ile kontrol edilmelidir. Dashboard unencrypted asset sayısını güvenlik metriği olarak gösterebilir.

Terraform Policy

Terraform configuration CI aşamasında policy engine ile kontrol edilebilir. Storage encryption, customer-managed key ve public access kuralları otomatik doğrulanabilir. Pull request üzerinde hata geliştiriciye erken gösterilir. Policy repository değişiklikleri security review gerektirebilir. Test fixture'ları hem geçerli hem hatalı örnekler içermelidir.

Cloud Policy

Cloud-native policy sistemleri resource creation sırasında güvenlik kuralı uygulayabilir. Belirli data sınıfı tag'i bulunan resource için customer-managed key zorunlu tutulabilir. Policy inheritance hesap ve proje seviyesinde tasarlanmalıdır. Exception'lar görünür ve süreli olmalıdır. Policy violation merkezi security dashboard'a aktarılabilir.

CI/CD Security Checks

CI/CD pipeline source code ve infrastructure configuration üzerinde encryption kontrolleri çalıştırabilir. Hard-coded key, insecure cipher ve TLS config hataları build öncesi yakalanabilir. False positive oranı yönetilebilir tutulmalıdır. Yalnızca warning üretmek yerine kritik ihlaller için build failure düşünülebilir. Security rule'lar version control altında tutulmalıdır.

Encryption Drift Detection

Deployment sonrası manuel değişiklikler beklenen encryption policy'den sapma yaratabilir. Drift detection runtime ortamını deklaratif policy ile karşılaştırır. Encryption kapatılmış veya key değiştirilmiş resource hızlı tespit edilebilir. Değişikliğin change record ile eşleşip eşleşmediği kontrol edilmelidir. Kritik drift otomatik remediation ile düzeltilebilir.

Public Storage + Encryption Kontrolü

Encrypted bir bucket'ın public olması hâlâ ciddi veri sızıntısı oluşturabilir. Encryption ve exposure iki farklı kontrol alanıdır. Policy as code public access ile key configuration'ı birlikte incelemelidir. Hassas data tag'i bulunan storage için public policy tamamen engellenebilir. Güvenlik dashboard'u bu kombinasyonları tek risk olarak göstermelidir.

Kriptografik Algoritmalar CI/CD'de Nasıl Kontrol Edilir?

Crypto kullanımını yalnızca manuel code review'a bırakmak büyük codebase'lerde sürdürülebilir değildir. Static analysis ve dependency scanning bilinen riskli primitive'leri otomatik bulabilir. MD5, SHA-1, ECB ve hard-coded key gibi pattern'ler özel kurallarla tespit edilebilir. TLS configuration testleri deployment sonrası da çalıştırılmalıdır. Amaç geliştiriciyi yavaşlatmak değil hatayı production'a çıkmadan görünür kılmaktır.

MD5 Kullanımını Tespit Etmek

MD5 güvenlik açısından collision-resistant hash gerektiren yeni tasarımlarda kullanılmamalıdır. Static analysis code içinde MD5 API çağrılarını bulabilir. Her kullanım güvenlik amacı taşımayabilir ve bu nedenle context review gerekir. Legacy checksum ile digital signature kullanımı aynı risk seviyesinde değildir. Security rule kullanım amacını mümkün olduğunca ayırt etmelidir.

SHA-1 Kullanımını Tespit Etmek

SHA-1 modern collision resistance gerektiren güvenlik amaçları için uygun değildir. Code scanner ve dependency audit SHA-1 kullanımını bulabilir. Certificate veya legacy protocol bağımlılıkları ayrıca incelenmelidir. Migration planı kullanım yerine göre hazırlanmalıdır. Yeni code için secure alternative standardı açık biçimde tanımlanmalıdır.

ECB Kullanımını Tespit Etmek

ECB cipher mode source code içindeki algorithm string veya API parameter üzerinden tespit edilebilir. Scanner bu pattern'i yüksek öncelikli bulgu olarak işaretleyebilir. False positive olması durumunda güvenlik gerekçesi belgelenmelidir. Yeni application data encryption için authenticated mode tercih edilmelidir. Code review template cipher mode sorusunu açıkça içermelidir.

Hard-Coded Key Detection

Secret scanning yüksek entropy string ve bilinen key formatlarını repository içinde arar. Commit öncesi hook erken uyarı sağlayabilir. CI scanner merkezi koruma katmanı oluşturur. Tespit edilen gerçek key compromised kabul edilip rotate edilmelidir. Secret'ı sadece Git history'den gizlemek yeterli değildir.

Static Analysis

Static analysis source code'u çalıştırmadan güvenlik pattern'leri açısından inceler. Insecure crypto API kullanımı otomatik bulunabilir. Language-specific rule set doğruluğu artırır. Scanner sonucu developer'a düzeltme örneğiyle sunulmalıdır. Kritik bulgular security gate olarak kullanılabilir.

Dependency Scanning

Crypto library güvenliği kullanılan sürümün bilinen açıklarına da bağlıdır. Dependency scanning eski veya vulnerable paketleri tespit eder. Patch yayınlandığında hızlı upgrade süreci bulunmalıdır. Transitive dependencies de taramaya dahil edilmelidir. Library değiştirme kararında API stability ve security maintenance geçmişi değerlendirilmelidir.

TLS Configuration Testing

TLS testleri protocol version, cipher suite ve certificate validation durumunu kontrol edebilir. Deployment sonrası gerçek endpoint üzerinden test yapmak configuration drift'i yakalar. Eski TLS sürümü aktifse pipeline veya monitoring alarm üretebilir. Certificate expiration da aynı test kapsamına alınabilir. Internal database ve service endpoint'leri de taranmalıdır.

NIST Kriptografi Standartları

NIST yayınları cryptographic algorithm, key management ve module security konularında geniş bir referans seti sunar. SP 800-57 key lifecycle konusunda temel rehberlerden biridir. SP 800-131A algoritma ve key length geçiş planlarına odaklanır. FIPS 140-3 cryptographic module güvenlik gereksinimlerini tanımlar. Kurumlar bu belgeleri doğrudan kopyalamak yerine kendi risk, compliance ve sistem kapsamlarına uyarlamalıdır.

NIST SP 800-57

NIST SP 800-57 key management için kapsamlı rehber sunar. Key type, protection, lifecycle ve cryptoperiod gibi konuları ele alır. Kurumsal key management policy oluştururken güçlü referanstır. Encryption key ile signing key'in farklı gereksinimlerini anlamaya yardımcı olur. Güncel final ve taslak sürüm durumu yeni politika hazırlanırken ayrıca kontrol edilmelidir.

Key Management

NIST yaklaşımında key management yalnızca key storage değildir. Generation, distribution, use, backup, recovery ve destruction gibi süreçleri kapsar. Metadata ve access control da önemli güvenlik bileşenidir. Kurum key inventory olmadan bu yaşam döngüsünü sağlıklı yönetemez. Otomasyon human error riskini azaltabilir.

Cryptoperiod

Cryptoperiod bir key'in yetkili kullanım süresini tanımlar. Süre key type, security strength ve kullanım bağlamına göre değişebilir. Tek yıllık rotation gibi sabit şirket kuralı her key için doğru olmayabilir. Key exposure ve şifrelenen veri hacmi değerlendirilmelidir. Policy kararın gerekçesini açık biçimde belgelemelidir.

Key Protection

Key protection key materyalinin confidentiality ve integrity özelliklerini korumayı amaçlar. Master key'in plaintext export edilmesi mümkün olduğunca sınırlandırılmalıdır. KMS ve HSM güvenli storage sağlar. Backup key'leri de production key kadar korunmalıdır. Key metadata ve access policy yetkisiz değişikliklerden korunmalıdır.

NIST SP 800-131A

NIST SP 800-131A cryptographic algorithm ve key length geçişlerine odaklanır. Amaç zayıflayan yöntemlerden daha güçlü seçeneklere planlı geçiş sağlamaktır. Legacy sistem envanteri bu geçiş için temel gereksinimdir. Hard-coded algorithm kullanımı migration maliyetini artırır. Crypto agility bu nedenle uzun vadeli mimari hedef olmalıdır.

Algorithm Transition

Algorithm transition eski primitive'in kullanım dışına alınmasını planlı biçimde gerçekleştirir. Mevcut ciphertext veya signature verisi bir gecede değiştirilemeyebilir. Read-old ve write-new modeli geçiş sürecinde kullanılabilir. Versioned metadata hangi algoritmanın kullanıldığını belirler. Migration tamamlandığında legacy primitive kod ve config'ten kaldırılmalıdır.

FIPS 140-3

FIPS 140-3 cryptographic module güvenlik gereksinimlerine odaklanan standarttır. Bir algoritmanın güçlü olması ile kullanılan module'un FIPS validation sahibi olması farklı konulardır. Belirli regulated sistemler doğrulanmış module kullanımını şart koşabilir. Uygulamanın FIPS mode açması tek başına bütün güvenlik gereksinimlerini karşılamaz. Key management, IAM ve application security kontrolleri yine gereklidir.

FIPS 140-3 Nedir?

FIPS 140-3 cryptographic module'ların tasarım ve güvenlik gereksinimlerini tanımlayan standarddır. Fiziksel güvenlik, interfaces, authentication, sensitive security parameters ve self-test gibi farklı alanları kapsar. Bir uygulamanın AES kullanması otomatik olarak FIPS 140-3 validated olduğu anlamına gelmez. Validation belirli module ve configuration kapsamına bağlıdır. Regulated projelerde tam ürün ve certificate kapsamı kontrol edilmelidir.

Cryptographic Module Validation

Module validation belirli cryptographic implementation'ın tanımlı test ve gereksinimlerden geçtiğini gösterir. Bu değerlendirme algoritma adıyla sınırlı değildir. Kullanılan module version ve deployment mode önemlidir. Uygulama farklı library sürümüne geçerse validation kapsamı değişebilir. Compliance ekibi teknik ekip ile birlikte gerçek runtime module'u doğrulamalıdır.

Algoritma ile Module Validation Arasındaki Fark

AES standard bir algoritmadır. FIPS validation ise belirli cryptographic module'un gereksinimlere uygunluğunu değerlendirir. Güçlü algoritmayı kendi yazdığınız library içinde kullanmanız validation anlamına gelmez. Aynı algoritma farklı module'larda farklı sertifika durumuna sahip olabilir. Bu ayrım procurement ve compliance kararlarında önemlidir.

Regulated Sistemlerde Kullanım

Bazı regulated ortamlar doğrulanmış cryptographic module kullanımını talep edebilir. Gereksinim sözleşme, sektör veya kamu standardına göre değişir. Proje başında compliance scope belirlenmelidir. Son aşamada library değiştirmek büyük teknik maliyet oluşturabilir. Architecture decision record içinde validation gereksinimi açıkça tutulmalıdır.

FIPS Mode Kullanmak Tek Başına Güvenlik Sağlar mı?

Hayır, FIPS mode tek başına güvenli sistem oluşturmaz. Uygulama hâlâ hard-coded key kullanabilir veya yetki kontrolünde hata yapabilir. TLS certificate validation kapalı olabilir. Password storage yanlış tasarlanmış olabilir. FIPS yalnızca daha geniş security architecture içindeki belirli cryptographic requirement alanını kapsar.

OWASP Kriptografi Standartları ve Rehberleri

OWASP Cheat Sheet serisi geliştiriciler için uygulanabilir güvenlik önerileri sunar. Cryptographic Storage, Key Management, Password Storage ve TLS rehberleri hassas veri güvenliği tasarımında özellikle değerlidir. ASVS ise uygulama güvenlik gereksinimlerini doğrulanabilir kontroller hâline getirir. Mobil uygulamalar için ayrıca mobil güvenlik rehberleri bulunur. Ekipler OWASP rehberlerini secure coding standard ve code review checklist içine dahil edebilir.

Cryptographic Storage Cheat Sheet

Cryptographic Storage Cheat Sheet data at rest koruması için pratik rehber sağlar. Hassas veriyi mümkün olduğunca az saklamayı vurgular. Modern symmetric algorithm ve authenticated cipher mode kullanımını teşvik eder. Key ile data separation konusunu ayrıca ele alır. Kendi cryptographic algorithm'ınızı yazmamak temel mesajlardan biridir.

Key Management Cheat Sheet

Key Management rehberleri key generation, storage ve lifecycle konusunda geliştiricilere pratik yön verir. Anahtarların source code içinde tutulmaması önemli prensiptir. Key rotation ve access control en baştan tasarlanmalıdır. KMS ve HSM gibi merkezi çözümler operasyonu kolaylaştırır. Key inventory olmadan güvenli lifecycle yönetmek zordur.

Password Storage Cheat Sheet

Password Storage Cheat Sheet parolaların reversible encryption yerine uygun password hashing ile korunmasını önerir. Argon2id modern seçimlerden biridir. bcrypt, scrypt ve PBKDF2 belirli kullanım koşullarında değerlendirilebilir. Salt ve work factor parametreleri doğru uygulanmalıdır. Parola hashing değerleri donanıma göre benchmark edilmelidir.

TLS Cheat Sheet

TLS Cheat Sheet modern web uygulamalarında TLS 1.3 kullanımını öne çıkarır. Gerektiğinde TLS 1.2 uyumluluğuna izin verilebilir. Eski protokoller kapatılmalıdır. Strong cipher suite, HSTS ve certificate validation gibi konular birlikte ele alınır. Server configuration düzenli scanner ile doğrulanmalıdır.

ASVS

OWASP ASVS uygulama güvenliği gereksinimlerini doğrulama açısından yapılandırılmış bir çerçeve sağlar. Cryptography, authentication ve data protection kontrolleri mimari review'a dahil edilebilir. Gereksinimler test case'e dönüştürülebilir. Böylece güvenlik yalnızca genel tavsiye olarak kalmaz. Release sürecinde hangi kontrollerin geçtiği kayıt altına alınabilir.

Mobile Security Standards

Mobil güvenlik standardları cihaz üzerinde key ve sensitive data storage konularına özel önem verir. Platform secure storage API'lerinin kullanılması gerekir. Reverse engineering ve compromised device riskleri web uygulamalarından farklıdır. Network certificate validation mobil tarafta da kritik öneme sahiptir. Mobile security testleri local storage ve backup davranışını özellikle kontrol etmelidir.

PCI DSS Perspektifinde Hassas Veri Depolama

PCI DSS ödeme kartı verilerinin korunmasına ilişkin özel güvenlik gereksinimleri tanımlar. Gereksiz account data saklamamak temel yaklaşımlardan biridir. Saklanan hassas bilgiler güçlü cryptography ve kontrollü key management süreçleriyle korunmalıdır. Key lifecycle, split knowledge ve erişim kısıtlamaları ödeme ortamlarında özellikle önemlidir. PCI scope'u doğru küçültmek teknik ve operasyonel maliyeti de azaltabilir.

Stored Account Data

Stored account data yalnızca database tablosunda bulunan veriden ibaret değildir. Log, backup, export ve temporary file içinde de account data bulunabilir. Data discovery süreçleri gerçek kapsamı belirlemelidir. Gereksiz kopyalar kaldırılmalıdır. Storage location inventory düzenli güncellenmelidir.

Veri Saklamayı Minimumda Tutmak

Ödeme verisini hiç saklamamak çoğu zaman en güçlü risk azaltma yöntemidir. Business gereksinimi olmayan kart verisi tutulmamalıdır. Tokenization scope küçültmeye yardımcı olabilir. Retention süresi açık biçimde belirlenmelidir. Süresi dolan verinin silindiği doğrulanmalıdır.

Strong Cryptography

Strong cryptography güncel kabul gören algoritma ve key strength kullanılmasını gerektirir. Legacy cipher'lar migration planına alınmalıdır. Encryption mode ve key management de algoritma kadar önemlidir. Cryptographic inventory bu geçişleri görünür kılar. Standart gereksinimleri kullanılan PCI DSS sürümü üzerinden doğrulanmalıdır.

Key Storage

Cardholder data encryption key'leri plaintext olarak sıradan storage üzerinde tutulmamalıdır. KEK ile wrap veya HSM/KMS koruması uygulanabilir. Key access yalnızca gerekli custodians veya workloads ile sınırlandırılmalıdır. Backup key'ler ayrıca korunmalıdır. Key storage location inventory içinde açıkça belirtilmelidir.

Key Separation

Key ile encrypted account data aynı güvenlik alanında korunmamalıdır. Key separation database dump'ın tek başına plaintext üretmesini engellemeye yardımcı olur. HSM veya KMS ayrı trust boundary sağlar. Role separation insider riskini azaltır. Key access audit logları düzenli incelenmelidir.

HSM

HSM ödeme ortamlarında yüksek değerli cryptographic key'lerin korunması için kullanılabilir. Key materyalinin donanım sınırı dışında plaintext bulunmasını azaltır. Dual control ve split knowledge süreçleriyle birlikte kullanılabilir. Cihaz availability ve backup planı ihmal edilmemelidir. Certification gereksinimi projenin compliance kapsamına göre doğrulanmalıdır.

Dual Control ve Split Knowledge

Dual control kritik key operations için birden fazla kişinin katılımını sağlayabilir. Split knowledge tek kişinin key'in tamamını bilmesini önlemeyi amaçlar. Bu yöntemler özellikle manuel key component süreçlerinde önemlidir. Procedure yalnızca dokümanda kalmamalı ve düzenli tatbikatla doğrulanmalıdır. Emergency access aynı kontrol hedeflerini mümkün olduğunca korumalıdır.

TLS

Cardholder data ağ üzerinden taşınırken güçlü TLS kullanılmalıdır. Eski protokoller kapatılmalıdır. Certificate validation doğru yapılandırılmalıdır. Internal payment traffic de encryption kapsamına alınmalıdır. TLS configuration düzenli security scan ile kontrol edilmelidir.

KVKK Açısından Şifreleme ve Veri Depolama

KVKK kapsamında kişisel veri güvenliği yalnızca şifreleme algoritması seçmekten ibaret değildir. Veri sorumlularının uygun teknik ve idari tedbirleri birlikte değerlendirmesi gerekir. Veri minimizasyonu, erişim yetkileri, loglama, güvenli saklama ve silme süreçleri encryption ile birlikte çalışmalıdır. Kullanılan tedbirler işlenen verinin niteliği ve riskine göre belirlenmelidir. Kurumun güncel rehberleri ve ilgili kararları proje sırasında ayrıca incelenmelidir.

Kişisel Veri Güvenliği

Kişisel veri güvenliği confidentiality, integrity ve availability hedeflerini birlikte içerir. Yetkisiz erişimi önlemek kadar verinin kaybolmasını ve yanlış değiştirilmesini engellemek de önemlidir. Encryption gizlilik için güçlü araçtır. Access control ve backup güvenliği bu korumayı tamamlar. Risk assessment işlenen verinin türüne göre yapılmalıdır.

Teknik ve İdari Tedbirler

Teknik tedbirler encryption, access control, logging ve network security gibi mekanizmaları kapsayabilir. İdari tedbirler politika, eğitim, yetki süreci ve vendor yönetimi gibi alanları içerir. İki grup birbirinden bağımsız düşünülmemelidir. Güçlü teknoloji yanlış insan erişimiyle etkisiz kalabilir. Kurumsal güvenlik programı her iki alanı birlikte yönetmelidir.

Uluslararası Kabul Gören Encryption Yöntemleri

Hassas veri korumasında bilinen ve geniş güvenlik incelemesinden geçmiş cryptographic primitive'ler tercih edilmelidir. AES ve modern TLS bu kapsamda yaygın örneklerdir. Kendi algoritmasını geliştirmek gereksiz risk oluşturur. Kullanılan library aktif olarak güncellenmelidir. Algorithm seçimi yanında key management ve mode seçimi de belgelenmelidir.

Anahtar Yönetimi

KVKK uyumlu kişisel veri güvenliği tasarımında encryption key korunması temel teknik konudur. Key'e erişebilen kişi ve servisler sınırlandırılmalıdır. KMS veya HSM kullanılabilir. Rotation ve incident response prosedürleri belirlenmelidir. Key access logları gerektiğinde investigation için erişilebilir olmalıdır.

Cloud Storage

Cloud storage kullanımı sorumluluğu tamamen hizmet sağlayıcıya devretmez. Veri sorumlusu kendi erişim ve configuration kontrollerini yönetmelidir. Encryption by default, customer-managed key ve access policy risk seviyesine göre değerlendirilmelidir. Data residency ve uluslararası aktarım konuları ayrıca hukuki değerlendirme gerektirebilir. Public exposure kontrolleri sürekli izlenmelidir.

Erişim Yetkileri

Kişisel veriye yalnızca iş gereksinimi bulunan kişiler erişmelidir. Role değişikliklerinde eski permissions kaldırılmalıdır. Privileged access ayrı süreçle yönetilebilir. Decrypt yetkisi normal database read yetkisinden ayrılabilir. Düzenli access review gereksiz yetkileri tespit eder.

Logging

Logging güvenlik olaylarını araştırmak için gereklidir. Buna rağmen log içine gereksiz kişisel veri yazılması yeni risk oluşturur. PII redaction ve masking uygulanmalıdır. Log erişimi sınırlı ve audit edilebilir olmalıdır. Retention süresi kullanım amacına göre belirlenmelidir.

Retention ve Silme

Kişisel veri gerekli süre sona erdiğinde kontrolsüz biçimde tutulmamalıdır. Retention policy sistemlerde otomatik uygulanabilir. Silme süreci cache, backup ve replica etkisini değerlendirmelidir. Crypto-shredding belirli teknik senaryolarda yardımcı olabilir. Hukuki silme yükümlülüğünün nasıl yerine getirileceği ilgili uzmanlarla ayrıca doğrulanmalıdır.

KVKK İçin Encryption Tek Başına Yeterli midir?

Hayır, encryption kişisel veri güvenliğinin yalnızca bir katmanıdır. Anahtar erişimi sınırsızsa ciphertext'in sağlayacağı koruma zayıflar. MFA, access control, audit logging, data minimization ve backup security birlikte uygulanmalıdır. Vendor risk management cloud veya dış hizmet kullanımında ayrıca önemlidir. Güvenli tasarım bir algoritmaya değil birbirini destekleyen kontrol katmanlarına dayanmalıdır.

Encryption + Access Control

Encryption veriyi yetkisiz storage erişimine karşı korur. Access control ise kimin decryption veya uygulama erişimi yapabileceğini belirler. İki kontrol birlikte çalışmalıdır. Database hesabı ele geçirilirse application-level encryption ek sınır oluşturabilir. Key permission'ları database permission'larından ayrı yönetilmelidir.

MFA

MFA özellikle privileged kullanıcı hesaplarının ele geçirilmesini zorlaştırır. KMS administrator ve cloud console hesapları yüksek değerli hedeflerdir. Tek parola ile erişim risklidir. Phishing-resistant MFA seçenekleri mümkün olduğunda tercih edilebilir. Service account authentication ise insan MFA modelinden farklı olarak workload identity ile yönetilmelidir.

Audit Logging

Audit logging kritik veri ve key erişimlerini görünür hâle getirir. Olağan dışı decrypt veya export işlemleri araştırılabilir. Log bütünlüğü korunmalıdır. Central SIEM korelasyonu farklı sistemlerdeki olayları birleştirir. Alarm üretmeyen log sistemi tek başına yeterli detection sağlamayabilir.

Data Minimization

Toplanmayan veri çalınamaz. Bu basit prensip kişisel veri güvenliğinde çok güçlüdür. Gereksiz alanlar form ve database schema'dan kaldırılmalıdır. Analitik için gerçek kimlik yerine pseudonymous identifier kullanılabilir. Minimizasyon encryption ve compliance maliyetini de düşürür.

Retention

Veriyi gereğinden uzun süre saklamak saldırı yüzeyini büyütür. Retention iş amacı ve hukuki gereksinime bağlanmalıdır. Süresi biten kayıtlar otomatik silinebilir. Backup retention bu süreci karmaşıklaştırabileceği için baştan değerlendirilmelidir. Retention exception'ları kayıt altına alınmalıdır.

Backup Güvenliği

Backup kişisel verinin büyük bir kopyasını içerir. Encryption ve access control backup üzerinde de uygulanmalıdır. Restore key'leri güvenli şekilde saklanmalıdır. Backup export işlemleri audit edilmelidir. Düzenli recovery testi yapılmalıdır.

Vendor Risk Management

Dış hizmet kişisel veri işliyorsa vendor'ın güvenlik kontrolleri değerlendirilmelidir. Encryption, incident response ve subprocessor süreçleri sorgulanabilir. Sözleşme tek başına teknik güvenlik kanıtı değildir. Data flow hangi verinin hangi dış sisteme gittiğini göstermelidir. Vendor değişikliği durumunda veri silme ve key lifecycle planlanmalıdır.

Cryptographic Inventory Nedir?

Cryptographic inventory kurumda hangi algoritma, key, certificate ve library'nin nerede kullanıldığını gösteren kayıt sistemidir. Bu envanter olmadan legacy algorithm migration veya emergency response çok zorlaşır. Inventory yalnızca security ekibinin Excel dosyası olarak kalmamalıdır. CI/CD ve runtime scanning ile otomatik güncellenmesi daha güvenilir sonuç verir. Crypto agility programının başlangıç noktalarından biri budur.

Kullanılan Algoritmalar

Her sistemde kullanılan encryption, hashing, signing ve key agreement algoritmaları listelenmelidir. Kullanım amacı algoritma adından ayrı tutulmalıdır. SHA-256 password storage içinde yanlışken HMAC içinde uygun olabilir. Legacy primitive'ler açıkça işaretlenmelidir. Migration owner ve deadline kaydedilmelidir.

Kullanılan Key Sizes

Key size algoritmanın security strength değerlendirmesinde önemli metadata'dır. RSA ve AES aynı key size mantığıyla karşılaştırılamaz. Inventory algorithm ile key size bilgisini birlikte tutmalıdır. Policy altındaki değerler otomatik alarm üretebilir. Geçiş planları ilgili application owner ile ilişkilendirilmelidir.

Certificates

Certificate inventory expiration ve algorithm migration için gereklidir. Domain, service, issuer ve expiry bilgileri tutulabilir. Süresi yaklaşan certificate otomatik alarm üretmelidir. Private key location ayrıca kaydedilmelidir ancak secret materyalin kendisi inventory içine yazılmamalıdır. mTLS sistemlerinde workload certificate sayısı yüksek olduğu için automation gerekir.

Crypto Libraries

Hangi application'ın hangi crypto library version'ını kullandığı bilinmelidir. Vulnerability çıktığında etkilenen sistemler hızlı tespit edilebilir. Transitive dependencies de inventory kapsamına dahil edilmelidir. Kullanılmayan eski library'ler kaldırılmalıdır. Merkezi approved library listesi geliştiricilerin daha güvenli seçim yapmasını sağlar.

KMS/HSM

KMS ve HSM asset'leri key hierarchy'nin temel parçalarıdır. Hangi key'in hangi service veya HSM cluster'da bulunduğu kaydedilmelidir. Region ve account bilgileri recovery açısından önemlidir. Key administrator ve owner rolleri belirtilmelidir. Inventory secret değer değil metadata içermelidir.

Algoritmanın Kullanıldığı Sistem

Algoritma bilgisi tek başına yeterli değildir. Hangi application, endpoint veya data pipeline içinde kullanıldığı bilinmelidir. Legacy cipher migration sırasında bu eşleme gereklidir. Source code repository ve deployment artifact inventory ile ilişkilendirilebilir. Böylece remediation sahibi hızlı bulunur.

Veri Sınıfı

Crypto asset hangi veri sınıfını koruduğuyla eşleştirilmelidir. Restricted data için daha güçlü policy uygulanabilir. Internal data aynı key hierarchy'yi kullanmak zorunda değildir. Data classification değiştiğinde encryption requirement otomatik yeniden değerlendirilebilir. Inventory security risk prioritization için bu bilgiyi kullanabilir.

Key Owner

Her key için açık bir owner bulunmalıdır. Owner rotation, access review ve decommission kararından sorumlu olur. Sahipsiz key zamanla unutulan risk kaynağına dönüşebilir. Employee offboarding veya team reorganization sırasında ownership transfer edilmelidir. Owner bilgisi audit sırasında kolayca erişilebilir olmalıdır.

Crypto Agility Nedir?

Crypto agility bir sistemin algoritma veya key modelini büyük yeniden yazım gerektirmeden değiştirebilme kabiliyetidir. Cryptographic standartlar zamanla değişebilir ve bazı algoritmalar kullanım dışına alınabilir. Hard-coded algorithm ve ciphertext formatı migration'ı zorlaştırır. Versioned encryption metadata ve abstraction layer bu geçişleri kolaylaştırabilir. Post-quantum migration ihtiyacı crypto agility değerini daha da artırmaktadır.

Algoritmayı Uygulamadan Ayırmak

Business logic doğrudan belirli cipher API'sine bağlanırsa değişiklik maliyeti artar. Güvenli crypto service veya library abstraction kullanılabilir. Bu abstraction yanlış seçenekleri geliştiriciden gizlemelidir. Config üzerinden keyfi algorithm seçimine izin vermek de yeni risk oluşturabilir. Yalnızca approved primitive'ler desteklenmelidir.

Hard-Coded Algorithm Kullanımını Azaltmak

Algorithm name source code'un birçok yerine dağılmamalıdır. Merkezi crypto module seçimi migration'ı kolaylaştırır. Bununla birlikte insecure algorithm'ın config ile yeniden etkinleştirilmesi engellenmelidir. Version policy açık biçimde tanımlanmalıdır. Static analysis direct primitive kullanımını tespit edebilir.

Versioned Encryption Metadata

Ciphertext hangi algorithm ve key version ile üretildiğini belirten metadata taşıyabilir. Bu bilgi secret değildir ancak integrity korumasına dahil edilebilir. Decryption layer doğru version'ı seçebilir. Migration sırasında eski ve yeni ciphertext birlikte okunabilir. Metadata formatının gelecekte yeni algoritmalar eklemeye izin vermesi önemlidir.

Key ve Algorithm Migration

Key rotation ile algorithm migration aynı operasyon değildir ancak birlikte planlanabilir. Yeni write işlemleri yeni algorithm ve key ile başlatılabilir. Eski data background process ile aşamalı dönüştürülebilir. Migration progress ölçülmelidir. Son legacy record dönüştükten sonra eski code path kaldırılmalıdır.

Legacy Cipher Decommission

Legacy cipher kullanımının sıfıra indiği doğrulanmadan library desteği kaldırılmamalıdır. Inventory hangi system veya record'ların eski cipher kullandığını göstermelidir. Read-only support geçiş döneminde gerekli olabilir. Deadline ve owner belirlemek migration'ın sürüncemede kalmasını önler. Decommission sonrası policy eski cipher'ı tekrar kullanmayı engellemelidir.

Mass Re-Encryption Planı

Algorithm değişimi milyonlarca record için mass re-encryption gerektirebilir. İşlem CPU, IO ve KMS kapasitesini etkiler. Incremental batch yaklaşımı daha güvenli olabilir. Rollback ve retry mekanizması idempotent tasarlanmalıdır. Migration sırasında application iki ciphertext version'ını okuyabilmelidir.

Post-Quantum Cryptography Hassas Veri Depolamayı Nasıl Etkileyecek?

Kuantum bilgisayarlar özellikle belirli public-key algoritmaların uzun vadeli güvenliğini etkileyebilecek potansiyele sahiptir. NIST 2024 yılında ML-KEM, ML-DSA ve SLH-DSA standartlarını yayımladı. Bu gelişme kurumların cryptographic inventory ve migration planı oluşturmasını daha önemli hâle getiriyor. Symmetric encryption tamamen ortadan kalkmayacak ve AES güçlü rolünü sürdürecek. En doğru yaklaşım panik içinde algoritma değiştirmek yerine crypto agility ve uzun ömürlü veri riskini planlı biçimde değerlendirmektir.

Harvest Now, Decrypt Later Riski

Saldırgan bugün şifreli network trafiğini veya ciphertext'i toplayıp gelecekte daha güçlü hesaplama imkânıyla çözmeye çalışabilir. Bu risk özellikle yıllarca gizli kalması gereken veriler için önemlidir. Kısa ömürlü verinin risk profili farklı olabilir. Public-key exchange kullanılan uzun vadeli kanallar bu açıdan değerlendirilmelidir. PQC readiness assessment veri gizlilik süresini envantere eklemelidir.

ML-KEM

ML-KEM NIST tarafından standardize edilen post-quantum key encapsulation mechanism'dır. İki tarafın public channel üzerinden shared secret oluşturmasına yardımcı olur. Daha sonra bu secret symmetric encryption içinde kullanılabilir. ML-KEM doğrudan büyük dosyaları şifrelemek için AES'in yerine geçen algoritma olarak düşünülmemelidir. Entegrasyon desteği ve standard library availability zaman içinde izlenmelidir.

ML-DSA

ML-DSA post-quantum digital signature standardlarından biridir. Digital signature encryption ile aynı işlevi görmez. Amaç authenticity, integrity ve signature doğrulamasıdır. Certificate ve code signing ekosistemleri zaman içinde PQC geçişinden etkilenebilir. Crypto inventory signing algorithm'larını da içermelidir.

SLH-DSA

SLH-DSA hash tabanlı stateless digital signature yaklaşımıdır. NIST tarafından post-quantum signature standardı olarak yayımlanmıştır. ML-DSA'dan farklı performans ve signature size özelliklerine sahiptir. Her application aynı PQC algoritmasını kullanmak zorunda değildir. Use case ve standard guidance üzerinden seçim yapılmalıdır.

Symmetric Encryption'ın Rolü

Post-quantum geçiş symmetric encryption kullanımını ortadan kaldırmaz. AES data at rest ve bulk encryption için temel araç olmaya devam eder. Kuantum tehdidi symmetric key security strength üzerinde public-key sistemlerinden farklı etki gösterir. Uzun vadeli data için key size seçimi yeniden değerlendirilebilir. Anahtar yönetimi ise gelecekte de temel güvenlik gereksinimi olacaktır.

AES-256 ve PQC

AES-256 uzun vadeli yüksek security margin isteyen sistemlerde güçlü symmetric seçenek olarak değerlendirilebilir. PQC kavramı AES'in doğrudan yerine geçen bir teknoloji değildir. ML-KEM gibi algoritmalar key establishment tarafında rol oynar. AES ise bulk data encryption görevini sürdürebilir. Mimari bu farklı rolleri birbirine karıştırmamalıdır.

Hybrid Migration

Hybrid migration klasik ve post-quantum mekanizmaların geçiş döneminde birlikte kullanılmasını ifade edebilir. Amaç yeni algoritmaya güven kazanılırken mevcut interoperability özelliklerini korumaktır. Protocol ve library desteği dikkatle izlenmelidir. Kendi hybrid protocol tasarımınızı yazmak yerine standard implementation kullanılmalıdır. Migration aşamaları test ve telemetry ile takip edilmelidir.

PQC Readiness Assessment

PQC readiness assessment kurumun public-key crypto kullanımını envanterle başlatır. Certificate, VPN, TLS, signing ve key agreement noktaları belirlenir. Verinin ne kadar süre gizli kalması gerektiği kaydedilir. Library ve vendor roadmap bilgileri izlenir. Böylece yüksek öncelikli migration alanları risk bazlı sıralanabilir.

AI ve RAG Sistemlerinde Hassas Veri Depolama

AI ve RAG sistemleri yeni veri kopyaları oluşturabildiği için mevcut security policy kapsamına açık biçimde alınmalıdır. Prompt logs, conversation history, vector embeddings ve knowledge base içinde kişisel veya ticari veri bulunabilir. API credential ve model provider'a gönderilen payload ayrıca değerlendirilmelidir. Tenant isolation yalnızca application database'de değil vector database ve cache katmanında da uygulanmalıdır. Encryption, retention ve access control bu sistemlerde başlangıç mimarisinin parçası olmalıdır.

Prompt Logs

Prompt logları kullanıcıların hassas veri yazabileceği serbest metin alanlarıdır. Varsayılan olarak bütün promptları uzun süre saklamak risklidir. PII detection ve redaction mekanizmaları değerlendirilebilir. Debug ve observability ihtiyacı data minimization ile dengelenmelidir. Kullanıcıya hangi verinin kaydedildiği açık biçimde yönetilmelidir.

Conversation History

Conversation history kişisel tercihler, iş belgeleri veya gizli bilgiler içerebilir. Tenant ve user bazlı access control uygulanmalıdır. At-rest encryption ve retention policy birlikte kullanılmalıdır. Kullanıcı silme talebi varsa bağlı index ve cache kopyalarının etkisi değerlendirilmelidir. Export fonksiyonları güçlü authorization gerektirmelidir.

Vector Embeddings

Embedding ham metnin birebir kopyası değildir ancak tamamen risksiz kabul edilmemelidir. Kaynak verinin hassasiyeti embedding storage policy'sini etkiler. Vector database erişimi tenant bazında sınırlandırılmalıdır. Metadata alanlarında plaintext PII bulunup bulunmadığı kontrol edilmelidir. Backup ve index replication encryption kapsamına dahil edilmelidir.

RAG Knowledge Base

RAG knowledge base kurumsal dokümanların işlenmiş kopyalarını barındırabilir. Document-level ACL retrieval aşamasında korunmalıdır. Kullanıcının erişemediği belge model context'ine girmemelidir. Source storage ve vector index aynı access modelini takip etmelidir. Ingestion pipeline secret ve PII logging açısından test edilmelidir.

Model Training Data

Training data hassas bilgi içerebilir ve model lifecycle boyunca uzun süre saklanabilir. Veri kullanım amacı ve retention açık biçimde tanımlanmalıdır. PII minimization ve anonymization değerlendirilebilir. Training snapshot ve experiment artifact'ları ayrı storage kopyaları oluşturur. Access control yalnızca production database üzerinde uygulanmamalıdır.

API Credentials

Model provider API credentials source code veya notebook içine yazılmamalıdır. Secret manager ve workload identity benzeri yöntemler kullanılmalıdır. Notebook output veya experiment log secret içerebilir. Credential scope ve rate limit dar tutulmalıdır. Sızıntı şüphesinde hızlı rotation yapılmalıdır.

Tenant-Specific Encryption

Multi-tenant AI platformunda her müşterinin conversation ve knowledge base verisi ayrı cryptographic scope'a alınabilir. Tenant-specific DEK blast radius değerini azaltır. Vector database ve object storage aynı tenant key hierarchy'siyle ilişkilendirilebilir. Tenant offboarding key destruction sürecini kolaylaştırabilir. Key count automation ile yönetilmelidir.

Model Provider'a Gönderilen Veriler

Dış model hizmetine gönderilen prompt ve document chunk'ları veri boundary dışına çıkabilir. Gönderilmeden önce gerçekten gerekli alanlar seçilmelidir. Secret ve gereksiz PII redaction uygulanabilir. Vendor retention ve training policy teknik ve hukuki açıdan değerlendirilmelidir. Hassas veri için provider seçimi data classification policy ile bağlanmalıdır.

Encryption ile Secret Management Arasındaki Fark

Encryption genel veriyi gizlilik amacıyla korumaya odaklanırken secret management uygulamanın kullandığı credential ve key gibi yüksek değerli secret'ların yaşam döngüsünü yönetir. API secret, database password ve certificate private key sıradan encrypted field gibi ele alınmamalıdır. Secret manager erişim, versioning ve rotation özellikleri sunabilir. KMS ise cryptographic key ve operations üzerinde yoğunlaşır. Doğru araç seçimi secret türünü anlamakla başlar.

Encryption Key

Encryption key ciphertext oluşturmak ve çözmek için kullanılan cryptographic material'dır. Secret olarak korunmalıdır. Master key KMS veya HSM içinde tutulabilir. Uygulamanın raw key'i doğrudan alması her zaman gerekli değildir. Key usage policy cryptographic operation bazında sınırlandırılabilir.

API Secret

API secret servis kimliğini doğrulamak veya request signing yapmak için kullanılabilir. Source code içinde tutulmamalıdır. Secret manager'da versioned biçimde saklanabilir. Rotation sırasında eski ve yeni secret kısa süre birlikte desteklenebilir. Kullanılmayan secret'lar revoke edilmelidir.

Password

Kullanıcı parolası secret'tır ancak uygulama tarafından geri okunabilir biçimde saklanmamalıdır. Password hashing tercih edilmelidir. Database service password gibi machine credential ise secret manager içinde tutulabilir. İki password türünün storage ihtiyacı farklıdır. Aynı kelime kullanıldığı için aynı teknik çözüm uygulanmamalıdır.

Certificate Private Key

Certificate private key TLS veya signing sisteminin kritik secret'ıdır. File permission tek koruma yöntemi olmamalıdır. HSM, secure key store veya controlled secret system kullanılabilir. Private key export gerekiyorsa süreç sıkı biçimde sınırlandırılmalıdır. Certificate rotation private key lifecycle ile birlikte yönetilmelidir.

KMS

KMS cryptographic key lifecycle ve controlled operations için tasarlanmıştır. Data encryption key wrap ve unwrap işlemlerini yapabilir. IAM ve audit özellikleri key erişimini görünür kılar. Generic API password saklamak için her zaman en uygun araç olmayabilir. Secret manager ile görev ayrımı yapılmalıdır.

Secret Manager

Secret manager password, API token ve benzeri application secret'larını merkezi olarak saklar. Versioning ve controlled retrieval sunabilir. Workload identity ile erişim statik bootstrap credential ihtiyacını azaltır. Rotation automation mümkün olduğunda kullanılmalıdır. Secret access logları anormal kullanım açısından izlenmelidir.

Vault

Vault kavramı merkezi secret ve credential management yaklaşımını ifade etmek için sık kullanılır. Dynamic credential üretimi uzun ömürlü secret kullanımını azaltabilir. Policy ile hangi workload'un hangi secret'a erişebileceği sınırlandırılır. High availability ve disaster recovery kritik öneme sahiptir. Vault erişilemez olduğunda uygulamanın davranışı önceden test edilmelidir.

Hangi Veri Nerede Saklanmalı?

User password password hashing ile database'de hash olarak tutulmalıdır. API secret secret manager'da saklanabilir. Encryption master key KMS veya HSM içinde korunmalıdır. Certificate private key kullanım senaryosuna göre secure key store veya HSM'de bulunabilir. Sıradan application data ise uygun encryption layer ile storage üzerinde korunmalıdır.

Open Source Cryptography Ekosistemi

Güvenli kriptografi geliştirmek için yıllardır incelenen open source library'lerden yararlanmak önemli avantaj sağlar. OpenSSL, libsodium, Google Tink ve language-native crypto API'leri farklı kullanım alanlarına sahiptir. Seçimde yalnızca popülerlik değil API güvenliği, bakım durumu ve platform uyumluluğu değerlendirilmelidir. Hazır high-level primitive kullanmak geliştiricinin nonce veya tag gibi ayrıntılarda hata yapma riskini azaltır. Kendi encryption algorithm'ınızı yazmak yerine incelenmiş implementation kullanmak güvenliğin temel prensiplerindendir.

OpenSSL

OpenSSL TLS ve genel cryptographic operations için yaygın kullanılan kütüphanelerden biridir. Geniş algorithm desteği sunması güçlü olduğu kadar yanlış API seçimi riskini de artırabilir. High-level EVP API'leri düşük seviyeli primitive kullanımına göre tercih edilebilir. Library güncellemeleri güvenlik patch'leri açısından takip edilmelidir. Sistem package version ile application runtime version arasındaki fark bilinmelidir.

libsodium

libsodium geliştiricilere daha güvenli high-level cryptographic API sunmayı hedefler. Safe default yaklaşımı yanlış primitive kombinasyonlarını azaltabilir. Secretbox ve password hashing gibi hazır fonksiyonlar yaygın kullanım senaryolarını kapsar. Library'nin resmi dokümantasyonu izlenmelidir. Platform binding'lerinin bakım durumu ayrıca kontrol edilmelidir.

Google Tink

Google Tink yüksek seviyeli cryptographic primitive API'leri sunar. Keyset ve primitive abstraction crypto agility açısından faydalı olabilir. Geliştiricinin doğrudan nonce yönetmesi gereken senaryoları azaltmayı hedefler. Kullandığınız dil ve platformdaki destek durumu kontrol edilmelidir. Güvenli default'ları değiştirmeden önce açık gerekçe bulunmalıdır.

BoringSSL

BoringSSL belirli büyük ölçekli ürünlerin ihtiyaçları için geliştirilen OpenSSL türevi bir crypto library'dir. Genel amaçlı üçüncü taraf uygulamalar için API stability hedefleri farklı olabilir. Bu nedenle dependency seçimi yalnızca feature listesine göre yapılmamalıdır. Projenin maintenance modeline uygun library tercih edilmelidir. Uzun vadeli upgrade maliyeti göz önünde bulundurulmalıdır.

Language-Native Crypto Libraries

Java, .NET, Python, Go ve Rust gibi platformların güçlü native veya standard crypto API'leri bulunur. Native library kullanmak dependency sayısını azaltabilir. Buna rağmen düşük seviyeli API yanlış kullanıma açık olabilir. Framework'ün recommended high-level primitive'leri tercih edilmelidir. Runtime version ve security patch durumu düzenli güncellenmelidir.

Hazır Primitive Kullanmak Neden Önemlidir?

Cryptographic primitive'in doğru implementation'ı çok sayıda ayrıntıya bağlıdır. Nonce, padding, tag validation ve constant-time comparison gibi konularda küçük hata ciddi güvenlik açığı oluşturabilir. High-level library bu ayrıntıları güvenli default ile yönetebilir. Geliştirici business logic'e odaklanabilir. Güvenlik review scope'u da daha küçük olur.

Kendi Crypto Algoritmanı Yazmamak

Kriptografi teorisi ve implementation güvenliği uzmanlık gerektirir. Yeni algoritma yıllarca public review görmeden bilinmeyen zayıflıklar taşıyabilir. Güvenlik için gizli algoritmaya güvenmek uygun yaklaşım değildir. Standard ve geniş incelemeden geçmiş primitive'ler kullanılmalıdır. Yenilik ihtiyacı varsa akademik ve endüstri review süreci izlenmelidir.

Şifreleme İçin Hangi Programlama Dili Kullanılmalıdır?

Güvenli encryption için tek doğru programlama dili yoktur. Java, C#, Python, Go, Rust ve JavaScript gibi dillerin olgun crypto library seçenekleri bulunur. Asıl önemli konu güvenilir library, safe API ve doğru key management kullanmaktır. Memory safety bazı riskleri azaltabilir ancak yanlış nonce yönetimini çözmez. Ekip bildiği dilde güvenli ve bakımı yapılabilir implementation üretmeyi hedeflemelidir.

Java

Java platformu JCA ve JCE üzerinden geniş cryptographic özellikler sağlar. Algorithm string ve provider seçimi yanlış yapılandırmaya açık olabilir. Modern AEAD API'leri tercih edilmelidir. KeyStore veya external KMS entegrasyonu kullanılabilir. JVM ve crypto provider güncellemeleri düzenli takip edilmelidir.

C# / .NET

.NET modern cryptographic API'ler sunar. AES-GCM gibi authenticated primitive'ler güncel runtime sürümlerinde kullanılabilir. Platform data protection API'leri belirli application secret senaryolarında faydalıdır. Secret key source code içine yazılmamalıdır. Runtime security patch'leri deployment policy'nin parçası olmalıdır.

Python

Python standard library'nin yanında güvenilir cryptography paketleri kullanılır. Düşük seviyeli primitive yerine yüksek seviyeli recipe API'leri tercih edilmelidir. Dependency version güvenlik scanner ile izlenebilir. Python process memory'sinde plaintext key süresi mümkün olduğunca kısa tutulmalıdır. Notebook ve debug output secret sızıntısı açısından dikkatle yönetilmelidir.

Go

Go standard library güçlü crypto package'leri içerir. AEAD interface modern encryption tasarımlarını destekler. Error handling sırasında plaintext veya key loglanmamalıdır. Binary içine hard-coded secret gömmekten kaçınılmalıdır. Go module dependencies düzenli olarak taranmalıdır.

Rust

Rust memory safety özellikleriyle bazı implementation hatalarını azaltabilir. Buna rağmen cryptographic protocol tasarımı için yine uzmanlık gerekir. Olgun crate'ler ve güvenli API'ler tercih edilmelidir. Unsafe code kullanılan cryptographic dependency'ler ayrıca incelenebilir. Key zeroization ihtiyacı için uygun crate ve pattern kullanılmalıdır.

JavaScript / TypeScript

JavaScript ve TypeScript server veya browser tarafında farklı crypto API'lere sahiptir. Browser Web Crypto API kullanılabilir. Client-side code içindeki secret'ın kullanıcı tarafından görülebileceği unutulmamalıdır. Backend master key frontend bundle içine hiçbir koşulda eklenmemelidir. Node.js runtime ve dependency security düzenli güncellenmelidir.

Programlama Dilinden Çok Crypto Library Seçiminin Önemi

Aynı dil içinde güvenli ve riskli cryptographic API'ler bulunabilir. Safe high-level library yanlış kullanım ihtimalini azaltır. Aktif maintenance ve security response geçmişi önemli seçim kriteridir. Standard primitive ve interoperability desteği de değerlendirilmelidir. Ekip için ortak approved crypto library belirlemek code review sürecini kolaylaştırır.

Open Source ve İşbirliğinin Güvenli Kriptografideki Rolü

Cryptographic sistemler geniş inceleme ve bağımsız testten önemli ölçüde fayda görür. Open source code araştırmacıların implementation davranışını incelemesine imkân verebilir. Bu durum kodun otomatik olarak güvenli olduğu anlamına gelmez. Aktif maintenance, vulnerability disclosure ve community test suite'leri kaliteyi yükseltir. Üniversite ve sektör arasındaki işbirliği yeni algoritma ve saldırı yöntemlerinin daha hızlı değerlendirilmesini sağlar.

Peer Review

Peer review cryptographic tasarımın bağımsız uzmanlar tarafından değerlendirilmesini sağlar. Tasarım sahibinin fark etmediği assumption hataları ortaya çıkabilir. Security proof ile implementation davranışı ayrı ayrı incelenmelidir. Review tek seferlik faaliyet olmamalıdır. Büyük değişikliklerde yeniden değerlendirme gerekir.

Açık Kaynak Crypto Libraries

Açık kaynak crypto library'leri geniş kullanıcı topluluğu tarafından incelenebilir. Popüler olmak güvenlik garantisi değildir. Release süreçleri, test kapsamı ve security response geçmişi değerlendirilmelidir. Dependency pinning ve update policy kullanılmalıdır. Kurum kritik library'ler için software bill of materials tutabilir.

Güvenlik Araştırmacıları

Güvenlik araştırmacıları cryptographic implementation ve protocol hatalarını bağımsız olarak inceleyebilir. Responsible disclosure süreci sorunların kontrollü biçimde bildirilmesine yardımcı olur. Vendor'ın hızlı patch yayınlama kapasitesi library seçiminde önemlidir. Araştırmacı raporları yalnızca CVE çıktığında değil mimari review sırasında da takip edilmelidir. Öğrenilen dersler internal secure coding standardına eklenebilir.

Vulnerability Disclosure

Vulnerability disclosure güvenlik açığı bildirimini yapılandırılmış sürece dönüştürür. Projede açık security contact ve policy bulunmalıdır. Araştırmacıya nasıl rapor göndereceği anlatılmalıdır. Kritik cryptographic bug için hızlı triage mekanizması gerekir. Patch hazır olduğunda downstream kullanıcıların bilgilendirilmesi planlanmalıdır.

Community Test Suites

Community test suite bilinen edge case ve attack vector'ları otomatik kontrol edebilir. Cryptographic implementation regression riskini azaltır. Known-answer test'leri algorithm correctness için faydalıdır. Negative test'ler invalid tag veya malformed ciphertext davranışını doğrulamalıdır. CI pipeline bu testleri her release'de çalıştırmalıdır.

Üniversite Sektör İşbirliği

Üniversiteler cryptography research ve yeni saldırı teknikleri konusunda önemli bilgi üretir. Sektör ise gerçek sistem ve performans problemlerini araştırmaya taşır. Ortak workshop ve open source proje iki taraf için öğrenme alanı oluşturabilir. Öğrenciler güvenlik standardlarını gerçek uygulamalar üzerinde test edebilir. Yerel topluluklar bu işbirliğinin erişilebilir başlangıç noktası olabilir.

Diyarbakır Yazılım Topluluğu İçin Kriptografi Proje Fikirleri

Kriptografiyi öğrenmenin en etkili yollarından biri küçük fakat gerçek çalışma mantığına sahip projeler üretmektir. Diyarbakır Yazılım Topluluğu içinde secure storage, password hashing ve key rotation üzerine uygulamalı çalışmalar geliştirilebilir. Projeler yalnızca algoritma kullanımını değil threat modeling ve benchmark pratiğini de öğretmelidir. Topluluğun mevcut proje yaklaşımını görmek için https://www.diyarbakiryazilim.com.tr/projects sayfası incelenebilir. Ortak repository ve code review modeli katılımcıların birbirinin güvenlik kararlarını değerlendirmesine yardımcı olur.

Secure Storage Workshop'u

Workshop küçük bir uygulamadaki hassas veri akışını çıkararak başlayabilir. Katılımcılar önce plaintext storage riskini gözlemler. Ardından AES-GCM ve KMS benzeri key separation modeli uygulanabilir. Nonce, ciphertext metadata ve error handling birlikte test edilir. Son aşamada ekipler threat model sonuçlarını karşılaştırabilir.

OWASP Cryptography Laboratuvarı

Laboratuvar OWASP Cryptographic Storage rehberindeki hataları uygulamalı gösterebilir. Base64, ECB ve hard-coded key gibi yanlış örnekler hazırlanabilir. Katılımcılar her problemi tespit edip güvenli alternatif uygular. Static analysis rule eklemek çalışmayı CI/CD güvenliğine bağlar. Böyle bir eğitim teori ile kod arasındaki ilişkiyi güçlendirir.

Envelope Encryption Demo Projesi

Demo uygulaması random DEK üreterek küçük bir dosyayı AES-GCM ile encrypt edebilir. DEK ayrı KEK altında wrap edilir. Ciphertext yanında yalnızca wrapped key ve metadata tutulur. KEK rotation sırasında re-wrapping gösterilebilir. Bu proje KMS mantığını anlamak için oldukça öğreticidir.

Argon2 Password Storage Benchmark

Katılımcılar farklı Argon2id memory ve iteration parametrelerini kendi donanımlarında test edebilir. P50 ve p95 login latency ölçülebilir. Parallel request altında memory consumption izlenebilir. Sonuçlar farklı cihazlar arasında karşılaştırılabilir. Böylece password hashing parametresinin neden tek sabit sayı olmadığını uygulamalı görmek mümkün olur.

TLS Configuration Scanner

Basit scanner belirli test endpoint'inin TLS version ve certificate bilgisini kontrol edebilir. Eski protocol desteği bulursa warning üretebilir. Certificate expiration süresini raporlayabilir. Proje daha sonra CI/CD integration eklenerek genişletilebilir. Sadece izin verilen test sistemlerinde kullanılmalıdır.

Open Source Key Rotation Demo

Demo uygulaması iki key version ile zero-downtime rotation davranışını gösterebilir. Yeni kayıtlar version 2 ile encrypt edilirken eski kayıtlar version 1 ile okunmaya devam eder. Background migration eski ciphertext'i dönüştürür. Progress dashboard migration oranını gösterir. Son aşamada eski key disable edilerek recovery senaryosu test edilir.

Yazılımcılar Güvenli Veri Depolama Alanında Nasıl Uzmanlaşabilir?

Güvenli veri depolama öğrenmek yalnızca kriptografi matematiği çalışmakla sınırlı değildir. TLS, database security, password hashing, cloud KMS ve incident response konularını birlikte anlamak gerekir. En iyi öğrenme yolu küçük güvenlik projeleri ve code review çalışmalarıdır. OWASP ve NIST gibi kaynaklar düzenli okunmalıdır. Açık kaynak güvenlik projelerine katkı yapmak gerçek implementation davranışını görme fırsatı sağlar.

Temel Cryptography

Başlangıçta symmetric ve asymmetric encryption farkı anlaşılmalıdır. Hash, HMAC, digital signature ve key derivation kavramları birbirinden ayrılmalıdır. AES-GCM gibi modern primitive'lerin hangi problemi çözdüğü öğrenilmelidir. Matematik temeli faydalıdır ancak güvenli library kullanma pratiği de aynı derecede önemlidir. Kendi algorithm'ını üretmek yerine standard primitive'ler üzerinde çalışılmalıdır.

TLS

TLS handshake, certificate ve trust chain kavramları öğrenilmelidir. Browser HTTPS ile database TLS arasındaki ortak prensipler görülmelidir. TLS 1.3 server configuration uygulamalı test edilebilir. Certificate validation kapatıldığında oluşan risk laboratuvar ortamında incelenebilir. mTLS daha ileri aşamada service identity konusu ile birlikte çalışılabilir.

Password Hashing

Argon2id, bcrypt, scrypt ve PBKDF2 arasındaki farklar öğrenilmelidir. Salt ve pepper kavramları uygulamalı örneklerle pekiştirilmelidir. Parameter benchmark gerçek hardware üzerinde yapılmalıdır. Legacy hash migration küçük demo ile test edilebilir. Fast hash'in password storage için neden uygun olmadığı ölçümle görülebilir.

Database Security

TDE, column-level ve application-level encryption farkı öğrenilmelidir. SQL injection ile storage encryption'ın farklı tehditler olduğu anlaşılmalıdır. Least privilege database role tasarımı uygulanabilir. Query performance ve encryption birlikte benchmark edilmelidir. Backup ve replica güvenliği de database security kapsamına dahil edilmelidir.

Cloud KMS

Cloud KMS ile envelope encryption uygulaması yapmak key management kavramlarını somutlaştırır. IAM policy ile encrypt ve decrypt izinleri ayrılabilir. Audit log üzerinden key usage izlenebilir. Rotation ve disable operasyonları kontrollü demo ortamında test edilmelidir. Production key üzerinde eğitim deneyi yapılmamalıdır.

HSM

HSM key'in neden hardware boundary içinde tutulduğunu anlamak için önemlidir. Sign ve decrypt operation'larının key export etmeden nasıl çalıştığı incelenebilir. High availability ve backup konusu ayrıca öğrenilmelidir. FIPS module validation kavramıyla ilişki kurulabilir. Cloud HSM demo ortamı erişilebilir bir başlangıç sağlayabilir.

OWASP

OWASP Cheat Sheet serisi geliştiricilere doğrudan uygulama önerileri sunar. Cryptographic Storage ve Password Storage iyi başlangıç noktalarıdır. ASVS kontrol maddeleri test senaryosuna dönüştürülebilir. Güvenlik eğitimi yalnızca okumak yerine vulnerable demo uygulamasıyla desteklenmelidir. Her proje için küçük security checklist oluşturulabilir.

NIST

NIST dokümanları key management ve algorithm transition konularında daha ayrıntılı referans sağlar. SP 800-57 key lifecycle için temel kaynaktır. SP 800-131A algorithm migration düşüncesini geliştirir. FIPS 203, 204 ve 205 post-quantum geçiş için güncel standartları tanımlar. Dokümanlar proje gereksinimiyle eşleştirilerek okunmalıdır.

Açık Kaynak Güvenlik Projeleri

Open source projelerde code review yapmak gerçek cryptographic API kullanımını gösterir. Documentation ve test katkıları da değerlidir. Security issue çözmek için önce proje disclosure policy'si okunmalıdır. Küçük test veya scanner geliştirmek başlangıç için uygundur. Topluluk çalışmaları öğrenme sürecini daha sürdürülebilir kılar.

Örnek Bir Hassas Veri Şifreleme Mimarisi Nasıl Tasarlanır?

Güvenli mimari tek seferde algoritma seçilerek kurulmaz. Süreç data inventory ile başlar ve monitoring ile devam eder. Her adım önceki kararın üzerine eklenir. Özellikle data classification, threat modeling ve key hierarchy aşamaları sonraki teknik seçimi doğrudan etkiler. Aşağıdaki yaklaşım farklı kurumsal sistemlere uyarlanabilecek pratik bir iskelet sunar.

Adım 1: Sensitive Data Inventory

İlk adım hangi hassas verinin nerede bulunduğunu belirlemektir. Database, object storage, log, backup ve external API akışları listelenmelidir. Her asset için owner atanmalıdır. Veri akış diyagramı beklenmeyen kopyaları görünür kılar. Inventory otomatik discovery araçlarıyla desteklenebilir.

Adım 2: Data Classification

Bulunan veriler hassasiyet seviyesine göre sınıflandırılmalıdır. Public, Internal, Confidential ve Restricted gibi model kullanılabilir. Her sınıf için encryption ve access requirement tanımlanmalıdır. Classification yalnızca dokümantasyon etiketi olmamalıdır. Infrastructure policy bu etiketi teknik kontrole bağlamalıdır.

Adım 3: Data Minimization

Her hassas alan için gerçekten gerekli olup olmadığı sorulmalıdır. Gereksiz PII toplanmamalıdır. Saklama süresi mümkün olduğunca kısa belirlenmelidir. Tokenization ile gerçek değeri sistem dışında tutma fırsatı değerlendirilmelidir. Encryption kapsamı gereksiz veriyi saklama bahanesi olmamalıdır.

Adım 4: Threat Modeling

Hangi saldırgana karşı koruma gerektiği açık biçimde tanımlanmalıdır. Disk theft, compromised DBA, application exploit ve insider farklı tehditlerdir. Her tehdit farklı encryption layer gerektirebilir. Trust boundary ve data flow diyagramı kullanılmalıdır. Kontroller saldırı senaryolarıyla eşleştirilmelidir.

Adım 5: Encryption Layer Seçimi

Full disk, TDE, field-level ve application-level seçenekleri değerlendirilmelidir. Tek katman bütün tehditleri çözmez. Restricted data için birden fazla layer gerekebilir. Query ve operational requirement seçimi etkiler. Karar architecture decision record içine yazılmalıdır.

Adım 6: Algorithm ve Mode Seçimi

Modern ve kabul gören primitive kullanılmalıdır. Symmetric data encryption için AES-GCM veya uygun bağlamda ChaCha20-Poly1305 değerlendirilebilir. ECB gibi insecure mode'lardan kaçınılmalıdır. Nonce gereksinimi açık biçimde belgelenmelidir. Kendi crypto protocol tasarımı yapılmamalıdır.

Adım 7: KMS/HSM Seçimi

Master key'lerin nerede tutulacağı belirlenmelidir. Çoğu cloud uygulamada KMS güçlü başlangıç noktasıdır. Daha yüksek hardware control gereken sistemlerde HSM değerlendirilebilir. Availability ve disaster recovery gereksinimleri seçimi etkiler. Key access audit logging zorunlu özellik olarak değerlendirilmelidir.

Adım 8: DEK/KEK Hiyerarşisi

Envelope encryption için DEK ve KEK rolleri tanımlanmalıdır. DEK scope tenant veya data category bazında belirlenebilir. KEK KMS veya HSM içinde tutulabilir. Wrapped DEK ciphertext yanında saklanabilir. Metadata key version bilgisini taşımalıdır.

Adım 9: IAM ve Separation of Duties

Database, application ve key administrator rolleri ayrılmalıdır. Workload identity kullanarak static secret azaltılmalıdır. Encrypt ve decrypt permissions gerektiğinde farklı servislerde tutulmalıdır. Human production access kısa ömürlü ve audit edilmelidir. Critical key operation için dual approval uygulanabilir.

Adım 10: TLS

Bütün external ve internal hassas trafik TLS ile korunmalıdır. TLS 1.3 varsayılan tercih olabilir. Database ve message broker bağlantıları unutulmamalıdır. Certificate verification açık olmalıdır. Service identity gereken bölgelerde mTLS değerlendirilebilir.

Adım 11: Log/Cache/Backup Kontrolü

Hassas plaintext'in loglara düşüp düşmediği test edilmelidir. Cache TTL ve data content incelenmelidir. Backup encryption ve key availability doğrulanmalıdır. Temporary file ve crash dump politikası da değerlendirilmelidir. Veri güvenliği ana database sınırının ötesine taşınmalıdır.

Adım 12: Key Rotation

Her key type için cryptoperiod belirlenmelidir. Scheduled ve emergency rotation süreçleri ayrılmalıdır. Versioned ciphertext zero-downtime geçişi kolaylaştırabilir. KEK rotation için re-wrapping kullanılabilir. Rotation başarısı monitoring ile ölçülmelidir.

Adım 13: Key Recovery Testi

Recovery prosedürü yalnızca dokümanda bırakılmamalıdır. Test key ve backup üzerinden gerçek restore yapılmalıdır. KMS outage veya yanlış region senaryosu simüle edilebilir. Recovery yetkisi kontrollü olmalıdır. Test sonucu düzenli olarak raporlanmalıdır.

Adım 14: Security Testing

Static analysis insecure crypto kullanımını taramalıdır. Secret scanning repository ve CI pipeline içinde çalışmalıdır. TLS configuration test edilmelidir. Negative test invalid tag ve wrong key davranışını kontrol etmelidir. Penetration testing application-level erişim kontrollerini ayrıca incelemelidir.

Adım 15: Monitoring ve Audit

Encryption deployment sonrası da izlenmelidir. Decrypt volume, key age ve rotation compliance ölçülmelidir. SIEM unexpected identity ve region kullanımını alarm olarak ele alabilir. Cryptographic inventory düzenli güncellenmelidir. Güvenlik programı sürekli review ile canlı tutulmalıdır.

Güvenli Veri Depolamada Yapılan Yaygın Hatalar

Cryptographic hataların büyük bölümü algoritmanın matematiğinden değil kullanım biçiminden kaynaklanır. Base64'ü encryption sanmak, key'i source code'a yazmak veya parolayı SHA-256 ile tek başına hashlemek sık karşılaşılan örneklerdir. Backup ve log kopyaları da genellikle gözden kaçar. TDE'nin bütün saldırıları engellediğini düşünmek yanlış güven hissi oluşturabilir. Secure coding standard bu hataları doğrudan yasaklayan açık kurallar içermelidir.

Base64'ü Encryption Sanmak

Base64 encoding'dir ve secret key kullanmaz. Herkes kolayca geri çevirebilir. Hassas veriyi Base64 biçiminde database'e yazmak gizlilik sağlamaz. Encoding yalnızca taşıma veya temsil amacıyla kullanılmalıdır. Encryption gereken yerde modern cryptographic primitive kullanılmalıdır.

Password'ü AES ile Encrypt Etmek

Password authentication için geri okunmak zorunda değildir. AES kullanılırsa decryption key saklanması gerekir. Bu key sızdığında bütün parolalar açılabilir. Password hashing bu riski azaltmak için tasarlanmıştır. Argon2id gibi uygun algoritma tercih edilmelidir.

SHA-256'yı Tek Başına Password Hash Olarak Kullanmak

SHA-256 çok hızlıdır. Bu özellik saldırganın yüksek sayıda parola tahmini yapmasını kolaylaştırır. Salt eklemek hızlı brute-force problemini çözmez. Memory-hard veya adaptif password hashing kullanılmalıdır. Legacy SHA-256 kayıtları migration planına alınmalıdır.

Kendi Encryption Algoritmasını Yazmak

Yeni crypto algorithm geliştirmek ciddi uzmanlık ve uzun review süreci gerektirir. Gizli tutulan algorithm güvenlik garantisi oluşturmaz. Standard primitive'ler geniş araştırma ve testten geçmiştir. Uygulama ihtiyaçları için hazır crypto library kullanılmalıdır. Custom protocol zorunluysa bağımsız uzman review'u gerekir.

ECB Kullanmak

ECB plaintext pattern'lerini ciphertext içinde koruyabilir. Aynı blok aynı key altında aynı sonuç verir. Yapılandırılmış veri hakkında bilgi sızıntısı oluşabilir. Modern application encryption için authenticated mode tercih edilmelidir. Static analysis ECB kullanımını otomatik engelleyebilir.

Nonce/IV Tekrar Kullanmak

Bazı mode'larda aynı key ile nonce tekrar kullanımı ciddi güvenlik kaybına yol açar. GCM bu konuda özellikle dikkat gerektirir. Distributed system nonce generation stratejisi test edilmelidir. Library'nin güvenli API'si tercih edilmelidir. Nonce secret değildir ancak uniqueness koşulu önemlidir.

Key'i Kod İçine Yazmak

Hard-coded key repository ve build artifact içinde yayılır. Bir kere commit edildiğinde history içinde kalabilir. Key secret manager veya KMS üzerinden runtime'da alınmalıdır. Secret scanning pipeline içinde çalışmalıdır. Bulunan key derhal rotate edilmelidir.

Key'i Ciphertext ile Aynı Database'de Tutmak

Plaintext key ile ciphertext aynı database'de bulunursa database dump ikisini birlikte açığa çıkarabilir. Key ayrı security boundary içinde tutulmalıdır. KMS veya HSM bu ayrımı sağlar. Wrapped DEK ciphertext yanında tutulabilir. Çünkü onu açacak KEK ayrı sistemdedir.

Bütün Veriyi Tek Key ile Encrypt Etmek

Tek key compromise durumunda çok büyük blast radius oluşturabilir. Tenant veya data category bazlı DEK kapsamı daraltabilir. Key sayısı arttığında automation gerekir. Envelope encryption yönetim yükünü azaltır. Key hierarchy data classification ile eşleştirilmelidir.

Key Rotation Yapmamak

Sonsuza kadar kullanılan key exposure süresini büyütür. Rotation policy key type ve risk bazında tanımlanmalıdır. Rotation otomatikleştirilebilir. Eski ciphertext compatibility planlanmalıdır. Emergency rotation normal schedule'dan ayrı prosedür olmalıdır.

Backup'ları Unutmak

Backup production verisinin büyük kopyasını içerir. Ana storage encryption backup'a otomatik yansımayabilir. Backup key lifecycle ayrıca yönetilmelidir. Restore testinde decryption gerçekten denenmelidir. Retention süresi gereksiz veri birikimini önlemelidir.

Log'larda Plaintext PII Bırakmak

Log sistemi hassas verinin kontrolsüz kopyasına dönüşebilir. Request body ve exception data özellikle risklidir. Structured logging ve redaction uygulanmalıdır. Access token ile password hiçbir koşulda loglanmamalıdır. Log retention data classification ile uyumlu olmalıdır.

TDE'nin Her Saldırıya Karşı Koruduğunu Sanmak

TDE storage file theft riskini azaltır. Database engine yetkili sorgulara plaintext döndürür. SQL injection veya compromised database credential bu nedenle hâlâ risklidir. Field-level veya application-level encryption ek koruma sağlayabilir. Threat model hangi layer'ın gerekli olduğunu belirlemelidir.

HTTPS Kullanıp Database Trafiğini Plaintext Bırakmak

HTTPS sadece client ile web endpoint arasındaki trafiği korur. Backend ile database bağlantısı ayrı network path'tir. Hassas query ve result'lar internal network üzerinde plaintext kalabilir. Database TLS etkinleştirilmelidir. Certificate validation da zorunlu olmalıdır.

Encryption Açıp Key Access'i Sınırsız Bırakmak

Bütün servisler decrypt yapabiliyorsa key compromise alanı genişler. Least privilege ile permission daraltılmalıdır. Encrypt-only workload mümkünse decrypt izni almamalıdır. KMS audit logları access pattern'i izlemelidir. Access review düzenli yapılmalıdır.

Recovery Key'lerini Test Etmemek

Recovery key yalnızca var olmakla fayda sağlamaz. Gerçek restore sırasında çalıştığı doğrulanmalıdır. Yanlış format veya eksik permission disaster anında ortaya çıkmamalıdır. Düzenli recovery tatbikatı yapılmalıdır. Test key'leri production data'dan izole biçimde kullanılabilir.

Güvenli Encryption Tasarımının Başarısı Nasıl Ölçülür?

Güvenlik kontrolünün varlığını ölçemiyorsanız zaman içinde bozulduğunu fark etmek zorlaşır. Encryption coverage, key age, rotation compliance ve legacy algorithm kullanımı gibi metrikler programın durumunu gösterir. Yalnızca yüzde yüz coverage hedefi yeterli değildir. Excessive decrypt permission ve key recovery success rate de operasyon kalitesini gösterir. Metrikler ekipleri cezalandırmak yerine iyileştirme önceliğini belirlemek için kullanılmalıdır.

Encryption Coverage

Encryption coverage hassas asset'lerin ne kadarının uygun protection kullandığını gösterir. Veri sınıfına göre ayrı oran hesaplanmalıdır. Public data ile Restricted data aynı metriğe karıştırılmamalıdır. Unknown asset sayısı ayrıca izlenmelidir. Discovery sistemi coverage hesabının doğruluğunu artırır.

Unencrypted Sensitive Asset Sayısı

Şifrelenmemiş hassas asset sayısı doğrudan remediation backlog oluşturabilir. Storage, backup ve database ayrı kategorilerde takip edilmelidir. Yeni asset oluştuğunda otomatik scanner tespit etmelidir. Critical data için hedef sıfır olabilir. Exception'ların owner ve expiry bilgisi bulunmalıdır.

Key Rotation Compliance

Rotation compliance cryptoperiod süresi dolmuş key sayısını ölçer. Scheduled rotation otomasyonu başarısızlıkları görünür hâle gelir. Key type bazında farklı target belirlenebilir. Overdue key'ler risk seviyesine göre önceliklendirilmelidir. Metric yalnızca key creation date üzerinden değil gerçek active usage üzerinden hesaplanmalıdır.

Key Age

Key age en eski active key'leri bulmayı sağlar. Yüksek yaş her zaman otomatik risk değildir ancak review gerektirebilir. Long-lived root key ve short-lived DEK farklı policy'lere sahiptir. Dashboard key type'a göre threshold kullanmalıdır. Owner bilgisi remediation sürecini hızlandırır.

Excessive Decrypt Permission Sayısı

Gereksiz decrypt permission security posture için önemli göstergedir. Kullanılmayan servis role'ları düzenli review ile kaldırılmalıdır. Permission graph hangi identity'nin hangi key'e eriştiğini gösterebilir. Human decrypt access ayrı izlenebilir. Hedef decrypt kapsamını iş ihtiyacıyla sınırlı tutmaktır.

Hard-Coded Key Findings

Secret scanning tarafından bulunan hard-coded key sayısı secure coding kalitesini gösterir. Kritik olan yalnızca bulguyu kapatmak değildir. Gerçek key rotate edilmelidir. Aynı hata tekrar ediyorsa developer tooling iyileştirilmelidir. Trend zaman içinde düşmelidir.

TLS Coverage

TLS coverage external ve internal hassas bağlantıların ne kadarının encryption kullandığını gösterir. Database ve message broker bağlantıları dahil edilmelidir. Protocol version ayrıca ölçülmelidir. TLS 1.0 veya 1.1 kullanan endpoint'ler legacy olarak işaretlenmelidir. Certificate validation durumu mümkün olduğunda otomatik test edilmelidir.

Legacy Algorithm Kullanımı

MD5, SHA-1 veya legacy cipher kullanımı cryptographic inventory üzerinden izlenebilir. Kullanım amacı sonucu etkiler. Her legacy instance için migration owner atanmalıdır. Deadline yaklaşınca escalation yapılabilir. Yeni deployment'ta legacy primitive policy ile engellenmelidir.

Key Recovery Success Rate

Key recovery success rate disaster recovery kabiliyetini gösterir. Backup mevcut olsa bile key recover edilemiyorsa sonuç başarısızdır. Düzenli tatbikatlar gerçek metriği üretir. Recovery süresi de ayrıca ölçülmelidir. Başarısız testler kök neden analiziyle kapatılmalıdır.

Cryptographic Incident Sayısı

Key leak, expired certificate veya insecure cipher deployment cryptographic incident olarak izlenebilir. Sadece toplam sayı yeterli değildir. Severity ve root cause kategorisi kullanılmalıdır. Tekrarlayan hata process problemine işaret eder. Incident lessons learned secure coding standardına yansıtılmalıdır.

Güvenli Şifreleme ve Hassas Veri Depolamanın Geleceği

Hassas veri güvenliğinin geleceğinde encryption varsayılan özellik olmaktan daha ileri giderek policy-driven bir kontrol hâline gelecektir. Hardware-backed key management daha erişilebilir olurken crypto agility post-quantum geçiş için temel gereksinim olacaktır. Confidential computing data in use risklerini azaltmak için daha geniş kullanım görebilir. Searchable ve queryable encryption ürün tasarımlarında yeni seçenekler sunacaktır. Bununla birlikte en önemli ilkeler değişmeyecek: gereksiz veriyi saklamamak, key'i veriden ayırmak ve erişimi mümkün olduğunca dar tutmak.

Encryption by Default

Yeni storage kaynaklarının otomatik encrypt edilmesi human error riskini azaltır. Default key type veri sınıfına göre farklı olabilir. Policy unencrypted resource oluşmasını engelleyebilir. Legacy asset'ler migration programına alınmalıdır. Encryption by default erişim kontrolünün yerine geçmez.

Policy-Driven Encryption

Data classification tag'i encryption requirement'ı otomatik belirleyebilir. Restricted resource customer-managed key olmadan deploy edilemeyebilir. Policy CI/CD ve cloud control plane içinde uygulanabilir. Exception'lar süreli ve audit edilebilir olmalıdır. Bu yaklaşım güvenlik kararlarını kişisel tercihten çıkarır.

Hardware-Backed Key Management

Hardware-backed key protection cloud ve mobile platformlarda daha yaygın hâle gelmektedir. Key'in plaintext export edilmemesi güçlü güvenlik sınırı sağlar. Attestation gibi özellikler belirli workload senaryolarında ek güven oluşturabilir. Operasyon kolaylığı ile hardware assurance birlikte sunulabilir. Recovery tasarımı yine kritik kalır.

Confidential Computing

Confidential computing data in use korunmasına odaklanan hardware-backed izolasyon tekniklerini kullanır. Amaç hassas workload memory'sini host veya diğer process'lerden daha güçlü biçimde ayırmaktır. Her uygulama için gerekli değildir. Threat model yüksek privilege host erişimini içeriyorsa değerli olabilir. Attestation ve key release policy birlikte kullanılabilir.

Searchable / Queryable Encryption

Encrypted data üzerinde sınırlı query yapabilme uzun süredir önemli araştırma alanıdır. Deterministic encryption basit equality search sağlarken bilgi sızıntısı taşır. Daha gelişmiş yöntemler performans ve leakage arasında farklı dengeler sunar. Uygulama seçimi açık threat model gerektirir. Normal database query rahatlığını aynen koruyan sihirli encryption çözümü olmadığı kabul edilmelidir.

Crypto Agility

Yeni cryptographic standartlar çıktıkça migration kabiliyeti daha önemli olacaktır. Ciphertext metadata versioned tutulmalıdır. Algorithm business logic'e gömülmemelidir. Cryptographic inventory sürekli güncel olmalıdır. Legacy primitive decommission için düzenli program kurulmalıdır.

Post-Quantum Migration

Post-quantum migration özellikle public-key cryptography kullanan sistemleri etkileyecektir. NIST standardları artık kurumların plan yapabileceği somut temel sunmaktadır. Certificate ve protocol ecosystem desteği aşamalı gelişecektir. Hybrid deployment belirli geçiş dönemlerinde kullanılabilir. Veri gizlilik süresi migration önceliğini belirlemelidir.

Automated Key Lifecycle

Manual key lifecycle büyük sistemlerde sürdürülebilir değildir. Automatic rotation, policy enforcement ve expiry monitoring yaygınlaşacaktır. Key creation belirli infrastructure deployment'a bağlanabilir. Owner ve data class metadata otomatik eklenebilir. Human approval yalnızca yüksek riskli irreversible operasyonlarda tutulabilir.

Continuous Cryptographic Compliance

Yıllık audit tek başına modern cloud ortamının hızına yetişemez. Continuous scanning unencrypted asset ve legacy cipher kullanımını anlık tespit edebilir. Policy violation deployment sırasında engellenebilir. Dashboard key age ve TLS coverage gibi metrikleri sürekli gösterebilir. Compliance böylece dönemsel belge hazırlamaktan sürekli teknik kontrole dönüşür.

Sıkça Sorulan Sorular

Bu bölüm geliştiricilerin ve teknik yöneticilerin güvenli şifreleme konusunda sık sorduğu temel soruları kısa ve uygulanabilir biçimde yanıtlar. Her cevap tek başına mimari karar yerine geçmez. Veri sınıfı, tehdit modeli ve kullanılan platform mutlaka değerlendirilmelidir. Özellikle key management ve password storage konularında güvenilir library ve güncel standart kullanılması önemlidir. Yüksek riskli projelerde security architecture review yapılması fayda sağlar.

Hassas veri nasıl güvenli saklanır?

Önce verinin gerçekten saklanması gerekip gerekmediği belirlenmelidir. Gerekli veriler sınıflandırılmalı ve uygun at-rest encryption kullanılmalıdır. Anahtar KMS veya HSM gibi data'dan ayrı sistemde korunmalıdır. TLS ile transit trafik şifrelenmeli ve access control uygulanmalıdır. Log, cache ve backup kopyaları da aynı güvenlik modeline dahil edilmelidir.

En güvenli şifreleme algoritması hangisidir?

Tek bir algoritmayı bütün kullanım alanları için en güvenli ilan etmek doğru değildir. Bulk data encryption için AES-GCM veya uygun koşullarda ChaCha20-Poly1305 güçlü modern seçeneklerdir. Public-key işlemler için farklı primitive'ler gerekir. Güvenlik mode, key management ve implementation kalitesine de bağlıdır. Algoritma kullanım amacına göre seçilmelidir.

AES-256 nedir?

AES-256 256 bit secret key kullanan simetrik encryption çeşididir. Büyük veri setlerinde etkili biçimde kullanılabilir. AES-GCM gibi authenticated mode ile birlikte tercih edilebilir. Key'in güvenli saklanması zorunludur. AES-256 tek başına sistemin tamamının güvenli olduğunu garanti etmez.

AES-GCM neden tercih edilir?

AES-GCM confidentiality ve integrity özelliklerini birlikte sağlayan AEAD mode'dur. Authentication tag ciphertext değişikliğini tespit etmeye yardımcı olur. Modern hardware üzerinde yüksek performans gösterebilir. Aynı key altında nonce tekrar kullanımından kaçınılmalıdır. Güvenilir library API'si kullanılmalıdır.

AES-128 mi AES-256 mı kullanılmalıdır?

Her iki seçenek de modern uygulamalarda güçlü kullanım alanına sahiptir. AES-256 daha yüksek key strength margin sunar. AES-128 belirli performans ve interoperability gereksinimlerinde yeterli olabilir. Karar compliance ve uzun vadeli confidentiality ihtiyacına göre verilmelidir. Key management hatası iki seçeneğin de güvenliğini zayıflatır.

Password neden encrypt edilmemelidir?

Password authentication için geri çözülebilir biçimde saklanmak zorunda değildir. Encryption kullanılırsa bir decryption key saklamak gerekir. Bu key compromise bütün parolaların açılmasına neden olabilir. Password hashing doğrulama için daha uygun tasarımdır. Argon2id gibi modern algoritmalar tercih edilmelidir.

Argon2id nedir?

Argon2id memory-hard password hashing algoritmasıdır. CPU yanında memory cost parametresi kullanır. GPU ve yüksek paralellikli cracking maliyetini artırmayı hedefler. Memory, iteration ve parallelism değerleri sistem donanımına göre benchmark edilmelidir. Modern password storage için güçlü seçeneklerden biridir.

bcrypt güvenli midir?

bcrypt uzun süredir kullanılan adaptif password hashing algoritmasıdır. Uygun work factor ile legacy ve bazı modern sistemlerde kullanılabilir. Yeni uygulamalarda Argon2id gibi seçenekler ayrıca değerlendirilmelidir. bcrypt'in password length davranışı implementation üzerinden bilinmelidir. Work factor zaman içinde artırılmalıdır.

SHA-256 parola saklamak için yeterli midir?

Hayır, SHA-256 tek başına password storage için uygun değildir. Çok hızlı çalışır ve saldırganın yüksek sayıda tahmin yapmasını kolaylaştırır. Salt kullanmak bu hız sorununu çözmez. Password-specific slow veya memory-hard algorithm kullanılmalıdır. SHA-256 farklı cryptographic amaçlarda hâlâ değerlidir.

Salt ve pepper arasındaki fark nedir?

Salt her password için benzersiz olan ve gizli tutulması gerekmeyen değerdir. Pepper ise database'den ayrı saklanan secret olabilir. Salt rainbow table kullanımını zorlaştırır. Pepper ek defense layer sunabilir. Pepper kullanılıyorsa KMS veya secret manager gibi ayrı storage'da korunmalıdır.

TDE nedir?

TDE database storage file'larını şifreleyen transparent encryption yaklaşımıdır. Application query davranışını genellikle değiştirmez. Disk ve offline file theft riskine karşı faydalıdır. SQL injection veya compromised database account'a karşı tek başına koruma sağlamaz. Hassas field'lar için ek encryption layer gerekebilir.

Column-level encryption nedir?

Column-level encryption yalnızca belirli database alanlarını şifreler. Kimlik, finansal veya benzeri yüksek riskli alanlarda kullanılabilir. Query ve index davranışını etkileyebilir. Key database'den ayrı tutulmalıdır. Deterministic ve randomized yöntemlerin farklı güvenlik özellikleri vardır.

Application-level encryption nedir?

Application-level encryption veriyi database'e göndermeden önce uygulama içinde şifreler. Database yalnızca ciphertext görür. DBA veya database credential threat modeline karşı ek koruma sağlar. Query kabiliyeti azalabilir. Key management ve versioned ciphertext formatı dikkatle tasarlanmalıdır.

Envelope encryption nedir?

Envelope encryption veriyi DEK ile şifreleyip DEK'i ayrı KEK ile wrap eden modeldir. KEK genellikle KMS veya HSM içinde tutulur. Büyük payload doğrudan KMS'e gönderilmez. Böylece performans ve key management ölçeklenebilir hâle gelir. Wrapped DEK ciphertext yanında saklanabilir.

DEK ve KEK arasındaki fark nedir?

DEK gerçek application data'yı şifreler. KEK ise DEK'i korur. DEK daha sık ve daha küçük scope'ta üretilebilir. KEK merkezi KMS veya HSM içinde tutulabilir. Bu hierarchy compromise blast radius ve rotation yönetimini kolaylaştırır.

KMS ile HSM arasındaki fark nedir?

KMS key lifecycle ve IAM yönetimini yüksek seviyede sunan hizmettir. HSM key materyalini özel hardware boundary içinde korumaya odaklanır. KMS altyapısı HSM kullanabilir. Her application'ın doğrudan HSM ile çalışması gerekmez. Seçim compliance, control ve operational requirement'a göre yapılmalıdır.

Encryption key nerede saklanmalıdır?

Master encryption key ciphertext ile aynı database'de plaintext tutulmamalıdır. KMS veya HSM tercih edilebilir. Daha düşük riskli secret'lar uygun secret management sisteminde tutulabilir. Source code ve container image kalıcı key storage değildir. Erişim least privilege ve audit ile korunmalıdır.

Key rotation ne sıklıkta yapılmalıdır?

Tek bir evrensel rotation süresi yoktur. Key type, data sensitivity, usage volume ve exposure riskine göre cryptoperiod belirlenmelidir. Compliance gereksinimleri ayrıca değerlendirilmelidir. Compromise şüphesinde scheduled süre beklenmeden emergency rotation yapılmalıdır. Kurum her key type için açık policy oluşturmalıdır.

TLS 1.3 kullanılmalı mı?

Evet, modern uygulamalarda TLS 1.3 varsayılan tercih olmalıdır. Uyumluluk gerektiren client'lar için güvenli TLS 1.2 desteği tutulabilir. Eski TLS sürümleri kapatılmalıdır. Certificate validation doğru yapılandırılmalıdır. Internal service ve database trafiği de TLS kapsamına alınmalıdır.

KVKK şifreleme gerektiriyor mu?

KVKK açısından kişisel veri güvenliğinde uygun teknik ve idari tedbirlerin uygulanması gerekir. Encryption önemli teknik tedbirlerden biridir ancak tek başına yeterli değildir. Veri türü ve risk seviyesi dikkate alınmalıdır. Access control, logging, retention ve backup security birlikte ele alınmalıdır. Belirli hukuki yükümlülükler için güncel Kurum rehberleri ve uzman görüşü ayrıca incelenmelidir.

FIPS 140-3 nedir?

FIPS 140-3 cryptographic module security requirements standardıdır. Algorithm strength ile module validation aynı kavram değildir. Belirli regulated sistemler validated module kullanımı talep edebilir. Kullanılan gerçek library ve module version'ın kapsamı kontrol edilmelidir. FIPS mode bütün application security sorunlarını otomatik çözmez.

Post-quantum cryptography nedir?

Post-quantum cryptography büyük ölçekli quantum computer tehdidine karşı dayanıklı olması hedeflenen cryptographic algoritmaları kapsar. NIST ML-KEM, ML-DSA ve SLH-DSA için standartlar yayımlamıştır. Bu algoritmalar farklı key establishment ve digital signature görevlerine hizmet eder. Migration için önce cryptographic inventory gerekir. Mevcut sistemler planlı crypto agility yaklaşımıyla hazırlanmalıdır.

AES kuantum bilgisayarlara karşı güvenli midir?

Quantum threat symmetric encryption'ı public-key cryptography ile aynı şekilde etkilemez. AES güçlü symmetric encryption olarak önemini korur. Uzun vadeli yüksek security margin için AES-256 değerlendirilebilir. PQC standardları AES'in doğrudan yerine geçmez. Özellikle key exchange ve digital signature tarafında değişiklik daha belirgin olacaktır.

Hassas veriler backup'ta nasıl korunmalıdır?

Backup dosyaları güçlü at-rest encryption kullanmalıdır. Backup key'leri data'dan ayrı tutulmalıdır. Cross-region restore için key availability test edilmelidir. Retention gereksiz veri birikimini önlemelidir. Düzenli disaster recovery testi gerçek decrypt ve restore işlemini kapsamalıdır.

Şifreleme performansı nasıl ölçülür?

Encryption ve decryption throughput temel metriklerdir. P50, p95 ve p99 latency kullanıcı deneyimini gösterir. CPU kullanımı ve KMS API call sayısı ayrıca izlenmelidir. DEK cache hit rate envelope encryption davranışını anlamaya yardımcı olur. Benchmark production benzeri payload ve concurrency ile yapılmalıdır.

Güvenli Şifreleme ve Hassas Veri Depolama Standartları Hakkında Ek Sıkça Sorulan Sorular

Güvenli Şifreleme ve Hassas Veri Depolama Standartları hakkında karar verirken ekiplerin yalnızca algoritma ismine değil bütün veri yaşam döngüsüne bakması gerekir. Hassas verinin nerede bulunduğu, hangi ağlardan geçtiği ve kimlerin decryption yapabildiği birlikte değerlendirilmelidir. OWASP ve NIST gibi kaynaklar teknik kararların doğrulanması için iyi başlangıç noktalarıdır. KVKK kapsamındaki sistemlerde veri güvenliği ve idari süreçler birlikte ele alınmalıdır. Kurumsal veri şifreleme ve hassas veri güvenliği hizmeti arayan ekiplerin de çözüm seçmeden önce gerçek veri akışını ve tehdit modelini çıkarması faydalıdır.

Güvenli şifreleme ve hassas veri depolama için hangi standartlar kullanılmalıdır?

OWASP Cryptographic Storage, Key Management, Password Storage ve TLS rehberleri uygulama ekipleri için güçlü teknik referanslardır. NIST SP 800-57 key management yaşam döngüsüne yardımcı olur. NIST SP 800-131A algorithm transition planları açısından değerlidir. FIPS 140-3 belirli cryptographic module gereksinimlerinde önem kazanır. KVKK ve sektör özelindeki standartlar kullanılan veri ve hukuki kapsamla birlikte değerlendirilmelidir.

Hassas veriler depolama sırasında ve aktarım sırasında nasıl şifrelenmelidir?

Depolama sırasında veri sınıfına göre disk, database, field veya application-level encryption kullanılabilir. Çok hassas alanlarda application-level AES-GCM ve envelope encryption güçlü seçenek oluşturur. Aktarım sırasında TLS 1.3 tercih edilmelidir. Database ve service-to-service bağlantıları da encryption kapsamına alınmalıdır. KMS veya HSM key'leri data storage'dan ayrı tutmalıdır.

AES-256, TLS ve güçlü parola hash algoritmaları hangi veri türlerinde kullanılmalıdır?

AES-256 geri okunması gereken yüksek hassasiyetli verilerin simetrik encryption ihtiyacında değerlendirilebilir. TLS ağ üzerinden taşınan hassas ve normal application trafiğini korur. Kullanıcı parolaları AES ile encrypt edilmemeli, Argon2id gibi password hashing algoritmaları kullanılmalıdır. API secret ve certificate private key ise secret management mekanizmalarında korunmalıdır. Teknik seçim her zaman verinin kullanım amacına göre yapılmalıdır.

Şifreleme anahtarlarının saklanması, erişim kontrolü ve düzenli anahtar rotasyonu nasıl yönetilmelidir?

Master key KMS veya HSM içinde tutulmalıdır. Key ile encrypted data ayrı trust boundary'lerde bulunmalıdır. IAM least privilege uygulanmalı ve decrypt permission yalnızca gerekli workload'lara verilmelidir. Rotation key type ve cryptoperiod'a göre otomatikleştirilebilir. Key access audit logları anormal decrypt davranışını tespit etmek için izlenmelidir.

Güvenli şifreleme ve hassas veri depolama standartları konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Veri şifreleme ve siber güvenlik danışmanlığı yakınımda şeklinde arama yapan geliştiriciler için yerel teknik topluluklar uygulamalı öğrenme açısından değerli başlangıç noktalarıdır. Diyarbakır'da yazılım, güvenlik ve açık kaynak projeleri üzerine bağlantı kurmak isteyenler Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about sayfasından bilgi alabilir. Topluluk ortamında OWASP laboratuvarı, TLS testi veya envelope encryption demosu gibi uygulamalı çalışmalar geliştirilebilir. Kurumsal sistemlerde gerçek kişisel veri üzerinde eğitim yapılmamalı ve izole demo verisi kullanılmalıdır. Danışmanlık gereksiniminde ise önce veri envanteri, tehdit modeli ve mevcut key management yapısının değerlendirilmesi doğru başlangıç olur.

Sonuç

Güvenli Şifreleme ve Hassas Veri Depolama Standartları güçlü bir cipher seçmekten çok daha geniş bir mühendislik disiplinidir. Sağlam tasarım önce gereksiz veriyi ortadan kaldırır, kalan veriyi sınıflandırır, doğru encryption katmanını seçer ve anahtarları veriden ayrı yönetir. AES-GCM, TLS 1.3, Argon2id, KMS, HSM ve envelope encryption ancak doğru erişim politikaları, loglama, backup güvenliği ve rotation süreçleriyle birlikte anlam kazanır. Benim projelerde en faydalı bulduğum yaklaşım, önce basit bir data flow diyagramı çıkarıp her adımda plaintext'in nerede bulunduğunu sormaktır. Bu tek soru log, cache, database, backup ve external API katmanlarında gözden kaçan birçok riski görünür kılar. Diyarbakır'da bu konuları birlikte öğrenmek, proje geliştirmek ve yazılım topluluğuyla bağlantı kurmak için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilir, uygulamalı çalışmalar için https://www.diyarbakiryazilim.com.tr/projects sayfasına göz atabilirsiniz. En iyi başlangıç noktası daha fazla encryption eklemek değil, hangi veriyi neden koruduğunuzu net biçimde tanımlamaktır.