In Amazon Web Services, there are two different privileged accounts. One is defined as Root User and the other is defined as an IAM User. In this blog, I will break down the differences of an AWS Root User versus an IAM account, when to use one account versus the other, and best practices for protection of these identities in the cloud. The AWS Root User is the first cloud service identity created by default when you create your cloud service provider account. It is important to note-all cloud service providers have some form of root account. Depending on the provider, you may be allowed to have more than one such account. The more root accounts you have, the larger the risk surface. Because of its omnipotence, the AWS root account is a prime target for threat actors because it can control everything in your instance and in your account profile. As a security best practice, the default root account should be disabled, or even deleted, and never used unless absolutely necessary. With the above considerations in mind, avoid using your root user to perform everyday tasks. To mitigate the risks of the default root account, organizations should create an IAM user with administrative-like privileges to manage their AWS environment in adherence to the principle of least privilege. An AWS IAM User can be created by a root user or another IAM user who has entitlements to create additional IAM users. Can authenticate or start a remote session using their IAM User credentials and their Account ID or alias, if entitlement is granted Can correspond to a human, application, process, or another machine-based identity Depending on the use case, individual IAM users can be assigned to entitlements or role-based-access groups AWS Root User versus IAM User. An AWS IAM user granted administrative privileges can do almost everything a root user can do, except for a few tasks that are restricted to the root account. If you delete the root account, which some security professionals may advocate, these changes will be permanently inaccessible. This is particularly important if you plan to change providers, or the account is ephemeral for testing or development Changing many of your cloud service provider account settings, like the root email address Changing your support plan and billing information Enabling or disabling specific security controls, like MFA, to manage key runtime parameters, like deletion. Regardless of the account type, the cloud represents unique challenges for all identities. Do not use your root user access key for anything except for those rare use cases where it is absolutely unavoidable. If the cloud provider allows for it, consider disabling root, or even deleting the root account, if you can overcome the potential issues listed above Enable MFA for all your root users, as well as for all IAM users. Single-factor authentication should never be used for cloud access Never share your root user or IAM users credentials with anyone for anything, at any time Create separate IAM users for anyone who needs access to an account. Accounts should never be shared-even for machine identities Implement least privilege access for your IAM users - always! Consider this identity Fully closed, since most cloud service providers do not grant any privileges upon account creation. Broadly using highly privileged, superuser accounts like root or administrator, even with MFA enabled, can introduce unnecessary risk. Limiting privileged access exposure is critical to mitigating risks for all identities in the cloud. Identities in the cloud are different than identities on premise. On premise, we generally think of identities in the form of accounts. In the cloud, and for a mature cybersecurity practices, organizations should think of identities first. This allows the concept of identities to be applied to abstract cloud concepts like entitlements and principals, in addition to traditional security controls like privileges, permissions, and rights. If you consider the identity first, all the controls needed for your security policies and management can be defined for an identity to ensure complete coverage. This not only includes the controls listed above, but also the workflow for a successful identity governance solution including the joiner, mover, leaver concepts. BeyondTrust considers identities first in managing risks and policy in the cloud. With comprehensive cloud-based identity discovery and automation, BeyondTrust can help identify risks in the cloud based on identities and integrate with leading IGA solutions, such as by using SCIM, to complete identity management
This Cyber News was published on www.beyondtrust.com. Publication date: Wed, 01 Feb 2023 01:18:02 +0000