Suppose an employee Petya leaves the scandal, and you need to make sure that he does not break anything at last. Or Vasya is transferred to another department, and he should not dig anymore in the files of his former unit.

Now the most interesting thing: you need to somehow remember what specific data these comrades had access to, and what should be covered first.

If everything is obvious and simple with access to applications, this is not the case with file resources.

Our corporate file server was a rather sad sight. On the one hand, the volume of data accumulated over the years, and on the other, the heritage in the form of nowhere recorded access rights granted by previous generations of administrators. All this happened before the introduction of the system of applications for access and quickly did not understand.

At that time, we looked at several programs to collect information about access rights. But they were processing tons of file server data for a very long time, and the generated reports required an additional file modification.

Here is what we tried:

• Sysinternals AccessEnum (Freeware)

  
  

• Netwrix Change Notifier for File Servers (Freeware)

  
  

• Netwrix Auditor for File Servers

  
  

• ScriptLogic Security Explorer

  
  
• Auditor 1 XP

As a result, a script was written on Powershell to collect data through Get-Acl and then automatically generate a report using the form agreed with the security service. But a number of drawbacks immediately surfaced:

• It is too inconvenient to run the script each time and wait for hours until the access matrix is ​​formed;

  
  

• The option of keeping records in the form of paper applications did not fit. Mainly due to the lack of an automatic search mechanism;

  
  
• The use of different systems for accounting is fraught with additional work on periodic verification and updating of data.

The best solution was the organization of a structured system of access based on resource groups.

About resource groups

Usually, administrators use two methods of providing access:

1. Directly to the user account. If you do not keep a detailed protocol for assigning rights, then confusion will quickly arise;

   
   
2. Rights to the role-based group. The same drawback as in the previous case. Moreover, without the rights assignment protocol, it is difficult to understand whether a particular group is being used by someone or can be deleted.

As an alternative and more convenient option, you can use the model of resource groups. These are common security groups that meet the following requirements:

• Grant access rights to only one network resource or subdirectory, which may have several access groups with different rights;

  
  

• Can be nested;

  
  
• If necessary, provide rights only to directories. It is advisable to avoid assigning rights to individual files.

Violation of these requirements will destroy the whole concept of a structured access system.

Dig a little deeper

At first glance, the access system based on resource groups is redundant and requires additional manipulations when creating shared network resources and subdirectories with their own rights. But all this is offset by the simplicity of rights management and the ability to delegate authority to responsible employees without administrative rights on the server or in the domain.

Over the years of using such a system, I have never regretted the time spent on preparation. Now you can at any time look at the user's membership in groups and immediately determine where he has access.

The structured access system is focused on Windows file servers, but can easily be adapted to other operating systems.

A structured access system based on resource groups is not a variation on the topic of role-based access, but its important element.

How are the "passes" issued?

Access to a shared network resource or subdirectory is provided only to the corresponding resource groups - local "Administrators" and "System". Each shared directory should be treated as the root of a tree, in which all accesses are inherited by subdirectories from the parent folder. Access rights to a subdirectory can be granted regardless of the rights to the parent directory. I will illustrate the main ideas on the example of my own server and its folder structure.

If it is necessary to disable inheritance at some sub-level or set access prohibition, this means that from the point of view of information security, the directory structure is selected incorrectly. Restricted access information should not be placed on a resource with wider access due to the risk of its being compromised.

The depth of the directory attachments on the file server can be arbitrary. But if it is often necessary to issue rights to subdirectories below levels 3–5, then such a structure will become overloaded and will require optimization.

The name of the new file server is "FILESRV1". On the file server in the root of the disk for data created a directory named “Shares”. Inheritance of access rights from the parent directory is disabled and access is restricted.

The shared directories will only be created in the Shares folder. The name of such a directory must match the corresponding name of the file share - for example, “Public”.

For the orderly placement of data in Active Directory, a structure of organizational units "... \ Groups \ Shares ..." has been created. Organizational units are created for each file server and file share. Organizational units are not created for subdirectories.

For example, I created the following resource groups:

• FILESRV1-Public

  
  

• FILESRV1-Public-R

  
  

• FILESRV1-Public-W

  
  

• FILESRV1-Public-News-2016-R

  
  
• FILESRV1-Public-News-2016-W

The last two are needed to provide individual employees with expanded rights to the "2016" catalog.

Now you need to include all this in the group "FILESRV1-Public"

A couple of words about the choice of names

Security groups are created in the organizational unit with the name of the file share:

• "server_name-share_file_name" to browse the directory tree without access to the data;

  
  

• "server_name-share_file_name-R" for read access to the data;

  
  
• "servername_name shared file-share-W" for data access with read and write permissions.

These groups are required for all file shares; in the field "description" you should indicate the real network path.

If you need to grant permissions starting with the name of the subdirectory, then two security groups are created in the organizational unit of the file share:

• "server_name_name_file_resource_name-chain_name_divided_r-R"

  
  
• "server_name_name_file_resource_name-chain_name_divided_wire-W"

When issuing permissions other than “ read only ” or “ read and write ”, use a different letter instead of the “R” or “W” suffix. Security groups with special rights are created only for those directories where it is really necessary.

The proposed rules for naming resource groups make it possible, by their names, to determine the directory to which access is granted. Created groups should be included in the general group with the rights only to browse the directory tree.

In order to provide access over the network, it is better to issue the rights to shared resources to the "Authenticated Users" group, but you can also use “Domain Users” or “Everyone”. Permissions at the file system level do not allow unauthorized access to data without explicit permission.

At the file system level, the "Public" directory has appropriate access rights for groups.

Similarly set access rights for the catalog "2016"

No additional actions are required with the "News" catalog.

Now members of the “FILESRV1-Public-News-2016-R” and “FILESRV1-Public-News-2016-W” groups will have access only to the “2016” folder, and users from “FILESRV1-Public-R” and “FILESRV1-Public -W ”- to the shared network resource“ \ FILESRV1 \ Public ”and all its subdirectories.

What is the result

Of course, when creating resources, a lot of time is spent on preparation, but we get the following advantages:

• We exempt ourselves from the constant work of providing access through the delegation of these functions to responsible employees;

  
  
• We can see at any time what rights and to which folders the user has.

Even if now your file server looks more like a big USB flash drive, then in 2 - 3 years it may well turn into a traditional file dump with all the attendant problems.

If you know simpler methods of organizing and controlling access rights - be sure to share your experience in the comments.