Csp компоненты

CSP КОМПОНЕНТЫ ЭЦП

Для
работы с удостоверяющим центром мы
используем компоненты ПАК
«КриптоПро УЦ».

В
базовый
состав компонент
ПАК «КриптоПро УЦ» входят:

Время на прочтение

Content Security Policy (CSP) — это механизм безопасности веб-приложений, который используется для сокращения рисков, связанных с атаками, такими как внедрение скриптов (XSS) и выполнение нежелательного кода (инъекция). C SP позволяет веб-разработчикам указывать браузерам, из каких источников разрешено загружать ресурсы, такие как скрипты, стили, изображения, шрифты и другие элементы.

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

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


CSP КОМПОНЕНТЫ

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

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

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

Причина 1

Официальная документация на Aladdin-RD JaCarta больше адаптирована под операционные системы Astra Linux и ALT Linux, сертифицированные в Минобороны, ФСТЭК и ФСБ как средства защиты информации.

Причина 2

Лучшая инструкция по настройке взаимодействия с аппаратными носителями в Linux, которую удалось найти, была также от wiki.astralinux.ru — Работа с КриптоПро CSP

Причина 3

UPD 16.04.2019: В процессе настройки среды и оборудования выяснилось, что носитель, первым оказавшийся в распоряжении, был вовсе не JaCarta PKI Nano, как ожидалось, а устройство работающее в режиме SafeNet Authentication Client eToken PRO.

UPD 16.04.2019: Некогда Банку требовалось устройство, которое могло бы работать в той же инфраструктуре, что и eToken PRO (Java). В качестве такого устройства компания “ЗАО Аладдин Р. Д.” предложила токен JaCarta PRO, который был выбран банком. Однако на этапе формирования артикула и отгрузочных документов сотрудником компании была допущена ошибка. Вместо модели JaCarta PRO в артикул и отгрузочные документы случайно вписали JaCarta PKI.

UPD 16.04.2019: Благодарю компанию Аладдин Р. Д., за то что помогли разобраться и установить истину.

В этой ошибке нет никаких политических и скрытых смыслов, а только техническая ошибка сотрудника при подготовке документов. Токен JaCarta PRO является продуктом компании ЗАО “Аладдин Р. Д.”. Апплет, выполняющий функциональную часть, разработан компанией “ЗАО Аладдин Р. Д”.

Этот eToken PRO относился к партии, выпущенной до 1 декабря 2017 года.
После этой даты компания «Аладдин Р. Д.» прекратила продажу устройств eToken PRO (Java).

Забегая немного вперед, нужно сказать, что работа с ним настраивалась через соответствующие драйверы — SafenetAuthenticationClient-10.0.32-0.x86_64, которые можно получить только в поддержке Аладдин Р. Д. по отдельной online заявке.

Данный токен определялся и откликался. При помощи утилиты SACTools из пакета SafenetAuthenticationClient можно было выполнить его инициализацию. Но при работе с СКЗИ он вел себя крайне странно и непредсказуемо.

Проявлялось это следующим образом, на команду:

Выдавался ответ, что все хорошо:

Но сразу после попытки зачитать ключи программно эта же проверка начинала выдавать ошибку:

Согласно перечню кодов ошибок объектной модели компонентов Microsoft COM Error Codes (Security and Setup)

NTE_KEYSET_ENTRY_BAD
0x8009001A
Keyset as registered is invalid.

«Невалидный набор ключей» — причина такого сообщения, возможно, кроется либо в старом чипе, прошивке и апплете Gemalto, либо в их драйверах для ОС, которые не поддерживают новые стандарты формирования ЭП и функции хэширования ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012.

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

Справедливости ради требуется отметить, что SafeNet eToken PRO корректно работал с ключами ГОСТ Р 34.10-2001 в ОС Windows 7 и 10.

Можно было бы попробовать установить СКЗИ КриптоПро CSP 4.0 ФКН (Gemalto), но целевая задача — защитить наши ключи ЭП и шифрования с помощью сертифицированных ФСБ и ФСТЭК изделий семейства JaCarta, в которых поддерживаются новые стандарты.

