Напярэдадні старту новага набору на курс працягваем публікаваць серыю артыкулаў пра шыфраванне ў MySQL.
У папярэднім артыкуле гэтай серыі мы абмеркавалі, . Сёння, грунтуючыся на атрыманых раней ведах, паглядзім на ратацыю галоўных ключоў.
Ратацыя галоўных ключоў складаецца ў тым, што генеруецца новы галоўны ключ і гэтым новым ключом паўторна шыфруюцца ключы таблічных прастор (якія захоўваюцца ў загалоўках таблічных прастор).
Давайце ўспомнім, як выглядае загаловак зашыфраванай таблічнай прасторы:
З папярэдняга артыкула мы ведаем, што сервер пры запуску счытвае загалоўкі ўсіх зашыфраваных таблічных прастор і запамінае самы вялікі KEY ID. Напрыклад, калі ў нас ёсць тры табліцы з KEYID = 3 і адна табліца з KEYID = 4, то максімальны ідэнтыфікатар ключа будзе роўны 4. Давайце назавем гэты KEY ID - MAX KEY ID.
Як працуе ратацыя галоўнага ключа
1. Карыстальнік выконвае ALTER INNODB MASTER KEY.
2. Сервер запытвае ў сховішча ключоў (keyring) генерацыю новага галоўнага ключа з UUID сервера і KEYID, роўным павялічанаму на адзінку MAXАСНОЎНЫЯID. Такім чынам, мы атрымліваем ідэнтыфікатар галоўнага ключа, роўны INNODBKEY-UUID- (MAXАСНОЎНЫЯID + 1). Пры паспяховай генерацыі галоўнага ключа MAX KEY ID павялічваецца на адзінку (г.зн. MAXАСНОЎНЫЯID = MAXАСНОЎНЫЯID + 1).
3. Сервер праглядае ўсе таблічныя прасторы, зашыфраваныя з дапамогай галоўнага ключа, і для кожнай таблічнай прасторы:
-
шыфруе ключ таблічнай прасторы новым галоўным ключом;
-
абнаўляе ідэнтыфікатар ключа на новы MAXАСНОЎНЫЯID;
-
калі UUID адрозніваецца ад UUID сервера, то абнаўляе UUID сервера.
Як мы ведаем, ідэнтыфікатар галоўнага ключа (Master Key ID), які выкарыстоўваецца для расшыфроўкі табліцы, складаецца з UUID і KEY ID, лічаных з загалоўка таблічнай прасторы. Што мы робім цяпер, дык гэта абнаўляем гэтую інфармацыю ў загалоўку шыфравання таблічнай прасторы, каб сервер атрымліваў правільны галоўны ключ.
Калі ў нас ёсць таблічныя прасторы, атрыманыя з розных месцаў, напрыклад, з розных рэзервовых копіяў, то яны могуць выкарыстоўваць розныя галоўныя ключы. Усе гэтыя галоўныя ключы неабходна будзе атрымаць са сховішча пры запуску сервера. Гэта можа запаволіць запуск сервера, асабліва калі выкарыстоўваецца сервернае сховішча ключоў. З дапамогай ратацыі галоўнага ключа мы паўторна шыфруем ключы таблічных прастор адным галоўным ключом, аднолькавым для ўсіх таблічных прастор. Цяпер пры запуску сервер павінен атрымаць толькі адзін галоўны ключ.
Гэта, вядома, толькі прыемны пабочны эфект. Галоўная мэта ратацыі галоўных ключоў - зрабіць наш сервер больш бяспечным. У выпадку, калі галоўны ключ быў якой-небудзь выявай выкрадзены са сховішча (напрыклад, з Vault Server), то можна згенераваць новы галоўны ключ і паўторна зашыфраваць ключы таблічных прастор, зрабіўшы выкрадзены ключ несапраўдным. Мы ў бяспецы… амаль.
У папярэднім артыкуле я казаў пра тое, што пасля крадзяжу ключа таблічнай прасторы трэці бок можа выкарыстоўваць яго для расшыфроўкі дадзеных. Пры ўмове, што ёсць доступ да нашага дыска. У выпадку крадзяжу галоўнага ключа і наяўнасці доступу да зашыфраваных дадзеных, можна выкарыстоўваць скрадзены галоўны ключ для расшыфроўкі ключа таблічнай прасторы і атрымаць расшыфраваныя дадзеныя. Як бачым, ратацыя галоўнага ключа ў гэтым выпадку не дапамагае. Мы паўторна шыфруем ключ таблічнай прасторы новым галоўным ключом, але фактычны ключ, які выкарыстоўваецца для шыфравання / дэшыфраванні дадзеных, застаецца ранейшым. Таму "хакер" можа і далей выкарыстоўваць яго для расшыфроўкі дадзеных. Раней я намякаў, што можа выконваць сапраўднае паўторнае шыфраванне таблічных прастор, а не толькі простае паўторнае шыфраванне ключа таблічнай прасторы. Гэтая функцыя завецца струменямі шыфравання (encryption threads). Аднак на дадзены момант гэтая функцыянальнасць усё яшчэ эксперыментальная.
Ратацыя галоўнага ключа карысная, калі галоўны ключ скрадзены, але ў зламысніка няма магчымасці яго выкарыстоўваць і расшыфраваць ключы таблічных прастор.
Чытаць яшчэ:
Крыніца: habr.com