Google Cloud'da Geçiş Hâlindeki Verilerin Şifrelenmesi

Bu, Google'ın verilerinizi korumak için şifrelemeyi nasıl kullandığıyla ilgili üçüncü rapordur. Daha önce Google Cloud Platform'da Kullanımda Olmayan Verilerin Şifrelenmesi ve G Suite şifreleme raporlarını yayınlamıştık. Google'da şifreleme kullanımı hakkında bilgi edinmek için bu belgeleri de okumanız işinize yarayabilir. Bu raporda, Google Cloud Platform ve G Suite dahil olmak üzere Google Cloud'da geçiş hâlindeki verilerin şifrelenmesi ile ilgili daha fazla ayrıntı bulacaksınız.

Tüm Google ürünlerinde, müşteri verilerini korumaya ve verilerin güvenliğini sağlama yöntemlerimiz konusunda olabildiğince şeffaf olmaya çalışıyoruz.

Bu raporda bulunan içerik, Aralık 2017 itibarıyla doğrudur. Bu rapor, yazıldığı anda geçerli olan durumu belirtir. Google Cloud olarak müşterilerimiz için sağladığımız korumayı durmadan geliştirdiğimizden, güvenlik politikalarımız ve sistemlerimiz zaman içinde değişebilir.

Google Cloud'da Geçiş Hâlindeki Verilerin Şifrelenmesi

CIO düzeyinde özet

  • Google, geçiş hâlindeki verilerin kimliğini, bütünlüğünü ve gizliliğini korumak için çeşitli güvenlik önlemleri alır.
  • Google, veriler Google tarafından veya Google adına kontrol edilmeyen fiziksel sınırların dışına taşınırken bir veya daha fazla ağ katmanında geçiş hâlindeki tüm verileri şifreleyip doğrular. Geçiş hâlindeki veriler Google tarafından veya Google adına kontrol edilen bir fiziksel sınır içinde bulunuyorsa bu veriler genellikle doğrulanır ancak şifrelenmeyebilir.
  • Google, kurulmakta olan bağlantıya bağlı olarak geçiş hâlindeki verilere varsayılan korumaları uygular. Örneğin, TLS kullanarak kullanıcı ve Google Front End (GFE) arasındaki iletişimlerin güvenliğini sağlarız.
  • WAN üzerinden ek veri şifreleme gereksinimleri olan Google Cloud müşterileri, veriler bir kullanıcıdan uygulamaya veya sanal makineden sanal makineye taşınırken veriler için daha fazla koruma uygulamayı seçebilir. Bu korumalar arasında IPsec tünelleri, Gmail S/MIME, yönetilen SSL sertifikaları ve Istio bulunur.
  • Google, geçiş hâlindeki verilerin her yerde herkes için şifrelenmesine yardımcı olmak amacıyla endüstriyle etkin bir şekilde çalışır. Geçiş hâlindeki verilerin şifrelenmesini ve internette veri güvenliğini teşvik eden Sertifika Şeffaflığı, Chrome API'leri ve güvenli SMTP gibi birçok açık kaynaklı projemiz vardır.
  • Google, geçiş hâlindeki verilerin şifrelenmesinde sektör liderliğini sürdürmeyi planlamaktadır. Bu doğrultuda, şifreleme teknolojisinin geliştirilmesi ve iyileştirilmesi için kaynaklar ayırıyoruz. Bu alandaki çalışmalarımız, Anahtar Şeffaflığı ve post kuantum kriptografi alanlarındaki yenilikleri de içermektedir.

Giriş

Güvenlik, herkese açık bulut tedarikçisi seçiminde genellikle belirleyici bir unsurdur. Google'da güvenlik son derece önemlidir. Verileriniz ister internet üzerinden aktarılıyor ister Google'ın altyapısında taşınıyor ister sunucularımızda saklanıyor olsun, onları korumak için durmadan çalışıyoruz.

Google'ın güvenlik stratejisinin merkezinde, hem kullanımda olmayan hem de geçiş hâlindeki veriler için kimlik doğrulama, bütünlük ve şifreleme bulunmaktadır. Bu makalede, Google Cloud'da geçiş hâlindeki verilerin şifrelenmesine dair yaklaşımımız açıklanmaktadır.

Aktif olmayan veriler için Google Cloud Platform'da Kullanımda Olmayan Verilerin Şifrelenmesi konusuna bakın. Google Güvenliğinin tamamıyla ilgili genel bir bakış için Google Altyapı Güvenliği Tasarımına Genel Bakış konusuna bakın.

Kitle: Bu belge, Google Cloud Platform'u kullanmakta olan veya kullanmayı düşünen CISO'lara ve güvenlik işlemleri ekiplerine yöneliktir.

Ön koşullar: Bu giriş kısmına ek olarak şifreleme ve temel kriptografi öğelerine dair genel bilgiye sahip olduğunuzu varsayarız.

Kimlik Doğrulama, Bütünlük ve Şifreleme

Google, geçiş hâlindeki verilerin kimliğini, bütünlüğünü ve gizliliğini korumak için çeşitli güvenlik önlemleri alır.

  • Kimlik Doğrulama: İster insan ister işlem olsun veri kaynağını ve hedefi doğrularız.
  • Bütünlük: Gönderdiğiniz verilerin, hedeflerine değişmeden ulaştığından emin oluruz.
  • Şifreleme: Verilerinizi geçiş hâlindeyken gizli tutmak için anlaşılmaz hâle getiririz. Şifreleme, düz metnin yalnızca veri sahibi tarafından yetkilendirilen taraflarca erişilebilir olmasını sağlamak amacıyla okunabilir verilerin (düz metin) okunaksız (şifreli metin) hâle getirildiği bir işlemdir. Şifreleme işleminde kullanılan algoritmalar herkese açıktır ancak şifreli metnin şifresini çözmek için gereken anahtar gizlidir. Geçiş hâlindeki verilerin şifrelenmesinde, veri şifreleme için kullanılacak paylaşılan bir simetrik anahtar oluşturmak amacıyla genellikle elips biçimli eğriye dayalı Diffie-Hellman gibi asimetrik anahtar değişimi kullanılır. Şifreleme hakkında daha fazla bilgi için Modern Kriptografiye Giriş konusuna bakın.

Şifreleme, üç durumdaki verileri korumak için kullanılabilir:

  • Kullanımda olmayan verilerin şifrelenmesi, verilerinizi depolanırken şifreleyerek sistemdeki güvenlik ihlallerine veya veri hırsızlığına karşı korur. Kullanımda olmayan verileri şifrelemek için genellikle Gelişmiş Şifreleme Standardı (AES) kullanılır.
  • Geçiş hâlindeki verilerin şifrelenmesi: Siteniz ile bulut sağlayıcısı ya da iki hizmet arasında veri aktarımı gerçekleştirilirken iletişimin kesintiye uğraması durumunda verilerinizi korur. Bu korumanın sağlanması için veriler iletilmeden önce şifrelenir, uç noktalarında kimlik doğrulama yapılır ve gelen verilerin şifreleri çözülüp veriler doğrulanır. Örneğin, Taşıma Katmanı Güvenliği (TLS) genellikle taşıma güvenliği için geçiş hâlindeki verileri şifrelemek için kullanılır. Güvenli/Çok Amaçlı İnternet Posta Uzantıları (S/MIME) ise çoğu zaman e-posta iletilerinin güvenliğini sağlamak için kullanılır.
  • Kullanımda olan verilerin şifrelenmesi: Verilerinizi, sunucular tarafından homomorfik şifreleme gibi hesaplamalar yapmak için kullanıldığı sırada korur.

Şifreleme, daha geniş bir güvenlik stratejisinin küçük bir parçasıdır. Geçiş hâlindeki verilerin şifrelenmesiyle, aşağıdakiler yapılarak bir bağlantı kurulduktan ve doğrulandıktan sonra olası saldırganlara karşı verileriniz korunur:

  • Genellikle üçüncü taraflarca sağlanan ağın alt katmanlarına güvenme ihtiyacını ortadan kaldırma
  • Olası saldırı yüzeyini azaltma
  • İletişimin kesintiye uğraması durumunda saldırganların verilere erişmesini önleme

Yeterli kimlik doğrulama, bütünlük ve şifreleme sayesinde, kullanıcılar, cihazlar veya işlemler arasında gezinen veriler saldırgan bir ortamda korunabilir. Bu makalenin geri kalanında, Google’ın geçiş hâlindeki verileri şifreleme yaklaşımı ve bunun nerede uygulandığı açıklanmaktadır.

