...
General
Reject by default - start with the least amount of permissions across the board (users, machines, services, access)
There should be no need for services to send traffic externally, this should be locked down
NACL’s to provide a second layer of security to ensure many mistakes with security groups don’t leave service wide open
Domain certificates to be per subdomain rather than wildcards. This will allow finer grain control to allow things like revokes if there were a breach
Encryption
In transit - this is relation to network traffic
At rest - when data is stored on disk (either as files or in a form of a database)
Network traffic within the VPC must be encrypted
Inbound network traffic on HTTP must be redirected to use HTTPS
Security groups
These behave like firewalls which limit (reject) certain types of traffic - can be attached to many types of resources
Many finely grained groups, named appropriately and not shared between VPC’s
Chained where it makes sense
WAF (Web application firewall)
Where it makes sense, to be placed in front of any application that receives traffic sourced externally
Controlled networking routes
Resources can only be reached via certain routes
No public IP’s
Applications must be stored in privates subnets with no direct accessible route from outside the VPC
Network traffic
Subnet to subnet traffic within a VPC will always allow to flow
VPC to VPC traffic would be heavily discouraged unless there was a valid reason and no other choice
VPC to on-prem/other cloud provider communication can be done via IPSEC VPN & BGP. This however is a large under taking and there may be better alternatives
...
Application
The applications we develop and deploy fit roughly in 3 groups
...