Using Amazon Web Services (AWS) Under Cornell’s Master Contract

Cornell IT has entered into an Enterprise Agreement with Amazon to provide public cloud services to the Cornell community. The agreement allows Cornell faculty and staff (but not students) to opt-in to use AWS cloud-based IT infrastructure services under a Cornell Master Account. Participating in the Enterprise Agreement has a range of benefits.

The Cornell Enterprise Agreement was reviewed and approved by University Counsel, and provides greater protections than the standard AWS click-through license terms. See this page for a list of data types approved for use in AWS under the master agreement.

AWS is not a service provided by Cornell IT. AWS is a contracted-for service that individual Cornell units can purchase and use. Use of AWS and associated fees are the sole responsibility of each purchasing unit. The responsibility of Cornell IT is limited to maintenance and oversight of the Enterprise Agreement, and monthly rebilling of AWS charges to units whose service consumption generated those charges.

What is needed to participate in Cornell’s AWS Contract?

• An onboarding discussion with CIT, College Business Officer (CBO), IT Director and Security Liaison to discuss information regarding responsibilities and practices.
• Commitment from the College Business Officer to take responsibility for all AWS bills generated under the unit’s accounts.
•  Acknowledgement of commitment to adhere to Cornell Security and data policies:
  • 5.10 Data Security
  • 5.4.2 Reporting Electronic Security Incidents
  • 4.12 Data Stewardship and Custodianship
  • 4.5 Access to Student Information
•  Name and email address of responsible account holder.
• Accounting code for re-billing
•  Must be Cornell Staff, Faculty or Researcher, Students are not covered under this contract.
• Must agree to have the following turned on in your AWS account:
  • Use of Shibboleth for Authentication
  • Use of DUO (Multi-Factor Authentication) for AWS Console Access
  • AWS Config Activation
  • AWS CloudTrail Activation
  • AWS CloudTrail Logs Sent To ITSO
  • Cloudcheckr Activation

Using the private Direct Connect to AWS

It has been  determined the risks (eavesdropping, session interception, spoofing) to be comparable to the university’s own backbone. That being the case, there’s no policy reason, nor a risk-based reason, to take a different stance on encryption requirements than we do here on campus.

General Recommendations

Encryption

When working in AWS there are many opportunities to encrypt your data at rest and in flight. It many cases in encrypting your data is transparent to your application. You should always encrypt if you can. The following services allow you to encrypt your data at rest with the click of a button:

• S3
• EBS
• RDS
• Redshift
• Storage Gateway

You should always encrypt traffic leaving AWS over the public internet, though it is good practice to always encrypt traffic in flight. When using services like Cloud Front, Elastic Load Balancing, and S3 there are built in facilities for using SSL. When connection to backend services such as databases it is recommended to encrypt that traffic even it if never leaves the VPC or is going over the Direct Connect. For example Oracle has the built in capability to encrypt all data in transit using TLS. Most RDS engines support encryption in flight see the references below for more information.

References:

Using SSL/TLS to encrypt a connection to a DB instance
Server side encryption 
Encryption Overview
Securing Data at Rest with Encryption 
Oracle Database Encryption Options on Amazon RDS