Cloud Key Management Service'ın ayrıntılı incelemesi

Yazarlar: Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer, Honna Segel, Dwight Worley

Teşekkür: Adrian Sears, John Randolph, Tim Dierks, Chris Rezek, Stanley McKenzie, Kevin Plybon, David Hale, Sergey Simakov, David U. Lee, Carrie McDaniel, Anton Chuvakin, Dave Tonisson

Son güncelleme zamanı: Nisan 2020

1. Giriş

Google Cloud'un çalışma prensibi, verilerin Google Cloud müşterilerine ait olduğu ve nasıl kullanıldıklarını müşterilerin kontrol etmesi gerektiği temellerine dayanır.

Verileri Google Cloud ile depoladığınızda verileriniz varsayılan olarak kullanımda değilken şifrelenir. Cloud Key Management Service (Cloud KMS) platformumuzu kullandığınızda verilerinizin kullanımda değilken nasıl şifrelendiği ve şifreleme anahtarlarınızın nasıl yönetildiği üzerinde daha fazla kontrol sahibi olabilirsiniz.

Cloud KMS platformu, Google Cloud müşterilerinin şifreleme anahtarlarını doğrudan veya diğer bulut kaynakları ve uygulamaları tarafından kullanılmak üzere merkezi bir bulut hizmetinde yönetmesine olanak tanır. Cloud KMS, anahtarların kaynağı için aşağıdaki seçenekleri sunar:

  • Cloud KMS yazılımının arka ucu, verilerinizi kontrolü sizin elinizde olan simetrik veya asimetrik bir anahtarla şifreleme esnekliği sağlar (Cloud KMS).
  • Donanım anahtarına ihtiyacınız varsa simetrik ve asimetrik anahtarlarınızın yalnızca FIPS 140-2 Seviye 3 onaylı Donanım Güvenlik Modüllerinde (HSM) kullanıldığından emin olmak için Cloud HSM'yi kullanabilirsiniz.
  • Kendi oluşturduğunuz anahtarları kullanmanız gerekirse Cloud KMS kendi şifreleme anahtarlarınızı içe aktarmanıza olanak tanır.
  • Cloud KMS'in oluşturduğu anahtarları diğer Google Cloud hizmetleriyle kullanmayı seçebilirsiniz. Bu anahtarlar, müşteri tarafından yönetilen şifreleme anahtarları (CMEK) olarak bilinir. CMEK özelliği, diğer Google Cloud hizmetlerindeki verilerin korunmasına yardımcı olmak için kullanılan şifreleme anahtarlarını oluşturmanıza, kullanmanıza, rotasyonunu sağlamanıza ve yok etmenize olanak tanır.
  • Cloud External Key Manager (Cloud EKM) ile anahtarları Google Cloud harici bir anahtar yöneticisinde oluşturabilir ve yönetebilir, ardından aktif olmayan verileri korumak için Cloud KMS platformunu ayarlayarak harici anahtarları kullanabilirsiniz. Müşteri tarafından yönetilen şifreleme anahtarlarını Cloud EKM anahtarıyla birlikte kullanabilirsiniz. Cloud EKM şimdilik bu teknik belgenin kapsamında yer almamaktadır.

Google, Compute Engine ve Cloud Storage için müşterinin sağladığı şifreleme anahtarlarını (CSEK) da destekler. Böylelikle, verilerin şifresi çözülürken ve veriler şifrelenirken API çağrısında sağlanan bir anahtar kullanılır. CSEK bu teknik belgenin kapsamı dışındadır. Daha fazla bilgi için online belgelere bakın.

Cloud KMS'i tasarlarken Google, kullanımı kolay bir platformda kontrol edebileceğiniz en geniş seçenek yelpazesine sahip ölçeklenebilir, güvenilir ve yüksek performanslı bir çözüm sunmayı amaçladı. Cloud KMS'in tasarımı beş temele dayanmaktadır:

  • Müşteri denetimi. Cloud KMS, yazılım ve donanım şifreleme anahtarlarını yönetmenize veya kendi anahtarlarınızı sağlamanıza olanak tanır.
  • Erişim denetimi ve izleme. Cloud KMS sayesinde farklı anahtarlarla ilgili izinleri yönetebilir ve anahtarların nasıl kullanıldığını izleyebilirsiniz.
  • Bölgesellik. Cloud KMS kullanıma hazır bölgeselleştirme olanağı sunar. Hizmet, yazılım anahtarlarını yalnızca seçtiğiniz Google Cloud bölgesinde oluşturacak, depolayacak ve işleyecek şekilde yapılandırılmıştır.
  • Dayanıklılık. Cloud KMS, Google Cloud'daki en yüksek dayanıklılık standartlarına sahiptir. Veri bozulmasına karşı koruma sağlamak ve verilerin şifresinin başarıyla çözülebildiğini doğrulamak için Cloud KMS, tüm anahtar materyalllerini ve meta verileri düzenli olarak tarar ve yedekler.
  • Güvenlik. Cloud KMS, anahtarlara yetkisiz erişime karşı güçlü koruma sağlar ve Kimlik ve Erişim Yönetimi (IAM) ve Cloud Denetleme Günlükleri denetimleri ile tamamen entegredir.

Bu makalede, Cloud KMS platformunun Genel Kullanılabilirlik (GA) sürümündeki iç işleyişine odaklanılmıştır. Bu seçenekler Google Cloud'da depoladığınız anahtarları ve diğer hassas verileri korumanıza yardımcı olur. Bu makalenin hedef kitlesi, Cloud KMS mimarisi, altyapısı ve özellikleri hakkında ayrıntılı bilgiye ihtiyaç duyan teknik karar alıcılardır. Bu makalede şifreleme kavramları ve bulut mimarileri hakkında temel bilgiye sahip olduğunuz varsayılır.

2. Google'da şifreleme kavramları ve anahtar yönetimi

Bu bölümde Google'ın çok katmanlı anahtar yönetimi altyapısı bağlamında anahtar yönetimiyle ilgili bazı terim ve tanımlar açıklanmaktadır.

2.1. Anahtarlar, anahtar sürümleri ve anahtarlıklar

