1c вградено препълване на езиков стек. Препълване на стека

14.04.2016 г. Версия 3.22 Променен е интерфейсът, коригирани са грешки при прехвърляне на регистри, променена е процедурата за прехвърляне на организация и счетоводни политики. Платформа 8.3.7.2027 BP 3.0.43.174
17.03.2016 Версия 3.24 Забелязаните грешки са коригирани. Платформа 8.3.8.1747 BP 3.0.43.241
16.06.2016 Версия 3.26 Забелязаните грешки са коригирани. Платформа 8.3.8.2088 BP 3.0.44.123
16.10.2016 г. Версия 4.0.1.2 Коригирано прехвърляне на съхранение на стойност, променено прехвърляне на счетоводна политика за версии 3.44.*. Платформа 8.3.9.1818 BP 3.0.44.164.
19.04.2017 г. Версия 4.0.2.7 Алгоритъмът за прехвърляне на регистри, свързани с директории, е променен, забелязаните грешки са коригирани, прехвърлянето с презаписване на връзки е коригирано.
29.05.2017 г. Версия 4.0.4.5 Променено прехвърляне на движения, добавен преглед на движенията на прехвърлени документи, нещо друго...
30.05.2017 г. Версия 4.0.4.6 Коригирана грешка при попълване на списъка със съществуващи директории в източника (благодаря, скромно)
17.06.2017 Версия 4.0.5.1 Алгоритъмът за прехвърляне на движения е променен.
19.07.2017 г. Версия 4.0.5.4 Прехвърлянето на CI от BP 2.0 е променено. Неочаквано прехвърлянето от UT 10.3 беше извършено от Smilegm, в тази версия прехвърлянето беше леко коригирано за тази ситуация)))
08/10/2017 Версия 4.0.5.5 Коригирани грешки при прехвърляне от BP 2.0
19.09.2017 Версия 4.4.5.7 Фиксирана проверка на връзката за 3.0.52.*
28.11.2017 г. Версия 4.4.5.9 Коригирани докладвани грешки
12/06/2017 Версия 5.2.0.4 Алгоритъмът за търсене на връзки е преработен. Добавени са процедури за прехвърляне от BP 1.6; вече няма строга връзка с BP - можете лесно да го използвате за прехвърляне на данни с „почти“ идентични конфигурации. Ще се опитам да коригирам всички коментари своевременно.
12/08/2017 Версия 5.2.1.3 Добавен алгоритъм за прехвърляне на отчети за заплати от BP.2.0 към BP 3.0. Включени промени за споделяне между идентични конфигурации.
19.12.2017 г. Версия 5.2.2.2 Коригирано е прехвърлянето на независими информационни регистри за директории, които са в размерите на тези регистри.

12/06/2017 Нова обработка версия 5.2.0.4. Сред съществените промени е възможността за прехвърляне от BP 1.6 към BP 3.0. Основната промяна е управлението на търсенето на връзки към директория - в предишните версии търсенето беше по GUID, но в тази версия можете да активирате търсенето "По подробности":

17.01.2018 Версия 5.2.2.3 Коригирани - забелязани грешки в подчинени справочници и периодични информационни регистри.

19.07.2018 Версия 5.2.2.8 Забелязаните грешки са коригирани.

в който можете да зададете подробности за търсене за всяка директория. Самият този режим „възникна“ по многобройни искания на работници, за случаите, когато е необходим обмен във вече съществуваща база данни, която вече има данни (например за обединяване на счетоводни записи за две организации в една база данни).

21.12.2015 Платформа 8.3.7.1805 и BP 3.0.43.29 бяха пуснати съответно нова версияобработка 3.1:-) (описание по-долу). Нова функционалност - възможност за сравняване на салда и обороти между две бази данни на BP (за всички сметки, ако сметкопланите съвпадат, или за отделни съвпадащи счетоводни сметки, с или без анализ).
01/03/2016 Версия 3.5 - механизмът за свързване към изходната база е променен - ​​приведен в съответствие с BSP 2.3.2.43. Отстранени незначителни грешки. Платформа 8.3.7.1845, BP 3.0.43.50
16.02.2016 г. Версия 3.6 - Добавен е флагът „Задаване на ръчна корекция“ за документи, прехвърлени с движения. Фиксиран трансфер на движения - документи с дата по-малка от началото на периода се прехвърлят без движения. Платформа 8.3.7.1917, BP 3.0.43.116
22.03.2016 г. Версия 3.10 - Добавен е флагът „Винаги презаписвайте препратките“ за задължително пренаписване на референтни обекти (скоростта на трансфер е значително намалена, но понякога е необходимо). Добавен е разделът „Подготовка“, където можете да конфигурирате съответствието на изходните и целевите диаграми на сметки (на същото ниво като кодовете на сметки) и прехвърлянето на константи. Платформа 8.3.7.1970 г., BP 3.0.43.148

03.04.2016 г. Версия 3.11 Попълването на списъка с документи, съществуващи в източника, е променено: попълва се по движения според сметкоплана, става само чрез връзки за периода, точно както в // сайт/публично/509628/

Обработката е предназначена за прехвърляне на данни за произволен период по същия начин като „Качване на MXL“ с ITS, само без използване на XML, JSON и други междинни файлове - обмен от база данни към база данни чрез COM. Във версии по-стари от 3.10 връзката се използва чрез алгоритъм от BSP, който осигурява регистрация на comcntr.dll (ако ОС „позволява“), както и различни съобщения, когато е невъзможно да се установи връзка, за пример - „Информационната база е в процес на актуализиране“ и др. Добавена е проверка за избор на приемник като източник на IS - издава се предупреждение.

Може да се използва за:

1. Прехвърляне на нормативна справочна информация (RNI) от източника на IS до местоназначението на IS (прехвърлянето на цялата справочна информация се извършва по искане на потребителя, необходимите справочници и т.н. се прехвърлят чрез връзки по време на всякакви трансфери).

2. Прехвърляне на документи за избран период.

3. Прехвърляне на цялата информация от „счупена“ система за информационна сигурност, ако тя е стартирана в режим 1C:Enterprise и качването на данни или стартирането на конфигуратора е невъзможно.

Особеност на обработката - информационната сигурност на приемника и източника може да е различна; прехвърляне от 2.0 на 3.0 - изданията са различни, но прехвърлянето работи!!! Несъответстващите детайли се игнорират или за тях трябва да бъдат посочени алгоритми за прехвърляне.

коментар: Преобразуването на данни НЕ СЕ ИЗПОЛЗВА! И не питайте защо!!! За тези, които са особено придирчиви - BP 3.0 се променя почти всеки ден, вече няма сила да поддържате правилата за прехвърляне актуални - тук всичко е по-просто :-).

Друга особеност на обработката е, че тя се стартира в информационната сигурност на приемника (най-близките по функционалност аналози работят обратното - от източника към приемника).

Първи стъпки - трябва да посочите периода на обработка, да посочите организацията от източника, тя ще бъде прехвърлена към местоназначението.

При прехвърляне на организация се прехвърлят счетоводните политики и „свързаните“ информационни регистри. Следователно, когато за първи път изберете организация в източника, ще мине известно време, преди тя да се появи в приемника.

Сметкопланите на източника и местоназначението трябва да са еднакви, никакви различни сметки във версии 2.* не се прехвърлят към местоназначението, планира се да се даде възможност за коригиране на съвпадащи сметки и анализи в бъдеще. Акаунтите се прехвърлят с кодове, които не се намират в приемника НЕ ​​МОГАТ ДА БЪДАТ СЪЗДАДЕНИ!!!

Останалите обекти се прехвърлят с помощта на вътрешни идентификатори (GUID), така че трябва да обърнете внимание на някои ключови директории, например - Валути.

Ако планирате да обменяте с „чиста“ база данни, тогава е по-добре да изтриете директориите, попълнени при първото стартиране преди обмена. Защо има страница в обработката, където можете да получите тези елементи на директория и да ги изтриете. Най-малко трябва да премахнете валутата "rub". - защото дублирането е почти неизбежно (по принцип това лесно се коригира след споделяне на търсенето и подмяната на дубликати, вградени в BP 3.0).

Обработката предвижда извикване на страницата за изтриване на директория, когато първоначалната форма за попълване е отворена:

Когато отворите обработка, ще се покаже страница за изтриване на директории, попълнени при първоначалното попълване:

От версия 3.22 интерфейсът е променен, сега всички подготвителни операции са табирани и винаги са налични

Важно е да проверите съответствието на сметкоплана на източника и получателя и не забравяйте да посочите съответствието на сметките.

Няма нужда да изтривате предварително дефинирани елементи на директория - те се прехвърлят чрез конфигурационни идентификатори (не GUID).

Можете да изберете обекти за прехвърляне с помощта на формата за избор от директории и документи (информационните регистри, свързани с тези обекти, ще бъдат прехвърлени автоматично, така че няма нужда да ги избирате отделно).Прехвърляне на регистри, намаляването е временно деактивирано - трябва да разработите списък с регистри за прехвърляне - нещо трябва да бъде прехвърлено, нещо не трябва, на този етап е достатъчно какво се прехвърля в указателите, списъкът с регистри за прехвърляне ще бъде в шаблона в бъдещите версии.

При обмен с 2.0 някои от детайлите (напр. Информация за връзка) се прехвърля според вградения в обработката алгоритъм, т.к за 2.0 и 3.0 те се съхраняват по различен начин. Подобна е ситуацията с редица документи (например Корекция на дълга).

Списъкът с типове обекти може да бъде попълнен по различен начин във версия 3.22, това е поставено в подменю, промените са показани на снимката:

Има опростяване на използването на обработката - не можете да избирате директории за обмен, а просто да попълните списъка с типове в приемника само с онези типове директории, които имат поне един запис в източника.

Обработката има вградено оформление, което изброява директории, които не е необходимо да се прехвърлят от източника към местоназначението (оформлението „Изключване от прехвърляне“). Можете да добавите (премахнете) всякакви директории към това оформление. Ако не е необходимо да прехвърляте всички референтни данни, достатъчно е да прехвърлите документите, чийто списък може да бъде получен и без да избирате типове, просто попълнете всички изходни документи, за които съществуват транзакции.

Осигурено е прехвърляне на документи с движения; за обмен 3.0 на 3.0 и кореспонденция на сметкопланове работи едно към едно; при обмен на 2.0 на 3.0 са възможни грешки, така че се препоръчва да се прехвърлят документи без движения и след това просто ги прехвърлете на приемника. При прехвърляне на документи с движения се поставя флагът „Ръчна настройка“.

Атрибутът „Публикувано“ е зададен в документите на получателя по същия начин, както в източника, но движенията (ако не са прехвърлени) ще се появят само след като документите бъдат обработени, например, като се използва обработката, вградена в BP 3.0 Групово осчетоводяване на документи (препоръчителна опция) или от тази обработка (тук има бутон „Публикуване на документи“).

Ако обработката е планирана да се използва за постоянен обмен, тя може да бъде регистрирана в информационната сигурност на получателя (бутон „Регистрация“). За „еднократни“ трансфери можете просто да го използвате чрез File - Open.

21.12.2015 г. - Версия 3.1 платформа 8.3.7.1805 и захранващ блок 3.0.43.29 (версия 2.15 за 3.0.43.* не работи - конфигурацията е сменена доста).

Променено:

Диалог за избор на опция за връзка, флагът Клиент-сървър е винаги наличен, в зависимост от настройката му, или избор на папка на файлова база данни, или поле с името на базата данни на сървъра и името на самия сървър е наличен (бъг в диалоговия прозорец версия 2.15 е коригиран)

- НОВА ФУНКЦИОНАЛНОСТ: Механизъм за съгласуване на салда и оборот между базата данни източник и получател в различна степен на детайлност:

Мисля, че изборът на опции за проверка е ясен от фигурата:

Има разлики в използването на тънкия и дебелия клиент - в дебелия клиент веднага се показва прозорец за сравнение на файлове:

В тънкия клиент не се занимавах с програмно натискане на бутони; предлагам проста опция за показване на прозорец за сравнение:

Сравнението в тънък клиент, IMHO, е по-удобно, защото... има бутони за навигация за разликите, което е по-удобно за големи таблици, отколкото скролиране с мишката:

22.03.2016 г. Версия 3.10 - Добавен е флагът „Винаги презаписвайте препратките“ за задължително пренаписване на референтни обекти (скоростта на трансфер е значително намалена, но понякога е необходимо). Добавен е разделът „Подготовка“, където можете да конфигурирате съответствието на изходните и целевите диаграми на сметки (на същото ниво като кодовете на сметки) и прехвърлянето на константи. Платформа 8.3.7.1970 г., BP 3.0.43.148

- НОВА ФУНКЦИОНАЛНОСТ:Преди да прехвърлите документи, се препоръчва да проверите сметкоплана за последователност в източника и местоназначението, както и съответствие с установените константи.

За целта е добавен раздел “Подготовка”, в който можете да зададете следните съответствия:

Алгоритъмът за попълване на таблицата за съпоставяне на сметки е прост - анализира се оборотът, съществуващ в източника, и за всяка сметка, намерена там, се намира съвпадение в приемника по код; ако съвпадение не бъде намерено, ред със сметката в таблицата се показва код, чрез който трябва да изберете акаунта на получателя, той ще се използва при прехвърляне. Съответствието с Poke е установено на ниво код.

За проверка и прехвърляне на съответствието на установените константи се използва съответната таблица:

Попълваме го и го прехвърляме, ако е необходимо. Прехвърлят се само константи, маркирани с флага...

Програмният стек е специална област от паметта, организирана според принципа на опашката LIFO (последен влязъл, първи излязъл). Името "стек" идва от аналогията на принципа на изграждането му с купчина плочи - можете да поставите плочи една върху друга (методът на добавяне към стека, "натискане", "натискане"), а след това вземете ги, като започнете отгоре (метод за получаване на стойност от стека, "изскачане", "изскачане"). Програмният стек се нарича още стек за извикване, стек за изпълнение или стек на машина (за да не го бъркате със "стека" - абстрактна структура от данни).

За какво е стек? Тя ви позволява удобно да организирате извикването на подпрограми. При извикване функцията получава някои аргументи; трябва също така да съхранява своите локални променливи някъде. Освен това трябва да вземем предвид, че една функция може да извика друга функция, която също трябва да предава параметри и да съхранява своите променливи. Използвайки стека, когато предавате параметри, просто трябва да ги поставите в стека, след което извиканата функция може да ги „извади“ от там и да ги използва. Там могат да се съхраняват и локални променливи – в началото на кода си функцията заделя част от паметта на стека, а когато контролът се върне, я изчиства и освобождава. Програмистите на езици от високо ниво обикновено не мислят за такива неща - компилаторът генерира целия необходим рутинен код за тях.

Последици от грешка

Сега сме почти близо до проблема. Абстрактно, стекът е безкрайно хранилище, в което нови елементи могат да се добавят безкрайно. За съжаление, в нашия свят всичко е ограничено - и стековата памет не е изключение. Какво се случва, ако приключи, когато аргументите на функцията бъдат избутани в стека? Или функцията разпределя памет за своите променливи?

Ще възникне грешка, наречена препълване на стека. Тъй като стекът е необходим за организиране на извикването на дефинирани от потребителя функции (и почти всички програми на съвременните езици, включително обектно-ориентираните, са изградени на базата на функции по един или друг начин), те вече няма да могат да бъди наречен. Следователно операционната система поема контрола, изчиства стека и прекратява програмата. Тук можем да подчертаем разликата между препълване на стека и препълване на стека - в първия случай възниква грешка при достъп до неправилна област на паметта и ако няма защита на този етап, тя не се проявява в този момент - при успешен комбинация от обстоятелства, програмата може да работи нормално. Ако само паметта, до която се осъществява достъп, беше защитена, . В случай на стек, програмата със сигурност се прекратява.

За да бъдем напълно точни, трябва да се отбележи, че такова описание на събитията е вярно само за компилатори, които компилират към естествен код. В управляваните езици виртуалната машина има собствен стек за управлявани програми, чието състояние е много по-лесно за наблюдение и дори можете да си позволите да хвърлите изключение към програмата, когато възникне препълване. В езиците C и C++ не можете да разчитате на такъв „лукс“.

Причини за грешката

Какво може да доведе до такава неприятна ситуация? Въз основа на механизма, описан по-горе, една възможност е, че има твърде много вложени извиквания на функции. Този сценарий е особено вероятен при използване на рекурсия. Безкрайната рекурсия (при липса на мързелив механизъм за оценка) се прекъсва по този начин, за разлика от , което понякога има полезни приложения. Въпреки това, с малко количество памет, разпределено за стека (което например е типично за микроконтролерите), проста последователност от извиквания може да бъде достатъчна.

Друг вариант са локалните променливи, които изискват много памет. Да имате локален масив от милион елемента или милион локални променливи (никога не знаете какво ще се случи) не е най-добрата идея. Дори едно извикване на такава алчна функция може лесно да причини препълване на стека. За да получите големи количества данни, е по-добре да използвате механизми за динамична памет, които ще ви позволят да се справите с грешката от липсата им.

Динамичната памет обаче е доста бавна по отношение на разпределението и освобождаването (тъй като операционната система се справя с това) и при директен достъп трябва ръчно да я разпределяте и освобождавате. Паметта в стека се разпределя много бързо (всъщност просто трябва да промените стойността на един регистър); в допълнение, обектите, разпределени в стека, имат автоматично извиквани деструктори, когато контролът на функцията се върне и стекът се изчисти. Разбира се, веднага възниква желанието да получите памет от стека. Следователно, третият начин за препълване е собственото разпределение на паметта на стека от програмиста. Библиотеката C предоставя функцията alloca специално за тази цел. Интересно е да се отбележи, че ако функцията за разпределяне на динамична памет malloc има свой собствен „близнак“ за освобождаването й, free, тогава функцията alloca го няма - паметта се освобождава автоматично след връщане на контрола върху функцията. Може би това само усложнява ситуацията - в края на краищата няма да е възможно да освободите паметта, преди да излезете от функцията. Въпреки че, според страницата на ръководството, "функцията alloca зависи от машината и компилатора; на много системи нейното внедряване е проблематично и с грешки; използването й е много несериозно и не се приема с намръщение" - тя все още се използва.

Примери

Като пример, нека да разгледаме кода за рекурсивно търсене на файлове, намиращ се в MSDN:

Void DirSearch(String* sDir) ( try ( // Намерете подпапките в папката, която е предадена. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0;i< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Текст); int numFiles = f->get_Length(); за (int j=0; j< numFiles; j++) { listBox1->Елементи->Добавяне(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox::Show(e->Message); ) )

Тази функция получава списък с файлове в посочената директория и след това се извиква за онези елементи от списъка, които случайно са директории. Съответно, с достатъчно дълбоко дърво файлова система, получаваме естествен резултат.

Пример за втория подход, взет от въпроса "Защо се случва препълване на стека?" от сайт, наречен Stack Overflow (сайтът е колекция от въпроси и отговори по всяка програмна тема, а не само Stack Overflow, както може да изглежда):

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

Както можете да видите, основната функция разпределя памет в стека за масиви от типове int и float, всеки с милион елемента, което общо дава малко по-малко от 8 мегабайта. Ако смятате, че по подразбиране Visual C++ запазва само 1 мегабайт за стека, тогава отговорът става очевиден.

И ето един пример, взет от хранилището на GitHub на проекта Lightspark Flash player:

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

Можете да се надявате, че h.getLength()-7 не е твърде голямо число, така че да няма препълване на следващия ред. Но спестеното време за разпределяне на памет струва ли си „потенциалния“ срив на програмата?

Долен ред

Препълването на стека е фатална грешка, която най-често засяга програми, съдържащи рекурсивни функции. Въпреки това, дори ако програмата не съдържа такива функции, все още е възможно препълване поради големия размер на локалните променливи или грешка при ръчното разпределение на паметта в стека. Всички класически правила остават в сила: ако има избор, по-добре е да изберете итерация вместо рекурсия и също така не правете ръчна работа вместо компилатора.

Библиография

• Е. Таненбаум. Компютърна архитектура.
• Уикипедия. Препълване на стека.
• Препълване на стека. Препълване на стека C++.

Стекът, в този контекст, е последният в първия буфер, който разпределяте по време на изпълнението на вашата програма. Последно, първо (LIFO) означава, че последното нещо, което поставите винаги е първото нещо, което изскочите обратно - ако извадите 2 елемента от стека, „A“ и след това „B“, тогава първото нещо, което изскочите от стека ще бъде "B", а следващото нещо ще бъде "A".

Когато извикате функция във вашия код, следващата команда след извикването на функцията се съхранява в стека и всяко пространство в паметта, което може да бъде презаписано от извикването на функцията. Избраната функция може да използва повече стек за собствените си локални променливи. Когато това бъде направено, ще освободи пространството на локалната променлива, което е използвало, и след това ще се върне към предишната функция.

Препълване на стека

Препълване на стека е, когато сте използвали повече памет в стека, отколкото вашата програма е предвидила да използва. На вградени системи може да имате само 256 байта за стека и ако всяка функция заема 32 байта, тогава можете да имате само 8 извиквания на функция към функция 2 с дълбока функция на функция 1, която извиква функция 3, която извиква функция 4. ..който извиква функция 8, която извиква функция 9, но функция 9 презаписва паметта извън стека. Това може да презапише паметта, кода и т.н.

Много програмисти правят тази грешка, като извикват функция A, която след това извиква функция B, която след това извиква функция C, която след това извиква функция A. Може да работи през повечето време, но само един грешен вход ще го накара да се върти в кръг завинаги, докато компютърът fails открива, че стекът е пълен.

Рекурсивните функции също са причина за това, но ако пишете рекурсивно (т.е. вашата функция се извиква сама), тогава трябва да сте наясно с това и да използвате статични/глобални променливи, за да предотвратите безкрайна рекурсия.

Обикновено операционната система и езикът за програмиране, които използвате, управляват стека и той е извън вашите ръце. Трябва да погледнете графиката на извикванията си (дървовидна структура, която показва от вашата основна точка какво извиква всяка функция), за да видите колко дълбоки са извикванията на вашите функции и да идентифицирате цикли и рекурсия, които не са предвидени. Умишлените цикли и рекурсията трябва да бъдат изкуствено проверени за грешки, ако се извикват един друг твърде много пъти.

Освен добрите практики за програмиране, статичното и динамичното тестване, не можете да направите много в тези системи от високо ниво.

Вградени системи

В света на вградените системи, особено в кода с висока степен на сигурност (автомобилна, аерокосмическа, аерокосмическа), вие извършвате обширни тестове и преглед на кода, но също така правите следното:

• Деактивиране на рекурсия и цикли - съответствие с политиката и тестването
• Съхранявайте кода и стека далеч един от друг (код във флаш, стек в RAM и никога няма да съвпадат един с друг)
• Поставете предпазни ленти около стека - празна област от паметта, която запълвате с магическо число (обикновено процедурата за прекъсване, но тук има много варианти) и стотици или хиляди пъти в секунда гледате предпазните ленти, за да направите със сигурност не са презаписани.
• Използвайте защита на паметта (т.е. не изпълнявайте на стека, не четете или пишете директно зад стека)
• Прекъсванията не извикват вторични функции - те задават флагове, копират данни и оставят приложението да се погрижи за обработката им (в противен случай може да се окажете 8 дълбоко в дървото на повикванията на функциите, да имате прекъсване и след това да имате още няколко функции вътре изходът на прекъсването, причинявайки хвърляне). Имате няколко дървета на повикванията - едно за основните процеси и едно за всяко прекъсване. Ако вашите прекъсвания могат да се прекъсват взаимно... е, има дракони...

Езици и системи от високо ниво

Но на езици от високо ниво, работещи на операционни системи:

• Намалете съхранението на локални променливи (локалните променливи се съхраняват в стека), въпреки че компилаторите са доста умни по отношение на това и понякога ще поставят големи парчета в купчината, ако вашето дърво на повикванията е плитко)
• Избягвайте или строго ограничавайте рекурсията
• Не прекъсвайте програмите си твърде много във все по-малки и по-малки функции - дори без да се вземат предвид локалните променливи, всяко извикване на функция консумира до 64 байта в стека (32-битов процесор, запазвайки половината от регистрите на процесора, флаговете и т.н.).
• Поддържайте дървото на повикванията плитко (подобно на описанието по-горе)

Уеб сървъри

Зависи от пясъчника, който имате, дали можете да контролирате или дори да видите стека. Вероятно можете да се справите с уеб сървърите като всеки друг език и операционна система на високо ниво - до голяма степен е извън вашите ръце, но проверете езика и сървърния стек, който използвате. Например, можете да разделите стека на вашия SQL сървър.

Ръководството за програмист на Informix® DataBlade™ API е достъпно за изтегляне. Разделът „Управление на стеково пространство“ описва създаването на дефинирани от потребителя функции (UDR). Тази статия предоставя допълнителна информация и съвети за отстраняване на грешки.

Следната информация се прилага независимо дали UDR работи на дефиниран от потребителя виртуален процесор (VP) или на VP CPU. Стекът на нишката може да бъде преместен към дефиниран от потребителя виртуален процесор непосредствено преди изпълнението на UDR.

Какъв размер на стека е разпределен за UDR?

Размерът на стека, достъпен за UDR, зависи от това как е създаден UDR:

използвайки модификатора STACK, който позволява на UDR да използва своя специално разпределен стек,

без модификатора STACK, което означава, че UDR ще сподели стека, разпределен от сървъра, с нишката, която прави заявката. Размерът на стека в този случай ще се определя от стойността на параметъра STACKSIZE в конфигурационния файл onconfig.

Модификатор STACK

Операторите CREATE PROCEDURE или CREATE FUNCTION имат незадължителен модификатор STACK, който ви позволява да укажете количеството стеково пространство в байтове, което е необходимо за изпълнение на UDR.

Ако използвате модификатора STACK, когато създавате UDR, сървърът ще разпределя и освобождава стеково пространство всеки път, когато UDR се изпълнява. Действителният наличен размер е равен на стойността на STACK в байтове минус някои допълнителни разходи в зависимост от броя на аргументите на функцията.

Ако стойността на STACK е по-малка от параметъра STACKSIZE във файла onconfig (вижте следващия раздел), тогава размерът на стека, определен за UDR, ще бъде автоматично закръглен до стойността STACKSIZE.

Конфигурационен параметър STACKSIZE

Конфигурационният файл onconfig включва параметър STACKSIZE, който определя размера на стека по подразбиране за потребителски нишки.

Ако не укажете STACK, когато създавате UDR, сървърът не разпределя допълнително пространство в стека за изпълнение на това UDR. Вместо това UDR използва пространството на стека, разпределено за изпълнение на заявката. Наличният размер на стека ще зависи от режийните разходи за изпълнение на функцията на ниво SQL.

Стекът за нишка се разпределя веднъж за конкретната нишка, изпълняваща заявката. Производителността е по-добра, когато UDR споделя един стек с нишка, тъй като сървърът не губи ресурси за разпределяне на допълнителен стек за всяко UDR извикване. От друга страна, ако размерът на стека, използван от UDR, се доближава до стойността на STACKSIZE, това може да причини препълване на стека при извикване на функцията като част от сложна заявка (в който случай ще бъде налично по-малко пространство в стека за изпълнение на UDR).

Моля, обърнете внимание, че не трябва да задавате твърде висока стойност на STACKSIZE, тъй като това ще засегне всички потребителски нишки.

Кога е необходимо да се контролира размера на стека?

Трябва да управлявате стековото пространство, ако UDR прави рекурсивни извиквания или ако UDR изисква повече стеково пространство, отколкото е налично по подразбиране в стека на нишката на заявката (STACKSIZE).

Има два начина за увеличаване на стека за UDR изпълнение:

Посочете модификатора STACK, когато създавате UDR.

Използвайте mi_call(), за да правите рекурсивни повиквания (вижте Ръководството на програмиста на Informix DataBlade API за пример).

Ако не посочите размер чрез STACK и ако не използвате mi_call() за увеличаване на текущия стек и ако UDR направи нещо, което изисква много място в стека, това ще доведе до препълване на стека.

Обърнете внимание, че някои функции mi_* добавят нов сегмент на стека за собствено изпълнение. Тези сегменти се освобождават при връщане към извикващата UDR функция.

Какво да направите, ако нещо се обърка?

Мониторинг на използването на стека

Целта на наблюдението е да се идентифицира конкретният UDR, който причинява препълването на стека, така че да можете да промените стойността на STACK специално за този конкретен UDR.

Наблюдение на използването на стека с командата "onstat -g sts".

Наблюдение на сесия, изпълняваща SQL заявка с помощта на "onstat -g ses session_id"

След като идентифицирате SQL заявка, която завършва с препълване на стека, трябва да определите използването на стека чрез отделно изпълнение на UDR заявките, които са част от оригиналната заявка.

Можете динамично да зададете стойността STACK за UDR. Например:

променя функцията MyFoo (lvarchar,lvarchar) с (добавяне на стек=131072);

След като промените стойността на STACK, трябва да тествате оригиналната заявка, за да сте сигурни, че вече е стабилна.

Увеличете STACKSIZE

Друга възможност е да опитате да увеличите стойността на STACKSIZE. Проверете дали това решава проблема. (Не забравяйте да върнете старата стойност по-късно).

Ако увеличаването на STACKSIZE не помогне, проблемът най-вероятно е повреда в паметта. Ето няколко предложения:

Разрешете драскане на паметта и проверка на пул памет. Разделът „Проблеми с отстраняване на грешки“ в статията Разпределяне на памет за UDR обяснява как да направите това.

Преразгледайте използването на mi_lvarchar. Особено внимание трябва да се обърне на местата, където mi_lvarchar се предава на функция, която очаква да получи като аргумент низ, завършващ с нула.

Намалете броя на VP на процесора (или потребителя) до един, за да възпроизведете проблема по-бързо.

mi_print_stack() -- Solaris

Informix Dynamic Server за Solaris OS включва функция mi_print_stack(), която може да бъде извикана в UDR. По подразбиране тази функция записва рамката на стека в следния файл:

/tmp/default.stack

Не можете да промените името на изходния файл, но можете да промените местоположението му, като промените стойността на променливата на средата DBTEMP. Уверете се, че директорията $DBTEMP може да се записва от потребителя на informix. Всички грешки, възникнали при изпълнението на mi_print_stack(), се докладват на $MSGPATH.

Тази функция е достъпна само за OC Solaris.

Терминологичен речник

Термини и съкращения, използвани в тази статия:

UDR	Дефинирана от потребителя рутина
В.П.	Виртуален процесор

Тази статия още веднъж демонстрира, че всеки набор от мерки за сигурност трябва да обхваща всички етапи на внедряване: разработка, внедряване, администриране на системата и, разбира се, организационни мерки. В информационните системи „човешкият фактор“ (включително потребителите) е основната заплаха за сигурността. Този набор от мерки трябва да бъде разумен и балансиран: няма смисъл и е малко вероятно да бъдат отделени достатъчно средства за организиране на защита, която надвишава цената на самите данни.

Въведение

1C:Enterprise е най-разпространената счетоводна система в Русия, но въпреки това до версия 8.0 нейните разработчици обърнаха много малко внимание на проблемите със сигурността. Основно, разбира се, това беше продиктувано от ценовата ниша на продукта и фокуса върху малкия бизнес, където няма квалифицирани ИТ специалисти и възможните разходи за внедряване и поддръжка на сигурна система биха били непосилни за предприятието. С пускането на версия 8.0 акцентът трябваше да се промени: цената на решенията се увеличи значително, системата стана много по-мащабируема и гъвкава - изискванията се промениха значително. Дали системата е станала достатъчно надеждна и сигурна е много индивидуален въпрос. Основната информационна система на едно модерно предприятие трябва да отговаря най-малко на следните изисквания за сигурност:

• Доста ниска вероятност от повреда на системата поради вътрешни причини.
• Надеждна авторизация на потребителите и защита на данните от неправилни действия.
• Ефективна система за предоставяне на потребителски права.
• Онлайн система за архивиране и възстановяване в случай на повреда.

Решенията, базирани на 1C:Enterprise 8.0, отговарят ли на тези изисквания? Няма ясен отговор. Въпреки значителните промени в системата за контрол на достъпа, остават много нерешени проблеми. В зависимост от това как е проектирана и конфигурирана системата, всички тези изисквания може да не бъдат изпълнени или изпълнени в достатъчна степен за дадено изпълнение, но си струва да се обърне внимание (и това е значително следствие от „младостта“ на платформата ), че за пълното изпълнение на изброените условия е необходимо да се положат наистина херкулесови усилия.

Тази статия е предназначена за разработчици и внедрители на решения на платформата 1C:Enterprise, както и системни администратори на организации, където се използва 1C:Enterprise, и описва някои аспекти на разработването и конфигурирането на версията клиент-сървър на системата от точката на от гледна точка на организацията информационна сигурност. Тази статия не може да се използва като заместител на документация, а само посочва някои точки, които все още не са отразени в нея. И, разбира се, нито тази статия, нито цялата документация ще могат да отразят сложността на проблема за изграждане на защитена информационна система, която в същото време трябва да задоволи противоречивите изисквания за сигурност, производителност, удобство и функционалност.

Класификация и терминология

Основният предмет на разглеждане в статията са информационните заплахи.

Информационна заплаха– възможността за ситуация, при която данните ще бъдат прочетени, копирани, променени или блокирани без разрешение.

И въз основа на това определение статията класифицира информационните заплахи, както следва:

• Неоторизирано унищожаване на данни
• Неоторизирана промяна на данни
• Неоторизирано копиране на данни
• Неоторизирано четене на данни
• Липса на данни

Всички заплахи се делят на умишлени и неумишлени. Ще наричаме реализирана информационна заплаха инцидент. Характеристиките на системата са:

Уязвимости– характеристики, водещи до инциденти Мерки за защита– функции, които блокират възможността за инцидент

По принцип се разглеждат само онези случаи, чиято вероятност се дължи на използването на технологичната платформа 1C: Enterprise 8.0 във версията клиент-сървър (освен това, в случаите, когато това не противоречи на значението просто на 1C или 1C 8.0) . Нека дефинираме следните основни роли във връзка с използването на системата:

• Оператори– потребители, които имат права да преглеждат и променят данни, ограничени от роля на приложение, но нямат административни функции
• Системни администратори– потребители, които имат административни права в системата, включително административни права в операционните системи на сървъра на приложения и MS SQL сървъра, административни права в MS SQL и др.
• Администратори по информационна сигурност– потребители, на които са делегирани определени административни функции в информационната база 1C (като добавяне на потребители, тестване и коригиране, архивиране, настройка на приложно решение и др.)
• Системни разработчици– потребители, разработващи приложно решение. Като цяло може да нямат достъп до работещата система.
• Лица, които нямат директен достъп до системата– потребители, на които не са делегирани права за достъп до 1C, но които могат в една или друга степен да повлияят на работата на системата (обикновено това са всички потребители на същия домейн на Active Directory, в който е инсталирана системата). Тази категория се счита основно за идентифициране на потенциално опасни обекти в системата.
• Автоматизирани административни скриптове– програми, на които са делегирани определени функции, предназначени за автоматично извършване на определени действия (например импорт-експорт на данни)

Тук трябва да се отбележат две точки: първо, тази класификация е много груба и не взема предвид разделенията във всяка група - такова разделение ще бъде създадено за някои конкретни случаи, и второ, предполага се, че други лица не могат да повлияят на операцията на системата, което трябва да се осигури чрез външни за 1С средства.

Всяка система за сигурност трябва да бъде проектирана с оглед на осъществимостта и разходите за притежание. По принцип при разработване и внедряване на информационна система е необходимо цената на защитата на системата да съответства на:

• стойността на защитената информация;
• разходи за създаване на инцидент (в случай на умишлена заплаха);
• финансови рискове в случай на инцидент

Безсмислено и вредно е да се организира защита, която е много по-скъпа от оценката на нейната финансова ефективност. Има няколко метода за оценка на рисковете от загуба на информация, но те не се обсъждат в обхвата на тази статия. Друг важен аспект е поддържането на баланс между често противоречиви изисквания за информационна сигурност, производителност на системата, удобство и лекота на работа със системата, скорост на разработка и внедряване и други изисквания към корпоративните информационни системи.

Основни характеристики на механизма за информационна сигурност на системата

1C:Enterprise 8.0 се предлага в две версии: файл и клиент-сървър. Версията на файла не може да се счита за гарантираща информационната сигурност на системата поради следните причини:

• Данните и конфигурацията се съхраняват във файл, който може да се чете и записва от всички потребители на системата.
• Както ще бъде показано по-долу, системното оторизиране се заобикаля много лесно.
• Целостта на системата се осигурява само от ядрото на клиентската част.

Във версията клиент-сървър за съхраняване на информация се използва MS SQL Server, който осигурява:

• По-надеждно съхранение на данни.
• Изолиране на файлове от директен достъп.
• По-усъвършенствани транзакции и механизми за заключване.

Въпреки значителните разлики между файловата и клиент-сървърната версия на системата, те имат унифицирана схема за контрол на достъпа на ниво приложно решение, която предоставя следните възможности:

• Упълномощаване на потребител с помощта на паролата, посочена в 1C.
• Упълномощаване на потребител въз основа на текущия потребител на Windows.
• Присвояване на роли на системните потребители.
• Ограничаване на административни функции по роли.
• Разпределение на наличните интерфейси по роли.
• Ограничаване на достъпа до обекти с метаданни по роля.
• Ограничаване на достъпа до детайлите на обекта по роля.
• Ограничаване на достъпа до обекти с данни чрез роли и параметри на сесията.
• Ограничаване на интерактивния достъп до данни и изпълними модули.
• Някои ограничения за изпълнение на код.

Като цяло използваната схема за достъп до данни е доста типична за информационните системи от това ниво. Въпреки това, по отношение на тази реализация на тристепенна архитектура клиент-сървър, има няколко основни аспекта, които водят до относително голям брой уязвимости:

1. Голям брой етапи на обработка на данни и на всеки етап могат да се прилагат различни правила за достъп до обекти.

   Донякъде опростена диаграма на етапите на обработка на данни, които са важни от гледна точка на сигурността, е показана на фиг. 1. Общо правилоза 1C е да намалите ограниченията, докато се движите надолу по тази схема, следователно, използвайки уязвимост на един от горни ниваможе да наруши системата на всички нива.

2. Недостатъчно установени процедури за наблюдение на предаваните данни при преминаване от ниво на ниво.

   За съжаление, не всички вътрешни механизми на системата са идеално дебъгвани, особено за неинтерактивни механизми, чието дебъгване винаги е по-трудоемко от една страна, но по-отговорно от друга. Тази „болест“ не е проблем само с 1C; тя се среща в много сървърни продукти от повечето доставчици. Едва през последните години вниманието към тези проблеми се увеличи значително.

3. Недостатъчно висока средна квалификация на разработчици и системни администратори, наследени от предишната версия.

   Продуктите от линията 1C:Enterprise първоначално бяха фокусирани върху лекотата на разработка и поддръжка и върху работата в малки организации, така че не е изненадващо, че исторически се е развило, че значителна част от „разработчиците“ на приложни решения и „администраторите“ на системи нямат достатъчно знания и умения за работа с много по-сложен продукт, какъвто е версия 8.0. Проблемът се влошава от практиката, възприета от компаниите-франчайзополучатели, да преподават „в битка“ за сметка на клиентите, без систематично да подхождат към този въпрос. Необходимо е да се отдаде почит на компанията 1C, че през последните няколко години тази ситуация постепенно се коригира: сериозни компании франчайзополучатели започнаха да подхождат по-отговорно към проблема с подбора и обучението на персонала, нивото на поддръжка на информационните технологии от компанията 1C се увеличи значително, появиха се програми за сертифициране, насочени към високо ниво на обслужване; но ситуацията не може да бъде коригирана незабавно, така че този фактор трябва да се вземе предвид при анализа на сигурността на системата.

4. Платформата е сравнително млада.

   Сред продуктите с подобен фокус и предназначение, това е едно от най-младите решения. Функционалността на платформата беше горе-долу установена преди по-малко от година. В същото време всяка версия на платформата, започвайки с 8.0.10 (именно в тази версия бяха внедрени почти всички текущи възможности на системата) стана значително по-стабилна от предишните. Функционалността на стандартните приложни решения все още расте със скокове и граници, въпреки че се използват само половината от възможностите на платформата. Разбира се, при такива условия можем да говорим за стабилност доста условно, но като цяло трябва да се признае, че в много отношения решенията на платформата 1C 8.0 са значително по-напред във функционалността и производителността (а често и в стабилността) на подобни решения на 1C 7.7 платформа.

И така, системата (и евентуално стандартно приложно решение) се внедрява в предприятието и се инсталира на компютри. На първо място, необходимо е да се създаде среда, в която настройката на сигурността на 1C има смисъл и за това тя трябва да бъде конфигурирана по такъв начин, че да е изпълнено предположението, че сигурността на системата е значително повлияна от системните настройки.

Следвайте общите правила за настройка на сигурността.

Не може да се говори за информационна сигурност на една система, ако не се спазват основните принципи за създаване на защитени системи. Уверете се, че са изпълнени поне следните условия:

• Достъпът до сървърите е физически ограничен и е осигурена тяхната непрекъсната работа:
  • сървърното оборудване отговаря на изискванията за надеждност, коригирана е подмяната на дефектно сървърно оборудване, за особено критични области се използват схеми с дублиране на хардуер (RAID, захранване от множество източници, множество комуникационни канали и др.);
  • сървърите се намират в заключено помещение, като това помещение се отваря само за времето на работа, която не може да се извършва дистанционно;
  • Само един или двама души имат право да отварят сървърното помещение, в случай на авария е разработена система за известяване на отговорните лица;
  • осигурено е непрекъснато захранване на сървърите
  • осигурени са нормални климатични условия на работа на оборудването;
  • има противопожарна аларма в сървърното помещение, няма опасност от наводнение (особено за първи и последен етаж);
• Настройките на мрежовата и информационната инфраструктура на предприятието са изпълнени правилно:
  • Защитните стени са инсталирани и конфигурирани на всички сървъри;
  • всички потребители и компютри са оторизирани в мрежата, паролите са достатъчно сложни, за да не могат да бъдат познати;
  • системните оператори имат достатъчно права да работят нормално с него, но нямат права за административни действия;
  • антивирусните инструменти са инсталирани и активирани на всички компютри в мрежата;
  • Желателно е потребителите (с изключение на мрежовите администратори) да нямат административни права на клиентските работни станции;
  • достъпът до интернет и преносимите носители на информация трябва да бъдат регулирани и ограничени;
  • трябва да се конфигурира системен одит на събития за сигурност;
• Решени са основните организационни въпроси:
  • потребителите имат достатъчна квалификация за работа с 1C и хардуер;
  • потребителите са уведомени за отговорност за нарушаване на правилата за работа;
  • за всеки съществен елемент от информационната система са определени материално отговорни лица;
  • всички системни единици са запечатани и затворени;
  • Обърнете специално внимание на инструктажа и надзора на чистачи, строителни работници и електротехници. Тези лица могат поради небрежност да причинят щети, които не са сравними с умишлените щети, причинени от недобросъвестен потребител на системата.

внимание!Този списък не е изчерпателен, а само описва това, което често се пропуска при внедряването на доста сложна и скъпа информационна система!

• MS SQL Server, сървър на приложения и клиентска част работят на различни компютри, сървърни приложения работят с правата на специално създадени Windows потребители;
• За MS SQL Server
  • зададен е смесен режим на оторизация
  • Потребителите на MS SQL, включени в ролята на администратор на сървъра, не участват в работата на 1C,
  • за всеки IB 1C е създаден отделен MS SQL потребител, който няма привилегирован достъп до сървъра,
  • MS SQL потребител на една ИС няма достъп до друга ИС;
• Потребителите нямат директен достъп до файловете на сървъра на приложения и MS SQL сървъра
• Работните станции на оператора са оборудвани с Windows 2000/XP (не Windows 95/98/Me)

Не пренебрегвайте препоръките на разработчиците на системата и четене на документацията. Важни материали за настройка на системата са публикувани на ITS дискове в раздела „Методически препоръки“. Обърнете специално внимание на следните статии:

1. Характеристики на приложения, работещи със сървъра 1C:Enterprise
2. Поставяне на данни 1C:Enterprise 8.0
3. Актуализация на 1C:Enterprise 8.0 от потребители Microsoft Windowsбез администраторски права
4. Редактиране на потребителския списък от името на потребител, който няма администраторски права
5. Конфигуриране на настройките на защитната стена на Windows XP SP2 за стартиране на SQL Server 2000 и SQL Server Desktop Engine (MSDE)
6. Конфигуриране на параметри на COM+ Windows XP SP2 за стартиране на сървъра 1C:Enterprise 8.0
7. Конфигуриране на настройките на защитната стена на Windows XP SP2 за сървъра 1C:Enterprise 8.0
8. Конфигуриране на настройките на защитната стена на Windows XP SP2 за HASP License Manager
9. Създаване на резервно копие информационна базаизползвайки SQL Server 2000
10. Проблеми с инсталирането и конфигурацията на 1C:Enterprise 8.0 във версията "клиент-сървър".(една от най-важните статии)
11. Особености Настройки на Windows Server 2003 при инсталиране на сървър 1C:Enterprise 8.0
12. Регулиране на потребителския достъп до информационната база във версия клиент-сървър(една от най-важните статии)
13. Сървър 1C: Enterprise и SQL сървър
14. Подробна процедура за инсталиране на 1C:Enterprise 8.0 във версията "клиент-сървър"(една от най-важните статии)
15. Използване на вградения език на сървъра на 1C:Enterprise

Но когато четете документацията, бъдете критични към получената информация, например статията „Проблеми с инсталирането и конфигурирането на 1C: Enterprise 8.0 във версия клиент-сървър“ не описва точно правата, които се изискват за потребителя USER1CV8SERVER. Ще има връзки към списъка по-долу, например [ITS1] означава статията „Характеристики на приложения, работещи със сървъра 1C:Enterprise“. Всички връзки към статии са дадени към последния брой на ITS към момента на писане (януари 2006 г.)

Използвайте възможности за оторизация, комбинирани с оторизация на Windows за потребителите

От двата възможни режима на потребителско разрешение: вграден 1C и комбиниран с Windows OS разрешение, ако е възможно, трябва да изберете комбинирано разрешение. Това ще позволи на потребителите да не се бъркат с множество пароли при работа, но няма да намали нивото на сигурност на системата. Въпреки това, дори за потребители, които използват само оторизация на Windows, е силно препоръчително да зададете парола, когато я създавате, и едва след това да деактивирате 1C оторизацията за този потребител. За да се осигури възстановяване на системата в случай на разрушаване на структурата на Active Directory, е необходимо да оставите поне един потребител, който може да влезе в системата с помощта на 1C оторизация.

Когато създавате роли за решение за приложение, не добавяйте права „в резерв“

Всяка роля на решение за приложение трябва да отразява минимално необходимия набор от права за извършване на действията, дефинирани от тази роля. Някои роли обаче може да не се използват самостоятелно. Например за интерактивно стартиране външни леченияМожете да създадете отделна роля и да я добавите към всички потребители, които трябва да използват външна обработка.

Редовно преглеждайте регистрационните файлове и протоколите за работа на системата

Ако е възможно, регулирайте и автоматизирайте прегледа на регистрационни файлове и протоколи за работа на системата. С правилна конфигурация и редовен преглед на регистрационните файлове (филтриране само по важни събития), неразрешените действия могат да бъдат открити рано или дори предотвратени по време на подготвителната фаза.

Някои функции на версията клиент-сървър

Този раздел описва някои от работните функции на опцията клиент-сървър и тяхното въздействие върху сигурността. За по-лесно четене се използват следните обозначения:

внимание! описание на уязвимостта

Съхраняване на информация, която контролира достъпа до системата

Съхраняване на списък на потребителите на информационна сигурност

Цялата информация за списъка на потребителите на тази информационна сигурност и достъпните за тях роли в нея се съхранява в таблицата Params в базата данни MS SQL (виж [ITS2]). Разглеждайки структурата и съдържанието на тази таблица, става очевидно, че цялата потребителска информация се съхранява в запис със стойност на полето FileName „users.usr“.

Тъй като предполагаме, че потребителите нямат достъп до базата данни на MS SQL, този факт сам по себе си не може да бъде използван от нападател, но ако е възможно да се изпълни код в MS SQL, това „отваря вратата“ за получаване на всякакви (! ) достъп от 1C . Същият механизъм (с незначителни промени) може да се използва и във файловата версия на системата, което, имайки предвид характеристиките на файловата версия, напълно изключва неговата приложимост при изграждане на защитени системи.

Препоръка:В момента няма начин приложението да бъде напълно защитено от подобни промени, с изключение на използването на тригери на ниво MS SQL Server, което от друга страна може да създаде проблеми при актуализиране на версията на платформата или промяна на списъка с потребители. За да проследите такива промени, можете да използвате дневника на 1C (като обърнете внимание на „подозрителни“ влизания в режим на конфигуратор, без да посочвате потребителя) или да поддържате SQL Profiler постоянно работещ (което ще има изключително отрицателно въздействие върху производителността на системата) или конфигурирайте предупрежденията механизъм (най-вероятно заедно с помощта на тригери)

Съхраняване на информация за списъка на IS на сървъра

За всеки сървър на приложения 1C се съхранява информация за списъка на базите данни MS SQL, свързани към него. Всяка информационна база използва собствен низ за връзка от сървъра на приложения и MS SQL сървъра, за да работи. Информацията за информационните бази, регистрирани на сървъра на приложения, заедно с низовете за връзка се съхраняват във файла srvrib.lst, който се намира на сървъра в директорията<Общие данные приложений>/1C/1Cv8 (например C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst). За всяка система за информационна сигурност се съхранява пълен низ за свързване, включително MS SQL потребителска парола, когато се използва смесен MS SQL модел за оторизация. Именно наличието на този файл дава възможност да се опасявате от неоторизиран достъп до базата данни на MS SQL и ако, противно на препоръките, привилегирован потребител (например „sa“) се използва за достъп до поне една база данни, тогава в в допълнение към заплахата за една информационна сигурност, съществува заплаха за цялата система, използваща MS SQL.

Интересно е да се отбележи, че използването на смесена авторизация и Windows авторизация на MS SQL сървър води до различни видове проблеми при получаване на достъп до даден файл. Така че ключовите отрицателни свойства на упълномощаването на Windows ще бъдат:

• Работа на цялата информационна сигурност на сървъра на приложения и на MS SQL сървъра под един набор от права (най-вероятно излишни)
• От процеса на 1C сървър на приложения (или като цяло от потребителя USER1CV8SERVER или негов еквивалент), без да посочвате парола, можете лесно да се свържете с всяка информационна сигурност, без да посочвате парола

От друга страна, може да е по-трудно за атакуващия да изпълни произволен код от контекста на потребителя USER1CV8SERVER, отколкото да получи указания файл. Между другото, наличието на такъв файл е друг аргумент за разпределяне на сървърните функции на различни компютри.

Препоръка:Файлът srvrib.lst трябва да бъде достъпен само от сървърния процес. Не забравяйте да конфигурирате одита, за да промените този файл.

За съжаление, по подразбиране този файлпочти не е защитен от четене, което трябва да се вземе предвид при внедряването на системата. Идеалният вариант би бил сървърът на приложения да предотврати четене и запис на този файл, докато работи (включително четене и запис от потребителски връзки, изпълнявани на този сървър).

Липса на оторизация при създаване на информационна сигурност на сървъра

внимание! Грешката при липса на разрешение беше коригирана във версия 8.0.14 на платформата 1C:Enterprise. В тази версия се появи концепцията за „1C:Enterprise Server Administrator“, но докато списъкът с администратори е посочен на сървъра, системата работи, както е описано по-долу, така че не забравяйте за тази възможна функция.

Вероятно най-голямата уязвимост от този раздел е способността за почти неограничено добавяне на информационна сигурност към сървъра на приложения, в резултат на което всеки потребител, който получи достъп до връзка със сървъра на приложения, автоматично получава възможността да изпълнява произволен код на сървъра на приложения . Нека да разгледаме това с пример.

Системата трябва да бъде инсталирана по следния начин

• MS SQL Server 2000 (например мрежово име SRV1)
• Сървър 1C:Enterprise 8.0 (мрежово име SRV2)
• Клиентска част 1C:Enterprise 8.0 (мрежово име WS)

Предполага се, че потребителят (наричан по-долу ПОТРЕБИТЕЛ), работещ на WS, има поне минимален достъп до една от системите за информационна сигурност, регистрирани на SRV2, но няма привилегирован достъп до SRV1 и SRV2. Като цяло комбинацията от функции на изброените компютри не влияе на ситуацията. Системата е конфигурирана, като се вземат предвид препоръките в документацията и на ITS дисковете. Ситуацията е показана на фиг. 2.

• конфигурирайте COM+ сигурността на сървъра на приложения, така че само потребителите на 1C да имат право да се свързват с процеса на сървъра на приложения (повече подробности [ITS12]);
• файлът srvrib.lst трябва да бъде само за четене за потребителя USER1CV8SERVER (за да добавите нова информационна сигурност към сървъра, временно разрешете писането);
• За да се свържете с MS SQL, използвайте само TCP/IP протокола, в този случай можете:
  • ограничавайте връзките с помощта на защитна стена;
  • конфигурирайте използването на нестандартен TCP порт, което ще усложни връзката на „външни“ IB 1C;
  • използвайте криптиране на предаваните данни между сървъра на приложения и SQL сървъра;
• конфигурирайте защитната стена на сървъра, така че използването на MS SQL сървъри на трети страни да е невъзможно;
• използвайте инструменти за защита на интранет, за да изключите възможността неоторизиран компютър да се появи в локалната мрежа (IPSec, групови политики за сигурност, защитни стени и др.);
• При никакви обстоятелства не предоставяйте на потребителя USER1CV8SERVER административни права на сървъра на приложения.

Използване на код, работещ на сървъра

Когато използвате версията клиент-сървър на 1C, разработчикът може да разпредели изпълнението на кода между клиента и сървъра на приложения. За да може кодът (процедурата или функцията) да се изпълнява само на сървъра, е необходимо той да бъде поставен в общ модул, за който е зададено свойство „Сървър“ и в случай, че изпълнението на модула е разрешено не само на сървъра, поставете кода в ограничената секция „#If Server“:

#Ако сървър, тогава
Функция OnServer(Param1, Param2 = 0) Експорт // Тази функция, въпреки своята простота, се изпълнява на сървъра
Param1 = Param1 + 12;
Върнете Param1;
EndFunction
#EndIf

Когато използвате код, който се изпълнява на сървъра, трябва да имате предвид, че:

• кодът се изпълнява с права USER1CV8SERVER на сървъра на приложения (достъпни са COM обекти и сървърни файлове);
• всички потребителски сесии се изпълняват от едно копие на услугата, така че, например, препълване на стека на сървъра ще доведе до прекъсване на връзката на всички активни потребители;
• отстраняването на грешки в сървърните модули е трудно (например не можете да зададете точка на прекъсване в програмата за отстраняване на грешки), но трябва да се направи;
• прехвърлянето на контрол от клиента към сървъра на приложения и обратно може да изисква значителни ресурси с големи обеми прехвърлени параметри;
• използване на интерактивни инструменти (формуляри, документи с електронни таблици, диалогови прозорци), външни отчети и обработка в код на сървъра на приложения е невъзможна;
• не се допуска използването на глобални променливи (променливи на модула на приложението, декларирани с индикация "Експортиране");

За повече подробности вижте [ITS15] и други статии за ITS.

Сървърът на приложения трябва да има специални изисквания за надеждност. В правилно изградена система клиент-сървър трябва да бъдат изпълнени следните условия:

• никакви действия на клиентското приложение не трябва да прекъсват работата на сървъра (с изключение на административни случаи);
• сървърът не може да изпълни програмен код, получен от клиента;
• ресурсите трябва да бъдат разпределени „справедливо“. клиентски връзки, осигуряваща наличност на сървъра независимо от текущото натоварване;
• при липса на блокиране на данни клиентските връзки не трябва да влияят взаимно на работата;
• не на сървъра потребителски интерфейс, но трябва да се разработят инструменти за наблюдение и регистриране;

Като цяло системата 1C е изградена по такъв начин, че да се доближи до тези изисквания (например, невъзможно е да се принуди външна обработка да се извърши на сървъра), но все още съществуват няколко неприятни функции, следователно:

Препоръка:При разработването на сървър за изпълнение се препоръчва да се придържате към принципа на минимален интерфейс. Тези. броят на влизанията в сървърните модули от клиентското приложение трябва да бъде много ограничен, а параметрите трябва да бъдат строго регулирани. Препоръка:При получаване на параметри на процедури и функции на сървъра е необходимо да се валидират параметрите (проверете дали параметрите отговарят на очаквания тип и диапазон от стойности). Това не се прави в стандартните решения, но е много желателно да се въведе задължителна валидация в собствените ви разработки. Препоръка:Когато генерирате текст на заявка (и особено параметъра на командата Run) от страната на сървъра, не използвайте низове, получени от клиентското приложение.

Обща препоръка би била да се запознаете с принципите за изграждане на сигурност уеб-приложения за база данни и работят на подобни принципи. Приликите наистина са значителни: първо, подобно на уеб приложение, сървърът на приложения е междинен слой между базата данни и потребителския интерфейс (основната разлика е, че уеб сървърът формира потребителския интерфейс); второ, от гледна точка на сигурността, не можете да се доверите на данните, получени от клиента, т.к има възможност за стартиране на външни отчети и обработка.

Предаващи параметри

Предаването на параметри към функция (процедура), изпълнявана на сървъра, е доста деликатен въпрос. Това се дължи главно на необходимостта от прехвърлянето им между сървъра на приложенията и клиентските процеси. Когато контролът премине от страната на клиента към страната на сървъра, всички предадени параметри се сериализират, прехвърлят се към сървъра, където се „разопаковат“ и се използват. При преминаване от страната на сървъра към страната на клиента, процесът е обратен. Тук трябва да се отбележи, че тази схема правилно обработва предаването на параметри по препратка и по стойност. При предаване на параметри се прилагат следните ограничения:

• Само непроменливи стойности (т.е., чиито стойности не могат да бъдат променяни) могат да се прехвърлят между клиента и сървъра (и в двете посоки): примитивни типове, препратки, универсални колекции, стойности за системно изброяване, съхранение на стойности. Ако се опитате да подадете нещо друго, клиентското приложение се срива (дори ако сървърът се опита да предаде неправилен параметър).
• Не се препоръчва да се прехвърлят големи количества данни при предаване на параметри (например низове с повече от 1 милион знака), това може да повлияе негативно на производителността на сървъра.
• Не можете да предавате параметри, съдържащи циклична препратка, както от сървъра към клиента, така и обратно. Ако се опитате да подадете такъв параметър, клиентското приложение се срива (дори ако сървърът се опита да предаде неправилния параметър).
• Не се препоръчва прехвърлянето на много сложни колекции от данни. Когато се опитате да предадете параметър с много голямо ниво на вложеност, сървърът се срива (!).

внимание! Най-неприятната функция в момента вероятно е грешката при предаване на сложни колекции от стойности. Така например кодът: Ниво на влагане = 1250;
M = нов масив;
PassedParameter = M;
За сметка = 1 по ниво на цикъл на вмъкване
MVInt = Нов масив;
M.Add(MVInt);
M = MVint;
EndCycle;
ServerFunction(PassedParameter);

Води до аварийно спиране на сървъра с прекъсване на връзката на всички потребители и това се случва преди управлението да бъде прехвърлено към кода на вградения език.

Използване на опасни функции от страната на сървъра.

Не всички вградени езикови инструменти могат да се използват в код, изпълняван на сървъра на приложения, но дори сред наличните инструменти има много „проблематични“ конструкции, които могат грубо да се класифицират, както следва:

• способни да предоставят възможност за изпълнение на код, който не се съдържа в конфигурацията (група „Изпълнение на код“)
• в състояние да предостави на клиентското приложение информация за файла и операционна системапотребител или извършване на действия, които не са свързани с работа с данни („Нарушаване на права“)
• способни да причинят срив на сървъра или да използват много големи ресурси (група „Срив на сървъра“)
• способни да причинят повреда на клиента (група повреда на клиента) – този тип не се разглежда. Пример: предаване на променлива стойност към сървъра.
• грешки в програмните алгоритми (безкрайни цикли, неограничена рекурсия и т.н.) („Програмни грешки“)

Основните проблемни проекти, познати ми (с примери), са изброени по-долу:

Процедура Изпълнение(<Строка>)

Изпълнение на код.Позволява ви да изпълните част от кода, който му се предава като стойност на низ. Когато се използва на сървъра, трябва да се уверите, че получените от клиента данни не се използват като параметър. Например не е разрешено следното използване:

#Ако сървър, тогава
ProcedureOnServer(Param1) Експортиране
Изпълнение (Параметр1);
Край на процедурата
#EndIf

Въведете "COMObject" (конструктор New COMObject(<Имя>, <Имя сервера>))

Създава външно приложение COM обект с права USER1CV8SERVER на сървъра на приложения (или друг указан компютър). Когато се използва на сървър, уверете се, че параметрите не се предават от клиентското приложение. От страна на сървъра обаче е ефективно да използвате тази функция при импортиране/експортиране, изпращане на данни по интернет, прилагане на нестандартни функции и т.н.

Функция GetCOMObject(<Имя файла>, <Имя класса COM>)

Нарушаване на права и изпълнение на код.Подобно на предишния, само получаване на COM обекта, съответстващ на файла.

Процедури и функции ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()

Нарушение на правата.Изпълнявайки ги на сървъра, те ви позволяват да разберете подробностите за организацията на подсистемата на сървъра. Когато се използва на сървър, уверете се, че данните или не се прехвърлят към клиента, или не са достъпни за оператори без подходящо разрешение. Обърнете специално внимание на факта, че данните могат да бъдат предадени обратно в параметър, предаден чрез препратка.

Процедури и функции за работа с файлове (CopyFile, FindFiles, MergeFiles и много други), както и типове файлове.

Нарушение на правата.Те позволяват чрез изпълнението им на сървъра да се получи споделен достъп до локални (и разположени в мрежата) файлове, достъпни с потребителски права USER1CV8SERVER. Ако се използва съзнателно, тогава е възможно ефективно да се изпълняват задачи като импортиране/експортиране на данни на сървъра.

Не забравяйте да проверите вашите потребителски права на 1C, преди да използвате тези функции. За да проверите потребителските права, можете да използвате следната конструкция в сървърния модул:

#Ако сървър, тогава
Процедура PerformWorkWithFile() Export
RoleAdministrator = Метаданни.Roles.Administrator;
Потребител = SessionParameters.CurrentUser;
Ако User.Roles.Contains(RoleAdministrator) Тогава
//Тук се изпълнява кодът за работа с файлове
endIf;
#EndIf

Не забравяйте да проверите параметрите, ако използвате тези процедури и функции, в противен случай съществува риск от случайно или съзнателно причиняване на непоправима вреда на сървъра на приложения 1C, например, когато изпълнявате следния код на сървъра:

Път = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
MoveFile(Path + "srvrib.lst", Path + "Here'sWhereTheFileGoes");

След изпълнение на такъв код на сървъра, ако потребителят USER1CV8SERVER има правата да го промени, както е описано по-горе, и след рестартиране на сървърния процес (по подразбиране, 3 минути след излизане на всички потребители), ще възникне ГОЛЯМ въпрос относно стартирането на сървъра . Но също така е възможно напълно да изтриете файлове...

Типове "XBase", "BinaryData", "XML Reader", "XML Writer", "XSL Transformation", "ZipFile Writer", "ZipFile Reader", "Text Reader", "Text Writer"

Нарушение на правата.Те позволяват, като ги изпълняват на сървъра, достъп до локални (и намиращи се в мрежата) файлове от определени типове и четене/запис в тях с потребителски права USER1CV8SERVER. Ако се използва съзнателно, е възможно ефективно да се изпълняват задачи като импортиране/експортиране на данни на сървъра, регистриране на работата на определени функции и решаване на административни задачи. Като цяло препоръките съвпадат с предишния параграф, но трябва да обмислите възможността за прехвърляне на данни от тези файлове (но не обекти от всички тези типове) между клиентската и сървърната част.

Въведете „Системна информация“

Нарушение на правата.Позволява ви да получите данни за сървъра на приложения в случай на неправилно използване и прехвърляне на данни към клиентската част на приложението. Препоръчително е да ограничите правото на използване при използване.

Типове "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTTPConnection"

Нарушение на правата.Когато се използва на сървър, той се свързва към отдалечен компютър от сървър на приложения с права USER1CV8SERVER. Препоръки:

• Контрол на параметрите при извикване на методи.
• Контрол на потребителските права на 1C.
• Сериозни ограничения върху правата на потребителя USER1CV8SERVER за достъп до мрежата.
• Правилно настройване на защитната стена на сървъра на приложения 1C.

Когато се използва правилно, е удобно да се организира, например, изпращане на имейли от сървър на приложения.

Типове "InformationBaseUserManager", "InformationBaseUser"

Нарушение на правата.Ако се използва неправилно (в привилегирован модул), е възможно да се добавят потребители или да се променят параметрите за оторизация на съществуващи потребители.

Формат на функцията

Срив на сървъра.да Тази на пръв поглед безобидна функция, ако нейните параметри не се контролират и изпълняват на сървъра, може да доведе до срив на сървърното приложение. Грешката възниква при форматиране на числа и използване на режима за показване на водещи нули и голям брой знаци, напр.

Формат (1, "CHZ=999; CHVN=");

Надявам се, че тази грешка ще бъде коригирана в следващите версии на платформата, но междувременно, във всички извиквания на тази функция, които могат да бъдат изпълнени на сървъра, проверете параметрите на извикването.

Процедури и функции за запазване на стойности (ValueInRowInt, ValueInFile)

Срив на сървъра.Тези функции не обработват кръгови препратки в колекции или много дълбоко влагане, така че може да се сринат в някои много специални случаи.

Грешки в гранични и специални стойности на параметри във функции. Контрол на изпълнението.

Един от проблемите, които може да срещнете, когато използвате сървър, е високата "отговорност" на сървърните функции (възможността цялото сървърно приложение да се срине поради грешка в една връзка и използването на едно "ресурсно пространство" за всички връзки) . Оттук и необходимостта да се контролират основните параметри на времето за изпълнение:

• За вградени езикови функции проверете техните параметри за стартиране (добър пример е функцията „Формат“)
• Когато използвате цикли, уверете се, че условието за изход от цикъла е изпълнено. Ако цикълът е потенциално безкраен, изкуствено ограничете броя на итерациите: MaximumIterationCounterValue = 1000000;
  Брояч на итерации = 1;
  Чао
  FunctionWhichMayNotReturnFalseValue()
  И (Брой итерации<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Тяло на цикъла
  Брояч на повторения = Брояч на повторения + 1;
  EndCycle;
  Ако брояч на итерации>Максимална стойност на брояча на итерации, тогава
  //.... обработва събитието на прекалено дълго изпълнение на цикъл
  endIf;

• Когато използвате рекурсия, ограничете максималното ниво на влагане.
• Когато формирате и изпълнявате заявки, опитайте се да предотвратите много дълги селекции и селекции на голямо количество информация (например, когато използвате условието "В ЙЕРАРХИЯ", не използвайте празна стойност)
• Когато проектирате информационна база, осигурете достатъчно голям резерв от битова дълбочина за числа (в противен случай събирането и умножението стават некомутативни и неасоциативни, което затруднява отстраняването на грешки)
• В изпълними заявки проверете логиката на операцията за наличие на NULL стойности и правилната работа на условията и изразите на заявката, използвайки NULL.
• Когато използвате колекции, контролирайте способността да ги прехвърляте между сървъра на приложения и страната на клиента.

Използване на терминален достъп до клиентската страна за ограничаване на достъпа

Често можете да намерите препоръки за използване на терминален достъп за ограничаване на достъпа до данни и подобряване на производителността чрез изпълнение на клиентски код на терминалния сървър. Да, ако е конфигуриран правилно, използването на терминален достъп наистина може да повиши общото ниво на сигурност на системата, но, за съжаление, често можете да се сблъскате с факта, че при практическа употреба сигурността на системата само намалява. Нека се опитаме да разберем с какво е свързано това. Сега има две общи средства за организиране на терминален достъп, това са Microsoft Terminal Services (протокол RDP) и Citrix Metaframe Server (протокол ICA). Като цяло инструментите на Citrix предоставят много по-гъвкави възможности за администриране на достъп, но цената на тези решения е много по-висока. Ще разгледаме само основните характеристики, общи за двата протокола, които могат да намалят общото ниво на сигурност. Има само три основни опасности при използване на терминален достъп:

• Възможност за блокиране на работата на други потребители чрез изземване на прекомерни количества ресурси
• Достъп до данни на други потребители.
• Неоторизирано копиране на данни от терминалния сървър към компютъра на потребителя

Във всеки случай терминалните услуги ви позволяват да:

• Увеличете надеждността на работа (ако има повреда на терминалния компютър, потребителят може впоследствие да продължи да работи от същото място)
• Ограничете достъпа до клиентското приложение и файловете, които то записва.
• Прехвърлете изчислителното натоварване от работната станция на потребителя към сървъра за терминален достъп
• Управлявайте системните настройки по-централно. За потребителите запазените настройки ще бъдат валидни, независимо от кой компютър са влезли в системата.
• В някои случаи можете да използвате терминално решение за отдалечен достъп до системата.

Необходимо е да се ограничи броят на възможните връзки към терминалния сървър за един потребител

Поради "лакомостта" на клиентското приложение 1C по отношение на ресурсите е наложително да се ограничи максималния брой едновременни връзки на един потребител (оператор) към терминалния сървър. Една активно използвана връзка може да използва до 300 MB памет само с едно копие на приложението. В допълнение към паметта, процесорното време се използва активно, което също не допринася за стабилността на потребителите на този сървър. Едновременно с предотвратяването на прекомерното използване на сървърни ресурси, такова ограничение може да предотврати използването на чужди сметка. Изпълнява се чрез стандартни настройки на терминалния сървър.

Не трябва да позволявате повече от едно или две клиентски приложения на 1C да работят едновременно в една връзка

Продиктувано от същите причини като в предходния параграф, но технически по-трудно за изпълнение. Проблемът е, че е почти невъзможно да се предотврати рестартирането на 1C с помощта на инструментите на терминалния сървър (защо ще бъде обяснено по-долу), така че трябва да внедрите тази функция на ниво решение на приложението (което също не е добро решение, тъй като сесиите могат да останат „висящи“ за известно време. Ако приложението е прекратено неправилно, има нужда от прецизиране на решението на приложението в модула на приложението и някои справочници, което ще усложни използването на актуализации от 1C). Много е желателно да оставите на потребителя възможността да стартира 2 приложения, за да можете да изпълнявате някои действия (например генериране на отчети) във фонов режим - клиентското приложение, за съжаление, всъщност е еднопоточно.

Не се препоръчва да се дават права за достъп до терминалния сървър на потребители, които имат право да изпълняват ресурсоемки изчислителни задачи в 1C или да се предотврати такова стартиране, докато други потребители активно работят.

Разбира се, по-добре е да оставите достъп до терминалния сървър само на потребители, които не използват задачи като извличане на данни, географски диаграми, импорт/експорт и други задачи, които натоварват сериозно клиентската част на приложението. Ако все още има нужда да се разрешат такива задачи, тогава е необходимо да се: уведоми потребителя, че тези задачи могат да повлияят на производителността на други потребители, да се запише началото и края на такъв процес в дневника, да се разреши изпълнението само на регулиран време и др.

Необходимо е да се уверите, че всеки потребител има права за запис само в строго определени директории на терминалния сървър и че други потребители нямат достъп до тях.

Първо, ако не ограничите възможността да пишете в споделени директории (като директорията, в която е инсталиран 1C), остава възможно нападателят да промени поведението на програмата за всички потребители. Второ, данните на един потребител (временни файлове, файлове за запазване на настройките на отчета и т.н.) при никакви обстоятелства не трябва да бъдат достъпни за друг потребител на терминалния сървър - по принцип това правило се спазва при нормална конфигурация. Трето, нападателят все още има възможност да „засипе“ дяла, така че да не остане място на твърдия диск. Знам, че ще ми възразят, че операционната система Windows, започвайки с Windows 2000, има квотен механизъм, но това е доста скъп механизъм и на практика никога не съм виждал реално приложение от него.

Ако предишните проблеми с настройката на достъпа като цяло бяха доста лесни за изпълнение, тогава такава (на пръв поглед) проста задача като регулиране на потребителския достъп до файлове не се изпълнява тривиално. Първо, ако не се използва квотният механизъм, могат да се записват големи файлове. Второ, системата е изградена по такъв начин, че почти винаги ще е възможно да запишете файла, така че да е достъпен за друг потребител.

Като се има предвид, че задачата е трудна за пълно решаване, се препоръчва да се одитират повечето файлови събития

Необходимо е да се забрани свързването (картографиране) на дискови устройства, принтери и клипборда на клиентската работна станция.

В RDP и ICA е възможно да се организира автоматично свързване на дискове, принтери, com портове на клипборда на терминалния компютър към сървъра. Ако тази възможност съществува, тогава е почти невъзможно да се предотврати стартирането на чужд код на терминалния сървър и запазването на данни от 1C на клиента за достъп до терминал. Разрешете тези функции само за тези с администраторски права.

Достъпът до мрежови файлове от терминалния сървър трябва да бъде ограничен.

Ако това не бъде направено, потребителят отново ще може да изпълнява нежелан код или да запазва данни. Тъй като обикновеният дневник не проследява файлови събития (между другото, добра идея за внедряване от разработчиците на платформа) и е почти невъзможно да се настрои системен одит в цялата мрежа (няма достатъчно ресурси за поддържането му), по-добре е потребителят да може да изпраща данни или за печат, или по имейл. Обърнете специално внимание на това, че терминалният сървър не работи директно със сменяемите носители на потребителите.

При никакви обстоятелства не трябва да оставяте сървъра на приложения на терминалния сървър, когато създавате защитена система.

Ако сървърът на приложения работи на същия компютър като клиентските приложения, тогава има много възможности да нарушите нормалната му работа. Ако по някаква причина е невъзможно да се разделят функциите на терминалния сървър и сървъра на приложения, тогава обърнете специално внимание на потребителския достъп до файловете, използвани от сървъра на приложения.

Необходимо е да се изключи възможността за стартиране на всички приложения с изключение на 1C:Enterprise на терминалния сървър.

Това е едно от най-трудните за изпълнение желания. Нека започнем с факта, че трябва да конфигурирате правилно правилата за групова сигурност в домейна. Всички административни шаблони и политики за ограничаване на софтуера трябва да бъдат конфигурирани правилно. За да се тествате, уверете се, че поне следните функции са блокирани:

Сложността на прилагането на това изискване често води до възможността за стартиране на „допълнителна“ 1C сесия на терминалния сървър (дори ако други приложения са ограничени, принципно е невъзможно да се забрани стартирането на 1C с помощта на Windows).

Помислете за ограниченията на обикновения журнал (всички потребители използват програмата от един компютър)

Очевидно, тъй като потребителите отварят 1C в терминален режим, тогава терминалният сървър ще бъде записан в дневника. Дневникът не показва от кой компютър се е свързал потребителят.

Терминален сървър – защита или уязвимост?

И така, след като разгледахме основните характеристики на северния терминал, можем да кажем, че терминалът север потенциално може да помогне в автоматизацията за разпределяне на изчислителното натоварване, но изграждането на сигурна система е доста трудно. Един от случаите, когато използването на терминален сървър е най-ефективно, е при стартиране на 1C без Windows Explorer в режим на цял екран за потребители с ограничена функционалност и специализиран интерфейс.

Работа на клиентската част

Използване на Internet Explorer (IE)

Едно от условията за нормална работа на клиентската част 1C е използването на компоненти Internet Explorer. Трябва да сте много внимателни с тези компоненти.

внимание! Първо, ако шпионски или рекламен модул е ​​„прикачен“ към IE, тогава той ще се зареди дори ако преглеждате HTML файлове в 1C. Досега не съм виждал никакво съзнателно използване на тази функция, но видях в една от организациите зареден „шпионски“ модул от една от порнографските мрежи с работещ 1C (антивирусната програма не беше актуализирана, симптомите за които бяха открити : при настройването на защитната стена беше ясно, че 1C се опитва на порт 80 да се свърже с порно сайт). Всъщност това е още един аргумент в полза на факта, че защитата трябва да бъде всеобхватна

внимание! Второ, системата 1C позволява използването на Flash филми, ActiveX обекти, VBScript в показани HTML документи, изпращане на данни в интернет, дори отваряне на PDF файлове (!), Въпреки че в последния случай пита „отвори или запиши“... Като цяло всичко, което сърцето ви желае. Пример за не съвсем разумно използване на вградените възможности за преглед и редактиране на HTML:

• Създайте нов HTML документ (Файл -> Нов -> HTML документ).
• Отидете в раздела "Текст" на празния документ.
• Премахнете текста (изцяло).
• Отидете в раздела "Преглед" на този документ
• С помощта на плъзгане и пускане преместете файл с разширение SWF (това са Flash филмови файлове) от отворен Explorer в прозорец на документ, например от кеша на браузъра, въпреки че можете да използвате и FLASH играчка за забавление.
• Колко хубаво! Можете да стартирате играчка на 1C!

От гледна точка на сигурността на системата това е напълно погрешно. Досега не съм виждал специални атаки срещу 1C чрез тази уязвимост, но най-вероятно ще бъде въпрос на време и стойността на вашата информация.

Има някои други незначителни проблеми, които възникват при работа с поле на HTML документ, но основните са двата изброени. Въпреки че, ако подходите творчески към тези функции, можете да организирате наистина невероятни интерфейсни възможности за работа с 1C.

Използване на външни отчети и обработка.

внимание! Външни доклади и обработка - от една страна - удобен начинвнедряване на допълнителни печатни формуляри, регулаторни отчети, специализирани доклади, от друга страна, потенциален начин за заобикаляне на много ограничения за сигурност на системата и нарушаване на работата на сървъра на приложения (за пример вижте по-горе в „Параметри за предаване“). В системата 1C има специален параметър в набора от права за ролята „Интерактивно отваряне на външна обработка“, но това не решава напълно проблема - за пълно решение е необходимо да стесните кръга от потребители, които могат да управляват външни печатни формуляри, регулаторни доклади и други стандартни възможности на стандартни решения, реализирани чрез външни обработки. Например, по подразбиране в UPP всички главни потребителски роли имат възможност да работят с директория с допълнителни печатни формуляри и това всъщност е възможността да се използва всяка външна обработка.

Използване на стандартни механизми за стандартни решения и платформи (обмен на данни)

Някои от стандартните механизми са потенциално опасни и то по неочаквани начини.

Печат на списъци

Всеки списък (например директория или информационен регистър) в системата може да бъде отпечатан или записан във файл. За да направите това, просто използвайте стандартната функция, достъпна от контекстното меню и менюто „Действия“:

Имайте предвид, че почти всичко, което потребителят вижда в списъците, може да бъде изведено във външни файлове. Единственото нещо, което можем да посъветваме, е да поддържате дневник за отпечатването на документи на сървърите за печат. За особено критични форми е необходимо да конфигурирате панела за действие, свързан с полето на защитената таблица, така че възможността за показване на списък да не е достъпна от този панел и да деактивирате контекстното меню (вижте Фигура 6).

Обмен на данни в разпределена база данни

Форматът за обмен на данни е доста прост и е описан в документацията. Ако потребителят има възможност да замени няколко файла, той може да направи неоторизирани промени в системата (въпреки че това е доста трудоемка задача). Възможността за създаване на периферна база данни при използване на планове за обмен на разпределени бази данни не трябва да е достъпна за обикновените оператори.

Стандартен обмен на XML данни

При стандартен обмен на данни, който се използва за обмен между стандартни конфигурации (например „Управление на търговията“ и „Счетоводство на предприятието“), в правилата за обмен е възможно да се зададат манипулатори на събития за зареждане и разтоварване на обекти. Това се реализира чрез получаване на манипулатор от файла и процедурата “Run()” за стандартна обработка на зареждането и разтоварването на файла (процедурата “Run()” се стартира от страна на клиента). Очевидно не е трудно да се създаде такъв фалшив обменен файл, който ще извърши злонамерени действия. За повечето потребителски роли на стандартни решения споделянето е разрешено по подразбиране.

Препоръка:ограничаване на достъпа до обмена на XML за повечето потребители (оставяйки го само на администраторите по сигурността на информацията). Съхранявайте регистрационни файлове на изпълнението на тази обработка, като запазвате файла за обмен, например, изпращайки го чрез имейладминистратор на информационната сигурност преди изтегляне.

Използване на общи отчети, особено конзолата за отчети

Друг проблем е потребителският достъп по подразбиране до общи отчети, особено отчета на конзолата за отчети. Този отчет се характеризира с факта, че ви позволява да изпълнявате почти всякакви заявки за информационна сигурност и дори ако системата за права 1C (включително RLS) е конфигурирана доста стриктно, тя позволява на потребителя да получи много „допълнителна“ информация и принуждава сървъра да изпълни заявка, която ще изразходва всички ресурси на системата.

Използване на режим на цял екран (режим на работен плот)

Един от ефективните начини за организиране на специализирани интерфейси с ограничен достъп до функционалността на програмата е режимът на цял екран на основната (и вероятно единствената) форма на използвания интерфейс. В този случай няма проблеми с достъпността, например менюто "Файл" и всички потребителски действия са ограничени от възможностите на използвания формуляр. За повече подробности вижте „Характеристики за прилагане на десктоп режим“ на ITS диска.

Архивиране

Архивирането за версията клиент-сървър на 1C може да се извърши по два начина: качване на данни във файл с разширение dt и създаване на резервни копия с помощта на SQL. Първият метод има много недостатъци: изисква се изключителен достъп, самото създаване на копие отнема много повече време, в някои случаи (ако структурата за сигурност на информацията е нарушена) създаването на архив е невъзможно, но има едно предимство - минималният размер на архива. За SQL архивирането е вярно обратното: създаването на копие се извършва във фонов режим с помощта на SQL сървъра, поради простата структура и липсата на компресия - това е много бърз процес и докато физическата цялост на SQL базата данни не е повредена, архивирането се извършва, но размерът на копието съвпада с истинския размер на информационната сигурност в разширено състояние (компресията не се извършва). Поради допълнителните предимства на системата за архивиране на MS SQL е по-препоръчително да се използва (разрешени са 3 типа архивиране: пълно, диференциално, копие на журнала на транзакциите; възможно е да се създават редовно изпълнявани задачи; резервно копие и резервно копие системата се разгръща бързо; възможно е да се предвиди размерът на необходимото дисково пространство и т.н.). Основните точки на организиране на архивиране от гледна точка на сигурността на системата са:

• Необходимостта да изберете място за съхранение на резервни копия, така че да не са достъпни за потребителите.
• Необходимостта от съхраняване на резервни копия на физическо разстояние от MS SQL сървъра (в случай на природни бедствия, пожари, атаки и др.)
• Възможност за даване на права за стартиране на архивиране на потребител, който няма достъп до архивиране.

За повече подробности, моля, вижте документацията на MS SQL.

Криптиране на данни

За защита на данните от неоторизиран достъп често се използват различни криптографски инструменти (както софтуерни, така и хардуерни), но тяхната осъществимост до голяма степен зависи от правилното приложение и цялостната сигурност на системата. Ще разгледаме криптирането на данни на различни етапи от предаването и съхранението на данни с помощта на най-често срещаните средства и основните грешки при проектирането на системата с помощта на криптографски инструменти.

Има няколко основни етапа на обработка на информацията, които могат да бъдат защитени:

• Трансфер на данни между клиентската част на системата и сървъра за приложения
• Прехвърляне на данни между сървъра на приложения и MS SQL Server
• Данни, съхранявани на MS SQL Server (файлове с данни на физически диск)
• Криптиране на данни, съхранявани в информационната сигурност
• Външни данни (във връзка с информационната сигурност)

За данни, съхранявани от страната на клиента и на сървъра на приложения (запазени потребителски настройки, списък с информация за сигурност и т.н.), криптирането е оправдано само в много редки случаи и следователно не се разглежда тук. Когато използваме криптографски инструменти, не трябва да забравяме, че използването им може значително да намали производителността на системата като цяло.

Обща информация за криптографска защита на мрежови връзки при използване на TCP/IP протокол.

Без сигурност всички мрежови връзки са уязвими за неоторизирано наблюдение и достъп. За да ги защитите, можете да използвате криптиране на данни на ниво мрежов протокол. За криптиране на данни, предавани в локална мрежа, най-често се използват IPSec инструменти, предоставени от операционната система.

IPSec инструментите осигуряват криптиране на предаваните данни с помощта на DES и 3DES алгоритми, както и проверка на целостта с помощта на MD5 или SHA1 хеш функции. IPSec може да работи в два режима: транспортен режим и тунелен режим. Транспортният режим е по-подходящ за защита на връзки в локална мрежа. Тунелният режим може да се използва за организиране на VPN връзки между отделни мрежови сегменти или за защита на отдалечена връзка към локална мрежа през отворени канали за данни.

Основните предимства на този подход са:

• Възможност за централизирано управление на сигурността с помощта на инструменти на Active Directory.
• Възможността за изключване на неоторизирани връзки към сървъра на приложения и MS SQL сървъра (например, възможно е да се защити срещу неоторизирано добавяне на информационна сигурност на сървъра на приложения).
• Премахване на "слушането" на мрежовия трафик.
• Не е необходимо да променяте поведението на приложните програми (в този случай 1C).
• Стандартният характер на такова решение.

Този подход обаче има ограничения и недостатъци:

• IPSec не защитава данните от намеса и подслушване директно на компютрите източник и местоназначение.
• Количеството данни, прехвърлени по мрежата, е малко по-голямо, отколкото без използване на IPSec.
• При използване на IPSec натоварването на централния процесор е малко по-високо.

Подробно описание на внедряването на IPSec инструменти е извън обхвата на тази статия и изисква разбиране на основните принципи на функциониране на IP протокола. За да конфигурирате правилно защитата на връзката, моля, прочетете съответната документация.

Отделно е необходимо да се споменат няколко аспекта на лицензионното споразумение с 1C при организиране на VPN връзки. Факт е, че въпреки липсата на технически ограничения, при свързване на няколко сегмента от локална мрежа или отдалечен достъп на отделен компютър към локална мрежа обикновено са необходими няколко основни консумативи.

Криптиране на данни при прехвърляне между клиентската част на системата и сървъра за приложения.

В допълнение към криптирането на ниво мрежов протокол е възможно да се криптират данни на ниво протокол COM+, което е споменато в статията „Регулиране на потребителския достъп до информационната база във версия клиент-сървър“ на ITS. За да го приложите, трябва да зададете ниво на удостоверяване за повиквания към „Поверителност на пакети“ за приложението 1CV8 в „Услуги за компоненти“. Когато е зададен на този режим, пакетът се удостоверява и криптира, включително данните и самоличността и подписа на подателя.

Криптиране на данни при прехвърляне между сървъра на приложения и MS SQL Server

MS SQL Server предоставя следните инструменти за криптиране на данни:

• Възможно е да се използва Secure Sockets Layer (SSL) при прехвърляне на данни между сървъра на приложения и MS SQL Server.
• Когато използвате многопротоколната мрежова библиотека, криптирането на данни се използва на ниво RPC. Това е потенциално по-слабо криптиране от използването на SSL.
• Ако се използва протоколът за обмен на споделена памет (това се случва, ако сървърът на приложения и MS SQL Server се намират на един и същ компютър), тогава криптирането не се използва в никакъв случай.

За да установите необходимостта от криптиране на всички предавани данни за конкретен MS SQL сървър, трябва да използвате помощната програма "Server Network Utility". Стартирайте го и в раздела „Общи“ поставете отметка в квадратчето „Принудително шифроване на протокола“. Методът на криптиране се избира в зависимост от този, използван от клиентското приложение (т.е. сървърът на приложения 1C). За да използвате SSL, трябва да конфигурирате правилно услугата за сертификат във вашата мрежа.

За да зададете необходимостта от криптиране на всички предадени данни за конкретен сървър на приложения, трябва да използвате помощната програма "Client Network Utility" (обикновено намираща се в "C:\WINNT\system32\cliconfg.exe"). Както в предишния случай, в раздела "Общи" поставете отметка в квадратчето "Принудително шифроване на протокола".

Струва си да се има предвид, че използването на криптиране в този случай може да окаже значително влияние върху производителността на системата, особено когато се използват заявки, които връщат големи количества информация.

За по-пълна защита на връзката между сървъра на приложения и MS SQL Server при използване на TCP/IP протокола, можем да препоръчаме няколко промени в настройките по подразбиране.

Първо, можете да зададете порт, различен от стандартния (порт 1433 се използва по подразбиране). Ако решите да използвате нестандартен TCP порт за обмен на данни, имайте предвид, че:

• MS SQL сървърът и сървърът на приложения трябва да използват един и същ порт.
• Когато използвате защитни стени, този порт трябва да бъде разрешен.
• Не можете да зададете порт, който може да се използва от други приложения на MS SQL сървъра. За справка можете да използвате http://www.ise.edu/in-notes/iana/assignments/port-numbers (адресът е взет от SQL Server Books Online).
• Когато използвате множество копия на услугата MS SQL Server, не забравяйте да прочетете документацията на MS SQL за конфигуриране (раздел „Конфигуриране на мрежови връзки“).

Второ, в настройките на TCP/IP протокола на MS SQL сървъра можете да зададете флага „Скриване на сървъра“, който забранява отговорите на заявки за излъчване за този екземпляр на услугата MS SQL Server.

Криптиране на MS SQL данни, съхранявани на диск

Има доста голям избор от софтуер и хардуер за криптиране на данни, разположени на локален диск (това включва стандартната възможност на Windows да използва EFS, използването на ключове eToken и програми на трети страни като Jetico Bestcrypt или PGPDisk). Една от основните задачи, изпълнявани от тези инструменти, е защитата на данните в случай на загуба на медия (например, ако сървърът бъде откраднат). Особено си струва да се отбележи, че Microsoft не препоръчва съхраняването на MS SQL бази данни на криптирани носители и това е напълно оправдано. Основният проблем в този случай е значителен спад в производителността и възможни проблеминадеждност от повреди. Вторият фактор, усложняващ живота на системния администратор, е необходимостта да се гарантира наличността на всички файлове на базата данни в момента, в който услугата MS SQL за първи път има достъп до тях (т.е. желателно е интерактивните действия да бъдат изключени при свързване на криптирана среда).

За да избегнете забележим спад в производителността на системата, можете да използвате възможността на MS SQL за създаване на бази данни в няколко файла. Разбира се, в този случай базата данни MS SQL не трябва да се създава от 1C сървъра при създаването на информационната база, а трябва да се създава отделно. Пример за TSQL скрипт с коментари е даден по-долу:

ИЗПОЛЗВАЙТЕ master
ОТИВАМ
-- Създайте база данни SomeData,
СЪЗДАВАНЕ НА БАЗА ДАННИ SomeData
-- чиито данни се намират изцяло във файловата група PRIMARY.
НА ПЪРВИЧНО
-- Основният файл с данни се намира на криптиран носител (логическо устройство E:)
-- и има първоначален размер от 100 MB, може автоматично да се увеличи до 200 MB с
-- на стъпки от 20 MB
(ИМЕ = Някои данни1,
ИМЕ НА ФАЙЛА = "E:\SomeData1.mdf",
РАЗМЕР = 100MB,
МАКСИМАЛЕН РАЗМЕР = 200,
FILEGROWTH = 2),
-- Вторият файл с данни се намира на некриптиран носител (логическо устройство C:)
-- и има първоначален размер от 100 MB, може да се увеличи автоматично до лимита
-- дисково пространство на стъпки от 5% от текущия размер на файла (закръглено до 64 KB)
(ИМЕ = SomeData2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
РАЗМЕР = 100MB,
МАКСИМАЛЕН РАЗМЕР = НЕОГРАНИЧЕН,
РАСТЕЖ НА ФАЙЛА = 5%)
ВПИСВАМ СЕ
-- Въпреки че регистърът на транзакциите също може да бъде разделен на части, това не трябва да се прави,
-- защото този файл се променя много по-често и се почиства редовно (например, когато
-- създаване на резервно копие на база данни).
(ИМЕ = SomeDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
РАЗМЕР = 10MB,
МАКСИМАЛЕН РАЗМЕР = НЕОГРАНИЧЕН,
FILEGROWTH = 10)
ОТИВАМ
-- По-добре е незабавно да предоставите собственост върху базата данни на потребителя, от чието име
-- 1C ще се свърже. За да направим това, трябва да декларираме текущата база
- току що създаден,
ИЗПОЛЗВАЙТЕ SomeData
ОТИВАМ
-- и изпълнете sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Кратко отклонение за автоматичното нарастване на размера на файла с данни. По подразбиране размерите на файловете за нови бази данни се увеличават на стъпки от 10% от текущия размер на файла. Това е напълно приемливо решение за малки бази данни, но не е много добро за големи: при размер на база данни от например 20 GB, файлът трябва незабавно да се увеличи с 2 GB. Въпреки че това събитие ще се случи доста рядко, то може да продължи няколко десетки секунди (всички други транзакции са ефективно неактивни през това време), което, ако се случи по време на активна работа с базата данни, може да причини някои повреди. Второто отрицателно последствие от пропорционалното увеличение, което се случва, когато дисковото пространство е почти напълно пълно, е вероятността от преждевременен отказ поради недостатъчно свободно пространство. Например, ако дисков дял с капацитет от 40 GB е изцяло посветен на една база данни (по-точно на един файл на тази база данни), тогава критичният размер на файла на базата данни, при който е необходимо спешно (много спешно, до точката на прекъсване на нормалната работа на потребителите) за реорганизиране на съхранението на информация е файл с данни с размер 35 GB. С размера на увеличението, зададен на 10-20 MB, можете да продължите да работите, докато достигнете 39 GB.

Ето защо, въпреки че горният списък посочва увеличение на размера на един от файловете на базата данни на стъпки от 5%, за големи размери на база данни е по-добре да зададете фиксирано увеличение от 10-20 MB. Когато задавате стойностите на нарастване за нарастване на размера на файла на базата данни, е необходимо да се вземе предвид, че докато един от файловете във файлова група достигне максималния си размер, се прилага правилото: файловете в една файлова група се увеличават едновременно време, когато всички са напълно запълнени. Така че в примера по-горе, когато файлът SomeData1.mdf достигне своя максимален размер от 200 MB, файлът SomeData2.ndf ще бъде с размер около 1,1 GB.

След създаването на такава база данни, дори нейните незащитени файлове SomeData2.ndf и SomeData.ldf да станат достъпни за нападател, ще бъде изключително трудно да се възстанови истинското състояние на базата данни - данните (включително информация за логическата структура на базата данни ) ще бъдат разпръснати в няколко файла и ключовата информация (за това, например кои файлове съставляват тази база данни) ще бъде в шифрования файл.

Разбира се, ако се използва съхраняване на файлове на база данни с помощта на криптографски средства, тогава архивирането (поне на тези файлове) не трябва да се извършва на некриптиран носител. За да архивирате отделни файлове на база данни, използвайте подходящия синтаксис на командата BACKUP DATABASE. Моля, имайте предвид, че въпреки че е възможно да защитите резервно копие на база данни с парола (опциите „PASSWORD = “ и „MEDIAPASSWORD = “ на командата „BACKUP DATABASE“), такова архивиране не става криптирано!

Криптиране на данни на сървър на приложения и клиент, съхранявани на дискове

В повечето случаи не може да се счита за оправдано съхраняването на файлове, използвани от 1C:Enterprise (клиентска част и сървър на приложения) на криптиран носител поради неоправдано високи разходи, но ако такава необходимост съществува, имайте предвид, че сървърът на приложения и клиентската част на приложението много често създават временни файлове. Често тези файлове могат да останат след като приложението приключи и е почти невъзможно да се гарантира премахването им с помощта на 1C инструменти. По този начин става необходимо да се шифрова директорията, използвана за временни файлове в 1C, или да не се съхранява на диск с помощта на RAM устройство (последната опция не винаги е възможна поради размера на генерираните файлове и изискванията за RAM на 1C:Enterprise самото приложение).

Криптиране на данни с помощта на вградени 1C инструменти.

Стандартните възможности за използване на криптиране в 1C се свеждат до използване на обекти за работа с Zip файлове с параметри за криптиране. Налични са следните режими на криптиране: AES алгоритъм с ключ от 128, 192 или 256 бита и остарял алгоритъм, първоначално използван в Zip архиватора. Zip файловете, криптирани с AES, не се четат от много архиватори (WinRAR, 7zip). За да генерирате файл, съдържащ криптирани данни, трябва да посочите парола и алгоритъм за криптиране. Най-простият пример за функции за криптиране-декриптиране, базирани на тази функция, е даден по-долу:

Функция EncryptData(данни, парола, метод на криптиране = недефиниран) Експортиране

// Записване на данните във временен файл. Всъщност не всички данни могат да бъдат запазени по този начин.
ValueInFile(TemporaryFileName, Data);

// Записване на временни данни в архива
Zip = Нов ZipFileRecord(TemporaryArchiveFileName, Password, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Write();

// Прочетете данните от получения архив в RAM
EncryptedData = NewValueStorage(NewBinaryData(ArchiveTemporaryFileName));

// Временни файлове - изтриване

Функция EndFunctions DecryptData(EncryptedData, Password) Export

// Внимание! Коректността на подадените параметри не се следи

// Записване на предадената стойност във файл
ArchiveTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);

// Извличане на първия файл от току-що записания архив
TemporaryFileName = GetTemporaryFileName();
Zip = Нов ReadZipFile(TemporaryArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Прочетете записания файл
Данни = ValueFromFile(TemporaryFileName + "\" + Zip.Items.Name);

//Изтриване на временни файлове
DeleteFiles(TemporaryFileName);
DeleteFiles(ArchiveTemporaryFileName);

Данни за връщане;

EndFunction

Разбира се, този метод не може да се нарече идеален - данните се записват във временна папка в чист текст, производителността на метода, честно казано, е по-лоша от всякога, съхранението в базата данни изисква изключително много място, но това е единственият метод, който се базира само на вградените механизми на платформата. В допълнение, той има предимство пред много други методи - този метод едновременно пакетира данни заедно с криптирането. Ако искате да приложите криптиране без недостатъците, които има този метод, трябва или да ги внедрите във външен компонент, или да се обърнете към съществуващи библиотеки чрез създаване на COM обекти, например, като използвате Microsoft CryptoAPI. Като пример ще дадем функциите за криптиране/декриптиране на низ въз основа на получената парола.

Функция EncryptStringDES(UnencryptedString, Password)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Тази константа е от CryptoAPI

EncryptionMechanism.Content = UnencryptedString;
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

върне EncryptedString;

EndFunction // EncryptStringDES()

Функция DecryptStringDES(EncryptedString, Password)

//Внимание! Параметрите не се проверяват!

Encryption Engine = Нов COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Парола);
опит
EncryptionMechanism.Decrypt(EncryptedString);
Изключение
// Грешна парола!;
Връщане Недефинирано;
EndAttempt;

ReturnEncryptionMechanism.Content;

EndFunction // DecryptStringDES()

Моля, имайте предвид, че при прехвърляне празна стойноствъвеждането на низ или парола в тези функции ще генерира съобщение за грешка. Низът, получен чрез тази процедура за криптиране, е малко по-дълъг от оригинала. Спецификата на това криптиране е, че ако шифровате низ два пъти, получените низове НЯМА да бъдат идентични.

Основни грешки при използване на криптографски инструменти.

Когато използвате криптографски инструменти, често се правят същите грешки:

Подценяване на наказанието за производителност при използване на криптография.

Криптографията е задача, която изисква доста голям брой изчисления (особено за алгоритми като DES, 3DES, GOST, PGP). И дори когато се използват високопроизводителни и оптимизирани алгоритми (RC5, RC6, AES), няма спасение от ненужно прехвърляне на данни в паметта и изчислителна обработка. И това почти отрича възможностите на много сървърни компоненти (RAID масиви, мрежови адаптери). Когато използвате хардуерно шифроване или хардуерно извеждане на ключа за шифроване, има допълнително възможно затруднение в производителността: скоростта на трансфер на данни между допълнителното устройство и паметта (където производителността на такова устройство може да не е критична). Когато използвате криптиране на малки количества данни (например имейл съобщение), увеличаването на изчислителното натоварване на системата не е толкова забележимо, но в случай на пълно криптиране на всичко това може значително да повлияе на производителността на системата като цяло.

Подценяване на съвременните възможности за избор на пароли и ключове.

В момента възможностите на технологията са такива, че ключ с дължина 40-48 бита може да бъде избран от малка организация, а ключ с дължина 56-64 бита от голяма организация. Тези. трябва да се използват алгоритми, които използват ключ от поне 96 или 128 бита. Но повечето ключове се генерират с помощта на хеш алгоритми (SHA-1 и т.н.) въз основа на пароли, въведени от потребителя. В този случай ключ с дължина 1024 бита може да не помогне. Първо, често се използва лесна за отгатване парола. Факторите, които улесняват избора са: използване само на един регистър на буквите; използване на думи, имена и изрази в пароли; използване на известни дати, рождени дни и др.; използване на "модели" при генериране на пароли (например 3 букви, след това 2 цифри, след това 3 букви в цялата организация). Добрата парола трябва да бъде сравнително произволна последователност от главни букви, цифри и препинателни знаци. Въведените от клавиатурата пароли с дължина до 7-8 знака, дори и при спазване на тези правила, могат да бъдат познати за разумно време, така че е по-добре паролата да е поне 11-13 знака. Идеалното решение е да се избегне генерирането на ключ с помощта на парола, например с помощта на различни смарт карти и т.н., но в този случай е необходимо да се предвиди възможност за защита срещу загуба на носителя на ключа за криптиране.

Несигурно съхранение на ключове и пароли.

Често срещани примери за тази грешка са:

• дълги и сложни пароли, написани на лепкави бележки, залепени на монитора на потребителя.
• съхраняване на всички пароли във файл, който не е защитен (или е защитен много по-слабо от самата система)
• съхранение на електронни ключове в публичното пространство.
• често прехвърляне на електронни ключове между потребители.

Защо да правим блиндирана врата, ако ключът за нея е под изтривалката?

Прехвърляне на първоначално криптирани данни в незащитена среда.

Когато настройвате система за сигурност, уверете се, че тя върши работата си. Например, попаднах на ситуация (която не е свързана с 1C), когато първоначално криптиран файл, когато програмата работи в ясна форма, беше поставен във временна папка, откъдето можеше да бъде безопасно прочетен. Често резервните копия на криптирани данни в ясна форма се намират някъде „недалеч“ от тези данни.

Използване на криптографски инструменти за други цели

Чрез шифроване на данни по време на пренос не можете да очаквате данните да бъдат недостъпни там, където се използват. Например IPSec услугите по никакъв начин не пречат на сървъра на приложенията да "надушва" мрежовия трафик на ниво приложение.

По този начин, за да избегнете грешки при внедряването на криптографски системи, трябва (най-малко) да направите следното, преди да ги внедрите.

• Разбирам:
  • Какво трябва да се защити?
  • Какъв метод на защита трябва да използвате?
  • Кои части от системата трябва да бъдат защитени?
  • Кой ще контролира достъпа?
  • Ще работи ли криптирането във всички правилни области?
• Определете къде се съхранява информацията, как ще бъде изпратена по мрежата и компютрите, от които информацията ще бъде достъпна. Това ще предостави информация за скоростта, капацитета и използването на мрежата преди внедряването на системата, което е полезно за оптимизиране на производителността.
• Оценете уязвимостта на системата към различни видове атаки.
• Разработете и документирайте план за сигурност на системата.
• Оценете икономическата ефективност (оправданост) от използването на системата.

Заключение

Разбира се, в бърз преглед е невъзможно да се посочат всички аспекти, свързани със сигурността в 1C, но нека си позволим да направим някои предварителни заключения. Разбира се, тази платформа не може да се нарече идеална - тя, както много други, има своите проблеми при организирането на защитена система. Но това в никакъв случай не означава, че тези проблеми не могат да бъдат заобиколени, а напротив, почти всички недостатъци могат да бъдат отстранени с правилното разработване, внедряване и използване на системата. Повечето проблеми възникват поради недостатъчно развитие на конкретно решение за приложение и неговата среда за изпълнение. Например стандартните решения без значителни промени просто не предполагат създаването на достатъчно сигурна система.

Тази статия още веднъж демонстрира, че всеки набор от мерки за сигурност трябва да обхваща всички етапи на внедряване: разработка, внедряване, администриране на системата и, разбира се, организационни мерки. В информационните системи „човешкият фактор“ (включително потребителите) е основната заплаха за сигурността. Този набор от мерки трябва да бъде разумен и балансиран: няма смисъл и е малко вероятно да бъдат отделени достатъчно средства за организиране на защита, която надвишава цената на самите данни.

Компания е уникална услуга за купувачи, разработчици, дилъри и афилиейт партньори. В допълнение, това е един от най-добрите онлайн магазини за софтуер в Русия, Украйна и Казахстан, който предлага на клиентите широка гама от продукти, много методи на плащане, бърза (често моментална) обработка на поръчките и проследяване на процеса на поръчка в личен раздел .