Fortalecimiento de su postura de seguridad API

El efecto bola de nieve de la ciberseguridad

Con las comunidades de desarrollo y los equipos de productos, hay muchas cosas que se han unido: todo, desde nuevos desarrolladores, la introducción de código abierto, nuevas APIs, técnicas de desarrollo ágiles, la nube, DevOps, DevSecOps, etc. Eventualmente, si no maneja esto, lo alcanzará y llegará a un punto sin retorno. Ya sea que sea una empresa pequeña, una empresa mediana o una gran empresa, si ignora y no aborda estos problemas, terminaremos en una brecha de seguridad (golpeada por la bola de nieve). Es posible que muchas personas no se den cuenta de que el ciberdelito es más rentable que el tráfico mundial de drogas. Ahora, considere ese hecho, y las API son importantes porque los delincuentes van a ir a donde están los datos.

La seguridad de la API todavía es relativamente nueva. El Top 10 de seguridad de API de OWASP se lanzó a finales del 2019. Por lo tanto, solo llevamos poco más de dos años para tener estas vulnerabilidades de seguridad de API bien definidas como una industria que los profesionales del software ahora pueden comenzar a abordar.

Entonces, la pregunta sigue siendo: ¿Cómo se puede evitar un incendio en un contenedor de seguridad de API?

Antes de hablar sobre lo que funciona, abordemos algunas fallas que hemos visto en el camino.

El enfoque Whack-a-Mole – Encontramos un problema; arreglamos un problema. Si alguna vez has jugado al juego, golpea un topo, sabes que lo golpeas con un mazo y aparece otro y, con el tiempo, su velocidad y número aumentan a medida que intentas golpearlos, tratando desesperadamente de mantener el ritmo. En algún momento te das cuenta de que no hay esperanza de ganar el juego porque los topos llegarán más rápido de lo que puedas derribarlos. Lo mismo ocurre con la analogía de la bola de nieve, nunca tendrás suficientes bolas de nieve para atacar todas las amenazas. Este enfoque puede funcionar por un tiempo, pero lo alcanzará y se producirá una infracción.

Solo vamos a monitorear todo: como el niño que gritó lobo, los profesionales de la seguridad son profetas del infortunio hasta que alguien ve un lobo. Todos sabemos que los lobos existen y son peligrosos, pero hasta que atacan, la guía de los profesionales de seguridad a menudo se reduce a una hipérbole. Si bien puede monitorear todo, nunca tendrá suficientes monitores o personas para responder a los monitores y su relación señal / ruido tiende a ser muy alta. Como la fábula, el niño que gritó lobo, la gente puede dejar de creerte debido a todos los falsos positivos.

Política y estándares obligatorios: las políticas y los estándares son buenos, pero no son suficientes. Solo son efectivos cuando los empleados los comprenden y los utilizan en el proceso de desarrollo, lo que significa que no solo se integra en el proceso de desarrollo, sino que también forma parte de la canalización y el lanzamiento. Si es algo que está fuera de la norma del día a día, rápidamente se olvida. Si esto no está automatizado, fallará.

el enfoque de comando y control: el siguiente enfoque es la gestión de arriba hacia abajo, el enfoque de comando y control. «¡Haz esto porque yo te lo dije!» Puede funcionar hasta cierto punto, pero de manera realista, los líderes que insisten en que sus equipos sigan sus decisiones sin cuestionar pueden perder muchos aprendizajes y comentarios constructivos que podrían mejorar los productos. Este tipo de enfoque también puede causar un desequilibrio para los equipos de productos ágiles.

Colaboración: personas, procesos y tecnología

La seguridad de la API es un acto de equilibrio. Hay un aspecto de personas, un aspecto de procesos y un aspecto de tecnología. Si están fuera de balance, te caerás de tu taburete y los malos estarán listos para atacar. La seguridad de la API no es un problema de seguridad, es una responsabilidad comercial compartida. Las personas, los procesos y las tecnologías deben trabajar juntos para gestionar el riesgo. Esto es muy importante. Si no lo hace, desperdiciará mucho dinero. Si te enfocas en la tecnología e ignoras a las personas y los procesos, fracasarás. Si te enfocas en los procesos, ignoras a las personas y la tecnología, fracasarás. Si te concentras en dos de ellos, aún fallarás. Es el equilibrio de estas tres cosas lo que crea la base para un programa de seguridad de API exitoso para una organización de cualquier tamaño.

Para que la seguridad sea completamente exitosa a través del acto de equilibrio de personas, procesos y tecnología, debe encontrar formas de eliminar el trabajo manual siempre que sea posible y aumentar los esfuerzos manuales con un enfoque de cambio a la izquierda para automatizar todo, comenzando en el momento del diseño. Solo a través de la automatización y la habilitación de DevSecOps, el equipo puede mantener su velocidad y entregar un producto seguro y de calidad.

Los 5 pasos para fortalecer la postura de seguridad de las API

  1. Conozca su inventario: si no sabe lo que hay, las cosas pueden perderse con bastante facilidad. Los equipos pueden salir por su cuenta y volverse deshonestos y hacer cosas con grandes intenciones, pero de repente descubres que hay muchos problemas de seguridad. Así que controle absolutamente todo su inventario de API. 
  2. Audite sus API sensibles: asegúrese de realizar una auditoría de seguridad en sus API más sensibles. De esta forma, puede encontrar y solucionar problemas de seguridad antes de que lo haga un atacante.

3.Ataque el Top 10 de seguridad de la API de OWASP: haga todo lo posible para abordar el Top 10 de seguridad de la API de OWASP. Si no está familiarizado con ellos, puede hacer clic en el siguiente para obtener más información:

A1: Control de acceso a nivel de objeto roto
A2: Autenticación rota
A3: filtrado de datos inadecuado
A4: Falta de recursos y limitación de velocidad
A5: Función faltante / control de acceso a nivel de recursos
A6: Asignación masiva
A7: Configuración incorrecta de seguridad
A8: inyección
A9: Gestión inadecuada de activos
A10: Registro y monitoreo insuficientes

4.Confíe pero verifique: debe confiar en que sus equipos harán lo correcto, pero somos humanos. La gente está bajo presión para cumplir con una fecha límite y se pueden cometer errores. A veces, las cosas simplemente suceden. Quiere asegurarse de poder verificarlo. Entonces, si algo sucede, se puede encontrar y reparar de inmediato.

5.Coordine la divulgación y la recompensa por errores: no asuma que la seguridad lo sabe todo. Invite a la gente buena para que le ayude a encontrar errores. ¡Te sorprenderá lo que puedes aprender de eso!

Más información sobre 42Crunch API Security Platform.

     Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Las APIs, la seguridad y como detectar actividad maliciosa en nuestras APIs y su desarrollo en el ciclo de vida.

Las API modernas (especialmente en microservicios interconectados) erosionan los límites típicos de la red y reducen la efectividad de las protecciones perimetrales tradicionales, como los firewalls de aplicaciones web (WAF). Mauny sugiere que con la importancia cada vez menor del perímetro, es más importante proteger los datos que el perímetro en sí.

La otra consideración clave es garantizar que las herramientas de seguridad de API tengan el contexto completo para garantizar que la herramienta tome la decisión correcta, ya sea de forma estática (como cuando se audita un contrato de API con el estándar OpenAPI) o dinámicamente al imponer el comportamiento del tráfico en un punto final de API. Los WAF también ejemplifican cómo la falta de contexto los hace ineficaces para proteger una API: un WAF no puede distinguir el comportamiento malo (no intencionado) del comportamiento bueno (intencionado). 

Finalmente, el artículo destaca el valor de los contratos API como medio hacia un modelo de seguridad positivo, en el que se define claramente el comportamiento esperado, lo contrario de un modelo de seguridad negativo donde se infiere un mal comportamiento. Al utilizar una definición de API (como una definición de OpenAPI del contrato de API) es posible verificar el proceso de desarrollo de API en cada etapa del ciclo de desarrollo e implementación. Este enfoque le brinda al oficial de seguridad una visión temprana de la postura de seguridad de las API y garantiza que las API se pueden probar con sus contratos.

Aunque los entornos en la nube ofrecen a las empresas muchos beneficios de seguridad, continúan surgiendo nuevas vulnerabilidades que ofrecen a los atacantes nuevos caminos hacia los entornos basados en la nube. 

Una de esas rutas de ataque es la API. Cada aplicación móvil conectada, web moderna o alojada en la nube utiliza y expone API. Estas API permiten el acceso a los datos y llamar a la funcionalidad de la aplicación. Si bien son relativamente fáciles de exponer, son difíciles de documentar y defender. 

Como resultado, abundan las API ocultas y zombies, la verificación de tipos es laxa, las especificaciones de la API están incompletas y los problemas de autenticación y autorización a menudo aumentan. Para abordar estos desafíos, 42Crunch colaboró con Cisco para crear APIClarity, una nueva herramienta de código abierto para mejorar la configuración y protección de las API.

Un informe reciente de IBM revela que dos tercios de las brechas en la nube tienen su origen en una mala configuración de las implementaciones de API. El informe contiene 12 meses de hallazgos de varios equipos de investigación de IBM y concluye que los entornos de nube deben estar mejor protegidos, los hallazgos clave del informe incluyen:

  • Existe un vasto y próspero mercado negro para la reventa de detalles y credenciales de acceso a la nube pública, como el acceso al Protocolo de escritorio remoto.
  • Muchos sistemas podrían verse comprometidos debido a contraseñas deficientes y políticas inadecuadas.
  • Las API fueron la causa más común de compromiso, representando casi dos tercios de los casos identificados en el informe.
  • La erosión del perímetro tradicional ha dado lugar a escenarios más complejos que son difíciles de proteger con sistemas heredados.

