Linux: administradores de sistemas productivos sin root (asegurando la propiedad intelectual)?

¿Hay alguna forma de hacer que un syadmin experimentado de Linux sea productivo sin darle acceso completo a la raíz?

Esta pregunta proviene de una perspectiva de protección de la propiedad intelectual (IP), que en mi caso, es completamente código y / o archivos de configuración (es decir, pequeños archivos digitales que se copian fácilmente). Nuestra salsa secreta nos ha hecho más exitosos de lo que sugeriría nuestro tamaño pequeño. Del mismo modo, somos una vez mordidos, dos veces tímidos de algunos ex empleados sin escrúpulos (no administradores de sistemas) que intentaron robar IP. La posición de la alta gerencia es básicamente: "Confiamos en las personas, pero por interés propio, no podemos correr el riesgo de dar a una persona más acceso del que absolutamente necesita para hacer su trabajo".

En el lado del desarrollador , es relativamente fácil particionar los flujos de trabajo y los niveles de acceso para que las personas puedan ser productivas pero solo vean lo que necesitan ver. Solo las mejores personas (propietarios reales de la compañía) tienen la capacidad de combinar todos los ingredientes y crear la salsa especial.

Pero no he podido encontrar una buena manera de mantener este secreto de IP en el lado del administrador de Linux. Hacemos un uso extenso de GPG para el código y los archivos de texto confidenciales ... pero, ¿qué impide que un administrador (por ejemplo) demande a un usuario y salte a su sesión de pantalla tmux o GNU y vea lo que está haciendo?

(También tenemos el acceso a Internet deshabilitado en todas partes que podría entrar en contacto con información confidencial. Pero nada es perfecto, y podría haber agujeros abiertos para administradores de sistemas inteligentes o errores en el lado del administrador de la red. O incluso un buen USB antiguo. Por supuesto, existen muchas otras medidas, pero están más allá del alcance de esta pregunta).

Básicamente, lo mejor que puedo encontrar es usar cuentas personalizadas con sudo , similar a lo que se describe en Varios administradores de sistemas Linux que funcionan como root . Específicamente: nadie, excepto los propietarios de la compañía, tendría acceso directo a la raíz. Otros administradores tendrían una cuenta personalizada y la capacidad de sudo en la raíz. Además, se instituiría el registro remoto y los registros irían a un servidor al que solo los propietarios de la compañía podrían acceder. Ver el registro desactivado activaría algún tipo de alertas.

Un administrador de sistemas inteligente probablemente todavía podría encontrar algunos agujeros en este esquema. Y aparte de eso, sigue siendo reactivo en lugar de proactivo . El problema con nuestra IP es tal que los competidores podrían usarla muy rápidamente y causar muchos daños en muy poco tiempo.

Así que aún mejor sería un mecanismo que limite lo que el administrador puede hacer. Pero reconozco que este es un equilibrio delicado (particularmente a la luz de la resolución de problemas y la solución de problemas de producción que deben resolverse ahora ).

No puedo evitar preguntarme cómo otras organizaciones con datos muy sensibles manejan este problema. Por ejemplo, administradores de sistemas militares: ¿cómo gestionan los servidores y los datos sin poder ver información confidencial?

Editar: En la publicación inicial, tenía la intención de abordar de manera preventiva los comentarios de "prácticas de contratación" que están comenzando a aparecer. Uno, se supone que es una pregunta técnica , y las prácticas de contratación de la OMI tienden más a las preguntas sociales . Pero, dos, diré esto: creo que hacemos todo lo razonable para contratar personas: entrevista con múltiplesgente de la firma; verificación de antecedentes y referencias; Todos los empleados firman numerosos documentos legales, incluido uno que dice que han leído y entendido nuestro manual que detalla las preocupaciones de IP en detalle. Ahora, está fuera del alcance de esta pregunta / sitio, pero si alguien puede proponer prácticas de contratación "perfectas" que filtren al 100% de los malos actores, soy todo oídos. Los hechos son: (1) No creo que haya un proceso de contratación tan perfecto; (2) la gente cambia: el ángel de hoy podría ser el diablo de mañana; (3) el intento de robo de código parece ser algo rutinario en esta industria.

Lo que estás hablando se conoce como el riesgo "Eysymin Sysadmin". Lo largo y corto de esto es:

• Un administrador de sistemas es alguien que tiene privilegios elevados
• Técnicamente experto, a un nivel que los convertiría en un buen 'hacker'.
• Interactuando con sistemas en escenarios anómalos.

La combinación de estas cosas hace que sea esencialmente imposible detener la acción maliciosa. Incluso la auditoría se vuelve difícil, porque no tiene "normal" para comparar. (Y, francamente, un sistema roto también puede haber roto la auditoría).

Hay un montón de pasos mitigantes:

• Separación de privilegios: no puede evitar que un chico con root haga algo en el sistema. Pero puede hacer que un equipo sea responsable de las redes y otro equipo responsable de los 'sistemas operativos' (o Unix / Windows por separado).
• Limite el acceso físico al kit a un equipo diferente, que no obtiene cuentas de administrador ... pero se encarga de todo el trabajo 'manos'.
• Separe la responsabilidad de 'escritorio' y 'servidor'. Configure el escritorio para inhibir la eliminación de datos. Los administradores de escritorio no tienen capacidad para acceder a los sensibles, los administradores del servidor pueden robarlo, pero tienen que saltar a través de los aros para sacarlo del edificio.
• Auditoría a un sistema de acceso restringido, syslogy auditoría a nivel de evento, a un sistema relativamente resistente a la manipulación al que no tienen acceso privilegiado. Pero recopilarlo no es suficiente, debe monitorearlo, y, francamente, hay muchas maneras de 'robar' información que podría no aparecer en un radar de auditoría. (Cazador furtivo vs. gamekeepers)
• aplica el cifrado 'en reposo', de modo que los datos no se almacenan 'en claro', y requiere un sistema en vivo para acceder. Esto significa que las personas con acceso físico no pueden acceder a un sistema que no está siendo monitoreado activamente, y que en un escenario 'anómalo' donde un administrador de sistemas está trabajando en él, los datos están menos expuestos. (por ejemplo, si la base de datos no funciona, los datos probablemente no sean legibles)
• La regla de los dos hombres: si estás de acuerdo con que tu productividad esté paralizada y tu moral también. (En serio, lo he visto hecho, y el persistente estado de trabajo y observación hace que las condiciones de trabajo sean extremadamente difíciles).
• Revise sus administradores de sistemas: pueden existir varias comprobaciones de registros según el país. (Verificación de antecedentes penales, incluso puede encontrar que puede solicitar una autorización de seguridad en algunos casos, lo que desencadenará la investigación de antecedentes)
• Cuida de tus administradores de sistemas: lo último que quieres hacer es decirle a una persona "de confianza" que no confías en ellos. Y ciertamente no desea dañar la moral, porque eso aumenta las posibilidades de comportamiento malicioso (o 'no-negligencia, sino un resbalón en la vigilancia'). Pero pague de acuerdo con la responsabilidad y el conjunto de habilidades. Y considere las 'ventajas', que son más baratas que el salario, pero que probablemente valen más. Como café gratis o pizza una vez por semana.
• y también puede intentar aplicar condiciones de contrato para inhibirlo, pero tenga cuidado con lo anterior.

Pero fundamentalmente, debe aceptar que esto es algo de confianza, no técnico. Tus administradores de sistemas siempre serán potencialmente muy peligrosos para ti, como resultado de esta tormenta perfecta.

Todo lo dicho hasta ahora aquí es algo bueno, pero hay una forma no técnica 'fácil' que ayuda a negar un administrador de sistemas no autorizado: el principio de cuatro ojos que básicamente requiere que dos administradores de sistemas estén presentes para cualquier acceso elevado.

EDITAR: Los dos elementos más importantes que he visto en los comentarios están discutiendo el costo y la posibilidad de colusión. Una de las formas más importantes que he considerado para evitar estos dos problemas es con el uso de una compañía de servicios administrados que se usa solo para verificar las acciones tomadas. Hecho correctamente, los técnicos no se conocerían. Asumiendo la destreza técnica que debería tener un MSP, sería bastante fácil tener un cierre de sesión de las acciones tomadas ... tal vez incluso tan simple como un sí / no a algo nefasto.

Si la gente realmente necesita acceso de administrador a un sistema, entonces es poco lo que puede hacer para restringir sus actividades en ese cuadro.

Lo que la mayoría de las organizaciones hacen es confiar, pero verificar : puede dar acceso a las personas a partes del sistema, pero usa cuentas de administrador con nombre (por ejemplo, no les da acceso directo a la raíz ) y luego audita sus actividades en un registro. no puede interferir con

Hay un acto de equilibrio aquí; Es posible que deba proteger sus sistemas, pero también debe confiar en las personas para que hagan su trabajo. Si la empresa fue anteriormente "mordida" por un empleado inescrupuloso, entonces esto podría sugerir que las prácticas de contratación de las empresas son de alguna manera pobres, y esas prácticas fueron supuestamente creadas por los "altos directivos". La confianza comienza en casa; ¿Qué están haciendo para arreglar sus opciones de contratación?

Sin ponerse en un giro mental técnico loco para tratar de encontrar una manera de dar poder a un administrador de sistemas sin darle poder (es probable que sea posible, pero en última instancia sería defectuoso de alguna manera).

Desde el punto de vista de la práctica empresarial, hay un conjunto de soluciones simples. No es una solución barata, sino simple.

Usted mencionó que las partes de IP que le preocupan están divididas y solo las personas en la parte superior tienen el poder de verlas. Esta es esencialmente tu respuesta. Debe tener varios administradores, y NINGUNO de ellos debe ser un administrador en sistemas suficientes para armar la imagen completa. Por supuesto, necesitaría al menos 2 o 3 administradores para cada pieza, en caso de que un administrador esté enfermo o en un accidente automovilístico o algo así. Tal vez incluso escalonarlos. Digamos que tiene 4 administradores y 8 piezas de información. admin 1 puede acceder a sistemas que tienen piezas 1 y 2, admin 2 puede llegar a piezas 2 y 3, admin 3 puede llegar a 3 y 4, y admin 4 puede llegar a 4 y 1. Cada sistema tiene un administrador de respaldo, pero no El administrador puede comprometer la imagen completa.

Una técnica que también usan los militares es la limitación de los datos en movimiento. En un área sensible puede haber un solo sistema que sea capaz de grabar un disco, o usar una unidad flash USB, todos los demás sistemas están restringidos. Y la capacidad de usar ese sistema es extremadamente limitada y requiere aprobación documentada específica por parte de los superiores antes de que a nadie se le permita poner ningún dato sobre cualquier cosa que pueda conducir al derrame de información. Junto con el mismo token, se asegura de que el tráfico de red entre diferentes sistemas esté limitado por firewalls de hardware. Los administradores de su red que controlan los cortafuegos no tienen acceso a los sistemas que están enrutando, por lo que no pueden acceder específicamente a la información, y los administradores de su servidor / estación de trabajo se aseguran de que todos los datos hacia y desde un sistema estén configurados para encriptarse,

Todas las computadoras portátiles / estaciones de trabajo deben tener discos duros cifrados, y cada empleado debe tener un casillero personal al que se les requiere que bloqueen las unidades / computadoras portátiles al final de la noche para asegurarse de que nadie llegue temprano / salga tarde y obtenga acceso a algo se supone que no deben hacerlo.

Cada servidor debe, como mínimo, estar en su propio rack cerrado, si no en su propia sala cerrada, de modo que solo los administradores responsables de cada servidor tengan acceso a él, ya que al final del día el acceso físico triunfa sobre todos.

A continuación hay una práctica que puede lastimar / ayudar. Contratos limitados. Si cree que puede pagar lo suficiente para seguir atrayendo nuevos talentos, la opción de mantener solo a cada administrador durante un conjunto de tiempo predeterminado (IE 6 meses, 1 año, 2 años) le permitiría limitar el tiempo que alguien tendría para intentar juntar todas las piezas de su IP.

Mi diseño personal sería algo similar a ... Divida sus datos en la cantidad de piezas que tenga, digamos por tener un número 8, tiene 8 servidores git, cada uno con su propio conjunto de hardware redundante, cada uno administrado por Un conjunto diferente de administradores.

Discos duros cifrados para todas las estaciones de trabajo que tocarán la IP. con un directorio específico de "proyecto" en el disco que es el único directorio en el que los usuarios pueden colocar sus proyectos. Al final de cada noche se les requiere sanatizar sus directorios de proyectos con una herramienta de eliminación segura, luego se quitan los discos duros y encerrado (solo para estar seguro).

Cada bit del proyecto tiene asignado un administrador diferente, por lo que un usuario solo interactuaría con el administrador de la estación de trabajo al que está asignado, si su asignación de proyecto cambia, sus datos se borran, se les asigna un nuevo administrador. Sus sistemas no deben tener capacidades de grabación y deben usar un programa de seguridad para evitar el uso de unidades flash USB para transferir datos sin autorización.

toma de esto lo que quieras.

Sería similar al desafío de contratar a un conserje para un edificio. El conserje tiene todas las llaves, puede abrir cualquier puerta, pero la razón es que el conserje las necesita para hacer el trabajo. Lo mismo con los administradores del sistema. Simétricamente, uno puede pensar en este viejo problema y ver formas en que la confianza se otorga históricamente.

Aunque no existe una solución técnica de corte limpio, el hecho de que no exista ninguna no debería ser una razón por la que no lo intentemos, una agregación de soluciones imperfectas puede dar resultados algo excelentes.

Un modelo donde se gana la confianza :

• Otorgue menos permisos para comenzar
• Aumente gradualmente los permisos
• Poner un honeypot y controlar lo que sucede en los próximos días.
• Si el administrador del sistema lo informa en lugar de tratar de abusar de él, es un buen comienzo

Implementar varios niveles de poderes administrativos :

• Nivel 1: puede modificar el nivel inferior de los archivos de configuración
• Nivel 2: puede modificar un nivel ligeramente más alto de archivos de configuración
• Nivel 3: puede modificar un nivel ligeramente superior de archivos de configuración y configuraciones del sistema operativo

Siempre cree un entorno donde el acceso total de una persona no sea posible :

• Sistemas divididos en grupos
• Otorgue poderes de administración de clúster a diferentes grupos
• Mínimo 2 grupos

Use la regla de dos hombres cuando realice cambios básicos de alto nivel :

• https://en.wikipedia.org/wiki/Two-man_rule
• Requerir un administrador de cluster1 y cluster2 para los cambios principales

Confía y verifica :

• Registrar todo
• Registro de monitoreo y alertas
• Asegúrese de que todas las acciones sean distinguibles

Papeleo :

• Pídales que firmen documentos para que el sistema legal pueda ayudarlo al demandarlos si lo lastiman le da más incentivos para no hacerlo.

Es muy difícil proteger los hosts contra aquellos con acceso administrativo. Si bien las herramientas como PowerBroker intentan hacer esto, el costo es agregar algo más que puede romperse Y agregar barreras a los intentos de solucionarlo. Su disponibilidad del sistema SE caer al implementar algo como esto por lo que establece la expectativa de que ya en el coste de la protección de las cosas.

Otra posibilidad es ver si su aplicación puede ejecutarse en hosts desechables a través de un proveedor de la nube o en una nube privada alojada localmente. Cuando uno se rompe, en lugar de enviar un administrador para que lo arregle, lo descarta y crea automáticamente un reemplazo. Esto requerirá mucho trabajo en el lado de la aplicación para que funcionen en este modelo, pero puede resolver muchos problemas operativos y de seguridad. Si se hace mal, puede crear algunos problemas de seguridad importantes, así que obtenga ayuda experimentada si sigue esa ruta.

Esta es su discusión de referencia: https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux

Divide su responsabilidad al tener ingenieros de seguridad cuyo trabajo es realizar configuraciones e instalaciones del sistema, pero no obtienen credenciales ni acceso a las máquinas en producción. También ejecutan su infraestructura de auditoría.

Tiene administradores de producción que reciben los sistemas pero no tienen las claves para iniciar la máquina sin que las políticas de SELinux estén activas. La seguridad no obtiene las claves para descifrar los datos confidenciales almacenados en reposo en el disco para cuando una máquina dañada se retira del servicio.

Utilice un sistema de autenticación centralizado con auditorías sólidas como Vault y utilice sus operaciones de cifrado. Entregue los dispositivos Yubikey para que las claves sean absolutamente privadas e ilegibles.

Las máquinas se limpian en caso de rotura o se manejan juntas mediante operaciones y seguridad, y si siente la necesidad de supervisión ejecutiva.

Los administradores por la naturaleza del trabajo tienen acceso a todo. Pueden ver todos los archivos del sistema de archivos con sus credenciales de administrador. Por lo tanto, necesitará una forma de cifrar los archivos para que los administradores no puedan verlos, pero los equipos que deberían verlos aún pueden usar los archivos. Examine el cifrado transparente de Vormetric ( http://www.vormetric.com/products/transparent-encryption )

La forma en que funcionaría es que se ubica entre el sistema de archivos y las aplicaciones que acceden a él. La administración puede crear la política que dice "Solo el usuario httpd, que ejecuta el demonio del servidor web, puede ver los archivos sin cifrar". Luego, un administrador con sus credenciales raíz puede intentar leer los archivos y solo obtener la versión cifrada. Pero el servidor web y cualquier herramienta que necesite los ve sin cifrar. Incluso puede sumar el binario para que sea más difícil para el administrador moverse.

Por supuesto, debe habilitar la auditoría para que, en caso de que un administrador intente acceder a los archivos, se marque un mensaje y la gente lo sepa.

La única forma práctica es restringir quién puede hacer qué con sudo. Potencialmente, también podría hacer la mayor parte de lo que desea con selinux, pero probablemente le tomará una eternidad descubrir la configuración correcta, lo que puede hacer que sea poco práctico.

Acuerdos de no divulgación. Contrata a un administrador de sistemas, tienen que firmar un NDA, si rompen su promesa, llévalos a los tribunales. Esto puede no evitar que roben secretos, pero cualquier daño que causen al hacerlo es recuperable en la corte.

Los administradores de sistemas militares y gubernamentales deben obtener autorizaciones de seguridad de diferentes grados según la sensibilidad del material. La idea es que alguien que puede obtener una autorización tiene menos probabilidades de robar o engañar.

Otra forma de reducir el riesgo (usar junto a los mencionados anteriormente, no en lugar de) es pagar un buen dinero a sus administradores de sistemas. Págales tan bien que no quieran robarle su IP y dejarlo.

Estoy pensando que esta pregunta podría no ser posible responder completamente sin más detalles, como:

¿Cuántos administradores de sistemas espera mantener "restringidos"?

¿Para qué necesitan las personas el acceso "administrador de sistemas"?

En primer lugar, tenga en cuenta lo que puede hacer con sudo. Con sudo, puede permitir permisos elevados para ejecutar un solo comando (o variaciones, como los comandos que comienzan con "mount -r" pero no se permiten otros comandos). Con las claves SSH, puede asignar credenciales que permiten que una persona solo ejecute un determinado comando (como "sudo mount -r / dev / sdd0 / media / backup"). Por lo tanto, hay una manera relativamente fácil de permitir que casi cualquier persona (que tenga una clave SSH) pueda realizar algunas operaciones específicas sin dejar que hagan absolutamente todo lo demás.

Las cosas se vuelven un poco más difíciles si quieres que los técnicos realicen arreglos de lo que está roto. Normalmente, esto puede requerir una mayor cantidad de permisos y quizás acceso para ejecutar una amplia variedad de comandos y / o escribir en una variedad de archivos.

Sugiero considerar el enfoque de los sistemas basados ​​en la web, como CPanel (que es utilizado por varios ISP) o sistemas basados ​​en la nube. A menudo pueden hacer que desaparezcan los problemas en una máquina, haciendo que toda la máquina desaparezca. Por lo tanto, una persona puede ejecutar un comando que reemplaza la máquina (o restaura la máquina a una imagen buena conocida), sin necesariamente darle acceso a la persona para leer muchos datos o realizar pequeños cambios (como combinar una solución menor) con la introducción de una puerta trasera no autorizada). Luego, debe confiar en las personas que hacen las imágenes, pero está reduciendo en cuántas personas debe confiar para hacer las cosas más pequeñas.

Sin embargo, en última instancia, se debe proporcionar una cierta cantidad de confianza a un número distinto de cero de personas que ayudan a diseñar el sistema y que operan al más alto nivel.

Una cosa que hacen las grandes empresas es confiar en cosas como los servidores SQL, que almacenan datos a los que se puede acceder de forma remota por un mayor número de máquinas. Entonces, un mayor número de técnicos puede tener acceso raíz completo en algunas máquinas, sin tener acceso raíz a los servidores SQL.

Otro enfoque es ser demasiado grande para fallar. No piense que los grandes ejércitos o las corporaciones gigantes nunca tienen incidentes de seguridad. Sin embargo, saben cómo:

• recuperar,
• limitar el daño (separando cosas valiosas)
• tener contramedidas, incluidas amenazas de litigio
• tienen procesos para ayudar a limitar la exposición indeseable a la prensa y tienen planes sobre cómo influir en el giro de cualquier historia negativa que se desarrolle

La suposición básica es que el daño que ocurre es simplemente un riesgo y un costo de hacer negocios. Esperan continuar operando, y los desarrollos y mejoras en curso a lo largo de los años limitarán la cantidad de daño que un solo incidente pueda afectar su valor a largo plazo durante un período de tiempo.

Hacer una verificación proactiva es muy difícil.

Soluciones como http://software.dell.com/solutions/privileged-management/ (no trabajo para Dell y hay otras soluciones similares disponibles) son muy efectivas para hacer cumplir la responsabilidad del administrador de sistemas.

Coloque la máquina de administración raíz en la habitación cerrada con dos llaves y dé solo una para cada uno de los dos administradores. Los administradores siempre trabajarán juntos, observándose mutuamente las actividades. Debe ser la única máquina que contiene la clave privada para iniciar sesión como root.

Es posible que algunas actividades no necesiten derechos de root, por lo que solo una parte del trabajo requeriría ir a esa sala para la "programación de pares"

También puede grabar actividades de video en esa sala principalmente para asegurarse de que nadie trabaje solo (eso es fácilmente visible). Además, asegúrese de que el lugar de trabajo sea tal que la pantalla sea fácilmente visible para ambas personas (tal vez una gran pantalla de TV con las fuentes grandes).