Hello Everyone!! Continuamos en Obss con el sexto capitulo de la importancia de una buena estrategia Zero Trust dentro de nuestra organización. En este capitulo vamos a presentar varios escenarios posibles para la implementación de una ZTA.

Cualquier organización puede diseñarse teniendo en cuenta los principios de la confianza cero. La mayoría de las organizaciones ya cuentan o deberían contar con algunos elementos de confianza cero en su infraestructura empresarial (mas o menos básicos) o están en vías de implantar políticas y buenas prácticas de seguridad y control de la información.

La ZTA tiene sus raíces en organizaciones que están distribuidas geográficamente, bien a nivel nacional y/o internacional y/o tienen una fuerza de trabajo altamente móvil.

En los casos de uso que vamos a exponer a continuación, la ZTA no se indica explícitamente, ya que es probable que la organización disponga de infraestructuras basadas en el perímetro y posiblemente en la ZTA. Como hablaremos en otro punto más adelante (ver punto migración hibrida y arquitectura basada en el perímetro), es probable que haya un periodo en el que los componentes de la ZTA y la infraestructura de red basada en el perímetro estén funcionando simultáneamente en una empresa.

Pero vamos a meternos en harina.

Empresa con ubicaciones remotas

Como hemos comentado con anterioridad dentro de ubicaciones remotas consideramos sucursales de la organización dentro de una misma localidad, provincia, comunidad, estado o de forma internacional.

El escenario más común es el de una organización con una sede central y una o más ubicaciones geográficamente dispersas que no están unidas por una conexión de red física propiedad de la empresa (ver la figura de arriba). Es posible que los usuarios de la ubicación remota no dispongan de una red local completa propiedad de la empresa, pero aun así necesiten acceder a los recursos de la empresa para realizar sus tareas.

La empresa puede tener uno o varios enlace MPLS (Multiprotocol Label Switch) con la red de la sede central de la organización, pero puede no tener el ancho de banda adecuado para todo el tráfico o puede no desear que el tráfico destinado a aplicaciones/servicios basados en la nube atraviese la red de la sede central de la organización. Del mismo modo, los usuarios pueden trabajar de forma remota o estar en una ubicación remota y utilizar dispositivos de propiedad de la empresa o personales (BYOD). En tales casos, una organización puede desear conceder acceso a algunos recursos (por ejemplo, calendario del empleado, correo electrónico), pero denegar el acceso o restringir las acciones a los recursos más sensibles (por ejemplo, base de datos, etc.).

En este caso de uso, la(s) PE/AP(s) a menudo se aloja(n) como un servicio en la nube (que normalmente proporciona una disponibilidad superior y no requerirá que los trabajadores remotos dependieran de la infraestructura de la empresa para acceder a los recursos en la nube) con recursos finales que tienen un agente instalado o que acceden a un portal de recursos.

Puede que no sea lo más adecuado tener el PE/AP alojado en la red local de la organización, ya que las oficinas y los trabajadores remotos deben enviar todo el tráfico de vuelta a la red de la organización para llegar a las aplicaciones/servicios alojados en los servicios en nube.

Empresa con soluciones en la nube o multi-nube

Un escenario cada vez más común para desplegar una ZTA es el de una organización que utiliza varios proveedores de nube (ver la imagen de abajo). En este escenario, la organización tiene una red local pero utiliza dos o más proveedores de servicios en la nube para alojar aplicaciones/servicios y datos. A veces, la aplicación/servicio se aloja en un servicio en la nube independiente de la fuente de datos. Por motivos de rendimiento y facilidad de gestión, la aplicación alojada en el proveedor de nube A debería poder conectarse directamente a la fuente de datos alojada en el proveedor de nube B en lugar de obligar a la aplicación a realizar un túnel de vuelta a través de la red de la organización.

Este escenario es la implementación servidor-servidor de la especificación del perímetro definido por software (SDP, por sus siglas en ingles Software Defined Permiter) de la CSA (Cloud Security Alliance). A medida que las organizaciones se mueven hacia más aplicaciones y servicios alojados en la nube, se hace evidente que confiar en el perímetro de la empresa para la seguridad se convierte en una responsabilidad. Como se ha explicado en otros capítulos, los principios ZTA consideran que no debería haber diferencia entre la infraestructura de red propiedad de la empresa y operada por ella y la infraestructura propiedad de cualquier otro proveedor de servicios y operada por él.

El enfoque ZT para el uso de nubes múltiples consiste en colocar PEP en los puntos de acceso de cada aplicación/servicio y fuente de datos. Los PE y AP pueden ser servicios ubicados en cualquiera de las dos nubes o incluso en un tercer proveedor de nube. El usuario (a través de un portal o de un agente local instalado) accede entonces directamente a los PEP. De este modo, la organización puede seguir gestionando el acceso a los recursos aunque estén alojados fuera de ella. Uno de los retos a los que se enfrenta es este escenario es que los distintos proveedores de nube tienen formas únicas de implementar funcionalidades similares. Los roles implicados de la organización tendrán que ser conscientes de cómo implementar su ZTA empresarial con cada proveedor de nube que utilicen.

Empresa con servicios contratados y/o acceso de usuarios no corporativos

Otro escenario que nos encontramos con asiduidad es el de una organización que incluye visitantes in situ y/o proveedores de servicios contratados que requieren un acceso limitado a los recursos de la empresa para realizar su trabajo (ver la figura de abajo).

Tomemos como ejemplo, una organización que tiene sus propias aplicaciones/servicios, bases de datos y activos de forma local. Esto incluye servicios contratados a proveedores que pueden estar ocasionalmente in situ o no, para proporcionar mantenimiento (por ejemplo, sistemas inteligentes de calefacción e iluminación que son propiedad y están gestionados por proveedores externos). Estos usuarios y proveedores de servicios necesitarán conectividad de red para realizar sus tareas. Una organización de confianza cero podría facilitar esto permitiendo a estos dispositivos y a cualquier técnico de servicio visitante el acceso a Internet mientras se ocultan los recursos de la empresa.

En este escenario, la empresa también tiene un centro de reuniones donde los visitantes interactúan con los empleados. Una vez más, con un enfoque ZTA de SDP, los endpoints de los usuarios y los visitantes se diferencian y pueden acceder a los recursos de la organización adecuados. Los visitantes de la organización pueden tener acceso a Internet pero no pueden acceder a los recursos de la organización. Es posible que ni siquiera puedan descubrir los servicios de la empresa a través de exploraciones de la red.

En este escenario, los PE y AP podrían estar alojados como un servicio en la nube o en la LAN (suponiendo un uso escaso tráfico de los servicios alojados en la nube). Los recursos de la empresa podrían tener un agente instalado (ver capítulos anteriores) o acceder a los recursos a través de un portal. Las AP garantizan que todos los activos que no pertenezcan a la organización (los que no tienen agentes instalados o no pueden conectarse a un portal) no puedan acceder a los recursos locales, pero sí a Internet.

Colaboración entre Organizaciones

Otro escenario típico que nos encontramos es la colaboración entre organizaciones. Por ejemplo, hay un proyecto en el que participan empleados de la empresa A y de la empresa B (ver imagen de abajo). Las dos organizaciones pueden ser públicas, una organización pública y una empresa privada o dos organizaciones privadas. La organización A gestiona la base de datos utilizada para el proyecto, pero debe permitir el acceso a los datos a determinados usuarios de la organización B. La organización A puede crear cuentas especializadas para que los usuarios de la organización B accedan a los datos necesarios y denegar el acceso a todos los demás recursos, pero esto puede volverse rápidamente difícil de gestionar. Tener a ambas organizaciones inscritas en un sistema de gestión de identificación federada permitiría establecer más rápidamente estas relaciones, siempre que las PEP de ambas organizaciones puedan autenticar a los sujetos en una comunidad de identificación federada.

Este escenario puede ser similar al primer escenario organizaciones con ubicaciones remotas, ya que los usuarios de ambas organizaciones pueden no estar localizados en las infraestructuras de red de sus organizaciones y el recurso al que necesitan acceder puede estar dentro de un entorno empresarial o alojado en la nube. Esto significa que no es necesario que existan complejas reglas de cortafuegos o listas de control de acceso (ACL) en toda la organización que permitan a determinadas direcciones IP pertenecientes a la organización B acceder a los recursos de la primera en función de las políticas de acceso de esta última. La forma de lograr este acceso depende de la tecnología utilizada. De forma similar al primer escenario, un PE y un AP alojados como servicio en la nube pueden proporcionar disponibilidad a todas las partes sin tener que establecer una VPN o similar. A los usuarios de la organización B se les puede pedir que instalen un agente de software en su activo o que accedan a los recursos de datos necesarios a través de un gateway web (ver capítulos anteriores).

Empresas con servicios públicos al cliente

No podemos dejar pasar la oportunidad de hablar en este capitulo, aunque no toca de forma directa la ZTA de las empresas que poseen bien paginas web públicas o bien marketplace (aunque en este último caso siempre debería implementar una DMZ, por sus siglas en ingles demilitarized zone, entre el front-end y las base de datos).

Una característica común en muchas organizaciones es poseer un servicio de cara al público que puede o no incluir el registro del usuario (es decir, los usuarios deben crear o haber recibido un conjunto de credenciales de inicio de sesión).

Estos servicios pueden estar destinados al público en general, a un conjunto de clientes con una relación comercial existente o a un conjunto especial de usuarios ajenos a la organización.

Para un recurso general de cara al público que no requiere credenciales de inicio de sesión para acceder (por ejemplo, una página web pública), los principios de la ZTA no se aplican directamente. La organización no puede controlar estrictamente el estado de los recursos solicitados, y los recursos públicos anónimos (por ejemplo, una página web pública) no requieren credenciales para poder acceder a ellos.

Las organizaciones deben establecer políticas para los usuarios públicos registrados, como los clientes (es decir, con los que se posee una relación comercial). Si se exige a los usuarios que se identifiquen a través de credenciales, la organización debe establecer políticas relativas a la longitud de la contraseña, el ciclo de vida y otros detalles, y puede proporcionar MFA como opción o requisito. Por otro lado, lo abordaríamos la política de forma diferente si permitimos el acceso a través de entidades certificadoras.

Sin embargo, las organizaciones están limitadas en las políticas que pueden implementar para esta clase de usuarios. La información sobre las solicitudes entrantes puede ser útil para determinar el estado del servicio público y detectar posibles ataques que se hagan pasar por usuarios legítimos.

La empresa organización, por otro lado, debe ser consciente de los reglamentos relativos a la protección de datos que se puede recopilar y registrar sobre los usuarios de ese servicio.