7 bonnes pratiques en matière de sécurité des bases de données : guide de la sécurité des bases de données

À retenir
Qu’est-ce que la sécurité des bases de données ?
7 bonnes pratiques de sécurité des bases de données
7 bonnes pratiques de sécurité des systèmes associés
En résumé : bonnes pratiques de sécurité des bases de données

À retenir

Séparez les serveurs de bases de données des serveurs web afin d’empêcher les attaquants d’accéder à la base de données si le serveur web est compromis. (Accéder à la section)
Auditez et surveillez régulièrement l’activité de la base de données afin de détecter les comportements suspects et d’y réagir. (Accéder à la section)
Mettez en place des contrôles d’accès stricts fondés sur le principe du moindre privilège et examinez régulièrement les autorisations des utilisateurs. (Accéder à la section)

Les bases de données contiennent certaines des données les plus sensibles d’une organisation. Il est donc essentiel de suivre les bonnes pratiques de sécurité des bases de données pour protéger ces données contre les cyberattaques et le vol de données par des personnes internes.

Une sécurité efficace des bases de données protège les informations sensibles grâce à plusieurs niveaux de contrôles qui réduisent le risque de fuite et limitent les dommages potentiels d’une fuite réussie. Nous présenterons sept bonnes pratiques de sécurité des bases de données qui créent des contrôles superposés, suivies de sept bonnes pratiques supplémentaires pour les systèmes associés. Le résultat est une défense en profondeur rigoureuse qui réduit les risques dans toute l’organisation.

Qu’est-ce que la sécurité des bases de données ?
7 bonnes pratiques de sécurité des bases de données
7 bonnes pratiques de sécurité des systèmes associés
En résumé : bonnes pratiques de sécurité des bases de données

Qu’est-ce que la sécurité des bases de données ?

La sécurité des bases de données regroupe les contrôles mis en œuvre par les organisations pour empêcher les accès non autorisés ou les fuites de données provenant des fichiers de bases de données, des systèmes de gestion de bases de données (SGBD) et des systèmes connectés. Les contrôles de sécurité comprennent des techniques d’architecture, la conception des applications, des procédures, des processus et des outils qui rendent les données plus difficiles à consulter et à utiliser.

Une sécurité des bases de données mal assurée nuira à l’efficacité des opérations, aux performances des applications et à l’expérience utilisateur. La sécurité doit être conciliée avec les besoins opérationnels, l’objectif étant de réduire les risques à un niveau acceptable tout en préservant la facilité d’utilisation.

Les bonnes pratiques et les contrôles de sécurité des bases de données s’appliquent spécifiquement aux bases de données. Toutefois, celles-ci n’existent pas dans un isolement complet : les organisations doivent donc également défendre l’écosystème plus large. Pour être correctement protégée, une base de données doit aussi bénéficier de la mise en œuvre de bonnes pratiques de sécurité plus générales, appliquées aux systèmes associés.

Voir les meilleures solutions de sécurité des bases de données

7 bonnes pratiques de sécurité des bases de données

Pour protéger une base de données, celle-ci doit se trouver dans un environnement sécurisé, protégé par son propre périmètre de sécurité et accessible uniquement à des utilisateurs sécurisés. Ces sept bonnes pratiques sécurisent spécifiquement les bases de données et leurs données.

1. Séparer les serveurs de bases de données

Par définition, les serveurs web doivent être accessibles publiquement pour pouvoir être utilisés, mais cela en fait également des cibles privilégiées pour les attaques. Une attaque réussie peut donner à un attaquant accès au serveur hôte du site web ou de l’application, ce qui lui permet d’accéder à tout ce qui est hébergé sur le serveur.

Les bases de données doivent être isolées dans un conteneur, un serveur physique ou un serveur virtuel distinct afin de permettre un renforcement supplémentaire de la sécurité et d’empêcher tout accès si le site web ou l’application est compromis. Seuls les ports nécessaires du serveur séparé doivent être ouverts et, dans la mesure du possible, l’organisation doit modifier les ports de communication par défaut pour rendre les attaques plus difficiles à mener.

