Borg için İkili Program Yetkilendirmesi: Google'ın kod kaynağını doğrulama ve kod kimliğini uygulama yöntemi

Google, güvenlik ekibimizin güvenliği iyileştirmek amacıyla şirket içinde geliştirdiği BeyondCorp ve BeyondProd gibi projeleri açıklayan teknik belgeler hazırlamıştır. Google güvenliğine genel bir bakış için Güvenlik Altyapısı Tasarımı teknik belgemize göz atın.

Bu teknik belgede, Google'ın kod inceleme sürecini, kod kaynağını1 ve yaptırım mekanizmalarına olan ihtiyacı açıklıyoruz. Özel bir yaptırım denetimi olan Borg için İkili Program Yetkilendirmesi'nin (BAB) geliştirilmesine odaklanıyoruz. BAB'nin amacı, Google'da dağıtılan üretim yazılımlarının doğru şekilde incelenmesini ve yetkilendirilmesini (özellikle de kodun kullanıcı verilerine erişme yetkisi olduğunda) sağlayarak şirket içinde çalışanların oluşturduğu riskleri azaltmaktır. Tüm Google ürünlerinde, kullanıcı verilerinin korunmasına değer verir ve güvenlik önlemlerimiz konusunda mümkün olduğunca şeffaf olmaya çalışırız.

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 müşterilerimiz için sağladığımız korumayı sürekli olarak geliştirdiğimizden, güvenlik politikalarımız ve sistemlerimiz zaman içinde değişebilir.

CIO düzeyinde özet

  • Şirket içinde çalışanların oluşturduğu riskler, kullanıcı verilerinin güvenliği için bir tehdit oluşturur. Google'da, çalışanların kuruluşa dair bilgilerini kullanma veya kullanıcı verilerine yetkisiz erişim sağlama (yetkisiz bir iş yürütme dahil) olasılığını en aza indirmek için elimizden geleni yapmak istiyoruz.
  • Borg için İkili Program Yetkilendirmesi, yani BAB, Google'da dağıtılan üretim yazılımının ve yapılandırmanın düzgün bir şekilde incelenip yetkilendirilmesini (özellikle de kodun kullanıcı verilerine erişme yetkisi olduğunda) sağlayarak şirket içinde çalışanların oluşturduğu riskleri en aza indiren dahili bir dağıtım zamanında yaptırım denetimidir.
  • BAB, kod ve yapılandırma dağıtımlarının belirli minimum standartları karşılamasını sağlar.
  • BAB, yaptırımın yanı sıra yaptırım içermeyen denetim modunda da kullanılarak belirli gereksinimler karşılanmadığında uyarı verebilir.
  • BAB'nin benimsenmesi, Google'ın çalışanların oluşturduğu riskleri azaltmasına, olası saldırıları önlemesine ve Google üretim sistemlerinin tek tipliğini desteklemesine yardımcı olur.

Google'da çalışanların oluşturduğu riskleri en aza indirme

Güvenliğin birinci öncelik olduğu bir firma olarak, çalışanların oluşturduğu riski, yani Google personelinin (veya kuruluştaki diğer herhangi bir kişinin) şirkete dair bilgilerini veya erişimini kullanarak kötü amaçlı eylemlerde bulunması potansiyelini sınırlandırmak için önlemler aldık. Çalışanların oluşturduğu risk, bir saldırganın saldırısını kolaylaştırmak için Google'daki bir kişinin kimlik bilgilerini ele geçirdiği senaryoyu da kapsar. Çalışanların oluşturduğu riske karşı korunma alanında yenilikler yaratmak için ciddi ölçüde kaynak ayırdık. Google'da kullanıcı verilerinin güvenceye alınması çok önemlidir ve verileri kapsamlı şekilde korumak için çaba gösteririz. Hedefimiz, bir Google çalışanının kullanıcı verilerine yetkisiz erişimini önlemektir.

Kullanıcı verilerine erişim yetkilendirmesi

Google'da, bazen hizmetlerimizin ve personelimizin kullanıcı verilerine erişmesi gerekir. Verilerle aşağıdaki şekillerde etkileşime gireriz:

  1. Son kullanıcı olarak: Hizmeti kullanan bir çalışan, doğrudan hizmete kimlik doğrulaması yapar ve hizmet de kullanıcının kendi verilerini döndürür. Örneğin, Gmail hesabına giriş yapan bir kullanıcı kendi e-postalarını görür.
  2. Rol kapsamında: Google çalışanlarının yaptıkları işlerin büyük kısmı, anonimleştirilmiş kullanıcı verileri kullanılarak başarıyla tamamlanabilir. Ancak nadiren, personelimizin kullanıcı verilerine işleri gereği erişmeleri gerekir (ör. destek veya hata ayıklama için). Kullanıcı verilerine erişim konusunda mümkün olduğunca yüksek şeffaflık sağlamayı hedefliyoruz. Bunun için kullandığımız yöntemlerden birisi, Google Cloud müşterilerinin, verilerine yapılan erişimleri gerçek zamanlı günlükler aracılığıyla görüntüleyebilmelerini sağlayan Erişim Şeffaflığıdır.
  3. Bir hizmet kapsamında, programatik olarak: Bir hizmetin, bir görevi tamamlamak için geniş ölçekte programatik olarak kullanıcı verilerine erişmesi gerekebilir. Örneğin, bir veri ardışık düzeni, toplu kullanım istatistikleri oluşturabilmek için binlerce kullanıcının verilerini aynı anda sorgular. Bu tür bir ihtiyaç doğduğunda, tek tek kullanıcı verileri yerine bir veri kümesi için erişim sağlanır. Her bir kullanıcının verilerine erişim, günlüğe kaydedilmez.

Bu teknik belge, üçüncü senaryoda sunulan tehdit modeline odaklanır. Kullanıcı verilerine erişen sistemleri çalıştıran yöneticilerin, güçlerini kötüye kullanamayacağından emin olmak isteriz.

Tehdit modeli

Bu belgede ele aldığımız denetimler, tek taraflı erişimi önleyerek kullanıcı verilerini korumak için oluşturulmuştur. Tek başına hareket eden bir Google personelinin, uygun yetkilendirme veya gerekçe olmaksızın doğrudan ya da dolaylı olarak kullanıcı verilerine erişmesini veya verileri başka bir şekilde etkilemesini önlemek istiyoruz. Denetimlerimiz; işlemi yürüten kişinin kötü niyetli olmasından, hesap güvenliğinin ihlal edilmiş olmasından veya yetkinin istemeden verilmiş olmasından bağımsız bir şekilde bu işlemleri önlüyor.

Google'ın container mimarisine alınmış altyapısı

Altyapımız, Borg adı verilen bir küme yönetimi sistemi kullanılarak container mimarisine alınır. Her biri on binlerce makineye sahip birden fazla küme genelindeki birçok farklı uygulamada, yüz binlerce iş çalıştırırız. Bu geniş ölçeğe rağmen, üretim ortamımız oldukça homojendir. Bunun sonucunda, kullanıcı verilerine erişimle ilgili temas noktaları daha kolay kontrol edilebilir ve denetlenebilir.

Ayrıca, container'ları kullanarak ciddi güvenlik avantajları elde ederiz. Container'ların değişmez şekilde kullanılmaları amaçlanmıştır; bir görüntünün tamamen yeniden oluşturulmasıyla sık sık yeniden dağıtım yapılır. Bu özellik, bağlamdaki bir kod değişikliğini incelememize imkan tanır ve altyapımıza dağıtılan tüm değişiklikler için tek bir dar geçit noktası sağlar.

Bir hizmetin kullanıcı verilerine programatik erişimini sınırlandıran bir çözümü nasıl geliştirdiğimizi anlamak için öncelikle Google'da bir hizmetin üretime nasıl girdiğini anlamak önemlidir.

1. Adım: Kod incelemesi

Kaynak kodumuz, binlerce çalışanın kodu tek bir konuma kaydedebilmesini sağlayan monolitik merkezi depoda saklanır. Tek bir kod tabanı kullanmak, kaynak kod yönetimini basitleştirir, özellikle de üçüncü taraf kodlara olan bağımlılığımızı azaltır. Monolitik bir kod tabanı aynı zamanda kod incelemeleri için tek bir dar geçit noktasının zorunlu kılınmasını da sağlar. Google'da kod incelemelerimiz, kodu yazan kişi dışında en az bir mühendisin denetimini ve onayını içerir. Kod inceleme sürecimiz, herhangi bir sistemde yapılan kod değişikliklerinin en azından o sistemin sahipleri tarafından onaylanması kuralını zorunlu kılar. Kod kaydedildikten sonra derlenir.

Üçüncü taraf veya açık kaynaklı kodlardan değişiklikleri içe aktarırken, değişikliğin uygun olduğunu (ör. en son sürüm) doğrularız. Ancak kullandığımız üçüncü taraf veya açık kaynaklı kodlara şirket dışındaki geliştiricilerin uyguladığı her değişiklik için çoğu kez aynı inceleme kontrollerini uygulamayız.

2. Adım: Doğrulanabilir derlemeler

Kaynak kod oluşturup derleyerek dağıtım için ikili program sağlayan Bazel benzeri bir derleme sistemi kullanırız. Derleme sistemimiz, derlemeleri yürüten çalışanlardan ayrı, yalıtılmış ve kilitlenmiş bir ortamda çalışır. Her derleme için sistem bir doğrulanabilir derleme manifesti, yani derlemede kullanılan kaynakları, ikili programların veya diğer derleme yapılarının şifreli karmalarını ve tüm derleme parametrelerini detaylarıyla açıklayan imzalı bir sertifika üretir. Bu manifest, bir ikili programı, oluşturulmasında kullanılan kaynak koda kadar ve dolayısıyla tanımladığı kaynak kodun oluşturulma ve gönderilme sürecine kadar izleyebilmemizi sağlar. Ek olarak, dosyada yapılan herhangi bir değişikliğin, imzayı otomatik olarak geçersiz kılacak olması nedeniyle manifest bize ikili programın değiştirilmediğini doğrulama imkanı da sunar.

Derleme işlemleri teorik olarak rastgele kodlardan oluşabilir. Bu nedenle derleme sistemimiz çok kiracılı yapı için sağlamlaştırılmış durumdadır. Başka bir deyişle, derleme sistemimiz bir derlemenin diğer derlemeleri etkilemesini önleyecek şekilde tasarlanmıştır. Sistem; derlemelerin, doğrulanabilir derleme manifestlerinin veya sistemin kendisinin bütünlüğünü ihlal edebilecek değişiklikler yapmasını önler. Derleme tamamlandığında, değişiklik Borg kullanılarak dağıtılır.

3. Adım: Dağıtım işleri

İkili programlar, derlendikten sonra container mimarisine alınmış altyapımızda Borg işi olarak dağıtılabilir. Bu işler, ikili programlar veya veriler içerebilen ve kurulumu Borg tarafından yönetilen paketler kullanır. Borg yapılandırması; işin dağıtılması için paketler, çalışma zamanı parametreleri, bağımsız değişkenler ve işaretler gibi gereksinimleri belirler. Borg; kısıtlamaları, önceliği, kotayı ve yapılandırmada listelenen diğer gereksinimleri dikkate alarak işi planlar. Borg işi, dağıtımdan sonra üretimdeki diğer işlerle etkileşime girebilir.

4. Adım: İş kimliği

Borg işleri kimlik olarak çalışır. Veri depolarına veya diğer hizmetlerin uzak prosedür çağrısı (RPC) yöntemlerine erişmek için bu kimlik kullanılır. Bir kimlik, rol hesabı (ör. bir hizmet) veya kullanıcı hesabı (ör. bir çalışanın kişisel hesabı) olabilir. Birden fazla iş aynı kimlikle çalışabilir. Belirli bir kimliğe sahip işleri dağıtma veya değiştirme yetkisini, yalnızca hizmeti çalıştırmakla sorumlu kişilere tanırız. Bu kişiler genellikle Site Güvenirliği Mühendislerimiz (SRE'ler) olur.

Borg bir iş başlattığında, işin temel hazırlığını şifreli kimlik bilgileriyle yapar. İş, bu kimlik bilgilerini diğer hizmetlerin isteklerini yürütürken kimliğini doğrulamak amacıyla kullanır (Uygulama Katmanı Aktarım Güvenliği kullanarak). Bir hizmetin belirli verilere veya başka bir hizmete erişmesi için hizmet kimliği mutlaka gerekli izinlere sahip olmalıdır. Google Cloud'daki Cloud Data Loss Prevention (Cloud DLP) API gibi bir hizmet örneğini düşünün. DLP API'nin tarama amacıyla verilere erişmesi için iki şeye ihtiyacı vardır: Öncelikle, DLP API belirli bir kimlikle çalışacak şekilde yapılandırılmalıdır. Bu durumda, birlikte çalışacağı kimlik bir rol hesabıdır. İkinci olarak, DLP API'nin taradığı verilerle ilgili izinler, bu rol hesabını içermelidir. Hizmet, geçerli bir kimlik ve doğru izinler olmadan tarama işlemini yürütemez.

Politikalarımız, kullanıcı verilerine (veya diğer hassas bilgilere) erişimi olan herhangi bir rol hesabının BAB ve diğer güvenlik sistemleri tarafından sıkı şekilde denetlenmesini gerektirir. Kalite güvencesi işlemlerinin ve hassas veri veya kaynaklara erişimi olmayan geliştirme işlerinin daha az denetimle çalışmasına izin verilir.

Tüm unsurların birleşimi: Bir işin ömrü

Özetle, altyapımızda iş çalıştırma adımları şöyledir:

  1. Bir Google geliştiricisi, kod değişikliğini yazar. Daha sonra bunu inceleme için bir veya daha fazla Google mühendisine gönderir. İnceleme işlemi, uygun kimlik doğrulaması ve günlük kaydı denetimlerini içerir. Onaylandıktan sonra kod kaydedilir.
  2. Geliştirici tarafından tetiklenen derleme sistemi, ikili programları korumalı alana alınmış bir ortamda doğrulanabilir şekilde derler ve paketler. Bu derleme işlemi, derleme sisteminin kimlik doğrulama amacıyla imzaladığı bir paket oluşturur.
  3. İş, uygun güvenli kimlik altında çalışan işleri yönetmek için özel yetkiye sahip bir mühendis tarafından Borg üzerinde dağıtılır.
  4. Bir Borg işi, kullanıcı verileri gibi ayrıcalıklı kaynaklara erişmeye çalıştığında işin kimliği yetkilendirme için doğrulanır.

Artık işlerin üretim ortamımızda nasıl çalıştığını biliyorsunuz. Şimdi de BAB'nin ele aldığı tehdit modelini inceleyelim. Bu modelde, potansiyel olarak kötü amaçlı bir çalışanın yetkilendirilmemiş bir iş çalıştırması önlenir. BAB, bunu başarmak için bir ikili program dağıtılmadan önce gerekli tüm güvenlik denetimlerinin gerçekleştirildiğini doğrular.

Bu bölümde, container mimarisine alınmış altyapımıza genel bir bakış sunduk. Üretim ortamımıza dair temel bir kavrayışa sahip olmak, verilere programatik kullanıcı erişimiyle ilgili denetimlerimizi anlamanız için ön koşul niteliğindedir. Sonraki bölümde bu denetimler daha ayrıntılı şekilde açıklanmıştır.

Borg için İkili Program Yetkilendirmesi (BAB)

Yıllardır, kullanıcı verilerine manuel olarak erişilmesini önlemek için ciddi çalışmalar yürütmekteyiz. Bu çalışmalar arasında, Google çalışanlarının işlerini yapmak için ihtiyaç duydukları veri ve iş yönetimi erişimini sınırlandırmak da yer alır.

BAB'nin misyonu, Google'da dağıtılan tüm üretim yazılımları ve yapılandırmalarının doğru şekilde incelenmesini ve yetkilendirilmesini (özellikle de kodun kullanıcı verilerine erişme yetkisi olduğunda) sağlamaktır. Bu misyon doğrultusunda BAB, yetkisiz işlerin başlatılmasını önlemek amacıyla dağıtım zamanında yaptırım hizmetinin yanı sıra BAB'nin etkinleştirildiği işlerde kullanılan kod ve yapılandırmanın denetim takibini sağlar.

Doğrulama

BAB, ikili programların dağıtılırken belirli gereksinimleri karşıladıklarını doğrular. Örneğin, bir hizmet sahibi, hizmeti için kullanılan ikili programın incelenen, kaydedilen, test edilen ve yetkilendirilen kod ile derlenmesini zorunlu kılabilir. Bu tür denetimleri dağıtım zamanı denetimleri olarak adlandırırız. BAB ayrıca bir ikili program dağıtıldıktan sonra da denetimler yürütebilir. Bunlara dağıtım sonrası denetimleri adını veririz. Dağıtım sonrası doğrulamalarıyla ilgili daha fazla bilgi için Yaptırım modları bölümümüze göz atın.

Kod değişiklikleri, yeni bir ikili program yaratır. Yeni ikili programdaki değişikliklerin geçerli olması için ikili programın dağıtılması gerekir. BAB, dağıtım zamanında birçok türde denetime imkan tanır. Bu denetimlerden bazıları şöyledir:

  • İkili program, kaydedilen kodla derlenmiş mi?

    Kod, Google'ın kaynak kod deposuna gönderilmiş ve kaydedilmiş mi? Kodun gönderilmesi için genellikle ikinci bir Google mühendisi tarafından incelenmesi gerekir.

  • İkili program, doğrulanabilir şekilde derlenmiş mi?

    Bu ikili program, denetlenebilir kaynaklara kadar geriye doğru izlenebilir mi? Onaylı bir derleme sistemiyle derlenmiş mi?

  • İkili program, test edilmiş kodla derlenmiş mi?

    İkili program, test gereksinimlerini karşılıyor mu?

  • Koddan derlenen ikili programın dağıtımda kullanılması mı amaçlanıyor?

    Kod, kaynak kod depomuzun bu Borg işiyle ilgili proje veya ekibe karşılık gelen uygun bölümüne gönderilmiş mi?

Bunlar üretim ortamımıza özgü olsa da güvenlik, uyum veya güvenilirlik gereksinimlerinize bağlı olarak CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) ortamlarınızda da benzer gereksinimler zorunlu kılınabilir.

Hizmete özgü politikalar

Hassas verilere erişen işler, geçerli ticari nedenler için bazı istisnalar dışında genellikle kod gönderilmesini gerektirir. Hassas veriler arasında kullanıcı verileri, istihdam ve finans verileri ile özel veriler veya iş verileri gibi diğer gizli bilgiler yer alır. Google'daki tüm işlerin bir politikaya sahip olması gerekir. Kullanıcı verilerine erişim gerektirmeyen bir Borg işinin bile tanımlı bir politikası olur ancak listelenen belirli bir gereksinim olmaz.

Hizmet sahipleri BAB'yi kullanmaya başladıklarında, hizmetleriyle ilgili güvenlik gereksinimlerini içeren bir politika tanımlar. Hizmetin uygulanmasında kullanılan tüm rol hesapları, bir BAB politikası belirtmelidir. Her bir rol hesabı için BAB Politikası, kullanıma sunulması amaçlanan işleri, işin kodunu ve yapılandırma gereksinimlerini tanımlar. Bir politikanın tanımlanması veya değiştirilmesi de incelenmesi gereken bir kod değişikliğidir.

BAB Politikasında zorunlu kılınabilecek gereksinimler şunları içerir:

  • Kodun doğrulanabilir şekilde derlenmiş olması: Doğrulanabilir şekilde derlenen kodlar denetlenebilir özelliktedir. Ancak bu, kodun incelemeden geçtiği anlamına gelmez. Kodun gönderilmediği durumlar bile vardır. Doğrulanabilir derlemelerde kullanılan kodlar, gönderilmemiş olsa bile en az 18 ay süreyle denetlenebilir.

  • Kodun gönderilmiş olması: Kod, kaynak depomuzdaki özel ve amaçlanan bir konumdan derlenmiştir. Bu, genellikle kodun incelemeden geçmiş olduğu anlamına gelir.

  • Yapılandırmaların gönderilmiş olması: Dağıtım sırasında sağlanan tüm yapılandırmalar, normal kod ile aynı inceleme ve gönderim sürecinden geçer. Sonuç olarak, komut satırı işaret değerleri, bağımsız değişkenler ve parametreler inceleme yapılmadan değiştirilemez.

BAB uygulayan sistemlerin ve bileşenlerin sıkı şekilde denetlenmesi gerekir. Bu da olası en katı gereksinimlerin ve ek manuel denetimlerin uygulanmasıyla sağlanır.

Yaptırım modları

BAB, Borg işi tarafından belirlenen politikaya göre farklı işlemler yürütür. Yaptırım modu adını verdiğimiz bu işlemler üç türlüdür: Dağıtım zamanında yaptırım, dağıtım zamanında denetim ve sürekli doğrulama. Bir politika tanımlanırken hizmet sahibi, dağıtım zamanında yaptırım veya dağıtım zamanında denetim modlarından birini seçmelidir. Sürekli doğrulama modu varsayılan olarak etkindir. Aşağıdaki bölümlerde her bir mod hakkında ayrıntılı bilgi verilmektedir.

Dağıtım zamanında yaptırım modu

Yeni bir iş gönderildiğinde, Borgmaster2 işin BAB Politikasında belirtilen gereksinimleri karşıladığını doğrulamak için BAB'ye danışır. Bu denetim, bir kabul denetleyicisi görevi görür. Gereksinimler karşılanıyorsa Borgmaster işi başlatır. Gereksinimler karşılanmıyorsa istekte bulunan kullanıcı bunu gerçekleştirebilecek yetkiye sahip olsa bile Borgmaster isteği reddeder.

Yaptırım modunda, Borg işi için BAB Politikasında belirtilen gereksinimler karşılanmıyorsa BAB, Borg işinin dağıtımını engeller. BAB'de yeni olan hizmetler genellikle denetim modunda (sonraki bölümde açıklanmıştır) başlar ve daha sonra yaptırım moduna geçer.

Acil müdahale prosedürleri

Bir olay veya kesinti durumunda önceliğimiz, etkilenen hizmeti mümkün olan en kısa sürede eski durumuna getirmektir. Acil bir durumda, incelenmemiş veya kaydedilmemiş kodların çalıştırılması gerekebilir. Bunun sonucunda, acil müdahale işareti kullanılarak yaptırım modu geçersiz kılınabilir. Acil müdahale prosedürleri, BAB'nin normalde bir dağıtımı engelleyeceği durumda BAB'de hata yaşanması halinde yedek görevi de görür. Acil müdahale prosedürünü kullanarak iş dağıtan bir geliştirici, yaptığı istek kapsamında bir gerekçe de göndermelidir.

Acil müdahale prosedürünün kullanılmasından sonra birkaç saniye içinde BAB, ilişkili Borg işi hakkındaki ayrıntıları günlüğe kaydeder. Günlükte, kullanılan kod ve kullanıcı tarafından sağlanan gerekçe bulunur. Birkaç saniye sonra, merkezi güvenlik ekibimize bir denetim takibi gönderilir. Denetim takibi, birkaç saat içinde rol hesabına sahip olan ekibe gönderilir. Acil müdahale prosedürleri yalnızca son çare olarak kullanılması için tasarlanmıştır.

Dağıtım zamanında denetim modu

Denetim modunda, bir Borg işi için politika gereksinimleri karşılanmıyorsa BAB bunu günlüğe kaydeder ancak işin dağıtımını engellemez. Bu politika ihlali, rol hesabına sahip olan ekibe uyarı gönderilmesini tetikler.

Google'da, kullanıcı verilerine erişen hizmetler gibi belirli hizmetlerin yaptırım modunu kullanmasını zorunlu kılarız. Tüm hizmet sahiplerini yaptırım modunu kullanmaya teşvik eder ve denetim modunu yalnızca yeni bir hizmeti başlatırken kullanmalarını öneririz. Denetim modunu kullanmak isteyen hizmet sahipleri, istisna alabilmek için bir gerekçe sunmalıdır. Örneğin, güvenilirlik SLO'su (Hizmet Düzeyi Hedefi) BAB'nin sunduğundan çok daha yüksek olan bir hizmet, denetim modunu kullanabilir.

Denetim modu, başlangıç politikasına ince ayarlamalar yapmak için kullanışlı olsa da çoğu hizmet için pratik bir sabit durum değildir. Denetim modunu kullanırken, politika ihlalinin üzerinden birkaç saat geçmeden hizmet sahibi bir ihlal olduğu konusunda bilgilendirilmez. Bu da karmaşık bir bildirim akışına yol açarak gerçek güvenlik sorunlarının hizmet sahibi tarafından yaratılan hatalar veya politika yapılandırma yanlışlarıyla gizlenmesine neden olabilir. Yaptırım modunda hizmet sahibi, politikalarla uyumlu olmayan bir işi başlatmaya çalıştığında derhal geri bildirim alır. Bunun sonucunda bildirim akışı çok daha düzenli olur. Ayrıca BAB yaptırım modu, bir işin çalışmak için tasarlandığı rol yerine yanlışlıkla başka bir rolle başlatılması gibi istenmeyen hataları yakalar.

Sürekli doğrulama

Bir iş dağıtıldığında, dağıtım sırasındaki yaptırımdan bağımsız olarak kullanım ömrü boyunca sürekli olarak doğrulanır. Bir BAB işlemi günde en az bir kez çalışarak; başlatılan (ve hala çalışmakta olabilecek) işlerin, politikalarındaki olası güncellemelere uyum sağlayıp sağlamadığını kontrol eder. Örneğin, sürekli doğrulama modu, güncel olmayan politikalarla veya acil müdahale prosedürleri kullanılarak dağıtılan bir kimlikle çalışan işler olup olmadığını sürekli olarak kontrol eder. Güncellenen politikaya uyum sağlamayan bir iş bulunursa BAB, hizmet sahiplerine riski azaltabilmeleri için bildirim gönderir.

Küresel olarak izin verilen paketler

Google'da, hizmetlerimizin çoğu tarafından yaygın şekilde kullanılan bazı paketler bulunur. Her bir hizmeti kendi sürümünün bakımını yapmaya zorlamaktansa bu paketlere merkezi olarak izin verilir. Bunlara küresel olarak yönetilen paketler adı verilir. Bir hizmet sahibi, BAB Politikasını yazarken belirli bir iş için küresel olarak izin verilen paket belirtebilir. Yaygın kullanılan paketler için ayrıca küresel bir varsayılan mekanizma bulunur. Böylece her bir hizmetin politikası kapsamında ayrı ayrı listelenmeleri gerekmez. Bu da Google'ın kuruluş genelinde yaygın kullanılan sistem bileşenleri üzerinde açık bir denetim sürdürmesine imkan tanır ve bileşenlerin ekiplerin müdahalesi olmadan doğru şekilde incelenmesini ve güncellenmesini sağlar. Bir hizmetin sahibi, hizmetin BAB Politikası kapsamında bu paketlere açık şekilde izin verebilse de, sahiplerin önerilen ve desteklenen yolu kullanmaları kolaylaşır.

Sıra dışı durumlar

Google, üretimde dağıtılan kodlar için kod incelemeleri ve doğrulanabilir derlemeler gibi güçlü güvenlik denetimleri uygular. BAB, bu güvenlik denetimlerinin uygun şekilde benimsendiğinden emin olmak için ek bir denetim ve yaptırım noktası görevi görür.

Ancak BAB her durumda etkili şekilde kullanılamaz. BAB aşağıdaki sıra dışı durumları desteklemez: standart olmayan derleme sistemleriyle derlenen kodlar, Borg dışındaki ortamlarda dağıtılan kodlar ve nihai üretim parametreleri seçilmeden önce gerçek kişiler tarafından incelenmeye uygun olmayan veri analizi ve makine öğrenimi kodları. Bu durumlarda, diğer kod kaynağı doğrulama sistemleri dahil bir dizi güvenlik önlemleri bulunur. Bu kodlar yine de Google'ın genel güvenlik denetimlerine tabidir.

Borg için İkili Program Yetkilendirmesini uygulama

BAB ekibi, BAB'nin uygulanması için acil müdahale prosedürleri ve denetim modu dahil, bir dizi yeni özellik geliştirmiştir. Bu araçlar, hizmet sahiplerinin BAB'yi kendi başlarına denemelerini mümkün olduğunca kolaylaştırmıştır. Kuruluşunuzda BAB gibi bir sistem dağıtmayı düşünüyorsanız bu geçişi kolaylaştırmak için ek çalışmalara ihtiyaç duyabilirsiniz. Bu bölümde, uygulama planımız kapsamında bizim yürüttüğümüz kuruluş ve değişiklik yönetimi çalışmaları açıklanmaktadır.

Avantajlar

BAB, Google'da geliştirilmesi ve benimsenmesi için işletme örneği oluşturulmasına yardımcı olan üç avantaja sahiptir: çalışanların oluşturduğu risklerin azaltılması, sağlam kod kimliği ve basitleştirilmiş uyum.

Çalışanların oluşturduğu risklerin azaltılması

BAB, temel olarak herhangi bir kişinin kullanıcı verilerine yetkilendirilmemiş programatik erişim elde etmesini önlemek amacıyla geliştirilmiştir. BAB, bir mühendisin kimlik bilgilerini ele geçiren bir saldırganın veya bir mühendisin, hassas verilere uygunsuz şekilde ve fark edilmeden erişim sağlamasını zorlaştırır.

Sağlam kod kimliği

Container mimarisine alınmış altyapı bölümünde açıklandığı gibi, Borg işleri bir kimlik (genellikle bir rol hesabı) olarak çalışır. Bu kimlik, diğer hizmetler tarafından herhangi bir veriye erişim vermeden önce uygun yetkilendirmeyi doğrulamak amacıyla kullanılır. Ancak diğer hizmetler bu verilerin nasıl kullanılacağıyla ilgili bir yaptırım uygulayamaz; bu nedenle iş kimliğinin, aldığı verileri kötüye kullanmadığına güvenmesi gerekir. BAB, bir işin kimliğini belirli bir koda bağlar ve böylece iş kimliğinin ayrıcalıklarını yürütmek için yalnızca belirtilen kodun kullanılabilmesini sağlar. Bu da, iş kimliğinden (bir kimliğe ve ayrıcalıklı tüm gerçek kullanıcılarına geçişli olarak güvenme) kod kimliğine (belirli bir anlama sahip olmasına göre incelenen ve onay süreçleri olmadan değiştirilemeyen belirli bir kod parçasına güvenme) geçişe imkan tanır.

Basitleştirilmiş uyum

BAB, önceden manuel olarak yürütülen uyum görevlerini basitleştirmiştir. Google'daki belirli süreçler, verileri ele alma şekilleriyle ilgili daha sıkı denetimler gerektirir. Örneğin, finansal raporlama sistemimizin Sarbanes-Oxley Yasası (SOX) ile uyumlu olması gerekir. BAB'den önce, uyumluluğumuzu sağlamak için doğrulamaları manuel olarak yürütmemize yardımcı olan bir sistemimiz bulunmaktaydı. BAB'den sonra, bu denetimlerin çoğu, hizmetlerin BAB Politikaları temel alınarak otomatikleştirildi. Bu denetimlerin otomatikleştirilmesi, uyum ekibinin hem dahil edilen hizmetlerin kapsamını hem de bu hizmetlerle ilgili uygun denetimlerin benimsenme kapsamını genişletmesini mümkün kıldı.

Bir hizmetin kullanıma başlaması

BAB ekibinin, kullanıma başlama sürecinin basit ve anlaşılır olmasını sağlaması gerekiyordu. Başlangıçta, Google'daki hizmet sahiplerinin BAB'yi benimsemekle ilgili iki temel endişesi vardı:

  • BAB'nin yeterince güvenilir olmaması, kritik durumlarda uygulanmasını engelleyebilirdi.
  • BAB, sık yürütülen kod kayıtları ve yinelemeli işlemlerle bir hizmetin geliştirilmesini yavaşlatabilirdi.

BAB ekibi, bu ilk endişeleri ele almak için denetim modunu geliştirdi. BAB ekibi bu modu kullanarak, sistemin bazı temel ilk kullanıcılarına BAB'nin işe yaradığını kanıtlayabildi. BAB ekibi, güvenilirliği daha yüksek düzeyde uygulayabilmek için bir kullanılabilirlik SLO'su geliştirdi ve yaptırım modu için acil müdahale prosedürlerini tanıttı.

