Header Ads Widget

Ticker

6/recent/ticker-posts

Técnicas para madurar la seguridad de la plataforma



Si le gusta construir con API, probablemente esté introduciendo una nueva arquitectura de software para brindar avances en la escalabilidad y la eficiencia. ¿Pero también estás introduciendo inseguridades? A medida que los ecosistemas digitales maduran, también debe hacerlo la ciberseguridad. Especialmente para plataformas grandes con recursos externalizados, se deben esperar violaciones de datos y las vulnerabilidades de API deben mitigarse antes de que ocurra una violación.

Para combatir estos problemas frecuentes, recientemente reunimos a tres oradores expertos en nuestro LiveCast de seguridad de plataforma de maduración . Este seminario web de una hora presenta a los expertos en seguridad de API Jacob Ideskog , vicepresidente y experto en identidad de Curity , el Dr. Keith Casey , solucionador de problemas de API en Okta y Himanshu Kumar , seguridad y diseño de API de MTS en T-Mobile.

A continuación, cubrimos las principales conclusiones de este diálogo de expertos y demostramos cómo el manejo de identidades y las pruebas adecuadas pueden madurar las plataformas API a escala. Cubriremos una escala de madurez para la seguridad de las API, el manejo práctico de los ámbitos en un entorno empresarial del mundo real y pensar como un malvado para atacar sus propias API.

Vea el LiveCast de seguridad de plataforma madura aquí:

Primero, ¿qué es la madurez de seguridad de API?

Jacob Ideskog trabaja con OpenID Connect y OAuth todos los días, creando servidores OAuth y mecanismos de autenticación en Curity. A lo largo de su trabajo, ha visto todo tipo de enfoques de seguridad API, desde HTTP Basic Auth, API Keys , JWTs y flujos avanzados de OAuth . Naturalmente, algunos métodos son mejores que otros.

Según Jacob, comprender la seguridad de la plataforma comienza con comprender dónde se encuentra su plataforma en  el modelo de madurez de seguridad de API . Tomando ideas prestadas del modelo de madurez REST Richardson , el modelo de madurez de seguridad de API define un espectro de modelos de seguridad de API. Muestra cuán segura es una plataforma y ofrece una escalera paso a paso para mejorar.

Jacob-Ideskog

Jacob Ideskog describe cómo evaluar la madurez de su enfoque de seguridad de API con un modelo útil.

El modelo de madurez de seguridad de API comienza en el nivel cero . En Level Zero, la plataforma solo usa claves API o autenticación básica. Para Jacob, este es un método heredado e inseguro porque solo verifica que una máquina pueda hablar con otra máquina; no vincula al usuario con el recurso solicitado. La información del usuario, transmitida dentro de las solicitudes HTTP, permanece sin confirmar. Es solo autenticación, sin autorización.

El nivel uno introduce la autenticación basada en token con un servidor OAuth. Los flujos de OAuth involucran a los usuarios para autenticarse y otorgar acceso con un token de portador, lo que hace que el usuario forme parte del mecanismo de autenticación. El nivel uno es un buen comienzo, ya que vincula al usuario con la solicitud, pero este enfoque aún no verifica la autorización, es decir, "LO que se le permite hacer". El nivel uno también lucha para separar roles entre grupos, como backend versus usuarios externos.

El nivel dos presenta los ámbitos de OAuth. Estos contienen "permisos" denominados, que se pueden utilizar para asignar roles de acceso. Jacob detalla cómo una tienda de comercio electrónico podría usar ámbitos para asignar roles específicos, como inventory_readleer o billing_writeEstos ámbitos están integrados en el token. El nivel dos bloquea la aplicación, vinculando los permisos de usuario. Desafortunadamente, los ámbitos todavía están vinculados a la aplicación, no al usuario. Este modelo también conduce a una cadena de confianza no deseada.

Por último, el nivel tres es el paso final en el modelo de madurez de seguridad de API. Aquí, presentamos la confianza centralizada mediante reclamaciones . Según Jacob, una Reclamación es "una propiedad sobre un sujeto afirmada por una parte". Al incorporar reclamos en tokens de acceso (como ID de cuenta o tipos de usuario), el servidor OAuth puede buscar detalles de identidad y centralizar esta seguridad.

La confianza centralizada mediante reclamos es “el lugar al que desea llegar para madurar su modelo de seguridad API”, dice Jacob. Con este enfoque, la autorización es uniforme y confiable, y los vectores de ataque (o espacio para errores honestos) se reducen significativamente.

Estudio de caso: Comunicación de confianza cero en T-Mobile

Himanshu Kumar

Himanshu Kumar demuestra cómo se pueden utilizar los ámbitos de OAuth junto con un modelo de confianza cero.

Himanshu Kumar está de acuerdo en que los tokens y los ámbitos vinculados al usuario proporcionan un alto nivel de madurez de seguridad. Dentro de nuestro LiveCast, Himanshu se basó en las ideas de Jacob para analizar cómo se están aplicando OpenID Connect y OAuth Scopes en una situación de nivel empresarial para habilitar la seguridad de punto final federado.

Himanshu reconoce cómo puede encontrar problemas al introducir el uso de Scope. Por un lado, reconoce que, por razones de experiencia del usuario, los ámbitos no siempre reflejan los ámbitos seleccionados por el usuario. Reconoce otros problemas al interpretar de forma universal los ámbitos y aprovechar los ámbitos para la autorización de acceso a los puntos finales.

En entornos empresariales, un servidor de identidad normalmente concede una aplicación para realizar llamadas en nombre de un usuario. Dentro de este entorno, los ámbitos están hechos para representar funcionalidades de punto final controladas por dominios; como dice Himanshu, "una unión del usuario y el cliente de la aplicación". Himanshu describe cómo adoptar dos tipos de tokens: un token de acceso para la autorización de punto final y un token de identidad para la autorización de datos a nivel de usuario.

Si una empresa tiene miles de puntos finales de API y cientos de dominios, habrá muchas dependencias de API entre dominios. Entonces, ¿cómo podemos abordar esto manteniendo la seguridad? Himanshu recomienda adoptar el modelo Zero Trust , en el que los tokens de acceso deben volver a emitirse para cruzar dominios.

Himanshu también destaca la importancia de la gobernanza para OAuth Scopes y las vistas previas de tokens de acceso. Un aspecto de esto son las convenciones de nomenclatura para los ámbitos. En T-Mobile, que se definen con tres segmentos como tales: <domain-name>:<resource/function>:<action>Un ejemplo sería is ecommerce:orders:readVea la presentación completa para conocer los pensamientos adicionales de Himanshu sobre la gobernanza del alcance, el flujo de tokens y las técnicas de optimización.

Cómo se administran los ámbitos en un entorno empresarial.

Amanecer del sombrero negro

Keith Casey

Mientras que nuestros dos primeros oradores buscan mejorar la seguridad de la API, Keith Casey apunta a destruirla.

Como solucionador de problemas de API en Okta, el Dr. Keith Casey Jr "vive y respira" OAuth y los problemas de seguridad del cliente. En su charla, " Privacidad práctica y enfoque adverso ", Keith examina cómo coquetear con el lado oscuro puede revelar vulnerabilidades invisibles.

Pero primero, para considerar cómo surgen las vulnerabilidades, vayamos a la raíz del problema. Normalmente, una API se desarrolla internamente para resolver algún tipo de problema operativo. Lo usa un solo equipo. Con el tiempo, el interés en la API crece a medida que más equipos ven los beneficios de su uso y el uso se expande en toda la organización.

Ahora, aquí es cuando ocurre un cambio importante: las personas orientadas al producto ven el potencial comercial en la integración y presionan para abrirla a los socios. Pensar en la API comienza a cambiar de un mecanismo interno a una API como producto . Ahora, tenemos cientos de desarrolladores externos que consumen una API que originalmente estaba destinada a un caso de uso interno mínimo. ¿Ves el dilema?

Según Keith, con demasiada frecuencia, los equipos de seguridad solo conocen la API justo antes de que se externalice. Los desarrolladores a menudo no crean desde un punto de vista externo. Por tanto, las vulnerabilidades suelen estar codificadas de forma rígida. Keith ve muchos dilemas en esta progresión típica.

"Fundamentalmente, debemos darnos cuenta de que a medida que nuestras API tengan éxito, su uso crecerá", dice Keith. “Si no tomamos en cuenta estas preocupaciones desde el principio, causarán problemas catastróficos más adelante”. Parece que existen beneficios de seguridad al seguir la filosofía de Amazon de construir para la externalización desde el primer día.

Para rectificar las brechas, los propietarios deben considerar la seguridad antes de la fase del producto y junto con el desarrollo. Imagina que eres un atacante. ¿Cómo haría un mal uso y abuso de una API? Al adoptar esta perspectiva con sus propios servicios, los propietarios de productos pueden aprender mucho y armar mejor sus servicios.

Keith recomienda que los desarrolladores de API ataquen literalmente los modos de autenticación y autorización, los puntos finales y las cargas útiles. Aquí hay algunas formas de mejorar su API:

Autenticación

  • Pruebe sus claves de API: ¿Son las cadenas de caracteres lo suficientemente largas? ¿Cómo se aseguran?
  • Pruebe sus ámbitos: ¿Los ámbitos reflejan realmente los permisos que otorgan?
  • Fuzz your scopes: si combinamos scopes, ¿eso trae resultados negativos? ¿Hay desajustes entre sistemas?

Puntos finales

  • Usar datos basura: ¿Qué sucede si le damos enormes paquetes de solicitudes? Trate de paralizar los sistemas.
  • Explore endpoints: utilice Open API & Hypermedia para descubrir endpoints. Genere URL aleatorias para encontrar puntos finales "secretos".
  • Pruebe todos los verbos: ¿El uso del método OPTIONS HTTP produce un resultado inesperado?

Carga útil

  • Incrementar los ID: literalmente agregue "1" a los ID de cliente.
  • Revise los mensajes de error: considere si los mensajes de error están revelando demasiada información.
  • Prueba todos los verbos: alimenta cargas complejas con verbos HTTTP matizados.

Keith agrega que la realización de estas acciones debería activar muchas alertas de monitoreo de API. De lo contrario, es una señal de que sus procesos de DevSecOps no están funcionando tan bien como deberían.

Si toma el sombrero negro para adoptar un enfoque de confrontación, es probable que encuentre vulnerabilidades que no había considerado (como el "usuario amable" que es) y descubrirá información que su API está exponiendo involuntariamente. Puede que también te diviertas un poco.

Keith agrega que es mejor "atacar nuestra API con las personas en las que confiamos". Porque si no lo hace, alguien más lo hará.

Conclusiones de la seguridad de la plataforma madura

Los exploits continuos  demuestran claramente una falta de madurez de la seguridad en toda la industria, lo que subraya la necesidad de una mayor previsión de seguridad. En este seminario web, pudimos vislumbrar cómo los proveedores de API pueden mejorar su seguridad con enfoques establecidos. Algunas conclusiones clave incluyen:

  • Los alcances y reclamaciones de OAuth son la forma más madura de seguridad de API
  • Considere cómo los malos pueden hacer un mal uso de su API
  • Pruebe las acciones de solicitud de carga útil, puntos finales y autenticación

Publicar un comentario

0 Comentarios