오픈 뱅킹은 안전한가?

오픈 뱅크 사용자 및 서비스 제공자가 안전하게 금융 서비스를 이용 혹은 제공하기 위해 필요한 보안 기술에 대한 권고 사항입니다. 본 내용은 기술적 가이드라인이며 더욱 정확한 것은 보안 전문 컨설팅 업체의 지원을 받아야 합니다.

본 규격은 현 온라인 금융 서비스에서 제공하는 보안 제품들의 수준과 동일한 고려 사항과 해법을 오픈 뱅크 금융 기관과 사용자에게 제공함으로서 적어도 현재 수준의 금융 보안이 이루어 지도록 하기 위한 것입니다.

보안 가이드가 필요한 이유

온라인 금융 서비스를 위해서는 금융 기관이 이용자에 대한 단말 보안을 책임져야 하는 상황입니다. 고객의 책임으로 본인이 동의하는 경우 보안 프로그램 해제가 가능합니다.

전자금융거래법 시행세칙 29조
2. 3) 이용자PC에서의 정보유출을 방지하기 위해 이용자의 접속 시 우선적으로 이용자PC에 개인용 침입차단 시스템, 키보드 해킹방지 프로그램 등의 보안 프로그램을 설치할 것 (다만, 고객의 책임으로 본인이 동의 하는 경우에는 보안프로그램 해제 가능)

하지만 이것이 거의 불가능하며 새로운 해킹 수단이 나올 때 마다 금융기관은 새로운 대응 소프트웨어를 플러그인으로 개발하여 배포하고자 하고 있습니다. (메모리 기반 해킹, 피싱 등)

전자금융거래법 9조 1항
금융기관 또는 전자금융업자는 접근매체의 위조나 변조로 발생한 사고, 계약체결 또는 거래지시의 전자적 전송이나 처리과정에서 발생한 사고로 인하여 이용자에게 손해가 발생한 경우에는 그 손해를 배상할 책임을 진다. (단 이용자의 고의나 중대 과실이 있는 경우는 예외)

그 이유는 위 규정에 따라 이용자의 고의 및 중과실을 입증 하지 못하는 경우 금융기관의 손해배상 책임 부담이 강화 되기 때문입니다. 따라서 아래 보안 가이드는 공인 인증서 예외 상태에서도 충분한 보안을 유지 하기 위한 가이드로서 필요한 것입니다.

1. 전송데이터 보호

1.1 보안웹서버 구축

• 고객과 은행 서버간의 안전한 데이터 송수신을 위하여 SSL 보안웹서버를 구축한다.
• SSL Protocol의 종류중 SSL 버전2에서는 알려진 취약점이 존재하므로 보안서버는 SSL 버전3나 TLS 버전1 프로토콜만을 사용하도록 구성한다.
• SSL negotiation시 안전한 암호 알고리즘을 이용하도록 웹서버를 구성한다.
• 예를 들어 DES등의 사용을 금지하고 안전성이 입증된 SEED, 3DES 등을 이용
• SSL 서버 인증서는 신뢰할 수 있는 CA로부터 인증서를 발급받는다.
• 사용자가 SSL 서버 인증서와 도메인 및 사이트 운영 은행을 명확히 확인할 수 있도록 EV(Extended Validation) SSL 서버 인증서를 이용한다

2. 사용자 이용환경 보호

2.1 보안패치

• 사용자 이용 환경은 지속적으로 보안취약점이 발견되며 이를 보완할 패치가 필요함을 명시한다.
• 사용자에게 보안 업데이트의 중요성과 설치방법을 각 운영체제별로 충분히 안내하고윈도우 운영체제일 경우 한국정보보호 진흥원에서 제공하는 PC자동보안업데이트 프로그램을 설치안내한다.
• http://www.boho.or.kr/pccheck/pcch_05.jsp?page_id=5

2.2 개인방화벽

• 사용자 개인 PC에 대한 침입차단 및 보호를 위하여 개인 방화벽이 필요하다.
• 서버에서 사용자의 개인 PC 환경을 직접 제어할 수 없다는 기본적인 사실에 입각하여 다양한 운영체제에 맞는 개인 방화벽 프로그램이나 활성화하는 방법을 자세하게 안내한다.
• 다수 사용자가 많이 이용하는 운영환경에 대해서 은행이 자체 비용으로 해당 사용자 환경에 대해서만 제공할 수 있다.
• 이 경우에 프로그램 내려받기등의 방법으로 제공하며 원하지 않는 사용자에게 프로그램 설치를 강요하지 않는다.
• 단 이 경우에 금융 사고에 대비하여 금융 기관이 무과실을 입증할 수 있도록 사용자가 최신 개인 방화벽 프로그램을 사용하고 있었음을 기술적으로 알 수 있게 한다.

2.3 안티바이러스

• 사용자 개인 PC의 침입 감지 및 복구를 위하여 바이러스 방지 프로그램이 필요하다.
• 서버에서 사용자의 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실에 입각하여 다양한 운영체제에 맞는 바이러스 방지프로그램이 방지방법을 자세하게 안내한다.
• 윈도우즈 운영체제일 경우 한국정보보호진흥원에서 제공하는 무료 및 유료 바이러스 백신 프로그램 안내를 포함한다.
• http://www.boho.or.kr/pccheck/pcch_02.jsp?page_id=2
• 다수 사용자가 많이 이용하는 운영환경에 대해서 은행이 자체 비용으로 해당 사용자 환경에 대해서만 바이러스 방지 프로그램을 제공할 수 있다.
• 이 경우에도 프로그램 내려받기등의 방법으로 제공하며 원하지 않는 사용자에게 프로그램 설치를 강요하지 않는다.
• 단 이 경우에 금융 사고에 대비하여 금융 기관이 무과실을 입증할 수 있도록 사용자가 최신 안티바이러스 프로그램을 사용하고 있었음을 기술적으로 알 수 있게 한다.

2.4 키보드해킹방지

• 사용자 개인 PC가 설사 침해되었더라도 전자금융거래에서 최소한의 보안성을 확보하기 위하여 키보드 해킹방지 솔루션이 필요하다.
• 키보드 해킹방지 솔루션이 바이너리 프로그램으로 구현될 경우에는 특정 환경에서만 동작될 수 밖에 없는 구조적인 문제점이 있다.
• 이를 해결하기 위하여 사용자가 키 입력을 처음부터 하지 않도록 하는 형태의 스크린 키보드 해킹방지 솔루션이 적당하다.
• 자바스크립트 기반 온스크린 키보드 방식
• 운영체제 내장 스크린키보드는 통상 키 입력과정을 그대로 Simulation하기 때문에 키보드 해킹방지 효과가 없다.

2.5 자바스크립트 보안

• 오픈뱅크 뱅킹 프로세스 과정에서 자바스크립트는 사용자 뱅킹 환경이나 파라미터 제어를 위하여 중요하게 사용되며 이러한 자바스크립트 무결정을 보호하는 보안이 필요하다.
• 자바스크립트 무결성을 보장하기 위하여 다음 사항을 고려한다.
• 자바스크립트 난독기(obfuscation)를 적용
• 자바스크립트의 일부를 서버에서 필요시 동적으로 로딩하여 사용
• 자바스크립트의 주요 소스를 세션정보와 연계하여 Static하게 재사용 불가하도록 구성

3. 서비스 보안구성

3.1 꼭 필요한 정보만 명시적으로 제공

• 사용자의 개인정보는 사용자 자신을 포함해서 모든 경우에 대하여 안전하게 보호되어야한다.
• 서비스 제공 프로세스 전반에 걸쳐 사용자 자신의 정보라도 서비스 이용에 필요하지 않다면 사용자에게 제공하지 않는다.
• 예를 들어 사용자가 입력한 계좌번호라도 서비스 과정중에서 명시적으로 꼭 필요한 경우에 한하여 최소한의 노출빈도로 제공한다.
• 사용자 선택의 편의를 위하여 제공하는 경우 주요 정보를 Masking 처리한다.

3.2 웹어플리케이션 보안

