Дана стаття розрахована на 2х осіб в компанії використовуючої 1С: Підприємство.
Перша особа, це ключові користувачі (зазвичай менеджери), які стурбовані проблемами несанкціонованого доступу до комерційної інформації. Даній категорії осіб слід уважно вивчити підрозділи «Злом» нижче. У даних розділах міститься інформація про те як рядовий користувач може організувати злом БД. Ви можете перевірити чи закриті дані від можливості викрадання даних чи ні, тобто зробити невеликий аудит системи безпеки. Якщо ви бачите, що доступ не закритий, звернетеся до адміністратора з проханням терміново вирішити дану проблему.
Друга особа, це системні адміністратори, що забезпечують безпеку 1С:Підприємства. Аналізуючи розділи злом ви зможете отримати уявлення про типові атаки. У розділах «Захист» містяться рекомендації по організації протидії злому.
Злом і захист 1С в локальній і мережевій версії
Злом
Злом зазвичай складається з 2х стадій. Перша стадія це викрадання бази методом копіювання, друга стадія це аналіз викраденої бази. Для копіювання бази користувач зазвичай використовує штатні засоби Windows типу Explorer, за допомогою яких копіює на дискету DBF-файли бази.
Аналіз викраденої бази зазвичай проводиться за допомогою помічника-студента. Як правило, аналіз проводять в Excel.
Захист
Зверніть увагу, даному методу злому неможливо протидіяти використовуючи програмні рішення на мові 1С. Викрадачеві не потрібно зламувати паролі і обходити програму, він дістає доступ до даних відразу мимо 1С. Це важливий коментар щодо "дитячого саду" в захисті 1С. Мені доводилося зустрічати шарлатанів, які пропонують зробити "примочку" в конфігурації 1С для "100% захисту". Це просто втрачені гроші, захист повинен прикривати дані.
Перейдемо тепер до захисту. Ситуація важка: база даних 1С не зашифрована, зберігається у відомому форматі, закрити доступ користувачів до неї не можна, оскільки вони з нею працюють. Можна спробувати накласти на файли бази атрибут hidden, але самі розумієте це захист тільки від дурня. Якщо у вас 1С працює під Windows NT (Windows 2000, Windows XP) можна закрити від модифікації користувачами конфігурацію і файл паролів, але дані не закрити. Можна ввести драконівські правила роботи і вилучити дисководи у користувачів. Проте користувачі можуть відправити викрадену базу поштою, проаналізувати її на місці без винесення з фірми або просто прийти з Notebook або своїм дисководом.
Висновок
Надійно захистити базу навіть від недосвідчених користувачів в такому варіанті фактично неможливо.
Злом і захист 1С для Термінального Сервера
Microsoft Terminal Server користується заслуженою репутацією хорошого рішення, якщо з 1С працюють 5-10 користувачів і у багатьох погані комп'ютери. У разі використання терміналу користувач працює з програмою не на своїй машині, а на термінальному сервері. Управляє користувач програмою через спеціальне вікно терміналу. Термінал зручний тим, що дозволяє працювати 1С на слабких і старих машинах. Інший аспект терміналу - це можливість підвищити безпеку 1С. Підвищення безпеки не відбувається автоматично з установкою терміналу, потрібна настройка, причому серйозна. Сенс настройки полягає в тому, що б заховати на терміналі від користувача засобу копіювання файлів і дати йому працювати тільки з 1С. Якщо термінал настроєний правильно, то після реєстрації користувач відразу виявляється в 1С, саме такий варіант ми і розглянемо.
Злом
Упевненість багатьох менеджерів в надійності захисту MS Terminal Server тільки полегшує завдання. Злом бази під терміналом також зазвичай полягає в копіюванні бази і подальшому її аналізі. Якщо аналіз в цілому робиться також, то копіювання бази вимагає якогось трюкацтва від користувача. Перше що перевіряє зломщик, це те, що адміністратор схалтурив в настройці терміналу. Запуск 1С при старті терміналу можна набудувати на клієнтові і на сервері. На клієнтові простіше набудувати і більшість адміністраторів йдуть таким шляхом. Для зняття автозапуску 1С з клієнта потрібно увійти в Client Connection Manager, зайти у властивості з'єднання і прибрати галочку "Start the following program". Після цього зломщик входить в термінал, але потрапляє не в 1С, а на Desk Top і копіює базу.
Якщо адміністратор добре попрацював над безпекою, тоді може спрацювати один з наступних методів. Опинившись в 1С користувач натискає Ctrl+o або Ctrl+s, з'являється вікно запиту файлу. В ім'я файлу вводять *.DBF, потім переходять в каталог бази 1С, виділяють її, утримуючи клавішу Shift, і копіюють в Clipboard натиснувши Ctrl+ins. Потім перегортають у вікні каталоги вгору поки не знайдуть Network Neighborhood (Мережеве оточення). Зазвичай відкривають по мережі свою машину і копіюю базу на її мережеву теку натиснувши Shift-ins. Мережева тека може бути створена і на дисководі через закладку Sharing у властивостях теки дискети.
Окрім даного способу користувач може, використовуючи напівдокументовані можливості 1С зробити наступне: запустити з 1С віддалено файл-менеджер Far, запустити спеціальну конфігурацію або звіт 1С., які таємно копіюють базу, змусити саму 1С скопіювати базу, через команди вручну.
Прослуховування мережі. Багато хто живе ілюзією щодо того, що інформацію, яку передає термінал по мережі не прослуховувати. Витягнути з термінального протоколу який пароль в 1С набирає користувач елементарне завдання, якщо використовується застарілий Windows NT Server Terminal Edition (STE).
Захист
Деякі заходи щодо захисту ми вже зачепили розглядаючи напад. Перше що потрібно зробити це набудувати "Start the following program at logon" на сервері. Правда тут є тонкий момент, при настройці "в лоб", користувачі втратять доступ до ресурсів домена. Варто подумати і проконсультуватися перед установкою терміналу, тим паче, що неправильно поставлені ліцензії терміналу фактично "прогорають".
Наступний момент, ми можемо закрити від користувача непотрібні застосування через засоби NTFS. Проте, як видно вище, користувач може використовувати засоби копіювання фактично ні чого не запускаючи на сервері. Цікавий момент, відключити в 1С панель "Файл" з її Ctrl+o і Ctrl+s не можна. Єдино надійний варіант це закрити файловий порт на термінальному сервері. Але в даному випадку перестане працювати друк по мережі, резервне копіювання на аварійний сервер і так далі. Для невеликої організації це серйозна проблема, оскільки сервер дорога штука і хоче він використовувати багатофункціонально, а для середньої організації відсутність мережевого друку це просто не серйозно. Я вже не говорю про те, що доведеться накласти заборону на використання Microsoft Office спільно з 1С. Інакше, навіть із закритим портом, базу розпатрають на сервері без копіювання. Загалом, чим більше ми відключимо сервісів, тим безпечніше сервер, можна його і взагалі вимкнути, він буде зовсім безпечним, тільки кому він такий потрібний? Для нормальної роботи доведеться відкрити цілий ряд портів: 25, 53, 80, 110, 119 і ін. Все це потенційні дірки в захисті сервера, та і по самому порту терміналу (3389) можна провести атаку класу DOS.
Прослуховування мережі. Слід зазначити, що найбільш поширений термінальний сервер STE легко прослуховувати, багаторівневе шифрування терміналу реалізоване в Windows 2000. Рішення з високою безпеку зазвичай збирають на базі Citrix Metaframe, оскільки даний продукт має цілий набір серйозних засобів захисту (Citrix Secure Gateway, SSL 128bit, SECUREICA, Socks 4/5, Ticketing і ін.) Проте навіть для 10 робочих місць ця система вам обійдеться приблизно в $5000. Додайте сюди ще апгрейд сервера. Термінальний сервер Microsoft йде безкоштовно в Windows 2000, але за клієнтські місця все одно треба платити по $400 за кожен пакет з 5 ліцензій.
Висновок
Термінальний сервер як мінімум дозволяє підвищити трудомісткість злому, підвищення безпеки даного рішення вимагає вилучення у користувачів цілого ряду сервісних функцій і можливостей. Інший аспект – надзвичайно висока вартість рішень з високим рівнем безпеки на базі термінального рішення: від $5000 до $10000.
Злом і захист 1С для Microsoft SQL Server
Якщо Microsoft Terminal Server не є спеціалізованим засобом призначеним для захисту баз даних, то Microsoft SQL Server (MS SQL) містить в собі наймогутніші засоби безпеки, які тільки можна застосувати до 1С.
Проте стандартне 1С:Підприємство не використовує засобу розмежування доступу MS SQL і кожен користувач працює з базою з повними правами (Database Owner, DBO). На перший погляд це жахає, але не все так погано. Логін і пароль DBO простий користувач не знає, він зберігається в зашифрованому вигляді у файлі 1CV7.DBA. Подібний підхід 1С до організації безпеки на MS SQL здається дилетантизмом тільки на перший погляд. Багато конкурентів 1С програми, що проводять, під MS SQL заявляють як своя конкуретноє перевага, то що авторизація користувачів в їх застосуванні робиться засобами самого MS SQL. Тонкість полягає в тому, що для ефективної організації захисту засобами MS SQL потрібно виключити доступ користувачів до таблиць бази, а вирішити тільки маніпуляції через так звані уявлення (view) і процедури, що зберігаються (stored procedure). Хоча частенько заявляється, що це все є, а реально цього немає, програмісти не встигають робити нові функції, куди ним до захисту даних. Якщо у вашій організації використовується подібна програма під MS SQL, ви можете переконається в відсутності її безпеки просто підключившись до бази через Microsoft Query використовуючи свого користувача і його пароль. Вірогідність 90%, що ви зможете проглядати таблиці. Як видимий підхід 1С надійніше, причому MS SQL 2000 включає засоби для підтримки аналогічного виду безпеки (Application Security Role).
Проблема захисту 1С для MS SQL, точніше загальна проблема захисту класу Application Security Role, полягає в тому, що навіть теоретично не забезпечити надійне шифрування логіна і пароля DBO. Будь-який криптостійкий захист базується на тому, що програма не містить в собі всієї інформації необхідною для розшифровки даних. Зазвичай відсутні дані - це пароль користувача.
Якщо зломщик знає пароль хоч одного користувача 1С, при будь-якому криптозахисті він зможе розшифрувати пароль DBO, оскільки володіє 100% початковій інформації для розшифровки.
Злом
Злом 1С для SQL зазвичай складається з 2х стадій. Перша стадія це дешифрування пароля DBO. Друга стадія це аналіз даних через пряме підключення до MS SQL за допомогою Microsoft Query і Excel. Друга стадія може полягати і в копіюванні бази, але це роблять рідше.
Дешифрування пароля DBO. Треба сказати, що фахівці 1С представляючи безнадійність захисту пароля DBO застосували зовсім слабкий метод криптування (Xor-шифрування). Тому дешифрування пароля проводиться дуже легко. Для цього зазвичай намагаються скопіювати файл 1CV7.DBA і потім його дешифровують програмами типу unsql.exe. Інший метод не вимагає копіювання файлу, а будується на запуску троянської конфігурації або зовнішнього звіту 1С, які на макромові 1С містять алгоритм дешифрування пароля.
Хочеться сподіватися, що фахівці 1С хоч би зашифрують пароль DBO через пароль користувача або його HASH-код. Це хоч би підвищить вартість злому до $100-$200. За такі гроші зазвичай наймають програміста, який за день в покроковому режимі трасує 1С. Якщо програміст має в своєму розпорядженні файл паролів users.usr і пароль хоч одного користувача, він зможе відстежити роботу механізму аутентифікації 1С в штатному режимі і просто дійти до того місця, де 1С сама розшифрує пароль DBO. Хакер після такого трасування може написати автоматичну програму злому пароля DBO для 1С.
Після отримання пароля DBO зломщик зазвичай приступає до аналізу даних в базі використовуючи Microsoft Query і Excel (див. статтю про доступ через Excel до даних 1С).
Скопіювати базу MS SQL не дуже просте заняття, оскільки це не зробити шляхом копіювання файлів. Потрібна спеціальна програма, наприклад Data Migration Wizard, за допомогою якої можна скопіювати базу 1С з SQL у вигляді DBF-файлов собі на диск.
Також слід зазначити, що можливий злом 1С для SQL шляхом аналізу тимчасових файлів, в яких 1С містить значну частину БД.
Захист
Треба сказати, що у разі MS SQL адміністратор може розвернути засоби аудиту, які дозволять відмітити несанкціонований доступ до баз з Microsoft Query і копіювальників даних. Це можна зробити використовуючи SQL Profiler. Проте потрібна спеціальна і дуже серйозна настройка профайлера. Інакше можна не відмітити злом серед тисяч легальних команд, і крім того, без настройки профайлер у декілька разів знижує швидкість роботи БД.
MS SQL дозволяє задіювати шифрування при передачі даних через SSL.
Інший важливий момент, це настройка входу в базу не під sa, а під окремим користувачам. Наступна дія, це розділення системи на декілька окремих баз 1С. Такими засобами можна мінімізувати збиток, але в цілому дірки для злому залишаються.
Для вирішення проблем безпеки 1С для SQL потрібно задіювати режим Row Level Security з MS SQL. Проте для цього потрібний спеціальний продукт.
Висновок
1С: Підприємство для SQL є найзахищенішою версією даного застосування. Проте, на даний момент існують методи злому 1С для SQL, які в змозі реалізувати досвідчені користувачі.
Для забезпечення безпеки бази для MS SQL потрібний незалежний аудит сервера і розгортання серйозного захисту поверх 1С. Як приклад такого захисту можна привести «Захист 1С: Підприємства для SQL»
Злом і захист 1С для Microsoft SQL Server під Microsoft Terminal Server
Використання 1С під Microsoft SQL Server під Microsoft Terminal Server одночасно дозволяє поєднувати захист даних систем. Описані раніше методи злому і захисту в цілому вірні для даного комплексу. Відзначимо тільки декілька відмітних моментів. Злом і захист будуються навколо розшифровки пароля DBO, на даному етапі ключовий момент захист 1cv.DBA від копіювання засобами Microsoft Terminal Server. Як і у випадку з DBF під Microsoft Terminal Server абсолютного захисту тут не побудувати. Далі захист будується на блокування доступу до MS SQL. Один з основних методів тут закриття порту MS SQL, якщо MS SQL і Microsoft Terminal Server стоять на одній машині. Варіант далеко не ідеальний з погляду вартості устаткування і споживчих якостей системи. Хоча абсолютного захисту і в даному випадку немає, найбільш стійкі до злому варіанти можна побудувати за допомогою продуктів, які задіюють вбудовані засоби безопастності MS SQL.
Злом без злому
Як те ні дивно, але в більшості випадків користувачеві взагалі не потрібне щось зламувати для отримання конфіденційної інформації. Стандартні засоби безпеки 1С дозволяють розмежувати доступ на рівні типу документа, але не підмножини документів. Наприклад, можна дати або не дати право користувачеві на доступ до довідника клієнтів, проте не можна вказати, що потрібний доступ тільки до частини довідника.
Проблема розмежування доступу на рівні підмножин документів заслуговує окремої статті, відзначимо загальні підходи до її рішення.
1) Декілька баз даних 1С. Наприклад, по одній базі для кожного підрозділу. Такий підхід швидко реалізується, але потім виникають проблеми з повторним введенням інформації, перекиданням даних між базами і отриманням консолідованої звітності. У разі використання баз під управлінням MS SQL можна використовувати службу DTS для передачі інформації між конфігураціями, але це тільки частково вирішує проблему.
2) Доопрацювання конфігурації 1С з реалізацією розмежування. Слід зазначити, що це достатньо дорогий проект. Також слід зазначити, що таке рішення не гарантує розмежування доступу на фізичному рівні. В результаті з'являється багато дірок. Найбільша проблема це те, що доводиться вручну програмувати доступ у всіх документах, звітах і журналах. Дуже велика вірогідність, що із-за помилки програміста користувач зможе підібрати такі настройки звіту або журналу, які дадуть йому доступ до потрібної інфорациі. Інша проблема, це можливість аналізу тимчасових файлів 1С і прослуховування мережі для злому.
3) Формування звітів в Excel на базі системи OLAP з MS SQL. Сенс полягає в тому, що звіти можна отримувати не в 1С, а в Microsoft Excel через сервіс OLAP, який входить в MS SQL. Даний сервіс дозволяє конфігурувати безпеку для користувачів. Наприклад, можна вказати статистику по яких клієнтах може переглядати користувач, а по яких ні. Важливе зауваження, більшість настільних OLAP-рішень з маркою «1С: Сумісно» не використовують засобу OLAP з MS SQL і небезпечні з погляду доступу до даних.
4) Використання безпеки на рівні записів бази даних (Row Level Security). В даному випадку користувачеві 1С для SQL закривається доступ до частини об'єктів на рівні сервера. Таке рішення швидко і дешево упроваджується, невимагається зміни конфігурації 1С. Проте для включення Row Level Security з 1С потрібна установка спеціальної програми, наприклад «Захист 1С: Підприємства для SQL». У основі Row Level Security лежить використання Restricted View.
Загальні висновки
Всі версії 1С на основі DBF-файлів достатньо легко можуть бути зламані. Організувати ефективну протидію цьому надзвичайно складно. Можна організувати деяку протидію злому за допомогою MS Terminal Server і Citrix Metaframe. Проте дане рішення буде коштує досить дорого і зажадає вилучення у користувачів цілого ряду можливостей.
1С: Підприємство для SQL може забезпечити надійний захист даних, але тільки у випадку якщо будуть закриті пропуски в його безпеці. Для вирішення даної проблеми можна використовувати продукт «Захист 1С: Підприємства для SQL».
