|
|
| Line 27: |
Line 27: |
| | | | |
| | </div></div> | | </div></div> |
| − | {{TOCright}} | + | {{Delete|reason=Expired Content}} |
| − | | |
| − | | |
| − | == Overview and Current Situation in Government of Canada ==
| |
| − | Cloud computing has made the jump from buzzword to deployed technology. However, many potential cloud customers do not understand the scope of the cloud, how it should be used, and how to address security in the cloud. The image below is a simplified view of an enterprise such as the GC. The goal of the organization is to provide needed services to the citizens of Canada and other public users as well as internal services to allow GC employees and contractors to keep the business of the GC running. Service delivery is the ultimate goal, but there are several foundational elements provided by the people, processes, and technology of the GC. The technical contribution to the foundation is contained in information technology and information systems (IT/IS). As shown in the image on the left, cloud computing is simply an enabling information technology supporting the mission of the business of the enterprise.
| |
| − | [[File:Cloud Computing Enables the Business of the GC.PNG|left|thumb|444x444px|Cloud Computing Enables the Business of the GC]]
| |
| − | The GC IT/IS enterprise is large in scope and geography, yielding a challenging operational, maintenance, and security environment. GC users hail from 400,000+ federal government employees and 100,000+ federal government business enterprise employees. Canada's population is 35 million, representing the pool of potential Canadian citizen public users. GC resources are also accessed by non-Canadian public users, including international visitors to GC sites. The hundreds of GC agencies and departments are spread across the country and around the world, each with independent policies, assets, and resultant security postures.
| |
| − | | |
| − | Currently, the GC operates 480+ data centres attached to thousands of stove-piped networks running unique instances of front-office and back-office applications. These data centres consist of purpose built servers racked for each application, resulting in low hardware utilization rates (i.e. 15% or less), long lead times for provisioning (i.e. weeks to months), sub-optimal use of data centre space, power and cooling, and high recurring costs.
| |
| − | | |
| − | Current use of cloud computing is department-based, deployed internally in department-hosted private data centres and clouds for processing sensitive information and contracted with cloud providers for unclassified and public information sites. This distributed, department-led IT procurement and deployment model leads to a number of enterprise level issues, including: inconsistent application and adoption of new technologies and business processes, standards, and open systems; a lack of ability to adapt to the changing threat environment while increasing the threat surface faster than security mitigations are deployed; incomplete network and element awareness and mapping; independently owned and operated legacy applications (5000+) and associated data and information stores, many without a path to a consolidated infrastructure and modern security protections; limited inter-domain interoperability and inadequate information sharing and access between agencies, departments, and partners. All of these effects perpetuating the expensive, inefficient, and insecure aspects of the current enterprise.
| |
| − | | |
| − | A contributing aspect to the low penetration of low-cost, high performance solutions enabled by cloud computing is the slow uptake of cloud technology in Canada as a whole. In a white paper published by IT World Canada, the perspective of Canadian CIOs on cloud computing was described as follows:<blockquote>''"Their posture towards the cloud, in other words, could not be more Canadian: optimistic but pragmatic, slow but deliberate, purposeful but not aggressive."''</blockquote>In addition to worries about security and reliability, several additional factors contribute to the slow uptake, including data and information security and the protection of personal privacy, loss of control, expected cost and effort to convert to cloud computing, lack of a clear return on investment, change to a different management and contracting paradigm, data and information sovereignty requirements, ramification from the Personal Information and Electronic Documents Acts (PIPEDA) and the US Patriot Act, lack of open cloud and cyber security standards, concerns with vendor lock-in, lack of suitable bandwidth, and the desire to try the technology first or see solid proof of cost savings from other with trusted vendors before deploying to the greater enterprise.
| |
| − | | |
| − | The measured rate of adoption places Canada 9th out of 24 countries considered part of the cloud global economy, up from 12th in 2012. Several efforts are pushing Canada toward the cloud. GC's Cloud First campaign is an effort to hasten the adoption of cloud computing in the GC. The Canadian Cloud Council was formed to help push the adoption and thought leadership of Canada in the global cloud economy. Large cloud service providers, such as Amazon, are moving to Canada as the country's appetite for cloud services increases. The ultimate measure of success is the establishment of cloud computing offerings within Canada and subsequent increase in adoption rates by Canadian businesses and governments.
| |
| − | | |
| − | With responsibility for processing and storing large amounts of sensitive data/information (e.g. classified, protected, private), the GC needs to minimize the risk of unauthorized disclosure of data. Adoption of cloud technology provides a wrinkle in the current approach to information security since portions of the information system are out of the direct control of the GC and the department charged with protecting sensitive GC information.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Why Cloud Computing? ==
| |
| − | Why is cloud technology adoption gaining momentum in the GC? The GC has several imperatives directly supported by the characteristics of cloud computing. The GC Cloud First campaign is a move to lower recurring costs associated with IT/IS infrastructure through the consolidation of IT/IS assets and the associated trained IT personnel by mandating cloud technology as part of the investment planning decision process. In addition to lowering IT/IS costs, cloud computing streamlines service delivery with a robust, failure tolerant foundation enabling the rapid addition of features and functionality. A challenge with the adoption of the cloud is maintaining the security of information processed and stored in the cloud environment.
| |
| − | | |
| − | The image below maps GC desires to the key characteristics of cloud computing: on-demand self service, broad network access, resource pooling, rapid elasticity, and measured service:
| |
| − | | |
| − | <br>
| |
| − | | |
| − | [[File:Why Cloud Computing..PNG|centre|thumb|770x770px|Why Cloud Computing?]]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | === ''Savings'' ===
| |
| − | The immediate benefit to cloud computing is that consolidating resources in fewer data centres results in reduced facility, personnel, and training costs. What makes cloud computing different from traditional consolidation are the characteristics of resource pooling and rapid elasticity that allow the system to handle peak loads without excess over-capacity. Without resource pooling, each server or network device must have enough power to handle the peak load of applications and users assigned to it. With resource pooling, additional resources can be dynamically acquired when needed, and disposed of when no longer needed (rapid elasticity). these concepts can be applied to processor time, memory, network bandwidth, and potentially other resources where demand expands and contracts over time. Resource pooling and rapid elasticity works best when different peak loads occur at different times. Resource pooling and rapid elasticity are usually enabled through the use of virtualization technologies.
| |
| − | | |
| − | === ''Service'' ===
| |
| − | All the essential cloud characteristics play a role in providing high performance and high availability services to end users. Given an appropriate mix of applications and users, resource pooling and rapid elasticity ensure acceptable performance by dynamically acquiring additional resources when required. Resource pooling and rapid elasticity may also allow services to be synchronized and rapidly reassigned in case of a hardware failure. On-demand self-service and broad network access ensure availability. Measured service allows performance and availability to be measured and improvements made as necessary.
| |
| − | | |
| − | === ''Security'' ===
| |
| − | The essential cloud characteristics do not directly address security and the cost-saving benefits of cloud computing often overshadow security concerns. Given the additional risk factors, the security of a cloud service cannot reasonably be expected to be more secure than a well-designed and well-managed in-house private enclave, but the level of security should not be significantly less. This is particularly an issue when using commercial cloud providers that have Internet connectivity, may pool resources with other (potentially hostile) customers in a multi-tenant environment, and may not perform adequate vetting of employees. A strong Security Assessment & Authorization (SA&A) certification and continuous monitoring program is essential to ensure that adequate security controls are in place and remain effective throughout the life of the service. A measured service capability that provides customers with real-time and on-demand insights into the security posture of the cloud service (not just the performance of the cloud service, although this is also important) is a key consideration when evaluating cloud service offerings.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Cloud Computing Defined ==
| |
| − | As cloud exited the realm of concept and hyperbole and became widely available for commercial and government markets, several efforts emerged to standardize the notion of cloud computing and guide the industry toward the adoption of open standards.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information about this, please read the following sections which can be expanded by clicking on 'Expand' on the far right.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''Cloud Standardization Efforts''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Cloud Standardization Efforts}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''NIST Definition of Cloud Computing''' <div class="mw-collapsible-content">
| |
| − | ---- {{:NIST Definition of Cloud Computing}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''Extensions to NIST Definitions''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Extensions to NIST Definitions}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''Evolving Definitions of Cloud Computing''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Evolving Definitions of Cloud Computing}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''What Is Not Cloud Computing''' <div class="mw-collapsible-content">
| |
| − | ---- {{:What Is Not Cloud Computing}} </div></div>
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Security Ramifications of Cloud Computing ==
| |
| − | Cloud computing is an intriguing technology for low cost, high performance IT/IS solutions. However, security remains one of the biggest hurdles to large scale adoption for potential consumers of cloud services like the GC.
| |
| − | | |
| − | The Cloud Security Alliance (CSA) tracks top threats to cloud computing. These threats are summarized in the CSA's The Notorious Nine Cloud Computing Top Threats in 2013. The nine critical threats to cloud security, ranked in order to severity are shown in the table below.
| |
| − | | |
| − | {| class="wikitable"
| |
| − | | style="background: #000000; color: #ffffff | '''Priority'''
| |
| − | | style="background: #000000; color: #ffffff | '''Cloud Threat'''
| |
| − | | style="background: #000000; color: #ffffff | '''Aspects of the Cloud Threat'''
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''1'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Data Breaches'''
| |
| − | |Data leakage or unauthorized access and exfiltration of sensitive data or information
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''2'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Data Loss'''
| |
| − | |Permanently destroyed data due to malicious, accidental, or natural events
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''3'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Account Hijacking'''
| |
| − | |Eavesdropping, modifying information, redirecting clients to illegitimate sites, and using account to attack others
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''4'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Insecure APIs'''
| |
| − | |Broad array of ill effects from associated policy violations and abuse
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''5'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Denial of Service'''
| |
| − | |Lost business, increased usage charges, and damage to reputation due to service outage
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''6'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Malicious Insiders'''
| |
| − | |Intentional misuse of access privileges to compromise confidentiality, integrity, or availability of cloud-based information or services
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''7'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Abuse of Cloud Services'''
| |
| − | |Use of power of cloud computing for nefarious purposes
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''8'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Insufficient Due Diligence'''
| |
| − | |Increased risk due to lack of understanding of cloud service provider's contract clauses, SLA, operations and security posture
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''9'''
| |
| − | | style="background: #e5e5e5; color: #000000 | '''Shared Technology Issues'''
| |
| − | |Risks of sharing infrastructure with other entities (i.e. multi-tenancy)
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | | |
| − | A recent report from ETSI's Cloud Standards Coordination Initiative addresses security considerations of moving to the cloud, citing the transfer of data and application responsibility from the consumer to the cloud service provider (CSP) and the multi-tenant, shared resource environment of the CSP as the key sources of the security risk. The table below lists ETSI's cited risks and challenges associated with a cloud computing service.<br>
| |
| − | | |
| − | {| class="wikitable"
| |
| − | | style="background: #000000; color: #ffffff | '''Typical Risks and Challenges'''
| |
| − | |-
| |
| − | |Availability of services and/or data and information
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Lack of data or information classification mechanisms
| |
| − | |-
| |
| − | |Integrity of services and/or data and information
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Confidentiality concerns
| |
| − | |-
| |
| − | |Cost and difficult of migration to the cloud (legacy software, etc.)
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Vendor lock-in
| |
| − | |-
| |
| − | |Repudiability and lack of forensic capability
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Loss of control of services and/or data and information
| |
| − | |-
| |
| − | |Responsibility ambiguity
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Lack of liability of providers in case of security incidents | |
| − | |-
| |
| − | |Regulatory compliance
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | | |
| − | In addition to these risks and concerns, ETSI's report specifies several key issues requiring attention in the standards community indicated in the table below.
| |
| − | | |
| − | {| class="wikitable"
| |
| − | | style="background: #000000; color: #ffffff | '''Gaps and Issues with Current Cloud Standards'''
| |
| − | |-
| |
| − | |Cross-border legal issues, including variation in data and information protection regulations
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Conflict of interest between customers and national security of the hosting country
| |
| − | |-
| |
| − | |Visibility and transparency
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Assurance and trust
| |
| − | |-
| |
| − | |Certification, audit, and testing
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Identity and access management
| |
| − | |-
| |
| − | |Provider use of the services of other providers
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Virtualization and multi-tenancy risks
| |
| − | |-
| |
| − | |Data and information location control
| |
| − | |-
| |
| − | | style="background: #e5e5e5; color: #000000 | Secure data and information deletion and the exit process
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | | |
| − | The themes throughout the ETSI and CSA reports make it clear that cloud services must be vetted, agreement thoroughly reviewed, management and responsibility clearly delineated, and security controls properly implemented and audited. The adoption of cloud services requires a rigorous decision process prior to adoption to make sure the deployment of services into any particular cloud environment is appropriate based on the sensitivity and rules for handling data and information.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Current Situation for Cloud Security ==
| |
| − | The image below shows the current GC enterprise IT/IS infrastructure as consisting of multiple interconnected networks and associated information systems (domains) belonging to different organizations for different purposes. There is little to no centralization, with each domain network connecting to other domain networks via one or more perimeters. There are also multiple Public Access Zones (PAZs) that provide connectivity to the Internet. For a description of the architecture components in the image below, please read the GC Enterprise Architectural Components section of the [[Media:GC ESA Definition Document (ESADD) - Main Body.pdf|GC ESA Description Document Main Body]] document. For information on additional architectural elements, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | [[File:GC Notional Current Enterprise Security Architecture.PNG|centre|thumb|792x792px|GC Notional Current Enterprise Security Architecture]]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | With the creation of Shared Services Canada (SSC) in 2011, an initial goal was to reduce the number of networks and PAZs through consolidation and sharing. Consolidation of over 3,000 overlapping and uncoordinated networks is being performed as part of the GCNet program. For more information on architectural approaches to network consolidation, see the [[Media:GC ESA Definition Document (ESADD) - ANNEX C NCS.pdf|GC ESA Description Document Annex C: Network and Communications Security]] document.
| |
| − | | |
| − | Following the announcement of the Cloud First strategy, SSC has begun planning the deployment of cloud services, initially focused on providing cloud-based email and remote desktop services. It is unclear at present whether SSC plans to act as a Could Provider, Cloud Broker, or both. SSC will act as the Cloud Carrier using GCNet as a common network that enables internal (inter-department) and external communications.
| |
| − | | |
| − | Some GC departments may already be using commercial cloud services, the security of which may be suspect given the current lack of cloud deployment policy and a Security Assessment & Authorization (SA&A) process with no centralized oversight.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Operational States ==
| |
| − | [[File:GC Secure Cloud Current Operational States.PNG|thumb|443x443px|GC Secure Cloud Current Operational States]]
| |
| − | This section defines the operational states based on assumptions about the current implementation of cloud computing within the GC.
| |
| − | | |
| − | The Information Technology Infrastructure Library (ITIL) security management process defines a number of sub-processes. These sub-processes have been mapped to cloud operational states as shown by the colour-coded annotation in the image on the right.
| |
| − | # '''''Control:''''' The Control sub-process organizes and manages the security management process itself. The Control sub-process defines the processes, the allocation of responsibility for the policy statements and the management framework.
| |
| − | # '''''Plan:''''' The Plan sub-process contains activities that in cooperation with the Service Level Management lead to the (information) Security section in the SLA. Furthermore, the Plan sub-process contains activities that are related to the underpinning contracts which are specific for (information) security.
| |
| − | # '''''Implementation:''''' The Implementation sub-process makes sure that all measures, as specified in the plans, are properly implemented. During the Implementation sub-process, no (new) measures are defined nor changed. The definition or change of measures will take place in the Plan sub-process in cooperation with the Change Management Process.
| |
| − | # '''''Evaluation:''''' The evaluation of the implementation and the plans is very important. The evaluation is necessary to measure the success of the implementation and the Security plans.
| |
| − | # '''''Maintenance:''''' It is necessary for the security to be maintained. Because of changes in the IT-infrastructure and changes in the organization itself, security risks are bound to change over time.
| |
| − | The Control and Evaluation ITIL phases are omitted from the image on the right to reflect the lack of existing policy instruments that address acquisition, deployment, and maintenance of cloud service, and the lack of a well-defined Security Assessment & Authorizations (SA&A) process.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Justification For and Nature of Changes ==
| |
| − | | |
| − | === ''Justification for Changes'' ===
| |
| − | The GC is undergoing a transformation of its information systems with the goals of:
| |
| − | # Achieving cost savings
| |
| − | # Providing better service to GC users and Canadian citizens
| |
| − | # Improving security
| |
| − | The transformation began in 2009 and has already achieved a number of significant milestones. The last key element of the transformation is the creation of the Cloud First initiative. This will drive the consolidation of a large number of data centres to a significantly smaller number, leading to fewer facilities, fewer information systems (servers and networking hardware components). and less effort to monitor, manage, and maintain facilities and information systems. Consolidation of information systems also allows computing power and network bandwidth to be dynamically reallocated to handle peak demands in different areas of the GC enterprise that occur throughout the day.
| |
| − | | |
| − | The GC is also working to have better understanding of its entire application portfolio through Application Portfolio Management (APM). The goal of APM is to eliminate development of duplicate or similar applications by multiple departments. The consolidation of computing resources within the cloud will help identify and reduce duplication.
| |
| − | | |
| − | === ''Description of Desired Changes'' ===
| |
| − | Shared Services Canada (SSC) has identified the end state of cloud computing to be:
| |
| − | | |
| − | '''Consolidation Principles:'''
| |
| − | # As few data centres as possible,
| |
| − | # Locations determined objectively for the long term,
| |
| − | # Several levels of resiliency and availability,
| |
| − | # Scalable and flexible infrastructure,
| |
| − | # Infrastructure transformed, not "fork-lifted" from old to new,
| |
| − | # Separate application development environment,
| |
| − | # Standard platforms which meet common requirements, and
| |
| − | # Build in security from the beginning, as reflected in SSC's "security by design" motto.
| |
| − | '''Business Intent:'''
| |
| − | # Business to Government,
| |
| − | # Government to Government, and
| |
| − | # Citizens to Government.
| |
| − | '''Enterprise Security:'''
| |
| − | # All departments share one logical Operational Zone (network consolidation),
| |
| − | # Domains and zones where required,
| |
| − | # Classified information below Top Secret,
| |
| − | # Balanced security and consolidation,
| |
| − | # Consolidated, controlled, secure perimeters, and
| |
| − | # Certified and accredited infrastructure,
| |
| − | '''Service Management:'''
| |
| − | # Information Technology Infrastructure Library (ITIL) Information Technology Service Management (ITSM) Framework,
| |
| − | # Standardized service levels/availability levels,
| |
| − | # Inclusive of scientific and special purpose computing,
| |
| − | # Standardized application and infrastructure lifecycle management,
| |
| − | # Smart evergreening, and
| |
| − | # Full redundancy - within data centres, between pairs, across sites.
| |
| − | A specific set of operation actions, technical features, and their relative priorities are listed in the next section.
| |
| − | | |
| − | === ''Assumptions and Constraints'' ===
| |
| − | '''Assumptions:'''
| |
| − | * GC will implement and procure cloud solutions and services,
| |
| − | * Threats continue to prove GC systems to attempt to exfiltrated protected information. Attack surface increases to include cloud vendors,
| |
| − | * Threats are external and internal,
| |
| − | * Technology will evolve to support enterprise-wide information-centric security, and
| |
| − | * Not all systems and functions are collapsible to the cloud; the notion of standalone enclaves will persist for high-value, specialized functions.
| |
| − | '''Constraints:'''
| |
| − | * Cost-effective rollout required,
| |
| − | * Leverage legacy investments where possible,
| |
| − | * Phased incorporation of cloud services and technology, and
| |
| − | * Many existing applications are not deployable to the cloud.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Summary of Impacts ==
| |
| − | The GC business model allows for feedback from Departments and adjustments to the implementation plan.
| |
| − | * '''''Planning and Implementation:''''' GC IT Architecture Review Board (GC ITARB) provides a forum for assessing architectural changes throughout an IT-enabled project lifecycle.
| |
| − | * '''''Operation:''''' Risk management activities are required to fully vet deployment of new capabilities and assess community risk of moving functions to cloud infrastructure.
| |
| − | | |
| − | === ''Operational Impacts'' ===
| |
| − | Users are already familiar with the transition away from local application services to web-based remote "application-on-demand" services and should therefore see no significant differences as these remote application services are moved to a cloud environment.
| |
| − | | |
| − | In the case of PaaS, end users may be required to migrate from local thick clients (e.g. a conventional desktop or laptop computer) to thin clients that access remote desktop services in a cloud. This transition may have more of a visible impact than SaaS in that network access will become a requirement to obtain any application service. Thin clients may also have a different form-factor to familiar desktops and laptops.
| |
| − | | |
| − | As data centre computing resources transition to a remote cloud, departmental IT staff will see their responsibilities transition. IT staff must be able to monitor the performance of local and cloud IT resources, but their ability to control those resources will be reduced.
| |
| − | | |
| − | === ''Organizational Impacts'' ===
| |
| − | As departments move from deploying their own IT/IS capabilities to using those offered by cloud providers, the departmental IT function will become less technical and more focused on contract negotiation and performance against these contracts.
| |
| − | | |
| − | Traditional methods of assessing and authorizing systems will change, with more emphasis on evaluating contracts and less on evaluating the information systems themselves, particularly if a FedRAMP-equivalent process is implemented that allows department to select from pre-authorized cloud providers.
| |
| − | | |
| − | The roles and responsibilities of various enterprise actors will need to transition in accordance with the cloud computing paradigm.
| |
| − | | |
| − | === ''Impacts During Development and Acquisition'' ===
| |
| − | The transition to cloud computing will fundamentally change how new IT/IS capabilities are acquired and deployed. Some key tasks and decision points during the acquisition process are shown in Section 5.2 of the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Analysis of the Proposed Security Architecture ==
| |
| − | For more information about the proposed security architecture for GC cloud computing, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | === ''Benefits'' ===
| |
| − | Cloud computing provides cost benefits from the ability to consolidate resources in a smaller number of data centres. The essential characteristics of resource pooling and rapid elasticity allow dynamic reallocation of resources to handle peak loads. This allows for more efficient use of fewer resources.
| |
| − | | |
| − | The on-demand self-service and broad network access are essential characteristics of cloud computing that promise highly available access for end users of cloud services.
| |
| − | | |
| − | === ''Disadvantages and Limitations'' ===
| |
| − | Cloud computing is focused on the efficiency and usability benefits that are achieved through consolidation and resource pooling. Improving security is not a stated goal of cloud computing, and the essential characteristics of resource pooling, rapid elasticity, on-demand self-service, and broad network access have the potential to reduce security in comparison to conventional information systems.
| |
| − | | |
| − | When deploying cloud technology, special attention must be paid to verifying that applicable security controls are being complied with. This may be problematic for outsourced clouds where the cloud consumer may not have the ability to perform a hands-on evaluation of the cloud provider's implementation, but is instead dependent on the provider's commitment to abide by the terms of the agreed MSA.
| |
| − | | |
| − | If the performance of a cloud provider is unacceptable, or a cloud provider terminates service, changing cloud providers and recovering intellectual property from old provider may be a challenging problem. Depending on the SA&A and continuous monitoring requirements levied on cloud providers by the GC, a provider may be unable or unwilling to remain in compliance, thereby forcing the GC to terminate the service.
| |
| − | | |
| − | A lack of common cloud management standards can result in the need to deploy and learn new cloud management tools when a service is transitioned between cloud providers.
| |
| − | | |
| − | Section 6 of the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|ESA ConOps Annex B: Cloud Security]] document delineates a number of scenarios intended to help illustrate the scope of the process, policy, technological, operational, and organizational impacts of the cloud computing paradigm for the GC.
| |
| − | | |
| − | === ''Alternatives Considered'' ===
| |
| − | Data centre consolidation is already occurring within the GC and cloud computing is the next logical step in the process. Cloud computing has been widely embraced by industry and government. Cloud computing is a broad concept and distinctly different approaches have emerged.
| |
| − | | |
| − | Although Cloud First is intended to encourage GC departments to use cloud computing, it is not the appropriate answer for all problems.
| |
| − | | |
| − | Having moved a service to the cloud, it can be very expensive to convert back to a traditional service model or transition the service to another cloud provider. For instance, the Australian Government has decided to change course on their IS consolidation effort due to lack of meeting cost and service delivery objectives.
| |
| − | | |
| − | It is, therefore, imperative that the GC implement a comprehensive cloud decision process as illustrated by the notion process discussed in section 5.2 of the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|ESA ConOps Annex B: Cloud Security]] document so as to ensure GC stakeholder requirements and expectations are properly vetted.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == References ==
| |
| − | * [[Media:GC Enterprise Security ConOps - ANNEX B Cloud Security.pdf|GC ESA ConOps Annex B: Cloud Security]]
| |
| − | * [[Media:GC ESA Definition Document (ESADD) - Main Body.pdf|GC ESA Description Document Main Body]]
| |
| − | * [[Media:GC ESA Definition Document (ESADD) - ANNEX C NCS.pdf|GC ESA Description Document Annex C: Network and Communications Security]]
| |
| − | | |
| − | [[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
| |
| − | [[Category:Enterprise Security Architecture]]
| |
| − | [[Category:Cloud computing]]
| |
