Meilleures pratiques de sauvegarde et de récupération de base de données – Bien choisir son serveur d impression

La possibilité de restaurer des bases de données à partir de sauvegardes valides est un élément essentiel pour assurer la continuité des activités. L’intégrité de la sauvegarde et les restaurations constituent un élément important de la Objectifs de contrôle informatique pour Sarbanes-Oxley, 2^{Dakota du Nord} Édition. Dans de nombreux cas, les auditeurs informatiques se contentent de confirmer si les sauvegardes sont effectuées sur disque ou sur bande, sans tenir compte de l'intégrité ou de la viabilité du support de sauvegarde.

Cet article couvre les rubriques liées à la perte de données et aux types de sauvegarde et de récupération de base de données disponibles. Les meilleures pratiques pouvant aider un auditeur à évaluer l'efficacité de la sauvegarde et de la récupération de la base de données sont également fournies. Cet article porte sur les technologies et les fonctionnalités du système de gestion de base de données relationnelle Oracle (RDBMS) et de Microsoft (MS) SQL Server, qui couvrent ensemble environ 40% de toutes les installations de base de données. Figure 1 fournit une courte comparaison entre Oracle et MS SQL Server.

L’une des principales responsabilités de l’administrateur de base de données consiste à se préparer à une éventuelle défaillance des supports, du matériel et des logiciels, ainsi qu’à restaurer les bases de données en cas de sinistre. En cas de défaillance de ce type, l'objectif principal est de s'assurer que la base de données est disponible pour les utilisateurs dans un délai acceptable, tout en évitant toute perte de données. Les administrateurs de bases de données doivent évaluer s'ils sont prêts à réagir efficacement à de telles situations en répondant aux questions suivantes:

• L’administrateur de base de données est-il convaincu que les données sur lesquelles reposent les activités de la société sont sauvegardées avec succès et que les données peuvent être récupérées à partir de ces sauvegardes dans les délais prescrits, conformément à un accord de niveau de service ou à un délai de récupération, comme spécifié dans le plan de reprise après sinistre de l'organisation?
• L'administrateur de base de données a-t-il pris des mesures pour élaborer et tester les procédures permettant de protéger et de récupérer les bases de données après de nombreux types de défaillances?

Voici une liste de contrôle pour les procédures de sauvegarde et de récupération de base de données, expliquée tout au long de cet article:

1. Développer un plan de sauvegarde complet.
2. Effectuer une gestion de sauvegarde efficace.
3. Effectuer des tests périodiques de restauration des bases de données.
4. Faites en sorte que les SLA de sauvegarde et de restauration soient rédigés et communiqués à toutes les parties prenantes
5. Demandez à la partie base de données du plan de reprise après sinistre (DRP) d'être rédigée et documentée.
6. Conservez vos connaissances et votre savoir-faire sur les outils de sauvegarde et de restauration de bases de données et de systèmes d'exploitation à jour.

Plan de sauvegarde complet

Les administrateurs de base de données sont chargés d'élaborer un plan de sauvegarde complet pour les bases de données dont ils sont responsables. Le plan de sauvegarde doit inclure tous les types de SGBDR au sein de l'entreprise et couvrir les domaines suivants:

• Décidez ce qui doit être sauvegardé. Il est impératif que l'administrateur de base de données connaisse les composants de la base de données, du système d'exploitation et des applications associés qui doivent être sauvegardés, que ce soit via une sauvegarde en ligne ou une sauvegarde à froid hors ligne.
  Vous trouverez ci-dessous les détails de ce qui doit être sauvegardé:
  • Logiciel du système d'exploitation: un événement tel qu'une défaillance matérielle nécessitera une restauration complète du système, à commencer par le système d'exploitation. Il est donc nécessaire de sauvegarder le système d'exploitation du serveur de base de données au début et après toutes mises à jour du système ou modifications de configuration.
  • Logiciel SGBDR – Le logiciel SGBDR doit être sauvegardé initialement et après les correctifs / mises à niveau.
  • Logiciel d'application, le cas échéant – Ceci s'applique en particulier à Oracle E-Business Suite, à Oracle Application Server et à Oracle Enterprise Manager (OEM). L’administrateur de base de l’application doit effectuer une sauvegarde complète initiale des applications sur disque à l’aide d’une commande appropriée du système d’exploitation, puis planifier des sauvegardes incrémentielles futures, par exemple, après l’éventuelle correction ou mise à niveau. Ces sauvegardes doivent également être transférées sur bande.
  • Mots de passe: tous les mots de passe de superutilisateur pouvant être requis lors de la récupération doivent être préservés. Il est judicieux de s'assurer que les mots de passe par défaut fournis avec l'installation initiale du SGBDR sont modifiés.
  • Tous les composants des bases de données Oracle:
    • Fichier de paramètres de base de données – Un fichier de paramètres ou un fichier de paramètres de serveur (SPFILE) définit les paramètres d'initialisation persistants d'une base de données, y compris des informations sur les fichiers de contrôle de la base de données.
    • Fichier (s) de contrôle de la base de données: le fichier de contrôle stocke le statut de la structure physique de la base de données. S'il devient indisponible, la base de données ne peut pas fonctionner. Il est impératif que ces fichiers soient sauvegardés lors de la sauvegarde d'autres composants de la base de données. Dans les versions ultérieures d'Oracle (à partir de la version 9i), l'administrateur de base de données peut configurer la sauvegarde automatique du fichier de paramètres ainsi que du fichier de contrôle afin de garantir leur sauvegarde après chaque sauvegarde et après toute modification structurelle de la base de données.
    • Fichiers de données de base de données: ils doivent être sauvegardés pendant la sauvegarde à froid ainsi que pendant la sauvegarde en ligne, à l’aide du logiciel RMAN (Recovery Manager) d’Oracle ou, dans les versions de base de données Oracle dans lesquelles RMAN n’a pas été introduit, en plaçant les espaces de table en mode de sauvegarde. L'administrateur de base de données doit essayer d'exécuter toutes les bases de données de production en mode de journalisation d'archivage afin que la récupération jusqu'au point d'échec soit possible.
    • Refaire les fichiers journaux et les journaux redo archivés: lors de la sauvegarde à froid, l'administrateur de base de données doit sauvegarder les journaux redo. Lorsque la base de données est exécutée en mode de journal d'archivage et en train de faire une sauvegarde en ligne, l'administrateur de base de données doit archiver les journaux redo manuellement ou automatiquement, puis sauvegarder tous les journaux redo.
    • Fichiers réseau Oracle: il est important de sauvegarder tous les fichiers du réseau Oracle initialement et après toute modification.
    • Fichiers de mot de passe – Les fichiers de mot de passe utilisés doivent être sauvegardés initialement et après toute modification.
  • Bases de données MS SQL Server:
    • Sauvegardez les bases de données système et utilisateur.
    • Disposez d’un plan de maintenance distinct pour les bases de données système, c’est-à-dire maître, modèle, msdb. Master ne prend en charge que les sauvegardes complètes. La sauvegarde tempdb n'est pas requise, car elle est reconstruite au démarrage de SQL Server.
    • Sauvegardez toutes les bases de données utilisateur. Configurez toutes les bases de données utilisateur pour un modèle de récupération complète et sauvegardez les journaux de base de données et de transaction.
