Vault’un Koruyucuları: Anahtarları Gerçekte Kim Elinde Tutuyor? Veri Koruma – 2. Bölüm

Merhaba arkadaşlar,

1. Bölümde Amazon S3 yetkilendirme, S3 şifreleme ve Amazon Macie konularını ele aldık. Bu sefer ise konuyu bir adım daha ileriye taşıyacağız.

İlk bakışta, bu seride ele aldığımız her şeyin tek bir amacı varmış gibi görünebilir: verileri şifrelemek. Bu doğru olsa da, çok daha büyük bir resim var. Bu makalenin sadece şifreleme anahtarlarını oluşturan, depolayan ve koruyan hizmetler hakkında olduğunu düşünebilirsiniz. Kısmen haklısınız. Amacım, size sıfırdan güvenli bir mimariyi nasıl kuracağınızı göstermek. Sadece hizmetlerin kendilerini değil, aynı zamanda bunların güçlü bir güvenlik temeli oluşturmak için nasıl birlikte çalıştıklarını da inceleyeceğiz.

Burada ele alınan her şey, AWS Certified Security Specialty (SCS-C03) sertifikasyonu için pratik bir kılavuz görevi de görüyor; bu sayede sadece sınav konularını değil, aynı zamanda bu hizmetlerin gerçek AWS ortamlarında nasıl kullanıldığını da anlamanıza yardımcı oluyor.

Bu makalede, AWS Key Management Service (AWS KMS), AWS CloudHSM, AWS Secrets Manager ve AWS Certificate Manager (ACM) hizmetlerinin iç işleyişini derinlemesine inceleyeceğiz. Umarım hazırsınızdır — hadi başlayalım.

Başlayalım! 🔥

KMS Anahtar Türleri: Aslında Kim Neye Sahip?

Sormanız gereken ilk soru şudur: Anahtar aslında nedir? Şifrelenmiş verilerin kilidini açan basit bir 1 ve 0 dizisi mi, yoksa KMS Anahtarı, Veri Anahtarı, Veri Anahtar Çifti veya HMAC Anahtarı gibi daha spesifik bir şey mi?

İkinci soru ise, o anahtarın sahibi ve yöneticisinin kim olduğudur. Daha önce “İnsan Dışı Kimlikler” başlıklı makalemi okuduysanız, sahipliğin anahtarın kendisi kadar önemli olduğunu zaten biliyorsunuzdur.

Bunlar tamamen farklı iki kavramdır ve er ya da geç muhtemelen kendinize “Hangi anahtar bana aitti?” diye sorarken bulacaksınız. Bu karışıklığı önlemek için önce anahtar sahipliğine bir göz atalım.

Sahiplik açısından KMS Anahtarları üç kategoriye ayrılır:

• Müşteri Tarafından Yönetilen Anahtar: Sizin tarafınızdan oluşturulur. İzinler, anahtarın yaşam döngüsü, anahtarın etkinleştirilmesi veya devre dışı bırakılması, rotasyon, etiketler, takma adlar ve silme işlemleri üzerinde tam kontrol sahibi olursunuz.
• AWS Tarafından Yönetilen Anahtar: Verilerinizi korumak için Amazon S3 veya Amazon RDS gibi AWS hizmetleri tarafından otomatik olarak oluşturulur. Bu anahtarlar, aws/rds gibi aws/hizmet-adı adlandırma kuralını izler. Anahtarı ve Anahtar Politikasını görüntüleyebilirsiniz, ancak anahtarın rotasyonunu yönetemez, Anahtar Politikasını değiştiremez veya anahtarı silemezsiniz.
• AWS'ye Ait Anahtar: Tamamen AWS'ye aittir ve AWS tarafından yönetilir. Bu anahtarlar birden fazla AWS hesabı arasında paylaşılır ve hesabınızla ilişkilendirilmez. Bu anahtarları göremez, yönetemez veya bunlarla etkileşimde bulunamazsınız. Bu anahtarlar, AWS tarafından yönetilen hizmetler için şifreleme sağlamak üzere arka planda çalışır.

