Чи слід розробникам надати дозвіл на запит ( SELECT/ лише читання) виробничих баз даних? На попередньому місці, де я працював, команда розробників мала db_datareaderроль; де я зараз працюю, команда розробників не може навіть підключитися до виробничого екземпляра.

Один з тестових примірників - це копія виробництва, яка відновлюється з резервної копії виробництва раз на тиждень, так що проблем із розробниками, які насправді бачать дані, не виникає.

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

Це дійсно залежить від того, чи має розробник будь-які обов'язки щодо підтримки. Якщо вони знаходяться на гачку для підтримки третього рядка, тоді, ймовірно, потрібно буде переглянути виробничу базу даних для цього.

Зазвичай це погана ідея робити що-небудь на виробничому сервері, якщо це дійсно не потрібно робити там.

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

Якщо проблема полягає в тому, що у вас немає виробничих дзеркальних середовищ або будь-яких засобів, щоб розмістити копію виробничих даних кудись для своїх розробників, то це дещо інше питання. У такому випадку ваші розробники дійсно потребують хоча б одного дзеркального середовища. Якщо ви не можете бачити, у чому проблема в даних, то їх важко усунути.

Немає.

Розробники не повинні мати доступ до систем виробничої бази даних з наступних причин:

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

   1. Блокуйте таблиці, блокуючи інші критичні процеси.
   2. Зробіть кеш даних, змушуючи інші процеси перечитувати дані з диска.
   3. Оподатковуйте свій рівень зберігання, впливаючи на інші послуги, які поділяють цей об'єм.

2. Безпека : Ваша виробнича база може містити конфіденційну інформацію, наприклад:

   • паролі хешей
   • Платіжна інформація
   • інша особиста інформація

   Мати її мають лише ті, хто абсолютно потребує доступу до цієї інформації. У добре організованій компанії розробники не серед цих людей. Крім того, ваша компанія не зможе відповідати вимогам PCI та SOX, якщо її розробники отримають доступ до виробничих систем із цими даними.

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

   "Але це стосується і DBA! Вони могли це зробити!" Саме так. Ви хочете якомога менше суперузерів, як це відповідально можливо.

Так.

Розробники повинні мати доступ до виробничих систем.

У моєї компанії у нас є чотири команди, які займаються виробничими базами даних. Вони є:

1. Розробники , які розробляють та записують схему та код для баз даних. Вони не мають доступу до баз даних у виробництві. Хоча вони іноді сидять з адміністраторами або підтримують людей і допомагають їм подивитися щось наживо.
2. Адміністратори , які розгортають, контролюють та керують базами даних у виробництві.
3. Підтримуйте людей , які досліджують виробничі проблеми, що залежать від часу та надають зворотній зв’язок розробникам, щоб вони могли розробляти виправлення.
4. Люди з бізнес-аналітики , які витягують дані з баз даних виробництв, використовуючи регулярно оновлені копії цих баз даних, або ретельно написані та витяги з QA-ed (зазвичай розроблені адміністраторами).

Доцільно надати розробникам доступ до виробництва, коли у вас є певні недоліки в інших групах.

Наприклад:

• У вас немає команди підтримки. Хто знатиме, де шукати, щоб налагодити цю нестабільну виробничу проблему? Ваші розробники. Надайте їм доступ " розбити скло ".
• У вас немає команди команди BI. Ваші адміністратори не мають або хочуть нічого спільного з повідомленнями або витягами. Хто буде вирішувати звіт, який ваші виконавці бачать щоранку? Ваші розробники. Надайте їм обмежений доступ для налагодження цих звітів та витягів.
• У вас немає команди адміністратора. Ви в дуже маленькій або стартап-компанії, тому привітайтеся з "випадковим DBA". Ваші розробники подвоюються як ваші адміністратори, і тому їм потрібен повний доступ до виробництва.

Продуктивність буде великою причиною.

