Google Bulut Platformu Güvenlik Esasları

6 min readDec 6, 2021

Google Bulut Platformunda Güvenliğin Önemi.

Google, platformunu güvenli bir hale getirmek için büyük adımlar atmıştır. Bununla birlikte son kullanıcının (yani siz) kendi kaynaklarını güvenlik altına alması gerekmektedir. Buna birçok bulut platformunda olduğu gibi paylaşılan sorumluluk modeli adı verilmektedir.

Burada işleyeceğimiz bazı konulara değinirsek:

- Temel güvenlik ve erişim konseptleri
- Kimlik ve Erişim Yönetimi
- Ağ altyapısını güvence altına almak (Vpc ve Güvenlik Duvarı)
- Compute Engine işletim sistemlerinin güvence altına alınması
- Veri depolama erişimini güvence altına almak
- GCP çevresinin izlenmesi ve loglanması
- Şifreleme teknikleri

vb gibi konular olacaktır. GCP konsoluna temel düzeyde bir hakimiyet ve GCE instance’larına erişme ve silme gibi konuları bilmek yararımıza olacaktır.

GCP Kaynak Hiyerarşisi

Google’ın bulut platform hiyerarşisine bir göz atarsak onu bir Linux işletim sistemi dizin yapısına benzetebiliriz. Bildiğiniz gibi Linux dosya sisteminde Root en tepede bulunur. Onun altında ise diğer dizinler ve alt dosyalar yer alır. Google Cloud’da buna benzer biçimde parent-child ilişkisi ile çalışır. Root kısmını Organizasyonun kendisi temsil eder. (ornek.com gibi) Projeler birincil dizinlerde yer alır. (dev, test, prod gibi) Kaynaklar ie projelerin alt dosyalarında yer almaktadır. Compute engine, app engine, cloud storage, cloud pub/sub vb gibi bir çok öğe bu alt dizinlerde yar alır.

Seviyeler/Katmanlar

Organizasyon (Şirketin kendisi — medium.com gibi)

- Organizasyon seviyesindeki roller tüm katmanlara “global” olarak uygulanır.

Projeler (Gcp’nin temel organizasyonel komponenti)

- Aynı projedeki servisler varsayılan olarak belirli bir güven seviyesine sahiplerdir.
- Erişim kontrolünün birincil metodudur.
- GCP servislerini oluşturabilir ve yönetebiliriz.
- Faturalama, Api’ler ve roller gibi kısımları bulunur.

Kaynaklar

- GCP servisleridir. (Compute Engine, BigQuery vb.)

IAM (Identity & Access Management)

Kimlik ve Erişim Yönetimi bulutta oldukça önemlidir. Nedeni ise tüm organizasyonların kaynaklara erişmek ve onları yönetmek için bu sisteme ihtiyaç duymasıdır. Güvenlik açısından bakıldığında istenmeyen erişimleri engellemek ve en az yetki verme prensibi gibi güvenlik kurallarını uygulamak açısından olmazsa olmazdır.

Bulutta IAM kavramı, temel olarak kimin, ne şekilde, hangi kaynaklara erişebileceğinin yönetilmesini kapsar. “Kim” sorusu üye ile, “Neye” sorusu erişebileceği roller ile ve kaynaklar ise “resources” şeklinde temsil edilir.

Member (“Kim” anlamındaki Üye)

Bir kişi, birden fazla kişiden oluşan grup ya da bir program olabilir.

-Google hesabıdır. Bireyseldir (ör: admin@erbuluthizmetleri.net gibi)
- Google grubu. (ör: DevTeam@erbuluthizmetleri.com gibi)
- G Suite alanı (domain) (ör: @erbuluthizmetleri.com gibi)
- Bulut kimlik alanı (domain) G suite gibi ancak Google servisleri olmadan
- Servis hesabı — program erişimi

(9554214484725-compute@developer.gserviceaccount.com gibi)

Her üye bir e-posta hesabı ile temsil edilir. E-posta hesabı = erişim metodudur.

Rol (“Neye” erişilebileceği)

- Rol: Erişim izinlerinin toplamıdır.
- İzinler: Kaynaklarda hangi operasyonların yapılabileceğini tanımlar.
- İzinleri üyelere atamak yerine rolleri kullanırız. Rolleri ise üyelere atarız.

Rol Odağı

