La couche au-dessus de laquelle la plupart des équipes s'arrêtent.

• Des accès qui se sont accumulés : des identifiants permanents et étendus accordés au lancement parce que les délimiter était plus difficile.
• Un produit sur le point de se voir poser des questions de sécurité, pour la première fois, par le processus d'achat d'un client.
• Un agent, une tâche ou une intégration dont les permissions ont été héritées plutôt que décidées.
• Un comportement que les journaux applicatifs ne peuvent pas expliquer, où la réponse se trouve dans l'environnement d'exécution, le noyau, le système de fichiers ou le réseau.
• Un système qui a besoin d'être durci comme une décision de conception plutôt que comme une étape ajoutée avant le lancement.

Une architecture de référence, c'est-à-dire la forme sur laquelle le travail est conçu, et non un relevé de systèmes livrés. Elle nomme des couches et des responsabilités, jamais des produits : ce qui tourne à une couche donnée est une décision prise avec vous pendant le cadrage, pas ici à l'avance.

• Un modèle d'accès : qui et quoi peut atteindre quel système, avec quel privilège, pendant combien de temps.
• Une gestion des identifiants et des secrets, avec des secrets dans votre coffre et injectés à l'exécution plutôt que commités ou collés.
• Une revue des menaces menée pendant la conception du système, et non appliquée après coup.
• Des décisions de durcissement consignées avec leur raisonnement, pour qu'un contrôle puisse être revu plutôt que deviné.
• Du débogage de bas niveau et système : la cause retracée, et le changement qui la corrige.
• Une liste de contrôle des accès et de la sécurité, remplie pour la mission et rendue à la fin.

• Un accès permanent et étendu accordé au lancement parce que le délimiter correctement était plus difficile.
• Des identifiants dans les sources, dans un fil de discussion ou dans un ticket, où ils survivent à la personne qui les y a mis.
• Un rayon d'impact hérité d'un identifiant pratique plutôt que décidé par quelqu'un.
• Un contrôle qui échoue en mode ouvert, de sorte qu'une dépendance injoignable devient un contournement passé inaperçu.
• Une défaillance récurrente que personne ne sait expliquer, où l'enquête s'arrête à la frontière de l'application.

• La certification de conformité. Aucun audit SOC 2 ou ISO 27001 n'est proposé ni détenu, et un cabinet qui vend le certificat est une autre entreprise.
• Le test d'intrusion comme livrable. Un test indépendant doit rester indépendant ; ici, on construit et on revoit le système plutôt que de l'attester.
• Une revue de sécurité sans autorité pour rien changer, où le rapport est le produit et où rien n'est corrigé.
• Les contrats de réponse aux incidents. Aucune équipe n'est d'astreinte, et promettre un délai de réponse que personne ne peut assurer serait pire que de refuser.
• Tout ce qui exige de publier une affirmation de sécurité avant qu'elle soit vraie. Ce qui est énoncé, c'est la pratique, et elle se vérifie sur /security.

1. 01

   La liste des accès, et leur restitution

   Ce qui a été délivré, à quoi, avec quel privilège, et quand cela a été rendu. L'accès est demandé par système plutôt qu'accordé largement au départ, ce qui fait de sa restitution une liste de contrôle et non un exercice d'archéologie.

2. 02

   Des secrets dans votre coffre, jamais dans le nôtre

   Les identifiants vivent dans votre gestionnaire de secrets et sont injectés à l'exécution pendant toute la mission. Il n'y a pas d'étape de migration à la fin, parce qu'ils n'ont jamais été ailleurs.

3. 03

   Les décisions, avec leur raisonnement

   Chaque contrôle relié à sa raison d'être, pour que votre équipe puisse le revoir plutôt que l'hériter. Une frontière dont la raison est perdue est une frontière que quelqu'un de serviable finira par élargir.

4. 04

   La cause, pas seulement la correction

   Quand le travail était une enquête, ce qui se passait réellement et comment cela a été établi, pour que la prochaine occurrence soit reconnue plutôt que de faire l'objet d'une nouvelle enquête partie de zéro.

• PolitiquePratiques de sécuritéLa pratique d'ingénierie déclarée : accès, identifiants, chemins de déploiement, frontières des données, permissions des agents et passation.
• RéalisationUn gestionnaire d'affichage à privilèges séparésLa réalisation de système d'exploitation, et la preuve que le travail se poursuit réellement sous la couche applicative.
• ArticleChoisir un système d'initUne décision système argumentée en détail, y compris ce qu'elle a coûté, comme exemple de la façon dont ce raisonnement se mène.