...
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
...
Some investigations have already been kicked off around ECS and lambda but like previous sessions we should try and standardise before we invest into any one approach
Like the previous sessions, we’ve had another meeting to discuss the possible solutions for these broad types of applications. Here’s what we’ve come up with so far:
Frontend applications
S3
ECS
Cloudfront
VMs (EC2)
EKS
Backend applications
ECS
VM
EKS
Lambda
Lightsail / Elastic Beanstalk
Backend applications - non public accessible
Just like the BE list above
With this list, we went through a process of elimination to remove products that we thought are not suitable or not possible due to the time constraints or skills within the team. With that in mind, the following was removed for the following reasons:
Cloud front: requires a backing service to initially serve the content
VM’s: the current solution, requires too much moving parts and requires a lot of time and management
EKS: managed kubernetes cluster, although good we don’t have to skills in the team. It’s also possible “overkill” for the service we provide
LightSail/Elastic Beanstalk: to simplistic for our needs, would be a good usecase for basic landing page like products
So that leaves us with: S3 + ECS for the frontend and ECS + Lambda for the backend. We don’t know what is the best choice for each type so spikes will be created to investigate each option
Infrastructure as code
Like all other forms of infrastructure, AWS is prone to configuration drift (where configuration differ’s from environment to environment) and flakey highly customised unique resources that are treated like pets (See: The history of Pets and Cattle). To circumnavigate these issues, we already use tools such as Terraform and Ansible to build and manage infrastructure as well as configure them in a uniform way.
...
This will contain the HEE developed terraform modules are allow developers to spin up whole environments / services with minimal copying and pasting while allowing to create resources in a standard manner
There will be times where creating infrastructure as code won’t be possible as constraints such as time or knowledge may force a developer to experiment using the AWS web console. This is ok as long as the developer takes those changes/learning and brings it back into code so that other can reuse and share
Other
With all this now “down on paper” we now have some guidance of where to do next. We’ll need to do several spikes and create a large set of tickets to enable the migration to AWS