Estou acostumado a trabalhar em ambientes muito seguros e, por isso, projeto minhas permissões com um grau muito fino de granularidade. Uma coisa que eu normalmente faço é explicitamente DENYusuá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 sobre eles.
Recentemente, durante uma reunião de equipe, um desenvolvedor levantou a questão de que a lógica para garantir que os campos nunca sejam atualizados deve estar contida na camada de aplicativo e não na camada de banco de dados, caso "eles precisem atualizar os valores por algum motivo". Para mim, isso soa como a mentalidade típica de um desenvolvedor (eu sei, eu costumava ser um!)
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 do aplicativo significa que ele afeta apenas as pessoas que usam a camada do aplicativo e também pressupõe que o código estará livre de bugs e a segurança em torno desses caminhos de código será à prova de balas. Essas são grandes suposições.
Se eles absolutamente precisam ser atualizados, isso pode ser feito por uma pessoa não afetada pelo explícito
DENY, ou a pessoa pode ser movida temporariamente para uma função que não é afetada, ouDENYpode ser removida temporariamente. Essas são coisas fáceis para você, como DBA, configurar a auditoria. No aplicativo? Não muito.Eu concordo completamente com @Aaron no aspecto técnico disso.
Além disso, eu diria, em relação às melhores práticas:
Dado que é trabalho/responsabilidade do DBA proteger os dados, a abordagem padrão deve ser fazer exatamente isso, conforme o DBA achar adequado e exigir um caso de negócios sólido para fazer uma alteração. Um hipotético-futuro-potencial-um pouco-possível-dado-certas-condições-que-serão-pensadas-mais-tarde-e-confirmadas-bem-depois-de-isso-mas-talvez-mudou-mais-tarde-ou-talvez-nunca -o motivo que realmente aconteceu (ou seja, "por algum motivo") parece uma justificativa um pouco frágil, especialmente quando o tópico está mudando um padrão / prática da empresa.
Nunca confie em alguém que quer fazer mudanças em algo que nunca deveria mudar ;-), (ainda mais se eles nem sabem porque querem).
Diga ao desenvolvedor que ele pode adicionar essa lógica ao código do aplicativo para evitar essas atualizações. Mas, também que você não vai remover o arquivo
DENY. Se / quando o dia chegar (epode nãoprovavelmente não) que alguém receba um erro ao tentar atualizar uma dessas colunas, então você poderá discutir se removerá ou não oDENY, o que exigirá uma justificativa real e sólida do motivo pelo qual alguém estaria atualizando esse valor no primeiro lugar.O ponto é: deve haver um caso de negócios real orientando o que as pessoas gastam seu tempo. O tempo está em alta demanda, mas é escasso, então você (e todos os outros) têm 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 vs guias, alguém?) e você pode passar anos mudando isso para frente e para trás se esse desenvolvedor sair e for substituído por alguém que se oponha fortemente a esses campos serem atualizáveis. Se nenhum cliente está solicitando isso (ou algo que exija), e não há benefício tangível (mesmo benefício atrasado, como quitação de dívida técnica, que é difícil de mostrar o ROI, mas vale muito a pena, pois o as chances de que o tempo gasto não resulte em economias de custos reais a longo prazo são quase nulas), em seguida, feche o pedido ou coloque-o no backlog em baixa prioridade, mesmo nos casos em que o idealismo diz que deve ser alterado (este não é um desses casos, mas mencionado para aqueles que pensam que é). Idealismo é ótimo para conversas, mas empresas não podem pagar aluguel, utilidades, funcionários, impostos, etc com ideais.
@jpmc26 está correto sobre a necessidade de comunicação, mas não exatamente correto sobre o que precisa ser comunicado. Sim, você deve ouvir o que os outros estão solicitando e procurar entender o raciocínio deles, o que inclui fazer perguntas se você não tiver certeza sobre alguma coisa.
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, você 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, tipos de computador, não somos (geralmente) conhecidos por nossas habilidades de comunicação inter-humana, então, você realmente precisa ter certeza de que os outros o entendem , qual é o seu raciocínio, quais são suas responsabilidades e como essas coisas realmente funcionam .
Eu coloquei essa última parte porque há um alto grau de mal-entendido, desinformação e falta de conhecimento por aí (até 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 (@Aaron se referiu a isso como "restrição de fluxo de trabalho vs restrição de dados" em um comentário sobre a pergunta) e que, embora a maioria dos dados naturalmente pertença ao aplicativo, alguns dados realmente pertence ao modelo de dados. Um DBA deve ditar aos desenvolvedores como os dados do aplicativo serão restritos? Claro que não. É nosso trabalho oferecer como os dados do aplicativo podemser constrangido. Se uma violação de uma regra de negócios relacionada aos dados do aplicativo puder causar danos e o aplicativo não for 100% a única maneira de manipular os dados, talvez uma restrição de verificação possa realmente ajudar (e eles não são difíceis de alterar ou remover ).
MAS, vindo de outra direção, os desenvolvedores não devem ditar como os dados do modelo de dados (ou seja, meta-dados) 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 apenas 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 significa que você está prestes a começar a adicionar restrições ou restrições aos dados do aplicativo. MAS, será difícil levar a conversa adiante de uma maneira verdadeiramente produtiva se essa distinção não for compreendida.
Então:
DENYnas colunas de auditoria e propus o mesmo em lugares em que trabalhei no passado.Curiosamente, tive uma conversa muito semelhante com um desenvolvedor líder (muito bom), talvez em 2000, quando comecei a adicionar chaves estrangeiras. Ele argumentou (com bastante seriedade) que era um excesso de engenharia / idealismo desnecessário (algo assim, já se passaram 17 anos desde aquela conversa) e não valeu a pena o desempenho. Ele deixou bem claro que a limpeza de dados relacionados deve ser tratada na camada do aplicativo. (sim, eu adicionei os FKs porque ele não seria o único a limpar os dados órfãos que seu código inevitavelmente criaria)
Anos depois, ele se desculpou 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
created_on. Este exemplo em particular é uma restrição extremamente modesta.O desenvolvedor provavelmente está preocupado que a equipe de DBA (que inclui você) pretenda adicionar tantas ou tão complexas restrições que comece a impedir sua capacidade de trabalhar efetivamente, ou que quando algo fora do comum surgir ou algo mudar, a equipe de DBA vai resistir às mudanças e impedir a capacidade da equipe de desenvolvedores de progredir. Esta é uma preocupação relativamente razoável. As burocracias e a perda da capacidade de efetuar as mudanças necessárias são ocorrências reais, e a codificação de muitas restrições ou restrições complexas pode ter efeitos negativos no desempenho e na capacidade de responder às mudanças nos requisitos.
O desenvolvedor pode nem perceber que essa é a natureza de suas preocupações. Eles provavelmente estão acostumados a ter domínio livre do banco de dados, e desistir desse nível de liberdade é difícil, especialmente se você sabe que nunca abusou dele. Portanto, seu senso de preocupação em perder a capacidade de fazer o que precisam pode ser vago e mal definido.
Portanto, há algumas coisas que você deve fazer para aliviar esses medos:
Você tem declarações conflitantes
Cabe realmente a você ditar o primeiro?
Você joga no mínimo privilégio para fazer o aplicativo funcionar sem prova 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 muitas vezes existem regras de negócios que vão além do que um banco de dados pode fazer.
VendorID nunca deve mudar, mas e se dois fornecedores se fundirem. Nunca diga nunca.
Se a equipe do aplicativo contaminar os dados e eles disseram que precisavam dessa autoridade, ela está com eles. Se as equipes de aplicativos funcionarem para você, você poderá ditar.
A pergunta apropriada é se o aplicativo atualizar os dados.