[z/OS]

WebSphere Application Server for z/OS에 대한 SSL(Secure Sockets Layer) 보안

이 주제에서는 사용자가 SSL(Secure Sockets Layer) 프로토콜을 이해하고 z/OS®에서 암호 서비스 시스템 SSL이 작동 방식을 이해한다고 가정합니다. SSL은 WebSphere® Application Server에서 여러 컴포넌트가 신뢰 및 프라이버시를 제공하는 데 사용됩니다. 이러한 컴포넌트에는 내장 HTTP 전송, 오브젝트 요청 브로커(ORB)(클라이언트와 서버) 및 보안 LDAP(Lightweight Directory Access Protocol) 클라이언트가 있습니다. SSL 구성은 WebSphere Application Server에서 클라이언트 및 서버 간에 다릅니다. 보호 설정된 통신 및 사용자 인증 보안이 네트워크에 추가되도록 하려면 SSL(Secure Socket Layer) 보안을 사용하면 됩니다.

SSL은 WebSphere Application Server for z/OS가 제공하는 보안의 필수사항입니다. 이는 관리 보안이(가) 사용 가능하면 활성화됩니다. 관리 보안이 사용 가능하면 관리 서브시스템은 항상 SSL을 사용하여 관리 명령, 관리 콘솔 및 WebSphere Application Server 프로세스 사이의 통신 보안을 유지합니다.

다음과 같은 경우 서버 보안이 사용 가능하면 WebSphere Application Server for z/OS 런타임은 선택적으로 SSL을 사용할 수 있습니다.
  • 웹 애플리케이션 보안 제한조건으로 기밀성을 지정한 경우 웹 애플리케이션을 보호하기 위해 SSL을 사용합니다. CONFIDENTIAL 또는 INTEGRAL의 전송 보증은 웹 클라이언트와 웹 서버 간의 통신이 안전하고 HTTP(HTTPS SSL)를 통해 이루어짐을 보증합니다. 또한 애플리케이션 배치 중 보안 제한조건(CLIENT_CERT)을 지정한 경우 SSL을 사용하여 클라이언트 인증을 수행할 수 있습니다.
  • CSIV2(Common Secure Interoperability version 2) 전송 설정에서 SSL/TLS가 지원될 때(또는 필요할 때) IIOP(Inter-ORB Protocol)를 보호하기 위해 SSL을 사용할 수 있습니다. 이는 보안 > 글로벌 보안을 클릭하면 설정됩니다. RMI/IIOP 보안 아래에서 CSIv2 인바운드 전송 또는 CSIv2 아웃바운드 전송을 클릭하십시오.
  • 활성 사용자 레지스트리가 LDAP일 때 LDAP 클라이언트와 서버 사이의 통신을 보호하기 위해 SSL을 사용할 수 있습니다.
SSL 구성 시, WebSphere Application Server for z/OS에는 두 가지 유형의 SSL 레퍼토리가 있습니다. 레퍼토리 유형은 SSL에 사용되는 기본적인 서비스에 관련됩니다.
  • HTTP/SOAP 커넥터를 사용하는 관리 요청의 SSL 레퍼토리 유형으로 JSSE(Java™ Secure Socket Extension)를 선택해야 합니다. JSSE 레퍼토리는 (APAR PQ77586을 적용하여) 키 저장소 또는 신뢰 저장소에 대한 SAF 키 링이나 HFS(Hierarchical File System) 파일을 지정할 수 있습니다.
참고: 디먼에 속하는 것을 제외하고 모든 SSSL(System Secure Sockets Layer) 유형의 SSL 구성 레퍼토리는 JSSE(Java Secure Socket Extension) 유형으로 변환됩니다. 현재 시스템 SSL은 디먼이 JVM 없이 실행되며 JSSE가 Java에서만 지원되므로 디먼 주소 공간에 의해서만 사용됩니다.

