Cet article est partagé par la communauté Huawei Cloud « Capacités de sécurité GaussDB (DWS) 3A », auteur : yd_281561943.
1. Introduction
- Version applicable : [8.0.0 (et supérieure)]
La sécurité des bases de données fait référence à la technologie qui protège les bases de données pour empêcher les utilisateurs non autorisés de voler, de falsifier et de détruire les informations contenues dans la base de données. La technologie de sécurité des bases de données peut être simplement divisée en trois A :
- Authentification : l'authentification résout le problème de savoir qui est autorisé à entrer (entrée)
- Autorisation : Autorisation pour résoudre le problème de ce qui peut être fait (travail)
- Audit : l'audit résout le problème de ce qui a été fait (suivi)
2. Authentification——Authentification
L'authentification de connexion résout le problème de savoir si les utilisateurs peuvent se connecter à la base de données. Ce produit prend en charge les méthodes d'authentification suivantes :
- Authentification basée sur l'hôte : le serveur vérifie le fichier de configuration en fonction de l'adresse IP du client, du nom d'utilisateur et de la base de données à laquelle accéder pour déterminer si l'utilisateur a réussi l'authentification.
- Authentification par mot de passe : y compris l'authentification par mot de passe crypté pour les connexions à distance et l'authentification par mot de passe non crypté pour les connexions locales.
- Authentification par certificat : ce mode nécessite la configuration d'une connexion SSL et le client doit fournir un certificat SSL valide, et aucun mot de passe utilisateur n'est requis.
- Authentification tierce : ldap, oneaccess, etc.
Ces méthodes nécessitent toutes de configurer le fichier "pg_hba.conf", au format de fichier pg_hba.conf, pg_hba est constitué de plusieurs lignes d'enregistrements HBA :
La signification d'un enregistrement HBA indique quels utilisateurs (USER) sont autorisés, à partir de quelles adresses IP (ADDRESS), dans quel type de connexion (TYPE), dans quelle méthode d'authentification (METHOD) et à quelles bases de données (DATABASE) se connecter.
Lors de l'authentification, les enregistrements du fichier hba sont vérifiés de bas en bas pour chaque demande de connexion. Si l'enregistrement actuel correspond, il est renvoyé. L'ordre des enregistrements HBA est très critique. Cette logique de hba est très importante et ne doit pas être modifiée facilement, sinon elle entraînerait de très graves problèmes.
Cas : problèmes causés par des modifications de la logique HBA
Il y a eu un problème avec la connexion ldap. Pendant le processus de mise à niveau, les enregistrements du fichier pg_hba.conf ont été triés, ce qui a entraîné le changement de l'ordre des lignes de configuration ldap avant et après la mise à niveau vers la fin de la ligne de configuration sha256. En raison du mécanisme de parcours séquentiel de pg_hba.conf, après la mise à niveau, l'utilisateur ldap ne correspond pas correctement à la ligne de configuration sha256 et la connexion échoue.
Afin de résoudre les problèmes causés par le changement d'ordre, la première version du plan de modification consiste à placer la logique de jugement ldap au début du parcours de la boucle : regardez d'abord le type d'authentification s'il s'agit d'une authentification ldap, jugez s'il s'agit d'une authentification ldap. Le champ méthode de la ligne de configuration est ldap. Sinon, passez à la ligne suivante jusqu'à ce que la méthode soit trouvée ldap.
Dans cette version du plan de modification, les connexions d'authentification LDAP correspondent à tous les enregistrements HBA LDAP. Lorsque l'utilisateur se connecte à la base de données, la connexion peut réussir, mais l'activité ne peut pas être effectuée et un message d'erreur est signalé : "Nom d'utilisateur/mot de passe invalide, connexion refusée.". La raison en est que lorsque les nœuds internes exécutent des instructions, l'authentification entre les nœuds sera effectuée. Le type d'authentification est de confiance et aucun mot de passe ne sera fourni. Après modification, seuls les enregistrements ldap seront mis en correspondance et la méthode ldap nécessite un mot de passe, signalant ainsi une erreur.
Avant et après la mise à niveau, les emplacements des lignes de configuration ldap et sha256 sont les suivants :
Avant la mise à niveau : héberger tous @/etc/ldap/ldap_user 0.0.0.0/0 ldap ldapserver=xxx.xxx.xxx.xxx ldapport=xxx ldapprefix="CN=" ldapsuffix="OU=test_dmj_group,DC=com" héberger tous tous 0.0.0.0/0 sha256 Après la mise à niveau : héberger tous tous 0.0.0.0/0 sha256 héberger tous @/etc/ldap/ldap_user 0.0.0.0/0 ldap ldapserver=xxx.xxx.xxx.xxx ldapport=xxx ldapprefix="CN=" ldapsuffix="OU=test_dmj_group,DC=com"
TYPE : le type est l'un des quatre types suivants : local, hôte, hostssl et hostnossl.
Respectivement:
local : seules les connexions socket de domaine Unix sont autorisées.
hôte : autorise les connexions TCP/IP et peut faire correspondre les demandes de connexion SSL et non SSL.
hostssl : autorise les connexions TCP/IP et correspond uniquement aux demandes de connexion SSL.
hostnossl : autorise les connexions TCP/IP et ne correspond qu'aux demandes de connexion non SSL.
DATABASE : vous pouvez utiliser all pour représenter toutes les bases de données, ou vous pouvez spécifier explicitement les bases de données en les séparant par des virgules.
UTILISATEUR : Vous pouvez utiliser all pour représenter tous les utilisateurs, ou vous pouvez spécifier explicitement les utilisateurs en les séparant par des virgules. Peut être le nom d'un utilisateur de base de données spécifique ou un nom de groupe précédé de +. La marque + signifie en fait « correspondre à n'importe quel rôle qui appartient directement ou indirectement à ce rôle », alors qu'un nom sans la marque + ne correspond qu'à ce rôle spécifique.
ADRESSE : L'adresse à laquelle l'enregistrement de déclaration correspond et à laquelle permet l'accès. Lorsque le type est local, cela signifie une connexion locale et aucune adresse IP ne doit être spécifiée.
MÉTHODE : les méthodes d'authentification incluent trust, rejet, md5, sha256, ldap, cert, oneaccess, etc.
trust : liste blanche, autorisant les connexions sans condition.
Rejeter : liste noire, rejette inconditionnellement les connexions.
md5 : la méthode d'authentification par mot de passe de pg n'est pas sûre.
sha256 : authentification par mot de passe pour gaussdb.
ldap : utilisez LDAP pour l'authentification tierce.
cert : Mode d'authentification du certificat client. Ce mode nécessite la configuration de la connexion SSL et nécessite que le client fournisse un certificat SSL valide. Aucun mot de passe utilisateur n'est requis.
oneaccess : utilisez oneaccess pour l’authentification tierce.3.Autorisation——Autorisation
Les autorisations indiquent si les opérations d'un utilisateur sur un objet de base de données sont autorisées. Les autorisations dans GaussDB (DWS) incluent trois scénarios : les autorisations système, les autorisations des objets de données et les autorisations utilisateur.
3.1 Autorisations système
3.1.1 Séparation des pouvoirs
Par défaut, les administrateurs système dotés de l'attribut SYSADMIN disposent de l'autorité la plus élevée sur le système. Dans la gestion d'entreprise réelle, afin d'éviter les risques élevés causés par une concentration excessive des droits des administrateurs système, une séparation des pouvoirs peut être mise en place et les autorisations de l'attribut CREATEROLE et AUDITADMIN de l'administrateur système sont accordées respectivement à l'administrateur de sécurité et à l'administrateur d'audit. .
3.1.2 Autorisation d'autorisation du système
Les autorisations système sont également appelées attributs utilisateur, notamment SYSADMIN, CREATEDB, CREATEROLE, AUDITADMIN et LOGIN.
Les autorisations système peuvent être autorisées lors de la création ou de la modification de rôles ou d'utilisateurs. Dans l'option de l'instruction d'option CREATE/ALTER ROLE/USER user_name [WITH], les champs suivants peuvent être définis pour implémenter l'autorisation d'autorisation système.
Administrateur système | NOSYSADMIN
Déterminez si un nouveau rôle est un « administrateur système ». Le rôle avec l'attribut SYSADMIN possède l'autorité la plus élevée sur le système. La valeur par défaut est NOSYSADMIN.
ADMINISTRATEUR AUDIT | NOAUDITADMIN
Définissez si le rôle possède des attributs de gestion d'audit. La valeur par défaut est NOAUDITADMIN.
CRÉÉDB | NOCRÉÉEB
Détermine si un nouveau rôle peut créer des bases de données. Le nouveau rôle n'est pas autorisé à créer des bases de données. La valeur par défaut est NOCRATEDB.
CRÉATEROLE | NOCRÉATEROLE
Détermine si un rôle peut créer de nouveaux rôles (c'est-à-dire exécuter CREATE ROLE et CREATE USER). Un rôle doté des autorisations CREATEROLE peut également modifier et supprimer d'autres rôles. La valeur par défaut est NOCREATEROLE.
CONNEXION | NOLOGIN
Seuls les rôles dotés de l'attribut LOGIN peuvent se connecter à la base de données. Un rôle avec l'attribut LOGIN peut être considéré comme un utilisateur. La valeur par défaut est NOLOGIN.3.2 Autorisations des objets de données
Les objets de données incluent des tables et des vues, des champs désignés, des bases de données, des fonctions, des schémas, etc. Les opérations telles que leur création, leur ajout, leur suppression, leur modification et leur interrogation sont des autorisations d'objet de données. Le format de syntaxe d'autorisation est : GRANT [privilèges] ON [objets] TO [utilisateurs], et le format de syntaxe de révocation d'autorisation est REVOKE [privilèges] ON [objets] FROM [utilisateurs].
3.3 Autorisations des utilisateurs
3.3.1 Autorisation des droits de l'utilisateur
Accordez les autorisations d’un rôle ou d’un utilisateur à un ou plusieurs autres rôles ou utilisateurs. Un rôle ou un utilisateur autorisé dispose des autorisations du rôle ou de l'utilisateur autorisé. Lorsque WITH ADMIN OPTION est déclaré, l'utilisateur autorisé peut accorder à nouveau l'autorisation à d'autres rôles ou utilisateurs et révoquer toutes les autorisations héritées du rôle ou de l'utilisateur. Lorsqu'un rôle ou un utilisateur autorisé est modifié ou révoqué, les autorisations de tous les utilisateurs qui héritent du rôle ou des autorisations de l'utilisateur seront modifiées en conséquence. Le format de syntaxe est GRANT role TO user.
3.3.2 Rôles prédéfinis
GaussDB (DWS) fournit un ensemble de rôles prédéfinis, nommés commençant par « gs_role_ ». Ces rôles prédéfinis ont des autorisations fixes. Lorsque certains utilisateurs doivent effectuer des opérations connexes, il leur suffit d'accorder les rôles prédéfinis aux utilisateurs. Les rôles prédéfinis actuels de GaussDB (DWS) sont les suivants :
4.Audit——Audit
L'audit fait référence à l'enregistrement de la connexion et de la sortie de l'utilisateur ainsi que du comportement et des opérations dans la base de données après la connexion, afin que l'administrateur de sécurité de la base de données puisse utiliser ces informations de journal pour connaître l'utilisateur, l'heure et le contenu des opérations illégales.
4.1 Définir les éléments de configuration de l'audit
Pour permettre à la base de données d'auditer une certaine fonction, vous devez activer le commutateur principal d'audit (audit_enabled) et le commutateur d'élément d'audit correspondant (audit_operation_exec). La modification de la valeur de cet élément de configuration pendant le fonctionnement de la base de données prendra effet. immédiatement. Pas besoin de redémarrer la base de données.
Il y a deux points à noter. Premièrement, si vous auditez des opérations ddl, vous devez configurer audit_system_object pour auditer les opérations ddl d'un objet spécifique. Deuxièmement, si vous auditez une transaction, le fait que les opérations au sein de la transaction soient auditées dépend du fait que. des éléments de configuration spécifiques sont configurés. Contrôle des paramètres des éléments d'audit :
4.2 Afficher les journaux d'audit
La commande de requête d'audit est pgxc_query_audit :
sélectionnez * dans pgxc_query_audit (timestamptz startime,timestamptz endtime,audit_log);
starttime et endtime représentent respectivement l'heure de début et l'heure de fin de l'enregistrement d'audit. audit_log représente le nouveau chemin de fichier physique du journal d'audit en cours d'affichage. Lorsque audit_log n'est pas spécifié, les informations du journal d'audit connectées à l'instance actuelle sont affichées par défaut. Les résultats de la requête d'audit sont les suivants :
postgres=# créer la table t1(id int);
ERREUR : la relation "t1" existe déjà
postgres=# select * from pgxc_query_audit('2021-03-21','2021-03-30') order by endtime desc limit 1 ;
-[ ENREGISTREMENT 1 ]---+--------------------------------
heure de début | 2021-03-21 11:49:41.643+08
heure de fin | 2021-03-21 11:49:41.652+08
type_opération | ddl
type_audit | ddl_table
résultat | échoué
nom d'utilisateur | perfadm
base de données | postgres
client_conninfo | gsql@[local]
nom_objet | t1
texte_commande | créer la table t1 (id int);
détail_info | la relation "t1" existe déjà
transaction_xid | 0
id_requête | 1062177
nom_noeud | cn_5001
fil_id | 139916885260032@669613657906735
port_local | 6000
port_distant |
5. Autres technologies de sécurité des entrepôts de données
Affichage de la sécurité des données : désensibilisation des données, contrôle d'accès au niveau des lignes.
Stockage sécurisé des données : cryptage du stockage des données, cryptage transparent.
Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~