Simetrik ve Asimetrik KMS Anahtarları

Varsayılan olarak, bir KMS Anahtarı simetrik bir anahtardır. 256 bitlik AES-GCM algoritmasını kullanır ve AWS KMS'den asla dışarı çıkmaz. Sizin adınıza verileri şifreleyen neredeyse tüm AWS hizmetleri bu simetrik anahtar modeline dayanır.

Asimetrik bir KMS Anahtarı da oluşturabilirsiniz. Bu durumda, AWS KMS bir açık anahtar ve özel anahtar çifti oluşturur. Özellikle sertifika sınavlarında ve senaryo tabanlı sorularda sıklıkla gözden kaçan bir ayrıntı, asimetrik bir anahtarın ya şifreleme ya da dijital imzalama için kullanılabileceğidir; ancak asla her ikisi için aynı anda kullanılamaz.

Bu modelde, açık anahtar AWS KMS'den güvenli bir şekilde dışarı çıkabilir ve hatta indirilebilir. Ancak özel anahtar, hiçbir zaman düz metin olarak AWS KMS'den dışarı çıkmaz. AWS KMS, özel anahtarı her zaman hizmet içinde güvende tutar.

Veri Anahtarları ve Veri Anahtar Çiftleri (Aynı Ad, Farklı Anlam)

Veri Anahtarları bir KMS Anahtarı tarafından oluşturulabilir, ancak AWS KMS dışında kullanılmak üzere tasarlanmıştır. En yaygın kullanım alanı, AWS Şifreleme SDK'sı ile istemci tarafında şifreleme yapmaktır.

GenerateDataKey API'si, aynı anahtarın iki sürümünü döndürür: bir düz metin sürümü ve bir şifreli sürüm. Buna karşılık, GenerateDataKeyWithoutPlaintext yalnızca şifreli sürümü döndürür. Bu, genellikle verileri hemen şifrelemeniz gerekmediğinde tercih edilir.

İki sürümün alınması, bunun asimetrik bir anahtar gibi görünmesine neden olsa da, Veri Anahtarı yine de simetrik bir anahtardır. Her iki çıktı da aynı anahtar materyalini temsil eder. Biri düz metin halindeyken, diğeri bir KMS Anahtarı ile şifrelenmiştir.

Öte yandan, bir Veri Anahtar Çifti, AWS KMS dışında kullanılmak üzere tasarlanmış asimetrik bir anahtar çifti. Bu, istemci tarafında şifreleme, dijital imzalama ve imza doğrulama için tasarlanmıştır.

Desteklenen anahtar çifti türleri şunlardır:

• RSA (2048, 3072 ve 4096 bit): Genellikle sertifikalar ve genel amaçlı asimetrik şifreleme için kullanılır.
• ECC (NIST P-256, NIST P-384, NIST P-521 ve SECG P-256K1): Yüksek performanslı kriptografik işlemler için tercih edilir. SECG P-256K1 eğrisi, kripto para birimleriyle ilgili uygulamalarda yaygın olarak kullanılır.
• SM2: Yalnızca AWS Çin Bölgelerinde desteklenen bir Çin kriptografik standardıdır.

Bu modelde, özel anahtar, seçtiğiniz simetrik KMS Anahtarı kullanılarak şifrelenir ve güvenli bir şekilde depolanır.

Anahtar Döndürme: Arka Planda Aslında Neler Değişiyor

Otomatik Döndürme, AWS'nin önerdiği yaklaşımdır ve çoğu zaman kullanacağınız yöntem de budur. Bu özelliği etkinleştirdiğinizde, AWS tüm döndürme sürecini sizin adınıza halleder.

