Header Ads Widget

Ticker

6/recent/ticker-posts

Equipar su API con la armadura adecuada

 

Equipando_su_api_right_argmor_security_armor

Las API son tan amplias y variadas como los sistemas que dependen de ellas; Mientras que algunos sistemas pueden manejar datos de clientes, pagos e investigación colaborativa, otras API pueden manejar datos menos importantes como las redes sociales y el intercambio de imágenes.

Debido a las variaciones en la aplicación y el uso, las API enfrentan un conjunto único de consideraciones y problemas que surgen de su disponibilidad que ningún otro sistema enfrenta: la diferencia entre tener una API para consumo público o una destinada a uso interno, en ciertas circunstancias, puede significar la diferencia entre el éxito megalítico y el fracaso catastrófico.

Comprender los objetivos comerciales específicos involucrados en hacer que su API sea privada o pública es primordial. Hoy, identificaremos la diferencia entre API públicas, privadas y de socios. , y cuándo cada tipo tiene sentido en diferentes escenarios. También abordaremos algunos ejemplos de fallas en la restricción y documentación de API, así como algunos éxitos en diseño y desarrollo.

Diferencias en los enfoques de API: API privadas, públicas y de socios

Al considerar la interacción entre las API y sus mercados previstos, existen tres enfoques generales para la concesión de licencias y la disponibilidad.

security_armor_private

Las API privadas son API destinadas a optimizar las operaciones internas, traduciendo las llamadas de forma oculta. Si bien pueden estar documentados, esta documentación es en gran medida limitada y está destinada únicamente a fines internos. El desarrollo está a cargo de los creadores de la API y no se permiten derivaciones. Si bien este tipo de ciclo de desarrollo e implementación puede ser muy efectivo para crear y mantener un crecimiento acelerado , su API está limitada por lo que la diseñó para hacer: su API no evolucionará con los tiempos y las necesidades del mercado a menos que la fuerce específicamente. a, lo que puede requerir mucho tiempo y dinero.

security_armor_public

Las API públicas son API que tienen cierto acceso público, funcionan de manera más transparente y permiten que otros usuarios, servicios y sistemas se vinculen con partes de la interfaz subyacente. Estas API suelen estar muy documentadas, ya que los desarrolladores las utilizarán públicamente para utilizar la API para varios servicios. Para algunas API públicas muy transparentes, la "bifurcación" de la API, creando nuevas derivaciones de la API, está abierta a cualquiera que desee hacerlo, haciéndola evolucionar orgánicamente. Sin embargo, esto es raro, ya que la mayoría de las API web públicas todavía son de código cerrado, lo que permite a una empresa mantener la propiedad total. En general, las API públicas permiten crear un ecosistema de desarrolladores de terceros con sus datos o servicios, una evolución orgánica con nuevas posibilidades y servicios, potencialmente resultando en un crecimiento acelerado explosivo y sostenido.La desventaja de una API pública es que podría disminuir el valor de sus principales canales de distribución y, en algunas situaciones, las oportunidades de monetización directa que surgirían de una API privada o de socio más bloqueada.

security_armor_partner

Las API de socio son API B2B que se exponen a través de acuerdos entre el desarrollador y el cliente, que describen la aplicación y el uso de la API. La documentación suele ser exhaustiva, pero solo para aquellas llamadas de interfaz que serán utilizadas por la empresa según se define en la licencia contractual; otras funciones están bloqueadas, no documentadas o requieren autorización y autenticación para su uso. Una API de este tipo es muy eficaz y puede resultar extremadamente lucrativa. Las derivaciones se pueden subcontratar, pero todo el desarrollo de API es sintético y dirigido en lugar de orgánico.

Descargar desarrollo API Mindest

Consideraciones y advertencias

Entonces, ¿cuál es la opción que impulsa a una empresa al modelo de API pública y a otra a la API de socio? Al considerar el tipo de licencia y disponibilidad de API, se deben tener en cuenta varias consideraciones al comienzo del ciclo de vida de la API , ya que pueden cambiar fundamentalmente el enfoque para el desarrollo de su API al cambiar la metodología de implementación.

En primer lugar, considere la naturaleza de los datos y los sistemas a los que hará referencia su API. Al diseñar una API que aproveche datos personales seguros, como números de seguro social, registros de pago y servicios de identificación general, la cantidad de seguridad necesaria para su API cambia drásticamente el equilibrio hacia una consideración de privado o de empresa a empresa. Licencia.

Esto se debe en gran parte a la vulnerabilidad del código y la documentación de la API de cara al público . Piense en su licencia como una armadura. Si bien la armadura de placas es pesada y dificulta el movimiento, es extremadamente segura. La armadura de cuero, por otro lado, es extremadamente ligera y flexible, lo que otorga una agilidad extrema. Su licencia es muy similar: las API privadas son una armadura de placa y las API públicas de código abierto son de cuero. Las API de socios de empresa a empresa son como una cadena de correo: en algún punto intermedio en cuanto a otorgar agilidad y protección. Si bien el uso de API públicas puede controlarse de alguna manera (o curtirse en el espíritu de nuestras metáforas de armadura), nunca serán tan seguras como una API privada de código cerrado y plateada.

En segundo lugar, considere la cantidad de mantenimiento que desea realizar. Todos los tipos de API pueden tener ciclos de desarrollo arduos, largos y costosos, dependiendo de sistemas e interfaces propietarios. Los costos y recursos pueden extenderse para las API públicas con el fin de mantener portales de desarrolladores orientados al público y mantener los sistemas de soporte externos, como canales de marketing, hackatones y otras operaciones de productos API .

Finalmente, se debe considerar la monetización. Si bien las API privadas de código cerrado se pueden monetizar a través de una eficiencia operativa mejorada y promociones de contenido , las API de socios se pueden licenciar mediante una tarifa para obtener ingresos directos; Las API públicas de código abierto también se pueden monetizar mediante la venta directa de datos y otras metodologías.

La serie de blogs del ciclo de vida de las API

Entonces, ¿dónde está el término medio?

Entonces, ¿dónde está la línea? ¿Cuál es la combinación ideal de seguridad, condiciones de acceso y monetización para su situación específica? Funcionalmente, su API solo debe ser tan pública como lo requieran sus funciones, sus diseños, las limitaciones de su negocio y los objetivos de su implementación.

Por ejemplo, si uno estuviera desarrollando una API que usaría datos proporcionados por proveedores externos para recopilar datos para análisis, ¿cuál sería una cantidad adecuada de exposición? Dada la naturaleza de los datos y los requisitos de seguridad probablemente establecidos por los proveedores, una API de socio sería apropiada; después de todo, otros socios tendrán que vincularse a su API para entregar datos, y deberá proporcionar cierta cantidad de documentación para que eso ocurra.

Por el contrario, si estuviéramos diseñando una API que entrega redes sociales o feeds RSS a un usuario, ¿cuál sería un tipo de exposición apropiado? En este caso, debido a que los datos están completamente abiertos, no están vinculados a sistemas y utilizan datos públicos, una API pública es apropiada. En este escenario, el código abierto es perfecto, ya que permite que el número máximo de usuarios utilice la API y la mejore con el tiempo, utilizando servicios de colaboración como GitHub y Bitbucket para revisar y bifurcar la API en sistemas mejores y más grandes; si la API tuviera que tratar con datos confidenciales, proveedores externos, etc., esto cambiaría, pero tal como está, el nivel de exposición es absolutamente apropiado para el escenario del caso de uso.

Sus consideraciones deben ser un amplio espectro de oportunidades de monetización, costo de mantenimiento y más, pero en términos de seguridad, los desarrolladores siempre deben seguir la regla de la simplicidad: exponer solo lo que debe exponerse .

Fracaso del mundo real

A finales de 2014, el gigante de las redes sociales Snapchat se enfrentó a una gran falla de seguridad en su API indocumentada descubierta por la empresa de seguridad GibSec . Debido a la naturaleza de su API (B2B y semiprivada), las aplicaciones de terceros pudieron conectarse al servicio de tal manera que los servidores y sistemas conectados se volvieron vulnerables.

Una vulnerabilidad en la API, utilizando una llamada autenticada y autorizada a la /ph/find_friendssolicitud, abrió el sistema Snapchat a los piratas informáticos de una manera que los desarrolladores ni siquiera consideraron; Después de calcular la cantidad de usuarios de Snapchat y la cantidad de solicitudes que podrían completarse en un minuto, GibSec estimó que los 8 millones de usuarios podrían tener sus datos personales, números de teléfono e incluso imágenes raspadas por un servidor promedio en aproximadamente 26.6 horas (lo que fue una estimación conservadora).

Entonces, ¿cómo falló la API? Funcionalmente, hubo una discrepancia entre el acceso documentado y las restricciones reales sobre esas características. Si bien la API se diseñó para ser una API de socio, se documentó con estos socios de la misma manera que una API pública.

Si bien es cierto que si la API fuera más pública, se podrían haber detectado y solucionado vulnerabilidades antes de que se convirtiera en un problema mayor, el hecho es que la API no necesitaba estar abierta en primer lugar. Al no administrar adecuadamente los datos y permitir que empresas y desarrolladores no autorizados accedan a la API de Snapchat y a los sistemas internos, Snapchat quedó innecesariamente expuesto y vulnerable.

Además, el hecho de que Snapchat no se adhirió a un enfoque singular fue extremadamente perjudicial. Si el sistema fuera 100% interno, es probable que un equipo haya estado monitoreando la API y se habría encontrado con el problema mucho antes de que se descubriera realmente. Si la API fuera solo B2B, la vulnerabilidad no habría sido un problema, ya que las llamadas habrían requerido autenticación y autorización muy por encima de la de un usuario normal, evitando que ocurriera la filtración. Finalmente, si la API fuera completamente pública, es probable que la vulnerabilidad se hubiera descubierto antes, tal vez a través de los esfuerzos de los llamados "hackers de sombrero blanco" que prueban las vulnerabilidades por diversión o por uso común.

Ni plato, cuero o cadena, el Snapchat falló porque ocupaba un extraño espacio entre los enfoques de API. Dado que no se realizó la preparación necesaria para definir la premisa de la API, el acceso a la API no se mantuvo bien, lo que dejó una enorme vulnerabilidad presente.

Obtenga más información sobre la preparación: etapa de análisis: preparación de su estrategia de API previa al lanzamiento

Dos éxitos del mundo real

Lego

LEGO , la famosa compañía de juguetes de ladrillos de Dinamarca, ha pasado la mayor parte de su existencia asegurándose de que sus juguetes fueran divertidos, creativos y seguros. Cuando LEGO se lanzó a la era moderna, comenzaron a considerar seriamente el desarrollo de su propia API, centrándose en gran medida en extender esa creatividad y seguridad a la World Wide Web. A continuación, Dennis Bjørn Petersen analiza el desarrollo, los desafíos y los éxitos de su API privada de código cerrado.

Vea al arquitecto de plataformas LEGO Dennis Bjørn Petersen presente en un evento de API nórdicas

El éxito de la historia de LEGO demuestra exactamente por qué una API debe tener límites determinados en lo que respecta a la divulgación de fuentes. Debido a la naturaleza de los datos que maneja LEGO y a la corta edad de su público objetivo, la API que se desarrolló se bloqueó en un entorno de API privada. Este desarrollo, aislado de la exposición, aseguró que el sistema fuera seguro y eficaz.

Carson City, Nevada

Otra gran historia de éxito de API es la de Carson City, Nevada. Mientras que el éxito de la API de LEGO se debió a su naturaleza cerrada y diseño con propósito, para Carson City, la integración de una API que utiliza los activos de los sistemas de infraestructura de la ciudad y la colaboración de varios socios públicos y privados demuestra el éxito en el espacio de API de socios. .

Cuando Carson City se propuso diseñar su sistema de ciudad inteligente, formaron una asociación entre el Departamento de Obras Públicas de Carson City , los ciudadanos de Carson City y Schneider Electric . La ciudad empaquetó los datos abiertos generados por varios dispositivos inteligentes en la ciudad en una API de socio diseñada específicamente para la optimización, la generación de informes y la planificación. Los funcionarios de Carson City pudieron lograr cosas asombrosas, convirtiendo su ciudad en una verdadera ciudad inteligente . Según el informe final presentado por Schneider Electric , hubo muchos beneficios:

  • Se agilizó la gestión de las centrales eléctricas de la ciudad.
  • El sistema de gestión del agua se optimizó drásticamente.
  • Las operaciones de mantenimiento se redujeron de una semana de 5 a 4 días.
  • Se ahorraron horas de personal gracias a la reducción del "tiempo de conducción" entre ubicaciones. Al diseñar su API para que funcione específicamente para el propósito previsto, en una circunstancia limitada con socios seguros, definidos y examinados, Carson City se preparó para un éxito masivo con beneficios reales y lucrativos. resultados.

Conclusiones

Contemplar las licencias, la accesibilidad y la disponibilidad fundamental de su API debe ser su primer paso en el ciclo de vida de la API . La complejidad de las situaciones presentadas por su elección en este paso inicial puede afectar el éxito, la longevidad y la utilidad de sus API. Si bien la seguridad es, como siempre, una preocupación principal en las consideraciones iniciales, la monetización de su API, la disponibilidad del sistema y la facilidad de uso de ese sistema en su conjunto dependen completamente del enfoque adoptado.

Repasemos los beneficios de cada enfoque:

  • Las API públicas de Leather Armor pueden tener una amplia tasa de adopción y el potencial de difundir el conocimiento de la marca.
  • Las API privadas de Plated Armor permiten una mayor seguridad y administración interna. Mantenlo en secreto, mantenlo a salvo .
  • Las API de Chain Mail Partner son quizás el Goldilockian Mithril para su situación de integración B2B, lo que permite una combinación de seguridad y potencial de asociación definido.

Más que cualquier otra consideración, su propósito particular al desarrollar una API determinará la elección que haga. ¡Ahora ingrese a la economía API blandiendo la armadura que elija y feliz solicitando!

Publicar un comentario

0 Comentarios