With private cloud environments, you have three options for client security:

• Secure trusted client. A secure trusted client one that exists on the internal network and has a security trust relationship with the cloud domain. You would provide appropriate levels of protection to these client computers by using anti-virus protection, two-factor authentication, hardware computer security, and integral data protection. Connections to the private cloud network must be made over a protected communications channel with a quarantine process to ensure that the client computer has the latest security updates, anti-virus definitions, personal firewall enabled and so on before being allowed to access the service endpoints.
• Insecure untrusted client. Here, you do not trust the client computers at all and assume that every input that you receive from the client is suspect. You then check the input for type, range, length, and format. Your application design ensures that no sensitive data is stored locally on the client, which can be a desktop, tablet, mobile device, or even a browser on a public kiosk computer.
• Secure untrusted client. With this option, you provide as much local security as possible to the client as with the secure trusted client example. However, you do not set up any form of inherent trust relationship between the client and the cloud environment, as would be explicit with domain membership. Authentication would be through federation and your cloud-based applications would treat all client input as suspect and thoroughly check this information before accepting it.

The option for insecure trusted client is not considered further for obvious reasons.

An example of a secure untrusted client would be a laptop with integrated disk encryption, either hardware or software-based. It would require two-factor authentication to log on, using either a smart card or fingerprint recognition and would not be domain-joined. Authentication to the cloud service would also be two-factor and the device might include a geographic locating device to assist with recovery in case of theft.

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

One area that may change with private and hybrid cloud implementations is domain membership, which is no longer a pre-requisite if the client uses federated authentication to identify themselves to cloud –based applications using the cloud directory service as their home realm. It should be noted that implementing federated authentication on a standalone computer rather than adding that computer to the domain changes the profile of network services available to the clients.

In reality, most organizations running private cloud environments will probably attempt to secure their client computers as much as possible. However, as previously discussed, if an attacker can gain physical possession of a hardware device, your attempts to protect the data on it must be extremely effective and render the stored data functionally inaccessible. There must certainly be no inherent degradation of the security of your private cloud environment if a client computer is stolen and compromised. And if a client computer is stolen and compromised, the effects of this compromise on your environment must be carefully assessed.

Unfortunately, the only person who is likely to know the difference between a stolen laptop and a stolen and compromised one will be the attacker. In consequence, you must either be absolutely sure that a stolen client laptop is as close to an inert lump of plastic and metal from the attacker’s perspective or that you can rapidly make any changes to your own environment that may be required (for example, reissuing trusted root certificates and revoking ones on the stolen equipment) resulting from the possible compromise.