Bảo mật dữ liệu rất quan trọng trong thời kỳ GDPR, PCI DSS hoặc HIPPA. Để tuân thủ các quy định, người ta phải hết sức thận trọng về cách dữ liệu nên được lưu trữ và bảo vệ. Thông thường, dữ liệu có thể ở trạng thái nghỉ hoặc đang chuyển. Dữ liệu đang chuyển là dữ liệu được chuyển từ hoặc đến cơ sở dữ liệu. Kết quả truy vấn được gửi đến máy khách hoặc ứng dụng hoặc dữ liệu được sao chép giữa các nút của cụm là ví dụ về các trường hợp khi dữ liệu đang được truyền. Chúng tôi có xu hướng bảo mật dữ liệu ở trạng thái đó bằng cách sử dụng SSL hoặc TLS - các kết nối được mã hóa giữa các nút cơ sở dữ liệu hoặc cơ sở dữ liệu và ứng dụng khách.
Ở phía bên kia của quang phổ, chúng tôi có dữ liệu ở trạng thái nghỉ - chúng tôi có thể nói rằng hầu hết dữ liệu, tại thời điểm nhất định, ở trạng thái nghỉ. Chúng ta đang nói ở đây về dữ liệu được lưu trữ trên đĩa trong không gian bảng, cấu trúc dữ liệu khác nhau (bộ đệm gcache, nhật ký làm lại) và nhật ký (nhật ký nhị phân và chuyển tiếp). Hãy xem xét những điều cần cân nhắc xung quanh chủ đề này trong MariaDB.
Mã hóa gì trong MariaDB?
Tốt nhất, bạn cần mã hóa mọi thứ. Cơ sở dữ liệu lưu trữ dữ liệu ở những nơi khác nhau và những cách khác nhau, như đã đề cập ở trên. Tập dữ liệu lớn nhất được lưu trữ trong không gian bảng - đây là vị trí "cuối cùng" nơi dữ liệu được lưu trữ. Rõ ràng, có thể mã hóa không gian bảng - nếu không, toàn bộ tính năng sẽ trở nên vô nghĩa. MariaDB có thể lưu trữ dữ liệu trong một không gian bảng dùng chung, một vài trong số chúng hoặc mọi bảng có thể được lưu trữ trong một không gian bảng riêng biệt - tất cả các kịch bản đó đều được hỗ trợ. Người dùng có một số mức độ linh hoạt khi chọn nội dung để mã hóa. Bạn có thể mã hóa mọi thứ, các bảng riêng lẻ hoặc mọi thứ ngoại trừ một số bảng riêng lẻ.
MariaDB InnoDB làm lại nhật ký
Một cấu trúc khác lưu trữ dữ liệu là InnoDB redo log. Nhật ký làm lại InnoDB là nơi dữ liệu được ghi sau khi một hàng nhất định đã được nâng cấp. Dữ liệu từ nhật ký làm lại cuối cùng sẽ được chuyển sang không gian bảng nhưng trong một thời gian, nhật ký làm lại InnoDB chứa tất cả các sửa đổi đã xảy ra gần đây. Như bạn có thể tưởng tượng, dữ liệu này cũng rất quan trọng và cần được bảo vệ - MariaDB cho phép bạn mã hóa nhật ký làm lại InnoDB.
MariaDB Nhật ký nhị phân
Nhật ký nhị phân (cũng như nhật ký chuyển tiếp) lưu trữ thông tin về các truy vấn được thực thi để sửa đổi dữ liệu. Vì thông tin được bao gồm cho phép chúng tôi tạo lại trạng thái hiện tại của hàng đã trải qua sửa đổi, đây là một dạng dữ liệu khác cần được bảo vệ và mã hóa. Cả nhật ký nhị phân và nhật ký chuyển tiếp đều có thể được mã hóa trong MariaDB.
Bộ nhớ đệm Galera
Galera cache (gcache) là một bộ đệm trên đĩa trong Galera Cluster lưu trữ thông tin về các sửa đổi đã thực thi. Nó được sử dụng trong trường hợp lỗi nút hoặc sự cố mạng tạm thời để cho phép các nút tham gia cụm bắt kịp chỉ bằng dữ liệu mà chúng bị thiếu, tránh chuyển toàn bộ tập dữ liệu. Tương tự như nhật ký nhị phân hoặc nhật ký làm lại, gcache chứa danh sách các sửa đổi và như vậy, nó có thể được sử dụng để khôi phục và ghép các phần dữ liệu lại với nhau. Trong phiên bản cộng đồng của MariaDB Galera Cluster, gcache không thể được mã hóa. Tùy chọn như vậy có sẵn trong phiên bản Doanh nghiệp của MariaDB Galera Cluster.
Điều gì không thể được mã hóa trong MariaDB?
Vẫn còn một số nơi mà các phần dữ liệu có thể hiển thị mà không thể được mã hóa, ít nhất là cho đến thời điểm hiện tại, trong MariaDB. Thứ nhất, nhật ký lỗi có thể chứa các mẫu truy vấn có khả năng làm lộ một số dữ liệu. Không thể mã hóa nhật ký lỗi, nhưng có thể chuyển hướng nhật ký lỗi đến nhật ký hệ thống và thực hiện một số cơ chế bảo vệ bên ngoài MariaDB.
Nhật ký từ Trình cắm Kiểm tra
Audit Plugin cũng tạo nhật ký - nhật ký này có thể chứa thông tin nhạy cảm, bao gồm các truy vấn chính xác đã được thực thi trên cơ sở dữ liệu. Không thể mã hóa nhật ký này, nhưng nó có thể được chuyển hướng đến nhật ký hệ thống và mã hóa ở đó.
Nhật ký Truy vấn
Nhật ký truy vấn chung và chậm - những nhật ký đó sẽ chứa các truy vấn (hoặc ít nhất là các mẫu của chúng) đã được MariaDB thực thi. Hiện tại, không thể mã hóa các nhật ký đó.
Vùng đệm InnoDB
Bộ nhớ - MariaDB chỉ thực hiện mã hóa cho các trang được lưu trữ trên đĩa. Tất cả dữ liệu được lưu trữ trong vùng đệm InnoDB sẽ không được mã hóa. Vùng đệm InnoDB được thiết kế để giữ các hàng được sửa đổi hoặc truy cập gần đây bằng truy vấn SELECT - những hàng đó rõ ràng sẽ chứa các mẫu dữ liệu. Hiện tại, không có tùy chọn nào để mã hóa vùng đệm InnoDB trong MariaDB. Hãy nhớ rằng một người sẽ yêu cầu quyền truy cập vào hệ thống để đọc bộ nhớ trực tiếp. Đó không phải là một nhiệm vụ tầm thường, mặc dù nó không phải là không thể hoàn thành.
Xin lưu ý rằng chúng tôi đã đề cập đến các tùy chọn mã hóa có trong MariaDB. Luôn có khả năng sử dụng một lớp mã hóa khác. Ví dụ:mã hóa toàn bộ bộ nhớ sẽ hiển thị các bản ghi không thể đọc được đối với bất kỳ ai có quyền truy cập vật lý vào đĩa. Mặt khác, nó sẽ không bảo vệ dữ liệu khỏi những người có thể đăng nhập vào hệ thống.
Khả năng tương thích với các công cụ bên ngoài
Một điều khác cần xem xét là khả năng tương thích. Nếu bạn quyết định mã hóa MariaDB của mình, bạn phải lưu ý rằng điều này có thể ảnh hưởng đến cách bạn hoạt động. Không thể sử dụng các công cụ bên ngoài như XtraBackup hoặc mysqlbinlog để xử lý dữ liệu và tạo bản sao lưu hoặc xử lý các bản ghi nhị phân. Bạn sẽ phải gắn bó với các công cụ được tạo bởi MariaDB (như Mariabackup), được viết với cơ chế mã hóa. Họ có thể xử lý dữ liệu khi mã hóa còn lại được triển khai trong MariaDB.
Lập kế hoạch cho Quy trình Mã hóa
Phần này sẽ không thảo luận chi tiết về quy trình, nhưng nó xem xét những gì bạn nên cân nhắc khi lập kế hoạch mã hóa, chẳng hạn như tài nguyên và thời gian. Việc sử dụng CPU cũng như hoạt động I / O sẽ tăng lên trong suốt quá trình. Từ quan điểm của người dùng, tất cả đều phụ thuộc vào cài đặt cấu hình và sau đó thực hiện các lệnh ALTER để xây dựng lại và mã hóa các bảng hiện có. Đối với các cơ sở dữ liệu lớn, chỉ riêng điều này đã có thể là một thách thức đáng kể đòi hỏi phải lập kế hoạch. Thay đổi giản đồ có thể là một gánh nặng nghiêm trọng và bạn nên sử dụng các công cụ như pt-online-schema-change để giảm tác động của chúng lên hệ thống sản xuất và kiểm soát tốt hơn quy trình.
Lời kết
Như chúng tôi đã đề cập, dữ liệu rất quan trọng đối với tất cả các tổ chức và điều quan trọng là đảm bảo dữ liệu được an toàn và được bảo vệ. Mã hóa dữ liệu ở trạng thái còn lại là một trong những yếu tố quan trọng trong toàn bộ bức tranh. Chúng tôi rất muốn nghe ý kiến của bạn về trải nghiệm của bạn với việc mã hóa dữ liệu ở chế độ nghỉ trong MariaDB. Nếu bạn muốn chia sẻ suy nghĩ của mình, bạn có thể để lại bình luận bên dưới.
