Azure Enclave 모범 사례

이 문서에서는 Azure Enclave에 대한 주요 개념 및 모범 사례를 설명합니다.

Azure Enclave는 보안, 격리 및 규정 준수 클라우드 환경의 배포 및 관리를 가속화하고 간소화합니다. 이러한 환경은 상용 환경과 에어갭 환경 전반에서 가장 민감한 임무와 워크로드를 처리하도록 설계되었습니다.

Azure Enclave에서 워크로드를 성공적으로 빌드하고 실행하려면 다음을 비롯한 몇 가지 주요 개념을 이해하고 구현해야 합니다.

• 네트워킹 및 조직 디자인 패턴
• 보안 디자인 패턴
• 관리되는 리소스 그룹

Azure Enclave 제품 그룹, 엔지니어링 팀 및 현장 팀은 다음과 같은 모범 사례 및 개념 문서를 개발했습니다. 이 문서는 커뮤니티 및 Enclave 소유자 및 개발자가 중요한 개념을 더 잘 이해하고 적절한 기능을 구현하는 데 도움이 되도록 작성되었습니다.

Azure 설정

이러한 설정 단계를 읽고 이러한 구성 단계가 Azure Enclave 사용 사례에 적합한지 확인합니다.

Network Watcher 리소스 그룹 구성

가상 네트워크 흐름 로그 생성과 관련된 잠재적인 문제를 방지하려면 리소스 그룹을 미리 설정하고 NetworkWatcherRG 해당 리소스 그룹에 대한 역할을 앱 Mission Enclave 에 할당 Owner 하거나 구독에서 첫 번째 Enclave를 만들기 전에 설정 및 역할 할당이 자동으로 수행되었는지 확인합니다.

이 잠재적인 문제를 완화하려면 각 구독마다 새 구독에서 NetworkWatcherRG라는 NetworkWatcher 리소스 그룹을 수동으로 만든 다음, NetworkWatcherRG에 대해 Azure Enclave 앱에 Mission EnclaveOwner 권한을 부여합니다.

1. NetworkWatcherRG 리소스 그룹을 선택하고 Access control (IAM)을 선택한 다음, Add 및 Add role assignment을 선택합니다.

1. Privileged administrator roles을 선택하고, owner을 선택한 다음 Next을 선택합니다.

1. 를 선택하고Select members, 검색에 입력 Mission Enclave 하고, 앱을 선택하고Mission Enclave, 다음Select을 선택합니다Next.

1. 구독에 조건이 필요한 경우 Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended)을 선택한 다음 Review + assign을 선택합니다.

1. 업데이트가 완료되면 Azure Enclave 리소스 배포를 시작할 수 있습니다.

커뮤니티 또는 enclave를 만들 때 Azure Enclave는 다음 단계를 시도합니다.

1. NetworkWatcherRG이(가) 존재하는지 확인합니다. 그렇지 않은 경우 해당 리소스 그룹을 만들려고 시도합니다.
2. Mission Enclave에서 Owner 앱에 영구 NetworkWatcherRG 할당이 있는지 확인합니다. 그렇지 않은 경우 Mission Enclave 앱을 Owner에 영구 NetworkWatcherRG 할당으로 할당해 보세요. 상속된 Owner 사용 권한이 있더라도 영구 Owner 할당 만들기가 시도됩니다.
3. 단계가 실패하면 가상 네트워크 흐름 로그를 만들려고 할 때 enclave 배포가 실패할 수 있습니다.

Azure Enclave의 네트워킹 및 조직 디자인 패턴

멀티 테넌시

• 리소스를 구성하는 방법

네트워킹 디자인

Azure Enclave는 다음과 같은 간소화된 사용자 인터페이스에서 여러 Azure 네트워킹 제품의 기능과 유연성을 결합합니다.

• Azure 가상 WAN
• Azure Firewall
• Azure 가상 네트워크
• 네트워크 보안 그룹

Azure Enclave는 다음과 같은 전반적인 권장 사항을 제공합니다.

• Azure 지능형 방화벽 보안 Platform-as-a-Service인 Azure Firewall 제공하기 위한 네트워킹 요구 사항이 있는 경우 커뮤니티를 배포해야 합니다.
• 한 허브-스포크 Virtual WAN을 다른 허브-스포크 Virtual WAN과 분리해야 하는 조직상 요구 사항 또는 데이터 민감도 요구 사항이 있는 경우 커뮤니티를 배포하는 것이 좋습니다.
• 여러 Azure 지역에 걸친 시스템을 지원하기 위한 네트워킹 요구 사항이 있는 경우 커뮤니티를 배포해야 하며, 각 지역에는 자체 Azure Firewall 필요합니다. 다중 허브 Azure Firewall 사용 사례에 대해 자세히 알아봅니다.
• 분산형 허브 및 스포크 광역 네트워크에서 많은 수의 시스템을 지원하기 위한 네트워킹 요구 사항이 있는 경우 커뮤니티를 배포해야 합니다. Azure Virtual WAN 대해 자세히 알아보세요.
• 동일한 프라이빗 네트워크의 일부로 유사한 워크로드를 배포하기 위한 네트워킹 요구 사항이 있는 경우 Enclave를 배포해야 합니다.
• Enclave는 가상 네트워크가 필요하고 기존 커뮤니티와 동일한 Virtual WAN 내에 있는 워크로드 요구 사항이 있는 경우 배포되어야 합니다.

커뮤니티 네트워크 디자인 고려 사항

커뮤니티 네트워크를 계획할 때 가능한 경우 기본 Azure 서비스 모범 사례 설명서를 따라야 합니다. 다음 모범 사례를 포함합니다.

• Azure Firewall 모범 사례
• Azure Firewall 다중 허브 및 스포크
• 허브 및 스포크 Azure Virtual WAN 아키텍처
• Azure Virtual WAN 네트워크 토폴로지
• Azure Virtual WAN FAQ

Enclave 네트워크 디자인 고려 사항

enclave 네트워크를 계획할 때 가능한 경우 기본 Azure 서비스 모범 사례 설명서를 따라야 합니다. 다음 모범 사례를 포함합니다.

• Azure Virtual Network 개념 및 모범 사례
• 네트워크 보안 그룹 개요

전체 Azure 네트워킹 모범 사례에 대해 자세히 알아봅니다.

워크로드 배포

• 워크로드는 enclave 기여자가 Azure 리소스를 배포할 수 있는 관리되는 리소스 그룹에 연결됩니다.
• 기본적으로 모든 Azure Enclave 워크로드는 기본 제공 Azure Policy 이니셔티브를 통해 관리됩니다.
• 사용자 지정 거버넌스 설정이 있는 커뮤니티와 연결된 워크로드는 기본 Azure Enclave 거버넌스 구성 대신 이 고유한 구성을 사용합니다.
• Azure 리소스 이름 지정에 대한 고려 사항

Azure Enclave에 대한 보안 디자인 패턴

Azure Enclave 환경을 디자인할 때 이러한 보안 디자인 패턴을 고려합니다.

보안 경계

Azure Enclave는 사이버 보안과 관련하여 심층 방어 접근 방식을 사용합니다. 커뮤니티 및 enclave를 배포할 때 Azure Enclave는 네트워크 격리, 보안, 액세스 제어 및 로깅 및 모니터링의 여러 계층을 설정합니다.

공유 보안 책임

Azure 서비스인 Azure Enclave는 클라우드에서 공유 책임 모델을 유지하기 위해 최선을 다하고 있습니다. 특히 Azure Enclave의 경우 워크로드는 사용자의 책임입니다. Azure 공유 책임은 워크로드에 PaaS 서비스를 배포한 경우 워크로드에서 상속됩니다.

