Có bao giờ thực hành tốt để sử dụng một tài khoản cơ sở dữ liệu riêng biệt cho mỗi người dùng của một ứng dụng?

Các ứng dụng tôi đã sử dụng dựa trên máy chủ và sử dụng một tài khoản cơ sở dữ liệu cho nhiều người dùng, với mã ứng dụng kiểm soát những gì người dùng có thể làm hoặc người dùng đơn lẻ.

Có bất kỳ ứng dụng kinh doanh phức tạp thành công nào mà mỗi người cần có tài khoản cơ sở dữ liệu của riêng họ và máy chủ cơ sở dữ liệu được dựa vào để thực thi các quy tắc chính sách về những gì mỗi người dùng nên được phép và không được phép làm?

Tôi đang suy nghĩ về các ứng dụng mà nhiều người đóng góp vào thông tin trong một cơ sở dữ liệu và có thể truy cập thông tin được lưu trữ bởi những người khác - ví dụ: các đồng nghiệp trong một tổ chức, những người cần truy cập vào hồ sơ khách hàng.

Ngoài ra có một tên cho loại thiết lập này?

Nếu bạn cần kiểm soát thực sự chặt chẽ được thi hành ở cấp dữ liệu. Ví dụ kiểm toán rộng rãi. Kiểm toán sẽ không tốt nếu nhiều người dùng chia sẻ cùng một tài khoản. Nếu bạn có một số người dùng có nhu cầu truy cập cơ sở dữ liệu trực tiếp.

Nếu bảo mật chặt chẽ, bạn thường không để lộ cơ sở dữ liệu trực tiếp. Bạn có một dịch vụ và khách hàng phải lấy dữ liệu từ dịch vụ.

Trong một ứng dụng web, cơ sở dữ liệu (ví dụ cổng 1433) thường không được hiển thị trực tiếp để bạn có mức độ bảo mật. Ngay cả khi ứng dụng web truy cập trực tiếp vào cơ sở dữ liệu, người dùng vẫn không có quyền truy cập trực tiếp vào cơ sở dữ liệu.

Nếu đăng nhập và mật khẩu trong ứng dụng khách thì nó có thể bị hack. Nếu một tên miền bạn có thể sử dụng bảo mật tích hợp.

Tại cơ sở dữ liệu, bạn có thể có các điều khiển khá tốt. Nhưng kiểm soát mức hàng là một chút công việc. Một cơ sở dữ liệu không phải là một công cụ tốt cho các quy tắc kinh doanh. Các quy tắc kinh doanh và bảo mật chi tiết thường được thi hành ở cấp ứng dụng.

Bạn có thể có một chế độ hỗn hợp trong đó có một số quy trình được lưu trữ được sử dụng bởi quản trị viên và bạn muốn theo dõi quản trị viên nào. Và bạn có thể cấp quyền truy cập chỉ đọc cho người dùng tạo báo cáo trực tiếp.

Thách thức ở đây là truy cập cơ sở dữ liệu của bạn được quản lý bởi sự trừu tượng hóa. Thay vì người dùng kết nối như chính họ, về cơ bản họ đảm nhận danh tính của một số vai trò ứng dụng tổng quát. Bạn không chỉ mất khả năng hiển thị của kết nối riêng lẻ mà còn mất khả năng xác định các loại quyền truy cập khác nhau cho tất cả người dùng cá nhân của bạn.

Lý do chính để sử dụng phương pháp này là sự đơn giản. Nhiều ứng dụng được thiết kế sao cho người dùng ứng dụng sẽ không có kiến ​​thức về cơ sở dữ liệu. Họ thực sự không cần nó, đặc biệt nếu ứng dụng quản lý bảo mật nội bộ của chính nó. Hầu hết người dùng cá nhân sẽ không bao giờ kết nối trực tiếp với cơ sở dữ liệu, vì vậy việc xác định đăng nhập rõ ràng cho họ là không cần thiết.

Lần duy nhất bạn nên xem xét để cho cơ sở dữ liệu quản lý bảo mật của mình là nếu bạn có người dùng sẽ kết nối trực tiếp với cơ sở dữ liệu của bạn. Điều này có nghĩa là họ đang đi xung quanh ứng dụng của bạn và nó không còn có thể tự thực thi bảo mật nữa. Ưu điểm ở đây là bạn có thể chi tiết hơn về việc xác định bảo mật của mình. Nhược điểm là chi phí cao hơn để quản lý người dùng và quyền của họ.

Nếu bạn cảm thấy cần loại quyền truy cập này, bạn muốn sử dụng Kiểm soát truy cập dựa trên vai trò . Bạn nên xác định vai trò dựa trên loại quyền nào cần thiết trong cơ sở dữ liệu của bạn và sau đó nhóm người dùng cá nhân theo các vai trò đó. Điều này cho phép bạn kiểm tra và kiểm soát tốt hơn mô hình bảo mật của mình, có thể nhanh chóng vượt khỏi tầm kiểm soát khi quản lý truy cập trực tiếp.

Có một cách tiếp cận lai với điều này. Nếu bạn muốn bảo mật của mình được cơ sở dữ liệu kiểm soát một phần, bạn có thể tạo nhiều người dùng ứng dụng, mỗi người dùng được xác định bởi vai trò của họ và cấp quyền truy cập rõ ràng cho những người dùng đó dựa trên vai trò họ thực hiện. Điều này có nghĩa là bạn có thể tận dụng công cụ cơ sở dữ liệu cho một số mô hình bảo mật của mình, nhưng bạn vẫn phải có một số quản lý trong ứng dụng. Nó làm tăng sự phức tạp của mô hình người dùng ứng dụng, nhưng cung cấp cho bạn mức độ chi tiết tốt hơn trên các thông tin đăng nhập khác nhau được sử dụng.

Bạn nên bắt đầu thực thi bảo mật ở mức chi tiết nhất càng sớm càng tốt. Vai trò giúp đỡ trong vấn đề này - cho phép mọi người truy cập vào một số bảng cùng một lúc không phải là một cơn ác mộng.

Tài khoản duy nhất cho mọi người là một nguồn câu hỏi tuyệt vời ở đây và những nơi khác - "bản ghi x đã bị xóa, làm cách nào để biết ai đã làm điều đó?" - câu trả lời là bạn không thể - không có tài khoản cá nhân và kiểm toán .

Bằng cách "kiểm toán" Tôi có nghĩa là trong khi tất cả đều có tài khoản cho tất cả mọi người, điều đó không có nghĩa là bạn có bảo mật thực sự. Nếu, giả sử, một bản ghi trong bảng HR bị xóa, tất cả những gì bạn có thể nói là ai đó có quyền truy cập vào bảng HR đã làm điều đó - đó là x số người.

Bạn cần kích hoạt trong hệ thống của mình để ghi lại các hành động để có thể theo dõi cấp độ cá nhân đã thực hiện hành động X (trừ khi bạn có RDBMS như Oracle nơi điều này có thể được thực hiện tự động).

Trong mọi trường hợp, bạn phải luôn đảm bảo an ninh của mình càng chi tiết càng sớm càng tốt - cung cấp cho mọi người quyền truy cập vào các bảng chỉ trên cơ sở "cần biết". Và, luôn bao gồm dấu thời gian cho các hành động đối với các bảng - mọi người thường đưa id của họ cho người khác - nếu bạn có thể nói, "Jimmy, bạn là người duy nhất trong văn phòng lúc 17:49 ..." - một lần nữa, đó không phải là sắt, chỉ là một mũi tên khác trong run rẩy của bạn.

Có lẽ nếu bạn đã cho chúng tôi RDBMS của bạn, bạn có thể nhận được lời khuyên cụ thể hơn / phù hợp hơn với tình huống của bạn không?

Vâng, đúng vậy. Kết nối với cơ sở dữ liệu từ một ứng dụng với tư cách là một người dùng mạnh mẽ là vi phạm nguyên tắc đặc quyền tối thiểu . Đây là nguyên nhân gốc rễ của hầu hết các cuộc tấn công SQL Injection.

Điều này thường được thực hiện do sự thiếu hiểu biết, vì đơn giản, hoặc đôi khi vì hiệu suất.

Cơ sở dữ liệu thường tồn tại lâu và được sử dụng bởi nhiều ứng dụng cùng một lúc và theo thời gian. Bạn có thể lưu tài nguyên bằng cách tập trung kiểm soát truy cập trong cơ sở dữ liệu thay vì qua nhiều ứng dụng.

Bạn muốn chọn một máy chủ db hỗ trợ Bảo mật Hàng, Bảo mật Cột và Xác thực Proxy / Xác thực Proxy (hỗ trợ người dùng db thực + nhóm kết nối)

Nó cũng sẽ an toàn hơn cho các ứng dụng dựa trên "plugin", như Wordpress, nơi khó tránh khỏi việc tiêm SQL do các tác giả plugin không có kỹ năng. Mỗi plugin được đăng nhập db, thay vì toàn bộ ứng dụng.