M1 Projet de Sécurisation d'un SI¶

1. Logistik¶

A. Séances¶

2x 3 séances pour ce "Projet de Sécurisation d'un SI" :

16-18 Mars
27-29 Avril

B. Group or not group¶

Le job est à faire soit solo soit en duo.

Vous pouvez changer entre la première et la deuxième session.

C. Prérequis tech¶

🖥️ Un hyperviseur à dispo

on devra tous lancer l'infra en local de notre côté
il faudra pop des VMs

📃 Ansible installé sur votre poste

sur VOTRE poste : c'est depuis votre PC que les commandes Ansible sont exécutées
Ansible repose sur SSH, il vous faudra donc une paire de clés

🦊 Un compte Gitlab

une fois votre compte créé, faites moi parvenir votre blaz/email
je vous ajoute au groupe pour avoir accès au dépôt du projet

2. Principe du projet¶

A. La réflexion¶

Mon point de départ de la réflexion c'était :

exploiter le format du cours (2 sessions de 3 séances, espacées d'un mois+)
ne pas faire un projet type, un peu chiant et sans saveur, AD + SIEM/SOC + Pfsense blablabla

B. Le coeur du truc¶

Ce que je vous propose donc :

je vous donne un dépôt Gitlab unique, avec du code d'infra (Ansible essentiellement)
c'est fonctionnel, ça déploie une infra modeste qui fait quelques trucs
vous devez faire des Merge Requests sur le dépôt Gitlab afin de proposer des améliorations

On travaille donc tous sur le même dépôt Gitlab : on fait évoluer la même infra.
L'idée c'est que chacun va avoir le temps de poncer 1 feature, puis de l'intégrer à l'infra.

Pas de pression d'objectif pour monter une énième infra complète en 2 jours.

La branche main sera sacrée (une branche protected dans Gitlab) :

impossible de push directement dessus
ne doit contenir que du code fonctionnel
ne doit contenir que du code maîtrisé, compris, et intégré
doit passer ma validation

Je serai le seul 🐈 à pouvoir merge votre travail (votre branche) sur la branche main : vous soumettez un Merge Request et je l'accepte (ou pas).

Je pense que les bénéfices de ce format sont multiples :

à la fin on va avoir un truc vraiment carré avec chaque groupe qui intègre son ptit bout
on va se heurter à des problématiques de merge : certaines de vos modifs seront ptet contradictoires
un vrai projet de groupe, avec un vrai résultat, ou chaque brique a été pensée et pas juste jetée dans la soupe
des technos cools : du vrai travail avec git+ansible déjà, mais aussi la liberté d'aller sur les trucs de votre choix, avoir le temps de les poncer, avec mon assistance
respectez des bonnes pratiques communes : si ton code est dégueu, ou pas assez uniforme avec le reste, je le refuserai

3. Rendu attendu¶

A. Issues¶

Pour justifier votre travail sur le projet, et organiser les tâches, on va utiliser les features de git et Gitlab.

La feature sur laquelle vous choisissez de bosser doit répondre à un besoin de sécurité de l'infra.

Par "sécurité" : voyez large. C'est à dire : intégrité, disponibilité, confidentialité.

Vous devez créer au moins une issue qui identifie un manquement de sécurité, elle doit être formatée comme suit :

* **I'm submitting a ...**
  - [ ] bug report
  - [ ] feature request

* **What is the current behavior?**

<ton_texte_ici>

* **If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem**

<ton_texte_ici>

* **What is the expected behavior?**

<ton_texte_ici>

* **What is the motivation / use case for changing the behavior?**

<ton_texte_ici>

* **Other information** (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

<ton_texte_ici>

Très largement inspiré des templates que j'ai trouvé sur ce repo.

B. Merge Request¶

➜ A l'issue de chaque session de 3 jours, j'attends au moins 1 Merge Request sur le dépôt, par groupe (solo ou duo).

Donc à priori, ça fait un Merge Request le mercredi 18 Mars et un autre le mercredi 29 Avril.

On peut bien sûr envisager de vous laissez à chaque fois jusqu'au dimanche pour finir le Merge Request...
... mais si j'le refuse faudra continuer à taff pour qu'il soit accepté quoiqu'il arrive.

On peut aussi envisager un travail sur une feature unique sur les 6 séances.
Auquel cas, j'attendrai quand même au bout des 3 premiers jours : les issues + un lien vers la branche où est votre travail.

➜ Les Merge Requests (MR) doivent :

répondre à 1 ou plusieurs issues
évidemment ne contenir que la feature clean, et pas une seule ligne de superflu
avoir des commentaires pertinents pour expliquer certains choix, paramètres, etc
être accompagnés d'un texte qui explique le contenu de la MR et sa pertinence

➜ Le texte qui accompagne la PR doit être formaté comme suite :

* **What kind of change does this PR introduce?** (Bug fix, feature, docs update, ...)

<ton_texte_ici>

* **What is the current behavior?** 

<lien_vers_les_issues_concernées>
<ton_texte_ici>

* **What is the new behavior (if this is a feature change)?**

<ton_texte_ici>

* **Does this PR introduce a breaking change?** (What changes might users need to make in their application due to this PR?)

<ton_texte_ici>

* **Other information**:

<ton_texte_ici>

➜ Contenu de chaque MR

le code soumis évidemment
si nécessaire (genre si t'ajoutes une machine), modifier l'inventaire Ansible
si nécessaire (modification violente du déploiement ?), modifier le README.md
si nécessaire (modification de l'archi), éditer le schéma Excalidraw
toute autre modification nécessaire pour que le repo reste fonctionnel avec un README.md exhaustif

4. Résumé clair de votre job¶

Sur chaque sesison de 3 jours :

if [[ not gitlab_account ]] && Vous créez un compte Gitlab + m'envoyez votre blaz/email pour être ajouté au groupe Gitlab et avoir la visibilité sur notre repo
Vous déployez l'infra sur votre PC (création de VMs + lancement du playbook Ansible principal, suivez le README.md du repo)
Vous identifiez une faiblesse de sécu : dév, infra, réseau, peu importe
Vous créez une (ou plusieurs) issue(s) Gitlab pour expliquer ce soucis
Vous faites un POC dans votre environnement pour palier à ce soucis
Vous créez une branche sur le repo Gitlab, et écrivez le code Ansible pour déployer vos changements dans l'infra
Vous faites un Merge Request pour me proposer les changements

J'ai déjà fait une tite liste avec une ~30aine d'améliorations potentielles, de plus ou moins grande envergure. Je préférerai que la réflexion vienne de vous, mais n'hésitez pas à faire appel à moi, si vous avez la flemme, ou si vous voulez un truc auquel vous auriez pas forcément pensé.