Dina antisipasi mimiti enrollment anyar pikeun kursus kami terus nyebarkeun runtuyan artikel ngeunaan enkripsi dina MySQL.
Dina artikel saméméhna dina séri ieu () urang ngobrol ngeunaan vaults konci. Dina tulisan ieu, urang bakal ningali kumaha konci master dianggo sareng ngabahas kaunggulan sareng kalemahan enkripsi amplop.
Gagasan balik enkripsi amplop nyaéta yén konci anu dianggo pikeun énkripsi (konci tablespace) énkripsi sareng konci anu sanés (konci master). Tombol tablespace sabenerna dipaké pikeun encrypt data. Sacara grafis bisa digambarkeun saperti kieu:
Konci master perenahna di keyring, sarta kenop tablespace aya dina headers tablespace énkripsi (dina kaca 0 tina tablespace nu).
Dina gambar di luhur:
-
Méja A énkripsi ku konci 1 (Konci 1). Konci 1 énkripsi nganggo konci master sareng disimpen énkripsi dina lulugu tabel A.
-
Méja B énkripsi sareng Key 2. Konci 2 énkripsi nganggo konci master (konci masker) sareng disimpen énkripsi dina lulugu tabel B.
-
Jeung saterusna.
Nalika server perlu ngadekrip tabel A, éta retrieves master key ti gudang, maca énkripsi konci 1 ti lulugu tabel A, sarta decrypts konci 1. The decrypted konci 1 ieu sindangan dina mémori server sarta dipaké pikeun ngadekrip tabel A. .
InnoDB
Dina InnoDB, énkripsi sareng dekripsi saleresna dilakukeun dina lapisan I / O. Nyaéta, halaman énkripsi pas sateuacan disiram kana disk sareng didekripsi langsung saatos dibaca tina disk.
Dina InnoDB, enkripsi ngan ukur tiasa dianggo dina tingkat tablespace. Sareng sacara standar, sadaya tabel didamel dina rohangan méja anu misah (). Dina basa sejen, tablespace dijieun nu ngan bisa ngandung hiji méja. Sanajan anjeun bisa nyieun tabel dina tablespace utama ogé (). Tapi dina sagala hal, tabél sok aya di sababaraha tablespace. Sarta saprak enkripsi dilumangsungkeun dina tingkat tablespace, éta boh sagemblengna énkripsi atanapi henteu. Hartina, mustahil mun encrypt ukur bagian tina tabel dina spasi tabel utama.
Upami kusabab sababaraha alesan anjeun gaduh file-per-table ditumpurkeun, teras sadaya tabel didamel di jero rohangan méja sistem. DI anjeun tiasa encrypt sistem tablespace ngagunakeun variabel innodbsysspasi méjaénkripsi atanapi nganggo benang énkripsi, tapi ieu masih mangrupa fitur ékspérimén. MySQL teu gaduh ieu.
Sateuacan urang ngaléngkah, urang kedah ningali struktur ID konci master. Ieu diwangun ku UUID, KUNCIID sareng awalan "INNODBKey". Sigana mah kieu: INNODBKey-UUID-KEYKTP.
UUID nyaéta uuid tina server sareng tablespace énkripsi. KUNCIID ngan saukur hiji nilai kantos-ngaronjatkeun. Nalika nyieun master key KEY pikeun kahiji kalinaID nyaeta 1. Salila rotasi konci, lamun master konci anyar dijieun, konciID = 2 jeung saterusna. Urang bakal ngobrol langkung seueur ngeunaan rotasi konci master dina tulisan salajengna dina séri ieu.
Ayeuna urang terang kumaha identifier konci master, hayu urang tingali header tablespace énkripsi. Nalika tablespace ieu énkripsi, informasi enkripsi ditambahkeun kana lulugu. Sigana mah kieu:
KEY ID nyaeta KEYID ti master key ID kami geus dibahas. UUID nyaéta uuid tina server, anu ogé dianggo dina identifier konci master. TABLESPACE KEY - tombol spasi méja, nu diwangun ku 256 bit dihasilkeun acak ku server. Vektor initialization (IV) ogé diwangun ku 256 bit dihasilkeun acak (sanajan kudu 128 bit). IV dipaké pikeun initialize enkripsi jeung dekripsi AES (tina 256 bit, ngan 128 dipaké). Dina tungtungna aya checksum CRC32 pikeun TABLESPACE KEY sareng IV.
Sadaya waktos ieu kuring nyederhanakeun sakedik ku nyarios yén lulugu ngandung konci énkripsi tina tablespace. Kanyataanna, konci tablespace sareng vektor initialization disimpen sareng énkripsi babarengan nganggo konci master. Émut yén sateuacan énkripsi konci tablespace sareng vektor initialization, CRC32 diitung pikeun aranjeunna.
Naha CRC32 diperyogikeun?
Dina nutshell, pikeun mastikeun validitas konci master. Saatos ngadekrip konci tablespace sareng vektor initialization, checksum diitung sareng dibandingkeun sareng CRC32 anu disimpen dina header. Upami checksums cocog, teras urang gaduh konci master sareng konci tabelspace anu leres. Upami teu kitu, tablespace ditandaan salaku leungit (urang moal bisa ngadekrip eta atoh).
Anjeun tiasa naroskeun: dina waktos naon verifikasi konci dilaksanakeun? Dina jawaban eta lamun server dimimitian. A server kalawan tabel énkripsi / tablespaces berbunyi UUID, KEY di ngamimitianID tina lulugu jeung dibangkitkeun ID konci master. Éta teras kéngingkeun konci master anu diperyogikeun tina keyring, ngadekrip konci tablespace, sareng pariksa checksum. Sakali deui, upami checksum cocog, teras sadayana henteu kunanaon, upami henteu, ruang méja ditandaan leungit.
Lamun maca artikel saméméhna dina séri ieu (), teras anjeun tiasa émut yén nalika nganggo toko konci dumasar-server, server dina ngamimitian ngan ukur nampi daptar idéntifikasi konci, atanapi langkungna, id konci sareng id pangguna, sabab pasangan ieu sacara unik ngaidentipikasi konci éta. Ayeuna kuring nyarios yén nalika server ngamimitian, éta nampi sadaya konci anu diperyogikeun pikeun mariksa yén éta tiasa ngadekrip konci tabel. Janten naha salami inisialisasi, dina kasus neundeun server, ngan ukur konci anu dimuatid jeung pamakéid, sarta teu sakabeh konci? Kusabab anjeun bisa jadi teu butuh kabeh konci. Ieu utamana alatan rotasi konci master. Nalika konci master diputer, konci master anyar dijieun dina kolong, tapi kenop heubeul teu dihapus. Ku kituna, anjeun bisa jadi kudu loba konci dina keystore server nu server teu butuh jeung ku kituna teu dicandak lamun server dimimitian.
Geus waktuna ngobrol saeutik ngeunaan pro jeung kontra enkripsi master konci. Kauntungannana pangbadagna nyaéta yén anjeun ngan butuh hiji konci enkripsi (master key), nu bakal disimpen misah ti data énkripsi Anjeun. Hal ieu ngajadikeun server ngamimitian gancang jeung neundeun leutik, sahingga gampang pikeun ngatur. Sareng ogé konci master tunggal gampang regenerasi.
Sanajan kitu, enkripsi master key boga hiji aral badag: sakali hiji tablespace énkripsi kalawan tablespace_key, éta salawasna tetep énkripsi kalawan konci nu sami. Puteran konci master henteu ngabantosan di dieu. Naha ieu kalemahan? Urang terang yén MySQL gaduh bug anu tiasa nyababkeun kacilakaan ngadadak sareng nyiptakeun file inti. Kusabab file inti ngandung dump memori server, eta bisa lumangsung yén dump ngandung konci tablespace decrypted. Pikeun nyieun masalah parah, kenop tablespace decrypted disimpen dina mémori, nu bisa swapped kana disk. Anjeun tiasa nyarios yén ieu sanés kakurangan sabab anjeun peryogi hak akar pikeun ngaksés file ieu sareng partisi swap. Sumuhun. Tapi akar ngan ukur diperyogikeun sakedap. Sakali batur boga aksés ka konci tablespace decrypted, anjeunna / manehna bisa neruskeun migunakeun eta pikeun ngadekrip data, sanajan tanpa hak husus root. Salaku tambahan, disk tiasa dipaling, sareng partisi swap / file inti tiasa dibaca nganggo alat pihak katilu. Tujuan tina TDE nyaéta sangkan teu kabaca sanajan disk dipaling. DI Kasebut nyaéta dimungkinkeun pikeun ulang encrypt spasi tabel kalawan konci dihasilkeun anyar. Fitur ieu disebut benang énkripsi sareng masih ékspérimén dina waktos nyerat.
Maca deui:
sumber: www.habr.com