회원님의 커뮤니티와 엔클레이브는 공동의 책임을 의미합니다. 커뮤니티와 enclave는 Azure Enclave 리소스 공급자가 미리 구성된 보안 허브 및 스포크 네트워크 환경을 만드는 공유 책임 모델을 사용합니다. Enclave 엔드포인트, 커뮤니티 엔드포인트, 전송 허브 또는 Enclave 연결을 만들어 이 네트워크 환경을 관리합니다. 또한 특정 미리 보기 버전의 Azure Enclave를 사용하면 Azure Virtual WAN, Azure Virtual Network 및 기타 기본 Azure 네트워킹 서비스에서 제공하는 기본 컨트롤을 통해 네트워크를 수동으로 변경할 수 있습니다.

Azure Enclave 거버넌스도 공동의 책임입니다. Azure Enclave 리소스 공급자는 워크로드 배포당 미리 구성된 보안 Azure Policy 이니셔티브 목록을 만듭니다. 그러나 이제 커뮤니티는 워크로드에 대해 미리 구성된 목록을 재정의하는 커뮤니티 Azure Policy 이니셔티브를 사용자 지정할 수 있습니다. 정책 요구 사항에도 불구하고 규정 준수 또는 거버넌스 요구 사항에 따라 이러한 Azure Policy 이니셔티브 할당을 수동으로 면제할 수 있는 기능이 유지됩니다.

Azure 보안 모범 사례

Azure Enclave는 Azure 리소스를 배포하고 워크로드를 구현하기 위한 Microsoft Azure 보안 모범 사례 및 패턴을 따르는 것이 좋습니다.

시스템, 클라우드 인프라, IT 담당자 및 팀 구조, 기업 사이버 보안 인식 교육을 구성하기 위한 클라우드 채택 프레임워크 Azure 보안 모범 사례를 따라야 합니다.

도메인 이름 시스템을 통한 데이터 반출

DNS(Domain Name System)를 통한 데이터 반출은 일반적으로 방화벽을 통해 허용되고 악의적인 활동에 대해 거의 모니터링되지 않는 프로토콜을 사용하므로 조직에 중요한 보안 문제를 나타냅니다. 공격자는 DNS 쿼리를 악용하여 도메인 이름 내에서 정보를 인코딩하거나 DNS 터널링 기술을 사용하여 손상된 시스템에서 중요한 데이터를 은밀하게 추출할 수 있습니다. 이 방법은 DNS 트래픽이 정상적인 것처럼 보이고 기존의 보안 모니터링 도구를 우회하는 경우가 많기 때문에 은밀합니다.

DNS 기반 데이터 반출 공격에서 악의적인 행위자는 종종 하위 도메인 레이블 지정 또는 TXT 레코드 쿼리와 같은 기술을 사용하여 도난당한 데이터를 DNS 쿼리로 인코딩합니다. 예를 들어 공격자는 중요한 데이터를 청크로 분할하고 각 청크를 DNS 쿼리의 하위 도메인으로 공격자 제어 도메인에 포함할 수 있습니다. 공격자의 DNS 서버의 DNS 로그에서 데이터를 추출할 수 있습니다. 이 방법을 사용하면 DNS 쿼리가 일반 이름 확인 요청으로 표시되므로 낮은 프로필을 유지하면서 큰 데이터 세트를 점진적으로 반출할 수 있습니다.

Azure DNS 보안 정책을 사용하여 데이터 반출 해결

Azure DNS 보안 정책은 Azure Virtual Network 내에서 DNS 트래픽에 대한 세분화된 제어를 제공하여 DNS 기반 데이터 반출 공격에 대한 포괄적인 보호를 제공합니다. 이 서비스를 사용하면 조직은 데이터가 성공적으로 유출되기 전에 의심스러운 DNS 활동을 감지하고, 경고를 생성하며, 차단할 수 있는 선제적 보안 조치를 구현할 수 있습니다.

