Zero Trust (Sıfır Güven) Güvenlik Modeli Nedir?

Uzun yıllar boyunca güvenliği bir kaleye benzettik. Etrafına yüksek bir sur (güvenlik duvarı) örer, tek bir kapıya (VPN) nöbetçi koyar ve içeriye girmeyi başaran herkesin "bizden biri" olduğunu varsayardık. Kapıdan geçen kişi artık sorgusuz sualsiz koridorlarda dolaşabilir, odaların çoğuna girebilir, sunuculara ulaşabilirdi. Bu model kâğıt üzerinde mantıklıydı; çünkü tehdidin daima dışarıdan geldiğini, içerinin ise güvenli bir bölge olduğunu kabul ediyordu. Ne var ki bugünün gerçekliği bu varsayımı çoktan yerle bir etti.

Zero trust (sıfır güven), tam olarak bu "içerisi güvenlidir" varsayımını çöpe atan bir güvenlik yaklaşımıdır. Sloganı bir cümlede özetlenir: hiçbir şeye güvenme, her şeyi doğrula. Ağın içinden gelen bir istek de dışından gelen bir istek de aynı şüpheyle karşılanır; her erişim talebi, kaynağına ve hassasiyetine bakılmaksızın kimlik, cihaz ve bağlam üzerinden yeniden doğrulanır. Bu rehberde kale-hendek modelinin neden çöktüğünü, zero trust'ın hangi ilkeler üzerine kurulduğunu ve kendi sunucunuzda bu yaklaşıma bugün hangi somut adımlarla geçmeye başlayabileceğinizi, kıdemli bir sistem yöneticisinin gözünden anlatacağım.

Kale-Hendek Modeli Neden Çöktü#

Klasik çevre güvenliği (perimeter security), ağı ikiye böler: güvenilir iç ağ ve güvenilmez dış dünya. Güvenlik duvarı bu ikisi arasındaki suru, VPN ise tek kapıyı oluşturur. Sorun, bu modelin dayandığı iki temel varsayımın artık geçerli olmamasıdır.

Birinci varsayım, "içerisi güvenlidir" fikridir. Oysa saldırıların çok büyük kısmı bugün tam da içeriden başlıyor. Bir çalışanın oltalama (phishing) e-postasına tıklaması, bir geliştiricinin bilgisayarına bulaşan zararlı yazılım ya da sızdırılmış bir VPN kimliği, saldırganı bir anda "güvenilir iç ağın" tam ortasına yerleştirir. Kaleye bir kez girdikten sonra hiçbir kapı onu durdurmaz; bu duruma güvenlikte yanal hareket (lateral movement) denir. Saldırgan tek bir zayıf makineden başlayıp veritabanı sunucusuna, oradan yedekleme sistemine sıçrayarak tüm ağı ele geçirebilir. Çünkü içeride kimse kimliğini bir daha sormaz.

İkinci varsayım, "çevre bellidir" fikridir. Eskiden tüm sunucular tek bir veri merkezindeydi ve suru çizmek kolaydı. Bugün ise uygulamalarınız bir bulut sunucuda, veritabanınız başka bir sağlayıcıda, ekibiniz evden, kafeden, farklı ülkelerden bağlanıyor; SaaS servisleri, API'ler ve konteynerler devreye giriyor. Böyle bir ortamda "iç ağ" diye net bir sınır kalmadı. Suru nereye çizeceğinizi bilemediğinizde, suru korumaya çalışmak anlamını yitirir.

Zero trust işte bu iki çökmüş varsayımın yerine yenisini koyar: güven, bir ağ konumunun değil, her seferinde yeniden kanıtlanan bir kimliğin ve bağlamın sonucudur.

Zero Trust Aslında Ne Söyler#

Zero trust bir ürün değildir; satın alıp kurabileceğiniz bir kutu yoktur. Bir mimari yaklaşım, bir zihniyettir. Özünde tek bir cümle yatar: "asla güvenme, daima doğrula" (never trust, always verify). Bunu pratiğe döktüğünüzde üç soruyu her erişim talebinde yeniden sorarsınız.

