서버 없는 아키텍처에서 보안 책임 문제 아직도 분명치 않아
인적 요소가 취약점 유발...닷넷 런타임 언어는 유달리 취약점 많아
[보안뉴스 문가용 기자] 오픈소스 서버레스 애플리케이션들의 20%에서 치명적인 보안 취약점들이 발견됐다. 이는 1000개의 오픈소스 서버레스 프로젝트들을 분석한 보안 업체 퓨어섹(PureSec)이 발표한 내용이다.
퓨어섹이 발견한 건 공격자들이 애플리케이션을 마음대로 주무를 수 있게 해주는 치명적인 취약점이나 환경설정 오류였다고 한다. 그 중 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)]
인적 요소가 취약점 유발...닷넷 런타임 언어는 유달리 취약점 많아
[보안뉴스 문가용 기자] 오픈소스 서버레스 애플리케이션들의 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) 무단전재-재배포금지>
문가용기자 기사보기
[2024-12-28] 
