Разрешения. Как Вы Ограничиваете Доступ К Производственной Среде В Компании, В Которой Работаете?

В компании, в которой я работаю, DevOps-инженеры (на данный момент только два сотрудника — я и еще один коллега) — единственные люди, которые имеют доступ к производственной базе данных.

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

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

1. База данных содержит поврежденные данные, что приводит к ошибкам. Они выполняют команды для исправления ошибок.

2. Сообщается об ошибке. И они хотят видеть текущие значения внутри базы данных.

3. Один из наших клиентов хочет изменить свои данные. Но наше веб-приложение не имеет возможности вносить изменения. Поэтому нам приходится отправлять команды MySQL непосредственно в базу данных, чтобы выполнить требование клиента.

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

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

Я не думаю, что это хорошая архитектура для компании. Как вы контролируете права доступа к производственной среде в вашей компании?

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

#разрешения

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

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

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

Например, в моей среде (веб-приложение PHP) я использую Doctrine Schema для обновлений схемы и миграцию Yii2 для изменения данных. Соответствующие команды являются частью 7-строчного сценария bash, который запускает все необходимые команды для развертывания изменений в каждой среде.

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

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

Такие вещи, как ProxySQL, который вы уже цитировали в комментарии, могут подойти для баз данных MySQL, просто настройка MySQL для регистрации событий также может быть хорошим подходом, MySQL предлагает коммерческую версию плагин аудита что может решить проблему предоставления вашим разработчикам доступа к базе данных и выполнения требований CISO по отслеживанию того, что делается.

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

Я знаю одно коммерческое решение, которое может помочь (и позволить проводить аудит не только запросов к БД), а именно: сильныйDM, он также позволяет проверять сеансы ssh и rdp, так как если вашим разработчикам нужен доступ к БД, им, вероятно, также понадобится доступ к машинам, на которых размещены приложения, для целей отладки.

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

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

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

Вопрос:
Почему разработчики бегут что-либо против производственной базы данных?

Как вы контролируете права доступа к производственной среде в вашей компании?

Ролевое управление доступом.

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

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