Policies for resource management
To ensure that cloud resources (particularly when using IaaS and PaaS services) align with operational and security policies, it’s often necessary to leverage technical policies to enforce these within a cloud environment. These technical policies allow organizations to configure a technical template of standards that the cloud resources are either configured to adhere to at the time of setup, reconfigured to adhere to as changes are made, or potentially create alerts for an administrator when the resource is no longer in compliance. In many cases, different policies might be assigned to different resources based on the intent and use of the resource. For example, there may be a need to apply more restrictive policies to a resource that is in a production environment versus a sandbox environment, or those resources that are accessible to external users versus those that are only accessible to users within a corporate directory. The determination of what policies an organization applies should be based on the system architecture and integration of the environment. Developing an effective method to control how, where, and when different policies are applied can be done using tagging. In addition to tags supportingthe application of policies, another use case for tags in some cloud environments, such as AWS, is to enable Attribute-Based Access Controls (ABACs). These tags can be used to control who and what can access a particular resource and what actions they can take. Other use cases for tagging are to ensure resources are mapped correctly to architecture and technical requirements for segmentation, quota allocation, business continuity, and disaster recovery. In short, tagging is a way of associating metadata with resources using key-value pairing, and provides a method for grouping resources, controlling access to those resources, and understanding the expectations of what type of security controls the resource should be in adherence to. Although, in some cases, tags may systematically control who has access, this may not always be the case and should be verified. Some tags may be used to provide identifiers for architecture (production and non-production), sensitive data or data classification (Personally Identifiable Information (PII)), ownership (IT team versus a business team), or applicable compliance and regulatory controls (Sox, PCI and GDPR).
When using policies and tags, organizations must leverage automation where possible to ensure the application of policies and tags is consistently enforced. There should also be a documented policy for the use of policies and tagging that outlines when and how these attributes are applied and the roles and responsibilities related to and impacted by different tags. This policy should also support a documented and agreed-upon naming convention for the tagging key-value pairs, as well as outline ownership for ensuring consistency of what these pairs mean. This should be done for all cloud environments the organization is operating in and the use of tagging and definitions for the key-value pairs should be captured, along with the asset inventory to be provided at the start of an audit. In assessing the application of policies and tags, important areas to identify are where policy and tags have not been applied, where there are policy exemptions, and the process for periodic review of any automated applications of policies and tagging. Keep in mind that there may be some areas where default tagging capabilities have been enabled by the cloud provider. You should also assess whether there is any default-enabled policy configuration for the cloud environment and review any policies that may have been disabled.
Each of the cloud providers enables multiple paths to access tagging and policy information. They also each have a concept of Blueprints or Landing Zones, which enable preconfigured environments that can be automatically provisioned through code (Infrastructure as Code (IaC) and Policy as Code) and include default compliance policies (often including tagging) and enabled security services and best practices. These options generally intend to apply security and governance policies at scale for multi-account organizations and should greatly minimize potential misconfigurations or misapplication of policies and tags. To learn more about the Blueprint or Landing Zone features of the three major cloud providers, visit the following links:
- Azure: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/
- Google Cloud Platform (GCP): https://cloud.google.com/anthos-config-management/docs/concepts/blueprints
As an IT auditor, you should be aware of where options that directly modify and review policy and tagging settings exist. These features may be spread out between identity or security features or have a dedicated feature area, and this will vary by cloud provider.
In the Microsoft Azure portal, one way to see and edit tags (depending on access permissions) is by accessing an individual resource and selecting Tags from either the Overview area or directly selecting
Tags from the left navigation panel, as shown inFigure 5.1:
Figure 5.1 – Example Microsoft Azure resource tagging
Another way to find features related to Policy and Tags in Microsoft Azure is by using the search bar and searching for resources. By performing a search in the Azure portal and navigating to Tags, as in Figure 5.2, we have the option to look at existing key-value tag pairs and get more insight into howtags can be defined and used within Microsoft Azure:
Figure 5.2 – Microsoft Azure key-value tag pairing
In Figure 5.3, a search on Policy allowed us to navigate directly to the Policy blade, where we can see there is a resource that appears to be non-compliant with a default policy:
Figure 5.3 – Microsoft Azure Policy blade
Selecting the policy that appears as non-compliant provides additional details on the policy and why the resource has been flagged as non-compliant, as shown in Figure 5.4. This would be a great option for an IT auditor as they can have this report extracted and compared against the organization’s IT controls:
Figure 5.4 – Microsoft Azure Policy blade
Additional details about the use of tags and policies within Microsoft Azure can be found athttps://
docs.microsoft.com/en-us/azure/azure-resource-manager/management/ tag-policies.
In AWS, one location where you can find configuration for tags is under AWS Resource Groups, as shown in Figure 5.5:
Figure 5.5 – AWS Resource Groups and tagging
As the name suggests, you can group resources, as well as apply tagging to individual resources and edit tag policies. As mentioned earlier, AWS allows ABAC via the use of tags, so it’s important to understand the taxonomy and tagging design an organization is using since it may influence access controls. To learn more about this, you can check out https://docs.aws.amazon.com/ IAM/latest/UserGuide/tutorial_attribute-based-access-control.html.
Within Google Cloud, much of the policy, tagging, and resource management abilities exist within the IAM & Admin product, as shown in Figure 5.6. Here, you can easily identify a list of built-in inherited policies that have been applied. The option for Tags is visible in the left-hand side navigation:
Figure 5.6 – Google Cloud Platform organizational-level policies
Now that we’ve reviewed how policies and tags may be used to impact compliance, let’s review other options for controlling changes to resources.