¿Cómo proteger los datos del usuario en la base de datos con Rails?

Question

Estoy creando una aplicación de rieles que necesita almacenar una gran cantidad de datos confidenciales. Para asegurar a mis clientes que los datos están protegidos, quiero encriptarlos por usuario. Investigué buscando gemas que puedan lograr esto. Hasta ahora he encontrado strongbox y safe. Juntos, esto parece proporcionar una solución para mí.

Sin embargo, me pregunto si esta es una práctica común. Parecería que la mayoría de las aplicaciones de rieles tienen algunos datos confidenciales para almacenar con respecto a sus usuarios. está manejando mi encriptación de contraseñas, pero los correos electrónicos y otros datos personales son igual de delicados. ¿Es una práctica común dejar estos elementos sin cifrar en la base de datos y asumir que nunca se verán comprometidos? Entiendo que la base de datos reside en un área que no se puede comunicar con el mundo exterior, pero un atacante determinado podría fácilmente comprometer esto. ¿Es una práctica común que los desarrolladores de Rails dejen sus datos sin cifrar y simplemente confíen en la seguridad de su servidor web?

Answer 1

El problema con el cifrado de su base de datos es que cualquier cosa que encripte no se puede utilizar en una consulta SQL, y también tiene que descifrarse antes de poder usarla. Esto significa que debe colocar la clave de descifrado muy cerca de la base de datos y, en la mayoría de los casos, si alguien puede poner en peligro su base de datos, eso significa que también han comprometido su clave de descifrado al mismo tiempo. Por lo tanto, el paso de cifrado le ha comprado muy poco. Con las contraseñas, no es necesario descifrar porque en realidad es una función hash. Es mucho mejor asegurarse de que la base de datos nunca se vea comprometida en primer lugar.

Siempre asuma que si un pirata informático puede poner en peligro una parte de su seguridad, pueden comprometerlo todo. La cadena es tan fuerte como su eslabón más débil y todo eso.

Los números de tarjeta de crédito y de la seguridad social (que afortunadamente no es necesario que indexe) son probablemente la excepción más obvia, pero si tiene que hacer esta pregunta, no tiene que almacenarlos artículos en primer lugar. Hay todo tipo de problemas legales en los que te puedes meter por meterse esas cosas.

Answer 2

Número de tarjeta de crédito, SSN, etc. siempre deben almacenarse cifrados.

Las contraseñas siempre se deben almacenar cifradas, utilizando un hash unidireccional. Esto significa que cuando el usuario proporciona una contraseña, puede determinar si coincide con lo que almacenó en la base de datos, pero dado solo la representación cifrada en la base de datos, no puede determinar su contraseña, salvo los ataques de fuerza bruta/diccionario.

Encuentro que en mi aplicación, me gusta agregar lectores y escritores _ **** no encriptados a mi clase, para que el manejo de la representación encriptada sea sencillo.

class User 
    # has db column encrypted_cc_number 
    def unencrypted_cc_number 
    WhateverEncryptionClassYouUse.decrypt(encrypted_cc_number) 
    end 
    def unencrypted_cc_number=(val) 
    self.encrypted_cc_number = WhateverEncryptionClassYouUse.encrypt(val) 
    end 
end 

Answer 3

El uso de mecanismos de seguridad en capas y la criptografía fuerte es una buena práctica si está almacenando una gran cantidad de datos sensibles. Es requerido por el estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS). Le sugiero que lea el siguiente documento de directrices: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf.

Usted debe definitivamente no "asume que nunca se verá comprometida"