Estimados amigos de Inseguros !!!
El control 4.6 del CIS dice una cosa muy concreta: la gestión remota de los canales de administración tiene que hacerse de forma segura y controlada.
Traducido al mundo real: todo lo que sea administrar sistemas, redes, cloud o aplicaciones, tiene que ir por canales seguros. Protocolos cifrados, superficies mínimas, y con un modelo de administración pensado, no improvisado.
Porque el problema no es “hacer RDP”. El problema es desde dónde lo haces, con qué identidad lo haces y qué estás exponiendo.
Lo típico que se ve en entornos es justo lo contrario de lo que pide este control: gente administrando con su equipo de productividad, con el mismo usuario que usa para el correo, navegando por Internet, instalando cosas… y luego ese mismo equipo hace RDP al DC, al servidor, al appliance, a lo que sea. Eso es una receta perfecta para que un día te roben credenciales privilegiadas.
Este control insiste en separar mundos. Equipo de productividad es una cosa. Administración es otra. Para administrar, hace falta un entorno dedicado, fortificado, con segundo factor, con identidad dedicada. No es lo mismo “jmolina@” que “jmolina-admin”. Y no es lo mismo “puedo hacer de todo desde cualquier sitio” que “solo puedo administrar desde un sitio controlado”.
Y luego está la otra parte que se ve muchísimo: interfaces de administración expuestas donde no toca. Portales de gestión en Internet. O incluso en la red interna, pero accesibles desde la red de usuarios. Eso no debería existir. Administración y usuarios no son el mismo plano. Hay que segmentar y tratar los servidores como si fueran desde fuera: superficie mínima, control, y canales seguros.
Aquí aparecen varios conceptos que encajan muy bien con el 4.6:
Bastion / jump server. Un punto de salto para administrar, y desde ahí haces la gestión. Y si ese bastión está bien montado, se registra lo que se hace: a nivel de red y a nivel de comandos.
Just-in-time. No es “tienes acceso siempre”. Es “te dejo administrar esto durante dos horas, desde esta IP, con esta cuenta, y luego se revoca”. Menos tiempo, menos exposición.
Cuentas privilegiadas sin Internet. La cuenta admin no tiene por qué navegar. Ni abrir correos. Ni usar aplicaciones de productividad. Admin es admin.
Certificados y autenticación fuerte. No depender solo de una contraseña. Certificado personal, segundo factor físico, y control de la identidad.
Y por supuesto, monitorización. Siempre monitorización. Si alguien intenta acceder a un canal de administración desde un sitio raro, o si hay patrones extraños, eso tiene que verse.
En cloud esto se entiende muy fácil. ¿Tiene sentido poder administrar Azure desde cualquier lugar del mundo? En muchos casos, no. Se puede decidir que solo se administra desde sede, desde equipos enrolados, con políticas de acceso condicional. Y luego se deja un break glass super fortificado para emergencias. No es “porque sí”. Es porque es control de superficie.
Y en on-prem pasa igual. El ejemplo típico: SQL Server. En vez de hacer RDP al servidor y luego abrir el Management Studio allí, se trabaja con un salto controlado. Se evita el “RDP alegre” como hábito, y se diseña un canal de administración seguro por entorno.
Este control, al final, obliga a hacer una reflexión por activo: cómo se administra de forma segura este sistema. No existe una receta universal. Existe un criterio: canales seguros, exposición mínima, identidades dedicadas, registro y control.
Si estás aplicando Controles CIS y quieres hacerlo con mentalidad de empresa, en la academia tienes formación orientada a entornos reales en www.seguridadsi.com.
Gracias por leerme !!!
