Kapabilitas dan tugas keamanan

Selesai

Layanan SQL Server dan Azure SQL telah dikenal karena pentingnya mereka mengenakan keamanan, khususnya sebagai kelas perusahaan. Di unit ini, Anda akan mempelajari tentang berbagai kemampuan keamanan yang terkait dengan keamanan jaringan dan manajemen akses. Dalam unit berikut, Anda akan mendapatkan pengalaman langsung dengan beberapa kemampuan ini.

Diagram of enterprise-class security.

Keamanan jaringan

Lapisan keamanan pertama melibatkan jaringan. Kemampuan dan tugas jaringan berbeda antara Azure SQL Database dan Azure SQL Managed Instance. Untuk informasi tentang kemampuan jaringan Azure SQL Managed Instance, lihat arsitektur Koneksi ivity untuk Azure SQL Managed Instance.

Keamanan jaringan Azure SQL Database

Saat mengamankan jaringan untuk Azure SQL Database, Anda memiliki empat pilihan utama:

  • Perbolehkan akses ke layanan Azure
  • Gunakan aturan firewall
  • Gunakan aturan jaringan virtual
  • Gunakan Azure Private Link

Selain pilihan utama ini, Anda memiliki kesempatan untuk memblokir semua akses publik (hanya dengan Azure Private Link) dan opsi untuk memaksa versi Keamanan Lapisan Transportasi (TLS) minimum. Metode yang paling tidak aman, tetapi yang paling mudah dikonfigurasi, adalah mengizinkan akses ke layanan Azure. Metode yang paling aman adalah menggunakan Private Link. Bagian berikut akan mencakup kemampuan untuk setiap opsi, serta cara mengonfigurasi dan memelihara setiap opsi.

Perbolehkan akses ke layanan Azure

Selama penyebaran Azure SQL Database, Anda memiliki opsi untuk mengatur Izinkan layanan Azure dan akses sumber daya ke server ini ke Ya. Jika Anda memilih opsi ini, Anda mengizinkan sumber daya apa pun dari wilayah atau langganan mana pun kemungkinan untuk mengakses sumber daya Anda. Opsi ini memudahkan Untuk memulai dan menjalankan serta membuat Azure SQL Database terhubung ke layanan lain, seperti Azure Virtual Machines, Azure App Service, atau bahkan Azure Cloud Shell, karena Anda mengizinkan apa pun yang datang melalui Azure memiliki potensi untuk terhubung.

Diagram of allowing access to Azure services.

Namun, mengizinkan akses ke layanan Azure tidak mengizinkan apa pun di luar Azure (misalnya, lingkungan lokal Anda) untuk memiliki akses.

Konfigurasi yang paling aman adalah mengatur Izinkan layanan Azure dan akses sumber daya ke server ini ke Tidak, yang memblokir semua koneksi dan jaringan selain yang telah Anda tambahkan secara eksplisit dengan berbagai opsi yang mengikuti di bagian berikutnya.

Aturan firewall

Opsi Anda berikutnya adalah menerapkan aturan firewall. Hasil Anda mungkin mirip dengan akses izinkan layanan dan sumber daya Azure ke server ini kecuali, untuk setiap layanan (dalam gambar berikut, komputer virtual (VM)), Anda harus menambahkan aturan firewall unik untuk memungkinkannya tersambung. Aturan firewall juga memungkinkan lingkungan lokal Anda untuk terhubung ke sumber daya Azure SQL Database, karena Anda dapat menambahkan aturan untuk mesin dan aplikasi di lingkungan lokal Anda.

Diagram of firewall rules.

Untuk mendapatkan konektivitas di Azure, Anda juga dapat mengizinkan akses ke layanan Azure lalu menambahkan aturan firewall hanya untuk konektivitas lokal. Seperti yang disebutkan sebelumnya, Izinkan akses layanan dan sumber daya Azure ke server ini tidak seaman, karena memungkinkan semua lalu lintas Azure. Kami menyarankan agar Anda menggunakan aturan firewall secara eksklusif.

Mari kita lihat contoh sebelumnya dengan aturan firewall yang dikonfigurasi. Dari alat yang mendukung Transact-SQL (T-SQL) seperti SQL Server Management Studio (SSMS), Anda dapat menjalankan kueri berikut dari Azure VM Anda di jaringan virtual SQLDBVNET-EUS:

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

Hasilnya adalah 174.17.218.16. Ini adalah alamat IP publik Azure VM. Meskipun kita menggunakan aturan firewall, semua koneksi yang dibuat ber publik.

Aturan jaringan virtual

Jika Anda hanya ingin menggunakan aturan firewall, aturan firewall dapat menjadi rumit untuk disiapkan. Hanya menggunakan aturan firewall berarti Anda harus menentukan rentang alamat IP untuk semua koneksi Anda, yang terkadang dapat memiliki alamat IP dinamis. Alternatif yang jauh lebih mudah adalah menggunakan aturan jaringan virtual untuk membangun dan mengelola akses dari jaringan tertentu yang berisi VM atau layanan lain yang perlu mengakses data.

Jika Anda mengonfigurasi akses dari jaringan virtual dengan aturan jaringan virtual, sumber daya apa pun di jaringan virtual tersebut dapat mengakses server logika Azure SQL Database. Ini dapat menyederhanakan tantangan untuk mengonfigurasi akses ke semua alamat IP statis dan dinamis yang perlu mengakses data. Dengan menggunakan aturan jaringan virtual, Anda dapat menentukan satu atau beberapa jaringan virtual, yang mencakup semua sumber daya di dalamnya. Anda juga dapat mulai menerapkan teknologi jaringan virtual untuk menghubungkan jaringan di seluruh wilayah di Azure dan lokal.

Diagram of virtual network rules.

Dalam contoh ini, seperti pada bagian sebelumnya, Anda bisa menjalankan kueri yang sama dari Azure VM Anda di jaringan virtual SQLDBVNET-EUS:

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

Hasilnya sekarang adalah 10.0.0.2, alamat IP pribadi Azure VM. Hasil ini membuat Anda selangkah lebih dekat untuk membuat koneksi pribadi ke server logika Azure SQL Database Anda, karena sumber daya sekarang terhubung melalui jaringan virtual.

Strategi umum lainnya untuk menganalisis koneksi Anda adalah memeriksa hierarki Domain Name System (DNS). Di Azure VM yang sama, dalam prompt perintah, Anda bisa menjalankan perintah berikut ini:

nslookup aw-server.database.windows.net  

Dengan menggunakan perintah ini, Anda bisa mendapatkan detail yang terkait dengan infrastruktur DNS. Hasil Anda akan mirip dengan yang berikut ini:

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   cr2.eastus1-a.control.database.windows.net
Address:    174.17.218.16
Aliases:    aw-server.database.windows.net
            dataslice2.eastus.database.windows.net

Di bawah jawaban non-otoritatif, ada beberapa hal penting yang perlu dilihat:

  • Nama: Titik akhir yang dimulai cr2 adalah bagian dari hierarki DNS publik. Tanpa terlalu banyak masuk ke dalam hierarki, katakanlah itu cr2 adalah cincin kontrol 2 dan bahwa ada beberapa "irisan" data di bawahnya.
  • Alamat: Alamat IP yang dikembalikan di sini harus sesuai dengan alamat IP publik Azure VM Anda. Meskipun alat seperti hop akhir SSMS mungkin melalui alamat IP privat VM Anda, alamat IP publik VM Anda masih digunakan untuk terhubung dalam beberapa kapasitas.
  • Alias: Alias adalah berbagai titik dalam hierarki DNS; dalam hal ini, "ikatan" data tertentu dan titik akhir yang Anda sambungkan.

Catatan

Dalam blok output sebelumnya, Alamat: 168.63.129.16 adalah alamat IP publik virtual yang digunakan untuk memfasilitasi saluran komunikasi ke sumber daya platform Azure. Ini berlaku untuk semua wilayah dan semua sistem cloud nasional, dan tidak akan berubah.

Meskipun koneksi melalui SSMS datang melalui alamat IP privat Azure VM, Anda masih pada akhirnya terhubung melalui titik akhir publik.

Anda telah melihat cara mengonfigurasi jaringan yang paling aman dengan menggunakan database Anda di Azure SQL Database dengan titik akhir publik. Metode mengamankan database dalam Microsoft Azure SQL Database ini telah digunakan selama bertahun-tahun. Namun, pada tahun 2019, Azure mulai bergerak menuju konsep tautan pribadi, yang lebih seperti cara Azure SQL Managed Instance diterapkan. Dengan Azure Private Link, Anda dapat menyambungkan ke database Anda di SQL Database dan beberapa penawaran platform-as-a-service (PaaS) lainnya dengan menggunakan titik akhir privat. Ini berarti bahwa ia memiliki alamat IP pribadi dalam jaringan virtual tertentu.

Diagram of a private endpoint connection.

Dalam contoh sebelumnya, Anda akan melihat bahwa infrastruktur jaringan umum tidak berubah dan Anda masih dapat menerapkan strategi konektivitas jaringan virtual dari aturan jaringan virtual. Namun, Anda tidak perlu membuat aturan jaringan virtual. Sumber daya yang perlu terhubung ke server database harus memiliki akses ke jaringan virtual tempat titik akhir berada. Dalam contoh, titik akhir adalah SQLDBVNet-EUS. Hanya koneksi yang melalui titik akhir pribadi yang memiliki akses, dan semua koneksi lainnya (misalnya, dari internet) ditolak.

Saat Anda melanjutkan dengan contoh ini, pada Azure VM di jaringan SQLDBVNet-EUSvirtual, Anda dapat sekali lagi menjalankan perintah T-SQL berikut:

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

Hasilnya sekarang adalah 10.0.0.2, yang merupakan alamat IP privat Azure VM dalam contoh ini. Dengan menambahkan akses dari jaringan virtual Anda, koneksi ke Azure SQL Database dari VM Anda akan muncul melalui alamat IP privat VM Anda. Ini adalah hasil yang sama yang Anda lihat dengan aturan jaringan virtual.

Namun, Anda mungkin ingin menggunakan prompt perintah untuk melihat hierarki DNS dengan menggunakan perintah berikut:

nslookup aw-server.database.windows.net  

Jika Anda menggunakan perintah sebelumnya, hasil Anda akan sedikit berbeda dengan endpoint pribadi yang dikonfigurasi:

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   aw-server.privatelink.database.windows.net
Address:    10.0.0.5
Aliases:    aw-server.database.windows.net

Di bawah jawaban non-otoritatif, ada beberapa hal penting yang perlu dilihat:

  • Nama: Perhatikan bahwa Anda tidak lagi menunjuk ke hierarki DNS publik, hanya ke DNS Azure Private Link. Ini berarti bahwa lebih sedikit informasi yang terungkap tentang server database Anda.
  • Alamat: Untuk aturan jaringan virtual, alamat yang dikembalikan adalah alamat IP publik VM Anda, tetapi sekarang harus satu atau beberapa alamat IP privat dalam hierarki Private Link (satu adalah titik akhir privat Azure SQL Database Anda).
  • Alias: Seperti di kolom Nama, tidak ada yang terkait dengan hierarki DNS, namun Anda masih bisa tersambung ke nama server (misalnya, aw-server.database.windows.net).

Satu hal yang mungkin Anda tanyakan apakah Anda tersambung ke titik akhir privat adalah mengapa Anda masih menggunakan nama server yang sama? Di backend, saat Anda hanya menggunakan metode Private Link untuk menyambungkan ke Azure SQL Database (yaitu, tidak ada firewall atau aturan jaringan virtual), informasi diproses sebagai berikut:

  • aw-server.database.windows.net
    • Diselesaikan berdasarkan layanan untuk aw-server.privatelink.database.net
      • Diselesaikan berdasarkan layanan 10.0.0.5 ke (alamat IP titik akhir pribadi Anda)

