I have a verified domain that works with the IAM user I have created.
Emails go out successfully.
I am looking to lock this down, so I have first created a VPC endpoint, that allows SMTP traffic from the entire VPC. This too works without issue.
Finally, I want to only allow email to be sent via this endpoint, and as such want to have the SES Authorization policy to accept email sending from the local VPC range (10.204.0.0/16 for example). This is to ameliorate for any leaked credentials so bad actors cannot send emails impersonating our domain just because they have some SES access.
I cannot filter by aws:SourceIp as this only works for public IP addresses.
As such, is this even possible or do I have to allow for the possibility (however unlikely that is) that leaked credentials could allow external actors to send as our verified domain?
CodePudding user response：
Amazon SES can use SMTP credentials, which essentially means SES is connected to the internet & is theoretically public by nature.
While you can restrict IAM users & roles from using the Amazon SES API, there's no way you can restrict someone from connecting to any of the Amazon SES endpoints to abuse your SMTP server using stolen credentials. This is how the SMTP protocol works by design - using credentials.
It has no idea of a VPC IP range.
While you can't prevent leaked credentials from being used, you can monitor your Amazon SES sending activity & perhaps use CloudWatch alarms to notice any suspicious behaviour to be more reactive in case leakage happens.
Also be proactive to prevent leaking in the first instance - storing SMTP credentials in a locked-down AWS Parameter Store, only giving one main IAM SMTP user the permission to carry out the ses:SendRawEmail action at a time etc.
The combination of high levels of monitoring, tight restrictions on what application has access to the SMTP credentials at what time, constant rotation of the IAM SMTP user and thus SMTP credentials and general security awareness should hopefully prevent leakage of your credentials and if the worst does happen, the above actions should reduce the time to detect & the blast radius so to speak.
Thank you for trying to apply security at all layers & preparing for security events!