엔터프라이즈 등록 및 Azure AD 테넌트

Azure 계약을 가진 기업 고객이 적절한 Azure AD 테넌트를 만들고 엔터프라이즈 등록(Enrollment)를 구현하는 중요한 초기 단계

EA 등록(Enrollment)은 Azure EA 포털을 통해 관리되며, 등록(Enrollment) 은 종종 부서, 계정, 구독을 포함하는 조직의 계층 구조를 나타냄

1. 엔터프라이즈 등록 (Enrollment) 계획–설계 권장 사항

• Work or school account모든 계정에 대해서만 인증 사용(Microsoft 계정은 사용 X)
• 알림(Notification)이 적절한 그룹/계정에 전송 되도록 알림 연락처 메일 주소를 설정
• 조직에는 기능, 부서, 지역, 팀 구조와 같은 다양한 구조가 있을 수 있음. 부서 및 계정을 사용하여 조직의 구조를 등록 계층 구조에 매핑하면 청구를 분리하는 데 도움이 됨
• Azure 메타데이터(예: 태그 및 위치)를 사용하여 조직의 비용을 탐색하고 분석할 수 있는 Azure Cost Management + 청구 보고서 및 보기를 사용
• 등록 내의 계정 소유자 수를 제한하고 최소화하여 구독 및 연결된 Azure 리소스에 대한 관리자 액세스를 제한
• 부서별, 계정별로 예산을 할당하고 해당 예산과 관련된 알림을 설정
• 비즈니스 도메인에 독립적인 IT 기능이 있는 경우 IT를 위한 새 부서 (Department)를 생성
• 다중 Azure Active Directory (Azure AD) 테넌트가 사용되는 경우 Account Owner가 해당 계정에 대한 구독이 프로비전 되는 위치와 동일한 테넌트와 연결되어 있는지 확인
• 개발/테스트(개발/테스트) 워크로드의 경우 가능한 경우 Enterprise Dev/Test offer 사용. 사용 약관을 준수하는지 확인
• 알림 계정 이메일 주소로 발송된 알림 이메일을 무시 X. Microsoft는 해당 계정으로 중요한 EA 수준 메일을 발송함
• Azure AD에서 EA 계정을 이동하거나 이름을 변경 X
• 정기적으로 EA 포털을 감사하여 액세스 권한이 있는 사용자를 검토하고 가능한 경우 Microsoft 계정 사용하지 않음
• 모든 기업계약 등록에서 DA 보기 요금과 AO 요금 보기를 모두 활성화하여 올바른 권한이 있는 사용자가 Azure Cost Management + Billing 데이터를 볼 수 있도록 함

2. Azure AD 테넌트 정의–설계 권장 사항 

• Azure Active Directory 포털을 사용하여 사용자 지정 도메인 이름 추가에 따라 Azure AD 테넌트에 하나 이상의 사용자 지정 도메인 추가
  • Azure AD Connect를 계획하거나 사용하여 사용자 지정 도메인 이름이 온-프레미스 Active Directory 도메인 서비스 환경에 반영되는지 확인하려면 Azure AD UserPrincipalName 채우기를 검토
• 지원되는 토폴로지 중 하나를 기반으로 Azure AD Connect를 사용하여 Azure Single Sign-On 전략을 정의
• 조직에 ID 인프라가 없는 경우 Azure AD 전용 ID 배포를 구현하여 시작. Azure AD Domain Services 및 Microsoft Enterprise Mobility + Security를 사용하여 배포하면 SaaS 어플리케이션 등 및 디바이스에 대한 통합된 보안 구현이 가능
• Azure AD Multi-Factor Authentication은 추가적인 보안 및 인증 계층을 제공. 보안 강화를 위해 모든 권한 있는 계정에 대해 multi-factor authentication및 조건부 액세스 정책을 적용
• 테넌트 전체 계정 잠금을 방지 하기 위해 긴급 액세스 또는 투명 계정에 대해 계획하고 구현
• Id 및 액세스 관리에 Azure AD Privileged Identity Management를 사용
• 모든 Azure AD 진단 로그를 중앙 Azure Monitor Log Analytics 작업 영역으로 보내고 Azure AD 로그를 Azure Monitor 로그와 통합
• 여러 Azure AD 테넌트 생성 X. 자세한 내용은 단일 디렉터리 및 ID에서 표준화하기 위한 엔터프라이즈 규모 및 클라우드 채택 프레임워크 Azure 모범 사례 지침에 대한 테스트 접근 방식을 참조
• Azure Lighthouse를 사용하여 타사/파트너에게 고객 Azure AD 테넌트의 Azure 리소스에 대한 액세스 권한을 부여하고 다중 테넌트 Azure AD 아키텍처의 Azure 리소스에 대한 중앙 집중식 액세스 권한을 부여

Azure AD Connect용 토폴로지

단일 포리스트, 단일 Azure AD 테넌트

가장 일반적인 토폴로지는 하나 이상의 도메인이 있는 단일 사내 포리스트와 단일 Azure AD 테넌트입니다. Azure AD 인증의 경우 암호 해시 동기화가 사용됩니다. Azure AD Connect의 고속 설치(express installation)는 이 토폴로지만 지원합니다.

다중 포리스트, 단일 Azure AD 테넌트

많은 조직에는 합병 또는 인수 등의 사유로 여러 온-프레미스 Active Directory 포리스트가 있는 환경이 있습니다.

모든 포리스트에 연결이 필요한 경우 서버를 경계(perimeter) 네트워크(DMZ 및 스크린 서브넷이라고도 함)에 배치할 수 있습니다.

Azure ID 및 액세스 관리

IAM(Identity and Access Management)은 퍼블릭 클라우드의 경계 보안. 안전하고 완벽한 규정을 준수하는 퍼블릭 클라우드 아키텍처의 기반으로 취급되어야 함

1. Azure Active Directory–설계 권장 사항

• 역할 및 보안 요구 사항에 따라 랜딩 존 내부에 배포된 리소스를 관리하기 위해 중앙 집중식 및 위임된 책임을 사용
• 이러한 유형의 권한 있는 작업에는 특별한 권한이 필요
  • 서비스 주체 개체 만들기
  • Azure AD에 애플리케이션 등록
  • 인증서 또는 와일드카드 인증서 조달 및 처리
