Защита и управление данными в TDMS
Мониторинг действий пользователей
Принимая решение о создании собственной системы управления техническими данными, руководство нашей компании ясно понимало, что мы отнюдь не первые, кто взялся за решение подобной задачи.
Продавая чужие системы и анализируя представленные на рынке отечественные и западные программные продукты, предназначенные для коллективной работы с технической информацией, мы пришли к неутешительному выводу: помимо того что эти системы имели устаревшую архитектуру, запутанные интерфейсы и настройки, а также явно завышенные цены, многие из них элементарно не обеспечивали необходимого уровня безопасности хранения и управления данными. Здесь, конечно, речь идет не об общепризнанных мировых лидерах на рынке PDM/PLM — в этих системах, как правило, все в порядке и с функциональными возможностями, и с безопасностью; однако по причине высокой цены продукта и еще большей стоимости внедрения подобные системы недоступны большинству российских предприятий. Явные проблемы с безопасностью обнаружились у систем среднего класса, к которым относятся все российские продукты и десятки аналогичных западных разработок.
Технические специалисты вряд ли найдут в данной статье что-либо новое — мы расскажем об основных принципах, на которых строится система защиты и управления данными в TDMS. Следует отметить, что на российском рынке очень трудно найти систему, в которой учтены все столь очевидные требования к построению систем коллективного доступа с целью обеспечения необходимого уровня безопасности.
Выбор СУБД
Первое, на что мы обратили внимание, — это выбор системы управления базами данных (СУБД). Выбор производился по целому ряду критериев: распространенность, удобство работы, масштабируемость и т.д. Одним из определяющих факторов стало обеспечение необходимого уровня безопасности и бесперебойной работы. Многие поставщики сетевого ПО любят рассказывать о многоплатформенности, гибкости и т.п. На деле же зачастую оказывается, что некоторая часть предлагаемых ими СУБД не может соответствовать требованиям безопасности, а гибкость решения, поддерживающего большое количество платформ, достигается за счет упрощения серверной части ПО и игнорирования рекомендаций по защите данных; как следствие, такая СУБД не может использоваться в системах коллективного доступа. Изучая платформы СУБД, мы руководствовались принципом «лучше меньше, да лучше». Выбор для российского рынка был достаточно очевиден: Microsoft SQL Server 2000 и Oracle 9i. Другим возможным вариантом была DB2, но эта система почти неизвестна в России, и потому уже на начальном этапе развития TDMS решено было не тратить ресурсы компании на поддержку еще одной платформы.
И SQL Server, и Oracle имеют сертификаты безопасности уровня C21 . Обе системы надежны и обеспечивают круглосуточную бесперебойную работу без вмешательства администратора. Обе имеют многоуровневые системы защиты данных, встроенные средства резервного копирования и мониторинга. SQL Server, пожалуй, самая легкая и удобная в администрировании СУБД, одинаково хорошо работающая с любыми объемами данных. Oracle же, помимо C2, имеет еще более десяти различных сертификатов безопасности и является стандартом де-факто для создания информационных систем масштаба предприятия. Не случайно большинство российских и западных предприятий использует именно SQL Server и Oracle.
 |
