[ISMS-P] 멀티 클라우드 환경 중견기업의 접근 통제 (2.6.1 ~ 2.6.7)
클라우드 환경으로 인프라가 대거 전환되면서 전통적인 네트워크 물리 경계가 무너졌습니다. 온프레미스의 방화벽이나 IPS 장비를 지나야만 진입할 수 있었던 경계가, 이제는 마우스 클릭 몇 번과 API 호출만으로 외부에 쉽게 노출될 수 있습니다. 멀티 클라우드에서 안전한 경계를 유지하기 위해선 논리적인 접근 통제(Access Control) 정책을 빈틈없이 구축해야 합니다.
이번 글에서는 ISMS-P 인증기준 2.6 (접근 통제)의 7개 세부 항목을 멀티 클라우드를 사용하는 중견기업 관점에서 살펴보고, 인증심사원 시험에 자주 출제되는 결함 시나리오를 바탕으로 퀴즈와 해결책을 정리해 보겠습니다.
1. 2.6.1 네트워크 접근
📌 인증기준 개요
내부망과 외부망(인터넷망)을 분리하고, 대내외 서비스를 제공하는 시스템의 중요도와 용도에 따라 네트워크 영역을 격리하여 상호 간의 통신 경로를 제한해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- VPC 기반의 망 분리: AWS, Azure, GCP 등에서 VPC/VNet을 생성할 때, 개발(Dev)·스테이징(Stg)·운영(Prod) 환경을 논리적으로 완전히 격리하고 VPC 피어링이나 VPN 통로 상에서 불필요한 라우팅 경로를 차단해야 합니다.
- Any Open 방화벽 규칙 금지: 클라우드 보안 그룹(Security Group) 및 네트워크 ACL(NACL) 설정 시, 목적지가 불분명한 외부 IP 전체(
0.0.0.0/0)를 대상으로 인바운드 통신을 허용해선 안 됩니다. 허용이 필요한 IP 대역만 명시적으로 인가해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 A기업의 AWS 클라우드 네트워크 아키텍처를 점검 중이다.
- 심사원: “서비스 개발 환경과 실제 상용 서비스(운영) 환경의 네트워크 격리 상태를 확인해 보겠습니다.”
- 담당자: “저희는 동일한 VPC 안에서 서브넷(Subnet)만 나누어 개발 서버와 운영 서버를 배포했습니다.”
- 심사원: “그렇다면 개발 서브넷의 EC2 인스턴스에서 운영 서브넷의 데이터베이스 서버로 직접 핑(Ping)을 보내거나 접속하는 경로가 차단되어 있나요?”
- 담당자: “장애 대응 및 개발 단계에서의 빠른 디버깅을 위해 두 서브넷 간의 모든 포트 통신은 제한 없이 열려 있습니다.”
Q. 위 상황에서 발생할 수 있는 명백한 결함 조치 항목은?
- 2.6.3 응용프로그램 접근 - 개발자가 응용프로그램 소스 코드를 임의로 고침
- 2.6.1 네트워크 접근 - 중요도 및 용도가 다른 개발 영역과 운영 영역의 네트워크가 동일 VPC 내에서 방화벽 또는 ACL을 통한 접근 제어 없이 전체 연결되어 있음 (정답)
- 2.4.3 정보시스템 보호 - 개발 서버의 물리적 하드웨어 이중화가 누락됨
- 2.6.5 무선 네트워크 접근 - 사내 개발실 AP에 WPA3가 활성화되지 않음
해설: 개발망과 운영망은 정보보호 및 개인정보보호 관점에서 가장 엄격히 통제되어야 하는 경계입니다. 동일 VPC 내에 묶어두고 라우팅 및 보안 그룹 통제 없이 전체 개방하는 것은 2.6.1 네트워크 접근의 대표적인 결함 사항입니다. 가능하면 환경별로 VPC를 물리적으로 분리하고 통제가 필요합니다.
2. 2.6.2 정보시스템 접근
📌 인증기준 개요
운영체제(OS), 가상화 하이퍼바이저 등 정보시스템 자체에 대한 사용자 접근을 통제하고, 미인가자의 관리자 계정 접근을 차단하기 위한 통제 조치를 수립해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- SSH/RDP 관리 포트 노출 차단: 클라우드 가상 머신(EC2, VM 등)의 SSH(22번), RDP(3389번) 포트가 퍼블릭 인터넷 환경에 바로 오픈되어 있다면 극도로 위험합니다.
- SSM/Bastion Host 활용: 콘솔이나 시스템 터미널에 접근할 때 Bastion Host(배스천 호스트) 또는 AWS Systems Manager(SSM) Session Manager 등 세션 터널링 솔루션을 거쳐 사내 IP를 통해서만 접속 가능하도록 강력한 인바운드 제한 정책을 설정해야 합니다.
📝 실전 시험 대비 (기출 복원 시나리오)
[상황] 심사원이 B기업의 클라우드 서버 인프라 보안 그룹(Security Group) 설정을 확인하고 있다.
- 심사원: “GCP Compute Engine에 있는 리눅스 인스턴스들의 방화벽 설정 값을 검토 중인데, 외부 인바운드 룰에 22번 포트(SSH)가
0.0.0.0/0으로 허용되어 있는 인스턴스가 5대 정도 발견되었습니다. 사유가 무엇인가요?” - 담당자: “아, 그 서버들은 외주 개발자들이 집이나 카페에서 급하게 접속하여 빌드 수정을 해야 하는 서버들이라, 외부에서도 접속할 수 있도록 포트를 전부 개방해 두었습니다. 하지만 SSH 키 페어 파일이 있어야만 로그인이 가능하므로 안전합니다.”
Q. 위 상황에서 도출되는 보안 통제 결함으로 가장 올바른 사유는?
- 2.5.4 비밀번호 관리 - 외주 개발자의 SSH 키 패스워드가 너무 짧음
- 2.6.2 정보시스템 접근 - 시스템 관리 및 개발용 포트(SSH)가 불특정 다수의 외부 IP(
0.0.0.0/0)를 대상으로 상시 개방되어 보안 통제가 미흡함 (정답) - 2.6.7 인터넷 접속 통제 - 개발자들이 유해 사이트에 접속하여 작업함
- 2.5.3 사용자 인증 - 서버 접근 시 일회용 OTP를 사용하지 않음
해설: SSH(22), RDP(3389)와 같은 운영체제 관리용 포트는 브루트포스(무작위 대입) 공격의 주 타깃입니다. 키 페어 로그인을 사용한다 하더라도 네트워크 레벨에서 허용된 소스 IP로만 제한하여 노출 범위를 최소화해야 합니다. 그렇지 않고 전 세계에 개방한 것은 2.6.2 결함입니다.
3. 2.6.3 응용프로그램 접근
📌 인증기준 개요
웹 애플리케이션, 모바일 앱 등 응용프로그램 수준에서 중요 정보 및 개인정보 유출을 방지하기 위해 사용자 역할에 따른 기능 및 데이터 접근 범위를 제한하고 통제해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- API 게이트웨이 및 백엔드 권한 통제: 클라우드 환경의 서버리스(Serverless)나 컨테이너(EKS, AKS 등) 아키텍처에서는 API 수준에서 접근 제어가 정밀하게 설계되어야 합니다.
- 화면 및 기능 접근 제한: 일반 사용자, 파트너사, 내부 정직원 등의 권한 등급에 따라 개인정보 조회 기능, 삭제 기능, 엑셀 다운로드 기능 등을 메뉴 수준에서 세부 통제(RBAC)해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 C기업의 고객 관리 백오피스 응용프로그램을 점검하고 있다.
- 심사원: “백오피스 포털에 등록된 일반 상담원 계정과 개인정보보호 관리자 계정의 기능적 차이가 어떻게 되나요?”
- 담당자: “관리자 계정은 모든 고객의 개인정보를 대량으로 조회하고 엑셀로 다운로드할 수 있으며, 일반 상담원은 고객 민원 해결을 위해 단건 검색만 가능해야 합니다.”
- 심사원: “일반 상담원 계정으로 직접 로그인하여 확인해 보겠습니다. 상담원 화면에서 ‘전체 회원 엑셀 다운로드’ 버튼이 보이고, 실제로 5만 명의 고객 데이터가 다운로드되는 것으로 확인됩니다.”
- 담당자: “원래는 막아두어야 하는데, 앱 소스 코드 상에서 다운로드 버튼의 권한 분기가 빠져 있는 것 같습니다.”
Q. 위 상황에 해당하는 적절한 결함 항목은?
- 2.5.1 사용자 계정 관리 - 상담원 계정이 오랫동안 사용되지 않음
- 2.6.4 데이터베이스 접근 - DBMS의 패치가 최신 버전이 아님
- 2.6.3 응용프로그램 접근 - 일반 상담원의 응용프로그램 접근 권한이 최소화되지 않아 중요 기능(개인정보 대량 엑셀 다운로드)에 불필요하게 접근할 수 있음 (정답)
- 2.8.5 소스 프로그램 관리 - 웹 소스가 외부 저장소(GitHub)에 공개됨
해설: 사용자의 직무와 역할에 따라 웹/앱 응용프로그램 메뉴와 기능을 정밀하게 통제하지 않은 것은 2.6.3 응용프로그램 접근의 명확한 결함입니다.
4. 2.6.4 데이터베이스 접근
📌 인증기준 개요
개인정보 및 중요 정보가 저장된 데이터베이스시스템(DBMS)에 대한 접근은 원천적으로 제한하고, 별도의 전용 접근제어 솔루션이나 질의(SQL) 통제 대책을 통해 인가된 사람만이 데이터에 접근하도록 해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- PaaS DB의 접근 격리: RDS(AWS), Cloud SQL(GCP), Azure SQL Database 등 클라우드 PaaS 데이터베이스는 퍼블릭 IP를 차단하고 오직 내부 VPC 대역에서만 수신하도록 설정(Private IP 설정)해야 합니다.
- 접근 통제 솔루션 경유: 개발자와 DBA가 DB를 조작할 때는 DB 접근제어 솔루션을 반드시 거치도록 강제하고, 해당 솔루션을 우회하여 로컬 PC에서 데이터베이스로 직접 쿼리를 날릴 수 있는 모든 경로를 네트워크 레벨에서 차단해야 합니다.
📝 실전 시험 대비 (기출 복원 유형)
Q. 다음 중 2.6.4 데이터베이스 접근 항목의 결함 사례로 가장 적절한 것은?
- 데이터베이스 관리자(DBA)가 데이터베이스 접속 시 비밀번호 없이 SSH 키로만 로그인하고 있다.
- 사내 DB 접근제어 지침서에는 모든 개발자가 접근제어 솔루션을 거치도록 규정했으나, 실제 확인 결과 특정 운영 DB 서버에 대해 일부 DBA와 개발자들이 사내망에서 접근제어 도구를 우회하여 직접 쿼리(DML 등)를 실행할 수 있는 방화벽 정책이 활성화되어 있다. (정답)
- AWS Aurora DB에 대해 Multi-AZ 이중화를 설정하지 않아 하드웨어 장애 시 데이터 유실 우려가 있다.
- 개인정보가 포함된 테이블의 일부 컬럼(주민번호 등)이 파일 시스템에 암호화되지 않은 상태로 저장되어 있다.
해설: DB 접근제어 정책의 핵심은 ‘우회 경로의 완벽한 차단’입니다. 규정과 정책이 있더라도 기술적으로 DB 포트(1521, 3306 등)에 접근할 수 있는 우회로가 뚫려 있다면 2.6.4 데이터베이스 접근의 주요 결함입니다. (참고: 3번은 가용성, 4번은 2.7.1 암호정책 적용 관련 영역입니다.)
5. 2.6.5 무선 네트워크 접근
📌 인증기준 개요
사내에서 사용하는 무선 네트워크(Wi-Fi)는 인증 및 암호화 수준이 높은 통제 대책을 적용하여 보안성을 확보해야 하며, 외부 방문객용 무선망과 내부 업무용 무선망은 물리적 혹은 논리적으로 엄격히 분리해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- WPA2/WPA3 Enterprise (802.1X 인증) 적용: 사내 Wi-Fi 연결 시 일반 패스워드를 공유하여 사용하는 WPA-Personal 방식을 지양하고, 직원별 사번/ID와 인증서를 연동하는 802.1X 엔터프라이즈 인증 방식을 도입해야 합니다.
- 방문객(Guest) 망 격리: 내방객용 오픈 Wi-Fi 대역에서 클라우드 사내 전용망(VPN Gateway 등)이나 내부 주요 정보시스템 IP 대역으로 라우팅되거나 통신이 연결되지 않도록 AP(Access Point) 수준에서 VLAN 격리 처리를 완수해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 D기업의 무선 Wi-Fi 인프라 및 전산망 연결 구조를 확인 중이다.
- 심사원: “사내에서 직원들이 사용하는 Wi-Fi 이름(SSID)과 내방객이 사용하는 Wi-Fi 이름이 어떻게 되나요?”
- 담당자: “직원용은
COMPANY_INTERNAL이고, 외부 방문객용은COMPANY_GUEST입니다.” - 심사원: “GUEST용 Wi-Fi에 제 개인 노트북을 연결해서 사내 프린터나 개발 서버의 GCP VPN 터널 게이트웨이 IP로 접근을 시도해 보겠습니다. 어라, 핑(Ping)이 가고 포트가 열리는 것으로 확인되네요.”
- 담당자: “같은 무선 AP 기기에서 신호만 나누어 놓은 것이라 백엔드 네트워크망 레벨에서는 라우팅이 차단되지 않아 내부망에 붙을 수 있는 상태인 것 같습니다.”
Q. 위 상황에 대해 내릴 결함 사항으로 가장 적절한 것은?
- 2.4.1 보호구역 지정 - 무선 AP가 천장에 매달려 있어 손쉽게 분실될 위험이 있음
- 2.6.2 정보시스템 접근 - 방문객이 GCP 관리 콘솔에 다이렉트로 접근함
- 2.6.5 무선 네트워크 접근 - 방문객용 무선망과 내부 업무용 무선망이 논리적/네트워크 레벨에서 분리되어 있지 않아 외부인이 내부망에 무단 접근할 수 있음 (정답)
- 2.5.3 사용자 인증 - 게스트용 Wi-Fi에 일회용 OTP가 적용되지 않음
해설: 무선망 보안의 필수 체크 포인트는 외부인 게스트 망과 내부 업무망의 완벽한 상호 격리입니다. SSID만 나누어 놓고 라우팅 단에서 격리하지 않은 것은 2.6.5 무선 네트워크 접근의 대표적인 결함 사항입니다.
6. 2.6.6 원격접근 통제
📌 인증기준 개요
사외(재택근무, 해외 외근 등)에서 내부망 또는 클라우드 정보시스템에 원격으로 접속하는 경우, 안전한 가상사설망(VPN) 등의 암호화 전송로를 제공하고, 추가적인 멀티팩터 인증(MFA)과 단말 보안 수준 검증을 동반해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 원격 접속 시 단말 보안 상태 검증(Host Checker): VPN 접속 요청 단말에 백신이 필수 구동 중인지, 최신 OS 패치가 적용되었는지, 사내 MDM이 가동 중인지 기술적으로 점검한 후 정상 단말에만 터널을 제공해야 합니다.
- 원격 접근 이력 로깅: 사외에서 클라우드 자원을 관리하기 위해 유입되는 모든 VPN 접속 로그(ID, 소스 IP, 시간, 단말 맥 주소 등)는 최소 2년 이상 보존해야 합니다.
📝 실전 시험 대비 (기출 복원 시나리오)
[상황] 심사원이 E기업의 원격 근무 보안 통제 체계를 검사하고 있다.
- 심사원: “코로나 이후 재택근무가 활성화되었다고 들었습니다. 사외에서 클라우드 개발 서버나 내부 시스템에 접속할 때 어떤 절차를 거치나요?”
- 담당자: “저희가 직원 노트북에 SSL-VPN 클라이언트를 설치해 주어, VPN 터널을 통해 암호화 접속하도록 강제하고 있습니다. 접속 승인은 보안팀에 이메일로 요청하면 수동으로 승인해 줍니다.”
- 심사원: “그렇다면 직원들이 사용하는 재택근무용 개인 PC(BYOD)나 노트북의 단말 상태에 대한 보안 검사(백신 구동 여부, 윈도우 보안 패치 등)를 확인하는 절차가 VPN 장비에 세팅되어 있나요?”
- 담당자: “개인 단말기 사정은 제각각이라 별도의 단말 상태 제어나 백신 검사 세팅은 적용하지 않았고, 백신을 설치하라고 공지만 보냈습니다.”
Q. 위 재택근무 원격접근 통제 체계의 결함 요소로 가장 알맞은 것은?
- 이메일로 VPN 접속을 신청하는 절차는 유효하지 않음
- SSL-VPN이 아닌 IPSec-VPN만 필수 권장되어야 함
- 2.6.6 원격접근 통제 - 원격으로 정보시스템에 접속하는 단말기기에 대해 기술적인 최소 보안 통제(백신 구동 여부 검사 등 Host Checker 적용) 없이 VPN 연결을 상시 허용함 (정답)
- 2.10.6 업무용 단말기기 보안 - VPN 계정 명단이 공유 폴더에 있음
해설: 원격접근 통제(2.6.6) 규정은 재택 근무 단말이 보안적으로 오염되었을 경우(웜, 봇넷 등), 사내망 및 클라우드 내부로 위협이 전파되는 것을 막기 위해 단말 보안성 자동 검증 장치(Host Checker 등)를 필수 적용하도록 요구합니다. 이를 단순 권장 공지로 대체하고 점검 장치를 마련하지 않은 것은 명백한 결함입니다.
7. 2.6.7 인터넷 접속 통제
📌 인증기준 개요
사내 업무용 컴퓨터, 서버 등에서 외부 인터넷망으로 유입되는 불필요한 인터넷 접속을 통제하고, 유해 사이트(악성코드 배포, 해킹 포럼, 웹하드 등)에 대한 접속을 자동 차단하는 대책을 강구해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 업무용 PC의 유해사이트 차단: 사내 업무용 PC에서 외부 파일 저장소(Dropbox, Google Drive 등 비공식 사용 채널), 프록시 우회 사이트 등으로 유출되는 것을 감시 및 차단(Secure Web Gateway - SWG 등 도입)해야 합니다.
- 클라우드 서버의 아웃바운드 인터넷 통제: 개인정보를 취급하는 백엔드 서버(DB, WAS 등)가 업데이트 등 필수적인 용도 외에 불필요하게 외부 퍼블릭 인터넷 사이트와 임의로 연결(아웃바운드 접속)되지 않도록 NAT Gateway 설정, 프록시 서버 경유 또는 이그레스 필터링(Egress Filtering)을 정교화해야 합니다.
🚀 AI를 활용한 접근 통제 자동화 의견
멀티 클라우드 환경에서는 변경 주기가 짧아 보안 그룹이나 네트워크 접근 제어가 실시간으로 틀어질 수 있습니다. 여기에 AI를 접목한 자동화 전략이 유효합니다.
1. AI 기반 보안 그룹(Security Group) 미스컨피규레이션(Misconfiguration) 자동 수정
- 실시간 비인가 오픈 차단: CSP의 보안 설정 로그(AWS Config, Azure Resource Graph 등)를 AI 컴플라이언스 엔진이 실시간 모니터링합니다. 만약 엔지니어가 임의로 특정 보안 그룹에 0.0.0.0/0 (Any Open) 룰을 적용할 경우, AI가 비즈니스 중요도와 사전 화이트리스트 목록을 즉각 분석하여 비정상 오픈으로 판단되는 경우 해당 규칙을 자동으로 삭제하고 차단 조치한 뒤 담당자에게 통보합니다. (2.6.1, 2.6.2 대응)
2. 가변형 스마트 VPN 및 조건부 원격 접근 (Context-Aware Access Control)
- 위험도 기반 동적 VPN 터널 제어: AI가 원격 접속자의 단말 보안 등급, 로그인 시간대, 위치(Geographic location), 평소 접속 패턴(UEBA)을 종합 분석합니다. 예컨대, 평소 낮에 한국에서 접속하던 엔지니어가 평일 새벽 해외 IP에서 VPN 접속을 시도할 경우, 평소와 다른 단말 상태가 탐지되면 AI가 다단계 MFA를 추가 요구하거나 접근 권한의 수준을 최소 보기 모드로 낮추어 원격 접속을 제한합니다. (2.6.6 대응)
💡 요약 및 결론
멀티 클라우드의 접근 통제는 ‘방화벽 룰셋 관리’ 수준을 넘어 ‘제로 트러스트(Zero Trust) 관점의 다층 방어 체계’를 수립하는 과정입니다.
| 항목 | 핵심 키워드 | 클라우드 환경 핵심 체크리스트 |
|---|---|---|
| 2.6.1 네트워크 접근 | 망 분리, 방화벽 관리 | 개발/운영 VPC 격리, Any Open(0.0.0.0/0) 룰셋 제한 |
| 2.6.2 정보시스템 접근 | OS/가상화 접근 통제 | SSH(22), RDP(3389) 외부 노출 금지, SSM 및 배스천 구성 |
| 2.6.3 응용프로그램 접근 | 앱 RBAC, 기능 제한 | 개인정보 대량 다운로드 버튼 분기 및 일반 상담원 기능 차단 |
| 2.6.4 데이터베이스 접근 | DB 접근제어 솔루션 | DB의 퍼블릭 IP 차단, 쿼리 직접 수행 차단 및 우회로 봉쇄 |
| 2.6.5 무선 네트워크 접근 | 사내 Wi-Fi, 망 격리 | WPA2/3 Enterprise(802.1x) 도입, 게스트 망-사내망 라우팅 차단 |
| 2.6.6 원격접근 통제 | VPN 암호화, 단말 보안 | VPN 기기 보안 검사(Host Checker) 필수화, 접속 로그 2년 보존 |
| 2.6.7 인터넷 접속 통제 | 아웃바운드 제어, 우회 차단 | 사내 단말 유해사이트 차단, 클라우드 서버의 이그레스(Egress) 제한 |
눈에 보이지 않는 네트워크 통로마다 적절한 감시관과 방어선을 설치하는 것, 그것이 ISMS-P 접근 통제 영역을 통과하고 인프라 전체를 해킹 위협으로부터 지켜내는 가장 확실한 해답입니다.