Update howto/security_101.md

howto/security_101.md

@@ -0,0 +1,75 @@
+# Security 101: Quelques bases de sécurité
+
+Le but ici est de donner quelques conseils généraux de sécurité qui est bon à
+respecter le plus possible lors de changements de l'infrastructure ou de
+services.
+La liste ne se veut pas exhaustive, mais permet de donner l'esprit global qu'il
+faut avoir.
+
+## Sécurité des comptes utilisateurs
+
+Que ce soit les membres de l'association, comme les membres actifs, il faut
+prendre les précautions pour s'assurer que ses identifiants ne fuient pas dans
+la nature :
+
+  * **Ne pas avoir de comptes locaux avec des mots de passe actifs.**
+    Un compte avec possibilité d'authentification par mot de passe DOIT être
+    dans l'annuaire LDAP. Cela permet de faciliter le changement de mot de
+    passe et ne pas laisser des mots de passe cassés traîner.
+
+  * **Ne pas partager un compte.**
+    Et oui, on évite de filer son mot de passe à son voisin.
+
+  * **Avoir un mot de passe solide.**
+    `toto2345` n'est pas un bon mot de passe et prend en moyenne moins de 5
+    minutes à être bruteforcée avec
+    [john](https://fr.wikipedia.org/wiki/John_the_Ripper).
+
+  * **Favoriser l'authentification par paire de clées.**
+    Pour les services le permettant (SSH, Git...), il est préférable d'avoir
+    une paire de clé. Une clé privée ne doit jamais quitter le périphérique
+    où elle a été créée (que ça soit un token matériel ou une machine Linux).
+    Il est préférable de protéger la clé privée par un mot de passe.
+    Ainsi si une de vos machine est compromise, vous pouvez révoquer seulement
+    sa clé et tracer où elle a été utilisée.
+
+  * **Favoriser la double authentification.**
+    Pour les services critiques (paiement, accès root...) il est préférable
+    d'ajouter un second facteur d'authentification et d'alerter l'équipe si
+    seulement le premier facteur a réussi mais le second a échoué.
+    Pour les services Web, voir le standard WebAuthn. Pour OpenSSH il existe
+    des intégrations avec des applications de second authentification.
+
+  * **Utiliser un gestionnaire de mots de passe pour les secrets partagés.**
+    Pour les secrets partagés au sein de l'équipe technique, on les chiffre
+    pour les clés privées de chaque administrateur.
+
+## Sécurité des logiciels développés
+
+  * **Ne pas fixer strictement les versions des paquets.**
+    Il faut s'assurer que les contraintes sur les dépendances permettent
+    d'obtenir les mises à jour de sécurité. Souvent il n'est que nécessaire
+    de fixer la version majeure (`~=2.1`, plutôt que `==2.1.1`).
+
+  * **Privilégier le gestionnaire de paquet de la distribution.**
+    La distribution rétroporte les mises à jour de sécurité. Il est donc de
+    bon goût d'utiliser le plus possible ses paquets pour simplifier la mise
+    à jour de l'ensemble de l'infrastructure. 
+
+  * **Utiliser des outils de linting avec des règles de sécurité.**
+    Les bons outils de linting connaissent les patterns pouvant potentiellement
+    se traduire en faille de sécurité.
+
+  * **Lancer le logiciel en non-privilégiés.**
+    Un logiciel ne devrait jamais avoir besoin de `root` ou de `sudo`.
+    Lors de l'écriture du service, on peut également ajouter des protections
+    suplémentaires pour augmenter l'isolation.
+
+## Sécurité de l'infrastructure
+
+  * **Faire ses backups, et vérifier qu'elles marchent.**
+
+  * **Faire des scans des ports ouverts.**
+    Pour cela on peut lancer `nmap` sur la plage d'adresses IP.
+
+  * **Monitorer et alerter.**