Ketika sebuah transaksi gagal, tim teknologi ingin mengetahui penyebabnya secepat mungkin. Log diperiksa, trace ditelusuri, metrik dibandingkan, lalu perjalanan request dilihat dari satu layanan ke layanan lainnya. Dalam hitungan menit, titik masalah dapat ditemukan tanpa harus menebak-nebak apa yang terjadi di dalam sistem.

Observability memberikan kemampuan tersebut. Namun, ada konsekuensi yang sering luput dari perhatian: agar sistem semakin mudah diamati, semakin banyak pula informasi yang dikumpulkan.

Pada awalnya mungkin hanya timestamp, status request, dan durasi proses. Kemudian ditambahkan user ID, parameter API, alamat IP, error message, request body, hingga atribut transaksi untuk membantu investigasi.

Semakin lengkap datanya, semakin mudah masalah ditelusuri.

Namun, pada titik tertentu, telemetry tidak lagi sekadar menjelaskan kondisi sistem. Ia dapat mulai membawa data yang seharusnya tidak berada di sana.

Di sinilah muncul paradoks baru dalam observability security. Sistem memang semakin terlihat, tetapi pada saat yang sama perusahaan dapat menciptakan lokasi baru tempat data sensitif disimpan.

Masalahnya Bukan Observability, tetapi Keinginan untuk Merekam Segalanya

Ada alasan yang sangat masuk akal mengapa tim engineering menyukai telemetry yang detail.

Ketika suatu aplikasi mengalami masalah, konteks sangat penting. Log yang terlalu sederhana sering kali hanya menunjukkan bahwa sebuah proses gagal tanpa menjelaskan penyebabnya. Karena itu, developer menambahkan lebih banyak informasi agar debugging menjadi lebih cepat.

Distributed tracing juga mendorong pola serupa. Semakin banyak atribut yang disertakan pada sebuah span, semakin mudah perjalanan request ditelusuri.

Masalah muncul ketika pola tersebut berubah menjadi pendekatan collect everything first, investigate later.

Setiap field tambahan berarti ada data tambahan yang harus dikirim, diproses, disimpan, direplikasi, dan diberikan akses kepada pihak tertentu.

Panduan Open Telemetry sendiri menekankan prinsip data minimization dalam pengumpulan telemetry. Data seharusnya dikumpulkan karena memiliki tujuan observability yang jelas, bukan hanya karena secara teknis dapat direkam.

Prinsip ini penting karena kemampuan mengumpulkan data tidak selalu sama dengan kebutuhan untuk menyimpannya.

Data Sensitif Sering Masuk Telemetry Tanpa Disengaja

Kebocoran melalui telemetry tidak selalu terjadi karena seseorang sengaja mencatat informasi rahasia. Dalam banyak kasus, data sensitif masuk sebagai efek samping dari proses debugging atau instrumentation.

Sebuah developer mungkin menambahkan request payload agar error lebih mudah dianalisis. Namun, payload tersebut dapat membawa nama pelanggan, alamat email, nomor telepon, alamat, atau informasi transaksi.

Hal serupa dapat terjadi pada proses autentikasi.

Authorization header, access token, cookie, session identifier, dan parameter tertentu dapat ikut tercatat ketika logging dibuat terlalu detail.

OWASP secara konsisten menyarankan agar informasi seperti password, access token, session identifier, encryption key, dan data pribadi sensitif tidak dicatat secara langsung di dalam log.

Persoalannya menjadi lebih rumit karena telemetry modern tidak hanya berbentuk log.

Trace dapat memiliki attributes. Error monitoring dapat menyimpan context. Application performance monitoring dapat mencatat URL, query parameter, user identifier, atau metadata request.

Dengan kata lain, sensitive data dalam telemetry dapat muncul di berbagai tempat yang sebelumnya tidak dianggap sebagai penyimpanan data.

Satu Data Kini Dapat Memiliki Perjalanan Kedua

