Redes de Confianza Cero

Capítulo 4. Tomar decisiones de autorización

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Autorización es posiblemente el proceso más importante que tiene lugar en una red de confianza cero, y como tal, tomar una decisión de autorización no debe tomarse a la ligera. Cada flujo y/o solicitud requerirá, en última instancia, que se tome una decisión.

Las bases de datos y los sistemas de apoyo de los que hablaremos aquí son los sistemas clave que se unen para tomar y afectar a esas decisiones. Juntos, tienen autoridad para el control de acceso y, por tanto, deben estar rigurosamente aislados. Hay que distinguir cuidadosamente entre estas responsabilidades, sobre todo a la hora de decidir si colapsarlas en un único sistema, lo que en general debe evitarse si es posible.

El modelo de confianza cero es todavía muy nuevo, y este ámbito está experimentando una rápida evolución. Parte del contenido incluido en este capítulo se considera el estado del arte en el momento de escribir esto. Las implementaciones conocidas aún varían enormemente en sus enfoques, y la mayoría no están disponibles públicamente. Dicho esto, se comprenden los principales componentes y responsabilidades.

Teniendo en cuenta la realidad, este capítulo se centrará en la disposición arquitectónica de alto nivel de los componentes necesarios para tomar decisiones de autorización de confianza cero, así como en la forma en que encajan entre sí y aplican dichas decisiones.

Arquitectura de autorización

La arquitectura de autorización de confianza cero de consta de cuatro componentes principales, como se muestra en la Figura 4-1:

• Ejecución
• Motor político
• Motor de confianza
• Almacenes de datos

Estos cuatro componentes son distintos en sus responsabilidades y, por ello, los tratamos como sistemas separados. Desde el punto de vista de la seguridad, es muy conveniente que estos componentes estén aislados entre sí. Estos sistemas representan en la práctica las joyas de la corona del modelo de seguridad de confianza cero, por lo que debe prestarse especial atención a su mantenimiento y postura de seguridad. Evalúa cuidadosamente cualquier propuesta que sugiera colapsar estas responsabilidades en un único sistema.

Figura 4-1. Sistemas de autorización de confianza cero

El componente de aplicación existirá en gran número en todo el sistema y debe estar lo más cerca posible de la carga de trabajo. Es el que realmente afecta al resultado de la decisión de autorización. Suele manifestarse como un equilibrador de carga , un proxy o incluso un cortafuegos . Este componente interactúa con el motor de políticas , que es la pieza que utilizamos para tomar la decisión real. El componente de aplicación se asegura de que los clientes están autenticados, y pasa el contexto de cada flujo/solicitud al motor de políticas. El motor de políticas compara la solicitud y su contexto con la política, e informa al ejecutor de si la solicitud se permitirá o no.

El motor de confianza es aprovechado por el motor de políticas con fines de análisis de riesgos. Aprovecha múltiples fuentes de datos para calcular una puntuación de riesgo, similar a una puntuación crediticia. Esta puntuación puede utilizarse para proteger contra desconocidos, y ayuda a mantener una política sólida y robusta sin complicarla con casos de perímetro y firmas. El motor de la política la utiliza como un componente adicional mediante el cual se puede tomar una decisión de autorización. Google BeyondCorp es ampliamente reconocido como pionero de esta tecnología.

Por último, tenemos los diversos almacenes de datos de que representan la fuente de verdad de los datos que se utilizan para informar de la autorización. Estos datos se utilizan para dibujar una imagen contextual completa de un flujo/solicitud concreto, utilizando pequeños fragmentos de datos autentificados como claves de búsqueda principales (es decir, un nombre de usuario o el número de serie de un dispositivo). Estos almacenes de datos, ya sean datos de usuario, de dispositivo o de otro tipo, son muy aprovechados tanto por el motor de políticas como por el motor de confianza, y representan el respaldo con el que se miden todas las decisiones .

Ejecución

