Một khuôn khổ quản trị API chuyển các nguyên tắc rộng lớn thành các quyết định mà các nhóm có thể lặp lại. Nó xác định những API nào thuộc phạm vi, ai sở hữu mỗi quyết định, những kiểm soát nào được áp dụng, các kiểm soát đó chạy ở đâu, bằng chứng nào chúng tạo ra và cách các ngoại lệ được phê duyệt. Chi tiết vận hành đó là sự khác biệt giữa một tài liệu quản trị và một hệ thống quản trị. Hướng dẫn này cung cấp một khuôn khổ thực tế cho các chương trình API doanh nghiệp. Nó bao gồm:
- một mô hình hoạt động bảy lớp;
- quyền ra quyết định tập trung và liên bang;
- một RACI cho các hoạt động quản trị chung;
- các bậc rủi ro để áp dụng các kiểm soát cân xứng;
- các chế độ kiểm soát: hướng dẫn, cảnh báo, chặn và xem xét;
- một ma trận kiểm soát quản trị API mẫu;
- một mô hình ngoại lệ và bằng chứng;
- một mô hình trưởng thành năm cấp độ;
- một lộ trình triển khai 12 tuần.
Nếu bạn cần định nghĩa rộng hơn, trường hợp kinh doanh, số liệu và các loại công cụ trước, hãy bắt đầu với Quản trị API là gì?. Bài viết này bắt đầu với việc triển khai.
button
Khuôn khổ quản trị API là gì?
Một khuôn khổ quản trị API là hệ điều hành mà một tổ chức sử dụng để đưa ra và xác minh các quyết định liên quan đến API. Nó kết nối các chính sách và tiêu chuẩn với chủ sở hữu, kiểm soát, bằng chứng, đo lường và ngoại lệ trong suốt vòng đời API.
Một khuôn khổ hoàn chỉnh nên trả lời bảy câu hỏi:
- Kết quả: Chúng ta đang cố gắng bảo vệ kết quả kinh doanh, người dùng, bảo mật hay vận hành nào?
- Phạm vi: Những API, nhóm, môi trường và giai đoạn vòng đời nào được bao phủ?
- Quyền ra quyết định: Ai định nghĩa tiêu chuẩn cơ sở, sở hữu từng API, phê duyệt ngoại lệ và giải quyết các phát hiện?
- Rủi ro: Những API nào cần kiểm soát chặt chẽ hơn và tại sao?
- Kiểm soát: Các nhóm phải làm gì, và kiểm soát nên hướng dẫn, cảnh báo, chặn hay yêu cầu xem xét?
- Bằng chứng: Làm thế nào tổ chức biết rằng kiểm soát đã hoạt động?
- Cải thiện: Những biện pháp nào cho thấy quản trị đang giảm thiểu rủi ro mà không ảnh hưởng đến việc triển khai?
Không có một tiêu chuẩn quản trị API phổ quát nào mà mọi công ty có thể sao chép mà không thay đổi. Khuôn khổ phải phản ánh kiến trúc, người dùng, dữ liệu, mô hình triển khai, bối cảnh quy định và mức độ chấp nhận rủi ro của tổ chức. Các tài liệu tham khảo bên ngoài có thể cung cấp thông tin: OpenAPI Specification định nghĩa một định dạng hợp đồng API đọc được bằng máy; OWASP API Security Top 10 cung cấp thông tin đầu vào về rủi ro bảo mật; và NIST Cybersecurity Framework cung cấp một mô hình rộng hơn cho quản trị, vai trò, chính sách, rủi ro và giám sát. Không có nguồn nào trong số đó thay thế quyền sở hữu và các quyết định cụ thể của tổ chức.
button
Bảy lớp của một khuôn khổ quản trị API
Coi khuôn khổ là bảy lớp kết nối với nhau thay vì một tài liệu chính sách dài.
| Lớp | Quyết định cần đưa ra | Đầu ra tối thiểu |
|---|---|---|
| 1. Kết quả và phạm vi | Tại sao quản trị tồn tại và nó bao gồm những gì? | Tuyên bố kết quả, phạm vi, loại trừ và ngày xem xét |
| 2. Mô hình hoạt động | Ai sở hữu các tiêu chuẩn, API, kiểm soát, bằng chứng và ngoại lệ? | Bản đồ quyền quyết định và RACI |
| 3. Danh mục và rủi ro | Có những API nào và mỗi API cần bao nhiêu kiểm soát? | Khoảng tồn kho, chủ sở hữu, trạng thái vòng đời và bậc rủi ro |
| 4. Các miền kiểm soát | Những yêu cầu nào áp dụng cho thiết kế, quyền truy cập, bảo mật, thay đổi và vận hành? | Thư viện kiểm soát được phiên bản |
| 5. Quy trình triển khai | Ở đâu kiểm soát nên hướng dẫn, cảnh báo, chặn hoặc yêu cầu xem xét? | Chế độ kiểm soát, trình kích hoạt và đường dẫn khắc phục |
| 6. Bằng chứng và ngoại lệ | Điều gì chứng minh kiểm soát đã hoạt động và các sai lệch được quản lý như thế nào? | Bản ghi bằng chứng, bản ghi ngoại lệ, chủ sở hữu và ngày hết hạn |
| 7. Đo lường và cải tiến | Liệu khuôn khổ có cải thiện kết quả và trải nghiệm của nhà phát triển không? | Thẻ điểm, chu kỳ xem xét và danh mục cải tiến tồn đọng |
Một điểm yếu ở một lớp sẽ làm suy yếu các lớp còn lại. Một tiêu chuẩn chính xác mà không có chủ sở hữu sẽ trở thành tùy chọn. Một kiểm tra chặn mà không có quy trình ngoại lệ sẽ tạo ra các giải pháp thay thế ẩn. Một bản ghi kiểm toán không có yêu cầu được nêu rõ chỉ ghi lại hoạt động chứ không chứng minh rằng rủi ro đúng đã được giải quyết.
1. Xác định kết quả và phạm vi trước khi viết chính sách
Bắt đầu với một tập hợp nhỏ các kết quả mà các giám đốc điều hành, nhóm nền tảng và nhóm triển khai có thể nhận biết. Ví dụ:
- người dùng có thể tìm thấy API chính xác và chủ sở hữu chịu trách nhiệm;
- các hợp đồng công khai và đối tác vẫn có thể dự đoán được khi chúng thay đổi;
- các API rủi ro cao nhận được đánh giá bảo mật và quyền riêng tư phù hợp;
- tài liệu chứa đủ chi tiết để triển khai và kiểm tra tích hợp;
- thông tin xác thực sản xuất không xuất hiện dưới dạng văn bản thuần túy trong các tài sản API được chia sẻ;
- quyền truy cập bị xóa khi mọi người rời đi hoặc không còn cần nữa;
- các phiên bản lỗi thời cung cấp cho người dùng một đường dẫn di chuyển được ghi lại;
- người đánh giá có thể tái tạo các quyết định quan trọng và hành động quản trị.
Tránh các mục tiêu mơ hồ như “tất cả các API phải tuân thủ.” Tuân thủ cái gì, cho API nào, vào thời điểm nào và theo quyết định của ai? Viết một kết quả có thể đo lường được và sau đó xác định các chính sách và kiểm soát cần thiết để hỗ trợ nó.
Đặt ra các giới hạn rõ ràng
Ghi lại những gì khuôn khổ bao gồm:
- REST, GraphQL, gRPC, API hướng sự kiện hoặc các loại giao diện khác;
- API nội bộ, đối tác, công khai và bên thứ ba;
- thiết kế, phát triển, phát hành, vận hành, thay đổi, lỗi thời và ngừng hoạt động;
- các hợp đồng API, tài liệu, kiểm thử, kho lưu trữ, thông tin xác thực và không gian làm việc cộng tác;
- các cổng runtime, hệ thống nhận dạng, nhật ký, khả năng quan sát và quy trình xử lý sự cố;
- chỉ API mới, hoặc cả API mới và API hiện có.
Cũng ghi lại các loại trừ. Một bản phát hành đầu tiên có thể bao gồm các API REST mới và các thay đổi quan trọng đối với các API công khai hiện có, trong khi việc khắc phục các hệ thống cũ theo một kế hoạch dựa trên rủi ro riêng. Một loại trừ rõ ràng có thể được quản lý; một loại trừ giả định sẽ trở thành một điểm mù.
2. Chọn một mô hình hoạt động và phân công quyền ra quyết định
Quản trị thường thất bại ở một trong hai thái cực. Một ủy ban trung ương phê duyệt mọi quyết định và trở thành điểm nghẽn, hoặc mỗi nhóm tự giải thích chính sách một cách độc lập và doanh nghiệp không có một tiêu chuẩn cơ sở nhất quán.
Hầu hết các tổ chức lớn cần một mô hình liên bang:
- một nền tảng API trung tâm hoặc nhóm hỗ trợ sở hữu tiêu chuẩn cơ sở của doanh nghiệp, các mẫu chia sẻ, công cụ chung và báo cáo chương trình;
- các quản lý miền chuyển đổi tiêu chuẩn cơ sở thành hướng dẫn cụ thể theo miền và giúp các nhóm áp dụng nó;
- các chủ sở hữu sản phẩm API vẫn chịu trách nhiệm về từng API và kết quả của người dùng;
- các chuyên gia bảo mật, quyền riêng tư, IAM, SRE và tuân thủ sở hữu hoặc xem xét các kiểm soát trong miền của họ;
- các nhóm triển khai thực hiện các kiểm soát và khắc phục các phát hiện;
- một chủ sở hữu rủi ro được chỉ định phê duyệt các ngoại lệ có thời hạn.
Liên bang hóa không có nghĩa là “các nhóm quyết định mọi thứ.” Nó có nghĩa là quyền hạn được phân phối với các giới hạn rõ ràng, bằng chứng và các đường dẫn leo thang.
button-text
Tập trung, liên bang hay phân tán?
| Mô hình | Hoạt động tốt nhất khi | Rủi ro chính | Rào cản bảo vệ |
|---|---|---|---|
| Tập trung | Danh mục API nhỏ, được quản lý chặt chẽ hoặc bắt đầu từ các thực hành không nhất quán | Hàng đợi xem xét và các quyết định chậm | Mục tiêu mức dịch vụ, các mẫu có thể tái sử dụng và tiêu chí ủy quyền |
| Liên bang | Nhiều miền chia sẻ một tiêu chuẩn cơ sở của doanh nghiệp nhưng cần chuyên môn địa phương và quyền tự chủ | Giải thích không đồng đều giữa các miền | Tiêu chuẩn cơ sở được phiên bản, cộng đồng quản lý, bằng chứng chung và hiệu chỉnh định kỳ |
| Phân tán | Các nhóm độc lập và API có ít người dùng hoặc rủi ro chung | API trùng lặp, tiêu chuẩn không tương thích và mức độ phơi nhiễm vô hình | Các kiểm soát doanh nghiệp tối thiểu cho kho, bảo mật và quyền sở hữu |
Kiểm soát tập trung có thể chặt chẽ hơn đối với các quyết định rủi ro cao trong khi các lựa chọn thiết kế thông thường vẫn được tự phục vụ. Mô hình hoạt động nên thay đổi theo rủi ro, không phải theo ý thức hệ.
Một RACI quản trị API thực tế
Sử dụng vai trò thay vì tên cá nhân để mô hình tồn tại qua các thay đổi tổ chức.
| Hoạt động | Chịu trách nhiệm chính (Accountable) | Chịu trách nhiệm thực hiện (Responsible) | Được tham vấn (Consulted) | Được thông báo (Informed) |
|---|---|---|---|---|
| Đặt ra các kết quả quản trị API doanh nghiệp và mức độ chấp nhận rủi ro | Nhà tài trợ điều hành | Trưởng nhóm quản trị/chương trình API | Bảo mật, kiến trúc, pháp lý/quyền riêng tư, lãnh đạo miền | Các nhóm API |
| Duy trì tiêu chuẩn cơ sở kiểm soát của doanh nghiệp | Trưởng nhóm nền tảng hoặc kiến trúc API | Nhóm hỗ trợ API | Bảo mật, IAM, SRE, quản lý miền | Các nhóm sản phẩm và triển khai |
| Duy trì các tiêu chuẩn miền và các mẫu có thể tái sử dụng | Trưởng nhóm kiến trúc miền | Quản lý API miền | Hỗ trợ trung tâm, bảo mật, đại diện triển khai | Các nhóm miền |
| Giữ thông tin về chủ sở hữu, người dùng, bậc và trạng thái vòng đời của API luôn cập nhật | Lãnh đạo miền/sản phẩm | Chủ sở hữu sản phẩm API | Trưởng nhóm kỹ thuật, nhóm nền tảng | Người dùng |
| Thực hiện các kiểm soát thiết kế, tài liệu, kiểm thử và phát hành | Chủ sở hữu sản phẩm API | Nhóm triển khai | Quản lý API, QA, bảo mật khi cần | Trưởng nhóm nền tảng/chương trình |
| Vận hành các kiểm soát xác thực, lưu lượng, ghi nhật ký và khả năng quan sát runtime | Trưởng nhóm vận hành dịch vụ/nền tảng | Nhóm dịch vụ, SRE, nhóm cổng hoặc bảo mật | Chủ sở hữu API, bảo mật | Chương trình quản trị |
| Cung cấp, xem xét và xóa quyền truy cập không gian làm việc quản trị | Chủ sở hữu IAM | Quản trị viên IAM/IT và không gian làm việc | Chủ sở hữu nhóm, bảo mật | Chương trình quản trị |
| Phê duyệt một ngoại lệ rủi ro cao | Chủ sở hữu rủi ro được chỉ định | Chủ sở hữu API chuẩn bị yêu cầu | Chủ sở hữu kiểm soát, bảo mật/quyền riêng tư, kiến trúc | Trưởng nhóm chương trình và người dùng bị ảnh hưởng |
| Xem xét các số liệu và cải thiện khuôn khổ | Trưởng nhóm quản trị/chương trình API | Chủ sở hữu hỗ trợ và dữ liệu | Quản lý miền, đại diện nhà phát triển, chủ sở hữu rủi ro | Nhà tài trợ điều hành |
Các chức danh chính xác sẽ khác nhau, nhưng mỗi hoạt động cần một vai trò chịu trách nhiệm chính. Nhiều chủ sở hữu chịu trách nhiệm chính thường có nghĩa là không ai có thể đưa ra quyết định cuối cùng.
3. Lập danh mục API và phân bậc rủi ro
Bạn không thể áp dụng một khuôn khổ cho một danh mục không xác định. Tối thiểu, hãy ghi lại:
- Tên API và định danh ổn định;
- Chủ sở hữu kinh doanh hoặc sản phẩm chịu trách nhiệm;
- Chủ sở hữu kỹ thuật và liên hệ hỗ trợ;
- Miền và người dùng;
- Loại giao diện và nguồn đáng tin cậy;
- Mức độ phơi nhiễm: nội bộ, đối tác hoặc công khai;
- Phân loại dữ liệu;
- Mức độ quan trọng của doanh nghiệp;
- Trạng thái vòng đời và ngày xem xét;
- Chủ sở hữu triển khai và runtime;
- Các phụ thuộc và người dùng đã biết;
- Bậc rủi ro và lý do của nó.
Kết nối danh mục này với danh mục API và quy trình vòng đời API của bạn. Một bảng tính có thể bắt đầu công việc, nhưng thông tin về quyền sở hữu và vòng đời cuối cùng nên được lưu trữ ở nơi các nhóm có thể cập nhật nó.
Ví dụ mô hình ba cấp độ
| Bậc | Các chỉ số điển hình | Ví dụ xử lý kiểm soát |
|---|---|---|
| Bậc 1: Rủi ro nghiêm trọng hoặc cao | Tiếp xúc công khai hoặc đối tác; dữ liệu được quy định hoặc cực kỳ nhạy cảm; tác động tài chính hoặc an toàn; cơ sở người dùng lớn; phụ thuộc kinh doanh quan trọng | Đánh giá kiến trúc/bảo mật và chủ sở hữu chính thức, bằng chứng phát hành chặt chẽ hơn, khả năng tương thích và ngừng sử dụng được kiểm thử, mục tiêu khắc phục ngắn hơn, đánh giá quyền truy cập định kỳ, bằng chứng runtime |
| Bậc 2: Quan trọng | Sử dụng nội bộ hoặc đối tác hạn chế; quy trình làm việc kinh doanh quan trọng; độ nhạy dữ liệu vừa phải; một số nhóm phụ thuộc | Tiêu chuẩn cơ sở doanh nghiệp, kiểm tra thiết kế/tài liệu tự động hoặc do người dùng kích hoạt, kiểm thử bắt buộc, chủ sở hữu được đặt tên, xem xét thay đổi cho các cập nhật quan trọng, xem xét quyền truy cập theo lịch trình |
| Bậc 3: Rủi ro thấp hoặc thử nghiệm | Nguyên mẫu tạm thời; sử dụng nội bộ nhạy cảm thấp; người dùng và tác động hạn chế | Tiêu chuẩn cơ sở đơn giản, chủ sở hữu và ngày hết hạn, quy tắc thông tin xác thực và truy cập tối thiểu, tiêu chí thăng cấp rõ ràng trước khi sử dụng rộng rãi hơn |
Đừng gán bậc chỉ dựa vào mức độ tiếp xúc. Một API riêng tư xử lý dữ liệu nhân viên nhạy cảm cao có thể cần kiểm soát nhiều hơn một API công khai chỉ đọc đơn giản. Sử dụng một số yếu tố và ghi lại lý do để hai nhóm đánh giá các API tương tự đưa ra các quyết định tương tự.
4. Xây dựng thư viện kiểm soát được phiên bản
Một chính sách nêu rõ một kết quả bắt buộc. Một tiêu chuẩn định nghĩa một cách làm việc được phê duyệt. Một kiểm soát ngăn chặn, phát hiện hoặc ghi lại một sai lệch. Bằng chứng cho thấy những gì đã xảy ra. Giữ các tạo phẩm này được kết nối.
Ví dụ:
- Chính sách: Các tài sản API được chia sẻ không được chứa thông tin xác thực sản xuất dạng văn bản thuần túy.
- Tiêu chuẩn: Các giá trị xác thực nhạy cảm sử dụng các biến cục bộ đã được phê duyệt hoặc các tham chiếu Vault.
- Kiểm soát phòng ngừa: Một chính sách thông tin xác thực chặn việc lưu trữ các giá trị văn bản thuần túy không được hỗ trợ.
- Kiểm soát phát hiện: Một trình quét xác định một bí mật có thể có trong các tài sản được hỗ trợ.
- Quy trình khắc phục: Nhóm loại bỏ giá trị, thu hồi hoặc xoay vòng nó trong hệ thống phát hành, kiểm tra mức độ phơi nhiễm và ghi lại giải pháp.
- Bằng chứng: Kết quả chính sách, phát hiện của trình quét, vé xoay vòng bên ngoài và bản ghi đóng.
Các miền kiểm soát cốt lõi
| Miền | Các câu hỏi mà thư viện kiểm soát nên trả lời |
|---|---|
| Quyền sở hữu và mô hình hoạt động | Có chủ sở hữu chịu trách nhiệm được đặt tên không? Ai phê duyệt các tiêu chuẩn và ngoại lệ? |
| Danh mục và vòng đời | API có được lập danh mục, phân loại, xem xét, loại bỏ và ngừng hoạt động một cách có chủ ý không? |
| Thiết kế và hợp đồng | Có hợp đồng đọc được bằng máy không? Các quy ước đặt tên, lỗi, phân trang, khả năng tương thích và lược đồ có thể tái sử dụng có được giải quyết không? |
| Tài liệu và khả năng khám phá | Người dùng có thể tìm thấy API và hiểu xác thực, tham số, ràng buộc, phản hồi, lỗi, ví dụ và trạng thái thay đổi không? |
| Kiểm thử và phát hành | Những kiểm tra hợp đồng, chức năng, bảo mật, hiệu suất và khả năng tương thích nào là bắt buộc trước khi phát hành? |
| Nhận dạng và quyền truy cập quản trị | Ai có thể tham gia, quản lý, chỉnh sửa, xuất bản, xuất hoặc xem các tài sản API? Quyền truy cập được xem xét và xóa như thế nào? |
| Thông tin xác thực và dữ liệu nhạy cảm | Bí mật có thể được lưu trữ ở đâu? Chúng được tham chiếu, phát hiện, xoay vòng và xóa như thế nào sau khi bị lộ? |
| Kiểm soát nguồn và chuỗi cung ứng | Những kho lưu trữ, nhánh, đánh giá, phụ thuộc và luồng tạo phẩm nào được phê duyệt? |
| Bảo vệ và vận hành runtime | Những kiểm soát cổng, ủy quyền, mối đe dọa, ghi nhật ký, giám sát, khả năng phục hồi và sự cố nào áp dụng sau khi triển khai? |
| Bằng chứng và ngoại lệ | Những bản ghi nào chứng minh hoạt động, chúng được giữ lại trong bao lâu và ai có thể phê duyệt một sai lệch? |
Các nguyên tắc thiết kế API phải đủ cụ thể để kiểm tra. Các ví dụ công khai như Hướng dẫn thiết kế API của Google và Nguyên tắc API REST của Microsoft cho thấy cách các tổ chức biến các ưu tiên chung thành các quy ước cụ thể. Chỉ áp dụng các quy tắc phù hợp với người dùng và kiến trúc của bạn, và gán cho mỗi quy tắc một chủ sở hữu, phiên bản, ngày có hiệu lực, ví dụ và đường dẫn di chuyển.
5. Chọn chế độ kiểm soát phù hợp: hướng dẫn, cảnh báo, chặn hoặc xem xét
Không phải mọi yêu cầu đều phải là một rào cản cứng nhắc. Chọn một chế độ dựa trên rủi ro, tính xác định, mức độ trưởng thành và chi phí của một kết quả dương tính giả.
| Chế độ | Nó làm gì | Tốt nhất cho | Tránh khi |
|---|---|---|---|
| Hướng dẫn | Cung cấp các mẫu, ví dụ, thành phần có thể tái sử dụng và hướng dẫn nội tuyến | Các tiêu chuẩn mới, các lựa chọn thiết kế phức tạp và hỗ trợ tự phục vụ | Rủi ro đòi hỏi sự phòng ngừa hoặc bằng chứng đáng tin cậy |
| Cảnh báo | Báo cáo một sai lệch có thể xảy ra nhưng cho phép quy trình làm việc tiếp tục | Thời gian áp dụng, các vấn đề rủi ro thấp hơn và các kiểm tra có một số mơ hồ | Các nhóm có thể bỏ qua một rủi ro quan trọng vô thời hạn |
| Chặn | Ngăn chặn việc lưu, hợp nhất, phát hành hoặc triển khai cho đến khi vấn đề được khắc phục hoặc ngoại lệ được phê duyệt | Các yêu cầu có tính xác định cao, độ tin cậy cao với đường dẫn khắc phục nhanh | Quy tắc chủ quan, không ổn định hoặc có khả năng tạo ra các kết quả dương tính giả gây gián đoạn |
| Xem xét | Gửi quyết định cho một người có đủ năng lực | Đánh đổi kiến trúc, ngữ cảnh quyền riêng tư, các ngoại lệ rủi ro cao và các thay đổi cần đánh giá của người dùng | Mọi thay đổi định kỳ đều yêu cầu cùng một người xem xét khan hiếm |
Một quá trình triển khai hiệu quả thường chuyển từ hướng dẫn sang cảnh báo và sau đó là chặn sau khi các nhóm có các ví dụ, công cụ và tỷ lệ dương tính giả được đo lường. Một số quyết định nên luôn được xem xét vì ngữ cảnh rất quan trọng.
Trước khi chặn, hãy xác nhận rằng:
- quy tắc có chủ sở hữu được đặt tên và lý do được ghi lại;
- kiểm tra đủ tính xác định cho rủi ro dự định;
- các nhóm nhận được giải thích rõ ràng và ví dụ tuân thủ;
- khắc phục có sẵn trong quy trình làm việc bình thường;
- một đường dẫn ngoại lệ tồn tại và có mục tiêu phản hồi;
- tổ chức có thể đo lường các dương tính giả, các lối tắt và tác động đến việc triển khai.
6. Tạo ma trận kiểm soát quản trị API
Ma trận kiểm soát là hồ sơ làm việc của khuôn khổ. Nó phải đủ chi tiết để triển khai nhưng đủ gọn để xem xét.
Tối thiểu, hãy bao gồm:
- ID kiểm soát và miền;
- mục tiêu và yêu cầu;
- phạm vi và các bậc rủi ro áp dụng;
- trình kích hoạt vòng đời;
- chế độ: hướng dẫn, cảnh báo, chặn hoặc xem xét;
- vai trò chịu trách nhiệm chính và chịu trách nhiệm thực hiện;
- hệ thống triển khai;
- bằng chứng và hệ thống ghi lại;
- chu kỳ xem xét hoặc thực hiện;
- mục tiêu khắc phục;
- người phê duyệt ngoại lệ và quy tắc hết hạn;
- trạng thái và ngày xem xét gần nhất.
Ma trận kiểm soát quản trị API mẫu
Mẫu này là một điểm khởi đầu, không phải là một danh sách kiểm tra tuân thủ phổ quát.
| ID | Mục tiêu kiểm soát | Áp dụng cho | Chế độ | Chủ sở hữu chịu trách nhiệm chính | Bằng chứng ví dụ | Tần suất hoặc trình kích hoạt |
|---|---|---|---|---|---|---|
| GOV-01 | Mỗi API được quản lý có một chủ sở hữu chịu trách nhiệm chính, bậc rủi ro, nguồn đáng tin cậy và trạng thái vòng đời | Tất cả các API được quản lý | Xem xét | Lãnh đạo miền/sản phẩm | Bản ghi danh mục và lịch sử xem xét | Khi tạo; hàng quý |
| DES-01 | API sản xuất sử dụng hợp đồng đọc được bằng máy đã được phê duyệt khi thích hợp | Tất cả các API sản xuất | Chặn hoặc xem xét | Chủ sở hữu sản phẩm API | OpenAPI được phiên bản hoặc hợp đồng đã được phê duyệt khác | Khi tạo và thay đổi quan trọng |
| DES-02 | Các hợp đồng tuân theo các tiêu chuẩn thiết kế và lỗi áp dụng | Bậc 1–2; một số bậc 3 | Cảnh báo, sau đó chặn cho các quy tắc xác định | Trưởng nhóm kiến trúc API | Kết quả Lint/kiểm tra và ngoại lệ được phê duyệt | Khi thay đổi hợp đồng |
| DOC-01 | Các điểm cuối ghi lại mục đích, xác thực, tham số, ràng buộc, phản hồi, lỗi và các ví dụ đại diện | Tất cả các API hướng người dùng | Cảnh báo hoặc xem xét | Chủ sở hữu sản phẩm API | Danh sách kiểm tra tài liệu hoặc báo cáo hoàn chỉnh | Trước khi phát hành |
| CHG-01 | Các thay đổi gây phá vỡ và ngừng sử dụng tuân theo quy trình thông báo và di chuyển người dùng đã được phê duyệt | API công khai, đối tác và API nội bộ được tái sử dụng rộng rãi | Chặn cộng với xem xét | Chủ sở hữu sản phẩm API | Kết quả tương thích, phê duyệt, thông báo và kế hoạch di chuyển | Khi có thay đổi quan trọng |
| TST-01 | Các kiểm thử hợp đồng và chức năng bắt buộc vượt qua trước khi phát hành | Tất cả các API sản xuất | Chặn | Trưởng nhóm kỹ thuật | Báo cáo kiểm thử gắn liền với bản phát hành | Mỗi bản phát hành |
| IAM-01 | Quyền không gian làm việc phản ánh quyền tối thiểu và trách nhiệm công việc hiện tại | Tất cả các không gian làm việc API | Xem xét | Chủ sở hữu nhóm/không gian làm việc | Phân công vai trò và bản ghi xem xét quyền truy cập | Hàng quý và khi thay đổi vai trò |
| IAM-02 | Quyền truy cập không gian làm việc quản trị bị xóa kịp thời sau sự kiện rời khỏi tổ chức | Tất cả các không gian làm việc API | Hành động tự động cộng với xem xét | Chủ sở hữu IAM | Sự kiện hủy cấp phép và kết quả đối chiếu | Khi có sự kiện; đối chiếu hàng tháng |
| SEC-01 | Các giá trị xác thực nhạy cảm sử dụng các tham chiếu đã được phê duyệt thay vì văn bản thuần túy được chia sẻ | Tất cả các tài sản API được chia sẻ | Chặn | Chủ sở hữu bảo mật/nền tảng | Kết quả chính sách hoặc bản ghi cấu hình | Khi lưu hoặc thay đổi |
| SEC-02 | Các thông tin xác thực bị nghi ngờ bị lộ được phân loại, xóa, thu hồi hoặc xoay vòng bên ngoài và đóng với lý do | Tất cả các tài sản được hỗ trợ | Phát hiện cộng với xem xét | Chủ sở hữu nhóm | Phát hiện, xóa nguồn, vé xoay vòng bên ngoài và đóng | Khi phát hiện; xem xét theo tuần |
| SRC-01 | Các hợp đồng được quản lý sử dụng các kho lưu trữ, quyền, nhánh và đường dẫn xem xét đã được phê duyệt | Bậc 1–2 | Chặn trong kiểm soát nguồn | Chủ sở hữu nền tảng/kiểm soát nguồn | Cài đặt kho lưu trữ và lịch sử yêu cầu kéo | Khi thay đổi; xem xét hàng quý |
| AUD-01 | Các hành động quản trị liên quan đến bảo mật được thu thập và xem xét theo kế hoạch bằng chứng | Bậc 1 và các chương trình được quy định | Ghi lại cộng với xem xét | Chủ sở hữu bảo mật/tuân thủ | Xuất, bộ sưu tập API, bản ghi SIEM và vé xem xét | Thu thập hàng ngày; xem xét hàng tháng |
| RUN-01 | Các API bị lộ sử dụng xác thực, ủy quyền, lưu lượng, mối đe dọa và kiểm soát ghi nhật ký runtime đã được phê duyệt | API công khai, đối tác và API nội bộ nhạy cảm | Chặn khi triển khai/runtime | Chủ sở hữu nền tảng runtime/bảo mật | Chính sách cổng, kiểm thử ủy quyền, nhật ký runtime và giám sát | Triển khai và vận hành liên tục |
| LIF-01 | Các API lỗi thời có chủ sở hữu, kế hoạch người dùng, ngày tháng và ngừng hoạt động được xác minh | API công khai, đối tác và API nội bộ được tái sử dụng | Xem xét | Chủ sở hữu sản phẩm API | Trạng thái danh mục, thông báo, theo dõi di chuyển và phê duyệt ngừng hoạt động | Hàng tháng cho đến khi ngừng hoạt động |
Ma trận có thể tải xuống mở rộng mẫu này với các định nghĩa chế độ kiểm soát, trường RACI, hướng dẫn bằng chứng, chấm điểm mức độ trưởng thành, theo dõi triển khai và bản đồ khả năng của Apidog.
7. Thiết kế bằng chứng và ngoại lệ như các quy trình làm việc hạng nhất
Bằng chứng nên trả lời một câu hỏi cụ thể
Đừng thu thập nhật ký chỉ vì chúng tồn tại. Đối với mỗi kiểm soát, hãy định nghĩa:
- quyết định hoặc yêu cầu mà bằng chứng hỗ trợ;
- hệ thống nguồn và chủ sở hữu chịu trách nhiệm;
- các trường cần thiết để diễn giải nó;
- tần suất thu thập và xem xét;
- yêu cầu lưu giữ và truy cập;
- cách các khoảng trống hoặc kiểm soát thất bại tạo ra công việc khắc phục;
- cách bằng chứng được bảo vệ khỏi rò rỉ dữ liệu nhạy cảm.
Một báo cáo kiểm thử có thể cho thấy rằng một kiểm thử đã chạy và vượt qua đối với một tạo phẩm cụ thể. Nó không chứng minh rằng kiểm thử đã bao phủ mọi rủi ro quan trọng. Một sự kiện kiểm toán quản trị có thể cho thấy ai đã thay đổi một vai trò. Nó không phải là một nhật ký yêu cầu runtime. Một đánh giá thiết kế có thể cho thấy rằng một điểm cuối đã được kiểm tra tại một thời điểm. Nó không phải là việc thực thi sản xuất liên tục.
Ánh xạ bằng chứng đến lớp chính xác: nền tảng phát triển API, kiểm soát nguồn, CI/CD, nhà cung cấp nhận dạng, cổng, nền tảng đám mây, SIEM, hệ thống quan sát, nền tảng vé hoặc sổ đăng ký rủi ro. Hầu hết các kiểm soát doanh nghiệp cần nhiều hơn một hệ thống.
Mọi ngoại lệ cần một ngày hết hạn
Một bản ghi ngoại lệ có thể sử dụng được chứa:
- API, phiên bản, môi trường và ID kiểm soát bị ảnh hưởng;
- lý do yêu cầu hiện tại không thể được đáp ứng;
- rủi ro và người dùng hoặc dữ liệu bị ảnh hưởng;
- kiểm soát bù đắp;
- quyết định khắc phục hoặc chấp nhận rủi ro;
- chủ sở hữu chịu trách nhiệm chính và người phê duyệt;
- ngày bắt đầu, ngày hết hạn và ngày xem xét;
- bằng chứng và các mục công việc được liên kết;
- quyết định đóng, gia hạn hoặc leo thang cuối cùng.
Các ngoại lệ nên dễ yêu cầu nhưng khó quên. Xem xét chúng theo tuổi, rủi ro, nhóm và kiểm soát. Các ngoại lệ lặp đi lặp lại đối với cùng một quy tắc có thể cho thấy việc hỗ trợ kém, một tiêu chuẩn không thực tế, một khả năng nền tảng bị thiếu hoặc một quy tắc cần được thiết kế lại.
Mô hình trưởng thành quản trị API
Sử dụng các cấp độ trưởng thành để quyết định khoản đầu tư tiếp theo, không phải để tạo ra một điểm số phù phiếm. Đánh giá từng miền kiểm soát một cách riêng biệt; danh tính có thể được đo lường trong khi quyền sở hữu vòng đời vẫn mang tính phản ứng.
| Cấp độ | Đặc điểm có thể quan sát | Bằng chứng bạn nên có thể thể hiện | Bước tiếp theo |
|---|---|---|---|
| 1. Phản ứng | Các quy tắc là kiến thức truyền miệng; quyền sở hữu và kho hàng không đầy đủ; các đánh giá xảy ra sau sự cố | Các tài liệu rải rác và khắc phục cụ thể theo vấn đề | Đặt tên chủ sở hữu, lập danh mục ban đầu và định nghĩa năm đến mười kiểm soát tối thiểu |
| 2. Xác định | Các chính sách cơ sở, tiêu chuẩn, vai trò và mẫu ngoại lệ tồn tại | Các tiêu chuẩn được phiên bản, RACI, ma trận kiểm soát ban đầu và các bậc được phân công | Thí điểm khuôn khổ với các nhóm thực tế và chuyển hướng dẫn chung vào các quy trình làm việc |
| 3. Nhúng | Các kiểm soát hoạt động trong quá trình thiết kế, phát triển, phát hành, truy cập và thay đổi; các nhóm có một lộ trình được lát đá | Kết quả kiểm tra, báo cáo kiểm thử, quy trình làm việc truy cập, bản ghi ngoại lệ và các mẫu có thể tái sử dụng | Đo lường mức độ bao phủ, dương tính giả, thời gian khắc phục và ma sát của nhà phát triển |
| 4. Đo lường | Mức độ bao phủ, sự phù hợp, ngoại lệ, phát hiện và tác động đến việc triển khai được xem xét theo bậc rủi ro | Các mẫu số đáng tin cậy, dữ liệu xu hướng, báo cáo cũ và các quyết định cải tiến | Ủy quyền nhiều quyết định thông thường hơn và cải thiện các miền yếu bằng cách sử dụng bằng chứng |
| 5. Thích ứng và liên bang | Các nhóm miền hoạt động trong các giới hạn doanh nghiệp rõ ràng; các kiểm soát phát triển theo các sự cố, phản hồi của người dùng và thay đổi kiến trúc | Các phần mở rộng miền được hiệu chỉnh, báo cáo liên miền, quyết định ngoại lệ nhanh chóng và các quy tắc không hiệu quả bị loại bỏ | Tiếp tục kiểm tra các giả định; ngăn chặn sự trưởng thành trở thành quan liêu |
Đừng yêu cầu mọi miền phải đạt Cấp độ 5. Một khu vực ổn định, rủi ro thấp có thể cần Cấp độ 3 nhất quán hơn là một chương trình thích ứng phức tạp.
Lộ trình triển khai 12 tuần
Tuần 1–2: Đặt ra nhiệm vụ
- Đặt tên nhà tài trợ điều hành và trưởng nhóm chương trình.
- Đồng ý ba đến năm kết quả và phạm vi ban đầu.
- Ghi lại các loại trừ, giả định và ngày xem xét.
- Chọn một miền thí điểm với nhu cầu thực tế và các nhóm triển khai sẵn lòng.
Tuần 3–4: Xây dựng tiêu chuẩn cơ sở danh mục
- Lập danh mục các API thí điểm, chủ sở hữu, người dùng, nguồn đáng tin cậy, mức độ phơi nhiễm, dữ liệu và trạng thái vòng đời.
- Xác định các tiêu chí bậc rủi ro đơn giản và kiểm tra chúng trên các API đại diện.
- Xác định quyền sở hữu bị thiếu và các phụ thuộc không xác định là rủi ro rõ ràng.
Tuần 5–6: Định nghĩa quyền ra quyết định và kiểm soát tối thiểu
- Phê duyệt RACI và đường dẫn leo thang.
- Chọn năm đến mười kiểm soát có giá trị cao cho dự án thí điểm.
- Viết các trường mục tiêu, phạm vi, chế độ, chủ sở hữu, bằng chứng, khắc phục và ngoại lệ cho từng trường.
- Tạo các ví dụ và mẫu tuân thủ.
Tuần 7–8: Đặt kiểm soát vào quy trình làm việc
- Bắt đầu với hướng dẫn và cảnh báo nơi các nhóm cần thời gian áp dụng.
- Chỉ sử dụng các cổng cứng cho các yêu cầu vật chất, có tính xác định.
- Kết nối các hệ thống thiết kế, tài liệu, kiểm thử, nhận dạng, thông tin xác thực, kiểm soát nguồn và runtime với các kiểm soát liên quan.
- Đào tạo người đánh giá và các nhóm triển khai bằng cách sử dụng các ví dụ tương tự.
Tuần 9–10: Vận hành bằng chứng và ngoại lệ
- Kiểm tra xem bằng chứng có thể tái tạo lại quyết định và phiên bản tạo phẩm không.
- Thực hiện một bài tập trên bàn cho một kiểm soát thất bại và một yêu cầu ngoại lệ.
- Định nghĩa hàng đợi xem xét, mục tiêu phản hồi, chủ sở hữu khắc phục và thông báo hết hạn.
- Xóa các giá trị nhạy cảm khỏi báo cáo và xuất khẩu.
Tuần 11–12: Đo lường và mở rộng
- Xem xét mức độ bao phủ, sự phù hợp, tuổi của ngoại lệ, thời gian khắc phục, dương tính giả và tác động đến việc triển khai.
- Phỏng vấn các nhà phát triển và người dùng thí điểm.
- Sửa các quy tắc gây nhầm lẫn trước khi thêm nhiều kiểm soát hơn.
- Xuất bản việc triển khai miền tiếp theo và danh mục tích hợp runtime tồn đọng.
Mục tiêu của 12 tuần đầu tiên không phải là bao phủ toàn bộ doanh nghiệp. Đó là một vòng lặp kiểm soát hoạt động mà tổ chức có thể quan sát và cải thiện.
Apidog ánh xạ vào khuôn khổ như thế nào
Apidog có thể hỗ trợ các kiểm soát thiết kế và cộng tác quan trọng trong khuôn khổ này. Nó nên được kết nối với hệ thống kiểm soát nguồn, CI/CD, nhận dạng, cổng, SIEM, khả năng quan sát và hệ thống rủi ro của tổ chức, nơi các hệ thống đó sở hữu các kiểm soát khác.
| Khu vực khuôn khổ | Khả năng liên quan của Apidog | Phạm vi mô tả chính xác |
|---|---|---|
| Tiêu chuẩn thiết kế | Quy trình làm việc thiết kế tập trung vào OpenAPI và Kiểm tra Tuân thủ Điểm cuối do người dùng kích hoạt | Đánh giá AI đánh giá việc đặt tên, tài liệu, việc sử dụng phương thức HTTP, cấu trúc phản hồi và các thực hành bảo mật khi người dùng chạy nó. Nó không phải là việc thực thi liên tục phổ quát hay cổng runtime. |
| Chất lượng tài liệu | Tài liệu được tạo/chia sẻ và Kiểm tra Hoàn chỉnh Tài liệu API | Kiểm tra xem xét các định nghĩa, mô tả, ví dụ, ràng buộc, mã trạng thái, phản hồi và lỗi cho tài liệu điểm cuối hiện tại. |
| Nhận dạng không gian làm việc | SAML SSO, cung cấp SCIM, vai trò nhóm/dự án và ánh xạ nhóm SAML | Tài liệu SCIM công khai hiện tại hỗ trợ thêm và xóa người dùng, không phải cập nhật người dùng hoặc nhóm SCIM. Ánh xạ nhóm SAML có thể quản lý tư cách thành viên nhóm và vai trò dự án ban đầu mà không ghi đè vai trò dự án đã được gán hiện có. Các kiểm soát này không ủy quyền các cuộc gọi đến một API sản xuất. |
| Cộng tác với quyền tối thiểu | Các vai trò nhóm tích hợp và các vai trò dự án tích hợp hoặc tùy chỉnh được ghi lại trong Vai trò & Quyền Thành viên | Tài liệu hiện tại chỉ hỗ trợ các vai trò dự án tùy chỉnh; các vai trò nhóm hoặc tổ chức tùy chỉnh chưa được ghi lại là có sẵn. |
| Ngăn chặn thông tin xác thực | Chính sách Doanh nghiệp với các chế độ Tắt, Cảnh báo hoặc Chặn cho các trường xác thực được hỗ trợ, cộng với các biến và tham chiếu Vault | Phạm vi chính sách bị giới hạn trong các trường và quy trình làm việc xác thực được ghi lại. Chính sách Phiên SSO cô lập quyền truy cập vào Nhóm của tôi trong một phiên SSO của tổ chức; nó không phải là thời gian chờ phiên nhàn rỗi. |
| Phát hiện thông tin xác thực | Máy quét Bí mật không đồng bộ, các mẫu tích hợp và tùy chỉnh, các phát hiện bị che dấu, các lần xuất hiện, các chỉ báo phơi nhiễm công khai và theo dõi giải quyết | Máy quét Bí mật được ghi lại cho Doanh nghiệp SaaS và chưa có sẵn cho việc triển khai tại chỗ. Nó không quét các kho lưu trữ GitHub/GitLab bên ngoài hoặc tự động thu hồi, xoay vòng, xóa hoặc thay thế các bí mật. |
| Bằng chứng quản trị | Nhật ký Kiểm toán với bộ lọc, xuất CSV và truy vấn API | Nhật ký Kiểm toán được ghi lại cho Doanh nghiệp SaaS, chưa có sẵn tại chỗ, với thời gian lưu giữ 180 ngày. Chúng bao gồm các sự kiện tổ chức/bảo mật được hỗ trợ, không phải các yêu cầu API runtime. Các trình kết nối SIEM gốc, Syslog, webhook và truyền phát theo thời gian thực hiện chưa được ghi lại là được hỗ trợ. |
| Quy trình làm việc Git và nguồn đáng tin cậy | Kết nối Git, nhập/sao lưu OpenAPI và tích hợp nơi lưu trú dữ liệu GitHub Enterprise Cloud | Quyền kho lưu trữ, nhánh, đánh giá và đánh giá nơi lưu trú vẫn là trách nhiệm bên ngoài. Tích hợp chuyên dụng hỗ trợ các tenant *.ghe.com gốc đủ điều kiện, không phải GitHub Enterprise Server, các miền tùy ý, các miền con lồng nhau hoặc các đường dẫn URL. |
| Kiểm thử và bằng chứng triển khai | Các trường hợp API, kịch bản kiểm thử, báo cáo và quy trình làm việc CI/CD | Bằng chứng kiểm thử chỉ mạnh như mức độ bao phủ được thiết kế và liên kết tạo phẩm. Apidog không thay thế việc thực thi cổng runtime, khả năng quan sát sản xuất hoặc phản ứng sự cố. |
Đối với việc lựa chọn nền tảng, hãy so sánh các sản phẩm với ma trận đã hoàn thành thay vì điều chỉnh mô hình hoạt động của bạn theo danh sách tính năng. So sánh các công cụ quản trị API phân tách các khả năng quản trị thiết kế, không gian làm việc, kho, bảo mật và runtime.
Câu hỏi thường gặp về khuôn khổ quản trị API
Các thành phần của một khuôn khổ quản trị API là gì?
Các thành phần cốt lõi là kết quả và phạm vi, mô hình hoạt động, kho API và mô hình rủi ro, thư viện kiểm soát được phiên bản, các chế độ kiểm soát quy trình làm việc, quy trình bằng chứng và ngoại lệ, và vòng lặp đo lường và cải thiện.
Ai nên sở hữu quản trị API?
Một nhà tài trợ điều hành nên sở hữu nhiệm vụ, trong khi một nền tảng API, kiến trúc hoặc trưởng nhóm hỗ trợ điều hành chương trình. Quản lý miền và chủ sở hữu sản phẩm API nên sở hữu ứng dụng cục bộ. Các chức năng bảo mật, quyền riêng tư, IAM, SRE và tuân thủ vẫn chịu trách nhiệm về các kiểm soát trong các lĩnh vực chuyên môn của họ.
Quản trị API nên được tập trung hay liên bang?
Các doanh nghiệp lớn thường hưởng lợi từ một mô hình liên bang: một tiêu chuẩn cơ sở doanh nghiệp tối thiểu với các quyết định miền được ủy quyền. Xem xét trung tâm có thể vẫn dành cho các ngoại lệ rủi ro cao, trong khi công việc tuân thủ thông thường tuân theo các mẫu tự phục vụ.
Những gì thuộc về ma trận kiểm soát quản trị API?
Bao gồm mục tiêu kiểm soát, phạm vi, bậc rủi ro, trình kích hoạt, chế độ, vai trò chịu trách nhiệm chính và chịu trách nhiệm thực hiện, hệ thống triển khai, bằng chứng, chu kỳ, mục tiêu khắc phục, người phê duyệt ngoại lệ, trạng thái và ngày xem xét.
Các kiểm soát quản trị có nên chặn các bản phát hành không?
Chỉ khi yêu cầu là quan trọng, có tính xác định, ổn định và được hỗ trợ bởi khắc phục rõ ràng và đường dẫn ngoại lệ. Sử dụng hướng dẫn, cảnh báo hoặc xem xét thủ công khi ngữ cảnh quan trọng hoặc các dương tính giả sẽ tạo ra sự gián đoạn không cân xứng.
Mô hình trưởng thành quản trị API là gì?
Đó là một cách để đánh giá mức độ nhất quán của hoạt động quản trị—từ các thực hành phản ứng qua các kiểm soát được định nghĩa, nhúng, đo lường và thích ứng/liên bang. Đánh giá các miền một cách riêng biệt và sử dụng kết quả để chọn khoản đầu tư tiếp theo thay vì tạo ra một điểm số phù phiếm.
Apidog có thể tự cung cấp quản trị API hoàn chỉnh không?
Không có nền tảng phát triển nào bao phủ mọi lớp. Apidog có thể hỗ trợ thiết kế API, tài liệu, kiểm thử, cộng tác, nhận dạng không gian làm việc, kiểm soát thông tin xác thực, bằng chứng quản trị và quy trình làm việc Git. Lưu lượng runtime, ủy quyền sản xuất, bảo vệ mối đe dọa, SIEM, khả năng quan sát, cơ sở hạ tầng và chấp nhận rủi ro tổ chức yêu cầu các hệ thống và chủ sở hữu được kết nối phù hợp.
Làm cho khuôn khổ có thể thực thi được
Khuôn khổ quản trị API tốt nhất không phải là khuôn khổ có nhiều chính sách nhất. Đó là khuôn khổ mà các nhóm có thể áp dụng, người đánh giá có thể giải thích, chủ sở hữu rủi ro có thể bảo vệ và tổ chức có thể cải thiện bằng chứng.
Bắt đầu với một danh mục API thực tế, một tiêu chuẩn cơ sở kiểm soát nhỏ, các vai trò chịu trách nhiệm chính và một quy trình ngoại lệ trung thực. Sau đó, sử dụng mẫu ma trận kiểm soát để chuyển mỗi yêu cầu từ một khát vọng thành một quy trình làm việc.
Nếu tổ chức của bạn muốn hợp nhất các kiểm soát thiết kế, tài liệu, kiểm thử, cộng tác và không gian làm việc doanh nghiệp, hãy khám phá Apidog Enterprise dựa trên ma trận đã hoàn thành của bạn.