Bulutta yerel uygulamalar için Azure güvenliği

Tavsiye

Bu içerik, .NET Docs veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Azure için Bulut Yerel .NET Uygulamaları Tasarlama adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

Azure eKitap kapak küçük resmi için Buluta Özel .NET uygulamaları.

Bulutta yerel uygulamalar geleneksel uygulamalara göre hem daha kolay hem de güvenli hale getirilebilir. Dezavantajı ise daha küçük uygulamaların güvenliğini sağlamalı ve güvenlik altyapısını oluşturmak için daha fazla enerji ayırmanız gerekir. Çoğu hizmet dağıtımında programlama dillerinin ve stillerinin heterojen doğası, birçok farklı sağlayıcının güvenlik bültenlerine daha fazla dikkat etmeniz gerektiği anlamına da gelir.

Diğer taraftan, her biri kendi veri deposuna sahip küçük ölçekli hizmetler bir saldırının kapsamını sınırlar. Bir saldırgan bir sistemin güvenliğini tehlikeye atarsa, tek parçalı bir uygulamada olduğundan başka bir sisteme atlamak muhtemelen daha zordur. İşlem sınırları güçlü sınırlardır. Ayrıca, bir veritabanı yedeklemesi ortaya çıkarsa, bu veritabanı yalnızca bir veri alt kümesi içerdiğinden ve kişisel verileri içerme olasılığı düşük olduğundan zarar daha sınırlıdır.

Tehdit modelleme

Avantajlar buluta özel uygulamaların dezavantajlarından daha ağır bassa da, aynı bütünsel güvenlik zihniyetinin izlenmesi gerekir. Güvenlik ve güvenli düşünme, geliştirme ve operasyon hikayesinin her adımının bir parçası olmalıdır. Bir uygulamayı planlarken şu soruları sorun:

• Bu verilerin kaybolmasının etkisi ne olur?
• Bu hizmete eklenen hatalı verilerden kaynaklanan hasarı nasıl sınırlayabiliriz?
• Bu verilere kimlerin erişmesi gerekir?
• Geliştirme ve yayın süreciyle ilgili denetim ilkeleri var mı?

Tüm bu sorular tehdit modelleme adlı bir sürecin parçasıdır. Bu süreç sisteme yönelik tehditlerin ne olduğu, tehditlerin ne kadar olası olduğu ve bunların olası zararları sorusunu yanıtlamaya çalışır.

Tehdit listesi oluşturulduktan sonra bunların hafifletmeye değip değmeyeceğine karar vermeniz gerekir. Bazen bir tehdit o kadar olasılık dışıdır ve planlaması o kadar pahalıdır ki, buna enerji harcamaya değmez. Örneğin, bazı durum düzeyinde aktörler milyonlarca cihaz tarafından kullanılan bir işlemin tasarımına değişiklikler ekleyebilecektir. Şimdi, Halka 3'te belirli bir kod parçasını çalıştırmak yerine bu kod Halka 0'da çalıştırılır. Bu işlem, hiper yöneticiyi atlayarak çıplak metal makinelerde saldırı kodunu çalıştırabilen bir açıktan yararlanılmasına olanak tanır ve bu, bu donanımdaki tüm sanal makinelere yönelik saldırılara izin verir.

Değiştirilen işlemcilerin, mikroskobu ve bu işlemcinin silikon tasarımı hakkında gelişmiş bilgi olmadan algılanmaları zordur. Bu senaryo olası değildir ve hafifletmek pahalıdır, bu nedenle büyük olasılıkla hiçbir tehdit modeli bunun için açık koruması oluşturulmasını önermez.