Azure DNS 보안 정책은 여러 주요 메커니즘을 통해 DNS 데이터 반출을 해결합니다. 먼저, 알려진 악성 도메인 또는 반출 시도에서 일반적으로 사용되는 의심스러운 도메인 패턴에 대한 쿼리를 차단할 수 있는 DNS 트래픽 규칙을 만드는 기능을 제공합니다. 조직은 명령 및 제어 인프라 또는 데이터 반출 서비스와 연결된 도메인의 차단 목록을 유지할 수 있습니다. 둘째, 서비스는 보호된 가상 네트워크 내에서 모든 DNS 쿼리 및 응답을 캡처하는 포괄적인 DNS 로깅 기능을 제공합니다. 이 로깅을 사용하면 보안 팀이 DNS 트래픽 패턴을 분석하고 잠재적인 반출 시도를 식별할 수 있습니다. 셋째, 정책 엔진은 조직에서 의심스러운 도메인의 전체 범주를 차단하거나 승인된 DNS 대상에 대한 허용 목록을 구현할 수 있도록 와일드카드 도메인 필터링을 지원합니다.

Azure DNS 보안 정책을 구현하면 DNS 데이터 반출에 대해 여러 계층의 방어가 생성됩니다. 트래픽 규칙은 다양한 우선 순위 수준으로 구성할 수 있으므로 보안과 운영 요구 사항의 균형을 맞추는 복잡한 보안 정책을 사용할 수 있습니다. 이 서비스는 법의학 분석 및 위협 헌팅에 대한 자세한 로그를 제공하면서 악의적인 쿼리의 실시간 차단을 지원합니다. 또한 가상 네트워크 링크는 DNS 보안 정책이 보호된 네트워크 세그먼트 내의 모든 리소스에 일관되게 적용되어 공격자가 우회하기 어려운 포괄적인 보안 경계를 만듭니다.

Azure Enclave 배포의 경우 Azure DNS 보안 정책을 전체 보안 아키텍처의 일부로 통합해야 합니다. 조직은 Enclave 워크로드의 DNS 트래픽을 모니터링하고 제어하도록 DNS 보안 정책을 구성하여 개별 워크로드가 손상되더라도 중요한 데이터를 보호해야 합니다. DNS 로그의 지속적인 모니터링과 결합된 DNS 도메인 목록의 정기적인 검토 및 업데이트는 진화하는 DNS 기반 위협에 대한 지속적인 보호를 제공하고 Azure Enclave 환경의 보안 무결성을 유지하는 데 도움이 됩니다.

자세한 내용은 DNS 보안 정책 설명서에서 확인할 수 있습니다.

기본 DNS 보안 정책 거부 구현

Azure Enclave 환경에서 보안을 최대화하려면 조직은 DNS 필터링에 대해 "기본적으로 거부, 예외 허용" 접근 방식을 구현해야 합니다. 이 보안 모델은 명시적으로 허용되지 않는 한 모든 DNS 쿼리가 차단되도록 하여 DNS 기반 데이터 반출 및 명령 및 제어 통신에 대해 가장 강력한 보호를 제공합니다.

기본적으로 거부 방법은 Azure DNS 보안 정책 내에서 2계층 DNS 규칙 구조를 사용하여 구현됩니다.

1단계: 기본 거부 규칙 만들기 루트 도메인(점)만 포함하는 DNS 도메인 . 목록을 만듭니다. 이 와일드카드 도메인은 가능한 모든 DNS 쿼리와 일치합니다. 다음으로 구성된 DNS 트래픽 규칙에 이 도메인 목록을 연결합니다.

• 우선 순위: 65000(가장 낮은 우선 순위)
• 동작: 차단
• 도메인 목록: 루트 도메인(.)

이 규칙은 우선 순위가 높은 규칙에서 명시적으로 허용되지 않는 모든 DNS 쿼리를 차단하는 catch-all 역할을 합니다.

2단계: 허용 목록 규칙 만들기 합법적인 비즈니스 작업에 필요한 특정 도메인을 포함하는 별도의 DNS 도메인 목록을 만듭니다. 여기에는 다음이 포함될 수 있습니다.

• 필수 Azure 서비스(예: *.azure.com, *.microsoft.com)
• 회사 도메인 및 신뢰할 수 있는 Microsoft 이외의 서비스
• 운영 체제 업데이트 서비스
• 인증 기관 도메인

다음으로 구성된 DNS 트래픽 규칙에 허용 목록을 연결합니다.

• 우선 순위: 500-1000(기본 거부보다 높은 우선 순위)
• 작업: 허용
• 도메인 목록: 특정 승인된 도메인

우선 순위 기반 규칙 처리 Azure DNS 보안 정책은 규칙을 우선 순위 순서로 처리합니다(낮은 숫자 = 더 높은 우선 순위). DNS 쿼리가 수행되는 경우:

1. 시스템은 우선 순위가 높은 허용 규칙(우선 순위 500-1000)을 먼저 평가합니다.
2. 도메인이 허용 목록과 일치하면 쿼리가 허용됩니다.
3. 일치하는 규칙이 없 allow 으면 쿼리가 기본 거부 규칙(우선 순위 65000)으로 넘어가고 트래픽이 차단됩니다.

이 방법은 다음과 같은 몇 가지 보안 이점을 제공합니다.

• 제로 트러스트 모델: 명시적으로 권한이 부여되지 않는 한 DNS 쿼리가 허용되지 않습니다.
• 세분화된 제어: 조직은 액세스할 수 있는 도메인을 정확하게 제어할 수 있습니다.
• 감사 내역: 차단된 모든 쿼리가 기록되어 잠재적인 위협에 대한 가시성을 제공합니다.
• 증분 업데이트: 기본 거부 규칙을 수정하지 않고 목록을 허용하도록 승인된 새 도메인을 추가할 수 있습니다.

구현 예:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

이 방법을 구현하는 조직은 필요한 도메인의 포괄적인 인벤토리로 시작하고 운영 요구 사항 및 보안 로그에 따라 허용된 도메인 목록을 점진적으로 구체화해야 합니다. 차단된 쿼리를 정기적으로 검토하면 강력한 보안 상태를 유지하면서 허용 목록에 추가해야 할 수 있는 합법적인 도메인을 식별할 수 있습니다.

Windows DNS 서버를 사용하여 기본 DNS 거부 정책 구현

Azure DNS 보안 정책을 활용할 수 없거나 온-프레미스 DNS 제어가 필요한 환경의 경우 DNS 정책 기능이 있는 Windows DNS 서버를 사용하여 유사한 기본 거부 보안을 구현할 수 있습니다. 이 방법은 기존 Windows 인프라와의 호환성을 유지하면서 DNS 기반 데이터 반출에 대해 유사한 보호를 제공합니다.

Windows DNS 서버(Windows Server 2016 이상)는 조직에서 정교한 DNS 필터링 규칙을 구현할 수 있도록 하는 DNS 정책 기능을 지원합니다. 기본 거부 모델은 DNS 정책 규칙 과 영역 구성의 조합을 통해 달성할 수 있습니다.

Azure Enclave의 관리되는 리소스 그룹

Azure Enclave에서 관리하는 리소스를 포함하는 리소스 그룹입니다.

커뮤니티 관리 리소스 그룹

커뮤니티 관리 리소스 그룹에는 커뮤니티란?에 설명된 인프라 리소스가 포함되어 있습니다.

