Должны ли разработчики получать разрешение на запрос ( SELECT/ только для чтения) производственных баз данных? Предыдущее место , где я работал, команда разработчиков была db_datareaderроль; где я сейчас работаю, команда разработчиков не может даже подключиться к производственному экземпляру.

Один из тестовых экземпляров - это копия рабочей копии, восстанавливаемая из рабочей резервной копии раз в неделю, поэтому у разработчиков нет никаких проблем с просмотром данных.

Какие веские причины существуют для того, чтобы не позволять разработчикам запрашивать производство (кроме простого нежелания иметь доступ к чтению конфиденциальных данных)?

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

Обычно плохая идея делать что-либо на рабочем сервере, если в этом нет необходимости.

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

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

Нет.

Разработчики не должны иметь доступа к системам производственных баз данных по следующим причинам:

1. Доступность и производительность : наличие прав на чтение только для базы данных не является безопасным. Плохо написанный запрос может:

   1. Блокировка таблиц, блокировка других критических процессов.
   2. Очистите кеш данных, заставляя другие процессы перечитывать данные с диска.
   3. Наложите налог на уровень хранения, влияя на другие службы, которые совместно используют это хранилище

2. Безопасность : ваша производственная база данных может содержать конфиденциальную информацию, такую ​​как:

   • хеши паролей
   • Платежная информация
   • другая личная информация

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

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

   «Но это касается и администраторов баз данных! Они могут сделать это!» Именно так. Вам нужно как можно меньше суперпользователей.

Да.

Разработчики должны иметь доступ к производственным системам.

В моей компании четыре команды, которые занимаются производственными базами данных. Они есть:

1. Разработчики , которые проектируют и пишут схему и код для баз данных. Они не имеют доступа к базам данных в производстве. Они, тем не менее, иногда сидят с администраторами или сотрудниками службы поддержки и помогают им посмотреть на что-то вживую.
2. Администраторы , которые развертывают, отслеживают и управляют базами данных в производстве.
3. Поддержите людей , которые исследуют чувствительные ко времени производственные проблемы и предоставляют обратную связь разработчикам, чтобы они могли разработать исправления.
4. Сотрудники Business Intelligence , которые извлекают данные из производственных баз данных, используя либо регулярно обновляемые копии этих баз данных, либо тщательно написанные и проверенные выдержки (обычно разработанные Администраторами).

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

Например:

• У вас нет команды поддержки. Кто будет знать, где искать, чтобы отладить эту чувствительную ко времени проблему производства? Ваши разработчики. Предоставьте им доступ " разбить стекло ".
• У вас нет команды BI. Ваши администраторы не имеют или не хотят иметь ничего общего с отчетами или выдержками. Кто будет разбираться с отчетом, который ваши руководители видят каждое утро? Ваши разработчики. Предоставьте им ограниченный доступ для отладки этих отчетов и выписок.
• У вас нет команды администратора. Вы находитесь в очень маленькой или начинающей компании, так что поздоровайтесь со «случайным администратором базы данных». Ваши разработчики удваиваются как ваши администраторы, и поэтому им необходим полный доступ к продукту.

Производительность будет большой причиной.

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

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Это рецепт катастрофы. Обратите внимание, что это декартово произведение с порядком, что означает, что оно будет отсортировано в tempDB.

Принцип «наименьшие привилегии» и «нужно знать»: проходят ли разработчики этот тест?
Особенно когда стучат Одиторы или Сарбаннес-Оксли.

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

Тогда нужен ли доступ постоянно? У них может быть доступ "разбить стекло", используя имя входа SQL или альтернативную учетную запись Windows, которая требует выхода из системы. В нашем случае это был владелец данных (надеюсь, что кто-то разбирается в технологиях) и ИТ-менеджер, который одобрил это.

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

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

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

Я думаю, что ответ, как и во многих других вещах, «зависит».

Большая база данных ERP с большим количеством конфиденциальной информации о компании и клиенте? Вероятно, нет (как по соображениям безопасности, так и по производительности).

Ведомственная база данных объемом 5 МБ с интерфейсом Access, которая отслеживает взносы в фонды для пончиков и пиццы? Не будет большой разницы, по крайней мере, для доступа только для чтения.

Конечно, первый пример гораздо более распространен, чем второй, но вам следует помнить об этих различиях, если вы отвечаете за принятие таких политических решений. Но, с другой стороны, удивительно, как быстро база данных фонда пончиков и пиццы объемом 5 МБ может охватить путь до 50-гигабайтных номеров-номеров / номеров кредитных карт-клиентов / кто-знает-что-что- еще база данных, если вы позволите.

В обычной среде 24/7 OLTP нормальный разработчик не должен быть допущен к работе. Период! Если время от времени появляется конкретная причина, разрешения могут быть предоставлены по запросу. Но на обычной основе нет.

Я видел много причин для этого:

• ВЫБРАТЬ * с большого стола, ведущего к:

  • проблемы производительности (декартовы произведения);
  • блокирование проблем, которые в конечном итоге поставили сайт на колени;
  • блокирующая цепочка, которая приводит к зависанию репликации;
  • заказывая большой набор данных, который заполнил диск TempDB, который ... угадайте, что? Вызвала полное безумие :-)!
  • высокое кровяное давление для DBA, отвечающего за производство в эту ночь;

• чтение конфиденциальных данных (у разработчика не должно быть доступа к информации о кредитной карте или к личным данным пользователя);

Я уверен, что есть еще больше причин.

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

Пара вопросов для рассмотрения

• Являются ли данные чувствительными?
• Являются ли программисты частью основной доверенной команды или какой-либо оффшорной команды?
• Каков масштаб запрашиваемых данных с точки зрения влияния на производительность?
• Каков масштаб проекта или долларов?
• Насколько критична продолжительность работы?

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

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

Приспособьте свои методы к тому, что вы делаете.

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

1. Нам нужен доступ в реальном времени, чтобы следить за нашей ежедневной обработкой. (Несмотря на то, что у нас есть приборная панель, мы должны быть в состоянии пристально следить за всем. Хотя было бы неплохо иметь эту функцию на нашей приборной панели, мы обнаружили, что это непрактично.)
2. Нам нужен доступ в реальном времени для расследования любых производственных сбоев, потому что задержки могут оказать огромное влияние. (Я не собираюсь обсуждать наши неудачи здесь. Они бывают разных видов)
3. Мы часто должны делать пользовательские отчеты для бизнес-пользователей, и эта информация должна быть актуальной. (у dba нет времени на это, и у нас нет времени их ждать. хотя, конечно, не идеальный.)
4. Нам нужно проверить производственные развертывания / исправления DDL / DML. (Администраторы баз данных развертывают их, но только мы знаем, как это должно быть структурировано. Мы знаем больше о структуре нашей базы данных, чем администраторы баз данных. Здесь мы можем быть странными, но наша база данных очень сложна, потому что наш бизнес очень сложен.)

Производительность является проблемой. У нас есть разработчики, вызывающие замедление. Однако это единичные экземпляры, и наш SQL так сильно зависит от производительности, что наши разработчики редко понимают влияние своих запросов.

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

Я согласен, что бремя оправдания должно быть на тех, кто требует доступа. Обычно в среде, где я консультировался, у меня был доступ к производственным системам, где это была небольшая среда, и я был специалистом по поддержке. У меня был доступ к резервным копиям и т. Д., Где мне оказывали поддержку, и косвенный доступ (через выделенного разработчика поддержки) к рабочим данным.

Самое главное: вам нужен этот доступ, когда вы находитесь на крючке, чтобы все работало гладко, и вы должны ответить на вопрос финансового сотрудника о том, что что-то не работает. В этом случае вы не всегда можете работать даже с данными за день. С другой стороны, чем больше доступа, тем хуже. Обычно, как консультант, я стараюсь избегать такого рода доступа, если только он не нужен. Поскольку я работаю с финансовыми базами данных, последнее, что я хочу, - это обвинение во вводе моих собственных счетов :-D.

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

Большая проблема с моей стороны связана с доступом для записи. Если у разработчика нет доступа, то тем более у разработчика нет прав на запись. Если вы хотите проверить целостность книг, вы хотите сохранить доступ к записи как можно меньшему количеству людей. Журналы аудита гораздо проще проверить, если у разработчиков нет доступа. Если у разработчика есть права на чтение, то у вас всегда возникает вопрос, было ли какое-либо присоединение с эскалацией привилегий, которое может дать доступ на запись (возможно, внедрение SQL в хранимой процедуре?). Я часто имел полный доступ к платежной информации клиента, когда у меня был доступ к промежуточной среде. Если есть промежуточная среда, которая работает, я обычно буду активно просить не иметь доступа к производству, если это не необходимо.

Так что это не идеально, конечно. Разработчик может по-прежнему встраивать в приложение «черные двери», которые могут быть нелегко обнаружить, но этот подход является разумным подходом, учитывая тот факт, что резервные данные доступны за день до этого, и мне кажется, что это их проблема.

Надеюсь это поможет.

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

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

Разработчику по-настоящему не нужен доступ к производственной среде, просто с точки зрения разработчиков, если трудно воспроизвести серьезную ошибку.

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

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

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

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

Данные являются наиболее ценной частью большинства приложений!

Производительность может быть одной из причин.

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

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

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

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

Использование логинов SQL для предоставления доступа к таблицам только для чтения - это здорово. НО, что мешает им создать запрос с 20 объединениями или выполнить SELECT * из таблицы с миллионами записей? Эти запросы могут случайно убить производительность вашей базы данных и хранилища.

Моя компания Stackify придумала умный способ решить эту проблему. Разработчики могут выполнить запрос через наше программное обеспечение, и мы используем план запроса, чтобы убедиться, что это всего лишь оператор SELECT, а оценочная стоимость запроса низкая, и он вернет всего несколько записей. Таким образом, они не могут причинить много вреда. Мы также проверяем все запросы, которые они выполняют.

Это только одна из вещей, которые мы предоставляем. Посетите наш сайт http://www.Stackify.com, чтобы узнать больше о наших решениях поддержки DevOps .

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

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

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

Нет никогда!!

Вот почему у нас есть серверы разработки / тестирования / UAT. Данные из Production могут быть скопированы в тестовую среду, и разработчики могут продолжить их тестирование. Выборочные запросы также могут быть очень вредными в случае производственной среды. Это увеличивает нагрузку и в пиковое время может снизить общую производительность.

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

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

Никто (dev, dba, sa) не имеет доступа к любому серверу или базе данных в любой среде с обычным сетевым входом в систему. Все они имеют определенные учетные записи «admin», которые должны быть использованы. Да, обычно dba и sa используют их чаще, но даже они должны действовать осторожно. Я сожжен всеми.

Таким образом, в хороший день доступ к ИТ-роли не требуется. Тем не менее, дерьмо поражает поклонника, все руки на палубе, и нам нужны правильные люди, решающие проблему. Это обычно ведет разработчик, который знает приложение и ведет dba и sa к определенным пунктам. Это просто ненужная задержка или запрос и подтверждение.

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