Приложение N 20. Рекомендации по заполнению полей табличной формы заявления на регистрацию Пользователя УЦ | ГАРАНТ

приложение n 12. формат и структура сертификата ключа подписи | гарант

приложение n 20. рекомендации по заполнению полей табличной формы заявления на регистрацию пользователя уц | гарант

приложение. требования к форме квалифицированного сертификата ключа проверки электронной подписи | гарант

------------------------------

------------------------------

Certificate ::= SIGNED { SEQUENCE {

    version                 [0]     Version DEFAULT v l,

    serialNumber                    CertificateSerialNumber,

    signature                       AlgorithmIdentifier,

    issuer                          Name,

    validity                        Validity,

    subject                         Name,

    subjectPublicKeyInfo            SubjectPublicKeyInfo,

    issuerUniqueIdentifier  [1]     IMPLICIT UniqueIdentifier OPTIONAL,

    subjectUniqueIdentifier [2]     IMPLICIT UniqueIdentifier OPTIONAL,

    extensions              [3]     Extensions OPTIONAL } }

SIGNED { ToBeSigned } ::= SEQUENCE {

    toBeSigned                      ToBeSigned,

    COMPONENTS OF                   SIGNATURE { ToBeSigned } }

SIGNATURE { ToBeSigned } ::= SEQUENCE {

    algorithmIdentifier             AlgorithmIdentifier,

    encrypted                       ENCRYPTED-HASH { ToBeSigned } }

ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING (CONSTRAINED BY

                                       { ToBeSigned }).

------------------------------

------------------------------

------------------------------

------------------------------

KeyUsage ::= BIT STRING {

    digitalSignature      (0),

    contentCommitment     (1),

    keyEncipherment       (2),

    dataEncipherment      (3),

    keyAgreement          (4),

    keyCertSign           (5),

    cRLSign               (6),

    encipherOnly          (7),

    decipherOnly         (8)}.

IssuerSignTool ::= SEQUENCE {

    signTool            UTF8String SIZE(1.200),

    cATool              UTF8String SIZE(1..200),

    signToolCert        UTF8String SIZE(1.. 100),

    cAToolCert          UTF8String SIZE(1.100) }.

Как делегировать полномочия на ou

При делегировании полномочия на OU другим пользователям желательно предоставлять права не непосредственно учетным записям пользователям, а административным группам. Таким образом, чтобы предоставить права на OU новому пользователю достаточно добавить его в предварительно созданную доменную группу.

Для делегирования щелкните ПКМ по OU и выберите пункт Delegate Control.

В мастере делегирования управления выберите группу пользователей, которым нужно предоставить доступ.

Затем выберите задачи администрирования, которые нужно делегировать.

В данном примере мы делегировали членам группы AccountOperators полномочия на смену паролей всех пользователей в контейнере Belarus.

Как создать ou с помощью powershell

Ранее для создания OU в AD можно было использовать консольную утилиту dsadd. Например, для создания OU в домене можно выполнить такую команду:

dsadd ou “ou=Kazahstan,dc=vmblog,dc=ru”

В Windows Server 2008 R2 появился отдельный модуль для работы с AD: Active Directory module для Windows PowerShell (входит в состав RSAT). Для создания Organizational Unit можно использовать командлет New-ADOrganizationalUnit. Например, создадим новый OU с именем Belarus в корне домена:

New-ADOrganizationalUnit -Name “Belarus”

Чтобы создать новый OU в существующем контейнере, выполните команду:

New-ADOrganizationalUnit -Name Minsk -Path “OU=Belarus,DC=vmblog,DC=ru” -Description “Belarus central office ” -PassThru

Набор разрешенных символов в скп

В СКП любой используемый текст должен быть представлен в формате UNICODE, где каждый символ кодируется двумя байтами (16 бит). Для непосредственной записи в СКП текст должен быть закодирован по стандарту UTF-8 (RFC 3629).

При наборе текста для СКП разрешается использовать только символы, UNICODE коды которых приведенные в табл. 2.

При извлечении и декодировании текста из СКП для дальнейшей его обработки в программном обеспечении (в том числе и в ПО СИОЭД) код каждого символа должен быть дополнительно приведен к однобайтовому коду (8 бит) в кодовой странице Windows-1251, в соответствии с кодами в табл. 2.

