¿Es posible mantener algo invisible para el administrador del servidor?

No, como regla general, no puede bloquear por completo a los administradores y aún permitirles el acceso suficiente para hacer su trabajo. Puede levantar algunas barreras que dificultan que un individuo abuse de su acceso privilegiado (y permanezca sin ser detectado) sin conspirar con otros.

La mayoría de las empresas enfrentan este tipo de desafíos de manera más o menos similar: mitigan los riesgos con procedimientos y controles, aplicados por contratos, tecnología y auditorías.

• contrata personas capaces y confiables y les ofrece suficientes incentivos para continuar actuando de esa manera (la zanahoria: trabajo interesante, apreciación, efectivo y el palo: cláusulas de penalización, procesamiento, etc.)
• después de la configuración inicial, el acceso administrativo está restringido (piense en sudo muy limitado en lugar de una contraseña de root conocida)
• use herramientas para que sus administradores no necesiten acceso real a la línea de comandos de los sistemas para realizar tareas comunes de administrador
• administración de cuentas con privilegios, cada escalada de privilegios sigue el procedimiento y requiere un principio estricto de cuatro ojos
• Ningún individuo individual puede mantener todas las llaves del reino
• confía pero verifica, implementa auditorías independientes
• separación de funciones, un administrador de sistemas no tiene derechos DBA, ni viceversa
• cifrado de datos en reposo (hace que sea difícil acceder a sus datos críticos al pasar los controles de acceso internos en su aplicación al leerlos directamente desde el disco)
• Los controles de acceso obligatorios de SELinux pueden realmente restringir "el poder de la raíz"
• e incluso podría imaginar una configuración en la que cada acción de administrador se guarde, en lugar de ejecutarse manualmente.

Por lo tanto, no hay una sola medida, pero una combinación de las medidas que mencioné y muchas de las que he omitido puede dificultar que un administrador de sistemas tenga acceso a los datos que no debería, al menos no sin descubrimiento.

Si un usuario tiene acceso administrativo completo (root en Linux, Administrator en Windows), él (o ella) puede hacer lo que quiera, hasta e incluyendo la modificación de los permisos de archivos y los derechos de acceso si, por alguna razón, hay algo que no hace. Ya no tienes acceso a. Esto es inevitable, ya que es el punto principal de tener acceso administrativo completo en primer lugar.

La solución es no otorgarle al usuario acceso administrativo completo, pero solo otorgarle los permisos necesarios para administrar lo que necesita administrar; sin embargo, dependiendo de los sistemas y las tareas que realmente necesita realizar, esto puede ser complicado y puede variar en dificultad desde algo tan simple como "ubicar al usuario en un grupo específico" para "personalizar en gran medida los permisos del sistema de archivos y las políticas del sistema".

Si los datos y el código de la aplicación se deben mantener confidenciales, sugiero el manejo de los datos en forma cifrada siempre que sea posible.

Por supuesto, un administrador podría tomar medidas contra eso, pero sigue siendo un mejor enfoque que solo depender de los permisos del sistema solamente.

La auditoría de las acciones de un administrador con auditd por otro equipo podría ser más efectiva que paralizar una cuenta de administrador y dificultar las tareas diarias.

Es posible que pueda ocultar algo a un administrador del sistema si está dispuesto a gastar algo de dinero en hacerlo (esto puede no ser un gran problema ya que su escenario se refiere a los secretos comerciales de una empresa de inversión) y acepta otros riesgos.

La idea básica aquí se basa en la implementación de un rootkit residente del BIOS que oculta el acceso a una funcionalidad específica en el sistema operativo. Como probablemente tenga servidores modernos, estarían equipados con UEFI, una nueva forma de BIOS. El firmware UEFI admite la carga de un fragmento de código denominado Update Capsule.

En las máquinas basadas en Windows, esta funcionalidad ha sido utilizada por compañías como Lenovo para instalar software persistente, como se puede leer aquí y aquí . Se puede encontrar un artículo de Intel que describe esta funcionalidad en máquinas basadas en Linux aquí .

La Update Capsule contendría el "rootkit", en este caso, un fragmento de código personalizado que siempre se cargaría cuando se iniciaran los servidores y tendría algunos componentes que se ayudarían a controlarse entre sí (para garantizar que la parte UEFI no se haya sido sobrescrito, etc).

Exactamente qué acceso al sistema operativo tendría que bloquear este código depende de la naturaleza de los secretos comerciales (ya sea un código en ejecución, valores en alguna base de datos u otra cosa).

Si esta sería la solución correcta depende de factores como la naturaleza exacta de su entorno (ya sea que use máquinas virtuales o no, qué tipo de configuración de falla tiene, etc.).

Y luego esto también viene con la advertencia de que nada es absolutamente infalible. Así, por ejemplo, tendría que confiar en los desarrolladores (o contratar a otras personas para que verifiquen el código fuente, por ejemplo, puertas traseras). Además, si el administrador del sistema tiene acceso físico al hardware (los servidores reales) donde residen los secretos comerciales, es posible que pueda sortear esta configuración.

¿La computadora de desarrollo y la computadora de producción son iguales? De lo contrario, puede mantener el código fuente en una computadora (acceso altamente restringido), compilar utilizando la ofuscación de código y usar el código compilado en el clúster de producción, con el código que necesita un PW antes de ejecutarse.

Si desea que alguien que no sea usted mismo administre los sistemas que contienen información confidencial. Se reduce a contratar al administrador correcto en el que puede confiar y tiene la ética de no abusar de sus poderes para proteger los datos de la empresa. También requiere tener los acuerdos sobre no divulgar dicha información y tener repercusiones legales en caso de que haya un error ético.

Después de haber sido administrador de sistemas Jr. en una empresa de desarrollo de software, mi trabajo consistía en mantener los sistemas críticos. Muchos de estos sistemas contenían el código fuente, correos electrónicos confidenciales y datos financieros de la compañía. Teniendo ese poder, hice mi trabajo proteger los datos de aquellos que no tenían permiso para ver dichos datos. Además de ser administrador de sistemas, no miraría los datos porque estaban fuera del alcance de mi trabajo. Si fuera necesario examinar algunos de estos datos para realizar mi trabajo, pediría autorización antes de hacerlo.

Hay algunas cosas que puedes hacer

• conceder permisos de forma restrictiva a sysadmin
• cifrar datos confidenciales
• acuerdo NDA con sysadmin
• almacenar datos en un sistema remoto donde solo las personas de confianza tienen acceso