Azure SQL Database instances with unrestricted ranges of allowable IP addresses unnecessarily broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

Example 1: The following example Ansible task defines an overly exposed Azure SQL Database instance.

- name: Create Firewall Rule
  azure.azcollection.azure_rm_sqlfirewallrule:
    resource_group: orgTestGroup
    server_name: orgSQLServer
    name: SQLServerFWRule
    start_ip_address: 0.0.0.0
    end_ip_address: 255.255.255.255

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example template defines a wildcard lambda principal.

{
    "Resources": {
        "LambdaPerm": {
            "Type": "AWS::Lambda::Permission",
            "Properties": {
            "SourceAccount": "AWS::AccountId",
            "SourceArn": "bucket.Arn",
            "FunctionName": "function.Arn",
            "Action": "lambda:InvokeFunction",
            "Principal": "*"
            }
        }
    },
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Lambda Permission"
}

Software modules from untrusted software supply chains might not be secure. Attackers can exploit the weakness of any poorly managed supply chain to insert malicious code.
A Terraform module is a pre-built set of configuration files. Modules make it easier and faster to get cloud services up and running. Many sources provide modules, including but not limited to the Terraform Registry, local directories, source repositories, and cloud storage. However, only a fraction of modules published in the Terraform Registry are systematically and continuously verified among all sources. A verified module listed in the Terraform Registry is a module that is in active maintenance and tested for compatibility but is not necessarily secure by design.

Publicly accessible resources are susceptible to distributed denial of service (DDoS) attacks and expose data to unauthorized access, tampering, and potential theft.

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Mismanagement of permissions increases the risk of unauthorized access to or modification of data and undermines service availability.

A service account is a special Google account used by an application or a VM instead of a person, which uses sensitive permissions to run automated processes or make API requests on behalf of end users. It should be carefully managed, controlled, and audited, so it can be trusted. Assigning a service account role to an IAM user, which typically represents a person, weakens the security control.

Backups and data recovery controls protect data and ensure its availability so the business can maintain daily operations.

Backups and data recovery controls protect data and ensure its availability so the business can maintain daily operations.

Azure offers several encryption options, each with specific benefits and limitations. For example, Azure storage server-side encryption (SSE) performs encryption by default without using compute resources, however, it does not encrypt the temporary disk or caches. It also does not protect data flowing from a compute instance to storage. Azure Disk Encryption (ADE), encrypts both temporary disks and caches, as well as data flowing to storage, but at the expense of compute resources.

Azure offers several encryption options, each with specific benefits and limitations. For example, Azure storage server-side encryption (SSE) performs encryption by default without using compute resources, however, it does not encrypt the temporary disk or caches. It also does not protect data flowing from a compute instance to storage. Azure Disk Encryption (ADE), encrypts both temporary disks and caches, as well as data flowing to storage, but at the expense of compute resources.

Azure offers several encryption options, each with specific benefits and limitations. For example, Azure storage server-side encryption (SSE) performs encryption by default without using compute resources, however, it does not encrypt the temporary disk or caches. It also does not protect data flowing from a compute instance to storage. Azure Disk Encryption (ADE), encrypts both temporary disks and caches, as well as data flowing to storage, but at the expense of compute resources.

Granting access or BigQuery roles to the special principal type such as allUsers and allAuthenticatedUsers gives anyone access to sensitive data.

Granting allUsers or allAuthenticatedUsers a Cloud KMS CryptoKey role gives anyone access to sensitive data.

Granting allUsers or allAuthenticatedUsers a Cloud Storage role gives anyone access to sensitive data.

Failure to block unwanted network traffic expands a cloud service's attack surface.

By default, IP forwarding is disabled in a Compute Engine instance. IP forwarding allows sending and receiving packets with non-matching source or destination IPs. An attacker can exploit this by routing packets through the Compute Engine instance to bypass network access control.

Example 1: The following Terraform configuration enables IP forwarding by setting can_ip_forward to true.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  can_ip_forward = true
  ...
}

By default, Google Cloud Compute Engine encrypts all data at rest. A customer-supplied encryption key (CSEK), if specified, encrypts the data encryption keys. Google does not store any CSEK on a Compute Engine instance and cannot access the protected data unless the correct CSEK is provided.

Example 1: The following example shows a Terraform Configuration that defines a persistent disk for a Compute Engine instance. The disk_encryption_key block is missing so there is no CSEK to protect the data encryption keys.

resource "google_compute_disk" "compute-disk-demo" {
    name  = "test-disk"
    type  = "pd-ssd"
}