클라우드 도입을 통해서 얻게되는 보안의 장단점이 잘 정리되어 있습니다. 
미 연방 정부의 년간 IT 예산은 2010년에만 거의 8백억 달러로 다른 어떤 조직보다도 많습니다. 예산을 절약하고 서비스를 개선하기 위해 정부는 새로운 대체 시스템을 조달하려고 하며 그 첫 번째 시도로 클라우드를 채택하기 시작했습니다.
from: http://www.ibm.com/developerworks/kr/industry/library/ind-govcloud/index.html
미국의 연간 IT예산이 90조원이 넘는군요. 한국은 2010년 예산이 1.35조로 편성되었었네요. 이미 많은 클라우드 경험을 갖추신 분들이 많겠지만 흐름에 따라 클라우드 서비스를 이용하거나 준비하시는 분들에게 도움이 될 기사입니다.




---

infoQ에 올라온 이슈입니다. 아마존의 EC2를 커맨드라인이 아닌 Web UI를 지원하는 서비스(https://console.aws.amazon.com/)가 얼마 전에 시작되었는데, 이로 인해 해커들이 좋아하게 생겼다는 내용과 그렇지 않다는 지적입니다. 더 적은 수의 인원, 더 나은 도구, 더 나은 프로세스, 그리고 피고용인을 대행하지 않는다는 점입니다. 사실 대부분의 보안 사고는 내부사람을 통해서 발생합니다.

 

구글의 AppEngine, 아마존의 EC2, S3를 포함한 AWS 등 클라우드 컴퓨팅 플랫폼을 제공하는 서비스들이 많아지고 있습니다. 기업의 데이터를 타사의 서버에 올려놓는 것을 달가워하지 않는 경우가 많습니다. 구글 칼렌다가 기능이 아무리 화려하다고 해도 기업의 프로젝트 업무 진행 스케줄을 거기에 올려놓는 것은 무리가 있기도 합니다. 심지어는 칼렌다 검색을 열어놓는 경우도 있습니다. 모르고 말이죠.

 

하지만 모든 기업의 정보가 다 그런 것은 아니겠죠. 외부에서 처리할 만한 것은 외부의 자원을 이용하는 것이 나을 것입니다. NYT가 몇 십 년되는 기사 데이터를 하루 남짓한 시간에 아마존의 서비스를 이용해서 처리한 것은 유명하죠.

 

구글 Apps 서비스salesforce.com의 서비스를 본다면 중소규모의 기업이 쓰기에 저렴하고 안정적으로 사용할 매력적인 서비스입니다. 비슷한 경우가 될 수 있겠지만 대용량의 서비스를 안정적으로 저렴하게 이용하려면 아마존의 AWS는 아주 최고입니다. 하지만 정보 보안 이슈는 제대로 된 명분을 갖고 또 실제적으로도 안전해야 합니다.

 

국내의 보안 현실과 정책은 생각하고 싶지 않습니다. 프로그램으로 모든 게 다 될 줄 알고 만든 법이라는 생각이 들어서 말이죠.


지속적인 통합 툴인 Hudson(https://hudson.dev.java.net)은 기업 내부 즉 인트라넷용입니다. 회사 밖에서는 접근하지 않는다는 것을 기본으로 설정하게 되어있죠. 만약 인터넷 같은 외부에 노출이 되는 경우는 인증을 걸어서 아무나 컨트롤하지 못하도록 하는 것이 중요합니다.

구글에서 "hudson access control"이라고 검색해봤습니다. wiki페이지가 나오는군요.


첫번째 링크를 클릭해서 들어가면 Hudson 보안강화하기 위키페이지가 나옵니다.
http://hudson.gotdns.com/wiki/display/HUDSON/Securing+Hudson

보안 레벨을 다양하게 지원하는데, 토픽은 다음과 같습니다.

Topics


저는 간략하게 설정해 보았습니다. 아직 경험이 많지 않아서 성큼성큼 나아가기 힘드니까요.
Quick and Simple Security 페이지의 설명에서 발췌한 내용입니다.

$ java -jar hudson.war --argumentsRealm.passwd.user=password --argumentsRealm.roles.user=admin

이러한 형식으로 시작 옵션을 줍니다.

$ java -jar hudson.war --argumentsRealm.passwd.kenu=okjsp --argumentsRealm.roles.kenu=admin

user와 password 부분을 변경해 주면 됩니다. 그리고 Hudson 설정에서 보안을 사용한다고 설정해야 합니다.
Hudson 관리(Manage Hudson) > Configure System 메뉴를 선택합니다.

설정화면에서 위쪽 설정 옵션 중 Enable security를 체크합니다. 하단의 옵션은 Delegate  to servlet container 에 그 아래 옵션은 Legacy Mode 를 선택하고 저장하면 됩니다.


설정이 완료되고 옵션을 주어서 시작하면 다음과 같은 메시지를 볼 수 있습니다.


로그인 id별  권한처리도 가능하다 하니 위키 문서를 참고하시면 될 것입니다.

okjsp 사이트의 보안을 강화하기 위해서 작업을 시작했습니다. http://www.okjsp.pe.kr 외 에 https://www.okjsp.pe.kr 접속을 위한 것이죠. 현재 아직 인증서오류가 발생하고 있습니다. 아직 돈을 내지 않았기 때문이죠. ^^; 인증서 에이전시에 등록할 때 10만원 내외의 비용이 필요합니다.

인증서를 신청하기 전에 서버 작업이 필요합니다. 그에 대한 설명입니다.

jdk에는 인증서를 위한 도구가 포함되어 있습니다. keytool 이라는 프로그램입니다. bin 디렉토리 아래 javac와 같이 있죠.

[root@169s /root]$ rm -rf .keystore
[root@169s /root]$ $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
keystore 암호를 입력하십시오: changeit
새 암호를 다시 입력하십시오: changeit
이름과 성을 입력하십시오.
  [Unknown]:  www.okjsp.pe.kr
조직 단위 이름을 입력하십시오.
  [Unknown]:  okjsp
조직 이름을 입력하십시오.
  [Unknown]:  okjsp
구/군/시 이름을 입력하십시오?
  [Unknown]:  Seoul
시/도 이름을 입력하십시오.
  [Unknown]:  Seoul
이 조직의 두 자리 국가 코드를 입력하십시오.
  [Unknown]:  KR
CN=www.okjsp.pe.kr, OU=okjsp, O=okjsp, L=Seoul, ST=Seoul, C=KR이(가) 맞습니까?
  [아니오]:  y

<tomcat>에 대한 키 암호를 입력하십시오.
        (keystore 암호와 같은 경우 Enter를 누르십시오):
[root@169s /root]$


위와 같은 절차를 거치면 root계정의 홈 디렉토리에 .keystore 파일이 생깁니다.

이 파일에서 인증서를 요청하기 위한 Certificate Signing Request (CSR) 파일을 생성합니다.

[root@169s /root]$ $JAVA_HOME/bin/keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr
keystore 암호를 입력하십시오:
[root@169s /root]$ ls cer*
certreq.csr
[root@169s /root]$ cat certreq.csr
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBpzCCARACAQAwZzELMAk.........1IxDjAMBgNVBAgTBVNlb3VsMQ4wDAYDVQQHEwVTZW91
...
-----END NEW CERTIFICATE REQUEST-----


개인정보라 함은 이름, 주민번호, 휴대폰, 이메일 등을 조합해서 해당 사람에 대한 식별이 가능한 정보라고 합니다. SSL을 설치하는 이유는 로그인할 때 비밀번호가 암호화되어서 중간에서 packet sniffer 도구 등으로 탐지되지 않도록 하기 위함입니다.

개인사이트다, 뭐다 말이 많지만 주민번호 받지않는 회원가입이 있고 로그인이 있기 때문에 보안설정은 하는 게 좋을 듯 합니다. 그냥 익명의 사이트로 간다면 글에 대한 신뢰성이 바닥으로 떨어지기 때문입니다.

정보보호진흥원kisa에서 소개해준 업체들 좀 돌아다녀 봐야겠습니다. 싼 거 찾으러 말이죠. ^^;

관련정보: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html

+ Recent posts