Imagina este escenario. Estás creando una aplicación y necesitas una clave de API para conectar a un servicio, una contraseña de base de datos o una clave de cuenta de almacenamiento. Así que la pones directamente en tu código, tal vez en un archivo de configuración o una variable de entorno. Funciona y todo va bien hasta que subes ese código a GitHub o compartes un cuaderno con un compañero con un compañero. Y así de repente, tu secreto ya no es tan secreto. Si ese código cae en las manos equivocadas, todo tu sistema queda expuesto. Azure Key Vault es la herramienta que soluciona ese problema. Te ofrece un lugar seguro para almacenar secretos y que nunca terminen en tu código. Pero aquí está lo que la mayoría hace malo. Solo tener un Key Vault no te hace seguro automáticamente. La forma en que lo configuras, controlas el acceso y asignas permisos importa igual. Al final de este episodio, sabrás qué es realmente Key Vault, qué puedes almacenar, cómo funciona el acceso y el mayor error que podría dejar tus secretos expuestos.

Todo en lenguaje sencillo sin tecnicismo son lo que necesitas saber. Entonces, ¿qué es exactamente Azure Key Vault? ¿Qué es Azure Key Vault? Aquí tienes la definición más simple. Azure Key Vault es una caja fuerte digital en la nube para tu secreto. Es un servicio administrado de Microsoft para claves de API, contraseñas de bases de datos, cadenas de conexión, claves de cifrado y certificados en un lugar central. No tienes que preocuparte por la infraestructura porque Azure se encarga de las actualizaciones, el tiempo de actividad y la seguridad. Tú solo lo usas. Piénsalo como un edificio de eficiente. Tienes estaciones de trabajo, salas de reuniones y archivadores. Pero en el sótano hay una caja fuerte donde guardas lo importante. Llaves maestras, efectivo, documentos legales. Nadie entra sin permiso de autenticación. Y cada vez que alguien abre la puerta queda registro. Eso es Key Vault.

La sala asegura en el sótano de tu arquitectura de Azure. Al contrario, haz eso con la server. Hace 20 años, si necesitabas una contraseña de base de datos, la escribías directamente en un archivo de configuración, una variable de entorno o, peor aún, en texto plano en tu código. Si alguien accedía a ese servidor, lo tenía todo. Y si necesitabas rotar esa contraseña, tenías que actualizarla en todas partes. Cada archivo de configuración, cada entorno, cada despliegue, era una pesadilla. Key Vault cambia todo eso. En lugar de dispersar secretos en tu código y archivos de configuración, los almacenas en un lugar central. Tus aplicaciones lo solicitan durante la ejecución solo cuando los necesite. Y como todo está centralizado, puede rotar un secreto en un solo lugar y cada aplicación que lo utilice obtendrá el nuevo valor automáticamente sin cambios de código ni redistribuciones. El punto es que Key Vault no es solo un administrador de contraseñas para tus aplicaciones.

Es un servicio central. Cada servicio de Azure puede integrarse con él. App Service Functions, AKS, Data Factory, Synapse y GAPS y las canalizaciones de DevOps saben cómo comunicarse con Key Vault. Se convierte en la columna vertebral de tu arquitectura de nube de seguro. Y una vez que lo configuras correctamente, dejas de preocuparte por completo sobre la gestión de credenciales. Te puedes almacenar. Ahora que sabes qué es Key Vault, hablemos de lo que realmente puedes guardar dentro. Tienes tres categorías principales. Secretos, claves y certificados. Cada una hace algo diferente. Y entender la diferencia te ayuda a usar Key Vault de la manera correcta. Comencemos con los secretos. Esto es lo que la gente alnacena con más frecuencia. Los secretos son cadenas de conexión, claves de API, contraseñas de bases de datos, claves de cuentas de almacenamiento, básicamente todas las credenciales cotidianas que tus aplicaciones necesitan para hablar con otro servicio.

