Чи слід явно ЗАБУДИТИ ОНОВЛЕННЯ до стовпців, які не слід оновлювати?

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

Наприклад:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

Ці два стовпці ніколи не слід змінювати після встановлення значення. Тому я б явно дозвіл на них.DENYUPDATE

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

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

Яка найкраща практика у цьому сценарії?

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

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

Я повністю погоджуюся з @Aaron щодо технічного аспекту цього.

Крім того, я б сказав, щодо найкращих практик:

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

2. Ніколи не довіряйте тому, хто хоче змінити те, що ніколи не повинно змінюватися ;-), (тим більше, якщо вони навіть не знають, чому цього хочуть).

3. Повідомте розробнику, що вони можуть додати таку логіку до коду програми, щоб запобігти цим оновленням. Але також і те, що ви не збираєтесь видаляти DENY. Якщо / коли день коли-небудь настане (і цене можемабуть, не буде) якщо хтось отримує помилку, намагаючись оновити один із цих стовпців, тоді ви можете обговорити питання про те, видалити ви чи ні DENY, що вимагатиме фактичного, ґрунтовного обґрунтування того, чому хтось буде оновлювати це значення в першість.

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

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

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

   Я вкладаю цю останню частину, тому що там є високий ступінь нерозуміння, дезінформації та браку знань (навіть деякі тут на цій самій сторінці). Наприклад, мабуть, існує таке поняття, що всі правила - це бізнес-правила. Нам потрібно пояснити, що існує різниця між правилами даних та правилами бізнесу (@Aaron назвав це у коментарі до питання "обмеження робочого процесу проти обмеження даних"), і хоча більшість даних, природно, належать додатку, деякі дані насправді належить до моделі даних. Якщо адміністратор бази даних диктат до розробників , як дані додатки будуть стримуватися? Звичайно, ні. Це наша робота , щоб підносити як дані додатки балончикабути обмеженим. Якщо порушення ділового правила, пов’язаного з даними програми, може заподіяти шкоду, а додаток не є стовідсотковим способом маніпулювання даними, можливо, можливо перевірка обмеження може дійсно допомогти (і їх не важко змінити або видалити ).

   Але, виходячи з іншого напрямку, розробники не повинні диктувати, як обробляються дані даних (тобто метадані). Сюди входять поля аудиту (наприклад, created_on/ created_byстовпці) та стовпці PK / FK (ці значення повинні бути відомі лише внутрішньо і не надаватися клієнтам). Ці дані не є тим, що додаток зберігає у клієнтів (навіть якщо програма може бачити значення та навіть використовувати їх, наприклад, з ідентифікаторами), це те, що зберігає модель даних про дані програми.

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

Так:

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

2. Анекдотично у мене була дуже схожа розмова з провідним розробником (дуже хорошим), можливо, у 2000 році, коли я почав додавати іноземні ключі. Він стверджував (досить щиро), що це непотрібна надмірна інженерія / ідеалізм (щось подібне, минуло 17 років з тієї розмови) і не варто вдаватися до виступу. Йому було цілком зрозуміло, що очищення пов’язаних даних слід обробляти на рівні додатків. (так, я додав ФК, тому що він не збирався прибирати осиротілих даних, які його код неминуче створить)

   Через роки він вибачився за аргументацію ;-)

Ймовірно, це проблема XY. Розробник, ймовірно, не особливо переймається блокуванням оновлень для справді постійного поля, як-от created_on. Цей конкретний приклад є надзвичайно скромним обмеженням.

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

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

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

1. Сильно спілкуйтеся з розробниками. Переконайтеся, що ви розумієте потреби функцій, які вони намагаються створити, і переконайтеся, що ви реагуєте, коли відбудуться зміни. Послухайте, що вони мають сказати, і наполегливо працюйте, щоб знайти рішення, яке врівноважує їхні проблеми з вашими. Будьте готові зігнутись, коли у них є законні потреби. Переконайтеся, що вони знають, що ви союзник у створенні програмного забезпечення.
2. Будьте обережні щодо обмеження. Обмеження, навіть ті, що мають на меті забезпечити цілісність та безпеку, можуть ускладнити адаптацію до змін або вирішення непередбачених обставин. Отож розумійте, що кожне додане вами обмеження настільки ж ймовірно, що пов’язане з ним вартість, оскільки це, можливо, заощадить витрати (за можливим винятком первинних та зовнішніх ключів, які практично не мають недоліків). Будьте впевнені, що обмеження, які ви накладаєте, справді потрібні або вигідні.
3. Я не бачу жодної ознаки, що ви це робите, але хочу зазначити це для інших читачів: не розглядайте дані чи базу даних як відповідальність вашої чи вашої команди. Дані є активом для всієї компанії. Без системи для його зберігання (бази даних) та сценаріїв, інструментів або додатків для їх створення, оновлення та отримання даних дані нічого не варті. Оскільки всі повинні використовувати цей актив, дані - це відповідальність кожного. Сама база даних є лише однією частиною отримання цінності від даних.

У вас суперечливі твердження

• Стовпці, які ніколи не слід оновлювати
• Їм потрібно оновити значення з певних причин

Чи насправді вам доводиться диктувати першим?

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

Хто відповідає за цілісність даних?

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

VendorID ніколи не повинен змінюватися, але що робити, якщо два постачальника злиття. Ніколи не кажи ніколи.

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

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