서버레스 애플리케이션 및 API, 20%가 취약한 채 유통된다

2018-04-09 15:15
  • 카카오톡
  • 네이버 블로그
  • url
서버 없는 아키텍처에서 보안 책임 문제 아직도 분명치 않아
인적 요소가 취약점 유발...닷넷 런타임 언어는 유달리 취약점 많아


[보안뉴스 문가용 기자] 오픈소스 서버레스 애플리케이션들의 20%에서 치명적인 보안 취약점들이 발견됐다. 이는 1000개의 오픈소스 서버레스 프로젝트들을 분석한 보안 업체 퓨어섹(PureSec)이 발표한 내용이다.


[이미지 = iclickart]

퓨어섹이 발견한 건 공격자들이 애플리케이션을 마음대로 주무를 수 있게 해주는 치명적인 취약점이나 환경설정 오류였다고 한다. 그 중 6%는 심지어 API 키나 크리덴셜을 공개된 코드 레포지토리에 포스팅 해두기도 했다.

퓨어섹에 의하면 대부분 취약점들은 ‘시큐어 코딩’이 아직 정착하지 않아서 생기는 것들이라고 한다. 즉 개발자들의 보안 관련 인식이 아직 높지 않기 때문에 이러한 현상이 발생한다는 것이다. 특히 서버레스 기술과 관련된 보안의 경우 교육은 제대로 진행되지 않고 있는데, 쉬운 ‘복사해서 붙여넣기’ 관행은 빠르게 퍼지고 있어 문제는 계속해서 악화되고 있는 중이다.

서버레스 애플리케이션 취약점의 근본 이유 1
퓨어섹의 CTO인 오리 세갈(Ory Segal)은 “이번 연구 결과가 놀랍지는 않다”며 “애플리케이션 개발에 있어 보안이 완벽히 구현된 예는 찾기 힘들었다”고 말한다. “서버레스 아키텍처를 가진 애플리케이션은 ‘새로운’ 개념으로, 기존 애플리케이션 보안의 방법을 가지고는 이러한 새로운 애플리케이션들을 보호하기가 쉽지 않습니다.”

서버레스 애플리케이션 취약점의 근본 이유 2
서버레스 인프라, 즉 서버가 없는 인프라에서의 보안 및 안전 책임은 현재 누구에게 있을까? 즉 물리 보안, 네트워크 보안, 운영 시스템의 패치 등은 누가 해야 하는 걸까? 서버레스 인프라 제공업자에게 있는 것이 일반적이다. 애플리케이션의 소유주/개발자는 애플리케이션 자체의 로직, 코드, 데이터, 애플리케이션 층위의 환경설정에만 책임이 있다. 하지만 사고에 따라 이 둘을 명확하게 구분하기가 쉬운 게 아니라 보안 사고가 날 때 책임질 자를 결정하는 데에 혼선이 빚어질 수밖에 없다.

서버레스 애플리케이션 취약점의 근본 이유 3
또한 취약점이 발견되는 비율은 런타임 언어별로도 비슷했다. 즉 특정 런타임 언어에 따라 오류가 더 많이 나타나는 건 아니라는 것이다. 그렇다면 취약점이 발생하는 가장 큰 요인은 ‘인간적인 요소’가 된다. 다만 닷넷(DotNet) 런타임의 경우는 예외라고 퓨어섹은 강조한다. “닷넷의 경우는 취약점이 예외적으로 많이 발견됐습니다.”

서버레스 애플리케이션 취약점의 근본 이유 4
보안 업체 블랙덕의 기술 에반젤리스트인 팀 맥키(Tim Mackey)는 보안 전문 외신인 인포시큐리티(Info-Security)를 통해 “서버레스 아키텍처의 핵심 기능은 소비용 API를 구분하는 것”이라고 말한다. “API는 더 큰 애플리케이션에 통합될 목적으로 사용자에게 제공되는 기본 단위의 서비스입니다. 이런 API들을 용도에 따라 구분하는 것이 보안의 첫 단계여야 합니다.”

