Private cloud day session 5 a solution for private cloud security
•Als PPTX, PDF herunterladen•
1 gefällt mir•589 views
The document discusses several topics related to private cloud security including key principles, challenges, reference models, and threats and countermeasures. It addresses concerns that tenants and architects might have regarding access control, monitoring usage, and reconciling perceptions of infinite resources. The document also examines security domains in a reference model, different security functionality, and private cloud security models involving virtualization stacks, hypervisors, and isolating partitions at different privilege rings.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Private cloud day session 5 a solution for private cloud security
Ähnlich wie Private cloud day session 5 a solution for private cloud security (20)
Mehr von Microsoft TechNet - Belgium and Luxembourg
Mehr von Microsoft TechNet - Belgium and Luxembourg (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Private cloud day session 5 a solution for private cloud security
- 8. Key Security Differences in Private Cloud Private Cloud Security Principles Private Cloud Security Challenges Private Cloud Reference Model Private Cloud Security Model
- 11. Cloud Security Threats and Countermeasures at a Glance
- 12. Multitenancy in private • Multiple orgs and divisions VM VM cloud VM VM Requires • Authentication logical • Authorization VM VM VM separation • Access controls
- 13. Mobile Security Virtualization of Security Controls Workloads Tools • Integrate with the private cloud fabric Automated Playing • Provide separate configuration interfaces Mobility catch-up • Provide programmable elastic, on-demand services Unlinked from Px • Support policies governing logical attributes • Enable trust zones separating multiple tenants in a dynamic environment
- 15. Apply generic security best Principles provide general rules and guidelines to support the evolution of a practices secure cloud infrastructure. They are enduring, seldom amended, and inform and support the way you secure the private cloud. These principles form the basis on which a secure cloud infrastructure is planned, designed and created Security is a Enforce Isolation wrapper All data Attackers are Use strong Automate security AuthN and AuthZ locations cryptography operations accessible Minimize attack Limit “routing” Audit extensively Strong GRC service
- 17. As a consumer (tenant) of the services offered by a private cloud in my enterprise, I require that application data is secure, no one else can access it, and that the data is safe if something untoward occurs Prevent leakage Also applies to between tenants administrators Role Based AAA Access Control
- 18. As the architect, designer, or operator of a private cloud Who has authority to: solution, how do I control who has access to my private cloud services and how do I monitor Demand Provision Use Release and audit the use of my services?
- 19. I am concerned that a rogue application, client, or denial of service (DoS) attack might destabilize the data center by requesting a large amount of resources. How do I reconcile the perception of infinite resources with reality?
- 20. As an architect of a private cloud Bring Your Own Device solution, I want to be sure that an appropriate level of security applies Assess device state regardless of client location and regardless of form factor. This Application access control requirement applies to both cloud management and application security. Data on device
- 21. • IPv6 Driven • Porous borders By: • “Tail Chasing” • Cost/benefit
- 23. A Reference Model is: • Abstract • Describes entities and there relationships • Defines and clarifies a problem space • Technology agnostic A Reference Model can be used to: • Create standards for objects in the model • Break down a large problem space • Define concepts and relationships • Define and create roles and responsibilities • Compare different things (software solutions)
- 27. Security Security Functionality Domains Infrastructure Security Platform Security Software Security Service Delivery Security Management Security Client Security Legal/Compliance
- 29. Root Partition Guest Partitions Ring 3 Ring 3 Virtualization Stack Guest Applications VM Worker Processes OS Server Core Kernel Windows Kernel Device Drivers VMBus Ring 0 Ring 0 “Ring “-1” Windows hypervisor Storage NIC CPU
- 30. Root Guest Guest VM 1 VM 2 VM 3 Partition Partition Partition (Admin) Virtual- ization VM 1 VM 2 Stack Virtualization Stack Drivers Hypervisor Drivers Hypervisor Hardware Hardware “The fact is, the absolute last place you want to see drivers is in the hypervisor, not only because the added abstraction layer is inevitably a big performance problem, but because hardware and drivers are by definition buggier than "generic" code that can be tested.” Linus Torvalds, https://lists.linux-foundation.org/pipermail/desktop_architects/2007-August/002446.html
- 32. Data Center’s Physical Servers Guest OS Data-Center Network
- 35. Free Stuff!
Hinweis der Redaktion
- Welcome to this session on Private CloudThe topic is “A Solution for Private Cloud Security”I’m Tom Shinder, a Principle writer in the Server and Cloud Division Information Experience GroupYou might know me from my ISAserver.org daysIf you’ve been thinking “I know that guy from somewhere” – then now you know from where
- Is knowing architecture useful?I’ve heard each of these said in the pastArchitects are closer to rocket scientistsHow do you think the Star Ship Enterprise knew where to go?Architects need to have an understanding of the capabilities that software can provide and understand what is possible and what is not currently possible and seek alternativesArchitects do a lot of things – they typically have datacenter infrastructure and operations experience before getting into the architecture businessThere are some in the room now – now you know some!Maybe you did need an architect!Ah ha! If you don’t know what’s an architect, then this is a great time to learn what the purpose and value of architecture provides
- It’s important to understand that the industry is placing increasing importance to architects and architecture.A Corporate Executive Board study shows that among the CIOs surveyed – 63 % believe that architecture is growing in importance and that 47% of them are having difficulty finding architects.A recent Gartner study focused on the future of IT notes that with the growing importance of cloud computing, that there will be an increased emphasis on architecture roles and that the term “cloud architect” is used increasingly often when thinking about the new roles. They see a number of new cloud architect positions becoming important in the next five years.Many believe that while there is likely to be a significant contraction in the total number of infrastructure and operations IT professionals due to widespread adoption of cloud computing, the number of cloud architect positions will increase so that the total number of IT positions will remain stable or potentially grow as the architect roles are defined and refined.
- The Winchester “Mystery” house is an example of what happens when there is no architectural blueprint for a building design(read the four bullet points)Does this remind you of your datacenter network today?
- A surgeon doesn’t just grab a scalpel and starting cutting based on where he thinks the organs are, or even after having participated in a several surgical operations. Surgeons need to understand the entire system on which they’re working, as a surgical procedure requires prerequisite knowledge of many areas, such as anatomy, physiology, pharmacology, biochemistry, neuroscience, pathology and microbiology, even before considering the surgical procedures. These areas provide the architectural framework that provides the definitions, constraints, requirements and decision points for every step of the surgical process.
- Now that I’ve given you a bit of background on the value of understanding architectural and the value of architectural background and guidelines, let’s get to the meat of today’s discussion. We will cover the following:Key security differences in the private cloudPrivate cloud security principlesPrivate cloud security challengesPrivate cloud reference modelPrivate cloud security model
- In a traditional data center environment, the demarcation of security responsibilities between the data center operator and the service user was relatively well defined. Generally, the responsibility was aligned with ownership of the physical component, whether that was a server, a networking device or the overall network infrastructure; if the IT department owned and administered the server, then that department also managed and updated security on that asset. With cloud models, security responsibility has altered, in that departments may be responsible for a portion of the security on the service that they pay for, depending on the service provisioning model in use. The figure shows the split of security responsibility for the three main cloud provision models.
- Taking the private cloud reference model as the basis for analysis, you can identify threats to the private cloud infrastructure and place these threats into appropriate places within the model. This approach provides a basis for threat modeling and risk analysis. Hence, you can classify attacks according to the layer or stack that the attack targets. This figure highlights the primary areas in the private cloud where these individual attack types can target. Note that this diagram is not showing responsibilities but listing the different types of attacks that might take place against the management stack, the infrastructure layer and so on. You should also note that some of these areas may be out of control of the private cloud provider, such as client security. Note: This figure only summarizes the threats that may exist at the different levels of the cloud architecture. For an explanation of each of these threats and applicable countermeasures, see Cloud Security Threats and Countermeasures at a Glance, at http://blogs.msdn.com/b/jmeier/archive/2010/07/08/cloud-security-threats-and-countermeasures-at-a-glance.aspx.
- A key differentiator with public cloud environments is that the service is provided on a shared tenant basis and multiple tenants use the same pooled infrastructure and services. The public cloud implementation then applies authentication, authorization, and access controls to create logical partitions between the tenants so that individual tenants are isolated from each other and cannot see other tenants’ data. Note: In private cloud terminology, a tenant is a client, typically a business unit within the organization, who is using the private cloud to run their applications and services.The perception of a private cloud is that it is only hosting one organization, and in consequence, security partitioning is not required. In reality, organizations may have good reasons to want to implement such partitioning, such as between different business units or between the finance department and the rest of the organization. In consequence, a private cloud model may also be a shared tenant model with similar requirements for effective security partitioning between different business units as with public cloud implementations.
- Virtualization is not an absolutely essential component of private cloud architectures, as organizations can use blade server arrays or other compute-dense configurations to provide cloud-based services. However, the advantages of improved server utilization and greater operational flexibility that virtualization platforms provide have led to very high uptake of this technology in cloud environments.Virtualization radically changes the way an organization secures and manages its data center. Because workloads are mobile and can move from host to host based on optimization algorithms that require no human involvement, security policies linked to physical location are no longer effective, so security policies must be independent of network or hardware topologies.Although estimates of data center server virtualization indicate that this technology has reached adoption levels of over 50%, management and security tools for virtualized environments are still catching up with the physical systems that they replace. The presence of the new hypervisor layer provides additional attack vectors and new opportunities for security breaches. One example of the new attack vectors occurs when virtual machines running on the same physical host typically use virtual networking components to communicate between these guest operating systems. In consequence, virtual machines can be communicating with each other without those communications being picked up by monitoring tools on the physical network. IT staff must be able to identify when inter-virtual machine traffic is occurring and apply policies and monitoring to that traffic.A key factor for implementing effective security in virtualized environments will be virtualization of the security controls themselves. As these virtualized controls become available, they should as a minimum meet the following criteria:Fully integrate with the private cloud fabricProvide separate configuration interfacesProvide programmable, on-demand services in an elastic mannerConsist of policies that govern logical attributes, rather than policies that are tied to physical instancesEnable the creation of trust zones that can separate multiple tenants in a dynamic environmentIn summary, security in private cloud environment must be adaptive and natively implemented into a fabric where resources are allocated dynamically. Any security functionality that is tied to a server, an IP address, a MAC address, port, or other physical instance will no longer be as effective as in purely physical environments.
- For the private cloud, the key security principle that drives an effective design is that your design should seek to build a system of controls, rather than a collection of controls. This unified system of controls is more than just the individual security technologies and methodologies – each part integrates with each other to provide the overall defenses. This unified security approach would include the following design principles:Apply generic security best practicesUnderstand that isolation is keyConsider security as a “wrapper”Assume attackers are authenticated and authorizedAssume all data locations are accessibleUse established strong cryptographic technologiesAutomate security operationsReduce attack surfaceLimit routingAudit extensively Implement effective governance, risk management and complianceApply Generic Security Best Practices Private clouds use existing technologies such as virtualization and extend the infrastructure designs current in many organizations. As such, you should maintain existing security practices as part of the security design for your private cloud. For example, you should continue to:Implement the principles of least privilege and defense in depth. Use firewalls and use separate NICs for management functions. Carry out penetration testing and to audit your security processes.However, private cloud architectures introduce new potential vulnerabilities and you must modify and add to your existing design to mitigate these new threats.Enforce Isolation Typically, private cloud implementations use virtualization technologies to make infrastructure, platform, and software resources available to clients within the enterprise. Tenants may be other business units within the enterprise, or other sections of the IT department using private cloud resources to deliver services to client business units. Even though private cloud tenants are part of the same organization, you must ensure isolation of their resources. For example, confidential human resources data must not be generally accessible even though the human resources systems could be running on the same physical server as the company intranet. It is not just an issue of simple confidentiality. In the IaaS, PaaS, and SaaS service delivery models, you may not know which tenant services are co-hosted on the same physical devices at any particular time. In consequence, a problem in one tenant service could affect the performance, network connectivity, or network availability of other tenant services on the same physical hardware. Your design must ensure isolation between tenants in both the physical and virtual environments that make up the private cloud.If your private cloud is partially or wholly hosted by a third party, then you must be assured that the cloud infrastructure used by the third party also guarantees isolation, both between your services and between your services and any other organization's services that the third party also hosts.Consider Security as a Wrapper You should consider security as a “wrapper” around all elements of your private cloud architecture. The private cloud reference model in figure 1 shows how security concerns are relevant to all elements in all layers and stacks within the architecture: Infrastructure PlatformSoftware Service delivery ManagementA private cloud typically hosts services in virtualized environments, with multiple services co-located on the same physical device. The security wrapper functions must be applied to both the physical and virtual environments because in a private cloud architecture you cannot assume that by protecting the physical environment you automatically protect the virtual environment, and vice versa. If an attacker gains access to the physical infrastructure, they can disrupt not only the infrastructure, but also potentially gain access to the virtualized resources hosted in the cloud. If attackers manage to compromise a virtualized environment, they can potentially use the compromised environment as a platform to attack other virtualized environments within the cloud or to attack the infrastructure.Although your design should consider security as a wrapper around all elements in the architecture, your design should take into account the possibility that responsibility for security may be split between the CSP and the tenants. For more information about this scenario, see the third paper in the series “A Solution for Private Cloud Security: Service Operation."Considering security as a wrapper should be part of your defense in depth strategy for securing your private cloud. For a more information about the private cloud reference model shown in Figure 1, see the first paper in the series “A Solution for Private Cloud Security: Service Blueprint."Assume Attackers are Authenticated and Authorized In the private cloud, you may delegate some of the responsibility for managing the security of the environment to the tenant. A tenant may provision resources through a self-service portal in order to run its tenant application or service in the private cloud. The cloud service provider may have little or no control over how the tenant configures and uses its virtual resources and this includes control over how the tenant grants access to its services to its end users. Because of this, you must assume that attackers can be authenticated users with authorized access to a virtual machine running in your data center. The attacker could be an untrustworthy employee, someone using stolen credentials, or an attacker using elevated credentials.You should consider this route of attack from within a virtual machine in your data center in addition to more traditional attacks that may be mounted from outside your organization in an attempt to exploit weaknesses in your external defenses. Attackers will now attempt to find weaknesses that they can exploit in the virtual environment. For example, an attacker might try to gain access to the hypervisor from within the hosted virtual machine, a type of exploit known as hyperjacking. Assume All Data Locations are Accessible This point closely relates to the previous point about authenticated and authorized attackers. In private cloud architectures, many data locations are exposed as services. For example, virtual machines may mount virtual hard disks from a storage resource, or they may use virtual queues, virtual tables, or virtual binary large object (BLOB) storage. A tenant may provision these resources through an automated self-service portal as part of the infrastructure or platform services provisioning process. If an attacker can gain access to a tenant's virtual environment, you must assume that they may also gain access to the tenant's data locations.Because of this, you should consider when and how to encrypt data and how to store and manage the encryption keys that enable access to the data stored in the cloud.Do Not Trust Client Information You cannot make any assumptions about the security of any of the client applications that access the tenant services hosted in the private cloud. This proviso is especially important when the tenant wants to enable broad network access to the tenant service from multiple device types and from multiple locations. Poorly designed client applications could accidently reveal credentials or keys, and may perform limited validation on the data that they send to the services hosted in the cloud. Therefore, cloud management services and tenant services must perform their own validation of data sent from all client applications.In contrast, you have more control over the client applications and tools that you use to manage the cloud infrastructure. For example, you may limit access to cloud management functions to client applications running on the corporate intranet, or use certificates to identify client applications. However, some cloud management operations may require calls to published APIs, which themselves may not require full validation of the data sent to the cloud and could be invoked from a custom application created by a developer.Use Established Strong Cryptographic Techniques Encryption of data at rest, in transit, and during processing can help to ensure that the data is only visible to those who should be able to see it. Therefore using encryption can help to preserve the isolation of tenants' resources and help to mitigate the threat that attackers may be authenticated users with access to the locations where the application or service stores its data.You should ensure that your infrastructure uses established, strong encryption techniques wherever it uses encryption. Tenants should also be encouraged or mandated to use established, strong encryption techniques in their own cloud-hosted applications and services.Implementing cryptographic algorithms securely is complex and difficult.Using strong, established cryptographic algorithms and cryptographic systems rather than "rolling your own" helps to validate your approach to encryption, and makes your cryptographic processes auditable. Remember that attackers will only bother attacking the algorithm itself if they recognize it as weak – typically, they go after the keys.Automate Security Operations The size of private clouds, self-service provisioning, and virtualization all combine to make it essential to automate operational activities such as collecting and correlating monitoring data, responding to security related incidents, and allocating resources to tenants to prevent denial of service situations.A typical private cloud hosts a large number of tenant services and supports a large number of end users. To ensure effective and timely responses to security issues, you must automate those responses as far as possible. Automated security responses rely on monitoring, so your design must include monitoring services that enable you to automatically identify and act on possible security issues. The automated response procedures must send notifications to the staff that are responsible for security and create a full audit trail of their actions. You should evaluate and review these procedures regularly. Note that when configuring security monitoring, you must also not let yourself be swamped by security responses and turn off monitoring altogether. Better to build up a feel for what is important by enabling rules more slowly. When you have a baseline and an understanding for your environment, you can then add the automation.If you are building your virtualization host and guest environments from standard templates or images, you should ensure that those templates and images include configuration of the monitoring on which your automated responses will rely.Your private cloud design should include a comprehensive automation platform that will enable operational activities such as those outlined above. You should also ensure that the security monitoring and response automation can cope with cloud-based environments and with virtual machines that can be rapidly provisioned and deprovisioned.Reduce Attack Surface As with all computer systems, reducing the attack surface is a key element to preventing attacks from succeeding. If the attacker only has a very small area to attempt to access, then he or she has far fewer options to find a successful exploit. Within a private cloud environment where you are likely to be using virtualization, you must ensure that you reduce attack surface wherever possible on both host and guest computers. You should only enable the ports, services, and features that are essential to your operations. Your risk assessment should identify all unnecessary components and you should then remove or disable these components.Limit Routing Anytime data transitions though the private cloud, it adds another possible place that an attacker might be able to access or tamper with that data. Your private cloud design should limit the number of nodes that data must pass through to reach its destination as a part of the overall design goal to reduce the attack surface.For example, if a tenant is deploying a three-tier application to the private cloud, they should be able to configure the application so that the individual tiers can communicate directly with each other without the data passing through a shared broker component unless there is a specific requirement for this to happen.Additionally, more complex routing requires more complex monitoring, and the more difficult it becomes to understand the flow of data within the already complex cloud environment.Audit Extensively The cloud is a relatively new and fast changing environment that means that new usage patterns and new threats will emerge. Your security processes should be audited regularly in order to validate that the current security design includes mitigations for known threats. If not already applicable, you should consider gaining consider certifications such as ISO/IEC 27001and SAS 70 Type II.ISO/IEC 27001 is an international standard has been prepared to provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an Information Security Management System (ISMS). This International Standard can assess conformance by interested internal and external parties. For more information, visit http://www.iso.org.Statement on Auditing Standards No. 70 (SAS 70) is an international auditing standard that enables businesses that provide services to other organizations to provide an independent, trustworthy account of their internal control practices. An independent auditor performs the SAS 70 audit and generates the resulting SAS 70 report, which the service provider supplies to its customers and clients for use when they themselves undergo auditing. For more information, visit http://www.aicpa.org.Implement Effective Governance, Risk Management and Compliance In a private cloud, because ownership of and responsibility for services hosted in the cloud is split between various parties, the SLAs between the parties must make clear where those responsibilities lie and what the different parties should expect from each other.The set of SLAs that you must consider will depend, in part, on the particular cloud model adopted by your organization:If you chose to adopt a hybrid cloud model, or chose to host your private cloud with a third-party organization, then the enterprise CSP will have SLAs with the third-party cloud service provider and with the client business units within the organization. In these scenarios, the IT department is acting as a broker to deliver and manage cloud services provided by an external entity, to internal clients.If you are hosting the private cloud on premises, you must then negotiate SLAs between the IT department and the client business units.If you are using a third party to provide some or all of the private cloud services in the enterprise, then you must ensure that the SLAs with the third party provider enable you to meet your SLAs with your internal clients. This requires a detailed understanding of what the third party SLAs offer in terms of security. For example:How do they guarantee isolation between tenants? What do they guarantee in terms availability and disaster recovery?How do they ensure the integrity of your applications and data?What steps do they take to ensure the physical security of your data such as vetting employees who have access to the physical environment and hardware disposal procedures?Regardless of whether you choose to host the private cloud externally with a third party, on premises, or adopt a hybrid approach, you will still need SLAs between the your IT department and the tenants within the organization. The on-demand, self-service attribute of the private cloud, means that there may be some delegation of responsibility for managing the security of the virtualized environment to the tenant. In addition to the guarantees made to the tenant by the cloud service provider, SLAs may also need to specify requirements related to security that the tenant must fulfill. For example, an SLA might specify the encryption technologies that the tenant service should use to protect data, or that the tenant should use the enterprise directory for identity management through federation services provided by the CSP.How much delegation of responsibility occurs will vary between organizations and between tenants. For some organizations, the primary motive behind adopting a private cloud model will be to make more efficient use resources by pooling them: the IT department will still deploy and manage applications and services on behalf of the client business units. In this scenario, the on-demand, self-service characteristic is not significant to the relationship between the cloud service provider and the client business unit, and SLAs will cover traditional areas such as availability, disaster recovery, and performance. However in some scenarios, tenants will make use of the on-demand, self-service functionality of the private cloud to obtain and manage infrastructure or platform resources to run their own applications and services. In this case, the split in responsibility for security features such as identity and access management or data protection may be more complex and the SLAs must include clear definitions that are understood and agreed upon by all the concerned parties.Scenarios that are more complex are also possible. For example, in addition to managing the private cloud infrastructure, the IT department may also commission, procure, or develop applications for other business units within the organization. In this scenario, one part of the IT department may use the on-demand, self-service capability of the private cloud to acquire infrastructure or platform services on behalf of the client business unit and also handle some or all of the ongoing management of the service on behalf of the client business unit. This arrangement creates a scenario where there are two SLAs: one between the cloud service provider and service provider sections of the IT department, and one between the service provider part of the IT department and the client business unit.In a private cloud, all parties must have an explicit understanding of their obligations and responsibilities and agree to them. Depending on the model adopted by your organization, the list of parties involved might include: third-party cloud services providersan internal cloud-services providerapplication and software providers who are a part of the IT department and who consume private cloud servicesclient business units within the organization whose applications and services are hosted in the private cloudWhen you are negotiating and drafting SLAs you must ensure that:You cover all aspects of security for all hosted services and applications and there are no gaps in responsibility.Your SLAs with third party providers enable you to meet the SLAs with your tenants
- Problem Statement: As the consumer (tenant) of the services offered by a private cloud in my enterprise, I want to be sure that the data in my application is secure, that no-on else can access it, and that it is safe if something untoward occurs.Resource pooling is the mechanism by which cloud environments can increase utilization levels, reduce costs and make use of cheaper resources, such as commoditized servers and inexpensive hard disks. For example, organizations no longer need to buy in expensive storage area network (SAN) equipment but can instead create cheaper storage pools that employ resilience rather than redundancy to protect the data. By using management tools to create compute, storage and networking pools and by automating the allocation of these resources, the cloud administrators can enable multiple users, groups, or organizations to make use of these pooled resources. Resource pooling needs to be considered at all three service layers of the private cloud model. But this resource pooling also requires significant consideration of the security aspects from such a configuration.With public cloud implementations, it is self-evident that resource pooling also infers a requirement for strict account partitioning. No public cloud business model is likely even to come to market if it cannot offer effective separation and segregation of customer data. In a public cloud model, this partitioning also applies to common areas such as the directory service. With a private cloud implementation, a similar requirement for strict data partitioning is not immediately obvious. With areas such as the directory service, such partitioning may even be counter-productive. Instead, the question you need to ask is whether you would want every business unit and individual within your organization to view the data or use the applications belonging to every other unit or user. If universal access is desirable then access control list (ACLs) and application, file, or share system permissions are superfluous and you do not need to partition your private cloud environment.If, however, you do need to protect data and applications from access by authenticated users who are not authorized to view that information or use those applications, then you do need to implement some form of partitioning within your private cloud environment. Similarly, administrative rights need to be carefully controlled, as you may want to give certain groups or business units the right to carry out limited administrative actions on their resources.With each pooled resource, you must ensure that each tenant’s data or applications are kept partitioned from those belonging to other tenants. Any data that is exclusively owned by a consumer should not leak to other sessions nor be accessible by other users or tenants, whether maliciously or not. Partitioning and Role Based Access Control (RBAC) also applies to your administrators, who should not have automatic access to tenant data. In the case where an administrator does require access to tenant data, then that access must be carefully audited.
- Problem Statement:As the architectofa private cloud solution, how do I control who has access to my private cloud services and how do I monitor and audit the use of my services?The essence of cloud provisioning is that of self-service. When combined with rapid elasticity, self-service enables cloud implementations to provide dynamic and timely responses to requests for more or fewer resources. No longer is it necessary to go through a cumbersome process to request a new server, development platform, or software – you can simply go to a self-service portal and select what type of computing resource you want from a standardized service catalog. The portal then provisions the environment, allocates resources from the shared pools, mounts the environment, configures security, and then connects the consumer to the requested service. Yet the simplicity of on-demand self-service can also be its weakness. Because cloud environments are often virtualized, any errors in assigning security permissions during the provisioning process could, for example, result in other tenants being able to access the newly provisioned environment. Hence monitoring of the success of provisioning and deprovisioning requests is vital. Because the attacker profile is different for private cloud, you also have to identify additional vulnerabilities and security gaps. Hence, you must consider who has authority to demand, provision, use, or release services, regardless at what service level (SaaS, PaaS or IaaS) those services are provided. You must be able to authenticate the users making these requests, implement RBAC to grant access to the relevant resources at the right level, ensure that permissions on the resources are correctly set, provide secure access to the resources and partition those resources from other service users. When the requesting user indicates that the resources are no longer required, you must be able to deprovision those resources, remove access, and destroy any residual data that might be present. All resources must then be returned to the cloud in the same base state as all assets in the respective resource pools. The destruction of residual data is particularly important. Cases have come to light of public cloud providers finding that tenant data from one session was not being adequately purged, which enabled subsequent tenants to access this data.You must also provide your consumers with an SLA that details the security levels that apply to the provisioning and deprovisioning processes. This SLA must specify the resultant security outcomes without compromising overall security by providing details of how the security is applied.
- Problem Statement: As the architect of a private cloud solution, I am concerned that a rogue application, client, or denial of service (DoS) attack might destabilize the data center by requesting a large amount of resources. How do I balance the requirement that individual consumers or tenants have the perception of unlimited resources with the reality of limited shared resources?A further key difference with cloud environments compared to traditional IT provision is that cloud implementations should provide the perception of unlimited resources. Because the compute, storage, and network resources are pooled and can therefore be shared between customers, customers can request as little or as much of each resource as they need within their budgetary constraints. The management system can then rapidly allocate these additional resources either through manual requests or by automatic, demand-led provisioning.Rapid elasticity enables organizations and business units to scale their operations up and down quickly to meet demand. For example, prior to rolling out a new desktop operating system, the IT department can scale up its helpdesk application to handle the expected increase in support calls. When the operating system is bedded in and the support call volume decreases, the additional resources can be released back into the shared pool. Rapid elasticity enables organizations to cope with a variety of variations in demand such as irregular spikes (such as might occur after an exceptional news event) or regular patterns, like running month-end financial reports.However, the very strength and advantages of rapid elasticity can also be a weakness. It is important to understand that the perception of unlimited resources does not equate to infinite resources. Ultimately, there is a resource limit even in the most well-founded private cloud implementation. In consequence, repeated requests to provisioning resources or an inability to deprovision resources properly could lead to resource exhaustion. There is the risk that the provisioning process itself could mimic a DoS attack. If the process of requesting resources is fully automated, an application error or a logical failure in the provisioning process could lead to repeated resource requests. Eventually, these repeated requests could use up all the compute, memory and storage resources within the cloud environment. When a new tenant makes a service request or an existing tenant wants to increase their allocation of resources, the private cloud environment would not be able to respond to these service requests. There is also the scenario of an unwitting or even semi-malicious attack where the same tenant just goes on requesting more and more resources “because they can”. Simply because departments are charged for resources may not be enough of an incentive for them not to request resources on a whim. Hence monitoring and management must be able to implement pre-set quotas and ensure that the limits of resources per tenant are not breached without prior authorization. These quotas must be centrally configurable and adjustable on a per-tenant basis for maximum flexibility.
- Problem Statement:As an architect of a private cloud solution, I want to be sure that an appropriate level of security applies regardless of where the client is connecting from and regardless of the device form factor. This requirement applies to both cloud management and application security.With public cloud implementations, delivering broad network access requires public network connectivity. In private cloud environments, there is no absolute requirement to connect your data center to the Internet, although not having this connectivity might adversely affect the potential benefits from the private cloud implementation. In a fully managed and closed network environment, it is possible have a unanimously homogenous client base. However, the phenomenal proliferation of mobile devices, browsers and computer form factors from multiple vendors combined with greater user demands to access work data from anywhere in the world means that private cloud architectures must plan to include broad network access as an option. This proliferation has led to the phrase “bring your own device” or BYOD being coined to cover this consumerization of IT.Any form of hybrid cloud architecture also implies the requirement for broad network access. Consumers may be authenticating to an application provided by a public cloud provider using federated identity to authenticate from your internal directory service. Your internally-hosted private cloud implementations may also be using web services from a third public cloud provider. In consequence, failing to consider the broad network access picture is inherently limiting.The broad network access cloud characteristic requires IT departments to consider the entirety of the client to service network journey. It is also requires consideration of the effect of this requirement for universal access on management of the environment. Just as consumers need to access the cloud services from anywhere, so do providers.
- When moving to a private cloud environment, you may want to review the relative importance of the perimeter network as a security boundary. Although we do not advocate removal of the perimeter network, there are several reasons why the perimeter network and associated firewalls should no longer be regarded as a comprehensive defense against network intrusion. This list highlights some of the reasons for this change of emphasis:Authenticated attackers. As organizations secure their environments against anonymous users, attacks against data centers are increasingly using authenticated credentials. With private cloud environments, this trend is expected to continue and you should design your environment with this scenario in mind. If the attacker is able to authenticate, then they can already penetrate your perimeter network and access your cloud-based applications and data. Client types. Moving to a cloud environment may result in the requirement to allow access from untrusted clients, such as kiosk computers. Connections from these client types require checking not just at the perimeter but at every stage throughout the end-to-end communication process. Defense in depth. Private cloud implementations require a true defense in depth approach to security, where every layer of the architecture is secured. This approach inevitably changes the relative importance of the perimeter network, making it just a part of your total defenses.So although the perimeter network is still a an identified security boundary (and possibly the first that the customers encounter), you should consider whether its relative weight in the overall security picture has changed.In private or hybrid cloud implementations, rather than remove the perimeter network altogether, you can place all other networks outside the perimeter into the untrusted zone. The figure provides a conceptual representation of this change.
- From Wikipedia:“A reference model in systems, enterprise, and software engineering is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations.[1]Contents[hide] 1 Overview2 The uses of a reference model3 Examples4 See also5 References[edit] OverviewThere are a number of concepts rolled up into that of a 'reference model.' Each of these concepts is important:Abstract: a reference model is abstract. The things described by a reference model are not actual things, but an abstract representation of things. Therefore, when describing the architecture of a house, an actual exterior wall may have dimensions and materials, but the concept of a wall is part of the reference model. One must understand the concept of a wall in order to build a house that has walls.Entities and relationships: A reference model contains both entities (things that exist) and relationships (how they interact with one another). A list of entities, by itself, is not sufficient to describe a reference model.Within an environment: A reference model does not attempt to describe "all things." A reference model is used to clarify "things within an environment" or a problem space. To be useful, a reference model should include a clear description of the problem that it solves, and the concerns of the stakeholders who need to see the problem get solved.Technology agnostic: A reference model is not useful if it makes assumptions about the technology or platforms in place in a particular computing environment. A reference model is a mechanism for understanding the problems faced, not the solutions involved, and as such, must be independent of the selected solutions in order to provide value to the practitioner. Note: That does not preclude the development of a reference model that describes a set of software applications, because the problem space may be "how to manage a set of software applications."[edit] The uses of a reference modelThere are many uses for a reference model. One use is to create standards for both the objects that inhabit the model and their relationships to one another. By creating standards, the work of engineers and developers who need to create objects that behave according to the standard is made easier. Software can be written that meets a standard, and developers can copy that software to use it again, or build a software factory that generates that code. When done well, a standard can make use of design patterns that support key qualities of software, such as the ability to extend the software in an inexpensive way.Another use of a reference model is to educate. Using a reference model, leaders in software development can help break down a large problem space into smaller problems that can be understood, tackled, and refined. Developers who are new to a particular set of problems can quickly learn what the different problems are, and can focus on the problems that they are being asked to solve, while trusting that other areas are well understood and rigorously constructed. The level of trust is important to allow software developers to efficiently focus on their work.A third use of a reference model is to improve communication between people. A reference model breaks up a problem into entities, or "things that exist all by themselves." This is often an explicit recognition of concepts that many people already share, but when created in an explicit manner, a reference model is useful by defining how these concepts differ from, and relate to, one another. This improves communication between individuals involved in using these concepts.A fourth use of a reference model is to create clear roles and responsibilities. By creating a model of entities and their relationships, an organization can dedicate specific individuals or teams, making them responsible for solving a problem that concerns a specific set of entities. For example, if a reference model describes a set of business measurements needed to create a balanced scorecard, then each measurement can be assigned to a specific business leader. That allows a senior manager to hold each of their team members responsible for producing high quality results.A fifth use of a reference model is to allow the comparison of different things. By breaking up a problem space into basic concepts, a reference model can be used to examine two different solutions to that problem. In doing so, the component parts of a solution can be discussed in relation to one another. For example, if a reference model describes computer systems that help track contacts between a business and their customers, then a reference model can be used by a business to decide which of five different software products to purchase, based on their needs. A reference model, in this example, could be used to compare how well each of the candidate solutions can be configured to meet the needs of a particular business process.”
- When envisioning your route to the private cloud, a reference model can help you visualize your complete environment. Note that a private cloud reference model does not identify specific technologies but instead shows the capabilities that your design must include. There is currently no universally accepted reference model for private cloud and several organizations that work in this area have published their own model. Microsoft is no exception and has devoted significant investment into creating a private cloud reference model that Enterprise Architects can use to create their design. The figure shows the Microsoft Private Cloud Reference Model in detail.You might initially think that this reference model is not particularly useful, as it is not giving you a prescriptive design for building a private cloud. However, this approach is intentional, as it does not bind you in to a particular technology and is much more adaptable for long-term planning. Instead, you use the reference model at the conceptual level to identify what capabilities your final physical implementation must have. For example, in the Service Delivery layer, you need the capability of service provisioning. This capability is not a product or a technology; it is simply functionality that must be present in your final design.From this model, you then might identify particular technologies that you plan to implement. Reasons for adopting a particular technology can include:PriceFeaturesCompatibilityPerformanceCompany policyPersonal preferenceTechnical maturityCustomer requirements
- The technology Model might look like this with a private cloud implementation based on Microsoft technologies. Note that this diagram shows only Microsoft core technologies – partner offerings are available to address the additional capabilities. From this technology view, you can then move on to the infrastructure and network views, which shows the hardware, software and network components that make up the private cloud design. For prescriptive guidance on these aspects of private cloud technology, see Microsoft Private Cloud Fast Track, at http://www.microsoft.com/en-us/server-cloud/private-cloud/hyperv-cloud-fast-track.aspx.
- Intro to the domains covered in the Private Cloud Security Model
- The private cloud security model uses the same design as the private cloud reference model but replaces the capabilities with mechanisms for implementing security. This figure shows how these mechanisms tie in to the different layers of the private cloud reference model.
- The biggest risk to running in a virtualized, multi-tenancy environment is that code running on 1 tenant’s virtual machine can interact with processes, memory or data belonging to another virtual machine, or that of the host server itself. So we are going to take a high-level look at the architecture of the Hyper-V hypervisor, and how it is used to mitigate that threat.This slide shows a standard, non-virtualized version of Windows. The kernel and kernel-mode drivers are run in the highly privileged ring 0 processor mode and user processes are run in the least privileged ring 3.When Hyper-V is installed, the hypervisor is inserted into the software stack below the Windows kernel to virtualize the underlying physical resources. While there is no such thing as “ring -1”, the diagram illustrates that the hypervisor is running in an even more privileged state than the kernel and device drivers in ring 0. Hyper-V implements a Microkernel hypervisor that minimizes the size of the trusted computing base and hence the potential for security-related flaws. At ~600 KB in size, only the minimum required set of functions are implemented in the critical hypervisor layer, and all other virtualization functionality is pushed up into the less privileged ring 3.An instance of Windows Server “core” exists in what is known as the root partition and is responsible for mediating the access of all virtual machines to physical resources via the hypervisor. A “core” installation is an implementation of Windows that has no user shell and none of the user mode applications associated with a full installation of Windows – all you have is a command-prompt interface as well as a set of powerful management interfaces that can be used by remote tools. By removing all of this functionality from the deployment, the attack surface is dramatically reduced and servicing requirements such as patching are significantly reduced.Also in the root partition but up in the least privileged ring 3 is the virtualization stack and worker processes that manage all of the virtual machines.Each virtual machine is run in a dedicated Guest partition and serviced by a unique worker process in the virtualization stack. It has its own operating system – whether that be a Windows server version, Windows client version, Linux system, or any other supported platform.And for every guest partition that gets created, a new worker process is created that is dedicated to managing that virtual machine. By running each virtual machine as a separate worker process in ring 3, a misbehaving process cannot affect the stability of the remaining worker processes.Each partition also has a dedicated VMBus channel through which requests for physical resources like CPU, network and storage devices are mediated via kernel-mode drivers. So in this architecture, there is no common communication channel shared by guest partitions.The hypervisor provides:SeparationUnique hypervisor resource pools per guestSeparate worker processes per guestGuest-to-parent communications over unique channelsNon-interferenceGuests cannot affect the contents of other guests, parent, hypervisorGuest computations protected from other guestsGuest-to-guest communications not allowed through VM interfacesMemory, registers, and caches scrubbed on VM context switchAll of these capabilities speak to the key issue of isolation when running a private cloud. Each workload needs to be isolated at all levels from each other workloads, and any connectivity or sharing of resources must be explicitly configured and must have a strong justification for such configuration before enabling the connectivity.
- So we have seen the microkernel hypervisor implemented by Hyper-V, lets have a look at the Monolithic hypervisor architecture implemented by other virtualization platforms.In a Monolithic hypervisor, the virtualization stack and third-party drivers run inside the privileged hypervisor layer. The more code (and in particular third-party code such as device drivers) that is run, the more potential exists for a flaw to undermine the security or reliability of the hypervisor.By putting all of this code – especially third party code into their hypervisor, the harder it is to perform security verification on it and the more opportunity exists that a security flaw could undermine the isolation and non-interference enforced by the hypervisor. So every time a new driver is released to support the monolithic hypervisor, a new opportunity is presented that an undetected flaw can threaten the security of the solution.This is echoed by a quote from Linus Torvalds who pioneered Linux and is the architect of the Linux kernel.
- The final layer of security controls that we are going to look at is those at the network layer. In a private cloud environment, we are going to be transferring traffic from multiple tenants over the same shared network infrastructure, as well as management and monitoring traffic for the hosting infrastructure. It is therefore critical that we can achieve an appropriate level of traffic isolation so that one tenants traffic is never exposed to another, and the management traffic that is so critical to the operation of the infrastructure is logically isolated from all tenants.Physical network adapters on the hosts can be dedicated to the root partition to prevent any network connectivity between the host and the guests that run on it. Additionally, you can use 802.1Q (VLAN tagging) to enable traffic from individual VMs to be isolated on individual VLANs – even if they share a physical network adapter in the host. In the future, we envision that all guest traffic will move through a single interface, and all management traffic will move through separate adapters or be consolidated into a single management interface and have appropriate VLAN tagging and QoS policies applied.802.1Q (VLAN Tagging) is an IEEE standard to allow multiple entities to securely share a single network medium. The switch that a host is connected to tags frames as corresponding to a VLAN, and all compatible network devices between that switch and the frames destination honor the VLAN ID and maintain separation of the traffic from other VLANs. The virtualization platform can then play the role of the edge switch, adding VLAN tags appropriate for the connected virtual machines to allow traffic to be properly isolated.The diagram shows different types of traffic isolated on 4 or more VLANs, using dedicated physical adapters or shared adapters and VLAN tagging (or a mix of both). For example, the host may have dedicated adapters for each of the 3 types of management traffic, and share 1 or more adapters between guests. Related guests would be assigned a common VLAN ID (to allow them to communicate), which will be maintained regardless of which physical host in the cluster the VMs are hosted on.Any traffic that must traverse between VLANs must pass through a firewall, and be subjected to the access control policy defined there.
- VLAN enforcement and access control between VLANs is used to control network traffic at the network layer. Following the principle of defence in depth, these controls are supplemented on individual hosts to guard against compromise or misconfiguration of network security and provide greater granularity in managing access.A host-based firewall is enabled on every virtualization host server, management system and tenant VM with the following requirements:Block all inbound connections except those explicitly allowed. Those inbound connections that are required can be filtered at the IP and port level, or a remote host may be required to authenticate at the network level (using AuthN systems such as Kerberos or certificates) before it can establish a connection (IPsec is used to enable the network authentication using AuthIP).Guests are prevented from establishing any connections to the host operating systems or management systems to protect against attack on the hosting platform, and all of the firewall policies can be centrally managed via Active Directory Group Policy.Server and Domain isolation using IPsec can be used to further partition hosts on the network. A common use would be to mandate that hosts authenticate to one another (using Kerberos) before they are allowed to establish connections. Hosts that belong to the domain will be able to authenticate and establish IPsec-protected connections, while rogue hosts will be unable to authenticate and hence will fail to establish connections. IPsec has the added benefit of detecting any modification to traffic, and optionally encrypting any application traffic against interception.
- Learn more about Private Cloud Security architecture by reading the Service Blueprint, Service Design and Service Operations Guides.
- I welcome all of you to take this presentation and re-present it.Lots of speaker’s note to help you.Improve it!Get the word out that before you begin to build your private cloud, you need to understand the core Principles, Concepts and Patterns of successful private clouds.