1с надто складний запит можливе переповнення стека. Перенесення даних через COMConnector. Мережевий файловий доступ із сервера терміналів має бути обмежений

Керівництво програміста Informix® DataBlade™ API доступне для завантаження в . Розділ "Managing Stack Space" описує створення функцій користувача (UDR). Ця стаття надає додаткову інформацію та поради щодо налагодження.

Нижченаведена інформація справедлива незалежно від того, чи виконується UDR на певному користувачем віртуальному процесорі (VP), чи CPU VP. Стек нитки може бути переміщений певний користувачем віртуальний процесор безпосередньо перед виконанням UDR.

Стек якого розміру виділяється для UDR?

Розмір стека, доступного для UDR, залежить від того, як UDR була створена:

за допомогою модифікатора STACK, який дозволяє UDR використовувати свій спеціально виділений стек,

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

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

Вирази СREATE PROCEDURE або CREATE FUNCTION мають опціональний модифікатор STACK, який дозволяє вказати розмір простору стека в байтах, який необхідний для виконання UDR.

Якщо Ви використовуєте модифікатор STACK під час створення UDR, сервер виділятиме і звільнятиме простір стека при кожному виконанні UDR. Справжній доступний розмір дорівнює значенню STACK у байтах мінус деякі накладні витрати, що залежать від кількості аргументів функції.

Якщо величина STACK менша, ніж значення параметра STACKSIZE у файлі onconfig (див. наступний розділ), то розмір стека, що виділяється для UDR, буде автоматично округлятися до величини STACKSIZE.

Параметр конфігурації STACKSIZE

Файл конфігурації onconfig включає параметр STACKSIZE, який визначає розмір стека за замовчуванням для користувацьких ниток.

Якщо Ви не вказуєте STACK під час створення UDR, сервер не виділяє додатковий простір стека для виконання цієї UDR. Натомість UDR використовує простір стека, виділений для виконання запиту. Доступний розмір стека залежатиме від накладних витрат виконання функції лише на рівні SQL.

Стек для нитки виділяється один раз для конкретної нитки, що виконує запит. Швидкодія вище, коли UDR ділить один стек з ниткою, оскільки сервер не витрачає ресурсів виділення додаткового стека кожному за виклику UDR. З іншого боку, якщо розмір стека, що використовується, наближається до значення STACKSIZE, це може викликати переповнення стека при виклику функції у складі запиту (у цьому випадку для виконання UDR буде доступно менше простору стека).

Слід пам'ятати, що не варто встановлювати завищене значення STACKSIZE, так як це торкнеться всіх ниток користувача.

Коли потрібно керувати розміром стека?

YВи повинні керувати простором стека якщо 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. Наприклад:

Після зміни значення STACK слід протестувати оригінальний запит, щоб переконатися, що він тепер працює стабільно.

Збільшення STACKSIZE

В якості альтернативи спробуйте збільшити значення STACKSIZE. Перевірте, чи це вирішило проблему. (Пізніше не забудьте повернути старе значення).

Якщо збільшення STACKSIZE не допомогло, швидше за все проблема пошкодження пам'яті. Ось кілька пропозицій:

Увімкніть memory scribble та перевірку пулів пам'яті. Розділ "Debugging Problems" у статті Memory Allocation for UDRs пояснює, як це зробити.

Перегляньте використання mi_lvarchar . Особливу увагу слід приділити місцям, де mi_lvarchar передається функції, яка очікує отримати нуль-термінований рядок як аргумент.

Скоротіть кількість CPU (або власних) VP до одного, щоб відтворити проблему швидше.

mi_print_stack() -- Solaris

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

/tmp/default.stack

Ви не можете змінити ім'я файлу виводу, але можна змінити його розташування, змінивши значення змінної оточення DBTEMP. Переконайтеся, що у директорію $DBTEMP дозволено запис користувача informix. Будь-які помилки, які виникають під час виконання mi_print_stack() виводяться в $MSGPATH.

Ця функція доступна лише для OC Solaris.

Глосарій

Терміни та скорочення, що використовуються в даній статті:

Ця стаття ще раз демонструє, що будь-який комплекс заходів щодо безпеки повинен охоплювати всі етапи впровадження: розробку, розгортання, системне адміністрування та, обов'язково, організаційні заходи. В інформаційних системах саме "людський фактор" (зокрема користувачі) – головна загроза безпеці. Цей комплекс заходів має бути розумним і збалансованим: немає сенсу і навряд чи буде виділено достатні кошти на організацію захисту, яка перевищує за вартістю самі дані.

Вступ

1С:Підприємство є найпоширенішою обліковою системою в Росії системою, але, незважаючи на це, до версії 8.0 її розробники приділяли вкрай мало уваги питанням безпеки. В основному, звичайно, це диктувалося ціновою нішою продукту та орієнтацією на малі підприємства, де відсутні кваліфіковані ІТ-фахівці, і можлива вартість розгортання та підтримки захищеної системи була б недозволено дорогою для підприємства. З випуском версії 8.0 акценти мали змінитися: вартість рішень значно зросла, система стала значно масштабованішою і гнучкішою – вимоги значно змінилися. Чи стала система досить надійною та захищеною – це питання дуже індивідуальне. Основна інформаційна система сучасного підприємства має задовольняти як мінімум наступним вимогам безпеки:

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

Чи задовольняють рішення на базі 1С:Підприємства 8.0 таким вимогам? Однозначної відповіді немає. Незважаючи на значні зміни в системі управління доступом, залишилося досить багато невирішених питань. Залежно від того, як розроблена та налаштована система, всі ці вимоги можуть не виконуватися або виконуватися в достатній для даного впровадження мірі, проте варто звернути увагу (і це істотне наслідок "юності" платформи), що для повного виконання перерахованих умов доводиться прикладати воістину титанічні зусилля.

Ця стаття призначена для розробників та впроваджувачів рішень на платформі 1С:Підприємство, а також системних адміністраторів організацій, де використовується 1С:Підприємство, та описує деякі моменти розробки та налаштування клієнт-серверного варіанта системи з точки зору організації інформаційної безпеки. Ця стаття не може використовуватися як заміна документації, а лише вказує на деякі моменти, що не знайшли поки в ній відображення. І, звичайно, ні ця стаття, ні вся документація не зможуть відобразити всю складність проблеми побудови захищеної інформаційної системи, яка водночас має задовольняти суперечливі вимоги безпеки, продуктивності, зручності та функціональності.

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

Ключовим предметом розгляду статті є інформаційні загрози.

Інформаційна загроза– можливість ситуації, коли дані несанкціоновано будуть прочитані, скопійовані, змінені чи заблоковані.

І, виходячи з цього визначення, у статті інформаційні загрози класифікуються таким чином:

• Несанкціоноване знищення даних
• Несанкціонована зміна даних
• Несанкціоноване копіювання даних
• Несанкціоноване читання даних
• Недоступність даних

Усі загрози поділяються на навмисні та ненавмисні. Реалізовану інформаційну загрозу називатимемо інцидентом. Особливостями системи є:

В основному розглядаються лише ті випадки, ймовірність яких обумовлена ​​застосуванням саме технологічної платформи 1С: Підприємство 8.0 у клієнт-серверному варіанті (далі, коли це не суперечить сенсу просто 1С або 1С 8.0). Визначимо такі основні ролі стосовно використання системи:

• Оператори– користувачі, які мають обмежені прикладною роллю права на перегляд та зміну даних, але не мають адміністративних функцій
• Адміністратори системи- Користувачі, які мають адміністративні права в системі, у тому числі адміністративні права в операційних системах сервера додатків і сервера MS SQL, адміністративні права на MS SQL і т.п.
• Адміністратори ІБ- Користувачі, яким делеговані окремі адміністративні функції в інформаційній базі 1С (такі як додавання користувачів, тестування та виправлення, резервне копіювання, налаштування прикладного рішення тощо)
• Розробники системи- Користувачі, які розробляють прикладне рішення. У випадку доступу до робочої системі можуть мати.
• Особи, які не мають безпосереднього доступу до системи– користувачі, яким не делеговані права на доступ до 1С, але які тією чи іншою мірою можуть впливати на роботу системи (зазвичай це всі користувачі того ж домену Active Directory, в якому встановлено систему). Ця категорія розглядається насамперед виявлення потенційно небезпечних суб'єктів у системі.
• Автоматизовані адміністративні сценарії– програми, яким делеговані деякі функції, призначені для автоматичного виконання деяких дій (наприклад, імпорт-експорт даних)

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

Будь-яка система безпеки має створюватися з урахуванням доцільності та вартості володіння. Загалом під час розробки та впровадження інформаційної системи необхідно, щоб ціна захисту системи відповідала:

• цінності інформації, що захищається;
• витрат на створення інциденту (у разі навмисної загрози);
• фінансовим ризикам у разі інциденту

Безглуздо та шкідливо організовувати захист значно дорожчий, ніж оцінка його фінансової ефективності. Є кілька методик оцінки ризиків втрати інформації, але у межах цієї статті вони розглядаються. Іншим важливим аспектом є дотримання балансу, що найчастіше суперечать один одному вимог до інформаційної безпеки, продуктивності системи, зручності та простоті роботи з системою, швидкості розробки та впровадження та інших вимог до інформаційних систем підприємств.

Основні особливості механізму інформаційної безпеки системи

1С:Підприємство 8.0 поставляється у двох варіантах: файловий та клієнт-серверний. Файловий варіант не можна вважати таким, що забезпечує інформаційну безпеку системи з наступних причин:

• Дані та конфігурація зберігаються у файлі, доступному для читання та запису всім користувачам системи.
• Як нижче буде показано, авторизація системи дуже легко обходиться.
• Цілісність системи забезпечується лише ядром клієнтської частини.

У клієнт-серверному варіанті для зберігання інформації використовується MS SQL Server, що забезпечує:

• Більш надійне зберігання даних.
• Ізоляція файлів від прямого доступу.
• Більш досконалі механізми транзакцій та блокувань.

Незважаючи на значні відмінності файлового та клієнт-серверного варіанта системи, вони мають єдину схему контролю доступу на рівні прикладного рішення, які надають такі можливості:

• Авторизація користувача по паролю заданому в 1С.
• Авторизація користувача за поточним користувачем Windows.
• Призначення ролей для користувачів системи.
• Обмеження виконання адміністративних функцій за ролями.
• Призначення доступних інтерфейсів за ролями.
• Обмеження доступу до об'єктів метаданих за ролями.
• Обмеження доступу до реквізитів об'єктів за ролями.
• Обмеження доступу до об'єктів даних за ролями та параметрами сеансу.
• Обмеження інтерактивного доступу до даних та виконуваних модулів.
• Деякі обмеження виконання коду.

В цілому, схема доступу до даних, що використовується, досить типова для інформаційних систем такого рівня. Однак стосовно даної реалізації триланкової клієнт-серверної архітектури є кілька важливих аспектів, які призводять до відносно великої кількості вразливостей:

1. Велика кількість етапів обробки даних, причому на кожному етапі можуть діяти різні правила доступу до об'єктів.

   Дещо спрощена схема етапів обробки даних, суттєвих з погляду безпеки, наведена на рис.1. Загальним правилом для 1С є зменшення обмежень у міру переходу вниз за цією схемою, тому використання вразливості на одному з верхніх рівнів може порушити роботу системи на всіх рівнях.

2. Недостатньо налагоджені процедури контролю даних, що передаються при переході з рівня на рівень.

   На жаль, далеко не всі внутрішні механізми системи ідеально налагоджені, особливо це стосується неінтерактивних механізмів, налагодження яких завжди з одного боку трудомісткіша, але з іншого більш відповідальна. Ця "хвороба" не є проблемою виключно фірми 1С, вона зустрічається в багатьох серверних продуктах більшості вендорів. Лише останніми роками увага до цих проблем значно зросла.

3. Недостатньо висока середня кваліфікація розробників та адміністраторів систем, що дісталася у спадок від попередньої версії.

   Продукти лінійки 1С:Підприємство спочатку були орієнтовані на простоту розробки та підтримки і на роботу в невеликих організаціях, тому не дивно, що історично склалося так, що значна частина "розробників" прикладних рішень і "адміністраторів" систем не мають достатніх знань і навичок для роботи зі значно складнішим продуктом, яким є версія 8.0. Проблему ускладнює і прийнята в компаніях-франчайзі практика навчати "в бою" за рахунок клієнтів, не підходячи системно до цього питання. Необхідно віддати належне фірмі 1С у тому, що за останні кілька років ця ситуація поступово виправляється: серйозні компанії-франчайзі стали відповідальніше підходити до проблеми підбору та навчання персоналу, рівень інформаційно-технологічної підтримки з боку фірми 1С значно зріс, з'явилися програми сертифікацій орієнтовані на високий рівень сервісу; але моментально ситуацію виправити не можна, тому цей чинник слід враховувати під час аналізу безпеки системи.

4. Порівняно невеликий вік платформи.

   Серед продуктів подібної спрямованості та цілей використання це одне з наймолодших рішень. Функціональність платформи більш-менш устояла менше року тому. При цьому кожен реліз платформи, починаючи в 8.0.10 (саме в цьому релізі були реалізовані майже всі нинішні можливості системи) ставав значно стабільнішим за попередні. Функціональність типових прикладних рішень досі зростає не щодня, а щогодини, хоча з можливостей платформи використовується від сили половина. Звичайно, в таких умовах говорити про стабільність, можна досить умовно, але в цілому необхідно визнати, що вже у багатьох відношеннях рішення на платформі 1С 8.0 значно обганяють за функціональністю та продуктивністю (а нерідко і стабільністю) аналогічні рішення на платформі 1С 7.7.

Отже, система (і, можливо, типове прикладне рішення) розгортається для підприємства і встановлюється на комп'ютери. В першу чергу необхідно створити таке середовище, в якому матиме сенс налаштування безпеки 1С, а для цього його необхідно налаштувати таким чином, щоб припущення, що на безпеку системи суттєво впливають налаштування системи, виконувалося.

Дотримуйтесь загальних правил безпеки.

Ні про яку інформаційну безпеку системи не може бути й мови, якщо не дотримуються основних принципів створення безпечних систем. Обов'язково переконайтеся, що хоча б такі умови забезпечені:

• Доступ до серверів фізично обмежений та забезпечена їхня безперебійна робота:
  • серверне обладнання відповідає вимогам надійності, заміна несправного серверного обладнання налагоджена, для особливо критичних ділянок використовуються схеми з дублюванням апаратного забезпечення (RAID, живлення від кількох джерел, кілька каналів зв'язку тощо);
  • сервери знаходяться в замиканні, причому це приміщення відкривається тільки на час робіт, які не можуть бути виконані віддалено;
  • право відкривати приміщення серверів є лише в однієї-двох осіб, у разі екстреної необхідності розроблено систему оповіщення відповідальних осіб;
  • забезпечено безперебійне електроживлення серверів
  • забезпечено нормальний кліматичний режим роботи обладнання;
  • у приміщенні серверів є пожежна сигналізація, немає ймовірності затоплення (особливо стосується перших та останніх поверхів);
• Налаштування мережі та інформаційної інфраструктури підприємства виконано коректно:
  • на всіх серверах встановлені та налаштовані брандмауери;
  • всі користувачі та комп'ютери авторизовані у мережі, паролі досить складні, щоб їх не можна було підібрати;
  • у операторів системи достатньо прав для нормальної роботи з нею, але немає прав на адміністративні дії;
  • на всіх комп'ютерах мережі встановлені та включені антивірусні засоби;
  • бажано, щоб користувачі (крім адміністраторів мережі) не мали адміністративних прав на клієнтських робочих місцях;
  • доступ до Інтернету та до знімних носіїв інформації має бути регламентований та обмежений;
  • системний аудит подій безпеки має бути налаштований;
• Вирішено основні організаційні питання:
  • користувачі мають достатню кваліфікацію для роботи з 1С та апаратними засобами;
  • користувачі сповіщені про відповідальність порушення правил експлуатації;
  • призначені матеріально відповідальні за кожен матеріальний елемент інформаційної системи;
  • всі системні блоки опломбовані та закриті;
  • особливу увагу приділіть інструктажу та контролю над прибиральниками приміщень, будівельниками та електриками. Ці особи можуть по необережності завдати шкоди, яка не порівнянно більше навмисної шкоди, заподіяної несумлінним користувачем системи.

Увага!Даний список не є вичерпним, а лише описує те, що нерідко упускається при розгортанні будь-якої досить складної та дорогої інформаційної системи!

• MS SQL Server, сервер додатків та клієнтська частина працюють на різних комп'ютерах, серверні програми працюють під правами спеціально створених користувачів Windows;
• Для MS SQL Server
  • встановлено режим змішаної авторизації
  • користувачі MS SQL, що входять у роль serveradmin, не беруть участь у роботі 1С,
  • для кожної ІБ 1С створено окремий користувач MS SQL, який не має привілейованого доступу до сервера,
  • користувач MS SQL однієї ІБ не має доступу до інших ІБ;
• Користувачі не мають безпосереднього доступу до файлів сервера додатків та сервера MS SQL
• Робочі місця операторів оснащені Windows 2000/XP (не Windows 95/98/Me)

Не нехтуйте рекомендаціями розробників системи та читанням документації. На дисках ІТС у розділі "Методичні рекомендації" публікуються важливі матеріали щодо налаштування системи. Особливу увагу зверніть на такі статті:

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

Але, читаючи документацію, критично ставтеся до отриманої інформації, наприклад, у статті "Питання установки та налаштування 1C:Підприємства 8.0 у варіанті "клієнт-сервер"" не зовсім точно описані права, які потрібні користувачеві USER1CV8SERVER. На наведений список нижче будуть зустрічатися посилання, наприклад [ИТС1] означає статтю "Особливості роботи додатків з сервером 1С:Підприємства". Всі посилання на статті дано на останній на момент написання випуску ІТС (січень 2006 р.)

Використовуйте для користувачів можливості авторизації, поєднаної з авторизацією Windows

Із двох можливих режимів авторизації користувачів: вбудована 1С та суміщена з авторизацією ОС Windows – по можливості слід вибрати суміщену авторизацію. Це дозволить користувачам не плутатися з кількома паролями під час роботи, але не знизить рівень безпеки системи. Однак, навіть для користувачів, які використовують лише авторизацію Windows, вкрай бажано при створенні задати пароль, і лише після цього вимкнути авторизацію 1С для цього користувача. Для відновлення системи у разі руйнування структури Active Directory необхідно залишити хоча б одного користувача, який може увійти в систему, використовуючи авторизацію 1С.

Створюючи ролі прикладного рішення, не додавайте прав "про запас"

Кожна роль прикладного рішення має відбивати мінімально необхідний набір прав до виконання дій, визначених цією роллю. У цьому деякі ролі можуть використовуватися самостійно. Наприклад, для інтерактивного запуску зовнішніх обробок можна створити окрему роль і додати її всім користувачам, які мають використовувати зовнішні обробки.

Проводьте регулярний перегляд журналів реєстрації та протоколів роботи системи

По можливості регламентуйте та автоматизуйте перегляд журналів реєстрації та протоколів роботи системи. При правильному налаштуванні та регулярному перегляді журналів (з фільтрацією лише за важливими подіями) можна вчасно виявити несанкціоновані дії або навіть запобігти їх на етапі підготовки.

Деякі особливості роботи клієнт-серверного варіанта

У цьому розділі описано деякі особливості роботи клієнт-серверного варіанта та їх вплив на безпеку. Для більшої зручності при прочитанні прийнято такі позначення:

Увага! опис вразливості

Зберігання інформації, що управляє доступом до системи

Зберігання списку користувачів ІБ

Вся інформація про список користувачів даної ІБ і доступні їм ролі в ній зберігається в таблиці Params в базі даних MS SQL (див. [ИТС2]). Поглянувши на структуру та вміст цієї таблиці, стає очевидним, що вся інформація про користувачів зберігається у записі зі значенням поля FileName – "users.usr".

Так як ми припускаємо, що користувачі не мають доступу до БД MS SQL, то сам по собі цей факт не може бути використаний зловмисником, однак у разі можливості виконання коду на MS SQL це відкриває двері на отримання будь-якого (!) доступу з 1С . Той самий механізм (з незначними змінами) можна використовувати і файлової версії системи, що, враховуючи особливості файлової версії, повністю виключає застосовність їх у побудові безпечних систем.

Зберігання інформації про список ІБ на сервері

До кожного сервера додатків 1С зберігається інформацію про списку підключених до нього БД MS SQL. p align="justify"> Кожна інформаційна база для роботи використовує свій рядок з'єднання сервера додатків і сервера 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 під одним набором прав (скоріше за все надлишковим)
• З процесу сервера додатків 1С (або в загальному випадку від користувача USER1CV8SERVER або його аналога) без вказівки пароля можна легко підключатися до будь-якої ІБ без вказівки пароля

З іншого боку, зловмиснику може бути можливість виконувати довільний код з контексту користувача USER1CV8SERVER може бути складніше, ніж отримати зазначений файл. До речі, наявність такого файлу – ще один аргумент за рознесення серверних функцій різні комп'ютери.

На жаль, за замовчуванням цей файл майже не захищений від прочитання, що необхідно враховувати при розгортанні системи. Ідеальним варіантом було б, якби сервер додатків під час роботи запобігав читанню та запису даного файлу (у тому числі читання та запис виконуваними на цьому сервері підключеннями користувачів).

Відсутність авторизації при створенні ІБ на сервері

Увага! Помилка відсутності авторизації була виправлена ​​у релізі 8.0.14 платформи 1С:Підприємство. У цьому релізі з'явилося поняття "Адміністратор сервера 1С:Підприємство", але поки на сервері вказано список адміністраторів, система діє так, як описано нижче, тому не забувайте про цю можливу особливість.

Напевно, найбільшою вразливістю з цього розділу є можливість майже необмежено додавати ІБ сервер додатків, внаслідок чого будь-який користувач, який отримав доступ до з'єднання з сервером додатків автоматично отримує можливість запускати довільний код на сервері додатків. Розглянемо це з прикладу.

Повинна бути встановлена ​​система у наступному варіанті

• MS SQL Server 2000 (наприклад, ім'я мережі SRV1)
• Сервер 1С:Підприємство 8.0 (мережеве ім'я SRV2)
• Клієнтська частина 1С:Підприємство 8.0 (мережеве ім'я WS)

Передбачається, що користувач (далі USER), що працює на WS, має хоча б мінімальний доступ до однієї з ІБ, зареєстрованих на SRV2, але не має привілейованого доступу до SRV1 і SRV2. У цілому нині поєднання функцій перерахованими комп'ютерами впливає ситуацію. Налаштування системи виконано з урахуванням рекомендацій у документації та на дисках ІТС. Ситуація відбито на рис. 2.

• налаштувати безпеку COM+ на сервері додатків таким чином, щоб лише користувачі 1С мали право на підключення до процесу сервера додатків (детальніше [ІТС12]);
• файл srvrib.lst повинен бути доступний тільки для читання користувачеві USER1CV8SERVER (для додавання нової ІБ на сервер тимчасово дозволяти запис);
• для підключення до MS SQL використовувати лише протокол TCP/IP, у цьому випадку можна:
  • обмежувати підключення за допомогою брандмауера;
  • налаштувати використання нестандартного порту TCP, що ускладнить підключення "сторонніх" ІБ 1С;
  • використовувати шифрування переданих даних між сервером додатків та сервером SQL;
• налаштувати брандмауер сервера так, щоб використання сторонніх серверів MS SQL було неможливим;
• використовувати внутрімережеві засоби безпеки для унеможливлення появи неавторизованого комп'ютера в локальній мережі (IPSec, групові політики безпеки, брандмауери тощо);
• у жодному разі не надавати користувачеві USER1CV8SERVER адміністративні права на сервері додатків.

Використання коду, що виконується на сервері

При використанні клієнт-серверного варіанта 1С розробник може розподіляти виконання коду між клієнтом та сервером додатків. Для того, щоб код (процедура або функція) виконувався тільки на сервері, необхідно розташувати її в загальному модулі, для якого встановлено властивість "Сервер" і, у разі, коли виконання модуля дозволено не тільки на сервері, розташувати код у секцію обмежену "#Якщо Сервер ":

#Якщо Сервер Тоді
Функція На сервері (Парам1, Парам2 = 0) Експорт // Ця функція, незважаючи на її простоту, виконується на сервері
Парам1 = Парам1 + 12;
Повернення Парам1;
КінецьФункції
#КінецьЯкщо

При використанні коду, що виконується на сервері, необхідно враховувати, що:

• код виконується з правами USER1CV8SERVER на сервері програм (доступні COM-об'єкти та файли сервера);
• всі сесії користувача виконуються одним екземпляром служби, тому, наприклад, переповнення стека на сервері викликає відключення всіх активних користувачів;
• налагодження серверних модулів утруднена (наприклад, у відладчику не можна поставити точку зупинки), але має бути здійснена;
• передача управління від клієнта серверу додатків і назад може вимагати значних ресурсів при великих обсягах параметрів, що передаються;
• використання інтерактивних засобів (форм, табличних документів, діалогових вікон), зовнішніх звітів та обробок у коді на сервері додатків неможливе;
• використання глобальних змінних (змінні модулі програми, оголошені із зазначенням "Експорт") неприпустимо;

Докладніше див. [ІТС15] та інші статті ІТС.

До сервера програм повинні пред'являтися особливі вимоги щодо надійності. У правильно збудованій клієнт-серверній системі повинні бути виконані такі умови:

• ніякі дії клієнтської програми не повинні переривати роботу сервера (крім адміністративних випадків);
• на сервері не може виконуватись програмний код, отриманий від клієнта;
• ресурси повинні "справедливо" розподілятися за підключеннями клієнтів, забезпечуючи доступність сервера незалежно від поточної завантаженості;
• у разі відсутності блокувань даних, підключення клієнтів не повинні впливати на роботу один одного;
• на сервері немає інтерфейсу користувача, але повинні бути розвинені засоби моніторингу і протоколювання;

В цілому система 1С побудована так, щоб наблизитися до даних вимог (наприклад, змусити зовнішні обробки виконуватися на сервері неможливо), але кілька неприємних особливостей все ж таки існує, тому:

Загальною рекомендацією буде ознайомитись із принципами побудови безпечних веб-Додатків для баз даних і працювати за подібними принципами. Подібність, справді чимала: по-перше, як і веб-додаток, сервер додатків це проміжний шар між БД та інтерфейсом користувача (основна відмінність у тому, що веб-сервер формує інтерфейс користувача); по-друге, з погляду безпеки не можна довіряти отриманим від клієнта даним, т.к. можливий запуск зовнішніх звітів та обробок.

Передача параметрів

Передача параметрів функції (процедурі), що виконується на сервері, досить тонке питання. Це насамперед пов'язані з необхідністю передачі їх між процесом сервера додатків і клієнта. При переході управління з клієнтської частини на серверну всі параметри, що передаються, серіалізуються, передаються на сервер, де "розпаковуються" і використовуються. При переході із серверної частини на клієнтську – зворотний процес. Тут необхідно відзначити, що дана схема коректно обробляє передачу параметрів за посиланням та за значенням. При передачі параметрів діють такі відмежування:

• Передавати між клієнтом та сервером (в обидві сторони) можна лише немутабельні значення (тобто значення яких не можуть змінюватися): примітивні типи, посилання, універсальні колекції, значення системних перерахувань, сховище значення. При спробі передати щось інше – аварійне завершення клієнтської програми (навіть якщо передавати некоректний параметр намагається сервер).
• Не рекомендується при передачі параметрів передавати великі обсяги даних (наприклад, рядки понад 1 мільйон символів), це може негативно позначитися на продуктивності сервера.
• Не можна передавати параметри, що містять циклічне посилання, причому з сервера на клієнт, так і назад. При спробі передати такий параметр – аварійне завершення клієнтської програми (навіть, якщо передавати некоректний параметр намагається сервер).
• Не рекомендується надсилати дуже складні колекції даних. При спробі передачі параметра з дуже великим рівнем вкладення відбувається аварійне завершення сервера (!).

Увага! Найнеприємнішою особливістю на даний момент, напевно, є помилка передачі складних колекцій значень. Так, наприклад, код: РівеньВкладеності = 1250;
М = Новий Масив;
Параметр = М;
Для Сч = 1 По РівеньВкладення Цикл
МВнутр = Новий Масив;
М.Додати(МВнутр);
М = МВнутр;
КінецьЦикл;
Серверна Функція (Передається Параметр);

Приводить до аварійної зупинки сервера з відключенням всіх користувачів, причому це відбувається до передачі керування кодом вбудованою мовою.

Використання небезпечних функцій на стороні сервера.

Не всі засоби вбудованої мови можна використовувати в коді, що виконується на сервері додатків, але навіть серед доступного інструментарію є безліч "проблемних" конструкцій, які можна умовно класифікувати так:

• здатні надати можливість виконання коду, що не міститься в конфігурації (група "Виконання коду")
• здатні надати в клієнтську програму інформацію про файлову та операційну систему користувача або виконати дії, не пов'язані з роботою з даними ("Порушення прав")
• здатні викликати аварійну зупинку сервера або такі, що використовують дуже великі ресурси (група "Збій сервера")
• здатні викликати відмову у роботі клієнта (група "Збій клієнта") – цей вид не розглядається. Приклад: передачі мутабельного значення на сервер.
• помилки алгоритмів програмування (нескінченні цикли, необмежена рекурсія тощо) ("Помилки програмування")

Основні відомі мені проблемні конструкції (з прикладами) наведені нижче:

Процедура Виконати(<Строка>)

Виконання коду.Дозволяє виконати фрагмент коду, який передається йому як рядкове значення. При використанні на сервері необхідно простежити, щоб як параметр не використовувалися дані, отримані з клієнта. Наприклад, неприпустиме наступне використання:

#Якщо Сервер Тоді
Процедура На Сервері (Парам1) Експорт
Виконати (Парам1);
КінецьПроцедури
#КінецьЯкщо

Тип "COMОб'єкт" (конструктор Новий COMОб'єкт (<Имя>, <Имя сервера>))

Створює COM-об'єкт зовнішньої програми під правами USER1CV8SERVER на сервері програм (або іншому вказаному комп'ютері). При використанні на сервері, слідкуйте, що параметри не передаються з клієнтської програми. Однак на стороні сервера ефективно використовувати цю можливість при імпорті/експорті, надсиланні даних через Інтернет, реалізації нестандартних функцій тощо.

Функція ОтриматиCOMОб'єкт(<Имя файла>, <Имя класса COM>)

Порушення прав та виконання коду.Аналогічно попередньому лише отримання COM-об'єкта, відповідного файлу.

Процедури та функції Ім'яКомп'ютера(), КаталогТимчасовихФайлів(), КаталогПрограми(), КористувачіWindows()

Порушення прав.Дозволяють, виконавши їх у сервері, з'ясувати деталі організації серверної підсистеми. При використанні на сервері, простежити, що дані не передаються на клієнт, або не доступні операторам без відповідного допуску. Особливу увагу зверніть на те, що дані можуть бути передані у параметрі, переданому за посиланням.

Процедури та функції роботи з файлами (Копіювати файл, Знайти файли, Об'єднати файли та багато інших), а також типи файлу.

Порушення прав.Дозволяють, виконавши їх на сервері, отримати спільний доступ до локальних (і розміщених у мережі) файлів, доступних під правами користувача USER1CV8SERVER. Якщо використовуються усвідомлено, можлива ефективна реалізація таких завдань, як імпорт/експорт даних на сервері.

Перед використанням цих функцій обов'язково перевіряйте права користувача 1С. Для перевірки прав користувача можна використовувати таку конструкцію в модулі сервера:

#Якщо Сервер Тоді
Процедура ВиконатиРоботуСфайлом() Експорт
РольАдміністратор = Метадані.Ролі.Адміністратор;
Користувач = Параметри Сеансу.ПоточнийКористувач;
Якщо Користувач.Ролі.Утримує(РольАдміністратор) Тоді
//Тут виконується код роботи з файлами
КінецьЯкщо;
#КінецьЯкщо

Обов'язково перевіряйте параметри, якщо застосовуєте ці процедури та функції, інакше залишається ризик завдати випадково або усвідомлено непоправної шкоди серверу додатків 1С, наприклад, при виконанні на сервері коду:

Шлях = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
ПереміститиФайл(Шлях + "srvrib.lst", Шлях + "ОтКудаДелсяФайл");

Після виконання такого коду на сервері, якщо користувач USER1CV8SERVER має право на його зміну, про що було написано вище, і після перезапуску процесу сервера (за замовчуванням через 3 хвилини після виходу всіх користувачів), виникне ВЕЛИКЕ питання щодо запуску сервера. Адже можливе і повне видалення файлів...

Типи "XBase", "ДвійковіДані", "ЧитанняXML", "ЗаписXML", "ПеретворенняXSL", "ЗаписZipФайлу", "ЧитанняZipФайлу", "ЧитанняТексту", "ЗаписТексту"

Порушення прав.Дозволяють, виконавши їх на сервері, отримати доступ до локальних (і розміщених у мережі) певних типів файлів і виконувати їх читання/запис під правами користувача USER1CV8SERVER. Якщо використовуються усвідомлено, можлива ефективна реалізація таких завдань, як імпорт/експорт даних на сервері, протоколювання роботи деяких функцій, вирішення адміністративних завдань. В цілому рекомендації збігаються з попереднім пунктом, але слід враховувати можливості передачі цих файлів (але не об'єктів всіх цих типів) між клієнтською та серверною частиною.

Тип "Системна інформація"

Порушення прав.Дозволяє, при некоректному використанні та передачі даних до клієнтської частини програми можна отримати дані про сервер додатків. Бажано під час використання обмежувати право використання.

Типи "ІнтернетЗ'єднання", "ІнтернетПошта", "ІнтернетПроксі", "HTTPЗ'єднання", "FTPЗ'єднання"

Порушення прав.При використанні сервера з'єднується з віддаленим ПК з сервера додатків під правами USER1CV8SERVER. Рекомендації:

• Контролює параметри під час виклику методів.
• Контроль прав користувача 1С.
• Жорсткі обмеження прав користувача USER1CV8SERVER доступу до мережі.
• Правильне налаштування брандмауера на сервері програм 1С.

При правильному використанні зручно організовувати, наприклад, розсилку електронної пошти із сервера програм.

Типи "МенеджерКористувачівІнформаційноїБази", "КористувачІнформаційноїБази"

Порушення прав.У разі некоректного використання (у привілейованому модулі) можливе додавання користувачів або зміна параметрів авторизації існуючих користувачів.

Функція Формат

Збій сервера.Так! Ця, як би нешкідлива функція, якщо не контролювати її параметри і виконати на сервері, здатна викликати аварійне завершення програми сервера. Помилка проявляється при форматуванні чисел та використанні режиму виведення провідних нулів та великої кількості знаків, наприклад

Формат (1, "ЧЦ = 999; ЧВН =");

Сподіваюся, ця помилка буде виправлена ​​в найближчих релізах платформи, а поки у всіх дзвінках цієї функції, які можуть виконуватися на сервері, проконтролюйте параметри дзвінка.

Процедури та функції збереження значень (ЗначенняВрядокВнутр, ЗначенняФайл)

Збій сервера.Ці функції не обробляють циклічні посилання в колекціях та дуже велику глибину вкладеності, тому в деяких дуже спеціальних випадках можуть спричинити аварійне завершення.

Помилки граничних та особливих значень параметрів у функціях. Контроль за виконанням.

Однією з проблем, з якими можна зіткнутися при використанні сервера - велика "відповідальність" серверних функцій (можливість аварійного завершення всього серверного додатку через помилку в одному з'єднанні та використання одного "простору ресурсів" для всіх з'єднань). Звідси необхідність контролювати основні параметри часу виконання:

• Для функцій вбудованої мови перевіряйте параметри їхнього запуску (яскравий приклад – функція "Формат")
• У разі використання циклів переконайтеся, що умова виходу з циклу спрацьовує. Якщо цикл потенційно нескінченний обмежте штучно кількість ітерацій: Максимальне значення Лічильника Ітерацій = 1000000;
  Лічильник Ітерацій = 1;
  Бувай
  Функціяякаможенеповернути брехливогозначення()
  І (ЛічильникІтерацій<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Тіло циклу
  Лічильник Ітерацій = Лічильник Ітерацій + 1;
  КінецьЦикл;
  Якщо ЛічильникІтерацій>МаксимальнеЗначення ЛічильникаІтерацій
  //.... обробити подію надмірно довгого виконання циклу
  КінецьЯкщо;

• У разі використання рекурсії обмежуйте максимальний рівень вкладеності.
• При формуванні та виконанні запитів намагайтеся запобігти дуже довгим вибіркам та вибіркам великої кількості інформації (наприклад, при використанні умови "В ІЄРАРХІЇ" не використовуйте порожнє значення)
• При проектуванні інформаційної бази забезпечте досить великий запас розрядності для чисел (інакше додавання та множення стає некомутативним та неасоціативним, що ускладнює налагодження)
• У запитах перевірте логіку роботи на наявність значень NULL і коректну роботу умов і виразів запиту з використанням NULL.
• При використанні колекцій контролюйте можливість їх передачі між сервером програм та клієнтською частиною.

Використання термінального доступу до клієнтської частини для обмеження доступу

• Можливість блокувати роботу інших користувачів шляхом захоплення надмірної кількості ресурсів
• Доступ до інших користувачів.
• Несанкціоноване копіювання даних із термінального сервера на комп'ютер користувача

У будь-якому випадку термінальні служби дозволяють:

• Підвищити надійність роботи (при збої на комп'ютері-терміналі користувач може продовжити роботу з того ж місця)
• Обмежити доступ до клієнтської програми, файлів, що зберігаються.
• Перенести обчислювальне навантаження з робочого місця користувача на сервер термінального доступу
• Більш централізовано керувати налаштуваннями системи. Для користувачів збережені настройки будуть дійсні незалежно від того, з якого комп'ютера вони увійшли до системи.
• У деяких випадках можна використовувати термінальне рішення для віддаленого доступу до системи.

Необхідно обмежувати кількість можливих з'єднань із сервером терміналів одного користувача

В силу "ненажерливості" клієнтської програми 1С щодо ресурсів обов'язково необхідно обмежувати максимальну кількість одночасних підключень одного користувача (оператора) до сервера терміналів. Активне підключення може використовувати до 300 МБ пам'яті тільки з одним екземпляром програми. Крім пам'яті активно використовується процесорний час, що також сприяє стабільності роботи користувачів цього сервера. Одночасно із запобіганням надмірного використання ресурсів сервера, таке обмеження може запобігти використанню чужого облікового запису. Реалізується стандартними параметрами термінального сервера.

Не можна допускати запуску більше одного-двох клієнтських програм 1С одночасно в одному підключенні

Диктується тими самими причинами, що у попередньому абзаці, але технічно складніше реалізується. Проблема в тому, що запобігти повторному запуску 1С засобами сервера терміналів практично неможливо (нижче буде пояснено чому), тому доводиться реалізовувати цю можливість на рівні прикладного рішення (що теж не є добрим рішенням, тому що можуть залишатися деякий час сесії, що "висять") при некоректному завершенні програми та виникає необхідність доопрацювання прикладного рішення в модулі додатка та деяких довідників, що ускладнить використання оновлень від 1С). Дуже бажано залишити користувачеві можливість запускати 2 додатки для можливості запускати деякі дії (наприклад, формування звітів) у фоновому режимі – клієнтська програма, на жаль, фактично однопотокова.

Не рекомендується давати права на доступ до термінального сервера користувачам, які мають право запуску ресурсомістких обчислювальних завдань у 1С або запобігати такому запуску під час активної роботи інших користувачів.

Звичайно, доступ на термінальний сервер краще залишити тільки користувачам, які не використовують такі завдання як аналіз даних (data mining), географічні схеми, імпорт/експорт, та інші завдання, які серйозно навантажують клієнтську частину програми. Якщо все ж таки є необхідність вирішити такі завдання, то необхідно: повідомляти користувача про те, що ці завдання можуть вплинути на швидкодію інших користувачів, зафіксувати в журналі реєстрації подію початку та закінчення такого процесу, дозволяти виконання лише в регламентований час тощо.

Необхідно переконатися, що кожен користувач має право на запис тільки в певні каталоги сервера терміналів та інші користувачі не мають до них доступу.

По-перше, якщо не обмежити можливість запису в загальні каталоги (такі як каталог, куди встановлена ​​1С), то зберігається можливість зловмиснику змінити поведінку програми для всіх користувачів. По-друге, дані одного користувача (тимчасові файли, файли збереження налаштувань звітів тощо) ні в якому разі не повинні бути доступні іншому користувачеві термінального сервера – загалом при звичайному налаштуванні це правило виконується. По-третє, у зловмисника залишається можливість "засмітити" розділ так, що на жорсткому диску не залишиться місця. Я знаю, мені заперечать, що в Windows, починаючи з Windows 2000, є механізм квот, але це досить витратний механізм, та й реального його використання я практично не зустрічав.

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

Враховуючи, що завдання повністю вирішується важко, рекомендується здійснювати аудит більшості файлових подій.

Необхідно заборонити підключення (mapping) дискових пристроїв, принтерів та буфера обміну клієнтського робочого місця.

У RDP та ICA є можливість організувати автоматичне підключення дисків, принтерів, буфера обміну com-портів термінального комп'ютера до сервера. Якщо ця можливість є, практично неможливо заборонити запуск стороннього коду на сервері терміналів і збереження даних з 1С на клієнті термінального доступу. Дозволяйте ці можливості лише особам, які мають адміністративні права.

Мережевий файловий доступ із сервера терміналів має бути обмежений.

Якщо цього не робити, то користувач зможе знову ж таки запустити небажаний код або зберегти дані. Так як штатний журнал реєстрації не відслідковує файлові події (до речі, хороша ідея для реалізації розробниками платформи), а системний аудит у всій мережі налаштувати практично неможливо (не вистачить ресурсів на його обслуговування), краще, щоб користувач міг відправляти дані або на друк, або електронною поштою. Особливу увагу зверніть на те, щоб термінальний сервер не працював безпосередньо зі знімними носіями користувачів.

У жодному разі під час створення захищеної системи не можна залишати сервер додатків на термінальному сервері.

Якщо сервер програм запускається одному комп'ютері з клієнтськими додатками, існує досить багато можливостей порушення його нормальної роботи. Якщо з якихось причин розділити функції термінального сервера та сервера програм неможливо, зверніть особливу увагу на доступ користувачів до файлів, що використовуються сервером програм.

Необхідно виключити можливість запуску всіх програм крім 1С:Підприємства на термінальному сервері.

Це один із найскладніших пунктів побажань. Почнемо з того, що необхідно правильно налаштувати політику групової політики безпеки в домені. Необхідно правильно налаштувати всі "Адміністративні шаблони" та "Політики обмеженого використання програм". Для того, щоб перевірити себе, переконайтеся, що хоча б такі можливості заблоковані:

Складність реалізації цієї вимоги часто призводить до можливості запустити на сервері терміналів "зайвий" сеанс 1С (навіть якщо інші програми обмежені, то принципово заборонити запуск 1С засобами Windows не можна).

Враховуйте обмеження штатного журналу реєстрації (усі користувачі використовують програму з одного комп'ютера)

Очевидно, що якщо користувачі відкривають 1С в термінальному режимі, то і в журналі реєстрації буде записуватися саме сервер терміналів. З якого комп'ютера підключився користувач журнал реєстрації не повідомляє.

Сервер терміналів – захист чи вразливість?

Отже, після розгляду основних особливостей півночі терміналів можна сказати, що потенційно північ терміналів може допомогти в автоматизації для розподілу обчислювального навантаження, але побудувати безпечну систему досить складно. Одним із випадків, коли застосування сервера терміналів найбільш ефективно, є запуск 1С без Windows Explorer у повноекранному режимі для користувачів з обмеженим функціоналом та спеціалізованим інтерфейсом.

Робота клієнтської частини

Використання Internet Explorer (IE)

Однією з умов нормальної роботи клієнтської частини 1С є використання компонентів Internet Explorer. З цими компонентами слід бути дуже обережними.

Увага! По-перше, якщо до IE "причепився" модуль spyware або adware, він завантажиться і в разі перегляду будь-яких HTML файлів в 1С. Поки я не зустрічав свідомого використання цієї можливості, але зустрічав в одній із організацій завантажений "шпигунський" модуль однієї з порнографічних мереж при запущеній 1С (антивірусна програма не оновлювалася, симптоми за якими виявлено: при налаштуванні брандмауера було видно, що 1С намагається по порту 80 підключитися до порносайту). Власне, це ще один аргумент на користь того, що захист має бути комплексним.

Увага! По-друге, система 1С допускає використання у відображуваних HTML-документах flash-роликів, ActiveX об'єктів, VBScript, відправлення даних в Інтернет, навіть відкриття PDF-файлів(!), правда в останньому випадку запитує "відкрити або зберегти"... загалом, все, що душа забажає. Приклад не цілком розумного використання вбудованої можливості перегляду та редагування HTML:

• Створіть новий HTML-документ (Файл -> Новий -> HTML документ).
• Перейдіть на закладку "Текст" пустого документа.
• Видаліть текст (повністю).
• Перейдіть на закладку "Перегляд" цього документа
• За допомогою drag-n-drop перемістіть з відкритого провідника у вікно документа файл із розширенням SWF (це файли flash-роликів), наприклад з кеша браузера, хоча можна і з іграшкою FLASH для забави.
• Яка краса! На 1С можна запустити іграшку!

З погляду безпеки системи це зовсім неправильно. Поки що спеціальних атак на 1С через цю вразливість я не зустрічав, але, швидше за все, це виявиться питанням часу та цінності Вашої інформації.

Є ще деякі незначні моменти, які виявляються під час роботи з полем HTML-документа, але основними є два перераховані. Хоча, якщо підходити до цих особливостей творчо, можна організувати воістину чудові інтерфейсні можливості роботи з 1С.

Використання зовнішніх звітів та обробок.

Увага! Зовнішні звіти та обробки – з одного боку – зручний спосіб реалізації додаткових друкованих форм, регламентної звітності, спеціалізованих звітів, з іншого – потенційний спосіб обійти багато обмежень безпеки системи та порушити роботу сервера додатків (приклад див. вище в "Передача параметрів"). У системі 1С є спеціальний параметр у наборі прав ролі "Інтерактивне відкриття зовнішніх обробок", але цілком проблему це не знімає – для повного вирішення треба досить сильно звузити коло користувачів, які можуть керувати зовнішніми друкованими формами, регламентними звітами та іншими штатними можливостями типових рішень реалізованих із використанням зовнішніх обробок. Наприклад, за умовчанням в УПП у всіх основних ролей користувачів є можливість роботи з довідником додаткових друкованих форм, а це, по суті, можливість використання будь-яких зовнішніх обробок.

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

Деякі стандартні механізми потенційно небезпечні, причому досить несподіваним чином.

Друк списків

Будь-який список (наприклад, довідник або регістр відомостей) у системі можна роздрукувати або зберегти у файл. Для цього достатньо використовувати штатну можливість, доступну з контекстного меню та меню "Дії":

Враховуйте, що все, що користувач бачить у списках, може бути виведено у зовнішні файли. Єдине, що можна порадити, – ведіть протокол друку документів на серверах друку. Для особливо критичних форм необхідно налаштувати панель дій, пов'язану з табличним полем, що захищається так щоб можливість виведення списку не була доступна з цієї панелі, і відключити контекстне меню (див. рис 6).

Обмін даними у розподіленій базі

Формат обміну даними досить простий та описаний у документації. Якщо користувач має можливість підмінити кілька файлів, він може внести неавторизовані зміни в систему (хоча це заняття досить трудомістке). Можливість створення периферійної бази під час використання планів обміну розподіленої бази даних має бути доступна звичайним операторам.

Стандартний обмін даними XML

У стандартному обміні даними, який використовується для обміну між типовими конфігураціями (наприклад, "Управління торгівлею" та "Бухгалтерія підприємства") є можливість вказати у правилах обміну обробники подій завантаження та вивантаження об'єктів. Реалізується це отриманням обробника з файлу та процедурою "Виконати()" стандартної обробки завантаження та вивантаження файлу (процедура "Виконати()" запускається на клієнтській частині). Очевидно, що нескладно створити такий фальшивий обмінний файл, який виконуватиме шкідливі дії. Для більшості ролей користувачів типових рішень обмін за замовчуванням дозволено.

Рекомендація:обмежити доступ до XML-обміну для більшості користувачів (залишити лише адміністраторам ІБ). Вести протоколи запусків цієї обробки, зберігаючи файл обміну, наприклад, надсилаючи його електронною поштою адміністратору ІБ до завантаження.

Використання універсальних звітів, особливо консолі звітів

Ще однією проблемою є доступ користувачів за промовчанням до універсальних звітів, особливо це стосується звіту "Консоль звітів". Цей звіт характерний тим, що дозволяє виконати практично будь-які запити до ІБ, і якщо навіть система прав 1С (у тому числі RLS) налаштована досить жорстко, дозволяє користувачеві отримати багато "зайвої" інформації та змусити сервер виконувати такий запит, який забере всі ресурси системи.

Використання повноекранного режиму (режим робочого столу)

Одним із ефективних способів організації спеціалізованих інтерфейсів з обмеженим доступом до функціонала програми є повноекранний режим основної (і, можливо, єдиної) форми, що використовується інтерфейсом. При цьому не виникає питань доступності, наприклад, меню "Файл" і всі дії користувача обмежуються можливостями використовуваної форми. Докладніше див. "Особливості реалізації режиму робочого столу" на диску ІТС.

Резервне копіювання

Резервне копіювання для клієнт-серверної версії 1С можна виконувати двома способами: вивантаження даних у файл з розширенням 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 (наприклад, можливо захиститись від неавторизованого додавання ІБ на сервері додатків).
• Виняток "прослуховування" мережного трафіку.
• Відсутність необхідності змінювати поведінку прикладних програм (у разі 1С).
• Стандартність такого рішення.

Однак цей підхід має обмеження та недоліки:

• IPSec не захищає дані від втручання та прослуховування безпосередньо на комп'ютері-джерелі та комп'ютері-приймачі даних.
• Об'єм даних, що передаються по мережі, дещо більше, ніж без використання IPSec.
• При використанні IPSec дещо більше навантаження на центральний процесор.

Детальний опис використання коштів IPSec виходить за рамки цієї статті і вимагає розуміння основних принципів функціонування протоколу IP. Щоб правильно настроїти захист з'єднань, ознайомтеся з відповідною документацією.

Окремо слід згадати декілька аспектів ліцензійної угоди з 1С при організації VPN-з'єднань. Справа в тому, що, незважаючи на відсутність технічних обмежень, при з'єднанні декількох сегментів локальної мережі або віддаленому доступі окремого комп'ютера до локальної мережі зазвичай потрібна наявність декількох базових поставок.

Шифрування даних під час передачі між клієнтською частиною системи та сервером додатків.

Окрім шифрування на рівні мережевого протоколу, можливе шифрування даних на рівні протоколу COM+, що згадано у статті "Регулювання доступу користувачів до інформаційної бази у клієнт-серверному варіанті" ІТС. Для реалізації необхідно в "Служби компонентів" (Component Services) встановити для програми 1CV8 встановити рівень автентифікації (Authentication level for calls) "Секретність пакетів" (Packet Privacy). Під час встановлення цього режиму виконується автентифікація пакета та його шифрування, включаючи дані, а також посвідчення та підпис відправника.

Шифрування даних при передачі між сервером додатків та MS SQL Server

MS SQL Server надає такі засоби для шифрування даних:

• Можливе використання Secure Sockets Layer (SSL) при передачі даних між сервером додатків та MS SQL Server.
• У разі використання мережної бібліотеки Multiprotocol використовується шифрування даних на рівні RPC. Це потенційно слабше шифрування, ніж при використанні SSL.
• Якщо використовується протокол обміну Shared Memory (це відбувається, якщо сервер додатків та MS SQL Server розташовані на одному комп'ютері), то шифрування не використовується у будь-якому випадку.

Для того щоб встановити необхідність шифрування всіх даних, що передаються для певного сервера MS SQL необхідно скористатися утилітою "Server Network Utility". Запустіть її та на закладці "General" встановіть прапорець "Force protocol encryption". Метод шифрування вибирається залежно від використовуваного клієнтським додатком (тобто сервером програми 1С). Для використання SSL необхідно правильно настроїти службу видачі сертифікатів у мережі.

Для того щоб встановити необхідність шифрування всіх даних, що передаються для певного сервера додатків, необхідно скористатися утилітою "Client Network Utility" (зазвичай розташованою в "C:WINNTsystem32cliconfg.exe"). Як і в попередньому випадку, на закладці "General" встановіть прапорець "Force protocol encryption".

Варто враховувати, що використання шифрування в цьому випадку може досить позначитися на продуктивності системи, особливо при використанні запитів, що повертають великі обсяги інформації.

Щоб повніше захистити з'єднання між сервером додатків і 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 (розділ "Configuring Network Connections").

По-друге, у налаштуваннях протоколу TCP/IP на сервері MS SQL можна встановити прапорець "Hide server", що забороняє відповіді на широкомовні запити даного примірника служби MS SQL Server.

Шифрування даних MS SQL, що зберігаються на диску

Є досить великий вибір програмних та апаратних засобів для шифрування даних, розташованих на локальному диску (це і штатна можливість Windows використовувати EFS, і використання ключів eToken, і програми сторонніх виробників типу Jetico Bestcrypt або PGPDisk). Однією з основних завдань, що виконується цими засобами, є захист даних при втраті носія (наприклад, при крадіжці сервера). Варто відзначити, що Microsoft не рекомендує зберігати бази MS SQL на зашифрованих носіях, і це цілком обґрунтовано. Основною проблемою при цьому є суттєве падіння продуктивності та можливі проблеми надійності від збоїв. Другим фактором, що ускладнює життя адміністратору системи, є необхідність забезпечити доступність всіх файлів бази даних на момент першого звернення служби MS SQL до них (тобто бажано, щоб при підключенні шифрованого носія було виключено інтерактивні дії).

Щоб уникнути помітного падіння продуктивності системи можна скористатися можливістю MS SQL створювати бази даних у кількох файлах. Звичайно, в цьому випадку база даних MS SQL не повинна створюватись сервером 1С при створенні інформаційної бази, а має бути створена окремо. Приклад сценарію на TSQL з коментарями наведено нижче:

USE master
GO
-- Створити базу даних SomeData,
CREATE DATABASE SomeData
- Дані якої повністю розташована в групі файлів (filegroup) PRIMARY.
ON PRIMARY
-- Основний файл даних розташований на зашифрованому носії (логічний диск E:)
-- і має початковий розмір 100 МБ, може бути автоматично збільшений до 200 МБ
- Кроком 20 Мб
(NAME = SomeData1,
FILENAME = "E:\SomeData1.mdf",
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 2),
-- Другий файл даних розташований на незашифрованому носії (логічний диск:)
-- і має початковий розмір 100 МБ, може бути автоматично збільшений до межі
-- дискового простору з кроком 5% від поточного об'єму файлу (округлюється до 64 Кб)
(NAME = SomeData2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
SIZE = 100MB,
MAXSIZE = UNLIMITED,
FILEGROWTH = 5%)
LOG ON
- Хоча лог транзакцій можна було також розділити на частини, робити цього не варто.
- т.к. цей файл змінюється набагато частіше і регулярно очищається (наприклад при
- Створення резервної копії БД).
(NAME = SomeDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
SIZE = 10MB,
MAXSIZE = UNLIMITED,
FILEGROWTH = 10)
GO
- Краще відразу віддати володіння базою даних користувачу, від імені якого
- Підключатиметься 1С. Для цього нам необхідно поточною базою оголосити
- Щойно створену,
USE SomeData
GO
-- та виконати процедуру sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Невеликий відступ про автоматичне зростання розміру файлу даних. За замовчуванням для створюваних баз даних розміри файлів збільшуються з кроком 10% поточного розміру файлу. Це цілком прийнятне рішення для невеликих баз даних, але не дуже хороше для великих: при розмірі бази, наприклад, 20 ГБ файл має разом збільшитися на 2 ГБ. Хоча ця подія відбуватиметься досить рідко, вона може тривати кілька десятків секунд (всі інші транзакції в цей час фактично простоюють), що при виникненні її під час активної роботи з базою даних може спричинити деякі збої. Другим негативним наслідком пропорційного збільшення, яке проявляється при майже повністю заповненому дисковому просторі, є ймовірність передчасного збою через нестачу вільного місця. Наприклад, якщо розділ диска об'ємом 40 ГБ повністю відданий під одну базу даних (точніше, під один файл цієї бази), то критичним розміром файлу бази даних при якому необхідно терміново (дуже терміново, аж до переривання нормальної роботи користувачів) реорганізувати зберігання інформації Розмір файлу даних 35 ГБ. При встановленому розмірі збільшення 10-20 МБ можна продовжувати до досягнення 39 ГБ.

Тому, хоча в наведеному лістингу встановлено збільшення розміру одного з файлів бази даних з кроком 5%, при великих розмірах БД краще встановити фіксоване збільшення 10-20 МБ. При встановленні значень кроку зростання розміру файлів бази даних необхідно врахувати, що до досягнення одним із файлів файлової групи максимального розміру діє правило: файли однієї файлової групи збільшуються всі одночасно, коли всі вони будуть заповнені повністю. Таким чином, у наведеному прикладі, коли файл SomeData1.mdf досягне максимального розміру 200 МБ, файл SomeData2.ndf буде розміром близько 1,1 ГБ.

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

Звичайно, якщо використовується зберігання файлів бази даних з використанням криптографічних засобів, то резервне копіювання (хоча цих файлів) не повинно вестися на нешифрований носій. Для забезпечення архівації окремих файлів бази даних слід скористатися відповідним синтаксисом команди "BACKUP DATABASE". Зверніть увагу, що, незважаючи на можливість захисту резервної копії бази даних паролем (опції "PASSWORD=" та "MEDIAPASSWORD=" команди "BACKUP DATABASE"), така резервна копія не стає зашифрованою!

Шифрування даних сервера додатків та клієнтської частини, що зберігаються на дисках

У більшості випадків не можна визнати виправданим зберігання файлів використовуваних 1С:Підприємством (клієнтською частиною та сервером додатків) на носії, що шифрується, через невиправдано високі витрати, проте, якщо така необхідність існує, зверніть увагу, що сервер додатків і клієнтська частина програми дуже часто створюють тимчасові файли. Нерідко ці файли можуть залишитися після завершення роботи програми, причому гарантувати видалення їх засобами 1С практично неможливо. Таким чином, виникає шифрувати каталог, що використовується для тимчасових файлів в 1С або не зберігати його на диску, використовуючи RAM-drive (останній варіант не завжди можливий в силу розмірів файлів, що формуються, і вимог до обсягу оперативної пам'яті самого додатка 1С:Підприємства).

Шифрування даних вбудованими засобами 1С.

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

Функція ЗашифруватиДані (Дані, Пароль, Метод Шифрування = Невизначено) Експорт

// Запишемо дані до тимчасового файлу. Взагалі далеко не будь-які дані можна так зберегти.
ЗначенняВФайл(Ім'я ТимчасовогоФайлу, Дані);

// Запишемо тимчасові дані до архіву
Зіп = Новий ЗаписZipФайлу(Ім'яТимчасовогоФайлуАрхіву, Пароль,МетодШифрування);
Зіп.Додати (Ім'я Тимчасового Файлу);
Зіп.Записати();

// Зчитуємо дані з отриманого архіву до оперативної пам'яті
ЗашифрованіДані = Новий СховищеЗначення(Новий ДвійковіДані(Ім'яТимчасовогоФайлуАрхіву));

// Тимчасові файли – видаляємо

КінецьФункції Функція РозшифруватиДані(ЗашифрованіДані, Пароль) Експорт

// Увага! Коректність переданих параметрів не відстежується

// Записуємо передане значення у файл
Ім'яТимчасовогоФайлуАрхіву = ОтриматиІм'яТимчасовогоФайлу("zip");
ДвійковіДаніАрхіву = ЗашифрованіДані.Отримати();
ДвійковіДаніАрхіву.Записати(Ім'яТимчасовогоФайлуАрхіву);

// Виймаємо перший файл щойно записаного архіву
Ім'яТимчасовогоФайлу = ОтриматиІм'яТимчасовогоФайлу();
Зіп = Новий ЧитанняZipФайлу(Ім'яТимчасовогоФайлуАрхіву, Пароль);
Зіп.Вилучити(Зип.Елементи, Ім'яТимчасовогоФайлу, РежимВідновленняШляхівФайлівZIP.НеВідновлювати);

// Зчитуємо записаний файл
Дані = ЗначенняІзФайлу (Ім'яТимчасовогоФайлу + "\" + Зіп.Елементи.Ім'я);

// Видаляємо тимчасові файли
ВидалитиФайли(Ім'яТимчасовогоФайлу);
Видалити Файли (Ім'я Тимчасового Файлу Архіву);

Повернення Дані;

КінецьФункції

Звичайно, такий спосіб не можна назвати ідеальним – дані записуються у тимчасову папку у відкритому вигляді, продуктивність методу, прямо скажемо, гірше нікуди, зберігання в базі даних потребує надзвичайно багато місця, але це єдиний спосіб, який ґрунтується лише на вбудованих механізмах платформи. До того ж він має перевагу перед багатьма іншими методами – цей метод одночасно з шифрацією виконує упаковку даних. Якщо потрібно реалізувати шифрування без тих недоліків, які є у даного методу, необхідно або реалізувати їх у зовнішній компоненті, або звернутися до існуючих бібліотек через створення COM-об'єктів, наприклад, використовуючи Microsoft CryptoAPI. Як приклад наведемо функції шифрування/дешифрування рядка виходячи з отриманого пароля.

Функція ЗашифруватиСтрокуDES(НезашифрованийРядок, Пароль)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Ця константа із CryptoAPI

МеханізмШифрування.Content = НезашифрованийРядок;
МеханізмШифрування.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
ЗашифрованаРядок = МеханізмШифрування.Encrypt();

Повернення ЗашифрованаРядок;

КінецьФункції // ЗашифруватиСтрокуDES()

Функція РозшифруватиСтрокуDES(ЗашифрованийРядок, Пароль)

//Увага! Параметри не перевіряються!

МеханізмШифрування = Новий COMОб'єкт ("CAPICOM.EncryptedData");
МеханізмШифрування.SetSecret(Пароль);
Спроба
МеханізмШифрування.Decrypt(ЗашифрованийРядок);
Виняток
// Невірний пароль!;
Повернення Невизначено;
КінецьСпроби;

Повернення МеханізмШифрування. Content;

КінецьФункції // РозшифруватиСтрокуDES()

Зауважте, що під час передачі порожнього значення як рядка або пароля в ці функції виникне повідомлення про помилку. Рядок, отриманий за допомогою такої процедури шифрування дещо довший за оригінал. Специфіка цього шифрування така, що якщо зашифрувати рядок двічі, отримані рядки НЕ будуть ідентичні.

Основні помилки під час використання криптографічних засобів.

При використанні криптографічних засобів дуже часто допускаються ті самі помилки:

Недооцінка падіння продуктивності під час використання криптографії.

Криптографія – завдання, яке потребує досить великої кількості обчислень (особливо таких алгоритмів, як DES, 3DES, ГОСТ, PGP). І навіть у разі використання продуктивних та оптимізованих алгоритмів (RC5, RC6, AES) нікуди не подітися від зайвої передачі даних у пам'яті та обчислювальної обробки. А це майже зводить нанівець можливості багатьох серверних компонентів (RAID-масиви, мережеві адаптери). При використанні апаратного шифрування або апаратного отримання ключа для шифрування виникає додаткове можливе вузьке місце у продуктивності: швидкість передачі між додатковим пристроєм і пам'яттю (причому продуктивність такого пристрою може не грати вирішальної ролі). При використанні шифрування невеликих обсягів даних (наприклад, поштового повідомлення) зростання обчислювального навантаження на систему не настільки помітне, але у разі тотального шифрування всього і все це може дуже позначитися на продуктивності системи в цілому.

Недооцінка сучасних можливостей щодо підбору паролів та ключів.

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

Ненадійне зберігання ключів та паролів.

Типовими прикладами цієї помилки є:

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

Навіщо робити броньовані двері, якщо ключ від неї лежить під килимком біля дверей?

Передача зашифрованих даних у небезпечне середовище.

Під час організації системи безпеки переконайтеся, що вона виконує своє завдання. Наприклад, я стикався з ситуацією (не пов'язаною з 1С), коли спочатку зашифрований файл під час роботи програми у відкритому вигляді поміщався в тимчасову папку, звідки його можна було спокійно прочитати. Нерідко також резервні копії зашифрованих даних у відкритому вигляді лежать десь "неподалік" від цих даних.

Використання криптографічних засобів не за призначенням

При шифруванні даних, що передаються, не можна очікувати, що дані будуть недоступні в місцях їх використання. Наприклад, служби IPSec жодним чином не запобігають можливості "прослуховування" мережевого трафіку на рівні програми на стороні сервера програм.

Таким чином, щоб уникнути помилок при впровадженні криптографічних систем, до її розгортання слід (як мінімум) зробити таке.

• З'ясуйте:
  • Що потрібно захистити?
  • Який метод захисту слід використати?
  • Для яких ділянок системи потрібно забезпечувати безпеку?
  • Хто керуватиме доступом?
  • Чи працюватиме шифрування на всіх потрібних ділянках?
• Визначте місця зберігання інформації, спосіб їх пересилання по мережі та комп'ютери, з яких буде доступ до цієї інформації. Це дозволить отримати інформацію про швидкість, ємність та використання мережі до впровадження системи, що корисно для оптимізації швидкодії.
• Оцініть вразливість системи різних типів атак.
• Розробте та задокументуйте план безпеки системи.
• Оцініть економічну ефективність (виправданість) використання системи.

Висновок

Звичайно, у побіжному огляді не можна вказати всі аспекти, пов'язані з безпекою в 1С, але дозволимо собі зробити деякі попередні висновки. Звичайно, ідеальною цю платформу назвати не можна – у ній, як і в багатьох інших, є свої проблеми організації захищеної системи. Але це в жодному разі не означає, що ці проблеми не можна обійти, навпаки, майже всі недоліки можуть бути ліквідовані за умови правильної розробки, впровадження та використання системи. Більшість проблем виникає через недостатнє опрацювання конкретного прикладного рішення та середовища його виконання. Наприклад, типові рішення без внесення значних змін просто не передбачають створення захищеної достатньою мірою системи.

Ця стаття ще раз демонструє, що будь-який комплекс заходів щодо безпеки повинен охоплювати всі етапи впровадження: розробку, розгортання, системне адміністрування та, обов'язково, організаційні заходи. В інформаційних системах саме "людський фактор" (зокрема користувачі) – головна загроза безпеці. Цей комплекс заходів має бути розумним і збалансованим: немає сенсу і навряд чи буде виділено достатні кошти на організацію захисту, яка перевищує за вартістю самі дані.

Компанія - Це унікальний сервіс для покупців, розробників, дилерів та афіліат-партнерів. Крім того, це один із найкращих Інтернет-магазинів ПЗ в Росії, Україні, Казахстані, який пропонує покупцям широкий асортимент, безліч способів оплати, оперативну (часто миттєву) обробку замовлення, відстеження процесу виконання замовлення в персональному розділі.