(2-1)‘API 보안’의 ABC-“‘API 게시’때 위험”

[애플경제 이윤순 기자] API(Application Programming Interface)는 소프트웨어 간의 상호작용과 호환을 통해 애플리케이션을 편리하게 다양한 플랫폼에서 사용할 수 있게 한다. 현대 IT생활과 기업활동의 기본적 도구를 제공하는 셈이다. 그러나 이는 또한 보안상의 취약점도 많아서 이에 대한 다양한 대책이 필요한 실정이다.

우선 API는 민감한 데이터가 훼손당하거나 유출, 탈취되는 등 보안 취약성이 자주 노출되곤 한다. 이에 특히 API를 배포, 게시할 때나, 다른 시스템과 통합하기 위해 API를 사용할 경우에 많이 발생한다.

API 게시할 때 특히 ‘취약점’ 노출

API를 게시할 경우 특히 인증이 잘못되거나, 취약한 인증방법을 사용할 때 문제가 된다. API는 사내에서도 엄격한 인증 메커니즘을 사용, 이를 요청하는 사용자의 신원이 확실하고, 정확하게 인증시스템에 연결되어 있는지 확인해야 한다. 그러나 흔히 API 개발 중에 코더(coder)는 최신의 강력한 인증을 구현하지 못하는 경우가 있다. 그 결과 API 백엔드는 악의적인 해커가 쉽게 손상시키거나 우회할 수 있고, 쉽게 깨뜨릴 수 있는 취약한 인증만 있는 경우가 적지 않다.

API가 API 호출의 다른 쪽 끝에 있는 사용자의 신원을 올바르게 확인하지 못할 때 문제가 생긴다. 애초 신원이 불확실한 사람에 의해 의도하지 않은 작업이 이뤄지고, 민감한 정보가 공유되는 등 위험이 발생한다.

이를 방지하기 위해 코더는 우선 강력한 인증 모듈을 표준화하고, 개발 주기 동안 비표준 인증이 있는 모든 코드를 거부한 상황에서 테스트를 진행해야 한다. 이를 위해 사이버 보안 팀은 API에 대한 침투를 탐지하기 위한 테스트를 통해 부적절한 인증을 찾아야 한다.

그러나 보안전문가들은 “API 요청이 어디에서 오는지부터 알아낸다고 해서 안심하면 안 된다”며 “요청자의 신원을 기반으로 백엔드 시스템과 데이터에 대한 액세스를 안전하게 제어하는 ​​것이 중요하다”고 강조한다.

‘잘못된 권한 부여’도 문제

국내 사이버보안 전문업체인 P사 관계자는 “액세스 권한이 특정인에게 집중되어 있는 또한 부적절하고, 권한 남용”이라고 지적했다.

그는 “부적절한 API 액세스는 무단 액세스를 방지할 수는 있어도, 합법적인 파트너나 고객들이 필요한 데이터와 서비스를 검색할 권한이 주어지지 않는게 문제”라며 “스펙트럼의 다른 쪽 끝에서 지나치게 광범위한 액세스 제어는 사용자가 필요 이상의 것을 보거나, 수행할 수 있도록 한다”고 지적했다.

또한 그런 경우 “악의적인 행위자가 개인 정보와 시스템에 액세스할 수 있도록 허용할 수도 있다”는 것이다.

이를 해소하기 위해선 가능한 한 자동화된 전체 사용자를 대상으로 한 검증을 할 때 실제 액세스 시나리오와 똑같은 상황을 적용해야 한다.

즉 “적절하게 인증된 요청을 통해 모든 필요한 데이터에 액세스할 수 있는지를 평가하는 것이 애초 목표”라는 얘기다. 그래서 이를 제어하는 ​​개체나 데이터 저장소에서, 해당 보안 테스트에 대한 권한이 없는 데이터를 검색하거나, 작업을 해보라는 요청도 포함해야 한다. 이를 통해 검색과 작업 수행의 실패를 유도하는 것이다.

또 전체 인증 정책을 검토, 검증할 때 반드시 API 인증을 포함해야 한다는게 전문가들의 조언이다. 침투 가능성을 없애기 위해 관련 보안 정책을 잘 준수하고 있는지를 정기적을 점검해야 한다.

API는 네트워크에 연결된 기능이다. 그러므로 가짜 트래픽으로 API를 유린하도록 설계된 DoS나 DDoS 공격을 받을 수 있다. API가 필요한 기능을 제공하는 경우 성능이 저하되거나 가용성이 부족하면 전체 업무나 공정에 심각한 결과가 초래될 수 있다.

DoS 또는 DDoS 공격이 가해지면, API가 적시에 합법적인 요청을 처리할 수 없게된다. 또는 잘못된 요청으로 인해 API가 리소스를 해제하지 않고 소모되거나 고갈될 수 있다. 심지어는 API 프로세스가 서로 충돌하는 지점까지 밀려날 수 있다.

이를 방지하기 위해선 요청이 백엔드 시스템에 도달하기 전에 대기열에 넣고 제어해야 한다. DDoS 방어와 함께 더 엄격한 코딩을 구현, ‘요청 중단’이 될 경우를 막아야 한다.

치명적 위험…‘서버 측 요청 위조’

가장 큰 API 위험 중 하나는 서버 측 요청을 위조하는 것이다. 즉, API 서비스가 악의적인 행위자의 복제품으로 탈바꿈되어, 측면 침해나 다른 사람에 대한 공격의 공범이 될 위험을 초래한다.

이를 통해 악의적인 행위자는 API 서비스가 인프라 내부의 다른 시스템이나, 타사 리소스 또는 사이트에 도달하기 위해 애쓴다. 예를 들어, 링크드인(LinkedIn) 페이지에 대한 URL을 제공받을 것으로 기대하는 API 호출은, 엉뚱하게 API 서비스의 자체 호스트에서 TCP 포트를 열기 위한 요청을 받을 수도 있다. 이에 API를 통해 신중하게 구성된 요청을 제출할 필요가 있다.

특히 “URL이 가리킬 수 있는 위치를 제어하려면 ‘허용 목록’을 사용해야 한다”는 주문이다. 또한 API 환경에서 제로 트러스트를 구현, 서로 상호작용해서는 안 될 시스템에 접근하는 것을 방지해야 한다. 그렇지 않고 API 입력에 대한 검토가 불충분할 경우 큰 위험을 초래한다는 지적이다.

API를 관리할 때 무심코 사용자 입력을 수락하고, 코드나 외부 데이터베이스의 데이터 구조를 먼저 검토하지 않고 저장할 수 있다. 사실 이런 경우는 흔히 있다. 웹 앱과 마찬가지로 이는 SQL 주입 공격, 버퍼 오버플로 공격 등에 노출되는 전형적인 사례다.

API는 거짓 데이터나, 전혀 엉뚱한 데이터가 자칫 ‘유효’한 것으로 처리될 위험도 있다. 이런 경우 API 관리 시스템 자체가 공격의 플랫포이 될 수도 있다는 지적이다.

이를 방지하기 위해선 요청이 있을 때 결코 선뜻 수락해선 안된다. 수락에 앞서 철저히 입력 사항의 구문을 분석하고 검증할 필요가 있다는 지적이다.