Должен ли я явно ОТКАЗАТЬ ОБНОВЛЕНИЕ столбцов, которые не должны быть обновлены?

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

Например:

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

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

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

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

Какова лучшая практика в этом сценарии?

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

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

Я полностью согласен с @Aaron по техническим аспектам этого.

Помимо этого, я бы сказал, в отношении лучших практик:

1. Принимая во внимание, что работа / ответственность администратора баз данных заключается в защите данных, подход по умолчанию должен состоять в том, чтобы делать именно это, как администратор базы данных считает целесообразным, и требовать веского экономического обоснования для внесения изменений. Гипотетический потенциальный будущий, несколько возможный, учитывая определенные условия, которые будут подвергнуты мозговому штурму, позже, и подтверждены, гораздо позже, но, может быть, изменились, позже или, возможно, никогда Фактически возникающая причина (то есть, «по какой-то причине») кажется немного неубедительной, особенно когда тема меняет стандарт / практику компании.

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

3. Скажите разработчику, что он может добавить такую ​​логику в код приложения, чтобы предотвратить эти обновления. Но также то, что вы не собираетесь удалять DENY. Если / когда наступит деньможет невероятно, не будет) что кто-то получит ошибку при попытке обновить один из этих столбцов, тогда вы можете обсудить, удаляете ли вы или нет DENY, что потребует фактического, веского обоснования того, почему кто-то будет обновлять это значение в первое место.

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

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

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

   Я включил эту последнюю часть, потому что там есть высокая степень непонимания, дезинформации и недостатка знаний (даже некоторые прямо здесь, на этой самой странице). Например, кажется, существует понятие, что все правила являются бизнес-правилами. Нам нужно объяснить, что существует различие между правилами данных и бизнес-правилами (@Aaron в комментарии к вопросу назвал это «ограничение рабочего процесса против ограничения данных») и что большинство данных, естественно, принадлежит приложению, некоторые данные на самом деле принадлежит модели данных. Должен ли администратор БД диктовать разработчикам, как будут ограничены данные приложения ? Конечно нет. Наша задача - предложить, как данные приложения могутбыть ограниченным. Если нарушение бизнес-правила, связанного с данными приложения, может нанести вред, и приложение не является 100% -ным способом манипулирования данными, тогда, возможно, ограничение проверки может действительно помочь (и их нетрудно изменить или удалить). ).

   НО, исходя из другого направления, разработчики не должны диктовать, как обрабатываются данные модели данных (т.е. метаданные). Это включает в себя поля аудита (например, столбцы created_on/ created_by) и столбцы PK / FK (предполагается, что эти значения известны только для внутреннего использования и не предоставляются клиентам). Эти данные не то, что приложение хранит о клиентах (даже если приложение может видеть значения и даже использовать их, например, с идентификаторами), это то, что модель данных хранит о данных приложения.

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

Так:

1. Да, мне нравится идея явного DENYв колонках аудита, и я предлагал то же самое в местах, где я работал в прошлом.

2. Кстати, у меня был очень похожий разговор с ведущим разработчиком (очень хороший), возможно, в 2000 году, когда я начал добавлять внешние ключи. Он утверждал (вполне искренне), что это было излишним чрезмерным инженерным / идеализмом (что-то в этом роде, прошло 17 лет с тех пор), и оно не стоило удара производительности. Он был совершенно уверен, что очистка связанных данных должна быть обработана на уровне приложения. (да, я добавил FK, потому что он не собирался очищать потерянные данные, которые неизбежно создаст его код)

   Спустя годы он извинился за этот аргумент ;-)

Это, вероятно, проблема XY. Разработчик, вероятно, не особенно обеспокоен блокировкой обновлений в действительно постоянном поле, как created_on. Этот конкретный пример является чрезвычайно скромным ограничением.

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

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

Итак, есть пара вещей, которые вы должны сделать, чтобы смягчить эти страхи:

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

У вас есть противоречивые заявления

• Столбцы, которые никогда не должны обновляться
• Они должны обновить значения по какой-то причине

Это действительно зависит от вас, чтобы продиктовать первое?

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

Кто несет ответственность за целостность данных?

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

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

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

Соответствующий вопрос - должно ли приложение когда-либо обновлять данные.