Рубрика «PKI»

Помощь девопсам по внедрению PKI - 1
Ключевые интеграции Venafi

У девопсов и так много работы, а от них ещё требуют экспертных знаний по криптографии и инфраструктуре открытых ключей (PKI). Это неправильно.

Действительно, у каждой машины должен быть валидный TLS-сертификат. Они нужны для серверов, контейнеров, виртуальных машин, в сетках service mesh. Но количество ключей и сертификатов растёт как снежный ком, а управление быстро становится хаотичным, дорогостоящим и рискованным, если всё делать самостоятельно. При отсутствии надлежащей практики применения политик и мониторинга бизнес может пострадать из-за слабых сертификатов или неожиданного истечения срока действия.

GlobalSign и Venafi организовали два вебкаста в помощь девопсам. Первый — вводный, а второй — с более конкретными техническими советами по подключению системы PKI от GlobalSign через облако Venafi с помощью опенсорсных инструментов через HashiCorp Vault из конвейера Jenkins CI/CD.
Читать полностью »

Зачем нужен собственный удостоверяющий центр - 1
Примеры 1) промежуточного УЦ в открытой иерархии доверия и 2) частной иерархии, которая изолирована от открытой иерархии, со своим собственным корневым УЦ

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

Но что, если мы хотим создать частную инфраструктуру PKI со своим собственным УЦ? Действительно, в некоторых ситуациях такие промежуточные или частные иерархии очень удобны на практике.
Читать полностью »

Шагая по пути улучшения инфраструктуры, я решил добить древний и мучительный вопрос — без лишних телодвижений предоставлять возможность коллегам (разработчикам, тестировщикам, админам, etc ) самостоятельно управлять своими виртуалками в ovirt'е. В ovirt есть несколько компонентов, которые надо настроить для решения моего вопроса: сам веб интерфейс, noVNC консоль и заливка образов дисков.

Кнопки «Сделать Зашибись» я не нашёл, поэтому показываю какие ручки я крутил, чтобы решить данную задачу. Полная инструкция под катом:

Как подружить Ovirt и Let's Encrypt - 1

Читать полностью »

Работа с СКЗИ и аппаратными ключевыми носителями в Linux - 1

Хранение ключей на токенах и смарт-картах обеспечивает дополнительную защиту от внешних и внутренних нарушителей, в том числе имеющих определенный уровень доступа к информационной системе и оборудованию.

Сегодня я расскажу, как мы защищаем ключи шифрования и электронной подписи в наших информационных системах, и сделаю это в подробном, хорошо проиллюстрированном руководстве по настройке SUSE Linux Enterprise Server 12 SP3 для работы с токеном Aladdin JaCarta PKI и КриптоПро CSP KC2 4.0.9944.

Опубликовать данное руководство побудило несколько причин:
Читать полностью »

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

Настоящая статья более подробно раскрывает еще один подход к долгосрочному архивному хранению (ДАХ) – формирование усовершенствованной электронной подписи (УЭП), а именно ЭП в архивных форматах CAdES-A и XAdES-A.

Как организовать долгосрочное архивное хранение электронных документов - 1

Читать полностью »

ИОК: библиотеки GCrypt и KSBA как альтернатива OpenSSL с поддержкой российской криптографии. Продолжение - 1Мы продолжаем разговор об альтернативе openssl и речь пойдет о библиотеке libksba, которая входит в состав GnuPG. Библиотека libksba предоставляет высокоуровневый интерфейс для работы с такими объектами инфраструктуры открытых ключей как сертификаты, запросы на сертификаты, электронная подпись (CMS/PKCS#7). Однако, в отличии от библиотеки GCrypt, в которой реализована поддержка российских криптографических алгоритмов, то в libksba отсутствует реализация рекомендаций ТК-26 по использованию алгоритмов ГОСТ Р 34.10-2001/2012, ГОСТ Р 34.11-94/2012 в таких объектах ИОК как сертификаты, запросы на сертификаты, объекты PKCS#7/CMS (подписанные и/или шифрованные документы и т.п).
Читать полностью »

Инфраструктура открытых ключей: Удостоверяющий Центр на базе утилиты OpenSSL и SQLite3 (Посткриптум) - 1В одном из комментариев, присланным участником garex, в ответ на заявление:

Но сегодня в стандартной версии openssl отсутствует поддержка как ГОСТ Р 34.11-2012, так и ГОСТ Р 34.10-2012. Более того в версии 1.1 поддержка криптографии ГОСТ исключена из стандартной поставки («The GOST engine was out of date and therefore it has been removed.»)

было сказано:

Чем не устраивает вот эта, которую «убрали?» github.com/gost-engine/engine
Пример билда: github.com/rnixik/docker-openssl-gost/blob/master/Dockerfile

Читать полностью »

Инфраструктура открытых ключей: библиотека GCrypt как альтернатива OpenSSL с поддержкой российской криптографии - 1 Приближается вторая половина 2018 года и скоро должен наступить «2000-й год» в ИОК на базе российской криптографии. Это связано с тем, что

использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!

Уже сегодня не имеет смысла получать сертификаты с подписью по ГОСТ Р 34.10-2001. Читать полностью »

image Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.
Читать полностью »

Варианты хранения криптографических ключей - 1Продолжает расти популярность решений на основе PKI — всё больше сайтов переходят на HTTPS, предприятия внедряют цифровые сертификаты для аутентификации пользователей и компьютеров, S/MIME доказывает свою состоятельность и для шифрования электронной почты, и как способ проверки источника сообщений для противодействия фишингу. Но шифрование и аутентификация в этих приложениях практически бессмысленны без правильного управления ключами.

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

Во многих случаях секретные ключи — личные удостоверения ваших сотрудников (и, следовательно, часть персональных данных организации), так что их защита приравнивается к защите отпечатков пальцев при использовании биометрических учётных данных. Вы же не позволите хакеру добыть отпечаток своего пальца? То же самое и с секретными ключами.

В этой статье мы обсудим варианты защиты и хранения закрытых ключей. Как вы увидите, эти варианты могут незначительно отличаться в зависимости от типа сертификата(ов) и от того, как вы его используете (например, рекомендации для сертификатов SSL/TLS отличаются от рекомендаций для сертификатов конечных пользователей).
Читать полностью »