Enkripsi Data: Terminologi Penting yang Harus Diketahui Pengembang

Saat dunia menjadi semakin didorong oleh data, penanganan data pengguna yang aman menjadi lebih penting dari sebelumnya.

Sebagai pengembang, pekerjaan kami sudah cukup sulit: menangani sistem yang sangat kompleks dan rapuh dengan banyak titik kegagalan sementara kami menerjemahkan keinginan manusia yang melayang ke UI dan backend. Untuk menambah tugas adalah pertimbangan yang muncul dan penting: keamanan data. Dan untuk alasan yang baik: kami sebagai pelanggan marah jika data kami disalahgunakan (jadi wajar saja jika kami memberikan pengalaman yang aman dan menyenangkan bagi pengguna kami), dan pemerintah serta perusahaan menuntut kepatuhan.

Keamanan data sebagai yang terbaik

Apa yang membuat keamanan lebih sulit adalah bahwa ia memiliki beberapa lapisan dan menjadi tanggung jawab semua orang. Dalam tim cloud modern, beberapa tim secara langsung mengontrol masuk/keluar data: pengembang, admin database, sysadmin (orang DevOps, jika Anda mau), pengguna back-office yang memiliki hak istimewa, dan sebagainya. Peran/tim ini dapat dengan cepat menutup mata dan menganggap keamanan data sebagai masalah orang lain. Namun, kenyataannya adalah bahwa mereka memiliki dunianya sendiri untuk diurus karena admin database tidak dapat mengontrol sisi keamanan aplikasi, orang DevOps sama sekali tidak dapat melakukan apa pun tentang akses back office, dan seterusnya.

Pengembang dan keamanan data

Semua yang dikatakan, pengembang memiliki area permukaan akses terbesar dalam hal data: mereka membangun setiap bagian dari aplikasi; mereka terhubung ke berbagai layanan backend; token akses feri bolak-balik; mereka memiliki seluruh cluster database untuk membaca/menulis dari perintah mereka; aplikasi yang mereka tulis memiliki akses tak terbantahkan ke semua bagian sistem (misalnya, aplikasi Django dalam produksi memiliki semua hak istimewa untuk membuang atau menghapus seluruh koleksi S3 selama sepuluh tahun terakhir), dan seterusnya. Akibatnya, kemungkinan tertinggi kecerobohan atau kelalaian dalam hal keamanan ada di tingkat kode sumber dan merupakan tanggung jawab langsung pengembang.

Sekarang, keamanan data adalah lubang kelinci tanpa dasar, dan tidak mungkin saya bisa menggaruk permukaan dalam satu posting. Namun, saya ingin membahas terminologi penting yang harus diketahui pengembang untuk menjaga keamanan aplikasi mereka. Anggap saja sebagai Keamanan Data Aplikasi 101.

Mari kita mulai!

Hashing

Jika Anda menginginkan definisi yang sangat ketat, selalu ada Wikipedia, tetapi dalam istilah sederhana, hashing adalah proses mengubah data ke bentuk lain, di mana informasinya tidak dapat dibaca. Misalnya, menggunakan proses pengkodean Base64 yang terkenal (dan sangat tidak aman), string “Apakah rahasia saya aman bagi Anda?” dapat dikonversi (“hash”) menjadi “SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”. Jika Anda mulai menulis buku harian pribadi Anda dalam format Base64, misalnya, tidak mungkin keluarga Anda dapat membaca rahasia Anda (kecuali mereka tahu cara memecahkan kode dari Base64)!

Ide mengacak data ini digunakan saat menyimpan kata sandi, nomor kartu kredit, dll., di aplikasi web (sebenarnya, ini harus digunakan di semua jenis aplikasi). Idenya, tentu saja, adalah bahwa jika terjadi pelanggaran data, penyerang tidak boleh menggunakan kata sandi, nomor kartu kredit, dll., untuk melakukan kerusakan yang sebenarnya. Algoritma yang sangat kuat dan canggih digunakan untuk melakukan hashing ini; sesuatu seperti Base64 akan menjadi lelucon dan akan langsung dipatahkan oleh penyerang mana pun.

Sandi hashing menggunakan teknik kriptografi yang dikenal sebagai hashing satu arah, yang berarti bahwa meskipun mungkin untuk mengacak data, tidak mungkin untuk mengacaknya. Lalu bagaimana aplikasi tahu itu kata sandi Anda saat Anda masuk? Yah, ia menggunakan proses yang sama dan membandingkan bentuk acak dari apa yang baru saja Anda masukkan sebagai kata sandi dengan formulir acak yang disimpan dalam database; jika cocok, Anda diizinkan untuk masuk!

Sementara kita membahas topik hash, ada sesuatu yang menarik. Jika Anda pernah mengunduh perangkat lunak atau file dari Internet, Anda mungkin diminta untuk memverifikasi file sebelum menggunakannya. Misalnya, jika Anda ingin mengunduh ISO Ubuntu Linux, halaman unduhan akan menunjukkan kepada Anda opsi untuk memverifikasi unduhan Anda; jika Anda mengkliknya, sebuah popup akan terbuka:

Munculan memberitahu Anda untuk menjalankan perintah, yang pada dasarnya akan meng-hash seluruh file yang baru saja Anda unduh dan membandingkan hasilnya dengan string hash yang Anda lihat di halaman unduhan: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 . Konversi ini dilakukan menggunakan algoritme SHA256, yang penyebutannya dapat Anda lihat di bagian akhir perintah: shasum -a 256 --check .

Idenya adalah jika hash yang dihasilkan melalui cek Anda berbeda, ini berarti seseorang telah mencampuri unduhan Anda dan memberi Anda file yang dikompromikan sebagai gantinya.

Beberapa nama akrab yang akan Anda dengar di domain hashing kata sandi adalah MD5 (tidak aman dan sekarang tidak berfungsi), SHA-1, dan SHA-2 (keluarga algoritme, di mana SHA-256 adalah anggotanya, seperti SHA-512), SCRYPT, BCRYPT, dll.

pengasinan

Semua jenis keamanan adalah permainan kucing-dan-tikus: pencuri mempelajari sistem saat ini dan muncul dengan celah baru, yang diperhatikan, dan pembuat kunci meningkatkan permainan mereka, dan seterusnya dan seterusnya. Kriptografi tidak terkecuali. Sementara mengonversi hash kembali ke kata sandi menjadi tidak mungkin, penyerang dari waktu ke waktu telah mengembangkan teknik canggih yang menggabungkan tebakan cerdas dengan kekuatan komputasi belaka; sebagai hasilnya, sembilan kali sepuluh, mereka dapat memprediksi kata sandi yang benar, hanya dengan hash.

Akibatnya, teknik pengasinan telah berkembang. Artinya, perhitungan hash kata sandi (atau data apa pun) akan dilakukan berdasarkan kombinasi dua hal: data itu sendiri, serta string acak baru yang tidak dapat ditebak penyerang. Jadi, dengan salting, jika kita ingin hash kata sandi superman009 , pertama-tama kita akan memilih string acak sebagai "garam," misalnya, bCQC6Z2LlbAsqj77 dan kemudian melakukan perhitungan hash pada superman009-bCQC6Z2LlbAsqj77 . Hasil hash akan menyimpang dari struktur biasa yang dihasilkan oleh algoritme, sangat mengurangi cakupan rekayasa balik atau tebakan cerdas.

Baik Hashing dan Salting adalah domain yang sangat rumit dan terus berkembang. Jadi, sebagai pengembang aplikasi, kami tidak akan pernah berurusan langsung dengan mereka. Tapi itu akan sangat membantu kami jika kami tahu ini dan bisa membuat keputusan yang lebih baik. Misalnya, jika Anda memelihara kerangka kerja PHP lama dan kebetulan melihat bahwa ia menggunakan hash MD5 untuk kata sandi, Anda tahu sudah waktunya untuk memasukkan pustaka kata sandi lain dalam proses pembuatan akun pengguna.

Kunci

Anda akan sering menemukan istilah "kunci" dalam konteks enkripsi. Sejauh ini, kami telah membahas hashing kata sandi atau enkripsi satu arah, di mana kami mengonversi data secara permanen dan menghancurkan bentuk aslinya. Ini adalah ide yang buruk untuk penggunaan praktis sehari-hari — dokumen yang ditulis dan dikirim melalui email dengan sangat aman sehingga tidak akan pernah bisa dibaca tidak ada gunanya! Jadi, kami ingin mengenkripsi data sedemikian rupa sehingga kami ingin informasi terbuka dengan pengirim dan penerima, tetapi ketika sedang ditransfer atau disimpan, itu harus tidak dapat dibaca.

