Enkripsi sering kali menjadi topik keamanan, tetapi penting juga untuk privasi. Tujuan enkripsi adalah untuk mencegah orang lain membaca informasi terenkripsi... tetapi mencegah orang lain membaca informasi Anda adalah salah satu cara untuk membuatnya tetap pribadi. Pengguna sering kali dibatasi dalam hal kemampuan yang dapat dilakukannya sendiri. Namun, dengan bantuan Anda sebagai penyedia layanan yang digunakan, enkripsi dapat membantu mempertahankan data miliknya.
Ada tiga cara yang relevan untuk menerapkan enkripsi guna membantu privasi pengguna: enkripsi saat dalam pengiriman, enkripsi dalam penyimpanan, dan enkripsi end-to-end:
- Enkripsi saat dalam pengiriman adalah menjaga data tetap terenkripsi antara pengguna dan situs Anda: yaitu HTTPS. Anda mungkin sudah menyiapkan HTTPS untuk situs, tetapi apakah Anda yakin bahwa semua data yang dikirim ke situs Anda dienkripsi? Inilah fungsi pengalihan dan HSTS, dan dijelaskan di bawah ini dan harus menjadi bagian dari penyiapan HTTPS Anda.
- Enkripsi dalam penyimpanan adalah enkripsi data yang disimpan di server Anda. Hal ini melindungi dari pelanggaran data dan merupakan bagian penting dari sikap keamanan Anda.
- Enkripsi end-to-end adalah enkripsi data pada klien sebelum mencapai server Anda. Tindakan ini melindungi data pengguna bahkan dari Anda: Anda dapat menyimpan data pengguna, tetapi tidak dapat membacanya. Hal ini sulit diterapkan, dan tidak cocok untuk semua jenis aplikasi, tetapi sangat membantu privasi pengguna, karena tidak ada yang dapat melihat data mereka selain diri mereka sendiri.
HTTPS
Langkah pertama adalah menayangkan layanan web Anda melalui HTTPS. Kemungkinan besar Anda sudah melakukannya, tetapi jika belum, itu adalah langkah yang penting. HTTPS adalah HTTP, protokol yang digunakan browser untuk meminta halaman web dari server, tetapi dienkripsi menggunakan SSL. Artinya, penyerang dari luar tidak dapat membaca atau mengganggu permintaan HTTPS di antara pengirim (pengguna Anda) dan penerima (Anda), karena pesan dienkripsi sehingga dia tidak dapat membacanya atau mengubahnya. Ini enkripsi dalam pengiriman: saat data berpindah dari pengguna ke Anda, atau dari Anda ke pengguna. Enkripsi HTTPS dalam pengiriman juga mencegah ISP pengguna, atau penyedia Wi-Fi yang mereka gunakan, agar tidak dapat membaca data yang mereka kirimkan kepada Anda sebagai bagian dari hubungan mereka dengan layanan Anda. Hal ini juga dapat memengaruhi fitur layanan Anda: banyak penggunaan JavaScript API yang ada mengharuskan situs ditayangkan melalui HTTPS. MDN memiliki daftar yang lebih lengkap, tetapi API yang digunakan dengan konteks yang aman meliputi pekerja layanan, notifikasi push, berbagi web dan kripto web, serta beberapa API perangkat.
Untuk menayangkan situs melalui HTTPS, Anda memerlukan sertifikat SSL. Paket ini dapat dibuat secara gratis melalui Let's Encrypt, atau sering kali dapat disediakan oleh layanan hosting Anda jika Anda menggunakannya. Anda juga dapat menggunakan layanan pihak ketiga yang "me-proxy" layanan web Anda dan dapat menyediakan HTTPS, serta layanan caching dan CDN. Ada banyak contoh layanan tersebut, seperti Cloudflare dan Fastly—tepatnya layanan mana yang akan digunakan bergantung pada infrastruktur Anda saat ini. Di masa lalu, HTTPS bisa merepotkan atau mahal untuk diterapkan, sehingga cenderung hanya digunakan di halaman pembayaran atau origin yang sangat aman; tetapi sertifikat yang tersedia secara gratis, peningkatan standar, dan proliferasi browser yang lebih besar telah menghilangkan semua kendala tersebut.
Anjuran
- Aktifkan HTTPS di server Anda untuk semua hal (metode apa pun yang Anda pilih).
- Pertimbangkan untuk menggunakan proxy di depan server Anda, seperti Cloudflare (httpsiseasy.com/ menjelaskan prosesnya).
- Opsi Let's Encrypt akan memandu Anda melalui proses pembuatan sertifikat SSL Let's Encrypt.
- Atau, gunakan OpenSSL secara langsung untuk membuat sertifikat Anda sendiri dan menandatanganinya oleh certificate authority (CA) pilihan Anda (Aktifkan HTTPS akan menjelaskan cara melakukannya secara mendetail).
Pendekatan yang Anda pilih bergantung pada kompromi bisnis. Mengizinkan pihak ketiga mengelola koneksi SSL untuk Anda adalah hal yang paling mudah untuk disiapkan, dan memiliki manfaat lain seperti load balancing, caching, dan analisis. Namun, masalah ini juga disertai dengan penyerahan beberapa kontrol kepada pihak ketiga tersebut secara jelas, serta dependensi yang tidak dapat dihindari pada layanan mereka (dan kemungkinan pembayaran, bergantung pada layanan yang Anda gunakan dan tingkat traffic Anda).
Membuat sertifikat dan menandatanganinya oleh CA adalah cara kerja proses SSL. Namun, penggunaan Let's Encrypt dapat lebih mudah jika didukung oleh penyedia Anda atau jika tim server Anda cukup mahir melakukannya, dan gratis. Penyedia juga biasanya menawarkan SSL sebagai layanan jika Anda menggunakan sesuatu pada level yang lebih tinggi daripada hosting cloud, jadi sebaiknya periksa.
Mengapa
Keamanan adalah bagian dari kisah privasi Anda: kemampuan menunjukkan bahwa Anda menjaga keamanan data pengguna dari gangguan akan membantu membangun kepercayaan. Jika Anda tidak menggunakan HTTPS, situs Anda juga akan ditandai sebagai "tidak aman" oleh browser (dan telah beberapa lama). JavaScript API yang sudah ada biasanya hanya tersedia untuk halaman HTTPS ("asal yang aman"). Hal ini juga melindungi pengguna Anda dari penggunaan web yang dilihat oleh ISP mereka. Ini jelas merupakan praktik terbaik; ada sedikit atau tidak ada alasan untuk tidak menggunakan HTTPS untuk situs web saat ini.
Cara browser menampilkan halaman HTTP (tidak aman)
Mengalihkan ke HTTPS
Jika situs Anda tersedia di URL http: dan https:, Anda harus mengalihkan semua akses URL http ke https. Hal ini dilakukan karena alasan di atas, dan juga memastikan bahwa situs Anda tidak akan muncul di whynohttps.com jika menjadi populer. Cara melakukan ini sangat bergantung pada infrastruktur Anda. Jika dihosting di AWS, Anda dapat menggunakan load balancer Klasik atau Aplikasi. Google Cloud juga serupa. Di Azure, Anda dapat membuat Front Door; di Node dengan Express, periksa request.secure; di Nginx catch all port 80 and return 301; dan di Apache, gunakan RewriteRule. Jika Anda menggunakan layanan hosting, kemungkinan besar layanan tersebut akan otomatis menangani pengalihan ke URL HTTPS untuk Anda: Netlify, Firebase, dan GitHub Pages, di antara banyak lainnya.
HSTS
HSTS adalah kependekan dari "HTTP Strict-Transport-Security", dan merupakan cara mengunci browser agar menggunakan HTTPS untuk layanan Anda selamanya. Setelah Anda puas dengan migrasi ke HTTPS, atau jika sudah melakukannya, Anda dapat menambahkan header respons HTTP Ketat-Transport-Security ke respons keluar. Browser yang sebelumnya telah mengakses situs Anda akan mencatat telah melihat header ini, dan sejak saat itu akan otomatis mengakses situs ini sebagai HTTPS meskipun Anda meminta HTTP. Dengan begitu, pengalihan Anda tidak akan dilewatkan seperti di atas: ini seperti jika browser diam-diam "mengupgrade" semua permintaan ke layanan Anda untuk menggunakan HTTPS.
Demikian pula, Anda dapat menayangkan header Upgrade-Insecure-Requests
bersama halaman Anda. Fungsinya berbeda dari, tetapi terkait dengan Strict-Transport-Security. Jika Anda
menambahkan Upgrade-Insecure-Requests: 1, permintaan dari halaman ini ke resource lain (gambar, skrip) akan diminta
sebagai https meskipun linknya adalah http. Namun, browser tidak akan meminta ulang halaman tersebut sebagai https, dan browser tidak akan mengingatnya untuk lain waktu. Dalam praktiknya, Upgrade-Insecure-Requests berguna jika Anda mengonversi situs yang ada dengan banyak link ke HTTPS dan mengonversi URL link dalam konten sulit dilakukan. Namun, sebaiknya ubah kontennya jika memungkinkan.
HSTS pada dasarnya adalah fitur keamanan: fitur ini "mengunci" situs Anda ke HTTPS bagi pengguna yang pernah mengunjungi situs Anda sebelumnya. Namun, seperti di atas, HTTPS baik untuk privasi, dan HSTS bagus untuk HTTPS. Demikian pula, Upgrade-Insecure-Requests tidak benar-benar diperlukan jika Anda mengupdate semua konten, tetapi ini merupakan pendekatan “belt-and-braces” yang berguna untuk menambahkan perlindungan mendalam dalam memastikan bahwa situs Anda akan selalu berupa HTTPS.
Anjuran
Tambahkan header HSTS ke respons keluar Anda:
Strict-Transport-Security: max-age=300; includeSubDomains
Parameter max-age menentukan berapa lama, dalam detik, browser harus mengingat dan menerapkan upgrade HTTPS. (Di sini kita menyetelnya ke 300 detik, yaitu, lima menit.) Pada akhirnya, Anda ingin angkanya menjadi 6.3072.000, yang berarti dua tahun, dan merupakan angka yang direkomendasikan hstspreload.org, tetapi cukup sulit untuk dipulihkan jika ada masalah. Jadi, sebaiknya tetapkan angka ini dengan angka yang rendah di awal (300), uji untuk mengonfirmasi bahwa tidak ada yang rusak, lalu tingkatkan angkanya secara bertahap.
Tambahkan header Upgrade-Insecure-Requests ke respons keluar:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
Enkripsi end-to-end
Cara yang baik untuk menjaga privasi data pengguna adalah dengan tidak menampilkannya kepada siapa pun selain pengguna tersebut, termasuk Anda. Hal ini sangat membantu sikap kepercayaan Anda: jika Anda tidak memiliki data pengguna, jelas bahwa Anda tidak dapat melakukan apa pun dengan data yang mereka tidak inginkan. Salah satu cara untuk melakukan ini adalah tidak membiarkan data pengguna meninggalkan perangkat mereka sama sekali, dengan menyimpan semua data sisi klien. Pendekatan ini berfungsi, tetapi ada batasan untuk aplikasi murni sisi klien: penyimpanan data browser bisa dibatasi ukurannya, dan di beberapa browser dapat dihapus dengan sedikit atau tanpa peringatan. Data Anda juga sulit atau tidak mungkin diakses di dua perangkat, seperti laptop dan ponsel. Oleh karena itu, mungkin ada baiknya mengirim data ke server seperti biasa, tetapi mengenkripsinya dengan kunci yang hanya diketahui oleh pengguna, sehingga server tidak dapat mengaksesnya (karena tidak dapat mendekripsinya), tetapi dapat menyimpannya.
Bagaimana cara kerjanya?
Pendekatan ini sering digunakan oleh aplikasi pesan, yang disebut sebagai "enkripsi menyeluruh", atau "e2e". Dengan cara ini, dua orang yang mengetahui kunci satu sama lain dapat mengenkripsi dan mendekripsi pesan mereka bolak-balik, serta mengirim pesan tersebut melalui penyedia pesan, tetapi penyedia pesan (yang tidak memiliki kunci tersebut) tidak dapat membaca pesan tersebut. Sebagian besar aplikasi bukanlah aplikasi pesan, tetapi dua pendekatan—penyimpanan data sisi klien dan enkripsi data saja dengan kunci yang diketahui klien—untuk menyimpan data secara lokal tetapi juga mengirimkannya terenkripsi ke server. Penting untuk menyadari bahwa ada batasan pada pendekatan ini: hal ini tidak mungkin dilakukan untuk semua layanan, dan khususnya, tidak dapat digunakan jika Anda, sebagai penyedia layanan, memerlukan akses ke data yang disimpan pengguna. Seperti yang dijelaskan di bagian 2 dalam seri ini, sebaiknya patuhi prinsip minimalisasi data; hindari pengumpulan data jika memungkinkan. Jika pengguna memerlukan penyimpanan data, tetapi Anda tidak memerlukan akses ke data tersebut untuk menyediakan layanan, enkripsi end-to-end adalah alternatif yang berguna. Jika Anda menyediakan layanan yang memerlukan kemampuan untuk melihat apa yang disimpan pengguna untuk menyediakan layanan, enkripsi end-to-end tidak akan cocok. Namun, jika tidak, Anda dapat membuat JavaScript sisi klien layanan web mengenkripsi data apa pun yang dikirimkannya ke server, dan mendekripsi data apa pun yang diterimanya.
Contoh: Excalidraw
Excalidraw melakukan hal ini dan menjelaskan caranya dalam postingan blog. Library ini adalah aplikasi menggambar
vektor yang menyimpan gambar di server, yang dienkripsi dengan kunci yang dipilih secara acak. Salah satu alasan Excalidraw dapat mengimplementasikan enkripsi menyeluruh dengan kode yang relatif sedikit ini adalah karena library kriptografis kini terintegrasi
ke dalam browser dengan window.crypto, yang merupakan kumpulan
JavaScript API yang didukung di semua browser modern. Kriptografi itu sulit dan mengimplementasikan
algoritma memiliki banyak {i>edge case<i}. Meminta browser melakukan bagian pekerjaan yang sulit di sini membuat enkripsi lebih mudah diakses oleh
developer web sehingga mempermudah implementasi privasi melalui data terenkripsi. Seperti yang dijelaskan Excalidraw dalam penulisannya,
kunci enkripsi tetap berada di sisi klien, karena merupakan bagian dari fragmen URL: saat browser mengunjungi URL
https://example.com/path?param=1#fraghere, jalur URL (/path) dan parameter (param=1) diteruskan ke server
(example.com), tetapi fragmen (fraghere) tidak, sehingga server tidak pernah melihatnya. Ini berarti bahwa meskipun data terenkripsi melewati server, kunci enkripsinya tidak, sehingga privasi tetap dipertahankan karena data dienkripsi end-to-end.
Batasan
Pendekatan untuk mengenkripsi data pengguna ini tidaklah sempurna. Hal ini berkontribusi pada sikap kepercayaan Anda terhadap pengguna, tetapi tidak dapat sepenuhnya menggantikannya. Pengguna Anda masih harus mempercayai layanan Anda, karena Anda dapat, kapan saja, menukar penyedia layanan yang dienkripsi dengan JavaScript, dengan beberapa JavaScript serupa yang tidak dapat ditembus tidak dapat ditembus data yang tidak dapat ditembus; dan meskipun pengguna dapat mendeteksi apakah situs yang Anda gunakan telah melakukannya, hal ini sangat sulit dilakukan. Dalam praktiknya, pengguna masih perlu mempercayai bahwa Anda tidak akan sengaja membaca dan menyadap data tersebut.
Penting untuk diingat bahwa salah satu tujuan enkripsi menyeluruh adalah untuk mencegah Anda, sebagai pemilik situs, agar tidak dapat membaca data. Hal ini bagus untuk privasi, tetapi juga berarti bahwa jika ada masalah, Anda tidak dapat membantu. Pada intinya, layanan yang menggunakan enkripsi end-to-end memungkinkan pengguna memegang kunci enkripsi. (Hal ini mungkin tidak jelas atau terang-terangan, tetapi seseorang harus memiliki kuncinya, dan jika data dirahasiakan dari Anda, maka itu bukan Anda.) Jika kunci tersebut hilang, Anda tidak dapat melakukan apa pun untuk membantu, dan mungkin data yang dienkripsi dengan kunci tersebut juga dapat hilang. Terdapat keseimbangan yang baik antara privasi dan kegunaan: menjaga privasi data agar tidak semua orang yang menggunakan enkripsi, tetapi juga menghindari memaksa pengguna untuk menjadi pakar kriptologi yang mengelola kunci mereka sendiri dengan cara yang aman.
Enkripsi dalam penyimpanan
Selain mengenkripsi data pengguna saat dalam pengiriman, pertimbangkan juga untuk mengenkripsi data yang telah Anda simpan di server. Hal ini membantu melindungi dari pelanggaran data, karena siapa pun yang mendapatkan akses tanpa izin ke data Anda yang disimpan akan memiliki data terenkripsi, yang diharapkan tidak memiliki kunci untuk mendekripsinya. Ada dua pendekatan berbeda dan saling melengkapi untuk mengenkripsi data dalam penyimpanan: enkripsi yang Anda tambahkan, dan enkripsi yang ditambahkan oleh penyedia penyimpanan cloud Anda (jika Anda menggunakan penyedia penyimpanan cloud). Enkripsi penyedia penyimpanan tidak memberikan banyak perlindungan terhadap pelanggaran data melalui software Anda (karena enkripsi penyedia penyimpanan biasanya transparan bagi Anda sebagai pengguna layanan mereka), tetapi dapat membantu terhadap pelanggaran yang terjadi di infrastruktur penyedia. Fitur ini sering kali mudah diaktifkan dan sangat patut dipertimbangkan. Kolom ini berubah dengan cepat dan tim keamanan Anda (atau engineer yang menguasai keamanan di tim Anda) adalah saran terbaik untuk memberi saran, tetapi semua penyedia penyimpanan cloud menawarkan enkripsi dalam penyimpanan untuk block storage Amazon S3 dengan menetapkan, Azure Storage, dan Google Cloud Storage secara default, dan untuk penyimpanan data database AWS RDS, antara lain Azure SQL, Google Cloud SQL.{/1 Periksa hal ini dengan penyedia penyimpanan cloud Anda, jika Anda menggunakannya. Menangani enkripsi data dalam penyimpanan sendiri untuk membantu melindungi data pengguna dari pelanggaran data menjadi lebih sulit karena logistik pengelolaan kunci enkripsi dengan aman dan membuatnya tersedia untuk kode tanpa membuatnya juga tersedia bagi penyerang adalah tantangan yang sulit. Tempat ini bukan tempat terbaik untuk memberikan saran terkait masalah keamanan pada tingkat tersebut. Sebaiknya bicarakan dengan engineer atau tim khusus Anda yang memahami hal ini, atau agensi keamanan eksternal.