Կոդավորումը MySQL-ում. օգտագործելով հիմնական բանալի

Դասընթացի համար նոր գրանցման մեկնարկի ակնկալիքով «Տվյալների բազա» մենք շարունակում ենք հրապարակել MySQL-ում գաղտնագրման մասին հոդվածների շարքը:

Այս շարքի նախորդ հոդվածում (Կոդավորումը MySQL-ում: Keystore) մենք խոսեցինք առանցքային պահոցների մասին: Այս հոդվածում մենք կանդրադառնանք, թե ինչպես է օգտագործվում հիմնական բանալին և կքննարկենք ծրարի կոդավորման առավելություններն ու թերությունները: 

Ծրարի գաղտնագրման գաղափարն այն է, որ գաղտնագրման համար օգտագործվող բանալիները (սեղանի տարածքի ստեղները) կոդավորված են մեկ այլ բանալիով (հիմնական բանալի): Tablespace ստեղները իրականում օգտագործվում են տվյալների գաղտնագրման համար: Գրաֆիկորեն այն կարելի է ներկայացնել այսպես.

Հիմնական բանալին գտնվում է ստեղնաշարի մեջ, իսկ սեղանի տարածքի ստեղները՝ կոդավորված սեղանի տարածության վերնագրերում (աղյուսակի 0-րդ էջում): 

Վերևի նկարում.

• Աղյուսակ Ա-ն կոդավորված է 1-ին բանալիով (Բանալին 1): Բանալին 1-ը գաղտնագրված է հիմնական բանալիի միջոցով և կոդավորված է պահվում A աղյուսակի վերնագրում:

• Աղյուսակ B-ը կոդավորված է բանալի 2-ով: Բանալին 2-ը գաղտնագրված է հիմնական բանալիով (դիմակավորող բանալի) և պահվում է գաղտնագրված B աղյուսակի վերնագրում:

• Եվ այսպես շարունակ:

Երբ սերվերը պետք է գաղտնազերծի A աղյուսակը, այն վերցնում է հիմնական բանալին պահեստից, կարդում է ծածկագրված բանալին 1-ը A աղյուսակի վերնագրից և վերծանում բանալին 1: Ապակոդավորված 1 բանալին պահվում է սերվերի հիշողության մեջ և օգտագործվում է A աղյուսակը վերծանելու համար: .

InnoDB- ը

InnoDB-ում փաստացի կոդավորումը և վերծանումը կատարվում է I/O շերտում: Այսինքն՝ էջը գաղտնագրվում է հենց այն սկավառակի վրա դնելուց առաջ և վերծանվում է սկավառակից կարդալուց անմիջապես հետո:

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

Եթե ​​ինչ-ինչ պատճառներով անջատված եք ֆայլը մեկ աղյուսակում, ապա բոլոր աղյուսակները ստեղծվում են համակարգի սեղանի տարածքում: IN Percona սերվեր MySQL-ի համար դուք կարող եք գաղտնագրել համակարգի սեղանի տարածությունը՝ օգտագործելով innodb փոփոխականըsysսեղանի տարածությունգաղտնագրել կամ օգտագործել գաղտնագրման թելեր, բայց սա դեռ փորձնական հատկություն է: MySQL-ը սա չունի:

Նախքան առաջ անցնելը, մենք պետք է նայենք հիմնական բանալի ID-ի կառուցվածքին: Այն բաղկացած է UUID, KEY-իցID և «INNODBKey» նախածանց: Կարծես այսպես. INNODBKey-UUID-KEYՆույնականացում

UUID-ը սերվերի uuid-ն է՝ կոդավորված սեղանի տարածությամբ: ԲԱՆԱԼԻID-ն պարզապես անընդհատ աճող արժեք է: Առաջին անգամ հիմնական ստեղնը ստեղծելիսID-ն 1 է: Բանալին պտտելու ժամանակ, երբ ստեղծվում է նոր գլխավոր բանալի, KEYID = 2 և այլն: Հիմնական բանալիների ռոտացիայի մասին ավելի շատ կխոսենք այս շարքի հաջորդ հոդվածներում:

Այժմ, երբ մենք գիտենք, թե ինչ տեսք ունի հիմնական բանալի նույնացուցիչը, եկեք նայենք գաղտնագրված աղյուսակի վերնագրին: Երբ սեղանի տարածքը գաղտնագրված է, գաղտնագրման տեղեկատվությունը ավելացվում է վերնագրում: Այն կարծես այսպիսին է.

KEY ID-ն KEY էID-ն հիմնական բանալին ID-ից, որը մենք արդեն քննարկել ենք: UUID-ը սերվերի uuid-ն է, որն օգտագործվում է նաև հիմնական բանալին նույնացուցիչում: TABLESPACE KEY - սեղանի տարածության բանալի, որը բաղկացած է 256 բիթից, որոնք պատահականորեն ստեղծվել են սերվերի կողմից: Նախաստորագրման վեկտորը (IV) նույնպես բաղկացած է 256 պատահականորեն առաջացած բիթից (չնայած այն պետք է լինի 128 բիթ): IV-ն օգտագործվում է AES կոդավորման և վերծանման սկզբնավորման համար (256 բիթից օգտագործվում է միայն 128-ը): Վերջում կա CRC32 ստուգիչ գումար TABLESPACE KEY-ի և IV-ի համար:

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

Ինչու է անհրաժեշտ CRC32-ը:

Մի խոսքով, հիմնական բանալի վավերականությունն ապահովելու համար: Tablespace ստեղնը և սկզբնավորման վեկտորը վերծանելուց հետո ստուգիչ գումարը հաշվարկվում և համեմատվում է վերնագրում պահվող CRC32-ի հետ: Եթե ​​ստուգիչ գումարները համընկնում են, ապա մենք ունենք ճիշտ հիմնական ստեղնը և tablespace ստեղնը: Հակառակ դեպքում, սեղանի տարածքը նշված է որպես բացակայող (մենք, այնուամենայնիվ, չենք կարողանա վերծանել այն):

Կարող եք հարցնել. ո՞ր կետում է իրականացվում հիմնական ստուգումը: Պատասխանն այն է, երբ սերվերը սկսվում է: Կոդավորված աղյուսակներով/սեղանային տարածքներով սերվերը կարդում է UUID, KEY գործարկման ժամանակID-ն վերնագրից և առաջացնում է հիմնական բանալի ID-ն: Այնուհետև այն ստեղնաշարից ստանում է անհրաժեշտ հիմնական բանալին, վերծանում է սեղանի տարածության բանալին և ստուգում ստուգման գումարը: Կրկին, եթե ստուգիչ գումարը համընկնում է, ապա ամեն ինչ լավ է, եթե ոչ, ապա սեղանի տարածությունը նշված է որպես բացակայող:

Եթե ​​կարդում եք այս շարքի նախորդ հոդվածը (Կոդավորումը MySQL-ում: Keystore), այնուհետև դուք կարող եք հիշել, որ սերվերի վրա հիմնված բանալիների պահեստ օգտագործելիս, գործարկման ժամանակ սերվերը ստանում է միայն հիմնական նույնացուցիչների ցանկը, ավելի ճիշտ՝ բանալու id-ն և օգտագործողի id-ը, քանի որ այս զույգը եզակիորեն նույնացնում է բանալին: Հիմա ես ասում եմ, որ երբ սերվերը սկսում է, նա ստանում է բոլոր ստեղները, որոնք անհրաժեշտ են ստուգելու համար, որ կարող է վերծանել սեղանի տարածքի ստեղները: Այսպիսով, ինչու սկզբնավորման ժամանակ, սերվերի պահպանման դեպքում, բեռնվում է միայն բանալինID և օգտվողid, և ոչ բոլոր ստեղները: Քանի որ ձեզ կարող են բոլոր բանալիները չպահանջել: Սա հիմնականում պայմանավորված է հիմնական բանալիների պտտմամբ: Երբ հիմնական բանալին պտտվում է, պահոցում ստեղծվում է նոր հիմնական բանալի, բայց հին ստեղները չեն ջնջվում: Այսպիսով, դուք կարող եք ունենալ բազմաթիվ բանալիներ սերվերի բանալիների պահեստում, որոնք սերվերին պետք չեն, և, հետևաբար, չեն առբերվում սերվերի գործարկման ժամանակ:

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

Այնուամենայնիվ, հիմնական բանալի գաղտնագրումն ունի մեկ մեծ թերություն. երբ սեղանի տարածքը կոդավորված է tablespace_key-ով, այն միշտ մնում է կոդավորված նույն բանալիով: Հիմնական ստեղնը պտտելը այստեղ չի օգնում: Ինչու է սա թերություն: Մենք գիտենք, որ MySQL-ն ունի սխալներ, որոնք կարող են հանգեցնել հանկարծակի խափանման և հիմնական ֆայլի ստեղծմանը: Քանի որ հիմնական ֆայլը պարունակում է սերվերի հիշողության աղբավայր, կարող է պատահել, որ աղբավայրը պարունակում է վերծանված սեղանի տարածքի բանալին: Իրավիճակն ավելի վատթարացնելու համար գաղտնազերծված սեղանի ստեղները պահվում են հիշողության մեջ, որը կարելի է փոխանակել սկավառակի վրա: Կարելի է ասել, որ սա թերություն չէ, քանի որ այս ֆայլերը և փոխանակման միջնորմ մուտք գործելու համար անհրաժեշտ են արմատային իրավունքներ: Այո՛։ Բայց արմատը պետք է միայն որոշ ժամանակով: Հենց որ ինչ-որ մեկին հասանելի լինի վերծանված tablespace ստեղնը, նա կարող է շարունակել օգտագործել այն տվյալների վերծանման համար՝ նույնիսկ առանց արմատային արտոնությունների: Բացի այդ, սկավառակը կարող է գողացվել, իսկ փոխանակման միջնորմը/հիմնական ֆայլերը կարելի է կարդալ երրորդ կողմի գործիքների միջոցով: TDE-ի նպատակն է այն անընթեռնելի դարձնել, նույնիսկ եթե սկավառակը գողացված է: IN Percona սերվեր MySQL-ի համար Հնարավոր է նորից գաղտնագրել աղյուսակի տարածությունը նոր գեներացված բանալիներով: Այս հատկությունը կոչվում է գաղտնագրման թելեր և գրելու պահին դեռ փորձնական է:

Իմացեք ավելին դասընթացի մասին

Կարդալ ավելին:

• Կոդավորումը MySQL-ում: Keystore

Source: www.habr.com