Playbook untuk menangani persyaratan keamanan umum dengan Azure SQL Database dan Azure SQL Managed Instance

  • Artikel

Berlaku untuk:Azure SQL DatabaseAzure SQL Managed Instance

Artikel ini menyediakan praktik terbaik tentang cara menyelesaikan persyaratan keamanan umum. Tidak semua persyaratan berlaku untuk semua lingkungan, dan Anda harus berkonsultasi dengan database dan tim keamanan Anda tentang fitur mana yang akan diterapkan.

Catatan

ID Microsoft Entra sebelumnya dikenal sebagai Azure Active Directory (Azure AD).

Menyelesaikan persyaratan keamanan umum

Dokumen ini menyediakan panduan tentang cara menyelesaikan persyaratan keamanan umum untuk aplikasi baru atau yang sudah ada menggunakan Azure SQL Database dan Azure SQL Managed Instance. Hal ini diatur oleh area keamanan tingkat tinggi. Untuk mengatasi ancaman tertentu, lihat bagian Ancaman keamanan umum dan mitigasi potensial. Meskipun beberapa rekomendasi yang disajikan berlaku saat memigrasikan aplikasi dari lokal ke Azure, skenario migrasi bukanlah fokus dokumen ini.

Penawaran penyebaran Azure SQL Database tercakup dalam panduan ini

Penyebaran tidak tercakup dalam panduan ini

  • Azure Synapse Analytics
  • Azure SQL VMs (infrastruktur sebagai layanan)
  • SQL Server

Audiens

Audiens yang dimaksudkan untuk panduan ini adalah pelanggan yang menghadapi pertanyaan tentang cara mengamankan Azure SQL Database. Peran yang tertarik pada artikel praktik terbaik ini meliputi, tetapi tidak terbatas pada:

  • Arsitek Keamanan
  • Manajer Keamanan
  • Pejabat Kepatuhan
  • Petugas Privasi
  • Insinyur Keamanan

Cara menggunakan panduan ini

Dokumen ini dimaksudkan sebagai pendamping dokumentasi Keamanan Azure SQL Database kami yang sudah ada.

Kecuali dinyatakan lain, kami rekomendasikan Anda mengikuti semua praktik terbaik yang tercantum di setiap bagian untuk mencapai tujuan atau persyaratan masing-masing. Untuk memenuhi standar kepatuhan keamanan tertentu atau praktik terbaik, kontrol kepatuhan terhadap peraturan penting tercantum di bawah bagian Persyaratan atau Tujuan di mana pun berlaku. Ini adalah standar keamanan dan peraturan yang dirujuk dalam makalah ini:

Kami berencana untuk terus memperbarui rekomendasi dan praktik terbaik yang tercantum di sini. Berikan masukan atau koreksi apa pun untuk dokumen ini menggunakan tautan Umpan Balik di bagian bawah artikel ini.

Autentikasi

Autentikasi adalah proses untuk membuktikan bahwa pengguna adalah yang mereka klaim. Azure SQL Database dan SQL Managed Instance mendukung dua jenis autentikasi:

  • Autentikasi SQL
  • Autentikasi Microsoft Entra

Catatan

Autentikasi Microsoft Entra mungkin tidak didukung untuk semua alat dan aplikasi pihak ke-3.

Manajemen pusat untuk identitas

Manajemen identitas pusat menawarkan keuntungan berikut:

  • Mengelola akun grup dan mengontrol izin pengguna tanpa menduplikasi data masuk di seluruh server, database, dan instans terkelola.
  • Manajemen izin yang disederhanakan dan fleksibel.
  • Manajemen aplikasi dalam skala besar.

Cara menerapkan

  • Gunakan autentikasi Microsoft Entra untuk manajemen identitas terpusat.

Praktik Terbaik

  • Buat penyewa Microsoft Entra dan buat pengguna untuk mewakili pengguna manusia dan buat perwakilan layanan untuk mewakili aplikasi, layanan, dan alat otomatisasi. Perwakilan layanan setara dengan akun layanan di Windows dan Linux.

  • Tetapkan hak akses ke sumber daya ke perwakilan Microsoft Entra melalui penetapan grup: Membuat grup Microsoft Entra, memberikan akses ke grup, dan menambahkan anggota individual ke grup. Di database Anda, buat pengguna database mandiri yang memetakan ke grup Microsoft Entra Anda. Untuk menetapkan izin di dalam database, tambahkan pengguna database mandiri yang mewakili grup Anda ke peran database, atau berikan izin kepada mereka secara langsung.

    Catatan

    Di SQL Managed Instance, Anda juga dapat membuat login yang memetakan ke perwakilan Microsoft Entra dalam master database. Lihat MEMBUAT DATA MASUK (T-SQL).

  • Menggunakan grup Microsoft Entra menyederhanakan manajemen izin dan pemilik grup, dan pemilik sumber daya dapat menambahkan/menghapus anggota ke/dari grup.

  • Buat grup terpisah untuk administrator Microsoft Entra untuk setiap server atau instans terkelola.

  • Pantau perubahan keanggotaan grup Microsoft Entra menggunakan laporan aktivitas audit ID Microsoft Entra.

  • Untuk instans terkelola, langkah terpisah diperlukan untuk membuat admin Microsoft Entra.

Catatan

  • Autentikasi Microsoft Entra dicatat di log audit Azure SQL, tetapi tidak di log masuk Microsoft Entra.
  • Izin Azure RBAC yang diberikan di Azure tidak berlaku untuk izin Azure SQL Database atau SQL Managed Instance. Izin tersebut harus dibuat/dipetakan secara manual menggunakan izin SQL yang ada.
  • Di sisi klien, autentikasi Microsoft Entra memerlukan akses ke internet atau melalui User Defined Route (UDR) ke jaringan virtual.
  • Token akses Microsoft Entra di-cache di sisi klien dan masa pakainya tergantung pada konfigurasi token. Lihat artikel, Masa pakai token yang dapat dikonfigurasi di ID Microsoft Entra
  • Untuk panduan tentang pemecahan masalah autentikasi Microsoft Entra, lihat blog berikut: Memecahkan masalah ID Microsoft Entra.

Autentikasi multifaktor Microsoft Entra

Disebutkan dalam: Praktik OSA #2, ISO Access Control (AC)

Autentikasi multifaktor Microsoft Entra membantu menyediakan keamanan tambahan dengan memerlukan lebih dari satu bentuk autentikasi.

Cara menerapkan

  • Aktifkan autentikasi multifaktor di ID Microsoft Entra menggunakan Akses Bersyar dan gunakan autentikasi interaktif.

  • Alternatifnya adalah mengaktifkan autentikasi multifaktor untuk seluruh penyewa Microsoft Entra atau domain Direktori Aktif.

