2012. 1. 26. 16:06

문서 객체 모델(DOM : Document Object Model)은 객체 지향 모델로써 구조화된 문서를 표현하는 형식이다. DOM은 플랫폼/언어 중립적으로 구조화된 문서를 표현하는 W3C의 공식 표준이다. DOM은 또한 W3C가 표준화한 여러 개의 API의 기반이 된다.

DOM은 HTML 문서의 요소를 제어하기 위해 웹 브라우저에서 처음 지원되었다. DOM은 동적으로 문서의 내용, 구조, 스타일에 접근하고 변경하는 수단이었다. 브라우저 사이에 DOM 구현이 호환되지 않음에 따라, W3C에서 DOM 표준 규격을 작성하게 되었다.
- 위키백과 "문서 객체 모델" 인용 

문서 객체 모델을 어떻게 설명해야 하는가? 기반이 되는 개념들을 설명한 후에 종합하는 것이 유리할 것 같다. 어떠한 개념들이 있는가 나열하기 보다는 위키 백과의 요약된 설명을 인용했다. 위키 백과는 많은 기술과 용어들을 소개하고 있지만 불친절한(?) 해설들이 꽤 많다. 백과사전은 매뉴얼과 다르다 라고 이해하는게 정신 건강에 좋을 것 같고, 어쨋든 잘 정리된 정보인 것은 확실하다.

DOM에 포함된 다양한 개념들을 하나씩 파헤쳐 보자.

1. 문서 혹은 구조화된 문서

일반적으로 문서는 특정 주제를 다룬 문장 혹은 글의 집합이라고 설명할 수 있다. "구조화된 문서(structured document)"는 계층적(hierarchical) 형태 혹은 트리(tree) 형태로 만들어진 문서를 말한다. 달리 말하자면, 문장들이 순서대로 읽을 수도 있지만, 문장, 단락(paragraph) 혹은 단어 간에 부모/자식/형제 관계가 존재한다는 말이다. 구조화된 문서들은 사용자에게 보여지는 방식에 따라서 부모/자식 관계가 눈에 보이기도 하고, 보이지 않는 경우도 있다. 또한, 문서 내부에 삽입되어 있지만 시각화 되지 않는 정보들도 있다.

2. 객체 지향 모델

객체지향 문서라는 표현이 이상하게 여겨질 수 있다. 객체는 "행위"와 "자료"를 함께 묶어둔 프로그램 부품을 말하는데, 문서에도 "행위"가 존재할까? DOM으로 표현된 문서에 표현된 "행위"는 문서 자체가 동작하는 것이 아니라, 문서에 포함된 다양한 요소(element)들을 편집하는 방법을 규정한 것이다.

3. 플랫폼/언어 중립적

DOM 문서는 유닉스, 리눅스, 윈도우 등 거의 모든 운영체제에서 읽고 쓸 수 있다. 또한 DOM 문서는 자바, 자바스크립트, C, Perl 등 다양한 프로그래밍 언어를 이용해 작성하거나, 조회할 수 있다. 이를 위해, W3C는 DOM 문서를 조작할 수 있는 API들을 정의했다.

4. DOM API

W3C는 DOM 문서를 편집할 수 있도록 다양한 API들을 제안(엄격히 지켜야 하는 규정은 아니다) 했다. W3C를 지지하는 다양한 프로그램 개발 조직 및 개발자들은 W3C에서 제안한 API를 다양한 언어와 라이브러리로 구현하였다.

함께 읽으면 좋은 글 : 
DOM 이해하기 (한글) - IBM
Posted by 곽중선
2012. 1. 26. 14:22
스프링 시큐리티를 왜 도입해야 하는가? 라는 질문을 던져놓고 필요한 답을 찾아봤습니다. 아래 웹 페이지의 일부 내용을 번역한 것입니다.


1. 스프링 시큐리티는 어플리케이션의 모든 보안 요구사항을 충족할 수 있는가?

스프링 시큐리티는 사용자 인증(authentication) 및 권한 제어(authorization) 요구에 대해 매우 유연한 프레임워크를 제공하지만, 보안 어플리케이션을 구축하기 위해서는 스프링 시큐리티의 범위 밖에 있는 다양한 고려사항이 있다. 웹 어플리케이션은 이미 잘 알려져 있는 모든 종류의 공격에 취약하기 때문에, 개발을 시작하기 전에 발생할 수 있는 문제들을 잘 이해한 후에 코딩하고 설계해야만 한다. 웹 어플리케이션 개발자가 알아야 하는 주요 이슈와 대응책을 얻기 위해서는 OWASP 웹 사이트를 참조하기를 바란다.
 
2. web.xml 보안으로 충분하지 않는가?

자, 당신이 스프링 기반으로 엔터프라이즈 응용 프로그램을 개발하고 있다 가정하자. 

일반적으로 언급되고, 보안 시스템 구축 시 요구되는 4가지 보안 문제가 있다. 인증(authentication), 웹 요청 보안(web request security), 서비스 계층 보안 (비즈니스 로직을 구현한 메소드들), 도메인 객체 인스턴스 보안 (서로 다른 도메인 객체는 다른 접근 제한 등급을 가진다) 등이다. 

1) 인증(authentication) : 서블릿 사양(servlet specification)에는 기본적인 인증 방식이 정의되어 있다. 그러나, 일반적으로 서블릿 인증을 수행하기 위해서는 웹 컨테이너(web container)의 고유 영역(realm)을 설정해야 한다. (예를 들자면, 톰캣의 설정 방식과 JBoss의 설정 방식이 다르다.) 이러한 설정 방식은 이식성(portability)이 없는데다, 컨테이너의 인증 인터페이스를 구현한 자바 클래스를 작성해야 하는 경우 더욱 더 이식성이 없어지게 된다. 스프링 시큐리티를 사용하게 되면 WAR 수준에서 완벽한 호환성을 달성할 수 있다. 게다가, 스프링 시큐리티는 검증된 사용자 인증 제공자 및 메커니즘들을 선택할 수 있으므로, 개발 진행 중에 인증 방식을 선택하거나 교체할 수 있다. 이는 확정되지 않은 운영 환경을 대상으로 개발되는 소프트웨어를 개발하는 업체에게 유용하다.

2) 웹 요청 보안(web request security) : 서블릿 사양(servlet specification)에서는 요청 URI의 보안성을 유지하는 방법을 제공한다. 그러나, 서블릿 사양에 기초해 보안 가능한 URI들은 사양에서 지정한 제한된 URI 포맷을 따라야만 한다. 스프링 시큐리티는 훨씬 더 포괄적인 방식을 제공하고 있다. 예를 들어, Ant 경로 혹은 정규식 표현을 사용할 수 있다. 단순히 요청된 페이지 경로가 아니라, URI의 일부 요소 (HTTP Get 인자 등)를 고려할 수도 있다. 이것은 웹 어플리케이션이 실행되는 동안에 웹 요청 보안이 동적으로 변경될 수 있음을 의미한다.

3) 서비스 레이어와 도메인 객체 보안(Service layer and domain object security) : 서블릿 사양 내에 서비스 계층 보안 및 도메인 객체 인스턴스 보안에 대한 지원(혹은 표준)이 없다는 것은 다계층(multi-tier) 어플리케이션을 개발함에 있어 심각한 한계를 보여준다. 일반적으로 개발자들은 이러한 요구사항을 애써 무시하거나, MVC 컨트롤러 코드 (더 나쁜 경우는 뷰 계층에서...) 내에서 보안 로직을 구현한다. 이러한 대응 방식은 심각한 단점들을 내포하고 있다.

a. 관심사의 분리(Separation of concerns) : 인증은 횡단 관심사(crosscutting concern)로 간주되어야 하고, 그렇게 구현되어야 한다. 반면에 MVC 코드나 뷰에서 인증 코드를 구현할 경우, 제어 로직과 인증 로직을 함께 테스트 하기 어렵고, 디버깅하기 어려우며, 코드 중복으로 이어지게 된다. 

b. 리치 클라이언트와 웹 서비스에 대한 지원(rich clients and web services) : 새로운(혹은 추가된) 유형의 클라이언트를 필수적으로 지원해야 하는 상황이 닥친다면, 웹 계층에 내장된 인증 코드는 재사용할 수 없게 된다. 이런 상황에서는 스프링 리모팅 익스포터(remoting expoters)만이 서비스 계층 빈(MVC 컨트롤러가 아닌 객체)들을 외부로 노출할 수 있다. 다양한 클라이언트 유형을 지원하기 위해서는 인증 로직인 서비스 계층에 존재해야 한다. 

c. 계층 문제(layering issues): MVC 컨트롤러나 뷰(view) 계층에 인증 로직을 담는 것은 매우 잘못된 계층 설계이다. 반면에, 서비스 계층에서 인증하게끔 결정할 경우 모든 서비스 계층 메소드에 추가 인자(argument)를 전달해야 하는 문제가 발생한다. 좀 더 우아한 방식은 ThreadLocal 에 인증 정보를 담는 방식이나, 이는 개발 기간의 증가를 의미한다. 가장 경제적인 방법(비용 절감 차원)은 전용(dedicated) 보안 프레임워크를 사용하는 것이다. 

d. 인증 코드 품질(authorization code quality) :  웹 프레임워크들은 종종 "올바른 것들은 더욱 쉽게 할 수 있고, 잘못된 방식들은 더욱 하기 어렵게 만드는 것(make it easier to do the right things, and harder to do the wrong things)"이라고 불리운다. 보안 프레임워크는 보다 다양한 목적과 추상적 방식으로 설계되기 때문에 웹 프레임워크와 동일한 특징을 가지고 있다. 자신만의 인증 코드를 작성할 경우, "검증(design check)"이 이루어지지 않는다. 반면에 보안 프레임워크들은 객관적으로 검증된 것이다. 또한, 자체 제작(in-house) 된 인증 코드는 광범위한 개발을 통한 개선, 외부 혹은 동료 개발의 리뷰, 버전업 등이 이루어지지 않는다.
 
간단한 어플리케이션인 경우, 서블릿 스펙 보안으로 충분할 수 있다. 그러나, 웹 컨테이너 간의 낮은 이식성, 설정 방식의 비호환성, 웹 요청 보안의 유연성 부족, 서비스 계층과 도메인 객체 인스턴스 보안의 부재 등을 고려해 본다면, 또 다른 솔루션을 고려해야 하는 것이 분명하다. 
Posted by 곽중선