«Интернет сегодня, это результат компромисса между открытостью и безопасностью, где второй всегда приносился в жертву первому. Но если бы изначальным условием было «ничего не работает без криптографического доказательства», мы бы получили другую сеть — не добавлением защитных слоёв, а перепроектированием её атомарных частиц. Это не просто мечта, а альтернативная архитектура, которая показывает, почему современная регуляторика вынуждена работать с тем, что есть.»
Протоколы и архитектура как доказательство происхождения
Ядро интернета — стек TCP/IP — проектировалось для соединения доверенных узлов в закрытой академической среде. IP-адрес в заголовке пакета никогда не был удостоверением личности; это просто указатель для маршрутизации, который можно подделать. В мире, где безопасность была бы фундаментом, базовый протокол передачи данных потребовал бы криптографического подтверждения права на использование IP-адреса для каждого отправленного пакета.
Механизм мог бы напоминать Proof-of-Work, но для сетевого уровня: прежде чем маршрутизатор принял пакет, отправитель должен был бы предъявить токен, доказывающий владение приватным ключом, связанным с его сетевым префиксом. Такой подход устранил бы спуфинг и DoS-атаки с поддельными адресами на уровне сетевой инфраструктуры, а не на уровне межсетевых экранов и систем обнаружения вторжений. Архитектура сети изначально отвергала бы анонимные пакеты.
Такая модель перекликается с современными идеями, например, с концепцией RPKI (Resource Public Key Infrastructure), которая пытается криптографически привязать IP-адреса к их владельцам. Но RPKI, это надстройка, требующая добровольного внедрения. Если бы это было требованием протокола, BGP-хуки и атаки на маршрутизацию стали бы технически невозможны.
Идентификация и доверенные корни
DNS — телефонная книга интернета — изначально создавалась как открытый и распределённый справочник. Безопасность (DNSSEC) добавили спустя десятилетия, и её внедрение до сих пор фрагментарно. В альтернативной архитектуре криптография была бы неотъемлемой частью разрешения имён.
Каждый DNS-запрос и ответ автоматически подписывались бы и проверялись. Цепочка доверия начиналась бы не с набора корневых сертификатов, встроенных в браузер, а с аппаратного или системного ключа, вшитого в сетевое устройство или ОС. Регистрация нового домена включала бы не только внесение записи в реестр, но и генерацию криптографической пары ключей, публичная часть которой сразу становилась частью глобальной иерархической структуры доверия.
Это создало бы систему, где фишинг на уровне DNS был бы исключён, так как браузер не мог бы получить «легитимный» ответ, ведущий на поддельный IP-адрес. Вся инфраструктура PKI (Public Key Infrastructure) для web слилась бы с DNS, устранив необходимость в отдельных центрах сертификации для TLS.
Сертификаты как встроенная проверка, а не внешняя покупка
В нынешней модели HTTPS, это договорённость между браузером и сервером использовать шифрование, подтверждённое сертификатом от доверенного центра. Сертификат, это внешний артефакт, который нужно купить, установить и периодически обновлять. В безопасной с нуля архитектуре понятие «сертификат» в его нынешнем виде исчезло бы.
Владение доменом криптографически означало бы наличие права подписывать контент для этого домена. При установке соединения сервер автоматически предъявлял бы криптографическое доказательство, сгенерированное на основе ключей домена, а клиент проверял бы его по цепочке доверия, идущей от встроенного корня. Не было бы этапа выбора центра сертификации, оплаты и верификации по email.
Архитектура соединения
Установка защищённого соединения выглядела бы не как многоэтапный handshake, а как единый криптографически верифицируемый процесс.
- Клиент формирует запрос, включающий доменное имя и криптографический nonce (одноразовое число).
- Этот запрос автоматически направляется через безопасную DNS, которая возвращает не только IP-адрес, но и подписанное утверждение от реестра о привязке ключей к домену.
- Сервер, получив запрос, отвечает подписанным доказательством, созданным с использованием своего приватного ключа домена и nonce клиента.
- Проверив подпись, клиент сразу начинает шифрование трафика, используя выведенный из этого обмена сессионный ключ.
Такой подход исключает атаки типа «man-in-the-middle» на этапе рукопожатия и делает невозможным обслуживание сайта без криптографически подтверждённых прав на домен.
Централизация доверия против распределённости
Фундаментальная безопасность требует ответа на вопрос: кому вы доверяете изначально? В текущем интернете доверие распределено между сотнями центров сертификации, встроенных в ПО. В архитектуре, построенной на безопасности, иерархия доверия, вероятно, была бы более централизованной и явной.
Существовало бы ограниченное число глобальных корневых центров, чьи ключи аппаратно защищены и законодательно закреплены. Каждое сетевое устройство и ОС при изготовлении получали бы корневой сертификат этого центра. Распределённость сохранялась бы на уровне маршрутизации и данных, но не на уровне криптографической идентификации.
Эта модель напрямую соотносится с регуляторными подходами, например, с отечественными доверенными корнями или инфраструктурой квалифицированной электронной подписи. Она даёт регулятору рычаг контроля над источниками доверия в сети, но одновременно создаёт единые точки отказа и потенциального контроля. Баланс между безопасностью и свободой был бы смещён в сторону контролируемой верифицируемости.
Учёт и аудит как часть протокола
Сегодня журналы безопасности, это надстройка. Сервера, маршрутизаторы, базы данных пишут логи по собственной инициативе и в своём формате. В протоколе изначально не заложено обязательство оставлять криптографические следы.
В альтернативной архитектуре ключевые сетевые события (установление соединения, изменение маршрута, делегирование домена) могли бы требовать формирования криптографически подписанного «чека» или транзакции. Эти транзакции не обязательно публиковались бы в общий реестр, как в блокчейне, но сохранялись у участников взаимодействия и в доверенных аудиторских узлах.
Такой встроенный механизм обеспечивал бы неотрекаемость и возможность бесспорного аудита. Например, можно было бы доказать, что пакет от конкретного IP в определённое время прошёл через конкретные маршрутизаторы, или что делегирование домена было санкционировано его владельцем. Это напрямую отвечало бы требованиям 152-ФЗ к обеспечению учёта событий безопасности и недекларированных возможностей в средствах защиты информации.
Фактически, регуляторное требование «обеспечить журналирование» превратилось бы из директивы в следствие архитектурного решения.
Как эта гипотетическая модель влияет на текущую регуляторику
Требования ФСТЭК и 152-ФЗ сегодня, это попытка наложить жёсткий каркас безопасности на гибкую и открытую архитектуру. Они предписывают шифрование каналов, аутентификацию, контроль целостности и учёт событий. В интернете, безопасном с самого начала, большинство этих требований выполнялось бы автоматически на протокольном уровне.
Современная регуляторика таким образом компенсирует архитектурные уязвимости. Например, требование использовать VPN или TLS, это реакция на отсутствие шифрования в IP. Требование строгой аутентификации — ответ на возможность спуфинга.
Это приводит к выводу, который важен для IT-специалиста и регуляторщика: часть мер защиты в современных стандартах и законах является не фундаментальной, а компенсационной. Они не создают новую безопасную среду, а пытаются «залатать» существующую. Понимание этого разделения позволяет более адекватно оценивать риски и выбирать решения: одни меры борются с фундаментальными недостатками архитектуры, а другие — с её конкретными эксплуатационными уязвимостями.
Гипотетическая модель также указывает вектор для разработки новых изолированных систем (например, государственных или корпоративных сегментов), где регуляторные требования можно зашить в архитектуру, а не навязывать поверх. Это может снизить сложность и стоимость соответствия, так как безопасность будет не настраиваемой опцией, а свойством по умолчанию.