Certains recommandent d’installer un serveur proxy HTTPS entre la base de données et les requêtes, mais séparer fonctionnellement le serveur web et le serveur de base de données produit le même résultat. Un serveur proxy peut toutefois être utile pour les bases de données du réseau interne qui peuvent être interrogées directement par des utilisateurs ou des appareils réseau autorisés.

Pour sécuriser davantage la base de données, envisagez de placer le serveur de base de données sur un segment de réseau physique ou virtuel distinct, avec des privilèges d’accès très restreints. La microsegmentation de ce type peut empêcher les attaquants ayant obtenu un accès plus général au réseau de se déplacer facilement latéralement pour accéder à un serveur de base de données qui pourrait ne pas apparaître sur le réseau d’un utilisateur compromis.

2. Utiliser des pare-feu pour bases de données

Les bases de données ne deviennent utiles que lorsqu’elles sont accessibles, mais cet accès doit être protégé. La première couche de défense repose sur des pare-feu propres aux bases de données, qui refusent l’accès par défaut. Le seul trafic autorisé à traverser le pare-feu doit provenir d’applications, de serveurs web ou d’utilisateurs précis ayant besoin d’accéder aux données. En l’absence de besoin spécifique, le pare-feu doit également empêcher la base de données d’établir des connexions sortantes.

L’accès direct à la base de données doit être limité ou refusé si le cas d’usage le permet. Toute modification des règles du pare-feu doit être contrôlée par des procédures de gestion des changements et déclencher des alertes pour la surveillance de la sécurité.

Les organisations peuvent déployer des outils spécialisés pour bases de données intégrant des pare-feu spécifiques, tels que Oracle Audit Vault and Database Firewall, un pare-feu de nouvelle génération (NGFW) physique ou virtuel dédié, ou des solutions de pare-feu applicatif web (WAF). Les organisations disposant de ressources plus limitées peuvent simplement déployer une version renforcée du pare-feu du système d’exploitation du serveur de base de données.

3. Sécuriser l’accès des utilisateurs à la base de données

Le nombre d’utilisateurs, d’applications et d’interfaces de programmation d’applications (API) accédant à la base de données doit être aussi faible que possible. Tout accès ne doit être accordé qu’après autorisation du réseau ou de l’application et, même dans ce cas, tout accès doit reposer sur le principe du moindre privilège et être accordé pour la durée la plus courte possible. Cette bonne pratique peut être divisée en trois sous-catégories : l’autorisation des utilisateurs, les accès privilégiés et l’utilisation des bases de données par les équipes de développement et d’exploitation (DevOps).

Autorisation des utilisateurs

Le contrôle de l’accès à la base de données est géré par l’administrateur système, ou admin. L’admin accorde des autorisations définies par les rôles et en ajoutant les comptes utilisateurs à ces rôles de base de données. Par exemple, le rôle de sécurité au niveau des lignes (RLS) restreint l’accès en lecture et en écriture aux lignes de données en fonction de l’identité de l’utilisateur, de ses appartenances à des rôles ou du contexte d’exécution de la requête.

Les solutions spécialisées de sécurité des bases de données peuvent permettre une gestion centralisée des identités et des autorisations, limiter le stockage des mots de passe et activer des politiques de rotation des mots de passe. Une gestion complète des accès peut ne pas être réaliste pour les petites organisations, mais il reste important de gérer les autorisations par rôles ou groupes plutôt que par utilisateurs individuels.

Les administrateurs doivent également renforcer les règles d’accès à la base de données :

