Test your CloudWatch Events rule

Test your new rule by running one of the monitored operations. In this tutorial, the monitored operation is creating an organizational unit (OU). You view the log entry that the Lambda function creates, and you view the email that Amazon SNS sends to subscribers.

Tip

You can also use this tutorial as a guide in conﬁguring similar operations, such as sending email notiﬁcations when account creation is complete. Because account creation is an asynchronous operation, you're not notiﬁed by default when it completes. For more information on using AWS CloudTrail and CloudWatch Events with AWS Organizations, see Logging and monitoring in AWS Organizations (p. 320).

Prerequisites

This tutorial assumes the following:

• You can sign in to the AWS Management Console as an IAM user from the management account in your organization. The IAM user must have permissions to create and conﬁgure a log in CloudTrail, a function in Lambda, a topic in Amazon SNS, and a rule in CloudWatch. For more information about granting permissions, see Access Management in the IAM User Guide, or the guide for the service for which you want to conﬁgure access.

• You have access to an existing Amazon Simple Storage Service (Amazon S3) bucket (or you have permissions to create a bucket) to receive the CloudTrail log that you conﬁgure in step 1.

Important

Currently, AWS Organizations is hosted in only the US East (N. Virginia) Region (even though it is available globally). To perform the steps in this tutorial, you must conﬁgure the AWS Management Console to use that region.

Step 1: Conﬁgure a trail and event selector

In this step, you sign in to the management account and conﬁgure a log (called a trail) in AWS CloudTrail.

You also conﬁgure an event selector on the trail to capture all read/write API calls so that CloudWatch Events has calls to trigger on.

To create a trail

1. Sign in to AWS as an administrator of the organization's management account and then open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.

2. On the navigation bar in the upper-right corner of the console, choose the US East (N. Virginia) Region. If you choose a diﬀerent region, AWS Organizations doesn't appear as an option in the CloudWatch Events conﬁguration settings, and CloudTrail doesn't capture information about AWS Organizations.

3. In the navigation pane, choose Trails.

4. Choose Create trail.

5. For Trail name, enter My-Test-Trail.

6. Perform one of the following options to specify where CloudTrail is to deliver its logs:

• If you already have a bucket, choose No next to Create a new S3 bucket and then choose the bucket name from the S3 bucket list.

• If you need to create a bucket, choose Yes next to Create a new S3 bucket and then, for S3 bucket, enter a name for the new bucket.

Note

S3 bucket names must be globally unique.

7. Choose Create.

8. Choose the trail My-Test-Trail that you just created.

9. Choose the pencil icon next to Management events.

10. For Read/Write events, choose All, choose Save, and then choose Conﬁgure.

CloudWatch Events enables you to choose from several diﬀerent ways to send alerts when an alarm rule matches an incoming API call. This tutorial demonstrates two methods: invoking a Lambda function that can log the API call and sending information to an Amazon SNS topic that sends an email or text message to the topic's subscribers. In the next two steps, you create the components you need: the Lambda function, and the Amazon SNS topic.

Step 2: Conﬁgure a Lambda function

In this step, you create a Lambda function that logs the API activity that is sent to it by the CloudWatch Events rule that you conﬁgure later.

To create a Lambda function that logs CloudWatch Events events

1. Open the AWS Lambda console at https://console.aws.amazon.com/lambda/.

2. If you are new to Lambda, choose Get Started Now on the welcome page; otherwise, choose Create a function.

3. On the Create function page, choose Blueprints.

4. From the Blueprints search box, enter hello for the ﬁlter and choose the hello-world blueprint.

5. Choose Conﬁgure.

6. On the Basic information page, do the following:

a. For the Lambda function name, enter LogOrganizationEvents in the Name text box.

b. For Role, choose Create a custom role and then, at the bottom of the AWS Lambda requires access to your resources page, choose Allow. This role grants your Lambda function

permissions to access the data it requires and to write its output log.

c. Choose Create function.

7. On the next page, edit the code for the Lambda function, as shown in the following example.

console.log('Loading function');

exports.handler = async (event, context) => { console.log('LogOrganizationsEvents');

console.log('Received event:', JSON.stringify(event, null, 2));

return event.key1; // Echo back the first key value // throw new Error('Something went wrong');

};

