¿Dónde almaceno de forma segura la clave de un sistema en el que la fuente está visible?

  

¿Cómo puedo proporcionar una seguridad decente en este caso para evitar que alguien tome la base de datos (mediante acceso local, esta máquina NO está conectada a Internet)?

Hay muchas cosas que puedes hacer, pero la mayoría no es directamente programación de base de datos. Debido a que la mayor parte de esto no es programación, podría estar fuera del alcance para usted. No sé para qué fue contratado o qué antecedentes tiene. Si esto está fuera del alcance o no se siente cómodo implementándolo, entonces comunique a su cliente sus inquietudes de seguridad y recomiende que contrate a un especialista.

• Hash los números de tarjeta de crédito.

Esto depende del propósito de los números de tarjeta de crédito almacenados. Si el número solo se usa para identificar de forma única a un cliente o comprar, entonces realmente no necesita el número de la tarjeta de crédito, solo un valor que se asigna de forma inequívoca al número de la tarjeta de crédito. Si este es el caso, entonces reemplaza el número de la tarjeta de crédito con un hash del número de la tarjeta de crédito. Algunos algoritmos hash: SHA1, MD5, RIPEMD-128/256.

• Eliminar el número de la tarjeta de crédito.

Si en algún momento el número de la tarjeta de crédito ya no es necesario, pero el resto de los datos de la fila es, borre el campo de la tarjeta de crédito. Si necesita conservar alguna indicación de la tarjeta, pero no para cargarla, entonces mantenga los últimos cuatro dígitos.

• Rompe la base de datos en partes.

Si no necesita acceder a todo al mismo tiempo, divida la base de datos en partes a las que necesita acceder al mismo tiempo. Si las entradas son independientes, entonces divídalo en partes del mismo tamaño. Esto limitará el daño si una pieza se pierde o es robada. Intente cargar la menor cantidad de piezas a la vez que sea razonable. Si su aplicación tiene solo unas pocas piezas accesibles a la vez, esto ralentizará a un usuario no autorizado.

• Guarde las llaves fuera de la máquina.

Hay algunas maneras de hacer esto. Un método es utilizar un token criptográfico. Hay dispositivos USB, dispositivos de tarjetas inteligentes y tokens de software. Los tokens de software se pueden almacenar en cualquier medio extraíble (CD-ROM, DVD, unidad de disco USB, etc.). Si divide su base de datos en partes, podría considerar el uso de claves diferentes para algunas partes, especialmente si algunas se usan con menos frecuencia que otras.

• 'Sal' su clave

Un salt es un número aleatorio que se usa normalmente con entradas de contraseña con hash para dificultar que un atacante que accede a una base de datos de contraseñas encuentre rápidamente todas las contraseñas en la base de datos. PBKDF2 es un algoritmo criptográfico que utiliza un salt y una contraseña para generar una clave. Genere una sal (número aleatorio) para cada fila y almacene la sal en texto sin formato en la fila. Utilice PBKDF2 u otro algoritmo de generación de clave adecuado para generar una clave para luego alinear y cifrar los datos de la tarjeta de crédito utilizando la clave generada. El propósito es hacer que el atacante lea la base de datos y genere una nueva clave para descifrar cada número de tarjeta de crédito.

• Limite el acceso de red al sistema.

Dice que la máquina no está conectada a Internet pero sospecho que todavía está en una red interna. Use el firewall en el sistema para restringir el acceso a la red a otros dos o tres sistemas. Si el sistema necesita conectarse a más de dos o tres sistemas, entonces puede que tenga que pensar en mover la base de datos a un sistema diferente o hacer un sistema dedicado para la base de datos.

• Limite el acceso de los usuarios al sistema.

Configure la política de seguridad para permitir que solo unos pocos usuarios críticos puedan iniciar sesión en la máquina. Si más de ocho personas necesitan acceso a la máquina, de nuevo, eso debería ser una señal de que la base de datos debe moverse a otro sistema o a su propio sistema dedicado. Mi respuesta rápida a ocho usuarios: administrador del sistema, administrador alternativo del sistema, administrador de seguridad, administrador alternativo de la seguridad, administrador de base de datos, administrador alternativo de la base de datos, desarrollador de la aplicación, desarrollador de la aplicación alternativo.

• Limite el acceso físico al sistema.

Esto es solo la buena puerta cerrada a la antigua. Si necesita estar en un área compartida con otro sistema, intente hacer que sean sistemas que permitan el acceso a los mismos usuarios. Si todo lo que está disponible es un armario o gabinete, solo asegúrese de que tenga una llave única. Una gran cantidad de cerraduras de oficina y furnite comparten claves comunes.

• Limite lo que los usuarios tienen acceso físico al sistema.

El hecho de que necesiten acceder a la máquina no significa que necesiten acceso físico al sistema. Elija a quién le da las llaves y pídales que no hagan copias ni se las presten a nadie más.

