Anda menerbitkan rilis pada malam hari, memeriksa notifikasi, dan menemukan kredential yang tidak seharusnya pernah meninggalkan repositori pribadi. Mungkin itu adalah kata sandi database. Mungkin itu adalah kunci akses ke cloud dengan izin yang lebih luas daripada yang diinginkan. Dalam kasus apapun, masalah bukan hanya karena seseorang bisa masuk. Masalah adalah database keamanan masih dianggap sebagai masalah login ketika sebenarnya itu adalah masalah siklus penyimpanan.
Hal itu muncul di mana-mana dalam sistem nyata. Tim memungkinkan enkripsi sekali dan menganggap mereka sudah selesai. Mereka menjaga backup tetapi tidak pernah menguji restore. Mereka membuat akun layanan admin untuk kemudahan dan melupakan bahwa akun itu ada. Mereka memblokir produksi, kemudian meninggalkan staging penuh dengan data pelanggan yang dicopy. Jika Anda sedang membangun aplikasi mobile atau web, penyimpanan database yang aman harus mencakup semua hal: database utama, replika, ekspor, log, backup, dan kunci yang mengontrol semua hal itu.
Jika Anda juga sedang mencoba mengatasi autentikasi untuk aplikasi berikutnyaingatlah bahwa autentikasi dan keamanan penyimpanan menyelesaikan mode gagal yang berbeda. Autentikasi memutuskan siapa yang boleh masuk. Keamanan penyimpanan membatasi kerusakan ketika seseorang melakukannya, atau ketika data bocor melalui jalur yang tidak diharapkan. Untuk tim yang mengirimkan aplikasi yang menghadap ke pelanggan, juga patut untuk menyesuaikan keputusan penyimpanan dengan kontrol yang berdekatan seperti API standar keamanan untuk kelayakan toko aplikasi.
Kemarin bukanlah teori. Produksi data global mencapai 64,2 zettabyte pada tahun 2020 dan diperkirakan akan meningkat menjadi 180 zettabyte pada tahun 2025 menurut Ringkasan penyimpanan data Edge Delta. Pada skala itu, penyimpanan yang aman tidak lagi menjadi tugas penguatan dan menjadi arsitektur
Daftar Isi
- Mengapa Keamanan Basis Data Lebih dari Hanya Kata Sandi
- Mengerti Model Ancaman Basis Data Anda
- Pilar Utama Keamanan Penyimpanan Basis Data
- Polanya Pelaksanaan Praktis untuk Enkripsi
- Menguasai Manajemen Kunci dan Rahasia
- Membuat Strategi Cadangan dan Pengembalian yang Tahan Banting
- Daftar Periksa Pengembang untuk Penyimpanan Database yang Aman
- Frequently Asked Questions
Mengapa Keamanan Basis Data Lebih dari Hanya Kata Sandi
Kata sandi melindungi titik masuk. Tidak melindungi data setelah kredential terleleh, snapshot dicopy, atau layanan internal yang berkelebihan mulai membaca tabel yang tidak pernah dimaksudkan untuk disentuh. Itulah mengapa penyimpanan basis data yang aman harus berlapis.
Model mental lama sederhana: letakkan basis data di belakang firewall, memerlukan kata sandi yang kuat, dan menjauhkan orang luar. Model tersebut rusak dalam sistem cloud, backend mobile, dan alur CI/CD modern. Data bergerak antar layanan. Para insinyur membuat ekspor sementara. Tugas analitis menyalin rekaman. Sistem backup menyimpan salinan di infrastruktur yang berbeda. Serangga tidak perlu menghancurkan mesin basis data itu sendiri jika mereka bisa mencuri kunci, menyalahgunakan token API, atau menemukan replika dengan kontrol yang lebih lemah.
Kegagalan keamanan terjadi di jalur diam
Kegagalan penyimpanan paling merusak tidak terlihat dramatis awalnya. Mereka terlihat biasa saja.
- Kenyamanan pengembang menjadi risiko produksi: Kredensial admin bersama digunakan kembali oleh skrip karena memutarinya akan menghancurkan pengembangan.
- Dataset yang dicopy melarikan diri dari pengawasan: Rekaman produksi diklon ke staging agar QA bisa mereproduksi bug.
- Backup menjadi titik lemah: Produksi memiliki kontrol yang kuat, tetapi wadah restore atau kebijakan snapshot tidak.
Aturan praktis: If ada satu hal yang menghalangi penyerang dan data yang dapat dibaca hanya satu kredit, Anda tidak memiliki penyimpanan yang aman. Anda memiliki titik kegagalan tunggal.
Kebanggaan harus bertahan dari penyalahgunaan kredit
Panduan awal Microsoft untuk cloud merekomendasikan dasar yang mencakup enkripsi dalam transit dan di tempat istirahat, kontrol akses dengan hak yang paling sedikit, dan pemantauan untuk aktivitas tidak sah, seperti yang diterangkan dalam praktek keamanan data cloudnya. Dasar yang tepat karena insiden nyata sering dimulai dengan akses yang valid digunakan dengan cara yang salah.Yang efektif dalam praktek adalah yang membosankan dan konsisten. Enkripsi file database. Enkripsi koneksi. Bagi peran layanan. Hapus akses admin yang berdiri di mana pun. Log operasi sensitif. Peringatkan pola akses yang tidak sesuai dengan penggunaan normal. Tidak ada yang glamor, tapi itu mencegah insiden nyata.
Cara yang berguna untuk berpikir tentangnya adalah sebuah vault fisik. Pintu vault berarti. Begitu juga dengan kunci kompartemen, rekaman kamera, log pengunjung, dan kebijakan siapa yang dapat membuka box mana. Penyimpanan database yang aman bekerja sama dengan cara itu. Kata sandi hanya pintu depan.
Pahami Model Ancaman Database Anda
Sebelum Anda memilih kontrol, peta cara sistem Anda dapat gagal. Model ancaman database untuk penyimpanan tidak perlu akademis. Perlu memberitahu siapa yang dapat menyentuh data sensitif, bagaimana mereka melakukannya, dan apa yang terjadi jika mereka berhasil.
Diagram alir lima langkah yang menggambarkan proses pembangunan model ancaman database yang komprehensif untuk keamanan data.
Sensitif data jarang hidup di satu basis data produksi yang rapi. Panduan modern menekankan penemuan dan manajemen posisi karena informasi sensitif sering kali berakhir di salinan, backup, log, dan lingkungan pengembangan, sehingga kegagalan sering terjadi di luar basis data utama, seperti yang disebutkan dalam Ringkasan Sentra tentang keamanan data cloud dan manajemen posisi. Oleh karena itu, perencanaan insiden harus mencakup skenario seperti paparan vendor dan dataset yang dicopy. Ini juga adalah tempat respons yang lebih luas, seperti praktik terbaik respons bocor pihak ketiga, menjadi relevan.
Mulai dengan aset, bukan alat
Daftar apa yang penting sebelum Anda daftar produk.
Untuk tim aplikasi kebanyakan, aset yang kritis adalah sederhana:
- Rekaman pelanggan seperti profil, riwayat pesanan, metadata terkait pembayaran, atau konten terkait kesehatan.
- Bahan autentikasi seperti hash kata sandi, rekaman sesi, token refresh, atau API rahasia.
- Data operasional, seperti log audit, antrian pekerjaan, catatan administrator, dan ekspor dukungan. Aset pemulihan, seperti snapshot, dump logis, log waktu tertentu, dan kunci enkripsi.
- Item terakhir lebih penting daripada tim pikir. Jika penyerang dapat menghapus backup atau mengakses kunci yang dapat memecahkan mereka, cerita pemulihan Anda runtuh. Tiga wadah ancaman yang paling penting
Model sederhana yang saya gunakan dengan pengembang memiliki tiga wadah.
Pengganggu luar
Wadah ini adalah yang paling banyak dipikirkan orang pertama. Injeksi SQL, token __CAPGO_KEEP_0__ yang dicuri, kredit awan yang terlepas, panel administrator yang terbuka, dependensi yang rentan. Benang merah adalah seseorang yang tidak dikenal mendapatkan akses ke data.
Pertanyaan untuk ditanyakan:
This is the bucket everyone thinks about first. SQL injection, stolen API tokens, leaked cloud credentials, exposed admin panels, vulnerable dependencies. The common thread is an outsider getting a path to data.
Apakah kredensial server yang dicuri dapat membaca lebih dari satu layanan yang dibutuhkan?
- Apakah seseorang dapat menjalankan kueri database secara tidak langsung melalui aplikasi?
- Apakah kredensial server yang dicuri dapat membaca lebih dari satu layanan yang dibutuhkan?
- Apakah snapshot yang dicopy dapat dibaca secara mandiri?
Ancaman dari dalam
Hal ini termasuk insider yang berbahaya dan karyawan yang baik dengan akses yang terlalu luas. Seorang insinyur dukungan mengexport data untuk menyelesaikan tiket. Seorang kontraktor menyimpan salinan lokal. Seorang administrator platform dapat membaca baris produksi meskipun pekerjaannya tidak memerlukannya.
Apa yang membantu di sini adalah pemisahan tugas, akses berdasarkan peran, dan jejak audit yang membuat akses sensitif terlihat.
Jika Anda tidak dapat menjawab siapa yang mengakses rekaman pelanggan, kapan mereka mengaksesnya, dan mengapa akses tersebut diizinkan, maka kontrol database Anda lebih lemah dari yang terlihat.
Pengungkapan tidak sengaja
Kategori ini adalah yang paling umum di tim yang bergerak cepat. Tempat penyimpanan yang tidak terkonfigurasi dengan baik. Lingkungan pengujian yang ditanami dengan data hidup. Log debug yang mencakup token atau informasi pribadi. Salinan cadangan yang ditempatkan di lingkungan keamanan rendah untuk troubleshooting.
Pengungkapan tidak sengaja adalah mengapa keamanan penyimpanan data harus beroperasi kuat. Anda tidak menyelesaikannya dengan satu pengaturan. Anda menyelesaikannya dengan klasifikasi data, penghalang, tinjauan, dan pembersihan rutin.
Pilar Utama Keamanan Penyimpanan Database
Serangan jarang datang dari satu kegagalan dramatis. Biasanya datang dari rantai kesalahan-kesalahan biasa. Salinan cadangan dicopy ke akun yang salah. Layanan mendapatkan izin yang lebih luas daripada yang dibutuhkan. Kunci lama tetap aktif selama beberapa bulan karena rotasi yang terus ditunda. Penyimpanan database yang aman harus mengganggu rantai tersebut di beberapa titik, dan terus melakukannya saat sistem berubah.
Saya mengelompokkan pekerjaan ke empat pilar: enkripsi, pengendalian akses, auditing, dan pengurangan. Cadangan dan pemulihan juga penting, tetapi mereka layak mendapatkan penanganan operasional sendiri karena data yang dipulihkan seringkali menjadi jalur ekspose baru jika tidak ada yang menguji di mana data itu berada, siapa yang bisa membacanya, dan kunci mana yang bisa mengenkripsinya.
Enkripsi mengurangi nilai data yang dicuri
Enkripsi membeli waktu dan mengurangi dampak. Jika seseorang mendapatkan snapshot disk, file backup mentah, atau lalu lintas dari jaringan internal, data yang dienkripsi jauh lebih sulit untuk diubah menjadi catatan pelanggan.
Di tempat istirahat, enkripsi melindungi file database, snapshot, dan artefak cadangan. Di transit, TLS melindungi koneksi antara server aplikasi, proxy, dan mesin database. NIST menangani kedua kontrol dalam panduan tentang enkripsi penyimpanan dan perlindungan transportasi di SP 800-111 dan rekomendasi terkait data di tempat istirahat..
Tukarannya adalah operasional, bukan teoretis. Enkripsi hanya membantu jika pengelolaan kunci dipisahkan dari jalur data dan dipertahankan secara waktu. Enkripsi amplop bekerja seperti kunci utama bangunan dan kunci kantor yang terkunci. Layanan pengelolaan kunci melindungi kunci utama, dan kunci utama itu mengenkripsi kunci data singkat yang digunakan untuk catatan atau file yang sebenarnya. Desain itu membatasi ekspose selama rotasi dan membuat lebih mudah untuk membatalkan atau mengganti bahan kunci tanpa menulis semuanya sekali lagi.
Tim suka masalah ketika mereka mengaktifkan enkripsi sekali dan berhenti di situ. Periksa di mana kunci hidup, siapa yang bisa menggunakannya, apakah rotasi yang dijadwalkan, dan apakah cadangan lama masih bergantung pada versi kunci yang dilupakan.
Kontrol akses membatasi radius ledakan
Izin harus mengikuti batas aplikasi, bukan organisasi.
Peran basis data untuk API seharusnya tidak bisa membaca data gaji. Pekerja latar belakang tidak boleh memiliki hak untuk mengubah skema karena migrasi awal yang nyaman. Alat dukungan harus menggunakan tampilan yang disaring atau prosedur yang disetujui daripada akses meja yang luas.
Model yang praktis seperti ini:
- Peran aplikasi web: Akses terbatas untuk membaca dan menulis di tabel di balik permintaan pengguna.
- Peran pekerja: Akses ke catatan yang dibutuhkan untuk menjalankan pekerjaan.
- Peran analitik: Akses membaca saja ke dataset yang disusun dengan penghapusan identifikasi langsung di mana mungkin.
- Peran admin darurat: akses yang singkat, disetujui dengan catatan yang kuat dan pengawasan.
Pilar ini menjadi kuat ketika dipasangkan dengan transformasi data. Jika sebuah tim dapat melakukan pekerjaannya dengan data yang disembunyikan atau dikurangi, berikan versi itu daripada nilai produksi penuh. Untuk data kesehatan yang terregulasi, penghilangan identifikasi PHI seringkali adalah perbedaan antara akses yang berguna dan paparan yang tidak perlu.
Rahasia sekitar database layak mendapatkan disiplin yang sama. Tim yang memperketat kontrol penyimpanan tetapi meninggalkan kunci mesin yang tercecer di log CI, build mobile, atau skrip dukungan masih meninggalkan jalur serangan yang luas. Kebiasaan operasional yang sama berlaku untuk API kunci keamanan untuk kinerja toko aplikasi, terutama ketika aplikasi mobile dan layanan backend berbagi batasan kepercayaan.
Pengauditan menunjukkan apakah kontrol nyata.
Sebuah kebijakan yang tidak dapat diverifikasi hanya merupakan harapan.
Jejak audit menjawab pertanyaan yang penting selama insiden. Siapa yang membaca rekaman. Siapa yang mengubah izin. Siapa yang menjalankan pekerjaan ekspor. Siapa yang digunakan untuk memecahkan arsip. Mereka juga mengekspos pergeseran lambat, seperti akun layanan yang mulai menyentuh tabel yang tidak perlu sebelumnya.
Audit yang berguna biasanya mencakup:
- Aktivitas autentikasi: penggunaan sukses, penggunaan gagal, penggunaan token, dan sesi administratif.
- Pengaturan Otorisasi: izin, pembatalan, pembuatan peran, perubahan kebijakan, dan perubahan skema.
- Polanya akses sensitif: bacaan massal, ekspor besar, jalur kueri tidak biasa, dan akses di luar jam atau jaringan sumber yang diharapkan.
- Event Manajemen Kunci: pembuatan kunci, rotasi, upaya dekripsi gagal, versi dinonaktifkan, dan perubahan kebijakan di KMS atau penyimpanan rahasia.
Perluan penyimpanan dan tinjauan berlaku di sini. Jika log akan kedaluwarsa sebelum seseorang menyelidiki, atau jika tidak ada yang memeriksa perubahan hak istimewa kecuali ada kebocoran, sistem audit ada di kertas lebih dari dalam praktek.
Berikut adalah penjelasan yang baik sebelum detail implementasi menjadi terlalu abstrak:
Pengurangan menjaga data sensitif keluar dari tempat yang tidak bisa Anda pertahankan dengan baik.
Pengurangan adalah di mana banyak tim mendapatkan kemenangan keamanan terbesar dengan upaya insinyur yang paling sedikit.
Simpan lebih sedikit. Simpan lebih singkat. Salin ke tempat yang lebih sedikit. Jika fitur hanya memerlukan rentang usia, jangan menyimpan tanggal lahir penuh. Jika dukungan hanya memerlukan empat karakter terakhir dari identifikasi, hindari menampilkan bidang penuh. Jika lingkungan uji tidak memerlukan data pribadi hidup, jangan memulihkan cadangan produksi ke dalam mereka dan sebutnya sementara.
Ini juga merupakan disiplin operasional. Jadwal penyimpanan perlu dilaksanakan. Ekspor lama perlu dihapus. Sistem-sistem bawah harus direview karena risiko meningkat setiap kali bidang sensitif direplikasi ke indeks pencarian, cache, danau data, penyimpanan mobile, dan file CSV ad hoc. Untuk aplikasi Capacitor @capgo/capacitor-penyimpanan-data-sqlite dan @capgo/capacitor-sql-cepat dapat menyediakan penyimpanan persistensi sisi aplikasi yang terenkripsi, tetapi Anda masih perlu memutuskan apa yang tidak perlu disimpan secara lokal sama sekali.
Tujuan dari pilar-pilar ini bukanlah kesempurnaan pada hari pertama. Ini adalah membangun sistem penyimpanan yang tetap dapat dibela setelah rotasi kunci, perubahan staf, tanggapan insiden, pemulihan backup, dan pertumbuhan produk. Itulah di mana penyimpanan database yang aman biasanya berhasil atau gagal.
Polanya Implementasi Praktis untuk Enkripsi
Tidak ada satu pola enkripsi untuk setiap sistem. Pilihan yang tepat tergantung pada apa yang dilindungi, siapa yang perlu mengaksesnya, dan berapa banyak kompleksitas yang dapat didukung oleh tim. Kesalahan adalah memilih pola yang terdengar kuat dan kemudian menerapkan dengan buruk.
TDE adalah basis tercepat
Enkripsi Data Transparan, atau TDE, biasanya merupakan tempat yang paling mudah untuk dimulai. Mesin database mengenkripsi file di disk dan mendekripsi mereka ketika mesin membaca mereka ke dalam memori. Aplikasi sering tidak perlu code perubahan.
Ini adalah garis dasar yang kuat untuk:
- Pengamanan database secara keseluruhan
- Kebutuhan komplianan tingkat penyimpanan
- Mengurangi risiko dari disk yang dicuri, snapshot, atau akses file mentah
TDE tidak melindungi dari segala sesuatu. Jika seorang penyerang mendapatkan akses database yang valid, mesin akan masih menyajikan data yang terdecyr. Itu mengapa TDE membantu dengan kompromi penyimpanan, bukan penyalahgunaan kreditensi yang sah.
Enkripsi aplikasi-level melindungi bidang yang paling penting
Enkripsi aplikasi-level terjadi sebelum data mencapai database. Anda code mengenkripsi bidang yang dipilih, kemudian menulis ciphertext ke penyimpanan. Hal ini berfungsi baik untuk kolom yang sangat sensitif seperti ID pemerintah, detail bank, rahasia pemulihan, atau catatan pribadi.
Kontrol tambahan tersebut datang dengan konsekuensi:
- Anda memiliki lebih banyak kompleksitas: pemilihan kunci, library enkripsi, perilaku rotasi, dan penanganan kesalahan.
- Pencarian menjadi lebih sulit: cocokan tepat, pencarian sebagian, dan indeks menjadi masalah desain.
- Para pengembang memerlukan disiplin: Satu shortcut dalam skrip migrasi dapat menghindari model Anda secara keseluruhan.
Polosan pola pseudocode seperti ini:
| Langkah | Aksi |
|---|---|
| 1 | Baca bidang teks rata dari permintaan |
| 2 | Tanyakan kepada layanan kunci untuk kunci enkripsi data atau gunakan kunci lokal yang dibungkus |
| 3 | Enkripsi bidang di aplikasi |
| 4 | Simpan ciphertext dan metadata di database |
| 5 | Hanya dekripsi di jalur baca yang disetujui |
Untuk penyimpanan aplikasi lokal, pertanyaan desain yang sama berlaku. Jika Anda menyimpan token offline atau keadaan sinkron yang sensitif di perangkat, jangan asumsikan penyimpanan mobile aman secara default. Gunakan pola yang sadar platform seperti yang dibahas dalam penyimpanan aman untuk token offline di Capacitor.
Enkripsi amplop adalah aman di dalam aman
Enkripsi amplop terdengar menakutkan, tapi konsepnya sederhana. Anda enkripsi data dengan satu kunci, kemudian enkripsi kunci tersebut dengan kunci lain yang lebih terlindungi.
Bayangkan itu seperti dokumen yang terkunci di dalam sebuah lemari aman kecil. Kunci lemari aman kecil tersebut kemudian terkunci di dalam sebuah vault bank.
Alur kerja biasa:
- Buat kunci data untuk catatan, file, atau batch.
- Enkripsi data dengan kunci data tersebut.
- Bungkus kunci data menggunakan kunci utama di KMS atau HSM.
- Simpan ciphertext plus metadata kunci yang dibungkus bersama dengan catatan atau objek.
- Hanya unwrap selama pembacaan yang diotorisasi.
Kiat lapangan: Pakai enkripsi amplop ketika Anda membutuhkan kompartemalisasi kuat tanpa mengekspos kunci utama yang berumur lama kepada setiap server aplikasi.
Gaya ini umum karena seimbang antara kinerja dan kontrol. Aplikasi menggunakan kunci data yang berumur pendek untuk pekerjaan enkripsi sebenarnya, sementara KMS atau HSM melindungi kunci utama yang digunakan untuk mengampulkannya dan menggunakannya.
Pembandingan Pola Enkripsi
| Pola | Kompleksitas Implementasi | Dampak Kinerja | Terbaik Untuk |
|---|---|---|---|
| Enkripsi Disk atau Volume | Rendah | Rendah | Perlindungan tingkat infrastruktur untuk server dan penyimpanan terhubung |
| Enkripsi Data Transparan | Rendah hingga sedang | Rendah hingga sedang | Perlindungan database keseluruhan dengan perubahan aplikasi minimal |
| Enkripsi aplikasi-level | Sedang hingga tinggi | Bervariasi tergantung penggunaan kolom dan desain kueri | Kolom sensitif tinggi dan pemisahan ketat diperlukan |
| Enkripsi amplop | Sedang hingga tinggi | Sedang | Jaringan yang memerlukan isolasi kunci yang lebih kuat dan kontrol kunci yang skalabel |
Aturan praktisnya sederhana. Mulai dengan basis kuat seperti TDE atau enkripsi di-aktifkan secara otomatis. Tambahkan enkripsi tingkat lapangan atau amplop hanya di mana sensitivitas data dan model ancaman membenarkan biaya tambahan untuk insinyur.
Penguasaan Pengelolaan Kunci dan Rahasia
Serangan sering kali dimulai dengan kesalahan penanganan rahasia biasa. Basis data produksi dienkripsi, cadangan ada, dan akses tampak terkendali pada kertas. Kemudian, pekerjaan CI mencetak token ke log, insinyur menggunakan kembali kredential admin untuk skrip dukungan, atau kunci yang ketinggalan zaman tetap aktif lama setelah tim yang menciptakannya telah berpindah.
Oleh karena itu, pengelolaan kunci dan rahasia adalah praktik operasional, bukan tugas pengaturan.
Basis data yang dienkripsi dengan kunci yang tidak dihandle dengan baik bekerja seperti ruang server yang terkunci dengan akses yang tergantung di pegangan pintu. Pedoman pemerintah membuat poin yang sama. Enkripsi sendiri tidak menutup celah jika tim melewatkan pengelolaan kunci berbasis KMS atau HSM, akses yang paling tidak berkekuatan, dan rencana pemulihan, seperti yang dijelaskan dalam pedoman NSA dan mitra dalam mengamankan data di awan.
Di mana tim salah
Polanya familiar dalam tinjauan insiden:
- Rahasia di sumber code: Kredential yang dihardcode, sertifikat yang diintegrasikan, atau skrip utilitas yang secara bertahap menjadi dependensi produksi.
- Rahasia di file konfigurasi yang dicopy: file-file yang dipindahkan antara laptop, disimpan di folder bersama, atau dikomitkan selama perbaikan yang terburu-buru.
- Variabel lingkungan dengan kontrol yang lemah: nyaman, tapi sering terbuka melalui log pembangunan, riwayat shell, laporan kegagalan, atau izin runtime yang luas.
- Tidak ada kepemilikan untuk rotasi: kunci ada selama bertahun-tahun karena tidak ada tim yang memiliki rencana reissue, rollout, dan rollback.
- Sekret privilègi bersama: satu kredential yang digunakan oleh aplikasi, insinyur, dan otomatisasi, yang membuat audit dan pengendalian menjadi lebih sulit.
Jika Anda standardisasi cara menyimpan rahasia aplikasi dan infrastruktur, referensi yang praktis untuk mengelola variabel lingkungan yang aman dapat membantu tim meninggalkan penyebaran rahasia ad hoc.
Apa yang baiknya pengelolaan kunci seperti itu
Gunakan __CAPGO_KEEP_0__ ketika kebijakan pusat, pengendalian akses, log audit, dan rotasi yang dijadwalkan lebih penting daripada kontrol perangkat keras yang disesuaikan. Gunakan HSM ketika risiko, persyaratan kompatibilitas, atau aturan perlindungan kunci dan tanda tangan membenarkan batasan perangkat keras yang dedikasi. Banyak tim tidak memerlukan HSM di mana-mana. Mereka memerlukan aturan yang jelas untuk sistem mana yang dapat meminta operasi dekripsi, manusia mana yang dapat mengubah kebijakan, dan bagaimana aksi-aksi tersebut diperiksa.
Enkripsi amplop adalah model mental yang baik di sini. Ini bekerja seperti menjaga uang tunai di dalam kotak kecil yang terkunci, kemudian menyimpan kotak tersebut di dalam vault bank. Aplikasi mengelola kunci data yang singkat untuk pekerjaan enkripsi. Kunci vault tetap di KMS atau HSM, dan akses kepadanya sangat terbatas.
Kontrol yang mencegah insiden nyata adalah operasional:
- Rotasi kunci pada jadwal yang dapat dieksekusi dengan aman: rotasi mengurangi umur kunci yang telah dibajak, tetapi hanya jika aplikasi, pekerjaan, dan pemulihan masih berfungsi setelahnya.
- Tugas yang terpisah: layanan yang membaca data pelanggan tidak boleh juga dapat mengubah kebijakan kunci atau mematikan logging.
- Catat peristiwa kunci yang sensitif: pembuatan kunci, rotasi, permintaan dekripsi, upaya akses yang gagal, dan perubahan kebijakan harus semua terlihat.
- Menguji kembali jalur pengenkripsi ulang: Menggulung kunci penggulung biasanya lebih mudah daripada mengenkripsi data aplikasi, tetapi kedua-duanya memerlukan buku rencana dan langkah mundur.
- Matikan dan pensiunkan rahasia lama secara sengaja: Biarkan waktu untuk proses migrasi, kemudian hapus kreditus kuno sehingga tidak dapat menjadi pintu belakang diam.
CI/CD layak mendapatkan disiplin yang sama seperti runtime produksi. Sistem bangun biasanya memiliki akses luas dan visibilitas lemah, yang membuatnya menjadi tempat umum untuk kebocoran rahasia. Tim yang serius tentang ini biasanya formalisasi manajemen rahasia dalam alur CI/CD bukanlah menganggap kreditus alur pipa sebagai pengecualian sementara.
Aturan sederhana. Aplikasi code harus meminta operasi kriptografi dari sistem yang dipercaya, bukan membawa kunci utama mentah ke sekitar lingkungan.
Desain pengenkripsi yang paling kuat di dalam stack Anda tidak akan berarti apa-apa jika seorang pengembang, alur pipa, atau alat dukungan dapat menyalin kunci utama ke tempat yang salah.
Mengembangkan Strategi Cadangan dan Pemulihan yang Tahan Banting
Cadangan adalah bagian dari penyimpanan database yang aman, bukan tugas administratif terpisah. Jika produksi dilindungi dan cadangan tidak, penyerang akan mengambil jalan yang lebih mudah.
Guidance penyimpanan independen merekomendasikan menjaga sistem cadangan dan pemulihan pada tingkat perlindungan yang sama dengan produksi karena insiden ransomware dan malware sering kali meninggalkan cadangan yang aman dan teruji sebagai satu-satunya jalur pemulihan yang masuk akal, menurut Hypertec’s panduan penyimpanan data yang aman.
Backup memerlukan batasan keamanan sendiri
Desain backup yang tahan lama memiliki beberapa sifat:
- Backup dienkripsi dalam perjalanan dan di tempat istirahat.
- Kredensial backup terpisah dari kredensial produksi.
- Kontrol penghapusan dan penyimpanan lebih sulit untuk disalahgunakan daripada akses aplikasi normal.
- Target restorasi tidak menjadi lingkungan produksi bayangan dengan kontrol yang lemah.
Mode gagal umum adalah menyimpan backup yang dienkripsi sementara membiarkan peran produksi yang sama menghapusnya. Mode lainnya adalah mengembalikan ke lingkungan sementara dengan akses insinyur yang luas dan tidak ada logging.
Uji restorasi adalah kontrol yang sebenarnya
Backup yang tidak diuji hanya penyimpanan yang berharap.
Tim yang dapat mengembalikan dengan baik tidak hanya memverifikasi bahwa pekerjaan backup selesai. Mereka membuktikan bahwa restorasi berhasil, bahwa data yang dikembalikan dapat digunakan, dan bahwa kunci dekripsi, pengaturan koneksi, dan layanan yang terkait semua berada di tempat ketika dibutuhkan.
Program restorasi yang praktis termasuk:
- Routine restore drills ke dalam lingkungan yang terisolasi.
- Pengecekan fungsi aplikasi setelah pemulihan database, bukan hanya pemulihan file.
- Pengecekan ketersediaan kunci agar cadangan yang dienkripsi dapat di dekripsi.
- Pengujian akses pada sistem yang dipulihkan untuk mencegah data sensitif menjadi terlihat luas selama insiden.
Cadangan tidak menyelamatkan Anda. Pemulihan yang sukses menyelamatkan Anda.
Jika Anda hanya menguji pembuatan cadangan dan tidak pernah menguji pemulihan di bawah tekanan, maka Anda belum memvalidasi strategi pemulihan Anda. Anda telah memvalidasi bahwa file dapat mengumpul di suatu tempat.
Daftar Periksa Pengembang untuk Penyimpanan Database yang Aman
Ini adalah daftar periksa yang saya ingin tim menggunakan selama ulasan desain, ulasan rilis, dan pembersihan pasca-insiden.
Desain
- Apakah kita telah mengidentifikasi lapangan-lapangan sensitif dengan jelas: data pribadi, bahan autentikasi, catatan keuangan, dan apa saja yang tunduk pada aturan penyimpanan.
- Apakah kita telah memutuskan apa saja yang tidak perlu disimpan: lapangan-lapangan yang tidak diperlukan oleh fitur, dan salinan yang dapat dihindari oleh tim-tim downstream.
- Apakah kita telah memetakan semua tempat di mana data akan hidup: produksi, pengujian, log, ekspor, sistem analitik, cadangan, dan perangkat klien.
Implementasi
- Apakah data dienkripsi di tempat dan dalam perjalanan: untuk database, replika, dan jalur cadangan.
- Apakah peran aplikasi dan layanan ditetapkan dengan ketat: Tidak ada superuser bersama untuk lalu lintas aplikasi normal.
- Apakah rahasia dan kunci enkripsi diatur di luar code dan konfigurasi longgar: dengan akses yang dikendalikan dan auditabilitas.
- Apakah kita log akses sensitif dan perubahan hak istimewa: di tempat sentral yang dapat ditanya oleh penjaga.
Operasi
- Apakah rotasi kunci dan tinjauan rahasia merupakan bagian dari operasi normal: bukanlah kerumunan tahunan.
- Apakah kita tes restorasi secara teratur: termasuk dekripsi, startup aplikasi, dan tinjauan akses pada sistem yang ditemukan kembali.
- Apakah kita audit penyebaran data secara terus-meneri: salinan pengembangan, ekspor dukungan, dataset pengembangan, dan lokasi cadangan yang dilupakan.
Penyimpanan database yang aman tidaklah merupakan tahap proyek. Ini merupakan disiplin yang berulang.
Frequently Asked Questions
Apakah enkripsi default penyedia cloud cukup baik
Ini merupakan dasar yang kuat, bukan strategi yang lengkap. Enkripsi default membantu melindungi media penyimpanan dan layanan yang diatur, tetapi tidak menyelesaikan akses yang berlebihan, dataset yang dicopy, kontrol backup yang lemah, atau pengelolaan kunci yang buruk.
Apakah enkripsi dapat merusak kinerja database
Beberapa kali, ya. Dampaknya tergantung pada pola. Enkripsi infrastruktur dan database biasanya memiliki kompleksitas aplikasi yang lebih sedikit. Enkripsi field-level memberikan kontrol yang lebih kuat untuk data yang dipilih, tetapi dapat memperumit indeks, filtering, dan pencarian. Ukur pada beban kerja Anda sebelum peluncuran luas.
Apakah ini berbeda untuk sistem SQL dan NoSQL
Prinsip-prinsip tetap sama. Anda masih membutuhkan enkripsi, hak istimewa yang paling sedikit, auditing, pengelolaan kunci, dan pemulihan yang telah diuji. Detail implementasi berbeda karena penyimpanan dokumen, penyimpanan nilai kunci, dan sistem relasional menampilkan model akses yang berbeda dan perilaku kueri.
Bagaimana tokenisasi berbeda dari enkripsi
Enkripsi mengubah data sehingga sistem yang diotorisasi dapat membaliknya dengan kunci yang tepat. Tokenisasi mengganti nilai sensitif dengan nilai pengganti dan menyimpan data asli terpisah. Tokenisasi dapat mengurangi paparan dalam alur kerja aplikasi, tetapi menambahkan kompleksitas desain sistem dan tidak menghilangkan kebutuhan untuk kontrol penyimpanan yang kuat.
Capgo membantu tim untuk mengirimkan perbaikan ke Capacitor dan aplikasi Electron dengan cepat, dengan pengiriman bundle web yang ditandatangani, kontrol peluncuran, perlindungan rollback, dan observabilitas rilis. Jika rencana tanggap darurat Anda bergantung pada mendapatkan perbaikan sisi klien keluar cepat setelah kesalahan penyimpanan, autentikasi, atau API Capgo layak dievaluasi sebagai bagian dari sisi operasional dari pemulihan.