Las principales recomendaciones del informe incluyen:

  • Los entornos deben protegerse mediante un refuerzo más sólido de los sistemas (por ejemplo, mediante la protección de contraseñas o la aplicación de políticas).
  • Se debe imponer un gobierno más estricto a la “TI en la sombra” porque representa un riesgo comercial no cuantificado y es una fuente frecuente de compromiso.
  • Las organizaciones deben comprender los riesgos inherentes a la rápida apertura al acceso público de las APIs que hasta ahora solo eran internas, ya que esto abre nuevos vectores de ataque. 

Cada vez más, los puntos finales de las APIs destinados a aplicaciones web o móviles están siendo atacados por robots y actores deshonestos, ser capaz de identificar estos ataques en los sistemas permite frustrar los ataques potenciales antes de que tengan éxito estas son algunas sugerencias clave (y relativamente simples) para los desarrolladores de API:

  • Utilice un dominio separado para aplicaciones web y móviles. Esto permite identificar la actividad espuria, por ejemplo, al poder detectar cuándo un navegador está accediendo a un punto final destinado a una aplicación móvil, un indicador principal de que un atacante humano puede estar intentando aplicar ingeniería inversa a la API.
  • Preste atención a la presencia de «rastreadores», como Facebook y Google, que se utilizan comúnmente para enumerar sitios web, en los puntos finales de la API, especialmente en los de aplicaciones móviles. La presencia de rastreadores en los registros suele ser una indicación de reconocimiento activo y un ataque inminente.
  • Revise los registros de API periódicamente, prestando especial atención a las cadenas de agentes de usuario: una señal de comportamiento inusual o inesperado suele ser el precursor de un ataque.

Dado el aumento de los ataques de bots a las API, estas simples recomendaciones deberían resultar valiosas para los creadores de API.

     Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Las herramientas de seguridad de la aplicación no están a la altura de la seguridad de la API

Las últimas dos décadas han visto una proliferación de software (según GitHub, solo en 2020 ha habido un aumento del 35% en los repositorios de código) en todos los aspectos de nuestras vidas en forma de aplicaciones web o móviles. Los adversarios han atacado cada vez más estas aplicaciones y los defensores han adoptado diversas herramientas y tecnologías de prueba para protegerlas.

Hoy en día, la mayoría de las empresas cuentan con un programa de seguridad de aplicaciones (AppSec) para gestionar la implementación de estas herramientas y gestionar las vulnerabilidades asociadas. La única constante en el mundo del desarrollo de software es el cambio, y nunca más que en los últimos años con la adopción generalizada de tecnologías nativas de la nube (como contenedores, plataformas de orquestación) y la ruptura del monolito a través de la adopción de microservicios.

Desafortunadamente para los equipos de AppSec, este panorama en rápida evolución ha significado que muchas de las herramientas que utilizan no están a la altura de la tarea de proteger sus aplicaciones.

En ninguna parte esto es más evidente que con la seguridad de las interfaces de programas de aplicación (API), que son fundamentales para todas las aplicaciones modernas. Las API presentan un desafío único desde la perspectiva de la seguridad debido a su singularidad desde el punto de vista del ataque, un hecho reconocido por OWASP, quien produjo una lista dedicada de los 10 principales para las vulnerabilidades de seguridad de las API .

Por qué las herramientas de AppSec existentes se comportan mal en las API

  
SAST no fue diseñado para aplicaciones centradas en API

El caballo de batalla de cualquier programa de AppSec es la prueba de seguridad de aplicaciones estáticas (SAST), que es una evaluación de «caja blanca» de las vulnerabilidades en una aplicación derivada del examen del código fuente y la creación de un modelo del flujo de datos a través de una aplicación para determinar dónde La aplicación puede ser vulnerable a ataques externos mediante, por ejemplo, ataques de inyección.

Las rutas de flujo de datos complejas o los marcos no compatibles reducen la precisión de un análisis SAST, ya que el modelo puede estar incompleto o ser inexacto.

En el caso de las API, esto es significativamente más complejo ya que la mayoría de las herramientas SAST están diseñadas para trabajar con aplicaciones web construidas como, por ejemplo, Java Servlet PHttpRequest.Bodyages o páginas ASP .Net.

En este caso, la herramienta SAST detecta instancias HttpRequest.Body dentro de una base de código, ya que normalmente así es como se construye una página web. Desafortunadamente, las API son significativamente más complejas, ya que se construyen de manera diferente utilizando una gran cantidad de marcos de terceros (como SpringBoot, Flask, etc.), y la detección de los puntos de entrada en la aplicación es más compleja, lo que genera modelos inexactos y tasas más altas de falsos negativos.

DAST carece de contexto de API

La prueba de seguridad de aplicaciones dinámicas (DAST) es una evaluación de «caja negra» de una aplicación en ejecución mediante el ejercicio de los puntos finales de la aplicación de la misma manera que lo haría un usuario, o un atacante. Las herramientas DAST son expertas en «spidering» una aplicación web para determinar la estructura de la página y los campos de entrada y luego atacar estos campos para identificar vulnerabilidades.

Desafortunadamente, para una API, el escáner DAST no puede enumerar los puntos finales de la API, lo que hace que tales ataques sean imposibles. Algunas herramientas DAST (como OWASP ZAP ) pueden ingerir un archivo OpenAPI / Swagger para iniciar el proceso de spidering.

Incluso en este caso, sin una comprensión más profunda de los puntos finales de la API, las herramientas DAST no pueden proporcionar una evaluación inteligente de la seguridad de la API. Por ejemplo, un escáner DAST no podrá identificar problemas de Autorización de nivel de objeto roto ( BOLA ) a menos que tenga conocimiento del valor del parámetro utilizado para identificar el objeto (para identificar este campo) y luego poder interpretar el respuesta para determinar si el ataque tuvo éxito o si se devuelve algún error.

Desplazamiento a la izquierda en seguridad API

Las herramientas de seguridad han mostrado grandes avances en la última década, sin embargo, el impedimento más importante para las iniciativas de AppSec altamente escalables y efectivas es que las actividades de seguridad se llevan a cabo demasiado tarde en el ciclo de vida de desarrollo de software (SDLC).

Probar demasiado tarde aumenta el costo de la remediación y reduce la probabilidad de que el desarrollador repare. En el caso de las aplicaciones monolíticas típicas, no había otra alternativa que probar al final del ciclo, ya que se requería una instancia funcional y en ejecución de la aplicación para realizar las pruebas, particularmente para DAST.

Con el advenimiento de una arquitectura centrada en API basada en microservicios, es posible probar cada una de las API individuales a medida que se desarrollan en lugar de requerir una instancia completa de una aplicación, lo que permite un enfoque de «cambio a la izquierda» que permite la prueba temprana de componentes individuales. .

Debido a que las API se especifican antes en el SDLC y tienen un contrato definido (a través de una especificación OpenAPI / Swagger), son ideales para un enfoque de prueba de seguridad preventivo de «cambio a la izquierda»: la especificación de API y la implementación subyacente se pueden probar en un IDE de desarrollador como una actividad independiente.

El núcleo de este enfoque son las herramientas de prueba específicas de API, ya que se requiere un conocimiento contextual del contrato de API. Las herramientas SAST / DAST existentes serán en gran parte inadecuadas en esta aplicación; en la discusión sobre las pruebas DAST para detectar BOLA identificamos la incapacidad de la herramienta DAST para comprender el comportamiento de la API.

Al especificar el comportamiento de la API con un contrato, se puede aplicar y verificar el comportamiento correcto, lo que permite un modelo de seguridad positivo (el comportamiento deseado está en la lista blanca) en lugar de un enfoque de lista negra como DAST.

El siguiente diagrama resume las diferencias clave entre las pruebas nativas de seguridad de API y las pruebas DAST, de 42Crunch :

Fuente: 42Crunch.

Las herramientas de prueba de seguridad que he discutido generalmente son operadas por los equipos de seguridad o AppSec de una organización y, a menudo, se imponen a los desarrolladores que pueden encontrarlas inadecuadas para las prácticas de desarrollo modernas, como la integración continua (CI) y la implementación continua (CD), lo que a veces lleva al desarrollador frustración y menores tasas de adopción de herramientas de seguridad.

Por el contrario, es más probable que se adopten y utilicen activamente las herramientas de seguridad de API que pueden agregar valor al esfuerzo de desarrollo (por ejemplo, permitiendo la validación continua de las especificaciones de API) dentro de sus entornos.

Conclusión

¿Tienen las herramientas de prueba de seguridad más tradicionales, como SAST y DAST, un lugar en su entorno de desarrollo de API? Es casi seguro que la respuesta es sí, especialmente si tiene una inversión y un proceso centrados en estas herramientas. Al aprovechar la naturaleza declarativa de las especificaciones de API, una organización inteligente puede utilizar herramientas específicas de API para adoptar un enfoque de «cambio a la izquierda» y aplicar y probar la seguridad de API mediante un modelo de seguridad positivo. Todas las API resultantes producidas se garantizan seguras por diseño, lo que proporciona una base sólida para la pila de aplicaciones de alto nivel (páginas web o aplicaciones móviles) que se pueden probar utilizando herramientas SAST / DAST.

Publicado originalmente en The New Stack

Publicado en por Colin Domoney

     Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Red Hat OpenShift en Azure

Red Hat OpenShift en Azure amplía Kubernetes. La ejecución de los contenedores en producción con Kubernetes requiere herramientas y recursos adicionales. Esto suele incluir la necesidad de trabajar con registros de imágenes, la administración de almacenamiento, las soluciones de red y las herramientas de registro y supervisión, todo lo cual debe tener versiones y probarse junto. La creación de aplicaciones basadas en contenedor requiere un trabajo de integración aún mayor con middleware, marcos, bases de datos y herramientas de CI/CD.

Red Hat OpenShift en Azure combina todo esto en una sola plataforma, ofreciendo facilidad de operaciones a los equipos de TI mientras proporciona a los equipos de aplicaciones lo que tienen que ejecutar.

Red Hat y Microsoft han diseñado, operado y admitido Red Hat OpenShift en Azure de forma conjunta para ofrecer una experiencia de soporte integrado. No hay máquinas virtuales que operar y no se requiere ninguna aplicación de revisiones. Red Hat y Microsoft revisan, actualizan y supervisan los nodos maestros, de infraestructura y aplicación en su nombre. Sus clústeres de Red Hat OpenShift en Azure se implementan en su suscripción a Azure y se incluyen en su factura de Azure.

Puede elegir sus propias soluciones de CI/CD, almacenamiento, red y registro, o bien usar las soluciones integradas para la administración de código fuente automatizada, la creación de contenedores y aplicaciones, implementaciones, el escalado, la administración del estado, etc. Red Hat OpenShift en Azure proporciona una experiencia de inicio de sesión integrada a través de Azure Active Directory.

Beneficios de Red Hat OpenShift en Azure:
      • Cree, implemente y escale aplicaciones en OpenShift con confianza, ARO ofrece clústeres totalmente administrados y de alta disponibilidad a petición, supervisados y gestionados conjuntamente por Microsoft y Red Hat.
      • Es una plataforma de contenedores como servicio (PaaS) con una experiencia de desarrollador y operador notablemente mejorada.
      • Centrese en lo más importante con aprovechando la interfaz de usuario mejorada para la topología y la compilación de aplicaciones en la consola web.
      • Automatice la compilación, las pruebas y la implementación de las aplicaciones con OpenShift Pipelines, un sistema de integración e implementación continuas (CI/CD) sin servidor diseñado para escalarse.
      • Pruebe una experiencia de desarrollo rápido en la nube utilizando Red Hat CodeReady Workspaces.

     Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Red Hat OpenShift Service on AWS

Red Hat OpenShift Service en AWS (ROSA) es un servicio OpenShift totalmente administrado de manera conjunta y respaldado por Red Hat y Amazon Web Services (AWS), con este servicio usted tendrá la libertad de concentrarse en la implementación de aplicaciones mediante:

  • Consolas de creación de clústeres: Para crear un nuevo clúster, comience desde la consola de administración de AWS usando ROSA. Esto se integra con la nueva API y CLI de rosa para aprovisionar clústeres en su cuenta de AWS. La nueva API para la creación de clústeres alivia la carga de implementar manualmente el clúster en su VPC y cuenta existentes.
  • Experiencia de consumo: Una vez creados los clústeres, puede operarlos con la consola web de OpenShift o con el Administrador de clústeres de OpenShift. El servicio ROSA también utiliza API de OpenShift. Estas herramientas brindan una experiencia OpenShift estandarizada para aprovechar sus habilidades y conocimientos de herramientas existentes. Recibe actualizaciones de OpenShift con nuevas versiones de funciones y una fuente común compartida para alinearse con OpenShift Container Platform. ROSA admite las mismas versiones de OpenShift que Red Hat OpenShift Dedicated y OpenShift Container Platform para lograr la coherencia de las versiones.
  • Integración con los servicios de AWS: ROSA puede integrarse con una variedad de servicios de computación, bases de datos, análisis, aprendizaje automático, redes, dispositivos móviles y diversas aplicaciones de AWS, lo que permite a los clientes beneficiarse de los más de 170 servicios de AWS que escalan bajo demanda en todo el mundo. Se puede acceder directamente a estos servicios nativos de AWS para implementar y escalar servicios rápidamente a través de la misma interfaz de administración.
  • Uso del servicio de token de seguridad de AWS: El servicio de token de seguridad (STS) de Amazon Web Services (AWS) es un servicio web global que proporciona credenciales a corto plazo para IAM o usuarios federados. Puede utilizar AWS STS con Red Hat OpenShift Service en AWS (ROSA) para asignar credenciales temporales con privilegios limitados para roles de IAM específicos de componentes. El servicio permite que los componentes del clúster realicen llamadas a la API de AWS mediante prácticas seguras de gestión de recursos en la nube. Puede utilizar la CLI de rosa para crear el rol de IAM, la política y los recursos del proveedor de identidad necesarios para los clústeres de ROSA que utilizan STS.

Red Hat OpenShift en AWS es una plataforma para desarrollar e implementar aplicaciones en contenedores; que permite ser implementado en contenedores simples o en operadores avanzados de Kubernetes, en ellos podemos hacer:

  • Crear proyectos desde la consola web o CLI para organizar y compartir el software que se desarrolla.
  • Utilizar la perspectiva del desarrollador en Red Hat OpenShift Service en la consola web de AWS para crear e implementar aplicaciones fácilmente. Usar la vista Topología para interactuar visualmente con sus aplicaciones, monitorear el estado, conectar y agrupar componentes y modificar su base de código.
  • Utilizar la herramienta CLI para crear aplicaciones de uno o varios componentes fácilmente y automatizar la implementación, la construcción y las configuraciones de rutas de servicio. Abstraer conceptos complejos que le permite a los desarrolladores centrarse en el desarrollo de sus aplicaciones.
  • Crear canalizaciones con los sistemas sin servidor, nativos de la nube, de integración continua y de implementación continua que se ejecutan en contenedores aislados. Utilizar recursos personalizados estándar de Tekton para automatizar implementaciones y están diseñados para equipos descentralizados que trabajan en arquitectura basada en microservicios.
  • Crear aplicaciones en clúster para ROSA; Obtenga información sobre el  Operator Framework y cómo implementar aplicaciones utilizando operadores instalados en sus proyectos.
  • Elija entre diferentes estrategias de compilación (Docker, S2I, personalizadas y canalizadas) que pueden incluir diferentes tipos de materiales de origen (de lugares como repositorios de Git, entradas binarias locales y artefactos externos). Luego, siga ejemplos de tipos de compilación, desde compilaciones básicas hasta compilaciones avanzadas.
  • Crear imágenes de contenedor utilizando ROSA, con la definición de secuencias de imágenes le permitirá recopilar varias versiones de una imagen en un solo lugar a medida que continúa su desarrollo. Los contenedores S2I le permiten insertar su código fuente en un contenedor base que está configurado para ejecutar código de un tipo particular (como Ruby, Node.js o Python).
  • Use los objetos Deployment y DeploymentConfig para ejercer una administración detallada de las aplicaciones. Utilice la página de cargas de trabajo o la CLI para administrar las implementaciones. Aprenda estrategias de implementación personalizadas, recreativas y continuas.
  • Use plantillas existentes o cree sus propias plantillas que describan cómo se construye o implementa una aplicación. Una plantilla puede combinar imágenes con descripciones, parámetros, réplicas, puertos expuestos y otro contenido que define cómo se puede ejecutar o construir una aplicación.

Actividades del administrador del clúster

 

Si bien el equipo de Ingeniería de confiabilidad del sitio (SRE) de Red Hat Site Reliability Engineering (SRE) realiza el mantenimiento del clúster y la configuración del host, el equipo administrador de ROSA cuenta con todas las capacidades para hacerlo además de las siguientes funciones especificas para esta integración:

  • Gestionar administradores dedicados: conceda o revoque permisos a usuarios administradores dedicados.
  • Trabajar con Logging: obtenga información sobre el servicio Red Hat OpenShift Service en AWS Logging y configure los servicios complementarios de registro.
  • Supervisar clústeres: aprenda a utilizar la interfaz de usuario web para acceder a los paneles de supervisión.
  • Administrar nodos: aprenda a administrar nodos, incluida la configuración de grupos de máquinas y el ajuste de escala automático.

     Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Fundamentos de Amazon Web Services (AWS)

Amazon Web Services (AWS) es la plataforma número uno en la nube, cuenta con presencia en más de 245 países, 25 regiones y 81 zonas a nivel mundial, con más de 200 servicios, encontramos en ella servicios desde la implementación de cargas a un clic de distancia, creación, diseño o desarrollo de aplicaciones específicas, infraestructuras moldeables a las necesidades del cliente, análisis de Big Data entre otras, es considerado el ecosistemas más grande y dinámico del sector, siendo el líder por mas de diez años consecutivos. 

Gracias a su ecosistema dinámico le ha permitido a la aplicación llegar a todos los sectores de la economía, en todos los niveles empresariales, demostrando así que sus soluciones están diseñadas para ajustarse a las necesidades propias de cada cliente, de manera ágil, innovadora, rápida y eficaz.

Gracias a su ecosistema dinámico le ha permitido a la aplicación llegar a todos los sectores de la economía, en todos los niveles empresariales, demostrando así que sus soluciones están diseñadas para ajustarse a las necesidades propias de cada cliente, de manera ágil, innovadora, rápida y eficaz.

Seguridad

Contamos con un modelo de responsabilidad compartida entre AWS y el cliente, en el que AWS es responsable por la seguridad de la nube, la infraestructura física, el software y las capacidades de red de los servicios en la nube; El cliente es el responsable de la seguridad en la nube. Es decir, la configuración de los servicios en la nube, el software y la administración de los datos confidenciales.

Para entender la seguridad en la nube, es necesario adoptar el modelo Zero Trust, en el todos los componentes y servicios de las aplicaciones se consideran entidades discretas y potencialmente maliciosas.

Cuando pensamos en la seguridad debemos aplicar todas las medidas de seguridad que tenemos en todos los niveles de nuestro sistema mediante los siguientes tres conceptos.

  • Identity and Access Management (IAM)
  • Seguridad de la red
  • Cifrado de datos

IAM es el servicio responsable de realizar el seguimiento de las identidades y accesos en un sistema.

Con IAM podrán aplicar todos los límites de acceso para los agentes dentro de AWS mediante los siguientes principios.

  1. los PRINCIPIOS especifican a QUIÉNES se les otorgan permisos.
  2. las ACCIONES especifican QUÉ es lo que se debe realizar.
  3. los RECURSOS especifican CUÁLES son las propiedades que se tienen que acceder.

Con Cero trust a IAM adoptamos el principio del mínimo privilegio, se puede aplicar a un principio o a un recurso y están asociadas a un principio que se conoce como políticas basadas en identidades.

La seguridad de la red abarca cualquier sistema, configuración o proceso que salvaguarde el acceso, la capacidad de uso y los recursos accesibles de la red. AWS proporciona una amplia gama de características para asegurar su red, tanto a nivel de red como a nivel de recursos mediante los componente de la red lógica de Amazon Virtual Private Cloud (VPC) mediante:

  • Subredes: una serie de direcciones IP dentro de su VPC.
  • Tablas de enrutamiento: un conjunto de reglas que determinan hacia dónde se dirige el tráfico.
  • Gateway de Internet: un componente que permite la comunicación entre los recursos dentro de su VPC e Internet.

Esto nos ayudara a salvaguardar el trafico de VPC.

El cifrado de datos es el proceso de codificar la información de manera que sea ininteligible para cualquier tercero que no posea la clave que se requiere para descifrar los datos mediante dos tipos:

  1. Cifrado de datos en tránsito: implica la codificación de los datos mientras viajan entre sistemas. Todos los servicios de almacenamiento y de bases de datos dentro de AWS proporcionan puntos de enlace de HTTPS que permiten el cifrado de los datos en tránsito. AWS también le ofrece servicios de red que pueden ayudarlo a aplicar el cifrado de datos en tránsito para sus propios servicios.
  2. Cifrado de datos en reposo: Implica cifrar todos los datos dentro de los sistemas de almacenamiento y las bases de datos de AWS, que admiten el cifrado de datos en reposo, este servicio no cuenta con cargos adicionales por el cifrado y sus gastos de rendimiento son mínimos. 
El pilar de eficacia del rendimiento se centra en cómo puede ejecutar los servicios de manera eficiente y escalable en la nube. Mientras la nube le brinda los medios para gestionar cualquier cantidad de tráfico, requiere que elija y configure los servicios con la escala en mente.

Los servidores eran caros y, a menudo, se implementaban y configuraban manualmente, pasando semanas antes de que se entregue un servidor y se conecte físicamente a su centro de datos. En la nube los servidores son recursos básicos que se pueden aprovisionar automáticamente en segundos. Ningún servidor único debe ser esencial para la operación del servicio.

Nos centraremos en los siguientes dos conceptos eficiencia del rendimiento:

  • Selección
  • Escalado

La selección en AWS es la capacidad de elegir el servicio que más se alinea con la carga de trabajo, con 175 servicios distribuidos en más de docenas de categorías, permitiendo elegir la herramienta adecuada para el trabajo.

La carga de trabajo típica generalmente requiere la selección de alguna de las cuatro categorías principales de servicios en AWS:

  1. La informática: involucra el servicio que procesará los datos (por ejemplo, máquina virtual).
  2. El almacenamiento: involucra el almacenamiento estático de datos (por ejemplo, almacenamiento de objetos).
  3. La base de datos: involucra el almacenamiento organizado de datos (por ejemplo, base de datos relacional).
  4. La red: involucra la forma en que se mueven los datos (por ejemplo, red de entrega de contenido).

Si bien elegir el servicio correcto es clave para comenzar, elegir como escalar es importante para el rendimiento continuo.

AWS posee dos medios primarios de escalado:

    1. Escalado vertical: Implica actualizar la informática subyacente a un tipo de instancia más grande, adicionalmente suele ser más fácil de implementar ya que lo pueden hacer sin que el servicio esté en un clúster. La desventaja es que se encuentra con un límite superior mucho más bajo en comparación con el escalado horizontal. 
    2. Escalado horizontal: Implica más sobrecarga en la implementación, dando que necesita un servicio proxy para direccionar el tráfico a su flota de servicios, necesita llevar a cabo una comprobación dé estado para eliminar las instancias defectuosas del grupo de direccionamiento, así como también seleccionar un algoritmo de direccionamiento específico que sea óptimo para la carga de trabajo. 

Eficacia del Rendimiento

Fiabilidad

A la hora de pensar en la fiabilidad en la nube, es útil pensar en términos de radio de alcance. Se puede pensar en el radio de alcance como el impacto máximo que se puede soportar en caso de un error del sistema. Para crear sistemas fiables, se busca minimizar el radio de alcance de cualquier componente individual.

Cuando se piensa en términos del radio de alcance, el problema del error ya no es una cuestión de si va a ocurrir, sino de cuándo va a suceder.

Para afrontar un error cuando ocurre, se pueden utilizar las siguientes técnicas para limitar el radio de alcance:

  • Aislamiento de errores
  • Límites

 El aislamiento de errores limita el radio de alcance de un incidente mediante el uso de componentes independientes redundantes que se separan a través de zonas de aislamiento de errores. Las zonas de aislamiento de errores contienen el impacto de cualquier error en el área dentro de la zona.

AWS tiene zonas de aislamiento de errores en tres niveles:

      1. Recurso y solicitud: Se dividen en una dimensión determinada, como el ID del recurso, estas partículas se les conoce como celdas que están diseñadas para ser independientes y contener los errores; adicionalmente utilizamos una técnica de partición aleatoria para limitar el radio de alcance.
      2. Zona de disponibilidad: Es una instalación completamente independiente con capacidades dedicadas a la energía, el servicio y la red. Se encuentran geográficamente distantes de otras AZ para evitar errores relacionados con peligros del entorno, como incendios e inundaciones.
      3. Región: Cada región es un centro de datos completamente autónomo, compuesto por dos o más AZ. El aislamiento de errores se consigue a nivel de región mediante la implementación de copias redundantes de los servicios en diferentes regiones.

Los límites son restricciones que pueden aplicarse para proteger a los servicios de una carga excesiva. Son un medio eficaz para limitar el radio de alcance tanto de incidentes externos, como.

Los servicios de AWS tienen límites específicos de servicio por cuenta y por región. A estos límites también se los conoce como cuotas de servicio.
Existen dos tipos de límites:

• límites blandos que se pueden aumentar si se solicita un aumento a AWS.
• límites duros que no se pueden aumentar.

Cada servicio tiene límites diferentes. Para llevar un seguimiento de sus límites y solicitar aumentos, puede utilizar el servicio Service Quotas.

El pilar de excelencia operativa se centra en cómo puede mejorar de manera continua su habilidad para ejecutar sistemas, crear mejores procedimientos y obtener información.

A la hora de pensar en la excelencia operativa en la nube, es útil pensarla en términos de automatización.

El error humano es la principal causa de defectos e incidentes operativos. Cuantas más operaciones automatizadas, menos probabilidades de error humano.

Además de evitar errores, la automatización ayuda a mejorar constantemente los procesos internos. Estos promueven un conjunto de prácticas recomendadas recurrentes que se pueden implementar en toda la organización.

Cuando piensa en las operaciones como automatización, debe centrar la atención en las áreas que actualmente requieren la mayor parte del trabajo manual y que podrían conllevar el mayor nivel de error. También es fundamental implementar un proceso mediante el que se pueda supervisar, analizar y mejorar el trabajo operativo.

Nos centraremos en los siguientes dos conceptos de excelencia operativa: 

  1. Infraestructura como código.
  2. Observabilidad

Es el proceso de administración de la infraestructura mediante archivos de configuración de lectura automática. La IaC es la base que permite automatizar la infraestructura.

En lugar de aprovisionar servicios manualmente, se crean plantillas que describen los recursos que desea. La plataforma de IaC se encarga de aprovisionar y configurar los recursos por usted.

La IaC ofrece una forma declarativa y automatizada de aprovisionar infraestructura. Permite aplicar a la infraestructura las mismas herramientas (p. ej., Git) y procesos (p. ej., revisión de código) que ya aplica al código.

La observabilidad es el proceso de medición del estado interno del sistema. Por lo general se realiza con el objetivo de optimizarlo para que alcance un estado final deseado.

Cuando se trata de excelencia operativa, no se puede mejorar lo que no se mide. Crear una base sólida de observabilidad posibilita conocer el impacto de la automatización en el sistema y mejorarlo continuamente.

