- Внешние провайдеры
- Внутренние провайдеры
- Дополнительная информация
- Интерфейс ssf
- Криптопро ssf — купить лицензию криптопро ssf по выгодной цене в ростове-на-дону на официальном сайте
- Формирование/проверка эцп на сервере
- Формирование/проверка эцп средствами внешнего крипто-провайдера
- Электронная подпись в sap – это просто
Внешние провайдеры
Внешние провайдеры представляют собой ПО расположенное на уровне сервера представления. Доступ к ним может осуществляться двумя способами:
- Через RFC вызов SSF провайдера на локальной машине
- Через ActiveX элемент и вызов провайдера MS Crypto-API
В любом случае доступ осуществляется только в диалоговом режиме. SSF провайдер это библиотека с заранее описанными функциями, которая создается на базе предоставляемой SAP спецификации.
Внутренние провайдеры
Внутренние провайдеры представляют собой набор библиотек расположенных на уровне сервера приложений. Компания SAP предоставляет два внутренних крипто-провайдера (ABAP стек):
- SAPSECULIB – библиотека поддерживает DSA алгоритм и может быть использована только для формирования/проверки ЭЦП (т.к. сам алгоритм не предназначен для шифрования);
- SAPCRYPTOLIB – поддерживает как DSA, так и RSA алгоритм, с возможностью выбора размера ключа. Используется как для формирования/проверки ЭЦП, так и для шифрования (RSA);
Обе библиотеки не позволяют использовать криптографическое железо такое как: смарт-карты, токены и прочее, секретные ключи в обоих случаях будут находиться в специальных защищенных хранилищах на сервере приложения. Для возможности использования железа, необходимо использовать внешние провайдеры.
Библиотека SAPSECULIB при необходимости может быть заменена SAPCRYPTOLIB, для чего есть соответствующие ноты.
Дополнительная информация
Начиная с версии 1.0.0, в OpenSSL включили в состав утилиты для работы с алгоритмами ГОСТ, благодаря чему мы можем формировать и верифицировать квалифицированные ЭЦП из ABAP, взаимодействуя с OpenSSL, например, через файловый интерфейс. Более подробную информацию по поддержке ГОСТ можно найти как на официальном сайте, так и на других, например, тут.
Интерфейс ssf
Интерфейс к SSF предоставляет набор модулей через которые могут быть вызваны функции крипто-провайдеров, основные из них описаны далее:
| ФМ | Описание |
| SSF_*VERSION | Получает версию крипто-провайдера |
| SSF_*QUERYPROPERTIES | Функция возвращает значения поддерживаемых провайдером свойств: форматы шифрования, хеш-алгоритмы и т.п. |
| SSF_*SIGN | Формирование ЭЦП |
| SSF_*VERIFY | Проверка ЭЦП |
| SSF_*ENVELOPE | Формирование зашифрованного сообщения |
| SSF_*DEVELOPE | Расшифровка сообщения |
| SSF_*ADDSIGN | Добавляет подпись к уже подписанному сообщению. |
| SSF_*DIGEST | Получение хеша |
| SSF_GET_PARAMETER | Получение параметров SSF приложения |
| SSFS_CALL_CONTROL | Вызов диалога подписания через Microsoft Crypto API |
* — при работе с внутренними провайдерами необходимо заменить * на KRN_, например: SSF_KRN_VERSION:
При использовании интерфейса SSF зачастую приходится передавать множество параметров, таких как:
- Используемый хеш-алгоритм,
- Необходимость включения сертификата в подпись,
- Необходимость включения данных в подпись,
- Алгоритм кодировки и др.
Для разных приложений, данные параметры могут различаться, чтобы не хранить их как константы, можно воспользоваться специальной настройкой. Для этого, в первую очередь, необходимо создать SSF приложение, делается это через ракурс ведения (SE16) к таблице SSFAPPLIC, создадим новую запись:
Значение X отвечает за возможность определения параметра для приложения, если оставить значение пустым, для текущего приложения нельзя будет настроить указанный параметр. Сохраним приложение, проставив везде X.
Для его настройки необходимо перейти в транзакцию STRUST и нажать F9 (Среда -> Ведение параметров SSF), зададим следующие параметры:
Получить значения параметров можно через ФМ SSF_GET_PARAMETER. Описание большинства из них приводится во встроенной документации.
Кроме параметров передаваемых непосредственно в интерфейсы SSF, тут так же имеется информация о файле профиле SSF в котором система будет получать закрытые ключи, а так же личной адресной книге, где для верификации подписей должны храниться открытые ключи (сертификаты). В нашем случае это будет один и тот же файл.
Криптопро ssf — купить лицензию криптопро ssf по выгодной цене в ростове-на-дону на официальном сайте
Осуществляется транспортной компанией, курьером или в пункты самовывоза от 4 до 9 рабочих дней после оплаты или подтверждения заказа.
Электронные лицензии отправляются на электронную почту заказчика.
Точная стоимость и срок доставки в Ростове-на-Дону рассчитываются при оформлении заказа.
Формирование/проверка эцп на сервере
В данном примере мы сформируем ЭЦП средствами SAPCRYPTOLIB на сервере приложений, а так же выполним её верификацию.
Прежде чем вызывать функции SSF необходимо получить пару – закрытый/открытый ключ и положить их в хранилище (PSE файл).
Для генерации пары воспользуемся OpenSSL – набор открытых инструментов для криптографии. В статье я не буду подробно останавливаться на инструменте OpenSSL, будут лишь приведены необходимые команды.
И так, создаем приватный ключ:
На данном шаге необходимо будет указать пароль для ключа. Для получения DSA ключа можно воспользоваться утилитой gendsa.
Сформируем открытый ключ:
Далее создадим сертификат, но прежде сформируем файл конфигурации, на базе которого будет создан сертификат, запишем в него следующее:
Команда на создание сертификата:
Для импорта пары закрытый/открытый ключ нам понадобится файл в формате PKCS#12, для его создания выполним команду:
Для того чтобы сервер приложений мог выполнять криптографические функции ему необходимо знать как получить пары закрытых/открытых ключей, за их хранение на сервере приложения отвечает PSE файл. Следующим шагом создадим PSE файл с помощью утилиты sapgenpse. Данная утилита может быть получена на SAP Marketplace, она входит в пакет SAPCRYPTOLIB. И так, создание PSE файла:
Полученный PSE файл загрузим через транзакцию STRUST:
- Щелкнув два раза на элементе «Файл» откроется окно выбора файла, укажем наш client.pse, после чего система запросит пароль, укажем тот, что указывали при создании PSE.
- Открыв PSE на просмотр, сохраним его для ранее созданного приложения ZSSFAP: Меню -> СПП -> Сохранить как -> SSF приложение -> ZSSFAP
На данном этапе мы записали хранилище (PSE) на сервер приложений, доступ к нему можно получить по адресу указанному в серверном параметре (тр. RZ11) – «ssf*/ssfapi_lib». (На стороне SAP может быть до 3-х крипто-провайдеров, для того чтобы ими воспользоваться должны быть выполнены соответствующие настройки в параметрах сервера, которые можно найти по маске ssf*. Описание данных параметров можно найти в документации к ним).
Для тестирования ЭЦП запустим программу SSF02 и укажем следующие параметры:
Запишем в файл 123.txt любую текстовую последовательность, например: 123.
После выполнения программы мы получим файл 123.txt.sig, в котором будет содержаться цифровая подпись:
Для её верификации изменим параметры и запустим вновь:
- Выбор функции: Верифицировать
- Данные ввода: 123.sig
- Данные вывода – пусто
- Данные сравнения: 123.txt
- Личная адресная книга – PAB: SAPSSF_ZSSFAP.pse (необходима для верификации относительно сертификата (открытого ключа))
Верификация пройдена:
Кроме программы SSF02, верифицировать ЭЦП можно и внешними средствами, такими как КриптоАРМ.
Далее приводится код простой ABAP программы выполняющий формирование/проверку ЭЦП на стороне сервера приложений для текстовой строки:
PARAMETERS:p_textTYPEstringDEFAULT‘123’. DATA: gv_data TYPExstring, gv_error TYPEtext80, gt_signer LIKESTANDARDTABLEOFssfinfo, gt_sign LIKESTANDARDTABLEOFssfbin, gt_data LIKEgt_signWITHHEADERLINE, gv_sign_len LIKEssfparms—sigdatalen, gv_crc LIKEssfparms—ssfcrc, gv_datalen LIKEssfparms—indatalen. START-OF-SELECTION. CALLFUNCTION‘SCMS_STRING_TO_XSTRING’ EXPORTING text =p_text IMPORTING buffer=gv_data EXCEPTIONS failed=1 OTHERS=2. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. CALLFUNCTION‘SCMS_XSTRING_TO_BINARY’ EXPORTING buffer =gv_data IMPORTING output_length=gv_datalen TABLES binary_tab =gt_data. CALLFUNCTION‘SSF_KRN_SIGN_BY_AS’ EXPORTING ssfapplication =‘ZSSFAP’ ostr_input_data_l =gv_datalen b_detached =‘X’ b_inc_certs =‘ ‘ IMPORTING ostr_signed_data_l =gv_sign_len crc =gv_crc TABLES ostr_input_data =gt_data ostr_signed_data =gt_sign EXCEPTIONS ssf_krn_error =1 ssf_krn_noop =2 ssf_krn_nomemory =3 ssf_krn_opinv =4 ssf_krn_nossflib =5 ssf_krn_input_data_error =6 ssf_krn_invalid_par =7 ssf_krn_invalid_parlen =8 ssf_fb_input_parameter_error=9 OTHERS =10. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. IFgv_crcISNOTINITIAL. CALLFUNCTION‘SSF_ERRORMESSAGE’ EXPORTING crc =gv_crc result =0 IMPORTING errortext=gv_error EXCEPTIONS error =1 others =2. WRITE:/`Ошибка получения подписи: `,gv_error. EXIT. ENDIF. CALLFUNCTION‘SSF_KRN_VERIFY_BY_AS’ EXPORTING ssfapplication =‘ZSSFAP’ ostr_signed_data_l =gv_sign_len ostr_input_data_l =gv_datalen IMPORTING crc =gv_crc TABLES ostr_signed_data =gt_sign ostr_input_data =gt_data ostr_output_data =gt_data signer_result_list =gt_signer » Информация о подписанте EXCEPTIONS ssf_krn_error =1 ssf_krn_noop =2 ssf_krn_nomemory =3 ssf_krn_opinv =4 ssf_krn_nossflib =5 ssf_krn_input_data_error =6 ssf_krn_invalid_par =7 ssf_krn_invalid_parlen =8 ssf_fb_input_parameter_error=9 OTHERS =10. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. IFgv_crcISNOTINITIAL. CALLFUNCTION‘SSF_ERRORMESSAGE’ EXPORTING crc =gv_crc result =0 IMPORTING errortext=gv_error EXCEPTIONS error =1 others =2. WRITE:/`Ошибка сверки подписи: `,gv_error. EXIT. ENDIF. CLEAR:gv_data,p_text. CALLFUNCTION‘SCMS_BINARY_TO_XSTRING’ EXPORTING input_length=gv_sign_len IMPORTING buffer =gv_data TABLES binary_tab =gt_sign EXCEPTIONS failed =1 OTHERS =2. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. CALLFUNCTION‘SSFC_BASE64_ENCODE’ EXPORTING bindata =gv_data binleng =gv_sign_len IMPORTING b64data =p_text EXCEPTIONS ssf_krn_error =1 ssf_krn_noop =2 ssf_krn_nomemory =3 ssf_krn_opinv =4 ssf_krn_input_data_error=5 ssf_krn_invalid_par =6 ssf_krn_invalid_parlen =7 OTHERS =8. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. WRITE`ЭЦП (BASE64):`COLORCOL_HEADING. WRITE:/p_text. |
Формирование/проверка эцп средствами внешнего крипто-провайдера
Зачастую требуется обеспечить формирование квалифицированной ЭЦП, т.е. той, которая выполняется на основании закрытого ключа выданного центром сертификации прошедшим проверку соответствующими органами (ФСБ и пр.). К сожалению, как правило, такие центры оперируют алгоритмами ГОСТ, который не может быть обработан крипто-провайдерами SAP.
- Путём вызова специального диалога, который связывается с установленным в системе крипто-провайдером через Microsoft Crypto API, вызов соответствующих API реализован в ActiveX элементе.
- Путём вызова функций SSF через RFC с обращением к локальной машине пользователя.
Первый способ позволяет только получать ЭЦП относительно указанных данных. Вызов диалога осуществляется через ФМ SSFS_CALL_CONTROL:
Диалог выглядит следующим образом:
В системе есть демонстрационная программа SSFSDEMO в которой так же вызывается указанный ФМ. К сожалению данный способ весьма ограничен в настройке, нельзя, например, убрать из списка не действительные сертификаты или сертификаты не предназначенные для ЭЦП. Однако есть специальная нота, которая решает эти проблемы.
Второй способ подразумевает перед его использованием дополнительную настройку:
- На локальной машине пользователя должна быть установлена SSF библиотека.
- В используемой системе должен быть определен RFC адрес для доступа к GUI (По умолчанию это — SAP_SSFATGUI см. тр. SM59)
- На компьютере пользователя необходимо настроить путь к библиотеке SSF, чтобы SAP GUI мог вызывать её функции. Настройка выполняется в файле ssfrfc.ini. В моем случае я использую библиотеку КриптоПро SSF, и файл содержит только строку с путём к SSF библиотеке:
- Для возможности подписания/верификации крипто-провайдер должен обладать всеми нужными ему данными. Необходимо убедиться, что на локальной машине установлены нужные сертификаты. Просмотр сертификатов в Windows можно вызвать через соответствующую надстройку: Пуск -> Выполнить -> certmgr.msc.
Более подробно о настройке SSF вы можете почитать в официальной документации.
Далее приведен код простейшей ABAP программы для работы с внешним крипто-провайдером:
PARAMETERS:p_textTYPEstringDEFAULT‘123’. DATA: gv_data TYPExstring, gv_error TYPEtext80, gt_signer LIKESTANDARDTABLEOFssfinfo, gt_sign LIKESTANDARDTABLEOFssfbin, gt_data LIKEgt_signWITHHEADERLINE, gt_data_ex LIKEgt_signWITHHEADERLINE, gv_sign_len LIKEssfparms—sigdatalen, gv_crc LIKEssfparms—ssfcrc, gv_datalen LIKEssfparms—indatalen. FIELD—SYMBOLS: <gs_signer> LIKELINEOFgt_signer. START-OF-SELECTION. CALLFUNCTION‘SCMS_STRING_TO_XSTRING’ EXPORTING text =p_text IMPORTING buffer=gv_data EXCEPTIONS failed=1 OTHERS=2. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. CALLFUNCTION‘SCMS_XSTRING_TO_BINARY’ EXPORTING buffer =gv_data IMPORTING output_length=gv_datalen TABLES binary_tab =gt_data. APPENDINITIALLINETOgt_signerASSIGNING<gs_signer>. <gs_signer>—id=‘E = Sidorochkin@ocrv.RU’. CALLFUNCTION‘SSF_SIGN’ EXPORTING ssf_dest =‘SAP_SSFATGUI’ b_inc_certs =‘ ‘ b_detached =‘X’ ostr_input_data_l =gv_datalen str_hashalg =‘GOST3411’ IMPORTING ostr_signed_data_l =gv_sign_len crc =gv_crc TABLES ostr_input_data =gt_data signer =gt_signer ostr_signed_data =gt_sign EXCEPTIONS ssf_rfc_error =1 ssf_rfc_no_memory =2 ssf_rfc_get_data_error =3 ssf_rfc_send_data_error =4 ssf_rfc_signer_list_error =5 ssf_rfc_input_data_error =6 ssf_fb_input_parameter_error=7 ssf_rfc_destination_error =8 OTHERS =9. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. IFgv_crcISNOTINITIAL. CALLFUNCTION‘SSF_ERRORMESSAGE’ EXPORTING crc =gv_crc result =0 IMPORTING errortext=gv_error EXCEPTIONS error =1 others =2. WRITE:/`Ошибка получения подписи: `,gv_error. EXIT. ENDIF. CLEAR:gt_signer. CALLFUNCTION‘SSF_VERIFY’ EXPORTING ssf_dest =‘SAP_SSFATGUI’ b_inc_certs =‘ ‘ ostr_signed_data_l =gv_sign_len ostr_input_data_l =gv_datalen str_pab =» str_pab_password =» IMPORTING crc =gv_crc TABLES ostr_signed_data =gt_sign ostr_input_data =gt_data signer_result_list =gt_signer ostr_output_data =gt_data_ex EXCEPTIONS ssf_rfc_error =1 ssf_rfc_no_memory =2 ssf_rfc_get_data_error =3 ssf_rfc_send_data_error =4 ssf_rfc_input_data_error =5 ssf_fb_input_parameter_error=6 ssf_rfc_destination_error =7 OTHERS =8. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. IFgv_crcISNOTINITIAL. CALLFUNCTION‘SSF_ERRORMESSAGE’ EXPORTING crc =gv_crc result =0 IMPORTING errortext=gv_error EXCEPTIONS error =1 others =2. WRITE:/`Ошибка сверки подписи: `,gv_error. EXIT. ENDIF. CLEAR:gv_data,p_text. CALLFUNCTION‘SCMS_BINARY_TO_XSTRING’ EXPORTING input_length=gv_sign_len IMPORTING buffer =gv_data TABLES binary_tab =gt_sign EXCEPTIONS failed =1 OTHERS =2. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. CALLFUNCTION‘SSFC_BASE64_ENCODE’ EXPORTING bindata =gv_data binleng =gv_sign_len IMPORTING b64data =p_text EXCEPTIONS ssf_krn_error =1 ssf_krn_noop =2 ssf_krn_nomemory =3 ssf_krn_opinv =4 ssf_krn_input_data_error=5 ssf_krn_invalid_par =6 ssf_krn_invalid_parlen =7 OTHERS =8. IFsy—subrc<>0. MESSAGEIDsy—msgidTYPEsy—msgtyNUMBERsy—msgno WITHsy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4. ENDIF. WRITE`ЭЦП (BASE64):`COLORCOL_HEADING. WRITE:/p_text. |
Обратите внимание на параметр подписанта, в вашей системе идентификатор будет иным.
Для проверки работы внешних провайдеров проще всего воспользоваться упомянутой ранее программой SSF02, параметры будут аналогичными ранее указанным, за исключением того, что нужно будет указать RFC адрес и хеш-алгоритм внешнего провайдера.
Электронная подпись в sap – это просто
Все чаще получаю запросы от заказчиков об использовании электронной подписи в их решениях. Зачастую сама идея внедрения электронной подписи уже вызывает множество вопросов, как технического характера, так и общего – всвязи со столкновением с весьма специфической областью информационной безопасности, имеющей множество нюансов и отсылок к законодательству. Этой статьей я хочу показать, что применение ЭП – это просто.
Немного истории
В 1977 г. Ronald Rivest, Adi Shamir, и Len Adleman публикуют свою статью “Метод получения электронной подписи и криптосистемы с открытым ключом” (здесь и далее мой перевод):
Вероятно, эра электронной почты уже близко. Мы должны быть уверены, что можем сохранить два важных свойства текущей “бумажной почты”: письма должны остаться персональными и – могут быть подписаны лично. В нашей статье мы продемонстрируем как внедрить эти свойства в систему электронной почты. Сердцем нашего предложения будет новый метод шифрования. Он применяет элегантную концепцию “криптосистем с открытым ключей” предложенной Diffie и Hellman.
“Элегантная концепция Diffie и Hellman”
, о которой пишут авторы, действительно была важным шагом в области криптографии. К середине семидесятых NSA (National Security Agency) уже контролировало широкое использование криптографии за счет контроля средств распределения ключей шифрования. Однако, принцип распределения открытых ключей, предложенный Diffie и Hellman позволил уйти от этого, и теперь физические и юридические лица получили способ безопасно обмениваться зашифрованными сообщениями, не получая общий секретный (“симметричный”) ключ шифрования от сторонней правительственной организации.
Принцип, предложенный Diffie и Hellman можно проиллюстрировать на примере “красок”. Каждая из сторон обладает своей собственной “секретной” краской, но обменивается с партнером только смесью красок (Alice – оранжевым и Bob – голубым в качестве “приветствия”; второй раз – коричневым в качестве ключа шифрования). Предполагается, что найти “секретную” краску в смеси не представляется возможным.
В оригинале, конечно, криптографическая стойкость алгоритма предложенного Diffie и Hellman, основана на математике – а именно – сложности проблемы дискретного логарифмирования (https://ru.wikipedia.org/wiki/Дискретное_логарифмирование)
Это еще была не электронная подпись, но в той же статье, Diffie и Hellman предлагают использовать закрытый ключ (“секретную краску”) для шифрования сообщений и выдавать открытый ключ для проверки сообщений:
Если пользователь А хочет послать сообщение пользователю B, он “дешифрует” его с помощью своего закрытого ключа и отправляет партнеру результат “дешифровки”. Пользователь B может прочитать сообщение и быть уверен в его подлинности (authenticity), применив функцию шифирования открытым ключом. Кто угодно может использовать данную функцию и получить в итоге исходное сообщение.
Всемирно известный теперь алгоритм RSA в области электронной подписи (по первым буквам фамилий Ronald Rivest, Adi Shamir, and Len Adleman) полностью реализует принцип, предложенный Diffie и Hellman.
Фактически, в двух упомянутых статьях в 1976–1977 гг была заложена основа для 95% используемой на сегодня криптографии. Клиент-серверное шифрование, межсерверное шифрование, электронная подпись и пр., – все это результат использования предложенных 39 лет назад принципов.
Электронная подпись в России
Иронично, но не смотря на то, что прошло уже почти 40 лет с момента публикации алгоритмов RSA, мы до сих пор вынуждены хранить абсолютное большинство документов в бумажном виде.
Тем не менее, мир не стоит на месте, и с каждым годом законодательство разрешает все больше и больше документов переводить в электронную форму, используя электронную подпись для придания документам юридической значимости. Нет сомнений, что в перспективе на 20 лет вперед, все законодательные барьеры будут устранены и необходимость хранить бумажные документы отпадет вовсе. Опыт Эстонии, в которой функции электронной подписи используются даже в таких тонких сферах как при проведении голосования (в т.ч. в парламент), хороший тому пример.
На сегодня, область применения ЭП в Российской Федерации можно разделить на пять больших областей:
Главные преимущества использования электронной подписи – это значительное ускорение документооборота (особенно в масштабе глобальных корпораций) и повышение безопасности обмена информацией в целом.
Если на вашем предприятии уже есть электронный документооборот, то с помощью электронной подписи вы можете придать ему юридическую значимость. В случае коммуникации с заказчиками, подрядчиками и государственными органами, использование электронной подписи ускоряет взаимодействие, в конечном итоге сокращая издержки.
Электроная подпись в SAP
Один из наших клиентов в области нефти и газа экономит 4 млн рублей ежегодно только лишь на одной печати документов, заменив распечатку инвентаризационных карточек хранением документов в подписанном ЭП виде. В качестве средств криптографической защиты информации (СКЗИ) специалисты SAP рекомендовали использовать библиотеку sapcryptolib. Наряду с commoncryptolib она может устанавливаться в стандартный пакет поставки большинства решений SAP. Необходимо отметить, что раз эти библиотеки имеют реализацию криптографических средств, то они подпадают под действие регуляторов. Уточняйте, может ли ваша организация их импортировать.
К модулям FI (Финансы), SD (Сбыт), HR (Персонал), и другим, уже подключен стандартный криптопровайдер SAP:
Таким образом, функция ЭП уже реализована на уровне платформы SAP NetWeaver, это означает, что функции подписи и верификации документов уже доступны для бизнес-процессов предприятия. Остается их только подключить.
Как известно, российским законодательством (№ ФЗ-63 “Об электронной подписи” от 06 апреля 2022 года) определено три вида электронной подписи:
Простая и неквалифицированная ЭП могут быть реализованы в стандартной поставке SAP NetWeaver. При это объем доступных функций достаточно широк:
- Подпись и верификация на сервере и на тонком клиенте
- Поддержка PKCS#7, XML, S/MIME, Adobe PDF Forms
- Поддержка NetWeaver ABAP и NetWeaver Java
- Работа в SAP GUI и веб-приложениях
- Поддержка кириллических сертификатов
- Использование защищенного хранилища сертификатов Microsoft Keystorage (уровень ОС Windows)
- Использование USB-токенов и смарткарт
- Проверка наличия подписи доверенного выдающего удостоверяющего центра (проверка цепочки сертификатов)
- Проверка сертификатов на отозванность (по Certificate Revokation List — CRL)
- Возможность архивного хранения ЭП (с версионностью)
- Получение сертификатов Active Directory (по протоколу LDAP)
- Управление сертификатами (Public Key Infrastructure — PKI)
(для использования некоторых функций могут потребоваться дополнительные лицензии)
Говоря о квалифицированной ЭП, надо понимать, что требования к такому типу ЭП отличаются от страны к стране. Так, например, немецкий Акт об Электронной подписи (“Signaturgesetz”) от 1997 года требует, чтобы используемые в ЭП сертификаты выдавались квалифицированным удостоверяющим центром, для подписания использовались только отдельные устройства – смарткарты или токены, а сами подписываемые электронные документы должны записываться только на неизменяемые носители (например, на оптические диски).
Поэтому в вопросах реализации квалифицированной ЭП, SAP полагается на помощь партнеров-разработчиков СКЗИ.
Принципиальным требованием ФСБ при сертификации ПО для квалифицированной ЭП является использование ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-2001 в реализации криптографических алгоритмов (на июнь 2022 года требования на применение ГОСТ Р 34.10-2022 и ГОСТ Р 34.11-2022 до конца не регламентированы)
Технически, применение криптоалгоритмов ГОСТ в SAP достигается простым переключением «обертки» (wrapper) СКЗИ. “Обертка” подменяет собой использование стандартной библиотеки sapcryptolib обращением к любому стороннему СКЗИ, построенному на ГОСТ. Например, СКЗИ «ЛИССИ-CSP», “КриптоПро CSP”, “Валидата CSP” – если мы говорим об интерфейсе MS CSP; ПБЗИ «СКЗИ LirSSL», если используется интерфейс OpenSSL; ruTokenЭЦП/eTokenGOST если мы говорим об токенах/смарт-картах с интерфейсом PKCS11. В частности, решение ООО «ЛИССИ-Софт» под названием «FoxSSF» позволяет использовать СКЗИ с поддержкой всех трех вышеперечисленных интерфейсов. В следующей нашей статье мы более подробно поговорим о решениях, позволяющих подписывать документы SAP квалифицированной электронной подписью.
В заключение необходимо упомянуть проблему архивного хранения документов, подписанных ЭП. Т.к. в отличие от бумажной подписи, алгоритмы и сертификаты электронной подписи имеют свойство устаревать, необходимо заранее озаботиться получением долгосрочных сертификатов, от наиболее стабильных и уважаемых удостоверяющих центров. Если планируется более чем пятилетний срок хранения, то на подписываемых документах необходимо ставить штамп времени. Такой подход позволяет фиксировать время подписи, поэтому:
Если штампы времени не используются, то по истечении определенного срока возникнет необходимость переподписывать документы, что, само собой, довольно затратная процедура в масштабе больших организаций. С точки зрения законодательства тонкости долгосрочного хранения пока еще до конца не проработаны, так, например, вопрос о том, можно ли просто разом переподписать все документы одной подписью остается открытым.
При этом технически в каком виде вы храните подпись: в виде таблицы базы данных, архива или файла – не имеет значения. Для архивного хранения в SAP есть три хранилища: ArchiveLink, Archive Development Kit и Knowledge Warehouse. Для документов (PDF, DOC и т.д.) мы рекомендуем использовать ArchiveLink, а для таблиц баз данных – Archive Development Kit. В свою очередь, только Knowledge Warehouse позволяет записывать данные в фоновом задании. Все три варианта могут представлять данные для проверки (аудита) и работают с внешними устройствами, чтобы не нагружать сервер приложений.
Автор — Даниил Лузин
Консалтинговое подразделение ООО «САП СНГ»
Космодамианская наб. 52/7, 113054 Москва
Т. 7 495 755 9800 доп. 3045
М. 7 926 452 0425
Ф. 7 495 755 98 01
