Shared Services Canada (SSC)

Transcription

1 Shared Services Canada (SSC) Cloud Computing Architecture Identity, Credential & Access Architecture Framework Advisory Committee Transformation, Service Strategy and Design August 29,

2 Agenda TIME TOPICS PRESENTERS 9:00 9:10 Opening Remarks, Objectives & July Meeting Review 9:10 9:15 Cloud Computing: Recap from July AFAC meeting B. Long, Chair W. Daley, Vice-Chair B. Long 9:15 9:40 Cloud Computing Architecture J. Danek 9:40 10:20 Round Table All 10:20 10:30 Health Break 10:30 11:00 Identity, Credential & Access 11:00 11:45 Round Table All R. Thuppal 11:45 12:00 Closing Remarks Chair 2

3 Shared Services Canada Enterprise Architecture Cloud Computing Architecture AFAC Meeting 2 August 29, 2013 Jirka Danek DG Enterprise Architecture 3

4 SSC High Level Requirements Application mobility between private, public and hybrid cloud environments Ability to manage, orchestrate, administrate, and provision from a single open interoperable architectural framework Ability to provide an environment for open competition and level playing field among vendors To ensure on-going competition (not just at contract award) low cost / high value to the Crown over the contract life Agility to have flexibility in the architecture that will allow for scale both from a capacity perspective and with respect to change in technology directions driven by our requirements and marketplace opportunities 4

5 GC Cloud Orchestration Architecture v1 Portal and Self Service Catalogue Multi-Cloud Services (Orchestration, Governance, Financial Control, Brokering, ICAM, Reporting) GC Hybrid Cloud Services GC Public Cloud Services Service, Security, Savings Agility & Mobility GC Community Cloud Services 5

6 July AFAC Cloud Computing Feedback OpenStack was considered by some as not mature enough at this time OpenStack was seen as a potential option for open cloud interoperability, however, it was noted that there are very few significant production implementations at this time It was observed that OpenStack is just one of a number of cloud open standards bodies, and no clear winner has emerged at this time OpenStack is complex and implementation skills are not readily available Fail fast test it and try application mobility in small initial iterations Some AFAC members suggested the cost of the systems integration work for OpenStack would out-weigh the benefit of application mobility Some participants felt that OpenStack would be good for selective non-mission critical workloads Others felt that OpenStack would be good as a long term strategy, but shouldn t be the only plank in SSC s approach to cloud interoperability Did we hear you correctly?? 6

7 SSC DC Challenge Sample Win/Lintel Only Cloud Computing Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Mgmt. Compute Compute Compute Compute OS OS OS OS Hypervisor Hypervisor Hypervisor Hypervisor Hardware Hardware Hardware Hardware 7

8 SSC DC Challenge Sample Win/Lintel Only Cloud Computing VCE FlexPod vstart PureFlex CloudSystem HItachi Integrated Mgmt. Integrated Mgmt. Integrated Mgmt. Integrated Mgmt. Integrated Mgmt. Integrated Mgmt. Integrated Infrastructure Systems Compute OS Compute OS Compute OS Compute OS Compute OS Compute OS Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor 8

9 SSC DC Challenge Sample Win/Lintel Only Cloud Computing IBM PureApplication HP AppSystem Oracle Exadata Integrated Application Systems Integrated Mgmt. Compute OS Integrated Mgmt. Compute OS Integrated Mgmt. Compute OS Hypervisor Hypervisor Hypervisor DBMS 9

10 Roadmap of Cloud-based Services Multi-Services, Service Providers and Service Layers Private, Public and Hybrid Cloud Environments Roadmap includes: Enterprise HR Service Enterprise Finance Service Enterprise Document Service Enterprise Web Hosting Service GCNet Services Unified Communications Services Enterprise Data Centre IaaS and PaaS Services Partner-based SaaS implementations (except ETI) 10

11 The Emerging Broker Role Cloud Broker Roles 1. Service Intermediation Enhances via value-added services 2. Service Aggregation Cloud services integration from multiple CSPs 3. Service Arbitrage Managing capacity dynamically, or managing service across a number of providers to meet, for example, SLA or optimum cost metrics. NIST Cloud Reference Architecture: 11

12 Broker Use Cases 1. of New Hires: A new government employee joins the government. Their HR information is with Cloud Service Provider #1 (CSP #1) and their financial information and pay systems are with CSP #2. Their is with CSP #3. How does SSC orchestrate interoperability among the systems? What is a broker role? How do we manage ICAM, and directory services? How do we manage custom interoperability? 2. Fail Over and DR: SSC implements a mission critical application internally and wishes to fail over based on capacity thresholds to a hybrid cloud or public cloud provider. 3. Dynamic Allocation: SSC implements an IaaS service for a government web site that is anticipating dramatic changes in capacity that cannot be estimated. Can we implement a pool of cloud providers and allocate workloads based on price or capacity thresholds? 12

13 Questions 1. How do we architect to effectively manage the future state environment? 2. Do we architect for separate management and orchestration systems and processes for each service? 3. Are there mature enterprise reference architecture models that bridge SaaS to PaaS from different service providers? 4. How do we ensure vendor neutrality in this kind of situation? 5. How should we architect to manage cloud sprawl? 13

14 Shared Services Canada Enterprise Architecture Identity, Credential & Access AFAC Meeting 2 August 29, 2013 Raj Thuppal DG Cyber & IT Security Transformation 14

15 Purpose Present GC ICAM proposed plan and Early Releases Seek feedback and input Questions/Discussion 15

16 July 2013 AFAC ICAM Feedback Build in increments according to need and priorities make it as simple as possible Have very clear business goals Make it something attractive that users want to get Scaling to a new identity might be a challenge incrementally connect the islands and migrate from the islands to a consolidated approach Consider all open standards, protocols (e.g. SAML and others) Awareness one of the costs impacts of ICAM is the admin of credentials: Consolidate credentials Be cost effective Bring as much capability as possible to Help Desk (SSC & Partner) Work on the security posture Privacy by Design some provinces have some of the best privacy practices Did we hear you correctly?? 16

17 IT Security Transformation (Draft) IT Security Current State Dept Dept Dept IT Security Target State GCNet Multiple Identities Multiple Identities Multiple Identities Multiple Credentials Single Identity Unified Credential Data in Transit Back office Back office Apps Apps Multiple Multiple Access Access Controls Controls Data in Processing Data at Rest Mission Mission Specific Specific Apps Apps DEFENCE IN DEPTH Consolidated Consolidated Back office Back office Apps Apps Centralized Access Data at Controls Rest Data in Data at Transit Rest Data in Processing Mission Mission Mission Specific Mission Specific Specific Apps Specific Apps Apps Apps Focus on network, perimeter protection and network authentication Focus on data, through layers of protection, separation and active detection Transformation from multiple network domains to single GC domain requires shift from network based security to identity and data based security. 17

18 ICAM Challenges and Requirements DRIVERS Increase Security Improve Service Generate Savings CHALLENGES Lack of comprehensive access controls and management of admin privileges, and dormant accounts Limited GC policy and standards enforcement capability Lack of single GC identity repository Partner specific ICAM, difficult to implement GC wide services Hard coded dependency on ICAM solutions inhibits service evolution Duplication and fragmented technologies, processes and service management Lack of GC wide capability forces application specific ICAM solutions (ex: ETI) SSC Initiatives Blackberry 10 GC-Wifi GCNet GC converged communications GC Secret infrastructure Data centre consolidation Workplace technology devices TBS Initiatives HR Web Fin GCDocs Mobility EMERGING REQUIREMENTS 18

19 GC ICAM Scope (Proposed) Scope: A Government of Canada solution Internal GC workers (e.g. employees, contractors, agents of the Crown, integrees, trusted guests, retirees) and non-person entities (e.g. devices, applications) Logical (IT systems/applications) and physical (building) access management Designated (to Protected B*) and Classified (to Secret) identities, credentials and resources will be managed Current ICAM-related processes and technologies will be transformed to the new ICAM solution, and new ones will be created as needed Out-of-Scope: Individuals and businesses external to the Government of Canada *Note: Protected C requirements are handled as part of the Classified environment 19

20 GC ICAM Schedule (Proposed) Current State Inventory of infrastructure and systems Lessons learned Requirements Partner and enterprise requirements End State Plan and Procure End-state architecture and design Service strategy, design, delivery model Business case(s) Consolidation and transformation roadmap Implementation plan Detailed Plans Implement Rn Program : Project, Reporting, Communications, Governance, Stakeholder Engagement, Finance ( ) Implement Rn ( ) Implement Future State ( ) 2013 Sept Jun Sep. Dec. Apr

21 Current State Identity Credential Requirements and Support to Transformation Programs (e.g., , Data Centre ) Access PWGSC Industrial Security Program Workers Security Clearance Attributes Transformation Initiative Employee Attributes ETI Onboarding HR Applications (43 Partners ++) Employees Attributes GEDS Employee Attributes mykey ICM Service Person PKI Key & Onboarding PKI Directory services Departments (DND, RCMP, CRA) Person PKI Key PKI Directory services Others (e.g. SSL ) Line of Business Applications Embedded credential Departments tools and policies Secure Remote Access Departments Facilities PenMod Employee Attributes 21

22 Opportunities TBS back office application modernisation initiatives (HR, Fin, Web, GCDocs) IT service specific ICAM solutions are being designed due to lack of GC wide solution (Ex: ETI), there is an urgent need for a GC ICAM solution (SSC and TBS led initiatives) Internal credential management system is already a GC wide service that could be transformed (open standards, consolidation, decouple from applications etc..) to end state service relatively quickly ETI directory could be leveraged to populate GC ICAM AFAC, industry feedback and previous GC attempts recommend building in increments according to need and priorities and make it as simple as possible 22

23 GC ICAM Schedule (Proposed) Current State Inventory of infrastructure and systems Lessons learned Requirements Partner and enterprise requirements End State End-state architecture and design Service strategy, design, delivery model Tactical Plan Plan and Procure Detailed Plans Business case(s) Consolidation and transformation roadmap Implementation plan Implement Rn Program : Project, Reporting, Communications, Governance, Stakeholder Engagement, Finance ( ) Implement Rn ( ) Implement Future State ( ) 2013 Sept Jun Sep. Dec. Apr

24 ICAM Transformation Strategy Policies Analysis, Access IOS ICAM Directory Policies Process Governance Technology Policies Process Governance Technology July 2013 Dec Jan Dec GC ICAM Program Release 1 ICAM: Identity : Attributes Authoritative Sources Onboarding process Identity Manager Release 2: Identity Credential Access Release...: Identity Credential Access Credential : Applications Authentication (UserID/Pw or mykey) PKI Transformation Access : PiV cards for SSC Simple Sign-On 24

25 GC ICAM Release 1 (Proposed) Principles Avoid development of application specific ICAM services Leverage existing enterprise ICAM services (ETI, ICMS etc..) Adopt open standards Focus on foundation elements that paves way for future GC ICAM Consolidate identities Scope Identity Identify attributes and their authoritative sources Build GC ICAM directory leveraging ETI directory services and other sources Establish GC identity manager that hosts user identities and passwords Credential Transform GC-ICMS and other PKI services Application authentication/decoupling (e.g. using SAML) Access Building access card standard and pilot Web application simple sign-on 25

26 New GC ICAM Service Release 1 - Draft Identity PWGSC Industrial Security Program Workers Security Clearance Attributes Transformation Initiative Employee Attributes ETI Onboarding HR Applications (43 Partners ++) Employees Attributes GEDS Employee Attributes PenMod Employee Attributes Credential Requirements and Support to Transformation Programs and TBS Initiatives (e.g. HR, WEB, Fin, GCDOCS,, , Data Centre ) mykey ICM Service Person PKI Key & Onboarding PKI Directory services Departments (DND, RCMP, CRA) Person PKI Key PKI Directory services Others (e.g. SSL ) Line of Business Applications Embedded credential Access Departments tools and policies Secure Remote Access Departments Facilities New Enterprise Service Identity : Attributes Authoritative Sources Onboarding process Identity Manager Credential : Applications Authentication (UserID/Pw or mykey) PKI Transformation Access : PiV cards for SSC Simple Sign-On 26

27 Questions - Engaging Discussion For the GC ICAM: 1. Is proposed Release 1 scope sufficient to establish critical foundation for GC ICAM? 2. Should the strategy for internal ICAM be federated or non-federated? 3. Should the strategy for ICAM authoritative sources be federated or nonfederated? 27