Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

이번 장에서는 미들웨어 커넥션을 안전하게 하기 위한 두가지 방법을 설명할 것이다. 이 두가지 옵션은 Transparort Layer Security(TLS)를 사용하며 TLS 는 Secure Sockets Layer(SSL)의 강화된 버전이다.

미 들웨어 보안 옵션은 브로커에 연결하는 부분을 제어한다.  어떠한 큐와 토픽에 대해서 노드가 읽고 쓸 수 있는지는 P103의 "Authentication and Authorization"에서 설명한 authorizationEntry 설정에서 제어를 한다.

MCollective 는 자체적으로 authorization 시스템을 가지고 있으며 어떤 Mcollectiev 요청이 어떤 서버에 적용할 수 있는지는 p163의 "Authorization"에서 설명을 한다.

미들웨어 시큐리티는 오직 노드가 브로커에 연결할 수 있는지 없는지, 통신에 암호화를 할 것인지 말것인지를 제어한다.

TLS 는 pre-arranged symmetric key 를 가지고 암호화해서 트래픽을 보호한다. 이 키는 쌍방간의 트래픽을 암호화 할 때 사용한다. 각 사이드의 TLS 연결은 각 사이드의 X.509 인증서를 통해서 검증을 할  수 있다. 이러한 asymmetric cryptography 은 데이터를 보내기 전에 서로 통신을 하기에 적절한지 를 확인한다.

은 행 웹사이트에 접근을 할 때 브라우저는 웹사이트가 정말로 은행 사이트인지를 검증하기 위해 암호화 확인을 한다. 브라우저에서 확인할 수 있고 신뢰할 수 있는 authority 에 의해 사인된 은행의 공개 키(X.509 인증서)를 가지고 있는지를 확인한다.

은 행 웹사이트에서는 일반적으로 현재 쓰고 있는 브라우저에서 당신이 누구인지를 증명하기 위해 인증서를 제공하는 것은 필요로 하지 않지만 이것은 적절한 TLS 설정이다. username 과 비밀번호 대신에 TLS 암호화에 의해서 보호가 되었는지만 의존을 한다.

TLS 암호화를 하기 원한다면 다음의 설정을 이해하는 것이 필요하다:

  • Anonymous TLS : MCollective 노드와 미들웨어 간에 암호화를 하는 간단한 방법을 제공. 웹 클라이언트가 안전한 웹사이트에 접근할때와 같이 클라이언트가 적절한 TLS 인증서를 가지고 있을 필요는 없다. secure session 이 설정이 되고 end-to-end 암호화를 통해 연결에 사용하는 사용자 이름과 비밀번호를 보호한다. (Figure 11-1).

Figure 11-1. TLS encryption without client TLS certificates

  • CA-Verified TLS : 암호화된 전송 뿐만 아니라 MCollectiev 노드와 미들웨어 간에 암호화된 인증을 지원한다. 모든 MCollective 노드는 미들웨어에 접근하기 위해 미리 사인된 TLS 인증서를 가지고 있어야 한다. 이러한 설정을 통해서 미들웨어에 대한 보안을 강화한다. (Figure 11-2).

Figure 11-2. TLS encryption with bidirectional TLS certificate verification

    • CA-Verified TLS 를 활성화 하기 위해서는 두가지 부분이 있다. trusted server 와 trusted clients 이다.

어떻게 두가지 옵션을 설명하는지 확인을 해보자.

Anonymous TLS

장점

단점

Puppet Module Setup

이 책에서 제공하는 Puppet module을 쓴다면 다음과 같이 설정을 하면 된다.

hiera 를 이용할 경우

또는 puppet manifests 에서 수정을 할 경우

수동 설정하기

테스팅

CA-Verified TLS Servers

MCollective 노드와 미들웨어 간에 TLS 키와 인증서로 암호화된 통신을 하는 방법이다.

장점

단점

Setup Paths

TLS using Puppet CA

Puppet 모듈을 이용할 경우 다음과 같이 구성을 함.

또는

TLS using Another CA

keyStore 와 trustStore 검증하기

CA-Verified TLS Clients

각 클라이언트 요청은 연결을 하기 위해서 자신의 인증서을 가지고 있어야 한다. 가장 일반적인 방법은 각 사용자별로 각자의 인증서를 만드는 것이다. 각 팀별로 인증서를 생성해서 오직 해당 팀만 private key 에 접근 할수 있도록 하는게 좋겠다. 이 방법 외에 다른 방법을 찾을 수도 있을 것이다. 어찌되었든 검증하고자 하는 유일한 entity 별로 TLS 인증서를 만들어야 한다.

Clients of the Puppet CA

클라이언트 인증서를 생성하는 방법 중 한가지는 Puppet master 에서 인증서를 생성하여 원하는 시스템으로 복사하는 방법이다. 그렇지만 이렇게 하려면 각 사용자는 Puppet master 에 root 권한이 필요하다.

Create a Puppet keypair on the client node

저자는 특정 로그인 사용자에 대하여 다음과 같이 작업을 하는 것이 쉽다는 것을 발견하였다. (해당 사용자의 private key 는 다른 사람에게 노출이 되면 안된다)

Puppet Master 의 관리자 권한으로 다음과 같이 해당 사용자에 대한 인증서를 사인한다.

사용자는 다음와 같은 명령을 실행하여 자신만의 key, cert 와 CA를 가질 수 있다.

이 러한 에러는 적절한 반응이다. --no-daemonize --no-client 옵션은 Puppet 이 실행되는 것을 방지하기 위해서 필요하다. 이러한 옵션을 제공하지 않으면, Puppet aget 는 기본 catalog 로 실행을 하려고 할 것이다. 일반 사용자로 로그인을 했다면 문제를 일으키지는 않겠지만 이러한 상황을 피하는 것이 좋을 것이다.

Change the client configuration

클 라이언트가 자신의 키를 쓰도록 하기 위해 개인적인 설정 파일을 만들어야 한다. MCollective 클라이언트에서 찾는 기본 파일 이름은 사용자 홈 디렉토리의 .mcollective 이다. 명령어 라인에서 -c config 옵션을 통해서 다른 설정 파일을 지정할 수도 있다.

각 사용자의 ~/.mcollective 에 다음을 설정한다.

만 략 Puppet 으로 관리하는 시스템에 root 권한으로 접근을 할 수 있는 사용자가 있다면 그 사용자는 해당 노드의 Puppet 인증서로 미들웨어에 접근이 가능할 것이다. 왜냐하면 동일한 Puppet CA에 의해서 사인을 한 적절한 인증서 이기 때문이다. 그래서 MCollective 의 authorization 이 매우 중요한 이유이다.

나는 이것이 보안 문제라고 생각하지 않는다. 어떤 노드가 pupet 환경에 있다면 미들웨어에 접근할 수 있도록 허용하는 것이 맞을 것이다. If users have root access, then the server login to the middleware is visible to them anyway. 그래서 client 패스워드와 permissions 가 다른지를 확인하는 것은 매우 중요한 부분이다.

Clients Using Another CA

Change the Client Configuration

결론

ActiveMQ 브로커에 연결하는 노드를 안전하게 보호하는 방법은 두가지가 있다.

  • Anonymous TLS 암호화는 암호화된 키를 만들기 위해 오직 서버 인증서만 사용한다. 이것은 웹사이트에서 사용하는 방식이며 구현이 간단한다.
  • CA-Verified TLS 암호화는  쌍방향 authentication 을 제공하는 것으로 동일한 CA 로 사인을 한 각자의 인증서에 따라서 서로를 확인한다. 이경우 모든 서버와 클라이언트를 위해 단일한 키와 인증서로 사인을 하는 것이 필요하다.

이러한 두가지 방법을 통해 네트워크를 통해서 정보가 스니핑 당하지 않도록 로그인 정보와 MCollective 정보를 보호할 수 있다.

Labels
  • No labels