Enkripsi, kunci, secret, dan data uji: pembagian tanggung jawab

Apa yang perlu dipetakan lebih dulu?

Catat tempat data berada, siapa yang dapat membacanya, dan siapa yang mengelola perlindungannya. Sertakan database, berkas, cadangan, log, ekspor, perangkat kerja, dan lingkungan uji. Label “sudah dienkripsi” belum menjelaskan semuanya.

Panduan ini membantu pembagian pekerjaan teknis. Enkripsi tidak menggantikan dasar pemrosesan, pembatasan tujuan, atau pemenuhan hak data pribadi. Hubungkan peta ini dengan catatan pemrosesan data pribadi.

Apa beda enkripsi saat dikirim dan disimpan?

Enkripsi saat dikirim melindungi perjalanan data pada koneksi yang dicakup. Enkripsi saat disimpan melindungi data pada lapisan tertentu, misalnya media penyimpanan atau aplikasi. Pilihannya bergantung pada ancaman yang hendak dihadapi.

Contohnya, enkripsi media tidak otomatis mencegah pembacaan melalui aplikasi yang memiliki izin membuka data. Karena itu, minta penjelasan tentang lapisan perlindungan, jalur pembukaan data, dan pihak yang memegang akses kunci. Jangan merancang algoritma kriptografi sendiri.

Contoh peta perlindungan data

Berikut contoh fiktif untuk aplikasi dokumen. Kolom bukti adalah hal yang perlu diminta, bukan pernyataan bahwa pengamanan telah diterapkan.

Salinan	Pertanyaan dan bukti yang diperiksa
Dokumen utama	Siapa dapat mengunduh dan membuka kuncinya? Periksa konfigurasi izin dan hasil pemeriksaan akun uji.
Cadangan	Apakah perlindungan dan kunci tersedia saat pemulihan? Periksa catatan restore di lingkungan terpisah.
Ekspor petugas	Di mana berkas disimpan dan kapan dihapus? Periksa pemilik ekspor, batas akses, dan jadwal retensi.
Lingkungan uji	Mengapa data ini diperlukan? Periksa daftar data fiktif atau keputusan penggunaan data yang telah ditinjau.
Log aplikasi	Apakah token atau isi dokumen ikut tercatat? Periksa sampel log yang sudah disamarkan dan tindak lanjut temuan.

Lengkapi peta dengan lokasi sistem, pihak penyedia, penanggung jawab internal, dan tanggal pemeriksaan. Klaim penyedia perlu dicocokkan dengan layanan serta konfigurasi yang benar-benar dibeli.

Apa yang disebut secret?

Secret adalah rahasia yang memberi akses, seperti kata sandi database, token layanan, dan kunci API. Batasi siapa atau layanan apa yang dapat mengambilnya, catat penggunaannya tanpa mencetak nilainya, serta siapkan pencabutan dan penggantian.

Jangan memasukkan secret aktif ke kode sumber, tangkapan layar, tiket umum, atau keluaran proses otomatis. Menghapus satu baris dari kode belum mencabut rahasia yang sudah tersebar. Jika bocor, nilai cakupan pemakaian, cabut atau ganti sesuai rencana, periksa penggunaan yang mencurigakan, dan pastikan layanan tetap berjalan.

Siapa mengurus kunci dan pemulihan?

Pisahkan penyimpanan kunci dari data sesuai desain yang dipilih. Tentukan pihak yang berhak membuat, memakai, mengganti, memulihkan, dan menonaktifkan kunci. Tim perlu memahami akibat kehilangan atau penghapusan kunci terhadap data dan cadangan.

Contoh keputusan internal: sebelum mengganti kunci layanan dokumen, pemilik pekerjaan menyiapkan daftar komponen pemakai, pemeriksaan setelah pergantian, dan cara memulihkan layanan. Catat hasilnya; jangan hanya mengandalkan status “rotasi berhasil” dari satu alat.

Bolehkah menyalin database produksi untuk pengujian?

Utamakan data fiktif yang cukup untuk menguji fungsi. Mengganti nama saja belum memastikan seseorang tidak dapat dikenali dari kombinasi kolom lain. Bila data nyata memang diperlukan, tinjau tujuan, kewenangan, pembatasan akses, salinan turunannya, dan waktu penghapusan sebelum memindahkannya.

Jangan memakai daftar ini sebagai persetujuan otomatis untuk menyalin data pelanggan. Tetapkan pemilik keputusan bersama pihak yang menangani PDP dan keamanan. Setelah pengujian, periksa penghapusan salinan sesuai panduan retensi dan penghapusan, termasuk pengecualian yang sah dan siklus cadangan.

Contoh memilih data sesuai tujuan pengujian

Contoh berikut adalah saran Kompli. Buat data dari awal tanpa menyalin identitas, isi dokumen, atau kredensial pelanggan.

Tujuan uji	Bahan yang disiapkan
Tampilan daftar pesanan	Pesanan buatan dengan teks pendek/panjang, nilai kosong, dan status berbeda
Pembatasan akses	Dua akun dan dokumen fiktif dengan pemilik serta izin berbeda
Batas kapasitas	Data buatan dengan jumlah dan ukuran yang direncanakan; jalankan pada lingkungan dan beban yang diizinkan

Data fiktif membantu membatasi paparan, tetapi harus mewakili kondisi yang ingin diuji. Uji tampilan yang berhasil belum membuktikan ketepatan migrasi database atau kemampuan layanan pada beban nyata. Bila kasusnya belum terwakili, perbaiki rancangan uji terlebih dahulu.

Latihan: salinan apa yang benar-benar diperlukan?

Tim hanya ingin memeriksa tampilan daftar. Perlukah seluruh database pelanggan?

Mulai dengan baris buatan yang mewakili variasi tampilan. Catat kekurangan cakupannya jika ada. Kemudahan menyalin database bukan alasan untuk membawa data yang tidak diperlukan ke lingkungan uji.

Nama diganti, tetapi nomor telepon dan catatan pelanggan tetap utuh. Apakah salinan bebas dibagikan?

Tidak. Orang masih dapat dikenali dari informasi lain. UU PDP Pasal 1 mencakup identifikasi melalui gabungan informasi. Tinjau isi dan tujuan penggunaan; untuk uji yang cukup dengan data fiktif, buat datanya dari awal.

Salinan database dienkripsi, tetapi semua anggota tim bisa membukanya. Apakah akses sudah dibatasi?

Enkripsi tidak membatasi anggota yang sudah diberi kemampuan membuka data. Periksa siapa memerlukan akses dan cabut izin yang tidak diperlukan. Catat pula ekspor, log, dan cadangan yang mungkin menyimpan salinan setelah pengujian selesai.

Contoh: API key masuk repositori publik

Contoh fiktif: pengembang menemukan API key produksi pada berkas contoh yang sudah terunggah. Menghapus baris pada versi terbaru belum mencabut key, dan salinannya mungkin masih ada pada riwayat atau tempat lain.

Hubungi pemilik sistem melalui jalur insiden. Petugas berwenang mencabut key yang terpapar, menyiapkan pengganti melalui penyimpanan yang aman, serta memperbarui layanan yang bergantung padanya. Catat bukti secara terbatas sambil membatasi paparan; jangan menyebarkan key ke tiket umum atau menghapus seluruh riwayat tanpa menilai dampak pada bukti dan tim.

Periksa log penggunaan, cakupan izin, dan perubahan yang mungkin dibuat memakai key tersebut. Setelah penggantian, uji fungsi layanan dan lanjutkan pemeriksaan dampak. Gunakan kartu tindakan awal dan catatan insiden; rotasi saja belum menjadi dasar untuk menyatakan insiden selesai.

Untuk penanganan terperinci, buka langkah saat API key bocor dan lembar rotasi kredensial.

Pahami risiko di balik pemeriksaan

Baca Cryptographic Failures untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.