by Brian Vecci
In my recent post, Improving Authorization with Metadata, we talked about what kinds of information we need in order to start cleaning up access control. This time I want to talk a little bit about how we’ll actually get that metadata and what it will take to use it to do anything useful.
If you recall, the metadata streams we’re going to be primarily concerned with are user and group information, permissions from the ACLs and user access activity. In addition, data classification can help us prioritize the work by finding important data (and when combined with the other metadata streams) that are located and might have excessive or broken permissions. So where does all this metadata come from?
The simple answer is that there’s no simple answer. Each platform is going to have its own interfaces and challenges when it comes to gathering this data. In the Windows world, for instance, in order to see who has access to a folder, or what folders a user has access to you’ll need to traverse each file system to get the permissions—every folder might have a unique ACL. In order to interpret the ACL’s, you’ll need to grab the users and groups from Active Directory, as well as the local groups on the servers, some of which will contain groups in AD. And that’s just NTFS Permissions—you also need to consider Windows Share Permissions, and the effective permissions a user might have based on both.
SharePoint permissions are complex, too. SharePoint objects have access control lists that refer to Active Directory users and groups and SharePoint groups, and each group is assigned one or more permission levels on the object, and each permission level is comprised of some combination of 33 individual permissions.
That’s interesting to compare with permissions on an Exchange mailbox, where access can be set at the server (mailbox permissions) and by the client through Outlook (sharing permissions). On top of that, think of all the actions you can perform within Exchange once you factor in message flagging and attachments.
UNIX file systems have NFS style permissions as well as POSIX ACLS, all of which can refer to local groups and users, and those in LDAP, NIS, or even Active Directory groups if you’re using an AD integration product like Centrify. NAS devices often have CIFS/NTFS style permissions, NFS permissions, and hybrid permissions modes to serve both CIFS and NFS clients on the same share.
As you can see, each of these platforms has its own idiosyncrasies, and we haven’t yet mentioned symbolic links, junction points, or DFS. And… this is just to see who has access. Who is actually accessing data is even trickier—we’ll talk about that in a future post.
On top of all that, think about the sheer amount of metadata you may be collecting—thousands of users in thousands of groups across hundreds of thousands of ACLs, that must be gathered carefully enough so it won’t significantly impact the environment, otherwise what’s the point? If monitoring the box is going to break the box, no one will do it. What this all means is that gathering up all of the relevant information across all the platforms you want to properly govern is no simple task, and analyzing and making sense of all the metadata is even harder—it requires a lot of platform expertise, and technology that is flexible and robust enough to handle the deep waters of today’s diverse file systems.
For further information please contact C24 at http://www.c24.co.uk