• Déterminez le type de sauvegarde approprié à utiliser pour vos données.
  • Bases de données Oracle:
    1. Sauvegardes logiques: ce type de sauvegarde est effectué via les utilitaires Oracle «exp.». À partir de la version 10g, Data Pump peut également être utilisé. L'ensemble de la base de données, schémas individuels, tables ou espaces de table peut être sauvegardé. La restauration est effectuée à l'aide de «imp» ou de Data Pump. Avec de telles sauvegardes, la récupération jusqu'au point d'échec n'est pas possible.
    2. Sauvegardes physiques hors ligne ou à froid – La base de données doit être fermée et une copie doit être faite de tous les fichiers de données essentiels et des autres composants de la base de données.
    3. Sauvegardes physiques en ligne ou à chaud: cette méthode permet de sauvegarder la base de données en cours d'exécution. Les points suivants doivent être gardés à l'esprit lors des sauvegardes en ligne:
       • Placez les espaces de table en mode de sauvegarde et sauvegardez les fichiers de données associés à l'aide d'une commande de copie du système d'exploitation ou utilisez RMAN, un outil performant fourni par Oracle pour la sauvegarde et la récupération à partir de la version 8.x. Oracle ajoute de nouvelles fonctionnalités à cet outil avec chaque version. RMAN peut utiliser le fichier de contrôle de base de données pour conserver son catalogue ou l'administrateur de base de données peut configurer le schéma de chaque base de données dans une base de données distincte pour les catalogues RMAN.
       • L'administrateur de base de données doit examiner et garder à l'esprit la matrice de compatibilité RMAN pour la base de données en cours de sauvegarde / restauration, ainsi que l'exécutable RMAN et la base de données / schéma de catalogue RMAN.
       • Les administrateurs de base de données doivent se familiariser avec les sauvegardes complètes, incrémentielles et différentielles et les configurer à l'aide de scripts RMAN. Les administrateurs de base de données doivent examiner leur édition de SGBDR, par exemple, les sauvegardes incrémentielles ne sont pas possibles dans les éditions standard antérieures à Oracle 10g. Pour restaurer / récupérer une base de données au point d’échec ou à un moment antérieur, l’administrateur de base de données doit mettre la base de données en mode journal d’archivage et sauvegarder tous les journaux redo archivés.
       • Il est important de ne pas oublier de sauvegarder le catalogue RMAN à la fin de chaque sauvegarde. Les administrateurs de base de données peuvent effectuer une sauvegarde d'exportation du schéma de catalogue RMAN.
  • Bases de données SQL Server:
    1. Sauvegardes logiques: dans SQL Server, les objets de schéma individuels peuvent être sauvegardés dans des fichiers à plat dans l'un des formats de fichier pris en charge. Les fichiers plats peuvent ensuite être restaurés à l'aide d'outils tels que l'utilitaire bcp, l'Assistant Importation et exportation ou les outils SQL Server Integration Services.
    2. Sauvegardes physiques: il est recommandé de configurer toutes les bases de données utilisateur pour un modèle de récupération complète. Les journaux de base de données et de transaction doivent également être sauvegardés pour restaurer / récupérer la base de données jusqu'au point de défaillance. Les administrateurs de base de données doivent se familiariser avec les modèles de récupération de base de données et les sauvegardes complètes, différentielles et de journal des transactions, et les configurer en conséquence. Une stratégie de sauvegarde de fichier ou de groupe de fichiers peut être utilisée si les bases de données à sauvegarder sont de très grandes bases de données (VLDB) partitionnées entre plusieurs fichiers.
• Établir une stratégie pour gérer les sauvegardes VLDB– Dans Oracle, l'administrateur de base de données peut réduire la fenêtre de sauvegarde pour les VLDB en allouant plusieurs canaux et en optimisant les sauvegardes, en économisant de l'espace disque en utilisant des sauvegardes compressées et en bloquant le suivi avec les techniques de sauvegarde incrémentielle avec les dernières versions. L'administrateur de base de données doit examiner la version et l'édition de la base de données pour confirmer la disponibilité de cette option. Si cela ne suffit pas, le DBA peut envisager de configurer des sauvegardes en miroir fractionné. Pour SQL Server, l'administrateur de base de données peut partitionner la base de données entre plusieurs fichiers et utiliser la stratégie de sauvegarde de fichier ou de groupe de fichiers. De plus, l'utilisation de plusieurs périphériques de sauvegarde dans SQL Server permet d'écrire des sauvegardes sur tous les périphériques en parallèle.
• Établir un calendrier et une fenêtre de sauvegarde appropriés– Il est recommandé de sélectionner une fenêtre de sauvegarde à un moment où la plus faible activité affecte la base de données afin que la sauvegarde ne réduise pas les ressources disponibles du serveur de base de données et ne ralentisse l’activité de l’utilisateur. L'administrateur de base de données peut ajuster la fenêtre de sauvegarde en parallélisant les sauvegardes à l'aide de plusieurs canaux; toutefois, l'administrateur de base de données doit examiner la version et l'édition de la base de données pour confirmer la disponibilité de cette option. Dans la grande majorité des cas, il est préférable de mettre en place un cycle de sauvegarde hebdomadaire commençant par des sauvegardes complètes le vendredi soir ou le samedi matin et par des sauvegardes incrémentielles / différentielles tout au long de la semaine. Les sauvegardes du journal d'archivage / des transactions peuvent être programmées toutes les quelques heures, en fonction de la volatilité de la base de données.
• Décidez où stocker les sauvegardes—Les bases de données Oracle et MS SQL Server peuvent être sauvegardées directement sur bande ou sur disque (localement ou sur le réseau), puis les sauvegardes peuvent être archivées sur bande. Il est recommandé de sauvegarder sur disque, de transférer sur bande et de stocker des bandes hors site pour la récupération après sinistre. Les sauvegardes sur disque sont plus rapides. Les administrateurs de base de données ont plus de contrôle et peuvent mieux surveiller ces derniers et, avec cette méthode, ils stockent deux jeux de sauvegardes: l'un sur disque, l'autre sur bande. Pendant la restauration, si les sauvegardes sont encore sur le disque, la restauration sera plus rapide, ce qui réduit le temps moyen de récupération (MTTR).
• Développer une politique de rétention de sauvegarde—La stratégie de conservation des sauvegardes concerne à la fois le calendrier de rotation des disques et des bandes et doit être définie en fonction du contrat de niveau de service établi avec la communauté des utilisateurs professionnels. Le propriétaire des données doit spécifier la période de conservation des données. La durée de conservation peut varier de quelques mois à plusieurs années, en fonction des lois locales. Par conséquent, l'administrateur de base de données doit supprimer les anciennes sauvegardes pour créer de l'espace pour les sauvegardes actuelles. La stratégie de conservation des données doit être choisie avec soin, en s'assurant qu'elle complète la stratégie de conservation du sous-système de supports de sauvegarde et les exigences de la stratégie de récupération de sauvegarde. Si aucun catalogue n'est utilisé, l'administrateur de base de données doit s'assurer que le paramètre d'instance de conservation de l'enregistrement du fichier de contrôle correspond à la stratégie de rétention.

Gestion de sauvegarde efficace

Après avoir établi un plan de sauvegarde solide et achevé le travail initial, l'administrateur de base de données doit gérer correctement les sauvegardes, en gardant à l'esprit les points suivants:

• Automatisation des sauvegardes—Pour Oracle, définissez les sauvegardes via OEM ou utilisez un outil de planification de système d'exploitation et spoulez la sortie dans un fichier journal qui peut être examiné pour détecter d'éventuelles erreurs. Dans SQL Server, utilisez les plans de maintenance pour planifier les sauvegardes.
• Surveillance des sauvegardes– Configurez la surveillance à l'aide des outils appropriés pour que l'administrateur de base de données reçoive un courrier électronique ou une alerte via un pager ou un téléphone portable en cas d'échec des sauvegardes, qui doivent être réexécutées dès que possible.
• Journaux et catalogues de sauvegarde—Examinez régulièrement les journaux de sauvegarde et les informations du catalogue de sauvegarde pour résoudre tous les problèmes. Utilisez les rapports RMAN pour afficher le statut de la sauvegarde. Pour Oracle, sauvegardez la base de données de catalogue RMAN en exportant périodiquement tous les schémas de catalogue, ainsi qu'en effectuant une sauvegarde d'exportation du schéma de catalogue RMAN à la fin de chaque sauvegarde. Pour SQL Server, sauvegardez les bases de données système, en particulier master et msdb.
• Maintenance du catalogue de base de données—Avec les bases de données Oracle, utilisez “delete obsolete” pour supprimer les sauvegardes en dehors de la stratégie de rétention de l'organisation. Si les sauvegardes obsolètes ne sont pas supprimées, le catalogue continuera de croître et les performances deviendront un problème. Une vérification croisée (sauvegarde croisée) vérifiera que le fichier catalogue / contrôle correspond aux sauvegardes physiques.
• Validation des sauvegardes—Validez et vérifiez les sauvegardes sans effectuer de restaurations réelles.
• Mise en place de dépendances– Lors de la sauvegarde sur disque, archivez ces sauvegardes sur bande dès que la sauvegarde sur disque est terminée.

Configurez un processus pour que les sauvegardes sur disque soient transférées sur bande sans perte de temps.

Test de restauration de sauvegarde

Imaginons le scénario suivant: une inondation a touché la zone dans laquelle se trouve le siège de la société et l’ensemble de l’infrastructure informatique a été endommagé, mais pas détruit. Avant l'événement, les administrateurs de base de données ont effectué des sauvegardes sur le support de sauvegarde, en suivant tous les processus décrits précédemment dans cet article, et les ont stockées hors site. Lors du dernier audit informatique de l’entreprise, l’auditeur a qualifié le processus de sauvegarde de «efficace».

