Hello Everyone!! Continuamos en Obss con el quinto capitulo de la importancia de una buena estrategia Zero Trust dentro de nuestra organización. En este capitulo vamos a comenzar a desgranar los componentes lógicos de la ZTA.

Componentes Lógicos de una ZTA

Existen numerosos componentes lógicos que conforman un despliegue de ZTA en una organización. Estos componentes pueden funcionar como un servicio on-premise o a través de un servicio basado en la nube. El modelo de referencia que se muestra en la imagen anterior muestra la relación básica entre los componentes y sus interacciones.

Observar que se trata de un modelo ideal que muestra los componentes lógicos y sus interacciones. El punto de decisión de políticas (PDP) se desglosa en dos componentes lógicos: el motor de políticas y el administrador de políticas (lo trataremos con posterioridad). Los componentes lógicos de la ZTA utilizan un plano de control independiente para comunicarse, mientras que los datos de las aplicaciones se comunican en un plano de datos. (Ver el punto Componentes de Red más adelante)

Aunque hemos definido PDP y PEP con anterioridad vamos a comentar los elementos de la imagen con mas detalle:

• Motor de políticas (PE): Este componente es responsable de la decisión final de conceder acceso a un recurso a un usuario determinado. El PE utiliza la política de la organización, así como información procedente de fuentes externas (por ejemplo, sistemas CDM, servicios de inteligencia sobre amenazas, etc.) como datos de entrada a un algoritmo de confianza para conceder, denegar o revocar el acceso al recurso (Ver el punto Algoritmos de confianza más adelante). El PE está emparejado con el componente administrador de políticas. El motor de políticas toma y registra la decisión (como aprobada o denegada), y el administrador de políticas ejecuta la decisión.
• Administrador de políticas (AP): Este componente es responsable de establecer y/o cerrar la vía de comunicación entre un usuario y un recurso (mediante comandos a los PEP pertinentes). Generará cualquier token o credencial de autenticación y autenticación específicos de la sesión utilizados por un usuario para acceder a un recurso de la organización. Está estrechamente vinculado al PE y depende de su decisión para, en última instancia, permitir o denegar una sesión. Si se autoriza la sesión y se autentica la solicitud, el AP configura el PEP para permitir que se inicie la sesión. Si se deniega la sesión (o se anula una aprobación anterior), el AP indica al PEP que cierre la conexión. Algunas implementaciones pueden tratar el PE y el AP como un único servicio, pero atendiendo el objetivo de esta guía, vamos a explicarlo en la totalidad de sus dos componentes lógicos. El AP se comunica con el PEP al crear la ruta de comunicación. Esta comunicación se realiza a través del plano de control.
• Punto de aplicación de políticas (PEP): Este sistema se encarga de habilitar, supervisar y, eventualmente, finalizar las conexiones entre un sujeto y un recurso de la organización. El PEP se comunica con el AP para reenviar solicitudes y/o recibir actualizaciones de políticas del AP. Se trata, en definitiva, de un único componente lógico en ZTA, pero puede dividirse en dos componentes diferentes: el lado del usuario (por ejemplo, un EndPoint) y el lado del recurso (por ejemplo, un componente de puerta de enlace frente al recurso que controla el acceso) o un único componente de portal que actúa como guardián de las vías de comunicación. Más allá del PEP se encuentra la zona de confianza (Ver el punto principios ZT en capítulos anteriores).

Además de los componentes principales de una organización que implementa una ZTA, varias fuentes de datos proporcionan reglas de entrada y políticas utilizadas por el motor de políticas al tomar decisiones de acceso. Entre ellas se incluyen fuentes de datos locales y externas, es decir, no controladas o creadas por la propia organización. Estas pueden incluir:

• Sistema de diagnóstico y mitigación continuos (CDM): Recopila información sobre el estado actual del activo de la organización y aplica actualizaciones a los componentes de configuración y software. Un sistema CDM empresarial proporciona al motor de políticas la información sobre el activo que realiza una solicitud de acceso, como si está ejecutando el sistema operativo (SO) con la actualización adecuada, la integridad de los componentes de software aprobados por la empresa o la presencia de componentes no aprobados y si el activo tiene alguna vulnerabilidad conocida. Los sistemas CDM también son responsables de identificar y aplicar (en función de las políticas de la organización) un subconjunto de políticas en dispositivos no empresariales activos en la infraestructura de la organización.
• Sistema de conformidad industrial: Garantiza que la organización sigue cumpliendo las reglas normativas a los que esté sujeta (por ejemplo, ISO, FISMA, etc.). Esto incluye todas las reglas de política que una organización desarrolla para garantizar el cumplimiento.
• Información sobre amenazas: Proporciona información de fuentes internas o externas que ayudan al motor de políticas a tomar decisiones de acceso. Puede tratarse de múltiples servicios que toman datos de fuentes internas y/o externas y proporcionan información sobre ataques o vulnerabilidades recién descubiertos. Esto también incluye fallos recién descubiertos en el software, malware recién identificado y ataques notificados a otros activos a los que el motor de políticas necesita denegar el acceso desde los recursos de la empresa.
• Registros de actividad de redes y sistemas: Este sistema empresarial agrega registros de los recursos, tráfico de red, acciones de acceso a recursos y otros eventos que proporcionan información en tiempo real (o casi real) sobre la postura de seguridad de los sistemas de información de la empresa.
• Políticas de acceso a los datos: Son los atributos, reglas y políticas de acceso a los recursos de la empresa. Este conjunto de reglas pueden estar creadas directamente por la organización o generado dinámicamente por el motor de políticas. Estas políticas son el punto de partida para autorizar el acceso a un recurso, ya que proporcionan los privilegios de acceso básicos para las cuentas y aplicaciones/servicios de la organización.
• Infraestructura de clave pública de la empresa (PKI): Este sistema es responsable de generar y registrar los certificados emitidos por la empresa a los recursos, usuarios, servicios y aplicaciones.
• Sistema de gestión de identidades: Se encarga de crear, almacenar y gestionar las cuentas de usuario y los registros de identidad de la organización. Este sistema contiene la información necesaria sobre el usuario (por ejemplo, nombre, dirección de correo electrónico, certificados) y otras características de la organización como la función, los atributos de acceso y los activos asignados. Este sistema suele utilizar otros sistemas (como una PKI) para la autenticación de cuentas de usuarios. Este sistema puede formar parte de una comunidad más amplia y puede incluir usuarios ajenos a la organización o enlaces a recursos ajenos a la organización para la colaboración.
• Sistema de gestión de eventos e información de seguridad (SIEM): Recopila información centrada en la seguridad para su posterior análisis. Estos datos se utilizan para perfeccionar las políticas y advertir de posibles ataques contra los activos de la empresa.

Modelos de la ZTA

Hay varias formas en que una organización puede implantar una ZTA para los flujos de trabajo. Estos modelos varían en los componentes utilizados y en la fuente principal de reglas de política para una organización. Cada modelo debe implementar todos los principios de la ZT (Ver el punto principios ZT en capítulos anteriores) , pero puede utilizar uno o dos (o un componente) como principal impulsor de las políticas. Una solución ZT completa debe incluir elementos de los tres componentes. Los componentes incluyen la gobernanza de la identidad mejorada, la microsegmentación lógica y la segmentación basada en la red.

Algunos implantaciones se inclinan a más a unos casos de uso que a otros. Una organización que desee desarrollar una ZTA puede descubrir que el caso de uso elegido y las políticas existentes apuntan a un componente más que a otros. Esto no significa que los otros componentes no les vayan a ser validos, sino que pueden ser más difíciles de implantar y/o pueden ser más costosos.

ZTA mediante la gobernanza de la identidad mejorada

Si consideramos como modelo la gobernanza de identidad mejorada para desarrollar una ZTA, ésta utiliza la identidad de los usuarios como componente clave de la creación de políticas. Si no fuera por los usuarios que solicitan acceso a los recursos de la empresa, no habría necesidad de crear políticas de acceso. Para este visión, las políticas de acceso a los recursos de la empresa se basan en la identidad y los atributos asignados. El requisito principal para el acceso a los recursos se basa en los privilegios de acceso concedidos al sujeto en cuestión. Otros factores como el endpoint utilizado, el estado de los activos y los factores ambientales pueden alterar el cálculo final del nivel de confianza (y la autorización de acceso final) o adaptar el resultado de alguna manera, como conceder sólo un acceso parcial a una fuente de datos determinada en función de la ubicación de la red. Los recursos individuales o los componentes PEP que protegen el recurso deben tener una forma de reenviar las solicitudes a un servicio de motor de políticas o autenticar al usuario y aprobar la solicitud antes de conceder el acceso.

La gobernanza de la identidad mejorada para organizaciones se emplean a menudo utilizando un modelo de red abierta o una red de empresa con acceso de visitantes o dispositivos no empresariales frecuentes en la red (Ver el punto componentes de red más adelante). El acceso a la red se concede inicialmente a todos los activos, pero el acceso a los recursos de la empresa se restringe a las identidades con los privilegios de acceso adecuados. La concesión de conectividad básica a la red tiene sus inconvenientes, ya que los agentes maliciosos podrían seguir intentando el reconocimiento de la red y/o utilizarla para lanzar ataques de denegación de servicio, ya sea internamente o contra terceros. Las empresas siguen necesitando supervisar y responder a este tipo de comportamiento antes de que afecte a los flujos de trabajo.

El modelo basado en la identidad mejorada funciona bien con el modelo de portal de recursos (Ver punto implementación basada en el portal de recursos) , ya que la identidad y el estado del dispositivo proporcionan datos secundarios de apoyo a las decisiones de acceso. Otros modelos también funcionan, dependiendo de las políticas establecidas. Los modelos basados en la identidad también funcionan bien para las organizaciones que utilizan aplicaciones/servicios basados en la nube que pueden no permitir el uso de componentes de seguridad ZT de propiedad u operados por la organización (como muchas aplicativos SaaS). La organización puede utilizar la identidad de los solicitantes para crear y aplicar políticas en estas plataformas.

ZTA mediante microsegmentación

Una organización puede optar por implantar una ZTA basada en colocar recursos individuales o grupos de recursos en un segmento de red único protegido por un gateway. En este modelo, la organización coloca dispositivos de infraestructura como switches (o enrutadores) o firewall de nueva generación (NGFW) o dispositivos de puerta de enlace de propósito especial para que actúen como PEP que protegen cada recurso o pequeño grupo de recursos relacionados. Alternativamente (o adicionalmente), la organización puede optar por implementar la microsegmentación basada en host utilizando agentes de software o cortafuegos en los EndPoints (Ver punto (ver punto implementación basada en agente/gateway). Estos gateways conceden acceso dinámicamente a las solicitudes individuales de un usuario, recurso o servicio. Dependiendo del modelo, el gateway puede ser el único componente PEP o parte de un PEP multiparte formado por la pasarela y el agente del lado del usuario.

Este modelo se aplica a una variedad de casos de uso y modelos de despliegue, ya que el dispositivo de protección actúa como el PEP, con la gestión de dichos EndPoints actuando como el componente PE/PA. Este modelo requiere un programa de gobierno de la identidad (IGP) para funcionar plenamente, pero se basa en los componentes del gateway para actuar como el PEP que blinda los recursos contra el acceso no autorizado y/o el descubrimiento.

La necesidad clave de este modelo es que los componentes PEP sean gestionados y puedan reaccionar y reconfigurarse según sea necesario para responder a las amenazas o a los cambios en el flujo de trabajo. Es posible implementar algunas características de una organización microsegmentada utilizando gateways menos avanzadas e incluso cortafuegos sin estado, pero el coste de administración y la dificultad para adaptarse rápidamente a los cambios hacen que esta sea una opción muy poco consistente.

ZTA mediante infraestructura de red y perímetros definidos por software

El último modelo utiliza la infraestructura de red para implementar la ZTA. La implementación de la ZTA podría lograrse utilizando una red superpuesta (es decir, la capa 7, pero también podría establecerse en un nivel inferior de la pila de red OSI). Estos modelos a veces se denominan también modelos de perímetro definido por software (SDP, por sus siglas en ingles Software Defined Perimeter) y con frecuencia incluyen conceptos de redes definidas por software (SDN, por sus siglas en ingles Software Defined Network) y redes basadas en la intención (IBN por sus siglas en ingles Intent Based Networking [La tecnología de redes basadas en la intención consiste en un proceso de automatización definida por software que utiliza altos niveles de inteligencia, análisis y orquestación para mejorar el tiempo de actividad y las operaciones de red.]) En este enfoque, el AP actúa como controlador de red que configura y reconfigura la red basándose en las decisiones tomadas por el PE. Los clientes siguen solicitando acceso a través de los PEP, que son gestionados por el componente AP.

Cuando el modelo se implementa en la capa de red de la aplicación (es decir, la capa 7 del modelo OSI), el modelo de implementación más común es el de agente/gateway. En esta modelo, el agente y el gateway (actuando como PEP único y configurado por el AP) establecen un canal seguro utilizado para la comunicación entre el usuario y el recurso.
Puede haber otras variaciones de este modelo, así como para redes virtuales en la nube, redes no basadas en IP, etc.

Variaciones desplegadas de la arquitectura

Todos los componentes anteriores son componentes lógicos. No tienen por qué ser sistemas únicos., ya que un único activo puede desempeñar las funciones de varios componentes lógicos y del mismo modo, un componente lógico puede constar de varios elementos de hardware o software para realizar las tareas. Por ejemplo, una PKI gestionada por la empresa puede constar de un componente responsable de la emisión de certificados para dispositivos y otro utilizado para la emisión de certificados a usuarios finales, pero ambos utilizan certificados intermedios emitidos desde la misma autoridad de certificación raíz de la empresa.

En algunas soluciones de plataformas ZT disponibles actualmente en el mercado, los componentes PE y AP se combinan en un único servicio.

Existen diversas variaciones en el despliegue de determinados componentes de la arquitectura que se describen en las secciones siguientes. Dependiendo de cómo esté configurada la red de una empresa, pueden utilizarse varios modelos de despliegue de ZTA para diferentes procesos empresariales en una misma empresa.

Despliegue basado en agente/gateway de Endpoints

En este modelo de despliegue, el PEP se divide en dos componentes que residen en el recurso o como componente directamente delante de un recurso. Por ejemplo, cada recurso de la empresa tiene instalado un agente de EndPoint que coordina las conexiones, y cada recurso tiene un componente (es decir, un gateway) que se coloca directamente delante para que el recurso se comunique sólo con dicho gateway, sirviendo esencialmente como proxy del recurso. El agente es un componente de software que dirige parte (o todo) el tráfico al PEP adecuado para que se evalúen las solicitudes. El Gateway es responsable de comunicarse con el administrador de la política y de permitir únicamente las vías de comunicación aprobadas configuradas por el administrador de la política.

En un escenario típico, un usuario con un endpoint de la organización desea conectarse a un recurso (por ejemplo, una aplicación/base de datos). La solicitud de acceso es tomada por el agente local, y la solicitud es reenviada al administrador de políticas. El administrador de políticas y el motor de políticas pueden ser un recurso local de la empresa o pueden ser un servicio alojado en la nube. El administrador de políticas reenvía la solicitud al motor de políticas para su evaluación.

Si se autoriza la solicitud, el administrador de políticas configura un canal de comunicación entre el agente de dispositivo y la pasarela de recursos pertinente a través del plano de control. Esto puede incluir información como una dirección de protocolo de Internet (IP), información de puerto, clave de sesión o elementos de seguridad similares. A continuación, el agente de dispositivo y la pasarela se conectan y comienzan los flujos de datos de aplicaciones/servicios cifrados. La conexión entre el agente de dispositivo y el gateway de recursos finaliza cuando se completa el flujo de trabajo o cuando el administrador de políticas la activa debido a un evento de seguridad (por ejemplo, tiempo de espera de la sesión, fallo en la reautenticación).

Este modelo se utiliza mejor en organizaciones que disponen de un sólido programa de gestión de endpoints, así como de recursos discretos que pueden comunicarse con el gateway. Para las organizaciones que utilizan en gran medida servicios en la nube, se trata de una implementación cliente-servidor del Perímetro Definido por Software (SDP) de la Cloud Security Alliance (CSA). Este modelo también es adecuado para las organizaciones que no desean aplicar una política BYOD. El acceso sólo es posible a través del agente de dispositivo, que puede colocarse en recursos propiedad de la organización.

Despliegue basado en Localización

Este modelo de despliegue es una variación del modelo anterior de agente de dispositivo/pasarela. En este modelo, es posible que los componentes del gateway no residan en los recursos individuales, sino en el límite de una localización de recursos (por ejemplo, un datacenter), como se muestra en la siguiente imagen.

Normalmente, estos recursos sirven a una única función empresarial o pueden no ser capaces de comunicarse directamente con una pasarela (por ejemplo, un sistema de base de datos heredado que no tiene una interfaz de programación de aplicaciones [API] que pueda utilizarse para comunicarse con una gateway). Este modelo de despliegue también puede ser útil para organizaciones que utilizan microservicios basados en la nube para un único proceso de negocio (por ejemplo, notificación a usuarios, búsqueda en bases de datos, desembolso de salarios). En este modelo, toda la nube privada se encuentra detrás de una pasarela.

Es posible que este modelo sea un híbrido con el modelo de agente/gateway de dispositivo. En este modelo, los activos de la empresa tienen un agente de dispositivo que se utiliza para conectarse a las puertas de enlace del enclave, pero estas conexiones se crean utilizando el mismo proceso que el modelo básico de agente de dispositivo/puerta de enlace.

Este modelo es útil para empresas que tienen aplicaciones heredadas o centros de datos locales que no pueden disponer de puertas de enlace individuales. La empresa necesita un sólido programa de gestión de activos y configuración para instalar y configurar los agentes de dispositivo. El inconveniente es que la puerta de enlace protege un conjunto de recursos y puede no ser capaz de proteger cada recurso individualmente. Esto también puede permitir que los sujetos vean recursos a los que no tienen privilegios de acceso.

Despliegue basado en el Portal de Recursos

En este modelo de despliegue, el PEP es un único componente que actúa como portal para las solicitudes de los sujetos. El portal de entrada puede ser para un recurso individual o un enclave seguro para un conjunto de recursos utilizados para una única función empresarial. Un ejemplo sería un portal de acceso a una nube privada o a un centro de datos que contenga aplicaciones heredadas, como se muestra en la siguiente imagen.

La principal ventaja de este modelo sobre los demás es que no es necesario instalar un componente de software (agente) en todos los Endpoints de la empresa. Este modelo también es más flexible para las políticas BYOD y los proyectos de colaboración entre organizaciones. Los administradores de la empresa no necesitan asegurarse de que cada dispositivo tiene el agente de dispositivo adecuado antes de su uso. Sin embargo, se puede solicitar información limitada de los dispositivos que solicitan acceso. Este modelo sólo puede escanear y analizar los activos y dispositivos una vez que se conectan al portal PEP y es posible que no pueda supervisarlos continuamente en busca de malware, vulnerabilidades sin parches y la configuración adecuada.

La principal diferencia con este modelo es que no hay un agente local que gestione las solicitudes, por lo que la organización puede no tener una visibilidad total o un control arbitrario sobre los activos, ya que sólo puede verlos/escanearlos cuando se conectan a un portal. La organización puede emplear medidas como el aislamiento del navegador para mitigar o compensar. Estos recursos pueden ser invisibles para la empresa entre estas sesiones. Este modelo también permite a los atacantes descubrir e intentar acceder al portal o intentar un ataque de denegación de servicio (DoS) contra el portal. Los sistemas del portal deben estar bien aprovisionados para proporcionar disponibilidad contra un ataque DoS o una interrupción de la red.

Sandboxing de aplicaciones de dispositivos

Otra variación del modelo de despliegue de agente/gateway es hacer que las aplicaciones o procesos examinados se ejecuten en compartimentos de los recursos.

Estos compartimentos pueden ser máquinas virtuales, contenedores o cualquier otra implementación, pero el objetivo es el mismo: proteger la aplicación o instancias de aplicaciones de un host posiblemente comprometido o de otras aplicaciones que se ejecuten en el activo.

En la imagen anterior, el endpoint en cuestión ejecuta aplicaciones aprobadas e investigadas en un espacio aislado. Las aplicaciones pueden comunicarse con el PEP para solicitar acceso a los recursos, pero el PEP rechazará las solicitudes de otras aplicaciones en el recurso. En este modelo, el PEP puede ser un servicio local de la empresa o un servicio en la nube.

La principal ventaja de esta variante del modelo es que las aplicaciones individuales están segmentadas del resto de los recursos. Si el recurso no puede ser escaneado en busca de vulnerabilidades, estas aplicaciones individuales aisladas pueden estar protegidas de una posible infección de malware. Una de las desventajas de este modelo es que las organizaciones deben mantener estas aplicaciones aisladas para todos los recursos y puede que no tengan una visibilidad completa de los recursos de los usuarios. La organización también tiene que asegurarse de que cada aplicación protegida por un espacio aislado es segura, lo que puede requerir más esfuerzo que la simple supervisión de los endpoints.

Algoritmo de confianza

Para una organización con un despliegue de ZTA, el motor de políticas puede considerarse como el cerebro y el algoritmo de confianza del PE como su proceso de pensamiento principal. El algoritmo de confianza (TA) es el proceso utilizado por el motor de políticas para, en última instancia, conceder o denegar el acceso a un recurso.

El motor de políticas recibe información de múltiples fuentes: la base de datos de políticas con información observable sobre los usuarios, los atributos y roles de los usuarios, los patrones históricos de comportamiento de los usuarios, las fuentes de inteligencia de amenazas y otras fuentes de metadatos. El proceso puede agruparse en grandes categorías. veamos la siguiente imagen.

En la imagen, las entradas pueden dividirse en categorías en función de lo que aportan al algoritmo de confianza.

• Solicitud de acceso: Es la solicitud real del usuario. El recurso solicitado es la información principal, pero también se utiliza información sobre el usuarios que lo solicita. Esto puede incluir la versión del sistema operativo, el software utilizado (por ejemplo, ¿aparece la aplicación solicitada en una lista de aplicaciones aprobadas?) y el nivel de actualización. Dependiendo de estos factores y de la postura de seguridad de los activos, se puede restringir o denegar el acceso a los activos.
• Base de datos de sujetos: Es el “quién” solicita acceso a un recurso. Es el conjunto de usuarios (humanos y procesos) de la organización o colaboradores y una colección de atributos/privilegios asignados a los usuarios. Estos usuarios y atributos forman la base de las políticas de acceso a los recursos. Las identidades de usuario pueden incluir una mezcla de identidad lógica (por ejemplo, ID de cuenta) y resultados de comprobaciones de autenticación realizadas por el PEP. Los atributos de la identidad que pueden tenerse en cuenta para derivar el nivel de confianza incluyen la hora y la geolocalización. Una colección de privilegios otorgados a múltiples usuarios podría considerarse como un rol, pero los privilegios deben asignarse a un usuario de forma individual y no simplemente porque puedan encajar en un rol concreto en la organización. Esta colección debe codificarse y almacenarse en un sistema de gestión de identidades y en una base de datos de políticas. También puede incluir datos sobre el comportamiento observado en el pasado del sujeto en algunas variantes (AT) (ver el punto variaciones del algoritmo de confianza)
• Base de datos de recursos (y estado observable): Es la base de datos que contiene el estado conocido de cada recurso (físico y virtual) propiedad de la organización (y también es recomendable los conocidos BYOD). Se compara con el estado observable del recurso que realiza la solicitud y puede incluir la versión del sistema operativo, el software presente y su integridad, la ubicación (ubicación de red y geolocalización) y el nivel de actualización. En función del estado del recurso comparado con esta base de datos, se puede restringir o denegar el acceso a los recursos.
• Requisitos de los recursos: Este conjunto de políticas complementa la base de datos de ID de usuario y atributos y define los requisitos mínimos para acceder al recurso. Los requisitos pueden incluir los niveles de garantía del autenticador, como la ubicación de la red MFA (por ejemplo, denegar el acceso desde direcciones IP extranjeras), la sensibilidad de los datos y las solicitudes de configuración de los recursos. Estos requisitos deben ser desarrollados tanto por los responsables de los datos como por los responsables de los procesos empresariales que utilizan los dato.
• Inteligencia sobre amenazas: Se trata de uno o varios flujos de información sobre amenazas generales y programas maliciosos activos que operan en Internet. También puede incluir información específica sobre comunicaciones observadas desde el endpoint que puedan ser sospechosas. Estos servicios pueden ser externos o escaneos y descubrimientos internos y pueden incluir firmas de ataque y mitigaciones. Este es el único componente que muy probablemente estará bajo el control de un servicio y no de la empresa.

El peso de importancia para cada fuente de datos puede ser un algoritmo propietario o puede ser configurado por la organización. Estos valores de ponderación pueden utilizarse para reflejar la importancia de la fuente de datos para una organización.

La política se implementa en el PA para su ejecución. El trabajo del AP consiste en configurar los PEP necesarios para permitir la comunicación autorizada. Dependiendo de cómo se despliegue la ZTA, esto puede implicar el envío de resultados de autenticación e información de configuración de la conexión a gateways y agentes o portales de recursos. Los PA también pueden retener o pausar una sesión de comunicación para volver a autenticar y autorizar la conexión de acuerdo con los requisitos de la política. El AP también es responsable de emitir el comando para terminar la conexión basado en la política (por ejemplo, después de un tiempo de espera, cuando el flujo de trabajo se ha completado, debido a una alerta de seguridad).

Variaciones del algoritmo de confianza

Existen diferentes formas de aplicar una AT. Los distintos ejecutores pueden ponderar los factores anteriores de forma diferente según la importancia percibida. Hay otras dos características importantes que pueden utilizarse para diferenciar las AV. La primera es cómo se evalúan los factores, ya sea como decisiones binarias o como partes ponderadas de una “puntuación” total o un nivel de confianza. La segunda es cómo se evalúan las solicitudes en relación con otras solicitudes del mismo usuario, aplicación/servicio o endpoint.

• Basada en criterios frente a basada en puntuaciones: Una AT basada en criterios supone un conjunto de atributos cualificados que deben cumplirse antes de conceder el acceso a un recurso o permitir una acción (por ejemplo, lectura/escritura). Estos criterios son configurados por la organización y deben configurarse independientemente para cada recurso. Sólo se concede el acceso o se aplica una acción a un recurso si se cumplen todos los criterios. Una AT basada en la puntuación calcula un nivel de confianza basado en los valores de cada fuente de datos y las ponderaciones configuradas por la organización. Si la puntuación es superior al valor umbral configurado para el recurso, se concede el acceso o se ejecuta la acción. En caso contrario, se deniega la solicitud o se reducen los privilegios de acceso (por ejemplo, se concede acceso de lectura pero no de escritura para un archivo).
• Singular frente a contextual: Una AT singular trata cada solicitud individualmente y no tiene en cuenta el historial del usuario al realizar su evaluación. Esto puede permitir evaluaciones más rápidas, pero existe el riesgo de que un ataque pase desapercibido si se mantiene dentro de la función permitida del usuario. Una AT contextual tiene en cuenta el historial reciente del usuario o del agente de red a la hora de evaluar las solicitudes de acceso. Esto significa que el PE debe mantener cierta información de estado sobre todos los usuarios y aplicaciones, pero puede ser más probable que detecte a un atacante que utiliza credenciales subvertidas para acceder a la información en un patrón que es atípico de lo que el PE ve para el usuario dado. Esto también significa que el PE debe estar informado del comportamiento de los usuarios por los PA (y los PEP) con los que interactúan los usuarios cuando se comunican. El análisis del comportamiento de los usuarios puede utilizarse para proporcionar un modelo de uso aceptable, y las desviaciones de este comportamiento podrían desencadenar comprobaciones de autenticación adicionales o denegaciones de solicitudes de recursos.

Ambos factores no siempre dependen el uno del otro. Es posible tener una AT que asigne un nivel de confianza a cada usuario y/o endpoint y siga considerando cada solicitud de acceso de forma independiente (es decir, singular). Sin embargo, las ZTA contextuales basadas en puntuaciones permitirían ofrecer un control de acceso más dinámico y granular, ya que la puntuación proporciona un nivel de confianza actual para el usuario y se adapta a factores cambiantes con mayor rapidez que las políticas estáticas modificadas por administradores humanos.

Idealmente, un algoritmo de confianza ZTA debería ser contextual, pero esto puede no ser siempre posible con los componentes de infraestructura disponibles en la organización. Una ZTA contextual puede mitigar las amenazas en las que un atacante se mantiene cerca de un conjunto “normal” de solicitudes de acceso para una cuenta de un usuario comprometido o un ataque interno. Es importante equilibrar la seguridad, la facilidad de uso y la rentabilidad a la hora de definir y aplicar algoritmos de confianza. Solicitar continuamente la reautenticación de un usuario frente a un comportamiento que es coherente con las tendencias y normas históricas para su función y papel dentro de la organización puede dar lugar a problemas de usabilidad.

Por ejemplo, si un usuario accede, a diario, a entre 20 y 30 documentos de texto, una AT contextual puede enviar una alerta si las solicitudes de acceso superan repentinamente los 100 documentos en un día. Una AT contextual también puede enviar una alerta si alguien está realizando solicitudes de acceso fuera del horario laboral normal, ya que podría tratarse de un atacante que está filtrando información. En definitiva, una AT contextual puede activar una alerta y requerir que el usuario satisfaga un nivel de confianza más estricto u otros criterios.

El desarrollo de un conjunto de criterios o valores de ponderación/umbral para cada recurso requiere planificación y pruebas. Los administradores de la empresa pueden encontrarse con problemas durante la implementación inicial de ZTA donde las solicitudes de acceso que deberían ser aprobadas son denegadas debido a una mala configuración. Esto dará lugar a una fase inicial de puesta a punto del despliegue. Es posible que sea necesario ajustar los criterios o las ponderaciones de puntuación para garantizar que las políticas se apliquen al tiempo que se permite el funcionamiento de los procesos de negocio de la organización. La duración de esta fase de ajuste depende de las métricas definidas por la organización para el progreso y la tolerancia de denegaciones/aprobaciones de acceso incorrectas para los recursos utilizados en el flujo de trabajo.

Componentes de red

En un entorno ZT, debe haber una separación (lógica o posiblemente física) de los flujos de comunicación utilizados para controlar y configurar la red y los flujos de comunicación de aplicaciones/servicios utilizados para realizar el trabajo real de la organización. Esto se suele desglosar en un plano de control para la comunicación de control de la red y un plano de datos para los flujos de comunicación de aplicaciones/servicios.

El plano de control es utilizado por varios componentes de la infraestructura (tanto propios de la organización como de proveedores de servicios) para mantener y configurar los activos; juzgar, conceder o denegar el acceso a los recursos; y realizar cualquier operación necesaria para establecer rutas de comunicación entre los recursos.

El plano de datos se utiliza para la comunicación real entre los componentes de software. Este canal de comunicación puede no ser posible antes de que se haya establecido la ruta a través del plano de control. Por ejemplo, el PA y el PEP podrían utilizar el plano de control para establecer la ruta de comunicación entre el sujeto y el recurso de la organización. La carga de trabajo de la aplicación/servicio utilizaría entonces la ruta del plano de datos que se ha establecido.

Requisitos de red para soportar ZTA

• Los recursos de la organización disponen de conectividad de red básica. La red de área local (LAN), controlada o no por la empresa, proporciona enrutamiento e infraestructura básicos (por ejemplo, DNS). Es posible que el recurso de la organización remota no utilice necesariamente todos los servicios de infraestructura.
• La organización debe ser capaz de distinguir entre los recursos que son propiedad o están gestionados por la organización y el nivel de seguridad actual de los dispositivos. Esto se determina mediante credenciales emitidas por la organización y no utilizando información que no pueda ser autenticada (por ejemplo, direcciones MAC de red que pueden ser suplantadas).
• La organización puede/debe monitorizar todo el tráfico de la red. La organización debería registrar los paquetes vistos en el plano de datos, aunque no pueda realizar una inspección de la capa de aplicación (es decir, la capa 7 de OSI) en todos los paquetes. La empresa filtra metadatos sobre la conexión (por ejemplo, destino, hora, identidad del dispositivo) para actualizar dinámicamente las políticas e informar al PE cuando evalúa las solicitudes de acceso.
• No se debe poder acceder a los recursos de la empresa sin acceder a un PEP. Los recursos de la organización no deben aceptar conexiones entrantes arbitrarias desde Internet. Los recursos deben aceptar conexiones configuradas a medida sólo después de que un usuario haya sido autenticado y por supuesto, autorizado. Estas vías de comunicación son establecidas por el PEP. Los recursos ni siquiera pueden ser descubiertos sin acceder a un PEP. Esto evita que los ciberdelicuentes identifiquen objetivos mediante escaneo y/o lancen ataques DoS contra recursos ubicados detrás del PEP. Es necesario tener en cuenta que no todos los recursos deben ocultarse de esta manera; algunos componentes de la infraestructura de red (por ejemplo, los servidores DNS) deben ser accesibles.
• El plano de datos y el plano de control están lógicamente separados. El motor de políticas, el administrador de políticas y los PEP se comunican en una red que está lógicamente separada y no es directamente accesible por los activos y recursos de la organización. El plano de datos se utiliza para el tráfico de datos de aplicaciones/servicios. El motor de políticas, el administrador de políticas y los PEP utilizan el plano de control para comunicarse y gestionar las rutas de comunicación entre los activos. Los PEP deben ser capaces de enviar y recibir mensajes tanto del plano de datos como del plano de control.
• Los recursos de la organización pueden acceder al componente PEP. Los usuarios de la organización deben poder acceder al componente PEP para acceder a los recursos. Esto podría adoptar la forma de un portal web, un dispositivo de red o un agente de software en el recursos de la organización que permita la conexión.
• El PEP es el único componente que accede al administrador de políticas como parte de un flujo de negocio. Cada PEP que opera en la red de la organización tiene una conexión con el administrador de políticas para establecer rutas de comunicación de los clientes a los recursos. Todo el tráfico del proceso de negocio de la empresa pasa a través de uno o más PEP.
• La infraestructura utilizada para soportar el proceso de decisión de acceso a la ZTA debe ser escalable para tener en cuenta los cambios en la carga del proceso. Los PE, AP y PEP utilizados en una ZTA se convierten en los componentes clave de cualquier proceso de la organización. El retraso o la imposibilidad de llegar a un PEP (o la imposibilidad de los PEP de llegar al PA/PE) repercute negativamente en la capacidad de realizar el flujo de trabajo. Una organización que implemente una ZTA necesita aprovisionar los componentes para la carga de trabajo esperada o ser capaz de escalar rápidamente la infraestructura para manejar un mayor uso cuando sea necesario.
• Es posible que los recursos de la organización no puedan llegar a determinados PEP debido a políticas establecidas. Por ejemplo, puede existir una política que establezca que los endpoints no puedan acceder a determinados recursos (o ninguno) si se encuentra fuera del país de origen de la organización. Estas politicas podrían basarse en la ubicación (geolocalización o ubicación de red), el tipo de dispositivo u otros criterios.