Every major cloud provider today offers a large array of security controls to help secure customer services and data. Many of which have been hardened and in some cases subjected to significant scrutiny. Despite the existence of these controls, which are designed to reduce the risk of operator error, misconfiguration of cloud-based infrastructure is relatively common and has contributed to a number of high profile data breaches.
Just as in any IT deployment, whether cloud or self-hosted, some of the default settings for deployed services, networks, and templates are insecure by default or can be confusing. They include:
Generally, services such as AWS CloudTrail provide real-time visibility and historical records of the events which occur within a system deployed on top of AWS cloud services. Although the cost to enable CloudTrail is relatively small, it is disabled by default for most services, requiring administrators to explicitly enable each desired service and/or action.
Without the ability to record and audit important events, awareness of an attack is extremely limited. As a result, investigating a potential breach or intrusion becomes difficult, if not impossible.
To mitigate this risk, at a minimum, the following events should be logged:
- Authentication Successes/Failures.
- Access to Critical Resources.
- All Cross-Account Requests/Responses.
- Any Changes to the high-level account configuration (including services and resources).
- User creation, modification, or deletion.
All Cloud Service Providers offer fine-grained mechanisms for securing resources deployed to the cloud but they must be configured properly and appropriate groups and roles must be chosen (or written) in order to provide the least amount of access that is required. In particular, administrative wildcard policies should be avoided.
Tip: In many cases, troubleshooting of AWS related permission issues can be accomplished using the IAM Policy Simulator: https://policysim.aws.amazon.com/
One of the most common misconfigurations which can lead directly to a data breach is the improper exposure of services to the public internet. Both AWS Virtual Private Clouds and Azure Virtual Networks provide the ability to restrict which endpoints are reachable and whether inbound or outbound traffic to individual endpoints is allowed. Services launched within an Azure Virtual Network are allowed outbound access to the internet by default but must be configured to allow inbound access or external reachability. In contrast, the default behavior for services launched within an AWS VPC varies depending on a number of factors, some of which are:
- The configuration of the VPC and the subnet within which service is being launched.
- Whether or not the service was launched within a 'default' or 'non-default' VPC subnet.
- Whether or not the service is configured with IPv4 or IPv6 addresses.
- For EC2 instances, whether or not it was launched using the EC2 Launch Instance Wizard.
Configuration management can be difficult when deploying services and infrastructure to the cloud and the misconfiguration of a critical component or feature can introduce serious security vulnerabilities.
As a result, it is necessary for the individuals or groups responsible for deploying and securing an organization's cloud-based services to be familiar with both the security controls available to them and the default configuration and behavior of each system component. Application owners should perform security audits and configuration reviews to ensure that their environment is not suffering from any misconfiguration issues introducing security risks.
Azure Virtual Networks:
AWS Virtual Private Clouds: