search

eclipse-arrowhead / core-java-spring

Eclipse Public License 2.0
27 stars 53 forks source link

Fallback on database compromise/errors #268

Open BlackRose01 opened 4 years ago

BlackRose01 commented 4 years ago

You may want to consider creating a table in the Arrowhead database that is write-only and contains hash/encrypted information about each system in the system_ table.

The basic idea here is that a core system is always able to verify the connection data of a system in the system_ table. This can be, for example, when an orchestration is requested. Among other things, this is intended to increase data integrity but also to counteract compromises.

In case of a compromise or error, a core system can restore the system information from the table.

Hope it will enhance the security.

KR, BlackRose01

emanuelpalm commented 4 years ago

I had a similar idea in https://github.com/arrowhead-f/core-java-spring/issues/192#issuecomment-616382525, but for another reason (avoiding stale data).

tsvetlin commented 3 years ago

@BlackRose01 This idea is confusing for me. Could you please explain it in detail?

BlackRose01 commented 3 years ago

Hi,

my idea follows the basic idea: "Is the system information from the system_ table correct and not compromised?" For example, let's assume that for some reason a foreign person got access to Arrowhead's tables. Now this person could change relevant system information and thus the orchestrator is delivering information (systems/services) that is potentially dangerous.

So my idea would be that when you create an entry in the system_ table, you automatically create a hash over the entry, which is then stored in a column or table that only allows reads and adds. This way the orchestrator is able to identify compromised entries and subsequently delete or ignore them.

This is not an absolute solution to improve security, but it could help.

tsvetlin commented 3 years ago

See: https://www.mysql.com/why-mysql/presentations/mysql-security-best-practices/

BlackRose01 commented 3 years ago

The question I always have to ask the orchestrator is whether the data I am getting is correct and reliable. So the best practices are not suitable for all companies and not all companies can implement that because of budget and a shortage of employees (e.g. small/medium sized companies).

borditamas commented 3 years ago

How you prevent if someone got access to the DB than won't be able update also the check sum?

borditamas commented 1 year ago

Should be considered in v5