Unutulmaması gereken en önemli nokta şudur: Dönüşüm, KMS Anahtarının kendisini değiştirmez; yalnızca anahtar materyalini değiştirir. Uygulamalarınız aynı Anahtar Kimliğine başvurmaya devam eder, bu nedenle sizin açınızdan hiçbir şey değişmez. Anahtar Kimliği aynı kaldığından, uygulamalarınızı veya yapılandırmalarınızı güncellemenize gerek yoktur.

Peki, eski verilerinize ne olur?

İşte burada tasarım gerçekten zarif bir hal alıyor. AWS, anahtar materyalinin önceki tüm sürümlerini saklar; bu da, yıllar önce daha eski bir anahtar sürümüyle şifrelenmiş verileri hala şifresini çözebileceğiniz anlamına gelir.

Yeni verileri şifrelerken, hangi anahtar materyali sürümünün kullanılacağını seçemezsiniz. AWS, her zaman o anda etkin olan anahtar materyali kullanarak şifreleme yapar.

Son bir şey daha. AWS Yönetilen Anahtarı veya AWS'ye Ait Anahtar kullanıyorsanız, anahtar rotasyonu konusunda hiç endişelenmenize gerek yoktur. AWS bunu otomatik olarak halleder ve tüm süreci arka planda yönetir.

Anahtar İlkeleri ve Yetkiler: Erişimi Gerçekte Kim Kontrol Ediyor?

Şimdiye kadar, anahtarı kimin oluşturduğunu ve kimin sahibi olduğunu konuştuk. Peki, “Bu anahtarı aslında kim kullanabilir?” sorusuna ne demeli? İşte burada Anahtar İlkeleri devreye girer.

Anahtar Politikası, tek bir KMS Anahtarına eklenmiş, JSON tabanlı bir kaynak politikasıdır. Her KMS Anahtarının tam olarak bir Anahtar Politikası vardır ve bu politika genellikle dört ana bölümden oluşur.

İlk bölüm, AWS Hesap Kökü içindir. Bu, AWS KMS’nin en çok yanlış anlaşılan kısımlarından biridir. Kök kullanıcıya Şifrele veya Şifre Çöz gibi kriptografik işlemleri gerçekleştirme izni vermez. Bunun yerine, IAM Politikalarının o anahtar üzerinde izinler vermesine olanak tanır. Bu ifadeyi kaldırırsanız, IAM aracılığıyla verdiğiniz tüm İzin Ver (Allow) izinleri anında geçersiz hale gelir (Engelle (Deny) ifadeleri ise hâlâ çalışır). Ayrıca, kök hesabın kendisi asla silinemeyeceği için anahtarınızın kalıcı olarak erişilemez hale gelmemesini de sağlar.

İkinci bölüm, Anahtar Yöneticileri içindir. Bu kimlikler anahtarı yönetebilir. Anahtar Politikasını güncelleyebilir, anahtarı etkinleştirebilir veya devre dışı bırakabilir ya da silinmesi için zamanlayabilirler. Yapamayacakları şey ise, anahtarı Şifrele veya Şifre Çöz gibi kriptografik işlemler için kullanmaktır. Ancak burada önemli bir ayrıntı vardır. Anahtar Politikasını değiştirebildikleri için, ihtiyaç duydukları her an kendilerine anahtarı kullanma izni verebilirler.

Üçüncü bölüm, Anahtar Kullanıcıları içindir. Bunlar, anahtarı fiilen kullanan kimliklerdir. Şifreleme, Şifre Çözme, Yeniden Şifreleme, Veri Anahtarı Oluşturma ve Anahtar Tanımlama gibi şifreleme işlemlerini gerçekleştirebilirler.

Son bölümde ise Yetki Verme işlemleri oluşturabilirsiniz.

Bir İzin'i, birine evinizin anahtarını geçici olarak vermek olarak düşünebilirsiniz. Bu, belirli bir kimliğe, belirli bir KMS Anahtarı üzerinde belirli işlemleri gerçekleştirme konusunda geçici izin verir. Elbette, birkaç kural vardır.

