Edit

Share via

Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log data

  • Article

Use the Amazon Web Services (AWS) connectors to pull AWS service logs into Microsoft Sentinel. These connectors work by granting Microsoft Sentinel access to your AWS resource logs. Setting up the connector establishes a trust relationship between Amazon Web Services and Microsoft Sentinel. This is accomplished on AWS by creating a role that gives permission to Microsoft Sentinel to access your AWS logs.

This connector is available in two versions: the legacy connector for CloudTrail management and data logs, and the new version that can ingest logs from the following AWS services by pulling them from an S3 bucket (links are to AWS documentation):

This tab explains how to configure the AWS S3 connector. The process of setting it up has two parts: the AWS side and the Microsoft Sentinel side. Each side's process produces information used by the other side. This two-way authentication creates secure communication.

Prerequisites

  • Make sure that the logs from your selected AWS service use the format accepted by Microsoft Sentinel:

    • Amazon VPC: .csv file in GZIP format with headers; delimiter: space.
    • Amazon GuardDuty: json-line and GZIP formats.
    • AWS CloudTrail: .json file in a GZIP format.
    • CloudWatch: .csv file in a GZIP format without a header. If you need to convert your logs to this format, you can use this CloudWatch lambda function.

  • You must have write permission on the Microsoft Sentinel workspace.

  • Install the Amazon Web Services solution from the Content Hub in Microsoft Sentinel. For more information, see Discover and manage Microsoft Sentinel out-of-the-box content.

Architecture overview

This graphic and the following text show how the parts of this connector solution interact.

Screenshot of A W S S 3 connector architecture.

  • AWS services are configured to send their logs to S3 (Simple Storage Service) storage buckets.

  • The S3 bucket sends notification messages to the SQS (Simple Queue Service) message queue whenever it receives new logs.

  • The Microsoft Sentinel AWS S3 connector polls the SQS queue at regular, frequent intervals. If there is a message in the queue, it will contain the path to the log files.

  • The connector reads the message with the path, then fetches the files from the S3 bucket.

  • To connect to the SQS queue and the S3 bucket, Microsoft Sentinel uses a federated web identity provider (Microsoft Entra ID) for authenticating with AWS through OpenID Connect (OIDC), and assuming an AWS IAM role. The role is configured with a permissions policy giving it access to those resources.

Connect the S3 connector

  • In your AWS environment:

    • Configure your AWS service(s) to send logs to an S3 bucket.

    • Create a Simple Queue Service (SQS) queue to provide notification.

    • Create a web identity provider to authenticate users to AWS through OpenID Connect (OIDC).

    • Create an assumed role to grant permissions to users authenticated by the OIDC web identity provider to access your AWS resources.

    • Attach the appropriate IAM permissions policies to grant the assumed role access to the appropriate resources (S3 bucket, SQS).

    We have made available, in our GitHub repository, a script that automates the AWS side of this process. See the instructions for automatic setup later in this document.

  • In Microsoft Sentinel:

Automatic setup

To simplify the onboarding process, Microsoft Sentinel has provided a PowerShell script to automate the setup of the AWS side of the connector - the required AWS resources, credentials, and permissions.

The script takes the following actions:

  • Creates an OIDC web identity provider, to authenticate Microsoft Entra ID users to AWS.

  • Creates an IAM assumed role with the minimal necessary permissions, to grant OIDC-authenticated users access to your logs in a given S3 bucket and SQS queue.

  • Enables specified AWS services to send logs to that S3 bucket, and notification messages to that SQS queue.

  • If necessary, creates that S3 bucket and that SQS queue for this purpose.

  • Configures any necessary IAM permissions policies and applies them to the IAM role created above.

For Azure Government clouds, a specialized script creates a different OIDC web identity provider, to which it assigns the IAM assumed role.

Prerequisites for automatic setup

Instructions

To run the script to set up the connector, use the following steps:

  1. From the Microsoft Sentinel navigation menu, select Data connectors.

  2. Select Amazon Web Services S3 from the data connectors gallery.

    If you don't see the connector, install the Amazon Web Services solution from the Content Hub in Microsoft Sentinel.

  3. In the details pane for the connector, select Open connector page.

  4. In the Configuration section, under 1. Set up your AWS environment, expand Setup with PowerShell script (recommended).

  5. Follow the on-screen instructions to download and extract the AWS S3 Setup Script (link downloads a zip file containing the main setup script and helper scripts) from the connector page.

    Note

    For ingesting AWS logs into an Azure Government cloud, download and extract this specialized AWS S3 Gov Setup Script instead.

  6. Before running the script, run the aws configure command from your PowerShell command line, and enter the relevant information as prompted. See AWS Command Line Interface | Configuration basics (from AWS documentation) for details.

  7. Now run the script. Copy the command from the connector page (under "Run script to set up the environment") and paste it in your command line.

  8. The script will prompt you to enter your Workspace ID. This ID appears on the connector page. Copy it and paste it at the prompt of the script.

    Screenshot of command to run setup script and workspace ID.

  9. When the script finishes running, copy the Role ARN and the SQS URL from the script's output (see example in first screenshot below) and paste them in their respective fields in the connector page under 2. Add connection (see second screenshot below).

    Screenshot of output of A W S connector setup script.

    Screenshot of pasting the A W S role information from the script, to the S3 connector.

  10. Select a data type from the Destination table drop-down list. This tells the connector which AWS service's logs this connection is being established to collect, and into which Log Analytics table it will store the ingested data. Then select Add connection.

Note

The script may take up to 30 minutes to finish running.

Manual setup

Microsoft recommends using the automatic setup script to deploy this connector. If for whatever reason you do not want to take advantage of this convenience, follow the steps below to set up the connector manually.

