Đặc quyền hợp lý để cấp cho người dùng thông thường là gì? [đóng cửa]

Tôi thấy danh sách các đặc quyền được cung cấp bởi MySQL là một chút áp đảo. Tôi không chắc ai nên có đặc quyền gì. Trong tâm trí tôi có ba người dùng điển hình cho tình huống của tôi:

1. root
2. developer
3. application

rootlà tự giải thích. Để developerngười dùng này cần có thể dễ dàng truy cập bất kỳ cơ sở dữ liệu nào, hãy điều chỉnh nó, v.v. Đối với người mới bắt đầu, tôi sẽ đặt người dùng này thành tập đặc quyền này:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationcó một bộ thậm chí còn hạn chế hơn. Nó chỉ nên được giới hạn để thao tác một cơ sở dữ liệu cụ thể.

Tôi không chắc chắn một bộ đặc quyền hợp lý là gì để cấp. Tập hợp đặc quyền hợp lý để cấp cho nhà phát triển và ứng dụng là gì và tại sao?

Một người dùng thông thường nên có:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Bốn cái đầu tiên khá rõ ràng - mặc dù bạn cũng có thể chỉ thiết lập người dùng "chỉ đọc" SELECT.

CREATE TEMPORARYcũng tiện dụng và thường vô hại: các bảng tạm thời có thể giúp tối ưu hóa các truy vấn, chia chúng thành các phần nhỏ hơn và nhanh hơn. Chúng được giới hạn trong kết nối thực thi và được tự động loại bỏ khi đóng.

EXECUTEphụ thuộc vào loại hệ thống của bạn. Bạn có thói quen lưu trữ? Bạn có muốn người dùng của bạn truy cập chúng? Hãy chắc chắn rằng bạn cũng biết về SECURITY=DEFINER/INVOKERđịnh nghĩa cho các thói quen được lưu trữ.

Trong mọi trường hợp, đảm bảo áp dụng tất cả các điều trên trên các lược đồ cụ thể . Tránh sử dụng:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

như ở trên cũng cấp các đặc quyền trên các mysqlbảng hệ thống, cho phép bất kỳ người dùng nào tạo tài khoản mới hoặc nâng cấp tập đặc quyền của riêng họ một cách hiệu quả. Thay vào đó, hãy làm:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

Trong bất kỳ hệ thống quy mô thực nào (nghĩa là không phải là một dự án cá nhân), các loại người dùng đó sẽ thay đổi theo môi trường, vì vậy nó không đơn giản như vậy.

Trong tất cả các môi trường, ứng dụng nên có những gì nó cần và không cần thêm (nói chung đây là "chọn / chèn / cập nhật trên tất cả các bảng" và "thực thi trên tất cả các quy trình". Đối với các hệ thống lớn hơn, nơi bạn có thể có người dùng ứng dụng riêng cho các tác vụ khác nhau (cho ví dụ một ứng dụng chịu trách nhiệm cung cấp dữ liệu kiểm duyệt và một ứng dụng khác để tạo báo cáo) bạn nên tách biệt các đặc quyền của chúng để chúng có ít nhất chúng cần (người dùng báo cáo có thể không cần và viết quyền). môi trường nếu bạn có chúng: Tôi đã thấy mã bị lỗi khi được quảng cáo thành Live hoạt động trong thử nghiệm vì mọi thứ trong môi trường thử nghiệm đều truy cập DB dưới dạng sa(tương đương với MSSQL root).Lý tưởng nhất là người dùng ứng dụng thường không có đặc quyền cho phép nó thay đổi lược đồ của bạn (CREATE,, DROP...) - có những trường hợp ngoại lệ cho vấn đề này nhưng chúng rất ít và xa.

rootlà, tốt , root. Trong sản xuất, đây chỉ là DBA của bạn và hiếm khi được sử dụng - chỉ để bảo trì hệ thống (nâng cấp lên thiết kế DB) và theo dõi. Đối với một hệ thống lớn, đặc biệt là trong các môi trường được quy định nơi bạn phải duy trì sự kiểm soát chặt chẽ các cá nhân vì mục đích trách nhiệm, bạn không được phép rootsử dụng một người dùng và thử tách các đặc quyền thành các cuộn nhỏ hơn (Tôi không chắc bạn có thể đi được bao xa với điều này trong mysql, nhưng bạn có thể khá chi tiết trong MSSQL, Oracle và vv).

Đối với người dùng nhà phát triển: họ hoàn toàn không có quyền truy cập vào môi trường sống của bạn. Đây là một trong những lý do tại sao người dùng ứng dụng không nên có lược đồ ảnh hưởng đến quyền: ai đó có quyền truy cập vào tài khoản nhà phát triển có thể có khả năng phá vỡ khóa của họ theo cách này. Trong môi trường thử nghiệm, họ thường không có quyền truy cập: họ sẽ gửi các bản vá cho QA và DBA (có thể sử dụng rootngười dùng) cho QA sẽ áp dụng các bản cập nhật cho môi trường thử nghiệm (thực tế điều này thường được tự động hóa trong các tổ chức lớn, do đó, QA DBA thực sự là một tập các kịch bản kiểm soát việc xây dựng lại môi trường thử nghiệm cho mỗi chu kỳ). Trong môi trường phát triển, đặc biệt là nếu các nhà phát triển có bản sao riêng của dịch vụ đang chạy, những người dùng này tất nhiên có quyền truy cập đầy đủ vào mọi thứ để có thể thử nghiệm.

Trên đây là tất cả các lưu ý chung: để đưa ra bất kỳ khuyến nghị cụ thể nào, chúng tôi sẽ cần biết nhiều hơn về (các) ứng dụng của bạn và môi trường chúng hoạt động. Môi trường mục tiêu đôi khi quan trọng hơn bạn nghĩ: tùy thuộc vào môi trường kinh doanh của bạn quyền của người dùng của bạn thậm chí có thể được quyết định trực tiếp là các quy định pháp lý, ngay cả trong quá trình phát triển nếu khách hàng của bạn từng cấp cho bạn quyền truy cập vào dữ liệu thực cho mục đích chẩn đoán.