Skenario 2 - Aplikasi misi-kritis
Di pelajaran sebelumnya, Anda bekerja melalui skenario yang melibatkan ketersediaan tinggi untuk sistem pengiriman 911. Di pelajaran ini, Anda akan mengulas satu solusi potensial dan beberapa item untuk dipertimbangkan.
Saat mengulas, Anda harus membandingkan solusi yang disediakan dengan yang Anda kembangkan di pelajaran sebelumnya. Sering kali, terdapat ebih dari satu solusi yang benar untuk masalah apa pun, tetapi selalu ada tradeoff. Item mana dalam solusi Anda yang berbeda dari yang diusulkan? Adakah hal dalam solusi Anda yang perlu dipikirkan kembali? Adakah hal dalam solusi yang tersedia yang menurut Anda bertujuan secara lebih menyeluruh dalam solusi Anda?
Opsi dan konfigurasi penyebaran
Pilihan pertama dalam mengatasi skenario sering kali adalah untuk mengidentifikasi opsi penyebaran Azure SQL mana yang berpotensi menjadi yang paling cocok. Jika Anda mempertimbangkan perjanjian tingkat layanan (SLA) saja, persyaratannya adalah untuk SLA 99,995 persen, yang hanya dapat disediakan oleh Azure SQL Database. Untuk mendapatkan SLA ini, Anda harus menyebarkan tingkat layanan Business Critical dan mengaktifkan penggunaan zona ketersediaan.
Set keputusan lain terkait dengan cara mengaktifkan geo-redundansi dan mempertahankan ketersediaan tinggi dalam bencana. Meskipun grup replikasi lokasi geografis dan kegagalan otomatis keduanya merupakan opsi di sini, grup kegagalan otomatis akan memungkinkan pelanggan untuk gagal jika diperlukan, tanpa mengubah string koneksi apa pun. Penyiapan ini berpotensi membantu mengurangi waktu henti untuk memperbarui aplikasi, karena tidak akan diperlukan. Anda juga dapat mengonfigurasikan kueri pemantauan untuk memeriksa status. Dengan demikian, jika ada yang tidak beres, Anda bahkan dapat memaksakan kegagalan.
Dalam konfigurasi ini, penting juga untuk memikirkan peran yang dimainkan colocation. Untuk menjaga ketersediaan tinggi, aplikasi Anda harus sedekat mungkin dengan database Anda, tentu saja di wilayah yang sama. Anda pasti ingin memastikan bahwa aplikasi Anda disebarkan di kedua wilayah grup kegagalan otomatis, sehingga salinan aplikasi yang berlebihan (misalnya, aplikasi web) ada. Jika ada kegagalan, Anda dapat menggunakan Azure Traffic Manager untuk mengubah rute lalu lintas ke aplikasi di wilayah sekunder.
DBA dan data sensitif
Koordinator sistem pengiriman 911 telah menyatakan kekhawatirannya tentang melindungi data sensitif (seperti riwayat kesehatan dan informasi pribadi lainnya), sambil tetap memungkinkan DBA untuk melakukan pekerjaan mereka.
Untuk memastikan bahwa DBA tidak dapat melihat data sensitif yang disimpan dalam kolom tertentu dan bahwa semua akses ke tabel yang berisi data sensitif dipantau, Anda dapat menggunakan beberapa teknologi Azure SQL. Menggunakan SQL Audit adalah praktik terbaik untuk memantau akses, tetapi DBA masih dapat melihat data. Mengklasifikasikan data sensitif dengan menggunakan Klasifikasi Data akan membantu, karena data sensitif akan diberi label dan Anda dapat melacaknya dengan Audit SQL. Namun, jika ini diterapkan, DBA masih akan dapat melihat data sensitif. Anda dapat menggunakan masking data dinamis untuk membantu menutupi data sensitif, tetapi tidak dimungkinkan untuk mencegah db_owner melihat data pengguna hanya dengan izin.
Jika data yang sangat sensitif ada dalam database, Anda dapat menggunakan Always Encrypted untuk mencegah db_owners melihatnya dengan aman. Anda dapat mengelola kunci Always Encrypted dengan pemisahan peran, sehingga admin keamanan tidak mengakses database dan DBA tidak mengakses kunci fisik dalam teks biasa. Dengan menggunakan strategi ini dalam kombinasi dengan pemantauan melalui SQL Audit, Anda dapat memantau, menutupi, dan melacak akses ke data sensitif, bahkan dari DBA dengan hak db_owner.
DBA harus memiliki data sensitif yang ditutupi, tetapi mereka masih harus dapat memecahkan masalah kinerja dengan menggunakan portal Microsoft Azure dan SQL Server Management Studio atau Azure Data Studio. Dan mereka harus dapat membuat pengguna database mandiri baru yang harus dipetakan ke perwakilan Microsoft Entra.
Salah satu solusinya adalah membuat grup Microsoft Entra yang disebut SQL DBA untuk DBA pada setiap instans. Kemudian, tetapkan grup ke kontrol akses berbasis peran Azure (RBAC) dari Kontributor Server SQL. Terakhir, Anda dapat mengatur grup menjadi admin Microsoft Entra di server logis.