Zero Trust ve SDP

Zero Trust – Sıfır Güven, bir kuruluşun ağ sınırları içindeki veya dışındaki her şey (bilgisayar, kullanıcı,…) için varsayılan bir güven seçeneğine sahip olmaması gerektiği fikrine dayanan güvenlik merkezli bir modeldir. Erişim izni verilmeden önce sisteme erişim sağlamaya ve bağlanmaya çalışan her şeyin kimliğinin doğrulanması gerekir. Zero Trust modeli ilk olarak 2010 yılında Forrester’da çalıştığı zamanda John Kindervag tarafından tasarlanmıştır.

Zero Trust yaklaşımındaki temel varsayımlar;

• Ağda (Network) her zaman düşmanca birileri bulunmaktadır
• Ağda her zaman harici ve dahili tehditler mevcuttur
• Ağın yerel olması, bir ağda güvene karar vermek için tek başına yeterli değildir
• Her cihaz, kullanıcı ve ağ trafiği doğrulanır ve yetkilendirilir
• Erişim politikaları dinamik olmalı ve olabildiğince çok veri kaynağından hesaplanmalıdır

Bu yazıda Zero Trust yaklaşımını referans ve Bulut Güvenliği İttifakı (Cloud Security Alliance – CSA ) bünyesinde geliştirilen Kara Bulut (Dark Cloud) olarak da isimlendirilen Yazılım Tanımlı Çevre (Software Defined Perimeter – SDP) çözüm mimarisini inceleyeceğiz.

Yazılım Tanımlı Çevre, günümüz ağlarının güvenliğini sağlama sorununun çözümüne yönelik çok farklı bir yaklaşımdır. CSA SDP Çalışma Grubu, cihaz/kullanıcı kimlik doğrulama, kimlik tabanlı erişim ve bunların dinamik olarak gerçekleştirilmesi yaklaşımını geliştirdi. SDP’deki güvenlik bileşenlerinin çoğu kanıtlanmış olsa da, bu üç bileşenin entegrasyonu oldukça yenidir.

SDP yaklaşımının önlediği tehditlerden bazıları;

• DoS (Denial of Service – Servisi devre dışı bırakma)
• Man in the middle (Kullanıcı ile uygulama arasına girme)
• Sunucu sorgulamaları (OWASP10)
• APT (Advanced Persistent Threat – İleri kalıcı tehditler)

SDP, mevcut DMZ yaklaşımı içerisindeki güvenlik araçlarına, Proxy, VPN, … gibi ilave bir araç olarak geliştirilmediğini belirtmek gerekir.  Tam tersine bu yeni yaklaşım hibrit bulut ortamına geçişte modası geçmiş bu araçlara bir alernatif sunmaktadır.

SDP yaklaşımındaki temel ilkeler:

• İlk prensip, kullanıcıların ve cihazlarının yeni Yazılım Tanımlı Çevrenin dışında yaşamasıdır. Bugün bir kurum düşünürseniz kendi kullanıcılarını kurumun hassas verilerinin bulunduğu sunucu ağı dışında tutmaya çalışmaktadır. Aynı zamanda kullanıcıların kurum ağına her zaman her yerden kolaylıkla erişebilmeleri de beklenmektedir.
• İkinci prensip, SDP, “önce kimlik doğrula, sonra bağlantı kur” yaklaşımı üzerine inşa edilmiştir. Çeşitli rollerdeki veya gruplardaki kullanıcıları bir ağ bölümüne bağlayan ve ardından yetkilendirme için uygulama düzeyinde izinlere dayanan geleneksel bir ağın aksine, SDP kişiselleştirilmiş izinler oluşturur; bir kullanıcının durumu değiştikçe, kişiselleştirilmiş izinler de değişir. Bu, çok daha ayrıntılı erişim kontrolüne izin verir.
• Üçüncü prensip, erişim kontrollerinin korunan ana bilgisayarlara mümkün olduğunca yakın yerleştirilmesidir. Kullanıcı bir kaynağa erişmeye çalıştığında – örneğin korumalı bir sunucuda bir web sayfası açarak, kullanıcı bilgisayarında çalışan yazılım isteği güvenli bir tünel aracılığıyla en yakın Ağ Geçidine (Gateway) yönlendirir. Bu durumda gerçek zamanlı – örneğin, “kullanıcının ağ konumuna göre erişimi kontrol etmek”  gibi ek politikalar uygulanabilir. Daha geniş ifade ile “kullanıcı özel ihtiyaçlarını karşılamak için aynı anda birden fazla ağ geçidine birden fazla bağlantı yapabilir”.