Prepare your AWS resources

  1. Create an S3 bucket to which you will ship the logs from your AWS services - VPC, GuardDuty, CloudTrail, or CloudWatch.

  2. Create a standard Simple Queue Service (SQS) message queue to which the S3 bucket will publish notifications.

  3. Configure your S3 bucket to send notification messages to your SQS queue.

Install AWS data connector and prepare environment

  1. In Microsoft Sentinel, select Data connectors from the navigation menu.

  2. Select Amazon Web Services S3 from the data connectors gallery.

    If you don't see the connector, install the Amazon Web Services solution from the Content Hub in Microsoft Sentinel. For more information, see Discover and manage Microsoft Sentinel out-of-the-box content.

  3. In the details pane for the connector, select Open connector page.

  4. Under Configuration, expand Setup with PowerShell script (recommended), then copy the External ID (Workspace ID) to your clipboard.

Create an Open ID Connect (OIDC) web identity provider and an AWS assumed role

  1. In a different browser window or tab, open the AWS console.

  2. Create a web identity provider. Follow these instructions in the AWS documentation:
    Creating OpenID Connect (OIDC) identity providers.

    Parameter Selection/Value Comments
    Client ID - Ignore this, you already have it. See Audience line below.
    Provider type OpenID Connect Instead of default SAML.
    Provider URL Commercial:
    sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d/

    Government:
    sts.windows.net/cab8a31a-1906-4287-a0d8-4eef66b95f6e/
    Thumbprint 626d44e704d1ceabe3bf0d53397464ac8080142c If created in the IAM console, selecting Get thumbprint should give you this result.
    Audience Commercial:
    api://1462b192-27f7-4cb9-8523-0f4ecb54b47e

    Government:
    api://d4230588-5f84-4281-a9c7-2c15194b28f7

  3. Create an IAM assumed role. Follow these instructions in the AWS documentation:
    Creating a role for web identity or OpenID Connect Federation.

    Parameter Selection/Value Comments
    Trusted entity type Web identity Instead of default AWS service.
    Identity provider Commercial:
    sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d/

    Government:
    sts.windows.net/cab8a31a-1906-4287-a0d8-4eef66b95f6e/    		 The provider you created in the previous step.
    Audience Commercial:
    api://1462b192-27f7-4cb9-8523-0f4ecb54b47e

    Government:
    api://d4230588-5f84-4281-a9c7-2c15194b28f7    		 The audience you defined for the identity provider in the previous step.
    Permissions to assign
    • AmazonSQSReadOnlyAccess
    • AWSLambdaSQSQueueExecutionRole
    • AmazonS3ReadOnlyAccess
    • ROSAKMSProviderPolicy
    • Additional policies for ingesting the different types of AWS service logs
    		 For information on these policies, see the relevant AWS S3 connector permissions policies page, in the Microsoft Sentinel GitHub repository.
    Name "OIDC_MicrosoftSentinelRole" Choose a meaningful name that includes a reference to Microsoft Sentinel.

    The name must include the exact prefix OIDC_, otherwise the connector will not function properly.

  4. Edit the new role's trust policy and add another condition:
    "sts:RoleSessionName": "MicrosoftSentinel_{WORKSPACE_ID)"

    Important

    The value of the sts:RoleSessionName parameter must have the exact prefix MicrosoftSentinel_, otherwise the connector will not function properly.

    The finished trust policy should look like this:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::XXXXXXXXXXXX:oidc-provider/sts.windows.net/cab8a31a-1906-4287-a0d8-4eef66b95f6e/"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "sts.windows.net/cab8a31a-1906-4287-a0d8-4eef66b95f6e/:aud": "api://d4230588-5f84-4281-a9c7-2c15194b28f7",
          "sts:RoleSessionName": "MicrosoftSentinel_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
        }
      }
    }
  ]
}
    • XXXXXXXXXXXX is your AWS Account ID.
    • XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is your Microsoft Sentinel workspace ID.

    Update (save) the policy when you're done editing.

Add the AWS role and queue information to the S3 data connector

  1. In the browser tab open to the AWS console, enter the Identity and Access Management (IAM) service and navigate to the list of Roles. Select the role you created above.

  2. Copy the ARN to your clipboard.

  3. Enter the Simple Queue Service, select the SQS queue you created, and copy the URL of the queue to your clipboard.

  4. Return to your Microsoft Sentinel browser tab, which should be open to the Amazon Web Services S3 (Preview) data connector page. Under 2. Add connection:

    1. Paste the IAM role ARN you copied two steps ago into the Role to add field.
    2. Paste the URL of the SQS queue you copied in the last step into the SQS URL field.
    3. Select a data type from the Destination table drop-down list. This tells the connector which AWS service's logs this connection is being established to collect, and into which Log Analytics table it will store the ingested data.
    4. Select Add connection.

    Screenshot of adding an A W S role connection to the S3 connector.

Configure an AWS service to export logs to an S3 bucket

See Amazon Web Services documentation (linked below) for the instructions for sending each type of log to your S3 bucket:

Known issues and troubleshooting

Known issues

  • Different types of logs can be stored in the same S3 bucket, but should not be stored in the same path.

  • Each SQS queue should point to one type of message, so if you want to ingest GuardDuty findings and VPC flow logs, you should set up separate queues for each type.

  • Similarly, a single SQS queue can serve only one path in an S3 bucket, so if for any reason you are storing logs in multiple paths, each path requires its own dedicated SQS queue.

Troubleshooting

Learn how to troubleshoot Amazon Web Services S3 connector issues.

Next steps

In this document, you learned how to connect to AWS resources to ingest their logs into Microsoft Sentinel. To learn more about Microsoft Sentinel, see the following articles: