Periodic update - 12/08/19-11:14am PT

doc_source/access-analyzer-archive-rules.md

@@ -0,0 +1,58 @@
+# Archive Rules<a name="access-analyzer-archive-rules"></a>
+
+Archive rules automatically archive new findings that meet the criteria you define when you create the rule\. For example, you can create an archive rule to automatically archive any findings for a specific S3 bucket that you regularly grant access to\. Or if you grant access to multiple resources to a specific principal, you can create a rule that automatically archives any new finding generated for access granted to that principal\. This lets you focus only on active findings that may indicate a security risk\.
+
+Use the information provided in the finding details to identify the specific resource and external entity to use when creating or editing a rule\. Wnen you create an archive rule, only new findings that match the rule criteria are automatically archived\. Existing findings are not automatically archived\.
+
+**Note**  
+When you create or edit an archive rule, Access Analyzer does not validate the values you include in the filter for the rule\. For example, if you add a rule to match an AWS Account, Access Analyzer accepts any value in the field, even if it is not a valid AWS account number\.
+
+**To create an archive rule**
+
+1. Open the IAM console at [https://console\.aws\.amazon\.com/iam/](https://console.aws.amazon.com/iam/)\.
+
+1. Choose **Access analyzer**, then choose **Archive rules**\.
+
+1. Choose **Create archive rule**\.
+
+1. Enter a name for the rule if you want to change the default name\.
+
+1. In the **Rule** section, under **Criteria**, select a property to match for the rule\.
+
+1. Choose an operator for the property value, such as **contains**\.
+
+   The operators available depend on the property you choose\.
+
+1. Optionally, add additional values for the property, or add additional criteria for the rule\.
+
+   To add another value for a criterion, choose **Add another value**\. To add another criterion for the rule, choose the **Add** button\.
+
+1. When finished added criteria and values, choose **Create archive rule**\.
+
+For example, to create a rule that automatically archives any findings for S3 buckets: choose **Resource type**, and then choose **is** for the operator\. Next choose **S3 bucket** from the **Select resource type** list, and then choose **Add**\.
+
+Continue to define criteria to customize the rule as appropriate for your environment, and then choose **Create archive rule**\.
+
+If you are create a new rule and add multiple criteria, you can remove a single criterion from the rule by choosing **Remove this criterion**\. You can remove a value added for a criterion by choosing **Remove value**\.
+
+**To edit an archive rule**
+
+1. Choose name of the rule to edit in the **Name**\.
+
+   You can edit only one archive rule at a time\.
+
+1. Add new or remove the existing criteria and values for each criterion\.
+
+1. Choose **Save changes**\.
+
+**To delete an archive rule**
+
+1. Select the check box for the rules to delete\.
+
+   You can delete one, many, or all rules at the same time\.
+
+1. Choose **Delete**\.
+
+1. Type **delete** in the **Delete archive rule** confirmation dialog, and then choose **Delete**\.
+
+The rules are deleted only from the analyzer in the current Region\. You must delete archive rules separately for each analyzer that you created in other Regions\.

doc_source/access-analyzer-concepts.md

@@ -0,0 +1,11 @@
+# How Access Analyzer Works<a name="access-analyzer-concepts"></a>
+
+This topic describes the concepts and terms that are used in Access Analyzer to help you become familiar with how Access Analyzer monitors access to your AWS resources\.
+
+IAM Access Analyzer is built on [Zelkova](https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/), which translates IAM policies into equivalent logical statements, and runs a suite of general\-purpose and specialized logical solvers \(satisfiability modulo theories\) against the problem\. Access Analyzer applies Zelkova repeatedly to a policy with increasingly specific queries to characterize classes of behaviors the policy allows, based on the content of the policy\. To learn more about satisfiability modulo theories, see [Satisfiability Modulo Theories](https://people.eecs.berkeley.edu/~sseshia/pubdir/SMT-BookChapter.pdf)\.
+
+Access Analyzer does not examine access logs to determine whether an external entity accessed a resource within your zone of trust\. It generates a finding when a resource\-based policy allows access to a resource, even if the resource was not accessed by the external entity\. Access Analyzer also does not consider the state of any external accounts when making its determination\. That is, if it indicates that account 11112222333 can access your S3 bucket, it knows nothing about the state of users, roles, service control policies \(SCP\), and other relevant configurations in that account\. This is for customer privacy – Access Analyzer doesn't consider who owns the other account\. It is also for security – if the account is not owned by the Access Analyzer customer, it is still important to know that an external entity could gain access to their resources even if there are currently no principals in the account that could access the resources\.
+
+Access Analyzer considers only certain IAM condition keys that external users cannot directly influence, or that are otherwise impactful to authorization\.
+
+Access Analyzer does not currently report findings from AWS service principals or internal service accounts\. In rare cases where Access Analyzer isn't able to fully determine whether a policy statement grants access to an external entity, it errs on the side of declaring a false positive finding\. Access Analyzer is designed to provide a comprehensive view of the resource sharing in your account, and strives to minimize false negatives\.

doc_source/access-analyzer-eventbridge.md

@@ -0,0 +1,129 @@
+# Monitoring AWS IAM Access Analyzer with Amazon EventBridge<a name="access-analyzer-eventbridge"></a>
+
+Use the information in this topic to learn how to monitor Access Analyzer findings with Amazon EventBridge\. EventBridge is the new version of Amazon CloudWatch Events\.
+
+## Findings Events<a name="access-analyzer-events-findings"></a>
+
+Access Analyzer sends an event to EventBridge for each generated finding, for a change to the status of an existing finding, and when a finding is deleted\. To receive findings and notifications about findings, you must create an event rule in Amazon EventBridge\. When you create an event rule, you can also specify a target action to trigger based on the rule\. For example, you could create an event rule that triggers an Amazon SNS topic when an event for a new finding is received from Access Analyzer\.
+
+## Event Notification Frequency<a name="access-analyzer-event-frequency"></a>
+
+Access Analyzer sends events for new findings and findings with status updates to EventBridge within about an hour from when the event occurs in your account\. Access Analyzer also sends events to EventBridge when a resolved finding is deleted because the retention period has expired\. For findings that are deleted because the analyzer that generated them is deleted, the event is sent to EventBridge approximately 24 hours after the analyzer was deleted\. When a finding is deleted, the finding status is not changed\. Instead, the `isDeleted` attribute is set to `true`\.
+
+## Example Event<a name="access-analyzer-event-example"></a>
+
+The following is an example Access Analyzer event sent to EventBridge\. The `id` listed is the ID for the event in EventBridge\. To learn more, see [Events and Event Patterns in EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-and-event-patterns.html)\.
+
+In the `detail` blob, the values for the `accountId` and `region` attributes refer to the account and Region reported in the finding\. The `isDeleted` attribute indicates whether the event was from the finding being deleted\.
+
+```
+{
+    "version": "0",
+    "id": "22222222-dcba-4444-dcba-333333333333",
+    "detail-type": "Access Analyzer Finding",
+    "source": "aws.access-analyzer",
+    "account": "111122223333",
+    "time": "2019-11-21T01:22:33Z",
+    "region": "us-west-2",
+    "resources": ["arn:aws:access-analyzer:us-west-2:111122223333:analyzer/MyAnalyzer"],
+    "detail": {
+        "version": "1.0",
+        "accountId": "111122223333",
+        "region": "us-west-2",
+        "isDeleted": false
+    }
+}
+```
+
+The following example shows data for an event that is sent to EventBridge from the `GetFinding` operation of the Access Analyzer API\.
+
+```
+"version": "0",
+  "id": "22222222-dcba-4444-dcba-333333333333",
+  "status": "ACTIVE",
+  "resourceType": "AWS::S3::Bucket",
+  "resource": "arn:aws:s3:::my-bucket",
+  "createdAt": "2019-11-20T04:58:50Z",
+  "analyzedAt": "2019-11-21T01:22:22Z",
+  "updatedAt": "2019-11-21T01:14:07Z",
+  "principal": {"AWS": "999988887777"},
+  "action": ["s3:GetObject"],
+  "condition": {},
+  "isPublic": false
+```
+
+Access Analyzer also sends events to EventBridge for error findings\. An error finding is a finding generated when Access Analyzer can't access a resource it tries to analyze\. Events for error findings include an `error` attribute as shown in the following example\.
+
+```
+"id": "22222222-dcba-4444-dcba-333333333333",
+"status": "ACTIVE",
+"resourceType": "AWS::S3::Bucket",
+"resource": "arn:aws:s3:::my-bucket",
+"error": "ACCESS_DENIED",
+"createdAt": "2019-10-16T19:21:44.244Z",
+"analyzedAt": "2019-10-16T19:21:44.244Z",
+"updatedAt": "2019-10-16T19:21:44.244Z"
+```
+
+## Creating an Event Rule with a Target<a name="access-analyzer-create-rule"></a>
+
+The following procedure describes how to create an event rule using the console\.
+
+Open the Amazon EventBridge console at [https://console\.aws\.amazon\.com/events/](https://console.aws.amazon.com/events/)\.
+
+1. Choose **Create rule**\.
+
+1. Enter a **Name** and, optionally, a **Description**\.
+
+1. Under **Define pattern** choose **Event pattern**, then choose **Custom pattern**\.
+
+1. Copy the following example and then paste it into the **Event pattern** box\.
+
+   ```
+   {
+     "source": [
+       "aws.access-analyzer"
+     ],
+     "detail-type": [
+       "Access Analyzer Finding"
+     ]
+   }
+   ```
+
+1. Choose **Save**\.
+
+1. Under **Select targets**, choose a **Target** action for the rule, such as an Amazon SNS topic or AWS Lambda function\. 
+
+1. Choose the specific SNS topic or Lambda function to use when the target is triggered\.
+
+   The target is triggered when an event is received that matches the event pattern defined in the rule\.
+
+1. Choose **Save** to create the rule\.
+
+To learn more about creating rules, see [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)\.
+
+### Create a Rule Using the CLI<a name="access-analyzer-create-rule-cli"></a>
+
+1. Use the following to create a rule for Amazon EventBridge using the AWS CLI\. Replace the rule name *TestRule* with the name for your rule\.
+
+   ```
+   aws events put-rule --name TestRule --event-pattern "{\"source\":[\"aws.access-analyzer\"]}"
+   ```
+
+1. You can customize the rule to trigger target actions only for a subset of generated findings, such as findings with specific attributes\. The following example demonstrates how to create a rule that triggers a target action only for findings with a status of Active\.
+
+   ```
+   aws events put-rule --name TestRule --event-pattern "{\"source\":[\"aws.access-analyzer\"],\"detail-type\":[\"Access Analyzer Finding\"],\"detail\":{\"status\":[\"ACTIVE\"]}}"
+   ```
+
+1. To define a Lambda function as a target for the rule you created, use the following example command\. Replace the Region and the function name in the ARN as appropriate for your environment\.
+
+   ```
+   aws events put-targets --rule TestRule --targets Id=1,Arn=arn:aws:lambda:us-east-1:111122223333:function:MyFunction
+   ```
+
+1. Add the permissions required to invoke the rule target\. The following example demonstrates how to grant permissions to a Lambda function, following the preceding examples\.
+
+   ```
+   aws lambda add-permission --function-name MyFunction --statement-id 1 --action 'lambda:InvokeFunction' --principal events.amazonaws.com
+   ```

doc_source/access-analyzer-findings-archive.md

@@ -0,0 +1,21 @@
+# Archiving Findings<a name="access-analyzer-findings-archive"></a>
+
+When you get a finding for access to a resource that is intentional, such as an IAM role that is used by multiple users for approved workflows, you can archive the finding\. When you archive a finding it is cleared from Active findings list, letting you focus on the findings you need to resolve\. Archived findings aren't deleted\. You can filter the Findings page to display your archived findings, and unarchive them at any time\.
+
+To archive findings from the **Findings** page
+
+1. Select the check box next to one or more findings to archive\.
+
+1. Choose **Archive**\.
+
+   A confirmation is displayed at the top of the screen\.
+
+To archive findings from the **Findings Details** page\.
+
+1. Choose the **Finding ID** for the finding to archive\.
+
+1. Choose **Archive**\.
+
+   A confirmation is displayed at the top of the screen\.
+
+To unarchive findings, repeat the preceding steps, but choose **Unarchive** instead of **Archive**\. When you unarchive a finding, the status is set to Active\.