Audit
Audit
20.1 Présentation
L'audit vous permet de conserver un enregistrement des événements significatifs sur les serveurs et applications, ce qui vous donne une idée des informations consultées, du type d'accès, des modifications et de la personne qui exécute ces opérations. Ces informations sont enregistrées dans une base de données appelée le Magasin de données d'audit. Une fois les données enregistrées dans le magasin de données d'audit, vous pouvez concevoir des rapports personnalisés selon vos besoins. Vous pouvez rechercher des exemples d'univers et de rapports dans SAP Developer Network
Dans ce chapitre, un auditeur est un système responsable de l'enregistrement ou du stockage des informations sur un événement et un candidat à l'audit est un système quelconque responsable de l'exécution d'un événement auditable. Dans certains cas, un seul et même système peut exécuter les deux fonctions.
Fonctionnement de l'audit
Le CMS (Central Management Server) joue le rôle d'auditeur système, tandis que chaque serveur ou application qui déclenche un événement pouvant être audité joue le rôle de candidat à l'audit. Lorsqu'un
événement audité est déclenché, le candidat à l'audit génère un enregistrement et le stocke dans un fichier temporaire local. A intervalles réguliers, le CMS communique avec le candidat à l'audit pour demander ces enregistrements et écrit les données dans le magasin de données d'audit.
Le CMS contrôle également la synchronisation des événements d'audit se produisant sur différents ordinateurs. Chaque candidat à l'audit fournit un horodatage pour les événements d'audit qu'il consigne.
Pour garantir la cohérence des horodatages des événements sur différents serveurs, le CMS diffuse périodiquement son heure système aux candidats à l'audit. Les candidats à l'audit comparent ensuite cette heure avec celle de leurs horloges internes. En cas d'écart, ils corrigent l'heure enregistrée pour les événements d'audit suivants.
En fonction du type de candidat à l'audit, le système utilise l'un des workflows suivants pour enregistrer les événements.
Audit de serveur
Dans le cas d'événements générés par un serveur, le CMS peut agir à la fois comme candidat à l'audit et auditeur.
675 2012-05-10
Audit
1.
Un événement auditable est exécuté par le serveur.
2.
Le serveur candidat à l'audit écrit les événements dans un fichier temporaire.
3.
L'auditeur interroge le candidat à l'audit et lui demande un lot d'événements d'audit.
4.
Le serveur candidat à l'audit extrait les événements des fichiers temporaires.
5.
Le serveur candidat à l'audit transmet les événements à l'auditeur.
6.
L'auditeur écrit les événements dans le magasin de données d'audit et indique au serveur candidat
à l'audit de supprimer les événements des fichiers temporaires.
Audit de connexion client pour les clients connectés via CORBA
Cela inclut des applications telles que SAP BusinessObjects Web Intelligence.
676
1.
Le client se connecte au CMS, qui joue le rôle de candidat à l'audit. Le client fournit son adresse IP et le nom de l'ordinateur afin que le candidat à l'audit les vérifie.
Remarque :
Un port doit être ouvert dans le pare-feu entre le CMS et le client. Le chapitre Sécurité du Guide d'administration de la plateforme SAP BusinessObjects Business Intelligence contient des informations supplémentaires sur les pare-feu.
2.
Le candidat à l'audit écrit les événements dans un fichier temporaire.
3.
L'auditeur interroge le candidat à l'audit et lui demande un lot d'événements d'audit.
4.
Le candidat à l'audit extrait les événements des fichiers temporaires.
5.
Le candidat à l'audit transmet les événements à l'auditeur.
2012-05-10
Audit
6.
L'auditeur écrit les événements dans le magasin de données d'audit et indique au candidat à l'audit de supprimer les événements des fichiers temporaires.
Audit de connexion client pour les clients connectés via HTTP
Cela inclut des applications en ligne telles que la zone de lancement BI, la CMC, SAP BusinessObjects
Web Intelligence, etc.
677
1.
Le navigateur se connecte au serveur d'applications Web et les données de connexion sont envoyées
à ce serveur.
2.
Le SDK de la plateforme de BI soumet la requête de connexion au candidat à l'audit (CMS), accompagnée de l'adresse IP et du nom de l'ordinateur sur lequel le navigateur est installé.
3.
Le candidat à l'audit écrit les événements dans un fichier temporaire.
4.
L'auditeur interroge le candidat à l'audit et lui demande un lot d'événements d'audit.
5.
Le candidat à l'audit extrait les événements des fichiers temporaires.
6.
Le candidat à l'audit envoie les événements à l'auditeur.
7.
L'auditeur écrit les événements dans le magasin de données d'audit et indique au candidat à l'audit de supprimer les événements des fichiers temporaires.
Audit d'absence de connexion pour les clients connectés via CORBA
Ce workflow s'applique à l'audit d'événements SAP BusinessObjects Web Intelligence en cas de connexion via CORBA.
2012-05-10
Audit
678
1.
L'utilisateur réalise une opération pouvant faire l'objet d'un audit.
2.
Le client contacte le CMS pour vérifier si l'opération est configurée pour être auditée.
3.
Si l'action est configurée pour être auditée, le CMS communique cette information au client.
4.
Le client envoie les informations d'audit au service du proxy d'audit du client, lequel est hébergé sur un serveur de traitement adaptatif.
Remarque :
Un port du pare-feu doit être ouvert entre chaque client et chaque serveur de traitement adaptatif hébergeant un service du proxy d'audit du client, ainsi qu'entre chaque client et le CMS. Le chapitre
Sécurité du Guide d'administration de la plateforme SAP BusinessObjects Business Intelligence contient des informations supplémentaires sur les pare-feu.
5.
Le service du proxy d'audit du client écrit les événements dans un fichier temporaire.
6.
L'auditeur interroge le service du proxy d'audit du client et lui demande un lot d'événements d'audit.
7.
Le service du proxy d'audit du client extrait les événements des fichiers temporaires.
8.
Le service du proxy d'audit du client envoie les informations sur les événements à l'auditeur.
9.
L'auditeur écrit les événements dans le magasin de données d'audit et indique au service du proxy d'audit du client de supprimer les événements des fichiers temporaires.
Audit d'absence de connexion pour les clients connectés via HTTP
Ce workflow s'applique à l'audit d'événements SAP BusinessObjects Web Intelligence (à l'exception des événements de connexion) en cas de connexion via HTTP.
2012-05-10
Audit
679
1.
L'utilisateur lance un événement susceptible d'être audité. L'application cliente contacte le serveur d'applications Web.
2.
Le serveur d'applications Web vérifie si l'événement est configuré pour être audité.
Remarque :
Le schéma montre le CMS auditeur contacté, mais tout CMS du cluster peut être contacté pour ces informations.
3.
Le CMS renvoie les informations de configuration d'audit au serveur d'applications Web, qui les retransmet à l'application cliente.
4.
Si l'événement est configuré pour être audité, le client envoie les informations sur l'événement au serveur d'applications Web, qui les transmet au service du proxy d'audit du client, lequel est hébergé sur un serveur de traitement adaptatif (APS).
5.
Le service du proxy d'audit du client écrit les événements dans un fichier temporaire.
6.
L'auditeur interroge le service du proxy d'audit du client et lui demande un lot d'événements d'audit.
7.
Le service du proxy d'audit du client extrait les événements des fichiers temporaires.
8.
Le service du proxy d'audit du client envoie les informations sur les événements à l'auditeur.
9.
L'auditeur écrit les événements dans le magasin de données d'audit et indique au service du proxy d'audit du client de supprimer les événements des fichiers temporaires.
Clients prenant en charge l'audit
Les applications client suivantes prennent en charge l'audit :
• Central Management Console (CMC)
• Zone de lancement BI
• Open Document
• Analyse
2012-05-10
Audit
680
• Fournisseur de services Web Live Office
• Web Intelligence Desktop
• Mobile
• Dashboard Design et Presentation Design
• Dashboard Manager
Remarque :
Au moins une instance de service du proxy d'audit du client doit être en cours d'exécution pour recueillir les événements d'audit des clients répertoriés ci-dessus.
Les clients non répertoriés ci-dessus ne génèrent pas directement d'événements, mais certaines actions accomplies par les serveurs découlant d'opérations d'applications client peuvent être auditées.
Cohérence de l'audit
Dans la plupart des cas, lorsque la fonction d'audit est correctement installée, configurée et sécurisée et que les versions appropriées de toutes les applications clientes sont utilisées, l'audit consigne tous les événements système indiqués de manière conforme et cohérente. Toutefois, il est important de garder à l'esprit que certaines conditions affectant le système et l'environnement peuvent avoir une incidence négative sur l'audit.
Il existe toujours un décalage entre l'heure à laquelle un événement se produit et l'heure de son transfert final dans la base de données d'audit. Des conditions telles que l'indisponibilité du CMS ou de la base de données d'audit ou la perte de la connectivité réseau peuvent augmenter ces délais.
En tant qu'administrateur système, vous devez tout faire pour éviter les conditions suivantes, qui risquent de se solder par des enregistrements d'audit incomplets :
• Un lecteur stockant les données d'audit atteint sa capacité maximale. Vérifiez que l'espace disque est suffisant pour votre base de données d'audit et les fichiers temporaires du candidat à l'audit.
• Un serveur candidat à l'audit est supprimé du réseau de manière incorrecte avant d'avoir transmis tous les événements d'audit. Lorsque vous supprimez un serveur du réseau, vous devez veiller à accorder suffisamment de temps pour que les événements d'audit soient enregistrés dans la base de données d'audit.
• La suppression ou la modification des fichiers temporaires du candidat à l'audit.
• Un échec du disque/matériel.
• La destruction physique d'un ordinateur hébergeant l'auditeur ou le candidat à l'audit
Dans certaines conditions, les événements d'audit peuvent être dans l'incapacité d'accéder au CMS auditeur. Citons par exemple :
• Les utilisateurs avec des versions client antérieures.
• Le blocage de la transmission d'informations d'audit par des pare-feu incorrectement configurés.
Remarque :
• Les événements générés par des applications clientes contenant des informations envoyées côté client, soit en dehors de la zone sécurisée du système. Par conséquent, dans certaines conditions, ces informations peuvent ne pas être aussi fiables que les informations enregistrées par les serveurs du système.
• Si vous souhaitez supprimer un serveur de votre déploiement, vous devez d'abord désactiver ce serveur tout en le laissant en cours d'exécution et connecté à votre réseau jusqu'à ce que tous les
événements des fichiers temporaires aient pu être transmis à la base de données d'audit. La métrique
2012-05-10
