Uso de GitHub App en su lugar
Si es posible, considera la creación de una GitHub App en lugar de una OAuth app. En general, se prefieren las GitHub Apps frente a las OAuth apps. Las GitHub Apps usan permisos específicos, proporcionan al usuario más control sobre los repositorios a los que puede acceder la aplicación y usan tokens de corta duración. Estas propiedades pueden mejorar la seguridad de la aplicación, ya que limitan el daño que se causaría si se filtrasen las credenciales de la aplicación.
De forma similar a las OAuth apps, las GitHub Apps pueden usar de todos modos OAuth 2.0, generar un tipo de token de OAuth (denominado token de acceso de usuario) y realizar acciones en nombre de un usuario. No obstante, las GitHub Apps también pueden actuar de manera independiente del usuario.
Para más información sobre las GitHub Apps, consulta "Acerca de la creación de GitHub Apps".
Para más información sobre cómo migrar una OAuth app existente a una GitHub App, consulta "Migración de aplicaciones de OAuth a aplicaciones de GitHub".
Uso de ámbitos mínimos
La OAuth app solo debe solicitar los ámbitos que la aplicación necesita para realizar su funcionalidad prevista. Si alguno de los tokens de la aplicación está en peligro, con esto se limitará la cantidad de daños que pueden producirse. Para obtener más información, vea «Autorización de aplicaciones de OAuth».
Protección de las credenciales de la aplicación
Con un secreto de cliente, la aplicación puede autorizar a un usuario y generar tokens de acceso de usuario. Estos tokens se pueden usar para realizar solicitudes de API en nombre de un usuario.
Debes almacenar el secreto de cliente de la aplicación y los tokens generados de forma segura. El mecanismo de almacenamiento depende de la arquitectura de las integraciones y de la plataforma en la que se ejecuta. Por lo general, debes usar un mecanismo de almacenamiento pensado para almacenar datos confidenciales en la plataforma que estés usando.
Secretos de cliente
Si la aplicación es un sitio web o una aplicación web, considera la posibilidad de almacenar el secreto de cliente en un almacén de claves como Azure Key Vault, o como una variable de entorno cifrada o un secreto en el servidor.
Si la aplicación es un cliente nativo, una aplicación del lado cliente o se ejecuta en un dispositivo de usuario (en lugar de ejecutarse en los servidores), no puedes proteger el secreto de cliente. Debes tener cuidado si planeas acceder a tus propios servicios en función de los tokens generados por la aplicación, ya que cualquier usuario puede acceder al secreto de cliente para generar un token.
Tokens de acceso de usuario
Si la aplicación es un sitio web o una aplicación web, debes cifrar los tokens en el back-end y garantizar que haya seguridad en los sistemas que pueden acceder a los tokens. Considere la posibilidad de almacenar tokens de actualización en un lugar independiente de los tokens de acceso activos.
Si la aplicación es un cliente nativo, aplicación del lado cliente o se ejecuta en un dispositivo de usuario (en lugar de ejecutarse en tus servidores), es posible que no puedas proteger los tokens igual de bien que en una aplicación que se ejecuta en los servidores. Debes almacenar tokens a través del mecanismo recomendado para la plataforma de la aplicación y tener en cuenta que es posible que el mecanismo de almacenamiento no sea totalmente seguro.
Uso del tipo de token adecuado
Las OAuth apps pueden generar tokens de acceso de usuario para realizar solicitudes de API autenticadas. La aplicación nunca debe usar una contraseña de personal access token o GitHub para autenticarse.
Creación de un plan para controlar infracciones de seguridad
Debes tener un plan implementado para poder controlar las infracciones de seguridad de forma oportuna.
En caso de que el secreto de cliente de tu aplicación esté en peligro, tendrás que generar un nuevo secreto, actualizar la aplicación para que utilice el nuevo secreto y eliminar el antiguo.
En caso de que los tokens de acceso de usuario estén en peligro, debes revocar inmediatamente estos tokens. Para obtener más información, vea «Puntos de conexión de la API de REST para las autorizaciones de OAuth».
Verificar el acceso a sus organizaciones a un usuario
Los usuarios externos a la organización o la enterprise pueden acceder a la aplicación OAuth. Si pretende que una aplicación solo la usen los miembros de su organización o enterprise, debe comprobar el estado de la suscripción del usuario cuando el usuario inicie sesión en la aplicación.
Para buscar la lista de organizaciones de las que un usuario es miembro, puede usar el punto de conexión "Enumerar organizaciones para el usuario autenticado". A continuación, puede validar esta lista en una lista de organizaciones aprobadas para la aplicación. Para obtener más información, vea «Puntos de conexión de API REST para organizaciones».
Realización de exámenes de vulnerabilidades normales
Debes realizar exámenes de vulnerabilidades regulares para la aplicación. Por ejemplo, puedes configurar el examen de código y el examen de secretos para el repositorio que hospeda el código de la aplicación. Para obtener más información, vea «Acerca del examen de código» y «Acerca del examen de secretos».
Elección de un entorno adecuado
Si la aplicación se ejecuta en un servidor, comprueba que el entorno del servidor es seguro y que puedes controlar el volumen de tráfico esperado de la aplicación.
Uso de servicios de forma segura
Si la aplicación usa servicios de terceros, se deben usar de forma segura:
- Los servicios usados por la aplicación deben tener un inicio de sesión y una contraseña únicos.
- Las apps no deben compartir cuentas de servicio tales como servicios de correo electrónico o de bases de datos para administrar tu servicio SaaS.
- Solo los empleados con tareas administrativas deben tener acceso de administrador a la infraestructura que hospeda la aplicación.
Adición del registro y supervisión
Considere la posibilidad de agregar funcionalidades de registro y supervisión para la aplicación. Un registro de seguridad debería incluir:
- Eventos de autenticación y autorización
- Cambios a la configuración del servicio
- Escritura y lectura de objetos
- Los cambios de permisos de usuarios y grupos
- Elevación de rol a aquel de administrador
Los registros deben usar marcas de tiempo coherentes para cada evento y registrar los usuarios, las direcciones IP o los nombres de host de todos los eventos registrados.
Habilitación para la eliminación de datos
Si tu aplicación está disponible para otros usuarios, debes darles la posibilidad de eliminar sus datos. Los usuarios no deben tener que enviar un correo electrónico ni llamar a una persona de soporte técnico para eliminar sus datos.