Google’ın Ağ Altyapısı

Google ağının fiziksel sınırları

Google, Google tarafından veya Google adına kontrol edilen fiziksel sınırın dışına aktarılan geçiş hâlindeki veriler için farklı korumalar uygular. Fiziksel sınır, Google tarafından veya Google adına kontrol edilen fiziksel bir alanın etrafındaki engeldir. Bu sınır içinde sıkı güvenlik önlemlerinin alınmasını sağlayabiliriz. Bu konumlara erişim kısıtlıdır ve dikkatli bir şekilde izlenir. Google çalışanlarının yalnızca küçük bir kısmı donanıma erişebilir. Bu fiziksel sınırların içinde bulunan geçiş hâlindeki veriler genellikle doğrulanır ancak bu veriler, varsayılan olarak şifrelenmemiş olabilir. Tehdit modelinize göre hangi ek güvenlik önlemlerinin uygulanacağını seçebilirsiniz.

Küresel internetin büyüklüğünden dolayı, WAN'ımızdaki fiber bağlantılar ya da Google tarafından veya Google adına kontrol edilen fiziksel sınırların dışındaki herhangi bir yer için bu fiziksel güvenlik kontrollerini uygulayamayız. Bu nedenle, fiziksel güven sınırlarımızın dışında ek korumaları otomatik olarak uygularız. Bu korumalar arasında geçiş hâlindeki verilerin şifrelenmesi de bulunur.

Trafik nasıl yönlendirilir?

Bir önceki bölümde, Google ağının fiziksel sınırları ve bu sınırın dışına gönderilen verilere nasıl farklı korumalar uyguladığımız ele alınmıştır. Google'da geçiş hâlindeki verilerin nasıl şifrelendiğini tam olarak anlamak için trafiğin internet üzerinden nasıl yönlendirildiğini de öğrenmek gerekir. Bu bölümde, isteklerin bir son kullanıcıdan uygun Google Cloud hizmetine veya müşteri uygulamasına nasıl ulaştığı ve trafiğin hizmetler arasında nasıl yönlendirildiği açıklanmaktadır.

Google Cloud hizmeti, müşterilerimize sunduğumuz modüler bir bulut hizmetidir. Bu hizmetler arasında bilgi işlem, veri depolama, veri analizi ve makine öğrenimi bulunmaktadır. Örneğin, Google Cloud Storage ve Gmail, Google Cloud hizmetleridir. Müşteri uygulaması, Google Cloud'da barındırılan ve Google müşterisi olarak Google Cloud hizmetleriyle oluşturup dağıtabileceğiniz bir uygulamadır. Google Cloud’da barındırılan müşteri uygulamaları veya iş ortağı çözümleri, Google Cloud hizmetleri olarak kabul edilmez1. Örneğin Google App Engine'i, Google Kubernetes Engine'i veya Google Compute Engine'deki bir sanal makineyi kullanarak oluşturduğunuz uygulama, bir müşteri uygulamasıdır.

Aşağıda açıklanan beş yönlendirme isteği türü, Şekil 1'de gösterilmiştir. Bu şekilde, çeşitli ağ bileşenleri ile her bağlantı için uygulanan güvenlik arasındaki etkileşimler gösterilmektedir.

Son kullanıcıdan (internet) Google Cloud hizmetine yönlendirme

Google Cloud hizmetleri, Google Front End (GFE) adlı küresel olarak dağıtılmış bir sistemi kullanarak dünyanın her yerinden gelen istekleri kabul eder. GFE; gelen HTTP(S), TCP ve TLS proxy trafiği için trafiği sonlandırır, DDoS saldırılarına karşı önlemler alır ve Google Cloud hizmetlerine giden trafik için yük dengeleme uygular. Tüm dünyada, tek noktaya yayın veya Anycast ile gösterilen GFE varlık noktaları bulunur.

GFE'ler, trafiği proxy aracılığıyla Google Cloud hizmetlerine yönlendirir. GFE'ler, kullanıcının isteğini ağ omurgamız üzerinden Google Cloud hizmetine yönlendirir. Bu iletişimler Google tarafından veya Google adına kontrol edilen fiziksel bir sınırın dışına çıktığında, bu bağlantı için GFE ile Google Cloud hizmetinin veya müşteri uygulamasının kullanıcı arabirimi arasında kimlik doğrulama ve şifreleme uygulanır. Şekil 1'de bu etkileşim gösterilmiştir (A bağlantısı olarak etkilenmiştir).

Son kullanıcıdan (internet) Google Cloud’da barındırılan bir müşteri uygulamasına yönlendirme

İnternetten gelen trafiği, Google Cloud’da barındırdığınız bir müşteri uygulamasına yönlendirmenin çeşitli yolları vardır. Trafiğinizin yönlendirilme şekli, aşağıda açıklandığı gibi yapılandırmanıza bağlıdır. Şekil 1'de bu etkileşim gösterilmiştir (B bağlantısı olarak etkilenmiştir).

  • Google Cloud HTTP(S) veya TCP/SSL proxy Yük Dengeleyici harici yük dengeleyici kullanma: Google Compute Engine sanal makinelerinde barındırılan bir müşteri uygulaması HTTP(S), TLS veya TCP bağlantılarını sonlandırmak ve proxy kullanıp bu trafiği sanal makinelerine yönlendirip dağıtmak için Google Cloud Yük Dengeleyici (GCLB) hizmetini kullanabilir. GFE'ler Google Cloud hizmetleri için trafiği sonlandırıp yönlendirse de bu yük dengeleyici hizmetleri, GFE'ler tarafından uygulanır. GCLB trafiği GFE'ler arasında yönlendirdiğinde, trafik Google tarafından veya Google adına kontrol edilen bir fiziksel sınırın dışına çıkarken bağlantılar doğrulanır ve şifrelenir. GCLB trafiği bir GFE ile müşterinin sanal makinesini barındıran fiziksel bir makine arasında yönlendirdiğinde, bu trafik Google tarafından veya Google adına kontrol edilen bir fiziksel sınırın dışına çıkarken doğrulanır ve şifrelenir. HTTPS yük dengeleyicileri için son kullanıcılar ile GFE arasındaki bağlantılar, müşterilerin yük dengeleyici için sağladığı sertifikalar kullanılarak TLS veya QUIC ile şifrelenir ve doğrulanır. HTTP yük dengeleyicileri için son kullanıcılar ile GFE arasındaki bağlantılar şifrelenmez veya doğrulanamaz. SSL yük dengeleyicileri için son kullanıcılar ile GFE arasındaki bağlantılar, yine müşteri tarafından sağlanan sertifikalar kullanılarak TLS ile şifrelenir. TCP yük dengeleyicileri için son kullanıcı ve GFE arasında şifreleme uygulanmaz. Bununla birlikte, müşterinin uygulaması son kullanıcı ve sanal makineler arasında kendi şifrelemesini uygulayabilir.
  • Harici bir IP veya ağ yük dengeleyici IP kullanarak doğrudan bir sanal makineyle bağlantı kurma: Sanal makinenin harici IP'si veya ağ yükü dengeli bir IP üzerinden bağlantı kuruyorsanız bağlantı GFE'den geçmez. Bu bağlantı, varsayılan olarak şifrelenmez ve bağlantının güvenliği kullanıcının isteği doğrultusunda sağlanır.
  • Cloud VPN'i kullanma: VPN aracılığıyla şirketinizdeki bir ana makine ile Google Cloud sanal makinesi arasında bağlantı kuruyorsanız bağlantı şirketinizdeki ana makineden/ana makineye, şirketinizdeki VPN'e, Google VPN'e, Google Cloud sanal makinesine gider. Bağlantı GFE'den geçmez. Şirket içindeki VPN ile Google VPN arasındaki bağlantı IPsec ile korunur. Google VPN ile Google Cloud sanal makinesi arasındaki bağlantı, Google tarafından veya Google adına kontrol edilen fiziksel bir sınırın dışına çıkarken doğrulanıp şifrelenir.
  • Cloud Özel Ara Bağlantısı'nı kullanma: Özel Ara Bağlantı üzerinden bağlantı kuruyorsanız bağlantı doğrudan şirketinizdeki ana makineden/ana makineye gider ve GFE'den geçmez. Bu bağlantı, varsayılan olarak şifrelenmez ve bağlantının güvenliği kullanıcının isteği doğrultusunda sağlanır.

Sanal Makineden Sanal Makineye yönlendirme

