Sevgili Bucket: Başkası Bulmadan Önce Sırlarını Güvende Tutmak, Veri Koruma - 1. Bölüm

Bu diziyi takip ediyorsanız, bunun nereye varacağını zaten biliyorsunuzdur. Gereksiz ayrıntılar yok, pazarlama sunumları yok; sadece Güvenlik Uzmanı rozetine ulaşmak için her bir alanı tek tek ele alırken gerçekten tuttuğum notlar var.

Bu sefer, bu yolda en zorlu alanlardan biri olan Veri Koruması konusuna dalıyoruz. Tek seferde ele alınacak çok fazla konu var, bu yüzden konuyu iki bölüme ayırıyorum. 1. Bölümde S3 yetkilendirme, S3 şifreleme (sunucu tarafı ve istemci tarafı) ve Amazon Macie ele alınacak. 2. Bölümde ise KMS'nin iç işleyişi, CloudHSM, Secrets Manager ve Certificate Manager ele alınacak.

Hadi başlayalım 🙌

S3 Yetkilendirme: Bucket Politikaları ve ACL’ler

S3, IAM'den ayrı kendi yetkilendirme katmanına sahiptir ve bu katman iki türde gelir:

Bucket Politikaları: JSON belgeleri, yapısal olarak IAM politikalarıyla neredeyse aynıdır, ancak önemli bir fark vardır. Bunlar, Principal öğesini içerir. Bir bucket politikası bir kullanıcıya veya role bağlı olmadığından, kimin hakkında olduğunu açıkça belirtmesi gerekir. Bucket politikaları, tüm bucket’a (ve içindeki her şeye) uygulanır ve Koşulları destekler; IP kısıtlamaları, MFA gereksinimleri gibi ince ayarlı denetimleri düşünün.

ACL'ler (Erişim Kontrol Listeleri): daha eski ve daha kaba bir araçtır. JSON yoktur, koşullar yoktur, açıkça reddetme yoktur. Önceden tanımlanmış dört yetki sahibi arasından birine izinler seçersiniz:

• Bucket Sahibi: tam kontrol, her zaman
• Herkes: genel erişim (oturum açmış veya açmamış)
• Kimliği Doğrulanmış Kullanıcılar: herhangi bir hesaptan oturum açmış herhangi bir AWS kimliği
• S3 Günlük Dağıtım Grubu: kova erişim günlüklerini depoladığında kullanılır

Kullanıcıların kafasını karıştıran temel fark şudur: depo düzeyinde, ACL'ler Liste ve Yazma işlemlerini destekler. Nesne düzeyinde ise Yazma izni hiç yoktur; yalnızca Nesneyi Oku ve nesnenin kendi ACL'sinde Oku/Yazma izni vardır.

Uygulamada: Bir nesne ACL'si, o nesneyi kimin okuyabileceğini kontrol etmenizi sağlar, ancak nesnenin içeriğini üzerine yazmak için kullanamazsınız; bunu yalnızca bir depo politikası veya IAM sağlayabilir.

Çakışma Kuralı: AWS Kimin Kazanacağına Nasıl Karar Verir?

Sınavda sürekli karşımıza çıkan senaryo şudur: Bir asıl kullanıcı bir IAM grubundadır, kova için bir politika vardır ve ayrıca bir nesne ACL’si de mevcuttur. Üç potansiyel kural kümesi vardır ve bunlar birbiriyle çelişebilir. Peki hangisi geçerli olur?

AWS bunu tek ve net bir kural ile çözer:

Varsayılan olarak, her şey reddedilir. Erişim sağlamak için herhangi bir yerde (IAM, kova politikası veya ACL) bir “İzin Ver” kuralı gereklidir. Ancak zincirin herhangi bir yerinde tek bir açık “Reddet” kuralı varsa, kaç tane “İzin Ver” kuralı olursa olsun, bu kural tüm “İzin Ver” kurallarını geçersiz kılar.

