1. Analyse de la sécurité

1.1 Biens à protéger

• Le code
• La DB
• le serveur
• Le vps

1.2 Risques

1.2.1 Le Code

Importance :

• Le code source peut contenir des informations sensibles, comme des clés API, des informations d'identification ou des algorithmes propriétaires.
• Toute modification non autorisée du code peut introduire des vulnérabilités ou des comportements malveillants.
• Des attaques comme le déni de service peuvent empêcher l'accès au code ou le rendre inopérant. Risques :
• Injection de code malveillant : Un attaquant pourrait insérer du code malveillant pour compromettre l'application.
• Vol de propriété intellectuelle : Le code source peut être volé, entraînant une perte de propriété intellectuelle.
• Défauts de sécurité : Des failles de sécurité dans le code peuvent être exploitées pour compromettre le système.

1.2.2 La Base de Données

Importance :

• La base de données contient des informations sensibles sur les utilisateurs, comme des données personnelles .
• La corruption ou la modification non autorisée des données peut entraîner des pertes ou des erreurs graves.
• Les données doivent être accessibles en permanence pour le bon fonctionnement de l'application. Risques :
• Fuites de données : Les données sensibles peuvent être volées ou divulguées.
• Corruption de données : Les données peuvent être altérées, rendant les informations erronées ou inutilisables.

1.2.3. Le Serveur

• Assurer que le serveur fonctionne correctement et n'a pas été compromis est essentiel pour maintenir la confiance dans le système.
• Le serveur doit être en ligne et fonctionnel pour garantir l'accès aux services. Risques :
• Accès non autorisé : Des attaquants pourraient obtenir un accès non autorisé au serveur, compromettant ainsi l'ensemble du système.
• Exploitation des vulnérabilités : Les failles dans le logiciel du serveur peuvent être exploitées pour compromettre le système.

1.2.4. Le VPS

Importance :

• Le VPS héberge des données et des applications sensibles qui doivent être protégées.
• La configuration du VPS doivent rester intacts pour garantir le bon fonctionnement des services.
• Le VPS doit être disponible en permanence pour éviter les interruptions de service.

Risques :

• Isolation défaillante : Sur un serveur virtuel partagé, une mauvaise isolation peut permettre à un attaquant d'accéder à d'autres environnements virtuels.

• Accès non autorisé : Des attaquants pourraient obtenir un accès non autorisé au VPS, compromettant la sécurité des données et des applications.

• Exploitation des vulnérabilités : Les failles dans la gestion du VPS ou dans le système d'exploitation peuvent être exploitées pour compromettre le serveur virtuel.

  • avec quelle probabilité
  • et quel impact de l'attaque qui résulterait de cette menace.

Classez ces menaces en fonction du risque.]

1.3 Contre-mesures

1.3.1. au niveau de la DB

• Redémarrage de la base de données lorsque le Dockerfile du backend plante.
• Redirection des données de notre conteneur MongoDB vers notre VPS qui l'héberge.
• Création d'un profil avec un mot de passe sécurisé pour l'accès à notre base de données.
• Mise en place de logs grâce à Docker avec la commande ´docker logs´

1.3.2. au niveau du VPS

• Tous les conteneurs communiquent dans un seul et même réseau pour éviter que les données ne soient accessibles depuis le VPS.
• L'utilisation des micro services permet de prévenir les pertes en cas de panne des conteneurs.
• Chargement des ports.
• Mise en place d'une authentification par clé SSH.

1.3.3. au niveau du server

HTTP only
Pour empêcher l'accès aux cookies par des voleurs via JavaScript (côté client).
réduisez le risque d'attaques de type cross site Scripting, étant donné que le cookie de session ne peut pas être lu ou volé par des scripts malveillants.

Secure
Pour garantir que les cookies ne sont envoyés que sur des connexions HTTPS.
pour protéger les données des utilisateurs contre une attaque de type "man-in-the-middle" sur des réseaux non sécurisés.

Same site
Pour contrôler si un cookie est envoyé avec les requêtes inter-sites.
pour prévenir les attaques de type Cross-Site Request Forgery (CSRF), il est important d'utiliser les directives "Strict" ou "Lax" dans les attributs du cookie.

JWT Mise en place des Jwt contenu dans les cookies.

Requêtes sécurisé Chaque requête get est remplacer par des requêtes post pour que les requêtes pour que les requêtes ne soit pas écrites en claire. De plus, nous ajoutons des vérification qu'on est bien authentifier et qu'on est bien soit Admin, soit Utilisateur. Aussi non on est pas autorisé à accéder au contenu de la requête.

1.3.4. au niveau du code

• Mise en place des codes d'erreur pour éviter l'envoie de données non attendue par des formulaire par exemple.

2. Sécurisation

• Désactivation du mot de passe et mise en place d'un clé RSA pour ce connecter en SSH sur le VPS.
• Mise en place de Fail2Ban.
• Isolation grâce aux Containers Docker.
• Mise en place d'un mot de passe sur la DB.

3. Validation de la sécurité

Nous avons mis en place un système de tokens et de cookies sécurisé, Nous avons aussi mis en place une gestion des ressource de l'api, avec une limitation de requêtes sur un cours l'abs de temps. Nous pouvons aussi voir les logs des container grâce à la commande docker logs et voir l'état des containers avec la commande docker ps ou docker container ls.

4. Cadre légal

4.1 Contraintes légales

• Respect des donnés privées avec le cryptages des données sensible dans la DB tel que le mot de passe.

4.2 Mise en oeuvre de ces contraintes

• Utilisation de la librairie bcrypte de npm pour crypter les données pour qu'elle ne soit pas lisible en claire dans la DB

5. Bilan et Limites

On aurait pu crypté plus de données personnel tel que l'email ou le numéro de téléphone par exemple. Mais en général nous ne voyons pas tellement ce que nous aurions pu mettre en plus en part s'imposer le faite de respecter complétement la norme RGPD.