Azure 역할 기반 액세스 제어Azure role-based access control

그룹 기반 액세스 권한 및 사용 권한을 활용하는 것이 좋습니다.Group-based access rights and privileges are a good practice. 개별 사용자가 아닌 그룹으로 관리하면 액세스 정책을 간소화하고 팀 간에 일관적인 액세스 관리를 제공하여 구성 오류를 줄일 수 있습니다.Dealing with groups rather than individual users simplifies maintenance of access policies, provides consistent access management across teams, and reduces configuration errors. 해당 그룹에 사용자를 할당하고 제거하여 특정 사용자의 권한을 최신 상태로 유지할 수 있습니다.Assigning users to and removing users from appropriate groups helps keep current the privileges of a specific user. Azure RBAC (역할 기반 액세스 제어) 는 사용자 역할로 구성 된 리소스에 대 한 세분화 된 액세스 관리를 제공 합니다.Azure role-based access control (Azure RBAC) offers fine-grained access management for resources organized around user roles.

Id 및 보안 전략의 일환으로 권장 되는 Azure RBAC 관행의 개요는 azure id 관리 및 액세스 제어 보안 모범 사례를 참조 하세요.For an overview of recommended Azure RBAC practices as part of an identity and security strategy, see Azure identity management and access control security best practices.

Azure 역할 기반 액세스 제어 개요Overview of Azure role-based access control

Azure 역할 기반 액세스 제어를 사용 하 여 팀 내에서 업무를 분리 하 고 특정 Azure Active Directory (Azure AD) 사용자, 그룹, 서비스 주체 또는 관리 되는 id에 대 한 충분 한 액세스 권한만 부여 하 여 작업을 수행할 수 있습니다.By using Azure role-based access control, you can separate duties within your team and grant only enough access for specific Azure Active Directory (Azure AD) users, groups, service principals, or managed identities to perform their jobs. Azure 구독 또는 리소스에서 모든 사람에게 무제한 액세스 권한을 제공하지 않고 각 리소스 집합에 대해 권한을 제한할 수 있습니다.Instead of giving everybody unrestricted access to your Azure subscription or resources, you can limit permissions for each set of resources.

Azure 역할 정의 는 해당 역할에 할당 된 사용자 또는 그룹에 허용 되거나 허용 되지 않는 작업을 나열 합니다.Azure role definitions list operations that are permitted or disallowed for users or groups assigned to that role. 역할의 범위는 이 정의된 권한이 적용되는 리소스를 지정합니다.A role's scope specifies which resources these defined permissions apply to. 여러 수준(관리 그룹, 구독, 리소스 그룹 또는 리소스)에서 범위를 지정할 수 있습니다.Scopes can be specified at multiple levels: management group, subscription, resource group, or resource. 범위는 부모/자식 관계로 구조화되어 있습니다.Scopes are structured in a parent/child relationship.

Azure RBAC 범위 계층 구조

특정 역할에 사용자 및 그룹을 할당 하 고 범위에 역할을 할당 하는 방법에 대 한 자세한 내용은 Azure Portal를 사용 하 여 Azure 역할 할당 추가 또는 제거를 참조 하세요.For detailed instructions for assigning users and groups to specific roles and assigning roles to scopes, see Add or remove Azure role assignments using the Azure portal.

액세스 제어 전략을 계획할 때 사용자에게 작업을 수행하는 데 필요한 사용 권한만 부여하는 최소 권한 액세스 모델을 사용합니다.When planning your access control strategy, use a least-privilege access model that grants users only the permissions required to perform their work. 다음 다이어그램에서는이 방법을 통해 Azure RBAC를 사용 하기 위한 제안 된 패턴을 보여 줍니다.The following diagram shows a suggested pattern for using Azure RBAC through this approach.

Azure RBAC 사용에 대 한 제안 된 패턴

참고

보다 구체적인 또는 세부적인 사용 권한을 정의할수록 액세스 제어가 복잡하고 관리하기 어려울 가능성이 높습니다.The more specific or detailed permissions are that you define, the more likely it is that your access controls will become complex and difficult to manage. 이는 클라우드 자산 크기가 증가함에 따라 더욱 그렇습니다.This is especially true as your cloud estate grows in size. 리소스별 사용 권한을 사용하지 않습니다.Avoid resource-specific permissions. 대신 관리 그룹 을 사용 하 여 구독 내에서 액세스 제어를 위한 엔터프라이즈 수준의 액세스 제어 및 리소스 그룹 을 사용 합니다.Instead, use management groups for enterprise-wide access control and resource groups for access control within subscriptions. 사용자별 사용 권한도 사용하지 않습니다.Also avoid user-specific permissions. 대신, AZURE AD의 그룹에 액세스 권한을 할당 합니다.Instead, assign access to groups in Azure AD.

Azure 기본 제공 역할 사용Use Azure built-in roles

Azure는 액세스를 제공하기 위한 세 가지 핵심 역할이 포함된 많은 기본 제공 역할 정의를 제공합니다.Azure provides a many built-in role definitions, with three core roles for providing access:

  • 소유자 역할 은 리소스에 대 한 액세스를 포함 하 여 모든 것을 관리할 수 있습니다.The Owner role can manage everything, including access to resources.
  • 참가자 역할 은 리소스에 대 한 액세스를 제외한 모든 것을 관리할 수 있습니다.The Contributor role can manage everything except access to resources.
  • 읽기 권한자 역할 은 모든 항목을 볼 수 있지만 변경할 수는 없습니다.The Reader role can view everything but not make any changes.

이러한 핵심 액세스 수준부터 시작하여 추가적인 기본 제공 역할을 사용하여 특정 리소스 유형 또는 Azure 기능에 액세스하기 위한 보다 세부적으로 제어할 수 있습니다.Beginning from these core access levels, additional built-in roles provide more detailed controls for accessing specific resource types or Azure features. 예를 들어 다음 기본 제공 역할을 사용하여 가상 컴퓨터에 대한 액세스를 관리할 수 있습니다.For example, you can manage access to virtual machines by using the following built-in roles:

기본 제공 역할을 사용 하 여 특정 기능에 대 한 액세스를 관리 하는 또 다른 예는 비즈니스 단위, 환경 또는 프로젝트에 대 한 비용 추적에서 비용 추적 기능에 대 한 액세스 제어에 대 한 설명을 참조 하세요.For another example of using built-in roles to manage access to particular features, see the discussion on controlling access to cost-tracking features in Track costs across business units, environments, or projects.

사용 가능한 기본 제공 역할의 전체 목록은 Azure 기본 제공 역할을 참조 하세요.For a complete list of available built-in roles, see Azure built-in roles.

사용자 지정 역할 사용Use custom roles

Azure에 기본 제공되는 역할이 다양한 액세스 제어 시나리오를 지원하지만 조직 또는 팀의 모든 요구를 충족하지 못할 수 있습니다.Although the roles built in to Azure support a wide variety of access control scenarios, they might not meet all the needs of your organization or team. 예를 들어 가상 머신 및 Azure SQL Database 리소스 관리를 담당하는 단일 사용자 그룹이 있는 경우 필요한 액세스 제어의 관리를 최적화하기 위해 사용자 지정 역할을 만들 수 있습니다.For example, if you have a single group of users responsible for managing virtual machines and Azure SQL Database resources, you might want to create a custom role to optimize management of the required access controls.

Azure RBAC 설명서에 사용자 지정 역할 만들기에 대한 지침과 역할 정의 작동 방식에 대한 세부 정보가 나와 있습니다.The Azure RBAC documentation contains instructions on creating custom roles, along with details on how role definitions work.

대규모 조직에 대한 책임과 역할 분리Separation of responsibilities and roles for large organizations

Azure RBAC를 사용 하면 조직에서 대기업 자산의 다양 한 관리 작업에 다양 한 팀을 할당할 수 있습니다.Azure RBAC allows organizations to assign different teams to various management tasks within large cloud estates. 이를 통해 중앙 IT 팀이 핵심 액세스 및 보안 기능을 제어할 수 있을 뿐만 아니라 소프트웨어 개발자 및 기타 팀에 특정 워크로드 또는 리소스 그룹에 대한 많은 제어권을 제공할 수 있습니다.It can allow central IT teams to control core access and security features, while also giving software developers and other teams large amounts of control over specific workloads or groups of resources.

또한 대부분의 클라우드 환경에서는 여러 역할을 사용하고 이러한 역할 간의 책임 분리를 강조하는 액세스 제어 전략의 이점을 활용할 수 있습니다.Most cloud environments can also benefit from an access-control strategy that uses multiple roles and emphasizes a separation of responsibilities between these roles. 이러한 접근 방식을 사용하려면 리소스 또는 인프라에 대한 중요한 변경 사항이 있을 때 완료하기 위해 여러 역할이 관여되며 둘 이상의 사용자가 변경 내용을 검토하고 승인해야 합니다.This approach requires that any significant change to resources or infrastructure involves multiple roles to complete, ensuring that more than one person must review and approve a change. 이러한 책임 분리는 단일 사용자가 중요한 데이터에 액세스하거나 다른 팀 멤버에게 알리지 않고 취약점을 발생시키는 기능을 제한합니다.This separation of responsibilities limits the ability of a single person to access sensitive data or introduce vulnerabilities without the knowledge of other team members.

다음 표에서는 IT 책임을 별도의 사용자 지정 역할로 분할하는 일반적인 패턴을 보여 줍니다.The following table illustrates a common pattern for dividing IT responsibilities into separate custom roles:

그룹Group 일반 역할 이름Common role name 담당 작업Responsibilities
보안 운영Security operations SecOpsSecOps 일반적인 보안 감독을 제공합니다.Provides general security oversight.
미사용 시 암호화와 같은 보안 정책을 설정하고 적용합니다.Establishes and enforces security policy such as encryption at rest.

암호화 키를 관리합니다.Manages encryption keys.

방화벽 규칙을 관리합니다.Manages firewall rules.
네트워크 운영Network operations NetOpsNetOps 라우팅, 피어링 등 가상 네트워크 내의 네트워크 구성 및 작업을 관리합니다.Manages network configuration and operations within virtual networks, such as routes and peerings.
시스템 작업Systems operations SysOpsSysOps 계산 및 스토리지 인프라 옵션을 지정하고 배포된 리소스를 유지 관리합니다.Specifies compute and storage infrastructure options, and maintains resources that have been deployed.
개발, 테스트 및 작업Development, test, and operations DevOpsDevOps 워크로드 기능 및 애플리케이션을 빌드하고 배포합니다.Builds and deploys workload features and applications.

는 서비스 수준 계약 및 기타 품질 표준을 충족 하는 기능 및 응용 프로그램을 운영 합니다.Operates features and applications to meet service-level agreements and other quality standards.

이러한 표준 역할의 작업 및 사용 권한을 분석해 보면 다양한 수준의 서로 다른 사용자가 이러한 역할을 수행하는 경우에도 애플리케이션, 구독 또는 전체 클라우드 자산에 걸쳐 동일한 경우가 많습니다.The breakdown of actions and permissions in these standard roles are often the same across your applications, subscriptions, or entire cloud estate, even if these roles are performed by different people at different levels. 따라서 사용자 환경 내에서 다양 한 범위에 적용 되는 Azure 역할 정의의 공통 집합을 만들 수 있습니다.Accordingly, you can create a common set of Azure role definitions to apply across different scopes within your environment. 그런 다음 사용자 및 그룹에 일반적인 역할을 할당할 수 있으며 리소스, 리소스 그룹, 구독 또는 관리를 담당하는 관리 그룹의 범위에만 해당됩니다.Users and groups can then be assigned a common role, but only for the scope of resources, resource groups, subscriptions, or management groups that they're responsible for managing.

예를 들어 여러 구독이 있는 허브 및 스포크 네트워크 토폴로지에서 는 허브 및 모든 워크 로드 스포크에 대 한 공통 역할 정의 집합이 있을 수 있습니다.For example, in a hub and spoke network topology with multiple subscriptions, you might have a common set of role definitions for the hub and all workload spokes. 허브 구독의 NetOps 역할은 모든 워크 로드에서 사용 하는 공유 서비스에 대 한 네트워킹 유지 관리를 담당 하는 조직의 중앙 IT 팀 구성원에 게 할당 될 수 있습니다.A hub subscription's NetOps role can be assigned to members of the organization's central IT team, who are responsible for maintaining networking for shared services used by all workloads. 그런 다음 워크로드 스포크 구독의 NetOps 역할을 특정 워크로드 팀 멤버에게 할당하면 해당 구독 내에 네트워킹을 구성하여 워크로드 요구 사항을 최대한 지원할 수 있습니다.A workload spoke subscription's NetOps role can then be assigned to members of that specific workload team, allowing them to configure networking within that subscription to best support their workload requirements. 두 경우 모두 동일한 역할 정의가 사용되지만, 범위 기반 할당으로 사용자가 작업을 수행하는 데 필요한 액세스 권한만 갖도록 해야 합니다.The same role definition is used for both, but scope-based assignments ensure that users have only the access that they need to perform their job.