Join us
@boldlink ・ May 12,2022 ・ 5 min read ・ 1228 views
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.
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:
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:
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:
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.
Join other developers and claim your FAUN account now!
AWS DevOps Consultancy, Boldlink
@boldlinkInfluence
Total Hits
Posts
Only registered users can post comments. Please, login or signup.