Untuk ini, konsep "kunci" ada dalam kriptografi. Persis seperti apa bunyinya: kunci gembok. Orang yang memiliki informasi mengacaknya menggunakan beberapa rahasia yang disebut kunci. Kecuali penerima/penyerang memiliki kunci ini, tidak mungkin untuk menguraikan data, tidak peduli seberapa canggih algoritme mereka.

Tombol Putar

Sementara kunci memungkinkan enkripsi dan dapat diandalkan, kunci membawa risiko yang dilakukan kata sandi: begitu seseorang mengetahui kuncinya, seluruh permainan selesai. Bayangkan sebuah skenario di mana seseorang meretas beberapa bagian dari layanan seperti GitHub (walaupun selama beberapa detik) dan dapat memperoleh kode berusia 20 tahun. Di dalam kode, mereka juga menemukan kunci kriptografi yang digunakan untuk mengenkripsi data perusahaan (praktik yang mengerikan untuk menyimpan kunci bersama dengan kode sumber, tetapi Anda akan terkejut betapa seringnya hal ini terjadi!). Jika perusahaan tidak mau repot-repot mengganti kuncinya (seperti kata sandi), kunci yang sama dapat digunakan untuk membuat kekacauan.

Akibatnya, praktik mengganti kunci sering berkembang. Ini disebut rotasi kunci, dan jika Anda menggunakan penyedia PaaS cloud yang terhormat, itu harus tersedia sebagai layanan otomatis.

Misalnya, AWS memiliki layanan khusus untuk ini yang disebut AWS Key Management Service (KMS). Layanan otomatis menyelamatkan Anda dari kerumitan mengubah dan mendistribusikan kunci di antara semua server dan saat ini tidak perlu khawatir dalam hal penerapan besar.

Kriptografi Kunci Publik

Jika semua pembicaraan sebelumnya tentang enkripsi dan kunci membuat Anda berpikir itu sangat rumit, Anda benar. Menjaga kunci tetap aman dan meneruskannya sehingga hanya penerima yang dapat melihat data mengalami masalah logistik yang tidak memungkinkan komunikasi aman saat ini berkembang. Tetapi semua berkat kriptografi kunci publik, kami dapat berkomunikasi atau melakukan pembelian secara online dengan aman.

Jenis kriptografi ini merupakan terobosan matematis utama, dan itulah satu-satunya alasan Internet tidak berantakan dalam ketakutan dan ketidakpercayaan. Detail algoritmanya rumit dan sangat matematis, jadi saya hanya bisa menjelaskannya secara konseptual di sini.

Kriptografi Kunci Publik bergantung pada penggunaan dua kunci untuk memproses informasi. Salah satu kuncinya disebut Kunci Pribadi dan seharusnya tetap rahasia dengan Anda dan tidak pernah dibagikan dengan siapa pun; yang lain disebut Kunci Publik (dari mana nama metode itu berasal) dan seharusnya dipublikasikan secara publik. Jika saya mengirim data kepada Anda, pertama-tama saya harus mendapatkan kunci publik Anda dan mengenkripsi data dan mengirimkannya kepada Anda; di akhir Anda, Anda dapat mendekripsi data menggunakan kunci pribadi dan kombinasi kunci publik Anda. Selama Anda tidak secara tidak sengaja mengungkapkan kunci pribadi Anda, saya dapat mengirimkan data terenkripsi kepada Anda yang hanya dapat dibuka oleh Anda.

Keindahan sistem ini adalah saya tidak perlu mengetahui kunci pribadi Anda, dan siapa pun yang mencegat pesan tidak dapat melakukan apa pun untuk membacanya meskipun mereka memiliki kunci publik Anda. Jika Anda bertanya-tanya bagaimana ini mungkin, jawaban terpendek dan paling non-teknis berasal dari sifat perkalian bilangan prima:

Sulit bagi komputer untuk memfaktorkan bilangan prima yang besar. Jadi, jika kunci aslinya sangat besar, Anda dapat yakin bahwa pesan tersebut tidak dapat didekripsi bahkan dalam ribuan tahun.

Keamanan Lapisan Transportasi (TLS)

Anda sekarang tahu cara kerja Kriptografi Kunci Publik. Mekanisme ini (mengetahui kunci publik penerima dan mengirimi mereka data yang dienkripsi menggunakan itu) adalah apa di balik semua popularitas HTTPS dan itulah yang menyebabkan Chrome mengatakan, "Situs ini aman." Apa yang terjadi adalah bahwa server dan browser mengenkripsi lalu lintas HTTP (ingat, halaman web adalah string teks yang sangat panjang yang dapat ditafsirkan oleh browser) dengan kunci publik masing-masing, menghasilkan HTTP Aman (HTTPS).

