[ 하둡 인사이드 ] 3. 하둡과 보안

순서

1) 하둡 RPC

2) 하둡 스트리밍

3) 하둡 & 보안

4) 하둡 HDFS 읽기

5) 하둡 HDFS 쓰기

6) 하둡 IO  (Writable / Avro)

7) 하둡 & 가용성  (Zookeeper) 

8) 하둡 쉘 스크립트 및 환경

하둡은 HDFS 라는 분산파일시스템과 맵리듀스라는 그것을 이용하여 계산을 하는 도구를 가지고있습니다.  (YARN 이전) 계산에는 간단한 배치성 작업이 주를 이루며 다양한 머신러닝 알고리즘 (머하웃 라이브러리) 을 실행할수도 있습니다.계산복잡도,알고리즘형태에 따라서  지라프,하마같은 다른 도구를 사용할수도 있으며 , 하둡 YARN 과 함께 다양한 빅데이터 솔루션들이 하모니를 이루고 있습니다. 

Storm-yarn 같은 도구를 사용하여 실시간 분석을 용이하게 할수도있으며, 메모리를 적극적으로 활용한 Spark 라는 제품도 각광을 받고 있습니다.

HDFS : http://www.slideshare.net/madvirus/hdfs-28871456 

Map&Reduce: http://www.slideshare.net/madvirus/ss-29075031 

이전에 하둡 RPC 를 살펴보았고 , 3번째 순서인 보안으로 넘어갑니다. 저도 보안에 대해서 특별히 잘 아는게 아니기때문에 간단히 소개정도의 글이 될거 같습니다. 그리고  하둡  HDFS 의 보안에 한정되며 

하둡 보안관련 이슈중에 일부분만 소개해 드립니다. (다른 에코 시스템들과의 연계같은거 제외) 

하둡 보안을 살펴보기 전에  먼저 일반적인 보안기술 및 자바 보안관련 라이브러리에 대해서 살펴볼 필요가 있습니다. ( 보다 정확한 정보를 위해서는 반드시 스펙문서등을 참고하십시요. 버전마다 차이가 있습니다. ) 

아래 몇가지 개념을 소개하고 있는데  편하게 쭈욱 읽어내려가시면 될거 같습니다.

-  인증 (Authentication)

   접근하려는 사람이 누구인지 확인하는 행위 ( 예: A 는.비밀번호를 확인하여  회원인것을 인증함) 

   커버로스는 인증부분을 책임집니다. ( 오직 인증만, 접근허가 (ACL) 정책은 하둡내에서 구현해야합니다.)

-  인가 (Authorization)

   접근하려는 사람이 어떤 권한을 가지고 있는지 확인하는 행위 ( 예:A 는  /data1  에 접근권한이 있다)  

-  암호화  

암호화 :  어떤 문자열 "hello world"  를  "332XF3FX_*)3" 로 알아보지 못하게 바꾸는것.

복호화 :   "332XF3FX_*)3"  을 다시  "hello world" 로 환원하는것.

-  해쉬함수

"E1FW4OMXF#%FWE()&E32RFEF2F" 이렇게 긴 문장을 

"F3F34"  요렇게 짧게 바꾸는 작업을 말한다. 

해쉬된 문장을 원래 문장으로 바꾸는건 불가능하다.

해쉬를 왜 (why) 하냐면 , 짧으면 무엇이 좋을까?  

1. 암호화, 복호화 할때 시간이 단축된다.

2. 원래 문장을 전송에 사용할 필요가 없어진다. 따라서 비밀번호같은것의 노출을 피할수있다.

   예를들어 비밀번호를 해쉬함수를 통해서 걸러진 문장을 DB 에 저장해두면,  진짜 비밀번호를 

   알수는 없지만, 동일한 비밀번호로부터 나온 결과라는것은 알수있게된다.

MD5 / SHA1 같은것을 사용한다.

