Audit au niveau des éléments avec Sharepoint Server 2007

Paru le 09 mars 2007

**Résumé :**Découvrez la prise en charge d'audit intégrée dans Microsoft Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007, et comment étendre cette prise en charge grâce à la solution Item-Level Auditing personnalisée. (29 pages imprimées)

Ted Pattison (Ted Pattison Group)

Joanna Bichsel (Microsoft Corporation)

**S'applique à :**Microsoft Office System 2007, Microsoft Office SharePoint Server 2007, Microsoft Windows SharePoint Services 3.0.

Télécharger MOSSSampleItemLevelAuditing.exe.

Item-Level Auditing with SharePoint Server 2007 

Sur cette page

Audit avec SharePoint Server 2007
Prise en charge d'audit intégrée dans Windows SharePoint Services et Office SharePoint Server 2007
Audit au niveau des éléments : une solution d'audit personnalisée
Affichage des entrées à partir du journal d'audit
Item-Level Auditing
Écriture d'entrées d'audit personnalisées
Prise en charge à valeur ajoutée des audits dans Office SharePoint Server 2007
Prise en charge de la création de rapports d'audit dans Office SharePoint Server 2007
Création d'un classeur Excel à partir des informations du journal d'audit
Rendu d'un classeur côté serveur à l'aide d'Excel Services
Empaquetage de la solution Item-Level Auditing en vue de son déploiement
Conclusion
Ressources supplémentaires

Audit avec SharePoint Server 2007

De nombreuses entreprises et agences gouvernementales sont soumis à des stratégies et des règlementations qui leur imposent un suivi rigoureux du lieu et du mode d'accès aux enregistrements et aux documents importants par les utilisateurs. Elles doivent notamment maintenir des journaux d'audit qui détaillent les événements qui assurent le suivi des données telles que l'identité des utilisateurs qui ont affiché ou mis à jour des enregistrement et documents, et la date à laquelle ces événements sont intervenus.

Auparavant, Microsoft Windows SharePoint Services 2.0 n'offrait pas de prise en charge exhaustive des audits. Par exemple, vous ne pouviez pas utiliser de composant pour vérifier l'accès aux pages ou l'accès aux éléments contenus dans des listes. De plus, les gestionnaires d'événements situés dans les bibliothèques de documents de Windows SharePoint Services 2.0 se déclenchaient uniquement lorsqu'un document d'une bibliothèque était mis à jour. Par conséquent, les gestionnaires d'événements situés dans les bibliothèques de documents de Windows SharePoint Services 2.0 ne fournissaient pas de prise en charge pour l'audit des événements qui se produisent lorsque des utilisateurs affichent des documents.

En réponse aux demandes d'utilisateurs, la dernière version des produits et technologies Microsoft SharePoint fournit désormais un certain nombre d'améliorations pour la prise en charge des audits, qui sont toutes incluses dans Microsoft Office System 2007. Microsoft Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007 fournissent tous deux une prise en charge de l'audit de l'accès des utilisateurs aux pages, aux contenus et aux documents, et incluent des événements pouvant être audités tels que l'affichage et la mise à jour.

Prise en charge d'audit intégrée dans Windows SharePoint Services et Office SharePoint Server 2007

Windows SharePoint Services 3.0 propose désormais une journalisation d'audit intégrée que vous pouvez activer et configurer au niveau d'une collection de sites. Lorsque vous activez l'audit, Windows SharePoint Services écrit les entrées d'événement d'audit dans une table de journaux d'audit stockée à l'intérieur de la base de données de contenu. Les entrées d'événement d'audit pour une collection de sites sont stockées avec tous les autres contenus Windows SharePoint Services tels que les éléments de liste, les documents, et les personnalisations de composants WebPart. Lorsque vous sauvegardez une collection de sites, toutes les information contenues dans le journal d'audit sont également sauvegardées.

Bien que Windows SharePoint Services fournisse les mécanismes de base pour l'audit, il n'offre pas de prise en charge intégrée pour permettre aux utilisateurs d'activer l'audit. Comme Windows SharePoint Services ne fournit pas la fonctionnalité permettant de voir les entrées écrites dans le journal d'audit, un développeur doit écrire du code pour activer la fonctionnalité de journalisation d'audit de Windows SharePoint Services. Un développeur doit également fournir du code et une interface utilisateur pour lire les entrées du journal d'audit et afficher ces données aux utilisateurs du site. L'exemple de code qui accompagne cet article indique comment créer ce type de solution d'audit personnalisée.

Si Windows SharePoint Services fournit les mécanismes de base pour l'audit, Office SharePoint Server 2007 apporte une valeur ajoutée en fournissant une interface utilisateur d'administration permettant l'audit au niveau des collections de sites. Office SharePoint Server 2007 va même encore plus loin et permet l'audit au niveau d'une liste ou d'une bibliothèque de documents, ainsi que le contrôle sur les types d'événements qui doivent être enregistrés dans le journal d'audit. Office SharePoint Server 2007 fournit également une fonction de rapport qui utilise les classeurs de Microsoft Office Excel pour afficher et conserver les enregistrement des journaux d'audit. Office SharePoint Server 2007 vous permet donc de bénéficier de la prise en charge d'audit de Windows SharePoint Services, sans avoir à écrire de code personnalisé.

Audit au niveau des éléments : une solution d'audit personnalisée

Cet article est accompagné d'une solution personnalisée appelée Item-Level Auditing (MOSSSampleItemLevelAuditing.exe) qui démontre des techniques permettant d'étendre la prise en charge d'audit disponible dans Windows SharePoint Services et dans Office SharePoint Server 2007. Tout d'abord, cette solution personnalisée indique comment étendre Windows SharePoint Services en activant la journalisation d'audit par programmation. Elle fournit également un composant d'interface utilisateur qui affiche les contenus du journal d'audit aux utilisateurs des sites Windows SharePoint Services. Cette solution personnalisée décrit également comment étendre Office SharePoint Server 2007 en ajoutant une prise en charge améliorée de la création de rapports à l'aide des nouveaux formats XML ouverts Office pour produire des classeurs Excel à partir des informations d'audit. La solution Item-Level Auditing indique également comment résoudre un problème qui n'est actuellement pas résolu par Windows SharePoint Services ou Office SharePoint Server 2007. En particulier, cette solution personnalisée démontre comment afficher et créer un rapport sur les entrées du journal d'audit qui sont associées à un seul élément d'une liste ou à un seul document d'une bibliothèque de documents.

L'intégralité de l'échantillon de code de cette solution est contenu dans un projet Microsoft Visual Studio 2005 nommé ItemAuditing.csproj. La figure 1 présente une vue des divers fichiers qui composent la solution. Ces fichiers de projet utilisent un grand nombre de nouvelles techniques de développement introduites dans Windows SharePoint Services 3.0, telles que les pages d'application, les fonctionnalités, et les packages de solution personnalisés.

Figure 1. Projet ItemAuditing

Avant de commencer, assurez-vous que les éléments suivants sont installés sur votre ordinateur de développement :

• Microsoft .NET Framework 3.0 (version RTM)

• Microsoft Visual Studio 2005

• Microsoft Windows SharePoint Services 3.0

• Microsoft Office SharePoint Server 2007

Ensuite, téléchargez le fichier MOSSSampleItemLevelAuditing.exe et procédez à l'extraction du contenu dans un répertoire de votre ordinateur de développement. Vous pouvez désormais suivre les instructions de Setup Document.docx pour exécuter l'exemple de solution. Au terme des instructions du document d'installation, vous disposerez du projet Visual Studio 2005 complet sur votre ordinateur. Le reste de cet article explique les divers éléments qui font fonctionner cette solution.

La solution Item-Level Auditing est composée des éléments suivants :

• Une fonctionnalité Windows SharePoint Services nommée Item Auditing

• Deux pages d'application appelées AuditLogViewer.aspx et ItemAudit.aspx

• Un gestionnaire personnalisé nommé Auditlogworkbook.ashx

• Un assembly nommé ItemAuditing.dll

Commençons par examiner la fonctionnalité Item Auditing et son fichier feature.xml.

        Xml

        <Feature Id="AA929AFF-4602-4d7f-A501-B80AC9A4BB52"
        Title="Item Auditing"
        Description="This feature allows user to view the audit history of documents."
        ImageUrl="CALVIEW.GIF"
        Version="1.0.0.0"
        Scope="Site"
        ReceiverAssembly="ItemAuditing, Version=1.0.0.0, Culture=neutral, 
          PublicKeyToken=7fd3ed697555604d"
        ReceiverClass="ItemAuditing.ItemAuditingFeatureReceiver"
        xmlns="https://schemas.microsoft.com/sharepoint/">

        <ElementManifests
        >
        <ElementManifest Location="elements.xml"
        />
        </ElementManifests
        >

        </Feature
        >
      

