Создание простой системы безотказности и защиты от мошенничества
Какие ключевые особенности следует учитывать, если я хочу создать простую систему защиты от мошенничества и отказа от авторства? В этом вопросе я в основном концентрируюсь на целостности строк базы данных. Это не вопрос разрешения безопасности.
Используя футбольную базу данных в качестве примера, некоторые из ключевых функций, которые я бы реализовал:
Предотвратить DBA от изменения данных строки с использованием традиционного SQL. Например, если строка базы данных уже сохранила 2:1 в результате, если администратор БД изменил результат на 2:3, мы сможем обнаружить модификацию. Все изменения должны быть сделаны через основное приложение.
Запретить копирование строки данных в другую строку с помощью внутренних изменений. Мы должны быть в состоянии обнаружить изменения мошенничества.
Есть ли какие-либо другие проблемы или функции, которые я должен рассмотреть, чтобы сделать мою систему более защищенной от мошенничества? Каковы лучшие практики, которые я должен знать? Любые указатели будут наиболее цениться.
Спасибо заранее.
2 ответа
Создайте один столбец, который является криптографической подписью других столбцов. Пока идентификатор включен в вычисление подписи, вы не сможете скопировать строку, потому что идентификатор изменится. Никакие модификации не могут быть выполнены без повторного вычисления хэша, поэтому изменение DBA также будет обнаружено.
Заметьте, это не решает проблему администраторов баз данных, удаляющих строки - это только подтверждает, что каждая отдельная строка прошла соответствующую бизнес-логику. Вы могли бы включить подпись для всей таблицы, но это становится довольно тяжелым!
Конечно, в какой-то момент вам понадобится секрет - личная часть ключа подписи. Ваш код будет нуждаться в доступе к этому... и тот, кто пишет этот код, может включать в себя заднюю дверь, чтобы отправить себе по электронной почте закрытый ключ и т. Д. Рано или поздно вам придется кому-то доверять, я подозреваю. (Конечно, вы можете применять несколько подписей от разных команд - поэтому командам придется вступать в сговор, чтобы подделать что-либо.)
Чтобы быть совершенно тупым: ты тратишь свое время.
Администраторы баз данных имеют эквивалент корневого доступа к вашей базе данных. Если нет, они будут довольно неэффективными. Те же проблемы возникают с системными администраторами, и все, что вы можете сделать, в лучшем случае - чуть больше, чем просто плацебо. Единственное, что вы можете сделать с злоумышленником с таким уровнем доступа, это не дать ему доступ с самого начала.
Лучшее, что вы можете сделать, это сделать это немного сложнее, создав контрольный журнал. Регистрируйтесь, когда пользователи входят в систему, выходят из системы, что они делают, на какие события реагирует система и так далее. Единственная реальная ценность этого - возможность (надеюсь) восстановить то, что произошло, если вы вручную решите войти и посмотреть на это позже.
Что касается изменения результата футбольного матча, спросите себя, насколько вероятно, что это произойдет. Конечно, это не меняет результат футбольного матча. Это просто изменить, как это было записано. Любой, кто видел это или участвовал, будет знать о фактическом результате, так какова ценность того, кто его меняет в системе?
В компаниях ошибки и злоба и обрабатываются процессами сверки. У биржевого маклера будет команда, которая будет составлять отчеты о том, что находится в системе, и сравнивать ее с фактически совершенными банковскими операциями. Любые расхождения помечаются красным. Таким образом, вы можете изменить свой баланс в системе, но он будет восстановлен.
Другая часть этой головоломки состоит в том, что ограничения на работу администратора БД не решат проблему. Разработчики приложений могут выпустить произвольный код. Даже если она проверена, система все равно может выйти из строя у инженеров по сборке или у кого-то с доступом с правами root к производственной среде, компилирующей модифицированную версию и запускающей ее.