RFC 1918 özel IP adresleri kullanılarak ağ omurgamızda gerçekleşen sanal makineden sanal makineye yönlendirme, trafiğin Google tarafından veya Google adına kontrol edilen fiziksel sınırların dışına yönlendirilmesini gerektirebilir. Sanal makineden sanal makineye yönlendirme örnekleri arasında şunlar yer alır:

  • Birbirine istek gönderen Compute Engine sanal makineleri
  • Cloud SQL gibi Google tarafından yönetilen bir sanal makineye bağlanan müşteri sanal makinesi

Sanal makineler arasındaki bağlantılar, fiziksel sınırın dışına çıktıkları takdirde şifrelenir ve fiziksel sınırın içinde doğrulanır. Genel IP adresleri kullanan sanal makineler arasındaki trafik, varsayılan olarak şifrelenmez ve trafiğin güvenliği kullanıcının isteği doğrultusunda sağlanır. Şekil 1'de bu etkileşim gösterilmiştir (C bağlantısı olarak etkilenmiştir).

Sanal Makineden Google Cloud hizmetine yönlendirme

Sanal Makine bir isteği Google Cloud hizmetine yönlendirirse istek GFE'ye yönlendirilir (Google Cloud hizmetinin, yukarıda açıklandığı gibi Google tarafından yönetilen bir sanal makinede çalıştırıldığı durumlar haricinde). GFE isteği alır ve internetten gelen isteklerde olduğu gibi yönlendirir: istek, sanal makineden Google Cloud hizmetine giden trafik için GFE'ler ile aynı genel IP'lere giden özel Google yolları üzerinden yönlendirilir. Özel Google erişimi, genel IP'leri olmayan sanal makinelerin bazı Google Cloud hizmetlerine ve Google App Engine'de barındırılan müşteri uygulamalarına erişmesine izin verir. (Sanal makine Google Compute Engine'da veya Google Kubernetes Engine'de barındırılan bir müşteri uygulamasına bağlanıyorsa bu trafik, internetten gelen isteklerle aynı şekilde harici yollar üzerinden yönlendirilir.) Şekil 1'de bu etkileşim gösterilmiştir (D bağlantısı olarak etkilenmiştir). Böyle bir istek yönlendirme türüne örnek olarak Compute Engine sanal makinesi ile Google Cloud Storage veya Makine Öğrenimi API'si arasında yönlendirme verilebilir. Google Cloud hizmetleri, varsayılan olarak bu bağlantıların TLS ile korunmasını destekler2. Bu koruma, sanal makineden GFE'ye yönlendirme sırasında uygulanır. Bağlantı, fiziksel sınırın dışına çıkarsa GFE ile hizmet arasında doğrulanır ve şifrelenir.

Google Cloud hizmetinden Google Cloud hizmetine yönlendirme

Bir üretim hizmetinden diğerine yönlendirme, ağ omurgamızda gerçekleşir ve trafiğin Google tarafından veya Google adına kontrol edilen fiziksel sınırların dışına yönlendirilmesini gerektirebilir. Şekil 1'de bu etkileşim gösterilmiştir (E bağlantısı olarak etkilenmiştir). Bu tür bir trafiğe örnek olarak Google Cloud Functions'ı tetikleyen Google Cloud Storage etkinliği verilebilir. Üretim hizmetleri arasındaki bağlantılar, fiziksel sınırın dışına çıktıkları takdirde şifrelenir ve fiziksel sınırın içinde doğrulanır.

Şekil 1: Varsayılan koruma ve Google ağının üzerinde gösterilen seçenekler

Geçiş Hâlindeki Verilerin Varsayılan Olarak Şifrelenmesi

Google, geçiş hâlindeki veriler için hem varsayılan olarak uygulanan hem de kullanıcı tarafından yapılandırılabilen çeşitli şifreleme türleri kullanır. Kullanılan şifreleme türü; OSI katmanına, hizmet türüne ve altyapının fiziksel bileşenine bağlıdır. Aşağıdaki şekil 2 ve 3'te, Google Cloud'un 3., 4. ve 7. katmanlar için uyguladığı isteğe bağlı ve varsayılan korumalar gösterilmektedir.

Şekil 2: Google Cloud'da Varsayılan Koruma ve 3. ve 4. Katmandaki Seçenekler

Şekil 3: Google Cloud'da Varsayılan Koruma ve 7. Katmandaki Seçenekler3

Bu bölümün geri kalanında, Google'ın geçiş hâlindeki verileri korumak için kullandığı varsayılan korumalar açıklanmıştır.

Kullanıcı ile Google Front End arasında şifreleme

Günümüzde birçok sistem, internet üzerinden iletişim kurmak için HTTPS protokolünü kullanmaktadır. HTTPS, protokolü TLS bağlantısı üzerinden yönlendirip isteklerin ve yanıtların gerçekliğini, bütünlüğünü ve gizliliğini sağlayarak güvenliği sağlar. Alıcı, HTTPS isteklerini kabul etmek için herkese açık-özel anahtar çifti ve Sertifika Yetkilisinden (CA) sunucu doğrulamasına yönelik X.509 sertifikası gerektirir. Anahtar çifti ve sertifika, kullanıcı isteklerinin gönderildiği alan adının alıcıya ait olduğunu kanıtlayarak uygulama katmanında (7. katman) kullanıcı isteklerinin korunmasına yardımcı olur. Aşağıdaki alt bölümlerde, kullanıcı ile GFE arasında şifrelemenin bileşenleri, yani TLS, BoringSSL ve Google'ın Sertifika Yetkilisi ele alınmaktadır. Tüm müşteri yollarının GFE ile yönlendirilmediğini hatırlayın. Özellikle de GFE'nin, bir kullanıcıdan Google Cloud hizmetine giden ve bir kullanıcıdan Google Cloud'da barındırılan ve Google Cloud Yük Dengeleme kullanan bir müşteri uygulamasına giden trafik için kullanıldığını unutmayın.

Taşıma Katmanı Güvenliği (TLS)

Bir kullanıcı Google Cloud hizmetine istek gönderdiğinde, kimlik doğrulama, bütünlük ve şifreleme sağlayarak ve web'deki (herkese açık) sertifika yetkilisinden alınan sertifikayla HTTPS protokolünü kullanarak geçiş hâlindeki verilerin güvenliğini sağlarız. Kullanıcının GFE'ye gönderdiği tüm veriler, geçiş sırasında Taşıma Katmanı Güvenliği (TLS) veya QUIC ile şifrelenir. GFE, istemcinin destekleyebileceklerine bağlı olarak istemci ile belirli bir şifreleme protokolü üzerinde anlaşır. GFE, mümkün olduğunda daha modern şifreleme protokolleri üzerinde anlaşma yapar.

GFE'nin ölçeklendirilmiş TLS şifrelemesi, Google ile kurulan son kullanıcı etkileşimlerinde uygulanmanın yanı sıra Google Cloud dahil TLS üzerinden Google ile kurulan API etkileşimlerini de kolaylaştırır. TLS şifrelememiz, harici posta sunucularıyla e-posta alışverişi için Gmail'de de kullanılır (daha fazla ayrıntıyı Gmail'de TLS'yi Gerekli Kılma bölümünde bulabilirsiniz).

Google, hem TLS'nin benimsenmesinde hem de uygulanmasının güçlendirilmesinde sektör lideridir. Bu doğrultuda, TLS'nin güvenlik özelliklerinin çoğunu varsayılan olarak etkin hâle getirdik. Örneğin, 2011'den beri TLS uygulamasında iletim gizliliği kullanıyoruz. İletim gizliliği, bağlantıyı koruyan anahtarın kalıcı olmamasını sağlar. Böylece araya girip bir iletiyi okuyan saldırgan, önceki iletileri okuyamaz.

BoringSSL

BoringSSL, TLS protokolünün Google tarafından yönetilen açık kaynaklı bir uygulamasıdır. Bu uygulama, OpenSSL'den çatallanır ve arayüzü OpenSSL ile büyün oranda uyumludur. Google, hem şirket içinde kullanmak hem de Açık Kaynaklı Chromium ve Android Projelerine daha iyi destek vermek için BoringSSL'yi OpenSSL'den çatallandırmıştır. BoringSSL'nin temelini oluşturan BoringCrypto, FIPS 140-2 seviye 1 ile doğrulanmıştır.

GFE'de TLS, BoringSSL ile uygulanır. Tablo 1'de, GFE'nin istemcilerle iletişim kurarken desteklediği şifreleme protokolleri gösterilmektedir.

