Şifreleme: duran ve aktarılan veri

Şifreleme denetim listelerinde tek bir kutu gibi görünür. Aslında iki ayrı sorudur.

Veri diskte dururken mi korunuyor, yoksa ağda giderken mi? Yanıtlar birbirinden bağımsızdır ve birini açmak diğerini kapatmaz. Üstelik ikisi de erişim denetiminin yerini tutmaz.

Önce her şifrelemenin hangi tehdide karşı çalıştığını ayıracaksın. Sonra S3'teki şifreleme seçeneklerini tanıyacak ve bir kovanın şifreleme durumunu komutla okuyacaksın. Aktarım şifrelemesini kova politikasıyla zorunlu kılmayı ve şifresiz bir anlık görüntüyü düzeltmeyi de göreceksin. En sonda şifrelemenin açık olduğunu bir denetçiye nasıl kanıtlayacağına bakacaksın.

Duran veri şifrelemesi (encryption at rest) diskteki, yedekteki ve anlık görüntüdeki baytları korur. Tehdit, verinin fiziksel ya da mantıksal bir kopyasının yanlış ellere geçmesidir. Bir disk hizmetten çıkarılır, bir yedek kaybolur ya da bir anlık görüntü yanlış hesapla paylaşılır.

Şifreleme varsa bu kopyalar anahtar olmadan anlamsız bayt yığınıdır. Bulutta çoğu servis bunu tek ayarla açar. Şifreleme ve çözme sunucu tarafında yapılır, uygulama bunu fark etmez.

S3, 5 Ocak 2023'ten beri her yeni nesneyi en az SSE-S3 ile şifreler. EBS disk şifrelemesi ise sunucu ile disk arasındaki trafiği de kapsar. Ama yetkili bir kimlik okuduğunda veri ona zaten çözülmüş gelir.

Aktarılan veri şifrelemesi (encryption in transit) kablodaki trafiği korur. Tehdit, iki uç arasına giren biridir: paketleri dinleyen ya da araya girip değiştiren saldırgan. Burada TLS çalışır ve iki iş görür.

Birincisi gizliliktir, trafik okunamaz. İkincisi kimlik doğrulamadır; sertifika, karşı tarafın gerçekten o sunucu olduğunu kanıtlar. Sertifika doğrulamasını kapatan istemci ikinci kazancı çöpe atar.

Şifreli ama doğrulanmamış bir bağlantı, araya giren saldırgana da şifreli bağlanır. Bulutta ağın bir kısmı sağlayıcının paylaşılan altyapısıdır. Bu yüzden iç ağı kendiliğinden güvenli saymak zayıf bir varsayımdır. Her bağlantı bacağı ayrı düşünülür.

S3'te sunucu tarafı şifrelemenin dört biçimi vardır. SSE-S3'te anahtarı S3 yönetir; ücretsizdir ve her kovanın varsayılanıdır. SSE-KMS'te veri anahtarlarını KMS'teki bir anahtar korur.

Anahtar politikası ikinci bir kapı olur ve her çözme işlemi CloudTrail'e düşer. DSSE-KMS aynı işi iki katman şifrelemeyle yapar ve katı düzenleyici gereklilikler için vardır. SSE-C'de anahtarı her istekte müşteri gönderir ve S3 onu saklamaz.

Bir de istemci tarafı şifreleme vardır: veriyi buluta göndermeden önce kendin şifrelersin, sağlayıcı düz metni hiç görmez. Kontrol arttıkça sorumluluk da artar. İstemci tarafında anahtarı kaybetmek veriyi kaybetmek demektir.

SSE-KMS'te her nesne için KMS'e bir çağrı gider. Milyonlarca nesnede bu hem maliyet hem kota sorunudur. S3 Kova Anahtarı (Bucket Key) bu yükü azaltır.

KMS'ten kısa ömürlü, kova düzeyinde bir anahtar alınır ve yeni nesnelerin veri anahtarları onunla üretilir. AWS bu yolla KMS istek maliyetinin yüzde 99'a kadar düştüğünü söyler. Bedeli bir ayrıntıdır: CloudTrail'de nesne ARN'si yerine kova ARN'si görünür ve olay sayısı azalır.

