Managed Red Tenant

Red Tenant는 권한 있는 ID와 그 디바이스만을 위해 존재하는 전용 Microsoft Entra 테넌트이며, 프로덕션 테넌트는 자기 자신 안에서가 아니라 Red Tenant에서 관리됩니다.

이유는 단순합니다. 테넌트를 침해한 사람은 그 테넌트를 복구할 때 쓸 계정까지 자동으로 손에 넣습니다. 그 계정들이 다른 테넌트에 있으면 침해된 사용자에서 완전한 장악으로 이어지는 경로가 끊깁니다. 이름은 Active Directory를 위한 별도 관리 포리스트를 뜻하던 Microsoft의 옛 모델 Red Forest에서 따왔습니다.

Enterprise Access Model은 환경을 계층으로 나눕니다. Control Plane(Tier 0)에는 ID와 권한을 관리하는 모든 것이, Management Plane(Tier 1)에는 서버와 애플리케이션, 워크로드가, User Access Plane(Tier 2)에는 엔드포인트 디바이스와 사용자가 속합니다.

그 바탕에 있는 규칙은 상위 계층이 하위 계층에서 통제될 수 있어서는 안 된다는 것입니다. 그래서 Entra ID에서는 Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Intune Administrator 같은 역할과 Entra Connect, 그리고 이 시스템들을 패치하거나 백업하거나 모니터링하는 모든 것이 Tier 0에 속합니다.

Control Plane을 솔직하게 점검하는 일부터 시작하는 것이 가장 좋습니다. 지금 어떤 계정과 그룹, 서비스 계정, 애플리케이션이 ID나 권한을 변경할 수 있는지 확인하는 작업입니다. 대부분의 환경에서 그 수는 미리 생각했던 것보다 훨씬 많습니다.

그다음에는 계층별로 계정을 분리하고, 영구 할당을 PIM으로 대체하며, 로그인을 전용 디바이스로 제한합니다. 저희 무료 Tiering Check는 지금 어디에서 Tier 경계가 넘나들고 있는지 도표로 보여 주며, 저희가 아는 한 가장 빠른 출발점입니다.

둘 다 ID와 로그인 상황은 검증하지만, 키보드가 연결된 디바이스는 어느 쪽도 검증하지 않습니다.

강력한 인증이 성공하면 그 끝에는 단말에 남은 토큰이 있습니다. 그 디바이스가 침해되어 있으면 PIM과 Conditional Access가 거기까지 제 역할을 다했더라도 토큰이 탈취되거나 세션이 가로채입니다. Red Tenant는 이 둘을 모두 활용하면서, 디바이스 자체가 격리된 환경에서 나온 것이어야 한다는 조건을 추가합니다.

Privileged Access Workstation(PAW)은 관리 작업에만 쓰이는 하드닝된 워크스테이션입니다. 메일과 일반 웹 브라우징이 없고, Application Control이 적용되며, 로컬 관리자 권한이 없고, TPM과 Secure Boot로 신뢰 앵커를 확보합니다.

Control Plane에 접근하는 모든 역할에는 전용 하드웨어가 필요합니다. 그곳에는 깨끗한 키보드 원칙이 적용되기 때문입니다. 자격 증명은 목표 시스템보다 신뢰 수준이 낮은 디바이스에 절대 닿아서는 안 됩니다. Tier 1에는 가상 방식으로 충분합니다.

Control Plane 아래의 모든 영역에서는 가상 방식으로 충분합니다. 가상 Access Workstation(VAW)은 Red Tenant 안에서 Azure Virtual Desktop으로 실행되며, Compliant 상태의 오피스 디바이스에서 Entra Private Access를 통해 ID 전환과 FIDO2로 접근합니다.

하드웨어 없이 확장되고 Azure와 Microsoft 365, 온프레미스를 모두 커버하지만, 액세스가 Tier 2 디바이스를 거치기 때문에 잔여 위험은 남습니다. 그래서 Control Plane은 하드웨어 PAW의 몫으로 남겨 둡니다.

아닙니다. 다만 모든 관리자에게는 별도의 ID와 별도의 액세스 경로가 필요하며, 그것이 물리 PAW인지 가상 VAW인지는 그 사람이 일하는 계층이 결정합니다.

실제로는 소수만 Tier 0 권한을 가지고 하드웨어 PAW를 받으며, 대다수는 VAW로 일합니다. 이 모델이 관리자 5명부터 5,000명까지 확장되는 이유가 바로 여기에 있습니다.

차이는 신뢰 앵커에 있습니다. 계정과 정책, 디바이스 관리가 프로덕션 시스템과 같은 테넌트에 있는 PAW는 그 테넌트와 운명을 함께합니다. 테넌트를 장악한 사람은 PAW를 하드닝하는 Intune 정책까지 장악하기 때문입니다.

Red Tenant는 계정과 디바이스, 관리 기능을 프로덕션 테넌트에서 닿을 수 없는 전용 테넌트로 옮깁니다. PAW라는 구성 요소 자체는 그대로이고, 그것이 서 있는 토대만 달라집니다.

PAM 솔루션은 자격 증명을 보관하고 세션을 중개합니다. 즉 자격 증명은 지키지만 그것이 사용되는 디바이스는 지키지 못합니다. 엔드포인트가 침해되면 공격자는 중개된 세션에 그대로 올라타며, Microsoft 역시 PAM 솔루션만으로는 디바이스 위험을 확실히 막지 못한다고 명시하고 있습니다.

Red Tenant는 PAM을 대체하지 않고 보완합니다. PIM과 기존 볼트는 그대로 쓸 수 있고, 달라지는 것은 액세스가 이제 위험 구역 밖의 디바이스에서 온다는 점입니다.

여러분의 승인 없이 적용되는 것은 아무것도 없습니다. Red Tenant의 모든 변경은 코드로 파이프라인을 거치며 여러분 쪽 Customer Approver의 승인을 받아야 하고, 비상 액세스는 어느 한쪽도 단독으로 행동할 수 없도록 나뉘어 있습니다.

여기에 더해 저희는 여러분의 환경을 저희 자체 Red Tenant에서, 여러분에게 적용되는 것과 같은 규칙에 따라 관리합니다. 거부권은 언제나 고객에게 있습니다.

제21조 제2항은 액세스 통제 정책, 다단계 인증, 시스템의 취득과 개발, 유지보수 과정의 보안 등을 명시하고, 제20조는 경영진에게 이행을 감독하고 입증할 책임을 지웁니다.

독일에서는 2025년 12월부터 BSI법을 통해, 오스트리아에서는 2026년 10월 1일부터 NISG 2026을 통해 적용됩니다. BSI IT 기본보호는 관리 작업의 분리를 기본 요구사항으로, 관리 기능을 별도 구조로 분리하는 것을 상위 요구사항으로 규정합니다. Red Tenant는 바로 이것의 클라우드 구현이며, 버전 관리되는 리포지토리가 여러분의 증적입니다.

직접 운영하기에 복잡한 것은 사실인 경우가 많습니다. 비용이 드는 부분은 기술이 아니라 지속적인 하드닝과 유지보수, 모니터링, 증적 관리이고, 이것들은 곁다리로 처리할 수 있는 일이 아니기 때문입니다.

Managed Service가 존재하는 이유가 바로 이것입니다. 그 부담은 자동화와 반복으로 감당할 수 있게 만드는 저희 쪽에 있고, 관리자 20명을 위한 Red Tenant는 2,000명을 위한 것과 같은 코드입니다.

Microsoft가 ESAE를 철회한 이유는 그 모델이 온프레미스 관리자만 다루었고 운영이 지나치게 복잡했기 때문이지, 분리가 효과가 없어서가 아니었습니다.

같은 문서는 Microsoft가 내부적으로 여전히 비슷한 아키텍처를 운영하고 있다고 밝히고, 모든 관리 작업에 PAW를 권고하며, 특별히 보호가 필요한 리소스에 대해서는 여러 테넌트에 걸친 격리를 명시적으로 제시합니다. Red Tenant는 이 원칙의 클라우드 버전이고, ESAE가 좌초한 원인인 운영 부담은 Managed Service가 떠맡습니다.

Tiering은 누가 무엇을 할 수 있는지를, PIM은 언제 할 수 있는지를, Conditional Access는 어떤 조건에서 할 수 있는지를 정합니다. 다만 세 가지 모두 자신이 보호해야 할 환경 안에 있고, Global Admin 권한을 쥔 공격자도 함께 가지게 되는 역할이 이를 관리합니다.

Red Tenant는 관리 기능을 그 환경 밖으로 꺼냅니다. 기존 통제 장치는 그대로 유지되며, 안쪽에서는 더 이상 닿을 수 없는 신뢰 앵커를 얻게 됩니다.