Jika tidak memiliki Backup yang baik, maka bisa meminta bantuan professional untuk melaksanakan recovery, namun hal tersebut tidak menjamin, karena ada varian ransomware yang menggunakan enkripsi dengan algoritma yang cukup strong sehingga tidak mudah untuk dikembalikan tanpa mengetahui kunci sebenarnya.

Terkait mekanisme backup, tentunya harus direncanakan dengan sangat matang, contohnya tidak hanya menyimpan backup di 1 tempat saja, melainkan juga dapat memanfaatkan strategi air gap (backup ke storage yang terisolasi). Jika masih memiliki file backup yang sehat, maka dapat dengan mudah melakukan proses recovery.

Terkait solusi perlindungan tambahan, pada 11DB/Postgres™ terdapat fitur Equnix Seamless Encryption (ESE) dengan metode column-based encryption, serta dilengkapi juga dengan pengaturan akses yang baik melalui role based access control sehingga ini dapat memberikan keamanan database yang tangguh.

Terkait solusi hemat biaya, 11DB/Postgres™ merupakan solusi alternatif dengan performa dan security yang tinggi. Kami mengembangkan solusi berbasiskan Open Source dan riset untuk membantu korporasi di Indonesia dapat mencapai Kemandirian, Kemerdekaan, dan Kedaulatan. Dengan begitu, korporasi dapat terhindar dari vendor lock-in. Apakah UMKM dapat memanfaatkanya? Tentu saja, namun pertimbangan biaya dan tingkat layanan menjadi hal yang cukup krusial bagi UMKM, karena tingkat layanan yang mumpuni selaras dengan biaya yang dikeluarkan. Mungkin dengan menggunakan layanan berbasis Cloud dapat menjadi solusi yang baik bagi UMKM.

Kita harus melakukan berbagai pencegahan pada berbagai lapisan keamanan. Dimulai dari pengaturan hak akses hardware (jangan sampai ada orang yang tidak berkepentingan mengambil alih kontrol), OS (karena di OS running berbagai aplikasi), database (termasuk melakukan hardening), aplikasi, framework, dst. Selain dari segi teknologi yang dapat memproteksi data, perlu diterapkan Tata Kelola dan Tata Laksana yang baik agar teknologi yang bagus tersebut dapat digunakan dan dikelola dengan baik.

Pengaturan hak akses yang sesuai dengan kebutuhan, disain sistem yang mengedepankan keamanan akses dan data, Pengaturan tata kelola yang menyeluruh, dan implementasi tata laksana yang baik adalah beberapa faktor penting yang dapat mencegah terjadinya kebocoran data. Pengabaian terhadap faktor diatas berpotensi terjadinya kebocoran data.

Kita dapat meminimalisasi risiko melalui penerapan NDA dan teknologi Zero Trust. Jika ingin mengakses langsung ke dalam sistem, user jangan langsung mengakses dari laptop, tetapi melalui VPN atau jump host (sebuah tempat trusted yang diperbolehkan untuk mengakses ke dalam server), lalu user dapat remote dari jump host. Selain dari aspek Teknologi, perlu juga diperhatikan dari segi Tata Laksana dan Tata Kelola yang ketat dan jelas.

Dalam filosofi zero trust, semua titik dapat menjadi potensi breach, dan oleh karenanya harus dimitigasi, bukan berarti sudah terjadi breach. Justru adanya enkripsi ESE ini digunakan sebagai cara kita mengimplementasikan zero trust, untuk minimalisasi potensi breach atau data leak.

Mengenai penggunaan tooling seperti CARAKA atau fitur spesifik 11DB tidak ditujukan untuk triage, bilamana attacker sudah menguasai sistem, dengan cara tertentu atau karena adanya kesalahan disain akses, maka ESE hanya dapat berfungsi untuk mengamankan data fisik yang dienkripsi, setidaknya menghindarkan dari kebocoran data karena adanya pencurian storage secara fisik. Pada dasarnya Teknologi CARAKA maupun fitur 11DB sebenarnya tidak ditujukan untuk kegiatan after attack seperti triage.

Kemudian, apabila kondisinya sudah ada ransomware dan data di-encrypt, maka bisa mengambil data dari lokasi backup. Lalu, bagaimana cara memastikan backupnya. Backup yang kita terapkan harus menerapkan multi level backup (multi tier backup) mulai dari snapshot 11DB/Postgres™ nya, snapshot disini dapat dikatakan mengambil secara keseluruhan dari databasenya, dan adanya incremental backup untuk bisa me-recover sehingga Recovery Point Objective-nya itu bisa sedekat mungkin dari waktu kejadiannya. Kemudian backup ini jangan disimpan hanya dalam satu tempat saja, misalkan kita sudah memiliki satu server, kemudian backup-nya kita taruh di server yang sama, bahkan jika di dalam satu hardisk yang sama, itu akan sama saja. Jadi, kita akan lempar ke satu storage spesifik tertentu, dan dari satu server itu akan dilempar lagi ke tempat lain seperti storage server khusus untuk backup atau teknologi isolated zone, dimana backupnya akan ditarik ke tempat lain kemudian hanya diakses atau terkoneksi saat kondisi tertentu seperti saat akan melakukan recovery tersebut. Dalam 11DB/Postgres™ sudah mendukung fitur snapshot, archiving, dan dapat dilempar ke storage lain, dan bisa dilakukan recovery secara PITR (Point Time Recovery). Sebagai contoh, terjadi ransomware attack pada pukul 11:00, apakah kita masih punya data backup-nya di situ atau dari tempat lain yang sudah di produce oleh 11DB/Postgres™ yang selanjutnya kita ambil dan restore, recover atau reply kembali semua transactionnya. Kemudian backup yang kita lakukan itu benar benar bersih dan tidak terinfeksi dari sebelumnya, jadi jika memang databasenya benar-benar sudah ter-encrypt yang sudah tidak bisa dibuka atau diakses secara file sistemnya. Kita biasanya menerapkan hashing, backupnya di hash dan simpan informasi hashnya. Jika keduanya sama, maka betul. Jika tidak sama, mungkin ada alteration, kita akan recover datanya dan lakukan PITR, seharusnya jika hash-nya masih sama, maka saat di-copy atau backup, hasil hash–nya harus sama kembali. Karena backup is not a backup if it cannot be restored.

Ya, memang terutama adalah akses superuser, pada dasarnya, semua akses harus bisa dicatat, diawasi, dan diaudit. Dengan menggunakan Caraka, kita juga mencatat semuanya, termasuk kegiatan yang dilakukan oleh semua user yang membutuhkan challenge OTP. Apabila terdapat tindakan mencurigakan (percobaan akses berkali-kali), kita bisa tuning lebih lanjut dan retrieve agar tidak menggunakan Super User setiap saat, melainkan menggunakan user dengan privilege yang sesuai.

Salah satunya harus sering dilakukan sosialisasi kepada tim sendiri seperti mengenai security awareness, misalkan jangan akses menggunakan root karena itu sudah salah besar. Lalu terkait dengan akses juga sama, kita terapkan policy-policy yang menjadi tata kelola, dan harus diterapkan, ditegakkan juga diawasi agar tim kita memberikan managed support yang baik. Jika memang ada akses-akses yang dibutuhkan untuk di approved harus mengajukan terlebih dahulu kepada supervisor atau atasannya. Salah satunya dengan teknologi Caraka, karena di dalam Caraka terdapat logging yang dapat dievaluasi, jika ada yang akan mengakses server, maka diakses akan di capture atau tercatat bahwa siapa akan melakukan apa, kapan, dari handphone mana. Jadi itu pentingnya sebuah audit log, pengawasan harus dilakukan secara berkala dan menerapkan tata kelola yang baik.