Kim istiyor? İsteği yapan kimliğin gerçekten iddia ettiği kişi olduğundan emin misiniz? Bu, güçlü kimlik doğrulamayı ve çok faktörlü doğrulamayı zorunlu kılar. Neyle istiyor? İsteğin geldiği cihaz güncel ve sağlıklı mı, yoksa yamalanmamış, virüslü bir makine mi? Neye erişmek istiyor ve bu makul mu? Muhasebe ekibinden birinin gece 03.00'te üretim veritabanına erişmeye çalışması, tek başına parolası doğru olsa bile şüphe uyandırmalıdır.

Bu üç soruyu her seferinde sormanın anlamı, güvenin kalıcı değil, oturuma ve bağlama bağlı olmasıdır. Bir kez doğrulanan kimlik sonsuza dek serbest kalmaz; her yeni kaynağa erişimde, çoğu zaman farkında bile olmadan yeniden değerlendirilir. Bu değerlendirme başarısız olduğunda erişim reddedilir ya da ek doğrulama istenir. Zero trust'ı geleneksel modelden ayıran asıl fark budur: güven, bir kapıdan geçildiği anda verilmiş bir hak değil, sürekli yenilenmesi gereken bir denge halidir.

Zero Trust'ın Dört Temel İlkesi#

Zero trust'ı somut bir mimariye dönüştüren dört taşıyıcı sütun vardır. Bunları anlamak, hangi teknolojinin neden devreye girdiğini görmenizi sağlar.

Sürekli doğrulama. Erişim, tek seferlik bir giriş değil, tekrar eden bir kontroldür. Her istek kimlik, cihaz durumu, konum ve davranış gibi sinyallerle yeniden değerlendirilir. Oturum boyunca risk sinyalleri değiştiğinde (örneğin aniden farklı bir ülkeden bağlantı gelmesi) sistem yeniden doğrulama isteyebilir. Bu, iki faktörlü doğrulamayı sadece giriş anının değil, sürekli güvenin bir parçası haline getirir.

En az yetki. Her kimlik yalnızca işini yapabilmek için gereken minimum erişime sahip olur, bir tık fazlasına değil. Bir yedekleme betiği tabloları değiştiremez, bir web uygulaması disk silemez, bir operatör yalnızca ilgili servisi yeniden başlatabilir. Böylece bir hesap ele geçirildiğinde saldırganın eline geçen "patlama yarıçapı" en aza iner.

Mikro segmentasyon. Ağ, tek büyük bir güvenli bölge değil, her biri kendi kapısı olan küçük bölmelere ayrılır. Web sunucusu yalnızca uygulama sunucusuyla, o da yalnızca veritabanıyla konuşabilir; gereksiz her yol kapalıdır. Bir bölme düşse bile diğerlerine sıçramak ayrı bir engelle karşılaşır.

Kimlik merkezlilik. Güvenlik kararının merkezinde artık IP adresi ya da ağ konumu değil, kimlik vardır. "Şu ağdan geliyor, o halde güvenli" mantığı yerini "şu kişi, şu cihazla, şu koşulda erişmek istiyor" mantığına bırakır. Ağ konumu olsa olsa bir sinyaldir; tek başına yeterli değildir.

Bu dört ilke birbirini besler. Kimlik merkezlilik olmadan sürekli doğrulama havada kalır; en az yetki olmadan mikro segmentasyonun etkisi sınırlıdır. Zero trust'ı gerçek kılan, bu dördünün bir arada çalışmasıdır. Sağlam bir zemin için önce sunucu güvenliğinin temellerini oturtmak, sonra bu ilkeleri üzerine inşa etmek en sağlıklı yoldur.

Kimlik Merkezli Erişim ve Güçlü Kimlik Doğrulama#

Zero trust yolculuğu neredeyse her zaman kimlikle başlar, çünkü diğer üç ilkenin de dayanağı odur. Kimliği güvenilir biçimde doğrulayamıyorsanız, kime hangi yetkiyi verdiğinizin, hangi cihazın bağlandığının bir anlamı kalmaz. Bu yüzden ilk somut adım, tek başına parolayı terk edip çok faktörlü doğrulamayı zorunlu hale getirmektir.

