홈 > Privacy Guide >Privacy 컬럼
제목 보안을 편리하게 서비스 할 수 있다면
닉네임 강용석 작성일 2015-01-23 오후 6:10:33 인기도

                                     보안을 편리하게 서비스 할 수 있다면

 

최근 해킹사고의 패턴을 간단하게 요약해 보면 이렇다. 악의적인 공격자가 백신이 탐지하지 못하는 신종 악성코드를 배포하고, 이 악성코드에 감염된 매체를 통해 개인정보를 무작위로 탈취한다. 탈취한 개인정보를 분석해 기업사이트의 계정과 패스워드를 알아내고, 이를 이용해 기업의 고객정보를 탈취하면 고객정보 유출사건이 되고, 해당 기업의 정보시스템 서비스를 중단시키면 해킹사고가 된다.

그럼 우리 기업들은 이를 방지하기 위해 어떠한 보안체계를 구축해오고 있는가? 현재 우리 기업들은 보안의 1선이라 할 수 있는 Network Perimeter의 침입차단과 탐지, 모니터링과 같은 대비책에 초점을 맞추고 있으며, 대부분의 투자 역시 Network 보안 솔루션과 시스템 구축에 집중하고 있다. VPN으로 승인 받은 사용자만이 보안체계의 1, 즉 내부망에 접속할 수 있다는 믿음 때문에 이에 대한 보호만 집중적으로 하면 된다는 것이다. 여기에다 정보시스템의 효율성과 편의성에 대한 수요 때문에 모든 사용자의 권한을 통제하는 것도 망설이고 있는 현실이다.

이 같은 태도가 어떠한 결과를 가져오는지 최근 발생한 해킹사고 사례를 통해 살펴보자. 정부정책에 따라 모든 공공기관은 인터넷 망분리를 위해 관련 솔루션 도입을 추진해 왔다. 인터넷으로부터 내부 Network을 격리하고자 한 것이다. 그러다 보니 사용자들의 업무 효율성 저하가 나타났고, 이에 대한 대안으로 이메일 연동, USB사용승인, 망연계시스템과 망간자료전송시스템을 추가 도입했다. 결과적으로 악성코드가 내부망으로 침투하는 길을 다시 열어준 셈이 되어 버린 것이다

일반적으로 DMZ서버의 취약점이나 탐지할 수 없는 악성코드를 해킹 사고의 원인으로 들지만, 결국 그 이면에는 계정권한관리 미흡, 사용자 인증의 부재, 그리고 접근권한에 대한 모니터링과 관리 프로세스의 미비 등 다양한 원인이 있었던 것으로 봐야 한다. 그래서 그 동안 발생한 해킹사고에 있어 망 분리된 내부 네트워크상에 있는 모든 문서가 DRM으로 암호화 조치 되었다면’, ‘퇴직자의 계정과 권한이 관리되고 있었다면이라는 아쉬움이 남는다.

우리 앞에 닥친 보안 이슈를 해결하기 위해서는 우선 보안을 바라보던 패러다임의 변화가 필요하다. 첫째는 서비스를 각각의 속성에 맞도록 공간화해야 한다. 예를 들어 전체 네트워크를 망의 분리대상으로 삼으면 모든 네트워크를 하나의 정책으로 일원화 해야 하는 맹점이 생긴다. 하지만 서비스 성격에 맞춰 정책을 구체화하고, 네트워크를 설계/분리하면 이와 같은 맹점을 해결할 수 있다.

이는 우리가 살고 있는 아파트 경비체계를 생각해 보면 쉽게 이해할 수 있다. 아파트 단지를 둘러싼 경계를 1, 각 동별 출입구를 2, 그리고 호수별 출입구를 3선으로 구분해 외부자 방문을 통제하는 것과 같이 보안에 있어서도 접근 통제정책이 반영돼야 하는 것이다.

이러한 형태로 3선의 보안을 분리하고 각기 다른 접근통제 정책을 반영해야 하는데 접근통제의 정책은 계정(Accounting), 권한(Authorization), 인증(Authentication), 감사(Auditing), 관리(Administration)의 다섯 가지 측면에서 설계하고 적용해야 한다.

이용자를 분류함에 있어 'IT서비스에 접근하는 신뢰할 수 있는 사용자’, ‘일반사용자’, 그리고 위험사용자라는 3계층으로 분류하는데, 이는 Compliance측면의 요구사항에 근거한 보안정책에 근거하고 있다.

신뢰할 수 있는 사용자는 기존에 등록된 정보와 동일한 사용자로 최소한의 인증을 통해 IT서비스에 접속할 수 있다. 일반 사용자는 최초 접속이거나 기존에 등록된 정보와 일정 부분 차이가 있는 사용자로 반드시 인증 수단을 거쳐야만 접속을 허용하도록 해야 한다.

위험 사용자는 악성코드 배포, 해킹의 위험군으로 분류된 IP주소나 과거 보안사고에 연루되었던 사용자를 비롯해, 일정시간 내에 물리적으로 이동이 불가한 지역에서 접속을 시도하는 자로 매우 강화된 인증과정을 거치도록 해야 한다. 가장 먼저 Blacklist기반의 차단 정책에 반영되어 있는 사용자에 대해서는 접속을 차단하고, Whitelist기반의 사용자는 ID, Password, 등록된 정보 또는 과거의 접속했던 이력정보와 일치하는 경우에만 신뢰할 수 있는 사용자로 간주하여 접속을 승인하도록 한다.

위험 사용자에 대해서는 접근에 대한 이상행위를 기반으로 판별해야 한다. 로그인 시도, 개인정보 조회, 거래 요청에 있어 사용자, 디바이스, 위치 등 모든 정보를 수집해 과거의 이력과 비교하여 위험평가를 실시하고, 결과에 따라 위험등급을 산정해야 한다. 그리고 해당 등급에 대해서는 사전에 정의된 보안정책 및 사용자의 Profile을 활용하여 판단 Rule에 따라 접속에 대한 승인, 추가인증 요청, 접속거부의 결과로 구성해야 한다.

보안정책에 따른 위험평가의 결과는 항시 다면적 결과를 보이기 때문에 완벽할 수 없고, 매번 추가적인 인증 등 요구사항을 실시하는 것은 신뢰할 수 있는 사용자에 대한 편의성 확보에 어려움을 주고 있다. 그러므로 병합된 형태의 판단 Rule을 생성하여 그에 따른 종합적인 결정을 해야 한다. 종합적인 판단은 시나리오 기반으로 이뤄지며, 시나리오는 최초 접속 이후 1시간 안에 100km 이상 떨어진 위치에서 접근시도, 10초 내에 3회 연속 인증을 실패한 IP에서 접속한 거래 시도, 해외접속 경험이 없는 사용자의 심야시간 접속시도 등의 예시로 정의할 수 있다.

결론적으로 기존에 등록된 사용자의 기본정보가 100% 일치하지 않거나, 기본정보가 일치한다고 하더라도 이상행위에 대한 정책이 적용되는 사용자라면 추가적인 2차 검증을 요구하여 접근을 승인하거나 차단해야 한다. 만일 2차 검증에 실패한 사용자는 유형관리에 등록하고, 재차 접속을 시도할 경우에는 횟수를 제한하여 Blacklist로 등록하여 접속을 차단해야 한다. 또한, 이렇게 정의된 결과 값은 접속유형관리를 통하여 위험관리모델로 Feedback하는 것 역시 지속적인 보안관리를 위해 필요하다.

위험평가에 따라 2차 검증이 필요한 사용자에 대해서는 반드시 추가적인 인증수단을 활용하여 다단계의 접속을 유도하고, 인증 유무에 따라 유형을 관리하여 추후에 해당 사용자의 접속에 대한 정책을 반영하여 관리해야 한다. 인증수단은 PKI를 활용한 인증서 기반의 인증, HW/SW 형태의 OTP SMS를 활용한 문자OTP방식, Q&A방식과 화면에 보여지는 문자를 입력하는 Captcha 방식 등 매우 다양한 형태로 존재하고 있다. 이러한 인증기법들을 다단계의 접속을 유도하기 위한 방식으로 구성하면 매우 안전한 서비스를 제공할 수 있다.

이러한 프로세스의 반영은 DB, 서버, 네트워크 장비뿐만 아니라 비즈니스 어플리케이션에 접속하는 모든 사용자에 대해 필요하다. 또한, 최근 화두가 되고 있는 개인정보보호법 및 정보통신기반보호법 등의 Compliance 요구사항을 준수하고 기업과 기관의 보안정책에 따라 계정의 Life-Cycle 및 권한을 관리하고 이상행위에 대한 감사추적을 실시하는 것도 유도할 수 있다. 무엇보다 IT서비스를 이용하는 일반 사용자들 즉, 사무실에서 정해진 단말을 통해 업무를 수행하는 대부분의 사용자들에게 ID/Password만 입력해도 당장의 업무를 사용할 수 있도록 편의성을 보장할 수 있다.

결국 네트워크를 서비스 속성에 맞추어서 분리하고 구분된 네트워크 별로 위험평가에 따른 검증을 통한 접근통제 정책을 반영하는 것은 사용자 스스로 자연스럽게 보안서비스를 이용할 수 있도록 한다는 점에서 가장 매력적인 보안대책이라고 할 수 있다.                             

 
강용석 / 인포섹 보안기술혁신본부장  

                                                 

파일
 
 
번호 제목 작성자 작성일 인기도 파일
  256   포스트 코로나19 시대, 개인정보..   손승원   2020-08-06  
   
  255   우리 사회가 추구하는 보안   박철광   2020-06-26  
   
  254   마이데이터 사업-데이터의 활용과..   김선희   2020-06-08  
   
  253   코로나 사태, 개인건강정보 보호..   이재호   2020-05-04  
   
  252   코로나 위기 극복 과정과 사이버..   윤혜정   2020-04-16  
   
  251   개인정보보호 담당자에게 필요한..   신용석   2020-04-14  
   
  250   바이러스가 소환한 프라이버시의..   박종섭   2020-04-01  
   
  249   개인정보 보호책임자 지정 관련 ..   이진규   2020-03-20  
   
  248   코로나19, 기생충, 그리고 보안   김정덕   2020-02-25  
   
  247   ‘데이터 3법’ 둘러싼 갈등 해소..   박영숙   2020-02-24  
   
  1   2   3   4   5   6   7   8   9   10