2.2.2 Вопросы безопасности данных
Обеспечение целостности на уровне модели данных приведено в разделе 2.2.1.
Были созданы роли базы данных согласно таблице 2.6. На рисунке 2.22
– рисунке 2.24 представлены фрагменты скрипта для создания ролей Менеджер по бронированию, Гость и Администратор БД. Полный скрипт создания ролей и выдачи им прав представлен в приложении Д.
Рисунок 2.22 – Создание роли «Менеджер по бронированию» и выдача прав
Рисунок 2.23 – Создание роли «Гость» и выдача прав
Рисунок 2.24 – Создание роли «Администратор БД» и выдача прав
Для каждой роли был создан пользователь для проверки выданных ролям прав (рисунок 2.25), для таблиц «Администратор», «Гость» и «Заявка»
27
была включена защита на уровне строк и написаны политики в соответствии с матрицей доступа. Полный скрипт для создания пользователей представлен в приложении Е, скрипт с подключением защиты на уровне строк и созданием новых политик представлен в приложении Ж.
Рисунок 2.25 – Создание пользователей и присваивание им ролей
Политики для роли «Гость» распространяются на таблицы «Администратор», «Гость» и «Заявка». В таблице «Администратор» пользователь может видеть только имя и фамилию сотрудника, с которым он работает или работал (то есть в таблице «Заявка» существует запись в которой есть идентификационный номер текущего пользователя и идентификационный номер администратора) и телефон для обратной связи. На рисунке 2.26 представлен фрагмент реализующий данную политику.
Рисунок 2.26 – Политика для таблицы «Администратор»
28
В таблице «Гость» пользователь видит только свою информацию, в соответствии с выданными правами на просмотр определенных столбцов, на рисунке 2.27 представлен фрагмент, реализующий данную политику.
Рисунок 2.27 – Политика для таблицы «Гость»
В таблице «Заявка» пользователь может видеть только записи, которые имеют в качестве идентификационного номера гостя, подавшего заявку, номер текущего пользователя, в соответствии с выданными правами на просмотр определенных столбцов, на рисунке 2.28 представлен фрагмент реализующий данную политику.
Рисунок 2.28 – Политика для таблицы «Заявка»
Был выполнен вход под учетной записью пользователя «guest1» с
ролью «Гость». На рисунке 2.29 представлен успешный просмотр доступных
29
столбцов в таблице «Администратор», пользователю «guest1» соответствует администратор с третьим идентификационным номером.
Рисунок 2.29 – Просмотр данных таблицы от имени пользователя с ролью «Гость»
На рисунке 2.30 представлено успешное добавление новой записи в таблицу «Заявка». Пользователь может сам заполнить выбранную комнату, количество гостей, дату и время заселения и выселения. Когда с ним свяжется администратор, который будет обрабатывать его заявку, работник сам обновит итоговую цену проживания и привяжет себя к заявке.
Рисунок 2.30 – Добавление новой записи в таблицу «Заявка»
На рисунке 2.31 представлена попытка просмотра данных таблицы «Заселение», так как эта таблица предназначена только для работы сотрудников гостиницы, гость не имеет к ней доступа.
30
Рисунок 2.31 – Попытка просмотра данных таблицы «Заселение»
Был выполнен вход под учетной записью пользователя «ХХХХХХХХХХ» с ролью «Менеджер по бронированию». На рисунке 2.32 представлен успешный просмотр всех столбцов и записей в таблице «Администратор», так как в отличие от гостя менеджер имеет право доступа к информации о своих коллегах.
Рисунок 2.32 – Просмотр данных таблицы от имени пользователя с ролью «Менеджер по бронированию»
На рисунке 2.33 представлено успешное изменение ранее существующей строки в таблице «Заявка», право на изменение строк таблицы дает возможность обрабатывать заявки и отличать рассмотренные от нерассмотренных.
31
Рисунок 2.33 – Изменение записи таблицы от имени пользователя с ролью «Менеджер по бронированию»
На рисунке 2.31 представлена попытка удаления записи из таблицы «Заселение», так как информация о гостях должна обязательно храниться некоторое время в базе, то менеджер не имеет права удалять записи из таблицы.
Рисунок 2.34 – Попытка удаления записи из таблицы «Заявка» от имени пользователя с ролью «Менеджер по бронированию»
32
В разработанной базе данных присутствуют общедоступные (согласно ст. 8 п. 1 Федеральному закону №152-ФЗ «О персональных данных») и иные персональные данные сотрудников и гостей гостиницы.
Так как для системы актуальны угрозы 3-го типа и в ИСПДн обрабатываются иные персональные данные более 100000 субъектов, не являющихся сотрудниками оператора, то для персональных данных устанавливается третий уровень защищенности (согласно п. 11 Постановлению Правительства №1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»).
Для третьего уровня защищенности были реализованы следующие технические меры по обеспечению безопасности персональных данных (согласно приложению к Приказу Федеральной службы по техническому и экспортному контролю №21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»):
•Идентификация и аутентификация пользователей, являющихся работниками оператора;
•Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей);
•Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей, в том числе внешних пользователей;
•Реализация необходимых методов (ролевой метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа;
•Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы;
33
•Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы.
Данные меры были реализованы средствами СУБД Postgres, но стоит
помнить и о реализации остальных мер согласно законодательству.
34