Audit untuk Azure SQL Database dan Azure Synapse Analytics

Aplikasi ke:Azure SQL DatabaseAzure Synapse Analytics

Audit untuk Azure SQL Database dan Azure Synapse Analytics melacak peristiwa database dan menulisnya ke log audit di akun penyimpanan Azure, ruang kerja Log Analytics, atau Azure Event Hubs.

Pengauditan juga mencakup:

  • Membantu menjaga kepatuhan terhadap peraturan, memahami aktivitas database, dan memperoleh wawasan tentang adanya perbedaan dan anomali yang dapat menunjukkan masalah bisnis atau dugaan pelanggaran keamanan.

  • Mengaktifkan dan memfasilitasi kepatuhan terhadap standar kepatuhan, meskipun tidak menjamin kepatuhan. Untuk informasi selengkapnya, lihat Microsoft Azure Trust Center tempat Anda dapat menemukan daftar sertifikasi kepatuhan SQL Database terbaru.

Catatan

Untuk informasi tentang audit Azure SQL Managed Instance, lihat Mulai audit Azure SQL Managed Instance.

Gambaran Umum

Anda dapat menggunakan audit Azure SQL Database untuk:

  • Mempertahankan catatan audit atas peristiwa yang dipilih. Anda dapat menentukan kategori tindakan database yang akan diaudit.
  • Laporan aktivitas database. Dengan adanya laporan yang telah dikonfigurasi sebelumnya dan dasbor, Anda dapat membuat laporan aktivitas dan kejadian dengan mudah.
  • Menganalisis laporan. Anda dapat menemukan peristiwa mencurigakan, aktivitas yang tidak biasa, dan tren.

Penting

Audit untuk Azure SQL Database, kumpulan SQL Azure Synapse Analytics, dan Azure SQL Managed Instance dioptimalkan untuk ketersediaan dan performa database atau instans yang sedang diaudit. Selama periode aktivitas yang sangat tinggi atau beban jaringan yang tinggi, fitur audit mungkin memungkinkan transaksi untuk melanjutkan tanpa merekam semua peristiwa yang ditandai untuk audit.

Peningkatan performa, ketersediaan, dan keandalan dalam audit server untuk Azure SQL Database (Juli 2025 GA)

  • Merancang ulang bagian utama Audit SQL yang mengakibatkan peningkatan ketersediaan dan keandalan audit server. Sebagai manfaat tambahan, ada penyelarasan fitur yang lebih dekat dengan SQL Server dan Azure SQL Managed Instance. Audit database tetap tidak berubah.
  • Desain audit sebelumnya memicu audit tingkat database dan menjalankan satu sesi audit untuk setiap database di server. Arsitektur baru audit membuat satu sesi peristiwa yang diperluas di tingkat server yang menangkap peristiwa audit untuk semua database.
  • Desain audit baru mengoptimalkan memori dan CPU, dan konsisten dengan cara kerja audit dalam SQL Server dan Azure SQL Managed Instance.

Perubahan akibat arsitektur ulang dalam audit server

  • Perubahan struktur folder untuk akun penyimpanan:
    • Salah satu perubahan utama melibatkan perubahan struktur folder untuk log audit yang disimpan dalam kontainer akun penyimpanan. Sebelumnya, log audit server ditulis ke folder terpisah; satu untuk setiap database, dengan nama database berfungsi sebagai nama folder. Dengan pembaruan baru, semua log audit server dikonsolidasikan ke dalam satu folder berlabel master. Perilaku ini sama dengan Azure SQL Managed Instance dan SQL Server.
  • Perubahan struktur folder untuk replika yang hanya dapat dibaca
    • Replika database hanya-baca dulu menyimpan log mereka di folder hanya-baca. Log tersebut sekarang ditulis ke dalam folder master. Anda dapat mengambil log ini dengan memfilter pada kolom baru is_secondary_replica_true.
  • Izin yang diperlukan untuk melihat log Audit:
    • VIEW DATABASE SECURITY AUDIT izin dalam database pengguna

Untuk lingkungan dengan banyak database yang menjalankan beban kerja OLTP berat, menggunakan audit tingkat server dengan pengaturan default dapat menyebabkan volume audit yang sangat besar di seluruh server logis. Karena semua peristiwa dari semua database ditulis ke dalam folder audit yang sama, mengkueri log audit untuk satu database menjadi lambat dan mahal secara operasional. Untuk meningkatkan performa dan mengurangi kebisingan:

  • Beralih ke audit tingkat database. Setiap database merekam ke berkas log auditnya sendiri, sehingga mengurangi total volume yang dipindai dan membuat pengambilan lebih cepat.
  • Tinjau ulang konfigurasi audit. Tentukan apakah menangkap semua peristiwa yang diselesaikan batch diperlukan, atau apakah konfigurasi terfilter kustom dapat memenuhi persyaratan keamanan dan kepatuhan Anda.

Keterbatasan dalam audit

  • Mengaktifkan pengauditan pada kumpulan SQL Azure Synapse yang sedang dijeda tidak didukung. Untuk mengaktifkan audit, aktifkan kembali kumpulan Synapse SQL.
  • Mengaktifkan audit dengan menggunakan User Assigned Managed Identity (UAMI) tidak didukung pada Azure Synapse.
  • Saat ini, identitas terkelola tidak didukung untuk Azure Synapse, kecuali akun penyimpanan berada di belakang jaringan virtual atau firewall.

Catatan

Untuk Azure Synapse Analytics, audit ke akun penyimpanan di belakang VNet memerlukan identitas terkelola yang ditetapkan system server dengan peran Storage Blob Data Contributor. Identitas terkelola yang ditetapkan pengguna (UAMI) tidak didukung untuk audit Synapse. Jika Anda perlu mengaudit akun penyimpanan yang menggunakan autentikasi hanya Microsoft Entra, konfigurasikan identitas terkelola yang ditetapkan sistem pada server dan berikan peran Kontributor Data Blob Penyimpanan pada akun penyimpanan target. Untuk informasi selengkapnya, lihat Menulis audit ke akun penyimpanan di belakang VNet dan firewall.

  • Karena batasan kinerja, kami tidak mengaudit tempdbtabel sementara. Meskipun grup tindakan "batch completed" menangkap pernyataan terhadap tabel sementara, grup tersebut mungkin tidak mengisi nama objek dengan benar. Namun, tabel sumber selalu diaudit, memastikan bahwa semua sisipan dari tabel sumber ke tabel sementara direkam.

  • Audit untuk kumpulan SQL Azure Synapse mendukung grup tindakan audit default hanya.

  • Saat Anda mengonfigurasi audit untuk server logical di Azure atau Azure SQL Database dengan tujuan log sebagai akun penyimpanan, mode autentikasi harus cocok dengan konfigurasi untuk akun penyimpanan tersebut. Jika menggunakan kunci akses penyimpanan sebagai jenis autentikasi, akun penyimpanan target harus diaktifkan dengan akses ke kunci akun penyimpanan. Jika akun penyimpanan dikonfigurasi untuk hanya menggunakan autentikasi dengan Microsoft Entra ID (formerly Azure Active Directory), audit dapat dikonfigurasi untuk menggunakan identitas terkelola untuk autentikasi.

  • Audit tidak didukung pada database dengan nama yang berisi ? karakter. Ini berlaku untuk audit server dan database, karena database dengan ? atas namanya tidak lagi didukung pada Azure.

  • log audit Azure SQL Database dan Azure Synapse menangkap hingga 4.000 karakter di bidang statement dan data_sensitivity_information. Jika output dari tindakan yang dapat diaudit melebihi batas ini, konten apa pun di luar 4.000 karakter pertama dipotong dan dikecualikan dari catatan audit.

