¿Qué tan seguro es este escenario de seguridad?

2

En un proyecto en el que estoy trabajando, necesitaba escribir algunas secuencias de comandos de trabajo cron, cuyo propósito es acceder a algunas API externas, que tienen información a la que el público no debería tener acceso. Todas las API externas requieren un nombre de usuario y una contraseña para que sean accesibles.

Al cliente le preocupaba que, si de alguna manera, alguien, logra piratear el servidor, y almacenamos las contraseñas en los archivos de script para estas API, el pirata informático obtendría acceso a la información segura o podría transferir dinero de estas API's a su propia cuenta.

Para resolver este problema, básicamente, para crear una segunda capa de seguridad en toda la aplicación, pensé que podía eliminar los trabajos cron, escribiendo una aplicación de demonio simple, que cuando se inicia, solicita una contraseña al administrador. Con esa contraseña, descifra las claves de acceso de la API y comienza a replicar las cosas que los trabajos de cron hicieron anteriormente.

El mayor inconveniente de esto es que siempre que el daemon se detiene por algún motivo, el administrador DEBE reiniciarlo manualmente, pero mi cliente dijo que esto no es un problema para él.

Básicamente, lo que me gustaría saber es qué tan seguro es este enfoque. ¿Puede un pirata informático, que logra piratear el servidor, recuperar la contraseña de administrador que se le proporcionó al demonio al iniciar, desde la memoria?

El entorno que uso es PHP (sé que esta no es la mejor solución para los scripts de daemon, pero el tiempo es preocupante, y este fue el más rápido de implementar).

¿Qué otros inconvenientes tiene este método, que no he pensado?

    
pregunta Adam Baranyai 19.11.2017 - 12:51
fuente

2 respuestas

3

Mover la contraseña a la memoria aumenta el costo para el atacante, pero no mucho. A cambio, el proceso del servidor se vuelve más frágil (lo que requiere la presencia humana para reiniciar), lo cual (como usted señaló) puede impactar negativamente los SLAs.

La regla general es que si un proceso legítimo tiene acceso a la información, también lo hace el actor de amenazas (si obtienen acceso al entorno del proceso legítimo). Cualquier API que se implemente de esta manera requiere la contraseña de texto sin formato.

Puede tomar un poco de trabajo educar a su cliente para que entienda esto.

(Esa es la respuesta básica a tu pregunta explícita. Aquí hay información adicional sobre el problema mayor que estás tratando de resolver :)

Otra mitigación podría ser almacenar parte del material en un HSM . Si se implementa correctamente, esto dificultaría aún más el acceso. Pero incluso entonces, si el servidor está comprometido, un atacante podría escribir código adicional para interceptar la contraseña a medida que se envía a la API.

Otra opción es mover la contraseña a un servidor proxy más seguro . Si no tiene la capacidad de bloquear el servidor actual, pero podría crear otro servidor que podría hacer significativamente más seguro, entonces podría usar ese servidor como un proxy y almacenar la contraseña allí. Esto aumenta la complejidad, pero puede valer la pena si el servidor proxy se puede reforzar. Ese servidor proxy también podría usarse para monitorear las transacciones en busca de actividad inusual, y bloquear cualquiera que no cumpla con ciertos criterios.

También podría trabajar con el proveedor de API para limitar de dónde proviene la actividad a direcciones IP específicas (de modo que el actor de amenazas no pueda simplemente robar la contraseña y luego usarla desde cualquier lugar). / p>

Si el servidor lo admitiera, también podría usar el cifrado de clave pública para proteger la contraseña o un certificado SSL de cliente para controlar quién puede conectarse a través de TLS.

Y, en general, debería usar HTTPS para la conexión y POST en lugar de GET para evitar que la contraseña aparezca en las URL en los registros, etc. Esto ayudará a proteger la contraseña en el vuelo fuera de del servidor.

Pero en todos estos escenarios, la contraseña debe usarse en texto plano, y siempre será vulnerable a la interceptación en algún paso del flujo de trabajo.

    
respondido por el Royce Williams 19.11.2017 - 18:02
fuente
1

Un concepto que a menudo trato de articular a los clientes es el principio de fuente limpia . Puede ser muy efectivo si asume una violación de un sistema y trabaja desde allí, pero también requiere que comprenda la relación de confianza entre los sistemas y sus elementos. Esto puede ser más complejo de lo que mucha gente imagina.

    
respondido por el Patrick Fussell 21.11.2017 - 05:24
fuente

Lea otras preguntas en las etiquetas