Bu bölümde anahtarlar, anahtar sürümleri ve anahtarların anahtarlıklar halinde gruplandırılması açıklanmaktadır. Aşağıdaki şemada anahtar gruplandırmaları gösterilmektedir. İlgili tanımlar şemanın altında yer almaktadır.

  • Anahtar: Belirli bir amaç için kullanılan şifreleme anahtarını temsil eden adlandırılmış bir nesnedir. Anahtar materyali: Şifreleme işlemleri için kullanılan gerçek bitler (yeni anahtar sürümleri oluştururken zaman içinde değişebilir).

    Anahtarın amacı ve diğer özellikleri anahtar kullanılarak yönetilir ve anahtarla bağlantılıdır. Bu nedenle, KMS kullanımını anlamak için en önemli nesne anahtardır.

    Cloud KMS hem asimetrik anahtarları hem de simetrik anahtarları destekler. Simetrik anahtar, bazı veri topluluklarını korumak için simetrik şifreleme yaparken kullanılır (örneğin, şifrelenmemiş metin öbeğini şifrelemek için GCM modunda AES-256 kullanırken). Asimetrik anahtar, asimetrik şifreleme veya dijital imza oluşturma işlemleri için kullanılabilir. Desteklenen amaçlar ve algoritmalar Cloud KMS belgelerinde açıklanmıştır.

  • Anahtarlık: Anahtarların düzen sağlanması için gruplandırılmasıdır. Anahtarlık Google Cloud projesine aittir ve belirli bir konumda tutulur. Anahtarlar IAM politikalarını kendilerini içeren anahtarlıktan devralır. İlgili izinlere sahip anahtarları anahtarlıkta gruplandırmak, her bir anahtar için ayrı ayrı işlem yapmanıza gerek kalmadan bu anahtarlara anahtarlık düzeyinde izin vermenizi, izinleri iptal etmenizi veya değiştirmenizi sağlar. Anahtarlıklar kolaylık sunar ve sınıflandırma yapabilmenizi sağlar. Ancak anahtarlıkları gruplandırmak sizin için mantıklı bir işlem değilse izinleri doğrudan anahtarlar üzerinde yönetebilirsiniz.

    Kaynak adı çakışmalarını önlemek adına anahtarlıklar silinemez. Anahtarlıkların ve anahtarların faturalandırılabilir maliyetleri veya kota sınırlamaları yoktur. Bu nedenle, mevcut olmaya devam ettiklerinde maliyetleri ya da üretim sınırları etkilenmez. Anahtarların ve anahtar materyallerinin silinmesi hakkında daha ayrıntılı bilgi için bu makalenin ilerleyen kısımlarındaki silme konulu bölüme bakın.

  • Anahtar meta verileri: IAM politikaları, anahtar türü, anahtar boyutu, anahtar durumu ve bunlardan türetilen veriler gibi KMS kaynaklarının özellikleridir ve kaynak adlarıdır. Anahtar meta verileri anahtar materyalinden farklı şekilde yönetilebilir.

  • Anahtar sürümü: Zaman içindeki belirli bir noktada anahtarla ilişkili anahtar materyalini temsil eder. Anahtar sürümü gerçek anahtar materyalini içeren kaynaktır. Sürümler, sürüm 1 ile başlayarak sırayla numaralandırılır. Bir anahtar rotasyonu yapıldığında yeni anahtar materyaline sahip yeni bir anahtar sürümü oluşturulur. Aynı mantıksal anahtarın zaman içinde birden fazla sürümü olabilir. Bu nedenle, tek bir sürümün kullanımı sınırlandırılır. Simetrik anahtarların her zaman birincil sürümü olur. Bu sürüm varsayılan olarak şifreleme için kullanılır. Cloud KMS, simetrik anahtarları kullanarak şifre çözdüğünde şifre çözme işlemini gerçekleştirmek için hangi anahtar sürümünün gerektiğini otomatik olarak belirler.

2.2. Anahtar hiyerarşisi

Aşağıdaki şemada, Google'ın dahili Anahtar Yönetimi Hizmeti'nin temel hiyerarşisi gösterilmektedir. Cloud KMS, Google KMS tarafından sarmalanan Cloud KMS ile şifrelenmiş anahtarlarda Google'ın dahili KMS'sinden yararlanır. Cloud KMS, Google KMS ile aynı güven kökünü kullanır. İlgili tanımlar şemanın altında yer almaktadır.

  • Veri şifreleme anahtarı (DEK): Verilerin şifrelenmesi için kullanılan anahtardır.
  • Anahtar şifreleme anahtarı (KEK): Bir veri şifreleme anahtarını şifrelemek veya sarmalamak için kullanılan anahtardır. Tüm Cloud KMS platformu seçenekleri (yazılım, donanım ve harici arka uçlar) anahtar şifreleme anahtarını kontrol etmenizi sağlar.
  • KMS Ana Anahtarı: Anahtar şifreleme anahtarlarını (KEK) şifrelemek için kullanılan anahtardır. Bu anahtar bellekte dağıtılır. KMS Ana Anahtarı donanım cihazlarında yedeklenir. Bu anahtar, anahtarlarınızın şifrelenmesinden sorumludur.
  • Root KMS: Google'ın dahili anahtar yönetim hizmetidir.

2.3. İşlemler

  • Proje: Cloud KMS kaynakları, diğer tüm Google Cloud kaynaklarında olduğu gibi bir Google Cloud projesine aittir. Verileri, Cloud KMS anahtarlarınızın tutulduğu projeden farklı bir projede barındırabilirsiniz. Bu özellik, anahtar yöneticileri ile veri yöneticileri arasındaki görevlerin ayrılmasına ilişkin en iyi uygulamayı destekler.
  • Konumlar: Proje içinde Cloud KMS kaynakları bir konumda oluşturulur. Daha fazla bilgi için Coğrafya ve bölgeler konusuna bakın.

3. Cloud KMS platformuna genel bakış

Cloud KMS platformu, birden fazla şifreleme algoritmasını destekler ve hem donanım hem de yazılım destekli anahtarları kullanarak şifreleme ve dijital imzalama yöntemleri sunar. Cloud KMS platformu, Kimlik ve Erişim Yönetimi (IAM) ve Cloud Denetleme Günlükleri ile entegredir. Böylece, ayrı ayrı anahtarlarda izinleri yönetebilir ve bunların nasıl kullanıldığını denetleyebilirsiniz.

Önceki şemada Cloud KMS platformunun ana bileşenleri gösterilmektedir. Yöneticiler, anahtar yönetim hizmetlerine Google Cloud Console'u veya gcloud komut satırı aracını kullanarak ya da REST veya gRPC API'lerini uygulayan uygulamalar aracılığıyla erişir. Uygulamalar, anahtar yönetim hizmetlerine REST API veya gRPC kullanarak erişir. Uygulamalar, müşteri tarafından yönetilen şifreleme anahtarlarını (CMEK) kullanacak şekilde etkinleştirilmiş Google hizmetlerini kullanabilir. CMEK bunun için Cloud KMS API'yi kullanır. Cloud KMS API, yazılım (Cloud KMS) veya donanım (Cloud HSM) anahtarlarını kullanmanıza olanak tanır. Hem yazılım hem de donanım tabanlı anahtarlar, Google'ın yedekleme korumalarından yararlanır.

Cloud KMS platformunda, anahtar oluştururken hangi anahtar arka ucunun anahtarı oluşturacağını ve anahtar üzerinde gelecekteki tüm şifreleme işlemlerini gerçekleştireceğini belirlemek için bir koruma düzeyi seçebilirsiniz. Cloud KMS platformu, Cloud KMS API'de SOFTWARE ve HSM koruma düzeyleri olarak sunulan iki arka uç (Cloud EKM hariç) sağlar. SOFTWARE koruma düzeyi, şifreleme işlemleri gerçekleştirmek için bir yazılım güvenlik modülü tarafından sarmalanması kaldırılabilen anahtarlara uygulanır. HSM koruma düzeyi, yalnızca tüm şifreleme işlemlerini anahtarlarla gerçekleştiren Donanım Güvenlik Modülleri tarafından sarmalanması kaldırılabilen anahtarlara uygulanır.

Google Cloud; Cloud Storage, BigQuery ve Compute Engine dahil birçok hizmet için CMEK'yi destekler. CMEK, Cloud KMS platformunu kullanmanıza olanak tanır. Böylece, bu hizmetlerin verilerinizi korumaya yardımcı olmak için kullandığı şifreleme anahtarlarını yönetebilirsiniz.

Cloud KMS şifreleme işlemlerini, FIPS 140-2 onaylı modüller gerçekleştirir. SOFTWARE koruma düzeyine sahip anahtarlar ve bunlarla gerçekleştirilen şifreleme işlemleri, FIPS 140-2 Seviye 1'e uygundur. HSM koruma düzeyine sahip anahtarlar ve bunlarla gerçekleştirilen şifreleme işlemleri, FIPS 140-2 Seviye 3'e uygundur.

3.1. Ortam ve bağımlılar

Bu bölümde Cloud KMS platformunun üzerinde çalıştığı Google altyapısı ve altyapının kullandığı iletişim protokolleri hakkında ayrıntılı bilgi verilmektedir.

3.1.1. Cloud KMS Borg işleri

Cloud KMS platformunun öğeleri, üretim aşamasındaki Borg işleri olarak çalışır. Borg, Google'ın API sunma işlerini ve toplu işleri yönetme özelliği sunan geniş ölçekli küme yöneticisidir. Fiziksel ve üretim altyapımızın güvenliği hakkında ayrıntılı bilgi için Google Altyapı Güvenliği Tasarımına Genel Bakış konusuna bakın.

3.1.1.1. Cloud KMS API sunma işleri

Cloud KMS API sunma işleri, müşterilerin anahtarlarını yönetme ve kullanma isteklerini sunan üretim aşamasındaki Borg işleridir. Bu sunma işleri, Cloud KMS'nin kullanılabildiği her Google Cloud bölgesinde çalışır. Her iş, tek bir bölgeyle ilişkilendirilir ve yalnızca ilişkili Google Cloud bölgesi dahilindeki coğrafi konumlarda bulunan sistemlerdeki verilere erişecek şekilde yapılandırılır. Anahtar yerleşimi hakkında daha fazla bilgi için bu makalenin ilerleyen kısımlarındaki Bölgesellik konusuna bakın.

3.1.1.2. Cloud KMS toplu işleri

Cloud KMS platformu, çeşitli programlarda üretim aşamasındaki Borg işleri olarak çalışan bir dizi toplu işi de sürdürür. Toplu işler bölgeye özeldir ve yalnızca ilişkili Google Cloud bölgesinden gelen ve bu bölgelerde çalışan verileri toplar. Bu işlerin gerçekleştirdiği görevler arasında aşağıdakiler yer alır:

  • Müşterinin faturalandırması için etkin anahtarları sayma.
  • Cloud KMS'nin herkese açık protokol arabelleği API'sindeki kaynakları toplama ve meta verilerin Cloud Öğe Envanteri'ne iletme. Bu bağlamdaki Kaynaklar, Cloud KMS'nin yönettiği tüm kaynaklardır (ör. anahtarlar ve anahtarlıklar).
  • İşletme analizi için tüm kaynakları toplama ve bilgileri raporlama.
  • Yüksek kullanılabilirlik için verilerin anlık görüntülerini alma.
  • Altyapıdaki veri deposunda saklanan hiçbir veride kesinti olmadığını doğrulama.
  • KMS Ana Anahtarı rotasyonu yapılırken müşterinin anahtar materyalini yeniden şifreleme.
3.1.1.3. Cloud KMS anahtar anlık görüntü aracı

Yüksek kullanılabilirlik düzeyini korumak adına Cloud KMS platformu, Cloud KMS API sunucusu görevlerini barındıran paylaşılan bir hizmetin her bir örneğinde yedek bir veri deposu tutar. Her hizmet, anlık görüntü aracı hizmetinin kendi örneğini dağıtır. Bu yedeklilik, hizmetleri son derece bağımsız hale getirir. Bu sayede, bir alt bölgede sorun oluşması halinde diğer alt bölgeler sınırlı düzeyde etkilenir. Cloud KMS API işinin şifreleme işlemi gerçekleştirmesi gerektiğinde iş, yerel anlık görüntü aracı işlerine paralel olarak birincil veri deposunu sorgular. Daha sonra Cloud KMS API, isteği başarıyla ilk tamamlayan işi kullanır. Anlık görüntü ardışık düzeninde aşırı eski verilerin sunulmasına neden olabilecek bir gecikme yaşanmasını önlemek adına API sunucusu, veriler iki saatten eskiyse anlık görüntü aracı işlerindeki sonuçları kullanmaz. Anlık görüntüler, her bölge için sürekli çalışan bir toplu işin sonucu olarak oluşturulur. Anlık görüntüler, anahtar materyaliyle ilişkili bulut bölgesinde tutulur.

3.1.2. İstemci-sunucu iletişimleri

Google, kendi uzak prosedür çağrısı (RPC) mekanizmasını kullanan istemci-sunucu iletişimlerinin güvenliğini sağlamak için (geçiş halindeki verilerin şifrelenmesi) Uygulama Katmanı Aktarım Güvenliği'ni (ALTS) kullanır. ALTS aşağıdakileri sağlar:

  • Uygulamalar için eşler arası kimlik doğrulama protokolü
  • Kayıt şifreleme protokolü
  • Kimliği doğrulanmış kullanıcıyı yetkilendirme işlemi için sunan bir API

ALTS el sıkışma ve kayıt şifreleme protokolleri, Taşıma Katmanı Güvenliği (TLS) el sıkışma ve kayıt protokollerine benzerdir. ALTS, Google'ın üretim ortamını optimize etmek için farklı dengelemeler yapar ve ALTS, üretim donanımının ve yazılım yığınının tamamına tümüyle entegre edilmiştir. Daha fazla ayrıntı için bu makalenin ilerleyen kısımlarındaki Cloud KMS platformunun çalışma ortamı konusuna bakın.

4. Cloud KMS platformu mimarisinin ayrıntıları

Bu bölümde anahtar materyalinin güvenliği ve veri deposunun koruması konularıyla başlanarak mimari ayrıntılar ele alınmıştır. Daha sonra anahtar materyalinin kaynağına ilişkin seçenekler ayrıntılı olarak açıklanmıştır:

Bu bölümde müşteri tarafından yönetilen şifreleme anahtarları (CMEK) seçenekleri de açıklanmaktadır.

Şu ana kadar sunulan mimari yapıların nasıl kullanıldığına ilişkin dinamik bir görünüm sağlamak adına bu makalede anahtar materyalinin yok edilmesi konulu bir inceleme dahil, Cloud KMS isteğinin yaşam döngüsü açıklanmaktadır.

4.1. Anahtar materyallerinin güvenliği

Cloud KMS'de anahtar materyali her zaman kullanımda değilken ve geçiş halinde şifrelenir. Anahtar materyalinin şifresi yalnızca aşağıdaki durumlarda çözülür:

  • Müşterinin kullandığı anlarda.
  • Müşterinin anahtar materyalini korumak için kullanılan Google'ın dahili anahtarının rotasyonu yapılırken veya bütünlüğü kontrol edilirken.

Cloud KMS'ye yapılan müşteri istekleri, müşteri ile Google Front End (GFE) arasında TLS kullanılarak geçiş halindeyken şifrelenir. Cloud KMS işleri ile farklı veri merkezlerindeki arka uçlar arasında şifreleme yapmak için daha önce istemci-sunucu iletişimleri hakkındaki bölümde açıklanan Uygulama Katmanı Aktarım Güvenliği (ALTS) sistemi kullanılır. ALTS ve geçiş halindeki verilerin şifrelenmesi, bu makalenin ilerleyen kısımlarındaki Cloud KMS isteğinin yaşam döngüsü bölümünde daha ayrıntılı olarak açıklanmıştır.

Kimlik doğrulama, hem Google veri merkezleri arasındaki hem de merkezlerin içindeki tüm KMS işlerinde gerçekleşir.

Google'ın politikası, işlerin yalnızca doğrulanabilir bir yöntemle oluşturulmuş, test edilmiş ve incelenmiş kaynak kodu kullandığından emin olmaktır. Borg için İkili Program Yetkilendirmesi (BAB) bu politikayı operasyonel düzeyde uygular ve bu durum, bu güvenlik belgelerinde daha ayrıntılı olarak açıklanmıştır.

