728x90
반응형

이 글의 일부는 AWS 공식 문서( 링크 )를 참고하였습니다. 단계별 상세 내용은 해당 문서를 참고하시기 바랍니다.

 

1. 도메인 등록하기

- whois.co.kr 등에서 도메인을 먼저 구매하세요.

 

도메인 네임은 알파벳과 숫자, 그리고 -(하이픈) 으로 구성할 수 있습니다. 도메인은 단순한 조합이 아닌 계층적인 구조로 이루어집니다. 

 

helloworld. co. kr(실제 생성 하실 때는 각자 원하는 이름으로 사용해야 합니다.)로 예를 들어보면... 

 

kr은 1단계로 최상위 도메인으로 국가도메인(kr, us 등)을 나타냅니다.

co는 2단계로 해당 도메인을 운영하는 기관의 성격을 나타냅니다.(co: 기업 , or:비영리기관 등)

helloworld 는 3 단계로 도메인 네임을 사용하는 기관이나 개인이 원하는 이름을 등록합니다. 

1단계의 종류에 따라 계층이 다를 수 있으며, 대표적으로 com 을 사용할 경우 1/2단계만으로 구성되기도 합니다.

위 예에서 없는 프로토콜, 예를들어 www, ftp 등은 발급된 도메인을 어떻게 활용할지에 따라 사용할 수 있습니다. 

 

이 1단계 종류의 인기에 따라 각 도메인 발급 기관은 가격을 다르게 측정하기도 합니다.

참고로 whois의 경우 io의 경우 1년 기준으로 6만원대이고 com의 경우 2만원대입니다. 

 

이후 등록인 정보 / 연장 책임자 정보를 입력 후 결제를 하면 해당 도메인을 소유할 수 있습니다. 

 

 

2. S3에 서비스를 위한 버킷 생성하기

 

S3에 helloworld.co.kr이라는 이름의 루트 도메인 버킷과 www.helloworld.co.kr이라는 이름의 서브 도메인 버킷을 만들어 보겠습니다.

 

루트 도메인 버킷에는 실제 컨텐츠를, 서브 도메인 버킷에서는 루트  도메인으로 리디렉션 되도록 설정해야 합니다. 

 

먼저 루트 도메인 버킷을 생성합니다. AWS S3 Console로 접속해서 helloworld.co.kr라는 이름으로 새로운 버킷을 생성합니다. 생성 시 컨텐츠로 사용될 파일들에 대해서는 퍼블릭 액세스를 허용하기 위해 "모든 퍼블릭 액세스 차단"을 해체하고 생성합니다. 

 

생성이 되었다면 버킷의 "속성" 탭으로 가서 "정적 웹 사이트 호스팅" 을 선택 후 아래와 같이 설정합니다. 해당 탭의 상단에 있는 엔드포인트는 여러분의 컨텐츠로 접근할 수 있는 주소입니다. html 컨텐츠를 업로드 후 이 주소로 접속하여 확인할 수 있습니다. 개인적으로 사용하거나 제한된 용도로 사용할 때는 별도의 도메인 설정없이 이 endpoint만을 사용할 수도 있습니다.

다음으로 "www.helloworld.co.kr"이라는 이름으로 서브 도메인 버킷을 만듭니다. 이 버킷은 루트 도메인 버킷으로 리디렉션하는 용도로 사용합니다. 버킷 생성 후 "정적 웹 사이트 호스팅" 설정에서 "요청 리디렉션"을 선택 후 루트 도메인 버킷 명을 입력하고 프로토콜에는 http를 입력하면 됩니다. 

공식 문서에는 "웹 사이트 트래픽용 로깅 구성"이 있지만, 추후 "구글 애널리틱스"를 예정이기 때문에 이 부분은 넘어가겠습니다. 필요하신 분들은 공식 문서를 참고하세요.

 

이제 "index.html"파일을 생성 후 아래 코드를 삽입합니다. 

<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>My Website Home Page</title>
</head>
<body>
  <h1>Welcome to my website</h1>
  <p>Now hosted on Amazon S3!</p>
</body>
</html>

이 파일을 "루드 도메인 버킷"에 업로드합니다. 

파일 추가 후 "다음" 버튼을 누르고 속성 중 "퍼블릭 권한 관리"에서 "이 객체에 퍼블릭 읽기 엑세스 권한을 부여함"을 선택 후 "업로드"버튼을 선택하여 컨텐츠 업로드를 완료합니다. 

파일 업로드를 할때마다 이렇게 지정할 수도 있지만 버킷의 정책을 변경하는 방법도 있습니다. 버킷의 "권한" -> "버킷 정책"을 눌러 아래 정책을 복사해서 넣고 저장하시면 helloworld.co.kr 에 업데이트되는 모든 컨텐츠를 누구나 읽을 수 있게 됩니다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::helloworld.co.kr/*"
            ]
        }
    ]
}

 

이제 "루트 도메인 버킷"의 엔드포인트와 "서브 도메인 버킷"의 엔드포인트로 접근을 테스트 해보시기 바랍니다. 두 엔드포인트 모두 "루트 도메인 버킷"의 index.html의 내용을 출력한다면 모두 정상적으로 성정된 것입니다.

 

이제 등록한 도메인을 "루트 도메인 버킷"으로 연결되도록 설정해 보겠습니다.

 

3. 도메인 연결하기

 

다시 whois로 돌아가 "내 도메인 자산 관리" 화면에서 "루트 도메인 버킷"으로 연결할 도메인을 선택 후 화면 하단의 "포워딩 서비스"를 선택합니다. 

"루트 도메인 버킷"의 엔드 포인트를 복사해 포워딩 URL에 복사해서 넣은 후 "주소창에 도메인명 유지"를 선택해야 합니다. 

"주소창에 포워딩 URL 표기"를 선택하면 도메인 주소를 입력 후 aws s3의 엔드포인트 주소를 주소창에 출력하게 됩니다.

 

금일 내용 중 "서브 도메인 버킷"을 같이 만들었는데 이어지는 다음 글에서 사용될 예정입니다. 

 

그럼 다음 글에서 다시 뵈요!!

 

 

반응형
728x90
반응형

마지막으로 직접 인증서를 발급하고 이를 개인용 사이트에 적용하는 방법을 상세히 알아보겠습니다. 

 

이 테스트는 CentOS 7.x , OpenSSL, Nginx에서 실행되었습니다.

 

인증서 발급을 위한 준비

 

인증서를 발급한 기록을 위해 두 가지 파일이 필요합니다. 하나는 발급된 인증서의 정보를 기록하는 것과 serial을 기록하는 파일, 이렇게 두 개의 파일을 준비해야 합니다. 

 

touch /etc/pki/CA/index.txt
echo '00' > /etc/pki/CA/serial

추후 인증서를 발급 후 두 파일을 보면 아래와 같습니다.

V    210109061528Z    00    unknown /C=KR/ST=Seoul/O=COMPANY/OU=DEV1/CN=your_domain/emailAddress=your_email@server.com

index.txt 파일에는 언제 어떤 정보를 포함한 인증서가 발급되었는지가 기록됩니다. 

01

serial 파일에는 00 에서 01로 한 개의 인증서가 발급되었다는 것을 확인할 수 있습니다. 

 

 

이제 CA 개인키를 생성합니다.

openssl genrsa -des3 -out ca.key 1024

그리고 CA의 CSR(Certificate Signing Request)을 생성합니다. csr 파일은 공개키와 사용하는 알고리즘 정보가 포함됩니다.

openssl req -new -key ca.key -out ca.csr

이제 Root CA의 인증서를 생성합니다. 

openssl x509 -req -days 1280 -in ca.csr -signkey ca.key -out ca.crt

이제 개인키에서 패스워드를 삭제하겠습니다. 사실 패스워드가 있는게 당연하겠지만, 웹 서버 가동때마다 계속 패스워드를 물어보게 할 수 없으니 일반적으로 삭제하고 사용합니다. 일반적으로 웹 서버들은 모두 패스워드 삭제를 '강요'합니다.

openssl rsa -in ca.key -out ca_key.pem

이로서 CA로서의 준비를 끝났습니다. 이제 웹서버를 위한 준비를 하겠습니다. 

 

웹 서버 인증서 만들기

웹 서버용 개인키를 생성합니다.

openssl genrsa -des3 -out server.key 1024

웹 서버용 CSR 을 생성합니다.

openssl req -new -key server.key -out server.csr

이제 준비가 되었으니 실제 인증서를 발급해 보겠습니다. 이 글은 개인용 인증서를 생성하고 적용하는 내용을 정리한 글입니다. 공인된 CA에 인증서 생성 요청은 필요하다면 추후 별도로 정리해 보겠습니다. (이미 수많은 글들이 있으니 쉽게 구글링으로 확인하실 수 있습니다.)

 

준비된 CA로 인증서를 제작합니다.

openssl x509 -req -in server.csr -out server.crt -signkey server.key -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

웹 서버에 설정하기 위해 웹 서버용 개인키에서 패스워드를 삭제합니다. (안그러면 웹 서버 실행때마다 물어봅니다.)

openssl rsa -in server.key -out server_key.pem

Diffie-Hellman 키 생성하기 

(* Logjam 취약점이 이전에 발표되었으며, 이로 인해 1024bit는 안전하지 않습니다. 꼭 2048 이상으로 사용하시기 바랍니다. 상세 내용은 구글링으로... ^^a)

openssl dhparam -out dhparam.pem2048

 

이제 위에서 생성한 파일들을 /etc/nginx/ssl 폴더를 만들어 넣어두고 아래와 같이 상위 폴더의 보안 설정에 맞춰줍니다.

restorecon -v -R /etc/nginx

 

웹 서버 (NGINX ) 설정하기 

 

nginx 의 설정을 별도로 수정하지 않았다면 /etc/nginx/default.conf 파일을 수정하면 됩니다.

 

# 기존 http도 https로 리디렉션 되도록 설정.
server {	
	listen      80;
	listen      [::]:80;
	server_name your_domain; # ip 일때는 굳이 쓸 필요가 없다.

# 301 moved permanently 응답과 합께 모든 http 요청을 https로 리디렉션한다.
	location / {
		return 301 https://your_domain:443$request_uri;
	}
}

server {
	listen       443 ssl http2 default_server;
	listen      [::]:443 ssl http2 default_server;
	server_name  your_domain; # ip 일때는 굳이 쓸 필요가 없다.

	ssl_certificate /etc/nginx/ssl/ca.crt;
	ssl_certificate_key /etc/nginx/ssl/ca_key.pem;
	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	ssl_dhparam /etc/nginx/ssl/dhparam.pem;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	# Cipher Suites 에 대해서는 이 링크(https://rsec.kr/?p=455)를 참고하세요. 너무 잘 설명해 두셔서 감동이었습니다. -o-b
	ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
	ssl_ecdh_curve secp384r1;

	ssl_prefer_server_ciphers on;
	ssl_stapling off;	# for self-signed cert
	ssl_stapling_verify off; # for self-signed cert

	location ~ /\.ht {
		deny all;
	}
	.
	.
	.

 만약 443이 아닌 다른 임의의 포트를 사용한다면 semanage에 추가해야 합니다. (selinux를 사용하지 않는 상태라면 통과입니다.)

semanage port -a -t http_port_t -p tcp 4430  # 포트 추가하기
semanage port -l | grep http_port_t # 포트 적용되었는지 확인

firewall-cmd --permanent --zone=public --add-port=4430/tcp # firewall에 4430포트 오픈
firewall-cmd --reload # 변경 사항 적용하기

이제 웹서버를 재실행 해보시기 바랍니다. http로 접속하시면 바로 https로 포워딩 되는지도 잘 확인해보시고요.

 

도움이 되셨으면 합니다.

 

모두 새해 복 많이 받으시고 멋진 2020년 되시기 바랍니다.

 

이만  ~~ !

반응형
728x90
반응형

회사 자체에서 사용되는 웹 사이트에 SSL을 도입할 일이 생겼는데, SSL 도입 자체가 처음이라 도입 과정의 내용을 정리해 보았습니다. Self Signed Certificate이라고 하는 용어도 이번에 첨 알게 되었네요. 

 

필요한 사전 내용부터 도입 과정, 예외상항에 대해서 순서대로 정리 보았으니 참고 되시길 바랍니다. 

(* 처음 해보는 거라 잘못된 정보, 오류가 있을 수 있습니다. ^^;;)

알고 가야 할 것들!

SSL(Secure Socket Layer)이 무엇인지는 너무 많은 글들이 있으니 여기서는 SSL 도입에 필요한 요점만 정리하겠습니다. 사실 TLS(Transport Layer Security)지만 SSL이라고 부르기 때문에 그대로 사용하겠습니다. 

 

HTTP와 HTTPS의 차이

HTTP는 평문(텍스트 그 자체!)으로 데이터를 전송합니다. 즉, 전송되는 데이터를 손쉽게 들여다 볼 수 있습니다. HTTPS는 Secure이 붙은 만큼 전송되는 데이터를 볼 수 있다 한들 암호화가 되어 있어서 무슨 내용인지 바로 알 수 없습니다.

 

그럼 서로 주고 받는 데이터를 암호화 한다면 복호화는 어떻게 할 수 있을까요? 보내는 곳에서 암호화한 방법을 알아야 받는 곳에서 복호화를 할 수 있을텐데?

 

세상에는 수많은 사이트가 존재합니다. 서로 데이터를 주고 받기 전에 암호화를 어떻게 할지 미리 알려줘야 하는데(대칭키 방식) 접속할 때마다 자기가 어떤 방법으로 암호화를 하는지 알려줘야 한다면, 이 방법을 알려주는 순간에 해커들이 이 정보를 훔쳐간다면 무용지물이 되겠죠. 그렇다고 사전에 암호화 하는 방법을 서로 미리 정해놓고 공유한다면 이 또한 안전하지도 않을 뿐더라, 암호화 방식이 바뀔 경우 대책이 없게 됩니다.

 

이를 보완하기 위해 개인키/공개키라는 개념이 나옵니다. 

 

Private Key(개인키)/Public Key(공개키)란?

말 그대로 개인키는 나만 가지고 있고, 공개키는 누구에게든 전달할 수 있는 키입니다. 공개키로 암호화된 데이터는 개인키로만 복호화 할 수 있습니다. 이 역도 성립합니다. 개인키로 암호화한 데이터는 공개키로 복호화 할 수 있습니다.

 

(*Private/Public Key 설명을 돕기 위한 그림으로 실제 위와 같이 데이터를 교환하지는 않습니다.)

그래서 공개키로 암호화된 데이터를 아무리 들여다 봐도 개인키를 모르는 이상 복호화 할 수 없습니다. ( 여기서 굳이 양자컴퓨터를 언급하지는 않겠습니다. ;; )

 

그런데 이 그림처럼 통신하기 위해서는 많은 연산이 필요합니다. 이를 해결하기 위해 핸드쉐이킹 단계 (클라이언트가 서버에 처음 연결하여 통신을 준비하는 단계) 에서 실제 데이터 전송을 위한 대칭키를 결정하는 단계에서만 사용됩니다. 이후부터 세션이 종료될 때까지 결정한 대칭키를 이용해 데이터를 교환하고, 세션이 종료될 때 사용한 대칭키는 파기하게 됩니다. 

 

(* 공개키 기법의 Handshaking 과정)

 

분명히 간단히 정리하려고 했는데, 정리 하다보니 정도 모르는 것들이 또 나와서 정리하고 그림도 그리다보니... 

 

조금 길어졌네요.

 

다음 글에서는 우리가 알고 있는 공인인증서는 무슨 역할을 하고, 왜 인증된 기관에서 받아야 하는지 알아보겠습니다.

 

그 후 마지막에는 Self-signed Certificate 작성과 적용 방법에 대해서 정리하고 마무리 하겠습니다. 

 

반응형
728x90
반응형

Unity5 발표 이후 공개된 여러 AssetBundle 관련 문서를 번역하다가 지금까지 알게된 주요 변경 사항들을 정리해봤습니다. 


처음 만져본 unity 버전이 5.0입니다. 현재 패치툴을 만들면서 보고 있어, 아직 발견하지 못하거나 이해가 낮아 잘못알고 있는 내용들이 발견되더라도 양해 바라면 댓글 달아주시면 수정/추가하겠습니다.

1. 5.0에서는 각 Asset (코드 파일 제외)별로 AssetBundle Name과 variant를 지정할 수 있다. 
   (Asset 미리보기 창의 하단에 설정 UI가 있습니다.)

2. name은 해당 Asset이 속할 AssetBundle의 이름이며, 설정 UI에서 선택하거나 새롭게 생성할 수 있습니다. 
   이 과정은 5.0 이전 버전에서는 수동으로 설정을 해야 했기 때문에 상당히 번거로웠으며, 이 작업을 편리하게 도와줄 수 있는 bundle mnager 같은 에셋이 발매되어 있습니다. (* 최근 5.0 버전에 맞게 개선된 버전이 나왔더군요.)

3. variant는 AssetBundle의 이름에 연결된 옵션이며, unity 공식 데모에서는 앱 실행 중 실시간으로 텍스쳐의 퀄리티를 변경할 수 있는 예로 사용되었습니다. 
 (* http://files.unity3d.com/vincent/assetbundle-demo/users_assetbundle-demo.zip를 참고하세요.)

4. 이전 버전에서는 변경되지 않은 Asset들도 모두 빌드되어 패치를 작성하는데 많은 어려움이 있었다고 합니다. (전 첫 unity 버전이 5.0이라 이전 경험자 분들의 이야기를 들어본 바에 의해서 적습니다.) 5.0 버전에서는 변경된 에셋들만 추려서 빌드됩니다. 

5. AssetBundle 이름을 검색하는 기능이 추가되었습니다. 검색 UI에 "b:"를 입력 후 원하는 에셋번들 이름을 넣으면 해당 이름을 가진 모든 에셋을 볼 수 있습니다.

6. 유니티가 직접 종속 관계를 관리하며, 이는 기존에 사용하던 PushAssetDependencies/PopAssetDependcies API를 사용할 필요가 없습니다. (* 공개된 원문에 있던 내용인데, 이전 버전을 사용해보지 않아 와닫진 않네요. ^^;)

이상입니다. 이 외 typetree, 이전 버전과의 혼용 등에 대한 내용들이 있었는데 추후 내용이 파악되면 추가하겠습니다. ^^a


반응형

+ Recent posts