Le support de sauvegarde du stockage hors site est récupéré et chargé. Un message apparaît à l'écran indiquant que les supports de sauvegarde sont «illisibles» en raison de problèmes d'intégrité. Qu'est-ce qui aurait pu arriver?

Beaucoup de choses auraient pu arriver. Cependant, il est clair qu'une étape critique a été ne pas se produire. La restauration à partir du support de sauvegarde n'a jamais été réellement testée. Le contrôle a été marqué comme efficace car un processus de sauvegarde était en place et en cours d'exécution. En outre, aucune erreur n'a été reçue lorsque l'entreprise a été sauvegardée sur le support de sauvegarde.

Les sauvegardes ne sont d'aucune utilité si l'équipe informatique ne peut pas restaurer les données sur le système au moment opportun. Un DBA devrait formuler une stratégie détaillée pour cette tâche:

1. Tests de restauration de bases de données—Il devrait être nécessaire de tester les restaurations de la base de données à partir du disque ainsi que des sauvegardes sur bande.
2. Validation des restaurations si possible– L'administrateur de base de données peut valider et vérifier les sauvegardes sans effectuer de restaurations réelles. La validation des sauvegardes à l'aide de la commande «restore validate database» fera tout sauf la restauration de la base de données. C'est la meilleure méthode pour déterminer si la sauvegarde est bonne et utilisable avant de se trouver dans une situation dans laquelle elle devient critique.
3. Actualisation des bases de données non productives à partir des sauvegardes de production– Il est recommandé de créer périodiquement des bases de données non productives à partir de sauvegardes de production à l'aide des commandes appropriées de l'utilitaire de sauvegarde / restauration en tant que procédure de restauration.
4. Effectuer des tests de restauration annuels / semestriels à partir d'une bande dans le cadre de l'audit– L’administrateur de base de données devra expliquer le processus au moyen d’un récit, conserver les journaux et prendre des captures d’écran pour montrer ce type de test de restauration.
5. Restaurations réelles—Lors des restaurations effectives, le DBA doit sauvegarder la base de données avant de procéder à la restauration. En fonction du type de perte et des sauvegardes disponibles, l'administrateur de base de données doit décider s'il convient d'effectuer une récupération complète (point dans le temps) ou incomplète. Une récupération incomplète peut être basée sur le temps, sur l'annulation ou sur le changement.
6. Stratégie pour récupérer de la corruption de la base de données—Pour les bases de données Oracle, l'administrateur de base de données peut activer la vérification de bloc à l'aide de paramètres appropriés pour détecter la présence de blocs corrompus dans la base de données. Cela a une légère surcharge de performances, mais permettra une détection précoce des blocs corrompus provoqués par des problèmes de disque, de système de stockage ou de système d'entrée / sortie (E / S) sous-jacents. Par défaut, RMAN recherche également les blocs corrompus lors de la sauvegarde. Dans les versions ultérieures d'Oracle, RMAN peut être utilisé pour réparer les blocs corrompus de la base de données.

SLA de sauvegarde et de récupération

L'équipe d'administration de base de données doit rédiger un contrat de niveau de service de sauvegarde et de récupération, décrivant en détail les procédures de sauvegarde, y compris un calendrier de récupération, et le faire approuver par la direction. Le contrat de niveau de service n’aide pas le processus de récupération proprement dit, mais définit les attentes de la communauté des utilisateurs (et de la direction) à l’égard du processus de récupération, ce qui peut donner à l’équipe plus de temps pour mener à bien le processus de restauration.

Plan de reprise après sinistre

L’administrateur de base de données doit veiller à ce que les bases de données constituent un élément clé du PRD global de la société. Toutes les parties prenantes doivent comprendre les éléments du plan de récupération et dans quel ordre l'équipe informatique va restaurer les bases de données. À ce stade, l’entreprise doit apporter sa contribution afin que les applications les plus critiques soient disponibles le plus rapidement possible.

Outils de sauvegarde et de récupération de bases de données et de systèmes d'exploitation

Cela semble évident, mais les administrateurs de base de données jouent le dernier et le plus important rôle dans le processus en ce sens qu'ils doivent maintenir à jour leurs connaissances des outils de sauvegarde et de récupération pour les SGBDR. Au cours de l'événement de restauration, les administrateurs de base de données n'auront pas le temps de découvrir les améliorations apportées aux outils de sauvegarde et de récupération.

