Header Ads Widget

Ticker

6/recent/ticker-posts

Seguridad API: las 4 defensas de la fortaleza API

 

4_defenses_API_stronghold_nordic_APIs

En un momento u otro, sus recursos seguros serán atacados. Esta es la desafortunada realidad de la era moderna, donde las habilidades necesarias para abrir un sistema, una red o una API de forma invasiva son más comunes que nunca. Se pueden perder millones de recursos e ingresos potenciales en cuestión de horas debido a una mala planificación e implementación de un protocolo de seguridad .

La información privada, los secretos comerciales e incluso los datos personales pueden ser expuestos al experto en penetración de la red y utilizados en su contra de formas tan extremas como variadas. Este artículo tiene como objetivo reforzar sus defensas definiendo los cuatro fundamentos de la seguridad API: autenticación , autorización , federación y delegación .

La importancia de la comprensión

Uno de los fallos de comprensión más comunes en el desarrollo de seguridad API es la idea de que la seguridad es una solución de "talla única". La idea de que los canales de seguridad funcionan de manera singular con variaciones solo en la experiencia final del usuario final es tan errónea como peligrosa; este concepto coloca al operador en una posición de menos herramientas a su disposición que aquellos que intentan "romper el sistema", exponiendo a su vez sus datos a un nivel extremo de riesgo innecesario.

Este problema se ve agravado por un malentendido común con respecto a las diferencias entre Autorización, Autenticación, Federación y Delegación. , lo que perpetúa un abismo de información errónea y mala aplicación. Este abismo ha causado muchos problemas de seguridad en el espacio de la API.

Dado que estos cuatro términos son en lo que se basa todo el concepto de seguridad API , es imperativo que los comprenda, sus usos y las implicaciones de su adopción. La falta de una comprensión básica de los protocolos, las metodologías y los conceptos de seguridad puede significar la diferencia entre un negocio próspero y orientado al crecimiento y un negocio estancado y que se deprecia.

Banner básico-01

Equilibrio de acceso y permisos

Tener una API que permita el acceso completo a la totalidad de sus sistemas y recursos es una pesadilla absoluta; es similar a ser el señor de un castillo y dejar las puertas de su bóveda abiertas de par en par; atrae el robo por su propia naturaleza, y abre innecesariamente sus materiales al espacio público. Como señor de tu fortaleza, ¿por qué darles a los merodeadores una vía de ataque?

Entonces, ¿cuál es la respuesta adecuada? ¿Dejamos los sistemas abiertos para mejorar la funcionalidad y asumimos que los usuarios tienen intenciones positivas? ¿O seguimos una ruta completamente opuesta, cerrando todas las funcionalidades, diseñando solo sistemas propietarios?

La solución radica en la combinación de ambos enfoques. Suponga que su enemigo está tratando de atraparlo en todo momento, pero no permita que esto afecte su necesidad de hacer negocios. La vigilancia constante le permite diseñar su API de una manera inteligente , abriendo solo lo que necesita abrirse y asegurándose de que esas aberturas no se relacionen con sistemas vitales que podrían dañarse. Funcionalmente, esto significa asignar elementos de autoridad a los consumidores de API en función de la cantidad mínima de acceso que necesitan para realizar las funciones que deben realizar . Al asignar diferentes roles y niveles de responsabilidades a los clientes, podemos crear un entorno escalonado que mantiene nuestros datos seguros.

Comprender las implicaciones de este sistema es de suma importancia, específicamente las diferencias entre los tipos de derechos y autoridades dentro del sistema en su conjunto. En nuestras definiciones, volveremos a la analogía de la defensa del castillo. El valiente y poderoso caballero Lancelot está tratando de regresar a la corte artúrica después de un largo mes luchando contra merodeadores sedientos de sangre; veamos qué defensas tendrá que pasar ...

Autenticación: identidad

"Soy yo Lancelot, con la contraseña 'Guinevere'"

