El seguir estas mejores prácticas te ayudará a proporcionar una experiencia de usuario segura.
Autorización, autenticación, y control de accesos
Te recomendamos crear una GitHub App en vez de una OAuth App. Las GitHub Apps son la forma oficial y recomendada de integrarse con GitHub, ya que ofrecen permisos mucho más granulares para acceder a los datos. Consulta "Diferencias entre aplicaciones de GitHub y aplicaciones de OAuth" para obtener más detalles.
- Las apps deben utilizar el principio del menor privilegio necesario y solo deberán solicitar los alcances de OAuth y permisos de GitHub Apps que dicha app necesite para llevar a cabo su funcionalidad prevista. Para más información, vea Principio de privilegios mínimos en Wikipedia.
- Las apps deben proporcionar a los clientes una forma de borrar su cuenta, sin tener que enviar un correo electrónico o llamar a una persona de soporte.
- Las apps no deben compartir tokens entre las diferentes implementaciones de la misma. Por ejemplo, una app de escritorio debe tener un token separado de aquella que es basada en web. Los tokens individuales permiten a cada app solicitar el acceso necesario a los recursos de GitHub por separado.
- Diseña tu app con diferentes roles de usuario, dependiendo de la funcionalidad que necesita cada tipo de usuario. Por ejemplo, un usuario estándar no debe tener acceso a la funcionalidad de administrador, y los gerentes de facturación podrían no requerir acceso de carga al código de un repositorio.
- 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.
- Todos los servicios que se utilicen en tu app deben contar con credenciales únicas de nombre de inicio de sesión y contraseña.
- El acceso privilegiado de administrador para la infraestructura de alojamiento productiva solo se deberá otorgar a los ingenieros y empleados con obligaciones administrativas.
- Las aplicaciones no deben usar un personal access token para autenticarse y se deben autenticar como una aplicación de OAuth o una aplicación de GitHub:
- Las aplicaciones de OAuth se deben autenticar mediante un token de OAuth.
- Las aplicaciones de GitHub se deben autenticar mediante un JSON Web Token (JWT), un token de OAuth o un token de acceso de instalación.
Protección de datos
- Las apps deben cifrar los datos que se transfieren a través del internet público utilizando HTTPS con un certificado TLS válido o con SSH para Git.
- Las apps deben almacenar las llaves secretas y las ID de los clientes de forma segura. Se recomienda almacenarlos como variables de entorno.
- Las apps deben borrar todos los datos de usuario de GitHub dentro de los 30 días posteriores de recibir una solicitud del usuario para hacerlo, o dentro de 30 días posteriores al final de la relación legal del usuario con GitHub.
- Las apps no deben requerir que el usuario proporcione su contraseña de GitHub.
- Las apps deben cifrar los tokens, ID de cliente y secretos de cliente.
Registro y supervisión
Las apps deben tener capacidad de monitoreo y de ingreso de usuarios. Las bitácoras de las apps deben retenerse por lo menos por 30 días y archivarse por un mínimo de un año. Un log de seguirdad debería incluir:
- Eventos de autenticación y autorización
- Cambios a la configuración del servicio
- Escritura y lectura de objetos
- Todos los cambios de permisos de usuarios y grupos
- Elevación de rol a aquel de administrador
- Marca de tiempo consistente para cada evento
- Usuarios orgien, direcciones IP, y/o nombres de host para todas las acciones registradas
Flujo de trabajo de respuesta a incidentes
Para proporcionar una experiencia segura a los usuarios, debes tener un plan claro de respuesta a incidentes antes de listar tu app. Te recomendamos tener un equipo de respuesta a incidentes para operaciones y de seguridad en tu compañía en vez de utilizar un proveedor tercero. Debes poder notificar a GitHub dentro de las primeras 24 horas de que se confirme un incidente.
Para obtener un ejemplo de un flujo de trabajo de respuesta a incidentes, vea la "Directiva de respuesta de vulneración de datos" en el sitio web de SANS Institute. Un documento corto con pasos claros a tomar en caso de un incidente es más valioso que una plantilla larga de una política.
Administración de vulnerabilidades y flujo de trabajo de parchado
Debes llevar a cabo escaneos de vulnerabilidades frecuentes para la infraestructura productiva. Debes clasificar los resultados de los escaneos de vulnerabilidades y definir un tiempo en el que acuerdes remediar dichas vulnerabilidades.
Si no estás listo para configurar un programa completo de administración de vulnerabilidades, es útil comenzar creando un proceso de parchado. Para obtener instrucciones sobre cómo crear una directiva de administración de revisiones, vea este artículo de TechRepublic "Establecimiento de una directiva de administración de revisiones".