Résumé coaching 9

ANALYSE DE SECURITE
+ Le groupe a effectué et documenté sur le wiki une analyse de sécurité correcte, en identifiant les biens à protéger et en estimant les menaces et les risques associés.
+ Le groupe a identifié des contre-mesures adéquates pour l'ensemble des menaces identifiées.  
+ Le groupe connait et documente les limites de son travail de sécurisation (risques résiduels, …)
+ Le groupe a réfléchi au suivi des aspects sécurité du projet tout au long du cycle de vie du projet
+ Un diagramme de flux de données est attendu
	
SECURISATION	
+ Le groupe a mis en place les éléments de sécurité demandés dans le cadre du cours. Le groupe justifie et implémente correctement les mesures de sécurité au niveau du serveur (Utilisation https, version à jour / patchée, réflexion sur le hardening du serveur -par ex : pas d’autre port ouvert-, gestion des connexions et sessions, disponibilité, …), au niveau logiciel ( Librairies / Framework utilisés à jour, XSS, SQLi,gestion/stockage des mots de passe, ... ) et de la DB ( Inaccessible de l’extérieur, permissions / rôles définis adéquatement, backup, …)
	
VALIDATION DE LA SECURITE
+ Les étudiants ont utilisé des outils extérieurs pour valider la sécurisation de leur site, et présentent les résultats sur le wiki
+ Les étudiants ont compris, interprété et pris en compte les retours donnés par les outils extérieurs et corrigé les failles de sécurité éventuellement identifiées
	
ASPECTS LEGAUX	
+ Le wiki présente les contraintes légales auquel est soumis le site web (notamment RGPD)
+ Le wiki présente ce qui a été mis en place, ou aurait dû être mis en place, pour respecter le prescrit légal (traitement des données, backup, …)

1. Analyse de la sécurité

1.1 Biens à protéger

• La base de donnée n'est pas manipulable autrement que via SSH et les méthodes de la backend, qui tournent derrière un proxy_reverse
• Les connexions BACKEND + FRONTEND tournent sur HTTPS OBLIGATOIRE avec certificats Let's Encrypt
• Le serveur est armé d'un fail2ban
• Le serveur est configuré avec ufw (pare-feu limité par ports)

1.2 Risques

• Serveur accessible via SSH si attaquant connait mot de passe (même si sécurité fail2ban)
• Injection SQL

1.3 Contre-mesures

• Fail2ban + ufw + proxy_reverse pour sécuriser communications
• Impossibilité d'insérer dans la backend du SQL car uniquement appel de fonctions & procédures possibles

1.4 Suivi de la sécurisation

• Que dire...

1.5 Diagramme de flux de données

• Communication simple: base de donnée <-> backend <-> frontend (le frontend ne communiquera jamais avec la base de donnée lui meme)

3. Validation de la sécurité

• Vérification dans Wireshark si les logins sont affichés en clairs: tout est haché et chiffré
• Les mots de passe coté BDD sont hachés et ont un salt, donc meme lecture en BDD ne donne pas mot de passe

4. Cadre légal

4.1 Contraintes légales

[Présentation des contraintes légales s'appliquant à votre application]

4.2 Mise en oeuvre de ces contraintes

[Explication de ce qui a été mis en place pour respecter le cadre légal dans le cadre de ce projet]

5. Bilan et Limites

[D'après vous, est-ce que la sécurisation mise en place est suffisante? Pourquoi? Quelles sont les limites ? Et les améliorations à envisager ?]