İlk olarak, bir Yetki her zaman yalnızca bir KMS Anahtarı için geçerlidir. Yetki sahibi yalnızca bir IAM Kullanıcısı, IAM Rolü veya Federasyonlu Kullanıcı/Rol olabilir. Bir IAM Grubu, AWS Organizasyonu veya benzer kimlikler için Yetki oluşturamazsınız.

Bir diğer önemli kural ise, Grant'lerin yalnızca İzin (Allow) izinlerini desteklemesidir. Reddetme (Deny) Grant'i oluşturmanın bir yolu yoktur.

Ayrıca, AWS Yönetim Konsolu'ndan Grant oluşturamazsınız. Bunun yerine AWS API'sini, AWS CLI'yi veya bir AWS SDK'sını kullanmanız gerekir.

Son olarak, sertifika sınavlarında sıklıkla karşımıza çıkan küçük bir ayrıntı var. Bir Grant oluşturduktan sonra, AWS KMS’nin nihai tutarlılık modelini izlemesi nedeniyle kısa bir gecikme yaşayabilirsiniz. Grant’i hemen kullanmanız gerekiyorsa, bekleme süresini atlamak için Grant oluşturma sırasında döndürülen GrantToken’ı eklemeniz yeterlidir.

Erişim Bulmacası: Adım Adım Açıklama

Şimdi bunu basit bir senaryo ile anlayalım.

Üç farklı KMS Anahtarımız olduğunu varsayalım.

• Anahtar A, IAM İlkelerinin erişim izni vermesine izin verir.
• Anahtar B, IAM’yi tamamen göz ardı eder ve Anahtar Politikası aracılığıyla Danny ve Carlos’a doğrudan erişim izni verir.
• Anahtar C, IAM'ye izin verir, ancak Danny ve Carlos'u açıkça reddeder. Aynı zamanda, Alana ve Jorge'ye izin verir; Jorge'nin ayrıca "Grants" oluşturma izni de vardır.

Şimdi kimin neye erişebileceğine bir bakalım.

Alana ile başlayalım. Anahtar Politikası, IAM izinlerinin değerlendirilmesine izin verdiği ve IAM ona erişim izni verdiği için A Anahtarını kullanabilir. Ayrıca, Anahtar Politikasında açıkça izin verildiği için C Anahtarını da kullanabilir. Ancak, Anahtar B'yi kullanamaz çünkü bu anahtar IAM'yi tamamen göz ardı eder ve Alana, Anahtar Politikasında listelenmemiştir.

Sırada Danny var. O, yalnızca Anahtar B'yi kullanabilir çünkü Anahtar Politikasında açıkça izin verilmiştir. Anahtar C'de ise bir Açık Reddetme tarafından engellenmiştir ve bir Açık Reddetme mevcut olduğunda, başka hiçbir izin bunu geçersiz kılamaz.

Şimdi Carlos'a bakalım. A Anahtarı'nda IAM, ona yalnızca Şifreleme işlemini gerçekleştirme izni verir. B Anahtarı'nda ise Anahtar Politikası'nda doğrudan listelendiği için tam erişime sahiptir. Bu durumda, IAM izinlerinin ne olduğu önemli değildir çünkü B Anahtarı, IAM'yi hiç değerlendirmez. Anahtar C'de ise, tıpkı Danny gibi, Açık Reddetme kuralı nedeniyle engellenir.

Son olarak Jorge'ye gelelim. A Anahtarı veya B Anahtarı üzerinde hiçbir izni yoktur. Ancak C Anahtarı üzerinde, anahtarı kullanmak için tam erişim hakkına sahiptir ve ayrıca delege edilmiş erişim için Yetki Belirlemeleri oluşturmasına da izin verilmiştir.

Bu senaryodan tek bir şey hatırlayacaksanız, şunu unutmayın:

AWS KMS'de Anahtar Politikası, kapı bekçisidir.

IAM İlkeleri tek başlarına kapıyı açamaz. Öncelikle Anahtar Politikası, "Evet, IAM izinleri bu anahtara erişimi kontrol edebilir" demelidir. Anahtar Politikası bir Açık Reddetme içeriyorsa, süreç burada sona erer. Kimliğin AdministratorAccess veya başka herhangi bir IAM İzin iznine sahip olması fark etmez. Kapı kapalı kalır.

Bu kuralı anladığınızda, çoğu AWS KMS yetkilendirme senaryosunu çözmek çok daha kolay hale gelir.

CloudHSM: KMS Yeterli Olmadığında

Şimdiye kadar, kriptografik anahtarlarımızı AWS KMS ile güvenli bir şekilde yönetiyorduk. Peki ya bir gün biri size, “Anahtarlarımın AWS’nin paylaşımlı altyapısında bulunmasını istemiyorum. Yalnızca bana ait özel bir donanımda depolanmasını istiyorum,” derse ne olur? İşte tam da bu noktada AWS CloudHSM devreye girer.

Donanım Güvenlik Modülü (HSM), şifreleme anahtarlarını korumak için tasarlanmış, fiziksel ve kurcalanmaya dayanıklı bir cihazdır. AWS CloudHSM, FIPS 140–2 Seviye 3 sertifikasına sahiptir; bu da dijital imza işlemi gerçekleştiriyorsanız, kendi Sertifika Yetkililiğinizi (CA) işletiyorsanız veya katı yasal gereklilikleri karşılamanız gerekiyorsa bu hizmeti ideal bir seçim haline getirir.

CloudHSM ile AWS KMS arasındaki en büyük fark tek bir cümleyle özetlenebilir:

KMS’de, altta yatan donanım paylaşılır. CloudHSM’de ise donanım tamamen size aittir.

CloudHSM ile neler yapabilirsiniz?

• Kriptografik anahtarlar oluşturabilir ve güvenli bir şekilde saklayabilirsiniz.
• Anahtarları içe ve dışa aktarabilirsiniz.
• Hem simetrik hem de asimetrik şifreleme gerçekleştirebilirsiniz.
• Dijital imzalar oluşturun ve doğrulayın.
• Hash ve HMAC hesaplayın.
• Kriptografik olarak güvenli rastgele sayılar oluşturun.

CloudHSM nasıl çalışır?

Her şey bir Küme oluşturmakla başlar. Bir küme, yüksek kullanılabilirlik sağlamak için farklı Kullanılabilirlik Bölgelerine dağıtılmış birden fazla HSM'den oluşur. Bir küme oluşturmadan önce bir VPC'ye ihtiyacınız olacaktır.

Ayrıca, hatırlamaya değer küçük ama önemli bir ayrıntı daha vardır.

• Alt ağınızın içindeki bileşen, HSM'nin kendisi değildir.
• Alt ağınıza aslında yerleştirilen şey bir Elastik Ağ Arayüzüdür (ENI).
• Fiziksel HSM donanımı, aynı Kullanılabilirlik Bölgesi içindeki, AWS'ye ait ayrı bir VPC içinde çalışır.

Bir küme oluşturduğunuzda, AWS otomatik olarak:

• AWSServiceRoleForCloudHSM adlı bir Hizmet Bağlantılı Rol oluşturur.
• HSM'lerin TCP 2223–2225 numaralı bağlantı noktaları üzerinden birbirleriyle iletişim kurmasına izin veren özel bir Güvenlik Grubu oluşturur.

Bir EC2 örneğini CloudHSM kümenize bağlamak istiyorsanız, yapmanız gereken sadece iki şey vardır:

1. EC2 örneğini CloudHSM Güvenlik Grubuna ekleyin.
2. CloudHSM İstemci yazılımını yükleyin.

CloudHSM kullanıcı rolleri

CloudHSM'de dört adet yerleşik kullanıcı rolü bulunur.

• PRECO (Pre Crypto Officer): Küme ilk kez sağlandığında oluşturulan geçici bir kullanıcıdır. Şifresini değiştirdiğinizde, Crypto Officer olur.
• CO (Crypto Officer): Kullanıcıları yönetir, sıfırlama işlemini gerçekleştirir ve kümenin durumunu izler.
• CU (Crypto User): Anahtarları oluşturur, siler, içe aktarır, dışa aktarır ve paylaşır. Bu rol ayrıca Şifreleme, Şifre Çözme, İmzalama ve Doğrulama işlemlerini de gerçekleştirir.
• AU (Appliance User): Kümedeki tüm HSM'leri senkronize tutar. Bu rolle doğrudan etkileşime girmezsiniz.

Güvenlik özellikleri

Özellikle akılda tutulması gereken iki güvenlik özelliği vardır.

• Birisi HSM'ye fiziksel olarak müdahale ederse, saldırı algılanır ve içinde depolanan tüm kriptografik anahtarlar otomatik olarak silinir.
• Bir Crypto User yanlış şifreyi çok fazla kez girerse, hesap kilitlenir. Yalnızca bir Crypto Officer bu kilidi açabilir.

İzleme ve günlük kaydı

İzleme açısından, iki CloudWatch metriği özellikle yararlıdır:

• HsmUnhealthy: Bir HSM arızalanırsa, AWS bunu otomatik olarak değiştirir.
• HsmTemperature: Sıcaklık 110°C'yi aşarsa, HSM otomatik olarak kendini kapatır.

Günlük kaydı için iki ayrı hizmet vardır:

• AWS CloudTrail, tüm CloudHSM API çağrılarını kaydeder.
• CloudHSM Denetim Günlükleri, HSM üzerinde yürütülen her komutu kaydeder.

Son olarak, hatırlamaya değer bir ayrıntı daha var. CloudHSM Denetim Günlükleri devre dışı bırakılamaz. Ayrıca, bu günlüklerin CloudWatch Logs'a gönderilmesi zorunludur.

Secrets Manager: Sabit Kodlanmış Şifrelerin Kaldırılması

Secrets Manager, şifreleri, API anahtarlarını, veritabanı kimlik bilgilerini ve gizli kalması gereken diğer her şeyi merkezileştirir ve sabit kodlanmış değerleri basit bir API çağrısıyla değiştirir. Dönüşüm, RDS tarzı kimlik bilgileri için yerleşiktir ve Lambda aracılığıyla diğer her şeye genişletilebilir. Gizli bilgiler KMS ile şifrelenir ve etkinlikler CloudTrail ve CloudWatch aracılığıyla tamamen denetlenebilir.

Erişim, hem kimlik tabanlı IAM ilkeleri hem de gizli bilgiye doğrudan eklenmiş kaynak tabanlı ilkeler aracılığıyla sağlanır ve hesaplar arası paylaşımı mümkün kılan da bu ikinci seçenektir.

Bir sırrı hesaplar arasında paylaşmak üç adımda gerçekleşir. İlk olarak, kullanıcının bulunduğu hesapta, sırrın ARN'sine secretsmanager:GetSecretValue ve KMS anahtarının ARN'sine kms:Decrypt izni veren bir satır içi ilke ekleyin. İkinci olarak, sırrı barındıran hesapta, KMS anahtarı ilkesini düzenleyerek söz konusu kullanıcıya kms:Decrypt ve kms:DescribeKey izinlerini verin. Üçüncü olarak, yine sırrı barındıran hesapta, sırrın kendisine GetSecretValue izni veren kaynak tabanlı bir ilke ekleyin; ancak bu son adımın CLI aracılığıyla gerçekleştirilmesi gerekir, çünkü konsol bunu desteklemez.

Sertifika Yöneticisi: Otomatik Güven

