From 5da3dd9feb9dcff6a102c09cb8f32060210b07a6 Mon Sep 17 00:00:00 2001 From: Tobias Bengfort Date: Mon, 16 Sep 2019 11:12:04 +0200 Subject: [PATCH] extend docs on security --- source/index.rst | 3 +- source/organizational/privacy-levels.rst | 19 ------- source/organizational/roles.rst | 4 -- source/organizational/security.rst | 70 ++++++++++++++++++++++++ 4 files changed, 71 insertions(+), 25 deletions(-) delete mode 100644 source/organizational/privacy-levels.rst delete mode 100644 source/organizational/roles.rst create mode 100644 source/organizational/security.rst diff --git a/source/index.rst b/source/index.rst index dc198cb..a1de3c1 100644 --- a/source/index.rst +++ b/source/index.rst @@ -17,8 +17,7 @@ Welcome to castellum-docs's documentation! :maxdepth: 2 :caption: Organizational - organizational/privacy-levels - organizational/roles + organizational/security Indices and tables ================== diff --git a/source/organizational/privacy-levels.rst b/source/organizational/privacy-levels.rst deleted file mode 100644 index f8b5c17..0000000 --- a/source/organizational/privacy-levels.rst +++ /dev/null @@ -1,19 +0,0 @@ -Privacy Levels -============== -Privacy levels are in accordance with data security levels of the Max Planck -Society. - -Users ------ -Privacy levels are assigned to Castellum users for read and for write -permissions. - -Subjects --------- -Each subject is assigned to a privacy level that is checked against users' -privacy levels. - -Attributes ----------- -Attributes are also assigned to privacy levels. They are overruled by subject -privacy level. diff --git a/source/organizational/roles.rst b/source/organizational/roles.rst deleted file mode 100644 index 9bf7f56..0000000 --- a/source/organizational/roles.rst +++ /dev/null @@ -1,4 +0,0 @@ -Roles -===== - -Castellum comes with blueprints for roles that allow to separate views on data. \ No newline at end of file diff --git a/source/organizational/security.rst b/source/organizational/security.rst new file mode 100644 index 0000000..332622c --- /dev/null +++ b/source/organizational/security.rst @@ -0,0 +1,70 @@ +Security model +============== + +The main purpose of castellum is to handle data of test subjects. It is +important to be able to read and write this data in various ways. We are +also legally required to provide some specific forms of access, e.g. +exporting or deleting all data on a single subject. + +On the other hand, we are also required to handle this data very +carefully. Among other things, we are required to split the data so that +users can only ever access the parts of the data they really need. + +The security measures outlined in this section are meant to only allow access +where allowed and required. + +Permissions +----------- + +Most actions in castellum are protected by one or more permission. For +easier handling, permissions are usually not assigned directly. Instead, +they are collected into meaningful groups (aka roles). Castellum comes +with some pre-defined sample groups, but you can adapt them to your +needs. + +Study membership +~~~~~~~~~~~~~~~~ + +If a user is a member of a study, they automatically gain the special +``access_study`` permission in the context of that study. You can also +assign additional groups to study members that only apply in the context +of the study. + +Privacy levels +~~~~~~~~~~~~~~ + +Every subject has a privacy level. A user is only allowed to access that +subject if they have a sufficient privacy level themselves. For recruitment +attributes, you can define separate privacy levels for read and write access. A +user's privacy level is controlled via the special permissions +``privacy_level_1`` and ``privacy_level_2``. The three levels (0-2) accord to +the data security levels of the Max Planck Society. + +Data separation +--------------- + +Implementation +~~~~~~~~~~~~~~ + +We chose to split the data into three different categories: + +- Scientific data is handled outside of castellum. Castellum only + provides the pseudonyms that are used to map this data to subjects. +- Data relevant for recruitment is handled in castellum. +- Contact data is also handled in castellum, but in a separate database + to provide an additional barrier. + +Security Considerations +~~~~~~~~~~~~~~~~~~~~~~~ + +The described architecture provides a clear structure for developers +that should help avoiding critical data leaks. Even if an attacker is +able to dump a whole table or even a whole database, this structure +still limits the impact. + +However, it is important to understand that the barrier between +recruitment and contact data is not that high. Since castellum has full +access to both, an attacker can also gain full access. Spreading the +system across several databases on different servers or even in +different organizations does not help much if there is still a single +point of entry. -- GitLab