November 27, 2018

Features

SentinelDB offers a wide variety of features, mostly through our RESTful API. Below you can find a full list of the features and their descriptions:

  • Encryption per record – we encrypt every record with a separate key. You get this feature out of the box and don’t have to do anything additional. We also do regular re-encryption of data, following the best practices in the field.
  • Datastore management – you can have multiple datastores (conceptually equivalent to a “database”, “keystore” or “schema” in popular database solutions), and you can manage them via our dashboard or through an API. Each datastore has its own wrapped encryption key and its own separate audit trail.
  • User management and authentication – you can store all your users and their personal data in SentinelDB. Each user can have a username and password which allows SentinelDB to be used for authenticating users. Whenever authentication succeeds, SentinelDB issues an OAuth-compliant token which can be used to make¬† further API calls to user-specific endpoints. This is useful when you have to store the authentication in a mobile app or a desktop application, rather than using the general API credentials by a backend system.
  • Two-factor authentication – each user stored in SentinelDB can be enrolled for two-factor authentication. Then each time username/password authentication is attempted, the user also has to provide the 2FA code in order to obtain a token.
  • Record store – each user can have a number of records that are owned by them. You can store different types of records, with different fields. Records can be binary (encoded as Base64) in order to accommodate scanned documents and other non-structured files.
  • Record schema validation – SentinelDB is schemaless, but you can define a custom JSON-schema and upon each insert or update, the data is validated against the schema
  • Search – records and users can be searched by any of their fields (provided they are declared to be searcheable in a search schema). Searches can be done by exact match or by keyword.
  • Search schema – each user and each record type can have a search schema defined so that SentinelDB knows which fields to index and make searchable. Schemas are flexible and can be modified if new fields are added.
  • Version history – the full history of modification for each user and each record is preserved and you can fetch any previous version for a given user or record.
  • Audit trail – all reads and writes are logged at our blockchain-based audit trail service – Sentinel Trails. You can login to the trails dashboard and drill down in the activity with flexible time-dependent queries. In order to have a more useful audit trail, you may have to provide an actorId for some of the SentinelDB API operations, indicating who was the user performing an action on a particular record (or another user). In most cases that would be the owning user, so no additional parameters are required.
  • Fraud detection – we allow you to define fraud-detection rules based on the audit trail which, when triggered, will notify you for potential data breaches. We have a default, built-in set of rules in SentinelDB that would automatically block the extraction of data. Ontop of that, we also have a machine-learning based anomaly detection that is trained to detect usage pattern anomalies and report them.
  • “Forget user” – implements the right to erasure (as per GDPR) by deleting all data about a user and keeping only a record that erasure has been performed.
  • Pseudonymization – if you need to provide a sample of your data to a third party for analysis, you can use pseudonymization to protect the user identities. SentinelDB has that feature built-in – you just provide a psedonymization key and we export pseudonymized data.
  • Anonymization – you can choose to manually or automatically (after a period of time) anonymize the records. Anonymization is not “erasure”, but it renders all the records anonymous, thus making them unlinkable to a particular person (data subject). This feature can be useful if you need to keep historical, business-relevant data and you don’t need it to be attached to a particular person (user).
  • Custom master key provider – by default we use AWS KMS for secure management of keys. However, you can choose to supply your own master key management. In order to do that, you have to expose several endpoints (for wrapping and unwrapping keys) and register your provider with us.
  • Automatic scalability – you don’t have to worry about scaling your database. SentinelDB and its underlying storage mechanism handle that for you. All you need to do is store and retrieve data.