Praktik Terbaik

  • Aktifkan Akses Bersyarat di ID Microsoft Entra (memerlukan langganan Premium).

  • Buat grup Microsoft Entra dan aktifkan kebijakan autentikasi multifaktor untuk grup yang dipilih menggunakan Microsoft Entra Conditional Access.

  • Autentikasi multifaktor dapat diaktifkan untuk seluruh penyewa Microsoft Entra atau untuk Direktori Aktif yang digabungkan dengan ID Microsoft Entra.

  • Gunakan mode autentikasi interaktif Microsoft Entra untuk Azure SQL Database dan Azure SQL Managed Instance tempat kata sandi diminta secara interaktif, diikuti oleh autentikasi multifaktor:

  • Terapkan aplikasi Anda untuk menyambungkan ke Azure SQL Database atau Azure SQL Managed Instance menggunakan autentikasi interaktif dengan dukungan autentikasi multifaktor.

    Catatan

    Mode autentikasi ini memerlukan identitas berbasis pengguna. Dalam kasus di mana model identitas tepercaya digunakan yang melewati autentikasi pengguna Microsoft Entra individual (misalnya, menggunakan identitas terkelola untuk sumber daya Azure), autentikasi multifaktor tidak berlaku.

Mengecilkan penggunaan autentikasi berbasis kata sandi untuk pengguna

Disebutkan dalam: Praktik OSA #4, ISO Access Control (AC)

Metode autentikasi berbasis kata sandi adalah bentuk autentikasi yang lebih lemah. Informasi masuk dapat disusupi atau diberikan secara keliru.

Cara menerapkan

  • Gunakan autentikasi terintegrasi Microsoft Entra yang menghilangkan penggunaan kata sandi.

Praktik Terbaik

  • Gunakan autentikasi akses menyeluruh menggunakan informasi masuk Windows. Federasi domain Active Directory lokal dengan ID Microsoft Entra dan gunakan autentikasi Windows terintegrasi (untuk komputer yang bergabung dengan domain dengan ID Microsoft Entra).

Mengecilkan penggunaan autentikasi berbasis kata sandi untuk aplikasi

Disebutkan dalam: Praktik OSA #4, ISO Access Control (AC)

Cara menerapkan

  • Aktifkan Identitas Terkelola Azure. Anda juga dapat menggunakan autentikasi terintegrasi atau berbasis sertifikat.

Praktik Terbaik

Lindungi kata sandi dan rahasia

Untuk kasus saat kata sandi tidak dapat dihindari, pastikan kata sandi diamankan.

Cara menerapkan

  • Gunakan Azure Key Vault untuk menyimpan kata sandi dan rahasia. Setiap kali berlaku, gunakan autentikasi multifaktor untuk Azure SQL Database dengan pengguna Microsoft Entra.

Praktik Terbaik

  • Jika menghindari kata sandi atau rahasia tidak dimungkinkan, simpan kata sandi pengguna dan rahasia aplikasi di Azure Key Vault, dan kelola akses melalui kebijakan akses Key Vault.

  • Berbagai kerangka kerja pengembangan aplikasi juga dapat menawarkan mekanisme khusus kerangka kerja untuk melindungi rahasia di aplikasi. Misalnya: Aplikasi core ASP.NET.

Gunakan autentikasi SQL untuk aplikasi warisan

Autentikasi SQL mengacu pada autentikasi pengguna saat menyambungkan ke Azure SQL Database atau SQL Managed Instance menggunakan nama pengguna dan kata sandi. Data masuk perlu dibuat di setiap server atau instans terkelola, dan pengguna dibuat di setiap database.

Cara menerapkan

  • Gunakan autentikasi SQL.

Praktik Terbaik

Manajemen akses

Manajemen akses (juga disebut Otorisasi) adalah proses mengontrol dan mengelola akses dan hak istimewa pengguna yang sah ke Azure SQL Database atau SQL Managed Instance.

Menerapkan prinsip hak istimewa paling sedikit

Disebutkan dalam: FedRamp mengontrol AC-06, NIST: AC-6, Praktik OSA #3

Prinsip hak istimewa paling sedikit menyatakan bahwa pengguna seharusnya tidak memiliki lebih banyak hak istimewa daripada yang diperlukan untuk menyelesaikan tugas mereka. Untuk informasi selengkapnya, lihat artikel Administrasi secukupnya saja.

Cara menerapkan

Tetapkan hanya izin yang diperlukan untuk menyelesaikan tugas yang diperlukan:

  • Dalam SQL Database:

    • Gunakan izin terperinci dan peran database yang ditentukan pengguna (atau peran server di SQL Managed Instance):
      1. Membuat peran yang diperlukan
      2. Membuat pengguna yang diperlukan
      3. Menambahkan pengguna sebagai anggota ke peran
      4. Kemudian tetapkan izin untuk peran.
    • Pastikan untuk tidak menetapkan pengguna ke peran yang tidak perlu.

  • Dalam Azure Resource Manager:

Praktik Terbaik

Praktik terbaik berikut bersifat opsional tetapi akan menghasilkan pengelolaan dan dukungan strategi keamanan Anda dengan lebih baik:

  • Jika memungkinkan, mulailah dengan set izin yang paling tidak mungkin dan mulai tambahkan izin satu per satu jika ada kebutuhan nyata (dan pembenaran) – sebagai lawan dari pendekatan sebaliknya: mencabut izin selangkah demi selangkah.

  • Menahan diri dari menetapkan izin kepada pengguna individu. Gunakan peran (peran database atau server) secara konsisten sebagai gantinya. Peran sangat membantu dengan izin pelaporan dan pemecahan masalah. (Azure RBAC hanya mendukung penetapan izin melalui peran.)

  • Buat dan gunakan peran kustom dengan izin tepat yang diperlukan. Peran umum yang digunakan dalam praktik:

    • Penyebaran keamanan
    • Administrator
    • Pengembang
    • Personel pendukung
    • Auditor
    • Proses otomatis
    • Pengguna akhir

  • Gunakan peran bawaan hanya jika izin peran sama persis dengan izin yang diperlukan untuk pengguna. Anda dapat menetapkan pengguna ke beberapa peran.

  • Ingat bahwa izin di mesin database dapat diterapkan dalam cakupan berikut (semakin kecil cakupannya, semakin kecil dampak dari izin yang diberikan):

    • Server (peran khusus dalam master database) di Azure
    • Database
    • Skema
      • Ini adalah praktik terbaik untuk menggunakan skema untuk memberikan izin di dalam database.
    • Objek (tabel, tampilan, prosedur, dan sebagainya)

    Catatan

    Tidak disarankan untuk menerapkan izin pada tingkat objek karena tingkat ini menambahkan kompleksitas yang tidak perlu ke penerapan keseluruhan. Jika Anda memutuskan untuk menggunakan izin tingkat objek, izin tersebut harus didokumentasikan dengan jelas. Hal yang sama berlaku untuk izin tingkat kolom, yang bahkan kurang direkomendasikan karena alasan yang sama. Perlu diketahui juga bahwa secara default TOLAK tingkat tabel tidak mengambil alih BERI tingkat kolom. Ini akan membutuhkan Konfigurasi Server kepatuhan kriteria umum diaktifkan.

  • Lakukan pemeriksaan rutin menggunakan Vulnerability Assessment (VA) untuk menguji terlalu banyak izin.

Menerapkan Pemisahan Tugas

