Consultor de administración remota de Linux: práctica recomendada [cerrado]

Estamos contratando un consultor en India como nuestro Administrador de Linux. No lo conocemos bien y requiere acceso de root a todos nuestros servidores para hacer su trabajo (incluida una auditoría de seguridad).

¿Cuál es la mejor práctica para habilitar a un consultor remoto para tal trabajo de modo que estemos protegidos contra cualquier actividad maligna?

Gracias por adelantado.

No hacerlo . Además, corre tanto peligro de ineptitud como de malicia por lo que he visto de la forma típica en que las empresas manejan esto.

Me gustaría decir que probablemente haya grandes administradores de sistemas en India, pero la forma en que muchas empresas hacen las cosas es terrible.

Si está pasando por un taller de carrocería, también es probable que vea un corte bastante grande para ellos, y es probable que muchos de ellos no hayan investigado adecuadamente a sus empleados. He hablado con tres, uno de los cuales trabajé y ninguno de ellos ha realizado entrevistas técnicas.

Entonces, si debe contratar a alguien de forma remota, por el amor de Dios, entrevístelo usted mismo y asegúrese de que conozca su trabajo. La administración del sistema es demasiado importante para entregarla a alguien a ciegas

Ahora que he manejado la parte de "ineptitud",

La administración es una frase bastante amplia. Y alguien con acceso de root puede hacer cualquier cosa . Ahora, personalmente , creo que crear una cuenta para el administrador y darle la capacidad de elevarse a través de sudo es una mejor idea (que su sistema de administración de configuración debería manejar si tiene muchos servidores). Dicho esto, incluso eso depende de una cierta cantidad de confianza. Hay tantas historias sobre el daño que puede hacer un administrador de sistemas descontento. ¿Cambiar todas tus contraseñas? Claro que podría entrar eventualmente, pero no es trivial, y probablemente costaría más de lo que está ahorrando.

Entonces, considere un local. De lo contrario, considere a alguien que haya examinado usted mismo y haya contratado directamente .

Como se ha mencionado, no hagas esto.

La única forma en que podrá protegerse es haciendo algo como esto:

1. Insista en que el consultor use un sistema de gestión de configuración de su elección.
2. El consultor escribirá manifiestos de gestión de configuración para las acciones que necesita completar.
3. El consultor probará los manifiestos en un sistema de prueba.
4. Cuando esté listo, el consultor confirmará la configuración en un repositorio de código.
5. Todos los cambios son revisados ​​por un miembro de su personal u otro consultor que no tiene absolutamente ninguna relación con el primero, y no tiene forma de contactarlos.
6. Una vez que se firman los cambios, usted o un miembro de su personal los aplica al servidor. El consultor original no debe tener acceso a ninguno de sus sistemas.

Como debería quedar claro, este es un proceso muy torpe e ineficiente, pero si insiste en aceptar el trabajo de un individuo no confiable, esta es una forma de manejar las cosas.

Sin embargo, como recomendé, es mucho mejor contratar a un individuo conocido y confiable.

¿Cuál es la mejor práctica para habilitar a un consultor remoto para tal trabajo de modo que estemos protegidos contra cualquier actividad maligna?

Desde una perspectiva legal: diligencia debida de antemano y sanciones estrictas por incumplimiento de contrato.

Comienza con las buenas prácticas habituales de contratación que también se aplican cuando se contrata personal en las instalaciones (y / o proveedores de servicios) que incluyen verificar el currículum provisto, solicitar transcripciones educativas y números de certificación, verificar y llamar a sus referencias, entrevistar, tal vez incluso una verificación de antecedentes o una revisión de seguridad, etc., etc.

Luego aplique la zanahoria : pague un valor justo, ofrezca un trabajo atractivo, colegas increíbles, buenas condiciones de trabajo y beneficios, etc. ( si paga cacahuetes, obtiene monos ) .

Y el palo : ¡incumplir los términos de su contrato de trabajo / servicio y enfermaremos a nuestros abogados y lo dejaremos en bancarrota!

Desafortunadamente, lo anterior se vuelve cada vez más difícil al cruzar fronteras y zonas horarias.

Una vez que decida contratar a alguien:

• directivas y políticas claras, las personas deben ser conscientes de lo que deberían y no pueden hacer.
• El principio de acceso mínimo se aplica, dificulta que las personas (accidentalmente o a propósito) hagan cosas que no deberían. Para el administrador típico del sistema, a menudo eso todavía significa acceso total, pero un auditor de seguridad, por ejemplo, no debería necesitar acceso completo de administrador, sino que simplemente puede solicitar a los administradores existentes que ejecuten un script en su nombre que recopile los detalles que necesita para hacer su informe. Tal script se puede verificar fácilmente de antemano.
• confiar pero verificar. Simplemente haga que el personal existente verifique el trabajo de un nuevo miembro y, como siempre, recopile información de auditoría.
• etcétera etcétera.

Esta pregunta detalla lo que generalmente les pido a mis clientes que hagan para establecer un acceso remoto para mí, que también podría ser un punto de partida para usted.

Me viene a la mente un método sistémico para protegerse, que no he visto mencionado.

Aloje sus instancias de Linux como máquinas virtuales en un hipervisor de virtualización (VMware, Xenserver, Hyper-V, etc.).

NO le dé acceso administrativo al administrador remoto al hipervisor. El administrador remoto solo obtendría acceso de root a las propias máquinas virtuales.

Implemente un sistema de respaldo basado en hipervisor (Unitrends, Veeam, vSphere Data Protection, etc.)

CONSERVE al menos una instantánea por día de cada VM Linux, retrocediendo en el tiempo que considere necesario.

NO le dé al administrador remoto acceso de escritura a los repositorios de respaldo.

Si hace estas cosas, tendrá instantáneas de respaldo de cada instancia de Linux sobre las cuales el administrador remoto no tiene control. Si el administrador remoto hace algo extraño, ya sea intencionalmente o accidentalmente, siempre puede montar una copia de seguridad antes de que ocurra el bloqueo para evaluar lo que sucedió y posiblemente recuperarse a un estado limpio.

Esto no será una prueba contra un ataque de canal lateral del hipervisor, que podría montarse desde una VM a la que el atacante tiene acceso de root.

Si sus copias de seguridad no van lo suficientemente atrás en el tiempo, esto no lo protegerá.

Debe confiar completamente en quien tenga el control de su hipervisor y la infraestructura de respaldo.

Si está haciendo esto en la nube (AWS, Azure, etc.), los detalles de implementación serán diferentes, pero el concepto general sería el mismo.

En esencia, divida las responsabilidades entre las partes que no son socios comerciales entre sí, además de contratar solo a personas de su confianza.

Dale su propia cuenta de usuario. Luego descubra exactamente a qué necesita acceso y concédale solo ese acceso, pero nada más. Por ejemplo, si necesita reconfigurar un servidor web Apache, use una ACL para darle acceso de escritura a los archivos de configuración de Apache y configúrelo sudopara permitirle reiniciar el servicio Apache pero no ejecutar ningún otro comando como root. Como siempre, guarde copias de seguridad de cualquier cosa a la que le esté dando acceso (en este caso, sus archivos de configuración de Apache).