Cahier des charges API : points de sécurité

3. Définir les journaux, leur conservation et les alertes

Choisir les événements à journaliser et les durées de conservation

Les droits, rejets et incidents définis plus haut doivent figurer dans les journaux pour apporter la preuve des échanges. Choisissez les événements à journaliser selon le risque : authentifications, refus d’accès, accès aux données sensibles et opérations sur celles-ci, exports, actions d’administration, changements de configuration ou de version, échecs d’intégration, reprises, délais d’attente, interruptions et incidents de sécurité. Chaque entrée doit préciser l’acteur ou le service, l’horodatage avec fuseau, l’opération ou l’endpoint, le système source, la référence de la ressource sans son contenu complet, l’identifiant de corrélation, le résultat, le statut HTTP, le type d’erreur et le volume d’échanges.^[14]

Pour relier les traces métier et sécurité, imposez un format structuré, comme JSON, et un identifiant de corrélation commun à tous les systèmes traversés. Synchronisez les horloges sur une même source NTP. Enregistrez les heures en UTC et affichez l’heure locale française dans les rapports opérationnels.^[14][15]

Excluez les mots de passe, leurs condensats, les jetons d’accès et de rafraîchissement, les clés privées et les données personnelles inutiles. Centralisez les journaux hors production sur une plateforme dédiée, avec chiffrement, contrôle d’intégrité et traçabilité des consultations, exports et suppressions.^[14][15]

Pour chaque catégorie, fixez une durée de conservation, sa justification, le responsable d’accès et les règles de suppression automatique. La CNIL recommande généralement 6 à 12 mois de conservation glissante ; toute autre durée doit être justifiée. Prévoyez aussi un gel juridique pour suspendre la suppression en cas d’enquête ou de contentieux identifié. Documentez les traces concernées, le motif, l’approbateur et la date de réexamen.^[14]

Fixer les seuils d’alerte et les délais de réponse

La matrice ci-dessous s’appuie sur ces journaux. Validez-la selon les risques et les horaires métier. Les délais commencent au déclenchement de l’alerte : un accusé ne vaut pas résolution.

Classez comme critique toute panne de production ou tout accès suspect à des données sensibles. Prévoyez une couverture 24 h/24 et 7 j/7, une alerte d’astreinte, un accusé sous 15 min et une escalade après 30 min sans prise en charge.

Pour les autres niveaux, précisez les plages couvertes, les canaux, les délais d’accusé et les objectifs de résolution. Rattachez l’escalade au responsable d’incident et à la procédure de la section 2 : analyse, préservation des preuves, confinement, remise en service ou blocage d’accès.

En recette, puis au moins une fois par an et après tout changement majeur d’intégration, déclenchez chaque règle à partir des journaux. Consignez dans le dossier de livraison les preuves que l’alerte atteint le bon destinataire, que l’horodatage est fiable et que l’escalade fonctionne.^[14]

4. Conclusion : attribuer les responsabilités et valider le lancement

Attribuer les responsabilités et documenter les procédures

Les flux, les accès, les journaux et les alertes sont définis. Cette dernière étape n’ajoute pas de contrôles : elle précise qui valide quoi, avec quelle preuve et à quelle échéance.

Pour chaque point du cahier des charges, désignez un responsable, un exécutant, un approbateur et un suppléant. Répartissez ces rôles entre l’entreprise, le développeur, l’hébergeur et l’éditeur du logiciel connecté. Indiquez qui peut suspendre un accès, préserver les preuves ou bloquer le lancement. Précisez aussi qui déclenche l’escalade et qui autorise le gel des échanges. ^[17]

Exigez un dossier versionné qui rassemble l’architecture, la cartographie des flux, les permissions et la gestion des erreurs. Il doit aussi couvrir la rotation et la révocation des secrets, la restauration, le retour arrière et les contacts d’urgence.

Distinguez les délais contractuels des obligations RGPD. En cas de violation, le sous-traitant informe le responsable de traitement sans délai. Si une notification est requise, ce dernier avertit la CNIL dans les meilleurs délais et, si possible, sous 72 heures après en avoir pris connaissance. Toute violation doit être documentée, même si elle ne nécessite pas de notification. ^[16][18]

La validation finale traduit ces exigences en décisions signées et traçables.

Checklist de validation du lancement

Cette checklist conditionne la mise en production. Pour chaque ligne, renseignez le propriétaire nommé, la référence de preuve, le statut et la date de validation au format JJ/MM/AAAA. Une case cochée sans preuve ne suffit pas.

• [ ] Documentation validée - Architecture, champs sensibles, destinataires, fréquence, volumes, lieux de transfert, hébergement, procédures et contacts validés.
• [ ] Configuration sécurisée - Permissions minimales, administration séparée, secrets protégés, chiffrement, isolation entre clients, limites de débit et versions d’API vérifiés.
• [ ] Tests de sécurité validés - Accès interdit refusé ; isolation, divulgation excessive, rejeu, contournement des limites et requêtes malformées testés ; identifiants expirés, révoqués ou hors périmètre rejetés ; masquage des journaux, restauration et retour arrière validés.
• [ ] Supervision opérationnelle - Journaux exploitables, valeurs sensibles masquées, conservation conforme, destinataires des alertes et délais de prise en charge vérifiés.
• [ ] Rôles et escalade nommés - Responsable d’exploitation, décideur d’incident et approbateur du lancement nommés ; contacts fournisseurs confirmés ; risques résiduels acceptés et documentés, avec dates de revue planifiées.

Bloquez la mise en production si une vulnérabilité critique reste ouverte ou si la supervision, la restauration ou le retour arrière n’ont pas été validés. La direction ou l’autorité métier/sécurité désignée accepte les risques restants. Pour chacun, consignez par écrit l’impact, la mesure compensatoire et l’échéance.

Planifiez une revue à J+30, puis au moins une fois par an et après tout changement important des données, des endpoints, de l’hébergement ou des méthodes d’accès.

Atelier en direct sur la sécurité des API

FAQs

Comment adapter les exigences de sécurité à mon budget ?

Partez des risques : cartographiez vos flux et vos actifs en distinguant la sensibilité des données de la criticité pour l’activité. Ciblez ensuite vos investissements sur les zones les plus exposées.

Limitez la V1 aux fonctions critiques. Pour éviter les surcoûts, consignez les hypothèses techniques et les interfaces dans le cahier des charges. Prévoyez aussi le coût de maintenance des connexions, généralement estimé entre 15 % et 20 % de l’investissement initial par an.

Que faire si un outil connecté limite la sécurité des échanges ?

Compensez ces faiblesses par des mesures techniques et organisationnelles. Utilisez des comptes de service dédiés, avec des droits d’accès limités au strict nécessaire. Séparez aussi clairement les secrets de production de ceux utilisés pour les tests. Si une vulnérabilité persiste, renforcez le chiffrement des données en transit et au repos, puis surveillez les anomalies.

Consignez ces limites dans le cahier des charges. Prévoyez également une procédure de secours manuelle pour maintenir l’activité en cas d’incident.

Comment vérifier les preuves de sécurité de mon prestataire ?

Dès le début du projet, exigez des journaux d’audit (logs) sans données personnelles. Pour chaque action, ils doivent consigner l’identifiant technique, la date, l’heure, l’action effectuée, l’objet concerné et le résultat. Prévoyez aussi un journal dédié au suivi des suppressions et des anonymisations de données.

Demandez également des preuves de conformité, étayées par des audits de sécurité réguliers et des tests de pénétration.