|
Test Case Title |
TC11.3 - Protected storage for Personal Data, Managing User Profile |
|
Goal |
The goal for this test case is to present a scenario where it’s possible to check that the Personal Data are stored in a protected way |
|
Prerequisites |
Access to the system at very low level. The following functionalities are available only for specific Snap4city users with specific privileges. |
|
Expected successful result |
The Personal Data are stored in a protected way |
|
Steps |
The Personal Data module, that include the User Profiles and any other information related to the user’s activities, ownerships and consents (delegations), is stored in a protected storage. The DB is located in a proper Debian machine not visible from any external access and it’s updated with all the secure patches available at the moment this document is wrote. Any external access is denied, beside a Java program, that run locally in the machine, that expose a set of apis that delivery some information of the user whenever is authenticated in the system via SSO (Keycloak). This enforcement is made via a short-term AccessToken in the process of the well know Open Id Connect (OAuth2). This Java program is protected using the last version of the Spring-security module.
The chosen DB itself is protected from external access via “Tablespace Encryption”. Any tables included in the User Profile DB are protected by a set of keys recorded in the database. These keys are protected by an external Master key, recorded out of the DB and accessible just to the administrator of the machine (this user is not register via SSO (Keyclock) in the snap4city system, but it’s kept completely out of the user’s flow. Several techniques can be enabled on top (Master key rotation) to provide even more security.
The plugin that provide this encryption is called “keyring_file plugin” (available for all MySQL version) and the storage of the key is located in the local folder /var/lib/keyring/keyring (accessible just to the administrator of the machine)
All the tables included in the Personal Data module are encrypted
A simple test to show the protection of the contents of the Personal Data can be made to assure that the data are not readable from any external access.
For example, if a malicious user is able to have the access of the machine, with a DB non protected, he is able to see the contents of, for example, the table Data with the command “head Data.idp”
As you can see, some information are wrote in clear text.
If we enable the encryption on the DB, a malicious user, digiting the same command as above, he is just able to see character without any sense (the Data are cyphered)
