AMAZON EC2 SECURITY MODEL

AMAZON EC2 SECURITY MODEL
For Amazon EC2, security is provided on several levels i.e. host OS, guest OS or Instance using firewalls and signed API calls [24]. Host OS security relies on cryptographically strong SSH keys that the user uses to log into the system. On the other hand, guest OS security enables the user to grant root access to these machines. Use of privilege escalation, SSH keypairs or user generated keypairs is encouraged.

For network security, Amazon defines Security groups, which are akin to firewalls. Security groups in EC2 have a default 'block-all-incoming-traffic' policy. A customer must manually open up ports for allowing inbound traffic to an instance. The traffic is configurable by protocol, port number, CIDR block or individual IP addresses. Similarly, outbound traffic can be controlled using iptables [25]. An instance can have multiple security groups, each with similar policies grouped together. As an additional layer of security, a firewall is configurable only by someone who possesses both the private key and the X.509 certificate, attached to each account. Given this setting of the firewall and the guest OS, it is possible to isolate two separate classes of administrators, the host administrator and the cloud administrator.

All calls to APIs must be signed with the account's X.509 certificate or the Secret Access Key. Amazon also recommends that the developer encrypt the API call using SSL, for added protection.

In order to safeguard the physical CPU (which runs instances) being compromised, Amazon uses a highly customized version of Xen [10]. This runs all the guest OS privileged instructions via the hypervisor, with elevated access to the actual machine underneath being impossible. Instance isolation on the same physical machine is achieved by placing the firewall (mentioned above) between the actual physical interface and the virtual interface of the instance. This ensures isolation similar to that offered by physically placing the machines apart. Physical RAM is protected using similar mechanisms.

To start or stop an instance, a user must possess the X.509 certificate and the private key. However, this can also be achieved via the AWS Management Console through a simple login and password. This creates vulnerability in the whole system. Moreover, AWS EC2 does not provide customer accessible audit log for forensic analysis in case of a breach.

6.3 MITIGATING ATTACKS
AWS provides standard provisions to circumvent attacks like Distributed Denial of Service (DDoS), man-in-the-middle attacks using mitigation techniques such as SYN cookies, limiting bandwidth, mutual authentication. IP spoofing is not possible and port scanning is ineffective, since all incoming ports are blocked by the security group default. The packet sniffer is rendered ineffective by the hypervisor, which does not deliver packets not addressed to it, even if the sniffer is placed in promiscuous mode. However, as with any new technology, there are bound to be exploits which are yet to be exposed. But they’re more likely to be part of the management tools used to transfer and modify cloud data as well as remote tools used to access applications in the cloud than the clouds themselves.

6.4 AMAZON S3 SECURITY MODEL
Security for S3 poses a different problem. This is primarily due to the storage model employed by S3. The key challenges include being able to control access to the data in a bucket or an object. Hence, Amazon provides default bucket level and object level access controls mechanisms using an Access Control List (ACL) to prevent data from being read by anyone. Amazon S3 data is sent on end-to-end SSL encrypted links. This prevents data leakage or theft while in transit. Encrypted file systems are not provided by default, so the customer has to encrypt their data before storing it on S3 [24]. This might be because key escrow is difficult and taking responsibility for keys that essentially ‘lock’ customer data is a daunting responsibility.

Since EBS is relatively new, it remains to be seen how the security policies around EBS are defined with respect to snapshots from EBS to S3 being encrypted and use of SSL for sending data between an EC2 instance and EBS volume.