Prowler ThreatScore Compliance Framework for Alibaba Cloud

No root access key exists

1000

1. IAM

1.1 Authentication

5

The root account in Alibaba Cloud has the highest level of privileges. Access keys provide programmatic access to the account, and when associated with the root account, they pose a significant security risk. It is recommended that no access keys be associated with the root account, ensuring that all programmatic access is managed through RAM users with least privilege access.

Removing access keys associated with the root account limits the vectors by which the most privileged account can be compromised. If an access key is leaked or stolen, attackers gain unrestricted access to all resources in the account. Eliminating root access keys reduces the risk of unauthorized access and enforces the use of RAM users with proper access controls.

MFA enabled for RAM console users

100

1. IAM

1.1 Authentication

4

Multi-Factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a RAM user logs on to Alibaba Cloud, they will be prompted for their username and password followed by an authentication code from their virtual MFA device. It is recommended that MFA be enabled for all RAM users that have console access.

Without Multi-Factor Authentication, a compromised password alone is enough to allow an attacker to access the console, gaining full visibility and control over Alibaba Cloud resources. MFA requires users to verify their identities by entering two authentication factors, making it significantly harder for attackers to gain access.

Inactive users disabled for console access

8

1. IAM

1.1 Authentication

2

RAM users can logon to Alibaba Cloud console using their username and password. If a user has not logged on for 90 days or longer, it is recommended to disable the console access of the user to reduce the attack surface.

Disabling users from having unnecessary logon privileges reduces the opportunity that an abandoned user or a user with compromised password can be exploited. Inactive accounts are prime targets for attackers as they may have outdated passwords or forgotten access that goes unmonitored.

Access keys rotated every 90 days

10

1. IAM

1.1 Authentication

3

Access keys consist of an access key ID and a secret, which are used to sign programmatic requests to Alibaba Cloud. RAM users need their own access keys to make programmatic calls via SDKs, CLIs, or direct API calls. It is recommended that all access keys be regularly rotated to minimize the risk of unauthorized access.

Access keys might be compromised by leaving them in code, configuration files, or cloud storage, and then stolen by attackers. Rotating access keys regularly reduces the window of opportunity for a compromised access key to be exploited, limiting potential damage from credential theft.

RAM password minimum length 14 or greater

10

1. IAM

1.1 Authentication

3

RAM password policies can be used to ensure password complexity. It is recommended that the password policy require a minimum of 14 or greater characters for any password to enhance security against brute force attacks.

Requiring longer and more complex passwords reduces the risk of compromise from brute force attacks, credential stuffing, and other password-based threats. A 14-character minimum makes it significantly harder for attackers to guess or crack passwords.

RAM password requires uppercase letter

10

1. IAM

1.1 Authentication

3

RAM password policies can be configured to enforce the use of at least one uppercase letter in user passwords. Including uppercase letters increases password complexity, making them more resilient to brute-force and dictionary attacks.

Requiring at least one uppercase letter ensures that passwords are not composed solely of lowercase letters or numbers, which are more predictable and easier to crack. This policy adds complexity and reduces the risk of unauthorized access.

RAM password requires lowercase letter

10

1. IAM

1.1 Authentication

3

RAM password policies can be configured to enforce the use of at least one lowercase letter in user passwords. Including lowercase letters increases password complexity, making them more resistant to brute-force and dictionary attacks.

Requiring at least one lowercase letter ensures that passwords are not composed solely of numbers or uppercase letters, which are easier to guess. This enforcement improves password complexity and overall account security.

RAM password requires symbol

10

1. IAM

1.1 Authentication

3

RAM password policies can be configured to enforce the use of at least one special character (symbol) in user passwords. Special characters add complexity, making passwords harder to guess or crack.

Requiring a symbol in passwords increases entropy, making brute-force and dictionary attacks more difficult. This policy strengthens overall password security and aligns with industry best practices.

RAM password reuse prevention

10

1. IAM

1.1 Authentication

3

RAM password policies can be configured to prevent users from reusing previous passwords. This ensures that users create new, unique passwords instead of cycling through old ones, enhancing security.

