Good Rules for Permission Design on File Servers
I want to share the experience of designing permissions on file servers. In theory and practice, both Unix and Windows (as the two most popular platforms) provide enough tools and capabilities to assign permissions to objects on file servers. This is quite an ordinary task when you have up to hundreds of users, a couple of servers, and only a few levels of the directory tree. With the increase in the number of servers, the number of directories, and there are much more users in such companies, an unpleasant circumstance appears - the costs of supporting the infrastructure for sharing files (time and staff) are rising sharply. In this topic, I would like to talk about the basic requirements for the design of the file sharing service, which will make it easier to simplify support and reduce its costs. I note in advance that we don’t touch the very process of maintaining servers (hardware, file systems and operating systems) and the content of objects (content types), but consider only the design of the shared access structure.
We describe the conditions for the strata which we will consider as an example and a real application.
Available at the moment:
The geographical location of servers, users, network infrastructure does not matter much for this situation.
As a result of using such an infrastructure for a couple of years, changing several system administrators, regularly assigning special permissions to directories (goals are not important) at the request of users, even with careful documentation, following the process of making changes and keeping track of changes in the infrastructure on such servers there is a mess in the directory permissions. A typical manifestation of confusion: it is necessary to understand why Olga Ivanova, a user (translator for example), has access to a catalog with financial information, and can also edit it to the same. We open directory permissions, model effective access permissions for this user, and see that she can even breed butterflies there, although judging by the group membership two levels higher there shouldn’t be any. The question arises: how is this situation? Surely the reason is the inheritance of permissions, although there may also be any special permissions that are not visible at first glance. There may be a reverse situation when a user cannot access documents that he needs to edit, and here it is already necessary to spend, as a rule, much more time to search for causes and correct errors. All this leads to a great investment of time, which in fact could have been avoided with proper planning and compliance with the design.
')
What can be offered as a solution to this situation (as we shall see later on and most of the other ones that occur on file servers). For a start, this is design development for file sharing infrastructure. The design should consist of a document describing at least the following areas:
I want to dwell on the requirements for the logical structure and access permissions, the description of the remaining sections of the design refers to the field of service management and is beyond the scope of this topic.
The main recommendations to avoid many errors with the support of the service:
Particular attention with the support of file sharing should be paid to the last three points, because the violation of any of them greatly complicates the investigation of incidents and the further design and development of the service. Any necessary actions with access resolutions can be performed within the last three points.
Compliance with these rules makes your sharing service scalable, understandable to any engineer, more secure. The main result will be a clear reduction in the cost of maintaining the service and reducing some of the risks.
The remaining sections of design (goals, risks, roles, links with other policies) in this case are no less important for optimal and successful design, implementation and support of the service. From which follows the need to pay them no less attention than to design permissions or to maintain order in the directory structure.
In order to avoid a holivar regarding paragraph 10. I want to immediately add that any prohibition of access can be replaced with properly designed permissions. Using “Deny Access” makes it very difficult to investigate incidents at high levels of nesting, but at small levels it can also be a lot of trouble. Accordingly, the use of inheritance and only permitting sets of access rights gives confidence in the transparent mechanism of inheritance and that nowhere between several levels is nothing hidden from you.
With ABE you need to be very careful and remember about its presence, otherwise there will be a lot of confusion when investigating incidents.
We describe the conditions for the strata which we will consider as an example and a real application.
Available at the moment:
- The five main file sharing servers
- More than five levels of nesting on each server
- More than 500 directories on each server
- More than 10 thousand files on each server
- Over 300 users
The geographical location of servers, users, network infrastructure does not matter much for this situation.
As a result of using such an infrastructure for a couple of years, changing several system administrators, regularly assigning special permissions to directories (goals are not important) at the request of users, even with careful documentation, following the process of making changes and keeping track of changes in the infrastructure on such servers there is a mess in the directory permissions. A typical manifestation of confusion: it is necessary to understand why Olga Ivanova, a user (translator for example), has access to a catalog with financial information, and can also edit it to the same. We open directory permissions, model effective access permissions for this user, and see that she can even breed butterflies there, although judging by the group membership two levels higher there shouldn’t be any. The question arises: how is this situation? Surely the reason is the inheritance of permissions, although there may also be any special permissions that are not visible at first glance. There may be a reverse situation when a user cannot access documents that he needs to edit, and here it is already necessary to spend, as a rule, much more time to search for causes and correct errors. All this leads to a great investment of time, which in fact could have been avoided with proper planning and compliance with the design.
')
What can be offered as a solution to this situation (as we shall see later on and most of the other ones that occur on file servers). For a start, this is design development for file sharing infrastructure. The design should consist of a document describing at least the following areas:
- target
- the benefit that will bring compliance with this policy
- application area
- requirements for the logical structure of file access
- access permissions for shared objects
- roles that are needed / will be involved in the design, implementation, support of this infrastructure
- risks in implementing and maintaining infrastructure
- the main problems that may be in the design, implementation, support
- links to any other policies, agreements, contracts that may affect the design, implementation and support of the file sharing service
I want to dwell on the requirements for the logical structure and access permissions, the description of the remaining sections of the design refers to the field of service management and is beyond the scope of this topic.
The main recommendations to avoid many errors with the support of the service:
- For a logical directory tree structure, it’s best to use a single design on all servers.
- On all servers it is recommended to use the same entry point to directories (root level)
- All directories that should have special access rights should have their own groups for users who need access to this directory.
- To provide access to directories, it is recommended to use separate user groups that should be placed in a separate container from other groups.
- All access groups must have a single predefined naming design.
- Permissions for directories can be issued only through the inclusion of members in a group that corresponds to this directory (never directly to an individual user)
- When setting permissions for a newly created directory, all system non-inheritable access groups should be deleted.
- Permission inheritance must be enabled starting from the root directory (root level) and must not be disabled under any circumstances.
- Access to objects can be granted only by granting two basic sets of rights — to read (read the list of objects, read permissions, read contents) and to change (read rights + change contents, delete files and directories, create files and directories). In some cases, you can use special groups (a separate type of groups) that can provide only the necessary part of the two main complete sets of access rights
- It is forbidden to use "deny access" (deny of access) under any circumstances
- It is recommended to use ABE if necessary to hide unnecessary directories from the eyes or, if necessary, not only to deny access, but also, to the extent possible, to ensure the appearance of their absence.
Particular attention with the support of file sharing should be paid to the last three points, because the violation of any of them greatly complicates the investigation of incidents and the further design and development of the service. Any necessary actions with access resolutions can be performed within the last three points.
Compliance with these rules makes your sharing service scalable, understandable to any engineer, more secure. The main result will be a clear reduction in the cost of maintaining the service and reducing some of the risks.
PS
The remaining sections of design (goals, risks, roles, links with other policies) in this case are no less important for optimal and successful design, implementation and support of the service. From which follows the need to pay them no less attention than to design permissions or to maintain order in the directory structure.
In order to avoid a holivar regarding paragraph 10. I want to immediately add that any prohibition of access can be replaced with properly designed permissions. Using “Deny Access” makes it very difficult to investigate incidents at high levels of nesting, but at small levels it can also be a lot of trouble. Accordingly, the use of inheritance and only permitting sets of access rights gives confidence in the transparent mechanism of inheritance and that nowhere between several levels is nothing hidden from you.
With ABE you need to be very careful and remember about its presence, otherwise there will be a lot of confusion when investigating incidents.
Source: https://habr.com/ru/post/118313/
All Articles