Une fonctionnalité Windows SharePoint Services 3.0 est toujours installée dans l'étendue définie au niveau de la batterie de serveurs. Cependant, vous pouvez définir l'étendue d'activation d'une fonctionnalité sur quatre niveaux différents. Une fonctionnalité peut être conçue pour être activée dans l'étendue d'un site, d'une collection de sites, d'une application Web ou d'une batterie de serveurs. Dans notre cas, la fonctionnalité Item Auditing a été conçue avec une étendue d'activation au niveau d'une collection de sites. Dans l'élément Feature, décrit précédemment, vous pouvez voir que l'attribut Scope est défini sur Site, ce qui signifie qu'elle est activée dans l'étendue d'une collection de sites. Si vous voulez créer une fonctionnalité activée dans l'étendue d'un site au lieu d'une collection de sites, vous devez attribuer une valeur Web au lieu de Site à l'attribut Scope.

Une fois la fonctionnalité Item Auditing installée dans une batterie de serveurs Windows SharePoint Services, elle est disponible pour activation dans n'importe quelle collection de sites située au sein de la batterie de serveurs. Si vous vous rendez sur la page d'administration Fonctionnalités de la collection de sites, vous devriez pouvoir activer la fonctionnalité, comme illustré à la figure 2.

Figure 2. Page d'administration Fonctionnalités de la collection de sites

Si vous examinez l'élément Feature dans le fichier feature.xml, vous remarquerez qu'il y a un attribut ReceiverAssembly et un attribut ReceiverClass. Cette technique permet à la fonctionnalité de référencer un assembly avec une classe qui fournit un gestionnaire d'événements qui se déclenche lorsque la fonctionnalité est activée. Ce type de gestion des événements spécifique à la fonctionnalité est rendu possible par l'écriture d'une classe personnalisée qui hérite de la classe SPFeatureReceiver, comme indiqué dans la classe ItemAuditingFeatureReceiver dans le code suivant.

        C#

        using System;
        using Microsoft.SharePoint;

        namespace ItemAuditing {

        public class ItemAuditingFeatureReceiver : SPFeatureReceiver {

        public override void FeatureActivated(SPFeatureReceiverProperties properties)  {
        // The feature activation code goes here.
        }

        public override void FeatureInstalled(SPFeatureReceiverProperties properties) { }
        public override void FeatureUninstalling(SPFeatureReceiverProperties properties) { }
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties) { }

        }
        }
      

La classe de récepteur de la fonctionnalité qui est créée pour la solution Item-Level Auditing fournit le code uniquement dans la méthode de gestionnaire d'événements FeatureActivated. Cependant, trois autres méthodes peuvent être écrites pour fournir le comportement de traitement d'événements lorsqu'une fonctionnalité est installée, et lorsqu'elle est cours de désactivation ou de désinstallation.

Lorsque la fonctionnalité Item Auditing est activée, sa méthode de gestionnaire d'événements FeatureActivated exécute le code nécessaire pour activer la fonctionnalité d'audit de Windows SharePoint Services. Le code situé dans le gestionnaire d'événements active cette fonctionnalité en obtenant une référence à un objet SPSite pour la collection de sites actuelle, puis en définissant les indicateurs d'audit corrects sur la propriété Audit de l'objet SPSite.

        C#

        public override void FeatureActivated(SPFeatureReceiverProperties properties)  {

        SPSite siteCollection = (SPSite)properties.Feature.Parent;
        // Turn on auditing flags.
        siteCollection.Audit.AuditFlags = SPAuditMaskType.All;
        siteCollection.Audit.Update();

        // Modify title of top-level site.
        SPWeb site = siteCollection.RootWeb;
        site.Title += " (audited)";
        site.Update();

        SPListTemplate template = site.ListTemplates["Document Library"];
        Guid docLibID = site.Lists.Add("AuditLogs", "Library for Audit Log Workbooks", template);
        SPList docLib = site.Lists[docLibID];
        docLib.OnQuickLaunch = true;
        docLib.Update();
        }
      

Comme le code l'indique, le gestionnaire d'événements FeatureActivated met également à jour le titre du site de niveau supérieur pour vous indiquer visuellement qu'il s'est exécuté avec succès. Il y a aussi du code pour créer une bibliothèque de documents appelée Journaux d'audit dans le site de niveau supérieur. Cette bibliothèque de documents est utilisée comme référentiel pour les classeurs Office Excel qui contiennent les données de journalisation d'audit. Vous trouverez des informations complémentaires dans les dernières sections du présent article.

Concentrons-nous pour le moment sur le code qui active la journalisation au niveau de la collection de sites. La propriété Audit expose un objet SPAudit, qui fournit une propriété AuditFlags. La propriété AuditFlags est basée sur l'énumération SPAuditMaskType et peut être attribuée simplement avec une valeur All pour activer toutes les fonctionnalités d'audit. Notez également qu'un appel à la méthode Update est nécessaire après modification des indicateurs d'audit sur un objet SPAudit.

        C#

        siteCollection.Audit.AuditFlags = SPAuditMaskType.All;
        siteCollection.Audit.Update();
      

Nous venons de voir comment activer l'audit pour une collection de sites entière. Cependant, vous devez comprendre que cette opération peut se révéler très coûteuse pour une collection contenant de nombreux sites avec un volume de trafic important. Par exemple, si vous avez une grande collection de sites avec de nombreux utilisateurs actifs, ou si vous effectuez l'audit d'opérations fréquentes telles que lectures de page, le journal d'audit se remplira très rapidement de données.

Dans certains cas, par exemple lorsque vous concevez un référentiel pour les documents confidentiels d'une agence gouvernementale, vous voudrez peut-être enregistrer tous les événements pouvant être audités. Cela risque de vous conduire à activer tous les événements pouvant être audités au niveau de la collection de sites. Vous pourriez également envisager de rassembler tous les documents confidentiels dans leur propre collection de sites pour ne pas avoir à journaliser le même niveau d'informations d'audit lorsque les utilisateurs affichent des documents non confidentiels.

D'autres scénarios peuvent survenir dans lesquels vous souhaiterez davantage de contrôle sur les éléments objets d'un audit dans l'étendue d'une même collection de sites. Par exemple, vous souhaiterez peut-être vérifier uniquement les opérations de mise à jour, mais pas les opérations de lecture. Vous devrez peut-être effectuer un audit sur une bibliothèque de documents, mais pas sur une autre du même site. Heureusement, Windows SharePoint Services vous permet de définir davantage le mode d'activation de l'audit. Vous pouvez par exemple activer l'audit pour une bibliothèque de documents unique.

        C#

        SPSite siteCollection = new SPSite("http://LitwareServer1");
        SPWeb site = siteCollection.OpenWeb();
        SPList list = site.Lists["Proposals"];
        list.Audit.AuditFlags = SPAuditMaskType.All;
        list.Audit.Update();
      

Notez aussi que lorsque vous activer l'audit, vous n'êtes pas obligé de journaliser tous les types d'événements pouvant être audités. Certains indicateurs d'audit vous permettent de contrôler les types d'événements d'audit que vous souhaitez journaliser grâce à Windows SharePoint Services. Les valeurs d'énumération de SPAuditMaskType sont des indicateurs au niveau du bit qui peuvent être utilisés ensemble pour configurer le jeu exact d'événements d'audit que vous souhaitez capturer.

        C#

        list.Audit.AuditFlags = SPAuditMaskType.View |
        SPAuditMaskType.Update |
        SPAuditMaskType.Delete;
        list.Audit.Update();
      

Le code précédent est un exemple d'un sous-ensemble de types d'événements que vous pouvez inclure dans le journal d'audit. Voici une liste complète des différentes valeurs d'énumération disponibles.

        C#

        SPAuditMaskType.CheckIn
        SPAuditMaskType.CheckOut
        SPAuditMaskType.ChildDelete
        SPAuditMaskType.Copy
        SPAuditMaskType.Delete
        SPAuditMaskType.Move
        SPAuditMaskType.ProfileChange
        SPAuditMaskType.SchemaChange
        SPAuditMaskType.Search
        SPAuditMaskType.SecurityChange
        SPAuditMaskType.Undelete
        SPAuditMaskType.Update
        SPAuditMaskType.View
        SPAuditMaskType.Workflow
      

Affichage des entrées à partir du journal d'audit

Maintenant que nous avons vu comment activer la journalisation d'audit, nous pouvons nous concentrer sur l'affichage des informations d'événement aux utilisateurs des sites à partir du journal d'audit. La solution Item-Level Auditing fournit une page d'application nommée Auditlogviewer.aspx. Le but de cette page est d'afficher l'intégralité du contenu du journal d'audit de la collection de sites aux administrateurs du site.

