The Console Settings page is used to make modifications to the console characteristics. This includes the CPU and Memory it is running with, the VPC and Subnets it is running within as well as the access URL you leverage to reach the console. Also included on this page is useful information about this particular deployment.
It is often useful to know the details of how the particular console you are in came about. Which stack did this console get deployed from? Where is it running? What is the unique service name? etc. Whether this is for your own purposes to explore within your AWS account or whether it is to get support from Cloud Storage Security, these data points are helpful. The Console Information section does just that. It gives you your current Subdomain, the CloudFormation Stack Name used to deploy, the uniquely generated Service Name and the AWS Region the console is deployed in.
Send Scan Result Findings to AWS Security Hub¶
AWS Security Hub provides a consolidated view of your security status in AWS. Automate security checks, manage security findings, and identify the highest priority security issues across your AWS environment. Antivirus for Amazon S3 has integrated with AWS Security Hub to allow your Amazon S3 object findings (malware and viruses) to be posted to this central location. Any infected files found within your Amazon S3 storage can be shown and managed alongside the rest of the findings coming from all other aspects of your infrastructure.
It is very simple to start sending
infected scan results to AWS Security Hub. Simply toggle the switch on (becomes purple and text changes from
Enabled) and Antivirus for Amazon S3 will activate
Accept Findings inside of AWS Security Hub and immediately start sending findings. You will not have to manually accept, although you can, the findings service inside the AWS Console. If you do happen to accept the service beforehand, you will still need to toggle inside the Antivirus for Amazon S3 console.
Example Finding within AWS Security Hub Console
Integration as seen inside the AWS Security Hub Console
Antivirus for Amazon S3 expects AWS Security Hub to be subscribed to in the region the console is running within.
Any incident found, no matter the region, will be posted to the console region's AWS Security Hub.
Let us know if you'd like the findings written out to the region they were found in.
Flipping the toggle to enabled when AWS Security Hub is not subscribed to will be reflected with an error.
Stop Accepting Findings for the Antivirus for Amazon S3 service inside the AWS Security Hub console, but do not also disable it in the Antivirus for Amazon S3 settings, we will continue to try to send events and errors will be sent to logs.
In order to give you a secure and consistent experience with how you access the Console, Cloud Storage Security has implemented a subdomain registration process on your behalf. By default, we create a subdomain that is made up of your
AWS account ID - AppID. With this we generate an access URL to the Management Console consisting of
<accountID-appID>.cloudstoragesecapp.com. This is shown to you in the Stack Outputs after completing the CloudFormation Template stack create. You are welcome to continue with this URL for as long as you use the product. But, we have seen with some customers they would prefer something more meaningful and relevant to their organization.
This management page is to allow you to do just that. Pick a value that is useful and meaningful to you. Check the availability just in case it is being used. If your value is unique, the
Save button will be enabled. Clicking
Save will replace the
With any DNS changes, you may find that it takes a couple of minutes for the new URL to be recognized by the DNS servers you are pointing at.
Console Security Group Inbound Access¶
External inbound access to the Console is controlled through an AWS Security Group (identified by the name CloudStorageSecConsoleGroup-
Console Task Settings¶
Task Settings apply to the actual AWS Fargate Task (container) running the console. The default settings within the CloudFormation Template are to run the console with .5vCPU and 1GB of Memory. This is suitable in most cases and certainly when you get started. As your data sets grow and you do more with it as well and if you have large numbers of existing objects you plan to retro scan regularly, you may find that bumping these numbers will help your console run more smoothly. You selected a VPC and two subnets to run the console in during the CloudFormation deployment. There may be times you'd like to change these values after the fact and this section makes it very easy to do so.
This section is to allow you to easily modify the running values of the console.
The Memory must always be set to a value that is between 2x and 8x of the vCPU.
vCPU = 0.5, then 1gb <= memValue <= 4gb vCPU = 1, then 2gb <= memValue <= 8gb vCPU = 2, then 4gb <= memValue <= 16gb vCPU = 4, then 8gb <= memValue <= 32gb
You'll notice a
Private associated with each VPC. This is an indicator of whether or not the VPC is tied to an Internet Gateway. Thought process being that with an IG in place you will have the required outbound access. The console does not require a public IP address or to be accessible from the public in general, but it does require outbound internet access to get to AWS ECR to pull new Task images.
You'll notice a
Restricted associated with each Subnet. This is an indicator of whether or not the Subnet is outbound routable to the internet. Minimally, the agent task must be able to reach the AWS ECR to pull new Task images and to be able to pull AV signature updates. Two validations are performed for this check. First, we check to see if the NACL associated with the Subnet(s) has outbound open for 0.0.0.0/0. Secondly, we check to see if there is a custom Route Table in place and verify it is routed to an internet gateway.
Generally, the first indicator for a good configuration will be whether or not the VPC has an internet gateway or something that is taking its place. Secondly, check the subnets for their outbound access.
Changing these values will cause the console to reboot.
If the VPC or Subnets are not proper for the console, you could have trouble reaching the console.
Retro Scanning Performance Example
Retro Scanning starts by crawling the objects in a given bucket(s) for a given time period. Crawling performance will be impacted by the specs (mainly vCPU) of the Console container. The default specs of .5vCPU will crawl one million objects (spread across 4 buckets in our testing) in about 4 minutes. A console with 2vCPU crawled the same one million objects in ~70 seconds. Extrapolate that out over 10s of millions or billions of objects and it can make a significant difference. We will be providing a mechanism to dynamically change the console specs for the duration of the crawl, but in the mean time please make adjustments to the specs here.