En lugar de incluirlos en tu código archivo de configuración, los colocas en Key Vault. Tu aplicación los obtiene en tiempo de ejecución y nadie los ve nunca en texto plan. Piénsalo como un cajón bajo llave en tu archivador digital. Los siguientes son las claves. Estas son claves de cifrado para datos en report. Si usas claves administradas por el cliente para Azure Storage, bases de datos SQL o para cifrar discos de máquinas virtuales, esas claves pueden residir en Key Vault. Eso te da control total sobre quién puede usarlas y cuándo. Y si necesitas claves respaldadas por hardware para el cumplimiento, el nivel premium te cubre con protección HCM. Luego tenemos los certificados. Certificados TLS y SCL para tus aplicaciones web, API y servicios internos. Key Vault puede almacenarlos, gestionar su ciclo de vida e incluso renovarlos automáticamente cuando están cerca de SPIN. Eso es un salvavidas para cualquiera que haya tenido un certificado que caducó a las 3 AM de un domingo.

Aquí hay un ejemplo real. Imagina que tienes una aplicación web que necesita una cadena de conexión a una base de datos y una clave de API para un servicio de terceros. A la antigua pondrías ambos en tu archivo JSON de configuración de la aplicación. Probablemente, si ese archivo termina en tu repositorio, cualquiera con acceso al código puede ver las credenciales de tu base de datos. Con Key Vault almacenas ambos valores como secretos. Tu aplicación los obtiene al inicio y nunca aparecen en tu código fuente. ¿Necesitas rotar la contraseña de datos? Actualízala en Key Vault. La aplicación obtiene el nuevo valor automáticamente en el siguiente reinicio, sin cambios de código, sin redespliegue. Algo que toma la gente por sorpresa es que el control de versiones está integrado. Cuando actualizas un secreto, Key Vault no sobreescribe el valor anterior, creado en la diversión. Las versiones antiguas se conservan para que puedas revertir si algo sale mal.

Eso es increíblemente útil durante los incidencias. Puedes volver rápidamente a un secreto anterior sin tener que recordar cuál era el valor antiguo. Puedes almacenar los tres tipos, secretos claves y certificados en el mismo almacén. Pero la mejor práctica es separar por entorno. Tener un almacén para desarrollo, uno para pruebas y uno para producción. Esto evita que alguien use accidentalmente un secreto de producción en un entorno de desarrollo y limita el alcance si un almacén se ve comprometido. Pero almacenar secretos es solo la historia. La verdadera pregunta es quién tiene acceso a ellos. ¿Cómo funciona el acceso? Hablemos de quién puede entrar. Key Vault tiene dos formas diferentes de controlar el acceso a lo que hay dentro y la que elijas importa mucho. El primer modelo son las políticas de accesorio. De la forma antigua. Creas políticas directamente en el almacén y asignas permisos a usuarios o grupos específicos para tipos de datos, secretos, claves o certificados.

El problema es que estas políticas están vinculadas directamente al almacén. Si tienes varios almacenes, debes administrar las políticas en cada uno por separado. No escala bien. Microsoft ahora recomienda no usarlas porque tienen problemas de seguridad conocidos. No admiten la gestión de identidades con privilegios y pueden crear rutas de escalada de privilegios inesperadas. El segundo modelo es Azure Base de Vaxe, control de acceso basado en roles. Esta es la forma moderna. Utiliza identidades de EntraID y es consistente con la forma en que administras permisos en todo Azure. Si ya sabes cómo dar acceso a alguien a una cuenta de almacenamiento o una máquina virtual, ya sabes cómo darle acceso a Key Vault. Mismo sistema, mismo patrón. Aquí está la regla de oro. Privilegios mínimos. Da solo acceso mínimo que alguien necesita. Nada más. Si alguien solo necesita leer secretos, no le des permiso para crearlos o eliminarlos.

Si alguien solo necesita administrar certificados, no le des acceso a las claves. Déjeme explicarte los roles clave. Tienes el lector de Key Vault. Esto permite a alguien listar secretos pero no leer sus valores. Usuarios secretos de Key Vault. Esto permite a alguien leer realmente los valores de los secretos. Y el oficial de secretos de Key Vault. Esto permite a alguien crear, actualizar y eliminar secretos. Note el patrón. Cada rol es específico para los datos dentro del almacén, no para el almacén en sí. Ahora, compare eso con los roles generales. Propietario, colaborador y lector. Esto se aplica en el almacén como recurso, no a los datos que contiene. Un propietario puede eliminar todo el almacén. Un colaborador puede modificar la configuración. Pero ninguno de estos roles por sí solo da acceso a los secretos internos. Esa es una capa de permisos distinta y ese es el punto clave. El control de acceso es como un pastel de las capas.

Necesita acceso al almacén en sí, esa es la primera capa, y necesita acceso a los datos dentro del almacén, esa es la segunda. Ambos deben concederse por separado. La mayoría de los principiantes solo piensan en la primera capa y en la segunda. Ahí es donde comienzan los problemas. El error de seguridad número uno. Este es el asunto. La mayoría de la gente ve el rol de colaborador de Key Vault y piensa que es seguro. Ven la palabra colaborador y asumen que pueden administrar la configuración pero no tocar los secretos. La propia documentación de Microsoft decía originalmente exactamente este error no le permite acceder a secretos, claves o certificados. Excepto que eso no es de todo cierto. Un usuario con el rol de colaborador de Key Vault puede modificar las políticas de acceso del almacén. Y si ese almacén todavía usa políticas de acceso heredadas, lo cual hace mucho, simplemente pueden otorgarse acceso de lectura total a cada secreto, clave y certificado.

No se necesita ninguna explotación especial ni una de que parchear. Es simplemente como funciona el permiso. Los investigadores de seguridad de Datadoc lo demostraron en 2020. Demostraron que un colaborador podía escalar el acceso total a los datos en cualquier almacén que use políticas de acceso heredadas. La respuesta de Microsoft fue interesante. Dijeron que esto no es una vulnerabilidad porque los colaboradores están diseñados para gestionar políticas de acceso, pero actualizaron la documentación para advertir explícitamente que el rol puede otorgarse acceso al plano de datos. Por lo tanto, esto no es un error en Key Vault, es una trampa de configuración. Y atrapa incluso equipos experimentados porque el nombre del rol suena inofensivo. Colaborador no suena como alguien que pueda leer las contraseñas de su base de datos, pero en la práctica pueden hacerlo. Piensa en el riesgo. Si un atacante compromete una cuenta con el rol de colaborador en su almacén de claves, no necesita entrar por la fuerza.

No necesita descifrar el cifrado. Solo modifican la política de acceso, se otorgan acceso de lectura y exfiltran silenciosamente todos los secretos almacenados, cadenas de conexión, claves API, certificados, todo. Todo. Y debido a que los cambios en la política de acceso son actividades administrativas normales, es posible que no activen ningún alerta. Entonces, uso. Primero, use RBACC de Azure para el acceso al plano de datos en lugar de políticas de accesoriedad. RBACC para la administración del almacén de los datos que contiene. Segundo, nunca otorgues el rol de colaborador de Key Vault a nadie que no lo necesite absolutamente. Tercero, si ya tienes usuarios con ese rol, auditorialos hoy mismo. Reemplace al colaborador con roles más específicos como usuario de secretos de Key Vault o administrador de secretos de Key Vault. Existe un segundo error que agrava este. Poner todos tus secretos en un solo almacén.

Tienes un almacén para todo. Desarrollo, pruebas, preproducción, producción y todas tus aplicaciones y ese almacén se ve comprometido. Todo queda expuesto. Es un punto único de FAI. Hablaremos más sobre la estrategia de almacenes múltiples en un momento, pero el principio es simple. No pongas todos los huevos en la misma canasta, especialmente cuando esa canasta contiene las llaves de toda tu infraestructura. Identidad administrada el estándar de oro. No sé cómo haces esto correctamente. Hablemos de la mejor manera de acceder a Key Vault. Un problema fundamental. Para tener credenciales de Key Vault, tu aplicación necesita autenticarse, pero para autenticarse necesita credenciales donde almacena las credenciales que tu aplicación usa para obtener credenciales. Es el dilema del huevo y la gallina. La vieja respuesta era una entidad de servicio con un secreto de cliente, pero ese secreto debe vivir en alguna parte, tal vez en un archivo de configuración, variables de entorno o un flujo de despliegue.

Y ahora vuelves al mismo problema. Solo has movido el secreto a otro lugar. La identidad administrada resuelve esto por completo. Así es como funciona. Cuando habilitas la identidad administrada en un recurso de Azure, como una aplicación web, una función o una máquina virtual, Azure crea automáticamente una identidad para ese recurso en Entry.id. Esa identidad es administrada completamente por Azure, sin credenciales que crear, sin secretos que rotar, nada que almacenar. El recurso simplemente tiene una identidad que Azure reconoce. Existen dos tipos. La identidad administrada asignada por el sistema está vinculada a un recurso específico. Si eliminas el recurso, la identidad también desaparece. Comparten un ciclo de vida, lo que simplifica la administración. La identidad administrada asignada por el usuario es una identidad independiente que puedes asignar a múltiples recursos. No comparte ciclo de vida con ninguno de ellos, por lo que es útil cuando necesitas la misma identidad en varios servicios.

Así es como se ve esto en la práctica. Tienes una aplicación web que necesita leer una cadena de conexión de base de datos desde Key Vault. Habilitas la identidad administrada asignada por el sistema en la aplicación web. Luego, otorgas esa identidad, el rol de usuario de secretos de Key Vault en tu almacén. Esa, sin cadenas de conexión en el código, sin secretos de cliente en archivos de configuración. La aplicación web se autentica en Key Vault usando su identidad administrada y Azure maneja toda la gestión de credenciales en segundo plano. Esto es lo más cercano a una autenticación sin credenciales en Azure. Es un cambio radical para la seguridad porque elimina el vector de ataque más común, el robo de credenciales. Si no hay credenciales que robar, no hay nada que un atacante pueda comprometer. Permítame darles un ejemplo en el mundo real. Imagina un proceso de datos en Synapse que necesita acceder a una cuenta de almacenamiento.

Igualmente, uno almacenaba la clave de la cuenta de almacenamiento de la configuración del proceso. Si alguien obtenía acceso a ese proceso, tiene la clave. Con la identidad administrada, el espacio de trabajo de Synapse tiene una identidad. A esa identidad se le concede acceso a Key Vault donde se almacena la clave de la cuenta de almacenamiento. El proceso obtiene la clave en tiempo de ejecución, la usa y nunca la almacena en ninguna parte, sin claves en el código, sin secretos en la configuración del proceso. Al combinar la identidad administrada con la RBA a base y al principio de menor privilegio, se obtiene una base segura para cualquier carga de trabajo en Azure. Sus aplicaciones se autentican sin credenciales. Acceden solo a lo que necesitan y cada acceso queda registrado y es auditable. Es el patrón que Microsoft recomienda para casi cualquier escenario. Una vez que comiencen a usarlo, se preguntarán por qué lo hacían de otra manera.

Costos y estrategia de múltiples almacenes. Entonces, hablemos de costos. Aquí es donde la mayoría de la gente se sorprende. ¿Cuánto cuesta realmente Azure Key Vault? El modo de precios es sencillo. No hay tarifa de almacenamiento por secreto. No paga por cada contraseña o clave API que almacenan. En cambio, paga por operación. Para el nivel estándar, son los 3 centavos por cada 10.000 operaciones. Una llamada para obtener un secreto cuenta como una operación. También lo es crear un secreto o listar lo que hay en el almacén. Para una aplicación típica de tamaño pequeño o mediano, eso suma apenas centavos al mes. Literalmente centavo. Comparen eso con AWS Secrets Manager. Cobran 40 centavos por secreto al mes solo por almacenarlo o más cargos adicionales por llamadas al app. Si tienes 100 secretos, son 40 dólares al mes antes de haber leído siquiera uno de ellos. Con Azure Key Vault, 100 secretos con un uso moderado podrían costarle 15 centavos.

