전자금융거래 보안과 금융감독원

2011.05.05 글쓴이 youknowit

2009년말에 아이폰이 국내에 도입되면서, 그전까지는 (IE 웹브라우저 99% 상황때문에) 잘 느끼지 못했던 국내 전자금융거래의 여러 이슈들이 표면화되었습니다. 그때 오픈웹은 “금융감독원에 드리는 건의“라는 글에서 강제 규정에 의존해왔던 금융감독체제에서 벗어나 다양한 보안기술 동향이 신속히 반영될 수 있도록 유연한 규제체제로 전환하는 것이 바람직하다는 견해를 개진했었습니다.

그 후 있은 변화는 “공인인증서를 사용하여야 한다”는 규정이 “공인인증서와 동등한 수준의 안전성이 인정되는 인증방법을 사용하여야 한다”로 바뀐 것에 그쳤습니다.

최근 불거져나온 현대 캐피탈과 농협 사태에서 보듯이, 전자금융거래의 안전을 위협하는 요인은 고객(client) 측에만 존재하는 것이 아닙니다. 서버 측의 보안이 어쩌면 더 중요하다고 평가할 여지도 있습니다. 공인인증서 채택 강제 규정을 둔 내막과 이유가 있겠지만, 강제 규정을 둘 경우 마치 그것만 충족하면 만사 OK라는 오해를 불러일으키기 십상입니다. 금융기관이 자기 서비스에 대한 평가를 지속적으로 수행하고(직접하건 제3의 전문기관에 의뢰하건) 파악된 위험에 대응하는 향상된 보안조치를 계속해나가는 것이 중요함에도, 그저 (공인인증서 + 보안플러그인 3종세트) 강제규정만 충족하면 그만이라는 식의 입장이 득세하게된 것은 아니었는지를 반성할 필요가 있습니다.

더구나 금감원은 매우 “경직된” 태도를 보여왔습니다. 예를 들어, 개인방화벽 프로그램을 “우선적으로” 설치하라는 규정(전자금융감독규정시행세칙 제29조 제2항 제3호)이 있다는 이유로, “반드시 설치하게 한 다음, 삭제할 수 있도록 하라”는 식으로 지도해 왔습니다. 삭제할 프로그램을 억지로 한번 설치하게 만들어서 무엇하자는 것인지를 은행들이 아무리 문의해도 금감원은 “규정”만을 내세우면서 절벽같은 태도를 견지해왔습니다. 어차피 삭제할 프로그램일지라도 “일단은 무조건 깔아라”고 고집하는 것이 금감원이 추구하는 보안입니까? 보안을 위한 규정인지, 규정을 위한 보안인지? 아니면, 보안 업체의 영업을 위한 보안인지? 혹시, 금감원 직원의 권위와 위상을 확인하기 위한 보안이었던가요?

이런식의 규제 하에서는 보안업체 종사자들도 “스스로 생각할” 능력이 마비됩니다. 그래서 심지어 리눅스 유저를 위한 개인방화벽 플러그인을 바이너리(binary)형태로 내려주면서 무조건 설치하도록 강제하는 웃지못할 사태가 “보안”의 이름으로 저질러지는 것이 바로 국내의 열악한 보안 실상입니다. 소스코드도 공개되지 않은채 binary code 형태로만 제공되는 어떤 패키지를 “듣보잡” 서버로부터 내려받아 그 파일의 무결성을 확인하는 절차도 없이 자신의 컴퓨터에 설치한다는 것은 리눅스 운영체제에서는 보안의 기본 상식을 벗어난 일이지만, 금감원 “공무원이 하라니까 하는” 식으로 국내 보안 산업은 철저히 전문가 무시/규정 만능으로 일관해 왔던 것입니다. “강제 규정”으로 보안을 해결하려는 발상은 이런 불행한 결과를 낳을 수밖에 없습니다.

금감원이 그동안 견지해 왔던 전자금융 감독기법은 이번 여러 사태를 거울 삼아 근본적인 반성이 있어야 할 것입니다. 조직개편과 인적쇄신의 노력도 물론 필요하겠지만, 현행 전자금융감독규정 자체를 전면 재검토 할 필요가 있습니다:

  • 특정 기술을 강제하는 것은 부작용만 낳게 됩니다. 바젤위원회가 채택한 전자금융위험관리 원칙에서 “should”라고 적힌 부분은 “…하는 것이 좋다”는 뜻이지, “…하여야 한다”는 뜻이 아닙니다.
  • 서비스는 가능한 한 별도 프로그램 설치가 필요 없도록 설계되는 것이 좋습니다.유저들에게 프로그램을 꼭 배포해야만 할 경우라면, 신원확인이 가능한 서버로부터 배포되어야 옳습니다. 어느 서버로부터 내려받아졌는지 확인조차 할 수 없는 어떤 프로그램을 설치하라고 강요하는 일은 이제 좀 그만하시죠. 구글 크롬 확장프로그램이 배포되는 서버 https://chrome.google.com/extensions/?hl=ko , 파이어폭스 확장이 배포되는 서버 https://addons.mozilla.org 들이 왜 모두 https 접속을 하는지 곰곰히 생각해 보시면 좋겠습니다.
  • 금융기관이 전자금융거래 설계를 외주(outsourcing)에 의존할 때 특별히 챙겨야할 부분들이 있습니다. 이 부분에 대한 효과적인 감독 기제가 무엇일지를 고민해야 합니다. 이 글 참조. 이 부분 역시 섣불리 강제 규정을 도입하여 해결하려는 우를 범하지 않기 바랍니다.
  • 금융사고 발생 현황을 금감원이 정확하게 파악할 수 있는 메카니즘이 필요합니다. 금융기관이 숨기면 할 수 없다고요? 조금만 생각해보시면 여러 효과적인 방법이 있을 것입니다. “공인인증서+보안 플러그인3종세트” 사용만 무작정 강제하면서, 정작 사고현황과 규모는 제대로 파악도 못하고 있는 현재의 금감원은 자신의 규제 기법에 대하여 진지한 반성이 필요합니다.

공인인증 플러그인 기술에 대한 집착은 이제 극복할 때가 왔습니다. 좀더 큰 안목에서 올바른 보안 기본 원칙과 근본 가치에 충실한 방향으로 전자금융 감독체제가 개선되었으면 하는 희망입니다. 플러그인 설치를 유저에게 강제한다고 해서 한국의 전자금융거래 보안이 확보되는 것이 아니라는 점은 이번 일련의 사태에서 드러났지 않습니까? 보안전문 기술인력의 판단과 선택을 존중하고, 업계의 자율성과 창의성이 활발히 발현될 수 있도록 지원하는 반면, 투명하게 파악된 사고 현황을 토대로 각 금융기관의 “보안 performance”를 관리하는 쪽으로 금융감독 정책의 대전환이 요구되는 시점이 왔습니다.

이렇게 해야 보안 전문인력과 보안업계의 활발한 성장도 가능할 것입니다. 그저 강제 규정이 “하라는 것이나 하는” 현재 국내 보안업계의 수동적 구도는 아무에게도 도움이 되지 않습니다.

Categories: 보안, 정책제안 | Comments Off  오픈웹 구독 메일로 받기

«

»