PhishCase.PHISHCASE / Confidentialité
Confidentialité : principes techniques
Cette page explique le fonctionnement technique actuel. Les documents juridiques définitifs du service doivent être validés par son responsable avant l’ouverture commerciale.
Données traitées
Le produit stocke les originaux EML/MSG, les pièces jointes référencées, hashes, en-têtes, corps, indicateurs, résultats d’analyse, notes, décisions et historique. Cloud ajoute comptes, appartenances, paramètres, métadonnées d’abonnement et journaux d’exploitation. Les emails et les notes peuvent eux-mêmes contenir des données personnelles ou confidentielles.
Destinataires et actions externes
L’hébergement conserve les données applicatives. Le service SMTP configuré reçoit destinataire, sujet et contenu transactionnel. Stripe, lorsqu’il sera configuré, reçoit les données nécessaires au parcours d’abonnement ; les champs de carte sont saisis chez Stripe. VT/urlscan reçoivent seulement les cibles explicitement recherchées/soumises. Les webhooks configurés reçoivent des identifiants et états limités, sans corps d’email ni pièces jointes. La liste contractuelle des sous-traitants reste à valider. La vérification DKIM explicite transmet les noms de sélecteur et de domaine au résolveur DNS configuré sur le serveur, sans envoyer le contenu du message.
Accès et minimisation
Les droits contrôlent les opérations et l’organisation active en Cloud. La console opérateur fournit des métadonnées d’exploitation ; elle n’accorde pas implicitement un accès aux enquêtes client. Les journaux applicatifs évitent les contenus de message et secrets. Protégez aussi les journaux du proxy et des dépendances : leur format et leur durée relèvent de l’opérateur.
Durées et suppression
Les offres Cloud prévoient 90/180/365 jours d’éligibilité à la purge des analyses. La candidate utilise une prévisualisation et une confirmation administrateur ; aucune suppression automatique à date n’est promise. Notes, dossiers, audit, facturation et sauvegardes ont des cycles distincts. La purge locale ne retire pas les données déjà transmises à un provider. Fréquence de purge, durée des logs et durée des archives doivent être fixées avant lancement.
Navigateur et cookies
Le site public charge ses ressources localement, sans analytics ni pixel tiers. Le choix FR/EN est mémorisé en stockage local. L’application emploie des cookies de session pour la connexion et des préférences nécessaires à son interface. Aucun outil publicitaire n’est intégré. La politique cookies définitive doit correspondre à l’infrastructure réellement mise en ligne.
Sécurité et récupération
Les preuves sont immuables et vérifiées par hash ; elles ne sont pas individuellement chiffrées sur disque. Les clés MFA/providers sont chiffrées côté Cloud ; les archives de sauvegarde utilisent une clé séparée. Les restaurations sont testées dans une base vide et une pile isolée. La destination de sauvegarde indépendante et les objectifs de reprise doivent être décidés avec l’exploitant.
Validation humaine avant ouverture
À renseigner et valider : identité et coordonnées de l’éditeur/responsable, hébergeur et région, contact pour les demandes relatives aux données, CGU, CGV, DPA, Privacy Policy, mentions légales, politique cookies, liste des sous-traitants dont hébergeur/SMTP/Stripe, durées et procédure d’exercice des droits. Le contact actuel renvoie au profil du mainteneur ; il ne remplace pas un canal juridique ou support formalisé.