그는 그 말을 이렇게 풀어 설명한다. “예를 들면 보통의 사용자 애플리케이션의 경우, 사용자가 엉뚱한 값을 입력하지 못하도록 하는 장치를 가지고 있습니다. 즉 입력 값을 특정한 기준을 가지고 한 번 거른다는 건데, 이렇게 걸러진 데이터는 자유롭게 애플리케이션이 처리해 그 값을 최종 사용자에게 돌려줍니다. 내부에서의 이러한 데이터 처리 과정을 쪼개 API 서비스로 전환하는 것도 가능한데, 이러한 API를 리팩토링(refactoring) 하는 과정 중에 입력값을 최초로 거르게 하는 기준이나 규칙은 무시되는 것이 보통입니다.”

이런 일이 발생하면 “엉뚱한 데이터가 서버레스 애플리케이션 및 아키텍처에 유입된다.” 그러면 당연히 예상치 못한 결과가 나온다. 그런데 이 API가 많은 사람들에게 사용되기 시작하면 예상치 못한 결과가 나온다는 리스크가 같이 퍼지기 시작한다.

또한 이러한 리스크는 어떤 API에도 존재할 가능성이 있다고 한다. 서버레스이든 아니든 말이다. 그러므로 API를 사용하고자 하는 개발자들은 ‘취약점이 존재한다’고 가정하고 해당 API를 검사한 후에 활용해야 한다고 팀 맥키는 권장한다.
[국제부 문가용 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>

헤드라인 뉴스

TOP 뉴스

이전 스크랩하기


과월호 eBook List 정기구독 신청하기

    • 다후아테크놀로지코리아

    • 인콘

    • 엔텍디바이스코리아

    • 이노뎁

    • 다후아테크놀로지코리아

    • 아이디스

    • 씨프로

    • 웹게이트

    • 씨게이트

    • 하이크비전

    • 한화비전

    • ZKTeco

    • 비엔에스테크

    • 비엔비상사

    • 원우이엔지

    • 지인테크

    • 지오멕스소프트

    • 이화트론

    • 다누시스

    • 테크스피어

    • 렉스젠

    • 슈프리마

    • 인텔리빅스

    • 시큐인포

    • 미래정보기술(주)

    • 동양유니텍

    • 비전정보통신

    • 경인씨엔에스

    • 트루엔

    • 성현시스템

    • 한결피아이에프

    • 프로브디지털

    • 디비시스

    • 세연테크

    • 스피어AX

    • 투윈스컴

    • 위트콘

    • 유에치디프로

    • 구네보코리아주식회사

    • 주식회사 에스카

    • 넥스트림

    • 포엠아이텍

    • 세렉스

    • 탈레스

    • 에스지에이솔루션즈

    • 로그프레소

    • 윈스

    • 포티넷코리아

    • 신우테크
      팬틸드 / 하우징

    • 에프에스네트워크

    • 유투에스알

    • 케이제이테크

    • 알에프코리아

    • 창성에이스산업

    • 아이엔아이

    • 미래시그널

    • 새눈

    • 에스에스티랩

    • 현대틸스
      팬틸트 / 카메라

    • 이스트컨트롤

    • 네티마시스템

    • 태정이엔지

    • (주)일산정밀

    • 넥스텝

    • 한국씨텍

    • 두레옵트로닉스

    • 에이티앤넷

    • 지에스티엔지니어링
      게이트 / 스피드게이트

    • 에이앤티글로벌

    • 포커스에이치앤에스

    • 신화시스템

    • 휴젠

    • 메트로게이트
      시큐리티 게이트

    • 글로넥스

    • 엘림광통신

    • 세환엠에스(주)

    • 유진시스템코리아

    • 카티스

    • 유니온커뮤니티

Copyright thebn Co., Ltd. All Rights Reserved.

MENU

회원가입

Passwordless 설정

PC버전

닫기