Питання безпеки інформаційних систем на платформі 1С:Підприємство 8.1

Короткий зміст:

Механізми забезпечення безпеки в 1С:Підприємстві 8.1

Приклад нехтування безпекою MS SQL Server і 1С:Підприємство 8.1

Комплексне поняття безпеки

Ділянка захисту даних «клієнт – кластер 1С:Підприємство 8.1»

Ділянка захисту даних «кластер – СУБД»

Ділянка захисту даних «Людина»

Аудит безпеки системи

1. Доступ користувачів до адміністративних дій конфігуратора

1.1 Виявлення загрози

1.2 Можливі наслідки

1.3 Заходи захисту

2. Відсутність розмежувань доступу в режимі 1С:Підприємство

2.1 Виявлення загрози

2.2 Можливі наслідки

2.3 Заходи захисту

3. Несанкціонований доступ до даних сервера СУБД

3.1 Виявлення загрози

3.2 Можливі наслідки

3.3 Заходи захисту

4. Використання «старих» логінів

4.1 Виявлення загрози

4.2 Можливі наслідки

4.3 Заходи захисту

5. Несанкціонований доступ до файлів кластера серверів

5.1 Виявлення загрози

5.2 Можливі наслідки

5.3 Заходи захисту

6. Вразливості операційної системи, СУБД

6.1 Виявлення загрози

6.2 Можливі наслідки

6.3 Заходи захисту

7. Віруси, трояни, логери

7.1 Виявлення загрози

7.2 Можливі наслідки

7.3 Заходи захисту

8. Паролі на моніторах, слабкі паролі

8.1 Виявлення загрози

8.2 Можливі наслідки

8.3 Заходи захисту

9. Перехоплення інформації

9.1 Виявлення загрози

9.2 Можливі наслідки

9.3 Заходи захисту

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

 

Короткий зміст:

У цій статті розглядаються питання безпеки інформаційних систем, що працюють на платформі 1С:Підприємство 8.1 у клієнт-серверному варіанті з використанням СУБД MS SQL Server.

Механізми забезпечення безпеки в 1С:Підприємстві 8.1

Що таке безпека? Часто вважається, що для забезпечення безпеки достатньо задати пароль облікового запису або зашифрувати дані. У деяких випадках це саме так. Але правильніше буде уточнити, що ці заходи посилюють захист інформації на деяких «ділянках» функціонування системи. Забезпечення захисту даних — поняття комплексне. Частина заходів з організації контролю доступу до інформації здійснюється технічними засобами, зокрема 1С:Підприємством, СУБД (наприклад, Microsoft SQL Server) та операційною системою. Частина заходів є набором адміністративних дій і правил компанії.

У цій статті буде розглянуто питання безпеки інформаційних систем, що працюють під керуванням 1С:Підприємства 8.1 у клієнт-серверному варіанті з використанням СУБД MS SQL Server.

Базовий принцип захисту даних у клієнт-серверному варіанті полягає в тому, що користувачі не мають прямого доступу до файлів інформаційної бази. «Посередником» між клієнтами 1С:Підприємства 8.1 і сервером СУБД є робочий процес rphost, який звертається із запитом до СУБД від імені свого облікового запису. Потім отриманий результат повертає клієнту.

Приклад реалізації клієнт-серверної архітектури

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

Хочете приклад?

Приклад нехтування безпекою MS SQL Server і 1С:Підприємство 8.1

У нашому прикладі в деякій компанії Х як сервер баз даних встановлено MS SQL Server 2000 із налаштуваннями за замовчуванням. Як обліковий запис контексту виконання служби «MSSQLServer» було вибрано обліковий запис операційної системи. Після розгортання клієнт-серверного варіанта 1С:Підприємства 8.1 для користувачів конфігурації було створено облікові записи та призначено паролі. Додаткових налаштувань, пов’язаних із безпекою, не виконувалося.

На перший погляд усе гаразд, користувачі не мають доступу до файлів серверів застосунків і СУБД. «Злам» буде зараховано після отримання зловмисником доступу до облікового запису адміністратора сервера з MS SQL Server.

За нашим сценарієм один зі співробітників компанії Х стає зловмисником. У нього є власний ноутбук. І він працює з інформаційною базою від імені свого "законного" облікового запису, як і більшість користувачів компанії.

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

Права на вивантаження інформаційної бази має будь-який користувач, якому дозволено виконувати "Адміністративні функції".

Зловмисник вивантажує інформаційну базу собі на локальний диск у вигляді файлу DT. Тепер він може розгорнути її локально на своєму комп’ютері або передати "ворогам".

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

Якщо не задати адміністратора кластера, то інформаційні бази зможе створювати будь-який користувач

У своїй інформаційній базі зловмисник створює привілейований модуль, що виконується на стороні сервера. Цей модуль працює від імені облікового запису сервера 1С:Підприємства і, звісно, має повний доступ до всіх даних 1С:Підприємства. Зокрема цей модуль може прочитати файл налаштувань C:\Program Files\1cv81\server\reg_1541\ 1CV8Reg.lst, де для баз серед параметрів зберігаються логін і пароль, під якими відбувається підключення до SQL Server.

Прочитавши файл налаштувань, застосунок отримує доступ до бази даних

Примітка. Починаючи з версії 8.1.6 паролі логінів СУБД у файлі налаштувань шифруються. Проте слід пам’ятати про підключення через USR1CV81, коли логін і пароль у параметрах бази не вказуються.

Причина, яка дозволила нам прочитати файл налаштувань, — це доступ до файлу для облікового запису процесу rphost, що за замовчуванням збігається з обліковим записом процесу ragent і rmngr.

Знаючи логін і пароль, зловмисник підключається до MS SQL Server 2000 і виконує для бази master такий скрипт:

EXEC xp_cmdshell 'net user Neo passW0rd /add' EXEC xp_cmdshell 'net localgroup Administrators Neo /add'

Ця команда створює користувача з ім’ям Neo та правами адміністратора на сервері, де встановлено MS SQL Server.

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

Щоб уникнути подібних помилок, розглянемо детальніше, як працюють механізми захисту.

Комплексне поняття безпеки

Комплексне поняття безпеки системи складається на основі її захищеності на різних ділянках. Можна виділити три основні ділянки захисту даних:

• Клієнт - кластер 1С:Підприємства
• Кластер 1С:Підприємства - СУБД
• Користувач системи

Ділянка захисту даних «клієнт – кластер 1С:Підприємство 8.1»

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

Ділянка захисту даних «кластер – СУБД»

Захист даних, що передаються між кластером серверів 1С:Підприємства та сервером СУБД, здійснюється засобами СУБД. MS SQL Server дає змогу організувати шифрування переданих даних за допомогою сертифікатів.

Ділянка захисту даних «Людина»

У цій статті розглядаються лише технічні заходи забезпечення безпеки. Слід мати на увазі, що існує й такий фактор безпеки, як користувач. Навіть найдосконаліший захист не може гарантувати безпеку системи, якщо до неї має доступ недобросовісний або неакуратний користувач. Системний адміністратор володіє інформацією про паролі, головний бухгалтер — фінансовою інформацією про компанію тощо. Це означає, що завжди є ще одна ланка системи, яка може виявитися найбільш вразливою в захисті інформації. Політика регулярної зміни паролів, яку проводить системний адміністратор, може бути зведена «нанівець», якщо користувачі вирішать, що зберігання «складних» паролів слід довірити пам’яткам на моніторі своїх робочих місць.

Аудит безпеки системи

Наступну таблицю можна використовувати як пам’ятку під час проведення аудиту безпеки системи.

Ймовірна загроза безпеці	Ділянка	Імовірність	Наслідки	Ймовірний зловмисник	Трудомісткість
1. Доступ користувачів до адміністративних дій конфігуратора	Клієнт	Висока	Копіювання всієї інформації	Програміст, досвідчений користувач	Середня
2. Відсутність розмежувань доступу в режимі 1С:Підприємство"	Клієнт	Середня	Копіювання ключової інформації	Програміст, досвідчений користувач	Висока
3. Несанкціонований доступ до даних сервера СУБД	СУБД	Середня	Псування інформації, копіювання інформації	Адміністратор	Середня
4. Використання старих логінів	Клієнт, Кластер, СУБД	Низька	Наслідки залежать від прав облікового запису	Звільнений співробітник	Низька
5. Несанкціонований доступ до файлів кластера серверів	Кластер	Низька	Псування інформації, можливість створення нових баз	Адміністратор, програміст	Низька
6. Наявність вразливостей операційної системи, СУБД	Клієнт, Кластер, СУБД	Низька	Підвищення прав за допомогою зламувачів, опублікованих в інтернеті, можливе повне копіювання інформації	Адміністратор, досвідчений користувач	Низька
7. Віруси, трояни, логери	Клієнт, Кластер, СУБД	Низька	Псування інформації, отримання даних, розкриття паролів користувачів	Адміністратор, досвідчений користувач	Низька
8. Паролі на моніторах, слабкі паролі	Клієнт	Середня	Несанкціонований доступ до облікових записів користувачів із подальшим доступом до даних	Досвідчений користувач, звільнений співробітник	Низька
9. Перехоплення інформації	Клієнт-Кластер, Кластер-СУБД	Мінімальна	Перехоплення паролів із подальшим доступом до даних	Висококваліфікований системний програміст, мережевий спеціаліст	Висока

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

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

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

1. Доступ користувачів до адміністративних дій конфігуратора

1.1 Виявлення загрози

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

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

• Вивантажувати інформаційну базу у файл на диску свого комп’ютера
• Призначати права доступу для інших користувачів інформаційної бази

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

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

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

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

1.2 Можливі наслідки

Як показує практика, імовірність виникнення такої загрози дуже висока.

Як наслідок слід особливо відзначити копіювання інформаційної бази.

1.3 Заходи захисту

1.3.1 Обмеження прав

Призначайте адміністративні права лише тим користувачам 1С:Підприємства, яким це справді необхідно.

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

• Адміністративні функції
• Оновлення конфігурації бази даних
• Зовнішнє з’єднання
• Інтерактивне відкриття зовнішніх обробок
• Інтерактивне відкриття зовнішніх звітів

1.3.2 Обмеження доступу до переносних носіїв

Щоб обмежити можливості зловмисників щодо копіювання бази даних на зовнішні носії (дисководи, USB-носії тощо), можна використовувати групові політики Active Directory.

2. Відсутність розмежувань доступу в режимі 1С:Підприємство

2.1 Виявлення загрози

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

На рисунку показано приклад налаштування прав менеджерам із продажу в типовому рішенні 1С.

Приклад налаштування прав у галузевому рішенні.

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

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

2.2 Можливі наслідки

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

2.3 Заходи захисту

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

3. Несанкціонований доступ до даних сервера СУБД

3.1 Виявлення загрози

Перевірте такі ознаки загрози:

• Наявність увімкненого (enabled) логіна sa для використовуваного MS SQL Server
• Обліковий запис служби MS SQL Server входить до доменних груп
• Є доступ до файлів, що зберігаються на комп’ютері, на якому запущено MS SQL Server
• Сервер 1С:Підприємства і SQL Server запущені на одному комп’ютері
• Відкрито доступ до сервера облікових записів користувачів
• Слабкі паролі логінів MS SQL Server
• Увімкнено можливість роботи з командним рядком службою MS SQL Server

3.2 Можливі наслідки

Повний доступ до інформаційних баз, що зберігаються на MS SQL Server.

3.3 Заходи захисту

Нижче наведено заходи захисту в порядку зростання складності реалізації:

3.3.1. Виключіть можливість доступу від імені SA

3.3.1.1. Видаліть обліковий запис SA

Наприклад, це можна зробити за допомогою команди:

ALTER LOGIN sa DISABLE 
 

На рисунку показано успішне вимкнення логіна SA.

3.3.1.2. Для виконання адміністративних функцій створіть обліковий запис з іншою назвою. Увімкніть цей обліковий запис до ролі sysadmin.

3.3.1.3 Цей обліковий запис повинен мати надійний пароль

Задати пароль через Tansact-SQL можна так :

ALTER LOGIN my_sa WITH PASSWORD = 'Ple@se_Don''t_C0mprom1se_My_SQL_S3rv3r_Bec@us3_It_Is_V3ry_Ne@r_And_D3ar_To_My_h2@rt'

У цьому прикладі для логіна my_sa буде вказано складний пароль. (Зміну пароля у версії MSDE описано на сайті Microsoft)

