1. JASMIN and CEMS: The Need for Secure Data Access in a Virtual Environment Cloud Workshop 23 July 2013 Philip Kershaw Centre for Environmental Data Archival RAL Space, STFC Rutherford Appleton Laboratory

2. Introduction JASMIN and CEMS background – Current phase 1 deployment – Plans for phase 2 Security Requirements Access Control and Federated Identity Management Cloud and Confidentiality Cloud and SLAs LST plot for the UK [John Remedios and Darren Ghent, University of Leicester].

3. JASMIN Phase 1 e-Infrastructure investment (NERC and UKSA) 6PB fast disk (Panasas) via low latency networks Distributed: RAL, Leeds, Bristol, Reading for Climate Science and Earth Observation (CEMS) communities Compute cluster, virtualisation (VMware) and private cloud (vCloud)

4. External Cloud Provider s JASMIN 2 and 3 Virtualisation Cloud Federation API Internal Private Cloud JASMIN / CEMS Academic [R89 Building STFC Rutherford Appleton Laboratory] Direct access to the data archive - Hosted processing and analysis environments NERC Environmental Big Data investment (2 internal phases) JASMIN for use by entire NERC community Expand to 12PB fast disk + 1000s cores Provided a range of service models Batch compute Virtualisation Cloud Private Cloud with capability to federate with public clouds Private cloud will be a host for virtual platforms Dynamically configured infrastructure to enable switching of storage and compute between private cloud and archive Isolated part of the network Cloud burst as demand requires Panasas Storage Bare Metal Compute Data Archive and compute

5. Evolving Security Requirements CEDA changing from a data provider to a data provider and hosting service Communities – JASMIN 1 + CEMS: Data for the Atmospheric Science and Earth Observation research communities – JASMIN 2 private cloud will serve wider NERC community Requirements 1.Enforcement of licence agreements, terms of use, embargo periods or limited distributions 2.User privacy – Data Protection Act 3.Protection of computing resources is the critical consideration Increasing importance with the provision of user hosting environments To prevent, – Loss of service of for extended period – Detrimental impact on science – Knock-on effect of reputational loss

6. Interfaces Interfaces – critical consideration as they mark out security boundaries Interfaces changing and evolving with new service models: virtualisation, cloud, …

7. Interfaces and Usage Patterns vs. Hosting Solutions High performance file system Hosted Processing Hosted Infrastructure PaaS – Hosted Analysis Environments Increasing virtualisation => Cloud platform Direct Access to the File System Sandboxed environments Service Offered Cloud Federation / Brokering Virtualisation and networking Virtual Storage Application Hosting Bare metal SOA Isolated network Increased set-up time, but longer usage Lower level of trust in user => <= Increased level of trust in user Users and usage More dynamic and autonomous usage patterns Great security risk usage patterns Shared Scientific Analysis hosts Virtual Infrastructures for other organisations

8. Access Control and Federated Identity Management RBAC (Role-Based Access Control) in place for many years FIM required for international collaborations

9. Earth System Grid Federation Security ESGF, a globally distributed federation of nodes initially deployed in support of CMIP5 Requirements: – Access control for enforcement of licence agreements and terms of use – Single sign-on (SSO) – Authorisation overseen by PCMDI, lead organisation Solution: – SSO: OpenID for browser-based access, SLCS (Short-Lived Credential Service - X.509) for command line wget and other clients (NetCDF) and GridFTP – SAML for attribute query and authorisation interfaces – RBAC with virtual Organisation(s) to managing access roles – RESTful authorisation policy Also adopted for CEDA’s infrastructure

10. Access Control and FIM for Clouds Build on work for ESGF – But ESGF designed for federated access to datasets – Low LoA required (Level of Assurance) for credentials New work with Contrail project to address some challenging use cases...

11. Contrail Project Goals EC FP7 Project, led by INRIA, 36 month+, completes Jan 2014 Federation of cloud providers Federation with external IdPs Elastic CAs for dynamically created services Autonomous SLA management (SLA@SOI) IaaS and PaaS integration Reuse of existing open standards: –OVF, OCCI, CDMI –WS-Security, SLA@SOI models...

12. Contrail – Delegation with OAuth 12 Cloud Providers Federation CLI Browser Federation Web Portal Federation core Online CA Service Federation Identity Provider  REST API  Multiple delegation hops Cloud credential mapping OAuth Contrail Federation Layer OAuth Authz Server External IdPs – Shib, OpenID

13. Confidentiality Homomorphic encryption – Homomorphic Encryption: Theory & Application, Jaydip Sen, Department of Computer Science, National Institute of Science & Technology Odisha, INDIA Divide data into chunks and distribute across multiple providers Only the owner can re-assemble the data No single provider can re-assemble the data Computationally expensive ESA Project DCGO (Data Chunks to Go) exploring this technology Other commercial solutions

14. SLAs and Security Lack of standardisation and relative immaturity are problems Contrail project Extends work of SLA@SOI project – Support for expressing SLAs at the level of individual resources by linking to OVF (Open Virtualisation Format) descriptors Federated negotiation with multiple providers and the selection of the optimum SLA offer according to user criteria Quality of Protection (QoP) terms, such as data locality, protection, replication, …

15. External Cloud Provider s Security, Cloud and Network Isolation Virtualisation Cloud Federation API Internal Private Cloud JASMIN / CEMS Academic [R89 Building STFC Rutherford Appleton Laboratory] Direct access to the data archive - Hosted processing and analysis environments 3 interfaces Private archive Private cloud Public cloud (via broker) Private archive and private cloud in independent networks but co-located key interfaces link between the two e.g. data download OPeNDAP Dynamically configured infrastructure to enable switching of storage and compute between private cloud and archive Isolated part of the network Cloud burst as demand requires Panasas Storage Bare Metal Compute Data Archive and compute

16. Conclusions Existing climate science and earth observation security requirements understood Strong foundation of access control and FIM to build on – Need to consider LoA for new use cases New user communities within NERC to consider New challenges with requirements to protect computing resources, new interfaces (attack vectors!) Confidentiality and SLAs – Areas where much more work is needed Network isolation baseline for private cloud Clarity and clear demarcation needed for hybrid cloud (cloud federation)