커뮤니티 관리 리소스 그룹 이름은 다음 명명 규칙을 myCommunityName-HostedResources-<GUID>따릅니다. 모든 커뮤니티 배포는 이 리소스 그룹을 만들고 그 안에 커뮤니티 인프라를 배치합니다. 커뮤니티를 삭제하면 Azure Enclave 리소스 공급자가 커뮤니티 관리 리소스 그룹을 자동으로 삭제합니다.

커뮤니티 관리 리소스 그룹에는 다음과 같은 제한 사항이 있습니다.

• 커뮤니티 관리 리소스 그룹에 대한 기존 리소스 그룹을 지정할 수 없습니다.
• 커뮤니티 관리 리소스 그룹에 대해 다른 구독을 지정할 수 없습니다.
• 커뮤니티를 만든 후에는 커뮤니티 관리 리소스 그룹 이름을 변경할 수 없습니다.
• 커뮤니티 관리 리소스 그룹 내에서 관리되는 리소스의 이름을 지정할 수 없습니다.
• 커뮤니티 관리 리소스 그룹 내에서 관리되는 리소스의 Azure 만든 태그를 수정하거나 삭제할 수 없습니다.

커뮤니티 관리되는 리소스 그룹에서 Azure 만든 태그, 리소스 및 기타 리소스 속성을 수정하거나 삭제하면 예기치 않은 결과가 표시됩니다. Azure Enclave가 커뮤니티 관리 리소스 그룹에서 인프라의 수명 주기를 관리함에 따라 변경 내용으로 인해 enclave가 지원되지 않는 상태로 전환될 수 있습니다.

리소스를 수정하려는 일반적인 시나리오는 태그를 통해서입니다. Azure Enclave를 사용하면 커뮤니티 관리 리소스 그룹의 리소스에 전파되는 태그를 만들고 수정할 수 있습니다. 예를 들어, 비즈니스 부서나 비용 센터를 지정하기 위해 사용자 지정 태그를 생성하거나 수정하고 싶을 수 있습니다. 커뮤니티 관리 리소스 그룹에 범위가 있는 Azure 정책을 만들어서 이 작업을 수행할 수도 있습니다.

메모

커뮤니티 관리 리소스 그룹 잠금을 사용하도록 설정하지 않은 경우 커뮤니티 관리 리소스 그룹의 리소스를 직접 수정할 수 있습니다. 커뮤니티 관리 리소스 그룹에서 리소스를 직접 수정하면 enclave가 불안정해지거나 응답하지 않게 될 수 있습니다.

Enclave의 관리되는 리소스 그룹

Enclave 관리되는 리소스 그룹에는 Enclave란?에 설명된 인프라 리소스가 포함되어 있습니다.

enclave 관리되는 리소스 그룹 이름은 다음 명명 규칙을 myEnclaveName-HostedResources-<GUID>따릅니다. 모든 Enclave 배포는 이 리소스 그룹을 만들고 그 안에 Enclave 인프라를 배치합니다. enclave를 삭제하면 Azure Enclave 리소스 공급자가 enclave 관리 리소스 그룹을 자동으로 삭제합니다.

enclave 관리되는 리소스 그룹에는 다음과 같은 제한 사항이 있습니다.

• enclave 관리되는 리소스 그룹에 대한 기존 리소스 그룹을 지정할 수 없습니다.
• Enclave 관리 리소스 그룹에 대해 다른 구독을 지정할 수 없습니다.
• enclave를 만든 후에는 enclave 관리 리소스 그룹 이름을 변경할 수 없습니다.
• Enclave 관리되는 리소스 그룹 내에서 관리되는 리소스의 이름을 지정할 수 없습니다.
• enclave 관리되는 리소스 그룹 내에서 관리되는 리소스의 Azure 만든 태그를 수정하거나 삭제할 수 없습니다.

enclave 관리 리소스 그룹에서 Azure 만든 태그, 리소스 및 기타 리소스 속성을 수정하거나 삭제하는 경우 네트워크, 액세스 및 모니터링 오류와 같은 예기치 않은 결과를 얻을 수 있습니다. Azure Enclave가 Enclave 관리 리소스 그룹의 인프라 수명 주기를 관리하므로 변경 내용이 변경되면 enclave를 지원되지 않는 상태로 전환할 수 있습니다.

리소스를 수정하려는 일반적인 시나리오는 태그를 통해서입니다. Azure Enclave를 사용하면 enclave 관리되는 리소스 그룹의 리소스에 전파되는 태그를 만들고 수정할 수 있습니다. 예를 들어, 비즈니스 부서나 비용 센터를 지정하기 위해 사용자 지정 태그를 생성하거나 수정하고 싶을 수 있습니다. enclave 관리되는 리소스 그룹에 범위가 있는 Azure 정책을 만들어 리소스 태그 지정을 수행할 수도 있습니다.

Warning

Enclave 관리되는 리소스 그룹에서 리소스를 수정하면 Enclave가 불안정하거나 응답하지 않게 될 수 있습니다.

워크로드 리소스 그룹

워크로드는 Azure 리소스를 만들고 구성할 수 있는 하나 이상의 리소스 그룹에 연결됩니다.

워크로드에 리소스 그룹 추가

일반적으로 새 리소스 그룹을 추가하려면 사용자에게 새 리소스 그룹을 만들 수 있는 권한이 있어야 합니다. 구독 Owner 또는 Contributor 역할에는 이 권한이 있지만 워크로드 리소스 그룹을 만드는 사용자에게는 이 권한 있는 권한이 없거나 필요하지 않을 수 있습니다. Azure Enclave는 사용자에게 유연성을 제공하는 가장 높은 사용자 권한 요구 사항에서 가장 낮은 사용자 권한 요구 사항에 이르기까지 새 리소스 그룹을 만드는 세 가지 방법을 시도합니다.

• 옵션 1: 워크로드를 만들거나 업데이트하는 개인에게 가장 권한 있는 권한이 필요하므로 모든 권한을 제공하지만 상승된 액세스가 필요합니다.
• 옵션 2: 사용자가 구독 수준에서 애플리케이션 소유권을 부여Mission Enclave하도록 수동으로 설정해야 하며, 이는 기본 설정에 맞지 않을 수 있습니다.
• 옵션 3: 사용자 또는 Mission Enclave 애플리케이션에 대한 권한이 필요하지 않으므로 가장 쉬운 방법이지만 리소스 그룹과 워크로드 간에 엄격한 1:1 관계를 적용합니다.

각 옵션에는 다양한 요구 사항에 맞게 제어, 편리성 및 유연성의 균형을 맞추는 이점과 제한 사항이 있습니다. 이러한 옵션은 각각 옵션 1부터 평가되며 첫 번째 성공 옵션은 새 리소스 그룹을 만드는 데 사용됩니다.

옵션 3을 사용하여 하나의 워크로드 리소스 그룹을 만든 후에는 해당 워크로드의 다음 워크로드 리소스 그룹에 옵션 3을 사용할 수 없다는 경고가 표시됩니다. 옵션 3을 다시 사용하여 새 워크로드를 만든 다음 새 워크로드 리소스 그룹을 만들 수도 있습니다.

enclave에 리소스 그룹을 추가합니다.

1. 워크로드에 대한 Azure 포털 페이지를 엽니다.
2. Manage을 선택한 다음 Resource Groups을 선택합니다.
3. Add a resource group를 선택합니다.
4. 열리는 Create new 측면 창에서 빈 새 리소스 그룹의 이름을 제공하거나 드롭다운을 선택하여 Resource Group 기존 리소스 그룹을 선택합니다.
5. OK을 선택한 다음 Save을 선택합니다.

워크로드 리소스 그룹은 다른 Azure 리소스 그룹과 어떻게 다른가요?

