Создание простой системы не отказаться / мошенничество

Question

Каковы ключевые особенности, которые я должен учитывать, если я хочу создать простой мошенничественную систему доказательства и не отказаться? На этот вопрос я в основном концентрируюсь на целостности строк базы данных. Это не вопрос разрешений безопасности.

Используя футбольную базу данных в качестве примера, некоторые из ключевых функций, которые я бы реализовал, являются:

1. Предотвратите DBA из модификации данных строки с использованием традиционного SQL. Например, если строка базы данных уже сохранена 2: 1 в результате, если DBA изменил результат до 2: 3, мы должны быть в состоянии обнаружить модификацию. Все изменения должны выполняться через основное приложение.

2. Предотвратите копирование строки данных в другую строку с использованием изменений в бэкэнда. Мы должны быть в состоянии определить изменения мошенничества.

Есть ли другие проблемы или функции, которые я должен рассмотреть возможность сделать мою систему более доказательством мошенничества? Каковы лучшие практики, о которых я должен знать? Любые указатели были бы наиболее ценными.

Спасибо заранее.

Answer 1

Создайте один столбец, который является криптографической подписью других колонн. До тех пор, пока идентификатор включен в вычисление подписи, вы не можете скопировать ряд, потому что идентификатор изменится. Никакие модификации не могут быть выполнены без компенсирования хеша, поэтому изменения DBA также будут обнаружены.

Это не решает проблему дбаса удаление Строки, разумейте вас - это только подтверждает, что каждая отдельная строка проходила через соответствующую бизнес-логику. Вы могли бы потенциально включать подпись для всего стола, но это начинает становиться довольно тяжелыми!

Конечно, в какой-то момент вам нужен секрет - частная часть ключа подписи. Ваш код будет нужен доступ к этому ... а тот, кто пишет этот код мог включите заднюю дверь, чтобы отправить сами по электронной почте частный ключ и т. Д. Рано или поздно, вы должны доверять кто-то, Я подозреваю. (Конечно, вы можете применить несколько подписей, конечно, из разных команд - так что команды должны были бы вступить в созвучие, чтобы погрузиться что-либо.)

Answer 2

Быть идеально тупой: вы тратите свое время.

DBA имеют эквивалент корневого доступа к вашей базе данных. Если нет, они будут довольно неэффективными. Те же проблемы возникают с системными администраторами и в основном все, что вы можете сделать, это немного больше, чем плацебо в лучшем случае. Единственное, что вы можете сделать с вредоносным человеком с этим уровнем доступа, не дают им доступ к началу.

Лучшее, что вы можете сделать, это сделать это маленький Сложнее, создавая аудиторскую тропу. Журнал, когда пользователи воходятся вход, выйти из системы, что они делают, какие события системы отвечают и так далее. Единственная реальная ценность этого является способным (надеюсь) реконструировать, что произошло, если вы вручную решите войти и посмотреть на него позже.

Что касается изменения результата футбольного матча, спросите себя, насколько вероятно, что это произойдет. Конечно, это на самом деле не изменится результат футбольного матча. Это просто измени, как оно было записано. Любой, кто видел это или участвовал, будет знать о фактическом результате, так что в том, какая ценность находится в том, что в одном изменении его в системе?

В компаниях, ошибках и злобу и обрабатывается процессами примирения. Будет ли Stockbroker будет иметь команду, которая управляет отчетами о том, что находится в системе, и сравнить его с банковскими операциями на самом деле. Любые расхождения получают красный флаг. Таким образом, вы могли бы изменить свой баланс в системе, но он вернется.

Другая часть этой головоломки заключается в том, что ограничения на активность DBA на самом деле не решит проблему. Разработчики приложений могут выпустить произвольный код. Даже если это рассмотрено, система все еще может сломаться на инженерах сборки или кого-либо с доступом к корневым уровнем к производственной среде, составляющей модифицированную версию и выполняя ее.