3.3.1.4 Виключити доступ до процедури xp_cmdshell

Процедура xp_cmdshell має доступ до ресурсів операційної системи сервера СУБД, зокрема до диска, на якому фізично розташована база даних.

3.3.1.5 Видалити групу BUILTIN\Administrator.

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

3.3.1.6 Якщо ви хочете надати користувачам можливість самостійно створювати бази, створіть персональні облікові записи кожному та наділіть їх роллю 'dbcreator'

Створити користувача та надати право створювати бази можна так:

USE [master]
GO
CREATE LOGIN [user1c] WITH PASSWORD=N'P@ssw0rd'
GO
EXEC master..sp_addsrvrolemember @loginame = N'user1c', @rolename = N'dbcreator' 
GO 

У цьому прикладі в результаті успішного виконання з’явиться користувач user1c і матиме роль 'dbcreator'.

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

Наділити обліковий запис роллю ' SecurityAdmin ' можна так:

EXEC master..sp_addsrvrolemember @loginame = N'user1c', @rolename = N'securityadmin' GO

Примітка. Переглянути набір прав для ролі можна за допомогою збереженої процедури sp_srvrolepermission.

Наприклад, для ролі dbcreator:

exec sp_srvrolepermission 'dbcreator'

3.3.1.7 Адміністратор баз даних може сам створювати бази, а потім передавати право володіння іншим користувачам.

Це робиться за допомогою збереженої процедури sp_changedbowner.

На рисунку показано передавання прав володіння базою від адміністратора, який створив базу, іншому користувачу

Такий підхід дозволить не надавати обліковим записам користувачів роль dbcreator. Тобто користувачі не зможуть самостійно створювати бази даних.

Використання sp_changedbowner для зміни власника бази даних:

USE db_buh
GO

EXEC sp_changedbowner user1c

GO  

У цьому прикладі db_buh — ім’я бази даних, user1c — ім’я користувача, який повинен стати власником бази.

3.3.2 Виключіть доступ користувачів (не адміністраторів) до сервера СУБД

Доступ до сервера має бути надано лише адміністраторам сервера та обліковому запису служб кластера серверів 1С:Підприємство 8.

Приклад налаштування доступу

3.3.3 Рознесіть сервер СУБД і сервер 1С:Підприємства на різні комп’ютери

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

3.3.4 Виключіть файловий доступ до даних MS SQL Server

Для комп’ютера, на якому запущено MS SQL Server, краще залишити працюючим застосунком лише MS SQL Server, виключивши такі сервіси, як "спільний файловий доступ", "поштовий сервер", "інтернет-проксі", "веб-сервери" тощо.

Приклад вимкнення файлового доступу мережею.

3.3.5 Регулярно створюйте резервні копії та зберігайте їх у безпечному місці поза розташуванням робочих серверів

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

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

3.3.6 Налаштування прав доступу служб MS SQL Server

Безпека виконання операцій сервера MS SQL Server в операційній системі визначається його обліковими записами. Це облікові записи служб SQL Server, Agent SQL Server і Browser SQL Server для SQL Server 2005.

Наприклад, SQL Server має доступ до виконання процедури «xp_cmdshell», яка дозволяє працювати з командним рядком Windows. Процес Windows, породжений процедурою xp_cmdshell, має ті самі права захисту, що й обліковий запис служби SQL Server.

Якщо обліковий запис має права системи або входить до групи Адміністратори, то xp_cmdshell дозволяє виконувати будь-які дії в операційній системі сервера СУБД. Якщо обліковий запис входить лише до групи Користувачі, можливості xp_cmdshell еквівалентні можливостям звичайного користувача.

У SQL Server 2005 функціональність «xp_cmdshell» за замовчуванням вимкнена з метою підвищення безпеки.

На рисунку показано консоль SQL Server 2005 Surface Area Configuration, яка керує можливістю ввімкнення/вимкнення найбільш «імовірних» цілей зловмисників, зокрема xp_cmdshell.

Для роботи 1С:Підприємство 8.1 усі вказані в цій консолі функції можуть бути вимкнені. Деякі системні адміністратори наділяють обліковий запис служби адміністративними правами «просто щоб працювало». Для організації підвищеної безпеки практикується «Принцип мінімальності привілеїв» — суб’єкт повинен мати набір мінімально необхідних прав для виконання своїх функцій. Стосовно служб SQL Server це означає таке:

• За можливості запускайте служби від імені облікового запису LocalService
• Використовуйте запис NetworkService для служб, яким потрібен доступ до мережевих ресурсів
• Використовуйте запис LocalSystem для служб, яким потрібен доступ до мережевих ресурсів і повний набір прав на локальний комп’ютер
• Застосовуйте підвищені заходи безпеки до серверів, на яких запущено служби з правами доменного адміністратора

На рисунку показано бажаний порядок використання привілеїв облікового запису служби SQL Server. Що вищі права запису, то більшу вразливість створює служба.

Обліковому запису, від імені якого працюють служби сервера, призначаються такі права користувача та привілеї:

• Дозволити заміну маркера рівню процесу (Act as part of operating system);
• Дозволити фіксувати сторінки в пам’яті (Lock pages in memory);
• Дозволити обхід перехресної перевірки (Bypass traverse checking);
• Дозволити вхід як служба (Log on as service);
• Дозволити налаштування квот пам’яті для процесу (Increase quotas);
• Дозволити заміну рівня процесу (Replace a process level token);
• Заборонити локальний вхід у систему (Deny logon locally);
• Заборонити вхід у систему через служби терміналів (Deny log on through Terminal Services).

Заборона локальної реєстрації в системі та з’єднання через сервер термінала обмежують можливості зловмисника в разі компрометації системи. Також необхідно видалити групу Domain Users у користувачів, які мають право Logon Locally.

Для роботи служби Agent SQL Server рекомендується вибирати обліковий запис користувача Windows, що не входить до групи Адміністратори. Однак існують обмеження під час адміністрування кількох серверів, коли обліковий запис служби агента SQL Server не входить до локальної групи Адміністратори. Зокрема, група Адміністратори потрібна, щоб використовувати можливість автоматичного перезапуску або створення типів CmdExec (виклик команд операційної системи) і ActiveX Script, які не належать адміністратору SQL Server.

