When AWS customers open their first account, they assume the responsibility for securely managing access to their root account credentials, under the Shared Responsibility Model. Initially protected by a password, it is the responsibility of each AWS customer to make decisions based on their operational and security requirements as to how they configure and manage access to this account.
There are many options and decisions both within AWS (configuration of a Multi-Factor Authentication (MFA) device, or providing contact details) and outside (safe logistics, access policies and email configuration), which affect the overall security and availability of the root account credentials, and so there is a great deal of flexibility in the options and configurations each AWS customer may settle on using.
We’re excited to announce the availability of AWS guidance on the recommended approaches that AWS customers should consider and use to protect these credentials both for the management and member accounts of an AWS Organization.
Take a look at root account credential management recommendations for the management account, which also apply to AWS customers operating with a single AWS account,
For the management of member accounts of an AWS Organization, we have a separate set of root account credential management recommendations.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Organizations forum or contact AWS Support.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.
AWS Config enables continuous monitoring of your AWS resources, making it simple to assess, audit, and record resource configurations and changes. AWS Config does this through the use of rules that define the desired configuration state of your AWS resources. AWS Config provides a number of AWS managed rules that address a wide range of security concerns such as checking if you encrypted your Amazon Elastic Block Store (Amazon EBS) volumes, tagged your resources appropriately, and enabled multi-factor authentication (MFA) for root accounts. You can also create custom rules to codify your compliance requirements through the use of AWS Lambda functions.
In this post we’ll show you how to use AWS Config to monitor our Amazon Simple Storage Service (S3) bucket ACLs and policies for violations which allow public read or public write access. If AWS Config finds a policy violation, we’ll have it trigger an Amazon CloudWatch Event rule to trigger an AWS Lambda function which either corrects the S3 bucket ACL, or notifies you via Amazon Simple Notification Service (Amazon SNS) that the policy is in violation and allows public read or public write access. We’ll show you how to do this in five main steps.
Enable AWS Config to monitor Amazon S3 bucket ACLs and policies for compliance violations.
Create an IAM Role and Policy that grants a Lambda function permissions to read S3 bucket policies and send alerts through SNS.
Create and configure a CloudWatch Events rule that triggers the Lambda function when AWS Config detects an S3 bucket ACL or policy violation.
Create a Lambda function that uses the IAM role to review S3 bucket ACLs and policies, correct the ACLs, and notify your team of out-of-compliance policies.
Verify the monitoring solution.
Note: This post assumes your compliance policies require the buckets you monitor not allow public read or write access. If you have intentionally open buckets serving static content, for example, you can use this post as a jumping-off point for a solution tailored to your needs.
At the end of this post, we provide an AWS CloudFormation template that implements the solution outlined. The template enables you to deploy the solution in multiple regions quickly.
Important: The use of some of the resources deployed, including those deployed using the provided CloudFormation template, will incur costs as long as they are in use. AWS Config Rules incur costs in each region they are active.
Architecture
Here’s an architecture diagram of what we’ll implement:
Figure 1: Architecture diagram
Step 1: Enable AWS Config and Amazon S3 Bucket monitoring
The following steps demonstrate how to set up AWS Config to monitor Amazon S3 buckets.
If this is your first time using AWS Config, select Get started. If you’ve already used AWS Config, select Settings.
In the Settings page, under Resource types to record, clear the All resources checkbox. In the Specific types list, select Bucket under S3.
Figure 2: The Settings dialog box showing the “Specific types” list
Choose the Amazon S3 bucket for storing configuration history and snapshots. We’ll create a new Amazon S3 bucket.
Figure 3: Creating an S3 bucket
If you prefer to use an existing Amazon S3 bucket in your account, select the Choose a bucket from your account radio button and, using the dropdown, select an existing bucket.
Figure 4: Selecting an existing S3 bucket
Under Amazon SNS topic, check the box next to Stream configuration changes and notifications to an Amazon SNS topic, and then select the radio button to Create a topic.
Alternatively, you can choose a topic that you have previously created and subscribed to.
Figure 5: Selecting a topic that you’ve previously created and subscribed to
If you created a new SNS topic you need to subscribe to it to receive notifications. We’ll cover this in a later step.
Under AWS Config role, choose Create a role (unless you already have a role you want to use). We’re using the auto-suggested role name.
Figure 6: Creating a role
Select Next.
Configure Amazon S3 bucket monitoring rules:
On the AWS Config rules page, search for S3 and choose the s3-bucket-publice-read-prohibited and s3-bucket-public-write-prohibited rules, then click Next.
Figure 7: AWS Config rules dialog
On the Review page, select Confirm. AWS Config is now analyzing your Amazon S3 buckets, capturing their current configurations, and evaluating the configurations against the rules we selected.
If you created a new Amazon SNS topic, open the Amazon SNS Management Console and locate the topic you created:
Figure 8: Amazon SNS topic list
Copy the ARN of the topic (the string that begins with arn:) because you’ll need it in a later step.
Select the checkbox next to the topic, and then, under the Actions menu, select Subscribe to topic.
Select Email as the protocol, enter your email address, and then select Create subscription.
After several minutes, you’ll receive an email asking you to confirm your subscription for notifications for this topic. Select the link to confirm the subscription.
Step 2: Create a Role for Lambda
Our Lambda will need permissions that enable it to inspect and modify Amazon S3 bucket ACLs and policies, log to CloudWatch Logs, and publishing to an Amazon SNS topic. We’ll now set up a custom AWS Identity and Access Management (IAM) policy and role to support these actions and assign them to the Lambda function we’ll create in the next section.
In the AWS Management Console, under Services, select IAM to access the IAM Console.
Create a policy with the following permissions, or copy the following policy:
Select Lambda from the list of services that will use this role.
Select the check box next to the policy you created previously, and then select Next: Review
Name your role, give it a description, and then select Create Role. In this example, we’re naming the role LambdaS3PolicySecuringRole.
Step 3: Create and Configure a CloudWatch Rule
In this section, we’ll create a CloudWatch Rule to trigger the Lambda function when AWS Config determines that your Amazon S3 buckets are non-compliant.
In the AWS Management Console, under Services, select CloudWatch.
On the left-hand side, under Events, select Rules.
Click Create rule.
In Step 1: Create rule, under Event Source, select the dropdown list and select Build custom event pattern.
Copy the following pattern and paste it into the text box:
The pattern matches events generated by AWS Config when it checks the Amazon S3 bucket for public accessibility.
We’ll add a Lambda target later. For now, select your Amazon SNS topic created earlier, and then select Configure details.
Figure 9: The “Create rule” dialog
Give your rule a name and description. For this example, we’ll name ours AWSConfigFoundOpenBucket
Click Create rule.
Step 4: Create a Lambda Function
In this section, we’ll create a new Lambda function to examine an Amazon S3 bucket’s ACL and bucket policy. If the bucket ACL is found to allow public access, the Lambda function overwrites it to be private. If a bucket policy is found, the Lambda function creates an SNS message, puts the policy in the message body, and publishes it to the Amazon SNS topic we created. Bucket policies can be complex, and overwriting your policy may cause unexpected loss of access, so this Lambda function doesn’t attempt to alter your policy in any way.
Get the ARN of the Amazon SNS topic created earlier.
In the AWS Management Console, under Services, select Lambda to go to the Lambda Console.
From the Dashboard, select Create Function. Or, if you were taken directly to the Functions page, select the Create Function button in the upper-right.
On the Create function page:
Choose Author from scratch.
Provide a name for the function. We’re using AWSConfigOpenAccessResponder.
The Lambda function we’ve written is Python 3.6 compatible, so in the Runtime dropdown list, select Python 3.6.
Under Role, select Choose an existing role. Select the role you created in the previous section, and then select Create function.
Figure 10: The “Create function” dialog
We’ll now add a CloudWatch Event based on the rule we created earlier.
In the Add triggers section, select CloudWatch Events. A CloudWatch Events box should appear connected to the left side of the Lambda Function and have a note that states Configuration required.
Figure 11: CloudWatch Events in the “Add triggers” section
From the Rule dropdown box, choose the rule you created earlier, and then select Add.
Scroll up to the Designer section and select the name of your Lambda function.
Delete the default code and paste in the following code:
import boto3
from botocore.exceptions import ClientError
import json
import os
ACL_RD_WARNING = "The S3 bucket ACL allows public read access."
PLCY_RD_WARNING = "The S3 bucket policy allows public read access."
ACL_WRT_WARNING = "The S3 bucket ACL allows public write access."
PLCY_WRT_WARNING = "The S3 bucket policy allows public write access."
RD_COMBO_WARNING = ACL_RD_WARNING + PLCY_RD_WARNING
WRT_COMBO_WARNING = ACL_WRT_WARNING + PLCY_WRT_WARNING
def policyNotifier(bucketName, s3client):
try:
bucketPolicy = s3client.get_bucket_policy(Bucket = bucketName)
# notify that the bucket policy may need to be reviewed due to security concerns
sns = boto3.client('sns')
subject = "Potential compliance violation in " + bucketName + " bucket policy"
message = "Potential bucket policy compliance violation. Please review: " + json.dumps(bucketPolicy['Policy'])
# send SNS message with warning and bucket policy
response = sns.publish(
TopicArn = os.environ['TOPIC_ARN'],
Subject = subject,
Message = message
)
except ClientError as e:
# error caught due to no bucket policy
print("No bucket policy found; no alert sent.")
def lambda_handler(event, context):
# instantiate Amazon S3 client
s3 = boto3.client('s3')
resource = list(event['detail']['requestParameters']['evaluations'])[0]
bucketName = resource['complianceResourceId']
complianceFailure = event['detail']['requestParameters']['evaluations'][0]['annotation']
if(complianceFailure == ACL_RD_WARNING or complianceFailure == PLCY_RD_WARNING):
s3.put_bucket_acl(Bucket = bucketName, ACL = 'private')
elif(complianceFailure == PLCY_RD_WARNING or complianceFailure == PLCY_WRT_WARNING):
policyNotifier(bucketName, s3)
elif(complianceFailure == RD_COMBO_WARNING or complianceFailure == WRT_COMBO_WARNING):
s3.put_bucket_acl(Bucket = bucketName, ACL = 'private')
policyNotifier(bucketName, s3)
return 0 # done
Scroll down to the Environment variables section. This code uses an environment variable to store the Amazon SNS topic ARN.
For the key, enter TOPIC_ARN.
For the value, enter the ARN of the Amazon SNS topic created earlier.
Under Execution role, select Choose an existing role, and then select the role created earlier from the dropdown.
Leave everything else as-is, and then, at the top, select Save.
Step 5: Verify it Works
We now have the Lambda function, an Amazon SNS topic, AWS Config watching our Amazon S3 buckets, and a CloudWatch Rule to trigger the Lambda function if a bucket is found to be non-compliant. Let’s test them to make sure they work.
We have an Amazon S3 bucket, myconfigtestbucket that’s been created in the region monitored by AWS Config, as well as the associated Lambda function. This bucket has no public read or write access set in an ACL or a policy, so it’s compliant.
Figure 12: The “Config Dashboard”
Let’s change the bucket’s ACL to allow public listing of objects:
Figure 13: Screen shot of “Permissions” tab showing Everyone granted list access
After saving, the bucket now has public access. After several minutes, the AWS Config Dashboard notes that there is one non-compliant resource:
Figure 14: The “Config Dashboard” shown with a non-compliant resource
In the Amazon S3 Console, we can see that the bucket no longer has public listing of objects enabled after the invocation of the Lambda function triggered by the CloudWatch Rule created earlier.
Figure 15: The “Permissions” tab showing list access no longer allowed
Notice that the AWS Config Dashboard now shows that there are no longer any non-compliant resources:
Figure 16: The “Config Dashboard” showing zero non-compliant resources
Now, let’s try out the Amazon S3 bucket policy check by configuring a bucket policy that allows list access:
Figure 17: A bucket policy that allows list access
A few minutes after setting this bucket policy on the myconfigtestbucket bucket, AWS Config recognizes the bucket is no longer compliant. Because this is a bucket policy rather than an ACL, we publish a notification to the SNS topic we created earlier that lets us know about the potential policy violation:
Figure 18: Notification about potential policy violation
Knowing that the policy allows open listing of the bucket, we can now modify or delete the policy, after which AWS Config will recognize that the resource is compliant.
Conclusion
In this post, we demonstrated how you can use AWS Config to monitor for Amazon S3 buckets with open read and write access ACLs and policies. We also showed how to use Amazon CloudWatch, Amazon SNS, and Lambda to overwrite a public bucket ACL, or to alert you should a bucket have a suspicious policy. You can use the CloudFormation template to deploy this solution in multiple regions quickly. With this approach, you will be able to easily identify and secure open Amazon S3 bucket ACLs and policies. Once you have deployed this solution to multiple regions you can aggregate the results using an AWS Config aggregator. See this post to learn more.
If you have feedback about this blog post, submit comments in the Comments section below. If you have questions about this blog post, start a new thread on the AWS Config forum or contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
– седя си аз на един хакатон, и всичко ми се отваря бавно. Поглеждам защо – раздадени са ми ipv6 мрежа и gw, пингва се, но няма ipv6 свързаност, и всичко се опитва в началото да ползва v6, отказва се и минава на v4. Издирват някакси админа, той отговаря “ами аз не съм пускал такова нещо” и т.н., поглеждам – mac адреса на default gw по v4 и тоя, от който ми идват router advertisement-ите е същия.
– “Хора, гръмна ви диск.” “Хора, гръмна ви друг диск.” “Хора, гърмят ви дискове с гигантска скорост, скоро няма да има де да си държите данните.” “Няма де да си държите данните, къде са ви replacement дисковете”…
– Предават се някакви сървъри на нови админи. Логва се стария да покаже нещо, и на конзолата се вижда “Last login преди 8 години”, машините не са update-вани (Debian 4-5).
– “Някой ви е влязъл в сървъра през ipmi-то, направил си е root account и е пуснал minerd. Моля сменете си паролите на IPMI-тата и ги филтрирайте от internet-а, даже производителя им (supermicro) казва, че тия неща не са толкова сигурни.”. Повторение на това – още два пъти в следващите 7-8 месеца, при същите хора.
Има много други такива случаи, но мозъкът ми вече отказва да ги приеме. Ще ми се да направим сървърни социални служби, дето като някой не си се грижи за нещата, да им назначава със съд адмиини, дето да ги поддържат, и на които да плаща собственика на сървърите/мрежата. Безхаберието трябва да е наказуемо, особено в размерите, в които го виждам от време на време…
To help secure your AWS resources, AWS recommends that you follow the AWS Identity and Access Management (IAM) best practice of enabling multi-factor authentication (MFA) for the root user of your account. With MFA turned on, the root user of your account is required to submit one form of authentication, which is the account password, and another form of authentication, such as a one-time password (OTP) from an MFA device. If you have MFA enabled on your root account and you lose or misplace your root MFA device, you can now reset it by using the AWS Management Console.
Now, your root user can use the AWS sign-in page to verify your root account’s email address and phone number. Then, the root user can deactivate the lost MFA device and set up a new MFA device in its place. Note that this information verification feature is available only for AWS root users with a phone number associated with their root account. If your root user does not have a valid phone number associated with your root account, the root user must call AWS Support to reset the lost MFA device.
In this blog post, I demonstrate how to reset a lost MFA device faster by using the AWS Management Console to verify your root user’s email address and phone number. I then demonstrate how to set up a virtual MFA device that you can use in place of the lost MFA device.
Note: This feature is available only to AWS accounts created before September 14, 2017. If you created your account after September 14, 2017, contact AWS Support to reset your lost MFA device.
Reset a lost MFA device
In this section, I demonstrate how to reset a lost MFA device. To reset your MFA device, you must know and have access to the email address and phone number associated with your root account.
Follow these steps to reset your lost MFA device:
Navigate to the AWS sign-in page, and enter your root account’s email address.
On the Root user sign in page, enter the password of your root account.
On the Amazon Web Services Sign In With Authentication Device page, choose Having problems with your authentication device? Click here.
On the Troubleshoot Your Authentication Device page, choose Sign In using alternative factors under Sign In Using Alternative Factors of Authentication.
On Step 1: Email address verification, validate that the email address is correct and choose Send verification email.
AWS sends an email with the subject line, AWS Email Verification, to the address associated with the root account. After the email is sent to your address, you will see Email sent under Step 1, as shown in the following screenshot. If you do not see the verification email in the root user’s inbox, check the spam folder or choose Resend the email under Step 1. After you locate the email, you can close the current browser tab. Follow the directions in the email to proceed with the verification process.
In the email from AWS with the subject line, AWS Email Verification, choose Verify your email address.
When you click the verification link, your email is verified and you are taken to Step 2 of the verification process. In Step 2: Phone number verification, choose Call me now to start the phone number verification process.
Answer the phone call from AWS and use your phone’s keypad to submit the six-digit verification code that appears on your computer screen.
After you have verified your root account’s email address and phone number, proceed to Step 3: Sign In. In Step 3, choose Sign in to the console to sign in to the AWS Management Console.
You automatically are redirected to the Your Security Credentials page. If your MFA device is lost, deactivate the MFA device by choosing Deactivate (see the following screenshot). If you find your MFA device later, you can reactivate it on the same Your Security Credentials page. (A reactivated device is treated like a new device, so choose Activate MFA to reactivate a device.)
You have successfully deactivated your lost MFA device. You will no longer see any details associated with the lost MFA device in the console. You now will see an Activate MFA option (see the following screenshot) that you can use to activate a new MFA device.
We recommend that you enable a new MFA device on your root account as soon as possible to ensure that your root account is protected by MFA. If you find your lost MFA device, you can reactivate it (see Step 9 earlier in this post).
In place of your lost MFA device, you can use a virtual MFA device to ensure that your root account remains protected by MFA. In the next section, I show how to set up a virtual MFA device and associate it with your root account.
Associate a virtual MFA device with your root account
After you deactivate your lost MFA device, you can associate a virtual MFA device with your root account to help secure your AWS resources. You need to download a virtual MFA app such as Google Authenticator or Authy 2-Factor Authentication to use virtual MFA with your AWS account.
To associate a virtual MFA device with your root account:
Choose Activate MFA on the Your Security Credentials page.
Choose a virtual MFA device and then choose Next Step.
If you do not have an AWS MFA-compatible application, install one of the available applications. Choose Next Step.
Open the virtual MFA app on your phone and choose the option to create a new account.
Use the app to scan the QR code on your computer screen. Alternatively, you can choose Show secret key for manual configuration, and then type the secret key in the MFA app.
In the Authentication code 1 box, type the OTP that appears in the virtual MFA app. Wait for up to 30 seconds for the app to generate a second OTP. Type the second OTP in the Authentication code 2 box and then choose Activate virtual MFA.
You have now successfully enabled virtual MFA and associated it with your root account, and your root account is now protected by using MFA. You will use the virtual MFA app to generate an authentication code for subsequent sign-ins.
Summary
In this blog post, I demonstrated how you can reset your AWS root account’s lost MFA device by using the AWS Management Console. I also showed how you can associate a virtual MFA device with your root account.
If you have comments about resetting an MFA device for root users, submit them in the “Comments” section below. If you have implementation questions, start a thread on the IAM forum or contact AWS Support.
Today, AWS made improvements to the way you sign in to your AWS account. Whether you sign in as your account’s root user or an AWS Identity and Access Management (IAM) user, you can now sign in from the AWS Management Console’s homepage. This means that if you sign in as an IAM user, you no longer have to use an account-specific URL. However, the account-specific URL you have used in the past to sign in will continue to work.
In the new sign-in experience, you can sign in from the home page using either your root user’s or IAM user’s credentials. In the first step, root users enter their email address; IAM users enter their account ID (or account alias). In the second step, root users enter their password; IAM users enter their user name and password.
In this blog post, I explain the improvements to the way you sign in to your AWS account as a root user or IAM user. If you use a password manager to help you sign in to your account, you may need to make updates so that it will work with the new sign-in experience.
The new sign-in experience
The new AWS sign-in experience allows both root users and IAM users to sign in using the Sign In to the Console link on the AWS Management Consoles’s home page.
Step 1: For root users and IAM users
As shown in the following screenshot, to sign in as a root user, type the email address associated with the root account. To sign in as an IAM user, type an AWS account ID or account alias. Then choose Next to proceed to Step 2.
If you usually sign in using the same browser and allow the browser to store AWS cookies, you will skip Step 1 on subsequent sign-in attempts. If you regularly switch users or accounts, AWS recommends that you prevent the sign-in page from storing AWS cookies.
Step 2: For root users
If you entered the email address associated with the root account in Step 1, you were taken to the second step to sign in to the root account, as shown in the following screenshot. Type the password of the root account and choose Sign in. If you enabled multi-factor authentication (MFA) for your root account, you will then be prompted to enter the code from your MFA device. After successful authentication, you will be signed in to the AWS Management Console, and your account’s home page will be displayed.
Step 2: For IAM users
If you entered an AWS account ID or account alias in Step 1, you were taken to the second step to sign in as an IAM user, as shown in the following screenshot. Type the user name and password of the IAM user, and choose Sign in. If MFA has been enabled for your IAM user, you will then be prompted to enter the code from your MFA device. After successful authentication, your account’s home page will be displayed.
With these changes, you may need to make updates to password managers so that they will work with the new sign-in experience.
If you have comments about the changes to how you sign in to your AWS account as a root user or IAM user, submit a comment in the “Comments” section below. If you have questions, start a new thread on the IAM forum.
Coming soon, AWS will improve the way you sign in to your AWS account. Whether you sign in as your account’s root user or an AWS Identity and Access Management (IAM) user, you will be able to sign in from the AWS Management Console’s home page. This means that if you sign in as an IAM user, you will no longer be required to use an account-specific URL. However, the account-specific URL you use to sign in today will continue to work.
In the new sign-in experience, you can sign in from the homepage using either your root user’s or IAM user’s credentials. In the first step, root users will enter their email address; IAM users will enter their account ID (or account alias). In the second step, root users will enter their password; IAM users will enter their user name and password.
In this blog post, I explain the improvements that are coming soon to the way you sign in to your AWS account as a root user or IAM user. If you use a password manager to help you sign in to AWS or if you use saved bookmarks or settings, you may need to make updates so that they will work with the new sign-in experience.
The new sign-in experience
The new AWS sign-in experience will allow both root users and IAM users to sign in using the Sign In to the Console link on the AWS home page.
Step 1: For root users and IAM users
As shown in the following screenshot, to sign in as a root user, you will type the email address associated with the root account. To sign in as an IAM user, you will type an AWS account ID or account alias. You will then choose Next to proceed to Step 2.
If you usually sign in using the same browser and allow the browser to store AWS cookies, you will skip Step 1 on subsequent sign-in attempts. If you regularly switch users or accounts, AWS recommends that you prevent the sign-in page from storing AWS cookies.
Step 2: For root users
If you enter the email address associated with the root account in Step 1, you will be taken to the second step of signing in to the root account, as shown in the following screenshot. Type the password of the root account and choose Sign in. If you enabled multi-factor authentication (MFA) for your root account, you will then be prompted to enter the code from your MFA device. After successful authentication, you will be signed in to the AWS Management Console, and the homepage of your root account will be displayed.
Step 2: For IAM users
If you enter an AWS account ID or account alias in Step 1, you will be taken to the second step for signing in as an IAM user, as shown in the following screenshot. Type the user name and password of the IAM user, and choose Sign in. If MFA has been enabled for your IAM user, you will then be prompted to enter the code from your MFA device. After successful authentication, the IAM user home page will be displayed.
With these changes, you may need to make updates to password managers and bookmarks so that they will work with the new sign-in experience. We will publish another Security Blog post when the updated sign-in experience is available.
If you have comments about the upcoming changes to how your root user and IAM users will sign in to your AWS account, enter a comment in the “Comments” section below. If you have questions, start a new thread on the IAM forum.
After you create your first AWS account, you might be tempted to start immediately addressing the issue that brought you to AWS. For example, you might set up your first website, spin up a virtual server, or create your first storage solution. However, AWS recommends that first, you follow some security best practices to help protect your AWS resources. In this blog post, I explain why you should follow AWS security best practices, and I link to additional resources so that you can learn more about each best practice.
Best practices to help secure your AWS resources
When you created an AWS account, you specified an email address and password you use to sign in to the AWS Management Console. When you sign in using these credentials, you are accessing the console by using your root account. Following security best practices can help prevent your root account from being compromised, which is an important safeguard because your root account has access to all services and resources in your account.
Create a strong password for your AWS resources
To help ensure that you protect your AWS resources, first set a strong password with a combination of letters, numbers, and special characters. For more information about password policies and strong passwords, see Setting an Account Password Policy for IAM Users. This also might be a good opportunity to use a third-party password management tool, which you can use to not only create strong passwords but also share those credentials securely with other members of your organization.
Use a group email alias with your AWS account
If for any reason you are unavailable to respond to an AWS notification or manage your AWS Cloud workloads, using a group email alias with your AWS account means other trusted members of your organization can manage the account in your absence. To update the email address used with your account, see Managing an AWS Account.
Enable multi-factor authentication
Multi-factor authentication (MFA) is a security capability that provides an additional layer of authentication on top of your user name and password. When using MFA, after you sign in with your user name and password (what you know), you must also provide an additional piece of information that only you have physical access to (what you have), which can come from a dedicated MFA hardware device or an app on a phone.
You must select the type of MFA device you want to use from the list of supported MFA devices. For a hardware device, ensure that you keep the MFA device in a secure location. If you are using a virtual MFA device (such as an app on your phone), you should think about what might happen if your phone is lost or damaged. One approach is to keep the virtual MFA device you use in a safe place. Another option is to activate more than one device at the same time or use a virtual MFA option that has options for device key recovery. To learn more about MFA, watch this video, and see Securing Access to AWS Using MFA and Enabling a Virtual Multi-Factor Authentication (MFA) Device.
Set up AWS IAM users, groups, and roles for daily account access
To manage and control access and permissions to your AWS resources, use AWS Identity and Access Management (IAM) to create users, groups, and roles. When you create an IAM user, group, or role, it can access only the AWS resources to which you explicitly grant permissions, which is also known as least privilege.
You can allow programmatic access to your AWS resources from the command line or for use with AWS APIs. However, AWS recommends that you do not create or use the access keys associated with your root account for programmatic access. In fact, if you still have access keys, delete them. Instead, create an IAM user and grant that user only the permissions needed for the APIs you are planning to call. You can then use that IAM user to issue access keys. To learn more, see Managing Access Keys for Your AWS Account.
As your AWS use grows or if you begin managing multiple AWS accounts, you might need to start diving deeper into security topics. For more information, see the following:
If you have comments about this post, submit them in the “Comments” section below. If you have questions about or issues implementing these best practices, please start a new thread on the IAM forum.
– Andy
The collective thoughts of the interwebz
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.