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

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Enkripsi perlu dinilai bersama hak akses, penyimpanan kunci, dan pemulihan. Tim juga perlu mengurus token, kata sandi layanan, serta salinan data yang tersebar di lingkungan uji dan cadangan.

URL kanonis: https://kompli.id/panduan/keamanan/enkripsi-kunci-dan-data-uji/
Sumber diakses: 2026-09-29
Diperbarui: 2026-09-29
Penulis: Kompli
Sumber diperiksa: 2026-09-29


## 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](/panduan/pdp/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](/panduan/pdp/retensi-dan-penghapusan-data-pribadi/), 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?

<details class="learning-answer">
<summary>Tim hanya ingin memeriksa tampilan daftar. Perlukah seluruh database pelanggan?</summary>
<p>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.</p>
</details>

<details class="learning-answer">
<summary>Nama diganti, tetapi nomor telepon dan catatan pelanggan tetap utuh. Apakah salinan bebas dibagikan?</summary>
<p>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.</p>
</details>

<details class="learning-answer">
<summary>Salinan database dienkripsi, tetapi semua anggota tim bisa membukanya. Apakah akses sudah dibatasi?</summary>
<p>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.</p>
</details>

## 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](/template/catatan-insiden-keamanan/#kartu-awal-api-key-atau-secret-terbuka); rotasi saja belum menjadi dasar untuk menyatakan insiden selesai.

Untuk penanganan terperinci, buka [langkah saat API key bocor](/panduan/keamanan/api-key-bocor/) dan [lembar rotasi kredensial](/template/rotasi-kredensial-insiden/).

## Pahami risiko di balik pemeriksaan

Baca [Cryptographic Failures](/panduan/owasp/cryptographic-failures/) untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.
## Sumber rujukan

- [UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi](https://jdih.komdigi.go.id/produk_hukum/view/id/832/t/crc32/) — Pasal 1, 20, 27–28 dan 35–39; identifikasi, dasar dan tujuan pemrosesan, serta pengamanan data
- [OWASP — Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) — Architectural Design, Key Management, Key Storage; lapisan enkripsi dan pemisahan kunci
- [OWASP — Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) — Bagian 2.3, 2.6–2.9 dan 9; akses, audit, siklus secret, pemulihan dan insiden

## Jalur belajar: Website dan aplikasi

Materi berikutnya: [Tentukan prioritas pembaruan dan periksa hasilnya](https://kompli.id/panduan/keamanan/mengelola-kerentanan-dan-patch/)

[Lihat urutan belajar](https://kompli.id/belajar/#website-dan-aplikasi)


## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Cara membuat catatan pemrosesan data pribadi (ROPA)](https://kompli.id/panduan/pdp/catatan-pemrosesan-data-pribadi/)
- [Retensi data pribadi: menentukan masa simpan dan penghapusan](https://kompli.id/panduan/pdp/retensi-dan-penghapusan-data-pribadi/)
- [Keamanan API: akses pengguna, tenant, token, dan batas penggunaan](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
- [Template catatan dan contoh laporan insiden keamanan](https://kompli.id/template/catatan-insiden-keamanan/)