ISMS-P 결함사례 고찰 #2.6. 접근통제

2.6.1 네트워크 접근

인증기준: 네트워크에 대한 비인가 접근을 통제하기 위하여 IP관리, 단말인증 등 관리절차를 수립· 이행하고, 업무목적 및 중요도에 따라 네트워크 분리(DMZ, 서버팜, DB존, 개발존 등)와 접근통제를 적용하여야 한다.

 

결함사례#1

네트워크 구성도와 인터뷰를 통하여 확인한 결과, 외부 지점에서 사용하는 정보시스템 및 개인정보 처리시스템과 IDC에 위치한 서버 간 연결 시 일반 인터넷 회선을 통하여 데이터 송수신을 처리하고 있어 내부 규정에 명시된 VPN이나 전용망 등을 이용한 통신이 이루어지고 있지 않은 경우가 있다. VPN이나 전용망을 사용하여 접근통제 영역을 구축해야 하는데, 일반 회선을 이용하게 되면 보안에 매우 취약해지게 된다. 이것은 전혀 보안에 대한 기본적인 방어도 구축하지 못했다고 말해도 과언이 아닐 것이다.

 

결함사례#2

내부망에 위치한 데이터베이스 서버 등 일부 중요 서버의 IP주소가 내부 규정과 달리 공인 IP로 설정되어 있고, 네트워크 접근 차단이 적용되어 있지 않은 경우가 있다. 중요 서버일 경우 특히나 IP 통제는 매우 중요하며, 내부망에서는 NAT를 쓰는 것이 보편적이다. 이같은 경우에도 보안이 상당히 취약해지는 결과를 낳을 것이다.

 

결함사례#3

서버팜이 구성되어 있으나, 네트워크 접근제어 설정 미흡으로 내부망에서 서버팜으로의 접근이 과도하게 허용되어 있는 경우가 있다. 서버팜은 다른 네트워크 영역과 구분하여 구성하는 것으로, 인가받은 내부 사용자의 접근만 허용하도록 정책을 적용하는 것이 일반적이다. 접근이 과도하게 허용되어 있다면 서버팜으로서의 의의를 잃게 되는 일이라 생각한다.

 

결함사례#4

외부자(외부 개발자, 방문자 등)에게 제공되는 네트워크를 별도의 통제 없이 내부 업무 네트워크와 분리하지 않은 경우가 있다. 망 분리, 네트워크 분리 같은 것들은 불조심 마냥 항상 염두하고 있어야 하는 문구라고 할 수 있다. 각 환경과 영역을 분리하여 업무 수행에 있어 필요한 서비스의 접근만 허용하도록 통제해야 할 것이다.

 

결함사례#5

내부 규정과는 달리 MAC주소 인증, 필수 보안 소프트웨어 설치 등의 보호대책을 적용하지 않은 상태로 네트워크 케이블 연결만으로 사내 네트워크에 접근 및 이용할 수 있는 경우가 있다. 이것은 결국 공격자도 똑같이 적용되는 것이며, 편의성은 단순 이용자만이 아닌 공격자에게도 적용된다는 것을 우리는 명심해야 한다. 나중에 소 잃고 외양간 고치는 것은 이미 너무도 늦은 일이다.

 

2.6.2 정보시스템 접근

인증기준: 서버, 네트워크시스템 등 정보시스템에 접근을 허용하는 사용자, 접근제한 방식, 안전한 접근수단 등을 정의하여 통제하여야 한다.

 

결함사례#1

사무실에서 서버관리자가 IDC에 위치한 윈도우 서버에 접근 시 터미널 서비스를 이용하여 접근하고 있으나, 터미널 서비스에 대한 세션 타임아웃 설정이 되어 있지 않아 장시간 아무런 작업을 하지 않아도 해당 세션이 차단되지 않는 경우가 있다. 일정시간 이상 업무를 수행하지 않는 경우 자동 접속차단을 하는 것은 기본 중 하나라고 생각한다. 실로 개인정보와 밀접한 관련이 있는 사이트의 경우 대부분 그런 타임아웃 설정을 넣고 있기 때문이다.

 

결함사례#2

서버 간 접속이 적절히 제한되지 않아 특정 사용자가 본인에게 인가된 서버에 접속한 후 해당 서버를 경유하여 다른 인가받지 않은 서버에도 접속할 수 있는 경우가 있다. 다른 네트워크나 다른 서버에서의 비인가 접근을 제대로 차단하지 않아 발생한 문제로 보인다. 접근제어의 정책에 따라 적절한 제한을 두어 이런 일이 발생하지 않도록 조치를 취해야 한다. 특히 다른 사례에 비해서 이같은 것은 놓치기가 쉬운 영역인데, 놓치기는 쉬우나 그것으로 인한 취약점은 너무도 크다.

 

결함사례#3

타당한 사유 또는 보완 대책 없이 안전하지 않은 접속 프로토콜(telnet, ftp 등)을 사용하여 접근하고 있으며, 불필요한 서비스 및 포트를 오픈하고 있는 경우가 있다. 이 프로토콜에 대해서도 계속해서 더욱 나은 버전과 설정이 나오고 있으며, 이에 대한 동향을 계속해서 파악할 필요가 있다. 기존에 쓰던 시스템에 대해서도 이미 되어있으니 그대로 쓰는 것이 아닌, 검토가 주기적으로 수행되어야 할 것이다. 이것은 일종의 위혐평가의 범위에 들어간다고 볼 수 있을 것이다. 그렇기에 대책 없이 안전하지 않은 프로토콜을 지속적으로 수행한다는 것은 제대로 위험평가 및 대응을 수행하지 않았다고 볼 수도 있을 것이다.

 

결함사례#4

모든 서버로의 접근은 서버접근제어 시스템을 통하도록 접근통제 정책을 가져가고 있으나, 서버접근제어 시스템을 통하지 않고 서버에 접근할 수 있는 우회 경로가 존재하는 경우가 있다. 우회를 하는 것은 특히나 공격자들이 즐겨쓰는 방식 중 하나이며, 이에 대한 공격법도 이미 알려진 것이 많다. 따라서 우회를 할 수 있는 경로를 모두 막아야 할 것이다. 우회를 할 수 있다면 접근제어는 오히려 없는 것보다 못한 상황이 될 것이다.

 

2.6.3 응용프로그램 접근

인증기준: 사용자별 업무 및 접근 정보의 중요도 등에 따라 응용프로그램 접근권한을 제한하고, 불필요한 정보 또는 중요정보 노출을 최소화할 수 있도록 기준을 수립하여 적용하여야 한다.

 

결함사례#1

응용프로그램의 개인정보 처리화면 중 일부 화면의 권한 제어 기능에 오류가 존재하여 개인정보 열람 권한이 없는 사용자에게도 개인정보가 노출되고 있는 경우가 있다. 대놓고 안전성 확보 조치를 못하는 경우가 되겠다. 단순 오류를 차치하고서도, 개인정보나 기타 중요정보의 불필요한 노출에 대해 제대로 응용 프로그램을 구현해야 할 것이다.

 

결함사례#2

응용프로그램의 관리자 페이지가 외부인터넷에 오픈되어 있으면서 안전한 인증수단이 적용되어 있지 않은 경우가 있다. 관리자 권한은 각별히 조심해야 하는 것 중 하나이기 때문에 접근을 철저히 관리해야 한다. 관리자 권한 하나를 탈취한 것만으로 유출할 수 있는 개인정보가 너무도 많다.

 

결함사례#3

