The project aims at setting up a highly secured document server in order to protect confidential documents produced and shared by a small number of people (CEO, Managing board...).

Context

This server must allow the members from different working groups to share documents. The groups themselves are partitioned: members of a group can only access the documents of their group. Personal storage zones are also useful. Groups evolve in time and it must be possible to add a member to a group, granting him access to all the data of the group, or to withdraw a member making him unable to access the data (of course it would not be possible to protect the data he previously accessed).

The ideal solution should include the coding of the files to prevent access from non-authorized people. Whenever possible, the solution should be integrated in the general security policy of the company, e.g. through the use of smart cards for the authentication of the users or the coding of data.

The security of the server should of course be as transparent as possible, and support the commonly used tools (such as Filemaker,...).

Moreover, the solution should include a backup system in order to recover the data in case of major problem. The existence of this system should not compromise the security of the data. The various risks that may lead to data loss should be considered, as much for the data itself as for the coding keys. This backup should be set up to work efficiently: Incremental backup rather than plain copy of all the secured data.

Finally, a limited access for the system managers is to be considered.

Individual coding of the zones

One of the first decisions to take deals with the individual coding of the user zones or not. This kind of solution requests that each user (or group of users) zone be coded with a different key and this key does not reside in the server. In this way, access to the data is impossible to anyone who has not got the coding key(s) whatever the rights he possesses or gets from the server.

Another solution is to trust the system managing the authentication and the rights on the operating system. This system is then in charge of granting or denying access to the various file zones, while it can access all of them. In any case, we will code the data.

In the scenario without individual coding, all the disks are nevertheless coded to avoid risks linked to the theft of the server or brute copy of the hard disks. It is advisable to consider the use of a hardware solution in order to guarantee a better storage of the coding keys.

From the setup point of view, many difficulties need to be overcome if we want to prevent the software from directly accessing the data.

Issues linked to the coding of a data base

The ideal solution to secure a data base would be a database software supporting the individual coding of each user's data. However, such a solution seems very difficult to enforce.

An intermediary solution is to make several groups in the database and increment the database engine with functionalities allowing it to decode the data upon access. This seems feasible although it requests a considerable amount of efforts.

In order to enforce such a solution, a small number of groups must be identified. They should be stable in time and their functions and privileges must be well defined (of course, this does not prevent members from being added or withdrawn from these groups).

Applications that must be working on the server

An important question, all the more so if we consider the unavoidable complexity of database softwares such as the ones described here above, is to precisely define the type of use to be made of the server, as well as the applications that we want it to run.

Coding of files vs. coding of "zone"

An easy solution enforced to secure a set of documents consists in maintaining the structure of the documents and coding the documents. The users can then access the documents as before, but they need to use their key to code the documents and access their content.

Transparent access vs. authentication step

A compromise is always necessary between security and user-friendliness of an application. It is obvious that final users prefer accessing their files as easily as possible, but some control steps are nevertheless advisable.

Authorised access for system managers or not?

Besides choosing to code the data individually or not, it is also possible to forbid the system managers from accessing the data. This may be advisable as much for the owners of the confidential documents as for the system managers themselves. On the other hand, it also limits the scope of their action in case of problems. Solutions exist and may be enforced to overcome theses problems.

Limit to the securisation

It is extremely important to properly understand the limits of the data protection process. The aim of our mission here is to secure the data stored on a distant server, but also to protect it during its transit between the secured server and the client (coded connection).