Keterangan

  • Peristiwa yang dimulai oleh SQLDBControlPlaneFirstPartyApp dalam log Aktivitas adalah fungsi internal Azure dari lapisan kontrol Azure SQL Database. Peristiwa yang dimulai oleh SQLDBControlPlaneFirstPartyApp adalah bagian dari operasi sinkronisasi internal antara mesin SQL dan Azure Resource Manager. Peristiwa ini adalah bagian normal dari manajemen Azure SQL Database dan diperlukan untuk representasi dan operasi sumber daya yang benar dalam Azure.
  • Penyimpanan premium dengan BlockBlobStorage didukung. Penyimpanan standar didukung. Namun, agar audit dapat menulis ke akun penyimpanan di belakang jaringan virtual atau firewall, Anda harus memiliki akun penyimpanan tujuan umum v2. Jika Anda memiliki akun v1 atau Blob Storage tujuan umum, upgrade ke akun penyimpanan v2 tujuan umum. Untuk petunjuk khusus, lihat Menulis audit ke akun penyimpanan yang berada di belakang VNet dan firewall. Untuk informasi selengkapnya, lihat Jenis akun penyimpanan.
  • Saat pelanggan mengaktifkan audit SQL dan juga mengonfigurasi pembatasan jaringan keluar , mereka harus mengizinkan daftar nama domain yang sepenuhnya memenuhi syarat dari akun penyimpanan audit mereka untuk memastikan peristiwa audit dapat berhasil mencapai tujuan. Jika titik akhir penyimpanan tidak di-whitelist, lalu lintas audit diblokir, mengakibatkan hilangnya kejadian audit. Setelah menambahkan FQDN akun penyimpanan yang diperlukan ke daftar yang diizinkan, pelanggan harus menyimpan ulang konfigurasi audit mereka untuk melanjutkan alur peristiwa audit seperti biasa.
  • Namespace hierarkis untuk semua jenis akun penyimpanan standar dan akun penyimpanan premium dengan BlockBlobStorage didukung.
  • Log audit ditulis ke Append Blobs dalam Azure Blob Storage pada langganan Azure Anda.
  • Log audit dalam format .xel dan dapat dibuka dengan SQL Server Management Studio (SSMS).
  • Untuk mengonfigurasi penyimpanan log yang tidak dapat diubah untuk peristiwa audit tingkat server atau database, ikuti instruksi yang disediakan oleh Azure Storage. Saat mengonfigurasi penyimpanan blob yang tidak dapat diubah untuk audit, pastikan izinkan penulisan penambahan yang dilindungi diatur ke Tambahkan blob atau Blokir dan tambahkan blob. Opsi Tidak Ada tidak didukung. Untuk kebijakan retensi berbasis waktu, interval retensi akun penyimpanan harus lebih pendek dari pengaturan retensi Audit SQL. Konfigurasi di mana kebijakan penyimpanan ditetapkan, tetapi retensi Audit SQL adalah 0, tidak tersedia.
  • Anda dapat menulis log audit ke akun Azure Storage di belakang jaringan virtual atau firewall.
  • Untuk detail tentang format log, hierarki folder penyimpanan, dan konvensi penamaan, lihat artikel SQL Database audit log format.
  • Audit untuk Gunakan replika baca-saja untuk mengalihkan beban kerja kueri baca-saja diaktifkan secara otomatis. Untuk informasi selengkapnya tentang hierarki folder penyimpanan, konvensi penamaan, dan format log, lihat artikel Format Log Audit SQL Database.
  • Saat menggunakan autentikasi Microsoft Entra, data masuk yang gagal tidak muncul di log audit SQL. Untuk melihat catatan audit login yang gagal, Anda perlu mengunjungi Microsoft Entra admin center, yang mencatat detail peristiwa ini.
  • Login dialihkan oleh gateway ke instans tertentu di mana database berada. Melalui login Microsoft Entra, kredensial pengguna diverifikasi sebelum mencoba menggunakan pengguna tersebut untuk login ke database yang diminta. Dalam kasus kegagalan, database yang diminta tidak pernah diakses, jadi tidak ada audit yang terjadi. Dengan login SQL, kredensial diverifikasi pada data yang diminta, sehingga dalam hal ini mereka dapat diaudit. Login yang sukses, yang jelas mencapai database, diaudit pada kedua kasus.
  • Setelah mengonfigurasi pengaturan audit, Anda dapat mengaktifkan fitur deteksi ancaman baru dan mengonfigurasi email untuk menerima pemberitahuan keamanan. Saat menggunakan deteksi ancaman, Anda akan menerima pemberitahuan proaktif tentang anomali aktivitas database yang dapat menunjukkan potensi ancaman keamanan. Untuk informasi selengkapnya, lihat SQL Advanced Threat Protection.
  • Setelah database dengan audit diaktifkan disalin ke server logis lain, Anda mungkin menerima email yang memberi tahu Anda bahwa audit gagal. Ini adalah masalah yang diketahui dan audit harus bekerja seperti yang diharapkan pada database yang baru disalin.

Konten terkait

  • Last updated on