Few things are more important in higher education IT than the security of institutional data. Current technologies, while incredibly useful, also make data more vulnerable to theft, extortion, manipulation, and other sinister activities. This post will discuss not only the importance of protecting your information assets but also the best ways to manage data security within Evisions’ Multiple Application Platform Server (MAPS) and Argos itself.
So, why security is so important? In my opinion, the answer falls into two major categories: theft prevention and legal compliance.
Theft is something we all know about. According to a recent survey by Javelin Strategy & Research, the total number of identity theft victims in the US rose from 10.2 million in 2010 to 12.6 million in 2012. In 2012, more than $20 billion dollars were stolen through cases related to identity theft or fraud. Protecting your students from identity thieves is a critical part of IT’s responsibilities as gatekeepers for institutional data.
The other part of the equation is the legislation governing the protection of personally identifiable information (PII). Wikipedia defines PII as “information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.” This includes things like their SSN or similar ID, DOB, place of birth, VIN numbers, driver’s license numbers, and so on. Restricting access to that information not only reduces the risk of identity theft, but it’s necessary in order to keep your institution in compliance with FERPA and other legislation governing the use and security of student data.
For these reasons, we must continue to be vigilant about the safety of our institutions’ information. When working in MAPS, there are three major security gateways, which we’ll go over in detail:
- Application Authentication (i.e. user accounts, either within MAPS or via an LDAP)
- Application Security (i.e. user access within the application)
- Database Security (i.e. data use and security within the database itself)
The MAPS environment requires users to log in, prior to granting them access to any institutional data. This login can be managed either through the MAP server itself (by creating users with the MAPS configuration tool) or through an LDAP environment, if your institution is using one. User accounts and user groups play an important role in controlling access to PII. End users should have access to the data they need and only the data they need. To keep track of which users need access to what, you’ll need to create user accounts and user groups thoughtfully.
The main thing to remember is to keep your user groups as simple as possible, by using your organizational structures as guidelines. As an example, let’s consider this very simple hierarchy:
For this organizational structure, you’d want to create four user groups, one for each office, and individual user accounts within those groups. As you’ll see later on, managing access within the application is linked directly to the organization of your user groups and accounts. Since access requirements typically vary by job function, it makes good sense to try and mirror your functional groups with your user groups.
Inside the Argos application specifically, data is organized into a folder structure analogous to the folders you have on your computer. For each folder, you can specify which user groups and user accounts have access to the data within. Like your users and groups, the most effective way to organize your folder structure is by business unit. Here is an example of a folder structure for the hierarchy we discussed earlier:
With this structure in place, as you add DataBlocks and Reports to those folders, you can easily assign security to each folder that limits access to the data within. This way folks in HR don’t get to see Finance reports and folks in Admissions don’t see HR data. This not only improves the security of your institution’s PII, but it also improves the user experience—they only see what they need to see. This approach will work really well for the majority of your users. The only exception is Argos’ special group of power users, called DataBlock designers, which we’ll get to in the next step.
For Argos users, database security comes into play primarily for DataBlock Designers. These are the power users who have table access because building DataBlocks requires writing database queries. At this point, security-wise, we have two options: 1) We restrict their access at the database level, or 2) we use clearly communicated security policies and frequent training to make sure they can and do enforce those policies.
In my experience, the second method is the best way to go for several reasons. Most often, the DataBlock Designers are going to be in the IT office. Part of that role, in my opinion, is the expectation that the employee understands the responsibilities that go along with the access they’re given. Even for folks outside IT, it is my experience that anyone who requires the kind of access we’re talking about also has adequate enough skills that policy and training can do the trick. The other advantage to option number two is that it lets your institution avoid a great deal of maintenance effort on the part of the database administrator.
NOTE: If policy and training don’t work for your institution, creating database roles that limit access by functional area will alleviate some of the maintenance burden.
Building security measures into your data infrastructure isn’t particularly difficult or time consuming. With a little bit of planning and forethought, you can establish your MAPS client, Argos file structure, and database access in a way that passively protects your institution’s data. And for your trouble, you’ll be reaping the benefits, when it comes to theft prevention and legal compliance, for years to come.