Как я могу предотвратить случайно поднимание с производственной базой данных?
Просто недавно у меня был разработчик, случайно пытаются восстановить базу данных к производству, когда он должен был восстанавливать к копии подготовки. Легко сделать, учитывая, что имена дб являются аналогичными, т.е. CustomerName_Staging по сравнению с CustomerName_Production.
Идеально, у меня были бы они на совершенно отдельных полях, но это стоится препятствующий, и, строго говоря, это не предотвращает то же самое, если пользователь соединяется с неправильным полем.
Это не проблема безопасности, по сути - это был корректный пользователь, работающий с базой данных подготовки, и если бы существует работа, которая будет сделана на производственной базе данных, это был бы он также. Я хотел бы иметь чиновника развертывания для выделения тех проблем, но команда не является достаточно многочисленной для этого.
Я хотел бы услышать некоторый совет с точки зрения практики, конфигурации и средств управления о том, как предотвратить это.
Если это то, что вы видите, как вы часто делаете, автоматизируйте это. А так как вы оба разработчики, написание кода должно быть в вашей рулевой рубке. :) Серьезно, однако... автоматизируя его, вы можете делать такие вещи, как:
- Убедитесь, что вы восстанавливаете на правильном сервере (т.е. никакого dev -> prod restores)
- Убедитесь, что это правильный "тип" базы данных (в вашем случае "постановка" и "производство")
- Выясните, какие бэкапы нужно восстанавливать автоматически, посмотрев на таблицы бэкапов в msdb
Et cetera. Вы ограничены только вашим воображением.
Короткий ответ - RBAC - управление доступом на основе ролей.
Ваши права доступа ко всем средам должны быть разными - и, как ни раздражают такие вещи, как UAC, они вам нужны: особенно для сред PROD.
Существует НИКОГДА причина для разработчиков иметь прямой доступ к Prod - независимо от того, насколько мала организация / команда. Ваш «Dev» также может носить шляпы «Stage» и «Prod», но ему нужны разные учетные данные и процессы для работы в разных средах.
Это раздражает? Абсолютно. Но помогает ли это предотвратить нарушение работы вашей среды? Совершенно верно.
У одного из моих коллег интересный подход к этому. Его цветовая схема терминала для производства fugly . Серый и розовый и трудночитаемый, что теоретически должно гарантировать, что бы он ни писал, он действительно намеревался писать.
Ваш пробег может варьироваться... и мне, наверное, не придется говорить, что он сам по себе едва ли пуленепробиваемый. :)
.Я не согласен с предположением в вопросе - это - безопасность, но я также не согласен с тем, что автоматизация сама по себе спасет день. Я начну с проблемы:
Вы не должны случайно делать что-либо для производства!
Это включает в себя случайное выполнение автоматизированных вещей.
Вы путаете безопасность системы с такими понятиями как "кому что дозволено". Ваши учётные записи разработчиков должны иметь возможность писать только на их копии, на сервер контроля версий и в базу данных разработчиков. Если они могут читать/записывать продукцию, их можно взломать и использовать для кражи клиентских данных или (как вы продемонстрировали) неправильно работать с ними, чтобы потерять клиентские данные.
Вам нужно начать с сортировки вашего рабочего процесса.
Ваши учётные записи разработчиков должны быть в состоянии писать на свои собственные копии, контроль версий и, возможно, переходить из-под контроля версий в тестовую среду.
Пользователи резервных копий должны иметь возможность только считывать с производства и записывать в ваше хранилище резервных копий (которое должно быть надлежащим образом защищено).
Для выполнения любых других операций по чтению/записи в процессе производства должна потребоваться специальная и неудобная аутентификация. Вы не должны быть в состоянии проскользнуть в него или забыть, что вы вошли в систему. Здесь полезен физический контроль доступа. Смарт-карты, флип-переключатели для "постановки на охрану" аккаунта, одновременный двухкнопочный доступ.
Доступ к продукции не должен быть необходимостью делать каждый день. Большая часть работы должна быть выполнена на вашей тестовой платформе, а внеурочное развертывание - на производстве после тщательного изучения. Небольшие неудобства не убьют вас.
Автоматизация - это часть решения.
Я не слеп к тому, что полный оборот (загрузка в VCS, проверка покрытия, подтягивание к тестовому серверу, запуск автоматизированных тестов, повторная аутентификация, создание резервной копии, подтягивание из VCS) - это долгий процесс.
Это, где автоматизация может помочь, согласно ответу Бена. Существует множество различных скриптовых языков, которые значительно, намного облегчают выполнение определенных задач. Просто убедитесь, что вы не делаете глупостей слишком легкими. Ваши шаги по повторной аутентификации все равно должны быть произнесены (и если они опасны), то они должны быть неудобными и трудновыполнимыми без размышлений.
Но только , автоматизация хуже, чем бесполезна. Она просто поможет вам совершать большие ошибки с меньшим количеством мыслей.
Подходит для команд любого размера.
Я заметил, что вы указываете размер вашей команды. Я один парень, и я прошел через это, потому что для того, чтобы попасть в аварию, нужен только один человек. Есть накладные расходы, но оно того стоит. В конечном итоге вы получаете гораздо более безопасную и гораздо более надежную среду разработки и производства.
Разработчики не должны знать пароль к производственной базе данных. Пароль prod должен быть случайным и не запоминающимся - что-то вроде результата затирания клавиатуры (Z^kC83N*(#$Hx). Ваш пароль dev может быть $YourDog'sName или correct horse battery staple или любым другим.
Конечно, вы можете узнать пароль, особенно если вы небольшая команда, взглянув на конфигурационный файл клиентского приложения. Это единственное место, где должен существовать пароль prod. Это гарантирует, что вам придется приложить целенаправленные усилия, чтобы получить пароль prod.
(Как всегда, у вас должны быть резервные копии в реальном времени для вашей производственной базы данных. Например, в MySQL архивируйте бинарные журналы как инкрементные бэкапы. Для PostgreSQL архивируйте журналы на заголовке. Это ваша защита в крайнем случае для любой катастрофы, в случае самоуничтожения или по другому поводу)
.Быстрое и простое решение: используйте две разные учетные записи пользователей, одну для нормальной работы в области разработки, которая имеет только доступ к базе данных разработки, а другую - для фактической работы с производственной базой данных, с полным доступом к ней. Таким образом, вам придется активно менять используемую учетную запись до того, как вы сможете внести какие-либо изменения в производство, чего должно быть достаточно для предотвращения случайных ошибок.
Такой же подход может быть использован, если у вас есть два вебсайта, или два сервера, или две целые среды: одна пользовательская учетная запись для разработки без доступа (или, по крайней мере, без доступа для записи ) к производству, другая пользовательская учетная запись для работы на производственной системе (системах).
Это тот же подход, что и для сисадмина, имеющего стандартную неадминовую учетную запись для рутинной работы (чтение электронной почты, веб-серфинг, билеты отслеживания, табели учета рабочего времени, написание документации и т.д.) и отдельную полноценную учетную запись админа, которая будет использоваться при реальной работе на серверах и/или в Active Directory
.