Đầu tiên , như nhiều người đã nói, việc giữ thông tin đăng nhập tách biệt với tập lệnh là điều cần thiết. (Ngoài việc tăng cường bảo mật, điều đó cũng có nghĩa là bạn có thể sử dụng lại cùng một tập lệnh cho một số hệ thống có thông tin xác thực khác nhau.)
Thứ hai , bạn nên xem xét không chỉ sự bảo mật của thông tin đăng nhập, mà còn ảnh hưởng nếu / khi những thông tin đó bị xâm phạm. Bạn không nên chỉ có một mật khẩu cho tất cả quyền truy cập vào cơ sở dữ liệu, bạn nên có các thông tin đăng nhập khác nhau với các cấp truy cập khác nhau. Chẳng hạn, bạn có thể có một người dùng DB có khả năng thực hiện tìm kiếm trong cơ sở dữ liệu - người dùng đó nên có quyền truy cập chỉ đọc. Một người dùng khác có thể có quyền chèn các bản ghi mới, nhưng không xóa chúng. Người thứ ba có thể được phép xóa hồ sơ.
Ngoài việc hạn chế quyền cho mỗi tài khoản, bạn cũng nên có hạn chế về nơi mỗi tài khoản có thể được sử dụng. Chẳng hạn, tài khoản được sử dụng bởi máy chủ web của bạn không được phép kết nối từ bất kỳ địa chỉ IP nào khác ngoài tài khoản của máy chủ web. Một tài khoản có quyền truy cập root đầy đủ vào cơ sở dữ liệu thực sự rất hạn chế về mặt nó có thể kết nối từ đâu và không bao giờ được sử dụng ngoài mục đích tương tác. Cũng xem xét sử dụng các thủ tục được lưu trữ trong cơ sở dữ liệu để hạn chế chính xác những gì có thể được thực hiện bởi mỗi tài khoản.
Các hạn chế này cần được triển khai ở phía máy chủ DB của hệ thống, do đó ngay cả khi phía máy khách bị xâm phạm, các hạn chế không thể được thay đổi từ nó. (Và, rõ ràng, máy chủ DB cần được bảo vệ bằng tường lửa, v.v. ngoài cấu hình DB ...)
Trong trường hợp tài khoản DB chỉ được phép truy cập chỉ đọc có giới hạn và chỉ từ một địa chỉ IP cụ thể, bạn có thể không cần bất kỳ thông tin xác thực nào khác, tùy thuộc vào độ nhạy cảm của dữ liệu và bảo mật của tập lệnh máy chủ đang được điều hành từ Một ví dụ có thể là một hình thức tìm kiếm trên trang web của bạn, có thể được chạy với người dùng chỉ được phép sử dụng một quy trình được lưu trữ, chỉ trích xuất thông tin sẽ được trình bày trên trang web. Trong trường hợp này, việc thêm mật khẩu không thực sự mang lại bất kỳ bảo mật bổ sung nào, vì thông tin đó đã được công khai và người dùng không thể truy cập bất kỳ dữ liệu nào nhạy cảm hơn.
Đồng thời đảm bảo rằng kết nối đến cơ sở dữ liệu được thực hiện bằng TLS hoặc bất kỳ ai nghe trên mạng đều có thể nhận được thông tin đăng nhập của bạn.
Thứ ba , xem xét loại thông tin để sử dụng. Mật khẩu chỉ là một hình thức và không an toàn nhất. Thay vào đó, bạn có thể sử dụng một số dạng cặp khóa công khai / riêng tư hoặc AD / PAM hoặc tương tự.
Thứ tư , xem xét các điều kiện theo đó tập lệnh sẽ được chạy:
Nếu nó được chạy tương tác, thì bạn nên nhập mật khẩu hoặc mật khẩu vào khóa riêng hoặc khóa riêng hoặc đăng nhập bằng vé Kerberos hợp lệ, khi bạn chạy nó - nói cách khác, tập lệnh sẽ nhận được mật khẩu thông tin đăng nhập trực tiếp từ bạn tại thời điểm bạn chạy nó, thay vì đọc chúng từ một số tệp.
Nếu nó được chạy từ máy chủ web, hãy xem xét việc thiết lập thông tin đăng nhập tại thời điểm bạn khởi động máy chủ web. Một ví dụ điển hình ở đây là chứng chỉ SSL - chúng có chứng chỉ chung và khóa riêng và khóa riêng có mật khẩu. Bạn có thể lưu trữ khóa riêng trên máy chủ web, nhưng bạn vẫn cần nhập mật khẩu cho nó khi bạn khởi động Apache. Bạn cũng có thể có thông tin đăng nhập trên một số loại phần cứng, chẳng hạn như thẻ vật lý hoặc HSM, có thể được gỡ bỏ hoặc khóa sau khi máy chủ được khởi động. (Tất nhiên, nhược điểm của phương pháp này là máy chủ không thể tự khởi động lại nếu có chuyện gì xảy ra. Tôi thích điều này hơn với nguy cơ hệ thống của tôi bị xâm phạm, nhưng số dặm của bạn có thể thay đổi ...)
Nếu tập lệnh đang được chạy từ cron, đây là phần khó. Bạn không muốn có thông tin xác thực nằm ở bất cứ đâu trên hệ thống của mình, nơi ai đó có thể truy cập chúng - nhưng bạn muốn có chúng nằm xung quanh để tập lệnh của bạn có thể truy cập chúng, phải không? Vâng, không hoàn toàn đúng. Xem xét chính xác những gì kịch bản đang làm. Nó cần những quyền gì trên cơ sở dữ liệu? Nó có thể bị hạn chế để nó không thành vấn đề nếu người sai kết nối với các quyền đó? Thay vào đó, bạn có thể chạy tập lệnh trực tiếp trên máy chủ DB mà không ai khác có quyền truy cập, thay vì từ máy chủ có người dùng khác không? Nếu, vì một số lý do mà tôi không thể nghĩ ra, bạn nhất định phải có tập lệnh chạy trên một máy chủ không an toàn và nó phải có thể làm điều gì đó nguy hiểm / phá hoại ... bây giờ là thời điểm tốt để suy nghĩ lại kiến trúc của bạn.
Thứ năm , nếu bạn coi trọng tính bảo mật của cơ sở dữ liệu của mình, bạn không nên chạy các tập lệnh này trên các máy chủ mà người khác có quyền truy cập. Nếu ai đó đã đăng nhập vào hệ thống của bạn, thì họ sẽ có khả năng nhận được thông tin đăng nhập của bạn. Ví dụ, trong trường hợp máy chủ web có chứng chỉ SSL, ít nhất có khả năng về mặt lý thuyết là ai đó có thể lấy quyền root và truy cập vào vùng nhớ của tiến trình httpd và trích xuất thông tin đăng nhập. Đã có ít nhất một lần khai thác trong thời gian gần đây, nơi điều này có thể được thực hiện qua SSL, thậm chí không yêu cầu kẻ tấn công phải đăng nhập.
Ngoài ra, hãy cân nhắc sử dụng SELinux hoặc apparmor hoặc bất cứ thứ gì có sẵn cho hệ thống của bạn để hạn chế người dùng có thể làm gì. Họ sẽ cho phép bạn không cho phép người dùng thậm chí cố gắng kết nối với cơ sở dữ liệu, ngay cả khi họ quản lý để có quyền truy cập vào thông tin đăng nhập.
Nếu tất cả điều này nghe có vẻ quá mức đối với bạn và bạn không đủ khả năng hoặc không có thời gian để làm điều đó - thì theo ý kiến của tôi (kiêu ngạo và tinh hoa), bạn không nên lưu trữ bất cứ thứ gì quan trọng hoặc nhạy cảm trong cơ sở dữ liệu của mình. Và nếu bạn không lưu trữ bất cứ thứ gì quan trọng hoặc nhạy cảm, thì nơi bạn lưu trữ thông tin đăng nhập của bạn cũng không quan trọng - trong trường hợp nào, tại sao lại sử dụng mật khẩu?
Cuối cùng , nếu bạn hoàn toàn không thể tránh lưu trữ một số loại thông tin đăng nhập, bạn có thể có thông tin chỉ đọc và sở hữu bởi root và root có thể cấp quyền sở hữu trên cơ sở tạm thời khi được yêu cầu bởi kịch bản (vì tập lệnh của bạn không nên chạy bằng root trừ khi thực sự cần thiết và việc kết nối với cơ sở dữ liệu không khiến nó cần thiết). Nhưng nó vẫn không phải là một ý tưởng tốt.