Uygulama Katmanı Aktarım Güvenliği

Yazarlar: Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt, Julien Boeuf

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.

CIO düzeyinde özet

  • Google'ın Uygulama Katmanı Aktarım Güvenliği (ALTS), Google tarafından geliştirilen ve tipik olarak Google altyapısı dahilindeki Uzak Prosedür Çağrısı (RPC) iletişimlerini güvence altına almak için kullanılan bir karşılıklı kimlik doğrulama ve aktarım şifreleme sistemidir. ALTS konsept olarak karşılıklı kimlik doğrulamalı TLS ile benzerdir, ama Google'ın veri merkezi ortamlarının ihtiyaçlarını karşılayacak şekilde tasarlanmış ve optimize edilmiştir.
  • ALTS güven modeli bulut benzeri container'a alınmış uygulamalar için tasarlanmıştır. Kimlikler belirli bir sunucu adı veya ana makine yerine varlıklara bağlıdır. Bu güven modeli sorunsuz mikro hizmet replikasyonu, yük dengeleme ve ana makineler arasında yeniden programlamayı kolaylaştırır.
  • ALTS iki protokole dayanır: El sıkışma protokolü (oturum devam ettirme ile) ve Kayıt protokolü. Bu protokoller oturumların nasıl oluşturulduğunu, doğrulandığını, şifrelendiğini ve devam ettirildiğini yönetir.
  • ALTS, Google'da kullandığımız özel bir aktarım katman güvenlik çözümüdür. ALTS'yi üretim ortamımıza göre tasarlamış olmamız nedeniyle ALTS ile endüstri standardı olan TLS arasında bazı ödünleşimler vardır. Ödünleşimler kısmında bu konu hakkında daha fazla bilgi bulabilirsiniz.

Giriş

Google'daki üretim sistemleri kolektif olarak her saniyede O(1010) Uzak Prosedür Çağrısı (RPC) yayınlayan bir dizi mikro hizmetten1 oluşur. Bir Google mühendisi üretim iş yükü2 planladığında, bu iş yükü tarafından yayınlanan veya alınan tüm RPC'ler varsayılan olarak ALTS ile korunur. Bu otomatik, sıfır yapılandırmalı koruma Google'ın Uygulama Katmanı Aktarım Güvenliği (ALTS) tarafından sağlanır. ALTS, RPC'lere verilen otomatik korumaların yanı sıra kolay hizmet replikasyonu, yük dengeleme ve üretim makineleri arasında yeniden programlamayı da kolaylaştırır. Bu makalede ALTS açıklanmakta ve Google'ın üretim altyapısına dağıtılması incelenmektedir.

Kitle: Bu belgenin hedef kitlesi Google'da kimlik doğrulama ve aktarım güvenliğinin nasıl geniş ölçekte uygulandığını merak eden altyapı güvenliği uzmanlarıdır.

Ön koşullar: Bu giriş kısmına ek olarak Google'da küme yönetimine dair genel bilgiye sahip olduğunuzu varsayarız.

Uygulama Düzeyinde Güvenlik ve ALTS

Web tarayıcılarından VPN'lere kadar pek çok uygulama geçiş halindeki verileri korumak için TLS (Aktarım Katmanı Güvenliği) ve IPSec gibi güvenli iletişim protokollerine güvenir3. Google olarak RPC iletişimlerini korumak için uygulama katmanında çalışan bir karşılıklı kimlik doğrulama ve aktarım şifreleme sistemi olan ALTS'yi kullanıyoruz. Uygulama düzeyinde güvenlik kullanmak uygulamaların doğrulanmış uzak eş kimliğine sahip olmasına olanak tanıyor; bu da ayrıntılı yetkilendirme politikaları uygulamakta kullanılabiliyor.

Neden TLS değil?

Bugün internet trafiğinin çoğunluğu TLS ile şifrelenirken Google'ın ALTS gibi özel bir güvenlik çözümü kullanması olağan dışı görünebilir. Google'da ALTS'yi geliştirme çalışmaları 2007'de başladı. O dönemde, TLS minimum güvenlik standartlarımızı karşılamayan pek çok eski protokol için destekle birlikte sunuluyordu. Kendi güvenlik çözümümüzü ihtiyacımız olan TLS bileşenlerini alıp kendi istediğimiz bileşenleri de ekleyerek tasarlayabilirdik. Ancak sıfırdan başlayarak Google'a daha uygun bir sistem oluşturmanın avantajları mevcut bir sisteme yama yapmanın faydalarına ağır bastı. Ayrıca, ALTS ihtiyaçlarımız açısından daha uygun ve geçmişte daha eski olan TLS'den daha güvenli olduğunu kanıtladı. Aşağıda TLS ile ALTS arasındaki temel farkların listesini bulabilirsiniz.

  • HTTPS semantikli TLS ile ALTS'nin güven modelleri4 arasında önemli bir fark vardır. TLS'de sunucu kimlikleri belirli bir ada ve buna karşılık gelen adlandırma şemasına bağlıdır. ALTS'de aynı kimlik birden fazla adlandırma şemasıyla kullanılabilir. Bu yöneltme düzeyi daha büyük bir esneklik sağlar ve mikro hizmet replikasyonu, yük dengeleme ve ana makineler arasında yeniden programlama sürecini önemli ölçüde kolaylaştırır.
  • TLS'ye kıyasla ALTS'nin tasarımı ve uygulanması daha basittir. Bunun sonucunda, ALTS'nin kaynak kodun manuel olarak incelenmesi veya yoğun rastlantısal veri testi aracılığıyla hata ve güvenlik açıklarına karşı izlenmesi daha kolaydır.
  • ALTS sertifikaları ve protokol mesajlarını serileştirmek için Protokol Arabelleği kullanırken TLS, ASN.1 ile kodlanmış olan X.509 sertifikalarını kullanır. Üretim hizmetlerimizin çoğunluğunun iletişim (ve bazen de depolama) için protokol arabellekleri kullanması nedeniyle ALTS Google'ın ortamına daha uygun bir çözümdür.