“Tis I Lancelot viene, con la contraseña 'Guinevere'”. La autenticación es doble, estableciendo confianza con identidad y un código secreto.

La autenticación es una capa de seguridad básica que se ocupa específicamente de la identidad de la parte solicitante. Piense en la autenticación como un acuerdo basado en la confianza. Cuando Lancelot llega a tu puente levadizo, grita su nombre junto con un código secreto a un guardia estacionado en la muralla del castillo de arriba. Estas dos formas de identificación se asegurará de que Lancelot se identifica sólo como Lancelot, y que Lancelot está permitido entrar en el castillo.

En el mundo real, este nivel de seguridad puede adoptar múltiples formas. Cuando un usuario elige solicitar datos o recursos, puede enfrentarse a una serie de protocolos, sistemas de inicio de sesión y servicios de verificación. Por ejemplo, un usuario puede iniciar sesión utilizando un servicio de autenticación que solo requiere un nombre de usuario y una contraseña. Para mayores niveles de seguridad, se les puede pedir que proporcionen un token de un solo uso generado en un dispositivo móvil o llavero. .

Autorización: Nivel de acceso

La autorización es un nivel de seguridad completamente independiente, aunque a menudo se confunde con la autenticación; mientras que la autenticación verifica que el solicitante es quien dice ser, la autorización determina el nivel de acceso que se le debe otorgar.

Sachsenspiegel

"Aquí dice que tienes el estatus de Mesa Redonda". La autorización considera qué nivel de acceso tiene el usuario al sistema. [Imagen: CC-BY-SA-3.0 a través de Wikimedia Commons]

Mientras Lancelot espera a que baje el puente levadizo y le permita entrar, el guardia da un paso atrás y revisa su "Libro de permisos de Ye Olde" para asegurarse de que Lancelot tiene derecho a entrar en el castillo. Esto es diferente a la autenticación. Mientras que Lancelot demostró que era quien decía ser, la Autorización se asegura de que tenga derecho a entrar en el castillo y, si realmente tiene ese derecho, a qué niveles puede acceder dentro del castillo.

La autorización es extremadamente importante, pero a menudo se pasa por alto. Es muy fácil para los desarrolladores de API asumir que, debido a que necesitan acceso a la API para sus sistemas, establecer los permisos predeterminados del usuario en "SysOp" o un acceso completo equivalente es aceptable. Ésta es una línea de pensamiento errónea. Si bien el desarrollador requiere inherentemente un nivel de acceso más alto que el usuario típico, es posible que un consumidor solo necesite una pequeña parte de las llamadas o funciones al mismo tiempo. . En esa situación, dejar abiertas las operaciones en exceso hace que el sistema sea más vulnerable a los ataques y el acceso no autorizado.

Federación: reutilización de credenciales y difusión de recursos

La seguridad federada es un sistema multipropósito:

  • para los usuarios , los sistemas de seguridad federados permiten el uso de un pequeño conjunto de credenciales con múltiples sistemas, servicios, aplicaciones o sitios web.
  • para los administradores , la seguridad federada permite la separación entre los recursos solicitados por el usuario y los sistemas utilizados para autenticar y otorgar autoridad al usuario .
  • Para las organizaciones , les permite administrar de manera centralizada las relaciones de confianza que tienen entre sí y garantizar, criptográficamente, que esa confianza sea exigible.

Las mismas credenciales de usuario en varios servicios

Con la federación, el usuario tiene la capacidad de utilizar el mismo conjunto de credenciales en varios servicios. Al hacer que la autenticación se lleve a cabo en un solo dominio, otros reinos de seguridad que confían en este dominio principal pueden reutilizar la autenticación y confiar en la autenticidad de la identidad establecida. Esto da como resultado lo que se llama una federación .

