 |
|
|
 |
| |
Amazon Web Services |
 |
|
|
The following information has been provided by Amazon Web Services in their Security Whitepaper posted on Creating HIPAA-Compliant Medical Data Applications with AWS, http://aws.amazon.com/about-aws/whats-new/2009/04/06/whitepaper-hipaa/.
|
|
| |
|
|
| |
 Physical Security
Amazon has many years of experience in designing, constructing, and operating large scale data centers. This experience has been applied to the AWS platform and
infrastructure. AWS data centers are housed in nondescript facilities, and critical
facilities have extensive setback and military grade perimeter control berms as well as
other natural boundary protection. Physical access is strictly controlled both at the
perimeter and at building ingress points by professional security staff utilizing video
surveillance, state of the art intrusion detection systems, and other electronic means.
Authorized staff must pass two-factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
Amazon only provides data center access and information to employees who have a
legitimate business need for such privileges. When an employee no longer has a business
need for these privileges, his or her access is immediately revoked, even if they continue
to be an employee of Amazon or Amazon Web Services. All physical and electronic
access to data centers by Amazon employees is logged and audited routinely. |
|
| |
|
|
| |
Virtual Security
Security within AWS is provided on multiple levels: The operating system (OS) of the host system, the virtual instance operating system or guest OS, a stateful firewall
and signed API calls. Each of these items builds on the capabilities of the others. The
goal is to ensure that data contained within Amazon EC2 cannot be intercepted by nonauthorized systems or users and that Amazon EC2 instances themselves are as secure as possible without sacrificing the flexibility in configuration that customers demand.
- Host Operating System: AWS administrators with a business need are required
to use their individual cryptographically strong SSH keys to gain access to a
bastion host. These bastion hosts are specifically built systems that are designed
and configured to protect the management plane of the cloud. Once connected to
the bastion, authorized administrators are able to use a privilege escalation
command to gain access to an individual host. All such accesses are logged and
routinely audited. When an AWS employee no longer has a business need to administer EC2 hosts, their privileges on and access to the bastion hosts are revoked.
- Guest Operating System: Virtual instances are completely controlled by
Dentisoft. AWS administrators do not have access to the instance, and cannot log into Dentisoft’s operating system. Dentisoft generates its own key pairs in order to guarantee that they are unique, and not shared with other customers or with AWS.
- Firewall: Amazon EC2 provides a complete firewall solution; this mandatory
inbound firewall is configured in a default deny mode and the Amazon EC2
customer must explicitly open any ports to allow inbound traffic. The traffic may
be restricted by protocol, by service port, as well as by source IP address
(individual IP or CIDR block). The firewall is controlled not by the host/instance itself, but requires the customer's X.509 certificate and key to authorize changes, thus adding an extra layer of security. Within EC2, the host administrator and cloud administrator can be separate people, permitting two man rule security policies to be enforced.
- API: Calls to launch and terminate instances, change firewall parameters, and
perform other functions are all signed by an X.509 certificate or the customer’s
Amazon Secret Access Key. Without access to the customer’s Secret Access Key
or X.509 certificate, Amazon EC2 API calls cannot be made on their behalf. In
addition, API calls can be encrypted in transit with SSL to maintain
confidentiality. Amazon recommends always using SSL-protected API
endpoints.
|
|
| |
|
|
| |
Network Security
The AWS network provides significant protection against traditional network security
issues. The following are a few examples:
- Distributed Denial Of Service (DDoS) Attacks: AWS API endpoints are hosted
on the same Internet-scale, world class infrastructure that supports the
Amazon.com retail site. Standard DDoS mitigation techniques such as syn
cookies and connection limiting are used. To further mitigate the effect of
potential DDoS attacks, Amazon maintains internal bandwidth which exceeds its
provider-supplied Internet bandwidth.
- Man In the Middle (MITM) Attacks: All of the AWS APIs are available via
SSL-protected endpoints which provides server authentication. Amazon EC2
AMIs automatically generate new SSH host keys on first boot and log them to the
console. Customers can then use the secure APIs to call the console and access
the host keys before logging into the instance for the first time. Customers are
encouraged to use the SSL endpoints for all of their interactions with AWS.
- IP Spoofing: Amazon EC2 instances cannot send spoofed traffic. The Amazon -
controlled, host-based firewall infrastructure will not permit an instance to send
traffic with a source IP or MAC address other than its own.
- Port Scanning: Port scans by Amazon EC2 customers are a violation of the
Amazon EC2 Acceptable Use Policy (AUP). Violations of the AUP are taken
seriously, and every reported violation is investigated. When Port scanning is
detected it is stopped and blocked. Port scans of Amazon EC2 instances are
generally ineffective because, by default, all inbound ports on Amazon EC2
instances are closed.
- Packet sniffing by other tenants: It is not possible for a virtual instance running in promiscuous mode to receive or "sniff" traffic that is intended for a different
virtual instance. While customers can place their interfaces into promiscuous
mode, the hypervisor will not deliver any traffic to them that is not addressed to
them. This includes two virtual instances that are owned by the same customer,
even if they are located on the same physical host. Attacks such as ARP cache
poisoning do not work within EC2. While Amazon EC2 does provide ample
protection against one customer inadvertently or maliciously attempting to view
another's data, as a standard practice customers should encrypt sensitive traffic.
|
|
| |
|
|
| |
Data Back-ups (Amazon S3)
While real-time data is redundantly stored using RAID, database back-ups occur each hour as well, and are stored redundantly in multiple physical locations as a normal part of our back-up services.
Amazon S3 provides both bucket- and object-level access controls, with defaults that only permit authenticated access by the bucket and/or object creator. Write and Delete permission is controlled by an Access Control List (ACL) associated with the bucket. Permission to modify the bucket ACLs is itself controlled by an ACL, and it defaults to creator-only access.
When an object is deleted from Amazon S3, removal of the mapping from the public
name to the object starts immediately, and is generally processed across the distributed
system within several seconds. Once the mapping is removed, there is no external access
to the deleted object. That storage area is then made available only for write operations
and the data is overwritten by newly stored data.
Dentisoft further encrypts the data on-the-fly prior to storage, and uses encrypted endpoints during transmission to the storage facilities, adding additional layers of data security.
|
|
| |
|
|
 |
|
|
