Quản lý khóa và mã hóa MySQL


10

Tôi đang phát triển một hệ thống mạng nội bộ cục bộ trong PHP / MySQL để quản lý dữ liệu khách hàng của chúng tôi. Có vẻ như cách tốt nhất là mã hóa dữ liệu nhạy cảm trên máy chủ MySQL khi nó đang được nhập.

Tuy nhiên, tôi không rõ ràng về cách tốt nhất để làm điều này trong khi vẫn có thể truy cập dữ liệu.

Có vẻ như một câu hỏi khó trả lời: chìa khóa được lưu trữ ở đâu? Làm thế nào để bảo vệ chìa khóa tốt nhất? Nếu khóa được lưu trữ trên mỗi máy của người dùng, làm thế nào để bảo vệ nó nếu máy bị khai thác? Nếu khai thác khóa, làm thế nào để thay đổi khóa?

Nếu khóa được lưu trữ trong DB, làm thế nào để bảo vệ nó ở đó? Làm thế nào người dùng sẽ truy cập nó?


Loại mã hóa và lưu trữ khóa sẽ phụ thuộc vào loại kịch bản bạn muốn ngăn chặn. Rõ ràng, nếu kẻ tấn công của bạn có người dùng root hoặc ứng dụng trên máy chủ, anh ta có thể sử dụng các thói quen tương tự để giải mã khi ứng dụng của bạn sử dụng. Vì vậy, kịch bản nào bạn muốn ngăn chặn? Ai đó ăn cắp bản sao lưu? Tấn công SQL SQL? Thứ gì khác?
Aleksandar Ivanisevic

Cảm ơn vi đa trả lơi! Tôi không quá quan tâm đến việc sao lưu. Tôi quan tâm nhiều hơn đến việc ai đó khai thác máy người dùng và sau đó truy cập trang web từ đó thông qua SQL, hoặc phá vỡ thông tin đăng nhập ứng dụng của người dùng. Tôi không quá quan tâm đến bản thân máy; thông tin đăng nhập cho su rất mạnh (tuy nhiên tôi không hề ảo tưởng rằng nó an toàn 100%).
bão

Câu trả lời:


9

Thực sự không có bất kỳ tính năng tích hợp nào của MySQL để xử lý các thiết lập khóa được mã hóa tinh vi. Bạn sẽ cần triển khai phần lớn logic mã hóa trong mã PHP và / hoặc mã phía trình duyệt (javascript?) Của riêng bạn.

Nhưng mối quan tâm đã nêu của bạn hơi kỳ dị: Có vẻ như mối quan tâm thực sự duy nhất của bạn là một cuộc tấn công SQL hoặc vũ phu (đoán mật khẩu, tôi giả sử) tấn công từ máy trạm máy tính để bàn / máy tính xách tay từ xa. Điều đó khiến tôi nghi ngờ rằng bạn đã có một số biện pháp bảo mật khác, chưa được đề cập và bạn đã phân tích các con đường thỏa hiệp có thể có.

  • Đối với một người, tôi giả sử bạn có các quy tắc tường lửa bảo vệ máy chủ MySQL / PHP trước mọi loại truy cập từ các IP máy khách từ xa không được chấp thuận. Nếu tôi đúng, điều đó có nghĩa là bạn chỉ lo lắng về các cuộc tấn công từ các máy trạm của người dùng bị xâm nhập.

  • Ngoài ra, tôi giả sử bạn hiểu rằng nếu kẻ tấn công trên máy chủ máy khách từ xa có thể leo thang đến quyền riêng tư / quản trị viên hoặc xâm phạm trực tiếp tài khoản của người dùng thực, thì dữ liệu của khách hàng đó không được bảo vệ bất kể mã hóa hay bất kỳ biện pháp bảo vệ nào khác. (Kẻ tấn công có thể đọc các khóa từ bất cứ nơi nào chúng được lưu trên đĩa hoặc rình mò khi người dùng thực sự nhập chúng khi đăng nhập và các khóa dẫn đến dữ liệu.)

Bắt đầu từ hai giả định đó, thật hợp lý khi chúng tôi kết luận rằng hai mối đe dọa duy nhất có liên quan là A) đoán mật khẩu vũ phu và B) các nỗ lực tiêm SQL:

  • Nếu kẻ tấn công không nhận được khóa của người dùng thực hoặc nếu anh ta muốn truy cập nhiều hơn chỉ là dữ liệu của người dùng thực, anh ta có thể thử tài khoản đăng nhập bắt buộc cho người dùng thực hoặc tài khoản khác. (Về lý thuyết, bạn có thể khóa từng tài khoản vào một IP máy khách từ xa cụ thể, điều này cũng sẽ giúp ngăn chặn các rủi ro.)
  • Nếu kẻ tấn công nhận được một khóa hợp lệ cho người dùng thực, anh ta có một con đường qua màn hình đăng nhập (có lẽ đủ đơn giản để bảo mật), dưới phần mềm của mã ứng dụng có khả năng bị lỗi. Việc tiêm SQL thành công từ bối cảnh người dùng thực cũng có thể cho anh ta quyền truy cập vào dữ liệu khách hàng khác.

Bây giờ, hãy nói về cách mã hóa phía máy chủ áp dụng cho các tình huống này:

  • Mã hóa phía máy chủ chắc chắn giúp chống lại mối đe dọa tiêm SQL. Nếu các giá trị hàng được mã hóa trong các bảng DB, kẻ tấn công chỉ có thể thấy bản mã vô nghĩa của dữ liệu thuộc về các tài khoản khác. Các mối đe dọa được chứa đựng, ngăn cách.
  • Mặc dù vậy, việc cưỡng bức đoán mật khẩu không thực sự trở nên khó khăn hơn đối với kẻ tấn công phải đối mặt với mã hóa phía máy chủ. Bất kể khóa của người dùng được lưu trữ trên máy chủ hay được tạo tại chỗ từ mật khẩu, điều duy nhất quan trọng là bạn có mật khẩu đúng hay không. Máy chủ quyết định cho phép bạn sử dụng khóa được lưu trữ hợp lệ vì nó kiểm tra mật khẩu của bạn là chính xác hay nó tính toán khóa hợp lệ cho bạn vì mật khẩu của bạn là đầu vào chính xác để tạo khóa đó.

Mặt khác, mã hóa phía máy khách thực sự làm cho các cuộc tấn công mật khẩu vũ phu không liên quan. Bạn không thể vũ phu một khóa được xây dựng đúng. Mã hóa phía máy khách về cơ bản cũng giữ mức bảo vệ chống lại việc tiêm SQL như mã hóa phía máy chủ. Máy khách có thể chuyển khóa tới máy chủ khi đăng nhập, giữ một bản sao trong bộ nhớ cho đến khi phiên kết thúc, điều này đặt gánh nặng CPU của tiền điện tử lên máy chủ. Hoặc, máy khách có thể tự xử lý mã hóa / giải mã trong trình duyệt. Có những thăng trầm cho cả hai kỹ thuật:

  • Việc chuyển khóa của nó tới máy chủ dễ dàng hơn để mã hóa và quản lý, và thường nhanh hơn nhiều đối với tài khoản mã hóa được tối ưu hóa hơn (có thể được biên dịch C).
  • Cách tiếp cận phía máy khách thuần túy mang lại sự bảo mật cao hơn, bởi vì ngay cả khi kẻ tấn công đã root trên máy chủ, anh ta vẫn không thể đọc được dữ liệu được mã hóa và anh ta sẽ không bao giờ có thể đọc được. Vectơ tấn công duy nhất có thể là thỏa hiệp máy trạm từ xa.

Cuối cùng, tôi sẽ lưu ý rằng có một số nhược điểm lớn trong hoạt động mã hóa dữ liệu trong cơ sở dữ liệu. Bởi vì các biểu diễn dữ liệu được mã hóa về cơ bản là các mẫu ngẫu nhiên, các tính năng cơ sở dữ liệu cơ bản như lập chỉ mục, tham gia, v.v. sẽ không hoạt động. Máy khách chịu một gánh nặng logic rất lớn và có thể mất rất nhiều lợi ích mà các tính năng cơ sở dữ liệu thường mang lại.


1
Ồ Câu trả lời tuyệt vời và kỹ lưỡng; Cảm ơn rât nhiều. Trong vài ngày qua, tôi đã xem xét một số tùy chọn và đã quyết định thử và thực hiện giải pháp phía khách hàng như bạn đề xuất. Lý tưởng nhất là các khóa sẽ được lưu trữ trên các ổ ngón tay cái sẽ chỉ được gắn trong khi người dùng đang làm việc trên hệ thống (bảo mật vật lý rất chặt chẽ) và khóa được giữ trong bộ nhớ chỉ khi phiên còn tồn tại. Ý tưởng là các khóa sẽ chỉ có thể truy cập được vào hệ thống trong giờ làm việc khi tôi ở đó để giám sát lưu lượng, v.v.
cơn bão

2

Bạn có thể muốn xem ezNcrypt , sử dụng ecryptfs, kiểm soát truy cập và quản lý khóa để cung cấp bảo mật và hiệu suất cao cho mã hóa Linux của cơ sở dữ liệu MySQL và các quy trình khác. Không, tôi không làm việc cho họ.


2

Bạn có thể sử dụng Scytale. Nó là một proxy mã hóa NoQuery cho các ứng dụng web và DBMS hiện đại. Hỗ trợ mã hóa đa người nhận và nhóm. Được tải với hệ thống mật mã RSA / AES mạnh mẽ. Nó cũng miễn phí 100% và nguồn mở.

https://bitbucket.org/maximelabelle/scytale

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.