Sie möchten Snyk in Aktion erleben?
The benefits of using cloud services like AWS are clear. They enable companies to become more SaaS-like by making it possible for them to build more scalable and flexible applications. But, using cloud services without security in mind, sets a business up for failure.
Snyk’s research concluded that 8 out of 10 companies experienced a serious cloud security incident in the past year. So for many organizations, it’s not a question of “if” but of “when” they will experience a serious incident. The best way to avoid the impending threat of cloud risk: by establishing strong AWS cloud security practices from the start.
Often, customers fall under the misconception that AWS is “secure by default.” While AWS prioritizes the security of the cloud, it’s up to you, as the customer, to focus on security in the cloud. This means that as an AWS user, your organization needs to take responsibility for securing everything that interacts with your cloud instance (data, containers, internal users, etc.). It’s a concept that cloud providers call “shared responsibility”: expecting both the provider and the customer to follow security best practices. Check out our guide to the shared responsibility model for more information.
Under the shared responsibility model, Amazon secures the underlying software and hardware components that keep AWS up and running. They’ve proactively worked to achieve the best possible security on their end, meeting security and compliance frameworks like PCI-DSS and HIPAA. Because of this, most unaddressed security issues show up on the customer’s side of the “shared responsibility” model.
AWS users often run into ten common “security in the cloud” risks, including:
It’s easy to accidentally put private content into public S3 buckets, or to unintentionally set a private S3 bucket to be public. Either of these simple mistakes means that anyone can read what’s inside your S3 buckets, and potentially use this information to access your data.
Setting up Amazon Identity and Access Management (IAM) incorrectly can lead to adverse effects later down the road. If the wrong access falls into the wrong hands, unauthorized changes can be made by malicious users.
Amazon Machine Images (AMIs) are templates that enable team members to rapidly launch an Amazon Elastic Compute Cloud (EC2) instance. It’s a common AWS vulnerability to accidentally make a public AMI, which reveals the inner workings of your organization’s cloud system to a publicly available catalog.
When you don’t have big-picture visibility of your organization’s cloud operations, it’s easy for details to slip through the cracks. This is because any number of your team members are setting up various AWS controls, configurations, and integrations on a daily basis. Simply put, you need to know what exists in order to secure it.
If you don’t define responsibilities and liability for AWS cloud security, no one will step up to the plate during a security incident. This is a massive risk. On the flip side, when liability is clearly assigned to responsible parties, it’s much easier to remediate incidents as quickly as possible.
It’s probably a given that you’ll store sensitive data in the cloud. Proactively protecting it falls under the customer’s responsibility, not the cloud provider’s. So you must take steps to protect it, or potentially face the consequences of a data breach. AWS recommends taking a few proactive steps to protect this data, such as using encryption and transport layer security (TLS).
Cloud misconfiguration is the root cause of several common AWS security risks. A misconfiguration within the cloud means that there aren’t proper controls in place for applications, containers, infrastructure, and other software components.
Cloud security on AWS isn’t just about the cloud itself. To achieve the best possible cloud security posture, the code stored within your cloud also needs to be secure. Insecure code, such as an IaC misconfiguration or a security issue within your first-party code or open source components, can be used by an attacker to gain unauthorized access to your systems. And just because this code is stored within AWS’ Serverless Application Repository or AWS CodeCommit doesn’t automatically make it safe to use.
Your code and data are only as secure as their containers. So an Amazon ECR without secure configuration (e.g. the right identity and access management, infrastructure security, and data protection measures) can become a significant vulnerability. Additionally, free open-source scanners within Amazon ECR will scan for a few known vulnerabilities from the NVD, but do so after a base image has been chosen, and leave the door open to possible security risks in those container workloads unless the base image itself has been scanned and updated as well.
Most of today’s businesses use open source across their entire organizations, meaning that open source vulnerabilities can affect cloud infrastructure and, in turn, become a cloud security issue. To stay on top of open source risk, it’s important to understand where each component is located, through end-to-end organizational visibility and an up-to-date inventory such as a software bill of materials (SBOM). In order to ensure no direct or transitive open source dependencies have been missed, it’s critical to apply security testing gates across the entire application stack on AWS, from development to production.
AWS cloud security might seem overwhelming, but it ultimately comes down to a few overarching best practices: end-to-end visibility of cloud resources and security risks across the entire application fleet, strong access control measures, data security measures, and secure application code — both first-party and open source.
Snyk provides comprehensive security for both applications and cloud environments, such as AWS, enabling organizations to meet these security best practices. Snyk and AWS have worked closely to build a multitude of integrations across the AWS application stack, allowing developers and security practitioners to easily find and fix misconfigurations in their AWS environment, as well as application-level security issues in first-party code, open source dependencies, container images, and IaC configurations across Terraform, CloudFormation or even the running Kubernetes environment. Learn more about how Snyk integrates with AWS security tooling.
Working With AWS Security Tools - Snyk
Learn how AWS’s built-in account security tools and Snyk’s application and service security tools work together to secure your entire AWS ecosystem.Weiterlesen