이 주제에서는 SSL 프로토콜과, z/OS에서 SSL이 작동하는 방법에 대한 간단한 설명을 제공합니다. SSL 프로토콜에 대한 정보는 웹 사이트(http://home.netscape.com/eng/ssl3/ssl-toc.html)로 이동하십시오.

SSL(Secure Sockets Layer)은 WebSphere Application Server 내에서 여러 컴포넌트가 신뢰 및 프라이버시를 제공하는 데 사용됩니다. 이러한 컴포넌트에는 내장 HTTP 전송, ORB(클라이언트 및 서버) 및 보안 LDAP 클라이언트가 있습니다. SSL 구성은 WebSphere Application Server에서 클라이언트 및 서버 간에 다릅니다. 보호 설정된 통신 및 사용자 인증 보안이 네트워크에 추가되도록 하려면 SSL(Secure Socket Layer) 보안을 사용하면 됩니다. WebSphere Application Server for z/OS에서 SSL을 지원하는 몇 가지의 목적이 있습니다.
  • 메시지가 네트워크에서 이동하는 동안 메시지 보안을 보호하기 위해 업계에서 승인한 방법을 제공하기 위해. 이것을 전송 레이어 보안이라고도 합니다. 전송 레이어 보안(TLS)은 두 개의 통신 애플리케이션 사이의 데이터 무결성 및 기밀성을 제공하는 기능입니다. 보호는 기본 전송 프로토콜의 맨 위(예를 들어, TCP/IP의 맨 위)에 있는 소프트웨어 레이어에서 발생합니다.

    SSL은 암호화 기술을 통해 통신 링크를 거쳐서 보안을 제공함으로써 네트워크에서의 메시지 무결성을 보장합니다. 쌍방 사이에 통신이 암호화되므로 제삼자는 메시지에 관여할 수 없습니다. SSL은 또한 기밀성(메시지 내용을 읽을 수 없도록 보장), 응답 발견 및 순서 이탈 발견 기능을 제공합니다.

  • 다양한 인증 프로토콜이 작동할 수 있는 보안 통신 매체를 제공하기 위해. 단일 SSL 세션은 여러 인증 프로토콜, 즉 통신 관련 측의 ID를 제공할 방법을 제공합니다.
    SSL 지원은 항상 서버가 고유 ID를 제공하는 메커니즘을 제공합니다. WebSphere Application Server for z/OS에서 SSL 지원을 사용하면 클라이언트가 이러한 방식을 사용하여 고유 ID를 증명할 수 있습니다.
    • 기본 인증(SSL 유형 1 인증이라고도 함): 클라이언트는 대상 서버에 의해 알려진 사용자 ID 및 비밀번호(또는 비밀번호 구문)를 전달하여 서버에 대해 고유 ID를 증명합니다.
      SSL 기본 인증으로 다음 사항이 가능합니다.
      • z/OS 클라이언트는 CSIv2 사용자 이름 및 비밀번호 메커니즘 GSSUP(Generic Security Services Username Password)로 정의된 사용자 ID 및 비밀번호를 사용하여 WebSphere Application Server for z/OS와 안전하게 통신할 수 있습니다.
      • WebSphere Application Server 클라이언트는 MVS™ 사용자 ID 및 비밀번호(또는 비밀번호 문구)를 사용하여 WebSphere Application Server for z/OS 서버와 안전하게 통신할 수 있습니다.
      • 요청에서 항상 비밀번호가 필요하므로, 간단한 클라이언트 대 서버 연결만 만들 수 있습니다. 즉, 서버는 요청에 응답하기 위해 다른 서버에 클라이언트 사용자 ID를 전송할 수 없습니다.
    • 클라이언트 인증 지원: 서버와 클라이언트는 모두 서로에게 고유 ID를 증명하기 위해 디지털 인증서를 제공합니다.

      WebSphere Application Server for z/OS에 대한 인증을 위해 디지털 인증서를 제공한 경우, 암호 해독된 인증서는 사용 가능한 사용자 저장소의 유효한 사용자 ID에 맵핑됩니다. 웹 애플리케이션에는 수천 개의 클라이언트가 있으므로 클라이언트 인증 관리가 관리 부담이 됩니다. 로컬 운영 체제가 WebSphere Application Server for z/OS에서 사용 가능한 사용자 저장소인 경우, SAF 인증서 이름 필터링을 사용하면 클라이언트 인증서를 저장하지 않아도 MVS 사용자 ID에 클라이언트 인증서를 맵핑할 수 있습니다. 인증서 이름 필터링을 통해, 사용자는 MVS 사용자 ID를 작성하고 모든 사용자에 대해 클라이언트 인증서를 관리하는 관리 오버헤드 없이 일련의 사용자들에게 서버 액세스 권한을 부여할 수 있습니다.

    • SSL 지원은 항상 서버가 고유 ID를 제공하는 메커니즘을 제공합니다. 다양한 메커니즘을 사용하여 클라이언트 ID를 증명할 수 있습니다. SSL v3 (및 TLS) 프로토콜은 클라이언트 디지털 인증서가 선택적으로 교환되도록 하는 기능을 제공합니다. 이 인증서는 인증에 사용할 수 있습니다.
    • CSIv2 ID 가정검증: z/OS 프린시펄, X501 식별 이름 및 X509 디지털 인증서에 대한 지원이 제공됩니다.
    • ID 가정검증 또는 검증할 수 있는 연관: 중간 서버는 해당 클라이언트의 ID를 안전하면서 효율적인 방법으로 대상 서버에 전송할 수 있습니다. 이 지원에서는 클라이언트 인증서를 사용하여 SSL 세션의 소유자로 중간 서버를 설정합니다. 시스템은 RACF®(Resource Access Control Facility)를 통해 중간 서버를 신뢰할 수 있는지 확인할 수 있습니다(이 레벨의 신뢰를 부여하기 위해 관리자는 배타적으로 보안 시스템 코드를 실행하는 RACF ID에 CBIND 권한을 부여함). 이 중간 서버에서 검증이 확립되면 대상 서버가 클라이언트 ID(MVS 사용자 ID)를 별도로 확인하지 않아도 됩니다. 해당 클라이언트 ID는 인증 요구 없이 신뢰됩니다.
  • 다음과 같은 기타 제품과 안전하게 상호운영할 수 있도록 합니다.
    • z/OS용 CICS®(Customer Information Control System) 트랜잭션 서버
    • 기타 WebSphere Application Server 버전
    • CORBA(Common Object Request Broker Architecture) 호환 오브젝트 요청 브로커

SSL은 기본적으로 사용 불가능하며 SSL 지원은 선택사항입니다. 보안이 작동되는 상태에서 WebSphere Application Server for z/OS를 실행할 경우, 관리 콘솔에서 SSL이 필요합니다. JSSE(Java Secure Socket Extension)는 사용된 SSL 레퍼토리 유형입니다.

표 1. SSL 연결 순서.

다음 표는 SSL 연결의 작동 방식에 대해 설명합니다.

단계 설명
조정 클라이언트가 서버를 찾은 후, 클라이언트와 서버는 통신을 위해 보안 유형을 조정합니다. SSL을 사용할 경우, 클라이언트에는 특수 SSL 포트에 연결하도록 지시합니다.
핸드쉐이크 클라이언트가 SSL 포트에 연결하고 SSL 핸드쉐이크가 발생합니다. 성공하면 암호화된 통신이 시작됩니다. 클라이언트는 서버의 디지털 인증서를 검사하여 서버를 인증합니다.

핸드쉐이크 동안 클라이언트 인증서를 사용할 경우, 서버는 클라이언트의 디지털 인증서를 검사하여 클라이언트를 인증합니다.

진행 중인 통신 SSL 데이터 교환 동안 클라이언트와 서버는 통신 암호화에 사용할 cipher 스펙을 조정합니다.
첫 번째 클라이언트 요청 클라이언트 ID는 선택된 클라이언트 인증 메커니즘(다음 중 하나)에 따라 판별됩니다.
  • CSIv2 사용자 ID 및 비밀번호(GSSUP)
  • CSIv2 검증된 ID

규칙

  • z/OS에서 Java 또는 C++ 클라이언트는 WebSphere Application Server for z/OS 또는 워크스테이션 Application Server와 상호운영 가능하며, SSL을 사용할 수 있습니다. CSIv2 보안은 z/OS에서 Java 클라이언트만 지원합니다.
  • 데이터 교환의 일부는 메시지 보호를 위해 SSL에서 사용하는 암호 스펙을 조정하는 것입니다. 사용되는 cipher 스펙 및 키 크기를 판별하는 두 가지 요소가 있습니다.
    • 시스템에 설치된 암호 서비스의 보안 레벨. 이 레벨은 WebSphere Application Server for z/OS가 사용 가능한 암호 스펙과 키 크기를 판별합니다.
    • 관리 콘솔을 통한 서버 구성을 사용하면 SSL 암호 스위트를 지정할 수 있습니다.
    자세한 정보는 z/OS System Secure Sockets Layer Programming을 참조하십시오.
  • z/OS 시스템 SSL 소켓의 경우 RACF 또는 이와 동등한 기능을 사용하여 디지털 인증서 및 키를 저장해야 합니다. 디지털 인증서와 키를 HFS의 키 데이터베이스에 저장하는 것은 옵션이 아닙니다.
팁: SSL 기본 인증 보안을 정의하려면 먼저 사용자의 서버 인증서를 서명한 인증 기관으로부터 서버에 대해 서명된 인증서와 인증 기관 인증서를 요청해야 합니다. 인증 기관으로부터 서버에 대해 서명된 인증서와 CA 인증서를 수신한 후, RACF를 사용하여 디지털 인증서 사용 권한을 부여하고, 서버 인증서 및 서버 키 링을 RACF에 저장하며, SSL 레퍼토리 별명을 작성한 후 관리 콘솔을 통해 서버의 SSL 보안 특성을 정의해야 합니다.

클라이언트의 경우, 키 링을 작성하여 서버 인증서를 발행한 인증 기관의 CA 인증서를 첨부해야 합니다. z/OS 클라이언트의 경우, RACF를 사용하여 클라이언트 키 링을 작성하고, CA 인증서를 해당 키 링에 첨부해야 합니다. 서버를 인증하려면 클라이언트의 경우, 서버(실제로 제어기 사용자 ID)는 인증 기관에서 작성한 서명된 인증서를 처리해야 합니다. 서버는 서명된 인증서를 전달하여 클라이언트에 대해 ID를 증명합니다. 클라이언트는 서버 인증서를 발행한 동일 인증 기관의 CA 인증서를 전달해야 합니다. 클라이언트는 서버의 인증서가 확실한지 확인하기 위해 인증 기관 인증서를 사용합니다. 확인되면 클라이언트는 메시지가 실제로 다른 서버가 아닌 해당 서버로부터 수신된 것을 보증할 수 있습니다. 클라이언트를 인증할 서버의 경우, 클라이언트가 서버에 대해 고유 ID를 증명하기 위해 전달하는 클라이언트 인증서가 없습니다. SSL 기본 인증 설계에서 서버는 사용자 ID 및 비밀번호 (또는 비밀번호 문구)로 클라이언트를 인증 확인하여 클라이언트를 인증합니다.

디먼의 MVS 사용자 ID에 대한 키 링 작성에 대해서는 디먼 SSL(Secure Sockets Layer)이 사용할 키 링 설정의 내용을 참조하십시오.


주제 유형을 표시하는 아이콘 개념 주제



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