Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Наши способы организации безопасного удалённого доступа к рабочим местам и корпоративным ресурсам
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline nomhoi  
#1 Оставлено : 29 октября 2020 г. 14:05:36(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Нужно реализовать вход по ЭЦП, как это реализовано, например, на ЕИС, госуслугах, nalog.ru.

Сервер Ubuntu, бэкенд на Django.

Достаточно ли использование средств плагина, или нужно использовать серверную SDK?

Как выглядит такой процесс?

Нужно ли сертифицировать в данном случае разрабатываемое ПО?
Offline two_oceans  
#2 Оставлено : 31 октября 2020 г. 5:09:52(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,153
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
Насчет сертификации скорее нет, при условии соблюдения требований формуляра криптопровайдера не создается новое СКЗИ (если конечно из raw подписи, выданной криптопровайдером не собираете в своем коде более сложный тип подписи - при сборке может считаться как новое СКЗИ) и чаще всего нужна "только" оценка влияния (грубо говоря, заключение, что подписывается именно то, что видит пользователь, данные защищены от подмены и соблюдены требования формуляра).

Широкими мазками процесс входа выглядит примерно так:
1. Клиент запрашивает страницу входа.
2. Сервер генерирует уникальную строку, (в самом простом случае гуид), отправляет строку клиенту в коде страницы входа. В коде предусмотрено обращение к плагину/расширению электронной подписи, вывод списка сертификатов клиента, подписание строки от сервера. Уникальность строки важна чтобы не было атак с повторением прошлого входа клиента третьей стороной.
3. Пользователь разрешает обращение к плагину/расширению, выбирает сертификат. Клиентская часть подписывает строку и отправляет серверу. Дополнительно отправляется или сертификат или данные для поиска сертификата в БД на сервере. Может также использоваться только открытый ключ, но в отечественных системах как правило берется сертификат целиком.
4. Сервер находит сертификат в БД (если клиент его не прислал) либо из запроса и проверяет подпись уникальной строки. Если подпись верна, это подтверждает что у клиента есть закрытый ключ соответствующий этому сертификату. Это частичная защита от подмены клиента третьей стороной (подтверждено, что верный клиент на конце цепочки, но посередине может быть еще кто-то).
Обратите внимание, что для проверки подписи гост потребуется криптопровайдер гост на сервере. Сама по себе проверка подписи не использует закрытый ключ и не требует покупки лицензии. Однако, если Вы решите еще и https по госту сделать, то лицензия понадобится.

Шаги 2-4 собственно аутентификация по сертификату, у веб-серверов обычно есть такой алгоритм двухсторонней аутентификации при установлении https (без поддержки сертификатов гост), можно либо подключить гост в веб-сервере и передавать уже проверенный сертификат в приложение либо продублировать шаги 2-4 в своем коде. Если без https (ресурс и так в защищенной сети, например), то однозначно придется дублировать в своем коде. В Интернете сервер должен работать по https и иметь доверенный сертификат. Это позволит клиенту обнаружить ситуацию когда третья сторона подменила сервер, так как алгоритм выше защищает от атаки "человек посередине" (MiTM) только частично.

5. Сертификат сопоставляется сервером по БД с пользователем конкретной информационной системы (сайта). Это идентификация пользователя. При регистрации/редактировании пользователя должны быть заранее указаны какие-то характерные поля сертификата (отпечаток сертификата - для запрета входа другими сертификатами того же человека - ЕИС не руководитель; ФИО, снилс - госуслуги, ЕИС руководитель; инн, огрн, огрнип - сайты ФНС; дополнительно специальное назначение сертификата - Росреестр; дополнительно должность/логин пользователя - СУФД; дополнительно код организации - старые сертификаты ЕИС). Идентификатор ключа из сертификата использовать не рекомендуется, так как теоретически его можно подделать. Для ЕИС руководителя используется основная привязка по фио и снилс, однако отпечаток последнего сертификата по которому вошли записывается в БД.
thanks 1 пользователь поблагодарил two_oceans за этот пост.
nomhoi оставлено 31.10.2020(UTC)
Offline nomhoi  
#3 Оставлено : 31 октября 2020 г. 8:27:13(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Спасибо! Очень хорошо продвинули по этому вопросу.
Offline nomhoi  
#4 Оставлено : 3 ноября 2020 г. 12:04:03(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Цитата:

Обратите внимание, что для проверки подписи гост потребуется криптопровайдер гост на сервере. Сама по себе проверка подписи не использует закрытый ключ и не требует покупки лицензии. Однако, если Вы решите еще и https по госту сделать, то лицензия понадобится.

Нам нужно обеспечить ФЗ-44, требуется ли в этом случае выполнить https по госту?
Еще предполагается, что будет использоваться vpn.

Отредактировано пользователем 3 ноября 2020 г. 12:07:38(UTC)  | Причина: Не указана

Offline two_oceans  
#5 Оставлено : 3 ноября 2020 г. 18:08:08(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,153
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
Факторы могут быть такие: есть пользователи извне Вашей организации? предполагается ли интеграция с ЕИС? vpn "на Вашем конце" железная или программная? vpn по госту, сертифицированная? vpn со стороны пользователей или со стороны ЕИС?

Если vpn программная по госту на этом же сервере, в принципе, то на то и выйдет (закрытый ключ, серверная лицензия, возможно "прелести" настройки двух криптопровайдеров). При интеграции с ЕИС скорее всего тоже (этим направлением не занимался).

Если vpn железная, по госту, сертифицированная, со стороны клиентов, то хороший шанс обойтись без https по госту. Уровень защиты вполне соответствующий, но у контролирующих органов может быть иное мнение.

Или как региональные министерства порой делают: заявляют, что сайт работает по госту, во всех договорах и соглашениях прописано, что передаются персональные данные, потому только гост. Смотрю сертификат - алгоритм Sha256Rsa, подтверждено Let's Encrypt - и гадаю (рукалицо) то ли врут в глаза, то ли не так настроили сервер.

Отредактировано пользователем 3 ноября 2020 г. 18:13:11(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
nomhoi оставлено 04.11.2020(UTC)
Offline nomhoi  
#6 Оставлено : 4 ноября 2020 г. 7:52:39(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Спасибо! Я так понял, что система создается для клиентов, сторонних пользователей. Так понимаю, https по госту делать придется. Можете подсказать, какие регламентирующие документы этот вопрос освещают? В самом ФЗ44 ничего про https и vpn нет.
Offline nikolkas_spb  
#7 Оставлено : 5 ноября 2020 г. 9:54:21(UTC)
nikolkas_spb

Статус: Активный участник

Группы: Участники
Зарегистрирован: 31.01.2017(UTC)
Сообщений: 215
Российская Федерация
Откуда: Санкт-Петербург

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 40 раз в 39 постах
Приказ ФСБ России от 10.07.2014 N 378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности" (Зарегистрировано в Минюсте России 18.08.2014 N 33620)
5. В соответствии с пунктом 13 Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства Российской Федерации от 1 ноября 2012 г. N 1119 <1> (далее - Требования к защите персональных данных), для обеспечения 4 уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:
г) использование средств защиты информации, прошедших процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации, в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз.

для понимания. процедура оценки - это сертификация. всегда.
Цена свободы - вечная бдительность!
thanks 1 пользователь поблагодарил nikolkas_spb за этот пост.
nomhoi оставлено 05.11.2020(UTC)
Offline nikolkas_spb  
#8 Оставлено : 5 ноября 2020 г. 9:58:28(UTC)
nikolkas_spb

Статус: Активный участник

Группы: Участники
Зарегистрирован: 31.01.2017(UTC)
Сообщений: 215
Российская Федерация
Откуда: Санкт-Петербург

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 40 раз в 39 постах
Вдогонку.
Сам протокол https не имеет сертификата. Использование его где-либо без прикрытия спец.средств чревато.
Цена свободы - вечная бдительность!
Offline nomhoi  
#9 Оставлено : 5 ноября 2020 г. 10:19:11(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Понятно, спасибо.
Offline two_oceans  
#10 Оставлено : 5 ноября 2020 г. 10:32:42(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,153
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
Сам я не юрист, так что могу в каких-то моментах ошибаться относительно нормативных актов. Пока писал ответ, выше уже привели правильное название актов.

В целом, если планируется вход по квалифицированному сертификату, то там одно за одно цепляется:
1) в БД придется хранить некие персональные данные пользователя - например, ФИО, снилс, место работы. Конечно тут есть момент, что они публикуются при выдаче сертификата, но, с другой стороны, согласие публиковать дано УЦ, а не некому сайту;
2) персональные данные - требуют особой защиты по закону "о персональных данных", главным образом, нужно шифрование при их передаче и в большинстве случаев расположение серверов на территории РФ;
3) если копнуть шифрование, то окажется что на территории РФ признаны... очевидно, алгоритмы гост. Правила эксплуатации СКЗИ, письма ФСБ также сводят все к актуальным гостам (2012,2015).
Аккредитованные УЦ выдают именно сертификаты гост согласно закона "об электронной подписи".
4) Принцип использования ключа у зарубежных алгоритмов и гост разный, так что смешать части шифросьюта нельзя - или зарубежный шифросьют или гост шифросьют.
5) как я уже упоминал - аутентификация по сертификату не полностью защищает от атаки "человек посередине" (MiTM), поэтому в Интернете сервер обязательно должен показать клиенту сертификат, а это предусмотрено только при использовании https протокола. Полностью атака не исключается, так как клиент может делать MiTM намеренно и обоснованно - для проверки трафика антивирусом, например.

В итоге, чтобы зашифровать персональные данные нужен гост шифросьют и сертифицированное СКЗИ. И нужен https чтобы передать сертификат сервера и снизить риск атаки "человек посередине" при аутентификации. Вообще говоря, эти части не обязательно слеплять вместе - обратите внимание, что госуслуги или портал Росреестра используют не гост-сертификат сервера. Однако, Казначейство везде это слепляет: ЕИС - вход по сертификату из двухстороннего https гост; гас "управление" - односторонний https гост от гас + вход через госуслуги по сертификату гост, односторонний https не-гост от госуслуг.
Цитата:
Сам протокол https не имеет сертификата.
Это да, но в состав сертифицированных СКЗИ (КриптоПро, Випнет) новых версий включен модуль добавления гост в HTTPS. Речь о поддержке в программах Майкорософт, модули gost_capi / gostengy на windows не входят в сертификацию.

Конечно есть аппаратные vpn c гостом, есть сертифицированные прокси (usergate, ngate, от континента тоже что-то такое есть) и т.п. Прикрыть есть чем, но понятно что тогда до приложения вряд ли дойдет сертификат клиента из https и вход по сертификату придется дублировать отдельно от https в своем коде, то есть https с односторонней аутентификацией на прокси и аутентификация по сертификату в приложении уже с http.

Отредактировано пользователем 5 ноября 2020 г. 10:40:08(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
nomhoi оставлено 05.11.2020(UTC)
Offline nomhoi  
#11 Оставлено : 5 ноября 2020 г. 11:38:01(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Спасибо. Сказал руководству обратиться к юристу специализирующемуся по данной теме, проконсультироваться.

Нам нужно обеспечить требования ФЗ-44, в соотвествии с таким приказом: Приказ Федерального казначейства от 30 декабря 2015 г. N 27н "Об утверждении Порядка регистрации в единой информационной системе в сфере закупок и признании утратившим силу приказа Федерального казначейства от 25 марта 2014 г. N 4н"

Пока созрел такой план реализации с использованием Django.

Допустим урл страницы для входа по ЭЦП будет /accounts/fz44/.
По запросу будет генерироваться уникальная строка и сохраняться в переменной 'state' сессии django. state будет передана вместе со страницей браузеру. js-приложение будет создано с помощью
https://github.com/vgoma/crypto-pro.
С помощью js приложения и браузерного плагина строка state будет подписана, state с подписью будет отправлен бэкенду по нажатию кнопки на форме.
В django-проекте будет создан собственный аутентификационный бэкенд, который будет обращаться к приложению на С, которое будет выполнять верификацию подписи. Здесь же, в этом бэкенде, выполнится сверка переменной state. Если верификация подписи проходит, то пользователь авторизуется.

В соответствии с этим приказом нужно будет добавить три группы пользователей: Администратор, Дополнительный администратор, Уполномоченный сотрудник. В django есть возможность создания групп пользователей с определенными правами. Эти группы не должны иметь статус "is staff".
Offline nikolkas_spb  
#12 Оставлено : 6 ноября 2020 г. 8:58:30(UTC)
nikolkas_spb

Статус: Активный участник

Группы: Участники
Зарегистрирован: 31.01.2017(UTC)
Сообщений: 215
Российская Федерация
Откуда: Санкт-Петербург

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 40 раз в 39 постах
Добрый бесплатный совет.
Юрист смотрит со своей поляны. Ты смотри со своей поляны. Он может не знать о приказах ФСТЭК и ФСБ, скорее всего так и есть.
Поэтому, смотри сам и думай сам. На юристов в это вопросе надежды нет, они не безопасники.
Цена свободы - вечная бдительность!
thanks 1 пользователь поблагодарил nikolkas_spb за этот пост.
nomhoi оставлено 27.11.2020(UTC)
Offline nomhoi  
#13 Оставлено : 27 ноября 2020 г. 11:37:13(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Автор: nikolkas_spb Перейти к цитате
Добрый бесплатный совет.
Юрист смотрит со своей поляны. Ты смотри со своей поляны. Он может не знать о приказах ФСТЭК и ФСБ, скорее всего так и есть.

Спасибо за совет. Имел в виду таких юристов, которые разбираются в данном вопросе. Хотя, возможно, врядли есть юристы, которые хорошо разбираются в таких технических деталях.
Цитата:

Поэтому, смотри сам и думай сам. На юристов в это вопросе надежды нет, они не безопасники.

Я так понял, у нас будет аппаратный сертифицированный VPN - випнет. И будет выполняться аттестация системы.

Отредактировано пользователем 27 ноября 2020 г. 11:39:26(UTC)  | Причина: Не указана

Offline nomhoi  
#14 Оставлено : 27 ноября 2020 г. 11:49:39(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Автор: two_oceans Перейти к цитате

5. Сертификат сопоставляется сервером по БД с пользователем конкретной информационной системы (сайта). Это идентификация пользователя. При регистрации/редактировании пользователя должны быть заранее указаны какие-то характерные поля сертификата (отпечаток сертификата - для запрета входа другими сертификатами того же человека - ЕИС не руководитель; ФИО, снилс - госуслуги, ЕИС руководитель; инн, огрн, огрнип - сайты ФНС; дополнительно специальное назначение сертификата - Росреестр; дополнительно должность/логин пользователя - СУФД; дополнительно код организации - старые сертификаты ЕИС). Идентификатор ключа из сертификата использовать не рекомендуется, так как теоретически его можно подделать.


Тут мне кажется, что если подписывать только state-код, то подменить можно и сертификат и данные сертификата.

Наверное, лучше сделать так: к state-коду присоединить данные сертификата, необходимые для идентификации, или сам сертификат, создать хэш, и потом этот хэш подписать. В бэкенде получить подпись и данные сертификата. Взять state-код из сессии, присоединить к нему полученные данные сертификата, создать хэш и выполнить верификацию по хэшу и подписи.

Полагаю, в этом случае можно быть уверенным, что полученные данные сертификата точно соответствуют сертификату, с помощью которого была выполнена подпись.

Отредактировано пользователем 27 ноября 2020 г. 11:51:51(UTC)  | Причина: Не указана

Offline nomhoi  
#15 Оставлено : 27 ноября 2020 г. 12:08:54(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Судя по этой теме: https://www.cryptopro.ru...aspx?g=posts&t=14636
можно однозначно идентифицировать пользователя по отпечатку сертификата, т.е. выполнять поиск по БД по этому отпечатку. Поле SHA1 Hash в сертификате.
Offline nomhoi  
#16 Оставлено : 27 ноября 2020 г. 12:12:19(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
Ну и поскольку отпечаток создается по всем данным сертификата, то к state-коду можно присоединять только этот отпечаток.
И тогда можно не создавать после присоединения хэш. state+отпечаток и так будет похож на хэш и его можно будет сразу подписывать.
Хэш поверх хэша вроде как нехорошо делать.

Отредактировано пользователем 27 ноября 2020 г. 12:15:45(UTC)  | Причина: Не указана

Offline nomhoi  
#17 Оставлено : 27 ноября 2020 г. 12:39:05(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
С другой стороны можно и отпечаток подставить другой.
Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи?
Offline two_oceans  
#18 Оставлено : 27 ноября 2020 г. 12:42:53(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,153
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
Зачем что-то присоединять, тем более постоянную часть? Другим сертификатом просто не проверится подпись, так как открытые ключи разные в сертификатах. Поэтому подмена сертификата ничего не дает. Вы в курсе как во вторую мировую вскрывали шифр машинки Энигма? Немцы тупо писали в начале каждого шифрованного сообщения что-то типа "Дорогой господин" - фиксированную фразу, что давало возможность подбирать ключ пока не получится эта фраза.

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

Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку.
Цитата:
Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи?
Да, использовать cades. Скорее тогда не получится сделать без сертификата. Однако объем подписи будет несколько килобайт что неудобно. Обычно используют при аутентификации на странице Raw подпись до пары сотен байт, в ней нет сертификата.
Цитата:
хэш на хэш - нехорошо
Возможно это прочитали про зарубежные алгоритмы? потому что при формировании ключа которым шифруется контейнер из пароля в гост вычисляется 2000 раз хеш на хэш+соль. Главное не забывайте соль добавлять и хэш на хэш не проблема.

Отредактировано пользователем 27 ноября 2020 г. 13:33:05(UTC)  | Причина: Не указана

Offline nomhoi  
#19 Оставлено : 27 ноября 2020 г. 13:03:40(UTC)
nomhoi

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.10.2020(UTC)
Сообщений: 39
Российская Федерация

Сказал(а) «Спасибо»: 8 раз
С помощью C API https://docs.cryptopro.ru/cades/reference/cadesc можно получить информацию о сертификате из подписи? Как это можно сделать?
Offline two_oceans  
#20 Оставлено : 27 ноября 2020 г. 13:13:15(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,153
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
По идее (плагином) после проверки Verify или CadesVerify должен стать доступен массив Signers подписи из которого можно получить сертификат.

Ах, другое API... после CadesVerifyMessage (или другой подходящей, смотрите по смыслу) получается CADES_VERIFICATION_INFO, в которой есть pSignerCert

MS API: CryptVerifyMessageSignature ppSignerCert

Отредактировано пользователем 27 ноября 2020 г. 13:20:05(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.