ALTS Tasarımı

ALTS, minimum kullanıcı müdahalesi ile hizmetten hizmete kimlik doğrulama ve güvenlik sağlamaya olanak tanıyan yüksek düzeyde güvenilir bir sistem olacak şekilde tasarlanmıştır. Bunu başarmak için aşağıda belirtilen özellikler ALTS tasarımının bir parçasıdır:

  • Şeffaflık: ALTS yapılandırması uygulama katmanına kadar şeffaftır. Varsayılan olarak hizmet RPC'leri ALTS ile güvence altına alınır. Bu, uygulama geliştiricilerin kimlik bilgisi yönetimi veya güvenlik yapılandırmaları konusunda endişelenmelerine gerek olmadan hizmetlerinin işlevsel mantığına odaklanabilmesine olanak tanır. Hizmetten hizmete bağlantı kurulurken ALTS uygulamalara ayrıntılı yetkilendirme kontrolleri ve denetim için kullanılabilecek olan doğrulanmış bir uzak eş kimliği sağlar.
  • Son teknoloji ürünü kriptografi: ALTS tarafından kullanılan tüm temel kriptografi öğeleri ve protokoller bilinen güncel saldırılara karşı güncellenmiştir. ALTS, Google tarafından kontrol edilen makineler üzerinde çalışır. Bu sayede, desteklenen tüm kriptografik protokoller kolayca yükseltilip hızla dağıtılabilir.
  • Kimlik modeli: ALTS kimlik doğrulamayı esasen ana makine adına değil kimliğe göre gerçekleştirir. Google'da her ağ varlığının (ör. kurumsal kullanıcı, fiziksel makine, üretim hizmeti veya iş yükü) ilişkili bir kimliği vardır. Hizmetler arasındaki tüm iletişimler karşılıklı olarak doğrulanır.
  • Anahtar dağıtımı: ALTS, her iş yükünün bir kimlik bilgileri grubu olarak ifade edilen bir kimliğe sahip olmasına dayanır. Bu kimlik bilgileri başlatma sırasında kullanıcı müdahalesine gerek olmadan her iş yüküne dağıtılır. Buna paralel olarak makineler ve iş yükleri için bir güven kökü ve bu kimlik bilgileri için bir güven zinciri oluşturulur. Bu sistem, uygulama geliştiricilerin müdahale etmesine gerek olmadan otomatik sertifika rotasyonu ve iptaline olanak tanır.
  • Ölçeklenebilirlik: ALTS, Google altyapısının devasa ölçeğini desteklemesi için son derece ölçeklenebilir olacak şekilde tasarlanmıştır. Bu gereksinim verimli Oturum Devam Ettirme'nin geliştirilmesiyle sonuçlanmıştır.
  • Uzun ömürlü bağlantılar: Doğrulanmış anahtar değişimi kriptografik işlemleri işlem yükü açısından pahalıdır. Google altyapısının ölçeğine uyum sağlamak amacıyla, başlangıçtaki bir ALTS el sıkışmasının ardından bağlantılar genel sistem performansını iyileştirmek için daha uzun bir süre boyunca sürdürülebilir.
  • Basitlik: TLS varsayılan olarak eski protokol sürümleri için destek ve geriye dönük uyumlulukla sunulur. Google'ın yerel olarak ALTS'yi destekleyecek şekilde tasarladığımız istemcileri ve sunucuları kontrol etmesi nedeniyle ALTS önemli ölçüde daha basittir.

ALTS Güven Modeli

ALTS kimlik doğrulamayı esasen ana makineye değil kimliğe göre gerçekleştirir. Google'da her ağ varlığının (ör. kurumsal kullanıcı, fiziksel makine veya üretim hizmeti) ilişkili bir kimliği vardır. Bu kimlikler ALTS sertifikalarına yerleştirilir ve güvenli bağlantı kurulurken eş kimlik doğrulaması için kullanılır. Uygulamak istediğimiz model, üretim hizmetlerimizin Site Güvenilirlik Mühendislerimiz (SRE'ler) tarafından yönetilebilen üretim varlıkları olarak çalışmasıdır5. Bu üretim hizmetlerinin geliştirme sürümleri hem SRE'ler hem de geliştiriciler tarafından yönetilebilen test varlıkları olarak çalışır.

Örneğin, iki hizmeti bulunan bir ürünümüz olduğunu düşünelim: hizmet-ön uç ve hizmet-arka uç. SRE'ler bu hizmetlerin üretim sürümünü kullanıma sunabilir: hizmet-ön uç-üret ve hizmet-arka uç-üret. Geliştiriciler test etme amacıyla bu hizmetlerin geliştirme sürümlerini oluşturup kullanıma sunabilir: hizmet-ön uç-gel ve hizmet-arka uç-gel. Üretim hizmetlerindeki kimlik doğrulama yapılandırması hizmetlerin geliştirme sürümlerine güvenmeyecek şekilde yapılandırılır.

ALTS Kimlik Bilgileri

Hepsi Protokol Arabelleği mesaj biçiminde ifade edilen üç tür ALTS kimlik bilgisi vardır.

  • Ana sertifika: Bir uzaktan İmzalama Hizmeti tarafından imzalanır ve el sıkışma sertifikalarını doğrulamakta kullanılır. Ana sertifika, bir ana özel anahtarla (ör. RSA anahtar çifti) ilişkili olan bir genel anahtar içerir. Bu özel anahtar el sıkışma sertifikalarını imzalamakta kullanılır. Bu sertifikalar, aşağıda tartışılan ALTS politikasıyla birlikte uygulandıklarında temelde sınırlanmış ara Sertifika Yetkilisi (CA) sertifikalarıdır. Ana sertifikalar tipik olarak üretim makineleri ve Borgmaster gibi container'a alınmış iş yükü planlayıcılar için verilir6.
  • El sıkışma sertifikası: Ana özel anahtar tarafından oluşturulur ve yerel olarak imzalanır. Bu sertifika, statik Diffie-Hellman (DH) parametreleri ve el sıkışma şifreleri gibi ALTS el sıkışması (güvenli bağlantı kurulumu) sırasında kullanılan parametreleri içerir. El sıkışma sertifikası ayrıca kendisinden türetilmiş olduğu ana sertifikayı (yani, el sıkışma sertifikasını imzalayan ana özel anahtarla ilişkili olan sertifikayı) da içerir.
  • Devam ettirme anahtarı: Devam ettirme biletlerini şifrelemekte kullanılan bir gizli anahtardır. Bu anahtar, aynı kimlikle ve aynı veri merkezi hücresinde çalışan tüm üretim iş yükleri için benzersiz olan ve bunlar arasında paylaşılan bir Devam Ettirme Tanımlayıcı IDR ile tanımlanır. ALTS'de oturum devam ettirme hakkında daha fazla bilgi edinmek için Oturum Devam Ettirme'ye bakın.

Şekil 1, bir İmzalama Hizmeti doğrulama anahtarı, bir ana sertifika ve bir el sıkışma sertifikasından oluşan ALTS sertifika zincirini göstermektedir. İmzalama Hizmeti doğrulama anahtarları ALTS'de güven kökü olup üretim ve kurumsal ağlarımızdaki tüm Google makinelerine yüklenmiştir.

Şekil 1: ALTS sertifika zinciri

ALTS'de bir İmzalama Hizmeti ana sertifikaları onaylar ve bunlar da El Sıkışma sertifikalarını onaylar. El Sıkışma sertifikaları ana sertifikalardan daha sık bir şekilde oluşturulduğundan, bu mimari İmzalama hizmetinin üzerindeki yükü azaltır. Google'da sertifika rotasyonu başta el sıkışma sertifikaları için olmak üzere sık sık gerçekleşir7. Bu sık rotasyon el sıkışma sertifikalarının taşıdığı statik anahtar değişimi çiftlerini telafi eder8.

Sertifika Verme

ALTS güvenli el sıkışmasında yer alabilmeleri için ağdaki varlıklara el sıkışma sertifikaları sağlanmış olması gerekir. Öncelikle, sertifikayı veren İmzalama Hizmeti tarafından imzalanan bir ana sertifika alır ve isteğe bağlı olarak bunu varlığa aktarır. Ardından, bir el sıkışma sertifikası oluşturulur ve ilişkili ana özel anahtar tarafından imzalanır.

Sertifikaları genellikle makine ve insanlara sertifika verilirken dahili Sertifika Yetkilimiz (CA), iş yüklerine sertifika verilirken de Borgmaster verir. Bununla birlikte, sertifikalar herhangi bir başka varlık tarafından verilebilir (ör. bir test veri merkezi hücresi için kısıtlanmış bir Borgmaster).

Şekil 2'de ana sertifika oluşturmak için İmzalama hizmetinin nasıl kullanıldığı gösterilmektedir. Bu süreç aşağıdaki adımlardan oluşur.

