Zero Trust 관점의 관리자 시스템 접근 통제 설계

관리자 시스템은 계정 하나만 뚫려도 전체 데이터와 설정이 넘어가는 곳이라, "VPN 안에 들어왔으니 믿는다"는 경계 모델이 가장 위험하게 작동하는 자리다. 이 글은 Zero Trust 원칙으로 관리자 접근을 신원, 단말, 정책 판정, 권한, 세션, 감사 여섯 겹으로 나눠 설계하고, 각 겹에서 무엇을 정하고 무엇을 남겨야 하는지 정리한다.

운영자가 출입증, 지문, 보안 키를 세 개의 검문대에서 차례로 확인받은 뒤 관제 콘솔로 들어가는 장면

한눈에 보기

겹	묻는 질문	핵심 통제	남길 기록
신원	누구인가	개인 계정, IdP 일원화, 피싱에 강한 MFA	로그인 성공·실패, MFA 방식
단말	어디서 들어오나	등록된 관리용 단말, 단말 인증서, EDR 상태	단말 ID, 상태 판정 결과
정책 판정	지금 허용해도 되나	PDP가 요청마다 판정, PEP가 집행	판정 입력과 결과
권한	무엇까지 할 수 있나	상시 권한 대신 시간 제한 권한(JIT)	승인자, 승인 사유, 만료 시각
세션	실제로 무엇을 했나	접근 프록시 경유, 세션 녹화	명령·쿼리·화면 기록
감사	나중에 증명할 수 있나	지울 수 없는 저장소, 정기 검토	검토 결과와 조치

관리자 단말이 IdP에서 로그인과 MFA를 거친 뒤 접근 프록시를 통해서만 관리자 시스템에 들어가고, 접근 프록시는 정책 판정 결과와 단말·역할 신호에 따라 허용하며 세션을 감사 로그에 남기고, 단말에서 관리자 시스템으로 바로 가는 경로는 막혀 있는 구성

그림에서 관리자 시스템으로 들어가는 길은 접근 프록시 하나뿐이다. 이 한 가지 결정이 나머지 통제를 모두 의미 있게 만든다.

왜 VPN 하나로는 부족한가

경계 모델은 "망 안쪽은 안전하다"를 전제로 한다. VPN에 붙은 순간 관리자 콘솔, 서버 SSH, DB 포트가 모두 열리고, 그 뒤로는 누가 무엇을 하는지 시스템이 다시 묻지 않는다. 그래서 VPN 계정 하나가 유출되면 공격자는 관리자와 같은 위치에 선다.

NIST SP 800-207은 Zero Trust를 몇 가지 원칙으로 정리한다. 이 글에서 쓰는 것은 세 가지다.

자원 단위로 접근을 허용한다. 망 전체가 아니라 "이 사람이 이 시스템의 이 기능"에 접근하는 것을 따로 판단한다.
세션마다 판단한다. 아침에 한 번 로그인했다고 저녁까지 믿지 않는다. 단말 상태나 위치가 바뀌면 다시 판정한다.
정책은 여러 신호로 동적으로 정한다. 역할만 보지 않고 단말 상태, 시간, 요청 대상의 민감도를 함께 본다.

망분리 환경이라도 이 원칙은 그대로 적용된다. 업무망 안쪽 역시 "안쪽이니 믿는다"로 두면 내부 단말 하나가 감염됐을 때 같은 일이 생긴다.

1. 신원: 사람마다 계정, 피싱에 강한 MFA

할 일

공유 계정을 없앤다. admin, root를 여러 명이 쓰면 로그에 남는 이름이 사람을 가리키지 못한다. 시스템 계정은 남겨 두되 사람은 개인 계정으로 로그인한 뒤 권한을 올린다.
인증을 IdP 하나로 모은다. 관리자 콘솔, 서버, DB, 클라우드 콘솔마다 따로 계정을 만들면 퇴사자 회수가 시스템 수만큼 늘어난다.
MFA는 피싱에 강한 방식(FIDO2/WebAuthn 보안 키, 플랫폼 인증기)을 기본으로 한다. SMS나 OTP 숫자 입력은 가짜 로그인 화면에 그대로 넘겨질 수 있다.
인사 시스템과 연결해 퇴사·전보 시 계정과 그룹을 자동으로 회수한다.

산출물: 관리자 계정 목록(사람과 1:1), IdP 연동 시스템 목록, MFA 정책서

2. 단말: 등록된 관리용 단말만

신원이 맞아도 감염된 노트북에서 들어오면 소용이 없다. 관리자 접근은 "누가"와 함께 "어떤 단말로"를 확인한다.

관리용 단말을 등록하고 단말 인증서를 발급한다. 인증서가 없는 단말은 로그인 화면까지도 가지 못하게 한다.
EDR 실행 여부, OS 패치 수준, 디스크 암호화 여부를 신호로 받는다. 기준에 못 미치면 접근을 막거나 읽기 전용으로 낮춘다.
개인 PC·휴대폰에서의 관리자 접근은 원칙적으로 막는다. 예외가 필요하면 기능(조회만)과 기간을 정해 승인받는다.

3. 정책 판정과 집행을 나눈다

접근 통제를 각 시스템 코드에 흩어 두면 기준이 시스템마다 달라진다. 판정은 정책 판정 지점(PDP) 한 곳에서 하고, 집행은 접근 프록시 같은 정책 집행 지점(PEP)이 맡는다.

정책을 코드로 두면 리뷰와 시험이 가능하다. 아래는 Open Policy Agent(Rego)로 쓴 예시다. 운영 환경 관리 기능은 피싱에 강한 MFA, 관리 단말, 정상 EDR, 역할, 승인 번호, 업무 시간을 모두 만족할 때만 허용한다.

package admin.access

import rego.v1

default allow := false

allow if {
	input.user.mfa == "phishing_resistant"
	input.device.managed
	input.device.edr_healthy
	"ops-admin" in input.user.roles
	input.resource.env == "prod"
	input.request.approval_id != ""
	within_work_hours
}

within_work_hours if {
	hour := time.clock([time.now_ns(), "Asia/Seoul"])[0]
	hour >= 8
	hour < 20
}

판정 입력과 결과는 그대로 로그로 남긴다. "왜 허용됐는가"를 나중에 설명하려면 결과만이 아니라 입력이 필요하다.

4. 권한: 상시 권한 대신 필요할 때만

운영 DB 쓰기 권한을 1년 내내 들고 있는 계정은 1년 내내 공격 대상이다. 높은 권한은 작업이 있을 때만 시간 제한으로 준다(Just-In-Time).

요청자가 작업 내용과 대상을 적어 권한을 요청하고, 다른 사람이 승인한다. 본인 승인은 막는다.
권한에는 만료 시각을 붙인다. 작업 단위로 1~8시간처럼 짧게 두고, 연장은 다시 요청하게 한다.
서버 접근은 짧은 수명의 SSH 인증서로 주면 회수할 필요 자체가 없다. 승인 시스템이 CA로 서명해 8시간짜리 인증서를 발급하는 식이다(ssh-keygen -s admin_ca -I 요청번호 -n deploy -V +8h id_ed25519.pub).
IdP 장애에 대비한 비상 계정(break-glass)은 따로 두되 봉인한다. 사용 즉시 알림이 가고, 사용 후 비밀번호를 바꾼다.

5. 세션: 프록시를 거치고 기록한다

관리자 시스템, SSH, RDP, DB 접근은 모두 접근 프록시를 지나게 한다. 프록시는 세션을 열기 전에 PDP에 묻고, 열린 세션의 명령·쿼리·화면을 기록한다.

프록시를 두는 것만으로는 부족하다. 대상 서버가 프록시 말고 다른 곳에서 오는 접속도 받으면 우회로가 남는다. 방화벽과 서버 설정 양쪽에서 프록시 대역만 받게 한다.

# /etc/ssh/sshd_config (관리 대상 서버, 주소는 예시)
PasswordAuthentication no
TrustedUserCAKeys /etc/ssh/admin_ca.pub
# 10.20.0.0/24 = 접근 프록시 대역
AllowUsers *@10.20.0.0/24

웹 관리자 콘솔도 같다. 콘솔을 인터넷이나 업무망 전체에 열지 말고, 프록시 뒤에 두어 프록시가 붙인 신원 정보만 믿게 한다.

6. 감사: 지울 수 없는 곳에 남긴다

관리자 권한을 가진 사람이 자기 기록을 지울 수 있으면 감사 로그는 의미가 없다.

로그는 관리 대상 시스템과 다른 계정·권한 체계의 저장소로 보낸다. 덮어쓰기와 삭제가 막힌(WORM) 보관을 쓴다.
보관 기간은 기관 지침과 관련 법령 기준을 확인해 정하고, 그 근거를 문서에 적는다.
월 1회처럼 주기를 정해 권한 부여 내역, 비상 계정 사용, 업무 시간 외 접근을 검토하고 결과를 남긴다. 아무도 보지 않는 로그는 사고 뒤에만 열린다.

통제를 왜 두는가

통제	막는 일	없으면 생기는 일
개인 계정 + IdP	책임 소재 불명	사고 기록에 `admin`만 남아 누가 했는지 모름
피싱에 강한 MFA	자격 증명 탈취	가짜 로그인 화면 하나로 관리자 권한 유출
관리 단말 확인	감염 단말 경유 접근	정상 계정이 악성코드의 통로가 됨
PDP/PEP 분리	시스템마다 다른 기준	한 시스템만 느슨해도 그쪽으로 우회
JIT 권한	상시 권한 남용	휴면 고권한 계정이 장기간 노출
프록시 단일 경로	우회 접속	기록 없는 직접 접속이 생김
WORM 감사 로그	흔적 삭제	사고 경위를 증명하지 못함

자주 하는 실수

VPN에 MFA를 붙이고 끝낸다. 들어온 뒤 모든 포트가 열려 있으면 경계 모델 그대로다. 자원 단위 판정이 빠져 있다.
프록시를 두고 직접 경로를 막지 않는다. 급할 때 쓰던 직접 SSH가 남아 있으면 결국 다들 그 길을 쓴다.
비상 계정을 평소에 쓴다. 편하다는 이유로 쓰기 시작하면 가장 강한 권한이 가장 덜 통제된다.
정책을 콘솔 클릭으로만 관리한다. 누가 언제 정책을 바꿨는지 리뷰할 수 없고 시험도 못 한다.
로그를 같은 서버에 쌓는다. 관리자 권한을 얻은 공격자가 가장 먼저 지우는 곳이다.

점검표

관리자 계정이 모두 사람과 1:1로 대응하고 공유 계정 로그인이 없다
관리자 시스템·서버·DB 인증이 IdP 하나로 모여 있다
관리자 MFA가 FIDO2/WebAuthn 같은 피싱에 강한 방식이다
퇴사·전보 시 인사 시스템 연동으로 권한이 자동 회수된다
등록되지 않은 단말에서는 관리자 로그인 화면에 도달할 수 없다
접근 정책이 코드로 저장되고 변경 이력과 리뷰가 남는다
운영 환경 고권한은 승인과 만료 시각이 있는 JIT로만 부여된다
대상 서버의 방화벽과 sshd 설정이 접근 프록시 대역만 허용한다
세션 기록과 판정 로그가 별도 계정의 삭제 불가 저장소에 쌓인다
비상 계정 사용과 업무 시간 외 접근을 정기적으로 검토한 기록이 있다

관리자 접근의 Zero Trust는 새 제품을 들이는 일이 아니라, 관리자 시스템으로 가는 길을 접근 프록시 하나로 줄이고 그 길에서 매번 신원·단말·권한을 다시 묻고 기록하는 구조를 만드는 일이다.