для чего нужен mydss
Для чего нужен mydss
КриптоПро myDSS – это приложение для смартфона, которое позволяет подписывать квалифицированной электронной подписью документы и контролировать действия пользователя в системах дистанционного банкинга, порталах госуслуг, системах ЭДО, электронных торговых площадках и т.д.
В основе КриптоПро myDSS лежит технология PayControl, которая обеспечивает строгую криптографическую аутентификацию пользователей, безопасное online-взаимодействие, отображение документа и подтверждение операций. Это позволяет сервису облачной электронной подписи КриптоПро DSS выполнить требования, предъявляемые регулятором к средствам электронной подписи.
Совместная разработка компаний КриптоПро и SafeTech на базе сертифицированного средства криптографической защиты КриптоПро CSP, КриптоПро DSS и системы подтверждения электронных транзакций PayControl.
Безопасность
Приложение myDSS выполняет визуализацию электронного документа и формирование подтверждения на его подписание в КриптоПро DSS.
Криптографическая аутентификация и защита канала между приложением и сервером КриптоПро DSS гарантируют, что только легальный пользователь сможет воспользоваться ключами подписи.
Ключи электронной подписи пользователей хранятся в сертифицированном КриптоПро HSM в неизвлекаемом виде.
Юридическая значимость подписи
Документ и другие действия пользователя заверяются квалифицированной электронной подписью, что обеспечивает неотказуемость действий. Пользователь не только подтверждает содержание документа, но и в дальнейшем не имеет возможности отказаться от совершенного действия.
Загрузка myDSS
Для загрузки приложения отсканируйте QR-код или перейдите по одной из ссылок ниже.
Облачная электронная подпись: что это такое и как ей пользоваться?
Появление электронных подписей позволило оптимизировать многие бизнес-процессы и работу компаний. Информация о пользователе, записанная на USB-носитель сделала электронный документооборот быстрым и удобным.
Ею пользуются не только ИП и ООО, но и физлица, например, для входа на «Госуслуги» или сайт ИФНС, чтобы получить услугу государственных учреждений.
На смену ставшей привычной ЭП, пришла облачная электронная подпись (ОЭП), которая не требует записи ключа и сертификата на носитель (рутокен), и нет привязки к рабочему месту. Не все еще знают, что это такое, как ей пользоваться, и какие преимущества она дает.
Ввиду того, что нашими читателями, в основном, являются участники и организаторы торгов, рассмотрим этот вопрос с точки зрения участия в тендерах, и какие в этом плюсы. Дадим инструкцию по установке необходимых программ и приложений для компьютера и телефона, чтобы можно было подписывать документы облачной ЭП.
Как стали использовать облачные электронные подписи (ОЭП)?
Использование электронных подписей прочно вошло во многие сферы нашей жизни. В различных компаниях сотрудников переводят на электронный документооборот (ЭДО), что делает все процессы удобными и быстрыми. Для подписания документов (договоров, актов, ведомостей, бухгалтерских отчетов и т.д.) требуется наличие электронной подписи. С помощью нее также осуществляется вход в личный кабинет пользователя ЭДО.
В своей работе применяют ЭП онлайн-специалисты и фрилансеры, которые ведут свою деятельность легально и заключают договора с заказчиками. Физические лица могут приобрести ЭП и пользоваться услугами государственных учреждений: записываться на прием в ФНС, к врачу районной больницы, подавать заявления, справки, заходить на «Госуслуги».
Наши читатели – это, в основном, участники торгов и заказчики, которые такие торги организовывают. Они тоже пользуются ЭП для входа в личный кабинет ЕИС, на электронную торговую площадку, при непосредственном участии в торгах.
Мы уже привыкли к электронной цифровой подписи (ЭЦП), которая записана на рутокен (флеш-накопитель), принадлежит одному конкретному владельцу и обеспечивает безопасность данных о нем. Сегодня аббревиатура ЭЦП уже не используется, так говорить неправильно. В обиход вошло новое сокращение – ЭП (электронная подпись). По своей сути, ЭЦП и ЭП – это одно и то же, однако в статье будем использовать новое общепринятое сокращение – ЭП.
На смену понятию электронной подписи, записанной на цифровой носитель, пришло понятие облачной электронной подписи (ОЭП), которая реализована с помощью современных технологий. Она не требует записи сертификата и ключа на какой-либо носитель, а хранится на специальном облаке, в связи с чем у пользователей возникает вопрос о ее надежности. В статье максимально подробно постараемся на него ответить.
Для ЭП на носителе необходима установка специальных программ на компьютер пользователя (СКЗИ) и дополнительных надстроек. В связи с тем, что на смену таким приложениям пришли облачные приложения, у IT-разработчиков появилось желание внедрить их в работу с ОЭП.
Не все до конца понимают, что такое «электронная подпись в облаке», а те понятия, которые даются на различных сайтах в интернете или на youtube-каналах блогеров, подходят для новичков и объяснению «на пальцах». С одной стороны, это хорошо, так как пользователь ЭП не должен иметь образование программиста и вникать в тонкости шифрования информации. Он просто подписывает документ, а как это происходит, как генерируется каждый отдельный код при подписании, интересно далеко не всем.
Что же такое ОЭП с научной точки зрения, расскажем ниже. Любознательным читателям это определение, а также весь материал данной статьи пригодится для расширения собственного кругозора.
Что такое квалифицированная ОЭП?
На сайте компании «КриптоПро», которая занимается разработкой и внедрением программ и приложений для работы с ЭП дается формулировка ОЭП, которая, по нашему мнению, наиболее соответствует действительности:
«Электронная подпись в облаке (облачная электронная подпись) – это вычислительная система, предоставляющая через сеть доступ к возможностям создания, проверки ЭП и интеграции этих функций в бизнес-процессы других систем».
Эта формулировка не исключает возможности для ОЭП использовать и локальное средство ЭП. Например, используя КриптоПро DSS Lite, пользователь через веб-браузер может подписывать электронный документ с помощью средства ЭП, установленного на его компьютер или планшет. В этом случае ключ подписи остается у пользователя, и защищенность сведений обеспечивается за счет стандартных методов, которые объединены в привычную нам ЭП. Или, проще говоря, это облачная ЭП с локальным средством ЭП.
Другой вариант облачной ЭП получается при использовании средства ЭП, хранящегося на облаке. Чтобы не путать это понятие с первым, назовем такую цепочку «полностью облачной ЭП». В среде специалистов до сих пор не утихают споры по поводу ее безопасности, так как информация передается на облако. Известно, что ЭП должна принадлежать одному собственнику. Записанную на носитель подпись владелец может хранить, например, в сейфе, чтобы ограничить доступ к ней третьих лиц. А как обеспечивается безопасность на облаке? Могут ли его взломать мошенники? Как сами разработчики гарантируют конфиденциальность информации, размещенной на облаке, и имеют ли сами доступ к ней?
Вопросами защищенности облака занимаются «безопасники» и консультирующие их юристы. Сведения должны не просто попасть на облако, но и быть обработаны и сохранены. С локальным средством все понятно: ЭП находится в защищенном пространстве пользователя. Но для облачной ЭП такое пространство отсутствует. При этом ответственность за обеспечение конфиденциальности данных в каком-то смысле «размывается» между её собственником и поставщиком облачных услуг.
Некоторые пользователи не доверяют надежности облака, так как не до конца понимают механизмы его действия. На облако передается ключ ЭП, а это информация, которая конфиденциальна и принадлежит конкретному человеку – собственнику. Защищенность ключа зависит от уровня безопасности средств, которые используются при аутентификации, и от ответственности владельца.
Разработчики КриптоПРО внедрили программу КриптоПро DSS, которая в тестовом режиме испытывалась экспертами. В этот сервер передаются ключи и сертификаты пользователей, а чтобы получить к ним доступ, необходимо пройти аутентификацию, которая возможна только для одного лица – владельца.
Как работает ОЭП?
Рассмотрим пример, характерный для участников торгов. Допустим, поставщик направляет свое предложение на участие в тендере. До появления ОЭП подписать документ невозможно было без установленного на компьютер пользователя плагина. Этот плагин и софт локального средства сообщались друг с другом и работали в неразрывной связке. Этот софт подключался к софту на USB-токене, который генерировал код (ключ). С помощью ключа транзакция заверялась и уже подписанная переходила в плагин на браузер.
Теперь вытащим из этой схемы флеш-накопитель: софт подключается к облачному хранилищу по защищенному каналу.
Одной из первых площадок, которая оценила возможности новых технологий и внедрила в свои процессы использование облачной ЭП, стала федеральная торговая площадка «Росэлторг».
Ответы на самые распространенные вопросы
А можно без софта на локальном компьютере?
Да, это возможно, если на ЭТП есть дополнительный сервер, который обрабатывает входящую информацию и выступает в роли этого самого локального средства. В этом случае пользователь может использовать любой браузер.
В чем отличие стандартной ЭП от облачной?
Оба эти варианта имеют общее ядро с сертификатом и уровнем безопасности. По своей сути, они аналогичны, просто меняется схема внутреннего API-шифрования при кодировке информации. В первом случае ключ извлекается из локального средства, а во втором – с виртуального (удаленного).
Для использования облачной ЭП тоже нужна авторизация?
Да. Однако теперь авторизация имеет два уровня защиты, и нет привязки к компьютеру. При этом авторизация для пользователя не вызовет никаких сложностей:
Таким образом, злоумышленникам трудно будет украсть Вашу подпись, так как для этого они должны еще иметь доступ к Вашему телефону или электронной почте, на которые придет СМС или письмо с паролем.
Где хранится сертификат на стороне удостоверяющего центра?
Каждый удостоверяющий центр имеет свое хранилище, которое называется HSM (hardware security module). Оно имеет защищенное пространство, которое поделено на закрытые ячейки. Массовый доступ к ним запрещен.
Проще говоря, пользователь авторизовался, создал запрос на формирование подписи, запрос попадает в HSM на подпись. Шифр подписи генерируется каждый раз при подписании нового документа. Поэтому электронная подпись – это защищенный объект, а ключ не доступен к просмотру.
HSM подтверждает право владельца подписать форму, как нотариус при сделке подтверждает, что вы – это действительно вы.
Как выглядит первое подключение?
Сначала нужно произвести нехитрую настойку на устройстве пользователя. Для этого вводится два адреса DSS-системы. В принципе, на этом настройка заканчивается.
Следующий этап – это авторизация на сервере. Собственник ОЭП указывает в полях персональные логин и пароль, которые он получил в удостоверяющем центре. После этого проходит двухэтапную авторизацию. Чаще всего, необходимо считать полученный QR-код и скачать.
Потом сканируется второй код со ссылкой на свою ячейку в HSM. Пользователь получает пин-код на подтверждение операции на свой телефон, идентифицируя себя. Затем нужно сменить пароль для входа.
Последующие операции происходят быстрее: ПИН отправляется push-уведомлением. Подразумевается, что если мобильное устройство защищено FaceID или считыванием отпечатка пальца, то второго уровня авторизации, совместно с указанием логина и пароля, вполне хватает для обеспечения конфиденциальности.
Если клиент потерял «незапароленный» телефон, на котором хранилась фотография с логином и паролем (реальный случай из жизни), он может обратиться в УЦ и попросить заблокировать доступ до выяснения.
Как получить конверт с доступами к ОЭП?
Конверт может получить заявитель (директор организации, должностное лицо, ответственный сотрудник), явившись лично в удостоверяющий центр с паспортом.
Либо может прийти сотрудник с официальной доверенностью, соответствующей требованиям 63-ФЗ (об электронной подписи) и требованиям службы безопасности УЦ.
ОЭП широко используется, или пока это редкость?
Использование ОЭП – это уже массовое явление сегодня. Тысячи клиентов из разных субъектов РФ применяют в своей работе электронную подпись на облаке. Из них большинство пользователей – это юридические лица, на втором месте по популярности использования – ИП. Большинство клиентов – москвичи. Затем идут граждане из Санкт-Петербурга, Новосибирска, Хабаровска, Ростова-на-Дону.
Как установить ОЭП и начать работать?
Для работы на локальном компьютере потребуется:
Чтобы пользоваться ОЭП на мобильном устройстве, оно должно работать на базе операционных систем не ниже Android 7.0 или iOS 8/9/10/11. Кроме этого, нужно установить приложение MyDss
Установка и настройка на смартфоне приложения MyDss
4. Для начала работы система уведомит вас о необходимости сканирования QR-кода. Предоставьте камере доступ к этому действию.
5. Считайте QR-код с сертификата, который получили в УЦ.
6. Придумайте имя для сохраняемого ключа, например, «ОЭП для торгов».
7. Выберите способ авторизации (с паролем, без пароля, отпечаток пальца, Face ID).
8. Программа готова к использованию.
Установка СКЗИ КриптоПро CSP 5
Чтобы пользоваться облачной ЭП потребуется наличие операционной системы Windows 7, 8, 8.1 или 10. Проверьте, что Ваша ОС подходит для работы с ОЭП. Для этого откройте «Центр обновлений Windows» и запустите поиск и обновления компонентов Windows.
Для работы с облачной подписью обязательно нужно скачать и настроить программу КриптоПро CSP 5.0.
Настройка КриптоПро CSP 5.0
3. Перейдите в раздел «Облачный провайдер».
Замена адреса DSS-системы
4. Вбейте логин и нажмите «Далее».
5. При первом запуске программы система предложит придумать новый пароль для доступа в личный кабинет. Для этого укажите старый пароль, а ниже – новый пароль, затем подтвердите его. При повторном запуске изменять пароль не нужно.
Аутентификация в приложении myDSS
Следующим шагом потребуется выполнить аутентификацию. Действие выполняется в приложении MyDss c мобильного устройства.
Если Вы выполнили все действия правильно, то система уведомит об успешности процедуры. На экране появится надпись «Установка сертификатов завершилась успехом».
Электронная подпись заработает по-новому. Для чего нужен переход на myDSS
Электронная подпись заработает по-новому. Для чего нужен переход на myDSS
С 1 января 2022 года в работе электронной подписи произойдут изменения. Отправка отчетов и подпись документов будет происходить с помощью технологии myDSS, а обычные sms уйдут в прошлое. Рассказываем, как это работает и для чего нужно продлить ЭЦП.
Что такое myDSS?
Это приложение для смартфона, которое работает по технологии PayControl. Приложение сделали для более безопасной работы с электронной подписью на госуслугах, онлайн-банкинге, ЭДО, тендерах и банкинге. Приложение гарантирует, что электронной подписью воспользуется только легальный пользователь.
Как это работает в Небе
Рассказали об этом нагляднее в нашем видеоролике:
Что будет со старой электронной подписью?
Подтверждение с помощью SMS работает до 1 января 2022 года. К сожалению, после этого электронная подпись перестанет действовать. Поэтому лучше уже сегодня ее продлить.
Для продления подписи нужно сделать несколько простых действий. Зайдите в раздел «Моя организация» → «Электронные подписи» и нажмите «Продлить срок действия».
Если у компании не поменялся директор и его паспортные данные, то Небо автоматически подгрузит старые данные и не нужно приходить в Центр идентификации для подтверждения личности. Нужно только подгрузить заявление и сканы первой страницы паспорта.
Если вы недавно продлили электронную подпись, то Небо компенсирует неиспользованный период на ваш баланс в сервисе. Например, вы заказали подпись в августе 2021 года до августа 2022 года. Если вы оформите новую подпись 1 декабря 2021 года, то она будет действовать до марта 2023 года, а заплатить нужно будет только за 3 месяца, так как вы не использовали 9 месяцев. Для компенсации позвоните или напишите в Небо.
Если оформляете электронную подпись впервые, то нужно заполнить заявление и прийти в Центр идентификации с документами, чтобы подтвердить личность.
Для чего нужен mydss
Раздел содержит руководство разработчика по работе с myDSS на Сервисе Управления Пользователями. В разделе приведены основные сценарии использования, примеры HTTP-запросов и ответов REST Сервиса Управления Пользователями.
Так же в разделе приведены рекомендации Администраторам по настройке DSS для реализации различных сценариев работы с myDSS.
Перед началом интеграции с Сервисом Управления Пользователями Администратору DSS необходимо:
Сценарии должны выполняться учётной записью с ролью Оператора DSS.
Аутентификация Операторов DSS на Сервисе Управления Пользователями осуществляется по сертификату (двухстороннее TLS-соединение).
Последовательность шагов по регистрации пользователя:
Регистрация логина пользователя
В качестве идентификатора (логина) пользователя могут выступать:
Внимание!
По умолчанию на DSS в качестве идентификатора разрешён только Логин.
Разрешить/запретить другие идентификаторы пользователя может Администратор DSS выполнив команду в консоли PowerShell:
Примеры запросов
Пример ответа
В ответ DSS вернёт идентификатор созданного пользователя (DssUserId). DssUserId используется при вызове любых методов Сервиса Управления Пользователями:
Вызывающая система может сохранить DssUserId. Это позволит ускорить последующие обращения к Сервису Управления Пользователями, так как не потребуется получать DssUserId повторно.
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | invalid_identifiers | Переданный идентификатор запрещённый на DSS. |
| 400 | invalid_phone | Пользователь с указанным номер телефона уже зарегистирован. |
| 400 | invalid_email | Пользователь с указанным email уже зарегистирован. |
| 400 | invalid_login | Пользователь с указанным логином уже зарегистирован. |
| 500 | An error has occurred | 1. В поле Login указан номер телефона или email. 2. Неверно сформирован email. 3. Неверно сформирован номер телефона. |
Назначение метода первичной аутентификации
После регистрации логина пользователя необходимо назначить метод первичной аутентификации. Пользователю может быть назначен один или несколько методов первичной аутентификации:
| Метод | Описание |
|---|---|
| /user/ | Только идентификация |
| /user/ | Аутентификация по паролю |
| /user/ | Аутентификация по сертификату |
| /user/ | Аутентификация через сторонний Центр Идентификации |
Чаще всего при использовании myDSS в качестве метода первичной аутентификации назначают «Только идентификация».
Внимание!
Назначаемый метод аутентификации должен быть разрешён на DSS. Включить или отключить метод аутентификации должен Администратор на сервере DSS.
Разрешить/запретить метод аутентификации можно на Сервере DSS командами:
Внимание!
Совместное включение методов idonly и password допустимо, но использоваться будет метод «Только идентификация».
Примеры запросов
Назначение метода первичной аутентификации «Только идентификация»
Пример ответа
Назначение метода аутентифиации не имеет возвращаемого значения.
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | wrong_operation | Метод аутентификации уже назначен. |
| 400 | invalid_authn_method | Метод аутентификации запрещён на сервере DSS. |
| 404 | user_not_found | Пользователь не найден. |
Получение QR-кода с ключом аутентификации myDSS
Перед назначением пользователю метода аутентификации myDSS необходимо получить QR-код, содержащий ключ аутентификации пользователя. QR-код должнен быть передан пользователю. Отсканировав QR-код пользователь загрузит ключ аутентификации в мобильное приложение myDSS.
Ключ аутентификации, передаваемый в QR-коде, может быть защищён на коде активации. Код активации передаётся пользователю в SMS или email сообщении.
Требование защиты ключа аутентификации на коде активации настраивается Администратором на сервере DSS и распространяется на всех пользователей.
Изменить длину кода активации может Администратор DSS выполнив команду в консоли PowerShell:
Примечание
Для отправки кода активации в SMS или Email Администратору необходимо подключить и настроить соответствующий модуль оповещения на сервере DSS.
Примеры запросов
В параметре UserContactInfo передаётся адрес электронной почты или номер телефона.
Если используется собственное мобильное приложение на основе PayControl SDK, то ключ аутентификации можно запросить в виде XML. Для получения ключа аутентификации в виде XML в запросе необходимо указать параметр NeedXmlKeyInfo со значением true и код активации KeyInfoPinCode
Пример ответа
Сервер возвращает следующие данные:
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | invalid_contact_info | 1. Требуется предоставить номер телефона или email для отправки кода активации. 2. Указан неверный тип данных для отправки кода активации. |
| 404 | user_not_found | Пользователь не найден. |
| 400 | wrong_operation | Попытка повторно получить QR-код. Для обнолвения ключа пользователя необходимо отправить PATCH запрос. |
| 500 | An error has occurred | 1. Метод аутентификации myDSS запрещен на сервере DSS. 2. Истекла лицензия на myDSS на сервере DSS. |
Назначение myDSS в качестве второго фактора аутентификации
После того как пользователю создан ключ аутентификации необходимо назначить метод аутентификации myDSS.
Пример запроса
Внимание!
Значение параметра level должно быть равно 1
Пример ответа
Метод не имеет возвращаемого значения.
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | invalid_authentication_scheme | Указан неверный уровень метода аутентификации. |
| 404 | user_not_found | Пользователь не найден. |
| 400 | authn_method_not_confirmed | Попытка назначить метод аутентификации не получив QR-код. |
Назначение операций, требующие подтверждения через myDSS
После получения QR-кода и назначения пользователю myDSS необходимо задать список операций требующий подтверждения с помощью myDSS.
Про типы операций, для которых можно настроить подтверждение, и их идентифкаторы можно прочитать на странице Типы Операций. В запросе необходимо перечислить коды операций, которые будет подтверждать пользователь.
Пример запроса
Пример ответа
Метод не имеет возвращаемого значения
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | invalid_authentication_scheme | Указан неверный уровень метода аутентификации. |
| 404 | user_not_found | Пользователь не найден. |
| 400 | wrong_operation | Оператору запрещено изменять список операций, требующих подтверждения. |
Обновление ключа аутентификации пользователя
Ключ аутентификации пользователя имеет ограниченный срок действия. Ключ аутентификации необходимо переодически обновлять. Процедура смены ключа аналогична получению первого ключа аутентификации
Примечание
Флаг DelayedActivation отвечает за режим активации нового ключа пользователя:
Пример запроса
Пример запроса с отложенной активацией ключа
Пример ответа
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | invalid_authentication_scheme | Указан неверный уровень метода аутентификации. |
| 404 | user_not_found | Пользователь не найден. |
| 400 | wrong_operation | Оператора запрещено изменять список операций, требующий подтверждения. |
Повторная отправка кода активации пользователю
Если ключ аутентификации уже назначен пользователю и защищён на коде активации, то можно сделать повторную отправку кода активации ключа.
Требование защиты ключа аутентификации на коде активации настраивается Администратором на сервере DSS и распространяется на всех пользователей.
В параметре UserContactInfo передаётся адрес электронной почты или номер телефона пользователя.
Пример запроса
Метод не имеет возвращаемого значения.
Пример ответа
Типовые ошибки
| HTTP-код | Ошибка | Описание |
|---|---|---|
| 400 | invalid_contact_info | 1. Нет возможности отправить вторую часть ключевой информации: не задана контактная информация пользователя. 2. Неизвестный тип контактной информации: «EmailAddrfess». |
| 400 | wrong_operation | Код активации не требуется в соответствии с настройками сервиса. |
| 404 | user_not_found | Пользователь не найден. |
Поиск пользователя
Сервис Управления пользователями предоставляет несколько возможностей поиска пользователя:
По логину, номеру телефона или email
Пример запроса
Тип ключа поиска может принимать значения (значение параметра type ):
Пример ответа
По логину пользователя во внешнем ЦИ
Пример запроса
Пример ответа
По идентификатору DssUserId
Пример запроса
Пример ответа
Расширенный поиск
Расширенный поиск позволяет применять различные фильтры для поиска пользователей. Результатом выполнения метода может быть группа пользователей, отвечающая параметрам фильтра.
Поиск пользователей можно выполнить по одному или нескольким параметрам:
| Параметр | Код | Описание |
|---|---|---|
| Login | 0 | Логин пользователя |
| PhoneNumber | 1 | Номер телефона |
| 2 | Адрес электронной почты | |
| CreateDate | 3 | Дата создания учётной записи |
| GroupId | 4 | Идентификаторы группы пользователя |
Код параметра указывается в поле Column
Операции сравнения могут быть следующих типов:
| Тип | Код | Описание |
|---|---|---|
| Equal | 0 | Строгое равенство |
| NotEqual | 1 | Не равно |
| Like | 2 | Содержит |
| Greater | 3 | Больше |
| Less | 4 | Меньше |
Код операции указывается в поле Operation
Тип cравнения Like определяет, совпадает ли указанная символьная строка с заданным шаблоном. Шаблон может включать обычные символы и символы-шаблоны. Во время сравнения с шаблоном необходимо, чтобы его обычные символы в точности совпадали с символами, указанными в строке. Символы-шаблоны могут совпадать с произвольными элементами символьной строки.
Поддерживаются следующие символы шаблоны:
| Символ-шаблон | Описание | Пример |
|---|---|---|
| % | Любая строка, содержащая ноль или более символов. | %вано% |
| (подчеркивание) | Любой одиночный символ. | _етров |
| [ ] | Любой одиночный символ, содержащийся в диапазоне ([a-f]) или наборе ([abcdef]). | [Л-С]омов |
| [^] | Любой одиночный символ, не содержащийся в диапазоне ([^a-f]) или наборе ([^abcdef]). | ‘ив[^а]% |
Параметры StartPosition и EndPosition определяют начальную и конечную позицию из итоговой выборки. Данные параметры могут быть использованы для постраничной выборки пользователей
При поиске пользователей по времени создания значение фильтра должно иметь следующий формат: yyyy-MM-ddThh:mm:ss





