분산 웹 서비스와 JWT

들어가며

6월 컬럼 에서, 분산 시스템에서 인증 처리를 위해서 토큰을 사용하는 부분에 대해서 다뤘다.

많은 웹 서비스들이 외부 서비스와 연동할 이유로, 혹은 외부에 API를 제공하기 위해서 OAuth 토큰을 지원한다.

즉, 이렇게 API 공급하는 쪽이,

  • 사용자를 인증하는 일
  • 인증한 사용자가 특정 API를 호출하는 일

두 가지를 쉽게 분리해서 처리할 수 있게 해준다.

인증/접근 토큰의 한계

이전 컬럼에서도 잠시 다뤘듯이, 토큰은 용도가 용도다 보니 다른 용도로 쓸 때는 부적당할 때가 있다.

  • 토큰에 대한 메타 정보가 포함되어 있지 않다.
  • 토큰이 정말로 발급자가 발급한 것인지 바로 확인할 수 없다.

이걸 확인하기 위해서, 발급자에게 토큰에 대한 정보를 확인해, 필요한 메타 정보를 얻고, 정말로 유효한 토큰인지 확인한다. 이 중에서 유효성 확인 부분은 토큰에 대한 전자 서명이 있는 경우에는 별도 통신 없이도 확인할 수 있다. 하지만 표준화된 방법이 있는 것은 아니라서, 널리 쓰기는 쉽지 않다.

지연 시간 문제

토큰을 확인하기 위해서 별도로 통신하는게 어떤 문제인지 생각해보자.
발급자에게 토큰을 확인한다면 다음과 같은 방식으로 통신이 이뤄진다.

Token 기반 메시지 흐름

인증 서버와 API 서버가 토큰을 확인하기 위해 통신하는 4, 5에서 걸리는 지연 시간이 전체 성능에 영향을 준다.
즉, 클라이언트는 순수하게 API호출을 위해 사용하는 시간에 더해서 4, 5 단계에 걸리는 시간 — 두 서버가 같은 네트워크에 있다면 1ms 정도, 서로 다른 네트워크라면 수십-수백 ms 정도 — 의 지연 시간을 겪게 된다.

JWT 를 OAuth 토큰으로 사용하기

JSON Web Token

RFC 7519 JSON Web Token (JWT) 에서는 JWT를 다음과 같이 설명한다.

JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.

  • 두 주체 사이에 전달할 용도의 가볍고, URL 에 사용하는데 문제 없게 특정 사항을 표현할 수 있는 방법
  • 이 JWT의 내용은 서명 (MAC) 을 포함한 JWS 나 암호화한 JWE 에 담아서 넘긴다.

이 두 가지 부분을 통해서 위에서 말한 두 가지 한계를 극복할 수 있다.

  • 즉 JWT의 내용 (claim) 에 메타 데이터를 넘길 수 있다.
  • JWS 서명 혹은 JWE 암호화를 이용해서 보낸 주체가 보낸 것을 변조하지 않았음을 알 수 있다.

어떻게 이런 용도로 쓰는지에 대해선 뒤에서 다시 설명하도록 하겠다.

JWT barer 토큰을 OAuth 인증 용도로 이용하기

RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants 에서는 아예 이런 용도로 쓰는 것에 대해서 제안하기도 했다.

예를 들어, POST https://api.example.com/v1/token.oauth2 가 있다면 다음과 같은 요청을 전송한다.

POST /v1/token.oauth2 HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0.
eyJpc3Mi[...생략...].
cC4hiUPo[...생략...]

JWT가 해결하는 문제들

JWT를 API 호출에 이용하기

우선 간단한 예로, 좀 더 단순하고, JWT 원래 목적에 좀 더 부합하게 bearer token 으로 API에 써보겠다.
예를 들어 GET https://api.example.com/v1/cat/ 이라는 APi가 있다고 치자.

GET /v1/cat/ HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: bearer eyJhb[...생략...].eyJpc[...생략...].cC4hi[...생략...]

이런 형식으로 호출하면 고양이 목록을 보내준다고 치자.

JWT 구조

Auth0 의 JWT 페이지 를 이용해서 디버깅해보면 쉽게 따라갈 수 있는 내용이다.
우선 JWT는 세 부분으로 이뤄져 있다.
JWT (JWS) 토큰 하나는 eyJhbGciOiAiUlMyNTYiLCAidHlwIjogIkpXVCJ9.eyJp[...생략...].rnHW[...생략...] 처럼 생겼다.
이 내용은 . 을 기준으로 세 부분으로 분리해서,

  • JOSE header (JSON object signature and encryption header)
  • Claim: JWT 가 포함하는 내용에 대한 것
  • Signature: JWT 헤더와 claim 부분에 대한 서명 (MAC)

이렇게 구분하며, 각각 base64 (URL safe한 변형) 으로 인코딩되어 있다.
흔히 쓰는 (표준) base64 대신에 URL safe 한 변형 — / 대신 _, + 대신 - 를 사용 — 을 쓰는 것은, JWT 가 URL의 일부 (GET param 이라거나)나 HTTP header 로 넘기려는 목적이라서다.

Header

JOSE 헤더를 보면,

{
"typ": "JWT",
"alg": "RS256"
}

대부분 간단한 두 가지 내용만 포함된다. 우선 이게 JSON web token이라는 typ 필드. 그리고 어떤 방식의 서명을 쓰는지에 대한 alg 필드가 있다. 여기서는 RSA + SHA2 (256) 을 사용한다. 가능한 algorithm (=alg) 에 대해서는 서명 부분에서 다시 설명하겠다.