Dalam arsitektur aplikasi tradisional, aliran data relatif mudah dibayangkan.

Pengguna mengirimkan informasi ke aplikasi. Aplikasi memprosesnya. Data kemudian disimpan pada database atau sistem lain yang memang dirancang untuk menangani informasi tersebut.

Observability menciptakan jalur tambahan.

Sebuah aplikasi dapat mengirim telemetry ke agent atau collector. Dari sana, data diteruskan melalui telemetry pipeline menuju platform monitoring, dashboard, storage, atau layanan pihak ketiga.

Artinya, sebagian informasi aplikasi memiliki perjalanan kedua.

Data yang sebelumnya hanya bergerak melalui:

Pengguna → Aplikasi → Database

dapat berubah menjadi:

Pengguna → Aplikasi → Collector → Telemetry Pipeline → Observability Platform → Dashboard → Archive

Setiap titik baru dalam perjalanan tersebut menambah lokasi yang perlu diamankan.

Ini bukan alasan untuk menghindari observability. Justru sebaliknya, observability sangat penting dalam pengoperasian sistem modern. Namun, perusahaan perlu memahami bahwa telemetry merupakan bagian dari data security architecture, bukan sekadar alat bantu developer.

Risiko Bisa Berpindah dari Database ke Dashboard Monitoring

Perusahaan biasanya memiliki perhatian besar terhadap database production.

Hak akses dibatasi. Koneksi dienkripsi. Infrastruktur dipisahkan. Aktivitas administrator diaudit. Backup dikelola secara khusus.

Tetapi perlindungan yang sama belum tentu diterapkan pada platform observability.

Siapa saja yang dapat mencari log production?

Apakah seluruh developer memiliki akses ke seluruh telemetry?

Apakah administrator dapat mengekspor data?

Apakah dashboard digunakan bersama oleh beberapa tim?

Apakah telemetry dikirim ke layanan pihak ketiga?

Pertanyaan tersebut menjadi semakin penting ketika log atau trace mengandung informasi pelanggan.

Sebuah perusahaan dapat memiliki database yang sangat terlindungi, tetapi tetap memiliki risiko apabila sebagian datanya muncul kembali pada platform monitoring dengan kontrol akses yang lebih longgar.

Pada kondisi seperti ini, attack surface tidak lagi berhenti pada aplikasi dan database.

Platform observability juga menjadi aset yang perlu diperlakukan sebagai bagian dari sistem kritis perusahaan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Fokus keamanan sering diarahkan pada endpoint aplikasi, server, API, dan database. Padahal, komponen pendukung seperti sistem logging, dashboard monitoring, integrasi telemetry, serta hak akses engineer juga dapat menentukan seberapa luas dampak sebuah insiden.

Retention Membuat Kesalahan Kecil Bertahan Jauh Lebih Lama

Ada perbedaan penting antara data yang muncul sesaat di aplikasi dan data yang tersimpan dalam telemetry.

Bayangkan sebuah perubahan kode secara tidak sengaja menyebabkan access token masuk ke log selama beberapa menit.

Developer kemudian menemukan kesalahan tersebut dan memperbaikinya.

Masalah pada aplikasi mungkin sudah selesai.

Namun, apakah token yang sebelumnya tercatat juga langsung hilang?

Belum tentu.

Jika log memiliki retention selama 30, 60, atau 90 hari, data tersebut dapat tetap berada di platform observability jauh setelah sumber masalahnya diperbaiki.

Microsoft bahkan memperlakukan Azure Monitor Logs sebagai tempat di mana data pribadi berpotensi tersimpan dan menyediakan mekanisme khusus untuk pengelolaannya.

Hal ini menunjukkan bahwa retention bukan sekadar persoalan kapasitas penyimpanan.

Retention juga merupakan bagian dari keamanan data.

Semakin lama telemetry disimpan, semakin panjang pula periode exposure ketika data sensitif telanjur masuk ke dalamnya.

Semakin Banyak Telemetry Tidak Selalu Berarti Sistem Semakin Mudah Dipahami

Ada anggapan bahwa observability yang baik berarti mengumpulkan data sebanyak mungkin.

Dalam praktiknya, situasinya tidak sesederhana itu.

Volume telemetry yang terlalu besar dapat menciptakan noise. Tim harus mencari informasi penting di antara jutaan event yang sebenarnya tidak relevan.

Biaya ingestion meningkat. Storage bertambah. Query menjadi lebih kompleks. Alert dapat muncul terlalu banyak.

Pada akhirnya, perusahaan dapat memiliki sangat banyak data tanpa benar-benar memiliki informasi yang membantu pengambilan keputusan.

Observability yang matang bukan diukur dari banyaknya data yang dikumpulkan, tetapi dari kemampuan organisasi memperoleh signal yang tepat ketika dibutuhkan.

Karena itu, pertanyaannya seharusnya bukan:

“Data apa saja yang bisa kita log?”

Melainkan:

“Informasi apa yang benar-benar dibutuhkan untuk mendeteksi dan menganalisis masalah?”

Perubahan pertanyaan ini terlihat sederhana, tetapi dampaknya besar terhadap desain telemetry.

Data Minimization Harus Dimulai Sejak Desain Observability

Pengamanan telemetry yang paling efektif bukan selalu menghapus informasi sensitif setelah data masuk ke sistem monitoring.

Pendekatan yang lebih kuat adalah mengurangi kemungkinan informasi tersebut dikumpulkan sejak awal.

Setiap atribut telemetry sebaiknya memiliki alasan.

Apakah user email benar-benar dibutuhkan untuk mencari penyebab kegagalan transaksi?

Apakah request body harus disimpan secara penuh?

Apakah customer identifier dapat diganti dengan internal reference ID?

Apakah session identifier perlu dicatat, atau cukup menggunakan nilai yang telah di-hash untuk korelasi?

Prinsipnya sederhana:

kumpulkan informasi yang diperlukan untuk observability, bukan seluruh informasi yang tersedia dari aplikasi.

Dengan pendekatan tersebut, telemetry tetap berguna tanpa berubah menjadi salinan tersembunyi dari database utama.

Masking dan Redaction Sebaiknya Dilakukan Sebelum Penyimpanan

Tidak semua sensitive data dapat dicegah dari sisi aplikasi.

Framework, instrumentation library, SDK, atau komponen pihak ketiga dapat menghasilkan telemetry secara otomatis.

Karena itu, perlindungan juga perlu diterapkan pada telemetry pipeline.

Salah satu arsitektur yang lebih aman adalah:

Application → Collector → Filter/Redaction → Observability Platform

Pada lapisan tersebut, organisasi dapat melakukan filtering terhadap atribut tertentu sebelum telemetry masuk ke storage.

Beberapa pendekatan yang dapat digunakan meliputi data masking, hashing, penghapusan attribute, allowlist, filtering, dan transformation.

OpenTelemetry Collector, misalnya, menyediakan mekanisme untuk menghapus, memfilter, mengubah, atau melakukan redaction terhadap attributes.

Pendekatan seperti ini membantu perusahaan membuat batas yang lebih jelas antara data yang dibutuhkan untuk observability dan data yang tidak seharusnya meninggalkan aplikasi.

Hak Akses Telemetry Tidak Seharusnya Diberikan Secara Merata

Platform observability sering diperlakukan sebagai alat engineering. Akibatnya, akses terkadang diberikan cukup luas agar pekerjaan tim lebih mudah.

Padahal, apabila telemetry membawa informasi operasional atau data pengguna, dashboard tersebut seharusnya mengikuti prinsip keamanan yang sama seperti sistem lainnya.

Penerapan least privilege menjadi penting.

Developer yang menangani satu layanan belum tentu membutuhkan akses terhadap telemetry seluruh aplikasi. Tim non-production juga tidak selalu membutuhkan akses ke log production.

