세분화 전략을 빌드하기 위한 권장 사항
Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.
| SE:04 | 아키텍처 디자인 및 플랫폼의 워크로드 공간에서 의도적인 세분화 및 경계를 만듭니다. 세분화 전략에는 네트워크, 역할 및 책임, 워크로드 ID 및 리소스 organization 포함되어야 합니다. |
|---|
세그먼트는 하나의 단위로 보호해야 하는 솔루션의 논리적 섹션입니다. 구분 전략은 고유한 보안 요구 사항 및 측정값 집합을 사용하여 한 단위를 다른 단위와 분리하는 방법을 정의합니다.
이 가이드에서는 통합 세분화 전략을 빌드하기 위한 권장 사항을 설명합니다. 워크로드에서 경계 및 격리 경계를 사용하여 적합한 보안 접근 방식을 설계할 수 있습니다.
정의
| 용어 | 정의 |
|---|---|
| Containment | 공격자가 세그먼트에 대한 액세스 권한을 얻는 경우 폭발 반경을 포함하는 기술입니다. |
| 최소 권한 액세스 | 작업 기능을 완료하기 위한 사용 권한 집합을 최소화하는 것을 목표로 하는 제로 트러스트 원칙입니다. |
| 경계 | 세그먼트 주변의 신뢰 경계입니다. |
| 리소스 조직 | 세그먼트 내의 흐름별로 관련 리소스를 그룹화하기 위한 전략입니다. |
| 역할 | 작업 함수를 완료하는 데 필요한 권한 집합입니다. |
| Segment | 다른 엔터티로부터 격리되고 보안 조치 집합으로 보호되는 논리 단위입니다. |
주요 디자인 전략
세분화 개념은 일반적으로 네트워크에 사용됩니다. 그러나 관리 목적 및 액세스 제어를 위해 리소스를 분할하는 것을 포함하여 솔루션 전체에서 동일한 기본 원칙을 사용할 수 있습니다.
세분화는 제로 트러스트 모델의 원칙에 따라 심층 방어를 적용하는 보안 접근 방식을 설계하는 데 도움이 됩니다. 한 네트워크 세그먼트를 위반하는 공격자가 다른 ID 컨트롤을 사용하여 워크로드를 분할하여 다른 네트워크 세그먼트에 액세스할 수 없도록 합니다. 보안 시스템에서 ID 및 네트워크 특성은 무단 액세스를 차단하고 자산이 노출되지 않도록 숨깁니다. 다음은 세그먼트의 몇 가지 예입니다.
- organization 워크로드를 격리하는 구독
- 워크로드 자산을 격리하는 리소스 그룹
- 단계별로 배포를 격리하는 배포 환경
- 워크로드 개발 및 관리와 관련된 작업 기능을 격리하는 팀 및 역할
- 워크로드 유틸리티로 격리하는 애플리케이션 계층
- 한 서비스를 다른 서비스와 격리하는 마이크로 서비스
세분화의 이러한 주요 요소를 고려하여 포괄적인 심층 방어 전략을 구축하고 있는지 확인합니다.
경계 또는 경계는 보안 컨트롤을 적용하는 세그먼트의 진입 가장자리입니다. 경계 컨트롤은 명시적으로 허용되지 않는 한 세그먼트에 대한 액세스를 차단해야 합니다. 목표는 공격자가 경계를 돌파하고 시스템을 제어하는 것을 방지하는 것입니다. 예를 들어 애플리케이션 계층은 요청을 처리할 때 최종 사용자의 액세스 토큰을 수락할 수 있습니다. 그러나 데이터 계층에는 애플리케이션 계층만 요청할 수 있는 특정 권한이 있는 다른 액세스 토큰이 필요할 수 있습니다.
포함 은 시스템에서 횡적 이동을 방지하는 세그먼트의 종료 가장자리입니다. 포함의 목표는 위반의 영향을 최소화하는 것입니다. 예를 들어 Azure 가상 네트워크를 사용하여 예상되는 트래픽 패턴만 허용하도록 라우팅 및 네트워크 보안 그룹을 구성하여 임의의 네트워크 세그먼트에 대한 트래픽을 방지할 수 있습니다.
격리 는 유사한 보증을 사용하여 엔터티를 경계로 보호하기 위해 함께 그룹화하는 방법입니다. 목표는 관리의 용이성과 환경 내의 공격을 억제하는 것입니다. 예를 들어 특정 워크로드와 관련된 리소스를 하나의 Azure 구독으로 그룹화한 다음 특정 워크로드 팀만 구독에 액세스할 수 있도록 액세스 제어를 적용할 수 있습니다.
경계와 격리를 구분하는 것이 중요합니다. 경계는 확인해야 하는 위치의 지점을 나타냅니다. 격리는 그룹화에 관한 것입니다. 이러한 개념을 함께 사용하여 공격을 적극적으로 포함합니다.
격리가 organization 사일로를 만드는 것을 의미하지는 않습니다. 통합 세분화 전략은 기술 팀 간의 맞춤을 제공하고 명확한 책임 라인을 설정합니다. Clarity 보안 취약성, 운영 가동 중지 시간 또는 둘 다로 이어질 수 있는 사용자 오류 및 자동화 오류의 위험을 줄입니다. 복잡한 엔터프라이즈 시스템의 구성 요소에서 보안 위반이 감지되었다고 가정합니다. 적절한 사람이 심사 팀에 포함되도록 모든 사람이 해당 리소스에 대한 책임이 있는 사람을 이해하는 것이 중요합니다. organization 및 관련자는 좋은 구분 전략을 만들고 문서화하여 다양한 종류의 인시던트에 대응하는 방법을 신속하게 식별할 수 있습니다.
절충: 세분화는 관리에 오버헤드가 있기 때문에 복잡성을 발생합니다. 비용의 절충도 있습니다. 예를 들어 나란히 실행되는 배포 환경이 분할될 때 더 많은 리소스가 프로비전됩니다.
위험: 합리적인 제한을 초과하는 마이크로 세분화는 격리의 이점을 상실합니다. 세그먼트를 너무 많이 만들면 통신 지점을 식별하거나 세그먼트 내에서 유효한 통신 경로를 허용하기가 어려워집니다.
경계로서의 ID
사람, 소프트웨어 구성 요소 또는 디바이스와 같은 다양한 ID는 워크로드 세그먼트에 액세스합니다. ID는 액세스 요청이 시작되는 위치에 관계없이 격리 경계를 넘어 액세스를 인증하고 권한을 부여하기 위한 기본 방어선이어야 하는 경계입니다. ID를 경계로 사용하여 다음을 수행합니다.
역할별로 액세스 권한을 할당합니다. ID는 작업을 수행하는 데 필요한 세그먼트에만 액세스하면 됩니다. 세그먼트에 대한 액세스를 요청하는 엔터티와 용도를 알 수 있도록 요청 ID의 역할 및 책임을 이해하여 익명 액세스를 최소화합니다.
ID는 서로 다른 세그먼트에서 서로 다른 액세스 범위를 가질 수 있습니다. 각 스테이지에 대해 별도의 세그먼트가 있는 일반적인 환경 설정을 고려합니다. 개발자 역할과 연결된 ID에는 개발 환경에 대한 읽기-쓰기 액세스 권한이 있습니다. 배포가 스테이징으로 이동하면 해당 권한이 억제됩니다. 워크로드가 프로덕션으로 승격될 때까지 개발자를 위한 scope 읽기 전용 액세스로 줄어듭니다.
애플리케이션 및 관리 ID를 별도로 고려합니다. 대부분의 솔루션에서 사용자는 개발자 또는 운영자와 다른 수준의 액세스 권한을 갖습니다. 일부 애플리케이션에서는 각 ID 유형에 대해 서로 다른 ID 시스템 또는 디렉터리를 사용할 수 있습니다. 액세스 범위를 사용하고 각 ID에 대해 별도의 역할을 만드는 것이 좋습니다.
최소 권한 액세스를 할당합니다. ID에 액세스가 허용되는 경우 액세스 수준을 결정합니다. 각 세그먼트에 대한 최소 권한으로 시작하고 필요한 경우에만 해당 scope 확장합니다.
최소 권한을 적용하면 ID가 손상된 경우 부정적인 영향을 제한할 수 있습니다. 시간이 지나면 액세스가 제한되면 공격 표면이 더 줄어듭니다. 시간 제한 액세스는 특히 손상된 ID가 있는 관리자 또는 소프트웨어 구성 요소와 같은 중요한 계정에 적용할 수 있습니다.
RBAC(역할 기반 액세스 제어)도 관리 오버헤드를 발생합니다. ID 및 해당 액세스 범위를 추적하는 것은 역할 할당에서 복잡해질 수 있습니다. 해결 방법은 개별 ID 대신 보안 그룹에 역할을 할당하는 것입니다.
ID 컨트롤에 대한 자세한 내용은 ID 및 액세스 관리를 참조하세요.
네트워크 액세스 제어와 달리 ID는 액세스 시 액세스 제어의 유효성을 검사합니다. 정기적인 액세스 검토를 수행하고 중요한 영향 계정에 대한 권한을 얻으려면 승인 워크플로를 요구하는 것이 좋습니다. 예를 들어 ID 구분 패턴을 참조하세요.
경계로서의 네트워킹
ID 경계는 네트워크에 구애받지 않지만 네트워크 경계는 ID를 보강하지만 대체하지는 않습니다. 네트워크 경계는 폭발 반경을 제어하고, 예기치 않은, 금지된 안전하지 않은 액세스를 차단하고, 워크로드 리소스를 난독 처리를 위해 설정됩니다.
ID 경계의 주요 초점은 최소 권한이지만 네트워크 경계를 디자인할 때 위반이 있다고 가정해야 합니다.
Azure 서비스 및 기능을 사용하여 네트워킹 공간의 소프트웨어 정의 경계를 만듭니다. 워크로드(또는 지정된 워크로드의 일부)가 별도의 세그먼트에 배치되면 통신 경로를 보호하기 위해 해당 세그먼트 간 트래픽을 제어합니다. 세그먼트가 손상된 경우 해당 세그먼트는 네트워크의 나머지 부분을 통해 횡적으로 확산되지 않도록 포함되고 방지됩니다.
공격자처럼 워크로드 내에서 발판을 마련하고 추가 확장을 최소화하기 위한 제어를 설정합니다. 컨트롤은 공격자가 전체 워크로드에 액세스하지 못하도록 검색, 포함 및 중지해야 합니다. 다음은 네트워크 컨트롤을 경계로 사용하는 몇 가지 예입니다.
- 공용 네트워크와 워크로드가 배치된 네트워크 간에 에지 경계를 정의합니다. 공용 네트워크에서 네트워크로 시야를 최대한 제한합니다.
- 방화벽을 통해 적절한 컨트롤을 사용하여 애플리케이션 앞에 DMZ(비무장 영역)를 구현합니다.
- 워크로드의 일부를 별도의 세그먼트로 그룹화하여 프라이빗 네트워크 내에서 마이크로 구분을 만듭니다. 보안 통신 경로를 설정합니다.
- 의도에 따라 경계를 만듭니다. 예를 들어 운영 네트워크에서 워크로드 기능 네트워크를 분할합니다.
네트워킹 구분과 관련된 일반적인 패턴은 네트워킹 구분 패턴을 참조하세요.
프라이빗 연결은 아키텍처 디자인을 변경하며, 종종 컴퓨팅 노드에 대한 프라이빗 액세스를 위한 점프 상자와 같은 구성 요소를 더 추가합니다.
네트워크 경계는 네트워크에서 제어 지점 또는 홉을 기반으로 하므로 각 홉은 잠재적인 실패 지점이 될 수 있습니다. 이러한 점은 시스템의 안정성에 영향을 미칠 수 있습니다.
네트워크 제어에 대한 자세한 내용은 네트워킹 및 연결을 참조하세요.
역할 및 책임
혼란과 보안 위험을 방지하는 세분화는 워크로드 팀 내에서 책임 라인을 명확하게 정의하여 달성됩니다.
역할 및 기능을 문서화하고 공유하여 일관성을 만들고 통신을 용이하게 합니다. 키 함수를 담당하는 그룹 또는 개별 역할을 지정합니다. 개체에 대한 사용자 지정 역할을 만들기 전에 Azure에서 기본 제공 역할을 고려합니다.
세그먼트에 대한 권한을 할당할 때 여러 조직 모델을 수용하면서 일관성을 고려합니다. 이러한 모델은 단일 중앙 집중식 IT 그룹에서 대부분 독립적인 IT 및 DevOps 팀에 이르기까지 다양할 수 있습니다.
리소스 조직
분할을 사용하면 워크로드 리소스를 organization 다른 부분이나 팀 내에서 격리할 수 있습니다. 관리 그룹, 구독, 환경 및 리소스 그룹과 같은 Azure 구문은 구분을 촉진하는 리소스를 구성하는 방법입니다. 리소스 수준 격리의 몇 가지 예는 다음과 같습니다.
- 다각형 지속성에는 분할을 지원하기 위해 단일 데이터베이스 시스템 대신 데이터 저장 기술의 조합이 포함됩니다. 다양한 데이터 모델별 분리, 데이터 스토리지 및 분석과 같은 기능 분리 또는 액세스 패턴으로 구분하려면 다각형 지속성을 사용합니다.
- 컴퓨팅을 구성할 때 각 서버에 대해 하나의 서비스를 할당합니다. 이 격리 수준은 복잡성을 최소화하고 공격을 포함하는 데 도움이 될 수 있습니다.
- Azure는 일부 서비스에 대한 기본 제공 격리를 제공합니다(예: 스토리지에서 컴퓨팅 분리). 다른 예제는 Azure 퍼블릭 클라우드에서 격리를 참조하세요.
Azure 촉진
다음 섹션에 설명된 대로 특정 Azure 서비스는 구분 전략을 구현하는 데 사용할 수 있습니다.
ID
Azure RBAC는 작업 함수별로 액세스를 격리하여 구분을 지원합니다. 특정 역할 및 범위에 대해 특정 작업만 허용됩니다. 예를 들어 시스템을 관찰하기만 하면 되는 작업 함수에는 ID가 리소스를 관리할 수 있는 기여자 권한과 판독기 권한을 할당할 수 있습니다.
자세한 내용은 RBAC 모범 사례를 참조하세요.
네트워킹
가상 네트워크: 가상 네트워크는 두 가상 네트워크 간에 트래픽을 추가하지 않고도 네트워크 수준 리소스를 포함합니다. 가상 네트워크는 구독 내의 개인 주소 공간에 만들어집니다.
NSG(네트워크 보안 그룹): 가상 네트워크의 리소스와 인터넷과 같은 외부 네트워크 간의 트래픽을 제어하기 위한 액세스 제어 메커니즘입니다. UDR(사용자 정의 경로)을 구현하여 트래픽에 대한 다음 홉을 제어합니다. NSG는 서브넷, VM(가상 머신) 또는 VM 그룹에 대한 경계를 만들어 세분화 전략을 세분화 수준으로 끌어올 수 있습니다. Azure에서 서브넷을 사용하는 가능한 작업에 대한 자세한 내용은 서브넷을 참조하세요.
ASG(애플리케이션 보안 그룹) : ASG를 사용하면 애플리케이션 태그 아래에 VM 집합을 그룹화하고 각 기본 VM에 적용되는 트래픽 규칙을 정의할 수 있습니다.
Azure Firewall: 가상 네트워크 또는 Azure Virtual WAN 허브 배포에 배포할 수 있는 클라우드 네이티브 서비스입니다. Azure Firewall 사용하여 클라우드 리소스, 인터넷 및 온-프레미스 리소스 간에 흐르는 트래픽을 필터링합니다. Azure Firewall 또는 Azure Firewall Manager를 사용하여 계층 3에서 계층 7 컨트롤로 트래픽을 허용하거나 거부하는 규칙 또는 정책을 만듭니다. 고급 필터링 및 사용자 보호를 위해 타사 보안 공급자를 통해 트래픽을 전달하여 Azure Firewall 및 타사로 인터넷 트래픽을 필터링합니다. Azure는 타사 방화벽에서 분할하는 데 도움이 되는 네트워크 가상 어플라이언스 배포를 지원합니다.
예제
다음은 Azure에서 워크로드를 분할하기 위한 몇 가지 일반적인 패턴입니다. 필요에 따라 패턴을 선택합니다.
이 예제는 보안 기준(SE:01)에 설정된 IT(정보 기술) 환경을 기반으로 합니다. 아래 다이어그램은 organization 수행한 관리 그룹 수준의 구분을 보여줍니다.
ID 구분 패턴
패턴 1: 작업 제목 기반 그룹화
보안 그룹을 구성하는 한 가지 방법은 소프트웨어 엔지니어, 데이터베이스 관리자, 사이트 안정성 엔지니어, 품질 보증 엔지니어 또는 보안 분석가와 같은 직급을 사용하는 것입니다. 이 접근 방식에는 수행해야 하는 작업을 고려하지 않고 해당 역할에 따라 워크로드 팀을 위한 보안 그룹을 만드는 작업이 포함됩니다. 워크로드의 책임에 따라 보안 그룹에 JIT(대기 또는 정시)의 RBAC 권한을 부여합니다. 필요한 액세스 권한에 따라 보안 그룹에 사용자 및 서비스 원칙을 할당합니다.
멤버 자격은 역할 할당 수준에서 매우 잘 표시되므로 역할에 액세스할 수 있는 역할을 쉽게 확인할 수 있습니다. 각 사용자는 일반적으로 온보딩 및 오프보딩을 쉽게 만드는 하나의 보안 그룹의 구성원입니다. 그러나 직위가 책임과 완벽하게 겹치지 않는 한 타이틀 기반 그룹화는 최소 권한 구현에 적합하지 않습니다. 구현을 함수 기반 그룹화와 결합할 수 있습니다.
패턴 2: 함수 기반 그룹화
함수 기반 그룹화는 팀 구조를 고려하지 않고 수행해야 하는 개별 작업을 반영하는 보안 그룹 organization 방법입니다. 이 패턴을 사용하면 워크로드의 필수 기능에 따라 필요에 따라 보안 그룹 RBAC 권한( 스탠딩 또는 JIT)을 부여합니다.
필요한 액세스 권한에 따라 보안 그룹에 사용자 및 서비스 원칙을 할당합니다. 가능한 경우 패턴 1의 그룹과 같은 함수 기반 그룹의 멤버로 기존 동종 그룹을 사용합니다. 함수 기반 그룹의 예는 다음과 같습니다.
- 프로덕션 데이터베이스 연산자
- 사전 프로덕션 데이터베이스 연산자
- 프로덕션 인증서 회전 연산자
- 사전 프로덕션 인증서 회전 연산자
- 프로덕션 라이브 사이트/심사
- 모든 액세스 사전 프로덕션
이 방법은 가장 엄격한 최소 권한 액세스를 유지하고 scope 분명한 보안 그룹을 제공하므로 수행된 작업 업무에 비해 멤버 자격을 쉽게 감사할 수 있습니다. 이 작업 함수와 일치하도록 기본 제공 Azure 역할이 있는 경우가 많습니다.
그러나 멤버 자격은 하나 이상의 계층으로 추상화되므로 리소스 관점에서 볼 때 그룹에 있는 사용자를 이해하기 위해 ID 공급자로 이동해야 합니다. 또한 한 사람이 전체 적용 범위를 위해 여러 멤버십을 유지 관리해야 합니다. 겹치는 보안 그룹의 행렬은 복잡할 수 있습니다.
패턴 2는 organization 차트가 아닌 액세스 패턴을 포커스로 만드는 것이 좋습니다. 조직도 및 멤버 역할이 변경되는 경우가 있습니다. 기능적 관점에서 워크로드의 ID 및 액세스 관리를 캡처하면 워크로드의 보안 관리에서 팀 organization 추상화할 수 있습니다.
네트워킹 구분 패턴
패턴 1: 워크로드 내의 구분(소프트 경계)
이 패턴에서 워크로드는 서브넷을 사용하여 경계를 표시하는 단일 가상 네트워크에 배치됩니다. 분할은 데이터베이스용 서브넷과 웹 워크로드용 서브넷을 사용하여 수행됩니다. 서브넷 1이 인터넷과만 통신하도록 서브넷 2 및 서브넷 2와만 통신할 수 있도록 NSG를 구성해야 합니다. 이 패턴은 계층 3 수준 컨트롤을 제공합니다.
패턴 2: 워크로드 내의 세분화
이 패턴은 플랫폼 수준 구분의 예입니다. 워크로드cmponents는 서로 피어링하지 않고 여러 네트워크에 분산됩니다. 모든 통신은 공용 액세스 지점 역할을 하는 중간자를 통해 라우팅됩니다. 워크로드 팀은 모든 네트워크를 소유합니다.
패턴 2는 포함을 제공하지만 가상 네트워크 관리 및 크기 조정의 복잡성이 추가되었습니다. 두 네트워크 간의 통신은 퍼블릭 인터넷을 통해 이루어지며, 이는 위험할 수 있습니다. 공용 연결의 대기 시간도 있습니다. 그러나 두 네트워크를 피어링하여 더 큰 세그먼트를 만들도록 연결하여 구분을 끊을 수 있습니다. 다른 퍼블릭 엔드포인트가 필요하지 않은 경우 피어링을 수행해야 합니다.
| 고려 사항 | 패턴 1 | 패턴 2 |
|---|---|---|
| 연결 및 라우팅: 각 세그먼트가 통신하는 방법 | 시스템 라우팅은 워크로드 구성 요소에 대한 기본 연결을 제공합니다. 외부 구성 요소는 워크로드와 통신할 수 없습니다. | 가상 네트워크 내에서 패턴 1과 동일합니다. 네트워크 간에 트래픽은 공용 인터넷을 통해 이동합니다. 네트워크 간에 직접 연결이 없습니다. |
| 네트워크 수준 트래픽 필터링 | 세그먼트 간의 트래픽은 기본적으로 허용됩니다. NSG 또는 ASG를 사용하여 트래픽을 필터링합니다. | 가상 네트워크 내에서 패턴 1과 동일합니다. 네트워크 간에 방화벽을 통해 수신 및 송신 트래픽을 모두 필터링할 수 있습니다. |
| 원치 않는 오픈 퍼블릭 엔드포인트 | NIC(네트워크 인터페이스 카드)는 공용 IP를 받지 않습니다. 가상 네트워크는 인터넷 API 관리에 노출되지 않습니다. | 패턴 1과 동일합니다. 하나의 가상 네트워크에서 퍼블릭 엔드포인트를 열어 더 많은 트래픽을 허용하도록 잘못 구성할 수 있습니다. |
리소스 조직
소유권 책임에 따라 Azure 리소스 구성
허브 가상 네트워크, 방화벽, ID 서비스 및 Microsoft Sentinel과 같은 보안 서비스와 같은 여러 워크로드 및 공유 서비스 구성 요소가 포함된 Azure 자산을 고려합니다. 자산 전체의 구성 요소는 기능 영역, 워크로드 및 소유권에 따라 그룹화되어야 합니다. 예를 들어 공유 네트워킹 리소스를 단일 구독으로 그룹화하고 네트워킹 팀에서 관리해야 합니다. 개별 워크로드 전용 구성 요소는 자체 세그먼트에 있어야 하며 애플리케이션 계층 또는 기타 조직 원칙에 따라 더 분할될 수 있습니다.
RBAC 역할 할당을 만들어 개별 세그먼트 내에서 리소스를 관리할 수 있는 액세스 권한을 부여합니다. 예를 들어 클라우드 네트워킹 팀은 리소스를 포함하는 구독에 대한 관리 액세스 권한을 부여받을 수 있지만 개별 워크로드 구독에는 부여되지 않을 수 있습니다.
적절한 세분화 전략을 사용하면 각 세그먼트의 소유자를 쉽게 식별할 수 있습니다. Azure 리소스 태그를 사용하여 소유자 팀과 함께 리소스 그룹 또는 구독에 주석을 추가하는 것이 좋습니다.
액세스 제어 구성 및 검토
리소스에 대한 세그먼트를 명확하게 정의하여 필요에 따라 적절한 액세스 권한을 부여합니다.
액세스 제어 정책을 정의할 때 최소 권한 원칙을 고려합니다. 컨트롤 플레인 작업(리소스 자체 관리)과 데이터 평면 작업(리소스에서 저장된 데이터에 대한 액세스)을 구분하는 것이 중요합니다. 예를 들어 직원에 대한 중요한 정보가 포함된 데이터베이스가 포함된 워크로드가 있다고 가정해 보겠습니다. 데이터베이스 백업과 같은 설정을 구성해야 하는 일부 사용자 또는 데이터베이스 서버의 성능을 모니터링하는 사용자에게 관리 액세스 권한을 부여할 수 있습니다. 그러나 이러한 사용자는 데이터베이스에 저장된 중요한 데이터를 쿼리할 수 없습니다. 사용자가 업무를 수행하는 데 필요한 최소 scope 부여하는 권한을 선택합니다. 각 세그먼트에 대한 역할 할당을 정기적으로 검토하고 더 이상 필요하지 않은 액세스를 제거합니다.
참고
RBAC의 소유자 역할과 같이 권한이 높은 일부 역할은 사용자에게 리소스에 대한 액세스 권한을 다른 사용자에게 부여할 수 있는 기능을 제공합니다. 소유자 역할이 할당된 사용자 또는 그룹 수를 제한하고 감사 로그를 정기적으로 검토하여 유효한 작업만 수행하도록 합니다.
관련 링크
보안 검사 목록
전체 권장 사항 집합을 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기