Модель приложения Функциональныетребования
Актерами приложения являются:
Клиент банка
Аудитор
Администратор системы
Для начала работы с интернет-банкингом каждый клиент обязан активировать услугу. После этого он получает доступ к остальному функционалу: переводу денег на другие счета, просмотру информации о счете. Если же он не видит больше необходимости в использовании системы, он может деактивировать услугу.
Зачастую с интернет-банкингом связано такое понятие, как «Расследование инцидентов», для этого аудитору необходимо иметь доступ к журналу действий.
Администратор имеет возможность конфигурировать приложение и управлять ролями пользователей
Рис.3. Функциональные требования
Архитектура
Данное приложение имеет MVCархитектуру:
Рис.4. Архитектура приложения
Уровень Views – уровень, на котором пользователи взаимодействуют с приложением. Уровень представления содержит общий код интерфейса пользователя, отделенный код (код, содержащийся в отдельном файле, что позволяет отделить разметку от поведения, которое реализовано в коде) и конструкторов, используемых для представления информации пользователю.
Controllers работает как мост между уровнем Models и уровнем View. Все данные проходят через него перед их передачей уровню представления
Все составляющие сайта находятся во взаимодействии. Для обеспечения безопасного взаимодействия должна служить авторизация, которая ограничивает доступ к страницам, в зависимости от роли.
Рис.5. Controller
Контроллеры логически разбивают систему на составляющие:
AccountController – отвечает за функционал аутентификации.
AdminController – отвечает за функционал администрирования.
AuditController – отвечает за функционал аудита.
HomeController – отвечает за функционал предоставляемый клиенту банка.
Рис.6. Model
Membership – класс .NET Framework, позволяющий работать с пользователями.
User – класс используется для описания функционала любого актера системы.
Client – класс используется для описания функционала клиента банка.
Auditor - класс используется для описания функционала аудитора системы.
Administrator – класс используется для описания функционала администратора системы.
Bill – класс используется для операций со счетами.
Configuration – класс используется для операций с конфигурацией.
Модель процесса подключения услуги
Рис.7. Модель процесса подключения услуги
Общие сведения о процессе разработки безопасного по Краткое описание процесса разработки безопасного по.
Процесс разработки безопасного ПО направлен на гарантирование безопасности разрабатываемых с его применением приложений.
Процесс разработки безопасного ПО является расширением стандартного процесса разработки ПО.
Процесс разработки безопасного ПО применяется на основании решения по необходимости обеспечения безопасности разрабатываемого приложения.
Цели процесса разработки безопасного по
Основные цели, которые ставятся перед данной реализацией процесса разработки безопасного ПО:
устранение уязвимостей в коде разрабатываемых приложений, критичных с точки зрения информационной безопасности;
формирование осознания важности вопросов безопасности у всех участников процесса разработки;
создание бизнес процесса по оценке рисков приложений и по дальнейшему принятию решений о минимизации этих рисков;
создание базиса для гарантирования заказчику определенного уровня безопасности разрабатываемых приложений, в том числе, использование процесса и для дальнейшего прохождения сертификаций продуктов.
Схема процесса разработки безопасного ПО
Рис.8.
Схема процесса разработки безопасного
ПО.
Как и при обычной разработке, основа – это процесс разработки, результат которого это некоторое разработанное приложение. Процесс разработки безопасного ПО дополняет стандартный процесс разработки для гарантирования информационной безопасности разрабатываемого приложения. Тем самым процесс разработки безопасного ПО вносит дополнительные требования при разработке для достижения определенного уровня безопасности и конфиденциальности разрабатываемого приложения.