La diferencia aumenta rápidamente a gran escala. Ahora bien, existe un nivel prim. Este añade claves respaldadas por HCM para cargas de trabajo que necesitan el mayor nivel de garantía criptográfica. Piensa en transacciones financieras, datos de salud o sistemas gubernamentales. El costo por operación es más alto. Alrededor de 15 centavos por 10.000 operaciones para tipos de clavanzados más una tarifa mensual por clave HCM. Pero para la mayoría de las aplicaciones, el nivel estándar es más que suficiente. Aquí está la sorpresa en los costos que toma la gente desprevenida. Para una aplicación web típica con un puñado de secretos y unos miles de operaciones al mes, Key Vault cuesta menos de un dólar. Gastará más en el café que tome mientras lo configura. Pero hay una estrategia que importa más que el costo. ¿Cuántas bóvedas utiliza? El enfoque inteligente es una estrategia de múltiples pruebas.

Use bóvedas separadas para desarrollo, pruebas, preproducción y producción. Esto evita el accidente más común. Alguien ejecutando un script de prueba que lea accidentalmente una base de datos de producción porque la cadena de conexión estaba en la misma bóveda. Cuando los entornos están separados, ese error se vuelve imposible. También debe separar por unidad de negocio o dominio de cumplimiento. Si maneja datos de tarjetas de pago, coloque esos secretos en su propia bóveda. Las cadenas de trabajo empresariales generales bañan otra y los datos de salud en la tercera. No se trata de ser difícil, se trata de limitar el radio impacto. Si una bóveda se ve comprometida, solo los secretos en esa bóveda quedan expuestos. El resto de su infraestructura permanece seguro. Dos redes de seguridad integradas que siempre debería gritar. La eliminación temporal significa que si alguien borra un secreto no desaparece permanentemente.

Entra en un estado recuperable por un periodo de retención que usted elige hasta 90 días. La protección contra pulga un paso más cerca. Nadie puede eliminar permanentemente la bóveda o su contenido hasta que expire ese periodo de retención. Juntos, previenen el tipo de pérdida de datos accidental que quita el sueño a los equipos de seguridad. ¿Cómo se conecta todo? Vamos a unir todo esto y ver cómo encajan las piezas. Keyboard no es una isla. Es el sistema nervioso central para los secretos en su arquitectura de Azure. Cuando entiende cómo fluye todo el sistema, todo encaja perfectamente. Esto es lo que sucede cuando una aplicación necesita un secreto. La aplicación lo solicita usando su identidad administrada. Esa identidad ya está registrada en Entra ID. Azure la crea automáticamente cuando habilitó la identidad administrada en el recurso. Entra ID valida que la identidad sea legítima luego pasa la solicitud a Keyboard.

Keyboard verifica los permisos de rebaje asignado. Si la identidad tiene el rol correcto, por ejemplo, usuario de secretos de Keyboard, el secreto es devuelto. Todo esto sucede en milisegundos. La aplicación nunca viene a creenciar, nunca más en una contracción. Simplemente obtiene el valor que necesita. Ahora piensa en cuántos servicios de Azure pueden conectarse a esto. App Service Functions, IKS, Data Factory, Synapse, Logic Apps, DevOps, Pipelines, todos. Saben cómo comunicarse con Keyboard. Puede configurar una aplicación web para que haga referencia al secreto directamente en la configuración de la aplicación. Puede configurar una canalización de Data Factory para obtener una clave de cuenta de almacenamiento de Keyboard Keybusy. Puedes configurar un clúster de Kubernetes para obtener secretos usando el controlador CCI de Keyboard. Cada servicio se integra igual usando el mismo sistema de identidad, los mismos roles RBAs y el mismo registro de auditoría.

El patrón DCI-CD es especialmente potente. Tus pipelines obtienen los secretos de Keyboard durante el despliegue. Nunca los almacenan en variables de pipeline y en secretos del repositorio. Si necesitas rotar la contraseña de una base de datos, la actualizas en Keyboard. La próxima vez que se ejecute el pipeline tomará el nuevo valor automáticamente. Sin cambios en el pipeline, sin cambios de código, sin redespliegues. Aquí es donde todo cobra sentido. Una vez que configuras Keyboard con identidad administrada y RBA-C, dejas de preocuparte por la gestión de credenciales. Tus aplicaciones

