Exigir claves de acceso
Exige que todos los miembros tengan una clave de acceso antes de abrir tu cuenta: quién queda exento, qué ven los miembros y cómo ayudar a alguien que ha perdido todas sus claves.
Por qué importa
Tanto las contraseñas como los códigos de autenticación pueden entregarse a una página de inicio de sesión falsa pero convincente. Las claves de acceso no: el navegador las vincula al dominio de Kit, así que nunca ofrece la credencial al sitio de un atacante. Exigir una en toda la cuenta limita el acceso mediante contraseñas o códigos obtenidos por phishing.
Activa el requisito en Configuración → Seguridad. La página requiere el permiso gestionar la seguridad, incluido en los roles Administrador y Analista de seguridad; consulta Roles del equipo.
Qué hace exactamente la política
Exigir claves de acceso no cambia cómo se inicia sesión en Kit. Cambia lo que la sesión puede abrir: la cuenta permanece cerrada hasta que la sesión se haya verificado con una clave de acceso. Las demás cuentas no se ven afectadas.
La distinción es intencionada. Una persona puede pertenecer a muchas cuentas de Kit y las claves pertenecen a la persona, no al espacio de trabajo. Obligar a iniciar sesión de una forma permitiría que tu cuenta dictara cómo entra alguien en el espacio de un cliente o en uno personal. Un control de acceso no: cada miembro inicia sesión como prefiere y se detiene ante tu puerta hasta demostrar una clave.
También significa que perder una clave de acceso impide a la persona entrar en una cuenta, no utilizar su identidad de Kit. Aún puede iniciar sesión, acceder a su perfil y trabajar en las cuentas que no exigen una clave de acceso.
Antes de activarlo
Debes tener una clave de acceso. El botón Exigir claves de acceso no hace nada hasta que la tengas; Kit responde: «Primero registra una clave de acceso en tu cuenta: nadie está exento de este requisito, tú tampoco».
El propietario nunca queda exento. La obligación de SSO de Kit sí lo exime porque un proveedor de identidad puede fallar en el servidor y dejar a todo el mundo fuera; una clave de acceso no falla así. Un propietario exento se convertiría en la credencial más débil de la cuenta, justo la que merecería la pena suplantar.
Añade primero la tuya en Configuración de la cuenta → Claves de acceso y vuelve después. La página Seguridad te avisa hasta que lo hagas.
Warning
Activar el requisito sin tu propia clave te impediría entrar en tu cuenta en la siguiente petición. Precisamente por eso Kit no lo permite.
Activarlo
La página Seguridad incluye una tabla de preparación con todos los miembros actuales:
| Estado | Significado |
|---|---|
| Preparado | Ya tiene al menos una clave de acceso |
| SSO exigido | Entra mediante una conexión SAML donde está activado Exigir SSO; consulta la excepción siguiente |
| Sin clave de acceso | Se bloqueará y recibirá un correo en cuanto actives el requisito |
Así no tienes que activarlo a ciegas. Antes sabes exactamente a quién detendrá. Si todo el mundo ya tiene una, la tabla también lo indica.
Quién queda exento
Un solo grupo: quienes inician sesión mediante SSO SAML en una conexión donde has activado «Exigir SSO». Para estas personas, Kit ya rechaza cualquier credencial que no proceda de tu proveedor de identidad, por lo que el requisito no aporta nada más.
Important
Esta excepción depende de quién controla la autenticación, no de su seguridad: si tu proveedor de identidad acepta una contraseña, la excepción también. Configura esa política en tu IdP.
Nadie más queda exento:
| No queda exento | Por qué |
|---|---|
| Propietarios y administradores | No hay excepciones por rol. Quien tiene más acceso es quien más debe demostrar. |
| SSO sin «Exigir SSO» | Si las contraseñas aún sirven para ese dominio, la delegación no es real. Solo cuenta la obligación. |
| Iniciar sesión con Google o GitHub | No controlas ni al proveedor ni su MFA, y el alta con OAuth de Kit conserva una contraseña utilizable. |
| Google One Tap | El mismo motivo: OAuth de consumo, no tu proveedor de identidad. |
| Códigos de doble factor | Pueden sufrir phishing. Un código no es una clave de acceso. |
| Navegadores de confianza | Confiar en un navegador omite un aviso de doble factor. No demuestra nada sobre claves de acceso. |
La excepción se evalúa en tiempo real, no queda fijada al iniciar sesión. Si relajas la obligación de SSO, los miembros antes exentos pasan a estar sujetos al requisito en su siguiente petición.
Qué ocurre de inmediato
El requisito se aplica desde que lo guardas. No hay periodo de gracia ni despliegue gradual: una persona con una sesión abierta encuentra el control en la siguiente carga de página.
| Efecto | Detalle |
|---|---|
| Miembros bloqueados | Ven una página titulada «[Cuenta] exige una clave de acceso», con el alta integrada, un enlace Cambiar de cuenta y la vuelta al destino original. |
| Membresía | No cambia. Nadie se elimina ni se modifican licencias, roles o invitaciones. |
| Otras cuentas | No cambian. El bloqueo solo se aplica a esta cuenta. |
| Nuevos miembros | El correo de invitación añade una línea sobre la clave necesaria, para que lo sepan antes de llegar y no al abrir la puerta. |
Solo reciben un correo quienes deben actuar. El asunto es «Añade una clave de acceso para seguir usando [Cuenta]» y explica qué ha cambiado, quién lo hizo, que basta con una clave y sirve el desbloqueo del dispositivo, además de ofrecer un enlace directo al alta. Quienes ya tienen una y quienes están exentos por SSO no reciben nada porque no se les pide ninguna acción.
Tú recibes un justificante distinto con los recuentos: cuántas personas recibieron el correo, cuántas ya tenían una clave y cuántas dependen de tu proveedor de identidad.
Tokens de API y asistentes de IA
No se revoca nada. Un token de API o una conexión de un asistente de IA actúa en nombre de alguien, pero no puede presentar una clave de acceso. Por eso Kit le hace una pregunta más sencilla: ¿la persona que lo creó tiene registrada una clave?
Mientras la respuesta sea no, los tokens de API de esa persona responden con 403 y sus conexiones MCP se rechazan. En cuanto registra una clave, ambos vuelven a funcionar con las mismas credenciales: no hay que emitir otro token, volver a autorizar el asistente ni tocar datos.
Note
Es una comprobación menos estricta que la del navegador: una sesión debe demostrar una clave de acceso, mientras que el token solo tiene que pertenecer a alguien que tenga una. Un token no puede realizar una ceremonia WebAuthn, así que es lo máximo que permite esa superficie.
Cuando alguien pierde todas sus claves de acceso
Ya no tiene sus dispositivos, así que no puede confirmar una clave. Tampoco puede registrar otra por su cuenta, porque para cambiar las claves se necesita una existente. Emite un pase de reinscripción desde su fila en la tabla de cumplimiento.
Tú nunca ves el pase. Kit lo envía directamente al miembro, en su idioma; no aparece en ninguna pantalla, mensaje ni registro del lado de quien lo emite. Tu confirmación solo indica que se ha emitido. La emisión queda registrada en el historial de auditoría, con quién la solicitó y para quién.
El miembro abre el enlace con su sesión iniciada. Después:
| Lo que hace | Qué implica |
|---|---|
| Abrir el enlace del correo | Nada: solo muestra una página de confirmación. Un escáner de enlaces o una vista previa del correo no puede consumir el pase. |
| Confirmar en esa página | El pase se consume y se abre una ventana de 15 minutos en la que Kit permite registrar una clave en vez de exigir la que ya no puede proporcionar. |
| Registrar una clave nueva | La ventana se cierra y el miembro recupera el acceso. |
El pase es de un solo uso y válido durante 24 horas. Emitir otro cancela inmediatamente cualquier pase pendiente para esa persona. Un enlace caducado, consumido, sustituido o abierto por quien no corresponde muestra siempre la misma página neutra, sin explicar el motivo. Si alguien dice que el enlace «ya no es válido», solo necesita otro.
Danger
Un pase de reinscripción permite sortear tu control más fuerte. Antes de emitirlo, comprueba por otro canal que hablas con la persona correcta. Usa un canal independiente, como una llamada telefónica. No te fíes solo de una respuesta por correo.
Desactivarlo
Haz clic en Dejar de exigir claves de acceso. Quienes no tienen una podrán abrir la cuenta en su siguiente petición, los tokens de API y las conexiones MCP rechazados volverán a funcionar de inmediato, y las claves ya registradas permanecerán donde están. No hay que volver a emitir nada en ningún sentido.
En resumen
- Registra primero una clave de acceso en tu cuenta: el botón no funcionará hasta que lo hagas
- Revisa la tabla de cumplimiento y localiza quién aparece como Sin clave de acceso
- Si cuentas con la excepción de SSO, comprueba que la conexión tiene activado Exigir SSO
- Activa el requisito y revisa el recuento de la confirmación antes de aceptarla
- Comprueba si los miembros bloqueados ya se han registrado desde la propia página; recibieron un enlace directo por correo
- Comprueba por teléfono, nunca solo por correo, la identidad de quien solicite un pase de reinscripción
- Recuerda que los tokens de API y las conexiones MCP se reanudan solos cuando su propietario registra una clave