Senaryo 2 çözümü - Görev açısından kritik uygulama
Önceki ünitede 911 görev dağıtım sistemi için yüksek kullanılabilirlik içeren bir senaryo üzerinde çalıştınız. Bu ünitede olası çözümlerden birini ve dikkate alınacak diğer 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
Senaryonun üzerinde çalışmak için yapılacak ilk seçim genellikle hangi Azure SQL dağıtım seçeneğinin en uygun çözüm olma potansiyelini taşıdığını belirlemektir. Tek başına hizmet düzeyi sözleşmesini (SLA) düşünürseniz, yüzde 99,995 düzeyinde bir SLA gereksinimi söz konusudur ve bu yalnızca Azure SQL Veritabanı ile sağlanabilir. Bu SLA'yı elde etmek için İş Açısından Kritik hizmet katmanını dağıtmanız ve kullanılabilirlik alanlarını etkinleştirmeniz gerekir.
Bir diğer karar grubu coğrafi yedekliliğin nasıl etkinleştirileceği ve olağanüstü durumlarda yüksek kullanılabilirliğin nasıl korunacağıyla ilgilidir. Hem coğrafi çoğaltma hem de otomatik yük devretme grupları burada kullanılabilir seçenekler olsa da, otomatik yük devretme grupları müşterinin hiçbir bağlantı dizesini değiştirmeden gerektiğinde yük devretmesine olanak tanır. Bu kurulum uygulamaların bağlantı dizelerini güncelleştirmek için kapalı kalma sürelerini azaltma potansiyeline sahip olabilir çünkü güncelleştirme gerekmeyecektir. Ayrıca durumu denetlemek için izleme sorguları da yapılandırabilirsiniz. Bu yolla, herhangi bir sorun olduğunda yük devretmeyi bile zorlayabilirsiniz.
Bu yapılandırmada ortak barındırmanın oynadığı rolü düşünmek de önemlidir. Yüksek kullanılabilirliği sürdürmek için uygulamanızın veritabanınıza mümkün olduğunca yakın olması, kesinlikle aynı bölgede yer alması gerekir. Otomatik yük devretme grubu için uygulamanızın her iki bölgeye de dağıtıldığından, böylelikle uygulamanın (örneğin bir web uygulaması) yedekli bir kopyasının bulunduğundan emin olmak istersiniz. Yük devretme gerçekleşirse, Azure Traffic Manager'ı kullanarak trafiği ikincil bölgedeki uygulamaya yönlendirebilirsiniz.
DBA'lar ve hassas veriler
911 görev dağıtım sistemi koordinatörleri DBA'ların işlerini yapmalarını sağlarken hassas verileri (sağlık geçmişi ve diğer kişisel bilgiler gibi) koruma konusunda kaygılandıklarını belirtmişlerdir.
DBA'ların belirli sütunlarda depolanan hassas verileri göremediklerinden ve hassas verilerin bulunduğu tablolara tüm erişimin izlendiğinden emin olmak için birkaç Azure SQL teknolojisinden faydalanabilirsiniz. SQL Denetimi'ni kullanmak erişimi izlemenin en iyi yöntemidir ama DBA'lar yine de verileri görebilir. Hassas verileri Veri Sınıflandırması kullanarak sınıflandırmak yararlı olabilir çünkü hassas veriler etiketlenir ve SQL Denetimi ile bunu izleyebilirsiniz. Öte yandan, bu uygulandığında da DBA'lar hassas verileri yine görebilir. Hassas verileri maskelemek için dinamik veri maskeleme özelliğini kullanabilirsiniz ancak bir veritabanı sahibinin (db_owner) kullanıcı verilerini görüntülemesini yalnızca izinlerle engellemek mümkün değildir.
Veritabanında son derece hassas veriler varsa, veritabanı sahiplerinin bile bu verileri görmesini güvenle engellemek için Always Encrypted hizmetini kullanabilirsiniz. Always Encrypted anahtarlarını rol ayrımıyla yönetebilirsiniz; böylelikle güvenlik yöneticisi veritabanına erişmez ve DBA da düz metin biçimindeki fiziksel anahtarlara erişmez. Bu stratejiyi SQL Denetimi'yle izleme yöntemiyle birlikte kullanarak hassas verileri izleyebilir, maskeleyebilir ve db_owner haklarına sahip DBA'ların bile bu verilere erişimini izleyebilirsiniz.
DBA'ların hassas verileri maskelemesi ancak Azure portalı, SQL Server Management Studio ve Azure Data Studio'yu kullanarak performans sorunlarını giderebilmesi gerekir. Ayrıca, Microsoft Entra sorumlularına eşlenmesi gereken yeni bağımsız veritabanı kullanıcıları oluşturabilmeleri gerekir.
Çözümlerden biri, her örnekteki DBA'lar için SQL DBA adlı bir Microsoft Entra grubu oluşturmaktır. Ardından grubu Azure rol tabanlı erişim denetiminin (RBAC) SQL Server Katkıda Bulunanı rolüne atayın. Son olarak, grubu mantıksal sunucuda Microsoft Entra yöneticisi olarak ayarlayabilirsiniz.