Mengonfigurasi dan mengelola keamanan Azure SQL Database untuk pemulihan lokasi geografis atau kegagalan

  • Artikel

Berlaku untuk:Azure SQL Database

Artikel ini menjelaskan persyaratan autentikasi untuk mengonfigurasi dan mengontrol replikasi geografis aktif dan grup failover. Artikel ini juga memberikan langkah-langkah yang diperlukan untuk mengatur akses pengguna ke database sekunder. Terakhir, artikel ini juga menjelaskan cara mengaktifkan akses ke database yang dipulihkan setelah menggunakan pemulihan lokasi geografis. Untuk informasi selengkapnya tentang opsi pemulihan, lihat Gambaran Umum Kelangsungan Bisnis.

Pemulihan bencana dengan pengguna yang mandiri

Tidak seperti pengguna tradisional, yang harus dipetakan untuk masuk dalam master database, pengguna yang terkandung dikelola sepenuhnya oleh database itu sendiri. Ini memiliki dua manfaat: Dalam skenario pemulihan bencana, pengguna dapat terus terhubung ke database utama baru atau database yang dipulihkan menggunakan pemulihan lokasi geografis tanpa konfigurasi tambahan, karena database mengelola pengguna. Ada juga potensi skalabilitas dan manfaat performa dari konfigurasi ini dari perspektif login. Untuk informasi selengkapnya, lihat Pengguna Database Mandiri - Membuat Database Anda Portabel.

Trade-off utamanya adalah bahwa mengelola proses pemulihan bencana dalam skala besar lebih menantang. Ketika Anda memiliki beberapa database yang menggunakan login yang sama, mempertahankan kredensial menggunakan pengguna mandiri dalam beberapa database dapat meniadakan manfaat pengguna mandiri. Misalnya, kebijakan rotasi kata sandi mengharuskan perubahan dilakukan secara konsisten dalam beberapa database daripada mengubah kata sandi untuk masuk sekali dalam master database. Karena alasan tersebut, jika Anda memiliki beberapa database yang menggunakan nama pengguna dan kata sandi yang sama, sebaiknya tidak menggunakan pengguna mandiri.

Cara mengonfigurasi login dan pengguna

Jika Anda menggunakan login dan pengguna (bukan pengguna mandiri), Anda harus mengambil langkah tambahan untuk memastikan bahwa login yang sama ada di master database. Bagian berikut menjelaskan langkah-langkah yang terlibat dan pertimbangan tambahan.

Catatan

Anda juga dapat menggunakan login yang dibuat dari MICROSOFT Entra ID (sebelumnya Azure Active Directory) untuk mengelola database Anda. Untuk informasi selengkapnya, lihat login dan pengguna Azure SQL.

Menyiapkan akses pengguna ke database sekunder atau yang dipulihkan

Agar database sekunder dapat digunakan sebagai database sekunder baca-saja, dan untuk memastikan akses yang tepat ke database utama baru atau database yang dipulihkan menggunakan pemulihan geografis, master database server target harus memiliki konfigurasi keamanan yang sesuai sebelum pemulihan.

Izin khusus untuk setiap langkah dijelaskan nanti dalam pembahasan topik ini.

Mempersiapkan akses pengguna ke replikasi lokasi geografis sekunder harus dilakukan sebagai bagian yang mengonfigurasi replikasi lokasi geografis. Mempersiapkan akses pengguna ke database yang dipulihkan secara geografis harus dilakukan kapan saja ketika server asli dalam keadaan online (misalnya sebagai bagian dari penelusuran DR).

Catatan

Jika Anda gagal atas atau pemulihan lokasi geografis ke server yang tidak memiliki login yang dikonfigurasi dengan benar, akses ke sana akan terbatas pada akun admin server.

Menyiapkan login di server target memerlukan tiga langkah yang diuraikan di bawah ini:

1. Menentukan masuk dengan akses ke database utama

Langkah pertama dari proses ini adalah menentukan login mana yang harus diduplikasi pada server target. Ini dicapai dengan sepasang pernyataan SELECT, satu di database logis master di server sumber dan satu di database utama itu sendiri.

Hanya admin server atau anggota peran server LoginManager yang dapat menentukan login di server sumber dengan pernyataan SELECT berikut.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

Hanya anggota peran database db_owner, pengguna dbo, atau admin server, yang dapat menentukan semua pengguna database utama di database utama.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Menemukan SID untuk login yang diidentifikasi pada langkah 1

Dengan membandingkan output kueri dari bagian sebelumnya dan mencocokkan SID, Anda dapat memetakan login server ke pengguna database. Login yang memiliki pengguna database dengan SID yang cocok memiliki akses pengguna ke database tersebut sebagai pengguna database utama.

Kueri berikut ini dapat digunakan untuk melihat semua pengguna utama dan SID mereka dalam database. Hanya anggota peran database db_owner atau admin server yang bisa menjalankan kueri ini.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

Catatan

Pengguna INFORMATION_SCHEMA dan sys memiliki SID NULL, dan SID tamu adalah 0x00. SID dbo dapat dimulai dengan 0x01060000000001648000000000048454, jika pembuat database adalah admin server bukan anggota DbManager.

3. Membuat login di server target

Langkah terakhir adalah membuka server target atau server, dan menghasilkan login dengan SID yang sesuai. Sintaks dasarnya adalah sebagai berikut.

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

Pada server target, jangan buat login baru dengan SID admin server dari sumbernya. Sebagai gantinya, buat admin server target masuk ke prinsipal database dalam database, seperti db_owner atau pengguna.

Catatan

Jika Anda ingin memberikan akses pengguna ke sekunder, tetapi tidak ke utama, Anda dapat melakukannya dengan mengubah login pengguna di server utama dengan menggunakan sintaks berikut.

ALTER LOGIN [<login name>] DISABLE

DISABLE tidak mengubah kata sandi, sehingga Anda selalu dapat mengaktifkannya jika diperlukan.

Langkah berikutnya