Şimdiye kadar, kriptografik anahtarlarımızı nasıl oluşturacağımızı, yöneteceğimizi ve koruyacağımızı öğrendik. Peki, bu anahtarları kullanan sunucunun gerçekten güvenilir olduğunu nasıl anlarız? İşte burada Dijital Sertifikalar devreye girer.

Dijital sertifika, bir Açık Anahtara güvenebileceğimizi kanıtlar. Bu güven, bir Sertifika Yetkilisi (CA) tarafından sağlanır.

İki ana Sertifika Yetkilisi türü vardır.

• Genel CA: Tarayıcılar ve işletim sistemleri tarafından varsayılan olarak güvenilir kabul edilir. Sertifika düzenleme maliyeti vardır ve bunlar internete açık uygulamalar için kullanılır.
• Özel CA: Burada işler biraz farklı yürür. Kimse, bu otoritenin verdiği sertifikalara güvenebilmesi için önce Kök Sertifikayı güvenilir bir sertifika deposuna (Trusted Store) yüklememiz gerekir. Sertifika vermek esasen ücretsiz olsa da, tüm PKI altyapısını kendimiz yönetmekle sorumluyuz. Bu nedenle Özel CA'lar genellikle sadece iç sistemler için kullanılır.

Hatırlamaya değer başka bir kavram daha vardır: Sertifika İptal Listesi (CRL).

Her Sertifika Yetkilisi, artık güvenilir olmayan sertifikaların bir listesini yayınlar. Bu sayede, iptal edilmiş veya güvenliği ihlal edilmiş sertifikalar istemciler tarafından otomatik olarak reddedilir.

İşte tam da bu noktada AWS Sertifika Yöneticisi (ACM), işleri çok daha kolaylaştırır.

ACM ile şunları yapabiliriz:

