[박종필 젬알토 이사] 아이디/비밀번호! 이 단순한 사용자 인증에만 의존하고 있다면, 언제 민감한 데이터가 외부로 유출될지 모른다. 해커가 민감한 기업 정보를 빼낼 때 가장 선호하는 방법인 사용자 계정을 먼저 훔치는 것이다. 이런 이유로 대형 서비스 사업자, 금융기관, 기업들은 더는 아이디/비밀번호에만 의지하지 않는다. 아이디/비밀번호에 OTP, 디지털 인증서 등의 추가 인증 수단을 더한다. 다양한 수단이 동원되고 다양한 형태의 보안 토큰을 사용자들에게 나누어 주면 ‘보안 수준’은 매우 높아진다. 문제는 운영과 관리 부담과 비용 증가라는 새로운 고민이 생긴다는 것이다. 이를 어떻게 해결하는 방법은 기본과 원칙을 지키는 것이다. 
 
◇아이덴티티, 새로운 고민거리로 떠올라
사용자 아이덴티티를 빼가는 수법은 점점 더 정교해진다. 또한, 내부 사용자의 실수나 고의로 인한 사고 역시 빈번하게 일어나고 있다. 하지만 기업은 사용자 아이덴티티 보호를 점점 어려워하고 있다. 사용자들은 회사에서 지급한 PC로만 사내망, 시스템, 데이터에 접근하지 않는다. 다양한 개인 소유 장치를 이용해 여러 위치에서 접근한다. 그리고 사용자들은 사내에 있는 시스템뿐 아니라 공용 클라우드에서 제공하는 서비스를 이용해 업무를 본다.
 
예를 하나 들어보자. 마이크로소프트 Office 365로 조직원에게 이메일, 팀 사이트, 메신저 등의 서비스를 제공하고 ERP 등 기간계 업무는 사내에 있는 시스템을 이용하는 기업을 찾는 것은 어려운 일이 아니다. 이처럼 애플리케이션/서비스의 위치 그리고 데이터의 위치가 다양해 지고 있으며, 이들에 접근하는 사용자는 시간과 장소 구분 없이 다양한 장치를 이용한다. 애플리케이션/서비스, 데이터에 대한 접근성과 이용 편의성이 높아진다는 것은 곧 보안 위협도 함께 커짐을 뜻한다. 보호할 대상, 위치가 많아지기 때문이다. 여기에 데이터 보호 관련 규제 강도가 높아지는 것도 부담으로 다가온다.
 
◇다중 인증이 유일한 해결책
사용자 아이덴티티 관련 최근 동향은 ‘다중 인증’이다. 우리가 일상적으로 쓰는 포탈, 검색엔진, 소셜 네트워크 서비스 등은 사용자 아이덴티티 보호를 위해 주기적인 비밀번호 변경과 함께 이중 인중 이용을 권장하고 있다. 이는 기업 역시 다르지 않다. 아이디/패스워드 방식이 갖는 보안 허점에 대한 인식이 퍼지면서 강력한 사용자 인증 수단 확보 차원에서 이중 인증 체제로 전환하는 곳이 늘고 있다. 다중 인증을 적용하는 방식은 조직 구성, 업무 절차, 사용하는 업무용 장치 등 여러 가지 특수성을 고려해 선택해야 한다. 일반적으로 기업들이 고려하는 다중 인증 방식은 다음과 같다.
 
-일회용비밀번호(OTP) 기반 인증: 최근 가장 일반적으로 쓰이는 방식으로 사용자 인증 장치와 인증 처리를 분리하는 방식이다.
-인증서 기반 인증: PKI를 활용하는 인증으로 공인인증서를 통한 인증이 이에 해당한다.
-컨텍스트 기반 인증: 장치, 위치, IP 주소 등 사용자 상황 정보를 토대로 인증을 처리하는 것이다. 마이크로소프트 SharePoint Server 등 비즈니스 애플리케이션에서 채용하는 경우가 많다.
 
보안 토큰을 한 가지만 쓸 수 있을까?
 
사용자 인증 방식이 다양한 것만큼 인증 장치인 보안 토큰 역시 그 종류가 많다. 보안 관리자는 이중 어느 한 가지 유형을 통일해 쓰는 것을 원할 것이다. 하지만 한 가지로 모든 것을 통일하는 것은 생각처럼 간단하지 않다. 조직원의 역할과 권한은 세부적으로 나뉜다. 그리고 접근 제어 대상 데이터와 비즈니스 애플리케이션은 많다. 조직원뿐 아니라 협력사 파견 인력, 계약직 등 외부인을 위한 인증 수단도 필요하다. 여러 조건과 상황을 종합해 보면 결국 다양한 보안 토큰이 쓰일 수밖에 없다는 답이 나온다. 가령 일반 사용자는 OTP로 인증을 한다. 이들에게는 OPT 장치를 배포한다. 그리고 외부 사용자에게는 모바일 OTP나 SMS를 통한 OOB(Out of Band) 인증을 적용한다. 이들에게는 별도의 인증 장치를 배포할 필요 없다.
 
◇다양성을 수용하는 포괄적 접근이 필요
다중 인증을 현실적으로 수용하는 방법은 ‘다양성’을 인정하는 것이다. 인증 방식, 보안 토큰은 유연하게 필요에 따라 적용하는 것이 좋다. 빅뱅 방식으로 전사 차원에서 하나로 통일하면 여러 부작용이 나올 수 있다. 대표적인 것이 종속성이다. 인증 방식과 수단을 하나로 강제하고 이를 기준으로 데이터, 애플리케이션에 대한 접근 제어, 감사/통제를 할 경우 이런저런 커스터마이징 작업이 이루어진다. 즉, 나중에 인증 방식과 보안 토큰을 바꾸려면 이것저것 함께 손봐야 할 것이 생긴다. 이런 종속성의 딜레마에 빠지지 않으려면 다음과 같은 네 가지 요건을 충족시키는 전략을 짜야 한다.
 
-프로그래밍 가능한 보안 토큰 사용: 보안 정책이나 절차가 변하면 그에 맞춰 유연하게 토큰값을 프로그래밍해 배포할 수 있어야 한다. 
-토큰 정보 암호화: 보안 토큰값은 암호화를 통해 이중 안전장치를 해야 합니다. 그리고 암호화된 토큰 값은 전용 장치(HSM)에 보관해야 한다.
-관리 효율성과 가시성 확보: 보안 토큰 배포, 업데이트, 교체 등의 관리 작업을 중앙집중적으로 할 수 있어야 한다.
-업계 표준 준수: 암호화 알고리즘(AES, SHA, DES 등), 업계 표준 및 API(PKCS, Java Card, X.509 등)을 따라야 한다.
 
위 네 가지 기준을 따르는 사용자 인증 체제를 갖춘 예를 도식화하면 다음 그림과 같다. 사용자는 다양한 인증 방식과 보안 토큰을 이용해 사내 망, 엔터프라이즈 포탈, 데스크톱 가상화 인프라(VDI), VPN, 클라우드 애플리케이션 등에 접근한다. 그리고 이에 대한 관리는 하나의 관점으로 이루어진다.

 
◇전사 차원의 사용자 인증 프레임워크가 해결책
앞서 언급한 바와 같이 다중 인증은 기업의 조건, 환경, 필요, 정책에 따라 다양한 인증 방식과 보안 토큰이 활용된다. 그리고 이런 다양성을 수용해야 하는 것이 보안 관리자에게 새로운 도전 과제가 되었다. 이를 해결하는 가장 확실한 방법은 사용자 인증 방식과 보안 토큰을 중앙집중적으로 처리, 관리할 수 있는 표준 플랫폼을 구축하는 것이다. 그리고 사용자 인증 관련 정보(credential)을 안전하게 보호하는 신뢰 기반으로 하드웨어 시큐리티 모델(HSM)을 배치해야 한다. 이 두 가지는 포인트 솔루션 차원이 아니라 프레임워크 차원에서 접근해야 한다.
 
[글. 젬알토 박종필 이사]