Saltar al contenido

Acceder a un entorno es tener una clave, no marcar una casilla

Crunu sella la clave de cada entorno solo para las personas y las máquinas que deben leerlo. Un desarrollador con acceso a development no puede leer production, porque la clave de production nunca se selló para él.

  • Cuatro roles en cada entorno
  • Perfiles de acceso para grupos enteros
  • Solicitudes que aprueba un propietario o un administrador
Ejemplo. Kiteline es una empresa ficticia.

Dos capas de roles

Los roles de organización deciden quién gestiona la organización. Los roles de entorno deciden qué recibe alguien dentro de un entorno, y se apoyan en claves.

  • OwnerTodo lo que puede hacer un administrador, además de nombrar administradores y propietarios y cambiar los ajustes de la organización. El último propietario no se puede eliminar.
  • AdminGestiona miembros, máquinas, tokens y el registro de auditoría, y llega a todos los entornos compartidos a través de la clave de recuperación de la organización.
  • MemberRecibe solo lo que se le concede: roles de entorno, asignados directamente o a través de perfiles de acceso.
Roles de entorno
Rol de entornoLeeModificaRecibe
EditorTodos los archivosSíLa clave del entorno
ReaderTodos los archivosNoLa clave del entorno
Specific filesArchivos seleccionadosNoUna copia sellada de esos archivos
OperatorNadaNoNinguna clave; añade máquinas

Invita y después comprueba la huella

Una invitación es un enlace con un secreto dentro, válido hasta 7 días. El nuevo miembro crea una cuenta y ve una huella; la comparas con él, por ejemplo en una llamada, y solo entonces le das acceso.

  • La clave es de la persona que invitasteComparar la huella confirma que nadie en medio, tampoco el servidor, ha cambiado la clave a la que vas a dar acceso.
  • Invitaciones firmadasEl registro de la invitación lo firma la persona que la creó.
  • Correo confirmado con un códigoCuando el servidor tiene configurado el correo, el nuevo miembro confirma su dirección con un código.

Leer la documentación

Ejemplo. Kiteline es una empresa ficticia.

Concede una vez para todo el grupo

Un perfil de acceso es un conjunto con nombre de pares entorno-rol, como Developers: Editor en development y staging. Cámbialo una vez y el cambio se aplica a todos sus miembros.

  • Cada versión va firmadaCada cambio en un perfil es una nueva versión firmada, así que puedes saber quién cambió qué.
  • Directo o a través de un perfilLa lista de acceso del miembro muestra de dónde viene cada rol: asignado directamente o a través de un perfil de acceso.
  • Espacio para equipos grandesLa lista de acceso de un entorno admite hasta 5000 entradas.

Leer la documentación

Ejemplo. Kiteline es una empresa ficticia.

Deja que la gente pida lo que necesita

Un miembro pide acceso indicando un motivo. La solicitud aparece en Access requests y en el contador de Pending actions, donde un propietario o un administrador la aprueba o la rechaza.

  • Solicitudes de los operadoresUn operador, que nunca ve los valores, puede solicitar acceso para una máquina o para un miembro.
  • Cada miembro ve solo sus entornosEl servidor solo le muestra a un miembro los entornos de su lista de acceso. Los propietarios y los administradores ven todos los entornos compartidos.
  • Se puede volverUn miembro dado de baja puede volver a ser admitido sin romper el historial de firmas.

Leer la documentación

Ejemplo. Kiteline es una empresa ficticia.

Lo que el control de acceso no cubre

Los roles deciden quién recibe una clave. No caducan por sí solos y no pueden recuperar lo que alguien ya leyó.

  • Sin fecha de fin para las personasEl acceso se mantiene hasta que lo retiras. Las invitaciones, los enlaces de acceso, los tokens, las concesiones de las máquinas y el acceso de emergencia (break-glass) sí caducan.
  • Sin SSO ni SCIMLos miembros inician sesión con una contraseña, una Secret Key y un segundo factor. No hay inicio de sesión único ni sincronización con directorios.
  • Los administradores llegan a todo lo compartidoLos propietarios y los administradores pueden abrir todos los entornos compartidos a través de la clave de recuperación de la organización. Asigna esos roles a pocas personas.
  • Leer es poder copiarQuien descifra un valor puede copiarlo. Retirar el acceso no borra lo que ya se vio.

Todas las limitaciones conocidas

Respuestas a preguntas frecuentes

¿Algo más? Escríbenos a support@crunu.com

¿Alguien con acceso a development puede leer production?

No. Cada entorno tiene su propia clave, y la clave de production solo se sella para las personas y las máquinas con acceso a production.

¿Qué diferencia hay entre Reader y Specific files?

Un Reader lee todos los archivos del entorno. Quien tiene Specific files recibe una copia sellada solo de los archivos que elegiste, que se actualiza cuando se guarda el entorno, y no puede modificarlos.

¿Puedo dar acceso a un compañero durante una semana?

No con una fecha de fin. El acceso de las personas se mantiene hasta que lo retiras. Para entregar unos pocos archivos durante un tiempo limitado, usa en su lugar un enlace de acceso con caducidad.

¿Crunu admite SSO o SCIM?

No. No hay inicio de sesión único para las personas ni sincronización con directorios.

¿Por qué comprobar una huella cuando alguien se une?

Confirma que la clave a la que das acceso pertenece a la persona que invitaste, y no a alguien en medio, tampoco al servidor.

Configura los roles antes de que crezca el equipo

Crea tu organización, añade un perfil de acceso para los desarrolladores e invita a la primera persona.

Gratis durante el acceso anticipado. Lee el modelo de seguridad