Blog

Blog APTIKA DISKOMINFOSP KUTIM

Audit Mandiri Keamanan Aplikasi Informatika sebagai Penyelesaian Strategis

Kamis, 21 Agustus 2025 02:39 siang
Ami Arief
Artikel
Views 120

Revolusi digital telah mengubah lanskap bisnis, pemerintahan, dan kehidupan sosial secara fundamental. Layanan hosting yang kredibel dan SaaS/PaaS kini menjadi infrastruktur utama dalam operasional sejumlah organisasi. Namun di tengah kemajuan ini, tantangan terkait keamanan, efisiensi dan tata kelola sistem kian kompleks. Audit mandiri keamanan aplikasi informatika muncul sebagai solusi strategis untuk memastikan bahwa aplikasi yang diselenggarakan dapat diukur kapasitas penyelenggaraannya dan memungkinkan untuk dapat dilakukan perbaikan/peningkatan guna mendukung tugas dan fungsi organisasi.

 

Definisi Audit Mandiri Aplikasi Informatika

Audit mandiri aplikasi informatika adalah proses pengecekan, penilaian dan verifikasi yang dilakukan secara internal terhadap perangkat lunak dan sistem digital yang diselenggarakan organisasi tanpa melibatkan auditor eksternal.
 

Perlunya Audit Mandiri Aplikasi Informatika

  • Mekanisme audit yang dapat diterapkan secara mikro/individu adalah penting. Faktor permasalahan terbesar berdasarkan pengalaman penangan aplikasi yakni faktor kontrol akses dan faktor kematangan layanan hosting. Bukan malware. Bila aplikasi terserang malware, dalam kondisi ada scan malware dan ada kontrol akses pengadministrasian sistem operasi, maka PTTI dapat melakukan tracing. Namun bilamana aplikasi dilepas begitu saja, maka ketika terjadi insiden, pengelola teknis masing-masing aplikasi akan dituntut pertanggungjawaban dalam keadaan tidak ada kontrol akses kepada aplikasi. Kontrol akses ini ada kaitannya dengan tingkat kematangan layanan hosting. Pada hosting yang telah kredibel, akan sangat memperhatikan privilege atas tiap-tiap pengelola aplikasi. Kontrol akses atas layanan SaaS tidak hanya langsung kepada akses VPS, melainkan ada manajemen risiko yang diimplementasi melalui laman dashboard dari user tenant. Ini hal yang penting dan krusial yang menjadikan audit aplikasi bukan hanya seremonial formal pemerintahan, tapi tentang survival. Sehingga penting untuk merumuskan mekanisme dan item audit yang sederhana dan fleksibel, dapat diimplementasi secara mikro/individu, berorientasi kepada teknis operasi aplikasi dan kontrol akses masing-masing pengelola teknis aplikasi.
  • VUCA.
  • Banyak jenis audit pemerintah, namun sebagian terlalu luas, kurang menyentuh pangkal permasalahan penyelenggaraan/operasi/kesinambungan aplikasi.
  • Keterhubungan audit mandiri aplikasi informatika dengan regulasi pemerintah. Audit dengan regulasi pemerintah secara taktis (semisal audit SPBE/BRIN audit tools, Indeks-KAMI, dsb) sifatnya ekstensif. Regulasi-regulasi itu telah dicoba untuk diterapkan, dan dijumpai sejumlah permasalahan-permasalahan strategis dan bermetamorfosis menjadi best practice. Best practice atas hal yang tidak dapat dijangkau oleh penerapan regulasi secara taktis menjurus kepada suatu mekanisme audit mandiri dalam konteks DevOps (lebih parsial). Beririsan namun tidak menggantikan proses audit secara keseluruhan. Audit mandiri yang dilakukan dengan baik akan membantu penguasaan materi atas audit aplikasi lainnya, serta mengkondisikan PTTI memiliki budaya dan karakter yang lebih memiliki kontrol akses dalam melakukan pengelolaan aplikasinya masing-masing.
 