Cualquier sistema de esta federación puede aceptar las credenciales del dominio de autenticación. El dominio principal es lo que llamamos un proveedor de identidad (IdP) o una parte afirmante (AP); los otros dominios de seguridad que confían en el IdP para autenticar a los usuarios se denominan Partes de confianza (RP) o Proveedores de servicios (SP). Los datos de autenticación e identidad se pasan entre estas partes mediante tokens. Estos tokens son acuñados por un sistema llamado Security Token Service (STS) o un servicio de federación (el servidor de autorización OAuth y un proveedor de OpenID Connect son ejemplos de un STS y un servicio de federación, respectivamente).

El resultado final es que un STS entrega un token al usuario después de que inicie sesión por primera vez en ese servicio de autenticación. Cuando el usuario solicita acceso a otro dominio, el dominio registra que el usuario ya tiene un token y le otorga acceso sin solicitar otro inicio de sesión.

Presentando Realms

federation_nordic_apis_API_stronghold

Un backend federado almacena recursos en varios sistemas, lo que permite a los usuarios acceder a varios servicios con las mismas credenciales.

El Rey sabe que los caballeros como Lancelot necesitan entrar en su castillo; también sabe que su castillo está situado en una ubicación muy mala, propenso a las redadas. Debido a esto, el Rey ha establecido otro castillo a algunas millas de distancia en una posición más defendible para albergar otros recursos preciosos. Lo hace para garantizar la seguridad entre el castillo principal y el castillo más fortificado que contiene otros valiosos tesoros. Esto agrega una capa de seguridad completamente separada, que actúa como un "búfer". La federación permite el inicio de sesión único (SSO) en estos diferentes "dominios de seguridad" o "reinos".

En los sistemas tradicionales que no usan Federación, el usuario iniciaría sesión en un servidor que se encuentra en un dominio / reino de seguridad en particular. Este dominio incluiría no solo este sistema de autenticación, sino también los recursos reales a los que el usuario intenta acceder. Si bien esto funciona bien en algunos casos, si los protocolos de autenticación y autorización se rompieran o violaran, la barrera entre los recursos y el usuario también se rompería. Esto podría permitir a un atacante tomar el control total del dominio.

Cuando ocurre una infracción

Con la seguridad federada, si se produce una infracción en el proveedor de identidad, las partes que confían pueden revocar la confianza que habían depositado previamente en esa parte; no todos los sistemas están comprometidos . Se rechaza la entrada a todas las solicitudes de autenticación federada realizadas por cualquier usuario al servidor de recursos. Imagina que el rey y sus caballeros se han retirado al castillo fortificado después de que el castillo principal fuera invadido por asaltantes. Ya no permiten la entrada de personas que soliciten acceso al castillo fortificado por temor a que en realidad sean asaltantes que usan palabras clave robadas.

Delegación: El sello del poder (limitado)

La delegación es otro proceso mediante el cual se pueden otorgar acceso y derechos a usuarios autorizados mientras se mantiene una cantidad de acceso relativamente limitada . Mientras que la federación funciona dando al usuario un token para usar en varios dominios, la delegación funciona autorizando a un usuario a funcionar parcialmente como si fuera otro usuario .

La delegación se puede comparar con un sello, que lleva el sello y los permisos de un rey API.

La delegación se puede comparar con un sello, que lleva el sello y los permisos otorgados por un proveedor de API

El Rey Arturo, al ver la difícil situación de Lancelot el Caballero, ha decidido facilitar el acceso futuro a su Reino. Crea un anillo con su sello real engastado en perlas y se lo da a Lancelot. Luego instruye a sus subordinados a seguir las órdenes de Lancelot, dado que están dentro de sus derechos como Caballero y no exceden la autoridad previamente otorgada expresamente por el Rey. De esta manera, cuando Lancelot presenta su sello, se ve que está actuando bajo las órdenes del Rey y no necesita verificarse ni autenticarse.

Para los usuarios de la web, esto se hace sitio por sitio. Por ejemplo, supongamos que el usuario está intentando iniciar sesión en “http://mail.corporate.orgBajo el sistema de federación, primero tendrían que iniciar sesión en una página de portal designada para acceder a cualquier recurso adicional en la federación usando su token. Bajo el sistema de delegación, “http://mail.corporate.org buscaría ver qué derechos se les ha otorgado y en nombre de quién están actuando. Como el usuario proviene de “http://profile.corporate.org y ya ha iniciado sesión en esa página utilizando una cuenta autenticada con privilegios elevados, el servidor de correo permite el acceso.http : // correo corporativo org  . Bajo el sistema de federación, primero tendrían que iniciar sesión en una página de portal designada para acceder a cualquier recurso adicional en la federación usando su token. Bajo el sistema de delegación, “ http : // mail corporativo org  buscaría ver qué derechos se les ha otorgado y en nombre de quién actúan. Como el usuario proviene de “ http : // profile corporativo org  y ya ha iniciado sesión en esa página utilizando una cuenta autenticada con privilegios elevados, el servidor de correo permite el acceso.

Recorrido por la publicación del blog CTA 5-01

Seguridad holística frente a enfoque singular

Lo más importante de todas estas consideraciones es la forma en que tratamos el sistema de seguridad fundamental que estamos implementando. Con demasiada frecuencia, los desarrolladores caen en la trampa de considerar que la seguridad es unilateral . Un usuario medio podría considerar tener tres dispositivos de autenticación como un buen control de seguridad; pero si ese servidor de autenticación se desconectara alguna vez, podría tener una cantidad infinita de sistemas de seguridad basados ​​en autenticación y su red aún estaría expuesta. Al pensar en la seguridad como un enfoque singular en lugar de uno holístico, está poniendo su API y su sistema en mucho más peligro de lo necesario.

Considere la seguridad de las limitaciones de nuestra historia sobre Lancelot, y póngase en los zapatos cómodos y sedosos del noble y sabio Rey Arturo. Sabes que vienen invasores; de hecho, ahora los puedes ver cruzando la montaña, preparándose para invadir. Examine su seguridad y realmente contemple toda su API Stronghold .

¿Consolidarías todas tus joyas y oro en una fortaleza y defenderías con todos los hombres en una sola puerta de madera? - O - ¿Preferirías distribuir tu riqueza en múltiples fortalezas, cada una con un foso infranqueable, una puerta de madera tripulada, una puerta de metal tripulada y guerreros armados esperando un poco más allá? Operacionalmente, los costos pueden ser los mismos, pero la seguridad es drásticamente diferente. En el primer escenario, el enemigo solo tendría que destruir la puerta de madera una vez para entrar a tu castillo, mientras que en el segundo escenario, tendrían que pasar cuatro obstáculos separados y desalentadores para incluso echar un vistazo a una única fortaleza interior. Una fortaleza de múltiples capas es cómo debe considerar la seguridad en el espacio de la API.

Aplicación para API

Al establecer un sistema de seguridad para su API, comprender la autenticación , la autorización , la federación y la delegación es de vital importancia. Decidir el acceso y las circunstancias específicas detrás de compartir sus recursos ayudará a establecer un escudo de seguridad para proteger los activos internos y resolver muchos problemas de seguridad antes de que surjan.

Para el administrador de sistemas moderno, existe una amplia gama de herramientas y servicios disponibles que hacen que la implementación de cualquiera de estos tipos de seguridad sea relativamente sencilla. Los servicios como OAuth y OpenID Connect se pueden integrar al principio del ciclo de desarrollo de la API, y los servicios de autenticación de terceros incluso se pueden implementar después de implementar la API.

Si bien todos los sistemas anteriores pueden funcionar en conjunto entre sí, saber cuándo y dónde se aplica mejor cada uno lo convierte en un mejor sistema en general, mejorando su seguridad, usabilidad y longevidad.

Publicar un comentario

0 Comentarios