Estoy aprendiendo sobre variables ambientales. Sé, por ejemplo, que si tengo una contraseña secreta no debería codificarla dentro de mi código.
Por lo que entendí es que un.envEl archivo debe usarse para cargar los secretos y las variables ambientales.
Una forma aún más segura de almacenar las variables es hacerlo como variables CLI usando elcolocardominio.
El motivo de todo esto es evitar que tu contraseña y datos sensibles no queden expuestos a personas no autorizadas.
Digamos ahora que creo un sitio web que tiene algunos secretos de API almacenados como variables CLI y un hacker puede acceder a mi servidor. Podría descubrir fácilmente los secretos y contraseñas de API con solo escribir el comando.imprimirven la CLI.
¿Cuál es la ventaja de utilizar variables CLI en lugar de almacenarlas en un archivo .env? ¿Cómo puedo asegurarme de que estas variables se oculten incluso para usuarios extraños?
Respuesta1
Una forma aún más segura de almacenar las variables es hacerlo como variables CLI usando el comando set.
No, no es. Por un lado, el comando realmente noalmacenarellos en cualquier lugar persistentes; y la otra cosa más importante acerca de las variables de entorno reales es que son todo lo contrario del almacenamiento seguro. Toda su funcionalidad se basa encada procesoobtener una copia gratuita de todas las variables de entorno: si usara, por ejemplo, setxen Windows para hacer que las variables persistan, entonces, literalmente, cada aplicación o herramienta que ejecute obtendrá automáticamente una copia a partir de entonces, ya sea que las solicite o no.
Cuando ve .envque se utilizan archivos, normalmente se cargan solo en el entorno de la aplicación web específicamente, o incluso no se usan como variables de entorno en absoluto (solo imitan la API familiar pero en realidad cargan las variables en un dict/matriz antiguo y simple). En el primer caso, las variables aún estarían disponibles para los programas generados directamente por la aplicación web, peronuncadisponible para su CLI SSH habitual; a pesar de que todavía se denominan "variables de entorno", ese no es el uso previsto.
(La aplicación en sí, por supuesto, todavía tiene acceso a ellos; después de todo, necesita conocer la clave API para poder usar la API, por lo que eso es inevitable. Siga las prácticas de programación recomendadas para que sea menos probable que un atacante encuentre una manera de ejecútelo printenv; por ejemplo, no coloque entradas externas como nombres de archivos directamente en los comandos.
Dependiendo de las API que esté utilizando, es posible dividir su aplicación en dos (algo así como microservicios) de modo que la interfaz no acceda directamente a la API, sino que siempre utilice otro servicio que conozca la clave API y solo permite que la interfaz realice tareas muy específicas).
Respuesta2
La gestión de secretos, contraseñas y claves es un juego complicado que consiste en equilibrar el esfuerzo que deseas realizar y el riesgo que supone. Algunos ejemplos aquí:
- Secretos pasados mediante un argumento de línea de comando: cualquier usuario del sistema puede verlos
- Secretos pasados desde el archivo text/.env: cualquier usuario con acceso de lectura al archivo puede robarlos. Si usa CLIcolocarComandos, esos también se mostrarán en su historial de comandos de forma predeterminada.
- Secretos cargados desde otro servidor: las credenciales para acceder a ese servidor todavía se almacenan localmente
- Secretos solo almacenados en la memoria: los usuarios con acceso root pueden acceder y volcar datos desde la memoria sin procesar.
Si alguien tiene control de su servidor, puede simplemente cambiar su código para enviarle las contraseñas de todos modos (una forma común de robar información de tarjetas de crédito, por ejemplo).
Recomiendo no almacenar secretos primarios localmente en texto sin formato, ya que es muy sencillo simplemente escanear archivos en busca de contraseñas. Más allá de eso, depende de usted. Algunas formas decentes de mejorar la seguridad son:
- Utilice algún tipo de almacén de claves cifrado para los secretos locales: simplemente agregar otro paso para acceder a contraseñas reales puede detener muchos ataques simples.
- Utilice un servidor/servicio externo para almacenar secretos, de modo que alguien que solo tenga acceso local no obtenga todo fácilmente