Define los ámbitos antes de la creación
Concede a una clave solo las acciones y los recursos que su trabajo requiere. Una integración de monitorización puede necesitar acceso de lectura; una herramienta de despliegue puede necesitar un conjunto definido de operaciones de ciclo de vida. Mantén la autoridad de facturación separada cuando sea posible.
Revela con cuidado y guarda de forma privada
Una clave real debe mostrarse mediante un flujo de creación seguro, protegerse en reposo y excluirse de URLs, de los paquetes del navegador y del control de código fuente. Registra el propietario, el propósito y la hora de creación sin exponer el secreto en sí.
Haga práctica la revocación
Emite credenciales separadas por integración para que una pueda revocarse sin detenerlo todo. Rota de forma deliberada y verifica que la clave antigua ya no funcione. Investiga el uso inesperado con registros de auditoría acotados.
Ponga a prueba los límites
Una prueba de lanzamiento útil incluye una operación permitida, una operación prohibida, una clave caducada o revocada y una solicitud fuera del límite de recursos de la clave. La autenticación por sí sola no es autorización.
Política de claves candidatas
El contrato de API describe hasta diez claves activas por cuenta, con propósitos con nombre, caducidad opcional y restricciones de dirección de origen. Los ámbitos separan lectura, gestión de servidores, facturación y control total. Un flujo de creación debe mostrar el secreto una sola vez y conservar únicamente una representación de verificación debidamente protegida.
Audita sin exponer la solicitud
Un registro de auditoría útil puede incluir el identificador de clave, la ruta, la hora y el resultado sin conservar contraseñas ni cuerpos de solicitud completos. El acceso al registro también necesita protección. Define la retención y la exportación en lugar de conservar indefinidamente un historial operativo sensible.
Asigna a cada automatización su propia credencial
Un verificador de copias de seguridad, un trabajador de despliegue y una integración de facturación no deberían compartir la misma clave de acceso completo. Asigne un nombre a cada clave según su función, otorgue el menor alcance y registre quién es su propietario. Los grupos previstos son lectura, servidores, facturación y completo; su asignación exacta de operaciones debe probarse cuando API esté disponible.
Creación, almacenamiento y rotación
El modelo de cuenta propuesto permite hasta diez claves activas. Muestre un secreto nuevo una sola vez y luego conserve solo el verificador del lado del servidor necesario para autenticarlo. Guarde la copia del cliente en un gestor de secretos o en un entorno de servicio protegido. Rote introduciendo un reemplazo, comprobando el worker dependiente y luego revocando la clave antigua; nunca coloque una clave en un URL público ni en un paquete del navegador.
Revocar el acceso, no la evidencia
Deshabilitar una clave debería detener las solicitudes futuras y preservar un registro de seguridad limitado de su uso pasado. Si una credencial puede haberse filtrado, revócala con prontitud, examina los recursos afectados y reemplaza cualquier secreto relacionado. Una lista de claves debería mostrar un identificador seguro y metadatos de último uso en lugar de secretos en texto plano recuperables.
Un poco más de claridad.
¿Puede esta página crear una clave API funcional?
No. La creación de claves requiere un backend de cuenta autenticado; esta página informativa no emite credenciales.