[테크플래닛 2015] 지금 왜 간편결제인가

시럽페이로 풀어본 보안 이야기

2015년 상반기 대한민국 IT 환경에서 가장 큰 이슈 중에 하나를 꼽으라면 바로 간편결제 분야가 아닐까 한다. 간편결제라는 용어가 짧은 시간 동안 대중적으로 사용하게 된 것도 지독하리만큼 불편했던 국내 온라인 결제 환경을 방증하는 것으로 생각한다. 물론 그렇게 불편하고 제약된 결제 환경을 제공할 수밖에 없었던 이유가 있었겠지만, 이는 윈도우, 인터넷 익스플로러, 액티브엑스(ActiveX) 같이 획일화한 사용자 결제 환경을 요구했으며 그러한 요구는 곧 사용자가 다양한 환경에서 서비스를 이용할 수 있는 권리를 빼앗았다. 권리를 빼앗겼음에도 많은 사용자가 불편을 받아들인 이유는 바로 ‘보안’이라는 키워드 때문이다.

컴퓨터 보안은 사전적인 의미로 ‘정보 시스템 안에 존재하는 하드웨어와 소프트웨어 그리고 정보들을 탈취와 훼손으로부터 보호하는 것’[1]이라 정의돼 있다. 온라인 결제 서비스의 관점으로 재정의를 해보면 ‘사용자의 개인 정보, 사용자의 신용카드, 계좌번호와 같은 결제 수단 정보, 이를 이용해 결제 가능한 정보를 탈취와 훼손으로부터 보호하는 것’으로 이해할 수 있을 것이다. 온라인에서의 결제라는 행위는 돈(가치)을 유통하는 행위이며 그 흐름 안에는 돈에 상응하는 정보가 존재하기 때문에 돈을 목적으로 하는 대부분의 크래커에게는 가장 매력적인 대상이 되며 반대로 보안 전문가에게는 가장 큰 고민이 되는 분야라고 할 수 있다.

현재 서비스 하는 간편결제 서비스들은 사용자에게 제한되고 일괄적인 환경을 요구하지 않더라도(물론 그러한 것이 보안에 더 취약하다) 적절한 보안 아키텍처를 각자의 관점으로 서비스화하고 있을 것이다. 그 중에 웹 표준 간편결제라는 전략을 취하고 있는 시럽페이 간편 결제 서비스를 통해 로그인 기반의 웹 서비스들이 기본적으로 고려해야 하는 보안 아키텍처들에 대해 간단하게 살펴보도록 하자. 미리 언급하고 싶은 건 높은 보안 수준의 해시 알고리즘, 좀 더 최신의 보안 기술에 대한 언급은 소개나 키워드 언급 수준이 될 것이므로 미리 마음의 준비를 하기 바란다(사실 기술과 관련된 정보는 간단한 검색 만으로도 수많은 정보와 라이브러리를 찾을 수 있다).

‘누구냐 넌’

대부분의 인터넷 서비스가 그렇듯이 시럽페이도 결제 버튼을 클릭해 결제 서비스를 제공하기 전 가장 먼저 사용자의 신원을 확인한다. 이러한 과정은 로그인 기능을 통해 제공하고 있으며 보안에서는 인증이라는 용어로 정의한다. 인증은 시럽페이와 같이 민감한 데이터를 가지고 있는 서비스가 가장 중요하게 생각하는 기능 중 하나이며 보안적으로 가장 완성도가 높아야 하는 기능 중 하나다. 사실 사전적인 인증(Authentication)의 정의는 ‘진짜라고 주장하는 한 개체(entity)의 일부분을 나타내는 데이터가 진실인지 여부를 확인하는 행위’를 말하며[2] 여기서 가장 흔한 실수와 오류가 인증을 사용자에 한정돼 설계, 구현하는 경우가 종종 있다는 것이다. 시럽페이의 경우는 결제와 상품이 이동하는 모든 대상, 즉 결제를 시도하는 사용자와 결제 상품을 소유하고 있는 가맹점 두 곳에 대한 인증이 모두 필요하다는 것이다. 그렇다면 이러한 것들은 어떠한 전략과 기술에 의해 구현되어 있는지 살펴보자. *컴퓨터 공학에서 개체의 사전적인 의미는 ‘하나의 정보 단위’를 의미하며 필요에 따라 대상이라는 용어로 대체돼 사용할 수 있다.

