Header Ads Widget

Ticker

6/recent/ticker-posts

9 preguntas para la auditoría de seguridad de API de nivel superior


 Una de las cosas más importantes que cualquier desarrollador de API puede darse cuenta es el hecho de que, como manejador de datos, tiene algunos de los requisitos legales y morales más importantes hacia sus sujetos de datos de cualquier organización con orientación técnica.

El hecho de que los consumidores confíen sus datos a los desarrolladores se basa en la idea de que estos datos estarán protegidos , que la API en sí se reforzará contra ataques y que el proveedor de API está haciendo todo lo que está a su alcance para protegerse continuamente contra posibles ataques. amenazas. Con esto en mente, la idea de auditar la seguridad de la API es extremadamente importante.

Hoy vamos a hacer exactamente eso. Discutiremos 9 preguntas que todo proveedor de API debería hacerse cuando se trata de seguridad . Si bien esta es una guía potencial para la auditoría de seguridad de API de alto nivel, esperamos que sea un punto de partida hacia preguntas más específicas a lo largo del ciclo de vida de la API.

Los beneficios de una auditoría de seguridad de API

En pocas palabras, la seguridad no es una propuesta de establecer y olvidar. Las amenazas están en constante evolución y, en consecuencia, también debería hacerlo su seguridad. Atrás quedaron los días en los que se producían picos masivos en el desarrollo tecnológico a lo largo de meses. La era moderna ve avances en el descifrado y nuevos métodos de penetración de la red en cuestión de semanas (o días) después de una nueva versión de software.

Por supuesto, existen sistemas sólidos para implementar que pueden anular muchas de estas amenazas. Seguir algunas " mejores prácticas " básicas para la seguridad puede anular la mayor parte de las vulnerabilidades y, como tal, estas mejores prácticas deben verse como una primera línea de defensa.

La auditoría puede ayudar a exponer puntos finales derrochadores , funciones duplicadas y llamadas que fallan constantemente y más, lo que si se reduce hace que el código base sea más mantenido y más seguro. Esto también tiene el efecto adicional de producir una documentación más clara y, llevado a su conclusión lógica, puede hacer que la gestión de versiones y la iteración sean mucho más fáciles y efectivas.

En otras palabras, una auditoría de seguridad no es solo una buena idea en términos de proteger su API, también es una buena idea para asegurar la salud de su programa API .

9 preguntas para auditar la seguridad de la API

Una forma de auditar una API es separar nuestras preguntas en tres categorías generales de acuerdo con el tipo de consumidor que interactuará con el sistema. Podemos separar ampliamente a estos consumidores en funciones básicas, generando Preguntas comerciales , Preguntas sobre tecnología y Preguntas sobre relaciones con el usuario .

Preguntas comerciales

Cuando hablamos de consideraciones comerciales , lo que realmente estamos viendo es la forma fundamental en que las competencias comerciales centrales impulsan el diseño y la función de la API. En otras palabras, estamos viendo cómo la API respalda el negocio en sí y, por lo tanto, identificamos las diversas preocupaciones de seguridad fundamentales para la funcionalidad empresarial. Esto incluye cómo  se recopila la información , cómo se retienen los datos y varios otros aspectos relacionados con los socios y las políticas internas .

1 - ¿Qué datos recopilamos y por qué?

Identificar por qué la empresa recopila los datos que lo hace es un gran primer paso para garantizar el cumplimiento de la seguridad. El RGPD y otras leyes relacionadas han puesto la privacidad de los datos en un primer plano en la mente del consumidor, pero estos problemas vienen desde hace tiempo. El simple hecho es que las empresas, y por lo tanto sus API, pueden recopilar datos en exceso con mucha facilidad Puede parecer una forma fácil de hacer las cosas, pero puede crear problemas mucho más grandes de lo que ofrece en términos de valor.

Comprender las nuevas leyes de protección de datos de la UE

El mayor impacto aquí es el hecho de que con una mayor cantidad de datos recopilados, la canalización de datos pierde eficacia y puede potencialmente traicionar las expectativas de privacidad del usuario . Esto, en conjunto, hace que la API sea un objetivo más grande y, por lo tanto, disminuye la seguridad general. Una API debería hacer mucho y exponer poco; en otras palabras, debería proporcionar una funcionalidad excelente sin exponer exactamente cuán poderosa es.

Si su API expone cantidades masivas de datos, a partir de un análisis de costo / beneficio puro, usted será un objetivo . Además, si sufre una infracción, especialmente si funciona en cualquier capacidad con datos de la UE o está sujeto a las leyes de protección de datos de la UE , sus posibilidades punitivas son extremas.

Mire su API y reduzca la recopilación de datos a solo lo necesario. Obtenga el consentimiento explícito del usuario para esa recopilación: una opción de "exclusión voluntaria" ya no es efectiva y, en muchos casos, no garantiza el cumplimiento de GDPR. Ofusque los datos cuando sea apropiado, especialmente en los puntos finales. Sobre todo, minimice su superficie de ataque de la forma más drástica posible y, al mismo tiempo, permita las funcionalidades comerciales básicas necesarias.

2 - ¿Tenemos políticas de seguridad interna?

La desafortunada realidad de la exposición de datos es que la mayoría de las amenazas no provienen de fuentes externas, sino de amenazas internas , políticas de seguridad deficientes, capacitación inadecuada y simple mala conducta. Incluso si la amenaza no es consciente o intencionada, el simple error humano puede ser mucho más dañino que cualquier ataque externo debido a la naturaleza del acceso interno a los recursos.

Afortunadamente, esta área de amenaza se puede mitigar quizás de manera más efectiva que cualquier otra área en este proceso de auditoría. Las políticas de seguridad interna son establecidas por miembros internos y, como tales, pueden adaptarse a sus organizaciones específicas, sus excentricidades y sus debilidades generales.

El endurecimiento de los procesos contra la ingeniería social, por ejemplo, puede ser relativamente simple si se bloquea el acceso a los sistemas hasta que el cliente proporciona una identificación de dos factores , eliminando así la inseguridad inherente de las preguntas secretas.

El robo de IP se puede prevenir separando los sistemas y asegurando que los clientes accedan al contenido a través de una API en un servidor seguro  y que su tráfico se enrute independientemente de otras fuentes de tráfico menos seguras.

Algo tan simple como garantizar una distribución adecuada de responsabilidades y poderes entre sus empleados puede contribuir en gran medida a garantizar la seguridad de este tipo y mitigar las amenazas más comunes.

Sobre la creación de políticas internas: fomento de una cultura interna de seguridad

3 - ¿Confiamos en nuestros socios?

Las amenazas internas son una preocupación seria, pero el término en sí es algo engañoso. Cuando hablamos de personas con información privilegiada, no solo estamos hablando de trabajadores individuales y aquellos con acceso a nivel de código; de lo que realmente estamos hablando es de la amenaza de personas con acceso interno elevado de cualquier tipo. Desafortunadamente, eso incluye socios que tienen un acceso elevado para funciones de empresa a empresa .

Cuando comparte datos de su API con otros terceros , confía no solo en que ellos protejan los datos que han obtenido de usted, sino en que su propia seguridad es lo suficientemente estricta como para proteger sus propios datos y su propia API. Debido a la naturaleza de una aplicación de empresa a empresa, este tipo de integraciones tienden a formar cadenas simbióticas entre los socios API, lo que significa que lo que afecta a un socio probablemente afectará al otro.

En otras palabras, si el sistema de un socio se ve comprometido, existe la amenaza seria y real de que los puntos finales que no están destinados a estar expuestos a su vez estén expuestos, transfiriendo así gran parte del impacto de un punto externo de falla a sus sistemas internos. .

En consecuencia, cualquier revisión de seguridad empresarial debe tener en cuenta una auditoría de socios externos , sus diversas políticas y los sistemas en los que integran su flujo de datos. Si no tiene un SLA o un acuerdo de nivel de servicio con ese socio, o no son 100% confiables y verificados, no es un socio al que deba brindar un mayor acceso.

Estudio de caso de seguridad de API para socios: Cambridge Analytica y Facebook

Preguntas sobre tecnología

Las preocupaciones tecnológicas van más allá de estas cuestiones comerciales y, en cambio, miran las implementaciones tecnológicas de las competencias comerciales centrales y sus funciones relacionadas. A menudo, este es el enfoque de la mayoría de las auditorías e implementaciones de seguridad, y aunque este es un aspecto extremadamente importante de este proceso de auditoría, es solo una parte del panorama general.

4 - ¿Están nuestros datos cifrados durante el tránsito? ¿Qué pasa con los datos en reposo?

El cifrado es una gran parte de la seguridad de la API, tanto en términos de datos en tránsito como de datos en reposo. Aunque el cifrado evoluciona de manera aleatoria, a menudo se descubren fallas importantes con los métodos más antiguos, por lo que ceñirse a una única solución con impetuidad no es un enfoque sostenible . Desafortunadamente, esto parece perdido para algunos proveedores de datos, ya que muchos de los problemas de seguridad más recientes han tenido una seguridad de datos laxa en su núcleo.

