Anahtar yönetimi ve KMS

Şifrelemenin zor kısmı algoritma değildir. Anahtarı nerede tutacağın, kimin kullanacağı ve nasıl yenileneceği asıl sorudur. Kodun içine gömülen bir anahtar, şifrelemeyi süsten ibaret bırakır; kodu okuyan veriyi de okur. AWS KMS bu işi senin yerine üstlenir.

Zarf şifrelemeyi komut satırında adım adım çalıştıracak, anahtar politikasının neden birincil kapı olduğunu öğreneceksin. Dönüşün eski veriye ne yaptığını ve silmenin neden bekletildiğini göreceksin. En sonda anahtarın kötüye kullanımını kayıtlardan yakalamaya bakacaksın.

Veriyi şifrelersen anahtarı korumak zorundasın. Anahtarı da şifrelersen onun anahtarını korumak zorundasın. Bu zincirin tepesinde bir kök anahtar kalır ve KMS bu kök anahtarları senin yerine tutar.

AWS KMS anahtarları FIPS 140-3 Güvenlik Düzeyi 3 onaylı donanım güvenlik modüllerinde (HSM) korunur ve servisten şifresiz çıkmaz. Sen anahtarı hiç görmezsin; yalnız şifrele, çöz ve veri anahtarı üret gibi çağrılar yaparsın.

KMS anahtarı büyük veriyi doğrudan şifrelemez, veriyi şifreleyen anahtarı korur. Buna zarf şifreleme denir. Her çağrı CloudTrail'e düşer, yani kimin hangi anahtarla ne zaman şifre çözdüğü kayda geçer. Azure'da aynı rolü Key Vault ve Managed HSM, Google Cloud'da Cloud KMS üstlenir.

KMS'te üç anahtar türüyle karşılaşırsın. AWS sahipli anahtarları (AWS owned) bir servis kendi içinde kullanır ve hesabında görünmez. AWS yönetimli anahtarları (AWS managed) bir servis senin hesabında oluşturur; aws/s3 ya da aws/ebs gibi takma adlarla görünür.

Politikalarını değiştiremezsin ve malzemeleri yılda bir kendiliğinden döner. Müşteri yönetimli anahtarda (customer managed) politikayı, takma adı, dönüşü ve silmeyi sen yönetirsin. Politika, anahtarı kimin kullanacağını yazan ayrı bir belgedir.

Fark denetimde belirginleşir. Müşteri yönetimli anahtarda kimin şifre çözeceğini politikayla sınırlar, gerektiğinde anahtarı devre dışı bırakıp erişimi tek hamlede kesersin. Kişisel veri taşıyan depolar için bu yüzden iyi bir varsayılandır.

Anahtar tasarımında sık sorulan bir soru vardır: kaç anahtar olmalı? Her kaynak için ayrı anahtar yönetimi ağırlaştırır, tek anahtar ise ayrıştırmayı yok eder. Yaygın denge, veri sınıfı ve ortam başına bir anahtardır.

Üretim ile test ayrı anahtar kullanır. Böylece test ortamındaki bir kimlik üretim verisini çözemez. Kod ve şablonlar ham anahtar kimliği yerine takma ada (alias) bakar.

Anahtar değiştiğinde yalnız takma adın gösterdiği yer güncellenir ve hiçbir uygulama değişmez. Anahtar politikalarını da kod olarak tutarsın: şablondan üretilen politika gözden geçirilir, geçmişi saklanır ve her yeni anahtarda aynı kalıp tekrarlanır.

Büyük veriyi KMS'e göndermek verimsizdir. KMS'in Encrypt çağrısı zaten en fazla 4 KB veri kabul eder. Bu yüzden iki katmanlı bir yapı kullanılır.

Veri şifreleme anahtarı (DEK) veriyi şifreler. Anahtar şifreleme anahtarı (KEK) ise DEK'i şifreler, yani sarar. KMS anahtarı burada KEK rolündedir.

Şifreli veri ile şifreli DEK yan yana saklanır ve düz DEK diske yazılmaz. Google Cloud'un önerisi de aynı yöndedir. DEK yerelde kullanılır, her yazmada yenisi alınır, AES-256-GCM tercih edilir ve iki kullanıcının verisi aynı DEK ile şifrelenmez. Aşağıda bu akışı lab-veri takma adlı anahtarla çalıştırıyorsun.

