Remarque : OpenID Connect est utilisé exclusivement comme protocole pour la connexion à un fournisseur d’identité existant du client. Un serveur d’autorisation ne fait pas partie du périmètre de livraison, mais peut être conçu, intégré ou configuré par nos soins si nécessaire. La connexion à des fournisseurs courants tels qu’AGOV ou SwissID est en principe possible et a déjà été réalisée avec succès.

Les chapitres « Architecture », « Flux de données » et « Sécurité » décrivent AVG2 en tant que produit. L’exploitation et l’infrastructure relèvent de l’exploitant de chaque installation. Les technologies utilisées figurent au chapitre « Technologie ».

Tous les cantons reçoivent la même image Docker. Chaque canton dispose de sa propre installation et de sa propre base de données, les différences entre cantons étant gérées par configuration. Aucune donnée n’est partagée entre les cantons.

Composants

Systèmes externes

Les systèmes suivants sont mis à disposition par l’exploitant :

• le fournisseur d’identité du client (OpenID Connect), pour la connexion
• un serveur de messagerie (SMTP), pour les notifications
• en option, un antivirus qui analyse les fichiers déposés avant leur enregistrement

Livraison et exploitation

• Les modifications de la base de données sont livrées sous forme de scripts SQL versionnés et appliquées avec l’outil DbUpdater, fourni dans une image distincte.
• Des health checks couvrent le démarrage, le bon fonctionnement de l’application (liveness) et la connexion à la base de données. En option, un point de terminaison Prometheus met des métriques à disposition.
• Pour Kubernetes, nous livrons un chart Helm.

Connexion et utilisateurs

La connexion passe du navigateur au fournisseur d’identité du client, puis au serveur AVG2. Le fournisseur d’identité transmet au serveur l’adresse e-mail de la personne, que le serveur rattache à la personne enregistrée dans AVG2. Les rôles et les autorisations proviennent d’AVG2, et non du fournisseur d’identité.

La section « Gestion des autorisations » du chapitre « Sécurité » décrit qui enregistre et gère quels utilisateurs. Quiconque se connecte auprès du fournisseur d’identité sans être enregistré dans AVG2 n’obtient aucun rôle, et donc aucun accès.

Saisie, traitement et restitution

Données personnelles

Pour chaque utilisateur, AVG2 enregistre le nom, le prénom, l’adresse e-mail, la langue, les rôles ainsi que la date et l’heure de la dernière connexion. L’adresse et le numéro de téléphone sont facultatifs et ne sont généralement pas renseignés. Aucun champ de données personnelles n’est prévu pour les personnes en formation, seuls des indicateurs sont saisis. Selon leur contenu, les documents déposés peuvent contenir des données personnelles.

Connexion et session

• La connexion s’effectue côté serveur via OpenID Connect, avec l’Authorization Code Flow. Par défaut, AVG2 utilise les Pushed Authorization Requests lorsque le fournisseur d’identité les prend en charge.
• Les jetons restent sur le serveur, dans le stockage des sessions. Le navigateur ne reçoit qu’un cookie contenant une clé de session. Ce cookie est HttpOnly et n’est transmis que via HTTPS.
• La session expire après une période d’inactivité (10 minutes par défaut, durée paramétrable par l’exploitant). Toute activité la prolonge.
• À la déconnexion, le jeton de rafraîchissement (refresh token) est révoqué auprès du fournisseur d’identité.
• Le rattachement à la personne se fait par l’adresse e-mail fournie par le fournisseur d’identité. Cela suppose que celui-ci livre des adresses e-mail vérifiées et uniques, ce qui relève de la responsabilité de son exploitant.

Contrôle des autorisations

• Le serveur vérifie l’authentification et les autorisations pour chaque requête API. Seuls font exception quelques points de terminaison sans données protégées, notamment pour la connexion, la déconnexion et les health checks. Seul le contrôle effectué sur le serveur fait foi, les contrôles dans le navigateur ne servent qu’à l’affichage.
• Chaque point de terminaison protégé doit être enregistré dans la gestion des autorisations de la base de données. Les requêtes vers un point de terminaison non enregistré sont refusées.
• Les rôles reçoivent des paquets d’autorisations assortis d’un niveau : lecture, écriture, étendu ou administration.
• Pour les données liées à un établissement, le serveur vérifie en outre que la personne est autorisée pour cet établissement : par un rôle au sein de l’établissement lui-même ou de son organisme responsable.

Gestion des autorisations

Nous configurons les rôles et les paquets d’autorisations et mettons en œuvre, si nécessaire, des exigences spécifiques au client. AVG2 distingue deux types de rôles.

Type de rôle Établissement