Disebutkan dalam: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Pemisahan Tugas, juga disebut Segregasi Tugas menjelaskan persyaratan untuk membagi tugas sensitif menjadi beberapa tugas yang ditetapkan untuk pengguna yang berbeda. Pemisahan Tugas membantu mencegah pelanggaran data.

Cara menerapkan

  • Identifikasi tingkat Pemisahan Tugas yang diperlukan. Contoh:

    • Antara lingkungan Pengembangan/Pengujian dan Produksi
    • Tugas sensitif dari segi keamanan vs tugas tingkat manajemen Administrator Database (DBA) vs tugas pengembang.
      • Contoh: Auditor, pembuatan kebijakan keamanan untuk Keamanan Tingkat Peran (RLS), Menerapkan objek SQL Database dengan izin DDL.

  • Identifikasi hierarki pengguna yang komprehensif (dan proses otomatis) yang mengakses sistem.

  • Buat peran sesuai dengan grup pengguna yang diperlukan dan tetapkan izin ke peran.

    • Untuk tugas tingkat manajemen di portal Microsoft Azure atau melalui otomatisasi PowerShell menggunakan peran Azure. Temukan peran bawaan yang cocok dengan persyaratan, atau membuat peran kustom Azure menggunakan izin yang tersedia
    • Buat peran Server untuk tugas di seluruh server (membuat data masuk baru, database) dalam instans terkelola.
    • Buat Peran Database untuk tugas tingkat database.

  • Untuk tugas sensitif tertentu, pertimbangkan untuk membuat prosedur tersimpan khusus yang ditandatangani oleh sertifikat untuk menjalankan tugas atas nama pengguna. Salah satu keuntungan penting dari prosedur tersimpan yang ditandatangani secara digital adalah bahwa jika prosedur diubah, izin yang diberikan ke versi prosedur sebelumnya segera dihapus.

  • Terapkan Enkripsi Data Transparan (TDE) dengan kunci yang dikelola pelanggan di Azure Key Vault untuk mengaktifkan Pemisahan Tugas antara pemilik data dan pemilik keamanan.

  • Untuk memastikan bahwa DBA tidak dapat melihat data yang dianggap sangat sensitif dan masih dapat melakukan tugas DBA, Anda dapat menggunakan Always Encrypted dengan pemisahan peran.

  • Jika penggunaan Always Encrypted tidak memungkinkan, atau setidaknya tidak tanpa biaya dan upaya besar yang bahkan merender sistem hampir tidak dapat digunakan, penyusupan dapat dilakukan dan dimitigasi melalui penggunaan kontrol kompensasi seperti:

Praktik Terbaik

  • Pastikan bahwa akun yang berbeda digunakan untuk lingkungan Pengembangan/Pengujian dan Produksi. Akun yang berbeda membantu mematuhi pemisahan sistem Uji dan Produksi.

  • Menahan diri dari menetapkan izin kepada pengguna individu. Gunakan peran (peran database atau server) secara konsisten sebagai gantinya. Memiliki peran sangat membantu dengan izin pelaporan dan pemecahan masalah.

  • Gunakan peran bawaan saat izin cocok dengan izin yang diperlukan – jika penyatan semua izin dari beberapa peran bawaan mengarah ke kecocokan 100%, Anda juga dapat menetapkan beberapa peran secara bersamaan.

  • Membuat dan menggunakan peran yang ditentukan pengguna saat peran bawaan memberikan terlalu banyak izin atau izin yang tidak memadai.

  • Penetapan peran juga dapat dilakukan sementara, juga dikenal sebagai Pemisahan Tugas Dinamis (DSD), baik dalam langkah-langkah Kerja Agen SQL di T-SQL atau menggunakan Azure PIM untuk peran Azure.

  • Pastikan DBA tidak memiliki akses ke kunci enkripsi atau penyimpanan kunci, dan Administrator Keamanan dengan akses ke kunci tersebut tidak memiliki akses ke database secara bergantian. Penggunaan Extensible Key Management (EKM) dapat membuat pemisahan ini lebih mudah dicapai. Azure Key Vault dapat digunakan untuk menerapkan EKM.

  • Selalu pastikan untuk memiliki Jejak audit untuk tindakan terkait keamanan.

  • Anda dapat mengambil definisi peran bawaan Azure untuk melihat izin yang digunakan dan membuat peran kustom berdasarkan kutipan dan akumulasi ini melalui PowerShell.

  • Karena setiap anggota peran database db_owner dapat mengubah pengaturan keamanan seperti Enkripsi Data Transparan (TDE), atau mengubah SLO, keanggotaan ini harus diberikan dengan hati-hati. Namun, ada banyak tugas yang memerlukan hak istimewa db_owner. Tugas seperti mengubah pengaturan database apa pun seperti mengubah opsi DB. Pengauditan memainkan peran kunci dalam solusi apa pun.

  • Tidak dimungkinkan untuk membatasi izin db_owner, dan oleh karena itu mencegah akun administratif melihat data pengguna. Jika ada data yang sangat sensitif dalam database, Always Encrypted dapat digunakan untuk mencegah dengan aman db_owners atau DBA lain untuk melihatnya.

Catatan

Mencapai Pemisahan Tugas (SoD) sangat menantang untuk tugas terkait keamanan atau pemecahan masalah. Area lain seperti pengembangan dan peran pengguna akhir lebih mudah disegregasi. Sebagian besar kontrol terkait kepatuhan memungkinkan penggunaan fungsi kontrol alternatif seperti Pengauditan saat solusi lain tidak praktis.

Untuk pembaca yang ingin menyelam lebih dalam ke SoD, kami merekomendasikan sumber daya berikut:

Lakukan ulasan kode reguler

Disebutkan dalam: PCI: 6.3.2, SOC: SDL-3

Pemisahan Tugas tidak terbatas pada data dalam database, tetapi menyertakan kode aplikasi. Kode berbahaya berpotensi menggagalkan kontrol keamanan. Sebelum menyebarkan kode kustom ke produksi, penting untuk mengulas apa yang sedang disebarkan.

Cara menerapkan

  • Gunakan alat database seperti Azure Data Studio yang mendukung kontrol sumber.

  • Menerapkan proses penyebaran kode yang disegregasi.

  • Sebelum menerapkan pada cabang utama, seseorang (selain pembuat kode itu sendiri) harus memeriksa kode untuk potensi elevasi risiko serta modifikasi data berbahaya untuk melindungi dari penipuan dan akses nakal. Ini dapat dilakukan menggunakan mekanisme kontrol sumber.

Praktik Terbaik

  • Standardisasi: Ini membantu menerapkan prosedur standar yang harus diikuti untuk pembaruan kode apa pun.

  • Penilaian Kerentanan berisi aturan yang memeriksa izin berlebihan, penggunaan algoritme enkripsi lama, dan masalah keamanan lainnya dalam skema database.

  • Pemeriksaan lebih lanjut dapat dilakukan di lingkungan QA atau pengujian menggunakan Perlindungan Ancaman Tingkat Lanjut yang memindai kode yang rentan terhadap SQL-injection.

  • Contoh apa yang harus diperhatikan:

    • Pembuatan pengguna atau mengubah pengaturan keamanan dari dalam penyebaran pembaruan kode SQL otomatis.
    • Prosedur tersimpan, yang tergantung pada parameter yang disediakan, memperbarui nilai moneter dalam sel dengan cara yang tidak sesuai.

  • Pastikan orang yang melakukan pengulasan adalah individu selain pembuat kode asal dan berpengetahuan luas dalam ulasan kode dan pengkodean yang aman.

  • Pastikan untuk mengetahui semua sumber perubahan kode. Kode dapat dalam Skrip T-SQL. Ini dapat berupa perintah ad hoc yang akan dijalankan atau disebarkan dalam bentuk Tampilan, Fungsi, Pemicu, dan Prosedur Tersimpan. Ini dapat menjadi bagian dari definisi Kerja Agen SQL (Langkah-langkah). Ini juga dapat dijalankan dari dalam paket SSIS, Azure Data Factory, dan layanan lainnya.

Perlindungan data

Perlindungan data adalah set kemampuan untuk melindungi informasi penting dari penyusupan dengan enkripsi atau pengaburan.

Catatan

Microsoft membuktikan Azure SQL Database dan SQL Managed Instance sesuai dengan FIPS 140-2 Tingkat 1. Ini dilakukan setelah memverifikasi penggunaan ketat algoritma yang dapat diterima FIPS 140-2 Tingkat 1 dan instans tervalidasi FIPS 140-2 Tingkat 1 dari algoritma tersebut termasuk konsistensi dengan panjang kunci yang diperlukan, manajemen kunci, pembuatan kunci, dan penyimpanan kunci. Pengesahan ini dimaksudkan untuk memungkinkan pelanggan kami menanggapi kebutuhan atau persyaratan untuk penggunaan instans tervalidasi FIPS 140-2 Tingkat 1 dalam pemrosesan data atau pengiriman sistem atau aplikasi. Kami mendefinisikan istilah "sesuai FIPS 140-2 Tingkat 1" dan "kepatuhan FIPS 140-2 Tingkat 1" yang digunakan dalam pernyataan di atas untuk menunjukkan penerapan yang dimaksudkan untuk penggunaan istilah berbeda "FIPS 140-2 Tingkat 1 tervalidasi" oleh pemerintah Kanada dan pemerintah Kanada.

Mengenkripsi data dalam transit

Disebutkan dalam: Praktik OSA #6, ISO Control Family: Cryptography

Melindungi data Anda saat data berpindah antara klien dan server Anda. Lihat Keamanan Jaringan.

Mengenkripsi data tidak aktif

Disebutkan dalam: Praktik OSA #6, ISO Control Family: Cryptography

Enkripsi tidak aktif adalah perlindungan kriptografi data ketika dipertahankan dalam database, log, dan file cadangan.

Cara menerapkan

  • Enkripsi data transparan (TDE) dengan kunci terkelola layanan diaktifkan secara default untuk database apa pun yang dibuat setelah 2017 di Azure SQL Database dan SQL Managed Instance.
  • Dalam instans terkelola, jika database dibuat dari operasi pemulihan menggunakan server lokal, pengaturan TDE dari database asli akan digunakan. Jika database asli tidak mengaktifkan TDE, kami merekomendasikan agar TDE diaktifkan secara manual untuk instans terkelola.

Praktik Terbaik

  • Jangan menyimpan data yang memerlukan enkripsi saat tidak aktif dalam master database. Database master tidak dapat dienkripsi dengan TDE.

  • Gunakan kunci yang dikelola pelanggan di Azure Key Vault jika Anda memerlukan peningkatan transparansi dan kontrol terperinci atas perlindungan TDE. Azure Key Vault memungkinkan kemampuan untuk mencabut izin kapan saja untuk merender database tidak dapat diakses. Anda dapat mengelola pelindung TDE secara terpusat bersama dengan kunci lain, atau memutar pelindung TDE sesuai jadwal Anda sendiri menggunakan Azure Key Vault.

  • Jika Anda menggunakan kunci yang dikelola pelanggan di Azure Key Vault, ikuti artikel, Panduan untuk mengonfigurasi TDE dengan Azure Key Vault dan Cara mengonfigurasi Geo-DR dengan Azure Key Vault.

Catatan

Beberapa item yang dianggap sebagai konten pelanggan, seperti nama tabel, nama objek, dan nama indeks, dapat dikirimkan dalam file log untuk dukungan dan pemecahan masalah oleh Microsoft.

Lindungi data sensitif yang digunakan dari pengguna dengan hak istimewa tinggi dan tidak sah

Data yang digunakan adalah data yang disimpan dalam memori sistem database selama eksekusi kueri SQL. Jika database Anda menyimpan data sensitif, organisasi Anda mungkin diperlukan untuk memastikan bahwa pengguna dengan hak istimewa tinggi dicegah untuk melihat data sensitif di database Anda. Pengguna hak istimewa tinggi, seperti operator Microsoft atau DBA di organisasi Anda harus dapat mengelola database, tetapi dicegah untuk melihat dan berpotensi menyelundupkan data sensitif dari memori proses SQL atau dengan mengkueri database.

Kebijakan yang menentukan data mana yang sensitif dan apakah data sensitif harus dienkripsi dalam memori dan tidak dapat diakses oleh admin dalam teks biasa, khusus untuk organisasi dan peraturan kepatuhan yang perlu Anda patuhi. Lihat persyaratan terkait: Mengidentifikasi dan menandai data sensitif.

Cara menerapkan

  • Gunakan Always Encrypted untuk memastikan data sensitif tidak diekspos dalam teks biasa di Azure SQL Database atau SQL Managed Instance, bahkan dalam memori/penggunaan. Always Encrypted melindungi data dari Administrator Database (DBA) dan admin cloud (atau aktor buruk yang dapat menyamar sebagai pengguna dengan hak istimewa tinggi tetapi tidak sah) dan memberi Anda kontrol lebih atas siapa yang dapat mengakses data Anda.

Praktik Terbaik

  • Always Encrypted bukan pengganti untuk mengenkripsi data tidak aktif (TDE) atau dalam transit (SSL/TLS). Always Encrypted tidak boleh digunakan untuk data yang tidak sensitif untuk mengecilkan dampak performa dan fungsionalitas. Menggunakan Always Encrypted bersama dengan TDE dan Keamanan Lapisan Transportasi (TLS) direkomendasikan untuk perlindungan komprehensif data tidak aktif, dalam transit, dan sedang digunakan.

  • Menilai dampak mengenkripsi kolom data sensitif yang diidentifikasi sebelum Anda menyebarkan Always Encrypted dalam database produksi. Secara umum, Always Encrypted mengurangi fungsionalitas kueri pada kolom terenkripsi dan memiliki batasan lain, tercantum di Always Encrypted - Detail Fitur. Oleh karena itu, Anda mungkin perlu merancang kembali aplikasi Anda untuk menerapkan kembali fungsionalitas, kueri tidak mendukung, di sisi klien atau/dan melakukan refaktor pada skema database Anda, termasuk definisi prosedur tersimpan, fungsi, tampilan, dan pemicu. Aplikasi yang ada mungkin tidak berfungsi dengan kolom terenkripsi jika tidak mematuhi larangan dan batasan Always Encrypted. Sementara ekosistem alat, produk, dan layanan Microsoft yang mendukung Always Encrypted semakin berkembang, beberapa di antaranya tidak berfungsi dengan kolom terenkripsi. Mengenkripsi kolom juga dapat memengaruhi performa kueri, bergantung pada karakteristik beban kerja Anda.

  • Kelola kunci Always Encrypted dengan pemisahan peran jika Anda menggunakan Always Encrypted untuk melindungi data dari DBA yang berbahaya. Dengan pemisahan peran, admin keamanan membuat kunci fisik. DBA membuat kunci master kolom dan objek metadata kunci enkripsi kolom yang menjelaskan kunci fisik dalam database. Selama proses ini, admin keamanan tidak memerlukan akses ke database, dan DBA tidak memerlukan akses ke kunci fisik dalam teks biasa.

  • Simpan kunci master kolom Anda di Azure Key Vault untuk memudahkan manajemen. Hindari menggunakan Windows Certificate Store (dan secara umum, solusi penyimpanan kunci terdistribusi, sebagai solusi manajemen kunci pusat yang berlawanan) yang mempersulit manajemen kunci.

  • Pikirkan dengan cermat melalui tradeoff menggunakan beberapa kunci (kunci master kolom atau kunci enkripsi kolom). Jaga agar jumlah kunci tetap sedikit untuk mengurangi biaya manajemen kunci. Satu kunci master kolom dan satu kunci enkripsi kolom per database biasanya cukup di lingkungan yang stabil (bukan di tengah rotasi kunci). Anda mungkin memerlukan kunci tambahan jika memiliki grup pengguna yang berbeda, masing-masing menggunakan kunci yang berbeda dan mengakses data yang berbeda.

  • Putar kunci master kolom sesuai persyaratan kepatuhan Anda. Jika Anda juga perlu memutar kunci enkripsi kolom, pertimbangkan untuk menggunakan enkripsi online untuk mengecilkan waktu henti aplikasi.

  • Gunakan enkripsi deterministik jika komputasi (kesetaraan) pada data perlu didukung. Jika tidak, gunakan enkripsi yang diacak. Hindari menggunakan enkripsi deterministik untuk set data entropi rendah, atau set data dengan distribusi yang diketahui publik.

  • Jika Anda khawatir tentang pihak ketiga yang mengakses data Anda secara legal tanpa persetujuan Anda, pastikan bahwa semua aplikasi dan alat yang memiliki akses ke kunci dan data di teks biasa berjalan di luar Microsoft Azure Cloud. Tanpa akses ke kunci, pihak ketiga tidak akan memiliki cara untuk mendekripsi data kecuali mereka melewati enkripsi.

  • Always Encrypted tidak mudah mendukung pemberian akses sementara ke kunci (dan data yang dilindungi). Misalnya, jika Anda perlu berbagi kunci dengan DBA untuk memungkinkan DBA melakukan beberapa operasi pembersihan pada data sensitif dan terenkripsi. Satu-satunya cara untuk secara andal mencabut akses ke data dari DBA adalah dengan memutar kunci enkripsi kolom dan kunci master kolom yang melindungi data, yang merupakan operasi yang mahal.

  • Untuk mengakses nilai teks biasa di kolom terenkripsi, pengguna harus memiliki akses ke Kunci Master Kolom (CMK) yang melindungi kolom, yang dikonfigurasi di penyimpanan kunci yang menahan CMK. Pengguna juga harus memiliki izin database VIEW ANY COLUMN MASTER KEY DEFINITION dan VIEW ANY COLUMN ENCRYPTION KEY DEFINITION.

Mengontrol akses pengguna aplikasi ke data sensitif melalui enkripsi

Enkripsi dapat digunakan sebagai cara untuk memastikan bahwa hanya pengguna aplikasi tertentu yang memiliki akses ke kunci kriptografi yang dapat melihat atau memperbarui data.

Cara menerapkan

  • Gunakan Enkripsi Tingkat Sel (CLE). Lihat artikel, Mengenkripsi Kolom Data untuk detailnya.
  • Gunakan Always Encrypted, tetapi waspadalah dengan batasannya. Batasannya tercantum di bawah ini.

Praktik terbaik:

Saat menggunakan CLE:

  • Kontrol akses ke kunci melalui izin dan peran SQL.

  • Gunakan Standar Enkripsi Lanjutan (direkomendasikan Standar Enkripsi Lanjutan 256) untuk enkripsi data. Algoritma, seperti RC4, DES dan TripleDES, tidak digunakan lagi dan tidak boleh digunakan karena kerentanan yang diketahui.

  • Lindungi kunci konten dengan kunci/sertifikat asimetris (bukan kata sandi) untuk menghindari penggunaan 3DES.

  • Berhati-hatilah saat memigrasikan database Enkripsi Tingkat Sel melalui ekspor/impor (file bacpac).

Perlu diingat bahwa Always Encrypted terutama didesain untuk melindungi data sensitif yang digunakan dari pengguna hak istimewa tinggi Azure SQL Database (operator cloud, DBAs) - lihat Melindungi data sensitif yang digunakan dari pengguna hak istimewa tinggi dan tidak sah. Ketahui tantangan berikut saat menggunakan Always Encrypted untuk melindungi data dari pengguna aplikasi:

  • Secara default, semua driver klien Microsoft yang mendukung Always Encrypted mempertahankan cache global (satu per aplikasi) kunci enkripsi kolom. Setelah driver klien memperoleh kunci enkripsi kolom teks biasa dengan menghubungi penyimpanan kunci yang memegang kunci master kolom, kunci enkripsi kolom teks biasa di-cache. Ini membuat mengisolasi data dari pengguna aplikasi multi-pengguna menantang. Jika aplikasi Anda meniru pengguna akhir saat berinteraksi dengan penyimpanan kunci (seperti Azure Key Vault), setelah kueri pengguna mengisi cache dengan kunci enkripsi kolom, kueri berikutnya yang memerlukan kunci yang sama tetapi dipicu oleh pengguna lain akan menggunakan kunci yang di-cache. Driver tidak akan memanggil penyimpanan kunci dan tidak akan memeriksa apakah pengguna kedua memiliki izin untuk mengakses kunci enkripsi kolom. Akibatnya, pengguna dapat melihat data terenkripsi bahkan jika pengguna tidak memiliki akses ke kunci. Untuk mencapai isolasi pengguna dalam aplikasi multi-pengguna, Anda dapat menonaktifkan penembolokan kunci enkripsi kolom. Menonaktifkan penembolokan akan menyebabkan overhead performa tambahan, karena driver perlu menghubungi penyimpanan kunci untuk setiap enkripsi data atau operasi dekripsi.

Lindungi data dari tampilan yang tidak sah oleh pengguna aplikasi sambil mempertahankan format data

Teknik lain untuk mencegah pengguna yang tidak sah melihat data adalah mengaburkan atau menutupi data sambil mempertahankan jenis dan format data untuk memastikan bahwa aplikasi pengguna dapat terus menangani dan menampilkan data.

Cara menerapkan

Catatan

Always Encrypted tidak berfungsi dengan Masking Data Dinamis. Tidak mungkin untuk mengenkripsi dan menutupi kolom yang sama, yang menyiratkan bahwa Anda perlu memangkatkan melindungi data yang digunakan vs. menutupi data untuk pengguna aplikasi Anda melalui Masking Data Dinamis.

Praktik Terbaik

Catatan

Masking Data Dinamis tidak dapat digunakan untuk melindungi data dari pengguna dengan hak istimewa tinggi. Kebijakan masking tidak berlaku untuk pengguna dengan akses administratif seperti db_owner.

  • Jangan izinkan pengguna aplikasi untuk menjalankan kueri ad hoc (karena mereka mungkin dapat mengatasi Masking Data Dinamis).

  • Gunakan kebijakan kontrol akses yang tepat (melalui izin SQL, peran, RLS) untuk membatasi izin pengguna untuk membuat pembaruan di kolom bermasker. Membuat masker pada kolom tidak mencegah pembaruan pada kolom tersebut. Pengguna yang menerima data bermasker saat mengkueri kolom bermasker, dapat memperbarui data jika mereka memiliki izin tulis.

  • Masking Data Dinamis tidak mempertahankan properti statistik dari nilai bermasker. Ini dapat memengaruhi hasil kueri (misalnya, kueri yang berisi predikat pemfilteran atau gabungan pada data bermasker).

Keamanan jaringan

Keamanan jaringan mengacu pada kontrol akses dan praktik terbaik untuk mengamankan data Anda saat transit ke Azure SQL Database.

Mengonfigurasi klien saya untuk tersambung dengan aman ke SQL Database/SQL Managed Instance

Praktik terbaik tentang cara mencegah mesin dan aplikasi klien dengan kerentanan terkenal (misalnya, menggunakan protokol TLS dan suite cipher yang lebih lama) agar tidak tersambung ke Azure SQL Database dan SQL Managed Instance.

Cara menerapkan

Praktik Terbaik

  • Terapkan versi TLS minimal di server SQL Database atau tingkat SQL Managed Instance menggunakan pengaturan versi TLS minimal. Kami merekomendasikan Anda mengatur versi TLS minimal ke 1.2, setelah melakukan pengujian untuk mengonfirmasi aplikasi mendukungnya. TLS 1.2 menyertakan perbaikan untuk kerentanan yang ditemukan dalam versi sebelumnya.

  • Mengonfigurasi semua aplikasi dan alat Anda untuk terhubung ke SQL Database dengan enkripsi diaktifkan

    • Encrypt = On, TrustServerCertificate = Off (atau setara dengan driver non-Microsoft).

  • Jika aplikasi Anda menggunakan driver yang tidak mendukung TLS atau mendukung TLS versi lama, ganti driver, jika memungkinkan. Jika tidak memungkinkan, evaluasi risiko keamanan dengan hati-hati.

Kecilkan permukaan serangan

Kecilkan jumlah fitur yang dapat diserang oleh pengguna yang berbahaya. Terapkan kontrol akses jaringan untuk Azure SQL Database.

Disebutkan dalam: OSA Practice #5

Cara menerapkan

Dalam SQL Database:

  • Mengatur Perbolehkan Akses ke layanan Azure menjadi OFF di tingkat server
  • Gunakan titik akhir Layanan VNet dan Aturan Firewall VNet.
  • Gunakan Private Link.

Dalam SQL Managed Instance:

Praktik Terbaik

  • Membatasi akses ke Azure SQL Database dan SQL Managed Instance dengan menyambungkan di titik akhir privat (misalnya, menggunakan jalur data privat):

    • Instans terkelola dapat diisolasi di dalam jaringan virtual untuk mencegah akses eksternal. Aplikasi dan alat yang berada di jaringan virtual yang sama atau direkankan di wilayah yang sama dapat mengaksesnya secara langsung. Aplikasi dan alat yang berada di wilayah yang berbeda dapat menggunakan koneksi virtual-jaringan-ke-virtual-jaringan atau perekanan sirkuit ExpressRoute untuk membangun koneksi. Pelanggan harus menggunakan Kelompok Keamana Jaringan (NSG) untuk membatasi akses melalui port 1433 hanya untuk sumber daya yang memerlukan akses ke instans terkelola.
    • Untuk SQL Database, gunakan fitur Private Link yang menyediakan IP privat khusus untuk server di dalam jaringan virtual Anda. Anda juga dapat menggunakan Titik akhir layanan jaringan virtual dengan aturan firewall jaringan virtual untuk membatasi akses ke server Anda.
    • Pengguna seluler harus menggunakan koneksi VPN titik-ke-situs untuk menyambungkan melalui jalur data.
    • Pengguna yang terhubung ke jaringan lokalnya harus menggunakan koneksi VPN situs-ke-situs atau ExpressRoute untuk menyambungkan melalui jalur data.

  • Anda dapat mengakses Azure SQL Database dan SQL Managed Instance dengan menyambungkan ke titik akhir publik (misalnya, menggunakan jalur data publik). Praktik terbaik berikut harus dipertimbangkan:

    Catatan

    Titik akhir publik SQL Managed Instance tidak diaktifkan secara default dan harus diaktifkan secara eksplisit. Jika kebijakan perusahaan melarang penggunaan titik akhir publik, gunakan Azure Policy untuk mencegah mengaktifkan titik akhir publik.

  • Menyiapkan komponen Azure Networking:

Mengonfigurasikan Power BI untuk koneksi aman ke SQL Database/SQL Managed Instance

Praktik Terbaik

Mengonfigurasikan App Service untuk koneksi aman ke SQL Database/SQL Managed Instance

Praktik Terbaik

Mengonfigurasi hosting Azure Virtual Machine untuk koneksi aman ke SQL Database/SQL Managed Instance

Praktik Terbaik

  • Gunakan kombinasi aturan Izinkan dan Tolak pada NSG komputer virtual Azure untuk mengontrol wilayah mana yang dapat diakses dari komputer virtual.

  • Pastikan komputer virtual Anda dikonfigurasi sesuai artikel, Praktik terbaik keamanan untuk beban kerja infrastruktur sebagai layanan di Azure.

  • Pastikan bahwa semua komputer virtual dikaitkan dengan jaringan virtual dan subnet tertentu.

  • Evaluasi jika Anda memerlukan rute default 0.0.0.0/Internet sesuai panduan tentang penerowongan paksa.

    • Jika ya – misalnya, subnet front-end - pertahankan rute default.
    • Jika tidak – misalnya, subnet tingkat tengah atau back-end – aktifkan penerowongan paksa sehingga tidak ada lalu lintas yang melalui internet untuk mencapai lokal (alias lintas tempat).

  • Terapkan rute default opsional jika Anda menggunakan perekanan atau menyambungkan ke lokal.

  • Terapkan Rute Yang Ditentukan Pengguna jika Anda perlu mengirim semua lalu lintas di jaringan virtual ke Network Virtual Appliance untuk inspeksi paket.

  • Gunakan titik akhir layanan jaringan virtual untuk akses aman ke layanan PaaS seperti Azure Storage melalui jaringan backbone Azure.

