diff --git a/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementBadUserNaming.png b/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementBadUserNaming.png new file mode 100644 index 00000000..12038584 Binary files /dev/null and b/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementBadUserNaming.png differ diff --git a/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementDoNotSetPermissionsOnUserRecord.png b/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementDoNotSetPermissionsOnUserRecord.png new file mode 100644 index 00000000..c3ee811c Binary files /dev/null and b/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementDoNotSetPermissionsOnUserRecord.png differ diff --git a/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementGoodUserNaming.png b/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementGoodUserNaming.png new file mode 100644 index 00000000..96e9794f Binary files /dev/null and b/Documentation/Images/ManualScreenshots/PermissionsManagement/PermissionsManagementGoodUserNaming.png differ diff --git a/Documentation/PermissionsManagement/GeneralRecommendations/Index.rst b/Documentation/PermissionsManagement/GeneralRecommendations/Index.rst new file mode 100644 index 00000000..7fa9dce6 --- /dev/null +++ b/Documentation/PermissionsManagement/GeneralRecommendations/Index.rst @@ -0,0 +1,129 @@ +.. include:: /Includes.rst.txt + +.. index:: backend, acl, permissions, user groups, user management + +.. _general-recommendations: + +======================= +General recommendations +======================= + +Recommendations outlined in this chapter, although not directly focused on +setting permissions in TYPO3, are closely related due to the various security +aspects described. It is advisable to thoroughly review these recommendations +before proceeding to the next chapter, where guidance on establishing top-level +backend groups corresponding to different roles, such as editors, proofreaders, +and others, is explained. + +.. _user-specific-accounts: + +Create user-specific accounts +============================= + +When creating backend users, avoid usage of generic usernames like :samp:`editor`, +:samp:`webmaster`, :samp:`proofreader`, etc. Instead use their real names, +such as :samp:`johndoe`, :samp:`john.doe`, or even their email address, :samp:`john.doe@mail.com`. +This approach guarantees that the identity of the user logging into the TYPO3 +backend is always known, as well as who is responsible for specific changes +in content or configuration. + +In the context of :abbr:`GDPR (General Data Protection Regulation)`, it is recommended +to use properly named accounts to easily distinguish individuals. Assigning top-level +groups to these accounts makes identifying user roles straightforward. + +.. figure:: ../../Images/ManualScreenshots/PermissionsManagement/PermissionsManagementBadUserNaming.png + :alt: Bad username setup + + Bad username setup + +.. figure:: ../../Images/ManualScreenshots/PermissionsManagement/PermissionsManagementGoodUserNaming.png + :alt: Good username setup + + Good username setup + +.. note:: + Avoid generic names for a backend username, instead use their real names. + +.. _ensure-safety: + +How to ensure safety +==================== + +When configuring TYPO3 permissions, begin by granting users only necessary access, +adding more as needed for security. Avoid giving admin rights unless absolutely +necessary, and use specialized accounts for routine tasks like content management. + +For temporary TYPO3 backend access, like for a temp worker or student, +use the feature to set an expiration date on accounts. This prevents security +risks from inactive accounts. Regularly review and remove unnecessary accounts. + +Secure each user account with a strong password and follow +:ref:`secure password guidelines` for new +or updated accounts. Promote cybersecurity by informing users about security policies. +Additionally, enable Multi-factor authentication (MFA) for an extra security layer. + +.. note:: + - Grant users only the access they truly need + - Instead of using administrative accounts, create groups for specific roles, such as editor, and assign these roles to users + - Regularly maintain backend user accounts, removing any that are no longer needed + - Always establish secure passwords for users + +.. _permissions-via-groups: + +Set permissions via groups, not user records +============================================ + +Permissions, like module visibility, language options, and database or file access, +can be configured via backend user records. While direct configuration on user +records may seem convenient, especially for small projects, it can lead +to long-term issues, such as difficulty tracking permission origins when spread +across users and groups. Centralizing permissions in backend groups simplifies their +management and maintenance. + +.. figure:: ../../Images/ManualScreenshots/PermissionsManagement/PermissionsManagementDoNotSetPermissionsOnUserRecord.png + :alt: User record without permissions + + Avoid setting permissions directly through the backend user record + +When permissions are assigned to individual users and groups, updating them +requires editing each account. Setting permissions at the group level +simplifies updates, as changes automatically apply to all group members. + +.. note:: + Configure permissions only through the backend user groups. Don’t set them on the user record. + +.. _file-mounts-and-files-management: + +File mounts and files management +================================ + +When planning for permissions and file access, consider how many separate +entry points (File Mounts) within file storage you will need. At a minimum, +you should create separate folders for each site you manage and then configure +them as distinct file mounts, which equate to separate backend groups. +These groups can later be assigned to users, granting them access to such folders. + +There are cases where some folders and the files within them have to be shared +across multiple sites. For this purpose, create separate file mounts +and dedicated groups for them. Then, combine these groups within a role group, +ensuring that each user associated with such a role group will have access +to the specified folders and files in the storage. + +.. uml:: _sample_backend_groups_hierarchy.plantuml + :align: center + :caption: Sample backend groups hierarchy + :width: 700 + +This diagram demonstrates the potential structure of folders within storage. +Create dedicated file mounts for folders, and then use those file mounts within +backend user groups. This arrangement enables two users with editor roles to +access distinct sets of folders: one can access files from Website A +and Shared folders, while the other accesses Website B and Shared folders. + +Often more complex configuration will be required, with a more nested folder +structure for each site. However, the setup remains similar - create separate +file mounts where needed and a backend group that will utilize this file mount. +Then, assign such groups to role groups. + +.. note:: + For each File Mount create a separate backend user group. diff --git a/Documentation/PermissionsManagement/GeneralRecommendations/_sample_backend_groups_hierarchy.plantuml b/Documentation/PermissionsManagement/GeneralRecommendations/_sample_backend_groups_hierarchy.plantuml new file mode 100644 index 00000000..c83e5df7 --- /dev/null +++ b/Documentation/PermissionsManagement/GeneralRecommendations/_sample_backend_groups_hierarchy.plantuml @@ -0,0 +1,43 @@ +@startuml + skinparam defaultTextAlignment center + + rectangle "**Storage**\nfileadmin/" as FileAdmin + rectangle "**Website B Files**\nfileadmin/website_b/" as Storage_B + rectangle "**Shared Files**\nfileadmin/shared/" as Storage_Shared + rectangle "**Website A Files**\nfileadmin/website_a/" as Storage_A + + FileAdmin -down- Storage_B + FileAdmin -down- Storage_Shared + FileAdmin -down- Storage_A + + rectangle "**File Mount**\nfileadmin/website_a/" as FM_B #Business;line.dotted + rectangle "**File Mount**\nfileadmin/shared/" as FM_S #Business;line.dotted + rectangle "**File Mount**\nfileadmin/website_a/" as FM_A #Business;line.dotted + + FM_B -up-> Storage_B + FM_S -up-> Storage_Shared + FM_A -up-> Storage_A + + rectangle "**FM_website_b**\nBackend Group" as FM_Website_B #Application + rectangle "**FM_shared**\nBackend Group" as FM_Shared #Application + rectangle "**FM_website_a**\nBackend Group" as FM_Website_A #Application + + FM_Website_B -up-> FM_B + FM_Shared -up-> FM_S + FM_Website_A -up-> FM_A + + rectangle "**R_website_b_editor**\nBackend Group (Role)" as R_Website_B_Editor #Implementation + rectangle "**R_website_a_editor**\nBackend Group (Role)" as R_Website_A_Editor #Implementation + + R_Website_B_Editor -up-> FM_Website_B + R_Website_B_Editor -up-> FM_Shared + R_Website_A_Editor -up-> FM_Website_A + R_Website_A_Editor -up-> FM_Shared + + rectangle "**Jane Doe**\nUser - editor role on Website B" as Editor_B #Motivation + rectangle "**John Doe**\nUser - editor role on Website A" as Editor_A #Motivation + + Editor_B -up-> R_Website_B_Editor + Editor_A -up-> R_Website_A_Editor + +@enduml diff --git a/Documentation/PermissionsManagement/Index.rst b/Documentation/PermissionsManagement/Index.rst index eda2dafe..dbed3bfd 100644 --- a/Documentation/PermissionsManagement/Index.rst +++ b/Documentation/PermissionsManagement/Index.rst @@ -105,4 +105,5 @@ the naming convention for backend groups later on. :titlesonly: :glob: - SettingUpBackendGroups/Index + GeneralRecommendations/Index + SettingUpBackendGroups/Index