Senaryo 1 çözümü - Küresel ölçekte ve güvenli bir erişimin mimarisini oluşturma
Önceki ünitede bir içerik teslim ağı için küresel ölçekte bir senaryo üzerinde çalıştınız. Bu ünitede olası çözümlerden birini ve dikkate alınacak bazı öğeleri gözden geçireceksiniz.
Gözden geçirirken, sağlanan çözümü önceki ünitede kendi geliştirdiğiniz çözümle karşılaştırmalısınız. Genellikle, herhangi bir sorunun birden fazla çözümü vardır ama her zaman bazı şeylerden ödün vermek gerekir. Çözümünüzdeki öğelerden hangileri önerilen çözümden farklı? Çözümünüzde yeniden üzerinde durabileceğiniz noktalar var mı? Sizin çözümünüzde, sağlanan çözüme göre daha kapsamlı olarak ele alınmış konular var mı?
Dağıtım seçeneği ve yapılandırma
Üzerinde düşünülmesi gereken ilk karar Azure SQL'in hangi dağıtım seçeneğinin kullanılacağıdır. Bir Azure sanal makinesindeki (VM) SQL Server kullanılabilir ama bir hizmet olarak platform (PaaS) teklifi daha az yönetim ek yüküyle daha uygun bir seçenek sağlayabilir.
Müşteri örnek kapsamlı bir özellik olan ortak dil çalışma zamanı modülünü (CLR) kullanıyor. CLR'de olduğu gibi Hizmet Aracısı ve Veritabanı Postası gibi örnek kapsamlı özellikleri destekleyen tek PaaS dağıtım seçeneği Azure SQL Yönetilen Örneği'dir. Bu nedenle Azure SQL Yönetilen Örneği, müşterinin CLR uygulamalarını yeniden yazmak zorunda kalmadan Azure SQL Veritabanı ile uyumlu bir çözüm (elastik veritabanı işleri gibi) gibi bir PaaS teklifine taşımasına olanak tanıyabilir.
Alınacak bir sonraki karar hizmet katmanıyla ilgilidir. Müşteri okuma ve yazma iş yüklerini yalıtmak istediğinden, bunu başarmanın en basit yolu İş Açısından Kritik hizmet katmanını kullanmaktır. İş Açısından Kritik hizmet katmanında arka planda çalışan bir Her Zaman Açık kullanılabilirlik grubu vardır. Bu ikincil çoğaltmalardan biri salt okunur iş yükleri için kullanılabilir.
İş Açısından Kritik, burada okuma ve yazma iş yüklerini ayırmaya yönelik yapılandırmanın yalnızca ilk yarısıdır. Senaryoda müşterinin birden çok bölgeyi aynı anda gerçekleşen birden çok sorguyla ölçeklendirip, bu arada da okuma ile yazma iş yüklerini yalıtabilmesi gerektiği belirtilmiştir.
Bu güçlüğe çözüm getirme potansiyeline sahip iki seçenek coğrafi çoğaltma ve otomatik yük devretme gruplarıdır. Öte yandan, coğrafi çoğaltma şu anda Azure SQL Yönetilen Örneği'nde desteklenmemektedir. Dolayısıyla bu senaryonun küresel okuma ölçeğine sahip olmasına yardımcı olabilecek tek seçenek otomatik yük devretme grubudur.
Müşteri otomatik yük devretme gruplarını kullandığı için İş Açısından Kritik hizmet katmanına ihtiyacı olup olmadığı, analiz iş yükleri için gereken yalnızca okuma uç noktalarının sayısına bağlıdır. Müşteri, İş Açısından Kritik hizmet katmanında bir otomatik yük devretme grubuyla üç okunabilir uç noktaya sahip olur:
- Birincil bölgenin kullanılabilirlik grubundan bir ikincil çoğaltma
- Yük devretme grubunun ikincisi (ikincil bölgedeki veritabanının birincil çoğaltması)
- İkincil bölgenin kullanılabilirlik grubundan bir ikincil çoğaltma
Analiz iş yükünün tüm bu okunabilir çoğaltmalara ihtiyacı yoksa, Genel Amaçlı hizmet katmanı daha uygun maliyetli bir çözüm olabilir.
En uygun kimlik doğrulama yöntemini seçme
Bu senaryonun diğer parçası, mümkün olan en güvenli teknolojileri oluşturma ve kullanma gereksinimi dikkate alınarak, her uygulamanın veya kişinin çözüme en iyi şekilde nasıl bağlanabileceğini saptamaktır. Senaryoyu bölerseniz, Azure SQL Yönetilen Örneği'ne erişmesi gerekecek dört farklı istemci vardır:
- Azure sanal makinesi üzerinde çalışan uygulama
- Etki alanına katılmış, Azure dışındaki makinede çalışan bir uygulama
- Etki alanına katılmamış, Azure dışındaki bir makinede bulunan SQL yönetim araçlarını (SQL Server Management Studio, Azure Data Studio, PowerShell) DBA’lar veya diğer kullanıcılar
- Azure dışındaki bir makinede çalışan, sürücü veya bağlantı dizesini değiştiremediğiniz eski uygulamalar
Şimdi bu istemcileri, kimlik doğrulama yöntemini nasıl seçebileceğinize ve dikkate alınacak bazı başka noktalarla kısıtlamalara göre ayıralım.
Azure sanal makinesi üzerinde çalışan uygulama
Azure kaynakları için yönetilen kimlikler, Azure sanal makinelerinde çalıştırılan uygulamalar için genel olarak önerilen parolasız kimlik doğrulama biçimidir.
Etki alanına katılmış, Azure dışındaki makinede çalışan bir uygulama
Azure dışındaki makineler için, yönetilen kimlikleri kullanma seçeneğiniz yoktur. Microsoft Entra Id aracılığıyla tümleşik kimlik doğrulaması, etki alanının Microsoft Entra ID ile birleştirildiği varsayılarak Azure dışındaki etki alanına katılmış makinelerde çalışan uygulamalar için önerilen kimlik doğrulama yöntemidir.
Azure dışındaki makine etki alanına katılmamışsa şunları yapabilirsiniz:
- Microsoft Entra Id'de uygulamanız için bir uygulama kimliği oluşturun.
- Uygulama kimliğiyle bir sertifikayı ilişkilendirebilirsiniz.
- Uygulamanızda değişiklik yaparak bir istemci kimliğiyle sertifika sağlama yoluyla Azure SQL Veritabanı için bir belirteç alabilirsiniz.
Sertifikanın bir özel anahtar içermesi ve bunun makineye dağıtılması gerekse de, uygulamanızı barındırarak en azından uygulama gizli dizisinin uygulama koduna veya yapılandırmaya sabit kodlanmasını önlersiniz. (Uygulamayı sertifika parmak iziyle yapılandırmanız gerekecektir.)
Etki alanına katılmamış, Azure dışındaki bir makinede bulunan SQL yönetim araçlarını kullanan DBA'lar veya diğer kullanıcılar
Azure dışındaki kullanıcılar için mümkünse parola kullanımının ortadan kaldırılması önerilir. Microsoft Entra tümleşik kimlik doğrulamasını kullanarak SQL araçlarıyla parola kullanımını ortadan kaldırabilirsiniz. Ancak, araçlar etki alanına katılmış bir makinede çalıştırılmalıdır ve etki alanı, bu senaryo için geçerli olmayan Microsoft Entra Kimliği ile birleştirilmelidir.
Ortam tümleşik kimlik doğrulaması önkoşullarını karşılamadığından, çoğu SQL aracının desteklediği çok faktörlü kimlik doğrulaması ile Microsoft Entra etkileşimli kimlik doğrulamasını kullanmanızı öneririz.
Azure dışındaki bir makinede çalışan, sürücü veya bağlantı dizesini değiştiremediğiniz eski uygulamalar
Sürücü veya bağlantı dizesinin değiştirilemediği senaryolarda maalesef parolaları ortadan kaldırma seçeneği yoktur. Bu eski uygulamaların SQL kimlik doğrulamasını kullanmaya devam etmeleri gerekir. Kısıtlamaları daha yakından inceleyebilir, uygulamaların daha güvenli ve daha korumalı kimlik doğrulaması yapmalarını sağlayacak bir yaklaşım için bu kısıtlamaların nasıl kaldırılabileceğini düşünebilirsiniz.