Browser SQL Server виконується як служба Windows і запускається на UDP-порту 1434. Під час запуску оглядач SQL Server зчитує дані з реєстру, визначає всі екземпляри SQL Server на цьому комп’ютері та призначає для них порти. Оглядач SQL Server прослуховує вхідні запити на ресурси Microsoft SQL Server і надає відомості про екземпляри SQL Server, встановлені на комп’ютері. Під час зупинення або вимкнення служби «SQL Server, оглядач» необхідно призначити кожному іменованому екземпляру конкретні номери портів. Права, які необхідно призначити оглядачу SQL Server для підвищення безпеки:

• Заборонити мережевий доступ до цього комп’ютера.
• Заборонити локальний вхід у систему.
• Заборонити вхід у систему як пакетне завдання.
• Заборонити вхід у систему через служби терміналів.
• Дозволити вхід у систему як служба.
• Дозволити читання та запис розділів реєстру SQL Server, що стосуються мережі (порти та канали).

Для роботи екземпляра за замовчуванням (Default) оглядач не потрібний. У MS SQL Server 2000 роль оглядача виконувала служба SQL Server.

Докладніше про налаштування служб можна прочитати на сайті Microsoft.

3.3.7 Використовуйте режими перевірки автентичності засобами MS SQL Server

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

На рисунку показано два способи доступу до сервера.

Це використання логінів SQL Server, які в консолі керування сервером розташовані в розділі Security, і використання облікових записів Windows. Доступ до баз даних відбувається шляхом асоціацій користувачів, які пройшли авторизацію на сервері, з користувачами баз даних.

Для роботи облікових записів SQL Server необхідно використовувати змішаний (mixed) режим перевірки автентичності користувачів. У більшості випадків це можна зробити за допомогою графічних утиліт доступу. Однак для MSDE версії MS SQL Server 2000 оснастки немає. У цьому випадку можна перемкнути режим за допомогою реєстру.

3.7.1.1. Увімкнення змішаного режиму після встановлення

Для роботи 1С:Підприємства 8.1 з MS SQL Server використовується режим авторизації MS SQL Server і Windows. Якщо під час встановлення було вибрано режим авторизації лише Windows (Windows only) — підключитися до інформаційної бази 1С:Підприємства 8.1 не вийде.

Щоб змінити тип авторизації, відкрийте SQL Server Enterprise Manager.

У дереві "Concole Root - Microsoft SQL Servers" розгорніть групу SQL Server Group і виберіть потрібний сервер (відповідає або імені комп’ютера, або (local) — для локального сервера).

Якщо серверів немає — треба зареєструвати новий сервер, вибравши в меню Action - New SQL Server Registration...

На значку сервера зробіть клацання правою кнопкою миші та в контекстному меню виберіть Properties. У вікні, що з’явиться, перейдіть на вкладку Security.

У розділі Security вкажіть Authentication на SQL Server and Windows.

Перезапустіть сервіс, наприклад за допомогою командного рядка:

net stop mssqlservernet start mssqlserver

або перезавантажте комп’ютер зі встановленим MS SQL Server.

Для SQL Server 2005

Щоб змінити тип авторизації, відкрийте SQL Server Management Studio.

У меню File – Connect Object Explorer і виберіть потрібний сервер.

Далі у вікні Object Explorer на значку сервера зробіть клацання правою кнопкою миші та в контекстному меню виберіть Properties. У вікні, що з’явиться, перейдіть на вкладку Security. У розділі Server authentication вкажіть SQL Server and Windows Authentication mode.

Перезапустіть сервіс. Для цього на значку сервера зробіть клацання правою кнопкою миші та в контекстному меню виберіть Restart.

3.3.7.2 Увімкнення змішаного режиму перевірки автентичності після встановлення за допомогою реєстру

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

За замовчуванням параметр реєстру LoginMode має значення 1 (перевірка автентичності Windows). Щоб увімкнути змішаний режим, значення цього параметра необхідно змінити на 2.

Розташування параметра LoginMode залежить від імені, під яким встановлено екземпляр MSDE. Якщо MSDE було встановлено з іменем за замовчуванням, параметр LoginMode міститься в такому розділі реєстру:

HKLM\Software\Microsoft\MSSqlserver\MSSqlServer\LoginMode

Якщо MSDE було встановлено під іншим іменем, параметр LoginMode міститься в такому розділі реєстру:

HKLM\Software\Microsoft\Microsoft SQL Server\ім’я_екземпляра\MSSQLServer\LoginMode

Під час використання SQL Server 2005 Express Edition параметр LoginMode міститься в такому розділі реєстру:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.4\MSSQLServer

Щоб присвоїти параметру LoginMode значення 2, виконайте такі дії.

1. За допомогою компонента «Служби» панелі керування зупиніть MSSQLSERVER та інші пов’язані служби (наприклад, SQLSERVERAgent).

2. Натисніть кнопку Пуск, виберіть пункт Виконати, введіть команду regedt32 і натисніть кнопку ОК.

3. Знайдіть такий розділ реєстру (відповідно до імені, під яким було встановлено MSDE):

HKEY_LOCAL_MACHINE\Software\Microsoft\MSSqlserver\MSSqlServer\

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\ім’я_екземпляра\MSSQLServer\

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.4\MSSQLServer\

4. На правій панелі вікна редактора реєстру двічі клацніть параметр LoginMode.

5. У діалоговому вікні Зміна параметра DWORD установіть для параметра значення 2, виберіть варіант Шістнадцяткове та натисніть кнопку ОК.

6. Щоб зміни набрали чинності, запустіть служби MSSQLSERVER і SQLSERVERAgent.

Зверніть увагу. Можливістю керування перемиканням режимів автентифікації за певних умов може скористатися зловмисник.

3.3.8 Розмістіть сервер у приміщенні, недоступному для сторонніх

Як компромісний варіант, використовуйте серверну стійку та надавайте ключі особам за затвердженим списком.

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

В Інтернеті можна знайти статті, які рекомендують шифрувати дані баз даних. Це можна робити як штатними засобами Windows, так і використовуючи ключі eToken та програми сторонніх виробників типу Jetico Bestcrypt або PGPDisk. Крім цього можна зустріти рекомендації створювати бази даних у кількох файлах, один із яких шифрувати.

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

3.3.10. Використання неформатованих розділів

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

