Bàn giao quyền truy cập cho kiểm thử bảo mật: phạm vi, tài khoản và thu hồi

Một người kiểm thử yêu cầu địa chỉ cổng, chi tiết DNS nội bộ và thông tin đăng nhập VPN, và yêu cầu được chuyển tiếp cho bạn với tiêu đề «cần quyền truy cập». Chỉ riêng yêu cầu không cho bạn biết đây là đánh giá nội bộ, kiểm thử ứng dụng có xác thực hay công việc trên một trang web công khai mà ai đó đã hiểu sai phạm vi. Hãy thực hiện bàn giao như một chuỗi có cổng ở từng bước, và dừng ở cổng đầu tiên không mở. Điều đó biến một yêu cầu mơ hồ thành thứ bạn có thể ủy quyền, bàn giao và sau này thu hồi.

Bắt đầu từ ủy quyền, không phải từ thông tin đăng nhập

Trước khi bất kỳ địa chỉ nào rời hộp thư của bạn, hãy xác lập ai sở hữu các mục tiêu và ai được phép phê duyệt kiểm thử trên chúng. Xác minh người kiểm thử thông qua đầu mối của hợp đồng mà tổ chức bạn đã dùng, không qua người chuyển tiếp email. Quan hệ khách hàng không phải là quyền kiểm thử mọi hệ thống tiếp cận được từ một tài khoản, và đơn đặt hàng không phải là tài liệu phạm vi.

Viết mục tiêu đã phê duyệt trong một câu và giữ nó bên cạnh bản bàn giao. «Đánh giá xác thực của cổng khách hàng» và «đánh giá mạng nội bộ» dẫn tới những gói hoàn toàn khác nhau, và khác biệt đó phải được giải quyết trước khi cấp phát, không phải sau khi phát hiện được ghi nhận. Câu đó cũng cho bạn thứ để chỉ vào khi yêu cầu lớn dần giữa công việc.

Nếu có nhà cung cấp dịch vụ lưu trữ hoặc bên thứ ba khác trên đường đi, yêu cầu của họ đứng trước sự thuận tiện của bạn. Kiểm thử hạ tầng của người khác mà không có sự cho phép của họ là vấn đề khác với kiểm thử ứng dụng chạy trên đó.

Nêu rõ góc nhìn và mục tiêu

Góc nhìn là câu hỏi mà đánh giá cố gắng trả lời, và nó quyết định gói truy cập nhiều hơn bất kỳ công cụ nào người kiểm thử định dùng. Một bài kiểm thử công khai không xác thực cần URL và khung thời gian. Một bài kiểm thử có xác thực cần tài khoản riêng cho các vai trò cụ thể trong phạm vi, và đánh giá nội bộ cần một điểm vào xác định với dải mục tiêu rõ ràng.

Nơi đường hầm đi vào không phải cùng một sự thật với việc ứng dụng nào đứng sau nó, và nó chắc chắn không cho phép thăm dò điểm vào. Hãy nói rõ điều đó trong bản bàn giao, vì câu «bạn đã cho tôi quyền truy cập vào subnet đó» đến rất nhanh khi một phát hiện bị tranh cãi. Danh sách mục tiêu bằng văn bản là thứ duy nhất giải quyết điều đó về sau.

Cung cấp tên máy chủ TLS cùng với URL. Một địa chỉ IP trần buộc người kiểm thử đoán tên, và tên đoán được tạo ra lỗi chứng chỉ được báo cáo như phát hiện thay vì như lỗi bàn giao.

Cấp danh tính riêng có ngày hết hạn

Cấp phát tài khoản chỉ tồn tại cho công việc này; đừng cho mượn đăng nhập hằng ngày của một nhân viên. Đặt khả năng tiếp cận mạng và quyền ứng dụng theo các nhiệm vụ đã thỏa thuận, sắp xếp đăng ký xác thực qua một đường được hỗ trợ, và đính kèm ngày hết hạn cùng một người được nêu tên chịu trách nhiệm thu hồi. Bàn giao thông tin đăng nhập qua kênh an toàn đã thỏa thuận, tách khỏi tài liệu phạm vi vốn được chuyển vòng quanh.

