Tiêu chuẩn PCI có cấm sử dụng Windows xác thực không?

Chúng tôi hiện đang sử dụng Chế độ hỗn hợp cho Xác thực máy chủ SQL của chúng tôi. Tôi đã cố gắng thuyết phục DBA của chúng tôi cho phép chúng tôi sử dụng Windows xác thực để chúng tôi có thể sử dụng Team Foundation Server, tuy nhiên anh ấy hoàn toàn từ chối cho phép chúng tôi có nó.

Theo anh ta, chúng tôi không thể có Xác thực Windows vì chúng tôi dự định cuối cùng sẽ tuân thủ PCI và PCI yêu cầu Chế độ hỗn hợp. Từ những gì tôi thấy trực tuyến, nó ngược lại: Tiêu chuẩn PCI thực sự thích Xác thực Windows hơn Chế độ hỗn hợp.

Ai đó có thể cho tôi thêm một số thông tin về điều này (tốt nhất là một URL nêu thông tin chính xác) để tôi có thể gửi nó cho người đứng đầu bộ phận của chúng tôi không?

Không.

Như bạn đã đề xuất, Tiêu chuẩn bảo mật dữ liệu PCI thực sự thích Xác thực Windows hơn bất kỳ phương tiện xác thực nào khác với SQL Server.

Phần của tiêu chuẩn bao gồm điều này là Yêu cầu 8: Gán một ID duy nhất cho mỗi người có quyền truy cập máy tính . Xác thực Máy chủ SQL (mà xác thực Chế độ hỗn hợp cho phép) không thành công hoặc gây khó khăn cho việc đáp ứng các yêu cầu PCI sau :

8.5.5 Xóa / vô hiệu hóa tài khoản người dùng không hoạt động ít nhất 90 ngày một lần.

8.5.8 Không sử dụng các tài khoản và mật khẩu chung, chung hoặc chung hoặc các phương thức xác thực khác.

8.5.12 Không cho phép một cá nhân gửi mật khẩu mới giống với bất kỳ mật khẩu nào trong bốn mật khẩu cuối cùng mà họ đã sử dụng

Là quản trị viên, vấn đề chính tôi gặp phải khi cho phép xác thực Máy chủ SQL là ứng dụng kết nối với cơ sở dữ liệu của bạn có khả năng sẽ kéo tên người dùng và mật khẩu bằng văn bản thuần từ tệp cấu hình . Bất kỳ ai có quyền truy cập đọc vào tệp cấu hình đó bây giờ cũng có quyền truy cập vào cơ sở dữ liệu của bạn.

Nếu bạn đang ở trong một cửa hàng Windows có thiết lập Active Directory mạnh mẽ, chỉ sử dụng Xác thực Windows để kết nối với cơ sở dữ liệu sản xuất của bạn sẽ mang lại nhiều lợi ích:

• Bảo mật và danh tính được thực thi ở cấp tên miền, giúp dễ dàng trao đổi và thu hồi quyền trên toàn miền.

  • Mỗi người và dịch vụ có một tài khoản miền riêng; tài khoản dịch vụ không thể truy cập vào máy và tài khoản người không phải DBA không thể kết nối với cơ sở dữ liệu.
  • Nhóm DBA của bạn không còn có thể chia sẻ thông tin đăng nhập DBA SQL Server với quyền của Chúa trên mọi trường hợp trong môi trường của bạn.
• Mặc dù SQL Server không cho phép bạn thực thi các quy tắc phức tạp về mật khẩu (mà bạn phải thực thi theo các yêu cầu PCI DSS 8.5.9-11), tôi cá rằng AD làm điều này tốt hơn. Ngoài ra, bạn có thực sự muốn thực thi các quy tắc này ở hai nơi khác nhau không?
• Các ứng dụng kết nối bằng Windows xác thực không còn có thể hiển thị thông tin đăng nhập của họ trong văn bản thuần túy. Sẽ khó hơn nhiều khi ai đó mở tệp cấu hình hoặc máy chủ ứng dụng và truy cập vào cơ sở dữ liệu của bạn.

Nếu bạn đang đề cập đến việc tuân thủ PCI cho ngành thẻ tín dụng, có Windows xác thực được ưu tiên. Tìm kiếm cụm từ này trên Google : "Thực tiễn tốt nhất về bảo mật SQL Server"

Hai liên kết hàng đầu, đặc biệt là liên kết đầu tiên, sẽ liên kết bạn với tài liệu mà Windows xác thực được ưa thích. Cái đầu tiên là một liên kết đến whitepaper thực hành tốt nhất cho SQL 2005 nhưng áp dụng cho tất cả các phiên bản SQL Server ở trên.

Tôi liên quan đến việc quét bảo mật trên cơ sở dữ liệu và các trường hợp bắt buộc phải đáp ứng các tiêu chuẩn DoD và Xác thực Windows cũng được ưu tiên ở đó. Tôi cũng đã trải qua các cuộc kiểm tra tuân thủ PCI và họ sẽ có xu hướng tìm kiếm Xác thực Windows.

Không có quy định tuân thủ nào (ví dụ: PCI, HIPAA, GLBA, Basel II, FERPA hoặc SOX) cấm chế độ Xác thực Windows

Trên thực tế, không nên sử dụng hệ thống được cung cấp và các tham số bảo mật khác trên SQL Server. Thay vì sử dụng chế độ hỗn hợp (cho phép xác thực cả Windows và xác thực SQL Server), chỉ sử dụng xác thực Windows. Nó sử dụng chính sách mật khẩu Windows để truy cập SQL Server. Điều này cho phép kiểm tra lịch sử mật khẩu, độ dài tối thiểu của mật khẩu và tuổi thọ tối thiểu và tối đa của mật khẩu. Các đặc điểm chính sách mật khẩu quan trọng nhất của Windows là khóa đăng nhập - nếu đăng nhập liên tục thất bại trong một số lần được chỉ định

Khi nói đến lỗ hổng tấn công brute-force xác thực SQL Server, tình hình không mấy thuận lợi. Xác thực Máy chủ SQL không có tính năng nào cho phép phát hiện khi hệ thống bị tấn công vũ phu. Hơn nữa, SQL Server rất nhạy khi xác thực thông tin xác thực SQL Server. Nó có thể dễ dàng xử lý các nỗ lực đăng nhập lặp đi lặp lại, hung hăng, mạnh mẽ mà không có hiệu suất tổng thể tiêu cực có thể chỉ ra các cuộc tấn công như vậy. Điều này có nghĩa là Xác thực Máy chủ SQL là một mục tiêu hoàn hảo để bẻ khóa mật khẩu thông qua các cuộc tấn công vũ phu

Ngoài ra, các phương thức brute-force đang phát triển với mỗi phương thức mã hóa và mật khẩu phức tạp mới được giới thiệu. Ví dụ: những kẻ tấn công sử dụng các bảng cầu vồng (các bảng được tính toán trước để đảo ngược các giá trị băm mật mã cho mọi tổ hợp ký tự có thể) có thể dễ dàng và nhanh chóng bẻ khóa bất kỳ mật khẩu băm nào