Sunucu erişiminde bunun en temiz karşılığı, parolayla SSH girişini tamamen kapatıp anahtar tabanlı kimlik doğrulamaya geçmektir. Parolalar tahmin edilebilir, sızabilir ve kaba kuvvetle denenebilir; SSH anahtarları ise pratikte denenemez. /etc/ssh/sshd_config içinde şu ayarlar, "kimlik kanıtlanmadan kapı açılmaz" ilkesini işletir:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthenticationMethods publickey

Bu yapılandırma parolayla girişi tümden reddeder, root ile doğrudan girişi kapatır ve yalnızca geçerli bir açık anahtar sunan bağlantıyı kabul eder. Kritik sunucularda bir adım öteye geçip SSH'a ek olarak TOTP tabanlı ikinci faktör de ekleyebilirsiniz; böylece anahtar dosyası çalınsa bile tek başına yetmez.

İnsan kimliklerinin ötesinde, uygulama ve servis kimlikleri de aynı disipline tabidir. Bir uygulamanın veritabanına "her şeyi yapabilen" bir hesapla bağlanması, kimlik merkezli düşüncenin tam tersidir. Onun yerine her uygulamaya, yalnızca dokunması gereken tabloya ve yalnızca yapması gereken işleme izin veren kısıtlı bir hesap tanımlarsınız:

CREATE USER 'blog_app'@'10.0.2.15' IDENTIFIED BY 'guclu-parola';
GRANT SELECT, INSERT, UPDATE ON blog.* TO 'blog_app'@'10.0.2.15';
-- DROP, ALTER, GRANT ve diğer tabloların hepsi bilinçli olarak dışarıda
FLUSH PRIVILEGES;

Burada dikkat edin: hesap yalnızca belirli bir iç IP'den (10.0.2.15) bağlanabiliyor ve yalnızca blog veritabanında okuma/yazma yapabiliyor. Bu, kimlik doğrulama ile en az yetkinin veritabanı katmanında buluştuğu noktadır. Panelinizde barındırdığınız hesaplarda benzer bir titizliği uygulamak için hosting ve veritabanı kullanıcı yetkileri konusundaki rehberlerimiz iyi bir başlangıç sağlar.

Mikro Segmentasyon ile Ağı Bölmek#

Kimliği çözdükten sonra sıra, saldırganın tek bir noktadan tüm sisteme yayılmasını engellemeye gelir. Klasik modelde iç ağdaki her sunucu birbiriyle serbestçe konuşabilir; bir makine düştüğünde gerisi de düşer. Mikro segmentasyon, bu serbestliği ortadan kaldırır ve her servis çiftinin arasına "gerçekten konuşmaları gerekiyor mu?" sorusunu koyar.

En temel seviyede bu, sunucu güvenlik duvarını "varsayılan reddet" (default deny) mantığıyla yapılandırmak demektir. Yani her şeyi açıp tehlikelileri kapatmaya çalışmazsınız; her şey kapalı başlar, yalnızca gereken portu, yalnızca gereken kaynağa açarsınız. Web sunucusunda yalnızca 80/443, veritabanı sunucusunda yalnızca uygulama sunucusundan gelen 3306 açık olmalıdır:

# Varsayılanı reddet, sonra yalnızca gerekli yolları aç
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH yalnızca yönetim ağından
iptables -A INPUT -p tcp -s 10.0.9.0/24 --dport 22 -j ACCEPT
# MySQL yalnızca uygulama sunucusundan
iptables -A INPUT -p tcp -s 10.0.2.15 --dport 3306 -j ACCEPT

Bu kurallarla veritabanı sunucusu, internetten hiçbir doğrudan bağlantı kabul etmez; sadece bilinen uygulama sunucusuyla ve sadece yönetim ağıyla konuşur. Bir saldırgan web sunucusunu ele geçirse bile, veritabanına ancak uygulamanın kısıtlı hesabıyla ve yalnızca izin verilen sorgularla ulaşabilir.

Uygulama katmanında mikro segmentasyonun bir başka yüzü, ters vekil (reverse proxy) üzerinde erişimi kaynak ve kimliğe göre daraltmaktır. Örneğin bir yönetim paneline yalnızca ofis ağından ve geçerli bir istemci sertifikasıyla erişilmesini istiyorsanız, Nginx bunu kolayca uygular:

location /yonetim/ {
    # Yalnızca yönetim ağı
    allow 10.0.9.0/24;
    deny all;

    # İstemci sertifikası (mTLS) zorunlu
    ssl_verify_client on;
    ssl_client_certificate /etc/nginx/ca/internal-ca.crt;

    proxy_pass http://127.0.0.1:8080;
}

Burada karşılıklı TLS (mTLS) devreye girer: yalnızca sunucu değil, istemci de kimliğini bir sertifikayla kanıtlar. Bu, "ağdan geldi diye güvenme, kimliğini de kanıtlasın" ilkesinin ağ trafiğine yansımasıdır. Sertifika altyapısı ve TLS yapılandırması konusunda güçlü bir zemin için SSL sertifikası çözümlerimiz ve internete açık uygulamaları koruyan web uygulama güvenlik duvarı (WAF) hizmetimiz, mikro segmentasyonu tamamlayan katmanlardır.

Cihaz Doğrulama ve Erişim Politikaları#

Zero trust'ta kimliğin doğru olması yeterli değildir; o kimliğin bağlandığı cihazın da sağlıklı olması gerekir. Doğru kullanıcı, güncellemeleri yapılmamış, disk şifrelemesi kapalı, virüslü bir dizüstü bilgisayardan bağlanıyorsa, o erişim yine risklidir. Bu yüzden olgun zero trust kurulumlarında erişim kararı bir "politika motoru" tarafından, kimlik ve cihaz sinyalleri birlikte değerlendirilerek verilir.

Bu politikaları soyut bir fikir olmaktan çıkarıp yazılı, denetlenebilir kurallara dönüştürmek işin özüdür. Aşağıdaki gibi bir politikayı düşünün; bu, birçok zero trust ağ geçidinin arka planda değerlendirdiği mantığın okunabilir bir temsilidir:

politika: uretim-veritabani-erisimi
kaynak: db-uretim
kosullar:
  kimlik:
    grup: veritabani-yoneticileri
    mfa: zorunlu
  cihaz:
    yonetiliyor: true
    disk_sifreleme: acik
    isletim_sistemi_guncel: true
  baglam:
    izin_verilen_saatler: "08:00-20:00"
    izin_verilen_ulkeler: [TR]
karar: izin_ver
aksi_halde: reddet_ve_uyar

Bu politika şunu söyler: üretim veritabanına yalnızca "veritabanı yöneticileri" grubundaki, çok faktörlü doğrulamayı geçmiş bir kimlik; yalnızca yönetilen, diski şifreli ve güncel bir cihazdan; yalnızca mesai saatlerinde ve Türkiye'den erişebilir. Bu koşullardan biri bile sağlanmazsa erişim reddedilir ve olay bir uyarı üretir. Dikkat edin, karar tek bir faktöre değil, kimlik + cihaz + bağlamın kesişimine dayanır. İşte "sürekli doğrulama" ilkesinin somut hali budur.

Küçük ve orta ölçekli kurulumlarda bu düzeyde bir politika motoruna ihtiyacınız olmayabilir; ama fikrini uygulayabilirsiniz. Yönetim erişimini belirli IP aralıklarıyla sınırlamak, mTLS zorunlu kılmak, mesai dışı girişlere ek doğrulama eklemek ve tüm erişimleri merkezi olarak loglamak, aynı zihniyetin daha hafif versiyonlarıdır. Cihaz tarafında ise güncel işletim sistemi, aktif güvenlik duvarı ve disk şifrelemesi gibi asgari şartları ekip için bir standart haline getirmek, "cihaz doğrulama" ilkesinin pratik başlangıcıdır.

Pratikte Nereden Başlanır#

Zero trust'ı bir gecede kuramazsınız ve buna gerek de yoktur. Doğrusu, aşamalı bir geçiştir: en kritik kaynakları belirleyip önce onların etrafına sıkı halkalar örer, zamanla kapsamı genişletirsiniz. İşte gerçekçi bir yol haritası.

İlk olarak envanter çıkarın. Hangi sunucular, uygulamalar, veritabanları ve servisler var; kim neye erişiyor? Göremediğiniz bir şeyi koruyamazsınız. İkinci olarak kimliği güçlendirin: tüm yönetici hesaplarında çok faktörlü doğrulamayı zorunlu kılın, SSH'ı anahtar tabanlı yapın, paylaşılan root ve ortak hesaplardan kurtulun. Üçüncü olarak en az yetkiyi uygulayın: her hesabın gerçekten neye ihtiyacı olduğunu gözden geçirip fazlalıkları kesin. Dördüncü olarak ağı segmentleyin: güvenlik duvarını "varsayılan reddet" yapın, servisler arası gereksiz yolları kapatın. Beşinci olarak görünürlük kurun: erişim loglarını merkezileştirin ki anormal davranışı fark edebilesiniz.

Bu adımların çoğu için özel bir "zero trust ürünü" gerekmez; elinizdeki araçlarla başlayabilirsiniz. Örneğin iç servislerin birbirini genel internet üzerinden değil, yalnızca özel ağdan görmesini sağlamak için split-horizon DNS gibi basit teknikler bile segmentasyonu güçlendirir:

; İç DNS — servisler birbirini yalnızca özel IP'den çözer
db.dahili.example.  IN  A  10.0.2.20
api.dahili.example. IN  A  10.0.2.15
; Bu kayıtlar dışarıdaki çözücülere hiç yayınlanmaz

Zero trust'a geçerken sık yapılan bir hata, her şeyi aynı anda değiştirmeye çalışmaktır. Bunun yerine tek bir kritik sistemle (örneğin üretim veritabanı ya da yönetim paneli) başlayın, orada halkaları tam oturtun, öğrendiklerinizi bir sonraki sisteme taşıyın. Yönetimini kendiniz üstlenmek istemediğiniz sunucularda sunucu yönetimi hizmetimiz sertleştirme ve erişim kontrolü katmanlarını sizin adınıza kurabilir; kendi altyapınızı sıfırdan tasarlıyorsanız VDS sunucu çözümlerimiz izole, tam kök yetkili bir zemin sunar. Konteyner tabanlı uygulamaları segmentli bir ortamda çalıştırmak isteyenler için ise App Center hazır kurulumlar sağlar.

Zero Trust Hakkında Yaygın Yanılgılar#

Zero trust popülerleştikçe, etrafında birkaç yanlış anlama da yaygınlaştı. Bunları netleştirmek, gereksiz beklentiden ya da yanlış kararlardan korur.

Birincisi, "zero trust bir üründür, alıp kurarsın" yanılgısıdır. Böyle bir kutu yoktur; satıcılar "zero trust çözümü" diye ürün pazarlasa da bunlar yalnızca yaklaşımın bir parçasını (genellikle kimlik ya da ağ katmanını) uygular. İkincisi, "VPN'i kapatırsam zero trust olurum" yanılgısıdır. VPN'i kaldırmak zero trust'ın sonucu olabilir ama başlangıcı değildir; her uygulamaya kimlik ve cihaz temelli erişim koymadan VPN'i kaldırırsanız güvenliği azaltmış olursunuz. Üçüncüsü, "zero trust sadece büyük şirketler içindir" yanılgısıdır. İlkeler ölçekten bağımsızdır; tek bir sunucuda bile en az yetki, güçlü kimlik ve segmentasyon uygulanabilir ve fayda sağlar.

Sıkça Sorulan Sorular#

Zero trust bir ürün mü, yoksa yaklaşım mı?#

Zero trust bir güvenlik yaklaşımıdır, satın alınabilir tek bir ürün değildir. Piyasadaki "zero trust çözümü" etiketli araçlar yalnızca yaklaşımın belirli bir katmanını (kimlik doğrulama, ağ geçidi, cihaz denetimi gibi) uygular. Gerçek zero trust, bu araçların ve doğru mimari kararların bir araya gelmesiyle oluşur; yani bir kutuyu kurmakla değil, bir zihniyeti tüm sistemlerinize uygulamakla elde edilir.

VPN ile zero trust arasındaki fark nedir?#

