Usar la bóveda

He introducido el uso de KMS antes y mencioné sus ventajas y usos. Los escenarios que utilizamos son los siguientes:

Si abandona AWS, la elección parece ser realmente No. demasiados. La Bóveda de Harshicorp es la única que conozco, y RatticDB cuenta como la mitad.

Vault proporciona almacenamiento seguro (clave/valor) y control de tokens, contraseñas, certificados, claves API, etc. Puede manejar la renovación de claves, revocación, auditoría y otras funciones. A través del acceso API, puede obtener contraseñas cifradas y guardadas, claves ssh, certificados X.509, etc. Sus características incluyen:

Debido a que el propósito de usar Vault es

Almacenamiento en Vault [backend(el archivo de pose es el siguiente:

Crear volumen, iniciar el servidor de Vault , configure Páselo a través de la variable de entorno VAULT_LOCAL_CONFIG

Debe ser accesible desde el puerto local 8200:

La siguiente solicitud API puede inicializar Vault. El significado de los dos parámetros es. la clave maestra Divida en varias partes y restaure, use 1 aquí

Resultado devuelto:

La primera es la clave pública de la clave maestra, la segunda es la clave para abrir el sello. y el último es el token raíz. La operación específica solo se puede verificar después de abrir la bóveda.

Resultado:

Por razones de seguridad, podemos usar el token raíz. cree un nuevo token con permisos limitados para continuar con las siguientes operaciones. Supongamos que la ruta que este token puede leer y escribir es secreta/*. Antes de esto, primero creamos una política para acceder a esta ruta:

. y luego cree una política de usuario correspondiente:

Cree dos tokens, token de administrador y token de usuario:

De esta manera, hay dos tokens para leer y escribir bajo los secretos/. * ruta. Puede intentar agregar un nuevo par clave-valor al token de administrador:

Esto proporciona administración de permisos básica, suponiendo que el servidor de almacén y el servidor de aplicaciones o servidor CI estén implementados en el mismo lugar privado. En la red, el servidor de aplicaciones y el esclavo CI no pueden realizar ssh, por lo que a través del servidor de aplicaciones o CI, durante el inicio, se puede obtener API-TOKEN a través de una solicitud HTTP y un token de usuario con permiso de lectura, y no se expone al exterior. p>

La instancia de AWS EC2 se puede vincular a instanciaProfile, que corresponde a la función de IAM. Esta función puede establecer permisos de acceso a los recursos de AWS, como permisos de escritura en un determinado depósito de S3 o permisos de escritura en Dynamodb, etc. Las funciones de AppRoles proporcionadas por Vault son mucho peores que las de instanciaProfile, pero de hecho pueden vincularla a una función con ciertos permisos para controlar el alcance del acceso.

Le permite utilizar el método de verificación de aprobación y crear una función para el esclavo CI al mismo tiempo:

La siguiente solicitud de API puede obtener la identificación de la función y generar la identificación secreta. Según el role-id, puede usarlos para iniciar sesión y obtener permiso para leer datos de la bóveda:

Utilice secret_id y role_id para iniciar sesión conjuntamente y obtener un nuevo token:

Luego use client_token para leer la escritura anterior Vaya al token de API de búsqueda en la bóveda:

Al iniciar el servidor de instancia AWS EC2, puede vincular un par de pares de claves ssh para facilitar a los usuarios el uso de ssh predeterminado del usuario ec2 al servidor. Desde la perspectiva de las mejores prácticas, el servidor debe tratarse como una instalación inmutable, sin permitir ssh. Pero la realidad es más cínica. Esta demanda todavía existe, por lo que podemos cambiar la forma y hacer nuestro mejor esfuerzo para administrar las claves ssh.

Por ejemplo, para cada servidor recién iniciado, se genera dinámicamente un par de claves ssh y se aplica solo a este servidor. Después de destruir el servidor, el par de claves se revoca.

Vault proporciona la función de administración del par de claves ssh. Usando esta función, podemos administrar el ciclo de vida de la clave. Admite dos métodos:

Para que Vault emita pares de claves, primero debe registrar una clave privada, que debe tener derechos administrativos en el servidor. Después de eso, debe crear una función, incluidas algunas. calificaciones, como admin El nombre del usuario, el usuario predeterminado y la dirección CIDR que debe coincidir con la dirección IP del servidor de destino. El proceso específico es el siguiente:

Todo el proceso es más o menos así. la clave privada registrada para iniciar sesión en el servidor de destino y luego escriba la clave pública en el par de claves recién generado en el archivo autorizado_keys del servidor de destino. Cuando desee iniciar sesión en el servidor, utilice el token de cliente correspondiente para verificar, obtener la clave privada e iniciar sesión a través de ssh. La clave tiene un tiempo de vencimiento y será revocada después de su vencimiento.

Creo que una de las dificultades de https en todo el sitio web radica en la gestión de PKI. Este año, ha habido varios problemas en el entorno del producto causados ​​por certificados caducados. Afortunadamente, cambié a AWS Certificate Manager a tiempo. , que es gratuito y vence automáticamente cuando renueva su contrato de arrendamiento, básicamente no tiene que preocuparse por problemas de administración. Nuestra gestión interna de PKI original es un poco más problemática. Necesitamos utilizar la CA intermedia LOB de nuestra propia línea de negocios para emitir nuevos certificados, ejecutar algunos scripts automatizados y encontrar la clave privada correspondiente de RatticDB.

Sin embargo, si la infraestructura no está basada en AWS, parece que no existe una herramienta adecuada y solo puede mantener la PKI usted mismo. Vault también proporciona administración de PKI, lo que puede ayudar en este sentido. Teniendo en cuenta la coherencia del entorno, el desarrollo, las pruebas y la puesta en escena también necesitan certificados, creo que esta función es significativa.

Vault guardará de forma segura la clave privada de la CA raíz. Puede obtener el archivo pem de ca a través de una solicitud http.

Vault debe configurarse con direcciones para acceder a CA y CRL (lista de revocación de certificados).

Cree una CA intermedia.

Almacene el contenido csr en el archivo example_lob.csr y solicite a la CA raíz que firme la CA intermedia.

Después de obtener los certificados de CA intermedia emitidos por la CA raíz, guárdelo como un archivo e impórtelo. El último paso es configurar CA/CRL, igual que el anterior.

Antes de comenzar a emitir certificados al servidor, debe crear una función y luego podrá emitirlos.

Una vez que obtenga la clave privada y el crt, puede colocarlos en el servidor para realizar pruebas. Creo que usar este grunt-connect-proxy puede hacer que las pruebas sean más rápidas.

Otra característica de Vault que creo que es muy buena es que puede usar LDAP como backend de autenticación. Siento que la presión de mantenimiento es mucho menor :) Puedes probar el resto de las características tú mismo. y también estamos considerando usarlo. Reemplace RatticDB para guardar algunas credenciales, como claves privadas. Puedo mostrar los resultados del pico en la próxima reunión de seguridad...