Các phương pháp hay nhất để bảo mật phần quản trị của một trang web là gì? [đóng cửa]

Tôi muốn biết những gì mọi người coi là phương pháp hay nhất để bảo mật phần Quản trị của các trang web, cụ thể là từ quan điểm xác thực / truy cập.

Tất nhiên có những điều hiển nhiên, chẳng hạn như sử dụng SSL và ghi lại tất cả quyền truy cập, nhưng tôi tự hỏi chỉ ở trên các bước cơ bản này mà mọi người coi thanh được đặt ở đâu.

Ví dụ:

• Bạn chỉ dựa trên cùng một cơ chế xác thực mà bạn sử dụng cho người dùng bình thường? Nếu không, thì sao?
• Bạn có đang chạy phần Quản trị trong cùng một 'miền ứng dụng' không?
• Bạn thực hiện những bước nào để làm cho phần quản trị không bị phát hiện? (hay bạn bác bỏ toàn bộ điều 'tối nghĩa')

Cho đến nay, các đề xuất từ ​​người trả lời bao gồm:

• Giới thiệu tạm dừng phía máy chủ nhân tạo trong mỗi lần kiểm tra mật khẩu quản trị viên để ngăn chặn các cuộc tấn công vũ phu [Nghệ thuật của nhà phát triển]
• Sử dụng các trang đăng nhập riêng biệt cho người dùng và quản trị viên bằng cách sử dụng cùng một bảng DB (để ngăn XSRF và đánh cắp phiên cấp quyền truy cập vào các khu vực quản trị) [Thief Master]
• Cũng nên xem xét thêm xác thực gốc máy chủ web vào khu vực quản trị (ví dụ: thông qua .htaccess) [Thief Master]
• Cân nhắc chặn IP của người dùng sau một số lần đăng nhập quản trị viên không thành công [Thief Master]
• Thêm hình ảnh xác thực sau khi đăng nhập không thành công của quản trị viên [Thief Master]
• Cung cấp các cơ chế mạnh như nhau (sử dụng các kỹ thuật trên) cho người dùng cũng như quản trị viên (ví dụ: không đối xử đặc biệt với quản trị viên) [Lo'oris]
• Xem xét xác thực cấp độ thứ hai (ví dụ: chứng chỉ ứng dụng khách, thẻ thông minh, không gian thẻ, v.v.) [JoeGeeky]
• Chỉ cho phép truy cập từ các IP / Miền đáng tin cậy, thêm kiểm tra vào đường ống HTTP cơ bản (thông qua ví dụ: HttpModules) nếu có thể. [JoeGeeky]
• [ASP.NET] Khóa IPrincipal & Hiệu trưởng (biến chúng thành bất biến và không thể liệt kê được) [JoeGeeky]
• Nâng cao quyền liên kết - ví dụ: gửi email cho các quản trị viên khác khi bất kỳ quyền nào của quản trị viên được nâng cấp. [JoeGeeky]
• Xem xét các quyền chi tiết dành cho quản trị viên - ví dụ: thay vì quyền dựa trên vai trò, hãy xác định quyền cho các hành động chỉ định cho mỗi quản trị viên [JoeGeeky]
• Hạn chế tạo quản trị viên - ví dụ: Quản trị viên không thể thay đổi hoặc tạo tài khoản quản trị viên khác. Sử dụng ứng dụng khách 'superadmin' bị khóa cho việc này. [JoeGeeky]
• Xem xét Chứng chỉ SSL phía máy khách hoặc bàn phím loại RSA (mã thông báo điện tử) [Daniel Papasian]
• Nếu sử dụng cookie để Xác thực, hãy sử dụng cookie riêng cho trang quản trị và trang bình thường, bằng cách đặt phần quản trị viên trên một miền khác. [Daniel Papasian]
• Nếu thực tế, hãy cân nhắc giữ trang quản trị trên một mạng con riêng tư, không kết nối Internet công cộng. [John Hartsock]
• Phát hành lại vé xác thực / phiên khi di chuyển giữa các bối cảnh quản trị / sử dụng bình thường của trang web [Richard JP Le Guen]

Đây đều là những câu trả lời hay ... Tôi thường muốn thêm một vài lớp bổ sung cho các phần quản trị của mình. Mặc dù tôi đã sử dụng một vài biến thể trên một chủ đề, nhưng chúng thường bao gồm một trong những điều sau:

• Xác thực cấp thứ hai : Điều này có thể bao gồm chứng chỉ ứng dụng khách (Ví dụ: x509 chứng chỉ), thẻ thông minh, không gian thẻ, v.v.
• Hạn chế tên miền / IP : Trong trường hợp này, chỉ những khách hàng đến từ các miền đáng tin cậy / có thể xác minh; chẳng hạn như mạng con nội bộ; được phép vào khu vực quản trị. Quản trị viên từ xa thường đi qua các điểm vào VPN đáng tin cậy để phiên của họ có thể được xác minh và cũng thường được bảo vệ bằng các khóa RSA. Nếu bạn đang sử dụng ASP.NET, bạn có thể dễ dàng thực hiện các kiểm tra này trong HTTP Pipeline thông qua Mô-đun HTTP, điều này sẽ ngăn ứng dụng của bạn nhận được bất kỳ yêu cầu nào nếu kiểm tra bảo mật không được đáp ứng.
• Bị khóa IPrincipal & Ủy quyền dựa trên nguyên tắc: Tạo các Nguyên tắc tùy chỉnh là một thực tế phổ biến, mặc dù một lỗi phổ biến là khiến chúng có thể sửa đổi và / hoặc liệt kê các quyền. Mặc dù đây không chỉ là vấn đề quản trị, nhưng vấn đề quan trọng hơn vì đây là nơi người dùng có thể có các quyền cao hơn. Hãy chắc chắn rằng chúng là bất biến và không thể liệt kê được. Ngoài ra, hãy đảm bảo rằng tất cả các đánh giá để Ủy quyền được thực hiện dựa trên Hiệu trưởng.
• Nâng cao quyền liên kết : Khi bất kỳ tài khoản nào nhận được một số quyền đã chọn, tất cả quản trị viên và nhân viên bảo mật sẽ được thông báo ngay lập tức qua email. Điều này đảm bảo rằng nếu kẻ tấn công nâng cao quyền, chúng tôi sẽ biết ngay. Các quyền này thường xoay quanh các quyền riêng tư, quyền xem thông tin được bảo vệ quyền riêng tư và / hoặc thông tin tài chính (ví dụ: thẻ tín dụng).
• Cấp quyền một cách tiết kiệm, ngay cả cho Quản trị viên : Cuối cùng, và điều này có thể nâng cao hơn một chút đối với một số cửa hàng. Quyền ủy quyền phải kín đáo nhất có thể và phải bao quanh các hành vi chức năng thực sự. Các phương pháp tiếp cận Bảo mật dựa trên vai trò (RBS) điển hình có xu hướng mang tính nhóm . Từ góc độ bảo mật, đây không phải là mô hình tốt nhất. Thay vì ' Nhóm ' như ' Trình quản lý người dùng ', hãy thử chia nhỏ thêm ( Ví dụ: Tạo người dùng, Cấp phép người dùng, Nâng cao / Thu hồi quyền truy cập, v.v.). Điều này có thể có chi phí cao hơn một chút về mặt quản trị, nhưng điều này mang lại cho bạn sự linh hoạt để chỉ chỉ định các quyền thực sự cần thiết bởi nhóm quản trị viên lớn hơn. Nếu quyền truy cập bị xâm phạm thì ít nhất họ có thể không nhận được tất cả các quyền. Tôi muốn kết hợp điều này trong các quyền Bảo mật truy cập mã (CAS) được hỗ trợ bởi .NET và Java, nhưng điều đó nằm ngoài phạm vi của câu trả lời này. Một điều nữa ... trong một ứng dụng, quản trị viên không thể quản lý việc thay đổi các tài khoản quản trị khác hoặc đặt người dùng làm quản trị viên. Điều đó chỉ có thể được thực hiện thông qua một ứng dụng bị khóa mà chỉ một vài người có thể truy cập.

Nếu trang web yêu cầu đăng nhập cho cả hoạt động thông thường và quản trị viên, ví dụ như diễn đàn, tôi sẽ sử dụng thông tin đăng nhập riêng biệt sử dụng cùng một cơ sở dữ liệu người dùng. Điều này đảm bảo rằng XSRF và đánh cắp phiên sẽ không cho phép kẻ tấn công truy cập vào các khu vực quản trị.

Ngoài ra, nếu phần quản trị nằm trong một thư mục con riêng biệt, việc bảo mật thư mục đó bằng xác thực của máy chủ web (.htaccess trong Apache chẳng hạn) có thể là một ý tưởng hay - thì ai đó cần cả mật khẩu đó và mật khẩu người dùng.

Việc che khuất đường dẫn quản trị hầu như không mang lại lợi ích bảo mật - nếu ai đó biết dữ liệu đăng nhập hợp lệ thì rất có thể anh ta cũng có thể tìm ra đường dẫn của công cụ quản trị vì anh ta đã lừa đảo nó hoặc đăng nhập vào bạn hoặc lấy nó thông qua kỹ thuật xã hội (điều này có thể sẽ tiết lộ đường dẫn, quá).

Một biện pháp bảo vệ bạo lực như chặn IP của người dùng sau 3 lần đăng nhập không thành công hoặc yêu cầu CAPTCHA sau khi đăng nhập không thành công (không phải cho lần đăng nhập đầu tiên vì điều đó cực kỳ khó chịu đối với người dùng hợp pháp) cũng có thể hữu ích.

• Tôi từ chối sự mù mờ
• Sử dụng hai hệ thống xác thực thay vì một là quá mức cần thiết
• Người dùng cũng phải tạm dừng nhân tạo giữa các lần thử
• Người dùng cũng nên chặn IP khi không thành công
• Người dùng cũng nên sử dụng mật khẩu mạnh
• Nếu bạn coi hình ảnh xác thực là ổn, hãy đoán xem, bạn cũng có thể sử dụng chúng cho người dùng

Vâng, sau khi viết nó, tôi nhận ra rằng câu trả lời này có thể được tóm tắt là "không có gì đặc biệt đối với đăng nhập quản trị, chúng đều là các tính năng bảo mật nên được sử dụng cho bất kỳ đăng nhập nào".

Nếu bạn chỉ sử dụng một thông tin đăng nhập duy nhất cho người dùng có cả đặc quyền của người dùng bình thường và đặc quyền của quản trị viên, hãy tạo lại mã định danh phiên của họ (có thể là trong cookie hoặc tham số GET hoặc bất kỳ thứ gì ...) khi có sự thay đổi về cấp độ priviledge ... ít nhất.

Vì vậy, nếu tôi đăng nhập, hãy thực hiện một loạt nội dung người dùng bình thường và sau đó truy cập trang quản trị, tạo lại ID phiên của tôi. Sau đó, nếu tôi điều hướng từ (các) trang quản trị sang trang người dùng bình thường, hãy tạo lại ID của tôi.

Có một mật khẩu quản trị tốt.

Không phải "123456"mà là một chuỗi các chữ cái, chữ số và các ký tự đặc biệt đủ dài, chẳng hạn, 15-20 ký tự. Thích "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Thêm tạm dừng cho mỗi lần kiểm tra mật khẩu để ngăn chặn cuộc tấn công vũ phu.

Dưới đây là một số điều khác cần xem xét:

1. Một tùy chọn cần xem xét, đặc biệt nếu bạn quản lý máy tính của quản trị viên hoặc họ có năng lực về mặt kỹ thuật, là sử dụng thứ gì đó dựa trên chứng chỉ SSL để xác thực máy khách. Bàn phím RSA và những gì không có cũng có thể được sử dụng để tăng cường bảo mật.
2. Nếu bạn đang sử dụng cookie - có lẽ cho mã thông báo xác thực / phiên - bạn có thể muốn đảm bảo rằng cookie chỉ được gửi đến các trang quản trị. Điều này giúp giảm thiểu rủi ro gây ra cho trang web của bạn bằng cách đánh cắp cookie, bằng thỏa hiệp lớp 1/2 hoặc XSS. Điều này có thể được thực hiện dễ dàng bằng cách đặt phần quản trị viên trên tên máy chủ hoặc miền khác cũng như đặt cờ bảo mật bằng cookie.
3. Việc hạn chế bằng IP cũng có thể là một cách thông minh và nếu bạn có người dùng trên khắp internet, bạn vẫn có thể thực hiện việc này, nếu có một VPN đáng tin cậy mà họ có thể tham gia.

Chúng tôi sử dụng Windows Authenticationđể truy cập quản trị. Đây là cách thiết thực nhất để bảo vệ các khu vực quản trị trong khi giữ cho xác thực tách biệt khỏi những gì áp dụng cho người dùng cuối nói chung. Quản trị viên hệ thống quản lý thông tin xác thực quyền truy cập của người dùng Quản trị viên và thực thi các chính sách mật khẩu trên tài khoản người dùng miền.

Cách nghiêm ngặt là có hai "trang trại" hoàn chỉnh khác nhau bao gồm cơ sở dữ liệu, máy chủ và tất cả và di chuyển dữ liệu từ trang trại này sang trang trại khác. Hầu hết các hệ thống hiện đại, quy mô lớn đều sử dụng cách tiếp cận này (Làm mờ nét ảnh, SharePoint, v.v.). Nó thường được coi là có các giai đoạn khác nhau "giai đoạn chỉnh sửa" -> "giai đoạn xem trước" -> "giai đoạn phân phối". Phương pháp này cho phép bạn xử lý nội dung / cấu hình giống như cách bạn xử lý mã (dev-> qa-> prod).

Nếu bạn ít hoang tưởng hơn, bạn có thể có một cơ sở dữ liệu duy nhất nhưng chỉ có phần quản trị viên của bạn có sẵn trên các máy chủ "chỉnh sửa". Ý tôi là, chỉ có các tập lệnh / tệp chỉnh sửa được đặt trên máy chủ chỉnh sửa.

Đương nhiên, giai đoạn chỉnh sửa sẽ chỉ khả dụng trên mạng nội bộ và / hoặc sử dụng VPN.

Điều này có vẻ hơi quá mức cần thiết và có thể không phải là giải pháp dễ dàng nhất cho tất cả các trường hợp sử dụng, nhưng nó chắc chắn là cách hoạt động hiệu quả nhất.

Lưu ý rằng những thứ như "có mật khẩu quản trị viên mạnh" là rất tốt, nhưng vẫn để quản trị viên của bạn mở các tùy chọn thông minh.

Nó phụ thuộc rất nhiều vào loại dữ liệu bạn muốn bảo vệ (các yêu cầu pháp lý và như vậy).

• Rất nhiều đề xuất là về xác thực .. Tôi nghĩ bạn chỉ nên xem xét sử dụng xác thực OpenId / Facebook làm đăng nhập. (Họ rất có thể sẽ dành nhiều tài nguyên hơn cho bảo mật xác thực sau đó bạn)

• Lưu các thay đổi cũng như cập nhật các giá trị trong cơ sở dữ liệu. Bằng cách đó, bạn có thể khôi phục các thay đổi từ người dùng X hoặc giữa ngày X và Y.

Tôi không nhận thấy bất kỳ ai đề cập đến việc lưu trữ / xác thực mật khẩu quản trị viên. Xin vui lòng không lưu trữ PW ở dạng văn bản thuần túy, và tốt nhất là không nên lưu trữ thứ gì đó có thể đảo ngược - sử dụng thứ gì đó như băm MD5 muối để ít nhất nếu ai đó tình cờ lấy được "mật khẩu" đã lưu trữ mà họ không có bất cứ thứ gì cực kỳ hữu ích, trừ khi họ cũng có kế hoạch muối của bạn.

Thêm trường mật khẩu và câu hỏi bảo mật mà Quản trị viên sẽ biết, ví dụ: tên bạn gái đầu tiên của bạn là gì hoặc ngẫu nhiên các câu hỏi mỗi khi xem bảng quản trị.

Có lẽ bạn luôn có thể đặt phần quản trị trong một thư mục lớn, ví dụ:

http://domain.com/sub/sub/sub/sub/sub/index.php

Nhưng điều đó không thực sự tốt đâu.

Có lẽ bạn có thể bao gồm một chuỗi truy vấn trong trang chủ, như:

http://domain.com/index.php?display=true

Khi đó, trường tên người dùng và mật khẩu sẽ xuất hiện.