данные данные хранения данных безопасность?

Question

Я начал работу в компании как разработчик junior sql на хранилище данных. С тех пор, как я просматриваю код и изучаю модели размеров и т. Д., Я изо всех сил стараюсь увидеть меры безопасности вне прав, которые разработчик имеет в среде.

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

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

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

Любые мнения и предложения по этому вопросу будут высоко оценены, спасибо.

Answer 1

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

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

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

Теперь для развертывания убедитесь, что у вас есть своего рода контрольный список, который нужно переходить при каждом развертывании. Первым шагом в контрольном списке должно быть резервное копирование существующей производственной среды. Напишите сценарии для автоматизации частей развертывания, когда это возможно. Используйте инструменты, такие как SQL Schema Compare, для определения различий между базой данных разработки и производства и т. Д. В идеале развертывание должно быть одним нажатием одной кнопки, а затем все развертывается автоматически, и вы можете вернуться к разработке, не беспокоясь.