Dự đoán về việc bắt đầu tuyển sinh mới cho khóa học chúng tôi tiếp tục xuất bản một loạt bài viết về mã hóa trong MySQL.
Trong bài viết trước của loạt bài này () chúng tôi đã nói về kho khóa. Trong bài viết này, chúng ta sẽ xem xét cách sử dụng khóa chính và thảo luận về những ưu điểm và nhược điểm của mã hóa phong bì.
Ý tưởng đằng sau mã hóa phong bì là các khóa được sử dụng để mã hóa (các khóa không gian bảng) được mã hóa bằng một khóa khác (khóa chính). Các khóa không gian bảng thực sự được sử dụng để mã hóa dữ liệu. Về mặt đồ họa, điều này có thể được biểu diễn như sau:
Khóa chính nằm trong kho khóa và các khóa của vùng bảng nằm trong tiêu đề của vùng bảng được mã hóa (trên trang 0 của vùng bảng).
Trong hình trên:
-
Bảng A được mã hóa bằng khóa 1 (Key 1). Khóa 1 được mã hóa bằng khóa chính và được mã hóa lưu trữ trong tiêu đề của bảng A.
-
Bảng B được mã hóa bằng khóa 2 (Key 2). Khóa 2 được mã hóa bằng khóa mặt nạ và được mã hóa lưu trữ trong tiêu đề của bảng B.
-
Và như vậy.
Khi máy chủ cần giải mã bảng A, nó sẽ lấy khóa chính từ cửa hàng, đọc khóa mã hóa 1 từ tiêu đề của bảng A và giải mã khóa 1. Khóa giải mã 1 được lưu trong bộ nhớ của máy chủ và được sử dụng để giải mã bảng A .
InnoDB
Trong InnoDB, việc mã hóa và giải mã thực sự được thực hiện ở cấp độ I/O. Nghĩa là, trang được mã hóa ngay trước khi nó được chuyển sang đĩa và được giải mã ngay sau khi được đọc từ đĩa.
Trong InnoDB, mã hóa chỉ hoạt động ở cấp vùng bảng. Và theo mặc định, tất cả các bảng được tạo trong các không gian bảng riêng biệt (). Nói cách khác, một vùng bảng được tạo chỉ có thể chứa một bảng. Mặc dù bạn cũng có thể tạo các bảng trong không gian bảng chính (). Nhưng trong mọi trường hợp, bảng luôn nằm trong một vùng bảng nào đó. Và vì mã hóa được thực hiện ở cấp vùng bảng, nên nó có được mã hóa hoàn toàn hay không. Nghĩa là, bạn không thể chỉ mã hóa một phần của các bảng trong không gian bảng chính.
Nếu vì lý do nào đó bạn đã vô hiệu hóa tệp trên mỗi bảng, thì tất cả các bảng được tạo bên trong không gian bảng hệ thống. TRONG bạn có thể mã hóa không gian bảng hệ thống bằng biến innodbhệ thốngkhông gian bảngmã hóa hoặc sử dụng chuỗi mã hóa, nhưng đây vẫn là một tính năng thử nghiệm. MySQL không có cái này.
Trước khi tiếp tục, chúng ta cần xem xét cấu trúc của ID khóa chính. Nó bao gồm UUID, KEYID và tiền tố "INNODBKey". Nó trông như thế này: INNODBKey-UUID-KEYTÔI.
UUID là uuid của máy chủ với không gian bảng được mã hóa. chìa khóaID chỉ là một giá trị ngày càng tăng. Khi bạn lần đầu tạo khóa chính KEYID là 1. Trong khi xoay khóa, khi khóa chính mới được tạo, KEYID = 2, v.v. Chúng ta sẽ nói nhiều hơn về xoay phím chính trong các bài viết sau của loạt bài này.
Bây giờ chúng ta đã biết mã định danh khóa chính trông như thế nào, hãy xem tiêu đề của không gian bảng được mã hóa. Khi một vùng bảng được mã hóa, thông tin mã hóa được thêm vào tiêu đề. Nó trông như thế này:
KEYID là KHÓAID từ ID khóa chính mà chúng ta đã thảo luận. UUID là uuid của máy chủ và cũng được sử dụng trong mã định danh khóa chính. TABLESPACE KEY - khóa không gian bảng, bao gồm 256 bit, do máy chủ tạo ngẫu nhiên. Vectơ khởi tạo (IV, vectơ khởi tạo) cũng bao gồm 256 bit được tạo ngẫu nhiên (mặc dù nó phải là 128 bit). IV được sử dụng để khởi tạo mã hóa và giải mã AES (trong số 256 bit, chỉ có 128 bit được sử dụng). Cuối cùng, có tổng kiểm tra CRC32 cho TABLESPACE KEY và IV.
Lúc này tôi đã đơn giản hóa một chút bằng cách nói rằng có một khóa không gian bảng được mã hóa trong tiêu đề. Trên thực tế, khóa vùng bảng và vectơ khởi tạo được lưu trữ và mã hóa cùng nhau bằng khóa chính. Hãy nhớ rằng trước khi khóa vùng bảng và vectơ khởi tạo được mã hóa, CRC32 được tính toán cho chúng.
Tại sao cần CRC32?
Tóm lại, để đảm bảo khóa chính hợp lệ. Sau khi giải mã khóa vùng bảng và vectơ khởi tạo, tổng kiểm tra được tính toán và so sánh với CRC32 được lưu trữ trong tiêu đề. Nếu tổng kiểm tra khớp, thì chúng ta có khóa chính và khóa không gian bảng chính xác. Mặt khác, không gian bảng được đánh dấu là bị thiếu (chúng tôi vẫn không thể giải mã nó).
Bạn có thể hỏi: việc xác minh khóa được thực hiện vào thời điểm nào? Câu trả lời là khi máy chủ khởi động. Máy chủ có bảng/không gian bảng được mã hóa đọc UUID, KEY khi khởi độngID từ tiêu đề và tạo ID khóa chính. Sau đó, nó lấy khóa chính được yêu cầu từ khóa, giải mã khóa vùng bảng và xác minh tổng kiểm tra. Một lần nữa, nếu tổng kiểm tra khớp, thì mọi thứ đều theo thứ tự, không - không gian bảng được đánh dấu là bị thiếu.
Nếu bạn đọc bài viết cuối cùng trong loạt bài này (), thì có lẽ hãy nhớ rằng khi sử dụng kho lưu trữ khóa của máy chủ, máy chủ chỉ nhận được danh sách các mã định danh khóa khi khởi động, chính xác hơn là id khóa và id người dùng, vì cặp này xác định khóa duy nhất. Điều tôi đang nói bây giờ là máy chủ, khi khởi động, sẽ nhận được tất cả các khóa mà nó cần để kiểm tra xem các khóa của vùng bảng có thể được giải mã hay không. Vậy tại sao khi khởi tạo, trong trường hợp lưu trữ máy chủ, chỉ có key được tảiid và người dùngid và không phải tất cả các khóa? Bởi vì bạn có thể không cần tất cả các phím. Điều này chủ yếu là do vòng quay của phím chính. Khi một khóa chính được xoay trong vault, một khóa chính mới sẽ được tạo nhưng các khóa cũ sẽ không bị xóa. Do đó, bạn có thể có nhiều khóa trong kho khóa của máy chủ mà máy chủ không cần đến và do đó không được truy xuất khi máy chủ khởi động.
Đã đến lúc nói một chút về những ưu điểm và nhược điểm của việc mã hóa bằng khóa chính. Ưu điểm lớn nhất là bạn chỉ cần một khóa mã hóa (khóa chính), khóa này sẽ được tách biệt khỏi dữ liệu được mã hóa của bạn. Điều này giúp máy chủ khởi động nhanh và dung lượng lưu trữ nhỏ, giúp dễ dàng quản lý. Và cũng là khóa chính duy nhất dễ dàng tạo lại.
Tuy nhiên, mã hóa khóa chính có một nhược điểm lớn: một khi vùng bảng được mã hóa bằng tablespace_key, nó sẽ luôn được mã hóa bằng cùng một khóa. Xoay phím chính không giúp được gì ở đây. Tại sao đây là một bất lợi? Chúng tôi biết rằng MySQL có các lỗi có thể khiến nó bị sập và tạo tệp lõi. Vì tệp lõi chứa kết xuất bộ nhớ máy chủ nên có thể xảy ra trường hợp kết xuất chứa khóa không gian bảng được giải mã. Tệ hơn nữa, các khóa không gian bảng được giải mã được lưu trữ trong bộ nhớ, có thể được hoán đổi vào đĩa. Bạn có thể nói rằng đây không phải là bất lợi vì bạn cần có quyền root để truy cập các tệp này và phân vùng trao đổi. Đúng. Nhưng root chỉ cần thiết trong một thời gian. Sau khi ai đó có quyền truy cập vào khóa vùng bảng được giải mã, họ có thể tiếp tục sử dụng nó để giải mã dữ liệu, ngay cả khi không có quyền truy cập root. Ngoài ra, đĩa có thể bị đánh cắp và các tệp hoán đổi / lõi có thể được đọc bằng các công cụ của bên thứ ba. Mục tiêu của TDE là làm cho nó không thể đọc được ngay cả khi đĩa bị đánh cắp. TRONG có thể mã hóa lại không gian bảng bằng các khóa mới được tạo. Tính năng này được gọi là chuỗi mã hóa và vẫn đang thử nghiệm tại thời điểm viết bài này.
Đọc thêm:
Nguồn: www.habr.com