AWS Client Stack Deployment

Create SQS Queues

Create 2 SQS queues manually as follows:

1. content sync-prod-job-process-v1

2. contentsync-prod-etl-process-v1

Create S3 Buckets

Create 2 buckets manually:

content-sync-configuration-$subdomain - This bucket will use to share the AWS setup script to the user.

$subdomain-prosperoware-io-encrypted-bucket - This bucket will use to store the client's content. Set default encryption to AES-256

Create the VPC

• Litera will share the scripts to create VPC.

• Download the scripts will be available at content-sync-configuration-$subdomain/vpc-configuration/.

• Configure AWS CLI. Follow instructions provided at AWS: AWS CLI.

• Execute below command on the terminal to create VPC:

• sh deploy.script create-stack --region us-east-1

Create the Lambda Security Group

1. Head over to VPC

2. Under Security Group click Create Security Group:

• Set the security group name to Lambda-SG

• Select the VPC created from the previous step.

• Add a rule for inbound and outbound as All Trafic and Source 0.0.0.0/0 or Destination as 0.0.0.0/0

Upload the shared content to the S3 bucket

Update the below 2 files

1. Open params-prod.yml available at S3Content/serverless/params/us-east-1

   • LambdaRole (update the AWSACCOUNTID to your AWSACCOUNTID)

   • SecurityGroup (Lambda-SG created in the previous step)

   • SubnetIds (please update the SubnetIds to the private subnet IDs of the VPC created earlier)

   • ContentSyncJobProcessQueue (update the AWSACCOUNTID value to your AWSACCOUNTID)

2. Open appconfig-prod.yml available at S3Content/config/ymls

   • CS_JOB_QUEUE (Update the AWSACCOUNTID value to your AWSACCOUNTID

3. Upload these files in S3 bucket content-sync-configuration-$subdomain

Create a CodeBuild project

1. Go to CodeBuild Console

2. Click Create build project.

3. Setup a Project name and Description in section Project Configuration.

4. Select the source provider to S3.

5. Choose the bucket content-sync-configuration-$subdomain created in previous steps.

6. Select s3 object key or folder type “serverless/”

7. Note: This folder on S3 used for stack.

8. Select operating system Ubuntu as Environment Section

9. Set the Runtime (s) to standard. Set image to: aws/codebuild/standard:2.0. Image version to Always use the latest image for this runtime version. And environment type to Linux.

10. Leave the privileges section unchecked.

11. Select New service role and set the role name to contentsync_role.

12. Click on Additional Configuration.

13. Set VPC to created in the previous steps.

14. Set the Subnets to Private Subnet #1 and Private Subnet #2.

15. Set the Security Group to the Lambda Security Group created at Step #3.

16. Under BuildSpec, select insert build commands and insert the build spec file shared at S3Content/serverless/buildspec.yml.

17. On the buildspec file there are some pre-configured commands that don’t need changes:

• The runtime version. Installing serverless. Deploying the Stack to the desired AWS region.

18. No change to artifacts.

19. Enable CloudWatch logs option.

20. Set The group name and stream name to blank.

21. Click create build project.

Create the IAM Role

Name the Lambda role: content_sync_lambda_service_node

Provide following permissions to Lamda role:

• AmazonEC2FullAccess

• SecretsManagerReadWrite

• AmazonSQSFullAccess

• AmazonS3FullAccess

• AmazonDynamoDBFullAccess

• AmazonSESFullAccess

• AmazonVPCFullAccess

• AmazonSNSFullAccess

• ContentSyncLambdaBasicExecution(Managed Policy)

• KMSWriteLambda(Managed Policy)

Edit the IAM Role

On the IAM console go to Roles.

Click contentsync_role.

Under Permissions of role, attach the AdministratorAccess Policy.

Deploy the Stack

1. Go to CodeBuild service console.

2. Click the created Content Sync project under Build Projects.

3. Click Start Build.

The data under Start Build section is predefined and do not be overwritten.

Lambda Validation

1. Go to Lambda console 

2. There will be 9 lambda functions deployed for content sync and ETL (Content Mover): 

• contentsync-**-contentsync-worker-v1 

• contentsync-**-contentsync-api-v1 

• contentsync-**-contentsync-manager-v1 

• contentsync-**-contentsync-etl-worker-v1

• contentsync-**-contentsync-etl-mapping-manager-v1

• contentsync-**-contentsync-etl-renewal-manager-v1

• contentsync-**-contentsync-etl-renewal-worker-v1

• contentsync-**-contentsync-etl-mapping-worker-v1

• contentsync-**-contentsync-systemauth-reload-v1

   

For each of the 9 lambdas above,

• select the Code source section,

• click on the upload from drop-down button → Amazon S3 location.

• Supply the Object URL of the jar file uploaded to the lambda-functions-code folder within the content-sync-configuration-[tenantname] bucket.

For latest content sync code go to “Prosperoware-cam.contentsync.apis-1.0” on Jenkins and check the lastest build that we deployed in prod. If build number was #130 then go to this S3

Complete the Function Upload

Click Upload under function package. Upload the jar shared at S3Content\lambda-functions-code folder, and click save on top right corner.

Create S3 Buckets

Create 2 buckets manually:

content-sync-configuration-$subdomain - This bucket will use to share the AWS setup script to the user.

$subdomain-prosperoware-io-encrypted-bucket - This bucket will use to store the client's content. Set default encryption to AES-256

Upload the shared content to the S3 bucket

Update the below 2 files

1. Open params-prod.yml available at S3Content/serverless/params/us-east-1

   • LambdaRole (update the AWSACCOUNTID to your AWSACCOUNTID)

   • SecurityGroup (Lambda-SG created in the previous step)

   • SubnetIds (please update the SubnetIds to the private subnet IDs of the VPC created earlier)

   • ContentSyncJobProcessQueue (update the AWSACCOUNTID value to your AWSACCOUNTID)

2. Open appconfig-prod.yml available at S3Content/config/ymls

   • CS_JOB_QUEUE (Update the AWSACCOUNTID value to your AWSACCOUNTID

3. Upload these files in S3 bucket content-sync-configuration-$subdomain

Complete the Function Upload

Click Upload under the function package. Upload the jar shared at S3Content\lambda-functions-code folder, and click save on the top right corner.

Security Configuration and Validation

AWS operates under a shared responsibility model. AWS takes care of security ‘of’ the cloud while we (AWS customers) are responsible for security ‘in’ the cloud. Let's validate the security for each AWS service used.

Identity and Access Management (IAM)

1. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

2. Do not access AWS with root administrator instead encourage to use user defined in IAM

SQS Queues

The queues use the default encryption provided by AWS.

S3 - Simple Storage Service

1. Default encryption – The second bucket is where the content will be stored, is encrypted with AES-256. This helps securely stores the files residing in the bucket.

2. Object lock – Prevents certain objects from being deleted.

3. Bucket policy, ACLs, and CORS - Not be accessible to the open web, or even from other accounts within your AWS Organisation. To protect sensitive data, permissions can be set by configuring.

VPC

• One VPC per your environment with 2 private subnets and 2 public subnets. The private subnets will be used when setting up the deployed resources so there’s no external access to the AWS resources provisioned.

Lambda Security Group

1. The Lambda security group is created inside the VPC so there’s no outside access allowed to the resources using the security group.

2. The inbound and outbound rules will allow access to all the services in the VPC.

3. Create lambda role - The lambda role will be created to share access between Lambda and other resources; and other resources between themselves.

4. Custom policies allows the lambda to create and write logs into CloudWatch

DynamoDB

1. Data is redundantly stored on multiple devices across multiple facilities in an Amazon DynamoDB Region

2. All user data stored in Amazon DynamoDB is fully encrypted at rest, it encrypts your data using 256-bit Advanced Encryption Standard (AES-256),

3. DynamoDB encryption at rest provides an additional layer of data protection by securing your data in an encrypted table—including its primary key, local and global secondary indexes, backups.

4. Use IAM roles to authenticate access to DynamoDB

   Use IAM policies for DynamoDB base authorization

Set up security monitoring

1. API Gateway

   1. This AWS Service is for creating, publishing, maintaining, monitoring and securing APIs.

   2. In CAM we use REST APIs integrated with Lambda functions endpoints or other AWS Services to restrict unauthorized access.

   3. The data which is in transit is encrypted by default through API Gateway

2. CloudTrails

   1. AWS Cloudtrail is another service we use as an integrated service with API Gateway

   2. Cloudtrail is a service that provides a record of events or actions taken by a user, role or AWS Service in API Gateway.

   3. Cloudtrail captures all REST API calls. This helps us strengthen security on API Gateway by auditing and monitoring internally the REST API calls being made from the API Gateway console and also code calls to the API Gateway service APIs.

3. GuardDuty

   1. Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, workloads, and data stored in AWS.

   2. GuardDuty analyzes tens of billions of events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon VPC Flow Logs, and DNS logs.

   3. We have enabled Amazon GuardDuty in all AWS Regions (in those which are not using either) as recommended by AWS for better security protection.

   4. The following list contains some types of attacks that GuardDuty can detect:

      • Denial Of Service

      • Brute Force

      • Tor Client

      • Attacks from different OS (Kali Linux, Parrot Linux, Pentoo Linux)

      • Phishing Domain Request

Elastic IP Configuration for client stack

• Once you deployed the client stack on your AWS account you follow the following procedure for configuring the client stack and iManage region where you provisioned your AWS client Stack.

Whitelisting for AWS

For more information on iManage region whitelist IP’s click here

• Navigate to the AWS account

• Navigate to the VPC service, opens the following screen -

Open

• Navigate to the NAT Gateways, view the following screen -

Open

• The elastic IP addresses attached to each NAT Gateway

• The attached IP’s should whitelist against your iManage server for the client stack