관리 업무와 일상 업무를 한 컴퓨터에서? Game Over.

컴퓨터 한 대, 탭 두 개, 클릭 한 번

이 시나리오는 전혀 화려하지 않으며, 바로 그 점이 이것을 그토록 위험하게 만듭니다. 한 관리자가 평소 쓰는 오피스 노트북 앞에 앉아 있습니다. 왼쪽 브라우저 탭에는 Global Admin 권한과 Intune 관리자 권한이 딸린 Microsoft 365 관리 센터가 열려 있습니다. 오른쪽 탭에서 그는 “무료 도구”를 내려받습니다. Invoice_2026.pdf.exe입니다. 클릭 한 번, PowerShell 페이로드, 지속성 확보, 권한 상승 진행. 기업 IT의 심장부인 Tier 0로 가는 길이 열립니다.

Game Over.

MITRE ATT&CK은 현재 엔터프라이즈 환경에 대해 222개 기법과 475개 서브 기법, 합쳐서 권한을 상승시키고 측면으로 이동하며 기업의 가장 민감한 자산에 도달하는 알려진 경로를 700개 가까이 문서화하고 있습니다. 공격자에게 필요한 것은 그중 정확히 하나입니다. 그리고 저희가 함께한 대부분의 인시던트 대응 현장에서는 같은 패턴이 드러납니다. 이메일을 읽고, 인터넷을 서핑하고, Teams에서 채팅하던 바로 그 기기에서 관리 업무가 이루어졌다는 것입니다.

“Assume Breach”를 진지하게 받아들이는 사람은, 그리고 NIS2 이후로는 그 외의 선택지가 거의 없는데, 불편한 결론을 받아들여야 합니다. 어떤 것들은 그저 같은 컴퓨터에 있어서는 안 됩니다. 절반의 분리는 분리가 아닙니다.

뻔한 답들이 충분하지 않은 이유

흔한 반사적 대응은 우리 모두 알고 있습니다. 점프 서버? 침해된 클라이언트에서 리버스 프록시 터널 하나면 공격자는 점프 박스를 그대로 통과해 달려갑니다. 같은 머신, 같은 브라우저, 같은 위험입니다. 고전적인 Privileged Access Management(PAM)를 자체 테넌트에 구축하는 방법? 그러면 곧바로 이런 질문이 생깁니다. 그 관리 환경은 누가 관리합니까? 보호되어야 할 관리자 워크스테이션이 자신이 보호해야 할 테넌트와 같은 테넌트 안에 살고 있다면, 만들어 낸 것은 벽이 아니라 원입니다. 그리고 오피스 노트북에서 접속하는 가상 데스크톱은요? 그것은 그 노트북의 키로거를 그대로 물려받습니다. 화면은 가상이지만 키 입력은 실제입니다. Zero Trust는 관리 업무와 일상 업무가 기기를 공유하는 바로 그 지점에서 끝납니다.

Managed Red Tenant: 아키텍처로서의 분리

바로 여기에서 Managed Red Tenant(MRT)가 출발합니다. 오직 관리 업무만을 위한, 완전히 코드로 관리되고 대대적으로 강화된 전용 테넌트 환경입니다. Tier 0 업무를 위해서는 Managed Service로 운영되는 Privileged Access Workstation(PAW)이 준비되어 있으며, 강화된 하드웨어 PAW는 별도의 물리적 기기로 제공됩니다. Tier 1 업무에는 Azure Virtual Desktop을 기반으로 하는 가상 액세스 워크스테이션 VAW가 쓰이며, compliant 기기에서만, FIDO2로만, Conditional Access 아래에서만 접근할 수 있습니다. 여기에 더 나은 편의성을 위해 특별히, 그리고 최대한 안전하게 구성된 iPad가 보완됩니다.

하지만 CIO에게 결정적인 지점은 기술이 아니라 운영 모델입니다. Red Tenant의 모든 변경은 Configuration as Code로 CI/CD 파이프라인을 거치며, 고객의 명시적인 승인이 있어야 배포됩니다. 이 공동 책임 원칙은 Managed Services를 구매하는 모든 사람이 던져야 할 질문에 답합니다. 서비스 제공업체 자신이 침해되면 어떻게 되는가? 답은 이렇습니다. 아무 일도 일어나지 않습니다. 고객의 승인 없이는 Red Tenant에서 구성 한 줄도 바뀌지 않습니다. 관리 계층은 고객의 위험 영역 밖에 놓이고, 거부권은 고객에게 남습니다.

운영상의 이득은 두 가지입니다. 첫째, 좀처럼 얻기 힘든 선명한 구분이 생깁니다. 운영 환경에 대한 모든 정당한 관리 접근은 정의상 MRT 머신에서 옵니다. 그 밖의 모든 것은 공격입니다. 이는 SOC에 잡음 없는 신호를 주어, 오탐을 분류하는 대신 즉시 대응할 수 있게 합니다. 둘째, 오피스 환경에 대한 공격이 성공했을 때 앞을 막는 것은 과속 방지턱이 아니라 벽입니다. 침해된 오피스 노트북에서 책상 옆에 별도의 기기로 놓여 있는 하드웨어 PAW로 건너뛰는 일은 공격자에게 극도로 어렵거나 불가능합니다.

그래도 일어난다면? Extra Life.

경험 있는 CIO라면 누구나 압니다. 100퍼센트의 보안은 없습니다. Assume Breach는 자신의 방어가 실패하는 경우까지 계획에 넣는다는 뜻이기도 합니다. 2026년 3월의 Stryker 사건은 그 경계가 얼마나 좁은지 보여 주었습니다. 침해된 Intune 관리자 계정 하나로 79개국의 기기를 초기화하기에 충분했습니다. 오늘날 랜섬웨어 그룹은 백업과 Active Directory, 즉 재구축에 필요한 바로 그 시스템을 표적으로 노립니다. 그때가 되어서야 즉흥적으로 대응하기 시작하는 기업은, 파일 서버가 암호화되고 작동하는 신원도 없고 커뮤니케이션 인프라 대신 전화 연락망만 있는 상태에서, 회사가 멈춰 서는 날과 주를 잃게 됩니다.

Red Tenant가 “Game Over”라는 말이 나오지 않게 막는 것이라면, Managed Dark Tenant는 Extra Life입니다. 평상시에는 잠들어 있다가 비상 상황에 활성화되는, 미리 준비된 재가동 환경입니다. 24/7 비상 번호로 전화 한 통이면 재해 복구 프로세스가 시작됩니다. 가상 워 룸이 침해되었을 수 있는 운영 환경과 무관하게 모든 핵심 이해관계자와의 안전한 커뮤니케이션을 즉시 구축합니다. Dark Tenant는 Infrastructure as Code로 구축되어 있기 때문에 모든 핵심 재가동 프로세스가 사전에 정의되고 자동화되어 있습니다. Active Directory와 신원 같은 시스템상 핵심적인 구성 요소는 스트레스 상황에서 임시로 조립되는 대신 깔끔하게 복구됩니다. 그 결과는 이렇습니다. 즉흥적인 재가동이 실무에서 흔히 몇 주를 잡아먹는 대신, 몇 시간에서 며칠 수준의 Recovery Time Objective(RTO)와 정의된 Recovery Point Objective(RPO)를 갖게 됩니다.

두 겹의 회복력

Red Tenant와 Dark Tenant는 서로 다른 두 가지 질문에 답하며, 그 둘이 합쳐져야 비로소 완전한 그림이 됩니다. Red Tenant는 이렇게 답합니다. 침해된 클라이언트가 침해된 도메인이 되는 일을 어떻게 막을 것인가? Dark Tenant는 이렇게 답합니다. 그래도 그런 일이 일어났을 때 어떻게 계속 움직일 것인가? 하나는 벽이고, 다른 하나는 안전망입니다.

오스트리아 기업에게는 여기에 규제적 차원이 더해지며, 그것은 곧 매우 구체적인 것이 됩니다. 2026년 10월 1일에 발효되는 NISG 2026과 함께 약 4,000개 오스트리아 기업이 입증 가능한 사이버보안 의무의 대상이 되며, 여기에는 위험 관리와 사업 연속성, 비상 계획, 위기 관리가 명시적으로 포함됩니다. 관리 접근이 아키텍처 차원에서 격리되어 있고 비상 상황을 위해 검증되고 자동화된 재가동 환경이 준비되어 있다고 감독 기구에 설명할 수 있는 사람은, 인식 교육과 희망을 내세우는 사람과는 다른 논의를 하게 됩니다.

두 서비스 모두 저희가 Managed Service로 운영하며, 이를 담당하는 팀은 BSI 인증 APT 대응 서비스 제공자로서 이미 불이 난 상황에서 정기적으로 반대편에 서 보고, 그 경험을 곧바로 아키텍처에 되돌려 넣습니다. 저희 고객에는 DAX 상장 기업은 물론 핵심 인프라 운영자도 포함됩니다.

어떤 것들은 같은 컴퓨터에 있어서는 안 됩니다. 그리고 어떤 기업은 Game Over를 감당할 수 없습니다. 그렇다면 벽과 Extra Life를 갖추는 편이 낫습니다.