CapordiaNombrar a los responsables antes de distribuir los accesos
Distingue al responsable del expediente de alquiler, a la persona que autoriza el acceso al proyecto y a la que puede aplicar los cambios técnicos en el destino. El responsable de los resultados no necesita necesariamente lanzar procesos ni administrar la máquina. Escribe las operaciones requeridas antes de elegir los permisos: leer un export, depositar entradas, ejecutar una tarea o modificar un entorno.
Verifica después el alcance de los accesos efectivamente entregados. Si no dispones del derecho de crear identidades o de ajustar los permisos, haz que se confirme el procedimiento posible antes de invitar a otros intervinientes. No eludas esta limitación distribuyendo la contraseña de la cuenta Capordia. Compartir el trabajo y gestionar el expediente comercial son dos cuestiones distintas.
Usar una identidad individual y conocer su alcance
Una identidad individual permite retirar el acceso de una persona sin reemplazar el de todo el equipo. En una organización SSH por claves, OpenSSH distingue la clave pública conocida por el servidor y la clave privada en manos del usuario. El documento de coordinación puede contener una referencia o una huella de clave pública; nunca debe contener la clave privada ni su frase de protección.
Dos claves diferentes que dan acceso al mismo sistema no crean automáticamente dos perímetros de archivos distintos. Los permisos dependen de la cuenta y de los mecanismos configurados en la máquina. Decide por tanto si el requisito afecta solo a la autenticación individual o también a la separación de acciones. Para las automatizaciones, prevé una identidad y un propietario explícitos, sin reutilizar discretamente la identidad personal de un compañero.
Verificar el destino antes de presentarle una identidad
En el primer acceso, controla el nombre de la máquina, la cuenta esperada y la huella de su clave de host a partir de una referencia de confianza obtenida en el proceso de entrega de los accesos. Esta clave de host identifica el servidor; es distinta de tu clave de usuario. Un mensaje inesperado de cambio de identidad del servidor merece un examen, no la eliminación automática de la referencia conocida.
OpenSSH conserva claves de host y avisa de sus cambios. Usa esta información con el contexto: reconstrucción anunciada de la máquina, dirección modificada o evento no explicado. Haz confirmar el cambio antes de continuar si no es esperado. El objetivo no es añadir un ritual a cada conexión, sino evitar tratar una alerta de identidad como una simple molestia de visualización.
Ejemplo ficticio: tres intervinientes, tres necesidades
El equipo ficticio «Dossier des ouvrages» prepara una semana de trabajo. Idriss ejecuta los procesamientos del proyecto A, Noémie revisa las exportaciones y Sacha interviene temporalmente para configurar el entorno. El equipo desea los derechos de la tabla, pero debe verificar que sean aplicables con el sistema realmente entregado. No se trata ni de cuentas de cliente existentes ni de funciones de gestión de equipo anunciadas por Capordia.
El principio decisivo es que Noémie no obtiene un acceso de administración para abrir un resultado y que la intervención de Sacha tiene un final. Una aprobación humana por sí sola no configura ningún derecho: el responsable técnico aplica los mecanismos disponibles y, después, cada uno ejecuta los controles previstos. Si la separación deseada no es viable, el proyecto debe adaptar su organización antes de introducir datos que exijan esa separación.
| Interviniente | Necesidad | Perímetro deseado | Revisión |
|---|---|---|---|
| Idriss, explotación | Depositar entradas y lanzar el proyecto A | Espacio de trabajo A, sin administración general | Fin de campaña o cambio de rol |
| Noémie, validación | Leer las exportaciones entregadas | Resultados retenidos, sin modificar las entradas | Fin de validación |
| Sacha, intervención | Preparar el entorno autorizado | Cambio definido y aprobado | Desde la recepción de la intervención |
Preparar una ficha de acceso y probar los límites
La ficha relaciona una persona o una automatización, una identidad técnica, un aprobador, un perímetro, una justificación y un plazo. Conserva la referencia de la clave pública y el procedimiento de retirada sin almacenar los secretos. OpenSSH ssh-keygen permite mostrar la huella de una clave pública: esta referencia ayuda a designar la clave correcta al añadirla o eliminarla, sin copiar su parte privada.
Prueba una acción autorizada sobre un archivo sintético y luego una acción deliberadamente fuera de perímetro, prevista como denegada. Para un rol de lectura, la apertura debe funcionar y un intento de modificación controlado debe ser denegado. No uses datos reales para probar una prohibición de borrado. Verifica también las rutas comunes y el destino de las salidas, porque un derecho correcto sobre una carpeta no garantiza todas las rutas del programa.
Prever la retirada y verificar una nueva conexión
Activa la retirada al final de la intervención, cuando una persona se marche o tras una sospecha de compromiso. El responsable identifica todas las autorizaciones afectadas, incluidos los demás caminos de acceso permitidos para esa misma identidad. Aplica la retirada según la configuración real. La directiva RevokedKeys de OpenSSH es un mecanismo posible entre los documentados; no debe suponerse activa en una máquina sin verificarlo.
Comprueba después que se rechaza una nueva autenticación con la identidad retirada, sin eliminar el acceso de recuperación del responsable. Examina por separado las sesiones ya abiertas, las tareas en curso y las identidades de automatización: retirar una autorización y detener una actividad son decisiones distintas. Si un trabajo debe continuar, transfiere su responsabilidad según un procedimiento acordado en lugar de dejar una identidad huérfana.
Evitar los atajos que impiden el control
Una clave privada compartida impide saber quién debe reemplazarla y a menudo obliga a una rotación colectiva. Un acceso amplio «provisional» tiende a durar si nadie ha fijado su fecha de revisión. Una cuenta de validación usada también para administrar la máquina hace que los controles de separación sean difíciles de interpretar. Corrige estos problemas en la ficha de acceso antes de que se conviertan en una dependencia de la explotación.
Evita también añadir reenvíos de agente, túneles o excepciones de acceso solo para sortear una dificultad no diagnosticada. Haz que el responsable autorizado describa la necesidad de conexión y sus restricciones. Esta guía no propone ninguna configuración de servidor universal: los mecanismos dependen de los derechos otorgados, del entorno y de los requisitos del proyecto. Una documentación general no equivale a validar el destino.
Entregar una organización de acceso que siga siendo verificable
Al recibir el proyecto, reúne la matriz aprobada, las identidades activas, las pruebas permitidas y rechazadas, los plazos y la persona capaz de retirar un acceso. Comprueba que una persona ausente puede ser sustituida sin difundir su secreto. La continuidad se apoya en un procedimiento y un responsable de respaldo autorizado, no en una contraseña compartida en la carpeta del proyecto.
Al hacer el relevo, revisa los accesos que hayan quedado inútiles y las automatizaciones que dependen de una identidad personal. Si un rechazo inesperado bloquea el trabajo, reúne un expediente de incidencia concreto con la identidad técnica, el camino afectado y el error depurado. No añadas permisos generales solo para hacer desaparecer el síntoma. El buen cierre es un acceso necesario, probado y con un final conocido.
Preguntas para decidir
¿Hay que compartir la cuenta de Capordia con todos los participantes?
No. El seguimiento del alquiler y los accesos técnicos al trabajo deben organizarse por separado. Define las identidades de máquina posibles con los derechos realmente otorgados. Este método no presupone ningún sistema de invitaciones ni de roles de equipo en el espacio de Capordia.
¿Una clave pública otorga automáticamente los permisos correctos?
No. Sirve para la autenticación cuando está autorizada; las acciones accesibles dependen después de la cuenta y de los permisos del sistema. Verifica una acción permitida y una acción que debe rechazarse sobre archivos sintéticos.
¿Qué hay que verificar tras la marcha de un participante?
Retira sus autorizaciones, comprueba que se rechaza una nueva autenticación y examina las sesiones, los trabajos y las automatizaciones que aún estén vinculados a su identidad. Conserva un responsable autorizado para la recuperación y el seguimiento. No des por hecha la retirada a partir de una simple casilla marcada.