Sécurité et Conformité
La sécurité est un élément essentiel pour assurer la confiance des utilisateurs de la plateforme.
Sécurité des données
Chiffrement des données
Le chiffrement des données au repos et en transit dépend des fournisseurs de service de stockage pour SeaweedFS et Postgresql. Dans le déploiement Kubernetes, le Helm Chart Qalita ne contient pas de configuration portant sur le chiffrement par défaut.
Il est à la charge de l'administrateur système qui déploie la plateforme de configurer le chiffrement des données au repos et en transit. Il peut être aidé par un Administrateur de base de données et d'un Ingénieur Réseau.
Au Repos
Les systèmes utilisent les supports de stockaque pour lire et écrire les données. On appelle ces systèmes "statefull" car leur état est sauvegardé sur un support de stockage. Dans la plupart des cas, ces systèmes offrent des méthodes de chiffrement de données "au repos" c'est à dire un chiffrement avant l'écriture des données sur le support de stockage et un déchiffrement après lecture du support de stockage. Cela garantie une inexploitabilité des données brutes par des pirates informatiques par compromission des supports de stockage.
| Postgresql | Seaweedfs | Redis |
|---|---|---|
| Pour la base postgresql, il faut modifier la configuration du moteur de base de donnée dans la configuration du helm chart pour y intégrer le chiffrement au repos. Helm PostgreSQL - Configuration Moteur de base de donnée | Seaweedfs permet le chiffrement des blobs par une clé unique stocké dans les méta données des blobs ces méta données étants stockés dans la partie Filer Store, vous pouvez garantir une robustesse en scidant la partie Filer Store (stockage des métadonnées) et Volume Store (stockage des données brutes) Configuration stockage du système de fichier | Dans l'implémentation QALITA Platform Redis est en mode "stateless" en tant que cache, nous n'utilisons pas de support de stockage, il n'y a donc pas necéssité de configuration spécifique. |
| Pour aller plus loin on peut explorer les options de chiffrement qu'offre nativement Postgresql Documentation PostgreSQL - Options de Chiffrement |
En transit
Le chiffrement en transit correspond au transfert de données sur les ports des systèmes de stockages de données, pour nous cela correspond à :
- 5432 pour
Postgresql - 8333 pour
Seaweedfs - 6379 pour
Redis
La configuration des systèmes de stockage ou de base de données fournissent une couche de chiffrement en transit à travers leur ports.
| Postgresql | Seaweedfs | Redis |
|---|---|---|
| Helm PostgreSQL - Chiffrement en transit | Helm Seaweedfs - Chiffrement en transit | Helm Redis - Chiffrement en transit |
| Seaweedfs Security Configuration |
Pour les serveur HTTP :
- 3080 pour le
Backend QALITA - 3000 pour le
frontend QALITA - 80 pour le
serveur de Documentation QALITA
Un mapping des ports avec un domaine ingress et son certificat TLS est necéssaire.
Chiffrement des Requêtes HTTP
Le chiffrement des requêtes dépend de la configuration des points de terminaisons réseaux et des certificats TLS utilisés.
Il est à la charge de l'administrateur système de configurer les points de terminaisons réseaux et la fourniture de certificats valides et exclusifs afin de garantir la sécurité des requêtes.
Dans le déploiement sur Kubernetes, le Helm Chart Qalita par défaut requiert cert-manager bien configuré pour fournir des certificats valides et exclusifs pour les points de terminaisons réseaux.
Il est créé les points de terminaisons suivants :
- frontend |
domain.com--->qalita-frontend-service:3000 - backend |
api.domain.com--->qalita-backend-service:3080 - doc |
doc.domain.com--->qalita-doc-service:80
Gestion des métriques
Les métriques sont calculées par les packs et sont stockées dans la base relationnelle de la plateforme, elles sont utilisées pour générer les rapports d'analyses, les tableaux de bord et les tickets.
Certains packs génèrent des métriques qui sont directement liés à des données sans opération d'agrégation, ces métriques sont stockées dans la base relationnelle de la plateforme. Elles sont sensibles et doivent êtres accédés avec le même niveau de sécurité que les données sources.
Veillez à bien lire les documentations des packs pour comprendre les métriques générées et leur sensibilité.
Conformité des données
Suivant votre secteur d'activité, vous pouvez être soumis à des réglementations et normes de conformité des données.
La plateforme tend à suivre et à se conformer aux réglementations et normes suivantes sans garantie de résultat ni certification :
Surveillance d'Activité
Gestion des accès
Les accès à la plateforme sont gérés par un système d'authentification et d'autorisation. Pour en savoir plus rendez-vous dans Gestion des Utilisateurs / Rôles / Habilitations
Gestion des logs
Il existe deux types de logs :
-
Logs d'activités utilisateurs Les logs d'action des utilisateurs sont stockés dans la base de données relationnelle de la plateforme dans la table
logs. Ils sont utilisés pour auditer le comportement des utilisateurs, aussi bien sur la webapp, qu'avec les agents, du fait de la mutualisation des jetons d'authentifications fournis par le backend à la fois pour la webapp et les agents.
-
Logs d'exécutions des tâches Les logs d'exécutions des tâches sont stockés dans le stockage SeaweedFS de la plateforme. Ils sont utilisés pour auditer le comportement des packs sur les données. Vous pouvez les consulter dans le dossier "LOGS" dans la page Agent de la plateforme, ou directement dans le stockage SeaweedFS dans le bucket
logs.
Export des logs utilisateurs
Vous pouvez exporter les logs utilisateurs directement depuis l'interface
Vous pouvez exporter les logs depuis une requête SQL directement à partir de la base Postgresql :
SELECT * FROM logs
Suppression des logs utilisateurs
Vous pouvez supprimer les logs utilisateurs durectement depuis l'interface
