BeyondProd: Bulutta yerel güvenliğe yeni bir yaklaşım

Google, şirket içinde geliştirilen, güvenliğin artırılmasına yardımcı olan projeleri açıklayan teknik belgeler hazırlamıştır. BeyondProd, BeyondCorp kavramlarını kasıtlı olarak yeniden ele alır. Tıpkı çevre güvenliği modelinin artık son kullanıcılar için fayda sağlamaması gibi, BeyondCorp da artık mikro hizmetler için fayda sağlamamaktadır. Orijinal BeyondCorp makalesi şöyle değiştirilebilir: "Bu modelin temel varsayımları artık geçerli değildir: Çevre, artık kuruluşun (veri merkezinin) yalnızca fiziksel konumu değildir ve çevrenin içinde kalanlar da artık kişisel bilişim cihazlarının ve kurumsal uygulamaların (mikro hizmetlerin) barındırıldığı kutsal ve güvenli bir yer değildir."

Bu teknik belgede, Google altyapısının farklı parçalarının, "bulutta yerel" olarak bilinen bir mimaride bir arada çalışarak iş yüklerini nasıl koruduğuna dair ayrıntılar sunuyoruz. Google güvenliğine genel bir bakış için Güvenlik Altyapısı Tasarımı teknik belgesine göz atın.

Bu teknik belgenin içeriği, Aralık 2019 itibarıyla doğrudur. Bu teknik belge, yazıldığı anda geçerli olan durumu belirtir. Google Cloud olarak kullanıcılarımız için sağladığımız korumayı durmadan geliştirdiğimizden, güvenlik politikalarımız ve sistemlerimiz zaman içinde değişebilir.

Sözlük

Bu belgede şu tanımlar kullanılmıştır:

  • Mikro hizmet, bir uygulamanın yürütmesi gereken bağımsız görevleri; her biri kendine ait API, kullanıma sunma, ölçeklendirme ve kota yönetimi ile bağımsız olarak geliştirilebilen ve yönetilebilen farklı hizmetlere ayırır. Daha modern bir mimaride web sitesi gibi bir uygulama, tek bir monolitik hizmet yerine mikro hizmetler koleksiyonu olarak çalıştırılabilir. Mikro hizmetler bağımsız, modüler, dinamik ve geçicidir. Birçok ana makine, küme veya hatta bulut genelinde dağıtılabilirler.

  • İş yükü, bir uygulamanın tamamladığı benzersiz bir görevdir. Mikro hizmet mimarisinde, iş yükü bir veya daha fazla mikro hizmet olabilir.

  • İş, bir uygulamanın bir kısmını çalıştıran tek bir mikro hizmet örneğidir.

  • Mikro hizmetler, hizmet kimliği kullanarak altyapıda çalışan diğer hizmetlere kendi kimliğini doğrular.

  • Hizmet ağı, hizmetler arası iletişim için kullanılan altyapı katmanıdır. Trafiği kontrol edebilir, politikalar uygulayabilir ve hizmet çağrıları için merkezi izleme sağlar. Mikro hizmet mimarisi kullanırken bu, hizmetlerin bu denetimleri uygulama yükünü kaldırır ve birçok mikro hizmet genelinde daha basit ve merkezi bir yönetime imkan tanır.

CIO düzeyinde özet

  • Google altyapısı, iş yüklerini container'lar içindeki bağımsız mikro hizmetler olarak dağıtır ve bu iş yüklerini container düzenleme sistemimiz olan Borg'u kullanarak yönetir. Bu, günümüzde yaygın şekilde "bulutta yerel" mimari olarak bilinen kavram için ilham ve temel oluşturur.

  • Google altyapısı özellikle güvenlik dikkate alınarak tasarlanmıştır, bu ilke sonradan düşünülerek benimsenmemiştir. Altyapımız, hizmetleri arasında bir güvence olduğunu varsaymaz.

  • Google, mikro hizmetlerini BeyondProd adlı bir girişimle korur. Bu koruma, kodun değiştirilme ve mikro hizmetlerdeki kullanıcı verilerine erişilme biçimini içerir. BeyondProd; karşılıklı olarak doğrulanan hizmet uç noktaları, aktarım güvenliği, küresel yük dengeleme ve hizmet reddi koruması ile uç nokta sonlandırma, uçtan uca kod kaynağı doğrulama ve çalışma zamanı ortamını korumalı alana alma işlemleri gibi kavramlar içerir.

  • Geleneksel bir güvenlik modelinden bulutta yerel güvenlik modeline geçtiğimizde, altyapımız ve geliştirme sürecimiz olmak üzere iki temel alanda değişiklikler yapmamız gerekti. Paylaşılan bileşenleri derleyerek tüm mikro hizmetleri kapsayan ve bunları birbirine bağlayan bir paylaşılan yapı oluşturduk, bu yapı hizmet ağı olarak da biliniyor. Böylece değişiklikleri kullanıma sunmak ve hizmetler genelinde tutarlı bir güvenlik düzeyine ulaşmak kolaylaştı.

Motivasyon

Google; daha yüksek kaynak kullanımı sağlamak, yüksek düzeyde kullanılabilir uygulamalar derlemek ve Google geliştiricilerinin çalışmalarını kolaylaştırmak için container'ları ve container düzenleme yaklaşımını benimsedi. Container mimarisine alınmış altyapıya geçiş için bir motivasyonumuz daha vardı: Güvenlik denetimlerimizi mimarimizle uyumlu kılmak. Çevre tabanlı bir güvenlik modelinin yeterince güvenli olmadığını açıkça görmüştük. Bir saldırgan, çevreyi aşması durumunda ağ içinde serbestçe hareket edebilirdi. Altyapımız genelinde daha güçlü güvenlik denetimlerine ihtiyaç duyduğumuzu fark etmekle birlikte, Google geliştiricilerinin de güvenlik özelliklerini kendileri uygulamak zorunda kalmadan güvenli uygulamalar yazabilmelerini ve dağıtabilmelerini kolaylaştırmak istiyorduk.

Monolitik uygulamalardan, düzenleme sistemi kullanarak container'lardan dağıtılan mikro hizmetlere geçişin somut operasyonel avantajları vardı: daha basit yönetim ve ölçeklenebilirlik. Bulutta yerel bu mimari, dağıtımları mikro hizmetlerin yönetim ve ölçeklenebilirlik avantajlarıyla uyumlu şekilde korumak için farklı araçlar içeren farklı bir güvenlik modeli gerektiriyordu.

Bu belge, burada BeyondProd olarak isimlendirilen bulutta yerel güvenliğin Google'da nasıl uygulandığını açıklar: Bulutta yerel güvenliğe geçişin güvenlik açısından anlamı, bulutta yerel güvenlik için güvenlik ilkeleri, bu gereksinimleri ele almak amacıyla oluşturulan sistemler ve benzer bir zorluğu kendi başınıza çözebilmeniz için bazı rehber bilgiler gibi konuları içerir.

Google'da bulutta yerel güvenlik

Container mimarisine alınmış mikro hizmetler

Google ilk zamanlarından beri, pahalı ve yüksek düzeyde kullanılabilir donanımlara yatırım yapmak yerine veri merkezi kapasitesini yaygın kullanılan düşük maliyetli sunucularla kurma şeklinde bilinçli bir tercihte bulundu. Sistemdeki bağımsız bir parça hata verse bile kullanıcıya görünen hizmetlerin kullanılabilirliğini sekteye uğratmamalıdır. Güvenilirliğimizin yol gösterici ilkesi her zaman bu olmuştur. Bu kullanılabilirliğe ulaşmak, tekil hataların kesintilere yol açmayacağı şekilde hizmetlerin yedekli örneklerini çalıştırmayı gerektiriyordu. Bu ilkenin sonucunda; yüksek yedekliliğe sahip bu dağıtılmış sistemlerin dağıtımlarını ölçeklendirilebilir şekilde yönetebilmek amacıyla container'lar, mikro hizmetler ve container düzenleme yaklaşımı geliştirildi.

Container mimarisine alınmış altyapı, her bir iş yükünün kendine ait bir değişmez, taşınabilir ve planlanabilir container'lar kümesi olarak dağıtılması anlamına gelir. Bu container'ları dahili olarak yönetmek amacıyla Borg1 adlı container düzenleme sistemini geliştirdik. Günümüzde halen her hafta birkaç milyar container'ın dağıtımı için bu sistemi kullanmaktayız.

Container'lar, iş yükleri için makineler genelinde kutu yükleme ve yeniden planlama yürütülmesini kolaylaştırmıştır. Mikro hizmetler ise bir uygulamanın geliştirilmesini ve farklı bölümlerinde hata ayıklamayı kolaylaştırmıştır. Mikro hizmetler ve container'lar, birlikte kullanıldıklarında iş yüklerinin bakım ve keşif amacıyla daha küçük ve kolay yönetilebilir birimlere ayrılabilmesini sağlar. Mikro hizmet mimarisi ile container mimarisine alınmış bir altyapıya geçiş, "bulutta yerel" sisteme geçiş olarak da bilinir. Hizmetler, Borg tarafından dağıtılan container'larda çalışır. Bu mimari, iş yüklerini gerektiği şekilde ölçeklendirir. Belirli bir iş yükü için yüksek talep varsa iş yükünü gerekli ölçekte yürütmek için aynı hizmetin kopyalarını çalıştıran birden fazla makine olabilir.

Google, güvenliği mimarimizdeki tüm geliştirmelerin bir parçası olarak dikkate almasıyla öne çıkar. Yakın zamanda ortaya çıkan bulutta yerel güvenlik kavramı, Google'ın yıllardır altyapımızı güvenceye almak amacıyla kullandığı sistemle karşılaştırılabilir düzeydedir. Bu mikro hizmet mimarisi ve geliştirme süreci ile amacımız, güvenlik sorunlarını geliştirme ve dağıtım yaşam döngüsünün mümkün olduğunca başlarında, bu sorunları ele almanın daha az maliyetli olduğu zamanda ele almak ve bunu standartlaştırılmış ve tutarlı bir şekilde yapmaktır. Böylece geliştiriciler daha güvenli sonuçlar elde etmeye devam ederken güvenlik konusunda daha az zaman harcayabilir.

Bulutta yerel mimariye geçiş

Modern güvenlik mimarileri, bir duvarın çevreyi koruduğu ve içerideki tüm kullanıcı veya hizmetlerin tamamen güvenilir olduğu geleneksel çevre tabanlı güvenlik modelinin ötesine geçti. BeyondCorp, modern kurumsal kullanıcının çalışma şeklindeki değişikliğe yanıt olarak ortaya çıktı. Günümüzde kullanıcılar hareket halinde ve genellikle bir kuruluşun geleneksel güvenlik çevresinin dışında, örneğin kafe veya uçak gibi herhangi bir yerde çalışabiliyor. BeyondCorp ile ayrıcalıklı bir kurumsal ağ fikrinden vazgeçmiş ve erişimi bir kullanıcının ağ konumundan bağımsız şekilde yalnızca cihaz ve kullanıcı kimlik bilgilerine ve özelliklerine dayanarak vermiştik.

Bulutta yerel güvenlik, aynı sorunu kullanıcılar için ele aldığı gibi hizmetler için de ele alıyor: Bulutta yerel bir dünyada, tıpkı kurumsal ağı korumak için bir güvenlik duvarına bel bağlayamayacağımız gibi, üretim ağını korumak için de bir güvenlik duvarına bel bağlayamayız. Tüm kullanıcılar aynı fiziksel konumu veya cihazı kullanmadığı gibi tüm geliştiriciler de aynı ortama kod dağıtmaz. BeyondProd ile mikro hizmetler yalnızca güvenlik duvarına sahip bir veri merkezinde değil; aynı zamanda herkese açık bulutlarda, özel bulutlarda veya üçüncü tarafların barındırdığı hizmetlerde çalışabilir ve her yerde güvenli olmaları gerekir.

Nasıl ki kullanıcılar hareket ediyor, farklı cihazlar kullanıyor ve farklı konumlardan bağlanıyorsa mikro hizmetler de hareket eder ve heterojen barındırıcılar genelinde farklı ortamlarda dağıtılır. BeyondCorp, "kullanıcı güveni, cihazların kurumsal ağa bağlanabilmesine değil, cihazların bağlama duyarlı durumu gibi özelliklere bağlı olmalıdır" derken, BeyondProd ise "hizmet güveni, IP veya ana makine kimliği gibi üretim ağındaki konumlara değil, kod kaynağı ve hizmet kimliği gibi özelliklere bağlı olmalıdır" der.

