[ISMS-P] 가상기업 ISMS-P 컨설팅

Whitehat School 3기 프로젝트 직전 실습 과제. 가상의 금융회사를 대상으로 ISMS-P 인증기준에 따라 결함을 도출하고, 개선방안과 인터뷰 질문을 작성하는 컨설턴트 역할을 수행했다.

ISMS-P 컨설팅이란 무엇을 하는 것인가

ISMS-P(정보보호 및 개인정보보호 관리체계 인증)는 국내 기업이 정보보호 및 개인정보보호 수준을 갖추고 있는지 심사하는 인증 제도다. 컨설팅은 본 심사 전에 현재 운영 환경을 인증기준에 비춰 점검하고, 결함을 미리 발굴해 개선하는 과정이다.

실습에서는 인터뷰 내용과 시스템 현황 자료를 바탕으로 결함 항목을 도출하고, 각 항목에 대해 인증기준 해석, 개선방안 제안, 후속 인터뷰 질문을 작성했다. 발견된 결함은 총 6개 항목으로, 접근통제 3건, 로그 관리 1건, 암호정책 1건, 계정 관리 2건이다.

결함 1: 원격접근 통제 미흡 (2.6.6)

상황: "현재 과도기적 시기라 사용자가 집 등 원하는 환경에서 public 인터넷을 통해 시스템에 접속할 수 있도록 임시로 구성한 상태"라는 인터뷰 답변이 나왔다.

이 한 문장에 결함이 압축되어 있다. ISMS-P 2.6.6 인증기준은 보호구역 이외 장소에서의 정보시스템 관리를 원칙적으로 금지하고, 불가피한 경우에도 책임자 승인, 접근 단말 지정, 구간 암호화, 강화된 인증 등 보완대책을 요구한다. "임시 구성"이나 "과도기"는 인증 심사에서 면책 사유가 되지 않는다.

개선 방향은 계층적으로 접근해야 한다. 우선 public 인터넷을 통한 직접 접근을 차단하고, 불가피한 원격접근은 VPN을 거치도록 강제한다. VPN 접속 자체에도 사용 승인과 기간 제한을 적용하고, MFA를 요구해야 한다. "임시"라는 상태가 방치될수록 실제 침해 위험과 인증 결함 모두 누적된다.

결함 2: 중요 서버 공인 IP 노출 (2.6.1)

상황: 같은 인터뷰에서 중요 서버의 IP 주소가 공인 IP로 설정되어 있고, 네트워크 접근 차단이 적용되지 않았음이 확인됐다.

2.6.1 인증기준은 업무 목적과 중요도에 따라 네트워크를 분리(DMZ, 서버팜, DB존 등)하고 접근통제를 적용하도록 요구한다. 중요 서버가 공인 IP를 가지고 방화벽 차단도 없다면, 이론적으로 인터넷에서 직접 접근이 가능하다. 이는 단순한 정책 미비가 아니라 실제 공격 노출 상태다.

개선 방향은 중요 서버를 사설 IP 대역으로 이전하고, 방화벽을 통해 외부 접근을 기본 차단하는 것이다. 인가된 사용자의 접근은 VPN 또는 전용망을 통해서만 가능하게 하고, 네트워크 접근 경로 전체를 식별해 문서화해야 한다.

이 결함은 결함 1(원격접근 통제)과 원인이 같다. 시스템을 어디서든 접근 가능하게 만들어둔 상태가 두 개의 인증기준을 동시에 위반하고 있다.

결함 3: 정보시스템 접근 통제 미정의 (2.6.2)

상황: "언제 어디서든 개인정보처리자가 자율적 판단에 따라 정보시스템에 접속"할 수 있도록 운영 중이라는 답변이 나왔다.

2.6.2 인증기준은 정보시스템에 접근을 허용하는 사용자, 접근 제한 방식, 안전한 접근 수단을 명확히 정의해서 통제하도록 요구한다. "자율적 판단에 따라 접속"은 인증기준과 정반대되는 운영 방식이다. 누가 어떤 시스템에 접근할 수 있는지 정의되지 않은 상태에서 모니터링 시스템 같은 주요 시스템에도 통제 없이 접근이 가능한 구조다.

서버접근제어 시스템 도입이 핵심 개선 방향이다. 모든 서버 접근을 단일 게이트웨이를 통하도록 강제하고, 서버 간 lateral movement(횡적 이동)를 제한해야 한다. 세션 타임아웃 설정도 빠져있다.

결함 4: 접속 로그에서 실제 사용자 식별 불가 (2.9.4)

상황: 개인정보처리시스템 접속 로그를 확인한 결과, 모든 접속 IP가 동일한 내부 IP(192.168.1.3)로 기록되어 있었다. 누가 언제 어디서 접속했는지 추적이 불가능한 상태다.

NAT나 프록시 환경에서 발생하는 전형적인 문제다. 내부망 모든 트래픽이 단일 게이트웨이를 통해 나가면서 출발지 IP가 덮어쓰여지는 것이다. 게다가 처리한 정보주체 관련 정보도 로그에 남기고 있지 않았다.

