In Parts 1 and 2, we reviewed Resource Allocation Planning, Tagging Resources, Authentication, Authorization and Password Policy, Audit Trail, Budget Control, Secure Access to cloud environments, Managing Compute Resources and Storing Sensitive Information.
In the third and final part of the series, we review additional best practices for building new environments in the cloud.
When using Object Storage, it is recommended to follow the following guidelines:
· Avoid allowing public access to services such as Amazon S3, Azure Blob Storage, Google Cloud Storage, Oracle Cloud Object Storage, etc.
· Enable audit access on Object Storage and store the access logs in a central account in the cloud environment (which will be accessible only for a limited amount of user accounts).
· It is highly recommended to encrypt data at rest on all data inside Object Storage and when there is a business or regulatory requirement, and encrypt data using customer managed keys.
· It is highly recommended to enforce HTTPS/TLS for access to object storage (users, computers and applications).
· Avoid creating object storage bucket names with sensitive information, since object storage bucket names are unique and saved inside the DNS servers worldwide.
· Avoid allowing inbound access to cloud environments using protocols such as SSH or RDP (in case remote access is needed, use Bastion host or VPN connections).
· As much as possible, it is recommended to avoid outbound traffic from the cloud environment to the Internet. If needed, use a NAT Gateway (such as Amazon NAT Gateway, Azure NAT Gateway, GCP Cloud NAT, Oracle Cloud NAT Gateway, etc.)
· As much as possible, use DNS names to access resources instead of static IPs.
· When developing cloud environments, and subnets inside new environments, avoid IP overlapping between subnets in order to allow peering between cloud environments.
Advanced use of cloud environments
It allows consumption of services, rather than maintaining servers, operating systems, updates/patches, backup and availability, assuming managed services in cluster or replica mode is chosen.
· Use Infrastructure as a Code (IoC) in-order to ease environment deployments, lower human errors and standardize deployment on multiple environments (Prod, Dev, Test).
Common Infrastructure as a Code alternatives:
To sum up:
Plan. Know what you need. Think scale.
If you use the best practices outlined here, taking off to the cloud for the first time will be an easier, safer and smoother ride then you might expect.