GDPR for IT – Documentation and Access Control
These days we are all busy securing our GDPR compliance, and most likely you and your colleagues are all in one way or another involved in, or affected by, GDPR related projects. These projects should all be successfully delivered by this coming May 2018. If you are already at home, congratulations on a job well done! But you’re not really done… 😉
To this day, our industry still has plenty of manual routines, and with it comes errors and mistakes. This post can help you with some of the auditing needed to be done from an IT Operations perspective in order to meet GDPR compliance by May. But most importantly; it will show you how to build dynamically updating IT documentation to keep at hand onward!
The critical part of GDPR is not really about meeting compliance in time. For IT Operations, focus will have to be on constantly maintaining a high level of control over things like access rights and storage of certain types of data. The main concern is minimizing the risk for errors and mistakes, and identifying them quickly should they come along. Now for THIS, vScope is an (almost) fix it for you kind of product! Let’s have a look at some of the things we can do for you!
Requirements for this tutorial
- The environment in focus for this analysis is a Microsoft environment set up with standard solutions for access control
- In order to follow this tutorial you will need a vScope Directory subscription or to be running a trial license
- The screenshots in this tutorial are from a vScope with all products licensed
Pt. 1 – Users
If you are in IT Operations, a lot of your efforts related to GDPR compliance will be going into access control. You will want to get as clear a view as possible of who has access to what. This section deals with the Who’s, more specifically being your users. Now, when we go out searching our environments for user accounts, we are going to end up with a few different types of those objects. In order to take the next step and investigate what they have access to, we need to start with getting our different types of users in order.
The table User Accounts (found directly under Table Explorer -> New Table) is the place to start out. In the following posts, you will be seeing screenshots from a server environment, but you can go right ahead and just apply this method to your clients as well.
We’ll start out just creating a simple overview of your active accounts. Using the column selector, open up the tag Active, and set the filtering to True.
Tip#1 Filtering can be done in a number of ways. Two easy options are to either right click a value in a field and choosing a filtering option, or searching for the tag in the filter panel to the right and using the check boxes.
These should be the user accounts needed to operate your environment. We’ll take a closer look at them by filtering out the domain accounts and the local accounts. Open up the tag Type. First, filter out Type = Domain and save that list as Domain Accounts. Then change your filtering to Type = Local, and save that list as Local Accounts.
Identifying inactive users
Regardless if you are auditing for GDPR, PCI, SOX or just to stay on top of your licensing, a good general rule is to keep track of any accounts not in use for 30 days. From both your Domain Accounts- and your Local Accounts list, run a check for inactives using the tag “Time since last login”. Set a range filter to 30d – .
Tip#2 You don’t have to open up a tag from the column selector in order to filter it. Keep your views clean by only opening up the columns you need to see, and keep the rest of the filtering to the filter panel.
Are the resulting accounts to be kept in use? Make some notes in the note field on their property pages (for example “parental leave”). This will come in handy in case of audit, when you might be asked to supply explanations for non-disabled inactives. The rest of the inactives? Save those lists, and name them Inactive Domain Accounts/Local Accounts – 30 days.
In your Active Directory, you might want to move the inactive domain accounts to a separate OU marked “Inactive – 30 days”. Then you can leave them there in a disabled state for some time, making sure no one misses them, before finally removing all access groups and moving them to a Disabled Users OU.
Identifying accounts with elevated permissions
In any type of IT audit situation where you are looking at access to data, you will want to review your elevated permissions accounts. One quick check has been built into Table Explorer with the help of the tag Domain Admin = True/False. Try opening that tag up from a new User Accounts table. Are things looking good? If not, make changes to the membership of your AD group Domain Administrators.
Elevated permissions can be a real trickster to deal with! This was a quick example of an obvious check to perform. However, an environment with a mixture of local and domain users and groups can have long chains of permission sharing through nesting. We will be going deeper into that in the next GDPR post about Groups and Resources.
Put a tracker on it
The above table provides you with a fast way to present IT documentation over the members of your AD Domain Administrators-group. But do you know what’s even better than having a glimpse at that table every now and then? Automated tracking of changes in the group membership!
Turn your table into a tracker, by clicking “Save” and choosing “Save as tracker case”.
This tracker will notify you whenever the vScope scan catches changes to the AD group Domain Administrators. Edit your tracker according to your preferences. In this example, I set it to a warning and wrote a suggestion to review the list. I also added some interest categories. That way, anyone who has a profile set up with those interests will automatically see my new tracker in their tracker view, and can choose to follow it. I can also share my new tracker with some of my colleagues right away, in case I want to bring special attention to it.
Do you want to do more tracking on the same resource? Try adding a new column directly from a tracker you are editing. Let’s try “Email”. Generally speaking, from a security perspective it is not recommended to have domain admin accounts mail enabled, so this is a good analysis to run. Now, let’s use a slightly more advanced tracking method. See the CHANGE element? Set it to “Email” has “Changed”. This way, any changes to email addresses linked to domain admin-accounts will render you a notification. Neat, isn’t it?
Don’t forget to “Save as…” otherwise your previously constructed tracker will be re saved with changes.
Click here to learn more about working with Tracker
Recap: Results of GDPR User Account analysis
So, now we have lists of all your active accounts, and for those that possibly should be disabled. Those lists equal constantly up to date documentation for when those auditors come a-knocking, or for that true-up that’s always lurking around the corner (or for when you just want to give yourself a pat on the shoulder for keeping you AD so neat! Good job, You!). On top of that, you’ve made some notes and tagging that contribute to your contingency strategy and disaster recovery plan.
Now don’t keep all your newfound knowledge to yourself! Remember that the tables you save can be shared with other parties in your organization (just click Collaborators). As a minimum, they need to be members of the limited vScope group Viewers. So make sure they have a vScope account (Learn how to integrate vScope with your directory service).
This guide will help you achieve expert level in external reporting with vScope in no time!
The result in bullets
- List of active domain users
- List of inactive domain accounts
- List of active local users
- List of inactive local accounts
- Tracking of changes to the group Domain Administrators
- Tracking of mail enabled Domain Administrator accounts
- Improved documentation regarding access control.
- Improved documentation regarding accounts with elevated permission.
In Pt. 2 of this GDPR series, we will have a look at group membership and resources. Get prepared by opening up a new table for the resource type User Groups.