This sample code logs the event with a LogOrganizationEvents marker string followed by the JSON string that makes up the event.

8. Choose Save.

Step 3: Create an Amazon SNS topic that sends emails to subscribers

In this step, you create an Amazon SNS topic that emails information to its subscribers. You make this topic a "target" of the CloudWatch Events rule that you create later.

To create an Amazon SNS topic to send an email to subscribers

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/.

2. In the navigation pane, choose Topics.

3. Choose Create new topic.

a. For Topic name, enter OrganizationsCloudWatchTopic.

b. For Display name, enter OrgsCWEvnt.

c. Choose Create topic.

4. Now you can create a subscription for the topic. Choose the ARN for the topic that you just created.

5. Choose Create subscription.

Step 4: Create a CloudWatch Events rule

a. On the Create subscription page, for Protocol, choose Email.

b. For Endpoint, enter your email address.

c. Choose Create subscription. AWS sends an email to the email address that you speciﬁed in the preceding step. Wait for that email to arrive, and then choose the Conﬁrm subscription link in the email to verify that you successfully received the email.

d. Return to the console and refresh the page. The Pending conﬁrmation message disappears and is replaced by the now valid subscription ID.

Step 4: Create a CloudWatch Events rule

Now that the required Lambda function exists in your account, you create a CloudWatch Events rule that invokes it when the criteria in the rule are met.

To create a CloudWatch Events rule

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. As before, you must set the console to the US East (N. Virginia) Region or information about Organizations is not available. On the navigation bar in the upper-right corner of the console, choose the US East (N. Virginia) Region.

3. In the navigation pane, choose Rules and then choose Create rule.

4. For Event source, do the following:

a. Choose Event pattern.

b. Choose Build event pattern to match events by service.

c. For Service Name, choose Organizations.

d. For Event Type, choose AWS API Call via CloudTrail.

e. Choose Speciﬁc operation(s) and then enter the APIs that you want monitored: CreateAccount and CreateOrganizationalUnit. You can select any others that you also want. For a complete list of available AWS Organizations APIs, see the AWS Organizations API Reference.

5. Under Targets, for Function, choose the function that you created in the previous procedure.

6. Under Targets, choose Add target.

7. In the new target row, choose the dropdown header and then choose SNS topic.

8. For Topic, choose the topic named OrganizationCloudWatchTopic that you created in the preceding procedure.

9. Choose Conﬁgure details.

10. On the Conﬁgure rule details page, for Name enter OrgsMonitorRule, leave State selected and then choose Create rule.

Step 5: Test your CloudWatch Events rule

In this step, you create an organizational unit (OU) and observe the CloudWatch Events rule generate a log entry and send an email to you with details about the event.

AWS Management Console

To create an OU

1. Open the AWS Organizations console to the AWS accounts page.

2. Choose the check box Root OU, choose Actions, and then under Organizational unit choose Create new.

Step 5: Test your CloudWatch Events rule

3. For the name of the OU, enter TestCWEOU and then choose Create organizational unit.

To see the CloudWatch Events log entry

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation page, choose Logs.

3. Under Log Groups, choose the group that is associated with your Lambda function: /aws/lambda/

LogOrganizationEvents.

4. Each group contains one or more streams, and there should be one group for today. Choose it.

5. View the log. You should see rows similar to the following.

6. Select the middle row of the entry to see the full JSON text of the received event. You can see all the details of the API request in the requestParameters and responseElements pieces of the output.

2017-03-09T22:45:05.101Z 0999eb20-051a-11e7-a426-cddb46425f16 Received event:

{ "version": "0",

"id": "123456-EXAMPLE-GUID-123456",

"detail-type": "AWS API Call via CloudTrail", "source": "aws.organizations",

"account": "123456789012", "time": "2017-03-09T22:44:26Z", "region": "us-east-1",

"resources": [], "detail": {

"eventVersion": "1.04", "userIdentity": { ...

"eventTime": "2017-03-09T22:44:26Z",

"eventSource": "organizations.amazonaws.com", "eventName": "CreateOrganizationalUnit", "awsRegion": "us-east-1",

"sourceIPAddress": "192.168.0.1",

"userAgent": "AWS Organizations Console, aws-internal/3", "requestParameters": {

"parentId": "r-exampleRootId", "name": "TestCWEOU"

"responseElements": { "organizationalUnit": { "name": "TestCWEOU",

"id": "ou-exampleRootId-exampleOUId",

"arn": "arn:aws:organizations::1234567789012:ou/o-exampleOrgId/ou-exampleRootId-exampeOUId"

} },

"requestID": "123456-EXAMPLE-GUID-123456", "eventID": "123456-EXAMPLE-GUID-123456", "eventType": "AwsApiCall"

} }

7. Check your email account for a message from OrgsCWEvnt (the display name of your Amazon SNS topic). The body of the email contains the same JSON text output as the log entry that is shown in the preceding step.

Clean up: Remove the resources you no longer need

To avoid incurring charges, you should delete any AWS resources that you created as part of this tutorial that you don't want to keep.

To clean up your AWS environment

1. Use the CloudTrail console to delete the trail named My-Test-Trail that you created in step 1.

2. If you created an Amazon S3 bucket in step 1, use the Amazon S3 console to delete it.

3. Use the Lambda console to delete the function named LogOrganizationEvents that you created in step 2.

4. Use the Amazon SNS console to delete the Amazon SNS topic named OrganizationsCloudWatchTopic that you created in step 3.

5. Use the CloudWatch console to delete the CloudWatch rule named OrgsMonitorRule that you created in step 4.

6. Finally, use the Organizations console to delete the OU named TestCWEOU that you created in step 5.

That's it. In this tutorial, you conﬁgured CloudWatch Events to monitor your organization for changes.

You conﬁgured a rule that is triggered when users invoke speciﬁc AWS Organizations operations. The rule ran a Lambda function that logged the event and sent an email that contains details about the event.

Best practices for the management account

Best practices for AWS Organizations

We recommend that you follow these best practices when you create and operate your organization.

Topics

• Best practices for the management account (p. 24)

• Best practices for member accounts (p. 27)

Best practices for the management account

Follow these recommendations to help protect the security of the management account in AWS Organizations. These recommendations assume that you also adhere to the best practice of using the root user only for those tasks that truly require it.

Note

AWS Organizations is changing the name of the “master account” to “management account”.

This is a name change only, and there is no change in functionality. You might continue to see a few instances of the old term while we complete the work to transition to the newer term. If you see one we missed, please use the Feedback link at the top of that page to let us know.

Topics

• Use the management account only for tasks that require the management account (p. 24)

• Use a group email address for the management account's root user (p. 25)

• Use a complex password for the management account's root user (p. 25)

• Enable MFA for your root user credentials (p. 25)

• Add a phone number to the account contact information (p. 26)

• Review and keep track of who has access (p. 26)

• Document the processes for using the root user credentials (p. 26)

• Apply controls to monitor access to the root user credentials (p. 27)

Use the management account only for tasks that require the management account

We recommend that you use the management account and its users and roles only for tasks that can be performed only by that account. Store all of your AWS resources in other AWS accounts in the organization and keep them out of the management account. The one exception is that we do recommend that you enable AWS CloudTrail and keep relevant CloudTrail trails and logs in the management account.

One important reason to keep your resources in other accounts is because Organizations service control policies (SCPs) do not work to restrict any users or roles in the management account.

Separating your resources from your management account also help you to understand the charges on your invoices.

Use a group email address for the management account's root user

• Use an email address that is managed by your business. Do not use a public email provider or one that is managed by a third party.

• Use an email address that forwards received messages directly to a list of senior business managers.

In the event that AWS needs to contact the owner of the account, for example, to conﬁrm access, the email message is distributed to multiple parties. This approach helps to reduce the risk of delays in responding, even if individuals are on vacation, out sick, or leave the business.

Use a complex password for the management account's root user

• The security of your account's root user depends on the strength of its password. We recommend that you use a password that is long, complex, and not used anywhere else. Numerous password managers and complex password generation algorithms and tools can help you achieve these goals.

• If you are using a strong password, as described in the previous point, and you rarely access the root user, we recommend that you do not periodically change the password. Changing the password more frequently than you use it increases the risk of compromise.

• Rely on your business' information security policy for managing long-term storage and access to the root user password. This approach might mean that you do any of the following:

• Print the password, and store it in a safe.

• Split the password into pieces, and distribute the pieces to senior business managers.

• Store the password in a password manager system or tool under further controls and processes.

If you do use a password manager, we recommend that it be oﬄine. To avoid creating a circular dependency, do not store the root user password with tools that depend on AWS services that you sign in to with the protected account.

Whatever method you choose, we recommend that the method is resilient and requires multiple actors to be involved to reduce collusion risks.

• Any access of the password or its storage location should be logged and monitored.

Enable MFA for your root user credentials

For instructions on how to enable multi-factor authentication (MFA), see Using multi-factor authentication (MFA) in AWS.

• Use a hardware-based device that does not rely on a battery to generate the one-time password (OTP).

This approach helps ensure that the MFA is impossible to duplicate and isn't subject to battery fade risks while in long-term storage.

• If you do decide to use a battery-based MFA, be sure to add processes to check the device periodically, and replace it when the expiry date approaches.

• Create a plan to handle the logistics of needing to maintain 24/7 access to the token in case it is needed.

• We strongly recommend that you don't re-use that physical MFA for any other purpose than protecting this management account. If you reuse the physical MFA, it can create both operational confusion and unnecessary exposure of the MFA.

Add a phone number to the account contact information

• Store the MFA device according to your information security policy but not in the same place as the associated password for the user. Make sure that the process to access the password and the process to access the MFA require diﬀerent access to diﬀerent resources (people, data, and tools).

• Any access of the MFA device or its storage location should be logged and monitored.

Add a phone number to the account contact information

• Although there are some credible attack vectors against landline, SIP, and mobile phone numbers, overall the risks are outweighed by the complexity of these vectors. If you use this mechanism to recover root access, other factors are available to the AWS Support representative to manage these risks. Therefore, we recommend adding a phone number as a useful additional barrier to the process.

• There are several options for provisioning a phone number, but the one we recommend is a dedicated SIM card and phone, stored long-term in a safe. It’s important to ensure that the team responsible for paying the mobile bill for this phone contract understand the importance of the number even though there will be apparently no calls sent or received by it over long periods of time.

• It’s important that this phone number not be well known within the business. Document it in the AWS Contact Information console page, and share its details with your billing team. Do not document it anywhere else. This approach helps to reduce the risk of the attack vectors associated with moving the phone number tied to the SIM to another SIM.

• Store the phone according to your existing information security policy. However, do not store the phone in the same location as the other related credential information.

• Any access of the phone or its storage location should be logged and monitored.

Review and keep track of who has access

• To ensure you maintain access to the management account, periodically review the personnel within your business who have access to the email address, password, MFA, and phone number associated with it. Align your review with existing business procedures. However, it’s worth adding a monthly or quarterly review of this information to ensure that only the correct people have access.

• Ensure that the process to recover or reset access to the root user credentials is not reliant on any speciﬁc individual to complete. All processes should address the prospect of people being unavailable.

Document the processes for using the root user credentials

• It’s common for important processes, such as the creation of the organization's management account, to be a planned process including multiple steps with multiple personnel. We recommend that you document and publish that plan, including the steps to be performed and their sequence of completion. This approach helps ensure that the decisions made are followed correctly.

• Document the performance of important processes as they are performed to ensure you have a record of the individuals involved in each step and the values used. It’s also important to provide documentation about any exceptions and unforeseen events that occur.

If an exception or unforeseen event does occur, document the time it occurred, who left the room, and what was taken out. You should then also document who returned to the room and what was brought back in.

• Create a suite of published processes about how to use the root user credentials in diﬀerent scenarios, such as resetting the password. If you are at all unsure about the process for interacting with AWS

Apply controls to monitor access to the root user credentials

Support in a speciﬁc scenario, create a support ticket to ask for the latest guidance about how to

在文檔中 AWS Organizations (頁 24-200)