1.3 Нефункциональные требования - Medical-Information/medical-information-portal GitHub Wiki

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

1.Требования к безопасности клиента

Разработка клиентского ПО должна проводиться в соответствии с рекомендациями по обеспечению безопасности ПО, используя последние обновления версий по поддержанию ПО и токенизацию для обеспечения защиты инфраструктурной среды.

Уязвимая конфиденциальная информация требует контроля при обращении и хранении: Созданные доступы в виде: логина и пароля для внутреннего пользователя должны сохраняться в защищенной части файлового хранилища. Пароль и т.д. должны автоматически сохраняться на устройствах пользователей, только по запросу пользователя.

Следует избегать кэширования конф.данных между сессиями, а в рамках сессии использовать хранилища, располагаемые в оперативной памяти устройства; После отправки пароля на сервер, следует удалять из оперативной памяти хранилища, генерировать смену пароля каждые 3 месяца для пользователя.

2.Требования к совместимости и дизайну

Сайт должен поддерживаться на всех версиях ПО: Macos, Windows XP; Мобильных версий: IOS,Android. Сайт должен работать на устройствах: ● IOS ● Android mobile Сайт должен функционировать в браузерах (от указанной версии и выше) : Google Chrome 55, Internet Explorer 11, Microsoft Edge 41, Yandex 20.3.0.1223, Opera 7 Дизайн сайта должен быть выполнен согласно прототипа и UI-kit. Дизайн сайта должен быть адаптивным.

3. Требования к безопасности сервера и передаче информации между сервером и клиентом

Передача конфиденциальной и чувствительной информации (логина, расширенного пароля) должна производится только в теле http-запроса или cookies для предотвращения случайного логирования на сервере.

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

Передача данных между Сайтом и Сервером производится по протоколу HTTPS c использованием SSL-шифрования трафика SSL-сертификат сервера поддерживаем EV SSl- сертификат с расширенной проверкой, клиент принимает только доверенный сертификат, который обеспечивает безопасность сайта.

После установки этого SSL-сертификата в адресной строке браузера отображается замок, HTTPS, название и страна компании. Отображение информации о владельце веб-сайта в адресной строке помогает отличить сайт от вредоносных.

Чтобы настроить сертификат с расширенной проверкой, владелец веб-сайта должен пройти стандартизированный процесс проверки подлинности и подтвердить, что он на законных основаниях имеет исключительные права на домен/

Дополнительно, клиент проверяет принадлежность SSL-сертификата сервера с помощью SSL Certificate Pinning (процедура проверки Fingerprint сертификата) (см. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning).

Для каждой сессии сервером создается одноразовый токен. При долгом бездействии клиента токен устаревает, и для доступа требуется повторная авторизация в системе. Время бездействия клиента = 24 часа.

4.Требования к релизной документации

Каждая документация по выпуску релиза должна включать информацию о версиях релиза, основных достижениях версий; После разработки продукта необходимо подготовить сопроводительную документацию для пользователя ( инструкцию) о том как работает созданная структура сайта ( основные компоненты и их взаимодействие), как пользоваться админкой сайта/

5. Тестирование

Продукт должен быть протестирован используя мануальное тестирование. Ошибки должны фиксироваться системой мониторинга ошибок