Mevcut bir hizmet BAB'yi kullanmaya başlarken, hizmet sahibi genelde öncelikle yalnızca denetim modunu etkinleştirir. Böylece, yaptırım modunu etkinleştirmeden önce olası sorunları tespit edebilir ve ele alabilir. Üretimde BAB kullanan herhangi bir iş için varsayılan politika, yaptırım modudur. Hizmet sahibi, işi dağıtmak için en azından kodun gönderilmesini ve doğrulanabilir şekilde derlenmiş olmasını gerektiren bir politika göndermelidir. Bir hizmet sahibi, bu minimum standardı karşılamadan da işini dağıtabilir ancak bunun için kendisine bir istisna verilmesi gerekir. Hizmetin daha hassas verilere ve/veya hizmetlere erişmesi gerekiyorsa hizmet sahibi daha sıkı gereksinimlere geçebilir. Başlangıç politikası tanımlamak zor olabilir; bu nedenle BAB ekibi hizmet sahiplerinin kendi politikalarını yazmalarına yardımcı olan otomatik araçlar oluşturmuştur. Bu araçlar, mevcut bir iş için kaynak deposunun hangi kısımlarının kullanıldığına bakarak uygun bir politika önerir.

Yeni bir hizmet BAB'yi kullanmaya başlarken, hizmet sahibi başlangıçtan itibaren yaptırım modunu etkinleştirir. Hizmet sahibi bir başlangıç politikası taslağı hazırlar ve ek gereksinimler eklemek için hızla yinelemeler yapar. Politikalar da kod değişiklikleri olarak yönetilir ve bu nedenle, güncellemelerin incelenmesi için ikinci bir Google mühendisine ihtiyaç duyar.

Etki

BAB ve container mimarisine alınmış bir dağıtım modelini benimsemek, Google'a güvenlik ve destek açısından birçok avantaj sağlar:

  • BAB, çalışanların oluşturduğu riskleri azaltmaya yardımcı olur: BAB, kodların kullanıcı verilerine erişmeden önce belirli standartlara ve değişiklik yönetimi uygulamalarına uymasını gerektirerek, tek başına hareket eden (veya hesabı ele geçirilen) bir Google çalışanının kullanıcı verilerine programatik olarak erişme olasılığını azaltır.
  • BAB, üretim sistemlerinin tek tip olmasını destekler: Container mimarisine alınmış sistemlerin kullanılması ve dağıtımdan önce bunların BAB gereksinimlerinin doğrulanması sayesinde, sistemlerimizde hata ayıklamak daha kolay hale gelir, sistemlerimiz daha güvenilir ve daha net değişiklik yönetimine sahip olur. BAB gereksinimleri, üretim sistemi gereksinimleri için ortak bir dil sağlar.
  • BAB, veri koruma için ortak bir dil belirler: BAB, uygunluğu sistemlerimiz genelinde izler. Bu uygunlukla ilgili veriler dahili olarak paylaşılır ve diğer ekipler tarafından sorgulanabilir. BAB verilerinin bu şekilde paylaşılması, ekiplerin veri koruma ile ilgili olarak birbirleriyle iletişim kurarken ortak terimler kullanabilmelerini sağlar. Bu ortak dil, ekipler genelinde verilerle çalışırken ihtiyaç duyulan karşılıklı haberleşmeleri azaltır.
  • BAB, uyum gereksinimlerinin programatik olarak izlenmesine imkan tanır: Finansal raporlama gibi bazı belirli süreçlerin, uyum için belirli değişiklik yönetimi gereksinimlerini karşılaması gerekir. BAB kullanıldığında bu denetimler otomatikleştirilerek zamandan tasarruf sağlanabilir ve kapsam genişletilebilir.

BAB, Google'da çalışanların oluşturduğu riskin azaltılması için kullanılan çeşitli teknolojilerden biridir.

Benzer denetimleri kuruluşunuzda benimseme

Google'da BAB'yi benimserken birçok önemli ders çıkardık. Böylesi büyük bir değişikliği gerçekleştirmek, korkutucu bir görev gibi görünebilir. Bu bölümde, sizin de BAB ilkelerini kendi kuruluşunuza uygulayabileceğinizi umarak bu süreçte öğrendiklerimizi paylaşacağız.

Daha homojen, container mimarisine alınmış bir CI/CD ardışık düzeni için çalışın.

Google'da BAB'nin benimsenmesi, kod geliştirmede kullandığımız araçların tutarlılığı ve entegrasyonu sayesinde mümkün olmuştur. Bu çalışmaların kapsamı içinde kod incelemeleri, doğrulanabilir derlemeler, container mimarisine alınmış dağıtımlar ve erişim kontrolü için hizmet tabanlı kimlik yer almaktaydı. Doğrulanabilir derlemeler, ikili programlarınızın nasıl derlendiğini denetlemenize imkan tanır; container'lar da ikili programları verilerden ayırmanıza imkan tanır ve bunların kullanım gereksinimlerini karşılamasını sağlamak amacıyla size bir yaptırım dar geçit noktası sunar. Bu yaklaşım, BAB'nin benimsenmesini kolaylaştırmış ve BAB gibi bir çözümün sunabileceği garantileri güçlendirmiştir.

Mikro hizmetlerin kullanıma sunulması, ana makine tabanlı kimlik (ör. IP adresi) yerine hizmet tabanlı kimliğin (ör. hizmet hesabı) benimsenmesine imkan tanımıştır. Hizmet tabanlı kimliğe geçiş, hizmetler arasında kimlik doğrulama ve yetkilendirmeyi yönetme biçiminizi değiştirebilmenizi sağlar. Örneğin, kimliği onaylamak için bir container görüntüsüne dahil edilmiş kimlik jetonu kullanıyorsanız kod kaynağı ile sağlanan garantiler çok güçlü olmayacaktır. Hizmet kimliğini doğrudan benimseyemiyorsanız ara bir adım olarak kimlik jetonlarını daha güçlü şekilde korumayı deneyebilirsiniz.

