API 거버넌스 프레임워크는 광범위한 원칙을 팀이 반복할 수 있는 결정으로 전환합니다. 이는 어떤 API가 범위에 포함되는지, 각 결정의 소유자는 누구인지, 어떤 제어가 적용되는지, 해당 제어가 어디에서 실행되는지, 어떤 증거를 생성하는지, 그리고 예외가 어떻게 승인되는지를 식별합니다.
이러한 운영 세부 사항이 거버넌스 문서와 거버넌스 시스템의 차이입니다.
이 가이드는 엔터프라이즈 API 프로그램을 위한 실용적인 프레임워크를 제공합니다. 포함된 내용은 다음과 같습니다:
- 7단계 운영 모델;
- 중앙 집중식 및 연합형 결정권;
- 일반적인 거버넌스 활동을 위한 RACI;
- 비례적인 제어를 적용하기 위한 위험 등급;
- 안내, 경고, 차단, 검토 제어 모드;
- 샘플 API 거버넌스 제어 매트릭스;
- 예외 및 증거 모델;
- 5단계 성숙도 모델;
- 12주 구현 로드맵.
더 넓은 정의, 비즈니스 사례, 지표 및 도구 카테고리가 먼저 필요하다면, API 거버넌스란 무엇인가?부터 시작하십시오. 이 문서는 구현부터 시작합니다.
API 거버넌스 프레임워크란 무엇인가?
API 거버넌스 프레임워크는 조직이 API 관련 의사 결정을 내리고 검증하는 데 사용하는 운영 시스템입니다. 이는 API 수명 주기 전반에 걸쳐 정책과 표준을 소유자, 제어, 증거, 측정 및 예외에 연결합니다.
완전한 프레임워크는 다음 7가지 질문에 답해야 합니다:
- 결과: 우리가 보호하려는 비즈니스, 소비자, 보안 또는 운영 결과는 무엇입니까?
- 범위: 어떤 API, 팀, 환경 및 수명 주기 단계가 포함됩니까?
- 결정권: 누가 기준선을 정의하고, 각 API를 소유하며, 예외를 승인하고, 발견 사항을 해결합니까?
- 위험: 어떤 API에 더 강력한 제어가 필요하며, 그 이유는 무엇입니까?
- 제어: 팀은 무엇을 해야 하며, 제어는 안내, 경고, 차단 또는 검토를 요구해야 합니까?
- 증거: 조직은 제어가 작동했음을 어떻게 알 수 있습니까?
- 개선: 어떤 측정값을 통해 거버넌스가 전달을 손상시키지 않으면서 위험을 줄이고 있는지 알 수 있습니까?
모든 회사가 변경 없이 복사할 수 있는 단일한 보편적인 API 거버넌스 표준은 없습니다. 프레임워크는 조직의 아키텍처, 소비자, 데이터, 배포 모델, 규제 맥락 및 위험 수용도를 반영해야 합니다. 외부 참조가 정보를 제공할 수 있습니다: OpenAPI 사양은 기계 판독 가능한 API 계약 형식을 정의하고; OWASP API 보안 Top 10은 보안 위험 입력을 제공하며; NIST 사이버 보안 프레임워크는 거버넌스, 역할, 정책, 위험 및 감독에 대한 광범위한 모델을 제공합니다. 이러한 출처 중 어느 것도 조직별 소유권 및 결정을 대체하지는 않습니다.
API 거버넌스 프레임워크의 7단계 계층
프레임워크를 긴 정책 문서가 아닌 7개의 연결된 계층으로 취급하십시오.
| 계층 | 내려야 할 결정 | 최소 출력 |
|---|---|---|
| 1. 결과 및 범위 | 거버넌스는 왜 존재하며, 무엇을 다루는가? | 결과 선언문, 범위, 제외 사항 및 검토 날짜 |
| 2. 운영 모델 | 누가 표준, API, 제어, 증거 및 예외를 소유하는가? | 결정권 지도 및 RACI |
| 3. 포트폴리오 및 위험 | 어떤 API가 존재하며, 각 API에 얼마나 많은 제어가 필요한가? | 재고, 소유자, 수명 주기 상태 및 위험 등급 |
| 4. 제어 도메인 | 설계, 접근, 보안, 변경 및 운영 전반에 걸쳐 어떤 요구 사항이 적용되는가? | 버전 관리된 제어 라이브러리 |
| 5. 제공 워크플로 | 제어는 어디에서 안내, 경고, 차단 또는 검토를 요구해야 하는가? | 제어 모드, 트리거 및 해결 경로 |
| 6. 증거 및 예외 | 제어가 작동했음을 무엇이 증명하며, 편차는 어떻게 관리되는가? | 증거 기록, 예외 기록, 소유자 및 만료일 |
| 7. 측정 및 개선 | 프레임워크가 결과 및 개발자 경험을 개선하고 있는가? | 성과 기록표, 검토 주기 및 개선 백로그 |
한 계층의 약점은 나머지 계층을 약화시킵니다. 소유자가 없는 정확한 표준은 선택 사항이 됩니다. 예외 처리 과정이 없는 차단 검사는 숨겨진 해결 방법을 만듭니다. 명시된 요구 사항이 없는 감사 추적은 활동을 기록하지만, 올바른 위험이 처리되었음을 증명하지는 않습니다.
1. 정책을 작성하기 전에 결과 및 범위를 정의하십시오
경영진, 플랫폼 팀 및 전달 팀이 인식할 수 있는 작은 결과 집합으로 시작하십시오. 예를 들어:
- 소비자는 올바른 API와 책임 있는 소유자를 찾을 수 있습니다;
- 공개 및 파트너 계약은 변경되더라도 예측 가능하게 유지됩니다;
- 고위험 API는 적절한 보안 및 개인 정보 보호 검토를 받습니다;
- 문서는 통합을 구현하고 테스트하기에 충분한 세부 정보를 포함합니다;
- 공유 API 자산에 프로덕션 자격 증명이 일반 텍스트로 나타나지 않습니다;
- 사람들이 퇴사하거나 더 이상 필요하지 않을 때 접근 권한이 제거됩니다;
- 더 이상 사용되지 않는 API는 소비자에게 문서화된 마이그레이션 경로를 제공합니다;
- 검토자는 중요한 결정 및 관리 조치를 재구성할 수 있습니다.
“모든 API는 규정을 준수해야 한다”와 같은 모호한 목표는 피하십시오. 무엇에 대해, 어떤 API에 대해, 어느 시점에서, 누구의 결정에 따라 규정을 준수해야 합니까? 측정 가능한 결과를 작성한 다음, 이를 지원하는 데 필요한 정책 및 제어를 식별하십시오.
명시적 경계를 설정하십시오
프레임워크가 다루는 내용을 문서화하십시오:
- REST, GraphQL, gRPC, 이벤트 중심 API 또는 기타 인터페이스 유형;
- 내부, 파트너, 공개 및 타사 API;
- 설계, 개발, 릴리스, 운영, 변경, 사용 중단 및 폐기;
- API 계약, 문서, 테스트, 리포지토리, 자격 증명 및 협업 작업 공간;
- 런타임 게이트웨이, ID 시스템, 로그, 관찰 가능성 및 사고 프로세스;
- 새로운 API만 또는 신규 및 기존 API 모두.
또한 제외 사항도 기록하십시오. 첫 번째 릴리스는 새로운 REST API 및 기존 공개 API에 대한 중요한 변경 사항을 다룰 수 있으며, 레거시 해결은 별도의 위험 기반 계획을 따를 수 있습니다. 명시적 제외는 관리 가능합니다; 가정된 제외는 사각지대가 됩니다.
2. 운영 모델을 선택하고 결정권을 할당하십시오
거버넌스는 일반적으로 두 가지 극단 중 하나에서 실패합니다. 중앙 위원회가 모든 결정을 승인하여 병목 현상이 되거나, 모든 팀이 정책을 독립적으로 해석하여 기업에 일관된 기준선이 없습니다.
대부분의 대규모 조직은 연합형 모델이 필요합니다:
- 중앙 API 플랫폼 또는 활성화 그룹이 엔터프라이즈 기준선, 공유 템플릿, 공통 도구 및 프로그램 보고를 소유합니다;
- 도메인 관리자는 기준선을 도메인별 지침으로 번역하고 팀이 이를 적용하도록 돕습니다;
- API 제품 소유자는 개별 API 및 소비자 결과에 대한 책임이 있습니다;
- 보안, 개인 정보 보호, IAM, SRE 및 규정 준수 전문가는 해당 도메인의 제어를 소유하거나 검토합니다;
- 전달 팀은 제어를 구현하고 발견 사항을 해결합니다;
- 정의된 위험 소유자는 시한부 예외를 승인합니다.
연합은 “팀이 모든 것을 결정한다”는 의미가 아닙니다. 이는 명시적인 경계, 증거 및 에스컬레이션 경로를 통해 권한이 분산됨을 의미합니다.
중앙 집중식, 연합형 또는 분산형?
| 모델 | 가장 적합한 경우 | 주요 위험 | 안전 장치 |
|---|---|---|---|
| 중앙 집중식 | API 포트폴리오가 작거나, 고도로 규제되거나, 일관성 없는 관행에서 시작하는 경우 | 검토 대기열 및 느린 결정 | 서비스 수준 목표, 재사용 가능한 패턴 및 위임 기준 |
| 연합형 | 많은 도메인이 엔터프라이즈 기준선을 공유하지만, 지역 전문 지식과 자율성이 필요한 경우 | 도메인 간 불균일한 해석 | 버전 관리된 기준선, 관리자 커뮤니티, 공통 증거 및 주기적 보정 |
| 분산형 | 팀이 독립적이고 API에 공유 소비자가 제한적이거나 위험이 적은 경우 | 중복 API, 호환되지 않는 표준 및 보이지 않는 노출 | 재고, 보안 및 소유권을 위한 최소 엔터프라이즈 제어 |
중앙 제어는 고위험 결정에 대해 더 엄격할 수 있으며, 일상적인 설계 선택은 자체 서비스로 유지될 수 있습니다. 운영 모델은 이념이 아닌 위험에 따라 달라져야 합니다.
실용적인 API 거버넌스 RACI
모델이 조직 변화에서도 살아남을 수 있도록 개별 이름 대신 역할을 사용하십시오.
| 활동 | 책임 (Accountable) | 담당 (Responsible) | 자문 (Consulted) | 정보 제공 (Informed) |
|---|---|---|---|---|
| 엔터프라이즈 API 거버넌스 결과 및 위험 수용도 설정 | 총괄 스폰서 | API 거버넌스/프로그램 리더 | 보안, 아키텍처, 법률/개인 정보 보호, 도메인 리더 | API 팀 |
| 엔터프라이즈 제어 기준선 유지 | API 플랫폼 또는 아키텍처 리더 | API 활성화 팀 | 보안, IAM, SRE, 도메인 관리자 | 제품 및 전달 팀 |
| 도메인 표준 및 재사용 가능한 패턴 유지 | 도메인 아키텍처 리더 | 도메인 API 관리자 | 중앙 활성화, 보안, 전달 담당자 | 도메인 팀 |
| API의 소유자, 소비자, 등급 및 수명 주기 상태를 최신으로 유지 | 도메인/제품 리더 | API 제품 소유자 | 기술 리더, 플랫폼 팀 | 소비자 |
| 설계, 문서화, 테스트 및 릴리스 제어 구현 | API 제품 소유자 | 전달 팀 | API 관리자, QA, 필요에 따른 보안 | 플랫폼/프로그램 리더 |
| 런타임 인증, 트래픽, 로깅 및 관찰 가능성 제어 운영 | 서비스/플랫폼 운영 리더 | 서비스 팀, SRE, 게이트웨이 또는 보안 팀 | API 소유자, 보안 | 거버넌스 프로그램 |
| 관리 작업 공간 접근 권한 프로비저닝, 검토 및 제거 | IAM 소유자 | IAM/IT 및 작업 공간 관리자 | 팀 소유자, 보안 | 거버넌스 프로그램 |
| 고위험 예외 승인 | 지정된 위험 소유자 | API 소유자가 요청 준비 | 제어 소유자, 보안/개인 정보 보호, 아키텍처 | 프로그램 리더 및 영향받는 소비자 |
| 지표 검토 및 프레임워크 개선 | API 거버넌스/프로그램 리더 | 활성화 및 데이터 소유자 | 도메인 관리자, 개발자 대표, 위험 소유자 | 총괄 스폰서 |
정확한 직책은 다를 수 있지만, 모든 활동에는 한 명의 책임 있는 역할이 필요합니다. 여러 명의 책임 있는 소유자는 보통 아무도 최종 결정을 내릴 수 없음을 의미합니다.
3. API를 인벤토리화하고 위험 등급을 할당하십시오
알 수 없는 포트폴리오에 프레임워크를 적용할 수 없습니다. 최소한 다음을 기록하십시오:
- API 이름 및 안정적인 식별자;
- 책임 있는 비즈니스 또는 제품 소유자;
- 기술 소유자 및 지원 담당자;
- 도메인 및 소비자;
- 인터페이스 유형 및 진실의 원천;
- 노출: 내부, 파트너 또는 공개;
- 데이터 분류;
- 비즈니스 중요도;
- 수명 주기 상태 및 검토 날짜;
- 배포 및 런타임 소유자;
- 종속성 및 알려진 소비자;
- 위험 등급 및 그 이유.
이 인벤토리를 API 카탈로그 및 API 수명 주기 프로세스에 연결하십시오. 스프레드시트로 작업을 시작할 수 있지만, 소유권 및 수명 주기 정보는 결국 팀이 최신 상태로 유지할 수 있는 곳에 있어야 합니다.
예시 3단계 모델
| 등급 | 일반적인 지표 | 예시 제어 처리 |
|---|---|---|
| 1등급: 중요 또는 고위험 | 공개 또는 파트너 노출; 규제되거나 고도로 민감한 데이터; 재정적 또는 안전 영향; 대규모 소비자 기반; 중요한 비즈니스 종속성 | 공식 소유자 및 아키텍처/보안 검토, 강화된 릴리스 증거, 테스트된 호환성 및 사용 중단, 더 짧은 해결 목표, 주기적 접근 검토, 런타임 증거 |
| 2등급: 중요 | 내부 또는 제한된 파트너 사용; 중요한 비즈니스 워크플로; 중간 데이터 민감도; 여러 종속 팀 | 엔터프라이즈 기준선, 자동 또는 사용자 트리거 설계/문서 검사, 필수 테스트, 지정된 소유자, 중요한 업데이트에 대한 변경 검토, 예정된 접근 검토 |
| 3등급: 저위험 또는 실험적 | 임시 프로토타입; 저민감도 내부 사용; 제한된 소비자 및 영향 | 경량 기준선, 소유자 및 만료일, 최소 자격 증명 및 접근 규칙, 더 넓은 사용 전 명확한 승격 기준 |
노출만으로 등급을 할당하지 마십시오. 고도로 민감한 직원 데이터를 처리하는 프라이빗 API는 간단한 공개 읽기 전용 API보다 더 많은 제어가 필요할 수 있습니다. 여러 요소를 사용하고 두 팀이 유사한 API를 평가할 때 유사한 결정을 내릴 수 있도록 근거를 기록하십시오.
4. 버전 관리된 제어 라이브러리 구축
정책은 필수 결과를 명시합니다. 표준은 승인된 작업 방식을 정의합니다. 제어는 편차를 방지, 감지 또는 기록합니다. 증거는 발생한 일을 보여줍니다. 이러한 아티팩트를 연결된 상태로 유지하십시오.
예를 들어:
- 정책: 공유 API 자산은 일반 텍스트 프로덕션 자격 증명을 포함해서는 안 됩니다.
- 표준: 민감한 인증 값은 승인된 로컬 전용 변수 또는 Vault 참조를 사용합니다.
- 예방 제어: 자격 증명 정책은 지원되지 않는 일반 텍스트 값 저장을 차단합니다.
- 탐지 제어: 스캐너는 지원되는 자산에서 가능한 비밀을 식별합니다.
- 교정 프로세스: 팀은 값을 제거하고, 발행 시스템에서 취소 또는 순환하며, 노출을 확인하고, 해결을 기록합니다.
- 증거: 정책 결과, 스캐너 발견, 외부 순환 티켓 및 종료 기록.
핵심 제어 도메인
| 도메인 | 제어 라이브러리가 답해야 할 질문 |
|---|---|
| 소유권 및 운영 모델 | 책임 있는 소유자가 지정되었는가? 누가 표준 및 예외를 승인하는가? |
| 포트폴리오 및 수명 주기 | API가 재고화되고, 분류되고, 검토되고, 사용 중단되고, 의도적으로 폐기되는가? |
| 설계 및 계약 | 기계 판독 가능한 계약이 있는가? 명명, 오류, 페이지 매김, 호환성 및 재사용 가능한 스키마가 처리되었는가? |
| 문서화 및 검색 | 소비자가 API를 찾고 인증, 매개변수, 제약 조건, 응답, 오류, 예시 및 변경 상태를 이해할 수 있는가? |
| 테스트 및 릴리스 | 릴리스 전에 어떤 계약, 기능, 보안, 성능 및 호환성 검사가 필요한가? |
| ID 및 관리 접근 | 누가 API 자산에 가입, 관리, 편집, 게시, 내보내기 또는 볼 수 있는가? 접근은 어떻게 검토되고 제거되는가? |
| 자격 증명 및 민감한 데이터 | 비밀은 어디에 저장될 수 있는가? 노출 후 어떻게 참조, 감지, 순환 및 제거되는가? |
| 소스 제어 및 공급망 | 어떤 리포지토리, 브랜치, 검토, 종속성 및 아티팩트 흐름이 승인되었는가? |
| 런타임 보호 및 운영 | 배포 후 어떤 게이트웨이, 권한 부여, 위협, 로깅, 모니터링, 복원력 및 사고 제어가 적용되는가? |
| 증거 및 예외 | 어떤 기록이 운영을 증명하며, 얼마나 오래 보관되며, 누가 편차를 승인할 수 있는가? |
API 설계 가이드라인은 테스트할 수 있을 만큼 구체적이어야 합니다. Google API 설계 가이드 및 Microsoft REST API 가이드라인과 같은 공개 예시는 조직이 일반적인 선호 사항을 구체적인 규칙으로 전환하는 방법을 보여줍니다. 소비자 및 아키텍처에 맞는 규칙만 채택하고, 모든 규칙에 소유자, 버전, 유효 날짜, 예시 및 마이그레이션 경로를 부여하십시오.
5. 올바른 제어 모드 선택: 안내, 경고, 차단 또는 검토
모든 요구 사항이 강제 게이트여야 하는 것은 아닙니다. 위험, 결정성, 성숙도 및 오탐 비용에 따라 모드를 선택하십시오.
| 모드 | 작동 방식 | 가장 적합한 경우 | 피해야 할 경우 |
|---|---|---|---|
| 안내 | 템플릿, 예시, 재사용 가능한 구성 요소 및 인라인 지침 제공 | 새로운 표준, 복잡한 설계 선택 및 자체 서비스 활성화 | 위험이 안정적인 예방 또는 증거를 요구하는 경우 |
| 경고 | 가능한 편차를 보고하지만, 워크플로가 계속되도록 허용 | 채택 기간, 저위험 문제 및 약간의 모호성이 있는 검사 | 팀이 중대한 위험을 무기한 무시할 수 있는 경우 |
| 차단 | 문제가 해결되거나 예외가 승인될 때까지 저장, 병합, 릴리스 또는 배포 방지 | 빠른 해결 경로를 가진 결정적이고 신뢰도 높은 요구 사항 | 규칙이 주관적이거나, 불안정하거나, 방해적인 오탐을 생성할 가능성이 있는 경우 |
| 검토 | 자격을 갖춘 사람에게 결정 전송 | 아키텍처 트레이드오프, 개인 정보 보호 맥락, 고위험 예외 및 소비자 판단이 필요한 변경 사항 | 모든 일상적인 변경에 동일한 희소한 검토자가 필요한 경우 |
효과적인 배포는 종종 팀이 예시, 도구 및 측정된 오탐율을 가진 후 안내에서 경고로, 그리고 차단으로 이동합니다. 일부 결정은 맥락이 중요하므로 항상 검토로 남아 있어야 합니다.
차단하기 전에 다음을 확인하십시오:
- 규칙에 이름이 지정된 소유자와 문서화된 근거가 있는지;
- 검사가 의도된 위험에 대해 충분히 결정적인지;
- 팀이 명확한 설명과 준수하는 예시를 받는지;
- 일반적인 워크플로 내에서 해결이 가능한지;
- 예외 경로가 존재하고 응답 대상이 있는지;
- 조직이 오탐, 우회 및 전달 영향을 측정할 수 있는지.
6. API 거버넌스 제어 매트릭스 생성
제어 매트릭스는 프레임워크의 작업 기록입니다. 구현하기에 충분히 상세해야 하지만, 검토하기에 충분히 간결해야 합니다.
최소한 다음을 포함하십시오:
- 제어 ID 및 도메인;
- 목표 및 요구 사항;
- 범위 및 적용 가능한 위험 등급;
- 수명 주기 트리거;
- 모드: 안내, 경고, 차단 또는 검토;
- 책임 및 담당 역할;
- 구현 시스템;
- 증거 및 기록 시스템;
- 검토 또는 실행 주기;
- 해결 목표;
- 예외 승인자 및 만료 규칙;
- 상태 및 마지막 검토 날짜.
샘플 API 거버넌스 제어 매트릭스
이 샘플은 시작점이며, 보편적인 규정 준수 체크리스트가 아닙니다.
| ID | 제어 목표 | 적용 대상 | 모드 | 책임 소유자 | 예시 증거 | 주기 또는 트리거 |
|---|---|---|---|---|---|---|
| GOV-01 | 모든 관리 API는 책임 소유자, 위험 등급, 진실의 원천 및 수명 주기 상태를 가집니다 | 모든 관리 API | 검토 | 도메인/제품 리더 | 카탈로그 기록 및 검토 이력 | 생성 시; 분기별 |
| DES-01 | 프로덕션 API는 해당되는 경우 승인된 기계 판독 가능한 계약을 사용합니다 | 모든 프로덕션 API | 차단 또는 검토 | API 제품 소유자 | 버전 관리된 OpenAPI 또는 기타 승인된 계약 | 생성 시 및 중요 변경 시 |
| DES-02 | 계약은 해당 설계 및 오류 표준을 따릅니다 | 1-2등급; 선택된 3등급 | 경고, 이후 결정적 규칙에 대해 차단 | API 아키텍처 리더 | 린트/검사 결과 및 승인된 예외 | 계약 변경 시 |
| DOC-01 | 엔드포인트는 목적, 인증, 매개변수, 제약 조건, 응답, 오류 및 대표적인 예시를 문서화합니다 | 모든 소비자 대면 API | 경고 또는 검토 | API 제품 소유자 | 문서화 체크리스트 또는 완전성 보고서 | 릴리스 전 |
| CHG-01 | 파괴적 변경 및 사용 중단은 승인된 소비자 알림 및 마이그레이션 프로세스를 따릅니다 | 공개, 파트너 및 널리 재사용되는 내부 API | 차단 + 검토 | API 제품 소유자 | 호환성 결과, 승인, 알림 및 마이그레이션 계획 | 중요 변경 시 |
| TST-01 | 필수 계약 및 기능 테스트는 릴리스 전에 통과해야 합니다 | 모든 프로덕션 API | 차단 | 엔지니어링 리더 | 릴리스에 연결된 테스트 보고서 | 모든 릴리스 |
| IAM-01 | 작업 공간 권한은 최소 권한 및 현재 직무를 반영합니다 | 모든 API 작업 공간 | 검토 | 팀/작업 공간 소유자 | 역할 할당 및 접근 검토 기록 | 분기별 및 역할 변경 시 |
| IAM-02 | 오프보딩 이벤트 후 관리 작업 공간 접근 권한은 즉시 제거됩니다 | 모든 API 작업 공간 | 자동화된 작업 + 검토 | IAM 소유자 | 프로비저닝 해제 이벤트 및 조정 결과 | 이벤트 발생 시; 월별 조정 |
| SEC-01 | 민감한 인증 값은 공유 일반 텍스트 대신 승인된 참조를 사용합니다 | 모든 공유 API 자산 | 차단 | 보안/플랫폼 소유자 | 정책 결과 또는 구성 기록 | 저장 또는 변경 시 |
| SEC-02 | 의심되는 노출된 자격 증명은 분류되고, 제거되고, 외부적으로 취소 또는 순환되고, 이유와 함께 종료됩니다 | 모든 지원 자산 | 탐지 + 검토 | 팀 소유자 | 발견, 소스 제거, 외부 순환 티켓 및 종료 | 탐지 시; 주간 노후화 검토 |
| SRC-01 | 관리되는 계약은 승인된 리포지토리, 권한, 브랜치 및 검토 경로를 사용합니다 | 1-2등급 | 소스 제어에서 차단 | 플랫폼/소스 제어 소유자 | 리포지토리 설정 및 풀 요청 이력 | 변경 시; 분기별 검토 |
| AUD-01 | 보안 관련 관리 조치는 증거 계획에 따라 수집되고 검토됩니다 | 1등급 및 규제 프로그램 | 기록 + 검토 | 보안/규정 준수 소유자 | 내보내기, API 수집, SIEM 기록 및 검토 티켓 | 매일 수집; 매월 검토 |
| RUN-01 | 노출된 API는 승인된 런타임 인증, 권한 부여, 트래픽, 위협 및 로깅 제어를 사용합니다 | 공개, 파트너 및 민감한 내부 API | 배포/런타임에서 차단 | 런타임 플랫폼/보안 소유자 | 게이트웨이 정책, 권한 부여 테스트, 런타임 로그 및 모니터링 | 배포 및 지속적인 운영 |
| LIF-01 | 사용 중단된 API는 소유자, 소비자 계획, 날짜 및 검증된 폐기를 가집니다 | 공개, 파트너 및 재사용된 내부 API | 검토 | API 제품 소유자 | 카탈로그 상태, 알림, 마이그레이션 추적 및 폐기 승인 | 폐기될 때까지 매월 |
다운로드 가능한 매트릭스는 이 샘플을 제어 모드 정의, RACI 필드, 증거 지침, 성숙도 점수, 구현 추적 및 Apidog 기능 맵으로 확장합니다.
7. 증거 및 예외를 일등 워크플로로 설계하십시오
증거는 특정 질문에 답해야 합니다
단지 존재한다는 이유만으로 로그를 수집하지 마십시오. 각 제어에 대해 다음을 정의하십시오:
- 증거가 지원하는 결정 또는 요구 사항;
- 원천 시스템 및 책임 소유자;
- 이를 해석하는 데 필요한 필드;
- 수집 및 검토 주기;
- 보관 및 접근 요구 사항;
- 격차 또는 실패한 제어가 어떻게 해결 작업을 생성하는지;
- 민감한 데이터 유출로부터 증거를 어떻게 보호하는지.
테스트 보고서는 특정 아티팩트에 대해 테스트가 실행되고 통과했음을 보여줄 수 있습니다. 이는 테스트가 모든 중요한 위험을 다루었음을 증명하지는 않습니다. 관리 감사 이벤트는 누가 역할을 변경했는지 보여줄 수 있습니다. 이는 런타임 요청 로그가 아닙니다. 설계 검토는 특정 시점에 엔드포인트가 확인되었음을 보여줄 수 있습니다. 이는 지속적인 프로덕션 적용이 아닙니다.
증거를 올바른 계층에 매핑하십시오: API 개발 플랫폼, 소스 제어, CI/CD, ID 공급자, 게이트웨이, 클라우드 플랫폼, SIEM, 관찰 가능성 시스템, 티켓팅 플랫폼 또는 위험 등록부. 대부분의 엔터프라이즈 제어는 하나 이상의 시스템이 필요합니다.
모든 예외에는 만료일이 필요합니다
사용 가능한 예외 기록에는 다음이 포함됩니다:
- 영향을 받는 API, 버전, 환경 및 제어 ID;
- 현재 요구 사항을 충족할 수 없는 이유;
- 위험 및 영향을 받는 소비자 또는 데이터;
- 보상 제어;
- 해결 또는 위험 수용 결정;
- 책임 소유자 및 승인자;
- 시작, 만료 및 검토 날짜;
- 증거 및 연결된 작업 항목;
- 최종 종료, 갱신 또는 에스컬레이션 결정.
예외는 요청하기 쉬워야 하지만, 잊기 어렵게 만들어야 합니다. 연령, 위험, 팀 및 제어별로 검토하십시오. 동일한 규칙에 대한 반복적인 예외는 부실한 활성화, 비현실적인 표준, 누락된 플랫폼 기능 또는 재설계되어야 할 규칙을 나타낼 수 있습니다.
API 거버넌스 성숙도 모델
성숙도 수준을 사용하여 다음 투자를 결정하고, 단일한 허영 점수를 만들지 마십시오. 각 제어 도메인을 개별적으로 평가하십시오; ID는 측정될 수 있지만 수명 주기 소유권은 반응적으로 남아 있을 수 있습니다.
| 수준 | 관찰 가능한 특성 | 보여줄 수 있어야 하는 증거 | 다음 단계 |
|---|---|---|---|
| 1. 반응적 | 규칙은 암묵적 지식; 소유권 및 재고가 불완전; 사고 후 검토 발생 | 분산된 문서 및 문제별 해결 | 소유자를 지정하고, 초기 포트폴리오를 재고화하며, 5~10개의 최소 제어를 정의 |
| 2. 정의됨 | 기준선 정책, 표준, 역할 및 예외 템플릿 존재 | 버전 관리된 표준, RACI, 초기 제어 매트릭스 및 할당된 등급 | 실제 팀과 함께 프레임워크를 시범 운영하고 공통 지침을 워크플로로 이동 |
| 3. 내장됨 | 제어가 설계, 개발, 릴리스, 접근 및 변경 중에 작동; 팀은 포장된 길을 가짐 | 검사 결과, 테스트 보고서, 접근 워크플로, 예외 기록 및 재사용 가능한 패턴 | 적용 범위, 오탐, 해결 시간 및 개발자 마찰 측정 |
| 4. 측정됨 | 적용 범위, 적합성, 예외, 발견 사항 및 전달 영향이 위험 등급별로 검토됨 | 신뢰할 수 있는 분모, 추세 데이터, 노후화 보고서 및 개선 결정 | 증거를 사용하여 더 많은 일상적인 결정을 위임하고 약한 도메인을 개선 |
| 5. 적응형 및 연합형 | 도메인 팀이 명확한 엔터프라이즈 경계 내에서 운영; 제어가 사고, 소비자 피드백 및 아키텍처 변경에 따라 진화 | 보정된 도메인 확장, 도메인 간 보고, 빠른 예외 결정 및 비효과적인 규칙 폐기 | 가정 계속 테스트; 성숙도가 관료주의가 되는 것을 방지 |
모든 도메인이 5단계에 도달할 것을 요구하지 마십시오. 안정적이고 저위험 영역은 정교한 적응형 프로그램보다 일관된 3단계가 더 필요할 수 있습니다.
12주 구현 로드맵
1-2주차: 위임 설정
- 총괄 스폰서 및 프로그램 리더 지정.
- 3~5개의 결과 및 초기 범위에 동의.
- 제외 사항, 가정 및 검토 날짜 기록.
- 실제 수요와 적극적인 전달 팀이 있는 시범 도메인 선택.
3-4주차: 포트폴리오 기준선 구축
- 시범 API, 소유자, 소비자, 진실의 원천, 노출, 데이터 및 수명 주기 상태를 재고화.
- 간단한 위험 등급 기준 정의 및 대표 API에 테스트.
- 누락된 소유권 및 알 수 없는 종속성을 명시적 위험으로 식별.
5-6주차: 결정권 및 최소 제어 정의
- RACI 및 에스컬레이션 경로 승인.
- 시범을 위한 5~10개의 고가치 제어 선택.
- 각 제어에 대한 목표, 범위, 모드, 소유자, 증거, 해결 및 예외 필드 작성.
- 준수하는 예시 및 템플릿 생성.
7-8주차: 워크플로에 제어 삽입
- 팀이 채택 기간이 필요한 경우 지침 및 경고로 시작.
- 결정적이고 중요한 요구 사항에 대해서만 하드 게이트 사용.
- 설계, 문서화, 테스트, ID, 자격 증명, 소스 제어 및 런타임 시스템을 관련 제어에 연결.
- 동일한 예시를 사용하여 검토자 및 전달 팀 교육.
9-10주차: 증거 및 예외 운영
- 증거가 결정 및 아티팩트 버전을 재구성할 수 있는지 테스트.
- 실패한 제어 및 예외 요청에 대한 탁상 훈련 실행.
- 검토 대기열, 응답 대상, 해결 소유자 및 만료 알림 정의.
- 보고서 및 내보내기에서 민감한 값 제거.
11-12주차: 측정 및 확장
- 적용 범위, 적합성, 예외 기간, 해결 시간, 오탐 및 전달 영향 검토.
- 시범 개발자 및 소비자 인터뷰.
- 더 많은 제어를 추가하기 전에 혼란스러운 규칙 수정.
- 다음 도메인 출시 및 런타임 통합 백로그 게시.
처음 12주의 목표는 완전한 엔터프라이즈 적용 범위가 아닙니다. 조직이 관찰하고 개선할 수 있는 작동하는 제어 루프입니다.
Apidog가 프레임워크에 매핑되는 방법
Apidog는 이 프레임워크에서 중요한 설계 시간 및 협업 제어를 지원할 수 있습니다. Apidog는 조직의 소스 제어, CI/CD, ID, 게이트웨이, SIEM, 관찰 가능성 및 위험 시스템(해당 시스템이 다른 제어를 소유하는 경우)에 연결되어야 합니다.
| 프레임워크 영역 | 관련 Apidog 기능 | 정확히 설명할 범위 |
|---|---|---|
| 설계 표준 | OpenAPI 중심 설계 워크플로 및 사용자 트리거 엔드포인트 준수 검사 | AI 검토는 사용자가 실행할 때 명명, 문서화, HTTP 메서드 사용, 응답 구조 및 보안 관행을 평가합니다. 이는 보편적인 지속적인 적용 또는 런타임 게이트가 아닙니다. |
| 문서 품질 | 생성/공유 문서 및 API 문서 완전성 검사 | 검사는 현재 엔드포인트 문서의 정의, 설명, 예시, 제약 조건, 상태 코드, 응답 및 오류를 검토합니다. |
| 작업 공간 ID | SAML SSO, SCIM 프로비저닝, 팀/프로젝트 역할 및 SAML 그룹 매핑 | 현재 공개 SCIM 문서는 사용자 추가 및 제거를 지원하며, 사용자 업데이트 또는 SCIM 그룹은 지원하지 않습니다. SAML 그룹 매핑은 기존에 할당된 프로젝트 역할을 덮어쓰지 않고 팀 멤버십 및 초기 프로젝트 역할을 관리할 수 있습니다. 이러한 제어는 프로덕션 API에 대한 호출을 승인하지 않습니다. |
| 최소 권한 협업 | 팀 역할 및 권한에 문서화된 내장 팀 역할 및 내장 또는 사용자 지정 프로젝트 역할 | 현재 문서는 사용자 지정 프로젝트 역할만 지원합니다; 사용자 지정 팀 또는 조직 역할은 아직 사용 가능한 것으로 문서화되지 않았습니다. |
| 자격 증명 방지 | 지원되는 인증 필드에 대한 Off, Warn 또는 Block 모드를 가진 엔터프라이즈 정책, 변수 및 Vault 참조 포함 | 정책 범위는 문서화된 인증 필드 및 워크플로로 제한됩니다. SSO 세션 정책은 조직 SSO 세션 중 내 팀에 대한 접근을 격리합니다; 이는 유휴 세션 시간 초과가 아닙니다. |
| 자격 증명 탐지 | 비동기 비밀 스캐너, 내장 및 사용자 지정 패턴, 마스킹된 발견 사항, 발생 횟수, 공개 노출 지표 및 해결 추적 | 비밀 스캐너는 엔터프라이즈 SaaS에 대해 문서화되어 있으며, 온프레미스 배포용으로는 아직 아닙니다. 외부 GitHub/GitLab 리포지토리를 스캔하거나 비밀을 자동으로 취소, 순환, 제거 또는 교체하지 않습니다. |
| 관리 증거 | 필터, CSV 내보내기 및 API 쿼리를 가진 감사 로그 | 감사 로그는 엔터프라이즈 SaaS에 대해 문서화되어 있으며, 온프레미스용으로는 아직 아니며, 180일 보관 기간을 가집니다. 이는 지원되는 조직/보안 이벤트를 다루며, 런타임 API 요청은 다루지 않습니다. 네이티브 SIEM 커넥터, Syslog, 웹훅 및 실시간 스트리밍은 현재 지원되는 것으로 문서화되지 않았습니다. |
| Git 및 진실의 원천 워크플로 | Git 연결, OpenAPI 가져오기/백업 및 GitHub Enterprise Cloud 데이터 상주 통합 | 리포지토리 권한, 브랜치, 검토 및 상주 평가는 외부 책임으로 남아 있습니다. 전용 통합은 GitHub Enterprise Server, 임의 도메인, 중첩된 하위 도메인 또는 URL 경로가 아닌 적격 루트 *.ghe.com 테넌트를 지원합니다. |
| 테스트 및 전달 증거 | API 사례, 테스트 시나리오, 보고서 및 CI/CD 워크플로 | 테스트 증거는 설계된 적용 범위 및 아티팩트 연결만큼만 강력합니다. Apidog는 런타임 게이트웨이 적용, 프로덕션 관찰 가능성 또는 사고 대응을 대체하지 않습니다. |
플랫폼 선택의 경우, 기능 목록에 운영 모델을 적용하기보다 완성된 매트릭스를 기준으로 제품을 비교하십시오. API 거버넌스 도구 비교는 설계 시간, 작업 공간, 재고, 보안 및 런타임 거버넌스 기능을 분리합니다.
API 거버넌스 프레임워크 FAQ
API 거버넌스 프레임워크의 구성 요소는 무엇입니까?
핵심 구성 요소는 결과 및 범위, 운영 모델, API 인벤토리 및 위험 모델, 버전 관리된 제어 라이브러리, 워크플로 제어 모드, 증거 및 예외 프로세스, 그리고 측정 및 개선 루프입니다.
누가 API 거버넌스를 소유해야 합니까?
총괄 스폰서가 위임을 소유해야 하며, API 플랫폼, 아키텍처 또는 활성화 리더가 프로그램을 운영해야 합니다. 도메인 관리자 및 API 제품 소유자는 로컬 적용을 소유해야 합니다. 보안, 개인 정보 보호, IAM, SRE 및 규정 준수 기능은 해당 전문 분야의 제어에 대한 책임이 있습니다.
API 거버넌스는 중앙 집중식이어야 합니까, 아니면 연합형이어야 합니까?
대규모 기업은 일반적으로 연합형 모델(위임된 도메인 결정을 가진 하나의 최소 엔터프라이즈 기준선)의 이점을 얻습니다. 중앙 검토는 고위험 예외에 대해 유지될 수 있으며, 일상적인 준수 작업은 자체 서비스 패턴을 따릅니다.
API 거버넌스 제어 매트릭스에는 무엇이 포함되어야 합니까?
제어 목표, 범위, 위험 등급, 트리거, 모드, 책임 및 담당 역할, 구현 시스템, 증거, 주기, 해결 목표, 예외 승인자, 상태 및 검토 날짜를 포함하십시오.
거버넌스 제어가 릴리스를 차단해야 합니까?
요구 사항이 중요하고, 결정적이며, 안정적이고, 명확한 해결 및 예외 경로로 지원되는 경우에만 차단해야 합니다. 맥락이 중요하거나 오탐이 불균형적인 혼란을 야기할 수 있는 경우에는 지침, 경고 또는 사람의 검토를 사용하십시오.
API 거버넌스 성숙도 모델은 무엇입니까?
이는 거버넌스가 얼마나 일관되게 작동하는지(반응적 관행부터 정의된, 내장된, 측정된, 적응형/연합형 제어까지) 평가하는 방법입니다. 도메인을 개별적으로 평가하고 그 결과를 사용하여 허영 점수를 생성하기보다는 다음 투자를 선택하십시오.
Apidog 자체만으로 완전한 API 거버넌스를 제공할 수 있습니까?
단일 개발 플랫폼이 모든 계층을 다루지는 않습니다. Apidog는 API 설계, 문서화, 테스트, 협업, 작업 공간 ID, 자격 증명 제어 및 Git 워크플로를 지원할 수 있습니다. 런타임 트래픽, 프로덕션 권한 부여, 위협 방지, SIEM, 관찰 가능성, 인프라 및 조직적 위험 수용에는 적절하게 연결된 시스템 및 소유자가 필요합니다.
프레임워크를 실행 가능하게 만드십시오
가장 좋은 API 거버넌스 프레임워크는 가장 많은 정책을 가진 것이 아닙니다. 팀이 적용할 수 있고, 검토자가 설명할 수 있으며, 위험 소유자가 방어할 수 있고, 조직이 증거를 가지고 개선할 수 있는 프레임워크입니다.
실제 API 포트폴리오, 작은 제어 기준선, 책임 있는 역할 및 정직한 예외 처리 과정으로 시작하십시오. 그런 다음 제어 매트릭스 템플릿을 사용하여 각 요구 사항을 열망에서 워크플로로 이동시키십시오.
조직이 설계, 문서화, 테스트, 협업 및 엔터프라이즈 작업 공간 제어를 통합하기를 원한다면, 완성된 매트릭스를 기준으로 Apidog Enterprise를 탐색해 보십시오.