Devo explicitamente negar a atualização para colunas que não devem ser atualizadas?

Estou acostumado a trabalhar em ambientes muito seguros e, portanto, projeto minhas permissões com um grau muito fino de granularidade. Uma coisa que normalmente faço é explicitamente DENYaos usuários a capacidade de UPDATEcolunas que nunca devem ser atualizadas.

Por exemplo:

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

Essas duas colunas nunca devem ser alteradas depois que o valor for definido. Portanto, eu explicitamente DENYa UPDATEpermissão deles.

Recentemente, durante uma reunião de equipe, um desenvolvedor enfatizou que a lógica para garantir que os campos nunca sejam atualizados deve estar contida na camada do aplicativo e não na camada do banco de dados no caso de "eles precisarem atualizar os valores por algum motivo". Para mim, isso soa como uma mentalidade típica de desenvolvedor (eu sei, eu costumava ser uma!)

Sou o arquiteto sênior da minha empresa e sempre trabalhei com o princípio da menor quantidade de privilégios necessários para que o aplicativo funcionasse. Todas as permissões são auditadas regularmente.

Qual é a melhor prática neste cenário?

O argumento não faz sentido. Eu sempre quero os controles e restrições o mais próximo possível dos dados. Colocá-lo na camada de aplicativo significa que ele afeta apenas as pessoas que estão usando a camada de aplicativo e também pressupõe que o código estará livre de erros e a segurança em torno desses caminhos de código será à prova de balas. Essas são grandes suposições.

Se eles absolutamente precisarem ser atualizados, isso poderá ser feito por uma pessoa não afetada pelo explícito DENY, ou a pessoa poderá ser temporariamente movida para uma função que não seja afetada ou DENYpoderá ser removida temporariamente. São coisas fáceis para você, como o DBA, configurar a auditoria. No aplicativo? Não muito.

Concordo plenamente com a @Aaron no aspecto técnico disso.

Além do que eu diria, com relação às melhores práticas:

1. Dado que é dever / responsabilidade do DBA proteger os dados, a abordagem padrão deve ser exatamente isso, conforme o DBA considerar adequado, e exigir um caso comercial sólido para fazer uma alteração. Um potencial hipotético-futuro-potencialmente-possível-dado-determinadas-condições-que-serão-brainstormed-mais-tarde-e-confirmado-bem-depois-mas-talvez-mudado-mais-tarde-ou-talvez-nunca A razão que realmente acontece (ou seja, "por alguma razão") parece um pouco frágil de justificativa, especialmente quando o tópico está mudando o padrão / prática da empresa.

2. Nunca confie em alguém que queira fazer alterações em algo que nunca deve mudar ;-), (ainda mais se elas nem sabem por que querem).

3. Diga ao desenvolvedor que é possível adicionar essa lógica ao código do aplicativo para impedir essas atualizações. Mas também você não removerá o DENY. Se / quando chegar o dia (epode nãoprovavelmente não vai) que alguém receba um erro ao tentar atualizar uma dessas colunas, então você pode discutir se deseja remover ou não o DENY, o que exigirá uma justificação sólida e real do motivo pelo qual alguém estaria atualizando esse valor no diretório primeiro lugar.

   A questão é: deve haver um caso de negócios real direcionando o que as pessoas gastam seu tempo. O tempo está em alta demanda e escasso fornecimento, para que você (e todos os demais) tenham coisas mais importantes a fazer do que mudar o sistema com base na opinião de alguém. Sempre haverá uma variedade de opiniões (espaços versus guias, alguém?) E você pode passar anos mudando isso de um lado para o outro se esse desenvolvedor sair e for substituído por alguém que se oponha fortemente àqueles campos que são atualizáveis. Se nenhum cliente estiver solicitando isso (ou algo que exija isso) e não houver benefício tangível (mesmo benefício atrasado, como a limpeza de dívidas técnicas, que é difícil de mostrar o ROI, mas vale muito a pena, pois o as chances de o tempo gasto não resultar em economia de custo real a longo prazo são reduzidas a zero), então feche a solicitação ou coloque-a no backlog com baixa prioridade, mesmo nos casos em que o idealismo diga que deve ser alterado (esse não é um desses casos, mas mencionado para os que pensam que é). O idealismo é ótimo para conversas, mas as empresas não podem pagar aluguel, serviços públicos, funcionários, impostos etc. com ideais.

