Débordement de pile de langage intégré 1c. Débordement de pile

14/04/2016 Version 3.22 L'interface a été modifiée, les erreurs lors du transfert des registres ont été corrigées, la procédure de transfert d'une organisation et les politiques comptables ont été modifiées. Plateforme 8.3.7.2027 BP 3.0.43.174
17/03/2016 Version 3.24 Les erreurs constatées ont été corrigées. Plateforme 8.3.8.1747 BP 3.0.43.241
16/06/2016 Version 3.26 Les erreurs constatées ont été corrigées. Plateforme 8.3.8.2088 BP 3.0.44.123
16/10/2016 Version 4.0.1.2 Transfert fixe du stockage de valeur, transfert modifié de la politique comptable pour les versions 3.44.*. Plate-forme 8.3.9.1818 BP 3.0.44.164.
19/04/2017 Version 4.0.2.7 L'algorithme de transfert des registres associés aux répertoires a été modifié, les erreurs constatées ont été corrigées, le transfert avec écrasement des liens a été corrigé.
29/05/2017 Version 4.0.4.5 Modification du transfert des mouvements, ajout de la visualisation des mouvements des documents transférés, autre chose...
30/05/2017 Version 4.0.4.6 Correction d'une erreur lors du remplissage de la liste des répertoires existants dans la source (merci shoy)
17/06/2017 Version 4.0.5.1 L'algorithme de transfert des mouvements a été modifié.
19/07/2017 Version 4.0.5.4 Le transfert de CI depuis BP 2.0 a été modifié. De manière inattendue, le transfert depuis UT 10.3 a été effectué par Smilegm, dans cette version le transfert a été légèrement corrigé pour cette situation)))
10/08/2017 Version 4.0.5.5 Correction d'erreurs lors du transfert depuis BP 2.0
19.09.2017 Version 4.4.5.7 Vérification de connexion fixe pour 3.0.52.*
28/11/2017 Version 4.4.5.9 Correction des erreurs signalées
06/12/2017 Version 5.2.0.4 L'algorithme de recherche de liens a été repensé. Des procédures de transfert depuis BP 1.6 ont été ajoutées, il n'y a plus de connexion stricte avec le BP - vous pouvez facilement l'utiliser pour transférer des données de configurations « presque » identiques. J'essaierai de corriger tous les commentaires rapidement.
12/08/2017 Version 5.2.1.3 Ajout d'un algorithme de transfert des fiches de salaire de BP.2.0 vers BP 3.0. Modifications incluses pour le partage entre des configurations identiques.
19/12/2017 Version 5.2.2.2 Le transfert des registres d'informations indépendants pour les annuaires qui sont dans les dimensions de ces registres a été ajusté.

12/06/2017 Nouvelle version de traitement 5.2.0.4. Parmi les changements importants figure la possibilité de passer de BP 1.6 à BP 3.0. Le principal changement est la gestion de la recherche des liens d'annuaire - dans les versions précédentes la recherche se faisait par GUID, mais dans cette version vous pouvez activer la recherche "Par détails" :

17/01/2018 Version 5.2.2.3 Corrigé - erreurs remarquées dans les répertoires subordonnés et les registres d'informations périodiques.

19/07/2018 Version 5.2.2.8 Les erreurs constatées ont été corrigées.

dans lequel vous pouvez définir les détails de recherche pour n’importe quel répertoire. Ce régime lui-même a « émergé » à la suite de nombreuses demandes de travailleurs, dans les cas où un échange est nécessaire dans une base de données déjà existante contenant déjà des données (par exemple, pour fusionner les registres comptables de deux organisations en une seule base de données).

21/12/2015 La plate-forme 8.3.7.1805 et BP 3.0.43.29 ont été publiées respectivement une nouvelle version traitement 3.1 :-) (description ci-dessous). Nouvelle fonctionnalité - la possibilité de comparer les soldes et le chiffre d'affaires entre deux bases de données BP (pour tous les comptes, si les plans comptables coïncident, ou pour des comptes comptables individuels correspondants, avec ou sans analyses).
03/01/2016 Version 3.5 - le mécanisme de connexion à la base source a été modifié - mis en conformité avec BSP 2.3.2.43. Bugs mineurs corrigés. Plateforme 8.3.7.1845, BP 3.0.43.50
16/02/2016 Version 3.6 - Ajout du flag "Définir la correction manuelle" pour les documents transférés avec des mouvements. Transfert fixe de mouvements - les documents dont la date est inférieure au début de la période sont transférés sans mouvements. Plate-forme 8.3.7.1917, BP 3.0.43.116
22/03/2016 Version 3.10 - Ajout du flag "Toujours écraser les références" pour la réécriture obligatoire des objets référencés (la vitesse de transfert est considérablement réduite, mais parfois c'est nécessaire). L'onglet "Préparation" a été ajouté, où vous pouvez configurer la correspondance des plans comptables source et destination (au même niveau que les codes comptes) et le transfert des constantes. Plate-forme 8.3.7.1970, BP 3.0.43.148

03/04/2016 Version 3.11 Le remplissage de la liste des documents existant dans la source a été modifié : il était renseigné par mouvements selon le plan comptable, il se faisait simplement par liens pour la période, tout comme dans // site/public/509628/

Le traitement est destiné au transfert de données pour n'importe quelle période de la même manière que le « Téléchargement MXL » avec ITS, uniquement sans utiliser XML, JSON et autres fichiers intermédiaires - échange de base de données en base de données via COM. Dans les versions antérieures à 3.10, une connexion est utilisée à l'aide d'un algorithme du BSP, qui prévoit l'enregistrement de comcntr.dll (si l'OS « le permet »), ainsi que divers messages lorsqu'il est impossible d'établir une connexion, par exemple exemple - "La base d'informations est en cours de mise à jour", etc. Ajout d'un contrôle pour sélectionner un récepteur comme source IS - un avertissement est émis.

Peut être utilisé pour :

1. Transfert des informations réglementaires de référence (RNI) de la source du SI vers la destination du SI (le transfert de toutes les informations de référence s'effectue à la demande de l'utilisateur, les ouvrages de référence nécessaires, etc. sont transférés via des liens lors d'éventuels transferts).

2. Transfert de documents pour toute période sélectionnée.

3. Transfert de toutes les informations d'un système de sécurité de l'information « en panne » s'il est lancé en mode 1C : Entreprise et que le téléchargement de données ou le lancement du configurateur est impossible.

Caractéristique du traitement - la sécurité des informations du destinataire et de la source peut être différente ; transfert de 2.0 à 3.0 - les éditions sont différentes, mais le transfert fonctionne !!! Les détails incompatibles sont ignorés ou des algorithmes de transfert doivent être spécifiés pour eux.

Commentaire: La conversion des données n'est PAS UTILISÉE ! Et ne demandez pas pourquoi !!! Pour ceux qui sont particulièrement pointilleux - BP 3.0 change presque tous les jours, il n'y a plus de force pour maintenir les règles de transfert à jour - tout est plus simple ici :-).

Une autre caractéristique du traitement est qu'il est lancé dans la sécurité des informations du récepteur (les analogues les plus proches en fonctionnalité fonctionnent dans l'autre sens - de la source au récepteur).

Mise en route - vous devez spécifier la période de traitement, spécifier l'organisation depuis la source, elle sera transférée vers la destination.

Lors du transfert d'une organisation, les politiques comptables et les registres d'informations « associés » sont transférés. Par conséquent, lorsque vous sélectionnez pour la première fois une organisation dans la source, un certain temps s'écoulera avant qu'elle n'apparaisse dans le récepteur.

Les plans comptables de la source et de la destination doivent être les mêmes, aucun compte différent dans les versions 2.* n'est transféré vers la destination, il est prévu de permettre l'ajustement des comptes correspondants et des analyses à l'avenir. Les comptes sont transférés à l'aide de codes qui ne sont pas trouvés dans le récepteur. NE PEUT PAS ÊTRE CRÉÉ !!!

Les objets restants sont transférés à l'aide d'identifiants internes (GUID), vous devez donc faire attention à certains répertoires clés, par exemple - Devises.

Si vous envisagez d'échanger avec une base de données « propre », alors mieux vaut supprimer les répertoires renseignés lors du premier lancement avant l'échange. Pourquoi y a-t-il une page dans le traitement où vous pouvez obtenir ces éléments de répertoire et les supprimer. Au minimum, vous devez supprimer la devise « frotter ». - parce que la duplication est presque inévitable (en principe, elle est facilement corrigée après avoir partagé la recherche et le remplacement des doublons intégrés à BP 3.0).

Le traitement prévoit d'appeler la page de suppression d'annuaire lorsque le formulaire de remplissage initial est ouvert :

A l'ouverture du traitement, une page de suppression des répertoires renseignés lors du premier remplissage s'affichera :

Depuis la version 3.22, l'interface a été modifiée, désormais toutes les opérations préparatoires sont par onglets et toujours disponibles

Il est important de vérifier la correspondance du plan comptable de la source et du destinataire et de veiller à indiquer la correspondance des comptes.

Il n'est pas nécessaire de supprimer les éléments de répertoire prédéfinis : ils sont transférés par des identifiants de configuration (et non par des GUID).

Vous pouvez sélectionner des objets à transférer à l'aide du formulaire de sélection à partir de répertoires et de documents (les registres d'informations associés à ces objets seront transférés automatiquement, il n'est donc pas nécessaire de les sélectionner séparément).Transfert de registres, la réduction est temporairement désactivée - vous devez élaborer une liste de registres à transférer - quelque chose doit être transféré, quelque chose ne doit pas, à ce stade il suffit de ce qui est transféré dans les annuaires, la liste des registres à transférer sera dans le modèle dans les versions futures.

Lors d'un échange avec la version 2.0, certains détails (par exemple, Coordonnées) est transféré selon l'algorithme intégré au traitement, car pour les versions 2.0 et 3.0, ils sont stockés différemment. La situation est similaire avec un certain nombre de documents (par exemple, l'ajustement de la dette).

La liste des types d'objets peut être renseignée différemment dans la version 3.22, celle-ci est placée dans un sous-menu, les modifications sont indiquées dans l'image :

Il existe une simplification de l'utilisation du traitement - vous ne pouvez pas sélectionner de répertoires à échanger, mais simplement remplir la liste des types dans le récepteur avec uniquement les types de répertoires qui ont au moins une entrée dans la source.

Le traitement possède une présentation intégrée qui répertorie les répertoires qui n'ont pas besoin d'être transférés de la source vers la destination (la présentation « Exclure du transfert »). Vous pouvez ajouter (supprimer) n'importe quel répertoire à cette mise en page. Si vous n'avez pas besoin de transférer toutes les données de référence, il suffit de transférer les documents dont la liste peut également être obtenue sans sélection de types, il suffit de compléter avec tous les documents sources pour lesquels des transactions existent.

Le transfert des documents avec mouvements est prévu ; pour les échanges 3.0 à 3.0 et la correspondance des plans comptables, cela fonctionne un à un ; lors de l'échange 2.0 à 3.0, des erreurs sont possibles, il est donc recommandé de transférer les documents sans mouvements, puis transférez-les simplement au récepteur. Lors du transfert de documents avec mouvements, le drapeau « Ajustement manuel » est activé.

L'attribut « Comptabilisé » est paramétré dans les pièces destinataires de la même manière que dans la source, mais les mouvements (s'ils n'ont pas été transférés) n'apparaîtront qu'après traitement des pièces, par exemple grâce au traitement intégré à BP 3.0. documents (option recommandée), ou de ce traitement (il y a un bouton « Publier des documents » ici).

Si le traitement est destiné à être utilisé à des fins d’échange permanent, il peut être enregistré dans la sécurité des informations du destinataire (bouton « S’inscrire »). Pour les transferts « ponctuels », vous pouvez simplement l'utiliser via Fichier - Ouvrir.

21/12/2015 - Version 3.1 plateforme 8.3.7.1805 et bloc d'alimentation 3.0.43.29 (la version 2.15 pour 3.0.43.* ne fonctionne pas - la configuration a été beaucoup modifiée).

Modifié:

Boîte de dialogue de sélection d'une option de connexion, l'indicateur Client-serveur est toujours disponible, selon son paramétrage, soit le choix d'un dossier de base de données de fichiers, soit un champ avec le nom de la base de données sur le serveur et le nom du serveur lui-même est disponible (un bug dans la boîte de dialogue version 2.15 a été corrigé)

- NOUVELLE FONCTIONNALITÉ : Un mécanisme de rapprochement des soldes et du chiffre d'affaires entre les bases de données source et réceptrice à différents degrés de détail :

Je pense que le choix des options de vérification ressort clairement de la figure :

Il existe des différences d'utilisation entre les clients légers et les clients lourds - dans le client lourd, une fenêtre de comparaison de fichiers s'affiche immédiatement :

Dans le client léger, je ne me suis pas soucié d'appuyer sur les boutons par programmation, je suggère une option simple pour afficher une fenêtre de comparaison :

La comparaison dans un client léger, à mon humble avis, est plus pratique, car... dispose de boutons de navigation pour les différences, ce qui est plus pratique pour les grands tableaux que de faire défiler avec la souris :

22/03/2016 Version 3.10 - Ajout du flag "Toujours écraser les références" pour la réécriture obligatoire des objets référencés (la vitesse de transfert est considérablement réduite, mais parfois c'est nécessaire). L'onglet "Préparation" a été ajouté, où vous pouvez configurer la correspondance des plans comptables source et destination (au même niveau que les codes comptes) et le transfert des constantes. Plate-forme 8.3.7.1970, BP 3.0.43.148

- NOUVELLE FONCTIONNALITÉ : Avant de transférer des documents, il est recommandé de vérifier le plan comptable pour la cohérence de l'origine et de la destination, ainsi que le respect des constantes établies.

A cet effet, un onglet « Préparation » a été ajouté dans lequel vous pouvez paramétrer ces correspondances :

L'algorithme de remplissage du tableau de correspondance des comptes est simple - le chiffre d'affaires existant dans la source est analysé, et pour chaque compte qui y est trouvé, une correspondance est trouvée dans le récepteur par code ; si une correspondance n'est pas trouvée, une ligne avec le compte le code est affiché dans le tableau, par lequel vous devez sélectionner le compte du destinataire, il sera utilisé lors du transfert. La conformité Poke est établie au niveau du code.

Pour vérifier et transférer la correspondance des constantes établies, le tableau correspondant est utilisé :

Nous le remplissons et le transférons si nécessaire. Seules les constantes marquées du drapeau sont transférées...

La pile de programmes est une zone mémoire spéciale organisée selon le principe de file d'attente LIFO (Last in, first out). Le nom "pile" vient de l'analogie du principe de sa construction avec une pile de plaques - on peut superposer des plaques les unes sur les autres (méthode d'ajout à la pile, "push", "push"), puis retirez-les en commençant par le haut (méthode pour obtenir une valeur de la pile, "popping", "pop"). La pile de programmes est également appelée pile d'appels, pile d'exécution ou pile machine (afin de ne pas la confondre avec la « pile » - une structure de données abstraite).

A quoi sert une pile ? Il vous permet d'organiser facilement l'appel des sous-programmes. Lorsqu'elle est appelée, la fonction reçoit des arguments ; il doit également stocker ses variables locales quelque part. De plus, il faut tenir compte du fait qu'une fonction peut appeler une autre fonction, qui doit également transmettre des paramètres et stocker ses variables. En utilisant la pile, lorsque vous passez des paramètres, il vous suffit de les mettre sur la pile, puis la fonction appelée peut les « extraire » de là et les utiliser. Des variables locales peuvent également y être stockées - au début de son code, la fonction alloue une partie de la mémoire de la pile, et lorsque le contrôle revient, elle l'efface et la libère. Les programmeurs de langages de haut niveau ne pensent généralement pas à de telles choses - le compilateur génère pour eux tout le code de routine nécessaire.

Conséquences d'une erreur

Nous sommes maintenant presque proches du problème. Dans l’abstrait, une pile est un magasin infini dans lequel de nouveaux éléments peuvent être ajoutés à l’infini. Malheureusement, dans notre monde, tout est fini – et la mémoire de pile ne fait pas exception. Que se passe-t-il si cela se termine lorsque les arguments de la fonction sont placés sur la pile ? Ou la fonction alloue-t-elle de la mémoire pour ses variables ?

Une erreur appelée débordement de pile se produira. Puisque la pile est nécessaire pour organiser l'appel de fonctions définies par l'utilisateur (et presque tous les programmes des langages modernes, y compris ceux orientés objet, sont construits sur la base de fonctions d'une manière ou d'une autre), ils ne pourront plus être appelé. Par conséquent, le système d'exploitation prend le contrôle, efface la pile et termine le programme. Ici, nous pouvons souligner la différence entre le débordement de pile et le débordement de pile - dans le premier cas, une erreur se produit lors de l'accès à une zone mémoire incorrecte, et s'il n'y a pas de protection à ce stade, elle ne se manifeste pas à ce moment-là - avec un succès combinaison de circonstances, le programme peut fonctionner normalement. Si seule la mémoire consultée était protégée, . Dans le cas d'une pile, le programme se termine certainement.

Pour être tout à fait précis, il convient de noter qu'une telle description des événements n'est vraie que pour les compilateurs qui compilent en code natif. Dans les langages gérés, la machine virtuelle possède sa propre pile pour les programmes gérés, dont l'état est beaucoup plus facile à surveiller, et vous pouvez même vous permettre de lever une exception au programme en cas de débordement. Dans les langages C et C++, on ne peut pas compter sur un tel « luxe ».

Raisons de l'erreur

Qu’est-ce qui a pu conduire à une situation aussi désagréable ? Sur la base du mécanisme décrit ci-dessus, il est possible qu'il y ait trop d'appels de fonctions imbriquées. Ce scénario est particulièrement probable lors de l'utilisation de la récursivité. La récursivité infinie (en l'absence d'un mécanisme d'évaluation paresseux) est ainsi interrompue, contrairement à , qui a parfois des applications utiles. Cependant, avec une petite quantité de mémoire allouée à la pile (ce qui est par exemple typique des microcontrôleurs), une simple séquence d'appels peut suffire.

Une autre option consiste à utiliser des variables locales, qui nécessitent beaucoup de mémoire. Avoir un tableau local d'un million d'éléments, ou d'un million de variables locales (on ne sait jamais ce qui se passe) n'est pas la meilleure idée. Même un seul appel à une fonction aussi gourmande peut facilement provoquer un débordement de pile. Pour obtenir de grandes quantités de données, il est préférable d'utiliser des mécanismes de mémoire dynamique, qui permettront de gérer l'erreur de son manque.

Cependant, la mémoire dynamique est assez lente en termes d'allocation et de désallocation (puisque le système d'exploitation gère cela), et avec un accès direct, vous devez l'allouer et la désallouer manuellement. La mémoire sur la pile est allouée très rapidement (en fait, il suffit de changer la valeur d'un registre) ; de plus, les objets alloués sur la pile ont des destructeurs automatiquement appelés lorsque le contrôle de la fonction revient et que la pile est effacée. Bien sûr, le désir d'extraire de la mémoire de la pile surgit immédiatement. Par conséquent, la troisième façon de déborder est l'allocation de mémoire par le programmeur sur la pile. La bibliothèque C fournit la fonction alloca spécifiquement à cet effet. Il est intéressant de noter que si la fonction d'allocation de mémoire dynamique malloc a son propre « jumeau » pour la libérer, free, alors la fonction alloca ne l'a pas - la mémoire est libérée automatiquement après le retour du contrôle de la fonction. Peut-être que cela ne fait que compliquer la situation - après tout, il ne sera pas possible de libérer de la mémoire avant de quitter la fonction. Même si, selon la page de manuel, "la fonction alloca dépend de la machine et du compilateur ; sur de nombreux systèmes, sa mise en œuvre est problématique et boguée ; son utilisation est très frivole et mal vue" - elle est toujours utilisée.

Exemples

A titre d'exemple, regardons le code de recherche récursive de fichiers situé sur MSDN :

Void DirSearch(String* sDir) ( try ( // Rechercher les sous-dossiers dans le dossier transmis. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0;je< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Texte); int numFiles = f->get_Length(); pour (int j=0; j< numFiles; j++) { listBox1->Articles->Ajouter(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox::Show(e->Message); ) )

Cette fonction obtient une liste de fichiers dans le répertoire spécifié, puis s'appelle pour les éléments de la liste qui se trouvent être des répertoires. En conséquence, avec un arbre suffisamment profond système de fichiers, on obtient un résultat naturel.

Un exemple de la deuxième approche, tiré de la question « Pourquoi un débordement de pile se produit-il ? » à partir d'un site appelé Stack Overflow (le site est une collection de questions et réponses sur n'importe quel sujet de programmation, et pas seulement Stack Overflow, comme cela peut paraître) :

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

Comme vous pouvez le constater, la fonction main alloue de la mémoire sur la pile aux tableaux de types int et float, chacun comportant un million d'éléments, ce qui donne au total un peu moins de 8 mégaoctets. Si l’on considère que par défaut Visual C++ ne réserve que 1 mégaoctet pour la pile, alors la réponse devient évidente.

Et voici un exemple tiré du dépôt GitHub du projet Lightspark Flash player :

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

Vous pouvez espérer que h.getLength()-7 ne soit pas un nombre trop grand afin qu'il n'y ait pas de débordement sur la ligne suivante. Mais le temps gagné sur l’allocation mémoire vaut-il le crash « potentiel » du programme ?

Conclusion

Le débordement de pile est une erreur fatale qui affecte le plus souvent les programmes contenant des fonctions récursives. Cependant, même si le programme ne contient pas de telles fonctions, un débordement reste possible en raison de la grande taille des variables locales ou d'une erreur d'allocation manuelle de mémoire sur la pile. Toutes les règles classiques restent en vigueur : s'il y a le choix, il vaut mieux choisir l'itération plutôt que la récursivité, et aussi ne pas faire de travail manuel à la place du compilateur.

Bibliographie

• E. Tanenbaum. L'architecture des ordinateurs.
• Wikipédia. Débordement de pile.
• Débordement de pile. Débordement de pile C++.

La pile, dans ce contexte, est la dernière du premier tampon que vous allouez lors de l'exécution de votre programme. Last, First (LIFO) signifie que la dernière chose que vous insérez est toujours la première chose que vous récupérez - si vous placez 2 éléments sur la pile, "A" puis "B", alors la première chose que vous retirez de la pile sera "B" et la chose suivante sera "A".

Lorsque vous appelez une fonction dans votre code, la commande suivante après l'appel de fonction est stockée sur la pile et sur tout espace mémoire pouvant être écrasé par l'appel de fonction. La fonction choisie peut utiliser plus de pile pour ses propres variables locales. Une fois cela fait, il libérera l'espace variable local qu'il utilisait, puis reviendra à la fonction précédente.

Débordement de pile

Un débordement de pile se produit lorsque vous avez utilisé plus de mémoire sur la pile que ce que votre programme avait prévu d'utiliser. Sur les systèmes embarqués, vous ne pouvez avoir que 256 octets pour la pile, et si chaque fonction prend 32 octets, alors vous ne pouvez avoir que 8 appels de fonction à la fonction 2 avec la fonction profonde 1, qui appelle la fonction 3, qui appelle la fonction 4. ...qui appelle la fonction 8, qui appelle la fonction 9, mais la fonction 9 écrase la mémoire en dehors de la pile. Cela peut écraser la mémoire, le code, etc.

De nombreux programmeurs font cette erreur en appelant la fonction A, qui appelle ensuite la fonction B, qui appelle ensuite la fonction C, qui appelle ensuite la fonction A. Cela peut fonctionner la plupart du temps, mais une seule mauvaise entrée la fera tourner pour toujours jusqu'à ce que l'ordinateur échoue découvre que la pile est pleine.

Les fonctions récursives en sont également une cause, mais si vous écrivez de manière récursive (c'est-à-dire que votre fonction s'appelle elle-même), vous devez en être conscient et utiliser des variables statiques/globales pour éviter une récursion sans fin.

En règle générale, le système d'exploitation et le langage de programmation que vous utilisez gèrent la pile, et cela n'est pas entre vos mains. Vous devriez regarder votre graphique d'appels (une structure arborescente qui montre à partir de votre point principal ce que chaque fonction appelle) pour voir la profondeur de vos appels de fonction et identifier les boucles et la récursivité qui ne sont pas prévues. Les boucles intentionnelles et la récursion doivent être artificiellement vérifiées si elles s'appellent trop souvent.

Hormis les bonnes pratiques de programmation et les tests statiques et dynamiques, vous ne pouvez pas faire grand-chose dans ces systèmes de haut niveau.

Systèmes embarqués

Dans le monde embarqué, en particulier dans le code à haute assurance (automobile, aérospatiale, aérospatiale), vous effectuez des tests et des révisions de code approfondis, mais vous effectuez également les tâches suivantes :

• Désactiver la récursivité et les boucles - conformité aux politiques et aux tests
• Gardez le code et la pile éloignés (le code en flash, empilé en RAM et ne correspondra jamais)
• Placez des barres de garde autour de la pile - une zone de mémoire vide que vous remplissez avec un nombre magique (généralement la routine d'interruption, mais il existe de nombreuses variantes ici) et des centaines ou des milliers de fois par seconde vous regardez les barres de garde pour faire sûr qu'ils n'ont pas été écrasés.
• Utilisez la protection de la mémoire (c'est-à-dire ne pas exécuter sur la pile, ne pas lire ou écrire directement derrière la pile)
• Les interruptions n'appellent pas de fonctions secondaires - elles définissent des indicateurs, copient les données et laissent l'application s'en charger (sinon vous pourriez vous retrouver 8 en profondeur dans votre arborescence d'appels de fonction, avoir une interruption, puis avoir quelques fonctions supplémentaires à l'intérieur). l'interruption de sortie, provoquant un lancer). Vous disposez de plusieurs arborescences d'appels : une pour les processus principaux et une pour chaque interruption. Si vos interruptions peuvent s'interrompre... eh bien, il y a des dragons...

Langages et systèmes de haut niveau

Mais dans les langages de haut niveau fonctionnant sur les systèmes d'exploitation :

• Réduisez le stockage des variables locales (les variables locales sont stockées sur la pile), bien que les compilateurs soient assez intelligents à ce sujet et mettent parfois de gros morceaux sur le tas si votre arbre d'appels est peu profond)
• Éviter ou limiter strictement la récursivité
• N'interrompez pas trop vos programmes dans des fonctions de plus en plus petites - même sans prendre en compte les variables locales, chaque appel de fonction consomme jusqu'à 64 octets sur la pile (processeur 32 bits, économisant la moitié des registres du processeur, des indicateurs, etc.).
• Gardez l'arbre d'appel peu profond (similaire à la description ci-dessus)

Serveurs Web

Cela dépend du bac à sable dont vous disposez si vous pouvez contrôler ou même voir la pile. Il y a de fortes chances que vous puissiez gérer des serveurs Web comme n'importe quel autre langage et système d'exploitation de haut niveau - cela est en grande partie hors de votre contrôle, mais vérifiez le langage et la pile de serveurs que vous utilisez. Par exemple, vous pouvez diviser la pile sur votre serveur SQL.

Le Guide du programmeur API Informix® DataBlade™ est disponible en téléchargement. La section « Gestion de l'espace de pile » décrit la création de fonctions définies par l'utilisateur (UDR). Cet article fournit des informations supplémentaires et des conseils de débogage.

Les informations suivantes s'appliquent si UDR s'exécute sur un processeur virtuel (VP) défini par l'utilisateur ou sur un processeur VP. La pile d'un thread peut être déplacée vers un processeur virtuel défini par l'utilisateur immédiatement avant l'exécution de l'UDR.

Quelle taille de pile est allouée pour l’UDR ?

La taille de la pile disponible pour un UDR dépend de la manière dont l'UDR a été créé :

en utilisant le modificateur STACK, qui permet à l'UDR d'utiliser sa pile spécialement allouée,

sans le modificateur STACK, ce qui signifie que UDR partagera la pile allouée par le serveur avec le thread faisant la requête. La taille de la pile dans ce cas sera déterminée par la valeur du paramètre STACKSIZE dans le fichier de configuration onconfig.

Modificateur PILE

Les instructions CREATE PROCEDURE ou CREATE FUNCTION ont un modificateur STACK facultatif qui vous permet de spécifier la quantité d'espace de pile, en octets, requise pour exécuter l'UDR.

Si vous utilisez le modificateur STACK lors de la création d'un UDR, le serveur allouera et libérera de l'espace de pile à chaque exécution de l'UDR. La taille réellement disponible est égale à la valeur STACK en octets moins une certaine surcharge en fonction du nombre d'arguments de la fonction.

Si la valeur STACK est inférieure au paramètre STACKSIZE dans le fichier onconfig (voir section suivante), alors la taille de la pile allouée pour l'UDR sera automatiquement arrondie à la valeur STACKSIZE.

Paramètre de configuration STACKSIZE

Le fichier de configuration onconfig inclut un paramètre STACKSIZE qui spécifie la taille de pile par défaut pour les threads utilisateur.

Si vous ne spécifiez pas STACK lors de la création d'un UDR, le serveur n'alloue pas d'espace de pile supplémentaire pour exécuter cet UDR. Au lieu de cela, l'UDR utilise l'espace de pile alloué pour exécuter la requête. La taille de la pile disponible dépendra de la surcharge liée à l'exécution de la fonction au niveau SQL.

La pile par thread est allouée une fois pour le thread spécifique exécutant la requête. Les performances sont meilleures lorsque l'UDR partage une pile avec un thread, car le serveur ne gaspille pas de ressources en allouant une pile supplémentaire pour chaque appel UDR. D'un autre côté, si la taille de la pile utilisée par l'UDR s'approche de la valeur STACKSIZE, cela peut provoquer un débordement de pile lors de l'appel de la fonction dans le cadre d'une requête complexe (auquel cas moins d'espace de pile sera disponible pour l'exécution de l'UDR).

Veuillez noter que vous ne devez pas définir la valeur STACKSIZE trop élevée, car cela affecterait tous les threads utilisateur.

Quand est-il nécessaire de contrôler la taille de la pile ?

YVous devez gérer l'espace de pile si l'UDR effectue des appels récursifs ou si l'UDR nécessite plus d'espace de pile que celui disponible par défaut dans la pile du thread de requête (STACKSIZE).

Il existe deux manières d'augmenter la pile pour l'exécution UDR :

Spécifiez le modificateur STACK lors de la création d'un UDR.

Utilisez mi_call() pour effectuer des appels récursifs (voir le Guide du programmeur de l'API Informix DataBlade pour un exemple).

Si vous ne spécifiez pas de taille via STACK, et si vous n'utilisez pas mi_call() pour augmenter la pile actuelle, et si l'UDR fait quelque chose qui nécessite beaucoup d'espace de pile, cela provoquera un débordement de pile.

Notez que certaines fonctions mi_* ajoutent un nouveau segment de pile pour leur propre exécution. Ces segments sont libérés lors du retour à la fonction UDR appelante.

Que faire si quelque chose ne va pas ?

Surveillance de l'utilisation de la pile

Le but de la surveillance est d'identifier l'UDR spécifique à l'origine du débordement de pile afin que vous puissiez modifier la valeur STACK spécifiquement pour cet UDR particulier.

Surveillance de l'utilisation de la pile avec la commande "onstat -g sts"

Surveillance d'une session exécutant une requête SQL à l'aide de "onstat -g ses session_id"

Après avoir identifié une requête SQL qui se termine par un débordement de pile, vous devez déterminer l'utilisation de la pile en exécutant séparément les requêtes UDR qui font partie de la requête d'origine.

Vous pouvez définir dynamiquement la valeur STACK pour UDR. Par exemple:

modifier la fonction MyFoo (lvarchar,lvarchar) avec (ajouter une pile = 131072) ;

Après avoir modifié la valeur STACK, vous devez tester la requête d'origine pour vous assurer qu'elle est désormais stable.

Augmenter la taille de la pile

Vous pouvez également essayer d'augmenter la valeur STACKSIZE. Vérifiez si cela résout le problème. (N'oubliez pas de renvoyer l'ancienne valeur plus tard).

Si l'augmentation de STACKSIZE ne résout pas le problème, le problème est probablement dû à une corruption de la mémoire. Voici quelques suggestions:

Activez le gribouillage de la mémoire et la vérification du pool de mémoire. La section « Problèmes de débogage » de l’article Allocation de mémoire pour les UDR explique comment procéder.

Reconsidérez l'utilisation de mi_lvarchar . Une attention particulière doit être accordée aux endroits où mi_lvarchar est passé à une fonction qui s'attend à recevoir une chaîne terminée par un caractère nul comme argument.

Réduisez le nombre de VP CPU (ou utilisateur) à un pour reproduire le problème plus rapidement.

mi_print_stack() -- Solaris

Informix Dynamic Server pour Solaris OS inclut une fonction mi_print_stack() qui peut être appelée dans l'UDR. Par défaut, cette fonction enregistre le cadre de pile dans le fichier suivant :

/tmp/default.stack

Vous ne pouvez pas modifier le nom du fichier de sortie, mais vous pouvez modifier son emplacement en modifiant la valeur de la variable d'environnement DBTEMP. Assurez-vous que le répertoire $DBTEMP est accessible en écriture par l'utilisateur informix. Toutes les erreurs rencontrées lors de l'exécution de mi_print_stack() sont signalées à $MSGPATH.

Cette fonctionnalité est uniquement disponible pour OC Solaris.

Glossaire

Termes et abréviations utilisés dans cet article :

UDR	Routine définie par l'utilisateur
V.P.	Processeur virtuel

Cet article démontre une fois de plus que tout ensemble de mesures de sécurité doit couvrir toutes les étapes de mise en œuvre : développement, déploiement, administration du système et, bien sûr, mesures organisationnelles. Dans les systèmes d’information, c’est le « facteur humain » (y compris les utilisateurs) qui constitue la principale menace pour la sécurité. Cet ensemble de mesures doit être raisonnable et équilibré : cela n’a aucun sens et il est peu probable que des fonds suffisants soient alloués pour organiser une protection qui dépasse le coût des données elles-mêmes.

Introduction

1C:Enterprise est le système comptable le plus répandu en Russie, mais malgré cela, jusqu'à la version 8.0, ses développeurs accordaient très peu d'attention aux problèmes de sécurité. Fondamentalement, bien sûr, cela était dicté par la niche de prix du produit et par l'accent mis sur les petites entreprises où il n'y a pas de spécialistes informatiques qualifiés, et le coût éventuel de déploiement et de maintenance d'un système sécurisé serait prohibitif pour l'entreprise. Avec la sortie de la version 8.0, l'accent a dû changer : le coût des solutions a considérablement augmenté, le système est devenu beaucoup plus évolutif et flexible - les exigences ont considérablement changé. La question de savoir si le système est devenu suffisamment fiable et sécurisé est une question très individuelle. Le système d'information principal d'une entreprise moderne doit répondre au moins aux exigences de sécurité suivantes :

• Probabilité assez faible de défaillance du système pour des raisons internes.
• Autorisation fiable des utilisateurs et protection des données contre les actions incorrectes.
• Un système efficace d’attribution des droits des utilisateurs.
• Système de sauvegarde et de récupération en ligne en cas de panne.

Les solutions basées sur 1C:Enterprise 8.0 répondent-elles à ces exigences ? Il n'y a pas de réponse claire. Malgré des changements importants dans le système de contrôle d'accès, de nombreux problèmes non résolus demeurent. Selon la façon dont le système est conçu et configuré, toutes ces exigences peuvent ne pas être satisfaites ou satisfaites dans une mesure suffisante pour une mise en œuvre donnée, cependant, cela vaut la peine d'y prêter attention (et c'est une conséquence importante de la « jeunesse » de la plateforme ) que pour remplir pleinement les conditions énumérées, il est nécessaire de déployer des efforts véritablement herculéens.

Cet article est destiné aux développeurs et aux implémenteurs de solutions sur la plate-forme 1C:Enterprise, ainsi qu'aux administrateurs système des organisations où 1C:Enterprise est utilisé, et décrit certains aspects du développement et de la configuration de la version client-serveur du système à partir du point point de vue de l'organisation sécurité des informations. Cet article ne peut pas être utilisé en remplacement de la documentation, mais souligne seulement certains points qui n'y sont pas encore reflétés. Et, bien entendu, ni cet article ni toute la documentation ne seront en mesure de refléter la complexité du problème de la construction d'un système d'information sécurisé, qui doit en même temps satisfaire aux exigences contradictoires de sécurité, de performances, de commodité et de fonctionnalité.

Classification et terminologie

Le principal sujet de réflexion dans cet article concerne les menaces liées à l’information.

Menace informationnelle– la possibilité d'une situation dans laquelle les données seront lues, copiées, modifiées ou bloquées sans autorisation.

Et, sur la base de cette définition, l’article classe les menaces informatiques comme suit :

• Destruction non autorisée de données
• Modification non autorisée des données
• Copie non autorisée des données
• Lecture non autorisée des données
• Indisponibilité des données

Toutes les menaces sont divisées en intentionnelles et non intentionnelles. Nous appellerons une menace informationnelle réalisée incident. Les caractéristiques du système sont les suivantes :

Vulnérabilités– caractéristiques conduisant à des incidents Mesures de protection– des fonctionnalités qui bloquent la possibilité d’un incident

Fondamentalement, seuls les cas dont la probabilité est due à l'utilisation de la plate-forme technologique 1C : Enterprise 8.0 dans la version client-serveur sont pris en compte (en outre, dans les cas où cela ne contredit pas le sens simplement de 1C ou 1C 8.0) . Définissons les principaux rôles suivants par rapport à l'utilisation du système :

• Les opérateurs– les utilisateurs qui ont des droits de visualisation et de modification des données limités par un rôle d'application, mais qui ne disposent pas de fonctions d'administration
• Administrateurs système– les utilisateurs qui disposent de droits d'administration dans le système, y compris des droits d'administration dans les systèmes d'exploitation du serveur d'applications et du serveur MS SQL, des droits d'administration dans MS SQL, etc.
• Administrateurs de la sécurité de l'information– les utilisateurs auxquels sont déléguées certaines fonctions administratives de la base d'informations 1C (telles que l'ajout d'utilisateurs, les tests et corrections, la sauvegarde, la mise en place d'une solution applicative, etc.)
• Développeurs de systèmes– les utilisateurs développant une solution applicative. En général, ils peuvent ne pas avoir accès au système en état de marche.
• Personnes n'ayant pas d'accès direct au système– les utilisateurs qui ne disposent pas de droits d'accès délégués à 1C, mais qui peuvent, à un degré ou à un autre, influencer le fonctionnement du système (il s'agit généralement de tous les utilisateurs du même domaine Active Directory dans lequel le système est installé). Cette catégorie est considérée principalement pour identifier les sujets potentiellement dangereux dans le système.
• Scripts d'administration automatisés– des programmes auxquels sont déléguées certaines fonctions, conçus pour effectuer automatiquement certaines actions (par exemple, import-export de données)

Il convient de noter ici deux points : d'une part, cette classification est très grossière et ne prend pas en compte les divisions au sein de chaque groupe - une telle division sera créée pour certains cas spécifiques, et d'autre part, il est supposé que d'autres personnes ne peuvent pas influencer le fonctionnement. du système, qui doit être fourni par des moyens externes à 1C.

Tout système de sécurité doit être conçu en tenant compte de la faisabilité et du coût de possession. De manière générale, lors de l'élaboration et de la mise en œuvre d'un système d'information, il faut que le prix de la protection du système corresponde à :

• la valeur des informations protégées ;
• les coûts de création d'un incident (en cas de menace délibérée) ;
• risques financiers en cas d'incident

Il est inutile et néfaste d’organiser une défense qui coûte bien plus cher que d’évaluer son efficacité financière. Il existe plusieurs méthodes pour évaluer les risques de perte d'informations, mais elles ne sont pas abordées dans le cadre de cet article. Un autre aspect important est le maintien d'un équilibre entre des exigences souvent contradictoires en matière de sécurité de l'information, de performances du système, de commodité et de facilité d'utilisation du système, de rapidité de développement et de mise en œuvre, ainsi que d'autres exigences relatives aux systèmes d'information d'entreprise.

Principales caractéristiques du mécanisme de sécurité des informations du système

1C:Enterprise 8.0 est disponible en deux versions : fichier et client-serveur. La version du fichier ne peut pas être considérée comme garantissant la sécurité des informations du système pour les raisons suivantes :

• Les données et la configuration sont stockées dans un fichier lisible et inscriptible par tous les utilisateurs du système.
• Comme nous le verrons ci-dessous, l'autorisation du système est très facilement contournée.
• L'intégrité du système est assurée uniquement par le noyau de la partie client.

Dans la version client-serveur, MS SQL Server est utilisé pour stocker des informations, qui fournissent :

• Stockage de données plus fiable.
• Isolation des fichiers de l'accès direct.
• Mécanismes de transaction et de verrouillage plus avancés.

Malgré les différences significatives entre les versions fichier et client-serveur du système, elles disposent d'un schéma de contrôle d'accès unifié au niveau de la solution applicative, qui offre les fonctionnalités suivantes :

• Autorisation de l'utilisateur à l'aide du mot de passe spécifié dans 1C.
• Autorisation utilisateur basée sur l'utilisateur Windows actuel.
• Attribution de rôles aux utilisateurs du système.
• Limiter les fonctions administratives par rôle.
• Affectation des interfaces disponibles par rôles.
• Restreindre l'accès aux objets de métadonnées par rôle.
• Restreindre l'accès aux détails des objets par rôle.
• Restreindre l'accès aux objets de données par rôles et paramètres de session.
• Restreindre l'accès interactif aux données et aux modules exécutables.
• Certaines restrictions d'exécution de code.

En général, le schéma d'accès aux données utilisé est assez typique des systèmes d'information de ce niveau. Cependant, par rapport à cette mise en œuvre d’une architecture client-serveur à trois niveaux, il existe plusieurs aspects fondamentaux qui conduisent à un nombre relativement important de vulnérabilités :

1. Un grand nombre d'étapes de traitement des données et à chaque étape des règles différentes d'accès aux objets peuvent s'appliquer.

   Un schéma quelque peu simplifié des étapes de traitement des données importantes du point de vue de la sécurité est présenté à la figure 1. Règle générale pour 1C consiste à réduire les restrictions à mesure que vous avancez dans ce schéma, par conséquent, en utilisant une vulnérabilité sur l'un des niveaux supérieurs peut perturber le système à tous les niveaux.

2. Procédures insuffisamment établies pour surveiller les données transmises lors du passage d'un niveau à l'autre.

   Malheureusement, tous les mécanismes internes du système ne sont pas parfaitement débogués, notamment pour les mécanismes non interactifs, dont le débogage est toujours plus laborieux d'une part, mais plus responsable de l'autre. Cette « maladie » n'est pas un problème exclusivement lié à 1C : elle se retrouve dans de nombreux produits serveur de la plupart des fournisseurs. Ce n’est que ces dernières années que l’attention portée à ces problèmes s’est considérablement accrue.

3. Qualifications moyennes insuffisamment élevées des développeurs et administrateurs système, héritées de la version précédente.

   Les produits de la gamme 1C:Enterprise étaient initialement axés sur la facilité de développement et de support et sur le travail dans de petites organisations. Il n'est donc pas surprenant qu'historiquement, une partie importante des « développeurs » de solutions d'application et des « administrateurs » de les systèmes ne disposent pas de connaissances et de compétences suffisantes pour travailler avec un produit beaucoup plus complexe, à savoir la version 8.0. Le problème est aggravé par la pratique adoptée par les entreprises franchisées d'enseigner « au combat » aux dépens des clients, sans aborder systématiquement cette question. Il faut rendre hommage à l'entreprise 1C qui, au cours des dernières années, a progressivement corrigé cette situation : les entreprises franchisées sérieuses ont commencé à adopter une approche plus responsable du problème de la sélection et de la formation du personnel, du niveau de support informatique de la société 1C s'est considérablement développée, des programmes de certification sont apparus visant un haut niveau de service ; mais la situation ne peut pas être corrigée instantanément, ce facteur doit donc être pris en compte lors de l'analyse de la sécurité du système.

4. La plateforme est relativement jeune.

   Parmi les produits ayant un objectif et des objectifs d'utilisation similaires, il s'agit de l'une des solutions les plus récentes. La fonctionnalité de la plateforme était plus ou moins établie il y a moins d’un an. Dans le même temps, chaque version de la plate-forme, à commencer par la 8.0.10 (c'est dans cette version que presque toutes les capacités actuelles du système ont été implémentées) est devenue nettement plus stable que les précédentes. Les fonctionnalités des solutions d'application standard continuent de croître à pas de géant, même si seulement la moitié des capacités de la plate-forme sont utilisées. Bien sûr, dans de telles conditions, nous pouvons parler de stabilité de manière plutôt conditionnelle, mais en général, il faut reconnaître qu'à bien des égards, les solutions sur la plate-forme 1C 8.0 sont nettement en avance en termes de fonctionnalité et de performances (et souvent en stabilité) par rapport aux solutions similaires sur la plate-forme 1C. Plateforme 7.7.

Ainsi, le système (et éventuellement une solution applicative standard) est déployé dans l'entreprise et installé sur les ordinateurs. Tout d'abord, il est nécessaire de créer un environnement dans lequel la configuration de la sécurité 1C a du sens, et pour cela, elle doit être configurée de telle manière que l'hypothèse selon laquelle la sécurité du système est significativement affectée par les paramètres du système soit remplie.

Suivez les règles générales de mise en place de la sécurité.

Il ne peut être question de sécurité des informations d'un système si les principes de base de la création de systèmes sécurisés ne sont pas respectés. Assurez-vous qu'au moins les conditions suivantes sont remplies :

• L'accès aux serveurs est physiquement limité et leur fonctionnement ininterrompu est assuré :
  • l'équipement serveur répond aux exigences de fiabilité, le remplacement des équipements serveur défaillants a été ajusté, pour les zones particulièrement critiques, des schémas avec duplication de matériel sont utilisés (RAID, alimentation provenant de sources multiples, canaux de communication multiples, etc.) ;
  • les serveurs sont situés dans un local verrouillé, et ce local n'est ouvert que pour la durée des travaux qui ne peuvent être effectués à distance ;
  • Seules une ou deux personnes ont le droit d'ouvrir la salle des serveurs ; en cas d'urgence, un système de notification des personnes responsables a été développé ;
  • une alimentation électrique ininterrompue des serveurs est assurée
  • les conditions climatiques normales de fonctionnement de l'équipement sont assurées ;
  • il y a une alarme incendie dans la salle des serveurs, il n'y a aucun risque d'inondation (surtout pour le premier et le dernier étage) ;
• Les paramètres du réseau et de l'infrastructure d'information de l'entreprise sont correctement complétés :
  • Des pare-feu sont installés et configurés sur tous les serveurs ;
  • tous les utilisateurs et ordinateurs sont autorisés sur le réseau, les mots de passe sont suffisamment complexes pour ne pas être devinés ;
  • les opérateurs du système ont suffisamment de droits pour travailler normalement avec celui-ci, mais n'ont pas de droits sur les actions administratives ;
  • les outils antivirus sont installés et activés sur tous les ordinateurs du réseau ;
  • Il est souhaitable que les utilisateurs (hormis les administrateurs réseau) ne disposent pas de droits d'administration sur les postes clients ;
  • l'accès à Internet et aux supports de stockage amovibles doit être réglementé et limité ;
  • l'audit du système des événements de sécurité doit être configuré ;
• Les principaux problèmes d'organisation ont été résolus :
  • les utilisateurs ont des qualifications suffisantes pour travailler avec 1C et le matériel ;
  • les utilisateurs sont informés de la responsabilité en cas de violation des règles de fonctionnement ;
  • des personnes financièrement responsables ont été désignées pour chaque élément matériel du système d'information ;
  • toutes les unités système sont scellées et fermées ;
  • Portez une attention particulière à la formation et à la supervision des nettoyeurs, des ouvriers du bâtiment et des électriciens. Ces personnes peuvent, par négligence, causer des dommages qui ne sont pas comparables aux dommages intentionnels causés par un utilisateur peu scrupuleux du système.

Attention! Cette liste n’est pas exhaustive, mais décrit seulement ce qui manque souvent lors du déploiement de tout système d’information assez complexe et coûteux !

• MS SQL Server, serveur d'applications et partie client exécutés sur des ordinateurs différents, applications serveur exécutées sous les droits d'utilisateurs Windows spécialement créés ;
• Pour MS SQL Server
  • le mode d'autorisation mixte est défini
  • Les utilisateurs MS SQL inclus dans le rôle serveradmin ne participent pas au travail 1C,
  • pour chaque IB 1C, un utilisateur MS SQL distinct a été créé qui n'a pas d'accès privilégié au serveur,
  • L'utilisateur MS SQL d'un SI n'a pas accès aux autres SI ;
• Les utilisateurs n'ont pas d'accès direct aux fichiers du serveur d'applications et du serveur MS SQL
• Les postes opérateurs sont équipés de Windows 2000/XP (et non de Windows 95/98/Me)

Ne négligez pas les recommandations des développeurs du système et la lecture de la documentation. Des documents importants sur la configuration du système sont publiés sur les disques ITS dans la section « Recommandations méthodologiques ». Portez une attention particulière aux articles suivants :

1. Caractéristiques des applications fonctionnant avec le serveur 1C:Enterprise
2. Placement de données 1C : Entreprise 8.0
3. Mise à jour 1C : Enterprise 8.0 par les utilisateurs Microsoft Windows sans droits d'administrateur
4. Modification de la liste des utilisateurs pour le compte d'un utilisateur qui ne dispose pas de droits d'administrateur
5. Configuration des paramètres du pare-feu Windows XP SP2 pour exécuter SQL Server 2000 et SQL Server Desktop Engine (MSDE)
6. Configuration des paramètres COM+ Windows XP SP2 pour exécuter le serveur 1C:Enterprise 8.0
7. Configuration des paramètres du pare-feu Windows XP SP2 pour le serveur 1C:Enterprise 8.0
8. Configuration des paramètres du pare-feu Windows XP SP2 pour HASP License Manager
9. Création d'une sauvegarde base d'informations en utilisant SQL Server 2000
10. Problèmes d'installation et de configuration 1C:Enterprise 8.0 dans la version "client-serveur"(un des articles les plus importants)
11. Particularités Paramètres Windows Serveur 2003 lors de l'installation du serveur 1C:Enterprise 8.0
12. Réguler l'accès des utilisateurs à la base d'informations dans la version client-serveur(un des articles les plus importants)
13. Serveur 1C :Entreprise et serveur SQL
14. Procédure d'installation détaillée de 1C:Enterprise 8.0 en version "client-serveur"(un des articles les plus importants)
15. Utilisation du langage intégré sur le serveur 1C:Enterprise

Mais lors de la lecture de la documentation, soyez critique à l'égard des informations reçues, par exemple, l'article « Problèmes d'installation et de configuration de 1C : Enterprise 8.0 dans la version client-serveur » ne décrit pas avec précision les droits requis pour l'utilisateur USER1CV8SERVER. Il y aura des liens vers la liste ci-dessous, par exemple [ITS1] signifie l'article « Caractéristiques des applications fonctionnant avec le serveur 1C:Enterprise ». Tous les liens vers les articles renvoient au dernier numéro d'ITS au moment de la rédaction (janvier 2006).

Utiliser les capacités d'autorisation combinées à l'autorisation Windows pour les utilisateurs

Parmi les deux modes d'autorisation utilisateur possibles : 1C intégré et combiné avec l'autorisation du système d'exploitation Windows, si possible, vous devez choisir l'autorisation combinée. Cela permettra aux utilisateurs de ne pas être confondus avec plusieurs mots de passe lorsqu'ils travaillent, mais ne réduira pas le niveau de sécurité du système. Cependant, même pour les utilisateurs qui utilisent uniquement l'autorisation Windows, il est fortement conseillé de définir un mot de passe lors de sa création, et seulement après cela de désactiver l'autorisation 1C pour cet utilisateur. Pour assurer la récupération du système en cas de destruction de la structure Active Directory, il est nécessaire de laisser au moins un utilisateur pouvant se connecter au système avec l'autorisation 1C.

Lors de la création de rôles de solution applicative, n'ajoutez pas de droits « en réserve »

Chaque rôle de solution d'application doit refléter l'ensemble minimum de droits requis pour effectuer les actions définies par ce rôle. Toutefois, certains rôles ne peuvent pas être utilisés indépendamment. Par exemple, pour un lancement interactif traitements externes Vous pouvez créer un rôle distinct et l'ajouter à tous les utilisateurs qui doivent utiliser un traitement externe.

Examiner régulièrement les journaux et les protocoles de fonctionnement du système

Si possible, réglez et automatisez l'affichage des journaux et des protocoles de fonctionnement du système. Avec une configuration appropriée et un examen régulier des journaux (filtrage uniquement par événements importants), les actions non autorisées peuvent être détectées tôt, voire empêchées pendant la phase de préparation.

Quelques fonctionnalités de la version client-serveur

Cette section décrit certaines fonctionnalités de fonctionnement de l'option client-serveur et leur impact sur la sécurité. Pour une plus grande facilité de lecture, les notations suivantes sont utilisées :

Attention! description de la vulnérabilité

Stockage des informations qui contrôlent l'accès au système

Stockage d'une liste d'utilisateurs de sécurité de l'information

Toutes les informations sur la liste des utilisateurs de cette sécurité de l'information et les rôles qui leur sont disponibles sont stockées dans la table Params de la base de données MS SQL (voir [ITS2]). En regardant la structure et le contenu de cette table, il devient évident que toutes les informations utilisateur sont stockées dans un enregistrement avec la valeur du champ FileName « users.usr ».

Puisque nous supposons que les utilisateurs n'ont pas accès à la base de données MS SQL, ce fait en soi ne peut pas être utilisé par un attaquant. Cependant, s'il est possible d'exécuter du code dans MS SQL, cela « ouvre la porte » à l'obtention de(! ) accès depuis 1C . Le même mécanisme (avec des modifications mineures) peut également être utilisé dans la version fichier du système, ce qui, compte tenu des caractéristiques de la version fichier, exclut complètement son applicabilité dans la création de systèmes sécurisés.

Recommandation: Pour le moment, il n'existe aucun moyen de protéger complètement l'application contre de telles modifications, à l'exception de l'utilisation de déclencheurs au niveau de MS SQL Server, qui, en revanche, peuvent poser des problèmes lors de la mise à jour de la version de la plateforme ou de la modification de la liste des utilisateurs. Pour suivre ces changements, vous pouvez utiliser le journal 1C (en faisant attention aux connexions « suspectes » en mode configurateur sans spécifier l'utilisateur) ou maintenir SQL Profiler en cours d'exécution en permanence (ce qui aura un impact extrêmement négatif sur les performances du système) ou configurer les alertes. mécanisme (très probablement ensemble utilisant des déclencheurs)

Stockage des informations sur la liste IS sur le serveur

Pour chaque serveur d'applications 1C, des informations sont stockées sur la liste des bases de données MS SQL qui y sont connectées. Chaque infobase utilise sa propre chaîne de connexion du serveur d'applications et du serveur MS SQL pour fonctionner. Les informations sur les infobases enregistrées sur le serveur d'applications, ainsi que les chaînes de connexion, sont stockées dans le fichier srvrib.lst, situé sur le serveur dans le répertoire<Общие данные приложений>/1C/1Cv8 (par exemple, C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst). Pour chaque système de sécurité de l'information, une chaîne de connexion complète est stockée, y compris le mot de passe de l'utilisateur MS SQL lors de l'utilisation d'un modèle d'autorisation MS SQL mixte. C'est la présence de ce fichier qui permet de craindre un accès non autorisé à la base de données MS SQL, et si, contrairement aux recommandations, un utilisateur privilégié (par exemple « sa ») est utilisé pour accéder à au moins une base de données, alors en En plus de la menace pour la sécurité de l'information, il existe une menace pour l'ensemble du système utilisant MS SQL.

Il est intéressant de noter que l'utilisation d'une autorisation mixte et d'une autorisation Windows sur un serveur MS SQL entraîne différents types de problèmes lors de l'accès à un fichier donné. Ainsi, les principales propriétés négatives de l'autorisation Windows seront :

• Fonctionnement de toute la sécurité des informations sur le serveur d'applications et sur le serveur MS SQL sous un seul ensemble de droits (très probablement redondants)
• Depuis le processus du serveur d'applications 1C (ou en général depuis l'utilisateur USER1CV8SERVER ou son équivalent) sans spécifier de mot de passe, vous pouvez facilement vous connecter à n'importe quelle information de sécurité sans spécifier de mot de passe

En revanche, il peut être plus difficile pour un attaquant d'exécuter du code arbitraire à partir du contexte de l'utilisateur USER1CV8SERVER que d'obtenir le fichier spécifié. D'ailleurs, la présence d'un tel fichier est un autre argument en faveur de la répartition des fonctions du serveur sur différents ordinateurs.

Recommandation: Le fichier srvrib.lst ne doit être accessible que par le processus serveur. Assurez-vous de configurer l'audit pour modifier ce fichier.

Malheureusement, par défaut ce fichier n'est quasiment pas protégé contre la lecture, ce qui doit être pris en compte lors du déploiement du système. L'option idéale serait que le serveur d'applications empêche la lecture et l'écriture de ce fichier pendant son exécution (y compris la lecture et l'écriture par les connexions utilisateur exécutées sur ce serveur).

Absence d'autorisation lors de la création de la sécurité des informations sur le serveur

Attention! L'erreur d'absence d'autorisation a été corrigée dans la version 8.0.14 de la plateforme 1C:Enterprise. Dans cette version, le concept de « 1C:Enterprise Server Administrator » est apparu, mais tant que la liste des administrateurs est spécifiée sur le serveur, le système fonctionne comme décrit ci-dessous, alors n'oubliez pas cette éventuelle fonctionnalité.

La plus grande vulnérabilité de cette section est probablement la possibilité d'ajouter de manière presque illimitée la sécurité des informations au serveur d'applications, grâce à laquelle tout utilisateur ayant accès à une connexion au serveur d'applications obtient automatiquement la possibilité d'exécuter du code arbitraire sur le serveur d'applications. . Regardons cela avec un exemple.

Le système doit être installé comme suit

• MS SQL Server 2000 (par exemple, nom de réseau SRV1)
• Serveur 1C : Enterprise 8.0 (nom du réseau SRV2)
• Partie client 1C : Enterprise 8.0 (nom du réseau WS)

Il est supposé que l'utilisateur (ci-après dénommé UTILISATEUR) travaillant sur le WS dispose d'un accès au moins minimal à l'un des systèmes de sécurité de l'information enregistrés sur SRV2, mais n'a pas d'accès privilégié à SRV1 et SRV2. En général, la combinaison des fonctions des ordinateurs répertoriés n'affecte pas la situation. Le système a été configuré en tenant compte des recommandations de la documentation et des disques ITS. La situation est représentée sur la Fig. 2.

• configurer la sécurité COM+ sur le serveur d'applications afin que seuls les utilisateurs 1C aient le droit de se connecter au processus du serveur d'applications (plus de détails [ITS12]) ;
• le fichier srvrib.lst doit être en lecture seule pour l'utilisateur USER1CV8SERVER (pour ajouter une nouvelle sécurité des informations au serveur, autoriser temporairement l'écriture) ;
• Pour vous connecter à MS SQL, utilisez uniquement le protocole TCP/IP, dans ce cas vous pouvez :
  • restreindre les connexions à l'aide d'un pare-feu ;
  • configurer l'utilisation d'un port TCP non standard, ce qui compliquera la connexion des « étrangers » IB 1C ;
  • utiliser le cryptage des données transmises entre le serveur d'applications et le serveur SQL ;
• configurer le pare-feu du serveur pour que l'utilisation de serveurs MS SQL tiers soit impossible ;
• utiliser des outils de sécurité intranet pour exclure la possibilité qu'un ordinateur non autorisé apparaisse sur le réseau local (IPSec, politiques de sécurité de groupe, pare-feu, etc.) ;
• N'accordez en aucun cas à l'utilisateur USER1CV8SERVER des droits d'administration sur le serveur d'applications.

Utiliser du code exécuté sur le serveur

Lors de l'utilisation de la version client-serveur de 1C, le développeur peut répartir l'exécution du code entre le client et le serveur d'applications. Pour que le code (procédure ou fonction) soit exécuté uniquement sur le serveur, il est nécessaire de le placer dans un module général pour lequel la propriété « Serveur » est définie et, dans le cas où l'exécution du module est autorisée non seulement sur le serveur, placez le code dans la section restreinte « #If Server » :

#Si le serveur alors
Function OnServer(Param1, Param2 = 0) Export // Cette fonction, malgré sa simplicité, est exécutée sur le serveur
Param1 = Param1 + 12 ;
Renvoie Param1 ;
FinFonction
#Fin si

Lorsque vous utilisez du code qui s'exécute sur le serveur, vous devez prendre en compte les éléments suivants :

• le code s'exécute avec les droits USER1CV8SERVER sur le serveur d'application (les objets COM et les fichiers serveur sont disponibles) ;
• toutes les sessions utilisateur sont exécutées par une seule instance du service, donc, par exemple, un débordement de pile sur le serveur entraînera la déconnexion de tous les utilisateurs actifs ;
• le débogage des modules serveur est difficile (par exemple, vous ne pouvez pas définir de point d'arrêt dans le débogueur), mais doit être fait ;
• le transfert du contrôle du client vers le serveur d'applications et inversement peut nécessiter des ressources importantes avec de grands volumes de paramètres transférés ;
• utilisation d'outils interactifs (formulaires, feuilles de calcul, Boîtes de dialogue), les rapports externes et le traitement en code sur le serveur d'application sont impossibles ;
• l'utilisation de variables globales (variables de module d'application déclarées avec l'indication "Export") n'est pas autorisée ;

Pour plus de détails, voir [ITS15] et d'autres articles ITS.

Le serveur d'applications doit avoir des exigences particulières en matière de fiabilité. Dans un système client-serveur correctement construit, les conditions suivantes doivent être remplies :

• aucune action de l'application client ne doit interrompre le fonctionnement du serveur (sauf cas administratifs) ;
• le serveur ne peut pas exécuter le code de programme reçu du client ;
• les ressources doivent être réparties « équitablement » connexions clients, garantissant la disponibilité du serveur quelle que soit la charge actuelle ;
• en l’absence de blocage des données, les connexions des clients ne doivent pas affecter le travail de chacun ;
• pas sur le serveur interface utilisateur, mais des outils de surveillance et de journalisation doivent être développés ;

En général, le système 1C est construit de manière à se rapprocher de ces exigences (par exemple, il est impossible de forcer l'exécution de traitements externes sur le serveur), mais plusieurs fonctionnalités désagréables existent toujours, donc :

Recommandation: Lors du développement d'un serveur d'exécution, il est recommandé de respecter le principe de l'interface minimale. Ceux. le nombre d'entrées dans les modules serveur à partir de l'application client doit être très limité et les paramètres doivent être strictement réglementés. Recommandation: Lors de la réception des paramètres de procédures et fonctions sur le serveur, il est nécessaire de valider les paramètres (vérifier que les paramètres correspondent au type et à la plage de valeurs attendus). Cela ne se fait pas dans les solutions standards, mais il est hautement souhaitable d'introduire une validation obligatoire dans vos propres développements. Recommandation: Lors de la génération du texte de la requête (et en particulier du paramètre de commande Run) côté serveur, n'utilisez pas les chaînes reçues de l'application client.

Une recommandation générale serait de vous familiariser avec les principes de sécurité des bâtiments. la toile-applications de bases de données et travaux sur des principes similaires. Les similitudes sont en effet considérables : d'une part, comme une application web, le serveur d'applications est une couche intermédiaire entre la base de données et l'interface utilisateur (la principale différence est que le serveur web forme l'interface utilisateur) ; deuxièmement, du point de vue de la sécurité, vous ne pouvez pas faire confiance aux données reçues du client, car il est possible de lancer des rapports et des traitements externes.

Passer des paramètres

Passer des paramètres à une fonction (procédure) exécutée sur le serveur est une question assez délicate. Cela est principalement dû à la nécessité de les transférer entre le serveur d'applications et les processus clients. Lorsque le contrôle passe du côté client au côté serveur, tous les paramètres transmis sont sérialisés, transférés au serveur, où ils sont « décompressés » et utilisés. Lors du passage du côté serveur au côté client, le processus est inversé. Il convient de noter ici que ce schéma gère correctement le passage des paramètres par référence et par valeur. Lors de la transmission de paramètres, les restrictions suivantes s'appliquent :

• Seules les valeurs non mutables (c'est-à-dire dont les valeurs ne peuvent pas être modifiées) peuvent être transférées entre le client et le serveur (dans les deux sens) : types primitifs, références, collections universelles, valeurs d'énumération système, stockage de valeurs. Si vous essayez de transmettre autre chose, l'application client plante (même si le serveur tente de transmettre un paramètre incorrect).
• Il n'est pas recommandé de transférer de grandes quantités de données lors de la transmission de paramètres (par exemple, des chaînes de plus d'un million de caractères), cela pourrait affecter négativement les performances du serveur.
• Vous ne pouvez pas transmettre de paramètres contenant une référence cyclique, à la fois du serveur au client et inversement. Si vous essayez de transmettre un tel paramètre, l'application client plante (même si le serveur tente de transmettre le paramètre incorrect).
• Il n'est pas recommandé de transférer des collections de données très complexes. Lorsque vous essayez de passer un paramètre avec un niveau d'imbrication très important, le serveur plante (! ).

Attention! La fonctionnalité la plus ennuyeuse pour le moment est probablement l’erreur lors de la transmission de collections complexes de valeurs. Ainsi, par exemple, le code : Nesting Level = 1250 ;
M = Nouveau tableau ;
Paramètre passé = M ;
Pour le compte = 1 par niveau de cycle d'imbrication
MVInt = Nouveau tableau ;
M.Add(MVInt);
M = MVint ;
Fin du cycle ;
ServerFunction (PassedParameter);

Conduit à un arrêt d'urgence du serveur avec la déconnexion de tous les utilisateurs, et cela se produit avant que le contrôle ne soit transféré au code dans le langage intégré.

Utilisation de fonctions non sécurisées côté serveur.

Tous les outils de langage intégrés ne peuvent pas être utilisés dans le code exécuté sur le serveur d'applications, mais même parmi les outils disponibles, il existe de nombreuses constructions « problématiques » qui peuvent être grossièrement classées comme suit :

• capable d'offrir la possibilité d'exécuter du code non contenu dans la configuration (groupe "Code Execution")
• capable de fournir à l'application client des informations sur le fichier et système opérateur l'utilisateur ou effectuer des actions non liées au travail avec les données (« Violation des droits »)
• capable de provoquer un crash du serveur ou d'utiliser des ressources très importantes (groupe "Server crash")
• capable de provoquer une défaillance client (groupe de défaillance client) – ce type n’est pas pris en compte. Exemple : transmettre une valeur mutable au serveur.
• erreurs dans les algorithmes de programmation (boucles sans fin, récursivité illimitée, etc.) (« Erreurs de programmation »)

Les principales conceptions problématiques que je connais (avec des exemples) sont répertoriées ci-dessous :

Procédure Exécuter(<Строка>)

Exécution du code. Vous permet d'exécuter un morceau de code qui lui est transmis sous forme de valeur de chaîne. Lorsqu'il est utilisé sur le serveur, vous devez vous assurer que les données reçues du client ne sont pas utilisées comme paramètre. Par exemple, l'utilisation suivante n'est pas autorisée :

#Si le serveur alors
Exportation de procédure sur serveur (Param1)
Exécuter(Param1);
Fin de la procédure
#Fin si

Tapez "COMObject" (constructeur New COMObject(<Имя>, <Имя сервера>))

Crée un objet COM d'application externe avec les droits USER1CV8SERVER sur le serveur d'applications (ou un autre ordinateur spécifié). Lorsqu'il est utilisé sur un serveur, assurez-vous que les paramètres ne sont pas transmis depuis l'application client. Cependant, côté serveur, il est efficace d'utiliser cette fonctionnalité lors de l'importation/exportation, de l'envoi de données sur Internet, de la mise en œuvre de fonctions non standard, etc.

Fonction GetCOMObject(<Имя файла>, <Имя класса COM>)

Violation des droits et exécution du code. Semblable au précédent, obtenant uniquement l'objet COM correspondant au fichier.

Procédures et fonctions ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()

Violation des droits. En les exécutant sur le serveur, ils permettent de connaître les détails de l'organisation du sous-système serveur. Lorsqu'elles sont utilisées sur un serveur, assurez-vous que les données ne sont pas transférées au client ou ne sont pas accessibles aux opérateurs sans autorisation appropriée. Portez une attention particulière au fait que les données peuvent être retransmises dans un paramètre passé par référence.

Procédures et fonctions pour travailler avec des fichiers (CopyFile, FindFiles, MergeFiles et bien d'autres), ainsi que les types de fichiers.

Violation des droits. Ils permettent, en les exécutant sur le serveur, d'accéder de manière partagée à des fichiers locaux (et situés sur le réseau) accessibles sous les droits d'utilisateur USER1CV8SERVER. S'il est utilisé consciemment, il est alors possible de mettre en œuvre efficacement des tâches telles que l'importation/exportation de données sur le serveur.

Assurez-vous de vérifier vos droits d'utilisateur 1C avant d'utiliser ces fonctions. Pour vérifier les droits des utilisateurs, vous pouvez utiliser la construction suivante dans le module serveur :

#Si le serveur alors
Procédure PerformWorkWithFile() Exportation
RoleAdministrator = Metadata.Roles.Administrator ;
Utilisateur = SessionParameters.CurrentUser ;
Si User.Roles.Contains(RoleAdministrator) Alors
//Le code pour travailler avec les fichiers est exécuté ici
fin si;
#Fin si

Assurez-vous de vérifier les paramètres si vous utilisez ces procédures et fonctions, sinon il existe un risque de causer accidentellement ou sciemment des dommages irréparables au serveur d'applications 1C, par exemple lors de l'exécution du code suivant sur le serveur :

Chemin = "C:\Documents and Settings\Tous les utilisateurs\Application Data\1C\1Cv8\" ;
MoveFile(Chemin + "srvrib.lst", Chemin + "VoiciOùLeFichierGoes");

Après avoir exécuté ce code sur le serveur, si l'utilisateur USER1CV8SERVER a le droit de le modifier, comme décrit ci-dessus, et après avoir redémarré le processus serveur (par défaut, 3 minutes après la sortie de tous les utilisateurs), une GRANDE question se posera sur le démarrage du serveur. . Mais il est également possible de supprimer complètement des fichiers...

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

Violation des droits. Ils permettent, en les exécutant sur le serveur, d'accéder à des fichiers locaux (et situés sur le réseau) de certains types et de les lire/écrire sous les droits d'utilisateur USER1CV8SERVER. S'il est utilisé consciemment, il est possible de mettre en œuvre efficacement des tâches telles que l'importation/exportation de données sur le serveur, la journalisation du fonctionnement de certaines fonctions et la résolution de tâches administratives. En général, les recommandations coïncident avec le paragraphe précédent, mais vous devez envisager la possibilité de transférer des données de ces fichiers (mais pas des objets de tous ces types) entre les parties client et serveur.

Tapez "Informations système"

Violation des droits. Permet d'obtenir des données sur le serveur d'application en cas d'utilisation incorrecte et de transfert de données vers la partie client de l'application. Il est conseillé de limiter le droit d'usage lors de l'utilisation.

Types "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Violation des droits. Lorsqu'il est utilisé sur un serveur, il se connecte à un PC distant depuis un serveur d'applications sous les droits USER1CV8SERVER. Recommandations :

• Contrôle des paramètres lors de l'appel des méthodes.
• Contrôle des droits des utilisateurs 1C.
• Restrictions sévères sur les droits de l'utilisateur USER1CV8SERVER pour accéder au réseau.
• Configurer correctement le pare-feu sur le serveur d'applications 1C.

Lorsqu'il est utilisé correctement, il est pratique pour organiser, par exemple, l'envoi d'emails depuis un serveur d'applications.

Types "InformationBaseUserManager", "InformationBaseUser"

Violation des droits. En cas de mauvaise utilisation (dans un module privilégié), il est possible d'ajouter des utilisateurs ou de modifier les paramètres d'autorisation des utilisateurs existants.

Format de fonction

Crash du serveur. Oui! Cette fonction apparemment inoffensive, si ses paramètres ne sont pas contrôlés et exécutés sur le serveur, peut provoquer le crash de l'application serveur. L'erreur se produit lors du formatage des nombres et de l'utilisation du mode d'affichage des zéros non significatifs et d'un grand nombre de caractères, par exemple

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

J'espère que cette erreur sera corrigée dans les prochaines versions de la plateforme, mais en attendant, dans tous les appels à cette fonction pouvant être exécutés sur le serveur, vérifiez les paramètres d'appel.

Procédures et fonctions de sauvegarde des valeurs (ValueInRowInt, ValueInFile)

Crash du serveur. Ces fonctions ne gèrent pas les références circulaires dans les collections ou les imbrications très profondes, elles peuvent donc planter dans certains cas très particuliers.

Erreurs dans les limites et valeurs de paramètres spéciaux dans les fonctions. Contrôle d'exécution.

L'un des problèmes que vous pouvez rencontrer lors de l'utilisation d'un serveur est la "responsabilité" élevée des fonctions du serveur (possibilité de planter l'ensemble de l'application serveur en raison d'une erreur dans une connexion et de l'utilisation d'un "espace de ressources" pour toutes les connexions). . D’où la nécessité de contrôler les principaux paramètres d’exécution :

• Pour les fonctions de langage intégrées, vérifiez leurs paramètres de lancement (un bon exemple est la fonction « Format »)
• Lorsque vous utilisez des boucles, assurez-vous que la condition de sortie de boucle est satisfaite. Si la boucle est potentiellement infinie, limiter artificiellement le nombre d'itérations : MaximumIterationCounterValue = 1000000 ;
  Compteur d'itérations = 1 ;
  Au revoir
  FunctionWhichMayNotReturnFalseValue()
  ET (nombre d'itérations<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Corps de la boucle
  Compteur d'itérations = Compteur d'itérations + 1 ;
  Fin du cycle ;
  Si compteur d'itérations> Valeur maximale du compteur d'itérations alors
  //.... gérer l'événement d'exécution d'une boucle trop longue
  fin si;

• Lorsque vous utilisez la récursivité, limitez le niveau d'imbrication maximum.
• Lors de la création et de l'exécution de requêtes, essayez d'éviter les sélections très longues et les sélections d'une grande quantité d'informations (par exemple, lors de l'utilisation de la condition « DANS LA HIÉRARCHIE », n'utilisez pas de valeur vide)
• Lors de la conception d'une base d'informations, prévoir une réserve de profondeur de bits suffisamment grande pour les nombres (sinon l'addition et la multiplication deviennent non commutatives et non associatives, ce qui rend le débogage difficile)
• Dans les requêtes exécutables, vérifiez la logique de fonctionnement pour la présence de valeurs NULL et le bon fonctionnement des conditions et expressions de requête utilisant NULL.
• Lorsque vous utilisez des collections, contrôlez la possibilité de les transférer entre le serveur d'applications et le côté client.

Utiliser l'accès au terminal côté client pour restreindre l'accès

Vous pouvez souvent trouver des recommandations pour utiliser l'accès au terminal afin de limiter l'accès aux données et d'améliorer les performances en exécutant du code côté client sur le serveur de terminal. Oui, si elle est configurée correctement, l'utilisation de l'accès au terminal peut en effet augmenter le niveau global de sécurité du système, mais, malheureusement, vous pouvez souvent constater qu'avec une utilisation pratique, la sécurité du système ne fait que diminuer. Essayons de comprendre à quoi cela est lié. Il existe désormais deux moyens courants d'organiser l'accès aux terminaux, à savoir Microsoft Terminal Services (protocole RDP) et Citrix Metaframe Server (protocole ICA). En général, les outils Citrix offrent des options d'administration des accès beaucoup plus flexibles, mais le prix de ces solutions est beaucoup plus élevé. Nous ne considérerons que les fonctionnalités de base communes aux deux protocoles qui peuvent réduire le niveau global de sécurité. Il n'y a que trois dangers principaux lors de l'utilisation de l'accès au terminal :

• Possibilité de bloquer le travail des autres utilisateurs en saisissant des quantités excessives de ressources
• Accès aux données des autres utilisateurs.
• Copie non autorisée des données du serveur de terminaux vers l'ordinateur de l'utilisateur

Dans tous les cas, les Services Terminal Server vous permettent de :

• Augmenter la fiabilité du travail (en cas de panne sur l'ordinateur du terminal, l'utilisateur peut ensuite continuer à travailler au même endroit)
• Restreindre l'accès à l'application client et aux fichiers qu'elle enregistre.
• Transférer la charge de calcul du poste de travail de l'utilisateur vers le serveur d'accès au terminal
• Gérez les paramètres du système de manière plus centralisée. Pour les utilisateurs, les paramètres enregistrés seront valides quel que soit l'ordinateur à partir duquel ils se sont connectés au système.
• Dans certains cas, vous pouvez utiliser une solution de terminal pour accéder à distance au système.

Il est nécessaire de limiter le nombre de connexions possibles au serveur de terminaux pour un utilisateur

En raison de la « gourmandise » de l'application client 1C en matière de ressources, il est impératif de limiter le nombre maximum de connexions simultanées d'un utilisateur (opérateur) au serveur de terminaux. Une connexion activement utilisée peut utiliser jusqu'à 300 Mo de mémoire avec une seule instance de l'application. En plus de la mémoire, le temps CPU est activement utilisé, ce qui ne contribue pas non plus à la stabilité des utilisateurs de ce serveur. Tout en empêchant une utilisation excessive des ressources du serveur, une telle restriction peut empêcher l'utilisation des ressources de quelqu'un d'autre. compte. Implémenté par les paramètres standard du serveur de terminaux.

Vous ne devez pas autoriser l'exécution simultanée de plus d'une ou deux applications client 1C sur une seule connexion.

Dicté par les mêmes raisons que dans le paragraphe précédent, mais techniquement plus difficile à mettre en œuvre. Le problème est qu'il est presque impossible d'empêcher le redémarrage de 1C à l'aide des outils du serveur de terminaux (pourquoi cela sera expliqué ci-dessous), vous devez donc implémenter cette fonctionnalité au niveau de la solution applicative (ce qui n'est pas non plus une bonne solution, car les sessions peuvent rester « suspendues » pendant un certain temps. Si l'application est terminée de manière incorrecte, il est nécessaire d'affiner la solution d'application dans le module d'application et certains ouvrages de référence, ce qui compliquera l'utilisation des mises à jour de 1C). Il est hautement souhaitable de laisser à l'utilisateur la possibilité d'exécuter 2 applications afin de pouvoir exécuter certaines actions (par exemple, générer des rapports) en arrière-plan - l'application client, malheureusement, est en fait monothread.

Il n'est pas recommandé d'accorder des droits d'accès au serveur de terminaux aux utilisateurs qui ont le droit d'exécuter des tâches informatiques gourmandes en ressources dans 1C ou d'empêcher un tel lancement pendant que d'autres utilisateurs travaillent activement.

Bien entendu, il est préférable de laisser l'accès au serveur de terminaux uniquement aux utilisateurs qui n'utilisent pas de tâches telles que l'exploration de données, les diagrammes géographiques, l'import/export et d'autres tâches qui chargent sérieusement la partie client de l'application. S'il est toujours nécessaire d'autoriser de telles tâches, il est alors nécessaire de : informer l'utilisateur que ces tâches peuvent affecter les performances des autres utilisateurs, enregistrer le début et la fin d'un tel processus dans le journal, autoriser l'exécution uniquement à un rythme réglementé. le temps, etc

Il faut s'assurer que chaque utilisateur dispose de droits d'écriture uniquement sur des répertoires strictement définis sur le serveur de terminaux et que les autres utilisateurs n'y ont pas accès.

Premièrement, si vous ne limitez pas la possibilité d'écrire dans des répertoires partagés (tels que le répertoire où 1C est installé), alors il reste possible pour un attaquant de modifier le comportement du programme pour tous les utilisateurs. Deuxièmement, les données d'un utilisateur (fichiers temporaires, fichiers de sauvegarde des paramètres de rapport, etc.) ne doivent en aucun cas être accessibles à un autre utilisateur du serveur de terminaux - en général, lors d'une configuration normale, cette règle est respectée. Troisièmement, l'attaquant a toujours la possibilité de « salir » la partition afin qu'il ne reste plus d'espace sur le disque dur. Je sais qu'on me objectera que le système d'exploitation Windows, à commencer par Windows 2000, dispose d'un mécanisme de quotas, mais c'est un mécanisme assez coûteux, et je n'en ai pratiquement jamais vu une réelle utilité.

Si les problèmes précédents de configuration de l'accès étaient généralement assez faciles à mettre en œuvre, alors une tâche aussi (apparemment) simple que de réglementer l'accès des utilisateurs aux fichiers n'est pas mise en œuvre de manière triviale. Premièrement, si le mécanisme de quota n'est pas utilisé, des fichiers volumineux peuvent être enregistrés. Deuxièmement, le système est construit de telle manière qu'il sera presque toujours possible de sauvegarder le fichier afin qu'il soit disponible pour un autre utilisateur.

Étant donné que la tâche est difficile à résoudre complètement, il est recommandé d'auditer la plupart des événements de fichiers.

Il est nécessaire d'interdire la connexion (mapping) des périphériques disques, des imprimantes et du presse-papier du poste client.

En RDP et ICA, il est possible d'organiser la connexion automatique des disques, imprimantes, ports COM du presse-papiers de l'ordinateur terminal au serveur. Si cette opportunité existe, il est alors presque impossible d'empêcher le lancement de code étranger sur le serveur de terminal et la sauvegarde des données de 1C sur le client d'accès au terminal. Autorisez ces fonctionnalités uniquement pour les personnes disposant de droits d'administrateur.

L'accès aux fichiers réseau à partir du serveur de terminaux doit être limité.

Si cela n'est pas fait, l'utilisateur pourra à nouveau exécuter du code indésirable ou enregistrer des données. Étant donné que le journal régulier ne suit pas les événements de fichiers (d'ailleurs, une bonne idée à mettre en œuvre par les développeurs de plates-formes) et qu'il est presque impossible de mettre en place un audit du système sur l'ensemble du réseau (il n'y a pas assez de ressources pour le maintenir), il est préférable que l'utilisateur puisse envoyer les données soit par impression, soit par courrier électronique. Faites particulièrement attention à ce que le serveur de terminaux ne fonctionne pas directement avec les supports amovibles des utilisateurs.

Vous ne devez en aucun cas laisser le serveur d'applications sur le serveur de terminaux lors de la création d'un système sécurisé.

Si le serveur d'applications s'exécute sur le même ordinateur que les applications client, il existe de nombreuses possibilités de perturber son fonctionnement normal. Si, pour une raison quelconque, il est impossible de séparer les fonctions du serveur de terminaux et du serveur d'applications, accordez une attention particulière à l'accès des utilisateurs aux fichiers utilisés par le serveur d'applications.

Il est nécessaire d'exclure la possibilité d'exécuter toutes les applications sauf 1C:Enterprise sur le serveur de terminaux.

C’est l’un des souhaits les plus difficiles à mettre en œuvre. Commençons par le fait que vous devez configurer correctement la politique de stratégie de sécurité de groupe dans le domaine. Tous les modèles d'administration et stratégies de restriction logicielle doivent être configurés correctement. Pour vous tester, assurez-vous qu'au moins les fonctionnalités suivantes sont bloquées :

La complexité de mise en œuvre de cette exigence conduit souvent à la possibilité de lancer une session 1C « supplémentaire » sur le serveur de terminal (même si les autres applications sont limitées, il est fondamentalement impossible d'interdire le lancement de 1C sous Windows).

Considérez les limites du journal régulier (tous les utilisateurs utilisent le programme à partir d'un seul ordinateur)

Évidemment, puisque les utilisateurs ouvrent 1C en mode terminal, alors le serveur de terminaux sera enregistré dans le journal. Le journal n'indique pas à partir de quel ordinateur l'utilisateur s'est connecté.

Terminal Server – Protection ou vulnérabilité ?

Ainsi, après avoir examiné les principales caractéristiques du terminal nord, nous pouvons dire que le terminal nord peut potentiellement contribuer à l'automatisation de la répartition de la charge informatique, mais la construction d'un système sécurisé est assez difficile. L'un des cas où l'utilisation d'un serveur de terminaux est la plus efficace est lors de l'exécution de 1C sans l'Explorateur Windows en mode plein écran pour les utilisateurs disposant de fonctionnalités limitées et d'une interface spécialisée.

Travail de la partie client

Utiliser Internet Explorer (IE)

L'une des conditions du fonctionnement normal de la partie client 1C est l'utilisation de composants Internet Explorer. Vous devez être très prudent avec ces composants.

Attention! Premièrement, si un module de logiciel espion ou publicitaire est « attaché » à IE, il se chargera même si vous affichez des fichiers HTML dans 1C. Jusqu'à présent, je n'ai vu aucune utilisation consciente de cette fonctionnalité, mais j'ai vu dans l'une des organisations un module « espion » chargé provenant d'un des réseaux pornographiques avec 1C en cours d'exécution (le programme antivirus n'a pas été mis à jour, dont les symptômes ont été détectés). : lors de la configuration du pare-feu, il était clair que 1C essayait de se connecter à un site pornographique sur le port 80). En fait, c'est un autre argument en faveur du fait que la protection doit être globale

Attention! Deuxièmement, le système 1C permet d'utiliser des animations Flash, des objets ActiveX, VBScript dans les documents HTML affichés, l'envoi de données sur Internet, voire l'ouverture de fichiers PDF (!), bien que dans ce dernier cas il demande « ouvrir ou enregistrer »... En général, tout ce que votre cœur désire. Un exemple d'utilisation pas tout à fait raisonnable des capacités intégrées d'affichage et d'édition HTML :

• Créez un nouveau document HTML (Fichier -> Nouveau -> Document HTML).
• Allez dans l'onglet "Texte" du document vierge.
• Supprimez le texte (entièrement).
• Allez dans l'onglet "Affichage" de ce document
• Par glisser-déposer, déplacez un fichier avec une extension SWF (ce sont des fichiers d'animation Flash) d'un explorateur ouvert vers une fenêtre de document, par exemple depuis le cache du navigateur, bien que vous puissiez également utiliser un jouet FLASH pour vous amuser.
• Si jolie! Vous pouvez faire fonctionner un jouet sur 1C !

Du point de vue de la sécurité du système, c'est complètement faux. Jusqu'à présent, je n'ai vu aucune attaque particulière sur 1C via cette vulnérabilité, mais ce sera très probablement une question de temps et de valeur de vos informations.

Il existe d'autres problèmes mineurs qui surviennent lorsque vous travaillez avec un champ de document HTML, mais les principaux sont les deux répertoriés. Cependant, si vous abordez ces fonctionnalités de manière créative, vous pouvez organiser des capacités d'interface vraiment étonnantes pour travailler avec 1C.

Utilisation de rapports et de traitements externes.

Attention! Rapports et traitements externes - d'une part - moyen pratique la mise en œuvre de formulaires imprimés supplémentaires, de reporting réglementaire, de rapports spécialisés, en revanche, constitue un moyen potentiel de contourner de nombreuses restrictions de sécurité du système et de perturber le fonctionnement du serveur d'applications (pour un exemple, voir ci-dessus dans « Passage des paramètres »). Dans le système 1C, il existe un paramètre spécial dans l'ensemble des droits pour le rôle "Ouverture interactive du traitement externe", mais cela ne résout pas complètement le problème - pour une solution complète, il est nécessaire de restreindre le cercle d'utilisateurs pouvant gérer formulaires imprimés externes, rapports réglementaires et autres fonctionnalités standard de solutions standards mises en œuvre à l'aide de traitements externes. Par exemple, par défaut dans UPP, tous les rôles d'utilisateur principaux ont la possibilité de travailler avec un répertoire de formulaires imprimés supplémentaires, et il s'agit en fait de la possibilité d'utiliser n'importe quel traitement externe.

Utiliser des mécanismes standards pour des solutions et plateformes standards (échange de données)

Certains des mécanismes standards sont potentiellement dangereux, et de manière inattendue.

Impression de listes

Toute liste (par exemple, un répertoire ou un registre d'informations) du système peut être imprimée ou enregistrée dans un fichier. Pour cela, il suffit d'utiliser la fonctionnalité standard disponible depuis le menu contextuel et le menu « Actions » :

Gardez à l’esprit que pratiquement tout ce que l’utilisateur voit dans les listes peut être exporté vers des fichiers externes. La seule chose que nous pouvons vous conseiller est de tenir un journal des impressions de documents sur les serveurs d'impression. Pour les formulaires particulièrement critiques, il est nécessaire de configurer le panneau d'action associé au champ de table protégé pour que la possibilité d'afficher une liste ne soit pas disponible depuis ce panneau, et de désactiver le menu contextuel (voir Figure 6).

Échange de données dans une base de données distribuée

Le format d'échange de données est assez simple et est décrit dans la documentation. Si l'utilisateur a la possibilité de remplacer plusieurs fichiers, il peut apporter des modifications non autorisées au système (bien qu'il s'agisse d'une tâche assez laborieuse). La possibilité de créer une base de données périphérique lors de l'utilisation de plans d'échange de bases de données distribuées ne devrait pas être accessible aux opérateurs ordinaires.

Échange de données XML standard

Dans l'échange de données standard, utilisé pour l'échange entre des configurations standard (par exemple, « Trade Management » et « Enterprise Accounting »), il est possible de spécifier des gestionnaires d'événements pour le chargement et le déchargement d'objets dans les règles d'échange. Ceci est implémenté en obtenant un gestionnaire à partir du fichier et la procédure « Run() » pour le traitement standard du chargement et du déchargement du fichier (la procédure « Run() » est lancée côté client). Évidemment, il n’est pas difficile de créer un tel faux fichier d’échange qui effectuera des actions malveillantes. Pour la plupart des rôles utilisateur des solutions standards, le partage est autorisé par défaut.

Recommandation: restreindre l'accès à l'échange XML pour la plupart des utilisateurs (en le laissant uniquement aux administrateurs de la sécurité de l'information). Conserver des traces des exécutions de ce traitement, en sauvegardant le fichier d'échange, par exemple, en l'envoyant par email administrateur de la sécurité des informations avant le téléchargement.

Utiliser des rapports génériques, notamment la console de rapports

Un autre problème concerne l'accès des utilisateurs par défaut aux rapports génériques, en particulier au rapport Report Console. Ce rapport se caractérise par le fait qu'il vous permet d'exécuter presque toutes les demandes de sécurité de l'information et, même si le système de droits 1C (y compris RLS) est configuré de manière assez stricte, il permet à l'utilisateur d'obtenir de nombreuses informations « supplémentaires ». et forcer le serveur à exécuter une requête qui consommera toutes les ressources du système.

Utilisation du mode plein écran (mode bureau)

L'un des moyens efficaces d'organiser des interfaces spécialisées avec un accès limité aux fonctionnalités du programme est le mode plein écran de la forme principale (et éventuellement la seule) de l'interface utilisée. Dans ce cas, il n'y a aucun problème d'accessibilité, par exemple le menu "Fichier" et toutes les actions de l'utilisateur sont limitées par les capacités du formulaire utilisé. Pour plus de détails, voir « Fonctionnalités d'implémentation du mode bureau » sur le disque ITS.

Sauvegarde

La sauvegarde pour la version client-serveur de 1C peut être effectuée de deux manières : en téléchargeant des données dans un fichier avec l'extension dt et en créant des copies de sauvegarde à l'aide de SQL. La première méthode présente de nombreux inconvénients : un accès exclusif est requis, la création d'une copie elle-même prend beaucoup plus de temps, dans certains cas (si la structure de sécurité de l'information est violée) la création d'une archive est impossible, mais il y a un avantage - la taille minimale de les archives. Pour la sauvegarde SQL, l'inverse est vrai : la création d'une copie s'effectue en arrière-plan à l'aide du serveur SQL, en raison de la structure simple et du manque de compression - c'est un processus très rapide, et tant que l'intégrité physique du SQL la base de données n'est pas violée, la sauvegarde est effectuée, mais la taille de la copie coïncide avec la vraie taille de la sécurité des informations à l'état étendu (la compression n'est pas effectuée). En raison des avantages supplémentaires du système de sauvegarde MS SQL, il est plus conseillé de l'utiliser (3 types de sauvegardes sont autorisés : complète, différentielle, copie du journal des transactions ; il est possible de créer des jobs régulièrement exécutés ; une copie de sauvegarde et une copie de sauvegarde système sont rapidement déployés ; il est possible de prédire la taille de l'espace disque requis, etc.). Les principaux points d'organisation d'une sauvegarde du point de vue de la sécurité du système sont :

• La nécessité de choisir un emplacement de stockage pour les sauvegardes afin qu'elles ne soient pas accessibles aux utilisateurs.
• La nécessité de stocker les sauvegardes à distance physique du serveur MS SQL (en cas de catastrophes naturelles, incendies, attaques, etc.)
• La possibilité de donner le droit de démarrer une sauvegarde à un utilisateur qui n'a pas accès aux sauvegardes.

Pour plus de détails, veuillez vous référer à la documentation MS SQL.

Cryptage des données

Pour protéger les données contre tout accès non autorisé, divers outils cryptographiques (à la fois logiciels et matériels) sont souvent utilisés, mais leur faisabilité dépend en grande partie de l'application correcte et de la sécurité globale du système. Nous examinerons le cryptage des données à différentes étapes de la transmission et du stockage des données en utilisant les moyens les plus courants et les principales erreurs dans la conception du système à l'aide d'outils cryptographiques.

Il existe plusieurs étapes principales du traitement des informations qui peuvent être protégées :

• Transfert de données entre la partie client du système et le serveur d'applications
• Transfert de données entre le serveur d'applications et MS SQL Server
• Données stockées sur MS SQL Server (fichiers de données sur disque physique)
• Cryptage des données stockées dans le cadre de la sécurité de l'information
• Données externes (en relation avec la sécurité de l'information)

Pour les données stockées côté client et sur le serveur d'applications (paramètres utilisateur enregistrés, liste de sécurité des informations, etc.), le chiffrement n'est justifié que dans de très rares cas et n'est donc pas pris en compte ici. Lors de l’utilisation d’outils cryptographiques, il ne faut pas oublier que leur utilisation peut réduire considérablement les performances du système dans son ensemble.

Informations générales sur la protection cryptographique des connexions réseau lors de l'utilisation du protocole TCP/IP.

Sans sécurité, toutes les connexions réseau sont vulnérables à la surveillance et aux accès non autorisés. Pour les protéger, vous pouvez utiliser le cryptage des données au niveau du protocole réseau. Pour chiffrer les données transmises sur un réseau local, les outils IPSec fournis par le système d'exploitation sont le plus souvent utilisés.

Les outils IPSec assurent le cryptage des données transmises à l'aide des algorithmes DES et 3DES, ainsi qu'une vérification de l'intégrité à l'aide des fonctions de hachage MD5 ou SHA1. IPSec peut fonctionner selon deux modes : le mode transport et le mode tunnel. Le mode transport est mieux adapté pour sécuriser les connexions sur un réseau local. Le mode tunnel peut être utilisé pour organiser des connexions VPN entre des segments de réseau distincts ou pour protéger une connexion à distance à un réseau local via des canaux de données ouverts.

Les principaux avantages de cette approche sont :

• Possibilité de gestion centralisée de la sécurité à l'aide des outils Active Directory.
• La possibilité d'exclure les connexions non autorisées au serveur d'applications et au serveur MS SQL (par exemple, il est possible de se protéger contre l'ajout non autorisé d'informations de sécurité sur le serveur d'applications).
• Élimination de « l'écoute » du trafic réseau.
• Il n'est pas nécessaire de modifier le comportement des programmes d'application (dans ce cas 1C).
• Le caractère standard d’une telle solution.

Cependant, cette approche présente des limites et des inconvénients :

• IPSec ne protège pas les données contre les interférences et les écoutes clandestines directement sur les ordinateurs source et de destination.
• La quantité de données transférées sur le réseau est légèrement plus importante que sans IPSec.
• Lors de l'utilisation d'IPSec, la charge sur le processeur central est légèrement plus élevée.

Une description détaillée de la mise en œuvre des outils IPSec dépasse le cadre de cet article et nécessite une compréhension des principes de base du fonctionnement du protocole IP. Pour configurer correctement la sécurité de la connexion, veuillez lire la documentation correspondante.

Par ailleurs, il est nécessaire de mentionner plusieurs aspects du contrat de licence avec 1C lors de l'organisation des connexions VPN. Le fait est que, malgré l'absence de restrictions techniques, lors de la connexion de plusieurs segments d'un réseau local ou de l'accès à distance d'un ordinateur individuel à un réseau local, plusieurs fournitures de base sont généralement nécessaires.

Cryptage des données lors du transfert entre la partie client du système et le serveur d'applications.

En plus du cryptage au niveau du protocole réseau, il est possible de crypter les données au niveau du protocole COM+, ce qui est mentionné dans l'article « Régulation de l'accès des utilisateurs à la base d'informations dans la version client-serveur » d'ITS. Pour l'implémenter, vous devez définir le niveau d'authentification pour les appels à « Packet Privacy » pour l'application 1CV8 dans « Component Services ». Lorsqu'il est défini sur ce mode, le paquet est authentifié et crypté, y compris les données ainsi que l'identité et la signature de l'expéditeur.

Cryptage des données lors du transfert entre le serveur d'applications et MS SQL Server

MS SQL Server fournit les outils suivants pour le cryptage des données :

• Il est possible d'utiliser Secure Sockets Layer (SSL) lors du transfert de données entre le serveur d'applications et MS SQL Server.
• Lors de l'utilisation de la bibliothèque réseau multiprotocole, le cryptage des données est utilisé au niveau RPC. Il s'agit d'un cryptage potentiellement plus faible que l'utilisation de SSL.
• Si le protocole d'échange de mémoire partagée est utilisé (cela se produit si le serveur d'applications et MS SQL Server sont situés sur le même ordinateur), alors le cryptage n'est en aucun cas utilisé.

Afin d'établir la nécessité de crypter toutes les données transmises pour un serveur MS SQL spécifique, vous devez utiliser l'utilitaire "Server Network Utility". Exécutez-le et dans l'onglet "Général", cochez la case "Forcer le cryptage du protocole". La méthode de cryptage est sélectionnée en fonction de celle utilisée par l'application client (c'est-à-dire le serveur d'applications 1C). Pour utiliser SSL, vous devez configurer correctement le service de certificat sur votre réseau.

Afin de définir la nécessité de chiffrer toutes les données transmises pour un serveur d'applications spécifique, vous devez utiliser l'utilitaire "Client Network Utility" (généralement situé dans "C:\WINNT\system32\cliconfg.exe"). Comme dans le cas précédent, dans l'onglet "Général", cochez la case "Forcer le chiffrement du protocole".

Il convient de noter que l'utilisation du cryptage dans ce cas peut avoir un impact significatif sur les performances du système, en particulier lors de l'utilisation de requêtes renvoyant de grandes quantités d'informations.

Afin de mieux protéger la connexion entre le serveur d'applications et MS SQL Server lors de l'utilisation du protocole TCP/IP, nous pouvons recommander plusieurs modifications aux paramètres par défaut.

Tout d'abord, vous pouvez définir un port autre que celui standard (le port 1433 est utilisé par défaut). Si vous décidez d'utiliser un port TCP non standard pour l'échange de données, veuillez noter que :

• Le serveur MS SQL et le serveur d'applications doivent utiliser le même port.
• Lors de l'utilisation de pare-feu, ce port doit être autorisé.
• Vous ne pouvez pas définir un port pouvant être utilisé par d'autres applications sur le serveur MS SQL. Pour référence, vous pouvez utiliser http://www.ise.edu/in-notes/iana/assignments/port-numbers (adresse tirée de SQL Server Books Online).
• Lorsque vous utilisez plusieurs instances du service MS SQL Server, assurez-vous de lire la documentation MS SQL pour la configuration (section « Configuration des connexions réseau »).

Deuxièmement, dans les paramètres du protocole TCP/IP sur le serveur MS SQL, vous pouvez définir l'indicateur « Masquer le serveur », qui interdit les réponses aux demandes de diffusion pour cette instance du service MS SQL Server.

Cryptage des données MS SQL stockées sur le disque

Il existe un choix assez large de logiciels et de matériels pour crypter les données situées sur un disque local (cela inclut la capacité standard de Windows à utiliser EFS, l'utilisation de clés eToken et des programmes tiers tels que Jetico Bestcrypt ou PPGDisk). L'une des tâches principales de ces outils est de protéger les données en cas de perte de support (par exemple, lors du vol d'un serveur). Il convient particulièrement de noter que Microsoft déconseille de stocker les bases de données MS SQL sur des supports cryptés, ce qui est tout à fait justifié. Le principal problème dans ce cas est une baisse significative de la productivité et problèmes possibles fiabilité contre les pannes. Le deuxième facteur qui complique la vie de l'administrateur système est la nécessité d'assurer la disponibilité de tous les fichiers de la base de données au moment où le service MS SQL y accède pour la première fois (c'est-à-dire qu'il est souhaitable que les actions interactives soient exclues lors de la connexion d'un support crypté).

Afin d'éviter une baisse notable des performances du système, vous pouvez utiliser la capacité de MS SQL pour créer des bases de données dans plusieurs fichiers. Bien entendu, dans ce cas, la base de données MS SQL ne doit pas être créée par le serveur 1C lors de la création de l'infobase, mais doit être créée séparément. Un exemple de script TSQL avec commentaires est donné ci-dessous :

UTILISER le maître
ALLER
-- Créer une base de données SomeData,
CRÉER UNE BASE DE DONNÉES
-- dont les données se trouvent entièrement dans le groupe de fichiers PRIMARY.
SUR PRIMAIRE
-- Le fichier de données principal se trouve sur un support crypté (lecteur logique E :)
-- et a une taille initiale de 100 Mo, peut être automatiquement augmentée à 200 Mo avec
-- par incréments de 20 Mo
(NOM = QuelquesDonnées1,
NOM DE FICHIER = "E:\SomeData1.mdf",
TAILLE = 100 Mo,
TAILLE MAXIMALE = 200,
CROISSANCE DES FICHIERS = 2),
-- Le deuxième fichier de données se trouve sur un support non crypté (lecteur logique C :)
-- et a une taille initiale de 100 Mo, peut être automatiquement augmenté jusqu'à la limite
-- espace disque par incréments de 5 % de la taille actuelle du fichier (arrondi à 64 Ko)
(NOM = QuelquesDonnées2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
TAILLE = 100 Mo,
TAILLE MAX = ILLIMITÉ,
CROISSANCE DES FICHIERS = 5 %)
SE CONNECTER
-- Bien que le journal des transactions puisse également être divisé en parties, cela ne doit pas être fait,
-- parce que ce fichier change beaucoup plus fréquemment et est nettoyé régulièrement (par exemple, lorsque
-- création d'une sauvegarde de base de données).
(NOM = CertainsDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
TAILLE = 10 Mo,
TAILLE MAX = ILLIMITÉ,
CROISSANCE DES FICHIERS = 10)
ALLER
-- Il est préférable de céder immédiatement la propriété de la base de données à l'utilisateur au nom duquel
-- 1C se connectera. Pour ce faire, nous devons déclarer la base actuelle
- vient de créer,
UTILISER CertainesDonnées
ALLER
-- et exécutez sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Une brève digression sur la croissance automatique de la taille du fichier de données. Par défaut, la taille des fichiers des nouvelles bases de données est augmentée par incréments de 10 % par rapport à la taille actuelle du fichier. C'est une solution tout à fait acceptable pour les petites bases de données, mais pas très bonne pour les grandes : avec une taille de base de données de par exemple 20 Go, le fichier devrait immédiatement augmenter de 2 Go. Bien que cet événement se produise assez rarement, il peut durer plusieurs dizaines de secondes (toutes les autres transactions sont effectivement inactives pendant ce temps), ce qui, s'il se produit pendant un travail actif avec la base de données, peut provoquer des échecs. La deuxième conséquence négative de l'incrément proportionnel, qui se produit lorsque l'espace disque est presque complètement plein, est la probabilité d'une panne prématurée due à un espace libre insuffisant. Par exemple, si une partition de disque d'une capacité de 40 Go est entièrement dédiée à une base de données (plus précisément, à un fichier de cette base de données), alors la taille critique du fichier de base de données à laquelle il est nécessaire de traiter de toute urgence (très urgence, au point d'interrompre le travail normal des utilisateurs) pour réorganiser le stockage des informations est la taille du fichier de données 35 Go. Avec la taille d'incrément définie entre 10 et 20 Mo, vous pouvez continuer à travailler jusqu'à atteindre 39 Go.

Par conséquent, bien que la liste ci-dessus indique une augmentation de la taille de l'un des fichiers de base de données par incréments de 5 %, pour les bases de données de grande taille, il est préférable de définir un incrément fixe de 10 à 20 Mo. Lors de la définition des valeurs d'incrément pour l'augmentation de la taille des fichiers de base de données, il est nécessaire de prendre en compte que jusqu'à ce qu'un des fichiers d'un groupe de fichiers atteigne sa taille maximale, la règle s'applique : les fichiers d'un groupe de fichiers sont augmentés tous en même temps. moment où ils sont tous complètement remplis. Ainsi, dans l'exemple ci-dessus, lorsque le fichier SomeData1.mdf atteint sa taille maximale de 200 Mo, le fichier SomeData2.ndf aura une taille d'environ 1,1 Go.

Après avoir créé une telle base de données, même si ses fichiers non protégés SomeData2.ndf et SomeData.ldf deviennent accessibles à un attaquant, il sera extrêmement difficile de restaurer le véritable état de la base de données - les données (y compris les informations sur la structure logique de la base de données ) seront dispersés dans plusieurs fichiers et les informations clés (sur, par exemple, les fichiers qui composent cette base de données) seront dans le fichier crypté.

Bien entendu, si le stockage des fichiers de base de données à l'aide de moyens cryptographiques est utilisé, la sauvegarde (au moins de ces fichiers) ne doit pas être effectuée sur un support non crypté. Pour sauvegarder des fichiers de base de données individuels, utilisez la syntaxe de commande BACKUP DATABASE appropriée. Attention, bien qu'il soit possible de protéger une sauvegarde de base de données par un mot de passe (les options "PASSWORD = " et "MEDIAPASSWORD = " de la commande "BACKUP DATABASE"), une telle sauvegarde n'est pas cryptée !

Chiffrement des données du serveur d'applications et des clients stockées sur les disques

Dans la plupart des cas, il ne peut pas être considéré comme justifié de stocker les fichiers utilisés par 1C:Enterprise (partie client et serveur d'applications) sur des supports cryptés en raison de coûts déraisonnablement élevés. Cependant, si un tel besoin existe, veuillez noter que le serveur d'applications et la partie client de l'application créent très souvent des fichiers temporaires. Souvent, ces fichiers peuvent rester après la fin de l'exécution de l'application et il est presque impossible de garantir leur suppression à l'aide des outils 1C. Ainsi, il devient nécessaire de chiffrer le répertoire utilisé pour les fichiers temporaires dans 1C ou de ne pas le stocker sur disque à l'aide d'un lecteur RAM (cette dernière option n'est pas toujours possible en raison de la taille des fichiers générés et des besoins en RAM de 1C:Enterprise application elle-même).

Cryptage des données à l'aide des outils 1C intégrés.

Les capacités standard d'utilisation du cryptage dans 1C se résument à l'utilisation d'objets pour travailler avec des fichiers Zip avec des paramètres de cryptage. Les modes de cryptage suivants sont disponibles : algorithme AES avec une clé de 128, 192 ou 256 bits et un algorithme obsolète utilisé à l'origine dans l'archiveur Zip. Les fichiers Zip chiffrés avec AES ne sont pas lisibles par de nombreux archiveurs (WinRAR, 7zip). Pour générer un fichier contenant des données cryptées, vous devez spécifier un mot de passe et un algorithme de cryptage. L'exemple le plus simple de fonctions de chiffrement-déchiffrement basées sur cette fonctionnalité est donné ci-dessous :

Fonction EncryptData (Données, Mot de passe, Méthode de cryptage = Non défini) Exporter

// Écrit les données dans un fichier temporaire. En fait, toutes les données ne peuvent pas être sauvegardées de cette manière.
ValueInFile (TemporaryFileName, Données);

// Écrit des données temporaires dans l'archive
Zip = Nouveau ZipFileRecord (TemporaryArchiveFileName, Mot de passe, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Write();

// Lit les données de l'archive reçue dans RAM
EncryptedData = NewValueStorage(NewBinaryData(ArchiveTemporaryFileName));

// Fichiers temporaires - supprimer

Exportation de la fonction EndFunctions DecryptData (EncryptedData, Mot de passe)

// Attention! L'exactitude des paramètres transmis n'est pas surveillée

// Écrit la valeur passée dans un fichier
ArchiveTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);

// Extrait le premier fichier de l'archive qui vient d'être écrite
NomFichierTemporaire = GetTemporaryFileName();
Zip = Nouveau ReadZipFile (TemporaryArchiveFileName, Mot de passe);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Lire le fichier écrit
Données = ValueFromFile (TemporaryFileName + "\" + Zip.Items.Name);

//Supprimer les fichiers temporaires
Supprimer les fichiers (TemporaryFileName);
Supprimer les fichiers (ArchiveTemporaryFileName);

Renvoyer des données ;

FinFonction

Bien sûr, cette méthode ne peut pas être qualifiée d'idéale - les données sont écrites dans un dossier temporaire en texte clair, les performances de la méthode, franchement, sont pires que jamais, le stockage dans la base de données nécessite une quantité d'espace extrêmement importante, mais cela est la seule méthode basée uniquement sur les mécanismes intégrés de la plateforme. De plus, elle présente un avantage par rapport à de nombreuses autres méthodes : cette méthode regroupe simultanément les données avec le cryptage. Si vous souhaitez implémenter le chiffrement sans les inconvénients de cette méthode, vous devez soit les implémenter dans un composant externe, soit vous tourner vers des bibliothèques existantes via la création d'objets COM, par exemple à l'aide de Microsoft CryptoAPI. A titre d'exemple, nous donnerons les fonctions de cryptage/déchiffrement d'une chaîne en fonction du mot de passe reçu.

Fonction EncryptStringDES (UnencryptedString, Mot de passe)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2 ; // Cette constante provient de CryptoAPI

EncryptionMechanism.Content = UnencryptedString ;
Moteur de chiffrement.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES ;
EncryptedString = EncryptionMechanism.Encrypt();

renvoie une chaîne chiffrée ;

EndFunction // EncryptStringDES()

Fonction DecryptStringDES (EncryptedString, Mot de passe)

//Attention! Les paramètres ne sont pas vérifiés !

Moteur de chiffrement = Nouveau COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Mot de passe);
Tentative
EncryptionMechanism.Decrypt(EncryptedString);
Exception
// Mot de passe incorrect!;
Retourner non défini ;
FinTentative ;

ReturnEncryptionMechanism.Content ;

EndFunction // DécrypterStringDES()

Veuillez noter que lors du transfert valeur vide la saisie d'une chaîne ou d'un mot de passe dans ces fonctions générera un message d'erreur. La chaîne obtenue à l'aide de cette procédure de cryptage est légèrement plus longue que l'originale. La spécificité de ce chiffrement est que si vous chiffrez une chaîne deux fois, les chaînes résultantes ne seront PAS identiques.

Erreurs fondamentales lors de l'utilisation d'outils cryptographiques.

Lors de l’utilisation d’outils cryptographiques, les mêmes erreurs sont souvent commises :

Sous-estimation de la pénalité en termes de performances lors de l'utilisation de la cryptographie.

La cryptographie est une tâche qui nécessite un assez grand nombre de calculs (notamment pour des algorithmes tels que DES, 3DES, GOST, PGP). Et même en utilisant des algorithmes performants et optimisés (RC5, RC6, AES), il n'y a pas d'échappatoire au transfert inutile de données en mémoire et au traitement informatique. Et cela annule presque les capacités de nombreux composants du serveur (matrices RAID, cartes réseau). Lors de l'utilisation du chiffrement matériel ou de la dérivation matérielle de la clé de chiffrement, il existe un goulot d'étranglement supplémentaire en termes de performances : la vitesse de transfert des données entre le périphérique supplémentaire et la mémoire (où les performances d'un tel périphérique peuvent ne pas être critiques). Lors de l'utilisation du cryptage de petites quantités de données (par exemple, un e-mail), l'augmentation de la charge de calcul sur le système n'est pas si perceptible, mais dans le cas d'un cryptage total de tout, cela peut grandement affecter les performances du système. dans son ensemble.

Sous-estimation des capacités modernes de sélection de mots de passe et de clés.

À l'heure actuelle, les capacités de la technologie sont telles qu'une clé d'une longueur de 40 à 48 bits peut être sélectionnée par une petite organisation et une clé d'une longueur de 56 à 64 bits par une grande organisation. Ceux. des algorithmes qui utilisent une clé d'au moins 96 ou 128 bits doivent être utilisés. Mais la plupart des clés sont générées à l'aide d'algorithmes de hachage (SHA-1, etc.) basés sur les mots de passe saisis par l'utilisateur. Dans ce cas, une clé d'une longueur de 1024 bits peut ne pas aider. Premièrement, un mot de passe facile à deviner est souvent utilisé. Les facteurs qui facilitent la sélection sont : l'utilisation d'une seule casse de lettres ; utilisation de mots, de noms et d'expressions dans les mots de passe ; utilisation de dates connues, d'anniversaires, etc. ; utiliser des « modèles » lors de la génération de mots de passe (par exemple, 3 lettres, puis 2 chiffres, puis 3 lettres dans toute l'organisation). Un bon mot de passe doit être une séquence assez aléatoire de lettres majuscules, de chiffres et de signes de ponctuation. Les mots de passe saisis au clavier comportant jusqu'à 7 à 8 caractères, même si ces règles sont suivies, peuvent être devinés dans un délai raisonnable, il est donc préférable que le mot de passe contienne au moins 11 à 13 caractères. La solution idéale est d'éviter de générer une clé à l'aide d'un mot de passe, par exemple à l'aide de diverses cartes à puce, etc., mais dans ce cas il faut prévoir la possibilité de se protéger contre la perte du support de clé de chiffrement.

Stockage non sécurisé des clés et des mots de passe.

Des exemples courants de cette erreur sont :

• des mots de passe longs et complexes écrits sur des notes autocollantes collées sur le moniteur de l’utilisateur.
• stocker tous les mots de passe dans un fichier qui n'est pas protégé (ou qui est beaucoup plus faible que le système lui-même)
• stockage de clés électroniques dans le domaine public.
• transfert fréquent de clés électroniques entre utilisateurs.

Pourquoi réaliser une porte blindée si la clé de celle-ci se trouve sous le paillasson ?

Transfert de données initialement cryptées vers un environnement non sécurisé.

Lors de la mise en place d’un système de sécurité, assurez-vous qu’il fait son travail. Par exemple, j'ai rencontré une situation (non liée à 1C) où un fichier initialement crypté, lorsque le programme s'exécutait sous forme claire, était placé dans un dossier temporaire, à partir duquel il pouvait être lu en toute sécurité. Souvent, les copies de sauvegarde des données cryptées sous forme claire se trouvent quelque part « non loin » de ces données.

Utilisation d'outils cryptographiques à d'autres fins

En chiffrant les données en transit, vous ne pouvez pas vous attendre à ce qu'elles soient inaccessibles là où elles sont utilisées. Par exemple, les services IPSec n'empêchent en aucun cas le serveur d'applications de « renifler » le trafic réseau au niveau de l'application.

Ainsi, pour éviter les erreurs lors de la mise en œuvre de systèmes cryptographiques, vous devez (au minimum) procéder comme suit avant de le déployer.

• Découvrir:
  • Que faut-il protéger ?
  • Quelle méthode de protection utiliser ?
  • Quelles parties du système doivent être sécurisées ?
  • Qui contrôlera l’accès ?
  • Le cryptage fonctionnera-t-il dans tous les bons domaines ?
• Déterminez où les informations sont stockées, comment elles seront envoyées sur le réseau et les ordinateurs à partir desquels les informations seront accessibles. Cela fournira des informations sur la vitesse, la capacité et l’utilisation du réseau avant la mise en œuvre du système, ce qui est utile pour optimiser les performances.
• Évaluez la vulnérabilité du système à différents types d’attaques.
• Élaborer et documenter un plan de sécurité du système.
• Évaluer l’efficacité économique (justification) de l’utilisation du système.

Conclusion

Bien entendu, dans un examen rapide, il est impossible d'indiquer tous les aspects liés à la sécurité dans 1C, mais permettons-nous de tirer quelques conclusions préliminaires. Bien sûr, cette plate-forme ne peut pas être qualifiée d'idéale - elle, comme beaucoup d'autres, a ses propres problèmes pour organiser un système sécurisé. Mais cela ne signifie en aucun cas que ces problèmes ne peuvent être contournés ; au contraire, presque toutes les lacunes peuvent être éliminées grâce à un développement, une mise en œuvre et une utilisation appropriés du système. La plupart des problèmes surviennent en raison du développement insuffisant d'une solution applicative spécifique et de son environnement d'exécution. Par exemple, des solutions standards sans changements significatifs n'impliquent tout simplement pas la création d'un système suffisamment sécurisé.

Cet article démontre une fois de plus que tout ensemble de mesures de sécurité doit couvrir toutes les étapes de mise en œuvre : développement, déploiement, administration du système et, bien sûr, mesures organisationnelles. Dans les systèmes d’information, c’est le « facteur humain » (y compris les utilisateurs) qui constitue la principale menace pour la sécurité. Cet ensemble de mesures doit être raisonnable et équilibré : cela n’a aucun sens et il est peu probable que des fonds suffisants soient alloués pour organiser une protection qui dépasse le coût des données elles-mêmes.

Entreprise est un service unique pour les acheteurs, les développeurs, les revendeurs et les partenaires affiliés. De plus, il s'agit de l'un des meilleurs magasins de logiciels en ligne de Russie, d'Ukraine et du Kazakhstan, qui propose aux clients une large gamme de produits, de nombreux modes de paiement, un traitement rapide (souvent instantané) des commandes et un suivi du processus de commande dans une section personnelle. .