GNU/Linux >> Tutoriales Linux >  >> Linux

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

Solución 1:

Todo lo dicho hasta ahora aquí es bueno, pero hay una forma no técnica 'fácil' que ayuda a negar un administrador de sistema deshonesto:el principio de los cuatro ojos que básicamente requiere que dos administradores de sistema 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 ambos problemas es con el uso de una empresa de servicios administrados utilizada solo para verificar las acciones realizadas. Hecho correctamente, los técnicos no se conocerían entre sí. Asumiendo la destreza técnica que debería tener un MSP, sería bastante fácil tener una aprobación de las acciones tomadas... tal vez incluso tan simple como un sí/no a cualquier cosa nefasta.

Solución 2:

Si las personas realmente necesitan acceso de administrador a un sistema, es poco lo que puede hacer para restringir sus actividades en ese cuadro.

Lo que hace la mayoría de las organizaciones es confiar, pero verificar - puede dar acceso a las personas a partes del sistema, pero usa cuentas de administrador designadas (por ejemplo, no les da acceso directo a raíz ) y luego auditar sus actividades en un registro en el que no pueden interferir.

Hay un acto de equilibrio aquí; es posible que necesite proteger sus sistemas, pero también necesita confiar en las personas para que hagan su trabajo. Si la empresa fue "mordida" anteriormente por un empleado sin escrúpulos, esto podría sugerir que las prácticas de contratación de las empresas son deficientes de alguna manera, y esas prácticas fueron supuestamente creadas por los "directores superiores". La confianza comienza en casa; ¿Qué están haciendo para corregir sus opciones de contratación?

Solución 3:

Lo que está hablando se conoce como el riesgo "Evil Sysadmin". El resumen es:

  • Un administrador de sistemas es alguien que tiene privilegios elevados
  • Técnicamente expertos, a un nivel que los convertiría en buenos 'hackers'.
  • Interactuar con sistemas en escenarios anómalos.

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

Hay un montón de medidas paliativas:

  • Separación de privilegios:no puedes evitar que un chico con root haga nada 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).
  • Limitar el acceso físico al kit a un equipo diferente, que no tiene cuentas de administrador... pero se encarga de todo el trabajo manual.
  • Separe la responsabilidad de 'escritorio' y 'servidor'. Configure el escritorio para inhibir la eliminación de datos. Los administradores de escritorio no tienen la capacidad de acceder a la información confidencial, los administradores del servidor pueden robarla, pero tienen que pasar por obstáculos para sacarla del edificio.
  • Auditoría a un sistema de acceso restringido - syslog y auditoría a nivel de eventos, a un sistema relativamente resistente a la manipulación al que no tienen acceso privilegiado. Pero recopilarla no es suficiente, debe monitorearla y, francamente, hay muchas formas de 'robar' información que podrían no aparecer en un radar de auditoría. (Cazador furtivo contra guardabosques)
  • aplique encriptación 'en reposo', de modo que los datos no se almacenen 'claros' y requiera 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, es probable que los datos no se puedan leer)
  • Regla de dos hombres:si está de acuerdo con que su productividad se vea afectada y su moral también. (En serio, lo he visto hacer, y el estado persistente de trabajar y ser observado hace que las condiciones de trabajo sean extremadamente difíciles).
  • Examine a sus administradores de sistemas:pueden existir varias verificaciones de registros según el país. (Verificación de antecedentes penales, usted podría incluso descubra que puede solicitar una autorización de seguridad en algunos casos, lo que activará la investigación)
  • Cuide a sus administradores de sistemas:lo último que desea hacer es decirle a una persona "de confianza" que no confía en ella. Y ciertamente no quieres dañar la moral, porque eso aumenta la posibilidad de un comportamiento malicioso (o 'no del todo-negligencia, sino un desliz en la vigilancia'). Pero pague de acuerdo con la responsabilidad y el conjunto de habilidades. Y considere los 'beneficios', que son más baratos que el salario, pero probablemente valorados más. Como café gratis o pizza una vez a la semana.
  • y también puede probar y aplicar condiciones de contrato para inhibirlo, pero tenga cuidado con lo anterior.

Pero fundamentalmente:debe aceptar que se trata de una cuestión de confianza, no de una cuestión técnica. Sus administradores de sistemas siempre serán potencialmente muy peligrosos para usted, como resultado de esta tormenta perfecta.

Solución 4:

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

Desde el punto de vista de la práctica comercial, existe un conjunto de soluciones simples. No es una solución barata, pero es simple.

Usted mencionó que las piezas de PI que le preocupan están divididas y solo las personas en la parte superior tienen el poder de verlas. Esta es esencialmente su respuesta. Debe tener varios administradores, y NINGUNO de ellos debe ser administrador en suficientes sistemas 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 tenga un accidente automovilístico o algo así. Tal vez incluso escalonarlos. digamos que tiene 4 administradores y 8 piezas de información. el administrador 1 puede acceder a los sistemas que tienen las piezas 1 y 2, el administrador 2 puede acceder a las piezas 2 y 3, el administrador 3 puede acceder a las piezas 3 y 4, y el administrador 4 puede acceder a las piezas 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 utilizan los militares es la limitación de datos en movimiento. En un área sensible, puede haber solo un 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 una aprobación documentada específica por parte de los superiores antes de que alguien pueda poner datos en cualquier cosa que pueda conducir a un derrame de información. Del mismo modo, 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 obtener acceso específico 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 estar encriptados, por lo que que los administradores de su red no pueden tocar la red y obtener acceso a los datos.

Todas las computadoras portátiles/estaciones de trabajo deben tener discos duros encriptados, y cada empleado debe tener un casillero personal en el que deben guardar las unidades/computadoras portátiles al final de la noche para asegurarse de que nadie llegue temprano/se vaya tarde y obtenga acceso a algo. no se supone que lo hagan.

Como mínimo, cada servidor debe estar en su propio rack cerrado, si no en su propia habitación 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 todo.

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 a cada administrador solo durante un período de tiempo predeterminado (es decir, 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 así como... Dividir sus datos en tantas partes como sea, digamos por el hecho de 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 encriptados para todas las estaciones de trabajo que tocarán la IP. con un directorio de "proyecto" específico en el disco, que es el único directorio en el que los usuarios pueden colocar sus proyectos. Al final de cada noche, deben limpiar sus directorios de proyectos con una herramienta de eliminación segura, luego se eliminan los discos duros y se encerrado (solo para estar seguro).

Cada parte del proyecto tiene un administrador diferente asignado, por lo que un usuario solo interactuaría con el administrador de la estación de trabajo al que está asignado, si la asignación de su proyecto cambia, sus datos se borran, se le 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.

Solución 5:

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 antiguo problema y observar las formas históricas en que se otorga la confianza.

Aunque no existe una solución técnica clara, el hecho de que no haya ninguna no debería ser una razón para que no intentemos ninguna, una agregación de soluciones imperfectas puede dar resultados excelentes.

Un modelo donde se gana la confianza :

  • Dar menos permisos para empezar
  • Aumentar gradualmente los permisos
  • Ponga un honeypot y controle lo que sucede en los próximos días
  • Si el administrador del sistema lo informa en lugar de intentar 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 superior de archivos de configuración
  • Nivel 3:puede modificar un nivel ligeramente superior de los archivos de configuración y la configuración del sistema operativo

Cree siempre un entorno en el que no sea posible el acceso total de una sola persona :

  • Sistemas divididos en clústeres
  • Otorgar poderes de administración de clústeres 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 cambios principales

Confiar y verificar :

  • Registrar todo
  • Supervisión de registros y alertas
  • Asegúrese de que todas las acciones sean distinguibles

Papeleo :

  • Hacer que firmen el papeleo para que el sistema legal pueda ayudarlo al demandarlos si lo lastiman da más incentivos para no hacerlo

Linux
  1. Linux:¿Separar completamente dos cuentas sin instalar sistemas operativos separados?

  2. acceso concurrente al archivo linux

  3. Enviar/recibir ZFS a través de ssh en Linux sin permitir el inicio de sesión de root

  4. Instalación de software en Linux sin privilegios de root

  5. ¿Cómo instalar localmente .deb sin apt-get, dpkg o acceso de root?

Cómo agregar repositorios a Red Hat Linux con y sin proxy

Cómo extender la partición raíz XFS sin LVM en Linux

CÓMO:Ejecutar Linux en Android sin root

Comandos de Linux utilizados con frecuencia por los administradores de sistemas de Linux - Parte 1

¿Cómo sé los permisos de un usuario específico en Linux con acceso de root?

¿Qué determina qué comandos de Linux requieren acceso de root?