Insiden data yang dialami Fore Coffee kembali mengingatkan bahwa perlindungan data pelanggan tidak hanya bergantung pada kemampuan perusahaan mencegah unauthorized access. Ada pertanyaan lain yang sama pentingnya dari sisi architecture: ketika satu bagian dari environment berhasil diakses, seberapa jauh data di dalamnya dapat dijangkau?
Fore mengonfirmasi adanya akses tanpa izin terhadap salah satu platform yang digunakan untuk mengelola data pelanggan. Berdasarkan investigasi awal, kejadian tersebut berdampak pada data hingga sekitar 5,7 juta akun. Informasi yang berpotensi diakses berbeda untuk setiap pelanggan dan dapat mencakup nama, email, nomor telepon, tanggal lahir, jenis kelamin, alamat yang tersimpan di aplikasi, hashed PIN, serta riwayat pembelian.
Fore juga menjelaskan bahwa aplikasi mereka tidak menyimpan NIK maupun foto KTP. Informasi pembayaran, termasuk detail kartu kredit atau debit, berada pada platform terpisah dan tidak terdampak dalam kejadian tersebut. Perusahaan telah mengambil langkah pengamanan dan menunjuk konsultan keamanan siber untuk melanjutkan investigasi forensik.
Investigasinya masih berlangsung. Karena itu, informasi yang tersedia saat ini belum cukup untuk menyimpulkan root cause teknis atau menilai bagaimana keseluruhan data architecture Fore dirancang.
Namun bagi perusahaan lain, insiden seperti ini tetap relevan sebagai momentum untuk meninjau satu hal: bagaimana access boundary dibangun di dalam data environment mereka sendiri.
Authentication menjawab siapa yang boleh masuk. Setelah akses diberikan, data architecture menentukan apa yang dapat dilakukan oleh identity tersebut.
Seorang user mungkin hanya membutuhkan beberapa field untuk menjalankan pekerjaannya. Application service bisa hanya memerlukan satu kelompok data untuk menyelesaikan sebuah process. Analytics workload mungkin membutuhkan transaction history tanpa harus mengetahui identitas lengkap customer.
Dalam environment yang berkembang secara bertahap, access scope seperti ini tidak selalu tetap rapi. Permission lama bisa masih aktif, service account memperoleh akses tambahan dari project sebelumnya, atau sebuah dataset yang awalnya digunakan oleh satu fungsi kemudian dipakai lebih luas tanpa peninjauan kembali terhadap sensitivity-nya.
Masalahnya baru terlihat ketika account atau komponen tersebut mengalami compromise.
Inilah alasan konsep blast radius relevan dalam data architecture. Istilah ini menggambarkan seberapa luas dampak yang dapat menjalar dari satu titik yang bermasalah. Dalam konteks data, pertanyaannya menjadi: jika satu identity, application, atau platform tidak lagi dapat dipercaya, data apa saja yang dapat dijangkaunya?
Customer data sering dibicarakan seolah merupakan satu kumpulan informasi yang utuh. Dalam penggunaannya, masing-masing bagian sebenarnya memiliki fungsi yang berbeda.
Transaction history dapat digunakan untuk analytics. Identitas customer diperlukan untuk fungsi tertentu yang berhubungan langsung dengan pelanggan. Finance memiliki kebutuhan sendiri, begitu juga customer service, marketing, dan operational teams.
Karena kebutuhannya berbeda, access model-nya juga tidak harus sama.
Perusahaan dapat memisahkan data berdasarkan sensitivity dan penggunaan, kemudian memberikan akses sesuai role dan workload. Dengan cara ini, user yang membutuhkan sales performance untuk reporting tidak otomatis mendapatkan akses ke seluruh customer identity yang berada di belakang transaksi tersebut.
Prinsip ini dikenal sebagai least privilege: sebuah identity hanya memperoleh akses yang memang diperlukan untuk menjalankan fungsinya.
Pada data platform, penerapannya bisa lebih granular daripada sekadar permission pada database. AWS Lake Formation, misalnya, mendukung fine-grained access control pada resource di Data Catalog dan data di Amazon S3. Pada workload yang didukung, control dapat diterapkan hingga level row, column, atau cell.
Pendekatannya bukan membuat data sulit digunakan, melainkan menghindari pemberian access scope yang lebih luas dari kebutuhan sebenarnya.
Ada banyak kondisi di mana dua user membutuhkan dataset yang sama tetapi tidak membutuhkan informasi yang sama di dalamnya.
Seorang analyst mungkin perlu melihat purchase category, jumlah transaksi, waktu pembelian, dan customer segment. Nomor telepon atau alamat email lengkap belum tentu diperlukan untuk menghasilkan analisis tersebut.
Di sinilah column masking menjadi relevan.
Alih-alih menutup seluruh dataset, field sensitif dapat ditampilkan dalam bentuk yang sudah disamarkan bagi role tertentu. Pengguna yang memang memiliki authorization tetap dapat melihat nilai aslinya, sedangkan fungsi lain hanya menerima informasi yang cukup untuk menyelesaikan pekerjaannya.
Databricks Unity Catalog mendukung row filters dan column masks untuk membatasi row serta nilai column yang terlihat ketika query dijalankan. Untuk governance dalam skala yang lebih besar, policy juga dapat diterapkan berdasarkan governed tags melalui attribute-based access control.
Dengan pendekatan seperti ini, kebutuhan menggunakan data tidak selalu berarti kebutuhan melihat seluruh isi data.
Modern data environment jarang terdiri dari satu database yang berdiri sendiri. Data berpindah melalui pipeline, masuk ke analytical table, digunakan untuk dashboard, diproses kembali oleh application, atau menjadi input untuk machine learning dan AI workload.
Ketika incident terjadi, mengetahui source data saja belum cukup. Tim perlu memahami downstream dependency yang menggunakan data tersebut.
Misalnya satu table berisi customer information diketahui memerlukan pemeriksaan. Tanpa lineage, tim harus mencari satu per satu pipeline, table turunan, notebook, job, atau dashboard yang mungkin menggunakan informasi tersebut.
Data lineage membuat hubungan ini lebih terlihat.
Unity Catalog dapat merekam bagaimana data bergerak melalui query, file, table, job, notebook, pipeline, dan dashboard. Lineage juga dapat tersedia hingga column level pada workload yang didukung, sehingga tim dapat melihat bukan hanya table mana yang saling berhubungan tetapi juga bagaimana field tertentu digunakan di downstream asset.
Capability ini tidak hanya berguna saat terjadi security incident. Lineage juga membantu ketika perusahaan perlu melakukan impact analysis, menemukan sumber data quality issue, atau mengetahui di mana sensitive information digunakan setelah meninggalkan source system.
Saat melakukan investigation, mengetahui hubungan antar-data belum cukup. Tim juga membutuhkan informasi tentang aktivitas yang benar-benar terjadi.
Di sinilah audit log berperan.
Auditability memungkinkan perusahaan melihat siapa yang melakukan aktivitas tertentu, asset apa yang diakses, dan tindakan apa yang dilakukan di dalam platform. Ketika dikombinasikan dengan lineage, tim memiliki dua jenis konteks: bagaimana data seharusnya bergerak dan bagaimana environment tersebut benar-benar digunakan.
Unity Catalog menyediakan audit capability untuk melacak access dan action terhadap governed assets, selain fungsi access control, classification, dan lineage yang berada dalam governance layer yang sama.
Dalam praktiknya, visibility semacam ini dapat mempercepat proses ketika security atau data team harus menentukan area mana yang perlu diperiksa lebih dulu.
Dalam pernyataannya, Fore menyebut informasi pembayaran berada pada platform terpisah sehingga tidak terdampak oleh kejadian yang sedang diinvestigasi.
Kita tidak dapat menyimpulkan dari informasi tersebut bahwa data separation secara langsung membatasi incident, karena technical findings dari investigasi forensik belum dipublikasikan.
Namun konsepnya tetap penting bagi enterprise architecture.
Payment data, customer identity, analytical data, employee information, dan operational records memiliki risk profile yang berbeda. Menempatkan seluruh informasi tersebut di bawah access path yang sama dapat menciptakan exposure yang lebih besar ketika satu titik mengalami compromise.
Separation memungkinkan perusahaan merancang control yang berbeda sesuai karakter data, mulai dari siapa yang dapat mengaksesnya sampai bagaimana data diproses dan didistribusikan ke workload lainnya.
Banyak perusahaan sudah memiliki policy yang menjelaskan siapa yang seharusnya memiliki akses terhadap informasi tertentu. Tantangannya adalah memastikan aturan tersebut benar-benar tercermin pada platform yang digunakan sehari-hari.
Dalam modern data platform, governance biasanya melibatkan beberapa capability yang saling berhubungan:
Pada Databricks, capability seperti fine-grained access control, governed tags, classification, lineage, audit logging, dan data discovery dapat dikelola melalui Unity Catalog.
Dalam AWS environment, Lake Formation dapat menjadi bagian dari governance layer untuk mengelola permission terhadap data lake, sementara IAM dan control pada service lain tetap digunakan sesuai architecture yang dibangun. AWS sendiri merekomendasikan penggunaan fine-grained Lake Formation permissions ketika organisasi membutuhkan pembatasan akses yang lebih detail terhadap resource data.
Teknologinya tidak harus sama di setiap perusahaan. Yang penting, policy dapat diterjemahkan menjadi control yang benar-benar berjalan pada data platform.
Insiden seperti yang dialami Fore tidak berarti setiap perusahaan harus langsung mengganti data platform atau menambah tool keamanan baru.
Review yang lebih berguna justru dimulai dari environment yang sudah ada.
Pertama, perusahaan perlu mengetahui siapa dan apa yang saat ini memiliki akses ke sensitive data. Scope ini sebaiknya mencakup human user, service account, application, integration, serta automated workload.
Setelah itu, periksa apakah permission yang diberikan masih sesuai dengan fungsi sebenarnya. User yang berpindah role, project yang sudah berakhir, atau integration lama sering menjadi alasan access scope tumbuh tanpa disadari.
Dataset dengan personal information juga dapat diperiksa kembali untuk mengetahui apakah seluruh field memang perlu tersedia bagi setiap consumer. Untuk beberapa workload, masking atau analytical dataset yang sudah dipisahkan mungkin sudah cukup.
Terakhir, perusahaan perlu melihat seberapa mudah mereka dapat menjawab pertanyaan tentang aliran data dan aktivitas pengguna. Jika mengetahui downstream dependency atau access history masih membutuhkan pencarian manual dari banyak system, governance visibility-nya masih dapat diperkuat.
Security architecture tidak bisa dibangun dengan asumsi seluruh preventive control akan selalu berhasil.
Credential bisa disalahgunakan. Vulnerability baru dapat ditemukan. Application dan third-party component akan terus berubah.
Karena itu, pertanyaan yang perlu dipikirkan bukan hanya bagaimana mencegah unauthorized access, tetapi juga bagaimana environment bereaksi jika salah satu control gagal.
Least privilege membatasi permission yang tersedia. Data separation memperkecil area yang dapat dijangkau dari satu access path. Masking mengurangi exposure terhadap field sensitif, sementara lineage dan auditability membantu tim memahami dampaknya ketika investigation harus dilakukan.
Tidak ada satu control yang menghilangkan seluruh risiko. Nilainya muncul ketika beberapa layer tersebut dirancang sebagai bagian dari architecture yang sama.
Investigasi atas insiden data Fore masih berjalan, sehingga pembahasan mengenai technical root cause sebaiknya menunggu hasil yang sudah terverifikasi. Fore sendiri menyatakan telah menunjuk konsultan keamanan siber untuk melakukan investigasi lebih lanjut terhadap aplikasi, platform terkait, dan system teknologi informasi lain yang relevan.
Bagi perusahaan lain, tidak perlu menunggu incident untuk melakukan exercise yang sama terhadap environment sendiri.
Ambil satu application atau service account yang memiliki akses ke customer data. Lihat permission yang dimilikinya, data domain yang bisa dijangkau, downstream workload yang mengonsumsi data tersebut, dan informasi apa yang tersedia jika aktivitasnya perlu ditelusuri.
Dari sana, pembicaraan mengenai data governance menjadi jauh lebih konkret. Perusahaan dapat melihat apakah access boundary masih sesuai, sensitive fields perlu dipisahkan atau dimasking, lineage cukup lengkap, dan area mana yang paling membutuhkan perbaikan.
Melalui Data Platform & Engineering, ICS Compute membantu enterprise meninjau serta membangun data architecture di AWS dan Databricks dengan governance yang mengikuti bagaimana data benar-benar digunakan. Scope dapat mencakup data platform assessment, access model, catalog dan ownership, lineage, masking, serta governance control sesuai kebutuhan dan risk profile environment perusahaan.
Insiden data dapat datang dari berbagai jalur. Data architecture membantu menentukan seberapa jauh satu jalur tersebut dapat mencapai environment yang lebih luas.