Penyulitan dalam MySQL: Keystore

Dalam menjangkakan permulaan pendaftaran baru untuk kursus "Pangkalan data" menyediakan terjemahan artikel yang berguna untuk anda.

Penyulitan Data Telus (TDE) muncul dalam Pelayan Percona untuk MySQL dan MySQL untuk beberapa lama sekarang. Tetapi pernahkah anda terfikir tentang cara ia berfungsi di bawah hud dan apakah kesan TDE pada pelayan anda? Dalam siri artikel ini, kita akan melihat cara TDE berfungsi secara dalaman. Mari kita mulakan dengan storan kunci, kerana ia diperlukan untuk sebarang penyulitan berfungsi. Kemudian kita akan melihat dengan lebih dekat cara penyulitan berfungsi dalam Pelayan Percona untuk MySQL/MySQL dan apakah ciri tambahan yang tersedia dalam Pelayan Percona untuk MySQL.

MySQL Keyring

Keyrings ialah pemalam yang membenarkan pelayan membuat pertanyaan, mencipta dan memadam kekunci dalam fail setempat (keyring_file) atau pada pelayan jauh (contohnya, dalam HashiCorp Vault). Kekunci sentiasa dicache secara setempat untuk mempercepatkan pengambilan semula.

Plugin boleh dibahagikan kepada dua kategori:

• Storan tempatan. Sebagai contoh, fail tempatan (kami memanggilnya cincin kekunci berasaskan fail).
• storan jauh. Contohnya Pelayan Bilik Kebal (kami memanggilnya cincin kekunci berasaskan pelayan).

Pemisahan ini penting kerana jenis storan berbeza berkelakuan sedikit berbeza bukan sahaja semasa menyimpan dan mendapatkan kunci, tetapi juga apabila ia dimulakan.

Apabila menggunakan storan fail, semua kandungan storan dimuatkan ke dalam cache semasa permulaan: id kunci, pengguna kunci, jenis kunci dan kunci itu sendiri.

Dalam kes kedai bahagian belakang (contohnya, pelayan Vault), hanya id kunci dan pengguna kunci dimuatkan semasa permulaan, jadi mendapatkan semua kunci tidak melambatkan permulaan. Kunci dimuatkan dengan malas. Iaitu, kunci itu sendiri dimuatkan dari Vault hanya apabila ia benar-benar diperlukan. Selepas memuat turun, kunci dicache dalam memori supaya pada masa hadapan tidak perlu mengaksesnya melalui sambungan TLS ke Pelayan Vault. Seterusnya, pertimbangkan maklumat yang terdapat dalam stor kunci.

Maklumat utama mengandungi perkara berikut:

• id kunci - pengecam kunci, contohnya:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• jenis kunci - jenis kunci berdasarkan algoritma penyulitan yang digunakan, nilai yang mungkin: "AES", "RSA" atau "DSA".
• panjang kunci - panjang kunci dalam bait, AES: 16, 24 atau 32, RSA 128, 256, 512 dan DSA 128, 256 atau 384.
• pengguna adalah pemilik kunci. Jika kunci ialah kunci sistem, seperti Kunci Induk, maka medan ini kosong. Jika kunci dibuat menggunakan keyring_udf, maka medan ini menunjukkan pemilik kunci.
• kunci itu sendiri

Kunci dikenal pasti secara unik oleh pasangan: key_id, pengguna.

Terdapat juga perbezaan dalam penyimpanan dan pemadaman kunci.

Penyimpanan fail lebih cepat. Anda mungkin berfikir bahawa stor kunci hanyalah satu kali menulis kunci kepada fail, tetapi tidak - masih banyak lagi perkara yang berlaku di sini. Setiap kali storan fail diubah suai, semua kandungan disandarkan dahulu. Katakan fail itu dipanggil my_biggest_secrets, maka sandaran akan menjadi my_biggest_secrets.backup. Seterusnya, cache ditukar (kunci ditambah atau dialih keluar) dan, jika semuanya berjaya, cache dibuang ke dalam fail. Dalam kes yang jarang berlaku, seperti ranap pelayan, anda mungkin melihat fail sandaran ini. Fail sandaran dipadamkan pada kali seterusnya kekunci dimuatkan (biasanya selepas pelayan dimulakan semula).