Blocking password reuse helps mitigate the risk of credential-based attacks. It prevents users from reverting to previously compromised passwords, reducing the likelihood of unauthorized access through known credentials.

RAM password expiration policy

10

1. IAM

1.1 Authentication

3

RAM password policies can require passwords to be expired after a given number of days. It is recommended that the password policy expire passwords after 365 days or greater to balance security with user convenience.

Annual password rotation complements other security measures and ensures credentials are periodically refreshed. This approach follows modern security guidance that favors annual password changes combined with MFA over frequent forced rotations that lead to weaker passwords.

RAM password lockout policy

10

1. IAM

1.1 Authentication

3

RAM password policies can temporarily block logon after several incorrect logon attempts within an hour. It is recommended that the password policy is set to temporarily block logon after 5 incorrect attempts to prevent brute force attacks.

Account lockout policies provide essential protection against brute force and password spraying attacks. By limiting the number of failed authentication attempts, organizations can significantly reduce the risk of credential compromise.

RAM policies attached to groups or roles

1

1. IAM

1.2 Authorization

1

By default, RAM users, groups, and roles have no access to Alibaba Cloud resources. RAM policies are the means by which privileges are granted. It is recommended that RAM policies be applied directly to groups and roles but not to individual users.

Assigning privileges at the group or role level reduces the complexity of access management and reduces the opportunity for a principal to inadvertently receive or retain excessive privileges. This approach simplifies administration and improves security posture.

No RAM policies with full administrative privileges

100

1. IAM

1.3 Privilege Escalation Prevention

4

RAM policies define permissions for users, groups, or roles. Following the principle of least privilege, users should be granted only the permissions required to perform their tasks. RAM policies containing Effect: Allow, Action: *, and Resource: * should not be created as they grant unrestricted access.

Providing full administrative privileges exposes your resources to potentially unwanted actions. Starting with minimal permissions and granting additional access as necessary is significantly more secure than providing excessive permissions and attempting to restrict them later.

No legacy networks for ECS instances

10

2. Attack Surface

2.1 Network

3

To prevent use of legacy networks, ECS instances should not have a legacy network configured. Legacy networks have a single network IPv4 prefix range and a single gateway IP address for the whole network, lacking proper network segmentation and security isolation.

Legacy networks cannot create subnetworks and are subject to single points of failure. VPC networks provide better security isolation, network segmentation capabilities, and control over IP addressing. Using VPC ensures that resources benefit from modern networking features and security controls.

VPC flow logging enabled

10

2. Attack Surface

2.1 Network

3

VPC Flow Logs capture and record IP traffic information for network interfaces within a VPC, allowing administrators to monitor and analyze network activity. It is recommended to enable VPC Flow Logs to track network traffic and detect anomalous activity.

VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or support security investigations. They help identify suspicious activity, failed connection attempts, and potential threats within the VPC.

RDS instances not publicly accessible

1000

2. Attack Surface

2.1 Network

5

Database servers should accept connections only from trusted networks and restrict access from the world. The authorized network whitelist should not contain 0.0.0.0/0, which would allow access to the instance from anywhere on the internet.

To minimize the attack surface on a database server, only trusted and required IPs should be whitelisted. Publicly accessible databases are vulnerable to brute-force attacks, unauthorized access attempts, and data breaches. Restricting access ensures that only authorized networks can connect.

Kubernetes private cluster enabled

100

2. Attack Surface

2.1 Network

4

A private cluster is a cluster that makes your master inaccessible from the public internet. In a private cluster, nodes do not have public IP addresses, and workloads run in an environment isolated from the internet. Nodes and masters communicate privately using VPC peering.

Exposing the Kubernetes API server to the public internet increases the risk of unauthorized access and attacks. Private clusters reduce network latency, improve security by eliminating external IP exposure, and reduce egress costs by using internal networking.

Kubernetes network policy enabled

100

2. Attack Surface

2.1 Network

4

A network policy specifies how groups of pods are allowed to communicate with each other and other network endpoints. NetworkPolicy resources use labels to select pods and define rules for allowed traffic. The Kubernetes Network Policy API allows cluster administrators to specify what pods can communicate with each other.

By default, pods are non-isolated and accept traffic from any source. Once a NetworkPolicy selects a pod, that pod will reject any connections not allowed by any NetworkPolicy. Network policies implement defense in depth and least privilege networking, reducing the blast radius of compromised workloads.

Kubernetes ENI multiple IP mode enabled

10

2. Attack Surface

2.1 Network

3

Alibaba Cloud ENI (Elastic Network Interface) supports assigning ranges of internal IP addresses as aliases to a VM's network interfaces. Using ENI multiple IP mode via the Terway network plugin allows clusters to allocate IP addresses from a known CIDR block.

ENI multiple IPs mode provides better scalability, network segmentation, and firewall controls for pods. Pod IPs are reserved within the network ahead of time, preventing conflicts. Firewall controls can be applied separately from nodes, and pods can directly access hosted services without NAT.

Security groups restrict SSH access from internet

100

2. Attack Surface

2.1 Network

4

Security groups provide stateful filtering of ingress/egress network traffic to Alibaba Cloud resources. It is recommended that no security group allows unrestricted ingress access to port 22 (SSH) from the internet (0.0.0.0/0).

Removing unfettered connectivity to remote console services such as SSH reduces a server's exposure to risk. Publicly exposed SSH ports are prime targets for brute-force attacks, credential stuffing, and exploitation of SSH vulnerabilities. Restricting access to specific IP addresses or VPNs significantly improves security posture.

Security groups restrict RDP access from internet

100

2. Attack Surface

2.1 Network

4

Security groups provide stateful filtering of ingress/egress network traffic to Alibaba Cloud resources. It is recommended that no security group allows unrestricted ingress access to port 3389 (RDP) from the internet (0.0.0.0/0).

Removing unfettered connectivity to remote console services such as RDP reduces a server's exposure to risk. Publicly exposed RDP ports are common targets for ransomware attacks, brute-force attempts, and exploitation of RDP vulnerabilities. Restricting access is essential for protecting Windows servers.

ActionTrail OSS bucket not publicly accessible

1000

2. Attack Surface

2.2 Storage

5

ActionTrail logs a record of every API call made in your Alibaba Cloud account. These log files are stored in an OSS bucket. It is recommended that the access control list (ACL) of the OSS bucket which ActionTrail logs to shall prevent public access to protect sensitive audit log content.

Allowing public access to ActionTrail log content may aid an adversary in identifying weaknesses in the affected account's use or configuration. Audit logs contain sensitive information about API activities, user actions, and system changes that should be protected from unauthorized access.

OSS buckets not publicly accessible

1000

2. Attack Surface

2.2 Storage

5

OSS buckets are containers used to store objects in Object Storage Service. It is recommended that the access policy on OSS buckets does not allow anonymous and/or public access to prevent unauthorized data exposure.

Allowing anonymous and/or public access grants permissions to anyone to access bucket content. Such access might not be desired if storing sensitive data. Public buckets are a common source of data breaches, exposing customer data, credentials, and proprietary information to the internet.

Kubernetes RBAC authorization enabled

100

2. Attack Surface

2.3 Application

4

In Kubernetes, RBAC is used to grant permissions to resources at the cluster and namespace level. RBAC allows you to define roles with rules containing a set of permissions, ensuring that subaccounts who bind the roles only have the permissions to access specific resources defined in RBAC policies.

The legacy authorizer in Kubernetes Engine grants broad, statically defined permissions. RBAC has significant security advantages and can help ensure that users only have access to specific cluster resources within their own namespace. It is the recommended authorization mode for production clusters.

Kubernetes cluster health check

10

2. Attack Surface

2.3 Application

3

Kubernetes Engine's cluster check feature helps verify the system nodes and components health status. When triggered, the checking process verifies the health state of each node in the cluster and also the cluster configuration including kubelet, docker daemon, kernel, and network iptables configuration.

