Hay muchas buenas respuestas aquí. Al final, es una decisión personal y el proceso organizativo también es una parte muy importante de todo el proceso.

Me gustaría señalar otra solución mejor manejable. Descargo de responsabilidad : esta es una solución que estoy desarrollando.

privacyIDEA es un sistema de gestión de dos factores. O, para decirlo más ampliamente, es un sistema de gestión de autenticación. Una posibilidad es que también puede asignar un token de autenticación abstracto " token de 4 ojos "a una cuenta de usuario. De esta manera, puede configurar que una determinada cuenta de usuario o ciertos comandos (sudo) necesiten la autenticación de dos o más personas. Estos usuarios podrían autenticarse con contraseñas o con tokens de hardware de contraseñas únicas como yubikeys.

El efecto secundario agradable es que obtiene un registro de auditoría firmado digitalmente dentro de privacyIDEA, para que pueda saber qué dos personas actuaron dentro de su regla de dos hombres.

  

¿Cómo se puede implementar el control de dos personas con una sobrecarga mínima?

TL; DR Esto se puede lograr usando un comando especial sudo que requiere una segunda persona para aprobar cada comando, combinado con una buena lista blanca para hacer que los comandos más seguros sean más convenientes. Es importante que cada comando sea aprobado por la regla de dos hombres o la protección es fácilmente derrotada.

Opciones de implementación de la regla de dos personas:

  

Acceso de raíz sin restricciones

Habilitar root de acceso temporalmente

Un script raíz pequeño podría requerir que una segunda persona (Usuario A) lo autorice antes de que sudo esté disponible para el administrador de sistema activo (Usuario B)

1. Usuario A: enable-sudo user-b
   (agrega automáticamente una entrada a /etc/sudoers con un límite de tiempo o una eliminación programada mediante el trabajo at )

2. Usuario B: sudo do stuff comenzará a trabajar en este punto

Lamentablemente, el Usuario B podría agregar fácilmente una puerta trasera una vez que el Usuario A haya autorizado el acceso. Esto podría ser tan simple como volver a agregar user-b a /etc/sudoers o iniciar un servicio separado.

No es posible hacer cumplir las reglas de seguridad de manera sólida una vez que alguien haya obtenido root (ya que está "sin restricciones"), por lo que debe monitorear de forma encubierta las posibilidades de desvío más probables y alertar a otro administrador de sistemas (más confiable) si algo comienza. impar después de una habilitación de dos hombres de sudo .

• trabajo inesperado at o cron
• proceso en segundo plano inesperado aún en ejecución
• secuencia de comandos de inicio inesperado

Y no les digas exactamente qué medidas de seguridad estás usando. Esto ayudará contra las obvias puertas traseras, especialmente si user-b no está familiarizado con las protecciones implementadas, pero no frustrará a un user-b que está determinado a causar problemas.

Regla de dos hombres basada en comandos

Crea tu propia versión de sudo , que alerta a la segunda persona de cualquier comando sugerido por la primera persona, con la capacidad de aprobar o rechazar.

No entraré en los detalles de implementación aquí, pero sería bastante sencillo de implementar.

En este caso, una puerta trasera debería estar oculta dentro de uno de los archivos provistos, por ejemplo, una actualización de software que se instalará.

Edición de archivos con vim

Su versión personalizada de sudo no debe permitir el lanzamiento de comandos de edición directa de archivos. Si alguien escribe oursudo vi , entonces oursudo tendrá que iniciar un script especial para editar archivos.

1. Copie el archivo en una ubicación /tmp (nombre de archivo generado aleatoriamente para evitar ataques de enlace simbólico)
2. Inicie vim con privilegios reducidos en una cuenta que no sea root (por lo tanto, user-b no puede usar la función "Guardar como" dentro de vim para omitir este contenedor)
3. Cuando se complete el guardado, presente un diff de los cambios del archivo a user-a .
4. Una vez aprobado, copie el archivo aprobado de /tmp a la ubicación de destino.

Barreras físicas

Requerir acceso físico para obtener root acceso podría ayudar a darle visibilidad a lo que user-b está haciendo. Dependiendo del entorno de la oficina, el equipo puede tener una idea de lo que user-b es hasta, y / o user-b puede ser menos cómodo causando problemas en ese entorno. Sin embargo, depende de la frecuencia con la que dicho acceso sea necesario.

Deficiencias: root = sin restricciones

Como puede deducirse de las ideas que he mencionado, no parece haber un fuego seguro para protegerse contra las instalaciones de puertas traseras. root access está diseñado para no permitir esto.

Enfoque de comandos de la lista blanca (restringir el acceso de la raíz)

Lo mejor es crear una lista blanca de comandos disponibles. (el cual sudo tiene la capacidad de ofrecer) Esto crea una sobrecarga significativa al principio, pero eventualmente puede ser más práctico a medida que aprendes el comando que se usa comúnmente.

  

Implementación de actualizaciones de aplicaciones

Sus aplicaciones no deben ejecutarse en el acceso de root. Aquellos que lo hagan deben pasar por un sistema de Revisión de Código separado y luego se pueden incluir las actualizaciones del compromiso VCS aprobado.

  

Software de parches [empaquetado]

Esto no se puede restringir, por lo que sugeriría usar la base de comandos de la regla de dos hombres descrita anteriormente.

  

Solución de problemas

Se pueden permitir herramientas seguras a través de sudo , y luego usar la regla de dos hombres basada en comandos para rodar la corrección.

La clave es implementar solo el control de dos personas para las operaciones que realmente lo necesitan.

Tareas de rutina

Las tareas de rutina, como la implementación de una versión de la aplicación o la aplicación de parches de seguridad, pueden tener secuencias de comandos. Un sys-admin puede crear el script, pero no puede ejecutarse hasta que un segundo sys-admin lo haya revisado y aprobado. Las tareas comunes, como reiniciar el servidor de aplicaciones o implementar la última versión de la aplicación, pueden tener un script aprobado previamente que se usa repetidamente. Las tareas no estándar necesitarán un script a medida.

Para hacer esto, se necesita algún tipo de sistema de administración de flujo de trabajo. Es posible que pueda usar un sistema de tickets como Trac, construir un sistema a medida en algo como JIRA, y las herramientas de administración de configuración como Puppet pueden tener características que podrían ayudar. Los dos administradores de sistemas NO necesitan ser físicamente locales; pueden trabajar de forma remota.

Los sistemas deben diseñarse de modo que la mayor parte del mantenimiento de rutina sea lo más automatizado posible: rotación programada de registros, etc.

Diagnostics

Los administradores de sistemas pueden tener acceso de solo lectura a los registros sin control de dos personas, siempre que los registros tengan información confidencial. También pueden tener una cuenta de bajo privilegio para ver páginas de estado y ejecutar comandos como top o ps. Esto permite a un único administrador del sistema diagnosticar problemas, y pueden trabajar de forma remota. Es posible que puedan remediarlo enviando un script como una tarea de rutina. Sin embargo, en algunos casos eso no será posible, por lo que hay una necesidad de acceso de emergencia.

Acceso de emergencia

A veces hay un problema grave y solo necesitas SSH como root. Para mantener el control de dos hombres, se necesitan dos personas en este punto. En la práctica, necesitan estar físicamente uno junto al otro. Una forma sencilla de implementar el control de acceso es tener una cuenta para cada emparejamiento, donde cada administrador del sistema conoce la mitad de la contraseña. Podría crear un sistema más inteligente con un módulo PAM personalizado, tal vez incluso requiriendo una tarjeta inteligente separada de ambos administradores de sistemas.

Una vez que haya iniciado sesión, es responsabilidad de los administradores de sistemas mantener el control de dos hombres. Deben inspeccionar los comandos de los demás antes de emitirlos, y bloquear el terminal si uno de ellos necesita salir.

El objetivo debe ser que el acceso de emergencia rara vez sea necesario.

Entornos de desarrollo

Solo es necesario usar el control de dos hombres para el entorno en vivo. Un único administrador del sistema puede tener acceso completo a un entorno de desarrollo, siempre que no haya datos en vivo. Pueden probar una tarea en el entorno de desarrollo, realizar algunas pruebas, solucionar los errores. Solo cuando tienen un script de trabajo lo envían a otro administrador del sistema para su aprobación.

Conclusión

Si se hace todo esto, creo que puede implementar un fuerte control de dos hombres con un 25% de sobrecarga. Hacer que sea un éxito depende de varias cosas (como el mantenimiento automatizado) que son buenas prácticas de todos modos. Si un sistema es tan sensible como para necesitar el control de dos hombres, ¡también es una buena idea hacer todos los conceptos básicos correctamente!

Nunca he visto esto implementado en un entorno comercial o gubernamental. Lo más cercano que he visto es una plataforma de banca en línea donde la mayoría de los administradores de sistemas no tienen acceso de raíz de forma rutinaria. Para realizar una tarea, esto se planearía primero en detalle y luego se aprobaría en el sistema de control de cambios. Para implementar el cambio, sys-admin obtuvo acceso de root por un período limitado. Además, había un pequeño número de administradores de sistemas de alto nivel que tenían acceso permanente a la raíz, en caso de emergencias. Este arreglo es mucho mejor de lo que normalmente veo, aunque no alcanza el control total de dos hombres.

Hay una técnica criptográfica que es muy relevante aquí, llamada intercambio secreto :

  

Intercambio secreto (también llamado división secreta ) se refiere a los métodos para distribuir un secreto entre un grupo de participantes, a cada uno de los cuales se le asigna una parte del secreto. El secreto puede reconstruirse solo cuando se combinan un número suficiente, posiblemente de tipos diferentes, de acciones; Las acciones individuales no tienen ningún uso por sí mismas.

Entonces, una estrategia que podrías adoptar es:

• Todas las acciones administrativas requieren autenticación con una clave criptográfica.
• La clave se divide n en todos los administradores de n , con un umbral de dos acciones para recuperar el secreto.
• Cada administrador debe mantener su parte secreta de todos los demás.

No conozco muchas implementaciones de intercambio secreto por ahí. Consulte esta pregunta para referencias Yo añadiría esto:

• HashiCorp's Vault es un sistema distribuido cliente / servidor para almacenar y recuperar secretos (por ejemplo, contraseñas a las que deben acceder las aplicaciones). El contenido de la base de datos de Vault se cifra con una clave que no se almacena en ningún lugar, sino que se divide en un conjunto de recursos compartidos secretos con un número y un umbral configurables. Para reconstituir la clave, tienen un proceso que llaman unsealing donde los propietarios del número requerido de acciones deben cada uno introduzca su parte.

Por lo tanto, podría cocinar algo con Vault para lograr esto. Las ideas claves serían:

• Mantenga todas las credenciales de administrador dentro de una instancia de Vault que solo se abre cuando se necesitan, y selle de inmediato cuando no lo son;
• Realice una secuencia de comandos de todas sus tareas para que los administradores nunca vean las credenciales reales, solo comparten sus claves maestras de Vault.

La única forma en que el control de dos personas puede implementarse de manera eficiente sin posibilidad de omitirlo, es asegurar físicamente el recurso en cuestión (computadora, medios de datos, etc.) para que sea inaccesible a menos que 2 personas, a través de datos biométricos, se autentiquen en el servicio. .

NO recomendaría una regla de 2 personas para iniciar sesión como root o similar para una computadora, en su lugar, preferiría restringir para que el tipo de acceso solo esté disponible en el sitio en un terminal físico, y luego ese terminal físico sea simplemente está metido en una habitación cerrada (sala de servidores o lo que sea) que requiera que 2 hombres se autentiquen para desbloquear.

La razón es que, de lo contrario, un hombre puede maliciosamente plantar una puerta trasera para permitir el control de un solo hombre, o los dos hombres pueden colaborar para reducir la seguridad del sistema al control de un solo hombre.

Al restringir físicamente el control de dos hombres, no es posible omitir el sistema, incluso si los dos hombres colaboran para dar acceso a la persona individual porque el otro hombre piensa que "se le tiene confianza" o algo por el estilo.

(por supuesto, dos mans podrían colaborar en la ejecución de un comando malicioso o lo que sea, pero el factor importante aquí es que no pueden colaborar para dar acceso permanente al hombre soltero)