[TASK] Add General Recommendation section for Permissions Managemend …

…docs (#329)

* [TASK] Add General Recommendation section for Permissions Managemend docs

This commit adds the General Recommendations section to the new
Permissions Management documentation.

This is part #2 from the PR series.

* [TASK] Add changes after review for General Recommendations chapter

---------

Co-authored-by: Marcin Sągol <[email protected]>

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:`[email protected]`.
+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<t3coreapi:security-secure-passwords>` 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.

Documentation/PermissionsManagement/GeneralRecommendations/_sample_backend_groups_hierarchy.plantuml

@@ -0,0 +1,43 @@
+@startuml
+  skinparam defaultTextAlignment center
+
+  rectangle "**Storage**\n<size:10>fileadmin/</size>" as FileAdmin
+  rectangle "**Website B Files**\n<size:10>fileadmin/website_b/</size>" as Storage_B
+  rectangle "**Shared Files**\n<size:10>fileadmin/shared/</size>" as Storage_Shared
+  rectangle "**Website A Files**\n<size:10>fileadmin/website_a/</size>" as Storage_A
+
+  FileAdmin -down- Storage_B
+  FileAdmin -down- Storage_Shared
+  FileAdmin -down- Storage_A
+
+  rectangle "**File Mount**\n<size:10>fileadmin/website_a/</size>" as FM_B #Business;line.dotted
+  rectangle "**File Mount**\n<size:10>fileadmin/shared/</size>" as FM_S #Business;line.dotted
+  rectangle "**File Mount**\n<size:10>fileadmin/website_a/</size>" 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**\n<size:10>Backend Group</size>" as FM_Website_B #Application
+  rectangle "**FM_shared**\n<size:10>Backend Group</size>" as FM_Shared #Application
+  rectangle "**FM_website_a**\n<size:10>Backend Group</size>" 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**\n<size:10>Backend Group (Role)</size>" as R_Website_B_Editor #Implementation
+  rectangle "**R_website_a_editor**\n<size:10>Backend Group (Role)</size>" 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**\n<size:10>User - editor role on Website B</size>" as Editor_B #Motivation
+  rectangle "**John Doe**\n<size:10>User - editor role on Website A</size>" as Editor_A #Motivation
+
+  Editor_B -up-> R_Website_B_Editor
+  Editor_A -up-> R_Website_A_Editor
+
+@enduml

Documentation/PermissionsManagement/Index.rst

@@ -105,4 +105,5 @@ the naming convention for backend groups later on.
    :titlesonly:
    :glob:
 
-    SettingUpBackendGroups/Index
+   GeneralRecommendations/Index
+   SettingUpBackendGroups/Index