Performing changes
Beyond using policies and tags to control compliant management of resources, these same features, along with others, may be used to restrict changes. Each of the cloud providers offers a way of grouping resources together for ease of classification. Both at a group and individual level, settings can be applied to lock the resource against changes or to restrict the level of changes that can be made (as shown in Figure 5.7), in addition to role assignments and access policies, as covered in Chapter 3, Identity and Access Management Controls:
Figure 5.7 – Example Microsoft Azure read-only lock applied
This level ofrestriction may not be readily apparent when discussing access controls, which is why organizations must document their system architecture. As auditors, we must understand that cloud providers offer a complex mix of controls that can be applied.
Now that we have looked at additional options for controlling changes, let’s gain insight into what cloud provider tools are available for managing changes.
Change management integration and workflows
When adopting IaaS or PaaS cloud services, many companies also choose to adopt change management processes that support continuous integration/continuous deployment (CI/CD). By necessity, this means there should be automated processes embedded into their change management procedures. From an auditing standpoint, this becomes important for a few different reasons. Removing manual processes also reduces the opportunity for manual IT control failures, but organizations now need to ensure that there are safeguards within the automated process that enforce separation of duties, automated policy applications, effective testing and approval gates, and rollback procedures. Automation workflows themselves will need to be regularly reviewed to ensure they adhere to change controls requirements, are not allowing compliance checks to be bypassed, and there is clear visibility and approval for those individuals with access to change the automation workflows or perform approvals as part of the workflows. Both the code and the automated workflows themselves should now be in scope for periodic review. Automation templates and workflows will need to be assessed for security-related controls such as the following:
- Are the latest security patches being applied through IaC templates?
- Who has access to maintain templates? Are changes to templates visible in logging?
- What is the mechanism that is enforcing all changes to go through the CI/CD pipeline? Are there any exceptions to this process?
- Who has access to login or account details for any workload identities or automation accounts being used to manage change integrations and deployments?
- Is there automated alerting to detect non-compliant changes? Who receives this alerting?
Each of the cloud providers has a set of capabilities that can be used to automate the deployment of resources, whether that is virtual machines (VMs), code, or even security and configuration policies. As shown in Figure 5.8, for AWS, some of these capabilities, such as CodeCommit, CodeDeploy, and CodePipeline, can be found under Developer Tools:
Figure 5.8 – AWS Developer Tools
These tools may be integrated with other third-party change management and CI/CD tools, or third-party tools may be used in place of these. As discussed in Chapter 1, Cloud Architecture and Navigation, organizations must provide a sound architectural diagram that outlines these types of integrations.
Like AWS, Microsoft Azure offers a set of tools for managing changes under theDevOps feature. As shown in Figure 5.9, in addition to deployment pipelines and change repositories, there is an option to view and track artifacts and test plans:
Figure 5.9 – Microsoft Azure DevOps
And in Google Cloud, you can find a set of available native CI/CD options, as shown in Figure 5.10:
Figure 5.10 – Google Cloud Platform CI/CD features
Keep in mind that these are only some of the built-in or native options available with each of the cloud providers. Other resources, such as AWS Config (https://aws.amazon.com/config/ features/) and Google Anthos Config Management (https://cloud.google.com/ anthos/config-management), can be used for auditing and deploying automating compliance deviation and Policy as Code configurations. Several popular open source options exist as well for managing policy and code automation. These include the following:
- Cloud Custodian, which is focused on AWS compliance and Policy as Code. More information can be found at https://aws.amazon.com/blogs/opensource/compliance-as-code-and-auto-remediation-with-cloud-custodian/.
- Gatekeeper is a general Compliance-as-Code tool that allows administrators to identify and reject any policy violations and also perform audits to see what existing resources may be violating policy. More information can be found at https://github.com/open-policy-agent/gatekeeper.
- Terraform by HashiCorp offers a general IaC tool with the ability to define policies and an ancillary tool, Terraform Compliance, that tests for policy compliance. Additional information can be found at https://developer.hashicorp.com/terraform/intro and https://terraform-compliance.com/.
In the interview and discovery phases of your audit, you may identify that different tools are used in different scenarios, along with integration to third-party products, which will need to be assessed.
Now that we have covered some of the available ways for managing and performing changes in cloud environments, let’s investigate some ways that we can see the history of changes that have been made.