Во пресрет на почеток на нови уписи за курсот продолжуваме да објавуваме серија написи за шифрирање во MySQL.
Во претходната статија од оваа серија, разговаравме . Денес, врз основа на знаењето стекнато порано, да ја разгледаме ротацијата на главните клучеви.
Ротацијата на главниот клуч вклучува генерирање на нов главен клуч и повторно шифрирање на клучевите на табелата (кои се зачувани во заглавијата на табеларниот простор) со овој нов клуч.
Ајде да се потсетиме како изгледа заглавието на шифрираната маса:
Од претходната статија, знаеме дека серверот ги чита заглавјата на сите шифрирани табели при стартување и го запомнува најголемиот KEY ID. На пример, ако имаме три табели со KEYID = 3 и една табела со KEYID = 4, тогаш максималниот ID на клучот ќе биде 4. Да го наречеме овој ID на КЛУЧ - MAX KEY ID.
Како функционира главната ротација на копчињата
1. Корисникот го извршува ALTER INNODB MASTER KEY.
2. Серверот бара приклучокот за клучеви да генерира нов главен клуч со серверот UUID и KEYИД еднаков на еден плус MAXКЛУЧЕНИД. Значи, добиваме идентификација на главниот клуч еднаков на INNODBKEY-UUID-(MAXКЛУЧЕНID + 1). По успешното генерирање на главниот клуч, MAX KEY ID се зголемува за еден (т.е. MAXКЛУЧЕНID=MAXКЛУЧЕНID + 1).
3. Серверот ги скенира сите табели шифрирани со главниот клуч и за секој простор за маса:
-
го шифрира клучот за табелата со новиот главен клуч;
-
го ажурира идентификацијата на клучот на новиот MAXКЛУЧЕНИД;
-
ако UUID е различен од UUID на серверот, тогаш ажурирајте го UUID на серверот.
Како што знаеме, идентификаторот на главниот клуч што се користи за дешифрирање табела се состои од UUID и KEY ID што се чита од заглавието на просторот на табелата. Она што го правиме сега е ажурирање на оваа информација во заглавието за шифрирање на просторот на табелата, така што серверот ќе го добие точниот главен клуч.
Ако имаме табели од различни локации, како што се различни резервни копии, тогаш тие може да користат различни мастер клучеви. Сите овие главни клучеви ќе треба да се извадат од складиштето кога ќе се стартува серверот. Ова може да го забави стартувањето на серверот, особено ако се користи продавница за клучеви на серверот. Со ротација на главниот клуч, ние повторно ги криптираме клучевите на табелата со еден главен клуч кој е ист за сите простори на маса. Сега серверот треба да добие само еден главен клуч при стартувањето.
Ова, се разбира, е само пријатен несакан ефект. Главната цел на ротацијата на главниот клуч е да го направи нашиот сервер побезбеден. Во случај главниот клуч да биде некако украден од сефот (на пример, од серверот на сефот), можно е да се генерира нов главен клуч и повторно да се шифрираат клучевите на табелата, со што украдениот клуч е неважечки. Ние сме безбедни...речиси.
Во претходна статија, зборував за тоа како штом еднаш клучот на табелата е украден, трета страна може да го користи за дешифрирање податоци. Под услов да има пристап до нашиот диск. Ако главниот клуч е украден и имате пристап до шифрираните податоци, можете да го користите украдениот главен клуч за да го дешифрирате клучот на табелата и да ги добиете дешифрираните податоци. Како што можете да видите, ротацијата на главниот клуч не помага во овој случај. Повторно го шифрираме клучот tablespace со новиот главен клуч, но вистинскиот клуч што се користи за шифрирање/дешифрирање на податоците останува ист. Затоа, „хакерот“ може да продолжи да го користи за дешифрирање на податоците. Претходно го навестив тоа може да изврши вистинско повторно шифрирање на просторот на масата, а не само едноставно повторно шифрирање на клучот на просторот на масата. Оваа функција се нарекува нишки за шифрирање. Сепак, оваа функционалност е сè уште експериментална во моментот.
Ротацијата на главниот клуч е корисна кога главниот клуч е украден, но не постои начин напаѓачот да го користи и да ги дешифрира клучевите на табелата.
Прочитај повеќе:
Извор: www.habr.com