사용자가 11번가와 같은 시럽페이 가맹점에서 시럽페이 결제 버튼을 클릭하면 사용자에게 로그인 페이지를 제공하기 전 시럽페이는 가장 먼저 가맹점 인증을 수행한다. 이를 위해 시럽페이는 사전에 가맹점에게 지정된 ID와 시크릿(Secret)을 부여한다. 가맹점은 시럽페이로 접속, 좀 더 정확하게 표현하면 시럽페이 사용자 데이터에 접근 권한을 얻기 위해 일정 규격의 데이터를 구성하고 미리 전달한 시크릿으로 서명(Signing)을 해야한다. 그리고 가맹점은 서명한 데이터(이하 토큰)를 이용해 시럽페이에게 접근 권한을 요청하며 시럽페이는 가맹점의 토큰을 확인하고 가맹점에게 해당하는 권한을 부여하게 된다. 이러한 과정에서의 요청, 응답 데이터는 JOSE(Javascript Object Signing and Encryption)[3]의 JWT(Json Web Token)를 이용해 각각의 메시지에 대한 무결성을 검증하며 OAuth 2.0 인증 프레임워크(Authorization Framework) 중 클라이언트 보증서(Client Credentials) 인증 방식[4]으로 인증을 수행하고 있다.

JOSE는 JSON, JSON-LD 데이터 포멧을 이용해 메시지에 대한 암호화를 지원하는 표준 규격이다. 시작은 모질라 재단에서 Mozpay API[5]라 불리는 프로젝트에서 처음 정의됐다. 이후 W3C의 웹 페이먼트(Web Payment) 그룹에서 공식적으로 지정해 사용하는 규격으로 2015년 5월에 IETF RFC 스탠다드(Standard)로 릴리즈된 따끈따근한 암호화 규격이다. 간략하게 설명하면 기존 무결성(JWS), 암호화(JWE)를 위한 암호화 알고리즘(JWA), 암호화 데이터(JWT), 암호화 키(JWK)에 대한 규격을 일원화해 웹에서 전달되는 JSON 형식의 암호화 방식을 쉽게 적용, 검증할 수 있는 규격이다. 좀 더 자세한 정보는 레퍼런스 링크[6]를 참조하기 바란다.

OAuth 2.0 인증 프레임워크의 클라이언트 보증서는 OAuth 2.0에서 클라리언트에 권한(Grant)을 부여하기 위한 인증 방식 중 하나로 리소스 서버(Resource Server)인 시럽페이는 클라이언트인 가맹점이 신뢰할 수 있다는 전제로 클라리언트 Id와 시크릿을 가맹점에 부여하고 이를 검증하는 방식으로 가맹점이 리소스 오너(Resource Owner)인 시럽페이의 사용자의 자원에 접근 권한을 얻게 되는 인증 방식이다.

시럽페이에서 가맹점에 대한 인증이 정상적으로 완료됐다면 이후 사용자 인증을 진행하게 된다. 여기서 시럽페이는 가맹점이 사용자 인증을 대행하는 싱글 사인 온(Single sign on, 이하 SSO)방식과 사용자가 직접 계정, 비밀번호를 입력하는 두 가지 방식을 제공하고 있다. SSO를 사용하기 위해서는 다음 두 가지 조건이 충족돼야 한다. 그 중에 하나는 회원체계를 보유하고 보안적으로 신뢰할 만한 가맹점을 경유해야 한다는 것과 다른 하나는 사용자가 해당 가맹점에게 시럽페이 로그인을 대행하는 것을 명시적으로 수락해야 한다는 두 가지 조건이 필요하게 되는 것이다. 이러한 조건이 성립될 경우 사용자 자신의 계정, 비밀번호를 입력해야하는 ‘사용자 인증’과정을 가맹점이 대행 할 수 있는 조건이 성립하는 것이며 이를 통해 가맹점과 사용자는 명시적인 사용자 인증 과정을 통과할 수 있게 된다. 만약 두 가지 조건 중 어느 한 조건이라도 충족되지 않는다면 SSO 방식, 즉 자동 로그인 기능을 사용 할 수 없으며 시럽페이는 사용자에게 계정과 비밀번호 입력을 요구하게 된다. 사용자에게 계정과 비밀번호를 입력받는 사용자 인증 방식은 비밀번호의 보안성에 크게 의존한 인증 방식이며 여기서 중요한 보안 기능이 바로 암호화 해시 함수(이하 해시 함수)[7], 그리고 솔트(Salt)[8]와 키 스트레칭(Key stretching)[9]이다.