# 1) Veri anahtarı iste: biri düz, biri ana anahtarla şifreli döner
$ aws kms generate-data-key --key-id alias/lab-veri --key-spec AES_256 \
    --encryption-context veri=musteri
{
    "CiphertextBlob": "AQIDAHhzY3...(kısaltıldı)",
    "Plaintext": "VdzKNHGzUAzJeRBVY+uUmo...(kısaltıldı)",
    "KeyId": "arn:aws:kms:eu-central-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}

# 2) Plaintext ile dosyayı yerelde AES-256-GCM ile şifrele, sonra bellekten sil
# 3) CiphertextBlob değerini base64 çözüp şifreli dosyanın yanına yaz: anahtar.bin

# 4) Çözerken şifreli anahtarı aynı bağlamla KMS'e gönder
$ aws kms decrypt --ciphertext-blob fileb://anahtar.bin --key-id alias/lab-veri \
    --encryption-context veri=musteri --query Plaintext --output text
VdzKNHGzUAzJeRBVY+uUmo...(kısaltıldı)

Çıktıyı satır satır oku. generate-data-key aynı anahtarı iki biçimde döndürür. Plaintext düz veri anahtarıdır ve base64 kodludur; onunla dosyayı yerelde şifreler, sonra bellekten silersin. CiphertextBlob aynı anahtarın KMS anahtarıyla şifrelenmiş hâlidir ve şifreli dosyanın yanına yazılır.

KeyId alanı takma adı değil, gerçek anahtar ARN'sini gösterir. Simetrik anahtarlarda çözme adımında --key-id zorunlu değildir, çünkü hangi KMS anahtarının kullanıldığı şifreli blobun içinde yazar. AWS yine de beklediğin anahtarı --key-id ile vermeni önerir; böylece başka bir anahtarla şifrelenmiş blob sessizce çözülmez. --encryption-context kısmı şifreleme bağlamıdır (encryption context).

Gizli olmayan anahtar-değer çiftleridir ve şifreli metne kriptografik olarak bağlanır. Çözerken aynı bağlamı vermezsen KMS isteği reddeder. Bağlam CloudTrail'de düz metin görünür, bu yüzden içine sır yazmazsın.

KMS'te erişimin birincil kapısı anahtar politikasıdır. KMS burada öbür AWS kaynak politikalarından ayrılır: anahtar politikası hesaba ya da hesaptaki kimliklere kendiliğinden izin vermez. İzin politikada açıkça yazmalıdır.

Varsayılan politikanın ilk ifadesi bu yüzden kritiktir. Principal olarak hesabın kök ARN'sini yazar ve kms:* izni verir. Bu ifade tek başına hiçbir kimliğe izin vermez.

Yaptığı iş, hesabın IAM politikalarıyla yetki devretmesinin yolunu açmaktır. İfade yoksa IAM tarafındaki izinler etkisiz kalır; IAM'deki açık ret ise yine çalışır. Sonuç şaşırtıcı olabilir. Hesabın yöneticisi bile, politika ona yol açmadıysa o anahtarla şifre çözemez.

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
},
{
  "Sid": "SiparisUygulamasiYalnizLabVeri",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/siparis-uygulamasi" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::lab-veri" }
  }
}

İkinci ifade dar bir kullanıcı ifadesidir. siparis-uygulamasi rolü yalnız çözme ve veri anahtarı üretme işlemi yapar. Koşul, şifreleme bağlamında lab-veri kovasının ARN'sini ister.

Kovada S3 Kova Anahtarı açık olduğu için bağlamda nesnenin değil kovanın ARN'si durur. Rol aynı anahtarla başka bir kovanın verisini çözmeye kalkarsa bağlam uymaz ve istek reddedilir. Konsolun ürettiği varsayılan politika bir ayrım daha yapar: anahtar yöneticileri ve anahtar kullanıcıları.

Yöneticiler politikayı değiştirir ama şifreleme işlemi yapamaz. Kullanıcılar şifreler ve çözer ama politikaya dokunamaz. Yine de dikkat et, politikayı değiştirebilen yönetici kendine her izni yazabilir. Yönetici listesi bu yüzden kısa tutulur.

Politika yazarken en büyük risk anahtarı yönetilemez bırakmaktır. Politikada yalnız tek bir kullanıcıya izin verip o kullanıcıyı silersen anahtara kimse dokunamaz. Erişimi geri almak için AWS Desteğine başvurman gerekir.

