Защитата на вашите данни е една от най-важните задачи, които трябва да дадем приоритет. Появата на регулации, които изискват съответствие със сигурността, като GDPR, HIPAA, PCI DSS или PHI, изисква данните ви да се съхраняват сигурно или да се предават по кабела.
В ClusterControl ние ценим значението на сигурността и предлагаме редица функции за защитен достъп до база данни и съхранявани данни. Едно от тях е осигуряването на резервни копия на вашата база данни, както в състояние на покой, така и при транспортиране. По време на пренос е, когато архивът се прехвърля през интернет или мрежа от източник до местоназначение, докато в състояние на покой е, когато данните се съхраняват в постоянно съхранение. В този блог ще ви покажем как можете да използвате ClusterControl за криптиране на вашите архивни данни в състояние на покой и по време на транспортиране.
Шифроване по време на транспорт
Когато управлявате архивиране чрез ClusterControl, използването на mysqldump или Percona Xtrabackup/Mariabackup се управлява по подразбиране без криптиране, когато се предава по кабела. Въпреки това, използването на TLS/SSL за криптиране на предаване на данни се поддържа от MySQL/MariaDB/Percona Server, както и Percona Xtrabackup, който предлага SSL опции при извикване на командата.
ClusterControl активира SSL по подразбиране, когато разгръщате клъстер, но няма контрола да превключи незабавно и да направи вашите данни криптирани по кабела по време на създаване на архивиране. Можете да разгледате предишните ни блогове за ръчния подход с помощта на ClusterControl, когато създавате своя клъстер или като използвате старомоден начин за ръчна настройка на TLS/SSL в MySQL.
В ClusterControl, когато разгръщате клъстер, можете да проверите раздела за сигурност или тази икона 
.
Щракването върху Бутонът 
ще ви позволи да замените сертификата, който в момента се използва или внедрява от ClusterControl по време на внедряването на вашия новоосигурен клъстер. Можете да проверите този блог "Актуализиран:Станете ClusterControl DBA - SSL Key Management и криптиране на MySQL данни в транзит", за който показахме как работим с ключовете. По принцип можете да преминете през лявата навигация на ClusterControl и да щракнете върху „Управление на ключовете“.
По-долу е даден пример за управление на ключове, в който можете да създавате и импортирате съществуващите си ключове.
Когато създавате резервно копие, използвайки mysqldump като логическо резервно копие, за да криптирате данните си, уверете се, че имате съответните опции за SSL.
Какво следва?
Тъй като имаме създадени от нас сертификати, трябва да активираме и настроим SSL съответно. За да сте сигурни в това, можете да проверите чрез ClusterControl или командния ред на mysql. Вижте изображенията по-долу:
или можете също да проверите в раздела производителност и да щракнете върху DB променливи, както се вижда по-долу:
Обърнете внимание, че може да отнеме известно време, за да се попълни в Performance -> DB Variables. Така че, ако искате да проверите ръчно, можете да използвате командния ред на mysql точно както по-долу:
Дефинирането на вашия ssl_cipher може да добави повече засилване на сигурността. Има списък с шифров пакет, ако стартирате SHOW GLOBAL STATUS LIKE ‘Ssl_cipher_list’\G или проверете тук. Шифровият пакет е комбинация от алгоритми за удостоверяване, криптиране и код за удостоверяване на съобщения (MAC). Те се използват по време на договаряне на настройките за сигурност за TLS/SSL връзка, както и за защитен трансфер на данни.
Тъй като ClusterControl ще стартира mysqldump локално в този хост, добавяйки следните параметри (вижте по-долу) във вашия конфигурационен файл на MySQL (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) ще шифрова всички действия за SQL дъмп. Вижте по-долу:
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pemМожете да опитате да наблюдавате с помощта на tcpdump и можете да видите по-долу сравнение с некриптиран срещу криптиран слой, използващ TLS.
С TLS/SSL:
Без TLS/SSL:
Когато използвате Percona XtraBackup или Mariabackup под ClusterControl, няма поддръжка на TLS/SSL от този момент, когато архивирането се предава по мрежата. Той използва socat, който по същество просто отваря порт в друг възел като средство за комуникация.
напр.
[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.Ако имате нужда от защитен слой по време на транспортиране, можете да направите това ръчно, като използвате опции --ssl* по време на извикване на команда. Вижте тук ръководството на Percona XtraBackup за повече информация. Все пак препоръчваме да получите своя сертификат/ключ от регистриран сертифициращ орган.
Като алтернатива, като използвате ClusterControl, можете да криптирате данните си, преди да ги изпратите през мрежата, изпращаните пакети не са необработени, а криптирани данни. Въпреки че криптирането разчита на покой, ще обсъдим това в следващия раздел.
Шифроване в покой
В ClusterControl, когато създавате резервно копие, имате възможност да направите данните си криптирани. Вижте по-долу:
Когато е криптиран, ClusterControl ще използва „Стандарт за предварително криптиране“ AES-256-CBC. Вижте примерния дневник по-долу:
[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.Ако съхранявате резервното си копие в облака, например с AWS S3, S3 предлага три различни режима на криптиране от страна на сървъра (SSE). Това са SSE-S3, SSE-C или SSE-KMS. Amazon предлага страхотни SSE функции, които се справят с криптирането на данни в покой. Можете да започнете тук, което се занимава с това как S3 използва AWS KMS. Ако премествате резервното си копие в хранилище, базирано на том или блок, AWS има EBS криптиране, използвайки AWS KMS. Можете да проверите тук за повече информация за това.
Microsoft Azure има страхотни функции и при работа с данни в покой. Разгледайте страницата „Шифроване на услугата за съхранение на Azure за данни в покой“. Azure обработва ключовете в своя Azure Key Vault, както и AWS KMS. За шифроване на Google за данни в покой, можете да проверите тук.
Когато съхранявате резервни копия на данни локално, можете да използвате LUKS (Linux Unified Key Setup) с комбинация от crypt или dmcrypt. Няма да обсъждам това в този блог, но това е добър източник за разглеждане:MySQL Encryption at Rest – Part 1 (LUKS). За повече информация относно криптирането на диска тази страница на ArchLinux „Шифроване на диск“ е чудесен източник за начало.
Най-важното е, че докато данните ви са криптирани в състояние на покой и при транспортиране, винаги проверявайте дали архивирането ви работи. Архив, който не е тестван, не е резервно копие, ако не работи, когато е необходимо възстановяване. Съхраняването на вашето архивно копие, докато е криптирано, трябва да бъде декриптирано без никакви проблеми, като по този начин вашите ключове трябва да се съхраняват поверително и по възможно най-сигурния начин. Освен това добавянето на криптиране към вашите данни, като InnoDB криптиране или SST (за Galera), добавя повече сигурност, но няма да ги разглеждаме в този блог.
Заключение
Шифроването на архивни данни в състояние на покой и при пренасяне са жизненоважни компоненти за съответствие с PHI, HIPAA, PCI DSS или GDPR, за да се гарантира, че чувствителните данни, предавани по кабела или записани на дискове, не могат да се четат от никой потребител или приложение без валиден ключ. Някои разпоредби за съответствие, като PCI DSS и HIPAA изискват данните в покой да бъдат криптирани през целия жизнен цикъл на данните.
Тук показваме как ClusterControl предлага тези опции на крайния потребител. Съответствието обаче е огромна задача, която засяга много различни области. Регламентите също се актуализират често, а процесите/инструментите също трябва да бъдат актуализирани съответно. Ние непрекъснато подобряваме различни области в ClusterControl, за да улесним съответствието. Бихме искали да чуем вашите мисли за това и как можем да подобрим.