Bulutta yerel yaklaşım ve uygulama geliştirme

Çevre tabanlı güvenliğe odaklanan daha geleneksel bir güvenlik modeli, bulutta yerel bir mimariyi tek başına koruyamaz. Üç katmanlı mimari kullanan bir monolitik uygulamanın, kritik öneme sahip etkinlikler için maksimum yükü kaldırabilecek kapasiteye sahip özel bir kurumsal veri merkezine dağıtıldığı bir örneği düşünün. Burada belirli donanım veya ağ iletişimi gereksinimlerine sahip uygulamalar, kasıtlı olarak normalde sabit IP adreslerine sahip belirli makinelere dağıtılır. Sonuç itibarıyla meydana gelen değişiklikler eşzamanlı olarak uygulamanın birçok bölümünü etkilediği için kullanıma sunma işlemleri seyrek, yüksek hacimli ve zor koordine edilir özellikte olur. Bu da daha seyrek güncellenen, güvenlik yamalarının da genellikle daha seyrek uygulandığı aşırı uzun ömürlü uygulamalar yaratır.

Ancak bulutta yerel modelde container'lar, uygulamanızın ihtiyaç duyduğu ikili programları ana makine işletim sisteminden ayırır ve uygulamaları daha taşınabilir hale getirir. Container'ların sabit biçimde kullanılmaları amaçlanmıştır; yani dağıtıldıktan sonra değişmezler. Bu nedenle sıklıkla yeniden derlenir ve yeniden dağıtılırlar. İşler yükleri kaldırabilecek şekilde ölçeklendirilir, yük arttığında yeni işler dağıtılır ve yük azaldığında mevcut işler sonlandırılır. Container'ların sıklıkla yeniden başlatılması, sonlandırılması veya yeniden planlanması sonucunda donanım ve ağ iletişiminin yeniden kullanımı ve paylaşımı daha sık gerçekleştirilir. Yaygın kullanılan standartlaştırılmış bir derleme ve dağıtım süreci sayesinde, ekipler kendi mikro hizmetlerinin geliştirilme sürecini ayrı ayrı yönetse bile, süreçler ekipler arasında daha tutarlı ve dengeli hale gelir. Bunun sonucunda, güvenlikle ilgili konular (ör. güvenlik incelemeleri, kod tarama ve güvenlik açığı yönetimi) geliştirme sürecinin daha erken adımlarında ele alınabilir.

Güvenlik açısından sonuçlar

BeyondCorp kullanıcılarına ve güvenilmeyen bir iç yapıya sahip modelin BeyondProd'daki mikro hizmetler için de geçerli olabileceğinden fazlasıyla bahsettik. Peki bu değişim neye benziyor? Tablo 1'de geleneksel altyapı güvenliği unsurları ve bunların bulutta yerel mimariyle farkları, karşılaştırmalı olarak belirtilmiştir. Tabloda ayrıca bir sistemden diğerine geçiş gereksinimleri de gösterilir. Bu bölümün sonraki kısımları, tablonun her bir satırı hakkında ayrıntılı bilgi verir.

Geleneksel altyapı güvenliği Bulutta yerel güvenlik Bulutta yerel güvenlik için gereksinimler
Çevre tabanlı güvenlik (ör. güvenlik duvarı). İç iletişimlerin güvenilir olduğu kabul edilir. Sıfır güven ilkesi. Hizmetler arası iletişim doğrulanmıştır ve ortamdaki hizmetlere dolaylı da olsa güvenilmez. Ağın uçta korunması (geçerliliğini korur) ve hizmetler arasında karşılıklı güven olmaması.
Belirli uygulamalar için sabit IP ve donanım. Daha fazla kaynak kullanımı, yeniden kullanımı ve paylaşımı (IP'ler ve donanım dahil). Kaynağı bilinen kodlar çalıştıran güvenilir makineler.
IP adresi tabanlı kimlik. Hizmet tabanlı kimlik.
Hizmetler, bilinen ve beklenen bir konumda çalışır. Hizmetler, ortamda herhangi bir yerde çalışabilir (herkese açık bulut ve özel veri merkezleri genelindeki karma dağıtımlar dahil).
Her bir uygulamada yerleşik olarak sunulan ve ayrı ayrı uygulanan, güvenliğe özgü gereksinimler.Merkezi bir zorunlu kılma politikası izlenerek hizmet yığınlarına entegre edilen ortak güvenlik gereksinimleri. Hizmetler genelinde politikaların tutarlı şekilde uygulanması için dar geçit noktaları.
Hizmetlerin derlenmesi ve incelenmesi konusunda sınırlı kısıtlamalar. Tutarlı şekilde tüm hizmetler için uygulanan güvenlik gereksinimleri.
Gözetimi sınırlı güvenlik bileşenleri. Güvenlik politikalarına ve politikalara bağlılığa dair merkezi bir bakış.
Özel ve seyrek kullanıma sunumlar. Mikro hizmetlerin daha sık değiştirildiği standartlaştırılmış bir derleme ve kullanıma sunma süreci. Basit, otomatikleştirilmiş ve standartlaştırılmış değişiklik kullanıma sunma.
İş yükleri genellikle sanal makineler olarak veya fiziksel ana makinelere dağıtılır; yalıtım sağlamak için fiziksel makineler ya da hipervizör kullanılır. Kutu yükleme uygulanan iş yükleri ve bunlara ait süreçler paylaşılan bir işletim sisteminde çalışır; iş yüklerinin yalıtımı için bir mekanizma gereklidir. Bir işletim sistemini paylaşan iş yükleri arasında yalıtım.

Tablo 1: Bulutta yerel mimariye geçiş için güvenlik gereksinimleri

Çevre tabanlı güvenlikten sıfır güven ilkeli güvenliğe

Geleneksel güvenlik modelinde bir kuruluşun uygulamaları, gelen trafiğe karşı koruma sağlamak için kuruluşun özel veri merkezi çevresindeki harici bir güvenlik duvarına bağlı olabilir. Bulutta yerel bir ortamda, ağ çevresinin yine de BeyondCorp modelinde olduğu gibi korunması gerekse de, çevre tabanlı bir güvenlik modeli artık yetersiz kalır. Bu yeni bir güvenlik sorunu anlamına gelmez ancak şu gerçeğin kabul edilmesini sağlar: Bir güvenlik duvarı, kurumsal ağı tamamen koruyamıyorsa üretim ağını da tamamen koruyamaz. Sıfır güven ilkeli güvenlik modelinde, dahili trafiğe tam olarak güvenemezsiniz. Kimlik doğrulama ve şifreleme gibi başka güvenlik denetimleri gerekir. Aynı zamanda, mikro hizmetlere geçiş, geleneksel güvenlik modelini yeniden değerlendirme fırsatı sunar. Tek bir ağ çevresine (ör. güvenlik duvarı) olan bağlılığınızı kaldırarak, ağı hizmetlere göre segmentlere ayırabilirsiniz. Bu fikri daha da ileri götürerek, hizmetler arasında güvenin olmadığı mikro hizmet düzeyinde segmentasyonu benimseyebilirsiniz. Mikro hizmetler sayesinde trafik, farklı denetimler içeren çeşitli güven seviyelerine sahip olabilir. Artık sadece dahili ve harici trafiği karşılaştırmazsınız.

Sabit IP ve donanımdan daha fazla paylaşılan kaynağa

Geleneksel güvenlik modelinde bir kuruluşun uygulamaları belirli makinelere dağıtılır ve bu makinelerin IP adresleri seyrek olarak değiştirilirdi. Bu durum, güvenlik araçlarının uygulamaları tahmin edilebilir bir şekilde birbirine bağlayan görece statik bir mimari haritasına güvenebileceği anlamına geliyordu. Güvenlik duvarı gibi araçların güvenlik politikaları, tanımlayıcı olarak IP adreslerini kullanabiliyordu.

Ancak bulutta yerel dünyada, paylaşılan ana makineler ve sık değişen işler nedeniyle mikro hizmetler arası erişimi kontrol etmek için güvenlik duvarı kullanmak işe yaramaz. Belirli bir IP adresinin belirli bir hizmete bağlı olmasına güvenemezsiniz. Bunun sonucunda, kimlik için bir IP adresi veya ana makine adını temel almak yerine bir hizmeti temel alırsınız.

Uygulamaya özgü güvenlik uygulamalarından hizmet yığınlarına entegre edilen paylaşılan güvenlik gereksinimlerine

Geleneksel güvenlik modelinde uygulamaların her biri, diğer hizmetlerden bağımsız şekilde kendi güvenlik gereksinimlerini karşılamakla sorumluydu. Bu gereksinimler arasında kimlik yönetimi, SSL/TLS sonlandırma ve veri erişim yönetimi yer alıyordu. Bu da sıklıkla tutarsız uygulamalar benimsenmesine veya ele alınmayan güvenlik sorunlarına yol açıyordu. Sorunların birçok yerde çözülmesi gerekiyor ve çözümlerin uygulanması zorlaşıyordu.

Bulutta yerel dünyada, bileşenler hizmetler arasında çok daha sık bir şekilde yeniden kullanılır ve politikaların hizmetler genelinde tutarlı şekilde zorunlu kılınmasına imkan tanıyan dar geçit noktaları bulunur. Farklı güvenlik hizmetleri kullanılarak farklı politikalar zorunlu kılınabilir. Her bir uygulamanın kritik güvenlik hizmetlerini ayrı ayrı benimsemesi gerekliliğine alternatif olarak, çeşitli politikaları farklı mikro hizmetlere bölebilirsiniz (örneğin, kullanıcı verilerine yetkilendirilmiş erişim sağlamak için bir politika, güncel TLS şifreleme paketlerinin kullanımını sağlamak için başka bir politika).

Özel ve seyrek kullanıma sunum süreçlerinden, kullanıma sunumların daha sık gerçekleştiği standartlaştırılmış süreçlere

Geleneksel güvenlik modelinde, paylaşılan hizmetler sınırlıydı. Daha yüksek dağıtımlı kod ve yerel geliştirme, bir uygulamanın birçok kısmını etkileyen bir değişikliğin etkisini belirlemenin zor olması anlamına geliyordu. Bunun sonucunda, kullanıma sunma işlemleri seyrek oluyor ve zor koordine ediliyordu. Geliştiriciler, bir değişiklik yapmak için her bir bileşeni doğrudan güncellemek zorunda kalabiliyordu (örneğin, bir yapılandırmayı güncellemek için sanal makineye SSH uygulama). Bu da genel olarak uygulamaların aşırı uzun ömürlü olmasına yol açıyordu. Güvenlik açısından bakıldığında, kod daha yüksek dağıtımlı olduğu için incelenmesi de daha zordu ve bir güvenlik açığı giderilirken her yerde giderildiğinden emin olmak çok daha zorlu bir işti. Kullanıma sunumların daha sık ve standartlaştırılmış olduğu bulutta yerel sisteme geçiş, yazılım geliştirme yaşam döngüsünde güvenliğin sola kaymasını2 sağlar. Bu da, güvenlik yamalarının düzenli uygulanması dahil, güvenlik hijyeninin daha basit ve tutarlı bir şekilde uygulanmasına imkan tanır.

Fiziksel makineler veya hipervizör kullanılarak yalıtılan iş yüklerinden aynı makine üzerinde çalışan ve daha yüksek yalıtım gerektiren kutu yükleme uygulanmış iş yüklerine

Geleneksel güvenlik modelinde iş yükleri, paylaşılan kaynaklar olmadan kendi örnekleri üzerinde planlanıyordu. Bir uygulama, kendi makine ve ağ sınırıyla etkili şekilde sınırlandırılıyor ve iş yükü yalıtımı sadece fiziksel ana makinelerin ayrılması, hipervizörler ve geleneksel güvenlik duvarlarına dayanarak yürütülüyordu.

Bulutta yerel dünyada, iş yükleri container mimarisine alınır ve bu yüklerin kutu yüklemesi paylaşılan ana makineler ve kaynaklarda gerçekleşir. Bu nedenle, iş yükleriniz arasında daha güçlü yalıtım olması gerekir. İş yükleri, ağ denetimleri ve korumalı alana alma teknolojileri kullanılarak birbirinden yalıtılan mikro hizmetlere ayrılabilir.

Güvenlik ilkeleri

Bulutta yerel mimariyi geliştirirken, güvenliğimizi de bir yandan güçlendirmek istedik. Bu nedenle, aşağıdaki güvenlik ilkelerini geliştirdik ve bunların optimizasyonunu gerçekleştirdik:

  • Ağın uçta korunması sayesinde iş yükleri, ağ saldırılarından ve yetkilendirilmemiş internet trafiğinden yalıtılır. Duvar tabanlı yaklaşım, bulutta yerel sistem için yeni bir kavram olmasa da halen en iyi güvenlik uygulamalarından biridir. Bulutta yerel dünyada çevre yaklaşımı, altyapıyı yetkilendirilmemiş trafiğe ve hacim temelli Hizmet Reddi saldırıları gibi olası internet saldırılarına karşı mümkün olabildiğince korumak için kullanılır.

  • Hizmetler arasında karşılıklı güven olmaması sayesinde yalnızca bilinen, güvenilen ve özel olarak yetkilendirilen çağrı sahipleri bir hizmeti kullanabilir. Böylece saldırganların bir hizmete erişmek için güvenilmeyen kod kullanması önlenir. Bir hizmetin güvenliği ihlal edilirse bu, saldırganın erişimini genişletebileceği işlemler yürütmesini engeller. Karşılıklı güven olmaması, bir güvenlik ihlalinin etki alanını sınırlandırmaya yardımcı olur.

  • Kaynağı bilinen kodlar çalıştıran güvenilir makineler sayesinde, hizmet kimlikleri yalnızca yetkilendirilmiş kod ve yapılandırmalar kullanacak ve yalnızca yetkilendirilmiş ve doğrulanmış ortamlarda çalışacak şekilde sınırlandırılır.

  • Hizmetler genelinde politikaların tutarlı şekilde uygulanması için dar geçit noktaları. Örneğin, kullanıcı verilerine erişim isteklerini doğrulamak amacıyla, bir hizmet erişiminin yetkilendirilmiş bir son kullanıcıdan gelen onaylanmış istekten elde edildiği ve yönetici erişimi için işletme gerekçelendirmesinin zorunlu olduğu dar geçit noktası.

  • Basit, otomatikleştirilmiş ve standartlaştırılmış değişiklik kullanıma sunma sayesinde altyapı değişikliklerinin güvenlik üzerindeki etkileri kolayca incelenebilir ve güvenlik yamaları da üretime çok az etki ile kullanıma sunulabilir.

  • Bir işletim sistemini paylaşan iş yükleri arasında yalıtım sayesinde, bir hizmetin güvenliği ihlal edildiğinde bu durum aynı ana makine üzerinde çalışan başka bir iş yükünün güvenliğini etkileyemez. Bu da, potansiyel bir güvenlik ihlalinin "etki alanını" sınırlandırır.

Altyapımızın tamamı için amacımız, bireylere bağlı olmayan otomatik güvenliğe sahip olmaktır. Güvenlik, hizmetlerle aynı şekilde ölçeklenmelidir. Hizmetler varsayılan olarak güvenli olmalı ve güvensizlik ancak istisnai durumlarda ortaya çıkmalıdır. Kullanıcı işlemleri de rutin değil istisnai olmalı ve gerçekleştiği zaman denetlenebilmelidir. Böylece bir hizmette, onu dağıtan kişiler yerine hizmet için dağıtılan koda ve yapılandırmaya dayanan bir kimlik doğrulama yapabiliriz.

Bu güvenlik ilkelerinin bir arada uygulanması; içeride çalışan container ve mikro hizmetlerin dağıtılabilmesi, birbirleriyle iletişim kurabilmesi ve bulutta yerel mimarinin özelliklerini zayıflatmadan yan yana çalışabilmesi (ör. basit iş yükü yönetimi, işlemsiz ölçeklendirme ve etkili kutu yükleme) anlamına gelir. Tüm bunlar, altyapıdaki güvenlik ve uygulama ayrıntıları yüklerini mikro hizmet geliştiricilerine yüklemeden başarılabilir.

Google'ın dahili güvenlik hizmetleri

Google'ın bulutta yerel altyapısını korumak için çeşitli dahili araçlar ve hizmetler tasarlayıp geliştirdik. Aşağıda listelenen güvenlik hizmetleri, birlikte çalışarak Güvenlik İlkeleri bölümünde açıklanan güvenlik ilkelerini ele alır:

  • Google Front End (GFE): Son kullanıcı ile bağlantıyı sonlandırır ve TLS en iyi uygulamalarını zorunlu kılmak için merkezi bir nokta sağlar. Odağımız artık çevre tabanlı güvenlik üzerinde olmasa da GFE, dahili hizmetleri hizmet reddi saldırılarına karşı koruma stratejimizin önemli bir parçası olmaya devam eder. GFE, bir kullanıcının Google ile bağlantısı için ilk giriş noktasıdır. Altyapımıza girdikten sonra, GFE aynı zamanda yük dengeleme ve trafiği bölgeler arasında gerektiği şekilde yeniden yönlendirme ile de sorumludur. Altyapımızda GFE, trafiği doğru mikro hizmete yönlendiren uç proxy'sidir.

  • Uygulama Katmanı Aktarım Güvenliği (ALTS): RPC doğrulaması, bütünlük ve şifreleme için kullanılır. ALTS, Google altyapısındaki hizmetler için karşılıklı kimlik doğrulama ve aktarım şifreleme sistemidir. Kimlikler genellikle belirli bir sunucu adı veya ana makine yerine hizmetlere bağlıdır. Bu da sorunsuz mikro hizmet replikasyonu, yük dengeleme ve ana makineler arasında yeniden programlama işlemlerini kolaylaştırır.

  • Borg için İkili Program Yetkilendirmesi ve Ana Makine Bütünlüğü sırasıyla mikro hizmet ve makine bütünlüğü doğrulaması için kullanılır:

    • Borg için İkili Program Yetkilendirmesi (BAB): Dağıtım zamanında uygulanan ve kodun dağıtılmadan önce dahili güvenlik gereksinimlerini karşıladığından emin olmayı sağlayan bir denetimdir. BAB denetimleri arasında değişikliklerin ikinci bir mühendis tarafından incelenmesi, kodun kaynak kod depomuza gönderilmesi ve ikili programların doğrulanabilir şekilde özel altyapı üzerinde derlenmesi yer alır. Altyapımızda BAB, yetkilendirilmemiş mikro hizmetlerin dağıtımını kısıtlar.
    • Ana Makine Bütünlüğü (HINT): Ana makine sistem yazılımının bütünlüğünü, güvenli başlatma işlemi ile doğrular ve mümkün olan yerlerde güvenli mikro denetleyici donanımla desteklenir. HINT denetimleri arasında dijital imzaların BIOS üzerinde doğrulanması, BMC, bootloader ve işletim sistemi çekirdeği yer alır.
  • Hizmet Erişim Politikası ve Son kullanıcı bağlamı biletleri verilere erişimi kısıtlamak için kullanılır:

    • Hizmet Erişim Politikası: Hizmetler arasında verilere erişilme şeklini sınırlandırır. Bir hizmetten diğerine bir RPC gönderildiğinde, Hizmet Erişim Politikası alıcı taraftaki hizmetin verilerine erişmek için gerekli kimlik doğrulama, yetkilendirme ve denetim politikalarını tanımlar. Bu da verilere erişilme şeklini sınırlandırır, gerekli en düşük erişim düzeyini sağlar ve erişimin nasıl denetlenebileceğini belirtir. Google altyapısında, Hizmet Erişim Politikası bir mikro hizmetin bir diğer mikro hizmetin verilerine erişimini sınırlandırır ve erişim kontrollerinin küresel analizlerine imkan tanır.
    • Son kullanıcı bağlamı (EUC) biletleri: Bu biletler, bir Son Kullanıcı Kimlik Doğrulaması hizmeti tarafından verilir ve hizmetlere hizmet kimliğinden ayrı bir kullanıcı kimliği sağlar. Bu biletler bütünlüğü korunan, merkezi olarak verilen ve yönlendirilebilen kimlik bilgileridir. Hizmet isteğinde bulunan bir son kullanıcının kimliğini kanıtlar. Böylece, ALTS aracılığıyla sağlanan eş kimliği genellikle erişim vermek için yetersiz olduğundan kimlik doğrulama kararları tipik olarak son kullanıcının kimliğine de dayandırılır ve hizmetler arasında güven ihtiyacı azalır.
  • Mavi-yeşil dağıtımlar için Borg araçları3: Bu araçlar, bakım görevleri yürütülürken çalışan iş yüklerinin taşınmasından sorumludur. Mevcut Borg işine ek olarak yeni bir Borg işi dağıtılır ve bir yük dengeleyici, trafiği bir işten diğerine aşamalı olarak taşır. Böylece bir mikro hizmet, kesinti yaşanmadan ve kullanıcı fark etmeden güncellenebilir. Bu araçlar, yeni özellikler eklediğimiz zamanlarda hizmet yükseltmeleri uygulamak ve kritik güvenlik güncellemelerini (ör. Heartbleed ve Spectre/Meltdown) kesinti yaşamadan uygulamak amacıyla kullanılır. Google Cloud altyapısını etkileyen değişikliklerde, sanal makine iş yüklerinin etkilenmemesini sağlamak için canlı geçiş kullanırız.

  • İş yükü yalıtımı için gVisor. gVisor, syscall'lara müdahale etmek ve bunları yönetmek için kullanıcı alanı çekirdeğini kullanarak ana makine ve potansiyel saldırı yüzeyi arasındaki etkileşimi azaltır. Bu çekirdek, bir uygulamanın çalıştırılması için gereken işlevlerin çoğunu sağlar ve uygulamanın erişebildiği ana makine çekirdek yüzeyini sınırlandırır. Google altyapısında gVisor, aynı ana makine üzerinde çalışan dahili iş yüklerini ve Google Cloud müşteri iş yüklerini birbirinden yalıtmak için kullanılan önemli araçlardan biridir.

Tablo 2, Güvenlik İlkeleri bölümünde açıkladığımız ilkelerin her birini, Google'da o ilkeyi uygulamak için kullandığımız ilgili araçla eşleştirmektedir.

Güvenlik ilkesi Google'ın dahili güvenlik aracı/hizmeti
Ağın uçta korunması Google Front End (GFE): TLS sonlandırma ve gelen trafik için politika yönetimi
Hizmetler arasında karşılıklı güven olmaması Uygulama Katmanı Aktarım Güvenliği (ALTS): RPC doğrulaması, bütünlük, şifreleme ve hizmet kimlikleri
Kaynağı bilinen kodlar çalıştıran güvenilir makineler Borg için İkili Program Yetkilendirmesi (BAB): Kod kaynağı doğrulaması

Ana Makine Bütünlüğü (HINT): Makine bütünlüğü doğrulaması

Hizmetler genelinde politikaların tutarlı şekilde uygulanması için dar geçit noktaları Hizmet Erişim Politikası: Hizmetler arasında verilere erişilme şeklini sınırlandırma

Son kullanıcı bağlamı (EUC) biletleri: Orijinal istek sahibinin kimliğini kanıtlama

Basit, otomatikleştirilmiş ve standartlaştırılmış değişiklik kullanıma sunma Borg araçları: Mavi-yeşil dağıtımlar
Bir işletim sistemini paylaşan iş yükleri arasında yalıtım gVisor: İş yükü yalıtımı

Tablo 2: Google'da bulutta yerel güvenliğin uygulanması için ilkeler ve güvenlik araçları

Tüm unsurların birleşimi

Bu bölümde, şimdiye kadar ele aldığımız bileşenlerin nasıl bulutta yerel dünyada bir araya gelerek kullanıcı isteklerini karşıladığı açıklanmaktadır. Bunun için de şu iki örneği düşünelim: Öncelikle kullanıcı verilerine ilişkin tipik bir isteği, oluşturulma anından hedefe iletilmesine kadar izliyoruz. İkinci adımda, bir kod değişikliğini geliştirme aşamasından üretime kadar izliyoruz. Google altyapısının tüm bölümlerinde burada listelenen teknolojilerin hepsi birden kullanılmaz; kullanım durumu hizmetlere ve iş yüklerine bağlıdır.

Kullanıcı verilerine erişim

Şekil 1'de görüldüğü gibi, GFE bir kullanıcı isteğini aldığında (1. adım), TLS bağlantısını sonlandırır ve isteği ALTS4 üzerinden uygun hizmetin ön ucuna iletir (2. adım). Uygulamanın ön ucu, merkezi bir Son Kullanıcı Kimlik Doğrulaması (EUA) Hizmeti kullanarak kullanıcının isteği için kimlik doğrulama yürütür ve başarılı olursa kısa ömürlü ve şifreli bir son kullanıcı bağlamı bileti (EUC) alır (3. adım).

diyagram

Şekil 1: Google'ın bulutta yerel mimari güvenlik denetimleri - kullanıcı verilerine erişim

Uygulama ön ucu daha sonra ALTS üzerinden bir depolama arka uç hizmetine RPC gönderir ve arka uç isteğinde EUC biletini iletir (4. adım). Arka uç hizmeti, aşağıdakileri sağlamak için Hizmet Erişim Politikası kullanır:

  1. ön uç hizmetinin ALTS kimliğinin arka uç hizmetine istek yapma ve EUC bileti sunma yetkisine sahip olmasını,
  2. ön uç kimliğinin Borg için İkili Program Yetkilendirmesi (BAB) ile korunmasını ve
  3. EUC biletinin geçerli olmasını.

Arka uç hizmeti daha sonra EUC biletindeki kullanıcının istenen verilere erişme yetkisine sahip olup olmadığını denetler. Bu denetimlerin herhangi biri başarısız sonuç verirse istek reddedilir. Çoğu durumda, arka uç çağrılarından oluşan bir zincir bulunur. Aradaki her hizmet, gelen RPC'ler üzerinde Hizmet Erişim Politikası denetimi yürütür ve EUC bileti giden RPC'lere iletilir. Bu denetimlerin başarılı sonuç vermesi durumunda, veriler yetkilendirilmiş uygulama ön ucuna döndürülür ve yetkilendirilmiş kullanıcıya sunulur.

Her makine, HINT sistemi aracılığıyla temel hazırlığı yapılan bir ALTS kimlik bilgisine sahiptir ve yalnızca HINT, makine başlatma işleminin başarılı olduğunu doğrularsa şifrelenebilir. Çoğu Google hizmeti, Borg üzerinde mikro hizmetler olarak çalışır ve bu mikro hizmetlerin her biri kendi ALTS kimliğine sahiptir. Borgmaster5 bu ALTS mikro hizmet kimlik bilgilerini, Şekil 1'de açıklandığı gibi mikro hizmetin kimliğine dayanarak iş yüklerine verir. Makine düzeyindeki ALTS kimlik bilgileri, mikro hizmet kimlik bilgilerinin temel hazırlığı için güvenli bir kanal oluşturur. Böylece yalnızca HINT ile doğrulanmış başlatmayı başarıyla geçebilen makineler mikro hizmet iş yükleri barındırabilir.

Kod değişikliği yapma

Şekil 2'de gösterildiği gibi, bir Google çalışanı yeterince güçlü bir BAB ile korunan bir mikro hizmette değişiklik yaptığında, değişikliğin merkezi kod depomuza gönderilmesi gerekir ve bu da kod incelemesini zorunlu kılar. Değişiklik, onaylandıktan sonra merkezi ve güvenilir derleme sistemimize gönderilir. Sistem, imzalı ve doğrulanabilir bir derleme manifesti sertifikası ile bir paket oluşturur (1. adım). Dağıtım sırasında BAB, bu sürecin derleme ardışık düzenindeki imzalı sertifika doğrulanarak izlendiğini onaylar (2. adım).

diyagram

Şekil 2: Google'ın bulutta yerel mimari güvenlik denetimleri - kod değişikliği yapma

Tüm iş yükü güncellemeleri, ister rutin bir kullanıma sunma ister acil durum güvenlik yaması olsun, mavi-yeşil dağıtımlar aracılığıyla ele alınır (3. adım). GFE, işlemlerin sürekliliğini sağlamak amacıyla yeni dağıtıma giden trafik için yük dengeleme uygular.

Tüm iş yükleri yalıtım gerektirir. İş yükü daha az güvenilir yapıdaysa; örneğin iş yükü çok kiracılıysa veya kaynak kod Google dışından geliyorsa iş yükü gVisor korumalı bir ortama dağıtılabilir ya da diğer yalıtım katmanlarını kullanabilir. Bu yalıtım, bir örneğin veya uygulamanın güvenliğinin ihlal edilmesi durumunda diğer örneklerin hiçbirinin etkilenmemesini sağlar.

BeyondProd'u uygulama

Sağlam bir geçiş

Google, bulutta yerel sisteme geçerek ve bu altyapıyı uygun şekilde güvenceye alarak dahili ve harici (Google Cloud) iş yükleri için çok güçlü güvenlik özellikleri sunabilir.

Paylaşılan bileşenlerin derlenmesiyle, geliştiricilerin yaygın güvenlik gereksinimlerini karşılama yükü en aza indirilir. İdeal olarak, güvenlik işlevi her bir bağımsız uygulamaya çok az entegrasyon gerektirmeli veya hiç entegrasyon gerektirmemelidir. Bunun yerine, tüm mikro hizmetleri kapsayan ve bunları birbirine bağlayan bir yapı olarak sunulur. Bu yapı yaygın olarak "hizmet ağı" olarak bilinir. Bu aynı zamanda, güvenliğin normal geliştirme veya dağıtım işlemlerinden ayrı olarak yönetilebileceği ve uygulanabileceği anlamına gelir.

Bulutta yerel mimariye geçişi gerçekleştirme

Google'ın bulutta yerel mimariye geçişi, altyapımız ve geliştirme sürecimiz olmak üzere iki temel alanda değişiklikler gerektirdi. Bu değişiklikleri eşzamanlı olarak ele aldık ancak bunlar birbirinden bağımsız olarak incelenebilirdi.

Altyapımızı değiştirme

Hizmet kimliği, kimlik doğrulama ve yetkilendirme için güçlü bir temel oluşturarak işe başladık. Güvenilir hizmet kimliklerine sahip bir temelimizin olması, bu hizmet kimliklerinin doğrulanmasına bağlı olan, Hizmet Erişim Politikaları ve EUC biletleri gibi daha üst düzey güvenlik özelliklerini uygulayabilmemizi sağladı. Bu geçişi hem yeni hem de mevcut hizmetler için kolaylaştırabilmek amacıyla, ALTS öncelikle tek bir yardımcı arka plan programına sahip bir kitaplık olarak sunuldu. Bu arka plan programı, tüm hizmetler tarafından çağrılan ana makine üzerinde çalıştı ve zamanla gelişerek hizmet kimlik bilgilerini kullanan bir kitaplığa dönüştü. ALTS kitaplığı, çekirdek RPC kitaplığına sorunsuz şekilde entegre edildi. Böylece geliştirme ekiplerine ciddi yük oluşturmadan geniş ölçekte benimsenmesi daha kolay hale geldi. ALTS'nin kullanıma sunulması, Hizmet Erişim Politikaları ve EUC biletlerinin kullanıma sunulması için ön koşuldu.

Geliştirme süreçlerimizi değiştirme

Google'ın sağlam bir derleme ve kod inceleme süreci benimsemesi çok önemliydi. Bu, hem çalıştırdığımız hizmetlerin bütünlüğünü hem de ALTS tarafından kullanılan kimliklerin anlamlı olmasını sağlamamıza imkan tanıdı. İki kullanıcılı kod incelemesi ve derleme ile dağıtım sırasında otomatik testler gibi gereksinimleri uygulamaya başlayabildiğimiz merkezi bir derleme süreci benimsedik. (Dağıtımla ilgili daha fazla ayrıntıyı Borg için İkili Program Yetkilendirmesi teknik belgesinde bulabilirsiniz.)

Temelleri oturtmamızın ardından, ortamlarımızda harici, güvenilmeyen kod çalıştırma ihtiyacına eğilmeye başladık. Bu amaç doğrultusunda, öncelikle ptrace ve ardından gVisor kullanarak korumalı alana alma işlemlerine başladık. Benzer şekilde, mavi-yeşil dağıtımlar hem güvenlik (ör. yama oluşturma) hem de güvenilirlik açısından ciddi avantajlar sağladı.

Bir sistemin politika ihlallerini engellemek yerine günlüğe kaydederek başlatılmasının çok daha kolay olduğunu hızlı bir şekilde keşfettik. Bu yaklaşımın iki açıdan avantajı oldu. Öncelikle, hizmet sahiplerine değişikliği test etme ve bulutta yerel ortama geçmenin hizmetleri üzerindeki etkisini (varsa) ölçme fırsatı sundu. Ayrıca, olası hataları düzeltmemizi ve hizmet ekiplerine sunmamız gerekebilecek ek işlevleri tanımlamamızı sağladı. Örneğin, bir hizmet BAB'ye katıldığında, hizmet sahipleri "yalnızca denetleme" modunu etkinleştirir. Bu, gereksinimlerini karşılamayan kod veya iş akışlarını tanımlamalarına yardımcı olur. Hizmet sahipleri, "yalnızca denetleme" modunda işaretlenen sorunları ele aldıktan sonra yaptırım moduna geçer. gVisor'da bunu öncelikle, korumalı alana alma özelliklerinde uyumluluk açıkları olsa bile, iş yüklerini korumalı alana alarak ve daha sonra korumalı alanı iyileştirmek için bu açıkları sistematik olarak ele alarak gerçekleştirdik.

Geçişin avantajları

BeyondCorp'un çevre tabanlı güvenlik modelinin ötesinde geliştirmeler sağlamamıza yardımcı olması gibi, BeyondProd da üretim güvenliği yaklaşımımızda benzer bir atılımı temsil etmektedir. BeyondProd yaklaşımı; hizmetler arasında güven varsayımında bulunmayan, iş yükleri arasında yalıtım sağlayan, yalnızca merkezi olarak derlenen uygulamaların dağıtımını onaylayan, güvenlik açığı yönetimini otomatikleştiren ve kritik öneme sahip veriler için güçlü erişim kontrollerini zorunlu kılan bulutta yerel bir güvenlik mimarisini tanımlar. BeyondProd mimarisi, Google'ın bu gereksinimleri karşılamak için çeşitli yeni sistemler geliştirmesinin önünü açmıştır.

Güvenlik çoğu kez en son ele alınır, bu sırada yeni bir mimariye geçiş kararı çoktan verilmiş olur. Güvenlik ekibinizin sürece baştan dahil edilmesi ve yeni güvenlik modelinin daha kolay yama yönetimi ve daha sıkı erişim denetimleri gibi avantajlarına odaklanılmasıyla, bulutta yerel mimari hem uygulama geliştirme hem de güvenlik ekiplerine ciddi avantajlar sağlayabilir. Bu makalede ele alınan güvenlik ilkelerini bulutta yerel altyapınıza uygulayarak, iş yüklerinizin dağıtımını, iş yüklerinizin iletişimlerinin güvenceye alınma ve diğer iş yüklerini etkileme şeklini güçlendirebilirsiniz.

Notlar

1 Borg, Google'ın iş yüklerini geniş ölçekte programlama ve çalıştırma amaçlı küme yönetimi sistemidir. Borg, Google'ın ilk birleştirilmiş container yönetimi sistemidir ve Kubernetes'in ilham kaynağıdır.

2 "Sola kayma" yazılım geliştirme yaşam döngüsünün erken adımlarına geçme anlamına gelir. Bunlar kod yazma, derleme, test, doğrulama ve dağıtım adımlarını içerebilir. Yaşam döngüsü diyagramları sıklıkla soldan sağa doğru çizildiğinden "sol" daha baştaki bir adım anlamına gelir.

3 Mavi-yeşil dağıtım, gelen trafiği etkilemeden bir değişikliği iş yükünde kullanıma sunma yöntemidir. Böylece son kullanıcılar uygulamaya erişirken herhangi bir kesinti yaşamaz.

4 Trafiğin Google altyapısı içinde GFE'den bir hizmete nasıl yönlendirildiğini daha iyi anlamak için Geçiş Halindeki Verilerin Şifrelenmesi teknik belgemizin Trafik nasıl yönlendirilir? bölümüne göz atın.

2 Borgmaster, Borg'un merkezileştirilmiş denetleyicisidir. İşlerin programlanmasını yönetir ve çalışan işlerle durumlarına göre iletişimler kurar.