MySQL-də şifrələmə: Açar anbarı

Kurs üçün yeni qeydiyyatın başlaması ərəfəsində "Məlumat bazası" Biz sizin üçün faydalı bir məqalənin tərcüməsini hazırlamışıq.

Şəffaf Məlumat Şifrələməsi (TDE) ortaya çıxdı MySQL üçün Percona Server və MySQL uzun müddətdir. Ancaq onun başlıq altında necə işlədiyini və TDE-nin serverinizə hansı təsir göstərə biləcəyini heç düşünmüsünüzmü? Bu məqalələr silsiləsində biz TDE-nin daxili olaraq necə işlədiyinə baxacağıq. Açar saxlama ilə başlayaq, çünki bu, hər hansı bir şifrələmənin işləməsi üçün tələb olunur. Sonra MySQL/MySQL üçün Percona Serverdə şifrələmənin necə işlədiyinə və MySQL üçün Percona Serverin hansı əlavə xüsusiyyətlərinə daha yaxından nəzər salacağıq.

MySQL açarlığı

Keyring serverə yerli faylda (keyring_file) və ya uzaq serverdə (məsələn, HashiCorp Vault) açarları sorğulamağa, yaratmağa və silməyə imkan verən plaginlərdir. Açarların axtarışını sürətləndirmək üçün həmişə yerli yaddaşda saxlanılır.

Pluginləri iki kateqoriyaya bölmək olar:

• Yerli saxlama. Məsələn, yerli fayl (biz buna fayl əsaslı açar halqası deyirik).
• Uzaqdan saxlama. Məsələn, Vault Server (biz buna server əsaslı açar halqası deyirik).

Bu ayırma vacibdir, çünki müxtəlif saxlama növləri yalnız açarları saxlayarkən və geri götürərkən deyil, həm də onları işə salarkən bir qədər fərqli davranır.

Fayl yaddaşından istifadə edərkən, işə salındıqda yaddaşın bütün məzmunu keşə yüklənir: açar identifikatoru, əsas istifadəçi, açar növü və açarın özü.

Server tərəfində olan mağaza (məsələn, Vault Server kimi) işə salındıqda yalnız açar identifikatoru və əsas istifadəçi yüklənir, ona görə də bütün düymələri əldə etmək başlanğıcı ləngitmir. Açarlar tənbəl şəkildə yüklənir. Yəni açarın özü Vault-dan yalnız həqiqətən lazım olduqda yüklənir. Yükləndikdən sonra açar yaddaşda saxlanır ki, gələcəkdə Vault Serverinə TLS bağlantıları vasitəsilə daxil olmaq lazım deyil. Sonra, əsas mağazada hansı məlumatların olduğuna baxaq.

Əsas məlumatlar aşağıdakıları ehtiva edir:

• açar id — açar identifikatoru, məsələn:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• açar növü — istifadə olunan şifrələmə alqoritminə əsaslanan açar növü, mümkün dəyərlər: “AES”, “RSA” və ya “DSA”.
• açar uzunluğu — baytlarda açar uzunluğu, AES: 16, 24 və ya 32, RSA 128, 256, 512 və DSA 128, 256 və ya 384.
• istifadəçi - açarın sahibi. Açar sistemdirsə, məsələn, Master Açar, onda bu sahə boşdur. Əgər açar keyring_udf vasitəsilə yaradılıbsa, bu sahə açarın sahibini müəyyənləşdirir.
• açarın özü

Açar cütlük tərəfindən unikal şəkildə müəyyən edilir: key_id, user.

Açarların saxlanması və silinməsində də fərqlər var.

Fayl yaddaşı daha sürətlidir. Siz hesab edə bilərsiniz ki, açar mağazası sadəcə olaraq faylın açarını bir dəfə yazır, amma yox, burada daha çox şey var. Fayl yaddaşında dəyişiklik edildikdə, əvvəlcə bütün məzmunun ehtiyat nüsxəsi yaradılır. Tutaq ki, fayl my_biggest_secrets adlanır, onda ehtiyat nüsxəsi my_biggest_secrets.backup olacaq. Sonra, keş dəyişdirilir (açarlar əlavə edilir və ya silinir) və hər şey uğurlu olarsa, keş fayla sıfırlanır. Nadir hallarda, məsələn, server nasazlığı, siz bu ehtiyat faylı görə bilərsiniz. Yedək faylı açarlar növbəti dəfə yükləndikdə silinir (adətən server yenidən işə salındıqdan sonra).

Açarı server anbarında saxlayarkən və ya silərkən yaddaş “açarı göndər” / “açarın silinməsini tələb et” əmrləri ilə MySQL serverinə qoşulmalıdır.

Serverin başlanğıc sürətinə qayıdaq. Başlatma sürətinin kasanın özündən təsirləndiyinə əlavə olaraq, başlanğıc zamanı kassadan neçə açarın götürülməsi lazım olduğu məsələsi də var. Əlbəttə ki, bu, serverin saxlanması üçün xüsusilə vacibdir. Başlanğıcda server şifrələnmiş cədvəllər/masa boşluqları üçün hansı açarın tələb olunduğunu yoxlayır və açarı yaddaşdan tələb edir. Master Açar şifrələməsi olan “təmiz” serverdə yaddaşdan çıxarılmalı olan bir Əsas Açar olmalıdır. Bununla belə, məsələn, ehtiyat server əsas serverdən ehtiyat nüsxəsini bərpa edərkən daha çox sayda açar tələb oluna bilər. Belə hallarda əsas açarın fırlanması təmin edilməlidir. Gələcək məqalələrdə bu barədə daha ətraflı danışılacaq, baxmayaraq ki, burada qeyd etmək istərdim ki, birdən çox Master Açardan istifadə edən serverin işə salınması bir az daha uzun çəkə bilər, xüsusən də server tərəfi açar anbarından istifadə edərkən.

İndi keyring_file haqqında bir az daha danışaq. Keyring_file-ni inkişaf etdirərkən, server işləyərkən keyring_file dəyişikliklərini necə yoxlamaq barədə də narahat idim. 5.7-də yoxlama fayl statistikası əsasında aparıldı, bu ideal həll yolu deyildi və 8.0-da SHA256 yoxlama məbləği ilə əvəz olundu.

keyring_file proqramını ilk dəfə işə saldığınız zaman server tərəfindən yadda qalan fayl statistikası və yoxlama məbləği hesablanır və dəyişikliklər yalnız uyğun olduqda tətbiq edilir. Fayl dəyişdikdə yoxlama məbləği yenilənir.

Biz artıq açar anbarlarla bağlı bir çox sualları əhatə etmişik. Bununla belə, tez-tez unudulan və ya səhv başa düşülən başqa bir vacib mövzu var: açarların serverlər arasında paylaşılması.

Nə demək istəyirəm? Klasterdəki hər bir server (məsələn, Percona Server) Percona Server öz açarlarını saxlamalı olduğu Vault Serverində ayrıca yerə malik olmalıdır. Yaddaşda saxlanılan hər bir Əsas Açar öz identifikatorunda Percona Serverinin GUID-ini ehtiva edir. Niyə vacibdir? Təsəvvür edin ki, sizin yalnız bir Vault Serveriniz var və klasterdəki bütün Percona Serverlər həmin tək Vault Serverindən istifadə edir. Problem aydın görünür. Əgər bütün Percona Serverləri id = 1, id = 2 və s. kimi unikal identifikatorları olmayan Əsas Açardan istifadə edirdisə, onda klasterdəki bütün serverlər eyni Əsas Açardan istifadə edərdilər. GUID-in təmin etdiyi şey serverlər arasında fərqdir. Əgər unikal GUID artıq mövcuddursa, niyə serverlər arasında açarların paylaşılması haqqında danışın? Başqa bir plagin var - keyring_udf. Bu plaginlə server istifadəçiniz açarlarını Vault serverində saxlaya bilər. Problem, məsələn, istifadəçi server1-də açar yaratdıqda və sonra server2-də eyni ID ilə açar yaratmağa çalışdıqda baş verir, məsələn:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Gözləmək. Hər iki server eyni Vault Serverindən istifadə edir, server2-də keyring_key_store funksiyası uğursuz olmamalıdır? Maraqlıdır ki, eyni şeyi bir serverdə etməyə çalışsanız, xəta alacaqsınız:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Düzdür, ROB_1 artıq mövcuddur.

Əvvəlcə ikinci nümunəni müzakirə edək. Daha əvvəl dediyimiz kimi, keyring_vault və ya hər hansı digər açarlıq plagini yaddaşdakı bütün əsas identifikatorları keşləyir. Belə ki, yeni açar yaratdıqdan sonra ROB_1 server1-ə əlavə edilir və bu açarı Vault-a göndərməklə yanaşı, açar da keşə əlavə olunur. İndi eyni açarı ikinci dəfə əlavə etməyə çalışdığımız zaman keyring_vault açarın keşdə olub olmadığını yoxlayır və xəta verir.

Birinci halda vəziyyət fərqlidir. Server1 və server2 ayrıca keşlərə malikdir. ROB_1-i server1 və Vault serverindəki açar keşinə əlavə etdikdən sonra server2-dəki açar keşi sinxronizasiya olunmur. Server2-də keşdə ROB_1 açarı yoxdur. Beləliklə, ROB_1 açarı keyring_key_store və Vault serverinə yazılır ki, bu da əslində əvvəlki dəyərin üzərinə yazır (!). İndi Vault serverində ROB_1 açarı 543210987654321-dir. Maraqlıdır ki, Vault serveri bu cür hərəkətləri bloklamır və asanlıqla köhnə dəyərin üzərinə yazır.

İndi biz Vault-da server bölməsinin niyə vacib ola biləcəyini görə bilərik - keyring_udf istifadə edərkən və açarları Vault-da saxlamaq istədiyiniz zaman. Vault serverində bu ayrılığa necə nail olmaq olar?

Vault-a bölmənin iki yolu var. Siz hər bir server üçün müxtəlif bağlama nöqtələri yarada və ya eyni bağlama nöqtəsində müxtəlif yollardan istifadə edə bilərsiniz. Bu ən yaxşı nümunələrlə təsvir olunur. Beləliklə, əvvəlcə fərdi montaj nöqtələrinə baxaq:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

Burada server1 və server2-nin müxtəlif bağlama nöqtələrindən istifadə etdiyini görə bilərsiniz. Yolları bölərkən konfiqurasiya belə görünəcək:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

Bu halda, hər iki server eyni bağlama nöqtəsi "mount_point", lakin fərqli yollardan istifadə edir. Bu yoldan istifadə edərək server1-də ilk sirri yaratdığınız zaman Vault serveri avtomatik olaraq “server1” kataloqu yaradır. Server2 üçün hər şey oxşardır. Siz mount_point/server1 və ya mount_point/server2-də sonuncu sirri sildiyiniz zaman Vault serveri də həmin qovluqları silir. Yol ayrılmasından istifadə etdiyiniz halda, yalnız bir bağlama nöqtəsi yaratmalı və serverlərin ayrı-ayrı yollardan istifadə etməsi üçün konfiqurasiya fayllarını dəyişdirməlisiniz. Bağlantı nöqtəsi HTTP sorğusu ilə yaradıla bilər. CURL istifadə edərək bunu belə etmək olar:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Bütün sahələr (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) konfiqurasiya faylının parametrlərinə uyğundur. Əlbəttə ki, eyni şeyi etmək üçün Vault yardım proqramlarından istifadə edə bilərsiniz. Ancaq montaj nöqtəsinin yaradılmasını avtomatlaşdırmaq daha asandır. Ümid edirəm ki, bu məlumat sizə faydalı olacaq və bu seriyanın növbəti məqalələrində görüşəcəyik.

Daha çox oxu:

• Sysbench və təsadüfi dəyişənlərin paylanması

Mənbə: www.habr.com