Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Untuk menulis kode ADO.NET yang aman, Anda harus memahami mekanisme keamanan yang tersedia di penyimpanan data atau database yang mendasar. Anda juga perlu mempertimbangkan implikasi keamanan fitur atau komponen lain yang mungkin dimuat aplikasi Anda.
Autentikasi, Otorisasi, dan Izin
Saat menyambungkan ke Microsoft SQL Server, Anda dapat menggunakan Autentikasi Windows, juga dikenal sebagai Keamanan Terpadu, yang menggunakan identitas pengguna Windows aktif saat ini ketimbang meneruskan ID pengguna dan kata sandi. Menggunakan Autentikasi Windows disarankan untuk database lokal karena kredensial pengguna tidak terekspos dalam string koneksi. Jika Anda tidak dapat menggunakan Autentikasi Windows untuk menyambungkan ke SQL Server, pertimbangkan untuk membuat string koneksi saat runtime menggunakan SqlConnectionStringBuilder.
Penting
Microsoft menyarankan agar Anda menggunakan alur autentikasi paling aman yang tersedia. Jika Anda menyambungkan ke Azure SQL, Identitas Terkelola untuk sumber daya Azure adalah metode autentikasi yang direkomendasikan.
Kredensial yang digunakan untuk autentikasi perlu ditangani secara berbeda berdasarkan jenis aplikasi. Misalnya, dalam aplikasi Formulir Windows, pengguna dapat diminta untuk memberikan informasi autentikasi, atau kredensial Windows pengguna dapat digunakan. Namun, aplikasi Web sering mengakses data menggunakan kredensial yang disediakan oleh aplikasi itu sendiri daripada oleh pengguna.
Setelah pengguna diautentikasi, cakupan tindakan mereka bergantung pada izin yang telah diberikan kepada mereka. Selalu ikuti prinsip hak istimewa paling sedikit dan hanya berikan izin yang benar-benar diperlukan.
Untuk informasi selengkapnya, lihat sumber berikut ini:
| Sumber daya | Deskripsi |
|---|---|
| Melindungi Informasi Koneksi | Menjelaskan praktik dan teknik keamanan terbaik untuk melindungi informasi koneksi, seperti menggunakan konfigurasi yang dilindungi untuk mengenkripsi string koneksi. |
| Pembuat String Koneksi | Menjelaskan cara membuat string koneksi dari input pengguna saat runtime. |
| Keamanan untuk SQL Server Database Engine dan Azure SQL Database | Menyediakan tautan untuk membantu Anda menemukan informasi tentang keamanan dan perlindungan di SQL Server Database Engine dan Azure SQL Database. |
Perintah Berparameter dan Injeksi SQL
Menggunakan perintah berparameter membantu melindungi dari serangan injeksi SQL, di mana penyerang "menyuntikkan" perintah ke dalam pernyataan SQL yang membahayakan keamanan di server. Perintah berparameter melindungi dari serangan injeksi SQL dengan memastikan bahwa nilai yang diterima dari sumber eksternal diteruskan sebagai nilai saja, dan bukan bagian dari pernyataan Transact-SQL. Akibatnya, perintah Transact-SQL yang dimasukkan ke dalam nilai tidak dijalankan di sumber data. Sebaliknya, mereka dievaluasi hanya sebagai nilai parameter. Selain manfaat keamanan, perintah berparameter menyediakan metode yang nyaman untuk mengatur nilai yang diteruskan dengan pernyataan SQL Transact atau ke prosedur tersimpan.
Untuk informasi selengkapnya tentang menggunakan perintah berparameter, lihat sumber daya berikut ini.
| Sumber daya | Deskripsi |
|---|---|
| Parameter DataAdapter | Menjelaskan cara menggunakan parameter dengan DataAdapter. |
| Memodifikasi Data dengan Prosedur Tersimpan | Menjelaskan cara menentukan parameter dan mendapatkan nilai yang dikembalikan. |
| Prosedur tersimpan (Mesin Basis Data) | Menjelaskan manfaat menggunakan prosedur tersimpan dan berbagai jenis prosedur tersimpan. |
Menyelidiki Serangan
Penyerang sering menggunakan informasi dari pengecualian, seperti nama server, database, atau tabel Anda, untuk memasang serangan pada sistem Anda. Karena pengecualian dapat berisi informasi spesifik tentang aplikasi atau sumber data Anda, Anda dapat membantu menjaga aplikasi dan sumber data Anda lebih terlindungi dengan hanya mengekspos informasi penting kepada klien.
Untuk informasi selengkapnya, lihat sumber berikut ini:
| Sumber daya | Deskripsi |
|---|---|
| Menangani dan menampilkan pengecualian di .NET | Menjelaskan bentuk dasar dari penanganan pengecualian terstruktur dalam try/catch/finally. |
| Praktik Terbaik untuk Pengecualian | Menjelaskan praktik terbaik untuk menangani pengecualian. |
Melindungi Sumber Data Microsoft Access dan Excel
Microsoft Access dan Microsoft Excel dapat bertindak sebagai penyimpanan data untuk aplikasi ADO.NET saat persyaratan keamanan minimal atau tidak ada. Fitur keamanan mereka efektif untuk pencegahan, tetapi tidak boleh diandalkan untuk lebih dari sekadar menghalangi campur tangan oleh pengguna yang kurang informasi. File data fisik untuk Access dan Excel ada di sistem file, dan harus dapat diakses oleh semua pengguna. Hal ini membuat mereka rentan terhadap serangan yang dapat mengakibatkan pencurian atau kehilangan data karena file dapat dengan mudah disalin atau diubah. Ketika keamanan yang kuat diperlukan, gunakan SQL Server atau database berbasis server lain di mana file data fisik tidak dapat dibaca dari sistem file.
Layanan Perusahaan
COM+ berisi model keamanannya sendiri yang bergantung pada akun Windows dan peniruan proses/utas. Namespace System.EnterpriseServices menyediakan wrapper yang memungkinkan aplikasi .NET untuk mengintegrasikan kode terkelola dengan layanan keamanan COM+ melalui kelas ServicedComponent.
Mengoperasikan dengan Kode Tidak Terkelola
.NET Framework menyediakan interaksi dengan kode yang tidak dikelola, termasuk komponen COM, layanan COM+, pustaka jenis eksternal, dan banyak layanan sistem operasi. Bekerja dengan kode yang tidak dikelola memerlukan langkah keluar dari perimeter keamanan untuk kode terkelola. Kode Anda dan kode apa pun yang memanggilnya harus memiliki izin kode yang tidak dikelola (SecurityPermission dengan bendera UnmanagedCode yang ditentukan). Kode yang tidak dikelola dapat memperkenalkan kerentanan keamanan yang tidak diinginkan ke dalam aplikasi Anda. Oleh karena itu, Anda harus menghindari interoperabilitas dengan kode yang tidak dikelola kecuali benar-benar diperlukan.
Untuk informasi selengkapnya, lihat Mengoperasikan dengan Kode Tidak Terkelola.