Проблему удалось решить, взяв настоящий токен JaCarta PKI в (XL) обычном корпусе.

Но на попытки заставить работать Safenet eToken PRO времени было потрачено немало. Хотелось обратить на это внимание и, возможно, кого-то оградить от подобного.

Причина 4

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

КриптоПро CSP 5.0 — новое поколение криптопровайдера, развивающее три основные продуктовые линейки компании КриптоПро: КриптоПро CSP (классические токены и другие пассивные хранилища секретных ключей), КриптоПро ФКН CSP/Рутокен CSP (неизвлекаемыe ключи на токенах с защищенным обменом сообщениями) и КриптоПро DSS (ключи в облаке).

Все преимущества продуктов этих линеек не только сохраняются, но и приумножаются в КриптоПро CSP 5.0: шире список поддерживаемых платформ и алгоритмов, выше быстродействие, удобнее пользовательский интерфейс. Но главное — работа со всеми ключевыми носителями, включая ключи в облаке, теперь единообразна. Для перевода прикладной системы, в которой работал КриптоПро CSP любой из версий, на поддержку ключей в облаке или на новые носители с неизвлекаемыми ключами, не потребуется какая-либо переработка ПО — интерфейс доступа остаётся единым, и работа с ключом в облаке будет происходить точно таким же образом, как и с классическим ключевым носителем.

Назначение КриптоПро CSP

В КриптоПро CSP 5.0 наряду с российскими реализованы зарубежные криптографические алгоритмы. Теперь пользователи имеют возможность использовать привычные носители ключей для хранения секретных ключей RSA и ECDSA.

Таблица алгоритмов, поддерживаемых разными версиями КриптоПро CSP.

Поддерживаемые технологии хранения ключей

В криптопровайдере КриптоПро CSP 5.0 впервые появилась возможность использования ключей, хранящихся на облачном сервисе КриптоПро DSS, через интерфейс CryptoAPI. Теперь ключи, хранимые в облаке, могут быть легко использованы как любыми пользовательскими приложениями, так и большинством приложений компании Microsoft.

Носители с неизвлекаемыми ключами и защищенным обменом сообщениями

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

Компании Актив, ИнфоКрипт и СмартПарк разработали новые защищенные токены, которые поддерживают данный протокол.

Многие пользователи хотят иметь возможность работать с неизвлекаемыми ключами, но при этом не обновлять токены до уровня ФКН. Специально для них в провайдер добавлена поддержка популярных ключевых носителей Рутокен ЭЦП 2.0, JaCarta-2 ГОСТ и InfoCrypt VPN-Key-TLS.

Классические пассивные USB-токены и смарт-карты

Большинство пользователей предпочитает быстрые, дешевые и удобные решения для хранения ключей. Как правило, предпочтение отдаётся токенам и смарт-картам без криптографических сопроцессоров. Как и в предыдущих версиях провайдера, в КриптоПро CSP 5.0 сохранена поддержка всех совместимых носителей производства компаний Актив, Аладдин Р. Д., Gemalto/SafeNet, Multisoft, NovaCard, Rosan, Alioth, MorphoKST и СмартПарк.

Кроме того, конечно, как и раньше поддерживаются способы хранения ключей в реестре Windows, на жестком диске, на флеш-накопителях на всех платформах.

Список производителей и моделей поддерживаемых КриптоПро CSP 5.0 R2

Инструменты КриптоПро

В составе КриптоПро CSP 5.0 появилось кроссплатформенное (Windows/Linux/macOS) графическое приложение — «Инструменты КриптоПро» («CryptoPro Tools»).

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

С помощью Инструментов КриптоПро решаются задачи управления контейнерами, смарт-картами и настройками криптопровайдеров, а также мы добавили возможность создания и проверки электронной подписи PKCS#7.

Поддерживаемое программное обеспечение

КриптоПро CSP позволяет быстро и безопасно использовать российские криптографические алгоритмы в следующих стандартных приложениях:

Интеграция с платформой КриптоПро

С первого же релиза обеспечивается поддержка и совместимость со всеми нашими продуктами:

Операционные системы и аппаратные платформы

Традиционно мы работаем в непревзойдённо широком спектре систем:

Таблица операционных систем, поддерживаемых разными версиями КриптоПро CSP.

Классификация операционных систем для использования КриптоПро CSP c лицензией на рабочее место и сервер.

Интерфейсы для встраивания

Для встраивания в приложения на всех платформах КриптоПро CSP доступен через стандартные интерфейсы для криптографических средств:

Производительность на любой вкус

Многолетний опыт разработки позволяет нам охватить все решения от миниатюрных ARM-плат, таких как Raspberry PI, до многопроцессорных серверов на базе Intel Xeon, AMD EPYC и PowerPC, отлично масштабируя производительность.

Регулирующие документы

Средство
криптографической защиты информации
КриптоПро CSP используется в ЦС, ЦР, АРМ
администратора и АРМ пользователей в
качестве средства, реализующего
криптографические функции (средства
ЭЦП).

Средство
криптографической защиты информации
КриптоПро CSP
разработано в соответствии с
криптографическим интерфейсом фирмы
Microsoft — Cryptographic Service Provider (CSP) и функционирует
в следующих операционных системах :

Основные
функции, реализуемые КриптоПро CSP:

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

СКЗИ
КриптоПро CSP
является системой с открытым распределением
ключей. Открытые ключи подписи и
шифрования представляются в виде
сертификатов открытых ключей. Закрытый
ключ ЭЦП может быть использован только
для формирования ЭЦП. Закрытый ключ
шифрования может быть использован как
для формирования ключа связи с другим
пользователем, так и для формирования
ЭЦП.

СКЗИ
КриптоПро CSP используется в двух вариантах
исполнения:

Nginx Шаг 5

Казалось бы мы настроили первое правило script-src — но нет. В нашем правиле есть ключевое слово ‘unsafe-inline’ который означает что мы разрешаем использование всех встроенных скриптов. Использование этого ключевого слова считается небезопасным.

Давайте попробуем удалить это ключевое слово, и посмотреть что будет:


CSP КОМПОНЕНТЫ

Высокая вероятность того что вы получите такую ошибку выше, и скорее всего подобных ошибок будет +- около 10, а то и больше, в зависимости от того сколько встроенных скриптов вы используете.

Так что же тут случилось, откуда тут вообще взялась эта ошибка?

Так как мы отказались от ключевого слово ‘unsafe-inline’ — то мы отказались и от использования встроенных скриптов. Теперь же нам нужно научиться “помечать” какие встроенные скрипты являются безопасными.

Хорошей практикой считается добавлять для наших встроенных скриптов атрибут nonce, и указывать в нем динамический хеш, тем самым валидируя скрипты. Этот динамический хеш будет генерироваться нашим сервером nginx. Таким образом, если встроенный скрипт не будет иметь хеш, или он будет не совпадать — то nginx откажется его подгружать, тем самым мы себя обезопасим от разных атак.

Настройка хеша, включает в себя изменение кода как со стороны frontend так и со стороны nginx.

Для начала начнем со стороны frontend. В целом, описанные ниже шаги можно применить на большинство фреймворков и библиотек, так как основные настройки делаются в корневом index.js и в webpack конфиге.

Nginx Шаг 3

Далее будет не лишним настроить протокол https, чтобы наш сайт открывался по https://localhost:3000

Для этого нам нужно сгенерировать ssl сертификат. В терминале переходим в папку, в которую сгенерируем 2 новых файла. Лично мне удобно открыть WebStorm со своим проектом, и использовать встроенный терминал.

Вводим в терминал команду openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem

После выполнения команды жмем enter чтобы скипать шаги до шага Common name.

На этом моменте для Common name вводим 127.0.0.1

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

В корне проекта появиться два файла cert.pem key.pem

Далее нам нужно перенести эти два файла в папку /usr/local/etc/ca-certificates или /opt/homebrew/etc/ca-certificates

И в конфиге nginx добавить следующие поля ниже поля server_name

P. S Опять же путь до файлов может отличаться

ssl_certificate /usr/local/etc/ca-certificates/cert.pem;

ssl_certificate_key /usr/local/etc/ca-certificates/key.pem;

Так же требуется добавить приписку ssl для поля listen

Получиться примерно так:

Перезапускаем nginx командой sudo nginx -s stop && sudo nginx

Теперь сайт должен открываться на https://localhost:3000

Руководство по настройке

После установки токена JaCarta PKI в USB порт сервера и запуска системы проверяем, что новое устройство обнаружено и появилось в списке:


CSP КОМПОНЕНТЫ

В нашем случае это Bus 004 Device 003: ID 24dc:0101

Для диагностики считывателей можно воспользоваться утилитой pcsc-tools из проекта security:chipcard (software.opensuse.org).

Пока не установлены все необходимые пакеты, информация о токене не отобразится.

Установка драйверов и ПО для работы с JaCarta PKI

На странице Поддержки сайта «Аладдин Р. Д.» загружаем Документацию и программное обеспечение для работы только с JaCarta PKI

Согласно Руководству по внедрению «JaCarta для Linux» пункт 4.2., первым делом требуется установить пакеты pcsc-lite, ccid и libusb.

Для работы утилиты управления JaCarta необходимо установить следующие компоненты:

Выполняем проверку наличия этих пакетов и установку:

zypper search pcsc-lite


CSP КОМПОНЕНТЫ

zypper search libusb


CSP КОМПОНЕНТЫ

zypper install pcsc-lite


CSP КОМПОНЕНТЫ

zypper search CCID


CSP КОМПОНЕНТЫ

zypper install pcsc-ccid


CSP КОМПОНЕНТЫ

CSP КОМПОНЕНТЫ

zypper install libusb

В итоге пакет pcsc-lite был обновлен, CCID установлен, libusb никаких действия не требовалось.

Следующими двумя командами выполняем установку пакета с драйверами и программным обеспечением непосредственно для работы с JaCarta PKI:

zypper install idprotectclientlib-637.03-0.x86_64.rpm


CSP КОМПОНЕНТЫ

zypper install idprotectclient-637.03-0.x86_64.rpm


CSP КОМПОНЕНТЫ

Проверяем, что драйверы и ПО для JaCarta PKI установились:

zypper search idprotectclient


CSP КОМПОНЕНТЫ

При попытках заставить работать SafeNet eToken PRO я нашел информацию, что предустановленный в SLES пакет openct — Library for Smart Card Readers может конфликтовать с pcsc-lite — PCSC Smart Cards Library, установку которого требует руководство Аладдин Р. Д.

zypper search openct


CSP КОМПОНЕНТЫ

Поэтому пакет openct удаляем:

rpm -e openct

Теперь все необходимые драйверы и ПО для работы с токеном установлены.

Выполняем диагностику с помощью утилиты pcsc-tools и убеждаемся, что JaCarta определяется в операционной системе:


CSP КОМПОНЕНТЫ

Установка пакетов КриптоПро CSP

При установке КриптоПро CSP по умолчанию нужные пакеты для работы с токенами и смарт-картами отсутствуют.

zypper search cprocsp


CSP КОМПОНЕНТЫ

Выполняем установку в CSP компонента поддержки JaCarta components for CryptoPro CSP

zypper install cprocsp-rdr-jacarta-64-3.6.408.683-4.x86_64.rpm


CSP КОМПОНЕНТЫ

Некоторые компоненты имеют зависимости. Так, например, если попытаться выполнить установку пакета поддержки SafeNet eToken PRO cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm — EMV/Gemalto support module, то получим сообщение о необходимости сначала установить базовый компонент CSP поддержки считывателей cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm — PC/SC components for CryptoPro CSP readers:

Устанавливаем базовые пакеты поддержки считывателей и ключевых носителей:

zypper install cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm


CSP КОМПОНЕНТЫ

zypper install lsb-cprocsp-pkcs11-64-4.0.9944-5.x86_64.rpm

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

zypper install cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm


CSP КОМПОНЕНТЫ

zypper install cprocsp-rdr-novacard-64-4.0.9944-5.x86_64.rpm
zypper install cprocsp-rdr-mskey-64-4.0.9944-5.x86_64.rpm
zypper install cprocsp-rdr-gui-gtk-64-4.0.9944-5.x86_64.rpm


CSP КОМПОНЕНТЫ

Проверяем итоговую конфигурацию КриптоПро CSP:


CSP КОМПОНЕНТЫ

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

/etc/init.d/cprocsp restart
/etc/init.d/cprocsp status


CSP КОМПОНЕНТЫ

Настройка и диагностика КриптоПро CSP

Проверим, видит ли криптографический провайдер наш токен и другие доступные типы носителей следующими командами:

/opt/cprocsp/bin/amd64/csptest -card -enum -v –v


CSP КОМПОНЕНТЫ

CSP КОМПОНЕНТЫ

/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -view -f cp1251


CSP КОМПОНЕНТЫ

Следуя инструкции КриптоПро CSP для Linux. Настройка, выполняем его регистрацию в криптографическом провайдере:

Чтобы выполнить требования Формуляра, Правил пользования и Руководства администратора безопасности КриптоПро CSP:

Использование СКЗИ «КриптоПро CSP» версии 4.0 с выключенным режимом усиленного контроля использования ключей не допускается. Включение данного режима описано в документах ЖТЯИ.00087-01 91 02. Руководство администратора безопасности.

Необходимо включить режим усиленного контроля использования ключей:

/opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long StrengthenedKeyUsageControl 1

Проверяем, что режим включен:


CSP КОМПОНЕНТЫ

Выполняем перезапуск службы криптографического провайдера:

После перезапуска проверяем, что ошибок в работе провайдера с ключевыми носителями нет:

/opt/cprocsp/bin/amd64/csptest -keyset –verifycontext


CSP КОМПОНЕНТЫ

/opt/cprocsp/bin/amd64/csptest -keyset -verifycontext -enum –unique

Работа с токеном JaCarta PKI

Запустим программу Xming (X11 forwarding) на своей станции, чтобы по SSH иметь возможность открывать и работать с графическими интерфейсами нужных утилит.

Это ярлыки, в которых можно посмотреть параметры запуска утилит Exec=/usr/bin/SACTools

Запустим утилиту IDProtectPINTool.

С помощью нее задаются и меняются PIN-коды доступа к токену.


CSP КОМПОНЕНТЫ

При первой инициализации токена будет полезна ссылка, содержащая PIN-коды (пароли) ключевых носителей по умолчанию

Программа IDProtect_Manager позволяет просматривать информацию о токене и контейнере с ключами и сертификатом:


CSP КОМПОНЕНТЫ

Для доступа к контейнеру с ключами нужно ввести пароль:


CSP КОМПОНЕНТЫ

CSP КОМПОНЕНТЫ

Для работы с SafeNet Authentication Client eToken PRO существуют аналогичные программы — SafeNet Authentication Client Monitor и SafeNet Authentication Client Tools, которые запускаются так:


CSP КОМПОНЕНТЫ

Выполнять операции непосредственно с ключевыми контейнерами удобнее в интерфейсе криптографического провайдера КриптоПро JavaCSP:


CSP КОМПОНЕНТЫ

Для отображения информации о содержимом контейнера с ключами можно выполнить команду:

Для диагностики контейнера используется эта же команда с ключом –check

Потребуется ввести пароль от контейнера:


CSP КОМПОНЕНТЫ

Программное извлечение ключей

В общем виде пример извлечения закрытого ключа и сертификата открытого ключа из контейнера на токене с помощью КриптоПро Java CSP следующий:

Если действовать так:

Key key = keyStore.getKey(keyAlias, pwd);

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

Результаты

Отторгаемый ключевой носитель-токен установлен во внутренний USB-порт сервера.

Само серверное оборудование опломбировано и размещается в помещении с ограниченным доступом.

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

Полезные ссылки

В
состав программного комплекса
«Удостоверяющий Центр» входят следующие
компоненты:

Центр
сертификации (ЦС) в составе:

Центр
регистрации (ЦР) в составе:

АРМ
администратора в составе:

АРМ
разбора конфликтных ситуаций:

Nginx Шаг 2

Теперь нам нужно сбилдить нашу статику и положить ее в usr/local/var/www или /opt/homebrew/var/www

В моем проекте это делается командой yarn run build

На выходе получаем папку static, берем ее внутренности и перемещаем в usr/local/var/www

После этого перезапускаем nginx командой sudo nginx -s stop && sudo nginx

Теперь на http://localhost:3000мы должны увидеть наше приложение

P. S Этот шаг нужно повторять каждый раз, когда вы обновляете код своего приложения, если хотите проверить результат

Nginx Шаг 1

В зависимости от вашей os, команды по установке и запуску nginx могут немного отличаться. Так как я использую mac os, я устанавливал nginx через brew (https://brew.sh)

После того как мы установили nginx, у нас есть доступ к базовой конфигурации.

Для Mac Os nginx лежит по адресу /usr/local/etc/nginx либо /opt/homebrew/etc/nginx/nginx.conf базовый конфиг nginx.conf

Первое что я хотел сделать — чтобы nginx, для начала, просто отдавал мою статику.

Поэтому мой базовый конфиг для локальной работы выглядел так:

В данном случае наш сервер должен отдавать статику по адресу http://localhost:3000/

Теперь можем запустить nginx командой sudo nginx

Если мы перейдем по адресу http://localhost:3000/ то должны увидеть что то вроде этого:


CSP КОМПОНЕНТЫ

Что дальше?

При локальной разработке у меня используется сервер на node.js «start»: «node scripts/start.js»

Но для нашего тестирования CSP нам потребуется настраивать заголовки на сервере, и самым популярным решением является поднять локально сервер на nginx вместо нашего скрипта.

Nginx Шаг 6

После того как мы добавили nonce=»CSP_NONCE» ко всем встроенным скриптам и стилям, нужно расширить конфигурацию nginx, и добавить:

Два поля в раздел location:

sub_filter **CSP_NONCE** $request_id;

Поле sub_filter_once указывает следует ли искать каждую строку для замены один раз.

Поле sub_filter задает строку для замены и строку замены.

То есть мы находим строку **CSP_NONCE** в нашей статике, и заменяем ее на значение переменной $request_id

Из заголовка удаляем строку unsafe-inline которая разрешала нам использование всех встроенных скриптов, и добавляем ‘nonce-$request_id’ и ‘strict-dynamic’

‘strict-dynamic’ — указывает, что доверие, явно предоставляемое скрипту, присутствующему в разметке, путем сопровождения его одноразовым значением или хэшем, должно распространяться на все скрипты, загруженные этим корневым скриптом.

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

После перезапуска nginx, у нас должны пропасть ошибки из консоли.

Структурная схема компонент.


CSP КОМПОНЕНТЫ

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

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

Автоматизированное
рабочее место (АРМ)
администратора Центра Регистрации –
это компонент, который предназначен
для выполнения операций, связанных с
регистрацией пользователей, формированием
закрытых ключей и запросов на сертификаты
открытых ключей, обработкой запросов
на сертификаты открытых ключей, получением
изданных Центром Сертификации
сертификатов, управлением (аннулированием,
приостановлением и возобновлением
действия) сертификатов и выполнением
иных действий по выполнению целевых
функций Удостоверяющего Центра.

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

АРМ
пользователя Удостоверяющего центра
– веб-приложение (набор веб-страниц),
размещенное на Центре Регистрации и
предназначенное для регистрации
пользователей, формирования ключей и
запросов на сертификаты открытых ключей,
получения изданных сертификатов и их
управления непосредственно с рабочего
места пользователя Удостоверяющего
центра.

Основными
задачами
удостоверяющего центра являются:

2. Установка серверной и клиентской ОС
на ВМ.

Для
настройки и проверки локальной сети
необходимо было установить на одну
виртуальную машину не только сервер,
но и на другую виртуальную машину клиент.
В качестве сервера была выбрана ОС
Windows
Server
2008, в качестве клиента была выбрана ОС
Windows
XP
Professional.
Установка велась на виртуальную машину
VM
Ware.

2.1. Установка клиентской ОС.

Приводятся
скриншоты хода установки ОС Windows
XP
Professional
(рисунки 1-2).


CSP КОМПОНЕНТЫ

Рисунок
1 – Установка
Windows XP Professional.


CSP КОМПОНЕНТЫ

Рисунок
2 – Установка
Windows XP Professional.

2.2. Установка серверной ОС.

Была
произведена схожая установка ОС Windows
Server
2008.

Приводится
скриншот рабочего стола, уже установленной,
ОС Windows
Server
2008 (рисунок 3).


CSP КОМПОНЕНТЫ

Рисунок
3 – Рабочий стол установленной ОС Windows
Server
2008.

2.3. Настройка сети между двумя виртуальными
машинами, на которых установлены Windows
Server 2008 и Windows
XP.

В
настройках обоих виртуальных машин
производим привязку физического адаптера
к ним. По средствам задания свойству
Network
adapter
значения Bridged
(рисунок 4).


CSP КОМПОНЕНТЫ

Рисунок
4 – Настройка виртуальных машин для
создания сети между ними.

В
настройках интернет подключения сервера
указываем следующие данные (рисунок
5).


CSP КОМПОНЕНТЫ

Рисунок
5 – Настройка интернет подключения для
сервера.

В
настройках интернет подключения клиента
указываем следующие данные (рисунок 6)


CSP КОМПОНЕНТЫ

Рисунок
6 – Настройка интернет подключения для
клиента.

Nginx Шаг 4

По идее сейчас все готово для того чтобы внедрять политику CSP.

Для того чтобы ее настраивать нам нужно понимать как она работает.

А работает она с помощью заголовка Content-Security-Policy, мы будем описывать правила, которые браузер должен будет соблюдать, а если какое-либо действие пользователя будет не по правилам — браузер откажется это выполнять.

Настройка начинается с того, что сначала мы запрещаем все, а потом начинаем добавлять исключения.

Начнем с правила script-src оно определяет допустимые источники JavaScript.

В nginx  добавляем заголовок со следующим значением:

add_header Content-Security-Policy «script-src ‘self’ ‘unsafe-inline'»;

В коде это выглядит так:

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


CSP КОМПОНЕНТЫ

Это говорит нам о том, что у нас есть источник который не описан в политике csp, и поэтому браузер его не загружает, давайте добавим источник в список разрешенных.

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

Nginx Шаг 7

Теперь продолжим добавлять различные директивы, например style-src со значением self

Перезапускаем nginx, обновляем страницу, и смотрим ошибки в консоли.

Скорее всего самые первые ошибки будут указывать на ресурсы, которых нет в white list.

Добавляем ресурс и nonce:

style-src “’self’ ‘nonce-$request_id’ https://*.example.com”

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

По такому принципу, вы можете добавить остальные директивы.

У вас получиться примерно так:

В целом на этом моменте можно считать настройку CSP завершенной.

Настройка frontend приложения

Сама настройка заключается в том, что мы должны добавить атрибут nonce=»CSP_NONCE» ко всем встроенным скриптам. Само значение CSP_NONCE на самом деле может быть любым. Это значение нужно для того, чтобы бы в будущем наш nginx находил это значение в статических файлах js, html и заменял на динамический хеш.

Начнем с простого, зайдем в наш index.html файл, и добавим этот атрибут ко всем подключаемым скриптам, стилям и шрифтам. К примеру у меня есть следующие скрипт и шрифт, в которые я добавляю атрибут:

Добавляем в наш index.html следующую запись

На эту запись могут ориентироваться некоторые UI библиотеки, например Material UI

Так же добавляем в index.html следующий скрипт

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

Как правило в этом месте описаны настройки для различных плагинов eslint, html.

Нам нужно установить плагин html-webpack-inject-attributes-plugin

Подключить его вверху конфига:

И добавить следующую запись последним элементов массива plugins

Так как использую react, у меня есть скрипт scripts/build.js, который запускается командой yarn run build , этот файл используется для сборки приложения в production

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

process.env. INLINE_RUNTIME_CHUNK = «false»;

Открываем наш корневой index.js, и в самый вверх добавляем запись:

// eslint-disable-next-line no-undef
__webpack_nonce__ = window.__webpack_nonce__;

ЭЦП:  КАК ПОДПИСАТЬ ДОКУМЕНТ ЭЛЕКТРОННОЙ ПОДПИСЬЮ В WORD
Оцените статью
ЭЦП64
Добавить комментарий