Enkripsi di MySQL: Master Key Rotation

Untuk mengantisipasi dimulainya pendaftaran baru untuk kursus "basis data" kami terus menerbitkan serangkaian artikel tentang enkripsi di MySQL.

Pada artikel sebelumnya di seri ini, kita telah membahasnya cara kerja enkripsi kunci utama. Hari ini, berdasarkan pengetahuan yang didapat sebelumnya, mari kita lihat rotasi kunci utama.

Rotasi kunci master melibatkan pembuatan kunci master baru dan mengenkripsi ulang kunci tablespace (yang disimpan di header tablespace) dengan kunci baru ini.

Mari kita ingat seperti apa header dari tablespace terenkripsi:

Enkripsi di MySQL: Master Key Rotation

Dari artikel sebelumnya, kita tahu bahwa server membaca header dari semua tablespace terenkripsi saat startup dan mengingat KEY ID terbesar. Misalnya jika kita memiliki tiga tabel dengan KEYID = 3 dan satu tabel dengan KEYID = 4, maka ID kunci maksimum adalah 4. Sebut saja KEY ID ini - MAX KEY ID.

Cara kerja rotasi kunci utama

1. Pengguna menjalankan ALTER INNODB MASTER KEY.

2. Server meminta keyring untuk membuat kunci master baru dengan UUID dan KEY serverID sama dengan satu ditambah MAXKUNCIPENGENAL. Jadi kami mendapatkan id kunci master sama dengan INNODBKEY-UUID-(MAXKUNCItanda pengenal + 1). Setelah pembuatan master key berhasil, MAX KEY ID bertambah satu (yaitu MAXKUNCIID=MAXKUNCItanda pengenal + 1).

3. Server memindai semua tablespace yang dienkripsi dengan kunci master, dan untuk setiap tablespace:

  • mengenkripsi kunci tablespace dengan kunci master baru;

  • perbarui id kunci ke MAX baruKUNCIINDO;

  • jika UUID berbeda dengan UUID server, maka perbarui UUID server.

Seperti yang kita ketahui, Master Key ID yang digunakan untuk mendekripsi tabel terdiri dari UUID dan KEY ID yang dibaca dari tablespace header. Apa yang kami lakukan sekarang adalah memperbarui informasi ini di header enkripsi tablespace sehingga server menerima kunci master yang benar.

Jika kita memiliki tablespace dari lokasi yang berbeda, seperti backup yang berbeda, maka mereka mungkin menggunakan kunci master yang berbeda. Semua kunci master ini perlu diambil dari repositori saat server dimulai. Ini dapat memperlambat startup server, terutama jika penyimpanan kunci sisi server digunakan. Dengan rotasi kunci master, kami mengenkripsi ulang kunci tablespace dengan kunci master tunggal yang sama untuk semua tablespace. Server sekarang seharusnya hanya menerima satu kunci master saat startup.

Ini, tentu saja, hanyalah efek samping yang menyenangkan. Tujuan utama rotasi master key adalah untuk membuat server kita lebih aman. Jika kunci master entah bagaimana dicuri dari lemari besi (misalnya, dari Server Vault), dimungkinkan untuk membuat kunci master baru dan mengenkripsi ulang kunci tablespace, membatalkan kunci yang dicuri. Kami aman... hampir.

Di artikel sebelumnya, saya berbicara tentang bagaimana kunci tablespace dicuri, pihak ketiga dapat menggunakannya untuk mendekripsi data. Asalkan ada akses ke disk kita. Jika kunci master dicuri dan Anda memiliki akses ke data yang dienkripsi, Anda dapat menggunakan kunci master yang dicuri untuk mendekripsi kunci tablespace dan mendapatkan data yang didekripsi. Seperti yang Anda lihat, rotasi kunci master tidak membantu dalam kasus ini. Kami mengenkripsi ulang kunci tablespace dengan kunci master baru, tetapi kunci aktual yang digunakan untuk mengenkripsi/mendekripsi data tetap sama. Oleh karena itu, "peretas" dapat terus menggunakannya untuk mendekripsi data. Sebelumnya saya mengisyaratkan itu Server Percona untuk MySQL dapat melakukan enkripsi ulang tablespace yang sebenarnya, bukan hanya enkripsi ulang kunci tablespace sederhana. Fitur ini disebut utas enkripsi. Namun, fungsi ini masih eksperimental saat ini.

Rotasi kunci master berguna saat kunci master dicuri, tetapi tidak ada cara bagi penyerang untuk menggunakannya dan mendekripsi kunci tablespace.

Mendaftar untuk pelajaran demo gratis.

Baca selengkapnya:

Sumber: www.habr.com