Akses langsung dari Sistem Operasi kedalam localhost Database, menjadi perhatian utama dalam security, karena bug atau zero day bug pada OS dapat muncul kapan saja, ada ribuan system call pada sistem operasi yang tidak mudah di awasi atau di mitigasi, bahkan oleh penyedia sistem operasi professional sekalipun. Dalam catatan sejarah ada saja lubang keamanan yang dapat dimanfaatkan oleh tindakan illegal untuk mendapatkan akses superuser sistem operasi (root-kit). Sehingga mitigasi terbaik saat ini adalah minimalisasi akses konsol terhadap host dimana database berada.

Superuser bukanlah user, melainkan tools yang kita pergunakan dalam kondisi sangat khusus, tidak boleh dipergunakan untuk kegiatan sehari-hari.

Super User hanya boleh dipegang oleh satu entitas, tidak boleh disebar ke orang secara sembarangan, dan perlu diintervensi dengan menggunakan MFA. Super User juga hanya digunakan untuk kegiatan dengan concern tinggi, seperti server side tuning, configuration, ataupun modification.

Seperti di 11DB/Postgres™, database ini juga tidak boleh diakses oleh Super User langsung melalui remote (CLI) dan perlu menggunakan Caraka sebagai MFA dan satu kesatuan gerbang untuk mengakses dashboard. Pengaturan autentikasi ini sangat penting dalam keamanan akses karena autentikasi ini melibatkan verifikasi user, verifikasi hak user, dan tracking ataupun audit kegiatan yang dilakukan oleh setiap user.

Terkait performance tuning, ini perlu dibahas di topik khusus agar penjelasannya dapat diberikan secara komprehensif. Namun, secara singkat, beberapa upaya performance tuning dapat dilakukan melalui normalisasi data, melakukan query dengan efektif, dan penerapan indeks.

Jika membicarakan server melalui OS artinya masuk ke dalam environment yang berjalan di atas server tersebut. BMC masuk ke dalam hardware management dan kenapa di harden, karena akses terhadap BMC memiliki hak yang lebih tinggi daripada superuser OS, sehingga itu harus diproteksi karena tidak boleh sembarang diakses. Contoh di production dalam proses tahapan preparation deployment, kita dapat mengakses ke dalamnya, namun ketika sudah production maka akan ditutup aksesnya. Tujuannya jangan sampai ada orang orang yang tidak diketahui atau tidak berwenang masuk ke dalam server tersebut dan mengontrol secara hardware, dan membuat sistem operasi lumpuh.

Langkah paling sederhana adalah dengan menggunakan SSL untuk setiap komunikasi data, namun ada cara yang lebih proper, yaitu dengan melakukan mengimplementasi switch dan melakukan konfigurasi dengan baik agar tidak ada kemungkinan sniffing. Atau dengan pertimbangan zero trust, bisa dengan mengimplementasikan keduanya.

Risiko maksimal, karena dengan cara tersebut akan sangat mudah mendapatkan akses superuser OS dan kedepannya akan dapat menguasai sistem secara keseluruhan. Linux Single Boot termasuk kedalam akses fisik yang tidak menjadi domain prevensi dari CARAKA.

Jika ingin benar-benar aman, pasti ada sedikit hal yang harus dikorbankan, seperti performa. Enkripsi pada 11DB/Postgres™ tetap menghasilkan CPU overhead, tetapi kami tekan hingga <2% agar tidak terlalu tinggi, melalui beberapa cara, yaitu:

1. Menerapkan index untuk mempermudah dan mempercepat pencarian data.
2. Melakukan enkripsi hanya pada kolom tertentu yang memang berisi data sensitif. Jika mengenkripsi pada table space, maka semua kolom pada tabel tersebut akan dienkripsi sehingga menghasilkan degradasi performa. Padahal. tidak semua data harus dienkripsi.

Selain dengan cara tersebut, kita juga dapat melakukan normalisasi data dengan memisahkan tabel berisi data yang sering di-update dan data yang jarang di-update (data terenkripsi).

Jika sudah menerapkan teknologi yang sesuai untuk melindungi keamanan sistem, maka tantangan berikutnya adalah mengenai Tata Kelola dan Tata Laksananya. Ketiga hal ini tidak dapat dipisahkan dan harus dilaksanakan dengan penuh kehati-hatian dan kecermatan untuk betul-betul dapat melindungi keamanan sistem.

IT Sovereignty secara harfiah adalah kedaulatan di dunia IT. Dengan kita memiliki kemandirian dalam mendapatkan sumber daya IT (Komputasi: Hardware, software, talent) maka kita tidak tergantung pada vendor asing, dan menghindarkan dari adanya potensi eavesdropping dari software yang kita dapat kan dari luar. Terlebih bilamana kita dapat menghindarkan dari penggunaan cloud asing yang jelas mengurangi kedaulatan kita akan data kita sendiri. Saat ini memang yang kita sasar dalam hal kedaulatan IT adalaah layer OS, Framework, Database dan Aplikasi. Kita belum memiliki industri hardware yang secara mandiri dapat memenuhi kebutuhan domesik, terima kasih atas mentionnya.

Setiap layer memiliki mitigasi keamannya sendiri, khususnya untuk 11DB/Postgres, dengan menerapkan ESE yang memiliki kemampuan enkripsi data secara end-to-end maka setidaknya system breach pada Sistem Operasi ataupun akses fisik pada hardware tidak menjadikan data dapat dikuasai oleh Attacker karena dalam kondisi terenkripsi. Adalah benar sistem keamanan harus berlapis sesuai dengan ruang lingkup dari masing-masing lapisan tersebut, tidak cukup hanya pada satu atau dua lapisan saja.

Saya rasa hingga saat ini, penggunaan SSL sangat efektif. Saat ini, untuk pertukaran key pada SSL sebaiknya menggunakan ML-KEM yang quantum-proof dan tidak lagi menggunakan RSA.

Banyak tools lain yang dapat digunakan. Contohnya adalah Equnix Seamless Encryption (ESE) untuk mengenkripsi data, Ksema, Caraka, SSL, dan lainnya. Lainnya seperti Pgcrypto namun kurang efektif karena integrasi dengan key managementnya harus dilakukan secara mandiri.

Dalam pengelolaan kunci, ESE terintegrasi dengan HSM untuk key management. Kunci disimpan di HSM dengan protokol HSM untuk store dan retrieve the keys. Jika ada user yang masuk dan ingin connect ke suatu database, maka key akan di-retrieve untuk bisa digunakan sesuai EPL level. Sehingga penerapan ini pun harus dipastikan agar aktivitas encrypt dan decrypt sesuai dengan hak akses setiap user. Terkait query database, kami menerapkan indexing untuk search data ke kolom yang di-encrypt, serta juga melakukan query dan server tuning.

Untuk kegiatan backup dan restore, tentunya kita menerapkan metode backup binary dan restore binary juga, sehingga tidak ada issue dengan penggunaan ESE, sementara untuk replikasi, selama replikasi yang dilakukan juga menggunakan binary streaming tidak ada masalah karena akan menggunakan konfigurasi dan key enkripsi yang sama. Sementara bilamana diinginkan untuk melakukan archiving maka sebaiknya menggunakan Replikasi logis yang dapat membuka kolom yang ternkripsi sehingga proses archiving dalam kondisi tidak diamankan oleh ESE, dan tentu saja tidak lagi menjadi domain proteksi ESE (karena archive tersebut sudah tidak lagi menjadi domain sistem produksi)

Yang dimaksud mungkin list of user dalam database kemudian rolenya apa saja. Dalam 11DB/Postgres™, kita bisa mengetahui semua list user yang ada di dalam database dan per masing-masing objectnya bisa muncul. Seperti contoh bahwa ada yang berwarna hijau itu read, kuning itu execute, dan merah itu write, sehingga dengan dashboard ini akan mempermudah dibandingkan memakai query. Karena sudah ada privilege dan rolenya untuk masing-masing object-nya juga. Cukup mudah meng-eksport user database untuk kebutuhan tersebut.