Selain itu, layanan akan memblokir Anda dari terhubung langsung dengan menggunakan apa pun selain aw-server.database.windows.net.

Manajemen akses

Setelah Anda menyelesaikan akses jaringan, lapisan berikutnya yang perlu dipertimbangkan adalah manajemen akses.

Kontrol Akses Berbasis Peran

Semua jenis operasi Azure untuk Azure SQL Database dikontrol melalui kontrol akses berbasis peran (RBAC). RBAC saat ini dipisahkan dari keamanan Azure SQL, tetapi Anda dapat menganggapnya sebagai hak keamanan di luar database Anda di SQL Database, dengan cakupan yang mencakup langganan, grup sumber daya, dan sumber daya. Hak tersebut berlaku untuk operasi di portal Microsoft Azure, Azure CLI, dan Azure PowerShell. RBAC memungkinkan pemisahan tugas antara penyebaran, manajemen, dan penggunaan.

Peran bawaan tersedia untuk mengurangi kebutuhan akan peran RBAC tingkat lebih tinggi, seperti Pemilik atau Kontributor. Secara efektif, Anda dapat menggunakan peran ini untuk meminta individu tertentu menyebarkan sumber daya Azure SQL (atau mengelola kebijakan keamanan) tetapi memberi pengguna lain akses aktual untuk menggunakan atau mengelola database. Misalnya, Kontributor SQL Server dapat menyebarkan server dan menetapkan pengguna untuk menjadi admin server dan database. Peran bawaan untuk Azure SQL Database meliputi:

  • Kontributor SQL DB: Dapat membuat dan mengelola database tetapi tidak dapat mengakses database (misalnya, tidak dapat menyambungkan dan membaca data)
  • Pengelola Keamanan SQL: Dapat mengelola kebijakan keamanan untuk database dan instans (seperti pengauditan) tetapi tidak dapat mengaksesnya
  • Kontributor SQL Server: Dapat mengelola server dan database tetapi tidak dapat mengaksesnya.

Autentikasi

Selama penyebaran server logis Azure SQL Database, Anda dapat menentukan metode Autentikasi berikut:

  • Hanya gunakan autentikasi Microsoft Entra
  • Gunakan autentikasi SQL dan Microsoft Entra
  • Menggunakan autentikasi SQL

Admin server perlu diatur selama penyebaran. Untuk database di Azure SQL Database, admin server adalah prinsipal tingkat server untuk server logis Azure SQL Database.

Jika Anda memigrasikan beban kerja yang memerlukan autentikasi Windows atau organisasi Anda menggunakan ID Microsoft Entra, Anda dapat menggunakan ID Microsoft Entra. Anda dapat menetapkan admin server Microsoft Entra dengan menggunakan portal atau alat baris perintah.

Autentikasi khusus Microsoft Entra adalah opsi default saat mengonfigurasi server baru. Login server telah diperkenalkan untuk memungkinkan prinsipal server Microsoft Entra, yang masuk dalam database virtual master SQL Database. Anda dapat membuat login Microsoft Entra dari pengguna, grup, dan perwakilan layanan Microsoft Entra. Saat menggunakan autentikasi khusus Microsoft Entra, Anda dapat membuat login autentikasi SQL, dan login yang ada akan tetap ada. Namun, hanya login autentikasi Microsoft Entra dan pengguna yang dapat terhubung ke server logis. Untuk mempelajari selengkapnya tentang autentikasi Microsoft Entra-only, lihat Autentikasi khusus Microsoft Entra dengan Azure SQL.

Screenshot of setting the Microsoft Entra administrator.

Bergantung pada bagaimana organisasi Anda telah mengonfigurasi instans Microsoft Entra, Anda dapat menyambungkannya dengan menggunakan salah satu dari tiga metode berikut (misalnya, di SSMS):

  • ID Microsoft Entra - Terintegrasi: Metode non-interaktif yang dapat Anda gunakan jika Anda masuk ke Windows dengan kredensial Microsoft Entra Anda dari domain federasi.

  • ID Microsoft Entra - Kata Sandi: Metode non-interaktif yang memungkinkan Anda terhubung dengan nama utama Microsoft Entra dengan menggunakan domain yang dikelola ID Microsoft Entra. Dari dokumentasi:

    Ini dapat berlaku untuk pengguna Microsoft Entra asli atau federasi. Pengguna asli adalah pengguna asli yang dibuat secara eksplisit di MICROSOFT Entra ID dan diautentikasi menggunakan nama pengguna dan kata sandi, sementara pengguna federasi adalah pengguna Windows yang domainnya digabungkan dengan ID Microsoft Entra. Metode terakhir (menggunakan nama pengguna & kata sandi) dapat digunakan ketika pengguna ingin menggunakan kredensial windows mereka, tetapi komputer lokal mereka tidak bergabung dengan domain (misalnya, menggunakan akses jarak jauh). Dalam hal ini, pengguna Windows dapat menunjukkan akun domain dan kata sandi mereka dan dapat mengautentikasi ke SQL Database atau Azure Synapse Analytics (sebelumnya SQL DW) dengan menggunakan kredensial federasi.

  • MICROSOFT Entra ID - Universal dengan autentikasi multifaktor (MFA): Metode interaktif yang melindungi akses ke data sambil memenuhi permintaan organisasi untuk proses masuk tunggal dengan autentikasi multifaktor Microsoft Entra.

Untuk Azure SQL Database, ada beberapa nuansa. Anda dapat memiliki login yang ada di database virtual master , pengguna database, dan bahkan pengguna database yang berisi untuk akun Microsoft Entra (disarankan). Meskipun admin server untuk Azure SQL Database pada dasarnya memiliki sysadmin hak, Anda dapat membuat admin yang lebih terbatas dengan menggunakan peran tingkat server atau database. Dua peran tingkat database tersedia untuk SQL Database yang hanya ada di database virtual master :

  • loginmanager: Peran tingkat database yang memungkinkan anggota membuat login untuk server database
  • dbmanager: Peran tingkat database yang memungkinkan anggota membuat dan menghapus database untuk server database

Berikut adalah daftar peran tingkat server di Azure SQL Database:

  • ##MS_DatabaseConnector##
  • ##MS_DatabaseManager##
  • ##MS_DefinitionReader##
  • ##MS_LoginManager##
  • ##MS_SecurityDefinitionReader##
  • ##MS_ServerStateReader##
  • ##MS_ServerStateManager##

Akhirnya, ketika Anda menyiapkan dan mengonfigurasi autentikasi dan otorisasi, Anda memiliki empat panduan untuk diikuti:

  • Menggunakan dengan admin server
  • Membuat admin lain seperlunya
  • Admin dapat membuat pengguna
  • Memberikan akses seperti yang Anda lakukan di SQL Server

Kemampuan lainnya

Setelah Anda langsung dengan beberapa kemampuan jaringan dan autentikasi, nantinya dalam modul Anda akan memeriksa kemampuan lain (dan tugas terkait) untuk perlindungan data, pemantauan, pencatatan, dan audit.

Uji pengetahuan

1.

Apa cara yang direkomendasikan dan paling aman untuk melindungi jaringan Anda untuk Azure SQL Database?

2.

Pertimbangkan contoh dari unit di mana alamat IP publik Azure VM adalah 174.17.218.16 dan alamat IP pribadi Azure VM adalah 10.0.0.2. Ketika Anda menggunakan aturan jaringan virtual untuk mengonfigurasi akses jaringan ke Azure SQL Database, apa yang akan dikembalikan dari SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;?