Должны ли разработчики иметь возможность запрашивать производственные базы данных?

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

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

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

148 голосов | спросил Tom Hunter 6 Jpm1000000pmFri, 06 Jan 2012 19:57:00 +040012 2012, 19:57:00

19 ответов


142

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

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

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

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

ответил ConcernedOfTunbridgeWells 6 Jpm1000000pmFri, 06 Jan 2012 20:13:06 +040012 2012, 20:13:06
128

Нет.

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

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

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

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

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

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

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

Да.

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

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

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

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

Например:

  • У вас нет группы поддержки. Кто будет знать, где искать отладочную проблему с учетом времени? Ваши разработчики. Предоставьте им разрыв стекла "доступ.
  • У вас нет команды BI. Ваши администраторы не имеют или не хотят иметь ничего общего с отчетами или выдержками. Кто собирается расследовать отчет, который ваши руководители видят каждое утро? Ваши разработчики. Предоставьте им ограниченный доступ для отладки этих отчетов и выписок.
  • У вас нет команды администратора. Вы находитесь в очень маленькой или стартовой компании, поэтому поздоровайтесь с «случайным администратором баз данных». Ваши разработчики удваиваются как ваши администраторы и, следовательно, нуждаются в полном доступе к производству.
ответил Nick Chammas 6 Jpm1000000pmFri, 06 Jan 2012 21:49:33 +040012 2012, 21:49:33
74

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

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

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

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

ответил JNK 6 Jpm1000000pmFri, 06 Jan 2012 20:03:17 +040012 2012, 20:03:17
31

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

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

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

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

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

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

ответил gbn 6 Jpm1000000pmFri, 06 Jan 2012 20:58:29 +040012 2012, 20:58:29
19

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

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

  • SELECT * из большой таблицы, ведущей к:

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

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

ответил Marian 6 Jpm1000000pmFri, 06 Jan 2012 21:14:56 +040012 2012, 21:14:56
18
  • Безопасность: может быть конфиденциальная информация, которая дезинфицируется, когда они делают ее доступной для разработчиков.
  • Паранойя: некоторые могут подумать, что вы все равно можете испортить данные, просто выберите доступ.
  • Производительность. Запрос требует некоторых ресурсов для выполнения, и вы не можете сказать мне, что ваши разработчики идеальны, когда пишут код.
ответил Paul 6 Jpm1000000pmFri, 06 Jan 2012 20:14:30 +040012 2012, 20:14:30
18

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

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

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

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

ответил db2 6 Jpm1000000pmFri, 06 Jan 2012 20:57:17 +040012 2012, 20:57:17
14

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

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

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

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

Адаптируйте свои действия к тому, что вы делаете.

ответил Jason Sebring 6 Jpm1000000pmFri, 06 Jan 2012 23:56:16 +040012 2012, 23:56:16
13

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

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

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

ответил user606723 6 Jpm1000000pmFri, 06 Jan 2012 21:21:49 +040012 2012, 21:21:49
10

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

ответил jl01 6 Jpm1000000pmFri, 06 Jan 2012 21:54:23 +040012 2012, 21:54:23
9

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

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

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

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

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

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

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

ответил Chris Travers 30 AM000000100000003031 2012, 10:25:30
8

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

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

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

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

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

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

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

ответил SoftwareCarpenter 7 Jpm1000000pmSat, 07 Jan 2012 23:15:50 +040012 2012, 23:15:50
7

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

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

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

ответил JSR 6 Jpm1000000pmFri, 06 Jan 2012 20:06:45 +040012 2012, 20:06:45
7

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

ответил MarlonRibunal 6 Jpm1000000pmFri, 06 Jan 2012 21:34:56 +040012 2012, 21:34:56
7

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

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

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

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

ответил Matt from Stackify 30 AM00000050000004031 2012, 05:18:40
6

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

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

ответил Tom Resing 6 Jpm1000000pmFri, 06 Jan 2012 22:29:26 +040012 2012, 22:29:26
4

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

ответил Ryan Waldron 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 24 Sep 2014 23:22:21 +0400 2014, 23:22:21
0

No..Never !!

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

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

ответил Ramakant Dadhichi 26 PMpThu, 26 Apr 2018 13:37:39 +030037Thursday 2018, 13:37:39
-1

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

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

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

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

ответил Phil 15 FebruaryEurope/MoscowbFri, 15 Feb 2013 23:57:16 +0400000000pmFri, 15 Feb 2013 23:57:16 +040013 2013, 23:57:16

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132