워크로드 리소스 그룹은 중요한 리소스가 만들어지는 위치이기 때문에 Azure Enclave 보안 및 규정 준수의 중요한 구성 요소입니다. 이러한 워크로드 리소스 그룹은 워크로드에 연결되고 워크로드는 enclave에 연결되므로 Azure Enclave는 워크로드 관리되는 리소스 그룹의 삭제를 관리합니다.

또한 정책은 워크로드 리소스 그룹에 적용됩니다. 커뮤니티 정책이 enclave로 흐르는 방식과 마찬가지로 Enclave 정책은 워크로드 리소스 및 워크로드 리소스 그룹으로 전달됩니다. 새 워크로드 리소스 그룹을 만들 때 역할은 enclave 수준에서 설정되고 구독에서 상속됩니다. 이러한 정책 중 일부는 커뮤니티로부터 상속되며, 워크로드와 워크로드 리소스 그룹에 적용되는 정책을 enclave에 생성할 수도 있습니다.

워크로드 리소스 그룹에서 리소스 구성

리소스를 두 개의 리소스 그룹으로 분할하려는 경우 다음 옵션 중 하나를 선택할 수 있습니다.

• 하나의 워크로드에 연결된 두 리소스 그룹 간에 해당 리소스 분할
• 각각 하나 이상의 리소스 그룹이 있는 두 워크로드 간에 해당 리소스 분할

워크로드 삭제

워크로드 삭제가 요청되면 워크로드 리소스 그룹이 비어 있는지 확인합니다. 워크로드 리소스 그룹에 리소스가 포함된 경우 요청된 워크로드 삭제가 실패하고 오류가 표시됩니다. 워크로드 및 워크로드 리소스 그룹을 삭제하려면 먼저 워크로드 리소스 그룹을 비웁니다. 빈 워크로드 리소스 그룹을 사용하면 중요한 리소스가 실수로 삭제되는 것을 방지할 수 있습니다.

워크로드에 연결된 리소스의 삭제는 동일한 동작을 따릅니다. 예를 들어 커뮤니티 삭제가 요청되었지만 모든 워크로드 리소스 그룹이 비어 있지 않으면 작업에 오류가 표시됩니다. 워크로드 리소스 그룹을 비우고 다시 시도합니다.

워크로드 관리 리소스 그룹에는 다음과 같은 제한 사항이 있습니다.

• 워크로드 관리되는 리소스 그룹에 대한 기존 리소스 그룹을 지정할 수 없습니다.
• 워크로드 관리되는 리소스 그룹에 대해 다른 구독을 지정할 수 없습니다.
• 워크로드를 만든 후에는 워크로드 관리 리소스 그룹 이름을 변경할 수 없습니다.
• 워크로드 관리되는 리소스 그룹 내에서 관리되는 리소스의 Azure 만든 태그를 수정하거나 삭제할 수 없습니다.

리소스를 수정하려는 일반적인 시나리오는 태그를 통해서입니다. Azure Enclave를 사용하면 워크로드 관리되는 리소스 그룹의 리소스에 전파되는 태그를 만들고 수정할 수 있습니다. 예를 들어, 비즈니스 부서나 비용 센터를 지정하기 위해 사용자 지정 태그를 생성하거나 수정하고 싶을 수 있습니다. 워크로드 관리되는 리소스 그룹에 범위가 있는 Azure 정책을 만들어 태그 지정을 수행할 수도 있습니다.

기타 Azure 모범 사례

Azure 커뮤니티, enclave 및 워크로드를 빌드할 때는 다음과 같은 범용 디자인 원칙을 염두에 두어야 합니다.

• Azure 네트워킹 아키텍처 디자인
• Azure의 허브-스포크 네트워크 토폴로지
• 허브 및 스포크 네트워크의 Azure Private Link
• Azure Firewall - 잘 설계된 프레임워크
• Azure 리소스 이름 지정에 대한 고려 사항
• Microsoft Azure 보안 모범 사례 및 패턴