Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuál es el papel de la identidad en la seguridad de API?


¿Qué opciones tienen las API y los microservicios cuando se trata de autenticación y autorización ? ¿Cuál es el papel de la identidad en la seguridad de la API?

En nuestro último LiveCast , buscamos descubrir las mejores prácticas para manejar la  identidad dentro de la seguridad de la API. Presentamos dos charlas iluminadoras; uno de David Garney de Tyk y otro de Travis Spencer de Curity. Ambos realizarán talleres en la Cumbre de la Plataforma , así que si te gusta lo que lees a continuación, ¡ regístrate para tu lugar hoy!

Mira el LiveCast aquí:

Los diversos mecanismos de autenticación

Entonces, ¿cómo autenticamos a los usuarios para nuestras API? Integradas en aplicaciones de terceros, las API requieren un tipo único de control de acceso y existen muchas opciones para la autenticación y autorización de microservicios.

Los beneficios de los microservicios

Como hemos visto antes, los microservicios son livianos y ofrecen una simplicidad individualista que las aplicaciones monolíticas simplemente no pueden proporcionar. También son flexibles ; los servicios se pueden implementar en diferentes hosts y con diferentes pilas técnicas. Funcionan bien con contenedorización, CI y CD. Además, dado que estas aplicaciones están separadas, significa que la exposición a ataques disminuye, lo que aumenta la seguridad en general.

Aunque los microservicios son únicos, a menudo funcionan en conjunto entre sí, lo que significa que los necesitamos para actuar de manera coherente. Un ejemplo es tener una forma estándar de saber  quién los consume y sus privilegios de acceso .

Entonces, ¿cómo implementamos un método estándar de autenticación y autorización en todos los microservicios? En su presentación, Dave Garney de Tyke cita tres formas específicas de implementar este control:

  1. Internamente dentro de cada microservicio
  2. Externamente mediante el uso de una puerta de enlace
  3. O usando una combinación de componentes internos y externos

Enfoque interno

En la estrategia 100% interna, los microservicios manejan tanto la autenticación como la autorización. En esta arquitectura, el usuario atraviesa ambos. Por lo tanto, el servicio tiene un control detallado, pero también significa que el servicio es autosuficiente y se ajusta al enfoque de microservicios. Las desventajas incluyen un esfuerzo de desarrollo adicional y es probable que se deban construir microservicios adicionales para manejar estas funciones.

Dave sostiene que al manejar la autenticación y la autorización por separado para cada microservicio, estamos perdiendo la oportunidad de reducir el exceso de código . Cuanto mayor sea la cantidad de microservicios involucrados, más valioso será externalizar este enfoque.

Externo

Con un enfoque externo, una puerta de enlace maneja tanto la autenticación como la autorización. Por lo tanto, no es necesario crear microservicios adicionales. Las ventajas son que al poner la responsabilidad en la puerta de enlace, puede eliminar la carga de los microservicios para centrarse en sus propias necesidades. Las desventajas podrían ser un control menos detallado si la puerta de enlace no puede tomar decisiones sobre información a la que tampoco tiene acceso. Dave también señala algunas vulnerabilidades potenciales; Depender completamente de una puerta de enlace significa que podría intentar circunnavegarla y acceder a la fuente directamente. Por supuesto, hay formas de mitigar esto.

Combinación

En el enfoque combinado de Dave, la autenticación tiene lugar en la puerta de enlace , como enfoque externo, lo que alivia la carga de cada microservicio para manejar la autenticación. La autorización tiene lugar en el microservicio. Por lo tanto, los microservicios se vuelven más ágiles, ya que no tienen que preocuparse por la autenticación, pero aún pueden autorizar según las credenciales proporcionadas. Los contras podrían ser un poco más de esfuerzo de desarrollo.

Enfoque Ricitos de Oro?

Dave recomienda el enfoque externo si es posible, ya que permitir que una puerta de enlace maneje tanto la autorización como la autenticación brinda cualidades que ahorran tiempo. Señala que, prácticamente, la mayoría utilizará un enfoque Ricitos de oro; un término medio entre la combinación y los enfoques externos.

Intente identificar requisitos de autorización complejos e implementarlos en su microservicio.

Dave define esta forma de pensar como macroautorización frente a microautorización. Macro-autorización como en la pasarela de acceso autoriza a todos sus microservicios y micro-autorización  , ya que cada microService que se amplía la autorización a sí mismos. Recomienda mecanismos de autorización complejos adaptados a los escenarios únicos en cuestión. El acceso a la base de datos, por ejemplo, se implementa mejor como microautorización.

Dave recomienda OpenID connect para la autenticación y, en su mayor parte, enfatiza la importancia de las puertas de enlace para descargar la funcionalidad a la puerta de enlace:

Lo que debe terminar es el equilibrio adecuado de descargar la mayor cantidad posible de esfuerzo de autenticación y autorización en la puerta de enlace, al tiempo que conserva la capacidad de realizar autorizaciones complejas a nivel de microservicio.

WS-Tyk-18

¿Quieren más? Regístrese aquí para el Tyk Workshop en la Platform Summit .

Avanzar con OAuth y OpenID Connect

A continuación, profundicemos un poco más en OAuth y OpenID Connect. Travis Spencer, director ejecutivo de Curity, no es ajeno a las estrategias de control de identidad. Describe Curity como un servidor OAuth avanzado y listo para usar, apto para banca, comercio minorista, telecomunicaciones y muchos otros casos de uso.

Los 4 actores de OAuth

Travis define los fundamentos básicos de OAuth con estos cuatro actores. Esto es lo que suele utilizar la literatura y la documentación sobre OAuth. Estos 4 actores conforman los flujos que discutimos a menudo en el blog.

  • Cliente : La aplicación; pueden ser aplicaciones móviles, aplicaciones web, aplicaciones de servidor y más.
  • Servidor de autorización (servidor OAuth) : a veces llamado proveedor de identidad, o en OpenID Connect se llama OP.
  • Servidor de recursos : estas son las API en sí mismas.
  • Propietario del recurso : normalmente un usuario, el que controla el recurso. También podría ser una organización, pero a menudo es un usuario.

Entonces, ¿cómo interactúan estos actores normalmente? Bueno, para una comparación más detallada, le recomendamos que asista al taller Advanced OAuth en la Platform Summit.

WS-curiosidad-2-18

Para obtener información avanzada de Travis Spencer, asista al taller Advanced OAuth y OpendID Connect.  (AGOTADO)

¡Regístrese hoy!

 

 



Publicar un comentario

0 Comentarios