제목 : 서비스구조와 보안
고운플랫폼의 서비스구조와 보안
1. 서론
많은 기능과 화려한 사용자 인터페이스를 제공하는 웹 서비스라 할지라도, 그것이 보안에 취약하다면 아무런 쓸모가 없습니다. W3C의 웹 관련 기술 표준화에 따라, 웹 서비스는 더욱 다양한 기능이 출현하게 될 것이고, 개발자나 시스템 운영자의 고민은 더 늘어날 전망입니다.
본 문서는 고운플랫폼의 설계와 서비스구조을 보안(security)적인 측면에서 살펴보고, 외부의 공격(attack)이나 시스템의 오동작 등에서 발생할 수 있는 것과 그렇지 않은 것을 식별하여, 웹 서비스의 개발과 운영에 지침이 되고자 합니다.
2. 애플리케이션의 배치
웹 애플리케이션의 배치(deployment)는 URL이 도달하는 웹 애플리케이션 서버의 특정 디렉터리(directory)에 애플리케이션을 구성하는 파일들을 복사하는 것으로 간략히 설명할 수 있습니다.
2.1. 설정파일과 사용자 파일
배치에서 발생하는 보안헛점의 대부분은, 애플리케이션 서버의 런타임에 대한 기초지식의 부족으로 인한 설계결함일 가능성이 많은데, 대표적으로 다음의 두 경우를 예로 들 수 있습니다.
- 데이터베이스 접속정보가 담긴 초기화 설정파일
- URL 경로에 있는 사용자의 파일
시스템 운영자는 애플리케이션을 초기화하는 설정파일에 어떠한 정보가 있는지 명확히 알아야 합니다. 데이터베이스 접속정보와 같은 보안에 민감한 내용이 초기화 설정파일에 포함되어 있다면, 이 내용은 URL 경로 외부에 위치한 별도의 파일로 분리해야 합니다. 마찬가지로, 사용자에 의해 업로드 된 파일을 URL 경로에 두는것은 "아무나 이 파일을 가져가시오"라고 하는 것과 동일합니다.
URL 경로에 있는 모든 파일은 웹 서버나 애플리케이션 서버의 잘못된 구성이나 오동작으로 인해 반드시 누출될 수 있습니다.
2.2. 고운플랫폼의 배치
사실, 웹 서비스의 구성에서 설정파일이나 사용자의 파일을 애플리케이션이 배치된 디렉터리에 함께 두는 것은 상식밖의 행위 입니다. 애플리케이션 패키지외에 다른 파일이 여기에 있으면, 서버의 소프트웨어를 업데이트에서 이것을 고려해야 하므로 YUM, APT와 같은 자동 배포(distribution) 도구를 사용 할 때마다 걸림돌으로 작용합니다.
다음은 Tomcat의 ROOT 문맥(context)에 고운플랫폼을 배치한 경우입니다.
$CATALINA_BASE/conf/Catalina/loalhost/ROOT.xml
ROOT 문맥을 정의한 파일입니다. 여기에는 로그파일의 이름과 애플리케이션의 설정파일인 gowoon-platform.properties의 위치가 지정되어 있습니다.
이 설정은 Tomcat에 별도의 가상호스트 설정이 없는 경우 모든 URL 요청은 localhost가 받게 되므로, 고운플랫폼의 가상호스트 기능을 사용할 수 있습니다.
/var/lib/tomcat/gowoon-platform-x.y.z.war
고운플랫폼의 배포 패키지 파일입니다. 이 파일의 이름을 ROOT.war로 변경한 후 webapps 아래에 두어도 되지만, 그렇게 하면 ROOT 문맥에서 사용한 애플리케이션이 무엇인지 잊어버릴 것입니다.
/var/lib/tomcat/webapps/ROOT.war -> /var/lib/tomcat/gowoon-platform.x.y.z.war
ROOT 문맥이 사용하는 ROOT.war를 심볼릭 링크로 만듭니다.
/var/lib/gowoon/localhost/gowoon-platform.properties
데이터베이스 접속정보 및 아래(stores)의 파일저장소 디렉터리 등이 설정됩니다.
/var/lib/gowoon/localhost/stores/
고운플랫폼이 사용하는 파일저장소의 디렉터리들이 위치합니다. 이들 디렉터리는 별도의 파일시스템이 마운트 될 수 있습니다.
이 설정에서 $CATALINA_BASE/webapps/ROOT는 httpd에서 참조될 수 있습니다. httpd의 설정이 미숙하여 이 디렉터리의 모든 파일이 노출되어도 공격자는 고운플랫폼의 패키지를 구성하는 파일 이외에는 어떠한 시스템 구성정보나 사용자의 파일도 획득할 수 없습니다.
고운플랫폼은 오픈시스템을 지향하고 있고, 언젠가는 소스프로그램을 비롯한 모든 파일은 인터넷을 통해 다운로드 될 수 있으므로 그리 대단한 비밀이 아닙니다. 하지만, 고운플랫폼으로 웹 서비스를 하는 서버의 구성정보와 이 서비스가 제공하는 파일을 비롯한 콘텐츠는 적법한 접근외에는 결코 노출되어서는 안되는 최고의 보안이슈입니다.
3. 서비스 진입점
애플리케이션의 서비스 진입점(entry point)이 많다는 것은, 외양간의 벽을 싸리울타리로 두른것과 같습니다. 이러한 경우는 URL이 애플리케이션의 스크립트 파일에 직접 도달하도록 개발된 것들에서 많이 발견됩니다.
ASP, JSP, PHP 등은 텍스트 스크립트로 쉽게 작성할 수 있습니다. 그러나 이것은 보안위험을 차단할 수 있는 대책이 있는 경우에만 장점으로 작용합니다. "쉽게 작성할 수 있다"는 장점 때문에 자칫 수 많은 서비스 진입점을 만들 수 있습니다. 파악되지 않는 서비스 진입점은 "쥐가 드나들 수 있는 구멍"이나 다름이 없습니다.
고운플랫폼의 서비스 진입점은 다음의 경우 외에는 없습니다.
3.1. 공용(public) 디렉터리
이 디렉터리는 웹 서버나 애플리케이션 서버에 의하여 직접 접근될 수 있습니다. 여기에는 고운플랫폼의 사용자 인터페이스에서 사용되는 스타일시트, 이미지, 자바스크립트 등 일반적인 리소스(resource) 파일들이 위치하게 됩니다.
3.2. MVC 서비스
고운플랫폼의 MVC 프레임워크는 접근권한통제(Authorization)에 있어서 다른 구현들과는 차이가 있습니다. 이것은 단일 페이지 구성에 있어서 하나 이상의 콘트롤러를 사용할 수 있고, 콘트롤러에 배정된 데이터원본은 각각 서로 다른 접근권한이 설정될 수 있습니다.
따라서, 어떠한 콘트롤러는 그것과 연관된 데이터원본에 대하여 사용자의 접근권한이 부족한 경우 차단되며, 다른것은 그렇지 않을 수 있습니다. 이는 단일 페이지로 구성된 콘텐츠를 보다 사용자 중심으로 표현할 수 있음을 의미합니다.
개발자들에게 널리 알려져있는 스프링프레임워크의 인터셉터(interceptor)는 접근권한이 부족한 경우 콘트롤러 요청을 차단합니다. 문제는 하나의 페이지에 하나의 콘트롤러만 사용하므로 URL 전체를 차단하는 결과가 될 수 있습니다.
고운플랫폼의 접근권한통제의 중심에는 데이터원본이 있습니다. 데이터원본은 애플리케이션 컴포넌트를 통해 접근되는 데이터의 논리적 개념으로, 데이터베이스의 테이블이나 뷰, 또는 파일의 집합인 경우가 대부분이지만, 실제 데이터 없이 역할권한 설정만 있는 경우도 있습니다. 같은 데이터원본을 사용하는 모든 컴포넌트는 그것이 MVC의 콘트롤러이든 리치 애플리케이션이든 모두 동일한 역할권한이 적용이 됩니다.
3.3. 리치 앱
고운플랫폼의 리치 앱은 웹 브라우저에 별도의 추가기능이 필요없는 JavaScript 애플리케이션입니다. 이것은 콘텐츠의 표시나 사용자에 의해 입력된 데이터의 저장 등을 위해 서버의 리치 앱 서비스와 AJAX 방식으로 소통(communication)하는데, 접근권한통제는 클라이언트와 서버에서 일관성은 유지하지만 각각 다른 목적으로 구현됩니다.
3.3.1. 클라이언트의 UX
리치 앱의 클라이언트에서 데이터원본의 역할권한은 사용자의 권한이 부족한 경우, 메뉴나 명령 버튼을 불능(disabled) 상태로 만드는데 사용됩니다. 사용자 인터페이스에서 역할권한의 적용은 사용자 경험을 위한 매우 중요한 기능입니다. 무료로 운영되고 수 많은 사용자로 널리 알려진 영리목적을 가진 포털 사이트의 웹 서비스에서 버튼이나 링크를 클릭한 후 "권한이 없습니다"라는 메지지를 보면 참으로 어이가 없습니다.
고운플랫폼의 리치 앱을 비롯한 GWT 애플리케이션은, Java로 작성되어 GWT의 컴파일러에 의해 JavaScript로 변환되는데, 이때 생성된 JavaScript 코드는 사람에 의해 분석되는 것이 사실상 불가능 합니다. 이 때문에 GWT 애플리케이션이 마치 보안문제를 해결한 것처럼 착각할 수 있지만, 이것은 어디까지나 사람의 눈으로 보여지는 것 뿐입니다.
3.3.2. AJAX 서비스 진입점
리치 앱을 위한 AJAX 인터페이스는 악의적인 공격을 받을 수 있는 서비스 진입점입니다.
GWT 애플리케이션은 서버와의 소통을 위해 AJAX 방식으로 JSON 데이터를 주고 받습니다. 여기에서 JSON 데이터는 클라이언트와 서버사이의 어느곳에서도 위·변조 될 수 있으며, 이러한 경우 서버는 잘못된 데이터를 저장하거나 오동작을 일으킬 수 있습니다. 물론, GWT는 이것에 대한 대책을 마련하고 있습니다.
GWT의 보안과는 별도로, 고운플랫폼의 접근권한통제는 리치 앱 서비스의 보안성을 강화합니다. 접근권한통제는, 모든 AJAX 요청 각각에 대하여 사용자를 식별하고, 이 사용자가 그 서비스와 연관된 데이터원본에 대하여 권한이 있는지를 검사합니다.
서버의 접근권한통제는 클라이언트가 전송한 데이터에 의존하지 않고 동작하기 때문에, 개발자가 실수로 누락한 사용자 경험 관련 코드를 감지하기도 하기도 합니다.
3.4. 파일 서비스
3.4.1. 업로드
서버로의 업로드는 권한이 있는 사용자만이 가능합니다. 이것은 프로젝트의 데이터원본을 사용하는 접근권한통제와는 별도로 관리됩니다. 서버 관리자는 클라우드 서비스의 운영정책에 따라 사용자별로 서로 다른 저장소와 공간을 할당할 수 있습니다.
고운플랫폼 전체에서, 업로드는 사용자의 내 파일에서만 가능합니다. 사용자는 내 파일에 업로드한 후 프로젝트에 제출할 수 있습니다. 시스템의 파일 저장소에 보관된 파일은 그것이 업로드되었던, 클라우드 내에서 만들어졌던, 그것의 원인이 된 최초의 사용자를 기록합니다. 이는 클라우드 시스템의 유용성과 안정성을 위해 반드시 필요합니다.
사실, 클라우드 서비스에서 파일은 대단히 큰 위험요소 일 수 있습니다. 사용자가 업로드한 파일은 바이러스나 악성코드일 수 있고, 웹 서비스의 명예를 실추 시킬 수 있는 내용일 수 있습니다. 이러한 파일이 프로젝트의 공개된 콘텐츠에 게시되면, 실로 난감하지 않을 수 없습니다.
클라우드 서비스의 프로젝트는 공공장소와도 같습니다. 사용자 기능에 포함된 내용은 비밀이지만, 프로젝트에 제출된 것에 대한 책임소재를 묻는 것은 당연합니다.
고운플랫폼에서 업로드를 위한 사용자 인터페이스는, AJAX 방식을 사용하여 한번의 요청에서 어러개의 파일을 순차적으로 전송하도록 구현되어 있고, 서버에서는 업로드 되는 파일마다 개별적으로 처리합니다.
서버의 파일 서비스는, 업로드 요청 각각에 대하여 다음의 절차를 거칩니다.
- 요청의 적합성 검사
- 사용자 식별
- 업로드 하는 파일의 크기 확인
- 사용자에게 배정된 저장소의 남은 용량을 확인
- 사용자의 파일 할당량과 사용량 확인
- 전송 요청 수락하여 임시파일에 저장
- 수신된 데이터의 크기와 업로드 요청 크기의 검사
- 저장소 업데이트
3.4.2. 다운로드
사용자 기능의 내 파일은 사용자 개인의 파일입니다. 내 파일에서 다운로드는 파일의 소유자인 세션 사용자만 가능합니다. 사용자 세션이 종료된 브라우저는 다운로드 URL이 보관되어 있다 할지라도 결코 사용자의 파일에 접근할 수 없습니다.
프로젝트 파일은 프로젝트에 제출된 사용자의 파일을 말합니다. 프로젝트 파일의 다운로드는 본 문서의 다른곳에서 언급하고 있는 접근권한통제와 동일하게 처리되며, 그것과 연관된 데이터원본의 상세권한이 검사됩니다.
데이터원본의 상세권한이 손님(guest)인 경우 프로젝트 파일의 URL은 어느 곳에서든 참조될 수 있으나, 그 외의 경우 웹 브라우저의 사용자 세션이 종료되면 접근할 수 없습니다.
3.4.3. 브라우저 캐시
프로젝트 파일이 첨부된 데이터원본의 상세권한이 손님(guest)인 경우를 제외하고, 웹 페이지의 인라인(inline) 미디어를 포함한 모든 다운로드는 브라우저에 캐시되어 저장되지 않도록 하고 있습니다.
하지만, 이것은 어디까지나 브라우저가 HTTP 캐시관련 서버의 응답을 반영해야만 그 효력이 있습니다.
4. 결론
웹 서비스의 진짜 공격자는 마치 검색엔진인 것처럼 가장하는 로봇입니다. 이것은 단순연구를 목적으로 하는 것도 있겠지만, 거대한 권력조직이 정보의 수집을 목적으로 전 세계에 웹 로봇 시스템을 운영하는 경우도 있는 것 같습니다. 어떠한 경우이든, 서버 로그의 분석을 통해 이들의 수단과 방법이 참으로 다양함을 알 수 있습니다.
고운플랫폼의 전 개발과정에서 보안과 접근권한통제의 설계와 구현에 소요된 시간과 노력은 가늠할 수 없을 정도입니다. 표면적으로는 거의 드러나지 않는 이 기능은, 시스템의 안정성과 사용자의 데이터 보호를 위해 지속적으로 연구되고 발전 될 것입니다.