Implementar la observabilidad incluye los siguientes pasos:

    1. Recopilación: Es el proceso mediante el que se suman todas las métricas necesarias para evaluar el estado de un sistema.
    2. Análisis: Las métricas recopiladas, puede utilizar una de las numerosas soluciones de bases de datos y análisis que ofrece AWS.
    3. Acción: Una vez que haya recopilado y analizado sus métricas, puede utilizarlas para lograr un resultado o proceso específico.

Excelencia operativa

Optimización de costos

El pilar de optimización de costos ayuda a lograr resultados empresariales mientras se minimizan los costos.

Cuando pensamos en la optimización de costos en la nube, es útil considerar los gastos de la nube en términos de los gastos operativos en lugar de inversión de capital. El gasto operativo es un modelo de pago por uso continuo, mientras que la inversión de capital es un modelo de compra única.

Los costos tradicionales de TI en los centros de datos en las instalaciones fueron mayormente inversión de capital. Paga por toda la capacidad anticipadamente, sin tener en cuenta si terminó de utilizarla. La compra de nuevos servidores puede ser un proceso extenso que implicó obtener certificaciones de varias partes. Esto es porque los costos de los gastos operativos fueron generalmente significativos y los errores costosos. Después de haber hecho una compra, los servidores reales pueden demorar semanas en comenzar.

El modelo de pago por uso introduce los siguientes cambios al proceso de optimización de costos:

  • Pago por uso.
  • Optimización de costos del ciclo de vida

Los servicios de AWS poseen un modelo de pago por uso en el que solo paga por la capacidad que utiliza. A continuación, hay cuatro maneras comunes de optimizar los gastos de la nube cuando paga por uso:

  1. Tamaño correcto: hace referencia a la coincidencia entre el aprovisionamiento del servicio y la configuración para la carga de trabajo.
  2. Tecnología sin servidor: Cuando utiliza tecnologías sin servidor, como Lambda, solo paga por lo que utiliza. Si no se ejecuta Lambda, no se le cobrará. La tecnología sin servidor es el mejor ejemplo de pago por uso.
  3. Reservas: La solicitud de reservas implica comprometerse a pagar por cierta cantidad de capacidad a cambio de un descuento significativo. Para EC2, puede dar lugar a un descuento del 72 % para la informática.
  4. Instancias de spot: Las instancias de spot de EC2 le permiten aprovechar la capacidad de EC2 que no utiliza para ejecutar instancias con hasta un 90 % de descuento cuando se las compara con precios bajo demanda. Esto puede producir enormes ahorros para sus cargas de trabajo tolerantes a errores.

La optimización de costos del ciclo de vida es el proceso continuo para mejorar el gasto en la nube a lo largo del tiempo.

Consiste en el siguiente flujo de trabajo de tres pasos:

  1. Analizar: AWS Cost Explorer lo ayuda a visualizar y revisar el gasto de la nube a lo largo del tiempo, puede desglosar el gasto mediante distintas facetas, como servicio y categoría. Utilice Cost Explorer para obtener información general de alto nivel, así como también informes detallados sobre su factura.
  2. Seguir: Cuando tenga información del gasto general de la nube, puede comenzar a agruparlo según las dimensiones que le interesen. Esto se hace con las etiquetas de asignación de costos. Es necesario que active cada etiqueta que desea seguir.
  3. Optimizar: Una vez que revisó y controló su gasto, puede optimizarlo. La optimización del gasto implica la implementación de técnicas sobre las que hablamos en Pago por uso. La optimización usualmente se realiza como parte de un objetivo presupuestario general.

                                                 Queremos ser su aliado tecnológico

                         Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

WSO2 Choreo – Ofreciendo una plataforma para la innovación

Digital es la palabra más común que escuchamos hoy. Cada organización está en un viaje de transformación digital. Los usuarios internos y externos esperan una experiencia digital perfecta de los productos y servicios que consumen. Además, según un informe reciente publicado por McKinsey & Company, los programas de transformación digital han avanzado siete años después de la pandemia.

La necesidad de transformación digital, a su vez, está impulsando una nueva era de desarrollo de software. Cada vez más empresas se diferencian principalmente a través de sus experiencias digitales, transformándose en empresas de software que crean productos digitales, independientemente de su dominio comercial principal. 

Competir en experiencias digitales únicas

La forma en que las organizaciones centren su desarrollo de software determinará su éxito. En un mundo donde la mayoría de los productos y servicios se pueden replicar, la experiencia se ha convertido en el verdadero factor diferenciador y el compromiso es el mayor impulsor del valor de una empresa. Por esta razón, las organizaciones deben priorizar la construcción de su propia experiencia digital única, que refleje quiénes son y qué representan, cualidades que no se pueden comprar simplemente.

Jeff Lawson (CEO de Twillio) lleva el argumento al siguiente nivel en su libro «Pregúntele a su desarrollador» diciendo «Construya o muera». Estamos de acuerdo. Cada vez más, las organizaciones están descubriendo que su supervivencia depende de su capacidad para crear productos de software que brinden una experiencia digital única y atractiva a sus clientes.

Las organizaciones que comprenden la importancia del software operan con una mentalidad de software, lo que significa que todos tienen que contribuir. Grupos con diferentes habilidades de programación se están uniendo en la creación y entrega de la cadena de suministro de aplicaciones digitales. Algunos lo llaman la democratización del desarrollo de software donde todos son desarrolladores. Capital One es un buen ejemplo de esto. La historia de éxito del banco muestra cómo fusionaron varias habilidades de desarrollo al crear equipos de scrum.

Fomento de la agilidad a través de la nube

Al mismo tiempo, las empresas han reconsiderado sus estrategias para ofrecer productos y servicios digitales; también han estado migrando de servidores locales a la nube para aumentar su agilidad.

Hace casi dos décadas, Google inventó el concepto de computación nativa en la nube impulsada por grandes volúmenes de servidores básicos, y desde entonces ha demostrado ser la mejor manera de acelerar la entrega de nuevas aplicaciones y escalarlas para satisfacer la demanda del mercado. La nube es ahora la solución de preferencia para ofrecer productos y servicios digitales ágiles. La computación nativa en la nube es ahora su propio mundo, con una amplia gama de tecnologías disponibles en varias alternativas, como Cloud Native Computing Foundation (CNCF), Amazon Web Services (AWS) y Microsoft Azure.

El simple hecho de pasar a la nube no es suficiente para aprovechar todo el poder de las tecnologías. Por lo tanto, la modernización de las aplicaciones se ha convertido en un ejercicio paralelo que utiliza conceptos nativos de la nube para garantizar el máximo retorno de las inversiones en transformación digital.

Abordar la complejidad de la nube

Desafortunadamente, la mayoría de los programas digitales fallan. De hecho, Harvard Business Review declaró que la tasa de éxito es inferior al 30%, lo que genera hasta 900.000 millones de dólares de desperdicio.

¿Qué causa la alta tasa de fallas? Principalmente, es la complejidad del espacio del problema, convertir la estrategia en unidades ejecutables, la falta de arquitectura y tecnología heredada. La escasez de miembros del equipo capacitados para manejar esta complejidad hace que sea difícil encontrar y retener una fuerza laboral digital. Además, el desafío de integrar sistemas y subsistemas y el diseño de API adecuado para esas integraciones son problemas tecnológicos que muchas organizaciones encuentran difíciles de resolver. Hay muchas otras razones para esta complejidad, como la ejecución basada en proyectos con presupuestos fijos, la organización centralizada y en capas y la arquitectura de la aplicación. Sin embargo, la creación, integración y administración de API suelen encabezar la lista.

Las organizaciones atrapadas en este ‘medio desordenado’ tienen dificultades para ofrecer el valor de las estrategias digitales que han definido. Para complicar aún más las cosas, los equipos de desarrollo trabajan en silos utilizando diferentes herramientas basadas en su experiencia técnica. Lo llamamos el ‘abismo de código bajo y código pro’. Por un lado, están los desarrolladores ad hoc que aprovechan las plataformas de código bajo. Por otro lado, están los desarrolladores altamente capacitados que continúan codificando utilizando lenguajes de software debido a las limitaciones de las plataformas de código bajo existentes que operan aislando el desarrollo. Sin una plataforma de desarrollo común, el desarrollo colaborativo es casi imposible.

La mayoría de los problemas descritos aquí provienen de dos desafíos principales: la necesidad de reducir la complejidad de la computación nativa en la nube y la necesidad de que participen grupos de desarrollo adicionales. Una plataforma que puede abstraer la complejidad y salvar el abismo del código bajo y el código pro es una gran solución. Tradicionalmente, las organizaciones dedican mucho tiempo, esfuerzo e inversión a crear una plataforma nativa en la nube para el desarrollo de software. No todas las empresas pueden permitirse este enfoque «hágalo usted mismo», sin importar los retrasos resultantes en la comercialización de productos digitales.

Algunos clientes de WSO2 han ido aún más lejos y han creado sus propias plataformas de innovación digital, que abordan desafíos comunes como la complejidad de la tecnología, las brechas de habilidades, la productividad y la agilidad. Trabajando junto con nuestros clientes en más de 1000 proyectos de transformación digital, hemos identificado la integración, el desarrollo de API y la seguridad como las capacidades técnicas básicas requeridas para la mayoría de estas iniciativas. Esto nos inspiró a traer al mercado una plataforma de próxima generación y disponible para la innovación digital: Choreo.

Visión general de Choreo
Choreo by WSO2 es una plataforma de integración como servicio (iPaaS) para la innovación, la productividad y la simplicidad, diseñada en la nube para la nube. El corazón de Choreo es Ballerina, el lenguaje de programación de código abierto nativo de la nube introducido por WSO2. Ballerina facilita la producción y el consumo de servicios. Permite de forma única a los desarrolladores crear el mismo código fuente ya sea que utilicen la sintaxis de texto, la sintaxis gráfica (utilizando diagramas de secuencia y diagramas de flujo de código bajo) o ambos simultáneamente. Como resultado, los desarrolladores ad hoc y altamente capacitados pueden colaborar en la creación de aplicaciones de clase empresarial utilizando el mismo idioma.
  

Además, Choreo utiliza tecnologías WSO2 existentes para proporcionar capacidades de integración y administración de API, además de la funcionalidad de administración de acceso e identidad del cliente (CIAM). Como iPaaS, Choreo proporciona un plano de datos disponible y un plano de control para el usuario. Sin embargo, Choreo también admite un modo híbrido al hacer que el plano de datos se ejecute en la implementación de Kubernetes preferida del cliente.

Comenzar con Choreo es fácil. El portal de autoservicio permite a los usuarios traer su inicio de sesión social usando las credenciales de GitHub y Google, o los usuarios pueden usar su correo electrónico y registrarse para obtener acceso gratuito. Choreo proporciona un entorno de desarrollo de extremo a extremo basado en la nube para crear, probar, depurar, ejecutar y administrar tres tipos de aplicaciones nativas de la nube: servicios, API e integraciones.

Un editor gráfico, plantillas predefinidas y asistentes integrados brindan una experiencia perfecta sin código. Al mismo tiempo, un editor de código completo integrado ofrece una rica experiencia de desarrollo de código profesional. Finalmente, las API expuestas por cada tipo de aplicación y los puntos finales de API externos pueden implementarse, descubrirse y consumirse entre sí en el mercado de Choreo. Choreo proporciona una gestión completa del ciclo de vida de las aplicaciones utilizando canalizaciones DevOps profesionales definidas mediante GitOps, tomando los artefactos e implementándolos en Kubernetes.

¿Porqué  Chore es diferente? 

Como se señaló anteriormente, solo Choreo permite a los desarrolladores cambiar entre un editor gráfico y un editor de texto para tener una experiencia simultánea de código bajo y pro-código. El editor visual representa la semántica del código utilizando notaciones de diagrama de secuencia y diagrama de flujo, mientras que el editor de texto proporciona un entorno de desarrollo completamente integrado (IDE). El resultado de ambas experiencias de codificación es un código Ballerina de código abierto; por lo tanto, los cambios del editor visual o textual se reflejan entre sí sin problemas.

A diferencia de otras soluciones de código bajo donde el código fuente es efectivamente una caja negra, con Choreo, las empresas obtienen código bajo sin bloqueo que controlan. Choreo almacena el código Ballerina de código abierto generado en GitHub. Los usuarios pueden clonar el repositorio de Git y desconectar el código, editarlo utilizando herramientas de código abierto disponibles gratuitamente y ejecutarlo en cualquier entorno preferido.

Choreo también ofrece capacidades de observación profunda igualadas por pocas otras ofertas de iPaaS en el mercado. Estas capacidades permiten a los desarrolladores ver los datos de observabilidad tanto en tiempo de diseño como en tiempo de ejecución para solucionar problemas. Además, los datos de observabilidad recopilados se introducen en un motor analítico para proporcionar análisis comerciales.

La inteligencia artificial (IA) integrada en Choreo guía al usuario a través de la experiencia de desarrollo. Primero, Choreo aprende de las actividades históricas y los comportamientos de desempeño con el desarrollo asistido por IA para anticipar la mayoría de las necesidades de un desarrollador. Luego, a medida que los desarrolladores codifican, amplía los límites de la IA para proporcionar comentarios sobre el rendimiento, finalización del código, detección de anomalías y mapeo de datos.

Impacto de negocios

Choreo aporta muchos beneficios comerciales. Las características de código bajo y DevOps de Choreo abstraen las complejidades, pero aún le permiten profundizar cuando lo desee. Choreo permite que los visionarios de cualquier lugar de la organización se conviertan en creadores, llevando una idea del concepto a la realidad en horas, no en semanas, independientemente de su experiencia técnica. Ahora, los equipos empresariales pueden concentrarse en crear excelentes experiencias, aplicaciones y servicios digitales y dejar que Choreo se encargue del resto.

En última instancia, Choreo acelera la transformación de su organización al proporcionar una plataforma para la innovación digital y salvar el abismo de código bajo de código profesional, todo mientras crea un flujo sin fricciones para los desarrolladores profesionales. Con Choreo, la línea divisoria entre negocios y TI finalmente se está desdibujando.

Choreo by WSO2 está disponible hoy como beta pública.

  Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

¿Cómo Ansible está rompiendo los silos culturales con la innovación?

Uno de los principales desafíos que enfrentan los administradores de sistemas, desarrolladores y otros, cuando ejecutan cargas de trabajo en Red Hat Enterprise Linux (RHEL) es cómo optimizar el rendimiento dimensionando correctamente en los sistemas, entendiendo la utilización y abordando los problemas que surgen. Para tomar decisiones basadas en datos sobre estos temas, el administrador o el desarrollador deben registrar las métricas de rendimiento y acceder a ellas.

El seguimiento de métricas de rendimiento con Performance Co-Pilot (PCP) y Grafana puede ser útil en casi cualquier entorno RHEL. Sin embargo, el proceso para configurarlo en una gran cantidad de hosts puede parecer abrumador al principio. Esta es la razón por la que Red Hat introdujo una función de sistema de métricas, que automatiza la configuración de métricas de rendimiento. 

El fondo

Antes de pasar a la demostración, veamos algunos conceptos básicos. Los roles del sistema RHEL son una colección de roles y módulos de Ansible que se incluyen en RHEL para ayudar a proporcionar flujos de trabajo consistentes y agilizar la ejecución de tareas manuales. La función del sistema de métricas le ayuda a visualizar las métricas de rendimiento en su entorno RHEL de forma más rápida y sencilla.

Red Hat admite el kit de herramientas Performance Co-Pilot (PCP) como parte de RHEL para recopilar métricas de rendimiento y Grafana para visualizar los datos. Si aún no está familiarizado con PCP y Grafana, consulte la serie que Karl Abbott publicó recientemente, en particular la parte 1 y la parte 2, que brindan una descripción general de estas herramientas. Además, la página de la serie de publicaciones de rendimiento de RHEL es un centro para nuestras publicaciones relacionadas con el rendimiento de RHEL.

Descripción general del entorno

En mi entorno de ejemplo, tengo un sistema de nodo de control llamado controlnode que ejecuta RHEL 8 y cuatro nodos administrados (dos ejecutan RHEL 8, dos ejecutan RHEL 7).

En este ejemplo, me gustaría instalar, configurar y comenzar a registrar métricas de rendimiento en los cinco de estos hosts usando PCP. También me gustaría instalar y configurar Grafana en el sistema del nodo de control, y que las métricas de rendimiento de los cinco servidores se puedan ver dentro de Grafana.

Ya configuré una cuenta de servicio Ansible en los cinco servidores, llamada ansible, y configuré la autenticación de clave SSH para que la cuenta ansible en controlnode pueda iniciar sesión en cada uno de los sistemas. Además, la cuenta de servicio ansible se ha configurado con acceso a la cuenta raíz a través de sudo en cada host. También instalé los paquetes rhel-system-roles y ansible en controlnode. Para obtener más información sobre estas tareas, consulte la publicación Introducción a los roles del sistema RHEL.

En este entorno, estoy usando un nodo de control RHEL 8, pero también puede usar Ansible Tower como su nodo de control de funciones del sistema RHEL. Ansible Tower proporciona muchas funciones y capacidades de automatización avanzadas que no están disponibles cuando se utiliza un nodo de control RHEL. Para obtener más información sobre Ansible Tower y su funcionalidad, consulte esta página de descripción general.

Definición del archivo de inventario y las variables de función

Necesito definir un inventario de Ansible para enumerar y agrupar los cinco hosts que quiero que configure el rol del sistema de métricas.

Desde el sistema de controlnode, el primer paso es crear una nueva estructura de directorio:

Estos directorios se utilizarán de la siguiente manera:

  • El directorio de métricas contendrá el libro de jugadas y el archivo de inventario.
  • metrics / group_vars definirá las variables de grupo de Ansible que se aplicarán a los grupos de hosts que se definieron en el archivo de inventario.

Crearé el archivo de inventario principal en metrics / Inventory.yml con el siguiente contenido:

Este inventario enumera los cinco hosts y los agrupa en dos grupos:

  • El grupo de servidores contiene los hosts rhel8-server1, rhel8-server2, rhel7-server1 y rhel7-server2.
  • El grupo metrics_monitor contiene el host de controlnode.

A continuación, tendré que definir las variables de función que controlarán el comportamiento de la función de métricas cuando se ejecute. El archivo README.md para el rol de métricas, disponible en /usr/share/doc/rhel-system-roles/metrics/README.md contiene información importante sobre el rol, incluida una lista de variables de rol disponibles y cómo usarlas.

Crearé un archivo que definirá variables para los cuatro sistemas enumerados en el grupo de inventario de servidores creando un archivo en metrics / group_vars / servers.yml con el siguiente contenido:

La variable metrics_retention_days establecida en 7 hará que el rol de métricas configure PCP en los sistemas de nuestro grupo de inventario de servidores y retenga los datos de rendimiento históricos durante siete días. A continuación, crearé un archivo que definirá las variables para el sistema enumerado en el grupo de inventario metrics_monitor creando un archivo en metrics / group_vars / metrics_monitor.yml con el siguiente contenido:

Las variables metrics_graph_service y metrics_query_service indicarán al rol que configure Grafana y Redis, respectivamente. Metrics_retention_days hará que se retengan siete días de datos de rendimiento históricos, los mismos que se configuraron en el archivo group_vars de los servidores.

La variable metrics_monitored_hosts debe establecerse en la lista de hosts remotos que deberían ser visibles en Grafana. En lugar de enumerar los hosts aquí, hago referencia a la variable grupos [‘servidores’], que contendrá la lista de hosts definidos en el grupo de inventario de servidores.

Creando el libro de jugadas

El siguiente paso es crear el archivo del libro de jugadas. El archivo README.md de métricas indica que la función no configura las reglas de firewall, por lo que además de llamar a la función de métricas, también necesitaré tener tareas para configurar las reglas de firewall.

Crearé el manual de estrategias en metrics / metrics.yml con el siguiente contenido:

La primera tarea, Open Firewall para pmcd, abrirá el servicio pmcd en el firewall en los cuatro sistemas enumerados en el grupo de inventario de servidores.

La tarea Open Firewall for grafana abrirá el servicio grafana en el firewall en el sistema único en el grupo de inventario metrics_monitor (el host de controlnode).

La siguiente tarea, Usar la función del sistema de métricas para configurar el registro de métricas de PCP, solo se aplica a los cuatro hosts del grupo de inventario de servidores y llama a la función del sistema de métricas. Según las variables metrics / group_vars / servers.yml, esto hará que PCP se configure en cada uno de estos cuatro hosts, y las métricas de rendimiento se retendrán durante siete días.

La tarea final, Usar la función del sistema de métricas para configurar Grafana, solo se aplica al host único en el grupo de inventario metrics_monitor (el host de controlnode). Las variables metrics / group_vars / metrics_monitor.yml harán que Grafana y Redis se configuren, PCP se configure con un período de retención de siete días y PCP también se configure para monitorear los otros cuatro servidores.

Si está utilizando Ansible Tower como su nodo de control, puede importar este manual de Ansible en Ansible Automation Platform creando un proyecto, siguiendo la documentación proporcionada aquí. Es muy común usar repositorios de Git para almacenar libros de jugadas de Ansible. Ansible Automation Platform almacena la automatización en unidades llamadas Trabajos que contienen el libro de jugadas, las credenciales y el inventario. Cree una plantilla de trabajo siguiendo la documentación aquí.

Solución alternativa para BZ 1967335

En el momento de escribir este artículo, cuando se usa el RPM rhel-system-roles en RHEL 8.4, hay un error (BZ 1967335) que causa problemas al configurar el monitoreo de PCP remoto. Estamos trabajando en una solución dirigida a RHEL 8.5.

Si usa el RPM rhel-system-roles en RHEL 8.4 o versiones anteriores, ejecute los siguientes comandos sed para solucionar el problema.

Ejecutando el libro de jugadas

En este punto, todo está en su lugar y estoy listo para ejecutar el libro de jugadas. Si está utilizando Ansible Tower como su nodo de control, puede iniciar el trabajo desde la interfaz web de Tower. Para esta demostración, estoy usando un nodo de control RHEL y ejecutaré el libro de jugadas desde la línea de comandos. Usaré el comando cd para moverme al directorio de métricas y luego usaré el comando ansible-playbook para ejecutar el libro de jugadas.

Especifico que se debe ejecutar el libro de jugadas metrics.yml, que debe escalar a la raíz (el indicador -b) y que el archivo Inventory.yml debe usarse como mi inventario de Ansible (el indicador -i). Después de completar el libro de jugadas, verifiqué que no hubo tareas fallidas:
También ejecuté el comando pcp y validé que veo los cinco hosts en las secciones pmlogger y pmie de la salida. El motor de inferencia de métricas de rendimiento (pmie) evalúa las reglas utilizando métricas a intervalos regulares y realiza acciones (como escribir advertencias en el registro del sistema) cuando cualquier regla se evalúa como verdadera. Es posible que todos los hosts tarden unos minutos en aparecer en la salida de pcp.
En mis pruebas, descubrí que es necesario reiniciar los servicios pmlogger y pmproxy en el host de Grafana en este punto para garantizar que Grafana funcione correctamente. Este problema se está rastreando en BZ 1978357. Los servicios se pueden reiniciar con este comando:
Iniciar sesión en Grafana

Ahora puedo iniciar sesión en Grafana a través de un navegador web accediendo al nombre de host de los servidores de Grafana en el puerto 3000, que en mi ejemplo será controlnode: 3000.

Se presenta una pantalla de inicio de sesión de Grafana y puede iniciar sesión con admin como nombre de usuario y contraseña.

La siguiente pantalla le pedirá que cambie la contraseña de administrador a una nueva contraseña. Una vez que se ha cambiado la contraseña de administrador, se muestra la interfaz web principal de Grafana.

A continuación, accederé al menú Configuración a la izquierda y haré clic en Fuentes de datos.

En el menú Fuentes de datos, seleccionaré PCP Redis.
Haré clic en la pestaña Paneles de control y, a continuación, en Importar para el panel de PCP Redis: descripción general del host.
A continuación, iré a la opción de menú Paneles de control a la izquierda y haré clic en Administrar
Seleccionaré el panel de PCP Redis: descripción general del host.
Desde este panel, tengo un menú desplegable donde puedo seleccionar cualquiera de los cinco hosts en mi entorno:
Cuando se selecciona un host, se muestran más de 20 gráficos de rendimiento diferentes. Tenga en cuenta que las métricas pueden tardar un par de minutos en aparecer en sus hosts si accede inmediatamente a Grafana después de ejecutar la función de métricas. Esto se debe a que las métricas que utilizan contrasemántica requieren al menos dos muestras antes de que se puedan mostrar, por lo que con el intervalo de muestreo predeterminado de un minuto, tomará dos minutos recolectar las dos muestras iniciales.
Conclusión

El rol del sistema de métricas puede ayudarlo a implementar rápida y fácilmente la supervisión de métricas de rendimiento en su entorno RHEL. Con esta información, podrá tomar decisiones basadas en datos sobre los sistemas de dimensionamiento adecuado y podrá utilizar los datos proporcionados para abordar mejor los problemas de rendimiento que surjan.

Para obtener más información sobre PCP en RHEL 8, revise los capítulos de supervisión y gestión del estado y rendimiento del sistema.

Hay muchas otras funciones del sistema RHEL que pueden ayudar a automatizar otros aspectos importantes de su entorno RHEL. Para explorar roles adicionales, revise la lista de roles del sistema RHEL disponibles y comience a administrar sus servidores RHEL de una manera más eficiente, consistente y automatizada hoy.

En mis pruebas, descubrí que es necesario reiniciar los servicios pmlogger y pmproxy en el host de Grafana en este punto para garantizar que Grafana funcione correctamente. Este problema se está rastreando en BZ 1978357. Los servicios se pueden reiniciar con este comando:
Autor:

Brian Smith es un Gerente de Producto en Red Hat enfocado en la automatización y administración de RHEL. Ha estado en Red Hat desde 2018, anteriormente trabajó con clientes del sector público como Technical Account Manager (TAM).

                                                    Queremos ser su aliado tecnológico

                 Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Acelere su transformación digital con Red Hat Ansible

Escrito por: Catalina Martínez | Key Account Manager | Abril 2020

¿Qué es la automatización TI?

La automatización de TI o automatización de la infraestructura tecnológica, es un factor clave en las empresas, que impulsa la eficiencia operativa y la optimización en un entorno de TI acelerando la transformación digital. Consiste en utilizar un software para crear políticas y procesos, reduciendo costos, complejidad, errores o reemplazando la interacción manual con sistemas de TI, permitiendo aprovisionar y administrar la infraestructura por medio del uso de plantillas definidas por un software y APIs. Al automatizar los procesos manuales, las operaciones de TI aumentan sus niveles de productividad.

La automatización tiene un efecto multiplicador que beneficia a los profesionales de TI, ya que les permite abordar desafíos comunes como:

  • Errores, riesgos y costos elevados que se relacionan con tareas rutinarias y procesos manuales.
  • Dificultad para llevar a cabo operaciones a escala.
  • Flujos de trabajo y operaciones poco eficientes.
  • Dificultad para monitorear los cambios, la demanda y el tamaño de la infraestructura.
  • Falta de tiempo para concentrarse en iniciativas de gran valor.
  • Y falta de conexión entre los equipos que utilizan procesos complejos para resolver problemas comunes.

La automatización puede aplicarse a cualquier elemento que se encuentre disponible en un dispositivo o recursos, como: aplicaciones, infraestructura, dispositivos en la red, servidores y almacenamiento, incluso a la gestión de la configuración.

Las tareas y funciones de automatización abarcan tecnologías como son los contenedores, los clústeres, y metodologías como DevOps en entorno de nube híbrida, multicloud, edge computing y seguridad.

Adopte una estrategia de automatización para modernizar su empresa

