Стаття - Захист та управління даними у TDMS
Приймаючи рішення про створення власної системи управління технічними даними, наша компанія ясно усвідомлювала те, що ми аж ніяк не перші, хто взявся за вирішення подібного завдання.
Продаючи чужі системи та аналізуючи представлені на ринку вітчизняні та західні програмні продукти, призначені для колективної роботи з технічною інформацією, ми дійшли невтішного висновку. Крім спадщини застарілої архітектури, завищених цін, заплутаних інтерфейсів та налаштувань, багато з цих систем банально не забезпечували необхідного рівня безпеки зберігання та управління даними. Не йдеться про загальновизнаних світових лідерів на ринку PDM/PLM — у цих системах, як правило, все гаразд і з функціональними можливостями, і з безпекою. Але через високу вартість продукту та ще більшу вартість впровадження ці системи недоступні більшості українських підприємств. Явні проблеми з безпекою виявились у систем «середнього класу», до яких належать усі українські продукти та десятки аналогічних західних розробок.
Технічні фахівці навряд чи знайдуть у цій статті щось нове: ми розповімо про основні принципи, на яких будується система захисту та управління даними у TDMS. Але тим більше дивно, що на українському ринку так важко знайти систему, в якій враховано такі очевидні вимоги до побудови систем колективного доступу з метою забезпечення необхідного рівня безпеки.
Вибір СУБД
Перше, на що ми звернули увагу, це вибір системи управління базами даних (СУБД). Вибір проводився за цілим рядом критеріїв: поширеність, зручність роботи, масштабованість Одним із визначальних факторів стали вимоги дозабезпечення необхідного рівня безпеки та безперебійної роботи. Багато постачальників мережного ПЗ люблять розповідати про багатоплатформність, гнучкість Насправді ж часто виявляється, що деяка частина СУБД, які вони пропонують, не може відповідати вимогам безпеки, а сама гнучкість рішення, що підтримує велику кількість платформ, досягається за рахунок спрощення серверної частини ПЗ, ігнорування рекомендацій щодо захисту даних — як наслідок, така СУБД не може використовуватись у системах колективного доступу. Вивчаючи платформи СУБД, ми керувалися принципом «краще менше та краще». Вибір для українського ринку був досить очевидним: Microsoft SQL Server 2000 та Oracle 9i. Іншим можливим варіантом була DB2, але ця система майже невідома в Україні, і тому вже на початковому етапі розвитку TDMS було вирішено не витрачати ресурси компанії на підтримку ще однієї платформи.
І SQL Server, і Oracle мають сертифікати безпеки рівня C2. Обидві системи надійні та забезпечують цілодобову безперебійну роботу без втручання адміністратора. Обидві мають багаторівневі системи захисту даних, вбудовані засоби резервного копіювання та моніторингу. SQL Server, мабуть, найлегша і зручніша в адмініструванні СУБД, яка однаково добре працює з будь-якими обсягами даних. Oracle ж, окрім C2, має ще більше десяти різних сертифікатів безпеки та de facto є стандартом для створення інформаційних систем масштабу підприємства. Не випадково більшість українських та західних підприємств використовують саме SQL Server та Oracle.
Для підключення до сервера бази даних TDMS використовує класичну трирівневу систему аутентифікації. Підключаючись до сервера з «прошитим» обліковим записом, користувач проходить лише перший рівень захисту. Підключившись, вінотримує право запустити процедуру перевірки імені та пароля користувача, а також пароля облікового запису програми. У базі даних зберігаються самі паролі, лише їх цифрові образи, отримані після обробки паролів спеціальної хеш-функцією.
Такий спосіб аутентифікації дозволяє запобігти подвійному введенню пароля, зберігаючи при цьому необхідний рівень безпеки.
Забезпечивши захист на боці сервера БД, але не подбавши про необхідний рівень організації колективної праці в електронній системі, ми надали б розхлябаному користувачеві чудову можливість творити чудеса, яких наїлися вдосталь проектні та конструкторські організації, здійснивши масову комп'ютеризацію і перетворивши свої проекти на файлове звалище.
Права доступу
Система TDMS призначена для колективної роботи з технічними даними та має в системі управління правами доступу низку особливостей, що відрізняють її від «плоських» електронних архівів. До таких властивостей можна віднести можливість призначення прав доступу кожний об'єкт системи, успадкування прав, ієрархічну модель адміністрування.
Можливість призначення прав на кожен об'єкт означає, що для будь-якого інформаційного об'єкта можна визначити користувачів чи групи користувачів, які мають певні права доступу до цього об'єкта. TDMS має гнучкі налаштування, що дозволяють призначати права доступу аж до видимості об'єкта в системі. Для керування правами доступу кожен об'єкт TDMS має адміністратор. Адміністратори TDMS утворюють ієрархію.
Ієрархічна модель управління правами доступу взята із реального життя. На будь-якому підприємстві є особа (директор), яка має практично необмежену владу. Є люди — скажімо, начальники підрозділів, якіперебувають у його підпорядкуванні. Саме такий принцип адміністрування використовується і в TDMS. Головний, системний адміністратор має у підпорядкуванні групу адміністраторів рангом нижче. Він може передати їм право на керування доступом до об'єктів. Кожному з підлеглих адміністраторів можуть підпорядковуватись інші адміністратори Члени адміністративної групи, кожен на своєму рівні, розподіляють права доступу користувачів до об'єктів. Адміністратор вищого рівня може змінювати права доступу до об'єкта, встановлені підпорядкованим йому членом адміністративної групи, а й замінити підлеглого адміністратора будь-яким іншим.
Будь-яка система документообігу має можливість відстежувати стадії роботи з об'єктом (документом). На різних стадіях життєвого циклу проекту, виробу чи окремого документа користувачі мають різні обмеження прав доступу до цих об'єктів. Але як система, призначена для роботи з технічними даними, TDMS наділена додатковими функціями роботи з ієрархічною структурою. Наприклад, без будь-якого програмування можна встановити умови, які не дозволять затвердити документ, якщо він містить незатверджені листи, або затвердити складальну одиницю, у складі якої є незатверджені деталі.
Такий підхід дозволяє узгоджено вести колективну розробку проектів, структуровано зберігати архівну інформацію, суворо визначивши межі прав доступу кожного користувача стосовно кожного об'єкта системи.
Моніторинг дій користувачів
Функції моніторингу можуть стати в нагоді не тільки для припинення дій «інсайдерів» та виявлення ненавмисних шкідників. Завдяки інформації, отриманій в результатімоніторингу, сумлінний адміністратор здатний оптимізувати деякі дії користувачів. Якщо кілька користувачів щодня здійснюють кілька послідовних однотипних операцій, адміністратор може автоматизувати їхні дії.
Не варто забувати і про моніторинг засобами СУБД. Наприклад, аудит рівня C2 Microsoft SQL Server допоможе адміністратору на ранній стадії зафіксувати спроби несанкціонованого доступу.
Історія розробки об'єкту
Історія розробки об'єкта є частиною системи безпеки. Але відображаючи всю інформацію про об'єкт проектування, пов'язані з ним поштові повідомлення, його версії, етапи, історія розробки дозволяє адміністратору об'єкта або іншій уповноваженій особі швидко визначити, чому і на якій підставі були прийняті ті чи інші рішення, чи були виконані всі необхідні вимоги, що стосуються правил розробки технічної документації.
Захист файлів
Здавалося б, можна поставити крапку. Але сервери БД – не файлова система. І як би ми не намагалися, вони не працюватимуть із файлами швидше, ніж операційна система. Падіння продуктивності стає особливо помітним під час роботи з великими файлами. Ще один недолік зберігання файлів у СУБД проявляється, коли організація працює у розподіленій мережі, локальні сегменти якої пов'язані щодо повільними лініями зв'язку. Уявіть собі, що станеться, коли сто осіб, що працюють в окремій будівлі, прийдуть о 8:00 на роботу і, зайшовши в систему, протягом півгодини спробують вивантажити файли з центрального сховища загальним об'ємом 500 Мб через канал 2 Мбіт/с.
Налаштування реплікації серверів БД — справа непроста і під силу лише професійним адміністраторам. Більшість проектних організацій просто немає в своєму розпорядженні такий персонал. На додаток до цього вартість додаткового сервера БД істотно збільшує витрати компанії на придбання та обслуговування програмного забезпечення.
TDMS використовує досить простий, але водночас ефективний спосіб створення підписів на електронному документі. У міру проходження етапів узгодження, а потім і затвердження, документ збирає підписи. Щоб поставити підпис на документ, потрібно ввести додатковий пароль. Будь-яке редагування документа призводить до того, що підписи під документом анулюються.
Сказавши про підписи TDMS, варто згадати про електронний цифровий підпис. З досвіду спілкування з нашими партнерами та клієнтами з'ясувалась чудова річ. Багато хто з них вважає, що механізм підписів, реалізований у TDMS, і є електронний підпис. Боюся їх засмутити, але це не так. Ось що говорить закон: «Електронний цифровий підпис - реквізит електронного документа, призначений для захисту даного електронного документа від підробки, отриманий в результаті криптографічного перетворення інформації з використанням закритого ключа електронного цифрового підпису і що дозволяє ідентифікувати власника сертифіката ключа підпису, а також встановити відсутність в електронному документі». Як бачите, закон дає досить чітке визначення електронного підпису. Понад те, він забороняє використання несертифікованих алгоритмів криптування.
Якщо банки, страхові компанії, деякі державні установи вже почали використовувати електронний підпис під час обміну документами (особливо фінансовими), то на нас це чекає не скоро. Паперові документи ще ніхто не скасовував, і в цех або на будмайданчик передаються ті самі паперові креслення абоїх копії, скріплені звичайними підписами та печатками. В цьому немає нічого страшного. Не треба революції, що все змітає на своєму шляху. Набагато краще, якщо електронні документи замінять паперові природним чином, як паперові архіви поступово замінюються електронними системами керування технічною інформацією. Правове поле вже є. Ще якихось 10-15 років — і майстер цеху носитиме під пахвою не рулон кальки, а графічний планшет.