2.9.4 인증기준은 접속자 계정, 접속 일시, 접속 IP, 처리한 정보주체 정보, 수행 업무 상세 내용을 모두 기록하도록 요구한다. 로그의 목적이 책임 추적성(accountability) 확보인데, 현재 로그는 그 기능을 전혀 하지 못하고 있다.

IP 식별이 안 되면 MAC 주소, Hostname, OS 정보를 보완해서 기록해야 한다. 로그 자체의 무결성도 문제인데, 임의 삭제나 편집이 가능한지, 로그 저장 위치와 운영 시스템이 분리되어 있는지도 확인이 필요하다.

결함 5: 취약 암호 알고리즘 사용 (2.7.1)

상황: Amazon RDS Custom 환경에서 DES 암호화 알고리즘을 사용하고 있는 것이 확인됐다.

DES는 56비트 키를 사용하는 1970년대 알고리즘이다. 현재 기준으로 수 시간 이내에 brute-force 공격으로 깨진다. 국내 법적 요구사항(개인정보보호법, 전자금융거래법 등)은 물론, ISMS-P 2.7.1 인증기준도 법적 요구사항을 반영한 안전한 암호 알고리즘 사용을 요구한다.

개선 방향은 단순하다. AES-256으로 교체해야 한다. 다만 이 과정에서 현재 DES로 암호화된 데이터를 어떻게 마이그레이션할 것인지, 암호키 관리 체계는 어떻게 되는지, 어떤 컬럼에 암호화가 적용되어 있는지 전수 파악이 선행되어야 한다.

클라우드 환경(RDS)에서 운영하고 있으므로, AWS KMS를 활용한 키 관리 체계 구축도 함께 권고할 수 있다.

결함 6: 과도한 권한 부여 및 계정 관리 부재 (2.5.1 / 2.5.5)

상황: 개인정보처리시스템에 접근할 수 있는 사용자 계정 전체에 모든 리소스에 대한 모든 권한이 일률적으로 부여되어 있었다. 관리자/특수 계정의 승인 이력도 시스템상에서 확인되지 않았다.

AWS 환경으로 보이는 이 상황을 IAM 정책으로 표현하면 "Action": "*", "Resource": "*" 상태다. 이는 최소 권한 원칙(Principle of Least Privilege)의 정반대다. 개인정보처리시스템 사용자가 업무상 필요 없는 모든 리소스에 접근할 수 있고, 특수 계정 운영 이력도 추적이 안 된다.

2.5.1과 2.5.5 두 항목이 동시에 위반된 이유는, 계정 등록/권한 부여 절차 자체가 없거나 형식적으로만 존재하기 때문이다. 개선 방향은 역할별 IAM 정책 재설계(직무 분리 + 최소 권한), 권한 부여·변경·말소 이력의 자동 기록, 정기적인 계정 점검 주기 수립, 신규 계정 등록 시 보안 서약 절차 도입으로 이어진다. 장기 미사용 계정과 퇴직자 계정을 즉시 정비하는 것도 포함된다.

+추가)

해당 사항과 관련있는 쿠팡 침해 사고가 발생했다. 퇴사자의 인가를 관리하지 못해서 일어난 사고라고 한다.

실습을 마치며

6개 결함 항목을 전체적으로 보면 공통점이 있다. 기술적으로 어려운 문제가 아니다. DES 대신 AES를 쓰는 건 설정 몇 줄이고, 라이브러리를 가져다 쓰는 거라면 거의 같은 공수가 발생할 것이다. AWS 상이라면 대칭 암호는 옵션에도 없을 것이고, 돈만 내면 더 복잡한 암호도 제공한다. VPN 구축이 불가능한 회사는 없다. 그런데 왜 이런 결함들이 실제 운영 환경에서 발생하는가?

내 생각에는 "처음부터 보안을 우선시하지 않아서"인 것 같다. 나도 프로젝트를 하면서 느낀 거지만, 처음에는 개발중이라는 핑계로 편의를 위해 열어두고, 나중에 닫으려고 보면 서비스가 멈출 지도 모른다는 핑계로 약한 보안성으로 운영되는 시스템들이 참 많다. 접근통제, 로그, 권한 관리가 모두 이런 패턴으로 방치된 케이스들이다.

컨설팅에서 인터뷰 질문을 작성하는 이유도 여기 있다. 기술적 취약점을 찾는 것만큼이나, 운영 담당자가 현재 상태를 인지하고 있는지, 개선 의지와 체계가 있는지를 확인하는 것이 중요하다. 사고 후 결함, 취약점 등등을 빨리 발견하는 것보다 사고가 일어나기 전에 지속적으로 통제하여 침해사고가 일어나지 않도록 하는 게 더 중요하다고 생각한다.

실습 환경: Whitehat School 3기 — 금융보안 환경의 Security Compliance Engineering(feat. MCP) 프로젝트
적용 인증기준: ISMS-P 2.5.1, 2.5.5, 2.6.1, 2.6.2, 2.6.6, 2.7.1, 2.9.4