Lo que impide que un desarrollador acceda a los detalles de la tarjeta de crédito y otros datos secretos de una empresa

PCI DSS las secciones 6, 7 y 8 se refieren a esta pregunta.

Por ejemplo, parte de 6.3.2 que requiere revisión de código:

  

Los cambios en el código son revisados por individuos que no son los originarios   autor del código, y por individuos conocedores del código-revisión   Técnicas y prácticas seguras de codificación.

6.4 con control de cambios:

  

Una separación de funciones entre el personal asignado a la   Entornos de desarrollo / prueba y aquellos asignados a la producción.   medio ambiente.

7.1 que controla el acceso ... en muchos entornos, el desarrollador que escribe el código nunca accede a los sistemas operativos donde se usa con datos en vivo:

  

Limite el acceso a los componentes del sistema y los datos del titular de la tarjeta solo a aquellos   personas cuyo trabajo requiere dicho acceso.

Y un toque de 8.7 para poner restricciones a las personas con acceso:

  

Examine la base de datos y la configuración de la aplicación para verificar   que todos los accesos de los usuarios, las consultas de los usuarios y las acciones de los usuarios en   ejemplo, mover, copiar, eliminar), la base de datos se realiza mediante programación   solo métodos (por ejemplo, a través de procedimientos almacenados).

Ahora, dicho todo, ¿se puede defender perfectamente a un experto de confianza? No, debido a la definición misma de "de confianza". Esto es cierto en todos los lugares (¿en cuántos espías se ha "confiado"? John Anthony Walker viene a la mente). Pero existen las mejores prácticas para defenderse de dicha amenaza, para mitigarlos, y el PCI DSS se formaliza como un número de requisitos. estas prácticas (para tarjetas de crédito ... ¡otros secretos están por su cuenta!)

(Y @ Stephen-Touset señala, 3.5.2 requiere:

  

Almacene claves secretas y privadas utilizadas para cifrar / descifrar el titular de la tarjeta   datos en una (o más) de las siguientes formas en todo momento:

Y una de esas formas es:

  

Dentro de un dispositivo criptográfico seguro (como un módulo de seguridad del host)   (HSM) o dispositivo de punto de interacción aprobado por PTS)

Lo que tiene la ventaja de guardar el material clave real fuera del alcance de los usuarios y administradores del día a día.)

En un grado no insignificante, esto es (como usted mencionó) un problema de confianza, no un problema técnico. Tratamos de ser cuidadosos y, en la medida de lo posible, contratar personas confiables que no abusen de sus posiciones.

Dicho esto, hay una serie de controles que pueden implementarse para limitar el acceso no autorizado y / o verificar que la confianza en las personas está bien ubicada y que, de hecho, no se está abusando de ella.

Estos son algunos de esos controles:

• Los secretos deben mantenerse en secreto. Las claves no deben estar integradas en el software. Deben ser generados y administrados por aquellos que administran y / o usan una instancia de aplicación, no por el desarrollador de la aplicación. Esto significa que las claves utilizadas en un entorno de desarrollo serán diferentes de las del entorno de control de calidad y, ciertamente, diferentes a las utilizadas en la producción, y rara vez hay una razón para que un desarrollador tenga acceso a un entorno de producción, mucho menos. Acceso a las llaves allí.
• Separación de funciones. Esto se lleva a cabo desde el final del último punto. Los desarrolladores desarrollan aplicaciones, los ingenieros de redes administran el tráfico y los dispositivos de red, los ingenieros de servidores administran servidores, los administradores de bases de datos vigilan los datos, etc. En la mayoría de los casos, no sería razonable que un desarrollador tenga acceso a servidores de producción y bases de datos que contengan datos reales y confidenciales, como información de tarjetas de crédito.
• Verificación del trabajo. En este caso, estamos hablando de la revisión del código, principalmente. Una vez más, en la mayoría de los casos, no hay razón para que un desarrollador pueda insertar un código que haga saber quién sabe qué en la producción sin que alguien más lo vea. Si bien esto está diseñado explícitamente para detectar errores involuntarios y que se sigan las mejores prácticas y convenciones, debería tener el efecto secundario de asegurar que se noten las adiciones intencionalmente maliciosas y que aparezcan señales de alerta.

Hay muchos otros controles que podrían incluirse en la lista, pero estas son algunas de las categorías principales en las que se ubicarán la mayoría de ellos.

El costo de prevenir esto es enorme, por lo que rara vez se realiza fuera de grupos de desarrollo enormes y bien financiados. Las menciones anteriores de la revisión del código, la revisión de seguridad, etc. son todas buenas ideas, pero en la práctica, los clientes están más interesados en poner en funcionamiento el código que en retrasar el uso de sus activos durante meses mientras se realizan los procesos de revisión.

El caso mayoritario con el que trata mi compañía es a medianas empresas que están dispuestas a gastar recursos en obtener software personalizado escrito para uso interno, pero sin derrocharse en algunos comités de desarrollo conformes a ISO de manera glacial solo para que su sistema de seguimiento de contactos de clientes o la base de datos de gestión de proyectos se puede mejorar.

Hablando de manera práctica, casi no hay forma de prevenir este tipo de abuso que no sea tratar con proveedores de software en los que confía. Esta no es una solución, por supuesto, pero al menos hace que la mente del cliente sea correcta y puede guiarlo para que elija socios comerciales con cuidado, y un proveedor de software es un socio comercial, uno de los más destacados. Lo íntimo que cualquier empresa tendrá, aunque la gente parece sorprendentemente ciega a esto la mayor parte del tiempo.

