¿Cómo hacer llamadas API automatizadas que sean al menos mínimamente seguras? [duplicar]

5

¿Qué debo hacer para escribir scripts (para automatización) en Powershell (y posiblemente incluso en Python) que me ayudan a acceder a las API mientras mantengo la información de credenciales segura EN el script y / o fuera de él (si se almacena y se recupera desde fuera)

Inicialmente, pensé en usar Lastpass, como lo hago para los navegadores web, y de alguna manera recuperar las credenciales de manera segura, pero no tienen ningún tipo de apoyo para tal cosa.

Luego estudié la API de protección de datos de Windows, y la clave utilizada para cifrar la contraseña es específica tanto para el usuario como para la máquina en la que se ejecuta el código, pero como estoy implementando y configurando muchas máquinas virtuales y contenedores, y si necesito acceder a ALGUNAS de las API como parte del proceso de configuración, no puedo usar el método.

Entonces, ¿cómo debo hacer para hacer esto?

Escuché que podemos usar keepass o similares, pero ¿cómo los usaría para mantener sus credenciales seguras para su código mientras las recupera para sus llamadas a la API?

¿Qué debo hacer?

    
pregunta AdilZ 01.12.2016 - 19:13
fuente

2 respuestas

2

Como Anders señaló que hay duplicados, no cubre bien su caso, lo que difiere de una manera que no es la clave para el cifrado sino la contraseña para la API.

Puede usar otro servicio web que esté sirviendo contraseñas de un solo uso, podría funcionar de esta manera:

  1. Su secuencia de comandos de Python del servidor A se conecta al servidor B, que es el "servidor de contraseñas"
  2. Usted envía las credenciales al servidor de contraseñas para autorizarse
  3. Recupera la contraseña de un solo uso (o la contraseña de 1 día) para la API
  4. Se conecta desde el servidor A al servidor C donde está la API y usted envía su contraseña de un solo día o de un día
  5. El servidor API C verifica con el servidor B, independientemente de la contraseña que se pueda usar
  6. Si coinciden las claves, obtienes una respuesta positiva del servidor C (API) al servidor A (cliente de Python).

Debería estar usando SSL (TLS) para todas las conexiones y verificar si los certificados están bien para evitar ataques MITM. También podría utilizar certificados de usuario para autorizarse junto con la contraseña.

Puede ampliar la seguridad de dicho sistema de muchas maneras, por ejemplo, limitando la contraseña de un solo uso a la dirección IP de su script de Python.

Además, su servidor API C puede almacenar las contraseñas en caché para que no las recupere del servidor B cada vez que realice una llamada a la API (idealmente en la RAM).

El beneficio para la seguridad es que tiene una auditoría completa en el servidor C y no tiene contraseñas permanentes, por lo que no necesita cambiarlas.

    
respondido por el Aria 01.12.2016 - 19:36
fuente
2

Hay MUCHAS maneras de repasar esto. Una lista corta incluye:

  • Servicios web
  • Almacenamiento local cifrado
  • Almacenamiento accesible encriptado compartido entre máquinas virtuales / contenedores

Si bien algunos de ellos tienen una gran cantidad de funciones avanzadas (auditoría, control total, seguridad mucho mayor), a menudo TODOS requerirán algún tipo de configuración. Entonces, como mencionó tener acceso a la implementación de contenedores, vamos con un método intermedio congelado y de difícil acceso.

La mejor imagen (s)

Ya que puede implementar contenedores fácilmente, esta opción es tener un contenedor cuyo único propósito es enviar los métodos de autenticación cifrados para los scripts y devolverlos antes de desaparecer, a los que solo se puede acceder desde la LAN de los contenedores en su VPL (Virtual Lan privado) para que NUNCA se comunique con el mundo exterior. En este punto, todo lo que está en el contenedor del script es una clave de descifrado. Solo con sus contenedores internos y máquinas acopladoras en su área remota, nadie puede escuchar esto. Esto significaría que su script tendría la clave de descifrado, y solo sería accesible localmente. Si alguna vez se compromete, cargue 2 nuevas imágenes de contenedor y listo.

Pros:

  • Ya usa un modelo que estás implementando
  • LAN solamente. Utilice una IP interna reservada (rango 172.X.X.X) en un controlador para comunicarse con esta ventana acoplable
  • Múltiples puntos de seguridad significa que, si se ven comprometidas, se pueden cargar nuevas credenciales en imágenes docker recién creadas y limpias
  • EXTREMADAMENTE difícil de comprometer (no la misma máquina, no el mismo código, tendría que comprometer AMBOS extremos para que valga la pena)
  • Protegido fácilmente (quién necesita SSH en un contenedor, ¿verdad?)
  • control de puerto EXACTO (no use los comunes, use uno muy oscuro solo para sus propósitos)
  • Muchos más

Contras:

  • Dos contenedores que deben conservarse junto con la pieza cifrada y la pieza de descifrado
  • Oh no, dos subidas

Ya que esto nunca sale a través de la red, nadie fuera de la red puede agarrar los paquetes e intentar hacer pases para descubrirlo. La lista de profesionales es definitivamente más grande que la pequeña cantidad de esfuerzo que se necesitaría para configurar esto, ya que es una imagen de contenedor. Simplemente cargue el nuevo código, listo.

Ahora que no tiene que preocuparse por almacenar la contraseña en los contenedores con la secuencia de comandos, o el contenedor con la clave de descifrado, puede estar seguro de que en el resto es casi imposible de descifrar. Especialmente si usas TLS con pin cert. Ahora tienes lo mejor de TODOS los mundos, incluso si los contenedores de alguna manera terminan en el mismo host.

Las únicas personas que podrían resolver esto en este punto serían ustedes y cualquier otra persona que sepa cómo se configuró exactamente. Sin embargo, eso se debe a que el eslabón más peligroso en la cadena de seguridad cibernética es el (los) humano (s).

    
respondido por el Robert Mennell 01.12.2016 - 20:05
fuente

Lea otras preguntas en las etiquetas