API 인벤토리 대시보드 구축
2026년 10월 30일 공유
API 보안 플랫폼 개발 현황과 BOLA 탐지 개선
개요
- 유형: 회의
- AP-EYE의 API 수집·인벤토리·분석 기능 구현 현황과 BOLA 탐지 개선 실험을 검토했다.
- 주요 대상은 보안 인력이 부족하고 데이터 외부 반출에 제약이 있는 조직이다.
- 연구 범위는 로그인 사용자 간 읽기 BOLA로 좁혔다. 주간 정리에서는 미탐 감소를 우선 목표로 제시했으며, 회의에서는 오탐과 담당자의 확인 작업량 감소도 강조했다.
- 트래픽 이상 징후 탐지와 실제 BOLA 판정은 구분한다.
참여자 및 역할
- 지도·검토 담당자: 평가 근거, 분석 구조, 화면 개선 및 배포 방향 검토.
- 개발팀 4명: API 수집·인벤토리, 운영 화면, 규칙 분석기, BOLA 검사 및 비교 실험 수행.
- 녹취만으로 개인별 담당 범위를 정확히 확정하기는 어렵다.
결정 사항
연구·평가 원칙
- BOLA 판정은 단순한 응답 유사도가 아니라 요청자 신원, 객체 소유자, 공개 여부를 확인해야 한다.
- Akto와 ARTEX의 결합 효과는 아직 입증되지 않았다. 로컬 LLM의 속도가 느리다는 이유만으로 Akto 선행 구조를 정당화하지 않는다.
- 비로그인 사례가 포함된 기존 실험 결과를 로그인 사용자 간 읽기 BOLA 성능으로 그대로 사용하지 않는다.
- 개선 주장은 기준 데이터, 실행 조건, 판정 근거와 함께 제시한다.
구현·운영 방향
- OpenAPI·Swagger 명세는 JSON·YAML로 받아 PostgreSQL에 저장한다.
- 기업별 API 차이에 대응하도록 분석 규칙을 설정 가능하게 한다. 현재 JSON 설정을 사용하며, 향후 화면에서 편집하도록 확장한다.
- 모델은 사용자 환경에 따라 로컬 또는 외부 API를 선택할 수 있는 유연한 구성을 지향한다.
- 팀원 모두 구현에 집중하고, GitHub로 공유·통합하면서 개선한다.
실행 항목
- 개발팀
- 구현 파트를 나눠 핵심 기능을 연결하고 통합 동작을 검증한다.
- 실험 조건·결과·스크린샷을 GitHub에 정리한다.
- 탐지·실험 담당
- 머신러닝과 디시전 모델의 적용 가능성을 비교한다.
- 사용 가능한 API 크레딧 등으로 모델을 시험하고 결과를 정리한다.
- 다중 계정·소유권 확인을 포함한 검사 개선 효과를 평가한다.
- 화면 담당
- 인벤토리를 한눈에 보는 테이블 중심으로 개편한다.
- 행별 조작 버튼과 Swagger의 엔드포인트 설명을 표시한다.
- 섀도 API·좀비 API 탐지 영역을 마련한다.
- 배포·연동 담당
- 외부에서 접속 가능한 시연 환경을 배포한다.
- DNS 변경으로 게이트웨이에 연결하는 방식을 검토·구현한다.
논의 사항
1. 구현 현황
- 명세와 게이트웨이 트래픽을 통합해 API 인벤토리를 구성했다.
- 명세에만 존재 / 트래픽에만 존재 / 양쪽에 존재하는 API를 구분한다.
- 객체 번호만 다른 경로를 같은 API로 묶고, 출처·관측 구간과 변경 이력을 관리한다.
- 담당자·중요도·민감 데이터 종류를 입력할 수 있다.
- 운영 화면에 로그인·역할별 권한, 명세·로그 입력, 규칙 적용, 승인 후 읽기 검사, 결과·근거 조회를 연결했다.
- 검사 주소와 계정을 코드에 고정하던 방식에서 설정 입력 방식으로 변경했다. 실제 Memos 앱에 요청을 보내 계정별 결과를 비교한다.
- ES3 앞에 게이트웨이를 두어 실제 API 요청과 시간별·API별 트래픽 그래프를 연결했다.
- 로그인과 요청 수집은 확인했다.
- 운영 트래픽이나 ES3의 BOLA 탐지 성능을 검증한 것은 아니다.
- 연결 로그에는 비밀번호·인증값 원문·쿼리·요청 및 응답 본문을 남기지 않는다.
- 회의 시점에는 이벤트 수집·화면과 실제 분석·검사 기능의 통합이 아직 진행 중이었다.
2. Akto·ARTEX 비교 결과
주간 정리의 Akto 개선 실험 66건에서는 미탐이 14건에서 8건으로 줄었고, 오탐은 10건으로 유지됐다.
별도 Memos 36건 실험은 BOLA 8건과 정상 28건으로 구성됐다.
구성 | BOLA 탐지 | 정상 사례 오탐 |
|---|---|---|
Akto 단독 | 0/8 | 6/28 |
ARTEX 단독 | 5/8 | 4/28 |
ARTEX가 Akto를 도구로 호출 | 4/8 | 6/28 |
- ARTEX는 마지막 판정 줄을 기준으로 집계했다.
- 같은 프롬프트로 재실행해도 36건 중 23건의 판정이 달라졌다. 도구 목록도 달라 완전히 동일한 반복 조건은 아니었다.
- Akto는 BOLA 8건 모두를 검사 대상에서 제외했다. 결합 구성의 탐지 4건은 ARTEX의 직접 요청으로 확인되어 Akto 연결의 기여로 보기 어렵다.
- 후속으로 소유자 확인 도구를 추가한 구성, 별도 판정 규칙을 적용한 구성, wger 두 계정 대조를 시험했다.
- Memos의 미탐 8건 중 로그인 사례는 4건, 비로그인 사례는 4건이다.
3. BOLA 탐지의 핵심과 Akto 한계
BOLA 검사는 다음 요소를 갖춰야 한다.
- 식별자 발견: 경로·쿼리·본문에서 객체 식별자를 찾는다.
- 인증 처리: 헤더·쿠키·커스텀 토큰을 적절히 교체한다.
- 요청자 식별: 계정·토큰과 사용자 신원을 연결한다.
- 권한 판정: 요청자와 객체 소유자, 공개 여부를 비교한다.
실측에서 Akto는 식별자 선정과 응답 비교에 한계가 있었다.
사례 | 주요 문제 | 결과 |
|---|---|---|
wger 목록 미탐 6건 | 식별자 선정 | YAML 한 줄 수정으로 해결 |
wger 단건 오탐 4건 | 자기조회·소유권 구분 | 외부 검증 또는 엔진 개선 필요 |
Memos 목록 미탐 8건 | 검사 대상 선정 실패 | YAML 수정으로 해결되지 않음 |
Memos 단건 오탐 6건 | 자기조회·소유권 구분 | 외부 검증 또는 엔진 개선 필요 |
- 개선의 중심은 식별자 자동 발견과 다중 신원 차등 검사다.
- “A의 객체를 B로 요청했을 때 읽히는가”를 확인하되, 공개 데이터나 정상 공유 권한은 제외해야 한다.
- 판정은 정상·보류·BOLA로 구분한다.
4. 이상 징후 분석과 모델 구성
- 머신러닝은 식별자 인식에 도움이 될 수 있지만, API 명세 변화에 따른 재학습과 품질 유지 부담이 있다.
- 대안으로 다음 2단계 구조가 제안됐다.
- 디시전 모델로 명확한 정상 요청을 빠르게 제외한다.
- 남은 의심 요청만 LLM으로 정밀 분석하고 담당자가 검토한다.
- 실시간 차단보다 탐지·모니터링을 우선한다.
- 이 구조는 제안 단계이며, 모델 선택과 성능 비교가 필요하다.
5. JSON 규칙 분석기 운영 요점
rules.json변경은 다음 평가부터 적용하며, 진행 중인 평가는 기존 설정의 스냅샷을 사용한다.
- 기본 집계 단위는 사용자·API별 300초 구간이다.
- 주요 지표는 요청 수, 서로 다른 객체 수·비율, 요청 간격 중앙값, 403·404 비율이다.
- 이전 정상 구간에서 계산한 분위수 경계로 평가한다.
기본 규칙 | 조건 | 용도 |
|---|---|---|
many_objects | 객체 수와 객체 비율이 정상 95백분위 초과 | 주 알림 |
burst | 요청 수가 95백분위 초과, 요청 간격이 5백분위 미만 | 보조 신호 |
denials | 객체 수와 403·404 비율이 95백분위 초과 | 보조 신호 |
- 사용자 정의 집계·계산식·경계를 추가할 수 있다. 단순 조건은
all, 복합 논리는when을 사용한다.
- 입력에는 시간, API, 가명 사용자, HTTP 상태, 객체 식별자를 사용하며 쿠키·토큰·응답 전문은 포함하지 않는다.
- 사용자 식별자가 없으면 전체 사용자를 임의로 합치지 않고 오류로 처리한다.
- 정상 기준 부족, 필수 지표 부족, 주 알림 비활성 상태는 정상 판정과 구분한다.
- 404 증가 등의 신호는 조사 대상일 뿐, 그 자체로 BOLA나 권한 위반을 확정하지 않는다.