참고로, compact 한 표현형을 쓰는게 표준의 목적이라, 정의하고 있는 필드 명은 대부분 짧다. (3자이하)

Claim

토큰이 어떤 내용 을 가지고 있는지에 대한 부분이다. 꼭 필요한 필드는 따로 없으며, 대부분 포함하는 필드 — 예를 들어 만료 시간인 exp — 가 있기는 하다.. 예를 들면, 아래와 같은게 가능하다.

{
"iss": "john.doe",
"aud": "client-id",
"iat": 1212050400,
"exp": 1512054000,
"permissions": [{"type": "cat", "action": ["read", "create", "updtae"]}]
}

발행 주체 (iss) 가 아무개이고, 만료 시간은 12-01이다. 위에 보이는 permissions 는 따로 표준으로 정하는 주체가 없는 private claim 이라고 부르는 맘대로 정해서 쓴 부분이다. (iat, aud 등도 흔히 쓰이는 공개 필드이지만, 여기서의 설명은 생략한다.)

Signature

서명이라고하기엔 조심스러운게, 여기에 올 수 있는 것은 전자 서명이 아니라 MAC (메시지 인증 코드; message authentication code) 다. 그래서 알고리즘에 따라서는
메시지가 변경되었는지 (tampered) 확인하려면 인증 서버에 다시 물어봐야할 수 있다.

여기서 alg 에 해당하는 알고리즘으로 사용하는 것은

  • HS256: HMAC + SHA256
  • RS256: RSA + SHA256
  • ES256: ECDSA + SHA256

같은 값이다. (MAC 알고리즘과 HASH bit 수에 따라 몇 가지 버전이 더 있다.)
이 중 RS256, ES256 만 전자 서명 알고리즘이고, HS256은 HMAC 알고리즘이다. 만약 HS256 혹은 이와 유사한 알고리즘을 쓰면 발행 주체와, 토큰 처리하는 주체가 같은 비밀 값을 공유해야 서명을 처리할 수 있다. (공개키 서명 방식인 RS256, ES256 같은 류는 공개키만 미리 전달받으면 직접 검증할 수 있다)

JWT + 공개키 서명을 쓴 경우의 흐름

JWT 공개키 서명 처리

이전 다이어그램과 비교해보면 토큰 확인을 위해서 인증 서버와 API서버가 통신하는 부분이 빠졌다.
JWT claim 을 해석하고 서명을 검증하는 작업은 수십-수백 us 정도의 작업이라, 이전과 비교하면 지연 시간에 상당한 이득이 있다.

문제 해결

즉, 위 내용의 claim 으로 메타 정보가 없는 문제를 해결한다.
그리고 (특정 서명 알고리즘에 한해서) 원격 서버에 다시 물어보지 않고도 토큰이 올바른지 확인할 수 있다. 다만 exp 부분을 써서 만료 시한을 따로 관리하지 않는다면 이 부분은 문제가 될 수 있으니 구현할 때 확인해보길 권장한다.

맺으며

일정 규모 이상의 게임 서비스든 웹 서비스든, 우리가 만드는 시스템은 더 많은 요청을 처리하기 위해서 결국 분산 시스템의 형태를 갖게 된다.
컴퓨터 공학의 많은 문제가 “추상화 계층”을 추가하는 방식으로 문제를 해결하는데 (혹은 숨기는데), 여기서도 인증 부분을 별도 서비스로 분리시키는 방법을 쓰는 경우가 흔하다.
이런 서비스 간 분리가 있으면 필연적으로 통신에 따른 지연 시간이 문제가 되는데, 표준화된 토큰인 JWT와 공개키 서명 방법을 이용해서 어느 정도 이 문제를 줄일 수 있다.

 

아이펀팩토리 김진욱 CTO

[G-STAR 2017] B2B관에서 아이펀팩토리를 만나세요!

 

11월 16일부터 부산에서 열리는 국내 최대 게임쇼, G-STAR 2017에 아이펀팩토리가 참가합니다!

