diff --git a/admin_manual/file_workflows/access_control.rst b/admin_manual/file_workflows/access_control.rst new file mode 100644 index 000000000..26f38db85 --- /dev/null +++ b/admin_manual/file_workflows/access_control.rst @@ -0,0 +1,117 @@ +==================== +Files access control +==================== + +Nextcloud's File Access Control app enables administrators to create and +manage a set of rule groups. Each of the rule groups consists of one or more +rules. If all rules of a group hold true, the group matches the request and +access is being denied. The rules criteria range from IP address, to user +groups, collaborative tags and :ref:`some more `. + +Denied access +------------- + +If access to a file has been denied for a user, the user can not: + +* Create/upload the file +* Modify the files +* Delete the file +* Download the file +* Syncronise the file with clients, such as the Nextcloud desktop and mobile clients + +Examples +-------- + + .. figure:: images/files_access_control_sample_rules.png + :alt: Sample rules to block on user group, time and IP base. + +The first rule group ``Support only 9-5`` denies any access to files for users +of the Support user group, between 5pm and 9am. + +The second rule group ``Internal testing`` prevents users of the Internal +testers group to access files from outside of the local network. + +Denying access to folders +------------------------- + +The easiest way to block access to a folder, is to use a collaborative tag. As +mentioned in the :ref:`Available rules ` section below, +either the file itself or one of the parents needs to have the given tag +assigned. + +So you just need to assign the tag to the folder or file, and then block the +tag with a rule group. The check is independent of the user's permissions for +the tag. Therefor restricted and invisible tags are recommended, otherwise a +user could remove and reassign the tag. + +This example blocks access to any folder with the tag ``Confidential``. + + .. figure:: images/files_access_control_collaborative_tags.png + :alt: Deny access based on collaborative tag + +Prevent uploading of specific files +----------------------------------- + +It's possible to prevent specific files from being uploaded to Nextcloud. You +simply need to define a rule based on the mimetype and our powerful access control +engine will block any attempt to upload the file. The safest way to define the rule +is to use a regular expression, as it will help you cover all the known media types +used for the type of file you're trying to block. + +The following example prevents zip files from being uploaded by using the regular +expression: ``/^application\/(zip|x-zip-compressed)$/i`` + + .. figure:: images/files_access_control_block_mimetype.png + :alt: Prevent upload based on mimetype + +Common misconfigurations +------------------------ + +Blocking user groups +^^^^^^^^^^^^^^^^^^^^ + +When trying to deny access to a group of users, make sure that sharing does not +allow them to create a way back in. When users are able to create a public link, +the users can log themselves out and visit their own public link to access the +files. Since at this point they are no user and therefor no member of the +blocked group, they will be able to read and change the file. + +The recommended work around is to create the same rule again, and deny access +for all users that are ``not member of`` a group, that contains all users of +your installation. + +External storage +^^^^^^^^^^^^^^^^ + +While access to files in external storages is not possible via Nextcloud, users +that have direct access to the external storage, can of course change files +there directly. Therefor it is recommended to disable the ``Allow users to mount +external storage`` option, when trying to to completely lock out users. + +.. _available-rules-label: + +Available rules +--------------- + +All rules can also be inverted (from ``is`` to ``is not``) using the operator +option. + +* **File collaborative tag:** Either the file itself, or any of the file + owner's parent folders needs to be tagged with the tag. + + .. note:: Tags used in access control rules should be restricted tags, + otherwise any user can remove the tag to access the file again. + The best way to do this is with the :doc:`automated_tagging`. + +* **File mimetype:** The mimetype of the file, e.g. ``text/plain`` +* **File size:** The size of the file (*Only available on upload*) + +* **Request remote address:** An IP range (either v4 or v6) for the accessing user +* **Request time:** Time span and timezone when the request happens +* **Request URL:** The URL which requests the file. (*This is the URL the file + is served from, not the URL the user is currently looking at.*) +* **Request user agent:** The user agent of the users browser or client. + Nextcloud desktop, Android and iOS clients are available as preconfigured + options. + +* **User group membership:** Whether the user is a member of the given group. diff --git a/admin_manual/file_workflows/automated_tagging.rst b/admin_manual/file_workflows/automated_tagging.rst new file mode 100644 index 000000000..295444b53 --- /dev/null +++ b/admin_manual/file_workflows/automated_tagging.rst @@ -0,0 +1,31 @@ +========================== +Automated tagging of files +========================== + +Nextcloud's Files Automated Tagging app allows to assign collaborative tags +to files and folders based on rules, similar to :doc:`access_control`. + +Assigning restricted and invisible tags +--------------------------------------- + +The main functionality of this app is to allow users to indirectly assign +restricted and invisible tags to files they upload. + +This is especially useful for retention and :doc:`access_control`, so people +that got the files shared can not remove the tag to stop the retention or +allow access against the owners will. + + + .. figure:: images/automated_tagging_sample_rule.png + :alt: Sample rule to assign a restricted tag. + +In the sample you can see a simple rule with only one condition. +It will tag all files with the restricted tag ``Protected file`` that are +uploaded into a folder that is tagged with ``Protect content``. No user can +remove the tag ``Protected file`` and therefor access control and retention +both work fine without users being able to work around them. + +Available rules +--------------- + +The available rules can be seen in the access control section: :ref:`available-rules-label`. diff --git a/admin_manual/file_workflows/images/automated_tagging_sample_rule.png b/admin_manual/file_workflows/images/automated_tagging_sample_rule.png new file mode 100644 index 000000000..6ec87a419 Binary files /dev/null and b/admin_manual/file_workflows/images/automated_tagging_sample_rule.png differ diff --git a/admin_manual/file_workflows/images/files_access_control_block_mimetype.png b/admin_manual/file_workflows/images/files_access_control_block_mimetype.png new file mode 100644 index 000000000..37278a790 Binary files /dev/null and b/admin_manual/file_workflows/images/files_access_control_block_mimetype.png differ diff --git a/admin_manual/file_workflows/images/files_access_control_collaborative_tags.png b/admin_manual/file_workflows/images/files_access_control_collaborative_tags.png new file mode 100644 index 000000000..17cda9dbf Binary files /dev/null and b/admin_manual/file_workflows/images/files_access_control_collaborative_tags.png differ diff --git a/admin_manual/file_workflows/images/files_access_control_sample_rules.png b/admin_manual/file_workflows/images/files_access_control_sample_rules.png new file mode 100644 index 000000000..e910174aa Binary files /dev/null and b/admin_manual/file_workflows/images/files_access_control_sample_rules.png differ diff --git a/admin_manual/file_workflows/images/retention_sample.png b/admin_manual/file_workflows/images/retention_sample.png new file mode 100644 index 000000000..00e37a37f Binary files /dev/null and b/admin_manual/file_workflows/images/retention_sample.png differ diff --git a/admin_manual/file_workflows/index.rst b/admin_manual/file_workflows/index.rst new file mode 100644 index 000000000..3056b0a3c --- /dev/null +++ b/admin_manual/file_workflows/index.rst @@ -0,0 +1,11 @@ +============== +File workflows +============== + + +.. toctree:: + :maxdepth: 2 + + access_control + automated_tagging + retention diff --git a/admin_manual/file_workflows/retention.rst b/admin_manual/file_workflows/retention.rst new file mode 100644 index 000000000..2ee332c53 --- /dev/null +++ b/admin_manual/file_workflows/retention.rst @@ -0,0 +1,33 @@ +================== +Retention of files +================== + +Nextcloud's Files Retention app allows to automatically delete files that +are tagged with a collaborative tag and have a certain age. + +Sample +------ + + .. figure:: images/retention_sample.png + :alt: Sample rule to delete files after 14 days. + +The rule from the sample will delete all files tagged with ``Temporary file`` after 14 days. + +Common misconfigurations +------------------------ + +Public collaborative tag +^^^^^^^^^^^^^^^^^^^^^^^^ + +Similar to :doc:`access_control` retention should use ``restricted`` or ``invisible`` +tags. Otherwise any user can remove the tag and the file is not removed after the given +period. Use :doc:`automated_tagging` to assign such tags to newly uploaded files. + +File age +^^^^^^^^ + +Currently retention is based on the creation date of the file. The sync client sends +the **original** creation date to the server, while uploading through the web interface +will create a new file with a **new** creation date. +We hope to be able to add a ``upload date`` to the filesystem soon, which would make more +sense. Until then this potentially unexpected behavior has to be taken into account.