La solution Item-Level Auditing inclut un fichier nommé elements.xml, qui fournit deux éléments CustomAction Element (Custom Action). L'élément CustomAction ajoute un élément de menu au menu Actions du site, lequel permet aux administrateurs du site de naviguer dans Auditlogviewer.aspx.

        Xml

        <!-- Add Command to Site Actions Dropdown -->
        <CustomAction Id="SiteActionsToolbar"
        GroupId="SiteActions"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1001"
        Title="Audit Log Viewer"
        Description="This page allows you to see the audit log."
        RequireSiteAdministrator="True"
        ImageUrl="/_layouts/images/LTTXTBOX.GIF">
        <UrlAction Url="~sitecollection/_layouts/AuditLogViewer.aspx"/>
        </CustomAction
        >
      

Cet élément CustomAction a été conçu pour ajouter l'élément de menu illustré à la figure 3. L'élément CustomAction a été défini avec un attribut RequiresSiteAdministrator auquel une valeur True a été attribuée. Puisque la fonctionnalité Item Auditing d'hébergement est associée à une étendue de collection de sites, cela signifie que l'élément de menu est uniquement affiché aux utilisateurs sont propriétaires de collection de sites. Vous pouvez également voir que l'attribut URL de l'élément UrlAction a été configuré avec une URL qui contient le jeton ~sitecollection. Cela signifie que Windows SharePoint Services peut analyser une URL de façon dynamique pour rediriger l'utilisateur vers cette page d'application en fonction du chemin de racine vers la collection de sites actuelle.

Figure 3. Élément de menu personnalisé

Lorsque les propriétaires de collection de sites cliquent sur l'élément de menu pour naviguer sur la page Audit Log Viewer, ils sont redirigés vers la page d'application personnalisée nommée Auditlogviewer.aspx située dans le répertoire Virtual Layouts. Cette page d'application personnalisée lit toutes les informations d'événement à partir du journal d'audit de la collection de sites et les affiche en utilisant un contrôle SPGridView, comme illustré à la figure 4.

Figure 4. Page Audit Log Viewer

La création de pages d'application personnalisées telles qu'Auditlogviewer.aspx offre une technique permettant d'ajouter des composants d'interface utilisateur à une solution Windows SharePoint Services qui contient du code personnalisé. Contrairement aux pages de site (par ex. default.aspx), les pages d'application personnalisées sont déployées une fois par batterie de serveurs et ne peuvent pas être personnalisées individuellement pour chaque site. Exécutées hors du répertoire virtual_layout et compilées dans une DLL d'assemby unique utilisée dans tous sites dans la batterie de serveurs, les pages d'application offrent de meilleures performances que les pages de site. Contrairement aux pages de site, les pages d'application vous permettent également d'y ajouter directement du code.

Les pages d'application personnalisées sont souvent créées pour être liées à application.master, le principal fichier de page maître utilisé par les pages d'application standard de Windows SharePoint Services. En règle générale, vous devez écrire les pages d'application de sorte qu'elles héritent d'une classe de base définie dans l'assembly Microsoft.Sharepoint nommée LayoutsPageBase. Voici un point de départ pour la disposition de base d'une page d'application personnalisée telle que Auditlogviewer.aspx.

        <%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, 
          Culture=neutral,PublicKeyToken=71e9bce111e9429c"%>
        <%@ Page Language="C" MasterPageFile="~/_layouts/application.master"
        Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase"  %>
        <%@ Import Namespace="Microsoft.SharePoint" %>
        <%@ Import Namespace="System.Data" %>
        <%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls"
        Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, 
          PublicKeyToken=71e9bce111e9429c" %>

        <script runat="server">
        protected override bool RequireSiteAdministrator {
        get { return true;}
        }
        protected override void OnLoad(EventArgs e)  {
        // Code goes here.
        }
        </script>

        <asp:Content ID="contentMain" ContentPlaceHolderID="PlaceHolderMain" 
          runat="server">
        <asp:Button ID="cmdRefreshPage" runat="server" Text="Refresh Page"
        OnClick="cmdRefreshPage_Click" />
        <asp:Button ID="cmdDeleteAllEntires" runat="server" Text="Clear Audit Log"
        OnClick="cmdDeleteAllEntires_Click" />
        <hr />
        <SharePoint:SPGridView ID="SPGridView1" runat="server" 
          AutoGenerateColumns="False" />
        </asp:Content>
      

Le code de cette page remplace la propriété RequireSiteAdministrator et renvoie une valeur True. Cela vous permet de verrouiller une page d'application de façon beaucoup plus sûre. Si vous remplacez la propriété RequireSiteAdministrator de la sorte, vous créez un environnement beaucoup plus sûr. Lorsqu'un utilisateur qui n'est pas administrateur du site essaie de naviguer dans cette page d'application, Windows SharePoint Services le redirige vers sa page Accès refusé standard.

Cette définition d'Auditlogviewer.aspx possède un bloc de script en haut du code qui programme selon le modèle d'objet. Lorsque vous programmez une page comme celle-là dans Visual Studio 2005, vous bénéficiez de la commodité de fonctions telles que le codage en couleurs et IntelliSense. Cependant, il est impératif d'ajouter a directive @Assembly appropriée en haut de la page. Vous devez modifier la directive @Assembly indiquée ci-dessus pour y inclure des informations pour l'assembly Microsoft.Sharepoint.

Les pages d'application sont utiles parce qu'elles fournissent un accès rapide et simple à l'objet Windows SharePoint Services. Après avoir créé une page d'application et fourni une implémentation de remplacement de la méthode OnLoad comme indiqué ci-dessus, vous pouvez obtenir des points d'entrée dans le modèle d'objet Windows SharePoint Services dans un contexte spécifique au site en utilisant le code suivant.

        C#

        protected override void OnLoad(EventArgs e)  {
        SPSite siteCollection = SPContext.Current.Site;
        SPWeb site = SPContext.Current.Web;
        }
      

La possibilité d'obtenir un contexte spécifique au site permet d'écrire des pages d'application beaucoup plus puissantes. Une page d'application peut se comporter différemment en fonction de votre chemin d'accès au site. Lorsque vous naviguez vers une page d'application via le contexte d'un site, il se comporte généralement différemment de si vous avez navigué vers la page via le contexte d'un autre site.

Nous allons maintenant aborder le code dans l'événement OnLoad qui est défini dans Auditlogviewer.aspx. Le code est écrit de façon à lire le journal d'audit de la collection de sites actuelle en créant un objet SPAuditQuery et en transmettant ensuite cet objet en tant que paramètre dans un appel à la méthode GetEntries. Un appel à la méthode GetEntries renvoie un objet SPAuditEntryCollection, qui permet d'examiner une entrée dans le journal d'audit cible en utilisant une simple boucle for…each.

        C#

        SPSite siteCollection = SPContext.Current.Site;
        SPAuditQuery wssQuery = new SPAuditQuery(siteCollection);
        SPAuditEntryCollection auditCol = siteCollection.Audit.GetEntries(wssQuery);

        foreach (SPAuditEntry entry in auditCol) {
        // inspect entry
        }
      

En examinant l'implémentation entière de la méthode OnLoad dans Auditlogviewer.aspx, vous pouvez constater qu'elle est écrite de sorte à afficher les informations d'événement d'audit en utilisant le contrôle SPGridView. Cette approche rend l'affichage des entrées d'audit cohérent avec les autres aspects de Windows SharePoint Services. Le remplissage du contrôle SPGridView avec des entrées d'audit implique la création d'un objet DataTable Microsoft ADO.NET, dans lequel il faut écrire les informations du journal d'audit. La technique de création et de remplissage d'un objet DataTable facilite la liaison de ces informations au contrôle SPGridView.

Notez que Windows SharePoint Services suit les heures des événements d'audit en se basant sur l'Heure universelle coordonnée (Heure de Greenwich). Après que le code de l'exemple d'application a récupéré l'heure, celle-ci est convertie à l'heure locale du serveur Web en appelant la méthode ToLocalTime qui est fournie par la classe DateTime de Microsoft .NET Framework. Mais si, par exemple, votre serveur Web frontal et votre utilisateur sont sur des fuseaux horaires différents, sachez que cet exemple d'application ne fournit pas de prise en charge pour la traduction des heures d'événement d'audit dans le fuseau horaire de l'utilisateur.

En examinant l'implémentation du code qui lit les informations du journal d'audit de Windows SharePoint Services, vous pouvez observer la façon dont elle récupère les noms d'utilisateur. Le journal d'audit de Windows SharePoint Services vérifie les ID d'utilisateur, mais pas les noms d'utilisateur. Après avoir obtenu un ID d'utilisateur, vous pouvez récupérer le nom d'utilisateur qui lui est associé en utilisant la méthode GetByID sur la collection SiteUser, qui est exposée en tant que propriété du site de niveau supérieur. Veillez à utiliser la collection SiteUsers : ne la confondez pas avec la collection Use, qui ne fournit pas les mêmes résultats.

        C#

        Private string GetUserNameById(int UserId, SPWeb site) {
        return site.SiteUsers.GetByID(UserId).Name;
        }
      

Certains clients pourraient vouloir exporter une partie de leurs journaux d'audit vers d'autres magasins externes, tels qu'une base de données ou une feuille de calcul Excel. L'exemple d'application fournit également un bouton de commande qui permet à l'utilisateur de vider le journal d'audit Windows SharePoint Services. Pour ce faire, appelez la méthode DeleteEntries sur l'objet SPAudit cible et passez un paramètre avec la date et l'heure limites de vidage de toutes les entrées qui ont fait l'objet d'un audit. Avant d'appeler DeleteEntries, vous pouvez fournir un code supplémentaire pour sauvegarder les données d'audit de façon sécurisée dans un magasin externe de votre choix pour vous assurer qu'aucune donnée d'audit importante n'est perdue.

Nous vous déconseillons d'utiliser ce bouton tel qu'il est actuellement implémenté, à moins qu'une logique personnalisée ne soit ajoutée à OnClick pour procéder à l'exportation avant la suppression. Cette logique n'a pas été ajoutée ici parce que différentes organisations peuvent souhaiter différents types de sauvegarde.

        C#

        // Add code here to export audit log into external store.
        SPSite siteCollection = SPContext.Current.Site;
        siteCollection.Audit.DeleteEntries(DateTime.Now.ToLocalTime().AddDays(1));
        siteCollection.Audit.Update();
      

Lorsqu'une solution d'audit personnalisée s'exécute au sein d'une grande collection de sites avec un trafic important, il peut être important d'enregistrer le journal d'audit dans des fichiers séparés et de le nettoyer. Vous pouvez souvent gérer l'espace de façon plus efficace en utilisant ce genre d'approche.

Item-Level Auditing

Maintenant que nous avons vu le code de base pour activer l'audit dans Windows SharePoint Services et afficher les informations d'événement d'audit aux utilisateurs, nous pouvons examiner comment ajouter la prise en charge nécessaire pour permettre aux utilisateurs de consulter les informations d'audit par document ou par élément. Nous démarrons en créant un élément de menu personnalisé dans le menu Edit Control Box (ECB) pour tous les documents de la collection de sites où la fonctionnalité Item Auditing est activée. L'objectif est que le menu ECB de chaque document de la collection de sites puisse fournir un élément de menu qui ressemble à ceci.

Figure 5. Élément de menu personnalisé dans le menu ECB

Un élément de menu personnalisé comme celui illustré à la figure 5 a été créé en ajoutant un deuxième élément CustomAction au fichier elements.xml de la fonctionnalité Item Auditing. L'élément CustomAction diffère de celui vu plus haut parce qu'il possède un attribut Location auquel est attribué une valeur de EditControlBlock. Cette valeur d'attribut indique à Windows SharePoint Services d'ajouter l'élément du menu au menu ECB pour une série spécifique d'éléments ou de documents. L'élément CustomAction définit les paramètres cibles pour l'élément du menu en utilisant un attribut RegistrationType avec une valeur List et un attribut RegistrationID de valeur de 101, l'identificateur pour les bibliothèques de documents Windows SharePoint Services standard. Notez que cet exemple d'application fournit uniquement un audit au niveau de l'élément pour les documents situés dans les bibliothèques de documents. Cependant, il pourrait être facilement étendu pour prendre en charge l'audit au niveau de l'élément pour n'importe quel type de liste.

        Xml

        <!-- Per Item Dropdown (ECB) Link -->
        <CustomAction Id="ItemAuditing.ECBItemMenu"
        RegistrationType="List"
        RegistrationId="101"
        ImageUrl="/_layouts/images/GORTL.GIF"
        Location="EditControlBlock"
        Sequence="300"
        Title="View Audit History">
        <UrlAction Url="~site/_layouts/ItemAudit.aspx?ItemId={ItemId}&amp;ListId={ListId}"
        />
        </CustomAction
        >
      

Observez également la valeur de l'attribut URL dans l'élément UrlAction. L'attribut URL est configuré comme suit.

        Xml

        ~site/_layouts/ItemAudit.aspx?ItemId={ItemId}&ListId={ListId}
      

Tout d'abord, notez que cette URL a été configurée pour rediriger l'utilisateur vers la deuxième page d'application personnalisée nommée Itemaudit.aspx. Vous pouvez également constater qu'il y a trois jetons dans cette URL, qui sont remplacées par Windows SharePoint Services de façon dynamique au moment de l'exécution. Le jeton ~site est remplacé par l'URL qui pointe sur le site actuel. Le jeton {ListId} est remplacé par le GUID qui identifie la bibliothèque de documents actuelle. Le jeton {ItemId} est remplacé par l'entier d'identification du document. Ces deux derniers jetons sont utilisés pour analyser une chaîne de requête qui peut transmettre à ItemAudit.aspx les informations dont il a besoin pour accéder au document cible et à la bibliothèque de documents qui le contient, en utilisant le modèle objet de Windows SharePoint Services.

Lorsque les utilisateurs sélectionnent le menu View Audit History du menu ECB pour un document particulier, ils sont redirigés vers la page d'application personnalisée nommée Itemaudit.aspx. Ils accèdent ensuite à un affichage du document, qui détaille des événements ayant fait l'objet d'un audit et qui ont été écrits dans le journal, comme illustré à la figure 6.

Figure 6. Page Itemaudit.aspx personnalisée

Maintenant que nous avons vu la page Itemaudit.aspx du point de vue de l'utilisateur, nous pouvons examiner son code. La structure fondamentale de cette page d'application est similaire à Auditlogviewer.aspx. Cependant, contrairement à Auditlogviewer.aspx, ItemAudit.aspx n'a pas été conçu pour un usage exclusif par les administrateurs du site. En fonction de leurs besoins, les autres utilisateurs peuvent également être autorisés à afficher ce code.

Examinons d'abord le code nécessaire pour extraire l'ID de l'élément de liste pour le document et le GUID pour la bibliothèque de documents de la chaîne de requête. Comme vous pouvez le voir dans le code précédent, cela est accompli en utilisant une technique de programmation standard impliquant la propriété QueryString de l'objet Request d'ASP.NET.

        C#

        SPSite siteCollection = SPContext.Current.Site;
        SPWeb site = SPContext.Current.Web;

        string ListId = Request.QueryString["ListId"];
        string ItemId = Request.QueryString["ItemId"];

        SPList list = site.Lists[new Guid(ListId)];
        SPListItem item = list.Items.GetItemById(Convert.ToInt32(ItemId));

        txtListId.Text = ListId;
        txtItemTitle.Text = list.Title;
        txtItemId.Text = ItemId;
        txtItemTitle.Text = item.Title;
      

Ce code démontre également qu'avec un petit peu de code supplémentaire impliquant le modèle d'objet Windows SharePoint Services, vous pouvez créer un objet SPList et un objet SPListItem pour programmer pour la bibliothèque de documents et le document cible.

Itemaudit.aspx comporte du code qui interroge le journal d'audit. Ce dernier est différent du code indiqué plus haut dans Auditlogviewer.aspx, parce qu'il recherche uniquement les événements d'audit qui sont spécifiques à un seul document. Pour ce faire, il faut appeler la méthode RestrictToList) sur l'objet SPAuditQuery avant d'appeler GetEntries et de transmettre l'objet SPListItem associé au document cible.

        C#

        SPAuditQuery wssQuery = new SPAuditQuery(siteCollection);
        wssQuery.RestrictToListItem(item);
        SPAuditEntryCollection auditCol = site.Audit.GetEntries(wssQuery);

        foreach (SPAuditEntry entry in auditCol) {
        // get info from audit log
        }
      

Maintenant que nous avons vu comment interroger l'enregistrement d'audit pour les événements spécifiques à un seul document, nous pouvons examiner l'un des aspects plus complexes de la fonctionnalité Item Auditing. La page ItemAudit.aspx a été explicitement conçue et implémentée pour afficher des informations d'audit à tous les utilisateurs, y compris ceux qui ne sont pas administrateurs de site. Cependant, cette situation pourrait être problématique, car le modèle d'objet de Windows SharePoint Services nécessite des privilèges d'administrateur pour tous les codes qui appellent la méthode GetEntries pour interroger le journal d'audit. Tous les codes s'exécutant sous l'identité d'un utilisateur ne disposant pas de privilèges d'administrateur du site échouent et présentent une erreur d'accès refusé.