VPN, klasik kale-hendek modelinin kapısıdır: kimliğinizi bir kez kanıtlarsınız, ardından iç ağa girer ve çoğu kaynağa serbestçe erişirsiniz. Zero trust ise böyle geniş bir güven vermez; her kaynağa erişimde kimliği, cihazı ve bağlamı yeniden değerlendirir. VPN "içeri girdin, artık serbestsin" derken, zero trust "her kapıda kimliğini yeniden göster" der. Zero trust olgunlaştığında VPN çoğu senaryoda gereksiz hale gelebilir.

Küçük bir işletme ya da tek sunucu için zero trust mantıklı mı?#

Evet, çünkü zero trust'ın ilkeleri ölçekten bağımsızdır. Tek bir sunucuda bile en az yetkiyle çalışan hesaplar tanımlamak, parola yerine SSH anahtarı ve iki faktörlü doğrulama kullanmak, güvenlik duvarını varsayılan reddet mantığıyla kurmak ve servisler arası gereksiz erişimi kapatmak mümkündür. Bunlar pahalı araçlar gerektirmez, sadece disiplinli kararlar gerektirir. Küçük bir kurulumda bu ilkeler, bir ihlalin tüm sistemi ele geçirmesini engelleyerek çok büyük fark yaratır.

Zero trust'a geçiş ne kadar sürer?#

Bu, aylara hatta bir yıla yayılabilen aşamalı bir yolculuktur ve bir gecede tamamlanması beklenmemelidir. Doğru yaklaşım, en kritik sistemleri (üretim veritabanı, yönetim panelleri gibi) önceliklendirip önce onların etrafına sıkı halkalar örmek, sonra kapsamı adım adım genişletmektir. Her aşamada kimlik, en az yetki ve segmentasyondan birini olgunlaştırırsınız. Aceleyle her şeyi aynı anda değiştirmek yerine küçük, denetlenebilir adımlarla ilerlemek hem güvenli hem sürdürülebilirdir.

Zero trust performansı ya da kullanıcı deneyimini yavaşlatır mı?#

İyi tasarlandığında hayır; hatta çoğu zaman deneyimi iyileştirir. Sürekli doğrulama, kullanıcının her seferinde parola girmesi anlamına gelmez; risk düşük olduğunda doğrulamalar arka planda, kullanıcı fark etmeden gerçekleşir. Ek doğrulama yalnızca bağlam şüpheli olduğunda (tanımadık cihaz, alışılmadık konum gibi) devreye girer. Böylece kullanıcılar günlük işlerinde daha az sürtünme yaşarken, gerçekten riskli anlarda sistem devreye girer. Kötü tasarlanmış her güvenlik önlemi gibi zero trust da yanlış kurgulanırsa can sıkabilir, ama doğrusu akıcıdır.

Kapanış#

Zero trust, güvenliği bir surla korunan kale olmaktan çıkarıp, her kapının kendi kimliğini sorduğu bir yapıya dönüştürmektir. "İçerisi güvenlidir" varsayımını terk edip her isteği yeniden doğruladığınızda, tek bir sızıntı artık tüm sistemin çöküşü anlamına gelmez; hasar, düştüğü bölmenin içinde kalır. Sürekli doğrulama, en az yetki, mikro segmentasyon ve kimlik merkezlilik; bu dört ilke bir arada, saldırganın en çok istediği şeyi, yani yanal hareketi ortadan kaldırır. Üstelik bu yolculuğa bugün elinizdeki araçlarla, tek bir kritik sistemi sertleştirerek başlayabilirsiniz.

Clou.TR olarak, bu ilkeleri altyapınıza taşırken yanınızda olacak katmanları tek çatı altında sunuyoruz. İzole ve tam kök yetkili bir zemin için VDS ve sunucu çözümlerimize, kimlik ve şifreleme katmanı için SSL sertifikalarımıza, internete açık uygulamalarınızı koruyan WAF hizmetimize, sertleştirmeyi bizim üstlenmemizi isterseniz sunucu yönetimi paketimize göz atabilir; işe önce sunucu güvenliğinin temellerini oturtup iki faktörlü doğrulamayı zorunlu kılarak başlayabilirsiniz. Güvenliği bir kapıya değil, her katmana yaymak; işte zero trust'ın size kazandırdığı en değerli alışkanlık budur.