 |
| Le dispositif SEPAmail au cœur d'une architecture de messagerie |
L'architecture schématisée ci-dessus s'articule autour du mode canonique :
- un composant recevant et envoyant les courriels (MTA)
- un composant chiffrant et déchiffrant, relié à un composant d'authentification et une infrastructure à clé publique (PKI)
- un composant SMART mettant en œuvre le protocole SEPAmail autour de la missive (décrit dans le document
SMIRK MIS1101, remplacé par SMIRK MIS1202 fin juillet 2012)
La liaison avec le reste du monde via des équipements de protection, type pare-feu.
Le mode flash est sobre et ne s'occupe que d'interfacer entre le reste du monde et le composant MTA une chaîne de type web-service.
Charge à la chaîne canonique de savoir traiter en priorité les flux reçu ou émis en mode flash.
Des liaisons facultatives sont à prévoir entre le SMART et :
- un module d'horodatage externe et certifié si besoin
- un module de contrôle de type juridique si besoin
L'information échangée de composants à composants
Dans cette architecture, l'information échangée est, tout au long de la chaîne :- une enveloppe SEPAmail, c'est à dire une enveloppe SMTP
- SMIME entre le composant crypto et le reste du monde (composant MTA compris)
- SMTP déchiffrée entre le composant crypto et le SMART
- Et entre le SI et le SMART :
- une missive SEPAmail, c'est à dire un flux xml au standard missive de SEPAmail.
On peut donc passer les arguments au sein de ces entêtes.
Le bloc d'information est ainsi porteur de toute l'information utile et il n'y a pas d'API compliqué à prévoir entre ces composants autres que la spécification des entêtes et leur utilisation au sein du Système d'information cible des spécifications d'intégration de SEPAmail.
Quelques éléments de sécurité
Le composant SMART et le composant CRYPTO sont certainement à protéger au sein d'un segment de réseau spécifique à SEPAmail.Cette organisation ne remet pas en questions les règles de sécurité autour du composant MTA, notamment son emplacement et le filtrage associé au flux SMTP.
Si un responsable de la sécurité du système d'information cible désire associer des règles spécifiques au flux SEPAmail, il pourra le réaliser sans souci sur l'adresse de courriel qui est spécifique :
- nom de domaine sepamail.eu,
- sous-domaine pouvant être authentifié en DKIM et soumis à des règles SPF,
- adresses de courriel définies et spécifiques à SEPAmail
Des anti-virus peuvent être habilement utilisés à plusieurs endroits et notamment sur le flux chiffré avec le reste du flux SMTP en entrée de SI puis après (et avant) le déchiffrement.
Le cœur du système d'information n'est exposé qu'à un flux xml filtré, authentifié (signature), intègre (signature), valide (schéma xml) et vérifié (anti-virus).
L'exploitation du dispositif
Le dispositif décrit peut être exploité de la façon habituelle pour l'entreprise, charge à l'intégrateur de la solution d'ajouter les prises (ou sondes) entre les nouveaux composants et le composant d'exploitation pour alerte d'une défaillance opérationnelle.Les fonctions du composant SMART
Que fait donc le SMART dans cette configuration ?Il implémente les fonctions non encore réalisées autour de la missive :
- gestion du flux de travaux (workflow) en émission de missive nominale, incluant :
- l'attente de l'acquittement
- le renvoi éventuel de la missive
- l'escalade si la missive n'est pas acquittée dans les temps prévus
- gestion de l'acquittement en réception de missive nominale
- directement si c'est possible
- en délégation de l'application métier cible du message sinon
- dépôt des missives en direction des applications métiers
- récupération des missives provenant des applications métiers
- pilotage des commandes autour de la missive
Ceci est décrit plus spécifiquement ici dans le document
Aucun commentaire:
Enregistrer un commentaire