Lindungi dari serangan Distributed Denial of Service (DDoS)

Serangan Distributed Denial of Service (DDoS) adalah upaya pengguna berbahaya untuk mengirim flood lalu lintas jaringan ke Azure SQL Database dengan tujuan untuk membanjiri infrastruktur Azure dan menyebabkannya menolak data masuk dan beban kerja yang valid.

Disebutkan dalam: Praktik OSA #9

Cara menerapkan

Perlindungan DDoS secara otomatis diaktifkan sebagai bagian dari Platform Azure. Ini termasuk pemantauan lalu lintas yang selalu ada dan mitigasi real time serangan tingkat jaringan pada titik akhir publik.

Praktik Terbaik

  • Ikuti praktik yang dijelaskan dalam Mengecilkan Permukaan Serangan membantu mengecilkan ancaman serangan DDoS.

  • Pemberitahuan informasi masuk Perlindungan Ancaman Tingkat Lanjut Informasi masuk brute force SQL membantu mendeteksi serangan brute force. Dalam beberapa kasus, pemberitahuan bahkan dapat membedakan beban kerja uji penetrasi.

  • Untuk aplikasi hosting komputer virtual Azure yang terhubung ke SQL Database:

    • Ikuti rekomendasi untuk Membatasi akses melalui titik akhir yang menuju Internet di Pertahanan Microsoft untuk Cloud.
    • Gunakan set skala komputer virtual untuk menjalankan beberapa instans aplikasi Anda di komputer virtual Azure.
    • Nonaktifkan RDP dan SSH dari internet untuk mencegah serangan brute force.

Pemantauan, pengelogan, dan audit

Bagian ini mengacu pada kemampuan untuk membantu Anda mendeteksi aktivitas anomali yang menunjukkan upaya yang tidak biasa dan berpotensi berbahaya untuk mengakses atau mengeksploitasi database. Ini juga menjelaskan praktik terbaik untuk mengonfigurasi pengauditan database untuk melacak dan mengambil peristiwa database.

Lindungi database dari serangan

Perlindungan ancaman tingkat lanjut memungkinkan Anda mendeteksi dan menanggapi potensi ancaman saat terjadi dengan memberikan pemberitahuan keamanan pada aktivitas anomali.

Cara menerapkan

  • Gunakan Perlindungan Ancaman Tingkat Lanjut untuk SQL untuk mendeteksi upaya yang tidak biasa dan berpotensi berbahaya untuk mengakses atau mengeksploitasi database, termasuk:
    • Serangan injeksi SQL.
    • Informasi masuk pencurian/kebocoran.
    • Penyalahgunaan hak istimewa.
    • Eksfiltrasi data.

Praktik Terbaik

  • Konfigurasikan Pertahanan Microsoft untuk SQL untuk server tertentu atau instans terkelola. Anda juga dapat mengonfigurasi Pertahanan Microsoft untuk SQL bagi semua server dan instans terkelola dalam langganan dengan mengaktifkan Pertahanan Microsoft untuk Cloud.

  • Untuk pengalaman investigasi penuh, disarankan untuk mengaktifkan Pengauditan SQL Database. Dengan pengauditan, Anda dapat melacak peristiwa database dan menulisnya ke jejak audit di akun Azure Storage atau ruang kerja Analitik Log Azure.

Audit peristiwa keamanan kritis

Pelacakan peristiwa database membantu Anda memahami aktivitas database. Anda dapat memperoleh wawasan tentang perbedaan dan anomali yang dapat menunjukkan masalah bisnis atau dugaan pelanggaran keamanan. Ini juga memungkinkan dan memfasilitasi kepatuhan terhadap standar kepatuhan.

Cara menerapkan

  • AktifkanPengauditan SQL Database atau Pengauditan Instans Terkelola untuk melacak peristiwa database dan menulisnya ke jejak audit di akun Azure Storage Anda, ruang kerja Analitik Log (pratinjau), atau Pusat Aktivitas (pratinjau).

  • Jejak audit dapat ditulis ke akun Azure Storage, ke ruang kerja Analitik Log untuk digunakan oleh log Azure Monitor, atau ke hub peristiwa untuk digunakan menggunakan hub peristiwa. Anda dapat mengonfigurasi kombinasi opsi ini, dan jejak audit akan ditulis untuk masing-masing.

Praktik Terbaik

  • Dengan mengonfigurasi Pengauditan SQL Database di server Anda atau Pengauditan Instans Terkelola untuk mengaudit peristiwa, semua database yang ada dan baru dibuat di server tersebut akan diaudit.
  • Secara default kebijakan pengauditan mencakup semua tindakan (kueri, prosedur tersimpan dan data masuk yang berhasil dan gagal) terhadap database, yang dapat mengakibatkan volume jejak audit yang tinggi. Disarankan bagi pelanggan untuk mengonfigurasi pengauditan untuk berbagai jenis tindakan dan grup tindakan menggunakan PowerShell. Mengonfigurasi ini akan membantu mengontrol jumlah tindakan yang diaudit, dan mengecilkan risiko kehilangan peristiwa. Konfigurasi audit kustom memungkinkan pelanggan untuk mengambil hanya data audit yang diperlukan.
  • Jejak audit dapat digunakan langsung di portal Microsoft Azure, atau dari lokasi penyimpanan yang dikonfigurasi.

Catatan

Mengaktifkan pengauditan ke Analitik Log akan dikenakan biaya berdasarkan tingkat penggunaan. Perhatikan biaya terkait dengan menggunakan opsi ini, atau pertimbangkan untuk menyimpan jejak audit di akun penyimpanan Azure.

Sumber daya lebih lanjut

Amankan jejak audit

Batasi akses ke akun penyimpanan untuk mendukung Pemisahan Tugas dan memisahkan DBA dari Auditor.

Cara menerapkan

  • Saat menyimpan Jejak audit ke Azure Storage, pastikan bahwa akses ke Akun Penyimpanan dibatasi untuk prinsip keamanan minimal. Kontrol siapa yang memiliki akses ke akun penyimpanan.
  • Untuk informasi selengkapnya, lihat Mengotorisasi akses ke Azure Storage.

Praktik Terbaik

Manajemen Keamanan

Bagian ini menjelaskan berbagai aspek dan praktik terbaik untuk mengelola postur keamanan database Anda. Ini termasuk praktik terbaik untuk memastikan database Anda dikonfigurasi untuk memenuhi standar keamanan, untuk menemukan dan untuk mengklasifikasikan dan melacak akses ke data yang berpotensi sensitif dalam database Anda.

Pastikan bahwa database dikonfigurasi untuk memenuhi praktik terbaik keamanan

Tingkatkan keamanan database Anda secara proaktif dengan menemukan dan memulihkan potensi kerentanan database.

Cara menerapkan

  • Aktifkan SQL Vulnerability Assessment (VA) untuk memindai database Anda untuk masalah keamanan, dan untuk secara otomatis berjalan secara berkala pada database Anda.