Para ser honesto, diría que si está ejecutando el sistema como una base de datos de acceso, presumiblemente con el front-end en el mismo sistema, solo hay una cantidad limitada que puede hacer para proteger los datos, como el atacante determinado podría obtener acceso a la clave de cifrado (por ejemplo, leyéndolo de la memoria cuando se usa).

Dicho esto, puedes hacer algunas cosas para subir un poco la barra. Por lo que he visto, una opción para almacenar secretos en una máquina Windows local es ponerlos en el registro y ACL proteger la clave de registro. Esto puede proporcionar cierta protección en el caso de que alguien tenga acceso al sistema el tiempo suficiente para capturar el archivo .mdb, pero no el tiempo suficiente para buscar la clave de forma exhaustiva en la máquina.

Otra protección valiosa en este escenario, puede ser implementar el cifrado de disco completo en el propio sistema. Esto ayudaría a proporcionar protección en un escenario donde se roba todo el dispositivo (suponiendo que se trata de una máquina de escritorio que probablemente se apagará cuando se la roben).

Aquí hay algunos pasos que podría considerar que podrían ayudar a mitigar algunos riesgos:

• Coloque la base de datos en una máquina separada. Esa máquina separada debe estar bloqueada para que solo ejecute los servicios necesarios para admitir una base de datos. Puede establecer un servidor de seguridad, por lo que solo acepta conexiones entrantes desde el servidor web de aplicaciones para usuario.

  Otra opción es ejecutar el servidor web front-end en una máquina virtual y ejecutar la base de datos en una máquina virtual separada.

• Configure la base de datos para bloquearla y reducir ciertos riesgos de seguridad (por ejemplo, configúrela para que los procedimientos almacenados y las consultas SQL no puedan generar comandos de shell). No sé hasta qué punto esto es aplicable a Access o qué configuraciones se recomiendan para Access, pero este es un buen paso para algunas bases de datos comerciales.

• Dependiendo del diseño y las necesidades de su aplicación web, es posible que solo tenga que escribir los números de las tarjetas de crédito en la base de datos y no leerlos. Si es así, es posible que pueda configurar la base de datos para aplicar esta restricción, ya sea mediante el uso de controles de acceso específicos o mediante controles de acceso generales y procedimientos almacenados (use el control de acceso de granularidad de la tabla o del usuario para evitar la aplicación web). desde el acceso directo a los números de tarjeta de crédito, a continuación, cree un procedimiento almacenado que tenga la capacidad de escribir un nuevo número de tarjeta de crédito, otorgue permiso a la aplicación web para invocar el procedimiento almacenado y convierta la aplicación web de modo que cada declaración SQL que toque las tarjetas de crédito se convierte para utilizar este procedimiento almacenado). Sin embargo, es poco probable que esto sea un cambio trivial en la aplicación web; esto se encuentra en la categoría de mayor riesgo y mayor costo.

• Revise el código del cliente para asegurarse de que usa declaraciones preparadas (o su equivalente), en lugar de concatenación de cadenas, para generar consultas SQL. Si usa la concatenación de cadenas, considere convertirla en declaraciones preparadas. La concatenación de cadenas conlleva riesgos importantes de vulnerabilidades de inyección SQL y representa una práctica de codificación subóptima.

• Como sugiere @Rory, podría considerar usar el cifrado de disco completo para el servidor que aloja la base de datos. Sin embargo, esto puede tener un valor modesto, ya que vuelve al enigma de "¿dónde almaceno la frase secreta?". Puede hacer que un operador del servidor ingrese la contraseña del FDE en el arranque, pero luego, si se produce un corte de energía o si el servidor se reinicia, su sitio estará inactivo hasta que un operador del servidor se presente personalmente para ingresar la frase de contraseña del FDE. .

• Puede considerar el cumplimiento de PCI-DSS como una medida de mitigación de riesgos. Sin embargo, esto podría ser más costoso de lo que está preparado para el cliente.

Dentro de sus restricciones, probablemente no podrá abordar completamente el riesgo de que la base de datos de tarjetas de crédito sea robada. En el mejor de los casos, puede mitigar parcialmente algunos de los riesgos de mayor probabilidad.

No hagas eso.

Seleccione un proveedor de pagos, por ejemplo, Stripe.com o Pay-pal, quien se encargará de la facturación de suscripciones por usted.

pro:   No tiene que sudar los detalles para proteger la base de datos o pagarle a otra persona para que lo haga.

con:   Si ya tiene una cuenta / pasarela comercial, PUEDE terminar pagando un poco más. Sin embargo, es muy probable que cueste lo que cueste, será mucho menos que la responsabilidad de una violación de datos, o la tarifa del asesor de seguridad, o incluso los costos operativos del servidor adicional sugerido por D.W.

El hecho de que su empresa / cliente insista en usar MS Access para esto sugiere que no están calificados para tomar decisiones de seguridad de TI. En serio, simplemente no lo hagas.