Transparency Model

[cefothe]

Proposal Architecture

Requirements

We want to have a track of every important activity in our system, this includes not only campaigns and payments but everything important. As a system, we need to provide a way to guarantee that nobody (not so easy at least ) will be able to manipulate the system and change/corrupt the data.

Proposal

The architect above has CDC via debezium attached to the database transaction log, and all changes will be streamed to Kafka. CDC gives use immutable data stream and we are going to have all database event. So nobody will change the data without changing the data in Kafka as well. We have history tables in places to have information in one more place. We don't want to have a single source of the truth. When a new Kafka message is consumed by the Transperancy service, it will check with the history table to verify it. If they are a mismatch a mail or discord message will be sent.
All topics in Kafka will have ACL's in place.

Pros

1. The system is highly distributed and highly available
2. All data is immutable, so we have a full track of what changes by who
3. Close to real-time solution
4. To manipulate the system you need to change the data in at least 3 places.

Cons

1. New microservice required and additional infrastructure
2. We need to define which tables are important for us to have history tables

Future improvements

1. Introduce distributed tracing (OpenTracing)
2. Create a set of libraries that will provide structure logs and minimize the risk of logging something wrong.
3. Introduce metrics (per request)
4. Add (DDD events in place)

Useful links

1. https://debezium.io/
2. https://opentracing.io/
3. https://kafka.apache.org/

[kachar]

Are there any DB requirements for the Debezium connector ?

Can you please update the post with relevant links to the different tools included in the proposal

[cefothe]

Yes, I will do that, I will move the entire discussion from discord here as well. But I'm not going to translate it, I hope is not a big problem,

[cefothe]

Изглежда добре. Имам няколко въпроса:

1. Защо е този допълнителен overhead с MongoDB след като вече си записал всичко в Кафка? Кафка може без проблеми да извърши всичко, което Mongo прави.
2. Това ще работи само ако имаш mTLS in place в самия cluster, иначе не е foolproof. Пример: gain-вам access до твоя cluster, мога да си пиша в Кафка (особено ако няма ACLs) и за всяка промяна, която правя по базата ти ще трия/добавям евенти в Кафка, че накрая всичко да мачва. Мога да reverse engineer-на proto messages и да си пусна всичко през самия service, накрая пак няма да го хванеш. Форматите на всеки message дори са публични в репото, дори не ми трябва да се занимавам сам да си ги създавам.
3. Този transparency service какво ще запазва в база данни?
4. "Microservice that runs as a job", Microservice и Job са ортогонални. Или едното, или другото. Microservice предимството е, че може да стане real time и веднага да alert-неш.
5. Audit log не значи, че задължително трябва да се прави audit на това, което се log-ва от даден сървиз. По-secure начин е да имаш end-to-end audit logging - всеки request, който влиза в cluster-a се лог-ва като евент (примерно в Кафка топик през някакъв interceptor), после според tracing ID се проследява всеки action, който идва от всички следващи requests и ги анализираш в real time, можеш да го пуснеш и през някакъв security scanner също. Крайната цел е не само transparencу, но и да се засече malicious activity на момента, а не преди да са ти дъмпнали или нарушили integrity на цялата база.

Мисля, че решения тук може доста да се измайсторят, по-скоро да се подхване с правилно дефиниране на проблема. Целта е transparency, ама transparency на какво или по-скоро на кои/какви данни? Ясно дефинирано какво трябва да бъде отчитано и пред кого. Дали ще се експортва нещо към external users, дали ще бъде само около internal security audits etc. Също така, как ще се пазиш от логване на PII?