Cloud KMS API işleri, anahtar meta verilerine erişebilir (örneğin, IAM politikası veya rotasyon süresi). Geçerli ve belgelenmiş bir iş gerekçesi (hata veya müşteri sorunu gibi) olan bir Google çalışanı da anahtar meta verilerine erişebilir. Erişimler dahili olarak günlüğe kaydedilir ve Erişim Şeffaflığı kapsamındaki verilere ilişkin günlükler de uygun müşterilere sunulur.

Bununla birlikte, Cloud KMS API işleri anahtar materyaline erişemez ve anahtar materyali, API arayüzü veya başka bir kullanıcı arayüzü aracılığıyla dışa aktarılamaz ya da görüntülenemez. Hiçbir Google çalışanının şifrelenmemiş müşteri anahtarı materyaline erişimi yoktur. Anahtar materyali ek olarak Root KMS'de Ana Anahtar ile şifrelenir. Bu yüzden anahtar materyaline herhangi bir kişi doğrudan erişemez.

4.2. Veri deposu koruması

Bu bölümde Google KMS'in anahtar verilerini nasıl koruduğu açıklanmaktadır.

4.2.1. Ana Anahtarlar

Cloud KMS, aktif olmayan tüm müşteri anahtarlarını sarmalamak için bir Ana Anahtar kullanır. Her Cloud KMS sunucusu, başlatma sırasında Ana Anahtarın bir kopyasını katı bağımlı olarak alır ve her gün Ana Anahtarın yeni bir kopyası alınır. Ana Anahtar düzenli aralıklarla yeniden şifrelenir.

4.2.2. Rotasyon politikası

Anahtar materyalinin yönetimine ilişkin genel kabul gören en iyi uygulamalardan biri anahtar rotasyonudur. Cloud KMS veri depolarını korumak için kullanılan anahtarlarda rotasyon politikası bulunur. Cloud KMS anahtarlarını sarmalayan Google'daki dahili KMS Ana Anahtarlarına da anahtar rotasyonu politikası uygulanır. KMS Ana Anahtarında, müşterinin önbelleğe aldığı ve en fazla bir günlük süresi olan bir anahtarla planlanmış maksimum 90 günlük şifrelenmiş metin vardır. Cloud KMS, KMS görevlerindeki Ana Anahtarları 24 saatte bir yeniler ve tüm müşteri anahtarlarını ayda bir yeniden şifreler.

4.2.3. Veri yerleşimi

Her bir Cloud KMS veri deposunun altyapısını oluşturan veriler, özel olarak verilerin ilişkilendirildiği Google Cloud bölgesinde tutulur. Bu, birden çok bölgeli konumlar için de geçerlidir (örneğin, çok bölgeli us konumu). Veri yerleşimi hakkında daha fazla bilgi için bu makalenin ilerleyen kısımlarındaki Bölgesellik konusuna bakın.

4.3. Oluşturma sonrasında anahtarın kullanılabilirliği

Cloud KMS veri deposunun anahtarı oluşturan işlemi kaydetmesinden ve depolama katmanının oluşturma işlemini onaylamasından hemen sonra Cloud KMS anahtarın kullanılmasına izin verir.

4.4 Cloud KMS yazılımının arka ucu: SOFTWARE koruma düzeyi

SOFTWARE koruma düzeyi, kriptografik işlemleri yazılımda gerçekleştirilen anahtarlara uygulanır. Bu bölümde bu düzeyin nasıl uygulandığına dair ayrıntılar açıklanmaktadır.

4.4.1. Algoritmik uygulamalar

Cloud KMS, tüm ilgili şifreleme çalışmalarında yazılım anahtarları için Google'ın BoringSSL uygulamasında bulunan BoringCrypto modülünü (BCM) kullanır. BCM, FIPS 140-2 onaylıdır. Cloud KMS ikili programı, bu modüldeki FIPS 140-2 Seviye 1 onaylı Temel Kriptografi Öğelerine göre derlenir. Bu modülün kapsamındaki en güncel algoritmalar belgeler sayfamızda listelenmiştir ve AES256-GCM simetrik ile RSA 2048, RSA 3072, RSA 4096, EC P256 ve EC P384 asimetrik şifreleme anahtarları kullanarak şifreleme, şifre çözme ve imzalama işlemlerini içerir.

4.4.2. Rastgele sayı oluşturma ve entropi

