Introducción
Una de las partes más interesantes de mi trabajo es la correspondencia que recibo de los lectores detallando sus propios escenarios y preguntas. A menudo escucho de personas que desean reemplazar sus soluciones VPN actuales con DirectAccess. Si bien siempre me alegra escuchar que la gente está pensando en implementar DirectAccess (en parte porque mi esposo trabaja con UAG DirectAccess y las noticias lo hacen feliz), tengo que recordarles que, si bien DirectAccess tiene muchas características que podrían hacerte pensar en una VPN, DirectAccess no es una VPN. De hecho, es mucho más. Una forma de entender cómo se diferencia el cliente DirectAccess del cliente VPN es ponerlo en perspectiva con otros tipos de clientes en su red y observar los problemas de conectividad y seguridad que son importantes con cada uno de estos tipos de clientes.
Tipos de clientes
Para comenzar esta discusión, supongamos que hay tres tipos generales de clientes que son miembros de dominio y están bajo su control administrativo. Cada uno de los tipos de cliente se consideraría un «cliente administrado» en mayor o menor medida:
- El «atornillado» red corporativa del cliente
- itinerancia Del cliente VPN de acceso remoto
- El cliente de DirectAccess
El «Atornillado» red corporativa del Cliente
El «atornillado» red corporativa del cliente es un sistema que puede o no puede estar, literalmente, atornillar, pero de cualquier manera, nunca sale de la intranet corporativa. Este sistema es un miembro de dominio, es un sistema administrado siempre y nunca está expuesto a ninguna otra red. Su acceso a Internet siempre está controlado por un firewall de inspección de la capa de aplicación, como un firewall TMG. Las ranuras USB y otros medios extraíbles están bloqueadas administrativa o físicamente y el acceso físico al edificio donde reside solo se permite a los empleados y a los invitados acompañados. Estos sistemas tienen instalado software antimalware, se configuran a través de una Directiva de grupo u otro sistema de administración para mantener la configuración de seguridad deseada, y la Protección de acceso a la red (NAP) está habilitada en la red para evitar que los sistemas no autorizados se conecten a la red y accedan a los recursos corporativos. El firewall de Windows con seguridad avanzada está habilitado y configurado para reducir el riesgo de amenazas introducidas por los gusanos de red.
Este concepto del cliente corpnet «atornillado» se acerca lo más posible al ideal de cliente seguro que uno pueda imaginar:
- El sistema nunca está expuesto a redes no confiables.
- El sistema siempre se administra.
- El sistema siempre está bajo el control de TI corporativa.
- El acceso al sistema está limitado a empleados e invitados acompañados.
- «El acceso» Fuera de banda » al sistema es limitado porque los puertos para medios extraíbles están deshabilitados administrativa o físicamente.
- Un firewall de Internet de inspección de la capa de aplicación, como TMG, evita que los usuarios descarguen exploits desde Internet.
- NAP reduce los riesgos de que los clientes no administrados se conecten a la red y propaguen malware obtenido de otras redes.
- Es poco probable que el sistema sea robado debido a las medidas físicas tomadas para «conectar» al cliente a la infraestructura física.
Si bien puede imaginar que este es el sistema ideal en términos de seguridad de red, ¿qué tan realista es esta caracterización? ¿Cuántos sistemas cliente tiene ahora que nunca salen de corpnet? E incluso con estos controles en su lugar, ¿cuán inmunes son estas máquinas para atacar? Considere lo siguiente:
- La ingeniería social es un método común que permite a los atacantes obtener acceso físico a máquinas dirigidas específicamente para que se puedan instalar malware y troyanos en clientes corpnet «atornillados».
- Incluso con los puertos físicos desactivados, es probable que los usuarios tengan acceso al menos a una unidad óptica, en cuyo caso el malware obtenido de algún lugar externo puede llegar al cliente corpnet «atornillado».
- Si bien un firewall de inspección de capa de aplicación puede ayudar mucho a evitar que el malware y los troyanos entren en corpnet, si el firewall no realiza una inspección SSL de salida (HTTPS), esencialmente no tiene valor, porque los troyanos pueden usar el canal SSL seguro (y no inspeccionado) para llegar a sus controladores. Además, los usuarios pueden aprovechar los proxies anónimos a través de una conexión SSL inesperada.
- Si se instalara un troyano en el cliente corpnet «atornillado», un troyano bien escrito usaría HTTP o SSL para conectarse a su controlador y lo más probable es que se conecte a un sitio que aún no se ha clasificado como «peligroso». Incluso si la organización utiliza un enfoque de» lista blanca «para la seguridad, el atacante podría secuestrar un» sitio seguro » de bajo perfil (tal vez con envenenamiento de DNS) e instruir al troyano para que se conecte a ese sitio para que pueda recibir comandos de control.
- Los usuarios pueden intentar eludir sus controles si no pueden visitar sitios o acceder a los recursos de Internet que desean. Si los usuarios utilizan conexiones inalámbricas, pueden desconectarse fácilmente de la red inalámbrica corporativa y conectarse a un teléfono conectado para acceder a los recursos que están bloqueados por el firewall corporativo y luego volver a conectarse a corpnet después de obtener lo que desean. Los usuarios con una conexión inalámbrica o cableada pueden conectar fácilmente una «tarjeta de aire» inalámbrica para conectarse a una red sin filtrar y comprometer la máquina a través de la puerta de enlace alternativa. En este escenario, el cliente corpnet «atornillado» de repente adquiere algunas de las características del cliente de acceso remoto itinerante.
La cuestión no es que la diligencia debida en materia de seguridad sea una lección de inutilidad. En cambio, lo que debe quedar claro es que incluso en la situación ideal del cliente corpnet» atornillado», hay muchas cosas que pueden salir mal y llevar a un incidente de seguridad. Aún debe hacer todo lo posible para asegurarse de que sus máquinas estén seguras, actualizadas y bien administradas, pero debe poner en perspectiva cómo se comparan estos clientes corpnet «aislados» e inmóviles con otros tipos de sistemas de clientes corporativos.
Finalmente y quizás lo más importante, vale la pena considerar si el concepto de cliente corpnet «atornillado» solo podría ser de interés académico. ¿Cuántos de estos clientes existen en redes corporativas hoy en día, especialmente en redes donde la mayoría de los empleados son trabajadores del conocimiento? En un entorno de trabajo de tareas, puede pensar en VDI como una solución viable, porque las tareas que realizan no requieren la amplia gama de funciones que proporciona un entorno de PC completo, pero los trabajadores del conocimiento necesitan la flexibilidad y la potencia que proporciona una plataforma de PC totalmente habilitada. Además, cada vez más empresas reconocen las ventajas del teletrabajo y cada vez más empleados trabajan desde casa o se conectan a corpnet mientras viajan. Lo que nos lleva a:
La Itinerancia de Cliente VPN de Acceso Remoto
En la década de 1990, la «atornillado» red corporativa del cliente era la norma. En la segunda década del siglo XXI, los trabajadores son mucho más móviles y el cliente atornillado ha dado paso al cliente VPN de acceso remoto en itinerancia. Los trabajadores del conocimiento tienen potentes computadoras portátiles que llevan al trabajo, a sus hogares, a los sitios de los clientes, a los hoteles, a las conferencias, a los aeropuertos y a cualquier otro lugar del mundo donde haya una conexión a Internet. Y en muchos casos, después de estar en una o más de estas ubicaciones, traen estas computadoras portátiles de vuelta a corpnet.
El cliente VPN de acceso remoto itinerante presenta un perfil de amenaza muy diferente en comparación con el mítico cliente corpnet» atornillado». Al igual que el cliente corpnet» atornillado», estas máquinas son miembros de dominio, tienen instalado software antimalware, tienen habilitado el Firewall de Windows con Seguridad Avanzada y están configuradas inicialmente para cumplir completamente con la política de seguridad corporativa. El equipo cliente VPN móvil, cuando se entrega por primera vez al usuario, es tan seguro como el cliente corpnet «atornillado».
Sin embargo, ese estado de configuración y seguridad no dura mucho tiempo. Es posible que el usuario no se conecte a corpnet a través de la conexión VPN durante días o semanas. O el usuario puede conectarse diariamente durante una o dos semanas, y luego no conectarse durante unos meses. Durante el ínterin, el equipo cliente VPN itinerante, lenta pero seguramente, no cumple con las normas. La directiva de grupo no está actualizada, las actualizaciones antivirus pueden completarse de forma irregular, otro software antimalware puede quedar desactualizado. Es posible que los controles de seguridad y cumplimiento que se imponen a los clientes ubicados en corpnet nunca lleguen a los clientes VPN de acceso remoto en itinerancia porque no se conectan a través de la VPN de manera oportuna.
El cliente VPN itinerante se aleja cada vez más de su configuración de cumplimiento de seguridad definida y el problema se agrava porque la máquina está conectada a varias redes de confianza baja y desconocida. Estas redes no administradas o mal administradas pueden estar llenas de gusanos de red y el equipo puede estar expuesto a usuarios que tienen acceso físico o lógico al equipo y que de otro modo no tendrían acceso al equipo si nunca abandonara corpnet.
¿Qué sucede cuando el usuario devuelve a la red corporativa este equipo que no cumple con las normas? ¿Qué pasa si el ordenador se ve comprometido por gusanos, virus, troyanos y otras formas de malware? El daño puede ser limitado si tiene la protección de acceso a la red habilitada en la red, pero ¿cuántas redes han activado NAP, a pesar de que ha estado disponible durante años como parte de la plataforma Windows Server 2008 y superior?
Por supuesto, el usuario ni siquiera necesitaría traer el equipo comprometido de vuelta a la red. Supongamos que el usuario ha conectado la computadora a varias redes diferentes, la ha expuesto a varios usuarios de confianza desconocidos y ha terminado con una computadora comprometida. Luego, el usuario debe cambiar su contraseña después de tres meses para que se conecte a través de VPN para realizar el cambio de contraseña. Los resultados de seguridad potencialmente desastrosos serían los mismos que si el equipo se devolviera a la red corporativa física.
Como puede ver, el cliente VPN itinerante sufre una serie de problemas de seguridad en comparación con el cliente «atornillado» histórico:
- El cliente VPN itinerante está conectado a corpnet de forma intermitente, o a veces nunca, y, por lo tanto, queda fuera del alcance de las directivas de grupo y otros sistemas de administración.
- El cliente VPN itinerante está expuesto a redes no administradas y mal administradas, lo que aumenta la «superficie atacante» potencial a la que está expuesto el cliente VPN de acceso remoto itinerante, en comparación con la máquina que nunca sale de corpnet.
- Los clientes VPN itinerantes pueden acceder a Internet y los usuarios pueden hacer lo que quieran mientras están conectados a sitios de Internet, porque normalmente no hay filtrado de conexiones a Internet cuando el cliente VPN no está conectado a corpnet.
- Si el cliente VPN está configurado para deshabilitar el túnel dividido, es posible que se vea obligado a usar puertas de enlace de acceso a Internet corporativas durante el tiempo que el cliente esté conectado. Sin embargo, una vez que se interrumpe la conexión VPN, el usuario puede hacer lo que quiera de nuevo, y puede compartir cualquier malware o troyanos que el equipo adquirió mientras estaba desconectado de la VPN cuando se conecta de nuevo.
- Los usuarios pueden evitar conectarse a la VPN porque los tiempos de inicio de sesión son lentos, la conectividad es inconsistente y toda la experiencia de la VPN no es óptima, lo que aumenta aún más el riesgo de incumplir el cumplimiento de la seguridad y aumenta el riesgo de compromiso.
Por lo tanto, el cliente VPN itinerante es significativamente diferente desde una perspectiva de seguridad, en comparación con el cliente corpnet «atornillado»:
- La política de grupo puede o no actualizarse oportunamente.
- El software antivirus puede o no actualizarse oportunamente.
- El software antimalware puede o no actualizarse oportunamente.
- Otros métodos de gestión y control pueden o no ser capaces de reconfigurar el cliente a tiempo.
- El número de personas que tienen acceso al equipo cliente VPN físico es potencialmente mayor que el de las que tienen acceso a un cliente corpnet «atornillado», incluidos no solo los familiares y amigos del usuario, sino también las personas que podrían robar el equipo.
La diferencia clave entre el cliente VPN itinerante y el cliente corpnet «atornillado» es que el cliente VPN no siempre se administra y está expuesto a un mayor número de amenazas programáticas y físicas. Sin embargo, hay formas de mitigar algunas de estas amenazas y muchas empresas ya han introducido métodos para hacerlo, como los siguientes:
- Implementación de cifrado de disco (como BitLocker) para que, si se roba una máquina, el disco no se pueda leer mediante un «ataque sin conexión». El cifrado de disco también puede emplear un método de acceso basado en» clave » al disco, de modo que si la máquina está apagada, la máquina no arrancará sin la clave.
- Se requiere autenticación de dos factores para iniciar sesión en la máquina, y el segundo factor también se requiere para desbloquear la máquina o despertarla del modo de reposo.
- Implementación de NAP o tecnologías similares para probar la seguridad de los terminales antes de que se permita el acceso a corpnet a la máquina. Si la máquina no puede reparar, no se permite el acceso a corpnet.
- Garantizar que las cuentas de usuario utilizadas para iniciar sesión en la red no sean las mismas que las cuentas administrativas utilizadas para administrar servidores y servicios de red, a fin de evitar ataques de elevación.
- Alejar el centro de datos de todos los clientes, tanto de VPN como de corpnet, para que el centro de datos esté separado física y lógicamente de toda la población de clientes.
El uso de una de estas mitigaciones contribuirá en gran medida a reducir la amenaza potencial expuesta por los clientes VPN de acceso remoto. Aunque tal vez no nivele el campo con el cliente corpnet «atornillado», puede haber escenarios en los que el cliente VPN de acceso remoto itinerante en realidad presente un riesgo menor. Examinaremos uno de ellos más adelante en este artículo.
El Cliente de DirectAccess
Ahora llegamos al tema del cliente de DirectAccess. Al igual que el cliente VPN, esta computadora puede moverse desde corpnet, a una habitación de hotel, a un centro de conferencias, a un aeropuerto y a cualquier otro lugar en el que se encuentre un cliente VPN de acceso remoto itinerante. El cliente de DirectAccess, durante su vida útil, estará conectado a redes de confianza y no de confianza, al igual que el cliente VPN de acceso remoto en itinerancia, y el riesgo de compromiso físico del equipo también es similar al que se ve con el cliente VPN de acceso remoto en itinerancia. Por lo tanto, parecería que el resultado de una comparación entre el cliente DirectAccess y el cliente VPN es que son esencialmente los mismos desde una perspectiva de amenaza.
sin Embargo, hay algunas diferencias significativas entre la itinerancia de cliente VPN de acceso remoto y el cliente de DirectAccess:
- El cliente de DirectAccess siempre es administrado. Mientras el equipo cliente de DirectAccess esté encendido y conectado a Internet, el cliente de DirectAccess tendrá conectividad con servidores de administración que mantienen al cliente de DirectAccess dentro del cumplimiento de la configuración de seguridad.
- El cliente de DirectAccess siempre se puede reparar. Si necesita conectarse al cliente de DirectAccess para realizar una configuración de software personalizada o solucionar un problema en el cliente de DirectAccess, no hay problema para obtener acceso porque la conexión entre el cliente de DirectAccess y las estaciones de administración de TI es bidireccional.
- El cliente de DirectAccess utiliza dos túneles separados para conectarse. El cliente de DirectAccess solo tiene acceso a la infraestructura de administración y configuración a través del primer túnel. El acceso general a la red no está disponible hasta que el usuario inicia sesión y crea el túnel de infraestructura.
Cuando se compara el cliente de DirectAccess con el cliente VPN de acceso remoto, el cliente de DirectAccess puede presentar un perfil de amenaza mucho menor que el cliente VPN, porque el cliente de DirectAccess siempre está bajo el comando y control de la TI corporativa. Esto contrasta marcadamente con los clientes VPN de acceso remoto itinerantes que pueden conectarse o no a la red corporativa durante largos períodos de tiempo, lo que conduce a una entropía de configuración que puede aumentar significativamente el riesgo de comprometer el sistema. Además, las mitigaciones mencionadas anteriormente que se aplican al cliente VPN de acceso remoto también se pueden usar con el cliente DirectAccess.
Aquí es donde llegamos al punto de hacer una distinción crítica: al comparar el cliente VPN de acceso remoto móvil con el cliente de DirectAccess, todas las pruebas apuntan al hecho de que el cliente de DirectAccess presenta un perfil de amenaza más bajo. Las comparaciones entre el cliente de DirectAccess y el cliente corpnet «atornillado» son probablemente solo de interés académico,ya que pocas organizaciones tienen estos clientes «atornillados» y la mayoría de las empresas están permitiendo a los usuarios con acceso VPN llegar a los recursos de corpnet, y tanto los clientes VPN como los clientes de DirectAccess entrarán y saldrán de la red corporativa, haciendo que la división entre el «cliente corpnet» y el «cliente remoto» prácticamente carezca de sentido desde una perspectiva de seguridad.
Conclusión
He escuchado a varias personas expresar su preocupación por las posibles amenazas que un cliente de DirectAccess puede presentar a la red corporativa debido a su capacidad «siempre activa». Sin embargo, esta preocupación se expresa sin considerar el contexto del cliente DirectAccess y cómo se compara con el cliente VPN de acceso remoto tradicional. A partir de los análisis proporcionados en este artículo, debe quedar claro en este punto que, debido a que el cliente de DirectAccess siempre está administrado, siempre actualizado y siempre dentro del comando y control de la TI corporativa, su perfil de amenaza es de hecho mucho más bajo que el presentado por el cliente VPN de acceso remoto.