Lập và quản lý bản đồ phụ thuộc bên thứ ba của website

Hãy duy trì một sổ phụ thuộc theo các hành trình người dùng đại diện. Trước hết quan sát yêu cầu mạng ở những trạng thái thực tế, sau đó đối chiếu với kiến trúc, cấu hình, hồ sơ mua sắm, hợp đồng và nhà cung cấp. Kết quả phải đủ để giao quyền sở hữu, hiểu luồng dữ liệu, đo chi phí, thử dự phòng và ra quyết định.

Phụ thuộc bên thứ ba của website là gì và tìm bằng cách nào?

Phụ thuộc bên thứ ba là mã, nội dung, dịch vụ, hạ tầng, thông tin xác thực, dữ liệu hoặc quan hệ nhà cung cấp nằm ngoài ranh giới kiểm soát liên quan và có thể ảnh hưởng đáng kể đến hành trình. Khác tên miền chỉ là tín hiệu khám phá: dịch vụ ngoài có thể dùng tên miền doanh nghiệp, còn nguồn cùng công ty vẫn có chủ sở hữu hoặc ranh giới lỗi riêng. Đây không phải danh mục gói mã nguồn.

Bắt đầu bằng bản ghi mạng trên các trang, thiết bị và trạng thái đại diện. Nhật ký có thể lọc yêu cầu khác nguồn và hiển thị trạng thái, loại, thành phần khởi tạo, kích thước, thời lượng, thác nước, yêu cầu bị chặn cùng quan hệ phụ thuộc. Hãy ghi cả trạng thái sau tương tác hoặc lựa chọn đồng ý; lần tải đầu tiên không đại diện cho đăng nhập, biểu mẫu, tìm kiếm hay giao dịch.

• Ghi tài nguyên, thành phần khởi tạo, chuỗi yêu cầu con, trạng thái, kích thước, thời lượng và vị trí trong thác nước.
• Lặp lại ở trạng thái trước và sau đồng ý, sau tương tác, trên thiết bị đại diện và trong bước có xác thực hoặc giao dịch nếu phù hợp.
• Đo trong bối cảnh cụ thể: mã lệnh bên thứ ba có thể phát sinh chi phí mạng, thực thi và kết xuất, đồng thời tải thêm tài nguyên; tác động thực tế phải được đo trong bối cảnh xác định.
• Giới hạn việc thu và chia sẻ bản ghi: tệp HAR có thể chứa tiêu đề hoặc dữ liệu nhạy cảm; thao tác làm sạch không chứng minh rằng mọi trường còn lại đều an toàn để phổ biến.

Làm sao phát hiện các phụ thuộc mà trình duyệt không thể hiện?

Ở lượt thứ hai, kiểm tra hồ sơ nền tảng và chuỗi nhà cung cấp: đăng ký tên miền, DNS, chứng thư, CDN, lớp biên, lưu trữ, CMS, danh tính, tìm kiếm, biểu mẫu, gửi thông báo, tích hợp máy chủ, quan sát hệ thống và kênh trạng thái. Các dịch vụ này có thể quyết định hành trình dù không hiện rõ trong phiên trình duyệt.

Hồ sơ mua sắm, hợp đồng, kiến trúc, cấu hình và trao đổi với nhà cung cấp có thể phát hiện nền tảng hoặc nhà thầu phụ vắng mặt trong bản ghi trình duyệt. Hãy ghi dịch vụ, mức quan trọng, luồng thông tin, đầu mối bảo đảm, tình trạng đánh giá, nhà thầu phụ và rủi ro tập trung. Không nguồn nào đầy đủ riêng lẻ; phải đối chiếu quan sát kỹ thuật với bằng chứng tổ chức.

• Nối từng dịch vụ với trang, thành phần và bước hành trình thực sự bị ảnh hưởng.
• Xác định người có thể xác nhận mục đích, vận hành, hợp đồng, tình trạng bảo đảm và quyền cho phép loại bỏ.
• Lần theo nhà thầu phụ hoặc hạ tầng dùng chung theo tỷ lệ rủi ro; ưu tiên chuỗi có thể làm gián đoạn hành trình trọng yếu.
• Ghi rõ điểm chưa biết thay vì suy đoán, rồi giao người chịu trách nhiệm và sự kiện cần bổ sung bằng chứng.

Sổ đăng ký phụ thuộc cần ghi những gì?

Mỗi phụ thuộc cần một dòng nối danh tính, phạm vi, trách nhiệm, bằng chứng và quyết định vòng đời. Ghi mức quan trọng, luồng thông tin, đầu mối, trạng thái bảo đảm, nhà thầu phụ, hợp đồng, điều kiện kích hoạt, trạng thái đồng ý, môi trường, thiết bị và bước hành trình. Hồ sơ phải cho biết dịch vụ xuất hiện ở đâu, phục vụ mục đích gì và ai có quyền thay đổi.

Gắn số liệu hiệu năng với hành trình, thiết bị, mạng, bộ nhớ đệm và ngày đo. Chi phí mạng, thực thi và kết xuất thay đổi theo cách triển khai, trang, tương tác và nhà cung cấp. Resource Timing cung cấp thời gian và kích thước trong phạm vi khả dụng, nhưng chính sách khác nguồn hoặc điều kiện nền tảng có thể hạn chế chi tiết. Không biến một quan sát thành điểm số phổ quát.

Ghi dữ liệu gửi và nhận, các bên tham gia, nơi nhận, mục đích, điều kiện kích hoạt cùng hồ sơ hợp đồng hoặc quyền riêng tư đã xem xét. Bên thứ nhất vẫn chịu trách nhiệm đối với việc xử lý được giao cho bên khác. Dùng giảm thiểu dữ liệu, giới hạn mục đích và minh bạch làm câu hỏi quyết định; yêu cầu cụ thể về thông báo, đồng ý, lưu giữ, chuyển giao và quyền người dùng cần chuyên gia có thẩm quyền xem xét.

Nên kiểm thử sự cố phụ thuộc như thế nào để vẫn an toàn?

Thử trong môi trường an toàn hoặc bằng công cụ trình duyệt đã được phê duyệt, xác định trước trạng thái còn sử dụng được và mỗi lần chỉ đổi một điều kiện. Không tạo sự cố sản xuất khi chưa được phép. Chặn yêu cầu có thể bộc lộ lỗi trước người dùng nhưng không tái tạo mọi kiểu ngừng dịch vụ, độ trễ, phản hồi sai dạng hoặc lỗi máy chủ. Khi phù hợp, xem xét phản hồi chậm, lỗi, rỗng, dữ liệu cũ và từ chối đồng ý.

Quan sát nội dung, điều hướng, biểu mẫu, xác thực, thông báo hoàn tất, đường thay thế, khả năng dùng bàn phím, nhãn, thời gian chờ, lỗi và giám sát; HTTP 200 không chứng minh hành trình còn dùng được. Dự phòng có thể kết hợp khôi phục kỹ thuật với nguồn lực thay thế hoặc xử lý thủ công tùy mức tác động. Ghi biểu hiện trước người dùng, tín hiệu vận hành, hành động phục hồi và kết quả của phương án thay thế.

• Phân loại kết quả theo đúng hành trình và điều kiện đã thử: nghiêm trọng, suy giảm, tùy chọn hoặc chỉ đo lường.
• Bốn nhãn “nghiêm trọng”, “suy giảm”, “tùy chọn” và “chỉ đo lường” là khung biên tập để phân loại chung, không phải tiêu chuẩn phổ quát về rủi ro hay tính liên tục.
• Kết quả chỉ đo lường vẫn có thể quan trọng nếu doanh nghiệp cần bằng chứng giám sát, phân bổ đóng góp hoặc thử nghiệm.
• Chuyển kiểm thử xâm nhập, thử khả năng chống chịu có tính phá hủy và bơm lỗi vào sản xuất cho chủ sở hữu đủ năng lực, với phê duyệt rõ ràng.

Giả sử bước đặt lịch dùng một widget. Bản ghi trình duyệt cho thấy iframe và các yêu cầu con; hồ sơ nhà cung cấp bổ sung chủ sở hữu, đối tác và luồng dữ liệu dự kiến. Khi widget bị chặn trong phép thử được phép, nội dung và đường liên hệ có khả năng tiếp cận vẫn dùng được, nhưng đặt lịch tức thời biến mất và giám sát không phát hiện. Nhóm ghi mức suy giảm, khoảng trống giám sát và đường thay thế đã thử.

Bản đồ phụ thuộc chỉ thật sự hữu ích khi cho thấy không chỉ website gọi gì, mà cả người dùng và đội vận hành gặp gì lúc sự phụ thuộc đó hỏng.

WebChorus Editorial Team

Khi nào nên giữ lại, thay thế, cô lập, trì hoãn, tự lưu trữ hoặc loại bỏ?

Chọn hướng xử lý từ mục đích, chủ sở hữu, chi phí đo được, luồng dữ liệu, lỗi, dự phòng và mức quan trọng của hành trình. Sáu hướng là khung thực hành, không phải chuẩn chung; tổ chức phải đối chiếu với tiêu chí tác động, hợp đồng, nhu cầu khôi phục và đánh giá chuyên môn. Widget đặt lịch giả định có thể được giữ lại với điều kiện bổ sung giám sát, duy trì đường liên hệ có khả năng tiếp cận và đặt sự kiện rà soát.

• Giữ lại khi mục đích hiện tại được bảo vệ, chủ sở hữu rõ ràng và chi phí, luồng dữ liệu cùng hành vi lỗi đã được chấp nhận theo hành trình.
• Thay thế khi năng lực vẫn cần nhưng phương án đã xác minh cải thiện chi phí, quyền kiểm soát, hỗ trợ, dữ liệu, lỗi hoặc rủi ro tập trung đang không thể chấp nhận.
• Cô lập khi cần giảm quyền truy cập hoặc phạm vi ảnh hưởng; JavaScript bên thứ ba được nhúng trực tiếp có thể thay đổi ngoài quy trình phát hành của tổ chức và chạy trong ngữ cảnh trang, dù khả năng cụ thể phụ thuộc cách tích hợp cùng kiểm soát của trình duyệt.
• Trì hoãn thành phần tùy chọn khi nó không cần tải trước nội dung hoặc tương tác chính; một facade có thể trì hoãn iframe tùy chọn cùng tài nguyên con cho đến khi người dùng kích hoạt, nhưng tương tác, nhãn, trạng thái đồng ý, khả năng tiếp cận và chức năng vẫn phải được kiểm thử.
• Tự lưu trữ chỉ khi tổ chức có thể sở hữu hợp pháp và vận hành việc phân phối, cấp phép, cập nhật, tính toàn vẹn, quyền riêng tư, bảo trì và hỗ trợ; chuyển vị trí byte không xóa rủi ro phần mềm thượng nguồn.
• Loại bỏ khi không ai bảo vệ được mục đích hiện tại, thành phần không dùng hoặc trùng lặp, hay giá trị được chấp nhận không còn tương xứng với chi phí và rủi ro quan sát được.

Cô lập không xóa rủi ro nhà cung cấp. Iframe, sandbox, Content Security Policy, kiểm tra tính toàn vẹn và luồng qua máy chủ có thể kiểm soát một số tích hợp, nhưng cần kỹ thuật và an ninh đánh giá tính phù hợp cùng đánh đổi chức năng. Subresource Integrity đối chiếu byte dự kiến của tài nguyên con được hỗ trợ, song cần phân phối tương thích và không xác thực mọi dịch vụ, API, iframe hay hành vi kinh doanh.

Làm sao giữ bản đồ phụ thuộc luôn cập nhật?

Đưa cập nhật vào vận hành website và kích hoạt theo sự kiện, thay vì áp một lịch cho mọi dịch vụ. Duy trì hồ sơ trung tâm từ các nguồn hiện có, ưu tiên chủ sở hữu, hợp đồng, bảo đảm, nhà thầu phụ và sự cố theo mức quan trọng. Nhận diện, đo lường và kiểm toán tích hợp trước khi chọn biện pháp giảm thiểu. Lịch rà soát, dự phòng và cam kết khôi phục phải tương xứng với tác động.

• Kích hoạt rà soát khi phát hành, đổi trình quản lý thẻ, thêm thành phần, mua sắm, gia hạn, nhận thông báo thay đổi hoặc ngừng hỗ trợ, xảy ra sự cố hay có đánh giá quyền riêng tư.
• Mỗi lần rà soát, cập nhật lần sử dụng gần nhất, trạng thái hợp đồng hoặc bảo đảm, quyết định cuối, người quyết định, việc còn mở và sự kiện tiếp theo.
• Kết nối giám sát với biểu hiện trên hành trình và khoảng trống đo lường; trạng thái nhà cung cấp hoặc điểm cuối chỉ là một phần bằng chứng.
• Đặt điều kiện phê duyệt phụ thuộc mới: mục đích, chủ sở hữu, luồng dữ liệu, chi phí dự kiến, lỗi, dự phòng, giám sát và sự kiện rà soát phải được xem xét trước khi áp dụng.

Trong tuần đầu, chọn một hành trình ưu tiên, ghi các trạng thái chính, đối chiếu bằng chứng trình duyệt với hồ sơ nhà cung cấp, tạo những dòng đầu tiên và giao chủ sở hữu tạm thời. Lập kế hoạch cho một phép thử lỗi được phép và có phạm vi hẹp. Sau đó mở rộng theo mức quan trọng, với đối tác an ninh, quyền riêng tư, pháp lý, mua sắm, khả năng tiếp cận và tính liên tục tham gia đúng thẩm quyền.