This is the fourth in a series of posts that will drill deeper into cloud security and some of the key questions it sparks. In the third installment, I highlighted physical security in the cloud and the physical security measures Rackspace has in place to protect its cloud customers’ data. In this fourth installment, I will highlight network security in the cloud.
In the cloud, traditional network security measures are still applicable – a secure cloud must be supported by a strong network.
For added security, we at Rackspace have implemented additional steps to manage the risks posed by web-scale virtualization and to manage the scope of our cloud environments. We can provide you services and guidance to assist with the management of additional risks posed by your operational model.
For protection, we ensure all Rackspace network infrastructure devices are located in physically secure data centers with tightly controlled access. As I pointed out in my recent post on physical security in the cloud, all visitors and authorized contractors are logged and escorted, and a host of physical security measures are in place to protect your data. Meanwhile, local console access to network devices is restricted to authorized individuals and requires access to the physical location and the correct username and password configuration.
And while Rackspace uses a wireless infrastructure for corporate connectivity, we do not allow wireless access points in the data halls where cloud infrastructure resides. To identify and neutralize rogue access points, we perform regular wireless scans.
Administrative access to the network devices that power our cloud infrastructure is controlled via industry standard practices, such as TACACS+, and is subject to appropriate logging and monitoring – and those records are retained for a year. Logical access to cloud infrastructure network devices is only given to Rackspace employees with a strong business requirement for such access and it is subject to permissions change control, including independent managerial authorization and timely revocation of access rights. All administrative access to network devices is encrypted.
The network also plays a role in provisioning new cloud environments, which is performed according to standardized procedures to minimize risk of accidental insecure network provisioning. Any changes to existing cloud network infrastructure are controlled by formal change management processes to reduce the risk of accidental insecure configuration.
At Rackspace, we also maintain strict policies on the use of network services. The network services underlying our cloud infrastructure are subject to DDoS/DoS mitigation and network policy enforcement controls to ensure the best possible quality of connection to your cloud resources and maximize the stability of the environment at large. These controls include anti-spoofing and IP prefix-lists, as well as Unicast Reverse Path Forwarding (URPF) protocols in place at edge routers in data centers hosting cloud environments. Additional environment-specific measures like automatically provisioned hypervisor controls are in place to control malicious or accidental misuse of network services by the cloud resources themselves.
At the same time, our network operations teams provide 24×7 monitoring of bandwidth statistics and network traffic trends for anomalies suggesting inbound DoS/DDoS attacks. Appropriate action including the null routing of involved IP addresses for the duration of the attack is taken to mitigate the infrastructure level impact of any DoS/DDoS targeted at cloud resources.
Network security is also key at the product level to protect our environment. Within Rackspace Cloud Servers, for example, newly created instances are configured with two network interfaces by default. The front or public-facing interface is allocated a unique IP address that is used to route traffic from the instance to the Internet. A secondary interface is allocated and assigned an IP address that is not routable to the Internet and is used for communication between instances in the same data center and with other Rackspace services. Recently, we launched Cloud Networks that provide the ability to create a cloud server on a completely isolated network that may or may not touch either of the two networks I just mentioned, depending on how you choose to configure it.
Customer segregation in Cloud Servers is enforced by the hypervisor. Hypervisor controls are in place to prevent MAC, ARP and IP spoofing on the public and private virtual interfaces of each Cloud Server. If a malicious user attempts to spoof IP or MAC addresses, those specific malformed packets are discarded. These rule sets prevent a given Cloud Server from sniffing the traffic of another, even one hosted on the same physical resources.
Logical network security is your responsibility as the customer.
That’s it for this week. I hope you found it informative. Be sure to tune in next week where I’ll talk about certifications, compliance and regulations.