How do you document/track your permissions
Solution 1:
You need a ticketing system that provides 3 things:
- Timestamp of when permissions were changed (added or removed) for a particular user
- Why they were changed
- Ability to search for these changes
Pretty much all ticketing systems already provide you with #1 in the form of a ticket creation date, modified date, etc. #2 is up to you to document in the ticket. Usually it is an approval e-mail from the resource manager pasted into the ticket saying they can have access (or access should be removed) and what kind. #3 is the most important and depends on the ticketing system, but if you have a system that is not easy to search then your work is cut out for you. If you can just search by the user so that all permission tickets are tied to their contact info in the ticketing system then you are good, otherwise you are essentially documenting your changes into a black hole.
Outside of a ticketing system that can do this to track changes (you mention that you have a basic ticketing system so maybe you need to get a better one that allows for better searching/reporting capability), any application, utility, or script you use will provide a snapshot of permissions only. You are still stuck with the "why?" of who has access to what, which can only be properly documented separately from the application since you'll likely need to capture the original e-mail or other approval text from the resource manager. Once you have that, where do you put it to associate it with the application's results?
Running an app or script to determine current permissions in a file structure also does not provide you with a nice audit trail of permission changes for a user either. You are essentially stuck with a big snapshot of current permissions at a single point in time. When you run it again, you will have another big snapshot of file permissions. Even if you retained the first permissions capture and compared it to the recent capture, and permissions have changed, how do you tie that to the reason for the change? Again, this brings us back to the ticketing system since #s 1,2,and 3 above will all be documented in one place.
Another issue you brought up is permission creep (when a user is reassigned to another permission and no longer needs access to resource X, but retains it anyway, because the fact that they no longer need access to resource X wasn't run by the IT Dept during the transition). The ONLY way to control this is to tell HR or whoever handles employee reassignments that IT needs to be notified when an employee gets reassigned so they can assign and revoke permissions appropriately. That's it. There is no magic application that will tell you a user has access to resource X but shouldn't anymore because their job is now Y. Human notification in some form has to be given to IT when this happens.
Solution 2:
If you already have a ticketing system in place, I'd suggest creating a new group, or tag, etc in your application for these types of requests and have users send in tickets for permission changes. If your ticketing system allows you to forward tickets to other users, or add them into the ticket, add in the required managers and ask for verify. This would allow you to keep a record to cover your work.
As mentioned above, create a security group for every share. In my environment, we would have shares named FIN_Yearly, GEN_Public, MGM_Reports (each dept has its own acronym). Security groups would then be named SG_FIN_YearlyAdmin, SG_FIN_YearlyUser, SG_GEN_PublicAdmin etc. User is read only, Admin is read/write.
From here you could create, for example SG_FinancialsManager; security groups that include other security groups in order to simplify access based on the jobs that they do. We personally do not do this as it muddies up tracking a bit. Rather than checking a share's SG and seeing a bunch of SGs with permissions, we have a list of users instead. Personal preference, really, and will depend on the size of your site. We usually use user templates for managing new users to specific positions.
If your ticketing system allows you to search through previous tickets you're pretty much done. If someone requests you to remove a user's permissions, you can track it. If a user then questions why they no longer have access, you can provide them with the ticket. If a manager asks you who has access to what, printscreen the requested security group.
Solution 3:
There are actually several commercial applications for doing this. The area is sometimes referred to as "Data Governance".
A couple of examples:
Varonis Data Governance Suite
http://www.varonis.com/products/data-governance-suite/index.html
Quest One Identity Manager – Data Governance Edition
http://www.quest.com/identity-manager-data-governance
I don't use these but having researched the topic and seeing a few demos, the scope of what may can be required would explain the marketplace. These applications are very complex, and not inexpensive. Some of them have very sophisticated methods of hooking into storage platforms for tracking access control lists. Even if it is not in your budget, the demos can be useful to get an idea of what an application like this does from a functional perspective.
One observation I had while reviewing this is they typically do not audit at the file level. If they did, there would be no way it would scale up to hundreds of millions or billions of documents. So they typically only track permissions at the directory level.