학습자료(~2017)/네트워크

[암호화] SSL on ISC, Part 1: SSL은 무엇이며, 왜 이것을 사용해야 하는가? - IBM

단세포소년 2012. 1. 12. 17:59
반응형

출처 : http://www.ibm.com/developerworks/kr/library/ac-iscssl1/index.html


인터넷 같은 오픈 통신 네트워크를 통한 데이터 보안은 개발자와 사용자들에게는 큰 걱정거리이다. 따라서, 여러분이 사용하고 있는 제품에 보안 환경을 설정하는 것이 매우 중요하다.

Netscape Communications와 RSA Data Security가 합동으로 개발한 Secure Sockets Layer (SSL)는 효율적인 방식으로 이러한 보안을 이룩할 수 있다. SSL은 암호화, 인증서 기반 인증, 구축된 네트워크 연결을 통한 보안 협상을 제공하고, 많은 기업들과 제품들은 자신들의 통신 프로토콜에 SSL을 채택하고 있다.

본 시리즈에서는, 다음 두 가지 주제를 집중 조명하기로 한다:

  1. 상세한 SSL 작동 방법
  2. Integrated Solutions Console Versions 5.1과 Versions 6.0.1 환경에서 SSL이 실행되는 방법

이 글에서는 SSL을 연구하고, 이것이 왜 Integrated Solutions Console 환경에 구현되어야 하는지 그 이유를 설명한다. 본 시리즈 Part 2와 Part 3에서는, Integrated Solutions Console Versions 5.1과 Versions 6.0.1에서 SSL을 구현하여 실행하는 단계별 가이드를 제공한다.

먼저, SSL이란 무엇인가?

SSL이란 무엇인가?

SSL은 TCP/IP를 사용하는 두 개의 통신 애플리케이션 간 프라이버시와 무결성을 제공하는 프로토콜이다. 클라이언트와 서버를 오고 가는 데이터는 시메트릭 알고리즘을 사용하여 암호화 된다.

퍼블릭 키 알고리즘(RSA)는 암호 키들의 교환과 디지털 서명에 사용된다. 퍼블릭 키 암호는 메시지를 암호화 하는데 사용되는 두 개의 키들을 사용하는 알고리즘을 정의한다. 하나의 키가 메시지를 암호화 하는데 사용되면, 다른 키는 암호 해제에 사용된다. 하나의 키(퍼블릭 키)를 공개하고 다른 키(개인 키)는 숨겨서 안전한 메시지를 받을 수 있다.

디지털 인증서

SSL에서 중요한 역할을 하는 디지털 인증서에 대해 알아보자. 디지털 인증서는 두 가지 목적을 갖고 있다:

  • 소유자의 신원 확인
  • 소유자가 퍼블릭 키를 사용할 수 있도록 함

디지털 인증서는 신용 기구 -- 인증서 기구 (CA) -- 에서 발행하며, 제한된 시간 동안에만 발행된다. 만료일이 지나면, 디지털 인증서는 교체되어야 한다. SSL은 키 교환, 서버 인증, 클라이언트 인증에 디지털 인증서를 사용한다.

디지털 인증서에는 인증서 소유자의 신분과 인증서 기구에 대한 정보가 포함되어 있다:

  • 소유자의 이름.
  • 소유자의 퍼블릭 키.
  • 디지털 인증서가 발행되었던 날짜.
  • 디지털 인증서가 종료하는 날짜.
  • 발행 기구의 이름이다. CA의 기구명이다.
  • 발행 기구의 디지털 서명.

SSL 연결은 http:// 대신 https://로 시작하는 URL을 사용하여 클라이언트에 의해 시작된다.

SSL 인증서 유형

SSL은 인증서를 사용하여 연결을 확인한다. 이러한 SSL 인증서는 보안 서버에 놓이고, 데이터를 암호화 하고 웹 사이트를 확인하는데 사용된다. SSL 인증서는 그 사람이 속해 있는 사이트를 확인하고, 인증서 보유자에 대한 정보, 인증서가 발행되었던 도메인, 인증서를 발행했던 Certificate Authority의 이름을 포함하고 있다.

다음은 SSL 인증서를 얻을 수 있는 세 가지 방법이다:

  1. Certificate Authority(CA) 인증서를 사용한다.
  2. 자가 서명 인증서를 사용한다.
  3. 더미 인증서를 사용한다.

Certificate Authority(CA) 인증서 사용하기

Certificate Authority는 업계의 신임을 받는 기구이며, 인터넷 인증서를 발행하고 있다. 대표적인 예로 VeriSign을 들 수 있다. CA 서명 인증서를 획득하려면, 충분한 정보를 CA에 제공하여 CA가 여러분의 신원을 확인할 수 있도록 해야 한다. CA는 새로운 인증서를 만들고, 이것을 디지털 서명을 한 다음, 여러분에게 제공한다. 대중적인 웹 브라우저들은 특정 CA에 의해 서명된 인증서를 신임하도록 미리 설정되어 있다. 클라이언트가 SSL을 통해 인증서가 발행된 서버로 연결하기 위해 추가적인 클라이언트 설정이 필요 없다.

자체 서명 인증서 사용하기

자가 서명 인증서는 사용자가 생성한 인증서이다. 자가 서명 인증서를 사용할 때, 인증서 발행자는 주제와 같다. 이 솔루션의 강점은 CA 서명 서버 인증서를 획득하는 것보다 자가 서명 서버 인증서를 만드는 시간이 덜 걸린다는 점이다. 하지만, 자가 서명 인증서는 SSL 연결을 통해 인증서를 설치하는 서버로 연결된 클라이언트가 인증서의 서명자를 신임하도록 설정되어야 한다. 인증서는 자가 서명되었기 때문에, 서명은 클라이언트의 트러스트 파일에 있지 않으므로, 추가되어야 한다. 모든 클라이언트의 트러스트 파일에 액세스 하는 것이 비현실적이라면, 이러한 설정을 사용하지 않는다. 대신 CA 서명 인증서를 얻어야 한다. 자가 서명 인증서는 서버와 인터랙팅 하는 클라이언트가 인증서를 신임하도록 설정될 수 있을 때에만 유용하다.

더미(dummy) 인증서 사용하기

멍청이(dummy) 인증서를 뜻하는 것이 아니다. 일반적으로 더미 인증서에는 지정된 환경에 SSL을 설정하고 그 기능을 테스트하는데 임시적으로 사용될 수 있는 플레이스홀더로서 작동하는 "가상의" 정보를 포함하고 있다. Integrated Solutions Console은 더미 인증서와 서버 및 클라이언트 트러스트와 키 파일을 제공한다.

그러면 이제, 인증서를 얻은 후에는 어떻게 할까?

클라이언트/서버 인증

인증서를 획득한 후에는 인증을 받아야 한다. 두 가지 유형의 SSL 인증이 있다:

  • 서버 측 인증
  • 클라이언트 측 인증

SSL 서버 인증은 서버의 신원을 확인할 수 있도록 한다. SSL을 실행하는 클라이언트 소프트웨어는 퍼블릭 키 암호라는 표준 기술을 사용하여 서버의 인증서와 퍼블릭 ID가 유효하고, 신임을 받는 CA의 클라이언트 리스트에 있는 인증서 기구에서 발행된 것인지를 검사한다. 만약 사용자가 네트워크를 통해서 신용 카드 번호를 보내고, 서버가 이를 받았는지 검사하고 싶을 경우 이와 같은 확인은 중요하다.