• Chaque établissement ou organisme responsable dispose toujours d’un interlocuteur. Celui-ci est officiellement connu du canton, qui l’enregistre dans AVG2.
• L’interlocuteur peut déléguer la saisie des données à des personnes ayant le rôle de fournisseur de données. Il gère lui-même les personnes qui ont accès à l’application et à son établissement.
• Pour le canton, l’interlocuteur reste la personne de référence : il vérifie les données, les valide et répond du bon déroulement. La manière dont il délègue la saisie en interne relève de son ressort.
• Une personne peut être rattachée à plusieurs établissements avec des rôles différents, p. ex. interlocuteur pour l’établissement A et fournisseur de données pour l’établissement B.

Type de rôle Application

Rôles globaux de l’application :

• Administrateur système : par défaut le support d’itree, sur demande également le client.
• Administrateur : responsable de la configuration des données de base.
• Responsable du dossier : chargé des tâches opérationnelles. Souvent, il n’y a pas de responsable du dossier et l’administrateur assume ces tâches.
• Lecteur de données : rôle destiné aux audits.

Utilisation et utilisateurs inactifs

AVG2 n’est pas une application utilisée au quotidien. En règle générale, le canton invite à un moment donné les prestataires à saisir leurs données. Une fois la période de saisie terminée, les processus démarrent et donnent lieu à des demandes de précisions et à des décisions. Il est donc fréquent que des utilisateurs ne se connectent pas pendant plusieurs mois, faute d’action à effectuer.

C’est pourquoi aucun blocage automatique des utilisateurs inactifs n’est prévu. Les interlocuteurs étant officiellement connus du canton, des processus de notification existent en dehors d’AVG2. Les changements de personnes sont ainsi réglés sur le plan organisationnel, et non dans AVG2. Le canton peut consulter la date de la dernière connexion dans les évaluations.

Saisies

• Toutes les saisies sont validées selon les mêmes règles dans le navigateur et sur le serveur. Le serveur rejette les données non valides, même si le navigateur est contourné.
• Les champs de texte contenant du HTML (p. ex. modèles d’e-mail, textes d’aide) sont contrôlés par le serveur lors de l’enregistrement, sur la base d’une liste de balises et d’attributs autorisés. Cette liste est modifiable dans les paramètres. Par défaut, elle n’admet ni scripts, ni cadres intégrés, ni gestionnaires d’événements. Les liens et les sources d’images ne sont acceptés qu’avec des schémas sûrs (p. ex. https).
• Les accès à la base de données passent par Entity Framework Core avec des requêtes paramétrées, y compris pour l’appel de procédures stockées.

Fichiers

• Les extensions de fichier autorisées sont définies côté serveur pour chaque type de document, et non par le navigateur.
• En option, chaque fichier déposé est analysé par un antivirus avant son enregistrement (voir chapitre « Architecture »).
• La consultation, la modification, le dépôt et la suppression sont autorisés par rôle et par type de document. Le serveur le vérifie à chaque accès et, pour les téléchargements, également par rapport à l’établissement concerné.
• Chaque téléchargement d’un document est journalisé avec la personne, le rôle et l’horodatage, à l’exception des modèles Word.

Traçabilité

• Les données de base et les données des établissements indiquent qui les a saisies et modifiées en dernier, et à quel moment.
• Les données saisies par les établissements sont historisées avec leur statut et une justification.
• Les données de base sont figées par année. Une année figée ne peut plus être modifiée librement. C’est voulu : les modifications ultérieures n’ont pas d’effet rétroactif sur les années précédentes (non-régression). Les décisions et décomptes antérieurs restent ainsi traçables.
• Un journal applicatif (Serilog) écrit dans la base de données et sur la console au format JSON, avec un identifiant de trace par requête. Les rôles autorisés peuvent le consulter dans l’application.
• Chaque envoi d’e-mail est journalisé avec le destinataire, l’objet, le statut et la personne qui l’a déclenché.
• En cas d’erreur inattendue, le navigateur ne reçoit qu’un message d’erreur générique et traduit. Les détails figurent uniquement dans le journal.

Plateforme

• La terminaison TLS est assurée par l’exploitant, en amont de l’application.
• Avec le chart Helm, le conteneur s’exécute sous un utilisateur sans droits root, sans élévation de privilèges, sans capacités Linux, avec le profil Seccomp RuntimeDefault et sans jeton d’accès à l’API Kubernetes.
• Les identifiants d’accès (base de données, fournisseur d’identité, SMTP) sont transmis sous forme de variables d’environnement ou de secret Kubernetes, et ne sont pas intégrés à l’image.

Dépendances

Pour chaque release, nous générons une SBOM dont les composants sont contrôlés dans Dependency-Track quant aux vulnérabilités connues (outils : voir chapitre « Technologie »). La personne responsable d’AVG2 au sein d’un canton obtient un accès en consultation à notre Dependency-Track.

Cet aperçu présente la documentation disponible pour AVG2, le public auquel elle s’adresse et l’endroit où la trouver.