Preparing and Registering AWS

Configure AWS for authentication using an IAM User or an IAM role, using within-account or cross-account logging. Configure an identity provider (IDP) for single sign-on if users log in to AWS through an IDP.

The steps to connect your AWS accounts to Oracle CASB Cloud Service are different, depending on several parameters of your AWS architecture.

Monitoring can be configured in two ways:
- By using an IAM User as the dedicated service account.
- By using an IAM Role in lieu of the dedicated service account.
Logging can also be configured in two ways:
- Within-account logging, in which each AWS account maintains CloudTrail logs within that same account.
- Cross-account logging, in which some or all AWS source accounts (source accounts) send their CloudTrail logs to a single target account’s S3 bucket.

To set up AWS for monitoring by Oracle CASB Cloud Service

If you prefer that Oracle CASB Cloud Service uses IAM Users to monitor your AWS instances:

If users log in to AWS using a supported IDP for single sign-on, start with Setting Up an Identity Provider Instance.

Note:
You can register your AWS instance without an IDP configured and add the IDP at a future time. See Updating the IDP Instance for an AWS Instance.
Then go to Using an IAM User: Creating and Registering a Dedicated Service User.
Then, if you use cross-account logging, continue with Using an IAM User: Adding Source Dedicated Service Users for Cross-Account Logging.

If your AWS architecture uses an IAM Role to monitor your AWS instances:

If users log in to AWS using a supported IDP for single sign-on, start with Setting Up an Identity Provider Instance

Note:
You can register your AWS instance without an IDP configured and add the IDP at a future time. See Updating the IDP Instance for an AWS Instance.
Then go to Using an IAM Role: Creating a Dedicated Service Role.
Then, if you use cross-account logging, continue with Using an IAM Role: Adding Source Dedicated Service Roles for Cross-Account Logging.

Using an IAM Role: Creating a Dedicated Service Role

Enable CloudTrail, and then create and register a dedicated account.

Using an IAM Role: Enabling CloudTrail

In order for CASB Cloud Service to monitor your AWS account, you must first enable both CloudTrail and S3 services.

Enabling CloudTrail and S3 allows the IAM account to read the AWS service and the CloudTrail logs in S3.

Log into your AWS console.
Select Services, and under Management Tools, click CloudTrail.

If CloudTrail is not enabled, then on the AWS CloudTrail screen you see a blue Get Started Now button.

If you do not see the blue Get Started Now button, CloudTrail is enabled — go to step 4.

If you do see the blue Get Started Now button, CloudTrail is not enabled — continue with the substeps below:

Click the blue Get Started Now button to begin the process of enabling CloudTrail.
On the Turn on CloudTrail page, enter a Trail name.

Note:
Ensure that you note the region in the top right corner of the page.

This name can be anything you like, as long as it is unique within your AWS account.
Leave the default setting of Apply trail to all regions set to Yes, and Read/Write events set to All.
Scroll to the Storage location section at the bottom of the page.

To create a new bucket (note that your S3 bucket will be created in the region in step 4b above):

Leave the default setting of Apply trail to all regions set to Yes, enter a name for the bucket in the S3 bucket field, and then click Advanced.
If you want to use a log file prefix to change the default location of the CloudTrail logs, enter the prefix in the Log file prefix field.

This will change the path to the S3 bucket policy to include the prefix.
If you want to encrypt CloudTrail, set Encrypt log files to Yes and select Yes to Create a new KMS key or No to use an existing key.

Note:
Your KMS (Key Management Service) must be in the same AWS region as your S3 bucket (noted in step 4b above) where your encrypted CloudTrail logs are stored.
Click Create.

If you chose to encrypt your CloudTrail in step 4.e.ii above, validate your KMS settings: The policy must contain the following statements. You can find the KMS policy by going to Services, IAM, Encryption Keys, changing the region to where you created your S3 bucket (step 4.b above) and clicking on the Key Name in the Alias column and reviewing the Key Policy:

{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::965634374182:user/testLocalUser"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Enable CloudTrail Encrypt Permissions",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "kms:GenerateDataKey*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:<AWSaccountnumber>:trail/*"
        }
      }
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

Validate your CloudTrail settings:
1. On the Trails page, click the CloudTrail name.
2. On the Configuration page, verify that the CloudTrail you just created has the settings specified in the previous steps.
3. Ensure that the CloudTrail is enabled for all regions in Trail Settings, and is capturing all events in Management events.

Validate your S3 settings:

Select Services, and under Storage, select S3.
Click the bucket name to display four tabs across the top.

Click the Permissions tab, and then click the Bucket Policy button.

The Bucket policy editor displays the policy in JSON format that was automatically created for your S3 bucket.

Ensure that the policy contains GetBucketAcl and PutObject, shown in bold below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::<bucket_name>"
        },
        {
            "Sid": "AWSCloudTrailWrite<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<bucket_name>/LORIC/AWSLogs/<AWSaccountnumber>/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

To use an existing bucket:

Change the default setting of Create a new S3 bucket to No and enter a name for the bucket in the S3 bucket field and click Advanced.

If you want to encrypt CloudTrail, set Encrypt log files to Yes.

Select Yes to Create a new KMS key or No to use an existing key.

Note:
Your KMS key must be in the same AWS region as your S3 bucket where your encrypted CloudTrail logs are stored.

Verify that your KMS policy contains the following statements by going to Services, IAM, Encryption Keys and changing the region to where you are creating your S3 bucket (step 4b above):

{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::965634374182:user/testLocalUser"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Enable CloudTrail Encrypt Permissions",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "kms:GenerateDataKey*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:<AWSaccountnumber>:trail/*"
        }
      }
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

If you want to use a log file prefix to change the default location of the CloudTrail logs, enter the prefix in the Log File Prefix field.

This will change the path in the S3 bucket policy to include the prefix.
To review the S3 bucket policy, select Services, and under Storage, select S3.

Click the bucket name, then click the Permissions tab, and click the Bucket Policy button.

Ensure that the policy contains GetBucketAcl and PutObject, shown in bold below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::<bucket_name>"
        },
        {
            "Sid": "AWSCloudTrailWrite<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<bucket_name>/LORIC/AWSLogs/<AWSaccountnumber>/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

If CloudTrail is already enabled, follow the substeps below.

It is recommended that you enable CloudTrail for all regions.

Ensure that all events are being logged.
1. From the Dashboard page, select Trails on the left.
2. On the Trails page, in the Name column, click the name of the CloudTrail.
3. Ensure that Apply trail to all regions is set to Yes.
  
  To change the setting, click the Edit icon to the right of Trail settings.
4. Ensure that Read/Write events is set to All.
  
  To change the setting, click the Edit icon to the right of Management events.
5. Ensure that the S3 bucket name is what you want to use.
  
  To create a new bucket to use, click the Edit icon to the right of Storage location.
6. If you want to encrypt CloudTrail, click the Edit icon to the right of Storage location, set Encrypt log files to Yes, and then set Create a new KMS key to:
  - Yes to create a new key.
  - No to use the existing key that you specify in the KMS key field.
  Note:
  Your KMS (Key Management Service) key must be in the same AWS region as your S3 bucket (noted in step 4b above) where your encrypted CloudTrail logs are stored.
Ensure that you have clicked Save at the bottom of each section where you made a change before you leave this page.

What to Do Next

Continue with Using an IAM Role: Creating and Registering a Dedicated Service Role.

Using an IAM Role: Creating and Registering a Dedicated Service Role

Create a dedicated AWS account and add or register the account with Oracle CASB Cloud Service for monitoring.

To watch a video that provides an overview of the steps in this task, see Creating and Registering a Target AWS Account Using an IAM Role.

Prerequisites:

You have successfully completed the steps in Using an IAM Role: Enabling CloudTrail.
If users log in to AWS through an identity provider, you have already created an identity provider instance in Oracle CASB Cloud Service. See Setting Up an Identity Provider Instance.

Log in to the AWS account that you will be registering in Oracle CASB Cloud Service.
In the AWS console, select Services, then under Security, Identity and Compliance select IAM.
On the Welcome to Identity and Access Management page, select Roles in the left navigation panel.

Here you will create the monitoring role for a stand-alone account, or the target account in cross-account logging.
Click the Create role button above the list of roles.
On the Select type of trusted entity page, select Another AWS account.

The Oracle CASB Cloud Service can assume this role to monitor the AWS account.

Caution:
You must keep this AWS page open and active until you can return from Oracle CASB Cloud Service with the External ID and Account ID that you will paste here.
Open a new browser tab and log in to your Oracle CASB Cloud Service tenant.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.
Click Add/Modify App.
On the Select an app type page, click Amazon Web Services, and then click Next.
On the Select an instance page:
1. Enter a name for this AWS instance.
  
  Names of any existing instances are listed below your input.
2. If users log in to AWS through an identity provider, select The users of this app instance log in using single sign-on through an identity provider and select the identity provider instance from the drop-down list.
  
  Note:
  
  The identity provider instance must already be defined. See Setting Up an Identity Provider Instance.
On the Select monitoring type page, select:
- Monitor only — if you want Oracle CASB Cloud Service to read data from AWS, but not write security control settings back to AWS. For a description of the security control settings that Oracle CASB Cloud Service automatically enforces when you select Monitor only, see Security Control Values for AWS (Monitor Only/Read Only).
- Push controls and monitor — if you want Oracle CASB Cloud Service to write security control settings back to AWS, in addition to reading AWS data. When you selectPush controls and monitor, you specify the security control settings that you want Oracle CASB Cloud Service to enforce in the next step.
  
  Note:
  Do not select Push controls and monitor if you selected only the ReadAccessOnly policy in Using an IAM Role: Enabling CloudTrail.
After you make your selection, click Next.
If you selected Monitor only, skip this step — you will go directly to the Enter credentials page.

Make your selections on the Select security controls page:
1. Select Standard, Stringent, or Custom.
  
  Each of these options provides a different set of security settings. For a description of all the options, see Security Control Values for AWS (Push Controls/Read-Write).
2. Examine the settings under Password Policies, Settings, and Access Controls, and make any changes you want to in those settings.
3. Click Next when you are done.
On the Enter credentials page, set Authentication type to IAM user role.

Note:
The read-only values for External ID and Account ID are automatically generated when you select IAM user role.

Caution:
A different External ID value generated each time that you select IAM user role. You must keep this Oracle CASB Cloud Service Page open and active until you can return and paste the User role ARN value into the User role ARN field.
Copy the External ID and Account ID to a temporary location from which you can copy and paste into the AWS console.
Switch back to the browser tab with your AWS account.
Paste the Account ID from the temporary location into the Account ID field in AWS.
Select Require external ID… and paste the External ID from the temporary location into the External ID field in AWS and click Next: Permissions.
On the Attach Policy page, select the policy that matches the Monitoring type you selected in the Oracle CASB Cloud Service registration process:
- If you selected Monitor only in Oracle CASB Cloud Service, select ReadOnlyAccess. (Scroll to the bottom of the list.)
- If you selected Push controls and monitor in Oracle CASB Cloud Service, you must select AdministratorAccess.
Click Next: Review.
On the Set role name and review page, enter a Role name, an optional Role description, and then click Create role.
Click the name of the role you just created.
On the Summary page, copy the Role ARN value.
Switch back to the Oracle CASB Cloud Service tab.
Paste the value from AWS into the User role ARN field.
If you want Oracle CASB Cloud Service to collect logs from an external account, slide the Collect logs from an external account switch to the right, then enter the Name of the Cross-Account role and Account Number.
Click Test Credentials.
If all configurations are correct, you see a “Credentials are valid” message.
Click Submit.

You see a notification that is going through its first data ingestion on your Oracle CASB Cloud Service tenant.
Click Done.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.

You see the AWS application tile displaying a gear icon. This indicates that the application is going through its first data ingestion.

Initial data typically begins to appear in 30 minutes to 2 hours, but can take longer in some cases. For status, check the Dashboard. If no data appears within 24 hours, contact Oracle Support.

You have successfully registered your AWS account with Oracle CASB Cloud Service, using an IAM user role to authenticate.

Next Steps

If you are setting up cross-account logging, you have completed setup of your target account. Continue with Using an IAM Role: Adding Source Dedicated Service Roles for Cross-Account Logging.
If you do not want to set up cross-account logging, you are done.

Using an IAM Role: Adding Source Dedicated Service Roles for Cross-Account Logging

For cross-account logging, add more AWS instances as source accounts and direct their logs to the S3 bucket created for the first account, which now becomes the target account.

The steps to add the first source account for cross-account logging are unique. The steps to add any number of additional source accounts for cross-account logging are all the same.

Using an IAM Role: Setting Up the First Source Dedicated Service Role

The steps to add the first source account for cross-account logging are unique. You perform these steps only once.

To watch a video that provides an overview of the steps in this task, see Creating and Registering a Source AWS Account using an IAM Role.

Cross-account logging is a configuration in Amazon Web Services that allows users to pipe CloudTrail log data from one account to another account’s S3 bucket.

The account that you set up in Using an IAM Role: Creating a Dedicated Service Role becomes the target account — all logs from the source accounts, the additional AWS accounts you create and register with Oracle CASB Cloud Service, are piped into the S3 bucket of this target account.

Prerequisites: Before proceeding, you must:

Complete all the tasks in Using an IAM Role: Creating a Dedicated Service Role.
Create the source account in AWS.
Get the Oracle CASB Cloud Service Account ID for the AWS source account for which you want logging to be consolidated into the S3 bucket in the hub account through cross-account logging.

Note:

To complete this procedure, you will need to open the AWS console in two different browsers. For example, Chrome and Firefox. You can’t access two different accounts at the same time in the AWS account using the same browser in two different windows or tabs.

Open a browser window and log in to the target AWS account.

This is the account which has the S3 bucket that all other AWS accounts will use for logging.

We will refer to this as the target account browser.
Open a window in a different browser and log into the source AWS account.

This is one of the other AWS accounts, which will use the S3 bucket from the target account for logging.

We will refer to this as the source account browser.

Note:
This must be a window in a different browser, not just a separate window in the same browser. For example, if you the target account in Chrome, you might open the source account in Firefox.
Switch to the target account browser.
Select Services, and under Storage, select S3.

The policy on the target account must be modified to allow the source accounts to write to it. If this is not done, the CloudTrail creation process in the source account will fail when it does not recognize the S3 bucket in the target account.
Click the bucket name to display four tabs across the top.
Click the Permissions tab, and then click the Bucket Policy button.

The Bucket policy editor displays the policy in JSON format that this S3 bucket is using.
Make a copy of this policy before you modify it, in case you need to restore it later.

Look closely at the Resource statement near the bottom.

This is how that Resource statement looks before any source accounts have been added:

            ...
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
            "Condition": {
                ...

In the Resource statement, add a left square bracket (“[“) after the colon, press Enter, and press Tab several times:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>
/LORIC/AWSLogs/<target_account_number>/*",
            "Condition": {
                ...

Press Enter at the end of the arn statement, then copy the entire arn statement and paste the copy directly below the original:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
            "Condition": {
                ...

At the end of the copied arn statement, delete the comma, press Enter, and then type a right square bracket (“]”) and a comma:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*"
            ],
            "Condition": {
                ...

In the copied arn statement, replace the <target_account_number> with the <source_account_number> for the AWS source account:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<source_account_number>/*"
                ],
            "Condition": {
                ...

Click Save.

If there are any syntax errors in your changes, you will see a message saying that the policy contains invalid JSON.

If this happens, try to find and correct the error, or click Cancel, restore the original policy that you saved, and start over with these instructions.
Select Services, and under Security, Identity & Compliance, select IAM.

You must now have the source account assume the IAM cross-account role that allows it to read the S3 bucket.
On the Welcome to Identity and Access Management page, select Roles from the list on the left.
Click the Create role button above the list of roles.
On the Select type of trusted entity page, select Another AWS account.

This option allows IAM users or roles that you own to assume this cross-account role.
In the Account ID field, enter the source account number and click Next: Permissions.
On the Attach Policy page, select the AmazonS3ReadOnly policy and click Next: Review.
On the Set role name and review page, in the Role name field, enter a name for the role, an optional Role Description, and then click Create role.
Click the role name to display the Summary page for the role.
Click the Trust relationships tab.

This tab displays the information on the relationship you have established between the target account and this source account.

Click the Edit trust relationship button.

On the Edit trust relationship page, you see the policy document for the trust relationship between the target and source accounts:

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": "arn:aws:iam::<source_account>:root" 
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

In the Principal statement, change root to the Amazon resource name (ARN) of the IAM user in the target account that will be used to monitor the source AWS account in Oracle CASB Cloud Service.

            ...
            "Principal": {
            "AWS": "arn:aws:iam::<source_account>:role/<IAM_role>" 
            }
            "Action": "sts:AssumeRole"
            ...

Click Save.

If there are any syntax errors in your changes, you will see a message saying that the policy contains invalid JSON.

If this happens, try to find and correct the error, or click Cancel, restore the original policy that you saved, and start over with these instructions.

What to Do Next

Continue with Using an IAM Role: Creating and Registering a Source Dedicated Service Role.

Using an IAM Role: Setting Up an Additional Source Dedicated Service Role

After you set up the first source account for cross-account logging, the steps to set up additional source accounts are the same. Repeat these steps for each additional source account.

To watch videos that provide an overview of the steps in this task, see:

Prerequisites:

Complete all the tasks in Using an IAM Role: Creating a Dedicated Service Role.
Complete all the steps in Using an IAM Role: Setting Up the First Source Dedicated Service Role.
Create the source account in AWS.
Get the Oracle CASB Cloud Service Account ID for the AWS source account for which you want logging to be consolidated into the S3 bucket in the hub account through cross-account logging.

Note:

Open a browser window and log in to the target AWS account.

This is the account which has the S3 bucket that all other AWS accounts will use for logging.

We will refer to this as the target account browser.
Open a window in a different browser and log into the source AWS account.

This is one of the other AWS accounts, which will use the S3 bucket from the target account for logging.

We will refer to this as the source account browser.

Note:
This must be a window in a different browser, not just a separate window in the same browser. For example, if you the target account in Chrome, you might open the source account in Firefox.
Switch to the target account browser.
Select Services, and under Storage, select S3.

The policy on the target account must be modified to allow the source accounts to write to it. If this is not done, the CloudTrail creation process in the source account will fail when it does not recognize the S3 bucket in the target account.
Click the bucket name to display four tabs across the top.
Click the Permissions tab, and then click the Bucket Policy button.

The Bucket policy editor displays the policy in JSON format that this S3 bucket is using.
Make a copy of this policy before you modify it, in case you need to restore it later.
Look closely at the Resource statement near the bottom.
This is how that Resource statement looks if one source account has been added:
```
            ...
            "Action": "s3:PutObject",
            "Resource":[
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<source1_account_number>/*"
            ],

            "Condition": {
                ...
```
For each additional source account that is added, you see another arn statement in the “Resource”: statement list.

To keep things simple, our example will show a policy with two arn statements. The steps are exactly the same for any higher number of arn statements.

Copy the entire first arn statement and paste the copy directly under the original:

            ...
            "Action": "s3:PutObject",
            "Resource":[
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<source1_account_number>/*"
            ],

            "Condition": {
                ...

In the copy of the arn statement, replace the <target_account_number> with the <source_account_number> that you are adding, in this example, <source_account2_number>:

            ...
            "Action": "s3:PutObject",
            "Resource":[
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<target_account_number>/*",
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<source2_account_number>/*",
                 "arn:aws:s3:::<target_bucket_name>/LORIC/AWSLogs/<source1_account_number>/*"
                 ],

            "Condition": {
                ...

Click Save.

If there are any syntax errors in your changes, you will see a message saying that the policy contains invalid JSON.

If this happens, try to find and correct the error, or click Cancel, restore the original policy that you saved, and start over with these instructions.
Select Services, and under Security, Identity & Compliance, select IAM.

You must now have the source account assume the IAM cross-account role that allows it to read the S3 bucket.
On the Welcome to Identity and Access Management page, select Roles from the list on the left.
Click the Create role button above the list of roles.
On the Select type of trusted entity page, select Another AWS account.

This option allows IAM users or roles that you own to assume this cross-account role.
In the Account ID field, enter the source account number and click Next Step.
On the Attach Policy page, select the AmazonS3ReadOnly policy and click Next Step.
On the Set role name and review page, in the Role name field, enter a name for the role, an optional Role Description, and then click Create Role.
Click the role name to display the Summary page for the role.
Click the Trust relationships tab.

This tab displays the information on the relationship you have established between the target account and this source account.
Click the Edit trust relationship button.

On the Edit trust relationship page, you see the policy document for the trust relationship between the target and source accounts.

Look closely at the arn statements in the Principal statement in this policy document.

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": "arn:aws:iam::<source1_account>:role/<IAM_role>" 
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

If the Principal statement has only one arn statement, as shown above:

After the "AWS":, enter a left square bracket (“]”), press Enter, and then press Tab several times:

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>" 
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

Enter a comma at the end of the arn statement line, then press Enter:

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                 
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

Copy the entire arn statement and paste it directly below the original, then enter a comma at the end of the original arn statement:

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                "arn:aws:iam::<source1_account>:role/<IAM_role>"
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

In the copied arn statement, replace the original source account number (<source1_account>) with the new source account you are adding (<source2_account>):

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                "arn:aws:iam::<source2_account>:role/<IAM_role>"
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

At the end of the copied arn statement, press Enter and enter a right square bracket (“]”):

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                "arn:aws:iam::<source2_account>:role/<IAM_role>"
                ]
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

If the Principal statement has more than one arn statement:

At the end of the first arn statement, press Enter, and then copy the entire first arn statement directly below itself:

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                "arn:aws:iam::<source2_account>:role/<IAM_role>"
                ]
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

In the copied arn statement, replace the first source account number (<source1_account>) with the account number of the new account you are adding (<source_new_account>):

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": [
                "arn:aws:iam::<source1_account>:role/<IAM_role>",
                "arn:aws:iam::<source_new_account>:role/<IAM_role>",
                "arn:aws:iam::<source2_account>:role/<IAM_role>"
                ]
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

Click Save.

If there are any syntax errors in your changes, you will see a message saying that the policy contains invalid JSON.

If this happens, try to find and correct the error, or click Cancel, restore the original policy that you saved, and start over with these instructions.

What to Do Next

Continue with Using an IAM Role: Creating and Registering a Source Dedicated Service Role.

Using an IAM Role: Creating and Registering a Source Dedicated Service Role

Create a role for the source account in AWS, begin registering the account in Oracle CASB Cloud Service to get the External ID, return to AWS to enter the External ID and set necessary permissions, and then complete the registration.

To watch a video that provides an overview of the steps in this task, see Creating and Registering a Source AWS Account using an IAM Role.

Log in to the AWS account that you will be registering in Oracle CASB Cloud Service.
In the AWS console, select Services, then under Security Identity and Compliance select IAM.
On the Welcome to Identity and Access Management page, select Roles in the left navigation panel.

Here you will create the monitoring role for this AWS source account.
Click the Create role button above the list of roles.
On the Select type of trusted entity page, select Another AWS account.

The Oracle CASB Cloud Service can assume this role to monitor the AWS account.

Caution:
You must keep this AWS page open and active until you can return form Oracle CASB Cloud Service with the External ID and Account ID that you will paste here.
Open a new browser tab and log in to your Oracle CASB Cloud Service tenant.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.
Click Add an App.
On the Select an app type page, click Amazon Web Services, and then click Next.
On the Select an instance page:
1. Enter a name for this AWS instance.
  
  Names of any existing instances are listed below your input.
2. If users log in to AWS through an identity provider, select The users of this app instance log in using single sign-on through an identity provider and select the identity provider instance from the drop-down list.
  
  Note:
  
  The identity provider instance must already be defined. See Setting Up an Identity Provider Instance.
On the Select monitoring type page, select:
- Monitor only — if you want Oracle CASB Cloud Service to read data from AWS, but not write security control settings back to AWS. For a description of the security control settings that Oracle CASB Cloud Service automatically enforces when you select Monitor only, see Security Control Values for AWS (Monitor Only/Read Only).
- Push controls and monitor — if you want Oracle CASB Cloud Service to write security control settings back to AWS, in addition to reading AWS data. When you selectPush controls and monitor, you specify the security control settings that you want Oracle CASB Cloud Service to enforce in the next step.
  
  Note:
  Do not select Push controls and monitor if you selected only the ReadAccessOnly policy in Using an IAM Role: Enabling CloudTrail.
After you make your selection, click Next.
If you selected Monitor only, skip this step — you will go directly to the Enter credentials page.

Make your selections on the Select security controls page:
1. Select Standard, Stringent, or Custom.
  
  Each of these options provides a different set of security settings. For a description of all the options, see Security Control Values for AWS (Push Controls/Read-Write).
2. Examine the settings under Password Policies, Settings, and Access Controls, and make any changes you want to in those settings.
3. Click Next when you are done.
On the Enter credentials page, set Authentication type to IAM user role.

Note:
The read-only values for External ID and Account ID are automatically generated when you select IAM user role.

Caution:
A different External ID value generated each time that you select IAM user role. You must keep this Oracle CASB Cloud Service Page open and active until you can return and paste the User role ARN value into the User role ARN field.
Copy the External ID and Account ID to a temporary location from which you can copy and paste into the AWS console.
Switch back to the browser tab with your AWS account.
Paste the Account ID from the temporary location into the Account ID field in AWS.
Select Require external ID… and paste the External ID from the temporary location into the External ID field in AWS and click Next: Permissions.
On the Attach Policy page, select the policy that matches the Monitoring type you selected in the Oracle CASB Cloud Service registration process:
- If you selected Monitor only in Oracle CASB Cloud Service, select ReadOnlyAccess. (Scroll to the bottom of the list.)
- If you selected Push controls and monitor in Oracle CASB Cloud Service, you must select AdministratorAcess.
Click Next: Review.
On the Set role name and review page, enter a Role name, an optional Role description, and then click Create role.
Click the name of the role you just created.
On the Summary page, copy the Role ARN value.
Switch back to the Oracle CASB Cloud Service tab.
Paste the value from AWS into the User role ARN field.
Slide the Collect logs from an external account switch to the right.
In the Name of Cross-Account role field, enter the name of your cross-account role.
In the Account number field, enter the account number of the target account.

This is the AWS account with the S3 bucket that is used for logging by all the AWS accounts.
Switch back to the AWS browser tab.

You need to create an inline policy to allow the AWS role to assume the cross-account role in the target account.

Caution:
You must keep this Oracle CASB Cloud Service page open and active until you can return and complete the registration process.
On the AWS Summary page, click the Permissions tab.
On the Permissions tab, click Inline Policies, and then click the click here link to create one.
On the Set Permissions page, expand Custom Policy, and then click the Select button to the right of Use the policy editor to customize your own set of permissions.

On the Review Policy page, enter a Policy Name, and then copy and paste the text below into the Policy Document window:

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
            "sts:AssumeRole"
        ],
        "Resource": "*"
      }
    ]
}

Click the Validate Policy button at the bottom.
Click Apply Policy.
Switch back to the Oracle CASB Cloud Service tab where you are registering this AWS instance.
Click Test Credentials.
If all configurations are correct, you see a “Credentials are valid” message.
Click Submit.

You see a notification that is going through its first data ingestion on your Oracle CASB Cloud Service tenant.
Click Done.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.

You see the AWS application tile displaying a gear icon. This indicates that the application is going through its first data ingestion.

Initial data typically begins to appear in 30 minutes to 2 hours, but can take longer in some cases. For status, check the Dashboard. If no data appears within 24 hours, contact Oracle Support.

You have successfully registered your AWS account with Oracle CASB Cloud Service, using an IAM user role to authenticate.

Next Steps

If you need to set up another AWS source account, continue with Using an IAM Role: Setting Up an Additional Source Dedicated Service Role.
If you do not need to set up another AWS source account, you are done.

Using an IAM User: Creating and Registering a Dedicated Service User

This IAM User is the only account that you configure for within-account logging. In cross-account logging, this IAM User is the first, or target, AWS account that you configure.

Using an IAM User: Enabling CloudTrail

In order for CASB Cloud Service to monitor your AWS account, you must first enable CloudTrail.

Enabling CloudTrail allows the IAM account to monitor the AWS services from the CloudTrail logs stored in S3.

To watch a video that provides an overview of the steps in this task, see Enabling CloudTrail and S3.

Log into your AWS console.
Select Services, and under Management Tools, click CloudTrail.

If CloudTrail is not enabled, then on the AWS CloudTrail screen you see a blue Get Started Now button.

If you do not see the blue Get Started Now button, CloudTrail is enabled — go to step 4.

If you do see the blue Get Started Now button, CloudTrail is not enabled — continue with the substeps below:

Click the blue Get Started Now button to begin the process of enabling CloudTrail.
On the Turn on CloudTrail page, enter a Trail name.

Note:
Ensure that you note the region in the top right corner of the page.

This name can be anything you like, as long as it is unique within your AWS account.
Leave the default setting of Apply trail to all regions set to Yes, and Read/Write events set to All.
Scroll to the Storage location section at the bottom of the page.

To create a new bucket (note that your S3 bucket will be created in the region in step 4b above):

Leave the default setting of Apply trail to all regions set to Yes, enter a name for the bucket in the S3 bucket field, and then click Advanced.
If you want to use a log file prefix to change the default location of the CloudTrail logs, enter the prefix in the Log file prefix field.

This will change the path to the S3 bucket policy to include the prefix.
If you want to encrypt CloudTrail, set Encrypt log files to Yes and select Yes to Create a new KMS key or No to use an existing key.

Note:
Your KMS (Key Management Service) key must be in the same AWS region as your S3 bucket (noted in step 4b above) where your encrypted CloudTrail logs are stored.
Click Create.

{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::965634374182:user/testLocalUser"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Enable CloudTrail Encrypt Permissions",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "kms:GenerateDataKey*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:<AWSaccountnumber>:trail/*"
        }
      }
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

Validate your CloudTrail settings:
1. On the Trails page, click the CloudTrail name.
2. On the Configuration page, verify that the CloudTrail you just created has the settings specified in the previous steps.
3. Ensure that the CloudTrail is enabled for all regions in Trail Settings, and is capturing all events in Management events.

Validate your S3 settings:

Select Services, and under Storage, select S3.
Click the bucket name to display four tabs across the top.

Click the Permissions tab, and then click the Bucket Policy button.

The Bucket policy editor displays the policy in JSON format that was automatically created for your S3 bucket.

Ensure that the policy contains GetBucketAcl and PutObject, shown in bold below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::<bucket_name>"
        },
        {
            "Sid": "AWSCloudTrailWrite<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<bucket_name>/LORIC/AWSLogs/<AWSaccountnumber>/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

To use an existing bucket:

Change the default setting of Create a new S3 bucket to No and enter a name for the bucket in the S3 bucket field and click Advanced.

If you want to encrypt CloudTrail, set Encrypt log files to Yes.

Select Yes to Create a new KMS key or No to use an existing key.

Note:
Your KMS (Key Management Service) key must be in the same AWS region as your S3 bucket where your encrypted CloudTrail logs are stored.

Verify that your KMS policy contains the following statements by going to Services, IAM, Encryption Keys and changing the region to where you are creating your S3 bucket (step 4b above):

{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::965634374182:user/testLocalUser"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Enable CloudTrail Encrypt Permissions",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "kms:GenerateDataKey*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:<AWSaccountnumber>:trail/*"
        }
      }
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSaccountnumber>:user/testLocalUser"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

If you want to use a log file prefix to change the default location of the CloudTrail logs, enter the prefix in the Log File Prefix field.

This will change the path in the S3 bucket policy to include the prefix.
To review the S3 bucket policy, select Services, and under Storage, select S3.

Click the bucket name, then click the Permissions tab, and click the Bucket Policy button.

Ensure that the policy contains GetBucketAcl and PutObject, shown in bold below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::<bucket_name>"
        },
        {
            "Sid": "AWSCloudTrailWrite<AWSaccountnumber>",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<bucket_name>/LORIC/AWSLogs/<AWSaccountnumber>/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

If CloudTrail is already enabled, follow the substeps below.

It is recommended that you enable CloudTrail for all regions.

Ensure that all events are being logged.
1. From the API activity history page, select Trails on the left.
2. On the Trails page, in the Name column, click the name of the CloudTrail.
3. Ensure that Apply trail to all regions is set to Yes.
  
  To change the setting, click the Edit icon to the right of Trail settings.
4. Ensure that Read/Write events is set to All.
  
  To change the setting, click the Edit icon to the right of Management events.
5. Ensure that S3 bucket name is what you want to use.
  
  To create a new bucket to use, click the Edit icon to the right of Storage location.
6. If you want to encrypt CloudTrail, set Encrypt log files to Yes and select Yes to Create a new KMS key or No to use an existing key.
  
  Note:
  Your KMS (Key Management Service) key must be in the same AWS region as your S3 bucket (noted in step 4b above) where your encrypted CloudTrail logs are stored.
Click Save at the bottom of the page.

What to Do Next

Continue with Using an IAM User: Creating a Dedicated Service User.

Using an IAM User: Creating a Dedicated Service User

Create the IAM user for Oracle CASB Cloud Service to monitor a standalone or target AWS account.

To watch a video that provides an overview of the steps in this task, see Creating a Dedicated Service Account for monitoring AWS (Target).

The IAM user account you create is called a dedicated service account because it should be reserved exclusively for use by Oracle CASB Cloud Service. No human, or other automated process should ever log into this account.

Prerequisites:

You have successfully completed the steps in Using an IAM User: Enabling CloudTrail.
If users log in to AWS through an identity provider, you have already created an identity provider instance in Oracle CASB Cloud Service. See Setting Up an Identity Provider Instance.

Note:
You can register your AWS instance without an IDP configured and add the IDP at a future time. See Updating the IDP Instance for an AWS Instance.

Log in to the AWS account that you will be registering in Oracle CASB Cloud Service.
In the AWS console, select Services, then under Security Identity and Compliance select IAM.
Select Users from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.
Click the Add user button at the top.
On the Add user page, in the User name field, enter a name for the user
Under Access type, select Programmatic access, and then click Next
On the Set permissions… page, click Attach existing policies directly.
Select the policy based on how you plan to register this AWS account with Oracle CASB Cloud Service:
- Monitor only (read only) – select the ReadOnlyAccess policy. (Scroll to the bottom of the list.)
- Push controls and monitor (read/write) – select the AdministratorAccess policy.
Click Next.
On the Review page, verify:
- User name of the IAM user.
- AWS access type is set to Programmatic access – with an access key.
- Under Permissions summary, in the Name column, the correct policy that you selected appears – either ReadOnlyAccess or AdministratorAccess.
Click Create user.
On the Success page, click the Download .csv button.

This is the only time you will be able to do this. Best practice is to rotate these keys every 90 days by regenerating them and update the keys in Oracle CASB Cloud Service. If you lose these keys, you will have to do that in order to have Oracle CASB Cloud Service continue monitoring this AWS account.
After keys are downloaded, click Close.

The user you just created should now appear in the AWS list of users.

What to Do Next

Continue with Using an IAM User: Registering the Dedicated Service User.

Using an IAM User: Registering the Dedicated Service User

To watch a video that provides an overview of the steps in this task, see Registering an AWS Account using a Dedicated Service Account (Target).

Prerequisites:

You have successfully completed the steps in Using an IAM User: Creating a Dedicated Service User.

Open a new browser tab and log in to your Oracle CASB Cloud Service.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.
Click Add/Modify App to display the Application Management page.

Note:
If this is the first application that you are registering, the Application Management page is displayed automatically.
On the Select an app type page, click Amazon Web Services and then click Next.
On the Select an instance page:
1. Enter a name for this AWS instance.
  
  Names of any existing instances are listed below your input.
2. If users log in to AWS through an identity provider, select The users of this app instance log in using single sign-on through an identity provider and select the identity provider instance from the drop-down list.
  
  Note:
  
  The identity provider instance must already be defined. See Setting Up an Identity Provider Instance.
3. Click Next.
On the Select monitoring type page, select:
- Monitor only (read only) — if you want Oracle CASB Cloud Service to read data from AWS, but not write security control settings back to AWS. For a description of the security control settings that Oracle CASB Cloud Service automatically enforces when you select Monitor only, see Security Control Values for AWS (Monitor Only/Read Only).
- Push controls and monitor (read–write) — if you want Oracle CASB Cloud Service to write security control settings back to AWS, in addition to reading AWS data. When you selectPush controls and monitor, you specify the security control settings that you want Oracle CASB Cloud Service to enforce in the next step.
  
  Note:
  Do not select Push controls and monitor if you selected only the ReadAccessOnly policy in Using an IAM Role: Enabling CloudTrail.
After you make your selection, click Next.
If you selected Monitor only, skip this step — you will go directly to the Enter credentials page.

Make your selections on the Select security controls page:
1. Select Standard, Stringent, or Custom.
  
  Each of these options provides a different set of security settings. For a description of all the options, see Security Control Values for AWS (Push Controls/Read-Write).
2. Examine the settings under Password Policies, Settings, and Access Controls, and make any changes you want to in those settings.
3. Click Next when you are done.
On the Enter credentials page, in the Access key and Secret key fields, enter the access key and secret key for the Oracle CASB Cloud Service user in the AWS account being registered.

You can get these keys from the CSV file that you downloaded when you created the IAM user.
If you want Oracle CASB Cloud Service to collect logs from an external source, then slide the Collect logs from an external account switch to the right. Then, enter the Name of the Cross-Account role and the Account Number.
Click Test Credentials.
If all configurations are correct, you see a “Credentials are Valid” message.
Click Submit.

You see a notification that is going through its first data ingestion on your Oracle CASB Cloud Service tenant.
Click Done.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.

You see the AWS application tile displaying a gear icon. This indicates that the application is going through its first data ingestion.

Initial data typically begins to appear in 30 minutes to 2 hours, but can take longer in some cases. For status, check the Dashboard. If no data appears within 24 hours, contact Oracle Support.

You have successfully registered your AWS account with Oracle CASB Cloud Service, using an IAM user role to authenticate.

Next Steps

If you are setting up cross-account logging, you have completed setup of your target account. Continue with Using an IAM User: Adding Source Dedicated Service Users for Cross-Account Logging
If you do not want to set up cross-account logging, you are done.

Using an IAM User: Adding Source Dedicated Service Users for Cross-Account Logging

For cross-account logging, add more AWS accounts as source accounts and direct their logs to the S3 bucket created for the target account.

Using an IAM User: Setting Up the First Source Dedicated Service User

Create the IAM user for Oracle CASB Cloud Service to monitor of source AWS accounts.

The account you create is called a dedicated service account because it should be reserved exclusively for use by Oracle CASB Cloud Service. No human, or other automated process should ever log into this account.

The steps to add the first source account for cross-account logging are unique. You perform these steps only once.

Cross Account logging is a configuration in AWS that allows users to log CloudTrail data from one AWS account to another AWS account’s S3 bucket.

The account that you set up in Using an IAM User: Creating a Dedicated Service User becomes the target account — all logs from the source accounts, the additional AWS accounts you create and register with Oracle CASB Cloud Service, are sent to the S3 bucket of this target account.

Prerequisites:

Complete all the tasks in Using an IAM User: Creating and Registering a Dedicated Service User.
Get the Oracle CASB Cloud Service Account ID for the AWS source account for which you want logging to be consolidated into the S3 bucket in the target account through cross-account logging.

Note:

To complete this procedure, you may want to open the AWS console in two different browsers. For example, Chrome and Firefox. You can’t access two different AWS accounts at the same time in the AWS account using the same browser.

Using an IAM User: Setting Up Cross-Account Logging

Set up cross-account logging, often referred to as x-acct logging.

To watch a video that provides an overview of the steps in this task, see DSA: Turn on Cross-Account Logging in AWS.

Open a browser window and log in to the target AWS account.

This is the account which has the S3 bucket that all other AWS accounts will use for logging.

We will refer to this browser window as the “target account browser.”
Open a window in a different browser and log into the source AWS account.

This is an AWS account that which will use the S3 bucket from the target account for logging.

We will refer to this browser window as the “source account browser.”

Note:
This must be a window in a different browser, not just a separate window in the same browser. For example, if you open the target account in Chrome, you might open the source account in Firefox.
Switch to the target account browser.
Select Services, and under Storage, select S3.

The policy on the target account must be modified to allow the source accounts to write to it. If this is not done, the CloudTrail creation process in the source account will fail when it does not recognize the S3 bucket in the target account.
Click the bucket name to display four tabs across the top.
Click the Permissions tab, and then click the Bucket Policy button.

The Bucket policy editor displays the policy in JSON format that this S3 bucket is using.
Make a copy of this policy before you modify it, in case you need to restore it later.

Look closely at the Resource statement near the bottom.

This is how that Resource statement looks before any source accounts have been added:

            ...
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
            "Condition": {
                ...

In the Resource statement, add a left square bracket ([) after the colon, press Enter, and press Tab several times:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
            "Condition": {
                ...

Press Enter at the end of the arn statement, then copy the entire arn statement and paste the copy directly below the original:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
            "Condition": {
                ...

At the end of the copied arn statement, delete the comma, press Enter, and then type a right square bracket (]”) and a comma:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
            ],
            "Condition": {
                ...

In the copied arn statement, replace the <target_account_number> with the <source_account_number> for the AWS source account:

            ...
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<target_account_number>/*",
                "arn:aws:s3:::<target_bucket_name>/[<optional_prefix>/]AWSLogs/<source_account_number>/*",
            ],
            "Condition": {
                ...

Click Save.

If there are any syntax errors in your changes, you will see a message saying that the policy contains invalid JSON.

If this happens, try to find and correct the error, or click Cancel, restore the original policy that you saved, and start over with these instructions.

What to Do Next

Continue with Using an IAM User: Creating the First Source Dedicated Service User.

Using an IAM User: Creating the First Source Dedicated Service User

Set up the IAM User dedicated service account for cross-account logging, often referred to as x-acct logging.

To watch a video that provides an overview of the steps in this task, see Registering an AWS Account using a Dedicated Service Account (Source).

Select Services, and under Security, Identity & Compliance, select IAM.

You must now have the source account assume the IAM cross-account role that allows it to read the S3 bucket.
On the Welcome to Identity and Access Management page, select Roles from the list on the left.
Click the Create new role button at the top left.
On the Select role type page, drop down the Role for cross-account access list and click the Select button for Provide access between AWS accounts you own.

This option allows IAM users or roles that you own to assume this cross-account role.
In the Account ID field, enter the source account number and click Next Step.
On the Attach Policy page, select the AmazonS3ReadOnly policy and click Next Step.
On the Set role name and review page, in the Role name field, enter a name for the role, an optional Role Description, and then click Create Role.
Click the role name to display the Summary page for the role.
Click the Trust relationships tab.

This tab displays the information on the relationship you have established between the target account and this source account.
Click the Edit trust relationship button.

On the Edit trust relationship page, you see the policy document for the trust relationship between the target and source accounts:

{
"Version": "2012-10-17",
"Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
            "AWS": "arn:aws:iam::<source_account>:root"
            }
            "Action": "sts:AssumeRole"
        }
    ]
}

In the Principal statement, change root to the Amazon resource name (ARN) of the IAM user in the target account that will be used to monitor the source AWS account in Oracle CASB Cloud Service:

            ...
            "Principal": {
            "AWS": "arn:aws:iam::<source_account>:<IAM_role_ARN>"
            }
            "Action": "sts:AssumeRole"
            ...

Click Save.

If there are any syntax errors in your changes, you will see a message saying that the policy contains invalid JSON.

If this happens, try to find and correct the error, or click Cancel, restore the original policy that you saved, and start over with these instructions.

What to Do Next

Continue with Using an IAM User: Registering an Additional Source Dedicated Service User.

Using an IAM User: Setting Up an Additional Source Dedicated Service User

Set up another source account to be used in cross-account logging.

To watch a video that provides an overview of the steps in this task, see Registering an AWS Account using a Dedicated Service Account (Source).

Prerequisites: Create and register the first source account, by completing the steps in:

Set Up an Additional Source Dedicated Service User

Log in to your source AWS account.
Select Services, and under Security, Identity & Compliance, select IAM.
On the Welcome to Identity and Access Management page, select Users on the left side, and then click the Add user button at the top.
On the Add user page, enter a User name.
Under Access type, select Programmatic access, and click Next.
On the Set permissions… page, click Attach existing policies directly.
Select the policy based on how you plan to register this AWS account with Oracle CASB Cloud Service:
- Monitor only (read only) — select the ReadOnlyAccess policy. (Scroll to the bottom of the list.)
- Push controls and monitor (read-write) — select the AdministratorAccess policy.
Click Next.
On the Review page, verify:
- User name of the IAM user.
- AWS access type is set to Programmatic access – with an access key.
- Under Permissions summary, in the Name column, the correct policy that you selected appears – either ReadOnlyAccess or AdministratorAccess.
Click Create user.
On the Success page, click the Download .csv button.

This is the only time you will be able to do this. Best practice is to rotate these keys every 90 days by regenerating them and update the keys in Oracle CASB Cloud Service. If you lose these keys, you will have to do that in order to have Oracle CASB Cloud Service continue monitoring this AWS account.
After keys are downloaded, click Close.

The user you just created should now appear in the AWS list of users.
If you selected the ReadOnlyAccess policy in step 7 above:
1. In the User name column, click the user you just created.
2. On the Summary page, on the Permissions tab, click the Add inline policy link in the lower right corner.
3. On the Set Permissions page, select Custom Policy., and then click Select to the right of Use the policy editor to customize your own set of permissions.
4. On the Review Policy page, enter a Policy Name, and then copy and paste the text below into the Policy Document window:
```
{
   "Version": "2012-10-17",
   "Statement": [
     {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole"
        ],
        "Resource": "*"
      }
   ]
}
```
5. Click the Validate Policy button at the bottom.
6. Click Apply Policy.
  
  The policy now appears on the Summary page, Permissions tab, in the list of policies that are Attached directly.

What to Do Next

Continue with Using an IAM User: Registering an Additional Source Dedicated Service User.

Using an IAM User: Registering an Additional Source Dedicated Service User

To watch a video that provides an overview of the steps in this task, see Registering an AWS Account using a Dedicated Service Account (Source).

Prerequisites: You should have just completed the steps in either Using an IAM User: Setting Up the First Source Dedicated Service User, or Using an IAM User: Setting Up an Additional Source Dedicated Service User.

Open a new browser tab and log in to your Oracle CASB Cloud Service tenant.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.
Click Add/Modify App to display the Application Management page.

Note:
If this is the first application that you are registering, the Application Management page is displayed automatically.
On the Select an app type page, click Amazon Web Services and then click Next.
On the Select an instance page:
1. Enter a name for this AWS instance.
  
  Names of any existing instances are listed below your input.
2. If users log in to AWS through an identity provider, select The users of this app instance log in using single sign-on through an identity provider and select the identity provider instance from the drop-down list.
  
  Note:
  
  The identity provider instance must already be defined. See Setting Up an Identity Provider Instance.
3. Click Next.
On the Select monitoring type page, select:
- Monitor only (read only) — if you want Oracle CASB Cloud Service to read data from AWS, but not write security control settings back to AWS. For a description of the security control settings that Oracle CASB Cloud Service automatically enforces when you select Monitor only, see Security Control Values for AWS (Monitor Only/Read Only).
- Push controls and monitor (read–write) — if you want Oracle CASB Cloud Service to write security control settings back to AWS, in addition to reading AWS data. When you selectPush controls and monitor, you specify the security control settings that you want Oracle CASB Cloud Service to enforce in the next step.
Note:
Do not select Push controls and monitor if you selected only the ReadAccessOnly policy in Using an IAM User: Enabling CloudTrail .

After you make your selection, click Next.
If you selected Monitor only, skip this step — you will go directly to the Enter credentials page.

Make your selections on the Select security controls page:
1. Select Standard, Stringent, or Custom.
  
  Each of these options provides a different set of security settings. For a description of all the options, see Security Control Values for AWS (Push Controls/Read-Write).
2. Examine the settings under Password Policies, Settings, and Access Controls, and make any changes you want to in those settings.
3. Click Next when you are done.
On the Enter credentials page, in the Access key and Secret key fields, enter the access key and secret key for the Oracle CASB Cloud Service user in the AWS account being registered.

You can get these keys from the CSV file that you downloaded when you created the IAM user.
Slide the Collect logs from an external account selector to the right.
In the Name of Cross-Account role field, enter the name of the cross-account role that you created in the target account.
In the Account number field, enter the account number of the target account.
Click Test Credentials.

If all configurations are correct, you see a “Credentials are Valid” message.
Click Submit.

You see a notification that this AWS instance is going through its first data ingestion on your Oracle CASB Cloud Service tenant.
Click Done.
Select Applications from the Navigation menu. If the Navigation Menu is not displayed, click the Navigation Menu icon to display it.

You see the new AWS application tile displaying a gear icon. This indicates that the application is going through its first data ingestion.

Initial data typically begins to appear in 30 minutes to 2 hours, but can take longer in some cases. For status, check the Dashboard. If no data appears within 24 hours, contact Oracle Support.

You have successfully registered your AWS account with Oracle CASB Cloud Service, using an IAM user role to authenticate.

Next Steps

If you need to set up another AWS source account, continue with Using an IAM User: Setting Up an Additional Source Dedicated Service User.
If you do not need to set up another AWS source account, you are done.

Security Control Values for AWS (Monitor Only/Read Only)

Review the AWS security controls that Oracle CASB Cloud Service monitors in monitor-only mode, together with the values for their stringent settings.

After registering the AWS instance in monitor-only mode, Oracle CASB Cloud Service displays security control alerts if the security control values in AWS deviate from the Oracle CASB Cloud Service baseline values for these controls.

These settings appear in the following locations in AWS:

Password policies: The IAM, Account settings section of the AWS administration console.
SSH and user keys: Oracle CASB Cloud Service checks the age of all user and EC2 SSH keys.
Multifactor authentication: The IAM, Users section of the AWS administration console.
Encryption and secure ports: Oracle CASB Cloud Service checks the encryption and port settings in network access control lists (ACLs) for all EC2 instances in an account.

The following describes Oracle CASB Cloud Service's default settings. In general, these settings are more stringent than the default settings within AWS.

Security Control Type	Security Control Name	Stringent Settings: Alert When This Value Is Changed	Description
Password policy	Minimum password length	10 characters	The longer a password is, the harder it is to crack.
Password policy	Require at least one uppercase letter	On	The more complex a password is, the harder it is to crack.
Password policy	Require at least one lowercase letter	On	The more complex a password is, the harder it is to crack.
Password policy	Require at least one number	On	The more complex a password is, the harder it is to crack.
Password policy	Require at least one non-alphanumeric character	On	The more complex a password is, the harder it is to crack.
Password policy	Allow users to change their own password	On	Users are more likely to update passwords when this activity is under their control.
Password policy	Password expiration period (in days)	30	The more frequently a password is updated, the harder it is to crack.
Password policy	Number of passwords to remember	10	Reused passwords open a window for an attacker to make use of an old password.
Password policy	Password expiration requires administrator reset	On	When passwords expire, this indicates an unused account. It’s a best practice to not let accounts sit idle.
Setting	Number of days for an SSH key to be considered old	30	SSH keys authenticate AWS EC2 instances. The more frequently these keys are updated, the harder they are to crack.
Setting	Number of days for an IAM key to be considered old	90	IAM keys authenticate AWS administrative users. The more frequently these keys are updated, the harder they are to crack.
Access controls	Require the root user to use multi-factor authentication	On	Multifactor authentication requires a user to enter more than one credential when logging in (for example, a password and a one-time code). This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Require the admin users to use multi-factor authentication	Off	The setting above applies only to the root user. This setting applies to all other admin users.
Access controls	Make sure that all S3 server buckets are encrypted	On	It’s a best practice to keep data at rest in encrypted form. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check public access acl enabled s3 buckets	On	This setting enables monitoring of S3 buckets with public access enabled through an ACL.
Access controls	Check cloud trails those stores logs less than two weeks	On	This setting requires at least two weeks of data to be retained in CloudTrail logs. There are two ways to retain data: through CloudTrail's configured S3 bucket, and through CloudTrail's configured CloudWatch logs.
Access controls	Require multi-factor authentication when deleting an S3 bucket	On	Deleting an S3 bucket means removing a data store. This is a sensitive operation and should require the extra security that multifactor authentication provides. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	VPCs whose flow logs are not stored as per standard	On	This setting causes Oracle CASB Cloud Service to flag VPCs whose flow logs are not stored according to standard guidelines.
Access controls	Check ec2 instances termination protection	On	This setting enables monitoring of termination protection for EC2 instances.
Access controls	Require security group checking for unsecured ports	Off	AWS manages critical organizational infrastructure. Security group checking provides an additional layer of security in the event that a port was left open to the internet. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Require network ACLs to use secure open ports	Off	AWS services listen for traffic on ports. These ports should require secure (encrypted) communication so that sensitive information isn’t transmitted in the clear. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled. This setting can only be enabled when the security control baseline for the application instance is set to Custom.
Access controls	Do not let network ACLs have Allow All set as the default	On	Allow All means that the access control list (ACL) provides access to anyone on the internet. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check use of Route 53 hosted zones	On	Amazon's Route 53 service maps domain name system (DNS) queries to numeric IP addresses. It routes end users to Internet applications by translating domain names (for example, `www.example.com`) into numeric IP addresses (for example, 192.0.2.1) that computers use to connect to each other. Route 53 works with external domain names. It also works with Amazon Virtual Private Clouds (VPCs), which allows custom domain names for your internal AWS resources without exposing them to the public internet. Consider using Route 53 service as a cost-effective solution for DNS routing that also can be extended to your VPCs. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check use of Route 53 health checks	On	Amazon Route 53 maps domain name system (DNS) queries to numeric IP addresses. Route 53 health checks ensure that your web resources that reside at these IP addresses are functional before directing traffic to them. Oracle CASB Cloud Service doesn’t monitor for Route 53 health checks in private hosted zones. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check EBS volume encryption status	On	Amazon Elastic Block Store (EBS) volumes provide incremental backup for Amazon Elastic Compute Cloud (EC2) instances. Encryption of these volumes prevents unauthorized access to the data on them. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check RDS encryption status	On	Amazon Relational Database Service (RDS) is a relational database in the cloud. Ensure that RDS encryption is enabled to prevent unauthorized access to the information stored in the database. Amazon RDS handles authentication, access, and decryption of data transparently with minimal impact on performance. Amazon RDS encryption also helps to fulfill compliance requirements for data-at-rest encryption. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.

Security Control Values for AWS (Push Controls/Read-Write)

Review the AWS security controls that Oracle CASB Cloud Service monitors for push-controls mode, together with the values for their stringent settings.

After you register the AWS instance in push controls mode, Oracle CASB Cloud Service pushes your selected security control values to the related AWS account. Later, it displays security control alerts if anyone changes these values.

These settings appear in the following locations in AWS:

Password policies: The IAM, Account settings section of the AWS administration console.
SSH and user keys: Oracle CASB Cloud Service checks the age of all user and EC2 SSH keys.
Multifactor authentication: The IAM, Users section of the AWS administration console.
Encryption and secure ports: Oracle CASB Cloud Service checks the encryption and port settings in network access control lists (ACLs) for all EC2 instances in an account.

After registration, if anyone lowers these values in the application, Oracle CASB Cloud Service generates a risk event in Risk Events.

The following describes Oracle CASB Cloud Service's default settings. In general these are more stringent than the default settings within AWS. You also can define custom settings for these controls.

Security Control Type	Security Control Name	Stringent Settings: Alert when this Value Is Changed	Description
Password policy	Minimum password length	10 characters	The longer a password is, the harder it is to crack.
Password policy	Require at least one uppercase letter	On	The more complex a password is, the harder it is to crack.
Password policy	Require at least one lowercase letter	On	The more complex a password is, the harder it is to crack.
Password policy	Require at least one number	On	The more complex a password is, the harder it is to crack.
Password policy	Require at least one non-alphanumeric character	On	The more complex a password is, the harder it is to crack.
Password policy	Allow users to change their own password	On	Users are more likely to update passwords when this activity is under their control.
Password policy	Password expiration period (in days)	30	The more frequently a password is updated, the harder it is to crack.
Password policy	Number of passwords to remember	10	Reused passwords open a window for an attacker to make use of an old password.
Password policy	Password expiration requires administrator reset	On	When passwords expire, this indicates an unused account. It’s a best practice to not let accounts sit idle.
Setting	Number of days for an SSH key to be considered old	30	SSH keys authenticate AWS EC2 instances. The more frequently these keys are updated, the harder they are to crack.
Setting	Number of days for an IAM key to be considered old	90	IAM keys authenticate AWS administrative users. The more frequently these keys are updated, the harder they are to crack.
Access controls	Require the root user to use multi-factor authentication	On	Multifactor authentication requires a user to more than one credential when logging in (for example, a password and a one-time code). This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Require the admin users to use multi-factor authentication	Off	The setting above applies only to the root user. This setting applies to all other admin users. When the security control baseline for the application instance is set to Custom, you can specify IAM groups to which this setting applies. Expand IAM group name(s) allowed and enter one or more admin group names in the IAM admin groups which need to be considered field.
Access controls	Make sure all S3 server buckets are encrypted	On	It’s a best practice to keep data at rest in encrypted form.
Access controls	Check public access acl enabled s3 buckets	On	This setting enables monitoring of S3 buckets with public access enabled through an ACL.
Access controls	Check cloud trails those stores logs less than two weeks	On	This setting requires at least two weeks of data to be retained in CloudTrail logs. There are two ways to retain data: through CloudTrail's configured S3 bucket, and through CloudTrail's configured CloudWatch logs.
Access controls	Require multi-factor authentication when deleting an S3 bucket	On	Deleting an S3 bucket means removing a data store. This is a sensitive operation and should require the extra security that multifactor authentication provides. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	VPCs whose flow logs are not stored as per standard	On	This setting causes Oracle CASB Cloud Service to flag VPCs whose flow logs are not stored according to standard guidelines.
Access controls	Check EC2 instance termination protection	On	This setting enables monitoring of termination protection for EC2 instances.
Access controls	Require security group checking for unsecured ports	On	AWS manages critical organizational infrastructure. Security group checking provides an additional layer of security in the event that a port was left open to the internet. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Require network ACLs to use secure open ports	On	AWS services listen for traffic on ports. These ports should require secure (encrypted) communication so that sensitive information is not transmitted in the clear. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled. This setting can only be enabled when the security control baseline for the application instance is set to Custom.
Access controls	Do not let network ACLs have Allow All set as the default	On	Allow All means that the access control list (ACL) provides access to anyone on the internet. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check use of Route 53 hosted zones	On	Amazon's Route 53 service maps domain name system (DNS) queries to numeric IP addresses. It routes end users to internet applications by translating domain names (for example, `www.example.com`) into numeric IP addresses (for example, 192.0.2.1) that computers use to connect to each other. Route 53 works with external domain names. It also works with Amazon Virtual Private Clouds (VPCs), which allows custom domain names for your internal AWS resources without exposing them to the public internet. Consider using Route 53 service as a cost-effective solution for DNS routing that also can be extended to your VPCs. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check use of Route 53 health checks	On	Amazon Route 53 maps domain name system (DNS) queries to numeric IP addresses. Route 53 health checks ensure that your web resources that reside at these IP addresses are functional before directing traffic to them. Oracle CASB Cloud Service doesn’t monitor for Route 53 health checks in private hosted zones. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check EBS volume encryption status	On	Alert if Elastic Block Store (EBS) is not encrypted. Exceptions for Instances: Enter volume ID of AWS instance. Separate multiple volume IDs with commas. Exceptions for Tags: Enter `<tag-key-name>:[<value>]`. Separate multiple values with commas. Separate multiple tag key names and value lists with commas: `<tag-key-name1>:[<key1-value1>, <key1-value2>, ...], <tag-key-name1>:[<key1-value1>, <key1-value2>, ...]` Background Information: Amazon Elastic Block Store (EBS) volumes provide incremental backup for Amazon Elastic Compute Cloud (EC2) instances. Encryption of these volumes prevents unauthorized access to the data on them. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.
Access controls	Check RDS encryption status	On	Alert if Relational Database Service (RDS) is not encrypted. Exceptions for Instances: Enter volume ID of AWS instance. Separate multiple volume IDs with commas. Exceptions for Tags: Enter `<tag-key-name>:[<value>]`. Separate multiple values with commas. Separate multiple tag key names and value lists with commas: `<tag-key-name1>:[<key1-value1>, <key1-value2>, ...], <tag-key-name1>:[<key1-value1>, <key1-value2>, ...]` Background Information: Amazon Relational Database Service (RDS) is a relational database in the cloud. Ensure that RDS encryption is enabled to prevent unauthorized access to the information stored in the database. Amazon RDS handles authentication, access, and decryption of data transparently with minimal impact on performance. Amazon RDS encryption also helps to fulfill compliance requirements for data-at-rest encryption. This setting and the other access controls on this page aren’t available as a security setting in the AWS administration console. However, when enabled, Oracle CASB Cloud Service monitors this resource and generates an alert when the feature isn’t enabled.

AWS Registration Errors

Learn how to troubleshoot the errors you may receive when you add or register an AWS instance.

Validation Failed: Credentials or Permissions Issues

Troubleshoot errors about invalid keys, inadequate permissions, or a cross-account logging problem.

Message text: Validation failed for one of these reasons:

Invalid access key or secret key.
This user needs additional permissions to access the AWS logs.
If you set up cross-account logging, ensure that this user has a cross-account role in the target account.

Description: To successfully register this application instance, ensure that all of the following are done:

In each AWS account that you want Oracle CASB Cloud Service to monitor, you need to create a dedicated identity and access management (IAM) user. You supply this user's access key and secret key when you register the account with Oracle CASB Cloud Service. If you received this message, this user's keys may have expired, or you may have supplied incorrect keys for this user.

For more information about creating the Oracle CASB Cloud Service user and the user's access keys, see Using an IAM User: Creating a Dedicated Service User if you are using IAM users to monitor your AWS instances, or Using an IAM Role: Creating and Registering a Dedicated Service Role if you are using IAM users to monitor your AWS instances.
User must have permissions to access the logs from a single account. Ensure that this user has the correct privileges for accessing logs in this single AWS account. See Using an IAM User: Creating a Dedicated Service User if you are using IAM users to monitor your AWS instances, or Using an IAM Role: Creating and Registering a Dedicated Service Role if you are using IAM users to monitor your AWS instances.
User must have permissions to access cross-account logs. Make sure that this user has the correct privileges for cross-account logging. See Using an IAM User: Adding Source Dedicated Service Users for Cross-Account Logging if you are using IAM users to monitor your AWS instances, or Using an IAM Role: Adding Source Dedicated Service Roles for Cross-Account Logging if you are using IAM users to monitor your AWS instances.

Validation Failed: Permissions Issues

Troubleshoot errors about user needing additional AWS permissions.

Message text: This user needs additional permissions to access the AWS logs.

Description: Ensure that this user has the correct privileges according to the user’s role. See the topic referenced below for the way Oracle CASB Cloud Service is monitoring your AWS instances, and the context for the account you are trying to register (standalone or first cross-account instance vs. additional cross-account instances).

AWS Monitored by	Standalone AWS Instance or First Instance in Cross-Account Logging	Additional AWS Instances in Cross-Account Logging
User	Using an IAM User: Creating a Dedicated Service User	Using an IAM User: Adding Source Dedicated Service Users for Cross-Account Logging
Role	Using an IAM Role: Creating and Registering a Dedicated Service Role	Using an IAM Role: Adding Source Dedicated Service Roles for Cross-Account Logging

Validation Failed: Logging Configuration Issues

Troubleshoot errors about CloudTrail or S3 bucket.

Message text: Validation failed for one of these reasons:

CloudTrail is off.
You set up cross-account logging but not every region is sending its logs to the same target S3 bucket.

Description: Ensure that CloudTrail is turned on. See Using an IAM User: Enabling CloudTrail if you are using IAM users to monitor your AWS instances, or Using an IAM Role: Enabling CloudTrail if you are using IAM roles. If you are doing cross-account logging, ensure every that region's logs are going to the same bucket.

Validation Failed: Other Issues

Troubleshoot errors that refer you to the AWS documentation.

This an error that appears when a more precise diagnosis isn’t possible. You will probably need help to troubleshoot the problem.

Message text: AWS error {0}. Refer to the AWS documentation for more information or contact Oracle CASB Cloud Service support for help.

Description: Some registration errors are generated directly from AWS. In this case, you can either consult the AWS documentation to diagnose the error, or contact Oracle CASB Cloud Service support to have a support representative help investigate the issue.

Warning: Enable CloudTrail

Your registration completed successfully, but CloudTrail is not enabled for all S3 buckets..

Message text: Warning: Credentials are valid for this user and you can complete app registration. However, you need to enable CloudTrail for one or more S3 buckets in this account.

Description: Oracle CASB Cloud Service ingests AWS CloudTrail log data and uses the information in the logs to analyze different types of risk. To provide Oracle CASB Cloud Service with this data, you must ensure that CloudTrail is enabled for each S3 bucket in the monitored AWS account.

See Using an IAM User: Enabling CloudTrail if Oracle CASB Cloud Service is using IAM users to monitor your AWS instances, or Using an IAM Role: Enabling CloudTrail if IAM roles are used..