Một vụ lộ thông tin đăng nhập vừa lên báo.
24 giờ đầu của bạn.

Giờ 0 đến 2: xác định bạn có bị phơi nhiễm không

1. Gọi tên tài sản thật chính xác. "Nhà cung cấp X bị tấn công" chỉ có ý nghĩa nếu bạn đang giữ tài khoản, thông tin đăng nhập, token hoặc dữ liệu ở nhà cung cấp X, hoặc dùng lại những mật khẩu từng nằm ở đó. Hãy viết ra phần giao nhau thực tế trước khi hành động.
2. Kiểm tra việc dùng lại, không chỉ việc có mặt. Bán kính thiệt hại của một vụ rò rỉ trải đến đúng những nơi mà cùng một mật khẩu hoặc một biến thể gần giống được dùng lại. Nếu thông tin đăng nhập của bạn nằm trong một kho dùng chung tìm kiếm được, truy vấn này mất vài phút; nếu chúng nằm rải trong các luồng chat và file bảng tính, bước này chính là nút thắt của bạn, và là bài học của bạn.
3. Đóng băng các lối vào tiện lợi. Tạm dừng mọi tính năng tự điền của tiện ích trình duyệt và mọi phiên dùng chung cho tên miền bị ảnh hưởng cho tới khi đổi xong.

Giờ 2 đến 12: đổi theo thứ tự ưu tiên

Đừng đổi theo thứ tự bảng chữ cái. Hãy đổi theo mức thiệt hại có thể gây ra:

1. Thông tin đăng nhập chuyển được tiền: ngân hàng, cổng thanh toán, hệ thống trả lương.
2. Gốc danh tính: nhà đăng ký tên miền, DNS, và chính các tài khoản quản trị của nhà cung cấp danh tính.
3. Gốc hạ tầng: tài khoản cloud, CI/CD, nơi lưu mã nguồn.
4. Bí mật của máy có tuổi thọ dài: khóa API và token, thứ chẳng bao giờ tự hết hạn và đúng là thứ mà các AI agent và tích hợp hay nắm giữ.
5. Mọi thứ còn lại mà vụ rò rỉ chạm tới.

Sau mỗi lần đổi, hãy thu hồi các phiên đang hoạt động và refresh token ở những dịch vụ cho phép; một mật khẩu vừa đổi không đá kẻ tấn công đang online ra ngoài.

Giờ 12 đến 24: chứng minh và nói ra

• Chứng minh đã xong bằng bản ghi, không bằng trí nhớ. Một nhật ký chỉ ghi thêm trả lời được câu "gần đây ai đã truy cập thông tin đăng nhập này, và có ai động vào nó sau khi tin lên báo không?" mà không cần phỏng vấn ai. Đây chính là lúc nhật ký chứng minh giá trị của nó.
• Nói cho nhóm biết điều gì đã thay đổi và nếu dữ liệu khách hàng nằm trong phạm vi, hãy làm theo nghĩa vụ thông báo của bạn thay vì theo mức thoải mái của bạn.
• Đặt lịch họp rút kinh nghiệm trong vòng một tuần: bước nào chậm, thông tin đăng nhập nào không có chủ, và cái gì sẽ được sửa.

Câu hỏi khó chịu mà bản tin đang đặt ra cho bạn

Mỗi vụ rò rỉ lên trang nhất cũng là một câu hỏi về chính nhà cung cấp của bạn: nếu người bị tấn công là họ, kẻ tấn công sẽ có được gì? Nếu câu trả lời trung thực là "bản rõ của chúng ta", thì cách sửa nằm ở kiến trúc, không nằm ở quy trình. Một kho zero-knowledge đổi câu trả lời đó thành "bản mã mà họ không mở được", và đó là lý do chúng tôi xây Keyvaci sao cho chính chúng tôi cũng không đọc được thứ bạn lưu. Diễn tập đổi mật khẩu vẫn quan trọng; cần đến nó ít hơn thì tốt hơn.