it-swarm-id.com

Manajemen kunci enkripsi Aplikasi Web

Singkatnya, mari kita pertimbangkan aplikasi web yang menyimpan beberapa informasi dalam database sebagai data terenkripsi. Sementara saya sengaja mencoba untuk menjaga ini agar tetap generik, berikut adalah beberapa asumsi:

  • Data terenkripsi hanya disimpan dalam database (tidak di tempat lain). Beberapa bidang dalam catatan yang diberikan dienkripsi, beberapa tidak.
  • Aplikasi web harus menulis data terenkripsi ke database.
  • Aplikasi web harus dapat membaca dan menampilkan data terenkripsi. Data hanya ditampilkan di bagian autentikasi dan dikelola yang dikelola aplikasi.
  • Data adalah informasi sensitif yang perlu dilindungi jika data dibuka/diakses (tanpa kunci *).

Pertanyaan:

  • Di mana/bagaimana Anda menyimpan kunci yang digunakan untuk enkripsi? Pertama, dalam sistem di mana server web dan database sama, bagaimana Anda mengelola kuncinya? Kedua, dalam sistem di mana server web dan server DB terpisah, bagaimana Anda mengelola kuncinya?
  • Apakah kunci hanya file yang dibatasi izin? Disimpan dalam beberapa alat/perangkat lunak terpisah? Saya telah melihat menyebutkan bahwa kadang-kadang kunci enkripsi juga dienkripsi, tetapi tidak jelas di mana itu dapat membantu.

Saya tahu ini adalah pertanyaan keamanan yang cukup mendasar dan jadi jika ada sumber daya yang mungkin saya lewatkan itu juga akan sangat, sangat membantu. Saya telah menghabiskan banyak waktu (selama bertahun-tahun) mencoba memahami informasi ini berdasarkan informasi tentang keamanan aplikasi web (OWASP, PCI DSS, dll.), Tetapi sering kali informasi ini sangat umum (misalnya, "melindungi data "," mengenkripsi data ") atau sangat spesifik (" untuk mengenkripsi sesuatu dengan AES, lakukan ini ... ").

* Saya mengerti bahwa ini bukan solusi keamanan lengkap. Saya mengerti bahwa ada beberapa vektor untuk mendapatkan informasi ini dan mendekodekannya. Saya mengakui bahwa ini mungkin pertanyaan yang buruk dalam terang itu :)

Diedit untuk menambahkan lebih banyak informasi tentang asumsi untuk pertanyaan ini

47
Rob

Di mana/bagaimana Anda menyimpan kunci yang digunakan untuk enkripsi?

Pendekatan standar jika Anda menggunakan enkripsi bawaan pada sesuatu seperti database SQL atau Oracle, database akan menghasilkan kunci enkripsi dan mengenkripsi ini dengan kunci perlindungan kunci lain atau kunci Master. Ini bisa berupa frasa sandi atau kunci yang lebih panjang yang disimpan di mis. file .pem.

Ini biasanya disimpan dalam direktori terbatas yang hanya dapat diakses oleh root/Administrator dan akun layanan basis data. Pada inisiasi basis data kuncinya dibaca dan dimuat ke dalam memori. Ini kemudian digunakan untuk mendekripsi kunci enkripsi.

Pertama, dalam sistem di mana server web dan database sama, bagaimana Anda mengelola kuncinya?

Kunci disimpan dalam direktori di server. Untuk memperbarui atau mencabut biasanya melalui program database.

Kedua, dalam sistem di mana server web dan server DB terpisah, bagaimana Anda mengelola kunci?

Kuncinya disimpan secara lokal hanya pada server database. Opsi yang lebih aman adalah dengan menggunakan Modul Keamanan Perangkat Keras (HSM) dalam skenario mana pun. Ini adalah perangkat perangkat keras yang dilampirkan ke server dan digunakan untuk menyimpan kunci daripada folder yang dibatasi di server.

Apakah kunci hanya file yang dibatasi izin? Disimpan dalam beberapa alat/perangkat lunak terpisah? Saya telah melihat menyebutkan bahwa kadang-kadang kunci enkripsi juga dienkripsi, tetapi tidak jelas di mana itu dapat membantu.

