L’on conviendra tous que les flux de messagerie sont devenus tout autant critiques que le fonctionnement de certaines bases de données métier au sein des entreprises. Arrêter les services de
messagerie est devenu parfois tout simplement impossible compte tenu du nombre d’information transitant par ce média. Au fur et mesure des projets en tout genre qu’il m’à été donné
d’entreprendre, j’ai pu constater que les flux applicatifs de messagerie, flux utilisés par les applications métiers, ne sont généralement pas contrôlés. L’idée n’est évidement pas de
systématiquement dans un environnement partiellement sécurisé que constitue le réseau local de l’entreprise, de « fliquer » les communications mais simplement recenser, voir normaliser
les protocoles de communications de l’outil de messagerie.
Les flux applicatifs de messagerie sont généralement initiés par des applications diverses, développées par différentes équipes, utilisant à leurs tours différentes plateformes de développement.
Dans la plupart des cas, les connaissances en matières de sécurisation des protocoles Smtp, Pop3, Imap4 (Authentification, Cryptage, signature etc..) sont quasi inconnu des développeurs ou chef
de projet. Ils se contentent simplement de l’utilisation des telles ou telles fonctions fournie par l’interface de développement.
La conséquence de cette situation conduit généralement à la mise en place quelque peu précipitée d’un service d’envoi et de réception totalement ouvert , sans authentification préalable
permettant au flux métier de pouvoir envoyer et recevoir sans véritable contrôle des messages depuis , ou vers le réseau Internet. L’open relai est une faille de sécurité importante car il
permet facilement l’usurpation d’identité sans pouvoir en déterminer la source (Absence d’authentification). De plus, l’absence de contrôle des méthodes de connexions complexifie
l’évolution des infrastructures de messagerie. Le déplacement des services d’envoi et de réception de message est alors hasardeux compte tenu de la non-connaissance par les équipes technique de
l’utilisation faite par les progiciels métiers. L’outil ou du moins l’utilisation qui en est faite échappe alors à son gestionnaire. Or je pense que cela n’est pas souhaitable à
terme, la normalisation des protocoles d’échange doit nécessairement être établie car elle est souvent beaucoup plus critique pour l’entreprise que la communication interpersonnelle dont
l’importance de certain sujet reste encore à démontrer…
Vers une normalisation des échanges
Comme précisé en introduction l’Entreprise doit pouvoir contrôler l’usage qui est fait de son principal outil de communication à savoir son outil de messagerie. Il convient donc de proposer à
l’ensemble des acteurs concernés une normalisation des échanges. Cette proposition de normalisation devrait inclure plusieurs niveaux de sécurité pour permettre à certaines applications aux
fonctionnements basiques de pouvoir malgré tout continuer à envoyer ou recevoir des messages. Je propose donc une normalisation à plusieurs niveaux avec la suppression progressive de ces relais
ouverts permettant à quiconque d’envoyer au nom d’une personne interne un message à destination de l’interne ou de l’externe.
Le premier niveau à prendre en compte est l’authentification des serveurs ou stations de travail devant initier une connexion vers les services de messagerie. Par la même, les administrateurs de
plateformes de messagerie pourront restreindre l’utilisation des services SMTP à ces dernières, évitant que tout utilisateurs depuis son poste puisse envoyer en dehors de son traditionnel client
de messagerie des messages au nom d’autre personne. La restriction s’effectuera la plupart du temps par une interdiction du relai ouvert exception faite des machines concernées. Dans la
plupart des cas ces restrictions se feront soit par adresse IP soit par le nom pleinement qualifié (nomdelastation.nomdudomaineinterne.extension). Cette protection constitue le premier niveau de
sécurisation. La problématique dans sa mise en place réside dans l’authentification des machines. Pour ce faire, les journaux de connexion des actuels serveurs SMTP/POP/IMAP seront d’une grande
utilité.
Le deuxième niveau concerne le premier aspect de normalisation à mettre en place. En effet, les applications émettrices peuvent adresser les services SMTP de plusieurs façons. La première méthode
est l’adressage direct via l’adresse IP. La seconde est l’utilisation d’un nom pleinement qualifié dont la résolution peut être assurée par les services DNS de l’entreprise ou localement par le
biais d’un fichier host. Dans tout les cas, ces méthodes ralentissent considérablement les déplacements de services SMTP lors des opérations de migration d’infrastructure. Elle complexifie
également les tests de plan de reprise d’activité. IL faut donc mettre en place un adressage commun relatif comme le nom DNS le permet, et imposer ce dernier à tous les environnements de
développement. Une fois réalisé, il sera très simple de basculer un service SMTP vers un autre serveur sans véritable conséquence pour les flux applicatifs. On pensera également à baisser la
durée de vie des ces enregistrements afin de faciliter la convergence en cas de basculement de service.
Le troisième niveau de concerne l’authentification des connexions applicatives. Ici plusieurs techniques sont possibles. Dans la plupart des cas il faudra composer avec ce que sont capable de
faire les applications métiers. Certaines seront capables d’utiliser plusieurs méthodes d’authentification plus ou moins sécurisées, d’autre ne proposeront qu’un seul type d’authentification de
type plaintext. (Passage du mot de passe en clair sur le réseau cf : http://tools.ietf.org/html/rfc4616). La rfc4954 (http://tools.ietf.org/html/rfc4954) définie par l’IETF précise la façon dont une application peut négocier son authentification. Il existe à ce jour
plusieurs protocoles d’authentification (GSSAPI, DIGEST-MD5,PLAIN,CRAM-MD5,NTLM) qui seront supportées ou pas, selon votre solution de messagerie. On précisera ici qu’il s’agit d’authentification
simple. Ces mécanismes d’authentification sont intégralement décrit dans la Rfc 4422 (http://tools.ietf.org/html/rfc4422) .
A ce stade plusieurs organisations sont possibles. La première est d’utiliser un seul et même compte utilisateur pour l’ensemble des applications métiers. Solution que je ne conseillerai pas en
raison de l’impact que pourrai avoir la suppression de ce compte ou le changement de son mot de passe. La seconde est d’utiliser un compte générique par applications métier. De cette façon vous
contrôlerez beaucoup mieux le modèle de permissions et minimiserez l’impact d’un changement de mot de passe.
Le quatrième niveau consiste à mettre en place une solution sécurisée basée sur le cryptage systématique des flux internes. Elle demandera l’utilisation de certificat permettant de mettre en
place la couche SSL. Elle sera nécessaire si vous désirez sécuriser les flux de réception utilisés par vos applications métiers (POPs/Imaps). Par défaut Exchange 2007 est d’ailleurs paramétré
pour n’utiliser que la couche sécurisée des deux protocoles précités.
Une évolution alternative consiste à utilisez pour les applications ayant la nécessitée d’interagir fortement avec la messagerie (Messagerie, Calendrier etc..) , le protocole propriétaire utilisé
par les clients de messagerie (Ex : Mapi pour Microsoft Exchange). Certains d’entre eux sont également accessibles par le biais de protocole plus standardisés comme cela est le cas
dans l’environnement Microsoft Exchange 2007 via les Webservices. (http://msdn.microsoft.com/en-us/library/bb204119.aspx)
Conclusion
Sans céder aux tentations de la sécurisation à outrance, la sécurisation des flux de messagerie engendrés par les applications métiers est nécessaire pour éviter la perte de contrôle de
l’utilisation de l’outil. Du simple référencement à la mise en place d’authentification basée sur une couche de transport cryptée, plusieurs niveaux sont possibles. Nul doute que la mise en place
sera longue et progressive car elle demandera des modifications des développement existants. Malgré cela l’entreprise gagnera en souplesse facilitant la reprise d’activité et les opérations de
modification d’infrastructure, tels que les migrations et les montées de version. En tout état de cause elle renforcera son niveau de sécurité.
Commentaires