Apabila menyimpan atau memadam kunci dalam stor pelayan, kedai mesti menyambung ke pelayan MySQL dengan arahan "hantar kunci" / "minta pemadaman kunci".

Mari kembali ke kelajuan permulaan pelayan. Sebagai tambahan kepada fakta bahawa peti besi itu sendiri mempengaruhi kelajuan permulaan, terdapat juga persoalan tentang berapa banyak kunci dari peti besi yang perlu diperolehi semasa permulaan. Sudah tentu, ini penting terutamanya untuk storan pelayan. Semasa permulaan, pelayan menyemak kunci mana yang diperlukan untuk jadual/ruang meja yang disulitkan dan meminta kunci daripada storan. Pada pelayan "bersih" dengan Kunci Induk - mesti ada satu Kunci Induk untuk penyulitan, yang mesti diambil daripada storan. Walau bagaimanapun, lebih banyak kunci mungkin diperlukan, contohnya, apabila sandaran daripada pelayan utama dipulihkan kepada pelayan siap sedia. Dalam kes sedemikian, putaran Kunci Induk hendaklah disediakan. Ini akan dibincangkan dengan lebih terperinci dalam artikel akan datang, walaupun di sini saya ingin ambil perhatian bahawa pelayan yang menggunakan berbilang Master Keys boleh mengambil sedikit masa lagi untuk bermula, terutamanya apabila menggunakan stor kunci pelayan.

Sekarang mari kita bercakap lebih sedikit tentang keyring_file. Semasa saya mereka bentuk keyring_file, saya juga bimbang tentang cara menyemak perubahan keyring_file semasa pelayan sedang berjalan. Dalam 5.7, semakan telah dilakukan berdasarkan statistik fail, yang tidak sesuai, dan dalam 8.0 ia telah digantikan dengan jumlah semak SHA256.

Kali pertama keyring_file dijalankan, statistik fail dan jumlah semak dikira dan diingati oleh pelayan, dan perubahan digunakan hanya jika ia sepadan. Apabila fail berubah, checksum dikemas kini.

Kami telah membincangkan banyak soalan tentang kedai kunci. Walau bagaimanapun, terdapat satu lagi topik penting yang sering terlupa atau salah faham - berkongsi kunci merentas pelayan.

Apa yang saya maksudkan? Setiap pelayan (contohnya, Pelayan Percona) dalam kluster mesti mempunyai lokasi berasingan pada Pelayan Bilik Kebal di mana Pelayan Percona mesti menyimpan kuncinya. Setiap Kunci Induk yang disimpan dalam peti besi mengandungi GUID Pelayan Percona dalam IDnya. Mengapa ia penting? Bayangkan anda hanya mempunyai satu Pelayan Bilik Kebal dan semua Pelayan Percona dalam kelompok menggunakan Pelayan Bilik Kebal tunggal ini. Masalahnya nampak jelas. Jika semua Pelayan Percona menggunakan Kunci Induk tanpa pengecam unik, seperti id = 1, id = 2, dsb., maka semua pelayan dalam kluster akan menggunakan Kunci Induk yang sama. Inilah yang disediakan oleh GUID - perbezaan antara pelayan. Mengapa kemudian bercakap tentang berkongsi kunci antara pelayan jika sudah ada GUID unik? Terdapat satu lagi pemalam - keyring_udf. Dengan pemalam ini, pengguna pelayan anda boleh menyimpan kunci mereka pada pelayan Vault. Masalah berlaku apabila pengguna mencipta kunci, contohnya, pada pelayan1, dan kemudian cuba mencipta kunci dengan ID yang sama pada pelayan2, contohnya:

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

Tunggu. Kedua-dua pelayan menggunakan Pelayan Bilik Kebal yang sama, bukankah fungsi keyring_key_store sepatutnya gagal pada pelayan2? Menariknya, jika anda cuba melakukan perkara yang sama pada pelayan yang sama, anda akan mendapat ralat:

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

Betul, ROB_1 sudah wujud.

Mari kita bincangkan contoh kedua dahulu. Seperti yang kami katakan sebelum ini, keyring_vault atau mana-mana pemalam peti besi lain (keyring) menyimpan semua ID kunci dalam memori. Jadi, selepas mencipta kunci baharu, ROB_1 ditambahkan pada pelayan1, dan selain menghantar kunci ini ke Bilik Kebal, kunci itu juga ditambahkan pada cache. Sekarang, apabila kami cuba menambah kunci yang sama untuk kali kedua, keyring_vault menyemak sama ada kunci itu wujud dalam cache dan melemparkan ralat.

Dalam kes pertama, keadaannya berbeza. Server1 dan server2 mempunyai cache yang berasingan. Selepas menambahkan ROB_1 pada cache kunci pada pelayan1 dan pelayan Bilik Kebal, cache kunci pada pelayan2 tidak segerak. Cache pada pelayan2 tidak mengandungi kunci ROB_1. Oleh itu, kekunci ROB_1 ditulis pada keyring_key_store dan ke pelayan Vault, yang sebenarnya menimpa (!) nilai sebelumnya. Kini kunci ROB_1 pada pelayan Vault ialah 543210987654321. Menariknya, pelayan Vault tidak menyekat tindakan sedemikian dan dengan mudah menimpa nilai lama.

Sekarang kita melihat sebab pengasingan oleh pelayan dalam Vault boleh menjadi penting apabila anda menggunakan keyring_udf dan ingin menyimpan kunci dalam Vault. Bagaimana untuk menyediakan pemisahan sedemikian dalam pelayan Vault?

Terdapat dua cara untuk membahagikan pada Vault. Anda boleh mencipta titik lekap yang berbeza untuk setiap pelayan, atau menggunakan laluan yang berbeza dalam titik lekap yang sama. Cara terbaik untuk menunjukkan ini adalah dengan contoh. Jadi mari kita lihat titik pelekap individu terlebih dahulu:

--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 = (...)

Di sini anda boleh melihat bahawa pelayan1 dan pelayan2 menggunakan titik lekap yang berbeza. Dengan pemisahan laluan, konfigurasi akan kelihatan seperti ini:

--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 = (...)

Dalam kes ini, kedua-dua pelayan menggunakan titik pelekap yang sama "mount_point" tetapi laluan berbeza. Apabila anda mencipta rahsia pertama pada pelayan1 menggunakan laluan ini, pelayan Vault secara automatik mencipta direktori "pelayan1". Untuk server2, semuanya sama. Apabila anda memadamkan rahsia terakhir dalam mount_point/server1 atau mount_point/server2, pelayan Vault juga memadamkan direktori tersebut. Sekiranya anda menggunakan laluan berpecah, anda mesti mencipta hanya satu titik pelekap dan menukar fail konfigurasi supaya pelayan menggunakan laluan berasingan. Titik pelekap boleh dibuat dengan permintaan HTTP. Dengan CURL ini boleh dilakukan seperti ini:

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

Semua medan (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) sepadan dengan parameter fail konfigurasi. Sudah tentu, anda boleh menggunakan utiliti Vault untuk melakukan perkara yang sama. Tetapi lebih mudah untuk mengautomasikan penciptaan titik pelekap. Saya harap anda mendapati maklumat ini membantu dan jumpa anda dalam artikel seterusnya dalam siri ini.

Baca lebih lanjut:

• Sysbench dan pengedaran pembolehubah rawak

Sumber: www.habr.com