Private Cloud Security Model - Service Delivery Security
The purpose of the service delivery layer is to make the services in the private cloud environment available to the consumer. The service delivery layer also provideshttp://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-85-24-metablogapi/5658.image_5F00_64BCDD48.png the interface through which consumers can connect. Capabilities that the service delivery layer provides are:
- Service end-points – provides the connection points to the SaaS, PaaS or IaaS hosted services.
- Self-service portal – enables consumers to request cloud resources and to return those resources to the general pool when no longer required.
- Service catalog – lists the services to which consumers can connect.
- Service provisioning – enables consumers to provision virtual machines, development environments, or applications.
- Billing – converts service usage into cost values and dispatches bills automatically.
- Service contracts – publishes and maintains a register of SLAs and operating level agreements (OLAs) for each tenant.
- Metering - accounts for consumers’ usage of cloud resources and sends this information to the billing capability.
- Service reporting – reports on the service levels actually provided and compares these levels to SLAs.
As this layer provides the service connection to the consumer, security is a critical issue with all these capabilities. Figure 1 shows the elements of the service delivery layer that require this security.
Figure 1: Service Delivery Security
As with the software, platform, and infrastructure layers, the security capabilities of IdAM, data protection, security monitoring, security management, authentication, authorization, RBAC and auditing all apply to the service delivery layer.
Connection Security
Connection security is a key element in securing the delivery of services, as consumers will always be accessing these services using a remote network connection. With private cloud environments, this paper has highlighted why you should consider the internal network as an untrusted network alongside the Internet. Hence, all client connections should be treated with the same level of minimal trust.
Establishing a secure connection to a client helps to ensure integrity of the data and makes it more difficult for an attacker to compromise the data stream. Hence, techniques such as TLS/SSL encryption using a minimum of 2048-bit public/private key pairs and 128-bit bulk encryption keys are essential.
Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Solution for Private Cloud is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this document, please include your name and any contact information you wish to share at the bottom of this page
Authentication is also a key requirement, as your private cloud environment should typically not be accepting unauthenticated requests. If you have a public web site that accepts anonymous requests, then this site should be hosted separately by a commercial hosting provider.
Certificates used for TLS/SSL traffic can be third-party or generated automatically by your internal CA. Regardless of the process that you use, clients should have the root certificate stored in their trusted root certification store to prevent error messages on connection. Users should be trained to be immediately suspicious if they receive a certificate error when connecting to a private cloud resource.
Note that if you have implemented an SSL inspection mechanism, then this mechanism can assist by also providing other validations, such as CA authenticity, certificate revocation list (CRL) checking, chaining, and other security tests on the certificate.
Connections from the service delivery layer to the software, platform, or infrastructure layer also need encryption and mutual authentication, typically by use of TLS/SSL or IPsec encryption.
Service End-Point Security
Even though the role of the perimeter network has diminished in private cloud implementations, the point at which the consumer connects to the service delivery layer is still a significant security boundary. Hence, your security defenses should aim to prevent the most common forms of attack from succeeding.
The security techniques of port and protocol restrictions combined with packet inspections, traffic analysis, intrusion detection systems, and honey traps are not unique to private cloud environments; what changes is the degree of automation that is necessary to respond to attacks. Defenses of any kind are useless if they are not actively protected and the increasing threat profile from more sophisticated attacks makes passive defense no longer effective in protecting your environment. Hence your perimeter defenses need to be closely monitored, with immediate follow-up action on any intrusion.
Authentication, authorization, and audit controls must apply at the point of contact. Links to federated identity providers must be secure from tampering or interception.
RESOURCES:
ACKNOWLEDGEMENTS LIST:
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]
Return to Private Cloud Security Model[
Return to Blueprint for A Solution for Private Cloud Security](http://social.technet.microsoft.com/wiki/contents/articles/blueprint-for-a-solution-for-private-cloud-security.aspx)
Return to A Solution for Private Cloud Security
Return to Reference Architecture for Private Cloud
Move forward to Private Cloud Security Model - Management Security
Table of Contents for A Solution for Private Cloud Security