블로그

재앙을 위한 조리법: API 우선, 보안 지속 전략

로리 맥비티 썸네일
로리 맥비티
2019년 4월 22일 게시

API에 대한 수요가 증가하고 있습니다. 모바일 앱을 활성화하여 디지털 경제를 활성화하는 데 도움이 되든, 자동화와 오케스트레이션 이니셔티브를 통해 내부적으로 생산성을 높이는 데 도움이 되든, API는 어디에나 있습니다.

많은 조직이 "API 우선!"이라는 디지털 구호를 채택했습니다. 즉, Cloud Elements의 2018년 API 통합 현황 에 응답한 사람 중 대부분(60%)이 모든 개발자에게 API를 제공한다고 답했습니다. 효과가 있네요. 놀랍게도 조직의 85%가 API 및 API 관련 구현을 통해 최소한 어느 정도의 수익을 창출하고 있습니다. 대부분(59%)은 조직 수익의 11~50%를 창출합니다. 10명 중 1명 이상(11%)이 API에서만 수익의 절반 이상을 창출합니다. ( MuleSoft의 API 가치 상승 )

하지만 그들이 API를 모든 개발자에게 공개한다는 점을 상기시켜드립니다. 선의의 개발자가 아니라, 모든 개발자가 그렇습니다.

오늘날 API 경제의 개방적 특성은 API 우선 전략이 보안 마지막 전략과 함께 이루어지는 경우가 너무 많은 안타까운 이유 중 하나입니다.

유명 조직이 관련된 API 관련 보안 사고의 실체는 비교적 쉽게 찾을 수 있습니다. Forbes에서 언급했든 F5 연구소에서 직접 발견했든 이러한 조직은 잘 알려진 보안 관행과 툴을 사용했다면 예방할 수 있었던 API 관련 보안 침해를 겪었습니다.

F5 Labs의 수석 위협 연구 전문가인 Ray Pompon은 API 보안에 대한 그의 연구에서 다음과 같이 언급했습니다.

"... 애플리케이션 보안에서 항상 발생했던 동일한 고전적인 문제와 관련된 패턴을 볼 수 있습니다. 즉, 공격자가 무차별 대입 공격이나 도용한 자격 증명을 통해 액세스하는 것입니다. 게다가 API에 인증되면 공격자는 지나치게 광범위하게 할당된 권한을 악용했습니다."

출처 < https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents >

동일한 고전적인 문제입니다. 결국 API는 대부분 JSON이나 XML 데이터의 페이로드를 전달하는 HTTP로 전송되는 URI로 구현되기 때문입니다. 이는 POST된 양식 데이터의 페이로드를 전달하는 HTTP로 전송된 URI와 크게 다르지 않습니다.

그리고 API는 단지 코드에 대한 인터페이스 라는 사실을 잊지 마세요. WhiteHat 애플리케이션 보안 통계 에 따르면 10만 줄의 코드(LOC)당 평균 39개의 취약점이 있는 코드입니다. 잠깐, 그건 전통적인 앱에 대한 이야기입니다. 마이크로서비스 아키텍처를 사용하여 인터페이스 (API)를 구현하면 100K LOC당 180은 어떨까요? 어느 쪽이든 취약점이 꽤 많죠.

API는 웹 앱과 동일한 취약점을 가지고 있습니다. 즉, 웹 애플리케이션과 동일한 보안에 대한 주의가 필요합니다.

하지만 API 보안에 두는 중요성은 오늘날 웹 애플리케이션의 중요성과 동일하지 않습니다. 적어도 보안 테스트에 대한 열악한 접근 방식을 폭로하는 실존적 증거에 근거하면 그렇습니다. SmartBear가 실시한 비공식 여론 조사에 따르면 오늘 응답자의 12%만이 "광범위한" API 보안 테스트를 실시한 것으로 나타났습니다. 거의 두 배인 23%는 API 보안 테스트를 전혀 실시하지 않았습니다. 이는 SmartBear가 실시한 보다 공식적인 조사 결과 와 일치하며, 응답자의 80%가 API를 테스트한다고 밝혔습니다.

그래도 그렇지 않은 사람이 20%는 남습니다.

API 우선 방식은 디지털 경제에 참여하고 기업과 운영을 효율적이고 강력한 디지털 머신으로 전환하는 좋은 방법입니다. 하지만 보안을 마지막에 두는 것은 트위터에서 보안을 트렌드에 맞춰 비판적인 해시태그로 만드는 좋은 방법입니다.* 그리고 아무도 그런 걸 원하지 않아요.

따라서 API를 중심으로 접근하려면(그래야 하겠지만) 최우선순위로 보안을 갖춰야 합니다. API에 대해 보안 마지막 전략을 적용하지 마세요.

시작하는 데 도움이 되는 간단한 단계:

  1. 있다면 테스트해 보세요.
  2. 사용자의 의견이 있다면 그것을 믿지 마세요.
  3. 사용자 로그인이 있는 경우, 무차별 대입 공격과 자격 증명 채우기 공격으로부터 보호하세요.
  4. API가 기반을 둔 시스템과 서비스를 유지 관리하고 패치를 적용해야 한다는 사실을 염두에 두세요. 그들의 취약점은 귀하의 API의 취약점입니다.

안전하게 지내세요.