• 조직에 Windows 통합 인증을 사용하는 애플리케이션에 Azure AD를 통해 원격으로 액세스해야 하는 시나리오가 있는 경우 Azure AD 애플리케이션 프록시를 사용
• Windows Server의 AD DS 및 Azure AD DS에 대한 워크로드의 호환성을 평가
• 네트워크 디자인에서 로컬 인증 및 관리를 위해 Windows Server의 AD DS가 필요한 리소스가 적절한 도메인 컨트롤러에 액세스할 수 있도록 허용
  • Windows Server의 AD DS의 경우 더 큰 전사적 네트워크 컨텍스트에서 로컬 인증 및 호스트 관리를 제공하는 공유 서비스 환경을 고려
• 이 서비스는 하나의 구독에만 프로젝션될 수 있으므로 주 지역 내에 Azure AD DS를 배포함. Azure AD DS 관리 도메인은 복제본 세트가 있는 추가 지역으로 확장 가능
• Azure 서비스에 대한 인증을 위해 서비스 주체 대신 관리 ID를 사용. 이 접근 방식은 자격 증명 도용에 대한 노출 감소

2. 랜딩 존 전제조건–설계 권장 사항

• 가능한 경우 Azure RBAC를 사용하여 리소스(Azure Key Vault, 스토리지 계정 또는 SQL 데이터베이스)에 대한 데이터 평면 액세스를 관리
• Azure 환경에 대한 권한이 있는 모든 사용자에 대해 Azure AD 조건부 액세스 정책을 배포합니다. 이렇게 하면 제어된 Azure 환경을 무단 액세스로부터 보호하는 데 도움이 되는 또 다른 메커니즘이 제공
• Azure 환경에 대한 권한이 있는 모든 사용자에 대해 다단계 인증을 시행하여 자격 증명 도용 및 무단 액세스의 위험을 크게 낮춤
• Azure 리소스 범위에 사용자를 직접 추가하는 대신 정의된 역할에 사용자를 추가 후 리소스 범위에 할당. 직접 사용자 할당은 중앙 집중식 관리를 우회하여 제한된 데이터에 대한 무단 액세스를 방지하는 데 필요한 관리를 크게 증가시킴
• Azure 리소스에 대한 Azure AD 관리 ID를 사용하여 사용자 이름 및 비밀번호에 따른 인증을 피할 수 있음. 퍼블릭 클라우드 리소스의 많은 보안 침해는 코드 또는 기타 텍스트 소스에 포함된 자격 증명 도용에서 비롯되므로 프로그램 액세스를 위해 관리되는 ID를 적용하면 자격 증명 도용의 위험이 크게 줄어듬
• 모든 IaaS(Infrastructure as a Service) 리소스에 대해 Microsoft Defender for Cloud 적시 액세스를 사용하여 IaaS 가상 머신에 대한 임시 사용자 액세스에 대해 네트워크 수준 보호를 활성화 함
• Azure AD PIM(Privileged Identity Management)을 사용하여 제로 스탠딩 액세스 및 최소 권한을 설정. 조직의 역할을 필요한 최소 액세스 수준으로 매핑함. Azure AD PIM은 다음을 수행할 수 있음
  • 현재 도구 및 프로세스의 확장
  • 설명된 대로 Azure 기본 도구 사용

  • 필요에 따라 둘 다 사용

• Azure AD PIM 액세스 검토를 사용하여 리소스 자격을 주기적으로 확인함.
• 상승된 액세스 권한이 필요한 자동화 Runbook에 권한 있는 ID를 사용함. 중요한 보안 경계를 위반하는 자동화된 워크플로는 동등한 권한을 가진 사용자와 동일한 도구 및 정책에 의해 관리되어야 함

3. 플랫폼 액세스–설계 권장 사항

• 리소스에 대한 액세스 권한을 부여하는 경우 Azure AD PIM의 Azure 컨트롤 플레인 리소스에 Azure AD 전용 그룹을 사용
  • 그룹 관리 시스템이 이미 있는 경우 온-프레미스 그룹을 Azure AD 전용 그룹에 추가.
    • Azure AD-only 그룹을 사용하면 Azure AD Connect를 통해 온프렘에서 동기화된 사용자와 그룹을 모두 추가할 수 있음. 게스트 사용자를 포함하여 Azure AD-only(클라우드 전용이라고도 함) 사용자 및 그룹을 단일 Azure AD-only 그룹에 추가할 수도 있음. 또한 사내에서 동기화된 그룹은 ID 진실 소스(내부 Active Directory)에서만 관리 및 업데이트할 수 있음. 이러한 그룹은 동일한 ID 소스의 멤버만 포함할 수 있으므로 Azure AD 전용 그룹처럼 유연성이 없음
• Azure AD 로그를 플랫폼 중심의 Log Analytics 작업 공간과 통합함. 로그 및 Azure의 모니터링 데이터에 대한 단일 정보 출처를 통해 조직은 로그 수집 및 보존 관련 요구사항을 충족할 수 있는 클라우드 네이티브 옵션을 제공함
• 데이터 주권 요구 사항이 있는 경우 사용자 지정 사용자 정책을 배포하여 이를 시행할 수 있음

관리 그룹 및 구독 조직

1. 관리 그룹 계층 구조를 정의-설계 권장 사항