Praktik Terbaik

  • Awalnya, jalankan VA pada database Anda dan lakukan iterasi dengan memulihkan pemeriksaan gagal yang menentang praktik terbaik keamanan. Siapkan garis besar untuk konfigurasi yang dapat diterima sampai pemindaian mengeluarkan bersihkan, atau semua pemeriksaan telah lewat.

  • Konfigurasikan pemindaian berulang berkala untuk dijalankan seminggu sekali dan konfigurasikan orang yang relevan untuk menerima surel ringkasan.

  • Ulas ringkasan VA setelah setiap pemindaian mingguan. Untuk setiap kerentanan yang ditemukan, evaluasi penyimpangan dari hasil pemindaian sebelumnya dan tentukan apakah pemeriksaan harus diselesaikan. Ulas jika ada alasan yang sah untuk perubahan konfigurasi.

  • Atasi pemeriksaan dan perbarui garis besar jika relevan. Buat item tiket untuk menyelesaikan tindakan dan melacaknya hingga terselesaikan.

Sumber daya lebih lanjut

Identifikasi dan beri tag data sensitif

Temukan kolom yang berpotensi berisi data sensitif. Apa yang dianggap sebagai data sensitif sangat tergantung pada pelanggan, peraturan kepatuhan, dll., dan perlu dievaluasi oleh pengguna yang bertanggung jawab atas data tersebut. Klasifikasikan kolom untuk menggunakan skenario audit dan perlindungan berbasis sensitivitas tingkat lanjut.

Cara menerapkan

  • Gunakan SQL Data Discovery and Classification untuk menemukan, mengklasifikasikan, memberi label, dan melindungi data sensitif dalam database Anda.
    • Lihat rekomendasi klasifikasi yang dibuat oleh penemuan otomatis di dasbor SQL Data Discovery and Classification. Terima klasifikasi yang relevan, sehingga data sensitif Anda terus-menerus diberi tag dengan label klasifikasi.
    • Tambahkan klasifikasi secara manual untuk bidang data sensitif tambahan yang tidak ditemukan oleh mekanisme otomatis.
  • Untuk informasi selengkapnya, lihat SQL Data Discovery and Classification.

Praktik Terbaik

  • Pantau dasbor klasifikasi secara teratur untuk penilaian yang akurat tentang status klasifikasi database. Laporan tentang status klasifikasi database dapat diekspor atau dicetak untuk dibagikan untuk tujuan kepatuhan dan audit.

  • Terus pantau status data sensitif yang direkomendasikan dalam SQL Vulnerability Assessment. Lacak aturan penemuan data sensitif dan identifikasi setiap penyimpangan di kolom yang direkomendasikan untuk klasifikasi.

  • Gunakan klasifikasi dengan cara yang disesuaikan dengan kebutuhan spesifik organisasi Anda. Sesuaikan kebijakan Perlindungan Informasi Anda (label sensitivitas, jenis informasi, logika penemuan) dalam kebijakan Perlindungan Informasi SQL di Pertahanan Microsoft untuk Cloud.

Lacak akses ke data sensitif

Pantau siapa yang mengakses data sensitif dan mengambil kueri pada data sensitif dalam jejak audit.

Cara menerapkan

Praktik Terbaik

Memvisualisasikan status keamanan dan kepatuhan

Gunakan sistem manajemen keamanan infrastruktur terpadu yang memperkuat postur keamanan pusat data Anda (termasuk database di SQL Database). Tampilkan daftar rekomendasi mengenai keamanan database dan status kepatuhan Anda.

Cara menerapkan

Ancaman keamanan umum dan mitigasi potensial

Bagian ini membantu Anda menemukan langkah-langkah keamanan untuk melindungi dari vektor serangan tertentu. Diharapkan sebagian besar mitigasi dapat dicapai dengan mengikuti satu atau lebih panduan keamanan di atas.

Ancaman keamanan: Penyelundupan data

Penyelundupan data adalah penyalinan, transfer, atau pengambilan data yang tidak sah dari komputer atau server. Lihat definisi untuk penyelundupan data di Wikipedia.

Menyambungkan ke server melalui titik akhir publik menghadirkan risiko penyelundupan data karena mengharuskan pelanggan membuka firewall mereka ke IP publik.

Skenario 1: Aplikasi pada komputer virtual Azure tersambung ke database di Azure SQL Database. Seorang aktor nakal mendapat akses ke komputer virtual dan menyusupkannya. Dalam skenario ini, penyelundupan data berarti bahwa entitas eksternal yang menggunakan komputer virtual nakal terhubung ke database, menyalin data pribadi, dan menyimpannya dalam penyimpanan blob atau SQL Database yang berbeda dalam langganan yang berbeda.

Skenario 2: DBA nakal. Skenario ini sering diangkat oleh pelanggan sensitif keamanan dari industri yang diatur. Dalam skenario ini, pengguna hak istimewa tinggi mungkin menyalin data dari Azure SQL Database ke langganan lain yang tidak dikontrol oleh pemilik data.

Mitigasi potensial

Saat ini, Azure SQL Database dan SQL Managed Instance menawarkan teknik berikut untuk mengurangi ancaman penyelundupan data:

  • Gunakan kombinasi aturan Izinkan dan Tolak pada NSG komputer virtual Azure untuk mengontrol wilayah mana yang dapat diakses dari komputer virtual.
  • Jika menggunakan server di SQL Database, atur opsi berikut:
    • Izinkan Layanan Azure menjadi OFF.
    • Hanya perbolehkan lalu lintas dari subnet yang berisi komputer virtual Azure Anda dengan menyiapkan aturan{b>
    • Gunakan Private Link
  • Untuk SQL Managed Instance, menggunakan akses IP privat secara default mengatasi masalah penyelundupan data pertama dari komputer virtual nakal. Aktifkan fitur delegasi subnet pada subnet untuk secara otomatis mengatur kebijakan yang paling ketat pada subnet SQL Managed Instance.
  • Masalah Rogue DBA lebih terekspos dengan SQL Managed Instance karena memiliki area permukaan yang lebih besar dan persyaratan jaringan yang terlihat oleh pelanggan. Mitigasi terbaik untuk ini adalah menerapkan semua praktik dalam panduan keamanan ini untuk mencegah skenario Rogue DBA (tidak hanya untuk penyelundupan data). Always Encrypted adalah salah satu metode untuk melindungi data sensitif dengan mengenkripsinya dan menjaga kunci tidak dapat diakses untuk DBA.

Aspek keamanan dari kelangsungan dan ketersediaan bisnis

Sebagian besar standar keamanan mengatasi ketersediaan data dalam hal kelangsungan operasional, dicapai dengan menerapkan kemampuan redundansi dan kegagalan untuk menghindari satu titik kegagalan. Untuk skenario bencana, ini adalah praktik umum untuk menyimpan cadangan file Data dan Log. Bagian berikut memberikan ringkasan tingkat tinggi tentang kemampuan yang ada di dalam Azure. Ini juga menyediakan opsi tambahan yang dapat dikonfigurasi untuk memenuhi kebutuhan spesifik:

Langkah berikutnya