-  대칭키 기반 암호화 

  1)  A 와 B 가 있습니다.  A 를 사람 혹은  클라이언트 / B 는  사람 혹은 서버라고 상상해 봅니다.
  2)  A 와 B 는 사이좋게 동일한 "대칭키" 라는 열쇠를 가지고있습니다. 

  3)  A 는 어떤 문서를 대칭키로 암호화 하여 B 에게 보내줍니다.

  4)  B 는 문서를 받아서 자신도 가지고있는 "대칭키" 로 복호화 하여 무슨 말이 써있나 읽어봅니다. 

  

  특징 :  동일한 키를 가지고  암호화/복호화를 한다. 

  단점 :  B 가  "대칭키" 를 가지고있지 않을때 A 가 B 에게 대칭키를 보내주다가, 중간에 탈취당하면...?

  기술 :  암호화 하는 기술에는 AES / DES 같은것들이 있습니다. 

- 공개키 기반 암호화 

   1)  A 와 B 가 있습니다.  A 를 사람 혹은  클라이언트 / B 는  사람 혹은 서버라고 상상해 봅니다.

   2)  A 와 B 는 각각  "공개키" 와 "개인키" 를 생성합니다. 

   3)  A 는 자신의 "공개키" 를  B 에게 보내줍니다.

   4)  B 는 자신의 "공개키" 를  A 에게 보내줍니다.

   5)  A 와 B 는 상대방의 "공개키" 로 자신의 문서를 암호화 하여 보내줍니다. 

   6)  A 와 B 는 자신의 "개인키" 로 상대방이 보낸 문서를 복호화 하면서 서로 통신합니다.

   특징 :  2개의 키가 필요하고, "공개키" 로 암호화 하고 "개인키" 로 복호화합니다.

   단점 :  암호화 / 복호화 하는데 시간이 오래 걸립니다. 그리고 "공개키" 가 상대방것인지 확인불가

   기술:  RSA , DSA 

- SSL / TLS 암호화 

   1)  클라이언트는 서버에게 보안통신을 하자고 요청합니다. (가능한 암호화알고리즘/해쉬함수를  보냄)

   2)  클라이언트가 보낸 리스트중에 서버는 센놈하나를  선택합니다.

   3)  서버는 자신의 공개키가 포함된 전자서명을 클라이언트에 보냅니다.(전자서명은 CA 의 개인키로함)

   4)  클라이언트는 자신의 컴퓨터나 브라우저에 내장된 CA 의 공개키로 서버가 보낸 전자서명을 검증

   5)  클라이언트는 검증후에 전자서명안의 서버의 공개키를 획득합니다.

   6)  클라이언트는 서버의 공개키로 자신이 만든 "대칭키" 를 암호화하여 서버로 보내줍니다.

   7) 서버는 자신의 개인키로 클라이언트가 보낸 "대칭키" 를 복호화합니다.

   8)  클라이언트와 서버는 이제 서로 동일하게 가지고있는 "대칭키" 로 암호화 통신을 합니다.

   특징 :  공개키 기반 암호화에서 상대방의 공개키를 믿을수있게 하기위해  인증서를 도입함. 

              공개키를 통한 핸드쉐이킹 후에는 "대칭키" 를 통해 통신. 

   응용기술 :  HTTP 프로토콜에 SSL 를 더 한것이  HTTPS 

