[Информационная безопасность, Исследования и прогнозы в IT] Доверенная третья сторона: как с ее появлением меняется электронная подпись

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
24-Дек-2020 19:32

Цитировать

За последние 10 лет принципиальным образом так и не решились вопросы удобного и долговременного (или еще «архивного») хранения документов c электронной подписью (ЭП) и их обмена со взаимным доверием. Да, есть специальные «архивные» разновидности расширенных форматов ЭП (CAdES-A и XAdES-A), которые содержат несколько меток времени, списки отозванных сертификатов и цепочки удостоверяющих центров (УЦ) на момент формирования ЭП. Есть варианты решений с «переподписанием» документов с ЭП или созданием доверенной среды для их хранения. Однако все это не добавляет «юзабилити». Появились и новые проблемы: отсутствие единой политики применения квалифицированных сертификатов в коммерческих информационных системах (особенно на торговых площадках), из-за чего в сертификаты начали добавлять узкоспециализированные OID; отсутствие единого реестра выданных сертификатов при значительном увеличении их числа; большое количество УЦ и их «текучка»; попытки мошенничества с недвижимостью и налоговыми декларациями при помощи квалифицированных сертификатов с ЭП, полученных мошенническим образом.
Принятые 27 декабря 2019 г. изменения в Федеральный закон «Об электронной подписи» нацелены на то, чтобы, наконец-то, устранить большинство этих проблем, узаконить облачную ЭП, а также фактически перестроить рынок удостоверяющих центров. Закон также вводит новый институт – доверенную третью сторону (ДТС). Нормы о ДТС должны вступить в силу с 1 января 2021 года. Несмотря на это, почти все, что связано с ДТС, еще в ожидании разъяснений и регламентации со стороны регуляторов. Попробую описать подробно, что нас ждет.
Какие неочевидные проблемы «краткосрочности» обычной электронной подписи существуют сегодня?
Я работаю в подразделении, которое занимается прикладной интеграцией. Так сложилось, что нам не приходилось внедрять «штатную» ЭП для документооборота «из коробки» или внедрять готовые клиентские приложения для работы с ЭП. Почти всегда задачи внедрения сводились к встраиванию ЭП (включая разного рода автоматизации по обслуживанию жизненного цикла сертификатов, ключей и их носителей) в существующие и совсем не коробочные документообороты или в информационные системы, в том числе с длительным хранением документов. На первых этапах проектирования процесс формирования ЭП больших сложностей обычно ни у кого не вызывал. Казалось бы, ну что тут? Сформировать хеш на документ и подписать его закрытым ключом с использованием базовых форматов электронной подписи, например, CAdES-BES или XAdES-BES. А вот потребность в дальнейшем среднесрочном и долговременном хранение документов с ЭП, проверка ЭП в документообороте (в том числе автоматизированная) всегда в конечном итоге влияли на архитектуру решения. Усложнялись форматы ЭП, начиная от CAdES-T и XAdES-T (с метками времени) и заканчивая их расширенными и специальными «A»-версиями (Archival). А дальше всё по кругу возвращалось к процессу формирования ЭП, чтобы обеспечить необходимым контекстом выбранный для нее формат.
Так как осуществить проверку ЭП документа, хотя бы лет так через 10-15? (Опустим такую подробность, что, скорее всего, спустя столько лет не будет сертифицированных средств криптографической защиты информации (СКЗИ), поддерживающих нужные криптографические алгоритмы и нужные форматы, а необходимые средства просмотра электронных документов не будут запускаться на текущих ОС.)
Обратимся к закону об ЭП (от 06.04.2011 № 63-ФЗ). Какие условия признания (проверки) квалифицированной ЭП содержатся в статье 11 «Признание квалифицированной электронной подписи» (приведу только пункт 2 статьи, потому что именно он влияет на проверку документов с ЭП во времени):

Квалифицированная электронная подпись признается действительной […] при одновременном соблюдении следующих условий:
2) квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен.

