Checks

E2E Networks database clusters should have automated backups enabled so data can be restored after failures, corruption, or accidental deletion. Automated backups capture point-in-time copies of the cluster on a recurring schedule.

E2E Networks database clusters should be configured with a custom administrative username instead of the well-known default, reducing the predictability of privileged credentials.

E2E Networks database clusters that expose a public IP should restrict connectivity through an IP whitelist instead of accepting connections from any address (0.0.0.0/0).

The master node of each E2E Networks database cluster should be reachable only over private networking and must not have a public IP address assigned.

E2E Networks database clusters should be in the RUNNING state, confirming they are operational rather than stopped, failed, or stuck in a transitional status.

E2E Networks database clusters should require SSL/TLS on the master node so that client connections and credentials are encrypted in transit.

E2E Networks database read replicas should be reachable only over private networking and must not have a public IP address assigned.

E2E Networks application load balancers serving HTTPS traffic should have a valid SSL certificate configured so client connections are encrypted and authenticated.

E2E Networks application load balancers should have HTTP health checks configured for their backends so traffic is only routed to healthy nodes.

E2E Networks load balancers should have BitNinja protection enabled to provide web application firewall coverage on public endpoints.

E2E Networks floating (reserved) IP addresses should be attached to a node instead of being left unassigned, since idle floating IPs can be reassigned unexpectedly.

E2E Networks public and addon reserved IP addresses should be attached to a resource, identifying orphaned addresses that remain internet-reachable without an owner.

E2E Networks VPCs should have at least one node attached, identifying unused network segments that may indicate misconfiguration or forgotten resources.

E2E Networks VPCs should be in the active state so that attached workloads retain expected connectivity and network isolation.

E2E Networks VPC peering connections should be established only with internal networks and must not extend trust to external peers outside the account.

E2E Networks nodes should have accidental protection enabled to guard against unintended deletion or modification of compute instances.

E2E Networks nodes should run with compliance mode enabled so required security controls are enforced and workload activity remains auditable.

E2E Networks nodes should have disk encryption enabled so data stored on node volumes and snapshots is protected at rest.

E2E Networks nodes should not be assigned a public IP address, keeping compute instances off the public internet unless inbound access is explicitly required.

E2E Networks nodes should not be running in rescue mode, which grants elevated filesystem access and can bypass normal operating controls.

E2E Networks nodes should be attached to a VPC so their traffic benefits from network isolation and segmentation controls.

E2E Networks security groups should not have an all-traffic rule, which permits unrestricted inbound and outbound network access.

E2E Networks security groups should not allow inbound all-protocol traffic from any source (0.0.0.0/0), which opens every port to the internet.

E2E Networks nodes should not rely solely on default security groups that have overly permissive inbound rules.