diff --git a/source/index.rst b/source/index.rst index dc198cbaba6144eba775a4ea4594de0b6801682a..a1de3c1da1041d8a2c63bdee4627876f8884ff3a 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 f8b5c1740ec84d2df904fd88189bca2e9c4505f0..0000000000000000000000000000000000000000 --- 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 9bf7f56d7b8b85954c31ccb610109bf1ca6013e8..0000000000000000000000000000000000000000 --- 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 0000000000000000000000000000000000000000..332622c37f7f65da8f1a01ca28a297c83d61f990 --- /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.