Les mots de passe vides ne doivent pas être autorisés
Les fichiers d’installation temporaires susceptibles de contenir des mots de passe doivent être supprimés
Les comptes par défaut doivent être supprimés s’ils ne sont pas nécessaires ; sinon, leurs mots de passe doivent être modifiés par rapport aux paramètres par défaut
Exiger des identifiants uniques pour tous les utilisateurs afin d’assurer le suivi et la journalisation
Les utilisateurs et les applications doivent utiliser des comptes distincts
Les utilisateurs inactifs doivent être désactivés ou supprimés selon une planification définie
Les privilèges élevés sur la base de données doivent être journalisés, signalés et éventuellement déclencher des alertes de sécurité
Les groupes d’utilisateurs et les droits d’accès doivent être examinés périodiquement
Les comptes doivent être automatiquement verrouillés après un certain nombre de tentatives de connexion échouées, généralement recommandé à six tentatives échouées

Accès privilégiés

Les administrateurs ne doivent disposer que des privilèges strictement nécessaires pour accomplir les tâches requises, et uniquement pendant la durée précise de leur besoin d’accès. Les accès privilégiés doivent être accordés temporairement et révoqués en continu. Les grandes organisations automatisent la gestion des accès à l’aide de logiciels de gestion des accès privilégiés (PAM). Les solutions PAM fournissent un mot de passe temporaire aux utilisateurs autorisés, journalisent les activités et empêchent le partage des mots de passe.

Utilisation des bases de données par les équipes DevOps

Bien qu’elles ne soient généralement pas considérées comme des utilisateurs, les équipes DevOps doivent créer des environnements de test afin de vérifier que les applications peuvent accéder correctement aux bases de données et les utiliser. Malheureusement, l’utilisation de données de bases de données réelles ou de production entraîne souvent des fuites accidentelles de données.

Pour éviter ces problèmes, les équipes DevOps doivent appliquer les pratiques suivantes :

Les données sensibles doivent être limitées à l’environnement de production
Les environnements de test doivent être séparés physiquement et logiquement des environnements de production
Les environnements de test doivent utiliser des rôles et des autorisations distincts de ceux des environnements de production
Les développeurs ne doivent pas accéder aux environnements de production, sauf en cas d’absolue nécessité
Les environnements de test ne doivent jamais contenir de véritables données de production ; il faut utiliser à la place des jeux de données synthétiques ou anonymisés

4. Renforcer la sécurité de la base de données

De même que le serveur doit être renforcé, la base de données doit également l’être afin de prévenir les attaques et les exploits élémentaires.

Le renforcement de la sécurité d’une base de données varie selon le type de plateforme, mais les étapes courantes comprennent le renforcement de la protection par mot de passe et des contrôles d’accès, la sécurisation du trafic réseau, ainsi que le chiffrement des champs sensibles de la base de données.

Tous les services ou fonctions inutilisés ou superflus de la base de données doivent être supprimés ou désactivés afin d’empêcher leur exploitation non détectée.

Tous les contrôles de sécurité de base de données fournis par celle-ci doivent être activés. Certains le seront par défaut et d’autres peuvent avoir été désactivés pour des raisons précises, mais chacun doit être évalué et toute justification de désactivation doit être documentée. Lorsque cela est possible, les administrateurs peuvent activer la sécurité au niveau des lignes et le masquage dynamique des données sensibles.

Les équipes DevOps doivent concevoir la base de données de manière à ce que les informations sensibles restent dans des tables séparées. Les administrateurs doivent également auditer continuellement les données afin de repérer les données sensibles et de déterminer si les tables séparées doivent être modifiées ou si des mesures de sécurité supplémentaires sont nécessaires. Certaines normes réglementaires ou de conformité imposeront des exigences précises en matière de découverte des données, qui devront être mises en œuvre, respectées et documentées pour prouver la conformité.

5. Auditer et surveiller en continu l’activité de la base de données

Les équipes DevOps conçoivent les systèmes avec certaines attentes, mais après l’intégration des bases de données aux applications et leur déploiement dans un environnement de production, des accès, requêtes utilisateur ou comportements inattendus des données peuvent survenir. Les administrateurs doivent surveiller et auditer en continu les journaux, les données et l’activité de la base de données, notamment :

