섀도 API 관리: 목록에 없는 API를 발견한 다음 해야 할 일
문서에 없는데 누군가는 호출하고 있습니다
API 목록을 정리했는데 로그에는 처음 보는 주소가 남아 있습니다. 테스트용으로 만들었거나, 이전 버전을 남겨둔 경우일 수 있습니다. 목록 밖에서 운영되는 API를 찾았다면 무엇부터 해야 할까요?
F5는 9월 14일 공식 글에서 AI 연결 서비스가 늘어나는 환경의 가시성 문제를 다뤘습니다. 이때 점검할 것은 새로운 연결뿐만이 아닙니다. OWASP도 부실한 API 인벤토리 관리를 별도 위험으로 분류합니다. 오래된 버전과 관리되지 않는 접점이 남아 있는지 함께 봐야 합니다.
세 가지 목록을 나란히 놓아보세요
먼저 API 명세, 게이트웨이·배포 설정, 실제 호출 기록을 비교해 보세요. 문서에만 있는 API와 실제로 호출되지만 문서에 없는 API를 구분합니다. 주소뿐 아니라 메서드, 버전, 운영·테스트 환경도 함께 적으면 같은 기능처럼 보이는 접점의 차이가 드러납니다.
여기서 ‘호출이 관찰되지 않았다’와 ‘존재하지 않는다’를 구별해야 합니다. 월말 배치나 특정 제휴사만 사용하는 API는 짧은 관찰 기간에 잡히지 않을 수 있습니다. 어느 구간의 트래픽을 수집했는지도 남겨두세요.
발견 건마다 다음 행동을 붙이세요
목록에 새 줄을 추가하는 것으로 점검을 끝내지 마세요. 담당 부서, 사용 목적, 다루는 데이터, 외부 노출 여부를 확인한 뒤 유지·수정·폐기 중 하나를 정합니다. 담당자가 불명확하면 확인 책임자와 기한부터 지정하는 편이 좋습니다.
예를 들어 쓰지 않는 것으로 보이는 조회 API라도 바로 차단하기보다 호출 주체와 업무 주기를 먼저 확인하세요. 유지한다면 명세와 보안 정책을 맞추고, 폐기한다면 호출자 안내와 차단 뒤 확인 절차를 정합니다. 판단 근거를 기록해야 다음 점검에서 같은 질문을 반복하지 않습니다.
탐색 도구 다음에는 운영 절차가 필요합니다
Litis가 소개하는 Akamai API Security는 API 탐색과 인벤토리 확보를 지원합니다. 도입을 검토할 때는 어떤 네트워크 구간과 환경을 관찰할지, 발견 결과를 누가 처리할지 함께 정하세요. 제품이 API를 찾는 일과 조직이 사용 종료를 결정하는 일은 각각 책임이 필요합니다.
폐기 후에는 해당 주소가 실제로 닫혔는지, 예상하지 못한 호출 실패가 생기지 않았는지 확인합니다. 이번 주에는 API 총개수 옆에 ‘담당자 미확인’과 ‘조치 대기’ 항목도 적어보면 어떨까요? 목록이 다음 행동으로 이어질 때 관리가 시작됩니다.
