Role-Based Access Control (RBAC) should be used on Kubernetes Services

Azure_Security_Benchmark_v2.0

PA-7

Azure_Security_Benchmark_v2.0_PA-7

Azure Security Benchmark PA-7

Privileged Access

Follow just enough administration (least privilege principle)

Customer

Azure role-based access control (Azure RBAC) allows you to manage Azure resource access through role assignments. You can assign these roles to users, group service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges complement the just in time (JIT) approach of Azure AD Privileged Identity Management (PIM), and those privileges should be reviewed periodically. Use built-in roles to allocate permission and only create custom role when required. What is Azure role-based access control (Azure RBAC): https://docs.microsoft.com/azure/role-based-access-control/overview How to configure Azure RBAC: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal How to use Azure AD identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview

n/a

Azure_Security_Benchmark_v3.0

PA-7

Azure_Security_Benchmark_v3.0_PA-7

Azure Security Benchmark PA-7

Privileged Access

Follow just enough administration (least privilege) principle

Shared

**Security Principle:** Follow the just enough administration (least privilege) principle to manage permissions at fine-grained level. Use features such as role-based access control (RBAC) to manage resource access through role assignments. **Azure Guidance:** Use Azure role-based access control (Azure RBAC) to manage Azure resource access through role assignments. Through RBAC, you can assign roles to users, group service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges will complement the just-in-time (JIT) approach of Azure AD Privileged Identity Management (PIM), and those privileges should be reviewed periodically. If required, you can also use PIM to define the time-length (time-bound-assignment) condition in role assignment where a user can activate or use the role only within start and end dates. Note: Use Azure built-in roles to allocate permissions and only create custom roles when required. **Implementation and additional context:** What is Azure role-based access control (Azure RBAC): https://docs.microsoft.com/azure/role-based-access-control/overview How to configure RBAC in Azure: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal How to use Azure AD identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview Azure AD Privileged Identity Management - Time-bound assignment: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-configure#what-does-it-do

n/a

CIS_Azure_1.1.0

8.5

CIS_Azure_1.1.0_8.5

CIS Microsoft Azure Foundations Benchmark recommendation 8.5

8 Other Security Considerations

Enable role-based access control (RBAC) within Azure Kubernetes Services

Shared

The customer is responsible for implementing this recommendation.

Ensure that RBAC is enabled on all Azure Kubernetes Services Instances

CIS_Azure_1.3.0

8.5

CIS_Azure_1.3.0_8.5

CIS Microsoft Azure Foundations Benchmark recommendation 8.5

8 Other Security Considerations

Enable role-based access control (RBAC) within Azure Kubernetes Services

Shared

The customer is responsible for implementing this recommendation.

Ensure that RBAC is enabled on all Azure Kubernetes Services Instances

CIS_Azure_1.4.0

8.7

CIS_Azure_1.4.0_8.7

CIS Microsoft Azure Foundations Benchmark recommendation 8.7

8 Other Security Considerations

Enable role-based access control (RBAC) within Azure Kubernetes Services

Shared

The customer is responsible for implementing this recommendation.

Ensure that RBAC is enabled on all Azure Kubernetes Services Instances

CMMC_2.0_L2

AC.L1-3.1.1

CMMC_2.0_L2_AC.L1-3.1.1

404 not found

n/a

CMMC_2.0_L2

AC.L1-3.1.2

CMMC_2.0_L2_AC.L1-3.1.2

404 not found

n/a

CMMC_2.0_L2

AC.L2-3.1.5

CMMC_2.0_L2_AC.L2-3.1.5

404 not found

n/a

AC.1.001

CMMC_L3_AC.1.001

CMMC L3 AC.1.001

Access Control

Limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information systems).

Shared

Microsoft and the customer share responsibilities for implementing this requirement.

Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement AC.1.002.

AC.1.002

CMMC_L3_AC.1.002

CMMC L3 AC.1.002

Access Control

Limit information system access to the types of transactions and functions that authorized users are permitted to execute.

Shared

Microsoft and the customer share responsibilities for implementing this requirement.

Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-oforigin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements).

AC.2.007

CMMC_L3_AC.2.007

CMMC L3 AC.2.007

Access Control

Employ the principle of least privilege, including for specific security functions and privileged accounts.

Shared

Microsoft and the customer share responsibilities for implementing this requirement.

Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions. Organizations consider the creation of additional processes, roles, and system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges). Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate in the application of this requirement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk.

AC.2.016

CMMC_L3_AC.2.016

CMMC L3 AC.2.016

Access Control

Control the flow of CUI in accordance with approved authorizations.

Shared

Microsoft and the customer share responsibilities for implementing this requirement.

Information flow control regulates where information can travel within a system and between systems (versus who can access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include the following: keeping exportcontrolled information from being transmitted in the clear to the Internet; blocking outside traffic that claims to be from within the organization; restricting requests to the Internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content. Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict system services, provide a packetfiltering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Transferring information between systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes: prohibiting information transfers between interconnected systems (i.e., allowing access only); employing hardware mechanisms to enforce one-way information flows; and implementing trustworthy regrading mechanisms to reassign security attributes and security labels.

CM.2.062

CMMC_L3_CM.2.062

CMMC L3 CM.2.062

Configuration Management

Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.

Shared

Microsoft and the customer share responsibilities for implementing this requirement.

Systems can provide a wide variety of functions and services. Some of the functions and services routinely provided by default, may not be necessary to support essential organizational missions, functions, or operations. It is sometimes convenient to provide multiple services from single system components. However, doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit component functionality to a single function per component. Organizations review functions and services provided by systems or components of systems, to determine which functions and services are candidates for elimination. Organizations disable unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of devices, transfer of information, and tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services.

hipaa-1149.01c2System.9-01.c

hipaa

1149.01c2System.9-01.c

1149.01c2System.9 - 01.c

Privilege Management

The organization facilitates information sharing by enabling authorized users to determine a business partner's access when discretion is allowed as defined by the organization and by employing manual processes or automated mechanisms to assist users in making information sharing/collaboration decisions.

Customer

n/a

Sample of signed information sharing agreements (e.g., disclosure agreements) with business partners, depicting sharing terms and conditions.

Third-party security policy and procedures (e.g., Azure Third Party Management SOP).

hipaa

1153.01c3System.35-01.c

hipaa-1153.01c3System.35-01.c

1153.01c3System.35-01.c

11 Access Control

1153.01c3System.35-01.c 01.02 Authorized Access to Information Systems

Shared

n/a

All file system access not explicitly required is disabled, and only authorized users are permitted access to only that which is expressly required for the performance of the users' job duties.

hipaa

1229.09c1Organizational.1-09.c

hipaa-1229.09c1Organizational.1-09.c

1229.09c1Organizational.1-09.c

12 Audit Logging & Monitoring

1229.09c1Organizational.1-09.c 09.01 Documented Operating Procedures

Shared

n/a

Separation of duties is used to limit the risk of unauthorized or unintentional modification of information and systems.

NIST_SP_800-53_R4

AC-3(7)

NIST_SP_800-53_R4_AC-3(7)

NIST SP 800-53 Rev. 4 AC-3 (7)

Access Control

Role-based Access Control

Customer

n/a

The information system enforces a role-based access control policy over defined subjects and objects and controls access based upon [Assignment: organization-defined roles and users authorized to assume such roles].

NIST_SP_800-53_R5_AC-3(7)

NIST_SP_800-53_R5

AC-3(7)

NIST SP 800-53 Rev. 5 AC-3 (7)

Access Control

Role-based Access Control

Customer

n/a

Enforce a role-based access control policy over defined subjects and objects and control access based upon [Assignment: organization-defined roles and users authorized to assume such roles].

NZ_ISM_v3.5

INF-9

NZ_ISM_v3.5_INF-9

NZISM Security Benchmark INF-9

Infrastructure

10.8.35 Security Architecture

Customer

n/a

It is important that the principles of separation and segregation as well as the system classification are incorporated into the overall security architecture to maximise design and operational efficiency and to provide and support essential security to the network design.

RBI_CSF_Banks_v2016

8.1

RBI_CSF_Banks_v2016_8.1

User Access Control / Management

User Access Control / Management-8.1

n/a

Provide secure access to the bank???s assets/services from within/outside bank???s network by protecting data/information at rest (e.g. using encryption, if supported by the device) and in-transit (e.g. using technologies such as VPN or other secure web protocols, etc.)

RBI_CSF_Banks_v2016

8.5

RBI_CSF_Banks_v2016_8.5

User Access Control / Management

User Access Control / Management-8.5

n/a

Implement appropriate (e.g. centralised) systems and controls to allow, manage, log and monitor privileged/superuser/administrative access to critical systems (Servers/OS/DB, applications, network devices etc.).

RBI_CSF_Banks_v2016

8.8

RBI_CSF_Banks_v2016_8.8

User Access Control / Management

User Access Control / Management-8.8

n/a

Implement measures to control installation of software on PCs/laptops, etc

RBI_ITF_NBFC_v2017

3.1.a

RBI_ITF_NBFC_v2017_3.1.a

RBI IT Framework 3.1.a

Information and Cyber Security

Identification and Classification of Information Assets-3.1

n/a

The IS Policy must provide for a IS framework with the following basic tenets: Identification and Classification of Information Assets. NBFCs shall maintain detailed inventory of Information Asset with distinct and clear identification of the asset.

RBI_ITF_NBFC_v2017

3.1.c

RBI_ITF_NBFC_v2017_3.1.c

RBI IT Framework 3.1.c

Information and Cyber Security

Role based Access Control-3.1

n/a

The IS Policy must provide for a IS framework with the following basic tenets: Role based Access Control ??? Access to information should be based on well-defined user roles (system administrator, user manager, application owner etc.), NBFCs shall avoid dependence on one or few persons for a particular job. There should be clear delegation of authority for right to upgrade/change user profiles and permissions and also key business parameters (eg. interest rates) which should be documented.

10.54

RMiT_v1.0_10.54

RMiT 10.54

Access Control

Access Control - 10.54

Shared

n/a

A financial institution must implement an appropriate access controls policy for the identification, authentication and authorisation of users (internal and external users such as third party service providers). This must address both logical and physical technology access controls which are commensurate with the level of risk of unauthorised access to its technology systems.

10.60

RMiT_v1.0_10.60

RMiT 10.60

Access Control

Access Control - 10.60

Shared

n/a

A financial institution must establish a user access matrix to outline access rights, user roles or profiles, and the authorising and approving authorities. The access matrix must be periodically reviewed and updated.

10.61

RMiT_v1.0_10.61

RMiT 10.61

Access Control

Access Control - 10.61

Shared

n/a

A financial institution must ensure' (a) access controls to enterprise-wide systems are effectively managed and monitored; and (b) user activities in critical systems are logged for audit and investigations. Activity logs must be maintained for at least three years and regularly reviewed in a timely manner.

10.62

RMiT_v1.0_10.62

RMiT 10.62

Access Control

Access Control - 10.62

Shared

n/a

In fulfilling the requirement under paragraph 10.61, large financial institutions are required to' (a) deploy an identity access management system to effectively manage and monitor user access to enterprise-wide systems; and (b) deploy automated audit tools to flag any anomalies.