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…

 

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)

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é.