Protokoller Kimlik Doğrulama Anahtar Değişimi Şifreleme Karma İşlevler
TLS 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

Tablo 1: Google Cloud Hizmetleri için Google Front End'de ve BoringSSL Şifreleme Kitaplığında Uygulanan Şifreleme

Google’ın Sertifika Yetkilisi

TLS'nin parçası olarak, sunucu bir bağlantı isteği aldığında kimliğini kullanıcıya kanıtlamalıdır. Bu kimlik doğrulaması, sunucunun söz konusu kimliği içeren bir sertifika sunmasıyla TLS protokolünde gerçekleştirilir. Sertifika, hem sunucunun DNS ana makine adını ve hem de genel anahtarını içerir. Sertifika sunulduğunda, bağlantıyı isteyen kullanıcının güvendiği, sertifikayı düzenleyen Sertifika Yetkilisi (CA) tarafından imzalanır10. Sonuç olarak, sunucuyla bağlantı kurmak isteyen kullanıcıların yalnızca kök CA'ya güvenmesi gerekir. Sunucunun her yerden erişilmesi isteniyorsa kök CA'nın tüm dünyadaki istemci cihazları tarafından tanınması gerekir. Günümüzde, çoğu tarayıcı ve diğer TLS istemci uygulamaları, "kök depolarında" güvenilir olarak yapılandırılan kendi kök CA gruplarına sahiptir.

Google'ın geçmişte kendi sertifika düzenleyen CA'sı olmuştur. Bu CA'yı, Google alanları için sertifikaları imzalamak amacıyla kullanıyorduk. Ancak kendi kök CA'mız olmamıştır. Bugün CA sertifikalarımız, Symantec (“GeoTrust”) ve daha önce GlobalSign (“GS Root R2” ve “GS Root R4”) tarafından yönetilen kökler de dahil olmak üzere her yerde dağıtılan birden fazla kök CA tarafından çapraz olarak imzalanmaktadır.

Haziran 2017’de, Google’a ait kök CA’ları kullanmaya başlayacağımızı duyurduk. Zaman içinde, Google alanları ve müşterilerimiz için sertifika verecek, her yerde dağıtılan bir kök CA kullanmayı planlıyoruz.

Kök anahtar geçişi ve anahtar rotasyonu

Kök CA anahtarları sık sık değiştirilmez çünkü yeni kök CA'ya geçiş için tüm tarayıcıların ve cihazların sertifikanın güvenini eklemesi gerekir ve bu işlem uzun sürer. Sonuç olarak, Google artık kendi kök CA'larını kullansa da kendi CA'larımıza geçerken eski cihazları da dikkate almak için geçici bir süre boyunca birden fazla üçüncü taraf kök CA ile çalışmaya devam edeceğiz.

Yeni bir kök CA oluşturmak için anahtar seremonisi gerekir. Google'da bu seremoni için olası 6 yetkili kişiden en az 3'ünün bir kasada saklanan donanım anahtarlarını kullanmak amacıyla fiziksel olarak bir araya gelmesi gerekir. Bu kişiler, bir dizi anahtar ve sertifika oluşturmak için elektromanyetik girişimden korunan, hava boşluklu Donanım Güvenlik Modülü (HSM) içeren özel bir odada bir araya gelir. Özel oda, Google veri merkezlerindeki güvenli bir konumda yer alır. Fiziksel güvenlik önlemleri, kameralar ve diğer gözlemciler gibi ek kontroller, sürecin planlandığı gibi gitmesini sağlar. Seremoni başarılı olursa oluşturulan sertifika; düzenleyen kişinin adı, genel anahtar ve imza dışında örnek sertifikaya benzer olur. Ortaya çıkan kök CA sertifikası, daha sonra eklenmesi için tarayıcı ve cihaz kök programlarına gönderilir. Bu süreç, ilişkili özel anahtarların gizliliğinin ve güvenliğinin iyi anlaşılmasını ve böylece anahtarlara on yıl veya daha uzun bir süre güvenilmesini sağlamak için tasarlanmıştır.

Daha önce açıklandığı gibi, CA'lar sertifikaları imzalamak için kendi özel anahtarlarını kullanır ve bu sertifikalar, kullanıcı oturumunun parçası olarak TLS el sıkışması başlatırken kimlikleri doğrular. Sunucu sertifikaları, ara CA'larla imzalanır. Bunlar, kök CA'ya benzer şekilde oluşturulur. Ara CA'ların sertifikaları, TLS oturumunun parçası olarak dağıtılır. Böylece yeni ara CA'ya geçiş daha kolay hâle gelir. Bu dağıtım yöntemi, CA operatörünün kök CA anahtar malzemesini çevrimdışı durumda tutmasını da sağlar.

TLS oturumunun güvenliği, sunucu anahtarının ne kadar iyi korunduğuna bağlıdır. Anahtar güvenliğinin ihlal edilme riskini daha da azaltmak için Google'ın TLS sertifikalarının kullanım ömrü, yaklaşık üç ay ile sınırlandırılmıştır ve sertifikalara yaklaşık iki haftada bir rotasyon uygulanır.

Daha önce bir sunucuya bağlanan istemci, kısaltılmış TLS el sıkışması ile önceki oturuma devam etmek için özel bilet anahtarı11 kullanabilir. Bu nedenle, bu biletler bir saldırgan için çok değerli hâle gelir. Google, en az günde bir kez bilet anahtarlarına rotasyon uygular ve 3 günde bir tüm mülklerde anahtarların geçerliliğini kaldırır. Oturum anahtarı bilet rotasyonu hakkında daha fazla bilgi için TLS Şifreleme Kısayollarının Güvenliğe Verdiği Zararı Ölçme konusuna bakın.

Google Front End'den Uygulama Ön Uçlarına Yönlendirme

Trafik nasıl yönlendirilir? konusunda açıklandığı gibi bazı durumlarda, kullanıcı istenen hizmetten ve ilişkili Uygulama Ön Ucundan farklı bir fiziksel sınırın içinden GFE'ye bağlanır. Bu durumda, kullanıcının isteği ve HTTP gibi başka bir 7. katman protokolü, TLS tarafından korunur veya Hizmetten hizmete kimlik doğrulama, bütünlük ve şifreleme bölümünde açıklanan Uygulama Katmanı Taşıma Güvenliği (ALTS) kullanılarak korunan bir RPC'ye kapsüllenir. Bu RPC'ler doğrulanır ve şifrelenir.

Google Cloud hizmetleri için RPC'ler varsayılan olarak ALTS ile korunur. Google Cloud'da barındırılan müşteri uygulamaları için Google Cloud Yük Dengeleyici'nin kullanılması gibi durumlarda trafik Google Front End üzerinden yönlendirilirse sanal makineye giden trafik, sonraki bölümde açıklanan Google Cloud'un sanal ağ şifrelemesi kullanılarak korunur.

Google Cloud’un sanal ağ şifrelemesi ve kimlik doğrulaması

Google Cloud'un sanal ağ altyapısı, trafik fiziksel sınırlarımızın dışına çıktığında şifreleme yapılmasını sağlar. Şifreleme, ağ katmanında gerçekleştirilir ve aynı Sanal Özel Bulut (VPC) veya eşleşen VPC ağlarında bulunan özel IP trafiğine uygulanır.

Google tarafından veya Google adına kontrol edilmeyen fiziksel sınırı aşan herhangi bir ağın güvenliğinin, aktarım trafiğini gizlice gözetleyebilecek, trafiğe veri ekleyebilecek veya trafiği değiştirilebilecek kötü niyetli bir kişi tarafından ihlal edilebileceğini varsayarız. Veriler, kontrol etmediğimiz fiziksel sınırların dışına çıktığında şifreleme kullanarak iletişimin bütünlüğünü ve gizliliğini sağlarız.

Ağ katmanında şifreleme uygulamak için Galois/Counter Mode'da (GCM) 128 bit anahtarla (AES-128-GCM) Gelişmiş Şifreleme Standardını (AES) kullanırız. Her iletişim ana makinesi çifti, kimliği doğrulanmış ve şifrelenmiş iletişimler için ALTS tarafından korunan kontrol kanalı üzerinden bir oturum anahtarı oluşturur. Oturum anahtarı, bu sanal makineler arasındaki tüm sanal makineden sanal makineye iletişimleri şifrelemek için kullanılır ve tüm oturum anahtarlarına düzenli olarak rotasyon uygulanır.

