¿Por qué BULK INSERT se considera peligroso?

Me gustaría entender por qué los equipos de ciberseguridad en general (más de una organización con la que he tratado) están totalmente en contra de otorgar BULK INSERT(por ejemplo, TSQL) derechos a las aplicaciones y los programadores de bases de datos. No puedo creer la excusa de "llenar el abuso del disco", a menos que me falte algo, ya que el resultado final no es diferente a una aplicación que hace algo como:

for (long i = 0; i < LONG_MAX; ++i)
    executeSQL("INSERT INTO table VALUES(...)");

y INSERTes un comando DML común que cualquier persona con permiso de escritura básico puede ejecutar.

Para beneficio de una aplicación, BULK INSERTes mucho más eficiente, más rápido y alivia al programador de la necesidad de analizar archivos fuera de SQL.

Editar: Originalmente hice esta pregunta en el sitio de seguridad de la información por una razón: no son los DBA los que están en contra del uso de BULK INSERT, es la "Garantía de información" (IA para abreviar: la gente de Ciberseguridad) la que está forzando el problema. Dejaré que esta pregunta se estire por otro día o dos, pero si la operación masiva de hecho evita las restricciones o los desencadenantes, puedo ver que eso es un problema.

Dado que probablemente haya tantos temores infundados como riesgos desconocidos, creo que es difícil decir realmente por qué existe una política sin preguntar a quién creó la política por qué están preocupados.

Sin embargo, supongo que probablemente tenga algo que ver con lo que BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)permite que alguien haga, a saber:

1. restricciones desactivar ( CHECK, DEFAULTy FOREIGN KEYyo creo)
2. deshabilitar los desencadenantes (si hay desencadenantes de auditoría en su lugar, pasarlos por alto probablemente se considerará indeseable; para obtener más explicaciones sobre este tema en particular, consulte la respuesta de @DVK )

Las diversas opciones se describen en la siguiente documentación:

• SqlBulkCopyOptions Enum
• INSERTAR A GRANEL

No mencioné el problema de bloqueo de la tabla observado por @RDFozz ya que eso no es específico para BULK INSERT: cualquiera puede presentar un TABLOCK / XLOCK o configurarlo TRANSACTION ISOLATION LEVELen SERIALIZABLE.

ACTUALIZAR

Encontré dos piezas adicionales de información que podrían ayudar a reducir esto:

1. Las cuestiones de poder desactivar los activadores, restricciones deshabilitar, y conjunto IDENTITY_INSERT ONpodría no ser una razón abrumadora para ver ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(a partir de SQL Server 2017), o el bulkadminrol de servidor como una amenaza. La razón es que para hacer cualquiera de las tres cosas que acabamos de mencionar, el Usuario debe tener ALTER TABLEpermisos en esa Tabla o en el Esquema en el que existe la Tabla. El encadenamiento de propiedad no cubre las modificaciones DDL. Entonces, si el usuario no tiene ALTER TABLE, entonces la capacidad de hacer estas tres cosas no es un problema.

2. Lo que no se ha discutido hasta ahora, y lo que en última instancia podría ser el problema de seguridad es que ambos BULK INSERTy OPENROWSET(BULK...acceder a recursos externos, fuera de SQL Server. Al acceder a SQL Server a través de un inicio de sesión de Windows, esa cuenta de Windows se suplantará (incluso si cambia el contexto de seguridad mediante EXECUTE AS LOGIN='...') para acceder al sistema de archivos. Esto significa que solo puede leer archivos para los que tiene permiso de lectura. Nada de malo con eso.

   PERO, cuando se accede a SQL Server a través de un inicio de sesión de SQL Server, el acceso externo se realiza en el contexto de la cuenta de servicio de SQL Server. Esto significa que alguien con este permiso podría leer archivos que de otro modo no podrían leer, y en carpetas a las que no deberían tener acceso.

   Como mínimo, si SQL Server se configuró para ejecutarse como una cuenta creada solo para SQL Server (el método preferido), dicho Usuario podría leer solo aquellos archivos a los que tiene acceso la cuenta "SQL Server". Si bien este es un problema limitado, todavía permite leer archivos como los archivos de registro de SQL Server (y probé el siguiente ejemplo y funciona):

   SELECT tmp.[Col1]
   FROM   OPENROWSET(BULK
      N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                     SINGLE_NCLOB) tmp([Col1]);
   

   La mayoría de las personas no tendrán acceso a la carpeta MSSQL \ Log , por lo que esta sería una forma de sortear las restricciones de seguridad existentes.

   Y, si SQL Server se está ejecutando como la Local Systemcuenta, sospecho que el alcance del problema solo aumenta y que un Usuario con este permiso podría leer una amplia gama de archivos relacionados con el sistema.

   Y, esta es probablemente la razón por la cual los otros métodos para realizar importaciones masivas - BCP y SqlBulkCopy- no requieren el bulkadminpermiso / rol: se inician fuera de SQL Server y manejarán los permisos del sistema de archivos por sí mismos. En esos casos, SQL Server nunca lee el archivo (o llega fuera de SQL Server), solo recibe los datos para importar desde el archivo que está siendo leído por el proceso externo.

Dejando a un lado las posibles implicaciones, se dijo en la pregunta:

Para beneficio de una aplicación, BULK INSERT es mucho más eficiente, más rápido, ..

OK adelante...

y alivia al programador de la necesidad de analizar archivos fuera de SQL.

Whoa Nelly Paremos aquí mismo. T-SQL generalmente no es la mejor opción de lenguajes para el análisis. A menudo es mejor hacer el análisis antes de insertar cosas en la base de datos. Una forma de hacerlo es usar los parámetros con valores de tabla (TVP). Consulte mi respuesta a otra pregunta (aquí en DBA.StackExchange) que trata el tema del análisis previo y la validación junto con la importación masiva eficiente de dichos datos:

T-SQL: CSV-> canalización de tabla con datos numéricos analizados personalizados, valores de búsqueda

Esto fue aludido en una respuesta anterior ("... deshabilitar los desencadenantes "), pero no explica por qué deshabilitar sería deseable desde el punto de vista comercial.

En muchas empresas, los desencadenantes en la tabla principal se utilizan para:

1. Valide las restricciones de integridad (aquellas con lógica de negocios más complicada de lo que generalmente se usa en las restricciones de DB)

2. Más importante aún, auditar los datos, específicamente para insertar datos en la tabla de auditoría correspondiente (o actualizar los campos de auditoría en la tabla principal).

Es bastante obvio cuáles son los problemas con el primero (su aplicación puede insertar datos incorrectos que tienen efectos negativos en el procesamiento posterior). En cuanto a esto último, si un disparador está deshabilitado, no tiene ninguna información de auditoría, lo que plantea dos problemas desde la perspectiva de la auditoría:

• En primer lugar, la auditoría como grupo ya no puede auditar los cambios de datos y, por lo tanto, no puede realizar su función principal como Auditoría interna.

• En segundo lugar, la falta de registros de auditoría puede ser un incumplimiento de los requisitos de auditoría por los que se rige una empresa (por ejemplo, SAS 70), lo que puede hacer que su empresa sea responsable de violar los contratos.

Otra posibilidad es el impacto de ejecutar una BULK INSERToperación.

Normalmente, este tipo de cosas se realizarían fuera de horario cuando sea posible, para no interferir con la actividad normal. Una inserción masiva puede bloquear una tabla durante horas, evitando que ocurran otras inserciones (así como seleccionar, actualizar o eliminar).

O, desde una perspectiva de seguridad, puede producir resultados muy similares a un ataque DoS.

Es cierto que uno puede hacer esto ya sea accidental o deliberadamente con transacciones y INSERTdeclaraciones simples . Sin embargo, el uso de un proceso de inserción masiva según lo previsto puede causar este efecto.

En general, esperaría que un DBA participe en la organización de actividades fuera del horario laboral, ya que también deben asegurarse de que las copias de seguridad y otros trabajos programados se completen. Si la gente programara este tipo de cosas sin la consideración suficiente para tales actividades, podría ver fallar las copias de seguridad, lo que puede ser un problema por varias razones.

Una razón para esto puede deberse a dejar en claro el registro de acciones. Si cada acción corresponde a una entrada en un archivo de registro, es bastante trivial ver algo que causó un problema sin ninguna referencia adicional. Si su archivo de registro dice "INSERTAR desde archivo externo", sin archivo externo, no puede decir nada más.

Por supuesto, podría modificar cómo funciona el registro, pero como punto de partida, hacer que cada acción sea atómica incluso dentro del registro no es una idea terrible.