Dans la plupart des cas, il est préférable d'empêcher les utilisateurs qui ne sont pas des administrateurs du site de pouvoir consulter les informations contenues dans un journal d'audit des collections de sites. C'est pour cette raison que le modèle d'objet Windows SharePoint Services impose cette restriction. Cependant, la fonctionnalité Item Auditing vous permet de créer des exceptions. Dans le scénario présent, nous souhaitons que tous les utilisateurs du site puissent consulter les informations d'audit. Par conséquent, le code d'Itemaudit.aspx doit utiliser une technique de programmation spéciale pour élever ses privilèges avant de pouvoir lire le journal d'audit Windows SharePoint Services.

Le code d'ItemAudit.aspx a été écrit pour interagir avec la classe SPSecurity afin d'appeler une méthode statique appelée RunWithElevatedPrivileges. Cette méthode accepte un seul paramètre, qui est un délégué. Si vous souhaitez écrire ce code de façon concise, vous pouvez utiliser des méthodes anonymes comme illustré dans l'exemple de code suivant.

        C#

        SPSecurity.RunWithElevatedPrivileges( delegate()  {
        // Code to run with elevated privileges goes here.
        // This code runs as SHAREPOINT/SYSTEM account.
        });
      

Une fois que vous avez élevé les privilèges du code à l'aide de cette technique, vous devez créer une nouvelle instance de la classe SPSite et de la classe SPWeb. Vous ne pouvez pas utiliser les objets disponibles via la propriété Current car ils ont été déjà créés dans le contexte de sécurité de l'utilisateur actuel. Le code suivant indique la marche à suivre pour créer un nouvel objet SPSite et un nouvel objet SPWeb en utilisant le contexte de sécurité élevé.

        C#

        SPSite siteColl = SPContext.Current.Site;
        SPWeb site = SPContext.Current.Web;

        SPSecurity.RunWithElevatedPrivileges(delegate()  {
        using (SPSite ElevatedSiteCollection = new SPSite(siteColl.ID)) {
        using (SPWeb ElevatedSite = ElevatedSiteCollection.OpenWeb(site.ID)) {
        // Now program against elevated SPSite object and SPWeb object.
        }
        }
        });
      

Le code précédent englobe également la création du nouvel objet SPSite et du nouvel objet SPWeb dans Microsoft Visual C# en utilisant la construction de sorte que les objets soient éliminés correctement. À présent, examinons un code plus long indiquant la marche à suivre pour interroger le journal d'audit pour le document cible en utilisant des privilèges élevés.

        C#

        SPSite siteColl = SPContext.Current.Site;
        SPWeb site = SPContext.Current.Web;

        SPSecurity.RunWithElevatedPrivileges(delegate()  {
        using (SPSite ElevatedSiteCollection = new SPSite(siteColl.ID)) {
        using (SPWeb ElevatedSite = ElevatedSiteCollection.OpenWeb(site.ID)) {

        SPList list = ElevatedSite.Lists[new Guid(ListId)];
        SPListItem item = list.Items.GetItemById(Convert.ToInt32(ItemId));

        SPAuditQuery wssQuery;
        SPAuditEntryCollection auditCol;

        wssQuery = new SPAuditQuery(ElevatedSiteCollection);
        wssQuery.RestrictToListItem(item);
        auditCol = ElevatedSite.Audit.GetEntries(wssQuery);

        foreach (SPAuditEntry entry in auditCol)  {
        // Query audit log with elevated privileges.
        }
        }
        }
        });
      

Écriture d'entrées d'audit personnalisées

Nous avons déjà vu que la page ItemAuditing.aspx peut afficher des entrées d'audit qui sont écrites automatiquement dans le journal d'audit par Windows SharePoint Services. Cependant, il peut arriver que vous vouliez résoudre un problème particulier en écrivant des entrées personnalisées dans le journal d'audit. Par exemple, vous pourriez ajouter un code à l'événement OnLoad pour une page d'application, qui examine l'adresse IP de l'utilisateur, puis écrit une entrée de journal d'audit personnalisée si l'adresse IP n'est pas reconnue dans le réseau local (LAN) de l'entreprise. Autre exemple : vous pourriez fournir un code permettant d'écrire une entrée de journal d'audit personnalisée enregistrant les événements d'une séquence de travail personnalisée.

Lorsque vous utilisez la solution Item-Level Auditing, vous devez écrire des entrées d'audit personnalisées pour enregistrer les moments où un utilisateur examine le journal d'audit d'un document particulier. Par exemple, si un utilisateur clique sur l'élément de menu View Audit History et est redirigé vers ItemAudit.aspx, l'audit Windows SharePoint Services ne consigne pas cet événement. Vous devez donc utiliser le code suivant pour écrire une entrée d'audit personnalisée.

        C#

        SPList list = site.Lists[new Guid(ListId)];
        SPListItem item = list.Items.GetItemById(Convert.ToInt32(ItemId));
        item.Audit.WriteAuditEvent(SPAuditEventType.Custom, "CustomViewAuditEvent",  
        // SoureName
        "<myXml>MyData</myXml>"  // Any arbitrary XML
        data
        );
      

Nous avons appris précédemment que le code devait s'exécuter avec des privilèges élevés pour pouvoir lire le journal d'audit. Cependant, il n'en est pas de même pour le code qui écrit dans le journal d'audit ; celui-ci ne nécessite pas d'autorisations élevées. De plus, si vous élevez les autorisations avant d'écrire dans le journal d'audit, celui-ci affiche les utilisateurs en tant que SHAREPOINT\SYSTEM au lieu de l'utilisateur actuel.

Une fois que vous avez écrit une entrée d'audit personnalisée, vous pouvez la lire ultérieurement dans le journal des événements comme vous liriez n'importe quel autre événement d'audit standard écrit via la fonctionnalité de journalisation d'audit Windows SharePoint Services. Cependant, vous pouvez paramétrer les événements personnalisés de façon à enregistrer les informations pertinentes dans le journal d'audit. L'exemple précédent montrait la procédure à suivre pour attribuer un Nom de source et transmettre des données XML personnalisées lors de l'écriture d'un événement personnalisé. Vous avez ensuite accès à ces informations lorsque vous lisez des événements d'audit en utilisant la propriété SourceName et la propriété EventData de la classe SPAuditEntry.

        C#

        foreach (SPAuditEntry entry in auditCol)  {
        if (entry.SourceName == "CustomViewAuditEvent") {
        string myXml = entry.EventData;
        // process custom event
        }
        }
      

Prise en charge à valeur ajoutée des audits dans Office SharePoint Server 2007

Office SharePoint Server 2007 offre deux dimensions intéressantes pour aider les entreprises qui ont besoin de contrôler l'accès des utilisateurs au contenu des sites Windows SharePoint Services et Office SharePoint Server 2007. Tout d'abord, Office SharePoint Server 2007 offre une interface d'utilisateur d'administration qui vous permet d'activer et de configurer l'audit sans avoir à écrire de code. Ensuite, Office SharePoint Server 2007 propose un aspect de création de rapports. Plus spécifiquement, Office SharePoint Server 2007 vous offre la possibilité de générer des classeurs Excel contenant les informations des événements d'audit du journal d'audit de Windows SharePoint Services. Les sections suivantes de cet article décrivent la façon dont Office SharePoint Server 2007 fournit une prise en charge de l'audit au niveau de des collections de sites et à des niveaux plus granulaires.

Nous allons commencer en examinant la prise en charge intégrée dans Office SharePoint Server 2007 pour la configuration de l'audit au sein d'une collection de sites. Rendez-vous à la page de paramétrage d'un site se trouvant dans une batterie de serveurs sur laquelle Office SharePoint Server 2007 est installé. De nombreux liens y sont ajoutés par des fonctionnalités spécifiques d'Office SharePoint Server 2007. Dans la section Administration de la collection de sites, localisez un lien portant la légende Paramètres d'audit des collections de sites comme illustré à la figure 7.

Figure 7. Administration de la collection de sites

Lorsque vous cliquez sur le lien Paramètres d'audit des collections de sites, une page d'application spécifique à Office SharePoint Server 2007 nommée AuditSettings.aspx s'ouvre. Cette page fournit une interface utilisateur (Figure 8) pour l'activation et la configuration des paramètres d'audit pour la collection de sites en cours. Comme illustré à la figure 8, la page d'application AuditSettings.aspx permet la configuration de l'audit des collections de sites à divers niveaux de granularité.

Figure 8. Page AuditSettings.aspx

Outre la configuration de l'audit au niveau de collections de sites, Office SharePoint Server 2007 vous permet également de configurer l'audit à un niveau beaucoup plus détaillé. Cette prise en charge est rendue possible par les stratégies de gestion des informations incluses dans Office SharePoint Server 2007.

Une stratégie de gestion des informations est un ensemble de règles qu'un administrateur de site peut définir, puis appliquer à un certain type de contenu. Les règles d'une stratégie de gestion des informations sont créées et configurées en termes de fonctionnalités de stratégie. Les fonctionnalités qui sont fournies par défaut avec Office SharePoint Server 2007 incluent la prise en charge de l'audit, de l'expiration, des étiquettes de documents et des codes à barres. Le modèle de programmation pour les fonctionnalités de stratégie est extensible, ce qui permet aux développeurs de créer leurs propres fonctionnalités de stratégie personnalisées. Pour les ressources offertes aux développeurs, consultez l'annexe à la fin de cet article.

Office SharePoint Server 2007 vous permet de créer et de configurer une stratégie de gestion des informations pour une instance spécifique d'une liste ou d'une bibliothèque de documents. Vous pouvez également créer une stratégie de gestion des informations pour un type de contenu, qui s'applique ensuite à des éléments et documents de liste pour toutes les listes ou bibliothèque de documents définies pour ce type de contenu. La possibilité d'appliquer des stratégies de gestion des informations aux types de contenu est très intéressante, car elle offre un contrôle plus granulaire que l'audit au niveau des collections de sites. Elle réduit également le besoin de configuration des paramètres d'audit au niveau des instances de listes ou des instances de bibliothèque de documents.

Office SharePoint Server 2007 vous permet également de définir des stratégies de gestion des informations au niveau des collections de sites. Cette fonctionnalité offre une plus grande facilité de gestion dans la mesure où vous pouvez définir une stratégie de gestion des informations une à l'intérieure d'une collection de sites, puis l'appliquer aux listes, bibliothèques de documents et types de contenu de votre choix au sein de cette collection de sites.

La page Paramètres du site comporte un lien intitulé Stratégies de collections de sites . Si vous cliquez sur ce lien, une page d'application nommée Policylist.aspx s'ouvre. Celle-ci vous permet de configurer une stratégie personnalisée, qui est étendue à la collection de sites en cours. La figure 9 illustre un exemple de stratégie personnalisée créée pour configurer un ensemble standard d'événements d'audit pouvant être appliqués à n'importe quelle liste, n'importe quelle bibliothèque de documents ou n'importe quel type de contenu.

Figure 9. Page de stratégies personnalisées

Après avoir défini une stratégie personnalisée au niveau des collections de sites, vous pouvez ensuite vous rendre à la page Paramètres de la liste pour une liste ou une bibliothèque de documents. Vous y trouverez un lien intitulé Paramètres de la stratégie de gestion des informations , comme illustré à la figure 10. Si vous cliquez sur ce lien, il vous redirige vers une page d'application nommée Policy.aspx, qui vous permet de créer une nouvelle stratégie d'informations. Vous pouvez également appliquer une stratégie déjà définie au niveau des collections de sites. Sur une batterie de serveurs sur lesquels Office SharePoint Server 2007 est installé, la page Windows SharePoint Services qui vous permet de créer et de configurer des types de contenu contient également un lien qui vous mène à Policy.aspx. À cet endroit, vous pouvez également créer ou appliquer des stratégies.

Figure 10. Page Paramètres de la liste

La figure 11 illustre les options disponibles via la page d'application Policy.aspx. Il s'agit là d'une méthode simple pour appliquer une stratégie personnalisée créée au niveau des collections de sites. Vous pouvez également définir et configurer une stratégie unique s'appliquant uniquement à la liste, à la bibliothèque de documents ou au type de contenu en cours. Dans de nombreux cas, cela permet de bénéficier d'une plus grande facilité de gestion. Par exemple, vous pouvez créer toutes vos stratégies au niveau des collection de sites, puis les appliquer aux listes, bibliothèques de documents et types de contenu appropriés.

Figure 11. Application de stratégies personnalisées

Prise en charge de la création de rapports d'audit dans Office SharePoint Server 2007

Nous avons vu comment Office SharePoint Server 2007 et les stratégies de gestion des informations pouvaient vous aider à configurer les paramètres d'audit de Windows SharePoint Services. Considérons maintenant la création de rapports. Office SharePoint Server 2007 vous donne la possibilité de produire plusieurs types de rapports d'audit. Vous pouvez afficher les différents types disponibles en cliquant sur le lien de la page Paramètres du site intitulé Rapports du journal d'audit. Ce lien ouvre une page d'application nommée Reporting.aspx, comme illustré à la figure 12.

Figure 12. Page Reporting.aspx

Lorsque vous cliquez sur l'un des liens de rapports affichés à la figure 12, Office SharePoint Server 2007 génère un fichier XML en réponse, qui est renvoyé à l'utilisateur. Le contenu de ce fichier est basé sur le langage XML connu sous le nom de Excel Markup Language (ExcelML). Lorsqu'Office SharePoint Server 2007 génère un document ExcelML sur le serveur et le renvoie à l'utilisateur, celui-ci a alors la possibilité d'ouvrir le document ExcelML comme un classeur Excel standard.

Créé à l'origine pour Microsoft Office Excel 2000, le langage ExcelML fut amélioré ultérieurement pour Microsoft Office 2003. L'un des facteurs ayant motivé l'équipe Office à créer ExcelML résidait dans la prise en charge de classeurs Excel côté serveur sans que cela nécessite pour le serveur d'exécuter une copie de Microsoft Excel. Par exemple, un composant côté serveur peut utiliser un analyseur XML standard pour produire un document XML dans le formulaire suivant.

        Xml

        <?xml version="1.0"?>
        <?mso-application progid="Excel.Sheet"?
        >
        <Workbook
        >
        <Worksheet
        >
        <Table
        >
        <Row
        >
        <Cell
        >
        <Data Type="String"
        >Mission Critical Data Goes Here</
        style="color: maroon">Data>
        </Cell
        >
        </Row
        >
        </Table
        >
        </Worksheet
        >
        </Workbook
        >
      

Une fois le document ExcelML généré, celui-ci peut être ouvert directement dans Microsoft Office Excel. L'équipe d'Office SharePoint Server 2007 a utilisé cette technique pour ses rapports d'audits. Lorsque vous cliquez sur un lien affiché à la page Reporting.aspx pour générer un rapport d'audit, Office SharePoint Server 2007 renvoie un document ExcelML et la boîte de dialogue illustrée à la figure 13 s'affiche pour l'utilisateur.

Figure 13. Boîte de dialogue Téléchargement de fichier

Si vous choisissez d'ouvrir un rapport directement dans Excel, vous pouvez afficher les informations d'audit comme illustré à la figure 14. À ce stade, vous pouvez également enregistrer le classeur sous n'importe quel format de fichier Excel pris en charge. Cette approche permet d'ouvrir et d'afficher ces rapports d'audit en utilisant Excel 2003 ou Excel 2007.

Figure 14. Informations d'audit dans Excel 2007

Office SharePoint Server 2007 fournit des rapports standard, qui répertorient les utilisateurs qui ont affiché et mis à jour des éléments de liste et des documents, et les utilisateurs qui ont modifié d'autres composants de site tels que des définitions de liste et des paramètres de sécurité. Office SharePoint Server 2007 offre également une flexibilité considérable pour le paramétrage, ce qui vous facilitera la tâche si vous souhaitez exécuter des rapports non officiels. Vous pouvez par exemple exécuter un rapport personnalisé et renseigner les critères comme illustré à la figure 15.

Figure 15. Rapport personnalisé

Création d'un classeur Excel à partir des informations du journal d'audit

Avant la sortie de Microsoft Office System 2007, les produits Microsoft tels que Word, Excel et PowerPoint s'appuyaient sur une structure de fichiers par défaut basée sur le format binaire. Ces formats de fichier étaient très difficiles à lire et à modifier, à moins d'utiliser le modèle d'objet de l'application Office hôte (Word ou Excel). Les entreprises ont donc essayé d'exécuter sur le serveur des applications bureautiques Office, ce qui engendrait des problèmes d'évolutivité et de robustesse.

Office 2000 et Office 2003 ont ajouté quelques fonctionnalités de création de classeurs Excel et de documents Word via XML, comme par exemple la possibilité de créer des classeurs Excel avec ExcelML.

Désormais, avec Microsoft Office System 2007, Microsoft a fait grandement avancer les choses en adoptant des formats XML ouverts Office pour les documents Word, Excel et PowerPoint. Ces formats utilisent une nouvelle norme de fichier pour la création de documents composites contenant plusieurs fichiers XML internes qui séparent le contenu des autres éléments du document tels que les instructions de formatage, les données et le code.

Le fichier de niveau supérieur dans les formats XML ouverts Office est connu sous le nom de package et structuré à l'aide de la technologie de fichier .zip standard. Les fichiers internes contenus dans un package sont appelés parties. De nombreuses parties de fichiers Word, Excel et PowerPoint contiennent des structures XML conformes aux schémas XML publiés. D'autres parties d'un package peuvent comprendre des fichiers binaires pour des éléments tels que des images, des clips audio et des vidéos.

L'un des principaux objectifs des formats XML ouverts Office est de proposer une approche standard pour la lecture, la modification et la création de documents dans des scénarios côté serveur où l'utilisation du modèle d'objet d'une application de bureau telle que Word ou Excel n'est pas une option valable.

Envisagez un scénario de site Windows SharePoint Services dans lequel vous avez créé et configuré un gestionnaire d'événements de sorte qu'il se déclenche chaque fois qu'un utilisateur charge un nouveau document Word. Les nouveaux formats XLM ouverts Office simplifient grandement l'extraction de données ou le nettoyage rapide du document, par exemple la suppression de commentaires et d'informations personnelles. Vous pouvez également exploiter les formats XLM ouverts Office pour développer des composants côté serveur qui génèrent des documents Word et classeurs Excel à l'aide de données extraites de sources de contenu telles qu'une liste Sharepoint ou, dans le cas de notre solution personnalisée, le journal d'audit Windows SharePoint Services.

Pour commencer à utiliser les formats XLM ouverts Office, vous devez apprendre à programmer avec la nouvelle API .NET Framework 3.0. C'est l'API qu'il est recommandé d'utiliser pour ouvrir et créer des packages. Vous devez également vous familiariser avec la structure de package et les schémas XML spécifiques à votre type de document Office particulier. Ces détails changent lorsque vous passez de documents Microsoft Office Word 2007 à Office Excel 2007 et Microsoft Office PowerPoint 2007. Microsoft a créé une communauté pour les développeurs consacrée aux formats XLM ouverts Office à l'adresse openxmldeveloper.org.

La solution Item-Level Auditing fournit un code qui génère des classeurs Excel à l'aide des formats XLM ouverts Office. Vous pouvez inspecter ce code dans le fichier source nommé Workbookfactory.cs. Dans ce fichier source, vous trouverez une classe nommée AuditLogWorkbook, qui programme par rapport à l'API d'empaquetage de .NET Framework 3.0 et exécute toutes les tâches nécessaires pour ajouter des informations provenant du journal d'audit Windows SharePoint Services dans un nouveau classeur Excel.

Le code source du fichier Workbookfactory.cs est compilé dans l'assembly nommé ItemAuditing.dll. Pour accéder à la classe AuditLogWorkbook, la définition de page nécessite une directive d'assembly.

        <%@ Assembly Name="ItemAuditing, Version=1.0.0.0, Culture=neutral,
          PublicKeyToken=7fd3ed697555604d" %>
        <%@ Page Language="C" MasterPageFile="~/_layouts/application.master"
        Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase"  %>

        <%@ Import Namespace="ItemAuditing" %>
      

La page d'application personnalisée ItemAudit.aspx comprend un bouton de commande portant le titre Generate Excel Workbook, qui permet à un utilisateur de générer un classeur Excel à la demande en utilisant les informations d'événement d'audit concernant un document spécifique. Ce bouton de commande redirige l'utilisateur vers un descripteur personnalisé dans le répertoire _layouts nommé AuditLogWorkbook.ashx et transmet la même chaîne de requête avec ListId et ItemId. Le descripteur personnalisé AuditLogWorkbook.ashx a la même directive d'assembly que celle indiquée plus tôt ; son code peut donc être lui aussi programmé par rapport à l'assembly ItemAuditing. Le code se trouvant dans AuditLogWorkbook.ashx utilise la classe AuditLogWork pour exécuter cette tâche.

        C#

        AuditLogWorkbook log = new AuditLogWorkbook();
        log.WriteHeaderInfo(list.Title, item.Name, DateTime.Now);
        SPAuditQuery wssQuery;
        SPAuditEntryCollection auditCol;

        wssQuery = new SPAuditQuery(ElevatedSiteCollection);
        wssQuery.RestrictToListItem(item);
        auditCol = ElevatedSite.Audit.GetEntries(wssQuery);

        string eventType;
        foreach (SPAuditEntry entry in auditCol) {
        if (entry.SourceName == "CustomViewAuditEvent") {
        eventType = "View Audit Log";
        }
        else {
        eventType = entry.Event.ToString();
        }
        log.WriteEntry(GetUserNameById(entry.UserId, site),
        entry.Occurred.ToLocalTime().ToString(),
        eventType,
        ParseVersionNumber(entry.EventData));
        }
      

Une fois que le code d'AuditLogWorkbook.ashx a généré le classeur en utilisant la classe AuditLogWorkbook, il doit renvoyer le classeur à l'utilisateur via le flux de réponse ASP.NET. La classe AuditLogWorkbook fournit une méthode GetDocument, qui renvoie un objet MemoryStream contenant le package avec le classeur Excel. Le code d'ItemAudit.aspx acquiert une référence à l'objet MemoryStream et l'utilise pour retransférer le contenu à l'utilisateur sous un format reconnu comme un classeur Excel 2007.

        C#

        Stream strDocument = log.GetDocument();

        Response.ClearContent();
        Response.ClearHeaders();
        Response.AddHeader("content-disposition", "attachment; filename=AudutLog.xlsx");
        Response.ContentType = @"application/vnd.-excel.document.12";
        Response.ContentEncoding = System.Text.Encoding.UTF8;

        strDocument.Position = 0;
        BinaryWriter writer = new BinaryWriter(Response.OutputStream);
        BinaryReader reader = new BinaryReader(strDocument);
        writer.Write(reader.ReadBytes((int)strDocument.Length));
        reader.Close();
        writer.Close();
        strDocument.Close();

        Response.Flush();
        Response.Close();
      

Lorsque l'utilisateur clique sur Generate Excel Workbook, il a la possibilité d'ouvrir le classeur directement dans Microsoft Excel ou de l'enregistrer sous la forme d'un fichier .xslx. Si l'utilisateur choisit d'ouvrir le fichier, les informations d'événement d'audit sont affichées au format illustré à la figure 16.

Figure 16. informations d'événement d'audit dans Excel 2007

Rendu d'un classeur côté serveur à l'aide d'Excel Services

Office SharePoint Server 2007 propose de nombreuses nouvelles fonctionnalités côté serveur pour l'utilisation de classeurs Office Excel avec Excel Services. Excel Services constitue une version côté serveur du moteur de calcul Excel traditionnel. Ce nouveau moteur est écrit par-dessus Windows SharePoint Services 3.0 de façon à pouvoir évoluer pour répondre aux besoins d'un large public.

Excel Services propose également un moteur de rendu puissant pouvant convertir un classeur Excel en HTML de sorte qu'il puisse être affiché dans le navigateur. Ceci permet à une entreprise de maintenir une série de classeurs dans une bibliothèque de documents Windows SharePoint Services centralisée, et rend le contenu accessible à tous les utilisateurs, y compris ceux dont l'ordinateur n'est pas équipé d'Excel.

Lorsque vous commencerez à utiliser Excel Services, vous vous rendrez compte que vous ne pouvez pas charger des classeurs et les afficher en HTML s'ils n'ont pas au préalable été ajoutés à une bibliothèque de documents configurée avec un emplacement de fichier approuvé. Le but d'un emplacement de fichier approuvé est de permettre à l'administrateur central d'une batterie de serveurs Office SharePoint Server 2007 de contrôler les classeurs pouvant être chargés dans Excel Services et les types de connexions de données autorisés.

Il existe un deuxième bouton de commande dans ItemAudit.aspx qui porte la légende View Workbook with Excel Services. Le gestionnaire d'événements pour ce bouton produit également un classeur Excel utilisant les formats XLM ouverts Office. À la différence du premier bouton de commande, le gestionnaire d'événements du deuxième bouton est conçu de façon à enregistrer le classeur Excel résultant dans la bibliothèque de documents nommée Journaux d'audit. L'utilisateur est ensuite redirigé afin de consulter ce classeur à l'aide d'Excel Services. Si vous avez convenablement configuré un emplacement de fichier approuvé, vous devriez pouvoir cliquer sur le bouton et obtenir un rendu HTML du classeur comme illustré dans l'exemple de la figure 17.

Figure 17. Rendu HTML du classeur

Attention, si vous exécutez l'application échantillon Item-Level Auditing sur un ordinateur équipé de Windows SharePoint Services mais pas d'Office SharePoint Server 2007, le bouton de commande intitulé View Workbook with Excel Services ne fonctionne pas convenablement, car il redirige l'utilisateur vers une application qui n'existe pas tant qu'Office SharePoint Server 2007 n'est pas installé.

Empaquetage de la solution Item-Level Auditing en vue de son déploiement

Précédemment, nous avons abordé toutes les fonctionnalités intrégrées à la solution Item-Level Auditing. Nous allons à présent pouvoir examiner comment empaqueter cette solution en vue d'un déploiement. Dans ce scénario, les fichiers devant être déployés sur le serveur Web frontal incluent un assembly, deux pages d'application personnalisées et les fichiers qui forment la fonctionnalité Item Auditing.