Tahapan Audit Mandiri

Audit mandiri aplikasi informatika terdiri dari beberapa tahapan utama:
  • Inventaris PTTI. Perlu memastikan pengelola teknis teknologi informasi (aplikasi) yang hendak diaudit merupakan entitas konkret, bukan entitas yang tidak dapat diidentifikasi, bukan pula entitas anonim yang perbuatannya tidak dapat dimintai pertanggungjawaban. Lumrahnya, tahap ini tahap yang paling berat diimplementasi. Dilematis yang lumrah dijumpai di dunia nyata yakni adanya organisasi, namun tidak ada kejelasan pengelola aplikasi. Banyak manusia, tidak banyak kapasitas DevOps-nya, motif regulasi pemerintah itu sendirilah yang mengangkat dan mengkondisikan aktor pemerintah ke kursi jabatan dengan karakter hanya pintar belanja namun tidak pintar kerja/kerja sama. Seketika pengelola aplikasi ada keterangan, begitu dicek kompetensi, tidak dapat melakukan maintenance aplikasi atau melakukan pengembangan berkelanjutan. Sekali mampu, bukan Tusinya. Begitu permasalahan di bawa ke struktural terkait, strukturalnya itu sendiri yang justru minim kompetensi manajerial/MPPL dan kompetensi teknis sehingga tidak ada atau minim pengetahuan teknis yang publikasi ke media pembelajaran untuk dibagikan dan dipelajari bawahan atau stakeholder terkait. Ini tentu saja polemik yang cepat atau lambat perlu masuk antrian penyelesaian. Maka mencari jalan tengah dalam bentuk solusi sementara yang legal dan transparan untuk perkara ini memang memerlukan kesabaran, pendalaman yang cukup pada masing-masing Bidang/Bagian/Sub Bagian, pencarian kesesuaian terbaik antara kriteria PTTI ideal dengan kondisi faktual dan aktual masing-masing personal. Rapat bersama mungkin diperlukan untuk konfirmasi keberatan atau penerimaan keputusan penentuan dan penetapan PTTI per Bidang/Bagian/Sub Bagian. Dari sisi rasionalitas, PTTI sudah tidak logis jika dibatasi maksimal 1 per OPD, karena secara faktual, Tusi antar Bidang/Bagian/Sub Bagian, berbeda. Itu berarti akan ada Probis yang berbeda. Probis berbeda, berarti aplikasi yang berbeda. Jika aplikasi tidak beda, maka sekurang-kurangnya modularnya yang berbeda, yang mana itu berarti source code yang berbeda dan perlu PTTI spesialis di setiap Probisnya yang berbeda. Batas jumlah PTTI akan menjadi relevan jika dibatasi minimal 1 per Bidang/Bagian/Sub Bagian dengan konsentrasi Probis yang berbeda-beda. Ditetapkan dalam SK yang dapat diakses melalui layanan pemerintah untuk kejelasan dan transparansi. Bilamana tidak ada transparansi, ini justru akan membawa dampak negatif berantai dan pertumbuhan VUCA yang tidak dapat secara signifikan diukur. Inventaris PTTI dan akses dokumen dengan mekanisme yang jelas akan memangkas segala risiko VUCA itu.
  • Inventaris aplikasi. Setelah PTTI dapat dipastikan merupakan aktor konkret, maka perlu untuk memastikan aplikasi yang diaudit juga konkret.
  • Inventaris item audit. Setelah tersedia aktor dan aplikasinya, maka perlu untuk menentukan ingin menggunakan framework audit yang mana. Item audit ada banyak jenis, tergantung regulasi perangkat pemerintah mana yang digunakan. Namun dalam konteks item audit terlampir, item audit yang dirumuskan dibatasi hanya pada hal yang signifikan dalam konteks penyelenggaraan/operasi aplikasi. Item audit keamanan aplikasi dibedakan dalam konteks kritikal dan sekunder. Kritikal berisi muatan item audit yang (relatif) kritis bilamana diabaikan dalam implementasi penyelenggaraan aplikasi. Sekunder berisi muatan item audit yang dapat berdampak positif terhadap keamanan penyelenggaraan aplikasi, namun tidak kritis bilamana ditinggalkan. Baik kritikal maupun sekunder dalam artikel ini tidak ditentukan wajib atau tidak wajibnya, disebabkan kondisi dan budaya digital suatu perangkat atau unit pemerintah akan berpengaruh terhadap dampak berantai penyelenggaraan aplikasi yang mana dapat disebabkan dari keputusan dan atau tindakan yang mengacu kepada optimalisasi nilai audit bila ditetapkan wajib. Semisal, budaya digital untuk pemutakhiran atau penanganan data pada suatu sistem informasi masih tidak independen dilakukan masing-masing pengguna (masih ‘dijokikan’) apakah secara parsial atau ekstensif, maka pemberlakuan status wajib untuk item audit 2FA hanya akan menambah permasalahan penanganan data, karena 2FA membuat proses penanganan yang semula ditangani orang yang bisa menangani, menjadi ditangani orang yang punya akun, yang mana orang yang punya akun, belum tentu memiliki kualifikasi, kompetensi atau persistensi disiplin dalam pemutakhiran data. Sehingga pada perangkat atau unit pemerintah dengan budaya digital seperti ini, item audit menjadi bernilai jika hanya diposisikan sebagai kerangka kerja audit, alat audit, cakupan wawasan dalam konteks audit, namun menjadi berbahaya atau merisikokan jika ditetapkan wajib untuk digeneralisir atas segala situasi kondisi perangkat atau unit kerja yang ada (seluruhnya).
  • Pemeriksaan teknis. Melakukan pemeriksaan objektif berdasarkan item audit. Memastikan bahwa aplikasi dapat diukur kapasitas penyelenggaraannya dalam memenuhi item audit. Dari sana terdapat informasi yang dapat membantu proses evaluasi.
  • Evaluasi. Evaluasi dilakukan berdasarkan hasil pemeriksaan teknis. Dari hasil pengukuran, dapat dipantau hasil audit per item, apakah hasil pada item tersebut baik (perlu dipertahankan/ditingkatkan) atau belum (perlu perbaikan).
  • Pembuatan laporan audit. Mendokumentasikan hasil audit, rekomendasi perbaikan/peningkatan, dan langkah tindak lanjut yang diperlukan.
  • Monitoring dan tindak lanjut. Melakukan pemantauan terhadap pelaksanaan rekomendasi serta peninjauan berkala untuk memastikan perbaikan telah diterapkan.
 

Kesimpulan

Audit mandiri aplikasi informatika bukan prosesi seremoni audit SPBE melainkan pendekatan survival untuk digitalisasi atau penyelenggaraan SaaS/PaaS yang berdaulat dan berkesinambungan dengan syarat daya dalam bentuk kompetensi (Pegawai Pemerintah) yang terdistribusi (terdapat pada tiap-tiap Bidang/Bagian/Sub Bagian) dengan bekal kontrol akses menuju media operasi layanan pemerintahan. Mekanisme audit mandiri yang relevan untuk diimplementasi secara individu (PTTI) merupakan solusi strategis dalam menghadapi tantangan era disrupsi. Audit mandiri bukan hanya alat verifikasi, tapi juga katalisator perbaikan/peningkatan tata kelola digital. Melalui audit mandiri, organisasi dapat membangun ketahanan digital secara bertahap, menumbuhkan kemandirian dan siap beradaptasi dengan perubahan zaman yang terus berlangsung secara langsung dan transparan tanpa mensyaratkan panjangnya proses birokrasi.
 

FAQ

1. Apa bedanya audit mandiri dengan audit eksternal SPBE/BRIN?
Audit mandiri Kabupaten/Kota dilakukan pada tingkat Kabupaten/Kota melalui leading sector-nya secara berkala, bersifat reflektif dan operasional, sementara audit eksternal biasanya bersifat formal, periodik, dan terfokus pada kepatuhan terhadap regulasi nasional. Audit mandiri juga dapat beragam tergantung konteksnya. Audit mandiri untuk tauval SPBE/Pemdi daerah merupakan self assessment tingkat pemerintah daerah dengan rangka sejumlah indikator SPBE/Pemdi. Audit mandiri keamanan aplikasi dalam konteks artikel ini merupakan self assessment dengan target seminim mungkin atau tidak adanya proses birokrasi yang perlu dilakukan (sama sekali) hanya untuk melakukan pengukuran capaian keamanan aplikasi berdasarkan standar (kritikal/sekunder) dan dapat dilakukan secara internal/seorang diri (oleh masing-masing pengelola aplikasi) dengan proyeksi tidak adanya ketergantungan terhadap kompetensi dari stakeholder ilegal atau hal yang menimbulkan polemik semisal black hat hacker, gray hat hacker dan ketidakjelasan birokrasi serta SOP belanja anggaran jasa white hat hacker dari individu untuk urusan pemerintahan. Memungkinkan PTTI untuk melakukan audit mandiri kapanpun. Analogi audit mandiri dengan audit eksternal yakni seperti ASI terhadap bayi jika tidak ada kerangka audit yang jelas, itu merupakan suatu kebutuhan fundamental selama periode tertentu. Anologi lainnya yakni seperti multivitamin untuk orang dewasa jika telah ada kerangka yang jelas namun daya yang kurang, itu bisa jadi bermanfaat, namun bukan hal yang utama. Hal yang lebih utama adalah meningkatkan stamina dan daya tahan secara natural dengan latihan kebugaran dan gaya hidup sehat (melakukan serangkaian kegiatan kerja dan melatih diri melalui serangkaian pembelajaran mandiri).

2. Apakah kami punya kapasitas SDM untuk melakukan audit mandiri?
Bilamana konteksnya hanya sebatas audit mandiri (untuk aplikasi sendiri dan tidak ada perbaikan/peningkatan yang harus dilakukan), maka audit mandiri tidak menuntut keahlian teknis tingkat lanjut. Panduan dan template yang telah disediakan dapat membantu praktisi melakukan evaluasi yang fundamental. Bilamana konteks audit adalah untuk perbaikan/peningkatan sistem atau melakukan audit untuk pihak lain, maka kemampuan development & operations (DevOps) dasar diperlukan untuk memastikan arahan yang diberikan bukan teori semata namun memang benar dapat diterapkan, bisa jadi kemampuan pemanfaatan kecerdasa buatan (semisal Chatbot AI) juga diperlukan. Adapun opsi belanja jasa untuk kesinambungan penyelenggaraan aplikasi hanya menjadi opsi yang relevan jika tiap-tiap individu pemerintah ada dalam Business Process Modeling and Notation (BPMN)/SOP belanja (barang dan jasa), kurang dari itu maka sebenarnya proses belanja tidak berjalan di atas dasar atau berdasar namun dasar yang tidak adil (tidak inklusif) sebab hanya mengakomodir hajat atau keperluan dari stakeholder tertentu, bukan tiap-tiap individu yang perlu belanja untuk urusam pemerintahan, sehingga ketidak adilan tentu bukan hal yang pantas untuk digeneralisir (dilumrahkan/dibudayakan), apalagi dijadikan objek ketergantungan dalam konteks audit keamanan aplikasi.

3. Bagaimana cara memulai audit mandiri tanpa menambah beban kerja?
Masukkan audit ke dalam RHK SKP awal tahun, jika RHK SKP awal tahun telah clear-fixed tidak dapat ditambah, maka dapat masukkan audit mandiri pada kinerja tambahan/kegiatan penunjang yang telah dibuat pada SKP di awal tahun.