Şu sıralamayı ezberleyin: Reddet > İzin Ver > Varsayılan Reddet. Bu mantık, AWS’nin her yerinde (IAM, KMS anahtar ilkeleri, SCP’ler) tekrar eder; bu nedenle bu konuyu iyice kavramak, sınavın tamamında size fayda sağlayacaktır.

S3 Sunucu Tarafı Şifreleme: SSE-S3, SSE-KMS, SSE-C

Aynı hedef, oraya ulaşmak için üç çok farklı yol.

SSE-S3: “sadece yükle” seçeneği. AWS anahtarları oluşturur ve değiştirir, sizin yapmanız gereken hiçbir şey yoktur. Ocak 2023’ten itibaren bu, açık istekle şifrelenmiş olsun ya da olmasın, S3’e yüklenen her nesne için varsayılan ayardır.

SSE-KMS: Anahtar yönetimini dahili olarak S3 yerine KMS’ye devreder. Bu size şunları sağlar:

• AWS tarafından yönetilen bir KMS anahtarı ile müşteri tarafından yönetilen bir anahtar arasında seçim yapma imkanı (tam kontrol: değiştirme, devre dışı bırakma, anahtar ilkeleri)
• CloudTrail aracılığıyla tam denetim izi
• İhtiyacınız olacak iki IAM izni: kms:GenerateDataKey (şifrelemek için) ve kms:Decrypt (şifreyi çözmek için)

SSE-C: Kendi anahtarınızı kullanırsınız. Tek sorun: Yalnızca HTTPS üzerinden çalışır. Anahtarı düz HTTP üzerinden gönderirseniz, S3 isteği doğrudan reddeder. S3, doğrulama amacıyla anahtarınızın tuzlu HMAC'sini depolar, ancak anahtarın kendisini asla depolamaz.

SSE-S3 ve SSE-KMS'nin temelindeki mekanizma aynı zarf şifreleme modelidir: nesnenizin gerçek şifrelemesini düz metin bir veri anahtarı yapar ve bu düz metin anahtar da bir ana anahtar (S3'ün kendi anahtarı veya KMS'nin anahtarı) ile şifrelenir. Düz metin sürümü asla diske yazılmaz; görevini yerine getirecek kadar süreyle bellekte kalır, ardından silinir.

Bucket Anahtarları: Kimsenin Bahsetmediği Maliyet Tasarrufu Hilesi

Her KMS API çağrısının bir maliyeti vardır. Kova Anahtarları bu faturayı ortadan kaldırır.

SSE-KMS’nin yarattığı ve kimsenin önceden bahsetmediği bir sorun şudur: Her bir nesne şifreleme veya şifre çözme çağrısı, KMS’ye bir gidiş-dönüş anlamına gelir. Büyük ölçekte, milyonlarca nesne söz konusu olduğunda, bu çok sayıda faturalandırılabilir API çağrısı demektir.

Bucket Keys bu sorunu çözer. S3, her nesne için KMS’den yeni bir veri anahtarı istemek yerine, KMS’den tek bir kova düzeyinde anahtar ister ve ardından sonraki her nesne için bu kova anahtarını kullanarak yerel olarak veri anahtarları oluşturur. Sonuç: Gerçek güvenlik durumunuzda hiçbir değişiklik olmadan KMS istek maliyetlerinde %99’a varan bir azalma. Bu, sadece sınav için değil, gerçek hayattaki AWS faturaları açısından da “bilmemek pahalıya mal olur” türünden gerçeklerden biridir.

İstemci Tarafı Şifreleme: CSE-KMS ve CSE-C

Verileriniz S3’e ulaştığında, zaten okunamaz durumdadır ve S3 bunun farkında bile değildir.

Bazen gereksinim “S3’te şifrele” değil, “dizüstü bilgisayarımdan/sunucumdan ayrılmadan önce şifrele” şeklindedir. İşte bu, S3 Şifreleme İstemcisi aracılığıyla gerçekleştirilen istemci tarafı şifrelemedir (CSE).

