Как я могу предотвратить случайный домкрат с производственной базой данных?

31

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

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

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

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

sql-server best-practices Крис Б. Беренс
источник
25
Разработчики не должны иметь права на запись в производственные базы данных или, предпочтительно, никакого доступа.
Michael Hampton
12
@MichaelHampton - это я и он. Я тоже разработчик. Что ты посоветуешь?
Крис Б. Беренс
10
Отдельные учетные записи пользователей для каждой роли (dev против ops / DBA). И обилие осторожности.
Майкл Хэмптон
2
Я настоятельно рекомендую, чтобы ваша производственная среда находилась в отдельной коробке. В противном случае подготовка и производство должны совместно использовать ресурсы - диск, процессор и т. Д. - и, если подготовка монополизирует ресурс, ваша производственная среда может пострадать.
Турбьёрн Равн Андерсен
1
Просто есть отдельные пользователи / пароли для этих баз данных.
Нейтринус

Ответы:

32

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

  • Убедитесь, что вы восстанавливаете на правильном сервере (т.е. нет dev -> prod restore)
  • Убедитесь, что это правильный «тип» базы данных (в вашем случае «подготовка» и «производство»)
  • Выясните, какие резервные копии нужно восстанавливать автоматически, просмотрев таблицы резервных копий в msdb

И так далее. Вы ограничены только вашим воображением.

Бен Тул
источник
1
Это интересная идея ... у нас уже есть код, который управляет восстановлением базы данных (для автоматического тестирования). Мы могли бы поместить слой абстракции между ними, который только когда-либо указывал на постановку, так что восстановление в производство было совершенно другим процессом ...
Крис Б. Беренс
11
Теперь вы думаете с порталами. :)
Бен Тул
4
Для автоматизированных заданий, которые влияют на производство, я бы хотел добавить шаг, который требует от пользователя ввода слова «производство», чтобы уменьшить вероятность того, что, по их мнению, они смотрят, например, на сценический эквивалент.
Джо Ли-Мойет
2
Я понизил голосование, поскольку никто не должен иметь доступ к продукции по умолчанию. У вас должен быть специальный процесс для восстановления пароля. Это неудобно, но на самом деле минимум.
OliverS
1
@BenThul Добавление другой учетной записи для доступа к продукту и создание еще одного неудобного шага - все еще правильное решение для меня. Бизнес-необходимость состоит не в том, чтобы DEV сэкономить 2 минуты, а в том, чтобы восстановить БД, которую можно без проблем перенести в учетную запись prod.
OliverS
32

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

Вы не должны быть в состоянии случайно сделать что-нибудь для производства!

Это включает в себя выполнение автоматических вещей случайно.

Вы путаете безопасность системы с такими понятиями, как «кому разрешено делать что». Ваши учетные записи разработчиков должны иметь возможность писать только в свои копии, на сервер контроля версий и базу данных dev. Если они могут читать / записывать производственные данные, их можно взломать и использовать для кражи данных клиентов или (как вы продемонстрировали) могут быть использованы для потери данных клиентов.

Вам нужно начать с сортировки вашего рабочего процесса.

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

  • Пользователи резервного копирования должны иметь возможность только читать с производства и записывать в хранилище резервных копий (которое должно быть точно защищено).

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

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

Автоматизация является частью решения.

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

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

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

Подходит для команд всех размеров.

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

Oli
источник
2
Кроме того, мне нравится использовать две именованные учетные записи для каждого пользователя. Один предназначен для обычного входа пользователя в систему, работы, повседневной работы и т. Д., В то время как вторая учетная запись (обычно с каким-либо суффиксом, таким как + или подчеркивание) обладает полными правами на prod и dev, которые требуются пользователю. Таким образом, пользователь должен принять активное решение подтолкнуть к Prod, а не Dev. Это похоже на пункт 3, описанный выше, но не требует значительной дополнительной инфраструктуры или затрат для демонстрации ценности.
user24313
3
Также важно избегать привычки делать что-либо, кроме поддержки продукта в вашем аккаунте. Для этого убедитесь, что prod не видит исходный код, не может запустить IDE и т. Д.
Эрик Ллойд,
Где взять одно из этих устройств с двумя ключами одновременно и поставляется ли оно с USB?
Лилиенталь
Еще кое-что, что может помочь, - это полная автоматизация (один или два щелчка) процедур в staging и dev, но не полная автоматизация производственных развертываний. Как вы предлагаете, необходимость в ручном удалении из коробки, чтобы что-то сделать для производства, но не для других сред, - это существенная разница в удобстве (Вы все еще можете написать сценарий для любых шагов и использовать этот сценарий во всех средах; я имею в виду, что вам придется вручную запускать выполнение указанных сценариев для производства.) Это, конечно, можно сделать в дополнение к типу аутентификации. процедуры, которые вы рекомендуете.
jpmc26
1
@Lilienthal Это была метафора для театра высокой безопасности, но вы могли подражать этим дешевым атакам USB-флешек на каждого разработчика, а затем проверять свою автоматизацию на наличие как минимум двух их серийных номеров при выполнении опасных задач. В больших командах вы можете войти в систему, чтобы увидеть, кто мешает производству, и привлечь к ответственности правильных людей, когда все пойдет не так.
Оли
12

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

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

robhol
источник
2
Я также использую большой красный цвет фона для подключений терминалов / дБ к производственным серверам, а также ярко-красные обои для администраторов на ПК ...
Falco
Да, я так думал. Сделать производство пожарной машины красным ...
Крис Б. Беренс
Цветовое кодирование помогает. Так же, как в IDE.
Турбьёрн Равн Андерсен
1

Разработчики не должны знать пароль к производственной базе данных. Пароль prod должен быть случайным и не запоминающимся - что-то вроде результата затирания клавиатуры ( Z^kC83N*(#$Hx). Ваш пароль разработчика может быть $YourDog'sNameили correct horse battery stapleили как угодно.

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

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

200_success
источник
Я не могу полностью согласиться с этим, потому что в любой реалистичной большой среде довольно часто встречаются случаи, когда разработчикам / администраторам необходим доступ к производственной базе данных. Конечно, в идеальном мире с безупречной системой этого никогда не должно произойти, но в большинстве систем, я знаю, вам нужно вручную исправить некоторые важные для работы данные ... Так что я с Оли, вход в систему должен быть неудобным, но выполнимым
Falco
1
@Falco Это именно то, что я предлагаю, хотя. Неудобно, но возможно.
200_success
Проблема с вашим подходом заключается только в том, что если возникла аварийная ситуация и производство остановилось, время имеет значение. Поэтому ваши разработчики должны знать, где найти пароль и как быстро его получить. Если им нужно поспрашивать, поищите в репозитории и конфигурационных файлах и постарайтесь не терять драгоценное время = деньги. Поэтому я предпочел бы иметь пароль в месте, где все знают, где искать, но это все еще неудобно, но быстро, если это необходимо
Falco
2
@Falco Поскольку среды prod должны тесно отражать среды разработки, файл конфигурации будет находиться в аналогичном месте на сервере prod, как и на машинах разработчиков. Любой компетентный разработчик должен знать, где искать, и если он не знает, где искать, то вам нужна эта задержка - именно для предотвращения повреждения типа, указанного в вопросе.
200_success
Незнание паролей не мешает несчастным случаям. Наоборот, это создает мотивацию для того, чтобы просто выполнить поиск пароля только один раз, и после этого разработчик может начать использовать историю bash или даже создать псевдоним для подключения к базе данных. И тогда несчастные случаи более вероятны.
k0pernikus
0

Краткий ответ - RBAC - управление доступом на основе ролей.

Ваши разрешения для всех сред должны быть разными - и такие же раздражающие, как такие вещи, как UAC, вам нужны, особенно для сред PROD.

Там нет НИКОГДА причины дэвов , чтобы иметь прямой доступ к Prod - независимо от того, насколько мала организации / команда. Ваш "Dev" может также носить шляпы "Stage" и "Prod", но ему нужно иметь разные учетные данные и процессы для работы в разных средах.

Это раздражает? Абсолютно. Но разве это [помогает] не мешать вашей среде? Абсолютно.

кроличий садок
источник
0

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

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

Это тот же подход, что и у системного администратора, имеющего стандартную учетную запись без прав администратора для рутинной работы (чтение электронной почты, веб-серфинг, отслеживание билетов, составление расписаний, написание документации и т. Д.) И отдельной учетной записи полного администратора, которая будет использоваться при фактической работе. на серверах и / или Active Directory.

Massimo
источник