• 관리 그룹 계층을 3~4개 이하의 수준으로 적절하게 균일하게 유지. 이러한 제한은 관리 오버헤드와 복잡성을 줄여 줌 
• 조직 구조를 깊이 중첩된 관리 그룹 계층 구조로 복제하지 말 것. 정책 할당 대 청구 목적으로 관리 그룹을 사용. 이 접근 방식에서는 Azure 랜딩 존 개념 아키텍처에서 의도한 목적에 따라 관리 그룹을 사용해야 함. 이 아키텍처는 동일한 관리 그룹 수준에서 동일한 유형의 보안 및 규정 준수가 필요한 워크로드에 대한 Azure 정책을 제공함.
• 루트 수준 관리 그룹 아래에 관리 그룹을 만들어 호스트 할 워크로드 유형을 나타냄. 이러한 그룹은 워크로드의 보안, 규정 준수, 연결 및 기능 요구 사항을 기반으로 함. 이 그룹화 구조를 사용하면 관리 그룹 수준에서 Azure 정책 집합을 적용할 수 있음. 이 그룹화 구조는 동일한 보안, 규정 준수, 연결 및 기능 설정이 필요한 모든 워크로드를 위한 것임
• 리소스 태그를 사용하여 관리 그룹 계층 구조를 쿼리하고 수평으로 탐색함. 리소스 태그는 Azure Policy를 통해 적용하거나 추가할 수 있음. 그런 다음 복잡한 관리 그룹 계층을 사용하지 않고도 검색 요구 사항에 맞게 리소스를 그룹화할 수 있음.
• 사용자가 Azure를 즉시 실험할 수 있도록 최상위 샌드박스 관리 그룹을 만듬. 그런 다음 프로덕션 환경에서 아직 허용되지 않을 수 있는 리소스로 실험할 수 있음. 샌드박스는 개발, 테스트 및 프로덕션 환경에서 격리를 제공함.
• 루트 관리 그룹 아래에 플랫폼 관리 그룹을 만들어 공통 플랫폼 정책 및 Azure 역할 할당을 지원함. 이 그룹화 구조는 Azure 기반에 사용되는 구독에 다양한 정책을 적용할 수 있도록 함. 또한 공통 리소스에 대한 청구가 하나의 기본 구독 세트로 중앙 집중화되도록 함
• 루트 관리 그룹 범위에서 수행되는 Azure Policy 할당 수를 제한함. 이 제한은 하위 수준 관리 그룹에서 상속된 정책 디버깅을 최소화 함
• 정책을 사용하여 관리 그룹 또는 구독 범위에서 규정 준수 요구 사항을 적용하여 정책 기반 거버넌스를 달성함
• 권한 있는 사용자만 테넌트에서 관리 그룹을 작동할 수 있는지 확인함. 관리 그룹 계층 설정에서 Azure RBAC 권한 부여를 사용하도록 설정하여 사용자 권한을 구체화 함. 이 그룹은 MSDN(Microsoft 개발자 네트워크) 또는 Visual Studio 혜택 및 구독에 대한 자격이 있는 사용자가 있는 경우 특히 중요함. 이러한 유형의 관리 그룹에 적합한 후보는 샌드박스 관리 그룹임. 자세한 내용은 설정 - 기본 관리 그룹을 참조
• 프로덕션, 테스트 및 개발 환경에 대한 관리 그룹을 만들지 말 것. 필요한 경우 이러한 그룹을 동일한 관리 그룹의 다른 구독으로 분리함. 이 주제에 대한 추가 지침을 검토하려면 다음을 참조
  • 엔터프라이즈 규모 아키텍처에서 "개발/테스트/프로덕션" 워크로드 랜딩 영역을 어떻게 처리합니까? - 자주하는 질문
  • 엔터프라이즈 규모를 위한 테스트 접근 방식

Azure 방문 영역 가속기의 관리 그룹

2. 구독 (Subscription) 조직 및 거버넌스–설계 권장 사항

• 구독을 비즈니스 요구 사항 및 우선 순위에 맞는 관리 단위로 취급할 것
• 구독 소유자가 역할 및 책임을 인식하도록 함
• 분기 또는 연 단위로 Azure AD Privileged Identity Management에서 액세스 검토를 수행하여 사용자가 고객 조직 내에서 이동할 때 권한이 확산되지 않도록 함
  • 예산 지출과 자원을 완전히 소유할 것
  • 정책 준수를 확인하고 필요한 경우 수정
• 새 구독에 대한 요구 사항을 식별할 때 다음 원칙을 사용

• 예산 지출 및 리소스 사용률에 대한 완전한 소유권.
• 정책 준수를 확인하고 필요한 경우 재구성
• 새 구독에 대한 요구 사항을 식별할 때 다음 원칙을 사용.
  • 크기 제한: 구독은 플랫폼 구독 제한 내에서 확장할 수 있는 구성 요소 워크로드의 확장 단위 역할을 함. 고성능 컴퓨팅, IoT 및 SAP와 같은 대규모 특수 워크로드는 제한을 피하기 위해 별도의 구독을 사용해야 함
  • 관리 경계: 구독은 거버넌스 및 격리를 위한 관리 경계를 제공하여 문제를 명확하게 구분할 수 있음. 개발, 테스트 및 프로덕션과 같은 다양한 환경은 종종 관리 관점에서 제거됨
  • 정책 경계:  구독은 Azure 정책 할당을 위한 경계 역할을 함. 예를 들어 PCI와 같은 보안 워크로드는 일반적으로 규정 준수를 위해 다른 정책이 필요함. 별도의 구독을 사용하는 경우 다른 오버헤드는 고려되지 않음. 개발 환경은 프로덕션 환경보다 정책 요구 사항이 더 느슨함
  • 대상 네트워크 토폴로지: 가상 네트워크는 구독 간에 공유할 수 없지만 가상 네트워크 피어링 또는 Azure ExpressRoute와 같은 다른 기술과 연결할 수 있음. 새 구독이 필요한지 결정할 때 서로 통신해야 하는 워크로드를 고려함
• 관리 그룹 구조 및 정책 요구 사항과 일치하는 관리 그룹 아래에 구독을 함께 그룹화. 그룹화는 동일한 정책 및 Azure 역할 할당 집합이 있는 구독이 관리 그룹에서 제공되도록 함
• Azure Monitor Log Analytics 작업 영역 및 Azure Automation Runbook과 같은 전역 관리 기능을 지원하려면 Platform 관리 그룹에서 전용 관리 구독을 설정할 것
• 필요한 경우 Platform 관리 그룹에서 전용 ID 구독을 설정하여 Windows Server Active Directory 도메인 컨트롤러를 호스팅
• Platform 관리 그룹에서 전용 연결 구독을 설정하여 Azure Virtual WAN 허브, 개인 DNS(Domain Name System), ExpressRoute 회로 및 기타 네트워킹 리소스를 호스팅 함. 전용 구독을 사용하면 모든 기반 네트워크 리소스가 함께 청구되고 다른 워크로드와 격리 됨
• 엄격한 구독 모델을 피하고 조직 전체에서 구독을 그룹화하기 위해 유연한 기준 세트를 선택할 것. 유연성 덕분에 조직의 구조와 워크로드 구성이 변경되면 고정된 기존 구독 집합을 사용하는 대신 새 구독 그룹을 만들 수 있음. 한 가지 크기가 구독에 모두 적합하지 않으며 한 사업부에서 작동하는 것이 다른 사업부에서는 작동하지 않을 수 있음. 일부 애플리케이션은 동일한 랜딩 존 구독 내에 공존할 수 있지만 다른 애플리케이션은 자체 구독이 필요할 수 있음
• 엔터프라이즈 규모 아키텍처에서 "개발/테스트/프로덕션" 워크로드 랜딩 영역을 어떻게 처리합니까?를 참조할 것. 이 점에 대한 추가 지침. FAW PR이 #2676 병합되면 링크를 업데이트해야 함

