Zero Trust Ağ Mimarisi ve BeyondCorp: Geleneksel Çevre Güvenliğini Aşmak

 · 

Zero Trust Ağ Mimarisi ve BeyondCorp: Geleneksel Çevre Güvenliğini Aşmak

Zero Trust Ağ Mimarisi ve BeyondCorp: Geleneksel Çevre Güvenliğini Aşmak

Geleneksel ağ güvenlik modelleri, güvenli bir iç çevre ve güvensiz bir dış çevre varsayımı üzerine kuruluydu. Bu perimeter tabanlı yaklaşım, kurumsal kaynaklara iç ağdan erişimin zımnen güvenilir olduğu anlayışını benimsiyordu. Ancak bulut bilişimin yükselişi, mobil iş gücü ve sofistike iç tehditler bu modeli yetersiz kıldı. Zero Trust (Sıfır Güven) felsefesi, "Asla Güvenme, Her Zaman Doğrula" ilkesiyle bu paradigmaya radikal bir alternatif sunar. Özellikle Google'ın BeyondCorp girişimi, bu felsefenin somut bir uygulamasını temsil eder.

BeyondCorp Felsefesinin Temel Dinamikleri

BeyondCorp, kurum içi kaynaklara erişimin, kullanıcının fiziksel konumundan veya ağ segmentinden bağımsız olarak, internet üzerinden güvenli bir şekilde sağlanabileceği bir model önerir. Bu, VPN ihtiyacını ortadan kaldırır ve erişim kararlarını sadece kimlik ve cihaz duruşu üzerine kurar. Geleneksel "güvenilir iç ağ" kavramını tamamen reddeder.

Bu modelin merkezinde, her erişim talebinin ayrı ayrı doğrulanması ve en az ayrıcalık ilkesinin uygulanması yatar. Erişim kararları sadece kimlik doğrulama ile değil, aynı zamanda cihazın sağlık durumu, kullanıcının rolü, erişmeye çalıştığı kaynak ve hatta zaman gibi bağlamsal faktörlerle de şekillenir.

Teknik Uygulama: Bileşenler ve İşleyiş

BeyondCorp mimarisini hayata geçirmek için birden fazla bileşen entegre çalışır:

  • Kimlik Sağlayıcı (IdP): Kullanıcı kimlik doğrulamasının merkezi noktasıdır. Multi-Factor Authentication (MFA) kullanımı zorunludur. (Örn: Okta, Azure AD, Google Identity Platform).
  • Cihaz Envanter ve Sağlık Kontrolü: Erişim öncesinde cihazın güncel işletim sistemi, yama seviyesi, antivirüs durumu gibi metrikleri kontrol edilir. Cihaz sertifikaları veya ajanlar bu bilgiyi sağlar.
  • Erişim Proxy'si/Ağ Geçidi: Tüm trafiği sonlandırır, politikaları uygular ve kimlik sağlayıcı ile entegre olur. Geleneksel VPN'in yerini alır. (Örn: Nginx ile Reverse Proxy, Envoy Proxy, Cloudflare Access).
  • Politika Motoru (Policy Engine): Erişim kararlarını dinamik olarak veren merkezi bir bileşendir. Kullanıcı kimliği, cihaz durumu, kaynak hassasiyeti ve bağlamsal faktörlere göre kuralları değerlendirir.
  • Güvenlik Bilgileri ve Olay Yönetimi (SIEM): Erişim günlüklerini toplar, analiz eder ve anormallikleri tespit eder.

Bir kullanıcı bir kaynağa erişmek istediğinde süreç şu adımları takip eder:

  1. Kullanıcı, erişim proxy'sine bağlanır.
  2. Proxy, kullanıcıyı IdP'ye yönlendirerek kimlik doğrulaması ister (MFA dahil).
  3. Kullanıcının cihazından cihaz sağlık verileri toplanır (cihaz sertifikası veya ajan aracılığıyla).
  4. Politika motoru, kullanıcı kimliği, cihaz sağlık durumu, kaynak gereksinimleri ve diğer bağlamsal faktörleri kullanarak bir erişim kararı verir.
  5. Eğer erişim onaylanırsa, proxy trafiği yetkilendirilmiş kaynağa yönlendirir. Aksi takdirde erişim reddedilir.

Gerçek Dünya Senaryosu: Geliştirme Ekibi ve Üretim Ortamı Erişimi

Büyük ölçekli bir SaaS şirketinde, geliştiricilerin üretim ortamındaki Kubernetes kümelerine ve veritabanlarına erişmesi gerekiyor. Geleneksel olarak bu, özel bir VPN ağı üzerinden veya bastion host'lar aracılığıyla sağlanırdı. BeyondCorp modeli ile bu süreç daha güvenli ve yönetilebilir hale getirilir.

Senaryo Adımları:

  1. Kimlik Doğrulama: Geliştirici, şirket tarafından sağlanan yönetilen bir cihazdan, IdP (örn. Okta) üzerinden MFA ile kimliğini doğrular.
  2. Cihaz Sağlığı: Okta Device Trust veya benzeri bir entegrasyon, cihazın işletim sisteminin güncel olduğunu, disk şifrelemesinin aktif olduğunu ve güvenlik yazılımının çalıştığını doğrular. Uyumsuz bir cihazdan erişim talebi otomatik olarak reddedilir.
  3. Erişim Politikası: Bir politika motoru (örn. Open Policy Agent (OPA) ile entegre edilmiş bir ağ geçidi), aşağıdaki gibi bir kural setini değerlendirir:
    • Kullanıcı developer grubunda mı?
    • Cihaz sağlık puanı 90 üzerinde mi?
    • Erişim talebi mesai saatleri içinde mi yapılıyor?
    • Erişilen kaynak production-k8s-cluster mı yoksa development-database mi?
    • production-k8s-cluster erişimi için ek olarak Yöneticiden onay gerekiyor mu?
// OPA (Rego) kuralı örneği (basitleştirilmiş)package system.authzdefault allow = falseallow {    input.user.groups[_] == "developer"    input.device.health_score >= 90    is_business_hours(input.request.time)    # Production Kubernetes erişimi için özel koşullar    input.request.resource == "production-k8s-cluster"    input.user.has_approval_for_prod == true}allow {    input.user.groups[_] == "developer"    input.device.health_score >= 90    is_business_hours(input.request.time)    input.request.resource == "development-database"}is_business_hours(time_str) = true {    # Zaman kontrolü mantığı burada yer alır (örn. 09:00-17:00 arası)    # Basitlik için her zaman true döndürülmüştür.}

Bu Rego kuralı, geliştirici grubundaki kullanıcıların belirli koşullar altında kaynaklara nasıl erişebileceğini gösterir. Üretim Kubernetes kümesi için ek bir has_approval_for_prod bayrağı gerektirilerek, hassas kaynaklara erişim daha da sıkılaştırılır.

  1. Uygulama: Eğer tüm koşullar sağlanırsa, ağ geçidi, geliştiricinin sadece production-k8s-cluster veya development-database gibi yetkilendirilmiş kaynaklara erişmesine izin verir. Başka hiçbir iç kaynağa (örn. finansal raporlama sistemi) erişimi otomatik olarak engellenir.

AWS Ortamında BeyondCorp İlkeleri

AWS bulutunda BeyondCorp ilkelerini uygulamak, çeşitli AWS servislerinin entegrasyonunu gerektirir.

  • Kimlik Yönetimi: AWS IAM Identity Center (eski adıyla AWS SSO) veya AWS Cognito, IdP olarak kullanılabilir ve diğer harici IdP'lerle entegre olabilir.
  • Erişim Kontrolü: AWS WAF, AWS API Gateway veya bir Layer 7 proxy (örn. Nginx, Envoy) EC2 üzerinde çalışarak erişim kontrol noktası görevi görebilir.
  • Cihaz Durumu: AWS Systems Manager (SSM) Agent, EC2 örnekleri ve hatta şirket içi cihazlar için envanter ve yama yönetimi sağlayabilir. Ancak son kullanıcı cihazları için genellikle üçüncü taraf MDM (Mobile Device Management) çözümleri veya endpoint ajanları kullanılır.
  • Politika Yönetimi: IAM politikaları, Resource-based politikalar ve VPC Endpoint politikaları, kaynak erişimini kısıtlamada kritik rol oynar. Politika motoru mantığı, AWS Lambda veya OPA gibi araçlarla uygulanabilir.
  • Denetim ve Loglama: AWS CloudTrail, Amazon CloudWatch Logs ve AWS Security Hub, tüm erişim ve güvenlik olaylarını merkezi olarak toplar ve analiz eder.

AWS ortamında, her servisin kendi erişim kontrol mekanizması (IAM) olması, mikro-segmentasyonun doğal bir uzantısıdır. BeyondCorp, bu yerel kontrolleri merkezi bir kimlik ve cihaz duruşu doğrulama katmanıyla birleştirir.

Sonuç

BeyondCorp yaklaşımı, geleneksel perimeter güvenliğinin ötesine geçerek, kurumların dağıtık ve dinamik iş yüklerini güvenle yönetmesini sağlar. "Her şey güvensizdir" varsayımıyla hareket ederek, her erişim talebini titizlikle doğrulayan bu model, modern siber güvenlik stratejilerinin temelini oluşturur. Uygulaması karmaşık olsa da, sağladığı güvenlik duruşu ve operasyonel esneklik, bu çabayı değerli kılar.

← Blog Listesine Dön