Обнаружение фальсификации базы данных, возможно ли это?

Ответ 1

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

-Mike

Ответ 2

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

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

Ответ 3

Если вы действительно хотите быть в безопасности, используйте - Напишите один раз. Прочитайте много материалов для этой таблицы.

Ответ 4

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

Ответ 5

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

Многие люди говорят: "Просто добавьте другую базу данных", и хотя я фактически практиковал этот вид регистрации самостоятельно, я не верю в это. Злоумышленник мог выбить эту гарантию дюжину способов.

Все, что мы делаем здесь, пытается найти способ сделать очевидным, что что-то произошло. Вы потеряете свои журналы. Вы не сможете доверять им: если я столкнулся с системой с надежной системой ведения журнала, я бы либо заполнил ее данными мусора, либо просто полностью уничтожил ее. Не попадайте в менталитет линии Мажино.

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

Ответ 6

Позволяет быть ясным: если вы предполагаете "Зловещий Sysadmin", криптографического решения не будет запрещено изменять данные в системе незаметным образом - есть решения, которые предотвратят их возможность расшифровывать информацию, но ничего, что может помешать им писать новую информацию в любом удобном для них виде.

Эта ситуация требует следующих условий:

• Чтобы система была, по необходимости, автономной. Если вы можете добавить еще одну систему в том, что Evil Sysadmin не имеет доступа к хосту регистрации (например, сервер syslog), то внезапно проблема становится тривиальным случаем передачи журналов или хешей на регулярной основе.

• Чтобы система не имела составных компонентов для однократной записи. Самыми простыми, как это было предложено другими, являются такие вещи, как принтер, однако вы можете использовать компакт-диск или обычное одноразовое оборудование для предотвращения этой проблемы. Они становятся сложнее, но не являются непреодолимыми, если у Evil Sysadmin есть физический доступ к машине.

• Для вас требуется определенность, а не статистическая вероятность. В случае, если № 1 и № 2 невозможны, единственным оставшимся решением является обхудание - реализация трюкиных ловушек, предназначенных для того, чтобы поймать фальсификацию, если Evil Sysadmin не знает о ловушке.

Секрет эффективного № 3 - тактический сюрприз. Цель состоит в том, чтобы передать впечатление, нападающему, что они знают все о каких-либо контрмерах, в то время как фактически имеют больше, о чем они не знают. В общем, это требует как минимум двух уровней покрытия - вам нужно иметь хотя бы один уровень защиты, от которого можно ожидать, что Evil Sysadmin будет идти на компромисс, потому что они будут искать его, и если они его не найдут, они получат подозрительные и копать глубже, пока они этого не сделают.

Важным моментом является то, что эта обложка должна быть настолько убедительна, чтобы удовлетворить Злого Sysadmin, что, как только они ее нашли, им больше не нужно смотреть. Второй слой затем идентифицирует фальсификацию с использованием альтернативных методов и создает соответствующее предупреждение. Существуют различные предложения в этом потоке транзакций и т.д., Которые могут быть реализованы. Чем ниже уровень вашего решения, тем вероятнее, что он преуспеет (т.е. Исправление исходного кода базы данных гораздо менее заметно, чем стандартный процесс, выполняющий соединение и запрос, исправление ядра менее заметно снова, изменение прошивки.).

Важно подчеркнуть, что это не идеальное решение. Как бы ни была сложна ваша установка, возможно, кто-то выяснил/скомпрометировал достаточную информацию для реализации контрмер. Это не относится к # 1 и # 2 (сделано правильно). Тем не менее, если ценность информации, которую вы защищаете, достаточно низка, чтобы люди с необходимыми навыками не интересовались работой по ее получению, она должна обеспечить работоспособную защиту.

Ответ 7

Вы можете использовать триггеры, посредством которых вы проверяете вставки, обновления и удаления. Теперь, если "злой администратор SQL" отключает триггеры, тогда у вас есть еще более сложные проблемы. Я бы не позволил злобному админу иметь полный контроль над системой, если бы я хотел защитить свои данные.

Ответ 8

Я думаю, что это отличный вопрос! Но ваш сценарий противоречит принципам разработки базы данных.

Контрольные суммы строк, триггеры, экспортирующие другие базы данных - все, что вы делаете, будет компромиссом!

Я могу только предложить что-то вне коробки - поможет ли вам применить какой-то стандарт, например PCI Соответствие?

Если это не удастся, я бы предложил искать другую работу! В нашей отрасли достаточно работы, где вам не нужно работать с этими людьми...

Ответ 9

Подумайте о том, чтобы создать автоматическое резервное копирование ваших данных в автоматическом резервном копировании. S3 настолько дешев в наши дни, что можно было бы создать процесс типа mysqldump, чтобы перенести весь ваш репозиторий данных в резервную копию Transatlantic Хранить все так часто. Как часто это будет зависеть от зла ​​вашего администратора баз данных.

Чтобы сделать этот процесс возможным, просто найдите или заведите машину в своей сети, чтобы злое администратор ничего не знал или не хотел смотреть, подозревала ли она что-либо. Здесь нельзя переоценить простоту и элегантность nofollow noreferrer → plug-in.

Замечание о фактическом механизме экспорта: ничего не зная о вашей конкретной системе, я предложил mysqldump или Oracle exp как самое простое и неистовое решение. Если у вашего приложения есть способ экспортировать данные в собственный формат (например, XML, JSON или даже протокольные буферы), другими словами, любой формат, который часть приложения, например, использует SOA для общения друг с другом), затем формат можно использовать в качестве формата вашего сальника.

Я применил этот подход в своем gitosis. Каждые три часа содержимое сбрасывается в европейский ковш S3. Это бедный человек VCS другого VCS.

Ответ 10

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

Ответ 11

Это общая проблема с безопасностью данных. Простой ответ: если вы находитесь в ситуации, когда один "злой администратор SQL" имеет доступ ко всей вашей среде, у вас нет способа защитить ваши данные.

Общей практикой для критически важных данных является регистрация на несколько резервных копий и защита, гарантируя, что ни один человек не имеет разрешений.

Ответ 12

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

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

Мне также нравится ответ BobbyShaftoe... сделайте это немного дальше, посмотрите, можете ли вы заставить спусковой механизм "заснуть" или что-то в этом роде, и через несколько минут все записи вернутся к тому, что они были... так что наши зло Admin считает, что он внес изменения, но они просто вернутся.

Ответ 13

Во-первых, будьте очень осторожны с тем, кого вы нанимаете для администрирования вашей системы.

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

Третье автоматическое резервное копирование, удаляемое за пределы площадки. Таким образом, даже если плохой парень сбросил базу данных и удалил резервную копию на месте, у вас есть резервная позиция. Убедитесь, что резервная копия вне сайта недоступна администратору базы данных, только у кого-то есть права, у кого нет прав на производство на сервере базы данных.

Затем нет прямых прав на таблицы для всех, кроме администратора. Это означает использование хранимых процедур без динамического SQL. Это, по крайней мере, предотвращает несанкционированный доступ к другим данным. Теперь труднее для ваших учетных лиц совершить мошенничество.

Никаких прав на администрирование производства для всех, кроме администратора, а другого в качестве резервного. Таким образом, если вы обнаружите, что триггер изменился, вы знаете, кто это сделал. Теперь все идет не так, у вас есть только два подозреваемых.

В SQL Server 2008 есть триггеры DDL, которые сообщают вам, кто внес структурные изменения. Опять же, если триггер не записал изменение, он был сделан администратором по умолчанию.

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

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

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

Ответ 14

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

Сверху моей головы я мог бы изобразить две разные базы данных, системный администратор "зла" имел бы только доступ к одному.

Одна база данных обеспечивала бы одноразовые прокладки другой базе данных и журнал, который запрашивал пэд и когда. Эта панель вместе с текущими данными о времени и строках может быть хэширована.

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

Если sysadmin может хранить время и одноразовый блок, тогда вся эта система рушится.

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

Ответ 15

Если вам нужен автоматизированный подход, вам сначала нужно знать, какие действия и контекст допустимы для типа пользователя. Это довольно сложно, потому что в правильном контексте падение приемлемо, но оно не для повседневного пользователя.

Мне нравится идея резервного копирования на бумаге, однако объем информации, которая создается, может очень быстро затихать с большой базой пользователей и интенсивным использованием БД.

Ответ 16

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

Ответ 17

Мне нравится решение MikeMontana, но я подумал, что стоит добавить к нему добавление. К сожалению, я не могу оставлять комментарии, поэтому я разместил их в новом ответе, ниже приведено оригинал:

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

-Mike

Несколько человек отметили: хорошо, что системный администратор мог пересчитать контрольную сумму (еще больше проблема, если вы хотите код для работы на своем сервере), к которой я добавляю следующее усовершенствование:

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

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

Кроме того, если вы получаете доступ к этим данным удаленно, этот подход невосприимчив к человеку в средних атаках с помощью дешифрования и вычислений контрольной суммы в локальном поле. Перехваченные данные остаются зашифрованными и, следовательно, непригодными для использования.

Единственным недостатком этой системы является обнаружение любой транзакции в базе данных. Вы можете решить это путем абстракции и сказать:

• проверить контрольную сумму
• вставить данные
• пересчитать контрольную сумму

но это устраняет преимущество того, что у вас есть доступ к данным без предоставления личного ключа.

Теперь можно решить эту проблему по-другому, для чего я бы рекомендовал вам:

Решение проблемы асимметрии доверия в грид-вычислениях

by Peter Dinda

http://portal.acm.org/citation.cfm?id=1066656

но детали реализации становятся длиннее.

Ответ 18

Пока есть некоторые очень хорошие предложения, они все укусят пыль.

Если у вас есть "ненадежный" актер, злой админ, как хранитель ваших данных, вы не можете защитить себя. Существуют различные схемы в сетевых протоколах и в реальном мире, чтобы вы могли защитить свои данные от несанкционированного доступа/курьера. Но, насколько мне известно, нет ничего, что могло бы защитить вас от ненадежного хранителя, как в "Привет. Я мистер Мэдофф, я был председателем Нью-Йоркской фондовой биржи, которому вы можете доверять мне...".

Ответ 19

Разделение элементов питания /Dual Power.

Мне нравятся идеи, которые были представлены до сих пор. Я хотел добавить свои собственные 2 цента.

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

Дополнительно третья сторона регистрирует взаимодействия с ключевыми частями нашей системы.

В целом, ни один человек не имеет достаточного контроля, чтобы влиять на все сдержек и противовесов, что делает выигрыш настолько низким, что его (надеюсь) не стоит координировать.

Ответ 20

Есть две интересные статьи по этой теме Один из них предлагает использовать HMAC alogrith. В другом предлагается использовать Condensed- Схема RSA и схема сигнатуры BGLS.

Аутентификация и целостность в аутсорсинговых базах данных

http://www.isoc.org/isoc/conferences/ndss/04/proceedings/Papers/Mykletun.pdf

Общая методика дискретного распознавания для реляционных баз данных

http://www.dsi.unive.it/~cortesi/paperi/iciss09.pdf

Я чувствую, что оба решения являются неоспоримыми, исходя из количества пропущенного риска. --Kiran.Kumar

Ответ 21

Помимо триггеров для аудита, контрольных сумм и т.д., вы можете посмотреть репликацию базы данных на другую ведомую базу данных - никто не сможет выполнять какие-либо действия непосредственно на ней.

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

Ответ 22

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

Ответ 23

Поскольку у вас злой админ имеет полный контроль над сервером, вам, вероятно, потребуется внешнее аудиторское решение, предназначенное для мониторинга активности привилегированных пользователей SQL Server.

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

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

Ответ 24

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

Что я понял, что если у вас есть пара с частным открытым ключом (назовите их Kpr и Kpb) и набором алгоритмов (A и B), чтобы:

(где K'pr и K'pb - действительная пара частного открытого ключа, отличная от Kpr и Kpb)

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

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

• Если злой админ получает копию закрытого ключа, он сможет сменить любой записи с этого момента. Это можно обойти, используя аппаратный модуль для создания подписей, поэтому закрытый ключ недоступен из программного обеспечения.
• Злой администратор сможет добавлять данные в вашу таблицу.

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

ИЗМЕНИТЬ:

После нескольких размышлений я, возможно, выяснил способ сделать это возможным с помощью существующих инструментов. Если вы включили открытый ключ для n-й записи в (n-1) -ой записи и ее подписи (что вы можете, потому что в момент написания записи вы могли бы получить доступ к следующему закрытому ключу) d защищает каждую запись предыдущей. После удаления секретного ключа подпись не может быть воссоздана, поэтому, пока у вас есть первый открытый ключ, вы всегда можете проверить всю таблицу. Это также устраняет необходимость иметь "последовательные" секретные ключи, вы можете просто генерировать новый закрытый ключ для каждой строки (хотя это было бы очень дорого). Те же недостатки все еще применяются.

Ответ 25

Ответ на этот вопрос 2016 года будет состоять в использовании blockchain. Согласно Википедии:

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