Sqlserver
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Sqlserver

Xác thực SQL Server so với xác thực Windows:Sử dụng cái nào và khi nào

Xác thực là một thành phần quan trọng của bất kỳ chiến lược bảo mật nào. Hôm nay, chúng ta sẽ thảo luận về xác thực SQL Server và cách nó cần thiết để bảo mật môi trường SQL Server của bạn và vai trò của xác thực Windows.

Thiết lập kết nối

Tất cả bắt đầu với một kết nối. Để thiết lập kết nối cơ sở dữ liệu thành công, máy khách hoặc ứng dụng yêu cầu thông tin sau:

  • Tên miền đủ điều kiện của SQL Server
  • Tên phiên bản
  • Số cổng
  • Thông tin xác thực (tên người dùng và mật khẩu) để xác thực

Ví dụ:giả sử bạn sử dụng ngân hàng trực tuyến. Để truy cập tài khoản của bạn, bạn phải nhập thông tin đăng nhập cho mục đích xác thực. Ngân hàng nhận dạng bạn khi bạn cung cấp thông tin xác thực hợp lệ và cho phép truy cập vào các dịch vụ của ngân hàng khi xác minh.

Tương tự, khi đăng nhập vào SQL Server, người dùng cần chỉ định thông tin xác thực hợp lệ để SQL Server có thể xác thực danh tính của họ và cấp quyền truy cập thích hợp.

SQL Server cung cấp hai chế độ xác thực máy chủ:

  • Xác thực Windows
  • Chế độ xác thực SQL Server và Windows (chế độ hỗn hợp)

Bạn có thể xác định các phương thức xác thực này trong quá trình cài đặt SQL Server hoặc thay đổi chúng sau đó thông qua khởi động lại. Điều quan trọng là quản trị viên cơ sở dữ liệu phải hiểu sự khác biệt giữa các phương pháp xác thực này và triển khai chúng theo yêu cầu cụ thể của tổ chức họ.

Hãy đi sâu hơn để hiểu những ưu điểm và nhược điểm của xác thực cả SQL Server và Windows.

Tổng quan về xác thực SQL Server

Quản trị viên cơ sở dữ liệu tạo thông tin đăng nhập SQL và cung cấp quyền thích hợp để người dùng tự xác thực với SQL Server. Người dùng cần chỉ định thông tin đăng nhập và mật khẩu khi kết nối với SQL Server như hình dưới đây.

Thông tin đăng nhập của người dùng được xác thực thông qua thông tin được lưu trữ trong cơ sở dữ liệu chính. Bạn có thể thực thi các chính sách sau cho thông tin đăng nhập SQL Server.

  • Thực thi chính sách mật khẩu :Quản trị viên có thể chọn tùy chọn này để triển khai chính sách mật khẩu Windows cho thông tin đăng nhập SQL Server. Nó bao gồm việc chỉ định độ dài và độ phức tạp của mật khẩu.
  • Thực thi hết hạn mật khẩu :Bạn có thể thực thi độ tuổi tối đa của mật khẩu. Mật khẩu sẽ hết hạn và cần thay đổi theo tiêu chí độ tuổi đã xác định.
  • Người dùng phải thay đổi mật khẩu ở lần đăng nhập tiếp theo :Người quản trị chỉ định mật khẩu trong quá trình tạo đăng nhập SQL. Sau khi người dùng đăng nhập bằng thông tin đăng nhập của họ, họ cần chỉ định mật khẩu mới và quản trị viên sẽ không biết mật khẩu mới này.

Lưu ý:Tất cả các cấu hình này đều ở cấp độ đăng nhập SQL riêng lẻ. Do đó, nếu bạn cần tạo nhiều thông tin đăng nhập SQL, bạn phải định cấu hình từng tài khoản với chính sách bắt buộc.

Chúng tôi không thể chỉ kích hoạt xác thực SQL. Để kích hoạt nó, hãy sử dụng tùy chọn xác thực hỗn hợp bao gồm cả xác thực Windows và SQL.

Nhược điểm của xác thực SQL Server

Có một số hạn chế và nhược điểm của việc sử dụng xác thực SQL Server một mình.

  • Người dùng cần nhớ thông tin xác thực đăng nhập SQL và cung cấp chúng trong chuỗi kết nối mỗi khi họ kết nối với SQL Server. Nếu bạn có nhiều Máy chủ SQL, người dùng có thể khó theo dõi mật khẩu cho từng trường hợp.
  • SQL Server lưu trữ mật khẩu trong cơ sở dữ liệu chính ở dạng mã hóa (băm). Tin tặc có thể đánh cắp thông tin bằng cách truy cập vào cơ sở dữ liệu. Vì các thông tin đăng nhập được mã hóa này cần phải được chuyển qua mạng, điều này có thể làm tăng khả năng bị đánh cắp thông tin đăng nhập của người dùng.
  • Bạn không thể triển khai các chính sách tài khoản bổ sung (tùy chỉnh) với thông tin đăng nhập xác thực Máy chủ SQL.
  • Nó làm tăng nhiệm vụ quản lý đăng nhập cho người quản trị cơ sở dữ liệu. Quản trị viên cơ sở dữ liệu không có bảng điều khiển quản lý trung tâm để quản lý thông tin đăng nhập trên tất cả các trường hợp.

Giả sử bạn có hơn 500 trường hợp SQL và người dùng yêu cầu quyền truy cập vào tất cả các trường hợp này. Trong trường hợp này, sẽ là một công việc tẻ nhạt đối với người quản trị cơ sở dữ liệu để kết nối với từng phiên bản và tạo thông tin đăng nhập của người dùng. Tương tự, nếu một người rời khỏi tổ chức, quản trị viên cơ sở dữ liệu cần tìm ra thông tin đăng nhập SQL của cá nhân đó và xóa họ khỏi tất cả các trường hợp này. Đây có thể là một quá trình rất tốn thời gian.

  • Bạn có thể gặp sự cố người dùng mồ côi khi di chuyển cơ sở dữ liệu sang các phiên bản khác nhau và điều này có thể xảy ra do SID không khớp trong cơ sở dữ liệu chính và cơ sở dữ liệu người dùng trên phiên bản mới.
  • Bạn cần quản lý các chính sách bảo mật cho mỗi lần đăng nhập SQL. Bạn không thể xác định một chính sách chung cho tất cả các tài khoản trong tổ chức của mình. Đối với cơ sở dữ liệu lớn, việc xác định chính sách cho từng lần đăng nhập cá nhân là một nhiệm vụ khó khăn.

Các trường hợp sử dụng tốt nhất để xác thực SQL Server

  • Nó có thể giúp các ứng dụng cũ hơn và phần mềm của bên thứ ba kết nối cơ sở dữ liệu nếu chúng không hỗ trợ xác thực Windows (AD).
  • Bạn có thể yêu cầu người dùng từ các miền không đáng tin cậy kết nối với SQL Server. Trong trường hợp này, ứng dụng có thể chỉ định thông tin đăng nhập SQL trong chuỗi kết nối và kết nối với cơ sở dữ liệu.
  • Để kết nối các phiên bản SQL độc lập không thuộc nhóm Active Directory (AD).
  • Nó có thể giúp SQL Server hỗ trợ các ứng dụng web nơi người dùng tạo danh tính riêng của họ.
  • Các quản trị viên chia sẻ một ID chung để kết nối với SQL Server bằng cách sử dụng xác thực Active Directory trong một số trường hợp. Việc gộp kết nối này không phải là một thực tiễn tốt. Trong trường hợp này, bạn có thể tạo thông tin đăng nhập riêng cho từng người dùng và kết nối với cơ sở dữ liệu bằng thông tin đăng nhập của họ.
  • Theo mặc định, nếu bạn triển khai Cơ sở dữ liệu SQL trên đám mây, tức là Cơ sở dữ liệu SQL Azure hoặc AWS RDS, bạn sẽ được cung cấp thông tin đăng nhập để xác thực Máy chủ SQL. Sau đó, nếu được yêu cầu, bạn có thể định cấu hình xác thực dựa trên AD.
  • Bạn có thể sử dụng nó để kết nối từ nhiều hệ điều hành như Linux và macOS.

Tổng quan về xác thực Windows

Trong xác thực Windows, trước tiên người dùng phải tự xác thực trong Active Directory. SQL Server xác thực người dùng thông qua mã thông báo chính của Windows trong hệ điều hành. Cùng với đó, SQL Server không yêu cầu mật khẩu để xác thực danh tính. Do đó, Windows xác nhận danh tính của người dùng để xác thực. SQL Server không lưu trữ thông tin xác thực trong xác thực Windows. Kết nối sử dụng xác thực Windows được gọi là kết nối đáng tin cậy hoặc tích hợp.

Lưu ý:Xác thực Windows là phương thức xác thực mặc định khi bạn cài đặt SQL Server.

Ưu điểm của xác thực Windows

  • Xác thực Windows là một cách kết nối an toàn với SQL Server và nó sử dụng mã thông báo và SPN cho mục đích xác thực bằng giao thức xác thực Kerberos. Do đó, nó không gửi mật khẩu qua mạng và bảo vệ an toàn khi đánh cắp mật khẩu trên toàn mạng.
  • Máy chủ SQL không lưu trữ thông tin đăng nhập của người dùng.
  • Nó sử dụng giao thức bảo mật Kerberos và bạn có thể triển khai các chính sách mật khẩu như mật khẩu phức tạp, khóa tài khoản và hết hạn mật khẩu. Chính sách mật khẩu này có thể được thực hiện ở cấp độ tổ chức trên tất cả các máy chủ. Do đó, bạn có thể kiểm soát các chính sách bảo mật của người dùng ở cấp tổ chức thay vì ở cấp đăng nhập cá nhân như với xác thực SQL Server.
  • Xác thực Windows cho phép phân tách các nhiệm vụ. Nhóm Active Directory (AD) quản lý người dùng AD. Trong khi đó, DBA thêm người dùng AD trong các phiên bản SQL và cung cấp các quyền thích hợp.
  • Active Directory giúp tạo các nhóm Windows. Nhóm AD có thể thêm nhiều người yêu cầu quyền truy cập như nhau trong một nhóm AD. Sau đó, bạn có thể thêm nhóm trong phiên bản SQL và cung cấp quyền ở cấp nhóm. Do đó, nếu một người mới tham gia, khi anh ta là một phần của nhóm AD, quyền truy cập cơ sở dữ liệu sẽ tự động được cấp trên máy chủ nơi nhóm AD này tồn tại. Tương tự, sau khi người dùng chuyển khỏi tổ chức và ID của họ bị xóa khỏi các nhóm AD này, họ sẽ không thể truy cập cơ sở dữ liệu được nữa.

Nhược điểm của xác thực Windows

  • Nếu bạn chỉ sử dụng xác thực Windows cho SQL Server, tất cả người dùng phải là một phần của Active Directory.
  • DBA không có quyền kiểm soát các nhóm và thông tin đăng nhập AD.
  • Tư cách thành viên nhóm AD không được DBA biết. Bạn sẽ không nhận được thông báo nếu người dùng được thêm vào hoặc bị xóa khỏi nhóm QUẢNG CÁO.

Tóm tắt

Bài đăng trên blog này phác thảo các thành phần chính của xác thực SQL Server và xác thực Windows. Tôi hy vọng nó sẽ giúp bạn hiểu sự khác biệt giữa các phương pháp xác thực này để quyết định phương pháp nào phù hợp nhất với doanh nghiệp và hoàn cảnh của bạn.

Xác thực SQL Server có thể được sử dụng trên cùng một máy với SQL Server hoặc trên một kết nối từ xa. Nếu bạn làm việc trong môi trường Active Directory, bạn nên sử dụng xác thực Windows. Nếu bạn làm việc trong môi trường không phải Active Directory, bạn có thể sử dụng xác thực SQL Server cho các kết nối cơ sở dữ liệu.

Xác thực Windows cung cấp tính bảo mật và tính linh hoạt hơn để quản lý thông tin đăng nhập trong SQL Server. Do đó, bạn nên sử dụng nó bất cứ khi nào khả thi.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Ví dụ về SQRT () trong SQL Server

  2. Cách thay thế một chuỗi trong cột bảng SQL Server

  3. Khôi phục sao lưu cơ sở dữ liệu SQL Server trên phiên bản thấp hơn

  4. Các tính năng ẩn của SQL Server

  5. Tạo một UDF liên kết lược đồ trong SQL Server