Файл: Методика защиты информации в системах электронного документооборота (Выбор программных средств разработки).pdf

Двухэтапную аутентификацию часто называют двухфакторной, не делая особой разницы между понятиями. Двухфакторная аутентификация может быть двухэтапной, но обратное верно не всегда. Граница между этими понятиями очень тонкая, поэтому их часто и не различают.

Двухэтапная аутентификация (Two-Step Verification, 2SV). Вход выполняется в два этапа – например, сначала вы вводите пароль к учетной записи, а потом код из SMS.

Двухфакторная аутентификация (Two Factor Authentication, 2FA). Вход тоже может выполняться в два этапа, но они должны отличаться факторами. Например, сначала вводится пароль, а потом одноразовый пароль, сгенерированный аппаратным токеном. [7]

Проверку пароля, совмещенную с проверкой одноразового кода, присланного на электронную почту нельзя назвать двухфакторной аутентификацией, если почта сама защищена только паролем. Так как такая проверка подтвердит только знание пользователем двух паролей: от приложения/сервиса/сайта и от почты. Другими словами, это однотипные факторы. А двухфакторная аутентификация должна состоять из факторов разных типов. В противопоставление такому примеру - использование смарт карты с обязательным вводом PIN-кода вполне может считаться двухфакторной аутентификацией: первый фактор — владение смарт картой, а второй — знание PIN кода.

Двухэтапная защита не панацея от угона аккаунта, но достаточно надежный барьер, серьезно усложняющий злоумышленникам доступ к чужим данным и в какой-то степени нивелирующий недостатки классической парольной защиты. Ведь у паролей, на которых основано подавляющее большинство авторизационных механизмов в Интернете, есть неизбежные недостатки, которые фактически являются продолжением достоинств: короткие и простые пароли легко запомнить, но также легко подобрать, а длинные и сложные трудно взломать, но и запомнить непросто. По этой причине многие люди используют довольно тривиальные пароли, причем сразу во многих местах. Второй этап в подобных случаях оказывается крайне полезен, поскольку, даже если пароль был скомпрометирован, злоумышленнику придется или раздобыть мобильник жертвы, или угнать ее почтовый ящик.

Этот метод удобен еще и тем, что способен предупреждать хозяина аккаунта о попытке взлома: если на ваш телефон или почту вдруг приходит сообщение с одноразовым кодом при том, что вы никаких попыток логина не предпринимали, значит, вас пытаются взломать – самое время менять оказавшийся ненадежным пароль.

Глава 2. ОБЪЕКТ И МЕТОДЫ ИССЛЕДОВАНИЯ

2.1 Технические требования

Назначение и цели системы

Назначение системы:

Организация личного онлайн кабинета, предназначенного для автоматизации процесса документооборота, как внутри компании ЭлеСи, так и с интеграторами системы SCADA Infinity.

Целями создания системы являются:

- увеличение отклика заказчик-интегратор в плане передачи необходимой информации;
- отслеживание жизненного цикла документов.

Классы пользователей

Доступ к системе должны иметь только авторизованные пользователи, которые разделяются по правам доступа в соответствии с пунктом 2.1.3.3 данного документа.

Требования к системе

Группы требований

В таблице 2.1.1 приведены группы требований разрабатываемой системы.

Таблица 2.1.1 – Группы требований

Символ	Группа требований
F	Функциональные требования
I	Требования к интерфейсу пользователя
AR	Требования к правам доступа
TS	Требования к техническому обеспечению
SR	Требования к программному обеспечению

Функциональные требования

В таблице 2.1.2 приведены функциональные требования разрабатываемой системы.

Таблица 2.1.2 – Функциональные требования

Код требования	Требования	Примечания
F.01	Общие требования
F.01.01	Должна быть реализована двухэтапная авторизация пользователей
F.01.02	Должен быть многопользовательский режим работы
F.01.03	Должно быть реализовано разграничение по правам доступа
F.01.04	Должна быть возможность работать с документами	добавление документа (со своего компьютера в систему); скачивание документа (в выбранный каталог на компьютер из системы).
F.01.05	Должно быть реализовано оповещение о событиях
F.01.06	Должно быть реализованы комментарии
F.02	Требования к документам
F.02.01	Документы должны находиться в карте документа, которая содержит описание документа и комментарии
F.02.02	При создании карты документа пользователем должны формироваться следующие данные: Название; Комментарий; Путь до файла.
F.02.03	При просмотре карты документа, системой должны предоставляться данные: Формат; Ссылка URL; Дата создания карты документа.
F.03	Требования к оповещению о событиях
F.03.01	Должны быть реализованы оповещения по e-mail об изменениях в доступных категориях и картах документов в соответствии с правами доступа
F.03.02	После создания категории или карты документа, всем пользователям, имеющим к ним доступ, должно приходить оповещение на e-mail	Вид оповещения: «В системе «Имя системы» для вас создана новая категория/новая карта документа «Имя категории»/«Имя карты документа»».
F.03.03	После редактирования категории или карты документа, всем пользователям, имеющим к ним доступ, должно приходить оповещение на e-mail	Вид оповещения: «В системе «Имя системы» изменена/изменен категория/карта документа «Имя категории»/«Имя карты документа»».
F.03.04	После создания пользователем нового комментария, всем пользователям, имеющим к нему доступ, должно приходить оповещение на e-mail	Вид оповещения: «В системе «Имя системы» в карте документа «Имя карты документа» новый комментарий».
F.04	Требования к истории карты документа
F.04.01	В истории карты документа должны отображаться сообщения от сервера, которые создаются в случае редактирования карты документа, добавления или скачивания документа	Вид сообщения: ««Имя пользователя» создал/изменил/ска чал документ «Название документа»»
F.05	Требования к комментариям
F.05.01	Комментарии должны быть реализованы в картах документов
F.05.02	Ввод комментариев должен осуществляться в специальной области, после нажатия на кнопку «Отправить» в окне с комментариями должна появиться запись	Вид записи: ««Имя пользователя»: «Текст сообщения»»
F.06	Требования к удалению
F.06.01	Должна быть реализована возможность удаления только карт документов, при наличии соответствующих прав доступа
F.06.02	Физического удаления карт документов не происходит, они должны оставаться в базе и быть доступны администратору

Требования к правам доступа

В таблице 2.1.3 приведены требования к правам доступа разрабатываемой системы.

Таблица 2.1.3 – Требования к правам доступа

Код требования	Требования	Примечания
AR.01	Общие требования
AR.01.01	Доступ к системе должны иметь только внесенные в базу пользователи
AR.01.02	Администратор системы должен обладать полным доступом ко всем функциям системы и управлять правами доступа других пользователей
AR.02	Требования к авторизации
AR.02.01	Должна быть реализована двухэтапная авторизация пользователей
AR.02.02	После успешного ввода пользователем логина и пароля, ему на почту должен прийти сгенерированный системой код доступа
AR.02.03	Код для авторизации должен генерироваться на 5 минут
AR.02.04	При неверном вводе пользователем данных для авторизации три раза, возможность входа должна заблокироваться для данного пользователя на 15 минут
AR.02.05	При неверном вводе пользователем данных для авторизации девять раз, возможность входа должна заблокироваться для данного пользователя на 24 часа
AR.03	Требования к правам доступа к группам пользователей
AR.03.01	Создавать группы пользователей должен иметь право только администратор	Должна быть возможность ввода названия, и выбора прав доступа
AR.03.02	Редактировать группы пользователей должен иметь право только администратор	Должна быть возможность редактирования названия и прав доступа
Код требования	Требования	Примечания
AR.04	Требования к правам доступа к пользователям
AR.04.01	Создавать пользователей должен иметь право только администратор	Должна быть возможность ввода полей: Имя; E-mail; Пароль. Должна быть возможность выбора: Группа пользователей.
AR.04.02	Редактировать пользователей должен иметь право только администратор
AR.04.03	Пользователи должны иметь доступ к редактированию только своего пароля
AR.05	Требования к правам доступа к категориям
AR.05.01	Должна быть реализовано правило доступа создания категорий	Должна быть возможность ввода полей: Название; Комментарий. Должна быть возможность выбора: Группы пользователей, которые имеют доступ
AR.05.02	Должно быть реализовано правило доступа редактирования всех доступных категорий
AR.05.03	Должно быть реализовано правило доступа редактирования только своих, созданных, категорий
AR.06	Требования к правам доступа к документам
AR.06.01	Должна быть реализовано правило доступа создания карт документов	Должна быть возможность ввода полей: Название; Комментарий. Должна быть возможность загрузки документа
Код требования	Требования	Примечания
AR.06.02	Должно быть реализовано правило доступа редактирования всех доступных карт документов
AR.06.03	Должно быть реализовано правило доступа редактирования только своих, созданных, карт документов
AR.06.04	Должно быть реализовано правило доступа скачивания всех доступных документов
AR.06.05	Должно быть реализовано правило доступа скачивания только своих, созданных, документов
AR.06.06	Должно быть реализовано правило доступа удаления только своих, созданных, карт документов
AR.07	Требования к правам доступа к истории документов
AR.07.01	Администратору должна быть доступна история всех документов
AR.07.02	Пользователям может быть доступна история только своих документов	Информация: Имя пользователя; Операция; Название документа; Дата.
AR.08	Требования к правам доступа к комментариям к карте документа
AR.08.01	Должно быть реализовано правило доступа отправки комментариев
AR.08.02	Должно быть реализовано правило доступа только просмотра комментариев

2.2 Требования к интерфейсу пользователя

В таблице 2.1.4 приведены требования к интерфейсу разрабатываемой системы.

Таблица 2.1.4 – Требования к интерфейсу

Код требования	Требования	Примечания
I.01	Общие требования
I.01.01	Язык интерфейса системы – русский
I.01.02	Не должно быть кнопок без имени или не помеченных специальной иконкой
Код требования	Требования	Примечания
I.01.03	Категории и карты документов должны быть представлены в виде дерева структуры, вложенность категорий в котором не ограничена
I.02	Требования к интерфейсам
I.02.01	Интерфейс начальной страницы должен выглядеть согласно рисунку Б.1 в приложении Б Требования к интерфейсу пользователя	Пользователь должен ввести свой логин и пароль и нажать кнопку «Войти»
I.02.02	Интерфейс страницы ввода кода должен выглядеть согласно рисунку Б.2 в приложении Б Требования к интерфейсу пользователя	Пользователь должен ввести код, который пришел ему на почту и нажать кнопку «Войти»
I.02.03	Окно с ошибками должно выглядеть согласно рисунку Б.3 в приложении Б Требования к интерфейсу пользователя
I.02.04	Окно с сообщением о неработоспособности кода должно выглядеть согласно рисунку Б.4 в приложении Б Требования к интерфейсу пользователя
I.02.05	Интерфейс меню пользователя должен выглядеть согласно рисунку Б.5 в приложении Б Требования к интерфейсу пользователя
I.02.06	Интерфейс страницы смены пароля должен выглядеть согласно рисунку Б.6 в приложении Б Требования к интерфейсу пользователя
I.02.07	Интерфейс страницы просмотра категории должен выглядеть согласно рисунку Б.7 в приложении Б Требования к интерфейсу пользователя
I.02.08	Интерфейс страницы просмотра карты документа должен выглядеть согласно рисунку Б.8 в приложении Б Требования к интерфейсу пользователя
I.02.9	Интерфейс страницы создания категории должен выглядеть согласно рисунку Б.9 в приложении Б Требования к интерфейсу пользователя
I.02.10	Интерфейс страницы создания карты документа должен выглядеть согласно рисунку Б.10 в приложении Б Требования к интерфейсу пользователя	Для прикрепления документа необходимо нажать кнопку «Выберите файл», выбрать нужный файл и нажать кнопку «Открыть»
Код требования	Требования	Примечания
I.02.11	Интерфейс страницы редактирования категории должен выглядеть согласно рисунку Б.11 в приложении Б Требования к интерфейсу пользователя
I.02.12	Интерфейс страницы редактирования карты документа должен выглядеть согласно рисунку Б.12 в приложении Б Требования к интерфейсу пользователя

Требования к техническому обеспечению

В таблице 2.1.5 приведены требования к техническому обеспечению разрабатываемой системы.

Таблица 2.1.5 – Требования к техническому обеспечению

Код требования

Требования

Примечания

TS.01

Требования к серверной части:

Windows Server 2012 R2;
частота процессора – от 2 ГГц;
объем оперативной памяти – от 8 Гбайт;
PostgreSQL, версия 10.1 и выше;
Python, версия 3.6.4 и выше;
объем свободного дискового пространства на системном диске 1 Тбайт.

2.3 Требования к программному обеспечению

В таблице 2.1.6 приведены требования к программному обеспечению разрабатываемой системы.

Таблица 2.1.6 – Требования к программному обеспечению

Код требования	Требования	Примечания
SR.01	Требования к клиентской части
SR.01.01	Должна функционировать под управлением следующих ОС: Windows версии не ниже 7; Linux с версией ядра не ниже 3.2; Android версии не ниже 4.4; Mac OS; Apple iOS версии не ниже 8.х.
SR.01.02	Не должна требовать дополнительных программных установок на стороне клиента
Код требования	Требования	Примечания
SR.01.03	Должна функционировать в следующих браузерах с версиями не ниже указанных: Safari, версия 11 и выше; Google Chrome, версия 62 и выше; Internet Explorer, версия 11 и выше; Microsoft Edge, версия 40 и выше; Mozilla Firefox, версия 57 и выше; Opera, версия 49 и выше; iOS Safari, версия 8.4 и выше; Android Browser, версия 4.4 и выше
SR.02	Требования к серверной части
SR.02.01	Должна функционировать под управлением ОС Windows версии не ниже 7, на веб-сервере Internet Information Services версия 10 и выше, с установлением защищенного соединения по протоколу HTTPS