АНАЛИЗ РИСКОВ И АРХИТЕКТУРНЫЕ КОНТРМЕРЫ ПРИ РАЗРАБОТКЕ ПЛАТФОРМЫ ДЛЯ УДАЛЕННОГО ЭЛЕКТРОННОГО ГОЛОСОВАНИЯ
Журнал: Научный журнал «Студенческий форум» выпуск №39(348)
Рубрика: Технические науки
Научный журнал «Студенческий форум» выпуск №39(348)
АНАЛИЗ РИСКОВ И АРХИТЕКТУРНЫЕ КОНТРМЕРЫ ПРИ РАЗРАБОТКЕ ПЛАТФОРМЫ ДЛЯ УДАЛЕННОГО ЭЛЕКТРОННОГО ГОЛОСОВАНИЯ
RISK ANALYSIS AND ARCHITECTURAL COUNTERMEASURES IN THE DEVELOPMENT OF A REMOTE ELECTRONIC VOTING PLATFORM
Kats Stanislav Dmitrievich
Student, Technological Institute (branch), Don State Technical University in Azov, Russia, Azov
Stetyukha Alexander Dmitrievich
Student, Technological Institute (branch), Don State Technical University in Azov, Russia, Azov
Аннотация. В статье рассматривается актуальная проблема обеспечения безопасности при разработке систем удаленного электронного голосования (УЭГ). Цель работы - предложить архитектурные решения и контрмеры для защиты платформы УЭГ от основных киберугроз. В качестве ответа предложена многоуровневая архитектура веб-приложения, включающая строгую аутентификацию по электронной почте и одноразовым паролям (OTP), обязательное использование протокола HTTPS, механизмы защиты от SQL-инъекций и межсайтовой подделки запросов (CSRF). Разработан прототип на базе стека технологий Python/Django и PostgreSQL.
Abstract. The article discusses the current problem of ensuring security in the development of remote electronic voting (UEG) systems. The aim of the work is to propose architectural solutions and countermeasures to protect the UEG platform from major cyber threats. As an answer, a multi-level architecture of the web application is proposed, including strict e-mail and one-time password authentication (OTP), mandatory use of HTTPS protocol, protection mechanisms against SQL injection and cross-site query forgery (CSRF). A prototype based on the Python/Django and PostgreSQL technology stack has been developed.
Ключевые слова: удаленное электронное голосование; кибербезопасность; анализ угроз; архитектура информационной системы; веб-приложение; аутентификация; защита данных; Django; SQL-инъекция; CSRF.
Keywords: remote electronic voting; cybersecurity; threat analysis; information system architecture; web application; authentication; data protection; Django; SQL injection; CSRF.
Введение:
Цифровая трансформация современных социокультурных и административных практик закономерно затрагивает сферу избирательных процессов. Удаленное электронное голосование (УЭГ) перестало быть теоретической концепцией, превратившись в инструмент, востребованный в условиях роста мобильности населения, пандемических ограничений и общей тенденции к цифровизации государственных и корпоративных услуг. Международный опыт пилотных проектов в Эстонии, Швейцарии, ряде штатов США подтверждает потенциальную эффективность УЭГ для повышения вовлеченности граждан и снижения организационных издержек.
Однако повсеместному внедрению таких систем препятствует комплекс серьезных технологических и доверительных вызовов. В отличие от коммерческих онлайн-транзакций, процесс голосования предъявляет уникальный набор противоречивых требований: необходимо одновременно гарантировать аутентичность голосующего, неизменность поданного голоса, тайну волеизъявления и доступность системы для всех участников. Нарушение любого из этих принципов ставит под сомнение легитимность всего процесса. Таким образом, безопасность становится не просто дополнительной опцией, а краеугольным камнем любой платформы УЭГ.
Основная проблема, исследуемая в статье, заключается в значительном разрыве между пониманием важности безопасности на концептуальном уровне и ее практической, глубоко интегрированной реализацией в конкретных программных решениях, особенно создаваемых для внутрикорпоративного или учебного применения. Зачастую разработка фокусируется на функциональных требованиях в ущерб анализу угроз, что приводит к появлению систем с критическими уязвимостями.
1. Анализ угроз безопасности в системах удаленного голосования
Безопасность информационной системы не может быть обеспечена без четкого понимания того, от каких именно угроз она должна быть защищена. Для систем удаленного электронного голосования данный этап критически важен, так как позволяет перейти от абстрактного «необходимо обеспечить безопасность» к конкретным инженерным решениям. В данном исследовании применялся упрощенный подход к моделированию угроз (Threat Modeling), фокусирующийся на активах системы, потенциальных злоумышленниках и их возможных атаках.
1.1. Ключевые активы и требования безопасности
Основными активами платформы УЭГ, подлежащими защите, являются:
- Учетные данные пользователя, они же логин, пароль, привязанная почта: Требуется конфиденциальность и защита от утечки.
- Факт и содержание поданного голоса: Требуется целостность и конфиденциальность.
- Итоговые результаты голосования: Требуется целостность и доступность для авторизованных лиц.
- Системные журналы: Требуется целостность для обеспечения подотчетности и расследования инцидентов.
1.2. Модель злоумышленника
В контексте платформы УЭГ можно выделить несколько типов потенциальных нарушителей:
- Внешний анонимный злоумышленник: Мотивирован нанести ущерб репутации системы или сорвать голосование (к примеру, DDoS-атака).
- Зарегистрированный пользователь-нарушитель: Стремится проголосовать многократно, изменить свой или чужой голос, нарушить тайну голосования другого участника.
- Внутренний нарушитель (администратор): Обладает расширенным доступом к системе и может пытаться манипулировать результатами или извлекать конфиденциальные данные. Данная модель считается одной из наиболее опасных.
- Пассивный наблюдатель (например, злоумышленник в сети): Стремится перехватить передаваемые данные.
1.3. Классификация и анализ ключевых угроз
На основе модели активов и злоумышленников угрозы можно классифицировать по точкам приложения.
Таблица 1.
Матрица угроз безопасности для платформы УЭГ
|
Категория угрозы |
Конкретная угроза |
Возможный вектор атаки |
Последствия |
|
Угрозы аутентификации и авторизации |
Несанкционированный доступ под видом легитимного пользователя |
Подбор слабых паролей, использование утекших учетных данных, перехват сессии. |
Фальсификация голоса, нарушение принципа «один человек - один голос». |
|
Создание фальшивых учетных записей |
Отсутствие строгой верификации при регистрации. |
Искажение электоральной картины, манипуляция результатами. |
|
|
Угрозы целостности данных |
Изменение голоса при передаче или хранении |
Man-in-the-Middle (MITM) атака, внедрение в базу данных. |
Недоверие к результатам, подрыв легитимности голосования. |
|
Фальсификация итоговых результатов |
Прямой доступ к базе данных или уязвимости в логике подсчета. |
Катастрофическая потеря доверия ко всей системе. |
|
|
Угрозы конфиденциальности |
Нарушение тайны голосования |
Связывание идентификатора пользователя с его голосом в БД. |
Возможность шантажа, давление на избирателей. |
|
Утечка персональных данных пользователей |
Уязвимости в коде (SQL-инъекция), некорректные настройки доступа. |
Нарушение законодательства (152-ФЗ), репутационные потери. |
|
|
Угрозы доступности |
Отказ в обслуживании (DoS/DDoS) |
Направленная перегрузка сервера запросами. |
Срыв голосования, потеря доверия к организаторам. |
|
Угрозы на уровне приложения |
Межсайтовый скриптинг (XSS) |
Внедрение вредоносного кода в страницы голосования. |
Кража сессий пользователей, перенаправление на фишинговые страницы. |
|
Межсайтовая подделка запроса (CSRF) |
Принуждение авторизованного пользователя к нежелательным действиям. |
Несанкционированное голосование от имени пользователя. |
|
|
SQL-инъекция |
Внедрение произвольного SQL-кода через поля ввода. |
Кража, изменение или удаление данных из БД. |
1.4. Выводы по разделу анализа угроз
Проведенный анализ демонстрирует, что платформа УЭГ подвержена широкому спектру угроз, затрагивающих все классические свойства информационной безопасности: конфиденциальность, целостность, доступность. Наиболее критичными для данного класса систем являются угрозы, ведущие к фальсификации результатов и нарушению принципа однократности голосования. Следующий раздел работы посвящен описанию архитектурных и программных контрмер, спроектированных для нейтрализации каждой из выявленных ключевых угроз.
2. Архитектура платформы и реализованные контрмеры
На основе проведенного анализа угроз спроектирована многоуровневая архитектура веб-приложения, в которой меры безопасности являются неотъемлемой частью каждого компонента, а не отдельным дополнением. Архитектура следует классической схеме «клиент-сервер» с четким разделением ответственности.
2.1. Общая архитектура системы
Система построена по трехуровневой модели:
- Уровень представления (Frontend): Статический клиент, реализованный на HTML, CSS и JavaScript. Его основная задача - предоставление пользовательского интерфейса для регистрации, аутентификации и голосования. Вся бизнес-логика и проверки вынесены на уровень приложения.
- Уровень приложения (Backend): Ядро системы, реализованное на фреймворке Python/Django. Выполняет обработку запросов, обеспечивает бизнес-логику, управляет сессиями и взаимодействует с базой данных. На этом уровне сосредоточены основные механизмы безопасности.
- Уровень данных (Database): Реляционная база данных PostgreSQL, отвечающая за надежное и структурированное хранение информации. Используются встроенные механизмы резервного копирования и управления доступом.
Все взаимодействие между клиентом и сервером осуществляется исключительно по защищенному протоколу HTTPS (TLS 1.2/1.3).
2.2. Детализация ключевых контрмер
Для каждой категории угроз, описанной в разделе 1, были реализованы соответствующие защитные механизмы.
Контрмеры против угроз аутентификации и авторизации:
- Двухэтапная регистрация: Для создания учетной записи пользователь предоставляет электронную почту. На нее высылается уникальная ссылка для подтверждения авторизации.
- Усиленная аутентификация: После регистрации вход в систему осуществляется по логину и сложному паролю. В дополнение к этому, реализована одноразовая проверка по коду OTP, который отправляется на привязанную почту. Это нейтрализует риск использования утекших или подобранных паролей.
- Сессии и контроль активности: Используются безопасные, подписанные криптографически сессии Django. Реализовано автоматическое завершение сессии после подачи голоса, что исключает возможность повторного голосования с одной и той же сессии.
Контрмеры против угроз целостности и конфиденциальности данных:
- Принцип разделения идентификаторов: Для обеспечения конфеденциальности в базе данных реализована схема, где таблица с пользователями и таблица с голосами не связаны напрямую внешним ключом. Голос анонимизируется на уровне приложения перед сохранением.
- Хэширование и неизменяемость: Поданный голос фиксируется по времени.
- Защита на уровне СУБД: Настроены минимально необходимые привилегии для пользователя приложениях для изменения информации в базе данных сервера, запрещающие прямое изменение таблиц.
Контрмеры против угроз на уровне приложения:
- Защита от SQL-инъекций: Обеспечивается за счет использования ORM Django (Object-Relational Mapping). Все запросы к базе данных строятся фреймворком автоматически, параметры экранируются, что делает классические SQL-инъекции невозможными.
- Защита от CSRF: Django предоставляет встроенную и обязательную по умолчанию защиту от CSRF. Для каждого состояния формы генерируется уникальный токен, проверяемый на стороне сервера.
- Защита от XSS: Шаблонизатор Django по умолчанию экранирует все переменные, выводящиеся в HTML. Для безопасной работы с JavaScript используется формат обмена данными JSON.
- Валидация входных данных: Все данные, поступающие от пользователя: логин, пароль, выбранный вариант, проходят строгую проверку на стороне сервера на соответствие ожидаемому формату, длине и типу.
Описанный набор контрмер формируют целостный защитный периметр, направленный на устранение уязвимостей на этапе разработки, а не после развертывания системы.
3. Результаты разработки и тестирования
Реализация контрмер воплотилась в работоспособный прототип веб-платформы для удаленного электронного голосования. Данный раздел описывает итоговый результат разработки и представляет результаты базового тестирования безопасности.
3.1. Функциональные возможности реализованного прототипа
Прототип представляет собой веб-приложение, доступное по стандартному адресу (например, http://localhost:8000 в среде разработки). Реализован следующий минимально необходимый функционал:
- Публичная зона: Страница с описанием текущего голосования.
- Модуль регистрации и аутентификации: Форма регистрации с подтверждением email, форма входа по логину и паролю, а также механизм отправки и проверки одноразового пароля для доступа к бюллетеню.
- Модуль голосования: Динамическое отображение активных опросов только для авторизованных и верифицированных OTP пользователей, форма для выбора варианта ответа с обязательным CSRF-токеном и однократная подача голоса с последующим отображением страницы-подтверждения.
- Административный модуль: Полнофункциональная панель для управления пользователями, опросами, вариантами ответов и просмотра анонимизированных результатов, ведение логов действий администратора.
3.2. Методы и результаты тестирования безопасности
Для верификации эффективности реализованных контрмер было проведено ручное тестиров ание на наличие распространенных уязвимостей, соответствующих выявленным ранее угрозам.
Таблица 2.
Результаты тестирования защитных механизмов прототипа
|
Тестируемая угроза |
Метод тестирования |
Результат тестирования и наблюдаемое поведение системы |
Соответствующая контрмера |
|
SQL-инъекция |
Попытка ввода кавычек ('), команд SQL (OR 1=1 --) в поля логина, пароля, параметры GET/POST-запросов. |
Все попытки завершились неудачей. Приложение либо отображало ошибку валидации формы, либо, в случае сложных атак через ORM, возвращало пустой результат. Утечки или модификации данных не произошло. |
Использование ORM Django. |
|
Тестируемая угроза |
Метод тестирования |
Результат тестирования и наблюдаемое поведение системы |
Соответствующая контрмера |
|
Межсайтовая подделка запроса (CSRF) |
Создание внешней HTML-страницы с формой, отправляющей POST-запрос на эндпоинт голосования, и попытка выполнить ее от имени авторизованной сессии. |
Запросы от внешней страницы отклонялись сервером с ошибкой 403 Forbidden. Голос не был засчитан. |
Встроенный механизм CSRF-защиты Django. |
|
Тестируемая угроза |
Метод тестирования |
Результат тестирования и наблюдаемое поведение системы |
Соответствующая контрмера |
|
Небезопасная аутентификация |
Попытка входа с простыми паролями (123456, password). Попытка повторного использования сессии или OTP-кода после голосования. |
Система допускала слабые пароли (требовалось только наличие минимальной длины), что является условным недостатком. Однако, после однократного голосования сессия блокировалась для повторной операции, а OTP-код становился недействительным. |
Механизм одноразовых сессий и OTP. Рекомендация: внедрить политику сложности паролей. |
|
Нарушение конфиденциальности |
Анализ структуры базы данных PostgreSQL через административную панель и прямое изучение таблиц. |
Прямая связь между записью в таблице auth_user и конкретным голосом в таблице polls_vote отсутствовала. Определить, как проголосовал конкретный человек, по данным БД было невозможно. |
Архитектурный принцип разделения идентификаторов. |
|
Доступность административной панели |
Проверка стандартного пути к админке (/admin) без аутентификации. |
Доступ к панели администратора был возможен только после ввода учетных данных администратора. Попытка прямого доступа перенаправляла на страницу входа. |
Стандартная система аутентификации и авторизации Django. |
3.3. Обсуждение результатов
Разработанный прототип успешно реализует концепцию «безопасность по дизайну». Результаты тестирования подтверждают, что основные архитектурные контрмеры эффективно работают:
- Угрозы инъекций (SQLi, XSS) нейтрализованы средствами самого фреймворка (ORM, экранирование шаблонов).
- Угроза несанкционированных действий (CSRF) блокируется встроенным механизмом.
- Угрозы аутентификации снижены за счет двухэтапной верификации (пароль и OTP).
- Ключевое требование тайны голосования обеспечено на архитектурном уровне схемой хранения данных.
Прототип демонстрирует достаточный уровень защищенности от наиболее вероятных и критичных угроз.
4. Заключение и рекомендации
В рамках данного исследования была решена задача повышения безопасности платформ удаленного электронного голосования на этапе их проектирования и разработки. Работа базировалась на методологии, где анализ угроз предшествует созданию архитектуры, что позволяет целенаправленно закладывать защитные механизмы в саму структуру системы.
Основные выводы работы заключаются в следующем:
- Систематизация угроз является необходимым первым шагом. Разработанная матрица угроз для платформы УЭГ (Табл. 1) выделяет наиболее критические векторы атак: несанкционированный доступ, фальсификация данных и нарушение тайны голосования.
- Комплексный архитектурный подход эффективен. Предложенная трехуровневая архитектура с использованием стека Django и PostgreSQL, дополненная аутентификацией, защитой от SQLi, CSRF, XSS и схемой анонимизации голосов, формирует целостный защитный контур.
- Результаты ручного тестирования (Табл. 2) показали, что ключевые контрмеры успешно отражают попытки эксплуатации стандартных веб-уязвимостей и обеспечивают базовые принципы безопасного голосования.
Таким образом, проведенное исследование демонстрирует, что создание безопасных, пригодных для практического использования систем удаленного электронного голосования является достижимой задачей при условии следования принципам «безопасности по дизайну» и использованию современных проверенных технологий.
