Réponse courte : Avant le lancement, prouvez l'isolation tenant et les parcours privilégiés, durcissez identité et récupération, vérifiez facturation et webhooks, retirez les secrets du code et répétez détection, sauvegarde et réponse à incident.
1. Définir le threat model du lancement
Listez données et actions qui nuiraient aux clients : lecture inter-tenant, prise de compte, abus admin, manipulation d'abonnement, fuite de clés et opérations destructrices. Cartographiez anonyme, membre, admin workspace, support interne et identités de service. Donnez un responsable et une preuve à chaque contrôle.
2. Prouver isolation tenant et actions privilégiées
Scopez chaque requête et chemin de stockage au tenant issu de la session, pas d'un paramètre du corps. Testez des utilisateurs de même rôle dans deux tenants. Ajoutez permissions et événements distincts pour invitations, rôles, exports, suppression, impersonation support et transfert de propriété.
test("workspace B cannot export workspace A", async () => {
const response = await api.as(adminB).post(`/workspaces/${workspaceA.id}/export`);
expect([403, 404]).toContain(response.status);
expect(await exportQueue.countFor(workspaceA.id)).toBe(0);
});3. Durcir identité et récupération
Utilisez un fournisseur ou une bibliothèque maintenue, des cookies sûrs, le MFA pour comptes internes et privilégiés, et la révocation serveur. Réinitialisation du mot de passe, changement d'email et reset MFA sont aussi des parcours d'authentification : tokens uniques courts, réponses génériques et notifications.
4. Vérifier facturation, webhooks et intégrations
Déduisez prix et droits côté serveur. Vérifiez la signature webhook sur le corps brut exact, refusez les événements trop anciens lorsque possible, traitez-les de façon idempotente et récupérez l'état autoritatif au besoin. Chiffrez les tokens tiers, limitez leurs droits et documentez leur rotation.
Pour callbacks et imports par URL, appliquez les défenses SSRF et l'egress réseau. Traitez appels d'outils IA et contenu récupéré comme entrées non fiables ; autorisez l'action indépendamment de la sortie du modèle.
5. Préparer les opérations de production
Séparez les secrets de production des builds et renouvelez tout identifiant passé dans l'historique Git. Émettez des événements structurés pour connexion, récupération, rôles, facturation et actions destructrices sans journaliser les valeurs sensibles. Testez restauration, alertes et révocation des sessions, secrets webhook et accès dépôt.
Erreurs fréquentes
- Tester avec un seul tenant et un seul admin.
- Faire confiance au plan, prix ou rôle envoyé par le client.
- Parser un webhook avant de vérifier sa signature.
- Donner au support un accès large permanent sans audit.
- Avoir des sauvegardes sans test de restauration mesuré.
- Déclarer le lancement sûr car le scan de dépendances est vert.
Jalon de lancement
- Les tests inter-tenant couvrent lectures, écritures, exports et fichiers.
- Les actions privilégiées ont permission et événement distincts.
- Session, récupération et reset MFA sont testés.
- Prix et droits sont autoritatifs côté serveur.
- Signature, replay et idempotence des webhooks sont vérifiés.
- Les secrets ont responsables, moindre privilège et rotation.
- Les logs sécurité atteignent une alerte réellement reçue.
- Restauration et canal d'incident ont été répétés.
Limites
Ce jalon n'est pas une certification et ne couvre pas toutes les dépendances de production. Infrastructure, IAM cloud, clients mobiles, agents desktop et données réglementées peuvent exiger des contrôles séparés. Répétez le threat model quand rôles, facturation, intégrations ou architecture tenant changent.
Sources primaires
Ressources liées
Faire relire un SaaS avant lancement
Appliquer ces contrôles au code et aux frontières produit réelles.