4. Apakah audit mandiri akan menggantikan audit resmi dari instansi pusat?
Esktensifitas Audit Mandiri Tauval SPBE/Pemdi dapat dipastikan tidak akan/tidak akan pernah dapat digantikan parsialitas audit mandiri keamanan aplikasi, bahkan audit keamanan aplikasi dengan standar manajemen keamanan informasi/Indeks Keamanan Informasi (I-KAMI) sekalipun belum terpenuhi seluruhnya dengan item audit mandiri keamanan aplikasi pada artikel ini. Audit mandiri keamanan aplikasi pada artikel ini hanya jalur cepat PTTI untuk pengukuran keamanan aplikasi yang sedang dikelola berdasarkan best practice, sifatnya melengkapi dan memperkuat kesiapan internal sebelum menghadapi audit eksternal. Ini juga membantu mengidentifikasi masalah fundamental yang sering luput dari audit formal.

5. Apa risiko jika kami tidak melakukan audit mandiri keamanan aplikasi dengan standarisasi yang terdapat pada artikel ini?
Jika anda telah menerapkan standar security check pada artikel sebelumnya, maka seharusnya tidak ada risiko besar yang muncul, hanya saja potensi dampak negatifnya akan lebih besar jika dibandingkan dengan ketiadaan audit mandiri, sebab ketiadaan audit berarti ketiadaan pengukuran, risiko yang tidak terukur seperti berenang di perairan yang tidak diketahui kedalamannya dan ada risiko hewan apa saja yang mungkin menghampiri. Berkenaan dampak negatif merupakan sebuah kepastian atau bukan, tidak dapat ditentukan terkecuali telah dapat didipastikan apakah ada atau tidak ada subjek (black hat atau gray hat hacker) yang menjadikan sistem yang Anda kelola sebagai objek (target peretasan/cracking), jika ada maka apa yang menjadi target capaian peretasannya dan seberapa jauh eskalasi dampak negatif atas capaian tersebut, berapa besar kapasitas peretas dan berapa besar kapasitas defender hosting serta pengelola aplikasi yang aplikasinya menjadi target. Adapun faktor yang berpengaruh terhadap besar kecilnya risiko, yakni ada atau tidaknya black hat atau gray hat hacker, risiko menjadi lebih besar bilamana black hat atau gray hat itu memiliki kapasitas dan target yang besar dalam membawa kerugian, ini dapat diperparah bilamana sistem tidak memiliki security check/audit internal yang memadai dan atau pengelola aplikasi tidak siap secara teknis (kompetensi) dan prosedural. 

6. Bagaimana jika aplikasi kami berbasis SaaS/PaaS dan kami tidak punya kontrol penuh?
Audit mandiri tetap relevan. Fokus bisa dialihkan ke aspek yang bisa dikendalikan: konfigurasi pengguna, pengelolaan data, integrasi antar sistem, dan pemantauan SLA dari penyedia layanan. Namun langkah yang logis dan rasional yakni bila tiap-tiap PTTI tidak menunggu terjadinya insiden terlebih dahulu, tidak dikambinghitamkan terlebih dahulu atas ketiadaan kontrol akses untuk penanggulangan/pertanggungjawaban, lalu kemudian baru menyadari bahwa kontrol itu penting atas risiko yang telah terjadi yang mana sebelumnya risiko itu dianggap hanya perumpamaan, simulasi atau halusinasi.

7. Apakah ada contoh atau template audit mandiri yang bisa kami gunakan?
Silahkan unduh starter pack audit mandiri keamanan aplikasi - Aptika Diskominfosp Kutim.