Cloud KMS şifreleme anahtarlarını oluştururken BoringSSL'yi kullanır. FIPS 140-2, kendi PRNG'lerinin (DRBG olarak da bilinir) kullanılmasını gerektirir. BoringCrypto'da, Cloud KMS yalnızca AES-256 ile CTR-DRBG kullanır. Bu da, sistemin geri kalanının rastgele veri aldığı birincil arayüz olan RAND_bytes için çıkış sağlar. Bu PRNG, kendisi de birden fazla bağımsız entropi kaynağından başlatılan Linux çekirdeği RNG'sinden başlatılır. Bu başlatma işlemi, diskte yapılan aramaların ayrıntılı ölçümleri ve paket içi varış süreleri gibi veri merkezi ortamından gelen entropik etkinlikleri ve mevcut olan yerlerde Intel'in RDRAND talimatlarını içerir. BoringSSL'de (FIPS'e uygun mod) rastgele sayı oluşturma aracının davranışı hakkında daha fazla bilgi için lütfen RNG tasarımı konusuna bakın.

4.5. Cloud KMS HSM arka ucu: HARDWARE koruma düzeyi

Cloud HSM hizmeti, Cloud KMS'ye donanım destekli anahtarlar sağlar. Müşterilere, Google veri merkezlerinde tümüyle yönetilen Donanım Güvenlik Modülleri (HSM) tarafından korunan şifreleme anahtarlarını yönetme ve kullanma olanağı sunar. Hizmet yüksek düzeyde kullanılabilirdir ve yatay olarak otomatik ölçeklendirilir. Anahtarlar, kriptografik olarak anahtarlığın tanımlandığı KMS bölgesine bağlıdır. Cloud HSM'de, oluşturduğunuz ve kullandığınız anahtarlar, anahtarın oluşturulduğu anda belirtilen bölgeye ait olan HSM kümesinin dışında gerçekleştirilemez. Cloud HSM'yi kullanarak şifreleme anahtarlarınızın oluşturulduğunu ve yalnızca bir donanım cihazında kullanıldığını doğrulayabilirsiniz. Mevcut Cloud KMS müşterilerinin Cloud HSM kullanması için uygulama değişikliği gerekmez. Cloud HSM hizmetlerine, Cloud KMS yazılımının arka ucuyla aynı API ve istemci kitaplıkları kullanılarak erişilir.

Cloud HSM, FIPS 140-2 Seviye 3 onaylı ve her zaman FIPS modunda çalışan HSM'leri kullanır. FIPS standardı, HSM'ler tarafından kullanılan kriptografik algoritmaları ve rastgele sayı oluşturma işlemini belirtir.

4.5.1. Cavium HSM'leri

Cavium HSM PCIe kartının FIPS 140-2 Seviye 3'e uygun olduğu tedarikçi firma tarafından doğrulanmıştır. Geçerli sertifika istek üzerine sunulur.

4.5.2. HSM anahtar hiyerarşisi

Aşağıda verilen şemanın üst yarısında Cloud KMS'yi görüyoruz. Cloud HSM, müşteri anahtarlarını sarmalar. Ardından da Cloud KMS, Google'ın veri deposuna aktarılan HSM anahtarlarını sarmalar.

Cloud HSM'de, Cloud HSM yönetim alanı içindeki materyalin taşınmasını kontrol eden bir anahtar (şemada gösterilmemiştir) bulunur. Bir bölgenin birden fazla HSM yönetim alanı olabilir.

HSM Kök Anahtarının iki özelliği vardır:

  1. Bu anahtar HSM'de oluşturulur ve HSM'lerin iyi tanımlanmış sınırlarını kullanım ömrü boyunca hiç terk etmez. Anahtar başka HSM'lerde veya yedek HSM'lerde çoğaltılabilir.
  2. HSM'lerin kullandığı müşteri anahtarlarını doğrudan veya dolaylı olarak sarmalama amaçlı bir anahtar şifreleme anahtarı olarak kullanılabilir.

HSM Kök Anahtarlarıyla sarmalanmış müşteri anahtarları HSM'de kullanılabilir ancak HSM, müşteri anahtarının şifrelenmemiş metnini asla döndürmez. HSM müşteri anahtarını yalnızca işlemler için kullanır.

4.5.3. Veri deposu koruması

HSM'ler anahtarlar için kalıcı depolama alanı olarak kullanılmaz. Anahtarları yalnızca kullanım sırasında depolarlar. HSM depolama alanı kısıtlı olduğundan HSM anahtarları, Cloud KMS anahtar veri deposunda şifrelenip depolanır. Bu konu, bu makalenin ilerleyen kısımlarındaki Veri deposu arka ucu bölümünde ayrıntılı olarak açıklanmıştır.

4.5.4. Rotasyon politikası

Cloud HSM'nin anahtar koruma stratejisinde yer alan birkaç anahtar türü vardır. Müşteriler kendi anahtarlarının rotasyonunu sağlar ve HSM anahtarlarının rotasyonu için Cloud KMS'den yararlanır.

4.5.5. Temel hazırlık ve yönetim süreci

HSM'ler, tek taraftan kaynaklanan güvenlik ihlallerini önlemek adına gerçekleştirilen çok taraflı yetkilendirme denetimleri gibi çeşitli fiziksel ve mantıksal güvenlik önlemlerine sahip bir laboratuvarda sağlanır.

Aşağıda Cloud HSM sistemi düzeyindeki sabit alanlar verilmiştir:

  1. Müşteri anahtarları şifrelenmemiş metin olarak çıkarılamaz.
  2. Müşteri anahtarları kaynak bölgenin dışına taşınamaz.
  3. Sağlanan HSM'lerde yapılan tüm yapılandırma değişiklikleri birden fazla güvenlik önlemiyle korunur.
  4. Yönetim işlemleri günlüğe kaydedilirken Cloud HSM yöneticileri ile günlük kaydı yöneticileri arasındaki görevlerin ayrılması ilkesine uyulur.
  5. HSM'ler, çalışma yaşam döngüsü boyunca izinsiz değişikliklerden (kötü amaçlı donanım veya yazılım değişikliklerinin eklenmesi ya da gizli anahtarların yetkisiz bir şekilde çıkarılması yoluyla) korunacak şekilde tasarlanmıştır.

4.5.6. Tedarikçi firma tarafından kontrol edilen donanım yazılımı

HSM donanım yazılımı, HSM tedarikçisi tarafından dijital olarak imzalanır. Google, HSM donanım yazılımını oluşturamaz veya güncelleyemez. Test için kullanılan geliştirme donanım yazılımı da dahil, tedarikçinin tüm donanım yazılımları imzalanır.

4.5.7. Bölgesellik

Müşteri anahtarları, belirli bir HSM Kök Anahtarına bağlandıklarında belirli coğrafi bölgelere de atanır. Örneğin, özel olarak us-west1 bölgesinde oluşturulan bir anahtar, us-east1 bölgesine veya us çoklu bölgesinde taşınamaz. Benzer şekilde, us çoklu bölgesinde oluşturulan bir anahtar us-west1 bölgesine veya bu bölgeden dışarı taşınamaz.

4.6. Cloud KMS: Anahtar içe aktarma

Bulut ortamınıza kendi anahtarlarınızı aktarmak isteyebilirsiniz. Örneğin, mevzuatlar bulut verilerinizi şifrelemek için kullanılan anahtarların belirli bir yöntemle veya belirti bir ortamda oluşturulmasına yönelik bir gereklilik getiriyor olabilir. Cloud KMS, şirket içinde veya External Key Manager'da oluşturduğunuz kendi şifreleme anahtarlarınızı içe aktarmanıza olanak tanır. Anahtar içe aktarma, bu anahtarları içe aktarmanızı ve mevzuat yükümlülüklerini yerine getirmenizi sağlar. Ayrıca, imzalama yeteneklerinizi buluta taşımak için asimetrik anahtarları da içe aktarabilirsiniz.

Anahtar içe aktarma işleminin bir parçası olarak Cloud KMS, desteklenen içe aktarma yöntemlerinden birini kullanır ve bir herkese açık/özel anahtar çifti olan sarmalama anahtarı oluşturur. Anahtar materyalinizi bu sarmalama anahtarıyla şifrelemek, geçiş halindeki anahtar materyalini korur.

Bu Cloud KMS herkese açık sarmalama anahtarı, içe aktarılacak anahtarı istemci üzerinde şifrelemek için kullanılır. Bu ortak anahtarla eşleşen özel anahtar, Google Cloud'da depolanır ve anahtar Google Cloud projesine eriştikten sonra anahtarın sarmalanmasını kaldırmak için kullanılır. Seçtiğiniz içe aktarma yöntemi, sarmalama anahtarını oluşturmak için kullanılan algoritmayı belirler. Sarmalandıktan sonra anahtar materyalini Cloud KMS'de yeni bir anahtara veya anahtar sürümüne aktarabilirsiniz.

İçe aktarılan anahtarlar HSM veya SOFTWARE koruma düzeyiyle kullanılabilir.

Cloud HSM'de sarmalama anahtarının özel anahtar kısmı yalnızca Cloud HSM içinde kullanılabilir. Özel anahtar kısmını Cloud HSM ile kısıtlamak, Google'ın anahtar materyalinizin sarmalanmasının Cloud HSM'nin dışında kaldırılmasını engeller.

4.7. Müşteri tarafından yönetilen şifreleme anahtarları (CMEK)

Google Cloud, varsayılan olarak aktif olmayan tüm müşteri verilerini şifreler ve şifreleme için kullanılan anahtarları yönetir. Bazı Google Cloud ürünlerinde ise müşteriler şifrelemede kullanılan anahtarları yönetmek için Cloud KMS'yi kullanabilir. CMEK hem yazılım hem de donanım destekli anahtarlar için kullanılabilir. Cloud KMS sayesinde müşteriler, anahtarların birçok özelliğini (ör. anahtar oluşturma, etkinleştirme/devre dışı bırakma, rotasyonunu sağlama ve anahtarları yok etme) kontrol edebilir ve bu anahtarlar üzerinde uygun IAM izinlerini yönetebilir. Cloud KMS, önceden tanımlanmış birkaç IAM rolü içerir. Bu roller belirli ayrıcalıklara ve sınırlamalara sahiptir ve önerilen görevlerin ayrılması ilkesini uygulamak için belirli kullanıcılara ve hizmet hesaplarına verilebilir.

Aşağıdaki konularda Cloud KMS platformuyla entegre edilmiş ve CMEK'yi destekleyen ürünlerle ilgili ayrıntılar verilmektedir:

Anahtar rotasyonunun kullanılan anahtar sürümü üzerindeki etkisi, bir ürünün CMEK'leri nasıl uyguladığına bağlıdır. Genel olarak, Cloud KMS anahtarının rotasyonu, ilişkili CMEK hizmetindeki verileri yeniden şifrelemez. Örneğin, tabloyla ilişkili Cloud KMS anahtarının rotasyonu yapıldığında BigQuery, bir tablo şifreleme anahtarının rotasyonunu otomatik olarak yapmaz. Mevcut BigQuery tabloları oluşturuldukları anahtar sürümünü kullanmaya devam eder. Yeni BigQuery tabloları geçerli anahtar sürümünü kullanır. Daha fazla bilgi için ilgili ürünün belgelerine bakın.

CMEK entegrasyonlarının ve CMEK ile uyumlu hizmetlerin tam listesi için bu belgelere göz atın. Google, diğer Google Cloud ürünleri için CMEK entegrasyonuna yatırım yapmaya devam etmektedir.

4.8. Cloud KMS isteğinin yaşam döngüsü

Şu ana kadar sunulan mimari yapıların nasıl kullanıldığına ilişkin dinamik bir görünüm sağlamak adına bu bölümde anahtar materyalinin yok edilmesi konulu bir inceleme dahil, Cloud KMS isteğinin yaşam döngüsü açıklanmaktadır.

Bu yaşam döngüsündeki adımlar şu şekildedir:

  1. Bir müşteri veya müşteri adına çalışmakta olan bir iş, Cloud KMS hizmeti için (https://cloudkms.googleapis.com) istek oluşturur. DNS, bu adresi Google Front End'in (GFE) bir her noktaya yayın IP'si adresine açıklar.
  2. GFE; genel DNS adını, Hizmet Reddi (DoS) korumasını ve TLS sonlandırmasını genel IP'de barındırır. Müşteri isteğini gönderdiğinde hangi konumun hedeflendiğine bakılmaksızın istek genellikle müşteriye yakın bir GFE'ye yönlendirilir. GFE'ler TLS iletişimini yürütür ve istek URL'si ile parametreleri kullanarak isteği hangi Global Yazılım Yükü Dengeleyicinin (GSBT) yönlendirdiğini belirler.
  3. Her Cloud KMS bölgesi için ayrı bir GSLB hedefi vardır. İstek Google'a us-east1 konumunda gelirse ve isteğin hedefi us-west1 ise istek, us-east1 ve us-west1 veri merkezleri arasında yönlendirilir. Veri merkezleri arasındaki tüm iletişimler, GFE ve Cloud KMS işlerinin ortak kimlik doğrulamasını yapan ALTS tarafından geçiş halindeyken şifrelenir.
  4. İstek Cloud KMS işine ulaştığında, öncelikle tüm Google Cloud hizmetlerinde yaygın olarak kullanılan işlerin çoğunu yöneten bir çerçeve tarafından işlenir. Bu çerçeve, kullanıcının kimliğini doğrular ve aşağıdakileri doğrulamak için bir dizi kontrol gerçekleştirir:
    • Müşterinin geçerli bir kimlik bilgisi olduğunu ve kimliğinin doğrulanabildiğini.
    • Google Cloud projesinde Cloud KMS API'nin etkin olduğunu ve geçerli bir faturalandırma hesabına sahip olduğunu.
    • Kotanın isteği yürütmek için yeterli olduğunu.
    • Müşterinin ilgili Google Cloud bölgesini kullanmak için izin verilenler listesinde olduğunu.
    • İsteğin VPC Hizmet Kontrolleri tarafından reddedilmeyeceğini.
  5. Bu kontroller geçildikten sonra çerçeve, isteği ve kimlik bilgilerini Cloud KMS'ye yönlendirir. Cloud KMS, hangi kaynaklara erişildiğini belirlemek için isteği ayrıştırır ve daha sonra çağrıyı yapanın istekte bulunma yetkisinin olup olmadığını öğrenmek için IAM'ye danışır. IAM, istek sıklığının denetleme günlüklerine yazılıp yazılmayacağını da Cloud KMS'ye bildirir.
  6. İsteğin kimliği doğrulandıktan ve istek yetkilendirildikten sonra Cloud KMS, istenen kaynağı getirmek için bölge içi veri deposu arka uçlarını çağırır. Kaynak getirildikten sonra müşterinin anahtar materyalinin şifresi çözülür ve materyal kullanıma hazırlanır.
  7. Daha sonra Cloud KMS, anahtar materyalini kullanarak anahtarın sarmalanmış sürümünü anahtarın koruma düzeyine bağlı olarak Cloud KMS yazılım arka ucuna veya Cloud HSM'ye yönlendirir ve böylece kriptografi işlemini gerçekleştirir.
  8. Kriptografi işlemi tamamlandıktan sonra yanıt, istekle aynı GFE-KMS kanalı türünde müşteriye gönderilir.
  9. Yanıt döndürüldüğünde Cloud KMS ayrıca bazı etkinlikleri eşzamansız olarak tetikler:
    • Denetleme ve istek günlükleri doldurulup yazılmak üzere sıraya alınır.
    • Raporlar, faturalandırma ve kota yönetimi amacıyla gönderilir.
    • İstek bir kaynağın meta verilerini güncellediyse değişiklik toplu iş güncellemeleri üzerinden Cloud Öğe Envanteri'ne gönderilir.

4.9. Anahtar materyalinin yok edilmesi

Google Cloud'daki verilerin silinmesi konusu bu teknik belgede açıklanmıştır. Anahtar materyali, müşteri verisi olarak kabul edilir. Bu nedenle, teknik belgede açıklanan yaklaşım Cloud KMS için geçerlidir. Ayrıca Google, anahtar materyalini hiçbir zaman Cloud KMS dışında paylaşmaz. Bu yüzden, silme işleminin 24 saatlik bekleme süresi tamamlandığında ve yedeklerin süresi dolduğunda anahtar materyali yok edilir. Bu işlem, içe aktarılan anahtarların Cloud KMS'nin denetimi dışındaki kopyaları için garanti edilmez.

Anahtar materyali yukarıda açıklandığı gibi yok edilirken anahtarlar ve anahtarlıklar silinemez. Anahtar sürümleri de silinemez ancak kaynakların kullanılamaz hale gelmesi için anahtar sürümü materyali yok edilebilir. Anahtarlıkların ve anahtarların faturalandırılabilir maliyetleri veya kota sınırlamaları yoktur. Bu nedenle, silinememeleri maliyetleri ya da üretim sınırlarını etkilemez.

Yok edilmesi planlandıktan sonra anahtar sürümü, kriptografi işlemleri için kullanılamaz. 24 saatlik süre zarfında kullanıcı, anahtar sürümünü geri yükleyerek yok edilmemesini sağlayabilir.

5. Cloud KMS platformunun çalışma ortamı

Cloud KMS platformunun çalışma ortamında anahtar materyalini korurken güvenilirliği, dayanıklılığı ve kullanılabilirliği optimize etmek için tasarlanmış veri depolama ve güvenlik politikaları, erişim kısıtlamaları ve risk azaltma stratejileri yer alır. Bu bölümde hizmetin çalışma yapısı, operasyon ekibi üyelerinin sorumlulukları, kimlik doğrulama mekanizmaları ile denetleme ve günlük kaydı protokolleri ele alınmaktadır. Bölümün sonunda yer alan açıklama hem yazılım hem de donanım destekli anahtarlar için geçerlidir.

5.1. Yazılım mühendisleri, site güvenirliği mühendisleri ve sistem operatörleri

Yazılım mühendisleri, sistemi tasarlamak ve ardından Cloud KMS hizmetinin kodlarının ve testlerinin büyük bir kısmını yazmak için ürün yöneticileri ve site güvenirliği mühendisleri (SRE'ler) gibi diğer paydaşlarla iş birliği yapmaktan sorumludur. Kod, müşteri isteklerine yanıt veren ana işi ve veri çoğaltma ile faturalandırma gibi işlemlerle ilgili ikincil işleri içerir. SRE'ler de kod yazabilir. Ancak yazılım mühendislerinin ve SRE'nin görevleri farklıdır. SRE'lerin ana sorumluluğu Cloud KMS işlerinin üretim ortamını korumaktır. SRE'ler mühendislik ve operasyon çalışmalarıyla güvenilirliği ölçüp geliştirir.

Sistem operatörleri, Cloud KMS için derleme ve yayınlama sürecinden, izleme görevlerinden, uyarılardan ve kapasite planlamasından sorumludur. Cloud KMS ile ilgili müşteri sorunlarına ve kesintilere ilk yanıt veren kişilerdir. Örneğin, sistem operatörleri, manuel sistemlerin işlerini en aza indirmek için araç ve otomasyondan yararlanır. Böylece, uzun vadeli değer katan çalışmalara odaklanabilirler.

5.2. Cloud KMS kaynaklarının bölgeselliği

Cloud KMS kaynaklarını dört tür Google Cloud konumundan birinde oluşturabilirsiniz:

  • Bölgesel konumlar. Bölgesel konum, belirli bir coğrafi yerdeki (ör. Iowa) alt bölgelerden oluşur.
  • İki bölgeli konumlar. İki bölgeli konum, iki farklı coğrafi yerdeki (örneğin, Iowa ve Güney Carolina) alt bölgelerden oluşur.
  • Çok bölgeli konumlar. Çok bölgeli konum, ABD gibi genel bir coğrafi bölgeye yayılmış alt bölgelerden oluşur.
  • Küresel konum. Küresel konum, dünyanın dört bir yanına yayılmış alt bölgelerden oluşur. Cloud KMS kaynaklarınızı küresel konumda oluşturduğunuzda bu kaynaklara dünya genelindeki alt bölgelerden ulaşabilirsiniz.

Konumlar, belirli bir kaynak için Cloud KMS isteklerinin yönetildiği ve ilgili şifreleme anahtarlarının depolandığı coğrafi bölgeleri temsil eder.

Kullanılabilir Cloud KMS konumları hakkında daha fazla bilgi için Cloud KMS belgelerine bakın.

5.2.1. Bulut bölgeleri ve veri merkezleri

Google Cloud bölgesi; tek bir bölge, ikili bölge, çoklu bölge veya küresel konum şeklindeki hedefine göre belirlenen belirli bir veri merkezi veya veri merkezi kümesi içerir. Google Cloud bölgeleri hakkında daha fazla bilgi için Google Cloud konumları konusuna bakın.

Her bir veri merkezi; bilgi işlem, ağ iletişimi veya verilerin depolanması için çok sayıda makine içerir. Bu makineler Google'ın Borg altyapısını çalıştırır.

Google veri merkezlerinin katı fiziksel güvenlik gereksinimleri vardır. Kullanıcı verileri içerebilecek tüm fiziksel alanlarda, giriş yapanların kimliğini doğrulamak için kullanılan rozet okuyuculara ve/veya iris tarayıcılarına sahip giriş yolları bulunması zorunludur. Girişler birden fazla kişiye açık tutulmaz; kişilerin tek tek kimliklerini doğrulaması gerekir. Güvenlik personelinin yaptığı inceleme sonucunda açıkça yetki verilmiş çantalar hariç bu alanlara çanta getirilmesine izin verilmez. Veri aktarabilen veya kaydedebilen elektronik cihazları getirmek veya dışarı çıkarmak için özel izin gereklidir.

5.2.2. Bölgesellik

Bazı sektörlerde şifreleme anahtarlarının belirli bir konumda tutulması gerekir. Yukarıdaki Cloud KMS kaynaklarının bölgeselliği konusunda da açıklandığı üzere Cloud KMS, bu gereksinimleri karşılamanıza yardımcı olacak dört tür bölgesel konum sunar.

Tek, ikili veya çok bölgeli konumlar için Cloud KMS, müşteri yazılımınızı ve donanım destekli anahtarlarınızı ve anahtar materyalinizi yalnızca söz konusu konumda oluşturur, depolar ve işler. Cloud KMS'nin kullandığı depolama ve veri işleme sistemleri, yalnızca anahtar materyaliyle ilişkili Google Cloud bölgesindeki kaynakları kullanacak şekilde yapılandırılır. İkili veya çok bölgeli konumlarda oluşturulan anahtar materyali, seçilen konumların sınırları dışına çıkmaz.

Küresel bölgelerde bölgesellik garantisi verilmez.

Cloud KMS; anahtar meta verilerinin, kullanım günlüklerinin veya geçiş halindeki anahtar materyalinin nerede tutulacağını garanti etmez. Anahtar meta verileri; anahtar türü, anahtar boyutu, anahtar durumu, IAM politikaları ve meta verilerden türetilen veriler gibi Cloud KMS kaynaklarının özelliklerini ve kaynak adlarını içerir.

CMEK kullanırken CMEK ile kullanmak istediğiniz diğer Google Cloud ürünlerinde seçtiğiniz özel, ikili veya çok bölgeli konumlara bakılmaksızın anahtarlarınız için aşağıdaki coğrafi Cloud KMS kısıtlamaları geçerli olur:

  • Belirli bir bölge için: Müşteri tarafından yönetilen bir KMS anahtarının bölgesi her zaman belirli bir Google Cloud hizmetinde koruduğu kaynağın bölgesi ile ilişkilendirilmelidir. Bu nedenle, tek bölge anahtarları ve kaynakları için yerleşim kısıtlamalarının uyumlu olacağı ve zorunlu kılınacağı garanti edilir.
  • İkili veya çok bölgeli konumlar için: Kullanıcılar, yerleşim uyumluluğunu garanti etmek adına anahtarları ve Google Cloud kaynakları için Google tarafından tanımlanan ilgili çoklu bölgeleri seçebilir. Bu coğrafi yerleşimi sağlamak için diğer ürünlerdeki bölgelerinizin seçtiğiniz bölgesel Cloud KMS konumuyla uyumlu olduğundan emin olun.

Aşağıdaki tabloda Cloud KMS için anahtar materyalinin yerleşimi özetlenmektedir.

Cloud KMS verilerinin yerleşimi Aktif olmayan, kullanılan
(tek bölge)
Aktif olmayan, kullanılan
(ikili/çoklu bölge)
Yazılım anahtar materyali Kalıcı İkili/çoklu bölgeyi oluşturan bölgelerde kalıcıdır.
Donanım anahtar materyali (HSM) Kalıcı İkili/çoklu bölgeyi oluşturan bölgelerde kalıcıdır.

5.2.3. Bölgesellik izleme

Google'ın dahili veri izleme hizmetleri, anahtar yerleşimini etkin bir şekilde izler. Cloud KMS yanlış yapılandırmalar tespit ederse veya anahtar materyali yapılandırılan bölgenin sınırları dışına çıkarsa, yanlış bölgede depolanırsa ya da materyale yanlış bölgeden erişilirse Cloud KMS, SRE ekip üyelerine uyarılar gönderir.

5.3. Kimlik doğrulama ve yetkilendirme

Cloud KMS'de OAuth2, JWT ve ALTS gibi çeşitli kimlik doğrulama mekanizmaları kabul edilir. Kullanılan mekanizma ne olursa olsun Cloud KMS, ana hesabı (kimliği doğrulanmış olan ve isteği yetkilendiren varlık) tanımlamak için sağlanan kimlik bilgilerini çözümler ve ana hesabın istekte bulunma yetkisinin olup olmadığını ve bir denetim günlüğü yazılıp yazılmadığını öğrenmek için IAM'yi çağırır.

Cloud KMS, hizmet yönetiminin birçok aşaması için genel Service Control API'nin dahili sürümünü kullanır. Cloud KMS işi bir isteği işleme almadan önce Service Control API'ye bir kontrol isteği gönderir. Bu API, tüm Google Cloud hizmetlerinde yaygın olarak uygulanan aşağıdakiler gibi birçok denetimi zorunlu kılar:

  • Müşterinin Cloud KMS API'yi etkinleştirip etkinleştirmediğini ve etkin bir faturalandırma hesabına sahip olup olmadığını kontrol etme.
  • Müşterinin kotasını aşıp aşmadığını kontrol etme ve kota kullanımını raporlama.
  • VPC Hizmet Kontrolleri'ni zorunlu kılma.
  • Geçerli özel bulut bölgeleri için müşterinin izin verilenler listesinde olup olmadığını kontrol etme.

5.4. Günlük Kaydı

Cloud KMS ile ilişkili üç günlük türü bulunur: Cloud Denetleme Günlükleri, Erişim Şeffaflığı günlükleri ve dahili istek günlükleri.

5.4.1. Cloud denetleme günlükleri

Cloud KMS, müşteri etkinliğini Cloud Denetleme Günlükleri'nde kaydeder. Müşteriler bu günlükleri Cloud Console'da görüntüleyebilir. Tüm yönetici etkinlikleri (örneğin, anahtar oluşturma veya yok etme) bu günlüklere kaydedilir. Müşteriler, anahtar kullanan diğer tüm işlemler için (örneğin, verileri şifrelemek veya verilerin şifresini çözmek için anahtar kullanma) günlüğe kaydetmeyi etkinleştirebilir. Müşteriler, günlükleri ne kadar süreyle saklamak istediklerini ve bunları kimin görüntüleyebileceğini kontrol eder.

5.4.2. Erişim Şeffaflığı günlükleri

Uygun müşteriler, isteğe bağlı olarak Erişim Şeffaflığı günlüklerini etkinleştirebilir. Bunlar, Google çalışanlarının Google Cloud kuruluşunuzda gerçekleştirdiği işlemlerin günlüklerini sunar. Cloud Denetleme Günlükleri'ndeki günlüklerin yanı sıra Erişim Şeffaflığı günlükleri; kim, nerede, ne zaman, ne yaptı gibi soruları yanıtlamanıza yardımcı olabilir.

Bu işlemlerle ilgili denetimlerinizi otomatikleştirmek için Erişim Şeffaflığı günlüklerini mevcut güvenlik bilgileriniz ve etkinlik yönetimi (SIEM) araçlarınızla entegre edebilirsiniz. Bu günlükler, Cloud Console'da Cloud Denetleme Günlükleri'nizle birlikte kullanılabilir.

Erişim Şeffaflığı günlük girişlerinde aşağıdaki ayrıntılar bulunur:

  • Etkilenen kaynak ve işlem.
  • İşlemin zamanı.
  • İşlemin nedenleri. Nedenlere örnek olarak müşteri tarafından başlatılan destek (destek kaydı numarasıyla) işlemleri, Google tarafından başlatılan destek işlemleri, üçüncü taraf veri istekleri ve Google tarafından başlatılan inceleme istekleri verilebilir.
  • Verilerle ilgili kimin işlem yaptığına ilişkin veriler (örneğin, Google çalışanının konumu).

5.4.3. Dahili istek günlükleri

İstek günlükleri, Cloud KMS platformuna gönderilen her istek için bir kayıt saklar. Bu kayıt, istek türü (API yöntemi veya protokolü) ve erişilen kaynak (kaynak adı, anahtar algoritması veya anahtar koruma düzeyi gibi) ile ilgili ayrıntıları içerir. Bu günlükler müşterinin şifrelenmemiş metnini, şifrelenmiş metnini veya anahtar materyalini saklamaz. Bu günlüklere yeni veri türleri eklenmeden önce gizlilik incelemelerinde uzman bir ekibin, günlüğe kaydedilen verilerdeki değişiklikleri onaylaması gerekir.

Yapılandırılan geçerlilik süresi (TTL) sona erdiğinde günlük girişleri kalıcı olarak silinir.

Nöbetçi Cloud KMS SRE'leri ve mühendisleri istek günlüklerine erişebilir. Günlüklere insan erişimi ve müşteri verilerini döndüren tüm erişimler için geçerli ve belgelenmiş bir işletme gerekçesi gerekir. Bazı istisnalarda insanların erişimi günlüğe kaydedilir ve Erişim Şeffaflığı günlüklerinde uygun müşterilerin erişebilmesi sağlanır.

5.5. Veri deposu arka ucu

Cloud KMS'nin veri deposu yüksek düzeyde kullanılabilirdir, dayanıklıdır ve korunur.

Kullanılabilirlik. Cloud KMS, yüksek düzeyde kullanılabilir olan ve bir takım kritik Google sistemini destekleyen Google'ın dahili veri deposunu kullanır.

Dayanıklılık. Cloud KMS, müşterinin anahtar materyalini veri deposunda saklamak için kimliği doğrulanmış şifreleme kullanır. Ayrıca, kullanımda değilken değişiklik yapılmadığından veya bozulmadığından emin olmak için tüm meta verilerin kimliği, karma tabanlı mesaj doğrulama kodu (HMAC) kullanılarak doğrulanır. Bir toplu iş, tüm anahtar materyallerini ve meta verileri saatte bir tarar, HMAC'lerin geçerli olduğunu ve anahtar materyalinin şifreyi başarıyla çözebildiğini doğrular. Herhangi bir veri bozulmuşsa Cloud KMS mühendislerine harekete geçebilmeleri için hemen uyarı gönderilir.

Cloud KMS, veri deposu için birkaç yedekleme türü kullanır:

  • Varsayılan olarak veri deposu, her satırın değişiklik geçmişini birkaç saat boyunca saklar. Acil durumlarda sorunları gidermeye daha fazla süre tanımak adına bu kullanım ömrü uzatılabilir.
  • Veri deposu saat başı bir anlık görüntü kaydı alır. Anlık görüntü gerekirse doğrulanabilir ve geri yükleme için kullanılabilir. Bu anlık görüntüler dört gün boyunca saklanır.
  • Her gün diske ve kasete bir tam yedek kopyalanır.

Cloud KMS ekibi, acil durumlarda yedekleri geri yükleme prosedürlerini belgelemiştir.

Yerleşim. Cloud KMS veri deposu yedekleri ilişkili Google Cloud bölgelerinde tutulur. Bu yedeklerin tümü kullanımda değilken şifrelenir. Yedeklerdeki verilere erişim, erişim gerekçelerine (Google destek kaydıyla gönderdiğiniz bilet numarası gibi) göre verilir ve insanların erişimi Erişim Şeffaflığı günlüklerine kaydedilir.

Koruma. Cloud KMS uygulama katmanında müşterinin anahtar materyali depolanmadan önce şifrelenir. Veri deposu mühendislerinin şifrelenmemiş metnin müşteri anahtarı materyaline erişimi yoktur. Ayrıca veri deposu, yönettiği tüm verileri kalıcı depolama alanına yazmadan önce şifreler. Bu nedenle, diskler veya kasetler de dahil, temel depolama alanı katmanlarına erişim, Google'ın dahili KMS'sinde depolanan veri deposu şifreleme anahtarlarına erişim olmadığında şifrelenmiş Cloud KMS verilerine erişime bile izin vermez.

6. Daha fazla bilgi

Daha fazla bilgi edinmek için aşağıdaki kaynakları keşfedin:

Teknik belgeler:

Diğer belgeler: