¿Debo explícitamente DENEGAR ACTUALIZACIÓN a las columnas que no deben actualizarse?

Estoy acostumbrado a trabajar en entornos muy seguros y por eso diseño mis permisos con un grado de granularidad muy fino. Una cosa que normalmente hago es explícitamente a los DENYusuarios la capacidad de UPDATEcolumnas que nunca deben actualizarse.

Por ejemplo:

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

Estas dos columnas nunca deben cambiarse una vez que se ha establecido el valor. Por lo tanto, lo haría de manera explícita DENYel UPDATEpermiso de ellos.

Recientemente, durante una reunión de equipo, un desarrollador planteó el punto de que la lógica para garantizar que los campos nunca se actualicen debe estar contenida dentro de la capa de aplicación y no en la capa de la base de datos en caso de que "necesiten actualizar los valores por alguna razón". Para mí, eso suena como la típica mentalidad de desarrollo (lo sé, ¡solía ser uno!)

Soy el arquitecto principal de mi empresa y siempre he trabajado con el principio de la menor cantidad de privilegios necesarios para que la aplicación funcione. Todos los permisos son auditados regularmente.

¿Cuál es la mejor práctica en este escenario?

El argumento no tiene sentido. Siempre quiero que los controles y restricciones estén lo más cerca posible de los datos. Ponerlo en la capa de aplicación significa que solo afecta a las personas que usan la capa de aplicación, y también supone que el código estará libre de errores y la seguridad alrededor de esas rutas de código será a prueba de balas. Esas son grandes suposiciones.

Si es absolutamente necesario que se actualicen, eso puede hacerlo una persona que no se vea afectada por lo explícito DENY, o que la persona pueda pasar temporalmente a un rol que no DENYse vea afectado, o que se pueda eliminar temporalmente. Estas son cosas que son fáciles para usted, como el DBA, para configurar la auditoría. En la aplicación? No tanto.

Estoy completamente de acuerdo con @Aaron en el aspecto técnico de esto.

Más allá de eso diría, con respecto a las mejores prácticas:

1. Dado que es el trabajo / responsabilidad del DBA proteger los datos, el enfoque predeterminado debe ser hacer exactamente eso, como el DBA lo considere apropiado, y requerir un caso comercial sólido para hacer un cambio. Un potencial hipotético-futuro-algo-posible-dado-ciertas-condiciones-que-serán-lluvia de ideas-más tarde-y-confirmadas-bien-después-de-eso-pero-tal vez-cambiado-más tarde o podría-nunca -la razón que realmente sucede (es decir, "por alguna razón") parece un poco débil de justificación, especialmente cuando el tema está cambiando el estándar / práctica de una empresa.

2. Nunca confíes en alguien que quiera hacer cambios en algo que nunca debería cambiar ;-), (aún más si ni siquiera saben por qué quieren hacerlo).

3. Dígale al desarrollador que puede agregar esa lógica al código de la aplicación para evitar esas actualizaciones. Pero también que no vas a eliminar el DENY. Si / cuando llega el día (ytal vez noprobablemente no) que alguien reciba un error al intentar actualizar una de estas columnas, entonces puede tener una discusión sobre si eliminará o no DENY, lo que requerirá una justificación real y sólida de por qué alguien estaría actualizando ese valor en el primer lugar.

   El punto es: debe haber un caso de negocios real que impulse lo que la gente pasa su tiempo. El tiempo es de gran demanda pero escaso, por lo que usted (y todos los demás) tienen cosas más importantes que hacer que cambiar el sistema según la opinión de alguien. Siempre habrá una variedad de opiniones (espacios frente a pestañas, ¿alguien?) Y podría pasar años cambiando esto de un lado a otro si ese desarrollador se va y es reemplazado por uno que se opone firmemente a que esos campos sean actualizables. Si ningún cliente está pidiendo esto (o algo que lo requiera), y no hay un beneficio tangible (incluso un beneficio retrasado, como la limpieza de la deuda técnica, que es difícil mostrar el ROI, pero vale la pena dado que el las posibilidades de que el tiempo empleado no resulte en un ahorro de costos real a largo plazo son escasas o nulas), luego, cierre la solicitud o póngala en la lista de pedidos de baja prioridad, incluso en los casos en que el idealismo dice que debe cambiarse (este no es uno de esos casos, pero se menciona para aquellos que piensan que sí). El idealismo es ideal para las conversaciones, pero las empresas no pueden pagar alquileres, servicios públicos, empleados, impuestos, etc. con ideales.

4. @ jpmc26 es correcto acerca de la necesidad de comunicación, pero no es exactamente correcto con respecto a lo que debe comunicarse. Sí, debe escuchar lo que otros solicitan y tratar de comprender su razonamiento, lo que incluye hacer preguntas si no tiene claro nada.

   SIN EMBARGO, la base de datos no está subordinada a la aplicación, y los profesionales de la base de datos (administradores, ingenieros, cualquier nombre que use su empresa) no están subordinados a los desarrolladores (como parece estar implícito en esa respuesta). No trabajas para los desarrolladores, trabajas para la empresa, igual que ellos. Este es un esfuerzo de equipo y no debes pedir perdón por hacer tu trabajo. Dicho esto, nos computery tipos no son (en general) conocidos por nuestras habilidades de comunicación entre humanos, así, que realmente necesita para asegurarse de que otros entienden que , lo que su razonamiento es, cuáles son sus responsabilidades, y cómo estas cosas realmente funciona .

   Puse esa última parte porque hay un alto grado de malentendidos, desinformación y falta de conocimiento (incluso algunos aquí en esta misma página). Por ejemplo, parece existir esta noción de que todas las reglas son reglas comerciales. Necesitamos explicar que hay una distinción entre las reglas de datos y las reglas comerciales (@Aaron se refirió a esto como "restricción de flujo de trabajo versus restricción de datos" en un comentario sobre la pregunta), y que si bien la mayoría de los datos pertenecen naturalmente a la aplicación, algunos datos en realidad pertenece al modelo de datos. ¿Debería un DBA dictar a los desarrolladores cómo se restringirán los datos de la aplicación ? Por supuesto no. Es nuestro trabajo ofrecer cómo los datos de la aplicación puedenestar limitado Si una violación de una regla comercial relacionada con los datos de la aplicación puede causar daños, y la aplicación no es la única forma 100% de manipular los datos, entonces tal vez una restricción de verificación realmente podría ayudar (y no son difíciles de cambiar o eliminar )

   PERO, viniendo desde la otra dirección, los desarrolladores no deberían dictar cómo se manejan los datos del modelo de datos (es decir, los metadatos). Esto incluye campos de auditoría (como las columnas created_on/ created_by) y las columnas PK / FK (se supone que estos valores solo se conocen internamente y no se dan a los clientes). Estos datos no son lo que la aplicación almacena sobre los clientes (incluso si la aplicación puede ver los valores e incluso usarlos, como con ID), es lo que el modelo de datos almacena sobre los datos de la aplicación.

   Por lo tanto, tiene sentido usar reglas de datos para proteger los datos del modelo de datos. Y hacerlo no implica que esté a punto de comenzar a agregar restricciones o restricciones en los datos de la aplicación. PERO, será difícil avanzar la conversación de una manera verdaderamente productiva si no se entiende esta distinción.

Asi que:

1. Sí, me gusta la idea de lo explícito DENYen las columnas de auditoría, y también he propuesto lo mismo en lugares en los que he trabajado en el pasado.

2. Como anécdota, tuve una conversación muy similar con un desarrollador líder (muy buena), tal vez en 2000, cuando comencé a agregar claves foráneas. Argumentó (con bastante seriedad) que era innecesaria la sobre ingeniería / idealismo (algo así, han pasado 17 años desde esa conversación) y que no valía la pena el rendimiento. Era bastante claro que la limpieza de datos relacionados debería manejarse en la capa de la aplicación. (sí, agregué los FK porque no iba a ser él quien limpiara los datos huérfanos que su código inevitablemente crearía)

   Años después se disculpó por hacer ese argumento ;-)

Este es probablemente un problema XY. El desarrollador probablemente no esté especialmente preocupado con el bloqueo de actualizaciones en un campo verdaderamente constante como created_on. Este ejemplo particular es una restricción extremadamente modesta.

El desarrollador probablemente está preocupado de que el equipo de DBA (que lo incluye a usted) tenga la intención de agregar tantas o tan complejas restricciones que comience a impedir su capacidad de trabajar de manera efectiva, o que cuando surge algo fuera de lo común o algo cambia, el equipo de DBA resistirá los cambios e impedirá la capacidad del equipo de desarrolladores para progresar. Esta es una preocupación relativamente razonable. Las burocracias y la pérdida de la capacidad de efectuar los cambios necesarios son acontecimientos reales, y codificar demasiadas restricciones complejas puede tener efectos negativos en el rendimiento y en la capacidad de responder a los cambios en los requisitos.

Es posible que el desarrollador ni siquiera se dé cuenta de que esta es la naturaleza de sus preocupaciones. Es probable que estén acostumbrados a tener un dominio libre de la base de datos, y renunciar a ese nivel de libertad es difícil, especialmente si sabes que nunca has abusado de él. Por lo tanto, su sentido de preocupación por perder la capacidad de hacer lo que necesitan podría ser vago y mal definido.

Así que hay un par de cosas que debes hacer para calmar estos temores:

1. Comunícate fuertemente con los desarrolladores. Asegúrese de comprender las necesidades de las características que están tratando de construir, y asegúrese de responder cuando se produzcan cambios. Escuche lo que tienen que decir y trabaje duro para encontrar una solución que equilibre sus preocupaciones con las suyas. Esté dispuesto a doblegarse cuando tengan necesidades legítimas. Asegúrate de que sepan que eres un aliado en la construcción del software.
2. Tenga cuidado al poner restricciones. Las restricciones, incluso aquellas destinadas a proporcionar integridad y seguridad, pueden dificultar la adaptación al cambio o enfrentar circunstancias imprevistas. Por lo tanto, comprenda que cada restricción que agregue tiene la misma probabilidad de tener un costo asociado que ahorrar costos (con la posible excepción de las claves primarias y externas, que prácticamente no tienen inconvenientes). Tenga la seguridad de que las restricciones que impone son realmente necesarias o beneficiosas.
3. No veo ninguna señal de que estés haciendo esto, pero quiero mencionarlo para cualquier otro lector: no veas los datos o la base de datos como responsabilidad tuya o de tu equipo. Los datos son un activo para toda la empresa. Sin un sistema para almacenarlo (la base de datos) y scripts, herramientas o aplicaciones para crearlo, actualizarlo y recuperarlo, los datos no tienen valor. Debido a que todos deben usar este activo, los datos son responsabilidad de todos. La base de datos en sí misma es solo una parte para obtener valor de los datos.

Tienes declaraciones contradictorias

• Columnas que nunca deben actualizarse.
• Necesitan actualizar los valores por alguna razón.

¿Realmente depende de ti dictar el primero?

Usted otorga el mínimo privilegio para que la aplicación funcione sin pruebas de que la aplicación nunca necesitará actualizar el valor.

¿Quién es responsable de la integridad de los datos?

Con restricciones de SQL, ¿puede garantizar la integridad de los datos? No, no puede, ya que a menudo hay reglas comerciales que van más allá de lo que puede hacer una base de datos.

VendorID nunca debería cambiar, pero ¿y si dos proveedores se fusionan? Nunca digas nunca.

Si el equipo de la aplicación contamina los datos y dijeron que necesitaban esa autoridad, entonces está en ellos. Si los equipos de aplicaciones funcionan para usted, puede dictar.

La pregunta adecuada es si la aplicación alguna vez actualiza los datos.