Kredit gambar: Mozilla Menarik untuk dicatat bahwa enkripsi tidak terjadi pada Transport Layer seperti itu; model OSI tidak mengatakan apa-apa tentang mengenkripsi data. Hanya saja, data dienkripsi oleh aplikasi (dalam hal ini, browser) sebelum diserahkan ke Transport Layer, yang kemudian meletakkannya di tempat tujuannya, tempat data didekripsi. Namun, prosesnya melibatkan Transport Layer, dan pada akhirnya, semuanya menghasilkan transportasi data yang aman, sehingga istilah "transport" layer security yang longgar tetap ada.

Anda bahkan mungkin menemukan istilah Secure Socket Layer (SSL) dalam beberapa kasus. Ini adalah konsep yang sama dengan TLS, kecuali bahwa SSL berasal jauh sebelumnya dan sekarang tidak lagi digunakan untuk TLS.

Enkripsi Disk Penuh

Terkadang kebutuhan keamanan begitu kuat sehingga tidak ada yang bisa dibiarkan begitu saja. Misalnya, server pemerintah tempat semua data biometrik suatu negara disimpan tidak dapat disediakan dan dijalankan seperti server aplikasi biasa karena risikonya terlalu tinggi. Tidaklah cukup untuk kebutuhan ini bahwa data dienkripsi hanya ketika sedang ditransfer; itu harus dienkripsi saat istirahat juga. Untuk ini, enkripsi disk penuh digunakan untuk mengenkripsi keseluruhan hard disk untuk memastikan data aman bahkan saat dilanggar secara fisik.

Penting untuk dicatat bahwa Enkripsi Disk Penuh harus dilakukan di tingkat perangkat keras. Itu karena jika kita mengenkripsi seluruh disk, sistem operasi juga dienkripsi dan tidak dapat berjalan saat mesin dinyalakan. Jadi, perangkat keras harus memahami bahwa konten disk dienkripsi dan harus melakukan dekripsi dengan cepat saat melewati blok disk yang diminta ke sistem operasi. Karena pekerjaan ekstra ini dilakukan, Enkripsi Disk Penuh menghasilkan pembacaan/penulisan yang lebih lambat, yang harus diingat oleh pengembang sistem tersebut.

Enkripsi ujung ke ujung

Dengan mimpi buruk privasi dan keamanan yang sedang berlangsung dari jejaring sosial besar akhir-akhir ini, tidak ada yang tidak menyadari istilah "enkripsi ujung ke ujung", bahkan jika itu tidak ada hubungannya dengan membuat atau memelihara aplikasi.

Kita telah melihat sebelumnya bagaimana Enkripsi Disk Penuh menyediakan strategi antipeluru terbaik, tetapi untuk pengguna sehari-hari, ini tidak nyaman. Maksud saya, bayangkan Facebook ingin agar data ponsel yang dihasilkan dan disimpan di ponsel Anda aman, tetapi Facebook tidak dapat memiliki akses untuk mengenkripsi seluruh ponsel Anda dan mengunci semua hal lain dalam prosesnya.

Untuk alasan ini, perusahaan-perusahaan ini telah memulai enkripsi ujung ke ujung, yang berarti data dienkripsi saat dibuat, disimpan, atau ditransfer oleh aplikasi. Dengan kata lain, bahkan ketika data mencapai penerima, data tersebut sepenuhnya dienkripsi dan hanya dapat diakses oleh telepon penerima.

Perhatikan bahwa enkripsi End-to-End (E2E) tidak membawa jaminan matematis seperti kriptografi Kunci Publik; itu hanya enkripsi standar di mana kunci disimpan dengan bisnis, dan pesan Anda seaman yang diputuskan bisnis.

Kesimpulan

Anda mungkin pernah mendengar sebagian besar istilah ini. Bahkan mungkin semuanya. Jika demikian, saya mendorong Anda untuk meninjau kembali pemahaman Anda tentang konsep-konsep ini, serta melakukan evaluasi seberapa serius Anda menanggapinya. Ingat, keamanan data aplikasi adalah perang yang harus Anda menangkan setiap saat (dan bukan hanya sekali), karena satu pelanggaran saja sudah cukup untuk menghancurkan seluruh industri, karier, dan bahkan kehidupan!