Elastic Path CloudOps for AWS creates three security groups, such as a public security group, a private security group, and a bastion security group. The public security group controls access to infrastructure in the public subnet, the private security group controls access to infrastructure in the private subnet, and the bastion security group controls access to the bastion server.
The Author and Live environment is deployed across the public and private subnets. However, you can only access infrastructure in the public subnet directly, and all important load-balancers(LB) are created in the public subnet.
- The public security group and private security groups allow all communication within themselves. All resources in a public security group or private security groups can communicate together with other resources in the same group.
- The public and private security groups allow all communication between each other.
- The public security group allows all communication from a VPN IP address set at the beginning of CloudOps initialization, but the private security groups do not allow this.
- The public and private security groups allows all communication from the bastion server.
- The bastion security group allows communication from the public and private security groups only through TCP traffic on port 22.
- The bastion security group also allows communication from the VPN IP address on ICMP traffic and on TCP traffic on port 22.
Data Security in CloudOpsData in Flight
Amazon's Elastic Load Balancers (ELBs) are the primary public and internal interface for CloudOps. The CloudCore component creates security groups to control traffic to ELBs. By default, these security groups restrict incoming traffic to resources inside the security group, but allow unrestricted outgoing access. The default setting for public security group allows all traffic from the IP address which run the init.sh script.
The public security group consists of the public ELBs. The private security group only allows access from the AWS resources inside the group and the public security group. This configuration ensures that only the public ELBs can connect to the back-end instances not regular web traffic. The ELBs only connect to the back-end instances on the HTTP ports. For non-VPN enabled access to the back-end instances, all SSH communication are done through bastion and its own security group.
You can configure Elastic Path CloudOps for AWS to encrypt traffic by enabling HTTPS on all load balancers. This uses a feature of AWS ELBs to offload all Transport Layer Security (TLS) encryption to the load balancers. HTTP load balancers internal to the CloudOps network are also run in TLS mode if the secure flag is enabled. However, all other traffic run unencrypted.
Elastic Path uses the AWS Certificate Manager (ACM) to store the SSL or TLS certificate that AWS ELBs use. You must have an SSL certificate to enable secure mode on the load balancers. Elastic Path recommends using the AWS Certificate Manager (ACM) to create SSL certificates. Alternatively, if you already have a certificate, you can import the certificate into ACM.
Data at Rest
CloudOps uses Amazon RDS instances to provision the database. This Amazon RDS instance and the snapshots at rest are not encrypted, however you can use the Amazon RDS encryption service, which uses AES-256 encryption algorithm to encrypt data on the server that hosts your Amazon RDS instance, to encrypt data in the database. For more information, see Encrypting Amazon RDS Resources.