По соображениям соблюдения, когда я удаляю личную информацию пользователя из базы данных в моем текущем проекте, соответствующие строки должны быть действительно безвозвратно удалены.Как безопасно удалить строку из базы данных?
В базе данных мы используем это Postgres 8.x,
Что я могу сделать, за регулярно запуская COMPACT/VACUUM?
К счастью, наши резервные копии будут храниться другими пользователями, и им будет разрешено хранить удаленную информацию.
«Неустранимое удаление» сложнее, чем кажется, и выходит за пределы вашей базы данных. Например, планируете ли вы вернуться ко всем предыдущим экземплярам вашей базы данных на ленту/резервную копию, где эта строка также существует, и удалять ее там тоже?
Рассмотрите возможность регулярного удаления и периодического ВАКУУМИРОВАНИЯ, о котором вы говорили ранее.
Сопровождать резервную копию вашей базы данных? - Если да, убедитесь, что вы также удалили его из резервных копий.
Это из-за риска для безопасности? В этом случае я изменил бы данные в строке, а затем удалю строку.
Это не то, что вы можете сделать со стороны программного обеспечения. Его аппаратная проблема, чтобы действительно удалить ее, вам нужно физически уничтожить диск.
Возможно, я отключен по касательной, но вы действительно хотите удалить таких пользователей? Большинство идентификаторов & подходы к управлению доступом рекомендуют поддерживать пользователей, но в состоянии с пометкой как удаленные, чтобы не потерять способность к аудиту (что у этого пользователя было в предыдущие пять лет)?
Удаление информации о пользователе может потребоваться для целей соблюдения целостности или для гнусных черных шляп. В любом случае не существует метода удаления, который гарантирует отсутствие следов от существования пользователя, как было отмечено в других сообщениях.
Возможно, вам следует уточнить, почему такое безотзывное удаление желательно ...?
Я согласен с этим, следуя этому маршруту. Если дело касается политики офиса, взгляните на эту статью ... http://www.adaptivepath.com/ideas/essays/archives/000251.php –
Европейская директива по защите данных предусматривает, что персональные данные будут удалены, если они больше не будут удалены необходимо. Поэтому его «на всякий случай» запрещено. Эта директива применяется в законодательстве всех членов Европейского союза. Это может быть его случай. – bortzmeyer
PCI DSS v3, Requeriment 3.1 Храните хранилище данных держателей карт до минимума, применяя политики, процедуры и процессы хранения и удаления данных, которые включают по крайней мере следующее для хранения данных данных держателя карты: ( ) Ограничение объема хранения данных и время хранения до . не для юридических, нормативных и требований бизнеса ** Способы безопасного удаления данных , когда больше не требуется ** ; • Особые требования для хранения данных о держателях карт ; • ежеквартальный процесс идентификации и надежно удаление сохраненных данных держателя карты который превышает установленный удержание. – Neoecos
Для выполнения «D» в ACID реляционные базы данных используют систему типа журнала транзакций для внесения изменений в базу данных. Когда делается удаление, делается удаление в копию памяти данных (буферный кеш), а затем записывается в файл журнала транзакций в синхронном режиме. Если база данных должна была сбой, журнал транзакций будет переименован, чтобы вернуть систему в правильное состояние. Таким образом, удаление существует в нескольких местах, где его нужно будет удалить. Только в более позднее время запись «удаляется» из фактического файла данных на диске (и любых индексов). Это количество времени зависит от базы данных.
Как насчет перезаписи записи со случайными символами/датами/цифрами и т. Д.?
Мое понимание - редактирование строки создает новую копию строки в db и отмечает, что старая строка является устаревшей, это было бы хуже, чем просто удаление строки – NSherwin