Discussion :

[steph4263]

Salut à tous.
Est ce que quelqu'un peut me dire la procédure à suivre pour faire un audit d'une base de données? S'il y a des cours ou éventuellement des livres qui traitent de ce sujet?


[Déplace par Braim, ancien forum était Mode d'emploi & aide aux nouveaux]

[qi130]

la procédure à suivre pour faire un audit d'une base de données

Hé hé.... bah tout dépend de ce que tu veux auditer....
- le fonctionnel
- le technique
- l'arrière boutique (sauvegardes, réorg, le tuning du SGBDR....)
- la sécurité

Ca dépend aussi de tes capacités (compétences) dans les segments évoqués ci-dessus, sachant que certains de ces segments se recoupent parfois.
Ca dépend aussi de qui te mandate pour réaliser cet audit (quel niveau d'information lui rapporter, quel vocabulaire employer)

Bref, l'audit n'est pas aussi simple que la longueur de ce mot le laisserait supposer....
Pour ma part, le 1er commandement de l'audit est "des faits, rien que des faits, toujours des faits"

Pour les formations et autres bouquins/Doc,

[steph4263]

Je suis étudiant, je vais devoir faire un audit pour un projet sur une base de données mais on nous indique pas la manière de procéder c’est pourquoi je suis un peu vague dans mes questions. Pour le moment j'essaye de me documenter car je n’ai pas encore accès à la base de données. Je sais juste que j’aurais les droits d’administration et que je n’aurais pas à m’occuper du matériel sur lequel tourne le SGBDR.

Es ce que tu peux me détailler pour chacun des types d'audits que tu m'as cité les points à regarder (le fonctionnel, le technique, l'arrière boutique, la sécurité). Peut être que ça pourra m'orienter vers un de ces audits.
Merci

[qi130]

... ben pas facile de faire court vu l'étendue demandée....

enfin, essayons !

Avant toute chose, l'auditeur doit être mandaté (terme consacré) par une personne ayant autorité sur le domaine audité.
Pas de mandat -> pas d'audit.

C'est ce mandat qui confère à l'auditeur l'autorité pour mettre son nez partout

fonctionnel :
- demander toute la doc du projet ou de l'appli
- demander les normes et méthodes de conception et de développement (y compris la planification et les abaques utilisés pour les charges)
- demander si un outil a été utilisé pour la modélisation si oui, faire sortir les modèles physique et conceptuel
- vérifier que le MCD est conforme aux Normes de conception
- vérifier que le MCD est conforme au cahier des charges
- vérifier que le MPD issu du passage conception->physique (ou généré par l'outil) est identique au modèle en production ( oui, ça peut exister)

En cas de pb constaté, l'audit doit se borner à mentionner des faits.
- pas de doc applicative -> pas bon ! mais l'audit est terminé, le rapport mentionnera ce pb de procédure et recommandera la mise en place de ce qu'il faut (référentiel documentaire, intranet, etc...)
- pas de normes/méthodes, idem -> mise en place de normes & méthodes
-déphasage des modèles -> mise en place d'une ADD, voire d'un processus de recette

Maintenant, s'il n'y a pas trop d'incohérences, on peut creuser un peu:
- interroger les utilisateurs sur leur implication dans le processus de développement de l'appli : comment ça se passe, sont ils contents, effet "tunnel" conception -> mise en prod, connaissent-ils la méthode en vigueur ? Y sont-ils formés? Est-elle respectée ? si non pourquoi (instances de validation ?)
.... et faire les recommendations qui s'imposent !

Lors de cette phase d'interview, il faut bannir les impressions des personnes interrogées ("il parait que", "on m'a dit que", "je crois que") => toujours les faits

Ce sera tout pour ce soir, mais tu as déjà de quoi faire.

Tu vois qu'un auditeur n'est pas un touche-à-tout, mais qq'un qui dispose de compétences assez pointues dans bon nombre de domaines; et pour celles qui lui manquent (sous-entendu les domaines où il se sent un peu juste), il peut toujours se faire aider par un expert.

Je te propose en parallèle, de cogiter sur les autres points et de me (nous) soumettre le résultat pour correction (histoire de voir si la démarche est correcte et suit la voie tracée ci-dessus), soit sur le forum soit par mp.

[SQLpro]

Un petit point que tu as oublié dans ton panagérique : le calcul de la volumétrie...

A +

[bloginfo]

J'ai écrit un article susceptible de vous intéresser sur le sujet de l'audit de bases de données relationnelles.

Quatre points d'analyse à mon sens :

• l’environnement (mémoire, process concurrents) ;
• la qualité du modèle relationnel (règles de nommage, présence de clés primaires, d'index uniques, de contraintes d'intégrité référentielle, de check constraints notamment) ;
• la performance du moteur ou comment éviter l'épuisement du cache ;
• la politique en matière de sauvegarde des données.

[SQLpro]

Au fait, pour ceux que ça intéresse :
http://www.sqlspot.com/sites/sqlspot...eDonnees-3.pdf

A +

[erpWorld]

Pourrons nous avoir si c'estpossible un exemple rapport d'audit pour s'inspirer ou même la table des matières

[SQLpro]

Pourrons nous avoir si c'estpossible un exemple rapport d'audit pour s'inspirer ou même la table des matières

C'est beaucoup trop confidentiel.....

A +

[Ndombi]

Hé hé.... bah tout dépend de ce que tu veux auditer....
- le fonctionnel
- le technique
- l'arrière boutique (sauvegardes, réorg, le tuning du SGBDR....)
- la sécurité

Ca dépend aussi de tes capacités (compétences) dans les segments évoqués ci-dessus, sachant que certains de ces segments se recoupent parfois.
Ca dépend aussi de qui te mandate pour réaliser cet audit (quel niveau d'information lui rapporter, quel vocabulaire employer)

Bref, l'audit n'est pas aussi simple que la longueur de ce mot le laisserait supposer....
Pour ma part, le 1er commandement de l'audit est "des faits, rien que des faits, toujours des faits"

Pour les formations et autres bouquins/Doc,