Ağ katmanında (3. katman) Google Cloud'un sanal ağı, sanal makineler arasındaki tüm trafiği doğrular. Güvenlik jetonları aracılığıyla yapılan bu kimlik doğrulaması, güvenliği ihlal edilmiş bir ana makineyi ağdaki adres sahteciliği paketlerine karşı korur.

Kimlik doğrulama sırasında, güvenlik jetonları gönderen ve alıcı hakkında kimlik doğrulama bilgileri içeren bir tünel başlığına kapsüllenir. Gönderen taraftaki kontrol düzlemi12 jetonu ayarlar ve jetonu alan ana makine onu doğrular. Güvenlik jetonları her akış için önceden oluşturulur ve bir jeton anahtarı (gönderenin bilgilerini içerir) ve ana makine gizli anahtarından oluşur. Google tarafından veya Google adına kontrol edilen fiziksel sınırların her kaynak-alıcı çifti için bir gizli anahtar mevcuttur. Şekil 4'te jeton anahtarlarının, ana makine gizli anahtarlarının ve güvenlik jetonlarının nasıl oluşturulduğu gösterilmiştir.

Şekil 4: Güvenlik Jetonları

Fiziksel sınır gizli anahtarı, 128 bitlik sözde rastgele bir sayıdır. Bu sayıdan, HMAC-SHA1 alınarak ana makine gizli anahtarları türetilir. Fiziksel sınır çiftinin ağ kontrol düzlemleri arasında yapılan el sıkışması ile fiziksel sınır gizli anahtarı üzerinde anlaşılır ve birkaç saatte bir anlaşma yenilenir. Bu giriş ve diğer girişlerden türetilen her bir sanal makineler arası kimlik doğrulama için kullanılan güvenlik jetonları, belirli bir gönderen ve alıcı çifti için anlaşılan HMAC'lerdir.

Hizmetten hizmete kimlik doğrulaması, bütünlük ve şifreleme

Google'ın altyapısındaki uygulama katmanında (7. katman), GFE'den bir hizmete ve hizmetten hizmete yapılan Google RPC çağrılarının kimlik doğrulaması, bütünlüğü ve şifrelenmesi için Uygulama Katmanı Taşıma Güvenliğimizi (ALTS) kullanırız.

ALTS, kimlik doğrulama için hizmet hesaplarını kullanır. Google’ın altyapısında çalışan her hizmet, ilişkili şifreleme kimlik bilgileriyle birlikte bir hizmet hesabı kimliği olarak çalışır. RPC'ler oluşturulurken veya başka hizmetlerden RPC'ler alınırken, hizmet kimlik doğrulama için kimlik bilgilerini kullanır. ALTS, dahili bir sertifika yetkilisi kullanarak bu kimlik bilgilerini doğrular.

Google tarafından veya Google adına kontrol edilen fiziksel sınır içinde ALTS, "kimlik doğrulama ve bütünlük" modunda RPC'ler için hem kimlik doğrulama hem de bütünlük sağlar. ALTS, WAN üzerinden Google tarafından veya Google adına kontrol edilen fiziksel sınırların dışına giden trafik için "kimlik doğrulama, bütünlük ve gizlilik" modunda otomatik olarak altyapı RPC trafiğine yönelik şifreleme uygular. Şu anda Google Cloud hizmetleri dahil Google hizmetlerine giden tüm trafik, bu korumalardan yararlanmaktadır.

ALTS, Google Front End'den Uygulama Ön Ucuna giden trafik için altyapı RPC mekanizmalarında HTTP gibi diğer 7. katman protokollerini kapsüllemek için de kullanılır. Bu koruma, uygulama katmanının yalıtımını sağlar ve ağ yolunun güvenliği üzerindeki her türlü bağımlılığı ortadan kaldırır.

Hizmetler, Google tarafından veya Google adına kontrol edilen fiziksel sınırlar içinde bile ALTS iletişimlerini yalnızca "kimlik doğrulama, bütünlük ve gizlilik" modunda kabul edecek ve gönderecek şekilde yapılandırılabilir. Bunun bir örneği, Google’ın altyapısındaki kullanımda olmayan verileri korumak için kullanılan şifreleme anahtarlarını depolayan ve yöneten Google’ın dahili anahtar yönetim hizmetidir.

ALTS Protokolü

ALTS, karşılıklı TLS'ye benzer bir güvenli el sıkışma protokolüne sahiptir. ALTS kullanarak iletişim kurmak isteyen iki hizmet, hassas bilgi göndermeden önce iletişim parametrelerinin kimliğini doğrulamak ve üzerinde anlaşmak için bu el sıkışma protokolünü uygular. Protokol iki adımlı bir süreçtir:

  • 1. Adım: El Sıkışması İstemci, Curve25519'u kullanarak sunucuyla eliptik biçimli eğri Diffie Hellman (ECDH) el sıkışması başlatır. İstemci ve sunucu, Diffe Hellman anahtarı değişimi sırasında kullanılan sertifikalarının parçası olarak onaylı ECDH genel parametrelerine sahiptir. El sıkışma, istemcide ve sunucuda bulunan ortak bir trafik anahtarıyla sonuçlanır. Sertifikalardan gelen eş kimlikler, kimlik doğrulama kararlarında kullanılmak üzere uygulama katmanına aktarılır.
  • 2. Adım: Şifrelemeyi kaydetme Veriler, 1. adımdaki ortak trafik anahtarı kullanılarak istemciden sunucuya güvenli bir şekilde iletilir. ALTS'de şifreleme, BoringSSL ve diğer şifreleme kitaplıkları kullanılarak uygulanır. Şifreleme, genellikle AES-128-GCM'dir. Bütünlük ise AES-GCM'nin GMAC'si tarafından sağlanır.

Aşağıdaki Şekil 5'te, ALTS el sıkışması ayrıntılı olarak gösterilmiştir. Daha yeni uygulamalarda, el sıkışmalarını süreç yardımcısı yapar. Bunun hâlâ uygulamalar tarafından yapıldığı bazı durumlar da var.

Şekil 5: ALTS El Sıkışması

Hizmetten hizmete kimlik doğrulama, bütünlük ve şifreleme konusunun başında açıklandığı gibi, ALTS Google'ın altyapısında ilişkili şifreleme kimlik bilgileriyle birlikte bir hizmet kimliği olarak çalışan her hizmetle kimlik doğrulama için hizmet hesaplarını kullanır. ALTS el sıkışması sırasında, süreç yardımcısı her istemci-sunucu çiftinin iletişimlerde kullandığı özel anahtarlara ve ilgili sertifikalara erişir. Hizmetin hesap kimliği için özel anahtar ve ilgili sertifika (protokol arabelleği tarafından imzalanır) sağlanmıştır.

ALTS Sertifikaları Birden çok ALTS sertifikası türü vardır:

  • Makine sertifikaları: Belirli bir makinede temel hizmetler için kimlik sağlar. Bunlara, yaklaşık 6 saatte bir rotasyon uygulanır.
  • Kullanıcı sertifikaları: Google mühendisi geliştirme kodu için bir son kullanıcı kimliği sağlar. Bunlara, yaklaşık 20 saatte bir rotasyon uygulanır.
  • Borg iş sertifikaları: Google’ın altyapısında çalışan işler için bir kimlik sağlar. Bunlara, yaklaşık 48 saatte bir rotasyon uygulanır.

Kök sertifika imzalama anahtarı, Google'ın dahili sertifika yetkilisinde (CA) depolanır. Bu, harici CA'mızdan farklı ve bağımsızdır.

ALTS'de şifreleme

ALTS'de şifreleme, kullanılan makinelere bağlı olarak çeşitli algoritmalarla uygulanabilir. Örneğin, çoğu hizmet AES-128-GCM'yi kullanır13. ALTS şifrelemesi hakkında daha fazla bilgiye Tablo 2'den ulaşabilirsiniz.

Makineler Kullanılan ileti şifreleme  
En yaygın AES-128-GCM  
Sandy Bridge veya daha eski AES-128-VCM GMAC yerine bir VMAC kullanır ve bu eski makinelerde biraz daha verimlidir.

Tablo 2: ALTS'de şifreleme

Çoğu Google hizmeti, ALTS'yi veya ALTS kullanan RPC kapsüllemeyi kullanır. ALTS'nin kullanılmadığı durumlarda, diğer korumalar kullanılır. Örneğin:

  • Bazı alt düzey makine yönetimi ve önyükleme hizmetleri SSH'yi kullanır
  • Bazı alt yüzey altyapı günlük kaydı hizmetleri TLS veya Datagram TLS'yi (DTLS) kullanır14
  • TCP dışı taşıma kullanan bazı hizmetler, Google tarafından veya Google adına kontrol edilen fiziksel sınırlar içinde diğer şifreleme protokolleri veya ağ düzeyinde korumaları kullanır

Sanal makineler ve Google Cloud Platform hizmetleri arasındaki iletişimler, Google Front End ile iletişim kurmak için ALTS'yi değil TLS'yi kullanır. Bu iletişimler, Sanal makineden Google Front End'e şifreleme konusunda açıklanmıştır.

Sanal makineden Google Front End'e şifreleme

Sanal makineden GFE'ye giden trafik, Google hizmetlerine ulaşmak için harici IP'leri kullanır. Bununla birlikte, Gizli Google Erişimi özelliğini istekler için yalnızca Google'a ait IP adreslerini kullanacak şekilde yapılandırabilirsiniz.

Harici bir kullanıcıdan Google'a gelen taleplerde olduğu gibi, sanal makineden GFE'ye giden TLS trafiğini varsayılan olarak destekliyoruz. Bağlantı, diğer harici bağlantılarla aynı şekilde kurulur. TLS hakkında daha fazla bilgi için Taşıma Katmanı Güvenliği (TLS) konusuna bakın.

Geçiş hâlindeki verilerin şifrelenmesi için kullanıcı tarafından yapılandırılabilen seçenekler

Geçiş Hâlindeki Verilerin Şifrelenmesi bölümünde, Google'ın geçiş hâlindeki veriler için uyguladığı varsayılan korumalar açıklanmıştır. Bu bölümde, kullanıcılarımızın bu varsayılan korumalarda yapabileceği yapılandırmalar açıklanmaktadır.

Şirket içi veri merkezinden Google Cloud’a

GCLB harici yük dengeleyicileri kullanan TLS

Bulut hizmetiniz bir Google HTTPS veya SSL Proxy harici yük dengeleyici kullanıyorsa GFE, sağladığınız ve kontrol ettiğiniz SSL sertifikalarını kullanarak kullanıcılarınızın gelen TLS bağlantılarını sonlandırır. Sertifikanızı özelleştirme hakkında daha fazla bilgiyi SSL Sertifikaları belgelerinde bulabilirsiniz.

Google Cloud VPN kullanan IPsec tüneli

Bir Google Cloud müşterisi olarak, şirket içi ağınızı bir IPsec VPN bağlantısı (3. katman) üzerinden Google Cloud Platform Sanal Özel Bulut (VPC) ağınıza güvenli bir şekilde bağlamak için Google Cloud VPN'i kullanabilirsiniz. İki ağ arasındaki trafik bir VPN ağ geçidi tarafından şifrelenir ve bu şifre diğer VPN ağ geçidi tarafından çözülür. Bu, internet üzerinde verilerinizi korur. Ayrıca, birden fazla VPN ağ geçidi ile birden fazla yük dengeli tünel oluşturabilirsiniz. Google Cloud VPN, verilerinizi aşağıdaki yollarla korur:

  • Sanal makinelerinizden Cloud VPN'e giden paketler, Google'ın ağı içinde kalır. Bu paketler, Google tarafından veya Google adına kontrol edilen fiziki sınırların dışına çıkarlarsa Google Cloud'un sanal ağı tarafından şifrelenir.
  • Cloud VPN'den şirket içi VPN'inize giden paketler, IPsec tüneli kullanılarak şifrelenir ve doğrulanır.
  • Şirket VPN'nizden şirket içi ana makinelerinize giden paketler, ağınızda uyguladığınız kontrollerle korunur.

Bir VPN kurmak için barındırılan hizmetin VPC ağında Cloud VPN ağ geçidi ve tünel oluşturun, ardından ağlar arasında trafiğe izin verin. İsterseniz iki VPC arasında da bir VPN kurabilirsiniz.

VPN tüneliniz için İnternet Anahtar Değişimi15 (IKE) sürümünü belirterek ağınızı daha da özel hâle getirebilirsiniz. IKE'nin, IKEv1 ve IKEv2 olmak üzere seçebileceğiniz iki sürümü vardır. Her bir sürüm, farklı şifreleri destekler. IKEv1'i belirtirseniz Google AES-128-CBC'yi kullanarak paketleri şifreler ve SHA-1 HMAC16 ile bütünlük sağlar. IKEv2 için çeşitli şifreler kullanılabilir ve desteklenir. Her durumda, Google Cloud VPN eş cihazların desteklediği en güvenli ortak protokol için anlaşma yapar. VPN kurma hakkındaki tüm talimatları, VPN Yönlendirme Seçeneği Belirleme belgelerimizde bulabilirsiniz.

IPsec tünelinin alternatiflerden biri Google Cloud Özel Ara Bağlantısı'dır. Özel Ara Bağlantı, şirket içi ağınız ve Google'ın ağı arasında doğrudan fiziksel bağlantılar ve RFC 1918 iletişimi sağlar. Bu bağlantı üzerinden geçişi yapılan veriler, varsayılan olarak şifrelenmez. Bu nedenle bu verilerin güvenliği, örneğin TLS kullanılarak uygulama katmanında sağlanmalıdır. Google Cloud VPN ve Google Cloud Ara Bağlantısı, Özel Ara Bağlantı ile IPsec VPN şifrelemesini kullanabilmeniz için aynı bağlantı noktasını kullanır. Ancak bunu yapabilmek için üçüncü taraf bir çözümü kullanmanız gerekir. MACsec (2. katman koruması) şu anda desteklenmemektedir.

Kullanıcıdan Google Front End'e

Yönetilen SSL sertifikaları: Ücretsiz ve otomatik sertifikalar

Google Cloud'da bir uygulama oluştururken, kullandığınız SSL sertifikasını yapılandırarak GFE'nin TLS desteğinden yararlanabilirsiniz. Örneğin, TLS oturumunun uygulamanızda sonlandırılmasını sağlayabilirsiniz. Bu sonlandırma, GCLB harici yük dengeleyicileri kullanan TLS konusunda açıklanan TLS sonlandırmasından farklıdır.

Ayrıca Google, hem Firebase Hosting hem de Google App Engine özel alanlarında ücretsiz ve otomatik SSL sertifikaları sağlar. Bu sertifikalar, yalnızca Google tarafından barındırılan mülkler için kullanılabilir. Google App Engine özel alan adlarıyla, kendi SSL sertifikalarınızı da sağlayabilir ve bir HTTPS Katı Taşıma Protokolü (HSTS) başlığını kullanabilirsiniz.

Alan adınız Google'ın altyapısına yönlendirildikten sonra, güvenli iletişim sağlamak amacıyla söz konusu alan adı için bir sertifika isteyip alırız. 2048 bit RSA veya secp256r1 ECC olan TLS sunucusu özel anahtarlarını yönetir ve müşterilerimiz adına sertifikaları yenileriz.

Gmail'de TLS'yi Gerekli Kılma

Taşıma Katmanı Güvenliği bölümünde aktardığımız gibi, Gmail varsayılan olarak TLS kullanır. Gmail, bir e-postanın oluşturduğu son durağın bir TLS oturumu üzerinde olup olmadığını kaydeder ve görüntüler17. Bir Gmail kullanıcısı başka bir Gmail kullanıcısıyla e-posta değişimi yaptığında, e-postalar TLS ile korunur veya bazı durumlarda doğrudan uygulama içinde gönderilir. Böyle durumlarda, Gmail uygulaması tarafından kullanılan RPC'ler Hizmetten hizmette kimlik doğrulaması, bütünlük ve şifreleme konusunda açıklandığı gibi ALTS ile korunur. Gmail, diğer e-posta sağlayıcılarından gelen iletiler için TLS'yi gerekli kılmaz. Gmail yöneticileri, Gmail'i tüm gelen ve giden e-postalar için güvenli TLS bağlantısı gerektirecek şekilde yapılandırabilir.

Gmail S/MIME

Güvenli/Çok Amaçlı İnternet Posta Uzantıları (S/MIME); kimlik doğrulama, bütünlük ve şifreleme sağlayan bir e-posta güvenliği standardıdır. S/MIME standardının uygulanması, e-posta gönderen kullanıcılarla ilişkili sertifikaların genel CA'da barındırılmasını gerekli kılar.

Yönetici olarak, Gmail'i giden e-postalar için S/MIME'yi etkinleştirecek şekilde yapılandırabilir, içerik ve ek uyumluluğu için politikalar oluşturabilir ve gelen ve giden e-postalar için yönlendirme kuralları oluşturabilirsiniz. Yapılandırıldığında, Gmail API'yi kullanarak kullanıcıların genel sertifikalarını Gmail'e yüklemeniz gerekir. Gmail'in dışındaki kullanıcılar için ilk S/MIME imzalı ileti değiştirilerek S/MIME'in varsayılan olarak ayarlanması gerekir.

Hizmetten hizmete ve sanal makineden sanal makineye şifreleme

Istio, hizmet keşfini ve bağlantısını basitleştirmek için Google, IBM, Lyft ve diğerleri tarafından geliştirilen açık kaynaklı bir hizmet ağıdır. Istio kimlik doğrulaması, hizmetler arasında geçiş hâlindeki verilerin otomatik olarak şifrelenmesini ve ilişkili anahtarların ve sertifikaların yönetilmesini sağlar. Istio, Google Kubernetes Engine ve Google Compute Engine'de kullanılabilir.

İş yükleri için karşılıklı kimlik doğrulama ve şifreleme uygulamak istiyorsanız istio kimlik doğrulamasını kullanabilirsiniz. Istio kimlik doğrulaması, özellikle Kubernetes'teki bir iş yükü için küme düzeyindeki bir CA'nın sertifika oluşturmasını ve dağıtmasını sağlar. Bunlar, daha sonra kapsülden kapsüle karşılıklı Taşıma Katmanı Güvenliği (mTLS) için kullanılır.

Google, internetin geçiş hâlindeki verileri şifrelemesine nasıl yardımcı olur?

Geçiş Hâlindeki Verilerin Varsayılan Olarak Şifrelenmesi ve Geçiş hâlindeki verilerin şifrelenmesi için kullanıcı tarafından yapılandırılabilen seçenekler konularında, Google Cloud'ın geçiş hâlindeki müşteri verileri için uyguladığı varsayılan ve özelleştirilebilir korumalar açıklanmıştır. Bunlara ek olarak, Google'ın geçiş hâlindeki verilerin şifrelenmesini ve internette veri güvenliğini teşvik eden birçok açık kaynaklı projesi ve başka çalışmaları vardır.

Sertifika Şeffaflığı

Kullanıcı ile Google Front End arasında şifreleme konusunda açıklandığı gibi, bir sitenin HTTPS sunmak için önce güvenilir bir web (genel) Sertifika Yetkilisine (CA) sertifika başvurusu yapması gerekir. Sertifika Yetkilisi, başvuru sahibinin alan adı sahibi tarafından yetkilendirildiğini doğrulamaktan ve sertifikada yer alan diğer bilgilerin doğru olduğunu kontrol etmekten sorumludur.Bu sertifika, daha sonra kullanıcının erişmeye çalıştığı sitenin kimliğini doğrulamak amacıyla tarayıcıya sunulur. HTTPS'nin doğru şekilde doğrulanmasını sağlamak için CA'ların yalnızca alan sahibinin yetki verdiği sertifikaları yayınladığından emin olmanız önemlidir.

Sertifika Şeffaflığı (CT), Google'ın site yöneticilerine ve alan sahiplerine bir CA'nın yetkisiz veya yanlış sertifikalar yayınlayıp yayınlamadığını tespit etmelerini sağlayacak bir yol sunmak için Mart 2013'te başlattığı bir çalışmadır. Alan sahiplerine, CA'lara ve diğer herkese, gördükleri güvenilir sertifikaları ya da CA'lar söz konusu olduğunda düzenledikleri sertifikaları herkese açık şekilde doğrulanabilen, yalnızca sona eklenen, değişikliğe karşı korumalı günlüklere kaydetmeleri için bir mekanizma sağlayarak çalışır. Bu kayıtlardaki sertifikalar, bilgilerin doğru ve yetkilendirilmiş olduğunu kontrol etmek için herkes tarafından incelenebilir.

Sertifika Şeffaflığı'nın ilk sürümü, IETF deneysel RFC, RFC 6962'de belirtilmiştir. Google, Sertifika Şeffaflığı'nın geliştirilmesi sırasında sertifikaları kaydedebilen açık kaynaklı günlük sunucusu ve Sertifika Şeffaflığı günlüklerini oluşturmak için kullanılan araçlar dahil olmak üzere çok sayıda aracı açık kaynaklı olarak kullanıma sunmuştur. Ayrıca Google Chrome, Genişletilmiş Doğrulama (EV) sertifikaları veya geçmişte uygunsuz şekilde sertifikalar düzenlenmiş CA'lar tarafından düzenlenen sertifikalar gibi bazı sertifikaların herkese açık şekilde ifşa edilmesini gerekli kılar. Chrome, 2018'den itibaren tüm yeni genel kullanım amaçlı güvenilir sertifikaların ifşa edilmesini gerekli kılacaktır.

Site operatörü olarak, web siteniz için yetkisiz sertifikaların verilip verilmediğini tespit etmek amacıyla Sertifika Şeffaflığı'nı kullanabilirsiniz. Google'ın Sertifika Şeffaflığı Raporu, Sertifika Arama veya Facebook araçları gibi bu işlemi kolaylaştıracak birçok ücretsiz araç mevcuttur. Sertifika Şeffaflığı'nı kullanmasanız bile birçok tarayıcı, kullanıcılarınızın web sitenize erişmek için güvendiği CA'ların sektör gereksinimlerini ve en iyi uygulamaları karşıladığından emin olmak ve sahte sertifikalarla karşılaşma riskini azaltmak için artık Sertifika Şeffaflığını düzenli olarak incelemektedir.

HTTPS kullanımını arttırma

Kullanıcı ile Google Front End arasında şifreleme konusunda açıklandığı gibi, sitelerimizin ve hizmetlerimizin varsayılan olarak modern HTTPS sağladığından emin olmak için çok çalışıyoruz. Amacımız, ürünlerimiz ve hizmetlerimizde %100 şifreleme sağlamaktır. Bu doğrultuda, her yıl Google Cloud dahil olmak üzere tüm mülklerimizle ilgili hedefimize doğru ilerleme durumumuzu takip eden HTTPS Şeffaflık Raporu yayınlıyoruz. HTTPS Katı Taşıma Protokolü'nü (HSTS)18 desteklemeyen tarayıcılar veya diğer istemcilere yönelik çözümler gibi bazı ürünlerimizde şifrelemeyi desteklememizi zorlaştıran teknik engeller üzerinde çalışmaya devam ediyoruz. Kullanıcıların bir sunucuya yalnızca HTTPS üzerinden bağlanmasına imkan tanımak için google.com ana sayfası da dahil olmak üzere bazı sitelerimizde HSTS kullanıyoruz.

İnternetin geri kalanının HTTPS'ye geçmeye çalıştığını biliyoruz. Bu geçişi aşağıdaki yollarla kolaylaştırmaya çalışıyoruz:

2016'da internetteki Google'a ait olmayan ilk 100 site için "İnternette HTTPS kullanımı" ile ilgili ölçümler yayınlamaya başladık. Bu ölçümlerle, farkındalığı artırmayı ve interneti tüm kullanıcılar için daha güvenli bir yer hâline getirmeyi amaçlıyoruz. Ekim 2017’de Chrome, Let's Encrypt’e verdiği finansal desteği Platinum sponsor olarak resmen yeniledi.

Güvenli SMTP kullanımını artırma: Gmail göstergeleri

Çoğu e-posta, varsayılan olarak şifrelemeyi kullanmadan e-posta gönderen Basit Posta Aktarım Protokolü (SMTP) kullanılarak değiştirilir. Bir e-postayı şifrelemek için posta sağlayıcısının TLS gibi güvenlik kontrollerini uygulaması gerekir.

Kullanıcı ile Google Front End arasında şifreleme konusunda açıklandığı gibi, Gmail varsayılan olarak TLS kullanır. Ayrıca Gmail'de TLS'yi gerekli kılma bölümünde, Gmail yöneticilerinin gelen ve giden e-postalar için TLS korumasının kullanımını nasıl gerekli kılabileceği açıklanmıştır. Google'ın HTTPS şeffaflığı için yaptığı çalışmalarda olduğu gibi, Gmail de gelen e-postalar için TLS kullanımıyla ilgili veriler sağlar. Bu veriler, Daha Güvenli E-posta Şeffaflığı Raporumuzda sunulmaktadır.

