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