Hesap kök ARN'sini içeren ifade bu kilitlenmeye karşı bir emniyet kemeridir. Politika değişikliklerini önce test hesabında denersin. Servislerin anahtarı senin adına kullanması ise yetki devriyle (grant) olur.

Örneğin EBS, şifreli bir birimi sunucuya bağlarken anahtar üzerinde dar bir yetki devri oluşturur. Konsolun ürettiği politika bu devri, kms:GrantIsForAWSResource koşuluyla yalnız AWS servisleri adına açılan isteklere bırakır. Kimsenin elle ve sınırsız devir yapamaması da bir güvenlik katmanıdır.

Anahtar dönüşü çoğu kişinin yanlış anladığı bir konudur. Müşteri yönetimli anahtarlarda otomatik dönüş isteğe bağlıdır ve varsayılan olarak kapalıdır. Açtığında KMS varsayılan olarak yılda bir yeni anahtar malzemesi üretir.

Aralığı 90 ile 2560 gün arasında kendin de seçebilirsin. Gerekirse tek seferlik anında dönüş (on-demand rotation) de yaparsın. Dönüş eski malzemeyi silmez.

Anahtar kimliği ve ARN'si aynı kalır, yeni şifrelemeler taze malzemeyi kullanır. Çözmede KMS, verinin hangi malzemeyle şifrelendiğini kendisi bulur ve eski veri okunmaya devam eder. Dönüşün yapmadığı şeyi de bil: veri anahtarlarını döndürmez ve veriyi yeniden şifrelemez. Sızmış bir veri anahtarının etkisini dönüş gidermez.

Anahtar silme ise geri alınamaz. Silinen anahtarla şifrelenmiş veri kalıcı olarak okunamaz. KMS bu yüzden isteği hemen uygulamaz, bir bekleme penceresine alır.

Pencere 7 ile 30 gün arasındadır ve varsayılan değer 30 gündür. Bu sürede anahtarın durumu silinmeyi bekliyor (Pending deletion) olur ve hiçbir şifreleme işleminde kullanılamaz. Pencere kapanmadan silmeyi iptal edebilirsin.

Emin değilsen silmek yerine anahtarı devre dışı bırakırsın, çünkü devre dışı anahtar yeniden açılır. Bekleme süresinde birinin anahtarı kullanmaya çalışması önemli bir işarettir. Bir CloudWatch alarmı bu denemeyi sana bildirir ve karar için zaman kazandırır.

$ aws kms schedule-key-deletion --key-id 1234abcd-... --pending-window-in-days 7

Anahtar kullanımını izlemek savunmanın parçasıdır. KMS'e yapılan her çağrı CloudTrail'e yazılır ve iki olay grubu ayrı izlenir. Birincisi kullanım olaylarıdır: Decrypt, GenerateDataKey ve ReEncrypt.

Beklenmedik bir kimliğin çözme çağrısı, alışılmadık bir bölgeden gelen kullanım ya da çağrı sayısındaki ani artış iyi uyarı kurallarıdır. İkincisi yönetim olaylarıdır: ScheduleKeyDeletion, DisableKey, PutKeyPolicy ve CreateGrant. Fidye senaryosunda ilk sinyal çoğu zaman buradan gelir.

Saldırgan anahtar politikasından yöneticileri çıkarır, anahtarı silme sırasına koyar ya da yabancı bir hesaba yetki devreder. Veriyi kendi hesabındaki bir anahtarla yeniden şifrelemek de bilinen bir desendir. Bu olaylar yüksek önemli alarma bağlanır.

Parola ve API anahtarı gibi küçük sırlar KMS'te değil, sır yöneticisinde durur. AWS Secrets Manager sırrı saklar, sürümler ve döndürür. Bir servisin senin adına yönettiği sırlarda, örneğin RDS'in yönettiği ana kullanıcı parolasında, dönüşü servis kendisi yapar. Öbür sırlarda dönüşü bir Lambda fonksiyonu yapar; hem sırrı hem hedef sistemdeki parolayı birlikte günceller.

Sırlar arka planda bir KMS anahtarıyla şifrelenir, yani KMS sırları koruyan katmanda çalışır. Systems Manager Parameter Store'daki SecureString parametreleri de aynı yolu izler. Azure'da Key Vault hem anahtarı hem sırrı tutar, Google Cloud'da ayrı bir Secret Manager servisi vardır. Uygulama sırrı çalışma anında kendi rolüyle okur.