IT 뉴스

API 보안에 대한 5가지 미신

최고관리자 0 122

API 보안에 대한 5가지 미신

Terena Bell | CSO
최근 보안 분야는 데이터 유출 사건으로 바빴다. 지난 2일 크렙스 온 시큐리티(Krebs on Security)는 파네라 브레드(Panera Bread)가 3,700만 명의 고객 데이터 유출 사고를 8개월 동안 무시했다고 폭로했다.

이후 4일 밤에는 지난해 9월 고객 인터페이스 제공업체 [24]7.ai에서 발생한 침해 사건에 대한 보도가 나왔다. 정확한 피해 범위는 아직 밝혀지지 않았지만 기사 작성 시점을 기준으로 [24]7 고객인 델타 에어라인(Delta Airlines) 측은 "수십만 명의 고객이 침해에 노출됐을 가능성이 있다"고 밝혔으며 또 다른 고객사인 시어스 홀딩스(Sears Holdings)는 10만 개 미만의 신용카드 번호가 유출됐다고 밝혔다.

델타는 공식 성명서에서 [24]7.ai의 유출 원인이 프로그램의 악성코드라고 설명했으나 파네라는 인증되지 않은 API 엔드포인트를 원인으로 지목했다. 파네라가 침해를 인지한 시점은 2017년 8월 2일이지만 그동안 무시한 것으로 알려졌다.


Credit: Getty Images Bank

API 보안을 중시하거나 더 자세히 알아보고자 하는 사람을 위해 API 보안에 대한 5가지 미신을 정리했다. API 취약점의 실체는 무엇일까.

미신 1. API 보안은 기술이 아닌 기능이다
API 보안 관리 업체 포럼 시스템(Forum Systems)의 최고 기술 책임자인 제이슨 메이시는 "API 제품 시장에서 많은 업체가 API 보안 기능에 대해 이야기한다"며, "현실적으로 API 보안을 제공하는 기능이 있다는 주장은 방화벽 또는 안티바이러스 보안을 제공하는 기능이 있다는 주장과 같다"고 말했다.

메이시는 "보호의 주체는 기능이 아니라 제품"이라면서, "애플리케이션이 진정한 방화벽 또는 악성코드 보호를 제공한다고 하면 아무도 믿지 않을 것이다. 마찬가지다. API 관리 플랫폼이 진정한 API 보안을 제공한다고 기대하면 안 된다"고 주장했다.

<실무적 API 설계 접근(A Practical Approach to API Design)>의 공동 저자인 키스 케이시는 API 보안을 프로세스 사고 방식이라고 말했다. 인증 제공업체 옥타(Okta)에서 API 문제 해결사(solver of API problems, 이는 케이시의 실제 직책 이름이다)로 일하는 케이시는 API 관리의 5가지 축을 라이프사이클(lifecycle), 인터페이스(interface), 접속(access), 소비(consumption), 비즈니스(business)로 요약했다.

케이시는 "이 5개 축이 우리의 판단 기준이다. 좋은 API 관리 플랫폼은 5가지 측면과 때로는 그 외의 부분까지 모두 포괄한다"고 말했다. 보안 소프트웨어는 그 중에서 가운데 축인 접속만 다룬다.

케이시는 포럼 시스템의 제품과 같은 보안 전용 툴이 다른 모든 제품의 보완 요소가 될 수 있지만 그것이 곧 전체 라이프사이클 관리를 포괄하는 툴은 보호 기능을 제공하지 못한다는 의미는 아니라고 말했다.


Credit: Keith Casey

미신 2. 소프트웨어 기반 API 보안 솔루션은 안전하다
메이시는 "이것이 낭설이 아니라고 생각한다면 얼마나 많은 취약점이 드러나야 수긍하겠는가"라고 되물었다. 일리가 있다. 파네라에서 발생한 사건의 전모는 아직 다 밝혀지지 않았지만 메이시는 더 명확히 입증된 사례로 스펙터(Spectre)와 멜트다운(Meltdown), 셸쇼크(Shellshock), 하트블리드(Heartbeed)를 들었다.

메이시는 스펙터와 멜트다운은 "외부 코드가 사용자의 보안 시스템에서 실행되어 시스템을 감염시킬 수 있게 해준다. 그러나 보안 제품을 기반으로 하는 API 보안 솔루션은 운영체제를 잠궈 외부 코드 실행을 허용하지 않고, 따라서 취약점에 노출되지 않으며 지금까지 노출된 사례도 없다"고 말했다.

미신 3. API 보안은 간단하다
API의 개념 자체는 단순하다. 실제로 애플리케이션 프로그램 인터페이스는 그저 두 프로그램을 연결할 뿐이다. 그러나 API 보안은 다른 문제다. 메이시는 "API는 클라우드와 모바일 기술로 이어진 기술의 발전, 그리고 상호 연결된 시스템의 끊임없이 높아지는 복잡성을 대표한다"고 설명했다. 메이시는 "연결의 단순함이 복잡성을 유발한다"면서 "API를 건너오는 정보가 실제 위협 벡터가 드러나는 지점이다. API 보안 솔루션의 접근 방법이 단순할수록 기대할 수 있는 보안 수준은 낮아진다"고 말했다.

케이시는 메이시의 말이 일부 맞지만 그 이유에 대해서는 의견이 달랐다. 케이시는 "끊임없이 높아지는 복잡성만이 문제가 아니라 경계가 이동했다는 사실도 있다"고 말했다. 케이시는 "과거 보안이 편했던 시절 사용자는 물리적으로 네트워크에 존재하거나 방화벽 내에 존재해야 했다"고 설명했다. 기본적으로 데이터는 물리적 네트워크나 방화벽 내부로 제한됐다.

케이시는 "API가 한 일은 외부 사람이 내부 시스템과 데이터 또는 기능을 우리가 기술한 방식대로 사용할 수 있는 장소를 만든 것"이라고 말했다. "데이터를 공유하는 동시에 이 데이터를 보호하기란 기본적으로 어렵다. 게다가 대부분의 사람들은 방화벽 바깥이라는 부분에 대해 제대로 생각해본 적이 없다. 이제 우리는 새로운 취약점과 공격에 노출되고 있다"고 말했다.

미신 4. API 게이트웨이는 API 보안 게이트웨이와 동일한 보호 기능을 제공한다
마이크 쿡은 사이버보안 비영리 기관인 (ISC)²의 거버넌스, 위험 및 규정 준수(GRC) 전문가다. 쿡은 "API 보안 게이트웨이가 지금보다 더 많이 사용되어야 한다. API는 그냥 들어와 모든 데이터를 읽거나 사용자의 다른 애플리케이션에서 데이터를 읽을 수 있다"면서, "API 보안 게이트웨이가 없으면 API와 상대방을 어떻게 확인하고 그쪽으로 나가는 정보가 꼭 필요한 정보이며 접속이 허가된 정보인지 어떻게 확인하겠는가? 또는 API 건너편의 회사가 정말 그 회사인지 어떻게 확인하겠는가"라고 물었다.

메이시는 API 보안을 기본적인 API 게이트웨이에서 얻지 못하는 이유에 대해 "API 게이트웨이 제품 자체가 침해가 가능하다면 해당 제품이 자랑하는 각종 API 보안 기능에는 아무런 의미가 없다. API 게이트웨이는 사이버보안 기술이 아니라, 안전하지 않은 운영체제에서 소프트웨어 애플리케이션으로 실행되는 통합 플랫폼을 기반으로 한다"고 설명했다. 메이시는 "보안 게이트웨이는 명확히 보호를 목적으로 설계되므로 보안 정책 스토리지와 무결성 보장을 사용해서 제품 자체가 침해되지 않도록 한다"고 말했다.

미신 5. API ID는 API 보안과는 별개다
메이시는 이 미신이 "ID 및 접속 제어를 사이버보안과 별개의 영역으로 다루면서 비롯된 업계의 오랜 잘못된 관행에서 비롯됐다"고 말했다. 사이버보안 제품은 ID를 지원하도록 만들어지지 않고 API ID 제품은 보안을 실행하도록 만들어지지 않는다. 최선의 API 보안을 위해서는 ID 접속과 사이버보안의 연계가 필요하다. 메이시는 "API 보안은 동적이며 많은 조건을 기반으로 한다"며, "사용자와 사용자 행동은 의사 결정 및 실행의 핵심적인 측면이다"고 설명했다. editor@itworld.co.kr  



원문보기: 
http://www.itworld.co.kr/news/108890#csidxd2e16690c102052a15047783dcf0947 2891465455_x7AY3rZg_acde5a986fadaf9ae3b509769af661bf3cc8eaeb.gif 

0 Comments
제목
Category
글이 없습니다.
State
  • 현재 접속자 1 명
  • 오늘 방문자 4 명
  • 어제 방문자 10 명
  • 최대 방문자 168 명
  • 전체 방문자 13,541 명
  • 전체 게시물 70 개
  • 전체 댓글수 17 개
  • 전체 회원수 3 명