Various Issues Around the Potential Integration of Cloud Vendors and CIT’s Next Generation Data Center.
CIT is in the process of implementing our “Next Generation” datacenter involving plans to abstract out the hardware layer from individual projects instead focusing on providing the computing resources needed to a project independent of specific hardware requirements. This will, in most cases, take the form of a VMWare virtual machine instance provisioned in a blade-based server environment.
This strategy begins to take us in the direction of a “cloud” style of computing where application and service owners are not involved in decisions around what actual hardware their applications and services are running on. It also prepares us to possibly take advantage of supplementing our own resources with commercial resources available from cloud vendors. Such supplementation could take the form of a separate “cloud vendor broker service” where CIT staff manage the acquisition of cloud resources on behalf of campus customers, OR we could integrate our own cloud service with one or more cloud vendors in such a way that customers of our private cloud service may be utilizing resources locally or out on the cloud. This latter paradigm is also referred to as a “hybrid” cloud solution.
Regardless of which model is implemented, a main “benefit” is that local customers need only interface with the local organization thus centralizing the institutional relationship with external cloud vendors. It also affords us the luxury of centralizing decisions made with respect to legal and policy issues that come when one considers hosting institutional data and/or applications in an external environment. In order to be prepared for this, CIT needs to address a multitude of issues in advance instead of trying to find answers to these issues as they come up. We have broken the issues into four main categories:
-
Security issues
-
Data issues
-
Availability issues
-
Contractual issues
Additionally, CIT has well established “best practices” and procedures for managing local physical IT resources. These best practices assume we have complete control of the physical production hardware. In a cloud vendor situation, we may not have as much control as we do with local resources. As such we must also examine the issue of whether or not our current standard practices MUST be executable in a cloud vendor situation OR if we need to amend our current standard practices to deal with the realities of utilizing a cloud vendor (in terms of access to physical hardware)
We’ll examine all of these issues one at a time:
Security Issues
The following issues arise when we consider externally hosted cloud resources that may not allow us access to the logs, hardware settings, etc. we would otherwise have access to when all hardware is local to our environment:
-
Log Issues
-
Is it an issue if we do not have access to logs in the following situations:
-
IaaS – Infrastructure logs?
-
PaaS – Platform AND infrastructure logs?
-
SaaS – Software, Platform AND infrastructure logs?
-
Do we require the ability to perform log-based intrusion detection ?
-
Access
-
Who has access to all parts of the service?
-
Who did what, when? (Audit access)
-
Best Practices
-
Patching--Is the vendor running the most secure versions of the operating system and supporting applications?
-
Configuration—Are vendor’s systems locked down sufficiently?
-
Scanning
-
Do vendors scan their systems themselves?
-
Can we scan our own hosts (hosted in the vendor environment)
-
From Campus?
-
From the Cloud?
-
If vendor scans our hosted systems, do we have access to the results?
-
Intrusion Detection
-
We have appliances that look at network traffic here on campus.
-
If we cannot deploy something similar in the cloud, does the vendor perform their own intrusion detection strategy?
-
What does audit require here?
-
What services require this functionality?
-
If virtual switches are used, can be monitor traffic to detect intrusion?
-
Risk/Vulnerability assessments
-
Who is responsible for this?
-
Sniffing
-
Is network traffic secure from sniffing?
-
Is data storage secure from other tenants?
Data Issues
These issues arise when we consider putting institutional data outside the geographic bounds of Cornell University:
-
Ownership
-
Who owns the data when it is hosted on non-Cornell physical resources?
-
In the case of Google, would our data end up accessible via their search engine?
-
Should Cornell be the sole entity responsible for deciding on whether or not to disclose data to law enforcement agencies based on subpoenas?
-
Encryption
-
Should all data stored on an external vendor’s storage be encrypted?
-
Should all data on the wire be encrypted?
-
NOTE: encryption of data in storage as well as encryption of network traffic is not always done with local systems at Cornell.
-
Key escrow
-
Where encryption occurs, do we escrow encryption key with vendor?
-
If vendor is encrypting do we get copies of the encryption keys?
-
HIPPA/FERPA
-
Must vendors commit to be bound by all HIPPA/FERPA requirements?
-
Extra/Secure Tier
-
Can Confidential data (as defined in Policy 5.10) exist in an external environment?
-
If so, how do we map our security tiers to vendor requirements?
-
Data Destruction
-
What standards of data destruction are required when physical media is taken out of service?
-
What requirements exist for the handling of backup media?
Availability Issues
These issues come up when considering the availability of an externally hosted service:
-
Network
-
What requirements do we have for a vendor’s network availability?
-
Vendor can likely only guarantee availability/performance to a certain point (likely their primary provider).
-
Server
-
Should we limit ourselves to vendors who can guarantee a certain amount of capacity?
-
SLAs/Maintenance Windows/Monitoring
-
Is the vendor obligated to tell us of changes in the system?
-
What type of monitoring/notifications do we require?
-
Disaster Recovery/High Availability
-
What level of DR must the vendor have in place?
-
What level of HA must the vendor have in place?
Contractual Issues
Contractual issues should be the best understood as Cornell has certainly engaged in many contracts with external vendors for IT services independent of any central cloud initiative. The following questions arise:
-
Contracts should be based, whenever possible, on the CSG Model Contract.
-
Vendor contracts should adhere to the guidelines listed in the “Principles of Outsourcing” document.
-
“Brokers” local to Cornell will negotiate contract/service terms based on local client needs.
Share with your friends: |