Considere los escándalos que surgieron en los últimos años con la participación de Google, Apple, Microsoft, etc. y la NSA. O incluso las invasiones de privacidad autodirigidas de Google. Los desarrolladores estaban asegurándose de que alguien pudiera robar los datos de sus clientes, y de una manera que los procesos de revisión de seguridad, que estas organizaciones en particular son lo suficientemente grandes como para costear, no alcanzaron. Es realmente un "¿Quis custodiet ipsos custodes?" problema (lit. "¿Quién guarda a los guardias?").

En mi propio caso, hemos determinado que nunca mantendremos los datos de los clientes por nosotros mismos. Eso significa que nos levantamos pequeños servidores baratos a los sitios de los clientes, y esos sirven el negocio directamente. Esta es la era de Internet increíblemente rápido y hardware barato; una pequeña empresa no necesita un servicio en la nube para acceder a sus datos desde cualquier lugar del mundo. Para garantizar la seguridad y la redundancia de datos, proporcionamos copias de seguridad a través del cable, pero son todas las burbujas cifradas, por lo que no podemos leerlo.

Nosotros podríamos abrir agujeros en sus servidores y abusar de su confianza si quisiéramos. Pero no hay manera de evitar que alguien malvado haga eso. Como propietario de mi empresa, he decidido que el mejor equilibrio entre la usabilidad de la seguridad VS (para nosotros y para el cliente) es hacer que conserven sus datos, y nosotros solo mantenemos copias de seguridad cifradas de ellos.

Mencioné la "nube" arriba. Esa es probablemente la mayor amenaza para la seguridad de los datos que nadie haya imaginado hasta ahora, y hay exactamente cero formas de garantizar la protección de los datos del cliente una vez que están fuera de sus manos. "La posesión es el 90% de la ley" es una buena lección, porque en la era moderna es el 90% de la seguridad de los datos.

Para las pequeñas y medianas empresas en las que un desarrollador usa varios puestos (DBA, sysadmin, soporte técnico, webmaster, etc.), la tarea de satisfacer el requisito de PCI DSS sería demasiado onerosa. Una posible solución para evitar que un desarrollador obtenga datos confidenciales es utilizar una API de terceros donde el procesamiento y almacenamiento de datos confidenciales se realiza en un sitio web de terceros trust en lugar de tu propio sitio web.

En el caso de las transacciones con tarjeta de crédito y la administración de pagos recurrentes, puede usar PayPal, que es compatible con PCI DSS, en lugar de lanzar su propio sistema . Por supuesto, el código aún debe ser revisado para garantizar que los clientes sean redirigidos al sitio web de terceros durante la transacción.

Al final del día, debe comenzar a confiar en alguien (un desarrollador de confianza o un tercero de confianza) que es contratado para que haga el trabajo por usted. De lo contrario, tienes que hacer todo por ti mismo.

A menudo, el desarrollador no tendrá acceso completo a la base de datos de clientes.

En mi empresa, todo nuestro desarrollo se realiza en bases de datos anónimas: los números de las tarjetas de crédito, los datos personales, etc., se eliminan y todo se confunde. Las bases de datos en vivo están en las máquinas de los clientes y los desarrolladores de nivel junior / medio simplemente no tienen acceso de lectura en esas tablas.

Podríamos acceder a ellos usando las contraseñas del sistema, pero para ello nos registraríamos tanto al recuperar el archivo para extraer la contraseña como al iniciar sesión desde la máquina "incorrecta" en la base de datos.

Otros sistemas que he visto incluyen el cifrado de los detalles de la tarjeta de crédito y que la clave no está disponible para el desarrollador.

Al final del día, un desarrollador suficientemente determinado podría acceder a casi cualquier cosa, pero al hacer que sea difícil evitar las tentaciones ocasionales y al iniciar sesión dejas en claro que habrá repercusiones.

Me sorprende que nadie haya mencionado DUKPT , pero tal vez sea porque algunas de las principales pasarelas de pago nunca llegaron a apoyándolo, y tal vez nunca lo harán ahora que TripleDES está sujeto a ataques de fuerza bruta. Pero fue una gran idea en su momento, y no hay razón para que no pueda hacerse con el cifrado moderno. Algunos proveedores siguen vendiendo lectores de tarjetas con DUKPT o algo así, y hay algunos procesadores pequeños que admiten el cifrado y actúan como servidores proxy para los más grandes.

No puedo agregar nada al artículo de Wiki, y no pretendo entender completamente cómo funciona, solo lo que hace. Pero esencialmente, el hardware es a prueba de manipulaciones y tiene cifrado incorporado, y emite el PAN ya sea encriptado o redactado. Solo la pasarela de pago puede descifrarlo, por lo que el comerciante o el desarrollador de su software no puede ponerlo en peligro por malicia o negligencia.

Además de todas las respuestas que explican cómo evitar que los desarrolladores accedan a esos datos secretos, también hay un método indirecto importante: acceder a los registros

se pueden registrar consultas, al igual que cualquier comando de shell, etc., y estos registros deben guardarse de tal manera que sean imposibles de eliminar por un desarrollador individual, de esa manera, incluso si tienen acceso, se pueden marcar banderas rojas. planteado - ¿por qué quieren TODOS los números de tarjetas de crédito? ¿en producción? - la parte importante de esto es que el desarrollador está usando sus propias credenciales para el trabajo, y que no hay "cuentas compartidas" que no lleven a personas específicas que puedan ser responsables de sus acciones.