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 más información, consulta Autorización de aplicaciones de OAuth.
Autorización exhaustiva y duradera
Después de iniciar sesión en un usuario, los desarrolladores de aplicaciones deben realizar pasos adicionales para asegurarse de que el usuario está pensado para tener acceso a los datos del sistema. Cada inicio de sesión requiere comprobaciones nuevas en torno a sus pertenencias, acceso y su estado actual de SSO.
Uso del id durable y único para almacenar el usuario
Cuando un usuario inicia sesión y realiza acciones en la aplicación, debe recordar qué usuario realizó esa acción para concederles acceso a los mismos recursos la próxima vez que inicien sesión.
Para almacenar los usuarios en la base de datos correctamente, use siempre el id del usuario. Este valor nunca cambiará para el usuario o se usará para que apunte a otro usuario, por lo que garantiza que proporciona acceso al usuario correcto. Puedes encontrar el id de un usuario con el punto de conexión de la API de REST GET /user. Consulte "Puntos de conexión de la API de REST para usuarios".
Si almacena referencias a repositorios, organizaciones y empresas, use también sus id para asegurarse de que los vínculos a ellos sigan siendo precisos.
Nunca use identificadores que puedan cambiar con el tiempo, incluidos los identificadores de usuario, los campos de datos dinámicos de la organización o las direcciones de correo electrónico.
Validación del acceso de la organización para cada nueva autenticación
Cuando uses un token de acceso de usuario, debes realizar un seguimiento de las organizaciones para las que está autorizado el token. Si una organización usa el inicio de sesión único de SAML y un usuario no lo ha realizado, el token de acceso de usuario no tendrá acceso a esa organización. Puedes usar el punto de conexión de la API REST de GET /user/installations para comprobar a qué organizaciones tiene acceso un token de acceso de usuario. Si el usuario no está autorizado a acceder a una organización, debe impedir su acceso a los datos propiedad de la organización dentro de su propia aplicación hasta que realice el SSO de SAML. Para obtener más información, vea «Puntos de conexión de la API de REST para instalaciones de GitHub Apps».
Almacenamiento de datos de usuario con contextos organizativos y empresariales
Además del seguimiento de la identidad de usuario a través del campo id, debe conservar los datos de la organización o de la empresa en la que cada usuario está funcionando. Esto le ayudará a asegurarse de que no filtre información confidencial si un usuario cambia los roles.
Por ejemplo:
- Un usuario está en la organización
Mona, que requiere el inicio de sesión único de SAML e inicia sesión en la aplicación después de realizar el inicio de sesión único. La aplicación ahora tiene acceso a lo que haga el usuario dentro deMona. - El usuario extrae un montón de código de un repositorio en
Monay lo guarda en la aplicación para su análisis. - Más adelante, el usuario cambia los trabajos y se quita de la organización
Mona.
Cuando el usuario accede a la aplicación, ¿puede ver el código y el análisis de la organización Mona en su cuenta de usuario?
Este es el motivo por el que es fundamental realizar un seguimiento del origen de los datos que guarda la aplicación. De lo contrario, la aplicación es una amenaza de protección de datos para las organizaciones y es probable que prohibieran la aplicación si no pueden confiar en que la aplicación protege correctamente sus datos.
Verificar el acceso de un usuario a su aplicación
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 más información, consulta Puntos de conexión de API REST para organizaciones.
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 más información, consulta Puntos de conexión de la API de REST para las autorizaciones de OAuth.
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.