La sécurité est le point de départ.

• Accès

  Moindre privilège, demandé système par système

  Chaque personne, processus, jeton et intégration reçoit le périmètre le plus étroit qui permette tout de même de faire le travail. L’accès est demandé système par système plutôt qu’accordé largement au lancement, et limité dans le temps lorsque la plateforme le permet.

• Secrets

  Les identifiants restent dans votre coffre

  Les identifiants vivent dans votre gestionnaire de secrets et sont injectés à l’exécution. Ils ne sont jamais commités dans le code source, collés dans une conversation ni envoyés par e-mail.

• Déploiement

  Le chemin vers la production est réversible

  Les livraisons suivent un chemin défini, avec des contrôles à chaque étape, et un retour arrière qui a été éprouvé et non supposé. Les environnements se reconstruisent à partir du code source, de sorte que la reprise est une procédure et non de l’improvisation.

• Frontières

  Les agents et les intégrations reçoivent des permissions explicites

  Ce qu’un agent, une tâche ou une intégration tierce peut lire, écrire et appeler est décidé et consigné, et non hérité de l’identifiant qui se trouvait déjà disponible. Les données qui franchissent une frontière la franchissent délibérément.

• Conception

  La sécurité commence à la conception

  La modélisation des menaces a lieu pendant la conception du système, et non comme une étape de durcissement ajoutée avant le lancement. La forme sûre est la première forme.

• Entrées

  Une entrée hostile est l’hypothèse par défaut

  Tout ce qui franchit une frontière de confiance est traité comme adverse : validé par rapport à un schéma explicite, borné, et rejeté s’il ne convient pas.

• Mode de défaillance

  Échec en mode fermé

  Lorsqu’un contrôle ne peut pas aboutir ou qu’une dépendance est injoignable, l’accès est refusé et non laissé passer. L’arrêt est la valeur par défaut sûre.

• Provenance

  Les décisions sont consignées

  Les choix de sécurité sont enregistrés avec leur raisonnement, de sorte qu’un contrôle peut être rattaché à la raison de son existence et réexaminé au lieu d’être deviné.

• Passation

  L’accès est restitué à la fin

  L’infrastructure tourne dans vos comptes et le code source vit dans vos dépôts tout du long, de sorte que révoquer l’accès est quelque chose que vous pouvez faire sans demander. Ce qui a été émis est restitué à la clôture de la mission, en pointant la liste qui a servi à l’émettre.

L’accusé de réception est un objectif et non un accord de niveau de service : aucune équipe de sécurité n’est d’astreinte, donc aucun délai de réponse fixe n’est promis. Aucune récompense financière n’est offerte. Aucune certification SOC 2 ou ISO 27001 n’est revendiquée et aucune n’est détenue : ce qui est publié sur cette page, c’est la pratique elle-même, ce dont un certificat n’est qu’un substitut. Une recherche de bonne foi qui respecte cette politique est la bienvenue et non sanctionnée.

• PageConfiance et donnéesL’autre moitié de la question : les sous-traitants ultérieurs derrière ce site, ce que chacun détient, combien de temps un message est conservé, et les informations sur l’entité qu’une fiche fournisseur demande.
• ProcessusLe cadre commercialLes règles d’accès et d’identifiants ci-dessus, reprises comme clauses de contrat : accord de confidentialité, propriété intellectuelle, moindre privilège demandé système par système, et accès restitués à la fin.
• DocumentsExemples de livrablesLa liste de contrôle des accès et de la sécurité est l’un des huit formats, présenté avec ce qu’il consigne et le risque qu’il écarte.
• ServiceSécurité et profondeur systèmeLà où cela cesse d’être une politique et devient la mission : frontières d’accès, durcissement, et le débogage qui commence là où s’arrêtent les journaux applicatifs.