Mesures techniques et organisationnelles de sécurité

Version 1.0 — 22 juillet 2026

6.1 Gouvernance

Amasma maintient une gouvernance de sécurité adaptée à sa taille, son modèle SaaS B2B/B2C et les risques associés à la prospection principalement orientée B2B, à l’IA, à la connexion de boîtes mail et aux données professionnelles ou de compte des utilisateurs.

6.2 Chiffrement

Les communications avec le service sont protégées par HTTPS/TLS. Redis Azure impose TLS 1.2. Les bases, stockages, sauvegardes et secrets doivent être protégés au repos via les mécanismes natifs des fournisseurs cloud.

6.3 Gestion des secrets

Les secrets sont conservés hors dépôt de code, dans des mécanismes spécialisés tels qu’Azure Key Vault ou équivalent. Les accès sont restreints, journalisés et soumis au principe du moindre privilège.

6.4 Contrôle d’accès

Amasma applique :

• rôles minimaux Azure/RBAC ;
• identité managée lorsque possible ;
• contrôles d’appartenance par tenant ;
• politiques RLS lorsque applicables ;
• accès administratifs limités aux besoins ;
• revue périodique des accès sensibles ;
• MFA obligatoire pour les comptes administrateurs lorsque le fournisseur le permet.

6.5 Isolation des tenants

Les données client sont isolées par tenant au niveau logique. Les requêtes doivent intégrer des contrôles d’appartenance. Les évolutions sensibles doivent inclure des tests d’autorisation et de non-régression.

6.6 Journalisation et monitoring

Amasma journalise les accès administratifs, authentifications, opérations sensibles et événements de sécurité. Les logs de sécurité sont conservés 12 mois, sauf gel probatoire lié à incident, fraude, abus ou litige.

Amasma utilise notamment Application Insights, Log Analytics, PostHog et contrôles de readiness/SLO.

6.7 Sauvegardes et restauration

Amasma vise des sauvegardes automatisées au moins quotidiennes, avec rétention glissante maximale de 90 jours. Les restaurations doivent être testées au moins trimestriellement.

Les objectifs internes non contractuels sont :

• RPO : 24 heures ;
• RTO : 48 heures.

6.8 Vulnérabilités

Amasma applique une gestion continue des vulnérabilités avec cibles de correction suivantes, sous réserve de disponibilité d’un correctif et de mesures compensatoires : Criticité Cible de correction Critique activement exploitable 72 heures Élevée 15 jours Moyenne 60 jours Faible 120 jours

6.9 Tests de sécurité

Amasma réalise des scans de secrets, tests d’autorisation/tenant, vérifications RLS et contrôles de production readiness à chaque évolution sensible.

Un pentest externe sera réalisé avant un contrat enterprise qui l’exige ou après un changement majeur de risque. Amasma ne revendique pas de pentest indépendant déjà réalisé pour le périmètre actuel.

6.10 Continuité et reprise

Amasma maintient une procédure de restauration depuis sauvegarde, redéploiement d’infrastructure et rotation des secrets. Le plan de continuité prévoit mode dégradé, files persistantes, reprise idempotente des tâches et communication client en cas d’incident majeur.

6.11 Suppression

La suppression comprend vérification de la demande, gel des exceptions légales, suppression de la base active sous 30 jours lorsque applicable, consignation minimale de l’opération et expiration des sauvegardes sous 90 jours.

6.12 Signalement de sécurité

Amasma ne dispose pas d’un programme de bug bounty rémunéré. Les signalements responsables doivent être adressés à contact@amasma.fr. Amasma vise un accusé de réception sous deux jours ouvrés.

Toute exploitation, exfiltration, persistance, atteinte à des données de tiers ou divulgation publique avant correction coordonnée est interdite.