Appendix B: Security Group (SG)
AWS has a limitation where virtual machine with multiple network interfaces cannot connect to different Virtual Private Cloud (VPCs). For example, a VM with two NICs, NIC1 and NIC2, will not be able to connect to VPC1 and VPC2 respectively.
AWS supports a virtual machine with multiple NICs to connect to different Subnets under a same Virtual Private Cloud. For example, a VM with two NICs, NIC1 and NIC2, can connect to ‘Subnet1’ and ‘Subnet2’ where these subnets exist under a same Virtual Private Cloud respectively.
AWS provides isolation between different VPCs. But it does not provide the same kind of isolation when it comes to subnets in the same VPC. For example, consider a VPC has two subnets, Subnet1 and Subnet2. And consider two VMs, VM-1 and VM-2, which are connected to Subnet1 and Subnet2 respectively. In this scenario VM-1 can access the resources from VM-2 and vice versa.
Application isolation is an important concern in enterprise environments, as enterprise customers seek to protect various environments from unauthorized or unwanted access. To achieve the traffic isolation between subnets, go for an option of filtering traffic using “Security Group” provided by AWS.
Ivanti Connect Secure, when provisioned through the CloudFormation template provided by Ivanti, creates four subnets under a virtual private cloud named “ICSVirtualNetwork”. The four Subnets are:
- ICSInternalSubnet
- ICSExternalSubnet
- ICSManagementSubnet
- ICSTunnelVPNPoolSubnet
Along with above mentioned subnets, create the following three Security Groups (SG) policies:
- SGExternalSubnet
- SGInternalSubnet
- SGManagementSubnet
In Security Group (SG) we need to create policies for Inbound and outbound traffic.
- The list of SG Inbound/Outbound rules created “Stack-ICSvExtSG” are:
- The list of SG Inbound/Outbound rules created “Stack-ICSvIntSG” are:
- The list of SG Inbound/Outbound rules created “Stack-ICSvMgmtSG” are:
