VPN과 Bastion, Identity-aware Access는 무엇이 다른가
관리자 접근을 하나의 방식으로 통일할 이유는 없습니다. 웹 기반 관리자 화면과 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 방식이 상당 기간 공존한다고 설명합니다.[1] 이 글은 사람이 관리자 화면, Cloud Control Plane, DB 관리 도구, SSH·RDP 같은 관리 Plane에 접근하는 경로만 다룹니다. API 요청에서 WAF·Gateway·JWT·mTLS가 맡는 역할, Origin으로 직접 우회하는 노출 경로, TLS 인증서의 발급·갱신·폐기는 각각 별도의 문제입니다.
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, 불필요한 기능 비활성화를 권고합니다.
Bastion은 관리 Protocol을 통제된 경유지로 모읍니다. 관리자는 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가 없어도 됩니다. 다만 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를 판단합니다. 사용자를 먼저 내부 네트워크에 넣은 뒤 이동하게 하기보다, 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이 다시 판단합니다.[2]
- VPN
- VPN은 원격 장치와 조직 네트워크 사이에 보호된 통신 경로를 만드는 방식이며, 연결 이후 어디까지 도달할지는 Routing과 Firewall, ACL, Segmentation이 정합니다.
- Bastion
- Bastion은 관리자가 Target Server에 직접 연결하지 않고 반드시 거쳐야 하는 통제된 경유지이며, 허용된 대상과 Protocol만 연결하도록 제한합니다.
- Identity-aware Access
- Identity-aware Access는 사용자를 내부 네트워크에 넣는 대신 자원 앞의 Proxy나 Broker가 Identity와 정책을 확인한 뒤 해당 자원으로 가는 경로만 여는 방식입니다.
제품 비교보다 먼저 정할 다섯 가지 질문
첫째, 누가 접근하는가. 내부 관리자, 개발자, 외주 유지보수 업체, Vendor Support, 자동화 시스템을 구분합니다.
둘째, 어떤 기기에서 접근하는가. 회사 관리 기기만 허용할지, 개인 기기나 외부 업체 기기를 허용할지 결정합니다.
셋째, 어떤 Protocol이 필요한가. HTTPS만 필요한지, SSH·RDP·DB Client·File Transfer·UDP·Legacy Tool까지 필요한지 확인합니다.
넷째, 정확히 무엇까지 도달해야 하는가. 관리자 화면 하나인지, 특정 서버인지, 관리 Subnet 전체인지, 여러 Site의 Network인지 구분합니다.
다섯째, 어떤 증거와 복구 경로가 필요한가. 접속 시각만 필요한지, 허용 정책과 기기 상태를 남겨야 하는지, 실제 명령·화면까지 기록해야 하는지, IdP 장애 때 누가 어떻게 들어갈지 정합니다.
이 다섯 질문을 적지 않으면 최신 제품을 도입해도 기존의 넓은 접근 권한과 불명확한 운영 절차를 그대로 옮기게 됩니다.
서비스 앞단에서 요청을 분류하고 방어 — 요청과 차단 기록을 살펴 방어 규칙을 조정하고 인증서와 접근 통제를 함께 관리합니다.
Identity와 도달 범위, Protocol을 비교합니다
아래 표의 등급은 특정 표준이나 Vendor가 공식적으로 부여한 등급이 아닙니다. 이 표는 여러 문서를 합성한 편집 판단입니다. NIST의 Zero Trust 원칙과 VPN 지침,[1] Cloud-native 환경의 접근통제 모델을 참고했습니다.[2] Microsoft의 Bastion Architecture, Google의 Identity-aware Access 문서도 이 글의 의사결정 질문에 맞게 합성했습니다. 제품과 구성에 따라 실제 기능은 달라집니다.
판단 축 | 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 지원 여부가 전제다 |
감사와 가용성, 복구를 비교합니다
Identity와 Protocol만으로 결정하면 장애 시점에 관리 Plane 전체가 잠기는 설계가 나옵니다. 감사 범위, 가용성 의존성, 운영 복잡도, 비상 접근, Break-glass, 회수 절차를 같은 표에서 함께 봅니다.
판단 축 | 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 원칙이 적용됩니다.[1]
세 방식은 어떻게 조합할까
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에 도달합니다. 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로 이전하기는 어렵고 업무 흐름별로 기존 방식과 새로운 방식이 공존한다고 설명합니다.[3]
평상시 Identity-aware Access에 독립된 Emergency Path를 더하는 조합도 있습니다. 평상시에는 자원 단위 Identity-aware Access를 쓰고 IdP나 정책 시스템 장애에 대비해 별도의 Emergency Identity와 제한된 VPN 또는 Bastion을 유지합니다. 다만 겉으로 경로만 두 개이고 실제로는 같은 IdP, DNS, MFA Service, Network Connector에 의존한다면 독립된 복구 경로가 아닙니다. 구성요소별 장애 의존성을 그려 봐야 합니다.
접속 로그와 정책 판단 로그, 세션 기록을 구분합니다
관리자 접근을 감사하려면 "로그가 있는가"가 아니라 어떤 질문에 답할 수 있는지 확인해야 합니다. 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와 함께 판단해야 합니다.
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 |
관측에서 복구와 개선까지 이어지는 운영 — 서비스 지표와 경보를 기준으로 대응하고 변경 이력과 사후 보고를 다음 개선에 연결합니다.
접근 시스템 자체를 Production Dependency로 관리합니다
Zero Trust 또는 Identity-aware Access를 도입하면 보안 Control Plane이 새로운 운영 의존성이 됩니다. NIST는 Policy Engine, Policy Administrator, Policy Enforcement Point가 중단되면 자원 접근 자체가 막혀 조직의 운영이 영향을 받는다고 지적합니다. 이는 Zero Trust에만 있는 문제가 아니며 Legacy Remote-access VPN에도 유사한 장애 위험이 있습니다.[1] 따라서 접근 아키텍처에는 정상 흐름뿐 아니라 실패 정책도 있어야 합니다.
관리자 접근에서 자동 Fail-open은 편리해 보이지만 정책 시스템 장애가 곧 전체 관리 Plane 공개로 이어집니다. 고위험 환경에서는 평상시 경로를 자동으로 넓히기보다 제한된 Break-glass 경로를 따로 만드는 편이 낫습니다.
실패한 구성요소 | 평상시 기본 정책 | 사전에 설계할 예외 |
|---|---|---|
| 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 |
Break-glass는 사전에 설계하고 감사합니다
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은 여러 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이 만들어집니다.
