Danh mục API có thể phát triển nhanh hơn khả năng duy trì tính nhất quán của tổ chức. Một nhóm sử dụng mô hình đặt tên khác với nhóm kia, quyền sở hữu trở nên không rõ ràng, thông tin xác thực xuất hiện trong các ví dụ được chia sẻ, quyền truy cập vẫn còn sau khi mọi người thay đổi vai trò và tài liệu bị lạc hậu so với triển khai.
Quản trị API cung cấp cho các tổ chức một cách thức có thể lặp lại để ngăn chặn những vấn đề đó mà không biến mỗi quyết định về API thành một cuộc họp ủy ban.
Quản trị API là hệ thống quyền ra quyết định, tiêu chuẩn, chính sách, quy trình và bằng chứng được sử dụng để hướng dẫn các API trong suốt vòng đời của chúng. Nó xác định thế nào là tốt, ai chịu trách nhiệm, nơi các biện pháp kiểm soát được áp dụng, cách xác minh sự tuân thủ và cách xử lý các ngoại lệ.
Quản trị hiệu quả không chỉ đơn thuần là một danh sách các quy tắc thiết kế. Nó kết nối thiết kế API, tài liệu, thử nghiệm, quyền sở hữu vòng đời, danh tính, quyền truy cập, bảo vệ thông tin xác thực, bằng chứng kiểm toán và quản lý thay đổi. Mục tiêu là một con đường thuận lợi giúp các nhóm xây dựng các API đáng tin cậy nhanh hơn.
Tổng quan về quản trị API
Một chương trình quản trị thực tế trả lời bốn câu hỏi:
- Điều gì là bắt buộc? Xác định các tiêu chuẩn và chính sách tối thiểu cho từng API hoặc cấp độ rủi ro.
- Ai quyết định? Chỉ định chủ sở hữu chịu trách nhiệm, người đánh giá và các kênh leo thang.
- Sự tuân thủ được xác minh như thế nào? Sử dụng các đánh giá, danh sách kiểm tra, kiểm soát nền tảng, thử nghiệm và các kiểm tra tự động hoặc do người dùng kích hoạt khi thích hợp.
- Điều gì xảy ra khi một quy tắc không thể tuân theo? Ghi lại một ngoại lệ, chủ sở hữu của nó, các biện pháp kiểm soát bù đắp, ngày hết hạn và sự phê duyệt.
Nó cũng tách biệt bốn khái niệm thường được coi là có thể hoán đổi cho nhau:
| Khái niệm | Mục đích | Ví dụ |
|---|---|---|
| Chính sách | Nêu rõ một kết quả bắt buộc | Thông tin xác thực sản xuất không được lưu trữ dưới dạng văn bản thuần túy trong các định nghĩa API được chia sẻ. |
| Tiêu chuẩn | Xác định một cách thức làm việc đã được phê duyệt | Tất cả các API REST công khai đều sử dụng các quy ước đặt tên, lỗi, phiên bản và phân trang của tổ chức. |
| Kiểm soát | Ngăn chặn, phát hiện hoặc ghi lại một sự sai lệch | Một chính sách thông tin xác thực chặn các bí mật văn bản thuần túy, hoặc một trình quét phát hiện một token có thể bị lộ. |
| Bằng chứng | Cho thấy liệu một biện pháp kiểm soát có hoạt động hay không | Một kết quả kiểm tra, hồ sơ phê duyệt, đánh giá quyền truy cập, báo cáo thử nghiệm hoặc sự kiện kiểm toán hành chính. |
Quản trị hoạt động hiệu quả khi các yếu tố này được kết nối. Một chính sách không có biện pháp kiểm soát thì khó thực thi. Một biện pháp kiểm soát không có chủ sở hữu sẽ tạo ra các phát hiện chưa được giải quyết. Bằng chứng không có yêu cầu xác định không chứng minh rằng rủi ro đúng đã được giải quyết.
Quản trị API so với Quản lý API so với Bảo mật API
Quản trị API, quản lý API và bảo mật API trùng lặp, nhưng chúng giải quyết các vấn đề khác nhau.
| Lĩnh vực | Câu hỏi chính | Phạm vi điển hình |
|---|---|---|
| Quản trị API | Những quy tắc, quyền sở hữu và bằng chứng nào nên áp dụng cho toàn bộ danh mục API? | Quyền ra quyết định, tiêu chuẩn, kiểm soát vòng đời, ngoại lệ, quản trị quyền truy cập và bằng chứng. |
| Quản lý API | API được xuất bản, vận hành, quan sát và tiêu thụ như thế nào? | Cổng API, định tuyến, giới hạn tốc độ, cổng thông tin nhà phát triển, phân tích thời gian chạy và đăng ký. |
| Bảo mật API | API, thông tin xác thực, dữ liệu và người tiêu dùng được bảo vệ như thế nào? | Xác thực, ủy quyền, bảo vệ mối đe dọa, bí mật, thử nghiệm, giám sát và ứng phó sự cố. |
Quản trị đặt ra các kỳ vọng mà khả năng quản lý và bảo mật giúp triển khai. Ví dụ, quản trị có thể yêu cầu mọi API được công khai ra bên ngoài phải có chủ sở hữu, một phương pháp xác thực đã được phê duyệt, một chính sách ngừng sử dụng đã được lập thành tài liệu và ghi nhật ký thời gian chạy. Một cổng API, hệ thống danh tính, nền tảng phát triển và ngăn xếp khả năng quan sát có thể cung cấp một phần của bộ kiểm soát.
Sự khác biệt này quan trọng khi lựa chọn công cụ. Một nền tảng thiết kế và cộng tác có thể quản lý các đặc tả, tài liệu, quyền truy cập không gian làm việc và hoạt động hành chính, trong khi một cổng hoặc nền tảng bảo mật quản lý lưu lượng thời gian chạy. Một chương trình doanh nghiệp thường kết nối các lớp này thay vì kỳ vọng một sản phẩm có thể thay thế tất cả chúng. Xem các hướng dẫn rộng hơn về bảo mật quản lý API và quản lý truy cập API cho các lĩnh vực liền kề đó.
Tại sao quản trị API lại quan trọng ở quy mô doanh nghiệp
Các nhóm nhỏ có thể dựa vào thỏa thuận không chính thức trong một thời gian. Phương pháp đó trở nên mong manh khi một tổ chức có nhiều nhóm, API, kho lưu trữ, môi trường và người tiêu dùng bên ngoài.
Quản trị API giúp các doanh nghiệp:
- Giảm sự không nhất quán và làm lại. Các tiêu chuẩn thiết kế và tài liệu được chia sẻ giúp API dễ đoán hơn cho nhà sản xuất và người tiêu dùng.
- Giúp quyền sở hữu hiển thị rõ ràng. Mỗi API, chính sách, ngoại lệ và quyết định vòng đời đều có một người hoặc nhóm chịu trách nhiệm.
- Mở rộng khả năng tự phục vụ của nhà phát triển. Các mẫu, ví dụ, thành phần có thể tái sử dụng và các kênh leo thang rõ ràng cho phép các nhóm đưa ra các quyết định thông thường một cách độc lập.
- Bảo vệ môi trường cộng tác. Vòng đời danh tính, kiểm soát truy cập dựa trên vai trò, xử lý thông tin xác thực và bằng chứng hành chính giúp giảm rủi ro không gian làm việc.
- Cải thiện khả năng khám phá và tái sử dụng. Một danh mục API giúp các nhóm tìm thấy các khả năng hiện có trước khi tạo bản sao.
- Quản lý thay đổi một cách có chủ ý. Các quy tắc về phiên bản, khả năng tương thích, ngừng sử dụng và loại bỏ bảo vệ người tiêu dùng khỏi những thay đổi không mong muốn.
- Tạo ra bằng chứng hữu ích. Kết quả kiểm soát, phê duyệt, sự kiện kiểm toán và hồ sơ khắc phục giúp người đánh giá hiểu điều gì đã xảy ra và ai đã hành động.
Mục tiêu không phải là sự đồng nhất vì lợi ích của nó. Quản trị tốt chuẩn hóa các quyết định có thể lặp lại đồng thời tạo không gian cho các nhóm sản phẩm đưa ra các lựa chọn cụ thể theo miền.
Quản trị API tập trung hay liên đoàn?
Một nhóm quản trị tập trung có thể xác định các quy tắc nhất quán, nhưng nó cũng có thể trở thành nút cổ chai nếu phải phê duyệt mọi thay đổi API. Một mô hình phân quyền hoàn toàn trao quyền tự chủ cho các nhóm nhưng thường tạo ra các tiêu chuẩn mâu thuẫn và kiểm soát rủi ro không đồng đều.
Các tổ chức lớn thường cần một mô hình liên đoàn:
- Một nhóm hỗ trợ hoặc nền tảng trung tâm sở hữu nền tảng doanh nghiệp, các mẫu được chia sẻ, kiểm soát chung và báo cáo.
- Các nhóm miền sở hữu API của họ và có thể thêm các tiêu chuẩn cụ thể theo miền nghiêm ngặt hơn.
- Người quản lý API giúp các nhóm giải thích các quy tắc và giải quyết các câu hỏi thường lệ.
- Một quy trình xử lý ngoại lệ được xác định rõ ràng xử lý các sai lệch hợp lệ mà không làm suy yếu nền tảng một cách thầm lặng.
- Các API có rủi ro cao nhận được nhiều đánh giá hơn so với các API nội bộ có rủi ro thấp.
Liên đoàn không chỉ là phân phối quyền phê duyệt. Mỗi quyết định được ủy quyền vẫn cần một chủ sở hữu rõ ràng, một bộ kiểm soát đã được phê duyệt và bằng chứng có thể được xem xét trên toàn tổ chức.
Các lĩnh vực kiểm soát quản trị API cốt lõi
Một khuôn khổ doanh nghiệp nên bao quát toàn bộ vòng đời thay vì chỉ tập trung vào các quy tắc kiểu dáng.
| Lĩnh vực quản trị | Các câu hỏi cần trả lời | Các biện pháp kiểm soát và bằng chứng điển hình |
|---|---|---|
| Mô hình hoạt động và quyền sở hữu | Ai sở hữu API, tiêu chuẩn, ngoại lệ và quyền đánh giá? | RACI, chủ sở hữu dịch vụ được chỉ định, phân công người quản lý, kênh leo thang. |
| Danh mục và vòng đời | Những API nào tồn tại, ai sử dụng chúng và chúng đang ở giai đoạn nào? | Kiểm kê, phân loại, trạng thái vòng đời, ngày đánh giá, hồ sơ ngừng sử dụng. |
| Thiết kế và hợp đồng | Các giao diện có nhất quán, dễ hiểu và tương thích không? | Hợp đồng OpenAPI, tiêu chuẩn đặt tên và lỗi, lược đồ có thể tái sử dụng, đánh giá khả năng tương thích. |
| Tài liệu và khám phá | Người tiêu dùng có thể hiểu và tìm thấy API không? | Mô tả, ví dụ, ràng buộc, định nghĩa phản hồi, tài liệu đã xuất bản bắt buộc. |
| Thử nghiệm và phát hành | API đã được xác thực trước khi phát hành chưa? | Kiểm thử hợp đồng, kiểm thử chức năng, mô phỏng, kết quả kiểm thử, tiêu chí phát hành, phê duyệt hoặc ngoại lệ. |
| Danh tính và quyền truy cập | Ai có thể tham gia, xem, thay đổi, quản lý hoặc xuất tài sản API? | SSO, cung cấp và hủy cung cấp, RBAC, ánh xạ nhóm, đánh giá quyền truy cập định kỳ. |
| Thông tin xác thực và dữ liệu nhạy cảm | Bí mật được lưu trữ, tham chiếu, phát hiện và khắc phục như thế nào? | Tham chiếu Vault, chính sách thông tin xác thực, quét bí mật, quy trình xoay vòng, xác định quyền sở hữu. |
| Kiểm toán và bằng chứng | Tổ chức có thể tái tạo lại các hành động hành chính quan trọng không? | Nhật ký kiểm toán hành chính, xuất khẩu, truy vấn API, hồ sơ đánh giá, lưu trữ bằng chứng. |
| Kiểm soát mã nguồn và yêu cầu dữ liệu | Các đặc tả được lưu trữ ở đâu và những yêu cầu về vị trí nào được áp dụng? | Các kho lưu trữ đã được phê duyệt, kiểm soát nhánh, quyền kho lưu trữ, đánh giá tích hợp, đánh giá vị trí cư trú. |
Các lĩnh vực này nên được chuyển đổi thành một ma trận kiểm soát chứa mục tiêu kiểm soát, phạm vi, chủ sở hữu, phương pháp triển khai, bằng chứng, tần suất đánh giá, quy trình ngoại lệ và các cấp độ rủi ro áp dụng.
Cách xây dựng khuôn khổ quản trị API
1. Bắt đầu với kết quả kinh doanh và rủi ro
Tránh bắt đầu với hàng trăm quy tắc. Chọn một số ít kết quả mà tổ chức cần, chẳng hạn như các API đối tác có thể dự đoán, ít thay đổi gây lỗi hơn, quá trình giới thiệu nhanh hơn, xử lý thông tin xác thực tốt hơn hoặc quy trình ngừng làm việc có thể chứng minh được.
Mỗi yêu cầu quản trị nên kết nối với một kết quả. Nếu một quy tắc được đề xuất không có người tiêu dùng, rủi ro hoặc lợi ích hoạt động có thể xác định được, đó có thể là một quy trình không cần thiết.
2. Kiểm kê API và gán cấp độ rủi ro
Ghi lại mọi API đã biết, chủ sở hữu của nó, người tiêu dùng, mức độ phơi nhiễm, độ nhạy cảm của dữ liệu, trạng thái vòng đời và nguồn đáng tin cậy. Việc kiểm kê không đầy đủ khiến việc áp dụng các biện pháp kiểm soát một cách nhất quán trở nên bất khả thi.
Sử dụng các cấp độ rủi ro để tránh đối xử như nhau với tất cả các API. Một API thanh toán công khai có thể yêu cầu đánh giá khả năng tương thích chính thức, bằng chứng mạnh mẽ hơn và thời hạn khắc phục ngắn hơn. Một nguyên mẫu nội bộ tạm thời có thể sử dụng một cơ sở nhỏ hơn. Tiêu chí phân cấp phải đủ rõ ràng để các nhóm khác nhau đưa ra các quyết định tương tự.
Kết nối danh mục với quản trị vòng đời API và khám phá để quyền sở hữu và trạng thái vẫn hiển thị sau đánh giá ban đầu.
3. Gán quyền ra quyết định
Xác định ai chịu trách nhiệm cho:
- nền tảng quản trị doanh nghiệp;
- các phần mở rộng cụ thể theo miền;
- mỗi API và tài liệu của nó;
- đánh giá bảo mật và quyền riêng tư;
- phê duyệt ngoại lệ;
- khắc phục các biện pháp kiểm soát không thành công;
- các quyết định ngừng sử dụng và loại bỏ.
Quyền sở hữu nên được gắn với các vai trò và nhóm, không chỉ tên cá nhân. Điều đó làm cho mô hình linh hoạt hơn khi mọi người thay đổi vị trí hoặc rời đi.
4. Xác định một bộ kiểm soát tối thiểu khả thi
Bắt đầu với các biện pháp kiểm soát giải quyết các vấn đề chung và quan trọng. Một nền tảng đầu tiên hữu ích có thể yêu cầu:
- một chủ sở hữu được chỉ định và trạng thái vòng đời;
- một hợp đồng API theo định dạng đặc tả đã được phê duyệt;
- đặt tên, lỗi, xác thực, phiên bản và phân trang tiêu chuẩn khi áp dụng;
- mô tả, ví dụ, ràng buộc tham số, phản hồi và các trường hợp lỗi;
- các kiểm thử và tiêu chí đánh giá bắt buộc;
- tham chiếu thông tin xác thực đã được phê duyệt thay vì bí mật văn bản thuần túy được chia sẻ;
- quyền truy cập không gian làm việc dựa trên vai trò và quy trình ngừng làm việc;
- một quy trình thay đổi gây lỗi và ngừng sử dụng;
- bằng chứng được ghi lại và một đường dẫn ngoại lệ.
Sử dụng tiêu chuẩn hóa API để xác định nền tảng thiết kế, sau đó biến các yêu cầu tài liệu thành một danh sách kiểm tra tài liệu điểm cuối API.
5. Đưa các biện pháp kiểm soát vào quy trình phân phối
Quản trị dễ thực hiện nhất khi các kiểm tra diễn ra tại nơi các nhóm đã làm việc.
| Giai đoạn vòng đời | Hoạt động quản trị |
|---|---|
| Khám phá và lập kế hoạch | Tìm kiếm danh mục, xác định chủ sở hữu, phân loại rủi ro và dữ liệu, và xác nhận liệu một API hiện có có thể được tái sử dụng hay không. |
| Thiết kế | Tạo hợp đồng, áp dụng các tiêu chuẩn, xem xét tính đầy đủ của tài liệu và xác định các ràng buộc tương thích dự kiến. |
| Phát triển và kiểm thử | Sử dụng mô phỏng và kiểm thử, giữ thông tin xác thực tránh xa các định nghĩa được chia sẻ và đồng bộ hóa các tạo phẩm đã được phê duyệt với kiểm soát mã nguồn khi cần thiết. |
| Đánh giá và phát hành | Đánh giá các biện pháp kiểm soát bắt buộc, ghi lại bằng chứng, giải quyết các phát hiện và phê duyệt các ngoại lệ có giới hạn thời gian. |
| Vận hành và thay đổi | Đánh giá quyền truy cập, xoay vòng thông tin xác thực, thu thập bằng chứng thời gian chạy từ các hệ thống vận hành thích hợp và quản lý các phiên bản. |
| Ngừng sử dụng và loại bỏ | Thông báo cho người tiêu dùng, theo dõi quá trình di chuyển, loại bỏ quyền truy cập và thông tin xác thực, lưu trữ bằng chứng và cập nhật danh mục. |
Một số biện pháp kiểm soát có thể được tự động hóa trong các hệ thống CI/CD hoặc chính sách. Những biện pháp khác yêu cầu chủ sở hữu sản phẩm, kiến trúc sư hoặc người đánh giá bảo mật đưa ra quyết định theo ngữ cảnh. Tự động hóa các kiểm tra có thể lặp lại, không phải trách nhiệm giải trình.
6. Tạo một quy trình xử lý ngoại lệ thực tế
Các nhóm đôi khi sẽ có lý do hợp lệ để không tuân theo mặc định. Một ngoại lệ nên bao gồm:
- API và yêu cầu bị ảnh hưởng;
- lý do tiêu chuẩn hiện tại không thể đáp ứng;
- rủi ro và bất kỳ biện pháp kiểm soát bù đắp nào;
- chủ sở hữu chịu trách nhiệm và người phê duyệt;
- ngày hết hạn hoặc đánh giá;
- quyết định khắc phục hoặc chấp nhận.
Theo dõi các ngoại lệ ngăn chặn các giải pháp "tạm thời" trở thành chính sách vĩnh viễn không được nhìn thấy.
7. Tạo điều kiện cho các nhóm bằng một con đường thuận lợi
Ghép nối các yêu cầu với các tài nguyên có thể tái sử dụng: các ví dụ đã được phê duyệt, mẫu, thành phần lược đồ, mẫu xác thực, mô hình lỗi, danh sách kiểm tra và hướng dẫn khắc phục sự cố. Giải thích tại sao mỗi biện pháp kiểm soát quan trọng tồn tại và đưa ra một ví dụ tuân thủ.
Điều này thay đổi quản trị từ một cổng đánh giá thành một hệ thống hỗ trợ. Các nhóm có thể giải quyết các vấn đề phổ biến trước khi yêu cầu phê duyệt, và người đánh giá có thể tập trung vào các quyết định có rủi ro cao hơn.
8. Đo lường kết quả và cải thiện nền tảng
Đánh giá các số liệu, ngoại lệ, sự cố, câu hỏi hỗ trợ và phản hồi của nhà phát triển theo định kỳ. Loại bỏ các quy tắc không cải thiện kết quả, làm rõ các quy tắc gây ra sự nhầm lẫn lặp đi lặp lại và tăng cường các biện pháp kiểm soát khi các lỗi tái diễn.
Các phương pháp hay nhất về quản trị API
Áp dụng quản trị trong suốt vòng đời
Chỉ đánh giá thiết kế thôi không thể giải quyết quyền truy cập cũ, thông tin xác thực không được quản lý, thay đổi gây lỗi không có tài liệu hoặc loại bỏ. Áp dụng các biện pháp kiểm soát thích hợp từ giai đoạn khám phá đến ngừng sử dụng.
Sử dụng các biện pháp kiểm soát dựa trên rủi ro
Tạo một nền tảng tối thiểu phổ quát, sau đó thêm các biện pháp kiểm soát dựa trên mức độ phơi nhiễm, độ nhạy cảm của dữ liệu, tác động đến người tiêu dùng, bối cảnh quy định và mức độ quan trọng trong kinh doanh. Quản trị dựa trên rủi ro dễ bảo vệ hơn và ít gánh nặng hơn so với việc áp dụng quy trình nghiêm ngặt nhất cho mọi API.
Các danh sách kiểm tra trong ngành có thể chuyển nền tảng đó thành các câu hỏi đánh giá cụ thể hơn. Ví dụ, danh sách kiểm tra quản trị API fintech này kết nối các yêu cầu về quyền truy cập, tài liệu, thay đổi và bằng chứng cho các nhóm API tài chính mà không coi một công cụ là sự thay thế cho việc đánh giá tuân thủ của chính tổ chức.
Tách biệt kiểm soát không gian làm việc khỏi kiểm soát thời gian chạy
Nhật ký kiểm toán hành chính không phải là nhật ký yêu cầu API. RBAC không gian làm việc không phải là ủy quyền thời gian chạy. Kiểm tra tuân thủ thiết kế không phải là thực thi sản xuất liên tục. Nêu rõ mỗi biện pháp kiểm soát bao phủ lớp nào và kết nối nó với hệ thống cổng, danh tính, bảo mật hoặc khả năng quan sát chịu trách nhiệm cho các lớp khác.
Ưu tiên phòng ngừa, sau đó là phát hiện và khắc phục
Khi có thể, hãy ngăn chặn hành vi rủi ro bằng các mẫu đã được phê duyệt, vai trò đặc quyền tối thiểu, tham chiếu kho lưu trữ và chính sách chặn. Sử dụng các kiểm tra và trình quét để xác định những gì phòng ngừa bỏ sót. Mỗi phát hiện vẫn cần một chủ sở hữu, mức độ nghiêm trọng, hành động khắc phục và ngày mục tiêu.
Biến các tiêu chuẩn thành sản phẩm có phiên bản
Xuất bản nhật ký thay đổi, ví dụ, hướng dẫn di chuyển và ngày có hiệu lực cho các tiêu chuẩn. Tránh thay đổi một quy tắc mà không giải thích cách các API hiện có nên phản ứng.
Xử lý các ngoại lệ như dữ liệu quản trị
Nhóm các ngoại lệ theo quy tắc, nhóm và nguyên nhân gốc rễ. Một số lượng lớn các ngoại lệ tương tự có thể cho thấy thiếu khả năng hỗ trợ, một tiêu chuẩn được thiết kế kém, một hạn chế của sản phẩm hoặc một biện pháp kiểm soát nên được tự động hóa.
Giữ các nhà phát triển trong vòng phản hồi
Đo lường thời gian kiểm tra mất bao lâu, nơi các nhóm bị tắc nghẽn và hướng dẫn nào khó áp dụng. Quản trị thành công khi nó cải thiện cả kết quả kiểm soát và chất lượng phân phối.
Cách đo lường quản trị API
Không chỉ đo lường thành công bằng số lượng chính sách đã viết hoặc đánh giá đã hoàn thành. Sử dụng một bộ số liệu cân bằng về phạm vi bao phủ, sự tuân thủ, rủi ro, luồng và kết quả.
| Số liệu | Ví dụ tính toán hoặc diễn giải |
|---|---|
| Phạm vi quyền sở hữu | API có chủ sở hữu chịu trách nhiệm ÷ API trong kho. |
| Phạm vi vòng đời | API có trạng thái vòng đời hiện tại và ngày đánh giá ÷ API đã kiểm kê. |
| Tuân thủ thiết kế | API đã kiểm tra vượt qua kiểm soát thiết kế bắt buộc ÷ API đã kiểm tra. Phân đoạn theo cấp độ rủi ro. |
| Mức độ đầy đủ của tài liệu | Các điểm cuối bắt buộc đáp ứng nền tảng tài liệu ÷ các điểm cuối được đánh giá. |
| Tình trạng ngoại lệ | Các ngoại lệ đang mở theo tuổi, rủi ro, chủ sở hữu và trạng thái hết hạn. |
| Độ trễ loại bỏ quyền truy cập | Thời gian giữa một sự kiện ngừng làm việc và việc loại bỏ quyền truy cập không gian làm việc liên quan. |
| Khắc phục phát hiện thông tin xác thực | Thời gian để phân loại và giải quyết các thông tin xác thực bị nghi ngờ bị lộ, phân tách theo mức độ nghiêm trọng. |
| Tỷ lệ thay đổi gây lỗi | Các bản phát hành chứa các thay đổi gây lỗi không mong muốn ÷ các bản phát hành được đánh giá. |
| Hiệu quả loại bỏ | Các API đã ngừng sử dụng được loại bỏ theo lịch trình và người tiêu dùng đã di chuyển thành công. |
| Trải nghiệm nhà phát triển | Thời gian để vượt qua kiểm soát, tỷ lệ lỗi lặp lại, khối lượng hỗ trợ và phản hồi của nhóm. |
Luôn xác định mẫu số và phạm vi. Tỷ lệ đạt 95% có ý nghĩa rất ít nếu chỉ một phần nhỏ, tự chọn của danh mục được kiểm tra.
Apidog hỗ trợ quản trị API doanh nghiệp như thế nào
Apidog mang thiết kế, tài liệu, thử nghiệm, cộng tác và kiểm soát không gian làm việc doanh nghiệp vào một nền tảng phát triển API. Nó mạnh nhất trong quản trị thời gian thiết kế và cộng tác; các tổ chức nên kết nối nó với cổng thời gian chạy, cơ sở hạ tầng, SIEM và các biện pháp kiểm soát khả năng quan sát của họ khi cần thiết.
| Mục tiêu quản trị | Khả năng liên quan của Apidog | Phạm vi để truyền đạt chính xác |
|---|---|---|
| Thiết kế API nhất quán | Quy trình làm việc API ưu tiên thiết kế, hỗ trợ OpenAPI, định nghĩa có thể tái sử dụng và Kiểm tra Tuân thủ Điểm cuối. | Kiểm tra Tuân thủ Điểm cuối đánh giá việc đặt tên, tài liệu và cấu trúc phản hồi khi người dùng chạy nó; không mô tả nó như một sự thực thi liên tục phổ quát. |
| Tài liệu đầy đủ | Tài liệu được tạo/chia sẻ và Kiểm tra Mức độ Hoàn chỉnh Tài liệu API. | Việc kiểm tra đánh giá các mục như định nghĩa, mô tả, ràng buộc, cấu trúc phản hồi, mã trạng thái và lỗi. |
| Danh tính không gian làm việc được kiểm soát | SAML SSO, cung cấp SCIM, RBAC cho các nhóm API và ánh xạ nhóm SAML. | Chúng quản lý quyền truy cập vào các tổ chức, nhóm, dự án và tài sản API của Apidog — không phải ủy quyền để gọi một API sản xuất. Tài liệu SCIM công khai hiện tại nên được kiểm tra trước khi mô tả các hoạt động ngoài việc thêm và xóa người dùng. |
| Xử lý thông tin xác thực an toàn hơn | Quản lý môi trường và bí mật, tích hợp Vault, Chính sách Doanh nghiệp và Trình quét Bí mật. | Trình quét Bí mật chạy bất đồng bộ và phát hiện các bí mật có thể bị lộ bên trong các tài sản Apidog được hỗ trợ. Nó không tự động thu hồi, xoay vòng, xóa hoặc thay thế chúng. Sử dụng một quy trình xoay vòng khóa API đã được xác định để khắc phục. |
| Bằng chứng hành chính | Nhật ký Kiểm toán với các bộ lọc, xuất CSV và truy vấn API. | Nhật ký Kiểm toán của Apidog bao gồm các sự kiện tổ chức và hành chính được hỗ trợ với thời gian lưu giữ tài liệu là 180 ngày. Chúng không phải là lưu lượng API thời gian chạy hoặc nhật ký ứng dụng. |
| Quy trình làm việc kiểm soát mã nguồn được quản lý | Kết nối kho lưu trữ Git, nhập OpenAPI, sao lưu/đồng bộ hóa và cộng tác nguyên bản Git. | Quyền kho lưu trữ và quản trị nhánh vẫn cần được cấu hình trong nền tảng kiểm soát mã nguồn. Xem cách đồng bộ hóa OpenAPI với GitHub và bảo mật các đặc tả API được lưu trữ trong Git. |
| Khả năng tương thích lưu trú dữ liệu của GitHub Enterprise Cloud | Kết nối cấp tổ chức với các bên thuê lưu trú dữ liệu GitHub Enterprise Cloud được hỗ trợ. | Tích hợp hỗ trợ các bên thuê SaaS gốc *.ghe.com. Nó không hỗ trợ GitHub Enterprise Server, các miền tùy chỉnh tùy ý, các miền phụ lồng nhau hoặc đường dẫn URL. Nó không được trình bày như một sự đảm bảo đầy đủ về vị trí lưu trú hoặc tuân thủ. |
Đối với người mua đánh giá phạm vi bao phủ của nền tảng, hãy sử dụng so sánh dựa trên yêu cầu của các công cụ quản trị API thay vì chỉ chọn dựa trên số lượng tính năng.
Lộ trình triển khai thực tế trong 90 ngày
Ngày 1–30: Thiết lập nền tảng
- Kiểm kê danh mục ban đầu và chỉ định chủ sở hữu chịu trách nhiệm.
- Xác định các cấp độ rủi ro và chọn một miền thí điểm.
- Thống nhất năm đến mười biện pháp kiểm soát tối thiểu.
- Lập tài liệu về các quy trình làm việc hiện tại về danh tính, quyền truy cập, thông tin xác thực, kiểm soát mã nguồn và bằng chứng.
- Thiết lập một mẫu ngoại lệ và tần suất đánh giá.
Ngày 31–60: Thí điểm trong các quy trình phân phối thực tế
- Áp dụng nền tảng cho các API mới và các API hiện có được chọn.
- Xuất bản các ví dụ về thiết kế và tài liệu.
- Cấu hình SSO, cung cấp, RBAC và ánh xạ nhóm thích hợp.
- Kiểm tra tài liệu, thiết kế, thông tin xác thực và các biện pháp kiểm soát bằng chứng.
- Đo lường thời gian tuân thủ, các lý do lỗi phổ biến và các ngoại lệ chưa được giải quyết.
Ngày 61–90: Mở rộng những gì hoạt động hiệu quả
- Tinh chỉnh các biện pháp kiểm soát bằng cách sử dụng bằng chứng thí điểm và phản hồi của nhà phát triển.
- Mở rộng sang các miền bổ sung dựa trên rủi ro.
- Tạo bảng điều khiển cho phạm vi, sự tuân thủ, ngoại lệ và khắc phục.
- Thêm các biện pháp kiểm soát sâu hơn cho các API có rủi ro cao hơn.
- Xuất bản lộ trình cho các tích hợp thời gian chạy, đánh giá quyền truy cập định kỳ và dọn dẹp vòng đời.
Bắt đầu với đủ cấu trúc để học hỏi. Một bộ kiểm soát nhỏ hơn mà các nhóm nhất quán tuân theo hữu ích hơn một khuôn khổ toàn diện chỉ tồn tại trong một tài liệu.
Cách chọn công cụ quản trị API
Đánh giá các công cụ dựa trên mô hình hoạt động và ma trận kiểm soát, không phải ngược lại. Các yêu cầu quan trọng bao gồm:
- hỗ trợ các đặc tả và giao thức API của tổ chức;
- tiêu chuẩn thiết kế, các thành phần có thể tái sử dụng và kiểm tra chất lượng;
- quy trình làm việc tài liệu, khám phá, thử nghiệm và vòng đời;
- danh tính doanh nghiệp, cung cấp, RBAC và ánh xạ nhóm;
- lưu trữ bí mật, chính sách, phát hiện và tích hợp khắc phục;
- bằng chứng hành chính, lọc, xuất và API;
- tích hợp Git, CI/CD, nhà cung cấp danh tính, Vault, cổng và khả năng quan sát;
- yêu cầu triển khai, vị trí dữ liệu và kho lưu trữ;
- xử lý ngoại lệ và báo cáo;
- trải nghiệm nhà phát triển giúp con đường tuân thủ rõ ràng.
Không có công cụ nào cần thực hiện mọi chức năng thời gian chạy và phát triển. Câu hỏi quan trọng là liệu các công cụ có trao đổi các tạo phẩm và bằng chứng phù hợp mà không tạo ra khoảng trống về quyền sở hữu hay không.
Câu hỏi thường gặp về quản trị API
Quản trị API là gì một cách đơn giản?
Quản trị API là tập hợp các quy tắc, trách nhiệm, quy trình làm việc và bằng chứng mà một tổ chức sử dụng để giữ cho các API nhất quán, an toàn, dễ khám phá và dễ quản lý trong suốt vòng đời của chúng.
Ai nên sở hữu quản trị API?
Sự tài trợ của ban điều hành có thể thuộc về lãnh đạo công nghệ hoặc sản phẩm, trong khi một nhóm nền tảng hoặc hỗ trợ sở hữu nền tảng chung. Các nhóm miền nên chịu trách nhiệm về API của họ, và các nhóm bảo mật, kiến trúc, pháp lý, quyền riêng tư và vận hành nên sở hữu các biện pháp kiểm soát liên quan đến lĩnh vực của họ.
Các ví dụ về chính sách quản trị API là gì?
Các ví dụ bao gồm yêu cầu một chủ sở hữu chịu trách nhiệm, một đặc tả API đã được phê duyệt, các mẫu xác thực tiêu chuẩn, tài liệu đầy đủ, đánh giá khả năng tương thích ngược, lưu trữ thông tin xác thực đã được phê duyệt, quyền truy cập đặc quyền tối thiểu, bằng chứng kiểm toán và một thời gian ngừng sử dụng xác định.
Quản trị API có làm chậm quá trình phát triển không?
Quản trị được thiết kế kém có thể làm chậm quá trình phát triển. Quản trị hiệu quả giảm các quyết định lặp lại và làm lại bằng cách cung cấp các mẫu, ví dụ, thành phần có thể tái sử dụng, kiểm tra tự phục vụ, các cấp độ rủi ro và một đường dẫn ngoại lệ rõ ràng.
Quản trị API có giống với quản lý API không?
Không. Quản trị định nghĩa quyền ra quyết định, tiêu chuẩn, chính sách và bằng chứng trên toàn bộ danh mục. Quản lý API thường tập trung vào việc xuất bản và vận hành API thông qua các khả năng như cổng, cổng thông tin, chính sách thời gian chạy và phân tích.
Một tổ chức nên bắt đầu như thế nào?
Bắt đầu với việc kiểm kê, chủ sở hữu được chỉ định, các cấp độ rủi ro, một bộ kiểm soát tối thiểu nhỏ và một miền thí điểm. Đo lường thí điểm, cải thiện quy trình làm việc và mở rộng dựa trên bằng chứng thay vì cố gắng triển khai toàn doanh nghiệp ngay lập tức.
Xây dựng quản trị vào cách các nhóm API hoạt động
Quản trị API nên làm cho việc phân phối đáng tin cậy có thể lặp lại. Xác định quyền sở hữu rõ ràng, áp dụng các biện pháp kiểm soát dựa trên rủi ro trong suốt vòng đời, giúp các nhóm tuân thủ các tiêu chuẩn và sử dụng bằng chứng để cải thiện chương trình theo thời gian.
Apidog hỗ trợ mô hình này bằng cách đưa thiết kế API, tài liệu, thử nghiệm, quy trình làm việc Git, cộng tác, danh tính doanh nghiệp, kiểm soát thông tin xác thực và bằng chứng hành chính vào một nền tảng chung. Khám phá Apidog Enterprise để đánh giá cách các biện pháp kiểm soát đó phù hợp với khuôn khổ quản trị của tổ chức bạn.