관리자 접근을 하나의 방식으로 통일할 필요는 없다. 웹 기반 관리자 화면과 Cloud Console에는 자원 단위로 사용자를 허용하는 Identity-aware Access가 잘 맞는다. 서버의 SSH·RDP 세션을 통제하고 작업 기록까지 남겨야 한다면 Bastion이 유리하다. 여러 Legacy Protocol, 전용 Client, UDP, 네트워크 진단 도구를 사용해야 한다면 접근 범위를 제한한 VPN이 여전히 현실적인 선택이다.
실제 운영 환경에서는 셋 중 하나만 남기기보다 조합하는 경우가 많다. Identity-aware Access로 사용자를 확인한 뒤 Bastion을 통해 SSH에 접속하거나, VPN으로 관리망에 들어온 뒤 허용된 Bastion을 거쳐 Target Server에 접근할 수 있다. 평상시에는 Identity-aware Access를 사용하고 해당 접근 시스템이나 IdP에 장애가 발생했을 때만 별도의 VPN 또는 Bastion 경로를 Break-glass로 유지할 수도 있다.
따라서 질문은 “VPN이 오래됐는가, Zero Trust가 최신인가”가 아니다. 누가, 어떤 기기로, 어떤 Protocol을 사용해, 정확히 어느 자원까지 도달하며 그 과정에서 어떤 증거가 남고 접근 시스템이 고장 났을 때 어떻게 복구할 것인가를 먼저 정해야 한다.
NIST의 Zero Trust Architecture 역시 네트워크 안쪽에 있다는 이유만으로 사용자를 신뢰하지 않는다. 사용자와 기기를 확인하고 접근을 자원과 세션 단위로 허용하며 Identity·기기 상태·환경 정보에 따라 동적으로 판단하는 것이 원칙이다. 동시에 NIST는 기존 경계 기반 접근과 Zero Trust 방식이 상당 기간 공존할 수 있다고 설명한다.
이 글은 사람이 관리자 화면, Cloud Control Plane, DB 관리 도구, SSH·RDP 같은 관리 Plane에 접근하는 경로만 다룬다. API 요청에서 WAF·Gateway·JWT·mTLS가 맡는 역할, Origin으로 직접 우회할 수 있는 노출 경로, TLS 인증서의 발급·갱신·폐기는 각각 별도의 문제다.
VPN·Bastion·Identity-aware Access는 무엇이 다른가
VPN은 네트워크에 도달하는 통로를 만든다
VPN은 원격 사용자의 장치와 조직의 네트워크 사이에 보호된 통신 경로를 만든다. IPsec VPN을 기준으로 보면 핵심 기능은 IP Network Layer에서 통신을 보호하는 것이다. 연결 이후 사용자가 어떤 Subnet, IP, Port에 도달할 수 있는지는 Routing, Firewall, ACL, Network Segmentation 정책이 결정한다.
VPN이라고 해서 반드시 전체 사내망을 모두 열어야 하는 것은 아니다. 사용자 그룹별 Route와 ACL을 나누고 관리 Subnet만 허용하며 기기 인증서·MFA·Device Posture를 결합할 수 있다. 문제는 이를 하지 않았을 때다. VPN 접속 성공을 내부 전체에 대한 신뢰로 해석하면 한 번 탈취된 계정이나 장치가 넓은 Network Reachability를 얻게 된다.
VPN Gateway 자체도 보호 대상이다. NSA와 CISA는 VPN Server가 보호된 네트워크로 들어가는 진입점이어서 공격자가 노리는 대상이 될 수 있다고 지적하며 강한 인증, 신속한 Patch, 불필요한 기능 비활성화를 권고한다. NSA
Bastion은 관리 Protocol을 통제된 경유지로 모은다
Bastion은 Jump Host 또는 관리 접속 Broker 역할을 한다. 관리자는 Target Server에 직접 SSH·RDP로 연결하지 않고 먼저 Bastion을 통과한다. Target은 Public IP나 외부 공개 Port 없이 Private Network에 둘 수 있고 Bastion에서 허용된 대상과 Protocol만 연결하도록 제한할 수 있다.
Microsoft의 현재 Bastion Architecture도 같은 구조를 사용한다. Bastion이 Virtual Network 안에서 Private IP의 VM으로 RDP·SSH 연결을 중계하며 Target VM은 Public IP가 없어도 된다. 관리형 구현에 따라 TLS 접속, 확장, 가용 영역 배치, 접속 세션 모니터링과 화면 기록 기능을 추가할 수 있다.
다만 Bastion이 존재한다는 사실과 세션이 감사된다는 사실은 다르다. 단순 Linux Jump Host는 SSH 접속 시각만 기록하고 실제 명령은 남기지 않을 수 있다. Session Recording도 특정 등급이나 접속 방식에서만 제공될 수 있다. Azure Bastion의 화면 기록도 별도 기능이며 AWS Session Manager의 경우 SSH·Port Forwarding 방식에서는 내부 Session Data가 다시 암호화되므로 명령 Logging을 제공하지 않는다고 명시한다.
세션 기록, Credential Brokering, 일시적 권한, 승인 Workflow까지 필요하다면 단순 Bastion보다 PAM(Privileged Access Management) 기능을 함께 검토해야 한다.
Identity-aware Access는 자원 앞에서 사용자와 Context를 판단한다
Identity-aware Access는 사용자를 먼저 내부 네트워크에 넣은 뒤 이동하게 하기보다, Application·Resource·Port 앞의 Proxy 또는 Broker가 Identity와 정책을 확인한 후 해당 자원으로 가는 경로만 연다.
Google IAP를 예로 들면 HTTPS Application 앞에 중앙 Authorization Layer를 두고 사용자나 Group별로 접근을 허용한다. Context-aware 정책을 결합하면 IP, 기기 속성, Patch 상태, 시간, URL Path 같은 조건도 사용할 수 있다. SSH·RDP를 포함한 TCP 관리 서비스 역시 구현에 따라 HTTPS Tunnel로 중계할 수 있다.
하지만 Identity-aware라는 이름만으로 모든 구현이 같은 것은 아니다. HTTP·HTTPS는 비교적 자연스럽지만 SSH·RDP·기타 TCP 지원 여부는 제품과 배치 방식에 따라 다르다. UDP, Broadcast, 오래된 Thick Client나 네트워크 Discovery를 요구하는 도구는 지원하기 어렵거나 별도의 VPN이 필요할 수 있다.
Identity-aware Access도 Target의 최종 권한을 대신하지 않는다. Broker가 “이 사용자는 이 서버의 SSH Port에 연결해도 된다”고 판단하더라도, 서버 안에서 Root 권한을 가져도 되는지, DB의 특정 Schema를 변경해도 되는지는 Target OS·Application·Database의 Authorization이 다시 판단해야 한다.
먼저 정해야 할 다섯 가지 질문
제품 비교보다 먼저 다음 질문에 답해야 한다.
누가 접근하는가
내부 관리자, 개발자, 외주 유지보수 업체, Vendor Support, 자동화 시스템을 구분한다.
어떤 기기에서 접근하는가
회사 관리 기기만 허용할지, 개인 기기나 외부 업체 기기를 허용할지 결정한다.
어떤 Protocol이 필요한가
HTTPS만 필요한지, SSH·RDP·DB Client·File Transfer·UDP·Legacy Tool까지 필요한지 확인한다.
정확히 무엇까지 도달해야 하는가
관리자 화면 하나인지, 특정 서버인지, 관리 Subnet 전체인지, 여러 Site의 Network인지 구분한다.
어떤 증거와 복구 경로가 필요한가
접속 시각만 필요한지, 허용 정책과 기기 상태를 남겨야 하는지, 실제 명령·화면까지 기록해야 하는지, IdP 장애 때 누가 어떻게 들어갈지 정한다.
이 다섯 질문을 적지 않으면 최신 제품을 도입해도 기존의 넓은 접근 권한과 불명확한 운영 절차를 그대로 옮길 가능성이 높다.
Administrative Access Decision Matrix
아래 표는 특정 표준이나 Vendor가 공식적으로 부여한 등급이 아니다. NIST의 Zero Trust 원칙과 VPN 지침, Microsoft의 Bastion Architecture, Google의 Identity-aware Access 문서를 이 글의 의사결정 질문에 맞게 합성한 Editorial Assessment다. 제품과 구성에 따라 실제 기능은 달라진다.
Identity·Reachability·Protocol 비교
| 판단 축 | VPN | Bastion | Identity-aware Access |
|---|---|---|---|
| User Identity | IdP·MFA·Client Certificate 연동 가능. 다만 인증이 보통 Tunnel 진입을 허용하며 각 Target의 권한은 별도다. | Bastion 로그인 Identity와 Target OS·DB 계정이 분리될 수 있다. PAM 연동 시 일시 권한·Credential Brokering 가능. | User·Group·Role·Resource가 정책의 중심이다. 자원별 허용과 회수가 비교적 자연스럽다. |
| Device Identity / Posture | Client Certificate, MDM, EDR·Posture 검사 연동 가능. 제품과 설정에 크게 의존한다. | 기본 Jump Host만으로는 사용자 Endpoint의 상태를 확인하지 못할 수 있다. Bastion 앞단에서 별도 검사가 필요하다. | 기기 소유, 암호화, Patch 상태, 위치 등의 Context를 정책에 넣기 쉽다. 구현별 지원 범위는 확인해야 한다. |
| Network Reachability | 허용 Route와 ACL 범위만큼 Network에 도달한다. Segmentation이 약하면 범위가 넓어진다. | 사용자는 Bastion까지 도달하고 Bastion만 허용된 Target에 연결한다. | 일반 Network를 열기보다 특정 Application·Resource·Port로 가는 경로를 허용한다. |
| Protocol Support | IP 기반 Protocol과 Legacy Tool 지원에 가장 유연하다. UDP나 전용 Client가 필요한 환경에 유리하다. | SSH·RDP에 가장 잘 맞는다. DB·File Transfer·Custom Port는 제품과 Proxy 방식에 따라 달라진다. | HTTPS가 가장 자연스럽다. SSH·RDP·일부 TCP도 가능하지만 UDP·Broadcast·Legacy 호환성은 제한될 수 있다. |
| Least Privilege | Route·Subnet·Port·User Group을 세밀하게 나눠야 한다. VPN 자체가 최소권한을 보장하지는 않는다. | Bastion이 접근할 Target, Port, Account를 제한해야 한다. Bastion이 관리망 전체에 도달하면 공백이 남는다. | 자원·사용자·세션 단위 정책에 유리하다. 단, Target 내부 권한은 계속 별도로 제한해야 한다. |
| Credential Exposure | VPN은 전송 경로를 보호할 뿐 Target Password·SSH Key를 없애지 않는다. | Credential을 Bastion에 집중시킬 수도, 일시 Key·Broker 방식으로 노출을 줄일 수도 있다. 설계 차이가 크다. | Federation과 단기 Token으로 정적 비밀을 줄일 수 있다. Legacy Target은 여전히 별도 Password나 Key를 요구할 수 있다. |
| Third-party Access | 전용 Profile·관리 Subnet·접속 시간·Route를 분리하지 않으면 외부 업체에 넓은 접근을 줄 수 있다. | 특정 서버에 대한 제한된 SSH·RDP 유지보수에 적합하다. 작업 Session 기록도 결합하기 쉽다. | 특정 Application·Resource만 외부 Identity에 허용하기 좋다. Federation과 대상 Protocol 지원 여부가 전제다. |
감사·가용성·복구 비교
| 판단 축 | VPN | Bastion | Identity-aware Access |
|---|---|---|---|
| Session Audit | 누가 언제 Tunnel에 연결했는지는 남길 수 있지만 Target에서 무엇을 했는지는 별도 로그가 필요하다. | 접속 대상과 시간을 중앙에서 확인하기 쉽다. 명령·화면 기록은 Proxy·PAM·제품 기능을 별도로 구성해야 한다. | 누가 어느 자원에 허용·거부됐는지 Decision Log를 남기기 좋다. 실제 명령이나 Application 내부 행동까지 보장하지는 않는다. |
| Availability | VPN Gateway, IdP, DNS, Routing이 운영 의존성이 된다. HA와 Patch 전략이 필요하다. | Bastion Instance 또는 Managed Service, Route, Target 계정이 모두 가용해야 한다. 단일 Jump Host는 Single Point of Failure가 된다. | IdP, Policy Engine, Proxy·Connector가 접근 Control Plane이 된다. 복제와 별도 Emergency Path가 필요하다. |
| Operational Complexity | Client 배포, Route, Split Tunnel, Firewall, Gateway Patch, Capacity를 관리한다. | Host Hardening, Patch, Scaling, Target Allowlist, 계정, Session Storage를 운영한다. Managed Bastion은 일부 부담을 줄인다. | IdP, Resource Inventory, Policy, Connector, Device Management, Log Integration을 함께 관리한다. 초기 정책 설계 부담이 크다. |
| Emergency Access | 독립된 VPN Gateway와 관리망을 복구 경로로 사용할 수 있다. 평시 권한과 분리해야 한다. | 제한된 Emergency Bastion을 복구 경유지로 사용할 수 있다. 주 Bastion과 동일 장애 영역이면 의미가 없다. | 평시 접근에는 강하지만 같은 IdP·Policy Engine 장애를 우회하지 못할 수 있다. 독립적인 Emergency Identity·Route가 필요하다. |
| Break-glass | 별도 계정·인증·Route·승인·경보를 사전에 구성한다. 전체 Network를 자동으로 여는 Fail-open은 피한다. | Emergency Bastion과 Target 계정을 사전 구성하고 사용 후 Credential을 회전한다. | 같은 Federation·Conditional Policy에 묶이지 않은 Emergency Identity 또는 Backup IdP가 필요하다. |
| Revocation | VPN Session 종료와 계정·Certificate 폐기뿐 아니라 Target의 기존 Session·Credential도 회수해야 한다. | Bastion Session 종료, Bastion 권한 회수, Target Account·Key·지속 Session 제거가 필요하다. | 중앙 정책과 Token을 빠르게 회수할 수 있지만 Cached Session과 Target 내부 권한은 별도로 종료해야 한다. |
상황별로 무엇부터 선택할까 웹 관리자 화면이 중심이라면 Identity-aware Access부터 본다
내부 운영 Backoffice, Grafana, CI/CD 관리자 화면, Database Web Console처럼 HTTPS로 접근하는 자원은 Identity-aware Access와 잘 맞는다. 사용자·Group별로 자원을 나누고 회사 관리 기기나 특정 시간대처럼 Context 조건을 붙이기 쉽다.
특히 외부 개발사나 유지보수 업체에 Application 하나만 열어야 한다면, 관리 Network 전체를 연결하는 VPN보다 자원 단위 정책이 접근 범위를 설명하고 회수하기 쉽다.
다만 Access Proxy를 켰다고 기존의 직접 접속 경로까지 자동으로 사라지는 것은 아니다. Google IAP도 Administrative Resource에서 IAP를 활성화하는 것만으로 Direct Request가 자동 차단되지는 않는다고 명시한다. 접근 Broker를 우회할 Hostname·IP·Port가 남지 않았는지는 별도로 검증해야 한다.
Private Server의 SSH·RDP가 중심이라면 Bastion을 본다
운영 서버에 직접 SSH·RDP를 열고 싶지 않고 누가 어느 서버에 접속했는지 중앙에서 통제해야 한다면 Bastion이 자연스럽다.
여기에 실제 작업 증거가 필요하면 다음을 별도로 확인해야 한다.
단순 연결 이력인지
Shell Command를 기록하는지
RDP 화면을 기록하는지
Native Client와 Browser Client 모두 기록되는지
File Transfer와 Port Forwarding도 감사되는지
기록이 수정 불가능한 별도 저장소에 보존되는지
“Session Recording 지원”이라는 기능명만 확인하지 말고 사용하는 Protocol과 Client 경로가 실제 Recording 범위에 포함되는지 봐야 한다.
여러 Legacy Protocol과 전용 도구가 필요하면 VPN을 유지할 수 있다
관리 작업에 SSH·RDP뿐 아니라 여러 TCP·UDP Port, Vendor 전용 Client, Network Discovery, 장비 관리 Protocol이 필요하다면 VPN이 더 단순할 수 있다.
이때 VPN을 전체 사내망 진입권으로 만들지 않는 것이 중요하다. 별도의 관리망, 사용자별 Route, Target Allowlist, MFA, 기기 인증, 접속 시간 제한을 적용해야 한다. VPN 접속 이후에도 Target의 인증과 Authorization은 다시 수행해야 한다.
VPN을 유지한다는 것은 Zero Trust를 포기한다는 뜻이 아니다. 네트워크 위치에 자동 신뢰를 부여하지 않고 사용자·기기·자원별로 권한을 줄이고 지속적으로 회수할 수 있다면 Zero Trust 원칙을 기존 접근 경로에도 적용할 수 있다.
세 방식은 어떻게 조합할 수 있을까
Identity-aware Access + Bastion
가장 일반적인 조합 중 하나다.
관리자 │ ├─ User Identity ├─ MFA ├─ Device Posture ▼ Identity-aware Access │ ├─ Resource Policy ├─ Access Decision Log ▼ Bastion / PAM │ ├─ SSH·RDP Protocol 중계 ├─ Target Account·Credential 통제 └─ Session Recording ▼ 관리 대상 서버
Identity-aware 계층은 누가 Bastion을 사용할 수 있는지 판단하고 Bastion은 어느 서버에 어떤 계정으로 접속하며 실제 Session에서 무엇을 했는지 통제한다.
VPN + Bastion
Legacy Tool 때문에 VPN이 필요하지만 관리망 전체의 직접 접속을 허용하고 싶지 않을 때 사용할 수 있다.
관리자 기기 │ ▼ 제한된 VPN │ └─ Bastion 주소만 Reachable │ ▼ Bastion / PAM │ └─ 승인된 Target만 Reachable
VPN 사용자가 Target Server에 직접 연결할 수 있다면 Bastion을 둔 목적이 약해진다. Route와 Firewall Policy가 Bastion 경유를 강제해야 한다.
Identity-aware Access + 제한된 VPN
관리자 Web Application은 Identity-aware Access로 전환하되, 일부 Legacy Network Tool만 별도 VPN에 남길 수 있다. 한 번에 모든 Protocol을 마이그레이션하기 어려운 조직에서 현실적인 전환 방식이다.
NIST도 대규모 조직이 한 번의 기술 교체로 Zero Trust로 이전하기는 어렵고 업무 흐름별로 기존 방식과 새로운 방식이 공존할 수 있다고 설명한다.
평상시 Identity-aware Access + 독립된 Emergency Path
평상시에는 자원 단위 Identity-aware Access를 사용하고 IdP나 정책 시스템 장애에 대비해 별도의 Emergency Identity와 제한된 VPN 또는 Bastion을 유지할 수 있다.
다만 겉으로 경로만 두 개이고 실제로는 같은 IdP, DNS, MFA Service, Network Connector에 의존한다면 독립된 복구 경로가 아니다. 구성요소별 장애 의존성을 그려봐야 한다.
접속 로그·정책 판단 로그·세션 기록을 구분해야 한다
관리자 접근을 감사하려면 “로그가 있는가”가 아니라 어떤 질문에 답할 수 있는지 확인해야 한다.
| Evidence Level | 답할 수 있는 질문 | 대표 Evidence |
|---|---|---|
| Connection Log | 누가 언제 어디에서 어느 Gateway 또는 Target에 연결했는가 | VPN Login, Bastion Connection, Source IP, Target, Session Duration |
| Access Decision Log | 어떤 Identity·기기 상태·Group·정책 때문에 허용 또는 거부됐는가 | Policy Version, Device Posture, Access Level, Authorization Result |
| Session / Action Audit | 접속한 뒤 실제로 어떤 명령·화면·설정 변경을 수행했는가 | Shell Command, RDP Recording, Application Audit, DB Query Audit |
Identity-aware Access는 Access Decision을 설명하는 데 강하지만 실제 Shell Command를 자동으로 기록하지 않을 수 있다. Bastion은 접속 경로를 모으지만 단순 Jump Host라면 명령 기록이 없을 수 있다. VPN은 Tunnel 연결을 기록해도 Target Application 내부의 행동까지 알지 못한다.
Google IAP의 Audit Log는 사용자, Source IP, 요청 자원, 허용 여부 같은 정보를 제공한다. Azure Bastion은 현재 연결 사용자, Target VM, Source IP, 연결 시각·기간을 보여주며 별도 기능으로 화면 기록을 지원한다. 이런 정보만으로 최종 변경 내용을 모두 재구성할 수 있는지는 Target의 OS·Application·Database Audit와 함께 판단해야 한다.
접근 시스템 자체를 Production Dependency로 관리해야 한다
Zero Trust 또는 Identity-aware Access를 도입하면 보안 Control Plane이 새로운 운영 의존성이 된다. NIST는 Policy Engine, Policy Administrator, Policy Enforcement Point가 중단되면 자원 접근 자체가 막혀 조직의 운영이 영향을 받을 수 있다고 지적한다. 이는 Zero Trust에만 있는 문제는 아니며 Legacy Remote-access VPN에도 유사한 장애 위험이 있다.
따라서 접근 아키텍처에는 정상 흐름뿐 아니라 실패 정책도 있어야 한다.
| 실패한 구성요소 | 평상시 기본 정책 | 사전에 설계할 예외 |
|---|---|---|
| IdP·Federation | 관리자 접근은 원칙적으로 Fail-closed | 같은 Federation에 의존하지 않는 Emergency Identity 또는 Backup IdP |
| Policy Engine·Access Broker | 고위험 자원 접근 중단 | 별도 Emergency Gateway·Bastion과 제한된 Target Role |
| Device Posture Service | 조건을 조용히 무시하지 않음 | 승인된 Secure Workstation에서 제한된 시간·자원만 허용 |
| Session Recording | 고위험 변경은 중단하거나 별도 승인 | 독립 Log와 수기 Incident Record를 병행한 제한적 Emergency Session |
| 중앙 Log Sink | Local Buffer 또는 제한 모드 | 독립 저장소·수기 Evidence·사후 Reconciliation |
| Primary Bastion | Target 직접 공개 금지 | 다른 장애 영역의 Emergency Bastion 또는 Cloud Console Recovery Path |
관리자 접근에서 자동 Fail-open은 편리해 보이지만 정책 시스템 장애가 곧 전체 관리 Plane 공개로 이어질 수 있다. 고위험 환경에서는 평상시 경로를 자동으로 넓히기보다 제한된 Break-glass 경로를 따로 만드는 편이 낫다.
Break-glass Checklist
Break-glass는 정상 통제를 몰래 우회하는 Backdoor가 아니다. 정상 접근 시스템이 고장 났을 때도 제한된 인원이 필요한 복구 작업을 수행할 수 있도록 사전에 설계하고 감사하는 비상 운영 절차다.
Microsoft, Google Cloud, AWS의 공식 지침은 공통적으로 Emergency Identity의 중복성, 평시 Identity Chain과 다른 의존성, 강한 인증, 모든 사용에 대한 경보, 정기 시험과 사용 후 Credential 회수를 강조한다.
발동 조건과 책임
Break-glass를 사용할 수 있는 장애·보안 사고 조건이 문서화되어 있는가
발동을 승인할 Owner와 대체 승인자가 정해져 있는가
야간·휴일에도 승인 절차가 작동하는가
관련 Incident 또는 변경 Ticket 없이 편의를 위해 사용하지 못하게 했는가
파괴적 작업에는 가능한 경우 2인 승인 또는 Dual Control을 요구하는가
Emergency Identity와 Credential
하나의 계정이나 하나의 Hardware Key가 Single Point of Failure가 되지 않도록 둘 이상의 Emergency Identity 또는 Credential Set이 있는가
적어도 하나의 Emergency Identity가 평시 Federation·SSO·Conditional Access 장애로 함께 막히지 않는가
평상시 관리자 계정과 다른 방식의 Phishing-resistant MFA나 Hardware Credential을 사용하는가
Credential과 Recovery Device가 서로 다른 안전한 위치에 보관되어 있는가
자동 휴면 삭제·만료·인사 이동 처리로 계정이 사라지지 않는가
Emergency Identity가 평상시 업무나 자동화에 사용되지 않는가
Reachability와 권한
Emergency Access Path가 사고 전에 미리 구성되어 있는가
전체 Network가 아니라 복구에 필요한 Management Plane과 Target만 도달 가능한가
허용 Role과 명령 범위가 사전에 정해져 있는가
가능하다면 권한과 Session에 최대 사용 시간이 설정되어 있는가
Break-glass를 위해 관리자 Port나 화면을 Internet에 상시 공개하지 않았는가
Cloud Access와 On-premises Access가 하나의 장애 의존성에 묶여 있지 않은가
감사와 탐지
Emergency Identity의 성공·실패 로그인마다 즉시 경보가 발생하는가
사용자, 시간, Source, Target, 발동 사유, 승인자를 기록하는가
가능한 범위에서 Shell Command·화면·설정 변경을 별도 기록하는가
주 접근 시스템과 다른 Log 저장 위치에도 Evidence가 남는가
기록 시스템이 중단됐을 때 사용할 수기 Incident Log Template이 있는가
시험과 정상화
위험도에 맞는 주기로 실제 로그인과 제한된 관리 작업을 시험하는가
시험에 IdP 장애, MFA 장애, DNS 장애, 주 Bastion 장애 시나리오가 포함되는가
담당자가 문서만 보고 복구 경로를 사용할 수 있는가
사용이 끝나면 모든 Session·Token·Certificate·Key를 종료하거나 회수하는가
장기 Credential을 사용했다면 즉시 회전하는가
수행한 명령과 변경을 검토하고 정상 접근 경로로 복귀했는지 확인하는가
실제 사용 또는 훈련 후 Runbook과 권한 범위를 수정하는가
흔히 실패하는 다섯 가지 설계
VPN 연결을 관리자 권한으로 간주한다
VPN은 Network Reachability를 제공한다. VPN에 들어온 사용자가 모든 관리자 화면과 Server에 접근할 수 있어야 한다는 뜻은 아니다. VPN 뒤에서도 사용자 Identity, Target Authorization, Network Segmentation이 필요하다.
Bastion을 두었지만 우회 경로를 남긴다
관리자는 Bastion을 사용하지만 Target의 SSH·RDP Port도 다른 Route에서 직접 도달할 수 있다면 감사와 통제는 선택 사항이 된다. Bastion 경유를 Architecture와 Network Policy가 강제해야 한다.
Bastion 접속 기록을 작업 증거라고 판단한다
사용자 A가 서버 B에 30분 접속했다는 사실과 어떤 명령으로 어떤 설정을 바꿨다는 사실은 다르다. Session Recording과 Target Audit를 별도로 설계해야 한다.
Identity-aware Access를 켜고 직접 접근 경로를 확인하지 않는다
Access Proxy가 동작해도 다른 Hostname, Direct IP, 내부 Route, 관리 Port가 남아 있으면 Proxy의 인증·정책을 통과하지 않을 수 있다. 이 문제의 구체적인 노출 경로와 차단 방법은 Origin Security 영역에서 따로 다뤄야 한다.
IdP 계정을 비활성화하면 모든 접근이 끝난다고 생각한다
이미 발급된 Token, VPN Tunnel, Bastion Session, Target OS Session, SSH Key, Local Account가 남아 있을 수 있다. Revocation은 Identity, Access Path, Target Credential, Active Session을 모두 확인해야 끝난다.
선택 결과를 문장으로 남겨야 한다
접근 방식을 선택했다면 제품명보다 아래와 같은 운영 문장을 남기는 편이 유용하다.
운영 관리자 화면은 회사가 관리하는 기기에서만 Identity-aware Access를 통해 접근한다. 사용자와 Group은 자원별로 허용하며 모든 허용·거부 판단을 중앙 Log에 기록한다.
Production Server의 SSH는 Bastion과 일시 계정을 통해서만 허용한다. Target Server는 관리자 단말에서 직접 Reachable하지 않으며 연결 이력과 Shell Audit를 별도로 보존한다.
Legacy Network Tool은 별도 관리 VPN에서만 사용한다. VPN 사용자는 Bastion과 승인된 장비 주소만 Reachable하며 일반 업무 Network에는 접근할 수 없다.
IdP 또는 Access Broker 장애 시에는 사전 등록된 Emergency Identity와 별도 Bastion을 사용한다. 모든 사용은 Incident로 선언하고 복구 후 Session 종료·Credential 회전·사후 검토를 수행한다.
이 문장을 작성할 수 없다면 아직 제품은 골랐어도 접근 아키텍처는 결정되지 않은 것이다.
VPN을 없앨 것인지보다 신뢰와 경로를 어디서 끊을지 결정해야 한다
VPN은 여러 Protocol과 Network Tool을 연결하는 데 강하다. Bastion은 SSH·RDP 같은 관리 Session을 통제된 경유지로 모으는 데 강하다. Identity-aware Access는 사용자·기기·자원별 정책과 허용 판단을 중앙화하는 데 강하다.
어느 하나도 그 자체로 완전하지 않다. VPN은 Target 권한과 작업 감사를 대신하지 않는다. Bastion은 사용자 기기 상태나 Application Authorization을 자동으로 해결하지 않는다. Identity-aware Access는 모든 Legacy Protocol을 지원하지 않으며 Target 내부 권한과 독립된 복구 경로도 따로 필요하다.
관리자 접근 방식을 정할 때는 다음 순서가 적절하다.
Protocol → Resource Scope → User Identity → Device Trust → Credential → Audit → Availability → Break-glass
“무엇이 더 최신인가”보다 이 순서로 질문에 답할 때, 평상시에는 최소한으로 열리고 장애 시에는 실제로 복구할 수 있는 관리 Plane을 만들 수 있다.