Conclusion

La principale responsabilité de l’équipe d’administration de base de données est d’examiner tous les types de SGBDR dans l’entreprise et de développer un plan de sauvegarde complet pour gérer efficacement les sauvegardes en surveillant de manière proactive les sauvegardes, en étant averti des sauvegardes ayant échoué et en les réexécutant de manière transparente et sans perte de temps. Il est recommandé de sauvegarder les données sur un disque physique, puis de les archiver sur bande à des fins de récupération après sinistre.

Une fois l’approche établie, il est impératif de tester périodiquement la restauration des données dans le cadre de la stratégie de sauvegarde et de restauration, et de passer en revue toutes les options avant d’exécuter la restauration / restauration effective. Il est important de confirmer que l'équipe de base de données est au courant des derniers outils de sauvegarde et de restauration et de veiller à ce que l'équipe dispose d'un processus clairement documenté avec des responsabilités claires. Si les administrateurs de base de données conservent les sauvegardes appropriées, les surveillent de manière proactive et peuvent fournir l'assurance de la récupération des données jusqu'au point requis par l'entreprise, ils ont effectué une grande partie du travail pour lequel ils ont été embauchés.

Les auditeurs informatiques peuvent aider les équipes d'administration des données à renforcer leurs contrôles et leurs processus de récupération de données en validant les opérations de l'administrateur de base de données, y compris le test de la récupération des données. Cet effort continu, proactif et coopératif entre l’audit interne et l’équipe DBA peut donner l’assurance à la direction que, en cas de sinistre, les données de l’entreprise peuvent être récupérées.

Ali Navid Akhtar, OCP, a plus de deux décennies d'expérience dans les bases de données. Il travaille en tant qu'administrateur de base de données principal chez Solo Cup Co.

Jeff Buchholtz, a plus de 18 ans de conception, de mise en œuvre et de support de solutions informatiques globales. Il occupe un rôle de direction informatique et est administrateur de base de données Oracle.

Michael Ryan, CIA, CPA, est le directeur de l’audit interne de Solo Cup Co., qui est principalement chargé de l’élaboration et de l’exécution des stratégies de conformité avec la loi américaine Sarbanes-Oxley Act 404.

Kumar Setty, CISA, possède plus de 10 ans d'expérience dans les domaines de l'analyse de données, de l'administration de systèmes, de l'audit et de la sécurité informatique. Il est gestionnaire chez PricewaterhouseCoopers LLP.

Profiter de cet article? Lire le plus récent Journal ISACA articles, devenez membre ou abonnez-vous à la Journal.

le Journal ISACA est publié par ISACA. L’adhésion à l’association, organisation bénévole au service des professionnels de la gouvernance informatique, donne le droit de recevoir un abonnement annuel au Journal ISACA.

Les opinions exprimées dans le Journal ISACA représentent les points de vue des auteurs et des annonceurs. Elles peuvent être différentes des politiques et déclarations officielles d’ISACA et / ou de l’IT Governance Institute et de leurs comités, ainsi que des opinions endossées par les employeurs des auteurs ou les rédacteurs en chef de la présente. Journal. Journal ISACA n’atteste pas de l’originalité du contenu des auteurs.

© 2012 ISACA. Tous les droits sont réservés.

Les instructeurs sont autorisés à photocopier gratuitement des articles isolés destinés à une utilisation en classe à des fins non commerciales. Pour toute autre copie, réimpression ou nouvelle publication, une autorisation écrite doit être obtenue de l'association. Si nécessaire, les propriétaires de droits d'auteur autorisent les personnes inscrites auprès du Copyright Clearance Centre (CCC), 27, rue Congress, Salem, MA 01970, à photocopier des articles appartenant à ISACA, moyennant un forfait de 2,50 USD par article, plus 25 ¢ par page. Envoyez le paiement au CCC en indiquant l'ISSN (1526-7407), la date, le volume et les numéros de première et dernière page de chaque article. La copie à des fins autres que d'usage personnel ou de référence interne, ou d'articles ou de colonnes n'appartenant pas à l'association sans l'autorisation expresse de l'association ou du détenteur des droits d'auteur est expressément interdite.