Файл: Методика защиты информации в системах электронного документооборота (Выбор программных средств разработки).pdf
Добавлен: 25.04.2023
Просмотров: 148
Скачиваний: 2
Двухэтапную аутентификацию часто называют двухфакторной, не делая особой разницы между понятиями. Двухфакторная аутентификация может быть двухэтапной, но обратное верно не всегда. Граница между этими понятиями очень тонкая, поэтому их часто и не различают.
Двухэтапная аутентификация (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 |
При просмотре карты документа, системой должны предоставляться данные:
|
|
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 |
Требования к серверной части:
|
2.3 Требования к программному обеспечению
В таблице 2.1.6 приведены требования к программному обеспечению разрабатываемой системы.
Таблица 2.1.6 – Требования к программному обеспечению
Код требования |
Требования |
Примечания |
SR.01 |
Требования к клиентской части |
|
SR.01.01 |
Должна функционировать под управлением следующих ОС:
|
|
SR.01.02 |
Не должна требовать дополнительных программных установок на стороне клиента |
|
Код требования |
Требования |
Примечания |
SR.01.03 |
Должна функционировать в следующих браузерах с версиями не ниже указанных:
|
|
SR.02 |
Требования к серверной части |
|
SR.02.01 |
Должна функционировать под управлением ОС Windows версии не ниже 7, на веб-сервере Internet Information Services версия 10 и выше, с установлением защищенного соединения по протоколу HTTPS |