응용프로그램에 대하여 타당한 사유 없이 세션 타임아웃 또는 동일 사용자 계정의 동시 접속을 제한하고 있지 않은 경우가 있다. 사실 여기서 '타당한 사유'라는 것에 해당하는 경우를 아직 보지 못했다. 굳이 기술적으로도 어렵지 않은 세션 타임아웃이나 동일 사용자 계정 동시 접속 제한을 하지 않을 이유가 없다. 과연 정말 법에서 인정하는 '타당한 사유'에 해당되는 사례가 있을지가 의문이다. 그저 귀차니즘의 결과이지 않을까 싶다.

 

결함사례#4

응용프로그램을 통하여 개인정보를 다운로드받는 경우 해당 파일 내에 주민등록번호 등 업무상 불필요한 정보가 과도하게 포함되어 있는 경우가 있다. 주민등록번호를 비롯한 각종 개인정보는 표시제한의 조치를 따라야 한다. 그래서 보통은 아무리 못해도 020101-4****** 식으로 기재하는 것처럼 말이다. 표시제한 조치 내용을 보면 휴대전화 번호, 도로명 주소, 이메일 주소 등에 대해 어떻게 조치를 해야 하는지 나와있으니 이것을 확인하여 조치를 취해야 할 것이다.

 

결함사례#5

응용프로그램의 개인정보 조회화면에서 like 검색을 과도하게 허용하고 있어, 모든 사용자가 본인의 업무 범위를 초과하여 성씨만으로도 전체 고객 정보를 조회할 수 있는 경우가 있다. 물론 업무상 like 검색이 필요한 경우가 있을 수도 있다. 허나 그것을 예외사항으로 두어야 하는 것이 맞다. 아예 like 검색이 되지 않도록 조치하여, like 검색을 안해버릇 하는 게 차라리 나을 수도 있다. 사실 like 검색을 굳이 쓰지 않아도 원하는 정보를 조회하는 데에는 문제가 없다.

 

결함사례#6

개인정보 표시제한 조치 기준이 마련되어 있지 않거나 이를 준수하지 않는 등의 사유로 동일한 개인정보 항목에 대하여 개인정보처리시스템 화면별로 서로 다른 마스킹 기준이 적용된 경우가 있다. 개인정보 표시제한 조치는 이미 성문화 되어있으므로 이를 기준으로 전부 통일하여 적용하는 것이 옳다. 그렇지 않을 경우 Aggregation 같은 사태가 발생할 수도 있을 것이다.

 

결함사례#7

개인정보처리시스템의 화면상에는 개인정보가 마스킹되어 표시되어 있으나, 웹브라우저 소스보기를 통하여 마스킹되지 않은 전체 개인정보가 노출되는 경우가 있다. 이같은 경우도 은근 있는 편이라 생각한다. 일반적으로 생각할 때, 당장 보이는 정보에만 집중을 하는 게 1순위이기 떄문이다. 웹브라우저 소스까지 확인하는 경우는 보통 없을 테니 말이다. 그런데 언제나 다각도로 정보의 접근 경우를 생각하고, 그것에 대한 조치를 취해야 한다. 공격자가 순수하게 개인정보처리시스템으로만 들어올 가능성은 적으니 말이다.

 

2.6.4 데이터베이스 접근

인증기준: 테이블 목록 등 데이터베이스 내에서 저장·관리되고 있는 정보를 식별하고, 정보의 중요도와 응용프로그램 및 사용자 유형 등에 따른 접근통제 정책을 수립·이행하여야 한다.

 

결함사례#1

대량의 개인정보를 보관·처리하고 있는 데이터베이스를 인터넷을 통하여 접근 가능한 웹 응용프로그램과 분리하지 않고 물리적으로 동일한 서버에서 운영하고 있는 경우가 있다. 물리적으로 분리를 하건, 논리적으로 분리를 하건, 분리는 언제나 필수로 여겨야 한다. 그것이 ISMS-P에서 요구하는 영역이 아니라고 해도 말이다. 보안과 관련된 업무를 하는 직원들에게 '망분리' 같은 단어는 너무나 친근하게 여겨지는 것과 일맥상통한다.

 

결함사례#2

개발자 및 운영자들이 응응 프로그램에서 사용하고 있는 계정을 공유하여 운영 데이터베이스에 접속하고 있는 경우가 있다. 언제나 1인 1계정 원칙은 필수로 지켜야 한다. 공유해서 계정을 사용한다는 것은 결국 해당 계정이 그 직원들의 업무에 모두 접근이 가능하다는 것을 의미하고, 이는 최소권한에도 위배되는 행위일 것이다. 그렇기에 원칙을 지켜야만 한다.

 

결함사례#3

내부 규정에는 데이터베이스의 접속권한을 오브젝트별로 제한하도록 되어 있으나, 데이터베이스 접근권한을 운영자에게 일괄 부여하고 있어 개인정보 테이블에 접근할 필요가 없는 운영자에게도 과도하게 접근 권한이 부여된 경우가 있다. 운영자라고 해서 모든 권한을 부여해서는 아니 된다. 운영자의 계정이 어떠한 역할과 책임을 지는지 확인을 하고, 그에 맞춰서 권한을 부여해야 할 것이다. 공격자가 이 사실을 알면 운영자의 권한을 바로 탈취하려 할 것이다.

 

결함사례#4

데이터베이스 접근제어 솔루션을 도입하여 운영하고 있으나, 데이터베이스 접속자에 대한 IP주소 등이 적절히 제한되어 있지 않아 데이터베이스 접근제어 솔루션을 우회하여 데이터베이스에 접속하고 있는 경우가 있다. 공격자는 언제나 접근제어나 방화벽을 우회하려 한다. 굳이 우회해서 가는 길이 있는데, 정문을 뚫어서 침입 사실을 더욱 빨리게 알릴 필요가 무엇이겠냔 말이다. 그렇기에 우회 여부에 대해서는 엄격하게 통제해야 한다.

 

결함사례#5

개인정보를 저장하고 있는 데이터베이스의 테이블 현황이 파악되지 않아, 임시로 생성된 테이블에 불필요한 개인정보가 파기되지 않고 대량으로 저장되어 있는 경우가 있다. 데이터베이스의 현황이나 접속자 계정 및 권한 목록은 지속적으로 확인 가능해야 하며, 개인정보 파기 원칙에 따라 파기에 대한 스케줄을 따로 정해야 할 것이다.

 

2.6.5 무선 네트워크 접근

인증기준: 무선 네트워크를 사용하는 경우 사용자 인증, 송수신 데이터 암호화, AP 통제 등 무선 네트워크 보호대책을 적용하여야 한다. 또한 AD Hoc 접속, 비인가 AP 사용 등 비인가 무선 네트워크 접속으로부터 보호대책을 수립·이행하여야 한다.

 

결함사례#1

외부인용 무선 네트워크와 내부 무선 네트워크 영역대가 동일하여 외부인도 무선네트워크를 통하여 별도의 통제 없이 내부 네트워크에 접근이 가능한 경우가 있다. 이것 역시 영역을 분리하지 않은 것이다. 분리는 언제나 선택이 아닌 필수로 여겨야 한다. ISMS-P 인증 때문이 아니더라도 말이다.

 

결함사례#2

무선 AP 설정 시 정보 송수신 암호화 기능을 설정하였으나, 안전하지 않은 방식으로 설정한 경우가 있다. 언제나 안전한 접속수단, 안전한 방식을 강구해야 한다. 어떤 인증을 설정할지, 어떤 제한을 둘지, 이런 것들에 대한 점검이 필요하다. 정보 송수신 단계는 특히나 공격자가 타깃으로 삼기 쉬운 영역임을 인지하고 설정해야 할 것이다.

 

결함사례#3

업무 목적으로 내부망에 연결된 무선AP에 대하여 무선AP 관리자 비밀번호 노출(디폴트 비밀번호 사용), 접근제어 미적용 등 보안 설정이 미흡한 경우가 있다. 비밀번호가 뚫려서 생기는 문제들 중 상당수가 초기 비밀번호를 그대로 사용해서 발생한다. 업무적인 것이든, 개인적인 것이든, 디폴트 비밀번호를 유지하는 것은 공격해달라고 아우성하는 것과 다름없다고 생각한다. 특별한 공격 루트면 몰라도, 일반적인 공격 루트에 대해서는 방어 수단을 공고히 해야 할 것이다.

 

2.6.6 원격접근 통제

인증기준: 보호구역 이외 장소에서의 정보시스템 관리 및 개인정보 처리는 원칙적으로 금지하고, 재택근무·장애대응·원격협업 등 불가피한 사유로 원격접근을 허용하는 경우 책임자 승인, 접근 단말 지정, 접근 허용범위 및 기간 설정, 강화된 인증, 구간 암호화, 접속단말 보안 (백신, 패치 등) 등 보호대책을 수립·이행하여야 한다.

 

결함사례#1

내부 규정에는 시스템에 대한 원격 접근은 원칙적으로 금지하고 불가피한 경우 IP 기반의 접근통제를 통하여 승인된 사용자만 접근할 수 있도록 명시하고 있으나, 시스템에 대한 원격 데스크톱 연결, SSH 접속이 IP주소 등으로 제한되어 있지 않아 모든 PC에서 원격 접속이 가능한 경우가 있다. 원격 접속이 정말 타깃이 되기 쉬운 영역이다. 이 운영 및 접속에 대해 책임자의 승인이 있어야 하고, 특히나 재택업무가 과거에 비해 늘어난 실정을 고려할 때, 원격 접근에 대해서는 더욱 철저히 다룰 필요가 있다.

 

결함사례#2

원격운영관리를 위하여 VPN을 구축하여 운영하고 있으나, VPN에 대한 사용 승인 또는 접속 기간 제한 없이 상시 허용하고 있는 경우가 있다. 무엇 대상이건, 시간 제한은 언제나 있어야 한다. 이 타임아웃도 기술적으로 어려운 것이 아니기에 바로 적용해야 한다. 솔직히 타임아웃이 엄청 짧은 것도 아닌데, 밥 먹고 왔다가 타임아웃 되었다고 다시 로그인하는 게 귀찮다면 세상에 귀찮지 않은 일은 없을 테니 말이다. 또한, VPN은 단순히 안전한 편이라고 해서 안심하고 막 쓰게 해서는 아니 될 것이다. 일반 회선에 비해 안전할 뿐이지, VPN 자체가 무적이 아니라는 점은 명시하고 지침에 따라 설정해야 할 것이다.

 

결함사례#3

외부 근무자를 위하여 개인 스마트 기기에 업무용 모바일 앱을 설치하여 운영하고 있으나, 악성코드, 분실·도난 등에 의한 개인정보 유출을 방지하기 위한 적절한 보호대책(백신, 초기화, 암호화 등)을 적용하고 있지 않은 경우가 있다. 이게 무슨 컨테이너 같은 기법을 쓰는 것도 아니고, 단순 외부에서의 접근을 위한 앱인데 보호대책이 적용되고 있지 않다는 것은 큰 문제라고 본다. 앞서 말했듯, 원격 접근은 공격자의 타깃이 되기 쉽고, 이에 대한 보호대책을 반드시 강구해야 할 것이다.

 

결함사례#4

외부 접속용 VPN에서 사용자별로 원격접근이 가능한 네트워크 구간 및 정보시스템을 제한하지 않아 원격접근 인증을 받은 사용자가 전체 내부망 및 정보시스템에 과도하게 접근이 가능한 경우가 있다. VPN은 결코 무적이 아니다. 뭐 사실 보안에서 안전하다는 것은 결국 상대적인 것일 뿐, 절대적인 것은 없기야 하지만 말이다. 아무튼 어떠한 것이건, 접근 권한은 정해진 바에 따라 적절하게 주어져야 할 것이다. 이에 따라 VPN 접근제어 정책 설정 현황을 확인할 필요가 있다.

 