El componente de aplicación (representado en la Figura 4-2) es un lugar natural para empezar. Se encuentra en la "primera línea" del flujo de autorización y es responsable de ejecutar las decisiones tomadas por el resto del sistema de autorización.

Figura 4-2. Un agente recibe una señal de autorización previa para conceder el acceso a un sistema que utiliza mecanismos de aplicación tradicionales. Estos sistemas juntos forman el componente de aplicación.

La aplicación puede desglosarse en dos responsabilidades principales. En primer lugar, debe producirse una interacción con el motor de políticas. Por lo general, se trata de la propia solicitud de autorización (por ejemplo, un equilibrador de carga ha recibido una solicitud y necesita saber si está autorizada o no). La segunda es la instalación real y la aplicación continua de la decisión. Aunque estas dos responsabilidades representan un único componente en la arquitectura de autorización de confianza cero, puedes elegir si se cumplen juntas o por separado.

La forma que elijas para gestionar esto dependerá probablemente de tu caso de uso. Por ejemplo, un proxy consciente de la identidad puede llamar al motor de políticas para autorizar activamente una solicitud que ha recibido, y en el mismo paso utilizar la respuesta para atender o rechazar la solicitud. Éste es un ejemplo de tratamiento unificado de las preocupaciones. Otra posibilidad es que un demonio de preautorización reciba una solicitud de acceso a un servicio concreto y llame al motor de políticas para que lo autorice. Una vez obtenida la autorización, el demonio puede manipular las reglas del cortafuegos local para permitir la solicitud concreta. Con este enfoque, nos basamos en mecanismos de aplicación "estándar" que son informados/programados por el plano de control de confianza cero. Sin embargo, hay que tener en cuenta que este enfoque requiere un gancho del lado del cliente para notificar al plano de control la solicitud de autorización. Esto puede ser aceptable o no, dependiendo del nivel de control sobre tus dispositivos y aplicaciones.

La colocación del componente de aplicación es muy importante. Puesto que representa nuestro punto de control dentro del plano de datos, debemos asegurarnos de que los componentes de aplicación se colocan lo más cerca posible de los puntos finales. De lo contrario, la confianza puede acumularse "detrás" del componente de aplicación, socavando la seguridad de confianza cero. Por suerte, el componente de aplicación puede modelarse como una especie de cliente y aplicarse libremente en todo el sistema. Esto contrasta con el resto de componentes de autorización, que se modelan como servicios de .

Motor de Política

El motor de la política es el componente que tiene el poder de tomar una decisión. Compara la solicitud procedente del componente de aplicación con la política para determinar si la solicitud está autorizada o no. Una vez determinado, el resultado se devuelve a la pieza de aplicación para su realización.

La disposición de la capa de aplicación y el motor de políticas permite tomar decisiones dinámicas y puntuales, permitiendo que la revocación se produzca rápidamente. Por ello, es importante que estos componentes se consideren por separado e independientemente. Esto no quiere decir, sin embargo, que no puedan estar ubicados conjuntamente.

Dependiendo de una serie de factores, un motor de políticas puede encontrarse alojado codo con codo con el mecanismo de aplicación. Un ejemplo de ello podría ser un equilibrador de carga que autorice las solicitudes mediante comunicación entre procesos (IPC) en lugar de una llamada remota. La ventaja más atractiva de esta arquitectura es la menor latencia para autorizar la solicitud. Un sistema de autorización de baja latencia permite una autorización detallada y completa de la actividad de la red; por ejemplo, se podrían autorizar solicitudes HTTP individuales en lugar de la autorización a nivel de sesión que se suele utilizar.

Debe tenerse en cuenta que es mejor mantener el aislamiento a nivel de proceso entre el motor de políticas y la capa de aplicación. La capa de aplicación, al estar en la ruta de datos del usuario, está más expuesta; por tanto, integrar el motor de políticas en el mismo proceso podría exponerlo a riesgos no deseados. La implementación del motor de políticas como proceso propio contribuye en gran medida a garantizar que los fallos en la capa de aplicación no comprometan el motor de políticas.

¿Qué ha sido de RADIUS?

La relación entre el motor de políticas y la capa de aplicación es familiar para la mayoría de los ingenieros de redes. En 1997, el IETF ratificó una norma que describía el protocolo RADIUS, que proporciona autenticación, autorización y contabilidad para los servicios de red. RADIUS son las siglas de Remote Authentication Dial-In User Service (Servicio de Autenticación Remota de Acceso Telefónico de Usuarios);sólo el nombre ya demuestra su antigüedad. Aunque el protocolo en sí es desesperadamente inseguro (utiliza MD5 para las afirmaciones de autenticidad), está escrito específicamente para la tarea que nos ocupa. ¿Cómo sería utilizar RADIUS entre la capa de aplicación y el motor de políticas? RADIUS podría protegerse con otros protocolos de los que se habla en este libro, pero parece una chapuza. Quizás exista la oportunidad de crear un proyecto similar a RADIUS, que tenga en cuenta la realidad de las amenazas de los sistemas actuales.

Política de almacenamiento

Es necesario almacenar las reglas de a las que hace referencia el motor de políticas. Estas reglas políticas se cargan en última instancia en el motor de políticas, pero se recomienda encarecidamente que las reglas se capturen fuera del propio motor de políticas. Almacenar las reglas políticas en un sistema de control de versiones es lo ideal y proporciona varias ventajas:

• Los cambios en la política pueden seguirse a lo largo del tiempo.
• Los motivos para cambiar la política se registran en el sistema de control de versiones.
• El estado actual previsto de la política puede validarse con los mecanismos de aplicación reales.

Muchas de estas ventajas se han aplicado históricamente mediante rigurosos procedimientos de gestión de cambios. En ese sistema, los cambios en la configuración del sistema se solicitan y aprueban antes de aplicarse en última instancia. El registro de gestión de cambios resultante puede utilizarse para determinar por qué el sistema se encuentra en el estado actual.

Trasladar las definiciones de política al control de versiones es la conclusión lógica de los procedimientos de gestión de cambios cuando el sistema puede configurarse mediante programación. En lugar de confiar en los administradores humanos del sistema para cargar la política deseada en el sistema, podemos capturar la política como datos que un programa puede leer y aplicar. En muchos sentidos, cargar la política es entonces similar a la implementación de software. Como resultado, los administradores del sistema pueden utilizar procedimientos estándar de desarrollo de software (a saber, revisión de código y conductos de promoción) para gestionar los cambios en la política.

¿Qué es una buena política?

La política en una red de confianza cero es en algunos aspectos similar a la seguridad de red tradicional, y en otros sustancialmente diferente.

La Política de Confianza Cero aún no está normalizada

La realidad actual de es que la política de confianza cero aún no está estandarizada del mismo modo que una política orientada a la red. Por ello, definir el lenguaje estándar de la política utilizada en una red de confianza cero es una gran oportunidad.

Veamos primero lo que es similar. Una buena política en una red de confianza cero es de grano fino. El nivel de granularidad variará en función de la madurez de la red, pero el objetivo deseado es una política que se ajuste al recurso individual que se está protegiendo. Esto no es muy diferente de un modelo de seguridad de red tradicional que pretende segmentar la red para disminuir la superficie de ataque.

El modelo de confianza cero empieza a divergir de la seguridad de red tradicional en los mecanismos de control que se utilizan para definir la política. En lugar de definir la política en términos de detalles de implementación de la red (direcciones IP y rangos), la política se define mejor en términos de componentes lógicos de la red. Estos componentes consistirán generalmente en

• Servicios de red
• Clases de punto final del dispositivo
• Funciones de los usuarios

Definir la política a partir de componentes lógicos que existen en la red permite al motor de la política calcular las decisiones de aplicación basándose en su conocimiento del estado actual de la red. Para ponerlo en términos concretos, un servicio web que se ejecuta hoy en un servidor puede estar mañana en otro distinto, o incluso puede moverse entre servidores automáticamente según lo indique un programador de cargas de trabajo. La política que definamos debe estar separada de estos detalles de implementación para adaptarse a esta realidad. En la Figura 4-3 se muestra un ejemplo de este estilo de política del proyecto Kubernetes.

Figura 4-3. Fragmento de una política de red de Kubernetes. Estas políticas utilizan etiquetas de carga de trabajo, computando las reglas de aplicación subyacentes basadas en IP cuando y donde sea necesario.

La política en una red de confianza cero también se apoya en las puntuaciones de confianza para anticiparse a vectores de ataque desconocidos. Al definir la política con un componente de puntuación de confianza, los administradores pueden mitigar el riesgo que, de otro modo, no podría capturarse con una política específica. Por tanto, la mayoría de las políticas deberían incluir un componente de puntuación de confianza. Hablaremos más sobre el componente de puntuación en la siguiente sección.

No existe ninguna norma

En la actualidad, las redes maduras de confianza cero aplican su propio lenguaje/formato de políticas caso por caso, y suelen desarrollarse totalmente en la empresa. Las redes de confianza cero más sencillas pueden incrustar la política en una estructura existente, como en la Figura 4-3. Aunque esta última suele ser aceptable, normalmente se queda pequeña a medida que la red evoluciona y añade funciones. Las ventajas de un lenguaje de políticas estandarizado/interoperable pueden verse claramente. Sin embargo, esta labor sigue siendo una cuestión de investigación abierta .

La política no debe basarse únicamente en la puntuación de confianza. Las características específicas de la solicitud que se autoriza también pueden formar parte de la definición de la política. Un ejemplo de esto podría ser que determinados roles de usuario sólo deberían tener acceso a un servicio concreto de .

¿Quién define la política?

Confianza cero la política de red debe ser de grano fino, lo que puede suponer una carga extraordinaria para los administradores del sistema a la hora de mantener la política actualizada. Para ayudar a repartir la carga de esta carga de configuración, la mayoría de las organizaciones deciden distribuir la definición de políticas entre los equipos, de modo que puedan ayudar a mantener la política de los servicios que les pertenecen.

Abrir la definición de políticas a toda una organización puede presentar ciertos riesgos, como usuarios bienintencionados que crean políticas demasiado amplias, aumentando así la superficie de ataque del sistema que pretendían restringir. Los sistemas de confianza cero se apoyan en dos flujos de trabajo organizativos para contrarrestar esta exposición.

En primer lugar, dado que la política suele almacenarse bajo control de versiones, tener a otra persona que revise los cambios en la política ayuda a garantizar que los cambios están bien considerados. Además, los equipos de seguridad pueden revisar los cambios y hacer preguntas de sondeo para asegurarse de que la política que se está definiendo tiene el alcance más estricto posible. Como la política se define utilizando la intención lógica en lugar de componentes físicos, la política cambiará menos rápidamente que si se definiera en términos físicos.

La segunda medida organizativa utilizada consiste en superponer una política de infraestructura amplia a una política de grano fino. Por ejemplo, un grupo de infraestructura puede exigir, con razón, que sólo un determinado conjunto de funciones pueda aceptar tráfico de Internet. Por tanto, el equipo de infraestructura definirá una política que haga cumplir esa restricción, y no se permitirá que ninguna política definida por el usuario la eluda. La aplicación de esta restricción puede adoptar varias formas: una prueba automatizada de la política propuesta, o tal vez un motor de políticas que simplemente rechace afirmaciones de políticas demasiado amplias procedentes de fuentes no fiables. Esta aplicación también puede ser útil para el cumplimiento de la normativa y de los requisitos reglamentarios de .

Motor de confianza

Elmotor de confianza de es el sistema de una red de confianza cero que realiza el análisis de riesgos de una solicitud o acción concreta. La responsabilidad de este sistema es producir una evaluación numérica del riesgo de permitir una solicitud/acción concreta, que el motor de políticas utiliza para tomar una decisión de autorización definitiva.

El motor de confianza recurrirá con frecuencia a los datos contenidos en los sistemas de inventario autorizados para comprobar los atributos de una entidad al calcular su puntuación. Un inventario de dispositivos, por ejemplo, podría proporcionar al motor de confianza información como la última vez que se auditó un dispositivo, o si tiene una determinada función de seguridad de hardware.

Crear una evaluación numérica del riesgo es una tarea difícil. Un enfoque sencillo sería definir un conjunto de reglas ad hoc que puntúen la peligrosidad de una entidad. Por ejemplo, un dispositivo al que le falten los últimos parches de software podría ver reducida su puntuación. Del mismo modo, se podría reducir la puntuación de confianza de un usuario que no se autentique continuamente.

Aunque la puntuación de confianza ad hoc puede ser sencilla para empezar, un conjunto de reglas definidas estáticamente será insuficiente para cumplir el objetivo deseado de defenderse de ataques inesperados. Por ello, además de utilizar reglas estáticas, los motores de confianza maduros utilizan técnicas de aprendizaje automático para derivar una función de puntuación.

El aprendizaje automático obtiene una función de puntuación calculando hechos observables a partir de un subconjunto de datos de actividad conocidos como datos de entrenamiento. Los datos de entrenamiento son observaciones en bruto que se han asociado a entidades fiables o no fiables. De estos datos se extraen características que se utilizan para derivar una función de puntuación generada por ordenador. Esta función de puntuación, un modelo en términos de aprendizaje automático, se compara con un conjunto de datos que tienen el mismo formato que los datos de entrenamiento. Las puntuaciones resultantes se comparan con evaluaciones de riesgo definidas por humanos, y la calidad del modelo puede entonces refinarse en función de su capacidad para predecir correctamente el riesgo de los datos analizados. Se puede decir entonces que un modelo que tenga suficiente precisión predice el riesgo de solicitudes aún no vistas en la red.

Aunque el aprendizaje automático se utiliza cada vez más para resolver problemas computacionales difíciles, no obvia la necesidad de reglas más explícitas en el motor de confianza. Ya sea por la limitación de los modelos de puntuación derivados o por la personalización deseada de la función de puntuación, los motores de confianza suelen utilizar una mezcla de métodos de puntuación ad hoc y de aprendizaje automático.

¿Qué entidades se puntúan?

Decidir qué componentes de una red de confianza cero deben puntuarse es una consideración interesante. ¿Deben calcularse las puntuaciones para cada entidad individual (usuario, dispositivo y aplicación), para el agente de red en su conjunto, o para ambos? Veamos algunos escenarios.

Imagina que un tercero malintencionado fuerza bruta las credenciales de un usuario. Algunos sistemas mitigarán esta amenaza bloqueando la cuenta del usuario, lo que puede suponer un ataque de denegación de servicio contra ese usuario concreto. Si puntuáramos negativamente a un usuario basándonos en esa actividad, una red de confianza cero sufriría el mismo problema. Un enfoque mejor es darse cuenta de que estamos autenticando al agente de red, y así se contrarresta al agente de red del atacante, dejando indemne al agente de red del usuario legítimo. Este escenario defiende que el agente de red es la entidad que debe ser puntuada.

Pero limitarse a anotar el agente de red puede ser insuficiente contra otros vectores de ataque. Considera un dispositivo que ha sido asociado con actividad maliciosa. Puede que el agente de red de un usuario en ese dispositivo no muestre signos de comportamiento malicioso, pero el hecho de que el agente se forme con un dispositivo sospechoso debería tener un claro impacto en la puntuación de confianza de todas las solicitudes originadas en ese dispositivo. Este escenario sugiere claramente que el dispositivo debe ser puntuado.

Por último, considera que un usuario humano malintencionado (la infame amenaza interna) utiliza varios dispositivos de quiosco para exfiltrar secretos comerciales. Nos gustaría que el motor de confianza reconociera este comportamiento a medida que el usuario salta de un dispositivo a otro y que reflejara el nivel decreciente de confianza en su puntuación de confianza para todas las futuras decisiones de autorización. También en este caso, vemos que la puntuación del agente de red por sí sola es insuficiente para mitigar las amenazas habituales.

En conjunto, parece que la solución correcta es puntuar tanto al propio agente de red como a las entidades subyacentes que lo componen. Estas puntuaciones pueden exponerse al motor de la política, que puede elegir el componente o componentes correctos a autorizar en función de la política que se escriba.

Sin embargo, presentar tantas puntuaciones para que se tengan en cuenta a la hora de redactar la política puede dificultar la tarea y hacerla más propensa a errores. En un mundo ideal, bastaría con una única puntuación, pero ese planteamiento impone requisitos adicionales de disponibilidad al motor de confianza. Un sistema que intente crear una única puntuación probablemente tendría que pasar a un modelo en línea, en el que el motor de confianza sea consultado interactivamente durante la toma de decisiones políticas. Al motor se le daría algún contexto sobre la solicitud que se está autorizando para que pudiera elegir la mejor función de puntuación para esa solicitud concreta. Este diseño es claramente más complejo de construir y manejar. Además, para la política en la que un administrador del sistema desea específicamente dirigirse a un componente concreto (por ejemplo, sólo permitir implementaciones desde dispositivos con una puntuación superior a X), parece bastante indirecta.

Exponer las puntuaciones consideradas arriesgadas

Aunque las puntuaciones asignadas a las entidades en una red de confianza cero no se consideran confidenciales, debe evitarse exponer las puntuaciones a los usuarios finales del sistema. Ver la puntuación de uno mismo podría ser una señal para los posibles atacantes de que están aumentando o disminuyendo su confianza en el sistema. Este deseo de ocultar información debe equilibrarse con la frustración de que los usuarios finales puedan comprender cómo sus acciones están afectando a su propia confianza en el sistema. Un buen compromiso del sector del fraude es mostrar a los usuarios sus puntuaciones con poca frecuencia, y destacar los factores que contribuyen a su puntuación determinación.

Almacenes de datos

Los almacenes de datos utilizados para tomar decisiones de autorización son, sencillamente, las fuentes de la verdad sobre el estado actual y pasado del sistema. La información de estos almacenes de datos fluye a través de los sistemas del plano de control, proporcionando gran parte de la base sobre la que se toman las decisiones de autorización, como se muestra en la Figura 4-4.

Anteriormente hablamos de que el motor de confianza aprovecha estos almacenes de datos para producir una puntuación de confianza, que a su vez es considerada por el motor de políticas. De este modo, la información de los almacenes de datos del plano de control ha fluido a través del sistema de autorización, llegando finalmente al motor de políticas, donde se ha tomado la decisión. Estos almacenes de datos son utilizados por el motor de políticas, tanto directa como indirectamente, pero pueden ser útiles para otros sistemas que necesiten datos fidedignos sobre el estado de la red.

Figura 4-4. Los almacenes de datos autorizados son utilizados por el motor de políticas tanto directamente como indirectamente a través del motor de confianza

Las redes de confianza cero suelen tener muchos almacenes de datos, organizados por funciones. Hay dos tipos principales:el inventario y el histórico. Un inventario es una única fuente coherente de verdad, que registra el estado actual del recurso o recursos que representa. Un ejemplo es un inventario de usuarios que almacena toda la información de los usuarios, o un inventario de dispositivos que registra la información sobre los dispositivos conocidos por la empresa.

En un inventario, existe una clave primaria que representa unívocamente a la entidad rastreada. En el caso de un usuario, lo más probable es que sea el nombre de usuario; para un dispositivo, quizá sea un número de serie. Cuando un agente de confianza cero se somete a autenticación, está autenticando su identidad frente a esta clave primaria del inventario. Piénsalo así: un usuario se autentica con un nombre de usuario determinado. El motor de políticas conoce el nombre de usuario y sabe que el usuario se ha autenticado correctamente. El nombre de usuario se utiliza entonces como clave primaria para la búsqueda en el inventario de usuarios. Tener en cuenta este flujo y propósito te ayudará a elegir las claves primarias correctas, dependiendo de tu implementación particular y de tus opciones de autenticación.

Un almacén de datos históricos de es un poco diferente. Los almacenes de datos históricos se guardan principalmente con fines de análisis de riesgos. Son útiles para examinar comportamientos y patrones recientes/pasados con el fin de evaluar el riesgo en relación con una solicitud o acción concreta. Lo más probable es que los componentes del motor de confianza consuman estos datos, ya que las determinaciones de confianza/riesgo son la principal responsabilidad del motor.

Se pueden imaginar muchos tipos de almacenes de datos históricos, y cuando se trata de análisis de riesgos, el cielo es el límite. Algunos ejemplos comunes son los registros contables de usuarios y los datos sFlow. Independientemente de los datos que se almacenen, deben poder consultarse utilizando la clave primaria de uno de los sistemas de inventario.

Hablaremos de varios almacenes de inventario y de datos históricos a medida que introduzcamos conceptos relacionados a lo largo de este libro .

Resumen

Este capítulo se ha centrado en los sistemas responsables de tomar la decisión última de si una solicitud concreta debe autorizarse en una red de confianza cero. Esta decisión es un componente crítico de una red de este tipo y, por tanto, debe diseñarse y aislarse cuidadosamente para garantizar que sea digna de confianza.

Desglosamos esta responsabilidad en cuatro sistemas clave: aplicación, motor de políticas, motor de confianza y almacenes de datos. Estos componentes son áreas lógicas de responsabilidad. Aunque podrían colapsarse en menos sistemas físicos, los autores prefieren un diseño aislado.

El sistema de aplicación de se encarga de garantizar que la decisión de autorización del motor de políticas surta efecto. Este sistema, al estar en la ruta de datos del tráfico de usuarios, se implementa mejor de forma que se haga referencia a la decisión política y luego se aplique. Dependiendo de la arquitectura elegida, el motor de la política podría ser notificado antes de que se produzca una solicitud, o durante el procesamiento de esa misma solicitud.

El motor de políticas es el sistema clave que calcula la decisión de autorización basándose en los datos de que dispone y en las definiciones de políticas que han elaborado los administradores del sistema. Este sistema debe estar fuertemente aislado. Lo ideal es que la política definida se almacene separada del motor y que se utilicen buenas prácticas de desarrollo de software para garantizar que los cambios se comprenden, se revisan y no se pierden a medida que la política pasa de ser propuesta a ser aplicada. Además, dado que las redes de confianza cero esperan tener una política mucho más detallada, las organizaciones maduras optan por distribuir la responsabilidad de definir esa política en la organización, con equipos de seguridad que revisen los cambios propuestos.

El motor de confianza es un concepto nuevo en los sistemas de seguridad. Este motor se encarga de calcular una puntuación de confianza de los componentes del sistema utilizando algoritmos estáticos e inferidos derivados de comportamientos anteriores. La puntuación de confianza es una determinación numérica de la fiabilidad de un componente y permite a los redactores de políticas centrarse en el nivel de confianza necesario para acceder a algún recurso, en lugar de en los detalles concretos de las acciones que podrían reducir esa confianza.

El componente final de esta parte del sistema son las fuentes de datos autorizadas que capturan datos actuales e históricos que pueden utilizarse para tomar la decisión de autorización. Estos almacenes de datos deben centrarse en ser fuentes de verdad. El motor de políticas, el motor de confianza y quizás los sistemas de terceros puedan aprovechar estos datos, de modo que la recopilación de estos datos tenga un retorno de la inversión decente al capturarlos.

El próximo capítulo profundizará en cómo los dispositivos ganan y mantienen la confianza de .