Best Practices to Secure the Cloud with Identity Management

Authored by: Dan Dagnall, Director of Pre-Sales Engineering at Fischer International Identity   What is the “cloud identity?”   The “cloud identity” begins at the birth of the user’s “digital identity” and includes the attributes to define “who you are.”  “Cloud Identity” is not a new term to those in the industry, but one that has definitely taken hold as the way to define “you” in the cloud.  Much focus has been on how to “enable” a secure authentication event (through mechanisms like ADFS or Shibboleth), which is a key component of securing the transaction between Identity Providers (“IdP”) and Service Providers (“SP”). However, too little focus has been placed on the fundamental component required to “ensure” the integrity of the transaction; and by “integrity,” I mean that the person is right, the attributes are right, and the values are right  The integrity of a “cloud identity” transaction can only be secured by sound identity management practices, with a razor-sharp focus on attribute management and policy enforcement.   Competent attribute management is the foundation of securing the “cloud identity.”  It is the attribute and its corresponding value that ultimately determine the digital identity of an individual (or entity).  When you consider the level of accuracy required (if your true goal is the validity of the transaction) in a cloud-centric world, you will concede the importance of properly representing the user in the cloud.  When you consider attributes within this context, it becomes clear why identity management (IdM\) is the epicenter for securing the cloud identity.   Attribute management is much more than “just a middleware component;” it is identity management at a fundamental level.  This fundamental level must not be overlooked as our industry begins discussing the large scale initiatives to create a common “ecosystem” through which cloud identities will travel.   There are a few key components of the IdM stack that provide for the integrity I’m describing; automation and policy management/enforcement.   Best Practice #1: Automation Sound identity management practices must include automation, which includes event detection and downstream provisioning (i.e. the system automatically detects when a user, along with data associated to the user, is added/modified within the system of record, followed by automatically provisioning the user and the required attributes to downstream systems). Detection of changes to key attributes specific to the user’s identity [ideally, in real time] ensures the validity of the attribute value, i.e. making sure the value is correct and placed in the proper location and that placement was/is authorized.   Manual modification of users (on downstream target systems) including manual entry of attribute/value pairs is not a secure approach unless identity management has authorized these actions and the user performing them.  Manual approaches can undermine data integrity and leave the user (whose identity and sensitive information will be floating around the cloud) at a major disadvantage and lead to improper representation of their identity in the cloud, not to mention the inherent risk for the user and the organization as a whole.  This represents a scary reality for some, unless of course IdM has been properly deployed to ensure that malicious events are either immediately detected or thwarted before-hand.   Automated event detection eliminates the need for manual interactions with the user’s attribute set, which as I’ve discussed is the single-most important aspect of securing one’s identity in the cloud.  Automated event detection when coupled with attribute management enables the proper enforcement of organizational policies put in place to protect the user.   Best Practice #2: Policy Management & Enforcement Once automation is introduced, securing the remaining aspects of the cloud identity shifts to policy management and enforcement.  Policy management is the layer of IdM which defines who is authorized and what level of access will be granted to downstream target systems.  Whether bound by regulation (which is most often the case) or the requirement to comply with a set of standards and/or practices to participate in global federations (i.e. attribute management processes that meet a certain criteria), policy definition is the key to successfully securing the cloud identity.   Securing this layer cannot be accomplished by allowing unchecked “human” decisions to overrule the policy because it can have a direct effect on how that user is represented in the cloud.  As a user, I’d sleep much better knowing that automated policy enforcement is managing my cloud identity, and abiding by organizational or regulatory guidelines like CSA and others to keep my identity safe and properly represented in the cloud.   In conclusion, someone with direct access to my data (because there is no automation), who can manipulate my attribute values without authorization (because there is no policy definition and enforcement), could compromise the representation of my “cloud identity” and call into question the integrity of the entire transaction. So before you consider cloud-based transactions, specifically those where identity data is required, it is in your best interest to solidify your IdM practices and introduce the components I’ve outlined.  Only then can you truly secure the cloud for your users and your organization.