- Organizasyon/Proje Seviyesi — Primitive
- Kaynak/Granular Seviyesi — Predefined gibi tanımlanır.

Primitive ve Predefined Roller

Primitive — Modern bulut IAM uygulamalarından önceki GCP rolüdür.

- Tüm projeye verilir.
- Sahip (owner) = Tam admin erişimi, IAM yönetimi ve faturalandırma.
- Editör = Kaynak durumlarını modifiye etme yetkisi.
- Viewer = Sadece-okuma erişimi.

Predefined (Önceden Belirlenmiş) Rol

- Granular — Kaynak seviyesine uygulanır. (Compute, Cloud storage vb)
- Örnek: Compute Engine Instance Admin gibi.
- Bir üye başına, çoklu (önceden belirlenmiş) roller verilebilir.

Kaynaklar

- Projeler
- Compute Engine Instance’ları
- Cloud Storage Bucket’ları
- BigQuery veri setleri vb. gibi olarak tanımlanabilir.

Cloud IAM İlkesi

IAM ifadelerinin bir toplamıdır diyebiliriz. Genel olarak programatik şekilde kullanılırlar.

İlke Hiyerarşisi

- Bir dosya sistemi gibidir.
- Parent-child ilişkisi.
- Child’ın sadece bir parent dosyası bulunur.
- İlkeler zincir boyunca yukarıdan aşağı miras alınır (inherited)
- Parent ilkesi child ilkesinin üzerindedir. (permissive)

En Az Yetki Prensibi Uygulamaları

- Kaynakları izole etmek için projeleri kullanın.
- Önceden belirlenmiş rolleri, primitive rollere tercih edin.
- En küçük odaktan başlayarak rolleri verin.
- Owner Rolünü, sadece bir IAM ilkesinin değişmesi gerekliyse verin. Yoksa onun yerine editör kullanın.
- Proje oluşturmayı, Proje Yaratıcısı Rolü ile kısıtlayın

Bazı İyi Uygulamalar

- İlke mirasını (Policy inheritance) etraflıca anlayın.
- Mümkün olan yerlerde grupları kullanın.
- Grubun sahibinin kim olduğunu ve onu kimin yönettiğini kontrol edin.
- Sadece kurumsal ya da şirket hesabı düzeyinde erişime olanak sağlayın.
- Kişisel G-mail hesapları olmasın.
- Cloud Identity hesabı ile dışarıdaki kişileri ekleyebilirsiniz.
- Servis hesaplarında ise hesabı actor/user erişimi şeklinde kısıtlayın.
- Gereksiz şekilde servis hesabı anahtarlarını açık etmeyin.
- Halen kullanılmakta olan servis hesaplarını silmeyin.
- Eğer aynı rol birçok projede gerekiyorsa, organizasyon ve ya dizin seviyesinde yetki verin.

Networking (Ağ) Nasıl Çalışır?

Bilgisayarlar iletişim kurmak için belirli bir ortak dile ihtiyaç duyarlar. TCP/IP ağ protokolü bu dile bir örnektir. TCP/IP ağ protokolü sadece tek bir protokol değil standartlaşmış bir protokoller bütünüdür.

OSI Model Katmanları basitçe aşağıdaki gibidir:

- Uygulama Katmanı
- Sunum (Presentation) Katmanı
- Oturum (Session) Katmanı
- Transport katmanı
- Ağ Katmanı
- Veri Bağlantı katmanı
- Fiziksel Katman

Network Portları

OSI Modelindeki seviye 4'ün üstündeki protokollere port numarası atanmıştır. Port = Kanal demektir. TCP ve UDP protokolleri için 65535 port mevcuttur. Ör: HTTP = port 80, SSH = port 22 gibi. Her protokolün numarası olmayabilir. Ör: ICMP gibi.

Güvenlik Duvarları

Güvenlik duvarları ağ erişiminin geçit koruyucuları gibi çalışırlar. Bazı durumlara göre erişime izin verir ve ya reddederler. Ör: Deny access on port 80, Allow access on port 22 gibi. GCP’de aynı şekilde port ve protokole bağlı olarak erişim, durumsal değişiklik gösterir. Bazı yerlerden erişimi kabul ederken diğerlerine kapatabilir.

İşletim Sistemi Uygulamaları

