CDN adalah: Apa yang Boleh Disimpan di Edge Kanal Bank

CDN adalah jaringan server edge yang menyimpan salinan respons sebuah situs dan menyajikannya dari titik terdekat dengan pengguna. Per 23 Oktober 2026, Cloudflare, Amazon CloudFront, dan Google Cloud CDN sama-sama mencantumkan PoP di Jakarta. Untuk bank, asuransi, atau multifinance, CDN boleh menyimpan aset statis dan halaman publik. Ia tidak boleh menyimpan dasbor terautentikasi, API yang mengembalikan data pribadi, atau endpoint OTP dan sesi. Begitu CDN mendekripsi TLS di edge, menurut pembacaan kami operatornya ikut memproses data pribadi nasabah dalam arti Pasal 16 ayat (1) UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (disahkan 17 Oktober 2022).

Ini bukan penjelasan "apa itu CDN" yang kesekian. Ini daftar keputusan untuk CTO yang memilih apa yang diletakkan di belakang CDN, dan untuk DPO atau CISO yang harus mempertahankan pilihan itu di depan pemeriksa OJK. Artikel ini menutup klaster minggu ini, setelah SLA adalah: menit downtime dan klausul OJK dan cloud computing adalah: kewajiban bank dan asuransi di bawah OJK.

Tabel cache-policy: apa yang boleh disimpan CDN di kanal bank

Lima kelas respons mencakup hampir semua yang dikirim kanal digital sebuah bank. Header di bawah adalah sintesis WEBARQ dari RFC 9111, HTTP Caching (IETF Standards Track, Juni 2022), bukan kutipan dari satu dokumen. Angka s-maxage di baris kedua cuma contoh; sesuaikan dengan seberapa sering halaman itu benar-benar berubah.

Aset ber-hash aman disimpan setahun karena setiap deploy menghasilkan nama file baru. Salinan lama tidak pernah tertukar dengan yang baru. Untuk halaman publik, s-maxage hanya berlaku bagi cache bersama seperti CDN; menurut RFC 9111 §5.2.2.10 ia mengalahkan max-age di sana, sementara browser tetap memeriksa ulang ke origin.

Jebakan terbesarnya ada di baris API. RFC 9111 §3.5 melarang cache bersama memakai ulang respons atas request yang membawa header Authorization, kecuali respons itu memuat must-revalidate, public, atau s-maxage. Satu developer yang menambahkan public ke API saldo "supaya lebih cepat" baru saja membuat respons itu boleh dibagikan ke pengguna lain. Satu kata, satu baris kode.

Header saja tidak cukup

RFC 9111 sendiri menulis bahwa no-store "is not a reliable or sufficient mechanism for ensuring privacy." Alasannya praktis. Dokumentasi Cloudflare (diperbarui 14 September 2026) menyatakan Cloudflare tidak menyimpan respons ber-private, no-store, no-cache, atau max-age=0, respons yang membawa Set-Cookie, dan request selain GET. HTML dan JSON juga tidak disimpan secara default. Tapi urutan itu berlaku "unless an Edge Cache TTL cache rule overrides the headers."