Ключевая информация (особенно в контексте длительного хранения документов) тут заключена в скобки. Квалифицированный сертификат не просто должен быть действительным на момент подписания электронного документа, но и сам момент подписания электронного документа должен быть зафиксирован, причем «достоверно», – и это обязательное условие.
Законодатель не предложил и даже не намекнул на способы подтверждения достоверности информации о моменте подписания электронного документа. Впрочем, это нормально. Требования к процедуре должны раскрывать ответственные регуляторы. И спустя 9 лет, после того, как в конце 2019 года вышли изменения к закону об ЭП, Минцифры России и ФСБ России (в части работы с меткой времени, но об этом дальше), наконец-то, разработали проекты приказов. Пока же бремя доказывания достоверности момента подписания все еще лежит на плечах разработчиков СКЗИ и на владельцах информационных систем. Например, полагаясь на открытые международные спецификации и стандарты, они вынуждены сами выбирать форматы ЭП, в том числе с меткой времени, и ждать, подтвердит или скорректирует их подход судебная практика.
Какие решения для обхода «краткосрочности» базовой ЭП обычно используют?
Единый стандарт для формата ЭП с меткой времени в процессе разработки. Самым очевидным, с точки зрения среднесрочного (5-10 лет) и долгосрочного хранения документов с ЭП, является реализация квалифицированной ЭП в одном из расширенных форматов (на усмотрение владельца ИС) как минимум:

с внедренной меткой времени для достоверного определения момента подписания электронного документа сроком до 15 лет (теоретический максимальный срок действия сертификата ключа проверки ЭП «сервиса меток времени»);
с информацией о факте проверки сертификата в виде приложенного ответа от OCSP-службы (службы онлайн-проверки статуса сертификата) или приложенного списка отозванных сертификатов (обеспечивающего подтверждение действительности квалифицированного сертификата на момент подписания), подкрепленных меткой времени.

К менее очевидным и менее распространенным решениям, обеспечивающим проверку ЭП документа через N-лет, относится создание доверенных сред хранения. В такую среду документ с ЭП помещается чаще всего еще во время действия выданного пользователю квалифицированного сертификата ЭП (например, сразу после подписания) с максимальным набором метаданных. При помещении документа с ЭП в доверенную среду проверяется ЭП, статус сертификата, формируются расширенные отчеты о фактах проверок. После этого целостность документа и всех связанных с ним метаданных обеспечивается доверенной средой. К таким решениям можно отнести, например, и внутренние/отраслевые реестры крупных организаций, в которых регистрируется максимально возможный набор метаданных документа с ЭП (как минимум, атрибуты документа и его хеш, ЭП, идентификатор сертификата и сам сертификат ЭП, факт проверки сертификата с меткой времени, отдельно метка времени на ЭП). При желании все это может быть подписано сверху технической подписью «архивариуса». В целом это подходит для внутренних нужд крупных компаний и организаций, где документы с ЭП не отчуждаются из системы или сама ЭП первично реализовывалась без метки времени.
Громоздкие доверенные среды хранения документов помогают избегать некоторых потенциальных проблем с компрометацией ЭП, так как подписанный документ сохраняется со всем набором метаданных. Но все же они не способствуют осуществлению электронного документооборота с ЭП между организациями. И опять, к сожалению, не отменяют необходимость доказывать достоверность информации о моменте подписания документа.
Как изменит ситуацию появление доверенной третьей стороны?
Мы добрались до самого главного. В дополнениях к 63-ФЗ «Об электронной подписи» от 27.12.2019 вместе с целым рядом изменений, в том числе юридическим признанием облачной ЭП, появляется институт доверенной третьей стороны (статья 18.1). Это новый вид организации, которая призвана обеспечить доверие при обмене электронными документами с ЭП.
Законом определяется перечень услуг, которые ДТС будут оказывать участникам электронного взаимодействия:

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

Иными словами, появляется аккредитованная организация (а не просто набор сервисов при аккредитованном УЦ), предоставляющая такой необходимый набор услуг:

проверка действительности ЭП и сертификатов на определенный момент времени;
проверка полномочий владельцев сертификатов ЭП;
выдача квитанций с результатами проверки квалифицированной ЭП;
ведение фактического реестра выполняемых (верифицируемых) операций.

