მე მქვია დენის როჟკოვი, მე ვარ პროგრამული უზრუნველყოფის დამუშავების ხელმძღვანელი კომპანია Gazinformservice-ში, პროდუქტის გუნდში. ჯატობა. კანონმდებლობა და კორპორატიული რეგულაციები აწესებს გარკვეულ მოთხოვნებს მონაცემთა შენახვის უსაფრთხოებისთვის. არავის სურს, რომ მესამე პირებმა მიიღონ წვდომა კონფიდენციალურ ინფორმაციაზე, ამიტომ ნებისმიერი პროექტისთვის მნიშვნელოვანია შემდეგი საკითხები: იდენტიფიკაცია და ავთენტიფიკაცია, მონაცემებზე წვდომის მართვა, სისტემაში ინფორმაციის მთლიანობის უზრუნველყოფა, უსაფრთხოების მოვლენების აღრიცხვა. ამიტომ, მინდა ვისაუბრო რამდენიმე საინტერესო პუნქტზე DBMS უსაფრთხოებასთან დაკავშირებით.

სტატია მომზადდა გამოსვლის საფუძველზე ქ @DatabasesMeetup, ორგანიზებული Mail.ru Cloud Solutions. თუ კითხვა არ გსურთ, შეგიძლიათ უყუროთ:

სტატია შედგება სამი ნაწილისგან:

• როგორ დავიცვათ კავშირები.
• რა არის მოქმედებების აუდიტი და როგორ ჩაიწეროს ის, რაც ხდება მონაცემთა ბაზის მხარეს და მასთან დაკავშირება.
• როგორ დავიცვათ მონაცემები თავად მონაცემთა ბაზაში და რა ტექნოლოგიები არსებობს ამისათვის.

DBMS უსაფრთხოების სამი კომპონენტი: კავშირის დაცვა, აქტივობის აუდიტი და მონაცემთა დაცვა

თქვენი კავშირების დაცვა

თქვენ შეგიძლიათ დაუკავშირდეთ მონაცემთა ბაზას პირდაპირ ან ირიბად ვებ აპლიკაციების საშუალებით. როგორც წესი, ბიზნეს მომხმარებელი, ანუ პირი, რომელიც მუშაობს DBMS-თან, ირიბად ურთიერთობს მასთან.

სანამ კავშირების დაცვაზე ისაუბრებთ, თქვენ უნდა უპასუხოთ მნიშვნელოვან კითხვებს, რომლებიც განსაზღვრავს, თუ როგორ იქნება სტრუქტურირებული უსაფრთხოების ზომები:

• არის თუ არა ერთი ბიზნეს მომხმარებელი ერთი DBMS მომხმარებლის ეკვივალენტური?
• DBMS მონაცემებზე წვდომა უზრუნველყოფილია მხოლოდ API-ის მეშვეობით, რომელსაც თქვენ აკონტროლებთ, თუ ცხრილებზე წვდომა პირდაპირ;
• არის თუ არა DBMS გამოყოფილი ცალკეულ დაცულ სეგმენტზე, ვინ და როგორ ურთიერთობს მასთან;
• გამოყენებულია თუ არა გაერთიანება/პროქსი და შუალედური ფენები, რამაც შეიძლება შეცვალოს ინფორმაცია იმის შესახებ, თუ როგორ არის შექმნილი კავშირი და ვინ იყენებს მონაცემთა ბაზას.

ახლა ვნახოთ, რა ინსტრუმენტები შეიძლება გამოყენებულ იქნას კავშირების დასაცავად:

1. გამოიყენეთ მონაცემთა ბაზის firewall კლასის გადაწყვეტილებები. დაცვის დამატებითი ფენა, მინიმუმ, გაზრდის იმის გამჭვირვალობას, რაც ხდება DBMS-ში და მაქსიმუმ, თქვენ შეძლებთ უზრუნველყოთ მონაცემთა დამატებითი დაცვა.
2. გამოიყენეთ პაროლის პოლიტიკა. მათი გამოყენება დამოკიდებულია იმაზე, თუ როგორ არის აგებული თქვენი არქიტექტურა. ნებისმიერ შემთხვევაში, ერთი პაროლი ვებ აპლიკაციის კონფიგურაციის ფაილში, რომელიც უკავშირდება DBMS-ს, არ არის საკმარისი დაცვისთვის. არსებობს მთელი რიგი DBMS ხელსაწყოები, რომლებიც საშუალებას გაძლევთ გააკონტროლოთ, რომ მომხმარებელი და პაროლი საჭიროებს განახლებას.

   შეგიძლიათ მეტი წაიკითხოთ მომხმარებლის შეფასების ფუნქციების შესახებ აქ, ასევე შეგიძლიათ გაიგოთ MS SQL დაუცველობის შემფასებლების შესახებ აქ. 