Desde TICXAR impulsamos soluciones y herramientas innovadoras que se ajustan a su mentalidad y enfoque de trabajo. Queremos fortalecer sus procesos de modernización y ayudarlo a definir una estrategia de automatización sostenible que guíe el diseño, evaluación, planificación y la adaptación. Red Hat Ansible Automation Platform es una herramienta que se centra en la facilidad de uso, desarrollo y seguridad de TI.

La suite de Ansible Automation está compuesta por Red Hat Ansible Tower y Red Hat Ansible Engine, con características y funciones basadas en el software como servicio (SaaS) para aumentar la eficacia en las empresas.

1. Red Hat Ansible Tower

Es el componente encargado de administrar la tecnología de Ansible, permitiendo al departamento de TI gestionar las configuraciones, preparar los sistemas, desarrollar y coordinar un efectivo workflow, implementar de forma segura las aplicaciones supervisando y gestionando el ciclo de vida incluidos los siguientes aspectos:

  • Implementación de código.
  • Automatización de los diseños.
  • Gestión de los certificados.
  • Reinicio de los servicios.
  • Pérdida de los recursos.

También permite gestionar entornos físicos y virtuales de diferentes proveedores y coordinar los siguientes elementos:

  • Sistemas operativos: Red Hat Enterprise Linux, Windows, Ubuntu, etc.
  • Servidores: HP, Dell, Cisco, etc.
  • Nubes: Amazon Web Services, Microsoft Azure, Google Cloud Platform, DigitalOcean, CloudStack, OpenStack, Rackspace, Packet, etc.
  • Infraestructuras: Red Hat OpenShift, VMware, NetApp, Kubernetes, Jenkins, JBoss, Docker, etc.
  • Redes: Arista, Cisco, Juniper, F5, Palo Alto, etc.

2. Red Hat Ansible Engine

Gracias a las características de Ansible Engine, las organizaciones tienen la posibilidad de acceder a una robusta tecnología empresarial, la cual puede ser aprovechada al máximo por los entornos DevOps, permitiendo acceder a herramientas e innovaciones disponibles.

Ejecute los playbooks de Ansible (lenguaje de automatización) para orquestar sus comandos, scripts y tareas programadas, facilitando la adopción e implementación de DevOps con mayor rapidez y eficiencia.

¿Sabías qué?

Las empresas que han adoptado una estrategia de automatización con Red Hat han logrado superar desafíos de TI, mejorando sus procesos actuales:

  • El 68% de los equipos de gestión de la infraestructura son más productivos.
  • El 25% de los equipos de seguridad son más eficientes.
  • Les ha permitido aumentar en un 135% la cantidad de aplicaciones desarrolladas por año.
  • Reducir del 53% en el downtime imprevisto.
  • Y generar un retorno sobre la inversión en un 99% anual.

La automatización desempeña un papel clave en la transformación digital y es un motor en la innovación y modernización de las compañías.

 

                                                       Queremos ser su aliado tecnológico

                        Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Contáctanos

Open Banking versión 2.0

Como facilitador de la banca abierta, nuestro trabajo es hacer que la colaboración y la innovación impulsadas por API (es decir, una verdadera transformación digital) entre usted y sus socios sea lo más fácil posible.

Nuestra versión de octubre de 2020 simplifica la ampliación de sus capacidades de banca abierta. Nos complace anunciar el soporte compatible con los estándares para la arquitectura de microservicios y varias mejoras más para ayudarlo a crear nuevos casos de uso de banca abierta con mayor facilidad. Con estas nuevas capacidades, WSO2 Open Banking 2.0 mejora la forma en que ayudamos a sus desarrolladores y equipos comerciales a crear, implementar rápidamente, administrar y monetizar API que agregan valor real para sus equipos internos, socios y consumidores.

Acelerado por la adopción más amplia por parte de los consumidores de casos de uso de banca abierta y los impactos de los bloqueos de COVID a nivel mundial, cada vez más bancos están considerando la banca abierta como un aspecto clave de su transformación digital. En este contexto, nuestros equipos ayudaron a un banco con sede en Londres a superar la tecnología heredada, mantener sus API en funcionamiento las 24 horas del día, los 7 días de la semana y expandir su base de clientes objetivo a través de socios a los millennials exigentes que exigen banca en cualquier momento. Otro cliente de la subsidiaria de CMA9 ahora está enfocado en duplicar los proveedores de terceros (TPP) incorporados a ellos en los próximos meses. También pusimos en línea a los bancos australianos con el derecho de datos del consumidor, cumpliendo plenamente a tiempo, y les permitimos crear casos de uso avanzados de banca abierta listos para usar.

Estos casos de uso han sido posibles basados no solo en nuestro compromiso de ofrecer banca abierta sobre la base de la tecnología de integración y gestión de API líder en la industria. Nuestra documentación actualizada constantemente, soporte y entrega altamente receptivos, y consultoría de banca abierta, ayudan a sus equipos a comprender nuestra tecnología y, lo que es más importante, cómo implementarla de manera más efectiva junto con una estrategia de banca abierta efectiva.

Microservicios

La solución ahora ofrece compatibilidad con estándares de banca abierta para la puerta de enlace API descentralizada, centrada en el desarrollador y nativa de la nube de WSO2 para microservicios. Esto agrega una amplia escalabilidad a la innovación de productos y servicios basada en API del banco. Las implementaciones de microgateway se basan en Docker y Kubernetes, lo que simplifica enormemente el proceso de creación, implementación y protección de API dentro de arquitecturas de microservicios distribuidos.

La arquitectura de microservicios permite reemplazar cientos de aplicaciones empresariales dentro del banco con miles de microservicios. La capacidad de crecimiento exponencial en la creación de servicios basados en API ofrece un potencial mucho mayor de éxito comercial para los esfuerzos de innovación colaborativa del banco entre equipos internos y socios.

Cumplimiento actualizado

Los estándares de datos del consumidor versión 1.3.1

  • Soporte de flujo de API para CX Guidelines versión 1.3.0, que incluye Identifier First Authentication junto con SMS OTP como segundo factor.
  • Capas adicionales de seguridad introducidas en el flujo de autenticación para prevenir ataques, incluido el ataque de enumeración y la OTP por fuerza bruta.
  • La API de administración está protegida con la autenticación JWT, lo que permite que solo la llame el Registro CDR y que contenga el punto final de actualización de metadatos y el punto final de obtención de métricas.
  • Todas las llamadas a la API se regulan de acuerdo con los requisitos no funcionales con umbrales establecidos utilizando las métricas TPS, número de llamadas y número de sesiones por día.
  • Soporte para la API de acuerdos de CDR, que facilita la revocación de un acuerdo de uso compartido existente utilizando el ID de acuerdo de CDR.
  • Se admiten los consentimientos concurrentes, lo que permite múltiples consentimientos para la misma combinación de client_id y user_id.
  • Soporte para el punto final de autorización empujado.
  • Soporte para los requisitos de informes reglamentarios.

Open Banking Standard de la Entidad de Implementación de Banca Abierta versión 3.1.5

  • Actualizaciones de las API del servicio de cuentas, pagos y confirmación de fondos (CoF).
    Soporte para las últimas Pautas de experiencia del cliente y Pautas operativas.
  • Sondeo agregado que permite que un TPP solicite un conjunto agregado de revocaciones de acceso y otros eventos de acceso a la cuenta relacionados con múltiples consentimientos de acceso de múltiples Usuarios de servicios de pago (PSU) durante un período específico.
  • Soporte para informes de información de gestión versión 3.1.2.
  • La validación de la firma JWS ahora se aplica ya que la exención 007 (que indicó que los ASPSP y los TPP no deben validar la firma del mensaje) ya no es efectiva.

Habilitación de capacidades de Open Banking avanzadas y premium
Capacidades comerciales

  • Soporte para la monetización API lista para usar.
  • Producción de API que permite a los usuarios integrar varias API y exponerlas como un solo producto.
  • Vea nuestro seminario web sobre las mejores prácticas en la producción de API.

UX mejorada y simplificación de los flujos de trabajo

  • Compatibilidad con API GraphQL que permite administrar servicios GraphQL como API.
  • Una interfaz de usuario renovada basada en ReactJS que ofrece más flexibilidad para los usuarios y desarrolladores.
  • Un nuevo portal de usuario que permite a los usuarios administrar sus preferencias relacionadas con la cuenta de usuario con más comodidad.
  • Un modelo de configuración de archivo único que reduce el alcance de errores humanos y mejora la experiencia del usuario.
  • Validación del esquema de API con la capacidad para que los usuarios utilicen sus definiciones de API abierta y apliquen validaciones de solicitudes y respuestas sin trabajo adicional.
  • API Mocking, que permite la creación de prototipos de API utilizando una carga útil simulada generada para scripts en línea.
  • Autorización basada en alcance para API REST internas que utilizan flujos comunes de OAuth2.

Seguridad

  • Autenticación sin contraseña con FIDO2 que aumenta su capacidad para combatir el phishing.
  • La autenticación JWT permite a los usuarios utilizar tokens autónomos al invocar API.
  • Detección y notificación de bots, incluida la detección de análisis de contexto y análisis de servicios internos.
  • Soporte para claves API, que se puede configurar a través del Portal para desarrolladores.
 

Para mayor información puede ver los siguientes webinars de ¿Qué hay de nuevo con WSO2 Open Banking? 

Articulo tomado de: «Imesh Umayanga,(26 de octubre de 2020), de la pagina web de WSO2, recuperado de https://bit.ly/3a2oxyu»

Para leer el articulo en su idioma original 

Haz clic aquí