Basket
{{item.CourseTitle}}
Price: {{item.ItemPriceExVatFormatted}} {{item.Currency}}
Browse by Topic
Browse by Vendor
Unlimited Training
Attend all the top-notch LIVE Instructor-led Courses you want for the price of less than one course.
Migrating to a platform like Amazon Web Services (AWS) offers incredible flexibility and power, but it also introduces new security considerations. While AWS secures the underlying infrastructure, your organisation is responsible for securing what you build on top of it. Understanding and addressing common configuration pitfalls is therefore essential for protecting your data and applications.
One of the most critical areas for security is controlling who can access what. Overly permissive access rights are a leading cause of security incidents.
Common Pitfall: Granting excessive permissions to users, groups, or services. Using the root account for everyday tasks is a particularly dangerous practice, as it has unrestricted access to all resources in a given account.
Best Practice: Strictly adhere to the principle of least privilege. Every user and service should only have the absolute minimum permissions required to perform their function. Use IAM Roles for applications running on EC2 instances and avoid using long-lived access keys wherever possible. Implement multi-factor authentication (MFA) on all accounts, especially the root user.
Data is your most valuable asset, and securing it within AWS involves multiple layers of controls, particularly concerning storage services like Amazon S3.
Common Pitfall: Misconfiguring S3 buckets to allow public access. This simple error has been the cause of numerous high-profile data breaches. Another frequent issue is failing to encrypt sensitive data, leaving it exposed if unauthorised access occurs.
Best Practice: Configure all S3 buckets to block public access by default. Use S3 Block Public Access features as a centralised control. Furthermore, enable encryption for data at rest using AWS Key Management Service (KMS) and enforce encryption in transit by using HTTPS/TLS endpoints. This is not just a technical control but a key requirement for complying with regulations like UK GDPR.
Your AWS network infrastructure is your first line of defence against external threats. Improperly configured network controls can leave your systems wide open to attack.
Common Pitfall: Creating overly permissive Security Groups that allow unrestricted inbound traffic (e.g., allowing access from 0.0.0.0/0 on ports like SSH or RDP). This exposes your virtual servers directly to the internet.
Best Practice: Treat Security Groups as a fundamental firewall for your instances. Your rules should be specific and deny all traffic by default, only allowing connections on the ports and from the IP addresses that are strictly necessary. Use Virtual Private Clouds (VPCs) to create isolated network segments for different application tiers.
You cannot protect against threats you cannot see. Without comprehensive logging and monitoring, suspicious activity can go undetected until it is too late.
Common Pitfall: Not enabling or regularly reviewing logs from services like AWS CloudTrail, VPC Flow Logs, or DNS logs. This creates significant blind spots in your security posture.
Best Practice: Ensure AWS CloudTrail is active in all regions, logging all API activity. Centralise these logs and use Amazon CloudWatch Alarms to create automated alerts for unusual behaviour, such as unauthorised IAM changes, root account usage, or attempts to disable logging. This proactive monitoring is vital for rapid incident response.
Ultimately, securing your AWS environment is not a one-time task but a continuous process of management and vigilance. The issues highlighted here represent some of the most common, but also the most preventable, vulnerabilities. By adopting a security-first mindset and implementing these best practices, your organisation can leverage the power of AWS without exposing itself to unnecessary risk. A robust security posture is the foundation for building a resilient, compliant, and trustworthy cloud presence.
Get Unlimited access to ALL the LIVE Instructor-led Security courses you want - all for the price of less than one course.
When discussing AWS security issues, it’s natural to ask about the security of the cloud. To be clear, it’s very safe. AWS and other major platform leaders make exhaustive efforts to keep systems secure and maintain certifications.
However, security problems can crop up in solutions and components of AWS during the implementation process. For example, a recent report found in 2018 and 2019, that 90% of cloud-based security problems were due to misconfiguration.
This means the problem occurred in the cloud, but the culprit was human error on the organization’s configuration side.
Fortunately, awareness and training can minimize many of these security issues.
Security is a joint responsibility when you work with AWS or any cloud provider. But many administrators are unaware of what AWS handles and what they need to manage on their side.
Please don’t assume the default configuration fits your needs when you implement and use AWS. It’s critical to have someone knowledgeable check and manage your configuration settings.
Also, AWS offers many services, all of which have varying degrees of responsibility. So, it’s critical to understand these differences when you select your service.
EC2, for example, puts your side in charge of security. Your team must configure the OS, manage applications, and safeguard data. It’s a handful!
Your company may select the default Virtual Private Cloud in AWS without changing the configuration. However, when they need to create a new application, it’s tempting to use the public subnet built into AWS by default.
This approach, however, is hazardous. Public subnets use internet gateways, and they can be accessed through public internet. This means anyone can easily see private data hosted on the subnet.
If your application needs to be accessible by the public, try a mix of private and public subjects, so critical databases and functionality cannot be accessed on the public internet.
Giving broad permissions is a common problem in many organizations. After all, it’s simpler to configure broad permissions. And it ensures that everyone has the access they need to do their work.
But unregulated system access can go awry. Users may soon get access to areas they shouldn’t have and make changes they shouldn’t make.
But after a month, you forget all the people who were given admin access. The security risk here is a dishonest company insider may pull out private or sensitive data at any time. They also can damage resources the system is running and even revoke access for other employees.
So, if you give total admin access to a service to one person, you should strongly reconsider. For security’s sake, your policy should offer the fewest permissions needed to get the task done.
The system’s root accounts can do a lot of harm if an unauthorized person accesses them. Unfortunately, far too many administrators don’t disable access to root APIs. This can be a costly mistake.
Remember that no one in the organization should access the AWS root account most of the time – this includes your most trusted admins. So do not share them across applications and users, or problems might result.
Your root accounts need to be safeguarded with two-factor authentication and should be used rarely.
Many recent data breaches and subsequent attacks involve cybercriminals stealing login information to hack other accounts. For example, one data breach involved Colonial Pipeline last year, and the company had to pay hackers $4.4 million to regain access.
This problem should clarify: Having usernames and ‘strong passwords’ are no longer enough.
You need to enforce robust passwords on AWS systems and use two-factor authentication. When you are using an application, activate multi-factor authentication. Anyone who doesn’t use multi-factor authentication should be immediately removed.
AWS offers tools to implement tokens, such as smartphones or physical cards, to use multifactor authentication. The more often your team uses multifactor authentication with AWS, the better your company cybersecurity will be.
Many people in the AWS security debate ask how we should view cloud security overall. Should we prioritize tools and controls or take security strategy as the first step? This sounds simple, but it’s more complex than you may think.
Most of the time, technology professionals say strategy should be handled first. This means that when assessing tools and controls, you can gauge how well it supports your security strategy.
Prioritizing strategy also lets you build cybersecurity into every business function. This is especially relevant with the development team and operations.
Let’s say your company chooses a configuration management tool that automates software patches and updates. Having a robust cybersecurity strategy thought out ahead of time helps you set up appropriate security controls from the first day.
As your organization implements and uses AWS, security is critical. Your team can keep AWS secure in your business environment by having employees trained in AWS security best practices.
You can get this essential training with our online AWS security certification today, so contact us now.
Discover the science and thoughts of leaders in the Skills-First Economy. Fill in your email to subscribe to monthly updates.
Through years of experience working with more than 1000 top companies in the world, we ́ve architected the Readynez method for learning. Choose IT courses and certifications in any technology using the award-winning Readynez method and combine any variation of learning style, technology and place, to take learning ambitions from intent to impact.