DBMS access management

As introduced before it’s necessary, in order to raise the security level of the whole system, to create restrictive access policy to the DBMS.

In particular, it turned out to be necessary to introduce different DBMS users, each one with different privileges concerning his specific task. Three distinct users have hence been created:

• u_logmanager: it’s the user the Log Manager makes use of to access the DBMS;

• u_tool: it’s the user the several tools described in the previous sections make use of in order to manage the data contained in the database;

• u_auditor: it’s the user the auditors make use of in order to retrieve data from the database;

The first limitation enforced to these users is based on their location. We thought it was more safe to allow the users u_logmanager and u_tool to have access to the DBMS only if their IP address is the same as the computer the Log Manager is running on (notice that the access to the DBMS is carried out through a TCP/IP connection). The user u_auditor, on the other hand, can be used to access the DBMS from any workstation, because auditors are allowed to access the system from remote locations.

For security reasons, these three users are granted with the sole and only privileges they may need to engage correctly the archiving and visualization operations.

In particular, the user utilized by the auditors during the verification phase must have only the capability of reading the database tables. Auditors must, in fact, only be able to retrieve, by means of appropriate queries, the data pertaining to the groups composition, the auditors and data archived in the tables “Logs” and

“Logs_aud”. At the same time, auditors must not be able to edit, delete and add records to the DBMS.

The user u_logmanager, on the other hand, must be able to insert data in the tables “Logs” and “Logs_aud”, other than reading the data pertaining to groups and auditors. In this way, the Log Manager can generate accordingly the secrets pertaining to each auditor. Notice that this user must not, nevertheless, be able to edit or delete records from the table “Logs” and “Logs_aud”, because this could lead to the compromising of the hash chain.

CHAPTER 5–IMPLEMENTATION

Finally, the user who can be utilized for system management must be able to add to the DBMS data concerning auditors and groups, conversely he must not be entitled to access (read or write) data archived by the Log Manager. Notice that the management tools can be used also to modify some fields of the tables

“Auditors”, “Groups” and “Groups_aud”; for that reason, we decided to provide the user u_tool with the edit privileges only on those fields. Further observation:

this user must not be entitled to delete data from any of the DBMS tables, not even those containing the data concerning groups and auditors. The removal of a user or a group, as described in the previous sections, does not cause the removal of data from the database, but the modification of the field “deactivation_date” of the record pertaining to the auditor or the group at issue.

MySQL – the DBMS adopted for this implementation – consents data management with granularity as subtle as the single table attribute. For each attribute we can specify, in relation with each user, any combination of the four available types of performable operations, that are:

• SELECT: used to read data from the database;

• INSERT: used to insert new data into the database;

• UPDATE: used to edit data already present in the database;

• DELETE: used to delete data from the database;

In the following figures there is a summarization of the privileges of the three users described above on the single tables of the DBMS:

Table “Auditors”

Attribute u_auditor u_logmanager u_tool

auditor_id select select select, insert

personal_data select select select, insert, update activation_date select select select, insert deactivation_date select select select, insert, update

public_key select select select, insert

signature select select select, insert, update pubkey_certificate select select select, insert, update

Table “Groups”

Attribute u_auditor u_logmanager u_tool

group_id select select select, insert

CHAPTER 5–IMPLEMENTATION

group_info select select select, insert, update total_auditors select select select, insert, update minimum_auditors select select select, insert, update activation_date select select select, insert deactivation_date select select select, insert, update signature select select select, insert, update pubkey_certificate select select select, insert, update

Table “Groups_aud”

Attribute u_auditor u_logmanager u_tool

group_id select select select, insert

auditor_id select select select, insert activation_date select select select, insert deactivation_date select select select, insert, update signature select select select, insert, update pubkey_certificate select select select, insert, update

Table “Groups_history”

Attribute u_auditor u_logmanager u_tool

group_id select / select, insert

modification_date select / select, insert

total_auditors select / select, insert

minimum_auditors select / select, insert

signature select / select, insert

pubkey_certificate select / select, insert

CHAPTER 5–IMPLEMENTATION

Table “Logs”

Attribute u_auditor u_logmanager u_tool

session_id select select, insert /

user_pseudonym select select, insert / administered_server select select, insert /

session_start select select, insert /

session_end select select, insert /

session_termination select select, insert /

timestamp select select, insert /

path select select, insert /

encrypted_data_hash select select, insert /

hash_chain select select, insert /

signature select select, insert /

pubkey_certificate select select, insert /

Table “Logs_aud”

Attribute u_auditor u_logmanager u_tool

session_id select select, insert /

auditor_id select select, insert /

session_start select select, insert /

encrypted_key select select, insert /

Figure 5-7: Privileges of the users on the single tables

CHAPTER 6–CONCLUSION AND FUTURE WORK

Chapter 6