Bulut bilişim hizmetleri kullanılmaya karar verildiğinde akla gelen öncelikli konulardan biri güvenliktir. Katıldığımız toplantılarda , etkinliklerde ,arkadaş grupları arasında -security- uzayıp giden tartışmaların başında geliyor. Azure kullanan ve gittiği her ortamda Azure konuşan biri olarak , Azure’un güvenlik ile ilgili neler sunduğu konusunu, “best practices” ‘ler çerçevesinde, bir yazı dizisi halinde ele almaya karar verdim.

“Azure Evreni!” içerisinde pek çok galaksinin yer aldığını söyleyebiliriz. Bizim odaklanacağımız galaksi “Azure Security Galaxy “ olacak. Bu galaksideki yolculuğumuz boyunca sevimli dostum “Eor” (İyoerr ) da bize eşlik ederek , uzay yolcuğumuzu keyiflendirecek. 🙂 Azure Security Galaxy’si içinde sıralanmış gezegenleri aşağıdaki şekilde görebilirsiniz. Bu yolculuğumuzda ilk durağımız “Network Security” gezegeni olacak.

https://cdn-images-1.medium.com/max/800/1*FgT5uyooqmjdDgxfJ5spGw.png

Azure Security Galaxy & Eor

Konumuza başlamadan önce “best practices “nedir buna biraz değinmekte fayda var. Best practices, en iyi uygulama, deneyimler ve araştırmalar yoluyla istenen sonuca bizi güvenli bir şekilde götürdüğü kanıtlanmış bir teknik veya metodolojidir. Bu terim sağlık, devlet yönetimi, eğitim sistemi, proje yönetimi, donanım ve yazılım , ürün geliştirme gibi pek çok alanda kullanılmaktadır.

Proje yönetimi konusunda uluslararası alanda tanınmış bir otorite olan Harold Kerzner’ın da belirttiği gibi best practise; “Those processes, procedures or practices which a company or project applies to other similar situations because they have proved to be valuable or successful in the past and they can be assumed to be successful again in the future.” bir şirketin veya projenin diğer benzer durumlara uyguladığı süreçler, usuller veya uygulamalardır. İnsanlar bu tekniklerin veya metodolojilerin peşinden gider , çünkü bunlar geçmişte başarılı olduklarını kanıtlamışlardır ve gelecekte de başarılı olacakları varsayılarak kullanılması öngörülür.

Bir metodoloji kendini kanıtladıktan sonra o ilgili alanda hemen yayılmaya başlar ve best practice olarak yayınlanır. Buna rağmen, kısa yol olma özelliği gösteren, vitamin niyetine bize iyi gelen 🙂 best practices’in bile bir organizasyon içinde veya bireylerde hayata geçmesi, yayılması çok kolay olmamaktadır. Amerikan Verimlilik ve Kalite Merkezi (American Productivity & Quality Center)’ine göre best practices’in benimsenmesinin önünde 3 temel engel bulunmaktadır:

1- Mevcut en yeni best practices hakkında bilgi eksikliği

2- Best practices’in benimsenmesi ile ilgili yapılacak değişiklikler için motivasyon eksikliği

3- Genel bilgi ve beceri eksikliği

Dostum Eor ve benim bu yazı dizisini hazırlamaktaki amacımız Azure Security konusunda best practices ile ilgili bir farkındalık oluşturmak. Bu best practices ‘in daha derinlerine inip, kendi organizasyonlarınızın içinde bulunduğu koşulları, mimariyi de göz önünde bulundurarak ,bunların nasıl hayata geçirilebileceği konusuna kafa yormanız gerekecektir.

Hazırsak yolculuğumuz başlıyor. EOR hazır mısın?

Azure Network Security Best Practices -1

https://cdn-images-1.medium.com/max/800/1*Zqbq9HjKb2lazZUYZAgvrA.png

Azure Network Security gezegenine bağlı 11 adet yıldız kümesi (=best practices) yer alıyor. Bunlar;

1. Alt ağları mantıksal olarak segmentlere ayır [Logically segment subnets]

2. Yönlendirme davranışını denetle [Control routing behavior]

3. Zorunlu Tünellemeyi Etkinleştir [Enable Forced Tunneling]

4. Sanal ağ cihazlarını kullanma [Use Virtual network appliances]

5. Güvenlik bölgesi oluşturma için DMZ’leri dağıtma [Deploy DMZs for security zoning]

5. Özel WAN bağlantılarıyla İnternet’e maruz bırakmaktan kaçının [Avoid exposure to the Internet with dedicated WAN links]

7. Çalışma süresini ve performansı optimize etme [Optimize uptime and performance]

8. Genel yük dengeleme kullan [Use global load balancing]

9. Azure Sanal Makinelerine RDP Erişimini Devre Dışı Bırak [Disable RDP Access to Azure Virtual Machines]

10. Azure Güvenlik Merkezi’ni etkinleştirin [Enable Azure Security Center]

11. Veri merkezinizi Azure’ye taşı [Extend your datacenter into Azure]

 

https://cdn-images-1.medium.com/max/800/1*zxy1hkaq-YJMdMTwTSOg3Q.png

 

Eor…! Acımasız açıklamalar yapmaktan gerçekten hoşlanıyorsun. Bu gerçekler senin geçmiş deneyimlerin olduğu için seni saygıyla dinlemekten başka çare bırakmıyorsun bize. Eor’un aslında karanlık bir geçmişi var. Onu da ayrıca ele alacağız. 🙂

