Marier le contrôle d'accès au réseau (NAC) et la gestion des identités (IAM) apparait inévitable à terme. Ensembles, les deux approches permettent une gestion au plus fin des scénarii d'accès.

Le scénario a de quoi faire rêver bon nombre d'administrateurs. Un vice-président "finances" souhaite accéder aux applications de gestion financière de l'entreprise. Son rôle, défini par une solution d'IAM fraichement déployée, l'y autorise parfaitement. Mais aujourd'hui, il le fait depuis un ordinateur portable inconnu. Peut-être est-il à son domicile et emprunte-t-il celui de son épouse ? En tout cas, il s'agit d'un comportement contraire à la politique de sécurité de l'entreprise. Si la solution d'IAM n'en a cure, celle de contrôle d'accès (NAC) devrait, elle, mettre fin automatiquement à la connexion. Oui mais voilà, il s'agit d'un VIP. Et on n'aime guère froisser cette population choyée en lui raccrochant au nez. Le serveur NAC, après avoir interrogé le gestionnaire des identités, apprend qu'il s'agit d'un VIP et décide alors de le favoriser, sans pour autant lui donner accès libre. Après avoir contrôlé que son terminal, bien que inconnu, est tout de même propre, le NAC propage une série de règles sur les pare-feu et les filtres applicatifs de l'entreprise. Le VIP est désormais autorisé à consulter les données qu'il souhaite mais pas à les télécharger, ni à récupérer de fichiers Excel, par exemple.

Bien qu'un tel scénario soit déjà réalisable aujourd'hui à l'aide d'autres outils, son automatisation ne l'est pas encore. La gestion des identités (IAM) et le contrôle d'accès réseau (NAC) sont deux mondes bien différents, gérés par des équipes qui ne communiquent que très peu.

Selon Mark Bauhaus, Executive Vice President chez Juniper, il faut toutefois envisager d'oublier ces notions distinctes de contrôle d'accès au réseau et aux applications, au profit d'un unique contrôle d'accès aux "ressources IT" dans leur ensemble. "Pour l'instant, deux groupes d'administrateurs dans l'entreprise s'occupent de cela. Ils devront ne faire plus qu'un", explique-t-il.

Se pose alors bien entendu de savoir qui, dans l'entreprise, sera responsable de ce contrôle d'accès unique. Les métiers ou la IT ? Le modèle de workflow proposé par l'IAM pourrait offrir une piste de réponse : la IT gère l'outil de workflow et les métiers - qui sont au plus près de l'utilisateur- s'occupent des habilitations.

Il restera toutefois encore à faire communiquer IAM et NAC afin que les informations liées aux profils de l'un enrichissent les règles de l'autre. "Nous manquons aujourd'hui d'un standard qui permettrait, par exemple, à l'Identity Manager de Sun de partager ses informations avec les NAP, NAC ou UAC qui contrôlent l'accès conditionnel au réseau", poursuit Mark Bauhaus. Selon lui, un tel travail devrait - et pourrait - venir d'une collaboration entre le Trusted Computing Group et le groupe de travail SAML (Security assertion markup language) à l'OASIS. Le standard qui verrait le jour s'appuierait probablement sur SAML 2, qui intègre déjà le framework de fédération des identités de Liberty Alliance.

Nous n'en sommes toutefois pas encore là. Le NAC en est encore à convaincre l'entreprise de son intérêt (et à se chercher un standard) et l'IAM représente un projet majeur en tant que tel. Une passerelle standardisée entre les deux n'est donc certainement pas à l'ordre du jour chez les entreprises. Toutefois l'intérêt d'une telle collaboration entre des pièces aussi rationnelles et aussi critiques de la sécurité mérite très certainement réflexion.