SSL 클라이언트 인증은 사용자의 신원을 서버가 확인할 수 있도록 한다. 서버 인증에 사용되었던 것과 같은 기술을 사용하여, SSL을 실행하는 서버 소프트웨어는 클라이언트의 인증서와 퍼블릭 ID가 유효하고, 신임을 받는 CA의 클라이언트 리스트에 있는 인증서 기구에서 발행된 것인지를 확인한다. 만약 서버가 기밀 금융 정보를 고객에게 보내고 있는 은행이고, 수신자 신원을 확인해야 하는 경우 이러한 확인은 중요하다.

그림 1은 이러한 프로세스를 시각적으로 묘사한 다이어그램이다:


그림 1. 클라이언트/서버 인증
The client/server authentication dance

키 파일(Key file) 대 트러스트 파일(Trust file)

WebSphere® Application Server에 의해 사용되는 SSL은 SSL 키 파일에는 개인 인증서를, 트러스트 파일에는 서명자의 인증서를 저장한다. 키 파일에는 인증서 모음이 포함되어 있는데, 각각 신원을 확인하기 위해 SSL 연결 초기화 동안 제공된다. 트러스트 파일에는 믿을 수 있는 것으로 간주된 인증서 컬렉션이 포함되어 있고, 제공된 인증서는 SSL 연결 초기화 동안 매치되어 신원을 확인한다.

SSL과 WebSphere Application Server

SSL 구현의 좋은 예는 IBM® WebSphere Application Server에 있다. 층을 이룬(layered) 보안 아키텍처에 보안이 구축된다. (그림 2)


그림 2. WebSphere Application Server의 보안 레이어
WebSphere Application Server의 보안 레이어

Network Security 레이어는 전송 레벨 인증과 메시지 무결성과 암호를 제공한다. 분리된 WebSphere Application Server 서버들간 통신은 SSL과 HTTPS를 사용하도록 설정될 수 있다. 또한, IP Security와 Virtual Private Network (VPN)는 메시지 보호에 사용될 수 있다.

SSL 프로토콜은 전송-레이어 보안-인증, 무결성, 기밀성-을 WebSphere Application Server의 클라이언트와 서버 간 보안 연결에 제공한다. 이 프로토콜은 TCP/IP 위, HTTP, LDAP, IIOP 같은 애플리케이션 프로토콜 밑에서 실행되며, 전송 데이터에 트러스트와 프라이버시를 제공한다. 클라이언트와 서버의 보안 설정에 따라서, 다양한 레벨의 트러스트, 데이터 무결성, 프라이버시가 확립된다. SSL의 기본 연산을 이해하는 것이 올바른 설정에 매우 중요하며, 클라이언트와 애플리케이션 데이터에 바람직한 보호 레벨을 확립할 수 있다.

다음은 SSL에서 제공하는 일부 보안 기능들이다:

  • 데이터 암호는 데이터가 와이어를 통해 흘러가는 동안 민감한 정보가 노출되는 것을 방지한다.
  • 데이터 서명은 데이터가 와이어를 통해 흘러가는 동안 수정되는 것을 방지한다
  • 클라이언트와 서버 인증은 올바른 사람 또는 머신과 통신하고 있다는 것을 확인해 준다.

SSL은 엔터프라이즈 환경에서 효과적인 보안이 될 수 있다.

SSL은 WebSphere Application Server 내에서 다중 컴포넌트에 의해 사용되어 트러스트와 프라이버시를 제공한다. 이러한 컴포넌트들은 HTTP 전송, ORB, 보안 LDAP 클라이언트다.

WebSphere Application Server에서 사용되는 SSL 구현은 IBM Java™ Secure Sockets Extension (IBM JSSE) 또는 IBM System SSL이다. IBM JSSE 프로바이더에는 SSL과 Transport Layer Security (TLS) 프로토콜을 지원하는 레퍼런스 구현과 애플리케이션 프로그래밍 인터페이스(IP) 프레임웍이 포함되어 있다. IBM JSSE 프로바이더에는 Java 2 플랫폼의 서명 관련 Java Cryptography Architecture (JCA) 기능을 위한 RSA 지원, 일반 SSL과 TLS cipher 수트, X.509 기반 키와 트러스트 매니저, JCA 키스토어 인증서용 PKCS12 구현을 제공하는 표준 프로바이더가 포함되어 있다.

JSSE 프로바이더 설정은 대부분의 다른 SSL 구현(예를 들어, GSKit) 설정과 비슷하다. 두 가지 차이점을 주목하라:

  • JSSE 프로바이더는 SSL 키 파일의 서명자와 개인 인증서 스토리지를 지원하지만, 트러스트 파일이라고 하는 개별 파일도 지원한다. 트러스트 파일에는 서명자 인증서만 포함될 수도 있다. SSL 키 파일에 모든 개인 인증서를 두고, 서명자 인증서는 트러스트 파일에 둔다. 개인 인증서만 보유할 수 있을 정도의 메모리를 가진 저렴한 하드웨어 암호 장치가 있을 경우에 이 같은 방식이 적당하다. 이 경우, 키 파일은 하드웨어 장치를 의미하고, 트러스트 파일은 서명자 인증서의 모든 것을 포함하고 있는 디스크 상의 파일을 의미한다.
  • JSSE 프로바이더는 플러그인에 의해 사용되는 상용 SSL 키 파일 포맷((.kdb 파일)을 인식하지 않는다. 대신, JSSE 프로바이더는 Java Key Store (JKS) 같은 표준 파일 포맷을 인식한다. SSL 키 파일은 플러그인과 애플리케이션 서버 간 공유되지 않는다. 더욱이, 키 관리 유틸리티의 다른 구현은 애플리케이션 서버 키와 트러스트 파일을 관리하는데 사용되어야 한다.

SSL과 Integrated Solutions Console

Integrated Solutions Console은 콘솔 모듈을 호스팅 및 통합할 수 있는 일반적인 웹 기반 관리 콘솔 프레임웍을 제공하여, 사용자들은 특정 IBM 제품들 보다는 솔루션을 관리한다. 이 프레임웍에는 포틀릿 컨테이너, 자바 관리 애플리케이션, Eclipse Help 모듈이 포함되어 있다.

SSL은 기밀성과 암호를 제공하도록 설정될 수 있다. 클라이언트 브라우저와 Integrated Solutions Console 서버 간 통신은 SSL을 사용하여 보호된다. Integrated Solutions Console이 폼 기반 인증을 사용하고, 이것은 로그인 동안 전송되는 사용자 ID와 패스워드를 암호화 하지 않기 때문에 암호화는 중요하다. 콘솔 모듈이 보안 연결을 통해 백엔드 리소스에 액세스 해야 한다면, 포틀릿은 SSL을 사용할 수 있다.

SSL이 중요한 이유?

왜 이것이 문제가 되는가? 오픈 통신 채널을 통해 안전하게(효과적으로) 데이터를 전송하는 것은 현대적인 IT 시스템을 관리하는데 있어 필수적인 요소이기 때문에, SSL은 이러한 보안을 확립하는데 도움이 되는 강력한 프로토콜이고, Integrated Solutions Console 환경에서 SSL을 실행하는 것은 복잡하고 도전이 되는 태스크가 될 수 있다. 왜 도전이 되는가? Integrated Solutions Console 같은 웹 기반 애플리케이션 환경에서의 데이터 보안은 초보자에게는 약간 모호해 보인다. IT 보안 자체가 광범위한 주제이고, 오픈 통신 네트워크에서 다양한 측면들을 다루고 있기 때문이다.

나머지 기술자료에서는 Integrated Solutions Console 기반 환경에서 SSL 중심의 데이터 보안을 설명하도록 하겠다. Integrated Solutions Condole 5.1 (더미, 자가 서명, CA 인증서 포함)용 SSL의 설정과 실행을 설명한 다음, Integrated Solutions Console 6.0.1에 똑 같은 것을 설정하는 방법을 설명하겠다.


참고자료

교육

제품 및 기술 얻기

반응형