GSIC — SLAM, session 2024

La journalisation des accès permet de démontrer la conformité (RGPD/CNIL), de détecter et prouver qui a accédé à quelles données (responsabilité, valeur probante) et de gérer les incidents de sécurité. C’est une obligation de l’article 32 du RGPD (mesures de sécurité).

a) La sauvegarde vise à restaurer des données en cas de perte/panne (objectif de continuité) ; l’archivage vise à conserver longtemps des données à valeur légale/probante (objectif de preuve).

b) Les journaux d’authentification sont archivés pour répondre à l’obligation légale de conservation (preuve et traçabilité sur la durée exigée).

La procédure prévoit une compression avec chiffrement → la confidentialité est assurée. En revanche, le transfert se fait sans vérification des sommes de contrôle (empreinte) → l’intégrité n’est PAS garantie : rien ne permet de détecter une altération des journaux pendant l’archivage. Il faudrait ajouter un condensat (hachage) vérifié à réception.

On réunit les comptes des différentes bases avec leur origine, en mettant NULL pour les champs absents :

CREATE VIEW v_liste_comptes AS
SELECT 'Personnel' AS origine, nom, prenom, compte_login, roles
FROM Personnel.utilisateur
UNION ALL
SELECT 'Logistique' AS origine, nom, prenom, compte_login, roles
FROM Logistique.utilisateur
UNION ALL
SELECT 'Formation' AS origine, nom, prenom, login AS compte_login, NULL AS roles
FROM Formation.utilisateur;

: prévoir une table Compte (origine, nom, prénom, login, application) et une table Role reliée aux comptes (un identifiant par rôle propre à une application), via une table d’association Compte–Role.

a) Créer le compte applicatif :

CREATE USER 'prep_sso'@'localhost' IDENTIFIED BY '<mot_de_passe_fort>';

b) Droits strictement nécessaires au programme (lecture de la vue + écriture dans l’inventaire) — moindre privilège :

GRANT SELECT ON BdInventaire.v_liste_comptes TO 'prep_sso'@'localhost';
GRANT INSERT ON BdInventaire.*               TO 'prep_sso'@'localhost';

a) L’agent qui a divulgué ses identifiants a violé la charte informatique (partage d’un accès personnel nominatif).

b) Le stagiaire est en faute : il s’est connecté à un système auquel il n’avait pas droit (accès non autorisé).

c) Risques : sanctions disciplinaires pour l’agent, et pour le stagiaire une responsabilité pénale possible (accès frauduleux à un système, art. 323-1 du Code pénal).

La charte informatique ne s’impose aux employés que si elle est annexée au règlement intérieur (procédure de dépôt/consultation respectée) et portée à leur connaissance (signée/communiquée).

Les données de santé : aptitude médicale, antécédents/résultats d’examens, groupe sanguin/rhésus, etc. — catégories particulières au sens de l’article 9 du RGPD.

Même si les accès par l’application sont sécurisés, un acteur disposant d’un accès direct à la base (administrateur de base de données, prestataire) ou le vol d’une sauvegarde permettrait de lire les données en clair. Le chiffrement des colonnes (clé hors base) protège contre cet accès direct.

-- Accès direct : la donnée apparaît chiffrée (illisible)
SELECT rhesus FROM PatientAnonyme;

-- Accès via la vue (utilisateur habilité, certificat) : donnée déchiffrée
SELECT rhesus FROM v_PatientAnonyme;   -- la vue déchiffre la colonne

: si les méthodes du contrôleur ne vérifient pas l’autorisation (ou construisent les requêtes par concaténation), l’API expose des accès non autorisés et des injections → atteinte à la confidentialité et à l’intégrité.

: le problème vient de l’audience du jeton (le « public » pour lequel le JWT est émis) ou du public de la formation : il faut regénérer/adresser le jeton au bon destinataire pour que l’API l’accepte.

Hypothèse la plus probable : le jeton JWT a expiré (sa durée de vie est dépassée pendant la pause). La vérification de signature/validité échoue → l’API renvoie invalid_token.

Sans paramètre, elle utilise le jeton de rafraîchissement (refresh token) courant pour demander un nouveau jeton d’accès au serveur SSO et le retourne :

getToken() :
    réponse = appel SSO (/token) avec le refresh_token courant
    nouveauJeton = réponse.access_token
    mettre à jour le jeton stocké
    retourner nouveauJeton

a) Avec le SSO, un seul compte compromis donne accès à TOUTES les applications → la gravité augmente (le risque passe à un niveau supérieur sur la matrice).

b) Amélioration : ajouter une authentification multifacteur (MFA) → réduit la vraisemblance qu’un compte usurpé soit exploité, ramenant le risque à un niveau acceptable.

Le mot de passe de 8 caractères est plus protecteur contre les attaques par force brute : son espace de combinaisons est bien plus grand (lettres + chiffres + spéciaux sur 8 positions) qu’un PIN à 4 chiffres (10 000 combinaisons seulement).

La reconnaissance faciale repose sur une donnée biométrique, qui est une donnée personnelle sensible au sens du RGPD (article 9). Son traitement est strictement encadré : il nécessite une base légale (souvent le consentement), une analyse d’impact (AIPD), et ne peut pas être imposé (une alternative — mot de passe — doit rester disponible), contrairement à un mot de passe.

Elle insère une entrée de journal (date/heure, utilisateur, action) dans la base SQLite via une requête paramétrée :

public void ajouterEntreeLog(EntreeLog uneEntree) {
    SQLiteDatabase db = this.getWritableDatabase();
    ContentValues valeurs = new ContentValues();
    valeurs.put("dateHeure", uneEntree.getDateHeure());
    valeurs.put("utilisateur", uneEntree.getUtilisateur());
    valeurs.put("action", uneEntree.getAction());
    db.insert("Log", null, valeurs);   // insertion paramétrée
    db.close();
}