Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TASK] Add General Recommendation section for Permissions Managemend docs #329

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
129 changes: 129 additions & 0 deletions Documentation/PermissionsManagement/GeneralRecommendations/Index.rst
Original file line number Diff line number Diff line change
@@ -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.
Original file line number Diff line number Diff line change
@@ -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
3 changes: 2 additions & 1 deletion Documentation/PermissionsManagement/Index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -105,4 +105,5 @@ the naming convention for backend groups later on.
:titlesonly:
:glob:

SettingUpBackendGroups/Index
GeneralRecommendations/Index
SettingUpBackendGroups/Index
Loading