Les données sont le nouvel or des grandes entreprises et organisations. Elles sont considérées comme l'élément vital de la plupart des entreprises modernes et il existe une multitude d'opportunités de vente ou de commercialisation auprès du large public d'Internet. Pour les grandes entreprises de commerce électronique ou de médias sociaux, les données déterminent leur capacité à générer des revenus et des revenus importants pour lesquels les données sont étroitement sécurisées et disposent d'une protection sophistiquée contre toute attaque malveillante et d'intrusion en ligne.
Donc, des données comme l'or, leur état précieux commence une fois qu'elles sont traitées. Sa valeur brute est pleine de désordre comme s'il s'agissait d'un gigantesque grignotage non trié. Une fois son essence structurée, la valeur des données se multiplie. Imaginez, si vous avez un site éducatif qui permet aux utilisateurs de payer. Une fois que vous avez des tonnes de conférences et de modules que votre public cible peut apprendre, développer et gagner un certain degré de productivité, vous avez saisi le goût de l'opportunité et du succès car vous avez la possibilité de réglementer les frais avant qu'ils ne puissent obtenir les données structurées qu'ils souhaitent. . Bien que cela ressemble au rêve de succès de tout le monde, lorsqu'il s'agit de données volumineuses et de leur essence sous-jacente, il y a des tonnes de complications pour les traiter et une préoccupation importante concerne les menaces pesant sur votre base de données.
Les menaces de base de données en général ont de nombreux et vastes secteurs à examiner et à examiner. Cependant, les causes les plus courantes sont le vol de données et les violations de données. Une autre menace courante est les privilèges étendus ou l'accès aux bases de données mal attribués et/ou fournis à un utilisateur. La protection de l'intégralité de l'hôte du serveur est une préoccupation pour quiconque gère une base de données. Renforcez votre sécurité et traitez tous les types d'attaques applicables telles que l'écoute clandestine, la modification, la lecture et le déni de service (DDoS) non seulement pour la base de données mais également pour l'ensemble de sa pile sous-jacente qui a accès ou qui s'interface avec votre stockage de données.
Dans ce blog, nous discuterons de l'étendue de la nécessité pour laquelle vous devez comprendre et avoir des privilèges d'accès à la base de données.
Dangers de mauvais privilèges d'accès
Nous devons inévitablement partager ou au moins créer un utilisateur que ce soit au niveau physique et technique. Alors que donner accès à quelqu'un d'autre signifie que vous faites confiance à la personne. Cela signifie également que la personne autorisée doit comprendre le danger et le péril de partager l'accès et les données du monde extérieur.
Le point le plus important de la sécurisation de vos privilèges d'accès est le niveau de compréhension de la sécurité entre vos ingénieurs, tels qu'un administrateur de base de données, un ingénieur en sécurité ou un administrateur de serveur. Si la compréhension est mauvaise ou manque de connaissances et d'expérience, en particulier des vulnérabilités et des expositions les plus récentes, cela peut être un problème pour l'organisation ou l'entreprise.
Il y a des choses de base qui doivent être comprises et prises en compte afin qu'il y ait un minimum ou du moins qu'il ne puisse pas être intrus ou exposé. Sinon, cela pourrait mettre vos données en danger du monde extérieur ou du moins à la mauvaise personne ou aux mauvaises personnes. Peut-être pour voler vos données et les utiliser dans leur propre intérêt pour gagner de l'argent ou ils peuvent vous les racheter et demander de l'argent en échange de votre mauvaise mise en œuvre de la sécurité.
Dans cette section, voyons quelques causes courantes de ces menaces de sécurité.
Partage du privilège d'accès root
Pour un environnement sur site, un cas habituel de violation de base de données repose principalement sur le risque de donner l'accès root soit au niveau du système d'exploitation, soit au niveau du logiciel de base de données. Il existe des cas où le mot de passe root est distribué et exposé à plusieurs personnes, ce qui ne devrait être limité qu'aux administrateurs travaillant uniquement sur le système. Cela peut se produire en raison d'un manque de liste de contrôle de sécurité ou de mesures dans le protocole avant la mise en œuvre des privilèges d'accès. Avoir une liste de contrôle de sécurité permet de suivre tous les accès et privilèges qui pourraient exposer des risques et des dangers, en particulier lorsqu'un utilisateur spécifique du système d'exploitation est exposé à un intrus. La liste de contrôle vous aide également à discuter ou à avoir un aperçu des mesures de sécurité en place et mises en œuvre en tant que protocole pour votre organisation.
Par exemple, un utilisateur disposant d'un accès root peut faire beaucoup de dégâts, comme supprimer toutes vos données de votre disque de stockage physique, réinitialiser le mot de passe root, créer son propre utilisateur/mot de passe qui ressemble comme un utilisateur légitime (peut être utilisé pendant très longtemps pour récolter des données à moins d'être pris tôt), sudo vers un autre utilisateur du système d'exploitation tel que l'utilisateur postgres, et beaucoup plus de choses effrayantes à apprécier par l'intrus.
Si vous utilisez MongoDB, un utilisateur avec un accès root peut se connecter à votre serveur de base de données. Tant que l'intrus peut localiser votre /etc/mongod.conf ou votre fichier de configuration mongodb et localiser le chemin de votre clé, il est facile de se connecter. Par exemple, l'utilisation de cette commande vous permet de vous connecter,
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"
Considérez une configuration d'installation normale de MySQL, un accès root peut être laissé sans mot de passe pour l'accès localhost. Il est facile d'y accéder une fois que vous êtes root. L'accès à des fichiers tels que $HOME/.my.cnf ou la visualisation du contenu de /etc/my.cnf vous permettra d'y accéder facilement.
Il est fortement recommandé de limiter uniquement ou simplement de donner votre accès root y au plus petit nombre de personnes qui travaillent directement avec le serveur pour mettre à jour les packages, les mises à jour de sécurité et appliquer les correctifs requis par l'équipe de développement.
Utiliser correctement sudoers
Les logiciels de base de données open source grand public tels que PostgreSQL, MySQL/MariaDB, MongoDB nécessitent la création d'un utilisateur de système d'exploitation spécifique. L'utilisateur du système d'exploitation a besoin d'un rôle spécifique limité pour permettre la gestion de ses capacités au sein de la fonctionnalité de base de données. Des autorisations de lecture et d'écriture appropriées doivent être définies pour le chemin du périphérique de stockage sous-jacent. Cependant, il y a des cas où certains qui utilisent ces utilisateurs spécifiques pour le logiciel de base de données ont des privilèges sudo qui sont également capables d'accéder à l'utilisateur uniquement désigné pour l'accès à la base de données. Les privilèges de l'utilisateur dans le système d'exploitation doivent être limités et il est préférable de limiter son accès en fonction du rôle. Par exemple, pour Percona Server CVE-2016-6664, bien que cela ait été corrigé, ce type de vulnérabilité est un exemple d'attaque possible d'un utilisateur spécifique qui a accès au compte MySQL et obtient un accès root. Les utilisateurs de Sudo doivent être passés en revue et faire comprendre que le rôle n'est limité qu'à un travail spécifique.
L'activation d'un système d'audit Linux tel que auditd peut aider à améliorer la sécurité car elle augmente les privilèges d'accès négligés au niveau du système d'exploitation, ce qui pourrait entraîner des vulnérabilités de sécurité de votre base de données. SELinux et AppArmor sont de bons exemples de modules de sécurité pour votre environnement Linux qui hébergent votre système de base de données pour vous aider à améliorer votre sécurité contre les intrus ou les violations qui mettraient en péril vos données.
Accorder des privilèges d'accès à la base de données
Les bases de données open source grand public offrent une liste granulaire de privilèges qui peuvent être personnalisés pour être attribués uniquement à une action spécifique pour un utilisateur spécifique. Il s'agit d'un moyen complet d'aider les administrateurs de bases de données à séparer en toute sécurité les données et à cibler les actions en fonction de privilèges spécifiques.
Privilèges d'accès communs
Vos privilèges les plus couramment utilisés doivent être basés sur ces trois catégories :
-
Capable de lire/trouver comme SELECT, SHOW VIEW, FIND
-
Capable d'insérer/mettre à jour/supprimer comme INSERT, UPDATE, DELETE, REMOVE
-
Capable d'effectuer des actions administratives telles que CREATE USER, CREATE ROLE, ALTER, REPLICATION, DROP USER/TABLES/ SCHEMA, opérations de mise à mort, etc.
Ces catégories peuvent être étendues à des privilèges plus raffinés en fonction de votre liste de contrôle de sécurité. Il est bon de définir un utilisateur spécifique à créer avec des privilèges spécifiques pour une tâche spécifique. Par exemple, une application peut avoir plusieurs utilisateurs avec ses propres privilèges désignés. Bien que l'application puisse être aussi complexe avec ce type d'implémentation. Il existe des cas où la connectivité par utilisateur peut être gourmande en ressources, comme l'utilisation d'ORM comme Hibernate, par exemple. En revanche, cela dépend de la conception architecturale de votre application. Le but d'une base par utilisateur dans une application peut aider à maintenir un privilège d'accès à la base de données plus raffiné et à éviter de nuire à vos données à cause de suppressions, de mises à jour non désirées ou d'une injection SQL attaquant votre base de données.
Dans la plupart des cas, une application utilise un utilisateur pour se connecter à la base de données qui est uniquement limitée à ses actions spécifiquement pour que l'application s'exécute. Il est préférable que vous conceviez votre privilège d'utilisateur d'application pour un accès en lecture-écriture uniquement. Alors que si des actions administratives sont requises, un script, un démon ou un module spécifique dans votre accès à l'application doit être séparé des utilisateurs normaux.-.
Accès à la base de données à éviter
PostgreSQL et MySQL/MariaDB ont cette option pour accorder à un utilisateur utilisant TOUS les privilèges. Pour PostgreSQL, il est également préférable d'avoir votre utilisateur avec NOSUPERUSER. Si possible, cela doit être évité à tout prix. Ce privilège peut effectuer la plupart de toutes les actions susceptibles de détruire ou de nuire à vos précieuses données. Vous pouvez utiliser TOUS les privilèges pour votre accès administrateur ou root, mais vous êtes limité aux utilisateurs qui ont besoin des super privilèges pour effectuer des tâches administratives et gérer les données.
Accès par table ou par schéma
C'est une bonne pratique de ne donner accès à un utilisateur que pour les tables requises. . Ainsi, même si l'utilisateur dispose de certains privilèges administratifs, tout dommage ne concerne qu'un ensemble limité de tables. Soit vous pouvez définir un schéma à l'échelle ; fournir un accès à une table limitée fournit un type de privilèges granulaire et vous aide à protéger vos données.
Accès limité à l'hôte uniquement
Se connecter via son adresse IP ressource permet de limiter l'accès à vos données. Évitez d'utiliser '%' tel que dans MySQL par exemple,
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';L'étendue des dommages est exposée à tout hôte auquel se connecter et ce n'est pas ce que vous vouliez qu'il se produise. Cela impose une vulnérabilité et le défi d'intrusion dans votre base de données est très faible.
Pour PostgreSQL, assurez-vous que vous avez défini votre pg_hba.conf et l'utilisateur sur sa limite spécifique d'hôte uniquement. Cela s'applique également à MongoDB pour lequel vous pouvez le définir dans votre fichier de configuration MongoDB ou /etc/mongodb.conf. Dans MongoDB, vous pouvez jouer avec les restrictions d'authentification et définir clientSource ou serverAddress respectivement, mais uniquement pour lesquelles vous demandez au client ou à l'utilisateur de se connecter ou d'être validé.
Contrôle d'accès basé sur les rôles
Le contrôle d'accès basé sur les rôles (RBAC) dans les bases de données fournit un moyen pratique de gérer l'utilisateur ou un moyen simple de regrouper un utilisateur avec son privilège désigné lié à une liste d'utilisateurs ou à un groupe d'utilisateurs.
Bien que vous deviez noter que les rôles sont gérés différemment dans toutes les bases de données open source. Par exemple, MySQL a défini les rôles comme suit,
Un rôle MySQL est une collection nommée de privilèges. Comme les comptes d'utilisateurs, les rôles peuvent avoir des privilèges accordés et révoqués.
Un compte utilisateur peut se voir attribuer des rôles, ce qui accorde au compte les privilèges associés à chaque rôle. Cela permet d'attribuer des ensembles de privilèges aux comptes et offre une alternative pratique à l'octroi de privilèges individuels, à la fois pour conceptualiser les attributions de privilèges souhaitées et pour les mettre en œuvre.
MongoDB définit le rôle avec RBAC comme,
MongoDB utilise le contrôle d'accès basé sur les rôles (RBAC) pour régir l'accès à un système MongoDB. Un utilisateur se voit attribuer un ou plusieurs rôles qui déterminent l'accès de l'utilisateur aux ressources et aux opérations de la base de données. En dehors des attributions de rôle, l'utilisateur n'a pas accès au système.
Alors que dans PostgreSQL,
PostgreSQL gère les autorisations d'accès aux bases de données en utilisant le concept de rôles. Un rôle peut être considéré soit comme un utilisateur de base de données, soit comme un groupe d'utilisateurs de base de données, selon la configuration du rôle. Les rôles peuvent posséder des objets de base de données (par exemple, des tables et des fonctions) et peuvent attribuer des privilèges sur ces objets à d'autres rôles pour contrôler qui a accès à quels objets. De plus, il est possible d'accorder l'appartenance à un rôle à un autre rôle, permettant ainsi au rôle de membre d'utiliser les privilèges attribués à un autre rôle.
Le concept de rôles englobe les concepts d'"utilisateurs" et de "groupes". Dans les versions de PostgreSQL antérieures à la 8.1, les utilisateurs et les groupes étaient des types d'entités distincts, mais il n'y a désormais que des rôles. N'importe quel rôle peut agir en tant qu'utilisateur, groupe ou les deux.
Bien que ces bases de données implémentent les rôles spécifiques à leur utilisation, elles partagent le concept d'attribution de rôles à l'utilisateur pour attribuer des privilèges de manière pratique. L'utilisation de rôles permet aux administrateurs de bases de données de gérer les utilisateurs requis pour se connecter ou accéder à la base de données.
Imaginez si vous avez une liste d'utilisateurs que vous devez gérer ou une liste d'utilisateurs qui peuvent être supprimés ou révoqués lorsqu'ils ne sont plus nécessaires. Dans certains cas spécifiques, si une certaine tâche nécessite du travail, les administrateurs de base de données peuvent créer des utilisateurs avec des rôles déjà en place. Ces utilisateurs créés peuvent être affectés à un rôle spécifique pour une courte période, puis révoqués une fois qu'ils ne sont plus nécessaires.
Les audits aident également à isoler les utilisateurs soupçonnés de vulnérabilités ou d'exposition de données. Dans ce cas, cela permet de gérer très facilement les utilisateurs avec des rôles.
Système de gestion des utilisateurs
Si la sécurité de vos données est gérée et mise en œuvre de manière appropriée, cela vous ouvre la voie vers le succès. Bien qu'il n'y ait pas de solution parfaite car les vulnérabilités et les intrusions évoluent toujours aussi. C'est comme un ver car il essaie de se cacher tout le temps jusqu'à ce qu'il soit capable d'atteindre son objectif de violer votre sécurité et d'accéder à vos données. Sans outils appropriés tels que des systèmes d'alerte ou des avis pour toute insécurité et vulnérabilité, il serait difficile de protéger vos données.
ClusterControl vous aide à gérer vos utilisateurs et à vérifier ou vérifier les privilèges de vos utilisateurs depuis les équilibreurs de charge jusqu'aux principaux utilisateurs de la base de données. Il propose également des conseillers et des alertes afin qu'il vous avertisse d'éventuelles vulnérabilités ou intrusions.
Par exemple, l'utilisation d'un MySQL/MariaDB avec un ProxySQL initial permet d'importer et d'ajouter des utilisateurs. Pour importer des utilisateurs, il collecte la liste des utilisateurs présents dans votre cluster MySQL/MariaDB actuel et vous propose de revoir ses privilèges actuels. Voir ci-dessous,
Aussi dans ce cas, un utilisateur ProxySQL peut être désactivé rapidement si une telle vulnérabilité a été connu pour l'utilisateur spécifique.
ClusterControl vous propose également de gérer directement les utilisateurs de votre base de données comme pour MySQL/MariaDB ou PostgreSQL. Pour MySQL/MariaDB, vous pouvez accéder à
Pour PostgreSQL,
Avec ClusterControl, vous pouvez personnaliser vos alertes en utilisant les conseillers. Les conseillers sont des entités basées sur des scripts qui sont modifiables. Par exemple, il s'agit d'un cluster MySQL/MariaDB comme indiqué ci-dessous, accessible via
En cliquant sur le bouton Modifier, vous pouvez personnaliser la façon dont ClusterControl réagirait au cas où il trouverait des utilisateurs avec n'importe quel hôte ou '%" ou un utilisateur sans mot de passe. Voyez comment le script s'affiche une fois que vous appuyez sur le Bouton Modifier.
Une fois que ClusterControl découvre que l'un de ces conseillers est déclenché, une alerte s'affichera et sera également envoyée à l'e-mail que vous avez configuré ou si des notifications tierces sont intégrées, il en sera informé là aussi.
Conclusion
Le privilège d'accès à la base de données est l'une des principales cibles de préoccupation pour les violations de données et les intrusions. Si votre utilisateur de base de données est exposé ou s'il y avait une menace majeure pour la version actuelle de la base de données qui n'a pas été corrigée, les chances d'être piraté ou la cible de ransomware et de vol sont très élevées. Comprendre les privilèges d'accès et définir les limites correctes vous aide à atténuer les risques d'exposition de vos précieuses données.
