Steps to Deploy

Deployment of our solution happens using a CloudFormation Template.

If you're planning to deploy both AV and DC at the same, then subscribe to both products and deploy AV first. When you enter the AV management console you can navigate to Configuration->License Management, where you will see an option to activate DC.

Consider your deployment options

Which parameters you configure in the CloudFormation Template depends on what your requirements for your deployment are. Options include:

• The Standard Deployment which requires filling out only 5 fields in the CloudFormation Template

• A completely Private Deployment where all of our components run in private VPCs and private Subnets with no public IPs assigned at all

• An in-between option where you have public access (public Load Balancer) while still running all solution components in a private VPC and Subnets

You can mix and match as well as incorporate VPC Endpoints to keep as much traffic as possible going over the AWS backbone.

For an in-depth overview of deployment options and details click here.

Standard Deployment

The Standard Deployment is the simplest deployment. After providing only 5 inputs to the CloudFormation Template you will have a deployed and running solution in ~5 minutes. This deployment expects the Console and the Agent(s) to be placed in VPCs and Subnets that have an Internet Gateway (IGW) allowing for outbound traffic.

This a typical setup for VPCs and Subnets.The outbound routing allows ECS to pull down images from ECR, allows the Console and Agent(s) to communicate with required AWS Services and provides access to the management UI. Although public IPs are assigned, control is still done through Security Groups and access can be limited through IP ranges.

With this deployment, we register your application subdomain with a Route53 Hosted Zone we host and manage in one of the Cloud Storage Security AWS accounts. This allows you to have consistent access to your application. If you'd prefer to manage the domain and SSL certificate required for a persistent URL yourself, you can leverage the Application Load Balancer options discussed below and on the Advanced Deployment Considerations page.

Step 1 - Quick Create Stack and Specify the Parameters

You must provide values for the following fields in the CloudFormation template:

1. Virtual Private Cloud (VPC) ID

2. Subnet A ID

3. Subnet B ID

4. Console Security Group CIDR Block

5. Email

You can leave all the default settings in the rest of the fields.

Set your network configuration

Set an initial email address

Virtual Private Cloud (VPC) ID

You must select a VPC from the drop down list for the Management Console to run in.

Subnet A ID

You must select a Subnet A ID from the drop down list contained in the selected VPC. Since we are doing a Standard Deployment, the subnet you select should be public, meaning it should have an IGW attached to it that allows outbound traffic.

Subnet B ID

You must select a different Subnet B ID from the drop down list contained in the selected VPC.

The subnets you choose for A and B must either be able to offer a public IP or be on a network you can access. Without that, the console will run, but not be reachable. This could simply be a public subnet reachable through an Internet Gateway.

Alternatively, it could be a private subnet that is an extension of your corporate network you access either from your corporate network or through a VPN connection. Or these subnets may be private subnets fronted by a public Load Balancer. Learn more about this option in the Advanced Deployment Considerations.

If you want to deploy privately continue reading further below.

Please note, If you select the same subnets for A and B, stack creation will fail. If you happen to pick the same value for each field, you will get a message as follows, please correct this before moving on.

Ensure both subnets you select belong to the VPC you have selected. You must select subnets in different Availability Zones.

Console Security Group CIDR Block

We will create a Security Group (SG) for the Management Console that we deploy. This SG will have rules that contain IP ranges which can access the Console. You must select a Console Security Group CIDR Block. Specify your network access or set to "0.0.0.0/0" to access the Management Console from anywhere.

If you need to add multiple IP ranges you can set your first one through the CloudFormation Template and once the solution is deployed you can go to the SG to add additional rules.

0.0.0.0/0 is wide open to the world. The application is still protected by SSL, a username and a password, but you may still choose to control this access. This could be your corporate network range or the /32 IP address your specific system is currently assigned. Google "what's my ip" and the first thing returned is what your current IP address is. Note: If your IP address changes, you may have to manually change the AWS Security Group value to represent the new IP

Email

You must set a valid Email address which we will use to send the initial account username and password that you will use to access your Management Console.

If you do not properly set the above 5 parameters, the stack creation will fail and/or you will be unable to access your deployment. If you run into any trouble whatsoever, please Contact Us and also make sure to review the Troubleshooting section of our help docs.

Step 2 - Review Stack and Acknowledge

Acknowledge before creating the stack

Ensure you have set all of the parameters in your CFT correctly. Check I acknowledge that AWS CloudFormation might create IAM resources with custom names. under Capabilities. Click Create Stack at the bottom of the screen.

Step 3 - Track the events and troubleshoot if needed

The stack you just created will have a status of CREATE_IN_PROGRESS as it runs. Wait for this to change to CREATE_COMPLETE and monitor the events it generates.

When finished the status for the stack will show CREATE_COMPLETE:

If the stack creation fails, click here to open the Troubleshooting section.

Step 4 - Console Access

Once the stack creation completes, click the Output tab. The top row in the table will have the URL for your Management Console. It will be in the format of https://<accountID-appID>.cloudstoragesecapp.com.

You will also receive an email to the address you entered while configuring your CloudFormation Template details. This email will include the URL to your console + a username and password which you will use to login to your account.

It may take a few minutes for DNS to propagate the URL of your management console. If you are unable to load the URL provided in the email/CloudFormation Outputs then wait a few minutes. If it continues to be an issue, check the console access troubleshooting to see if it is another issue or Contact Us.

If you chose to use a load balancer, the first field will be called LBWebAddress instead of ConsoleWebAddress

Private Deployment

In order to deploy privately you'll have to set the 5 parameters discussed above in the Standard Deployment section. However, this time you'll need to choose two private subnets (again in separate availability zones).

Private Deployments are defined by locking down the solution components (Console and Agents) such that they do not have public IPs (meaning leveraging private subnets that are behind a NAT Gateway). You can still provide public access if desired while locking everything else down. Whether it is best practices, compliance or internal rules you can deploy and leverage the solution as needed.

If you reviewed the Deployment Details page you'll see the deployment options leveraging Application Load Balancers. These can be internet-facing or internal and can even be leveraged with the Standard Deployment. You do not have to leverage an ALB in a private deployment, but there are a number of reasons you might want to.

First off, AWS Fargate tasks do not get assigned persistent IP addresses. As a result, the IP address can change underneath you requiring you to look it up. You may also decide you'd like to manage or apply your own domain and SSL certificate for accessing the application. A load balancer allows you to accomplish all of these things: a persistent access point, apply your own domain and leverage your own certificates.

Accessing a private deployment

If you only choose to use private subnets and do not use a Load Balancer in front of your Management Console, you will need to use the private IP that is generated by the ECS task that is stood up to host the console.

If you would like to have a persistent URL to access your privately deployed management console then you will need to stand up a load balancer in front of it. You can read more on this topic on the Deployment Details and Advanced Deployment Considerations page.

Advanced Deployment Considerations

The 5 fields discussed above are the minimum fields that have to be set to get the product successfully deployed. For many deployments, the default settings will work well. With that said, the other options in the CloudFormation Template could be beneficial for you to configure and therefore could warrant your attention.

To view details for configuring additional settings within your CloudFormation Template you can review our Advanced Deployment Considerations section. Feel free to SKIP this section if you just want to start with the defaults. However, please consider two exceptions:

1. By default, the stack will deploy without the use of a Load Balancer. There are times when this will not work for your use case. Two such scenarios are: you want to use your own DNS and SSL certificate or you want to deploy in a private subnet behind a NAT. These are both great reasons to leverage a load balancer.

   If you would like to include a load balancer at the time of deployment you can do so in your CloudFormation Template. You can also add a load balancer to an existing deployment without one. And you can remove the load balancer after the fact as well. Simply run a Stack Update and add or remove the load balancer. This must be done manually through the CloudFormation Console.

2. Resources can only be renamed to match your particular naming scheme at the time of deployment. Changing these values later will result in errors. The default values are fine to leave but if you feel the need to rename values such as your quarantine bucket you should do so now before you've deployed.

You can learn more about both of the above considerations by reviewing our Advanced Deployment Considerations section.

After you have finished deploying

You have completed creating the stack for Antivirus and/or Data Classification for Amazon S3. Next, go to the How to Configure section to start setting up the anti-malware detection.