CC BY
78
УДК 004.056.53
В.А. Хованец, П.В. Смолин
Адаптация информационных систем управления университетом требованиям закона о защите персональных данных
Рассматриваются варианты приведения информационных систем управления университетом в соответствии с требованиями закона о защите персональных данных. Анализируются способы управления доступом и способы ограничения доступа, реализуемые специальными алгоритмами на уровне строк данных в базах данных. Приведены результаты тестирования.
Ключевые слова: информационная безопасность, информационные системы управления, защита от несанкционированного доступа.
В соответствии с действующим законодательством в информационных системах, обрабатывающих персональные данные (ПДн), необходимо применять специальные меры по защите этих данных [3]. Такие требования распространяются на значительный объем информации, используемой в разных информационных системах. Не является исключением и информационная система управления учебным процессом (ИСУУП) Морского государственного университета им. адмирала Г.И. Невельского, поддерживающая автоматизацию кадрового учета сотрудников, студентов (курсантов), планирования учебного процесса, контроля успеваемости и других технологических процессов вуза [1].
Сегодня ИСУУП включает в себя десятки приложений, логически разделенных по основному назначению на восемь подсистем. Для связи всех отдельных задач и приложений в единую информационную среду применена стандартная архитектура «клиент-сервер», состоящая из основного SQL-сервера, отвечающего за хранение всех данных ИСУУП, и конечных приложений, установленных на рабочих местах пользователей.
Использование одного SQL-сервера для всех подсистем позволяет избежать дублирования данных, не требует синхронизации (репликации) данных, хранящихся на разных носителях, и дает возможность предоставлять данные приложения в любых требуемых сочетаниях. Несмотря на явные преимущества, эта схема имеет серьезный недостаток. Различные по составу и назначению данные требуют различных уровней и методов защиты от утечки, несанкционированного изменения или удаления. Вместе с тем защита может быть признана достаточной только тогда, когда вся система защищена не хуже, чем это требуется для каждой из составляющих ее частей. Иначе говоря, к общему SQL-серверу и хранящимся на нем данным должны быть предъявлены максимальные требования безопасности по всем подсистемам.
Все требования безопасности можно в общем случае разделить на два типа: предписываемые законодательством и установленные внутри организации. Требования второго типа нужны только для повышения эффективности работы информационной системы и увеличения доверия к обрабатываемым в ней данным со стороны конечных пользователей. Требования первого типа обусловлены наличием тех или иных ограничений и условий в действующем законодательстве. Остановимся на этих требованиях подробнее.
Из анализа следует, что законодательные требования о защите данных в ИСУУП могут применяться только к персональным данным. Вместе с тем, по проведенным оценкам, доля таких данных в ИСУУП не превышает 10%. Основная часть данных либо не являются ПДн, либо относятся к категории общедоступных ПДн, и, следовательно, не подлежит защите по требованиям первого типа.
Поэтому все данные ИСУУП были разделены на две группы: персональные данные, требующие защиты в соответствии с законодательством, и прочие данные. Каждая группа данных защищается отдельно в соответствии с разными требованиями безопасности. Более того, для лучшей защищенности и большей независимости группы данных физически разделяются между двумя серверами: сервером ПДн и сервером общих данных.
В качестве сервера общих данных используется SQL-сервер, к которому подключаются клиентские приложения, установленные на рабочих местах пользователей. Этот сервер несет основную нагрузку, обслуживая основное количество подсистем и конечных пользователей.
Для сервера ПДн в целях повышения безопасности применяются специальные ограничения. Во-первых, устанавливается только сертифицированное программное обеспечение для обработки персональных данных (операционная система, система управления базами данных - СУБД и пр.). Во-вторых, все приложения, обрабатывающие персональные данные, запускаются через механизм терминального доступа непосредственно на сервере. Более того, единственным возможным (инициированным конечным пользователем) подключением к серверу ПДн является подключение терминального доступа. Таким образом, невозможна передача персональных данных с сервера ПДн с использованием SQL, файлов и иными способами, кроме как в визуальном виде в режиме терминального доступа. Иначе говоря, при разрыве связи между сервером ПДн и рабочим местом на последнем не остается персональных данных.
Такая архитектура позволяет сконцентрироваться на защите персональных данных только на стороне одного сервера, ослабив защитные мероприятия на рабочих местах.
Одна из сложностей подхода с использованием терминального доступа - сохранение промежуточных результатов и печать выходных форм. Поскольку файлы и другие данные не могут быть переданы с сервера ПДн на рабочее место оператора, все промежуточные файлы, содержащие персональные данные, хранятся в локальных профилях пользователей на сервере, что повышает их защищенность. Для печати документов на сервере ПДн организуется настройка принтеров конечных пользователей. Это позволяет внедрить централизованный контроль над печатью документов с персональными данными.
Физически оба сервера находятся в одном защищенном серверном помещении. Сервер общих данных стандартным образом подключается к локальной сети университета. Сервер ПДн подключен к локальной сети с ограничениями по портам и протоколам. Кроме того, так как известны конкретные рабочие места операторов персональных данных, дополнительно вводится фильтр внешних подключений к серверу ПДн на уровне сетевых адресов.
Поскольку многие приложения, обрабатывающие персональные данные, для своей работы требуют и других данных хранящихся на общем сервере, оба сервера непосредственно соединены между собой с помощью дополнительного сетевого интерфейса, разрешающего только подключение к общему SQL-серверу со стороны сервера ПДн. Для работающих на сервере ПДн приложений организуется прозрачный доступ ко всем данным двух серверов с использованием механизма связи SQL-серверов. Таким образом, приложение, работая на сервере ПДн и обращаясь с запросами только к нему, может на самом деле получать некоторые данные с общего сервера.
Благодаря синхронной работе серверов и отсутствию дублирования бизнес-данных репликация для них не требуется. Единственная часть, которая реализуется сразу на двух серверах, - это логика и данные подсистемы безопасности. Служебная информация подсистемы безопасности для обоих серверов автоматически формируется на сервере ПДн как более защищенном, а затем часть, относящаяся к общим данным, копируется на сервер общих данных.
Остановимся подробнее на подсистеме безопасности.
Одно из необходимых условий обеспечения безопасности данных на SQL-сервере -разграничение доступа между пользователями. Стандартные средства, встроенные в СУБД, управляют доступом только на определенных уровнях, связанных с сущностями СУБД. В реальных задачах нужно контролировать доступ к наборам данных, отдельным строкам, а иногда и полям таблиц. Такое регулирование полномочий известно как безопасность на уровне строк (row-level security, RLS).
Существует три основных способа реализации RLS: на уровне клиента, на промежуточном уровне (сервере приложений, специальном сервисе) и сервере баз данных [2]. Реализация RLS на уровне клиента проста в разработке и поддержке, но обладает низкой безопасностью. Промежуточные уровни можно применять, если система изначально проектировалась как многоуровневая [3]. В классической архитектуре «клиент-сервер», по которой построена информационная система университета, единственной возможностью реализации RLS является использование средств СУБД.
Поскольку подсистема безопасности создана под использование СУБД Microsoft SQL Server 2008, в которой нет специальной поддержки RLS, была выбрана реализация RLS на реляционной СУБД с помощью представлений и триггеров. К подсистеме были предъявлены требования невысоких трудозатрат при развертывании и высокой производительности операций чтения данных.
В эксплуатируемой в настоящее время базе данных более 500 таблиц, при этом выделено несколько десятков свойств (ролей) пользователей, управляющих доступом к тем или иным данным по достаточно сложным критериям. При таких условиях создание
всех требуемых объектов безопасности (более 1000) вручную без ошибок невозможно. Кроме того, незначительные изменения в полномочиях ролей могут привести к необходимости обновления значительного количества связанных с этими ролями объектов.
Возможен другой способ - автоматическое создание объектов безопасности на основании структуры таблиц и использование в них для проверки полномочий небольшого числа общих функций-предикатов с параметрами (например, имя таблицы и код записи), написанных вручную. Данные предикаты применяются к каждой запрашиваемой для чтения (вставки, изменения, удаления) записи набора данных, проверяя у текущего пользователя возможность выполнения соответствующих действий. Но существенным недостатком такого подхода является заметное снижение производительности при любых операциях.
Третий способ - логическое продолжение второго, при котором в автоматически создаваемые представления и функцию включаются условия проверки безопасности. Подсистема безопасности, таким образом, состоит из двух уровней: общих структур данных, хранящих информацию о защите тех или иных данных, и объектов безопасности, формируемых автоматически на основании этих данных. Таким образом, в этом подходе сочетаются лучшие стороны первых двух способов при отсутствии их характерных недостатков. Именно такая схема RLS была выбрана для информационной системы университета.
Подсистема безопасности состоит из трех основных блоков: модуля управления учетными записями, модуля контроля прав доступа, модуля обработки заявок и формирования действующих разрешений.
Модуль управления учетными записями с заданной частотой актуализирует учетные записи безопасности сотрудников (студентов), включая их в роли в соответствии с занимаемой должностью (учебной программой). Учетные записи пользователей в Active Directory, созданные администраторами доменов, при этом автоматически связываются с соответствующими учетными записями безопасности.
Модуль контроля прав доступа реализует разграничения доступа. В общих чертах работа системы разграничения доступа к данным выглядит следующим образом:
1) Для каждого объекта доступа определяется набор правил доступа для субъектов (матрица доступа).
2) На основе этих правил выделяются общие условия, и составляется схема ролей.
3) С помощью списка ролей создается набор представлений, реализующих проверку выполнения условий для каждого конкретного субъекта, обратившегося к данным, и принимается решение о разрешении или запрете действия субъекта на основе полученных прав и ограничений.
Используются методы, позволяющие SQL-серверу заранее сформировать эффективные планы запросов для доступа ко всем объектам.
Полученный механизм RLS обладает простотой администрирования и поддержки: необходимо только включать или исключать пользователей из групп безопасности или выдавать уже готовые правила доступа. Модификация же самих правил доступа потребуется только при изменении общих требований к системе разграничения прав, что является достаточно редким явлением.
Модуль обработки заявок и формирования действующих разрешений. Значения параметров для всех условий доступа однозначно определяются на основании ролей, в которые входит та или иная учетная запись безопасности, однако их вычисление может быть достаточно медленным из-за иерархичности дерева ролей и необходимости рекурсии. Для повышения производительности системы назначение доступа учетным записям безопасности реализуется через механизм заявок.
Администратор, ответственный за назначение прав пользователей, создает заявку на включение учетной записи безопасности в соответствующую роль, возможно, с указанием срока действия. Процедура обработки заявок, работающая по расписанию, автоматически поддерживает в актуальном состоянии связь между учетными записями безопасности и ролями в соответствии с действующими заявками. При этом автоматически происходит включение в наследованные роли. На основании кадровой информации о сотруднике (студенте) и ролей формируются параметры для подстановки их в условия путем комбинирования разрешений и запретов ролей. Данная информация в совокупности составляет так называемые действующие разрешения учетной записи безопасности в соответствии со всеми разрешениями и запретами.
В заключение перечислим основные идеи, позволившие существенно поднять производительность RLS по сравнению со многими другими аналогами:
1) формирование специальной кэш-таблицы разрешений на основе групп и прав пользователей;
2) включение правил доступа в код представлений и триггеров безопасности;
3) управление доступом на уровне заявок администраторов, на основании которых автоматически формируются и заполняются все необходимые объекты БД и служебные структуры данных.
Были проведены многочисленные тесты реальных сценариев на платформе Microsoft SQL Server, которые показали увеличение производительности предлагаемого решения в 3-5 раз по сравнению с традиционной реализацией RLS, даже когда была применена тщательная настройка базы данных путем анализа планов запросов с добавлением специальных индексов и подсказок.
Разделение единой СУБД на две с разными уровнями защиты и использованием RLS позволяет сохранить практически без изменения технологию работы с большинством подсистем. Пользователи, не работающие с подсистемами с персональными данными, ничего не замечают, поскольку функционирующая в составе ИСУУП подсистема автоматического обновления конечных приложений прозрачно выполняет все действия по адаптации рабочих мест к новым структурам данных.
Каждый пользователь подсистем с персональными данными получает доступ к серверу ПДн, где уже установлены все нужные приложения. Технология дальнейшей работы таких пользователей мало отличается от существовавшей ранее, что важно при адапта-циях информационных систем, находящихся в эксплуатации.
При развитии информационных систем крупных предприятий одной из проблем является повышение категорий персональных данных, обрабатываемых в системах. При предлагаемом подходе изменения в информационных системах, например, при переходе с третьей категории персональных данных на вторую, будут минимальными.
Литература
1. Хованец В.А. Принципы построения распределенной информационной системы управления учебным процессом и производственной деятельностью / В.А. Хованец, Т.С. Чистяков // Информационные технологии в управлении и учебном процессе вуза: матер. 4-й Всерос. очно-заочной науч.-практ. конф. - Владивосток: Изд-во ВГУЭС, 2004. -С. 220-225.
2. Злыгостев А. Row-Level Security в РСУБД // RSDN Magazine: журнал для программистов. - 2004. - № 3 [Электронный ресурс]. - Режим доступа: http://www.rsdn.ru/ article/db/RowLevelSecurity.xml, свободный (дата обращения: 21.05.2010).
3. Крюков В.В. Корпоративная информационная среда вуза: Методология, модели, решения / В.В. Крюков, К.И. Шахгельдян. - Владивосток: Дальнаука, 2007. - 308 с.
4. Зыков В.Д. Защита персональных медицинских данных в автоматизированных медицинских информационных системах лечебно-профилактических учреждений / В.Д. Зыков, К.О. Беляков, Р.В. Мещеряков / Докл. Том. гос. ун-та систем управления и радиоэлектроники. - 2009. - № 1(19). - С. 67-70.
Хованец Виталий Анатольевич
Канд. физ.-мат. наук, доцент, проректор по информационным технологиям Морского государственного университета им. адмирала Г.И. Невельского, г. Владивосток Тел.: (+7 423-2) 30-12-60 Эл. адрес: khovanets@msun.ru
Смолин Павел Владимирович
Начальник отдела разработки программного обеспечения центра информационных технологий Морского государственного университета им. адмирала Г.И. Невельского, г. Владивосток Тел.: (+7 423-2) 30-12-42 Эл. адрес: smolin@msun.ru
V.A. Khovanets, P.V. Smolin
Bringing the management information systems of the university in compliance with the privacy legislation
There were examined different ways of bringing the management information systems of the university in compliance with the privacy legislation. The access control modes and restrictions based on row-level security were analyzed. There were shown the performance test results of data protection methods. Keywords: information security, management information system, protection against unauthorized access.