2.6.7 인터넷 접속 통제

인증기준: 인터넷을 통한 정보 유출, 악성코드 감염, 내부망 침투 등을 예방하기 위하여 주요 정보시스템, 주요 직무 수행 및 개인정보 취급 단말기 등에 대한 인터넷 접속 또는 서비스 (P2P, 웹하드, 메신저 등)를 제한하는 등 인터넷 접속 통제 정책을 수립·이행하여야 한다.

 

결함사례#1

개인정보 보호법에 따라 인터넷망 차단 조치를 적용하였으나, 개인정보처리시스템의 접근권한 설정 가능자 등 일부 의무대상자에 대하여 인터넷망 차단 조치 적용이 누락된 경우가 있다. 이것도 생각보다 빈번한 경우다. 사실 내 경험상, 의무 대상자인데 누락이 되었다기 보다는 조금 다른 경우인 게 많았다. 의무대상자가 아니고, 그래서 차단 조치 적용이 되어 있지가 않은데, 접근권한 설정이 주어진 경우이다. 결국 같은 말이 아니냐고 할 수 있는데, 사실 이야기의 순서가 좀 다르다. 일을 시켜야 하니, 접근권한을 따로 주는 것이고, 직무 기술서에는 그런 내용이 없는 상황인 것이다. 따라서 담당자들은 의무대상자에 대한 조치 적용만 따질 것이 아니라, 전직원들 상대로 현황에 대한 점검이 필요하다.

 

결함사례#2

개인정보 보호법에 따른 인터넷망 차단 조치 의무대상으로서 인터넷망 차단 조치를 적용하였으나, 다른 서버를 경유한 우회접속이 가능하여 인터넷망 차단 조치가 적용되지 않은 환경에서 개인정보처리시스템에 접속하여 개인정보의 다운로드, 파기 등이 가능한 경우가 있다. 계속 말하게 된다. 우회는 절대 절대 절대적으로 있어서는 안 된다. 우회 경로를 파악하는 즉시 이에 대한 조치가 필요할 것이다.

 

결함사례#3

DMZ 및 내부망에 위치한 일부 서버에서 불필요하게 인터넷으로의 직접 접속이 가능한 경우가 있다. DMZ나 내부망에서 인터넷 직접 접속이 가능하게 되면, 공격자가 일부 방어 수단을 건너뛰고 공격을 할 수도 있을 것이다. 이에 대한 취약점을 판단하여 접속 제한을 설정해야 한다.

 

결함사례#4

인터넷 PC와 내부 업무용 PC를 물리적 망분리 방식으로 인터넷망 차단 조치를 적용하고 망간 자료전송시스템을 구축·운영하고 있으나, 자료 전송에 대한 승인 절차가 부재하고 자료 전송 내역에 대한 주기적 검토가 이루어지고 있지 않은 경우가 있다. 자료 전송에 대한 승인 절차가 없고, 그 내역에 대한 검토도 없다면, 굳이 망분리를 한 이유가 옅어지게 된다. 이럴 경우의 망분리는 그저 공격자에게 조금 시간을 끌어주는 데에 그치지 않게 되는 것이다. 따라서 이에 대한 절차와 점검 내역을 관리하는 것은 주기적으로 꾸준히 진행해야 한다.

 

결함사례#5

내부 규정에는 개인정보취급자가 P2P 및 웹하드 사이트 접속 시 책임자 승인을 거쳐 특정 기간 동안만 허용하도록 되어 있으나, 승인절차를 거치지 않고 예외 접속이 허용된 사례가 다수 존재하는 경우가 있다. 특정 기간만 허용하는 것도 기술적으로 결코 어렵지 않다. 승인 절차를 밟는 게 귀찮다면, 기술적으로라도 그것을 강제해야 한다. 아쉬운 것은 편의성을 추구하는 개인이지, 지침을 따르는 조직은 아니기 때문이다.