4. @ jpmc26 está correto sobre a necessidade de comunicação, mas não exatamente sobre o que precisa ser comunicado. Sim, você deve ouvir o que os outros estão solicitando e procurar entender seu raciocínio, o que inclui fazer perguntas se você não tiver certeza sobre algo.

   NO ENTANTO, o banco de dados não é subserviente ao aplicativo e os profissionais de banco de dados (administradores, engenheiros, qualquer que seja o nome que sua empresa use) não são subservientes aos desenvolvedores (como parece estar implícito nessa resposta). Você não trabalha para os desenvolvedores, trabalha para a empresa, da mesma forma que eles. Este é um esforço de equipe e você não deve pedir perdão por fazer seu trabalho. Dito isto, nós Computery tipos não são (em geral) conhecido por nossas habilidades de comunicação inter-humanos, por isso, você realmente precisa ter certeza de que os outros a entender que você , o que seu raciocínio é, quais são as suas responsabilidades, e como essas coisas realmente funciona .

   Coloquei essa última parte porque há um alto grau de incompreensão, desinformação e falta de conhecimento por aí (mesmo alguns aqui nesta página). Por exemplo, parece haver essa noção de que todas as regras são regras de negócios. Precisamos explicar que há uma distinção entre regras de dados e regras de negócios (a @Aaron se refere a isso como "restrição de fluxo de trabalho versus restrição de dados" em um comentário sobre a pergunta) e que, embora a maioria dos dados pertençam naturalmente ao aplicativo, alguns dados realmente pertence ao modelo de dados. Um DBA deve ditar aos desenvolvedores como os dados do aplicativo serão restringidos? Claro que não. É nosso trabalho oferecer como os dados do aplicativo podemser constrangido. Se uma violação de uma regra comercial relacionada aos dados do aplicativo puder causar danos, e o aplicativo não for a única maneira 100% de manipular os dados, talvez uma restrição de verificação possa realmente ajudar (e não é difícil alterar ou remover )

   MAS, vindo de outra direção, os desenvolvedores não devem ditar como os dados do modelo de dados (ou seja, metadados) são tratados. Isso inclui campos de auditoria (como as colunas created_on/ created_by) e as colunas PK / FK (esses valores devem ser conhecidos internamente e não fornecidos aos clientes). Esses dados não são o que o aplicativo armazena sobre os clientes (mesmo que o aplicativo possa ver os valores e até mesmo usá-los, como com IDs), é o que o modelo de dados armazena sobre os dados do aplicativo.

   Portanto, faz sentido usar regras de dados para proteger os dados do modelo de dados. E isso não implica que você esteja prestes a começar a adicionar restrições ou restrições nos dados do aplicativo. MAS, será difícil avançar a conversa de uma maneira verdadeiramente produtiva se essa distinção não for entendida.

Tão:

1. Sim, gosto da ideia do explícito DENYnas colunas de auditoria e propus o mesmo em locais em que trabalhei no passado.

2. Curiosamente, tive uma conversa muito parecida com um desenvolvedor líder (muito bom), talvez em 2000, quando comecei a adicionar chaves estrangeiras. Ele argumentou (com sinceridade) que era um excesso de engenharia / idealismo desnecessário (algo assim, faz 17 anos desde aquela conversa) e não vale o desempenho atingido. Ele ficou bastante claro que a limpeza dos dados relacionados deve ser tratada na camada do aplicativo. (sim, eu adicionei os FKs porque ele não seria o responsável por limpar os dados órfãos que seu código inevitavelmente criaria)

   Anos depois, ele pediu desculpas por fazer esse argumento ;-)