Id bozuk erişim denetimleri (URL'de Id=2 ile Id=3 değiştirerek) veya SQL enjeksiyonu gibi artan numaralandırma saldırılarına izin veren daha olası tehditlere karşı koruma oluşturmak daha çekicidir. Bu tehditlere yönelik önlemler, şirketin itibarını zedeleyen utanç verici güvenlik açıklarını önlemek için oldukça makuldür.

En az ayrıcalık ilkesi

Bilgisayar güvenliğinde temel fikirlerden biri En Az Ayrıcalık ilkesidir (POLP). Bu aslında dijital veya fiziksel güvenlikle ilgili temel bir fikirdir. Kısacası, ilke, herhangi bir kullanıcı veya işlemin görevini yürütmek için mümkün olan en az sayıda haka sahip olması gerektiğidir.

Örneğin, bankadaki vezneleri düşünün: kasaya erişmek yaygın olmayan bir etkinliktir. Dolayısıyla, sıradan bir vezneci kasayı kendisi açamaz. Erişim elde etmek için, ek güvenlik denetimleri yapan bir banka yöneticisi aracılığıyla isteklerini yükseltmeleri gerekir.

Bir bilgisayar sisteminde, veritabanına bağlanan bir kullanıcının hakları harika bir örnektir. Çoğu durumda, hem veritabanı yapısını oluşturmak hem de uygulamayı çalıştırmak için kullanılan tek bir kullanıcı hesabı vardır. Aşırı durumlar dışında, uygulamayı çalıştıran hesabın şema bilgilerini güncelleştirme özelliğine ihtiyacı yoktur. Farklı ayrıcalık düzeyleri sağlayan birkaç hesap olmalıdır. Uygulama yalnızca tablolardaki verilere okuma ve yazma erişimi veren izin düzeyini kullanmalıdır. Bu tür bir koruma, veritabanı tablolarını bırakmayı veya kötü amaçlı tetikleyicileri tanıtmayı amaçlayan saldırıları ortadan kaldırır.

Bulutta yerel bir uygulama oluşturmanın hemen her bölümü, en az ayrıcalık ilkesini anımsama avantajından yararlanabilir. Rol tabanlı erişim denetiminde (RBAC) güvenlik duvarlarını, ağ güvenlik gruplarını, rolleri ve kapsamları ayarlarken bu seçeneği kullanabilirsiniz.

Sızma testi

Uygulamalar daha karmaşık hale geldikçe, saldırı vektörlerinin sayısı alarm hızında artar. Tehdit modelleme, sistemi oluşturan aynı kişiler tarafından yürütülme eğiliminde kusurludur. Birçok geliştiricinin kullanıcı etkileşimlerini hayal etme ve ardından kullanılamaz kullanıcı arabirimleri oluşturma konusunda sorun yaşadığı gibi çoğu geliştirici de her saldırı vektörünü görmekte zorlanır. Sistemi oluşturan geliştiricilerin saldırı yöntemlerinde iyi bilgili olmaması ve önemli bir şeyi kaçırması da mümkündür.

Sızma testi veya "penetrasyon testi," sisteme saldırmak amacıyla dış aktörleri devreye sokmayı içerir. Bu saldırganlar, işletmenin başka bir bölümünden iyi güvenlik bilgilerine sahip bir dış danışmanlık şirketi veya diğer geliştiriciler olabilir. Sistemi devreden çıkarmaları için kendilerine carte blanche verilir. Sık sık düzeltme eki yapılması gereken kapsamlı güvenlik açıkları bulurlar. Bazen saldırı vektörü, CEO'ya yönelik bir kimlik avı saldırısını istismar etmek gibi tamamen beklenmedik bir şey olabilir.

Azure sürekli olarak Microsoft'un içindeki bir bilgisayar korsanı ekibi tarafından saldırılara maruz kaldı. Yıllar içinde, yıkıcı olabilecek onlarca saldırı vektörüne ilk onlar ulaşıp, onları dışarıdan sömürülmeden önce kapattılar. Bir hedef ne kadar cazip olursa, dış aktörlerin bu hedeften yararlanmaya çalışma olasılığı o kadar artar ve dünyada Azure'dan daha cazip olan birkaç hedef vardır.

İzleme

Bir saldırgan bir uygulamaya sızmayı denerse, bir uyarı olmalıdır. Sık sık, hizmetlerden gelen günlükler incelenerek saldırılar tespit edilebilir. Saldırılar başarılı olmadan önce tespit edilebilen belirgin izler bırakır. Örneğin, parolayı tahmin etmeye çalışan bir saldırgan bir oturum açma sistemine birçok istekte bulunur. Oturum açma sistemi çevresinde izleme, tipik erişim deseniyle aynı hizada olmayan garip desenleri algılayabilir. Bu izleme, işlem kişisini bir tür karşı önlemi etkinleştirmesi için uyarabilen bir uyarıya dönüştürülebilir. Son derece olgun bir izleme sistemi, istekleri engellemek veya yanıtları kısıtlamak için proaktif olarak kurallar ekleyerek bu sapmaları temel alan bir işlem bile gerçekleştirebilir.

Derlemenin güvenliğini sağlama

Güvenliğin genellikle göz ardı edildiği bir yer, derleme işlemi sırasındadır. Derleme, güvenli olmayan kod veya kaydedilmiş kimlik bilgilerini taramak gibi güvenlik denetimlerini çalıştırmalıdır ve aynı zamanda derlemenin kendisinin de güvenli olması gerekir. Derleme sunucusunun güvenliği aşıldıysa, ürüne rastgele kod eklemeye yönelik harika bir vektör sağlar.

Bir saldırganın bir web uygulamasında oturum açmış kişilerin parolalarını çalmak aradığını düşünün. Çekilen kodu değiştirerek oturum açma isteklerini başka bir sunucuya yansıtmak üzere bir oluşturma aşaması oluşturabilirler. Kod derlemeden bir sonraki geçtiğinde sessizce güncellenmiş olur. Kaynak kodu güvenlik açığı taraması, derlemeden önce çalıştığından bu güvenlik açığını yakalamaz. Aynı şekilde, derleme süreci adımları derleme sunucusunda bulunduğundan kod gözden geçirmesinde kimse bunu yakalamaz. İstismar edilen kod, parolaları topladığı üretim ortamına gider. Büyük olasılıkla derleme işlemi değişikliklerinin denetim günlüğü yoktur veya en azından denetimi izleyen kimse yoktur.

Bu senaryo, sisteme girmek için kullanılabilecek, görünüşte düşük değerli bir hedefin mükemmel bir örneğidir. Bir saldırgan sistemin çevresini ihlal ettikten sonra, izinlerini istedikleri yerde gerçek zarara neden olabilecek bir noktaya yükseltmenin yollarını bulmaya başlayabilir.

Güvenli kod oluşturma

.NET Framework zaten oldukça güvenli bir çerçevedir. Yönetilmeyen kodun bazı tuzaklarından, örneğin dizilerin sınırlarının dışına çıkmak gibi, kaçınır. Güvenlik açıklarını bulduklarında düzeltmek için etkin bir şekilde çalışma yapılır. Hatta araştırmacılara çerçevedeki sorunları bulmaları ve bunları kötüye kullanmak yerine raporlamaları için ödeme yapan bir hata ödülü programı bile vardır.

.NET kodunu daha güvenli hale getirmenin birçok yolu vardır. .NET için güvenli kodlama yönergeleri makalesi gibi yönergelerin takip edilmesi, kodun sıfırdan güvenli olduğundan emin olmak için atılması gereken makul bir adımdır. OWASP ilk 10, güvenli kod oluşturmaya yönelik bir diğer değerli kılavuzdur.

Derleme işlemi, kaynak koddaki sorunları üretime geçirmeden önce algılamak için tarama araçları koymak için iyi bir yerdir. Çoğu projenin başka paketlere bağımlılıkları vardır. Güncel olmayan paketleri tarayabilen bir araç, her gece yapılan derlemede sorunları yakalar. Docker görüntüleri oluştururken bile temel görüntüde bilinen güvenlik açıklarının olmadığından emin olmak yararlı olur. Denetlenecek bir diğer şey de kimsenin kimlik bilgilerini yanlışlıkla depolamamış olmasıdır.

Yerleşik güvenlik

Azure, çoğu kullanıcı için kullanılabilirlik ve güvenliği dengelemek için tasarlanmıştır. Farklı kullanıcıların farklı güvenlik gereksinimleri vardır, bu nedenle bulut güvenliğine yönelik yaklaşımlarında ince ayarlamalar yapmaları gerekir. Microsoft , Güven Merkezi'nde çok sayıda güvenlik bilgisi yayımlar. Bu kaynak, yerleşik saldırı azaltma teknolojilerinin nasıl çalıştığını anlamak isteyen profesyoneller için ilk durak olmalıdır.

Azure portalında , Azure Danışmanı bir ortamı sürekli tarar ve önerilerde bulunan bir sistemdir. Bu önerilerden bazıları kullanıcılardan tasarruf etmek için tasarlanmıştır, diğerleri ise bir depolama kapsayıcısının dünyaya açık olması ve Sanal Ağ tarafından korunmaması gibi güvenli olmayabilecek yapılandırmaları belirlemek için tasarlanmıştır.

Azure ağ altyapısı

Şirket içi dağıtım ortamında, ağ kurmaya çok fazla enerji ayrılmıştır. Yönlendiricilerin, anahtarların ve benzeri aygıtların kurulumu karmaşık bir iştir. Ağlar, bazı kaynakların diğer kaynaklarla konuşmasına ve bazı durumlarda erişimi engellemesine olanak sağlar. Geliştirme ortamından üretim ortamına erişimi kısıtlamak sık kullanılan bir ağ kuralıdır, bu şekilde tamamlanmamış bir kod parçasının beklenmedik şekilde çalışıp büyük miktarda veriyi silmesi ihtimali ortadan kaldırılır.

Varsayılan olarak, çoğu PaaS Azure kaynağı en temel ve izin veren ağ kurulumuna sahiptir. Örneğin, İnternet'te herkes bir uygulama hizmetine erişebilir. Yeni SQL Server örnekleri genellikle kısıtlanır, böylece dış taraflar bunlara erişemez, ancak Azure tarafından kullanılan IP adresi aralıklarına izin verilir. Bu nedenle, SQL sunucusu dış tehditlere karşı korunsa da, saldırganın yalnızca Azure'daki tüm SQL örneklerine yönelik saldırılar başlatabileceği bir Azure köprü ucu ayarlaması gerekir.

Neyse ki çoğu Azure kaynağı ayrıntılı erişim denetimine izin veren bir Azure Sanal Ağına yerleştirilebilir. Şirket içi ağların daha geniş dünyadan korunan özel ağlar oluşturma yöntemine benzer şekilde, sanal ağlar Da Azure ağı içinde bulunan özel IP adresleri adalarıdır.

Şekil 9-1. Azure'da bir sanal ağ.

Şirket içi ağların ağa erişimi yöneten bir güvenlik duvarına sahip olduğu gibi, sanal ağın sınırında da benzer bir güvenlik duvarı oluşturabilirsiniz. Varsayılan olarak, bir sanal ağdaki tüm kaynaklar İnternet'le konuşmaya devam edebilir. Yalnızca gelen bağlantılar bir tür açık güvenlik duvarı istisnası gerektirir.

Ağ kurulduysa, depolama hesapları gibi iç kaynaklar yalnızca Sanal Ağ üzerindeki kaynaklar tarafından erişime izin verecek şekilde ayarlanabilir. Bu güvenlik duvarı, söz konusu depolama hesabının anahtarları sızdırılırsa, saldırganlar sızdırılan anahtarlardan yararlanmak için buna bağlanamaz. Bu senaryo, en düşük ayrıcalık ilkesinin başka bir örneğidir.

Azure Kubernetes kümesindeki düğümler, Azure'da daha yerel olan diğer kaynaklar gibi bir sanal ağa katılabilir. Bu işlev Azure Container Networking Interface olarak adlandırılır. Aslında, sanal ağ içinde sanal makinelerin ve kapsayıcı görüntülerinin tahsis edildiği bir alt ağı tahsis eder.

En az ayrıcalık ilkesini örneklemeye devam ederken, bir Sanal Ağ içindeki her kaynağın diğer her kaynakla iletişim kurmasına gerek yoktur. Örneğin, depolama hesabı ve SQL veritabanı üzerinden web API'sini sağlayan bir uygulamada, veritabanı ve depolama hesabının birbiriyle konuşması pek olası değil. Aralarındaki tüm veri paylaşımları web uygulamasından geçer. Bu nedenle, iki hizmet arasındaki trafiği reddetmek için bir ağ güvenlik grubu (NSG) kullanılabilir.

Kaynaklar arasındaki iletişimi reddetme politikası, özellikle trafik kısıtlamaları olmaksızın Azure kullanan bir geçmişten gelenler için uygulaması can sıkıcı olabilir. Diğer bazı bulutlarda ağ güvenlik grupları kavramı çok daha yaygındır. Örneğin AWS'de varsayılan ilke, kaynakların NSG'deki kurallar tarafından etkinleştirilene kadar kendi aralarında iletişim kuramamalarıdır. Bunu geliştirmek daha yavaş olsa da, daha kısıtlayıcı bir ortam daha güvenli bir varsayılan değer sağlar. Özellikle izinleri yönetmek için Azure Resource Manager veya Terraform kullanmak, uygun DevOps uygulamalarından yararlanmak kuralları denetlemeyi kolaylaştırabilir.

Sanal Ağlar, şirket içi ve bulut kaynakları arasındaki iletişimi ayarlarken de yararlı olabilir. Sanal özel ağ, iki ağı sorunsuz bir şekilde birbirine bağlamak için kullanılabilir. Bu yaklaşım, tüm kullanıcıların yerinde olduğu senaryolar için herhangi bir ağ geçidi olmadan bir sanal ağ çalıştırmaya olanak tanır. Bu ağı kurmak için kullanılabilecek bir dizi teknoloji vardır. En basiti, birçok yönlendirici ile Azure arasında kurulabilen bir siteden siteye VPN kullanmaktır. Trafik şifrelenir ve İnternet üzerinden diğer trafikle bayt başına aynı maliyetle tünellenir. Daha fazla bant genişliği veya daha fazla güvenliğin tercih edildiği senaryolar için Azure, şirket içi ağ ile Azure arasında özel bağlantı hattı kullanan Express Route adlı bir hizmet sunar. Daha maliyetli ve oluşturulması zor ama aynı zamanda daha güvenlidir.

Azure kaynaklarına erişimi kısıtlamak için rol tabanlı erişim denetimi

RBAC, Azure'da çalışan uygulamalara kimlik sağlayan bir sistemdir. Uygulamalar, anahtarlar veya parolalar yerine veya bunlara ek olarak bu kimliği kullanarak kaynaklara erişebilir.

Güvenlik Sorumluları

RBAC'deki ilk bileşen bir güvenlik sorumlusudur. Güvenlik sorumlusu bir kullanıcı, grup, hizmet sorumlusu veya yönetilen kimlik olabilir.

Şekil 9-2. Farklı güvenlik sorumlusu türleri.

• Kullanıcı - Azure Active Directory'de hesabı olan tüm kullanıcılar bir kullanıcıdır.
• Grup - Azure Active Directory'den kullanıcı koleksiyonu. Bir grubun üyesi olarak, kullanıcı kendi rollerine ek olarak bu grubun rollerini de üstlenir.
• Hizmet sorumlusu - Hizmetlerin veya uygulamaların altında çalıştığı bir güvenlik kimliği.
• Yönetilen kimlik - Azure tarafından yönetilen bir Azure Active Directory kimliği. Yönetilen kimlikler genellikle Azure hizmetlerinde kimlik doğrulaması için kimlik bilgilerini yöneten bulut uygulamaları geliştirirken kullanılır.

Güvenlik ilkesi hemen hemen her kaynağa uygulanabilir. Bu açıdan, Azure Kubernetes içinde çalışan bir kapsayıcıya güvenlik sorumlusu atanarak Key Vault'ta depolanan gizli dizilere erişmesine olanak sağlanabilir. Azure İşlevi, çağıran bir kullanıcının JWT'sini doğrulamak üzere Active Directory örneğiyle konuşmasına olanak sağlayan bir izin alabilir. Hizmetler bir hizmet sorumlusuyla etkinleştirildikten sonra izinleri roller ve kapsamlar kullanılarak ayrıntılı olarak yönetilebilir.

Görevler

Bir güvenlik sorumlusu birçok rol üstlenebilir veya daha sartorial bir benzetme kullanarak birçok şapka giyebilir. Her rol, "Azure Service Bus uç noktasından iletileri okuma" gibi bir dizi izin tanımlar. Bir güvenlik sorumlusunun etkin izin kümesi, bir güvenlik sorumlusunun sahip olduğu tüm rollere atanan tüm izinlerin birleşimidir. Azure'da çok sayıda yerleşik rol vardır ve kullanıcılar kendi rollerini tanımlayabilir.

Şekil 9-3. RBAC rol tanımları.

Azure'da yerleşik olarak Sahip, Katkıda Bulunan, Okuyucu ve Kullanıcı Hesabı Yöneticisi gibi bir dizi üst düzey rol de bulunur. Sahip rolüyle, güvenlik sorumlusu tüm kaynaklara erişebilir ve başkalarına izin atayabilir. Katkıda bulunan tüm kaynaklara aynı erişim düzeyine sahiptir ancak izin atayamaz. Okuyucu yalnızca mevcut Azure kaynaklarını görüntüleyebilir ve Kullanıcı Hesabı Yöneticisi Azure kaynaklarına erişimi yönetebilir.

DNS Bölgesi Katkıda Bulunanı gibi daha ayrıntılı yerleşik rollerin hakları tek bir hizmetle sınırlıdır. Güvenlik sorumluları herhangi bir sayıda rol üstlenebilir.

Kapsamlar

Roller, Azure içindeki kısıtlı bir kaynak kümesine uygulanabilir. Örneğin, önceki bir Service Bus kuyruğundan okuma örneğine kapsam uygulayarak, izni tek bir kuyruğa daraltabilirsiniz: "Azure Service Bus uç noktasından blah.servicebus.windows.net/queue1 iletileri okuma"

Kapsam tek bir kaynak kadar dar olabilir veya tüm kaynak grubuna, aboneliğe ve hatta yönetim grubunun tamamına uygulanabilir.

Bir güvenlik sorumlusunun belirli bir izne sahip olup olmadığını test ederken rol ve kapsam birleşimi dikkate alınır. Bu birleşim güçlü bir yetkilendirme mekanizması sağlar.

Reddet

Daha önce RBAC için yalnızca "izin ver" kurallarına izin verilirdi. Bu davranış, bazı kapsamların oluşturulmasını karmaşık hale getirdi. Örneğin, bir güvenlik sorumlusunun gerekli olan depolama hesapları dışında tüm depolama hesaplarına erişmesine izin vermek, potansiyel olarak sonsuz bir depolama hesabı listesine açık izin vermektir. Her yeni depolama hesabı oluşturulduğunda, bu hesap listesine eklenmesi gerekir. Bu ek yönetim ek yükü kesinlikle arzu edilmezdi.

Reddetme kuralları izin verilen kurallardan önceliklidir. Artık aynı "bir hariç tümüne izin ver" kapsamını temsil eden iki kural "tümüne izin ver" ve "bunu belirli bir kuralı reddet" olarak gösterilebilir. Reddetme kuralları yalnızca yönetimi kolaylaştırmakla kalmaz, herkese erişimi reddederek fazladan güvenli kaynaklara da izin verir.

Erişimi denetleme

Tahmin edebileceğiniz gibi, çok sayıda rol ve kapsama sahip olmak, hizmet sorumlusunun etkin iznini belirlemeyi oldukça zorlaştırabilir. Bunun üzerine reddetme kuralları yığmak, yalnızca karmaşıklığı artırmaya hizmet eder. Neyse ki, herhangi bir hizmet sorumlusu için etkili izinleri gösterebilen bir izin hesaplayıcısı vardır. Genellikle Şekil 9-3'te gösterildiği gibi portaldaki IAM sekmesinde bulunur.

Şekil 9-4. Bir uygulama servisi için izin hesaplayıcısı.

Sırları güvenceye alma

Parolalar ve sertifikalar, saldırganlar için yaygın bir saldırı vektörleridir. Parola kırma donanımı, kaba kuvvet saldırısı gerçekleştirebilir ve saniyede milyarlarca parola tahmin etmeye çalışabilir. Bu nedenle, kaynaklara erişmek için kullanılan parolaların çok çeşitli karakterlerle güçlü olması önemlidir. Bu parolalar tam olarak hatırlaması neredeyse imkansız olan parola türleridir. Neyse ki Azure'daki parolaların herhangi bir insan tarafından bilinmesi gerekmez.

Birçok güvenlik uzmanı, kendi parolalarınızı korumak için parola yöneticisi kullanmanın en iyi yaklaşım olduğunu öne sürüyor . Parolalarınızı tek bir konumda merkezi hale getirse de, son derece karmaşık parolalar kullanılmasına ve her hesap için benzersiz olduklarından emin olunmasına da olanak tanır. Azure'da da aynı sistem mevcuttur: gizli bilgiler için merkezi bir depo.

Azure Key Vault

Azure Key Vault veritabanları, API anahtarları ve sertifikalar gibi öğelerin parolalarını depolamak için merkezi bir konum sağlar. Gizli Kasaya bir sır girildikten sonra, bir daha gösterilmez ve onu çıkarmak ve görüntülemek için gereken komutlar bilerek karmaşık yapılmıştır. Kasadaki bilgiler yazılım şifrelemesi veya FIPS 140-2 Düzey 2 doğrulanmış Donanım Güvenlik Modülleri kullanılarak korunur.

Anahtar kasasına erişim RBAC'ler aracılığıyla sağlanır; yani yalnızca herhangi bir kullanıcı kasadaki bilgilere erişemez. Diyelim ki bir web uygulaması Azure Key Vault'ta depolanan veritabanı bağlantı dizesine erişmek istiyor. Erişim kazanmak için uygulamaların bir hizmet sorumlusu kullanarak çalıştırılması gerekir. Bu varsayılan rol kapsamında, sırları kasadan okuyabilirler. Örneğin, bir uygulamanın kasaya erişimini daha da sınırlayan bir dizi farklı güvenlik ayarı vardır, bu nedenle sadece gizli verileri okuyabilir, ancak güncelleştiremez.

Anahtar kasası erişimi izlenebilir, bu sayede yalnızca beklenen uygulamaların kasaya eriştiğinden emin olunur. Günlükler Azure İzleyici'ye yeniden entegre edilebilir, böylece beklenmeyen koşullar ile karşılaşıldığında uyarı ayarlama özelliği etkinleştirilir.

Kubernetes

Kubernetes'in içinde, küçük gizli bilgileri korumak için benzer bir hizmet vardır. Kubernetes Gizli Dizileri, tipik kubectl yürütülebilir dosya aracılığıyla ayarlanabilir.

Gizli dizi oluşturmak, depolanacak değerlerin base64 sürümünü bulmak kadar basittir:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Ardından, aşağıdaki örneğe benzer şekilde görünen ve adı secret.yml olan bir gizli dosyaya ekleyin:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Son olarak, aşağıdaki komut çalıştırılarak bu dosya Kubernetes'e yüklenebilir:

kubectl apply -f ./secret.yaml

Bu gizli bilgilere sahip diziler daha sonra birimlere monte edilebilir veya ortam değişkenleri aracılığıyla kapsayıcı işlemlere sunulabilir. Uygulama oluşturmaya yönelik On iki faktörlü uygulama yaklaşımı, ayarları bir uygulamaya iletmek için en düşük ortak paydanın kullanılmasını önerir. Ortam değişkenleri, işletim sistemi veya uygulama ne olursa olsun desteklendiğinden en düşük ortak paydadır.

Yerleşik Kubernetes gizli dizilerini kullanmanın bir alternatifi, Azure Key Vault'taki gizli dizilere Kubernetes'in içinden erişmektir. Bunu yapmanın en basit yolu, gizli bilgileri yüklemek isteyen kapsayıcıya bir RBAC rolü atamaktır. Uygulama daha sonra gizli dizilere erişmek için Azure Key Vault API'lerini kullanabilir. Ancak bu yaklaşım kodda değişiklik yapılmasını gerektirir ve ortam değişkenlerini kullanma desenini izlemez. Bunun yerine, kapsayıcıya değer eklemek mümkündür. Bu yaklaşım, kümedeki kullanıcılar tarafından erişilebildiği için Kubernetes gizli dizilerini doğrudan kullanmaktan daha güvenlidir.

Aktarım ve bekleme durumunda şifreleme

İster diskte olsun ister farklı hizmetler arasında geçiş yaparak verileri güvende tutmak önemlidir. Verilerin sızmasını engellemenin en etkili yolu, verileri başkaları tarafından kolayca okunamaz bir biçimde şifrelemektir. Azure çok çeşitli şifreleme seçeneklerini destekler.

Taşınma sürecinde

Azure'da ağdaki trafiği şifrelemenin çeşitli yolları vardır. Azure hizmetlerine erişim genellikle Aktarım Katmanı Güvenliği (TLS) kullanan bağlantılar üzerinden yapılır. Örneğin, Azure API'lerine yapılan tüm bağlantılar TLS bağlantıları gerektirir. Aynı şekilde, Azure depolamadaki uç noktalara yönelik bağlantılar yalnızca TLS şifreli bağlantılar üzerinden çalışmak üzere kısıtlanabilir.

TLS karmaşık bir protokoldür ve yalnızca bağlantının TLS kullandığını bilmek güvenliği sağlamak için yeterli değildir. Örneğin, TLS 1.0 kronik olarak güvenli değildir ve TLS 1.1 çok daha iyi değildir. TLS sürümlerinde bile bağlantıların şifresinin çözülmesini kolaylaştırabilecek çeşitli ayarlar vardır. En iyi eylem, sunucu bağlantısının up-to-date ve iyi yapılandırılmış protokoller kullanıp kullanmadiğini denetlemektir.

Bu denetim, SSL laboratuvarlarının SSL Sunucu Testi gibi bir dış hizmet tarafından yapılabilir. Tipik bir Azure uç noktasına yönelik bir test çalıştırması, bu örnekte bir hizmet veri yolu uç noktası, A’ya yakın mükemmel bir puan sağlar.

Azure SQL veritabanları gibi hizmetler bile verileri gizli tutmak için TLS şifrelemesi kullanır. Aktarımdaki verileri TLS kullanarak şifrelemenin ilginç tarafı, Microsoft için bile TLS çalıştıran bilgisayarlar arasındaki bağlantıyı dinlemenin mümkün olmadığıdır. Bu, verilerinin güvenliğinin Microsoft'un bizzat kendisi veya hatta standart bir saldırgandan daha fazla kaynağa sahip bir devlet aktörü tarafından risk altında olabileceğinden endişe duyan şirketler için rahatlık sağlamalıdır.

Şekil 9-5. Service Bus uç noktası için A puanını gösteren SSL laboratuvar raporu.

Bu şifreleme düzeyi her zaman yeterli olmayacak olsa da, Azure TLS bağlantılarının oldukça güvenli olduğundan emin olmanız gerekir. Şifreleme geliştikçe Azure güvenlik standartlarını geliştirmeye devam edecektir. Güvenlik standartlarını izleyen ve Azure'ı geliştiren birinin olduğunu bilmek güzel.

Dinlenme halinde

Herhangi bir uygulamada, verilerin diskte bulunduğu birkaç yer vardır. Uygulama kodunun kendisi bir depolama mekanizmasından yüklenir. Çoğu uygulama SQL Server, Cosmos DB ve hatta inanılmaz fiyat açısından verimli Tablo Depolama gibi bir veritabanı türü de kullanır. Bu veritabanlarının tümü, uygun izinlere sahip uygulamalardan başka kimsenin verilerinizi okuyamamasını sağlamak için yoğun şekilde şifrelenmiş depolama kullanır. Sistem işleçleri bile şifrelenmiş verileri okuyamaz. Böylece müşteriler gizli bilgilerinin gizli kaldığından emin olabilir.

Depolama

Azure'ın büyük bir kısmının altında yatan, Azure Depolama altyapısıdır. Sanal makine diskleri Azure Depolama'nın üzerine bağlanır. Azure Kubernetes Service, azure depolamada barındırılan sanal makinelerde çalışır. Azure İşlevleri Uygulamaları ve Azure Container Instances gibi sunucusuz teknolojilerin bile Azure Depolama'nın parçası olan diskleri tükenebilir.

Azure Depolama iyi şifrelenirse, diğer her şeyin de şifrelenmesini sağlayan bir temel sağlar. Azure Depolama, FIPS 140-2 uyumlu 256 bit AES ile şifrelenir. Bu, son 20 yıl içinde kapsamlı akademik incelemenin konusu olan iyi kabul gören bir şifreleme teknolojisidir. Şu anda, anahtarı bilgisi olmayan birinin AES tarafından şifrelenen verileri okumasına izin verecek bilinen bir pratik saldırı yoktur.

Varsayılan olarak, Azure Depolama'yı şifrelemek için kullanılan anahtarlar Microsoft tarafından yönetilir. Bu anahtarlara kötü amaçlı erişimi önlemeye yönelik kapsamlı korumalar vardır. Ancak, belirli şifreleme gereksinimlerine sahip kullanıcılar Azure Key Vault'ta yönetilen kendi depolama anahtarlarını da sağlayabilir . Bu anahtarlar herhangi bir zamanda iptal edilebilir ve bu da Depolama hesabının içeriğini erişilemez hale getirir.

Sanal makineler şifrelenmiş depolama kullanır, ancak Windows'da BitLocker veya Linux'ta DM-Crypt gibi teknolojileri kullanarak başka bir şifreleme katmanı sağlamak mümkündür. Bu teknolojiler, disk görüntüsü depolamadan sızdırılmış olsa bile okumanın neredeyse imkansız kalacağı anlamına gelir.

Azure SQL

Azure SQL'de barındırılan veritabanları, verilerin şifrelenmesini sağlamak için Saydam Veri Şifrelemesi (TDE) adlı bir teknoloji kullanır. Yeni oluşturulan tüm SQL veritabanlarında varsayılan olarak etkinleştirilir, ancak eski veritabanları için el ile etkinleştirilmesi gerekir. TDE, yalnızca veritabanının değil, yedeklemelerin ve işlem günlüklerinin de gerçek zamanlı şifreleme ve şifre çözme işlemlerini yürütür.

Şifreleme parametreleri veritabanında depolanır master ve başlangıçta kalan işlemler için belleğe okunur. Bu, veritabanının master şifrelenmemiş kalması gerektiği anlamına gelir. Gerçek anahtar Microsoft tarafından yönetilir. Ancak, tam güvenlik gereksinimlerine sahip kullanıcılar Key Vault'ta kendi anahtarlarını Azure Depolama için olduğu gibi sağlayabilir. Key Vault, anahtar döndürme ve iptal gibi hizmetler sağlar.

TDS'nin "Saydam" bölümü, şifrelenmiş veritabanını istemcide herhangi bir değişiklik yapmadan kullanabilmekten gelmektedir. Bu yaklaşım iyi bir güvenlik sağlarken, kullanıcıların verilerin şifresini çözebilmesi için veritabanı parolasının sızması yeterlidir. Veritabanındaki sütunları veya tabloları tek tek şifreleyen başka bir yaklaşım vardır. Always Encrypted veritabanında şifreli verilerin hiçbir zaman düz metin olarak görünmemesini sağlar.

Bu şifreleme katmanını ayarlamak için SQL Server Management Studio'da bir sihirbaz aracılığıyla çalıştırılarak şifreleme türünü ve ilişkili anahtarların Key Vault'ta depolandığı yeri seçmeniz gerekir.

Şekil 9-6. Always Encrypted kullanılarak şifrelenecek tablodaki sütunları seçme.

Bu şifrelenmiş sütunlardan bilgi okuyan istemci uygulamalarının şifrelenmiş verileri okumak için özel izinler yapması gerekir. Bağlantı dizeleri Column Encryption Setting=Enabled ile güncellenmeli ve istemci kimlik bilgileri Key Vault'tan alınmalıdır. Daha sonra SQL Server istemcisinin sütun şifreleme anahtarlarıyla astarlanması gerekir. Bu işlem tamamlandıktan sonra, kalan eylemler SQL İstemcisi için standart arabirimleri kullanır. Başka bir ifadeyle, SQL İstemcisi'nin üzerinde oluşturulan Dapper ve Entity Framework gibi araçlar değişiklik yapmadan çalışmaya devam edecektir. Always Encrypted henüz her dildeki her SQL Server sürücüsü için kullanılamayabilir.

her ikisi de istemciye özgü anahtarlarla kullanılabilen TDE ve Always Encrypted birleşimi, en kesin şifreleme gereksinimlerinin bile desteklenmesini sağlar.

Cosmos DB veritabanı hizmeti

Cosmos DB, Microsoft tarafından Azure'da sağlanan en yeni veritabanıdır. Güvenlik ve şifreleme göz önünde bulundurularak sıfırdan inşa edilmiştir. AES-256bit şifrelemesi tüm Cosmos DB veritabanları için standarttır ve devre dışı bırakılamaz. İletişim için TLS 1.2 gereksinimiyle birlikte depolama çözümünün tamamı şifrelenir.

Şekil 9-7. Cosmos DB'de veri şifreleme akışı.

Cosmos DB müşteri şifreleme anahtarlarını sağlamasa da, ekip tarafından bu olmadan PCI-DSS uyumlu kaldığından emin olmak için önemli çalışmalar yapılmıştır. Cosmos DB henüz Azure SQL'in Always Encrypted'a benzer tek sütunlu şifrelemeyi desteklememektedir.

Güvenliği koruma

Azure, yüksek oranda güvenli bir ürün yayınlamak için gereken tüm araçlara sahiptir. Ancak, bir zincir yalnızca en zayıf bağlantısı kadar güçlüdür. Azure üzerinde dağıtılan uygulamalar uygun bir güvenlik zihniyetiyle ve iyi güvenlik denetimleriyle geliştirilmeyen uygulamalar zincirdeki zayıf bağlantı haline gelir. Azure'da yüklü olan yazılımın Azure'ın kendisi kadar güvenli olduğundan emin olmak için kullanılabilecek birçok harika statik analiz aracı, şifreleme kitaplığı ve güvenlik uygulamaları vardır. Örnek olarak statik çözümleme araçları ve şifreleme kitaplıkları verilebilir.

ÖncekiSonraki