Şekil 2: Sertifika Verme

  1. Sertifika Veren, İmzalama Hizmetine bir Sertifika İmzalama İsteği (CSR) gönderir. Bu istekte İmzalama Hizmetinden A kimliği için bir sertifika oluşturması talep edilir. Bu kimlik örneğin bir kurumsal kullanıcı veya bir Google üretim hizmetinin kimliği olabilir.
  2. İmzalama Hizmeti, sertifikayı vereni (CSR'de yer alır) isteği gönderen (bu örnekte Sertifika Veren) olarak ayarlar ve sertifikayı imzalar. Daha önce söylemiş olduğumuz gibi, ilgili İmzalama Hizmeti genel (doğrulama) anahtarı tüm Google makinelerine yüklenmiştir.
  3. İmzalama Hizmeti imzalanan sertifikayı geri gönderir.
  4. A kimliği için bir el sıkışma sertifikası oluşturulur ve ana sertifikayla ilişkili özel anahtar tarafından imzalanır

Yukarıdaki süreçte gösterildiği gibi, ALTS'de bir sertifikayı veren ve imzalayan iki farklı mantıksal varlıktır. Bu örnekte, sertifikayı veren Sertifika Veren varlık, imzalayan ise İmzalama Hizmetidir.

ALTS'de sık kullanılan üç sertifika kategorisi vardır. Bu kategoriler şunlardır: İnsan, Makine ve İş Yükü. Aşağıdaki bölümlerde bu sertifikalardan her birinin nasıl oluşturulduğu ve ALTS'de kullanıldığı özetlenmiştir.

İnsan Sertifikaları

Google'da insan kullanıcılar tarafından üretim hizmetlerine yayınlanan RPC'leri güvence altına almak için ALTS'yi kullanıyoruz. Kullanıcıların RPC yayınlamak için geçerli bir el sıkışma sertifikası sağlamaları gerekir. Örneğin, Ayla ALTS güvenli RPC yayınlamak için bir uygulama kullanmak istiyorsa dahili CA'mızda kimliğini doğrulayabilir. Ayla, CA'da kimlik doğrulama işlemini kullanıcı adını, şifresini ve iki faktörlü kimlik doğrulamasını kullanarak yapar. Bu işlem Ayla'nın 20 saat süreyle geçerli olacak bir el sıkışma sertifikası almasıyla sonuçlanır.

Makine Sertifikaları

Google'ın veri merkezlerindeki her üretim makinesinin bir makine ana sertifikası vardır. Bu sertifika, bu makinedeki temel uygulamalar (ör. makine yönetimi arka plan programları) için el sıkışma sertifikaları oluşturmakta kullanılır. Makine sertifikasına yerleştirilen birincil kimlik, makinenin tipik amacını belirtir. Örneğin, farklı üretim ve geliştirme iş yükü türlerini çalıştırmakta kullanılan makinelerin farklı kimlikleri olabilir. Ana sertifikalar yalnızca doğrulanmış yazılım yığınları çalıştıran makineler tarafından kullanılabilir; bazı durumlarda bu güvenin kökü özel güvenlik donanımıdır9. Tüm üretim makinesi ana sertifikaları CA tarafından verilir ve birkaç ayda bir bunlara rotasyon uygulanır. Ayrıca, tüm el sıkışma sertifikalarına birkaç saatte bir rotasyon uygulanır.

İş Yükü Sertifikaları

ALTS'nin kilit bir avantajı kolay hizmet replikasyonu, yük dengeleme ve makineler arasında yeniden programlamayı kolaylaştıran bir iş yükü kimliği fikrine dayanarak çalışmasıdır. Üretim ağımızda geniş ölçekte küme yönetimi ve makine kaynağı tahsisi için Borg10 adlı bir sistem kullanıyoruz. Borg'un sertifika verme şekli ALTS'nin makineden bağımsız iş yükü kimliği uygulamasının bir parçasıdır.

Üretim ağımızdaki her iş yükü bir Borg hücresinde çalışır. Her hücre Borgmaster adı verilen mantıksal olarak merkezileştirilmiş bir denetleyici ve bu hücredeki her makinede çalışan Borglet adlı birkaç aracı işlem içerir. İş yükleri Borgmaster tarafından verilen ilişkili İş Yükü El Sıkışma Sertifikaları ile başlatılır. Şekil 3'te Borg ile ALTS'de iş yükü sertifikasyonu süreci gösterilmiştir.

Şekil 3: Google Üretim Ağı'nda El Sıkışma Sertifikası Oluşturma

Borgmaster artık ALTS'yi kullanması gereken iş yüklerini planlamaya hazırdır. Bir istemci, bir iş yükünü belirli bir kimlik olarak Borg'da çalışmak üzere planladığında aşağıdaki adımlar gerçekleşir.

  1. Her Borgmaster önceden bir Makine Ana Sertifikası ve bununla ilişkili özel anahtar yüklenmiş olarak kullanıma sunulur (şemada gösterilmemiştir).
  2. ALTSd11 bir Borgmaster El Sıkışma Sertifikası oluşturur ve Makine Ana özel anahtarını kullanarak bunu imzalar. Bu El Sıkışma Sertifikası, Borgmaster'ın ALTS güvenli RPC'ler yayınlamasına olanak tanır.
  3. Borgmaster bir Temel İş Yükü Ana Sertifikası ve bununla ilişkili özel anahtarı oluşturur. Borgmaster, bu Temel İş Yükü Ana Sertifikasının İmzalama Hizmeti tarafından imzalanmasını sağlamak için bir istek (bir ALTS güvenli RPC) başlatır. Bunun sonucunda, İmzalama Hizmeti Borgmaster'ı sertifikayı veren olarak listeler.
  4. Borgmaster, istemcinin iş yüklerini iş yükü yapılandırmasında belirtilen kimlik olarak çalıştırmaya yetkili olduğunu doğrular. İstemci bu yetkiye sahipse Borgmaster, Borglet'te Borg iş yükünü planlar ve bir İş Yükü El Sıkışma Sertifikası ile bununla ilişkili özel anahtarı yayınlar. Bu sertifika Temel İş Yükü Ana Sertifikası'ndan zincirlenir. İş Yükü El Sıkışma Sertifikası ve özel anahtarı bunun ardından güvenli bir şekilde Borglet'e iletilir (Borgmaster ile Borglet arasındaki karşılıklı olarak doğrulanmış ALTS korumalı bir kanal üzerinden). Borgmaster, Temel İş Yükü Ana Sertifikasına rotasyon uygular ve yaklaşık olarak iki günde bir tüm çalışan iş yükleri için El Sıkışma Sertifikalarını yeniden yayınlar. Ayrıca, aynı hücrede aynı kullanıcı olarak çalışan her iş yükü Borgmaster tarafından sağlanan aynı devam ettirme anahtarı ve tanımlayıcıyı (IDR) alır.
  5. İş yükünün ALTS güvenli bir RPC yapması gerektiğinde el sıkışma protokolünde İş Yükü El Sıkışma Sertifikasını kullanır. IDR de oturum devam ettirmeyi başlatmak için el sıkışmanın bir parçası olarak kullanılır. ALTS'de oturum devam ettirme hakkında daha fazla bilgi almak için Oturum Devam Ettirme'ye bakın.

ALTS Politikasının Uygulanması

ALTS politikası, hangi sertifika verenlerin hangi kimlikler için belirli sertifika kategorilerini verme yetkisine sahip olduğunu listeleyen bir belgedir. Bu belge üretim ağımızdaki tüm makinelere dağıtılır. Örneğin, ALTS politikası CA'nın makinelere ve insanlara sertifika vermesine izin verir. Ayrıca, Borgmaster'ın iş yüklerine sertifika vermesine de izin verir.

Sertifikaların verilmesi yerine sertifikaların doğrulanması sırasında politikaların zorunlu kılınmasının, farklı dağıtım türlerinde farklı politikaların uygulanmasına olanak tanıması nedeniyle daha esnek bir yaklaşım olduğunu fark ettik. Örneğin, test kümesindeki bir politikanın üretim kümesindeki bir politikaya kıyasla daha serbest olmasını isteyebiliriz.

ALTS el sıkışması sırasında sertifika doğrulaması ALTS politikasının kontrol edilmesini de içerir. Politika, doğrulanmakta olan sertifikada belirtilen sertifika verenin bu sertifikayı vermeye yetkili olduğundan emin olur. Sertifika verenin böyle bir yetkisi yoksa sertifika reddedilir ve el sıkışma işlemi başarısız olur. Şekil 4'te politika uygulamanın ALTS'de nasıl çalıştığı gösterilmiştir. Şekil 2'deki senaryoyu takip ederek Meltem'in (ayrıcalıklarını artırmak isteyen bir kurumsal kullanıcı) ağı yeniden yapılandırabilen güçlü bir kimlik olan Ağ Yöneticisi'ne bir ana sertifika vermek istediğini varsayalım. Elbette ALTS politikasında Meltem'e bu işlemi gerçekleştirme yetkisi verilmemiştir.

Şekil 4: Sertifika Verme ve Sertifika Kullanımı

  1. Meltem, Ağ Yöneticisi kimliği için bir ana sertifika yayınlar ve bunu İmzalama Hizmetine imzalatır. Bu işlem Şekil 2'deki ilk üç adıma benzerdir.
  2. Meltem oluşturulan ana sertifikayla ilişkili ana özel anahtarı kullanarak Ağ Yöneticisi için yerel olarak bir el sıkışma sertifikası oluşturur ve imzalar.
  3. Meltem oluşturulan el sıkışma sertifikasını kullanarak Ağ Yöneticisi kimliğine bürünmeye çalışırsa Meltem'in iletişim kurmaya çalıştığı eşteki ALTS politika uygulayıcısı işlemi engeller.

Sertifikanın İptal Edilmesi

Google'da sertifikalar geçerlilik süreleri dolduğunda iptal edilir veya Sertifika İptal Listemize (CRL) alınır. Bu bölümde, bu makalenin yazıldığı zamanda hâlâ dağıtım testlerinden geçmekte olan Google'ın dahili sertifika iptali mekanizmalarının tasarımı açıklanmıştır.

İnsan kurumsal kullanıcılara verilen tüm sertifikaların kullanıcıların her gün yeniden kimlik doğrulaması yapmasını gerektiren bir günlük geçerlilik sonu zaman damgası vardır. Üretim makinelerine verilen sertifikaların pek çoğunda geçerlilik sonu zaman damgaları kullanılmaz. Saat senkronizasyonu sorunlarından kaynaklanan kesintilere yol açabileceği için üretim sertifikalarının geçerlilik sürelerinin dolması için zaman damgalarına güvenmekten kaçınıyoruz. Bunun yerine, sertifikaların rotasyonu ve olay yanıtı işlemleri için bilgi kaynağımız olarak CRL'yi kullanıyoruz. Şekil 5'te CRL'nin nasıl çalıştığı gösterilmiştir.

Şekil 5: RevocationID ile Ana Sertifika Oluşturma

  1. CA'mızın bir örneği başlatıldığında12 CRL Hizmetiyle iletişime geçer ve bir iptal kimliği aralığı ister. İptal kimliği, iki bileşeni olan 64 bit uzunluğundaki bir kimliktir. Bu bileşenler 8 bitlik bir sertifika kategorisi (ör. insan veya makine sertifikası) ve 56 bitlik bir sertifika tanımlayıcıdır. CRL Hizmeti bu kimliklerden bir aralık seçer ve bunu CA'ya gönderir.
  2. CA bir ana sertifika isteği aldığında sertifikayı oluşturur ve içine bu aralıktan aldığı bir iptal kimliğini yerleştirir.
  3. Buna paralel olarak CA yeni sertifikayı iptal kimliğiyle eşleştirir ve bu bilgiyi CRL Hizmetine gönderir.
  4. CA ana sertifikayı verir.

El sıkışma sertifikalarına hangi iptal kimliklerinin atanacağı sertifikanın nasıl kullanıldığına göre belirlenir. Örneğin, insan kurumsal kullanıcılara verilen el sıkışma sertifikaları, kullanıcının ana sertifikasının iptal kimliğini devralır. Borg iş yüklerine verilen el sıkışma sertifikalarında iptal kimliği Borgmaster'ın iptal kimlikleri aralığından seçilerek atanır. Bu kimlik aralığı Borgmaster'a Şekil 5'te gösterilene benzer bir süreçle CRL Hizmeti tarafından atanır. Eşler ALTS el sıkışmalarında yer aldıklarında uzak eş sertifikasının iptal edilmemiş olduğundan emin olmak için CRL dosyasının yerel bir kopyasını kontrol eder.

CRL Hizmeti tüm iptal kimliklerini ALTS kullanan tüm Google makinelerine aktarılabilen tek bir dosya halinde derler. CRL veritabanı birkaç yüz megabayt büyüklüğünde olsa da oluşturulan CRL dosyası çeşitli sıkıştırma teknikleri sayesinde yalnızca birkaç megabayt büyüklüğünde olur.

ALTS Protokolleri

ALTS iki protokole dayanır: El sıkışma protokolü (oturum devam ettirme ile) ve Kayıt protokolü. Bu bölümde her protokol için yüksek düzeyli bir genel bakış sunulmuştur. Bu genel bakışlar protokollerin ayrıntılı teknik özellikleri olarak yorumlanmamalıdır.

El Sıkışma Protokolü

ALTS el sıkışma protokolü, hem Mükemmel İletim Gizliliği (PFS) hem de oturum devam ettirmeyi destekleyen Diffie-Hellman tabanlı bir kimliği doğrulanmış anahtar değişimi protokolüdür. ALTS altyapısı her istemci ve sunucunun kendi kimliklerini içeren bir sertifikası ve güvenilen bir İmzalama Hizmeti doğrulama anahtarına zincirlenen bir Eliptik Eğri Diffie-Hellman (ECDH) anahtarı olmasını sağlar. Bu statik ECDH anahtarlarının PFS el sıkışmada kullanılmasa bile iletim gizliliğini yenilemek için sık sık güncellenmesi nedeniyle, ALTS'de PFS varsayılan olarak etkinleştirilmez. El sıkışma sırasında istemci ve sunucu güvenli bir şekilde bir ortak geçiş şifreleme anahtarı belirler ve şifreleme anahtarının korumakta kullanılacağı Kayıt protokolünü kararlaştırır. Örneğin, istemci ile sunucu AES-GCM kullanarak bir RPC oturumunu korumakta kullanılacak olan 128 bitlik bir anahtar üzerinde anlaşabilir. El sıkışma işlemi Şekil 6'da gösterilmiş olan dört adet serileştirilmiş Protokol Arabelleği mesajından oluşur.

Şekil 6: ALTS El Sıkışma Protokolü Mesajları

  1. İstemci bir ClientInit mesajı göndererek el sıkışmayı başlatır. Bu mesaj istemcinin el sıkışma sertifikasını ve istemcinin desteklediği el sıkışmayla ilgili şifreler ve kayıt protokollerinin listesini içerir. İstemci sonlandırılmış bir oturumu devam ettirmeye çalışıyorsa mesaj bir devam ettirme tanımlayıcısı ve şifrelenmiş sunucu devam ettirme bileti içerir.
  2. ClientInit mesajı alındığında sunucu istemci sertifikasını doğrular. Sertifika geçerliyse sunucu, istemci tarafından sağlanan listeden bir el sıkışma şifresi ve kayıt protokolü seçer. Sunucu DH değişimi sonucunu hesaplamak için ClientInit mesajında bulunan bilgilerle kendi yerel bilgilerinin bir kombinasyonunu kullanır. Bu sonuç protokolün metniyle birlikte Anahtar Türetme Fonksiyonlarına13 girdi olarak kullanılarak aşağıdaki oturum gizli anahtarları oluşturulur:

    • Yük mesajlarını şifrelemek ve doğrulamakta kullanılan kayıt protokolü gizli anahtarı M.
    • Gelecekteki oturumlarda bir devam ettirme biletinde kullanılacak olan devam ettirme gizli anahtarı R.
    • Kimlik doğrulayıcı gizli anahtar A.

      Sunucu; sertifikasını, seçilen el sıkışma şifresini, kayıt protokolünü ve isteğe bağlı bir şifrelenmiş devam ettirme biletini içeren bir ServerInit mesajı gönderir.

  3. Sunucu el sıkışma kimlik doğrulayıcısı14 içeren bir ServerFinished mesajı gönderir. Bu kimlik doğrulayıcının değeri, önceden tanımlanmış bir bit dizisi ve kimlik doğrulayıcı gizli anahtar A üzerinde hesaplanan bir Karma Tabanlı Mesaj Doğrulama Kodu (HMAC) ile hesaplanır.

  4. İstemci ServerInit mesajını aldığında sunucu sertifikasını doğrular, sunucuya benzer bir şekilde DH değişimi sonucunu hesaplar ve aynı M, R ve A gizli anahtarlarını türetir. İstemci türetilen A gizli anahtarını kullanarak alınan ServerFinished mesajındaki kimlik doğrulayıcı değerini doğrular. El sıkışma sürecinin bu noktasında istemci M'yi kullanarak mesajları şifrelemeye başlayabilir. İstemci artık şifrelenmiş mesajlar gönderebildiği için ALTS'nin tek RTT'li bir el sıkışma protokolü olduğunu söyleyebiliriz.

  5. El sıkışma işleminin sonunda, istemci farklı bir önceden tanımlanmış bit dizisi üzerinde hesaplanan benzer bir kimlik doğrulayıcı değeri (bkz. adım 3) içeren bir ClientFinished mesajı gönderir. Gerek olması halinde istemci mesaja gelecekteki oturumlar için şifrelenmiş bir devam ettirme bileti ekleyebilir. Bu mesaj alınıp sunucu tarafından doğrulandıktan sonra ALTS el sıkışma protokolü sona erer ve sunucu M'yi kullanarak başka yük mesajlarını şifrelemeye ve kimliklerini doğrulamaya başlayabilir.

El Sıkışma protokolü Google'ın iç güvenlik analizi ekibinden Thai Duong tarafından incelenmiş ve Martin Abadi'nin yardımıyla Bruno Blanchet tarafından Proverif15 aracını kullanarak resmi olarak onaylanmıştır.

Kayıt Protokolü

El Sıkışma Protokolü Bölümünde bir Kayıt protokolü gizli anahtarı kararlaştırmak için El Sıkışma protokolünü nasıl kullandığımız açıklandı. Bu protokol gizli anahtarı ağ trafiğini şifrelemek ve kimliğini doğrulamakta kullanılır. Yığının bu işlemleri gerçekleştiren katmanı ALTS Kayıt Protokolü (ALTSRP) olarak adlandırılır.

ALTSRP çeşitli anahtar boyutları ve güvenlik özellikleri olan bir şifreleme şeması paketi içerir. El sıkışma sırasında istemci tercih sırasına göre sıralanmış olan tercih edilen şemalar listesini gönderir. Sunucu, istemcinin listesindeki sunucunun yerel yapılandırmasıyla eşleşen ilk protokolü seçer. Bu şema seçme yöntemi hem istemci hem de sunucuların farklı şifreleme tercihlerine sahip olabilmesine izin verir ve şifreleme şemalarını kullanıma sokmamıza (veya kaldırmamıza) olanak tanır.

Çerçeveleme

Çerçeveler ALTS'deki en küçük veri birimidir. Boyutuna bağlı olarak, her ALTSRP mesajı bir veya daha fazla çerçeveden oluşabilir. Her çerçeve aşağıdaki alanları içerir:

  • Uzunluk: Bit cinsinden çerçevenin uzunluğunu gösteren 32 bitlik imzalanmamış bir değer. Bu 4 baytlık uzunluk alanı toplam çerçeve uzunluğuna dahil edilmez.
  • Tür: Çerçeve türünü (ör. veri çerçevesi) belirten 32 bitlik bir değer.
  • Yük: Gönderilmekte olan kimliği doğrulanmış ve isteğe bağlı olarak şifrelenmiş esas veri.

Bir çerçevenin maksimum uzunluğu 1 MB artı 4 uzunluk baytıdır. Kısa çerçevelerin arabelleğe alma işlemi için daha az bellek gerektirmesi nedeniyle, mevcut RPC protokollerinde çerçeve uzunluğunu daha da fazla sınırlıyoruz. Büyük çerçeveler ayrıca bir sunucuya kaynak bırakmamak amacıyla gerçekleştirilen bir Hizmet Reddi (DoS) saldırısı sırasında potansiyel bir saldırgan tarafından istismar edilebilir. Çerçeve uzunluğunu sınırlamanın yanı sıra, aynı kayıt protokolü gizli anahtarı M'yi kullanarak şifrelenebilecek olan çerçevelerin sayısını da kısıtlıyoruz. Bu sınır, çerçeve yükünü şifrelemekte ve şifresini çözmekte kullanılan şifreleme şemasına bağlı olarak değişir. Bu sınıra ulaşıldığında bağlantının kapatılması gerekir.

Yük

ALTS'de her çerçeve bütünlüğü korunan ve isteğe bağlı olarak şifrelenen bir yük içerir16. Bu makalenin yayınlandığı tarih itibarıyla ALTS aşağıdaki modları desteklemektedir:

  • AES-128-GCM, AES-128-VCM: 128 bit anahtarlar ile sırasıyla AES-GCM ve AES-VCM modları. Bu modlar sırasıyla GCM ve VCM şemalarını17 kullanarak yükün gizliliğini ve bütünlüğünü korur.
  • AES-128-GMAC, AES-128-VMAC: Bu modlar sırasıyla GMAC ve VMAC kullanarak etiket hesaplama için yalnızca bütünlüğe yönelik korumayı destekler. Yük, bütünlüğünü koruyan kriptografik bir etiketle şifrelenmemiş metin halinde aktarılır.

Google'da tehdit modeline ve performans gereksinimlerine bağlı olarak farklı koruma modları kullanıyoruz. İletişim kuran varlıklar Google tarafından veya Google adına kontrol edilen aynı fiziksel sınır dahilindeyse yalnızca bütünlüğe yönelik koruma kullanılır. Bu varlıklar verilerinin hassasiyet derecesine göre hâlâ kimliği doğrulanmış şifrelemeye yükseltmeyi tercih edebilir. İletişim kuran varlıklar Google tarafından veya Google adına kontrol edilen farklı fiziksel sınırlar dahilindeyse ve bu nedenle iletişimler Geniş Alan Ağı üzerinden geçiyorsa seçilen modun ne olduğuna bakmaksızın bağlantı güvenliğini otomatik olarak kimliği doğrulanmış şifrelemeye yükseltiyoruz. Google, aynı sıkı güvenlik önlemlerinin uygulanamayacak olması nedeniyle, Google tarafından veya Google adına kontrol edilen fiziksel sınırın dışına aktarılan geçiş halindeki veriler için farklı korumalar uygular.

Her çerçeve ayrı olarak bütünlük açısından korunur ve isteğe bağlı olarak şifrelenir. Her iki eş normal çalışma sırasında senkronize olan istek ve yanıt sayaçlarının her ikisini de korur. Sunucu sırasız veya tekrarlanan istekler alırsa kriptografik bütünlük doğrulaması başarısız olur ve istek bırakılır. Benzer şekilde, istemci tekrarlanan veya hatalı sıralanmış yanıtları bırakır. Ayrıca, her iki eşin sayaçları koruması (bunların değerlerini çerçeve başlığına eklemek yerine) aktarımda ek bayt tasarrufu sağlar.

Oturum Devam Ettirme

ALTS, kullanıcılarının ağır asimetrik kriptografik işlemler yapmalarına gerek olmadan önceki oturumları devam ettirebilmesine olanak tanır. Oturum devam ettirme, ALTS El Sıkışma protokolünde yerleşik olan bir özelliktir.

ALTS el sıkışma işlemi istemciler ve sunucuların gelecekteki bağlantıları devam ettirmekte kullanılabilecek olan devam ettirme biletlerini güvenli bir şekilde değiş tokuş etmesine (ve önbelleğe almasına) olanak tanır18. Önbelleğe alınan her devam ettirme bileti, aynı kimlikle ve aynı veri merkezi hücresinde çalışan tüm iş yükleri için benzersiz olan bir Devam Ettirme Tanımlayıcısı (IDR) tarafından dizine eklenir. Bu biletler ilgili tanımlayıcılarıyla ilişkili olan simetrik anahtarlar kullanılarak şifrelenir.

ALTS iki tür oturum devam ettirmeyi destekler:

  1. Sunucu tarafı oturum devam ettirme: Bir istemci sunucu kimliğini ve türetilen devam ettirme gizli anahtarı R'yi içeren bir devam ettirme bileti oluşturur ve şifreler. Devam ettirme bileti el sıkışmanın sonunda ClientFinished mesajıyla sunucuya gönderilir. Gelecekteki oturumlarda sunucu bileti ServerInit mesajıyla istemciye geri göndererek oturumu devam ettirmeyi seçebilir. Bilet alındığında istemci hem devam ettirme gizli anahtarı R'yi hem de sunucunun kimliğini kurtarabilir. İstemci bu bilgileri kullanarak oturumu devam ettirebilir.

    IDR her zaman belirli bağlantılarla değil, bir kimlikle ilişkilidir. ALTS'de birden fazla istemci aynı veri merkezindeki aynı kimliği kullanabilir. Bu, istemcilerin daha önce iletişim kurmamış olabilecekleri sunucularla (ör. bir yük dengeleyici istemciyi aynı uygulamayı çalıştıran farklı bir sunucuya gönderirse) oturum devam ettirebilmesine olanak tanır.

  2. İstemci tarafı oturum devam ettirme: El sıkışma işleminin sonunda sunucu ServerFinished mesajıyla istemciye şifrelenmiş bir devam ettirme bileti gönderir. Bu bilet devam ettirme gizli anahtarı R'yi ve istemcinin kimliğini içerir. İstemci bu bileti kullanarak aynı IDR'yi paylaşan herhangi bir sunucuyla bir bağlantıyı devam ettirebilir.

Bir oturum devam ettirildiğinde, devam ettirme gizli anahtarı R'yi kullanarak yeni oturum gizli anahtarları M′, R′ ve A′ türetilir. M′ yük mesajlarını şifrelemek ve kimliklerini doğrulamakta kullanılır, A′ ServerFinished ve ClientFinished mesajlarını doğrulamakta kullanılır ve R′ yeni bir devam ettirme biletine kapsüllenir. Aynı devam ettirme gizli anahtarı R'nin asla bir defadan fazla kullanılmadığına dikkat edin.

Ödünleşimler

Anahtar Güvenliği İhlali Kimliğe Bürünme Saldırıları

ALTS el sıkışma protokolü tasarımı gereği Anahtar Güvenliği İhlali Kimliğe Bürünme (KCI) saldırılarına açıktır. Kötü niyetli bir kişi bir iş yükünün DH özel anahtarı veya devam ettirme anahtarının güvenliğini ihlal ederse bu anahtarı kullanarak bu iş yüküyle iletişim kurarken başka iş yüklerinin kimliğine bürünebilir19. Bir kimliğin bir örneği tarafından yayınlanan devam ettirme biletlerinin bu kimliğin başka örnekleri tarafından da kullanılabilmesini istediğimizden, bu durum açık bir şekilde devam ettirme tehdit modelimizde yer almaktadır.

ALTS el sıkışma protokolünün KCI saldırılarına karşı koruma sağlayan bir değişkeni mevcuttur, fakat bunun yalnızca devam ettirmenin istenmediği ortamlarda kullanılması uygundur.

El Sıkışma Mesajları için Gizlilik

ALTS hangi dahili kimliklerin iletişim kurduğunu gizleyecek şekilde tasarlanmamıştır. Bu nedenle, eşlerin kimliklerini gizlemek için el sıkışma mesajlarını şifrelemez.

Mükemmel İletim Gizliliği

ALTS'de Mükemmel İletim Gizliliği (PFS) desteklenir ama varsayılan olarak etkinleştirilmemiştir. Bunun yerine, çoğu uygulama için iletim gizliliği sağlamak amacıyla sık sertifika rotasyonu kullanırız. TLS 1.2'de (ve önceki sürümlerinde) oturum devam ettirme PFS ile korunmamaktadır. ALTS'de PFS etkinleştirildiğinde, PFS devam ettirilen oturumlar için de etkinleştirilir.

Sıfır Gidiş Dönüş Devam Ettirme

TLS 1.3, sıfır gidiş dönüş (0-RTT) gerektiren oturum devam ettirme sağlar, ama bunun güvenlik özellikleri daha zayıftır20. Google'daki RPC bağlantılarının genellikle uzun ömürlü olması nedeniyle ALTS'ye bir 0-RTT seçeneği eklememeye karar verdik. Yukarıdaki sebeplerden ötürü, kanal oluşturma gecikmesinin azaltılması 0-RTT el sıkışmaların gerektirdiği ek karmaşıklık ve/veya daha düşük güvenliği mazur gösterecek kadar iyi bir özellik değildi.

Diğer referanslar

Dipnotlar

1 Mikro hizmet, bir uygulamayı iş yetenekleri uygulayan serbest bağlantılı hizmetlerden oluşan bir koleksiyon olarak yapılandıran bir mimari stildir.
2 Üretim iş yükü, Google mühendislerinin Google'ın veri merkezlerinde çalıştırmayı planladığı bir uygulamadır.
3 Google'ın geçiş halindeki verileri nasıl koruduğu hakkında daha fazla bilgi edinmek için Google Cloud'da Geçiş Halinde Şifreleme raporumuza bakın.
4 Güven modeli, bir güvenlik protokolünün kimlik bilgileri ve kimlikleri tanımlamak, dağıtmak ve bunlara rotasyon uygulamak için kullandığı mekanizmadır.
5 Bazı hizmetler doğrudan geliştiriciler tarafından yönetilir.
6 Google üretim iş yüklerini planlamak ve başlatmaktan Borgmaster sorumludur. Daha fazla bilgi edinmek için Borg ile Google'da geniş ölçekli küme yönetimi belgesine bakın.
7 Google Cloud'da Geçiş Halinde Şifreleme raporunda sertifika rotasyonu sıklıkları hakkında daha fazla bilgi bulabilirsiniz.
8 Bir anahtarın güvenliği ihlal edilirse saldırgan yalnızca bu anahtar çiftinin kullanım ömrü süresince var olan trafiği keşfedebilir.
11 ALTSd: Başka ALTS işlemlerinin yanı sıra, el sıkışma sertifikalarının oluşturulmasından sorumlu olan arka plan programı.
12 Pratikte CA'nın İmzalama Hizmeti özel anahtarlarına erişimi vardır. Bu da iki mantıksal varlığı tek bir fiziksel varlık haline getirir.
13 Spesifik olarak RFC-5869'da tanımlanan şekliyle HKDF-Çıkarma ve HKDF-Genişletme.
14 ALTS el sıkışma protokolünün uygulanması ServerInit ve ServerFinished mesajlarını tek bir aktarım yükü şeklinde birleştirir.
16 Yük şifrelemenin kararlaştırılması el sıkışmadaki Kayıt protokolünün bir parçası olarak yapılır.
17 128 bit AES-GCM şeması NIST 800-38D'ye dayanır ve AES-VCM, AES-VCM, Tam Sayı Tabanlı Evrensel Bir Karma Fonksiyonu Kullanan Bir AES-GCM Yapısı belgesinde ayrıntılı olarak tartışılmıştır.
18 Oturum devam ettirme yalnızca geçici parametreler mevcut değilse hafif simetrik işlemler içerir.
Bu sayfayı yararlı buldunuz mu? Lütfen görüşünüzü bildirin:

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