Desbordamiento de pila de lenguaje incorporado 1c. Desbordamiento de pila

14/04/2016 Versión 3.22 Se ha cambiado la interfaz, se han corregido errores al transferir registros, se ha cambiado el procedimiento para transferir una organización y las políticas contables. Plataforma 8.3.7.2027 BP 3.0.43.174
17/03/2016 Versión 3.24 Se han corregido los errores detectados. Plataforma 8.3.8.1747 BP 3.0.43.241
16/06/2016 Versión 3.26 Los errores observados han sido corregidos. Plataforma 8.3.8.2088 BP 3.0.44.123
16/10/2016 Versión 4.0.1.2 Se corrigió la transferencia de almacenamiento de valor, se modificó la transferencia de la política contable para las versiones 3.44.*. Plataforma 8.3.9.1818 BP 3.0.44.164.
19/04/2017 Versión 4.0.2.7 Se ha modificado el algoritmo para transferir registros asociados a directorios, se han corregido los errores detectados y se ha corregido la transferencia con sobrescritura de enlaces.
29/05/2017 Versión 4.0.4.5 Cambió la transferencia de movimientos, agregó visualización de los movimientos de los documentos transferidos, algo más...
30/05/2017 Versión 4.0.4.6 Se corrigió un error al completar la lista de directorios existentes en el código fuente (gracias shoy)
17/06/2017 Versión 4.0.5.1 Se ha cambiado el algoritmo para transferir movimientos.
19/07/2017 Versión 4.0.5.4 Se ha modificado la transferencia de CI desde BP 2.0. Inesperadamente, la transferencia desde UT 10.3 la realizó Smilegm, en esta versión la transferencia se corrigió ligeramente para esta situación)))
10/08/2017 Versión 4.0.5.5 Se corrigieron errores al transferir desde BP 2.0
19.09.2017 Versión 4.4.5.7 Se corrigió la verificación de conexión para 3.0.52.*
28/11/2017 Versión 4.4.5.9 Se corrigieron errores reportados
06/12/2017 Versión 5.2.0.4 Se ha rediseñado el algoritmo de búsqueda de enlaces. Se han agregado procedimientos de transferencia desde BP 1.6; ya no existe una conexión estricta con el BP; puede usarlo fácilmente para transferir datos de configuraciones "casi" idénticas. Intentaré corregir todos los comentarios lo antes posible.
08/12/2017 Versión 5.2.1.3 Se agregó un algoritmo para transferir declaraciones de salario de BP.2.0 a BP 3.0. Cambios incluidos para compartir entre configuraciones idénticas.
19/12/2017 Versión 5.2.2.2 Se ha ajustado la transferencia de registros de información independientes para directorios que se encuentran en las dimensiones de estos registros.

06/12/2017 Nueva versión de procesamiento 5.2.0.4. Entre los cambios significativos está la capacidad de transferir de BP 1.6 a BP 3.0. El principal cambio es la gestión de la búsqueda de enlaces de directorios - en versiones anteriores la búsqueda era por GUID, pero en esta versión se puede habilitar la búsqueda "Por detalles":

17/01/2018 Versión 5.2.2.3 Corregido: errores detectados en directorios subordinados y registros de información periódica.

19/07/2018 Versión 5.2.2.8 Se han corregido los errores detectados.

en el que puede configurar los detalles de búsqueda para cualquier directorio. Este modo en sí "surgió" a raíz de numerosas solicitudes de los trabajadores, para los casos en que es necesario un intercambio en una base de datos ya existente que ya tiene datos (por ejemplo, para fusionar los registros contables de dos organizaciones en una base de datos).

21/12/2015 Se lanzaron la plataforma 8.3.7.1805 y BP 3.0.43.29, respectivamente una nueva version procesamiento 3.1:-) (descripción a continuación). Nueva funcionalidad: la capacidad de comparar saldos y facturación entre dos bases de datos de BP (para todas las cuentas, si los planes de cuentas coinciden, o para cuentas contables coincidentes individuales, con o sin análisis).
03/01/2016 Versión 3.5: se ha cambiado el mecanismo para conectarse a la base de origen; se ha adaptado a BSP 2.3.2.43. Errores minimos arreglados. Plataforma 8.3.7.1845, BP 3.0.43.50
16/02/2016 Versión 3.6: se agregó el indicador "Establecer corrección manual" para documentos transferidos con movimientos. Transferencia fija de movimientos: los documentos con fecha anterior al inicio del período se transfieren sin movimientos. Plataforma 8.3.7.1917, BP 3.0.43.116
22/03/2016 Versión 3.10: se agregó el indicador "Sobrescribir siempre referencias" para la reescritura obligatoria de objetos referenciados (la velocidad de transferencia se reduce significativamente, pero a veces es necesaria). Se agregó la pestaña "Preparación", donde se puede configurar la correspondencia de los planes de cuentas de origen y destino (al mismo nivel que los códigos de cuenta) y la transferencia de constantes. Plataforma 8.3.7.1970, BP 3.0.43.148

03/04/2016 Versión 3.11 Se cambió el llenado de la lista de documentos existentes en la fuente: se completó por movimientos según el plan de cuentas, se hizo simplemente mediante enlaces para el período, tal como en // sitio/público/509628/

El procesamiento está destinado a transferir datos para cualquier período de la misma manera que "Cargar MXL" con ITS, solo que sin usar XML, JSON y otros archivos intermedios: intercambio de una base de datos a otra a través de COM. En versiones anteriores a la 3.10, se utiliza una conexión mediante un algoritmo del BSP, que prevé el registro de comcntr.dll (si el sistema operativo "lo permite"), así como varios mensajes cuando es imposible establecer una conexión, por ejemplo: “La base de información está en proceso de actualización”, etc. Se agregó una verificación para seleccionar un receptor como fuente IS: se emite una advertencia.

Puede usarse para:

1. Transferencia de información de referencia reglamentaria (RNI) desde la fuente del SI al destino del SI (la transferencia de toda la información de referencia se realiza a petición del usuario, los libros de referencia necesarios, etc. se transfieren a través de enlaces durante cualquier transferencia).

2. Transferencia de documentos para cualquier período seleccionado.

3. Transferencia de toda la información desde un sistema de seguridad de la información "roto" si se inicia en modo 1C:Enterprise y es imposible cargar datos o iniciar el Configurador.

Característica del procesamiento: la seguridad de la información del receptor y la fuente puede ser diferente; transferencia de 2.0 a 3.0: las ediciones son diferentes, ¡pero la transferencia funciona! Los detalles que no coinciden se ignoran o se deben especificar algoritmos de transferencia para ellos.

Comentario: ¡La conversión de datos NO SE UTILIZA! ¡¡¡Y no preguntes por qué!!! Para aquellos que son especialmente exigentes: BP 3.0 cambia casi todos los días, ya no hay fuerzas para mantener actualizadas las reglas de transferencia; aquí todo es más sencillo :-).

Otra característica del procesamiento es que se inicia en la seguridad de la información del receptor (los análogos más cercanos en funcionalidad funcionan al revés, desde la fuente hasta el receptor).

Para comenzar: debe especificar el período de procesamiento, especificar la organización desde el origen y se transferirá al destino.

Al transferir una organización, se transfieren las políticas contables y los registros de información "relacionados". Por lo tanto, cuando selecciona por primera vez una organización en la fuente, pasará algún tiempo antes de que aparezca en el receptor.

Los planes de cuentas de origen y destino deben ser los mismos, no se transfieren cuentas diferentes en las versiones 2.* al destino, está previsto permitir el ajuste de cuentas coincidentes y análisis en el futuro. Las cuentas se transfieren utilizando códigos que no se encuentran en el receptor. ¡¡¡NO SE PUEDEN CREAR!!!

El resto de objetos se transfieren mediante identificadores internos (GUID), por lo que conviene prestar atención a algunos directorios clave, por ejemplo, Monedas.

Si planea intercambiar con una base de datos "limpia", entonces es mejor eliminar los directorios completados durante el primer lanzamiento antes del intercambio. ¿Por qué hay una página en el procesamiento donde puede obtener estos elementos del directorio y eliminarlos? Como mínimo, debe eliminar la moneda "frotar". - porque la duplicación es casi inevitable (en principio, esto se corrige fácilmente compartiendo la búsqueda y sustitución de duplicados integrada en BP 3.0).

El procesamiento prevé llamar a la página de eliminación del directorio cuando el formulario de llenado inicial está abierto:

Al abrir el procesamiento, se mostrará una página para eliminar directorios completados durante el llenado inicial:

Desde la versión 3.22, la interfaz ha cambiado, ahora todas las operaciones preparatorias están en pestañas y siempre disponibles

Es importante comprobar la correspondencia del Plan de Cuentas del origen y del destinatario y asegurarse de indicar la correspondencia de las cuentas.

No es necesario eliminar elementos de directorio predefinidos: se transfieren mediante identificadores de configuración (no GUID).

Puede seleccionar objetos para transferir utilizando el formulario de selección de directorios y documentos (Los registros de información asociados a estos objetos se transferirán automáticamente, por lo que no es necesario seleccionarlos por separado).La transferencia de registros, la reducción está temporalmente deshabilitada - es necesario desarrollar una lista de registros para la transferencia - algo debe transferirse, algo no, en esta etapa es suficiente lo que se transfiere en los directorios, la lista de registros para la transferencia será en la plantilla en futuras versiones.

Al intercambiar con 2.0, algunos de los detalles (por ejemplo, Información del contacto) se transfiere según el algoritmo integrado en el procesamiento, porque para 2.0 y 3.0 se almacenan de manera diferente. La situación es similar con varios documentos (por ejemplo, el Ajuste de Deuda).

La lista de tipos de objetos se puede completar de manera diferente en la versión 3.22, esto se coloca en un submenú, los cambios se indican en la imagen:

Hay una simplificación del uso del procesamiento: no puede seleccionar directorios para el intercambio, sino simplemente completar la lista de tipos en el receptor solo con aquellos tipos de directorios que tienen al menos una entrada en la fuente.

El procesamiento tiene un diseño incorporado que enumera los directorios que no necesitan transferirse desde el origen al destino (el diseño "Excluir de la transferencia"). Puede agregar (eliminar) cualquier directorio a este diseño. Si no necesita transferir todos los datos de referencia, basta con transferir los documentos, cuya lista también se puede obtener sin seleccionar tipos, simplemente complete con todos los documentos originales para los cuales existen transacciones.

Se proporciona la transferencia de documentos con movimientos, para los intercambios 3.0 a 3.0 y la correspondencia de planes de cuentas funciona uno a uno; al intercambiar 2.0 a 3.0, es posible que se produzcan errores, por lo que se recomienda transferir documentos sin movimientos, y luego simplemente transfiéralos al receptor. Al transferir documentos con movimientos, se establece el indicador "Ajuste manual".

El atributo "Publicado" se establece en los documentos del destinatario de la misma manera que en el origen, pero los movimientos (si no fueron transferidos) aparecerán solo después de que se procesen los documentos, por ejemplo, utilizando el procesamiento integrado en la publicación de grupo BP 3.0. documentos (opción recomendada), o de este procesamiento (Aquí hay un botón “Publicar Documentos”).

Si se prevé que el procesamiento se utilice para un intercambio permanente, se puede registrar en la seguridad de la información del destinatario (el botón "Registrarse"). Para transferencias "únicas", simplemente puede usarlo a través de Archivo - Abrir.

21/12/2015 - Versión 3.1 plataforma 8.3.7.1805 y unidad de fuente de alimentación 3.0.43.29 (la versión 2.15 para 3.0.43.* no funciona; la configuración ha cambiado bastante).

Cambió:

Cuadro de diálogo para seleccionar una opción de conexión, el indicador Cliente-servidor siempre está disponible, dependiendo de su configuración, ya sea la elección de una carpeta de base de datos de archivos o un campo con el nombre de la base de datos en el servidor y el nombre del servidor en sí. disponible (se ha solucionado un error en el cuadro de diálogo versión 2.15)

- NUEVA FUNCIONALIDAD: Un mecanismo para conciliar saldos y rotación entre las bases de datos fuente y receptora en distintos grados de detalle:

Creo que la elección de las opciones de verificación se desprende claramente de la figura:

Existen diferencias en el uso entre los clientes ligeros y pesados: en el cliente pesado, se muestra inmediatamente una ventana de comparación de archivos:

En el cliente ligero, no me molesté en presionar botones mediante programación; sugiero una opción simple para mostrar una ventana de comparación:

La comparación en un cliente ligero, en mi humilde opinión, es más conveniente, porque... tiene botones de navegación para diferencias, lo cual es más conveniente para tablas grandes que desplazarse con el mouse:

22/03/2016 Versión 3.10: se agregó el indicador "Sobrescribir siempre referencias" para la reescritura obligatoria de objetos referenciados (la velocidad de transferencia se reduce significativamente, pero a veces es necesaria). Se agregó la pestaña "Preparación", donde se puede configurar la correspondencia de los planes de cuentas de origen y destino (al mismo nivel que los códigos de cuenta) y la transferencia de constantes. Plataforma 8.3.7.1970, BP 3.0.43.148

- NUEVA FUNCIONALIDAD: Antes de transferir documentos, se recomienda verificar la coherencia del plan de cuentas en el origen y destino, así como el cumplimiento de las constantes establecidas.

Para ello se ha añadido una pestaña de “Preparación” en la que se pueden configurar estas correspondencias:

El algoritmo para completar la tabla de concordancia de cuentas es simple: se analiza el volumen de negocios existente en la fuente y, para cada cuenta encontrada allí, se encuentra una concordancia en el receptor por código; si no se encuentra una concordancia, se crea una línea con la cuenta. El código se muestra en la tabla, mediante el cual debe seleccionar la cuenta del destinatario, se utilizará durante la transferencia. El cumplimiento de Poke se establece a nivel de código.

Para comprobar y trasladar la correspondencia de las constantes establecidas se utiliza la tabla correspondiente:

Lo completamos y lo transferimos si es necesario. Sólo se transfieren las constantes marcadas con la bandera...

La pila de programas es un área de memoria especial organizada según el principio de cola LIFO (último en entrar, primero en salir). El nombre "pila" proviene de la analogía del principio de su construcción con una pila de placas: puede colocar placas una encima de la otra (el método de agregar a la pila, "empujar", "empujar"), y luego quítelos, comenzando desde arriba (método para obtener un valor de la pila, "popping", "pop"). La pila de programas también se denomina pila de llamadas, pila de ejecución o pila de máquina (para no confundirla con la "pila", una estructura de datos abstracta).

¿Para qué sirve una pila? Le permite organizar cómodamente la llamada de subrutinas. Cuando se llama, la función recibe algunos argumentos; también debe almacenar sus variables locales en algún lugar. Además, debemos tener en cuenta que una función puede llamar a otra función, la cual también necesita pasar parámetros y almacenar sus variables. Usando la pila, al pasar parámetros solo necesita colocarlos en la pila, luego la función llamada puede "sacarlos" de allí y usarlos. Las variables locales también se pueden almacenar allí: al comienzo de su código, la función asigna parte de la memoria de la pila y, cuando regresa el control, la borra y la libera. Los programadores en lenguajes de alto nivel generalmente no piensan en esas cosas: el compilador genera todo el código de rutina necesario para ellos.

Consecuencias de un error

Ahora estamos casi cerca del problema. En abstracto, una pila es un almacén infinito al que se pueden agregar nuevos elementos sin cesar. Desafortunadamente, en nuestro mundo todo es finito y la memoria de pila no es una excepción. ¿Qué sucede si termina cuando los argumentos de la función se colocan en la pila? ¿O la función asigna memoria para sus variables?

Se producirá un error llamado desbordamiento de pila. Dado que la pila es necesaria para organizar la llamada de funciones definidas por el usuario (y casi todos los programas en lenguajes modernos, incluidos los orientados a objetos, de una forma u otra se basan en funciones), ya no podrán ser llamado. Por lo tanto, el sistema operativo toma el control, limpia la pila y finaliza el programa. Aquí podemos enfatizar la diferencia entre desbordamiento de pila y desbordamiento de pila: en el primer caso, se produce un error al acceder a un área de memoria incorrecta, y si no hay protección en esta etapa, no se manifiesta en ese momento, con un éxito combinación de circunstancias, el programa puede funcionar normalmente. Si solo estuviera protegida la memoria a la que se accede, . En el caso de una pila, el programa ciertamente termina.

Para ser completamente preciso, cabe señalar que dicha descripción de eventos sólo es cierta para los compiladores que compilan en código nativo. En los lenguajes administrados, la máquina virtual tiene su propia pila para programas administrados, cuyo estado es mucho más fácil de monitorear, e incluso puede darse el lujo de lanzar una excepción al programa cuando ocurre un desbordamiento. En los lenguajes C y C++ no se puede contar con semejante “lujo”.

Razones del error

¿Qué podría conducir a una situación tan desagradable? Según el mecanismo descrito anteriormente, una posibilidad es que haya demasiadas llamadas a funciones anidadas. Este escenario es especialmente probable cuando se utiliza la recursividad. La recursión infinita (en ausencia de un mecanismo de evaluación diferido) se interrumpe de esta manera, a diferencia de , que a veces tiene aplicaciones útiles. Sin embargo, con una pequeña cantidad de memoria asignada a la pila (que, por ejemplo, es típica de los microcontroladores), una simple secuencia de llamadas puede ser suficiente.

Otra opción son las variables locales, que requieren mucha memoria. Tener una matriz local de un millón de elementos o un millón de variables locales (nunca se sabe lo que sucede) no es la mejor idea. Incluso una llamada a una función tan codiciosa puede provocar fácilmente un desbordamiento de la pila. Para obtener grandes cantidades de datos, es mejor utilizar mecanismos de memoria dinámica, que permitirán afrontar el error de su falta.

Sin embargo, la memoria dinámica es bastante lenta en términos de asignación y desasignación (ya que el sistema operativo maneja esto), y con acceso directo hay que asignarla y desasignarla manualmente. La memoria en la pila se asigna muy rápidamente (de hecho, solo necesita cambiar el valor de un registro); además, los objetos asignados en la pila tienen destructores llamados automáticamente cuando regresa el control de la función y se borra la pila. Por supuesto, surge inmediatamente el deseo de obtener memoria de la pila. Por lo tanto, la tercera forma de desbordarse es la propia asignación de memoria en la pila por parte del programador. La biblioteca C proporciona la función alloca específicamente para este propósito. Es interesante notar que si la función para asignar memoria dinámica malloc tiene su propio "gemelo" para liberarla, free, entonces la función alloca no lo tiene: la memoria se libera automáticamente después de que regresa el control de la función. Quizás esto solo complique la situación; después de todo, no será posible liberar la memoria antes de salir de la función. Aunque, según la página de manual, "la función alloca depende de la máquina y del compilador; en muchos sistemas su implementación es problemática y tiene errores; su uso es muy frívolo y está mal visto", todavía se usa.

Ejemplos

Como ejemplo, veamos el código para la búsqueda recursiva de archivos ubicado en MSDN:

Void DirSearch(String* sDir) ( try ( // Encuentra las subcarpetas en la carpeta que se pasa. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0;yo< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Texto); int numFiles = f->get_Length(); para (int j=0; j< numFiles; j++) { listBox1->Artículos->Agregar(f[j]); ) BúsquedaDir(d[i]); ) ) catch (Sistema::Excepción* e) ( Cuadro de mensaje::Mostrar(e->Mensaje); ) )

Esta función obtiene una lista de archivos en el directorio especificado y luego se llama a sí misma para aquellos elementos de la lista que resultan ser directorios. En consecuencia, con un árbol suficientemente profundo. sistema de archivos, obtenemos un resultado natural.

Un ejemplo del segundo enfoque, tomado de la pregunta "¿Por qué ocurre el desbordamiento de la pila?" de un sitio llamado Stack Overflow (el sitio es una colección de preguntas y respuestas sobre cualquier tema de programación, y no solo Stack Overflow, como podría parecer):

#definir W 1000 #definir H 1000 #definir MAX 100000 //... int main() ( int imagen; float dtr; initImg(imagen,dtr); return 0; )

Como puede ver, la función principal asigna memoria en la pila para matrices de tipo int y float, cada una con un millón de elementos, lo que en total da un poco menos de 8 megabytes. Si considera que, de forma predeterminada, Visual C++ reserva solo 1 megabyte para la pila, entonces la respuesta resulta obvia.

Y aquí hay un ejemplo tomado del repositorio de GitHub del proyecto Lightspark Flash Player:

DefineSoundTag::DefineSoundTag(/* ... */) ( // ... unsigned int soundDataLength = h.getLength()-7; unsigned char *tmp = (unsigned char *)alloca(soundDataLength); // .. . )

Puede esperar que h.getLength()-7 no sea un número demasiado grande para que no se desborde en la siguiente línea. Pero, ¿vale la pena el tiempo ahorrado en la asignación de memoria por el “potencial” bloqueo del programa?

Línea de fondo

El desbordamiento de pila es un error fatal que afecta con mayor frecuencia a los programas que contienen funciones recursivas. Sin embargo, incluso si el programa no contiene tales funciones, aún es posible un desbordamiento debido al gran tamaño de las variables locales o a un error en la asignación manual de memoria en la pila. Todas las reglas clásicas siguen vigentes: si hay una opción, es mejor elegir la iteración en lugar de la recursividad, y además no realizar trabajo manual en lugar del compilador.

Bibliografía

• E. Tanenbaum. Arquitectura de Computadores.
• Wikipedia. Desbordamiento de pila.
• Desbordamiento de pila. Desbordamiento de pila C++.

La pila, en este contexto, es la última en el primer búfer que asignas durante la ejecución de tu programa. Último, Primero (LIFO) significa que lo último que pones es siempre lo primero que sacas de la pila: si colocas 2 elementos en la pila, "A" y luego "B", entonces lo primero que sacas de la pila será "B" y lo siguiente será "A".

Cuando llamas a una función en tu código, el siguiente comando después de la llamada a la función se almacena en la pila y en cualquier espacio de memoria que la llamada a la función pueda sobrescribir. La función elegida puede utilizar más pila para sus propias variables locales. Cuando se hace esto, liberará el espacio de variable local que estaba usando y luego volverá a la función anterior.

Desbordamiento de pila

Un desbordamiento de pila se produce cuando ha utilizado más memoria en la pila de la que su programa pretendía utilizar. En los sistemas integrados, es posible que solo tenga 256 bytes para la pila, y si cada función toma 32 bytes, entonces solo puede tener 8 llamadas a la función 2 con la función profunda 1, que llama a la función 3, que llama a la función 4. ...quién llama a la función 8, que llama a la función 9, pero la función 9 sobrescribe la memoria fuera de la pila. Esto puede sobrescribir la memoria, el código, etc.

Muchos programadores cometen este error al llamar a la función A, que luego llama a la función B, que luego llama a la función C, que luego llama a la función A. Puede funcionar la mayor parte del tiempo, pero solo una entrada incorrecta hará que gire para siempre hasta que la computadora falla y descubre que la pila está llena.

Las funciones recursivas también son una causa de esto, pero si escribe de forma recursiva (es decir, su función se llama a sí misma), debe tener esto en cuenta y utilizar variables estáticas/globales para evitar una recursión interminable.

Por lo general, el sistema operativo y el lenguaje de programación que estás utilizando administran la pila y está fuera de tu control. Deberías mirar tu gráfico de llamadas (una estructura de árbol que muestra desde tu punto principal lo que llama cada función) para ver qué tan profundas son tus llamadas a funciones e identificar bucles y recursividad que no están previstos. Los bucles intencionales y la recursividad deben comprobarse artificialmente para detectar errores si se llaman entre sí demasiadas veces.

Aparte de las buenas prácticas de programación y las pruebas estáticas y dinámicas, no hay mucho que puedas hacer en estos sistemas de alto nivel.

Sistemas embebidos

En el mundo integrado, especialmente en el código de alta seguridad (automotriz, aeroespacial, aeroespacial), se realizan pruebas y revisiones de código exhaustivas, pero también se hace lo siguiente:

• Deshabilitar la recursividad y los bucles: cumplimiento de políticas y pruebas
• Mantenga el código y la pila separados (código en flash, pila en RAM y nunca coincidirán entre sí)
• Coloque barras de protección alrededor de la pila: un área vacía de memoria que llena con un número mágico (generalmente la rutina de interrupción, pero aquí hay muchas variaciones) y cientos o miles de veces por segundo mira las barras de protección para hacer seguro que no han sido sobrescritos.
• Utilice protección de memoria (es decir, no ejecute en la pila, no lea ni escriba directamente detrás de la pila)
• Las interrupciones no llaman a funciones secundarias: establecen indicadores, copian datos y dejan que la aplicación se encargue de manejarlos (de lo contrario, podría terminar a 8 profundidades de su árbol de llamadas de funciones, tener una interrupción y luego tener algunas funciones más dentro). la salida de la interrupción, provocando un lanzamiento). Tiene varios árboles de llamadas: uno para los procesos principales y otro para cada interrupción. Si tus interrupciones pueden interrumpirse entre sí... bueno, hay dragones...

Lenguajes y sistemas de alto nivel

Pero en lenguajes de alto nivel que se ejecutan en sistemas operativos:

• Reduzca el almacenamiento de variables locales (las variables locales se almacenan en la pila), aunque los compiladores son bastante inteligentes al respecto y, a veces, colocarán grandes fragmentos en el montón si su árbol de llamadas es poco profundo).
• Evite o limite estrictamente la recursividad
• No interrumpa demasiado sus programas en funciones cada vez más pequeñas; incluso sin considerar las variables locales, cada llamada a función consume hasta 64 bytes en la pila (procesador de 32 bits, lo que ahorra la mitad de los registros, indicadores, etc. del procesador).
• Mantenga el árbol de llamadas poco profundo (similar a la descripción anterior)

servidores web

Depende del sandbox que tengas si puedes controlar o incluso ver la pila. Lo más probable es que pueda manejar servidores web como cualquier otro lenguaje y sistema operativo de alto nivel; en gran medida está fuera de su control, pero verifique el idioma y la pila de servidores que está utilizando. Por ejemplo, puede dividir la pila en su servidor SQL.

La Guía del programador de API de Informix® DataBlade™ está disponible para descargar. La sección "Administración del espacio de pila" describe la creación de funciones definidas por el usuario (UDR). Este artículo proporciona información adicional y consejos de depuración.

La siguiente información se aplica tanto si UDR se ejecuta en un procesador virtual (VP) definido por el usuario como en una CPU de VP. La pila de un subproceso se puede mover a un procesador virtual definido por el usuario inmediatamente antes de ejecutar la UDR.

¿Qué tamaño de pila se asigna para la UDR?

El tamaño de la pila disponible para una UDR depende de cómo se creó la UDR:

usando el modificador STACK, que permite a la UDR usar su pila especialmente asignada,

sin el modificador STACK, lo que significa que UDR compartirá la pila asignada por el servidor con el hilo que realiza la solicitud. El tamaño de la pila en este caso estará determinado por el valor del parámetro STACKSIZE en el archivo de configuración onconfig.

modificador de PILA

Las sentencias CREATE PROCEDURE o CREATE FUNCTION tienen un modificador STACK opcional que le permite especificar la cantidad de espacio de pila, en bytes, que se requiere para ejecutar la UDR.

Si utiliza el modificador STACK al crear una UDR, el servidor asignará y desasignará espacio de pila cada vez que se ejecute la UDR. El tamaño real disponible es igual al valor STACK en bytes menos algo de sobrecarga dependiendo de la cantidad de argumentos de la función.

Si el valor STACK es menor que el parámetro STACKSIZE en el archivo onconfig (consulte la siguiente sección), entonces el tamaño de pila asignado para la UDR se redondeará automáticamente al valor STACKSIZE.

Parámetro de configuración STACKSIZE

El archivo de configuración onconfig incluye un parámetro STACKSIZE que especifica el tamaño de pila predeterminado para los subprocesos de usuario.

Si no especifica STACK al crear una UDR, el servidor no asigna espacio de pila adicional para ejecutar esa UDR. En cambio, la UDR utiliza el espacio de pila asignado para ejecutar la solicitud. El tamaño de pila disponible dependerá de la sobrecarga de ejecutar la función en el nivel SQL.

La pila por subproceso se asigna una vez para el subproceso específico que ejecuta la solicitud. El rendimiento es mejor cuando la UDR comparte una pila con un subproceso, ya que el servidor no desperdicia recursos asignando una pila adicional para cada llamada de UDR. Por otro lado, si el tamaño de pila utilizado por la UDR se acerca al valor STACKSIZE, puede provocar un desbordamiento de la pila al llamar a la función como parte de una consulta compleja (en cuyo caso habrá menos espacio de pila disponible para la ejecución de la UDR).

Tenga en cuenta que no debe establecer el valor STACKSIZE demasiado alto, ya que esto afectará a todos los hilos de usuario.

¿Cuándo es necesario controlar el tamaño de la pila?

Debe administrar el espacio de la pila si la UDR realiza llamadas recursivas o si la UDR requiere más espacio de pila del que está disponible de forma predeterminada en la pila del subproceso de solicitud (STACKSIZE).

Hay dos formas de aumentar la pila para la ejecución de UDR:

Especifique el modificador STACK al crear una UDR.

Utilice mi_call() para realizar llamadas recursivas (consulte la Guía del programador de API de Informix DataBlade para ver un ejemplo).

Si no especifica un tamaño a través de STACK, y si no usa mi_call() para aumentar la pila actual, y si la UDR hace algo que requiere mucho espacio de pila, provocará un desbordamiento de la pila.

Tenga en cuenta que algunas funciones mi_* agregan un nuevo segmento de pila para su propia ejecución. Estos segmentos se liberan al regresar a la función UDR que llama.

¿Qué hacer si algo sale mal?

Monitoreo del uso de la pila

El objetivo de la supervisión es identificar la UDR específica que está provocando el desbordamiento de la pila para que pueda cambiar el valor de STACK específicamente para esa UDR en particular.

Monitorear el uso de la pila con el comando "onstat -g sts"

Monitorear una sesión ejecutando una consulta SQL usando "onstat -g ses session_id"

Después de identificar una consulta SQL que finaliza con un desbordamiento de pila, debe determinar el uso de la pila ejecutando por separado las consultas UDR que forman parte de la consulta original.

Puede establecer dinámicamente el valor STACK para UDR. Por ejemplo:

alterar la función MyFoo (lvarchar,lvarchar) con (agregar pila=131072);

Después de cambiar el valor de STACK, debe probar la solicitud original para asegurarse de que ahora sea estable.

Aumentar el TAMAÑO DE LA PILA

Alternativamente, intente aumentar el valor STACKSIZE. Compruebe si esto resuelve el problema. (No olvide devolver el valor anterior más tarde).

Si aumentar STACKSIZE no ayuda, lo más probable es que el problema sea una corrupción de memoria. Aquí hay algunas sugerencias:

Habilite el garabato de memoria y la verificación del grupo de memoria. La sección "Problemas de depuración" del artículo Asignación de memoria para UDR explica cómo hacerlo.

Reconsidere el uso de mi_lvarchar. Se debe prestar especial atención a los lugares donde se pasa mi_lvarchar a una función que espera recibir una cadena terminada en nulo como argumento.

Reduzca la cantidad de VP de CPU (o usuario) a uno para reproducir el problema más rápido.

mi_print_stack()--Solaris

Informix Dynamic Server para el sistema operativo Solaris incluye una función mi_print_stack() que se puede llamar en la UDR. De forma predeterminada, esta función guarda el marco de la pila en el siguiente archivo:

/tmp/default.pila

No puede cambiar el nombre del archivo de salida, pero puede cambiar su ubicación cambiando el valor de la variable de entorno DBTEMP. Asegúrese de que el usuario de informix pueda escribir en el directorio $DBTEMP. Cualquier error encontrado al ejecutar mi_print_stack() se informa a $MSGPATH.

Esta función sólo está disponible para OC Solaris.

Glosario

Términos y abreviaturas utilizadas en este artículo:

UDR	Rutina definida por el usuario
vicepresidente	Procesador virtual

Este artículo demuestra una vez más que cualquier conjunto de medidas de seguridad debe cubrir todas las etapas de implementación: desarrollo, implementación, administración del sistema y, por supuesto, medidas organizativas. En los sistemas de información, el “factor humano” (incluidos los usuarios) constituye la principal amenaza a la seguridad. Este conjunto de medidas debe ser razonable y equilibrado: no tiene sentido y es poco probable que se asignen fondos suficientes para organizar una protección que supere el coste de los propios datos.

Introducción

1C:Enterprise es el sistema de contabilidad más común en Rusia, pero a pesar de esto, hasta la versión 8.0 sus desarrolladores prestaron muy poca atención a los problemas de seguridad. Básicamente, por supuesto, esto fue dictado por el nicho de precios del producto y el enfoque en las pequeñas empresas donde no hay especialistas en TI calificados, y el posible costo de implementar y mantener un sistema seguro sería prohibitivamente costoso para la empresa. Con el lanzamiento de la versión 8.0, el énfasis tuvo que cambiar: el costo de las soluciones aumentó significativamente, el sistema se volvió mucho más escalable y flexible; los requisitos cambiaron significativamente. Si el sistema se ha vuelto suficientemente fiable y seguro es una cuestión muy individual. El principal sistema de información de una empresa moderna debe cumplir al menos los siguientes requisitos de seguridad:

• Probabilidad bastante baja de fallo del sistema por motivos internos.
• Autorización de usuario confiable y protección de datos contra acciones incorrectas.
• Un sistema eficaz para la asignación de derechos de usuario.
• Sistema de respaldo y recuperación en línea en caso de falla.

¿Las soluciones basadas en 1C:Enterprise 8.0 cumplen estos requisitos? No hay una respuesta clara. A pesar de cambios significativos en el sistema de control de acceso, quedan muchas cuestiones sin resolver. Dependiendo de cómo esté diseñado y configurado el sistema, es posible que todos estos requisitos no se cumplan o no se cumplan en medida suficiente para una implementación determinada, sin embargo, vale la pena prestar atención (y esto es una consecuencia importante de la “juventud” de la plataforma ) que para cumplir plenamente las condiciones enumeradas es necesario aplicar esfuerzos verdaderamente hercúleos.

Este artículo está dirigido a desarrolladores e implementadores de soluciones en la plataforma 1C:Enterprise, así como a administradores de sistemas de organizaciones donde se utiliza 1C:Enterprise, y describe algunos aspectos del desarrollo y configuración de la versión cliente-servidor del sistema desde el punto de vista de la organización seguridad de información. Este artículo no puede utilizarse como sustituto de la documentación, sino que sólo señala algunos puntos que aún no han sido reflejados en el mismo. Y, por supuesto, ni este artículo ni toda la documentación podrán reflejar la complejidad del problema de construir un sistema de información seguro, que al mismo tiempo debe satisfacer requisitos contradictorios de seguridad, rendimiento, conveniencia y funcionalidad.

Clasificación y terminología

El tema clave a considerar en el artículo son las amenazas a la información.

Amenaza de información– la posibilidad de una situación en la que los datos sean leídos, copiados, modificados o bloqueados sin autorización.

Y, a partir de esta definición, el artículo clasifica las amenazas a la información de la siguiente manera:

• Destrucción no autorizada de datos
• Cambio de datos no autorizado
• Copia no autorizada de datos
• Lectura no autorizada de datos
• Indisponibilidad de datos

Todas las amenazas se dividen en intencionales y no intencionales. Llamaremos a una amenaza de información realizada. incidente. Las características del sistema son:

Vulnerabilidades– características que conducen a incidentes Medidas de protección– características que bloquean la posibilidad de un incidente

Básicamente, solo se consideran aquellos casos cuya probabilidad se debe al uso de la plataforma tecnológica 1C: Enterprise 8.0 en la versión cliente-servidor (además, en los casos en que esto no contradiga el significado de simplemente 1C o 1C 8.0) . Definamos los siguientes roles principales en relación con el uso del sistema:

• Operadores– usuarios que tienen derechos para ver y cambiar datos limitados por una función de aplicación, pero no tienen funciones administrativas
• Administradores de sistemas– usuarios que tienen derechos administrativos en el sistema, incluidos derechos administrativos en los sistemas operativos del servidor de aplicaciones y el servidor MS SQL, derechos administrativos en MS SQL, etc.
• Administradores de seguridad de la información.– usuarios a quienes se delegan determinadas funciones administrativas en la base de información de 1C (como agregar usuarios, probar y reparar, realizar copias de seguridad, configurar una solución de aplicación, etc.)
• Desarrolladores de sistemas– usuarios que desarrollan una solución de aplicación. En general, es posible que no tengan acceso al sistema de trabajo.
• Personas que no tienen acceso directo al sistema– usuarios a los que no se les han delegado derechos de acceso a 1C, pero que pueden, en un grado u otro, influir en el funcionamiento del sistema (normalmente todos estos son usuarios del mismo dominio de Active Directory en el que está instalado el sistema). Esta categoría se considera principalmente para identificar sujetos potencialmente peligrosos en el sistema.
• Scripts administrativos automatizados– programas a los que se delegan determinadas funciones, diseñados para realizar automáticamente determinadas acciones (por ejemplo, importación-exportación de datos)

Cabe señalar aquí dos puntos: en primer lugar, esta clasificación es muy aproximada y no tiene en cuenta las divisiones dentro de cada grupo; dicha división se creará para algunos casos específicos y, en segundo lugar, se supone que otras personas no pueden influir en la operación. del sistema, que debe ser proporcionado por medios externos a 1C.

Cualquier sistema de seguridad debe diseñarse teniendo en cuenta la viabilidad y el coste de propiedad. En general, al desarrollar e implementar un sistema de información, es necesario que el precio de proteger el sistema corresponda a:

• el valor de la información protegida;
• costos de crear un incidente (en caso de una amenaza deliberada);
• riesgos financieros en caso de un incidente

Es inútil y perjudicial organizar una defensa que sea mucho más costosa que evaluar su eficacia financiera. Existen varios métodos para evaluar los riesgos de pérdida de información, pero no se analizan en el alcance de este artículo. Otro aspecto importante es mantener un equilibrio entre los requisitos, a menudo contradictorios, de seguridad de la información, rendimiento del sistema, conveniencia y facilidad para trabajar con el sistema, velocidad de desarrollo e implementación y otros requisitos para los sistemas de información empresarial.

Características principales del mecanismo de seguridad de la información del sistema.

1C:Enterprise 8.0 viene en dos versiones: archivo y cliente-servidor. No se puede considerar que la versión del archivo garantice la seguridad de la información del sistema por los siguientes motivos:

• Los datos y la configuración se almacenan en un archivo que todos los usuarios del sistema pueden leer y escribir.
• Como se mostrará a continuación, la autorización del sistema se puede eludir muy fácilmente.
• La integridad del sistema está garantizada únicamente por el núcleo de la parte cliente.

En la versión cliente-servidor, se utiliza MS SQL Server para almacenar información, que proporciona:

• Almacenamiento de datos más confiable.
• Aislamiento de archivos del acceso directo.
• Mecanismos de transacción y bloqueo más avanzados.

A pesar de las diferencias significativas entre las versiones de archivos y cliente-servidor del sistema, cuentan con un esquema de control de acceso unificado a nivel de solución de aplicación, que proporciona las siguientes capacidades:

• Autorización del usuario mediante la contraseña especificada en 1C.
• Autorización de usuario basada en el usuario actual de Windows.
• Asignación de roles a los usuarios del sistema.
• Limitación de funciones administrativas por rol.
• Asignación de interfaces disponibles por roles.
• Restringir el acceso a objetos de metadatos por rol.
• Restringir el acceso a los detalles del objeto por rol.
• Restringir el acceso a objetos de datos por roles y parámetros de sesión.
• Restringir el acceso interactivo a datos y módulos ejecutables.
• Algunas restricciones de ejecución de código.

En general, el esquema de acceso a datos utilizado es bastante típico de sistemas de información de este nivel. Sin embargo, en relación con esta implementación de una arquitectura cliente-servidor de tres niveles, existen varios aspectos fundamentales que conducen a un número relativamente grande de vulnerabilidades:

1. Hay una gran cantidad de etapas de procesamiento de datos y en cada etapa pueden aplicarse diferentes reglas para acceder a los objetos.

   En la Fig. 1 se muestra un diagrama algo simplificado de las etapas de procesamiento de datos que son importantes desde el punto de vista de la seguridad. Regla general para 1C es reducir las restricciones a medida que avanza en este esquema, por lo tanto, usar una vulnerabilidad en uno de niveles superiores puede perturbar el sistema en todos los niveles.

2. Procedimientos insuficientemente establecidos para monitorear los datos transmitidos al pasar de un nivel a otro.

   Desafortunadamente, no todos los mecanismos internos del sistema están perfectamente depurados, especialmente los mecanismos no interactivos, cuya depuración es siempre más laboriosa por un lado, pero más responsable por el otro. Esta "enfermedad" no es un problema exclusivo de 1C; se encuentra en muchos productos de servidor de la mayoría de los proveedores. Sólo en los últimos años ha aumentado significativamente la atención a estos problemas.

3. Cualificaciones medias insuficientemente altas de los desarrolladores y administradores de sistemas, heredadas de la versión anterior.

   Los productos de la línea 1C:Enterprise se centraron inicialmente en la facilidad de desarrollo y soporte y en el trabajo en organizaciones pequeñas, por lo que no es sorprendente que históricamente se haya desarrollado que una parte importante de los "desarrolladores" de soluciones de aplicaciones y "administradores" de Los sistemas no tienen suficientes conocimientos y habilidades para trabajar con un producto mucho más complejo, que es la versión 8.0. El problema se ve agravado por la práctica adoptada por las empresas franquiciadas de enseñar “en combate” a expensas de los clientes, sin abordar sistemáticamente esta cuestión. Es necesario rendir homenaje a la empresa 1C porque en los últimos años esta situación se ha ido corrigiendo gradualmente: las empresas franquiciadas serias han comenzado a abordar de forma más responsable el problema de la selección y formación del personal, el nivel de soporte tecnológico de la información por parte de la empresa 1C ha crecido significativamente, han aparecido programas de certificación destinados a un alto nivel de servicio; pero la situación no se puede corregir instantáneamente, por lo que este factor conviene tener en cuenta a la hora de analizar la seguridad del sistema.

4. La plataforma es relativamente joven.

   Entre productos de enfoque y propósito de uso similares, esta es una de las soluciones más jóvenes. La funcionalidad de la plataforma se estableció más o menos hace menos de un año. Al mismo tiempo, cada versión de la plataforma, comenzando con 8.0.10 (fue en esta versión donde se implementaron casi todas las capacidades actuales del sistema) se volvió significativamente más estable que las anteriores. La funcionalidad de las soluciones de aplicaciones estándar sigue creciendo a pasos agigantados, aunque solo se utiliza la mitad de las capacidades de la plataforma. Por supuesto, en tales condiciones podemos hablar de estabilidad de manera bastante condicional, pero en general hay que reconocer que, en muchos aspectos, las soluciones en la plataforma 1C 8.0 están significativamente por delante en funcionalidad y rendimiento (y a menudo en estabilidad) que soluciones similares en 1C. Plataforma 7.7.

Entonces, el sistema (y, posiblemente, una solución de aplicación estándar) se implementa en la empresa y se instala en las computadoras. En primer lugar, es necesario crear un entorno en el que tenga sentido configurar la seguridad 1C, y para ello debe configurarse de tal manera que se cumpla el supuesto de que la seguridad del sistema se ve significativamente afectada por la configuración del sistema.

Siga las reglas generales para configurar la seguridad.

No se puede hablar de seguridad de la información de un sistema si no se siguen los principios básicos de la creación de sistemas seguros. Asegúrese de asegurarse de que se cumplan al menos las siguientes condiciones:

• El acceso a los servidores está limitado físicamente y se garantiza su funcionamiento ininterrumpido:
  • el equipo del servidor cumple con los requisitos de confiabilidad, se ha ajustado el reemplazo del equipo del servidor defectuoso, para áreas particularmente críticas se utilizan esquemas con duplicación de hardware (RAID, energía de múltiples fuentes, múltiples canales de comunicación, etc.);
  • los servidores están ubicados en una sala cerrada con llave y esta sala se abre solo mientras dure el trabajo que no se puede realizar de forma remota;
  • Sólo una o dos personas tienen derecho a abrir la sala de servidores, en caso de emergencia se ha desarrollado un sistema de notificación a las personas responsables;
  • Se garantiza el suministro eléctrico ininterrumpido a los servidores.
  • se garantizan las condiciones climáticas normales de funcionamiento del equipo;
  • hay alarma contra incendios en la sala de servidores, no hay riesgo de inundación (especialmente en el primer y último piso);
• La configuración de la red y la infraestructura de información de la empresa se realiza correctamente:
  • Los firewalls están instalados y configurados en todos los servidores;
  • todos los usuarios y computadoras están autorizados en la red, las contraseñas son lo suficientemente complejas como para que no se puedan adivinar;
  • los operadores del sistema tienen derechos suficientes para trabajar normalmente con él, pero no tienen derechos para realizar acciones administrativas;
  • las herramientas antivirus están instaladas y habilitadas en todas las computadoras de la red;
  • Es deseable que los usuarios (excepto los administradores de red) no tengan derechos administrativos en las estaciones de trabajo cliente;
  • el acceso a Internet y a los medios de almacenamiento extraíbles debería regularse y limitarse;
  • se debe configurar la auditoría del sistema de eventos de seguridad;
• Se han resuelto las principales cuestiones organizativas:
  • los usuarios tienen calificaciones suficientes para trabajar con 1C y hardware;
  • se notifica a los usuarios la responsabilidad por la violación de las reglas de operación;
  • se han designado personas financieramente responsables para cada elemento material del sistema de información;
  • todas las unidades del sistema están selladas y cerradas;
  • Preste especial atención a instruir y supervisar a los limpiadores, trabajadores de la construcción y electricistas. Estas personas pueden, por negligencia, causar daños que no son comparables a los daños intencionados causados ​​por un usuario sin escrúpulos del sistema.

¡Atención! Esta lista no es exhaustiva, solo describe lo que a menudo se pasa por alto al implementar cualquier sistema de información bastante complejo y costoso.

• MS SQL Server, el servidor de aplicaciones y la parte del cliente se ejecutan en diferentes computadoras, las aplicaciones del servidor se ejecutan bajo los derechos de usuarios de Windows especialmente creados;
• Para servidor MS SQL
  • el modo de autorización mixta está configurado
  • Los usuarios de MS SQL incluidos en la función serveradmin no participan en el trabajo de 1C,
  • para cada IB 1C se ha creado un usuario MS SQL independiente que no tiene acceso privilegiado al servidor,
  • El usuario de MS SQL de un IS no tiene acceso a otro IS;
• Los usuarios no tienen acceso directo al servidor de aplicaciones ni a los archivos del servidor MS SQL.
• Las estaciones de trabajo del operador están equipadas con Windows 2000/XP (no Windows 95/98/Me)

No descuides las recomendaciones de los desarrolladores del sistema y la lectura de la documentación. Los materiales importantes sobre la configuración del sistema se publican en discos ITS en la sección "Recomendaciones metodológicas". Preste especial atención a los siguientes artículos:

1. Características de las aplicaciones que funcionan con el servidor 1C:Enterprise
2. Colocación de datos 1C:Enterprise 8.0
3. Actualización 1C:Enterprise 8.0 por parte de los usuarios Microsoft Windows sin derechos de administrador
4. Editar la lista de usuarios en nombre de un usuario que no tiene derechos administrativos
5. Configuración de los ajustes del firewall de Windows XP SP2 para ejecutar SQL Server 2000 y SQL Server Desktop Engine (MSDE)
6. Configuración de los parámetros COM+ de Windows XP SP2 para ejecutar el servidor 1C:Enterprise 8.0
7. Configuración del firewall de Windows XP SP2 para el servidor 1C:Enterprise 8.0
8. Configuración del firewall de Windows XP SP2 para HASP License Manager
9. Creando una copia de seguridad base de información utilizando SQL Server 2000
10. Problemas de instalación y configuración 1C:Enterprise 8.0 en la versión "cliente-servidor"(uno de los artículos más importantes)
11. Peculiaridades configuración de Windows Server 2003 al instalar el servidor 1C:Enterprise 8.0
12. Regular el acceso de los usuarios a la base de información en la versión cliente-servidor(uno de los artículos más importantes)
13. Servidor 1C:Servidor empresarial y SQL
14. Procedimiento de instalación detallado de 1C:Enterprise 8.0 en la versión "cliente-servidor"(uno de los artículos más importantes)
15. Usando el lenguaje integrado en el servidor 1C:Enterprise

Pero al leer la documentación, sea crítico con la información recibida, por ejemplo, el artículo "Problemas de instalación y configuración de 1C: Enterprise 8.0 en la versión cliente-servidor" no describe con precisión los derechos que se requieren para el usuario USER1CV8SERVER. Habrá enlaces a la lista a continuación, por ejemplo [ITS1] significa el artículo "Características de las aplicaciones que funcionan con el servidor 1C:Enterprise". Todos los enlaces a los artículos pertenecen al último número de ITS en el momento de escribir este artículo (enero de 2006).

Utilice capacidades de autorización combinadas con la autorización de Windows para los usuarios

De los dos modos posibles de autorización de usuario: 1C integrado y combinado con la autorización del sistema operativo Windows, si es posible, debe elegir la autorización combinada. Esto permitirá que los usuarios no se confundan con múltiples contraseñas cuando trabajen, pero no reducirá el nivel de seguridad del sistema. Sin embargo, incluso para los usuarios que usan solo la autorización de Windows, es muy recomendable establecer una contraseña al crearla y solo después deshabilitar la autorización 1C para este usuario. Para garantizar la recuperación del sistema en caso de destrucción de la estructura de Active Directory, es necesario dejar al menos un usuario que pueda iniciar sesión en el sistema utilizando la autorización 1C.

Al crear roles de solución de aplicaciones, no agregue derechos "en reserva"

Cada rol de solución de aplicación debe reflejar el conjunto mínimo requerido de derechos para realizar las acciones definidas por este rol. Sin embargo, es posible que algunas funciones no se utilicen de forma independiente. Por ejemplo, para lanzamiento interactivo tratamientos externos Puede crear una función independiente y agregarla a todos los usuarios que necesiten utilizar procesamiento externo.

Revisar periódicamente los registros y los protocolos de funcionamiento del sistema.

Si es posible, regule y automatice la visualización de registros y protocolos de funcionamiento del sistema. Con una configuración adecuada y una revisión periódica de los registros (filtrando solo por eventos importantes), las acciones no autorizadas se pueden detectar tempranamente o incluso prevenir durante la fase de preparación.

Algunas características de la versión cliente-servidor

Esta sección describe algunas de las características operativas de la opción cliente-servidor y su impacto en la seguridad. Para mayor facilidad de lectura, se utilizan las siguientes notaciones:

¡Atención! descripción de la vulnerabilidad

Almacenamiento de información que controla el acceso al sistema.

Almacenamiento de una lista de usuarios de seguridad de la información

Toda la información sobre la lista de usuarios de esta seguridad de la información y los roles disponibles para ellos en ella se almacena en la tabla Params en la base de datos MS SQL (ver [ITS2]). Al observar la estructura y el contenido de esta tabla, resulta obvio que toda la información del usuario se almacena en un registro con el valor del campo Nombre de archivo "usuarios.usr".

Dado que asumimos que los usuarios no tienen acceso a la base de datos MS SQL, este hecho en sí no puede ser utilizado por un atacante; sin embargo, si es posible ejecutar código en MS SQL, esto "abre la puerta" a la obtención de cualquier(! ) acceso desde 1C . El mismo mecanismo (con cambios menores) también se puede utilizar en la versión de archivo del sistema, lo que, teniendo en cuenta las características de la versión de archivo, excluye por completo su aplicabilidad en la construcción de sistemas seguros.

Recomendación: Por el momento, no existe forma de proteger completamente la aplicación de tales cambios, excepto mediante el uso de activadores a nivel de MS SQL Server, que, por otro lado, pueden causar problemas al actualizar la versión de la plataforma o cambiar la lista de usuarios. Para rastrear dichos cambios, puede usar el registro 1C (prestando atención a los inicios de sesión "sospechosos" en el modo configurador sin especificar el usuario) o mantener SQL Profiler en constante ejecución (lo que tendrá un impacto extremadamente negativo en el rendimiento del sistema) o configurar las Alertas mecanismo (muy probablemente juntos usando desencadenantes)

Almacenamiento de información sobre la lista IS en el servidor

Para cada servidor de aplicaciones 1C, se almacena información sobre la lista de bases de datos MS SQL conectadas a él. Cada base de datos utiliza su propia cadena de conexión del servidor de aplicaciones y del servidor MS SQL para funcionar. La información sobre las bases de datos registradas en el servidor de aplicaciones, junto con las cadenas de conexión, se almacena en el archivo srvrib.lst, que se encuentra en el directorio del servidor.<Общие данные приложений>/1C/1Cv8 (por ejemplo, C:/Documentos y configuraciones/Todos los usuarios/Datos de aplicación/1C/1Cv8/srvrib.lst). Para cada sistema de seguridad de la información, se almacena una cadena de conexión completa, incluida la contraseña de usuario de MS SQL cuando se utiliza un modelo de autorización mixto de MS SQL. Es la presencia de este archivo lo que hace posible temer el acceso no autorizado a la base de datos MS SQL, y si, contrariamente a las recomendaciones, se utiliza un usuario privilegiado (por ejemplo, "sa") para acceder al menos a una base de datos, entonces en Además de la amenaza a la seguridad de la información, existe una amenaza a todo el sistema que utiliza MS SQL.

Es interesante observar que el uso de autorización mixta y autorización de Windows en un servidor MS SQL genera diferentes tipos de problemas al obtener acceso a un archivo determinado. Entonces, las propiedades negativas clave de la autorización de Windows serán:

• Operación de toda la seguridad de la información en el servidor de aplicaciones y en el servidor MS SQL bajo un conjunto de derechos (probablemente redundante)
• Desde el proceso del servidor de aplicaciones 1C (o en general desde el usuario USER1CV8SERVER o su equivalente) sin especificar una contraseña, puede conectarse fácilmente a cualquier seguridad de la información sin especificar una contraseña.

Por otro lado, puede resultar más difícil para un atacante ejecutar código arbitrario desde el contexto del usuario USER1CV8SERVER que obtener el archivo especificado. Por cierto, la presencia de un archivo de este tipo es otro argumento para distribuir las funciones del servidor en diferentes computadoras.

Recomendación: Solo el proceso del servidor debe poder acceder al archivo srvrib.lst. Asegúrese de configurar la auditoría para cambiar este archivo.

Desafortunadamente, por defecto Este archivo Casi no está protegido contra la lectura, lo que debe tenerse en cuenta al implementar el sistema. La opción ideal sería que el servidor de aplicaciones impida la lectura y escritura de este archivo mientras se ejecuta (incluida la lectura y escritura por parte de las conexiones de usuario que se ejecutan en este servidor).

Falta de autorización al crear seguridad de la información en el servidor.

¡Atención! El error de falta de autorización se solucionó en la versión 8.0.14 de la plataforma 1C:Enterprise. En esta versión, apareció el concepto de "1C:Enterprise Server Administrator", pero siempre que la lista de administradores esté especificada en el servidor, el sistema funciona como se describe a continuación, así que no se olvide de esta posible característica.

Probablemente la mayor vulnerabilidad de esta sección es la capacidad de agregar casi ilimitadamente seguridad de la información al servidor de aplicaciones, como resultado de lo cual cualquier usuario que obtenga acceso a una conexión al servidor de aplicaciones automáticamente tendrá la capacidad de ejecutar código arbitrario en el servidor de aplicaciones. . Veamos esto con un ejemplo.

El sistema debe instalarse de la siguiente manera

• MS SQL Server 2000 (por ejemplo, nombre de red SRV1)
• Servidor 1C:Enterprise 8.0 (nombre de red SRV2)
• Parte del cliente 1C:Enterprise 8.0 (nombre de red WS)

Se supone que el usuario (en adelante USUARIO) que trabaja en el WS tiene al menos acceso mínimo a uno de los sistemas de seguridad de la información registrados en SRV2, pero no tiene acceso privilegiado a SRV1 y SRV2. En general, la combinación de funciones de las computadoras enumeradas no afecta la situación. El sistema se configuró teniendo en cuenta las recomendaciones de la documentación y de los discos ITS. La situación se muestra en la Fig. 2.

• configurar la seguridad COM+ en el servidor de aplicaciones para que solo los usuarios de 1C tengan derecho a conectarse al proceso del servidor de aplicaciones (más detalles [ITS12]);
• el archivo srvrib.lst debe ser de solo lectura para el usuario USER1CV8SERVER (para agregar nueva seguridad de información al servidor, permita temporalmente la escritura);
• Para conectarse a MS SQL, utilice únicamente el protocolo TCP/IP, en este caso puede:
  • restringir las conexiones mediante un firewall;
  • configurar el uso de un puerto TCP no estándar, lo que complicará la conexión de "forasteros" IB 1C;
  • utilizar cifrado de datos transmitidos entre el servidor de aplicaciones y el servidor SQL;
• configurar el firewall del servidor para que el uso de servidores MS SQL de terceros sea imposible;
• utilizar herramientas de seguridad de la intranet para excluir la posibilidad de que aparezca una computadora no autorizada en la red local (IPSec, políticas de seguridad de grupo, firewalls, etc.);
• No otorgue bajo ninguna circunstancia al usuario USER1CV8SERVER derechos administrativos sobre el servidor de aplicaciones.

Usando código que se ejecuta en el servidor

Cuando se utiliza la versión cliente-servidor de 1C, el desarrollador puede distribuir la ejecución del código entre el cliente y el servidor de aplicaciones. Para que el código (procedimiento o función) se ejecute solo en el servidor, es necesario colocarlo en un módulo general para el cual esté configurada la propiedad "Servidor" y, en el caso de que se permita la ejecución del módulo no solo en el servidor, coloque el código en la sección restringida “#If Server":

#Si servidor entonces
Función OnServer(Param1, Param2 = 0) Exportar // Esta función, a pesar de su sencillez, se ejecuta en el servidor
Parámetro1 = Parámetro1 + 12;
Devolver parámetro1;
Función final
#Terminara si

Al utilizar código que se ejecuta en el servidor, debes tener en cuenta que:

• el código se ejecuta con derechos USER1CV8SERVER en el servidor de aplicaciones (objetos COM y archivos de servidor están disponibles);
• todas las sesiones de usuario son ejecutadas por una instancia del servicio, por lo que, por ejemplo, un desbordamiento de pila en el servidor hará que todos los usuarios activos se desconecten;
• depurar módulos de servidor es difícil (por ejemplo, no se puede establecer un punto de interrupción en el depurador), pero debe hacerse;
• transferir el control del cliente al servidor de aplicaciones y viceversa puede requerir importantes recursos con grandes volúmenes de parámetros transferidos;
• uso de herramientas interactivas (formularios, documentos de hoja de cálculo, Cuadros de diálogo), los informes externos y el procesamiento en código en el servidor de aplicaciones son imposibles;
• no se permite el uso de variables globales (variables del módulo de aplicación declaradas con la indicación "Exportar");

Para obtener más detalles, consulte [ITS15] y otros artículos de ITS.

El servidor de aplicaciones debe tener requisitos especiales de confiabilidad. En un sistema cliente-servidor construido correctamente, se deben cumplir las siguientes condiciones:

• ninguna acción de la aplicación cliente debe interrumpir el funcionamiento del servidor (excepto en casos administrativos);
• el servidor no puede ejecutar el código del programa recibido del cliente;
• Los recursos deben distribuirse “justamente” entre conexiones de clientes, asegurando la disponibilidad del servidor independientemente de la carga actual;
• en ausencia de bloqueo de datos, las conexiones de los clientes no deberían afectar el trabajo de los demás;
• no en el servidor interfaz de usuario, pero se deben desarrollar herramientas de seguimiento y registro;

En general, el sistema 1C está construido de tal manera que se acerca más a estos requisitos (por ejemplo, es imposible forzar el procesamiento externo en el servidor), pero aún existen varias características desagradables, por lo que:

Recomendación: Al desarrollar un servidor de ejecución, se recomienda respetar el principio de interfaz mínima. Aquellos. el número de entradas en los módulos del servidor desde la aplicación cliente debe ser muy limitado y los parámetros deben estar estrictamente regulados. Recomendación: Al recibir parámetros de procedimientos y funciones en el servidor, es necesario validar los parámetros (verificar que los parámetros correspondan al tipo y rango de valores esperado). Esto no se hace en las soluciones estándar, pero es muy recomendable introducir una validación obligatoria en sus propios desarrollos. Recomendación: Al generar texto de solicitud (y especialmente el parámetro Ejecutar comando) en el lado del servidor, no utilice cadenas recibidas de la aplicación cliente.

Una recomendación general sería familiarizarse con los principios de construcción segura. web-aplicaciones de bases de datos y trabajo sobre principios similares. Las similitudes son realmente considerables: en primer lugar, al igual que una aplicación web, el servidor de aplicaciones es una capa intermedia entre la base de datos y la interfaz de usuario (la principal diferencia es que el servidor web forma la interfaz de usuario); en segundo lugar, desde el punto de vista de la seguridad, no se puede confiar en los datos recibidos del cliente, porque es posible iniciar informes y procesamientos externos.

Pasando parámetros

Pasar parámetros a una función (procedimiento) ejecutada en el servidor es una cuestión bastante delicada. Esto se debe principalmente a la necesidad de transferirlos entre el servidor de aplicaciones y los procesos del cliente. Cuando el control pasa del lado del cliente al servidor, todos los parámetros transmitidos se serializan, se transfieren al servidor, donde se "desempaquetan" y se utilizan. Al pasar del lado del servidor al lado del cliente, el proceso se invierte. Cabe señalar aquí que este esquema maneja correctamente el paso de parámetros por referencia y por valor. Al pasar parámetros, se aplican las siguientes restricciones:

• Solo se pueden transferir valores no mutables (es decir, cuyos valores no se pueden cambiar) entre el cliente y el servidor (en ambas direcciones): tipos primitivos, referencias, colecciones universales, valores de enumeración del sistema, almacenamiento de valores. Si intenta pasar algo más, la aplicación cliente falla (incluso si el servidor intenta pasar un parámetro incorrecto).
• No se recomienda transferir grandes cantidades de datos al pasar parámetros (por ejemplo, cadenas de más de 1 millón de caracteres), esto puede afectar negativamente el rendimiento del servidor.
• No puede pasar parámetros que contengan una referencia cíclica, tanto del servidor al cliente como viceversa. Si intenta pasar dicho parámetro, la aplicación cliente falla (incluso si el servidor intenta pasar el parámetro incorrecto).
• No se recomienda transferir colecciones de datos muy complejas. Cuando intenta pasar un parámetro con un nivel de anidamiento muy grande, el servidor falla (!).

¡Atención! La característica más molesta en este momento es probablemente el error al pasar colecciones complejas de valores. Entonces, por ejemplo, el código: Nivel de anidamiento = 1250;
M = Nueva matriz;
Parámetro aprobado = M;
Para cuenta = 1 por nivel de ciclo de anidamiento
MVInt = Nueva matriz;
M.Añadir(MVInt);
M = MVint;
Fin del ciclo;
FunciónServidor(PasadoParámetro);

Conduce a una parada de emergencia del servidor con la desconexión de todos los usuarios, y esto ocurre antes de que el control se transfiera al código en el lenguaje integrado.

Usar funciones inseguras en el lado del servidor.

No todas las herramientas de lenguaje integradas se pueden utilizar en el código ejecutado en el servidor de aplicaciones, pero incluso entre las herramientas disponibles hay muchas construcciones "problemáticas" que se pueden clasificar aproximadamente de la siguiente manera:

• capaz de proporcionar la capacidad de ejecutar código no contenido en la configuración (grupo "Ejecución de código")
• capaz de proporcionar a la aplicación cliente información sobre archivos y Sistema operativo usuario o realizar acciones no relacionadas con el trabajo con datos (“Violación de derechos”)
• capaz de provocar una caída del servidor o utilizar recursos muy grandes (grupo "Caída del servidor")
• capaz de causar una falla del cliente (grupo de fallas del cliente); este tipo no se considera. Ejemplo: pasar un valor mutable al servidor.
• errores en algoritmos de programación (bucles sin fin, recursividad ilimitada, etc.) (“Errores de programación”)

Los principales diseños problemáticos que conozco (con ejemplos) se enumeran a continuación:

Procedimiento Ejecutar(<Строка>)

Ejecutando código. Le permite ejecutar un fragmento de código que se le pasa como un valor de cadena. Cuando se utiliza en el servidor, debe asegurarse de que los datos recibidos del cliente no se utilicen como parámetro. Por ejemplo, no se permite el siguiente uso:

#Si servidor entonces
ProcedimientoOnServer(Param1) Exportar
Ejecutar (Parámetro1);
Fin del Procedimiento
#Terminara si

Escriba "COMObject" (constructor Nuevo COMObject(<Имя>, <Имя сервера>))

Crea un objeto COM de aplicación externa con derechos USER1CV8SERVER en el servidor de aplicaciones (u otra computadora especificada). Cuando se utiliza en un servidor, asegúrese de que los parámetros no se pasen desde la aplicación cliente. Sin embargo, en el lado del servidor es eficaz utilizar esta función al importar/exportar, enviar datos a través de Internet, implementar funciones no estándar, etc.

Función ObtenerCOMObject(<Имя файла>, <Имя класса COM>)

Violación de derechos y ejecución de código. Similar al anterior, solo obteniendo el objeto COM correspondiente al archivo.

Procedimientos y funciones ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()

Violación de derechos. Al ejecutarlos en el servidor, permiten conocer los detalles de la organización del subsistema del servidor. Cuando se utiliza en un servidor, asegúrese de que los datos no se transfieran al cliente o que los operadores no puedan acceder a ellos sin el permiso adecuado. Preste especial atención al hecho de que los datos se pueden devolver en un parámetro pasado por referencia.

Procedimientos y funciones para trabajar con archivos (CopyFile, FindFiles, MergeFiles y muchos otros), así como tipos de archivos.

Violación de derechos. Permiten, ejecutándolos en el servidor, obtener acceso compartido a archivos locales (y ubicados en la red) accesibles bajo los derechos de usuario USER1CV8SERVER. Si se usa conscientemente, entonces es posible implementar efectivamente tareas como importar/exportar datos en el servidor.

Asegúrese de verificar sus derechos de usuario de 1C antes de utilizar estas funciones. Para comprobar los derechos del usuario, puede utilizar la siguiente construcción en el módulo del servidor:

#Si servidor entonces
Procedimiento Exportar PerformWorkWithFile()
RoleAdministrator = Metadatos.Roles.Administrador;
Usuario = SessionParameters.CurrentUser;
Si User.Roles.Contains (RoleAdministrator) Entonces
//Aquí se ejecuta el código para trabajar con archivos
terminara si;
#Terminara si

Asegúrese de verificar los parámetros si utiliza estos procedimientos y funciones; de lo contrario, existe el riesgo de causar accidentalmente o deliberadamente un daño irreparable al servidor de aplicaciones 1C, por ejemplo, al ejecutar el siguiente código en el servidor:

Ruta = "C:\Documentos y configuraciones\Todos los usuarios\Datos de programa\1C\1Cv8\";
MoveFile(Ruta + "srvrib.lst", Ruta + "Aquí es donde va el archivo");

Después de ejecutar dicho código en el servidor, si el usuario USER1CV8SERVER tiene derechos para cambiarlo, como se describe anteriormente, y después de reiniciar el proceso del servidor (de forma predeterminada, 3 minutos después de que todos los usuarios salgan), surgirá una GRAN pregunta sobre cómo iniciar el servidor. . Pero también es posible eliminar archivos por completo...

Tipos "XBase", "BinaryData", "XML Reader", "XML Writer", "XSL Transformation", "ZipFile Writer", "ZipFile Reader", "Text Reader", "Text Writer"

Violación de derechos. Permiten, al ejecutarlos en el servidor, acceder a archivos locales (y ubicados en la red) de determinados tipos y leerlos/escribirlos bajo los derechos de usuario USER1CV8SERVER. Si se usa conscientemente, es posible implementar efectivamente tareas como importar/exportar datos en el servidor, registrar el funcionamiento de ciertas funciones y resolver tareas administrativas. En general, las recomendaciones coinciden con el párrafo anterior, pero conviene considerar la posibilidad de transferir datos de estos archivos (pero no objetos de todos estos tipos) entre la parte cliente y la parte servidor.

Escriba "Información del sistema"

Violación de derechos. Le permite obtener datos sobre el servidor de la aplicación en caso de uso incorrecto y transferencia de datos a la parte cliente de la aplicación. Es recomendable limitar el derecho de uso al utilizar.

Tipos "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Violación de derechos. Cuando se utiliza en un servidor, se conecta a una PC remota desde un servidor de aplicaciones bajo los derechos USER1CV8SERVER. Recomendaciones:

• Control de parámetros al llamar a métodos.
• Control de derechos de usuario de 1C.
• Severas restricciones a los derechos del usuario USER1CV8SERVER para acceder a la red.
• Configurar correctamente el firewall en el servidor de aplicaciones 1C.

Cuando se utiliza correctamente, resulta conveniente organizar, por ejemplo, el envío de correos electrónicos desde un servidor de aplicaciones.

Tipos "InformationBaseUserManager", "InformationBaseUser"

Violación de derechos. Si se usa incorrectamente (en un módulo privilegiado), es posible agregar usuarios o cambiar los parámetros de autorización de los usuarios existentes.

Formato de función

Fallo del servidor.¡Sí! Esta función aparentemente inofensiva, si sus parámetros no se controlan y ejecutan en el servidor, puede provocar que la aplicación del servidor falle. El error ocurre al formatear números y usar el modo para mostrar ceros a la izquierda y una gran cantidad de caracteres, por ejemplo

Formato(1, "CHZ=999; CHVN=");

Espero que este error se corrija en las próximas versiones de la plataforma, pero mientras tanto, en todas las llamadas a esta función que se puedan ejecutar en el servidor, verifique los parámetros de llamada.

Procedimientos y funciones para guardar valores (ValueInRowInt, ValueInFile)

Fallo del servidor. Estas funciones no manejan referencias circulares en colecciones ni anidamientos muy profundos, por lo que pueden fallar en algunos casos muy especiales.

Errores en los valores de límites y parámetros especiales en funciones. Control de ejecución.

Uno de los problemas que puede encontrar al utilizar un servidor es la alta "responsabilidad" de las funciones del servidor (la posibilidad de que toda la aplicación del servidor falle debido a un error en una conexión y el uso de un "espacio de recursos" para todas las conexiones) . De ahí la necesidad de controlar los principales parámetros de tiempo de ejecución:

• Para funciones de lenguaje integradas, verifique sus parámetros de inicio (un buen ejemplo es la función "Formato")
• Cuando utilice bucles, asegúrese de que se cumpla la condición de salida del bucle. Si el bucle es potencialmente infinito, limite artificialmente el número de iteraciones: MaximumIterationCounterValue = 1000000;
  Contador de iteraciones = 1;
  Adiós
  FunciónWhichMayNotReturnFalseValue()
  Y (recuento de iteraciones<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Cuerpo del bucle
  Contador de iteraciones = Contador de iteraciones + 1;
  Fin del ciclo;
  Si el contador de iteraciones>Valor máximo del contador de iteraciones, entonces
  //.... manejar el evento de ejecución de un bucle excesivamente largo
  terminara si;

• Cuando utilice la recursividad, limite el nivel máximo de anidamiento.
• Al formar y ejecutar consultas, trate de evitar selecciones muy largas y selecciones de una gran cantidad de información (por ejemplo, cuando use la condición "EN JERARQUÍA", no use un valor vacío)
• Al diseñar una base de información, proporcione una reserva suficientemente grande de profundidad de bits para los números (de lo contrario, la suma y la multiplicación se vuelven no conmutativas ni asociativas, lo que dificulta la depuración)
• En consultas ejecutables, verifique la lógica de operación para detectar la presencia de valores NULL y el funcionamiento correcto de las condiciones y expresiones de consulta que utilizan NULL.
• Cuando utilice colecciones, controle la capacidad de transferirlas entre el servidor de aplicaciones y el lado del cliente.

Usar el acceso de terminal al lado del cliente para restringir el acceso

A menudo puede encontrar recomendaciones para utilizar el acceso al terminal para limitar el acceso a los datos y mejorar el rendimiento ejecutando código del lado del cliente en el servidor del terminal. Sí, si se configura correctamente, el uso del acceso al terminal puede aumentar el nivel general de seguridad del sistema, pero, desafortunadamente, a menudo se puede encontrar el hecho de que con el uso práctico la seguridad del sistema solo disminuye. Intentemos descubrir con qué está conectado esto. Ahora existen dos medios comunes para organizar el acceso a la terminal: Microsoft Terminal Services (protocolo RDP) y Citrix Metaframe Server (protocolo ICA). En general, las herramientas de Citrix brindan opciones de administración de acceso mucho más flexibles, pero el precio de estas soluciones es mucho mayor. Consideraremos sólo las características básicas comunes a ambos protocolos que pueden reducir el nivel general de seguridad. Sólo existen tres peligros principales al utilizar el acceso a la terminal:

• Capacidad de bloquear el trabajo de otros usuarios al apoderarse de cantidades excesivas de recursos.
• Acceso a los datos de otros usuarios.
• Copia no autorizada de datos del servidor terminal al ordenador del usuario

En cualquier caso, Terminal Services le permite:

• Incrementar la confiabilidad del trabajo (si hay una falla en el ordenador terminal, el usuario puede posteriormente continuar trabajando desde el mismo lugar)
• Restrinja el acceso a la aplicación cliente y a los archivos que guarda.
• Transferir la carga informática desde la estación de trabajo del usuario al servidor de acceso al terminal
• Administre la configuración del sistema de manera más centralizada. Para los usuarios, la configuración guardada será válida independientemente de desde qué computadora iniciaron sesión en el sistema.
• En algunos casos, puede utilizar una solución de terminal para acceder remotamente al sistema.

Es necesario limitar el número de conexiones posibles al servidor de terminal para un usuario.

Debido a la "glotonería" de la aplicación cliente 1C con respecto a los recursos, es imperativo limitar el número máximo de conexiones simultáneas de un usuario (operador) al servidor terminal. Una conexión utilizada activamente puede utilizar hasta 300 MB de memoria con una sola instancia de la aplicación. Además de la memoria, se utiliza activamente el tiempo de la CPU, lo que tampoco contribuye a la estabilidad de los usuarios de este servidor. Al mismo tiempo que impide el uso excesivo de los recursos del servidor, dicha restricción puede impedir el uso de los recursos de otra persona. cuenta. Implementado mediante la configuración estándar del servidor de terminal.

No debe permitir que más de una o dos aplicaciones cliente 1C se ejecuten simultáneamente en una conexión

Dictado por las mismas razones que en el párrafo anterior, pero técnicamente más difícil de implementar. El problema es que es casi imposible evitar que 1C se reinicie usando las herramientas del servidor de terminal (por qué se explicará a continuación), por lo que debe implementar esta función en el nivel de la solución de la aplicación (que tampoco es una buena solución, ya que las sesiones pueden permanecer "colgadas" durante algún tiempo. Si la aplicación se finaliza incorrectamente, es necesario perfeccionar la solución de la aplicación en el módulo de la aplicación y algunos libros de referencia, lo que complicará el uso de las actualizaciones de 1C). Es muy recomendable dejar al usuario la capacidad de ejecutar 2 aplicaciones para poder ejecutar algunas acciones (por ejemplo, generar informes) en segundo plano; desafortunadamente, la aplicación cliente es en realidad de un solo subproceso.

No se recomienda otorgar derechos de acceso al servidor de terminal a los usuarios que tienen derecho a ejecutar tareas informáticas que consumen muchos recursos en 1C o evitar dicho inicio mientras otros usuarios están trabajando activamente.

Por supuesto, es mejor dejar el acceso al servidor terminal sólo a los usuarios que no utilizan tareas como minería de datos, diagramas geográficos, importación/exportación y otras tareas que cargan seriamente la parte cliente de la aplicación. Si aún es necesario permitir tales tareas, entonces es necesario: notificar al usuario que estas tareas pueden afectar el desempeño de otros usuarios, registrar el inicio y el final de dicho proceso en el registro, permitir la ejecución solo en un momento regulado tiempo, etc

Es necesario asegurarse de que cada usuario tenga derechos de escritura solo en directorios estrictamente definidos en el servidor de terminal y que otros usuarios no tengan acceso a ellos.

En primer lugar, si no limita la capacidad de escribir en directorios compartidos (como el directorio donde está instalado 1C), un atacante sigue siendo posible cambiar el comportamiento del programa para todos los usuarios. En segundo lugar, los datos de un usuario (archivos temporales, archivos para guardar la configuración del informe, etc.) bajo ninguna circunstancia deben ser accesibles a otro usuario del servidor terminal; en general, durante la configuración normal, se sigue esta regla. En tercer lugar, el atacante todavía tiene la oportunidad de "ensuciar" la partición para que no quede espacio en el disco duro. Sé que me objetarán que el sistema operativo Windows, empezando por Windows 2000, tiene un mecanismo de cuotas, pero se trata de un mecanismo bastante caro y prácticamente nunca he visto ningún uso real del mismo.

Si las cuestiones anteriores sobre la configuración del acceso eran en general bastante fáciles de implementar, entonces una tarea tan (aparentemente) simple como regular el acceso de los usuarios a los archivos no se implementa de manera trivial. En primer lugar, si no se utiliza el mecanismo de cuotas, se pueden guardar archivos grandes. En segundo lugar, el sistema está diseñado de tal manera que casi siempre será posible guardar el archivo para que esté disponible para otro usuario.

Teniendo en cuenta que la tarea es difícil de resolver por completo, se recomienda auditar la mayoría de los eventos de archivos.

Es necesario prohibir la conexión (mapeo) de dispositivos de disco, impresoras y el portapapeles de la estación de trabajo del cliente.

En RDP e ICA, es posible organizar la conexión automática de discos, impresoras, puertos com del portapapeles de la computadora terminal al servidor. Si existe esta oportunidad, entonces es casi imposible evitar el lanzamiento de código externo en el servidor de terminal y el almacenamiento de datos de 1C en el cliente de acceso al terminal. Permita estas funciones solo para aquellos con derechos administrativos.

El acceso a archivos de red desde el servidor terminal debe ser limitado.

Si no se hace esto, el usuario podrá nuevamente ejecutar código no deseado o guardar datos. Dado que el registro normal no rastrea los eventos de archivos (por cierto, una buena idea para que lo implementen los desarrolladores de plataformas) y es casi imposible configurar una auditoría del sistema en toda la red (no hay suficientes recursos para mantenerla), es mejor que el usuario pueda enviar datos para imprimir o por correo electrónico. Preste especial atención a garantizar que el servidor de terminal no funcione directamente con los medios extraíbles de los usuarios.

Bajo ninguna circunstancia debe dejar el servidor de aplicaciones en el servidor de terminal al crear un sistema seguro.

Si el servidor de aplicaciones se ejecuta en la misma computadora que las aplicaciones cliente, existen muchas oportunidades de interrumpir su funcionamiento normal. Si por alguna razón es imposible separar las funciones del servidor de terminal y del servidor de aplicaciones, preste especial atención al acceso de los usuarios a los archivos utilizados por el servidor de aplicaciones.

Es necesario excluir la posibilidad de ejecutar todas las aplicaciones excepto 1C:Enterprise en el servidor terminal.

Este es uno de los deseos más difíciles de implementar. Comencemos con el hecho de que necesita configurar correctamente la política de política de seguridad de grupo en el dominio. Todas las Plantillas Administrativas y Políticas de Restricción de Software deben configurarse correctamente. Para ponerte a prueba, asegúrate de que al menos las siguientes funciones estén bloqueadas:

La complejidad de implementar este requisito a menudo conduce a la posibilidad de iniciar una sesión 1C "extra" en el servidor terminal (incluso si otras aplicaciones son limitadas, es fundamentalmente imposible prohibir el inicio de 1C usando Windows).

Considere las limitaciones del registro normal (todos los usuarios usan el programa desde una computadora)

Obviamente, dado que los usuarios abren 1C en modo terminal, el servidor de terminal se registrará en el registro. El registro no indica desde qué computadora se conectó el usuario.

Terminal Server: ¿protección o vulnerabilidad?

Entonces, después de considerar las características principales de la terminal norte, podemos decir que la terminal norte puede ayudar potencialmente en la automatización para distribuir la carga informática, pero construir un sistema seguro es bastante difícil. Uno de los casos en los que el uso de un servidor de terminal es más efectivo es cuando se ejecuta 1C sin el Explorador de Windows en modo de pantalla completa para usuarios con funcionalidad limitada y una interfaz especializada.

Trabajo de la parte del cliente.

Usando Internet Explorer (IE)

Una de las condiciones para el funcionamiento normal de la parte del cliente 1C es el uso de componentes. explorador de Internet. Hay que tener mucho cuidado con estos componentes.

¡Atención! En primer lugar, si un módulo de spyware o adware está "adjunto" a IE, se cargará incluso si ve algún archivo HTML en 1C. Hasta ahora no he visto ningún uso consciente de esta función, pero he visto en una de las organizaciones un módulo "espía" cargado de una de las redes pornográficas con 1C en ejecución (el programa antivirus no se actualizó, cuyos síntomas se detectaron : al configurar el firewall, estaba claro que 1C estaba intentando conectarse en el puerto 80 a un sitio porno). En realidad, este es otro argumento a favor de que la protección debe ser integral.

¡Atención! En segundo lugar, el sistema 1C permite utilizar películas Flash, objetos ActiveX, VBScript en documentos HTML mostrados, enviar datos a Internet, incluso abrir archivos PDF (!), aunque en este último caso pregunta “abrir o guardar”... En general, todo lo que tu corazón desea. Un ejemplo de un uso no del todo razonable de las capacidades integradas de visualización y edición de HTML:

• Cree un nuevo documento HTML (Archivo -> Nuevo -> Documento HTML).
• Vaya a la pestaña "Texto" del documento en blanco.
• Elimina el texto (por completo).
• Vaya a la pestaña "Ver" de este documento
• Usando arrastrar y soltar, mueva un archivo con extensión SWF (estos son archivos de películas Flash) desde un Explorador abierto a una ventana de documento, por ejemplo desde el caché del navegador, aunque también puede usar un juguete FLASH por diversión.
• ¡Que adorable! ¡Puedes ejecutar un juguete en 1C!

Desde el punto de vista de la seguridad del sistema, esto es completamente incorrecto. Hasta ahora no he visto ningún ataque especial a 1C a través de esta vulnerabilidad, pero lo más probable es que sea cuestión de tiempo y del valor de su información.

Hay algunos otros problemas menores que surgen al trabajar con un campo de documento HTML, pero los principales son los dos enumerados. Sin embargo, si aborda estas funciones de manera creativa, puede organizar capacidades de interfaz realmente sorprendentes para trabajar con 1C.

Utilización de informes y procesamientos externos.

¡Atención! Informes y procesamiento externos, por un lado, manera conveniente implementación de formularios impresos adicionales, informes regulatorios, informes especializados, por otro lado, una forma potencial de eludir muchas restricciones de seguridad del sistema e interrumpir el funcionamiento del servidor de aplicaciones (por ejemplo, ver arriba en "Pasar parámetros"). En el sistema 1C hay un parámetro especial en el conjunto de derechos para la función "Apertura interactiva de procesamiento externo", pero esto no resuelve completamente el problema; para una solución completa es necesario reducir el círculo de usuarios que pueden administrar formularios impresos externos, informes regulatorios y otras capacidades estándar de soluciones estándar implementadas mediante tratamientos externos. Por ejemplo, de forma predeterminada en UPP, todos los roles de usuario principales tienen la capacidad de trabajar con un directorio de formularios impresos adicionales, y esta, de hecho, es la capacidad de utilizar cualquier procesamiento externo.

Utilizar mecanismos estándar para soluciones y plataformas estándar (intercambio de datos)

Algunos de los mecanismos estándar son potencialmente peligrosos y de formas inesperadas.

Listas de impresión

Cualquier lista (por ejemplo, un directorio o registro de información) del sistema se puede imprimir o guardar en un archivo. Para hacer esto, simplemente use la función estándar disponible en el menú contextual y el menú "Acciones":

Tenga en cuenta que prácticamente todo lo que el usuario ve en las listas se puede enviar a archivos externos. Lo único que podemos recomendar es mantener un registro de la impresión de documentos en los servidores de impresión. Para formularios particularmente críticos, es necesario configurar el panel de acciones asociado con el campo de la tabla protegida para que la capacidad de mostrar una lista no esté disponible desde este panel y deshabilitar el menú contextual (ver Figura 6).

Intercambio de datos en una base de datos distribuida.

El formato de intercambio de datos es bastante sencillo y se describe en la documentación. Si el usuario tiene la capacidad de reemplazar varios archivos, puede realizar cambios no autorizados en el sistema (aunque esta es una tarea bastante laboriosa). La capacidad de crear una base de datos periférica cuando se utilizan planes de intercambio de bases de datos distribuidas no debería estar disponible para los operadores comunes.

Intercambio de datos XML estándar

En el intercambio de datos estándar, que se utiliza para el intercambio entre configuraciones estándar (por ejemplo, "Gestión comercial" y "Contabilidad empresarial"), es posible especificar controladores de eventos para cargar y descargar objetos en las reglas de intercambio. Esto se implementa obteniendo un controlador del archivo y el procedimiento "Ejecutar()" para el procesamiento estándar de carga y descarga de archivos (el procedimiento "Ejecutar()" se inicia en el lado del cliente). Obviamente, no es difícil crear un archivo de intercambio falso que realice acciones maliciosas. Para la mayoría de los roles de usuario de soluciones estándar, se permite compartir de forma predeterminada.

Recomendación: restringir el acceso al intercambio XML para la mayoría de los usuarios (dejándolo solo a los administradores de seguridad de la información). Mantenga registros de las ejecuciones de este procesamiento, guardando el archivo de intercambio, por ejemplo, enviándolo Por correo electrónico administrador de seguridad de la información antes de realizar la descarga.

Usar informes genéricos, especialmente la Consola de informes

Otro problema es el acceso predeterminado de los usuarios a informes genéricos, especialmente al informe de la Consola de informes. Este informe se caracteriza por el hecho de que le permite ejecutar casi cualquier solicitud de seguridad de la información y, incluso si el sistema de derechos 1C (incluido RLS) está configurado de manera bastante estricta, permite al usuario obtener una gran cantidad de información "extra". y obligar al servidor a ejecutar una solicitud que consumirá todos los recursos del sistema.

Uso del modo de pantalla completa (modo de escritorio)

Una de las formas efectivas de organizar interfaces especializadas con acceso limitado a la funcionalidad del programa es el modo de pantalla completa de la forma principal (y posiblemente única) de la interfaz utilizada. En este caso, no hay problemas de accesibilidad, por ejemplo, el menú "Archivo" y todas las acciones del usuario están limitadas por las capacidades del formulario utilizado. Para obtener más detalles, consulte "Características de la implementación del modo de escritorio" en el disco ITS.

Respaldo

La copia de seguridad para la versión cliente-servidor de 1C se puede realizar de dos maneras: cargando datos en un archivo con la extensión dt y creando copias de seguridad usando SQL. El primer método tiene muchas desventajas: se requiere acceso exclusivo, la creación de una copia en sí lleva mucho más tiempo, en algunos casos (si se viola la estructura de seguridad de la información) es imposible crear un archivo, pero hay una ventaja: el tamaño mínimo de el archivo. Para la copia de seguridad de SQL, ocurre lo contrario: la creación de una copia se produce en segundo plano utilizando el servidor SQL, debido a la estructura simple y la falta de compresión; este es un proceso muy rápido y siempre que se mantenga la integridad física del SQL. la base de datos no está rota, se realiza la copia de seguridad, pero el tamaño de la copia coincide con el tamaño real de la seguridad de la información en el estado expandido (no se realiza la compresión). Debido a las ventajas adicionales del sistema de copia de seguridad MS SQL, es más recomendable utilizarlo (se permiten 3 tipos de copias de seguridad: completa, diferencial, copia del registro de transacciones; es posible crear trabajos ejecutados periódicamente; una copia de seguridad y una copia de seguridad el sistema se implementa rápidamente; es posible predecir el tamaño del espacio en disco requerido, etc.). Los puntos principales a la hora de organizar una copia de seguridad desde el punto de vista de la seguridad del sistema son:

• La necesidad de elegir una ubicación de almacenamiento para las copias de seguridad de modo que no sean accesibles para los usuarios.
• La necesidad de almacenar copias de seguridad a una distancia física del servidor MS SQL (en caso de desastres naturales, incendios, ataques, etc.)
• La capacidad de otorgar derechos para iniciar una copia de seguridad a un usuario que no tiene acceso a las copias de seguridad.

Para obtener más detalles, consulte la documentación de MS SQL.

Cifrado de datos

Para proteger los datos del acceso no autorizado, a menudo se utilizan diversas herramientas criptográficas (tanto software como hardware), pero su viabilidad depende en gran medida de la correcta aplicación y la seguridad general del sistema. Analizaremos el cifrado de datos en varias etapas de la transmisión y almacenamiento de datos utilizando los medios más comunes y los principales errores en el diseño de sistemas utilizando herramientas criptográficas.

Hay varias etapas principales del procesamiento de la información que se pueden proteger:

• Transferencia de datos entre la parte cliente del sistema y el servidor de aplicaciones.
• Transferencia de datos entre el servidor de aplicaciones y MS SQL Server
• Datos almacenados en MS SQL Server (archivos de datos en disco físico)
• Cifrado de datos almacenados en seguridad de la información.
• Datos externos (en relación con la seguridad de la información)

Para los datos almacenados en el lado del cliente y en el servidor de aplicaciones (configuraciones de usuario guardadas, lista de seguridad de la información, etc.), el cifrado se justifica sólo en casos muy raros y, por lo tanto, no se considera aquí. A la hora de utilizar herramientas criptográficas, no debemos olvidar que su uso puede reducir significativamente el rendimiento del sistema en su conjunto.

Información general sobre la protección criptográfica de las conexiones de red cuando se utiliza el protocolo TCP/IP.

Sin seguridad, todas las conexiones de red son vulnerables a vigilancia y acceso no autorizados. Para protegerlos, puede utilizar el cifrado de datos a nivel de protocolo de red. Para cifrar los datos transmitidos en una red local, se utilizan con mayor frecuencia las herramientas IPSec proporcionadas por el sistema operativo.

Las herramientas IPSec proporcionan cifrado de datos transmitidos mediante algoritmos DES y 3DES, así como verificación de integridad mediante funciones hash MD5 o SHA1. IPSec puede funcionar en dos modos: modo transporte y modo túnel. El modo de transporte es más adecuado para proteger conexiones en una red local. El modo túnel se puede utilizar para organizar conexiones VPN entre segmentos de red separados o proteger una conexión remota a una red local a través de canales de datos abiertos.

Las principales ventajas de este enfoque son:

• Posibilidad de gestión de seguridad centralizada mediante herramientas de Active Directory.
• La capacidad de excluir conexiones no autorizadas al servidor de aplicaciones y al servidor MS SQL (por ejemplo, es posible proteger contra la adición no autorizada de seguridad de información en el servidor de aplicaciones).
• Eliminación de la "escucha" del tráfico de la red.
• No es necesario cambiar el comportamiento de los programas de aplicación (en este caso 1C).
• La naturaleza estándar de tal solución.

Sin embargo, este enfoque tiene limitaciones y desventajas:

• IPSec no protege los datos de interferencias y escuchas directas en las computadoras de origen y de destino.
• La cantidad de datos transferidos a través de la red es ligeramente mayor que sin utilizar IPSec.
• Cuando se utiliza IPSec, la carga en el procesador central es ligeramente mayor.

Una descripción detallada de la implementación de las herramientas IPSec está más allá del alcance de este artículo y requiere una comprensión de los principios básicos del funcionamiento del protocolo IP. Para configurar correctamente la seguridad de la conexión, lea la documentación correspondiente.

Por separado, es necesario mencionar varios aspectos del acuerdo de licencia con 1C al organizar conexiones VPN. El hecho es que, a pesar de la ausencia de restricciones técnicas, al conectar varios segmentos de una red local o al acceder remotamente una computadora individual a una red local, generalmente se requieren varios suministros básicos.

Cifrado de datos cuando se transfieren entre la parte cliente del sistema y el servidor de aplicaciones.

Además del cifrado a nivel de protocolo de red, es posible cifrar datos a nivel de protocolo COM+, como se menciona en el artículo "Regulación del acceso de los usuarios a la base de información en la versión cliente-servidor" de ITS. Para implementarlo, debe configurar el nivel de autenticación para llamadas en "Privacidad de paquetes" para la aplicación 1CV8 en "Servicios de componentes". Cuando se configura en este modo, el paquete se autentica y cifra, incluidos los datos y la identidad y firma del remitente.

Cifrado de datos cuando se transfieren entre el servidor de aplicaciones y MS SQL Server

MS SQL Server proporciona las siguientes herramientas para el cifrado de datos:

• Es posible utilizar Secure Sockets Layer (SSL) al transferir datos entre el servidor de aplicaciones y MS SQL Server.
• Cuando se utiliza la biblioteca de red multiprotocolo, el cifrado de datos se utiliza a nivel RPC. Este es un cifrado potencialmente más débil que el uso de SSL.
• Si se utiliza el protocolo de intercambio de memoria compartida (esto sucede si el servidor de aplicaciones y el servidor MS SQL están ubicados en la misma computadora), entonces no se utiliza cifrado en ningún caso.

Para establecer la necesidad de cifrar todos los datos transmitidos para un servidor MS SQL específico, debe utilizar la utilidad "Server Network Utility". Ejecútelo y en la pestaña "General", marque la casilla de verificación "Forzar cifrado de protocolo". El método de cifrado se selecciona según el utilizado por la aplicación cliente (es decir, el servidor de aplicaciones 1C). Para utilizar SSL, debe configurar correctamente el servicio de certificados en su red.

Para configurar la necesidad de cifrar todos los datos transmitidos para un servidor de aplicaciones específico, debe utilizar la utilidad "Client Network Utility" (generalmente ubicada en "C:\WINNT\system32\cliconfg.exe"). Como en el caso anterior, en la pestaña "General", marque la casilla "Forzar cifrado de protocolo".

Vale la pena considerar que el uso de cifrado en este caso puede tener un impacto significativo en el rendimiento del sistema, especialmente cuando se utilizan consultas que devuelven grandes cantidades de información.

Para proteger más completamente la conexión entre el servidor de aplicaciones y MS SQL Server cuando se utiliza el protocolo TCP/IP, podemos recomendar varios cambios en la configuración predeterminada.

En primer lugar, puede configurar un puerto distinto al estándar (el puerto 1433 se utiliza de forma predeterminada). Si decide utilizar un puerto TCP no estándar para el intercambio de datos, tenga en cuenta que:

• El servidor MS SQL y el servidor de aplicaciones deben utilizar el mismo puerto.
• Cuando se utilizan firewalls, se debe permitir este puerto.
• No puede configurar un puerto que puedan utilizar otras aplicaciones en el servidor MS SQL. Como referencia, puede utilizar http://www.ise.edu/in-notes/iana/assignments/port-numbers (dirección tomada de los Libros en pantalla de SQL Server).
• Cuando utilice varias instancias del servicio MS SQL Server, asegúrese de leer la documentación de MS SQL para la configuración (sección "Configuración de conexiones de red").

En segundo lugar, en la configuración del protocolo TCP/IP en el servidor MS SQL, puede configurar el indicador "Ocultar servidor", que prohíbe las respuestas a solicitudes de transmisión para esta instancia del servicio MS SQL Server.

Cifrado de datos de MS SQL almacenados en el disco

Existe una selección bastante grande de software y hardware para cifrar datos ubicados en un disco local (esto incluye la capacidad estándar de Windows para usar EFS, el uso de claves eToken y programas de terceros como Jetico Bestcrypt o PGPDisk). Una de las principales tareas que realizan estas herramientas es proteger los datos en caso de pérdida de medios (por ejemplo, si le roban un servidor). Vale la pena señalar especialmente que Microsoft no recomienda almacenar bases de datos MS SQL en medios cifrados, y esto está bastante justificado. El principal problema en este caso es una caída significativa de la productividad y Posibles problemas confiabilidad ante fallas. El segundo factor que complica la vida del administrador del sistema es la necesidad de garantizar la disponibilidad de todos los archivos de la base de datos en el momento en que el servicio MS SQL accede a ellos por primera vez (es decir, es deseable que se excluyan las acciones interactivas al conectar un medio cifrado).

Para evitar una caída notable en el rendimiento del sistema, puede utilizar la capacidad de MS SQL para crear bases de datos en varios archivos. Por supuesto, en este caso, la base de datos MS SQL no debe ser creada por el servidor 1C al crear la base de datos, sino que debe crearse por separado. A continuación se proporciona un ejemplo de un script TSQL con comentarios:

USE maestro
IR
- Crear una base de datos SomeData,
CREAR BASE DE DATOS Algunos datos
-- cuyos datos se encuentran íntegramente en el grupo de archivos PRIMARIO.
EN PRIMARIA
-- El archivo de datos principal se encuentra en un medio cifrado (unidad lógica E:)
-- y tiene un tamaño inicial de 100 MB, se puede aumentar automáticamente a 200 MB con
-- en incrementos de 20 MB
(NOMBRE = AlgunosDatos1,
NOMBRE DE ARCHIVO = "E:\SomeData1.mdf",
TAMAÑO = 100 MB,
TAMAÑO MÁXIMO = 200,
CRECIMIENTO DE ARCHIVOS = 2),
-- El segundo archivo de datos se encuentra en un medio no cifrado (unidad lógica C:)
-- y tiene un tamaño inicial de 100 MB, se puede aumentar automáticamente hasta el límite
-- espacio en disco en incrementos del 5% del tamaño del archivo actual (redondeado a 64 KB)
(NOMBRE = AlgunosDatos2,
NOMBRE DE ARCHIVO = "c:\archivos de programa\microsoft sql server\mssql\data\SomeData2.ndf",
TAMAÑO = 100 MB,
TAMAÑO MÁXIMO = ILIMITADO,
CRECIMIENTO DE ARCHIVOS = 5%)
ACCEDER
-- Aunque el registro de transacciones también podría dividirse en partes, esto no debería hacerse,
-- porque este archivo cambia con mucha más frecuencia y se limpia periódicamente (por ejemplo, cuando
-- crear una copia de seguridad de la base de datos).
(NOMBRE = Algunos registros de datos,
NOMBRE DE ARCHIVO = "c:\archivos de programa\microsoft sql server\mssql\data\SomeData.ldf",
TAMAÑO = 10 MB,
TAMAÑO MÁXIMO = ILIMITADO,
CRECIMIENTO DE ARCHIVOS = 10)
IR
-- Es mejor ceder inmediatamente la propiedad de la base de datos al usuario en cuyo nombre
-- 1C se conectará. Para hacer esto, necesitamos declarar la base actual.
- Acaba de crear,
USAR algunos datos
IR
-- y ejecuta sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Una breve digresión sobre el crecimiento automático del tamaño del archivo de datos. De forma predeterminada, los tamaños de archivo para las nuevas bases de datos aumentan en incrementos del 10% del tamaño del archivo actual. Esta es una solución completamente aceptable para bases de datos pequeñas, pero no muy buena para bases de datos grandes: con un tamaño de base de datos de, por ejemplo, 20 GB, el archivo debería aumentar inmediatamente en 2 GB. Aunque este evento ocurrirá con bastante poca frecuencia, puede durar varias decenas de segundos (todas las demás transacciones están efectivamente inactivas durante este tiempo), lo que, si ocurre durante el trabajo activo con la base de datos, puede causar algunas fallas. La segunda consecuencia negativa del incremento proporcional, que ocurre cuando el espacio en disco está casi completamente lleno, es la probabilidad de fallas prematuras debido a espacio libre insuficiente. Por ejemplo, si una partición de disco con una capacidad de 40 GB está completamente dedicada a una base de datos (más precisamente, a un archivo de esta base de datos), entonces el tamaño crítico del archivo de la base de datos en el que es necesario urgentemente (muy urgentemente, hasta el punto de interrumpir el trabajo normal de los usuarios) para reorganizar el almacenamiento de información es un archivo de datos de tamaño 35 GB. Con el tamaño de incremento establecido en 10-20 MB, puede continuar trabajando hasta llegar a 39 GB.

Por lo tanto, aunque la lista anterior especifica un aumento en el tamaño de uno de los archivos de la base de datos en incrementos del 5%, para bases de datos de gran tamaño es mejor establecer un incremento fijo de 10 a 20 MB. Al configurar los valores de incremento para el crecimiento del tamaño de los archivos de la base de datos, es necesario tener en cuenta que hasta que uno de los archivos de un grupo de archivos alcance su tamaño máximo, se aplica la regla: los archivos de un grupo de archivos aumentan todos al mismo tiempo. momento en que estén todos completamente llenos. Entonces, en el ejemplo anterior, cuando el archivo SomeData1.mdf alcance su tamaño máximo de 200 MB, el archivo SomeData2.ndf tendrá un tamaño de aproximadamente 1,1 GB.

Después de crear dicha base de datos, incluso si un atacante puede acceder a sus archivos desprotegidos SomeData2.ndf y SomeData.ldf, será extremadamente difícil restaurar el verdadero estado de la base de datos: los datos (incluida la información sobre la estructura lógica de la base de datos). ) se distribuirá en varios archivos y la información clave (sobre, por ejemplo, qué archivos componen esta base de datos) estará en el archivo cifrado.

Por supuesto, si se utilizan medios criptográficos para almacenar archivos de bases de datos, entonces la copia de seguridad (al menos de estos archivos) no debe realizarse en medios no cifrados. Para realizar una copia de seguridad de archivos de bases de datos individuales, utilice la sintaxis del comando BACKUP DATABASE adecuada. Tenga en cuenta que, aunque es posible proteger una copia de seguridad de la base de datos con una contraseña (las opciones "PASSWORD = " y "MEDIAPASSWORD = " del comando "BACKUP DATABASE"), dicha copia de seguridad no se cifra.

Cifrado de datos del servidor de aplicaciones y del cliente almacenados en discos.

En la mayoría de los casos, no se puede considerar justificado almacenar archivos utilizados por 1C:Enterprise (parte del cliente y servidor de aplicaciones) en medios cifrados debido a costos irrazonablemente altos; sin embargo, si existe tal necesidad, tenga en cuenta que el servidor de aplicaciones y la parte del cliente de la aplicación muy a menudo crean archivos temporales. A menudo, estos archivos pueden permanecer después de que la aplicación haya terminado de ejecutarse y es casi imposible garantizar su eliminación con las herramientas 1C. Por lo tanto, es necesario cifrar el directorio utilizado para los archivos temporales en 1C o no almacenarlo en el disco usando una unidad RAM (esta última opción no siempre es posible debido al tamaño de los archivos generados y los requisitos de RAM de 1C:Enterprise aplicación en sí).

Cifrado de datos mediante herramientas 1C integradas.

Las capacidades estándar para usar cifrado en 1C se reducen al uso de objetos para trabajar con archivos Zip con parámetros de cifrado. Están disponibles los siguientes modos de cifrado: algoritmo AES con una clave de 128, 192 o 256 bits y un algoritmo obsoleto utilizado originalmente en el archivador Zip. Muchos archivadores (WinRAR, 7zip) no pueden leer los archivos zip cifrados con AES. Para generar un archivo que contenga datos cifrados, debe especificar una contraseña y un algoritmo de cifrado. A continuación se ofrece el ejemplo más sencillo de funciones de cifrado y descifrado basadas en esta característica:

Función EncryptData(Datos, Contraseña, Método de cifrado = Indefinido) Exportar

// Escribe los datos en un archivo temporal. De hecho, no todos los datos se pueden guardar de esta forma.
ValueInFile(NombreDeArchivoTemporal, Datos);

// Escribe datos temporales en el archivo.
Zip = Nuevo ZipFileRecord(TemporaryArchiveFileName, Contraseña, EncryptionMethod);
Zip.Add(NombreDeArchivoTemporal);
Zip.Write();

// Leer datos del archivo recibido en RAM
EncryptedData = NewValueStorage(NewBinaryData(ArchiveTemporaryFileName));

// Archivos temporales - eliminar

Función EndFunctions DecryptData(EncryptedData, Contraseña) Exportar

// ¡Atención! No se controla la exactitud de los parámetros pasados.

// Escribe el valor pasado en un archivo
ArchiveTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);

// Extrae el primer archivo del archivo recién escrito
NombreDeArchivoTemporal = ObtenerNombreDeArchivoTemporal();
Zip = Nuevo ReadZipFile(TemporaryArchiveFileName, Contraseña);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Lee el archivo escrito
Datos = ValueFromFile(TemporaryFileName + "\" + Zip.Items.Name);

//Eliminar archivos temporales
Eliminar archivos (nombre de archivo temporal);
Eliminar archivos (nombre de archivo temporal de archivo);

Datos de devolución;

Función final

Por supuesto, este método no se puede llamar ideal: los datos se escriben en una carpeta temporal en texto claro, el rendimiento del método, francamente, es peor que nunca, el almacenamiento en la base de datos requiere una cantidad extremadamente grande de espacio, pero esto es el único método que se basa únicamente en los mecanismos integrados de la plataforma. Además, tiene una ventaja sobre muchos otros métodos: este método empaqueta datos junto con el cifrado simultáneamente. Si desea implementar el cifrado sin las desventajas que tiene este método, debe implementarlos en un componente externo o recurrir a bibliotecas existentes mediante la creación de objetos COM, por ejemplo, utilizando Microsoft CryptoAPI. Como ejemplo, daremos las funciones de cifrar/descifrar una cadena según la contraseña recibida.

Función EncryptStringDES(UnencryptedString, Contraseña)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Esta constante es de CryptoAPI

EncryptionMechanism.Content = UnencryptedString;
Motor de cifrado.Algoritmo.Nombre = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

devolver cadena cifrada;

Función final // EncryptStringDES()

Función DecryptStringDES(EncryptedString, Contraseña)

//¡Atención! ¡Los parámetros no están comprobados!

Motor de cifrado = Nuevo COMObject("CAPICOM.EncryptedData");
Mecanismo de cifrado.SetSecret(Contraseña);
Intentar
EncryptionMechanism.Decrypt(EncryptedString);
Excepción
// ¡Contraseña incorrecta!;
Devolver indefinido;
intento final;

ReturnEncryptionMechanism.Contenido;

Función final // DecryptStringDES()

Tenga en cuenta que al transferir valor vacío ingresar una cadena o contraseña en estas funciones generará un mensaje de error. La cadena obtenida mediante este procedimiento de cifrado es ligeramente más larga que la original. La especificidad de este cifrado es que si cifra una cadena dos veces, las cadenas resultantes NO serán idénticas.

Errores básicos al utilizar herramientas criptográficas.

Cuando se utilizan herramientas criptográficas, se suelen cometer los mismos errores:

Subestimar la penalización de rendimiento al utilizar criptografía.

La criptografía es una tarea que requiere una cantidad bastante grande de cálculos (especialmente para algoritmos como DES, 3DES, GOST, PGP). E incluso cuando se utilizan algoritmos optimizados y de alto rendimiento (RC5, RC6, AES), no se puede escapar de la transferencia innecesaria de datos en la memoria y el procesamiento computacional. Y esto casi anula las capacidades de muchos componentes del servidor (matrices RAID, adaptadores de red). Cuando se utiliza cifrado por hardware o derivación por hardware de la clave de cifrado, existe un posible cuello de botella adicional en el rendimiento: la velocidad de transferencia de datos entre el dispositivo adicional y la memoria (donde el rendimiento de dicho dispositivo puede no ser crítico). Cuando se utiliza el cifrado de pequeñas cantidades de datos (por ejemplo, un mensaje de correo electrónico), el aumento en la carga informática en el sistema no es tan notable, pero en el caso del cifrado total de todo, esto puede afectar en gran medida el rendimiento del sistema. como un todo.

Subestimación de las capacidades modernas para seleccionar contraseñas y claves.

Por el momento, las capacidades de la tecnología son tales que una organización pequeña puede seleccionar una clave con una longitud de 40 a 48 bits y una organización grande, una clave con una longitud de 56 a 64 bits. Aquellos. Se deben utilizar algoritmos que utilicen una clave de al menos 96 o 128 bits. Pero la mayoría de las claves se generan mediante algoritmos hash (SHA-1, etc.) basados ​​en las contraseñas ingresadas por el usuario. En este caso, es posible que una clave con una longitud de 1024 bits no ayude. En primer lugar, se suele utilizar una contraseña fácil de adivinar. Los factores que facilitan la selección son: utilizar un solo caso de letras; uso de palabras, nombres y expresiones en contraseñas; uso de fechas conocidas, cumpleaños, etc.; utilizar "patrones" al generar contraseñas (por ejemplo, 3 letras, luego 2 números y luego 3 letras en toda la organización). Una buena contraseña debe ser una secuencia bastante aleatoria de letras mayúsculas, números y signos de puntuación. Las contraseñas ingresadas desde el teclado de hasta 7 a 8 caracteres, incluso si se siguen estas reglas, se pueden adivinar en un tiempo razonable, por lo que es mejor que la contraseña tenga al menos 11 a 13 caracteres. La solución ideal es evitar generar una clave mediante una contraseña, por ejemplo, utilizando varias tarjetas inteligentes, etc., pero en este caso es necesario prever la posibilidad de protección contra la pérdida del medio de la clave de cifrado.

Almacenamiento inseguro de claves y contraseñas.

Ejemplos comunes de este error son:

• Contraseñas largas y complejas escritas en notas adhesivas pegadas al monitor del usuario.
• almacenar todas las contraseñas en un archivo que no está protegido (o que está protegido mucho más débilmente que el propio sistema)
• Almacenamiento de claves electrónicas en el dominio público.
• Transferencia frecuente de claves electrónicas entre usuarios.

¿Por qué hacer una puerta blindada si la llave está debajo del felpudo?

Transferencia de datos inicialmente cifrados a un entorno inseguro.

Al configurar un sistema de seguridad, asegúrese de que haga su trabajo. Por ejemplo, me encontré con una situación (no relacionada con 1C) en la que un archivo inicialmente cifrado, cuando el programa se ejecutaba en forma clara, se colocaba en una carpeta temporal, desde donde se podía leer de forma segura. A menudo, las copias de seguridad de datos cifrados en forma clara se encuentran en algún lugar "no lejos" de estos datos.

Uso de herramientas criptográficas para otros fines.

Al cifrar datos en tránsito, no se puede esperar que sean inaccesibles donde se utilizan. Por ejemplo, los servicios IPSec no impiden de ninguna manera que el servidor de aplicaciones "husmee" el tráfico de red a nivel de aplicación.

Por lo tanto, para evitar errores al implementar sistemas criptográficos, debe (como mínimo) hacer lo siguiente antes de implementarlos.

• Descubrir:
  • ¿Qué hay que proteger?
  • ¿Qué método de protección debería utilizar?
  • ¿Qué partes del sistema deben protegerse?
  • ¿Quién controlará el acceso?
  • ¿Funcionará el cifrado en todas las áreas correctas?
• Determine dónde se almacena la información, cómo se enviará a través de la red y las computadoras desde donde se accederá a la información. Esto proporcionará información sobre la velocidad, la capacidad y el uso de la red antes de implementar el sistema, lo cual es útil para optimizar el rendimiento.
• Evaluar la vulnerabilidad del sistema a varios tipos de ataques.
• Desarrollar y documentar un plan de seguridad del sistema.
• Evaluar la eficiencia económica (justificación) del uso del sistema.

Conclusión

Por supuesto, en una revisión rápida es imposible indicar todos los aspectos relacionados con la seguridad en 1C, pero permitámonos sacar algunas conclusiones preliminares. Por supuesto, esta plataforma no puede considerarse ideal; como muchas otras, tiene sus propios problemas a la hora de organizar un sistema seguro. Pero esto no significa en modo alguno que estos problemas no puedan evitarse; al contrario, casi todas las deficiencias pueden eliminarse con un desarrollo, implementación y uso adecuados del sistema. La mayoría de los problemas surgen debido al desarrollo insuficiente de una solución de aplicación específica y su entorno de ejecución. Por ejemplo, las soluciones estándar sin cambios significativos simplemente no implican la creación de un sistema suficientemente seguro.

Este artículo demuestra una vez más que cualquier conjunto de medidas de seguridad debe cubrir todas las etapas de implementación: desarrollo, implementación, administración del sistema y, por supuesto, medidas organizativas. En los sistemas de información, el “factor humano” (incluidos los usuarios) constituye la principal amenaza a la seguridad. Este conjunto de medidas debe ser razonable y equilibrado: no tiene sentido y es poco probable que se asignen fondos suficientes para organizar una protección que supere el coste de los propios datos.

Compañía es un servicio único para compradores, desarrolladores, distribuidores y socios afiliados. Además, esta es una de las mejores tiendas de software en línea en Rusia, Ucrania y Kazajstán, que ofrece a los clientes una amplia gama de productos, muchos métodos de pago, procesamiento de pedidos rápido (a menudo instantáneo) y seguimiento del proceso de pedido en una sección personal. .