캐싱 프록시의 SSL(Secure Sockets Layer)

높은 HTTPS 통신량으로, Caching Proxy 서버는 높은 CPU 사용을 발생시킵니다. 환경 변수(GSK_V3_SIDCACHE_SIZE) 및 프록시 지시문(SSLV3Timeout)을 조정하면, 프록시 서버가 로드를 핸들하고 CPU 사용을 줄일 수 있습니다.

SSL 세션 ID는 브라우저 및 서버에서 사용되는 암호화 또는 복호화 키를 포함하여 재사용 가능한 SSL 세션을 식별하고, 새 연결 시 발생하는 불필요한 SSL 핸드쉐이크를 피하기 위해 사용하는데 이는 서버에서 CPU 시간을 많이 소비하기 때문입니다. IBM 의 Global Security Kit (GSKit) 라이브러리는 캐싱 프록시 서버용으로 SSL 세션 ID를 지원하며 SSL 세션 ID 캐시를 포함합니다. 기본적으로, SSL 세션 ID 캐시는 512 항목을 포함하고 있습니다. 항목 한계에 도달하는 경우, 가장 오래된 세션 항목이 제거되고, 새 항목이 캐시에 추가됩니다.

GSK_V3_SIDCACHE_SIZE 환경 변수를 사용하여 SSL 세션 ID 캐시의 기본 크기를 변경하십시오. 변수의 유효한 값은 1 - 4096입니다. 크기를 늘리면 캐시된 SSL 세션을 찾는 데 필요한 찾아보기 시간이 늘어납니다. 그러나 증가된 검색 시간은 SSL 연결을 설정하는 데 필요한 오버헤드와 비교하여 대수롭지 않습니다. 캐시 크기를 늘리면, 프록시 서버가 더 많은 동시 SSL 세션을 처리하고 프록시 서버에 높은 HTTPS 로드가 있는 경우, CPU 사용을 줄일 수 있습니다.

Caching Proxy에는 조정 가능한 지시문 SSLV3Timeout이 있습니다. (참조 : SSLV3Timeout -- SSLV3 세션이 만료되기 전에 대기할 시간을 지정합니다.) 지시문의 기본값은 1000초입니다. 이 지시문은 세션 캐시에서 SSL 세션의 수명을 정의합니다. 수신 SSL 연결이 기존 SSL 세션을 사용하지 않고 세션 수명이 값을 초과하는 경우 해당 세션은 세션 캐시에서 제거됩니다. SSLV3Timeout 값을 일반적인 보안 클라이언트 세션의 길이로 설정하는 것을 권장합니다. 제한시간이 너무 짧게 설정된 경우, 프록시의 성능을 저하시킬 수 있습니다. 이는 여러 SSL 핸드쉐이크가 단일한 보안 세션을 완료하는 것이 필요하기 때문입니다. 그러나, 값이 너무 길게 설정된 경우, 보안 세션의 보안에 지장을 줄 수 있습니다.

캐싱 프록시가 대리 서버로 사용될 때, 클라이언트와 프록시 간 요청 또는 콘텐츠 서버와 프록시 간 요청, 혹은 양쪽 모두의 요청을 보안 소켓 계층(SSL)을 사용하여 안전하게 수행할 수 있습니다. SSL을 사용 가능하게 하려면, 우선 키 데이터베이스를 작성하여 인증을 작성하거나 획득해야 합니다.

애플리케이션 서버 배포판에는 키 및 인증서를 관리하기 위한 IBMGlobal Security Kit (GSKit) 유틸리티가 포함되어 있습니다. 자세한 내용은 키 및 인증서 관리를 참조하십시오.

키 데이터베이스와 인증서가 설정된 후, 대리 프록시 서버에 SSL을 구성하려면 구성 및 관리 양식에서 프록시 구성 → SSL 설정을 선택하십시오. SSL 설정 양식에서 SSL 사용 가능 상자를 선택한 후 해당 필드에 키 링 데이터베이스 파일 및 비밀번호 파일의 경로 이름을 입력하십시오. 선택적으로, SSL 세션의 시간 종료 값을 지정할 수 있습니다 (키 재작성에 너무 많은 시간이 소요되면 SSL V3 세션의 시간 종료 필드에 시간 종료 값을 증가시키려 할 수 있습니다).

또한 보안 요청의 컨텐츠를 캐시하려는 서버 시도 여부를 지정할 수 있습니다. 캐시로 성능을 개선할 수 있지만, 민감한 자료를 캐시하면 보안 위험을 초래할 수 있습니다. 캐싱 필터를 사용하여 보안 요청에서 캐시되는 파일 유형을 제어할 수 있습니다. 이를 위해 를 사용하는 URL에 대한 https:// 필터를 생성합니다. (캐싱 필터를 지정하려면 양식에서 구성 및 관리 를 선택하십시오 캐시 구성 –> 캐싱 필터.) 프록시 서버에 대한 SSL 캐시 설정은 클라이언트 시스템이나 컨텐츠 서버 시스템과의 연결 여부에 상관없이 프록시 서버에서 종료된 모든 연결에 영향을 줍니다.

MASK  ALL@"9.38.[100-192,202,203].[0-255]", @"9.38.[0-99],193-201,204-255].
[0-255]",@"[0-8,20-255].[0-37,39-255].[0-255].[0-255]"

전방향 프록시 설정에서는 SSL 터널링만 사용 가능합니다. SSL 터널링을 활성화하려면 구성 및 관리 양식에서 프록시 구성 → 프록시 설정을 선택하십시오. SSL 터널링 선택란을 선택하십시오.

CONNECT 메소드(기본적으로 사용 불가능함)가 또한 SSL 터널링 접속을 위해 사용 가능해야 합니다. 구성 양식에서 이를 활성화하려면 서버 구성 ( Server Configuration ) → 요청 처리(Request Processing)를 선택하고 요청 처리 방법( HTTP ) 양식을 사용하십시오.

키 데이터베이스는 하나 이상의 키 쌍 및 인증서를 저장하기 위해 서버가 사용하는 파일입니다. 모든 키 쌍과 인증에 하나의 키 데이터베이스를 사용하거나 여러 데이터베이스를 작성할 수 있습니다. 키 관리 유틸리티는 새 키 데이터베이스를 작성하고 비밀번호 및 스태쉬 파일을 지정하는 데 사용됩니다.

새 키 데이터베이스를 작성할 때 지정한 비밀번호는 개인용 키를 보호합니다. 개인용 키는 문서에 서명하거나 공용 키로 암호화된 메시지를 해독할 수 있는 유일한 키입니다.

키 데이터베이스 비밀번호는 자주 변경하는 것이 좋습니다. 그러나 비밀번호의 만기 날짜를 지정한 경우에는, 비밀번호를 변경한 시기의 기록을 보존하십시오. 비밀번호가 변경하기 전에 만기되면 오류 로그에 메시지가 작성되고 서버가 시작되지만, 보안 네트워크 연결은 작성할 수 없습니다.

프록시와 LDAP 서버 간 SSL 연결의 경우, pac_keyring.pwd 파일에 키 데이터베이스 비밀번호를 입력하십시오. (pac_keyring.pwd 파일은 iKeyman에서 생성된 숨김 파일이 아닙니다.)

이 프로시저를 통해 기본적으로 신뢰할 수 있는 인증 기관으로 지정된 인증 기관으로부터 이메일로 인증을 받으십시오. 인증 기관 서명된 인증을 발행하는 인증 기관이 키 데이터베이스에 있는 인증 기관이 아니면, 우선 인증 기관의 인증을 저장하고 인증 기관을 신뢰할 수 있는 인증 기관으로 지정해야 합니다. 이렇게 하면 데이터베이스로 인증 기관 서명된 인증을 받을 수 있습니다.

신뢰할 수 있는 인증 기관이 아닌 인증 기관으로부터 인증 기관에서 서명한 인증을 수신할 수는 없습니다. CA 인증서 저장하기를 참조하십시오.

인증 기관 서명된 인증을 키 데이터베이스로 수신하려면 다음을 수행하십시오.

1. 키 관리 유틸리티를 시작하십시오.
2. 메인 메뉴에서 키 데이터베이스 파일 > 열기를 선택하십시오.
3. 열기 대화 상자에 키 데이터베이스 이름(기본값 key.kdb를 승인)을 입력하십시오. 확인을 누르십시오.
4. 비밀번호 프롬프트 대화 상자에서 비밀번호를 입력하고 확인을 클릭하십시오.
5. DB 유형 목록의 파일 이름이 올바른지 확인하십시오.
6. 키 데이터베이스 창에서 개인 인증을 선택한 후, 수신을 클릭하십시오.
7. 파일의 인증 수신 대화 상자에서, 인증 파일 이름 텍스트 필드에 base 64-encoded 유효 파일의 이름을 입력하십시오. 확인을 누르십시오.
8. 키 관리자 유틸리티를 종료하려면 메인 메뉴에서 키 데이터베이스 파일 > 종료를 클릭하십시오.

신뢰할 수 있는 인증 기관이 서명한 인증만 보안 연결이 이루어지도록 허용됩니다. 신뢰할 수 있는 인증 기관 목록에 인증 기관을 추가하려면, 신뢰할 수 있는 인증으로 획득 및 저장해야 합니다.