AWS Intro – 3. Security

When you are building a platform hosted on a Public Cloud provider (Public being the operative word), Security must be at the forefront of your focus. Getting this wrong will always be a lesson impossible to come back from. We at Boldlink guide our clients to avoid learning this lesson the hard way.

It is crucial to have crystal clear optics on AWS Shared Responsibility Model borders and boundaries. We will focus now on four areas: Access; Observability, Network, and Data from this angle.

AWS Shared Responsibility Model.

Clear awareness of boundaries between AWS and its customers is vital. You must understand where you are exposed (ex. someone accesses AWS data centre and extracts data from their hardware or “bugs” the network) and what you can do to mitigate it.

Access, the physical access to AWS Datacenters, the Security of the buildings where the hosted hardware exists, and the APIs and Web console provided by AWS is AWS's responsibility.
The passwords, policies (complexity; rotation; etc.), permission access and how you decouple your organisations on AWS are the Customers' responsibility to maintain and protect, recommendations:

• For you as the customer, at a bare minimum, use MFA (multi-factor authentication) or 2FA (two-factor authentication) for your user authentication, this will protect you against brute force attacks on your AWS users' passwords.
• Set your access policies to be conditional on a valid MFA/2FA token and authentication.
• Centralise users on a single account and make users assume roles to access other accounts/resources only if MFA/2FA is active and has a valid authentication.
• Never use unattended AWS users and passwords for your applications, use IAM roles specific to each component with permissions tailored for the needs of that component/service.
• Restrict access to your production environments with temporary and very specific/limited credentials with a two approver review process.
• Restrict permissions assignment on a need-to basis, and where you can’t restrict guaranteeing action or Resources use combinations of Conditions.

Observability, let us consider the definition of Observability, Monitoring tells you when something is wrong, while Observability enables you to understand why. Monitoring is a subset of and necessary action for Observability. You can only monitor an observable system.
AWS will provide you with the building blocks such as services, tools, documentation and best practices to guide you and build upon your desired Observability. Customers take full ownership and responsibility for the solution they implement, AWS responsibility is exclusive to guarantee the services you are using are available and within SLAs.
It is worth mentioning here our recommendations relevant to you, such as:

• AWS Cloudwatch logs, metrics, events, etc., are at the centre of your AWS logging strategy since it integrates with all AWS services at different levels and delivers analytics and insights which can extend your analysis and Observability of your AWS “estate”.
• AWS Security Hub, which encompasses security tools such as Guarduty, Inspector and Macie, are crucial to monitoring and scanning your AWS accounts and platforms.
• A more recent release, AWS Audit Manager, allows you to continuously audit your AWS usage to simplify how you assess risk and compliance with industry standards and AWS best practices.
• Funnel all your telemetry and log data to S3 to take advantage of Athena and some of the predefined analysis capabilities at a low cost.
• Isolate where you are storing your data, decouple AWS accounts and organisations and make sure you keep logs and Security related data replicated and isolated.

Network, from a Shared Responsibility model, you must look at your AWS network as a network you don’t own, even when isolated on a per Customer basis, it is only done so through software, not hardware.
AWS Data Centers have many certifications enabling your Organisation to adopt and comply with the highest standards of your industry. See here. 

Traffic must be encrypted from and to your AWS platform and inside your AWS VPC (Virtual Private Cloud) networks. Remember, as an AWS customer, you are using someone else’s network infrastructure.

The availability of an AWS network backbone that connects the internet to AWS Datacentres is AWS's Responsibility. AWS will go as far as filtering the traffic before it reaches your platforms and prevents DDoS and, to some degree, inline attacks with AWS Shield Standard.

Protection can be extended with many Services and 3rd party products depending on the requirements of your solution from a Security, Compliance & Risk perspective.

Data, be it your logs, Databases or files, you must apply “encryption-at-rest” in everything data related.
AWS provides AWS KMS (Key Management System) and Cloud HSM to enable this, and you can still use or integrate many third-party cloud solutions.
Data integrity and persistence are ultimately AWS Customers' responsibility. AWS does provide services with native data replication (ex, S3; some of the RDS engines, etc.), which AWS Customers can leverage to build a full-scale DR or Data protection solution, but, please understand this is optional and must be intentionally set up by the AWS Customer, not AWS himself, a concise list of our recommendations:

• Chose wisely your KMS/Cloud HSM strategy, a PCI-DSS environment might require a solution outside AWS services offering due to its customisation standards, ex. use purpose-built Prometheus instead of AWS Cloudwatch for your Monitoring and alerting.
• Replicate critical data and backups to different regions and monitor error rates. Data protection and integrity are the AWS customer's responsibility.
• Enable MFA verification and authentication validation on the deletion of your Data, ex, AWS s3 MFA delete.
• Audit your data with AWS Macie, ex. Through ML (machine learning), you can detect non-PII or sensitive data stored on AWS S3.

AWS Security is a vast topic which we have just begun to scratch the surface of and will sound different depending on the industry and business model of your Organisation, we will dive further into this topic in the upcoming series for you.
Check out our page on Boldlink.io or follow us on LinkedIn here for a series of articles on the same — on AWS Security Intro - Access.