사용자에게서 비밀번호를 입력받으면 비밀번호를 솔트와 함께 키 스트레칭의 입력값으로 제공하고 임의의 문자열로 반환 받은 다음 원래 해싱하고자 했던 해시 함수로 해시를 만드게 일반적인 순서다. 해시 함수를 사용하는데 있어서 동일 입력값에 항상 동일한 출력값을 반환하는 것은 Dictionay attack과 Rainbow table attack 같은 형태의 공격을 용이하게 만든다. 어떠한 환경에서도 SHA1 해시 함수의 입력값 “abc”는 “a9993e364706816aba3e25717850c26c9cd0d89d” 해시를 가진다.[11] 즉 해시 알고리즘이 무엇인지와 해시만 알고 있다면 많은 비용이 들더라도 해시의 입력값을 유추할 수 있다는 것이다. 그렇기 때문에 범용적으로 사용하는 해시 알고리즘에 사용하는 사람, 용도, 목적에 따라 일부 인위적인 변화를 주게 되는데 이러한 변화를 주기 위한 임의의 값을 솔트라 지칭한다. 간단하게 설명하면 기존 “abc”에 대한 SHA1 해시는

abe : a9993e364706816aba3e25717850c26c9cd0d89d

를 가지지만 여기에 “EFS3QFB349”라는 솔트를 추가한다고 하면 “EFS3QFB349|abc”와 같이 변경해 기존과는 전혀 다른

EFS3QFB349|abc : 247bdc1880bdd1f4334e7188a1326b3e4e336846

해시를 생성할 수 있게 된다.

이렇게 솔트를 사용함에 따라 입력값에 대해 사용자가 임의의 변화를 주게되고 그에 따른 해시 또한 기존과는 전혀 다른 해시가 나오게 되므로 크래킹을 위해서는 솔트와, 솔트를 사용하는 방식에 대해서도 알아야 하는 비용이 생기게 되는 것이다. 물론 솔트 관리 이슈가 생기지만 이러한 것은 크게 문제가 되지 않으며 솔트 관리를 위한 투자에 비해 얻는 이익은 실로 크다고 볼 수 있다. 이렇게 솔트를 사용하는 방식은 위와 같이 사용자가 임의적으로 정하거나 해시 함수(더 정확하게는 암호화 해시 함수)에서 제공하는 방식으로 사용할 수 있다. 시럽페이에서는 솔트를 생성, 관리하는 방식으로 앞서 언급한 임의적으로 솔트를 생성, 조합하기도 하지만 웹 페이지에서 사용하는 솔트 값을 HMAC 해시를 이용하고 있다.

그렇다면 왜 시럽페이에서는 HMAC을 솔트로 사용하는 것인가라는 질문을 가질 수 있다. 그 질문에 대한 답을 간단하게 설명하면 사용자를 식별할 수 있는 데이터를 HMAC의 키로 활용해 사용자 별 솔트를 생성할 수 있으며 암호화 해시 함수이기 때문에 일정 수준 이상의 유일성이 보장되고 필요에 따라 사용자와 비밀번호 간의 인증과 무결성이 검증 가능하기 때문이다.

키 스트레칭은 단어 그대로 키를 늘리는 것이다. 해시 함수에서의 키(Key)는 바로 입력값을 의미한다. 솔트가 임의의 값을 입력값과 결합한 형태로 입력값을 변환하는 거라면 키 스트레칭의 경우는 해시 함수의 입력값 전체를 일정 수준의 복잡한 값으로 변환하는 것을 말한다. 일반적으로 해시 기반의 키 유도 함수(Key derivation function)[12]라 불리는 것들을 이용해 이러한 과정을 수행하게 된다.

키 유도 함수의 출력값만 보면 해시 알고리즘과 같다고 생각이 들 수 있다. 물론 키 유도 함수를 해시 함수로 대신해 사용해도 무관하다. 하지만 키 유도 함수의 경우 해시 알고리즘과는 다르게 일부 가변적인 요소를 설정할 수가 있으며 이는 마치 솔트와 같은 기능을 수행하게 되는 것이다(키 유도 함수에 따라 솔트를 요구하기도 한다). 시럽페이에서는 키 유도 함수로 PBKDF2와 스크립트(Scrypt) 두 가지를 병행해 사용하고 있다.

PBKDF2(Password-Based Key Derivation Function 2)[13]는 RSA 기반의 공개키 암호화 표준의 한 부분으로 적용된 대표적인 키 유도 함수 중 하나이며 RFC 2898[14] 표준으로 명시되어 있으며 기본적인 정의는 아래와 같다.

DK = PBKDF2(PRF, Password, Salt, c, dkLen)
PRF - HMAC과 같이 난수를 생성하기 위해 두 개의 파라미터를 가지며 고정된 길이의 값을 반환하는 함수
Password - 비밀번호 평문
Salt - RFC 문서에서는 64bits 이상을 사용할 것을 권장
c - PRF 함수를 반복하는 횟수
dkLen - 해시의 길이
DK - 해시

구현에 따라 이러한 파라미터는 조정이 있을 수 있지만 기본적으로 비밀번호(Password)에 대한 일정 수준의 이상의 키 스트레칭이 돼야 하며 이에 대한 가변적인 요소는 Salt, c, dkLen와 같이 외부 파라미터에 의해 제공돼야 한다. 그러나 이러한 키 스트레칭을 적용함에도 불구하고 하드웨어의 빠른 발전에 따라 GPUs를 이용한 무차별 대입 공격(Brute force attack)과 같은 공격에 취약점[15]이 발견되고 있다. 그래서 최신 키 스트레칭 기술인 Bcrypt 그보다 더 최신 기술인 스크립트와 병행해 사용할 권을 권장하고 있으며 시럽페이에서는 스크립트를 현재 사용하고 있다.

스크립트 는 비밀번호 기반 키 유도 함수다. 스크립트는 기본적으로 하드웨어 자원에 대해 고비용을 목적에 두고 있으며 이것은 바로 무차별 대입 공격과 같은 확률에 기반을 둔 공격에 대한 비용을 기하급수적으로 증가시키기 위한 목적이다. 물론 하드웨어 고비용을 목적에 두고 있어 일반적인 상황에서도 다른 키 유도 함수보다 더 많은 자원을 할애해야 하겠지만, 사용자에 의한 인증을 수행할 경우라면 이러한 고비용 처리는 일반적인 상황에서는 크게 문제가 되지 않을 것이다. 스크립트는 RFC Draft 상태[16]이며 정의는 다음과 같다.

Function scrypt(Passphrase, Salt, N, p, dkLen):
Passphrase - 비밀번호 평문
dkLen 키 스트레칭된 비밀번호 문자열의 길이
N - CPU/memory 비용
p - 병렬화 파라미터

스크립트도 PBKDF2와 같이 구현에 따라 파라미터는 조정될 수 있지만 PBKDF2와는 다르게 하드웨어 비용에 대한 가변적인 요소 N이 외부 파라미터로 제공되어야 한다.

‘난 선생, 넌 학생’

가맹점, 사용자 인증이 모두 정상적으로 완료되었다면 시럽페이 사용자는 시럽페이에 있는 자신의 정보에 접근할 수 있는 권한과 이를 이용해 결제를 수락 할 수 있는 권한을 얻고 가맹점은 사용자 결제수락 의사를 통해 시럽페이에게 결제요청 할 수 있는 권한을 얻게 된다. 여기서 언급하는 권한(Authorization)의 정의는 ‘일반적인 컴퓨터 보안, 정보 보안 영역에서 개별적으로 접근하고자 하는 자원에 대해 접근 권한을 지정하는 기능’이다.[17] 즉 사용자에게만 ‘결제수락’이라는 자원(기능)이 허용되며 가맹점에게만 ‘결제요청’이라는 자원이 허용돼야 한다는 것이다. 이러한 과정은 잘 추상화된 대상 간의 논리적인 절차에 기반하며 이러한 과정에서의 논리적인 오류는 곧 보안 헛점으로 나타나 크래커가 아니더라도 일반 사용자가 허용되지 않은 자원에 접근 할 수 있는 상태로까지 나타나게 되는 것이다.

