При обнаружении вмешательства базы данных действительно ли это возможно?

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

-Mike

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

Since you evil admin has full control of the server, you probably need an external auditing solution that's designed to monitor the activity of privileged SQL Server users.

Guardium make a network appliance that can log all of the query activity on a database or a server, and it does it at the network level (including local connections) so you can't do anything at the SQL Server level to interfere with it.

This doesn't prevent your evil admin from changing the table but, because it's a locked down appliance, the evil admin can't change the table then persuade the appliance to say that he didn't do it.

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

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

Разделение управления мощностью / двойное питание.

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

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

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

В целом,

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

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

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

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

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

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

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

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

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

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

Это обманчиво сложная проблема, я '

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

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

-Mike

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

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

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

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

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

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

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

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

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

Питер Динда

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

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

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

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

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

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

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

Питер Динда

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

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

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

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

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

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

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

Питер Динда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Многие люди говорят: «Просто добавьте еще одну базу данных», и хотя я на самом деле практикую сам веду журнал, не верю. Злонамеренный инсайдер может вывести из строя эту защиту дюжиной способов.

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

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

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

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

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

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

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

3. Это требует достоверности, а не статистической вероятности. В случае, если №1 и №2 невозможны, ваше единственное оставшееся решение - это затемнение - реализация хитрых ловушек, предназначенных для обнаружения взлома, если Злой системный администратор не знает о ловушке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрите возможность создания непрерывного, быстрого автономного резервного копирования ваших данных. S3 настолько дешев в наши дни, что время от времени можно создать процесс типа mysqldump для переноса всего репозитория данных в Transatlantic backup store. Как часто именно будет зависеть от злости вашего администратора базы данных.

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

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

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