3. გაამდიდრეთ სესიის კონტექსტი საჭირო ინფორმაციით. თუ სესია გაუმჭვირვალეა, არ გესმით, ვინ მუშაობს DBMS-ში მის ფარგლებში, შეგიძლიათ შესრულებული ოპერაციის ფარგლებში დაამატოთ ინფორმაცია ვინ რას აკეთებს და რატომ. ეს ინფორმაცია შეგიძლიათ ნახოთ აუდიტში.
4. SSL-ის კონფიგურაცია თუ არ გაქვთ ქსელის გამიჯვნა DBMS-სა და საბოლოო მომხმარებლებს შორის; ის არ არის ცალკე VLAN-ში. ასეთ შემთხვევებში აუცილებელია არხის დაცვა მომხმარებელსა და თავად DBMS-ს შორის. უსაფრთხოების ინსტრუმენტები ასევე ხელმისაწვდომია ღია კოდით.

როგორ იმოქმედებს ეს DBMS-ის მუშაობაზე?

მოდით გადავხედოთ PostgreSQL-ის მაგალითს, რათა დავინახოთ, როგორ მოქმედებს SSL პროცესორის დატვირთვაზე, ზრდის ვადებს და ამცირებს TPS-ს და მოიხმარს თუ არა ის ძალიან ბევრ რესურსს, თუ მას ჩართავს.

PostgreSQL-ის ჩატვირთვა pgbench-ის გამოყენებით არის მარტივი პროგრამა შესრულების ტესტების გასაშვებად. ის ახორციელებს ბრძანებების ერთ თანმიმდევრობას განმეორებით, შესაძლოა მონაცემთა ბაზის პარალელურ სესიებში და შემდეგ ითვლის საშუალო ტრანზაქციის განაკვეთს.

ტესტი 1 SSL-ის გარეშე და SSL-ის გამოყენებით — კავშირი დამყარებულია თითოეული ტრანზაქციისთვის:

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"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

ტესტი 2 SSL-ის გარეშე და SSL-ის გამოყენებით - ყველა ტრანზაქცია ხორციელდება ერთ კავშირში:

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"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

სხვა პარამეტრები:

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

ტესტის შედეგები:

 
არ არის SSL
SSL

კავშირი იქმნება ყველა ტრანზაქციისთვის

შეყოვნების საშუალო
171.915 ms
187.695 ms

tps კავშირების დამყარების ჩათვლით
58.168112
53.278062

tps კავშირების დამყარების გამოკლებით
64.084546
58.725846

CPU
24%
28%

ყველა ტრანზაქცია ხორციელდება ერთ კავშირში

შეყოვნების საშუალო
6.722 ms
6.342 ms

tps კავშირების დამყარების ჩათვლით
1587.657278
1576.792883

tps კავშირების დამყარების გამოკლებით
1588.380574
1577.694766

CPU
17%
21%

მსუბუქი დატვირთვის დროს, SSL-ის გავლენა შედარებულია გაზომვის შეცდომასთან. თუ გადაცემული მონაცემების რაოდენობა ძალიან დიდია, სიტუაცია შეიძლება განსხვავებული იყოს. თუ ჩვენ დავამყარებთ ერთ კავშირს თითო ტრანზაქციაზე (ეს იშვიათია, ჩვეულებრივ, კავშირი გაზიარებულია მომხმარებლებს შორის), თქვენ გაქვთ კავშირების/გათიშვის დიდი რაოდენობა, ზემოქმედება შეიძლება ოდნავ უფრო დიდი იყოს. ანუ, შეიძლება არსებობდეს შესრულების შემცირების რისკები, თუმცა განსხვავება არც ისე დიდია, რომ არ გამოიყენოთ დაცვა.

გთხოვთ გაითვალისწინოთ, რომ არსებობს ძლიერი განსხვავება, თუ შევადარებთ ოპერაციულ რეჟიმებს: თქვენ მუშაობთ იმავე სესიაზე ან სხვადასხვა სესიაზე. ეს გასაგებია: რესურსები იხარჯება თითოეული კავშირის შესაქმნელად.

გვქონდა შემთხვევა, როცა Zabbix-ს დავუკავშირდით ნდობის რეჟიმში, ანუ md5 არ იყო შემოწმებული, არ იყო საჭირო ავთენტიფიკაცია. შემდეგ მომხმარებელმა სთხოვა md5 ავტორიზაციის რეჟიმის ჩართვა. ამან დიდი დატვირთვა მოახდინა CPU-ზე და შესრულება დაეცა. ჩვენ დავიწყეთ ოპტიმიზაციის გზების ძიება. პრობლემის ერთ-ერთი შესაძლო გამოსავალი არის ქსელის შეზღუდვების დანერგვა, ცალკეული VLAN-ების შექმნა DBMS-სთვის, პარამეტრების დამატება, რათა ცხადი გახდეს, ვინ საიდან აკავშირებს და ამოიღოთ ავტორიზაცია. ასევე შეგიძლიათ ავტორიზაციის პარამეტრების ოპტიმიზაცია, რათა შეამციროთ ხარჯები ავტორიზაციის ჩართვისას. ზოგადად, ავთენტიფიკაციის სხვადასხვა მეთოდის გამოყენება გავლენას ახდენს შესრულებაზე და მოითხოვს ამ ფაქტორების გათვალისწინებას DBMS-ისთვის სერვერების (ტექნიკის) გამოთვლითი სიმძლავრის შემუშავებისას.

დასკვნა: უამრავ გადაწყვეტაში, ავტორიზაციის მცირე ნიუანსებმაც კი შეიძლება დიდად იმოქმედოს პროექტზე და ცუდია, როდესაც ეს ცხადი ხდება მხოლოდ წარმოებაში განხორციელებისას.

სამოქმედო აუდიტი

აუდიტი შეიძლება იყოს არა მხოლოდ DBMS. აუდიტი არის ინფორმაციის მოპოვება იმის შესახებ, თუ რა ხდება სხვადასხვა სეგმენტში. ეს შეიძლება იყოს მონაცემთა ბაზის firewall ან ოპერაციული სისტემა, რომელზედაც აგებულია DBMS.

კომერციული Enterprise დონის DBMS-ებში ყველაფერი კარგადაა აუდიტით, მაგრამ ღია წყაროში - არა ყოველთვის. აი, რა აქვს PostgreSQL:

• ნაგულისხმევი შესვლა - ჩაშენებული შესვლა;
• გაფართოებები: pgaudit - თუ ნაგულისხმევი ჟურნალი არ არის საკმარისი თქვენთვის, შეგიძლიათ გამოიყენოთ ცალკეული პარამეტრები, რომლებიც გადაჭრის გარკვეულ პრობლემებს.

რეპორტაჟის დამატება ვიდეოში:

"ძირითადი განცხადების აღრიცხვა შეიძლება უზრუნველყოფილი იყოს სტანდარტული ხე-ტყის ობიექტით log_statement = ყველა.

ეს მისაღებია მონიტორინგისთვის და სხვა გამოყენებისთვის, მაგრამ არ იძლევა დეტალების დონეს, რომელიც ჩვეულებრივ საჭიროა აუდიტისთვის.

საკმარისი არ არის მონაცემთა ბაზაში შესრულებული ყველა ოპერაციის ჩამონათვალი.

ასევე შესაძლებელი უნდა იყოს კონკრეტული განცხადებების მოძიება, რომლებიც საინტერესოა აუდიტორისთვის.

სტანდარტული ჟურნალი აჩვენებს, თუ რას ითხოვდა მომხმარებელი, ხოლო pgAudit ყურადღებას ამახვილებს დეტალებზე, თუ რა მოხდა, როდესაც მონაცემთა ბაზამ შეასრულა მოთხოვნა.

მაგალითად, აუდიტორს შეიძლება სურდეს გადაამოწმოს, რომ კონკრეტული ცხრილი შეიქმნა დოკუმენტირებული ტექნიკური ფანჯრის ფარგლებში.

ეს შეიძლება ჩანდეს მარტივი დავალება ძირითადი აუდიტისა და grep-ით, მაგრამ რა მოხდება, თუ მოგცემთ მსგავსი (განზრახ დამაბნეველი) მაგალითი:

DO$$
დასაწყისი
შეასრულეთ 'CREATE TABLE იმპორტი' || 'ant_table(id int)';
END$$;

სტანდარტული აღრიცხვა მოგცემთ ამას:

LOG: განცხადება: DO $$
დასაწყისი
შეასრულეთ 'CREATE TABLE იმპორტი' || 'ant_table(id int)';
END$$;

როგორც ჩანს, საინტერესო ცხრილის პოვნა შეიძლება მოითხოვდეს კოდის გარკვეულ ცოდნას იმ შემთხვევებში, როდესაც ცხრილები იქმნება დინამიურად.

ეს არ არის იდეალური, რადგან სასურველია უბრალოდ მოძებნოთ ცხრილის სახელი.

ეს არის სადაც pgAudit გამოდგება.

იგივე შეყვანისთვის, ის გამოიმუშავებს ამ გამომავალს ჟურნალში:

აუდიტი: SESSION,33,1,FUNCTION,DO,,"DO$$-ის გაკეთება
დასაწყისი
შეასრულეთ 'CREATE TABLE იმპორტი' || 'ant_table(id int)';
END$$;"
აუდიტი: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

არა მხოლოდ DO ბლოკი არის დარეგისტრირებული, არამედ CREATE TABLE-ის სრული ტექსტი განცხადების ტიპის, ობიექტის ტიპისა და სრული სახელით, რაც აადვილებს ძიებას.

SELECT და DML განცხადებების აღრიცხვისას, pgAudit შეიძლება იყოს კონფიგურირებული, რათა შეიტანოს ცალკე ჩანაწერი განცხადებაში მითითებული თითოეული ურთიერთობისთვის.

არ არის საჭირო ანალიზი, რომ იპოვოთ ყველა განცხადება, რომელიც ეხება კონკრეტულ ცხრილს (*). "

როგორ იმოქმედებს ეს DBMS-ის მუშაობაზე?

მოდით ჩავატაროთ ტესტები სრული აუდიტით ჩართულით და ვნახოთ რა ბედი ეწევა PostgreSQL მუშაობას. მოდით გავააქტიუროთ მონაცემთა ბაზის მაქსიმალური აღრიცხვა ყველა პარამეტრისთვის.

ჩვენ თითქმის არაფერს ვცვლით კონფიგურაციის ფაილში, მთავარია ჩართოთ debug5 რეჟიმი მაქსიმალური ინფორმაციის მისაღებად.

postgresql.conf

log_destination = 'stderr'
logging_collector = ჩართულია
log_truncate_on_rotation = ჩართულია
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = გამართვა5
log_min_error_statement = გამართვა5
log_min_duration_statement = 0
debug_print_parse = ჩართულია
debug_print_rewritten = ჩართულია
debug_print_plan = ჩართულია
debug_pretty_print = ჩართულია
log_checkpoints = ჩართულია
log_connections = ჩართულია
log_disconnections = ჩართულია
ჟურნალის_ხანგრძლივობა = ჩართულია
log_hostname = ჩართულია
log_lock_wait = ჩართულია
log_replication_commands = ჩართულია
log_temp_files = 0
log_timezone = 'ევროპა/მოსკოვი'

PostgreSQL DBMS-ზე 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD პარამეტრებით, ჩვენ ვატარებთ ჩატვირთვის სამ ტესტს ბრძანებების გამოყენებით:

$ 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

Ტესტის პასუხები:

არ არის ხე
ჭრით

მონაცემთა ბაზის შევსების მთლიანი დრო
წმ
წმ

RAM
24%
40%

CPU
72%
91%

ტესტი 1 (50 კავშირი)

ტრანზაქციების რაოდენობა 10 წუთში
74169
32445

გარიგებები/წმ
123
54

საშუალო შეყოვნება
405 ms
925 ms

ტესტი 2 (150 კავშირი 100 შესაძლო)

ტრანზაქციების რაოდენობა 10 წუთში
81727
31429

გარიგებები/წმ
136
52

საშუალო შეყოვნება
550 ms
1432 ms

ზომების შესახებ

DB ზომა
2251 MB
2262 MB

მონაცემთა ბაზის ჟურნალის ზომა
0 MB
4587 MB

დედააზრი: სრული აუდიტი არ არის ძალიან კარგი. აუდიტის მონაცემები იქნება ისეთივე დიდი, როგორც თავად მონაცემთა ბაზაში, ან უფრო მეტიც. ჭრის რაოდენობა, რომელიც წარმოიქმნება DBMS-თან მუშაობისას, წარმოების საერთო პრობლემაა.

მოდით შევხედოთ სხვა პარამეტრებს:

• სიჩქარე დიდად არ იცვლება: ჩაწერის გარეშე - 43,74 წამი, ლოგინგით - 53,23 წამი.
• RAM-ისა და CPU-ის მუშაობა დაზარალდება, რადგან საჭიროა აუდიტის ფაილის გენერირება. ეს ასევე შესამჩნევია პროდუქტიულობაში.

როგორც კავშირების რაოდენობა იზრდება, ბუნებრივია, შესრულება ოდნავ გაუარესდება.

აუდიტის მქონე კორპორაციებში კიდევ უფრო რთულია:

• არის ბევრი მონაცემი;
• აუდიტი საჭიროა არა მარტო syslog-ის მეშვეობით SIEM-ში, არამედ ფაილებშიც: თუ syslog-ს რამე დაემართება, უნდა იყოს მონაცემთა ბაზასთან ახლოს ფაილი, რომელშიც მონაცემები ინახება;
• აუდიტისთვის საჭიროა ცალკე თარო, რათა არ დაიკარგოს I/O დისკები, რადგან დიდ ადგილს იკავებს;
• ეს ხდება, რომ ინფორმაციის უსაფრთხოების თანამშრომლებს ყველგან სჭირდებათ GOST სტანდარტები, მათ სახელმწიფო იდენტიფიკაცია სჭირდებათ.

მონაცემებზე წვდომის შეზღუდვა

მოდით შევხედოთ ტექნოლოგიებს, რომლებიც გამოიყენება მონაცემთა დასაცავად და მათზე წვდომისთვის კომერციულ DBMS-ებში და ღია წყაროებში.

რა შეგიძლიათ გამოიყენოთ ზოგადად:

1. პროცედურების და ფუნქციების დაშიფვრა და დაბინდვა (Wrapping) - ეს არის ცალკეული ხელსაწყოები და უტილიტები, რომლებიც წასაკითხ კოდს წაუკითხავად ხდის. მართალია, მაშინ ის არც შეიძლება შეიცვალოს და არც უკან დაბრუნება. ეს მიდგომა ზოგჯერ საჭიროა მინიმუმ DBMS-ის მხრივ - ლიცენზიის შეზღუდვის ლოგიკა ან ავტორიზაციის ლოგიკა დაშიფრულია ზუსტად პროცედურისა და ფუნქციის დონეზე.
2. მონაცემთა ხილვადობის შეზღუდვა მწკრივებით (RLS) არის, როდესაც სხვადასხვა მომხმარებელი ხედავს ერთ ცხრილს, მაგრამ მასში მწკრივების განსხვავებულ კომპოზიციას, ანუ რაღაცის ჩვენება არ შეიძლება ვინმესთვის რიგის დონეზე.
3. ნაჩვენები მონაცემების რედაქტირება (Masking) არის, როდესაც მომხმარებლები ცხრილის ერთ სვეტში ხედავენ ან მონაცემებს ან მხოლოდ ვარსკვლავებს, ანუ ზოგიერთი მომხმარებლისთვის ინფორმაცია დაიხურება. ტექნოლოგია განსაზღვრავს, თუ რომელ მომხმარებელს ეჩვენება რა, მათი წვდომის დონის მიხედვით.
4. უსაფრთხოება DBA/აპლიკაცია DBA/DBA წვდომის კონტროლი უფრო მეტად ეხება DBMS-ზე წვდომის შეზღუდვას, ანუ ინფორმაციული უსაფრთხოების თანამშრომლებს შეიძლება გამოეყოთ მონაცემთა ბაზის ადმინისტრატორები და აპლიკაციის ადმინისტრატორები. ღია წყაროში ასეთი ტექნოლოგიები ცოტაა, მაგრამ კომერციულ DBMS-ებში ბევრია. ისინი საჭიროა, როდესაც ბევრი მომხმარებელია, რომლებსაც თავად სერვერებზე აქვთ წვდომა.
5. ფაილებზე წვდომის შეზღუდვა ფაილური სისტემის დონეზე. თქვენ შეგიძლიათ მიანიჭოთ უფლებები და წვდომის პრივილეგიები დირექტორიებზე ისე, რომ თითოეულ ადმინისტრატორს ჰქონდეს წვდომა მხოლოდ საჭირო მონაცემებზე.
6. სავალდებულო წვდომა და მეხსიერების გასუფთავება - ეს ტექნოლოგიები იშვიათად გამოიყენება.
7. ბოლოდან ბოლომდე დაშიფვრა პირდაპირ DBMS-დან არის კლიენტის მხარის დაშიფვრა გასაღების მენეჯმენტით სერვერის მხარეს.
8. მონაცემთა დაშიფვრა. მაგალითად, სვეტოვანი დაშიფვრა არის ის, როდესაც იყენებთ მექანიზმს, რომელიც შიფრავს მონაცემთა ბაზის ერთ სვეტს.

როგორ მოქმედებს ეს DBMS-ის მუშაობაზე?

მოდით შევხედოთ სვეტური დაშიფვრის მაგალითს PostgreSQL-ში. არსებობს pgcrypto მოდული, რომელიც საშუალებას გაძლევთ შეინახოთ შერჩეული ველები დაშიფრული ფორმით. ეს სასარგებლოა, როდესაც მხოლოდ ზოგიერთი მონაცემია ღირებული. დაშიფრული ველების წასაკითხად კლიენტი გადასცემს გაშიფვრის გასაღებს, სერვერი შიფრავს მონაცემებს და უბრუნებს კლიენტს. გასაღების გარეშე ვერავინ ვერაფერს გააკეთებს თქვენს მონაცემებთან.

მოდით შევამოწმოთ pgcrypto-ით. მოდით შევქმნათ ცხრილი დაშიფრული მონაცემებით და რეგულარული მონაცემებით. ქვემოთ მოცემულია ცხრილების შექმნის ბრძანებები, პირველ რიგში არის სასარგებლო ბრძანება - თავად გაფართოების შექმნა DBMS რეგისტრაციით:

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'));

შემდეგი, შევეცადოთ შევქმნათ მონაცემთა ნიმუში თითოეული ცხრილიდან და გადავხედოთ შესრულების ვადებს.

შერჩევა ცხრილიდან დაშიფვრის ფუნქციის გარეშე:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

წამზომი ჩართულია.

  id | text1 | ტექსტი 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 სტრიქონი)

დრო: 1,386 ms

შერჩევა ცხრილიდან დაშიფვრის ფუნქციით:

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

წამზომი ჩართულია.

  id | გაშიფვრა | გაშიფვრა
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 სტრიქონი)

დრო: 50,203 ms

ტესტის შედეგები:

 
არანაირი დაშიფვრა
Pgcrypto (გაშიფვრა)

აიღეთ 1000 მწკრივი
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

დაშიფვრა დიდ გავლენას ახდენს შესრულებაზე. ჩანს, რომ დრო გაიზარდა, რადგან დაშიფრული მონაცემების გაშიფვრის ოპერაციები (და გაშიფვრა, როგორც წესი, ჯერ კიდევ თქვენს ლოგიკაშია) მოითხოვს მნიშვნელოვან რესურსებს. ანუ, გარკვეული მონაცემების შემცველი ყველა სვეტის დაშიფვრის იდეა სავსეა შესრულების შემცირებით.

თუმცა, დაშიფვრა არ არის ვერცხლის ტყვია, რომელიც წყვეტს ყველა პრობლემას. გაშიფრული მონაცემები და გაშიფვრის გასაღები მონაცემთა გაშიფვრისა და გადაცემის პროცესში განთავსებულია სერვერზე. აქედან გამომდინარე, გასაღებები შეიძლება ჩაითვალოს ვინმეს, რომელსაც აქვს სრული წვდომა მონაცემთა ბაზის სერვერზე, როგორიცაა სისტემის ადმინისტრატორი.

როდესაც არის ერთი გასაღები მთელი სვეტისთვის ყველა მომხმარებლისთვის (თუნდაც არა ყველასთვის, მაგრამ შეზღუდული ნაკრების კლიენტებისთვის), ეს ყოველთვის არ არის კარგი და სწორი. სწორედ ამიტომ მათ დაიწყეს ბოლომდე დაშიფვრის გაკეთება, DBMS-ში დაიწყეს კლიენტისა და სერვერის მხრიდან მონაცემთა დაშიფვრის ვარიანტების განხილვა და გამოჩნდა იგივე გასაღების სათავსოები - ცალკეული პროდუქტები, რომლებიც უზრუნველყოფენ გასაღების მართვას DBMS-ზე. მხარე.

ასეთი დაშიფვრის მაგალითი MongoDB-ში

უსაფრთხოების მახასიათებლები კომერციულ და ღია კოდის DBMS-ში

ფუნქციები
გაცნობის
პაროლის პოლიტიკა
აუდიტი
პროცედურებისა და ფუნქციების წყაროს კოდის დაცვა
RLS
შიფრაცია

Oracle
კომერციული
+
+
+
+
+

MsSql
კომერციული
+
+
+
+
+

ჯატობა
კომერციული
+
+
+
+
გაგრძელება

PostgreSQL
უფასო
გაგრძელება
გაგრძელება
-
+
გაგრძელება

მონგოდბ
უფასო
-
+
-
-
ხელმისაწვდომია მხოლოდ MongoDB Enterprise-ში

ცხრილი შორს არის სრულყოფილი, მაგრამ სიტუაცია ასეთია: კომერციულ პროდუქტებში უსაფრთხოების პრობლემები დიდი ხანია მოგვარებულია, ღია წყაროში, როგორც წესი, უსაფრთხოებისთვის გამოიყენება რაიმე სახის დანამატი, ბევრი ფუნქცია აკლია. , ხანდახან რაღაც უნდა დაამატოთ. მაგალითად, პაროლის პოლიტიკა - PostgreSQL-ს აქვს მრავალი განსხვავებული გაფართოება (1, 2, 3, 4, 5), რომლებიც ახორციელებენ პაროლის პოლიტიკას, მაგრამ, ჩემი აზრით, არცერთი მათგანი არ მოიცავს შიდა კორპორატიული სეგმენტის ყველა საჭიროებას.

რა უნდა გააკეთოთ, თუ არსად არ გაქვთ ის, რაც გჭირდებათ? მაგალითად, გსურთ გამოიყენოთ კონკრეტული DBMS, რომელსაც არ გააჩნია ის ფუნქციები, რასაც მომხმარებელი მოითხოვს.

შემდეგ შეგიძლიათ გამოიყენოთ მესამე მხარის გადაწყვეტილებები, რომლებიც მუშაობენ სხვადასხვა DBMS-ებთან, მაგალითად, Crypto DB ან Garda DB. თუ ვსაუბრობთ შიდა სეგმენტის გადაწყვეტილებებზე, მაშინ მათ უკეთ იციან GOST-ების შესახებ, ვიდრე ღია წყაროში.

მეორე ვარიანტია ჩაწეროთ ის, რაც გჭირდებათ, განახორციელოთ მონაცემების წვდომა და დაშიფვრა აპლიკაციაში პროცედურის დონეზე. მართალია, GOST-ით უფრო რთული იქნება. მაგრამ ზოგადად, თქვენ შეგიძლიათ დამალოთ მონაცემები საჭიროებისამებრ, ჩადოთ იგი DBMS-ში, შემდეგ მოიძიოთ და გაშიფროთ საჭიროებისამებრ, პირდაპირ აპლიკაციის დონეზე. ამავდროულად, დაუყოვნებლივ იფიქრეთ იმაზე, თუ როგორ დაიცავთ ამ ალგორითმებს აპლიკაციაში. ჩვენი აზრით, ეს უნდა გაკეთდეს DBMS დონეზე, რადგან უფრო სწრაფად იმუშავებს.

ეს ანგარიში პირველად იყო წარმოდგენილი @Databases Meetup Mail.ru Cloud Solutions-ის მიერ. შეხედე ვიდეო სხვა სპექტაკლები და გამოიწერეთ ღონისძიების ანონსები Telegram-ზე Kubernetes-ის გარშემო Mail.ru Group-ზე.

კიდევ რა წავიკითხოთ თემაზე:

1. მეტი ვიდრე Ceph: MCS ღრუბლოვანი ბლოკის საცავი.
2. როგორ ავირჩიოთ მონაცემთა ბაზა პროექტისთვის, რათა აღარ მოგიწიოთ არჩევანის გაკეთება.

წყარო: www.habr.com