Тільки тому, що вони не можуть змінити дані, не означає, що вони не можуть впливати на сервер. Погано написаний запит може поставити виробниче середовище на коліна та потенційно спричинити інші проблеми (наприклад, переповнення tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Ось рецепт катастрофи. Зауважте, що це декартовий продукт із замовленням, а значить, він буде відсортований у tempDB.

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

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

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

Я вже бачив розробників протестувати або виконати запити на виробництво і прийняти його з - за невігластва. Сказавши це, розробники повинні брати на себе відповідальність за свої дії: якщо вони все-таки знімуть сервер, вони повинні відповідно постраждати. Мені когось понизили після одного інциденту ...

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

Також, чи існує середовище, в якому розробники можуть запускати запити на останні дані? У моєму останньому магазині продукт щодня відновлювався на тестовому сервері, щоб забезпечити це.

Я думаю, що відповідь, як і у багатьох речах ІТ, "залежить".

Масова база ERP з великою кількістю чутливої ​​інформації про компанію та клієнтів? Напевно, ні (як з міркувань безпеки, так і з точки зору продуктивності).

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

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

У звичайному 24/7 середовищі OLTP звичайний розробник не повинен бути дозволений у виробництві. Період! Якщо час від часу з'являється певна причина, тоді дозволи можуть бути надані за запитом. Але на звичайній основі ні.

Я бачив багато причин для цього:

• SELECT * з великої таблиці, що веде до:

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

• читання конфіденційних даних (розробник не повинен мати інформацію про кредитну карту ... або будь-які особисті дані користувача);

Я впевнений, що причин ще більше.

• Безпека: Можливо, є конфіденційна інформація, яка підлягає санітарній обробці, коли вона надає розробникам.
• Параноїя: Дехто може подумати, що ви все-таки можете зіпсувати дані, просто вибравши доступ.
• Продуктивність: Запит вимагає певних ресурсів, і ви не можете сказати, що ваші розробники ідеальні, коли вони пишуть код.

Пара предметів для розгляду

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

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

Більше доларів потребує більшої кількості процесів, необхідних суворіші стандарти практики розвитку.

Пристосовуйте свої практики до того, що ви робите.

Я працюю розробником дуже великої компанії. Усі наші розробники, які надаватимуть будь-яку підтримку (в основному всі вони), мають доступ до відповідних виробничих баз даних. Я можу говорити лише за свою конкретну команду, але я скажу вам, чому ми маємо доступ.

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

Продуктивність викликає занепокоєння. У нас є випадки, що розробники викликають уповільнення. Однак це поодинокі випадки, і наш SQL настільки обумовлений продуктивністю, що рідко наші розробники не розуміють впливу їх запитів.

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

Я погоджуюся, що тягар виправдання повинен лежати на тих, хто потребує доступу. Як правило, в середовищі, де я консультувався, я мав доступ до виробничих систем, де це було невелике середовище, і я був людиною, що надає підтримку. У мене був доступ до резервних копій і т.д., де я був підтримкою підтримки, і непрямий доступ (через спеціалізованого розробника підтримки) до виробничих даних.

Найголовніше: вам потрібен такий доступ, коли ви знаходитесь на гачку, щоб все нормально працювало, і ви повинні відповісти на запитання хлопця-фінансиста про те, що щось не працює. У такому випадку ви не завжди зможете працювати з даними навіть у добу. З іншого боку, чим більше доступу, тим гірше. Як правило, як консультант я схильний уникати отримання такого доступу, якщо це не потрібно. Оскільки я працюю над базами фінансових даних, останнє, що я хочу, - це звинувачення у введенні власних рахунків :-D.

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

Велике питання з моєї сторони пов'язане з доступом до запису. Якщо розробник не має доступу тоді, a fortiori, розробник не має доступу для запису. Якщо ви хочете перевірити цілісність книг, ви хочете забезпечити доступ до запису якомога менше людей. Слід перевірити набагато простіше, якщо розробники не мають доступу. Якщо розробник прочитав доступ, то у вас завжди виникає питання щодо того, чи було якесь приєднання ескалації привілеїв, яке може надати доступ до запису (можливо, вбудована в процедуру SQL ін'єкція?). Я часто мав повний доступ до інформації про виставлення рахунків клієнтові, коли мав доступ до інтерактивних середовищ. Якщо є таке інсценізаційне середовище, яке працює, я зазвичай активно прошу не мати доступу до виробництва, якщо це не потрібно.

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

Сподіваюся, це допомагає.

Редагувати: Просто додавши, що у великих середовищах, в яких я працював, я мав доступ до повних резервних даних, які часто становлять від декількох днів до декількох місяців для фінансової системи. Це завжди було досить добре для моєї роботи, і лише коли це відбулося, коли хлопці з фінансів потребували можливості перевірити новіші дані, щоб вони могли відповідати виробництву.

