Сигурността на данните е от решаващо значение във времена на GDPR, PCI DSS или HIPPA. За да се съобразят с разпоредбите, човек трябва да бъде изключително внимателен по отношение на това как данните трябва да се съхраняват и защитават. Данните обикновено могат да бъдат в покой или в транзит. Данните в транзит са данните, прехвърлени от или към базата данни. Резултатите от заявката, изпратени до клиента или приложението, или репликираните данни между възлите на клъстера са примери за случаи, когато данните се предават. Ние сме склонни да защитаваме данните в това състояние с помощта на SSL или TLS – криптирани връзки между възлите на базата данни или базата данни и клиента.
От другата страна на спектъра имаме данни в покой - бихме казали, че повечето данни в дадения момент са в покой. Тук говорим за данни, съхранявани на диск в пространства за таблици, различни структури от данни (gcache буфер, повторни регистрационни файлове) и журнали (двоични и релейни регистрационни файлове). Нека да разгледаме съображенията около тази тема в MariaDB.
Какво да шифроваме в MariaDB?
В идеалния случай трябва да шифровате всичко. Базите данни съхраняват данни на различни места и по различни начини, както бе споменато по-горе. Най-големият набор от данни се съхранява в пространства за таблици - това е „крайното“ място, където се съхраняват данните. Очевидно е възможно да се криптират пространства за таблици - в противен случай цялата функция би била безсмислена. MariaDB може да съхранява данните в едно споделено пространство за таблици, няколко от тях или всяка таблица може да се съхранява в отделно пространство за таблици - всички тези сценарии се поддържат. Потребителите имат известно ниво на гъвкавост, когато избират какво да криптират. Можете да шифровате всичко, отделни таблици или всичко, освен някои отделни таблици.
Журнал за повторение на MariaDB InnoDB
Друга структура, която съхранява данните е InnoDB redo log. InnoDB redo log е място, където се записват данни, след като даден ред е бил надстроен. Данните от дневника за повторно изпълнение в крайна сметка ще бъдат прехвърлени в пространството за таблици, но за известно време дневникът за повторение на InnoDB съдържа всички модификации, които са се случили наскоро. Както можете да си представите, тези данни също са критични и трябва да бъдат защитени - MariaDB ви позволява да шифровате InnoDB дневник за повторение.
Бинарни регистрационни файлове на MariaDB
Двоичните регистрационни файлове (както и релейните регистрационни файлове) съхраняват информация за изпълнени заявки, които променят данните. Тъй като включената информация ни позволява да реконструираме текущото състояние на ред, който е претърпял модификация, това е друга форма на данни, която трябва да бъде защитена и криптирана. Както двоичните, така и релейните регистрационни файлове могат да бъдат криптирани в MariaDB.
Кеш на Галера
Кешът на Galera (gcache) е дисков буфер в Galera Cluster, който съхранява информацията за извършените модификации. Използва се в случай на повреда на възел или временни проблеми с мрежата, за да позволи на възлите, които се присъединяват към клъстера, да наваксат, използвайки само данните, които им липсват, като избягва прехвърлянето на целия набор от данни. Подобно на двоичните регистрационни файлове или регистрационните файлове за повторение, gcache съдържа списъка с модификации и като такъв може да се използва за възстановяване и събиране на части от данни. В общностната версия на MariaDB Galera Cluster gcache не може да бъде криптиран. Такава опция става достъпна в Enterprise версията на MariaDB Galera Cluster.
Какво не може да бъде криптирано в MariaDB?
Все още има места, където може да се покажат части от данни, които не могат да бъдат криптирани, поне засега, в MariaDB. Първо, регистрационните файлове за грешки могат да съдържат проби от заявки, които потенциално могат да разкрият някои данни. Невъзможно е да се криптират регистрационните файлове за грешки, но е възможно да се пренасочи регистърът за грешки към системния журнал и да се приложи някакъв защитен механизъм извън MariaDB.
Регистрации от приставката за одит
Приставката за одит също генерира дневник - този дневник може да съдържа чувствителна информация, включително точните заявки, които са били изпълнени в базата данни. Не е възможно да се шифрова този дневник, но може да бъде пренасочен към системния журнал и да се шифрова там.
Регистъри на заявки
Общи и бавни регистрационни файлове на заявки – тези регистрационни файлове ще съдържат заявки (или поне извадки от тях), които са били изпълнени от MariaDB. Към момента не е възможно да се криптират тези регистрационни файлове.
InnoDB буферен пул
Памет - MariaDB извършва криптиране само за страниците, които се съхраняват на диска. Всички данни, които се съхраняват в буферния пул на InnoDB, ще бъдат некриптирани. Буферният пул на InnoDB е предназначен да поддържа редовете, наскоро модифицирани или достъпни чрез SELECT заявка - тези редове очевидно ще съдържат извадки от данни. Към момента няма опция за криптиране на буферния пул InnoDB в MariaDB. Моля, имайте предвид, че ще е необходим достъп до системата за четене на живата памет. Това не е тривиална задача, макар и да не е невъзможно да се изпълни.
Моля, имайте предвид, че разгледахме опциите за криптиране, включени в MariaDB. Винаги има възможност за използване на друг слой криптиране. Например криптирането на цялото хранилище ще направи регистрационните файлове нечетими за всеки, който би имал физически достъп до диска. От друга страна, няма да защити данните от някой, който може да влезе в системата.
Съвместимост с външни инструменти
Друго нещо, което трябва да имате предвид, е съвместимостта. Ако решите да криптирате своя MariaDB, трябва да имате предвид, че това може да повлияе на начина, по който работите. Не е възможно да се използват външни инструменти като XtraBackup или mysqlbinlog за обработка на данните и създаване на резервно копие или за работа с двоични регистрационни файлове. Ще трябва да се придържате към инструментите, създадени от MariaDB (като Mariabackup), които са написани с предвид механизма за криптиране. Те могат да обработват данните в покой, криптирането е внедрено в MariaDB.
Планиране на процеса на криптиране
Този раздел няма да обсъжда подробно процеса, но разглежда какво трябва да имате предвид, когато планирате криптиране, като ресурси и време. Използването на процесора ще се увеличи, както и I/O активността по време на процеса. От гледна точка на потребителя всичко се свежда до настройките за конфигурация и след това изпълнение на команди ALTER за повторно изграждане и криптиране на съществуващи таблици. За големите бази данни това само по себе си може да бъде значително предизвикателство, което изисква планиране. Промените в схемата могат да бъдат сериозна тежест и се препоръчва използването на инструменти като pt-online-schema-change, за да се намали въздействието им върху производствените системи и да се постигне по-добър контрол върху процеса.
Последни мисли
Както споменахме, данните са от решаващо значение за всички организации и е от решаващо значение да се гарантира, че данните са безопасни и защитени. Криптирането на данните в покой е един от важните елементи в цялата картина. Ще се радваме да чуем от вас за вашия опит с криптирането на данни в покой в MariaDB. Ако искате да споделите вашите мисли, можете да оставите коментар по-долу.
