난이도 : 초급 Anthony Nadalin, Chief Security Architect and Distinguished Engineer, IBM
Nataraj Nagaratnam, Senior Technical Staff Member, IBM
Maryann Hondo, Web Services Security Standards Lead, IBM
2005 년 9 월 06 일 서비스 지향 아키텍처(SOA)에서 애플리케이션의 보안은 도전적인 문제이다. SOA의 대표적인 특징인 약결합이 기존 보안 구현의 약점들까지 노출할 수 있기 때문이다. 지금까지의 솔루션으로는 입증된 트러스트 모델을 비롯하여 정책에 기반한 신뢰성, 웹 서비스 보안, 보안 엔지니어링 등이 있다.
머리말
정보 접근을 보안화 하는 것은 모든 애플리케이션의 기본이다. 보안은 SOA 원리에 따라 구현된 것에는 더욱 중요한 문제이다. 왜냐하면 SOA의 대표적인 특징이 약결합이기 때문이다. 이 같은 환경은 종종 기존 보안 구현의 한계를 드러내기 마련이다.
모델 중심의 개발과 SOA 기반 서비스 관리가 가져온 효율성과 관계 없이, 비즈니스 애플리케이션이라면 정보를 지속적으로 보안화 해야 하는 숙제를 지속적으로 가져가야 한다. 주변(방화벽과 라우터)을 단순히 보안화 하는 것으로는 충분하지 않다. 왜냐하면 온 디맨드 비즈니스는 파트너, 고객, 사원들간 관계가 변화하는 것에 발맞추어 동적인 트러스트 관계를 설정할 수 있어야 하기 때문이다. 따라서 보안화 된 온 디맨드 비즈니스에는 유연하고 커스터마이징 가능한 인프라가 필요하고 새로운 요구 사항들과 규제에 적응할 수 있어야 한다. 이렇게 유연해지려면 정책들이 인프라에 고정되어서는 안된다. 정책 중심의 인프라를 통해 보안 모델의 요구 사항들을 구현해야 한다. 간단한 일이 아니다.
이 글은 비즈니스 애플리케이션이 온 디맨드 보안 인프라에서 제공하는 보안 기능들과 보안화 된 서비스 지향 애플리케이션의 디자인 원리를 어떻게 활용할 수 있는지를 설명한다.
비즈니스 애플리케이션과 보안 인프라
보안 통합과 비즈니스 애플리케이션 및 정보에 대한 액세스는 일반적으로 인증, 권한을 통해 실현된다. 비즈니스가 인증, 권한 등을 관리하는 방식은 고객, 사원, 파트너들간 트러스트 관계의 관점에서 정해진다. 또한 이러한 관계가 비즈니스 애플리케이션의 보안에 미치는 영향이나 애플리케이션의 상대적 중요성과 보안의 관점으로도 결정된다.
비즈니스 파트너들간에 중요한 정보가 교환될 때, 이는 반드시 보안화 되어야 한다. 또한 안전한 방식으로 일관성 있게 보존되어야 한다. 근원 메시지의 무결성이 보장되어야 하며 필요할 경우 밸리데이션, 감사, 부인방지(nonrepudiation)가 실행되어야 한다. 민감한 정보는 암호화 되어 기밀성을 유지하거나 디지털 서명을 통해 무결성을 유지해야 한다. (디지털 서명은 부인방지에도 중요한 역할을 한다.) 완벽한 SOA 보안 디자인이라면 메시지 및 전송 관련한 보안 뿐만 아니라 정규 규제와 산업 관례에 순응하는 컨텐트를 보안화 하는 방법도 다루어져야 한다.
근본적으로 비즈니스와 사원, 고객, 파트너들간 트러스트 관계는 보안 정책의 정의 및 실행과 보안 레벨에 영향을 미친다. 인증과 암호화 키 등 관련 기술들은 이러한 트러스트 관계를 반영 및 관리하는데 사용된다. 비즈니스 파트너들간, 그리고 고객과 비즈니스간 트러스트 관계를 모델링 및 정의하는데 사용되는 툴은 신뢰성 정의를 IT 환경에 맞는 기술로 변환할 수 있다.
SOA 성숙도 모델
SOA 성숙도 모델은 웹 서비스는 클레임(claim)을 확인하는 인커밍 메시지를 요구하는 프로세스에 기반하고 있다. 클레임 예제로는 이름, 키, 허용, 기능 등이 포함된다. 제공된 정보에 근거하여 적절한 트러스트 모델이 요청자, 서비스 엔드포인트, 중재자들간 적용된다.
메시지는 요청자와 목표 서비스 사이에 여러 중재자들을 거친다. 엔드투엔드(ent-to-end) 보안 관리에는 요청자, 중재자, 최종 엔드포인트 서비스(공급자)간 트러스트 모델이 고려되어야 한다. (그림 1)
그림 1. 중재를 통한 요청자-공급자 트러스트 모델
네트워크와 전송 중재자(방화벽, 라우터, 프록시 서버)는 메시지 프로세싱의 관점에서 볼 때 신뢰를 받지 못한다. 전송중인 모든 메시지들은 이러한 중재자들로부터 스스로를 보호해야 한다.
OASIS Web Services Security(WSS) 스팩은 Simple Object Access Protocol(SOAP) 메시지에 보안을 제공한다. WSS를 사용하면 네트워크와 전송 중재자로부터 메시지의 신뢰성, 무결성, 기밀성 등을 유지할 수 있다.
그림 2. 메시지 중재 브로커의 트러스트 관계도 및 연합
모든 중재자들이 신뢰를 받지 못하는 것은 아니다. 웹 서비스 게이트웨이와 엔터프라이즈 서비스 버스 중재 서비스는 SOA에서 감시와 메시지 페이로드의 변형 등의 역할을 한다. ["IBM Enterprise Service Bus 소개" (developerworks, 2005)]. SOA 보안 인프라를 디자인 할 때 신뢰를 받는 중재자를 채택하는 것도 고려할 수 있다.
또 다른 신뢰 중재자는 요청자와 애플리케이션 서비스 호스트간 트러스트 관계를 핸들하는 메시지 브로커가 될 수 있다. 이 디자인에서 보안 책임은 브로커와 서비스 엔드포인트로 나누어 진다. 그림 2처럼, 메시지 중재는 메시지 레벨의 보안, 요청자와 공급자 환경간 정체성 연합, 요청자와 서비스 공급자간 트러스트 관계 관리 등의 책임을 맡고 있다. 서비스는 서비스 스팩의 보안 요구사항만 책임이 있다. 애플리케이션에서 불충분하거나 복잡한 인프라 코드를 걸러내어 이를 컨테이너에 위임함으로서, SOA 기반의 보안 방식은 유연성이 높아지고 재난의 가능성을 줄일 수 있는 것이다.
메시지 보안
WSS 스팩은 메시지 레벨의 메커니즘을 제공하여 무결성, 신뢰성, 인증에 기여한다. 따라서 웹 서비스 개발자들은 SOAP 교환을 보안화 할 수 있다. 이러한 메커니즘이 다양한 방식으로 결합되어 다양한 암호화 기술을 사용하는 광범위한 보안 모델을 구현할 수 있다.
WSS는 메커니즘을 확장하여 보안 토큰과 메시지를 제휴시켜서 다양한 인증 및 권한 포맷과 메커니즘까지 허용하고 있다. 예를 들어, 클라이언트가 자신들이 특별한 비즈니스 인증을 갖고 있다는 입증된 아이디와 서명된 클레임을 제공하면, 이 같은 메시지를 받는 웹 서비스는 이 클레임을 신뢰할지 여부를 결정한다.
보안 토큰 클레임은 권한이 부여되거나 권한을 받지 못한다. 권한을 받은 클레임은 보안 토큰으로서 나타나고, 이 보안 토큰은 디지털 서명이 되거나 권한에 의해 암호로 보호된다. 서명이 된 보안 토큰의 예로는 X.509 인증을 들 수 있다. 보안 토큰은 메시지에 "푸시(push) " 되거나 레퍼런스에 의해 표현되어, 수신자가 클레임을 "풀링(pull) " 할 수 있다.
보안 토큰은 트러스트 도메인 내에서만 유용하기 때문에 트러스트 도메인의 범위를 조정해야 한다. 계약으로 직접 조정하거나, 트러스트 정책을 실행하는 규칙 세트를 구현하기도 한다. 권한을 부여 받지 못한 클레임은 발신자와 수신자간 트러스트 관계가 확립되었다면 권한을 받을 수 있다. 예를 들어, 발신자인 Bob이 보낸 클레임이 권한을 부여 받지 못한 경우, 발신자와 수신자가 트러스트 연결을 사용하고 있다면 발신자가 Bob이라는 것을 수신자는 충분히 알 수 있다. 이 예제에서 이러한 트러스트 연결만으로도 충분한 입증력을 갖추는 것이다.
메시지 컨텐트를 불법 액세스(기밀성)나 불법 수정(무결성)으로부터 보호하는 것은 보안의 기본이다. WSS 스팩은 바디, 헤더, 어태치먼트 등을 암호화 하거나 디지털 서명을 하는 식으로 메시지를 보호한다.
요청을 인증하는 것은 선택적인 네트워크, 메시지에서 입증된 전송 측 보안과 정보(클레임), 메시지 기원 인증 기술 등에 기반 한다. 요청자는 네트워크와 전송측 보안, 메시지에서 입증된 클레임, 수신자에 알려진 키를 사용하는 요청자의 암호를 기반으로 수신자를 인증한다.
트러스트 모델
보안 토큰이 권한을 받았는지를 나타내는 한 가지 방법은 관련 비밀 키를 사용하는 디지털 서명을 포함시키는 것이다. 요청자는 보안 토큰(Public Key Infrastructure for X.509 Certificates(PKIX) 또는 X.509 인증)을 메시지와 제휴 시켜 요청된 클레임을 입증할 수 있다.
요청자가 해당 서비스에 필요한 클레임을 입증할 토큰을 갖고있지 않다면 해당 기구(보안 토큰 서비스)에 연락하여 알맞은 토큰을 요청한다. 보안 토큰 서비스는 다른 트러스트 도메인들간 트러스트 관계를 중재하는데 사용할 수 있는 보안 토큰을 발행한다.
WS-Trust (참고자료)에서 정의된 것 처럼 신청-응답(challenge-response) 프로토콜을 사용할 수도 있다. 메시지의 무결성과 보안 토큰이 권한을 받은 것이라는 것을 입증하기 위해 웹 서비스가 사용하는 것이다. 이 모델은 그림 3에 묘사되어 있다. 요청자는 서비스가 될 수 있고, 요청자와 목표 서비스는 트러스트를 받은 제 3자 보안 토큰 서비스를 갖고 있을 수 있다.
그림 3. 보안 토큰 서비스
이러한 SOA 성숙도 모델-클레임, 정책, 보안 토큰-은 아이디 기반 권한부여, 액세스 제어 리스트, 기능 중심의 권한 부여 같은 보다 구체적인 여러 모델을 지원한다. 또한, X.509 퍼블릭 키 인증, XML 기반 토큰, Kerberos 공유-비밀 티켓, 패스워드 같은 기존 기술을 사용할 수도 있다. SOA 성숙도 모델은 Web Services Secure Conversation Language(WSSC)와 Web Services Policy Framework과 결합하면 고급의 키 교환, 인증, 정책 기반의 접근 제어, 감사, 복잡한 트러스트 관계 등을 충분히 구현할 수 있다.
웹 서비스는 적용되는 정책이 있으며, 보안 토큰을 포함하고 있는 요청자에게서 메시지를 받고, WSSC 메커니즘을 사용하는 방어 기재를 갖고 있다. 다음은 웹 서비스의 트러스트 엔진에서 수행되는 것들이다.
- 토큰에 있는 클레임이 정책에 순응하고 있으며, 메시지가 정책에 순응한다는 것을 확인한다.
- 청구인(claimant)의 애트리뷰트가 서명을 통해 입증되었는지를 확인한다. 중재 과정을 거치는 트러스트 모델에서, 이 서명은 청구인의 아이디를 확인하지 않을 수도 있다. 청구인의 아이디를 선언하는 중재자의 아이디를 확인하는 경우가 있다. 이 클레임은 정책에 의해 입증여부가 가려진다.
- 보안 토큰의 발행자(보안 토큰 발행과 관련된 모든 것을 포함함)가 클레임을 발행할 자격(trust)이 있는지를 확인한다. 트러스트 엔진은 토큰을 외부에 입증하거나 중재해야 한다. (다시 말해서, 토큰을 보안 토큰 서비스로 보낸다. 이들이 다른 보안 토큰들과 교환될 수 있도록 하기 위함이다.)
이러한 조건들이 맞고 요청자가 권한을 부여 받으면, 이 서비스는 서비스 요청을 처리할 수 있다.
IP Security(IPSec)나 Transport Layer Security/Secure Sockets Layer(TLS/SSL) 같은 네트워크와 전송 보안 메커니즘은 SOA 성숙도 모델과 결합하여 사용되어 다양한 보안 요구 사항들과 시나리오를 지원한다. 요청자는 네트워크나 전송 보안 메커니즘을 통해, 보안 토큰을 발행, 검사, 갱신할 때 수신자를 사전 인증하는 방법도 모색할 수 있다.
프로그래밍 모델 디자인 원리
프로그래밍 모델에서는 누가 보안 정책을 실행할 책임을 맡을 것인지(인프라 또는 애플리케이션), 요청자가 사용할 수 있는 정보가 무엇인지를 결정해야 한다. 실행적 측면 외에도, (J2EE 전개 디스크립터에 의해 포착된) 디자인 정책은 애플리케이션을 관리하는데 도움이 된다. 핵심적인 구현 결정 중 하나는 어떻게 하면 비즈니스의 필요가 완벽하게 채워질 수 있는지를 결정하는 것이다. 인프라에서 보안 모델을 구현할지 아니면 각 애플리케이션에 보안을 적용할지 등을 결정해야 한다. 서비스 호출이 얼마나 다양한지도 고려해야 한다. 등록된 서비스 소비자가 커스터마이징을 통해 얼마나 혜택을 누릴 수 있는지도 파악해야 한다. 마지막으로, 보안 솔루션을 구현할 때 보안 애플리케이션을 구현하는 엔지니어링 방식인 보안 엔지니어링을 고려해야 한다.
인프라 관리 보안 대 애플리케이션 관리 보안
모든 기업들은 일반적으로 특정 사람들에게 보안 정책을 규명하고 실행할 책임을 부여한다. 많은 경우에 이 작업은 수동으로 이루어지기 때문에 기업은 상당히 많은 인력들을 여기에 투입한다.
복잡한 기업들이 솔루션과 연계된 보안 정책들의 실행을 중앙에서 관리하는 것을 권고한다. 다시 말해서, 사용자 신청(사용자 ID/패스워드)을 확인하고, 애플리케이션으로의 액세스를 제어하며(travelService에 대한 reserve()메소드), 아이디를 위임(run-as travelAgency id)하여 일관된 방식을 취한다. 초기 애플리케이션 보안 정책들은 몇몇 전개 객체(J2EE 애플리케이션용 전개 디스크립터)에서 정의될 수 있다. 전개 후에 애플리케이션 로직이 알려지면 정책 정보를 전개 환경에서 사용할 수 있다. 정책 선언들은 고급 정책 요구 사항들로 추출되어 후에 조정될 수 있다.
애플리케이션을 디자인 할 때 인프라 관리형 보안 또는 애플리케이션 관리형 보안에 대한 결정이 이루어 진다. 보안 제약과 보안 조건은 구현 객체에 첨부된다. 인프라에서 보안을 관리할지 아니면 애플리케이션을 보안화 할 지를 결정하는 시기는 애플리케이션 플랫폼에 대한 정보(Java ™ 2 Platform, Enterprise Edition (J2EE) 또는 Microsoft ® .NET)를 사용할 수 있을 때인 구현 단계이다.
우리는 애플리케이션이 비즈니스 로직에 집중하고, 서비스 액세스와 메시지를 보안화 하는 문제는 인프라로 위임할 것을 권장한다. 이러한 인프라 관리형 방식에서는 디자인 객체에 첨부된 보안 정책들은 해당 플랫폼에 맞는 정책들로 변형된다. [Unified Modeling Language(UML)를 통해 표현된 요구 사항들은 J2EE 전개 디스크립터로 변형된다.]
애플리케이션 관리형 방식에서는, 애플리케이션에서 보안이 실행되고, 해당 보안 콜아웃(callouts)이 구현되어야 한다. 애플리케이션 관리형 보안은 보안 콜아웃(authenticate())을 해당 플랫폼의 함수[Java Authentication and Authorization Service(JAAS)를 사용하는 loginContext.login()]로 변형해야 한다.
권한과 액세스 제어는 대단위(coarse-grained)부터 소단위(fine-grained)까지 다양하다. 대단위 접근 또는 소단위 접근에 대한 결정은 비즈니스 및 기술적 고려 사항들에 기반한다. 세분성 역시 정보 엔터티의 인스턴스(여행자의 신용 계정 프로파일), 사용자 애트리뷰트(여행사), 시간적 제약조건(9-5 p.m.), 접근 목적(여행 예약의 목적), 접근 경로(인트라넷 또는 외부 요청) 등의 영향을 받는다.
권한과 관련된 정책은 애플리케이션 역할을 정의하는 것으로 규명될 수 있다. 역할은 주어진 애플리케이션 리소스에 대해 특정 액션을 수행할 수 있는 권한의 모음이다. 예를 들어, 이 여행 애플리케이션에서는 ReservationBean에서 view() 또는 change() 메소드가 TravelAgent 역할이 접근할 수 있도록 선언하고 있다. 다시 말해서, TravelAgent는 구현 시 정의된 역할로서, 각 Enterprise JavaBeans(EJB)에서 특정 메소드를 호출하는 역할을 "여행사(Travel Agent) "가 수행할 것을 규명하고 있다. 구현 단계에서 정의되지 않는 것은 누가 TravelAgent의 특권을 가지고 있는지에 대한 것이다. 사용자-역할 할당은 일반적으로 전개시 초기화 되고 애플리케이션의 수명주기 동안 관리된다. Listing 1은 역할 기반 메소드 권한을 정의하는 코드 예제이다.
Listing 1. 역할 기반의 메소드 권한을 정의하는 코드
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-name> view</method-name>
<method-name> change</method-name>
</method>
</method-permission>
|
비즈니스 로직을 수행하기 전에 인증을 받은 아이디 정보가 필요한 애플리케이션은 반드시 그 정보를 인프라에서 획득해야 한다. 예를 들어, J2EE 환경에서 런타임은 인증 후에 사용자 아이디를 인식한다. 애플리케이션은 getCallerPrincipal() 같은 API를 사용하여 정보를 가져온다.
유연성의 선택
가끔 인증, 무결성, 기밀성 같은 요구 사항이나 제약 조건들이 클라이언트 런타임 시 필요할 때가 있다. 따라서 광범위한 클라이언트 런타임(브라우저 클라이언트, 비 브라우저 클라이언트, PDA 씬 클라이언트)을 지원하는 것이 바람직 하다. 이를 위해 여러분은 클라이언트 런타임 시 메시지 기밀성이 보장되고 사용자의 아이디(ID/패스워드 또는 인증)를 제공해야 한다는 것을 선언하는 정책을 퍼블리시 해야 한다.
예를 들어, TravelService 웹 서비스는 특정 서비스 토큰 유형과 기밀성 요구 사항이 필요하다는 필요한 머신 레벨에서 지원할 수 있는 것(WS-SecurityPolicy)을 수행한다. (Listing 2)
Listing 2. WS-Security Policy 예제
<wsp:Policy>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:KerberosV5APREQToken
sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:ProtectionToken>
<sp:SignBeforeEncrypting />
<sp:EncryptSignature />
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedParts>
<sp:Body/>
<sp:Header
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>
|
보안 엔지니어링
보안 솔루션을 개발 할 때 가장 좋은 방법 중 하나는 보안 엔지니어링이다. 정의가 잘 되어있는 패턴을 따라가면 애플리케이션, 서비스, 컴포넌트는 디자이너와 사용자가 기대하는 것을 정확히 수행할 수 있다. 각 구현 객체에 존재하는 위험 요소들을 평가하여 취약점이 노출되지 않도록 디자인 및 구현한다. 툴 지원과 코드 리뷰 역시 악영향을 줄이는데 도움이 된다.
요약
SOA 프로그래밍 모델은 각 서비스 호출이 서비스 정책을 준수하도록 한다. 보안 인프라는 컴포넌트와 서비스를 보안화 하는 SOA 환경을 구성한다. SOA 보안의 핵심은 정책 기반의 인프라와 정책의 관리이다. 이상적인 경우는 SOA 애플리케이션은 비즈니스 로직에 집중하고 보안 정책들의 실행을 위임하고 인프라의 트러스트 관계를 다루는 것이다. 웹 서비스 보안 스팩에 근거한 웹 서비스 보안 모델과 방식은 서비스 지향 애플리케이션을 보안화 하는 문제들을 해결하는데 도움이 된다.
참고자료 교육
토론
필자소개  | 
| Anthony Nadalin, Chief Security Architect and Distinguished Engineer, IBM |
| 
| Nataraj Nagaratnam, Senior Technical Staff Member, IBM
|
| 
| Maryann Hondo, Web Services Security Standards Lead, IBM
|
기사에 대한 평가
| 
