MySQL'de Şifreleme: Ana Anahtarı Kullanma

Kurs için yeni bir kaydın başlaması beklentisiyle "Veri tabanı" MySQL'de şifreleme hakkında bir dizi makale yayınlamaya devam ediyoruz.

Bu dizinin önceki makalesinde (MySQL'de Şifreleme: Anahtar Deposu) anahtar depolarından bahsettik. Bu yazıda, ana anahtarın nasıl kullanıldığına bakacağız ve zarf şifrelemenin avantajlarını ve dezavantajlarını tartışacağız. 

Zarf şifrelemenin arkasındaki fikir, şifreleme için kullanılan anahtarların (tablo alanı anahtarları) başka bir anahtarla (ana anahtar) şifrelenmesidir. Tablo alanı anahtarları aslında verileri şifrelemek için kullanılır. Grafiksel olarak, bu aşağıdaki gibi temsil edilebilir:

Ana anahtar, anahtar deposundadır ve tablo alanı anahtarları, şifrelenmiş tablo alanlarının başlıklarındadır (tablo alanının 0. sayfasında). 

Yukarıdaki resimde:

• Tablo A, anahtar 1 (Anahtar 1) ile şifrelenir. Anahtar 1, ana anahtar kullanılarak şifrelenir ve tablo A'nın başlığında şifrelenmiş olarak saklanır.

• Tablo B, anahtar 2 (Anahtar 2) ile şifrelenir. Anahtar 2, maskeleyici anahtar kullanılarak şifrelenir ve tablo B'nin başlığında şifrelenmiş olarak saklanır.

• Ve böyle devam eder.

Sunucunun A tablosunun şifresini çözmesi gerektiğinde, depodan ana anahtarı alır, A tablosunun başlığından şifrelenmiş 1. anahtarı okur ve 1. anahtarın şifresini çözer. Şifresi çözülmüş 1. anahtar, sunucunun belleğinde önbelleğe alınır ve A tablosunun şifresini çözmek için kullanılır. .

InnoDB'nin

InnoDB'de gerçek şifreleme ve şifre çözme, G/Ç düzeyinde yapılır. Yani, sayfa diske aktarılmadan hemen önce şifrelenir ve diskten okunduktan hemen sonra şifresi çözülür.

InnoDB'de şifreleme yalnızca tablo alanı düzeyinde çalışır. Ve varsayılan olarak tüm tablolar ayrı tablo alanlarında oluşturulur (tablo başına dosya tablo alanı). Başka bir deyişle, yalnızca bir tablo içerebilen bir tablo alanı oluşturulur. Ana tablo alanında da tablolar oluşturabilmenize rağmen (genel tablo alanı). Ancak her durumda, tablo her zaman bir tablo alanındadır. Ve şifreleme tablo alanı seviyesinde yapıldığından ya tamamen şifrelenir ya da şifrelenmez. Yani ana tablo alanındaki tabloların sadece bir kısmını şifreleyemezsiniz. 

Herhangi bir nedenle tablo başına dosya seçeneğini devre dışı bıraktıysanız, tüm tablolar sistem tablo alanı içinde oluşturulur. İÇİNDE MySQL için Percona Sunucusu innodb değişkenini kullanarak sistem tablo alanını şifreleyebilirsiniz.systablo alanışifreleme veya şifreleme dizileri kullanma, ancak bu hala deneysel bir özelliktir. MySQL'de buna sahip değil.

Devam etmeden önce, ana anahtar kimliğinin yapısını ele almamız gerekiyor. UUID, KEY'den oluşurKimlik ve önek "INNODBKey". Şuna benzer: INNODBKey-UUID-KEYKimliği.

UUID, şifrelenmiş tablo alanına sahip sunucunun uuid'sidir. anahtarKimlik sadece sürekli artan bir değerdir. İlk kez bir ana anahtar oluşturduğunuzda KEYKimlik 1'dir. Anahtar döndürme sırasında, yeni bir ana anahtar oluşturulduğunda, ANAHTARKimlik = 2 vb. Bu dizinin sonraki makalelerinde ana anahtar döndürme hakkında daha fazla konuşacağız.

Artık ana anahtar tanımlayıcısının neye benzediğini bildiğimize göre, şifrelenmiş tablo alanının başlığına bakalım. Bir tablo alanı şifrelendiğinde, şifreleme bilgisi başlığa eklenir. Şuna benziyor:

KEYID, ANAHTAR'dırDaha önce tartıştığımız ana anahtar kimliğinin kimliği. UUID, sunucunun uuid'sidir ve ana anahtar tanımlayıcısında da kullanılır. TABLESPACE KEY - sunucu tarafından rastgele oluşturulmuş 256 bitten oluşan tablo alanı anahtarı. Başlatma vektörü (IV, başlatma vektörü) ayrıca rastgele oluşturulmuş 256 bitten oluşur (ancak 128 bit olmalıdır). IV, AES şifrelemesini ve şifre çözmeyi başlatmak için kullanılır (256 bitten yalnızca 128'i kullanılır). Sonunda TABLESPACE KEY ve IV için bir CRC32 sağlama toplamı vardır.

Bunca zaman başlıkta şifreli bir tablo alanı anahtarı olduğunu söyleyerek biraz basitleştirdim. Aslında, tablo alanı anahtarı ve başlatma vektörü, ana anahtar kullanılarak birlikte saklanır ve şifrelenir. Tablo alanı anahtarı ve başlatma vektörü şifrelenmeden önce onlar için CRC32'nin hesaplandığını unutmayın.

CRC32 neden gereklidir?

Özetle, ana anahtarın geçerliliğini doğrulamak için. Tablo alanı anahtarının ve başlatma vektörünün şifresi çözüldükten sonra, bir sağlama toplamı hesaplanır ve başlıkta saklanan CRC32 ile karşılaştırılır. Sağlama toplamları eşleşirse, doğru ana anahtara ve tablo alanı anahtarına sahibiz. Aksi takdirde, tablo alanı eksik olarak işaretlenir (yine de şifresini çözemeyiz).

Şunu sorabilirsiniz: anahtarların doğrulanması hangi noktada gerçekleştirilir? Cevap, sunucunun ne zaman başladığıdır. Şifreli tablolara / tablo alanlarına sahip sunucu başlangıçta UUID, KEY okurBaşlıktan kimlik ve bir ana anahtar kimliği oluşturur. Daha sonra gerekli ana anahtarı anahtarlıktan alır, tablo alanı anahtarının şifresini çözer ve sağlama toplamını doğrular. Bir kez daha, sağlama toplamı eşleşirse, o zaman her şey yolundadır, hayır - tablo alanı eksik olarak işaretlenir.

Bu serideki son makaleyi okursanız (MySQL'de Şifreleme: Anahtar Deposu), o zaman belki bir sunucu anahtar deposu kullanırken, sunucunun yalnızca başlangıçta anahtar tanımlayıcıların bir listesini, daha kesin olarak anahtar kimliği ve kullanıcı kimliğini aldığını unutmayın, çünkü bu çift anahtarı benzersiz bir şekilde tanımlar. Şimdi söylediğim şey, sunucu başlangıçta tablo alanı anahtarlarının şifresinin çözülüp çözülemeyeceğini kontrol etmek için ihtiyaç duyduğu tüm anahtarları aldığıdır. Öyleyse, sunucu depolaması durumunda başlatma sırasında neden yalnızca anahtar yüklenir?kimlik ve kullanıcıkimlik ve tüm anahtarlar değil mi? Çünkü tüm anahtarlara ihtiyacınız olmayabilir. Bunun başlıca nedeni ana anahtarın dönüşüdür. Kasada bir ana anahtar döndürüldüğünde, yeni bir ana anahtar oluşturulur ancak eski anahtarlar silinmez. Bu nedenle, sunucunun anahtar deposunda, sunucunun ihtiyaç duymadığı ve bu nedenle sunucu başladığında alınmayan birçok anahtarınız olabilir.

Bir ana anahtar kullanarak şifrelemenin avantajları ve dezavantajları hakkında biraz konuşmanın zamanı geldi. En büyük avantaj, şifrelenmiş verilerinizden ayrı tutulacak yalnızca bir şifreleme anahtarına (ana anahtar) ihtiyacınız olmasıdır. Bu, sunucu başlatma işlemini hızlandırır ve depolamayı küçük hale getirerek yönetimi kolaylaştırır. Ayrıca tek ana anahtarın yeniden oluşturulması kolaydır.

Bununla birlikte, ana anahtar şifrelemenin büyük bir dezavantajı vardır: bir tablo alanı, bir kez tablespace_key ile şifrelendiğinde, her zaman aynı anahtarla şifrelenmiş olarak kalır. Ana anahtar döndürme burada yardımcı olmuyor. Bu neden bir dezavantaj? MySQL'in çökmesine ve bir çekirdek dosya oluşturmasına neden olabilecek hatalara sahip olduğunu biliyoruz. Çekirdek dosya bir sunucu bellek dökümü içerdiğinden, dökümün şifresi çözülmüş tablo alanı anahtarı içermesi mümkündür. Daha da kötüsü, şifresi çözülmüş tablo alanı anahtarları, diske değiştirilebilen bellekte saklanır. Bu dosyalara ve takas bölümüne erişmek için kök izinlerine ihtiyacınız olduğundan bunun bir dezavantaj olmadığını söyleyebilirsiniz. Evet. Ancak kök yalnızca bir süre için gereklidir. Birisi şifresi çözülmüş tablo alanı anahtarına eriştiğinde, root erişimi olmadan bile verilerin şifresini çözmek için kullanmaya devam edebilir. Ayrıca disk çalınabilir ve takas / çekirdek dosyaları üçüncü taraf araçlar kullanılarak okunabilir. TDE'nin amacı, disk çalınsa bile okunamaz hale getirmektir. İÇİNDE MySQL için Percona Sunucusu tablo alanını yeni oluşturulan anahtarlarla yeniden şifrelemek mümkündür. Bu özellik şifreleme dizileri olarak adlandırılır ve bu yazı yazıldığı sırada hala deneyseldir.

Kurs hakkında daha fazla bilgi edinin

Daha fazla oku:

• MySQL'de Şifreleme: Anahtar Deposu

Kaynak: habr.com