1. GİRİŞ

Kurumsal güvenlik politikaları (security policies), bir organizasyonun risk toleransını, davranış kurallarını ve teknik kontrol beklentilerini resmi olarak tanımlayan dokümanlardır. Günümüzün hızla değişen bulut‑native, microservice ve veri odaklı mimarilerinde, doğru tasarlanmış ve etkin uygulanmış güvenlik politikaları olmadan teknik kontroller yetersiz kalır. Politikalar, sadece "ne yapılması gerektiği"ni değil aynı zamanda "kimin, ne zaman, nasıl" yapacağını da ortaya koymalıdır.

Bu neden bugün önemli?

• Bulut, CI/CD ve otomasyon ile hızlı değişim; manuel süreçler yetersiz kalır.
• Regülasyonlar (GDPR, KVKK, PCI, HIPAA) ile uyumluluk talepleri politika gerektirir.
• Policy as code ve otomasyon sayesinde politikalar doğrudan runtime davranışa dönüştürülebilir — bu, güvenliğin ölçeklenmesini sağlar.

Kimler için önemli?

• Güvenlik liderleri (CISO), güvenlik mühendisleri
• DevOps ve SRE ekipleri — uygulama ve infra politikalarını hayata geçirmek için
• Yazılım geliştiriciler — secure-by-design geliştirme için
• Uyumluluk ve risk ekipleri — politika uyum ve kanıt süreçleri için

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• Security policy: Organizasyonun güvenlik hedeflerini ve bu hedeflere ulaşmak için uygulanması gereken kuralları tanımlayan üst düzey doküman.
• Standard: Politikanın teknik olarak nasıl uygulanacağına dair referans niteliğinde kurallar (örn. şifreleme algoritmaları, minimum TLS sürümü).
• Procedure / Procedure playbook: Operasyonel adımlar; bir güvenlik olayında veya rutin iş akışında yapılacaklar listesi.
• Policy as code (PaC): Güvenlik politikasını makine tarafından değerlendirilebilir kod formunda ifade etme yaklaşımı (örn. OPA / Rego, Sentinel, Kyverno, Gatekeeper).

2.2 Politika türleri

• Organizasyonel politika: Risk appetite, rol ve sorumluluklar, eğitim gereksinimleri.
• Teknik güvenlik politikası: IAM, şifreleme, ağ segmentasyonu, logging retention, backup policy gibi teknik gereksinimler.
• Operasyonel politika: Change management, vulnerability management, incident response süreçleri.
• Veri ve gizlilik politikası: Data classification, retention, data residency ve erişim kontrolleri.

3. NASIL ÇALIŞIR?

3.1 Policy lifecycle — yaşam döngüsü

Başarılı bir politika programı şu aşamaları içerir: oluşturma (design), onay (governance), yayın (communication), uygulama (enforcement), izleme (monitoring) ve düzenli gözden geçirme (review). Bu döngü SDLC ve değişiklik yönetimi ile entegre edilmelidir.

3.2 Policy as code: mimari ve bileşenler

Policy as code yaklaşımı aşağıdaki bileşenleri içerir:

1. Policy repository: Git tabanlı depoda yazılmış politika kodları (Rego, Sentinel, Kyverno manifestleri).
2. Policy engine: Runtime'da istekleri/artefaktları değerlendiren motor (OPA, Sentinel, Gatekeeper).
3. Enforcement points: CI/CD pipeline, admission controllers, API gateway, infra provisioning (Terraform plan checks) gibi yerlerde politika kontrolleri.
4. Monitoring & audit: Politika ihlallerinin telemetriye aktarımı, alerting ve report generation.

3.3 Teknik uygulama örnekleri

- CI/CD pipeline: PR açıldığında policy engine, Terraform plan veya Kubernetes manifest'lerini değerlendirir. Başarısızsa pipeline block edilir.

- Cluster admission control: Kubernetes Gatekeeper, policy as code ile runtime manifest'leri kontrol eder (örn. "container images must be from approved registry" veya "privileged: false").

- API gateway ve WAF: request bazlı politikalar (rate limit, content filtering, JWT validation) uygulanır.

3.4 Enforcement vs detection

Politikaları iki katmanda düşünün: preventive enforcement (erişimi reddet, deploy'u durdur) ve detective controls (log, alert, ticket oluştur). Kritik politikalar önleyici olmalı; esneklik gerektiren durumlarda önce tespit ve uyarı, ardından kademeli bloklama stratejisi izlenmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — güvenlik kültürü ve politikaların otomasyonu

Netflix gibi güvenlik‑olgun şirketler, politikaları kültüre entegre ederler. Otomasyon, test ortamlarında politikaların sürekli uygulanması ve mühendislerin kendi sorumluluk alanlarında policy'leri kullanabilir hale gelmesi önemli örneklerdendir. Bu tür organizasyonlarda "policy owners" ve "policy engineers" rolleri net tanımlıdır.

4.2 Amazon — ölçek, telemetry ve guardrails

Amazon‑ölçeğinde guardrails (koruyucu sınırlar) ve guardrail‑as‑code kavramları kullanılır. Örneğin maliyet, erişim ve güvenlik açısından otomatik kısıtlar devreye alınır; ihlal eden kaynaklar quarantine edilip owner'a bildirilir.

4.3 Stripe ve finansal hizmetler — compliance‑driven policy'ler

Stripe gibi finansal platformlar için güvenlik politikaları hem teknik hem de yasal zorunlulukları karşılamalıdır. Policy'ler, PCI/DSS ve regülasyon talepleriyle paralel olarak audit‑ready veri sağlar; KYC/KYB süreçleri ise operasyonel politikalara entegre edilir.

4.4 OpenAI — AI güvenlik politikaları ve model governance

Model‑ve‑data governance politikaları, LLM'lerin kullanımını sınırlar; kullanım politikaları, prompt filtering, rate limits ve abuse monitoring mekanizmaları içerir. Model dağıtımı ve retraining politikası ayrıca provenance ve dataset governance gerektirir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Politika kod olarak yazıldığında, tutarlılık ve ölçeklenebilirlik sağlanır.
• Denetim ve uyumluluk için kanıt üretimi kolaylaşır.
• Risklerin standardize edilmesi ve otomatik müdahale ile insan hatası azaltılır.

Sınırlamalar

• PaC benimsemek kültürel değişim gerektirir — mühendislik ekipleri politika yazma sorumluluğu almalı.
• Yanlış veya hatalı tanımlanmış politikalar üretimi bloke edebilir; staging/canary evreleri şarttır.
• Policy engine'lerin performans ve ölçek sorunları olabilir; latency kritik olan path'lerde dikkatli planlamak gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Production kullanımı

• Start small: kritik politikalar ile (IAM, image registry, secrets handling) başlayın.
• Deploy politikaları adım adım: önce detect‑only modda izle, ardından enforce moduna geçir.
• Version control: tüm politika kodları Git reposunda tutulmalı, PR süreçleri ile değişiklik izlenmeli.

7.2 Performans optimizasyonu

• Policy evaluation latency'yi ölçün ve caching stratejileri uygulayın.
• Ağ gecikmesi kritikse, karar noktasını (policy decision) yakınlaştırın veya local cache kullanın.
• Policy complexity'yi sınırlayın; mümkünse policy'leri modüler ve reuse‑able tutun.

7.3 Güvenlik ve ölçeklenebilirlik

• Secrets management: policy kodu içinde gizli bilgi saklamayın; referanslayın (KMS, Vault).
• High‑availability: policy engine bileşenleri için HA ve ölçeklenebilir mimari kurun.
• Logging ve audit: her politika değerlendirmesinin sonucu log'lanmalı ve uzun dönem saklanmalıdır.

8. SIK YAPILAN HATALAR

• Politika gereksinimini belirsiz bırakmak — politikalar açık, ölçülebilir ve uygulanabilir olmalı.
• Direct enforcement ile başlamak — detect‑only evresini atlamak operasyonu riske sokar.
• Policy'leri tek bir takımın sorumluluğuna bırakmak — multi‑stakeholder governance gereklidir.
• Kanıt ve logging eksikliği — denetim ve forensics için yeterli telemetry sağlanmalı.

9. GELECEK TRENDLER

9.1 Policy as data ve AI destekli politika üretimi

Policy as data yaklaşımı ile politika kuralları veri tabanlı tanımlanıp makine öğrenmesi ile öneri/optimizasyon süreçlerine dahil edilecek. AI, geçmiş ihlal ve operational cost verilerini kullanarak politika kurallarının etkisini öngörebilir.

9.2 Continuous policy validation ve compliance

Continuous compliance araçlarıyla, politika ihlalleri anlık olarak tespit edilip otomatik remediation tetiklenecek. Bu, SOC ve GRC süreçleri arasında daha sıkı entegrasyon sağlar.

9.3 Standards ve interoperability

Açık politika formatları ve standartları (ör. OAS for security policies, common policy schemas) yetişecek; bu sayede farklı araçlar arasında politika paylaşımı ve ortak governance mümkün olacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Policy as code nedir, neden kullanmalıyım?

   Policy as code, güvenlik politikalarının makine tarafından değerlendirilebilir biçimde kodlanmasıdır. Tutarlılık, otomatik enforcement, audit‑ready kanıt ve CI/CD entegrasyonu sağlar. Özellikle ölçekli, hızlı değişen ortamlarda tercih edilir.

2. 2. Hangi politikalar önce kodlanmalı?

   İlk adımda IAM kuralları, image provenance (approved registries), secrets handling ve network egress/ingress kısıtları gibi kritik politikalar kodlanmalıdır.

3. 3. Politika değişiklikleri nasıl yönetilmeli?

   Tüm politika değişiklikleri PR süreciyle yönetilmeli, owner onayı, automated test (policy linting, unit tests) ve staging rollout ile geçilmelidir.

4. 4. Detect‑only modu neden önemli?

   Detect‑only modu, politika etkinliğini ve false positive riskini ölçmek için kullanılır. Doğrulanmadan doğrudan engelleme üretimi bozabilir.

5. 5. Politika ihlallerini nasıl izlemeliyim?

   Policy engine log'larını SIEM'e gönderin, alerting ve ticketing entegrasyonu kurun. Ayrıca ihlal trendlerini KPI olarak izleyin.

6. 6. Policy kodu için hangi araçları önerirsiniz?

   OPA (Rego) + Gatekeeper, Kyverno, HashiCorp Sentinel, Azure Policy, AWS IAM Access Analyzer ve Terraform Sentinel gibi araçlar yaygın kullanılır. Seçim altyapı ve entegrasyon ihtiyaçlarına göre değişir.

7. 7. Politika performansını nasıl ölçerim?

   Policy evaluation latency, cache hit ratio, false positive/negative oranı ve pipeline block oranları gibi metrikleri izleyin. Ayrıca politika değişikliklerinin deploy gecikmesine etkisini ölçün.

8. 8. Küçük ekiplerde politikaları nasıl sürdürülebilir kılarım?

   Start small, own small: birkaç kritik politika ile başlayıp automation ve ownership tanımlayın. Policy şablonları ve reusable modüller ile bakım maliyetini düşürün.

Anahtar Kavramlar

• Policy as code (PaC): Güvenlik politika kurallarının kod biçiminde ifade edilmesi.
• Policy engine: PaC kurallarını değerlendiren runtime bileşen (OPA, Kyverno).
• Detect‑only: Politikayı sadece tespit ve raporlama için aktif etme modu.
• Governance: Politika sahipliği, onay akışları ve gözden geçirme süreçleri.

Öğrenme Yol Haritası

1. 0–1 ay: Security policy temel kavramları, organizasyonel politika şablonları ve SDLC entegrasyonu öğrenin.
2. 1–3 ay: OPA/ Kyverno gibi araçlarla basit politika kuralları yazın; CI/CD pipeline'a policy checks ekleyin.
3. 3–6 ay: Policy as code reposu, test ve staging süreçleri kurun; detect‑only evresinden enforce evresine geçiş stratejileri uygulayın.
4. 6–12 ay: Continuous compliance, policy monitoring, governance mekanizmaları ve cross‑team ownership ile olgunlaştırın.