Este é provavelmente um problema XY. O desenvolvedor provavelmente não está especialmente preocupado em bloquear atualizações para um campo verdadeiramente constante como esse created_on. Este exemplo em particular é uma restrição extremamente modesta.

O desenvolvedor provavelmente está preocupado com o fato de a equipe do DBA (que inclui você) pretender adicionar tantas ou complexas restrições que ele comece a impedir sua capacidade de trabalhar efetivamente, ou que, quando algo fora do comum surge ou algo muda, a equipe do DBA vai resistir às mudanças e impedir a capacidade da equipe de desenvolvedores de progredir. Essa é uma preocupação relativamente razoável. Burocracias e perda da capacidade de efetuar as mudanças necessárias são ocorrências reais, e a codificação de muitas ou complexas restrições pode ter efeitos negativos no desempenho e na capacidade de responder a mudanças nos requisitos.

O desenvolvedor pode nem perceber que essa é a natureza de suas preocupações. Eles provavelmente estão acostumados a reinar livremente no banco de dados e abrir mão desse nível de liberdade é difícil, especialmente se você sabe que nunca o abusou. Portanto, o senso de preocupação deles em perder a capacidade de fazer o que precisam pode muito bem ser vago e mal definido.

Portanto, há algumas coisas que você deve fazer para amenizar esses medos:

1. Comunique-se fortemente com os desenvolvedores. Certifique-se de entender as necessidades dos recursos que eles estão tentando criar e de responder às mudanças que ocorrerem. Ouça o que eles têm a dizer e trabalhe duro para encontrar uma solução que equilibre as preocupações deles com a sua. Esteja disposto a se curvar quando tiverem necessidades legítimas. Verifique se eles sabem que você é aliado na criação do software.
2. Seja cauteloso ao impor restrições. Restrições, mesmo aquelas destinadas a fornecer integridade e segurança, podem dificultar a adaptação às mudanças ou lidar com circunstâncias imprevistas. Portanto, entenda que cada restrição que você adiciona tem a mesma probabilidade de ter um custo associado a ela, além de economizar custos (com a possível exceção de chaves primárias e estrangeiras, que praticamente não têm desvantagens). Tenha certeza de que as restrições impostas são realmente necessárias ou benéficas.
3. Não vejo nenhum sinal de que você esteja fazendo isso, mas quero mencioná-lo para outros leitores: não visualize os dados ou o banco de dados como responsabilidade sua ou da sua equipe. Os dados são um ativo para toda a empresa. Sem um sistema para armazená-lo (o banco de dados) e scripts, ferramentas ou aplicativos para criar, atualizar e buscar, os dados são inúteis. Como todos devem usar esse ativo, os dados são de responsabilidade de todos. O próprio banco de dados é apenas uma parte da obtenção de valor dos dados.

Você tem declarações conflitantes

• Colunas que nunca devem ser atualizadas
• Eles precisam atualizar os valores por algum motivo

Cabe a você ditar o primeiro?

Você oferece o mínimo de privilégios para que o aplicativo funcione sem provas de que o aplicativo nunca precisará atualizar o valor.

Quem é responsável pela integridade dos dados?

Com restrições SQL, você pode garantir a integridade dos dados? Não, você não pode, pois geralmente existem regras de negócios que vão além do que um banco de dados pode fazer.

O Código do Fornecedor nunca deve mudar, e se dois fornecedores forem mesclados. Nunca diga nunca.

Se a equipe do aplicativo contaminar os dados e disserem que precisavam dessa autoridade, ela estará neles. Se as equipes de aplicativos funcionarem para você, você pode ditar.

A pergunta apropriada é se o aplicativo deve atualizar os dados.