Google, IETF ve sektörün diğer önemli aktörleriyle birlikte SMTP STS'nin geliştirilmesine öncülük ediyor. SMTP STS, HTTPS için HSTS gibidir ve SMTP'nin yalnızca şifreli kanallar üzerinden kullanımını gerekli kılar.

Chrome API'leri

Şubat 2015'te, Chrome yalnızca güvenli kaynaklarda19 güçlü yeni özelliklerin kullanıma sunulacağını duyurdu. Bu özellikler arasında özel bilgilerin işlenmesi ve bir kullanıcının cihazındaki sensörlere erişim bulunmaktadır. Chrome 50'de coğrafi konumdan başlayarak, güvenli olmayan kaynaklar için bu özellikleri kullanımdan kaldırmaya başladık.

Geçiş Hâlindeki Verilerin Şifrelenmesi için Devam Eden Yenilikler

Chrome Güvenliği Kullanıcı Deneyimi

Google Chrome, kullanıcı arayüzünde kullanıcıların bir siteyle kurdukları bağlantının güvenliğini kısa sürede anlamalarına imkan tanıyacak güvenlik bilgilerinin gösterilmesinde sektör lideridir. Kullanıcılar, bu bilgilerle verilerini ne zaman ve nasıl paylaşacakları hakkında bilinçli kararlar verebilir. Chrome, kapsamlı bir kullanıcı araştırması yürütür ve bu araştırmanın sonuçları, gözden geçirilmiş makalelerde paylaşır.

Chrome, kullanıcılarına daha fazla koruma sunmak için 2017'nin sonuna kadar tüm HTTP bağlantılarını güvenli değil olarak işaretleyeceğini duyurmuştur. Kullanıcılar, Chrome 56'dan itibaren bir HTTP sayfasında parola veya kredi kartı alanları içeren bir form varsa varsayılan olarak bir uyarı görecektir. Chrome 62 ile kullanıcı bir HTTP sayfasına veri girdiğinde ve Gizli modda HTTP sayfalarını ziyaret ettiğinde bir uyarı gösterilecektir. Sonuç olarak Chrome, HTTP üzerinden sunulan tüm sayfalar için bir uyarı gösterecektir.

Belirli yapılandırmaların Chrome'daki kullanıcılara nasıl görüntülendiğini görmek için BadSSL aracını kullanabilirsiniz.

Anahtar Şeffaflığı

İleti şifrelemenin yaygın şekilde benimsenmesinin önündeki önemli bir engel, genel anahtar değişiminin zorluğudur: İletişim kurduğum yeni bir kullanıcının genel anahtarını nasıl güvenilir bir şekilde bulabilirim? Google, bu sorunu çözmeye yardımcı olmak için Ocak 2017'de Anahtar Şeffaflığı'nı duyurmuştur. Bu, genel anahtarların dağıtımı için genel, güvenli ve denetlenebilir bir yol sağlayan açık bir çerçevedir. Bu çerçeveyle, kullanıcıların anahtarları manuel olarak doğrulamasına gerek kalmaz. Anahtar Şeffaflığı, temel olarak E2E ve OpenPGP e-posta şifrelemesi gibi iletişimlerde kullanıcıların genel anahtarlarının dağıtımına yöneliktir. Anahtar Şeffaflığı'nın tasarımı, anahtar kurtarma ve dağıtımı için yeni bir yaklaşımdır ve Sertifika Şeffaflığı ve CONIKS'ten elde edilen bilgileri temel alır.

Anahtar Şeffaflığı, açık kaynaklı olarak geliştirilir ve büyük ölçekli bir Merkle ağacı kullanılarak uygulanır. Anahtar Şeffaflığı Doğrulaması, hesap sahiplerinin hesaplarıyla hangi anahtarların ilişkilendirildiğini ve bir hesabın ne kadar süredir etkin ve kararlı olduğunu görmelerine imkan tanır. Google'ın Anahtar Şeffaflığı çalışmasının uzun vadeli hedefi, herkesin Anahtar Şeffaflığı sunucusu çalıştırmasını sağlamak ve istenilen sayıda uygulamaya entegre edilmesini kolaylaştırmaktır.

Post kuantum kriptografi

Google, geçiş hâlindeki verilerin şifrelenmesinde sektör liderliğini sürdürmeyi planlamaktadır. Bu doğrultuda, post kuantum kriptografi alanında çalışmaya başladık. Bu kriptografi türü, etkili kuantum saldırılarına karşı savunmasız olan mevcut temel kriptografi öğelerini, daha dayanıklı olduğuna inanılan post kuantum adaylarla değiştirmemize imkan tanır. Temmuz 2016'da, Chrome'un geliştirici sürümünde New Hope post kuantum kripto algoritmasını kullanarak böyle bir algoritmanın uygulanabilirliğiyle ilgili bir deneme yürüttüğümüzü duyurduk. Bu çalışmaya ek olarak, Google'daki araştırmacılar diğer uygulanabilir post kuantum anahtar değişim protokolleri hakkında makaleler yayınladı.

Ek

Altyapı Güvenliği Tasarımına Genel Bakış dahil olmak üzere Google Cloud Güvenliği ve genel SOC 3 denetim raporu dahil olmak üzere Google Cloud uyumluluğu hakkında daha fazla bilgi edinin.

Dipnotlar

1 İş ortağı çözümleri, Cloud Launcher'da sunulan çözümlerin yanı sıra Cloud Dataprep gibi iş ortakları ile birlikte oluşturulan ürünleri içerir.
2 Bu şifrelemeyi, örneğin Google Cloud Storage paketlerine HTTP erişimi için devre dışı bırakabilirsiniz.
3 Sanal makine ile hizmet arası iletişimler, 7. katmanda değil, yine 3. ve 4. katmanda korunur
4 TLS 1.3, henüz nihai sürüme geçmemiştir. Taslak sürüm, yalnızca test için Gmail gibi belirli Google alanlarında uygulanır.
5 Google, hâlâ protokolün bu sürümünü kullanan tarayıcılar için TLS 1.0'ı destekler. Kredi kartı bilgilerini işleyen tüm Google siteleri, Temmuz 2018'den itibaren TLS 1.0'ı desteklememektedir. Bu tarihte, Ödeme Kartı Endüstrisi (PCI) uyumluluk için TLS 1.0'ın kullanımdan kaldırılmasını gerekli kılmıştır.
6 QUIC ile ilgili ayrıntılar için https://www.chromium.org/quic adresini inceleyin.
7, 8, 9 Bazı eski işletim sistemleriyle geriye dönük uyumluluk için 3DES, SHA1 ve MD5'i destekliyoruz
10 Zincirli sertifikalarda CA'ya geçişli olarak güvenilir.
11 Bu bir oturum bileti (RFC 5077) veya bir oturum kimliği (RFC 5246) olabilir.
12 Kontrol düzlemi, ağın sinyal trafiğini taşıyan ve yönlendirmeden sorumlu olan parçasıdır.
13 Daha önce diğer protokoller kullanılıyordu ancak bunlar kullanımdan kaldırılmıştır. İşlerin %1'den azı bu eski protokolleri kullanmaktadır.
14 Datagram TLS (DTLS), datagrama dayalı uygulamaların gizlice dinlemeyi ve izinsiz değişiklik yapmayı önleyecek şekilde iletişim kurmasına imkan tanıyarak bu uygulamalar için güvenlik sağlar.
15 İnternet Anahtar Değişimi (IKE), IPsec protokolü paketinde bir güvenlik ilişkilendirmesi kurmak için kullanılan protokoldür.
16 HMAC-SHA-1, Google araştırmacılarının bulduğu SHAttered çakışması gibi SHA-1 çakışmaları nedeniyle bozulmaz.
17 Bu, G Suite kuruluşu için kullanıcı arayüzünde gösterilmez. Alan yöneticileri, E-posta Günlüğünde Arama'yı kullanarak alanları için verileri inceleyebilir.
18 HTTPS Katı Aktarım Protokolü, web sitelerinin yalnızca güvenli bağlantılar aracılığıyla erişilebilir olduklarını ve/veya kullanıcıların, kullanıcı aracılarını belirli sitelerle yalnızca güvenli bağlantılar üzerinden etkileşim kurmaya yönlendirebilmesi için kendilerine erişebileceklerini beyan etmelerine imkan tanıyan bir mekanizmadır.
19 Güvenli kaynaklar, belirli şema, ana makine veya bağlantı noktası kalıplarıyla eşleşen bağlantılardır.

Bu sayfayı yararlı buldunuz mu? Lütfen görüşünüzü bildirin:

Şunun hakkında geri bildirim gönderin...