Lindungi, Simpan, dan Buktikan

🌐 Juga tersedia dalam 28 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 6 dari 6 dalam bab Kualitas dan Tata Kelola Data, bab 5 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Persetujuan dan Hak untuk Dilupakan · Berikutnya: bab berikutnya, Data Master dan Identitas

Pertanyaan yang dijawab modul ini: Bagaimana Anda melindungi data, menyimpannya selama yang diwajibkan, dan membuktikannya?

Kita sudah menetapkan pemilik dan kebijakan, mencegah data buruk masuk, menulis kamus, menelusuri silsilah data, mengklasifikasikan yang penting, mempelajari hukum-hukumnya, dan memodelkan persetujuan. Sekarang kita harus menjalankannya. Data datang, dipakai, disalin, dan diubah, menua, dan pada akhirnya sebagian harus dihapus. Dan suatu hari seseorang akan bertanya: buktikan apa yang terjadi.

Tata Kelola Mengikuti Data

Saya tidak memandang tata kelola sebagai satu fitur. Saya memikirkan apa yang terjadi pada data sejak ia masuk sampai kita selesai dengannya:

Tangkap → Klasifikasikan → Lindungi → Pakai → Simpan → Hapus → Audit

Bukan tujuh proses teknis: tujuh pertanyaan yang harus dijawab arsitektur. Menangkap dan mengklasifikasikan sudah kita bahas: cegah kesalahan yang mahal (modul 2), dan ketahui data mana yang sensitif (modul 3). Klasifikasi menentukan apa yang terjadi di setiap tahap berikutnya, jadi modul ini melanjutkan dari sana.

Click to enlarge

Tujuh pertanyaan sepanjang hidup data. Alat mendukung kebijakan; alat tidak mendefinisikannya.

Lindungi: Sesuaikan Kontrol dengan Datanya

Siapa yang bisa melihatnya, mengubahnya, menerimanya? Haruskah ia dienkripsi, disamarkan di luar production, bisa diekspor, bisa dijangkau agen? Di sinilah keamanan Salesforce menjadi bagian dari tata kelola data: berbagi, izin objek dan bidang, enkripsi, penyamaran, akses integrasi. Topik-topik itu mengisi kursus-kursus utuh, jadi saya tidak akan mengajarkannya ulang. Poin tata kelolanya: perlindungan mengikuti klasifikasi dan kebijakan. Tidak setiap bidang butuh perlindungan yang sama, tidak setiap pengguna butuh akses yang sama, tidak setiap sistem hilir butuh setiap bidang.

Enkripsi Adalah Kontrol, Bukan Kepatuhan

