Data Storage in Identity and Access Management Systems

Data Storage in Identity and Access Management Systems is important to consider.  Unfortunately, some Cloud Identity and Access Management (IAM) systems have had some problematic security breaches lately.  The way the world is trending, these kinds of problems may get worse before they get better.  In my last post, I talked about how some data might better belong behind your firewall.

IAM Systems:  Do They Need to Store Data?

Even with your IAM system behind the firewall, it’s important what these systems store.  Security concerns have prompted several discussions with our prospective customers about what kind of data our software solutions store.  Does PeoplePlatform attempt to replicate Active Directory in some way and store user and group data in an intermediate database?  The answer to that question is “no” except in cases where administrators want to opt-in to certain kinds of functionality.  (This is discussed in the last section.)

For example, you might use PeoplePlatform to keep your system of record in sync with your directory.  For a school, this system of record might be a Student Information System or SIS.  PeoplePlatform doesn’t need to store data to do this.  This includes logic to provision users and groups, update them when appropriate, and de-provision them.  Our engineering and design teams have made an effort to allow users to do as much as possible without storing data unnecessarily.

What’s the Problem with Storing Data?

There isn’t an inherent problem in storing data in an additional repository except that with redundancy you provide another entry for hackers.  Hardening a database against attacks takes time and money.  These efforts could be better spent elsewhere.

Compliance with security standards is also important.  Our Health Care customers, for example, must consider HIPAA.  HIPAA mandates that some patient data doesn’t get stored at all.

When is it Appropriate to Store Data?

Some administrators may choose to opt in to use functionality that requires storing some data.  For example, you can create workflows in PeoplePlatform which store references to records in Active Directory.  In this case, the software will store a temporary reference to the directory object along with the future task.  Here a reference to an Active Directory object is stored; none of the attributes on the object itself need to be stored.

Another case where data might get stored is when administrators opt-in to have a complete audit trail of everything this has been done to their directory.  This again involves storing information about what has changed.  Even this can be accomplished without centralized database storage using email notifications.

In general, it’s good practice not to store data redundantly if it’s not necessary.