Menggunakan audit log

Setiap permintaan API di organisasi Anda dicatat selama 365 hari - siapa, apa, kapan, dari mana, dan lewat aplikasi mana. Ini adalah tempat pertama yang perlu diperiksa saat Anda perlu tahu apa yang terjadi.

Ditulis oleh Dukungan Didit · Diperbarui 19 Agustus 2026

#Apa yang dicatat

1234

1. Filter berdasarkan anggota, path, method, atau tanggal untuk menjawab 'siapa yang mengubah ini'.
2. Method dan status membedakan sebuah pembacaan dari sebuah perubahan yang benar-benar berlaku.
3. Anggota yang melakukan panggilan tersebut.
4. Dari mana asalnya - detail yang mengubah sebuah log menjadi bukti.

Setiap permintaan yang dibuat ke platform Didit di dalam organisasi Anda, apa pun yang membuatnya. Setiap entri membawa:

Log disimpan selama 365 hari lalu dihapus secara otomatis.

#Untuk apa sebenarnya ini digunakan

Empat situasi di mana ini adalah alat yang tepat:

• "Siapa yang mengubah workflow ini?" Sebuah alur yang berperilaku berbeda dari kemarin biasanya ada perubahan di baliknya, dan log menyebutkan siapa yang melakukannya.
• Menyelidiki sebuah insiden. Melacak persis apa yang diakses, oleh siapa, dari alamat mana, dalam urutan apa.
• Men-debug sebuah integrasi. Melihat permintaan yang benar-benar dibuat kode Anda sendiri, bukan yang Anda kira dibuatnya - termasuk yang menghasilkan error 4xx.
• Membuktikan kontrol akses. Menunjukkan kepada auditor bahwa akses ke data verifikasi bersifat teratribusi dan bisa ditinjau.

#Memfilter

Filter berdasarkan pengguna, endpoint, atau rentang tanggal untuk mempersempit daftar yang panjang. Ketika Anda sedang menyelidiki sesuatu yang spesifik, mulailah dari timestamp lalu bergerak keluar dari sana - sebuah permintaan jarang terjadi sendirian, dan panggilan-panggilan di sekitarnya biasanya menceritakan keseluruhan kisahnya.

#Permintaan dengan API key diatribusikan ke aplikasi, bukan ke seseorang

Sebuah permintaan dengan API key tidak punya pengguna untuk diatribusikan, jadi ditampilkan atas nama aplikasi. Itu adalah representasi yang jujur - platform ini sungguh-sungguh tidak tahu layanan atau engineer mana dari pihak Anda yang membuat panggilan tersebut.

Konsekuensi praktisnya: satu key yang dibagikan ke beberapa layanan membuat sebuah insiden jauh lebih sulit diselidiki. Jika atribusi penting bagi Anda, beri setiap konsumen aplikasi dan key-nya sendiri.

#Apa yang ada di dalam log, dan apa yang tidak

Log ini mencatat aktivitas - siapa memanggil apa, kapan, dari mana, dan status apa yang dikembalikan. Ini adalah jejak metadata, bukan salinan dari data verifikasi.

Jika Anda perlu tahu apakah data pribadi pelanggan muncul di entri-entri ini - pertanyaan yang sering muncul selama tinjauan perlindungan data - dapatkan jawabannya dari kontak Didit Anda dan catat hasilnya, alih-alih menyimpulkannya sendiri dari sebuah halaman bantuan. Ini justru jenis pernyataan yang akan diminta DPIA Anda sendiri sebagai bukti.

#Siapa yang bisa melihatnya

Akses audit log mengikuti peran. Compliance Officer mencakupnya; Reader tidak memiliki akses yang luas. Owner bisa memberikannya ke sebuah peran kustom. Lihat mengundang anggota tim dan menetapkan peran.

Menghapus seorang rekan tim tidak menghapus riwayatnya dari log - dan memang itulah intinya. Sebuah jejak yang bisa Anda ubah bukanlah jejak.

#Ekspor dan laporan juga dicatat

Membuat PDF session atau ekspor CSV adalah sebuah panggilan API, jadi itu juga muncul di sini beserta siapa yang membuatnya. Ini berguna ketika Anda perlu menunjukkan bahwa akses ke bukti verifikasi terkontrol, bukan terbuka bebas. Lihat mengunduh laporan verifikasi.

#Jika Anda butuh lebih dari 365 hari

Retensinya tetap 365 hari. Jika kewajiban Anda lebih panjang dari itu, ekspor apa yang Anda perlukan secara terjadwal dan simpan di sistem Anda sendiri - pola yang sama seperti menyimpan sendiri bukti session. Menentukan periode yang diwajibkan adalah keputusan kepatuhan untuk tim Anda; jangan merancang berdasarkan asumsi.