을의 Digital Finance 블로그(9)
금융보안-보안성과 편의성/생산성은 항상 Trade off 관계인가 ?
금융IT, Digital Finance에 있어서 보안의 중요성은 아무리 강조해도 지나치지 않다. 하지만 보안을 강조하다 보면, 사용자의 편의성이 훼손되고 SW개발이 지연되고 의도치 않은 장애가 발생하는 등 편의성/생산성에 지대한 영향을 미치기도 한다. 본 블로그에서는 보안성과 편의성/생산성의 Trade off 관계를 보다 효과적으로 관리하는 관점에 대해서 고민해 보고자 한다.
금융권에서는 2014년 카드 3사 보안 사고가 가장 회자되고 있지만, 이미 2010여 년부터 적지 않은 중대형 보안사고가 발생하고 있었다. 그 배경에는 대출, 보험 판매를 위한 텔레마케팅 경쟁이 격화되면서 개인정보의 가치가 높아지고 있었던 환경과도 관련이 있었다고 생각한다. 필자도 2011년 모 금융사 CIO(카드사, 캐피탈사 겸임) 재직시절 해킹 사고로 1년 가까이 보안 규정과 시스템을 재정비하면서, 전사적으로 보안에 대한 인식을 강화하는 데 많은 시간과 노력을 쏟았던 경험이 있었다. 그 과정에서 많은 개인들이 징계를 받았으며, 필자도 회사뿐만 아니라 감독기관으로부터 중징계를 받았던 아픈 기억이 있었다. 회사 입장에서도 금융사로서의 신뢰 이미지가 손상되고 신 사업 진출을 위한 감독기관 허가신청을 연기해야 하는 피해를 감수해야 했지만, 한편으로는 혁신과 자율을 중시하던 기업문화에도 적지 않은 부정적인 영향이 있었다. 그 당시 보안을 강화했던 전사적인 노력의 결과로, 2014년 카드 보안사고를 비켜갈 수 있었지만 정말 많은 비용을 치른 다음이었다.
2014년 카드 보안사고는 금융IT가 발전하기 위한 성장통의 하나라고도 볼 수 있지만, 금융산업 각각의 이해당사자들에게도 많은 부정적인 영향을 끼치게 되었다고 생각한다. 금융지주사는 설립취지 중의 하나였던, 고객정보공유가 엄격히 금지되면서 지금도 고객정보공유를 통한 시너지를 창출하는 데 어려움을 겪고 있고, 개별 금융사도 감독규정의 강화에 대응하여 고객정보에 대한 관리 프로세스를 강화하면서 고객정보 활용에 많은 제약을 받고 있다. 금융소비자 입장에서도 상품가입과정에서의 불편한 경험 (이해하기 힘든 깨알 같은 작은 폰트의 약관 동의)을, 고객정보제공 제공 과정에서 수없이 반복하게 되었다. 어떻게 보면 이러한 일률적인 보안강화 프로세스의 진정한 피해자는 금융소비자라고도 생각된다. IT개발 과정에서도 개발 보안강화, 보안성 심의를 포함한 절차가 강화되면서, 개발팀과 보안팀 간의 갈등도 격화되었고, IT운영 과정에서도 정기적인 모의해킹과 보안진단의 개선권고를 반영하기 위해 많은 시간과 노력을 기울이게 되었다.
현직에서 금융보안을 강화하는 과정에서 계속 고민했던 주제는, 보안성과 편리성/생산성의 Trade off였다. 보안 수준을 높이려면, 당연히 시간과 노력이 소요되고, 사용자는 불편해지고 개발의 생산성과 효율성은 하락하게 된다는 주장에 논리적 하자는 없다. 하지만 현장에서 매일 마주하는 이슈는 인력의 부족, 시간의 부족에도 불구하고 양보할 수 없는 보안요건을 적시에 충족시키는 방안이다. 새로운 클라우드 환경에서 외부와의 연결성이 강화되면서 보안은 더욱 어려운 주제가 되었다. 완벽한 답이 될 수는 없겠지만, 현장의 문제를 다루기 위한 몇 가지 관점과 기준을 고민해 보고자 한다. 보안에 대한 전체적인 시각이 필요한 리더나, 개별보안요건에 집중해야 하는 현장의 개발자들도 전체적인 보안에 관한 관점과 기준을 이해하고 있으면 보다 효과적으로 업무를 수행할 수 있을 거라 생각한다.
먼저 초연결 시대, 클라우드 등 변화하는 환경에서도 적용할 수 있는 전반적인 보안에 대한 몇 가지 중요한 관점과 접근법을 생각해 보고자 한다.
첫째, 리스크 기반의 보안(Risk Based) 정책을 고민해야 한다. 위험이 있는 곳에 방비를 더 강화하자는 관점이다. 전쟁에서도 적의 공격이 예상되는 지점, 위험도가 높은 지역에 보초도 더 세우고, 방비를 강화하는 논점과 동일하다. 이런 관점에서 외부 해킹의 가능성이 높은, 네트워크 구간에 많은 보안시스템을 갖추어 놓는다. 내부 네트워크구간보다 위험이 높은 DMZ구간에, 보다 강력한 네트워크 보안 장비를 설치하고 운영한다. 업무시스템(Application) 중에서도 내부사용자만 사용하는 업무시스템들보다, 외부 고객에게 노출되어 있는 Web, Mobile 시스템의 보안을 더 강화해야 한다. 나아가 사용자가 적은 Web, Mobile보다 사용자가 많은 Web, Mobile 시스템에 대해서는 취약점 점검과 모의해킹 주기도 단축시켜야 한다. 보호해야 할 정보 관점에서도, 개인정보는 마스킹하고 암호화하여 보다 안전하게 관리해야 한다. 기업 내 인력도 리스크에 따라, 관리자, 현업사용자 보다 IT직원의 리스크 등급이 더 높고, IT직원 중에서도 DB관리자를 포함하여 IT시스템을 직접 접근할 수 있는 루트계정을 가진 슈퍼유저의 리스크 등급이 더 높다. 리스크 등급이 높을수록, 망분리 및 기기접근 권한관리를 더 강화해야 한다. 여기서 리스크를 판정하는 기준은, 기업마다 비지니스 가치의 기준이 다르듯이 기업마다 상이하다. 보안을 담당하는 부서에서, 관련 부서와 논의하여 전사적으로 정의하고 전반적인 정책으로 수립해 놓는 것이 필요하다고 생각한다.
둘째, 효과적인 다중보안(Multi Layer) 정책을 검토해야 한다. 방어선이 하나인 것 보다, 방어선을 여럿 두어야 방비를 강화할 수 있다. 네트워크, 애플리케이션, DB 등 Layer별로 방어선을 구축하고 운영하는 방식이다. 네트워크 영역에서도 방화벽부터 무선침입차단시스템(WIPS)을 포함한 복수의 침입차단시스템(IPS)이 있다. 특히 해킹과 같은 보안위협은 한번 뚫리면 대량의 정보유출로 이어지기 때문에, 다중 보안이 필수적이다. 하지만 정기적으로 다중보안의 효과성과 비용효율성을 점검하면서 효율성을 높이는 방안을 고민해봐야 한다.
셋째, 회복력이 중요한 시대에 보안 탄력성(Security Resillience)을 고려해야 한다. 금융 IT는 고객, 파트너, 직원들 사이의 연결성을 강화하고 있으며, 사람, 기기, 데이터 사이의 연결점을 끊임없이 확장시키고 있다. 점점 더 개별자원에 대한 보안이 아니라, 탐지하고 대응하고 복구하는 관점이 더 중요해진다. 모든 시스템의 가시성을 높이고, 구체적인 위협과 취약점 정보를 통합하여 동종업계와 비교하면서, 끊임없이 변화하는 업무환경, IT환경에 대응해 가야 한다. 과거 로그정보를 통합, 분석하는 수준을 넘어, 모든 시스템의 정보와 취약점, 위협정보를 통합 분석하는 위협 인텔리전스를 강화하면서, 가장 큰 Top10 보안위협은 무엇인지, 위협을 탐지할 준비가 되어있는지, 위협이 노출된 곳은 어디이고, 위협이 미치는 영향을 신속하게 완화하거나 복구할 수 있는지에 대해 지속적으로 질문하고 개선해가야 한다.
넷째, 클라우드 보안에 대한 보다 깊은 고민이 필요하다. 금융권에서는 망분리 규정에 막혀, 퍼블릭 클라우드 도입에 시간이 걸리고 있지만, 디지털 플랫폼, 분석 영역 등에서 퍼블릭 클라우드의 장점을 활용하는 금융기관이 늘고 있다. 일견 클라우드는 보안이 약하다고 하지만, 인프라로 좁혀보면 보안을 더 강화할 수 있는 여지가 많다. 특히 항상 내부 인프라 인력은 부족한 반면에, 클라우드에는 이미 Managed 서비스 방식으로 보안을 강화하는 많은 옵션들이 있다. 금융기관 내부적으로 담당할 부분과 클라우드를 통해 해결할 부분을 구분하는 것부터, 클라우드에 대한 깊은 이해를 필요로 한다. 국내 금융그룹에서도 보안랜딩존을 구성하여, 서버보안 솔루션을 통일하고 프라이빗 클라우드와 퍼블릭 클라우드를 같이 관리하는 방식도 발전하고 있다. 초연결의 시대에 금융권 망분리 규제도 점점 완화되리라고 예상된다. 실제 망분리 규정으로 인해, 정작 경쟁력 있는 SaaS 기반의 보안 솔루션들을 사용하지 못했었던 불합리함도 완화되리라고 생각된다.
이하에서는 추가적으로 보안을 강화하면서 수반되는 현상으로, SW의 사용성, 편의성이 낮아지고 또 개발생산성이 저하되는 Trade off를 어떻게 관리하는 것이 좋을지 고민해 본다.
첫째, 보안성과 함께 고객경험을 훼손하지 않는 UI/UX, 프로세스를 탐색해야 한다. 보안은 고객, 사용자가 아니라 기업의 책임이 되었다. 과거에 보안을 강화하기 위해, Active X기반의 공인인증서를 발급받고 사용하는 불편한 과정을 모두 고객이 부담하기도 했었다. 결과적으로 고객 경험이 훼손되었고, 핀테크 중심으로 간편 인증이 도입되었다. 핀테크는 전통적인 금융기관 대비 위험을 감수하는 성향이 있기도 했지만, 실제적인 보안위험을 줄이면서, 고객의 편의성도 높이는 UI/UX, 프로세스에 대해 치열히 고민해 왔다. 핀테크사의 메기역할 덕분에 전통적인 금융기관들도 새로운 간편 인증 프로세스를 앞다투어 내놓고 있다. 규제기관의 입장에서도 규제를 구체화하고 감독관리하는 입장보다는, 보안의 전체적인 책임은 금융기관이 부담하면서 자율적으로 보안을 강화하는 것을 지지하는 입장이다. 오픈 뱅킹, 마이 데이타 출범에 맞추어, 토스는 사용자가 이해하기 쉬운 용어 사용과 함께 정보동의 프로세스를 획기적으로 개선하면서 국내 리딩 금융 플랫폼으로서의 자리를 굳히고 있다.보안위험을 잘 관리하는 것이 금융기관 경쟁력 강화로 이어지고 있다.
둘째, 자동화(Automation)된 선제적인 보안 프로세스를 고민하고 지속적으로 개선해야 한다. 보안은 개발 초기부터 계획되고 반영되어야 한다. 전체적인 보안 요건과 보안 아키텍처에 대한 고민은 프로젝트의 초기단계부터 시작해야 한다. Agile 개발 방식에 따라, Sprint 단위의 개발을 진행하면서 미리 미리 보안요구사항을 반영해 나가는 방식이 바람직하다. 이를 위해서는 DevOps 방식으로 CI/CD 툴 체인을 통해, 자동화된 방식으로 통합과 배포를 진행하는 것이 필수적이다. 아직도 Waterfall 방식의 개발이 많지만, 사전에 보안요건을 구체화하여 개발자에 개발보안 가이드를 배포하고 준수하게 하는 과정부터, 가능한 자동화된 CI/CD 툴 체인을 적용하게 하면 마지막 순간에 보안위험을 감수하고 출시해야 하는 어려운 상황을 줄일 수 있다. 금융기관에서는 CI/CD 툴 체인을 도입하고 프로세스를 정비하지만, 수작업 승인 프로세스를 줄이는 데는 어려움을 겪고 있다. 작업 프로세스별로 수작업 승인 프로세스를 유지하기보다는, 자동화된 방식으로 통합과 배포를 진행하면서 로그, 감사추적 방식으로 지속적으로 보안위험을 파악하고, 이들 보안위험을 완화시키기 위한 요건을 자동화된 프로세스에 반영하는 방식으로 개선해 가는 것이 바람직하다고 생각한다.
셋째, 개발생산성에 영향을 미치는 보안 권한 문제에 대해 주기적인 전향적인 검토가 필요하다. 통상 사용자에 대해서는 Need To Know 기반으로 접근권한이 주어지고, 개발자, 시스템 운영자에 대해서도 작업에 필요한 정도의 접근권한이 주어진다. 통상 개발자는 운영환경에 접근하지 못하고, 개발에 있어서도 오픈소스를 제대로 활용하기 어려운 환경이다. 개발과정에 필요한 오픈소스를 활용하는데 있어, 실제 오픈소스를 반입하고, 검증하는 절차의 복잡성으로 생산성에 정말 많은 악영향을 미치고 있다. 일부 금융기관에서는 별도 Sand Box 방식으로 인터넷에 연결하여 자유롭게 오픈소스를 활용하여 개발하고 난 후, 코드를 반입하는 방식을 고민하기도 한다. 개발뿐만 아니라 운영 과정에서도 외주 작업자에 대해서는 과도한 권한 제한이 있어, 실제 작업과 장애대응을 하는 데 수시로 갑사 직원의 계정을 사용해야 경우가 적지 않다. 외주 작업자 입장에서도 효과적인 작업을 하지 못할 뿐 아니라, 시스템을 전체적으로 이해할 수 있는 성장의 기회가 제한된다. 현재의 보안 규제, 규정을 잘 살펴보면서 무조건적인 권한 제한은 아닌지 주기적으로 검토할 필요가 있다. 리스크가 그리 크지 않다면, 권한 부여 주기를 제한하는 방식이든 실시간 모니터링 방식이든 개발 생산성에 영향을 주지 않으면서 보안 수준을 유지하는 여러 방안을 검토할 필요가 있다.
보안강화와 편의성/생산성의 Trade Off를 일차적인 수준에서 멈추고 타협하면 결국 전체적인 효과성, 효율성이 침해된다. Level 1에서 멈추고 타협하지 말고, Level2, Level3 더 낮은 수준까지 치열하게 고민하면서 두 마리의 토끼를 잡으려는 노력이 필요하다. 보다 디테일한 수준에서 보안위험을 높이지 않으면서도, 사용자 편의성을 높이고 생산성을 강화하는 방법을 고민하고, 이를 CI/CD 자동화 프로세스에 반영해가야 한다. 이러한 과정을 통해, 현업 그리고 개발자 모두 관련 비지니스에 대한 이해도와 시스템에 대한 장악력을 높일 수 있다고 생각한다.
