Skip to content

Latest commit

 

History

History
206 lines (129 loc) · 4.88 KB

volet-architecture-securite.adoc

File metadata and controls

206 lines (129 loc) · 4.88 KB

Volet architecture sécurité

Dernière modification : 2025-01-08

1. Introduction

Ceci est le point de vue sécurité. Il 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 volets du dossier sont accessibles d’ici.

Le glossaire du projet est disponible ici. Nous ne redéfinirons pas ici les termes fonctionnels ou techniques utilisés.

1.1. Documentation de Référence

Table 1. Références documentaires sécurité
Version Titre/URL du document Détail

2. Non statué

2.1. Points soumis à étude complémentaire

Table 2. Points soumis à étude complémentaire
ID Détail Statut Porteur du sujet Échéance

2.2. Hypothèses

Table 3. Hypothèses
ID Détail

3. Contraintes

4. Exigences

4.1. Exigences d’intégrité

Table 4. Niveau d’intégrité exigée par classe de données

Classe de données

Niveau « Non intègre » (La donnée peut ne pas être intègre)

Niveau « Détectable » (La donnée peut ne pas être intègre si l’altération est identifiée dans un délai raisonnable)

Niveau « Maîtrisé » (La donnée peut ne pas être intègre, si l’altération est identifiée et l’intégrité du bien essentiel retrouvée)

Niveau « Intègre » (La donnée doit toujours être rigoureusement intègre)

4.2. Exigences de confidentialité

Table 5. Niveau de confidentialité exigée par classe de données

Classe de données

Niveau « Public » (Tout le monde peut accéder à la donnée)

Niveau Limité » (La donnée n’est accessible qu’aux personnes habilitées)

Niveau « Réservé » (La donnée n’est accessible qu’au personnel interne habilité)

4.3. Exigences d’identification

4.4. Exigences d’authentification

Table 6. Exigence d’authentification par cas d’utilisation
Cas d’authentification Mot de passe respectant la politique de mot de passe Clé publique ssh connue OTP par Token Biométrie Connaissance de données métier E-mail d’activation Délégation authentification

4.5. Exigences de fédération d’identité

4.6. Exigences de SSO et SLO

4.7. Exigences de non répudiation

Table 7. Besoins de non-répudiation
Donnée signée Origine du certificat client Origine du certificat serveur

4.8. Exigences d’anonymat et de respect de la vie privée

4.9. Exigences sur les habilitations

Table 8. Matrice de rôles
Groupe ou utilisateur Rôle x Rôle y Rôle z

4.10. Exigences de traçabilité et d’auditabilité

Table 9. Données à conserver pour preuves
Donnée Objectif Durée de rétention

5. Mesures de sécurité

5.1. Intégrité

Dispositifs répondant aux exigences d’intégrité :

Table 10. Mesures pour assurer le niveau d’intégrité demandé
Classe de données Niveau exigé Mesures

5.2. Confidentialité

Dispositifs répondant aux Exigences de confidentialité :

Table 11. Mesures pour assurer le niveau de confidentialité demandé
Classe de données Niveau exigé Mesures

5.3. Identification

Dispositifs répondant aux exigences d’identification :

5.4. Authentification

Dispositifs répondant aux exigences d’authentification :

5.4.1. Comptes de service

Table 12. Comptes de service
Compte Ressource requérant authentification mode de stockage des credentials

5.5. Fédération d’identité

Dispositifs répondant aux exigences de fédération d’identité :

5.6. SSO, SLO

Dispositifs répondant aux <<Exigences de SSO et SLO> :

5.7. Non-répudiation

Dispositifs répondant aux Exigences de non répudiation :

5.8. Anonymat et vie privée

5.9. Habilitations

Dispositifs répondant aux Exigences sur les habilitations :

5.10. Tracabilité, auditabilité

6. Auto-contrôles

6.1. Auto-contrôle des vulnérabilités

Table 13. Checklist d’auto-contrôle de prise en compte des vulnérabilités courantes
Vulnérabilité Pris en compte ? Mesures techniques entreprises

6.2. Auto-contrôle RGPD

Table 14. Checklist d’auto-contrôle de respect du RGPD
Exigence RGPD Prise en compte ? Mesures techniques entreprises