lo noten. Los certificados se renuevan sin emergencia a la noche. El sistema maneja todo en segundo plano. Esta es la postura de seguridad que realmente importa. La identidad es el perímetro, no la red. No importa si alguien está dentro o fuera de tu red virtual. Lo que importa es si tienen una identidad válida con los permisos correctos. Keyboard hace cumplir esto por diseño. Cada solicitud de acceso pasa por la autenticación de EntraID y la autorización RBA-C, sin importar de dónde provenga. Y todo queda registrado. Cada lectura de secreto, cada operación de clave, cada recuperación de certificado. Puedes ver quién accedió Tienes los datos para investigar. Esto es crítico para el cumplimiento, la respuesta a incidentes y para saber qué sucede en tu entorno. Esa es la belleza de todo esto. Keyboard, EntraID, RBA-C e Identidad Administrada trabajan juntos como un marco de seguridad unificado.

Cada pieza refuerza a las demás. Y cuando están bien configurados, tienes un sistema de gestión de credenciales más seguro y sencillo de operar que cualquier cosa que pudieras construir. Conclusiones prácticas. Entonces, ¿qué deberías hacer ahora mismo? Convirtamos este conocimiento en acción. Aquí hay cosas que puedes abordar esta semana. Pies por tu modelo de permiso. Abre tu Keyboard en el portal, ve a la configuración de acceso y revisa lo que dice. Si ves política de acceso al almacén, esa es la forma antigua. Lo que quieres es el control de acceso basado en roles de Azure. La miración sencilla. Cambia el modelo de permisos y asigna roles RBAX a las mismas personas que ya tenían políticas de acceso. Hazlo hoy. Microsoft lo recomienda y la investigación que mencionamos mostró exactamente por qué. Luego audita todas las cuentas que tengan el rol de colaborador de Keyboard. Abre la hoja IAM en tu almacén y mira quién tiene acceso de colaborador.

Cada persona con ese rol necesita una buena razón. La mayoría de las veces no es así. Reemplace al colaborador con algo más específico. Si alguien solo necesita leer secretos, asígnele usuario de secretos de Keyboard. Si necesitan administrar secretos, use oficial de secretos de Keyboard. El objetivo es cerrar esa ruta de escalada por completo. Luego aproveche la identidad administrada. Cualquier servicio de Azure que necesite acceso a Keyboard debe usarla. Si tiene una aplicación web, una función, una factoría de datos o una máquina virtual que aún usa una entidad de servicio con un secreto de cliente, cambie a identidad administrada. Es más sencillo, más seguro y resuelve el problema del huevo y la gallina que tratamos. Hazur gestión en las credenciales por usted en segundo plano. Una cosa más. Habilite la eliminación temporal y la protección contra purga en cada bóveda. La eliminación temporal está activada por defecto en bóvedas nuevas, pero la protección contra purga no.

Activa. Esa configuración evita que alguien elimine permanentemente una bóveda o su contenido durante el periodo de retención. Ha salvado a más de un equipo de un error desastroso. Y está su llamada a la acción. Analice su enfoque actuales secretos. Encuentre un secreto que aún esté en un archivo de configuración, una variable de entorno codificado en el código. Muévalo a KeyVault esta semana. Solo. Una vez que vea lo simple que es que remueve el resto. La seguridad no es una configuración de una sola. Es una práctica. KeyVault facilita esa práctica, pero solo cuando lo usa correctamente. Las herramientas están ahí. Los patrones están probados. Ahora depende usted implementarlos. Ese es el sistema. KeyVault es su caja fuerte digital, pero es tan segura como los controles de acceso que le ponga. Comience con la auditoría que acabo de escribir. Revise su modelo de permiso, verifique sus asignaciones de colaborador y mueva un secreto a una bóvedad esta semana.

Suscríbase para más consejos de seguridad en la nube Lenguaje Sencillo y comparte esto con alguien que aún almacene secretos en archivos de configuración.