Zero Trust Erişim: Web Uygulamaları İçin Pratik Rehber

Zero trust nedir?

Zero trust, bir isteğin "iç ağdan geldiği" için güvenilir sayılmadığı, her erişimin kimlik ve bağlama göre ayrı ayrı doğrulandığı bir yaklaşımdır. ABD standart kurumu NIST bunu SP 800-207 belgesinde tanımlar: ağ konumu tek başına yetki vermez, kaynak başına erişim kararı verilir.

Web uygulamaları için sade bir okuması var: yönetim paneliniz internetten ulaşılabiliyorsa, herkes giriş formunu görür ve parola tahmin edebilir. Zero trust katmanı bu formun da önüne bir kapı koyar.

Neyi internete açık bırakmamalısınız?

Üç sınıf sistem sık hedef olur:

• Yönetim panelleri. /admin, /wp-admin, /dashboard gibi yollar otomatik tarayıcıların ilk baktığı yerlerdir. Parola zafiyeti veya yazılım açığı bir saldırıyı doğrudan yönetim yetkisine çevirir.
• Staging ve test ortamları. Genellikle üretimden daha az yamalıdır, gerçek veri kopyası içerebilir ve arama motorlarına sızabilir.
• İç araçlar. Grafana, Kibana, n8n, veritabanı yönetim arayüzleri gibi araçlar kendi kimlik doğrulamasıyla gelir ama bu doğrulamanın zayıf olduğu durumlar yaygındır.

Ortak nokta şudur: bu sistemlerin kullanıcı kitlesi küçük ve bellidir. Kimsenin anonim erişmesi gerekmiyorsa, anonim erişimi kapatmak en ucuz savunmadır.

VPN mi, kimlik farkında erişim katmanı mı?

VPN ağ düzeyinde çalışır: bağlanan kullanıcı ağın içine girer, o ağdaki her şeye ulaşabilir. Ayrıca her çalışana istemci kurmak ve yönetmek gerekir.

Kimlik farkında erişim katmanı uygulama düzeyinde çalışır: ziyaretçi uygulamaya giderken ters proxy araya girer, kullanıcıdan kimlik kanıtı ister ve doğrularsa isteği iletir. İstemci kurulumu yoktur; tarayıcı yeterlidir. Bu modelin mimarisi ters proxy rehberinde anlatılır.

İkisi birbirinin yerine geçmez. SSH ve veritabanı portları için VPN ya da güvenlik duvarı kuralı gerekir.

Kimlik kanıtı: e-posta OTP ve TOTP

E-posta OTP, kullanıcının adresine tek kullanımlık kod gönderir. Kurulumu kolaydır, ek uygulama gerektirmez. Zayıf noktası, posta kutusunun güvenliğine bağımlı olmasıdır; kod gecikebilir, spam klasörüne düşebilir.

TOTP, zamana bağlı tek kullanımlık paroladır (RFC 6238). Kimlik doğrulayıcı uygulama ile sunucu ortak bir sırrı paylaşır ve her ikisi de 30 saniye gibi bir zaman dilimine göre kod üretir. Altında HOTP vardır (RFC 4226). Ağ gerektirmez, posta kutusuna bağımlı değildir; ama sırrı taşıyan telefon kaybedilirse kurtarma planı gerekir.

İkisini birlikte istemek, saldırganın hem posta kutusunu hem de telefonu ele geçirmesini gerektirir. Hassas paneller için bu en makul seçenektir.

Kapsam: neyi, kimden, hangi yoldan?

İyi bir erişim kuralı üç soruyu yanıtlar:

1. Hangi yol? Tüm site mi, yoksa yalnızca /admin gibi bir önek mi? Kapsamı dar tutmak, herkese açık sayfaları bozmaz.
2. Hangi IP? Ofisin sabit adresini izin listesine eklemek, o adresten gelenlerin kimlik doğrulama adımını atlamasını sağlayabilir. İzin listesini eksiksiz tutun; ele geçirilmiş bir cihaz o IP'den bağlanırsa kapı açık kalır.
3. Hangi istisnalar? Webhook, ödeme geri çağrıları, sağlık kontrolleri ve mobil uygulama API'leri OTP giremez. Bunları hariç tutulan yollara koyun.

Oturum çerezi, kullanıcının her istekte yeniden doğrulanmasını önler. Çerezin ömrünü kısa tutun ve cihaz paylaşımı olan ortamlarda dikkatli olun.

Oturum çerezleri neden önemli?

Her istekte OTP girmek mümkün değildir. Doğrulamadan sonra proxy tarayıcıya bir oturum çerezi verir ve sonraki isteklerde yalnızca çerezi kontrol eder. Bu çerez parola gibi davranır: çalınırsa sahibi gibi erişilir. Üç önlem işe yarar: çerezi Secure ve HttpOnly işaretiyle vermek, süresini işinize uygun kısa tutmak ve ortak kullanılan bilgisayarlarda çıkış yapılmasını istemek.

Oturum süresi bir ödünleşimdir. Çok kısa süre kullanıcıyı her saat OTP girmeye zorlar ve insanlar kolaya kaçıp kapıyı kaldırtmaya çalışır. Çok uzun süre ise kayıp cihaz riskini büyütür. Hassas panellerde gün içi süre, düşük riskli staging için daha uzun süre makul bir başlangıçtır.

Atlatma riskleri

Kimlik katmanı, trafiğin gerçekten ondan geçtiği varsayımına dayanır. Saldırgan origin sunucunuzun IP'sini bulup doğrudan bağlanırsa Zero Trust'ı hiç görmez. Bu yüzden origin'i yalnızca proxy'ye açmak şarttır; ayrıntı için origin IP gizleme ve origin lock rehberine bakın.

Diğer riskler:

• Aşırı geniş istisna. /public/* gibi bir hariç tutma, yol normalleştirmesi yanlışsa /public/../admin ile aşılabilir. Yol eşleştirmesinin normalleştirilmiş yol üzerinde yapıldığını doğrulayın.
• Brute force. OTP uç noktasına sınırsız deneme açıksa kod tahmin edilebilir. Deneme ve gönderim sınırı şarttır.
• Zayıf kurtarma. "Kodu aldım" akışını sosyal mühendislikle atlatmak mümkünse katman işe yaramaz.

Bot trafiği için ayrı bir katman gerekir; bunu bot koruması rehberinde bulabilirsiniz.

Uygulama sırası

1. Korunacak yolu belirleyin (/admin, tüm staging).
2. Webhook ve API yollarını listeleyin, hariç tutun.
3. Yöntemi seçin; hassas panelde ikisini birlikte isteyin.
4. Ofis IP'lerini izin listesine ekleyin, yalnızca gerçekten sabit olanları.
5. Başka bir cihaz ve ağdan test edin; çıkış yapmış bir tarayıcıda panel yolunun kapıya düştüğünü görün.
6. Origin'i yalnızca proxy'ye açık hâle getirin.

Kaynaklar

• NIST SP 800-207: Zero Trust Architecture
• RFC 6238: TOTP
• RFC 4226: HOTP

İlgili ürün sayfaları:Teknoloji