Символы, UNICODE коды которых не соответствуют табл. 2, использовать не разрешается.

Таблица 2

Набор разрешенных символов для текстов в скп(все коды даны в шестнадцатеричной системе счисления)

Приложение 11

Рис. 1. схема доверия скп и сос в ируц

СКП делятся на 2 основных типа:

1. СКП, которые могут быть издателями других СКП и СОС.

2. Конечные СКП пользователей.

Все СКП делятся на 4 группы:

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

2. Кросс СКП УЦ ФНС России – кросс, выданный организатором сети ДУЦ для СКП УЦ ФНС России. УЦ ФНС России выдает СКП НО (для систем ГНИВЦ ПРИЕМ, ГНИВЦ ПРИЕМ Регион):

– СОЭД.

– САОЭД.

– Налоговый инспектор.

– АРМ ДиС.

Примечание. Сам СКП УЦ ФНС России в СИОЭД использовать запрещено.

3. Кросс СКП ДУЦ – кросс, выданный организатором сети ДУЦ для СКП УЦ ДУЦ, который является издателем СКП НП.

Примечание. Сам СКП УЦ ДУЦ в СИОЭД использовать запрещено.

4. СКП ключевых узлов СИОЭД – конечные СКП.

– Эти СКП не могут быть издателями других СКП.

– Эти СКП могут быть изданы только на Корневом СКП Организатора Сети ДУЦ.

5. СКП НП – конечные СКП.

– СКП для ЮЛ, ИП или УП.

– Эти СКП не могут быть издателями других СКП.

– Эти СКП могут быть изданы на Корневом СКП Организатора Сети ДУЦ или на СКП УЦ ДУЦ, кросс которого используется в СИОЭД.

Все СКП ключевых узлов СИОЭД выдаются только Организатором Сети ДУЦ:

– Оператор ИРУЦ.

– Спецоператор.

– Веб-сервер ИРУЦ.

– Сервер регистрации ИРУЦ.

– ЦСДИ.

Конечные СКП НП выдаются ДУЦ. При необходимости СКП НП может выдавать Организатор Сети ДУЦ.

Справочник кодов регионов

Приложение 8

Структура единого oid

1.2.643.3.<Координирующая организация>.<Эмитент1>. <эмитент2>.<Роль владельца СКП в информационных системах ФНС России (НП, НО, уполномоченный представитель НП, СпецОператор и т.д.)>.<Квалификация подписи (директор, бухгалтер, инспектор НО и т.д.)>.< Пользователь сервисов системы >.<Другие назначения1>.<другие назначения2>

N арки

1.- 4. зафиксировано 1.2.643.3

5. Координирующая организация – ФНС или Организатор Сети ДУЦ

6. Эмитент1 – ДУЦ. Содержит идентификатор ДУЦ, формируемый, как 1000 N паспорта ДУЦ. УЦ ГНИВЦ ФНС России имеет идентификатор 1000.

7. эмитент2 – УЦ, подчиненный ДУЦ

8. Роль владельца СКП в информационных системах ФНС – НП, инспектор НО, уполномоченный представитель НП, ИРУЦ, СОЭД, САОЭД, СпецОператор и т.д.

9. Квалификация подписи – 1-я подпись (директор, заместитель директора и т.д.), 2-я подпись (главный бухгалтер, бухгалтер и т.д.), 1-я и 2-я подпись, право подписи отсутствует – только шифровать и/или отправка, квалификация подписи не установлена и т.д.

10. Пользователь сервисов системы – сервис ИОН on-line (да или нет), др. сервисы

11. Другие назначения1 – зарезервировано

12. другие назначения2 – зарезервировано

Если в арке N 6 стоит число меньше 1000, то эта арка – управляющая, она содержит назначение данных, которые размещены в следующей арке (N 7), если в арке N 7 число меньше 1000, то арка – управляющая и содержит тип данных, которые размещены в следующей арке (N 8) и т.д. В случае с управляющими арками приведенная в начале приложения схема OID применяться не может.

Если арка N 6 содержит единицу, то арка – управляющая, указывает на то, что в следующей арке будет указан OID поля сертификата ключа подписи.

Примеры использования шестой арки:

1.2.643.3.ххх.1001 – показывает, что OID используется ДУЦ с паспортом N 1.

1.2.643.3.ххх.1.1 – показывает, что это OID поля INN (п.п. 7.2).

Требования к построению цепочек доверия скп и сос

Цепочки доверия СКП и СОС строятся по равенствам данных в расширении subjectKeyIdentifier издателя и authorityKeyIdentifier в изданном СКП или СОС.

Если в расширении authorityKeyIdentifier содержатся заполненные поля authorityCertIssuer и authorityCertSerialNumber, то дополнительно выполняется проверка соответствия DN из поля authorityCertIssuer атрибуту issuer из СКП издателя и соответствие серийного номера из поля authorityCertSerialNumber серийному номеру СКП издателя.

Приложение 1

Требования к скп

Ключевая пара СКП должна соответствовать стандарту ГОСТ Р 34.10-2001.

Поля СКП должны заполняться в соответствии рекомендациям IETF RFC5280 и ITU-T x.509 (если не указано другое).

Для любого текста, используемого в СКП, разрешается использовать набор символов из Приложение 10 #(если не указано другое).

Каждый СКП должен содержать следующие атрибуты и расширения:

1. Версия СКП (version) – должна быть не ниже 3.

2. Серийный номер (serialNumber) – уникальная последовательность в рамках одного УЦ, не более 160 бит.

3. Алгоритм подписи (signature) – в поле algorithm должен содержаться идентификатор алгоритма подписи ГОСТ Р 34.11-94/34.10-2001 (OID.1.2.643.2.2.3, в соответствии с RFC4491).

4. DN издателя СКП (issuer) – данные из поля субъект СКП издателя.

Для Корневого СКП Организатора Сети ДУЦ значение DN издателя должно быть равно DN субъекта.

5. Дата и время начала действия СКП (notBefore).

6. Дата и время окончания действия СКП (notAfter).

7. В DN субъекта СКП (subject) должны быть заполнены поля:

7.1. CN (OID.2.5.4.3) – обязательно к заполнению – для конечных СКП должно быть записано ФИО владельца СКП (Приложение 1).

Примечание. В СКП центров сертификации, а также СКП ключевых узлов СИОЭД (веб-сервер ИРУЦ, сервер регистрации ИРУЦ, АРМ ДиС, ЦСДИ, и т.д.), допускается указывать псевдоним владельца СКП (Приложение 2).

7.2. INN (OID.1.2.643.3.ххх.1.1, OID должен быть зарегистрирован) – обязательно к заполнению. Должен быть записан один из вариантов:

– ИНН организации, сотрудником которой является владелец СКП.

– ИНН физического лица владельца СКП.

– при отсутствии ИНН – 0 (цифра ноль 0x30 Код Windows-1251).

7.3. OU (OID.2.5.4.11) – обязательно к заполнению. Должен быть записан один из вариантов:

– подразделение организации, сотрудником которого является владелец СКП (Приложение 3).

– при отсутствии – 0 (цифра ноль 0x30 Код Windows-1251).

7.4. E (OID.1.2.840.113549.1.9.1) – обязательно к заполнению. Должен быть записан один из вариантов:

– действующий адрес электронной почты владельца СКП (Приложение 4).

– при отсутствии – 0 (цифра ноль 0x30 Код Windows-1251).

7.5. O (OID.2.5.4.10) – обязательно к заполнению. Должен быть записан один из вариантов:

– для ЮЛ или ИП должно быть записано краткое название ЮЛ или ИП – владельца СКП в соответствии с ЕГРЮЛ (Приложение 5).

– при отсутствии – 0 (цифра ноль 0x30 Код Windows-1251).

7.6. C (OID.2.5.4.6) – обязательно к заполнению – должен быть записан двух символьный код страны, две прописные латинские буквы в соответствии с ISO 3166 (ISO 3166-1 alpha-2).

7.7. L (OID.2.5.4.7) – обязательно к заполнению. Должен быть записан один из вариантов:

– название города или населенного пункта, где зарегистрированы ЮЛ, ИП или ФЛ (Приложение 6).

– при отсутствии – 0 (цифра ноль 0x30 Код Windows-1251).

7.8. S (OID.2.5.4.8) – обязательно к заполнению. Должен быть записан один из вариантов:

– название региона, где зарегистрированы ЮЛ, ИП или ФЛ (Приложение 7).

– при отсутствии – 0 (цифра ноль 0x30 Код Windows-1251).

7.9. T (OID.2.5.4.12) – обязательно к заполнению. Должен быть записан один из вариантов:

– для ЮЛ должность владельца СКП (Приложение 9).

– при отсутствии – 0 (цифра ноль 0x30 Код Windows-1251).

7.10. SN (OID.2.5.4.5) – не обязательно к заполнению – указывается серийный номер имени владельца сертификата (для обеспечения различимости имен владельцев СКП, если их Фамилии Имя и Отчество полностью совпадают). Для заполнения использовать цифры: 1, 2, и т.д.

Примечание. Каждое поле в DN, описанное в п.п. 7.1 – 7.10 допускается использовать только 1 раз. УЦ могут использовать дополнительные поля, если это не противоречит RFC, однако эти поля не будут обрабатываться в ИРУЦ.

8. Открытый ключ (subjectPublicKeyInfo):

8.1. Атрибут AlgorithmIdentifier поле algorithm – идентификатор алгоритма открытого ключа по ГОСТ Р 34.10-2001 (OID.1.2.643.2.2.19, в соответствии с RFC4491).

8.2. Атрибут AlgorithmIdentifier поле parameters – два параметра с OID.1.2.643.2.2.36.0 и OID.1.2.643.2.2.30.1 (в соответствии с RFC4491).

8.3. Для Корневого СКП Организатора Сети ДУЦ и Кросс СКП ДУЦ значение поля parameters формируется в соответствии с RFC4491.

8.4. Атрибут subjectPublicKey – открытый ключ.

9. Расширение extKeyUsage (OID.2.5.29.37) – расширенное использование ключа – должно содержать идентификатор использования “Защищенная электронная почта” (OID.1.3.6.1.5.5.7.3.4). Так же сюда могут быть добавлены другие идентификаторы использования по усмотрению ДУЦ, но при этом это расширение должно содержать не более 100 элементов.

Для Корневого СКП Организатора Сети ДУЦ и Кросс СКП ДУЦ расширение extKeyUsage может отсутствовать.

10. Расширение subjectKeyIdentifier (OID.2.5.29.14) – идентификатор ключа субъекта – должно содержать идентификатор открытого ключа в СКП в виде уникальной последовательности, формируемой в соответствие с RFC.

11. Расширение authorityKeyIdentifier (OID.2.5.29.35 или OID.2.5.29.1) – идентификатор ключа центра сертификатов – должно быть заполнено поле keyIdentifier значением расширения subjectKeyIdentifier в СКП издателя. OID.2.5.29.1 является устаревшим, для всех вновь выдаваемых СКП его использовать не разрешается.

Примечание. Для Корневого СКП Организатора Сети ДУЦ расширение authorityKeyIdentifier может отсутствовать.

Поля authorityCertIssuer и authorityCertSerialNumber могут отсутствовать в расширении, но если они заполнены, то должны содержать:

– authorityCertIssuer – DN Субъекта из СКП Издателя.

– authorityCertSerialNumber – Серийный номер из СКП издателя.

12. Расширение keyUsage (OID.2.5.29.15) – использование ключа:

12.1. Для конечных СКП должны быть установлены в 1 биты:

– 0 (цифровая подпись) или 1 (неотрекаемость) или оба, и 2 (шифрование ключей);

– биты 5 (подпись СКП) и 6 (подпись СОС) должны быть установлены в 0.

12.2. Для Корневого СКП Организатора Системы и Кросс СКП ДУЦ биты 5 (подпись СКП) и 6 (подпись СОС) должны быть установлены в 1.

12.3. Остальные биты должны заполняться в соответствии с рекомендациями RFC.

Требования к скп и сос

Доверие СКП (рис. 1) строится от одного корневого СКП – СКП организатора сети ДУЦ.

                                           ----------------------.        ---------.
                                           .                     .        .        .
----------.      ---------------.          .    Корневой СКП     .------->.  СОС   .
.         .      .   Кросс СКП  .<---------                      .        .        .
.   СОС   .<-----  УЦ ФНС России.          L-T-------T----------T-        L---------
L----------      LT--------------            .       .          .
                  .                          .       .          .
                  .                          .       .          .
                  .                          .       .          .
                  .                          .       .          .
                  .                          .       .          .
                  ў                          ў       .          ў
  ------------------.  -------------------------.    .     -----------.         -------.
  .     СКП НО      .  .СКП ключевых узлов СИОЭД.    .     .Кросс СКП  -------> .      .
  .- СОЭД           .  .- Оператор ИРУЦ         .    .     .   ДУЦ    .         . СОС  .
  .- САОЭД          .  .- Спецоператор          .    .     L----T------         L-------
  .- Инспектор      .  .- Веб-сервер ИРУЦ       .    .          .
  .- АРМ ДиС        .  .- Сервер регистрации    .    .          .
  .                 .  .  ИРУЦ                  .    .          .
  .                 .  .- ЦСДИ                  .    .          .
  L------------------  L-------------------------    .          .
                                                     ў          ў
                                              --------------. -----------.
                                              .             . .          .
                                              .   СКП НП    . .  СКП НП  .
                                              L-------------- L-----------

Требования к сос

Поля СОС должны заполняться в соответствии рекомендациям IETF RFC5280 и ITU-T x.509 (если не указано другое).

Размер файла СОС должен быть не более 250 Кбайт.

Для любого текста, используемого в СОС, разрешается использовать набор символов из Приложение 10 #.

Каждый СОС должен содержать следующие атрибуты и расширения:

1. Версия (version) – версия должна быть 2.

2. Издатель (issuer) – данные из поля субъект СКП издателя.

3. Дата издания СОС (thisUpdate).

4. Дата издания следующего СОС (nextUpdate).

5. Алгоритм подписи (signature) – должен содержать идентификатор алгоритма подписи ГОСТ Р 34.11-94/34.10-2001 (OID.1.2.643.2.2.3 в соответствии с RFC4491).

6. Расширение authorityKeyIdentifier (OID.2.5.29.35 или OID.2.5.29.1) – идентификатор ключа центра сертификатов – должно быть заполнено поле keyIdentifier значением расширения subjectKeyIdentifier в СКП издателя. OID.2.5.29.1 является устаревшим, для всех вновь выдаваемых СКП его использовать не разрешается.

Поля authorityCertIssuer и authorityCertSerialNumber могут отсутствовать в расширении, но если они заполнены, то должны содержать:

– authorityCertIssuer – DN Субъекта из СКП Издателя.

– authorityCertSerialNumber – Серийный номер из СКП издателя

7. Номер СОС cRLNumber (OID.2.5.29.20) – порядковый номер, начинающийся с 1 и увеличивающийся каждый раз на 1 при выпуске нового СОС. Допускается формирование значения номера СОС и дельта СОС выполнять по правилу, описанному в rfc 5280: каждый последующий номер должен быть больше предыдущего и длинна номера, должна быть не более 160 бит.

8. Индикатор дельты СОС deltaCRLIndicator (OID.2.5.29.27) критическое расширение – если в СОС присутствует это расширение, то СОС считается дельтой. Должен содержать номер равный или меньший, чем номер основного СОС из расширения cRLNumber.

Остальные расширения могут содержать любые данные, сформированные в соответствии с рекомендациями IETF RFC и ITU-T.

Требованияк сертификату ключа подписи и списку отозванных сертификатов для обеспечения единого пространства доверия сертификатам ключей электронной цифровой подписи(утв. приказом федеральной налоговой службы от 2 июля 2009 г. n мм-7-6/353@)

C – country – страна

CN – common name – поле в DN – общее имя = ФИО или псевдоним.

DN – distinguished name – расширение в СКП, в которое помещается отличительное имя владельца СКП, состоящее из нескольких полей.

E – e-mail – поле в DN – электронная почта.

L – locality – место расположения, например, город.

O – organization – поле в DN – организация.

OU – organization unit – поле в DN – подразделение организации.

S – state or province – область, регион.

T – title – должность,

АРМ ДиС (Суппорт) – АРМ диагностики и сопровождения, предназначен для мониторинга серверов обмена электронными документами ПК ГНИВЦ ПРИЕМ и ГНИВЦ ПРИЕМ Регион (ранее использовался для регистрации абонентов).

ДУЦ – доверенный удостоверяющий центр.

Кросс – СКП, выпущенный Организатором Сети ДУЦ для уполномоченного лица ДУЦ. Этот СКП используется для формирования доверительных отношений к СКП пользователей, изданных ДУЦ.

ИНН – индивидуальный номер налогоплательщика.

ИП – индивидуальный предприниматель.

ИРУЦ – информационный ресурс Удостоверяющего центра Организатора Сети Доверенных удостоверяющих центров.

НБО – налоговые декларации и бухгалтерская отчетность.

НО – налоговый орган.

НП – налогоплательщик.

САОЭД – сервер автоматической обработки электронных документов.

СИОЭД – система информационного обмена электронными документами с электронной цифровой подписью по телекоммуникационным каналам связи.

СКП – сертификат ключа подписи.

СОС (CRL) – список отозванных сертификатов.

СОЭД – сервер обмена электронными документами.

Спецоператор – специализированный оператор связи.

УП – уполномоченный представитель налогоплательщика.

УЦ – удостоверяющий центр.

ФИО – фамилия имя отчество.

ФЛ – физическое лицо.

ЦСДИ – центр сбора диагностической информации.

ЮЛ – юридическое лицо.

Шаг 1. предварительные изыскания и проверка гипотезы

Нет, серьезно, это правда, что в сертификате X.509 есть СНИЛС? Для проверки найдем образец — просим помощи у Яндекса по запросу «реестр выданных квалифицированных сертификатов», на первой же странице выдачи находим

, скачиваем первый попавшийся сертификат (под номером 10842) —

Открываем сертификат с помощью стандартного средства просмотра OC Windows и находим в описании субъекта подозрительно похожую строку с объектным идентификатором 1.2.643.100.3, состоящую из 11 цифр.

Лирическое отступление

О том, что такое объектный идентификатор (OID) вообще, лучше всего почитать здесь. Как используются объектные идентификаторы в описании структуры сертификатов X.509 — смотрим Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509).

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

Итак, поставленная задача потенциально выполнима, СНИЛС в квалифицированном сертификате есть. Идем дальше.

Шаг 3. разработка парсера x.509 сертификата на с#

Так сложилось, что разработка у нас ведется на C#, поэтому и пример парсера будет на C#, ничего личного и никакого холивара.

Для простоты формализуем задачу следующим образом. Дано: файл квалифицированного сертификата в системе ограничений CER (Canonical encoding rules). Требуется: разобрать (распарсить) сертификат и извлечь значения ИНН, СНИЛС и ОГРН из поля субъекта (Subject).

Для первых набросков обращаемся к возможностям пространства имен System.Security.Cryptography.X509Certificates:

using System.IO;
using System.Security.Cryptography.X509Certificates;
using System.Diagnostics;

namespace X509Parser
{
    class Program
    {
        static void Main(string[] args)
        {
            string fileName = @"c:Komarov_Aleksey_Petrovich_2021-03-31_a2ba20c4.cer";

            X509Certificate cert = new X509Certificate(File.ReadAllBytes(fileName));
            
            Debug.Print("Серийный номер: {0}", cert.GetSerialNumberString());
            Debug.Print("Дата окончания действия квалифицированного сертификата: {0}", cert.GetExpirationDateString());
            Debug.Print("Субъект: {0}", cert.Subject);
        }
    }
}

На выходе получаем:

Подведение итогов

Итак, подытоживая проделанную работу, мы:

1. Разобрались со структурой квалифицированных сертификатов X.509, которые попадают в сферу действия ФЗ «Об электронной подписи».
2. Узнали, что Приказ ФСБ РФ № 795 определяет дополнительные атрибуты — ИНН, СНИЛС, ОГРН и другие. Здесь же указываются соответствующие объектные идентификаторы (OID).
3. Разработали парсер сертификатов X.509 на C# с возможностью извлечения полей и их атрибутов с заданными объектными идентификаторами. Библиотека BouncyCastle добавила решению простоты.

В расчетах по времени произошла ошибка — вместо запланированных нескольких часов пришлось разбираться весь день. И еще два дня на подготовку исследования для Хабра.

Спасибо за внимание!