Ես Դենիս Ռոժկովն եմ, ես Գազինֆորմսերվիս ընկերության ծրագրային ապահովման ղեկավարն եմ, արտադրանքի թիմում: Ջատոբա. Օրենսդրությունը և կորպորատիվ կանոնակարգերը որոշակի պահանջներ են ներկայացնում տվյալների պահպանման անվտանգության համար: Ոչ ոք չի ցանկանում, որ երրորդ կողմերը մուտք ունենան գաղտնի տեղեկատվություն, ուստի ցանկացած նախագծի համար կարևոր են հետևյալ խնդիրները՝ նույնականացում և վավերացում, տվյալների հասանելիության կառավարում, համակարգում տեղեկատվության ամբողջականության ապահովում, անվտանգության իրադարձությունների գրանցում: Հետևաբար, ես ուզում եմ խոսել մի քանի հետաքրքիր կետերի մասին, որոնք վերաբերում են 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 վավերացման ռեժիմը: Սա մեծ բեռ դրեց պրոցեսորի վրա, և կատարողականությունը իջավ: Մենք սկսեցինք օպտիմալացման ուղիներ փնտրել: Խնդրի հնարավոր լուծումներից մեկը ցանցի սահմանափակումների ներդրումն է, DBMS-ի համար առանձին VLAN-ներ ստեղծելը, կարգավորումներ ավելացնելը, որպեսզի պարզ լինի, թե ով որտեղից է միանում և հեռացնել նույնականացումը: Կարող եք նաև օպտիմիզացնել նույնականացման կարգավորումները՝ նույնականացումը միացնելիս ծախսերը նվազեցնելու համար: , բայց ընդհանուր առմամբ նույնականացման տարբեր մեթոդների օգտագործումը ազդում է աշխատանքի վրա և պահանջում է հաշվի առնել այս գործոնները DBMS-ի համար սերվերների (ապարատային) հաշվողական հզորությունը նախագծելիս:

Եզրակացություն. մի շարք լուծումներում վավերացման նույնիսկ փոքր նրբերանգները կարող են մեծապես ազդել նախագծի վրա, և վատ է, երբ դա պարզ է դառնում միայն արտադրության մեջ ներդրման դեպքում:

Գործողությունների աուդիտ

Աուդիտը կարող է լինել ոչ միայն DBMS: Աուդիտը տարբեր հատվածներում տեղի ունեցող իրադարձությունների վերաբերյալ տեղեկատվության ստացումն է: Սա կարող է լինել կամ տվյալների բազայի firewall կամ օպերացիոն համակարգը, որի վրա կառուցված է DBMS-ը:

Առևտրային ձեռնարկությունների մակարդակի DBMS-ներում ամեն ինչ կարգին է աուդիտի դեպքում, բայց բաց կոդով` ոչ միշտ: Ահա թե ինչ ունի PostgreSQL-ը.

• լռելյայն մուտք - ներկառուցված մուտք;
• ընդլայնումներ՝ pgaudit - եթե լռելյայն գրանցումը բավարար չէ ձեզ համար, կարող եք օգտագործել առանձին կարգավորումներ, որոնք լուծում են որոշ խնդիրներ:

Զեկույցի հավելումը տեսանյութում.

«Հիմնական քաղվածքի գրանցումը կարող է տրամադրվել ստանդարտ գրանցման հաստատության կողմից՝ log_statement = all:

Սա ընդունելի է մոնիտորինգի և այլ կիրառումների համար, բայց չի ապահովում աուդիտի համար սովորաբար պահանջվող մանրամասների մակարդակը:

Բավական չէ տվյալների բազայում կատարված բոլոր գործողությունների ցանկը:

Պետք է նաև հնարավոր լինի գտնել կոնկրետ հայտարարություններ, որոնք հետաքրքրում են աուդիտորին:

Ստանդարտ գրանցումը ցույց է տալիս, թե ինչ է խնդրել օգտվողը, մինչդեռ pgAudit-ը կենտրոնանում է մանրամասների վրա, թե ինչ է տեղի ունեցել, երբ տվյալների բազան կատարեց հարցումը:

Օրինակ, աուդիտորը կարող է ցանկանալ ստուգել, ​​որ որոշակի աղյուսակ ստեղծվել է փաստաթղթավորված սպասարկման պատուհանում:

Սա կարող է թվալ պարզ առաջադրանք՝ հիմնական աուդիտի և grep-ի հետ կապված, բայց ի՞նչ, եթե ձեզ ներկայացնեն նման բան (դիտավորյալ շփոթեցնող) օրինակ.

DO$$
BEGIN
ԿԱՏԱՐԵԼ «ՍՏԵՂԾԵԼ ՍԵՂԱՆԻ ներմուծում» || 'ant_table (id int)';
ՎԵՐՋ $$;

Ստանդարտ անտառահատումը ձեզ կտա հետևյալը.

ՄԱՏԵՆՔ. հայտարարություն. ԱՆԵԼ $$
BEGIN
ԿԱՏԱՐԵԼ «ՍՏԵՂԾԵԼ ՍԵՂԱՆԻ ներմուծում» || 'ant_table (id int)';
ՎԵՐՋ $$;

Թվում է, որ հետաքրքրող աղյուսակը գտնելը կարող է պահանջել որոշակի կոդերի իմացություն այն դեպքերում, երբ աղյուսակները ստեղծվում են դինամիկ կերպով:

Սա իդեալական չէ, քանի որ նախընտրելի կլինի պարզապես որոնել ըստ աղյուսակի անունով:

Այստեղ է, որ pgAudit-ը հարմար է:

Նույն մուտքագրման համար այն կստեղծի այս ելքը գրանցամատյանում.

ԱՈՒԴԻՏ. ՆԻՍՏ,33,1,ՖՈՒՆԿՑԻԱ,DO,,«ԿԱՏԱՐԵԼ $$
BEGIN
ԿԱՏԱՐԵԼ «ՍՏԵՂԾԵԼ ՍԵՂԱՆԻ ներմուծում» || 'ant_table (id int)';
ՎԵՐՋ $$;"
ԱՈՒԴԻՏ՝ SESSION,33,2,DDL,ՍՏԵՂԾԵՔ ՍԵՂԱՆԱԿ,ՍԵՂԱՆԱԿ,public.important_table,CREATE TABLE important_sable (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_duration = միացված է
log_hostname = միացված է
log_lock_wait = միացված է
log_replication_commands = միացված է
log_temp_files = 0
log_timezone = 'Եվրոպա/Մոսկվա'

PostgreSQL DBMS-ի վրա 1 պրոցեսոր, 2,8 ԳՀց, 2 ԳԲ RAM, 40 ԳԲ 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

Փորձարկման արդյունքներ.

Ոչ ծառահատումներ
Փայտահատումներով

Տվյալների բազայի լրացման ընդհանուր ժամանակը
43,74 վայրկյան
53,23 վայրկյան

Ռամը
24%
40%

CPU
72%
91%

Թեստ 1 (50 միացում)

Գործարքների քանակը 10 րոպեում
74169
32445

Գործարքներ/վրկ
123
54

Միջին ուշացում
405 րոպե
925 րոպե

Թեստ 2 (150 միացում 100 հնարավորով)

Գործարքների քանակը 10 րոպեում
81727
31429

Գործարքներ/վրկ
136
52

Միջին ուշացում
550 րոպե
1432 րոպե

Չափերի մասին

DB չափը
2251 MB
2262 MB

Տվյալների բազայի գրանցամատյանի չափը
0 ՄԲ
4587 ՄԲ

Ստորին գիծ. ամբողջական աուդիտը այնքան էլ լավ չէ: Աուդիտից ստացված տվյալները կլինեն նույնքան մեծ, որքան տվյալների բազայում կամ նույնիսկ ավելին: DBMS-ի հետ աշխատելիս ստեղծվող անտառահատումների քանակը արտադրության մեջ սովորական խնդիր է:

Դիտարկենք այլ պարամետրեր.

• Արագությունը շատ չի փոխվում՝ առանց գրանցման՝ 43,74 վայրկյան, հատման դեպքում՝ 53,23 վայրկյան։
• RAM-ի և CPU-ի աշխատանքը կտուժի, քանի որ դուք պետք է ստեղծեք աուդիտի ֆայլ: Սա նկատելի է նաև արտադրողականության մեջ։

Քանի որ միացումների քանակը մեծանում է, բնականաբար, կատարումը փոքր-ինչ կվատթարանա:

Աուդիտ ունեցող կորպորացիաներում ավելի դժվար է.

• շատ տվյալներ կան;
• աուդիտը անհրաժեշտ է ոչ միայն syslog-ի միջոցով SIEM-ում, այլ նաև ֆայլերում. եթե syslog-ի հետ ինչ-որ բան է պատահում, պետք է լինի տվյալների բազայի մոտ գտնվող ֆայլ, որում պահվում են տվյալները.
• աուդիտի համար անհրաժեշտ է առանձին դարակ՝ I/O սկավառակները չվատնելու համար, քանի որ այն շատ տեղ է զբաղեցնում;
• Պատահում է, որ տեղեկատվական անվտանգության աշխատակիցներին ամենուր անհրաժեշտ է ԳՕՍՏ ստանդարտներ, նրանք պահանջում են պետական ​​նույնականացում:

Տվյալների հասանելիության սահմանափակում

Եկեք նայենք այն տեխնոլոգիաներին, որոնք օգտագործվում են տվյալների պաշտպանության և դրանց հասանելիության համար առևտրային DBMS-ներում և բաց կոդով:

Ինչ կարող եք ընդհանուր առմամբ օգտագործել.

1. Ընթացակարգերի և գործառույթների գաղտնագրում և մշուշում (Փաթաթում) - այսինքն՝ առանձին գործիքներ և կոմունալ ծառայություններ, որոնք ընթեռնելի կոդը դարձնում են անընթեռնելի: Ճիշտ է, ուրեմն այն ոչ կարող է փոխվել, ոչ էլ հետ վերադարձնել: Այս մոտեցումը երբեմն պահանջվում է առնվազն DBMS-ի կողմից. լիցենզիայի սահմանափակումների կամ թույլտվության տրամաբանությունը գաղտնագրված է հենց ընթացակարգի և գործառույթի մակարդակում:
2. Տվյալների տեսանելիությունը տողերով (RLS) սահմանափակելն այն է, երբ տարբեր օգտատերեր տեսնում են մեկ աղյուսակ, բայց տողերի այլ կազմը դրանում, այսինքն՝ ինչ-որ մեկին չի կարող ցուցադրվել տողի մակարդակով:
3. Ցուցադրվող տվյալների խմբագրումը (Քողարկում) այն է, երբ աղյուսակի մեկ սյունակում օգտագործողները տեսնում են կամ տվյալներ կամ միայն աստղանիշներ, այսինքն՝ որոշ օգտատերերի համար տեղեկատվությունը կփակվի: Տեխնոլոգիան որոշում է, թե որ օգտվողին ինչ է ցուցադրվում՝ ելնելով նրանց հասանելիության մակարդակից:
4. Անվտանգություն DBA/Application 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 | տեքստ 1 | տեքստ 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 րոպե
50,203 րոպե

CPU
15%
35%

Ռամը
 
+ 5%

Կոդավորումը մեծ ազդեցություն ունի կատարողականի վրա: Կարելի է տեսնել, որ ժամանակն աճել է, քանի որ գաղտնագրված տվյալների վերծանման գործողությունները (և վերծանումը սովորաբար դեռ փաթաթված է ձեր տրամաբանության մեջ) պահանջում են զգալի ռեսուրսներ: Այսինքն՝ որոշ տվյալներ պարունակող բոլոր սյունակները գաղտնագրելու գաղափարը հղի է կատարողականի նվազմամբ։

Այնուամենայնիվ, գաղտնագրումը արծաթե փամփուշտ չէ, որը լուծում է բոլոր խնդիրները: Վերծանված տվյալները և վերծանման բանալին տվյալների վերծանման և փոխանցման գործընթացում գտնվում են սերվերի վրա: Հետևաբար, բանալիները կարող են գաղտնալսվել որևէ մեկի կողմից, ով լիարժեք մուտք ունի տվյալների բազայի սերվեր, օրինակ՝ համակարգի ադմինիստրատորը:

Երբ կա մեկ բանալի ամբողջ սյունակի համար բոլոր օգտագործողների համար (նույնիսկ եթե ոչ բոլորի համար, այլ սահմանափակ հավաքածուի հաճախորդների համար), դա միշտ չէ, որ լավ և ճիշտ է: Ահա թե ինչու նրանք սկսեցին կատարել ծայրից ծայր ծածկագրում, DBMS-ում նրանք սկսեցին դիտարկել հաճախորդի և սերվերի կողմից տվյալների կոդավորման տարբերակներ, և հայտնվեցին այդ նույն բանալիների պահոցները՝ առանձին ապրանքներ, որոնք ապահովում են բանալիների կառավարում DBMS-ում: կողմը.

Նման գաղտնագրման օրինակ MongoDB-ում

Անվտանգության առանձնահատկություններ առևտրային և բաց կոդով DBMS-ներում

Գործառույթներ
Տիպ
Գաղտնաբառի քաղաքականություն
Աուդիտ
Ընթացակարգերի և գործառույթների սկզբնական ծածկագրի պաշտպանություն
RLS
Encryption

Oracle
կոմերցիոն
+
+
+
+
+

MsSql
կոմերցիոն
+
+
+
+
+

Ջատոբա
կոմերցիոն
+
+
+
+
Ստուգման նպատակով

PostgreSQL
ազատ
Ստուգման նպատակով
Ստուգման նպատակով
-
+
Ստուգման նպատակով

MongoDb
ազատ
-
+
-
-
Հասանելի է միայն MongoDB Enterprise-ում

Աղյուսակը հեռու է ամբողջական լինելուց, բայց իրավիճակը հետևյալն է. , երբեմն պետք է ինչ-որ բան ավելացնել։ Օրինակ, գաղտնաբառի քաղաքականությունը - PostgreSQL-ն ունի բազմաթիվ տարբեր ընդարձակումներ (1, 2, 3, 4, 5), որոնք իրականացնում են գաղտնաբառերի քաղաքականություն, բայց, իմ կարծիքով, դրանցից ոչ մեկը չի ծածկում ներքին կորպորատիվ սեգմենտի բոլոր կարիքները։

Ինչ անել, եթե որևէ տեղ չունեք այն, ինչ ձեզ հարկավոր է? Օրինակ, դուք ցանկանում եք օգտագործել հատուկ DBMS, որը չունի հաճախորդի պահանջած գործառույթները:

Այնուհետև կարող եք օգտագործել երրորդ կողմի լուծումներ, որոնք աշխատում են տարբեր DBMS-ների հետ, օրինակ՝ Crypto DB կամ Garda DB: Եթե ​​մենք խոսում ենք ներքին հատվածի լուծումների մասին, ապա նրանք ավելի լավ գիտեն ԳՕՍՏ-ների մասին, քան բաց կոդով:

Երկրորդ տարբերակն այն է, որ ինքներդ գրեք այն, ինչ ձեզ հարկավոր է, կատարեք տվյալների հասանելիություն և գաղտնագրում հավելվածում ընթացակարգային մակարդակով: Ճիշտ է, ԳՕՍՏ-ի հետ ավելի դժվար կլինի: Բայց ընդհանուր առմամբ, դուք կարող եք թաքցնել տվյալները, ըստ անհրաժեշտության, տեղադրել դրանք DBMS-ում, այնուհետև առբերել և վերծանել դրանք ըստ անհրաժեշտության՝ հենց հավելվածի մակարդակում: Միևնույն ժամանակ, անմիջապես մտածեք, թե ինչպես եք պաշտպանելու կիրառական այս ալգորիթմները։ Մեր կարծիքով, դա պետք է արվի DBMS մակարդակով, քանի որ այն ավելի արագ կաշխատի։

Այս զեկույցն առաջին անգամ ներկայացվել է ժ @Տվյալների բազաների հանդիպում Mail.ru Cloud Solutions-ի կողմից: Նայել video այլ ներկայացումներ և բաժանորդագրվեք իրադարձությունների հայտարարություններին Telegram-ում Mail.ru Group-ում Kubernetes-ի շուրջ.

Էլ ինչ կարդալ թեմայի շուրջ:

1. Ավելի քան Ceph. MCS ամպային բլոկի պահեստավորում.
2. Ինչպես ընտրել տվյալների բազա նախագծի համար, որպեսզի ստիպված չլինեք նորից ընտրել.

Source: www.habr.com