sudo useradd -m -e 2026-12-31 tester01
sudo passwd -S tester01
id tester01
lastlog -u tester01

Ghi lại ai nhận gì, và khi nào. Bản ghi đó là khác biệt giữa một bàn giao có kiểm soát và một mật khẩu chia sẻ mà không ai truy vết được, và đó là thứ đầu tiên mọi người hỏi sau một sự cố. Giữ nó cùng với tài liệu phạm vi thay vì trong một luồng chat, và ghi kênh bàn giao bên cạnh người nhận. Một dòng có dấu thời gian luôn thắng ký ức.

Trường ngày hết hạn là lưới an toàn, không phải kế hoạch. Vẫn phải có người gỡ đường mạng và vai trò ứng dụng vào cuối, vì một đăng nhập hết hạn trên mạng vẫn còn tiếp cận được không phải là quyền truy cập đã bị thu hồi.

Chứng minh bàn giao hoạt động trước khi khung giờ mở

Tự thực hiện bước nhảy đầu tiên của người kiểm thử, từ vị trí gần nhất có thể với vị trí của họ. Phân giải tên, kiểm tra danh tính chứng chỉ và xác nhận đường đi tới địa chỉ dự định chứ không phải địa chỉ lân cận.

dig +short app.example.com
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates
ip route get 10.60.0.25

Nếu đường đi không tới được mục tiêu, hãy dừng và hòa giải bàn giao thay vì để người kiểm thử tự tìm một tuyến thay thế. Khả năng tiếp cận tùy ứng chính là cách một đánh giá âm thầm vượt ra ngoài phạm vi, và nó gần như không bao giờ được ghi lại sau đó.

Gửi đầu mối vận hành, giờ được phép, hành động bị loại trừ và điều kiện dừng cùng với thông tin đăng nhập. Một người kiểm thử không liên hệ được ai lúc 02:00 sẽ đưa ra quyết định mà bạn không ủy quyền, và quyết định đó sẽ được mô tả trong báo cáo như thể nằm trong phạm vi.

NIST SP 800-115 định hình một đánh giá kỹ thuật là kiểm thử có kế hoạch, sau đó phân tích và giảm thiểu, và đó là hình dạng mà bản bàn giao này theo. Các cổng ở trên là lựa chọn thiết kế biên tập cho một kỹ sư hỗ trợ, không phải danh mục kiểm tra trích từ ấn phẩm đó.

Kết thúc công việc bằng cách gỡ bỏ quyền truy cập

Thu hồi theo thứ tự ngược với lúc cấp phát: vai trò ứng dụng, rồi quyền truy cập mạng, rồi chính danh tính. Xác nhận từng bước thay vì cho rằng bảng điều khiển đã làm điều nút bấm hứa. Khóa tài khoản trước khi giết các phiên của nó, nếu không phiên sẽ chỉ xác thực lại qua đường cũ. Sau đó kiểm tra các kết nối đã thiết lập một lần nữa trước khi tuyên bố đã đóng.

sudo passwd -l tester01
sudo pkill -u tester01
ss -tn state established '( sport = :443 )'

Xử lý mọi dữ liệu kiểm thử còn lưu, rồi theo dõi việc khắc phục qua quy trình báo cáo đã thỏa thuận ban đầu. Báo cáo nên nêu môi trường, mức truy cập, phạm vi và các giới hạn, vì nó ghi lại phát hiện của một lần đánh giá chứ không phải tuyên bố vĩnh viễn rằng trang web an toàn.

Giữ bản ghi thu hồi cùng với bản ghi bàn giao. Khi công việc tiếp theo mở ra, bạn muốn biết chính xác lần trước đã gỡ gì và ai phê duyệt, thay vì dựng lại bức tranh từ ký ức.