- 커버로스 

   1)  클라이언트는 KDC 에 사용자이름, 클라이언트 비밀키로 암호화한 타임스탬프,  TGT 요청을 보냄.

   1-1)  위에서 클라이언트 비밀키는 패스워드를 해쉬로 산출된 값이다. 그 값은 당연히  KDC 도 보유.  

   2)  KDC 는 그 메세지를 기반으로 클라이언트가 적절한지를 판단한다.

   2-1)  KDC 가 보유한 해당 클라이언트의 패스워드 해쉬값으로 복호화 되면 적절하다고 판단함.

   3) KDC 는 클라이언트에게 TGT 를 발행합니다. 

   3-1) TGT 는 KDC 자신의 비밀키로 암호화 되어져있다. 

   4) KDC 는 클라이언트에게 TGS 와 통신할때 사용할 둘만의 세션키를 발행한다. 

   4-11) 세션키는 클라이언트의 비밀키로 암호화 되어져있다. (세션키와 TGT 는 같게해서 단순화)  

   5) 클라이언트는 TGT 와 클라이언트 비밀키로 암호화한 사용자정보를 가지고 티켓발급이 필요한 

       서비스요청을 한다.

   6) 요청을 받은 KDC 의 TGS 는 TGT 를 자신의 비밀키로 해독하고 세션키로 암호화된 사용자 정보

       를 해독하여 사용자의 신원/타임스탬프를 확인한다.  

   7) KDC 는 해당 서비스와 통신할수있도록 티켓과 클라이언트와 서비스가 통신할때 사용할 둘만의 

       세션키를 클라이언트에게 발행해준다. 

   7-1) 티켓은 서비스키로 암호화, 둘만의 세션키는 클라이언트 비밀키로 암호화.  

   8) 클라이언트는 서비스에  티켓과  사용자 정보를 세션키로 암호화해서 전달. 사용해도 되냐고 함.

   9) 서비스는 티켓을 서비스키로 검증한후에 접근을 허락해줍니다.

 특징: 커버로스는 인증 시스템 입니다. / Single Sign ON (SSO) 

 장점: 1.네트워크를 통한 패스워드의 전송이 없다. 유효기간이 있는 티켓만이 돌아다님.

          2. 서비스들은 모든 클라이언트에 대한 정보를 각자 가지고있을 필요가 없다. 

 단점 :  커버로스의 KDC 가 멈추면 모든게 멈춥니다. (single point of failure) 

           서버간에 시간설정이 일치해야함.

커버로스 인증에 대하여 그림을 통하여 다시 살펴봅시다. ( Hadoop Security 책에서 발췌) 

위 그림에 대한 한글 설명을 하둡 보안이라는 책에서 가져왔습니다. 저 그림과 이 설명에는 몇가지 오류가 있는데 찾아보세요.

1. 클라이언트는 KDC 에 인증부호를 보내 TGT 을 요청한다.

2.  KDC 는 클라이언트에게 TGT 와 세션키를 제공한다. TGT 는 인증된 사용자에게 제공하는 특별 티켓으로 , 모든 서버의 서비스 티켓 발급에 이용된다. 8~10시간후 만료된다. 세션키는 통신에 참여하는 두 파티를 위한 공통키로, 두 파티간 전송되는 데이터의 암호화에 사용된다.

3. 클라이언트는 TGT 를 이용해 서비스 티켓을 TGS 에 요청한다.

4. KDC 는 서비스 티켓과 타겟 서버로 보내는 데이터의 암호화에 사용할 세션키를 제공한다.

   이때 세션키는 타켓 서버만이 자신의 비밀키를 사용해 세션키를 해독하고 사용자와 통신할수 

   있도록 타겟 서버의 비밀키를 통해 암호화된다.  

5. 클라이언트는 타겟 서버와 연결해 TGS 를 제출한다. 서버는 자신의 비밀키를 이용해  TGS 를 해독

    하고 클라이언트를 인증한다.

6. 서버는 세션키로 암호화된 인증 부호를 제공한다. 이제 클라이언트와 서버는 세션키를 비밀키로 공유하고 이키로 필요한 모든 데이터를 암호화한다.

오류1  : TGS 로 부터 받는 정보는 TGT 가 아니라 TGS / 4, 5 번 그림에서 TGT -> TGS