|
Защита БД
Для подключения к серверу БД TDMS использует классическую трехуровневую систему аутентификации. Подключаясь к серверу с прошитой учетной записью, пользователь проходит только первый уровень защиты. Подключившись, он получает право запустить процедуру проверки имени и пароля пользователя, а также пароля учетной записи приложения. В базе данных хранятся не сами пароли, а только их цифровые образы, полученные после обработки паролей специальной хэш-функцией. Такой способ аутентификации позволяет избежать двойного ввода пароля, сохраняя при этом необходимый уровень безопасности.
Стоит отметить, что учетная запись приложения работает не напрямую с таблицами базы данных, а через хранимые процедуры, обеспечивая соответствие между правами доступа пользователя и разрешенными ему операциями над данными.
Если бы мы обеспечили защиту на стороне сервера БД, но не позаботились о необходимом уровне организации коллективного труда в электронной системе, то предоставили бы недобросовестному пользователю полную свободу действий, от последствия которой страдают проектные и конструкторские организации, осуществившие массовую компьютеризацию и превратившие свои проекты в файловую свалку.
|
|
Права доступа
Система TDMS предназначена для коллективной работы с техническими данными и имеет в системе управления правами доступа ряд особенностей, которые отличают ее от «плоских» электронных архивов. К таким особенностям можно отнести возможность назначения прав доступа на каждый объект системы, наследование прав и иерархическую модель администрирования.
Возможность назначения прав на каждый объект означает, что для любого информационного объекта можно определить пользователей или группы пользователей, имеющих определенные права доступа к этому объекту. TDMS обладает гибкими настройками, позволяющими назначать права доступа вплоть до видимости объекта в системе. Для управления правами доступа у каждого объекта TDMS есть администратор; при этом администраторы TDMS образуют иерархию.
Иерархическая модель управления правами доступа отражает реальную жизнь. Любое предприятие имеет руководителя (директора), имеющего практически неограниченную власть. Другие работники, например начальники подразделений, находятся в его подчинении. У тех, в свою очередь, в подчинении находятся начальники отделов и т.д. Именно такой принцип администрирования используется и в TDMS. Главный системный администратор имеет в подчинении группу администраторов рангом ниже и может передать им право управления доступом к объектам. Каждому из подчиненных администраторов могут подчиняться другие администраторы и т.д. Члены административной группы на своих уровнях распределяют права доступа пользователей к объектам. Администратор более высокого уровня может не только изменять права доступа к объекту, установленные подчиненным ему членом административной группы, но и заменять подчиненного администратора любым другим.
Основой модели представления и отображения информации в TDMS служит древовидная структура. Объекты структурированы по иерархическому принципу; вложенность объектов подчинена заданным при настройке системы правилам вхождения объектов друг в друга. Наследование прав доступа существенно упрощает администрирование системы, построенной по иерархическому принципу. Администратору достаточно лишь один раз определить основной набор прав доступа (как правило, на просмотр), и наследуемые права будут автоматически переноситься на все вновь создаваемые объекты.
Любая система документооборота обладает возможностью отслеживать стадии работы с объектом (документом). На разных этапах жизненного цикла проекта, изделия или отдельного документа пользователи имеют различные ограничения прав доступа к этим объектам. Но как система, предназначенная для работы с техническими данными, TDMS наделена дополнительными функциями по работе с иерархической структурой. Например, без всякого программирования можно задать условия, которые не позволят утвердить документ, если он содержит неутвержденные листы, или утвердить сборочную единицу, в составе которой есть неутвержденные детали.
Такой подход позволяет согласованно вести коллективную разработку проектов, структурированно хранить архивную информацию, строго определив границы прав доступа каждого пользователя по отношению к тому или иному объекту системы.
|
|
Мониторинг действий пользователей
TDMS позволяет фиксировать практически все действия пользователей, касающиеся их работы в системе: создание, просмотр, редактирование, удаление объектов, выполнение запросов, создание версий и т.д. Накапливаемую информацию можно группировать для дальнейшего изучения не только по пользователям или документам, но и по любым другим критериям. Одним словом, в руках системного администратора и службы безопасности находится поистине незаменимый инструмент.
Функции мониторинга могут пригодиться не только для пресечения действий «инсайдеров» и выявления непреднамеренных вредителей — благодаря информации, полученной в результате мониторинга, добросовестный администратор способен оптимизировать некоторые действия пользователей. Если несколько пользователей ежедневно совершают несколько последовательных однотипных операций, администратор может их автоматизировать.
Не стоит забывать и о мониторинге средствами СУБД. Например, аудит уровня C2 Microsoft SQL Server поможет администратору уже на ранней стадии зафиксировать попытки несанкционированного доступа.
|
|
История разработки объекта
История разработки объекта не входит в систему безопасности, но, отражая всю информацию об объекте проектирования, связанных с ним почтовых сообщениях, его версиях, этапах и т.д., история разработки позволяет администратору объекта либо другому уполномоченному лицу быстро определить, почему и на каком основании были приняты те или иные решения и были ли выполнены все необходимые требования, касающиеся правил разработки технической документации.
|
|
Внутренняя почта
Встроенный почтовый модуль является защищенным средством для передачи различных системных сообщений, таких как уведомления о начале или окончании разработки, сообщения о назначении пользователя на выполнение определенных работ, различного рода директивы. Почта также используется для передачи сообщений от одного пользователя другому в результате маршрутизации документов. TDMS не передает по почте тела документов — в этом нет необходимости, поскольку в почтовом сообщении содержится ссылка на версию документа, что позволяет в любое время одновременно увидеть состояние документа на момент передачи и текущее состояние. Пользователь не имеет возможности удалять ни системное сообщение, ни сообщение, созданное в результате маршрутизации. Открыв TDMS, пользователь обязан открыть пришедшую к нему почту, что практически исключает возможность «саботажа» и элементы рассеянности.
|
|
Защита файлов
На первый взгляд ответить на вопросы о том, где и как хранить файлы, не слишком сложно. Обе используемые с TDMS СУБД позволяют достаточно эффективно хранить большие бинарные объекты. Размещая файлы непосредственно в СУБД, мы убиваем сразу трех зайцев: обеспечиваем максимальный уровень безопасности данных, осуществляем резервное копирование всех данных сразу и получаем возможность использовать встроенный в СУБД полнотекстовый поиск.
Казалось бы, можно поставить точку. Но серверы БД — не файловая система, поэтому, как бы мы ни старались, они не будут работать с файлами быстрее, чем операционная система. Падение производительности становится особенно заметным при работе с большими файлами. Еще один недостаток хранения файлов в СУБД проявляется в случае, когда организация работает в распределенной сети, локальные сегменты которой соединены относительно медленными линиями связи. Представьте себе, что произойдет, если сто человек, работающих в отдельном здании, придя в 8.00 на работу, зайдут в систему и в течение получаса попытаются выгрузить из центрального хранилища файлы общим объемом 500 Мбайт через канал 2 Мбит/с!
Настройка репликации серверов БД — дело непростое и под силу только профессиональным администраторам, и большинство проектных организаций не располагает таким персоналом. Вдобавок к этому стоимость дополнительного сервера БД существенно увеличивает расходы компании на приобретение и обслуживание программного обеспечения.
Для более эффективного использования ресурсов проектных организаций в качестве дополнения к серверу TDMS был разработан файловый сервер TDMS — опциональное приложение, запускаемое на любом локальном или удаленном компьютере и позволяющее эффективно управлять файлами, размещенными на практически неограниченном количестве устройств хранения. Файловые серверы TDMS, которых может быть сколько угодно, позволяют автоматически архивировать информацию, осуществлять резервное копирование, оптимизировать хранение файлов, учитывая скорость работы устройств хранения и частоту обращения к файлам. Кроме того, файловые серверы TDMS могут привязываться к подразделениям предприятия, что позволяет размещать файлы непосредственно в том сегменте сети, где они чаще всего используются.
Для обычного пользователя файловый сервер является «черным ящиком»: чтобы извлечь требуемый файл, клиентское приложение отправляет запрос на сервер БД, где происходит проверка прав на просмотр файла. Если такое право имеется, служба файлового сервера получает «добро» на передачу защищенного пакета данных на рабочее место пользователя. Обновление данных на файловом сервере происходит по аналогичному сценарию: данные помещаются на файловый сервер только после подтверждения прав пользователя на редактирование файла. Подобная схема позволяет создавать распределенные хранилища данных, не опираясь на политики безопасности отдельно взятой файловой системы.
Но и это еще не всё. Многие службы безопасности с опаской относятся к тому, что файлы при просмотре могут попасть на диск пользователя. Где бы ни находился файл, его открытие стандартными средствами редактирования, такими как Microsoft Word или AutoCAD, даст пользователю возможность сохранить его на локальном диске. И хотя правильно настроенные права доступа не позволят рядовому пользователю скопировать проект целиком, злоумышленником может стать и пользователь с большими полномочиями, например администратор TDMS. Чтобы решить эту проблему, TDMS предлагает дополнительную технологию, позволяющую передавать не сам файл, а отображение его содержимого. Специальный сервис на сервере создает изображение, которое передается пользователю, и тот работает с полученным с сервера изображением так же, как со стандартным средством просмотра. Сервис обладает возможностью корректно отображать все основные форматы файлов: Microsoft Office, DWG, DXF, растровые форматы. Дополнительно поставляются специализированные форматы файлов.
|
|
Подписи
TDMS использует довольно простой, но в то же время эффективный способ создания подписей на электронном документе. По мере прохождения этапов согласования и утверждения документ собирает соответствующие подписи. Чтобы поставить подпись на документе, требуется ввести дополнительный пароль, причем любое редактирование документа влечет за собой аннулирование всех подписей под документом.
Говоря о подписях TDMS, стоит упомянуть об электронной цифровой подписи. Многие из наших партнеров и клиентов считают, что механизм подписей, реализованный в TDMS, и есть электронная подпись, но это не так. Вот что гласит законодательство: «Электронная цифровая подпись — реквизит электронного документа, предназначенный для защиты данного электронного документа от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе» . Как видите, закон дает достаточно четкое определение электронной подписи. Более того, он запрещает использование несертифицированных алгоритмов криптования.
Если банки, страховые компании и некоторые государственные учреждения уже начали использовать электронную подпись при обмене документами (в особенности финансовыми), то остальных это ждет не скоро. Бумажные документы еще никто не отменял, и в цех или на стройплощадку передаются всё те же бумажные чертежи или их копии, скрепленные обычными подписями и печатями. В этом нет ничего страшного: не надо революции, сметающей всё на своем пути, — гораздо лучше, если электронные документы заменят бумажные естественным образом, как, например, на смену бумажным архивам постепенно приходят электронные системы управления технической информацией. Правовое поле уже есть, и еще каких-нибудь 10-15 лет мастер цеха будет носить под мышкой не рулон кальки, а графический планшет.
|
|