SQL Server дозволяє використовувати для створення файлів бази даних «неформатовані» (або «сирі» — raw) розділи. Неформатований розділ — це розділ диска, який був створений за допомогою утиліти fdisk або Disk Administrator, але не був відформатований. На такому розділі не існує файлової системи (FAT або NTFS), тому там неможливе зберігання файлів операційної системи. Проте якщо під час створення бази даних як фізичне ім’я файла вказати неформатований розділ, то SQL Server 2000 створить у цьому розділі блок даних (назвемо його файлом), який займе весь вільний простір. Оскільки під час створення файла буде зайнято весь доступний простір, збільшення розміру файла в цьому випадку неможливе. Як фізичне ім’я файла необхідно вказати лише літеру розділу, наприклад F. Задання неформатованого розділу іншим способом (а такі є — наприклад, формат, що використовується у файлі boot.ini) не допускається. Тобто, щоб мати можливість розмістити файл бази даних на неформатованому розділі, потрібно призначити цьому розділу конкретну літеру, сконфігурувавши його таким чином як логічний диск.

На рисунку показано неформатований розділ із логічним диском F.

На неформатованому розділі можна розмістити лише один файл бази даних. Навіть після того, як SQL Server створить у цьому розділі файл, операційна система сприйматиме розділ як неформатований або як розділ із невідомою файловою системою. Звичайні операції роботи з файлами, що виконуються операційною системою, будуть недоступні. Тобто не можна буде виконувати копіювання, видалення, зміну або переміщення створеного файла. Крім того, операції резервного копіювання за допомогою утиліти Windows NT Backup також будуть недоступні. Однак допускається створення резервних копій бази даних і журналу транзакцій засобами SQL Server. При використанні неформатованих розділів недоступні інструменти перевірки цілісності диска. Ба більше, неможлива «гаряча» заміна пошкоджених кластерів, яка виконується для файлової системи NTFS на дисках SCSI. У разі розміщення файлів бази даних на звичайних дисках із файловою системою є можливість скопіювати ці файли та підключити до іншого сервера SQL. За наявності неформатованих розділів скопіювати дані буде практично неможливо, оскільки в операційних системах сімейства Windows не реалізовано механізми роботи з неформатованими розділами.

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

Приклад створення бази db_buh у неформатованому розділі.

USE master
GO
CREATE DATABASE db_buh
ON ( NAME = db_buh,   FILENAME = 'f:') LOG ON( NAME = 'db_buh_log', FILENAME = 'g:' )
GO            

На рисунку показано приклад створення бази в сирих розділах дисків F і G.

4. Використання «старих» логінів

4.1 Виявлення загрози

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

Можна спробувати розробити автоматизовану процедуру перевірки тривалої неактивності облікових записів та їх автоматичного видалення

4.2 Можливі наслідки

Звільнений співробітник може скористатися своїм старим обліковим записом.

4.3 Заходи захисту

Регулярне адміністрування записів

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

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

1) Користувачі Windows (локальні облікові записи Windows і в служби каталогів Active Directory)

Факт застосування облікового запису Windows можна визначити за журналом подій безпеки Windows.

2) Користувачі інформаційних баз 1С:Підприємства

Факт використання облікового запису фіксується в журналі реєстрації 1С:Підприємства

3) Користувачі сервера MS SQL Server

Факт використання облікового запису фіксується в логах MS SQL Server (відповідно до налаштувань)

4) Користувачі баз даних MS SQL Server

5) Адміністратори центрального сервера кластера серверів 1С:Підприємства 8.1

6) Адміністратори кластера 1С:Підприємства

7) Облікові записи Windows для контексту виконання служб 1С:Підприємство 8.1 і MS SQL Server (та інших СУБД)

Крім того, слід розуміти, що:

• Користувачі Windows (1) можуть виступати як Користувачі 1С:Підприємство 8.1 (2), як Адміністратори файла кластерів (5) і Адміністратори кластера (6)

• Користувачі Windows (1) можуть бути Користувачами серверів СУБД (3). Однак 1С:Підприємство 8.1 використовує облікові записи самої СУБД (3)

• Користувачі СУБД (3) неявно отримують доступ до бази даних, «пов’язуючи» з обліковим записом бази даних (4). Наприклад, користувач «dbo» — це власник бази (dbowner). Користувач СУБД із роллю «Створювача бази», у MS SQL Server це «dbcreator», вважається користувачем бази «dbo»

• Облікові записи Windows (1) також є контекстом роботи служб (7). Тому не надавайте ці записи для роботи звичайних користувачів (1),(2)

• Розробники конфігурацій на платформі 1С:Підприємство також можуть використовувати програмне розмежування доступу. Для цього, як правило, створюється довідник «Користувачі». Керування налаштуваннями такого довідника виконується в режимі «1С:Підприємство», а не Конфігураторі. Максимальні права доступу до довідника «Користувачі» — читання даних.

5. Несанкціонований доступ до файлів кластера серверів

5.1 Виявлення загрози

Ознаки можливої загрози:

• Відсутність облікових записів адміністраторів кластера
• Використання одного облікового запису для служб ragent, rmngr, rphost
• Файловий доступ до сервера
• Фізичний доступ до сервера

5.2 Можливі наслідки

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

5.3 Заходи захисту

5.3.1 Створити адміністратора центрального сервера та адміністратора кластера серверів 1С:Підприємства

Створіть адміністратора центрального сервера

Якщо не задано адміністратора центрального сервера, то будь-який користувач зможе створити новий кластер.

Створіть адміністратора кластера

Якщо не задано адміністратора кластера, то будь-який користувач зможе редагувати параметри кластера.

5.3.2 Використовувати різні облікові записи для різних служб кластера серверів 1С:Підприємства

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

• Каталог даних застосунку
• Каталог тимчасових файлів.

Загальна ідеологія роботи зі службовими даними полягає в тому, що доступ до службових даних кластера серверів повинні мати лише менеджер кластера (rmngr.exe) та агент сервера (ragent.exe). Робочі процеси (rphost.exe) використовують службові дані лише через менеджер кластера, оскільки є потенційно небезпечними (у них можуть виконуватися фрагменти коду конфігурацій).

На рисунку показано загальну схему кластера

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

У каталозі даних застосунку під час встановлення кластера серверів 1С:Підприємства 8.1 створюється спеціальний каталог, призначений лише для файлів кластера серверів 1С:Підприємства.

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

На рисунку показано налаштування каталогу кластера.

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

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

Щоб rphost запускався від імені користувача RPHOSTUSER, а
ragent запускається від USR1CV81, необхідно зробити таке:

• до каталогу даних центрального сервера () помістити файл swpuser.ini такого змісту:

user=\\server\hostuser
password=пароль

На рисунку показано налаштування користувача процесу RPHOST.

• Користувача USR1CV81 включити до локальних політик безпеки:
  • Дозволити заміну маркера рівню процесу (Adjust memory quotas for a process);
  • Дозволити заміну маркера рівня процесу (Replace a process-level token);
  • Дозволити вхід як служба (Log on as service);
  • Дозволити вхід як пакетне завдання (Log on as batch job)
• Користувача RPHOSTUSER включити до локальних політик безпеки:
  • Вхід як служба (Log on as service)
  • Вхід як пакетне завдання (Log on as batch job).

На рисунку показано користувачів процесів RPHOST, RAGENT і RMNGR кластера 1С:Підприємство 8.1.

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

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

5.3.3 Виключіть файловий доступ до робочих серверів кластера

Для сервера 1С:Підприємства виключіть такі сервіси, як "спільний файловий доступ", "поштовий сервер", "інтернет-проксі", "веб-сервери" тощо.

Приклад вимкнення файлового доступу мережею.

5.3.4 Розмістіть сервер у приміщенні, недоступному для сторонніх

Як компромісний варіант, використовуйте серверну стійку та надавайте ключі особам за затвердженим списком.

6. Вразливості операційної системи, СУБД

6.1 Виявлення загрози

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

6.2 Можливі наслідки

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

6.3 Заходи захисту

• Виконуйте оновлення операційної системи

• Виконуйте оновлення СУБД

• Користуйтеся послугами компаній, що спеціалізуються на безпеці

7. Віруси, трояни, логери

7.1 Виявлення загрози

Присутність шкідливих програм виявляється або за допомогою антивірусів, або за фактом шкідливої діяльності вірусу.

7.2 Можливі наслідки

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

7.3 Заходи захисту

7.3.1 Використовуйте брандмауери.

Брандмауер — засіб захисту, який відстежує та обмежує обмін даними між комп’ютером і мережею або Інтернетом, тобто захищає комп’ютер від несанкціонованого доступу ззовні.

Починаючи з Windows XP, операційні системи компанії Microsoft стали містити вбудований брандмауер (мережевий екран, firewall). Для Windows XP SP2 і Windows Vista брандмауер за замовчуванням увімкнений.

Докладніше на сайті Microsoft.

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

Увімкнений брандмауер (особливо програмний) знижує швидкодію. У зв’язку з цим рекомендується уникати використання брандмауерів на сервері СУБД і сервері 1С:Підприємства.

Можливим наслідком використання брандмауера, який не налаштований для роботи з 1С:Підприємство 8.1, може бути повідомлення про помилку: «Не виявлено ключ

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

Щоб додати програму 1С:Підприємство 8.1 до списку винятків брандмауера Windows XP SP2, необхідно виконати такі дії:

• Увійдіть у систему за допомогою облікового запису адміністратора.
• Виберіть у меню Пуск пункт Виконати, введіть команду Firewall.cpl і натисніть кнопку ОК.
• Відкрийте вкладку Винятки.
• На вкладці Винятки натисніть кнопку Додати програму.
• Натисніть кнопку Огляд, перейдіть до каталогу програми (зазвичай C:\Program Files\1cv81\bin), знайдіть програму 1cv8.exe і натисніть кнопку ОК.
• Натисніть кнопку ОК.

Якщо в мережі використовується комп’ютер із HASP License Manager і на ньому ввімкнений брандмауер, необхідно додати HASP License Manager до списку винятків брандмауера. У Windows XP SP2 для цього необхідно виконати такі дії:

• Увійдіть у систему за допомогою облікового запису адміністратора.
• Виберіть у меню Пуск пункт Виконати, введіть команду Firewall.cpl і натисніть кнопку ОК.
• Відкрийте вкладку Винятки.
• На вкладці Винятки натисніть кнопку Додати програму.
• Натисніть кнопку Огляд, перейдіть до каталогу %Windir%\System32\, знайдіть програму nhsrvw32.exe і натисніть кнопку ОК.
• Натисніть кнопку ОК.

Можливі випадки, коли брандмауер увімкнений на сервері або як сервер використовується комп’ютер із настільною операційною системою, наприклад Windows XP SP2.

Порада. Зовсім не обов’язково запам’ятовувати порти та виконувані файли, які необхідно прописувати у брандмауері.

Щоб побачити «реальну» картину роботи клієнт-серверного варіанта та використовуваних портів (наприклад, щоб налаштувати брандмауер), можна скористатися безкоштовною утилітою TCPView.

7.3.2 Використання антивірусного ПЗ спільно з 1С:Підприємством 8

Антивірусне програмне забезпечення допомагає захищати комп’ютер від відомих вірусів, «черв’яків», «троянів» та інших шкідливих програм, які можуть призвести до збою в роботі комп’ютера. Однак антивірусне ПЗ потребує апаратних ресурсів. За постійно ввімкненого моніторингу всіх дій швидкість виконання всіх інших застосунків, зокрема 1С:Підприємство 8, може помітно знизитися. Наведемо рекомендації для кожного з компонентів клієнт-серверної архітектури 1С:Підприємство 8.

7.3.2.1 Використання антивірусного ПЗ на сервері з MS SQL Server

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

Замість цього слід періодично сканувати SQL Server за допомогою сканерів вірусів, бажано в періоди мінімального навантаження.

7.3.2.2 Використання антивірусного ПЗ на кластері серверів 1С:Підприємство 8

Також рекомендується уникати постійно ввімкненого моніторингу. Виконуйте сканування на віруси в періоди мінімального завантаження.

7.3.2.3 Використання антивірусного ПЗ на клієнті 1С:Підприємство 8

Комп’ютер із клієнтською частиною 1С:Підприємство 8 має найбільший ризик зараження вірусами. Слід розуміти, що, використовуючи антивірусну програму, Ви повинні вибрати розумний компроміс між ступенем захисту та швидкодією.

Як варіант налаштування антивірусу пропонується:

• Додати до винятків перевірюваних файлів:
  • файли з розширеннями *.1CD, *.1cl, *.log, *.elf, *.pfl, *.usr, *.v8i, *.lst, *.st, *.snp, *.epf, *.dat
  • виконувані застосунки: 1cv8.exe, ragent.exe, rmngr.exe, rphost.exe, 1CV8 Servers.msc з папки C:\Program Files\1cv8\bin\ (C:\Program Files (x86)\1cv8 — для 32бітної версії в 64бітному середовищі) або C:\Program Files\1cv81\bin\ (C:\Program Files (x86)\1cv81 — для 32бітної версії в 64бітному середовищі)
• Виключити з перевірки підкаталоги зі встановленими 1С:Підприємство, зазвичай
  • C:\Program Files\1cv8
  • С:\Program Files (x86)\1cv8
  • C:\Program Files\1cv81
  • C:\Program Files (x86)\1cv81
• якщо клієнт поєднано із серверною частиною, то для сервера також додайте
  • C:\Documents and Settings\All Users\Application Data\1С
  • C:\Documents and Settings\USR1CV81\Local Settings\Application Data\1C\1Cv81

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

• C:\Documents and Settings\<User>\Local Settings\Temp
• C:\WINNT\Temp

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

7.3.3 Виключення доступу до інтернету

Повністю виключіть можливість підключення до серверів через інтернет.

8. Паролі на моніторах, слабкі паролі

8.1 Виявлення загрози

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

8.2 Можливі наслідки

Серйозність загрози прямо залежить від прав запису цього співробітника.

8.3 Заходи захисту

8.3.1 Використовуйте політику складних паролів, виконуйте перевірку складності паролів

Паролі є «першою лінією захисту» від несанкціонованого доступу до Вашої інформації. Незважаючи на всі сучасні технології, часто вони стають основною ціллю зловмисника. Користувачі часто вигадують дуже прості паролі. Вони можуть означати день народження користувача, ім’я улюбленої кішки або номер мобільного. Такі паролі легко підібрати, застосовуючи загальновідомі закономірності. Іншим способом є перебір усіх можливих комбінацій символів.

Важливо, щоб користувачі складали надійні паролі. Хороший пароль — це той, який вкрай важко вгадати або підібрати, але дуже легко запам’ятати.

Щоб забезпечити «складні для зламу» паролі, у Windows використовується політика "Пароль повинен відповідати вимогам складності":

• містить щонайменше 7 символів;

• поєднує літери, числа та спеціальні символи;

• не міститься у словниках;

• не є ім’ям команди;

• не є ім’ям людини;

• не є ім’ям користувача;

• регулярно змінюється;

• значною мірою відрізняється від попередніх паролів.

Політику Windows наведено на рисунку.

Докладніше про застосування політики паролів Windows можна прочитати на сайті Microsoft. У MS SQL Server 2000 контроль складних паролів відсутній. У MS SQL Server 2005 існує можливість використовувати політику складних паролів Windows. Для кожного логіна сервера політика призначається персонально. Тобто один логін може відповідати вимогам складного пароля, а інший — ні.

На цьому рисунку параметр Enforce password policy означає застосування політики паролів, параметр Enforce password expiration означає застосування політики закінчення строку дії паролів.

Паролями можна керувати через Transact-SQL:

На цьому рисунку за допомогою коду Transact – SQL для наявного логіна було змінено пароль і ввімкнено параметр CHECK_POLICY (установлено значення ON — застосування політики паролів), увімкнено параметр CHECK_EXPIRATION (установлено значення ON — Політика закінчення строку дії паролів).

Перевірка складності паролів користувачів також присутня в 1С:Підприємстві 8.1.

Для керування перевіркою складності виберіть меню «Адміністрування – Параметри інформаційної бази».

На рисунку показано налаштування вимог до паролів конфігурації.

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

8.3.2. Застосовувати пристрої автоматичної автентифікації

Наприклад, ви можете використовувати смарт-картки.

9. Перехоплення інформації

9.1 Виявлення загрози

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

9.2 Можливі наслідки

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

9.3 Заходи захисту

9.3.1 Організуйте захист трафіку штатними засобами 1С:Підприємства (захист передавання даних кластеру серверів)

Під час створення нової бази ви вказуєте параметр «безпечне з’єднання» (захищене з’єднання). Існує можливість вибрати одне з трьох значень:

• Вимкнено
• Установлення з’єднання
• Постійно

На рисунку показано вибір параметра «Захищене з’єднання» для новостворюваної бази.

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

Рівень «Вимкнено» є найнижчим, рівень «Постійно» — найвищим. При цьому використовується безпечне з’єднання за протоколом TCP/IP із шифруванням алгоритмами RSA і Triple DES.

Рівень безпеки «Постійно»

Використання рівня безпеки «Постійно» дозволяє повністю захистити весь потік даних (як паролі, так і безпосередньо дані) між клієнтом і кластером серверів. При цьому весь обмін відбувається з використанням алгоритмів шифрування RSA і Triple DES. Слід враховувати, що при цьому можливе зниження продуктивності системи.

Рівень безпеки задається під час створення інформаційної бази. Ця інформація зберігається як на клієнті (у списку інформаційних баз), так і в кластері серверів (у реєстрі кластера). Після створення інформаційної бази її параметри, збережені в реєстрі кластера, змінити вже не можна. Однак можна змінити рівень безпеки, вказаний для цієї інформаційної бази на клієнті. Виконати налаштування рівня безпеки підключення через параметр запуску /SLev, який визначає рівень захищеності з’єднання клієнта із сервером 1С:Підприємства

Можливі значення:

/SLev0 – незахищене з’єднання.

/SLev1 – захищене з’єднання лише у процесі виконання автентифікації.

/SLev2 – захищене з’єднання протягом усього сеансу.

Відсутність параметра еквівалентна /SLev0.

На рисунку показано властивості ярлика, що викликає 1С:Підприємство із зазначенням рівня захищеності з’єднання.

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

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

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

Подальший обмін даними виконується відповідно до фактичного рівня безпеки, при цьому як клієнт, так і сервер шифрують передані дані з використанням сеансового ключа за алгоритмом Triple DES, у якого сам процес шифрування швидший, ніж RSA.

Рівень безпеки «Установлення з’єднання»

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

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

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

Рівень безпеки «Вимкнено»

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

Після встановлення з’єднання перший обмін даними виконується з використанням шифрування за алгоритмом RSA. Подальший обмін виконується незашифрованими даними.

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

Консоль кластера серверів взаємодіє з агентом сервера (процес ragent.exe). Бажаний рівень безпеки задається під час старту агента сервера. Фактичний рівень безпеки буде вибрано агентом сервера як максимальний із зазначеного під час старту та рівнів безпеки всіх кластерів, розташованих на цьому центральному сервері. Рівень безпеки кластера задається під час його створення (програмного або інтерактивного).

На рисунку показано реквізит «Безпечне з’єднання» консолі кластерів.

Спеціалістам із безпеки також може знадобитися знання алгоритмів шифрування, що застосовуються в 1С:Підприємство 8.1

• Криптографічна система RSA є системою асиметричного шифрування, у якій для кодування повідомлення використовується один ключ (публічний), а для розшифрування інший (секретний), тобто криптографічний алгоритм із відкритим ключем.
• Triple DES використовує потрійне шифрування симетричним алгоритмом DES. Це симетричний алгоритм шифрування, у якому один ключ використовується як для зашифровування, так і для розшифровування повідомлень.

За рівня безпеки «Постійно» виконується шифрування за такою схемою

У загальному вигляді протокол взаємодії клієнта та кластера серверів наведено на наступному рисунку:

Протокол взаємодії однаковий як для менеджера кластера (rmngr.exe), так і для робочого процесу (rphost.exe): після встановлення з’єднання перший обмін даними виконується з використанням шифрування за алгоритмом RSA, подальший обмін даними виконується з використанням шифрування за алгоритмом Triple DES.

Для рівня «Установлення з’єднання» у загальному вигляді протокол взаємодії клієнта та кластера серверів наведено на наступному рисунку:

Після встановлення з’єднання перший обмін даними виконується з використанням шифрування за алгоритмом RSA, потім обмін даними виконується з використанням шифрування за алгоритмом Triple DES до завершення процедури автентифікації. Подальший обмін виконується незашифрованими даними.

Для рівня безпеки «Вимкнено» у загальному вигляді протокол взаємодії клієнта та кластера серверів наведено на наступному рисунку:

Після встановлення з’єднання клієнт надсилає Відкритий ключ RSA і рівень безпеки до кластера серверів. Менеджер кластера надсилає йому повідомлення про новий рівень безпеки, зашифроване Відкритим ключем RSA. Подальший обмін виконується незашифрованими даними. Аналогічно здійснюється обмін даними клієнтського застосунку з робочим процесом кластера.

Паролі адміністраторів кластера серверів і паролі доступу до інформаційних баз зберігаються на кластері серверів у зашифрованому вигляді. Для цього використовується шифрування алгоритмами SHA1 і AES128.

SHA1 — це алгоритм контрольного сумування. З його допомогою зберігаються паролі, які перевіряє система 1С:Підприємство (наприклад, пароль адміністратора кластера, адміністратора центрального сервера). При цьому вихідний текст збережених паролів відновити не можна, а можна лише перевірити збіг контрольної суми введеного пароля зі збереженою контрольною сумою.

AES128 — це алгоритм шифрування. З його допомогою зберігаються паролі, для яких має відновлюватися вихідний текст (наприклад, паролі доступу до СУБД).

9.3.2 Захист MS SQL Server

Microsoft SQL Server дозволяє шифрувати трафік, що передається мережею. Для цього використовується Secure Sockets Layer (SSL) під час передавання даних між сервером кластера та MS SQL Server. Якщо робочий сервер кластера і MS SQL Server на одному комп’ютері, то використовується протокол обміну Shared Memory (і шифрування не використовується).

Для шифрування всіх переданих даних для MS SQL Server 2000 необхідно скористатися утилітою "Server Network Utility". На вкладці "General" установіть прапорець "Force protocol encryption".

На рисунку вказано шифрування на стороні клієнта SQL Server

Метод шифрування вибирається залежно від використовуваного клієнтським застосунком (тобто сервером застосунків 1С). Для використання SSL необхідно правильно налаштувати службу видавання сертифікатів у мережі.

Докладніше про шифрування сертифікатами можна прочитати на сайті Microsoft.

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

На рисунку показано шифрування на стороні сервера.

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

Додатковими заходами захисту передавання даних між сервером застосунків і MS SQL Server під час використання протоколу TCP/IP можна вважати зміну налаштувань, заданих за замовчуванням. Це використання нового порту замість стандартно використовуваного порту 1433. При цьому цю зміну також має бути виконано для комп’ютера із сервером застосунків, тобто має використовуватися один і той самий порт.

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

На рисунку показано «приховування» SQL Server.

MS SQL Server 2005 підтримує мережеві з’єднання як із клієнтом SQL Server 2000, так і з «власними» клієнтами Native Client.

Загальне налаштування мережевої конфігурації сервера тут.

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

Ще один момент, який слід знати, але він сам по собі не вважається вразливістю.

Рекомендований режим підключення до SQL Server для процесів 1С:Підприємства 8.1 — змішаний режим «mixed» авторизації (SQL Server і Windows). Для підключення необхідно використовувати облікові записи SQL Server. Проте існує можливість використовувати режим авторизації Windows.

На рисунку показано режим авторизації Windows для SQL Server 2005.

У цьому випадку необхідно визначити, який обліковий запис Windows використовується процесом rphost.exe.

На рисунку показано в диспетчері процеси rphost.exe та обліковий запис RPHOSTUSER, що використовується для цих процесів.

І вказати для запису права доступу до SQL Server і можливість створювати бази.

На рисунку створено користувача SQLSRV\RPHOSTUSER (він же користувач процесів rphost.exe) і вказано дозволи для роботи з базами даних на SQL Server 2005.

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

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

Користувача бази даних і пароль користувача не вказано. Буде використано обліковий запис робочого процесу кластера.

Звідси випливає висновок: для всіх інформаційних баз 1С:Підприємства 8.1 користувач буде один!

Такий підхід знижує загальну безпеку системи, оскільки, отримавши цей єдиний пароль, зловмисник отримає доступ до всіх баз одразу.