REPORTE OFICIAL | septiembre de 2014

Protección de las API contra ataques y robos Proteja las aplicaciones de su empresa para dispositivos móviles, la nube y la Web abierta.

2 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Tabla de contenido Resumen 

3

Sección 1: 

4

Nueva tecnología, viejas amenazas Sección 2: 8 Orientación para la mitigación Sección 3: 10 Obtención de un control total sobre la seguridad de las API Sección 4:11 Conclusiones

3 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Resumen Desafío La interfaz de programación de aplicaciones (API) es una tecnología emergente para la integración de aplicaciones mediante tecnología web. Este enfoque está creciendo en popularidad, debido a que se basa en técnicas bien comprendidas y aprovecha algunas infraestructuras existentes. Sin embargo, es un error pensar que podemos proteger las API con los mismos métodos y las mismas tecnologías que usamos para proteger la Web convencional centrada en el navegador. Las API son diferentes fundamentalmente de los sitios web y tienen un perfil de riesgo totalmente único que debe abordarse.

Oportunidad La mejor práctica para la arquitectura de seguridad de API es separar la implementación de API y la seguridad de API en distintos niveles. Según este modelo, un desarrollador de API puede centrarse completamente en el dominio de una aplicación, garantizando que cada API esté bien diseñada y promueva la integración entre diferentes aplicaciones. CA API Gateway proporciona al administrador de seguridad de API un control total sobre el control de acceso, la detección de amenazas, la confidencialidad, la integridad y la auditoría en cada API que publica la organización.

Beneficios CA API Gateway (anteriormente CA Layer 7 API Gateway) tiene un modelo de seguridad basado en políticas que se adapta fácilmente a los diferentes requisitos de seguridad para cada API. Ofrece políticas centrales que se pueden compartir con facilidad en conjuntos de API para crear una instancia de seguridad básica consistente, además de la capacidad de especializarse en una API por vez para cumplir con las necesidades específicas de una aplicación determinada. También se integra fácilmente con los sistemas de identidades existentes (LDAP, IAM, etc.) y sistemas de monitoreo operativos.

4 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Sección 1

Nueva tecnología, viejas amenazas Las API pueden representar una tecnología relativamente nueva, pero son susceptibles a muchos de los mismos riesgos que invadieron la computación desde los comienzos de Internet. La inyección de SQL, por ejemplo, tiene sus orígenes en el comienzo de la programación de cliente/servidor. Se espera que, a esta altura, los desarrolladores estén bien familiarizados con las medidas correctivas para lidiar con un ataque desarrollado de dicha magnitud. Pero la inyección de SQL migró fácilmente en aplicaciones web y está ahora resurgiendo a medida que más organizaciones publican API de Internet y vinculadas directamente a las infraestructuras de aplicaciones. Las API son ventanas a las aplicaciones y, como con cualquier ventana, una API puede utilizarse fácilmente de forma incorrecta. Las API bien diseñadas tiene la cualidad de autodescripción. Un buen desarrollador debe poder intuir cómo utilizar una API simplemente inspeccionando su URL, los parámetros de entrada y cualquier contenido devuelto. Sin embargo, esta misma claridad a menudo expone la implementación subyacente de una aplicación (detalles que, de lo contrario, quedarían ocultos por capas de funcionalidades de aplicaciones web). La transparencia que una API proporciona en una estructura interna de una aplicación a menudo ofrece a piratas informáticos pistas peligrosas que pueden llevar a vectores de ataque que quizá, de otro modo, puedan pasar por alto. Las API no solo colocan las aplicaciones bajo el microscopio del pirata informático, sino que también generan una mayor posibilidad de que haya un control corrupto al aumentar la superficie de ataque en las aplicaciones cliente. Las API ofrecen a los desarrolladores del lado del cliente, tanto desarrolladores legítimos como posibles crackers de sistemas, un acceso mucho más detallado a una aplicación que una aplicación web típica. Esto se debe a que el límite de especificidad para las llamadas a niveles de back-end se mueve de niveles internos relativamente seguros (aquellos que residen seguros en una DMZ) hasta la aplicación cliente que reside en Internet. Esto se muestra en la ilustración A. Una aplicación web típica consolida operaciones detalladas, como llamadas a un nivel de datos, detrás de simples páginas web. En la Web tradicional orientada a HTML, las interacciones se limitaban a interacciones básicas. Esto redujo el rango de posibles interacciones y, al hacerlo, redujo la exposición general, particularmente si la aplicación depuraba sus entradas de manera adecuada. Por su parte, las API mueven este límite de especificidad a la aplicación cliente en sí. Esto ofrece a un pirata informático considerablemente más lugares para explotar. En lugar de tener una sola forma simple funcionando como proxy para muchas llamadas internas a recursos de back-end, una aplicación impulsada por API puede realizar todas estas llamadas de manera individual y cualquiera de estas puede exponer vulnerabilidades. Este crecimiento en la superficie de ataque incrementa el riesgo que una organización debe administrar a medida que publica las API en la gran Internet.

5 | Reporte oficial: Protección de las API contra ataques y robos

Ilustración A: Las API trasladan el límite de especificidad de la función al cliente, lo que proporciona al pirata informático una superficie de ataque mucho más amplia con la que puede trabajar.

Las API aumentan la superficie de ataque Cliente web

Aplicación

Servidor HTTP

Límite de especificidad

Servidor HTTP

ca.com/ar

Límite de especificidad Servidor de aplicaciones

Servidor de aplicaciones

Base de datos

Base de datos

Tres categorías de riesgos amplias Es fácil desalentarse por el rango de posibles ataques contra las API. Dado que cada API es única, cada instancia conlleva un riesgo único según su implementación subyacente. Esto parece convertir la seguridad de las API en una tarea imposible. Afortunadamente, la mayoría de los ataques individuales contra las API caen en una de tres amplias categorías: 1. Los ataques a parámetros aprovechan los datos enviados en una API, incluidos las URL, los parámetros de consulta, los encabezados HTTP y el contenido de publicación. 2. Los ataques a la identidad aprovechan fallas en la autenticación, la autorización y el seguimiento de la sesión. En particular, muchos de estos ataques generan la migración de malas prácticas de la Web al desarrollo de API. 3. Los ataques de intermediarios interceptan transacciones legítimas y explotan datos no firmados o no cifrados. Pueden revelar información confidencial (como datos personales), alterar una transacción en vuelo o incluso reproducir transacciones legítimas. Una vez que comprendemos estas amplias categorías, podemos comenzar a diseñar una estrategia de migración eficaz contra los ataques a las API. Una estrategia de seguridad de API eficaz debe proteger incluso contra vectores de ataque futuros no previstos. Cada una de las tres categorías de ataque se describe en detalle a continuación. Riesgos de parámetros El ataque de parámetros clásico, como ya se observó, es la inyección de SQL. Los parámetros diseñados para cargar entradas legítimas en una consulta a la base de datos pueden, a menudo, ser manipulados para cambiar radicalmente el objetivo de una plantilla SQL subyacente. La inserción de script aprovecha los sistemas que finalmente interpretan el contenido enviado como un script. El clásico ejemplo es un fragmento de código de JavaScript enviado en una publicación en un foro web. Si esto no se intercepta en el ingreso (y por suerte casi todos los foros ahora detectan tales ataques), cualquier usuario posterior que lea la publicación experimentará la ejecución del script en su navegador, que posiblemente robará los token de sesión u otra información importante. Pero la inyección de script también puede ocurrir del lado del servidor, donde las aplicaciones mal diseñadas evalúan los datos enviados por el usuario y responden al script encapsulado.