Azure Virtual Network (sanal ağ) konusunda daha önce yazmış olduğum yazıya buradan erişebilirsiniz. Kısaca değinecek olursak, Azure VNet sanal bir ağ yapılandırmasıdır. Ağa bağlı aygıtlar arasında TCP/IP tabanlı iletişime izin verir. Bunun için sanal ağ arabirim kartlarını (NIC) sanal ağa bağlamamıza izin verir. Azure VNet’e bağlı virtual machine, aynı Azure VNet’teki kaynaklara, farklı Azure VNet kaynaklarına, internete ve onprem network’e erişebilir. Network security best practices ‘i -ki biz onlara konunun önemi sebebiyle “yıldız kümesi” adını vermiştik — biraz daha detaylı bir biçimde ele almaya başlayalım.

1. Logically segment subnets

Azure VNet, onprem ağınızdaki LAN’a (Local Area network) benzer ve tüm Azure Virtual Machine’lerinizi yerleştirebileceğiniz tek bir özel IP adresi alanına dayalı bir ağ oluşturmanızı sağlar. Burada kullanabileceğiniz IP adress alanları şunlardır:

· Sınıf A (10.0.0.0/8)

· Sınıf B (172.16.0.0/12)

· Sınıf C (192.168.0.0/16)

İşte bu blokları subnet (Cisco’daki karşılığı VLAN)’lere bölüyoruz.

Ayrıca subnetler (alt ağlar) oluşturmak istediğinizde CIDR (Classless Inter-Domain Routing) tabanlı subnet oluşturma ilkelerini kullanabilirsiniz. Subnetler arasındaki routing otomatik olarak gerçekleşir, yani bunun için manuel işlem yapmanıza gerek yoktur. Bu da şu demektir: Azure Virtual Network’te oluşturduğunuz subnetler arasında hiçbir ağ erişim denetimi yoktur. İşte tam bu noktada network access control için NSG (Network Security Group) ’yi kullanmanız önerilir. NSG’ler basit bir stateful packet inspection(SPI =durum denetlemeli paket incelemesi) cihazlarıdır.

NSG bir subnet’e veya bir Vnet içindeki tek bir sanal makineye uygulanabilir. NSG ile ağ trafiğine izin verme / reddetme(allow/deny) kuralları oluşturmak için şu 5 yaklaşımı kullanır:

· Kaynak IP (source IP)

· Kaynak bağlantı noktası, (source port)

· Hedef IP (destination IP)

· Hedef bağlantı noktası (destination port)

· Katman 4 protokolü (Layer 4 protocol)

https://cdn-images-1.medium.com/max/800/1*vpXSMsJqOa8m_Qwy3YCz1w.png

2. Yönlendirme davranışını denetle [Control routing behavior]

Azure VNet’e bağlı bir Azure VM, farklı subnet’te olsa bile , diğer Azure VM’ler ile iletişim halinde olabilir demiştik. Böylece Azure VNet’teki VM’ler hem birbirleriyle hem de internet ile iletişim kurabilirler. Bu pek çok deployment senaryosu için kullanışlı gibi görünse de routing konfigurasyonu yapmanız doğru bir yaklaşım olacaktır. Azure VNet üzerinde yapabileceğiniz routing kontrolü kritik bir öneme sahiptir. Hatalı bir yönlendirmenin sonuçları istenmeyen durumlara yol açabilir. Sanal makinede host edilen uygulama veya servisler bağlanmasını istemediğiniz cihazlara bağlanarak -ki bu senaryonun arkasında genelde saldırganlar olur- sisteminiz için ciddi bir tehdit oluşturabilir.

3– Zorunlu Tünellemeyi Etkinleştir [Enable Forced Tunneling]

Forced tunneling, kullandığınız servislerin internete bağlı cihazlarla bağlantı kurmasına izin vermemek amacıyla kullanabilceğiniz bir mekanizmadır. Forced tunneling etkinleştirdiğinizde, internete yapılan tüm bağlantılar, on-prem gateway üzerinden force edilir. Azure VNet, VM’lerin default olarak, internet trafiğini başlatmasına izin verir. Bu durum, VM’in saldırı yüzeyini arttırabilir ve bu da ciddi bir güvenlik riski oluşturur. Azure VNet ile onprem ağlarınız arasında bağlantı varsa forced tunneling’i etkinleştirmeniz önerilir.

https://cdn-images-1.medium.com/max/800/1*ihaGd-c-KuuEvII21JoBXg.png

Yukarıdaki resimde forced tunelling ‘in nasıl çalıştığını görebilirsiniz. Şekil, onprem’deki bir VPN cihazı ile Azure arasında kurulan S2S VPN bağlantısını göstermektedir. Frontend subnet internetten gelen müşteri isteklerini doğrudan kabul edip yanıt verebiliyor ve bu subnet için forced tunnelling işlemi yapılmıyor. Mid-tier (application server) ve Backend( database server) subnet için forced tunnelling konfigure ediliyor ve bu iki subnete gelen trafik S2S VPN tunel aracılığı ile onprem’deki gateway üzerine yönlendiriliyor. Forced tunelling konfigurasyonu Azure Powershell ile yapabiliyor.

Yolculuğun ikinci bölümünde başlangıç noktamız, best practise’lerden 4. yıldız kümesi olacak. Yazının başlangıcında dostum Eor yanımdaydı ancak birden ortadan kayboldu ve sanırım bazı gizemli olaylar peşinde. 4. Yıldız kümesine bizden önce gitmiş olmalı. Bakalım Eor yeni varış noktamızda bizi nelerle karşılayacak. 🙂

https://cdn-images-1.medium.com/max/800/1*YCLoE4nbZbxJH09KvCSPyg.png

Life is good !

Kaynak: https://docs.microsoft.com/en-us/azure/security/security-network-overview

 

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Fill out this field
Fill out this field
Lütfen geçerli bir e-posta adresi girin.
You need to agree with the terms to proceed