Utiliser une GitHub App à la place
Si possible, envisagez de créer une GitHub App à la place d’une OAuth app. En général, les GitHub Apps sont préférables aux OAuth apps. Les GitHub Apps utilisent des autorisations de granularité fine, donnent à l’utilisateur davantage de contrôle sur les référentiels auxquels l’application peut accéder et utilisent des jetons à courte durée de vie. Ces propriétés contribuent à durcir la sécurité de votre application, car elles limitent les dommages potentiels en cas de divulgation des informations d’identification de votre application.
Comme les OAuth apps, les GitHub Apps peuvent toujours utiliser OAuth 2.0, générer un type de jeton OAuth (appelé jeton d’accès utilisateur) et effectuer des actions au nom d’un utilisateur. Toutefois, les GitHub Apps peuvent aussi agir indépendamment d’un utilisateur.
Pour plus d’informations sur les GitHub Apps, consultez « À propos de la création d’applications GitHub ».
Pour plus d’informations sur la migration d’une OAuth app existante vers une GitHub App, consultez « Migration d’applications OAuth vers des applications GitHub ».
Utiliser des étendues minimales
Votre OAuth app ne doit demander que les étendues dont elle a besoin pour exécuter les fonctionnalités prévues. Si des jetons pour votre application sont compromis, cela limite la quantité de dommages susceptibles de se produire. Pour plus d’informations, consultez « Autorisation des applications OAuth ».
Autoriser de manière complète et durable
Après la connexion d'un utilisateur, les développeurs d'applications doivent prendre des mesures supplémentaires pour s'assurer que l'utilisateur est censé avoir accès aux données de votre système. Chaque connexion nécessite de nouvelles vérifications concernant les abonnements, l'accès et l'état actuel du SSO.
Utiliser l’unique et durable id pour stocker l'utilisateur
Lorsqu’un utilisateur se connecte et effectue des actions dans votre application, vous devez mémoriser l’utilisateur qui a effectué cette action pour lui accorder l’accès aux mêmes ressources la prochaine fois qu’il se connecte.
Pour enregistrer correctement les utilisateurs dans votre base de données, utilisez toujours l’id de l’utilisateur. Cette valeur ne changera jamais pour l’utilisateur ou sera utilisée pour pointer vers un autre utilisateur. Ainsi, elle garantit que vous fournissez l’accès à l’utilisateur voulu. Vous pouvez trouver l’id de l’utilisateur avec le point de terminaison de l’API REST GET /user. Consultez « Points de terminaison d’API REST pour les utilisateurs ».
Si vous stockez des références aux référentiels, organisations et entreprises, utilisez leur id également pour vous assurer que vos liens restent exacts.
N’utilisez jamais d’identifiants qui peuvent changer au fil du temps, y compris les descripteurs d’utilisateur, les champs de données dynamiques d’organisation ou les adresses e-mail.
Valider l’accès de l’organisation pour chaque nouvelle authentification
Lorsque vous utilisez un jeton d’accès utilisateur, vous devez suivre les organisations pour lesquelles le jeton est autorisé. Si une organisation utilise l’authentification unique SAML et qu’un utilisateur n’a pas effectué d’authentification unique SAML, le jeton d’accès utilisateur n’aura pas accès à cette organisation. Vous pouvez utiliser le point de terminaison de l’API REST GET /user/installations pour vérifier les organisations auxquelles un jeton d’accès utilisateur a accès. Si l’utilisateur n’est pas autorisé à accéder à une organisation, vous devez lui refuser l’accès aux données appartenant à l’organisation dans votre propre application jusqu’à ce qu’il effectue une authentification unique SAML. Pour plus d’informations, consultez « Points d’accès à l’API REST pour les installations GitHub App ».
Stocker les données des utilisateurs dans le contexte de l'organisation et de l'entreprise
Outre le suivi de l’identité de l’utilisateur via le champ id, vous devez conserver les données relatives à l’organisation ou à l’entreprise dont relève chaque utilisateur. Cela vous permettra de vous assurer qu’il n’y a pas de fuite d’informations sensibles si un utilisateur change de rôle.
Par exemple :
- Un utilisateur fait partie de l’organisation
Mona, qui nécessite une authentification unique SAML, et se connecte à votre application après avoir effectué l’authentification unique. Votre application a désormais accès à ce que fait l’utilisateur dansMona. - L’utilisateur extrait un nombre de codes d’un référentiel dans
Monaet l’enregistre dans votre application à des fins d’analyse. - Ultérieurement, l’utilisateur bascule d’une tâche à l’autre et est supprimé de l’organisation
Mona.
Quand l’utilisateur accède à votre application, peut-il toujours voir le code et l’analyse de l’organisation Mona dans son compte d’utilisateur ?
C’est pourquoi il est essentiel de suivre la source des données que votre application enregistre. Dans le cas contraire, votre application devient une menace à la protection des données pour les organisations qui seront susceptibles d’interdire votre application si elles ne peuvent lui faire confiance et ce afin de protéger correctement leurs données.
Vérifier l’accès d’un utilisateur à votre application
Votre application OAuth est accessible par des utilisateurs externes à votre organisation ou à votre entreprise. Si vous désirez qu’une application soit utilisée uniquement par les membres de votre organisation ou de votre entreprise, vous devez vérifier le statut d’appartenance de l’utilisateur lorsque celui-ci se connecte à votre application.
Pour trouver la liste des organisations dont un utilisateur est membre, vous pouvez utiliser le point de terminaison « Lister les organisations pour l’utilisateur authentifié ». Vous pouvez ensuite valider cette liste par rapport à une liste d’organisations approuvées pour votre application. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les organisations ».
Remarque : Sur GitHub.com, même une OAuth app créée par un compte d’utilisateur managé ou organisation avec utilisateurs managés peut être consultée par des utilisateurs extérieurs à l'entreprise.
Sécuriser les informations d’identification de votre application
Avec un secret client, votre application peut autoriser un utilisateur et générer des jetons d’accès utilisateur. Ces jetons peuvent être utilisés pour effectuer des requêtes d’API pour le compte d’un utilisateur.
Vous devez stocker le secret client de votre application et tous les jetons générés de manière sécurisée. Le mécanisme de stockage dépend de votre architecture d’intégrations et de la plateforme sur laquelle elle s’exécute. En général, vous devez utiliser un mécanisme de stockage destiné à stocker des données sensibles sur la plateforme que vous utilisez.
Clés secrètes client
Si votre application est un site web ou une application web, envisagez de stocker votre clé secrète client dans un coffre de clés, comme Azure Key Vault, ou en tant que variable d’environnement chiffrée ou secret sur votre serveur.
Si votre application est un client natif, une application côté client ou s’exécute sur un appareil utilisateur (au lieu de s’exécuter sur vos serveurs), vous ne pouvez pas sécuriser votre clé secrète client. Vous devez faire preuve de prudence si vous envisagez de contrôler l’accès à vos propres services en fonction des jetons générés par votre application, car n’importe qui peut accéder au secret client pour générer un jeton.
Jetons d’accès utilisateur
Si votre application est un site web ou une application web, vous devez chiffrer les jetons sur votre back-end et vous assurer qu’il existe une sécurité autour des systèmes qui peuvent accéder aux jetons. Envisagez de stocker les jetons d’actualisation dans un emplacement distinct des jetons d’accès actifs.
Si votre application est un client natif, une application côté client ou s’exécute sur un appareil utilisateur (par opposition à l’exécution sur vos serveurs), il se peut que vous ne puissiez pas sécuriser les jetons ainsi qu’une application qui s’exécute sur vos serveurs. Vous devez stocker les jetons via le mécanisme recommandé pour la plateforme de votre application, et garder à l’esprit que le mécanisme de stockage peut ne pas être entièrement sécurisé.
Utiliser le type de jeton approprié
Les OAuth apps peuvent générer des jetons d’accès utilisateur afin d’effectuer des requêtes d’API authentifiées. Votre application ne doit jamais utiliser un personal access token ou un mot de passe GitHub pour s’authentifier.
Planifier la gestion des violations de sécurité
Vous devez avoir un plan en place afin de pouvoir gérer les violations de sécurité en temps opportun.
Dans le cas où le secret client de votre application est compromis, vous devez générer un nouveau secret, mettre à jour votre application pour utiliser le nouveau secret, et supprimer votre ancien secret.
Dans le cas où les jetons d’accès utilisateur sont compromis, vous devez immédiatement révoquer ces jetons. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les autorisations OAuth ».
Effectuer des analyses de vulnérabilité régulières
Vous devez effectuer des analyses de vulnérabilité régulières pour votre application. Par exemple, vous pouvez configurer l’analyse du code et l’analyse des secrets pour le dépôt qui héberge le code de votre application. Pour plus d’informations, consultez « À propos de l’analyse du code » et « À propos de l’analyse des secrets ».
Choisir un environnement approprié
Si votre application s’exécute sur un serveur, vérifiez que votre environnement serveur est sécurisé et qu’il peut gérer le volume de trafic attendu pour votre application.
Utiliser les services de manière sécurisée
Si votre application utilise des services tiers, ils doivent être utilisés de manière sécurisée :
- Tous les services utilisés par votre application doivent avoir une connexion et un mot de passe uniques.
- Les applications ne doivent pas partager de comptes de service tels que les services par e-mail ou de base de données pour gérer votre service SaaS.
- Seuls les employés ayant des tâches administratives doivent avoir un accès administrateur à l’infrastructure qui héberge votre application.
Ajouter la journalisation et la supervision
Envisagez d’ajouter des fonctionnalités de journalisation et de supervision pour votre application. Un journal de sécurité peut inclure :
- des événements d’authentification et d’autorisation
- des changements de configuration de service
- des lectures et écritures d’objets
- des modifications d’autorisation d’utilisateur et de groupe
- l’élévation du rôle à l’administrateur
Vos journaux doivent utiliser un horodatage cohérent pour chaque événement et enregistrer les utilisateurs, les adresses IP ou les noms d’hôte pour tous les événements journalisés.
Activer la suppression de données
Si votre application est disponible pour d’autres utilisateurs, vous devez leur donner un moyen de supprimer leurs données. Les utilisateurs ne doivent pas avoir besoin d’envoyer un e-mail ou d’appeler une personne du support technique pour supprimer leurs données.