По сути это все те задачи и соответствующие «аккредитованные» решения по проверке ЭП во времени, которые призваны обеспечить внешний доверенный электронный документооборот с ЭП и минимум среднесрочное хранение документов.
А что не так с меткой времени и когда она должна заработать?
Подчеркну, что, в первую очередь, меня интересует правовое закрепление использования метки времени и унификация формата ЭП с меткой времени, а не сами расширенные форматы ЭП (основанные на разных международных стандартах), в которых метка времени давно уже используется.
К сожалению, законодатель (до декабря 2019) и регуляторы (до сентября 2020) не раскрывали функционал «метки времени». Отсюда пошли различные несовместимые между собой форматы ЭП. Они вроде бы и являлись усиленными квалифицированными и были выполнены на сертифицированных средствах, но обмен документами с такими ЭП с автоматическим доверием между разными информационными системами в обход системы межведомственного электронного взаимодействия (СМЭВ) был невозможен. В СМЭВ, конечно же, используется метка времени, выдаваемая внутренним сервисом для ЭП в формате XAdES-T, но решает она скорее транспортные задачи при передаче документов.
На сегодня с меткой времени больше ясности, но пока она так и не закреплена в нормативно-правовых актах.
«Метка доверенного времени» (именно так указано в законе об ЭП, но я везде пишу просто «метка времени») добавлена изменениями к закону об ЭП от 27.12.2019 г. Правда этот термин упоминается однократно в ст. 2 «Основные понятия, используемые в настоящем Федеральном законе», и больше нигде не используется. Норма о метке времени вступает в силу одновременно с нормой о ДТС (с 01.01.2021 года), поскольку они связаны между собой.
Закон определяет «метку времени» так:

«Достоверная информация в электронной форме о дате и времени подписания электронного документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной, удостоверяющим центром или оператором информационной системы […]».

Таким образом, метка времени может создаваться и проверяться ДТС, УЦ и оператором ИС, если она получена:

«[…]в момент подписания электронного документа электронной подписью в установленном уполномоченным федеральным органом порядке с использованием программных и (или) аппаратных средств, прошедших процедуру подтверждения соответствия требованиям, установленным в соответствии с настоящим Федеральным законом».

Почти год спустя (14 сентября 2020 г.) после появления метки времени в законе об ЭП вышел приказ Минцифры России № 472 «Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи». Он, наконец-то:

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

Далее. В дополнение к приказу Минцифры России № 472 (где, как я написал выше, нет ни определения метки времени, ни ссылки на нее, но есть требование к размещению в составе ЭП «времени создания ЭП») появилось 2 проекта правовых актов:

приказа Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации «Об утверждении порядка создания и проверки метки доверенного времени» в версии от 09.10.2020. Здесь раскрывается порядок создания и проверки меток времени «службой меток доверенного времени» (новый термин), определяются протокол взаимодействия со «службой штампов времени» (еще один новый термин), а также формат и содержание метки времени;
приказа ФСБ России «О внесении изменений в приложения ‎№ 1 и 2 к приказу ФСБ России ‎от 27 декабря 2011 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». Он обязывает создавать средства, «реализующие механизмы формирования меток доверенного времени» и «службы меток доверенного времени» в составе УЦ.

Очевидно, что ДТС для фиксирования «определенного момента времени» также нужна метка времени или сертификат ЭП, срок действия которого еще не истек. Метка времени должна быть одновременно и «доверенной», и «правильной» (ДТС должна ее понимать). И, скорее всего, идеальный алгоритм проверки электронных документов с ЭП, в которых реализована метка времени, в ДТС будет следующем:

Создание электронного документа с ЭП, где ЭП реализована средствами и в формате с поддержкой метки времени (приказ Минцифры России №472).
Получение метки времени в ДТС или где-то еще (в УЦ или у оператора ИС).
Встраивание метки времени (выданной «аккредитованным» сервисом – ДТС/УЦ/оператор ИС) в документ с ЭП.

И только если все эти этапы будут пройдены, ДТС сможет «подтвердить действительность электронной подписи» со всеми «плюшками и расширенными отчетами». Что из этого следует? Все, кто пожелает использовать ДТС для проверки документов с ЭП после истечения срока действия сертификата ЭП, должны иметь:

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

Формат метки времени

SPL

Проект приказа Минцифры России, о котором я писал выше, предлагает сделать rfc 3161 «Time-Stamp Protocol (TSP)» основой для формата метки времени и протокола взаимодействия со службой штампов времени. Кроме того, в документе предъявляются общие требования к алгоритму работы «службы штампов времени». Вот некоторые из них:

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

Если пропустить параметры, касающиеся протокола взаимодействия вызывающей стороны со службой штампов времени, то сама метка времени TimeStampToken будет выглядеть так:

На ум приходит пока только пара производителей СКЗИ, которые уже выпускают средства (серверную часть, библиотеки и клиентскую часть) для работы с меткой времени по rfc3161.

Нормативно-правовые акты регуляторов еще не приняты, тем не менее пазл с меткой времен начинает сходиться:

есть требования к ЭП (приказ Минцифры России № 472, который определяет необходимость учитывать время создания ЭП);
есть требования к службе и формату метки времени (проект приказа Минцифры, см. выше);
есть требования к СКЗИ, в которых должна поддерживаться метка времени (проект приказа ФСБ, см. выше);
есть требования к УЦ и ДТС, в составе которых должна быть реализована «служба меток доверенного времени» (тот же проект приказа ФСБ, см. выше).

Сложный функционал проверки полномочий в ДТС
Вернемся к ДТС и функционалу проверок правильности применения сертификатов ЭП и полномочий. В соответствии с изменениями в законе об ЭП от 27.12.2019 ДТС выступает в том числе в роли «авторизационного» центра, выполняющего:

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

При этом первый пункт также должен включать проверку правильности применения сертификата квалифицированной электронной подписи (КЭП):

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

Отдельно разберемся со вторым пунктом – проверкой полномочий. Кроме правильности применения типа сертификата выданного на физлицо, юрлицо или ИП, здесь должна выполняться проверка документа о полномочиях, который должен быть «подписан КЭП уполномоченного в установленном порядке на принятие соответствующих решений должностного лица соответствующего государственного органа или органа местного самоуправления». Сами же полномочия должны быть «определены на основании классификатора полномочий, который уполномоченный федеральный орган формирует, актуализирует». В соответствии со статьями 17.2 и 17.3 закона об ЭП необходимо также проверить наличие и содержимое электронной доверенности, поскольку именно она уполномочивает сторону на те или иные правоотношения. Таким образом, при проверке полномочий ДТС должна также проверять:

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

Выполнять данные проверки, конечно же, сможет прикладная система. Она понимает контекст электронных правоотношений, знает, какие полномочия и доверенности допустимы с сертификатами КЭП и с какими УЦ можно/нужно работать. Другой вопрос, как будет проводить такие проверки ДТС, ведь она не обладает информацией о контексте правоотношений.
«Авторизационные» операции при использовании сертификатов ЭП, с одной стороны, унифицировались. Специфицированные OID-ы в сертификатах ЭП теперь должны игнорироваться, а схемы авторизаций по принципу свой/чужой OID с 01.06.2020 вне закона. С другой стороны, разграничение полномочий и правила применения сертификатов ЭП трансформировались в более сложные процессы, которые еще должны быть отрегулированы к 01.01.2022.

«Белые пятна» в проверке полномочий

SPL

В проекте приказа ФСБ России «Об утверждении Требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи» разъяснений по «авторизационным» функциям ДТС так и не последовало. Например, пункт 2.3 проекта требований гласит:

«Компонент проверки полномочий должен осуществлять проверку полномочий должностного лица – отправителя электронного документа, являющегося владельцем сертификата ключа проверки электронной подписи».

Не ясно, где, например, проверка полномочий физического лица, действующего на основании документа о полномочиях или действующего на основании электронной доверенности? И какие именно полномочия должностного лица тут будут проверяться? Будем надеяться, что требования к применению доверенностей и полномочий, которые вступают в силу только с 01.01.2022, еще будут уточнены.
Сам же проект приказа определяет требования к набору компонентов средств ДТС и к функционированию компонентов средств ДТС. Большинство требований технические и организационно-технические и касаются информационной безопасности, что также несомненно очень важно, потому что позволит начать создавать «аккредитованные» ДТС.

Выводы: уже куда-то бежать или ждать?
«Легализация» хранения и дистанционного использования средствами УЦ облачной ЭП с 01.01.2021 должна запустить новый виток ее развития. Это касается увеличения количества внедряемых услуг на базе ЭП (особенно в наше ковидное время) и удобных сервисов работы с ЭП для мобильных клиентов и клиентов на рабочих местах, которые, в свою очередь, будут нуждаться во внешних обслуживающих сервисах проверки ЭП (на базе ДТС).
Скорее всего, либо под новый год, либо сразу же после праздников упомянутые мною приказы примут. Потом разработчикам СКЗИ потребуется еще месяца 3-4 для корректировки клиентского ПО и библиотек под новый формат ЭП с меткой времени и сервисы служб меток доверенного времени. К слову, последние у ключевых разработчиков СКЗИ уже реализованы и эксплуатируются как TSP-службы штампов времени.
Далее потребуется еще некоторое время на разработку функционала ДТС, явно не завязанного на какие-либо форматы, но необходимого по закону об ЭП:

создание квитанций с результатом проверки КЭП в электронном документе;
хранение данных, в том числе документирование выполняемых ДТС операций.

С учетом всех необходимых доработок ПО, а также организационных процедур на аккредитацию, ждать появления первых ДТС раньше лета 2021 года, думаю, не стоит. Может быть, ФНС и ключевой разработчик СКЗИ выпустят что-то раньше в качестве тестовой версии ДТС.
Услуги ДТС, очевидно, не будут бесплатными для всех, и все затраты прямо или косвенно лягут на участников электронного взаимодействия.
Появление на рынке ДТС должно в итоге способствовать появлению полезных сервисов (в первую очередь, в виде API для встраивания), которые смогут обеспечивать:

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

Эти сервисы можно будет встраивать в информационные системы, например:

для среднесрочного хранения документов,
для экспорта/отчуждения документов пользователям без опасения, что они станут непроверяемыми через год,
для автоматизированного принятия решений на основании результата проверок ЭП.

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

«Нам кажется, основной сценарий — использование электронной подписи на смартфоне. Такое техническое решение мы с коллегами согласовали, такая возможность есть».

Сказано это было в контексте поддержки министерством инициативы по бесплатной выдаче ЭП пользователям портала госуслуг.
Итого: заявленные изменения в законе об ЭП и предложенный функционал ДТС действительно интересны, долгожданны и обязательно будут востребованы. Метка времени (которая вводится одновременно с ДТС с 01.01.2021) «автоматически» решит проблемы среднесрочного хранения документов. ДТС и унифицированный формат ЭП с меткой времени позволят осуществлять доверенный оборот документов с ЭП старше 1 года и проверять их после отчуждения из системы. Конечно, многое зависит от реализации, и в том числе от регламентов и приказов Минцифры России и приказов ФСБ России, которые в идеале должны привести к единому знаменателю технические решения по всем ДТС.
Вместо P.S. Будущее рынка УЦ и ДТС
И напоследок хотелось бы написать про возможное схлопывание рынка УЦ.
Этим же законом изменен срок аккредитации УЦ с 5 до 3 лет. Аналогичный срок – 3 года – определен для аккредитации ДТС. При этом значительно возросли требования к УЦ. Теперь необходимо:

минимум 1 млрд рублей собственных средств (капитала) или 500 млн рублей капитала, но при этом один либо несколько филиалов или представительств УЦ должно быть размещено не менее чем в 3/4 субъектов России (аналогичное требование к ДТС);
финансовое обеспечение ответственности за убытки, причиненные третьим лицам в размере не менее 100 млн рублей для УЦ (сейчас это 30 млн рублей). Для ДТС размер еще не определен.

По оценкам экспертов, увеличение требований к минимальному капиталу приведет к сокращению количества УЦ более чем в 10 раз уже в 2021 (примерно с 450 до 20-40). По аналогии не ожидается и появления значительного количества ДТС, которые, скорее всего, будут созданы при ключевых УЦ (Центробанке, налоговой службе, казначействе), чтобы обслуживать их внутренние потребности. Возможно, они появятся и при нескольких крупных «выживших» коммерческих аккредитованных УЦ.
Пользователям или разработчикам небольших прикладных систем (тех, кто хотел бы внедрить документооборот с облачной ЭП), конечно же, интереснее работать с независимыми от удостоверяющих центров ДТС, а также взаимодействовать со всеми или большинством крупных УЦ.
Существующим УЦ, полагаю, было бы интересно создать свои ДТС. Для них это фактически процессинговый центр по проверке постоянного потока документов с ЭП, выполненный на собственных продуктах и решениях. Тем более что закон явно не запрещает совмещать УЦ и ДТС в одном юрлице. Но при таких требованиях к капиталу реальные возможности выйти на рынок этих услуг есть разве что у крупных технологичных банков.
Пишите, если есть вопросы не для комментариев — вот моя почта: SGontzov@croc.ru.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_issledovanija_i_prognozy_v_it (Исследования и прогнозы в IT), #_elektronnaja_dokumentatsija (электронная документация), #_dts (дтс), #_elektronnaja_podpis (электронная подпись), #_informatsionnaja_bezopasnost (информационная безопасность), #_zakonodatelstvo_v_it (законодательство в ит), #_doverennaja_tretja_storona (доверенная третья сторона), #_blog_kompanii_krok (
Блог компании КРОК
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_issledovanija_i_prognozy_v_it (
Исследования и прогнозы в IT
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 14:57
Часовой пояс: UTC + 5