3.2.1 크로스사이트 요청변조(CSRF)나 MITM(Man In the Middle) 공격등에 대한 대응

• CSRF나 MITM 형태의 공격은 아주 오래된 일반적인 해커의 공격방법이다.
• 유사한 형태로 sslsniffing, sslstrip 등을 들 수 있다.
• CSRF는 2007년 이래 가장 빈번하게 사용되는 해커의 공격방식이며 가장 최근의 국내 사례로는 A사의 1800만명 개인정보 유출사건이 있었다.
• 또한 피싱 사이트에 유인된 사용자의 입력정보를 실시간 변조하여 웹 어플리케이션을 공격하는 경우도 다수 존재하여 오픈뱅크의 서비스 환경에서는 이러한 공격방법에 대한 적극적인 대응이 필요하다.
• 다음과 같은 대응방안을 고려하여 웹어플리케이션을 보호한다.
• 사용자 인증이나 세션validation을 session cookie에만 의존하지 말고 GET이나 POST되는 파라미터에 포함된 토큰으로 추가 확인한다.
• 토큰은 서버에서 페이지별 또는 단위 기능별로 Unique하게 생성하여 사용자에게 응답
• HTTP Referer 정보를 철저하게 확인한다.
• referer spoofing을 방지하기 위하여 필히 SSL 세션 필요함
• Flash client에서의 공격에 대비하여 웹서버에 crossdomain.xml 파일을 생성하지 않도록 주의한다.
• 세션 타임아웃 설정등 엄격한 세션관리정책을 수행한다.
• 웹방화벽 이용
• 웹방화벽 이용시 Configuration을 완전하게 하는데 주의한다.

3.2.2. 피싱 방지를 위한 조치

• 사용자 아이디 입력 페이지와 로그인(사용자인증) 페이지를 순차로 배치하고, 로그인 페이지에는 해당 사용자가 미리 선택한 seal 이나 site key 아이콘이 뚜렷히 드러나도록 설계한다.
• 서버가 EV SSL 인증서를 채택하는 경우, 사용자들이 EV SSL 인증서 채택 서버에 접속해 있음을 확인하고 로그인 정보를 입력하도록, 해당 정보 입력란 근처에 설명, 안내한다.
• 사용자의 명시적 요청이 없는 한, 서버가 사용자에게 명세서, 기타 안내 이메일을 보내지 않는다.

3.2.3 OWASP 10대 보안위협에 대한 대응

• OWASP Top10 보안위협은 전세계적으로 해커들이 가장 자주 사용하는 보안위협요소를 정리하고 대응방안을 제시하고 있다.
• OWASP Guide에 근거한 웹어플리케이션의 보안성을 높이기 위하여 충분한 대응이 필요함.
• http://www.owasp.org/index.php/Top_10_2007

3.3 사용자 어카운트 관리

3.3.1 두가지 이상 요소로 사용자인증 (two-factor authentication)

• 명확하고 안전하게 사용자인증을 하기 위해서 최소한 2가지 이상의 방식을 복합하여 사용자인증을 할 필요가 있다.
• 사용되는 인증요소로는 다음사항을 고려한다.
• 패스워드 (조회 혹은 이체에 복수 사용 가능)
• 일회용 암호 생성기(OTP) 혹은 모바일 OTP 소프트웨어(Mobile OTP)
• 모바일 SMS 인증
• SSL Client Authentification 하의 공인 인증서 로그인
• 위 인증방식들을 제시하고 이중 사용자가 2개 이상을 복합적으로 선택하여 인증을 수행할 수 있도록 제공한다.
• 이렇게 하여 하나의 인증정보가 누출되더라도 다른 추가 인증 방식을 해커가 확보하기 어렵도록 하여 사용자를 보호할 수 있다.

3.3.2 엄격한 계정 관리정책 유지

• 사용자 계정에 대하여 오픈뱅크의 특성을 감안하여 기존 경험과 다소 다르더라도 엄격하게 계정 관리 정책을 유지해야한다.
• 권유되는 최소한의 계정관리 정책은 다음과 같다.
• 패스워드나 계정 리셋을 수행하는 경우 명확한 사용자확인 절차(오프라인 확인 등)를 거친다.
• 초기발급 패스워드는 최초 로그인시 갱신 유도
• 장기간 미사용 사용자에 대한 계정 잠금
• 패스워드 만료일 지정
• 패스워드 복잡성 증대
• 예전 패스워드 재사용 금지
• 반복적인 로그인 실패시의 계정 잠금
• 15분이상 Idle time 지속시 자동 로그아웃

4. 부인방지

4.1 사용자 본인 확인

• 사용자 본인 확인은 iPIN을 권장 한다.

4.2 사용자 부인 방지

• 사용자행위에 대한 부인방지 효력은 기본적으로 사용자의 오프라인 서명이나 인감날인, 온라인에서의 공인전자서명으로 발생된다.
• 온라인 공인인증서 의무 사용규정의 예외조항중 금감원장의 승인이 있는 경우를 주목하여 오프라인에서 사용자로부터 특정 인증정보 사용에 대한 부인방지 효력을 사전에 약정하고 인터넷 뱅킹 신청 시 사용자로부터 서명날인을 받는다.
• 오프라인 사전 약정에 근거하여 온라인에서 특정 인증정보 사용시 부인방지 효력을 부여한다. (예: 보안 카드 번호 + OTP 난수) 이를 공인 인증기관에 전달하여 보관한다. (인증기관의 일부 인증준칙(CPS) 개정 필요.)
• 이러한 방식에 대하여 금감원장의 승인을 득한다.
• 특정 인증정보로는 다음 사항을 고려한다.
• OTP 인증코드 사용
• 이체 비밀번호 사용
• 로그인 비밀번호 재입력
• 기타 플랫폼 의존적이지 않은 방식을 이용한다.
• 예, 인간 인지 기반 Video Captcha 방식 - 문자가 아닌 그림 기반 암호 설정

4.3 기술적 부인 방지

• 계좌 이체와 같은 금융 거래 시 악성 코드의 FORM 데이터 조작에 의해 사실 상 사용자의 부인 방지 자체에 위해가 가해질 수 있다.
• 공격에 의한 데이터 조작으로 인한 부인 방지를 위해 몇 가지 최소한의 기술적 절차적 수단을 강구한다.
• 거래 인증 : 이체와 같은 중요한 거래는 실시간으로 시행하지 않고, 시차를 두어 큐(Queue)에 쌓아둔 후, 사용자에 의해 이체 계좌 및 수취인을 온라인으로 재확인 후 거래 승인이 필요함.

4.4 추심 인증

• 온라인에서 모든 종류의 서비스를 한번에 실시간으로 제공하려고 하면서 보안관련 부담이 많이 발생되고 있다.
• 일정규모 이상의 고액거래(예,3천만원)나 위험도가 높은 거래에 대해서는 온라인이 아닌 다른 채널(예: SMS 혹은 OTP 암호, 전화 통화)을 통하여 2차 인증하는 정책을 유지해야한다.

5. 보안정책

5.1 보안정책의 공지 및 유지

• 서비스 운용에 필요한 합당한 보안정책을 수립하고 이 보안정책에 의하여 서비스를 운용하며 사용자가 보안정책의 정상운용유무를 확인할 수 있도록 보안정책과 운용상태를 공지해야한다.

5.2 바이너리 플러그인 사용정책

• 만일 사용자의 특정환경에 특화된 바이너리 플러그인을 사용해야한다면 플러그인이 꼭 필요한 경우만 특정환경에 한하여 일시적으로 활성화하여 사용하도록 해야함.

6. 서비스의 상호 운용성

• 오픈뱅크는 다양한 사용자 플랫폼에 대한 오픈된 서비스를 제공하는것과 다양한 서비스 제공자(Service Provider)들과의 유기적인 연계성을 확보하는것도 오픈뱅크의 취지를 고려할때 필요하다.
• 서비스 상호 운용성에 대한 자세한 설명은 다음 URL 참조
• http://docs.google.com/Doc?id=dd4mkptq_32zd3dkggd