Windows SharePoint Services 3.0 introduit un mécanisme de déploiement connu sous le nom de packages de solution. Un package de solution est un fichier .cab disposant d'une extension .wsp et contenant tous les fichiers qui doivent être déployés sur le serveur Web frontal, ainsi que d'autres instructions XML. Chaque package de solution doit contenir un fichier d'en-tête nommé manifest.xml qui définit un élément Solution. Voici un fichier manifest.xml qui a été créé pour la solution Item Auditing.

        Xml

        <Solution SolutionId="44BE5F4A-D561-4981-A318-95ABC706364A"
        xmlns="https://schemas.microsoft.com/sharepoint/">

        <FeatureManifests
        >
        <FeatureManifest Location="ItemAuditing\feature.xml"
        />
        </FeatureManifests
        >

        <TemplateFiles>
        <TemplateFile Location="LAYOUTS\AuditLogViewer.aspx"
        />
        <TemplateFile Location="LAYOUTS\ItemAudit.aspx"
        />
        <TemplateFile Location="LAYOUTS\AuditLogWorkbook.ashx"
        />
        </TemplateFiles>

        <Assemblies
        >
        <Assembly DeploymentTarget="GlobalAssemblyCache" Location="ItemAuditing.dll"
        />
        </Assemblies
        >

        </Solution
        >
      

Le fichier manifest.xml définit les fichiers faisant partie de la solution qui doivent être déployés sur le serveur Web frontal. Une fois que vous avez défini le fichier manifest.xml, l'étape suivante consiste à le compiler avec tous les autres fichiers requis dans un fichier .cab. Ceci peut être accompli grâce à l'outil MAKECAB.EXE. Lorsque vous utilisez cet outil, vous devez définir un fichier .did indiquant à MAKECAB.EXE les fichiers à inclure dans le fichier output.cab. Voici un exemple de fichier nommé cab.ddf utilisé pour l'élaboration du fichier de package ItemAuditing.wsp pour la solution Item-Level Auditing.

        .OPTION EXPLICIT ;Generate errors
        .Set CabinetNameTemplate=ItemAuditing.wsp
        .set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
        .Set CompressionType=MSZIP;** All files are compressed in cabinet files
        .Set UniqueFiles="ON"
        .Set Cabinet=on
        .Set DiskDirectory1=Package

        Solution\manifest.xml manifest.xml
        TEMPLATE\FEATURES\ItemAuditing\feature.xml ItemAuditing\feature.xml
        TEMPLATE\FEATURES\ItemAuditing\elements.xml ItemAuditing\elements.xml
        TEMPLATE\LAYOUTS\AuditLogViewer.aspx LAYOUTS\AuditLogViewer.aspx
        TEMPLATE\LAYOUTS\ItemAudit.aspx LAYOUTS\ItemAudit.aspx
        TEMPLATE\LAYOUTS\AuditLogWorkbook.ashx LAYOUTS\AuditLogWorkbook.ashx
        bin\Debug\ItemAuditing.dll ItemAuditing.dll
      

Après avoir défini le fichier .ddf, vous pouvez exécuter l'instruction de ligne de commande suivante pour élaborer le fichier de solution de package .wsp.

makecab /f Solution\cab.ddf

Une fois que vous avez généré un fichier de package de solution tel qu'ItemAuditing.wsp, vous disposez des composants nécessaires pour déployer votre solution dans une batterie de serveurs Windows SharePoint Services ou Office SharePoint Server 2007. Le déploiement d'un package de solution est accompli via un processus en deux étapes. Tout d'abord, vous devez ajouter le package de solution, qui copie le fichier .wsp dans la base de données de configuration. Ceci peut être réalisé grâce à l'outil STSADM.EXE.

        @SET SPDIR="c:\program files\common files\microsoft shared\web server extensions\12"
        %SPDIR%\bin\stsadm -o addsolution -filename package\ItemAuditing.wsp
      

Une fois la solution installée, il faut encore la déployer. Pour la deuxième étape, vous devez dire à Windows SharePoint Services de la déployer sur tous les serveurs Web frontaux de la batterie de serveurs. Cette étape peut être accomplie via l'interface utilisateur fournie par l'application Windows SharePoint Services, comme indiqué dans SetupDocument.docx. Cette étape peut également être réalisée en utilisant l'outil STSADM.EXE.

        @SET SPDIR="c:\program files\common files\microsoft shared\web server extensions\12"
        %SPDIR%\bin\stsadm -o deploysolution -name ItemAuditing.wsp -immediate –allowGacDeployment
      

Vous pouvez indiquer à Windows SharePoint Services de déployer une solution immédiatement ou plus tard. Dans un environnement de production, il est généralement intéressant de planifier les déploiements de packages de solution pendant les heures d'utilisation réduite pour minimiser l'impact sur les utilisateurs. L'exemple précédant montre que l'attribut immediate est utilisé pour demander à Windows SharePoint Services d'installer le package de solution immédiatement.

Notez également que la notification de ligne de commande visant à exécuter l'opération de solution de déploiement à partir de l'outil STSADM.EXE inclut le paramètre class="parameter">-allowGacDeployment. Ce paramètre est requis quand le package de solution ajoute un assembly au cache d'assembly global.

Conclusion

Cet article explore la prise en charge d'audit intégrée à Microsoft Windows SharePoint Services 3.0 et Office SharePoint Server 2007. Il traite également du développement de cette prise en charge grâce à la solution Item-Level Auditing personnalisée. Nous avons appris que Windows SharePoint Services offrait les bases nécessaires à l'audit, et ce via un journal d'audit étendu au niveau des collections de sites et une fonctionnalité d'écriture d'entrées d'audit dans ce journal chaque fois que les utilisateurs affichent et mettent à jour le contenu. Nous avons également découvert que ces bases sont faciles à développer à l'aide d'un code personnalisé qui lit et écrit à partir du journal d'audit.

Office SharePoint Server 2007 étend la prise en charge d'audit de Windows SharePoint Services en ajoutant une couche complète, qui permet l'activation et la configuration de l'audit sans avoir à écrire de code personnalisé. L'inclusion de stratégies de gestion des informations permet la création de stratégies d'audit au niveau des collections de sites, puis l'application de ces stratégies à des listes, bibliothèques de documents et divers types de contenu.

Office SharePoint Server 2007 fournit également une couche de création de rapports, qui permet de générer des classeurs Excel contenant les informations des événements d'audit. Ces classeurs Excel sont basés sur ExcelML, et vous pouvez les ouvrir en utilisant Microsoft Office Excel 2003 ou Microsoft Office Excel 2007. Vous avez également pu voir que vous pouviez créer une solution personnalisée telle que la solution Item-Level Auditing en utilisant les formats XLM ouverts Office pour produire des classeurs Excel contenant les informations d'événement d'audit. Une telle solution permet également d'utiliser Excel Services de façon à pouvoir afficher les information d'événement d'audit dans les classeurs obtenus en utilisant le navigateur. De cette façon, vous atteignez même les utilisateurs sur l'ordinateur desquels Excel n'est pas installé.

Pour en savoir plus, visitez le site Produits et technologies Microsoft Sharepoint.

Ressources supplémentaires

Pour plus d'informations, consultez les ressources suivantes :

Pour la conformité

• Guide de planification de la conformité aux réglementations

• Démystification de la conformité aux réglementations : une introduction à la conformité à l'usage des développeurs

• Association for Information and Image Management (AIIM)

• Association of Records Managers and Administrators (ARMA)

• Sarbanes-Oxley Financial and Accounting Disclosure Information

• COSO Internal Control Evaluation Framework

• The COBIT Appliance Framework

• Gestion de la conformité aux réglementations avec Microsoft Technology

• Blog de l'équipe Microsoft Records Management

• Live Communications Server 2005

Pour les développeurs

• Kit de développement logiciel Microsoft Office SharePoint Server 2007

• Recommandations de sécurité la sécurité : .NET Framework2.0

• Recommandations de sécurité : ASP.NET 2.0

• Directives sur le codage sécurisé

• Nouveautés pour les développeurs dans Microsoft Office System 2007

• Office System for Architects

• Articles Forrester : Developers Get Ready: 2007 Microsoft Office Is A Serious Application Platform

Ressources Comment...

• Émissions Web destinées aux développeurs Office

• Comment... Screencasts

• Nouveautés XML pour les développeurs Microsoft Office System 2007

• Kit de développement logiciel de Microsoft Office System 2007

• Starter kit Office System 2007 : starter kit de gestion du contenu d'entreprise

• Microsoft Office System 2007 - Portail d'apprentissage

Ressources pour les produits Microsoft

• Portail destiné aux développeurs SharePoint Server 2007

• Centre d'informations Excel 2007

• Portail Visual Studio Tools destiné aux développeurs Office

• Centre de développement MSDN Office

• Centre de développement MSDN ASP.NET

• Nouveautés pour les développeurs dans Microsoft Office System 2007

• Microsoft Office System 2007