Membatasi folder dapat diterima selama Anda mengelola akses administrator dan memantau hal-hal seperti login tanpa izin, login sebagai akun layanan, akun baru atau grup yang ditambahkan dengan akses ke folder. Seperti disebutkan di atas, HSM adalah opsi yang lebih aman jika data yang Anda lindungi dan ancaman yang Anda hadapi membutuhkannya.

Umumnya database akan membuat instance atau kunci tabel dan kemudian mengenkripsi ini dengan kunci master. Ada sedikit manfaat dalam mengenkripsi kunci master lebih lanjut.

11
Rakkhi

Sementara beberapa informasi yang baik telah diberikan dalam jawaban sebelumnya, ada cacat desain kritis, yang tidak benar-benar diperhatikan - tetapi berasal dari beberapa asumsi implisit dalam pertanyaan tersebut.

Perbedaannya tidak boleh antara:

  • Aplikasi web dan DB di server yang sama
  • Aplikasi web dan DB di server yang berbeda
  • enkripsi aplikasi vs db

Desain harus dimulai dari:

  • Siapa yang butuh akses ke kunci enkripsi/dekripsi?

Atau, sebenarnya lebih benar:

  • Siapa yang bertanggung jawab untuk melindungi kerahasiaan data?

Yang, pada gilirannya, berasal dari:

  • Ancaman apa yang Anda coba lindungi?
    Atau
  • Siapa yang Anda coba untuk mencegah membaca data Anda?

Hanya berdasarkan pertanyaan-pertanyaan ini, Anda dapat merancang cryptosystem yang direkayasa dengan baik. (Dan mencegah debu peri crypto yang disebut @ D.W.).

Jadi, beberapa contoh skenario:

  • Pengguna harus bertanggung jawab atas enkripsi, bahkan mencegah admin aplikasi melihat data
  • Aplikasi klien harus bertanggung jawab, tanpa harus melibatkan pengguna - tetapi ini masih perlu dilakukan di sisi klien (mis. Program cadangan).
  • Appserver secara aplikatif dan khusus mengenkripsi data yang dipilih, sebagai bagian dari logika bisnis (bahkan dba tidak dapat melihat data)
  • Server database harus secara otomatis dan transparan mengenkripsi data yang disimpan. (Ini hanya melindungi terhadap pencurian file db/disk fisik, dengan peringatan ...).

Untuk kesederhanaan, mari kita asumsikan bahwa enkripsi harus dilakukan di sisi server, tanggung jawab terletak pada server, dan pengguna akhir (dan administrator) tidak memiliki pengaruh pada enkripsi.

Pertanyaan utama, kemudian, apakah enkripsi dilakukan oleh server aplikasi, atau server database? (Sebenarnya tidak begitu sederhana, ada opsi lain ...)
Ini, seperti halnya sebagian besar masalah keamanan, kembali ke kompromi:

  • Apakah Anda mengelola kunci Anda sendiri, atau Anda lebih suka abstrak infrastruktur ini secara otomatis? (pertanyaan awal ... info lebih lanjut di bawah ...)
  • Apakah Anda khawatir tentang kejahatan (atau tidak kompeten programmer tidak berpengalaman?
  • Apakah Anda khawatir tentang admin jahat?
  • Apakah Anda khawatir tentang penggunaan aplikasi yang tidak sah?
  • Apakah Anda khawatir tentang akses SQL yang tidak sah?
  • Apakah Anda khawatir tentang akses file langsung yang tidak sah?
  • Apakah Anda khawatir tentang pencurian disk/server fisik?

Dan seterusnya. (Perhatikan bahwa beberapa pertanyaan di atas tidak relevan, dan tidak dapat diselesaikan dengan enkripsi server).


Sekarang, mari kita asumsikan Anda membuat keputusan, berdasarkan hal di atas, antara enkripsi server dan enkripsi basis data.
Perhatikan bahwa apakah server web dan db berada di server yang sama atau tidak, hampir tidak berpengaruh di sini - jika aplikasi mengenkripsi, maka itu hanya mengirim data "khusus" ke db, kalau tidak itu bisa diperdebatkan. Namun, ini tidak mempengaruhi diskusi ancaman di atas - beberapa masalah sudah usang oleh desain, ada yang ditingkatkan ...

  • Enkripsi server Web/Aplikasi
    • Kunci enkripsi (EK) yang Anda gunakan untuk mengenkripsi data, harus dienkripsi sendiri dengan kunci kunci enkripsi ( KEK).
    • EK terenkripsi harus disimpan di tempat yang terlindungi - ini bisa berupa file, kunci registri, apa pun - yang penting adalah membatasi akses ke sana, hanya untuk pengguna appserver (dan, mungkin admin - lihat di bawah).
    • KEK juga membutuhkan perlindungan - ini agak sulit.
      Jika Anda menggunakan Windows, Anda memiliki akses mudah ke DPAPI - ini menyediakan manajemen kunci tingkat OS, sehingga Anda dapat memiliki OS mengenkripsi KEK Anda dan mengelola kunci secara transparan untuk Anda. (Di balik layar, DPAPI akhirnya bergantung pada mengetahui kata sandi pengguna (dalam USER_MODE), sehingga merupakan titik akhir, titik lemah dari rahasia yang diketahui sebenarnya - tetapi tidak ada orang lain yang harus tahu kata sandi server di tempat pertama, kan?)
      Pilihan lain adalah perangkat eksternal/HSM, dibahas lebih lanjut di bawah ini.
    • KEK juga membutuhkan kontrol akses, tentu saja - ACL yang terbatas dan semua itu.
    • Ada beberapa alasan Anda ingin memisahkan EK dari KEK: Anda tidak ingin mengenkripsi data dalam jumlah besar dengan satu kunci; jika Anda perlu mengganti kunci, itu menjadi jauh lebih mudah (hanya mengenkripsi ulang EK dengan KEK baru); Anda dapat menggunakan enkripsi/penyimpanan yang lebih kuat, lebih lambat, lebih kompleks pada KEK; jika Anda harus memenuhi PCI, Anda dapat menerapkan split-knowledge pada KEK; dan lainnya.
    • Baik EK dan KEK tidak boleh disimpan dalam jangka panjang tanpa enkripsi - tergantung pada platform/bahasa Anda, ini berarti mis. tidak menyimpannya dalam objek String di .NET atau Java. Sebagai gantinya, simpanlah dalam array byte yang dapat diubah, dan selalu pastikan Anda membuangnya sesegera mungkin.
    • Beberapa kerangka kerja bahkan melangkah lebih jauh, dan menyediakan objek yang dilindungi spesifik. Misalnya. di .NET Anda dapat menggunakan kelas System.Security.Cryptography.ProtectedMemory dan/atau System.Security.Cryptography.ProtectedData untuk menjaga kunci tetap terlindungi, bahkan di memori.
  • Enkripsi basis data
    • Jika Anda memiliki server database Anda melakukan enkripsi, ini menjadi jauh lebih mudah: tabel/bidang dikonfigurasi untuk secara otomatis mengenkripsi data yang tersimpan di dalamnya, manajemen kunci benar-benar transparan (dari PoV aplikasi, bukan DBA), dan begitu seterusnya.
    • Sebagai contoh, Oracle dan MS SQL Server keduanya mendukung enkripsi built-in otomatis. Untuk MSSQL, manajemen kuncinya kompleks, namun mirip dengan yang saya jelaskan di atas. Sederhana: Ada EK, disimpan dalam database, yang dapat dikonfigurasi dba untuk digunakan untuk mengenkripsi/mendekripsi tabel atau bidang. Ini berada dalam tabel yang dilindungi, dienkripsi oleh KEK, pada gilirannya dienkripsi oleh KEK tingkat server, pada gilirannya dienkripsi menggunakan DPAPI pada akun layanan MSSQL.
    • Atau, MSSQL juga mendukung penggunaan enkripsi asinkron, mis. menyimpan pasangan kunci publik/pribadi - ini dapat berguna dalam skenario tertentu.
  • Opsi ketiga: penyimpanan enkripsi eksternal, atau HSM (modul keamanan perangkat keras) . Ini bisa berupa perangkat keras bersama, server, atau kartu perangkat keras atau dongle ... dll. [.____]
    • Perangkat ini dirancang untuk melindungi data kecil dengan sangat aman - mis., KEK Anda.
      Sekali lagi, alasan lain mengapa memisahkan EK dari KEK - ini akan memungkinkan Anda untuk mengenkripsi dan mendekripsi massa data secara efisien dengan EK, sambil tetap mengelola KEK dengan aman.
    • HSM biasanya diakses melalui driver khusus atau API, dimungkinkan untuk memasukkan ini ke dalam enkripsi basis data juga (tergantung pada produk, dll).
29
AviD