오류 2 :  클라이언트/서버간에 사용될 세션키가 타겟서버만이 자신의 비밀키로 세션키를 해독한다고 하는데 그럼 클라이언트는 세션키를 어떻게 얻을수 있나?? 저 위의 설명만으로는 알수없음.

- 언제 커버로스를 쓰고 언제 SSL 을 쓰나 ? 

  커버로스는 인증을 위해 사용합니다. 독자분의 서버에 여러가지 서비스 데몬이 있다고 칩시다.

  각각의 서비스를  영철이한테 오픈할것과  미숙이한테 오픈할것이 다를경우, 사용합니다. 

  SSL 은  님과 영숙이간에 서로 전화를 할때, 남이 무슨 얘기를 하는지 알수없게 하기위한 검증된

  암호화가 목적입니다. 전혀 사용하려는 목적 및  방법이 다르다는 말이지요. 비교대상은 아닙니다.

- JCA /  JCE   (Java Cryptograpy Architecture)

   자바 플랫폼 상에서 각종 암호화 관련 기능을 제공한다. 암호화 API , 난수생성, 해쉬함수, MAC, 

    전자 서명, 인증서, 키 생성 및 교환 제공. 

   

- JSSE   (Java Secure Socket Extension) 

   자바IO/NIO 를 이용한 소켓통신을 할때 Socket 객체를 이용하지 않은가?

   단지 그 객체를 SSLSocket 으로 바꾸어주면 SSL 로 보호되어진 통신을 할수있게 

   된다. (SSLSocketFactory.getDefault 를 이용하여 생성) 

- JAAS (Java Authentication and Authorization Service)

  위의 JCA 나 JSSE 가 암호화된 통신에 목적이 있다면, JAAS 는 인증과 접근허가등에 관련된 

  기능을 제공한다.

- JAVA SASL  / JAVA GSS-API 

 커버로스 프로토콜등 을 내부적으로 이용하여 , 보안 통신에 대한 API 와 구현을 제공한다.

 하둡에서도 커버로스를 사용할때 SASLServer / SASLClient 등을 사용한다.

특징

APIs and implementations for the following standards-based secure communications protocols: Transport Layer Security (TLS), Secure Sockets Layer (SSL), Kerberos (accessible through GSS-API), and the Simple Authentication and Security Layer (SASL). Full support for HTTPS over SSL/TLS is also included.

장점 

Authenticates peers over an untrusted network and protects the integrity and privacy of data transmitted between them.

오픈소스 하둡 과 보안 

대부분의 오픈소스 솔루션들은 처음부터 보안에 대해 염두해두고 개발되지 않습니다. 그 이유는 당연히

시간때문이겠지요. 자신의 유니크한 아이디어를 돌아가는 솔루션으로 만드는것이 1차 목표가 되는것이지 보안은 후속계획쯤으로 여겨지게 됩니다. 따라서 하둡도 마찬가지로 처음에는 보안부분에 크게 신경을 쓰지 않았으며 , 버전업이되면서 보안로직들이 추가되기 시작했습니다. 하둡을 이용하여 회사내의 데이터에 대해사 의미있는 가치를 창출하였을때 그 데이터에 대한 접근이 아무한테나 허용하면 안되겠지요.  하둡은 처음에는 단순히 실수에의한 데이터분실에 촛점을 맞춰서 간단히 보안을 추가했다면, 현재는 하둡 에코 시스템 및 타 시스템들과의 연동등에 복잡한 보안이슈가 발생하고 있습니다. 

컴퓨터의 사용자 정보/그룹 그 자체로 사용자 인증을 하였으며, 커버로스가 지원된 후에는 커버로스를 통해서 인증을 처리합니다.하지만 그것들은 단지 인증만 처리하므로, 사용자가 어떤 데이터를 사용하는것에 관련된 허가정책은 하둡내에서 따로 구현하고 있습니다. 

1. 각종 설정 사항들 

 

     hadoop.security.authentication 

     

    커버로스 인증을 할것이냐, 기본인증 (Simple) 을 할것이냐 구분한다.

    기본값은 운영체제의 사용자 이름을 이용하여 신분을 확인하는  방식이 사용되어야 한다.  

    (whoami 등을 조작가능) 

    

     hadoop.security..authorization 

    서비스 수준의 권한 부여 활성화. 

     hadoop.rpc.protection = privacy 

   

    하둡 RPC 매커니즘에서 SASL 보안을 지원한다.하둡 클라이언트와 네임노드간의 통신을 보호하고 암호화.

     hadoop-policy.xml 

    

    접근제어목록 (ACL) 을 구성하여 사용자/그룹이 서비스를 사용할수있는지 허가해줌.

     dfs.encrypt.data.transfer = true 

    클라이언트에서 데이터노드로의 데이터 전송에 보안된 데이터 전송을 위해 SASL 래퍼를 사용한다. 

    네임노드와 데이터노드는 비밀키를 공유하는데, 네임노드에서 클라이언트한테 비밀키로 암호화된 세션키

    를 넘겨주어, 그것을 이용하여 인증한다. 

2. 하둡 보안을 위한 설계 요구사항들 

 - 하둡 사용자는 승인받은 데이터에만 접근할수있어야한다.

 - 사용자는 자신의 잡만 읽고, 수정, 중지 

 - 인증한 서비스만이 데이터노드로 등록될수있다.

 - 데이터노드내의 데이터블록접근은 보안이 필요하고, 인증한 사용자만이 하둡 클러스터의 저장된 데이터에 접근할수있어야한다.

 - 하둡 클러스터를 안전하게 보호하기위해 내부 생성토큰을 이용하는데, 데이터접근을 위해서는 블록접근토큰이 필요하다.

3. 하둡 기본 보안 모델 without  커버로스 

하둡은  HDFS에 들어 있는 파일과 디렉터리에 대한 읽기/쓰기 권한을 제한할 수 있다. POSIX 파일 시스템과 유사하게, 사용자와 관리자는 파일/디렉토리에 대한 권한과 소유권 변경을 위해 chmod 와 chown 명령어를 사용할수 있다. 하둡은 사용자 관리 기능을 전혀 제공하지 않는다. 대신 하둡 내의 운영시스템 사용자를 이용한다. 

기본적으로 하둡은 사용자나 하둡 서비스에 대한 어떠한 인증도 지원하지 않는다. 사용자는 로그인 하는 동안 운영체제에만 인증한다. 이후 사용자가 하둡 명령어를 호출할때, 사용자의 ID와 그룹이 whoami / bash -c groups 에 의해 각각 정해진다. 따라서 중간에 스트립트 조작에 의한 권한 강탈이 가능하다.

 

4. 하둡 보안 모델 with 커버로스 

커버로스는 하둡 0.20.20x 버전부터 추가되었다.

1. 모든 하둡 서비스는 KDC 에 자신을 인증한다.

2. 데이터노드를 네임노드에 등록하고. 비밀키를 교환한다. (heartbeat 메세지안에추가)

3. 클라이언트는 KDC 에 자신을 인증하고 TGT 를 요청해서 받는다.

4. 클라이언트는 TGT 를 이용하여 KDC에 서비스 티켓을 요청해서 받는다.

5. 클라이언트는 서비스티켓을 이용하여 네임노드에 파일을 요청한다. 

6. 네임노드 서비스는 클라이언트에 데이터정보(블록ID) 와 블록접근 토큰을 제공한다.

7. 클라이언트는 데이터정보와 블록접근 토큰을 데이터노드에 보내서 실제 데이터를 요청한다.

8. 데이터노드는 블록접근토큰을 통해 인증을 하고 실제 데이터를 찾아서 스트리밍해준다. 

위의 그림은 HDFS 와 함께 맵리듀스에 대한 보안인터렉션을 보여준다.

.... 작성중 ....