Le dispositif SEPAmail au cœur d'une architecture de messagerie

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 système d'information se fait par le SMART.
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.

L'enveloppe SEPAmail et la missive SEPAmail sont des blocs d'information dotés d'un entête.
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

Le mode flash est associé au mode canonique et la sécurité spécifique du transactionnel à temps court peut ainsi reposer sur quelques règles communes.

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 SMIRK MIS1101 remplacé par SMIRK MIS1202 fin juillet 2012.

Vocabulaire SEPAmail : mode d'échange canonique versus flash

Le standard SEPAmail définit la structuration de l'information échangée, une organisation pour l'adressage, les séquences d'envoi/réception.
Concernant l'échange à proprement parler de l'information, la documentation cite de deux modes : le mode canonique et le mode flash.

Le mode d'échange canonique

L'adjectif canonique doit être compris dans son utilisation usuelle en mathématiques comme en informatique, c'est à dire standard ou encore naturel et instinctif.
SEPAmail est une messagerie sur internet, le mode d'échange canonique est donc celui de la messagerie électronique, c'est à dire le mécanisme d'échange proposé par le protocole SMTP.

Ce protocole met en œuvre le transfert direct de serveur à serveur et le relais si besoin. Il repose sur des protocoles tiers tels que le DNS, IP, TCP, ainsi qu'un mécanisme d'extensions du protocole qui permet notamment l'implémentation de priorité.
Enfin, il définit une liste de commandes pour permettre de dialoguer entre deux serveurs et, si besoin, différer la remise effective du message.
Cette souplesse protocolaire permet d'éviter de perdre des messages si l'un des composants automates de la messagerie n'est pas joignable.

En théorie, un message peut être distribué à son destinataire plusieurs jours après l'émission par son expéditeur. En pratique, la messagerie électronique est souvent très rapide; nous sommes habitués depuis des années à recevoir nos messages électroniques dans un temps très court (souvent plus rapide que les SMS) et c'est même cette particularité qui a fait le succès et la généralisation de la messagerie électronique.

Pour être efficientes dans la mise en œuvre du protocole SMTP, la plupart des applications dédiées à l'échange des messages (applications dites MTA comme Mail Tranfert Agent) ont mis en place un mécanisme efficace de files d'attente et c'est ce mécanisme qui permet une bonne articulation entre des applications différentes avec des contraintes souvent divergentes.

SEPAmail repose nativement sur le protocole SMTP pour la structuration de l'information (enveloppe SEPAmail = enveloppe SMTP).
SEPAmail repose aussi nativement sur le protocole SMTP pour l'échange de cette information.
Ainsi, une enveloppe SEPAmail peut transiter par les systèmes de messagerie électronique sans aucune modification de ces systèmes.
Avec le mode d'échange canonique, SEPAmail est totalement compatible avec la messagerie électronique existante.

Le mode d'échange flash

Le mode d'échange canonique ne garantit pas un temps très court pour l'échange des données.
SEPAmail définit donc, lorsqu'il est important d'échanger rapidement une enveloppe SEPAmail, un mode d'échange flash.

Celui-ci repose sur un mécanisme de services web avec une garantie de réponse courte dite flash, de l'ordre de quelques secondes, comme en monétique.

C'est ce mode d'échange qui est en cours d'expérimentation dans l'esprit  qui peut le plus peut le moins. Cette expérimentation permet de bien s'assurer des délais raisonnables bout à bout que l'on peut garantir selon la charge et l'organisation des systèmes d'information bancaires ainsi que les coûts maximums de l'infrastructure flash.

Quelques réflexions sur le mode d'échange batch

La monétique et les systèmes informatiques bancaires en général sont assez friands de traitements par lots (batch processing) à des temps programmés à l'avance (vacations) et donc non à la demande comme les traitements transactionnels sur requêtes d'un client. Certains acteurs bancaires adhérents de SEPAmail mettent en œuvre de tels traitements au sein de leur système d'information.

Ce mode d'échange n'est pas souhaité entre les adhérents pour plusieurs raisons :

• il va à l'encontre de la logique message unitaire de SEPAmail
• il induit une gestion centralisée et pilotée de la charge alors que SEPAmail privilégie une gestion répartie pair à pair de l'échange.
• il repose sur un mode non transactionnel alors que SEPAmail utilise le réseau IP, transactionnel par nature

Le web service sur internet et l'illusion du temps réel

Le temps réel est à la mode dans le monde internet et le service web semble être l'objet de toutes les attentions actuelles pour mettre en œuvre du temps réel.

Cependant, derrière ce terme se cache des contradictions qui sont rarement mises en avant.

Un système temps réel est généralement défini par sa capacité à délivrer un résultat dans un temps fini et garanti, ce qui oblige toute la chaîne des procédés utilisés à être en temps réel.

Or, le réseau IP repose aujourd'hui :

• sur des machines dont les système d'exploitation ne sont pas des systèmes temps réel
• sur des protocoles qui ne peuvent garantir le résultat et encore moins en temps fini

Le réseau IP repose sur le paradigme du best of qui est peu compatible avec le temps réel.

On devrait donc parler de temps court au lieu de temps réel. On peut parler aussi de temps synchrone entre deux automates, dans la transaction entre le serveur et le client.

Le mode flash SEPAmail est un mode synchrone alors que le mode canonique est un mode asynchrone.

Le service web (web services) peut être vu comme une généralisation du service de page web à l'internaute.
Les protocole de la famille tcp/ip (dont http) ont permis dans un premier temps à des automates de servir de l'information sous forme de pages html à des êtres humains organisés.

Très vite, des automates programmables doués d'ubiquité se sont substitués aux internautes pour transformer, traiter l'information et la restituer autrement (opérés de façon exceptionnelles par exemple par google, yahoo, kelkoo). Les services webs sont apparus pour permettre la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Les services webs présentent des particularités souvent oubliées et qu'il convient de bien appréhender dans le cadre de SEPAmail. Ils sont généralement en mode client/serveur avec une structure de coût essentiellement déportée sur le serveur. Ils sont plutôt gros consommateurs de ressources par rapport à d'autres implémentations. Ils sont souvent concurrentiels sur le réseau IP des transactions hommes/machines et l'articulation avec les échanges homme/machine est rarement facile à mettre en place.

L'engouement pour les architecture reposant sur des appels de procédures à distances (RPC ou Remote Procedure Call) a permis de régler quelques problématiques liés au secret de fabrication, au coûts d'intégration ou encore aux contraintes de distribution des services.

C'est dans ce contexte que SEPAmail a conçu un mode flash de cette messagerie sécurisée qui, devrait, à terme, n'être utilisé que pour les messages à forte valeur ajoutée pour les clients finaux.