Unlimited Design & Technology

Độ tin cậy và vận hành

Quản lý bí mật mà không đưa vào log triển khai

Log triển khai cần giải thích sự việc mà không trở thành nơi lưu thông tin đăng nhập thứ hai. Hãy rà soát toàn bộ đường đi của bí mật, tách siêu dữ liệu kiểm toán khỏi giá trị và chuẩn bị cách xử lý lộ lọt.

UDT Insights23/04/2023
Một đồng nghiệp giữ chìa khóa két ngoài nhật ký triển khai với chìa khóa bị gạch chéo trên đường truyền. Một đồng nghiệp quỳ dùng cờ lê.

Nhóm cần đủ chi tiết triển khai để điều tra lỗi, nhưng không phải giá trị nào cũng nên xuất hiện trong đó. Mật khẩu, mã truy cập và vật liệu ký cần đường xử lý khác cấu hình thường. Trước khi bật đầu ra chi tiết, hãy quyết định người vận hành cần gì và thông tin nào tuyệt đối không được vào log thường, phiếu hỗ trợ hoặc sản phẩm tạo ra từ quy trình dựng được chia sẻ.

Vẽ toàn bộ đường đi của bí mật

Liệt kê nguồn của từng bí mật triển khai, vai trò lấy nó, thành phần nhận nó và lúc nó hết hiệu lực. Xét cả nhánh lỗi và tệp xuất phục vụ hỗ trợ, không chỉ lần triển khai thành công. Mục tiêu là tìm bản sao ngoài ý muốn trước khi dựa vào tính năng che giá trị.

OWASP nêu bí mật không được xuất hiện dạng rõ trong log và mô tả vòng đời gồm tạo mới, luân chuyển, thu hồi, hết hạn.[5] Dùng vòng đời này để phân công trách nhiệm. Bí mật không có quy trình thay thế hoặc thu hồi là một phương án vận hành chưa hoàn chỉnh.

Ghi việc truy cập, không ghi giá trị

Nên có bản ghi kiểm toán xác định hành động, vai trò được phép, kết quả và tham chiếu bí mật nếu tham chiếu đó an toàn để lộ. Không ghi chính giá trị bí mật. Rà soát quyền xem các bản ghi này vì siêu dữ liệu vận hành vẫn có thể tiết lộ thông tin hữu ích về hệ thống.

Đừng mặc định việc che trên màn hình áp dụng cho mọi nơi nhận đầu ra. Yêu cầu kiểm tra sản phẩm thử nghiệm được phép xem, thông báo lỗi và bản ghi tác vụ được lưu. Dùng giá trị thử không có tác dụng trong diễn tập có kiểm soát, không đưa thông tin đăng nhập thật vào chỉ để chứng minh vấn đề.

Ví dụ giả định: triển khai hóa đơn thất bại

Trong ví dụ giả định này, lần triển khai thất bại khi kết nối dịch vụ hóa đơn với một thành phần bên ngoài. Bộ xử lý lỗi in toàn bộ đối tượng cấu hình. Nhóm nhận ra quy tắc che dự kiến áp dụng cho đầu ra thông thường nhưng không bao phủ nhánh ngoại lệ.

Nhóm đổi thiết kế chẩn đoán để chỉ báo giai đoạn kết nối lỗi và một tham chiếu an toàn. Họ cũng diễn tập quy trình xử lý lộ lọt đã duyệt bằng dữ liệu giả. Ví dụ mô tả rà soát thiết kế, không phải sự cố thông tin đăng nhập thật hoặc tuyên bố phòng ngừa tuyệt đối.

Kiểm tra cả phòng ngừa lẫn phục hồi

Người phụ trách triển khai và người rà soát bảo mật cần duyệt danh sách trọng tâm này trước khi mở rộng quyền xem bản ghi dựng.

  • Xác định ai được lấy từng bí mật và vì mục đích gì.
  • Loại giá trị bí mật khỏi đầu ra thường và thông báo lỗi.
  • Kiểm tra sản phẩm được lưu, không chỉ màn hình điều khiển.
  • Quy định ai thu hồi và thay thế vật liệu đã lộ.
  • Xác nhận việc thay thế không chỉ phụ thuộc vào chính giá trị bị xâm phạm.

Nêu rõ giới hạn

Xử lý bí mật tập trung và hạn chế đầu ra cần công tích hợp, đồng thời có thể gây bất tiện khi chẩn đoán. Che quá nhiều cũng có thể làm mất ngữ cảnh hữu ích. Giải quyết mâu thuẫn bằng các trường chẩn đoán an toàn, thay vì cho phép xuất mọi thứ.

Nếu nghi bị lộ, làm theo quy trình sự cố đã duyệt và đánh giá thu hồi, thay thế cùng các bản sao còn lưu. Xóa một dòng log không đồng nghĩa xác lập rằng truy cập không còn khả thi. Chỉ chấp nhận thiết kế khi trách nhiệm xử lý bình thường và phục hồi đều rõ.

Tài liệu tham khảo

Trao đổi về dự án của bạn

Cùng UDT xác định nhu cầu và bước triển khai tiếp theo.

Liên hệ UDT
Zalo