웹 서비스에 대한 보안 고려사항

웹 서비스 보안을 구성하는 경우, 결과가 광범위한 공격 메커니즘에 취약한지를 확인하는 데 모든 노력을 기울여야 합니다. 웹 서비스 보안 시 발생 가능한 보안 고려사항이 있습니다.

WebSphere® Application Server에서 SOAP 메시지 내 연관된 토큰, 무결성 및 기밀성을 사용 가능하게 하는 경우, 보안이 보장되지 않습니다. 이 보안 고려사항 목록은 완전하지 않습니다. 사용자 환경에 대한 고유 보안 분석을 수행해야 합니다.

  • 메시지의 새로운 정도 확인
    메시지의 새로운 정도는 메시지가 캡처되고 다시 전송되는 다시 반복 공격에서 자원을 보호하는데 관여됩니다. 서명된 메시지가 캡처되어 다시 전송될 수 있으므로 디지털 서명 자체가 다시 반복 공격을 방지할 수 없습니다. 메시지가 오픈 네트워크를 통해 교환 시, 메시지 수신자가 메시지 다시 반복 공격을 감지할 수 있도록 허용하는 것을 권장합니다. 이러한 용도로 웹 서비스 보안 스펙에 설명된 다음 요소를 사용할 수 있습니다.
    Timestamp
    시간소인 요소를 사용하여 메시지를 계속 추적하고 이전 메시지의 다시 재생을 감지할 수 있습니다. WS-Security 2004 스펙은 사용자가 주어진 기간동안 시간소인을 캐시하도록 권장합니다. 가이드라인으로서, 다시 재생을 감지하는데 최소 기간으로 5분을 사용할 수 있습니다. 만기된 시간소인을 포함하는 메시지는 거부됩니다.
    Nonce
    Nonce는 UsernameToken 프로파일에 있는 <UsernameToken> 요소의 하위 요소입니다. 각 nonce 요소에 고유한 값이 있으므로 받는 사람이 보다 용이하게 다시 반복 공격을 감지할 수 있습니다.
    문제점 방지 문제점 방지: 시간소인 요구사항을 사용하여 반복 공격으로부터 가장 높은 안전성을 구하려면 시간소인 및 난스(nonce) 둘 모두에 서명해야 합니다. 그렇지 않으면, 이러한 요소가 쉽게 대체되므로 다시 반복 공격을 방지할 수 없습니다.gotcha

    시간소인에 대한 자세한 정보는 시간소인을 참조하십시오.

    WebSphere Application Server는 IncludeTimestamp 정책 어설션을 적용합니다. 하지만 다수의 서비스 제공자는 요청에 해당 <wsu:Timestamp> 요소가 필요하지만 응답에 해당 요소를 전송하지 않습니다. 응답에는 보안 헤더도 없고 시간소인도 없을 수 있습니다. IncludeTimestamp가 정책에 있지만 응답에 시간소인이 리턴되지 않는 경우 클라이언트에서 다음의 오류가 발생합니다.
    CWWSS5730E: 필수 시간소인을 찾을 수 없습니다. 
    이 문제를 해결하려면 시간소인을 전송하도록 서비스 제공자를 구성하거나 WS-Security 정책 바인딩에서 com.ibm.wsspi.wssecurity.consumer.timestampRequired 사용자 정의 특성을 false로 설정하여 시간소인이 필요하지 않도록 클라이언트를 구성하십시오. 자세한 정보는 웹 서비스 보안 사용자 정의 특성의 내용을 참조하십시오.
  • 잠재 보안 틈새를 방지하도록 XML 디지털 서명과 XML 암호화를 적절히 사용

    웹 서비스 보안 2004 스펙이 SOAP 헤더에서 XML 디지털 서명과 XML 암호화를 사용하는 방법을 정의합니다. 따라서 사용자가 엔티티에 가능한 위협과 기타 보안 메커니즘의 컨텍스트의 XML 디지털 서명과 XML 암호화를 이해해야 합니다. XML 디지털 서명의 경우, 일반적으로 디지털 서명 사용과 특히 XML 디지털 서명으로 야기되는 모든 보안 영향을 인지하고 있어야 합니다. 디지털 서명을 기반으로 애플리케이션에 신뢰를 빌드하는 경우, PKI(Public Key Infrastructure)를 기반으로 하는 인증 신뢰 유효성 검증과 같은 기타 기술을 통합해야 합니다. XML 암호화의 경우, 공통 데이터 항목에 걸친 디지털 서명과 암호화의 조합이 일부 비밀번호 표기법의 취약성을 초래할 수도 있습니다. 예를 들어, 디지털 서명된 데이터 암호화 시, 디지털 서명을 일반 텍스트로 두고 공격이 예상되는 일반 텍스트에 취약하도록 메시지를 방치할 수도 있습니다. 일반적으로, 데이터가 암호화되는 경우, 데이터의 서명 또는 모든 요약을 암호화하십시오. 자세한 정보는 http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-Encrypt의 내용을 참조하십시오.

  • 보안 토큰의 무결성 보호

    토큰 대체 공격의 가능성이 있습니다. 이 시나리오에서, 디지털 서명은 종종 보안 토큰으로 파생되고 메시지에 포함된 키를 사용하여 확인됩니다. 토큰이 대체되면 수신자가 예상과는 다를 수 있는 대체 키를 기반으로 하는 메시지를 승인해야 할 수도 있습니다. 이 문제점의 가능한 솔루션 중 하나는 서명된 데이터와 함께 보안 토큰(또는 서명 키가 파생된 고유하게 식별된 데이터)에 서명하는 것입니다. 일부 경우에, 신뢰 권한이 발행한 토큰이 서명됩니다. 이러한 경우, 무결성 문제점이 없을 수도 있습니다. 그러나 애플리케이션 시맨틱 및 환경이 시간이 지남에 따라 변경될 수도 있지만 최선의 실천 방법은 이 공격을 예방하는 것입니다. 배치 환경에 따라 위험 평가를 사정해야 합니다.

  • 인증 경로 확인과 인증 취소 목록을 활용하도록 인증 확인

    디지털 서명에 사용된 토큰 ID의 유효성 또는 인증이 적절히 신뢰되었는지 확인하도록 권장합니다. 특히, X.509 토큰의 경우, 이 문제점은 인증 경로 확인과 CRL(Certificate Revocation List) 사용에 관여됩니다. WebSphere Application Server 버전 6 이상의 웹 서비스 보안 구현에서 인증은 <TokenConsumer> 요소에 의해 확인됩니다. WebSphere Application Server는 Java™ CertPath 라이브러리를 사용하는 X.509 인증의 기본 구현을 제공하여 인증을 확인 및 유효성 검증합니다. 구현에서, CRL의 명시적인 개념이 없습니다. 적절한 루트 인증 및 매개체 인증은 파일로만 준비됩니다. 정교한 솔루션의 경우, 온라인 CRL 데이터베이스 또는 OCSP(Online Certificate Status Protocol)을 사용하여 인증 및 CRL 확인을 수행하는 고유의 TokenConsumer 구현을 개발할 수도 있습니다.

  • 비밀번호를 포함하는 사용자 이름 토큰 보호

    사용자 이름 토큰의 비밀번호를 보호 조치 없이 다운스트림 서버에 전송하지 않도록 권장합니다. SSL(예: HTTPS)과 같은 전송 레벨 보안을 사용하거나 웹 서비스 보안의 XML 암호화를 사용하여 비밀번호를 보호할 수 있습니다. 보호의 선호 메소드는 사용자 환경에 따라 다릅니다. 그러나 공격에 취약하지 않음을 확신하는 일부 특수 환경에서 일반 텍스트로 비밀번호를 다운스트림 서버에 전송할 수도 있습니다.

웹 서비스 보안은 단지 XML 디지털 서명 및 XML 암호화를 사용 가능하게 하는 것보다 더 많은 작업을 필요로 합니다. 웹 서비스를 적절하게 보안하려면 PKI에 대한 지식이 있어야 합니다. 필요한 보안의 양은 배치 환경 및 사용법 패턴에 따라 다릅니다. 그러나 웹 서비스 보안에는 일부 기본 규칙과 우수 사례가 있습니다. PKI에 관한 일부 서적을 읽고 WS-I(Web Services Interoperability Organization) BSP(Basic Security Profile)에 관한 정보도 읽도록 권장합니다.


주제 유형을 표시하는 아이콘 참조 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_secconsider6wssec
파일 이름:rwbs_secconsider6wssec.html