We started using InfluxDB when 2.0 was released to store event data that sometimes contains sensitive information. The database exists in a special, locked down environment with disk encryption. However, the rules are changing and becoming more strict. Now, not only does it have to be in a locked down environment with disk encryption, but any data at rest, which includes any data inside a database, has to be encrypted.
I read where InfluxDB does not provide data encryption. Assuming that answer is still true, does anyone have any suggestions about how to encrypt the data going into and coming out of InfluxDB? We are using Grafana for a dashboard to display the data with Flux as the query language.
If the answer is that there is no answer, does anyone know of an open source replacement we can use for InfluxDB that does support data encryption?
Hello @Kevin_Taylor,
Welcome!
The database itself does not, you’re correct. To encrypt data in the database, we recommend that you use disk encryption. But note that disk encryption only protects data at rest. However, connections to the database can be made over TLS, which encrypts the traffic.
I don’t know of a replacement that supports data encryption. I’m sorry. Maybe the grafana community does? I’m not sure where else to ask.
Per the soon to be released PCI 4 requirements, disk encryption for data at rest is no longer good enough. The data itself has to be encrypted when at rest in addition to disk encryption.
I guess we’re down to attempting masking via regular expressions before we insert the data into influxbd. Really not looking forward to this.
Hi,
this is late but just for the record. Since String is an InfluxDB datatype, you could use an encryption algorithm right after the data is created and safe the encoded data (a string) in InfluxDB. This would just bear the inconvenience of needing an interface (custom Middleware with an API or Grafana Plugin for a custom Datasource) for decryption between the DB and Grafana. Or you use sth. else than Grafana. These are just my thoughts. I am not aware of such interfaces. Though, if someone knows one, it would be great if it could be posted here.
I think the trouble would be querying the database—for example, WHERE COLUMN=“text.” We’d have to encrypt the strings in the queries on the fly (which would require an SQL parser). I am not sure that a LIKE comparison would work: WHERE COLUMN =~ /text/. We’d have to decrypt the entire column first to run the comparison against text.
