Zero Trust Ağ Mimarisi: BeyondCorp Yaklaşımıyla Kurumsal Güvenliği Yeniden Tanımlamak

Geleneksel ağ güvenlik modelleri, kurumsal ağın içerisini güvenli, dışarısını ise güvensiz kabul eden bir çevre tabanlı yaklaşıma dayanır. Ancak bulut bilişim, mobilite ve SaaS uygulamalarının yaygınlaşmasıyla bu model geçerliliğini yitirmiştir. Güvenlik ihlallerinin büyük çoğunluğunun içeriden kaynaklandığı veya içeride yanal hareketle yayıldığı gerçeği, "asla güvenme, her zaman doğrula" ilkesine dayanan Zero Trust mimarisini zorunlu kılmıştır. BeyondCorp, Google tarafından geliştirilen ve bu prensibi hayata geçiren bir referans mimaridir.

BeyondCorp'un Temel Prensipleri ve Yapı Taşları

BeyondCorp, kullanıcıların ve cihazların kurumsal ağ sınırları içinde olup olmadığına bakılmaksızın tüm erişim isteklerinin kimlik doğrulaması ve yetkilendirmesini gerektiren bir erişim modelidir. VPN'in aksine, bu yaklaşım ağ katmanında geniş erişim sağlamak yerine, her bir uygulama erişimini ayrı ayrı değerlendirir. Ana bileşenleri şunlardır:

• Identity-Aware Proxy (IAP) / Erişim Proxy'si: Tüm uygulama trafiği bu proxy üzerinden geçer. Kullanıcı kimliğini, cihaz durumunu ve bağlamsal bilgileri doğrulayarak yalnızca yetkili istekleri hedef uygulamaya yönlendirir.
• Cihaz Güveni (Device Trust): Erişim izni vermeden önce cihazın güvenlik duruşu (işletim sistemi sürümü, yama seviyeleri, güvenlik yazılımları, şifreleme durumu) doğrulanır. Bu, özel bir istemci yazılımı veya işletim sistemi düzeyinde entegrasyon ile sağlanır.
• Kullanıcı Güveni (User Trust): Kullanıcıların kimliği, çok faktörlü kimlik doğrulama (MFA) ve kimlik sağlayıcıları (IdP) aracılığıyla sıkı bir şekilde doğrulanır.
• Bağlamsal Yetkilendirme (Contextual Authorization): Erişim kararları sadece kimlik veya cihaz bilgisine değil, aynı zamanda coğrafi konum, zaman, erişilen kaynak türü ve hatta kullanıcının risk profili gibi dinamik bağlamsal verilere dayanır.
• Politika Motoru (Policy Engine): Tüm bu verileri toplayan ve önceden tanımlanmış güvenlik politikalarına göre erişim kararlarını veren merkezi bir bileşendir.

Teknik Derinlik: Erişim Akışı ve Politika Uygulama

BeyondCorp mimarisinde bir kullanıcının bir uygulamaya erişim isteği aşağıdaki adımları takip eder:

1. Kullanıcı, web tarayıcısı üzerinden bir kurumsal uygulamaya (örneğin, https://jira.kurumsal.com) erişmeye çalışır.
2. DNS çözünürlüğü, isteği doğrudan hedef uygulama yerine, IAP katmanına yönlendirir.
3. IAP, kullanıcının kimliğini doğrulamak için IdP (örneğin, Okta, Azure AD) ile etkileşime girer. Kullanıcı MFA ile kimlik doğrulaması yapar.
4. IAP, kullanıcının cihazından gelen bilgileri (örneğin, cihaz sertifikası, Endpoint Detection and Response (EDR) agent raporu) toplar veya bir Cihaz Envanter/Sağlık servisine sorgu gönderir. Bu bilgiler, cihazın güncel OS, şifrelenmiş disk, güvenlik yazılımı durumu gibi metrikleri içerir.
5. Toplanan kullanıcı kimliği, cihaz durumu ve diğer bağlamsal veriler (IP adresi, coğrafi konum, zaman) Politika Motoruna iletilir.
6. Politika Motoru, tanımlanmış erişim kurallarına göre bu isteği değerlendirir. Örneğin:policy rule "jira_developers_access": if user.groups contains "jira-devs" and device.is_compliant and user.location in ["tr", "de"] and time.is_working_hours then allow else deny
7. Eğer politika motoru erişime izin verirse, IAP isteği güvenli bir şekilde (genellikle TLS tüneli üzerinden) hedef Jira uygulamasına iletir. Aksi takdirde, erişim engellenir ve kullanıcıya uygun bir mesaj gösterilir.
8. Tüm bu adımlar detaylı olarak loglanır ve merkezi bir güvenlik bilgi ve olay yönetimi (SIEM) sistemine aktarılır, böylece denetlenebilirlik ve tehdit avcılığı için veri sağlanır.

Gerçek Bir Senaryo: Çok Uluslu Bir SaaS Şirketinde BeyondCorp Uygulaması

Bir SaaS şirketinin dünya genelinde dağılmış 5000 çalışanı olduğunu ve bu çalışanların çeşitli coğrafi konumlardan (ev ofisler, ortak çalışma alanları, geleneksel ofisler) Salesforce, Jira, Confluence, şirket içi geliştirilmiş mikroservisler ve AWS yönetim konsolları gibi kritik uygulamalara erişmesi gerektiğini düşünelim. Önceden tüm erişim bir VPN tüneli üzerinden sağlanıyordu. Bu durum, VPN gateway'lerinin performans darboğazlarına, cihaz sağlığının denetlenememesine ve herhangi bir saldırıda yanal hareket riskine yol açıyordu.

Şirket, BeyondCorp modelini benimseyerek bu sorunları çözmeyi hedefledi. İlk adımda, şirket içi uygulamalar ve SaaS erişimleri için Azure AD entegrasyonlu bir Cloudflare Access (veya benzeri bir IAP çözümü) dağıtıldı. Çalışanların cihazlarına CrowdStrike Falcon Endpoint Protection agent'ı yüklendi ve bu agent'ın raporladığı cihaz sağlığı verileri (yama durumu, EDR aktivitesi, disk şifreleme) Cloudflare Access'in politika motoruna entegre edildi.

Örneğin, bir geliştirici Jira'ya erişmek istediğinde, önce Azure AD'de MFA ile kimlik doğrulaması yapar. Ardından, Cloudflare Access, geliştiricinin cihazının CrowdStrike tarafından 'compliant' (uyumlu) olarak işaretlenip işaretlenmediğini kontrol eder. Eğer cihaz güncel, şifreli ve EDR agent'ı aktif ise, geliştiricinin Jira'ya erişimine izin verilir. Aksi takdirde, erişim engellenir ve geliştiriciye cihazını güncellemesi veya güvenlik ekibiyle iletişime geçmesi talimatı verilir.

AWS yönetim konsollarına erişim için de benzer bir IAP katmanı (örneğin AWS SSO ve IAM Identity Center ile entegre bir IAP) kuruldu. Geliştiriciler, doğrudan AWS konsollarına erişmek yerine, IAP üzerinden kimlik doğrulamasından ve cihaz sağlığı kontrolünden geçerek AWS hesaplarına federasyon ile erişim sağladılar. Bu sayede, hiçbir çalışanın doğrudan internetten AWS konsoluna şifre ile erişme imkanı kalmadı, tüm erişimler IAP tarafından denetlendi ve loglandı.

# Cloudflare Access (pseudo-policy example for Jira)  
version: apps.cloudflare.com/v1beta2
kind: AccessApplication
metadata:
  name: jira-prod-app
  annotations:
    description: