다음을 통해 공유


랜딩 존 ID 및 액세스 관리

ID 아키텍처를 식별한 후에는 애플리케이션 및 플랫폼 랜딩 존에서 리소스에 대한 권한 부여 및 액세스를 관리해야 합니다. 인증된 각 보안 주체가 액세스하고 액세스해야 하는 리소스와 리소스에 대한 무단 액세스 위험을 완화하는 방법을 고려합니다. 자세한 내용은 ID 아키텍처 디자인을 참조하세요.

개요

ID 및 액세스 관리 디자인 영역은 Azure에서 엔터프라이즈 액세스 모델을 구현하고 제어 평면을 구현하고 보호하는 데 도움이 되는 지침을 제공합니다. 구독 민주화디자인 원칙을 통합하면 애플리케이션 팀은 플랫폼 팀이 설정하는 정책 보호책 내에서 자신의 워크로드를 관리할 수 있습니다. 또한 이 방법은 정책 기반 거버넌스 원칙을 따릅니다.

플랫폼 팀은 새 애플리케이션 랜딩 존 또는 구독을 프로비전할 책임이 있습니다. 애플리케이션 소유자에 대한 랜딩 존을 프로비전할 때 플랫폼 팀은 애플리케이션 소유자가 자체 리소스를 관리할 수 있도록 적절한 액세스 제어를 사용하여 구성해야 합니다. 애플리케이션 소유자는 Microsoft Entra ID 내에서 사용자 및 그룹을 만들고 관리하고 해당 사용자 및 그룹에 역할을 할당할 수 있어야 합니다. 그런 다음 애플리케이션 소유자는 자신의 리소스에 대한 액세스를 관리하고 필요에 따라 다른 사용자 및 그룹에 대한 액세스를 위임할 수 있습니다. 또한 랜딩 존은 애플리케이션의 요구 사항에 따라 Microsoft ID 플랫폼 구독에서 AD DS(Active Directory 도메인 Services) 또는 Microsoft Entra Domain Services에 대한 선택적 네트워크 연결이 있어야 합니다.

Azure RBAC(역할 기반 액세스 제어)를 사용하여 Azure 리소스에 대한 관리 액세스를 관리합니다. 사용자에게 단일 애플리케이션의 관리자와 같은 좁은 범위에 대한 권한이 필요한지, 여러 애플리케이션 워크로드에서 네트워크 관리자와 같은 광범위한 범위가 필요한지 고려합니다. 두 경우 모두 충분한 액세스 원칙을 따르고 사용자에게 정상적인 활동에 필요한 역할만 있는지 확인합니다. JIT(Just-In-Time) 액세스를 적용하는 데 필요한 경우 사용자 지정 역할 및 Microsoft Entra PIM(Privileged Identity Management)을 사용합니다. 플랫폼 팀은 ID 및 액세스 관리 기반을 담당하지만 플랫폼 및 애플리케이션 팀은 모두 서비스의 소비자이며 동일한 원칙을 따라야 합니다.

ID 및 액세스 관리는 한 랜딩 존을 다른 랜딩 존과 성공적으로 분리하고 조직 내에서 워크로드를 격리하는 데 중요합니다. 플랫폼 및 애플리케이션 랜딩 존 모두에 중요한 디자인 영역입니다.

조직에서 구독 자동 판매 프로세스를 사용하는 경우 애플리케이션 방문 영역에 대한 많은 ID 및 액세스 구성을 자동화할 수 있습니다. 랜딩 존 만들기를 표준화하여 애플리케이션 팀이 자체 리소스를 관리할 수 있도록 구독 자동 판매 구현합니다.

디자인 고려 사항

일부 조직에서는 여러 애플리케이션 간에 서비스를 공유합니다. 예를 들어 여러 독립 애플리케이션에서 사용하는 중앙 집중식 통합 서비스가 있을 수 있습니다. 이 시나리오에서는 중앙에서 관리되는 서비스와 애플리케이션 팀으로 전환되는 서비스를 고려하고 보안 경계를 적용해야 하는 위치를 이해합니다. 애플리케이션 팀에게 공유 서비스에 대한 관리 액세스 권한을 부여하면 개발자 생산성에 도움이 될 수 있지만 필요한 것보다 더 많은 액세스 권한을 제공할 수 있습니다.

보안 경계를 넘지 않는 애플리케이션 리소스를 애플리케이션 팀에 위임할 수 있습니다. 보안 및 규정 준수를 유지하는 데 필요한 다른 측면도 위임하는 것이 좋습니다. 사용자가 안전하게 관리되는 환경 내에서 리소스를 프로비전할 수 있도록 하면 조직은 중요한 보안 또는 거버넌스 경계 위반을 방지하면서 클라우드의 Agile 특성을 활용할 수 있습니다.

RBAC

Important

클래식 리소스 및 클래식 관리자는 2024년 8월 31일에 사용 중지됩니다. 불필요한 공동 관리자를 제거하고 세분화된 액세스 제어를 위해 Azure RBAC를 사용합니다.

Microsoft Entra ID 역할과 Azure RBAC 역할 간의 차이점을 이해합니다.

  • Microsoft Entra ID 역할은 Microsoft Entra ID와 같은 테넌트 전체 서비스 및 Microsoft Teams, Microsoft Exchange Online 및 Microsoft Intune을 포함한 기타 Microsoft 서비스 대한 관리 권한을 제어합니다.

  • Azure RBAC 역할은 가상 머신, 구독 및 리소스 그룹과 같은 Azure 리소스에 대한 관리 권한을 제어합니다.

  • Azure RBAC 소유자 및 사용자 액세스 관리자 역할은 Azure 리소스에 대한 역할 할당을 수정할 수 있습니다. 기본적으로 Microsoft Entra 전역 관리자 역할에는 Azure 리소스에 대한 액세스를 관리할 수 있는 권한이 없습니다. 명시적으로 사용하도록 설정해야 합니다. 자세한 내용은 모든 Azure 구독 및 관리 그룹을 관리할 수 있도록 액세스 권한 상승을 참조하세요.

Important

가장 적은 권한으로 역할을 사용하는 것이 좋습니다. 이렇게 하면 조직의 보안을 개선하는 데 도움이 됩니다. 전역 관리자는 기존 역할을 사용할 수 없는 경우 긴급 시나리오로 제한해야 하는 높은 권한의 역할입니다.

다음 다이어그램은 Microsoft Entra ID 역할과 Azure RBAC 역할 간의 관계를 보여 줍니다.

Microsoft Entra ID와 Azure RBAC 역할 간의 관계를 보여 주는 다이어그램

  • 속성을 으로 설정하는 isAssignableToRole 경우 역할 할당 가능 그룹을 만들고 그룹에 Microsoft Entra 역할을 할당할 true수 있습니다. 이 속성이 설정된 그룹만 보호됩니다. 그룹의 멤버 자격을 수정할 수 있는 유일한 역할은 전역 관리자, 권한 있는 역할 관리자 또는 그룹의 소유자입니다.

  • 일부 역할만 다른 관리자에 대한 암호 또는 MFA(다단계 인증) 설정을 다시 설정할 수 있습니다. 이 제한은 권한이 없는 관리자가 더 많은 권한을 얻기 위해 더 높은 권한의 계정의 자격 증명을 다시 설정하지 못하도록 합니다.

  • Azure 기본 제공 역할이 조직의 특정 요구 사항을 충족하지 않는 경우 사용자 지정 역할을 만들면 됩니다. 기본 제공 역할과 마찬가지로 테넌트, 관리 그룹, 구독 및 리소스 그룹 범위에서 사용자, 그룹 및 서비스 주체에 사용자 지정 역할을 할당할 수 있습니다. 가능한 경우 Azure 기본 제공 역할을 사용하고 필요한 경우에만 사용자 지정 역할을 만드는 것을 목표로 합니다.

  • 액세스 제어 전략을 설계할 때 역할, 역할 할당 및 사용자 지정 역할에 대한 서비스 제한을 알고 있습니다.

  • 일부 Azure RBAC 역할은 ABAC(특성 기반 액세스 제어) 또는 역할 할당 조건을 지원합니다. 조건을 사용하는 경우 관리자는 리소스의 특성에 따라 역할을 동적으로 할당할 수 있습니다. 예를 들어 스토리지 Blob 데이터 기여자 역할을 할당할 수 있지만 컨테이너의 모든 Blob이 아닌 특정 인덱스 태그가 있는 Blob에만 할당할 수 있습니다.

  • 기본 제공 및 사용자 지정 RBAC 역할 Microsoft.Authorization/roleAssignments/write 또는 Microsoft.Authorization/roleAssignments/delete 사용 권한을 사용하여 역할 할당을 만들고 삭제하고 업데이트할 수 있습니다. 이 역할이 있는 모든 사용자는 할당 범위의 모든 리소스에 대한 쓰기, 읽기 및 삭제 권한이 있는 사용자를 결정할 수 있습니다. 플랫폼 또는 애플리케이션 랜딩 존 팀 구성원은 권한 있는 역할을 다른 사용자 및 그룹에 위임하여 필요한 자율성을 부여하는 방법을 고려해야 합니다. 최소 권한 액세스 원칙을 준수하기 위해 조건을 사용하여 사용자를 위임할 수 있습니다.

디자인 권장 사항

일반 권장 사항

  • 플랫폼 구독, 애플리케이션 구독 및 Microsoft Entra ID 테넌트 등 Azure 환경에 대한 권한이 있는 사용자에 대해 Microsoft Entra MFA(다단계 인증)를 적용합니다. 많은 규정 준수 프레임워크에는 MFA 적용이 필요합니다. MFA는 자격 증명 도난 및 무단 액세스의 위험을 줄이는 데 도움이 됩니다. 중요한 정보에 대한 무단 액세스를 방지하려면 MFA 정책에 읽기 권한자 역할이 있는 사용자를 포함해야 합니다.

  • Azure 환경에 대한 권한이 있는 사용자에 대해 Microsoft Entra 조건부 액세스 정책을 사용합니다. 조건부 액세스는 제어된 Azure 환경을 무단 액세스로부터 보호하는 데 도움이 되는 또 다른 기능입니다. 애플리케이션 및 플랫폼 관리자는 역할의 위험 프로필을 반영하는 조건부 액세스 정책이 있어야 합니다. 예를 들어 특정 위치 또는 특정 워크스테이션에서만 관리 작업을 수행해야 하는 요구 사항이 있을 수 있습니다. 또는 Azure 리소스에 대한 관리 액세스 권한이 있는 사용자의 로그인 위험 허용 범위가 표준 Microsoft Entra ID 사용자보다 낮을 수 있습니다.

  • Microsoft Defender for Identity를 사용하도록 설정하여 사용자 ID를 보호하고 사용자 자격 증명을 보호합니다. Defender for Identity는 Microsoft Defender XDR의 일부입니다. Defender for Identity를 사용하여 의심스러운 사용자 활동을 식별하고 인시던트 타임라인을 가져올 수 있습니다. 조건부 액세스와 함께 사용하여 고위험 인증 시도를 거부할 수도 있습니다. Azure ID 구독의 온-프레미스 도메인 컨트롤러 및 도메인 컨트롤러에 Defender for Identity 센서를 배포합니다.

  • Microsoft Sentinel을 사용하여 위협 인텔리전스 및 조사 기능을 제공합니다. Sentinel은 Azure Monitor 로그, Microsoft Entra ID, Microsoft 365 및 기타 서비스의 로그를 사용하여 사전 위협 탐지, 조사 및 대응을 제공합니다.

  • 웹 검색 및 전자 메일 액세스와 같은 수정되지 않는 일상적인 액세스와 관리 액세스를 구분합니다. 웹 및 전자 메일은 일반적인 공격 벡터입니다. 사용자 계정이 손상되면 계정이 관리 액세스에 사용되지 않는 경우 보안 위반이 발생할 가능성이 적습니다.

    • 권한 있는 역할에 대해 별도의 클라우드 전용 계정을 사용합니다. 권한 있는 관리에 대해 수행하는 것과 동일한 계정을 매일 사용하지 마세요. 권한 있는 Microsoft Entra ID 및 Azure RBAC 역할은 Azure Portal 및 설명서에서 PRIVILEGED표시됩니다.

    • Azure 애플리케이션 리소스를 관리할 수 있는 권한이 없는 작업 함수 역할의 경우 별도의 관리 계정이 필요한지 아니면 Microsoft Entra PIM을 사용하여 관리 액세스를 제어할지를 고려합니다. PIM은 필요한 경우에만 계정에 필요한 권한이 있고 작업이 완료될 때 권한이 제거되도록 합니다(Just-In-Time 액세스라고도 함).

  • 역할 할당을 보다 관리하기 쉽게 만들려면 사용자에게 직접 역할을 할당하지 마세요. 대신 그룹에 역할을 할당하여 각 구독에 제한이 있는 역할 할당 수를 최소화합니다.

    • 그룹에 Microsoft Entra PIM을 사용하여 권한 있는 사용자에게 Just-In-Time 관리 액세스 제어를 적용합니다. 권한 관리를 사용하여 그룹 멤버 자격을 제어하는 것이 좋습니다. 권한 관리 기능을 사용하여 그룹 멤버 자격 작업에 승인 및 감사 워크플로를 추가하고 관리 그룹 구성원이 불필요하게 추가되거나 제거되지 않도록 할 수 있습니다.

    • 리소스에 대한 액세스 권한을 부여하는 경우 Azure 컨트롤 플레인 리소스에 대해 Microsoft Entra 전용 그룹을 사용합니다. Entra 전용 사용자 및 그룹 및 Microsoft Entra Connect를 사용하여 온-프레미스에서 동기화된 사용자를 Entra 전용 그룹에 추가할 수 있습니다. 그룹 관리 시스템이 이미 있는 경우 온-프레미스 그룹을 Microsoft Entra 전용 그룹에 추가합니다. Entra 전용 그룹을 사용하면 온-프레미스 디렉터리 서비스의 무단 수정으로부터 클라우드 제어 평면을 보호할 수 있습니다. Microsoft Entra 전용을 클라우드로만 알려져 있습니다.

  • Microsoft Entra ID 조직에서 실수로 잠기지 않도록 비상 액세스 계정 또는 비상 계정을 만듭니다. 응급 액세스 계정은 높은 권한이 있으며 특정 개인에게만 할당됩니다. 계정에 대한 자격 증명을 안전하게 저장하고, 사용을 모니터링하고, 정기적으로 테스트하여 재해가 발생하는 경우 사용할 수 있는지 확인합니다.

    자세한 내용은 Microsoft Entra ID의 관리자에 대한 보안 액세스 방법을 참조하세요.

