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 ».
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 ».
Vérifier l’accès d’un utilisateur à vos organisations
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 : Même un OAuth app créé par un compte d’utilisateur managé ou organisation avec utilisateurs managés est accessible par les utilisateurs en dehors de l’entreprise.
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.