Bagikan melalui


Pengauditan untuk Azure SQL Database dan Azure Synapse Analytics

Berlaku untuk: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 Anda, Log Analytics workspace, atau 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, di mana Anda dapat menemukan daftar terbaru sertifikasi kepatuhan SQL Database.

Catatan

Untuk informasi tentang audit Azure SQL Managed Instance, lihat Mulai dengan 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 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 di 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 akan 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 akan 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

Pernyataan audit SQL panjang penuh (Agustus 2025)

Azure SQL Database mendukung pernyataan audit panjang penuh, menghapus batas pemotongan 4.000 karakter sebelumnya dalam file audit.

Manfaat utama dari pembaruan ini meliputi:

  • Visibilitas lengkap: Log audit menangkap seluruh konten pernyataan SQL, meningkatkan keterlacakan.
  • Keamanan &kepatuhan yang ditingkatkan: Konteks penuh memungkinkan deteksi ancaman dan analisis forensik yang lebih baik.
  • Paritas fitur: Menyelaraskan Azure SQL Database dengan kemampuan audit SQL Server dan Azure SQL Managed Instance.

Perubahan ini memastikan bahwa tidak ada detail kueri penting yang hilang, membantu tim keamanan dan kepatuhan mempertahankan pengawasan yang kuat.

Keterbatasan dalam audit

  • Mengaktifkan audit pada kumpulan Azure Synapse SQL yang dijeda tidak didukung. Untuk mengaktifkan audit, aktifkan kembali kumpulan Synapse SQL.

  • Mengaktifkan audit dengan menggunakan User Assigned Managed Identity (UAMI) tidak didukung di Azure Synapse.

  • Saat ini, identitas terkelola tidak didukung untuk Azure Synapse, kecuali akun penyimpanan berada di belakang jaringan virtual atau firewall.

  • Karena kendala performa, kami tidak mengaudit tempdb dan tabel 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 kumpulan Azure Synapse SQL hanya mendukung kelompok tindakan audit default.

  • Saat Anda mengonfigurasi audit untuk server logis 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 ID Microsoft Entra (sebelumnya 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 tingkat server dan tingkat database , karena database dengan ? dalam namanya tidak lagi didukung di Azure.

Keterangan

  • 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 penyimpanan tujuan umum v1 atau tujuan umum Blob, ditingkatkan ke akun penyimpanan tujuan umum v2. Untuk petunjuk khusus, lihat Menulis audit ke akun penyimpanan yang berada di belakang VNet dan firewall. Untuk informasi selengkapnya, lihat Jenis akun penyimpanan.

  • 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, catatan login yang gagal tidak muncul di log audit SQL. Untuk melihat catatan audit login yang gagal, Anda perlu mengunjungi pusat admin Microsoft Entra, yang mencatat detail peristiwa ini.

  • Login dialihkan oleh gateway ke instans tertentu di mana database berada. Dengan login Microsoft Entra, kredensial diverifikasi sebelum mencoba menggunakan pengguna tersebut untuk masuk 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 Perlindungan Ancaman Tingkat Lanjut SQL.

  • 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.