Computer >> 컴퓨터 >  >> 프로그래밍 >> Redis

Redis Enterprise Cloud에서 Java 클라이언트를 위한 SSL 보안 연결 설정 완벽 가이드

들어가며

서버와의 보안 연결을 활용하는 소프트웨어를 개발하는 것은 모든 개발자가 반드시 갖춰야 할 필수 역량입니다. 특정 운영 환경에서 SSL을 사용하지 않기로 결정하더라도, 다루는 모든 서버에 대해 보안 연결을 설정하는 방법은 알아두어야 합니다. 이 글은 Python 개발자를 위해 작성했던 'Python으로 Redis Enterprise Cloud 보안 연결 활성화하기'의 후속편으로, Java 개발자를 위해 준비했습니다.

이 글에서는 Redis Enterprise Cloud와 Java 클라이언트 프로그램 사이에 SSL로 암호화된 연결을 활성화하고, 테스트하고, 구성하는 과정을 단계별로 살펴봅니다. Java 프로그램에서 SSL을 설정할 때 가장 헷갈리는 부분은 바로 인증서와 키를 Java가 이해할 수 있는 형식으로 변환하는 작업입니다. 이 변환 절차는 Java 전용 단계로, 전체 프로세스 중 '테스트'와 '구성' 단계 사이에 끼워 넣게 됩니다.

준비물

아래 도구들을 미리 준비해 두면 Redis에서 SSL 활성화 업무 티켓을 빠르게 닫을 수 있습니다:

  • Redis Enterprise Cloud 계정
  • OpenSSL
  • Java SE JDK
  • Jedis

또한 제공하는 작은 스크립트를 실행할 수 있도록 Bash 셸이 설치되어 있어야 합니다. 사용 중인 운영체제에 Bash가 기본 포함되어 있지 않다면 직접 설치하거나, 스크립트를 선호하는 셸 문법으로 옮겨 적으셔야 합니다.

SSL을 사용하려면 Redis Enterprise Cloud 구독에 SSL 기능이 활성화되어 있어야 합니다. 아직 활성화되어 있지 않다면 Redis 지원팀에 문의하여 기능을 요청해야 합니다. 지원팀 문의 링크는 계정 대시보드의 메인 메뉴에서 찾을 수 있으며, SSL 설정 관련 문서는 Redis Enterprise Cloud 운영 및 관리 가이드에서 확인할 수 있습니다.

SSL vs. TLS

한 가지 짚고 넘어가겠습니다. Python 편 글과 마찬가지로, 이 글에서도 'SSL'이라는 용어를 'SSL' 또는 'TLS'로 보호되는 연결을 모두 포괄하는 비공식적인 관례대로 사용합니다. Redis Enterprise Cloud가 현재(2018년 6월 기준) TLS 1.2 프로토콜을 사용해 연결을 보호하고 있음에도 불구하고, Redis Enterprise Cloud와 Jedis 양쪽 모두 공식 명칭으로 'SSL'을 사용하기 때문에 이 글에서도 그에 맞추었습니다.

1단계와 2단계

처음 두 단계는 Python 클라이언트용 SSL 설정 과정과 동일합니다. 내용을 여기서 반복하지 않고 Python 편 글을 참조하도록 안내하겠습니다. 해당 글에는 어떤 언어에서든 SSL 작업에 유용한 정보가 많이 담겨 있으므로, 계속 진행하기 전에 3단계 직전까지의 내용을 모두 읽어보시기를 권장합니다.

Java의 경우 2단계 이후부터 절차가 달라집니다. 따라서 여기서 '2.5단계'를 추가하여, Redis Enterprise Cloud에서 내려받은 자격 증명 파일을 JavaSE와 원활하게 호환되는 형식으로 변환하는 과정을 소개합니다.

2.5단계: 자격 증명 변환

JavaSE의 표준 구성 요소로서 Oracle은 JCA(Java Cryptography Architecture)를 포함한 다양한 보안 서비스를 제공합니다. JCA는 플러그인 형태의 공급자(provider)가 구현한 보안 서비스를 Java 애플리케이션이 호출할 수 있도록 하는 API 집합을 정의합니다. 애플리케이션은 사용 가능한 어떤 공급자든 자유롭게 선택할 수 있지만(공급자들이 표준 API 이상의 부가 서비스를 제공하기도 합니다), 대부분의 애플리케이션은 JDK에 기본 탑재된 공급자를 사용합니다.