les journaux de connexion des utilisateurs, en particulier les tentatives de connexion et les échecs
les comptes verrouillés (à la suite de nombreuses tentatives de connexion infructueuses)
l’élévation des privilèges dans la base de données
l’extraction, la copie ou la suppression de données dans la base de données (en particulier les modifications ou extractions à grande échelle)
l’accès aux données sensibles ou réglementées (qui peut être requis à des fins de conformité)
la création de nouveaux comptes

Les audits peuvent souvent détecter les activités anormales, et les équipes de sécurité peuvent configurer des alertes de sécurité sur les événements critiques afin d’avertir les équipes de sécurité ou d’activer les alertes des outils de gestion des informations et des événements de sécurité (SIEM). Les logiciels de surveillance de l’activité des bases de données (DAM) et de surveillance de l’intégrité des fichiers peuvent fournir des alertes de sécurité spécialisées, indépendamment des fonctions natives de journalisation et d’audit des bases de données.

6. Tester la sécurité de votre base de données

Bien que les audits puissent détecter les activités malveillantes en cours, les organisations ne doivent pas attendre les attaques pour tester leurs déploiements de bases de données. Les fournisseurs de bases de données doivent faire l’objet d’une veille concernant les mises à jour, et les processus de gestion des correctifs doivent mettre à jour les bases de données avec un délai minimal.

Cependant, l’application de correctifs ne concerne que les vulnérabilités rendues publiques. Certains fournisseurs de bases de données proposent des outils de test de sécurité et de configuration, comme le Database Security Assessment Tool, qui peuvent contribuer à identifier les risques. Il ne faut toutefois pas considérer que ces outils offrent une garantie à 100 % ; ils doivent être complétés par des tests ultérieurs au moyen d’analyses de vulnérabilités et de tests d’intrusion simulant des attaques potentielles afin de révéler les erreurs de configuration, les données accessibles par inadvertance et autres problèmes.

7. Bonnes pratiques relatives aux données des bases de données

Les bases de données structurent les données, mais les données qu’elles contiennent doivent également être protégées. La première étape consiste pour une organisation à ne stocker que les données protégées nécessaires à la fonction métier. La suppression des données excessives ou l’élimination des informations historiques inutiles peut réduire l’exposition aux risques.

Ensuite, les données doivent être contrôlées délibérément. Il faut éliminer la redondance des données protégées dans l’ensemble du système et, autant que possible, éviter la duplication de ces données en dehors du système de référence. Des fonctions de hachage peuvent être appliquées aux éléments de données protégées avant de stocker, en dehors du système, les données nécessaires à des fins de correspondance. Lorsque cela est possible, les données protégées telles que les informations de santé ou les numéros de carte bancaire doivent être dissociées des informations permettant d’identifier une personne (PII).

Le chiffrement doit également être mis en œuvre pour renforcer la protection. De nombreux fournisseurs proposent des solutions pour chiffrer les données au repos, en transit, voire en cours d’utilisation. Dans la base de données, les équipes DevOps peuvent chiffrer les données ou utiliser le masquage des données pour les dissimuler dans les tables. Certains outils de chiffrement permettent même de traiter et de rechercher les données sans les déchiffrer, de sorte qu’elles restent toujours chiffrées et protégées.

Certains fournisseurs cloud, comme Oracle, chiffrent les données stockées par défaut ou proposent des outils de gestion des clés de chiffrement, comme Azure Key Vault. Cependant, les organisations elles-mêmes sont responsables de garantir une protection adéquate tout au long du processus de stockage des données et de transfert des données.

7 bonnes pratiques de sécurité des systèmes associés

Si une pratique de sécurité ne s’applique pas spécifiquement aux bases de données, elle ne peut pas être considérée comme un simple composant de la sécurité des bases de données. Cela ne diminue toutefois pas l’importance de ces pratiques ni la nécessité de les mettre en place pour garantir la sécurité des bases de données.

1. Bonnes pratiques de sécurité physique

Bien qu’elle puisse parfois être négligée, la sécurité physique ne doit pas être tenue pour acquise. L’accès physique d’un attaquant à un centre de données peut compromettre même les meilleures pratiques et technologies de cybersécurité. La sécurisation de l’environnement physique contenant les serveurs et les équipements réseau doit être la première bonne pratique fondamentale en matière de sécurité informatique.

Les centres de données sur site nécessitent des mesures de sécurité physique telles que des caméras, des serrures et du personnel de sécurité présent sur place ; tout accès physique aux serveurs doit être contrôlé, journalisé et régulièrement examiné. Si les accès réguliers ne sont pas habituels, des alertes doivent être générées.

Les ressources hébergées dans le cloud peuvent échapper au contrôle physique direct d’une organisation, mais pas à sa responsabilité. L’organisation doit toujours confirmer que la sécurité physique est adéquate, ce qui est généralement assuré par le respect, par le fournisseur cloud, des normes de sécurité physique définies dans un référentiel de conformité tel que :

ISO 27001
ISO 20000-1
NIST SPs (SP 800-14, SP 800-23 et SP 800-53)
Department of Defensecadre technique d’assurance de l’information
SSAE 18 SOC 1 Type II, SOC 2 Type II et SOC 3

2. Utiliser des pare-feu pour applications web et réseaux

Les pare-feu fournissent une protection fondamentale à toutes les ressources informatiques. En plus de déployer un pare-feu pour la base de données, les organisations doivent déployer des pare-feu de nouvelle génération (NGFW) pour protéger leurs réseaux et des pare-feu applicatifs web pour protéger les sites web et les applications qui accèdent à la base de données.

Ces pare-feu plus généraux protègent l’organisation dans son ensemble contre les attaques qui touchent les bases de données ainsi que d’autres systèmes, comme les attaques par injection SQL et les attaques par déni de service distribué (DDoS).

3. Authentification des utilisateurs

Lorsque les bases de données autorisent les utilisateurs à y accéder, on part du principe que l’utilisateur a déjà été authentifié et que son identité a été vérifiée. Les bonnes pratiques de sécurité exigent l’authentification ou la vérification de l’identité de tous les types d’utilisateurs, tels que les invités, les employés, les clients et les administrateurs. Les sous-catégories de la sécurité de l’authentification des utilisateurs comprennent la gestion des menaces internes, la vérification des utilisateurs et la gestion des accès privilégiés (PAM).

Gestion des menaces internes

Certaines données peuvent avoir une telle valeur que des organisations criminelles paieront des employés pour les divulguer, voire placeront leurs propres membres dans des emplois sous de faux prétextes afin d’accéder aux données. Pour réduire ces risques liés aux menaces internes, les organisations doivent effectuer des vérifications d’antécédents pour les programmeurs, les prestataires, les professionnels de la sécurité, les administrateurs de bases de données et toute personne susceptible d’accéder à des informations sensibles ou de les rediriger.

Voir les meilleures solutions de prévention des pertes de données (DLP)

Une fois l’identité des employés confirmée, les organisations mettent en place des outils d’analyse comportementale des utilisateurs et des entités (UEBA), des fonctionnalités UEBA dans d’autres outils de sécurité et des journaux d’audit afin de rechercher les signes d’un comportement inapproprié ou anormal. Il faut garder à l’esprit que des identifiants dérobés utilisés par un pirate apparaîtront, pour la plupart des outils de sécurité, comme un accès autorisé jusqu’à la détection d’un comportement inhabituel. Enfin, il convient d’établir une politique de désactivation des comptes ou des accès superflus lorsque les employés changent de fonction ou quittent l’entreprise.

Vérification des utilisateurs

Pour préserver l’intégrité d’une identité vérifiée, les utilisateurs doivent confirmer régulièrement, voire constamment (notamment dans le cadre du zero trust), leur identité. Les mots de passe restent la méthode d’identification la plus couramment utilisée ; cependant, certaines organisations ont commencé à déployer l’authentification sans mot de passe.

Pour les comptes d’administrateurs et autres comptes privilégiés, les organisations doivent toujours utiliser l’authentification multifacteur (MFA). Pour les données les plus importantes, les organisations devraient envisager une authentification multifacteur physique, comme les cartes magnétiques, les jetons USB et d’autres méthodes qui ne peuvent pas être dérobées ou facilement reproduites par des attaquants distants.

Pour les organisations qui utilisent des mots de passe, il convient d’employer des mots de passe robustes et une gestion des mots de passe :

La complexité des mots de passe (combinaison de majuscules, de chiffres et de caractères spéciaux) ou des phrases secrètes (mots de passe beaucoup plus longs) doit être exigée
La longueur des mots de passe doit être d’au moins 8 caractères, et supérieure pour les comptes privilégiés
Les hachages des mots de passe doivent être stockés sous forme chiffrée et avec un sel
Les comptes doivent être verrouillés après plusieurs tentatives de connexion infructueuses ; jusqu’à six pour les comptes d’utilisateurs standard et seulement trois pour les comptes privilégiés ou d’administrateurs
Les mots de passe doivent expirer

Les organisations qui déploient des gestionnaires de mots de passe peuvent exiger une complexité accrue et des expirations plus fréquentes des mots de passe sans craindre que les utilisateurs les stockent dans des emplacements non sécurisés ou vulnérables. Les accès des utilisateurs doivent être régulièrement renouvelés afin d’empêcher les accès d’utilisateurs ou d’appareils obsolètes et oubliés.

Gestion des comptes privilégiés

L’utilisation abusive des accès administrateur peut causer d’immenses dommages ; les identifiants d’administration doivent donc être protégés par des mesures supplémentaires. Les exigences relatives aux mots de passe doivent être plus strictes, mais les organisations peuvent également envisager des outils de gestion des accès privilégiés (PAM) qui génèrent des mots de passe temporaires assortis de privilèges limités, de sorte que les utilisateurs autorisés doivent s’authentifier à chaque accès à la base de données.

Qu’elles utilisent ou non des outils spécialisés, les organisations doivent appliquer des règles supplémentaires aux accès privilégiés :

Aucun partage de mot de passe
Toutes les sessions et activités sont journalisées et régulièrement examinées
Toute élévation des privilèges des utilisateurs doit être journalisée et régulièrement examinée

4. Sécurité des appareils

Tous les appareils qui accèdent à la base de données, ainsi que le réseau en général, doivent être vérifiés et surveillés en continu afin de détecter toute compromission potentielle. L’antivirus fournit le niveau minimal de protection, mais, pour renforcer la protection, les organisations déploient souvent des outils de détection et de réponse sur les terminaux (EDR) ou des outils de détection et de réponse étendues (XDR), qui assurent une détection plus proactive.

Les appareils des administrateurs doivent être davantage restreints par l’utilisation de restrictions fondées sur les adresses IP et MAC, de l’autorisation par liste blanche, ou du contrôle d’accès au réseau (NAC). Ces mesures limitent le nombre d’appareils autorisés à accéder aux zones sensibles afin d’éviter que des identifiants dérobés ne soient trop utiles à un pirate.

Pour l’infrastructure liée à la base de données (ou à d’autres systèmes sensibles), l’organisation doit documenter tous les appareils, applications et outils. En outre, les fichiers de configuration et le code source doivent être verrouillés, accessibles uniquement par des comptes d’administrateurs protégés, et sécurisés par des politiques et des outils de gestion des changements.

Enfin, tous les systèmes doivent être surveillés. Les réseaux doivent être surveillés par des outils XDR ou des systèmes de détection et de prévention des intrusions (IDPS). Tous les systèmes de sécurité doivent envoyer des alertes aux gestion des informations et des événements de sécurité (SIEM), aux centres des opérations de sécurité (SOCs), ou aux équipes de détection et de réponse gérées (MDR).

5. Sécurité des applications et des API

Les applications et les API qui se connectent à la base de données ou à d’autres ressources informatiques doivent être sécurisées. Les équipes DevOps doivent commencer par appliquer des outils d’analyse des vulnérabilités aux sites web et applications développés en interne. Les grandes organisations déploieront des outils de sécurité des applications et des outils de sécurité des API pour mieux protéger et surveiller les systèmes.

6. Mettre régulièrement à jour le système d’exploitation et les correctifs

Les meilleurs outils et stratégies de sécurité seront compromis par une maintenance insuffisante. Tous les systèmes, applications, outils et micrologiciels doivent être surveillés afin de détecter les correctifs récemment publiés ou les vulnérabilités divulguées. Les systèmes critiques, notamment ceux qui se connectent aux bases de données, doivent être prioritaires pour la gestion régulière des correctifs et la gestion des vulnérabilités. Les composants de la chaîne d’approvisionnement logicielle, tels que les bibliothèques open source, doivent également faire l’objet d’un suivi et être corrigés en cas de vulnérabilités ou de mises à jour.

7. Bonnes pratiques de continuité d’activité

Même le meilleur plan peut rencontrer des problèmes. Que le problème provienne d’un employé mécontent, d’un pirate malveillant, d’une panne de courant ou d’une inondation, les bonnes pratiques de continuité d’activité et de reprise après sinistreconçoivent des systèmes résilients et permettant une reprise rapide.

Les architectures redondantes maintiennent la disponibilité en cas de défaillance du système. Les serveurs peuvent être rendus plus résilients grâce à une redondance active-passive pour assurer la reprise après basculement, ou à des serveurs d’équilibrage de charge qui répartissent les charges potentielles entre plusieurs serveurs.

Les sauvegardes des données et des systèmes protègent contre une défaillance complète du système ou une activité malveillante. Les sauvegardes doivent être régulières et hautement protégées. Les bonnes pratiques suivent la règle de sauvegarde 3-2-1 : trois copies des données sauvegardées, deux types de stockage et au moins une copie conservée hors site et hors ligne. Les sauvegardes ne doivent absolument pas être accessibles au public ; elles doivent être chiffrées et stockées séparément des clés de chiffrement.

Les sauvegardes doivent inclure non seulement les données, mais aussi les paramètres, les applications logicielles et les configurations de l’infrastructure sous-jacente, afin de permettre une reprise rapide des systèmes affectés. Les sauvegardes des infrastructures critiques doivent être testées régulièrement pour vérifier l’efficacité des processus de sauvegarde et établir des points de référence concernant les délais de reprise attendus.

À lire également : Créer une architecture résiliente aux ransomwares

En résumé : bonnes pratiques de sécurité des bases de données

Les violations de données peuvent entraîner une multitude d’amendes, d’impacts négatifs sur l’activité et de poursuites judiciaires. Malheureusement, des accidents et des incidents de sécurité peuvent survenir même dans des entreprises préparées, et leur coût dépendra directement des risques qu’une organisation choisit d’accepter. Une bonne pratique de sécurité des bases de données permet de compenser le risque croissant de violation de données, alors même que les attaques et leurs conséquences financières augmentent. Les organisations doivent examiner, adopter et maintenir autant de bonnes pratiques que possible afin de réduire le risque de violation et les coûts prévus des incidents futurs.

À lire ensuite : Considérations de sécurité pour les lacs de données
Cet article a été initialement rédigé par Paul Rubens et mis à jour par Chad Kime le 21 avril 2023.