Buradaki temel kavram zarf şifrelemedir ve KMS, SSE ve CSE'nin hepsi buna dayandığı için bu kavramı iyice kavramak önemlidir:

1. Benzersiz bir düz metin veri anahtarı oluşturulur ve nesnenizi şifrelemek için kullanılır
2. Bu veri anahtarı, bir sarmalama anahtarı ile sarılır (şifrelenir)
3. Düz metin veri anahtarı bellekten silinir
4. Hem şifrelenmiş nesne hem de şifrelenmiş veri anahtarı S3’e yüklenir

İki tür sarmalama anahtarı vardır:

• CSE-KMS: sarma anahtarı KMS'den gelir (kmsKeyId parametresi)
• CSE-C: Kendi sarma anahtarınızı sağlarsınız ve bu anahtar ham AES-GCM veya RSA anahtarı olmalıdır

Önemli nokta: S3, istemci tarafında şifrelenmiş nesneler hakkında hiçbir bilgiye sahip değildir. S3 için bunlar sadece baytlardan ibarettir. Bu durum, Macie devreye girdiğinde büyük önem kazanır: Macie, nesne içeriğini hassas veriler açısından tarar ve bu içerik yüklemeden önce istemci tarafında şifrelenmişse, Macie yalnızca şifreli metni görür, içindeki hiçbir şeyi işaretleyemez. Okumaya devam edin.

Amazon Macie: Otomatik Veri Gizliliği Dedektifiniz

Kuruluşunuzdaki her S3 kovasında kredi kartı numaralarını aramak için bir komut dosyası yazabilirsiniz. Ya da bu işi Macie’ye bırakabilirsiniz.

Macie, S3 depolarınızı kişisel olarak tanımlanabilir bilgiler (PII), finansal veriler, kimlik bilgileri ve diğer hassas içerikler açısından tarayan ve bu süreçte güvenlikle ilgili yanlış yapılandırmaları işaretleyen, yönetilen bir makine öğrenimi ve örüntü eşleştirme hizmetidir.

Kova düzeyinde izleme: Macie, beş belirli bulgu türünü izler:

• S3 depolama havuzunda genel erişim devre dışı
• S3 depolama kutusu şifrelemesi devre dışı
• S3 kovası herkese açık
• S3 kovası harici olarak çoğaltılmış
• S3 kovası harici olarak paylaşılmış

Son ikisi birbirine benziyor gibi görünse de aslında farklıdır: "harici olarak çoğaltıldı" ifadesi, S3 çoğaltma kurallarının nesneleri AWS hesabınız veya kuruluşunuz dışındaki bir depoya gönderdiği anlamına gelirken, "harici olarak paylaşıldı" ifadesi, depo politikası veya ACL'nin hesabınız dışındaki bir kullanıcıya erişim izni verdiği anlamına gelir; bu durumda çoğaltma söz konusu değildir.

Gözden kaçması kolay bir nüans: Macie, yalnızca etkinleştirildikten sonra meydana gelen değişiklikleri işaretler. Macie'yi etkinleştirmeden önce deponuzda şifreleme devre dışı bırakılmışsa, bu durum geriye dönük olarak işaretlenmez. Bulgular 90 gün boyunca saklanır ve API, EventBridge veya Security Hub aracılığıyla Macie konsolunda görüntülenir.

Hassas Veri Keşif İşleri: daha derinlemesine tarama. Bu işler, AWS’nin yerleşik yönetilen veri tanımlayıcılarını veya kendi özel tanımlayıcılarınızı (regex olarak yazılmış) kullanarak finansal bilgiler, kişisel tanımlayıcı bilgiler (PII), ulusal kimlik numaraları, tıbbi veriler ve kimlik bilgilerini arar. İşler tek seferlik olarak veya günlük/haftalık/aylık bir zamanlamaya göre çalıştırılabilir.

İşte yukarıdaki şifreleme bölümüyle doğrudan bağlantılı olan kısım. Macie’nin verilerinizi gerçekten okuyabilmesi, tamamen verilerin nasıl şifrelendiğine bağlıdır:

Şifreleme Türü / Macie bunu analiz edebilir mi?

• SSE-S3: Evet, sorun yok
• SSE-KMS (AWS tarafından yönetilen anahtar): Evet, sorun yok
• SSE-KMS (müşteri tarafından yönetilen anahtar): Yalnızca anahtar politikası aracılığıyla Macie’ye açıkça erişim izni verirseniz
• SSE-C: Hayır, yalnızca meta veriler
• İstemci tarafında şifreleme: Hayır, yalnızca meta veriler

Düşündüğünüzde mantıklı geliyor: Macie anahtarı alamazsa şifreyi çözemez ve şifreyi çözemezse, tek yapabileceği orada bir şey olduğunu not etmektir.

Maliyet üç eksende işler: değerlendirme için her depo başına aylık sabit 0,10 $; nesne envanterinizi otomatik keşif izliyorsa her 100.000 nesne başına aylık 0,01 $; ve keşif işlerinde ilk 50.000 GB/ay için 1 $/GB'den başlayan kademeli bir ölçek. Ortadaki rakam, içerik taramasıyla değil, sadece nesneleri saymakla ilgili olduğu için gözden kaçması kolaydır; ancak yüz milyonlarca küçük dosya içeren bir veri gölü veya merkezi bir günlük kovası işletiyorsanız, bu maliyet diğer ikisinin toplamını sessizce aşabilir. Haftada bir terabayt tararsanız, aylık yaklaşık 4.000 $'lık bir maliyetle karşı karşıya kalırsınız; bu önemsiz bir rakam değildir, ancak bir güvenlik ihlali manşetinden çok daha ucuzdur.

Tüm bunların ortak noktası varsa, o da şifreleme yöntemi seçiminin sadece bir güvenlik kararı değil, aynı zamanda operasyonel bir karar olduğudur. SSE-C, Macie’yi devre dışı bırakır. Müşteri tarafından yönetilen KMS anahtarları için açık bir paylaşım gerekir. Bucket Keys ise fark edilmeden size binlerce dolar tasarruf ettirir. Bunların hiçbiri, uçtan uca bir şekilde ortaya konana kadar açıkça görülmez.

Devam edecek…

2. Bölüm’de, tüm bunların arkasındaki mekanizmayı daha derinlemesine inceleyeceğiz: KMS’nin anahtarlarını gerçekte nasıl yapılandırdığı, CloudHSM’nin KMS’ye kıyasla (önemli) fiyat etiketini ne zaman hak ettiği, Secrets Manager’ın hesaplar arası paylaşımı nasıl yönettiği ve Certificate Manager’ın süresi dolmuş sertifikalardan kaynaklanan kesintilerden sizi nasıl sessizce kurtardığı.

2. Bölüm’de görüşmek üzere.

Kaynaklar

• Amazon S3 için depo ilkeleri
• Amazon S3'te erişim denetimi
• Şifreleme ile verileri koruma
• Amazon S3 yönetilen anahtarlarıyla sunucu tarafı şifrelemeyi kullanma (SSE-S3)
• AWS KMS anahtarlarıyla sunucu tarafı şifrelemeyi kullanma (SSE-KMS)
• Müşteri tarafından sağlanan anahtarlarla sunucu tarafı şifreleme kullanma (SSE-C)
• Amazon S3 Kova Anahtarları ile SSE-KMS maliyetini düşürme
• İstemci tarafı şifrelemeyi kullanarak verileri koruma
• Amazon Macie nedir?
• Yönetilen veri tanımlayıcılarını kullanma
• Amazon Macie fiyatlandırması
• AWS Sertifikalı Güvenlik — Uzmanlık (SCS-C03) Sertifikasyon Hazırlığı

Orijinal: https://medium.com/@0gulcandogan/my-dear-bucket-locking-down-your-secrets-before-someone-else-finds-them-data-protection-part-1-c5226954559e?source=rss-746132cb79a8------2