오픈넷 기부금, 금감원 압력으로 중단 위기

어제(7월8일) 오후 3:11에 삼성카드는 오픈넷 기부금 결제처리를 중단하겠다는 통지를 이메일로 보내왔습니다. 조금 후, 외환카드도 오픈넷 기부금 결제를 계속하기 곤란하다고 연락이 왔고, 연이어 신한카드도 결제를 중단하겠다고 연락해 왔습니다.
왜 그럴까요?
어제, 금감원이 오픈넷 기부금 결제를 허용하는 카드사들에게 오늘 오후2시까지 금감원에 ‘집합’하도록 명령을 내렸고, 이들 카드사들은 금감원의 해꼬지를 두려워한 나머지 뚜렷한 이유도 없이 오픈넷 기부금 결제를 일단 중단하기로 한 것입니다.
물론, 오픈넷 기부금 결제는 현행 규정상 아무런 문제점도 없는 적법한 것입니다. 금감원은 오픈넷 결제 기술이 무엇인지 이해하지도 못한 나머지 현행 규정에 위반된다고 꼬투리를 잡을 수 있을 것으로 지레 짐작하고 카드사를 협박하고 있지만, 오픈넷 결제는 다음과 같은 원리로 이루어집니다.

1. Mashup 기술

오픈넷 기부금 결제 페이지(https://openweb.or.kr/gift)를 일반인이 보면, 기부자가 입력한 카드번호 등의 정보가 마치 openweb.or.kr 서버로 전달되어 결제되는 듯 보일 것입니다. 그러나 실제로 카드정보는 이용자 브라우저에서 openweb.or.kr 서버를 거치지 아니하고 결제대행회사로 직접 전달됩니다. 오픈넷 기부금 결제 과정을 브라우저 디버깅 툴을 켜서 살펴보면 기부자가 입력한 결제정보가 결제대행사 서버로 직접 전달되는것을 확인할 수 있습니다.

오픈넷 서버(opennet.or.kr 또는 openweb.or.rk)는 결제 정보 처리에 개입하지 않고, 기부자가 입력한 카드번호 등의 정보를 오픈넷이 알 수도 없고, 저장하지도 않습니다. 이렇게 매시업 기술을 사용하면, 팝업이나 프레임, 액티브X 따위를 사용할 필요가 없어지고, 기부자가 오픈넷이 운영하는 페이지에서 결제에 필요한 모든 작업을 간편하고 일관되게 마칠 수 있는 깔끔한 유저경험을 제공할 수 있게됩니다. 팝업을 허용하라거나, 새로운 창을 띄우는 것은 구식 기술입니다.

2. Application Level의 E2E 데이터 전송 기술

오픈넷 기부금 페이지에서 기부자가 입력하는 신용카드 정보는 웹브라우저 Sandbox 내에서 End-to-End 암호화되어 결제대행사(페이게이트) 서버로 전송됩니다. 단순히 SSL 접속에만 의존하는 것이 아니라, 신용카드번호 등의 민감한 정보는 SSL체널(암호화 교신체널)로 내보내기 전에 미리 한번 더 암호화한 다음에 SSL암호화 교신체널로 내보낸다는 뜻입니다. SSL암호화 체널만을 사용할 경우, 중간단계의 여러 노드(node)들 (웹방화벽, 웹서버 등)에서 데이터가 복호화되고 노출되는 문제점이 있을 수 있습니다. 이것을 해결하는 것이 E2E over SSL 기술입니다.
E2E 암호화로 전송되는 정보는 결제처리 서버의 RSA Public Key로 암호화되어 전송되고 이 정보는 최종 수신 서버(결제처리 서버)의 어플리케이션내의 RSA Private Key로만 복호화가 가능하므로 데이터가 중간 단계에서 누출되지 않습니다.

3. Browser Sandbox Security

오픈넷 기부금 결제의 경우, 클라이언트 측 보안은 Browser Sandbox에 의존합니다. Sandbox란 모래박스를 의미하고 모래박스 안에서 무슨일이 일어나든 외부로 영향을 미치지 않고 외부의 상황도 모래박스 안으로 영향을 미치지 않는다는 개념입니다. 이용자의 OS(윈도우, 맥, 리눅스 등)에서 웹브라우저가 동작하고, 웹브라우저는 Sandbox Security로 불리는 보안 장치를 구비하고 있습니다. ActiveX등의 플러그인을 함부로 사용하면 웹브라우저의 Sandbox Security에 취약점이 생길 여지가 늘어나지만, 플러그인을 사용하지 않고 웹브라우저만을 이용할 경우 클라이언트 측의 보안은 매우 견고하게 유지될 수 있습니다.
오픈넷 기부금 페이지에서 기부자가 입력하는 정보는 웹브라우저가 제공하는 Sandbox Security 로 보호되고 있습니다. 전 세계의 주요 금융거래 사이트들이 플러그인을 사용하지 않고 웹브라우저만으로 거래를 수행하는 이유도 바로 여기에 있습니다. 액티브X 등의 플러그인은 불편할 뿐만 아니라, 여러분이 사용하는 웹브라우저에 크고작은 ‘보안 구멍’을 뚫어놓게 되므로 위험합니다.

4. 여신전문금융업감독규정

신용카드 결제에 적용되는 여신전문금융업감독규정 제24조의6 을 거론하면서 금감원이 꼬투리를 잡으려한다는 이야기를 오늘 아침에 들었습니다. 해당 조항은 다음과 같습니다:

③법 제24조제7호에 따라 신용카드업자는 「신용정보의 이용 및 보호에 관한 법률」 제20조제1항에서 정하는 내부관리규정을 마련하고 신용카드가맹점으로 하여금 신용카드등의 거래에 의해 얻은 신용카드회원등의 제반 정보에 대한 제3자의 불법 접근 또는 제3자에게 유출되는 등의 위험에 대해 처분·소거 또는 폐기 등 기술적·물리적 보안대책을 수립하도록 하여야 한다.

‘카드가맹점’은 상점, 인터넷 쇼핑몰 등과 결제대행사를 모두 포함하는 개념입니다. 오픈넷도 카드가맹점이고, 페이게이트, 이니시스, KVP등의 결제대행사도 카드가맹점에 해당합니다.
오픈넷의 경우에는 카드 정보 등을 아예 처리하지 않으므로, 이 조항이 문제될 이유는 전혀 없습니다. 그러나 페이게이트는 카드 정보 등을 ‘저장’하므로 이 조항에 위반된다는 것이 금감원 직원의 입장인듯 합니다.
좀 우스운 이야기입니다. 안심클릭, ISP결제 등을 사용하는 국내의 다른 결제대행사들도 고객의 카드정보를 ‘저장’하는 것은 마찬가지 입니다. 고객의 카드정보를 결제대행사가 알지 못하면 카드거래 액수를 카드사에 청구할 수도 없고, 카드사가 해당 거래에 대하여 결제대행사를 통하여 처리할 방법이 없습니다. 즉, 다른 결제대행사들도 모두 카드정보를 ‘저장’합니다.
그런데도 페이게이트만을 상대로 시비를 거는 것은 좀 …
또한, 위에 인용한 규정을 보시면 아시겠지만, “처분·소거 또는 폐기 등 기술적·물리적 보안대책을 수립”하라는 규정은 반드시 “처분, 소거, 폐기”를 해야만 한다는 것이 아니라, 그렇게 하거나, 다른 적절한 ‘기술적, 물리적 보안대책’을 수립하면 된다는 뜻입니다. 저장해서는 안된다거나 반드시 삭제해야 한다는 규정이 아니라, 공격에 대응한 보안대책을 수립하라는 뜻입니다.
오늘 오후2시에 금감원에 ‘집합’당한 카드사 관계자 분들을 위하여 이 글을 적어보았습니다.
금감원은 이쯤 되면, 선량한 규제자로 보기는 어려워진 듯 합니다. 악의적으로 규제권한을 남용하는 금감원에 대해서는 적절한 대응수단을 검토해 보겠습니다.