TLDR
- Your AWS root account email must NOT point to a specific person email Id.
- NEVER ever share your AWS root user credential to anyone.
- Do NOT use root user for day to day operations.
- DO Activate MFA (multi-factor authentication) on your root account.
P.S. There can be a dozen of reasons for a bill shock. The objective of this article is to fix some of the basic root account security anti-patterns (for beginners). I’ve focused on the Root Account security as most of the beginners tend to take its security for granted. As Root Account has unrestricted access any breach with root credentials will have large (yes, unlimited) blast radius!
Cloud Bill Shock 
Google it & you may come across 100s of instances where cloud service accounts of various individuals/companies have been misused by new age cyber pirates (euphemistically called Crypto Miners / Bitcoin Farmers).
Without an iota of doubt, AWS offers you unlimited capacities protected with state-of-the-art security practices. However, consider your bank has an excellent security practice and a perfectly secured website but can it prevent your account from an online robbery if you go on sharing your internet banking Sign-in User-Id and Password with others?
Ignorance is Bliss?
May be that’s true to some extent in real life. However in online world ignorance will be punished sooner than later. Cybersecurity is only as strong as your weakest link - and the weakest link most of the time is YOU (& your employees). Bot exploits are quite common & reported on a regular basis where hackers are running bots to look out for Access Keys in repository hosting services.
From last few weeks, I started consulting a few startups & SMEs who have recently migrated to AWS or have newly created the account & are about to migrate. A few clients were more than willing to share their root user credential without a second thought. A few are innocent enough to believe that as they're yet to deploy any of their assets (source code, data etc.) to the newly created account so there's no risk even if the credentials are compromised!
It seems not everyone is aware of the risk that their credentials can be misused by launching 100s of high-end virtual machines which can easily lead you to a staggering 5 figure bill within a day!
The security & compliance on AWS (or for that matter any cloud platform) works on the shared responsibility model. As per this model, the global AWS cloud infrastructure is secured by Amazon but OS level security, firewall configurations & more importantly the application level security is solely your responsibilities.
Security Anti-Patterns in AWS Account Management
(Yes! the most popular ones with the beginners)
1. Your root account email (i.e. AWS sign-up email) should not point to a specific person email Id.
Best Practice First & foremost, Sign-up AWS with an email alias – this disconnects the account from an individual user’s mailbox. The alias should point to a team distribution list addresses (i.e. multiple persons can receive alerts when Amazon is trying to warn you via email in case of a breach). Apart from being a security best practice; this arrangement also helps you when the employee (with root account email)quit the organization.
Although the root user eMail points to an alias (distribution list), at any point in time, only a single person should have the credentials to Sign-in. Others are simply receiving the emails and can inform the person responsible for root account handling in cases of an emergency.
2. Root account & other high privilege user accounts are NOT activated with MFA (Multi-factor Authentication).
3. Sharing root account credentials to a 3rd party or even to your own employees.
4. Having a single AWS account with unrelated teams (or business objectives).
5. Not setting up the AWS billing alerts.
6. Using a weak password for the Root Account.
6. Not using IAM at all.
7. Not applying an IAM password policy. This means that you'll definitely have many IAM users with weak passwords without any expiration.
8. Not following the principle of least privilege while assigning permission for IAM users.
9. Tying up the Root Account MFA to a personal mobile phone. (It’s a dependency. What if the person quits the company?)
So, what's the Best Way to Share your AWS Account with a Consultant?
For startups & smaller organizations, at times it may happen that you don't have the essential in-house competency to look into say why your billing has suddenly spiked (cost optimization) or whether your team is following the best security practices or you may have Scaling or Performance issues which you want to be sorted out with an external help. Or simply, you may wish to go for a review of your overall AWS architecture and want to bring in an external partner or independent AWS consultant for the task. So, what's the best way to go ahead till the required trust is built between you and the consultant?
One way which most of you may suggest (& practice) is to present your AWS console via a screen sharing application (Skype / Hangout / TeamViewer / GoToMeeting etc.). Well, this can work out to some extent but it does have a few limitations like:
What if the consultant wants to refer the architecture/console again after the meeting? Also, this approach requires a lot of coordination between your team and the consultant as both need to be present at the same time (even if it is remotely done).
IMO, the simplest, most efficient and secure way to start working with an independent consultant is to:
1. Share a Read-Only Access - The consultant can look into your architecture but CAN NOT CHANGE anything over there. For you, It hardly takes 5 minutes to set up a Read-Only IAM user via AWS console.
Here's a simple stepwise article to follow if you've not done it before.
Additionally, if there’s an S3 bucket in your account which has confidential information then it’s recommended that you assign an explicit deny policy for that bucket for that IAM user.
P.S. Similarly, if you want to provide Billing Dashboard access to a consultant for cost optimization then you can follow the steps mentioned in this article.
2. Share a Cross Account Access - Setting this up is definitely NOT as simple as the first approach. It requires more effort and a little more understanding of the AWS console. In this approach, the consultant can Sign-in to his own account and can access your account from there without any need of sharing credentials. You can define whatever permission you wish to grant to the consultant.
Here's a stepwise guide from Amazon support.
Is security still an afterthought for your organization?
It should NOT be. Are you following any of the above anti-patterns? If yes, go ahead & fix it before it's too late. Make security a zero-day job - fix it now.
References
https://www.olindata.com/en/blog/2017/04/spending-100k-usd-45-days-amazon-web-services
https://www.youtube.com/watch?v=tzJmE_Jlas0
https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html
0 comments:
Post a Comment