Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 110 сообщений
Cообщения с меткой

электронная подпись - Самое интересное в блогах

Следующие 30  »
света_М

Вам нужна электронная подпись? - Нужна!

Вторник, 31 Мая 2016 г. 20:26 (ссылка)

Это цитата сообщения Surge_Blavat Оригинальное сообщение

Вам нужна электронная подпись? - Нужна!




















Электронная подпись - ЭП



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

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



В Электронную Подпись записывается следующая информация:



*имя файла открытого ключа подписи;

*информация о лице, сформировавшем подпись;

*дата формирования подписи.



Первое время ЭП использовалась для автоматизации и упрощения какого либо бизнес-процесса и, в основном, ее применяли юридические лица. 



С течением времени область применения ЭП все расширялась и сейчас любое физическое лицо, может получить ЭП и решать с её помощью большое количество насущных задач:



*Получение государственных услуг  (www.gosuslugi.ru)

*Участие в общественных российских инициативах (www.roi.ru)

*Использование личного кабинета налогоплательщика (www.nalog.ru)

*Отправка документов на поступление в ВУЗ

*Ускоренная процедура онлайн кредитования для физических лиц (www.loanberry.ru)

*Аккредитация в качестве эксперта на портале ФГИС Росаккредитация (fsa.gov.ru)

*Отправка документов на регистрацию в качестве индивидуального предпринимателя

*В качестве индивидуального предпринимателя участие в поставках госорганам 

*Отправка документов на получение патента




Подробнее узнать и заказать ЭП можно тут   тут    и здесь








 

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Аудит СКЗИ и криптоключей

Пятница, 25 Марта 2016 г. 09:17 (ссылка)

image



С точки зрения информационной безопасности криптографические ключи являются критически важными данными. Если раньше, чтобы обокрасть компанию, злоумышленникам приходилось проникать на ее территорию, вскрывать помещения и сейфы, то теперь достаточно похитить токен с криптографическим ключом и сделать перевод через систему Интернет Клиент-Банк. Фундаментом обеспечения безопасности с помощью систем криптографической защиты информации (СКЗИ) является поддержание конфиденциальности криптографических ключей.



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



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



Термины и определения



image



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




  1. Криптографический ключ (криптоключ) — совокупность данных, обеспечивающая выбор одного конкретного криптографического преобразования из числа всех возможных в данной криптографической системе (определение из «розовой инструкции – Приказа ФАПСИ № 152 от от 13 июня 2001 г., далее по тексту – ФАПСИ 152).

  2. Ключевая информация — специальным образом организованная совокупность криптоключей, предназначенная для осуществления криптографической защиты информации в течение определенного срока [ФАПСИ 152].

    Понять принципиальное отличие между криптоключем и ключевой информации можно на следующем примере. При организации HTTPS, генерируются ключевая пара открытый и закрытый ключ, а из открытого ключа и дополнительной информации получается сертификат. Так вот, в данной схеме совокупность сертификата и закрытого ключа образуют ключевую информацию, а каждый из них по отдельности является криптоключом. Тут можно руководствоваться следующим простым правилом – конечные пользователи при работе с СКЗИ используют ключевую информацию, а криптоключи обычно используют СКЗИ внутри себя. В тоже время важно понимать, что ключевая информация может состоять из одного криптоключа.

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

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

  4. Средства криптографической защиты информации (СКЗИ) – средства шифрования, средства имитозащиты, средства электронной подписи, средства кодирования, средства изготовления ключевых документов, ключевые документы, аппаратные шифровальные (криптографические) средства, программно-аппаратные шифровальные (криптографические) средства. [ПП-313]

    При анализе данного определения можно обнаружить в нем наличие термина ключевые документы. Термин дан в Постановлении Правительства и менять его мы не имеем права. В тоже время дальнейшее описание будет вестись из расчета что к СКЗИ будут относится только средства осуществления криптографических преобразований). Данный подход позволит упростить проведение аудита, но в тоже время не будет сказываться на его качестве, поскольку ключевые документы мы все равно все учтем, но в своем разделе и своими методами.



Методика аудита и ожидаемые результаты



image



Основными особенностями предлагаемой в данной статье методике аудита являются постулаты о том, что:




  • ни один работник компании не может точно ответить на вопросы, задаваемые в ходе аудита;

  • существующие источники данных (перечни, реестры и др.) не точны или слабо структурированы.

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



Приведем основные зависимости, которые нам в этом помогут:




  1. Если есть СКЗИ, то есть и ключевая информация.

  2. Если есть электронный документооборот (в том числе с контрагентами и регуляторами), то скорее всего в нем применяется электронная подпись и как следствие СКЗИ и ключевая информация.

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

  4. Если работник задействован в электронном документообороте, то скорее всего у него есть ключевые документы.

  5. При организации электронного документооборота с контрагентами обычно выпускаются организационно-распорядительные документы (приказы) о назначении ответственных лиц.

  6. Если информация передается через сеть Интернет (или другие общественные сети), то скорее всего она шифруется. В первую очередь это касается VPN и различных систем удаленного доступа.

  7. Если в сетевом трафике обнаружены протоколы, передающие трафик в зашифрованном виде, то применяются СКЗИ и ключевая информация.

  8. Если производились расчеты с контрагентами, занимающимися: поставками средств защиты информации, телекоммуникационных устройств, оказанием услуг по передаче отёчности, услуг удостоверяющих центров, то при данном взаимодействии могли приобретаться СКЗИ или ключевые документы.

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

  10. При использовании средств виртуализации, ключевые документы могут храниться как внутри виртуальных машин, так и монтироваться к виртуальным машинам с помощью гипервизора.

  11. Аппаратные СКЗИ могут устанавливаться в серверных и быть недоступны для анализа по сети.

  12. Некоторые системы электронного документооборота могут находится в неактивном или малоактивном виде, но в тоже время содержать активную ключевую информацию и СКЗИ.

  13. Внутренняя нормативная и организационно-распорядительная документация может содержать сведения о системах электронного документооборота, СКЗИ и ключевых документов.



Для добычи первичной информации будем:




  • опрашивать работников;

  • проводить анализ документации компании, включая внутренние нормативные и распорядительные документы, а также исходящие платежные поручения;

  • проводить визуальный анализ серверных комнат и коммуникационных шкафов;

  • проводить технических анализ содержимого автоматизированных рабочих мест (АРМ), серверов и средств виртуализации.



Конкретные мероприятия сформулируем позже, а пока рассмотрим конечные данные, которые мы должны получить по итогам аудита:



image




Перечень СКЗИ:



По каждому элементу перечня фиксируем следующие данные:




  1. Модель СКЗИ. Например, СКЗИ Крипто CSP 3.9, или OpenSSL 1.0.1

  2. Идентификатор экземпляра СКЗИ. Например, серийный, лицензионный (или регистрационный по ПКЗ-2005) номер СКЗИ

  3. Сведения о сертификате ФСБ России на СКЗИ, включая номер и даты начала и окончания сроков действия.

  4. Сведения о месте эксплуатации СКЗИ. Например, имя компьютера на которое установлено программное СКЗИ, или наименование технических средств или помещения где установлены аппаратные СКЗИ.



Данная информация позволит:




  1. Управлять уязвимостями в СКЗИ, то есть быстро их обнаруживать и исправлять.

  2. Отслеживать сроки действия сертификатов на СКЗИ, а также проверять используется ли сертифицированное СКЗИ в соответствии с правилами, установленными документацией или нет.

  3. Планировать затраты на СКЗИ, зная сколько уже находится в эксплуатации и сколько еще есть сводных средств.

  4. Формировать регламентную отчетность.



Перечень ключевой информации:



По каждому элементу перечня фиксируем следующие данные:




  1. Наименование или идентификатор ключевой информации. Например, «Ключ квалифицированной ЭП. Серийный номер сертификата 31:2D:AF», при этом идентификатор следует подбирать таким образом, чтобы по нему можно было найти ключ. Например, удостоверяющие центры, когда посылают уведомления обычно идентифицируют ключи по номерам сертификатов.

  2. Центр управления ключевой системой (ЦУКС), выпустивший данную ключевую информацию. Это может быть организация выпустившая ключ, например, удостоверяющий центр.

  3. Физическое лицо, на имя которого выпущена ключевая информация. Эту информацию можно извлечь из полей CN сертификатов X.509

  4. Формат ключевой информации. Например, СКЗИ КриптоПРО, СКЗИ Верба-OW, X.509 и т.д (или другими словами для использования с какими СКЗИ предназначена данная ключевая информация).

  5. Назначение ключевой информации. Например, «Участие в торгах на площадке Сбербанк АСТ», «Квалифицированная электронная подпись для сдачи отчетности» и т.д. С точки зрения техники, в данном поле можно фиксировать органичения зафиксированные полях extended key usage и др сертификатов X.509.

  6. Начало и окончание сроков действия ключевой информации.

  7. Порядок перевыпуска ключевой информации. То есть знания о том, что нужно делать и как, при перевыпуске ключевой информации. По крайней мере желательно фиксировать контакты должностных лиц ЦУКС, выпустившего ключевую информацию.

  8. Перечень информационных систем, сервисов или бизнес-процессов в рамках которых используется ключевая информация. Например, «Система дистанционного банковского обслуживания Интернет Клиент-Банк».



Данная информация позволит:




  1. Отслеживать сроки действия ключевой информации.

  2. В случае необходимости быстро перевыпускать ключевую информацию. Это может понадобится как при плановом, так при внеплановом перевыпуске.

  3. Блокировать использование ключевой информации, при увольнении работника на которого она выпущена.

  4. Расследовать инциденты информационной безопасности, отвечая на вопросы: «У кого были ключи для совершения платежей?» и др.



Перечень ключевых документов:



По каждому элементу перечня фиксируем следующие данные:




  1. Ключевая информация, содержащаяся в ключевом документе.

  2. Носитель ключевой информации, на который записана ключевая информация.

  3. Лицо, ответственное за сохранность ключевого документа и конфиденциальность содержащейся в нем ключевой информации.



Данная информация позволит:




  1. Перевыпускать ключевую информацию в случаях: увольнения работников, обладающих ключевыми документами, а также при компрометации носителей.

  2. Обеспечивать конфиденциальность ключевой информации, путем инвентаризации носителей ее содержащих.



План аудита





Настало время рассмотреть практически особенности проведения аудита. Сделаем это на примере кредитно-финансовой организации или другими словами на примере банка. Данный пример выбран не случайно. Банки используют довольно большое число разношерстных систем криптографической защиты, которые задействованы в гигантском количестве бизнес-процессов, да и к тому же практически все банки являются Лицензиатами ФСБ России по криптографии. Далее в статье будет представлен план аудита СКЗИ и криптоключей, применительно к Банку. В тоже время данный план может быть взят за основу при проведении аудита практически любой компании. Для удобство восприятия план разбит на этапы, которые в свою очередь свернуты в сполйеры.



Этап 1. Сбор данных с инфраструктурных подразделений компании























































































Действие Ожидаемый результат и его использование
Источник – все работники компании
1 Делаем рассылку по корпоративной почте всем работниками компании с просьбой сообщить в службу информационной безопасности обо всех используемых ими криптографических ключах Получаем электронные письма, на базе которых формируем перечень ключевой информации и перечень ключевых документов
Источник – Руководитель Службы информационных технологий
1 Запрашиваем перечень ключевой информации и ключевых документов С некоторой вероятностью Служба ИТ ведет подобные документы, будем использовать их для формирования и уточнения перечней ключевой информации, ключевых документов и СКЗИ
2 Запрашиваем перечень СКЗИ
3 Запрашиваем реестр ПО, установленного на серверах и рабочих станциях В данном реестре ищем программные СКЗИ и их компоненты. Например, КриптоПРО CSP, Верба-OW, Signal-COM CSP, Сигнатура, PGP, ruToken, eToken, КритоАРМ и др. На базе этих данных формируем перечень СКЗИ.
4 Запрашиваем перечень работников (вероятно техническая поддержка), помогающих пользователям по использованию СКЗИ и перевыпуску ключевой информации. Запрашиваем у данных лиц аналогичную информацию, что и у системных администраторов
Источник – системные администраторы Службы информационных технологий
1 Запрашиваем перечень отечественных криптошлюзов (VIPNET, Континент, S-terra и др.) В случаях, когда в компании не реализованы регулярные бизнес процессы управления ИТ и ИБ, подобные вопросы могут помочь вспомнить системным администраторам о существовании того или иного устройства или ПО. Используем данную информацию для получения перечня СКЗИ.
2 Запрашиваем перечень отечественных программных СКЗИ (СКЗИ МагПро КриптоПакет, VIPNET CSP, CryptonDisk, SecretDisk, …)
3 Запрашиваем перечень маршрутизаторов, реализующих VPN для:

а) связи офисов компании;

б) взаимодействия с контрагентами и партнерами.
4 Запрашиваем перечень информационных сервисов, опубликованных в Интернет (доступных из Интернет). Они могу включать:

а) корпоративную электронную почту;

б) системы обмена мгновенными сообщениями;

в) корпоративные web-сайты;

г) сервисы для обмена информации с партнерами и контрагентами (extranet);

д) системы дистанционного банковского обслуживания (если компания – Банк);

е) системы удаленного доступа в сеть компании.

Для проверки полноты предоставленных сведений сверяем их с перечнем правил Portforwarding пограничных межсетевых экранов.
Анализируя полученную информацию с высокой вероятностью можно встретить использование СКЗИ и криптоключей. Используем полученные данные для формирования перечня СКЗИ и ключевой информации.
5 Запрашиваем перечень информационных систем, используемых для сдачи отчетности (Такском, Контур и т. д.) В данных системах используются ключи квалифицированной электронной подписи и СКЗИ. Через данный перечень формируем перечень СКЗИ, перечень ключевой информации, а также узнаем работников, пользующихся этими системами для формирования перечня ключевых документов.
6 Запрашиваем перечень систем внутреннего электронного документооборота (Lotus, DIRECTUM, 1С: Документооборот и др.), а также перечень их пользователей. В рамках внутренних систем электронного документооборота могут встретиться ключи электронной подписи. На основании полученной информации формируем перечень ключевой информации и перечень ключевых документов.
7 Запрашиваем перечень внутренних удостоверяющих центров. Средства, используемые для организации удостоверяющих центров, фиксируем в перечне СКЗИ. В дальнейшем будем анализировать содержимое баз данных удостоверяющих центров для выявления ключевой информации.
8 Запрашиваем информацию об использовании технологий: IEEE 802.1x, WiFiWPA2 Enterprise и систем IP-видеонаблюдения В случае использования данных технологий мы можем обнаружить в задействованных устройствах ключевые документы.
Источник – Руководитель кадровой службы
1 Просим описать процесс приема и увольнение работников. Фокусируемся на вопросе о том, кто забирает у увольняющихся работников ключевые документы Анализируем документы (обходные листы) на предмет наличия в них информационных систем в которых могут использоваться СКЗИ.






Этап 2. Сбор данных с бизнес-подразделений компании (на примере Банка)

















































































































Действие Ожидаемый результат и его использование
Источник – Руководитель служба расчетов (корреспондентских отношений)
1 Просим предоставить схему организации взаимодействия с платежной системой Банка России. В частности, это будет актуально для Банков, имеющих развитую филиальную сеть, при которой филиалы могут подключать в платежную систему ЦБ напрямую На базе полученных данных определяем местоположение платежных шлюзов (АРМ КБР, УТА) и перечень задействованных пользователей. Полученную информацию используем для формирования перечня СКЗИ, ключевой информации и ключевых документов.
2 Запрашиваем перечень Банков, с которыми установлены прямые корреспондентские отношения, а также просим рассказать кто занимается осуществлением переводов и какие технические средства используются. Аналогично, как для платежной системы Банка России
3 Запрашиваем перечень платежных систем, в которых участвует Банк (SWIFT, VISA, MasterCard, НСПК, и т.д), а также месторасположение терминалов для связи Аналогично, как для платежной системы Банка России
Источник – Руководитель подразделения, отвечающего за предоставление дистанционных банковских услуг
1 Запрашиваем перечень систем дистанционного банковского обслуживания. В указанных системах анализируем использование СКЗИ и ключевой информации. На основании полученных данных формируем перечень СКЗИ и ключевой информации и ключевых документов.
Источник – Руководитель подразделения, отвечающего за функционирование процессинга платежных карт
1 Запрашиваем реестр HSM На базе полученной информации формируем перечень СКЗИ, ключевой информации и ключевых документов.
2 Запрашиваем реестр офицеров безопасности
4 Запрашиваем информацию о компонентах LMK HSM
5 Запрашиваем информацию об организации систем типа 3D-Secure и организации персонализации платежных карт
Источник – Руководители подразделений, выполняющих функции казначейства и депозитария
1 Перечень банков, с которыми установлены корреспондентские отношения и которые участвую в межбанковском кредитовании. Используем полученную информацию для уточнения ранее полученных данных от службы расчетов, а также фиксируем информацию о взаимодействии с биржами и депозитариями. На базе полученной информации формируем перечень СКЗИ и ключевой информации.
2 Перечень бирж и специализированных депозитариев с которыми работает Банк
Источник – Руководители служб финансового мониторинга и подразделений ответственных за сдачу отчетности в Банк России
1 Запрашиваем информацию о том, как они отправляют сведения и получают сведения из ЦБ. Перечень задействованных лиц и технических средств. Информационное взаимодействие с Банком России жестко регламентировано соответствующими документами, например, 2332-У, 321-И и многими другими, проверяем соответствие этим документам и формируем перечни СКЗИ, ключевой информации и ключевых документов.
Источник – Главный бухгалтер и работники бухгалтерии, занимающиеся оплатой счетов по внутрибанковским нуждам
1 Запрашиваем информацию, о том, как происходит подготовка и сдача отчетности в налоговые инспекции и Банк России Уточняем ранее полученные сведения
2 Запрашиваем реестр платежных документов, для оплаты внутрибанковских нужд В данном реестре будем искать документы где:

1) в качестве адресатов платежей указаны удостоверяющие центры, специализированные операторы связи, производители СКЗИ, поставщики телекоммуникационного оборудования. Наименования данных компаний можно получить из Реестра сертифицированных СКЗИ ФСБ России, перечня аккредитованных удостоверяющих центров Минкомсвязи и других источников.

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




Этап 3. Технический аудит

































Действие Ожидаемый результат и его использование
1 Проводим техническую инвентаризацию ПО установленного на компьютерах. Для этого используем:

· аналитические возможности корпоративных систем антивирусной защиты (например, Антивирус Касперского умеет строить подобный реестр).

· скрипты WMI для опроса компьютеров под управлением ОС Windows;

· возможности пакетных менеджеров для опроса *nix систем;

· специализированное ПО для инвентаризации.
Среди установленного ПО ищем программные СКЗИ, драйвера для аппаратных СКЗИ и ключевых носителей. На базе полученной информации обновляем перечень СКЗИ.
2 Осуществляем поиск ключевых документов на серверах и рабочих станциях. Для этого

· Logon-скриптами опрашиваем АРМ в домене на предмет наличия сертификатов с закрытыми ключами в профилях пользователей и профилях компьютера.

· На всех компьютерах, файловых серверах, гипервизорах ищем файлы с расширениями: crt, cer, key, pfx, p12, pem, pse, jks и др.

· На гипервизорах систем виртуализации ищем примонтированные дисководы и образы дискет.
Очень часто ключевые документы представлены в виде файловых ключевых контейнеров, а также контейнерами, хранящимися в реестрах компьютеров, работающих под управлением ОС Windows. Найденные ключевые документы фиксируем в перечне ключевых документов, а содержащеюся в них ключевую информацию в перечне ключевой информации.
3 Анализируем содержание баз данных удостоверяющих центров Базы данных удостоверяющих центров обычно содержат в себе данные о выпущенных этим центрами сертификатов. Полученную информацию заносим в перечень ключевой информации и перечень ключевых документов.
4 Проводим визуальный осмотр серверных комнат и коммутационных шкафов, ищем СКЗИ и аппаратные ключевые носители (токены, дисководы) В некоторых случаях, невозможно провести инвентаризацию СКЗИ и ключевых документов по сети. Системы могут находится в изолированных сетевых сегментах, либо вообще не иметь сетевых подключений. Для этого проводим визуальный осмотр, в результатах которого должно быть установлены названия и назначение всего оборудования, представленного в серверных. Полученную информацию заносим в перечень СКЗИ и ключевых документов.
5 Проводим анализ сетевого трафика, с целью выявления информационных потоков, использующих шифрованный обмен Шифрованные протоколы – HTTPS, SSH и др. позволят нам идентифицировать сетевые узлы на которых выполняются криптографические преобразования, и как следствие содержащие СКЗИ и ключевые документы.




Заключение



В данной статье мы рассмотрели теорию и практику проведения аудита СКЗИ и криптоключей. Как вы убедились, процедура эта довольно сложная и трудоемкая, но если к ней грамотно подходить вполне осуществимая. Будем надеется данная статья вам поможет в реальной жизни. Спасибо за внимание, ждем ваших комментариев

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/280131/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Surge_Blavat

Вам нужна электронная подпись? - Нужна!

Вторник, 10 Ноября 2015 г. 12:00 (ссылка)


















Электронная подпись - ЭП



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

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



В Электронную Подпись записывается следующая информация:



*имя файла открытого ключа подписи;

*информация о лице, сформировавшем подпись;

*дата формирования подписи.



Первое время ЭП использовалась для автоматизации и упрощения какого либо бизнес-процесса и, в основном, ее применяли юридические лица. 



С течением времени область применения ЭП все расширялась и сейчас любое физическое лицо, может получить ЭП и решать с её помощью большое количество насущных задач:



*Получение государственных услуг  (www.gosuslugi.ru)

*Участие в общественных российских инициативах (www.roi.ru)

*Использование личного кабинета налогоплательщика (www.nalog.ru)

*Отправка документов на поступление в ВУЗ

*Ускоренная процедура онлайн кредитования для физических лиц (www.loanberry.ru)

*Аккредитация в качестве эксперта на портале ФГИС Росаккредитация (fsa.gov.ru)

*Отправка документов на регистрацию в качестве индивидуального предпринимателя

*В качестве индивидуального предпринимателя участие в поставках госорганам 

*Отправка документов на получение патента




Подробнее узнать и заказать ЭП можно тут   тут    и здесь








 

Метки:   Комментарии (15)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Электронная подпись в SAP – это просто

Воскресенье, 28 Июня 2015 г. 23:06 (ссылка)

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



image







Немного истории



В 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:



image



Таким образом, функция ЭП уже реализована на уровне платформы SAP NetWeaver, это означает, что функции подписи и верификации документов уже доступны для бизнес-процессов предприятия. Остается их только подключить.



Как известно, российским законодательством (№ ФЗ-63 “Об электронной подписи” от 06 апреля 2011 года) определено три вида электронной подписи:


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

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

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



Простая и неквалифицированная ЭП могут быть реализованы в стандартной поставке SAP NetWeaver. При это объем доступных функций достаточно широк:


  1. Подпись и верификация на сервере и на тонком клиенте

  2. Поддержка PKCS#7, XML, S/MIME, Adobe PDF Forms

  3. Поддержка NetWeaver ABAP и NetWeaver Java

  4. Работа в SAP GUI и веб-приложениях

  5. Поддержка кириллических сертификатов

  6. Использование защищенного хранилища сертификатов Microsoft Keystorage (уровень ОС Windows)

  7. Использование USB-токенов и смарткарт

  8. Проверка наличия подписи доверенного выдающего удостоверяющего центра (проверка цепочки сертификатов)

  9. Проверка сертификатов на отозванность (по Certificate Revokation List — CRL)

  10. Возможность архивного хранения ЭП (с версионностью)

  11. Получение сертификатов Active Directory (по протоколу LDAP)

  12. Управление сертификатами (Public Key Infrastructure — PKI)



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



Говоря о квалифицированной ЭП, надо понимать, что требования к такому типу ЭП отличаются от страны к стране. Так, например, немецкий Акт об Электронной подписи (“Signaturgesetz”) от 1997 года требует, чтобы используемые в ЭП сертификаты выдавались квалифицированным удостоверяющим центром, для подписания использовались только отдельные устройства – смарткарты или токены, а сами подписываемые электронные документы должны записываться только на неизменяемые носители (например, на оптические диски).



Поэтому в вопросах реализации квалифицированной ЭП, SAP полагается на помощь партнеров-разработчиков СКЗИ.



Принципиальным требованием ФСБ при сертификации ПО для квалифицированной ЭП является использование ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-2001 в реализации криптографических алгоритмов (на июнь 2015 года требования на применение ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 до конца не регламентированы)



Технически, применение криптоалгоритмов ГОСТ в SAP достигается простым переключением «обертки» (wrapper) СКЗИ. “Обертка” подменяет собой использование стандартной библиотеки sapcryptolib обращением к любому стороннему СКЗИ, построенному на ГОСТ. Например, СКЗИ «ЛИССИ-CSP», “КриптоПро CSP”, “Валидата CSP” – если мы говорим об интерфейсе MS CSP; ПБЗИ «СКЗИ LirSSL», если используется интерфейс OpenSSL; ruTokenЭЦП/eTokenGOST если мы говорим об токенах/смарт-картах с интерфейсом PKCS11. В частности, решение ООО «ЛИССИ-Софт» под названием «FoxSSF» позволяет использовать СКЗИ с поддержкой всех трех вышеперечисленных интерфейсов. В следующей нашей статье мы более подробно поговорим о решенях, позволяющих подписывать документы SAP квалифицированной электронной подписью.



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


  • по истечении срока действия сертификата или алгоритма не нужно “переподписывать” документ

  • исключается техническая возможность сдвинуть время подписания назад и использовать скопрометированный сертификат/алгоритм – по причине наличия подписи службы штампов времени (Time Stamp Protocol – TSP) на архивированных документах.



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

При этом технически в каком виде вы храните подпись: в виде таблицы базы данных, архива или файла – не имеет значения. Для архивного хранения в SAP есть три хранилища: ArchiveLink, Archive Development Kit и Knowledge Warehouse. Для документов (PDF, DOC и т.д.) мы рекомендуем использовать ArchiveLink, а для таблиц баз данных – Archive Development Kit. В свою очередь, только Knowledge Warehouse позволяет записывать данные в фоновом задании. Все три варианта могут представлять данные для проверки (аудита) и работают с внешними устройствами, чтобы не нагружать сервер приложений.

Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/260765/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Будущее электронной подписи

Воскресенье, 22 Июня 2015 г. 03:32 (ссылка)



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



Я бы хотел рассказать о более удобном способе электронной подписи.



Что же можно сделать



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



Сервер облачной подписи сам осуществляет все необходимые действия. От пользователя нужно только дать необходимые указания. Ну и самое главное, что должен сделать пользователь – аутентифицироваться.



Очевидным плюсом такого подхода является перенос Secure Element от пользователей, которые не очень-то приспособлены для правильного хранения и использования всяких смарт-картами, на сервер. Вот на сервере-то ключевая информация может храниться под защитой HSM. Это само по себе, не сильно отличается от хранения ключей на смарт-карте или токене. Но, согласитесь, научить всех пользователей правильно хранить ключевую информацию намного сложнее, чем обеспечить должный уровень безопасности сервера подписи. К тому же современные HSM из коробки предоставляют неплохие возможности для правильной работы с ключевой информацией.



Вопрос аутентификации пользователя становится в данном случае очень остро. Тут без многофакторной аутентификации не обойтись. На сегодняшний день уже есть большой выбор методов строгой аутентификации, таких, как, например, одноразовые пароли или биометрия. При должной настройке строгая аутентификация предоставляет уровень доверия к пользователю не ниже, чем при самостоятельном предъявлении сертификата.



На практике



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



Почему так лучше



Чтобы развеять сомнения, нужно только ответить себе на один вопрос: зачем нужна электронная подпись? А нужна она для того, чтобы быть уверенным, что она поставлена владельцем и чтобы обеспечить целостность. Первое успешно достигается многофакторной аутентификацией. Неплохие примеры ее использования – работа с интернет-банком. Целостность, конечно, тоже обеспечивается благодаря той самой подписи, которую ставит сервер.



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



Что-то похожее уже было



Аналогичный процесс с вынесением Secure Element в облако сейчас наблюдается в области электронных платежей. Технология Host Card Emulation позволяет эмулировать платежную карту на смартфоне без привязки к Secure Element, как это было раньше. Secure Element переносится в облако банка или, так называемого, Token Service Provider. Такой подход значительно упрощает развитие мобильных платежей и избавляет от необходимости построения отношений доверия между производителями смартфонов и банками.

Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/260733/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Tanyusha100

ЭП в Ростове...

Вторник, 27 Января 2015 г. 08:00 (ссылка)


ЭП в Ростове...

















     Ростов - на - Дону  - крупнейший город ЮФО России, а Ростовская область - перспективный привлекательный регион с множеством дорог и линий сообщений всех видов транспорта. Так сложилось географически и исторически, что проживает здесь народ европейской части России, которым не чужды все современные блага цивилизации. А где есть блага, там и обслуживание  и промышленность и строительство развиты и требуют постоянных инвестиций и поставок со всех уголков страны, а также внедрения тендеров  и приобретения определённого опыта, чтобы участвовать здесь в ремонте и строительстве и во всех поставках и услугах, которые с этим связаны.



4897960_4nkpbrgouxejmwri (109x32, 3Kb)





 


Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
angreal

Для чего нужна электронная подпись?

Пятница, 23 Января 2015 г. 08:16 (ссылка)


Для чего нужна электронная подпись?



В пересылке документов между организациями сейчас всё чаще используется электронная подпись (ЭП).  Для того чтобы оформить ЭП нужно просто обратиться в любую компанию типа "Бико". Давайте узнаем где же ЭП находит применение.

Читать далее...
Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Простое решение для использования ЭЦП

Понедельник, 22 Декабря 2014 г. 16:21 (ссылка)

imageНесколько лет назад мы начали проект «Открытые голосования», призванный создать систему для удобного проведения надежных и проверяемых голосований. К сожалению, дело ограничилось только теоретическими разработками, а в плане конкретных реализаций мы так и не продвинулись вперед. Не так давно я начал размышлять — почему так? Я сам разработчик. В команде тоже есть несколько разработчиков. Так что-же нам мешает? И пришел к выводу, что главная помеха — слишком большие первоначальные планы. Поэтому я решил начать с малого — с инструмента для простого использования электронной подписи обычными людьми. Причем, не только для нашего проекта, а для любого сайта, который сочтет это необходимым.



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



Итак, что-же я предлагаю…



Мобильное приложение, находящееся на смартфоне пользователя, обеспечивает всю базовую криптографию — создание ключей, их хранение и подписание документов. Документы представляют собой набор данных и шаблон для их отображения. Сейчас доступны два типа шаблонов: простой список и HTML шаблон.



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



Порядок работы



Естественно, что-бы сайт клиента мог отправить документ на подписание определенному пользователю, ему нужно сначала каким-то образом получить открытый ключ пользователя и привязать его к своей внутренней логике (например, к логину пользователя). Для этого предназначена процедура «Регистрации подписи». Заключается она в следующем:



— сайт выдает пользователю пару строк: свой идентификатор (обычно домен) и одноразовый код;

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

— сайт клиента получает от прокси сервера этот пакет и привязывает публичный ключ к своей логике.



После этого, в случае необходимости подписания документа на сайте:



— клиент формирует документ на подписание (включая внутренний идентификатор документа), шифрует данные документа открытым ключем пользователя, устанавливает для него идентификатор пользователя по его публичному ключу и отправляет на прокси;

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

— при получении такого документа пользователь расшифровывает его данные и формирует из них, шаблона и некоторых других атрибутов документа его подпись;

— полученную подпись он отправляет на прокси сервер вместе с идентификатором клиента и внутренним номером документа. Сами данные документа не отправляются (они сохранены у клиента);

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



На этом цикл заканчивается.



Итоги и перспективы



Конечно, я могу признать что система не идеальна. Но это первый вариант и, что самое важное, он есть и он работает. Так-же важно то, что его можно использовать не только для целей нашего проекта, которые связаны с реализацией голосований. Его можно использовать, например, для обеспечения двухфакторной авторизации. Или для защиты критичных действий пользователя типа изменения пароля или привязанного к логину e-mail (такой опциональный функционал уже внедряется на одном из популярных сайтов). Это базовый инструмент и на его основе можно построить все что угодно — дело ограничено лишь нашей фантазией. :)



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



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



Ну и ссылки:



Мобильное приложение в Google Play Market: GPLVote Sign Doc

Исходный код мобильного приложения на GitHub

Тестовый сайт клиента для тестирования мобильного приложения

Perl модуль GPLVote::SignDoc::Client, облегчающий прикрутку нужного функционала к сайтам клиентов

Исходный код тестового клиента на GitHub (Perl)

Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/246467/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<электронная подпись - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda