Header Ads Widget

Ticker

6/recent/ticker-posts

Cuando cero es mejor que uno: arquitectura de confianza cero

 

El enfoque tradicional de la seguridad se ha centrado en establecer el sistema perimetral. Las medidas de protección estaban destinadas a evitar que usuarios no autorizados accedan a la red corporativa. De esta manera, se trataba principalmente de proteger las redes y los recursos internos de las intrusiones externas. Sin embargo, este enfoque significaba que el sistema sería vulnerable de una manera diferente. La seguridad del perímetro, naturalmente, no ayuda a prevenir ataques en los que un intruso externo se hace pasar por un usuario interno. Si un intruso puede atravesar el perímetro, puede moverse rápidamente lateralmente dentro de la red para obtener más acceso a los recursos corporativos.

Hoy en día, con más recursos moviéndose a la nube y empleados trabajando de forma remota más que nunca, el perímetro realmente ya no existe. Aquí es donde entra en juego Zero-Trust Architecture.

¿Qué es Zero-Trust?
Zero-Trust Architecture (ZTA) no es una arquitectura única en sí misma. Primero, es una filosofía que asume que hay atacantes tanto dentro como fuera de la red. Por lo tanto, no se debe confiar automáticamente en ningún usuario o máquina. En segundo lugar, ZTA es un conjunto de pautas para diseñar sistemas y operaciones para reforzar la seguridad y proteger los activos de la empresa.

El principio fundamental de ZTA es "no confiar en nadie". Esto significa que ninguna entidad debería tener acceso a ningún recurso hasta que estén autenticados y hayan demostrado quiénes son y qué privilegios de acceso tienen. Este principio se aplica a todos los recursos y comunicaciones, ya sean internos o externos, y las políticas de acceso están bien definidas. ZTA pone énfasis en las aplicaciones y servicios para verificar siempre la entidad que solicita acceso a un recurso determinado.

¿Este usuario tiene permiso para acceder a este registro desde la ubicación indicada? ¿Este microservicio tiene permiso para acceder a otro microservicio para recuperar datos?

Estos tipos de decisiones de acceso generalmente se manejan bien mediante sistemas de control de acceso basados ​​en atributos o políticas, como Rego, XACML u otros lenguajes de políticas o productos que los admitan. Las políticas se modelan y controlan mediante un punto de decisión de políticas (PDP) y se aplican mediante un punto de aplicación de políticas (PEP). La implementación real del PEP difiere; podría ser una puerta de enlace API , por ejemplo. El aspecto de la autenticación está en el centro de esto, ya que es difícil determinar el acceso si se desconoce la entidad solicitante, independientemente de si se trata de un usuario, sistema o dispositivo.

¿Quién necesita confianza cero?
La respuesta corta es para todos.

La respuesta larga es que Zero-Trust es esencial para cualquier persona cuyas operaciones presuponen trabajar en la nube o en las instalaciones con diferentes usuarios o sistemas que acceden a la red o diferentes servicios. ZTA es fundamental no solo para el trabajo remoto, sino también para garantizar que las empresas tengan la oportunidad de crecer, tanto interna como externamente, con privilegios de acceso establecidos.

ZTA suele ser una prioridad mayor para las organizaciones que se ocupan de grandes volúmenes de datos críticos. Por ejemplo, la atención médica, las organizaciones financieras y las agencias gubernamentales son segmentos que generalmente tratan con algún nivel de información de identificación personal (PII). Por lo tanto, deberían estar mirando a ZTA si aún no lo han hecho.

Los esfuerzos de modernización y transformación digital suelen impulsar el uso de API. Con esto, la adopción de API crece constantemente y debería impulsar aún más la adopción de ZTA. Las API se utilizan como un punto de entrada a los datos y los usuarios, sistemas y dispositivos acceden a ellas. Por tanto, será fundamental implementar un mecanismo robusto para verificar quién tiene acceso a una API determinada en un contexto determinado.

¿Cómo pueden las plataformas basadas en API adoptar un enfoque de confianza cero?
Las API son tanto internas como externas. Siguiendo un enfoque ZTA, deben recibir el mismo trato. No confíes en nadie; verificar siempre. En los entornos modernos, las API son los puntos de entrada a todos los datos y serán un componente crítico para controlar el acceso. El enfoque histórico de controlar el acceso a las API mediante claves de API no será suficiente en un ZTA. Como hemos comentado anteriormente , las claves de API se pueden robar o compartir fácilmente, y será imposible verificar la identidad de la persona que llama que presenta una clave de API.

Una arquitectura moderna basada en tokens construida sobre OAuth y OpenID Connect encaja excepcionalmente bien en una plataforma basada en API. También podrá manejar todos los requisitos para un ZTA sólido. Existen flujos para autenticar tanto a los usuarios como a los sistemas. Después de una verificación exitosa, se pueden emitir tokens que contengan reclamos que se utilizan para controlar más el acceso y permitir un enfoque de privilegios mínimos.

Como se mencionó anteriormente, una puerta de enlace API puede ubicarse frente a las API y proporcionar protecciones valiosas, incluida la validación del token de acceso. Aquí hay patrones, como el enfoque de token fantasma y el enfoque de token dividido que se pueden usar según la arquitectura general y el caso de uso. Ambos están destinados a desalentar el uso de PII por parte de la aplicación que llama a la API. En cambio, la puerta de enlace API puede resolver esta información y pasarla a la API según sea necesario. Esto enfatizará aún más un enfoque ZTA.

Tanto si se utiliza una puerta de enlace API como si no, el control aquí se encuentra dentro del software. Esto puede abarcar múltiples arquitecturas y atender a organizaciones que utilizan un enfoque de múltiples nubes con servicios que se ejecutan en las instalaciones.

¿Cómo se debe implementar la confianza cero?
Hay cuatro bloques de construcción principales para implementar ZTA:

Un inventario de sistemas para detectar anomalías,
Procesamiento de autenticación y autorización,
Monitoreo de red y Contención y mitigación de amenazas.
Con todos estos procesos cruciales, uno se destaca porque lleva a cabo el principal requisito para ZTA: determinar quién es el usuario. Un sistema debe comprobar si el usuario es interno o externo, a qué parte de la organización pertenece, qué servicio está solicitando información de otro servicio, o incluso qué servicio de terceros está solicitando acceso a un servicio corporativo interno.

Estas son las tecnologías y estándares clave que ayudan a implementar Zero-Trust y garantizar que la autenticación y la autorización se desarrollen sin problemas:

1. Arquitectura basada en tokens
Una arquitectura basada en tokens es precisamente el tipo de servicio de autenticación robusto que se necesita para comenzar a implementar un ZTA. La razón es que el enfoque de autenticación basado en tokens puede manejar todos los diferentes tipos de casos de uso que abarcan desde usuarios que acceden a recursos hasta servicios que se comunican con otros servicios. Es escalable y altamente flexible y es el método a utilizar cuando se trata de seguridad API y control de acceso a microservicios.

Una arquitectura basada en token tiene varios aspectos del importante proceso de verificación ya integrados. Esto podría ser en forma de introspección de un token de acceso o decodificación y validación de un JWT. Además de una simple verificación que verifica si el token aún es válido, existe la noción de alcances y reclamos que se pueden aprovechar para controlar aún más qué acceso se otorga.

2. Autenticación multifactor (MFA)
Al autenticar cada solicitud de acceso a un recurso, interno o externo, el componente de autenticación se convierte en clave en ZTA. Debe haber mucha flexibilidad en el tipo de autenticación realizada para manejar tanto a los usuarios como a los servicios. Todos los recursos tampoco son iguales, por lo que habrá escenarios en los que se requiera algún tipo de autenticación intensiva para recursos más críticos donde probablemente se prefiera la autenticación multifactor (MFA) .

3. Inicio de sesión único
Los usuarios se moverán de un servicio a otro y accederán a diferentes recursos, y con eso, el inicio de sesión único (SSO) desempeñará un papel importante para optimizar la experiencia del usuario. Por supuesto, no todos los servicios permitirán SSO, ni deberían hacerlo. Esto debe controlarse y configurarse según el servicio y los datos a los que se accede, así como otras entradas contextuales.

4. Métodos de autenticación y sistema de alerta personalizables
En el proceso de autenticación, también debe considerar el nivel de confianza en la autenticación. Aquí es donde entran en juego entradas adicionales como la hora del día, la ubicación geográfica, la puntuación de riesgo, etc., para aumentar el método de autenticación y calcular la confianza de la autenticación dada. Por ejemplo, si la puntuación indica un nivel de riesgo inaceptable, tal vez sea necesario alertar / informar, y se deben invocar factores adicionales para elevar el nivel de confianza de la identidad del usuario.

Conclusión
Dado que la autenticación ocurre con cada solicitud de acceso a un recurso, la autenticación se vuelve crítica para implementar un ZTA. Una arquitectura basada en tokens se mapea excepcionalmente bien para manejar esto tanto para usuarios, servicios y dispositivos.

Las organizaciones deben avanzar hacia la implementación gradual de una ZTA para proteger sus recursos. Primero, comience con los recursos críticos y determine los requisitos para una autenticación sólida, incluidos los enfoques MFA y SSO para fortalecer la seguridad y facilitar la transición para los usuarios finales. Una gran confianza en la autenticación puede permitirle avanzar más en el aprovechamiento de una puerta de enlace de API para proteger las API mediante una arquitectura basada en token. En este caso, la autorización detallada mediante una política y atributos centralizados puede ayudar a determinar quién debería tener acceso a qué datos.

Publicar un comentario

0 Comentarios