AWS Root Account Security Best Practices
Learn more about AWS Root Account security best practices from Mission’s Senior Cloud Analyst.
As you move more and more of your systems to the cloud and hosted applications, identity and access management becomes substantially more important—and also substantially more complex. In the old days, it was easy enough to manage employees’ access to data and applications, simply by knowing what was installed on their computer and what level of network access you provided. The cloud breaks those tethers, which means your security is entirely dependent on how well you manage users’ access credentials.
The most obvious times that identity and access management (IAM) comes up are when a new employee joins the team and when one leaves. All things considered, onboarding is relatively straightforward, because you know what you need to get your new employee set up with. But it’s also a real hassle: you have to log in to every application and create a new account by hand. That could easily be 10, 15, or more different (and manual) tasks!
Things get way worse when an employee—especially a long-tenured one—moves on. Your chances of remembering everything he or she had access to and fully deprovisioning those accounts are pretty slim. Which means your chances of leaving a live account unintentionally active are pretty good. That’s a scary situation, no matter how much you trust your former employees. And with an former employee you don’t trust? Yikes!
But those two big moments aren’t the only potential vulnerability with IAM: when you’ve got a lot of different accounts to manage, that’s a lot of different credentials for users to keep straight and remember. And each account is an opportunity for security to get compromised. While we all know you should never use the same password for multiple accounts and that multi-factor authentication (MFA) improves security substantially, I’d bet that not a lot of you have confidence that good password hygiene is being practiced by everyone in your organization.
Fortunately, there’s a powerful tool called Okta that virtually eliminates all of these issues.
Okta is a single sign-on (SSO) solution that provides a simple control point for managing and monitoring all user credentials. It makes provisioning new users and deprovisioning departing employees a snap, and it ensures good password practices are adhered to, without asking your users to remember or manage dozens of unique, rigorous passwords.
OKTA Single Sign-On
For admins, all provisioning and deprovisioning for your connected applications and services—Microsoft Office365, Dropbox, G-Suite, Salesforce, AWS, Meraki, whatever—happens in a single interface in Okta. Your hosted applications are connected to Okta, and when you add a new user to your team, you simply select what he or she needs access to (and what level of access), and Okta does the recess. Log in one place and you’re done. Not only does this simplify setting up new employees, but it also standardizes that process and ensures that all accounts are created identically. Without Okta’s oversight on this, there’s no way to guarantee that every account is set up with all the right check boxes ticked and all the right permissions set.
When an employee moves on, deprovisioning is similarly simple: log in to Okta, shut down that user, and Okta does the rest. And with access all managed in one place, you can easily know what your team has access to and make changes as your organization’s needs change. No more guesswork or trying to manage access with spreadsheets.
For users, life with Okta is incredibly easy. Instead of trying to remember strong passwords for every hosted application or service, they have only a single log-in credential to remember: they log in to Okta, which provides seamless to all hosted applications and network resources.
OKTA Adaptive Multi-Factor Authentication
Okta also makes multi-factor authentication (MFA) both more flexible and easier to use. With MFA on, after a user signs on from a computer, Okta will send a push notification to the user’s phone—or, better yet, smart watch, which makes MFA both super convenient and maybe even fun!
Tapping the push notification validates the sign-on, and the user is off and running. Because requiring that additional step every time every user logs in could get irritating fast, Okta allows you to choose which users are required to use MFA and in what circumstances. For instance, you can require that only admins use MFA, or you can geo-fence the MFA by requiring the second level of authentication for any log-on outside a recognized IP address or location.
You can also add MFA to specific applications on top of the MFA required to log in to Okta. For example, logging in to Okta might require an MFA request. You acknowledge that request and gain access to your applications. However, as an added layer of protection‐if, say, you have very sensitive data in your AWS account and want to provide extra security— you can require another MFA authentication when opening that specific application.
The other benefit is that some cloud services and apps don’t support multi-factor authentication natively. Because your users will be signing on through Okta (which does support MFA), access to that other service or app now is gated by a log-on with MFA-level of security.
One final benefit to consider. With all the phishing and spoofing attacks out there, providing your users only a single environment to attend to dramatically decreases the chances that any of your users will fall prey to such an attack. Since there’s no need for them to do anything with, say, their Office365 credentials, they would know that any security-related contact from anything other than Okta is surely fraudulent. It’s not foolproof, of course, but it’s definitely a help.
Password managers are a great tool, but they don’t provide identity and access management. Password managers do make it easier for users to adhere to more stringent password standards, because one master password is all they need to remember rather than one for every login. But password managers don’t provide any of the administrative or management tools that an SSO tool like Okta does.
Provisioning and deprovisioning users would still require logging in to each application or service separately, and there’s no way to manage multi-factor authentication across applications or services. Password managers eliminate the need to remember passwords and can generate more secure passwords, but they don’t really help manage access more broadly. Nice for users, a bit of a help for security, but not much help for systems administrators. It’s also important to remember that password managers don’t ensure that corporate security standards are met, as they leave a lot of decision-making around security to the end user. They’re like a fancy notepad more than a real identity and access management tool integrated into your users’ workflow.
By contrast, with an SSO tool as powerful as Okta, you can dramatically simplify your business operations while also improving security, even as more applications move to the cloud. It’s a big win for users and admins alike.
Have a question about SSO, Okta or other cloud security practices? Drop us a line in the Contact form.