Artinya titik kendali yang sebenarnya adalah konfigurasi CDN, bukan header aplikasi. Kunci path seperti /api/* dan area akun ke aturan bypass cache, dan perlakukan setiap perubahan aturan cache sebagai change request yang disetujui, sama seperti perubahan firewall. Kalau harus memilih satu kontrol saja, kami memilih aturan bypass di CDN. Satu aturan di satu konsol lebih mudah diaudit daripada disiplin header di setiap tim aplikasi.

Kegagalan yang nanti dilihat tim kepatuhan adalah web cache deception. Penyerang memancing nasabah yang sedang login membuka URL seperti /akun/profil/x.css. Kalau edge menyimpan berdasarkan ekstensi file dan origin mengabaikan akhiran itu, halaman profil nasabah tersimpan di edge dan bisa diambil penyerang. Itu kebocoran data pribadi, dan Pasal 46 ayat (1) UU PDP memberi waktu pemberitahuan paling lambat 3 x 24 jam.

TLS di edge: CDN menjadi Prosesor Data Pribadi

UU PDP tidak menyebut CDN, cache, atau TLS satu kali pun. Jadi posisi berikut adalah analisis kami, bukan bunyi undang-undang. Pasal 16 ayat (1) memasukkan "penyimpanan" (huruf c) dan "penampilan, pengumuman, transfer" (huruf e) ke dalam pemrosesan. Edge yang mendekripsi lalu menyimpan atau meneruskan respons melakukan keduanya. Pasal 1 angka 5 mendefinisikan Prosesor sebagai pihak yang memproses "atas nama Pengendali Data Pribadi". Bank adalah Pengendali; operator CDN adalah Prosesor.

Konsekuensinya bisa dibaca pasal per pasal:

• Pasal 51 ayat (1) dan (3): CDN memproses berdasarkan perintah bank, dan pemrosesan itu tetap tanggung jawab bank.
• Pasal 51 ayat (5): CDN wajib mendapat persetujuan tertulis bank sebelum melibatkan prosesor lain.
• Pasal 51 ayat (6): pemrosesan di luar perintah bank menjadi tanggung jawab CDN.
• Pasal 52: kewajiban Pasal 36 (menjaga kerahasiaan) dan Pasal 39 (mencegah akses tidak sah) juga mengikat CDN.
• Pasal 37: bank wajib mengawasi setiap pihak dalam pemrosesan, termasuk CDN.

Pasal 74 memberi masa penyesuaian dua tahun sejak diundangkan, jadi menurut hitungan kami kewajiban ini berlaku penuh sejak 17 Oktober 2024. Pasal 34 ayat (2) menyebut "skala besar" (huruf c) dan "teknologi baru" (huruf f) sebagai pemicu penilaian dampak. CDN di depan kanal ritel bank menyentuh keduanya. Cara menyusunnya ada di DPIA Pasal 34 UU PDP untuk bank dan asuransi.

Siapa memegang kunci privat

Ada tiga model yang perlu ditanyakan ke vendor secara tertulis: sertifikat yang diterbitkan dan dikelola penyedia, sertifikat milik bank yang kuncinya diunggah ke penyedia, atau kunci yang tetap di infrastruktur bank. Model ketiga mengurangi risiko kunci bocor. Fakta dasarnya tidak berubah: setelah handshake, edge tetap melihat plaintext. Satu-satunya cara agar field tertentu tidak terbaca di edge adalah enkripsi per field; CloudFront menyebut fitur ini Field-Level Encryption.

Klausul kontrak yang sudah diwajibkan OJK

Penjelasan Pasal 29 ayat (1) POJK 11/POJK.03/2022 (ditetapkan 6 Juli 2022) menegaskan bank "tetap bertindak sebagai penyelenggara Sistem Elektronik" meski memakai penyedia jasa TI. CDN termasuk penyedia jasa TI itu. Pasal 30 ayat (3) mewajibkan kontraknya memuat, antara lain, komitmen menjaga kerahasiaan data nasabah (huruf b), mekanisme pelaporan kejadian kritis (huruf e), dan akses pemeriksaan bagi OJK (huruf i). Huruf d, persetujuan tertulis untuk subkontrak, sudah kami bahas di artikel SLA dan klausul OJK; ia sejalan dengan Pasal 51 ayat (5) UU PDP.

PoP CDN di Indonesia, dibaca 23 Oktober 2026

Tabel ini disusun dari halaman jaringan milik masing-masing penyedia, bukan dari pihak ketiga.

Fakta yang paling penting bagi DPO ada di Cloudflare. Regional Services (diperbarui 1 Juli 2026) membatasi pusat data mana yang boleh mendekripsi dan memeriksa trafik HTTPS. Region Asia yang tersedia adalah India, Jepang, Singapura, Korea Selatan, Hong Kong, dan Taiwan. Indonesia tidak ada di daftar itu; region kustom harus diatur lewat account team. Jadi, per tanggal ini, dekripsi Cloudflare tidak bisa dikunci ke Indonesia dari menu standar, padahal ada empat PoP di sini.

Google Cloud CDN menulis bahwa sumber daya cache-nya dibagi dinamis di seluruh jaringan edge global dan PoP yang aktif "can change without notice". Jakarta di daftar bukan jaminan nasabah Jakarta dilayani dari Jakarta. Untuk Akamai, ketiadaan daftar publik itu sendiri sudah temuan pengadaan: minta lokasi PoP dan lokasi dekripsi secara tertulis.

Kalau dekripsi terjadi di luar Indonesia

Respons yang sudah didekripsi dan disajikan dari PoP Singapura, menurut pembacaan kami, adalah transfer data pribadi ke luar negeri di bawah Pasal 56 UU PDP. Bank wajib memastikan negara penerima punya pelindungan setara atau lebih tinggi (ayat 2); jika tidak, pelindungan yang memadai dan mengikat (ayat 3); jika tidak juga, persetujuan nasabah (ayat 4). Ayat (5) menyerahkan detailnya ke Peraturan Pemerintah. Kami belum memastikan apakah PP itu sudah terbit, jadi periksa dulu sebelum mengandalkan salah satu jalur.

POJK 11 Pasal 35 ayat (1) mewajibkan Sistem Elektronik bank ditempatkan di pusat data di Indonesia, seperti dibahas di artikel cloud computing. Yang jarang dibaca adalah Penjelasan Pasal 35 ayat (3) huruf d: sistem front end untuk layanan global boleh, tapi back end "yang terakhir memproses data individu, akun, dan/atau transaksi nasabah, tetap ditempatkan di wilayah Indonesia." Ini satu-satunya tempat POJK 11 memisahkan front end dari back end, dan di situlah aturan praktis kami bertumpu: edge boleh membawa front end, tidak pernah sistem pencatat. Apakah PoP CDN termasuk "Pusat Data" menurut Pasal 1 angka 4 belum pernah diuji; POJK ini tidak menyebut CDN.

Untuk asuransi dan multifinance, Penjelasan Pasal 23 ayat (4) huruf d POJK 4/POJK.05/2021 (ditetapkan 9 Maret 2021) menarik garis yang sama. PADK OJK No. 1 Tahun 2026 (berlaku 1 Maret 2026) meminta penempatan di luar Indonesia tetap memastikan tiga hal: prinsip kerahasiaan, integritas, dan ketersediaan; jaminan kelangsungan usaha bank; dan efektivitas pengawasan OJK yang tidak berkurang.

WAF dan DDoS: apa yang ditutup, apa yang tidak

SEOJK 29/SEOJK.03/2022 (ditetapkan 27 Desember 2022) meminta pelindungan aplikasi web dengan WAF yang "berjalan di semua perangkat komputasi", dan mendefinisikan DDoS sebagai serangan terhadap ketersediaan. WAF dan penyerapan DDoS di CDN memenuhi sebagian kebutuhan itu, dengan dua batas:

• Origin yang terbuka melewati semuanya. Kalau IP origin bisa diakses langsung, penyerang tidak perlu lewat edge. Lampiran SEOJK yang sama meminta trafik cloud dibatasi ke "alamat IP yang dikenal oleh Bank". Di sini artinya origin hanya menerima rentang IP yang dipublikasikan CDN, idealnya ditambah autentikasi koneksi edge ke origin.
• WAF tidak menggantikan otorisasi. Request API yang meminta rekening nasabah lain dengan format yang sah tetap lolos WAF. Kontrol akses tetap tugas aplikasi; untuk API open banking, lihat bukti kepatuhan SNAP BI.

Ketersediaan: CDN juga titik gagal

CDN di jalur request adalah satu dependensi tambahan. Kalau CDN gagal, kanal mati walau origin sehat. Hitungannya sederhana: dua komponen berurutan masing-masing 99,9% menghasilkan 99,8% gabungan, atau sekitar 86 menit downtime per 30 hari, bukan 43 menit. Rumus dan tabel menitnya ada di artikel SLA.

• Origin failover melindungi dari origin yang mati, bukan CDN yang mati. CloudFront menyebutnya kemampuan bawaan untuk melayani dari origin cadangan.
• Multi-CDN melindungi dari CDN yang mati, dengan harga dua konfigurasi cache yang harus identik dan dua Prosesor di bawah Pasal 37 dan 51 UU PDP.
• stale-if-error (RFC 5861) hanya menyajikan salinan basi yang sudah tersimpan saat terjadi error. Menurut tabel di atas, dasbor dan API ber-no-store, jadi 0% trafik nasabah yang login tertolong. CDN bisa menjaga halaman promosi tetap tayang sementara login mobile banking mati.

Apakah CDN aman untuk bank?

Jawabannya bersyarat. Aman untuk aset statis dan halaman publik. Aman sebagai pass-through tanpa cache di depan kanal terautentikasi, untuk WAF dan DDoS, jika lima syarat terpenuhi: aturan bypass cache dikunci lewat change control, origin hanya menerima IP CDN, kontrak memuat Pasal 30 ayat (3) POJK 11, DPIA selesai, dan lokasi dekripsi diketahui tertulis. Tidak aman jika CDN menyimpan respons berisi data pribadi, atau mendekripsi di luar Indonesia tanpa dasar Pasal 56.

Empat anggapan keliru soal CDN di kanal bank

1. "CDN memperbarui keamanan TLS situs." CDN menghentikan TLS nasabah di edge lalu membuka koneksi kedua ke origin. Dua ruas terenkripsi (kalau koneksi ke origin juga TLS), plaintext di tengah.
2. "HTML itu statis." HTML bisa memuat nama dan saldo nasabah. Cloudflare pun tidak menyimpan HTML secara default.
3. "Konten dinamis tidak bisa di-cache." Salah ke dua arah. Respons personal bisa ter-cache karena salah konfigurasi, dan halaman publik yang sering berubah, seperti papan kurs, bisa di-cache beberapa detik dengan s-maxage.
4. "SLA 100%." Baca daftar pengecualiannya. Angka tanpa definisi pengukuran tidak bisa ditagih.

Untuk CTO dan CISO: urutan keputusan sebelum tanda tangan

1. Klasifikasikan setiap path ke lima kelas di tabel cache-policy, dan tulis header-nya di kode.
2. Kunci aturan cache di CDN untuk path API dan akun; perubahan lewat change request.
3. Minta vendor menyebut secara tertulis kota tempat TLS didekripsi untuk trafik Indonesia.
4. Putuskan model kunci privat dan apakah field tertentu perlu enkripsi per field.
5. Masukkan butir Pasal 30 ayat (3) POJK 11 dan Pasal 51 UU PDP ke kontrak, lalu jalankan DPIA.
6. Tutup origin ke rentang IP CDN, dan uji dari luar bahwa origin menolak request langsung.
7. Hitung ketersediaan gabungan CDN dan origin, lalu putuskan apakah multi-CDN sepadan dengan biaya pengawasannya.

Latar belakang soal skalabilitas origin ada di skalabilitas dengan solusi cloud native dan apa itu aplikasi cloud native. Kalau kanal Anda sedang dirancang ulang, tim kami mengerjakan pengembangan aplikasi cloud native dan pengembangan website untuk klien korporasi. Artikel ini disusun WEBARQ dengan bantuan AI; setiap pasal, RFC, dan halaman vendor yang dikutip dibaca langsung dari sumbernya, terakhir pada 23 Oktober 2026.