Microsoft Entra ID 권장 사항

  • 로그인 활동 및 테넌트 내 변경 내용의 감사 내역을 분석할 수 있도록 Microsoft Entra ID를 Azure Monitor 와 통합합니다. 관리 구독의 플랫폼 중앙 Azure Monitor 로그 작업 영역에 로그인 로그 및 감사 로그를 보내도록 진단 설정을 구성합니다.

  • Microsoft Entra ID 거버넌스의 권한 관리 기능을 사용하여 자동 승인 프로세스 및 권한 있는 그룹 구성원에 대한 정기적인 액세스 검토를 통해 그룹 멤버 자격을 제어하는 액세스 패키지를 만듭니다.

  • Microsoft Entra 기본 제공 역할을 사용하여 테넌트 수준에서 다음 ID 설정을 관리합니다.

    역할 설명 참고 항목
    전역 관리자 Microsoft Entra ID 및 Microsoft Entra ID를 사용하는 Microsoft 서비스 모든 측면을 관리합니다. 이 역할에 5명 넘게 할당하지 마세요.
    하이브리드 ID 관리자 Active Directory에서 Microsoft Entra ID로 클라우드 프로비저닝을 관리하고 Microsoft Entra Connect, Microsoft Entra 통과 인증, Microsoft Entra 암호 해시 동기화, Microsoft Entra Seamless SSO(Single Sign-On) 및 페더레이션 설정을 관리합니다.
    보안 관리자 보안 정보 및 보고서를 읽고 Microsoft Entra ID 및 Microsoft 365에서 구성을 관리합니다.
    애플리케이션 관리자 앱 등록 및 엔터프라이즈 앱의 모든 측면을 만들고 관리합니다. 테넌트 전체의 관리 동의를 부여할 수 없습니다.
  • 권한이 낮은 역할이 수행할 수 있는 작업에 더 높은 권한의 역할을 할당하지 마세요. 예를 들어 전역 관리자 역할이 아닌 사용자를 관리하도록 사용자 관리자 역할을 할당합니다. 자세한 내용은 Microsoft Entra 기본 제공 역할 권한을 참조 하세요.

  • 관리 단위를 사용하여 테넌트에서 특정 개체만 관리할 수 있도록 관리자 집합을 제한합니다. 관리 단위를 사용하여 디렉터리의 하위 집합 관리를 위임할 수 있습니다. 예를 들어 서비스 데스크 관리를 더 넓은 조직 내의 단일 사업부에 위임할 수 있습니다.

    관리 단위는 별도의 팀이 동일한 조직에서 Microsoft 365 플랫폼 및 Azure 플랫폼을 관리하는 보안 경계로서 별도의 Microsoft Entra ID 테넌트가 필요하지 않도록 하는 데 도움이 될 수 있습니다. 예를 들어 관리 단위를 사용하여 전체 Microsoft Entra ID 테넌트에 대한 권한을 부여하지 않고 Azure 애플리케이션 보안 주체의 관리를 애플리케이션 팀에 위임할 수 있습니다.

  • 제한된 관리 관리 단위를 사용하여 추가 보호를 제공합니다. 지정한 특정 관리자 집합이 아닌 다른 사용자가 특정 개체를 수정하지 못하도록 합니다. 예를 들어 의무 정책을 분리하려면 이 기능을 사용하여 사용자 관리자 역할이 있는 사용자도 특정 사용자 계정을 수정하지 못하도록 해야 할 수 있습니다. 이 제한은 애플리케이션이 사용하고 관리자도 수정해서는 안 되는 서비스 계정에 유용합니다. 권한 상승(예: 플랫폼 또는 랜딩 존 관리 권한이 있는 사용자 계정 또는 그룹을 수정하는 경우)을 방지할 수도 있습니다.

