Bỏ qua điều hướng
Blog

Xoay vòng khóa API: kiểm kê bên dùng trước khi thu hồi khóa cũ

Xoay vòng khóa API cần kiểm kê consumer, cách nạp secret và bằng chứng thu hồi. Chỉ dùng giai đoạn chồng khóa khi nhà cung cấp hỗ trợ.

Chia sẻFacebookLinkedInZalo
xoay vòng khóa API: minh họa sổ phiên bản secret, consumer và bằng chứng bỏ khóa cũ
Nội dung bài viết

Khóa mới đã tạo, ứng dụng thử gọi thành công, nhưng một tác vụ chạy ban đêm vẫn dùng khóa cũ. Thu hồi ngay có thể làm gián đoạn; giữ cả hai vô thời hạn lại bỏ mục đích của việc đổi khóa. Xoay vòng khóa API cần kiểm kê bên dùng và bằng chứng chuyển phiên bản, không chỉ một thao tác trong màn hình quản trị.

Trước tiên xác định loại thay đổi

Đổi định kỳ, đổi do nghi lộ và đổi vì người quản trị rời vai trò có mức khẩn cấp khác nhau. Với nghi lộ, không trì hoãn biện pháp ứng phó chỉ để đợi một lịch triển khai đẹp; đội có thẩm quyền phải cân bằng rủi ro và khả dụng theo quy trình sự cố. Bài này bàn thiết kế chuyển khóa có kiểm soát, không thay hướng dẫn ứng phó của nhà cung cấp.

OWASP Secrets Management đặt secret trong một vòng đời gồm cấp, sử dụng, đổi và thu hồi. Việc quản lý tập trung không tự chứng minh mọi consumer đã đọc giá trị mới. Cần xác định cách ứng dụng nhận secret: đọc lúc khởi động, theo từng request hay cache theo chính sách.

Sổ consumer chỉ giữ nhãn, không giữ giá trị khóa

Consumer giả định Cách đọc Owner và bằng chứng
API web Đọc khi khởi động Owner web, phiên bản triển khai đã chuyển
Worker báo cáo Cache trong tiến trình Owner dữ liệu, lần chạy bằng nhãn khóa mới
Tác vụ theo lịch Biến môi trường riêng Owner vận hành, lịch kế tiếp cần xác minh

Thông tin cần giữ là secret_id, version_label, nơi tham chiếu, quyền đọc, owner và cách xác minh. Không copy giá trị secret vào bảng tính hoặc ticket. Nếu nhà cung cấp có mã khóa không nhạy cảm để thống kê sử dụng, dùng đúng trường được phép; không tự suy rằng mọi chuỗi có vẻ giống ID đều an toàn công khai.

Đừng chỉ tìm trong repository chính. Secret có thể được tham chiếu ở lịch chạy, công cụ triển khai, máy tích hợp hoặc cấu hình riêng của đối tác. Phạm vi kiểm kê cần được cấp quyền; không đọc và xuất kho bí mật chỉ để biết có bao nhiêu nơi dùng. Mục đích là bản đồ tham chiếu và trách nhiệm.

Tên bên dùng, phiên bản, owner, lần xác minh và trạng thái
Tên bên dùng, phiên bản, owner, lần xác minh và trạng thái. Sơ đồ biên tập; số liệu hoặc tình huống trong hình là giả định, không phải log hay kết quả khách hàng.

Khoảng chồng lấp chỉ tồn tại nếu nhà cung cấp hỗ trợ

Một số API cho nhiều khóa cùng hiệu lực, số khác đổi ngay giá trị duy nhất. Cách chuyển phải theo hợp đồng thật. Nếu hỗ trợ chồng lấp, có thể cấp khóa mới với quyền phù hợp, chuyển consumer, xác minh rồi thu hồi khóa cũ. Nếu không hỗ trợ, cần cửa sổ thay đổi và phương án giảm gián đoạn riêng.

Tài liệu AWS Secrets Manager cho secret cơ sở dữ liệu minh họa các bước cấu hình theo loại tài nguyên; không phải bằng chứng một khóa API bên thứ ba hỗ trợ cùng chiến lược. Không áp cơ chế đổi mật khẩu DB vào token hoặc khóa ký mà chưa đọc tài liệu provider.

Khóa mới được cấp, consumer chuyển, bằng chứng sạch rồi thu hồi khóa cũ
Khóa mới được cấp, consumer chuyển, bằng chứng sạch rồi thu hồi khóa cũ. Sơ đồ biên tập; số liệu hoặc tình huống trong hình là giả định, không phải log hay kết quả khách hàng.

“Không còn lỗi” chưa chứng minh bỏ khóa cũ

Ví dụ giả định: web đã chuyển nhưng job cuối tháng chưa chạy trong cửa sổ quan sát. Dashboard bình thường chỉ xác nhận những đường đã hoạt động. Sổ cần đánh dấu job đó chưa xác minh, lên kế hoạch kiểm trong môi trường hoặc lượt chạy được phép và giữ người chịu trách nhiệm. Không tạo một giao dịch thật có tác động tài chính chỉ để thử khóa.

Nếu provider có nhật ký sử dụng theo mã khóa, đối chiếu với sổ consumer. Thiếu truy cập log phải được ghi là thiếu bằng chứng, không suy ra khóa cũ không còn ai dùng. Với consumer cache lâu, cần biết việc reload có thật sự thay giá trị hay chỉ khởi động một phiên bản vẫn đọc cấu hình cũ.

Rollback không đồng nghĩa bật lại một khóa đã lộ

Khi đổi định kỳ thất bại, phương án quay về tùy khả năng và chính sách của provider. Khi nghi lộ, dùng lại secret cũ có thể mở lại đúng rủi ro đang xử lý. Kế hoạch nên có cách cấp mới hoặc đường vận hành tạm được chấp thuận, không ghi chung “restore khóa cũ” cho mọi tình huống.

Sau thu hồi, kiểm các đường ít hoạt động và lỗi quyền. Dọn tham chiếu hết hạn theo quy trình nhưng giữ lịch sử phiên bản không chứa secret để điều tra. Một lần đổi chỉ kết thúc khi consumer, quyền và bằng chứng được đối chiếu; không kết thúc khi người quản trị đóng cửa sổ console.

Đổi khóa ở đúng tầng

Refresh token giữa nhiều worker giải quyết cuộc đua của phiên xác thực, khác kiểm kê và thu hồi khóa API. Khóa ký webhook lại cần hợp đồng xác minh riêng. Khi khảo sát tích hợp phần mềm với Onter, chỉ gửi sơ đồ consumer và nhãn phiên bản đã được phép chia sẻ; không gửi giá trị khóa hay credential qua form tư vấn.

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo