Իմ անունը Դենիս Ռոժկով է, ես «Գազինֆորմսերվիս»-ի ծրագրային ապահովման մշակման ղեկավարն եմ, արտադրանքի թիմում։ ՋատոբաՕրենսդրությունը և կորպորատիվ կարգավորումները որոշակի պահանջներ են սահմանում տվյալների պահպանման անվտանգության համար: Ոչ ոք չի ցանկանում, որ երրորդ կողմերը հասանելիություն ստանան գաղտնի տեղեկատվությանը, ուստի հետևյալ հարցերը կարևոր են ցանկացած նախագծի համար՝ նույնականացում և նույնականացում, տվյալների հասանելիության կառավարում, համակարգում տեղեկատվության ամբողջականության ապահովում և անվտանգության իրադարձությունների գրանցում: Հետևաբար, ես կցանկանայի խոսել տվյալների բազայի կառավարման համակարգի անվտանգության վերաբերյալ մի քանի հետաքրքիր կետերի մասին:

Հոդվածը պատրաստվել է ելույթի հիման վրա՝ @Տվյալների բազաների հանդիպում, կազմակերպված Mail.ru Cloud SolutionsԵթե ​​չեք ուզում կարդալ, կարող եք դիտել՝

Հոդվածը կունենա երեք մաս.

• Ինչպես ամրագրել կապերը։
• Ի՞նչ է գործողությունների աուդիտը և ինչպե՞ս գրանցել տվյալների բազայի կողմում տեղի ունեցողը և դրա հետ կապը։
• Ինչպե՞ս պաշտպանել տվյալները տվյալների բազայում և ինչ տեխնոլոգիաներ են հասանելի դրա համար։

Տվյալների կառավարման համակարգի անվտանգության երեք բաղադրիչներ՝ կապի անվտանգություն, գործողությունների աուդիտ և տվյալների պաշտպանություն

Միացման պաշտպանություն

Դուք կարող եք միանալ տվյալների բազային ինչպես ուղղակիորեն, այնպես էլ անուղղակիորեն՝ վեբ հավելվածների միջոցով: Որպես կանոն, գործարար կողմից օգտատերը, այսինքն՝ այն անձը, ով աշխատում է տվյալների բազային համակարգի հետ, անուղղակիորեն փոխազդում է դրա հետ:

Մինչև կապերի պաշտպանության մասին խոսելը, անհրաժեշտ է պատասխանել կարևոր հարցերի, որոնք որոշում են, թե ինչպես կկառուցվեն անվտանգության միջոցառումները.

• մեկ բիզնես օգտատերը համարժեք է մեկ DBMS օգտատիրոջ։
• արդյոք տվյալների բազայի տվյալներին մուտքը տրամադրվում է միայն ձեր կողմից կառավարվող API-ի միջոցով, թե՞ աղյուսակներին ուղիղ մուտք կա։
• արդյոք տվյալների բազայի կառավարման համակարգը հատկացված է առանձին պաշտպանված հատվածի, ով է փոխազդում դրա հետ և ինչպես։
• արդյոք օգտագործվում են միավորման/պրոքսիի սերվերներ և միջանկյալ ծրագրեր, որոնք կարող են փոխել կապի կառուցման եղանակի և տվյալների բազան օգտագործողների մասին տեղեկատվությունը։

Հիմա տեսնենք, թե ինչ գործիքներ կարող են օգտագործվել կապերը պաշտպանելու համար.

1. Օգտագործեք տվյալների բազայի firewall լուծումներ: Պաշտպանության լրացուցիչ շերտը առնվազն կբարձրացնի տվյալների բազայի կառավարման համակարգում տեղի ունեցողի թափանցիկությունը, և առավելագույնը դուք կկարողանաք ապահովել տվյալների լրացուցիչ պաշտպանություն:
2. Օգտագործեք գաղտնաբառի քաղաքականություններ: Դրանց օգտագործումը կախված է նրանից, թե ինչպես է կառուցված ձեր ճարտարապետությունը: Ամեն դեպքում, տվյալների բազայի կառավարման համակարգին միացող վեբ հավելվածի կոնֆիգուրացիայի ֆայլում մեկ գաղտնաբառը բավարար չէ պաշտպանության համար: Կան մի շարք տվյալների բազայի կառավարման գործիքներ, որոնք թույլ են տալիս վերահսկել, որ օգտագործողը և գաղտնաբառը կարիք ունեն թարմացման:

   Դուք կարող եք ավելին կարդալ օգտատիրոջ գնահատման գործառույթների մասին այստեղ, կարող եք նաև տեղեկանալ MS SQL խոցելիության գնահատման ծրագրերի մասին։ այստեղ. 

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

Ինչպե՞ս է սա ազդելու տվյալների բազայի կառավարման համակարգի աշխատանքի վրա։

Եկեք դիտարկենք PostgreSQL-ի օրինակը՝ տեսնելու համար, թե ինչպես է SSL-ը ազդում CPU-ի ծանրաբեռնվածության վրա, մեծացնում է ժամանակացույցը և նվազեցնում 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 նույնականացման ռեժիմը։ Սա մեծ ծանրաբեռնվածություն առաջացրեց պրոցեսորի վրա, կատարողականությունը նվազեց։ Մենք սկսեցինք փնտրել օպտիմալացման եղանակներ։ Խնդրի հնարավոր լուծումներից մեկը ցանցային սահմանափակում ներդնելն է, տվյալների բազայի համար առանձին VLAN-ներ ստեղծելը, կարգավորումներ ավելացնելը, որպեսզի պարզ լինի, թե ով է միանում և որտեղից, և նույնականացումը հանելը։ Նույնականացման միացման ժամանակ ծախսերը նվազեցնելու համար կարող եք նաև օպտիմալացնել նույնականացման կարգավորումները, բայց ընդհանուր առմամբ, տարբեր նույնականացման մեթոդների օգտագործումը ազդում է կատարողականության վրա և պահանջում է հաշվի առնել այս գործոնները տվյալների բազայի համար սերվերների (ապարատային) հաշվողական հզորությունը նախագծելիս։

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

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

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

Առևտրային ձեռնարկությունների մակարդակի տվյալների բազաների կառավարման համակարգերում աուդիտը նորմալ է, բայց ոչ միշտ բաց կոդով։ Ահա թե ինչ ունի PostgreSQL-ը.

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

Հաշվետվության լրացումը՝ տեսանյութում.

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

Սա ընդունելի է մոնիթորինգի և այլ նպատակներով, բայց չի ապահովում աուդիտի համար սովորաբար անհրաժեշտ մանրամասնության մակարդակը։

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

Պետք է նաև հնարավոր լինի բացահայտել աուդիտորի համար հետաքրքրություն ներկայացնող կոնկրետ պնդումներ։

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

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

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

ԱՆԵԼ $$
BEGIN
ԿԱՏԱՐԵՔ 'ՍՏԵՂԾԵԼ ԱՂՅՈՒՍԱԿ ներմուծել' || 'ant_table(id int)';
ԱՎԱՐՏ $$;

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

LOG: հայտարարություն՝ DO $$
BEGIN
ԿԱՏԱՐԵՔ 'ՍՏԵՂԾԵԼ ԱՂՅՈՒՍԱԿ ներմուծել' || 'ant_table(id int)';
ԱՎԱՐՏ $$;

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

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

Ահա թե որտեղ է pgAudit-ը օգտակար լինում։

Նույն մուտքային տվյալի համար այն գրանցամատյանում կտա հետևյալ արդյունքը՝

Աուդիտ. ՍԵԱՆՍ,33,1,ԳՈՐԾԱՌՈՒՅԹ,ԱՆԵԼ,,,ԱՆԵԼ $$
BEGIN
ԿԱՏԱՐԵՔ 'ՍՏԵՂԾԵԼ ԱՂՅՈՒՍԱԿ ներմուծել' || 'ant_table(id int)';
ԱՎԱՐՏ $$;"
ԱՈՒԴԻՏ։ ՍԵՍԻՈՆ,33,2,DDL,ՍՏԵՂԾԵԼ ԱՂՅՈՒՍԱԿ,ԱՂՅՈՒՍԱԿ,public.important_table,ՍՏԵՂԾԵԼ ԱՂՅՈՒՍԱԿ important_table (id INT)

Գրանցվում է ոչ միայն DO բլոկը, այլև CREATE TABLE-ի ամբողջական տեքստը՝ օպերատորի տեսակով, օբյեկտի տեսակով և լրիվ անվամբ, ինչը հեշտացնում է որոնումը։

SELECT և DML հրամանները գրանցելիս, pgAudit-ը կարող է կարգավորվել՝ հրամանում հղված յուրաքանչյուր հարաբերության համար առանձին գրառում գրանցելու համար։

Տվյալ աղյուսակին ազդող բոլոր հրամանները գտնելու համար վերլուծություն անհրաժեշտ չէ (*) »:

Ինչպե՞ս է սա ազդելու տվյալների բազայի կառավարման համակարգի աշխատանքի վրա։

Եկեք թեստեր անցկացնենք՝ լիարժեք աուդիտը միացված լինելով, և տեսնենք, թե ինչ է պատահում PostgreSQL-ի աշխատանքի հետ։ Միացրեք տվյալների բազայի առավելագույն գրանցումը բոլոր պարամետրերի համար։

Մենք կոնֆիգուրացիայի ֆայլում գրեթե ոչինչ չենք փոխում, կարևորը debug5 ռեժիմը միացնելն է՝ առավելագույն տեղեկատվություն ստանալու համար։

postgresql.conf

log_destination = 'stderr'
logging_collector = միացված
log_truncate_on_rotation = միացված
log_rotation_age = 1d
log_rotation_size = 10 ՄԲ
log_min_messages = debug5
log_min_error_statement = debug5
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_waits = միացված
log_replication_commands = միացված
log_temp_files = 0
log_timezone = 'Եվրոպա/Մոսկվա'

1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD պարամետրերով PostgreSQL DBMS-ում մենք անցկացնում ենք երեք բեռնման թեստ՝ օգտագործելով հետևյալ հրամանները.

$ 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 րոպե

Չափերի մասին

Տվյալների բազայի չափը
2251 MB
2262 MB

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

Եզրափակելով՝ լիարժեք աուդիտը այդքան էլ լավ չէ։ Աուդիտից ստացված տվյալների քանակը նույնը կլինի, ինչ տվյալների բազայում առկա տվյալները, կամ նույնիսկ ավելին։ Տվյալների բազայի կառավարման համակարգի հետ աշխատելիս առաջացող այս քանակի գրանցումները արտադրության մեջ տարածված խնդիր են։

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

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

Քանի որ կապերի քանակը մեծանում է, բնականաբար, կատարողականը մի փոքր կվատանա։

Կորպորացիաներում աուդիտն ավելի բարդ է.

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

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

Եկեք դիտարկենք առևտրային և բաց կոդով տվյալների կառավարման համակարգերում (DBMS) տվյալների պաշտպանության և դրանց հասանելիության համար օգտագործվող տեխնոլոգիաները։

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

1. Պրոցեդուրաների և ֆունկցիաների կոդավորում և մշուշոտում (փաթեթավորում), այսինքն՝ առանձին գործիքներ և օգտակար ծրագրեր, որոնք ընթեռնելի կոդը դարձնում են անընթեռնելի։ Այնուամենայնիվ, այն հետագայում չի կարող փոփոխվել կամ վերաձևակերպվել։ Այս մոտեցումը երբեմն պահանջվում է առնվազն տվյալների բազայի կառավարման համակարգի կողմից՝ լիցենզավորման սահմանափակումների կամ լիազորման տրամաբանությունը կոդավորվում է ճշգրիտ պրոցեդուրայի և ֆունկցիայի մակարդակում։
2. Տողերի մակարդակի տեսանելիությունը (RLS) այն է, երբ տարբեր օգտատերեր տեսնում են նույն աղյուսակը, բայց դրանում տողերի կազմը տարբեր է, այսինքն՝ ինչ-որ մեկը չի կարող տեսնել տողերի մակարդակում ինչ-որ բան։
3. Ցուցադրվող տվյալների խմբագրումը (դիմակավորումը) տեղի է ունենում, երբ աղյուսակի մեկ սյունակում գտնվող օգտատերերը տեսնում են կամ տվյալներ, կամ միայն աստղանիշներ, այսինքն՝ որոշ օգտատերերի համար տեղեկատվությունը փակ կլինի: Տեխնոլոգիան է որոշում, թե որ օգտատիրոջը ինչ ցուցադրել՝ հաշվի առնելով մուտքի մակարդակը:
4. Մուտքի սահմանազատում Անվտանգության տվյալների բազայի/կիրառական տվյալների բազայի/կիրառական տվյալների բազայի (DBA) օգտագործումը ավելի շատ վերաբերում է տվյալների բազայի կառավարման համակարգ մուտք գործելու սահմանափակմանը, այսինքն՝ տեղեկատվական անվտանգության աշխատակիցները կարող են առանձնացվել տվյալների բազայի ադմինիստրատորներից և ծրագրային ապահովման ադմինիստրատորներից: Բաց կոդով համակարգերում նման տեխնոլոգիաները քիչ են, բայց առևտրային տվյալների բազաներում դրանք շատ են: Դրանք անհրաժեշտ են, երբ սերվերներին մուտք ունեցող շատ օգտատերեր կան:
5. Ֆայլերի մուտքի սահմանափակում ֆայլային համակարգի մակարդակում: Դուք կարող եք տրամադրել իրավունքներ, արտոնություններ՝ գրացուցակներ մուտք գործելու համար, որպեսզի յուրաքանչյուր ադմինիստրատոր մուտք ունենա միայն անհրաժեշտ տվյալներին:
6. Պարտադիր մուտքը և հիշողության մաքրումը հազվադեպ օգտագործվող տեխնոլոգիաներ են։
7. Անմիջապես տվյալների բազայի համակարգում ծայրից ծայր կոդավորումը հաճախորդի կողմից կոդավորում է՝ բանալիների կառավարմամբ սերվերի կողմից։
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 մվ

Քաղվածք կոդավորման ֆունկցիայով աղյուսակից՝

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 մվ

Թեստի արդյունքներ:

 
Առանց կոդավորման
Pgcrypto (վերծանել)

1000 տողերի ընտրություն
1,386 րոպե
50,203 րոպե

CPU
15%
35%

Ռամը
 
+ 5%

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

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

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

Նման կոդավորման օրինակ MongoDB-ում

Անվտանգության գործիքներ առևտրային և բաց կոդով տվյալների բազաների կառավարման համակարգերում

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

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

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

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

PostgreSQL
Անվճար
Ստուգման նպատակով
Ստուգման նպատակով
-
+
Ստուգման նպատակով

MongoDB
Անվճար
-
+
-
-
Հասանելի է միայն MongoDB Enterprise-ում

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

Ի՞նչ անել, եթե ոչ մի տեղ չեք կարողանում գտնել այն, ինչ ձեզ անհրաժեշտ էՕրինակ, դուք ցանկանում եք օգտագործել որոշակի տվյալների բազայի կառավարման համակարգ, որը չունի հաճախորդին անհրաժեշտ գործառույթները։

Այնուհետև կարող եք օգտագործել երրորդ կողմի լուծումներ, որոնք աշխատում են տարբեր տվյալների բազաների կառավարման համակարգերի հետ, օրինակ՝ «Crypto DB» կամ «Garda DB»: Եթե խոսքը ներքին հատվածի լուծումների մասին է, ապա նրանք ավելի լավ գիտեն GOST-ների մասին, քան բաց կոդով համակարգերում:

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

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

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

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

Source: www.habr.com