Selain Role-Based Access Control, organisasi dapat mempertimbangkan MFA, audit akses, pemisahan environment, pembatasan export, serta pengendalian terhadap API platform observability.

Tujuannya bukan menghambat developer, tetapi memastikan bahwa akses terhadap telemetry sesuai dengan kebutuhan pekerjaan.

Observability Juga Memerlukan Security Review

Security assessment sering berfokus pada aplikasi yang terlihat langsung oleh pengguna.

Web application diuji. API diperiksa. Infrastruktur dievaluasi. Authentication dan authorization dianalisis.

Namun, arsitektur modern memiliki lebih banyak komponen.

Telemetry collector, monitoring dashboard, logging server, storage, integration API, secrets, retention configuration, dan access control juga dapat menjadi bagian dari risiko.

Karena itu, ketika melakukan security review atau penetration testing, organisasi sebaiknya tidak hanya bertanya apakah aplikasi dapat dieksploitasi.

Pertanyaan yang lebih luas adalah:

Jika suatu komponen berhasil diakses oleh pihak yang tidak berwenang, data apa yang dapat ditemukan dari telemetry yang tersedia?

Pendekatan seperti ini mengubah observability dari sekadar urusan operasi menjadi bagian dari Secure SDLC dan pengelolaan keamanan aplikasi.

Pertanyaan yang Lebih Penting Bukan Lagi “Apakah Sistem Kita Observable?”

Observability telah menjadi bagian penting dari aplikasi modern. Tanpanya, mendeteksi masalah, memahami kegagalan, dan menelusuri perjalanan request dapat menjadi jauh lebih sulit.

Namun, kemampuan melihat sistem secara detail perlu disertai disiplin mengenai data yang digunakan untuk menciptakan visibilitas tersebut.

Perusahaan perlu mulai mengajukan pertanyaan yang berbeda:

Data apa yang sebenarnya sedang direkam?

Apakah seluruh attributes tersebut benar-benar dibutuhkan?

Apakah ada PII, credentials, token, atau informasi bisnis sensitif di dalam telemetry?

Siapa yang memiliki akses?

Berapa lama data disimpan?

Ke mana telemetry dikirim?

Apa yang terjadi jika platform observability tersebut berhasil diakses oleh pihak yang tidak berwenang?

Observability yang baik tidak berarti mencatat segala sesuatu.

Observability yang baik adalah kemampuan mendapatkan konteks yang dibutuhkan untuk memahami sistem dengan tetap membatasi data, akses, serta risiko yang tercipta di sepanjang proses tersebut.

Sebab pada akhirnya, telemetry yang membantu perusahaan menemukan sebuah insiden seharusnya tidak menjadi sumber insiden berikutnya.

Pastikan Observability Tidak Memperluas Risiko Keamanan Sistem Anda

Implementasi observability perlu berjalan bersama dengan pengamanan aplikasi, API, infrastruktur, serta proses pengembangan yang tepat. Pengujian keamanan dapat membantu perusahaan mengidentifikasi apakah telemetry, logging mechanism, access control, maupun komponen pendukung aplikasi membuka jalur risiko yang sebelumnya tidak terlihat.

Fourtrezz dapat membantu perusahaan melakukan evaluasi keamanan melalui Vulnerability Assessment dan Penetration Testing, termasuk metode blackbox maupun greybox. Fourtrezz juga menyediakan layanan IT Development dengan pendekatan Secure by Design untuk pengembangan sistem internal, integrasi API, dashboard, serta solusi aplikasi bisnis yang mempertimbangkan keamanan sejak tahap perancangan.

Jika perusahaan Anda ingin memastikan bahwa sistem tidak hanya memiliki visibilitas yang baik, tetapi juga memiliki perlindungan yang memadai terhadap risiko keamanan, diskusikan kebutuhan tersebut bersama Fourtrezz.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]