데이터 공유, 외부 API 지나친 의존, 문서화 안된 경우 등
‘손상된 개체 수준 권한’ 등 OWASP ‘10대 API 위험요소’ 주목
[애플경제 이윤순 기자] API보안을 해치는 또 다른 요소는 데이터를 과도하게 공유하는 관행이다. API는 때로 기업들이 사내 데이터 보안 정책에서 명시한 것보다 더 많은 데이터를 노출하곤 한다. 이로 인해 개인 식별 정보나, 보호해야 할 정보가 부적절하게 공개될 수도 있다.
“데이터 세트의 추출물에 대해 API를 빌드하고 테스트하는 과정에서 좀더 광범위한 데이터 세트에 코드를 풀어놓음으로써 과도한 데이터 노출이 발생한다”는 지적이다. 또한 인증 문제로 인해 이같은 사태가 발생할 수도 있다.
API 검증 과정서 ‘레코드’ 제한 필요
이를 방지하기 위해선 API 검증 과정에서 ‘레코드’ 수를 제한할 필요가 있다. 대신에 유형이나 필드는 제한하지 않는 데이터 세트를 테스트하는게 바람직하다는 평가다. 데이터 손실 방지 시스템을 통해 공개되어서는 안 되는 데이터를 모니터링하고, 경고하거나 차단하거나 적극적으로 삭제해야 한다는게 전문가들의 조언이다.
API 종속성도 문제다. 즉, 내부 프로세스가 외부와 통합하는 과정에서 역시 동일한 API 서비스에 의존하는 경우가 그렇다. 즉 기업의 비즈니스 프로세스가 API 사용자의 간섭이나 훼손 행위에 노출되고 만다. 이같은 API 중심의 DoS 공격은 외부에 있는 프로세스뿐만 아니라, 내부 프로세스를 마비시키고 조직의 비즈니스 수행 능력을 심각하게 방해할 수 있다.
이를 예방하기 위해 외부에 있는 API에 대한 공격이 내부 API에 직접 영향을 미치지 않도록 하는게 중요하다. 즉, 내부에 있는 API 서비스와 외부에 있는 API 서비스를 분리하는 것도 유효한 방법 중 하나다.
이 밖에도 API를 게시하는 경우 초래되는 위험 요인은 많다. 예를 들어 API 기반 서비스의 버전에 대한 관리와 제어가 부족할 경우, 인증, 권한 부여, 입력 스캐닝이 일치하지 않게 된다. 또한 API 활동 로깅이 누락되거나, 로그 모니터링이 없어질 수도 있다.
안전하지 않은 방식의 데이터 사용 ‘금물’
API보안 위험은 게시할 경우에만 국한되지 않는다. 이 밖에도 API 사용과 관련된 위험 요인들이 많다.
우선 데이터를 안전하지 않은 방법으로 사용하는 경우다. 즉, API를 사용해 다른 시스템에서 데이터를 검색하는 경우다. 이런 경우 해당 시스템의 데이터가 잘못되었거나 심지어 악의적일 경우 보안에 구멍이 뚫릴 수도 있다. 이로 인해 회사 차원에서 잘못된 결정을 내리고, 잘못된 조치를 취하거나, 사실이 아닌 허위 정보를 규제 기관, 고객 또는 파트너에게 보고할 수도 있다.
이를 방지하기 위해선 입력을 반드시 검증해야 한다. 입력 검증은 무엇보다 API 보안에 중요하다. 즉 “입력되는 데이터의 출처를 추적하고, 문제를 적절하게 파악하며 사전에 조사할 수 있기 때문”이란 얘기다.
문서화되지 않은 외부 API 사용도 위험
기업은 또 외부, 특히 공급업체로부터 초래되는 보안 위협 요인에 각별히 유의해야 한다는 지적이다. 최근엔 특히 공급업체에서 비롯된 보안 위험 요소가 크게 증가하고 있는 현실이다.
외부 다른 기업 등의 API를 사용하는 경우가 날로 늘어나고 있다. 자체가 아닌 다른 API를 계속 사용하다보면 필연적으로 문제가 생길 수 밖에 없다. 국내 보안업체 I사 관계자는 “이런 경우 API 요청에 대한 응답을 제공하는 과정에 얼마나 많은 다른 위험 요소들이 관련되어 있는지 알기 어려운 경우가 많다”면서 “이로 인해 광범위한 공격 표면이 발생할 수 있다”고 경고했다.
이를 방지하기 위해선 “타사 혹은 외부의 다른 API의 수를 제한할 필요가 있다”는 주문이다. 즉, API 생태계를 제어할 수 있어야 한다. 필요한 경우 외부 혹은 타사로부터 초래되는 보안 위험을 파악하고 제한하기 위해 다른 API 공급자와도 계약, 협의하는게 필요하다.
“모든 비즈니스 프로세스, 문서화 필요”
비즈니스 프로세스가 API에 의존하지만, 만약 문서화되지 않은 경우 프로세스가 쉽게 중단될 우려가 크다. 즉, API 사용 방법을 변경해야 한다는 사실을 무시한 채, 비즈니스 프로세스 자체가 변경될 수도 있다는 지적이다. 앞서 I사 관계자는 “그런 경우 결국 프로세스가 제대로 작동하지 않는 결과가 발생할 수 있다.”면서 “API 작동 방식을 변경하면 당장은 문제가 드러나지 않아도, 결국 미묘한 오류나 변경이 발생할 수 밖에 없다”고 했다.
그런 이유로 “모든 비즈니스 프로세스를 철저히 문서화할 필요가 있다”는 지적이다. 즉, ‘제로 트러스트’ 아키텍처를 적용, 내부 시스템이 명시적 허가 없이 내부 또는 외부 API에 접근하는 것을 제한하는게 바람직하다는 얘기다.
“API에 내재된 위험은 또 API에만 국한되지 않는다”는 경고다. 즉 “주요 API 위험을 관리하고 조직의 네트워크가 안전하게 유지되도록 하려면, IT 및 사이버 보안 시스템에서 위험을 유발하는 문제 유형과 해당 위험을 해소할 수 있는 도구나 전략을 잘 알고 있어야 한다”는 지적이다.
그런 가운데 오픈소스 웹 앱 보안 프로젝트인 ‘OWASP’(The Open Worldwide Application Security Project)는 가 밝힌 상위 10개의 API 위험 요소를 각별히 유의해야 한다는 전문가들의 조언이다.
이는 ▲손상된 개체 수준 권한 부여, ▲손상된 인증, ▲손상된 개체 속성 수준 권한 부여, ▲제한 없는 리소스 소비, ▲ 손상된 기능 수준 권한 부여, ▲민감한 비즈니스 흐름에 대한 제한 없는 액세스, ▲서버 측 요청 위조, ▲ 보안 구성 오류, ▲부적절한 인벤토리 관리, ▲안전하지 않은 API 소비, ▲API 소비 위험 등이다.