- 1. Introduction
- 2. Non statué
- 3. Contraintes
- 4. Exigences
- 4.1. Exigences d’intégrité
- 4.2. Exigences de confidentialité
- 4.3. Exigences d’identification
- 4.4. Exigences d’authentification
- 4.5. Exigences de fédération d’identité
- 4.6. Exigences de SSO et SLO
- 4.7. Exigences de non-répudiation
- 4.8. Exigences d’anonymat et de respect de la vie privée
- 4.9. Exigences sur les habilitations
- 4.10. Exigences de traçabilité et d’auditabilité
- 4.11. Données à conserver pour preuves
- 5. Mesures de sécurité
- 6. RACI & Gouvernance de la Sécurité
- 7. Auto-contrôles de sécurité
Dernière modification : 2025-02-25
Date de la dernière revue globale : <Faire régulièrement des revues complètes de la vue (au moins une fois par an tant que le projet est actif) et mentionner la date ici>
Statut du document : <Indiquer ici le statut de la vue, par exemple 'DRAFT', 'FINALISÉ',…>
La vue sécurité décrit l’ensemble des dispositifs mis en œuvre pour empêcher l’utilisation non-autorisée, le mauvais usage, la modification illégitime ou le détournement des modules applicatifs.
Les autres vues du dossier sont accessibles d’ici.
Le glossaire du projet est disponible ici. Nous ne reprendrons pas ici les termes fonctionnels ou techniques déjà définis.
|
Tip
|
La disponibilité est traitée dans la vue infrastructure. |
|
Tip
|
Mentionner ici les documents d’architecture de référence (mutualisés). Ce document ne doit pas reprendre leur contenu sous peine de devenir rapidement obsolète et non maintenable. |
| N° | Version | Titre/URL du document | Détail |
|---|---|---|---|
1 |
1.0 |
Dispositifs_securite.pdf |
Catalogue de dispositifs de sécurité habilités |
2 |
latest |
Normes sécurité société |
|
3 |
latest |
Explications RGPD |
| ID | Détail | Statut | Porteur du sujet | Échéance |
|---|---|---|---|---|
ES1 |
Il conviendra de valider que les dispositifs anti-CSRF mis en place résolvent également les failles liées au couplage TLS + compression (type CRIME ou BREACH). |
EN_COURS |
Équipe sécurité |
AVANT 2040 |
|
Tip
|
Lister ici les contraintes de sécurité applicables à l’architecture, incluant notamment :
|
Exemple 1 : La politique de gestion des mots de passe devra se conformer à la norme XYZ, incluant une complexité minimale et un renouvellement périodique.
Exemple 2 : Il est formellement interdit à un module de la zone Internet d’accéder directement à la zone Intranet.
Exemple 3 : En application du RGPD, les données utilisateur devront être chiffrées au repos et en transit avec AES-256 et TLS 1.3.
|
Tip
|
Présenter ici les exigences, pas les dispositifs y répondant. Ceux-ci seront détaillés au chapitre 3. Pour les projets particulièrement sensibles, prévoir un dossier d’analyse de risque. Pour cela, utiliser par exemple la méthode EBIOS Risk Manager (Expression des Besoins et Identification des Objectifs de Sécurité). |
|
Tip
|
L’intégrité concerne la justesse, la durabilité et le niveau de confiance des données de l’application. Garantir l’intégrité des données signifie s’assurer qu’elles ne peuvent être altérées ou supprimées de manière involontaire (ex. : crash disque, corruption logicielle, bug applicatif) ou volontaire (ex. : attaque "man-in-the-middle", élévation de privilèges, sabotage interne). ⚠ Ne pas multiplier inutilement les classes de données. Une unique classification pour toute l’application est souvent suffisante. |
| Classe de données | Non intègre (Les erreurs d’intégrité sont tolérées) | Détectable (Les erreurs sont identifiées rapidement) | Maîtrisé (Les erreurs sont corrigées) | Intègre (Aucune altération n’est tolérée) |
|---|---|---|---|---|
Données de la base métier |
X |
|||
Données archivées |
X |
|||
Données statistiques agrégées |
X |
|||
Silo NoSQL des données Big Data (avant consolidation) |
X |
|||
Code source de l’application |
X |
|||
Documents officiels générés (ex. : avis d’imposition PDF) |
X |
|
Tip
|
Exemples de dispositifs associés selon le niveau d’intégrité requis :
|
|
Tip
|
La confidentialité est la garantie que l’information n’est accessible qu’aux personnes autorisées (définition ISO 27018). Bonnes pratiques :
|
| Classe de données | Public (Donnée accessible à tous sans restriction) | Limité (Accessible uniquement aux personnes habilitées) | Réservé (Restreint au personnel interne autorisé) | Privé (Accès strictement individuel) |
|---|---|---|---|---|
Contenu éditorial |
X |
|||
Données de profil utilisateur |
X |
|||
Historique du compte |
X |
|||
Logs techniques des activités |
X |
|||
Données RH (ex. : aides sociales aux employés) |
X |
|
Tip
|
Exemples d’applications des niveaux de confidentialité :
|
|
Tip
|
L’identification permet d'attribuer un identifiant unique à chaque utilisateur, afin de le différencier des autres. Attention : L’identification ne garantit pas que l’utilisateur est bien celui qu’il prétend être. C’est le rôle de l’authentification (exemple : mot de passe, MFA…). |
| Exigence | Description |
|---|---|
Identifiant unique |
Chaque utilisateur doit avoir un identifiant unique et non partageable. Une adresse e-mail personnelle est un bon identifiant. |
Validation de l’identité |
L’existence de l’identité d’un internaute doit être vérifiée avant tout appel de service. |
Pérennité de l’identifiant |
Un identifiant ne doit jamais être supprimé, modifié ou réutilisé, même après la suppression d’un compte utilisateur. |
|
Tip
|
Bonnes pratiques :
|
|
Tip
|
L’authentification vérifie qu’un utilisateur est bien celui qu’il prétend être, en validant son identité à l’aide d’un ou plusieurs facteurs de preuve. ⚠ À ne pas confondre avec l’identification, qui ne fait que distinguer un utilisateur d’un autre sans valider son identité. Cas particuliers :
|
L’authentification peut être basée sur un seul facteur ou être multi-facteurs (MFA) pour plus de sécurité. Les principaux types de facteurs sont :
-
Ce que l’on connaît → Mot de passe, phrase secrète, PIN, donnée métier.
-
Ce que l’on est → Biométrie (empreinte digitale, reconnaissance faciale, ADN, signature…).
-
Ce que l’on possède → Clé privée, token OTP (TOTP, FIDO2, carte à puce), e-mail de validation.
Le tableau ci-dessous indique les facteurs d’authentification requis selon le contexte d’utilisation :
Cas d’authentification |
Mot de passe respectant la politique de sécurité |
Clé publique SSH connue |
OTP par Token |
Biométrie |
Connaissance de données métier |
E-mail avec lien de vérification |
Utilisateur déjà inscrit |
X |
|||||
Création d’un compte |
XX |
X |
||||
Modification du mot de passe |
X |
X |
||||
Accès aux journaux sécurisés |
X |
|||||
Ajout d’un bénéficiaire de virement |
X |
X |
||||
Connexion à l’application mobile Y |
X |
|
Tip
|
Bonnes pratiques :
|
|
Tip
|
La fédération d’identité permet à un utilisateur de réutiliser son identité (credentials) gérée par un Identity Provider (IdP) pour s’authentifier sur plusieurs systèmes indépendants. Contrairement au SSO (Single Sign-On), qui assure une connexion automatique sans nouvelle saisie des identifiants, la fédération ne dispense pas de l’authentification mais centralise la gestion des identités. Exemples courants :
Avantages de la fédération d’identité :
|
Cas d’usage : L’identification et l’authentification des utilisateurs seront externalisées à Auth0, un fournisseur d’identité (IdP) supportant OIDC, SAML et OAuth2.
Objectifs :
-
Centraliser la gestion des identités et éviter la duplication des comptes utilisateurs.
-
Réduire les coûts de développement et d’exploitation liés à l’authentification.
-
Améliorer la sécurité en déléguant l’authentification à un IdP conforme aux normes de sécurité.
|
Tip
|
Le Single Sign-On (SSO) permet à un utilisateur de s’authentifier une seule fois et d’accéder à plusieurs applications sans ressaisir ses identifiants. Le Single Log-Out (SLO) assure qu’une déconnexion depuis une application entraîne automatiquement la déconnexion de toutes les autres applications du même domaine de confiance. Points d’attention :
Bonnes pratiques :
|
Exemple 1 : Pas de besoin de SSO Le portail applicatif repose sur un framework JSR352 qui gère déjà l’authentification unique. Aucun besoin de SSO supplémentaire.
Exemple 2 : Pas de SSO ni de SLO requis L’application fonctionne de manière autonome et ne partage pas d’authentification avec d’autres services.
Exemple 3 : SSO requis pour un environnement intranet
-
Une fois authentifié sur l’une des applications de l’intranet, l’utilisateur ne doit pas avoir à se reconnecter sur les autres applications jusqu’à expiration de la session.
-
Une déconnexion (SLO) depuis une application doit entraîner la déconnexion de toutes les autres applications du domaine.
-
Le protocole choisi sera OIDC avec un Identity Provider interne.
|
Tip
|
La non-répudiation garantit qu’un utilisateur ou une organisation ne peut nier avoir réalisé une action donnée (signature, validation, transaction…). Elle repose généralement sur des mécanismes cryptographiques, notamment la signature électronique et l’horodatage sécurisé. La signature numérique est reconnue légalement par le texte n°2000-230 du 13 mars 2000 du code civil, ainsi que par le règlement eIDAS (UE 910/2014) définissant plusieurs niveaux de signature : - Simple : Vérifie uniquement l’identité de l’émetteur. - Avancée (AES) : Liée de manière unique au signataire et protégée contre toute modification. - Qualifiée (QES) : Conforme aux normes les plus strictes, avec certificat qualifié et dispositif sécurisé. Cas d’usage typiques :
|
| Action ou document signé | Niveau de signature exigé | Origine du certificat client | Origine du certificat serveur |
|---|---|---|---|
Déclaration d’impôt sur le revenu (données X, Y et Z) |
Signature eIDAS qualifiée |
PKI de l’administration fiscale |
Autorité de certification Verisign |
Contrat d’embauche électronique |
Signature eIDAS avancée |
PKI interne de l’entreprise |
PKI externe certifiée eIDAS |
Validation d’un paiement électronique |
Signature eIDAS avancée |
Certificat bancaire du client |
PKI du fournisseur de paiement (ex. : Visa, Mastercard) |
|
Tip
|
Lister les contraintes d’anonymat et de vie privée légale (exigée par le RGPD). Voir [3]. |
Exemple 1 : Aucune consolidation de donnée ne pourra être faite entre les données du domaine PERSONNE et du domaine SANTE.
Exemple 2 : Par soucis de confidentialité en cas d’intrusion informatique, certaines données des personnes seront expurgées avant réplication vers la zone publique : le taux de cholestérol et le poids.
Exemple 3 : aucune donnée raciale, politique, syndicales, religieuse ou d’orientation sexuelle ne pourra être stockée sous quelque forme que ce soit dans le SI.
Exemple 4 : Les données OpenData issues du domaine « logement » ne contiendront que des données consolidées de niveau commune, pas plus précise.
Exemple 5 : En application de la directive européenne « paquet telecom », un bandeau devra informer l’usager de la présence de cookies.
Exemple 6 : En application du RGPD, un consentement explicite des utilisateurs dans la conservation de leurs données personnelles de santé sera proposé.
|
Tip
|
Une habilitation (ou autorisation) permet de contrôler l’accès à une fonction applicative spécifique (également appelée privilège ou permission) pour un utilisateur ou un groupe d’utilisateurs. Exemples de fonctions applicatives :
⚠ Il est recommandé de ne pas multiplier excessivement les fonctions et les rôles afin d’éviter une explosion combinatoire et des coûts de gestion élevés. Bonnes pratiques pour simplifier la gestion des habilitations :
Modèle classique de gestion des habilitations : 
Pseudo-utilisateurs et rôles prédéfinis : Penser à spécifier les utilisateurs génériques tels que :
Délégation d’autorisation (OAuth2, etc.) : Si l’application délègue ou consomme des autorisations via un système externe (OAuth2, OpenID Connect, etc.), il est nécessaire de préciser :
|
Exemple 1 : Les utilisateurs non connectés auront accès à tous les privilèges en lecture seule uniquement.
Exemple 2 : L’application utilisera une gestion des autorisations matricielle basée sur une association [rôles] → [groupes ou utilisateurs]. Le détail des autorisations sera documenté dans les SFD (Spécifications Fonctionnelles Détaillées).
Exemple de matrice de rôles :
| Groupe ou utilisateur | Rôle suppression |
Rôle administration |
Rôle consultation données de base |
|---|---|---|---|
Groupe |
X |
||
Groupe |
|||
Groupe |
X |
X |
X |
Utilisateur |
X |
X |
|
Tip
|
Lister ici les besoins en traçabilité et auditabilité pour détecter et analyser :
⚠ Les traces sont des données nominatives et sensibles. Elles doivent être protégées avec des mécanismes de confidentialité appropriés pour éviter tout abus. Différenciation des types de traces :
Bonnes pratiques :
|
Exemple 1 : Pour le module X, toute action métier (consultation et mise à jour) devra générer une trace métier contenant a minima :
-
L’identité de l’agent.
-
La date et l’heure.
-
En cas de modification : ancienne et nouvelle valeur.
Exemple 2 : Toute intrusion dans le SI devra être détectée dans la mesure du possible et remontée aux équipes de sécurité.
Exemple 3 : Il doit être possible de reconstituer l’historique complet d’un dossier patient à n’importe quelle date.
| Donnée | Objectif | Durée de rétention |
|---|---|---|
Log complet (IP, heure GMT, détail) des commandes passées sur le site |
Prouver que la commande a bien été passée |
1 an |
Date et contenu du mail de confirmation |
Prouver que le mail de confirmation a bien été envoyé |
2 ans |
Contrat d’assurance signé et numérisé en PDF |
Prouver que le contrat a bien été signé |
5 ans |
Avis d’imposition primitif avec signature numérique |
Conserver le montant et la validation de l’impôt |
5 ans |
Dispositifs répondant aux exigences d’intégrité :
| Classe de données | Niveau exigé | Mesures |
|---|---|---|
Données de la base métier |
Intègre |
|
Données archivées |
Détecté |
Génération de checksums SHA-256 des backups et validation lors des restaurations. |
Données calculées D1 |
Maîtrisé |
Stockage d’un checksum SHA1, relance automatique du calcul par batch en cas de divergence dans un délai de 24h. |
Silo NoSQL des données Big Data avant consolidation |
Non intègre |
Pas de mesure particulière, pas de backup, ces données sont temporaires et recalculables. |
Sources de l’application |
Intègre |
|
Avis d’imposition PDF |
Intègre |
|
Dispositifs répondant aux exigences de confidentialité :
| Classe de données | Niveau exigé | Mesures |
|---|---|---|
Contenu éditorial |
Public |
Échanges sécurisés via HTTPS (TLS 1.2+), pas d’authentification requise. |
Profil du compte du site Web |
Limité |
|
Historique du compte |
Réservé |
|
Logs des activités de l’internaute |
Réservé |
|
Données RH aides sociales aux employés |
Privé |
|
|
Tip
|
⚠ Confidentialité des données dérivées : ✔ Chiffrement des backups :
✔ Chiffrement des données clientes pour les applications lourdes :
|
Dispositifs répondant aux exigences d’identification :
|
Tip
|
Décrire ici le mode d’identification des utilisateurs et des systèmes (batchs, API, services externes). Préciser les attributs d’identification et les mécanismes garantissant l’unicité et la persistance des identifiants. |
Exemple 1 : L’identifiant des usagers sera l’attribut uid des DN cn=XXX,ou=service1,dc=entreprise,dc=com dans l’annuaire LDAP central.
Un filtre sera également appliqué pour restreindre l’accès aux membres du groupe ou=monapplication,dc=entreprise,dc=com.
Exemple 2 : Pour éviter la réutilisation des identifiants de comptes supprimés, une table d’historique historique_uid sera ajoutée à la base de données et systématiquement interrogée avant toute création de nouveau compte.
Exemple 3 : Les comptes de service seront identifiés via une clé API unique stockée dans un Vault sécurisé et soumise à une rotation automatique tous les 6 mois.
Dispositifs répondant aux exigences d’authentification :
|
Tip
|
Décrire ici les mécanismes d’authentification mis en place, y compris : - Le mode de stockage et de vérification des mots de passe. - Les éventuels facteurs d’authentification supplémentaires. - La gestion du cycle de vie des identifiants (création, mise à jour, suppression). |
Authentification par mot de passe :
Exemple 1 : L’authentification des internautes inscrits se fera par login/mot de passe, en respectant la politique de mot de passe P.
Les mots de passe seront hachés et stockés sous forme de digest bcrypt avec un facteur de coût de 12.
Exemple 2 : Les administrateurs internes utiliseront un SSO basé sur Kerberos avec délégation via un fournisseur d’identité OAuth2/OpenID Connect.
Exemple 3 : Pour permettre la récupération de compte, les utilisateurs pourront réinitialiser leur mot de passe via un lien temporaire envoyé par e-mail (valable 10 minutes).
Authentification forte (2FA/MFA) :
Exemple 4 : Lors de l’ajout d’un nouveau bénéficiaire de virement dans l’espace internet, l’utilisateur devra fournir : - Son mot de passe habituel. - Un OTP généré via une application TOTP (Google Authenticator, FreeOTP…).
Exemple 5 : L’accès aux API REST critiques nécessitera une authentification par clé API + JWT signé. Les clés API seront stockées dans un Vault et soumises à une rotation automatique.
Sécurisation des authentifications sensibles:
Exemple 6 : Toute tentative d’authentification échouée sera journalisée et supervisée. Après 5 échecs successifs, le compte sera verrouillé temporairement pendant 30 minutes.
Exemple 7 : Les connexions suspectes (nouvelle adresse IP, localisation inhabituelle) nécessiteront une vérification supplémentaire via un OTP envoyé par e-mail.
Dispositifs répondant aux exigences de fédération d’identité :
|
Tip
|
Les solutions les plus courantes sont actuellement :
Pour les applications Web, préciser les contraintes navigateur (gestion des cookies, SameSite policy…). |
Exemple : L’IHM grand public permettra une identification et authentification via France Connect (basé sur OpenID Connect). Les utilisateurs pourront s’identifier en réutilisant leur compte DGFiP, CNAM, etc.
Dispositifs répondant aux exigences de SSO et SLO :
|
Tip
|
Décrire ici la technologie choisie et son intégration dans l’architecture. Quelques solutions courantes :
Préciser les contraintes spécifiques aux applications Web, notamment la gestion des cookies, du token session, et les implications de SameSite / CORS. |
Exemple 1 : L’IHM X intégrera un client CAS spring-security pour le SSO. Le serveur CAS utilisé sera YYY et le realm d’authentification utilisé sera basé sur l’Active Directory (AD) Y.
Exemple 2 : Comme toutes les applications du portail métier, l’IHM X devra implémenter le Single Logout (SLO) en gérant les callbacks de déconnexion du serveur CAS.
Exemple 3 : Le SSO sera mis en œuvre via Keycloak en tant que fournisseur d’identité, avec une délégation vers l’AD via LDAP.
|
Tip
|
Les comptes de service sont utilisés pour authentifier une application ou un batch lorsqu’ils accèdent à un service d’infrastructure (base de données, API…). Bonnes pratiques :
|
| Compte | Ressource requérant authentification | Mode de stockage des credentials |
|---|---|---|
|
Base de données PostgreSQL et SQL Server |
Stockage comme secret Kubernetes (monté en volume uniquement sur les pods concernés) |
|
API REST X |
Authentification via JWT signé et stocké dans un coffre-fort numérique sécurisé |
|
Serveur CI/CD |
Stockage en HashiCorp Vault avec rotation automatique des secrets |
Dispositifs répondant aux exigences de non répudiation :
Exemple : La déclaration d’impôt sera signée par le certificat client de l’usager (X.509, RSA, SHA-256) qui lui a été fourni par le module X.
|
Tip
|
L'horodatage cryptographique ne répond pas à un besoin isolé mais est souvent utilisé en complément d’une signature électronique pour garantir la non-répudiation. L’horodatage permet de prévenir toute altération de date (antidatage ou postdatage). Il repose sur des jetons d’horodatage qualifiés (RFC 3161, eIDAS), délivrés par un Prestataire de Service de Confiance (TSA – Timestamping Authority). |
Exemple : Les signatures électroniques seront horodatées avec un jeton d’horodatage qualifié eIDAS, délivré par le prestataire de service de confiance XYZ.
Dispositifs répondant aux exigences d’anonymat et de respect de la vie privée :
Exemple 1 : Un audit interne annuel sera mené sur :
-
Le contenu des bases de données.
-
Les extractions de données à destination des partenaires externes.
Exemple 2 : Les données exposées publiquement seront exportées partiellement via :
COPY (SELECT <colonnes_autorisées> FROM table) TO <fichier>
Les colonnes sensibles seront exclues de la réplication vers la zone publique.
Exemple 3 : Un bandeau de consentement aux cookies sera mis en place sur toutes les pages de l’application Angular via le module angular-cookie-law.
Dispositifs répondant aux exigences sur les habilitations :
Exemple 1 : La gestion des autorisations sera intégrée applicativement et stockée dans la base PostgreSQL. Les tables dédiées aux habilitations seront détaillées dans le dossier de spécification.
Exemple 2 : L’accès aux carnets d’adresses sera contrôlé via OAuth2. L’API utilisée sera Google OAuth2 en Java.
Dispositifs répondant aux exigences de traçabilité et d’auditabilité :
Exemple 1 : À la fin de chaque action métier, l’application ReactJS effectuera un appel asynchrone à un service REST dédié à la traçabilité des actions. Ce service enregistrera les traces métier dans une base Elasticsearch pour consultation via Kibana.
Exemple 2 : Un système de détection d’intrusion (IDS) hybride (réseau + hôte), basé sur OSSEC, sera déployé sur l’ensemble des machines utilisées par l’application.
Exemple 3 : Les tables X, Y, … seront historisées selon le modèle suivant :
<diagramme de classe décrivant la conservation des versions de données>
Exemple 4 : Tous les documents servant de preuve seront archivés dans la GED (Gestion Électronique de Documents) avec des métadonnées permettant leur indexation et leur consultation rapide.
Exemple 5 : Les journaux contenant le tag [PREUVE] et issus de tous les modules seront :
-
Centralisés via le système de logs Elasticsearch.
-
Transformés et enrichis via Logstash.
-
Indexés quotidiennement dans l’index Elastic
preuvespour faciliter les recherches et la conformité.
Les cybermenaces incluent : malwares, phishing, attaques DOS/DDOS, exploitation de vulnérabilités (connues ou zero-day), ingénierie sociale, escroqueries en ligne, fuites de données sensibles, etc.
Le cadre de réponse aux menaces peut être aligné sur le NIST Cybersecurity Framework, qui définit 5 fonctions clés :
-
Identifier : Comprendre et prioriser les risques.
-
Protéger : Mettre en place des mécanismes de défense.
-
Détecter : Identifier une attaque en cours.
-
Réagir : Contenir et neutraliser la menace.
-
Récupérer : Restaurer les services après une attaque.
Ces solutions permettent d’anticiper les menaces avant qu’elles ne surviennent.
-
Formations et sensibilisations des utilisateurs et des équipes IT.
-
Systèmes de prévention d’intrusion (IPS) pour bloquer les acteurs jugés malicieux.
-
Revues d’habilitations régulières pour minimiser l’exposition.
-
Durcissement des règles de sécurité :
-
Authentification à facteurs multiples (MFA).
-
Rotation obligatoire des mots de passe.
-
Utilisation de coffres-forts numériques pour stocker les secrets.
-
-
Audits réguliers (tests d’intrusion, audit de code) par des experts internes ou externes.
-
Solutions DLP (Data Loss Prevention) pour surveiller et empêcher les fuites de données sensibles.
-
Blocage des vecteurs d’attaque (ex. désactivation des ports USB).
-
Mises à jour automatiques des patches de sécurité.
Exemple 1 : Sensibilisation des utilisateurs via les recommandations de l’ANSSI.
Exemple 2 : Mise en place de l’IPS OpenSource CrowdSec, basé sur le partage d’information communautaire (crowdsourcing).
Ces solutions permettent d’identifier les attaques en cours.
-
Antivirus nouvelle génération (basés sur IA et heuristiques, et non uniquement sur des signatures).
-
WAF (Web Application Firewall) pour analyser et bloquer les attaques applicatives.
-
SIEM (Security Information and Event Management) pour corréler et analyser les journaux issus de multiples sources.
-
IDS (Intrusion Detection System) pour surveiller le trafic réseau et détecter les attaques.
-
SAST (Static Application Security Testing) et DAST (Dynamic Application Security Testing) :
-
SAST : Analyse du code source pour identifier les vulnérabilités connues.
-
DAST : Analyse des comportements en exécution.
-
-
SCA (Software Composition Analysis) : Analyse des dépendances logicielles pour détecter les CVE (Common Vulnerabilities and Exposures).
Exemple 1 : Intégration de OWASP Dependency-Check dans la CI/CD pour détecter les librairies contenant des CVE.
Ces solutions permettent de réagir et corriger après la détection d’une menace.
-
Solutions anti-malware pour supprimer les logiciels malveillants.
-
Plans de restauration des sauvegardes pour reprendre l’activité rapidement (MTTR optimisé).
-
Isolation des zones compromises (micro-segmentation réseau, cloisonnement des applications).
-
Gestion de parc logiciel pour bloquer les logiciels non autorisés.
-
Analyse forensique pour comprendre les chemins d’attaque et identifier la source d’une compromission.
-
Procédures de réponse à incident, en se basant sur le standard NIST SP 800-61.
Exemple 1 : Déploiement d’un plan de secours basé sur les recommandations du NIST SP 800-61.
Ces solutions récentes reposent sur l’analyse comportementale et le Machine Learning.
-
UEBA (User and Entity Behavior Analytics) : Détection des comportements anormaux d’utilisateurs ou de systèmes.
-
Simulations d’attaques complexes pour tester la résilience du SI.
-
Threat Intelligence : Intégration de flux de renseignement sur les menaces en temps réel.
Exemple 1 : Surveillance des comportements suspects via AWS GuardDuty sur une application cloud AWS.
Exemple 2 : Utilisation de CrowdSec Threat Intelligence pour anticiper les tendances d’attaques.
|
Note
|
Ce RACI permet de définir clairement les rôles et responsabilités des équipes en matière de gestion de la sécurité informatique.
Dans un bon RACI, il ne doit jamais y avoir plus d’un A pour chaque ligne. |
| Équipe Systèmes & Cloud | Équipe Sécurité SI | Équipe Réseau | |
|---|---|---|---|
Création des comptes AWS |
R & A |
C & I |
I |
Création des stratégies IAM & SCP AWS |
R |
A |
C |
Gestion des logs CloudTrail et alertes CloudWatch |
R |
A |
I |
|
Tip
|
La gestion des vulnérabilités suit les standards OWASP Top 10, MITRE ATT&CK et NIST 800-53. Objectif : Vérifier que les mesures de protection, détection et correction sont bien appliquées pour réduire les risques d’attaques (ex: ransomware, attaques supply-chain, injections…). |
Vulnérabilité |
Prise en compte ? |
Mesures techniques entreprises |
Exposition de ports inutiles |
✅ |
Configuration du firewall iptables/nftables. Seuls les ports 443 et 22 sont ouverts. |
Brute-force SSH |
✅ |
Utilisation de Fail2Ban + authentification SSH par clé publique. |
Contournement des contrôles d’accès |
✅ |
Utilisation de Spring Security, OAuth2 et RBAC. |
Injection SQL / NoSQL |
✅ |
Utilisation exclusivement de Prepared Statements et ORM sécurisés. |
XSS (Cross-Site Scripting) |
✅ |
|
Fuite de secrets et API Keys |
✅ |
Utilisation de Vault pour stocker les secrets. |
Attaques HTTPS (CRIME, BREACH, DROWN) |
✅ |
|
CSRF (Cross-Site Request Forgery) |
✅ |
Utilisation du double submit cookie pattern et validation des tokens CSRF. |
Planification des mises à jour de sécurité |
✅ |
|
|
Tip
|
Le RGPD impose des exigences fortes sur les données personnelles des individus. Ces points sont basés sur les recommandations de la CNIL et de l'EDPB. A noter que le RGPD ne concerne que les personnes physiques, pas les entreprises. |
Exigence RGPD |
Prise en compte ? |
Mesures techniques entreprises |
Registre des traitements |
✅ |
Documentation complète dans Confluence / Notion. |
Minimisation des données collectées |
✅ |
Suppression des numéros de CB stockés inutilement. |
Droits des utilisateurs (accès, rectification, suppression) |
✅ |
Un formulaire dédié permet d’effectuer les demandes de droit via un workflow automatisé. |
Protection des données sensibles |
✅ |
|