Câu trả lời ngắn
Bạn không thể.
Nếu mật khẩu được lưu trữ trong cấu phần phần mềm được chuyển đến người dùng cuối, bạn phải coi như nó bị xâm phạm! Ngay cả khi cấu phần là một tệp nhị phân đã biên dịch, luôn có (ít nhiều phức tạp) để lấy mật khẩu.
Cách duy nhất để bảo vệ tài nguyên của bạn là chỉ để lộ một API giới hạn cho người dùng cuối. Xây dựng một API có lập trình (REST, WS + SOAP, RMI, JavaEE + Servlets, ...) hoặc chỉ hiển thị một số chức năng nhất định trong DB của bạn thông qua SPROC (xem bên dưới).
Một số điều đầu tiên ...
Câu hỏi ở đây không phải là làm thế nào để ẩn mật khẩu, mà là làm thế nào để bảo mật cơ sở dữ liệu. Hãy nhớ rằng chỉ mật khẩu thường là một biện pháp bảo vệ rất yếu và không nên được coi là cơ chế duy nhất để bảo vệ DB. Bạn có đang sử dụng SSL không? Không? Chà, thì ngay cả khi nếu bạn quản lý để ẩn mật khẩu trong mã ứng dụng, vẫn dễ dàng tìm thấy nó trên mạng!
Bạn có nhiều lựa chọn. Tất cả đều có các mức độ bảo mật khác nhau:
"Vai trò ứng dụng"
Tạo một người dùng cơ sở dữ liệu cho ứng dụng. Áp dụng ủy quyền cho vai trò này. Một thiết lập rất phổ biến là chỉ cho phép hoạt động CRUD.
Ưu điểm
- rất dễ thiết lập
- Ngăn chặn
DROPtruy vấn (f.ex. trong SQL injection?)
Nhược điểm
- Mọi người nhìn thấy mật khẩu đều có quyền truy cập vào tất cả dữ liệu trong cơ sở dữ liệu. Ngay cả khi dữ liệu đó thường được ẩn trong ứng dụng.
- Nếu mật khẩu bị xâm phạm, người dùng có thể chạy
UPDATEvàDELETEcác truy vấn không có tiêu chí (tức là:xóa / cập nhật toàn bộ bảng cùng một lúc).
Xác thực và xác thực nguyên tử
Tạo một người dùng cơ sở dữ liệu cho mỗi ứng dụng- / người dùng cuối. Điều này cho phép bạn xác định quyền truy cập nguyên tử ngay cả trên cơ sở mỗi cột. Ví dụ:Người dùng X chỉ có thể chọn các cột ở xa và baz từ foo bảng. Và không có gì khác. Nhưng người dùng Y có thể SELECT mọi thứ, nhưng không có cập nhật, trong khi người dùng Z có toàn quyền truy cập CRUD (chọn, chèn, cập nhật, xóa).
Một số cơ sở dữ liệu cho phép bạn sử dụng lại thông tin đăng nhập cấp hệ điều hành. Điều này làm cho việc xác thực đối với người dùng trở nên minh bạch (chỉ cần đăng nhập vào máy trạm, danh tính đó sau đó sẽ được chuyển tiếp đến DB). Điều này hoạt động dễ dàng nhất trong MS-stack đầy đủ (OS =Windows, Auth =ActiveDirectory, DB =MSSQL) nhưng - theo như tôi biết - cũng có thể đạt được trong các DB khác.
Ưu điểm
- Khá dễ thiết lập.
- Lược đồ ủy quyền rất nguyên tử
Nhược điểm
- Việc thiết lập tất cả các quyền truy cập trong DB có thể khá tẻ nhạt.
- Người dùng có
UPDATEvàDELETEquyền vẫn có thể vô tình (hoặc cố ý?) xóa / cập nhật mà không tiêu chuẩn. Bạn có nguy cơ mất tất cả dữ liệu trong bảng.
Quy trình được lưu trữ với xác thực nguyên tử &auth
Viết không Truy vấn SQL trong ứng dụng của bạn. Chạy mọi thứ thông qua SPROCs. Sau đó, tạo tài khoản db cho từng người dùng và chỉ định đặc quyền cho SPROCs chỉ .
Ưu điểm
- Cơ chế bảo vệ hiệu quả nhất.
- SPROC có thể buộc người dùng chuyển tiêu chí cho mọi truy vấn (bao gồm
DELETEvàUPDATE)
Nhược điểm
- không chắc liệu điều này có hoạt động với MySQL hay không (kiến thức của tôi về lĩnh vực đó còn sai sót).
- chu kỳ phát triển phức tạp:Mọi thứ bạn muốn làm, trước tiên phải được xác định trong SPROC.
Suy nghĩ cuối cùng
Bạn không nên cho phép các tác vụ quản trị cơ sở dữ liệu vào ứng dụng. Hầu hết thời gian, các hoạt động duy nhất mà ứng dụng cần là SELECT , INSERT , DELETE và UPDATE . Nếu bạn làm theo hướng dẫn này, hầu như không có rủi ro khi người dùng phát hiện ra mật khẩu. Ngoại trừ những điểm đã nêu ở trên.
Trong mọi trường hợp, hãy giữ các bản sao lưu. Tôi giả sử bạn muốn chiếu cơ sở dữ liệu của mình chống lại việc xóa hoặc cập nhật tình cờ. Nhưng tai nạn xảy ra ... hãy ghi nhớ điều đó;)
