Mã hóa ở trạng thái nghỉ và / hoặc AES_ENCRYPT

Mã hóa ở trạng thái nghỉ

Mã hóa ở trạng thái nghỉ là dữ liệu trong cơ sở dữ liệu khi nó không được sử dụng / truy cập hoặc cập nhật. Mã hóa khi đang di chuyển là những thứ như TLS nơi dữ liệu ( từ cơ sở dữ liệu ) được vận chuyển từ máy chủ đến máy chủ đến trình duyệt, tới máy chủ, tới trình duyệt, v.v. TLS hoàn toàn tốt trong hầu hết các tình huống nếu nó được xử lý cẩn thận và được tiếp cận với thái độ bạn cần làm nhiều hơn mức tối thiểu để thực sự làm cho nó an toàn về mặt thực tế.

Một ví dụ điển hình là mọi người đặt chứng chỉ TLS từ LetsEncrypt trên miền của họ và nghĩ rằng đột nhiên tất cả nội dung của họ đều an toàn; nhưng họ không mã hóa phiên hoặc cookie của họ vì vậy để lại một lỗ hổng lớn tiềm tàng trong hệ thống phòng thủ của họ.

Không sử dụng hệ thống mã hóa tích hợp sẵn của MySQL.

Tôi không thể nhấn mạnh điều này đủ; hệ thống mã hóa tích hợp trong MySQL không phù hợp để bảo vệ dữ liệu an toàn thực tế.

Vui lòng đọc câu trả lời của tôi cho một câu hỏi tương tự tại đây về chi tiết ( Tôi không muốn chỉ sao chép / dán ).

Được rồi, vì bạn nhấn mạnh .... đây:

Từ những gì tôi đã đọc trong nghiên cứu của riêng mình về chủ đề này, liên kết do Magnus cung cấp tới defuse / php -cryption là một trong những cách tốt nhất để ngăn MySQL từng khiến bạn xâm phạm dữ liệu của mình, bằng cách không bao giờ cho phép chương trình / máy chủ MySQL thấy giá trị bản rõ của dữ liệu của bạn.

- Trả lời như đã đăng ngày 7 tháng 5 năm 2017.

Ngoài ra, câu trả lời của Bill Karwin cho cùng một câu hỏi cung cấp một số thông tin chi tiết bổ sung có giá trị:

- Trả lời như đã đăng ngày 7 tháng 5 năm 2017.

Điểm kết thúc:

An ninh rất phức tạp. Nếu bạn muốn làm đúng cách và tự tin vào lớp vỏ hành tây bảo vệ của mình thì bạn cần phải làm rất nhiều thứ (xem phần gạch đầu dòng bên dưới); nhưng điều đầu tiên bạn cần làm là:

• Xác định người mà bạn đang bảo vệ chống lại

Nghiêm túc. Bạn cần các chiến lược khác nhau để chống lại kẻ muốn đánh cắp tên và địa chỉ văn bản rõ ràng của bạn so với kẻ muốn chiếm lấy máy chủ của bạn so với kẻ chỉ muốn dọn sạch dữ liệu chỉ vì. Đó là một huyền thoại rằng bạn có thể bảo vệ chống lại tất cả mọi người mọi lúc, theo quan niệm thì điều này là không thể *; vì vậy, bạn cần xác định những yếu tố gây ảnh hưởng có thể xảy ra nhất và sau đó tìm ra cách tốt nhất để giảm thiểu những tiến bộ của chúng.

Riêng với MySQL, một số khuyến nghị rõ ràng:

• Giữ SQL và PHP trên cùng một máy chủ. Không truy cập từ xa vào dữ liệu MySQL.

• Loại trừ quyền truy cập bên ngoài vào SQL (vì vậy nó là localhost duy nhất)

• Làm xáo trộn tên bảng và tên cột của bạn; nếu ai đó đột nhập vào dữ liệu của bạn và bạn có HDTBJ^BTUETHNUYT dưới cột username thì họ biết rằng có thể đây là tên người dùng nên họ có một khởi đầu rất tốt trong việc cố gắng phá mã hóa của bạn.

• QUAN TRỌNG :Thực sự khóa quyền truy cập vào bảng của bạn; thiết lập rất nhiều người dùng MySQL, mỗi người chỉ có đủ kỹ năng tối thiểu để làm những gì họ cần; bạn muốn người dùng đọc bảng ( chỉ ) và chỉ đọc một số bảng nhất định; người dùng ghi vào các bảng nhất định nhưng không có quyền truy cập vào các bảng khác. Đó là mối quan tâm riêng biệt để nếu bất kỳ người dùng nào trên MySQL bị xâm phạm; bạn đã không tự động mất mọi dữ liệu trong đó.

• Sử dụng các dịch vụ mã hóa PHP. Lưu trữ các khóa Mã hóa ở một nơi hoàn toàn riêng biệt; ví dụ:có một máy chủ khác mà bạn chỉ sử dụng để sao lưu mà bạn có thể truy cập chỉ để tiếp cận lấy các khóa mã hóa, do đó nếu máy chủ PHP / MySQL của bạn bị xâm phạm, bạn có một số chỗ để cắt và khóa máy chủ Khóa để thay thế bạn có thể hạn chế thiệt hại. Nếu máy chủ chính cũng có các bản sao lưu thì bạn thực sự không bị xâm phạm quá nặng ( tùy thuộc vào tình huống ).

• Thiết lập nhiều người theo dõi và người cung cấp thông tin email để cho bạn biết chính xác khi nào các quy trình nhất định đang chạy và người dùng máy chủ nào (không phải mọi người mà là chương trình) đang làm gì. Vì vậy, bạn có thể thấy lý do tại sao một quá trình không mong muốn bắt đầu chạy lúc 5 giờ sáng để thử và đo kích thước của các bảng MySQL. WTF?

• Có rất nhiều khả năng dữ liệu MySQL AES_ENCRYPT của bạn bị "đánh hơi" ngay cả khi nó không nằm yên trong DB, nhưng nếu trang web bị xâm nhập (hoặc tệ hơn là mã PHP không an toàn) thì các cuộc tấn công định thời có thể xảy ra nội dung dữ liệu bằng cách định thời gian tra cứu truy vấn và trả về gói dữ liệu.

• An ninh là một lỗ đen; tại một thời điểm nào đó, bạn sẽ nghĩ rằng "Hãy ngủ đi, tôi đã làm đủ rồi". Không ai có toàn bộ bảo mật, một số tổ chức rất tận tâm có đủ Bảo vệ. Bạn cần tính xem mình sẵn sàng đi bộ bao xa trước khi đi được quãng đường.

* Tại sao không thể? Bởi vì để bảo vệ dữ liệu của bạn khỏi tất cả các mối đe dọa, mọi lúc, nó sẽ cần phải không đọc được, không sử dụng được, giống như một hàm băm. Hàm băm được bảo vệ khỏi mọi người, mọi lúc. Nhưng một hàm băm không bao giờ có thể được hủy băm.