6 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Los ataques fuera del límite o de sobrecarga del búfer también son riesgos de parámetros. Estos ataques intentan explotar un sistema ofreciéndole datos fuera del rango o tipo esperado, lo que puede generar fallas en el sistema u ofrecer acceso al espacio en la memoria. Este es el clásico ataque contra programas en C que fue tan popular en la década de los 90, pero que aún existe. Los ataques de parámetros se generan debido a que los desarrolladores no restringen de manera cuidadosa las entradas a una pequeña gama de tipos previstos. Las API son particularmente susceptibles a estos ataques porque su característica de autodocumentación a menudo proporciona a los piratas informáticos las perspectivas de cómo un sistema subyacente utiliza un parámetro. A diferencia de las aplicaciones web, donde el uso final de un parámetro generalmente se oculta o incluso se esconde por completo detrás de una apariencia HTML, las API pueden identificar con claridad el significado subyacente de un parámetro. Esto es muy común si la API se genera de manera automática a partir de un código de aplicación subyacente, ya que los nombres internos significativos se asignan por lo general directamente a parámetros de API externos. Riesgos de identidades y sesiones Los piratas informáticos han utilizado durante mucho tiempo credenciales falsificadas o robadas para explotar aplicaciones en Internet. En este sentido, las API simplemente proporcionan otra vía para aplicar los mismos ataques. Pero las API también abren vectores de ataque únicos que utilizan identidades. Una cantidad de estos ataques explotan malas prácticas comunes que se originan en la comunidad de desarrollo de aplicaciones web. A medida que los desarrolladores web se trasladan al desarrollo de API, a menudo acarrean malos hábitos de la Web convencional. Otros ataques surgen de una extensa confusión sobre cómo las API difieren del desarrollo de aplicaciones web tradicional. Muchas aplicaciones que publican API requieren que los clientes utilicen una clave API para obtener acceso a su funcionalidad. Sin embargo, el nombre “clave API” es un tanto inexacto, ya que implica que la clave es exclusiva de una API específica. De hecho, una clave API se asocia con una aplicación del lado del cliente y se puede aplicar en toda una gama de llamadas de API diferentes que una aplicación puede realizar. Generalmente, la clave API es un identificador no visible enviado a un desarrollador e incorporado dentro de su aplicación. Por lo tanto, identifica una aplicación determinada, pero no una instancia específica de una aplicación, ya que esta clave es común en cada copia de la aplicación. Parece sencillo, pero, en la práctica, las claves API son el origen de una gran confusión. Esta confusión es el origen de un nuevo vector de ataque a las API. Una clave API no identifica un usuario ni tampoco una instancia única de una aplicación. Además, las claves API no son fidedignas, ya que la clave en sí se oculta, por lo general, en un código compilado y está sujeta a la extracción por parte de cualquier desarrollador capacitado. (La “reutilización” de claves API de aplicaciones existentes es un truco común del desarrollador para tratar con administradores de API, como Twitter, que restringen la distribución de nuevas claves). Las claves API nunca deben sustituir las credenciales de usuarios cuando se autoriza el acceso a las API. Una clave API se debe tratar como un mecanismo de seguimiento no fidedigno para proporcionar métricas operativas básicas (como una carga relativa proveniente de diferentes aplicaciones). No debe ser la base de la auditoría, ya que puede generar la solicitud de reintegros, solo porque no es confiable para manejarse de forma segura del lado del cliente, como una contraseña. Es sencillamente demasiado fácil falsificar una clave API, de modo que no se puede confiar en esta para auditorías importantes. Por desgracia, demasiadas aplicaciones utilizan las claves API sin cuidado, como si fueran secretos compartidos almacenados de forma segura. Esta informalidad proporciona a los piratas informáticos un nuevo vector de ataque simple para explotar. Si el modelo de seguridad de una aplicación asume que una clave API es única para un usuario o es una prueba segura y fidedigna de una aplicación cliente particular, la aplicación de servidor es vulnerable al uso incorrecto.

7 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

La administración de sesiones es otra área de considerable confusión en la comunidad de API. Los desarrolladores que provienen del mundo de aplicaciones web detestan incluir credenciales formales en cada transacción, ya que esto no es algo que nunca se consideraría en un sitio web convencional. En la Web normal, los navegadores mantienen sesiones con cookies u otros ID de sesión no visibles. Lamentablemente, las API rara vez adoptan un enfoque consistente para la administración de sesiones, lo que hace que los desarrolladores creen uno propio, a veces de dudosa calidad. Posiblemente, OAuth llena este vacío y es el enfoque preferido para el desarrollo de API. Sin embargo, OAuth es difícil de aplicar bien y aún confía en la protección de claves críticas, como token de acceso y token de actualización, en el cliente y en tránsito. Es una tecnología prometedora, pero la aplicación de OAuth sigue siendo un gran desafío. La configuración y aplicación incorrectas son problemas comunes que aumentan el riesgo de las API. Riesgos de ataques de intermediarios Las API están sujetas a un mayor riesgo de ataques de intermediarios cuando la transmisión no se cifra ni firma o cuando hay un problema con la configuración de una sesión segura. Si una API no utiliza de manera correcta el estándar SSL/TLS, todas las solicitudes y respuestas entre un cliente y el servidor API pueden verse posiblemente comprometidas. Las transmisiones pueden alterarse en tránsito o reproducirse. Se pueden capturar datos confidenciales (como información personalmente identificable, identificadores de sesión, etc.). Incluso esas API que utilizan el estándar SSL/TLS están en riesgo si esto se configura de manera inadecuada en el lado del servidor, si el servidor está sujeto a ataques de degradación en cifras o si el cliente no está validando de manera adecuada la sesión segura (como una validación de certificado total, cadenas de confianza, confiabilidad de autoridades de certificación sospechosas o comprometidas, etc.). Una parte de este riesgo es el resultado de problemas culturales persistentes. En el mundo de aplicaciones web, el estándar SSL usualmente solo se utiliza en algunas transacciones “importantes”, como el envío de tarjetas de crédito o contraseñas. Por cierto, estos datos necesitan protección, como también la necesitan las claves de sesión que acompañan otras transacciones comunes después de un inicio de sesión inicial. Herramientas como Firesheep, que interceptan con facilidad las cookies en transmisiones web no cifradas, ilustran drásticamente los riesgos asociados con este enfoque. Esta práctica es, en gran medida, histórica y proviene de la etapa cuando SSL era informáticamente costoso para utilizar en servidores. Sin embargo, Google demostró de forma persuasiva que, en servidores contemporáneos, la carga informática adicional que surge de SSL es básicamente insignificante. A pesar de esto, muchos desarrolladores dejan las API abiertas y desprotegidas solo por falta de hábito. De hecho, la versión original de OAuth incluyó firmas aplicadas en parámetros de consulta como una forma de garantizar la integridad en transacciones. OAuth 1.0a utilizó estas firmas para la protección contra los ataques de intermediarios que pueden alterar parámetros en vuelo o robar un token de acceso para utilizar en otras transacciones. Esto fue un pequeño avance en la dirección correcta, ya que reconoció que existe un riesgo, pero solo lo mitigó por un subconjunto de posibles ataques a las API (por ejemplo, ignora problemas de confidencialidad completamente). En práctica, les resultó muy difícil a los desarrolladores aplicar firmas de forma consistente en OAuth. La versión dos de la especificación hizo optativas las firmas en reconocimiento a esta complejidad, en lugar de requerir el uso de TLS/SSL para proteger los token portadores. Como consecuencia de este cambio, la nueva solución abordó problemas de confidencialidad. Sin embargo, esta solución aún asume que SSL/TLS se debe configurar de manera correcta, y esto es algo decisivamente más complejo que solo agregar “s” a http en una URL de API.

8 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Sección 2

Orientación para la mitigación Si bien las API son susceptibles a una amplia gama de ataques, la aplicación de solo cinco estrategias simples de mitigación permitirá a una organización publicar API de forma segura.

Validar parámetros La única defensa más eficaz contra los ataques de inyección es validar todos los datos entrantes con una lista blanca de valores esperados. El enfoque más práctico para esto es aplicar una validación con esquemas a todos los datos entrantes con un modelo de datos altamente restrictivo. La validación con esquemas debe ser lo más restrictiva posible, y se deben utilizar la escritura, los rangos y los conjuntos cada vez que sea posible. Lamentablemente, los esquemas producidos de manera automática por muchas herramientas de implementación a menudo reducen todos los parámetros a simples cadenas y no son eficaces para la identificación de posibles amenazas. Se prefieren mucho más los esquemas manuales, ya que los desarrolladores pueden limitar mejor las entradas, según su comprensión de qué datos espera la aplicación. Los datos estructurados publicados se deben validar con un lenguaje de esquema formal. El contenido XML tiene la ventaja de un lenguaje de esquema XML muy expresivo que es altamente eficaz para la creación de estructura y modelos de contenido restringido. Sin embargo, las aplicaciones pueden validar el contenido basado en JSON con un lenguaje de esquema JSON emergente. Esta tecnología puede no ser tan buena como el esquema XML, pero, como JSON, el lenguaje del esquema es mucho más simple de componer y comprender que XML, lo que aporta a los desarrolladores una ventaja decidida. Los parámetros de consulta generalmente se correlacionan con tipos más simples y pueden, por lo tanto, validarse con modelos textuales simples. Las expresiones regulares son un enfoque excelente para crear un esquema de parámetros de consulta muy restringido, pero ampliamente comprendido.

Aplicar detección de amenazas La detección de amenazas suele ser un ejercicio en la ubicación en la lista negra del contenido riesgoso, como declaraciones SQL o etiquetas SCRIPT. El desafío es aplicar esto eficazmente. Es fácil analizar los datos entrantes para textos como SELECT. Sin embargo, es mucho más difícil evitar falsos positivos cuando esta secuencia de caracteres se produce legítimamente. Es importante poder ajustar el análisis de seguridad de manera adecuada para la API en cuestión. La detección de virus también se debe considerar en contenido cifrado. El contenido binario publicado posiblemente puede ocultar contenido ejecutable. Las API involucradas en la transferencia de archivos deben decodificar de manera definitiva documentos adjuntos base64 y enviarlos para el análisis de virus de servidor. Muchos proveedores antivirus comerciales ofrecen una solución basada en el servidor con una API simple que cumple con ICAP. Una aplicación debe enviar contenido a esta antes de que persista en cualquier sistema de archivos, donde posiblemente pueda activarse como un virus. Por último, recuerde que la complejidad y el tamaño del mensaje pueden en sí mismos ser una amenaza para las API. Los mensajes muy largos, las estructuras de datos anidados o las estructuras de datos demasiado complejas pueden representar ataques de denegación de servicios eficaces contra un servidor de API. Es riesgoso comenzar simplemente el procesamiento de parámetros en una aplicación sin primero validar que el contenido esté dentro de un rango aceptable.

9 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Activar SSL en todos lados Haga de SSL/TLS la regla para todas las API. En el siglo XXI, SSL no es un lujo, es un requisito básico. Agregar SSL/TLS, y aplicarlo correctamente, es una defensa eficaz contra el riesgo de ataques de intermediarios. SSL/TLS proporciona confidencialidad e integridad en todos los datos intercambiados entre un cliente y un servidor, incluidos los token de acceso importantes como aquellos utilizados en OAuth. Ofrece opcionalmente una autenticación del lado del cliente mediante certificados, que es importante en muchos entornos de alta seguridad. Sin embargo, a pesar de ser mucho más simple que los métodos de seguridad de mensajes, como WS-Security, SSL aún puede ser utilizado de manera indebida. Es fácil realizar una configuración incorrecta en el servidor, y la investigación ha demostrado que muchos desarrolladores no validan adecuadamente certificados y confían en las relaciones cuando lo aplican. Destine tiempo a auditar la configuración y el uso del lado del servidor y del lado del cliente.

Separar identidades La identidad del usuario y la identidad de la aplicación son distintas. Los desarrolladores deben reconocer las limitaciones de las credenciales de ID de aplicaciones, como las claves API, y comprender el contexto correcto para utilizarlas. Los desarrolladores del lado del servidor deben separar con claridad las identidades de usuarios y las identidades de API, y posiblemente considerar incluso la autorización basada en un amplio contexto de identidades, que puede incluir todo el conjunto de detalles, como el usuario, la aplicación, el dispositivo (p. ej., un teléfono móvil particular), la ubicación, la hora, etc. OAuth se está convirtiendo rápidamente en el método de autorización aceptado para las API, pero es importante darse cuenta de que OAuth sigue siendo una tecnología compleja y confusa. Si bien OAuth, en algunos aspectos, se ha simplificado con su evolución de la versión 1.0a a la versión 2.0, su alcance se ha incrementado drásticamente. Esto creó una gran confusión sobre cómo y cuándo aplicarla. También creó problemas de interoperabilidad significativos. Los desarrolladores deben seguir los casos de uso básicos y de fácil comprensión, y siempre utilizar bibliotecas existentes en lugar de intentar crear una propia.

Utilizar soluciones probadas La regla básica de seguridad es: no invente una propia. Las API no son la excepción a esta regla. No hay ningún motivo para crear su propio marco de seguridad de API. Ya existen excelentes soluciones de seguridad para las API, como así también para la Web. El desafío es aplicarlas. Las bibliotecas para la validación de parámetros basada en formularios en aplicaciones web son comunes, de modo que debe tenerlas en cuenta en la arquitectura de API. De un modo similar, hay muchas bibliotecas de OAuth buenas disponibles para los idiomas más comunes. Otro enfoque probado es separar la seguridad de las API de la aplicación que las publica. Esto permite a los desarrolladores de aplicaciones focalizarse completamente en la lógica de la aplicación, mientras un experto en seguridad dedicado se centra en aplicar una política de seguridad de forma consistente en todas las API. Este enfoque se describe en la siguiente sección.

10 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

Sección 3

Obtención de un control total sobre la seguridad de las API Arquitecturas de API seguras La mejor práctica para la arquitectura de seguridad de API es separar la implementación de API y la seguridad de API en distintos niveles. Estos niveles separados enfatizan que el diseño de API y la seguridad de API son roles esencialmente diferentes que requieren un conocimiento diferente. Esta es una separación muy lógica de cuestiones, una que focaliza la experiencia en el problema adecuado, en el momento adecuado. Según este modelo, un desarrollador de API puede centrarse completamente en el dominio de una aplicación, garantizando que cada API esté bien diseñada y promueva la integración entre diferentes aplicaciones. Esto libera al desarrollador de la responsabilidad de proteger las API publicadas, ya que de esto se encargará un profesional dedicado en la seguridad de las API. El experto en seguridad de las API es responsable de aplicar una política de seguridad de forma consistente en toda la organización. Su foco está en la identidad, las amenazas y la seguridad de datos, en otras palabras, cada uno de los problemas y amenazas destacados en este documento. Es muy importante otorgar a cualquiera que desempeñe este rol crítico las herramientas adecuadas para el trabajo, ya que necesitará separar la seguridad de la implementación de API en sí. CA API Gateway es la herramienta indicada. Este es un dispositivo reforzado, que se proporciona en forma física o virtual y se implementa generalmente en la DMZ de una organización, como se indica en la ilustración B a continuación. Es el proxy seguro entre la aplicación interna y la Internet externa. CA API Gateway proporciona al administrador de seguridad de API un control total sobre el control de acceso, la detección de amenazas, la confidencialidad, la integridad y la auditoría en cada API que publica la organización.

Ilustración B: CA API Gateway crea una separación de intereses entre el desarrollo de API del lado del servidor y la seguridad en la API.

Puerta de enlace en línea sencilla ✓Control de acceso ✓Detección de amenazas ✓Confidencialidad e integridad ✓Administración de auditorías

Servidores de API internos

Firewall Firewall

Dispositivos móviles Directorio/IAM Nube Red empresarial Clientes de API

Integraciones informales impulsadas por API

11 | Reporte oficial: Protección de las API contra ataques y robos

ca.com/ar

CA API Gateway tiene un modelo de seguridad basado en políticas que se diseña fácilmente para adaptarse a los diferentes requisitos de seguridad para cada API. Ofrece políticas centrales que se pueden compartir con facilidad en conjuntos de API para crear una instancia de seguridad básica consistente, además de la capacidad de especializarse en una API por vez para cumplir con las necesidades específicas de una aplicación determinada. También se integra fácilmente con los sistemas de identidades existentes (LDAP, IAM, etc.) y sistemas de monitoreo operativos. CA API Gateway proporciona al administrador de seguridad un control total sobre todos los aspectos de la seguridad de las API, como los siguientes: • La detección de amenazas, como la inyección de SQL, XSS, CSRF, el tamaño del mensaje, etc. • La confidencialidad y la integridad, incluidas las limitaciones en conjuntos de cifras, cifras avanzadas basadas en tecnología, como certificados digitales de ECC, seguridad basada en mensajes, etc. • La validación de mensajes, como la validación de esquemas XML y JSON. • El soporte de autenticación, como las credenciales básicas, las claves API, OAuth, SAML, OpenID Connect, Kerberos, certificados digitales x509, etc. • La integración con los sistemas de administración de identidades y accesos (IAM) más comunes, como LDAP genérico, Microsoft AD, Tivoli Access Manager, Oracle Access Manager, CA/Netegrity, etc. • La limitación de la tasa de transferencia y la configuración del tráfico de transacciones con cualquier modelo. • La notificación de eventos y la auditoría impulsados por políticas, como la capacidad de capturar eventos según el criterio personalizado e integrarse con una infraestructura de administración y seguridad existente.

Sección 4:

Conclusiones Se dice que aquellos que no aprenden de la historia están condenados a repetirla. La seguridad de las API parece corroborarlo. Es importante reconocer, sin embargo, que las API incorporan nuevas amenazas que se deben abordar. La verdadera perspectiva que debemos tener de la historia es que los desarrolladores de aplicaciones se ocupan de la seguridad al final del proyecto, si se llegan a ocupar, y aceleran la implementación. Este comportamiento es difícil de cambiar. Es hora de adoptar un enfoque diferente. Separar el desarrollo de las API y la implementación de seguridad de las API es la mejor práctica que se debe seguir para crear una estrategia de API segura. CA API Gateway proporciona a los administradores de seguridad las herramientas necesarias para proteger las API de una organización.

12 | Reporte oficial: Protección de las API contra ataques y robos

Comuníquese con CA Technologies en ca.com/ar.

CA Technologies (NASDAQ: CA) crea un software que impulsa la transformación en las empresas y les permite aprovechar las oportunidades de la economía de la aplicación. El software es el centro de cada negocio, en cada industria. Desde la planificación hasta el desarrollo, la administración y la seguridad, CA trabaja con empresas en todo el mundo para cambiar la forma de vivir, de realizar transacciones y de comunicarse, mediante entornos móviles, de nube pública y privada, y centrales y distribuidos. Obtenga más información en ca.com/ar.

1 Mejor ilustrado por XKCD: http://xkcd.com/327/ 2 Para obtener un excelente estudio sobre los problemas comunes en el uso de SSL/TLS del lado del cliente en relación con las API, consulte: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

Copyright © 2014 CA. Todos los derechos reservados. El propósito de este documento es meramente informativo y no realiza ningún tipo de garantía en relación con los productos o las ofertas que aquí se mencionan.CS200_87351_0914