Overview
When deploying the Druva AWS DRaaS proxy using the Druva CloudFormation stack, customers may observe that their extended detection and response (XDR) or other security monitoring platforms generate alerts about the configuration of the automatically created VPC endpoint.
By default, the VPC endpoint policy includes the entry "Principal": "*". This configuration grants access to all AWS principals, which some security tools may flag as a potential security concern.
This configuration is necessary to enable seamless communication between the proxy and Druva services during initial deployment. However, customers with stricter compliance or security requirements may choose to harden the VPC endpoint policy by restricting the allowed principals. Doing so reduces exposure and aligns with organizational security best practices.
Questions:
Why are scoped policies not implemented by default?
Is it feasible to restrict the VPC endpoint policy to specific Druva-managed VPCs or AWS principals without impacting integration?
Does the current configuration require "Principal": "*" for functionality, or can it be safely scoped down?
Analysis
Druva’s DRaaS architecture is highly dynamic:
Each backup set may use a different, dynamically named S3 bucket.
Customers may have multiple Druva cloud instances in the same AWS account.
Different IAM roles may be used for deployment and ongoing operations.
Multiple endpoints (EC2, Lambda, SQS, etc.) are created at deployment and during DR workflows.
Failover instances may use user-defined IAM roles, which are not known at deployment time.
VPC endpoint policies cannot be easily restricted to specific resources or roles at deployment because:
Resource names and roles are dynamic and not known in advance.
Restricting policies could break DR workflows if required permissions are missing.
Any future Druva feature requiring new permissions would require manual policy updates by all customers.
Solution / Recommendations
1. Can the VPC endpoint policy be restricted?
Yes, the policy can be updated to allow access only to specific AWS roles or users. Example policies:
Restrict to a specific IAM role:
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YOUR_ROLE_NAME>"
},
"Resource": "*"
}
]
}
Restrict to a specific IAM user:
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<YOUR_ACCOUNT_ID>:user/<YOUR_USER_NAME>"
},
"Resource": "*"
}
]
}2. What are the risks?
The IAM role or user specified must have all necessary permissions (EC2, Lambda, SQS, VPC, endpoints, etc.) for DR workloads to function.
If permissions are insufficient, DR operations may fail.
Any future changes in Druva’s architecture or feature set may require policy updates.
3. Best Practice:
If possible, create a dedicated VPC for DRaaS workflows. This restricts endpoint access to resources within that VPC, providing an additional layer of security.
Regularly review and update IAM roles and policies to ensure least-privilege access while maintaining required functionality.
Additional Notes
The default "Principal": "*" policy is used to ensure seamless operation across dynamic resources and roles.
Restricting the policy is possible but requires careful management of permissions and awareness of future changes.
For further hardening, consult with Druva Support before making changes to ensure DR functionality is not impacted.