Es extremadamente importante abordar sus métodos de cifrado y asegurarse de que sean adecuados y seguros. Mientras que el cifrado en reposo es obviamente importante, también es igualmente importante garantizar el cifrado en tránsito . La cantidad de datos enviados a través de HTTP es una locura cuando se considera que HTTPS es mucho más seguro y muy fácil de configurar. No es una solución perfecta, claro, pero es una solución mejor que enviar por correo, y cuando se combina con otro cifrado avanzado, se convierte en una canalización segura para el tránsito de datos.

5 - ¿Nos estamos sobreexponiendo? ¿Estamos inclinando nuestra mano?

Se puede encontrar una gran exposición técnica en la simple práctica de exponer demasiado a demasiados en la API propiamente dicha. Cosas simples como no calificar adecuadamente los puntos finales limitantes , exponer demasiada información en las consultas o incluso documentar los puntos finales internos en documentación externa pueden ayudarlo y exponer mucho más sobre la API de lo que se esperaba o deseaba.

Para obtener más información, lea: Puntos de seguridad a considerar antes de implementar GraphQL

Como ejemplo de este tipo de sobreexposición, podemos mirar algo como GraphQL . Dado que GraphQL permite a los usuarios indicar qué datos quieren y en qué formato general, es concebible que, sin limitación de velocidad, un usuario externo infame pueda usar múltiples llamadas a API en diferentes formatos desde diferentes puntos finales para mapear efectivamente la totalidad del enrutamiento interno de API , exponiendo así la estructura de la propia API y comenzando a exponer las vulnerabilidades que podrían ser atacadas.

En esencia, esto es similar al escaneo de puertos y, como cualquier administrador de red decente puede decirle, limitar el acceso y bloquear los sistemas es un método proactivo y muy poderoso para proteger su API.

6 - ¿Tenemos lagunas o vulnerabilidades?

Si bien esto puede parecer tan simple como para no justificar su inclusión, la búsqueda de brechas y vulnerabilidades es un paso muy importante en la auditoría; desafortunadamente, a menudo se ve como el único paso y, como tal, se considera mejor como parte de un proceso en lugar de como una única solución. Mire su base de código tanto en reposo como en acción, y busque específicamente brechas y vulnerabilidades que surjan de la interacción común.

Estos a menudo se pasan por alto o se ignoran, especialmente cuando las vulnerabilidades parecen pequeñas. La realidad es que una sola brecha pequeña puede extenderse en cascada a través de múltiples puntos finales y productos, lo que resulta en un sistema mucho menos seguro y una propagación de la debilidad en la totalidad del sistema.

Una gran vulnerabilidad, a menudo asociada con las bases de datos en línea, es el uso de configuraciones y valores de configuración predeterminados . Si bien puede parecer fácil simplemente hacer clic en un botón y configurar un servidor predeterminado, en algunos casos, esto puede dejar los datos sin cifrar, fácilmente capturados y enviados sin cifrar. De hecho, muchas de las violaciones de datos de más alto perfil de los últimos diez años se han producido simplemente porque las bases de datos en cuestión o los servicios que las aseguraban tenían poco o ningún cifrado y utilizaban credenciales de seguridad predeterminadas.

Preguntas sobre relaciones con el usuario

Para terminar esta imagen, también necesitamos mirar las relaciones con los usuarios . Si bien técnicamente estamos mirando menos la política de seguridad interna de la API y, en cambio, nos centramos en las acciones de seguridad de aquellos que utilizan la API en sí, las implicaciones de su uso sugerirían que cualquier falla de seguridad no se debe necesariamente a sus acciones únicamente, pero en cambio debido a que la API incluso permite que esas acciones ocurran en primer lugar. En consecuencia, identificar los agujeros de seguridad facilitadores que permiten a los usuarios romper el sistema contribuirá en gran medida a rectificar cualquier problema potencial en el futuro.

7 - ¿Estamos investigando a nuestros clientes?

La mayoría de los clientes tienen buenas intenciones. El cliente solo quiere usar su API, a menudo para fines comerciales legítimos, bien informados y legales. Desafortunadamente, no puede confiar en todos los usuarios porque “la mayoría” hace lo correcto, especialmente cuando algunos de sus usuarios quieren usar la API para cantidades masivas de procesamiento de datos.

Una política de desarrollador legible por humanos es el primer paso para hacer cumplir los términos de servicio de la API.

Como tal, examinar su base de clientes es un tema enormemente importante para cualquier API segura. Asegúrese de que los clientes estén utilizando su acceso a los datos por las razones adecuadas y, lo que es más importante, establezca una forma de realizar un seguimiento del uso de referencia y asegúrese de que cualquier desviación se aborde y gestione correctamente.

Un ejemplo de este tipo de amenaza sería el mal uso masivo de datos de Cambridge Analytica . La organización extrajo información de una aplicación que se publicó en Facebook con "fines académicos" y utilizó esos datos para una multitud de usos diferentes, todo ello en violación de los términos de los servicios de Facebook.

Otro gran método para lidiar con estas preocupaciones es otorgar a los nuevos clientes cuentas iniciales con tarifas limitadas hasta que hayan demostrado que sus propósitos son legítimos y su uso permitido. Otro método consiste en atar en otras redes federadas con userbases de confianza, lo que permite la confianza que se establezca por confiar en su historia en otras redes.

Independientemente de cómo se asegure de que su cliente sea de confianza, esto es de suma importancia para una API segura. La mayoría de los ataques se originarán desde adentro, no desde forasteros al azar.

8 - ¿Tenemos una interfaz segura?

Dependiendo del método por el cual un usuario accede a la API y sus servicios, la inseguridad puede surgir no de la API, sino de la interfaz que se vincula con ella. Un frente web que utilice Flash o Silverlight podría, si esos complementos utilizan compilaciones más antiguas, exponer vulnerabilidades para la inyección de scripts u otros tipos de uso de código malicioso. Incluso algo como un widget de anunciante que muestra un anuncio en una página de inicio de sesión podría, en teoría, usarse para capturar datos sobre el navegador y la cadena del agente de usuario y, en algunos casos maliciosos , puede usar secuencias de comandos para capturar credenciales mediante capturas de sesión.

Considere cómo funciona la interfaz. ¿La API protege las claves correctamente en tránsito? ¿Se utiliza la clave para la autenticación total o simplemente como parte del proceso? Idealmente, una clave debería iniciar el proceso de identificación , pero no solo probar la propiedad, limitando así el daño. ¿Se limita la escalada de derechos de usuario o existe un sistema automático dado su nivel de suscripción? Estos sistemas pueden romperse y los usuarios a veces pueden escalar maliciosamente sus propios privilegios.

Todo esto a menudo se pasa por alto, pero vale la pena discutirlo: una interfaz es como la puerta de entrada, y tan importante como consideramos cerrar la puerta de entrada cuando salimos de la casa, ¡deberíamos tratar nuestras interfaces con amplia seguridad!

9 - ¿Es eficaz su asistencia al usuario?

La forma en que una API apoya a sus usuarios puede tener un efecto dramático en la seguridad. A menudo, la seguridad puede romperse involuntariamente, cuando los usuarios utilizan un sistema de formas que los diseñadores nunca planearon. Una amplia detección de esto, así como la documentación sobre cómo se debe utilizar correctamente un sistema , pueden contribuir en gran medida a mitigar estos problemas de los usuarios incluso antes de que aparezcan.

Además, los sistemas de apoyo al consumidor se pueden aprovechar como un método para informar e identificar estos problemas antes de que sean más grandes de lo que ya son. Los correos electrónicos de informes simples, un chat de soporte en vivo o incluso un programa de recompensas de búsqueda de errores pueden ser de gran ayuda para garantizar que los usuarios informen los problemas cuando los descubren, lo que tiene un efecto de fortalecimiento general en su API.

Ser proactivo en este ámbito es sumamente importante. Después de todo, si sus usuarios pueden encontrar y explotar estos problemas, a veces incluso accidentalmente, puede estar seguro de que los atacantes también pueden hacerlo; la única diferencia es que los atacantes no serán lo suficientemente amables como para notificarlo sobre la exposición, alertándolo. hay un problema en absoluto.

Conclusión

auditoría de seguridad api

Dirígete a nuestra página de API Security Insights para obtener más información sobre cómo proteger las API.

La seguridad es una parte extremadamente seria e importante de cualquier API y, como tal, se le debe dar la importancia y el peso que merece. Estas 9 preguntas básicas pueden mejorar la seguridad de la auditoría y, francamente, no son tan difíciles de abordar; adoptarlas como un estado de ánimo no solo da como resultado una mayor cantidad de seguridad de inmediato, sino que tiene un efecto compuesto cuando se usa como una estructura para un desarrollo seguro.

Teniendo en cuenta las posibles multas, sin mencionar la pérdida de confianza y comercio que puede resultar de estar expuesto o tener una API utilizada para propósitos nefastos, los beneficios de adoptar estas preguntas y pensar detenidamente en la seguridad en el futuro son inmediatos y se agravan con el tiempo, entregando un ecosistema de API más seguro, sólido y confiable.

Publicar un comentario

0 Comentarios