8. Siapa yang sebaiknya memimpin proses audit mandiri keamanan aplikasi di unit kerja kami?
Maslahat jika hanya ada dua pilihan, PTTI atau atasan langsung. Skenario atasan langsung untuk memimpin audit mandiri: Bilamana atasan langsung PTTI lebih ahli dan terampil dalam hal audit teknis aplikasi dan DevOps, maka sebaiknya dipimpin atasan langsung dan analisis serta problem solving dilakukan PTTI dengan arahan/bimbingan atasan langsung. Skenario PTTI masing-masing aplikasi memimpin proses audit mandiri: PTTI yang telah ditentukan dan ditetapkan melakukan langkah-langkah sebagaimana dimaksud di atas (inventaris aplikasi, dst). Kekurangan dari skenario kedua ini adalah PTTI tidak memiliki peran yang tepat untuk konsultasi/bimbingan, karena berjalannya skenario kedua ini menandakan ketiadaan atau minimnya kompetensi oleh peran di atasnya. Sebagai gantinya, dapat berkonsultasi pada aktor-aktor yang tertera pada SK CSIRT.

9. Di mana wadah PTTI untuk berkontribusi dan bertukar informasi untuk pengetahuan berkenaan aplikasi?
Di artikel/blog Aptika Diskominfosp Kutim. Hanya perlu menyempurnakan proses verifikasi, anda dapat berkontribusi dengan membuat karya tulis yang bernilai pengetahuan aplikasi informatika. Apakah SK PTTI atas aplikasi yang anda kelola telah terinventaris pada etalase kebijakan Aptika Diskominfosp Kutim? jika telah ada namun belum terinventaris, maka silahkan komunikasikan dengan pengelola SI Aptika Diskominfosp Kutim.

10. Berapa batas usia maksimal PTTI?
Tidak ada batas usia tertentu. Berdasarkan hasil pencarian, usia programmer tertua yakni 88 tahun dengan usia memulai belajar programming di 81 tahun, sedangkan administrator sistem server senior yang tertua ada di kisaran usia 70-80 tahun.

 

Lampiran

Audit Item SaaS/PaaS Mandiri Untuk Masing-masing PTTI (Individu)

Kritikal
Autentikasi & Otorisasi:
  1. Penggunaan autentikasi yang kuat (misal: 2FA, password kompleks).
  2. Pembatasan akses berbasis peran (role-based access control).
Manajemen Kerentanan:
  1. Patch dan update rutin pada sistem dan aplikasi.
  2. Tidak ada komponen atau library yang sudah usang/berisiko.
Enkripsi:
  1. Enkripsi data sensitif, baik saat transit maupun saat disimpan.
  2. Penggunaan protokol aman (HTTPS/TLS).
Logging & Monitoring:
  1. Pencatatan log aktivitas penting (login, akses data, perubahan konfigurasi).
  2. Monitoring insiden keamanan secara real-time.
Backup & Recovery:
  1. Prosedur backup data teratur dan uji pemulihan data.
  2. Proteksi backup dari akses tidak sah.
Firewall & Proteksi Jaringan:
  1. Implementasi firewall aplikasi/web.
  2. Proteksi terhadap serangan umum (DDoS, brute force, SQL injection, XSS).
 
Sekunder
Audit & Penilaian Berkala:
  1. Audit keamanan aplikasi secara berkala.
  2. Penilaian risiko dan simulasi insiden (penetration test).
Edukasi & Awareness:
  1. Pembelajaran Mandiri Keamanan Siber bagi Tim Pengelola Aplikasi.
  2. Membuat Artikel Keamanan Aplikasi yang Efektif dan Efisien bagi Tim Keamanan Siber dan Tim Pengelola Aplikasi.
Dokumentasi & SOP:
  1. Dokumentasi tata kelola aplikasi dan prosedur keamanan.
  2. SOP penanganan insiden dan pelaporan.
Pengelolaan Aset & Hak Akses:
  1. Inventarisasi aset aplikasi dan data.
  2. Review hak akses secara berkala.
Integrasi Keamanan Tambahan:
  1. Penggunaan WAF (Web Application Firewall) dan IDS/IPS.
  2. Mekanisme anti-malware dan anti-phishing.
Privasi Data:
  1. Implementasi kebijakan privasi sesuai regulasi.
  2. Masking data pada lingkungan pengujian.

 

Unduh

Tags:
audit mandiri keamanan aplikasi informatika penyelesaian strategis penyelenggaraan