Cómo administrar la seguridad de la API


Proteger los lugares donde se encuentran los servicios de aplicaciones es elementary para proteger la TI empresarial. Esto es lo que los profesionales de seguridad necesitan saber sobre «el pegamento invisible» que hace que las aplicaciones se comuniquen entre sí.

(Imagen: alice_photo / Adobe Stock)

«Hay una grieta en todo / Así es como entra la luz «- Himno, Leonard Cohen

Cuando se trata de aplicaciones empresariales, las grietas ciertamente están ahí, pero no es claro encontrar el camino a través de las brechas: son los delincuentes y sus asistentes de malware. Algunas de las grietas empresariales aparecen a través de vulnerabilidades en el código de la aplicación o el firmware, pero existen cientos, si no miles, de posibles grietas en los lugares donde las aplicaciones y funciones se unen en una aplicación basic, es decir, API.

Las interfaces de programación de aplicaciones (API, por sus siglas en inglés) son las formas formales y regularmente establecidas en que las aplicaciones se comunican entre sí. Esto significa que hay al menos una API para cada componente en una aplicación.

Más de la mitad de las API utilizadas en aplicaciones empresariales se desarrollan internamente, de acuerdo con el «Informe del estado del cartero 2019 del API, «para los cuales se encuestó a más de 10,000 desarrolladores. Otro 28% de las API provienen de organizaciones asociadas, mientras que aproximadamente el 19% están disponibles públicamente.

«Si piensa en alguna infraestructura hoy en día en las aplicaciones empresariales y los componentes que la soportan, generalmente hay un componente móvil, un componente de sitio world-wide-web y una miríada de bases de datos y servicios que las soportan, y todo esto sucede con las API», dice Mehul Revankar, director de gestión de productos en SaltStack. «Y, por lo tanto, la API es de alguna manera el pegamento invisible que mantiene todas estas cosas trabajando juntas sin problemas».

Interfaz crítica
Debido a que las API son tan críticas para el marco de aplicación moderno, son objetivos tentadores para los delincuentes. Y los trabajos de los delincuentes se hacen más fáciles debido a la falta de comprensión que muchos líderes de TI tienen sobre cuántas API funcionan en su infraestructura.

Parte del problema, dicen los expertos, es la naturaleza de las aplicaciones modernas. Lo que antes eran aplicaciones monolíticas que podían hacer llamadas a una capa de foundation de datos y presentación ahora son capas anidadas de microservicios y componentes sin servidor.

«¿Qué significa desde una perspectiva API? Lo que solía ser una llamada de función dentro de la aplicación en el pasado ahora es una llamada API», dice Shreyans Mehta, cofundador de Cequence y CTO. El desafío de seguridad es asegurarse de que las API permitan que solo las aplicaciones y usuarios autorizados pasen datos de una parte de una aplicación a otra.

El cambio al modelo de aplicación moderno está impulsado por la velocidad de los negocios modernos, con socios, clientes y necesidades comerciales internas que impulsan el requisito de velocidad, dice Kin Lane, evangelista jefe de Postman. Como resultado, «la gente simplemente no prioriza la catalogación y definición de cuáles son estas capacidades (API)», dice.

Tomarse el tiempo para catalogar las API y comprender cuántas API están realmente en el inventario de la organización, entonces, es el primer paso para asegurar las API. Pero una vez que sabes lo que hay que defender, ¿cómo puedes hacer eso mejor?

La buena noticia, según Lane, es que muchas de las API en uso por las empresas compartirán una foundation común. «La mayoría de las API son más un Rest de clase común o una API web», dice. «Esos tienen muchas características comunes: es bastante sencillo entender cómo asegurarlos».

Protege el RESTO
Con las API descubiertas y catalogadas, y la protección para el tipo RESTful bien entendida, ¿cómo deberían las organizaciones proceder a proteger el resto de las API en la arquitectura? Algunos hacen el caso para comenzar con lo básico.

Laurence Pitt, director de estrategia de seguridad international de Juniper Networks, dice que el cifrado es un buen punto de partida.

«Existen muchos métodos diferentes cuando se considera cómo bloquear una API, pero no tiene que ser demasiado complicada», explica. «En la mayoría de los casos, sería suficiente asegurarse de que la API esté utilizando HTTPS para la comunicación para garantizar que el tráfico no pueda ser rastreado fácilmente desde la crimson, y luego usar alguna forma de autenticación para permitir el acceso».

Si bien no es perfecto, ese método evitará que los piratas informáticos que utilizan herramientas de rastreo de Net encuentren API abiertas y controlen el tráfico, agrega Pitt.

El siguiente paso de seguridad podría implicar seguir un marco de seguridad para proteger las API. Afortunadamente, hay un par de marcos disponibles que múltiples expertos recomiendan como parte de un impulso hacia las mejores prácticas.

Mehta señala el Open World wide web Software Safety Task (OWASP) y su Proyecto de seguridad API como recurso, aunque ofrece una advertencia: «No creo que esté en un estado tan maduro en este momento hay más trabajo por hacer», dice. «Podría ser un buen comienzo, pero ahora le faltan muchas piezas».

A finales de septiembre se publicó un candidato de lanzamiento para el OWASP API Protection Major 10. En otras palabras, el proyecto API Security es literalmente un trabajo en progreso. Aun así, presenta 10 áreas que preocupan a los equipos de seguridad cuando se trata de API. Esas áreas van desde la autorización de nivel de objeto roto y la exposición excesiva de datos a registros y monitoreo insuficientes.

Más allá de OWASP
Si bien el marco OWASP aún se encuentra en el proceso de publicación y finalización, el Instituto Nacional de Ciencia y Tecnología (NIST) ha estado trabajando en marcos de seguridad de aplicaciones world wide web durante algún tiempo. NIST Publicación especial 800-95 fue publicado en 2007 y aún es considerado uno de los documentos fundamentales de seguridad world wide web por muchos profesionales. Y el NIST no ha detenido el proceso de desarrollo del marco

Una versión borrador de NIST Publicación especial 800-204, que cubre estrategias de seguridad para aplicaciones basadas en microservicios, se publicó en marzo con un período de comentarios que se extendió hasta abril. La versión closing de SP 800-204 fue publicado en agosto. Si bien es importante, Kiersten Todt, director gerente del Instituto de Preparación Cibernética, dice que el marco NIST, o cualquier otro, se usa es más crítico de lo que contiene.

«No se puede adoptar el marco», comienza ella. «El marco en sí tiene 98 controles. Algunas compañías podrán usar todos los 98. Muchos de ellos no. Así que mi punto es que todas estas herramientas deben usarse como pautas, pero nunca como destinos».

Aplicación reflexiva
Cuando se consideran como directrices, los marcos OWASP y NIST pueden estar sujetos a una revisión constante. «Como empresa, usted debe evaluar y reevaluar constantemente su misión, su entorno de amenazas, sus prioridades, etc.», explica Todt. «Y de nuevo, estos son lugares para comenzar, pero deben ser personalizados y deben ser evaluados constantemente».

En cuanto a los marcos y la tecnología que usan las organizaciones para implementar sus controles, Postman&#39s Lane dice que la perspectiva es crítica. «Tenga cuidado con lo que sigue: el próximo objeto brillante para distraerlo del trabajo duro», dice. «No permita que lo distraiga del arduo trabajo de identificar cuáles son sus API y de seguir la guía de pérdidas de manera consistente en todos sus equipos».

Al remaining, «Solo sé pragmático y reflexivo», agrega Lane.

Contenido relacionado:

Curtis Franklin Jr. es editor sénior en Dim Examining. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y video clip para Darkish Looking at y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Más tips





Enlace a la noticia original