Azure RBAC 권장 사항

  • 관리를 간소화하고 잘못된 구성의 위험을 줄이려면 모든 애플리케이션 랜딩 존에서 역할 및 역할 할당을 표준화합니다. 예를 들어 가상 머신을 관리하도록 사용자를 위임하는 역할이 있는 경우 모든 애플리케이션 랜딩 존에서 동일한 역할을 사용합니다. 또한 이 방법은 랜딩 존 간에 리소스를 이동하는 프로세스를 간소화합니다.

  • 가능한 경우 Azure RBAC를 사용하여 리소스에 대한 데이터 평면 액세스를 관리합니다. 데이터 평면 엔드포인트의 예로는 Azure Key Vault, 스토리지 계정 또는 SQL 데이터베이스가 있습니다.

  • Azure Monitor 로그 작업 영역이 적절한 권한 모델로 구성되었는지 확인합니다. 중앙 집중식 Azure Monitor 로그 작업 영역을 사용하는 경우 리소스 권한을 사용하여 애플리케이션 팀이 자신의 로그에 액세스할 수 있지만 다른 팀의 로그에는 액세스할 수 없도록 합니다.

기본 제공 역할
  • 기본 제공 역할이 요구 사항에 적합한지 여부를 고려합니다. 대부분의 경우 보안 그룹에 여러 기본 제공 역할을 할당하여 사용자에게 적절한 액세스를 제공할 수 있습니다. 그러나 역할에 사용자에게 필요한 권한을 초과하는 권한이 포함될 수 있으므로 기본 제공 역할을 사용할 수 없고 최소 권한 액세스도 준수할 수 없는 경우도 있습니다. 보다 세부적인 제어를 위해 작업 함수를 수행하는 데 필요한 특정 권한을 반영하는 사용자 지정 역할을 만드는 것이 좋습니다. 자세한 내용은 역할 기반 권한 부여 제공을 참조하세요.

  • 많은 Azure 기본 제공 역할은 플랫폼 및 리소스 수준에서 미리 정의된 역할 할당을 제공합니다. 여러 역할 할당을 결합하는 경우 전반적인 효과를 고려합니다.

  • Azure 랜딩 존 가속기는 일반적인 관리 기능에 대한 몇 가지 사용자 지정 역할을 포함합니다. Azure 기본 제공 역할과 함께 이러한 역할을 사용할 수 있습니다. 다음 표에서는 Azure 랜딩 존 가속기에서 사용자 지정 관리 역할 또는 영역을 설명합니다.

    관리 역할 또는 영역 설명 actions NotActions
    Azure 플랫폼 소유자(예: 기본 제공 소유자 역할) 관리 그룹 및 구독 수명 주기 관리 *
    구독 소유자 구독 소유자에 대한 위임된 역할 * Microsoft.Authorization/*/write, , Microsoft.Network/vpnGateways/*
    Microsoft.Network/expressRouteCircuits/*,
    Microsoft.Network/routeTables/write,
    Microsoft.Network/vpnSites/*
    애플리케이션 소유자(DevOps, 앱 작업) 구독 범위의 애플리케이션 또는 운영 팀에 대한 기여자 역할 * Microsoft.Authorization/*/write, , Microsoft.Network/publicIPAddresses/write
    Microsoft.Network/virtualNetworks/write,
    Microsoft.KeyVault/locations/deletedVaults/purge/action
    네트워크 관리(NetOps) 가상 네트워크, UDR, NSG, NVA, VPN, Azure ExpressRoute 등과 같은 플랫폼 전체 글로벌 연결을 관리합니다. */read,
    Microsoft.Network/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Support/*
    SecOps(보안 운영) 전체 Azure 자산 및 Key Vault 제거 정책에서 가로 보기가 있는 보안 관리자 역할 */read,
    */register/action,
    Microsoft.KeyVault/locations/deletedVaults/purge/action,
    Microsoft.PolicyInsights/*,
    Microsoft.Authorization/policyAssignments/*,
    Microsoft.Authorization/policyDefinitions/*,
    Microsoft.Authorization/policyExemptions/*,
    Microsoft.Authorization/policySetDefinitions/*,
    Microsoft.Insights/alertRules/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Security/*,
    Microsoft.Support/*

    해당 역할은 책임 모델에 따라 더 많은 권한이 필요할 수 있습니다. 예를 들어, 일부 조직에서 NetOps 역할은 전역 연결을 관리하고 구성하기만 하면 됩니다. 보다 중앙 집중화된 접근 방식이 필요한 조직에서는 허브와 해당 스포크 간에 피어링을 만드는 등 더 허용된 작업으로 NetOps 역할을 보강할 수 있습니다.

역할 할당 및 그룹
  • 플랫폼 팀이 애플리케이션 랜딩 존을 프로비전할 때 보안 그룹, 표준 역할 할당 및 사용자 할당 관리 ID와 같은 모든 필수 ID 및 액세스 관리 개체가 생성되도록 해야 합니다.

  • 구독 또는 리소스 그룹 범위에서 랜딩 존 역할 할당을 만듭니다. Azure Policy 할당은 관리 그룹 범위에서 수행되므로 하위 범위에서 랜딩 존 역할 할당을 프로비전해야 합니다. 이 방법을 사용하여 랜딩 존 관리자가 리소스에 대한 완전한 자율성을 가지지만 랜딩 존을 제어하는 Azure Policy 할당을 수정할 수 없도록 합니다.

  • 각 애플리케이션 랜딩 존에는 고유한 그룹 및 역할 할당이 있어야 합니다. 제네릭 그룹을 만들고 여러 랜딩 존에 할당하지 마세요. 이 접근 방식은 잘못된 구성 및 보안 위반으로 이어질 수 있으며 대규모로 관리하기가 어렵습니다. 한 사용자가 여러 랜딩 존에 액세스해야 하는 경우 각 랜딩 존의 적절한 그룹에 할당합니다. ID 거버넌스를 사용하여 그룹 멤버 자격을 관리합니다.

  • 사용자가 아닌 그룹에 역할을 할당합니다. 이 방법은 사용자가 조직에 가입하거나 조직을 떠날 때 올바른 권한을 갖도록 하는 데 도움이 됩니다. 또한 사용자가 팀 간에 이동할 때 올바른 사용 권한을 갖도록 하는 데 도움이 됩니다. 예를 들어 사용자가 네트워크 팀에서 보안 팀으로 이동하는 경우 네트워크 그룹에서 제거한 후 보안 그룹에 추가해야 합니다. 사용자에게 직접 역할을 할당하는 경우 다른 팀으로 이동한 후 역할을 유지합니다. ID 거버넌스를 사용하여 그룹 구성원을 수동으로 추가하고 제거하는 대신 그룹 멤버 자격을 관리합니다.

  • 개발/테스트 및 프로덕션과 같이 동일한 애플리케이션의 다양한 환경에 대해 별도의 보안 구성을 유지 관리합니다. 각 환경에 대해 별도의 그룹 및 역할 할당을 만듭니다. 환경 간에 관리 ID 또는 서비스 주체를 공유하지 마세요. 각 환경을 별도의 랜딩 존으로 처리합니다. 이 방법은 개발/테스트와 프로덕션 간의 격리를 보장하고 환경 간에 애플리케이션 배포를 이동하는 프로세스를 표준화하는 데 도움이 됩니다. 동일한 개인이 여러 랜딩 존에 액세스해야 하는 경우 각 랜딩 존의 적절한 그룹에 할당해야 합니다.

  • 플랫폼 관리자가 애플리케이션 랜딩 존에 대한 권한이 필요한지 여부를 고려합니다. 그렇다면 Microsoft Entra PIM을 사용하여 해당 리소스에 대한 액세스를 제어하고 필요한 최소 권한 권한을 할당합니다. 예를 들어 플랫폼 관리자는 문제를 해결하기 위해 특정 애플리케이션 랜딩 존에 액세스해야 하지만 애플리케이션 데이터 또는 코드에 대한 일상적인 액세스 권한이 없어야 합니다. 이 경우 플랫폼 관리자는 애플리케이션에 대한 액세스를 요청할 수 있습니다. 권한 있는 역할 관리자가 요청을 승인하고 플랫폼 관리자에게 지정된 기간 동안 필요한 권한이 부여됩니다. 이 방법은 업무 분리를 적용하고 우발적이거나 악의적인 잘못된 구성으로부터 애플리케이션 랜딩 존을 보호하는 데 도움이 됩니다.

  • 애플리케이션 팀과 같은 다른 사람에게 관리 책임을 위임하는 경우 전체 권한 집합이 필요한지 아니면 하위 집합만 필요한지 고려합니다. 최소 권한 원칙(PoLP)을 따릅니다. 예를 들어 Azure 리소스에 대한 액세스를 관리해야 하지만 리소스 자체를 관리할 필요가 없는 사용자에게 사용자 액세스 관리자 역할 또는 RBAC 관리자 역할을 할당할 수 있습니다. 사용자가 Azure RBAC 할당을 위임하고 할당할 수 있는 ID, ID 유형 및 역할을 제한하려면 조건과 함께 위임된 역할 할당을 사용합니다. 애플리케이션 팀은 조건을 사용하여 플랫폼 팀이 설정하는 제약 조건 내에서 자체 보안 주체를 관리할 수 있습니다. 권한 있는 역할 할당이 많을수록 플랫폼 팀에 대한 에스컬레이션이 필요합니다. 조건을 사용하여 RBAC 역할을 위임하는 경우 다음 요소를 고려합니다.

    • 기본 제공 및 사용자 지정 권한 있는 역할에 대한 현재 역할 할당을 검토하고 기존 할당에 적절한 조건을 추가해야 하는지 평가합니다. 예를 들어 Azure 랜딩 존 가속기가 제공하는 구독 소유자 및 애플리케이션 소유자 사용자 지정 역할에 조건을 추가할 수 있습니다. 이러한 조건은 역할을 할당할 수 있는 주체 유형을 제한하거나 할당할 수 있는 특정 역할을 제한할 수 있습니다.

    • 역할 할당에 조건을 추가할 때 PoLP를 따릅니다. 예를 들어 대리자가 그룹에만 역할을 할당하도록 제한하거나 대리인이 소유자, 사용자 액세스 관리자 및 RBAC 관리자와 같은 권한 있는 관리자 역할을 제외한 모든 역할을 할당할 수 있도록 제한합니다.

    • 사용 가능한 조건 템플릿이 요구 사항 또는 정책을 충족하지 않는 경우 사용자 고유의 조건을 빌드합니다.

      RBAC 제한 위임에 대한 조건 템플릿을 보여 주는 스크린샷

    • Azure 액세스 관리를 다른 사람에게 위임하는 알려진 제한 사항을 검토합니다.

  • 다음 표에서는 Azure 랜딩 존 환경에 대한 역할 할당 구조 예제를 보여 줍니다. 보안과 관리 용이성 간의 균형을 제공합니다. 조직의 요구 사항에 맞게 구조를 조정할 수 있습니다. 조직 내의 역할에 따라 동일한 개인을 여러 그룹에 할당할 수 있습니다. 그러나 특정 랜딩 존 내의 특정 그룹에 RBAC 할당을 적용해야 합니다.

    리소스 사용자 역할 할당 할당 대상 할당 범위
    Application X 랜딩 존 Application X 소유자 애플리케이션 소유자(사용자 지정, Azure 랜딩 존 가속기 포함) Application X Admins 보안 그룹 Application X 프로덕션 및 개발/테스트 구독
    Application X 랜딩 존 Application X 소유자 애플리케이션 액세스 관리자(사용자 지정, 자체 애플리케이션에 대한 액세스를 관리하는 역할 할당 조건 포함) Application X Admins 보안 그룹 Application X 프로덕션 및 개발/테스트 구독
    Application X 랜딩 존 Application X 데이터 관리자 데이터 관리자(사용자 지정, 필요한 데이터 리소스에 대한 권한 포함) Application X Data Team 보안 그룹 Application X 프로덕션 및 개발/테스트 구독
    애플리케이션 Y 랜딩 존 애플리케이션 Y 소유자 애플리케이션 소유자(사용자 지정, Azure 랜딩 존 가속기 포함) Application Y Admins 보안 그룹 Application Y 프로덕션 및 개발/테스트 구독
    애플리케이션 Y 랜딩 존 Application Y 테스트 팀 테스트 참가자(사용자 지정, 애플리케이션 테스트에 필요한 권한 포함) Application Y Test Team 보안 그룹 Application Y 개발/테스트 구독
    샌드박스 Application Z 개발 팀 소유자(기본 제공) Application Z developers 보안 그룹 샌드박스 구독의 Application Z 리소스 그룹
    플랫폼 리소스 플랫폼 관리 팀 기여자(기본 제공) Platform Admins PIM 그룹 Platform 관리 그룹
    플랫폼 랜딩 존 플랫폼 관리 팀 읽기 권한자(기본 제공) Platform Team 보안 그룹 조직 최상위 관리 그룹
    테넌트 전체 보안 팀 보안 작업(사용자 지정, Azure 랜딩 존 가속기 포함) Security Ops 보안 그룹 조직 최상위 관리 그룹
    테넌트 전체 보안 팀 조건부 액세스 관리자(기본 제공, 보호된 작업을 사용하도록 설정) Security administrators 보안 그룹 Microsoft Entra ID 테넌트
    테넌트 전체 네트워크 팀 네트워크 작업(사용자 지정, Azure 랜딩 존 가속기 포함) Network Ops 보안 그룹 모든 구독
    테넌트 전체 FinOps 팀 청구 판독기(기본 제공) FinOps Team 보안 그룹 조직 최상위 관리 그룹
  • 효과가 있는 Azure Policy 할당에는 DeployIfNotExists 비규격 리소스를 수정하기 위한 관리 ID 가 필요합니다. Azure Policy 할당 프로세스의 일부로 시스템 할당 관리 ID를 사용하는 경우 Azure는 필요한 권한을 자동으로 부여합니다. 사용자 할당 관리 ID를 사용하는 경우 사용 권한을 수동으로 부여해야 합니다. 관리 ID 역할 할당은 PoLP를 따르고 대상 범위에서 정책 수정을 수행하는 데 필요한 권한만 사용하도록 설정해야 합니다. 정책 수정 관리 ID는 사용자 지정 역할 정의를 지원하지 않습니다. 그룹이 아닌 관리 ID에 직접 역할 할당을 적용합니다.

Microsoft Entra PIM 권장 사항

  • Microsoft Entra PIM을 사용하여 제로 트러스트 모델 및 최소 권한 액세스를 준수합니다. 조직의 역할을 필요한 최소 액세스 수준과 상호 연결합니다. Microsoft Entra PIM에서 Azure 네이티브 도구를 사용하거나, 기존 도구 및 프로세스를 확장하거나, 필요에 따라 기존 도구와 네이티브 도구를 모두 사용할 수 있습니다.

  • Microsoft Entra PIM 액세스 검토를 사용하여 정기적으로 리소스 자격의 유효성을 검사합니다. 액세스 검토는 수많은 규정 준수 프레임워크의 일부이므로 많은 조직에서 이미 액세스 검토 프로세스를 갖추고 있습니다.

  • 상승된 액세스 권한이 필요한 자동화 Runbook 또는 권한 있는 배포 파이프라인에 대해 권한 있는 ID를 사용합니다. 동일한 도구와 정책을 사용하여 동등한 권한의 사용자를 제어하는 데 사용하는 중요한 보안 경계에 액세스하는 자동화된 워크플로를 제어할 수 있습니다. 애플리케이션 팀을 위한 자동화 및 배포 파이프라인에는 애플리케이션 소유자가 자신의 권한을 에스컬레이션하지 못하도록 하는 역할 할당이 있어야 합니다.

  • 구독 또는 관리 그룹의 플랫폼 또는 애플리케이션 랜딩 존 팀 구성원에게 할당된 소유자 또는 사용자 액세스 관리자와 같은 높은 권한의 Azure RBAC 역할을 제어합니다. 그룹에 대해 Microsoft Entra PIM을 사용하여 Azure RBAC 역할을 구성하므로 Microsoft Entra ID 역할과 동일한 권한 상승 프로세스가 필요합니다.

    예를 들어 사용자는 애플리케이션 랜딩 존의 리소스에 대한 제한된 관리 액세스 권한을 정기적으로 요구할 수 있습니다. 경우에 따라 소유자 역할이 필요할 수 있습니다. 애플리케이션 관리자 및 애플리케이션 소유자의 두 가지 보안 그룹을 만들 수 있습니다. 애플리케이션 관리자 그룹에 최소 권한 역할을 할당하고, 소유자 역할을 애플리케이션 소유자 역할에 할당합니다. 사용자가 필요한 경우 소유자 역할을 요청할 수 있도록 PIM 그룹을 사용합니다. 다른 모든 경우 사용자는 일반적인 작업을 수행하는 데 필요한 권한만 갖습니다.

  • Microsoft Entra PIM에서 보호된 작업을 사용하여 보호 계층을 추가합니다. Microsoft Entra ID에서 보호된 작업은 조건부 액세스 정책이 할당된 권한입니다. 사용자가 보호된 작업을 수행하려고 하면 먼저 필요한 권한에 할당된 조건부 액세스 정책을 충족해야 합니다. 예를 들어 관리자가 테넌트 간 액세스 설정을 업데이트할 수 있도록 하려면 먼저 피싱 방지 MFA 정책을 충족하도록 요구할 수 있습니다.

Azure 랜딩 존 가속기의 ID 및 액세스 관리

ID 및 액세스 관리는 Azure 랜딩 존 가속기 구현의 핵심 기능입니다. 배포에는 조직에서 해당 환경에 필요한 AD DS 도메인 컨트롤러 또는 기타 ID 서비스(예: Microsoft Entra Connect 서버)를 배포할 수 있는 ID 전용 구독이 포함됩니다. 모든 조직에서 구독에 서비스가 필요한 것은 아닙니다. 예를 들어 일부 조직에는 이미 Microsoft Entra ID와 완전히 통합된 애플리케이션이 있을 수 있습니다.

ID 구독에는 플랫폼 구독의 허브 가상 네트워크에 피어된 가상 네트워크가 있습니다. 이 구성을 사용하면 플랫폼 팀이 ID 구독을 관리할 수 있으며 애플리케이션 소유자는 필요에 따라 ID 서비스에 액세스할 수 있습니다. ID 서비스를 무단 액세스로부터 보호하려면 ID 구독 및 가상 네트워크를 보호해야 합니다.

Azure 랜딩 존 가속기 구현에는 다음 옵션도 포함됩니다.

  • ID 및 도메인 컨트롤러를 제어하는 권장 정책을 할당합니다.
  • 가상 네트워크를 만들고 가상 네트워크 피어링을 통해 허브에 연결합니다.

다음 단계