Відсутність доступу - це гарна річ і спосіб захистити розробників та інших людей від випадкового пошкодження даних або їх перегляду. Це також захищає компанії від порушення закону (тобто порушення Hipaa та конфіденційність)

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

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

Якщо дані потрібно звести до тестового середовища, тоді типовим є якийсь процес очищення даних, що може створити додаткову роботу.

Залежно від програмного забезпечення бази даних, яке використовується у виробництві, для розробника може знадобитися нова ліцензія, щоб отримати доступ до бази даних, що є великим витратом на просто доступ для читання.

Якщо ваша компанія не надає вам інструментів для налагодження чи дослідження виробничих проблем, це не тому, що у вас немає доступу до виробничих даних.

Дані - найцінніша частина більшості програм!

Ефективність може бути однією з причин.

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

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

Це залежить від DBA і наскільки він чи вона впевнений у розробнику. Зазвичай розробникам надаються запити (читання) привілеїв до виробничих баз даних. Як правило, розробники повинні працювати лише з тестовими / розробними базами даних.

Завдання полягає в тому, що більшість програмних програм керуються даними. Тож, коли ви намагаєтеся виправити проблему в додатку, вам дійсно потрібно побачити дані, які її ведуть. Тож розробникам справді потрібна певна форма доступу.

Чудово використовувати вхід у систему SQL, щоб дати їм лише доступ до таблиць. АЛЕ, що заважає їм створити запит з 20 приєднаннями або зробити SELECT * з таблиці з мільйонами записів? Ці запити можуть випадково вбити продуктивність вашої бази даних та сховища.

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

Це лише одна із речей, які ми надаємо. Перевірте нас на веб- сайті http://www.Stackify.com, щоб дізнатися більше про наші рішення щодо підтримки DevOps .

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

Незалежно від причини, з якої ви не могли б дозволити спеціальні запити безпосередньо до таблиць баз даних, може бути зроблено випадок, коли запити дозволяють переглядати та зберігати процедури. Використовуючи дозволи бази даних, ви можете запобігти SELECT запитам, які безпосередньо повертаються до таблиць, і навіть обмежити, які перегляди та збережені процедури даному користувачеві мають доступ. Цей метод не тільки надає гнучкість вашій базі користувачів, але також захищає цілісність та надійність даних при правильній реалізації.

У нашій компанії ми підтримуємо раби виробничих баз даних, лише для читання, на які не покладаються виробничі служби. Ми надаємо розробникам доступ до них для доступу до виробничих даних. Якщо є конфіденційні дані (інформація про клієнта, інформація про платежі тощо), ми обмежуємо тиражування цих таблиць і підтримуємо зразок таблиці даних на підлеглому сервері.

Ні ніколи!!

Ось чому у нас є сервери розробки / тестування / UAT. Дані з виробництва можна скопіювати на тестове середовище, і розробники можуть продовжити тестування. Вибір запитів може бути дуже шкідливим і у випадку виробничого середовища. Це збільшує навантаження і в піковий час може знизити всю продуктивність.

Будь-яка необхідна їм інформація повинна надходити через DBA, який може виконати те, що вони хочуть (Вибрати) та надіслати їм результати. Так ми робимо в нашому середовищі.

Я не впевнений, чому всі припускають, що розробники дурні і нічого не знають. Я отримую зразок тонни різних ролей, коли вони заплуталися і не повинні бути "у виробництві". У мене DBA, Sys Admins, Network Admins, Developers і т. Д. ... все заплутано.

Ніхто (dev, dba, sa) не має доступу до будь-якого сервера чи бази даних в будь-якому середовищі, де нормальний мережевий логін. Усі вони мають специфічні "адміністраторські" акаунти, які потрібно використовувати. Так, зазвичай dba і sa використовують їх частіше, але навіть вони повинні легше ступати. Я всіх спалив.

Тож у добрий день жодна ІТ-роль не потребує доступу. Однак ш! Т потрапляє у вентилятор, усі руки на палубі, і нам потрібні потрібні люди для вирішення проблеми. Зазвичай це веде розробник, який знає додаток та керує dba і sa до певних моментів. Це просто непотрібна затримка або прохання та затвердження.

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