Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management
Mode
All
Type
BuiltIn
Preview
False
Deprecated
False
Effect
Default Audit Allowed Audit, Deny, Disabled
RBAC role(s)
none
Rule aliases
none
Rule resource types
IF (2) Microsoft.ClassicStorage/storageAccounts Microsoft.Storage/StorageAccounts
Compliance
The following 23 compliance controls are associated with this Policy definition 'Storage accounts should be migrated to new Azure Resource Manager resources' (37e0d2fe-28a5-43d6-a273-67d37d1f5606)
Use Azure Policy to restrict which services you can provision in your environment.
How to configure and manage Azure Policy:
https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage
How to deny a specific resource type with Azure Policy:
https://docs.microsoft.com/azure/governance/policy/samples/not-allowed-resource-types
Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.
Configure and manage Azure Policy: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage
How to deny a specific resource type with Azure Policy: https://docs.microsoft.com/azure/governance/policy/samples/not-allowed-resource-types
How to create queries with Azure Resource Graph Explorer: https://docs.microsoft.com/azure/governance/resource-graph/first-query-portal
**Security Principle:**
Ensure that only approved cloud services can be used, by auditing and restricting which services users can provision in the environment.
**Azure Guidance:**
Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.
**Implementation and additional context:**
Configure and manage Azure Policy:
https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage
How to deny a specific resource type with Azure Policy:
https://docs.microsoft.com/azure/governance/policy/samples/not-allowed-resource-types
How to create queries with Azure Resource Graph Explorer:
https://docs.microsoft.com/azure/governance/resource-graph/first-query-portal
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, 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, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None.
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, 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, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None.
Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other 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 3.1.2.
Limit 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-of-origin. 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).
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, 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, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events
Shared
n/a
Audit logs record the following details for each auditable event:
• User identification.
• Type of event.
• Date and time.
• Success and failure indication.
• Origination of event.
• Identity or name of affected data, system component, resource, or service (for example, name and protocol).
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Audit logs are protected from destruction and unauthorized modifications
Shared
n/a
Audit log files, including those for externalfacing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify.