requérir cette authentification forte (de type certificat utilisateur via une carte à puce, ou encore une solution de One Time Password dite OTP) dès la « bordure » de l’entreprise. Celle-ci fournira ensuite via des mécanismes de SSO, une délégation d’accès transparente et sécurisée aux données stockées dans Sharepoint/Moss.
D’autre part, la possibilité de publier un ou plusieurs Intranets au sien d’un même portail permet de disposer d’une architecture centralisée, facile à maintenir, ce qui s’avère être un atout majeur pour les entreprises multi-intranets. L’utilisateur distant verra, en fonction de ses droits (appartenance à un groupe, annuaire LDAP, …) et des politiques de sécurité (par application) apparaître à l’écran un portail spécifiquement généré pour lui et potentiellement dans la langue qu’il aura choisie. Sur le portail d’entreprise ci-dessous, nous pouvons imaginer une entreprise utilisant un seul serveur IAG (éventuellement avec une solution de haute disponibilité) pour publier les sites Sharepoint et MOSS Européens.
La publication d’un intranet Sharepoint/ MOSS se fait via un assistant de publication spécifiquement développé par les experts Microsoft. Cette approche permet de garantir que le « I » de IAG (pour Intelligent) qui va être en mesure d’analyser le flux de données lors de cette publication. Ce « filtre applicatif SharePoint » est en fait la modélisation de tout ce qui est « normal » (Liste d’URL, paramètres passés, verbes http comme GET, POST, …) dans une consultation de site web SharePoint/MOSS. En conséquence, tout comportement « anormal » sera rejeté par IAG garantissant un haut niveau de sécurité. Tout comme le filtre pour OWA dispose de 84 règles, le filtre SharePoint 2003 en propose 92.
Un autre moyen de sécuriser les Intranets Sharepoint/MOSS avec IAG, est de conditionner les accès au portail et aux applications en fonction du niveau de conformité du poste client. Ceci permet d’imposer un niveau de conformité du poste client en fonction de la politique de sécurité pour l’accès au portail, mais aussi pour chacune des applications publiées à l’intérieur de celui-ci.
Dans notre exemple, nous avons créé un portail nommé « Portail d’entreprise SPS/MOSS Corp » avec ces conditions d’accès et les conditions d’accès aux applications. Si nous détaillons l’accès au portail, nous constatons que nous pouvons nous connecter à partir de n’importe quel poste de travail (condition type de poste) disposant d’un antivirus (condition politique de conformité) et à condition d’être membre du groupe « d’utilisateurs Corp » (condition de permission d’accès).
Une fois authentifié, le portail présentera les applications disponibles pour l’utilisateur en fonction de son appartenance aux groupes d’accès, du type de poste et des autres conditions. Si nous faisons un focus sur la publication de l’application « portail MOSS Corp », nous pouvons voir deux cas distincts en fonction du type de poste (Poste d’entreprise ou non) :
• Dans le premier cas, nous accédons à l’Intranet MOSS à partir d’un poste de l’entreprise (condition type de poste). Le poste client étant un poste d’entreprise, nous le considérons comme « gérer » et nous avons donc autorisé le téléchargement montant et descendant de document. Le choix d’autoriser le téléchargement montant peut se justifier car le poste client est un poste d’entreprise et l’accès au portail nous a imposé d’avoir un antivirus.
Le risque de transférer un document avec un virus est donc très faible. Le choix d’autoriser le téléchargement descendant peut également se justifier car le poste client est un poste d’entreprise et il n’y a donc pas de risque de transfert de document confidentiel sur un ordinateur non métrisé.
• Dans le deuxième cas, nous n’avons pas autorisé le téléchargement montant et descendant de document car les postes client sont de type « gérés et non gérés ». Nous ne prendrons donc pas le risque de télécharger (en montée comme en descente) des documents sur ou à partir d’un ordinateur potentiellement à risque comme par exemple dans un cybercafé.
Dans les deux cas, la politique de conformité impose d’avoir installé « l’Attachment Wiper » (condition de politique de sécurité). L’Attachment Wiper est un composant ActiveX fourni nativement avec IAG permettant de vider le cache du navigateur une fois la session terminée. Dans le cas où nous accédons à l’application à partir d’un Cybercafé, ceci nous garantit donc que nous ne laisserons pas d’information sur le poste client après notre passage. Globalement, la publication d’un ou plusieurs Intranet Sharepoint/ MOSS au travers d’IAG permet :
• De profiter des opportunités d’authentification apportées par le portail IAG (Ex : authentification forte),
• La centralisation des informations dans le cas où nous disposons de plusieurs serveurs MOSS à publier, mais également d’autres types d’applications (web ou non web),
• De profiter du filtrage « évolué » apporté par IAG aussi bien au niveau des URLs mais aussi au niveau du contenu (Ex : les 92 règles de filtrage créées automatiquement avec l’assistant de Sharepoint 2003),
• De définir des règles de conformité très poussées aussi bien au niveau du portail qu’au niveau de chaque Intranet SPS/MOOS.