“Önce kimlik doğrula, sonra bağlan” yaklaşımında; kaynaklar, potansiyel tehlikeli keşifler için görünmez hale getirilir ve yalnızca yetkili kullanıcıların, ağ kaynaklarına bağlanabilmesini sağlar.  Bu da saldırı yüzeyini azaltır ve güvenliği önemli ölçüde artırır.

SDP yaklaşımında, erişim politikaları ile birden fazla ağ geçidini (erişim noktasına) kullanarak, hem veri merkezlerine hem de bulut ortamlarına kolaylıkla ve hızlıca uygulanması mümkündür. Bu durum SDP’nin hibrit ortamlarda kullanımını çok uygun hale getirmektedir.

Günümüzün Ağ modeli

Günümüzde kullandığımız ağ modellemesi 20 yaşın üzerindedir ve güncelleme zamanı gelmiştir.  SDP modelini incelemeden önce, birçok kuruluşu bu eski ağları “Yazılım Tanımlı Çevre” ile değiştirmesi gereken zamanın nihayet geldiğini anlamaya iten dört ana değişikliği hatırlatalım:

• Mobil çalışma ve kişisel cihazlar: İnsanların istedikleri zamanda istedikleri anda kendi seçtikleri bir cihazdan istedikleri bilgiye anında erişmek gibi bir beklentileri var. Belki şirket ağına sürekli bağlı bir cihazları yok ancak gün içinde sık sık bu ağa erişmeye ihtiyaçları var. Şirketin verdiği cihazların yanında kendi kullandıkları cihazlar var. Bazı durumlarda birisini bazı durumlarda diğerini kullanmak isteyebiliyorlar.
• Bulut: Şirketler bulut kullanımını belirli bir seviyede benimsedi. İşletmelerin bir kısmı tamamen bulut altyapısını kullanırken bir kısmı hibrit bir modelde hem kendi veri merkezlerinde hem de birden fazla bulut altyapısını kullanmaya devam edecektir.
• Karmaşıklık: Ağlar, hâlâ “dışarıdan” gelen tehditlere karşın korunması gereken “içeriden” bir şey olarak görülüyor. Gerçekte ağlar, giderek karmaşıklaşan siber kabusu güvence altına almak için onlarca farklı nokta çözümü içeren bir yığın yumağına dönüştü. Son 20 yılda şirketler kendi iş ihtiyaçları için gerekli teknolojilerden daha çok bu teknolojilerin barındırdığı hassas verilerin güvenliğini ve bu teknolojilerin kesintisiz çalışmasını sağlamak için ilave teknolojileri kullanmak zorunda bırakıldılar.
• Dış Tehditler: Yeni istismarların kullanılma hızı korkutucu. Bir teknolojide tespit edilen bir zaafiyetin aynı günde istismar edecek bir zararlının yayınlandığı bir zamanda yaşıyoruz. Geleneksel (çok siteli) bir ağın saldırı yüzeyi çok geniştir. Tüm erişimi gizleyerek ağı etkili bir şekilde görünmez yapmazsanız, tüm bu tehditler karşısında ağları savunmanız neredeyse imkansıza yakındır.

Peki bu nasıl mümkün olacak

Bugün bir çok firma farklı zero trust yaklaşımında faklı SDP çözümü geliştiriyor. Bu yazıda size CSA SDP çalışma grubu içinde geliştirilen ve ticarileşen bir çözümü anlatmaya çalışacağım.

Bir saldırıdan korunmanın en güvenli yolu gizlenmektir. Saldırganlar sizi göremediği sürece size saldıramazlar. Koruduğunuz her neresi yada ne ise kötü niyetli erişimlere görünmez kılıp, sadece  güvendiğinize emin olduğunuz (emin olmak için iki seviyeli kimlik doğrulama da dahil farklı doğrulama yöntemleri de kullanarak) erişimlere görünür kılarsanız büyük bir sorunu çözmüş olursunuz!

CSA SDP çözüm mimarisinin de temelinde bulunan sistemlerin gizlenmesi konusunda kullanılan yöntemin adı, Single  Packet Authorization – Tek Paket Yetkilendirme (SPA). SPA 2006 yılında Micheal B. Rush tarafından keşfedilen patentli bir buluştur. Dileyen bağlantıdan buluşun orjinal patentine erişip inceleyebilirler.

Klasik ağ erişim güvenliğinde erişimleri önce içeri alıp sonrasında yetki kontrolü yaparız. Erişim için trafik güvenlik duvarından geçer ve ilgili servise erişir ve bu aşamada yetki kontrolü yapılır. Bir çok siber saldırgan bu aşamada farklı yöntem ve tekniklerle bu yetki konrolünü bir şekilde geçebilir ve izinsiz olarak şirket ağına sızmayı başarabilir. Neyse ki yeni ve daha güvenilir bir alternatif var.

Aşağıda bu yeni yaklaşımın gösterimi var. Bu gösterim üzerinden adım adım ilerleyelim:

1. Kullanıcı kimlik doğrulaması: Erişim talebini yapan kullanıcı kimliği, şirket kimlik ve erişim yönetim sistemine (LDAP, Active Directory, Radius, SAML) bağlı “Denetleyici-Controller”  tarafından doğrulanır.
2. Denetleyici, erişim yetkilerini uygular: Denetleyici, kullanıcıya atanan yetkileri kullanıcı özniteliklerine, rollerine ve bağlamına göre uygular ve ardından kullanıcının erişmesine izin verilen kaynakları listeleyen imzalı yetki belirteçleri (tokens) yayınlar.
3. Kullanıcı kaynaklara erişir: Kimliği doğrulanmış kullanıcı artık bir “Ağ Geçidi – Gateway”nin arkasındaki korumalı kaynaklara erişebilir.
4. Ağ Geçidi, Kullanıcı Yetkilerini değerlendirir: Ağ Geçidi, Yetkileri gerçek zamanlı olarak değerlendirerek tüm koşulların karşılandığından emin olur. Örneğin: ağ konumu, günün saati, cihaz sağlığı veya güvenlik grupları gibi hizmet meta verileri. Kullanıcılardan tek seferlik parola gibi ek bilgiler istenebilir.
5. Ağ geçidi kaynağa bağlantıyı açar: Ağ Geçidi gerekli koşulların başarıyla karşılandığını belirlerse, kullanıcı tarafından belirtilen korumalı kaynağa bir bağlantı açar.
6. Süreçteki tüm adımlar günlüğe kaydedilir: Kimlik doğrulama ve yetkilendirme süreci boyunca, Kullanıcıya, kaynaklara ve Denetleyici ve Ağ Geçitleri tarafından alınan kararlara ilişkin tüm adımlar günlüğe kaydedilir. Bunun için kullanılabilecek entegre bir LogServer vardır veya loglar ek eylem için kurumsal SIEM uygulamalarına gönderilebilir.
7. Yeni hizmetleri algılar: Ağ Geçidi, yeni ana bilgisayarların / hizmetlerin oluşturulmasını sürekli olarak izler ve – bu meta veriye ve kullanıcının Yetkilerine dayanarak – gerektiği şekilde kullanıcı erişimini ayarlar.

Çözümün bileşenleri

Öncelikle bu yaklaşımda çözüm bileşenlerinin tamamı SPA yöntemi ile gizlenmiştir. Yukarda belirtilen yöntemler doğrultusun yetkili bir erişim bağlantı haricindeki tüm talepler reddedilir (deny all)

Denetleyici – Controller

Denetleyici normalde, kullanıcı kimliğini doğrulamaya yarayan ve kullanıcı özniteliklerinin ve grup üyeliklerinin kaynağı olarak hareket eden bir Kimlik Sağlayıcısına [IdP] bağlıdır. IdP, Denetleyici erişebildiği sürece herhangi bir yerde bulunabilir. Bu ve benzeri çözümlerde ; Aktif Dizin (Active Directory) , LDAP, Radius ve SAML tabanlı kimlik yönetim sistemleri desteklenir. Denetleyicide, sırayla denenecek birden fazla IdP belirtilebilir.

İstemci – Client

İstemci, SDP bileşenlerinde TCP (UDP) bağlantısını açmak için önceden paylaşılan belirli bir SPA anahtarı kullanmalıdır. Bu bir yazılımdır ve kullanıcıların bilgisayarlarında yada mobil cihazlarında çalışır.

İstemci, kimlik doğrulama bilgilerini isteyecektir ve isteğe bağlı olarak, aygıtın, Tek Kullanımlık Parola (OTP) kullanımını (müşteri tarafından yapılandırılan yerleşik veya harici bir Radius hizmetini kullanarak) içeren bir yerleşik prosedürden geçmesi gerekir. Cihaz, kullanıcı kimlik bilgilerini cihaz kimliğiyle yapıştıran ve böylece cihazı uygun olarak işaretleyen bir yerleşik tanımlama bilgisi alır.

Client, kendi özel / genel anahtar çiftini oluşturur ve buna bağlı olarak, İstemci ve Ağ Geçitleri arasındaki sonraki tüm karşılıklı (D) TLS bağlantıları için kullanılacak olan, CA tarafından imzalanmış bir İstemci Sertifikası alır. İstemcilerden Ağ Geçidine giden bu trafik, hem sistem kontrol verilerini hem de uygulama verilerini içerir.

Ağ Geçidi – Gateway

Başarılı bir kimlik doğrulamasından sonra, İstemci, aşağıdakileri içeren Denetleyicilerden biri tarafından imzalanmış bir dizi Site tabanlı Yetki belirteci alır;

• O site için mevcut tüm Ağ Geçitlerinin listesi
• O sitedeki kullanıcı için açıklayıcı ağ yetkilendirme Eylemlerinin listesi.

Site, birden fazla fiziksel konuma yayılabilen, korunan ana bilgisayarların mantıksal bir grubunu ifade eden özel bir terimdir.

İstemci, önceden belirlenmiş bir ağırlığa göre Sitedeki Ağ Geçitlerinden birine bağlanır. Ağ geçitlerinin önünde yük dengeleyiciye gerek yoktur. Ağ Geçidi, bu belirli kullanıcı oturumu için mikro özel güvenlik duvarı oluşturmak üzere herhangi bir tanımlanmış Eylemi kullanmadan önce belirtecin imzasını doğrular.

Ağ geçitleri, İstemcilerden 443 numaralı bağlantı noktasında karşılıklı (D) TLS trafiği alacak ve Denetleyiciler ve LogServer ile 444 numaralı bağlantı noktasında karşılıklı TLS trafiği gönderecek ve alacaktır. Ağ geçitleri arasında hiçbir iletişim yoktur. Ağ geçitleri birkaç farklı yolla konuşlandırılabilir.

Sektörde yeni bir dönemi açacak bu yaklaşımı ve bu yaklaşımı kullanan çözümleri iyi anlamamız gerektiğini düşünüyorum. Bu konuda farklı yaklaşımları ve çözümleri incelemeye ve sizlerle paylaşmaya devam edeceğiz.

Kaynaklar:

https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-and-zero-trust/

https://www.appgate.com/software-defined-perimeter/how-it-works