★ 서버 개발, 무엇이든 물어보세요!  아이펀팩토리 부스 이벤트(B2B관 3층 #T09)

아이펀팩토리 부스에서는 현재 제작 중인 게임의 서버에 대한 궁금증을 속 시원하게 날려줄 ‘서버 무료 컨설팅’과 함께 다양한 이벤트가 준비될 예정이랍니다. 이벤트 참여하시고 알찬 선물 받아 가세요! 

★ 네이버 클라우드 플랫폼 세미나 – 아이펀팩토리 세션 진행!

11/16(목) 벡스코 제1전시장에서 열리는 네이버 클라우드 플랫폼 세미나에서는 ‘클라우드 환경에서 게임서비스 개발/런칭 쉽게 하기’라는 주제로 아이펀팩토리의 세션이 진행됩니다. 많은 참여 부탁드립니다!


홍보디자인_뉴스레터_블로그_사이즈수정

Jenkins 와 Unity3D 의 headless build 를 이용한 build 자동화

이 번 글에서는 Unity 로 만들어진 프로젝트를 Jenkins 를 통해 빌드 자동화 하는 것을 알아보도록 하겠다.
이 예제에서는 Mac 에 설치된 Unity 를 호출해서 빌드하는 것을 가정한다. 전체 흐름은 다음과 같다.

1. Jenkins 의 빌드 번호 등 빌드 환경 정보를 JSON 파일로 저장한다
2. Jenkins 가 Unity 의 editor script 를 batch mode 로 실행하고, editor script 는 앞의 JSON 형태의 정보를 넘겨 받아 빌드 결과물을 생성한다.
3. Jenkins 에서 Google drive 나 windows 공유 폴더 등에 결과물을 복사한다.
4. 팀원들이 다 같이 즐겁게 새 빌드를 플레이한다.

아래에 각 단계별로 좀 더 자세한 설명을 하도록 하겠다. 설명 중에 인용되는 코드는 좀 더 쉽게 읽히게 하기 위해서 에러 처리 등을 제외하고 단순화시켰다.

Step 1. 빌드 정보를 JSON 파일로 넘겨주기

빌드 자동화를 하게 되면 여러 빌드 파일이 생성되는데 이를 구분하기 위해서는 각 결과물에 빌드 번호를 포함하는 것이 편리할 것이다. 빌드 번호는 Jenkins 가 자동으로 생성해주는데, 이 정보를 활용하기 위해서는 Jenkins 의 빌드 번호 정보를 뒤에서 설명하는 Unity script 에 넘겨줄 필요가 있다. 여기서는 간단하게 JSON 파일 안에 빌드 정보를 포함하게 하고 Unity script 에서 이를 읽어서 빌드 번호를 추출하는 것으로 하겠다.

먼저 Jenkins 상에서 새로 아이템을 만들어준다.
Jenkins 설정에 따라 소스 저장소를 모니터링 하다가 새로 소스 저장소에 커밋되는 내용이 있으면 자동으로 빌드 아이템이 실행되게 할 수도 있고, 아니면 몇시간에 한 번씩 주기적으로 빌드를 만들어내게 설정할 수도 있다. 이 부분은 Jenkins 의 표준적인 설정 환경이니 Jenkins 매뉴얼을 참고하길 바란다.

해당 아이템에서 shell command 설정 부분이 핵심적인 부분인데, 다음과 같은 내용을 포함시킨다.

cat > convert.py <<EOF2
import json

conf = {}
conf[‘build_number’] = $BUILD_NUMBER
conf[‘apk’] = {
 “sdk_relative_path” : “NVPACK/android-sdk-macosx”   # android sdk 의 주소를 기입한다.
}

print json.dumps(conf, indent=2)
EOF2

python ./convert.py > build_config.json2
mv build_config.json2 build_config.json

그리고 나서는 별도의 shell command 로 아래에 설명되는 Unity editor script 를 호출해준다.

<code>
/Applications/Unity/Unity.app/Contents/MacOS/Unity -batchmode -logFile build.log -projectPath \$PWD -quit -nographics -executeMethod iFunFactoryEditorScript.BuildApk
</code>

Step 2. Unity editor script 에서 빌드 번호 받아서 실제 APK 파일 생성하기

Unity 의 Assets/Editor 디렉토리 아래 ScriptableObject 를 상속받은 C# class 를 포함하는 C# 스크립트를 추가함으로써 editor script 를 포함시킬 수 있다.

아래는 아이펀팩토리에서 사용되는 ifunfactory.cs 내용이다. 앞 단계에서 호출한 BuildApk 라는 함수가 static 으로 선언된 것을 확인할 수 있을 것이다.

1

우리는 이 스크립트에서 앞서 JSON 으로 넘겨준 build 번호를 넘겨 받아서 PlayerSettings 에 세팅함으로써, 최종 생성될 APK 에 포함될 version 번호를 지정할 수 있다.
아래는 이 코드의 예시이다.

<code>
JSONClass conf = JSON.Parse(System.IO.File.ReadAllText(“build_config.json”)).AsObject;
JSONClass backup = new JSONClass();

int build_number = conf[“build_number”].AsInt;
PlayerSettings.bundleVersion = “1.0.0.” + build_number;

JSONClass apk_conf = conf[“apk”].AsObject;
PlayerSettings.Android.bundleVersionCode = conf[“build_number”].AsInt;

string product_name = PlayerSettings.productName;
string output1 = product_name + “-” + conf[“build_number”].AsInt + “-unaligned.apk”;
string apk_name = product_name + “-” + conf[“build_number”].AsInt + “.apk”;
</code>

이제 기본적인 준비가 끝났으니 실제 APK 를 생성한다. 이 과정은 다음과 같이 BuildPipeline.BuildPlayer() 를 호출하는 것만으로 가능하다. 이 때 첫번째 인자로 빌드할 scene 의 리스트를 문자열 배열로 넘겨준다.

<code>
string[] scenes = [“scene1”, “scene2”];
BuildPipeline.BuildPlayer(scenes, output1, BuildTarget.Android, BuildOptions.None);
</code>

그런데 생성되는 APK 는 jarsigner 와 zipalign 을 거쳐야된다. 그렇기 때문에 다음과 같은 코드를 추가한다.

<code>
// Runs jarsigner on the generated apk file.
UnityEngine.Debug.Log(“Running jarsinger”);
Process jarsigner = new Process{StartInfo = new ProcessStartInfo{FileName = “jarsigner”, Arguments = “-verify -verbose ” + output1, UseShellExecute = false, RedirectStandardOutput = true}};
jarsigner.Start();
jarsigner.WaitForExit();

// Makes the generated apk file aligned.
UnityEngine.Debug.Log(“Running zipalign”);
string android_sdk_path = Environment.GetFolderPath(Environment.SpecialFolder.Personal) + “/” + apk_conf[“sdk_relative_path”].Value;
Process zipalign = new Process{StartInfo = new ProcessStartInfo{FileName = android_sdk_path + “/tools/zipalign”, Arguments = “-f -v 4 ” + output1 + ” ” + apk_name, UseShellExecute = false, RedirectStandardOutput = true}};
zipalign.Start();
zipalign.WaitForExit();
</code>

이렇게 생성된 APK 파일은 빌드 번호가 파일 이름에도 포함되고, 실제 apk 를 설치했을 때도 제대로 된 build 번호가 표시될 것이다.

끝으로 Jenkins 의 post-build action 으로 apk 파일을 archive 하게 해서 Jenkins 상에 저장할 수 있다. 여기까지로 작업을 완료할 수도 있지만, 만일 공유 폴더로 파일을 복사하고 싶은 경우 Jenkins 상에서 별도의 shell command 로 cp 명령을 추가해주면 된다.

단순한 Jenkins script 와 Unity editor script 로 손쉽게 unity project 의 빌드 자동화를 완성했다. 유사한 방식으로 APK 뿐만 아니라 iOS 용 IPA 를 생성하는 것도 가능한데, 이 부분은 여러분이 직접 시도해보면 좋을 것 같다.

아이펀팩토리 문대경 CEO

[유니티 로드쇼 2017] 아이펀팩토리가 전국 개발자 여러분을 찾아갑니다!

아이펀팩토리가 ‘유니티 로드쇼 2017(Unity Roadshow 2017)’의 외부 강연자로 전국의 개발자 여러분을 찾아갑니다!

오는 10월 17일 부산을 시작으로 전국 6개 도시에서 개최되는 유니티 로드쇼에서 아이펀팩토리가 함께 하는 기술 강연! 생생한 개발 실무와 노하우를 들을 수 있는 기회를 놓치지 마세요!

★ 강연시간: 전국 6개 지역 14:50~15:20
★ 강연제목:
쾌적한 서비스 운영을 위한 모니터링 시스템 구축
★ 강연소개:
게임 서버의 성능 지표 모니터링은 실제 라이브 단계에서 뿐만 아니라, 게임 출시 전 스트레스 테스트 단계에서 잠재적인 병목을 찾아내기 위해서도 필요한 기능입니다. 성능 지표 모니터링은 크게 OS 수준에서의 성능 지표, 서버 프로세스 수준에서의 성능 지표, 그리고 게임 수준에서의 성능 지표로 구분할 수 있습니다. 이 발표에서는 이 중 내부 counter 를 이용해 게임 수준에서의 성능 지표 모니터링을 구현하고 이를 활용하는 방법에 대해서 설명합니다.

 온라인홍보2

당신의 서비스에서 모두의 프라이버시 지키기

에드워드 스노든이 2013년에 내부 고발한 NSA의 광범위한 사찰까지 얘기 하지 않아도 ISP, 통신사나 여러분의 고용주가 컴퓨터 네트워크 위의 통신을 들여다보는 일은 비일비재하다. 하지만 조금만 더 노력을 기울이면 이런 프라이버시를 침해하는 일을 막거나 훨씬 어렵게 만들 수 있다. 이 글에서는 표준 프로토콜인 SSL/TLS를 어떻게 일반적인 웹 서버 프로세스나 응용 프로그램 프로세스에 적용할지 설명한다.

SSL/TLS

요즘의 웹 / 네트워크 환경에서는 인터넷 위로 통신하는 부분의 안전성을 위해서 TLS (transport layer security) 를 사용한다. 많은 곳에서 SSL (secure socket layer)이라고 부른다. 하지만 가장 나중 버전인 SSL v3 도 IETF에서 2016에 나온 RFC 7568에서 사용을 피하고 TLS v1.2 를 쓰라고 한다. 그래서 이 글에서는 TLS 라는 용어로 지칭하겠다.

TLS 가 제공하는 것

크게 다음 세 가지 기능을 제공한다.
• 인증 (authentication): 지금 통신 중인 서버가 연결하려고 한 서버가 맞는지 확인
• 보안 (confidentiality): 주고 받는 메시지를 남이 해독할 수 없게 변환
• 무결성 (integrity): 주고 받는 메시지를 남이 조작했는지 확인

TLS 표현 방식

wikipedia-tls.png

파이어폭스에서 확인한 위키 TLS 설정
구글 크롬이나 파이어폭스의 보안 탭을 열어보면 — 혹은 다른 OpenSSL 기반의 설정을 해봤다면 — 아래와 같은 문자열을 볼 수 있다. (아래 예는 위키백과 접속했을 때 사용한 알고리즘이다)
ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
대략 아래와 같은 의미이다.

• ECDHE 키교환: 타원곡선 디피-헬만 알고리즘 (ephemeral 키 방식)
• ECDSA 인증서 알고리즘: 타원곡선을 이용한 디지털 서명 알고리즘
• CHACHA20 스트림 암호화: 메시지를 암호화할 때 CHACHA20 스트림 암호화 알고리즘
Poly1305 MAC, SHA-256 HMAC: 메시지 무결성 검증 알고리즘 두 가지

TLS 표기 방식의 의미

인증을 담당하는 부분은 여기서 ECDSA 하나에 해당한다. 이 부분은 해당 웹 사이트에서 제공하는 인증서 서명 알고리즘에 해당한다.
보안에 해당하는 부분은 키 교환메시지 암호화 (블럭 혹은 스트림 암호화) 에 해당하는 ECDHE 와 Chacha20이다.
무결성 검증을 위해서 사용한 부분이 MAC에 해당하는 Poly1305 와 SHA-256 알고리즘이다.
이 중에서 보안무결성 보장을 위해서 사용한 부분은 웹 서버나 응용 프로그램에서 설정하는 부분이다. 즉, 아파치 웹 서버나 nginx 설정을 하다보면 설정해야하는 부분이다. 모질라 재단에서 제공하는 웹 서버용 권장 설정이나 권장 암호화 알고리즘 목록 의 모범 설정 예시를 참고하면 좋다. 이에 대해서는 이전 블로그 글에서 설명했다.

TLS 인증 기능?

TLS 의 (서버 쪽) 인증 기능은 서버 설정만으로 동작하지 않는다. TLS의 인증 기능이 어떻게 동작하는지 아래에서 살펴보겠다.

TLS 인증서

TLS 인증서는 아주 간단히 말하면 “믿을 수 있는 누군가가 특정 형식으로 전자 서명한 공개키” 다. 여기서 “믿을 수 있는 누군가” 에 해당하는 역할을 담당하는게 “인증 기관” 이다. 그리고 특정 형식에 해당하는게 X.509 형식이다.
주의할 점은 믿을 수 있는 누군가 에 대해서는 강제적인 합의가 있는 것이 아니라서, 웹 브라우저 / OS에 따라서 특정 인증 기관을 신뢰할 수도 있고, 신뢰하지 않을 수도 있다. 예를 들어 올해 초에 한국 전자 인증 (crosscert) 에서 권한없이 인증서를 발급해서 모질라 재단 쪽에서 문제를 재기했고, 이에 대해 관리/모니터링할 책임이 있는 시만텍 인증서 사업 부문에 대한 조사가 이뤄졌다. 그 결과 구글 크롬과 모질라 파이어폭스에선 조만간 시만텍에서 발급한 서버 인증서를 모두 신뢰하지 않게 된다.

전자 서명 구조

전자 서명은 단순히 특정 키 + 서명 형식이 아니고, 공개키 인프라 (PKI) 를 이용해서 키를 단계적으로 서명한다. 우선 인증 기관들의 공개키를 루트 인증서 (root certificate) 이라고 한다. 이 루트 인증서는 웹 브라우저나 운영 체제 수준에서 포함하고 있다. 그리고 이 루트 인증서로 서명한 중간 단계 인증서 (intermediate certificate) 혹은 이걸로 다시 서명한 인증서를 생성한다. 이렇게 몇 단계를 거쳐서 생성한 서명키(=공개키)로 실제 웹 서버의 인증서(=공개키)를 전자 서명 알고리즘으로 서명하면 TLS 인증서가 완성된다. 즉, 서버의 TLS 인증서에는 루트 인증서 바로 아래에 있는 서명키부터, 서버의 공개키까지를 포함한다.
그리고 이런 루트 인증 기관, 혹은 이를 대행하는 인증 기관들은 이런 공개키 서명할 때 비용을 청구한다. 흔히 “인증서 발급 비용” 이라고 말하는게 이런 부분이다.

자가 서명 인증서

인증 기관을 통하지 않고 스스로 서명한 인증서 (self-signed certificate) 를 만들 수도 있다. 하지만, 해당 인증서는 클라이언트 프로그램 (웹 브라우저 혹은 게임 클라이언트 등등) 에서 확인할 방법이 없어서 절대로 피해야 한다. 대안은 무엇일까? 공짜로 인증서를 만들 순 없을까?

공짜로 인증서를 만들 방법은 없을까?

서두에서 언급한것처럼 스노든의 내부 고발 이후로 프라이버시에 대한 관심/걱정은 대폭 증가했고, 2014년에 전자 프런티어 재단 (EFF), 모질라 재단, 미시건 주립대 등이 참여해서 Let’s Encrypt 라는 새로운 CA 를 만들었다. Let’s Encrypt 의 설립 목적이 “자동화된 방법”으로, “비용없이” 원하는 모두에게 TLS 인증서를 발급하는 것이라, 대부분의 경우에서 사용할 수 있는 인증서쉽게(?) 발급할 수 있다.

Let’s Encrypt 에서 TLS 인증서 발급해서 적용하기

foo.example.com처럼 도메인 주소를 가지고 있는 서버라면 아래 과정으로 TLS 인증서를 발급할 수 있다. 이를 DV; domain validated인증서라고 한다. 이외에 OV 나 EV 처럼 웹 브라우저에 기관 이름 혹은 사업자 이름이 뜨는 인증서도 있지만 Let’s Encrypt 에선 발급할 수 없다. 이런 인증서는 발급할 때 추가 확인절차가 있어서 “자동화” 발급만 지원하는 Let’s Encrypt 등에선 지원할 수 없다.

리눅스 서버에 적용하기

리눅스에서 인증서를 발급받는다면 다음과 같은 과정으로 TLS 인증서를 발급할 수 있다.
1. 웹 서버를 설치한다. (nginx, apache2, …; 여기서는 nginx 를 예제로 사용) bash $ sudo yum install -y nginx # centos; nginx $ sudo apt-get install -y nginx # ubuntu; nginx

2. 웹 서버에서 80번 포트로 접근할 때의 루트 디렉터리를 지정한다. 예를 들어 nginx 라면 아래와 같은 설정이 필요하다.
>server {
# 80
번 포트에 대한 설정
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    #
이 경로를 기억해두자.
    root /usr/share/nginx/html;

    location / {}

    # Let’s Encrypt 용 추가 설정
    location ~ /.well-known { allow all; }
   }

3. certbot 프로그램을 설치한다. 아래 명령 중에 사용 중인 서버 OS에 맞는 명령을 고르자.
   $ sudo yum install -y certbot # centos
   $ sudo apt-get install -y letsencrypt # ubuntu
   $ pip install certbot # python 사용 가능한 임의의 운영체제 (virtualenv 여도 무방)

4. 인증서 발급. 발급하려는 모든 도메인을 -d some.domain.com 하는 형식으로 여러번 지정할 수 있다. 2에서 설정한 웹 서버 루트 경로 (위에선 root 설정으로 지정) 를 webroot -w 의 인자로 전달해야 한다.
   $ sudo letsencrypt certonly –webroot -w /usr/share/nginx/html -d foo.example.com -d http://www.foo.example.com
해당 명령 실행 후에 /etc/letsencrypt/live 밑에 도메인 이름으로 심볼릭 링크가 걸린 디렉터리가 생긴다.

5. 서버 설정에 반영
   server {
    listen 443 default_server;
    listen [::]:443 default_server;
    server_name foo.example.com;
# 서버 도메인 지정
    root /usr/share/nginx/html;

# TLS 패러미터들 (인증을 제외한 나머지)
    ssl on;
    ssl_certificate /etc/letsencrypt/live/foo.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/foo.example.com/privkey.pem;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:!MD5;
    ssl_prefer_server_ciphers on;
 }

윈도우즈 지원

공식은 아니지만 Microsoft Windows 용 클라이언트 가 있으며, 위 웹 사이트의 Release 페이지에서 다운로드할수 있다. 이 커맨드라인 프로그램으로 유사한 작업을 해서 인증서를 발급받을 수 있다.

요약

• 현대적인 방법으로 프라이버시를 보호하는데 사용할 수 있는 TLS 레이어가 있다.
• TLS는 인증, 기밀 유지, 무결성 검증 기능을 제공한다. 이중 뒷쪽 두 가지는 서버 설정에 따라 동작한다.
• 인증을 위해서 인증 기관들이 존재하며, 여기서 발급받은 인증서가 필요하다.
• 인증서 발급을 자동화 + 무료로 처리하는 Let’s Encrypt 가 있으며, 서버에서 자동으로 처리할 수 있다.

아이펀팩토리 김진욱 CTO

아이펀팩토리, 세계 3대 게임쇼 독일 게임스컴 2017에 가다! -B2C편

게임스컴 한국공동관을 포함한 B2B관을 둘러 봤으니, 이제 본격적으로 게임 축제를 즐기기 위해 게임스컴 B2C관으로 출발합니다~!

10

입구부터 사람이 어마어마하죠? 입장을 위해 늘어선 줄은 늦은 오후였는데도 불구하고 끝이 보이지 않을 정도였어요. 

11

드이어 B2C관 입장!! 여러 종류의 게임들을 시연할 수 있는 게임스컴 B2C관에는 B2B관과는 다르게 다양한 연령층과 남녀 모두 즐길 수 있는 게임들이 많았습니다. 설레는 마음 안고 신나게 행사장을 둘러보러 갑니다요~! 

12

행사장에 들어가자마자 눈에 띈 곳은 바로 삼성 부스!
삼성의 여러 제품들을 체험해 볼 수가 있었는데요. 독일에서 만난 삼성 부스는 고향 친구를 만난 듯 반가웠습니다.
게다가 여러 나라의 참관객들이 삼성 부스에 많은 관심을 보여서 더욱 뿌~듯! 

13
▲관중 토너먼트와 VR 게임 시연

PS4, XBOX, PC(Steam) 플랫폼에 동시 런칭을 준비 중인 액션 게임이 새롭게 선보인 부스가 있었는데요, 행사 당일에서는 아직 서비스 전인 베타버전을 선보였어요. 유럽인들이 좋아할 만한 귀엽고 박력있는 3D 만화 같은 그래픽의 액션 대전 게임입니다. 토너먼트로 우승자에게는 상품이 증정되어 참여하는 사람들이 꽤 많았습니다.

VR 시연은 이제 게임쇼에서 빼놓을 수 없죠~! 게임스컴에서 역시 부스 곳곳에서 VR시연이 한창이었습니다. 

15
▲AMD 부스와 문명 게임

CPU 제조 업체인 AMD에서도 놀라운 성능의 하드웨어를 선보이며 문명 게임 시연을 진행했습니다. 체험할 수 있는 것들이 많아서 시간 가는 줄 모르고 즐겼… 

14.png

레이싱 게임부터 액션, VR 또 이미 출시된 게임 또는 출시 예정의 게임들까지! 그 종류도 매우 다양했습니다. 

16.png

짠~! 여기는 게임스컴 전시장 한 편에 위치한 기념품 부스입니다. 일반 쇼핑몰에 온 것처럼 판매 부스와 기념품 종류가 정말 다양했어요. 제 취향을 저격하는 굿즈들이 한 자리에!!! 정말 열리는 지갑을 움켜쥐느라 힘들었답니다..ㅠㅠ
그 중에서도 특히 인기가 많았던 곳은 블리자드 기념품 부스였어요. 놀이동산을 방불케 하는 긴 줄로 블리자드 캐릭터의 인기를 실감할 수 있었습니다.

자, 이제 마지막으로 게이머라면 누구나 열광할 EA부스와 블리자드 게임 부스입니다! 별도의 게임쇼라고 해도 될만큼 스케일이 어마어마하죠? 먼저 EA부스로 출발~

17
▲EA 부스 전경

18.png
▲9월 출시 예정인 FIFA 2018

특히 FIFA 2018 체험 존에서는 게임을 할 수 없을 만큼 대기인원이 굉장했습니다. 축구를 사랑하지만 기다릴 시간이 없던 글쓴이는 눈물을 머금고 자리를 떠나야하만 했습니다…ㅠㅠ

19.png
▲EA의 배틀프론트 2 체험 존

EA는 FIFA와 같은 스포츠 게임 개발을 넘어서 자체적으로 오리진이라는 게임플랫폼을 운영할 만큼 영향력 있는 게임 퍼블리셔인데요, 이번 게임스컴에서는 인기 있는 게임을 모두 체험존으로 만들어서 참관객들의 만족도를 한층 높여주었어요.

다음은 최근 스타크래프트 리마스터 출시로 글쓴이의 학창시절을 다시 한번 추억하게 해준 블리자드 체험존!

20.png
▲블리자드 오버워치 체험존

21
▲블리자드 스타크래프트 리마스터(좌) 히어로즈오브스톰 체험존(우)

22
▲블리자드 하스 스톤 체험존

블리자드 부스에서 시간가는 줄 모르고 게임을 즐기다 보니 어느새 탐방을 마칠 시간이 왔습니다..

게임스컴 2017은 전시장 구역별로 그 컨셉이 명확 했는데요. 오로지 미팅을 위한 B2B부터 다양한 굿즈를 판매하는 기념품 샵, 게임시연 부스 그리고 EA와 블리자드의 독립 체험존까지 게이머들의 축제라는 타이틀에 걸맞는 알찬 행사였습니다~! 

Python 기본 개념에 대한 간단한 퀴즈

Python은 그 단순함과 유연성, 다양한 라이브러리의 존재 등의 장점을 가진 언어이다. 웹 서비스로부터 통계, 최근에는 머신 러닝에 이르기까지 다양한 분야에서 사용된다.
이는 게임 산업에서도 마찬가지이다. 실시간 PVP등 성능이 중요한 게임에서는 GIL로 인한 멀티스레딩 불가 문제(C python, Pypy 등의 경우이다. IronPython 등 GIL이 없는 환경도 있다.), 스크립트 언어가 가지는 성능상의 불리함 등의 이유로 게임 개발에 직접로 사용되는 경우는 상대적으로 적지만( Eve online, 듀랑고 등 게임 구현에 Python을 적극적으로 도입하는 게임들도 있다.), 웹 서버 기반의 게임 서버 작성, 기능/부하 테스트를 위한 더미 클라이언트, 각종 배치 작업 등 각종 도구를 작성하는 용도 등으로 널리 사용된다.

Python의 단순함과 명료함은 툴 개발과 같은 높은 생산성이 있어야 하는 작업에 적합하다. 하지만 이것이 Python의 전부는 아니다. Python을 메인 언어로 하는 게임 개발 프로젝트는 많지 않기에 단순하고 생산성이 높은 언어로만 알고 있는 경우가 많지만, 이외에도 다양한 프로그램 패러다임을 지원할 수 있도록 명료하면서도 다양한 개념들이 존재한다.

아래의 문제들은 Python에서 지원하는 몇몇 개념에 대한 것들이다. 본사에서 후원한 Pycon 2017 에서 이벤트 진행에 사용한 문제들로, 특별한 언급이 없다면 Python 3.6 버전을 기준으로 한다. https://www.python.org/dev/peps/pep-0020/ 에 쓰인 것처럼, Python의 아름다움(?)을 느끼는 데 조금이나마 도움이 되길 바란다.

Q. Python의 에러 처리 메커니즘인 Exception에 대한 설명 중 옳은 것은?

1. 별도의 try… except 를 통해 처리되지 않은 exception 들을 처리하는 함수를 지정 가능하다.
2. 새로운 Exception을 임의로 정의할 수 없다.
3. 처리(handling)을 위해 특정 코드를 건너뛸 수는 없다.
4. 예외가 발생하지 않은 경우에만 실행되는 코드를 따로 지정할 수 없다.
5. 임의로 발생시킬 수 없다.

정답 : 1

Python에서는 내장 Exception 클래스를 상속받아 유저가 임의의 Exception을 정의할 수 있다. 다른 언어의 exception과 마찬가지로, exception 발생 시 코드 실행을 중지하고 가장 가까운 handler(except 문)으로 이동하므로, 특정 코드를 건너뛸 수 있으며 finally 문을 이용한, Exception 발생 여부와 관계없이 실행되는 블록을 작성할 수 있다.
이외에도 else 문을 사용하여 Exception이 발생하지 않은 경우에만 실행되는 블록을 작성할 수 있다.

1끝으로, 별도의 핸들링(except)을 거치지 않은 Exception은 sys.excepthook 함수에서 확인, 필요 시 처리 가능하다.

1-2

Q. 다음 중, Python Closure에 대한 설명으로 옳지 않은 것은?

1. 상위 영역의 변수에 접근이 필요한 경우, __dict__ 멤버에서 해당 변수를 찾으려 시도한다.
2. 일반적으로, nested function 형태이다.
3. Callable이다.
4. 다른 변수에 대입(binding)할 수 있다.
5. parent scope에 존재하는 변수를 참조할 수 있다.

정답 : 1.

Closure란, 어떤 함수 및 해당 함수의 실행 시 필요한 환경(각종 변수 등)을 모두 포함한 것을 뜻한다. 예를 들어, 아래 예제의 cl 은 inner 함수 및 inner의 실행에 필요한 변수(outer_var)를 모두 가지고 있는 Closure이다.

2-1

Python의 함수는 first class 값이므로, 일반적인 변수나 객체처럼 인자로 넘겨지거나 함수의 반환 값으로 사용 가능하다. Closure는 함수이므로 당연히 Callable의 일종이며 다른 변수에 대입(binding)할 수 있다. 또한 위의 예에서처럼, 실행에 부모 스코프(outer 함수의 스코프) 내의 변수가 필요하다면 해당 변수 또한 참조 가능하다.

Python의 각종 타입들은 실행 시 필요한 많은 정보, 혹은 동작들을 특수한 이름 규칙을 따르는 변수/함수로 관리한다. 예를 들어 함수의 이름은 __name__ 이라는 변수에 저장되며, 두 오브젝트간의 동등 비교(a == b) 시에는 __eq__(self, other) 라는 함수를 호출한다. 특정 오브젝트의 어트리뷰트들은 __dict__ 에 저장된다. 하지만 Closure 실행 시 필요한 변수들__dict__ 가 아닌, __closure__ 라는 멤버 변수에 저장된다.

Q. Python decorator에 대한 다음 설명 중 옳지 않은 것은?

1. 클래스 멤버 함수(method)는 decorated될 수 없다.
2. 하나의 함수가 둘 이상의 decorator로 decorated 될 수 있다.
3. 다른 모듈 내에 정의된 함수도 decorator로 사용할 수 있다.
4. 함수 정의 구문 위에 @ 기호를 붙여 사용한다.
5. decorator로 감싸진 함수의 __name__ 등 몇몇 변수의 값은 감싸지지 않은 함수의 그것과 다르다.

정답 : 1.

Python의 decorator는 closure 개념을 이용, 함수의 동작을 확장/변경하는 개념이다.

3

위의 예제는 DocratedSample 라는 클래스의 decorated_func 라는 Method를 doc_1, doc_2라는 두 개의 Decorator 로 감싸는 예제이다.

decorator 자체는 closure를 반환하는 함수이므로 다른 모듈에 속해 있어도 사용할 수 있다. 또한 어떤 함수가 decorator로 감싸지면, 이름이 같은 closure로 대체되므로 __name__ 등 몇몇 내장 변수의 값이 원래 함수의 그것과는 다르다.

Python에서 object의 method는 자기 자신을 가리키는 인자를 하나 더 받는 함수이므로 decorator 내에서 해당 처리( inner, inner_2 함수에서 self를 넘겨주는 동작)만 해 준다면 method도 decorator로 감쌀 수 있다.

Q. 다음 중, python 2.7이후의 내장 자료형인 set에 대한 설명으로 옳은 것은?

1. set 객체 자체는 hashable하지 않다.
2. 보기 내의 다른 모든 선택지가 옳다.
3. 원소를 추가/삭제할 수 있다.
4. 순회(iterate)할 수 있다.
5. set의 원소들은 해당 set 내에서 유일하다.

정답 : 2

우선 set의 객체는 collection.Iterable 의 instance이므로 순회(iterate)가능하며, set은 동일 set 객체 내의 원소들이 해당 set 객체 내에서 유일함을 보장해 준다.

Python의 내장 자료구조 중 set, dict 의 key 등 유일성이 보장된 값들을 관리하는 자료 구조들은, hashable 한 값들만을 원소로 취할 수 있다. 이러한 자료 구조들에서는 두 원소를 비교하기 위해 __hash__ 함수와 __eq__ 함수의 반환 값을 참조한다. 이 때, __eq__ 를 이용한 비교 결과 두 객체가 동일하다면, __hash__ 의 값도 동일한 경우를 hashable하다고 한다. (Python glossary) list, set 등 원소들을 변경 가능한(mutable) 자료 구조들의 경우, 값이 변경되었을 때 동일성을 판단하기 모호한 경우가 생긴다.

4

따라서 Python 내장 자료 구조 중 변경 가능한(mutable) 자료 구조들은 모두 hashable하지 않다. set은 필요에 따라 원소 추가, 제거가 가능하므로 mutable 한 자료 구조이며, 따라서 set은 hashable하지 않다.

Q. Python 2.x에서, 다음 코드에 대한 설명으로 옳은 것은?

5

1. type(B) 는 의 값은 ‘class __main__.B’ 이다.
2. Class B는 A를 상속받지만, A클래스 내의 now 필드는 상속받지 않는다.
3. a 객체의 now 필드는 a 객체가 생성된 시점의 시각이다.
4. j 필드는 b 객체에서 접근할 수 없다.
5. Class B 의 object 생성 시, 반드시 생성자의 j에 해당하는 값을 넘겨야 한다.

정답 : 2

Python 에서 object property 는 __init__ 함수에서 초기화함으로써 만들어지며, 설령 상속을 받았다 하더라도 super(…).__init__(…) 등의, 부모 클래스의 __init__을 호출해 주지 않으면 부모 클래스에서 선언된 property 는 사용할 수 없다.

이외에, 의외로 많은 실수를 하는 부분이 3번, 함수의 기본 인자값과 관련된 내용이다. Python에서 함수의 기본 인자값은 해당 문장이 interpreter에서 해석되는 시점에 평가된다. 즉 함수가 호출되는 시점에 평가되지 않는다.

5-1

위의 예제를 보면, obj 생성 시점은 21:33:34 임에도 불구하고, __init__ 에서 datetime.now()의 값으로 초기화하는 obj.now의 값은 그보다도 이전, 대략 5초 전이다. class 선언문 위에서의 시간 값과 비교해보면 class 선언문이 interpereter에서 해석된 시점의 것과 거의 유사함을 알 수 있다. 또한 5초 sleep후에 다시 생성해봐도 객체 내 now 의 값은 변함이 없음을 확인할 수 있다. 의외로 실수하기 쉬운 부분이므로, 함수 인자의 기본값을 함수의 반환값으로 지정하는 경우 주의가 필요하다.

Python 은 간결하고 명확한 언어이지만 그것이 다는 아니다. 개발자가 상당히 깊은 부분까지 커스터마이징이 가능하며, 우아한 코드를 작성할 수 있는 방법들을 제공한다. 위에서 언급한 개념들이 Python을 이용한 제품 설계, 개발 시 조금이라도 도움이 되기를 바라며 글을 마친다.

아이펀팩토리 민영기 TD