Azure Lighthouse 보안 및 권한: 멀티 테넌트 클라우드 액세스를 안전하게 관리하는 방법

By Mirko Peters · 2026-10-21

Azure Lighthouse 보안의 작동 방식, 테넌트 전반에 최소 권한을 적용하는 방법, 고객이 클라우드를 완전히 통제하는 방식을 알아봅니다.

Automatically translated with AI from the original post. Read the English original

Azure Lighthouse 보안은 최소 권한 원칙, 논리적 리소스 프로젝션, 고객이 통제하는 엄격한 경계를 기반으로 합니다. 이를 통해 관리형 서비스 공급자는 관리자 암호를 보유하지 않고도 기본 제공 Azure 역할과 영구적인 감사 추적을 사용해 멀티 테넌트 클라우드 환경을 관리할 수 있습니다.

핵심 요약

• 고객은 정확한 범위와 기본 제공 역할을 정의하여 자신의 Azure 테넌트에 대한 절대적인 권한을 유지합니다.
• 등록 정의와 등록 할당은 Azure가 모든 작업마다 확인하는 지속적인 핸드셰이크 역할을 합니다.
• Azure Lighthouse 위임에서는 전체 Owner 역할과 데이터 영역 액세스가 전혀 지원되지 않습니다.
• 공급자는 사용자 암호나 자격 증명을 공유하지 않고 자신의 포털에서 논리적 프로젝션을 통해 작업합니다.
• 활동 로그는 고객 테넌트의 모든 변경 사항을 기록하여 투명한 감사 추적을 제공합니다.

Azure Lighthouse의 보안 아키텍처

여러 클라우드 환경을 관리하려면 전통적으로 모든 고객 테넌트 안에 별도의 관리자 계정을 만들어야 했습니다. 이 방식은 큰 보안 위험, 임시 암호가 가득한 스프레드시트, 외부 시스템에 남아 있는 잊힌 자격 증명을 초래했습니다. Azure Lighthouse는 분리된 클라우드 환경 사이에 암호학적으로 결합된 안전한 통로를 만들어 이러한 방식을 근본적으로 바꿉니다.

Lighthouse는 테넌트를 병합하거나 자격 증명을 공유하는 대신 논리적 프로젝션을 사용합니다. 고객의 리소스는 테넌트, 구독, 리소스 그룹을 포함해 고객의 클라우드 환경 안에 그대로 남아 있습니다. 관리형 서비스 공급자는 자신의 관리 테넌트에 있는 안전한 통로를 통해 이러한 리소스를 봅니다. 공급자가 보내는 모든 요청은 Azure의 핵심 검증 계층을 거치며, 이 계층은 명령 실행을 허용하기 전에 승인 문서를 지속적으로 확인합니다.

두 부분으로 구성된 핸드셰이크

Azure Lighthouse의 보안은 맹목적인 신뢰가 아니라, 고객의 최상위 관리자가 직접 배포하는 변경 불가능한 두 개의 JSON 기반 구성 파일에 기반합니다.

첫 번째 구성 요소는 등록 정의입니다. 이 문서는 고객의 계정 안에 있으며, 신뢰하는 외부 조직이 누구인지와 해당 조직에 부여되는 특정 기본 제공 역할을 명시적으로 정의합니다. 두 번째 구성 요소는 등록 할당으로, 등록 정의를 특정 구독 또는 리소스 그룹에 연결하는 주소 역할을 합니다.

이 구성 요소는 고객의 테넌트에 존재하므로 고객이 전적으로 통제합니다. 계약이 종료되면 고객은 서비스 공급자의 협조 없이도 등록 할당을 삭제하여 즉시 액세스를 차단할 수 있습니다.

멀티 테넌트 환경에서 최소 권한 적용

최신 클라우드 보안의 핵심 원칙은 최소 권한 원칙입니다. 사용자와 시스템에 작업 수행에 필요한 최소한의 권한만 부여하는 원칙으로, Azure Lighthouse는 개별 사용자가 아닌 보안 그룹, 서비스 주체, 자동화 계정에 권한을 매핑하여 이 원칙을 손쉽게 적용할 수 있도록 합니다.

예를 들어 관리형 서비스 공급자(MSP)는 팀의 액세스를 다음과 같이 여러 계층으로 나눌 수 있습니다.

• 지원 팀: 변경 없이 가상 머신 상태와 진단 로그를 확인할 수 있도록 판독기 역할이 할당됩니다.
• 마이그레이션 엔지니어: 특정 리소스 그룹에 대해 기여자 역할이 할당되어 워크로드를 배포하고 업데이트를 적용합니다.
• 자동화 스크립트: 야간 백업과 원격 분석 수집을 실행하도록 범위가 지정된 사용자 지정 서비스 계정이 할당됩니다.

이처럼 세분화된 방식을 사용하면 공급자 측의 실수나 자격 증명 유출이 발생하더라도 관리 대상인 모든 고객 환경으로 피해가 번지는 상황을 막을 수 있습니다.

보안 가드레일로서의 기본 제공 역할 제한

조직이 과도한 권한 부여로부터 보호받을 수 있도록 Azure Lighthouse는 위임 가능한 범위에 대해 엄격한 가드레일을 적용합니다. 특히 최상위 소유자 역할은 Lighthouse 위임에서 전혀 지원되지 않습니다. 서비스 공급자는 다른 사용자에게 권한을 할당하거나 고객 구독의 최종 소유권을 가질 수 있는 권한을 결코 부여받을 수 없습니다.

또한 Azure Blob Storage 컨테이너의 파일 읽기나 데이터베이스 레코드 조회처럼 데이터 영역에 대한 액세스를 부여하는 역할은 Lighthouse를 통해 위임할 수 없습니다. Lighthouse는 인프라 제어 영역을 관리하며, 관리 감독이 데이터 개인정보 침해의 영역을 넘지 않도록 보장합니다.

감사 추적 및 규정 준수 추적

규정 준수 담당자는 외부 공급업체가 핵심 엔터프라이즈 클라우드 인프라에 액세스한다는 생각만으로도 우려하는 경우가 많습니다. Azure Lighthouse는 고객 측 경계 안에서 꼼꼼하고 변조 방지된 기록을 남겨 이러한 우려를 덜어 줍니다.

공급자 사용자가 수행하는 모든 작업, 즉 가상 머신 재부팅, 방화벽 규칙 수정, 네트워크 설정 업데이트 등은 고객의 Azure 활동 로그에 직접 기록됩니다. 이 로그는 고객의 테넌트에 저장되므로 외부 공급자가 변경하거나 삭제할 수 없습니다. IT 관리자는 정기적인 감사를 실행하여 다음과 같은 중요한 보안 질문에 답할 수 있습니다. 누가 이 리소스에 접근했는가? 언제 수정되었는가? 정확히 어떤 명령이 실행되었는가?

또한 기업은 Azure Lighthouse와 Privileged Identity Management(PIM)를 함께 사용하여 필요한 순간에만 권한을 상승시키도록 요구할 수 있습니다. 공급자 엔지니어는 상시 기여자 권한을 보유하는 대신 사고가 발생했을 때만 액세스를 요청할 수 있으며, 승인 내역은 기록되고 제한 시간은 자동으로 적용됩니다.

결론

Azure Lighthouse는 강력한 클라우드 보안과 효율적인 다중 테넌트 관리 사이에서 오랫동안 이어져 온 긴장 관계를 해결합니다. 암호 공유를 암호학적으로 검증되고 고객이 통제하는 위임 리소스 관리로 대체함으로써, IT 리더는 보안 태세를 훼손하지 않고 운영 규모를 확장할 수 있습니다. 이 아키텍처의 기본 개념을 살펴보려면 M365 FM Podcast의 전체 에피소드 듣기를 통해 현대 클라우드 관리를 전문 용어 없이 쉽게 정리한 내용을 확인해 보시기 바랍니다.

자주 묻는 질문

Azure Lighthouse 공급자가 우리 조직의 암호를 볼 수 있습니까?

아닙니다. Azure Lighthouse는 테넌트 간에 암호나 사용자 자격 증명을 노출, 전송 또는 공유하지 않습니다. 공급자는 자체 엔터프라이즈 ID 시스템을 사용하여 인증하며, 논리적 프로젝션을 통해 고객의 리소스에서 작업합니다.

공급자가 침해당하면 Azure Lighthouse 액세스에는 어떤 일이 일어납니까?

액세스는 등록 할당에 정의된 특정 기본 제공 역할과 리소스로만 엄격하게 범위가 지정되며 소유자 역할은 제외되므로, 피해 범위가 철저히 제한됩니다. 또한 고객은 자신의 포털에서 등록 할당을 삭제하여 액세스를 즉시 취소할 수 있습니다.

Azure Lighthouse는 사용자 지정 RBAC 역할을 지원합니까?

아닙니다. Azure Lighthouse는 Microsoft에서 제공하는 기본 제공 Azure 역할만 지원합니다. 공급자 또는 고객 테넌트에서 만든 사용자 지정 역할은 등록 정의에서 사용할 수 없습니다.

고객 테넌트에서 Azure Lighthouse를 설정할 권한은 누구에게 있습니까?

구독 또는 리소스 그룹 수준에서 역할을 할당할 수 있는 권한, 예를 들어 User Access Administrator 또는 Owner 권한을 가진 고권한 계정만 등록 템플릿을 배포하고 연결을 설정할 수 있습니다.