CloudGuard Permissions for Intelligence

A notification email informs you that CloudGuard cannot get logs from your S3 bucket <storage-name> because of the AccessDenied error. This error means that you removed some permission that allowed the collection of your logs.

The most usual cause of denied access is changes made in the IAM Identity and Access Management (IAM) - A web service that customers can use to manage users and user permissions within their organizations. Policy. To verify your IAM Policy, make sure that you have the correct CloudGuard-for-intelligence policy attached:

Reason 1:

The Intelligence policy connected to the CloudGuard trusted IAM role was changed or deleted by one of the users in the AWS Amazon® Web Services. Public cloud platform that offers global compute, storage, database, application and other cloud services. account.

Solution for Reason 1

It is necessary to restore the removed permissions.

To restore the removed permissions:

1. In the AWS console, open the CloudGuard trusted IAM role.

   To find the trusted IAM role, open the CloudGuard portal. After the cloud account is opened, the ARN Amazon Resource Names (ARNs) uniquely identify AWS resources. They are required to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls. role shows in the wizard in edit permissions.

2. Add a new inline/managed policy with the necessary permissions based on your S3 buckets A bucket is a container for objects stored in Amazon S3 (Amazon Simple Storage Service)..

   s3:GetObject - Allow this procedure for all S3 buckets onboarded to Intelligence. You must include the bucket ARN and the bucket ARN with an '/*' suffix to show that permissions apply to all objects.

   Copy

   {
       "Sid": "IntelligenceRequiredBucketPermissions",
       "Effect": "Allow",
       "Action": [
           "s3:GetObject"
       ],
       "Resource": [
           "arn:aws:s3:::cloudguard-intelligence-example-s3-bucket",
           "arn:aws:s3:::cloudguard-intelligence-example-s3-bucket/*",
       ]
   }

   kms:Decrypt - Allow this procedure on all the KMS AWS Key Management Service (AWS KMS) - A managed service that simplifies the creation and control of encryption keys that are used to encrypt data. keys the ARN used to encrypt the S3 bucket files or the CloudTrail logs directly.

   Copy

   {
       "Sid": "IntelligenceRequiredBucketOrCloudTrailDecryptPermissions"
       "Action": "kms:Decrypt",
       "Effect": "Allow",
       "Resource": [
           "arn:aws:kms:_____:1**********2:key/********-****-****-****-************"
       ]
   }

   sns:Subscribe and sns:Unsubscribe - These permissions are not directly required to retrieve the log files from the S3 bucket. Rather, Intelligence applies these permissions in its use enforcement process. Allow these procedures for all of the SNS topics used to send the S3 bucket event notifications to the Intelligence SQS Reliable and scalable hosted queues for storing messages as they travel between computers. queue.

   Copy

   {
       "Sid": "IntelligenceUsageEnforcementRequiredSnsPermissions",
       "Action": [
           "sns:Subscribe",
           "sns:Unsubscribe"
       ],
       "Effect": "Allow",
       "Resource": [
           "arn:aws:sns:_____:1**********2:______"
       ]
   }

Important - Do not change the inline IAM policy added as part of the CloudFormation Intelligence onboarding stack. These changes could be overwritten by future onboardings, but append a new inline/managed IAM policy.

Reason 1.2:

A different cause is a change to the CloudGuard trust policy.

The trust policy of the CloudGuard trusted role was changed, which causes permission issues in CloudGuard. For example, if the trust policy does not grant permissions to the right CloudGuard AWS account or the External ID required in the condition does not align with the one CloudGuard sends. To see the External ID from CloudGuard, in Cloud Account go to Edit Credentials.

Solution for Reason 1.2

It is necessary to correct the CloudGuard role trust policy.

To correct the CloudGuard role trust policy:

1. Give sts:assumerole permission to the CloudGuard AWS Account ID.

2. Set the External ID condition to the right value.

   The trust policy shows in the AWS Console below the Trust relationship section for the specific IAM Role.

To find the trust role and External ID value that CloudGuard uses:

1. Open the environment page in the CloudGuard Portal.

2. Select the applicable AWS account and click Edit Credentials.

   The value shows below the Role ARN and External Id sections.

   Copy

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam:: 1**********2:root"
               },
               "Action": "sts:AssumeRole",
               "Condition": {
                   "StringEquals": {
                       "sts:ExternalId": "************************"
                   }
               }
           }
       ]
   }

Reason 2:

The S3 bucket resource-based policy was changed to include an explicit denial that overrides the intelligence permission to do S3:GetObject.

Solution for 2

Exclude the CloudGuard trusted IAM role from the explicit deny.

To see the resource-based policy for the S3 bucket:

1. Go to the bucket view.

2. Select the Permission tab in the AWS Console.

Reason 3:

Encryption was added to the S3 bucket or directly to the CloudTrail.

Solution for 3

Add a new inline/managed policy to the CloudGuard trusted IAM role with the kms:Decrypt permissions with the correct KMS key resource.

To find the KMS KEY ARN:

1. Go to related CloudTrail and get the ARN, which is below the Log file SSE-KMS encryption.

2. Go to bucket > Properties > Default Encryption.

Add a new inline/ managed policy with the kms:decrypt resource to the CloudGuard trusted IAM role.

Copy

{
    "Sid": "IntelligenceRequiredBucketOrCloudTrailDecryptPermissions"
    "Action": "kms:Decrypt",
    "Effect": "Allow",
    "Resource": [
        "arn:aws:kms:_____:1**********2:key/********-****-****-****-************"
    ]
}

Important - Do not change the inline IAM policy added as part of the CloudFormation Intelligence onboarding stack. These changes could be overwritten by future onboardings. To prevent this, append a new inline/managed IAM policy.

This error means that you removed the CloudGuard AWS account from your trusted entities.

To add the account to the trusted entities:

1. Log in to the AWS console (aws.amazon.com).

2. Select Services and select the IAM service.

3. Click Roles and search for the Role created for CloudGuard (usually, CloudGuard-Connect).

4. To verify the External ID on the Role, click the Trust relationships tab.

5. Make sure that the External ID is the same as given on the CloudGuard portal.

   Note - The External ID must not be empty.

6. If the External ID is empty or it is necessary to change it, click Edit trust relationship and correct it as required.

Set the AllowBlobPublicAccess property to Enabled.

1. In your Azure storage account, navigate to Security + networking > Networking.

2. On the Firewalls and virtual networks page, in the Public network access, see which option is selected:

   • If Disabled is selected, change it to Enabled from selected virtual networks and IP addresses option. Make sure you have a proper IP rule that allows Intelligence collectors to collect log data from the storage account.

   • If Enabled from selected virtual networks and IP addresses is already selected, make sure you have a proper IP rule that allows Intelligence collectors to collect log data from the storage account.

   Note - If you change the Enabled from all networks option to Enabled from selected virtual networks and IP addresses, do it with caution as it impacts all access to the storage account.

3. In the Firewall section, enter an IP address based on your Data Center location. For the full list of the IP addresses, refer to FAQ.

4. Click Save.

CloudGuard supports retrieving logs using App Registration credentials. Sometimes, storage accounts onboarded with App Registration credentials can have issues with access to the CloudGuard portal.

To correct the issues, follow the instructions in Invalid Credentials or Missing Permissions.