3. 구독 할당량 및 용량 구성–설계 권장 사항

• 구독을 확장 단위로 사용하고 필요에 따라 리소스 및 구독을 확장. 그러면 워크로드가 Azure 플랫폼에서 구독 제한에 도달하지 않고 수평 확장에 필요한 리소스를 사용할 수 있음
• 예약 인스턴스를 사용하여 일부 지역의 용량을 관리. 그러면 워크로드에 특정 지역의 수요가 많은 리소스에 필요한 용량이 있을 수 있음
• 사용된 용량 수준을 모니터링하기 위해 사용자 지정 보기가 있는 대시보드를 설정하고 용량이 임계 수준(90% CPU 사용량)에 도달하면 경고를 설정
• 구독 프로비저닝에서 할당량 증가에 대한 지원 요청을 올림(예: 구독 내에서 사용 가능한 총 VM 코어). 그런 다음 워크로드가 기본 제한을 초과하기 전에 할당량 제한이 설정되었는지 확인가능

4. 비용 관리 설정–설계 권장 사항

• 사용자가 Azure AD 테넌트 간에 Azure 구독을 전송하지 못하도록 하려면 다음 설정을 구성

  • Subscription leaving Azure AD directory set to Permit no one.

  • Subscription entering Azure AD directory set to Permit no one.

• 제한된 사용자 집합을 구성할 것
  • Azure PlatformOps(플랫폼 운영) 팀의 구성원을 포함함
  • 면제된 사용자 목록에 Break Glass 계정을 포함함

네트워크 토폴로지 및 연결 - 설계 개요

1. IP 주소 지정 계획 –설계 권장 사항

• Azure 리전 및 온-프레미스 위치에서 겹치지 않는 IP 주소 공간을 미리 계획함
• Private 인터넷에 대한 주소 할당의 IP 주소 (RFC 1918)를 사용
• 다음 주소 범위를 사용하지 말 것
  • 224.0.0.0/4 (multicast)
  • 255.255.255.255/32 (broadcast)
  • 127.0.0.0/8 (loopback)
  • 169.254.0.0/16 (link-local)
  • 168.63.129.16/32 (internal DNS)
• 사설 IP 주소의 가용성이 제한된 환경의 경우 IPv6 사용을 고려할 것. 가상 네트워크는 IPv4 전용 또는 이중 스택 IPv4+IPv6일 수 있음
• /16과 같은 대규모 가상 네트워크를 생성하지 말 것. 이는 IP 주소 공간이 낭비되지 않도록 보장함. 지원되는 가장 작은 IPv4 서브넷은 /29이고 클래스 없는 도메인 간 라우팅(CIDR) 서브넷 정의를 사용할 경우 가장 큰 서브넷은 /2임. IPv6 서브넷의 크기는 정확히 /64여야 함
• 필요한 주소 공간을 미리 계획하지 않고 가상 네트워크를 만들지 말 것
• 특히 공용 IP 주소가 조직에 속하지 않는 경우 가상 네트워크에 공용 IP 주소를 사용하지 말 것

2. 온-프레미스 및 Azure 리소스에 대 한 DNS 및 이름 확인 구성–설계 권장 사항

• Azure의 이름 확인만 필요한 환경의 경우 확인을 위해 Azure Private DNS 영역을 사용. 이름 확인을 위한 위임 영역(예: azure.contoso.com)을 생성. Azure Private DNS에 대한 자동 등록을 활성화하여 가상 네트워크 내에 배포된 가상 머신에 대한 DNS 레코드의 수명 주기를 자동으로 관리
• Azure 및 온-프레미스에서 이름 확인이 필요한 환경에서는 두 개 이상의 VM (가상 컴퓨터)에 배포 된 기존 DNS 인프라 (예: Active Directory 통합 DNS)를 사용. 이러한 DNS 서버를 사용 하도록 가상 네트워크에서 DNS 설정을 구성
• Azure Firewall이 있는 환경의 경우 이를 DNS 프록시로 사용하여 평가
• Azure Private DNS를 사용하여 프레미스 간 DNS 확인을 위해 가상 머신을 확인자로 사용
• Azure 프라이빗 DNS 영역을 가상 네트워크에 연결하고 온-프레미스 DNS 서버를 사용하여 company.contoso.com과 같은 온-프레미스 DNS 이름에 대한 조건부 전달을 통해 DNS 서버를 하이브리드 확인자로 사용할 수 있음. Azure Private DNS 영역(예: azure.contoso.com)에 대해 Azure의 확인자 VM에 대한 조건부 전달자가 있는 온-프레미스 서버를 구성할 수 있음
• 자체 DNS(예: Red Hat OpenShift)를 필요로 하고 배포하는 특수 워크로드는 선호하는 DNS 솔루션을 사용해야 함
• 글로벌 연결 구독 내에 Azure Private DNS 영역을 생성. 생성해야하는 Azure Private DNS 영역에는 프라이빗 엔드포인트 (예 : privatelink.database.windows.net 또는 privatelink.blob.core.windows.net)를 통해 Azure PaaS 서비스에 액세스하는 데 필요한 영역이 포함됨

3. Azure 네트워크 토폴로지 정의 / 4. Azure 연결 –설계 권장 사항

1. Azure Virtual WAN Based Networking Topology
2. Traditional Azure Networking Topology

5. Azure PaaS 서비스에 대한 연결–설계 권장 사항

• 가상 네트워크 내에서 사용할 수 있도록 지원되는 Azure 서비스에 대한 가상 네트워크 Injection을 사용.
• 가상 네트워크에 Injection 된 Azure PaaS 서비스는 여전히 공용 IP 주소를 사용하여 관리 플레인 작업을 수행함. UDRs 및 NSGs를 사용하여 가상 네트워크 내에서이 통신이 잠겨 있는지 확인함.
• 공유 Azure PaaS 서비스에 대한 개인 링크 (Private Link) 를 사용함. 개인 링크(Private Link)는 일반적으로 여러 서비스에 사용할 수 있음.
• 프라이빗 피어링으로 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스함. 사용 가능한 공유 Azure 서비스에 대한 Dedicated Azure 서비스 또는 Azure Private Link 에 대한 가상 네트워크 Injection을 사용. Virtual network Injection 또는 Private Link를 사용할 수 없는 경우 온-프레미스에서 Azure PaaS 서비스에 액세스 하려면 Microsoft 피어 링과 함께 ExpressRoute를 사용함.
  • Microsoft 피어링을 사용하여 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스해도 PaaS 서비스의 공용 엔드포인트에 대한 액세스가 차단되지 않으므로 필요에 따라 별도로 구성 및 제한해야 함
• 가상 네트워크 서비스 엔드포인트를 사용하여 가상 네트워크 내에서 Azure PaaS 서비스에 안전하게 액세스할 수 있지만 Private Link를 사용할 수 없고 데이터 유출 우려가 없는 경우에만 가능함. 서비스 엔드포인트의 데이터 유출 문제를 해결하려면 Azure Storage에 대해 NVA 필터링을 사용하거나 가상 네트워크 서비스 엔드포인트 정책을 사용할 것
• 모든 서브넷에서 기본적으로 가상 네트워크 서비스 끝점을 사용하도록 설정 하지 말 것
• NVA 필터링을 사용하지 않는 한 데이터 유출 문제가 있는 경우 가상 네트워크 서비스 끝점을 사용하지 말 것
• Azure에서 Azure 리소스로의 통신을 활성화하기 위해 강제 터널링을 구현하지 않는 것이 좋음

6. 인바운드 및 아웃 바운드 인터넷 연결 계획 –설계 권장 사항

• Azure Firewall을 사용하여 다음을 제어함.
  • 인터넷에 대한 Azure 아웃 바운드 트래픽
  • 비 HTTP/S 인바운드 연결
  • East - West 트래픽 필터링 (필요 시)
• 고급 방화벽 기능(TLS 검사, 네트워크 침입 감지 및 방지 시스템(IDPS), URL 필터링, 웹 범주)이 필요한 경우 Azure Firewall 프리미엄을 사용
• Virtual WAN과 함께 Firewall Manager를 사용하여 Virtual WAN 허브 또는 허브 가상 네트워크에서 Azure 방화벽을 배포하고 관리함. 이제 방화벽 관리자는 가상 WAN과 일반 가상 네트워크 모두에서 일반 공급됨
• 여러 IP 주소와 범위가 Azure Firewall 규칙에서 일관되게 사용되는 경우 IP 그룹을 사용하는 것이 좋음. IP 그룹은 Azure 방화벽 DNAT, 네트워크 및 Azure의 여러 방화벽 및 구독에 대한 애플리케이션 규칙에서 재사용할 수 있음
• 글로벌 Azure Firewall 정책을 만들어 글로벌 네트워크 환경의 보안 상태를 제어하고 모든 Azure Firewall 인스턴스에 할당함. Azure 역할 기반 액세스 제어를 통해 증분 방화벽 정책을 로컬 보안 팀에 위임하여 세분화된 정책이 특정 지역의 요구사항을 충족하도록 허용함
• 조직에서 아웃바운드 연결을 보호하기 위해 이러한 솔루션을 사용하려는 경우 Firewall Manager 내에서 지원되는 파트너 SaaS 보안 공급자를 구성함
• 인터넷에서 인바운드 HTTP/S 트래픽을 보호 하기 위해 Landing Zone 가상 네트워크 내에서 WAF를 사용함
• Azure Front Door 및 WAF 정책을 사용 하 여 Azure 지역에서 방문 영역에 대 한 인바운드 HTTP/S 연결을 위한 글로벌 보호를 제공함
• Azure Front Door 및 Azure Application Gateway를 사용하여 HTTP/S 앱을 보호하는 경우 Azure FrontDoor에 WAF 정책을 사용할 것. Azure Front Door에서만 트래픽을 수신하도록 Azure Application Gateway를 잠금
• 어떤 시나리오에서도 Azure의 기본 인터넷 아웃바운드 액세스를 사용하지 말 것
  • 허브 VNet에 연결되지 않은 랜딩 존인 online 랜딩 존에는 NAT 게이트웨이를 사용할 것. 여기서 컴퓨팅 리소스는 인터넷 아웃바운드 액세스가 필요하며 Azure 방화벽(표준 또는 프리미엄) 또는 타사 NVA에서 제공하는 보안 기능이 불필요
• 동/서 또는 남/북 트래픽 보호 및 필터링에 파트너 NVA가 필요한 경우:
  • 가상 WAN 네트워크 토폴로지의 경우 NVA를 별도의 가상 네트워크(예: NVA 가상 네트워크)에 배포할 것. 그런 다음 리전의 가상 WAN 허브 및 NVA에 액세스 해야 하는 랜딩 존에 연결함. 이 글에서는 그 과정을 설명함
• 인바운드 HTTP/S 연결에 파트너 NVA가 필요한 경우 Landing Zone 가상 네트워크 내에 배포 하여 인터넷에 노출되는 앱과 함께 배포함
• 가상 머신 관리 포트를 인터넷에 노출하지 말 것
  • Azure Policy를 사용하여 공용 IP가 연결된 가상 머신 생성을 방지함
  • Azure Bastion을 사용하여 관리 목적으로 점프 박스 가상 머신에 액세스함
• Azure DDoS Protection Standard Protection 를 적용하여 가상 네트워크 내에서 호스트 되는 모든 공용 엔드포인트를 보호할 수 있음.
• 온-프레미스 경계 네트워크 개념 및 아키텍처를 Azure에 복제하지 말 것. Azure에서 유사한 보안 기능을 사용할 수 있지만 구현 및 아키텍처를 클라우드에 맞게 조정해야 함

7. 앱 (App) 서비스 제공 계획 –설계 권장 사항

• 내부 및 외부 연결 앱 모두에 대해 Landing Zone 내에서 앱 제공을 함.
• HTTP/S 앱을 안전하게 제공하려면 Application Gateway v2를 사용하고 WAF 보호 및 정책을 사용하도록 설정 했는지 확인함.
• HTTP/S 어플리케이션의 보안에 Application Gateway v2를 사용할 수 없는 경우 파트너 NVA를 사용함.
• Landing Zone 가상 네트워크 내의 인바운드 HTTP/S 연결에 사용되는 Azure Application Gateway v2 또는 파트너 NVA를 배포하고 보안을 유지하는 앱을 배포함.
• Landing Zone에서 모든 공용 IP 주소에 대해 DDoS standard 보호 계획을 사용함.
• WAF 정책과 함께 Azure Front Door를 사용하여 Azure Region에 걸친 전역 HTTP/S 앱을 제공하고 보호.
• Front Door 및 Application Gateway를 사용하여 HTTP/S 앱을 보호하는 경우 Front Door WAF 정책을 사용하고, Front Door 에서만 트래픽을 수신 하려면 Application Gateway를 잠금.
• Traffic Manager를 사용하여 HTTP/S 이외의 프로토콜에 걸쳐 있는 전역 애플리케이션을 제공함.

8. 랜딩 존 네트워크 계획–설계 권장 사항

• 서브넷 생성을 랜딩 존 소유자에게 위임. 이를 통해 서브넷(예: 단일 대형 서브넷, 다중 계층 애플리케이션 또는 네트워크 주입 애플리케이션)에서 워크로드를 분할하는 방법을 정의할 수 있음. 플랫폼 팀은 Azure Policy를 사용하여 특정 규칙(예: 인터넷에서 인바운드 SSH 또는 RDP 거부, 랜딩 존 간 트래픽 허용/차단)이 있는 NSG가 항상 거부 전용 정책이 있는 서브넷과 연결되도록 할 수 있음.

• NSGs를 사용하여 여러 서브넷에서 트래픽을 보호하고, 플랫폼 간 트래픽 (랜딩 존 간 트래픽)을 보호함.
• 어플리케이션 팀은 서브넷 수준 NSGs에서 어플리케이션 보안 그룹을 사용하여 Landing Zone 내에서 다계층으로 VM을 보호해야 함.
• NSGs 및 어플리케이션 보안 그룹을 사용하여 Landing Zone 내의 트래픽을 세부 분할하고 중앙 NVA를 사용하여 트래픽 Flow를 필터링 하지 않도록 함.

• NSG 흐름 로그를 사용 설정하고 트래픽 분석에 제공하여 내부 및 외부 트래픽 흐름에 대한 통찰력을 얻음. 감사 기능 및 보안 모범 사례로 구독의 모든 중요한 VNet/서브넷에서 흐름 로그를 사용하도록 설정해야 함

• NSGs를 사용하여 Landing Zone 간 연결을 선택적으로 허용.

• Virtual WAN 토폴로지의 경우 조직에서 랜딩 존을 가로질러 흐르는 트래픽에 대한 필터링 및 로깅 기능이 필요한 경우 Azure 방화벽을 통해 랜딩 존 간에 트래픽을 라우팅 함

• 조직에서 온프레미스에 대한 강제 터널링(기본 경로 보급)을 구현하기로 결정한 경우 다음 아웃바운드 NSG 규칙을 통합하여 BGP 세션이 중단될 경우 VNet에서 인터넷으로 직접 나가는 이그레스 트래픽을 거부하는 것이 좋음

9. 네트워크 암호화 요구 사항 정의–설계 권장 사항

• VPN 게이트웨이를 사용하여 온-프레미스에서 Azure로 VPN 연결을 설정하는 경우 트래픽은 IPsec 터널을 통해 프로토콜 수준에서 암호화 됨. 앞의 다이어그램은 흐름 A의 이 암호화를 보여 줌

• ExpressRoute Direct를 사용하는 경우 조직의 라우터와 MSEE 간의 계층 2에서 트래픽을 암호화하기 위해 MACsec을 구성함. 다이어그램은 흐름 B에서 이 암호화를 보여 줌

• MACsec이 옵션이 아닌 Virtual WAN 시나리오의 경우(예: ExpressRoute Direct를 사용하지 않음) Virtual WAN VPN 게이트웨이를 사용하여 ExpressRoute 프라이빗 피어링을 통해 IPsec 터널을 설정함. 다이어그램은 흐름 C에서 이 암호화를 보여 줌

• 비가상 WAN 시나리오와 MACsec이 옵션이 아닌 경우(예: ExpressRoute Direct를 사용하지 않음) 유일한 옵션은 다음과 같음

  • 파트너 NVA를 사용하여 ExpressRoute 프라이빗 피어링을 통해 IPsec 터널을 설정함

  • Microsoft 피어링을 사용하여 ExpressRoute를 통해 VPN 터널을 설정함

  • ExpressRoute 프라이빗 피어링을 통해 사이트 간 VPN 연결을 구성하는 기능을 평가함

• 기본 Azure 솔루션(다이어그램의 흐름 B 및 C에 표시됨)이 요구 사항을 충족하지 않는 경우 Azure에서 파트너 NVA를 사용하여 ExpressRoute 프라이빗 피어링을 통해 트래픽을 암호화 함

10. 트래픽 검사 계획–설계 권장 사항

• 제한된 캡처 창에도 불구하고 Network Watcher 패킷을 사용하여 캡처할 것

• 최신 버전의 NSG 흐름 로그가 필요한 세부 정보 수준을 제공하는지 평가함

• NSG 흐름 로그는 타사 Elastic Stack, Grafana 및 Graylog를 비롯한 여러 도구를 사용하여 분석할 수 있음. 권장되는 Azure 자사 솔루션은 Azure Traffic Analytics임

• 심층 패킷 검사가 필요한 시나리오에는 파트너 솔루션을 사용할 것

• 트래픽을 미러링하는 맞춤형 솔루션을 개발하지 말 것. 이 접근 방식은 소규모 시나리오에 적합할 수 있지만 발생할 수 있는 복잡성 및 지원 가능성 문제 때문에 대규모로 권장하지 않음

관리 및 모니터링 – 설계 개요

1. 인벤토리 및 가시성 고려 사항 –설계 권장 사항

• Azure RBAC, 데이터 주권 요구 사항 및 데이터 보존 정책에서 별도의 작업 영역을 요구하는 경우를 제외하고 단일 모니터 로그 작업 영역을 사용하여 플랫폼을 중앙에서 관리. 중앙 집중식 로깅은 운영 관리 팀이 요구하는 가시성에 매우 중요함. 중앙 집중화 드라이브 로깅은 변경 관리, 서비스 상태, 구성 및 기타 대부분의 IT 운영 측면에 대한 보고서를 작성함. 중앙 집중식 업무 공간 모델에 초점을 맞추면 관리 작업과 관찰 가능성 격차가 줄어듬
• 로그 보존 요구 사항이 2년을 초과하는 경우 Azure Storage로 로그를 내보냄. write-once, read-many 정책과 함께 변경할 수 없는 저장소를 사용하여 사용자가 지정한 간격 동안 데이터를 지울 수 없고 수정할 수 없도록 함
• 액세스 제어 및 규정 준수 보고를 위해 Azure Policy를 사용함. Azure Policy를 사용하면 일관된 정책 준수 및 빠른 위반 감지를 보장하기 위해 조직 전체에 설정을 적용할 수 있음
• Azure Policy를 사용하여 게스트 내 VM(가상 머신) 구성 드리프트를 모니터링 함. 정책을 통해 게스트 구성 감사 기능을 활성화하면 애플리케이션 팀 워크로드가 거의 노력 없이 즉시 기능들을 사용할 수 있음
• Azure Automation의 업데이트 관리를 Windows 및 Linux VM의 장기 패치 메커니즘으로 사용할 것. Azure 정책을 통해 업데이트 관리 구성을 적용하면 모든 VM이 패치 관리 요법에 포함됨. 또한 응용 프로그램 팀에게 VM에 대한 패치 배포를 관리할 수 있는 기능을 제공함. 또한 모든 VM에 걸쳐 중앙 IT 팀에 가시성 및 실행 기능을 제공 함
• Network Watcher를 사용하여 Network Watcher NSG 흐름 로그 v2를 통과하는 트래픽 흐름을 사전에 모니터링 함. Traffic Analytics는 NSG 흐름 로그를 분석하여 가상 네트워크 내의 IP 트래픽에 대한 심층적인 통찰력을 수집하고 효과적인 관리 및 모니터링을 위한 중요한 정보를 제공함. 트래픽 분석 기능은 다음과 같은 정보를 제공함
  • 대부분의 통신 호스트 및 애플리케이션 프로토콜
  • 가장 많이 대화하는 호스트 쌍
  • 허용 또는 차단된 트래픽

  • 인바운드 및 아웃바운드 트래픽

  • 오픈된 인터넷 포트

  • 대부분의 차단 규칙
  • Azure 데이터 센터당 트래픽 분산
  • 가상 네트워크
  • 서브넷
  • 불량 네트워크

• 리소스 잠금 (Lock)을 사용하여 중요한 공유 서비스의 실수로 인한 삭제를 방지함.
• 거부 정책을 사용하여 Azure 역할 할당을 보완함. 거부 정책은 정의된 표준과 일치하지 않는 리소스를 배포 및 구성하는 것을 방지하는 데 도움이 됨. 리소스 공급자로 요청이 전송되지 않도록 함으로써 이러한 작업을 수행함. 거부 정책과 Azure 역할 할당을 함께 사용하면 리소스를 배포 및 구성할 수 있는 사용자와 리소스를 배포 및 구성할 수 있는 리소스를 강제 적용할 수 있는 적절한 가드 레일이 구축됨
• 전체 플랫폼 모니터링 솔루션의 일부로 서비스 및 리소스 상태 이벤트를 포함함. 플랫폼 관점에서 서비스 및 리소스 상태를 추적하는 것은 Azure에서 리소스 관리의 중요한 구성 요소임
• Raw 로그 항목을 온-프레미스 모니터링 시스템으로 다시 보내지 않음. 대신 “Data born in Azure stays in Azure” 원척을 유지함. 온-프레미스 SIEM 통합이 필요한 경우 로그 대신 중요한 알림을 보냄.

2. 워크로드 관리 및 모니터링 –설계 권장 사항

• 중앙 집중식 Log Analytics 작업 영역을 사용하여 IaaS 및 PaaS 워크로드 리소스에서 로그 및 메트릭을 수집함
• Azure RBAC를 사용하여 작업 영역 및 로그 액세스를 제어함. 자세한 내용은 Azure Monitor 액세스 제어 개요를 참조
• 시간에 민감한(Time Sensitive) 분석을 위해 Azure Monitor Metrics을 사용 : Azure Monitor는 타임스탬프 데이터를 분석하도록 최적화된 시계열 데이터베이스에 메트릭스를 저장함. 메트릭은 경고 및 문제 탐지에 매우 적합함. 메트릭은 시스템 성능을 모니터링할 수도 있음. 메트릭을 로그와 결합하여 문제의 근본 원인을 식별할 수 있음
• 인사이트 및 보고를 위해 Azure Monitor Metrics를 사용 : 로그에는 서로 다른 속성 집합을 가진 레코드로 구성된 다양한 유형의 데이터가 포함됨. 로그는 성능 데이터, 이벤트 및 추적과 같은 다양한 소스의 복잡한 데이터를 분석하는 데 유용함. 필요한 경우 Azure 진단 확장 로그 저장소에 대해 Landing Zone 내에서 공유 저장소 계정을 사용함
• Azure Monitor alerts를 사용하여 운영 경고를 생성. Azure Monitor 경고는 메트릭 및 로그 경고를 통합하고 고급 관리 및 수정을 위해 작업 및 스마트 그룹과 같은 기능을 사용함

비즈니스 연속성 및 재해복구 – 설계 개요

1. 엔터프라이즈 규모 비즈니스 연속성 및 재해 복구 –설계 권장 사항

• Azure-to-Azure VM DR 시나리오에 Azure Site Recovery를 사용 : Site Recovery는 실시간 복제 및 복구 자동화를 사용하여 여러 리전에 걸쳐 워크로드를 복제함. VM 워크로드를 위한 기본 제공 플랫폼 기능은 낮은 RPO 및 RTO 요구사항을 충족함. Site Recovery를 사용하여 운영 워크로드에 영향을 주지 않고 복구 훈련을 실행할 수 있음. Azure 정책을 사용하여 복제를 사용하도록 설정하고 VM 보호를 감사할 수도 있음
• 네이티브 PaaS 서비스 재해 복구 기능을 사용 : 기본 제공 PaaS 기능은 워크로드 아키텍처의 복제 및 장애 조치를 위한 설계 및 배포 자동화를 단순화 함. 서비스 표준을 정의하는 조직은 Azure Policy를 통해 서비스 구성을 감사하고 시행할 수도 있음
• Azure 기본 백업 기능을 사용 : Azure 백업 및 PaaS 기본 백업 기능은 타사 백업 소프트웨어 및 인프라에 대한 필요성을 제거함. 다른 기본 기능과 마찬가지로 Azure 정책을 사용하여 백업 구성을 설정, 감사 및 적용하여 조직 요구 사항을 준수할 수 있음
• ExpressRoute 연결에는 여러 Region 및 피어링 위치를 사용 : 중복 하이브리드 네트워크 아키텍처는 중단이 Azure 지역 또는 피어링 공급자 위치에 영향을 미치는 경우 중단 없는 프레미스 간 연결을 보장하는 데 도움이 될 수 있음
• 프로덕션 및 DR 사이트에 겹치는 IP 주소 범위를 사용하지 않음 : 동일한 클래스 없는 도메인간 라우팅 블록을 사용하는 프로덕션 DR 네트워크에는 애플리케이션 장애 조치를 복잡하게 하고 지연시킬 수 있는 장애 조치 프로세스가 필요함. 가능한 경우 모든 사이트에 동시 연결을 제공하는 BCDR 네트워크 아키텍처를 계획할 것

보안, 거버넌스 및 규정 준수 – 설계 개요

1. 암호화 및 키 관리 정의–설계 권장 사항

• 페더레이션된 Azure Key Vault 모델을 사용하여 트랜잭션 규모 제한을 회피할 것

• 삭제된 개체에 대한 보존 보호를 허용하도록 활성화된 일시 삭제 및 제거 정책으로 Azure Key Vault를 프로비저닝 함
• 키, 비밀 및 인증서를 영구적으로 삭제할 수 있는 권한을 특수 사용자 지정 Azure AD(Azure Active Directory) 역할로 제한하여 최소 권한 모델을 따름

• 공공 인증 기관과 함께 인증서 관리 및 갱신 프로세스를 자동화하여 관리를 용이하게 함

• 키 및 인증서 교체를 위한 자동화된 프로세스를 설정

• 자격 증명 모음에 대한 액세스를 제어하려면 자격 증명 모음에서 방화벽 및 가상 네트워크 서비스 엔드포인트를 사용하도록 설정함

• 플랫폼 중심 Azure Monitor Log Analytics 작업 영역을 사용하여 Key Vault의 각 인스턴스 내에서 키, 인증서 및 비밀 사용을 감사함
• Key Vault 인스턴스화 및 권한 있는 액세스를 위임하고 Azure Policy를 사용하여 일관된 호환 구성을 적용
• 보안 주체 암호화 기능을 위해 Microsoft에서 관리 하는 키를 기본값으로 사용하고 필요할 때 고객 관리 키를 사용

• 애플리케이션 키 또는 비밀에 대해 Key Vault의 중앙 집중식 인스턴스를 사용하지 말 것

• 환경 간에 비밀 공유를 방지하려면 애플리케이션 간에 Key Vault 인스턴스를 공유하지 말 것

2. 거버넌스 계획–설계 권장 사항

• 필요한 Azure 태그를 식별하고 추가 정책 모드를 사용하여 사용량을 적용함. 태깅 전략 문서를 출발점으로 사용
• 규정 및 규정 준수 요구 사항을 Azure Policy 정의 및 Azure 역할 할당에 매핑.
• 상속된 범위에서 할당할 수 있도록 최상위 루트 관리 그룹에서 Azure Policy 정의를 설정.
• 필요한 경우 최하위 수준에서 제외를 사용하여 가장 적합한 수준에서 정책 할당을 관리.
• Azure Policy를 사용하여 구독 및 관리 그룹 수준에서 리소스 공급자 등록을 제어.
• 기본 제공 정책을 사용하여 운영 오버헤드를 최소화
• 특정 범위에서 기본 제공 리소스 정책 기여자 역할을 할당하여 애플리케이션 수준 거버넌스를 활성화
• 상속 된 범위에서 제외를 통해 관리 하지 않도록 루트 관리 그룹 범위에서 수행 되는 Azure Policy 할당 수를 제한.

3. 모니터링 및 감사 정책 정의–설계 권장 사항

• Azure AD reporting 기능을 사용하여 액세스 제어 감사 보고서를 생성.
• 장기적인 데이터 보존을 위해 Azure 활동 로그를 Azure Monitor 로그로 내보냄. 필요한 경우 2 년 이상 장기 저장소에 대 한 Azure Storage로 Export.
• 모든 구독에 대해 Defender for Cloud 표준을 사용하도록 설정하고 Azure Policy를 사용 하여 규정 준수를 보장
• Azure Monitor 로그 및 Microsoft Defender for Cloud를 통해 기본 운영 체제 패치 드리프트를 모니터링
• Azure 정책을 사용하여 VM 확장을 통해 소프트웨어 구성을 자동으로 배포하고 규정을 준수하는 기준 VM 구성을 적용
• Azure Policy를 통해 VM 보안 구성 드리프트를 모니터링
• 기본 리소스 구성을 중앙 집중식 Azure Monitor Log Analytics 작업 영역에 연결

• 로그 지향 실시간 경고에 Azure Event Grid 기반 솔루션을 사용

4. 플랫폼 자동화–액세스 제어 설계 권장 사항

• 기본 요구사항의 맥락에서 각 필수 서비스에 대한 공동 검사를 수행. 자신의 키를 가져오려는 경우 고려된 모든 서비스에서 키가 지원되지 않을 수 있음. 불일치가 원하는 결과를 방해하지 않도록 관련 완화를 구현함. 지연 시간을 최소화하는 적절한 지역 쌍(region pairs)과 재해 복구 리전을 선택함
• 보안 구성, 모니터링 및 경고와 같은 서비스를 평가하기 위한 보안 허용 목록 계획을 개발. 그런 다음 기존 시스템과 통합할 계획을 세움
• 프로덕션으로 이동하기 전에 Azure 서비스에 대한 인시던트 대응 계획을 결정
• Azure 플랫폼 로드맵에 따라 보안 요구 사항을 조정하여 새로 출시된 보안 제어를 최신 상태로 유지
• 해당하는 경우 Azure 플랫폼에 대한 액세스를 위한 제로 트러스트 접근 방식을 구현

기타사항