Security concept for the dilbo application for the association.
{#.club.clubname#}
As of: {#printedOn#}
dilbo Server.
{#dilboVersion#}
© dilbo.org
The application consists of an executable PHP script, which accesses accesses a MySQL database, and a file system for code storage Code storage, configuration and monitoring.
The file system is not externally readable except for selected directories. externally readable. Only the directories that are accessed directly via browser or accessed directly via browser or API: api, forms, js, license, pages, public, resources.
All other directories are readable both through authorization assignment, as well as by depositing a .htaccess file. file for access from the outside.
The application uses besides the standard modules of PHP no framework.
The technical user used to access the application's Database is stored in the configuration. This Configuration is located in the inaccessible area of the file directory and is not stored in plain text, but is additionally "hidden" by simple symmetrical scrambling and subsequent subsequent base64 encoding. This does not protect against real hackers, but it requires an access to the protected server area and is thus secured.
The application has a built-in load throttle that throttles throughput beyond max. {#.framework.sessions.max_inits_per_hour#} accesses or API containers and max. {#.framework.sessions.max_errors_per_hour#} errors per hour on both the PHP application and the API. Beyond the limit web access or API containers are increasingly delayed.
The API and the PHP application encapsulate all database accesses, so direct SQL statements by the user are are not possible. On the API, up to. up to ten transactions bundled in a container, e.g. for synchronization of multiple data sets.
The user will be notified in the API for each containerauthorized. When using the browser, the successful login establishes a session, which in case of inactivity is closed after {#.framework.sessions.max_session_keepalive#} seconds.
The communication takes place exclusively over HTTPS to protect the data from being read, lost and manipulated. protect. Use via HTTP is blocked in the Server setting.
Human users basically access... via PHP forms or pages access the data. Technical users, such as for example, a boathouse PC, can access via an API.
You authorize yourself for this with a Password, which is stored in the user record as a hash. To do this, the PHP supplied Hashalgorithm supplied with PHP is used in the default setting.
dilbo provides a Javascript application within the dilbo server package. This does not access the data directly, but via the API, just like any other client. There is no direct access from the efaWeb logbook application to the database.
It stores tables in the local storage except the persons and logbook table, which is only held in memory. The logbook data are only the last 50 sessions.
The dilbo application distinguishes six roles, those marked with *. marked are privileged roles, for which the Authorizations are listed by name below. Each role has basically all permissions of the role listed before:
The permissions for anonymous users are:
{#accessibleWebAnonymous#}
The permissions on the web are:
{#accessibleWebPerRole#}
The permissions on the API interface are:
{#accessibleApiPerRole#}
The application includes extensive monitoring logic as well as. the possibility of auditing.
Every transaction on the API, every login, every error and every data change, and every list deployment is logged. However, the corresponding logs are only accessible to users in the role of 'admin' role, as it also contains, in particular, in the data change log contains real data.
Users with an administrative privilege must be that their activity can be recorded and assigned.
The log is only accessible to users in the 'admin' role. can be assigned.
The application performs periodic "audits" during which the file access permissions in the application directory are corrected, if necessary.
Cron jobs are used for database control and allow the dispatching of personal logbooks to members.
All accesses are executed via HTTPS. Only during the installation, a one-time sftp access is required to store the installation file Installation file in the root directory. Upgrades also use HTTPS access to the dilbo server.
Data can be exported as lists via the API as well as via the User application to be exported as lists. The export via the API is required for the synchronization of the boathouse PCs with the server. The export as a list in the server application is for administrative purposes - it is written along with the exporting user and and requires the permission level "board".
Data can be imported as lists via the API as well as via the User application to be imported as lists. Importing via the API is required for the synchronization of the boathouse PCs with the server. Exporting as a list in the server application is used for Restoring backups and require 'admin' privileges.
In order to adequately ensure data protection. the following procedures for granting and verifying permissions. agreed.
Permissions will be assigned by a user with the the authorization "admin" after checking the function of the user in the club. The authorization "board" is thereby assigned only to function holders in the Association.
The authorization "board" or "admin" will be withdrawn in the event that the Association function from by a user with the authorization "admin" to "member". The user is set to the "anonymous" permission level when the user leaves the association set to the authorization level "anonymous".
Once a year, the permissions are checked by the operator of the of the application.
An automated deletion or anonymization of the data does not take place.
Once a year, this security concept will be updated and submitted the association's board of directors and the data protection officer for and the data protection officer for information and control of appropriate implementation of the application.
The following is a summary of the current Access Status and the current audit result is provided. Variable Information always refers to the last 14 days, thus represents therefore only represent a random sample.
With regard to the data sets, it should be noted that versioned tables. (boats, destinations, groups, persons) frequently contain more records than objects, because an object like the for example the person has several records with different temporal validity.
This monitoring information is also available to the administrator available online.
The access type is login, init (= page views), and error. (generated redirects to the error.php error page) are distinguished.
{#activitiesWeb#}
{#changesAll#}
Users with special rights are listed by name here for the control of the security concept by the club board.
The users with privileged roles are:
{#privilegedUsers#}
On a daily basis, dilbo records the status in the form of an audit. At creation of the concept, an audit was performed, the result of which is is printed here as well.
{#auditLog#}