기본 공급자를 사용할 때의 어려움은 Linux SSL 라이브러리에서 인증서와 키를 저장하는 데 널리 쓰이는 PEM 형식을 지원하지 않는다는 점입니다. JCA에서는 자격 증명 자료가 비밀번호로 보호되는 keystore 저장소에 보관됩니다. Java 애플리케이션에서는 일반적으로 두 개의 저장소를 사용합니다. 하나는 문서에서 keystore(키스토어), 다른 하나는 truststore(트러스트스토어)라고 부릅니다. 키스토어에는 클라이언트 소프트웨어의 인증서와 개인 키를 저장하고, 트러스트스토어에는 신뢰할 수 있는 인증 기관(CA)의 인증서를 저장합니다. Redis Enterprise Cloud는 PEM 형식을 사용하므로, 저희는 OpenSSL과 Java Keytool을 활용해 PEM 파일을 Java 클라이언트 프로그램에서 사용 가능한 키스토어와 트러스트스토어로 변환하는 데 필요한 모든 명령을 한 번에 실행해 주는 스크립트를 만들었습니다.

아래의 transmogrify.sh 스크립트는 redis_credentials.zip의 압축을 푼 디렉터리에서 실행해야 합니다. 이 스크립트는 Redis 인증 기관(CA) 인증서(redis_ca.pem)를 사용해 트러스트스토어(redis_truststore.p12)를 생성하고, 클라이언트 인증서(redis_user.crt)와 그에 대응하는 개인 키(redis_user_private.key)를 사용해 키스토어(redisclient_keystore.p12)를 생성합니다. 클라이언트 키스토어는 비밀번호로 보호되지만, 그럼에도 키스토어의 물리적 보안을 위한 별도 조치를 취하는 것이 좋습니다. 키스토어와 트러스트스토어는 특정 Redis 데이터베이스 인스턴스에 접속하는 모든 클라이언트에 배포해야 하므로, 이 파일들을 자격 증명 관리 시스템에 통합하는 것도 잊지 마세요.

JDK9 이전 버전의 Java는 독점적인 JKS(Java KeyStore) 형식을 선호했지만, JDK9부터는 업계 표준인 PKCS12 형식이 기본값이 되었습니다. 이 스크립트는 PKCS12 형식의 저장소를 생성하지만, 필요하다면 store type 옵션과 파일 확장자를 변경하도록 스크립트를 수정하여 JKS 형식을 사용할 수도 있습니다.

3단계: 클라이언트 코드에서 SSL 구성

Java 클라이언트에서 SSL을 활성화하는 마지막 단계는 클라이언트 코드를 수정해 SSL 연결을 수립하도록 하는 것입니다. 샘플 코드는 Redis Enterprise Cloud 인스턴스에 보안 연결을 수립한 후, Redis PING 명령을 전송합니다.

여기서 눈여겨볼 점은, 코드 어디에서도 2.5단계에서 생성한 키스토어나 트러스트스토어를 직접 참조하지 않는다는 것입니다. JCA 공급자의 기본 동작이 서버 인증을 처리해 주며, 우리가 제공해야 하는 것은 키와 인증서 정보뿐입니다. 이는 JCA 공급자가 읽는 시스템 속성으로 설정할 수 있습니다. IDE 애플리케이션 구성 또는 java 명령줄에 다음 매개변수를 추가하고, 시스템에 맞는 경로와 비밀번호로 수정하세요.

키스토어 속성:

  • javax.net.ssl.keyStoreType=PKCS12
  • javax.net.ssl.keyStore=/Users/tague/dev/ssl-testj/redisclient_keyStore.p12
  • javax.net.ssl.keyStorePassword=redis

키스토어 속성은 transmogrify 스크립트로 생성한 키스토어의 유형(형식), 위치, 비밀번호를 지정합니다. 마찬가지로 트러스트스토어 속성은:

  • javax.net.ssl.trustStoreType=PKCS12
  • javax.net.ssl.trustStore=/Users/tague/dev/ssl-testj/redis_truststore.p12
  • javax.net.ssl.trustStorePassword=redis

트러스트스토어의 유형, 위치, 비밀번호를 지정합니다. 마지막 속성인 javax.net.debug=ssl:handshake는 선택 사항으로, 디버깅 정보 출력을 활성화하는 데 사용됩니다.

Jedis에서 SSL을 사용하도록 구성하는 것 자체는 크게 어렵지 않습니다. 다만 PEM 형식의 자격 증명을 Java 키스토어와 트러스트스토어로 변환하는 절차에 익숙하지 않으면 처음에는 다소 부담스럽게 느껴질 수 있습니다.

이 글이 Java 개발자분들께 Python 개발자에게 드린 것과 같은 친절한 입문 가이드가 되었기를 바랍니다. 마지막으로 보안 관련 당부 말씀을 드리자면, 대부분의 조직에는 비밀번호와 개인 키를 관리하기 위한 고유한 정책과 절차가 마련되어 있습니다. 운영팀 및 보안팀의 가이드라인을 준수하고 있는지 반드시 확인하시기 바랍니다.