Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Meilleures pratiques en matière de sécurité pour les applications

Conseils pour préparer une application sécurisée à partager sur GitHub Marketplace.

Si vous suivez ces bonnes pratiques, vous allez plus facilement proposer une expérience utilisateur sécurisée.

Autorisation, authentification et contrôle d’accès

Nous vous recommandons de créer une application GitHub plutôt qu’une application OAuth. Les applications GitHub constituent le moyen officiellement recommandé pour l’intégration à GitHub, car elles offrent des autorisations beaucoup plus précises pour accéder aux données. Pour plus d’informations, consultez « Différences entre les applications GitHub et les applications OAuth ».

  • Les applications doivent utiliser le principe du privilège minimum et ne doivent demander que les étendues OAuth et les autorisations d’application GitHub dont l’application a besoin pour effectuer ses fonctionnalités prévues. Pour plus d’informations, consultez Principe du privilège minimum dans Wikipédia.
  • Les applications doivent fournir aux clients un moyen de supprimer leur compte, sans avoir à envoyer un e-mail ou à appeler un technicien.
  • Les applications ne doivent pas partager de jetons entre différentes implémentations de l’application. Par exemple, une application de bureau doit avoir un jeton distinct d’une application web. Les jetons individuels permettent à chaque application de demander l’accès nécessaire pour les ressources GitHub séparément.
  • Concevez votre application avec différents rôles d’utilisateur, en fonction des fonctionnalités requises par chaque type d’utilisateur. Par exemple, un utilisateur standard ne doit pas avoir accès aux fonctionnalités d’administrateurs et les gestionnaires de facturation n’ont peut-être pas besoin d’accéder par envoi (push) au code du référentiel.
  • 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.
  • Tous les services utilisés dans votre application doivent avoir des informations d’identification de connexion et de mot de passe uniques.
  • L’accès aux privilèges Administrateur à l’infrastructure d’hébergement de production ne doit être accordé qu’aux ingénieurs et aux employés qui ont des tâches administratives.
  • Les applications ne doivent pas utiliser les personal access token pour s’authentifier et doivent s’authentifier en tant qu’Application OAuth ou Application GitHub :

Protection des données

  • Les applications doivent chiffrer les données transférées sur l’Internet public à l’aide du protocole HTTPS, avec un certificat TLS valide ou SSH pour Git.
  • Les applications doivent stocker en toute sécurité l’ID client et les clés secrètes client. Nous vous recommandons de les stocker en tant que variables environnementales.
  • Les applications doivent supprimer toutes les données utilisateur GitHub dans les 30 jours suivant la réception d’une requête de l’utilisateur ou dans les 30 jours suivant la fin de la relation juridique de l’utilisateur avec GitHub.
  • Les applications ne doivent pas obliger l’utilisateur à fournir son mot de passe GitHub.
  • Les applications doivent chiffrer des jetons, des ID client et des clés secrètes clients.

Enregistrement et surveillance

Les applications doivent avoir des fonctionnalités de journalisation et d’analyse. Les journaux d’activité d’application doivent être conservés pendant au moins 30 jours et archivés pendant au moins un an. Un journal de sécurité doit inclure :

  • des événements d’authentification et d’autorisation
  • des changements de configuration de service
  • des lectures et écritures d’objets
  • toutes les modifications d’autorisation d’utilisateur et de groupe
  • l’élévation du rôle à l’administrateur
  • un horodatage cohérent pour chaque événement
  • des utilisateurs sources, adresses IP et/ou noms d’hôte pour toutes les actions journalisées

Workflow de réponse aux incidents

Pour offrir une expérience sécurisée aux utilisateurs, vous devez disposer d’un plan de réponse aux incidents clair en place avant de répertorier votre application. Nous vous recommandons d’avoir une équipe de réponse aux incidents de sécurité et d’exploitation dans votre entreprise plutôt que d’utiliser un fournisseur tiers. Vous devez avoir la possibilité de notifier GitHub dans les 24 heures suivant un incident confirmé.

Pour obtenir un exemple de workflow de réponse aux incidents, consultez « Stratégie de réponse aux violations de données » sur le site web de l’Institut SANS. Un court document avec des étapes claires à suivre en cas d’incident est plus utile qu’un modèle de stratégie long.

Workflow de gestion des vulnérabilités et de mise à jour corrective

Vous devez effectuer des analyses régulières des vulnérabilités de l’infrastructure de production. Vous devez trier les résultats des analyses de vulnérabilité et définir une période de temps dans laquelle vous acceptez de corriger la vulnérabilité.

Si vous n’êtes pas prêt à configurer un programme de gestion des vulnérabilités complet, il est utile de commencer par créer un processus de mise à jour corrective. Pour obtenir des conseils sur la création d’une stratégie de gestion des correctifs, consultez cet article TechRepublic « Établir une stratégie de gestion des patchs ».