- Güvenilir olmayabilecek uygulamaları kapatın. (Telnet gibi)
- Özel Kimlik bilgilerini koruyun.
- Linux için özel SSH anahtarları ve parolalar gibi.
- SSH anahtarlarını paylaşmayın.
- Windows için yerel hesabın kullanıcı adını ve parolayı vb gibi paylaşmayın.
- Misafir hesapları kapatın.
- Dosya paylaşımını ve yazdırmayı kapatın.

Yazılım Güvenlik Duvarı

Geleneksel güvenlik duvarı, ağı dış tehditlerden korur ancak ağ içindeki iletişimi açık bırakır. Google Cloud Firewall ise her instance için (iç iletişim dahil) uygulanır. Yazılım güvenlik duvarları genel olarak üçüncü parti denetim uyumu için gereklidir. En iyi uygulamalar: doküman uygulamasındaki VPC güvenlik duvarı ile çakışmamasına dikkat edin ve sadece gerekli trafiğin erişimine izin verin.

Kabul Edilebilir Kullanım ve Karar Adımları

- Kaynaklarınızı, legal olmayan şekilde (malware yaymak veya DDOS Atakları vb gibi) kullanmayacağınızı kabul edersiniz.

Kötüye Kullanma Kararı (Abuse Resolution)

- Hizmet kullanım koşulları ihlali.
- Gönder başvurusu. (Submit Appeal)
- Başvuru konfirme edilir ve çözülür.

Cloud Storage Güvence Altına Alma

Bulut depolama güvenliğinde bir açık olmasının çok zarar verici sonuçları olabilir. Gcp’de cloud storage güvenliği sizin kontrolünüzdedir. Hassas bilginin ifşa olması için herhangi bir neden yoktur. İfşa olayları % 100 önlenebilirdir. Section objective ile kazara oluşan ifşalardan kaçınabilirsiniz.

Şifreleme

Şifreleme veriyi enkodlama sürecine verilen isimdir. Onu karıştırıp dış partilerin kullanamayacağı bir hale getirmeye çalışır. Düz tekst, ciphertext’e dönüştürülür. Bir şifreleme anahtarı ile eşlenir. Public algoritma için AES kullanılır ancak gizli bir anahtar ile.

Şifreleme sizi ve verinizi çeşitli şekillerde korur. Şifrelemede veri, transitte olan veri ve at rest veri olarak tanımlanır. Transitte olan veri için şifrelenmiş veri, snooping denilen trafik gözetlemelerinden gizlenir. At rest veri için ise veri (scrambled) şifreleme anahtarı olmadan dönüştürülemez. (unscrambled)

GCP’de varsayılan olarak herşey şifrelenir. Şifrelenmeyen diye bir opsiyon mevcut değildir.

Transitte Şifreleme

- Varsayılan olarak şifrelenir.
- Varsayılan ve kullanıcı için özel opsiyonlar mevcuttur.

Varsayılan = BoringSSL kullanarak TLS. Sertifika Otoritesi, ALTS
Özel = VPN (IPsec), yönetilen SSL sertifikaları vb. gibi.

At Rest Şifreleme

- Veriyi korur (atak yapan hakimiyet elde etse bile anahtar olmadan şifreyi çözemez)
- Şifreleme, tüm Google Storage sistemlerinde miras olarak alınır. (inherent)
- Google veriyi, süreç içerisinde çoklu katmanlarda şifreler.
- Şifrelenmiş veri, parçalara ayrılır ve veri merkezlerine eşsiz anahtarlar ile dağıtılır. Key Management hizmeti ile her parçanın anahtarının kendisi, başka bir anahtar ile şifrelenir.

At Rest Opsiyonları

- Google yönetilen anahtarlar: Varsayılan/Otomatik opsiyon, sık şekilde rotasyon.
- KMS — Key Management Service ile Müşteri Anahtarları: Müşteriye sağlanan anahtarlar ve yönetilen depolama/rotasyon.
- Müşteri Tarafından Sağlanan ve Saklanan Anahtarlar: Kurum-içi (on-premise) saklanan anahtarlardır.
- Daha fazla otomasyon ve ya daha fazla kontrol şeklinde tercihinizi yapabilirsiniz.

Çalışma amaçlı notlardır. Bazı bilgiler (siz bu yazıyı okurken) değişmiş veya yenilenmiş olabilir. Bu nedenle kullanacağınız teknoloji için her zaman resmi web sitelerindeki güncel bilgileri esas alınız!

Kaynaklar: