Tại sao nó là một thực hành xấu để cho phép tất cả mọi người sử dụng đăng nhập sa?

Ngay cả Microsoft cũng không khuyến khích sử dụng chế độ xác thực SQL Server , nhưng các ứng dụng của chúng tôi yêu cầu nó.

Tôi đã đọc rằng đó là cách tốt nhất để không cho phép người dùng sử dụng sađăng nhập trực tiếp, thay vào đó sử dụng Windows xác thực và cho phép các tài khoản (hoặc nhóm tài khoản) đặc quyền sysadmin.

• Đó không phải là điều tương tự? Những lợi thế / bất lợi là gì?
• Cách thực hành tốt nhất làm tăng tính bảo mật của các phiên bản SQL Server của tôi?
• Điều này chỉ áp dụng cho các trường hợp sản xuất, hoặc cho các trường hợp phát triển nội bộ của chúng tôi nữa?

Bạn có một số câu hỏi khác nhau ở đây, vì vậy tôi sẽ loại chúng ra:

"Tôi đã đọc rằng đó là cách tốt nhất để không cho phép người dùng sử dụng đăng nhập sa trực tiếp, thay vào đó sử dụng Windows xác thực"

Bạn đang trộn lẫn hai thứ ở đây: khái niệm SA và khái niệm xác thực SQL và xác thực Windows.

Xác thực SQL là danh sách tên người dùng và mật khẩu được lưu trữ trong mỗi và mọi Máy chủ SQL. Thực tế là nó được lưu trữ trong SQL là vấn đề đầu tiên. Nếu bạn cần thay đổi mật khẩu đăng nhập, bạn phải thay đổi mật khẩu trên mọi máy chủ (hoặc duy trì các mật khẩu khác nhau trên các máy chủ khác nhau). Với xác thực Windows, bạn có thể vô hiệu hóa tập trung đăng nhập, thay đổi mật khẩu, đặt chính sách, v.v.

Nếu bạn chọn sử dụng xác thực SQL, thì SA chỉ là một lần đăng nhập xác thực SQL. Đó là tên người dùng quản trị viên mặc định, giống như Quản trị viên đang xác thực Windows. Nó có siêu năng lực cục bộ trong một trường hợp đó, nhưng không phải siêu năng lực toàn cầu trên tất cả các trường hợp.

"... và cho phép các tài khoản (hoặc nhóm tài khoản) đặc quyền sysadmin."

Dù bạn chọn phương thức xác thực nào, lý tưởng nhất là bạn muốn tuân theo nguyên tắc đặc quyền tối thiểu: cấp cho mọi người các quyền tối thiểu mà họ cần để hoàn thành công việc, và không còn nữa.

Đừng nghĩ họ chỉ là thông tin đăng nhập - họ là những người có thể khiến bạn bị sa thải. Nếu họ vô tình làm rơi cơ sở dữ liệu hoặc vô hiệu hóa các công việc sao lưu của bạn, họ sẽ không bị sa thải, vì theo mặc định, SQL không theo dõi ai đã làm gì. Bạn là người sẽ bị sa thải bởi vì điều đó sẽ xảy ra, và bạn sẽ không thể nói ai đã làm điều đó.

"Làm thế nào để thực hành tốt nhất tăng tính bảo mật cho các phiên bản SQL Server của tôi?"

Bạn muốn làm hai điều:

1. Ngăn chặn mọi người phá vỡ máy chủ
2. Khi họ phá vỡ máy chủ, có thể xác định chính xác ai đã làm điều đó

Điều đầu tiên được thực hiện với nguyên tắc đặc quyền tối thiểu: chỉ cung cấp cho mọi người những quyền mà họ cần, và không có gì nữa.

Việc thứ hai được thực hiện bằng cách cung cấp cho mỗi người thông tin đăng nhập của riêng họ, không cho phép đăng nhập chung (như cho phép mọi người sử dụng cùng tên người dùng / mật khẩu) và lý tưởng nhất là kiểm tra thông tin đăng nhập. Bạn có thể sẽ không làm phần cuối đó ngay lập tức, vì điều đó thật đau đớn, nhưng hãy đặt các phần đó vào vị trí trước để bạn có thể thêm kiểm toán sau khi ai đó bỏ cơ sở dữ liệu và sếp của bạn muốn biết tại sao.

Tôi biết bạn đang nghĩ gì: "Nhưng chúng tôi đang mã hóa ứng dụng và ứng dụng cần đăng nhập." Có, cung cấp cho ứng dụng thông tin đăng nhập của riêng mình và các nhà phát triển cần biết mật khẩu đó, nhưng thông tin đăng nhập đó phải bị tước quyền mà không ai có thể muốn sử dụng nó. Ví dụ, có thể chỉ cần ở vai trò db_datareader và db_datawriter, không có gì khác. Bằng cách đó, nó có thể chèn, cập nhật, xóa và chọn dữ liệu, nhưng không nhất thiết phải thay đổi lược đồ, thêm chỉ mục, thay đổi thủ tục được lưu trữ, v.v.

"Điều này chỉ áp dụng cho các trường hợp sản xuất, hay cho các trường hợp phát triển nội bộ của chúng tôi nữa?"

Tôi nghĩ rằng nó chỉ áp dụng cho các trường hợp phát triển vì tôi thường lo lắng về việc mọi người phá vỡ mọi thứ. Mọi người chỉ thích phá vỡ các máy chủ trong phát triển. Và tất nhiên, khi đến lúc đưa ra danh sách các thay đổi để chuyển sang sản xuất, tôi cần biết liệu một chỉ mục cụ thể có thực sự quan trọng đối với ứng dụng hay không, liệu một số kẻ đầu não chỉ chạy Trình điều chỉnh cơ sở dữ liệu và bảo nó áp dụng tất cả các thay đổi . Quyền thích hợp giúp giảm bớt nỗi đau đó.

Trên thực tế nếu bạn đọc whitepaper này: SQL Server Tách nhiệm vụ Whitepaper

Nó sẽ cho bạn biết rằng KHÔNG ai nên sử dụng các đặc quyền của sysadmin trên tài khoản của họ. Tài khoản truy cập hàng ngày của bạn nên được cấp quyền truy cập tối thiểu, không phải là quyền sysadmin rõ ràng. Với họ, SERVER SERVER thực sự gần với sysadmin là gì và sau đó cho phép bạn vẫn truy cập DENY / REVOKE khi họ không cần đến nó. Cho phép quyền sysadmin cho bất kỳ ai trở thành một vấn đề nếu bạn được yêu cầu phải đáp ứng bất kỳ tiêu chuẩn tuân thủ CNTT nào. Hầu hết các tiêu chuẩn yêu cầu sử dụng tối thiểu vai trò sysadmin.

Tôi vô hiệu hóa và đổi tên tài khoản "sa", giống như bạn làm với tài khoản quản trị viên tích hợp trên HĐH. Chỉ được sử dụng trong trường hợp khẩn cấp.

Các nhà phát triển thường được cấp quyền truy cập đầy đủ vào môi trường phát triển của họ. Sau đó, khi chương trình của họ được chuyển sang phiên bản tiền sản xuất, quyền truy cập của họ phải ở mức tối thiểu hoặc không có; giống như nó sẽ được sản xuất. Đó là một thế giới hoàn hảo. Tuy nhiên, nếu bạn không ở trong đó và các nhà phát triển của bạn có đặc quyền cao hơn bạn nghĩ họ cần, tôi sẽ kiểm tra tài khoản của họ. Tôi sẽ nắm bắt mọi thứ và bất cứ điều gì họ làm ở một mức độ nào đó. Vì vậy, trong trường hợp có sự cố xảy ra khi họ ở trên máy chủ sản xuất của bạn, bạn có thể quay lại và tìm hiểu chính xác những gì họ đã làm.

Nếu bạn phải tuân theo các tiêu chuẩn hoặc kiểm soát quy định bên ngoài (SOX, PCI, v.v.), thì bạn

• sẽ không kiểm toán
• đang thất bại trong kiểm tra PCI hàng tháng của bạn

Các nhà phát triển nên có db_owner trên SQL Server mạng chỉ để phát triển.

Nếu Máy chủ SQL của bạn là tất cả trên mạng với bản dựng tiêu chuẩn (nghĩa là cùng một tài khoản dịch vụ) thì có một quyền đối với tất cả các quyền.

Nếu tài khoản dịch vụ là quản trị viên cục bộ, thì các nhà phát triển của bạn cũng có toàn quyền kiểm soát các máy chủ.

Không có mặt tích cực.

sa = sysadmin

Đăng nhập bằng sa cung cấp cho người dùng khả năng thực hiện tất cả các thao tác sau: - thả và tạo cơ sở dữ liệu - sửa đổi các đối tượng trong cơ sở dữ liệu - thả và tạo thông tin đăng nhập - thay đổi mật khẩu - xóa tất cả dữ liệu

Cấp một tài khoản windows sysadmin đặc quyền hoàn thành điều tương tự.

Danh sách này tiếp tục, nhưng điều này sẽ cung cấp cho bạn một vài lý do tốt để KHÔNG BAO GIỜ ĐƯỢC MỌI NGƯỜI hãy để một người không phải quản trị viên sử dụng sa.

Bạn nên tạo một tài khoản windows hoặc SQL với các đặc quyền tối thiểu cần thiết để các ứng dụng hoạt động. (tức là đăng nhập, truy cập các thủ tục và lượt xem được lưu trữ)

Thực hành tốt nhất là đặt một số mật khẩu mạnh và quên nó đi.

Tôi có hai lựa chọn trong đầu ngay bây giờ, đó là lý do tại sao một người không nên có tài khoản SA yếu. Nếu bạn có mật khẩu yếu / trống cho SA một kẻ ác (dịch nó thành 'đồng nghiệp thân thiện') có thể:

• kích hoạt thủ tục hệ thống xp_cmdshell và, bằng cách sử dụng các đặc quyền của tài khoản dịch vụ Sql Server, làm hỏng hộp cục bộ của bạn (tạo / xóa tệp ..). Có bảo mật thấp cho SA không thực sự nói nhiều về cài đặt cá thể, nhưng có thể ngụ ý rằng người dùng dịch vụ có thể tuân theo các thực tiễn xấu (như là quản trị viên :-));

• bật thư trên ví dụ của bạn và chuyển nhanh một tập lệnh thư rác nhỏ (điều đó có thể sẽ gây ra cho bạn một số rắc rối với nhà cung cấp internet hoặc với các đồng nghiệp của bạn..tiếp tục xem thư đi đâu ;-));

Tôi sẽ không chỉ ra sự thật hiển nhiên rằng nó có thể bỏ cơ sở dữ liệu, đăng nhập ... vv

• Đó không phải là điều tương tự? Những lợi thế / bất lợi là gì?

• Không nhất thiết: ví dụ: trên phiên bản SQL Server từ máy tính xách tay của bạn, sự khác biệt giữa xác thực Windows và xác thực SQL có nghĩa là về mặt lý thuyết, kẻ tấn công bên ngoài chỉ có thể sử dụng tài khoản SQL, vì xác thực windows không thể được sử dụng bên ngoài miền của chính bạn tài khoản. Một người dùng có thể quét máy tính xách tay hàng xóm từ trung tâm thương mại nơi bạn đang uống cà phê và có thể thấy bạn đã cài đặt và khởi động SQL và có thể thử vui vẻ miễn phí. Không phải là nó có thể xảy ra thường xuyên ... nhưng đó là một khả năng :-).

• Cách thực hành tốt nhất làm tăng tính bảo mật của các phiên bản SQL Server của tôi?

• Vì mọi thực hành tốt nhất trên thế giới này đều thực hiện công việc của nó .. làm tăng khả năng nhược điểm có thể xảy ra (ví dụ: thực hành tốt nhất khi hoạt động thể chất sẽ làm giảm khả năng bạn giống như tôi .. một củ khoai tây văng) có thể xảy ra nếu không.

• Điều này chỉ áp dụng cho các trường hợp sản xuất, hoặc cho các trường hợp phát triển nội bộ của chúng tôi nữa?

• Hãy nói rằng tôi đề nghị thực hiện các thực tiễn tốt nhất về bảo mật (đã được thử nghiệm và sửa đổi theo nhu cầu của môi trường của bạn) ít nhất là trong sản xuất. Nhưng nếu trong quá trình phát triển, bạn cũng sử dụng dữ liệu sản xuất (nhạy cảm..v.v) hơn là một dấu hiệu mạnh mẽ về việc bạn cũng phải thay đổi thực tiễn phát triển của mình.

Giải quyết câu hỏi cuối cùng của bạn, chúng tôi sử dụng tài khoản SA trên tất cả các cơ sở dữ liệu phát triển của chúng tôi (với mật khẩu "sa", tại đó!)

Tuy nhiên, điều quan trọng cần lưu ý là chúng tôi không lưu trữ dữ liệu và chúng tôi không tạo dữ liệu. Cơ sở dữ liệu của chúng tôi chỉ được sử dụng cho kho dữ liệu cho ứng dụng C / C ++. Các cơ sở dữ liệu phát triển này hoàn toàn chứa dữ liệu thử nghiệm và thường xuyên được tạo, bỏ, sửa đổi, v.v. \

Ngoài ra, cũng quan trọng, tất cả các cơ sở dữ liệu phát triển được cài đặt trên các máy phát triển. (Ít nhất một bản sao cho mỗi nhà phát triển, ít nhất!) Vì vậy, nếu ai đó làm hỏng toàn bộ cài đặt, họ chỉ tự làm hỏng bản thân mình chứ không phải ai khác.

Khi nói đến một môi trường mà bạn muốn đảm bảo rằng cơ sở dữ liệu, bảng và dữ liệu của bạn thực sự phù hợp và an toàn, thì bạn muốn có một mật khẩu SA đẹp, chắc chắn. Nếu bạn để yếu thế này thì bất kỳ ai và mọi người đều có quyền truy cập đầy đủ vào dữ liệu của bạn và hoàn toàn có thể phá hủy cơ sở dữ liệu của bạn.

Đối với một nhóm các nhà phát triển với các bản sao cơ sở dữ liệu của riêng họ hoàn toàn chứa dữ liệu thử nghiệm, tôi vẫn chưa tìm thấy một đối số chắc chắn để duy trì tài khoản SA mạnh.

Bất kỳ tham số bảo mật hệ thống SQL Server mặc định nào được cung cấp phải được sửa đổi. Bạn không nên sử dụng chế độ hỗn hợp (cho phép xác thực cả Windows và SQL Server) để xác thực. Thay vào đó, chỉ chuyển sang xác thực Windows - sẽ thực thi chính sách mật khẩu Windows - kiểm tra độ dài mật khẩu, tuổi thọ và lịch sử. Tính năng của chính sách mật khẩu Windows làm cho nó khác với xác thực Máy chủ SQL là khóa đăng nhập - sau một số lần đăng nhập thất bại liên tiếp, đăng nhập sẽ bị khóa và không thể sử dụng được để sử dụng thêm

Mặt khác, xác thực Máy chủ SQL không cung cấp bất kỳ phương pháp nào để phát hiện các nỗ lực tấn công vũ phu và tệ hơn nữa, SQL Server thậm chí còn được tối ưu hóa để xử lý số lượng lớn các nỗ lực đăng nhập nhanh. Vì vậy, nếu xác thực Máy chủ SQL là bắt buộc trong một hệ thống Máy chủ SQL cụ thể, bạn nên vô hiệu hóa đăng nhập SA