Je m'appelle Denis Rozhkov, je suis responsable du développement logiciel chez Gazinformservice, dans l' équipe produit Jatoba . La législation et la réglementation des entreprises imposent certaines exigences en matière de sécurité du stockage des données. Personne ne veut que des tiers aient accès à des informations confidentielles.Par conséquent, les questions suivantes sont importantes pour tout projet: identification et authentification, gestion de l'accès aux données, garantie de l'intégrité des informations dans le système, enregistrement des événements de sécurité. Par conséquent, je veux parler de quelques points intéressants concernant la sécurité du SGBD.Cet article a été écrit par @Databases Meetup, hébergé par Mail.ru Cloud Solutions . Si vous ne voulez pas lire, vous pouvez voir:L'article comportera trois parties:- Comment protéger les connexions.
- Qu'est-ce qu'un audit des actions et comment enregistrer ce qui se passe sur la partie de la base de données et s'y connecter.
- Comment protéger les données dans la base de données elle-même et quelles technologies existent pour cela.
Les trois composants de la sécurité du SGBD: protection des connexions, audit d'activité et protection des donnéesProtection de connexion
Vous pouvez vous connecter à la base de données directement ou indirectement via des applications Web. En règle générale, l'utilisateur du côté de l'entreprise, c'est-à -dire la personne qui travaille avec le SGBD, n'interagit pas directement avec lui.Avant de parler de la sécurisation des connexions, vous devez répondre à des questions importantes qui dépendent de la façon dont les mesures de sécurité seront construites:- si un utilisateur professionnel est équivalent à un utilisateur SGBD;
- L'accès aux données du SGBD est-il fourni uniquement via l'API que vous contrôlez, ou y a-t-il un accès direct aux tables;
- si le SGBD est alloué dans un segment protégé distinct, qui interagit avec lui et comment;
- si le pooling / proxy et le middleware sont utilisés, ce qui peut modifier les informations sur la façon dont la connexion est établie et qui utilise la base de données.
Voyons maintenant quels outils peuvent être utilisés pour protéger les connexions:- Utilisez des solutions de classe de pare-feu de base de données. Une couche de protection supplémentaire, au moins, augmentera la transparence de ce qui se passe dans le SGBD, au maximum - vous pouvez fournir une protection supplémentaire des données.
- . , . — -, , . , , .
, MS SQL Vulnerability Assessmen . - . , , , , , . .
- Configurez SSL, si vous n'avez pas de séparation réseau du SGBD des utilisateurs finaux, il ne se trouve pas dans un VLAN distinct. Dans de tels cas, il est nécessaire de protéger le canal entre le consommateur et le SGBD lui-même. Les outils de protection sont parmi l'open source.
Comment cela affectera-t-il les performances du SGBD?
Regardons un exemple PostgreSQL, comment SSL affecte la charge CPU, augmentant les délais et diminuant TPS, si trop de ressources disparaissent si vous l'activez.Nous chargeons PostgreSQL en utilisant pgbench - c'est un programme simple pour exécuter des tests de performances. Il exécute à plusieurs reprises une séquence de commandes, éventuellement dans des sessions de base de données parallèles, puis calcule la vitesse de transaction moyenne.Test 1 sans SSL et en utilisant SSL - une connexion est établie avec chaque transaction:pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"
contrepgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"
Test 2 sans SSL et en utilisant SSL - toutes les transactions sont effectuées en une seule connexion:pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"
contrepgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"
Autres paramètres :scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000
Résultats des tests :Aux charges légères, l'effet de SSL est comparable à l'erreur de mesure. Si la quantité de données transférées est très importante, la situation peut être différente. Si nous établissons une connexion pour chaque transaction (c'est rare, généralement la connexion est partagée entre les utilisateurs), vous avez un grand nombre de connexions / déconnexions, l'effet peut être un peu plus. Autrement dit, il peut y avoir des risques de dégradation des performances, cependant, la différence n'est pas assez grande pour ne pas utiliser la protection.Veuillez noter qu'il existe une forte différence lors de la comparaison des modes de fonctionnement: au sein d'une même session, vous travaillez ou différent. Cela est compréhensible: des ressources sont consacrées à la création de chaque connexion.Nous avons eu un cas lorsque nous avons connecté Zabbix en mode de confiance, c'est-à -dire que nous n'avons pas vérifié md5, il n'y avait pas besoin d'authentification. Le client a ensuite demandé d'activer le mode d'authentification md5. Cela a donné une grande charge sur le CPU, les performances ont baissé. Ils ont commencé à chercher des moyens d'optimiser. L'une des solutions possibles au problème consiste à implémenter une restriction de réseau, à créer des VLAN distincts pour le SGBD, à ajouter des paramètres de sorte qu'il soit clair qui se connecte d'où et à supprimer l'authentification. Vous pouvez également optimiser les paramètres d'authentification pour réduire les coûts d'activation de l'authentification, mais en général, en utilisant diverses méthodes l'authentification affecte les performances et nécessite que ces facteurs soient pris en compte lors de la conception de la puissance de calcul des serveurs (matériel) pour un SGBD.Conclusion: dans un certain nombre de solutions, même de petites nuances d'authentification peuvent affecter considérablement le projet et elles sont mauvaises lorsqu'elles deviennent claires uniquement lorsqu'elles sont implémentées dans un produit.Audit des actions
Un audit peut être non seulement un SGBD. L'audit est la réception d'informations sur ce qui se passe sur différents segments. Il peut s'agir à la fois d'un pare-feu de base de données et du système d'exploitation sur lequel le SGBD est construit.Dans les SGBD d'entreprise avec audit, tout va bien, en open source - pas toujours. Voici ce que PostgreSQL a:- journal par défaut - journalisation intégrée;
- extensions: pgaudit - si vous n'avez pas suffisamment de journalisation par défaut, vous pouvez utiliser des paramètres distincts qui résolvent certains des problèmes.
Ajout au rapport dans la vidéo:«L'enregistrement de base des opérateurs peut être fourni avec une fonction d'enregistrement standard avec log_statement = all.Ceci est acceptable pour la surveillance et d'autres utilisations, mais ne fournit pas le niveau de détail généralement nécessaire pour un audit.Il ne suffit pas d'avoir une liste de toutes les opérations effectuées avec la base de données.Il devrait également être possible de trouver des déclarations spécifiques qui intéressent l'auditeur.L'outil de journalisation standard montre ce que l'utilisateur a demandé, tandis que pgAudit se concentre sur les détails de ce qui s'est passé lorsque la base de données a fait la demande.Par exemple, l'auditeur peut vouloir s'assurer qu'une table spécifique a été créée dans une fenêtre de maintenance documentée.Cela peut sembler une tâche simple pour l'audit de base et grep, mais que se passe-t-il si vous rencontrez quelque chose comme ça (intentionnellement déroutant) exemple:DO $$BEGINEXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';END $$;La journalisation standard vous donnera ceci:LOG: instruction: DO $$BEGINEXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';END $$;Il semble que la recherche d'une table d'intérêt puisse nécessiter une certaine connaissance du code dans les cas où les tables sont créées dynamiquement.Ce n'est pas idéal, car il serait préférable de simplement rechercher par nom de table.C'est là que pgAudit sera utile.Pour la même entrée, il affichera cette sortie dans le journal:AUDIT: SESSION, 33.1, FUNCTION, DO ,,, “DO $$BEGINEXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';END $$; "AUDIT: SESSION, 33,2, DDL, CREATE TABLE, TABLE, public.important_table, CREATE TABLE important_table (id INT)Non seulement le bloc DO est enregistré, mais également le texte intégral CREATE TABLE avec le type d'opérateur, le type d'objet et nom complet, ce qui facilite la recherche.dans la conduite du magazine des opérateurs SELECT et DML, pgAudit peut être configuré pour enregistrer une entrée distincte pour chaque relation, qui est référencée dans l'instruction.Il n'est pas nécessaire d'analyser pour trouver toutes les instructions qui se rapportent à une table spécifique ( * ) " .Comment cela affectera-t-il les performances du SGBD?
Exécutons les tests avec un audit complet activé et voyons ce qui se passe avec les performances de PostgreSQL. Nous permettons la journalisation maximale de la base de données à tous égards.Nous ne changeons presque rien dans le fichier de configuration, de l'important - activez le mode debug5 pour obtenir le maximum d'informations.postgresql.confSur le SGBD PostgreSQL avec les paramètres 1 CPU, 2,8 GHz, 2 Go de RAM, 40 Go de disque dur, nous effectuons trois tests de charge à l'aide des commandes suivantes:$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark
Résultats de test:Conclusion: un audit complet n'est pas très bon. Les données de l'audit se révéleront en volume, comme les données de la base de données elle-même, voire plus. La quantité de journalisation générée lors de l'utilisation du SGBD est un problème courant sur le produit.Nous regardons d'autres paramètres:- La vitesse ne change pas beaucoup: sans enregistrement - 43,74 secondes, avec enregistrement - 53,23 s.
- Les performances sur la RAM et le CPU diminueront, car vous devez créer un fichier avec l'audit. Il est également perceptible sur le productif.
Avec une augmentation du nombre de connexions, bien sûr, les performances vont légèrement se détériorer.Dans les entreprises avec audit, c'est encore plus difficile:- il y a beaucoup de données;
- L'audit est nécessaire non seulement via syslog dans SIEM, mais aussi dans les fichiers: tout à coup, quelque chose se passe avec syslog, le fichier dans lequel les données sont enregistrées doit être proche de la base de données;
- l'audit nécessite une étagère séparée, afin de ne pas couler sur les disques d'E / S, car il prend beaucoup de place;
- il arrive que les employés du SI aient besoin de GOST partout, ils ont besoin d'une identification des invités.
Restriction d'accès aux données
Examinons les technologies utilisées pour protéger les données et y accéder dans les SGBD commerciaux et open source.Ce qui peut être utilisé dans son ensemble:- Cryptage et obscurcissement des procédures et des fonctions (Wrapping) - c'est-à -dire des outils et des utilitaires séparés qui rendent le code illisible du code lisible. Certes, il ne peut être ni modifié ni refactorisé. Une telle approche est parfois requise au moins du côté du SGBD - la logique des restrictions de licence ou la logique d'autorisation est chiffrée précisément au niveau de la procédure et de la fonction.
- (RLS) — , , - - .
- (Masking) — , , - . , .
- Security DBA/Application DBA/DBA — , , , database- application-. open source , . , .
- . , , .
- — .
- End-to-end encryption — client-side .
- . , — , .
?
Regardons un exemple de chiffrement de colonne dans PostgreSQL. Il existe un module pgcrypto, il vous permet de stocker les champs sélectionnés sous forme cryptée. Ceci est utile lorsque seules certaines données sont précieuses. Pour lire les champs chiffrés, le client transmet la clé de déchiffrement, le serveur déchiffre les données et les transmet au client. Sans clé avec vos données, personne ne peut rien faire.Essayons avec pgcrypto . Créez une table avec des données chiffrées et des données régulières. Ci-dessous se trouve la commande pour créer des tables, dans la toute première ligne une commande utile crée l'extension elle-même avec l'enregistrement du SGBD:CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));
Ensuite, nous essaierons de faire un échantillonnage de données à partir de chaque table et de regarder les délais d'exécution.Sélection dans le tableau sans fonction de cryptage :psql -c "\timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt
Le chronomètre est activé. id | text1 | text2------ + ------- + -------1 | 1 | 12 | 2 | 23 | 3 | 3...997 | 997 | 997998 | 998 | 998,999| 999 | 9991000 | 1000 | 1000(1000 lignes)Temps: 1,386 ms.Échantillonnage à partir d'une table avec fonction de cryptage:psql -c "\timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt
Le chronomètre est activé. id | décrypter | décrypter----- + -------------- + ------------1 | \ x31 | \ x312 | \ x32 | \ x323 | \ x33 | \ x33...999 | \ x393939 | \ x3939391000 | \ x31303030 | \ x31303030(1000 lignes)Durée: 50,203 msRésultats du test :Le chiffrement a un impact important sur les performances. On peut voir que le timing a augmenté, car les opérations de décryptage des données cryptées (et le décryptage est généralement toujours encapsulé dans votre logique) nécessitent des ressources importantes. Autrement dit, l'idée de chiffrer toutes les colonnes contenant une sorte de données est lourde de performances réduites.Cependant, le cryptage n'est pas une solution miracle qui résout tous les problèmes. Les données déchiffrées et la clé de déchiffrement en cours de déchiffrement et de transfert de données se trouvent sur le serveur. Par conséquent, les clés peuvent être interceptées par ceux qui ont un accès complet au serveur de base de données, par exemple, un administrateur système.Lorsque la colonne entière pour tous les utilisateurs a une clé (même si ce n'est pas pour tous, mais pour un ensemble limité de clients), ce n'est pas toujours bon et juste. C'est pourquoi ils ont commencé à effectuer un chiffrement de bout en bout, le SGBD a commencé à envisager des options pour crypter les données du client et du serveur, les mêmes référentiels de coffre de clés sont apparus - des produits distincts qui assurent la gestion des clés du côté du SGBD.Un exemple d'un tel chiffrement dans MongoDBFonctions de sécurité dans les SGBD commerciaux et open source
Le tableau est loin d'être complet, mais la situation est la suivante: dans les produits commerciaux, les problèmes de sécurité sont résolus depuis longtemps, en open source, en règle générale, certains modules complémentaires sont utilisés pour la sécurité, de nombreuses fonctions ne suffisent pas, parfois vous devez ajouter quelque chose. Par exemple, les politiques de mot de passe - dans PostgreSQL, il existe de nombreuses extensions différentes ( 1 , 2 , 3 , 4 , 5 ) qui mettent en œuvre des politiques de mot de passe, mais, à mon avis, aucune ne couvre tous les besoins du segment national des entreprises.Que faire si nul n'est nécessaire ? Par exemple, je veux utiliser un SGBD spécifique, dans lequel il n'y a aucune fonction dont le client a besoin.Vous pouvez ensuite utiliser des solutions tierces qui fonctionnent avec différents SGBD, par exemple, "Crypto DB" ou "Garda DB". Si nous parlons de solutions du segment domestique, ils connaissent mieux les GOST que dans l'open source.La deuxième option consiste à écrire vous-même ce dont vous avez besoin, à implémenter l'accès aux données et le chiffrement dans l'application au niveau de la procédure. Certes, avec GOST, ce sera plus difficile. Mais en général - vous pouvez masquer les données selon vos besoins, les placer dans le SGBD, puis les récupérer et les décrypter comme il se doit, directement au niveau de l'application. En même temps, réfléchissez immédiatement à la façon dont vous protégerez ces algorithmes lors de l'application. À notre avis, cela devrait être fait au niveau du SGBD, car cela fonctionnera plus rapidement.Cette conférence a été faite pour la première fois au @Databases Meetup par Mail.ru Cloud Solutions. Regardez la videod' autres apparitions et inscrivez - vous pour les annonces d'événements Télégramme autour Kubernetes à Mail.ru Group .Quoi d'autre à lire sur le sujet :- Plus que Ceph: MCS Block Cloud Storage .
- Comment choisir une base de données pour le projet, afin de ne pas sélectionner à nouveau .