Секреты сами по себе не ценны. Ценно то, что они защищают

Обо мне

Меня зовут Кирилл Захаров, я старший аналитик в компании БФТ-Холдинг. Сейчас занят написанием статьи про СКЗИ, а в перерыве занимаюсь проектированием системы долговременного ухода. К сожалению, пока что платят деньги только за последнее.

Эта статья будет полезна:

• системным аналитикам, которые сталкиваются с темой криптографии и СКЗИ впервые;

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

• разработчикам, которым нужно лучше осознать требования заказчика «с точки зрения аналитика».

Введение

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

 Я постараюсь сегодня довольно доступно и наглядно рассказать, что это, зачем это и почему это.

СКЗИ — это не страшный перечень букв, а всего лишь инструменты, которые позволяют:

• зашифровать данные (чтобы никто не подсмотрел),

• подписать (чтобы доказать авторство),

• проверить целостность (чтобы никто не подменил по пути).

И именно аналитик в проекте часто должен заложить правильные требования к интеграции, чтобы потом всё работало.

Что такое СКЗИ простыми словами

СКЗИ = средства криптографической защиты информации.

В России это сертифицированные продукты (КриптоПро, VipNet, SignalCom, Рутокен и т. д.), без которых в госинтеграциях нельзя ни шагу.

Давайте иначе:

«СКЗИ — это как бронированный конверт с печатью. Его можно отправить по почте, и получатель будет уверен, что внутри то, что положили, и никто не вскрыл по дороге».

Но что про интеграции?

В REST всё просто: 

чаще всего хватает защищённого канала (TLS с ГОСТ-алгоритмами). Но бывают ситуации, когда дополнительно требуется подпись запроса. Вот и пример:

POST /api/payment
Host: secure-api.example.ru
Content-Type: application/json
Signature: MEQCIFh...

{
  "payerId": "12345",
  "amount": 1000,
  "currency": "RUB"
}

Signature — это электронная подпись, сформированная закрытым ключом.

Сервер проверяет её открытым ключом.

Если данные изменились хоть на символ → проверка не пройдёт

 А теперь о SOAP.

SOAP — это протокол обмена структурированными сообщениями, построенный на основе XML. В интеграциях через СМЭВ он используется для формирования запросов и ответов. Его спецификация предполагает наличие заголовков и тела, где как раз и хранится электронная подпись, обеспечивающая достоверность и неизменность данных:

<soap:Envelope>
  <soap:Header>
    <wsse:Security>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:Reference URI="#body"/>
        </ds:SignedInfo>
        <ds:SignatureValue>kKJH...98=</ds:SignatureValue>
        <ds:KeyInfo>
          <ds:X509Data>сертификат ГОСТ</ds:X509Data>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body Id="body">
    <GetCitizenData>
      <SNILS>123-456-789 00</SNILS>
    </GetCitizenData>
  </soap:Body>
</soap:Envelope>

 Здесь подпись подтверждает и целостность данных, и то, что запрос пришёл от доверенного источника.

Закрытый ключ, открытый ключ… Я сюда картинки пришел смотреть

Пара ключей — закрытый и открытый — это основа асимметричной криптографии. Именно она лежит в базе электронной подписи и сертификатов.

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

Закрытый ключ:

• Хранится только у владельца.

• Никому не передаётся.

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

Открытый ключ:

• Доступен всем.

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

Пример:

1. У тебя есть документ (например, JSON-заявление).

2. Ты берёшь свой закрытый ключ и создаёшь подпись.

3. Отправляешь документ + подпись.

4. Сервер берёт твой открытый ключ и проверяет:

   • подходит ли подпись к документу,

   • и действительно ли она сделана «тем самым закрытым ключом».

Если документ изменили по пути — проверка не пройдёт.

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

Казалось бы да, но… 

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

Сложности аналитика

 Когда я по своей глупости спросил у заказчика - надо ли подписывать запросы, в ответ прозвучало твердое и четкое ДА. Я до сих пор не уверен, что мой заказчик понимал вообще, что такое «запрос». Больше я таких вопросов ему не задаю.

При этом вопрос, как мне кажется, сам по себе неплохой, и это одна из проблем в использовании СКЗИ. Понять о необходимости криптографии в системе, это уже большой проделанный путь. Вы можете возразить: «Но ведь подобное прописано в ТЗ!». О да… Мы все видели эти размытые формулировки без четкого пояснения.

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

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

Наконец-то итог

Сложно? Ну немного. Страшно? Вроде нет.

Системному аналитику важно понимать:

• Где в интеграции нужен защищённый канал (TLS)

• Где обязательно накладывать электронную подпись, а где лучше помолчать

• Как прописать в требованиях работу с сертификатами

• Понимать все сложности наперед и быть к ним готовым

Но самое главное. Если аналитик понимает, какой «конверт» нужен в конкретной точке системы, он превращается из «человека, который рисует BPMN» в ценного эксперта, умеющего проектировать безопасные интеграции.