Regular cluster health checks help identify issues before they become critical security vulnerabilities. The checks verify cloud resource health status (VPC, VSwitch, SLB, ECS nodes), kubelet and docker daemon status, and kernel and iptables configurations. Running checks at least weekly ensures timely detection of misconfigurations.

Kubernetes Dashboard disabled

100

2. Attack Surface

2.3 Application

4

The Kubernetes Web UI (Dashboard) is backed by a highly privileged Kubernetes Service Account. It is recommended to use ACK User Console instead of Dashboard to avoid any privilege escalation via compromise of the dashboard.

The Kubernetes Dashboard can be used for creating or modifying resources with full cluster access. If compromised, an attacker could deploy malicious containers, access secrets, or take control of the entire cluster. Using managed console alternatives provides better security controls.

ECS endpoint protection installed

10

2. Attack Surface

2.3 Application

3

Endpoint protection should be installed on all ECS instances to detect and prevent malware, ransomware, and other malicious activities. Security Center agent provides real-time protection against threats targeting compute instances.

Without endpoint protection, ECS instances are vulnerable to malware infections, cryptomining attacks, and unauthorized access. The security agent monitors process execution, network connections, and file system changes to detect and block malicious activities in real-time.

ECS instances patched with latest OS updates

100

2. Attack Surface

2.3 Application

4

ECS instances should have the latest operating system patches applied to protect against known vulnerabilities. Unpatched systems are prime targets for attackers exploiting publicly disclosed vulnerabilities.

Outdated operating systems contain known vulnerabilities that attackers actively exploit. Regular patching closes security gaps and reduces the attack surface. Many high-profile breaches have resulted from failure to apply available patches in a timely manner.

ActionTrail multi-region enabled

100

3. Logging and Monitoring

3.1 Logging

4

ActionTrail is a web service that records API calls for your account and delivers log files. The recorded information includes the identity of the API caller, the time of the API call, the source IP address, the request parameters, and the response elements. A multi-region trail ensures that unexpected activities in otherwise unused regions are detected.

ActionTrail provides a history of API calls for security analysis, resource change tracking, and compliance auditing. Enabling multi-region logging ensures global service logging is captured, recording management operations performed on all resources in an Alibaba Cloud account.

Kubernetes Log Service enabled

100

3. Logging and Monitoring

3.1 Logging

4

Log Service should be connected with Kubernetes clusters to collect audit logs for central monitoring and analysis. By enabling Log Service, you will have container logs, kube-apiserver audit logs, and ingress logs available for incident investigation, compliance auditing, and security monitoring.

Log Service automatically collects, processes, and stores container and audit logs in a dedicated datastore. Container logs are collected from containers, audit logs from kube-apiserver, and events about cluster activity (such as Pod or Secret deletions). Central log collection allows access to all information on one dashboard.

RDS SQL auditing enabled

10

3. Logging and Monitoring

3.1 Logging

3

SQL auditing should be enabled on all applicable RDS instances. Auditing policy tracks database events and writes them to an audit log, helping to maintain regulatory compliance, understand database activity, and gain insight into discrepancies and anomalies that could indicate security violations.

Enabling auditing ensures that all existing and newly created databases are tracked. It helps detect unauthorized access, identify suspicious activity patterns, and support forensic investigations. Auditing is essential for compliance with security frameworks requiring database activity logging.

PostgreSQL log_disconnections enabled

8

3. Logging and Monitoring

3.1 Logging

2

Enabling log_disconnections helps PostgreSQL database log session terminations and duration. This log data can be used to identify abnormal patterns, troubleshoot issues, and support security investigations.

Logging disconnections provides visibility into session duration patterns that can indicate abnormal behavior. Combined with connection logging, this creates a complete picture of database access patterns. Anomalies in disconnection patterns may indicate unauthorized access attempts or compromised credentials.

OSS bucket logging enabled

8

3. Logging and Monitoring

3.1 Logging

2

OSS Bucket Access Logging generates a log that contains access records for each request made to your OSS bucket. An access log record contains details about the request, such as the request type, the resources specified, and the time and date the request was processed.

By enabling OSS bucket logging, it is possible to capture all events which may affect objects within target buckets. Configuring logs to be placed in a separate bucket allows access to log information useful in security and incident response workflows for forensic investigations.

PostgreSQL log_connections enabled

8

3. Logging and Monitoring

3.1 Logging

2

Enabling log_connections helps PostgreSQL Database log attempted connections to the server, as well as successful completion of client authentication. Log data can be used to identify, troubleshoot, and repair configuration errors and suboptimal performance.

Connection logging provides visibility into who is accessing the database and from where. This information is essential for security monitoring, detecting unauthorized access attempts, and forensic investigations. Combined with disconnection logging, it provides a complete audit trail.

PostgreSQL log_duration enabled

8

3. Logging and Monitoring

3.1 Logging

2

Enabling log_duration helps PostgreSQL Database log the duration of each completed SQL statement. This generates query and error logs that can be used to identify, troubleshoot, and repair configuration errors and suboptimal performance.

Duration logging helps identify slow queries and potential denial of service attacks through resource-intensive queries. It provides insights into database performance patterns and can reveal abnormal query execution times that may indicate security issues.

RDS SQL audit retention configured

8

3. Logging and Monitoring

3.2 Retention

2

Database SQL Audit Retention should be configured to be greater than 90 days or 6 months. Audit logs can be used to check for anomalies and give insight into suspected breaches or misuse of information and access.

Adequate retention periods ensure that audit logs are available for security investigations, incident response, and compliance requirements. Many regulatory frameworks require minimum log retention periods, and insufficient retention can result in missing critical evidence during investigations.

SLS logstore retention configured

8

3. Logging and Monitoring

3.2 Retention

2

Log Service logstores should have adequate retention periods configured to ensure logs are available for security investigations, compliance requirements, and forensic analysis.

Insufficient log retention can result in missing critical evidence during security investigations. Many compliance frameworks require minimum log retention periods, and organizations should configure retention based on their regulatory and operational requirements.

Kubernetes CloudMonitor enabled

8

3. Logging and Monitoring

3.3 Monitoring

2

The monitoring service in Kubernetes Engine clusters depends on the Alibaba Cloud CloudMonitor agent to access additional system resources and application services. The monitor can access metrics about CPU utilization, disk traffic, network traffic, and disk IO information.

CloudMonitor provides visibility into cluster health and performance, enabling detection of anomalies that could indicate security issues. System metrics help identify resource exhaustion attacks, cryptomining, and other malicious activities that manifest through abnormal resource usage patterns.

Security Center Advanced/Enterprise Edition

10

3. Logging and Monitoring

3.3 Monitoring

3

The Advanced or Enterprise Edition of Security Center enables threat detection for network and endpoints, providing malware detection, webshell detection, and anomaly detection capabilities for comprehensive security monitoring.

Advanced security monitoring capabilities are essential for detecting and responding to sophisticated threats. The enhanced editions provide real-time threat intelligence, automated response capabilities, and comprehensive visibility into security events across the cloud environment.

Security Center agent installed on all assets

10

3. Logging and Monitoring

3.3 Monitoring

3

The endpoint protection of Security Center requires an agent to be installed on endpoints to provide comprehensive intrusion detection and protection capabilities, including remote login detection, webshell detection and removal, and anomaly detection.

Without the security agent, endpoints lack visibility into security events, leaving potential threats undetected. The agent-based approach enables real-time monitoring of abnormal process behaviors, network connections, and changes to critical files and accounts.

Security Center high risk notifications enabled

10

3. Logging and Monitoring

3.3 Monitoring

3

All risk item notification should be enabled in Vulnerability, Baseline Risks, Alerts and AccessKey Leak event detection categories to ensure security operators receive timely notifications when security events occur.

Timely notification of security events is critical for rapid incident response. Without proper alerting, critical vulnerabilities and security incidents may go unnoticed, allowing attackers extended time to exploit weaknesses and expand their foothold.

Security Center vulnerability scan enabled

10

3. Logging and Monitoring

3.3 Monitoring

3

Scheduled vulnerability scanning should be enabled on all servers to discover system vulnerabilities in a timely manner. This ensures that security teams are aware of potential weaknesses before they can be exploited.

Regular vulnerability scanning is essential for maintaining a strong security posture. Automated scans identify missing patches, misconfigurations, and known vulnerabilities, enabling proactive remediation before attackers can exploit these weaknesses.

SLS unauthorized API calls alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring unauthorized API calls helps detect malicious activity such as reconnaissance, privilege escalation attempts, or compromised credentials being used to access resources.

Unauthorized API calls often indicate an attacker probing for vulnerabilities or attempting to access resources they should not have access to. Early detection of these patterns enables rapid response before significant damage occurs.

SLS console sign-in without MFA alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring console sign-ins without MFA helps identify users who have not enabled multi-factor authentication, representing a security gap that could be exploited if credentials are compromised.

Sign-ins without MFA are higher risk as they rely solely on password authentication. Alerting on these events helps identify compliance gaps and potential account compromises where attackers may have disabled MFA.

SLS console authentication failures alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring authentication failures helps detect brute-force attacks, credential stuffing attempts, and unauthorized access attempts against the management console.

Multiple authentication failures may indicate an ongoing attack attempting to guess credentials. Early detection allows security teams to block attacking IPs, lock affected accounts, or implement additional controls before successful compromise.

SLS root account usage alert enabled

100

3. Logging and Monitoring

3.4 Alerting

4

Monitoring root account usage is critical as the root account has unrestricted access to all resources. Any use of the root account should be investigated to ensure it is legitimate and necessary.

The root account should rarely be used in normal operations. Alerts on root account activity help detect unauthorized access to the most privileged account and ensure that legitimate root usage is documented and justified.

SLS RAM role changes alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring RAM role changes helps detect privilege escalation attempts, unauthorized permission modifications, and potential backdoor creation through role manipulation.

Changes to RAM roles can grant attackers persistent access or elevated privileges. Alerting on role changes enables rapid detection of unauthorized modifications that could compromise the security of the entire cloud environment.

SLS VPC changes alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring VPC changes helps detect network infrastructure modifications that could expose resources to unauthorized access or disrupt network segmentation controls.

VPC changes can significantly impact network security posture. Unauthorized modifications might create network paths that bypass security controls or expose internal resources to the internet. Real-time alerting enables rapid response to potentially malicious changes.

SLS VPC route changes alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring VPC route table changes helps detect modifications that could redirect traffic through malicious endpoints or disrupt legitimate network connectivity.

Route table modifications can enable man-in-the-middle attacks by redirecting traffic through attacker-controlled systems. Alerting on route changes helps detect unauthorized network path modifications that could compromise data confidentiality.

SLS security group changes alert enabled

100

3. Logging and Monitoring

3.4 Alerting

4

Monitoring security group changes helps detect modifications to firewall rules that could expose resources to unauthorized network access or create security gaps.

Security groups are the primary network access control mechanism. Unauthorized changes could open ports to the internet, allow lateral movement, or bypass network segmentation. Real-time alerting enables rapid response to potentially malicious rule changes.

SLS cloud firewall changes alert enabled

100

3. Logging and Monitoring

3.4 Alerting

4

Monitoring cloud firewall changes helps detect modifications to centralized firewall policies that could weaken network security controls across the entire cloud environment.

Cloud firewall provides centralized network security policy enforcement. Unauthorized changes could disable protection for multiple resources simultaneously. Alerting ensures that firewall modifications are detected and reviewed promptly.

SLS OSS bucket policy changes alert enabled

100

3. Logging and Monitoring

3.4 Alerting

4

Monitoring OSS bucket policy changes helps detect modifications that could make buckets publicly accessible or grant unauthorized access to sensitive data stored in object storage.

Bucket policy changes are a common vector for data breaches. Attackers may modify policies to exfiltrate data or create backdoor access. Alerting on policy changes enables rapid detection and remediation of potentially dangerous modifications.

SLS OSS permission changes alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring OSS permission changes helps detect modifications to access control lists that could grant unauthorized users access to sensitive data in object storage.

Permission changes on OSS buckets can expose sensitive data to unauthorized parties. Alerting on these changes ensures that access control modifications are reviewed and validated, preventing accidental or malicious data exposure.

SLS RDS configuration changes alert enabled

10

3. Logging and Monitoring

3.4 Alerting

3

Monitoring RDS instance configuration changes helps detect modifications that could weaken database security, disable auditing, or expose databases to unauthorized access.

Database configuration changes can have significant security implications. Modifications might disable encryption, open network access, or turn off audit logging. Alerting ensures that configuration changes are detected and reviewed for security impact.

SLS CMK changes alert enabled

100

3. Logging and Monitoring

3.4 Alerting

4

Monitoring customer-managed key changes helps detect modifications to encryption keys that protect sensitive data, including key deletion, rotation, or policy changes.

Customer-managed keys are critical for data protection. Unauthorized key changes could result in data loss if keys are deleted, or data exposure if key policies are weakened. Alerting enables rapid response to protect encrypted data assets.

OSS bucket secure transport enabled

10

4. Encryption

4.1 In-Transit

3

The secure transfer option enhances the security of OSS buckets by only allowing requests to the storage account via secure HTTPS connections. Any requests using HTTP will be rejected, ensuring that data is protected during transmission.

By default, OSS accepts both HTTP and HTTPS requests, which can expose data to interception. To enforce secure access, HTTP requests should be explicitly denied. This protects sensitive data from man-in-the-middle attacks and ensures compliance with security best practices for data in transit.

RDS SSL encryption enabled

10

4. Encryption

4.1 In-Transit

3

It is recommended to enforce all incoming connections to SQL database instances to use SSL. SQL database connections if successfully intercepted (MITM) can reveal sensitive data like credentials, database queries, and query outputs.

For security, it is recommended to always use SSL encryption when connecting to your database instance. This ensures that data in transit is protected from interception and man-in-the-middle attacks, maintaining confidentiality of sensitive database communications.

RDS TDE encrypted with customer key

10

4. Encryption

4.2 At-Rest

3

Transparent Data Encryption (TDE) with Bring Your Own Key (BYOK) support provides increased transparency and control over encryption keys. With BYOK, the database encryption key is protected by an asymmetric key stored in KMS that the data owner manages, rather than service-managed keys.

BYOK allows user control of TDE encryption keys, restricting who can access them and when. Using customer-managed keys provides additional security through separation of duties and allows organizations to maintain complete control over their encryption key lifecycle, including rotation and revocation.

ECS attached disks encrypted

10

4. Encryption

4.2 At-Rest

3

ECS cloud disk encryption protects your data at rest. The cloud disk data encryption feature automatically encrypts data when data is transferred from ECS instances to disks, and decrypts data when the data is read from disks.

Databases often contain sensitive and business-critical information. Encrypting data at rest ensures that underlying storage is protected even if physical access to the storage medium is compromised. Without encryption, data on disks can be read by anyone who gains access to the storage.

ECS unattached disks encrypted

10

4. Encryption

4.2 At-Rest

3

Ensure that unattached disks in a subscription are encrypted. Cloud disk encryption protects your data at rest using AES-256 encryption, ensuring that even disks not currently attached to instances maintain data protection.

Unattached disks may contain sensitive data from previous usage. Without encryption, this data remains vulnerable to unauthorized access if the storage medium is compromised. Encrypting all disks, including unattached ones, ensures comprehensive data protection.

RDS TDE enabled

10

4. Encryption

4.2 At-Rest

3

Transparent Data Encryption (TDE) should be enabled on every RDS instance. RDS Database transparent data encryption helps protect against the threat of malicious activity by performing real-time encryption and decryption of the database, associated backups, and log files at rest.

TDE provides encryption at rest without requiring changes to the application. It protects the database, backups, and transaction logs from unauthorized access. Even if an attacker gains access to the storage media, they cannot read the data without the encryption keys.