- Cloud Collectors Overview
- Administration
- Onboard Cloud Collectors
- Abnormal Security Cloud Collector
- AWS CloudTrail Cloud Collectors
- AWS CloudWatch Cloud Collector
- AWS S3 Cloud Collector
- AWS SQS Cloud Collector
- Azure Activity Logs Cloud Collector
- Azure Log Analytics Cloud Collector
- Azure Event Hub Cloud Collector
- Azure Storage Analytics Cloud Collector
- Box Cloud Collector
- Cato Networks Cloud Collector
- Cisco Duo Cloud Collector
- Cisco Umbrella Cloud Collector
- Cribl Cloud Collector
- CrowdStrike Cloud Collectors
- GCP Pub/Sub Cloud Collector
- Microsoft Defender XDR (via Azure Event Hub) Cloud Collector
- Microsoft Entra ID Context Cloud Collector
- Microsoft Entra ID Logs Cloud Collector
- Microsoft 365 Exchange Admin Reports Cloud Collector
- Microsoft 365 Management Activity Cloud Collector
- Microsoft Security Alerts Cloud Collector
- Microsoft Sentinel (via Event Hub) Cloud Collector
- Netskope Alerts Cloud Collector
- Netskope Events Cloud Collector
- Okta Cloud Collector
- Okta Context Cloud Collector
- Palo Alto Networks Cortex Data Lake Cloud Collector
- Proofpoint On-Demand Cloud Collector
- Proofpoint Targeted Attack Protection Cloud Collector
- Recorded Future Cloud Collector
- Salesforce Cloud Collector
- SentinelOne Alerts Cloud Collector
- SentinelOne Cloud Funnel Cloud Collector
- SentinelOne Threats Cloud Collector
- SentinelOne Cloud Collector
- Splunk Cloud Collector
- Symantec Endpoint Security Cloud Collector
- Trend Vision One Cloud Collector
- Zscaler ZIA Cloud Collector
- Webhook Cloud Collectors
- Wiz Issues Cloud Collector
- Wiz API Cloud Collector
- Troubleshooting Cloud Collectors
Prerequisites to Configure the SentinelOne Cloud Funnel Cloud Collector
Before you configure the SentinelOne Cloud Funnel Cloud Collector, complete the following prerequisites:
Create the S3 Bucket to store your data, provide SentinelOne with permissions: write objects and list objects, and share the S3 details to SentinelOne.
Configure S3/SQS Integration that receives a notification when new objects are added to the S3 Bucket.
Note
This guide assumes an existence of S3 bucket, and an SQS queue. Before you begin, identify the names for your S3 Bucket and the SQS queue ARNs. If you do not know the names for your S3 Bucket and the SQS queue ARNs, you can find them on the AWS Web Console or use the CLI. Configure the S3 bucket and the SQS queue such that whenever a new object is put into the S3 bucket, the SQS queue gets a notification.
Create the S3 Bucket
For storing your data and for providing SentinelOne with permissions: write objects and list objects, and sharing your S3 details to SentinelOne, create the S3 bucket.
To create the S3 bucket:
Log in to the AWS console with your credentials.
Navigate to the S3 console and click Create bucket. For more information see Creating a Bucket in the AWS documentation. While creating a bucket, when you specify a name for your S3 bucket, ensure that the bucket name is unique and follows the Bucket naming rules mentioned by AWS. For example, mylogs.mycompanyname.
After creating a bucket, add SentinelOne to the list of accounts that can read and write objects in your S3 bucket. For more information see Configuring ACLs.
Access the AWS Console.
In the Buckets list, click the name of the bucket for which you want to set permissions.
Click Permissions.
Scroll down to Access Control List (ACL) and click Edit.
Click Add grantee.
Enter our aws@scalyr.com canonical ID: c768943f39940f1a079ee0948ab692883824dcb6049cdf3d7725691bf4f31cbb.
Enable both List and Write objects.
Click Save changes.
Configure S3/SQS Integration
Use the following steps to configure the SQS queue that receives a notification when new objects are added to the S3 Bucket.
In the AWS Web Console, navigate to the S3 bucket where the data is located.
Under Properties, enable event notification for the SQS queue in the S3 bucket on which you want to receive logs.
For more information, see Enable Event Notifications in the AWS documentation.
Choose All object create events events to be notified.
Allow the S3 Bucket to send events to the SQS Queue.
Replace the access policy attached to the queue with the following policy (in the SQS console, you select the queue, and in the Access policy tab, click Edit Access policy (Permissions).
{ "Version":"2012-10-17", "Id":"example-ID", "Statement":[ { "Sid":"example-statement-ID", "Effect":"Allow", "Principal":{ "AWS":"*" }, "Action":[ "SQS:SendMessage" ], "Resource":"SQS-queue-ARN", "Condition":{ "ArnLike":{ "aws:SourceArn":"arn:aws:s3:*:*:bucket-name" } } } ] }
Obtain the SQS Properties
To obtain the SQS properties (SQS URL, SQS Region, and the SQS Message Origin), log in to your AWS account and refer to the following steps:
SQS URL – Go to the SQS service and check the SQS Queue used for the S3 events notifications. In the Details tab copy the URL value.
SQS Region – In the SQS Service page in the SQS Details tab, you view the SQS region. It is the string between the sqs and amazonaws strings in the URL. In the example above, the region is: us-east-1.
SQS Message Origin – Based on the integration you are configuring; messages are put in the queue in different ways.
For the messages put in the queue by the above setup, in which S3 notifies the SQS directly, select S3_TO_SQS.
For the messages put in the queue using the above method, in which the messages are sent from S3 to SNS, and then configured in SNS to be sent to SQS, select S3_TO_SNS_TO_SQS.