.jpg)
En Mambu, cuando comenzamos a usar API , la autenticación básica (nombre de usuario y contraseña) se consideraba un método confiable de autenticación. Sin embargo, a medida que la tecnología avanzó y creció la demanda de mayor seguridad, la autenticación básica quedó obsoleta. Hoy en día, la mayoría de las empresas de tecnología han eliminado gradualmente la compatibilidad con la autenticación de nombre de usuario/contraseña y han hecho la transición a soluciones más seguras y actualizadas.
La mayoría de los proveedores de API Gateway admiten el mismo conjunto básico de mecanismos de seguridad API, destacando las claves API y OAuth 2.0 como las opciones más destacadas para la autenticación y autorización. Durante los últimos años, hemos estado trabajando en nuestras API . Queríamos compartir lo que hemos aprendido al implementar un modelo de seguridad más potente a través de una implementación personalizada además de las claves API. Explicaremos nuestras opciones y compartiremos las mejores prácticas.
Nuestro viaje con las claves API comenzó hace unos años. En su momento era la mejor solución para nuestras necesidades como Plataforma de Banca en la Nube y las necesidades de nuestros clientes. La razón fue que las claves API son muy simples de usar desde la perspectiva del consumidor:
No puede ser más simple que eso.
Además, en nuestro caso, buscábamos cubrir un caso de uso principal que es autenticar y autorizar la interacción de aplicación a aplicación dentro de un perímetro privado. Y dado que OAuth 2.0 está diseñado principalmente para usuarios "no desarrolladores", que con frecuencia necesitan acceder a API públicas para exponer datos a las aplicaciones web o móviles de los usuarios finales, la elección fue simple.
Hemos introducido las siguientes opciones para brindarles a nuestros clientes medios para aprovechar nuestra clave API con una capa adicional de protección.
Lo ideal sería agregar un tiempo de vencimiento a cada clave API que cree. El TTL (tiempo de vida) recomendado depende de su uso específico y de sus requisitos de seguridad. Puede establecer el tiempo de vencimiento para cada clave API que cree a través de la interfaz de usuario de Mambu o de las API .
Como práctica recomendada, debe cambiar/rotar sus claves API al menos una vez al año o inmediatamente después de cualquier intento de ataque.
La rotación de claves API le permite invalidar claves API específicas utilizando una clave secreta para la autenticación. Cuando se rota una clave a través de nuestro punto final api-consumers-rotatekey , recibirá inmediatamente una clave API de reemplazo y una nueva clave secreta en el cuerpo de la respuesta.
Como práctica recomendada, recomendamos utilizar también la caducidad automática de la clave de consumidor de API en las Preferencias de Access. De esta manera, si olvida especificar un tiempo de vencimiento para la clave de reemplazo en la solicitud de rotación, la clave caducará en el TTL establecido mediante la caducidad automática de la clave del consumidor de API, que anula el TTL establecido mediante una llamada API, lo que garantiza que no terminar con claves que nunca caducan.
Si desea obtener más información sobre cómo establecer el tiempo de vencimiento, rotar claves y generar claves secretas, consulte nuestra documentación de soporte Claves API.
Para mejorar aún más la protección, las Claves API se almacenan mediante un proceso de encriptación, a través de nuestros sistemas de gestión de Claves API, cumpliendo con los más altos estándares de seguridad.
En Mambu, confiamos en nuestra implementación personalizada de claves API y consumidores de API y estamos realizando mejoras continuamente para mantenernos al día con los estándares del mercado y, al mismo tiempo, ser proactivos en la identificación y la vanguardia en las necesidades cambiantes de los clientes. En el transcurso del próximo año, planeamos agregar nuevas capacidades a nuestra solución de autenticación y autorización de API para reforzar aún más la seguridad.
En Mambu, cuando comenzamos a usar API , la autenticación básica (nombre de usuario y contraseña) se consideraba un método confiable de autenticación. Sin embargo, a medida que la tecnología avanzó y creció la demanda de mayor seguridad, la autenticación básica quedó obsoleta. Hoy en día, la mayoría de las empresas de tecnología han eliminado gradualmente la compatibilidad con la autenticación de nombre de usuario/contraseña y han hecho la transición a soluciones más seguras y actualizadas.
La mayoría de los proveedores de API Gateway admiten el mismo conjunto básico de mecanismos de seguridad API, destacando las claves API y OAuth 2.0 como las opciones más destacadas para la autenticación y autorización. Durante los últimos años, hemos estado trabajando en nuestras API . Queríamos compartir lo que hemos aprendido al implementar un modelo de seguridad más potente a través de una implementación personalizada además de las claves API. Explicaremos nuestras opciones y compartiremos las mejores prácticas.
Nuestro viaje con las claves API comenzó hace unos años. En su momento era la mejor solución para nuestras necesidades como Plataforma de Banca en la Nube y las necesidades de nuestros clientes. La razón fue que las claves API son muy simples de usar desde la perspectiva del consumidor:
No puede ser más simple que eso.
Además, en nuestro caso, buscábamos cubrir un caso de uso principal que es autenticar y autorizar la interacción de aplicación a aplicación dentro de un perímetro privado. Y dado que OAuth 2.0 está diseñado principalmente para usuarios "no desarrolladores", que con frecuencia necesitan acceder a API públicas para exponer datos a las aplicaciones web o móviles de los usuarios finales, la elección fue simple.
Hemos introducido las siguientes opciones para brindarles a nuestros clientes medios para aprovechar nuestra clave API con una capa adicional de protección.
Lo ideal sería agregar un tiempo de vencimiento a cada clave API que cree. El TTL (tiempo de vida) recomendado depende de su uso específico y de sus requisitos de seguridad. Puede establecer el tiempo de vencimiento para cada clave API que cree a través de la interfaz de usuario de Mambu o de las API .
Como práctica recomendada, debe cambiar/rotar sus claves API al menos una vez al año o inmediatamente después de cualquier intento de ataque.
La rotación de claves API le permite invalidar claves API específicas utilizando una clave secreta para la autenticación. Cuando se rota una clave a través de nuestro punto final api-consumers-rotatekey , recibirá inmediatamente una clave API de reemplazo y una nueva clave secreta en el cuerpo de la respuesta.
Como práctica recomendada, recomendamos utilizar también la caducidad automática de la clave de consumidor de API en las Preferencias de Access. De esta manera, si olvida especificar un tiempo de vencimiento para la clave de reemplazo en la solicitud de rotación, la clave caducará en el TTL establecido mediante la caducidad automática de la clave del consumidor de API, que anula el TTL establecido mediante una llamada API, lo que garantiza que no terminar con claves que nunca caducan.
Si desea obtener más información sobre cómo establecer el tiempo de vencimiento, rotar claves y generar claves secretas, consulte nuestra documentación de soporte Claves API.
Para mejorar aún más la protección, las Claves API se almacenan mediante un proceso de encriptación, a través de nuestros sistemas de gestión de Claves API, cumpliendo con los más altos estándares de seguridad.
En Mambu, confiamos en nuestra implementación personalizada de claves API y consumidores de API y estamos realizando mejoras continuamente para mantenernos al día con los estándares del mercado y, al mismo tiempo, ser proactivos en la identificación y la vanguardia en las necesidades cambiantes de los clientes. En el transcurso del próximo año, planeamos agregar nuevas capacidades a nuestra solución de autenticación y autorización de API para reforzar aún más la seguridad.