Hedeflerinizi belirleyin ve politikalarınızı gereksinimlerinize göre tanımlayın.

Politika odaklı kullanıma sunma sürecinizi adım adım oluşturun. Bazı değişiklikleri, CI/CD ardışık düzeninizde diğerlerinden daha erken uygulamanız gerekebilir. Örneğin, resmi kod incelemelerini dağıtım sırasında zorunlu kılmadan önce yürütmeye başlamanız gerekebilir.

Uyum, politika odaklı bir kullanıma sunma süreci için mükemmel bir motivasyon aracıdır. Bir politikada uyum gereksinimlerinizden en azından bazılarını kodlayabilirseniz testlerinizi otomatikleştirebilir ve bunların daima etkin olmasını sağlayabilirsiniz. Temel gereksinimlerle başlayın ve ilerledikçe daha gelişmiş gereksinimler kodlayın.

Politikaları, geliştirme sürecinin başlarında zorunlu kılın.

Bir yazılımla ilgili kapsamlı politikaları, yazılımın nerede çalışacağını ve ne tür verilere erişeceğini önceden bilmeden tanımlamak zordur. Bu nedenle, BAB Politikası yaptırımı, kod derlendiğinde değil, dağıtıldığında ve verilere eriştiğinde yürütülür. BAB Politikası, çalışma zamanı kimliği açısından tanımlandığı için aynı kod farklı ortamlarda çalışabilir ve farklı politikalara tabi olabilir.

BAB'yi kullanıcı verilerine erişimin sınırlandırılması amacıyla diğer erişim mekanizmalarına ek olarak kullanırız. BAB'nin bu şekilde kullanılmasıyla, hizmet sahipleri kodu kimlik olarak kabul eder ve verilere yalnızca belirli BAB gereksinimlerini karşılayan işlerin erişebilmesini garantileyebilir.

Mevcut hizmet sahiplerinin kullanıma nasıl başlayacağını belirleyin.

Yaptırımlardan hemen avantaj elde edecek ve geri bildirim sağlamaya istekli birkaç hizmet sahibi belirleyin. Bunun bir yolu, herhangi bir değişikliği zorunlu kılmadan önce hizmet sahiplerine kimlerin gönüllü olmak isteyeceğini sormaktır.

Mümkünse yaptırım modunu, denetim modundan önce zorunlu kılın veya denetim modu için ek yayınlama süresini kısıtlayarak zorunluk getirin. Denetim modu, hizmet sahiplerinin kullanıma hızlı şekilde başlamasını ve çalışanların oluşturduğu riskleri daha iyi anlamasını sağlar. Denetim modunun dezavantajı, çalışanların oluşturduğu risklerde somut bir azalma görmenin zaman alabilecek olmasıdır. Bu gecikme, değerin görülmesini ve diğerlerini yaptırımı benimsemeye ikna etmeyi zorlaştırabilir. BAB ekibi yaptırım için acil müdahale prosedürleri sağladığında hizmet sahipleri, gerektiğinde bir kaçış yolu olacağı için yaptırımı benimsemeye daha istekli olmuştur.

Ekipler genelinde değişiklik aracıları görevlendirin.

BAB dağıtımı için Google genelinde bir talimat oluşturduğumuzda, başarı oranımızı en çok etkileyen unsur, her bir ürün grubunda değişikliği yürütecek hizmet sahipleri bulmak oldu. Onların yardımını aldıktan sonra, devam etmekte olan değişiklikleri izleyecek resmi bir değişiklik yönetimi ekibi oluşturduk. Daha sonra, her bir ürün ekibinde değişiklikleri uygulayacak sorumlu hizmet sahipleri belirledik.

Üçüncü taraf kodları nasıl yöneteceğinizi belirleyin.

Bu makalede tanımladığımız CI/CD denetimlerinin çoğu; kodunuzun tek bir kuruluş tarafından geliştirildiği, incelendiği ve yönetildiği duruma yöneliktir. Bu durumdaysanız politika gereksinimleriniz kapsamına üçüncü taraf kodları nasıl dahil edeceğinizi değerlendirin. Örneğin, kullanılan tüm üçüncü taraf kodların deposunu tuttuğunuz ve bu kodu güvenlik gereksinimlerinize karşı düzenli olarak değerlendirdiğiniz ideal duruma yavaş yavaş geçerken, başlangıçta kodu muaf tutabilirsiniz.

Sonuç

Google'ın container mimarisine alınmış altyapısı ve CI/CD süreci kapsamında dağıtım zamanı yaptırım denetimini benimsemek, dağıttığımız kod ve yapılandırmanın güvenlik için belirli minimum standartlara uygun olduğunu doğrulamamızı sağladı. Bu, potansiyel olarak kötü amaçlı olabilecek bir çalışanın, kullanıcı verilerine erişebilecek yetkisiz bir iş çalıştırabilmesini sınırlandıran önemli bir denetimdir. BAB'nin benimsenmesi, Google'ın çalışanların oluşturduğu riski azaltmasına, olası saldırıları önlemesine ve üretim sistemlerimizin tek tipliğini desteklemesine imkan tanımıştır.

Diğer referanslar

Google'ın genel güvenliği ve container mimarisine alınmış altyapısı hakkında daha fazla bilgi için şu kaynakları inceleyebilirsiniz:

Notlar

1 Kaynak; bileşenleri, bileşenler üzerinde yapılan değişiklikleri ve bunların kökenini ifade eder. Bkz. https://csrc.nist.gov/glossary/term/Provenance.

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