Seguridad en la estrategia de APIs.

Las API exponen datos, servicios y transacciones, creando activos para compartir y reutilizar. La ventaja es la capacidad de aprovechar la energía creativa de los constituyentes internos y externos para crear nuevos productos y ofertas.

El inconveniente es la expansión de canales críticos que necesitan ser protegidos, canales que pueden proporcionar acceso directo a IP sensible que de otro modo no podría estar en riesgo. Las consideraciones de riesgo cibernético deben estar en el corazón de la integración y las estrategias API.

Una API creada teniendo en cuenta la seguridad puede ser una piedra angular más sólida de todas las aplicaciones que habilita; hecho mal, puede multiplicar los riesgos de la aplicación.

El alcance del control: a quién se le permite acceder a una API, qué se les permite hacer con ella y cómo se les permite hacerlo, es una preocupación importante. En el nivel más alto, la gestión de esta preocupación se traduce en la autenticación de nivel de API y la gestión de acceso, controlando quién puede ver, administrar y llamar a los servicios subyacentes.

Las preocupaciones más tácticas se centran en el protocolo, la estructura del mensaje y la carga útil subyacente, protegiendo contra solicitudes aparentemente válidas de código malicioso inyectado en sistemas centrales subyacentes. El enrutamiento, la regulación y el equilibrio de carga también tienen consideraciones cibernéticas: las denegaciones de servicio (donde un servidor está inundado de solicitudes vacías para invalidar su capacidad de realizar operaciones normales) puede dirigirse a las API tan fácilmente como pueden dirigirse a sitios web.

Al igual que la infraestructura y el tráfico de red se pueden monitorear para comprender las operaciones normales, las herramientas de administración de API se pueden usar para establecer una línea de base de las llamadas de servicio típicas. El monitoreo de eventos del sistema debe extenderse a la capa API, permitiendo que las llamadas de interfaz inesperadas se marquen para su investigación. Dependiendo de la naturaleza de las transacciones y los datos comerciales subyacentes, es posible que las respuestas deban prepararse en caso de que las API subyacentes se vean comprometidas, por ejemplo, trasladar el procesamiento de pedidos en línea de un minorista a sistemas de respaldo locales.

Otra implicación de la economía de la API es que las vulnerabilidades no descubiertas pueden estar expuestas a través de la capa de servicios. Algunas organizaciones tienen protocolos de seguridad en niveles que requieren diferentes niveles de certificación según los patrones de uso del sistema. Es posible que una aplicación desarrollada para operaciones internas, fuera de línea o de back-office no haya pasado las mismas inspecciones rigurosas por las que se someten las soluciones de comercio electrónico orientadas al público. Si esos sistemas de back-office se exponen a través de las API en la parte delantera, las puertas traseras y los patrones de diseño explotables pueden quedar expuestos inadvertidamente. De manera similar, los datos privados de clientes, productos o mercados podrían compartirse involuntariamente, lo que podría infringir las regulaciones del país o de la industria.

Plantear preguntas importantes: ¿Se puede proteger lo que se está abriendo? ¿Puedes confiar en lo que viene? ¿Puedes controlar lo que está saliendo? Los puntos de integración pueden convertirse en las joyas de la corona de una empresa, especialmente a medida que la economía de la API despega y lo digital se vuelve central para más modelos de negocios. Compartir activos probablemente forzará las respuestas cibernéticas basadas en la expectativa de un mundo limitado y restringido. Es probable que se necesiten nuevos controles y herramientas para proteger los posibles casos de uso ilimitados al tiempo que se proporciona una efectividad de extremo a extremo, de acuerdo con lo que pueden ser compromisos formales en los acuerdos contractuales de nivel de servicio. Los problemas técnicos son complejos pero solucionables, siempre que el riesgo cibernético sea una consideración fundamental cuando se inicien los esfuerzos de API.