Security description

During the design and implementation of solutions, we generally strive for the maximal privacy, integrity, and availability of data.

Privacy

We solve access to data on the level of distinction of access rights, authentication of users and authorization to the individual sources. For accessing our data through API we use authentication with the help of JWT, which is a digitally signed token and on the basis of asymmetric cryptography, we can clearly determine its authenticity and correctness and successfully identify the user. Every user has assigned roles and to these roles rights to sources are explicitly assigned (individual API endpoints, individual data). A newly implemented source is unavailable in its default state until it is permitted.

We solve access rights on an individual layer, where rights to the ‘inner’ systems on API are assigned to the users. Rights are assigned on the level of endpoints, type of data or individual parameters or values of parameters.

We solve access to managing applications and client applications via a user name (verified email) and a password. We store passwords in an encrypted form with the help of bcrypt. We have user and access data (emails, passwords) in a separate database from the main operating ‘data’ database. The applications for managing the system are available only on the internal network.

So far we do not store any personal data.

Integrity

All the communication takes place via HTTPS. We use the HSTS policy.

We secure the integrity of data on the level of regular validation and alerting. All data that we receive/download are validated against the central schema of data before passing them on in the system/storing them in the database. We have a clear database structure for all our databases. During a transition to a higher/lower version, we perform an up/down migration of databases.

Availability

The availability of data and the system is secured on the level of SLA by the supplier of the service (the example of a database ‘as a service’) or by a regular backup and the option of data recovery. The specific description of backups, operating and solving catastrophic scenarios is in individual documentation.

We solve protection against DDoS attacks on the level of infrastructure. We solve protection against ordinary overload of the system by scaling and by setting a rate-limit for queries of all the users. Every user has got a set maximal number of queries to the system for the given space of time. After exceeding this number, his access is temporarily limited.

We do a regular check of availability (and validity) of data, which we take over from the systems of third parties. If any of the data incomes stop, they come in the wrong format, they are not available on the appropriate interface or they are available in the wrong format, then we have an alerting setup and we immediately start to solve the problem. We store statistics of accesses to the API from our external ones to the ones of users to our API.

Further general principles:

• All inputs are sanitized to prevent a SQL-injection
• Publicly available forms are secured by a re-captcha against brute-force attacks
• Sensitive information is stored only in a secure environment (e.g. they are not a part of git repositories)
• Input and output APIs are separated applications – a publicly available API is a separated application, which is not able to change the data and permits only ‘safe’ methods like GET, HEAD, etc.