Untuk data yang diatur regulasi, enkripsi saat disimpan (at rest) mungkin diwajibkan, dan posisi saya adalah Shield adalah jawaban untuk persyaratan regulasi utama seperti itu. Shield Platform Encryption mengenkripsi bidang dan file saat disimpan. Tetapi “kami sudah mengenkripsinya, jadi kami patuh” itu salah dua kali. Enkripsi adalah satu kontrol di antara akses, retensi, audit, persetujuan, pemantauan, minimisasi, dan penghapusan. Dan ia punya trade-off fungsional yang harus Anda rancang sejak awal. Dengan skema probabilistik bawaan, bidang terenkripsi tidak bisa dipakai di klausa SOQL WHERE, GROUP BY, atau ORDER BY maupun di filter manajemen data; enkripsi deterministik sedikit mengorbankan kekuatan agar Anda bisa memfilter berdasarkan bidang itu. Bidang terenkripsi tidak bisa menggerakkan aturan berbagi berbasis kriteria, dan Anda tidak bisa mengurutkan tampilan daftar berdasarkan bidang itu (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Jadi enkripsi bukanlah kotak centang di akhir. Ia keputusan arsitektur. Bab keamanan data membahasnya lebih dalam.

Jangan Menyalin Risiko Production ke Sandbox

Production dikunci rapat. Lalu seseorang menyegarkan sandbox penuh, dan developer, penguji, kontraktor, serta integrasi uji kini memegang salinan data pribadi asli yang tidak pernah mereka butuhkan. Lingkungannya berubah; sensitivitas datanya tidak. Alat-alat penyamaran Salesforce ada persis untuk ini. Perhatikan sebuah perubahan: paket terkelola Data Mask mencapai akhir layanan pada 31 Desember 2026, dan penggantinya adalah Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Tetapi alatnya mendukung kebijakan, dan pertanyaannya datang lebih dulu: apakah lingkungan ini benar-benar butuh data sensitif asli? Jika data realistis yang tidak sensitif bisa dipakai untuk pengujian, itulah jawaban yang lebih baik.

Pakai: Izin Bukan Hanya Soal Manusia

Pengguna, integrasi, analitik, mitra, otomatisasi, dan agen semuanya memakai data. Persetujuan (modul 5), kepemilikan (modul 1), dan klasifikasi (modul 3) bertemu di sini saat runtime. Haruskah pengguna ini melihat nomor telepon Penerima? Haruskah integrasi ini mendapatkannya, atau Snowflake, atau agen ini sebagai grounding? Jawabannya tidak bisa “yah, secara teknis bisa.” Itulah perbedaan antara kemampuan dan tata kelola: arsitektur memutuskan apakah ia seharusnya.

Simpan: Menyimpan Segalanya Selamanya Tidaklah Netral

Banyak organisasi punya kebijakan retensi yang tidak disengaja: selamanya. Tidak ada yang memutuskannya; penyimpanan tersedia, jadi datanya tetap ada. Tetapi menyimpan data ada harganya bagi penyimpanan dan kinerja, memperluas paparan privasi dan keamanan, menambah kewajiban penemuan (discovery), dan memberi Anda lebih banyak tempat untuk dicari ketika seseorang minta dilupakan. Untuk setiap kategori penting: mengapa disimpan, berapa lama, apa yang memulai hitungannya, apakah ada batas minimum hukum atau batas maksimum privasi, dan apa yang terjadi di akhir: arsipkan, hapus, hilangkan identitasnya?

Dan mengarsipkan tidak sama dengan menyelesaikan retensi. “Kami sudah mengarsipkannya.” Apakah persyaratan retensinya hilang? Persyaratan privasinya? Keamanannya? Anda mengubah tempat data tinggal, bukan apa data itu. Sebuah arsip butuh kontrol akses, aturan retensi dan penghapusan, penemuan, dan audit. Pindahkan data pribadi ke arsip yang dilupakan semua orang, dan tata kelolanya justru memburuk.

Hapus: Siklus Hidup Butuh Pintu Keluar

Penghapusan bukan hanya untuk permintaan privasi individu. Data mencapai akhir periode retensinya; rekaman sementara hidup lebih lama daripada kegunaannya; arsip kedaluwarsa; sebuah proses menghilangkan identitas setelah waktu tertentu. Apa pun yang dinyatakan kebijakan, arsitektur butuh pintu keluar, bukan tangkap → simpan → simpan lebih banyak → simpan selamanya. Dan seperti yang ditunjukkan modul 5, menghapus rekaman Salesforce tidak cukup ketika salinannya tinggal di tempat lain.

Riwayat Juga Data

Kadang nilai saat ini tidak cukup. Nama resmi seorang mitra, klasifikasi seorang pelanggan, status persetujuan, atribut keuangan: bisnis atau regulator mungkin perlu tahu nilainya sebelumnya, kapan berubah, dan siapa yang mengubahnya. Riwayat itu adalah data, dan butuh keputusan retensinya sendiri.

Pelacakan riwayat bidang standar mengikuti hingga 20 bidang per objek dan menyimpan perubahan hingga 18 bulan, dan hingga 24 bulan hanya melalui API, dengan Data Loader atau queryAll() (Field History Tracking Overview (opens in a new tab)). Dan untuk bidang teks panjang, ia hanya mencatat bahwa bidang itu diedit, bukan isinya: sebuah celah jika itu bukti Anda. Field Audit Trail, bagian dari Shield atau dibeli tersendiri, mengikuti hingga 200 bidang per objek dan menyimpan riwayatnya sampai Anda menghapusnya, di arsip yang Anda jangkau melalui API (Field Audit Trail (opens in a new tab)). Posisi saya: riwayat bidang standar adalah bawaannya; pakai Field Audit Trail ketika regulasi atau kewajiban kepatuhan menuntut riwayat yang lebih panjang dan bisa dibuktikan. Bukan karena “audit terdengar bagus.”

Audit dan Pemantauan Tidaklah Sama

Riwayat bidang menjawab pertanyaan tentang perubahan pada bidang-bidang tertentu. Pertanyaan yang lebih luas (siapa yang login, siapa yang mengekspor data, API mana yang dipanggil, siapa melihat apa) adalah pemantauan, dan itulah Event Monitoring. Dalam pengalaman saya, ini biasanya dibutuhkan pelanggan yang lebih diatur regulasi, dan inilah posisi terkuat saya di bab ini: siapkan sebelum Anda membutuhkannya, dan alirkan event-eventnya ke sebuah repositori, seperti Splunk atau SIEM lain, jauh-jauh hari.

Inilah alasannya. File log event disimpan selama 1 hari tanpa add-on, dan hanya untuk sebagian tipe event; 30 hari secara bawaan dengan Shield atau add-on Event Monitoring, dan hingga 365 hari jika Anda memperpanjang retensinya (Event Monitoring FAQ (opens in a new tab)). Apa pun yang lebih lama sudah hilang kecuali Anda mengekspornya. Dan log berbayar tidak bisa diambil untuk periode apa pun sebelum kontrak Anda dimulai (FAQ yang sama): membeli add-on setelah insiden terjadi tidak mengembalikan masa lalu. Jadi salah satu percakapan terburuk yang bisa dialami seorang arsitek berjalan begini: “Bisakah kita melihat apa yang terjadi enam bulan lalu?” “Tidak.” “Kenapa tidak?” “Kita tidak menangkapnya.” Anda tidak boleh baru menyadari setelah masalah terjadi bahwa selama ini Anda tidak menangkap dan menyimpan event-event itu. Saat itu jawabannya sudah lenyap.

Click to enlarge

Siapkan sebelum Anda membutuhkannya.

Tetapi jangan berayun ke “catat semuanya.” Apa yang sedang Anda coba buktikan? Event mana yang penting, siapa yang membutuhkannya, berapa lama, siapa yang boleh membaca log-nya, dan bisakah log itu sendiri berisi data sensitif? Pencatatan menciptakan data, dan data itu juga butuh tata kelola. Dan bukti butuh pemilik: siapa pemilik repositorinya, meninjau peringatan, memeriksa bahwa retensinya berjalan, menyadari bahwa umpan datanya diam-diam gagal sejak tiga bulan lalu? Teknologi tanpa kepemilikan bukanlah tata kelola; kita kembali ke pemilik, steward, dan kustodian dari modul 1.

Buktikan Kontrolnya, Bukan Hanya Konfigurasinya

“Data Penerima hanya tersedia bagi kru yang ditugaskan ke titik pemberhentian itu.” Bagaimana kita tahu? Konfigurasi keamanan menunjukkan apa yang seharusnya terjadi. Bukti operasional (siapa yang benar-benar mengaksesnya, ekspor yang tidak biasa, sebuah integrasi yang menariknya, kontrol akses yang berubah) menunjukkan apa yang benar-benar terjadi. Tata kelola yang baik sering butuh keduanya.

Di luar ujian: apa yang diubah AI. Ketika agen beralih dari menjawab ke bertindak, tata kelola butuh bukti tentang apa yang dilihat agen, apa yang diputuskan atau dihasilkannya, dan apa yang dilakukannya, serta siapa atau apa yang memulainya, di bawah kebijakan mana. Mekanisme pencatatannya akan berubah; persyaratannya tidak: jika sebuah tindakan otonom itu penting, rancang sekarang bagaimana Anda akan merekonstruksinya nanti.

Steve Trucking: Siklus Hidup pada Satu Bidang

Ambil nomor telepon Penerima. Tangkap: ia datang di manifes mitra; periksa apakah bisa dipakai di tempat proses membutuhkannya. Klasifikasikan: data pribadi. Lindungi: hanya orang dan sistem dengan kebutuhan operasional yang menerimanya, dan kru hanya melihatnya untuk titik pemberhentian mereka sendiri, di hari itu. Pakai: kru mengoordinasikan pengiriman; perpesanan memakainya untuk tujuan yang disetujui; agen memakainya hanya jika kebijakan mengizinkan. Simpan: selama kebijakan bisnis dan privasi yang disetujui menyatakan. Hapus atau hilangkan identitasnya: ketika periode itu berakhir atau permintaan yang sah datang, di setiap salinan di seluruh lanskap. Audit: simpan bukti bahwa kontrol dan tindakannya terjadi.

Sekarang ambil kode pusat distribusi. Tangkap dengan akurat, klasifikasikan sebagai data referensi yang tidak sensitif, lindungi dengan akses operasional biasa, pakai secara luas, simpan sesuai kebutuhan bisnis, dan audit perubahannya jika penting. Siklus hidup yang sama, kontrol yang berbeda. Untuk itulah klasifikasi ada.

Tata Kelola Tidak Pernah Selesai

Sebuah regulasi baru muncul. Sebuah sistem atau integrasi baru menciptakan satu salinan lagi. Sebuah tim menciptakan satu bidang lagi. Sebuah platform baru go-live. Sebuah agen mendapat akses. Sebuah aturan retensi berubah. Sebuah Mitra Ritel baru datang. Arsitekturnya bergerak, dan tata kelola ikut bergerak. Tujuannya bukan data yang sempurna, kontrol yang tak terbatas, atau dokumen tata kelola yang tidak dibaca siapa pun. Tujuannya adalah keputusan-keputusan yang disengaja tentang data, yang dibangun ke dalam arsitektur.

Yang Diputuskan Arsitek di Sini

• Kontrol perlindungan mana yang didapat setiap kategori data, berdasarkan klasifikasi, kebijakan, dan pemakaian nyata, termasuk trade-off enkripsi.
• Berapa lama data dan riwayatnya disimpan, apa yang memulai hitungannya, dan apa yang terjadi di akhir.
• Kapan riwayat bidang standar sudah cukup dan kapan regulasi menuntut Field Audit Trail.
• Event mana yang ditangkap, di mana buktinya disimpan melampaui retensi platform, dan siapa pemiliknya.
• Bagaimana arsitektur membuktikan tindakan penting manusia, integrasi, dan agen setelah kejadian.

Bab ini dimulai dengan satu gagasan: tata kelola dirancang ke dalam org, bukan ditulis di sampingnya. Pemilik menetapkan kebijakan dan arsitek menegakkannya. Cegah data buruk masuk di tempat yang penting. Ketahui apa arti data Anda, dari mana asalnya, dan seberapa sensitif ia. Hormati hukum, modelkan persetujuan, kendalikan ke mana data pribadi pergi. Lindungi, simpan, dan hapus sesuai kebijakan. Dan tangkap buktinya sebelum ada yang memintanya, karena enam bulan setelah sebuah insiden adalah waktu yang buruk sekali untuk mengetahui bahwa buktinya hanya ada selama tiga puluh hari.

Jelajahi

• Bantuan Salesforce, General Shield Platform Encryption Considerations (opens in a new tab) dan Filter Encrypted Data with Deterministic Encryption (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Field History Tracking Overview (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Field Audit Trail (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).