Bir kural daha var. Varsayılan şifreleme ayarı kovaya bağlıdır ve yalnız sonraki yüklemeleri etkiler. Ayar değiştiğinde var olan nesneler olduğu gibi kalır. Aşağıdaki örnekte bunu bir kovada görüyorsun.

$ aws s3api get-bucket-encryption --bucket lab-veri
{
    "ServerSideEncryptionConfiguration": {
        "Rules": [
            {
                "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "aws:kms",
                    "KMSMasterKeyID": "alias/lab-veri"
                },
                "BucketKeyEnabled": true
            }
        ]
    }
}

$ aws s3api head-object --bucket lab-veri --key 2021/musteri.csv
{
    "LastModified": "2021-06-14T09:12:40+00:00",
    "ContentLength": 48213,
    "ServerSideEncryption": "AES256"
}

Çıktıyı satır satır oku. SSEAlgorithm değeri aws:kms ise kova SSE-KMS kullanır; AES256 görseydin SSE-S3 olurdu. KMSMasterKeyID hangi KMS anahtarının kullanılacağını söyler, burada kısa bir takma ad duruyor. S3 bu alanı yazarken doğrulamaz, yani yanlış bir anahtar kimliği ilk yüklemeye kadar fark edilmez.

AWS bu yüzden tam anahtar ARN'sini yazmanı önerir. Kısa takma ad isteği yapan hesapta çözülür; başka bir hesaptan gelen yükleme, kova sahibinin değil o hesabın anahtarıyla şifrelenebilir. BucketKeyEnabled true ise Kova Anahtarı açıktır.

İkinci komut tek bir nesneye bakar. 2021'de yüklenmiş nesne hâlâ AES256, yani SSE-S3 ile şifreli. Kovanın varsayılanı sonradan KMS'e çevrilmiş ama eski nesneye dokunulmamış.

ServerSideEncryption alanı hiç yoksa nesne 2023 öncesinde şifresiz yüklenmiştir. Eski nesneleri yeniden şifrelemek için S3 Batch Operations ile toplu kopyalama işi çalıştırırsın.

$ aws s3api put-bucket-encryption --bucket lab-veri \
    --server-side-encryption-configuration \
    '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'

S3 uç noktaları hem HTTP hem HTTPS isteği kabul eder. Aktarım şifrelemesini zorunlu kılmak için kova politikasına bir Deny ifadesi yazarsın. Koşul aws:SecureTransport anahtarına bakar. İstek TLS ile gelmediyse bu anahtarın değeri false olur ve ret devreye girer.

Kural Deny olduğu için kimliği ne olursa olsun herkese uygulanır. Principal alanındaki yıldız burada kovayı açmaz, tersine herkesi kısıtlar. Kaynak listesine hem kovayı hem de kovadaki nesneleri yazarsın. Yalnız nesneleri yazarsan listeleme gibi kova düzeyi istekler kuralın dışında kalır.

AWS Config'in s3-bucket-ssl-requests-only kuralı bu ifadenin varlığını sürekli denetler. CloudTrail kaydındaki tlsDetails alanı da isteğin TLS sürümünü gösterir. Bu alan yoksa ve isteği bir AWS servisi senin adına yapmadıysa, istek şifresiz gelmiş olabilir.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::lab-veri", "arn:aws:s3:::lab-veri/*"],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

Aktarım şifrelemesi tek bacakta bitmez. İstemciden yük dengeleyiciye, oradan uygulamaya, uygulamadan veritabanına giden her bacak ayrı düşünülür. Dış bacakta TLS kurup iç bacakta düz metin bırakmak yaygın bir eksiktir.

Veritabanı bağlantısında TLS zorunluluğunu sunucu tarafında açarsın; RDS for PostgreSQL'deki rds.force_ssl parametresi buna bir örnektir. Yük dengeleyicinin güvenlik politikası da önemlidir. Application Load Balancer'da konsol, yeni dinleyiciye TLS 1.3 ve kuantum sonrası anahtar değişimi destekleyen bir politika seçer.

CLI, CloudFormation ya da CDK ile politika belirtmezsen ELBSecurityPolicy-2016-08 gelir. Bu eski politika TLS 1.0 ve 1.1'i de kabul eder. Kodla kurduğun altyapıda politika adını bu yüzden açıkça yazarsın.

Şifrelemenin en çok yanlış anlaşılan yanı sınırıdır. Şifreleme bir erişim denetimi değildir. S3, sunucu tarafı şifrelemede veriyi isteği yetkili bulduğu herkese çözülmüş verir.

Saldırgan bir web uygulamasındaki SSRF açığıyla sunucunun rolünü ele geçirirse, o rolün okuyabildiği her nesneyi düz metin alır. Diskteki şifreleme bu senaryoda hiçbir şey değiştirmez. SSE-KMS burada küçük ama değerli bir fark yaratır.

Rolün hem s3:GetObject hem de anahtar üzerinde kms:Decrypt izni olmalıdır. Anahtar politikası dar tutulursa geniş S3 yetkisi tek başına yetmez. Her çözme çağrısı da CloudTrail'e düşer ve olağandışı kullanım görünür olur. Şifreleme bu yüzden dar politikalarla birlikte kurulur.

İkinci soru anahtarın kimde olduğudur. SSE-S3'te anahtarı sağlayıcı yönetir ve ona dokunamazsın. Müşteri yönetimli bir KMS anahtarında politikayı, dönüşü ve devre dışı bırakmayı sen yönetirsin. Anahtarı devre dışı bıraktığın an, ona bağlı veriye erişim tek hamlede kesilir.

İstemci tarafı şifrelemede sağlayıcı düz metni hiç görmez. Düzenleyici gereklilikler bazen kendi anahtarını zorunlu kılar. Bu karar teknik değil kurumsaldır ve sözleşmeye yazılır.

Yanlış varsayım denetimde ortaya çıkar ve düzeltmesi yeniden şifreleme ister. Bir de şunu unutma: yazma yetkisi olan saldırgan veriyi kendi anahtarıyla da şifreleyebilir. SSE-C bunun en açık örneğidir. S3 anahtarı saklamaz, saldırganın anahtarıyla yeniden şifrelenen veriyi sen de çözemezsin.

Blok depolamada kurallar daha katıdır. EBS'te şifreleme durumu birim oluşturulurken belirlenir. Var olan şifresiz bir birimi ya da anlık görüntüyü doğrudan şifreleyemezsin.

Şifresiz birim için önce anlık görüntü alırsın, sonra o görüntüden şifreli yeni bir birim açarsın. Şifresiz bir anlık görüntüyü ise şifreli olarak kopyalar ve eskisini silersin. Ters yön de kapalıdır: şifreli birimden ya da görüntüden şifre kaldırılamaz.

Varsayılan EBS şifrelemesi bölge başına açılan bir hesap ayarıdır. Açıkken yeni birimler ve şifresiz görüntüden alınan kopyalar şifreli doğar. Ayarı her bölgede ayrı açarsın. Veritabanı anlık görüntülerinde mantık aynıdır: şifreli kopya alır ve ondan geri yüklersin.

Şifrelemeyi açmak yetmez, açık olduğunu kanıtlaman gerekir. 6698 sayılı KVKK'nın 12. maddesi, veri sorumlusuna uygun güvenlik düzeyi için gerekli teknik ve idari tedbirleri alma yükümlülüğü getirir. Denetçi şifrelemenin açık olup olmadığını değil, bunu nasıl doğruladığını sorar.

Doğru cevap otomatik bir kontroldür. AWS Config kuralları kovaları, birimleri ve veritabanlarını sürekli tarar ve uymayan kaynağı listeler. S3 Inventory raporu her nesnenin şifreleme durumunu bir dosyaya döker.

Şifreli kaynakların oranı zamanla izlenir ve istisnaların yazılı gerekçesi bulunur. Kalıcı çözüm, kaynakların baştan şifreli doğmasıdır. Hesap düzeyi varsayılanları açarsın ve altyapı şablonlarına şifreleme satırını yazarsın.