• Ücretsiz Genel Sertifikalar talep edebiliriz.
• Genel/Özel Anahtar Çiftleri ve Sertifika İmzalama İstekleri (CSR'ler) oluşturma işlemini manuel olarak yapmamıza gerek kalmaz.
• Kendi Sertifika Yetkilisi altyapımızı yönetmekten kurtulabiliriz.
• AWS'nin sertifikalarımızı otomatik olarak yenilemesine izin vererek, "Sertifikanın süresi doldu ve kimse fark etmedi" gibi klasik kesintileri önleyebiliriz.

İşte kolayca unutulabilen ve sertifika sınavlarında sıklıkla karşımıza çıkan bir ayrıntı.

AWS Certificate Manager bölgesel bir hizmettir!!!!

Örneğin, eu-west-2 bölgesindeki bir Uygulama Yük Dengeleyicisi (ALB) için sertifika talep ediyorsak, sertifikanın da eu-west-2 bölgesinde oluşturulması gerekir.

Bununla ilgili önemli bir istisna vardır.

Amazon CloudFront kullanıyorsak, dağıtımın trafiği gerçekte nereden sunduğuna bakılmaksızın sertifika her zaman us-east-1 (Kuzey Virginia) bölgesinde bulunmalıdır.

Peki, bir Genel Sertifika talep ederken nelere ihtiyacımız var?

Sadece iki şeye:

• Güvenliğini sağlamak istediğimiz alan adları.
• Bir doğrulama yöntemi.

Etki alanı sahipliğini doğrulamanın iki yolu vardır.

• DNS Doğrulama: Alan adımıza bir CNAME kaydı ekleriz. Amazon Route 53 kullanıyorsak, ACM bu kaydı bizim için otomatik olarak oluşturabilir.
• E-posta Doğrulama: ACM, alan adının WHOIS kaydında listelenen iletişim adreslerine doğrulama e-postaları gönderir. Bu e-postalardan birini onaylamak için 72 saatimiz vardır.

Peki ya kendi Özel Sertifikalarımızı vermek istersek?

Bu durumda, önce ACM Özel Sertifika Otoritesini (Özel CA) devreye almamız gerekir.

Bunun için basit bir sertifika hiyerarşisi oluşturmamız gerekir.

• Kök CA: Kendi Kendine İmzalı Sertifikasını oluşturur, ancak son kullanıcı sertifikalarını asla doğrudan düzenlemez.
• Alt CA: Kök CA tarafından imzalanır ve uygulamalarımızın fiilen kullanacağı sertifikaları vermekten sorumludur.

Son olarak, hatırlanması gereken bir nokta daha var.

ACM Özel CA ücretsiz değildir. Oluşturduğumuz her Sertifika Yetkilisi için aylık bir ücret öderiz; ayrıca, bu yetkilinin verdiği her sertifika için ek bir ücret de öderiz.

Bu nedenle Özel CA, müşteriye yönelik internet uygulamaları için değil, bir kuruluş içindeki iç güven için tasarlanmıştır.

Son Dans

Bu bölümde ele aldığımız her hizmet, aynı temel soruyu farklı bir bakış açısıyla yanıtlar: Anahtarlarımızı kime emanet etmeliyiz ve bu güvenin ne kadarını devretmeye hazırız?

• AWS KMS: Altta yatan HSM altyapısı hakkında endişelenmeden kriptografik anahtarlarınızı güvenli bir şekilde yönetmek istiyorsanız, AWS bunu sizin için halleder.
• AWS CloudHSM: Anahtarlarınız üzerinde tam sahiplik ve kontrol sahibi olmak istiyorsanız, CloudHSM size tamamen size ait özel bir HSM donanımı sunar.
• AWS Secrets Manager: Şifreleri ve API anahtarlarını uygulamalarınıza sabit olarak kodlamak yerine, bunları güvenli bir şekilde depolamanıza ve hatta gerektiğinde otomatik olarak değiştirmenize olanak tanır.
• AWS Certificate Manager (ACM): Sertifika sağlama ve yenileme işlemlerini otomatikleştirerek, uygulamalarınızın her zaman güvenilir TLS bağlantıları kullanmasını sağlar.

Şimdiye kadar, veri korumanın sadece verileri şifrelemekten çok daha fazlası olduğunu gördük. Aynı zamanda şifreleme anahtarlarımızı, gizli bilgilerimizi ve sertifikalarımızı doğru şekilde yönetmek anlamına da gelir.

Bu noktaya kadar okuduğunuz ve bu makaleyi okumak için zaman ayırdığınız için çok teşekkür ederim.

Bir sonraki bölümde görüşmek üzere. O zamana kadar kendinize iyi bakın. 💛

Kaynakça

• KMS Anahtar Türleri (Müşteri Tarafından Yönetilen, AWS Tarafından Yönetilen, AWS'ye Ait)
• KMS Anahtar İlkeleri
• KMS Yetkileri
• AWS CloudHSM'ye Başlarken (Kümeler, VPC, ENI Kurulumu)
• AWS CloudHSM CLI Kullanıcı Yönetimi (PRECO, CO, CU Rolleri)
• AWS Secrets Manager Hesaplar Arası Erişim Eğitimi
• AWS Secrets Manager Hesaplar Arası Erişim (Kaynak Politikası ve KMS Anahtar Politikası Örnekleri)
• AWS Certificate Manager (ACM) Başlangıç Kılavuzu (Genel ve Özel Sertifikalar)
• AWS Certificate Manager Özel CA (Özel Sertifikalar)
• Amazon CloudFront SSL/TLS Sertifika Gereksinimleri (us-east-1 Gereksinimi)
• AWS Sertifikalı Güvenlik — Uzmanlık (SCS-C03) Sertifikasyon Hazırlığı

Orijinal: https://medium.com/@0gulcandogan/guardians-of-the-vault-who-really-holds-the-keys-data-protection-part-2-e1f58382d933?source=rss-746132cb79a8------2