시럽페이에서는 서버 자원에 대한 접근 권한을 부여 하는 대상에 대하여 OAuth 2.0 인증 프레임워크의 스코프(Scope, Access Token Scope)[18]와 롤(Role), 두 가치 추상화된 요소를 이용한다. 쉽게 표현하면 스코프는 접근하고자 하는 API를 그룹핑 한 것이고 롤은 사용자와 가맹점 같이 인증받은 개체를 그룹핑한 것이라 생각하면 될 것이다. 시럽페이는 인증 받은 개체의 스코프와 롤을 확인해 API 또는 서버 자원에 접근 할 수 있는지를 확인하게 되는 것이다.

물론 다양한 조건에서 다양한 개체에게 두 가지의 추상화를 적용하기 어려운 경우가 많다. 웹 페이지로 로그인을 하는 사용자, Rest API로 접근하는 서버나 써드파티 라이브러리에 대해 동일한 추상화가 가능하겠는가. 물론 설계 능력에 따라 가능할수도 불가능할 수도 있겠지만 여기서 언급하고자 하는 것은 컴퓨터 보안, 정보 보안의 영역에서는 인증만큼 권한이라는 기능, 그리고 이 두 가지 요소의 균형이 매우 중요하다는 것이다.

이쯤에서 인증에 대해 좀 더 기본적인 부분을 들여다 보자. 우선 인증에서 사용자를 검증하는 데 사용하는 요소(Factor)는 크게 세 가지로 분류될 수 있다.

- KNOW : 사용자가 알고 있는 무엇
- HAS : 사용자가 가지고 있는 무엇
- IS : 사용자 자신

전통적으로 인증이라는 과정은 KNOW 요소에 크게 의존하고 있다. 바로 계정과 비밀번호가 대표적이라 할 수 있다. 아마 주위를 둘러보아도 대부분의 컴퓨터 시스템은 계정과 비밀번호만 알고 있으면 컴퓨터 시스템 내에서 계정과 연관된 정보 또는 그 외의 정보에까지 접근하는 것을 허락할 것이다. 이렇게 KNOW 요소는 유출과 같은 형태로 불특정 다수에 의해 공유될 소지가 많은 취약점을 가지고 있다.

이러한 취약점을 보완하면서 인증이 필요한 경우 단일 요소로도 사용되기도 하지면 좀 더 흔하게 추가 인증 또는 2차 인증(Two-factor Authentication)이라는 기능으로 HAS 요소를 활용하고 있다. 흔히 문자인증, In/Out -Bounding ARS, OTP 등과 같이 인증을 받고자 하는 대상이 무엇인가를 점유하고 있는 것을 확인하는 방식을 취하며 이러한 것은 일정 수준의 불편함이 따르지만, KNOW 요소보다는 공유, 전파 될 확률이 적다는 보안적인 이점을 취할 수 있다.

그리고 현재 가장 주목받고 있으며 매우 빠르게 발전 중인 IS 요소는 대표적으로 생체 인식을 통한 인증체계다(물론 생체인식이 HAS 라는 주장도 있지만 누군가가 나의 손가락을 가져가() 크래킹을 시도할 수 있는 환경이 아니면 크게 신경 쓰지 않아도 될 것이다). 지문, 음성, 얼굴, 안구 등 사람의 여러 생체를 이용하여 대상을 인증하는 방식으로 지난 2014년 12월 생체인식 기반의 표준 쳬계인 FIDO[19]가 최종 Standard로 배포돼 이러한 생체인식을 통한 인증 방식은 더욱더 확산될 전망이다.

마지막으로 인증의 정의에는 포함되어 있지는 않지만, 현대에는 상황인식(Contextual Awareness)[20]이라는 용어로 인증에 실제로 개입되는 요소 이외에 정황, 상황을 추가로 분석해 인증하는 단계도 점차 확대되고 있다. 특정 서비스에 로그인 이후 다른 IP에서 접속, 다른 PC에서 접속 등을 알리는 메일을 받아 보았을 것이다. 이러한 것들이 기존의 인증 체계에 대한 취약점을 보완하고자 하는 노력 중의 하나이며 결제 서비스에서는 FDS(Fraud Detection System)가 담당하는 기능 중에 하나로 인식하고 있기도 하다.

시럽페이에 정상적으로 로그인 한 사용자는 구매하고자 하는 상품과 신용카드, 은행 계좌 등 자신이 등록한 결제 수단 정보들, 그리고 시럽페이 계정에 대한 정보를 조회할 수 있게 된다. 그러나 최종적으로 시럽페이에게 결제 의사를 전달하기 위한, 마치 카드 명세서의 서명을 하는 것과 같은 ‘결제수락’이라는 기능은 사용할 수 없는 상태이다. 결제수락이라는 기능에 접근할 수 있는 권한을 얻기 위해서는 핀번호 인증이라는 또 다른 인증을 거쳐야 최종적으로 가맹점에게 결제수락의 의사를 전달할 수 있게 되는 것이다. 다시 말하면 시럽페이에서는 결제수락 기능을 사용하기 위한 권한을 계정과 비밀번호로 인증된 사용자가 아닌 계정과 비밀번호 그리고 핀 번호 까지 인증한 사용자에게 권한을 부여한다는 것이다. 이러한 것들이 기능, API에 접근하는 단계에서 관리가 되거나 접근 후 요청 데이터를 검증하는 단계에서 관리가 되는 것은 나중의 문제다. 여러 개체들의 다양한 인증 상태에 따라 적절한 권한을 부여해야 하며 이를 위해 인증의 세 가지 요소를 이해하고 필요에 따라 적절한 요소가 반영된 인증을 사용해야 한다는 것이다.

사용자에게서 결제수락을 전달받았다고 시럽페이에서 결제가 바로 진행되지는 않는다. 우선 시럽페이는 사용자의 설정에 따라 ARS 또는 SMS-OTP 형태의 2차 인증을 요구할 수 있으며 이러한 점유 인증 형태의 2차 인증은 HAS 요소가 가지는 보안적인 강점을 그대로 취할 수 있게 된다. 그러나 사용자가 2차 인증을 설정 하지 않았더라도 시럽페이는 강제적으로 사용자에게 2차 인증을 요구할 수 있다. 그러한 기능은 바로 FDS에 의해 수행된다. 좀 더 풀어서 설명하면 시럽페이의 FDS는 사용자가 시럽페이서 정의한 안전하지 않은 상황(Context)이라고 판단되거나 가맹점이 지정한 상황인 경우 사용자에게 2차 인증을 강제적으로 요구할 수 있다는 것이다. 예를 들어 일정 기간 접속이 없던 사용자가 결제를 시도한다거나 현금으로 교환가능한 상품을 일정 금액 이상으로 구매하려고 한다거나 하는 상황인 것이다.

시럽페이가 추구하는 중요한 키워드 중에 하나는 안전함(Security)이다. 그러나 편리함(Convenient) 또한 그만큼 중요하다라고 할 수 있다. 안전함과 편리함은 모든 보안 시스템이 추구하는 가장 중요한 목표이며 두 개를 모두 만족시키기란 매우 어려운 것이라고 여겨지고 있지만 시럽페이는 안전함과 편리함 모두를 접근하는 방법 중에 하나로 인증과 권한에 대해 적절하게 균형을 이루어 나가는 전략을 취하고 있다는 것이다.

‘우리 둘만 아는 이야기’

대부분의 컴퓨터 시스템은 사람을 포함한 여러 대상과 데이터 교환으로 필요한 정보를 취합하고 이를 재가공해 목적에 부합한 기능을 수행한다. 이러한 동작 방식은 보안에 위험한 여러 가지 요소들을 내포하고 있으며 그러한 요소 가운데 사람 역시 배제될 수 없다. 컴퓨터 시스템은 가장 먼저 데이터를 교환하고자 하는 대상이 원하는 대상인지, 혹 탈취와 훼손을 목적으로 하는 대상은 아닌지 식별해야 하는 인증을 수행해야 하며 인증된 대상에게는 그에 맞는 적절한 권한을 부여하여 기능이 수행되도록 해야 한다. 그런데 컴퓨터 공학에서 기능이 수행되는 과정은 메시지 교환, 즉 의사소통(Communication)의 과정이라 표현되기도 한다. 컴퓨터와 컴퓨터, 컴퓨터와 소프트웨어, 소프트웨어와 사람 각각의 대상 간 메시지를 교환하는 과정을 기능이라고 표현하는 것이다. 그렇기 때문에 불특정 다수에 의해 구성된 네트워크 상에서 의사소통을 한다는 것 자체가 누군가는 메시지를 엿볼 수 있으며 누군가는 메시지를 변형 할 수 있다는 것이다. 이러한 문제점을 극복하고자 컴퓨터 보안은 무결성과 암호화라는 방식을 이용하기 시작했다.

데이터의 논리적인 무결성(이하 무결성)은 부분적인 상황으로 주어진 데이터 일부분의 정확성이나 합리성과 연관된다. 좀 더 쉽게 표현하자면 데이터가 생성 시점이나 서명 시점 이후 변경이 없는 데이터의 논리적인 성질이라 얘기할 수 있다. 보안에서 이러한 성질이 중요한 것은 바로 상호 메시지를 교환하고자 하는 대상 이외에 불특정 다수가 네트워크에 인위적으로 개입이 가능하며 이러한 개입을 통해 하고자 하는 중요한 행위 중 하나가 바로 메시지를 자신의 의도에 맞게 변경, 조작하는 것이므로 이를 검증하는 성질로 정의해 사용하고 있는 것이다.

암호화는 메시지를 인증된 일부 사용자에게만 읽을 수 있도록 하는 방법 중의 하나로 임의의 문자열로 부호화하는 과정을 얘기한다. 여러가지 방식이 존재하겠지만 기본적으로 암호화는 아무 의미를 갖지 않는 문자열을 반환한다. 물론 이 문자열은 암호화 알고리즘에 따라 제한된 조건의 사용자에게만 열람이 가능하다. 이러한 과정이 필요한 이유는 무결성이 필요한 이유와 동일하지만 암호화의 경우 정보를 숨기기 위한 기능에 목적을 두고 있다. 즉 네트워크를 이용하여 메시지를 전달하는 과정에서 누군가가 보아서도 안되는 메시지를 보낼 경우에는 암호화가 필요하다는 얘기인 것이다.

‘나는 아직도 배고프다’

시럽페이에서는 이외에도 각 상황에 맞추어 다양한 보안 메커니즘을 적용하고 있다. 중요한 클라이언트 입력을 가로채는 것(Snipping)을 방지하기 위한 가상 키패트, 하드웨어 보안 모듈(Hardware Security Module, HSM)[23]을 이용해 하드웨어 수준의 암복호화 및 관련 키 관리, 사용자 결제 정보를 물리적으로 분리된 영역에 별도로 관리, 명시적인 핀번호 저장하지 않는 방식 개발, 선택적으로 클라이언트 보안 솔루션인 V3와의 연동 등 정말 다양한 기능을 제공하고 있다. 그만큼 안점함을 추구하기란 생각보다 쉽지 않다는 것과 그럼에도 편리함을 추구할 여지는 충분하다는 것이다.

“A chain is only as strong as its weakest link'‘
“체인은 단지 가장 약한 부분만큼만 강하다.”

위의 구절은 토마스 레이드라는 작가가 1786년 쓴 지적인 남자의 힘이라는 수필의 한 구절을 인용한 구절이지만 현재 보안 분야에서 가장 많이 인용되는 문구가 됐다. 비밀번호 저장을 위해 높은 보안 수준의 해시 알고리즘을 쓰는 것, 최신 버전의 TLS 프로토콜을 사용하는 것과 같이 높은 보안 수준의 기술을 사용하는 것은 매우 중요하다. 하지만 그러한 것들이 하나의 흐름으로 연결지어 기능으로 만들어가는 과정에서 과연 약한 연결고리(weakest link)가 없는지를 고민하고 검증하는 것 또한 그만큼 중요하다고 말하고 싶다. 개인적으로는 그러한 노력들이 모여 우리나라의 컴퓨터 보안, 웹 서비스 보안 범위 안에서도 사용자에게 조금은 더 평등하고, 조금은 더 자유롭고, 조금은 더 편리한 환경이 되었으면 한다.

출처 : 마이크로소프트웨어 10월호

제공 : 데이터 전문가 지식포털 DBguide.net