When we look at the secure hybrid cloud, there seems to be a missing piece, a piece that is used to validate identity via role based access controls assigned to applications, data, and systems. An identity that allows control of dynamic instead of the normal static firewall rules that are part and parcel of most environments. The software defined data center needs security to move with it and not remain static. Yes we could manipulate the rules on the fly, but those manipulations require that we know who is using a particular VM at a given time and in the case of a server, the VM could be used by more than one user at a time, so we need something more dynamic. Privileged access to data needs to be enforced throughout the stack and not just within an application or by encrypting data. Validating against an identity is a key component of the secure software defined data center and secure hybrid cloud.
Per figure 1, we notice that we enter the hybrid cloud using our end user computing device, but from there can go anywhere, so we need a security tool that understands this motion and works with us. One that is part of the data, the end user computing environment, tied to identity, and controls how we are able to access data.
- Transition – The transitional component of a secure hybrid cloud contains all those items that either allow access to or move data between multiple cloud instances, between those clouds and a data center or centers, and between the end user computing device and clouds and data centers. The transitional component is fairly fluid. Check out these posts:
- Cloud – The cloud includes all those places outside our immediate control where data could end up or be taken from. In some cases, it is even used to further our transitional goals. This is where APIs tend to live.
- Data Center – The data center is generally within our control and could be a private cloud or just a collection of virtual and physical machines. The data center may transfer data between multiple data centers or back and forth to the cloud. Check out these posts:
Validate: Identity
The first part of this puzzle is to validate the identity of the user that is trying to access the data. To do that we need to know three things:
- Location: From where the data is being accessed? Is this location a valid location for total data access, subset, or none at all. In some cases, we may want to ensure data is accessed only from within the confines of our network. Limited access may be granted to those within the country, and no access outside the country.
- Device: From which device was the data being accessed? Is the device a ‘trusted device’, does it contain the proper security measures, or is this an unknown device. Such devices could be mobile devices owned by the company, limited access via BYOD if the appropriate security app is installed, or no access for an unknown device. A device in this context is the ultimate location of the display of the data.
- System: From which system is the data being accessed? Unlike device, there may be an intermediary system in use to access the data, such as a virtual desktop, server, application, process, etc. Are these intermediary systems also validated? Are they allowed to access the data?
- User: Ultimately, the user is either allowed to see the data or not, but a user request flows through all the other components of identity. User is generally a username, password, and groups. But since this is tied to an identity store it behooves us to ensure that the authorizations of the identity store are least privilege. This may take a bit more work to ensure.
Validate: AFORE CypherX
AFORE CypherX brings many of these constructs for validation into one product, except for location or device information. While this would be useful in the future, what CypherX provides, for windows applications, is a way to ensure only a validated user on a validated system can access the encrypted data via validated application. What does this ultimately mean? Security policy rules follow not only the data but the users and how the users access the data via applications. Firewalls and static data protection rules are no longer necessary as the security is built into the validation, encryption, and wraps around the application.
Access to data is only allowed if the system is validated, the application is validated, and the data is validated separately against an Active Directory identity store. Data can only be accessed by distinct users or users in specific groups, the application may only accessed by users in some groups, and the user has access to a superset of groups that may encompass the data and the application as well as the system. In essence, the proper access has to be granted to the user, the system, the application, and finally the data.
What does this imply? Let’s look at a simple example of using an SQL server:
A user logs into their virtual desktop and starts up an application. In order to even start the application, the user must be validated against the CypherX security context of the application and the system. If the user is not validated against both of these then the user cannot even launch the application If the user is validated against the system, but the system is not validated for the application, then the application cannot be launched.
The application security context then controls to where the application can go, to the SQL server. The SQL server also has a CypherX security context around it requiring the application to validate against the SQL server security context. If that works, then the data is accessible to the application.
If furthermore the database to be accessed is on an encrypted share, then the security context of the SQL server is validated against the encrypted share or even file.
Which implies that to access the data, one needs to validate across all these security contexts.
These contexts are managed by the AFORE CypherX management suite and provides a traceable security context throughout the stack. Access requires validation at all levels once the application is launched. In addition, these contexts can be anywhere within your secure hybrid cloud, not just within a single instance: On-Premise, IaaS, PaaS, and to some extent Storage Clouds can be used with AFORE CypherX. AFORE CypherX is a hybrid cloud wide solution.
Closing Thoughts
This is a very useful technology as we can now implement user-centric controls instead of vm-centric controls. The user can be a person, system, application, or filesystem each with their own identity and need to validate their access through the stack. User-centric controls provide a finer grain of control of data access. It however, does not alleviate the need for firewalls, but is an adjunct to them. But it does provide one place to control data access.
However, this implies that the identity store must be properly configured for least privilege and in most cases when there are 1000s of elements in active directory, there is bound to be some issues. So we must control our identity stores as well and fully understand any given user, system, applications, and filesystems access rights. This is where tools from IdentityLogix and Solarwinds may be helpful.
Identity is becoming more and more important for security purposes and we need to start pulling in device and location data to be used in validating access to data.
How do you validate access? Is your security user-centric or vm-centric?