Что выбрать и как не ошибиться?
В одном крупном холдинге считают, что утечки случаются, когда сотрудники ошибаются. На самом деле чаще всего срабатывает тихое правило трёх рукопожатий. Достаточно, чтобы человек подключился к внутренней системе, потом зашёл в личный кабинет, а после открыл почту. Три шага и система безопасности видит, кто именно сейчас сидит за клавиатурой, даже если он использует корпоративный VPN.
Причина проста каждый сервис оставляет невидимый след размерами пакетов. Анализируя эти следы, можно понять, что именно делает человек, не расшифровывая содержимое. Поэтому защита канала не всегда защищает самого человека.
Сетевая безопасность устроена странно. Все знают про замочек в браузере. Но почти никто не понимает, что происходит в тот момент, когда ты открываешь банковское приложение через корпоративный VPN. Там работают два разных механизма защиты одновременно. Они не дублируют друг друга. Они закрывают разные векторы атак в разных точках сетевого стека.
SSL/TLS и IPsec решают одну задачу - не дать перехватить данные. Но делают это так непохоже, что сравнивать их как "два способа шифрования" бессмысленно. Они функционируют на разных уровнях модели OSI и отражают различные типы угроз.
Зачем это вообще знать
Представь что ты настраиваешь удалённый доступ к рабочему серверу. Админ говорит "поднимем IPsec". Разработчик говорит "достаточно HTTPS". Оба правы. Оба неправы. Потому что они говорят о разных слоях защиты и не понимают где именно у второго появляется слепая зона.
Или другая ситуация. Компания перешла на удалёнку. Сотрудники работают из дома, подключаются к корпоративной сети. Кто-то поднял VPN на IPsec. Кто-то решил что хватит SSL-туннеля. Через полгода выясняется что половина подключений идёт в обход защиты потому что кто-то не понял разницу между защитой канала и защитой приложения.
Знание разницы не делает тебя сетевым инженером. Зато показывает, где именно образуются бреши в защите, даже когда кажется что периметр полностью закрыт.
Где данные становятся уязвимыми
Модель OSI обычно преподают как семь абстрактных уровней. Физический, канальный, сетевой, транспортный, сеансовый, представительский, прикладной. Запомнить легко, понять зачем невозможно. Потому что её подают как академическую схему, а не как карту потенциальных точек компрометации.
Посмотри на это с другой стороны. Данные проходят через сеть слоями. Каждый слой добавляет свои заголовки, свою служебную информацию. На каждом уровне есть момент когда данные открыты. Полностью или частично.
Третий уровень - сетевой. Здесь живут IP-адреса. Маршрутизаторы решают куда отправить пакет дальше. Они читают заголовок IP, смотрят адрес назначения, выбирают маршрут. В этот момент любой кто контролирует маршрутизатор видит кто кому пишет. Не содержимое пакета, а метаданные. Отправитель, получатель, размер пакета, время передачи.
Метаданные - это уже большая часть разведданных. Зная кто с кем общается и как часто, можно многое вывести даже без расшифровки содержимого.
Четвёртый уровень - транспортный. TCP или UDP. Здесь управляют потоком данных, делят их на сегменты, следят за доставкой. Тут добавляются порты. Номер порта показывает какому приложению предназначены данные. Порт 443 это HTTPS, порт 22 это SSH, порт 25 это почта. Кто видит транспортный уровень, тот знает не только кто с кем говорит, но и какой сервис используется.
Седьмой уровень - прикладной. Здесь работают браузеры, почтовые клиенты, мессенджеры. Здесь данные существуют в исходном виде, ещё не упакованные в транспортные обёртки. Твой запрос к серверу, ответ сервера, файлы, сообщения. Если на этом уровне нет шифрования, всё видно как на ладони.
А теперь вопрос. На каком уровне защищать?
Если защитить только седьмой уровень, метаданные останутся открыты. Кто-то увидит с кем ты общаешься и через какие сервисы. Если защитить только третий уровень, некоторые приложения всё равно могут сливать данные в незащищённом виде.
SSL/TLS работает между четвёртым и седьмым уровнями. Защищает данные приложения, но не скрывает кто с кем говорит. IPsec работает на третьем уровне. Шифрует весь пакет целиком, включая информацию о том какое приложение передаёт данные. Отсюда вся разница.
IPsec защищает маршрут
IPsec создаёт защищённый туннель между двумя точками сети. Представь два офиса компании в разных городах. Им нужно обмениваться данными так, будто они в одной локальной сети. Между офисами интернет, где любой промежуточный узел может перехватить пакеты.
Поднимаешь IPsec-туннель. Теперь все пакеты из первого офиса во второй шифруются на выходе, передаются через открытый интернет как непрозрачный поток, расшифровываются на входе во второй офис. Промежуточные маршрутизаторы видят только внешние заголовки. Откуда пришёл пакет, куда идёт, размер. Что внутри - неизвестно.
Внутри может быть что угодно. HTTP-запрос, SSH-сессия, обмен файлами по SMB, служебный трафик между серверами. IPsec не разбирает что именно летит. Ему всё равно. Он шифрует всё подряд.
У IPsec два режима работы. Транспортный и туннельный. В транспортном режиме шифруется только содержимое IP-пакета, заголовок с адресами остаётся открытым. В туннельном режиме весь исходный IP-пакет заворачивается в новый зашифрованный пакет с другими адресами. Чаще используют туннельный, потому что он скрывает структуру внутренней сети от внешних наблюдателей.
Настройка IPsec - это боль. Тебе нужно договориться о параметрах шифрования, алгоритмах, ключах. Эти параметры описываются через Security Policies - набор правил, которые определяют что защищать, между какими узлами и какими криптографическими методами. На маршрутизаторе прописываешь правила: весь трафик из подсети 10.0.1.0/24 в подсеть 10.0.2.0/24 шифровать таким алгоритмом с этими ключами.
Потом идёт согласование через IKE - Internet Key Exchange, протокол обмена ключами для IPsec. Два устройства обмениваются сообщениями, проверяют подлинность друг друга, договариваются о параметрах шифрования, генерируют сеансовые ключи. Процесс многофазный, съедает вычислительных ресурсов, но обеспечивает криптографически стойкое согласование.
IPsec громоздкий. Требует прав администратора на устройствах, доступа к маршрутизаторам, понимания сетевой топологии. Его не поднимешь быстро через веб-интерфейс за пять минут. Зато когда поднял, он защищает всё что идёт через туннель, без участия приложений.
Приложениям не нужно знать про IPsec. Они работают как обычно, отправляют данные в сеть, получают ответы. За шифрование отвечает инфраструктура уровнем ниже. Это и преимущество, и опасность IPsec одновременно. Плюс - универсальность, любое приложение автоматически защищено. Минус - если туннель не поднят или сломался, приложения об этом не узнают и будут слать трафик в открытую.
SSL/TLS защищает сессию
SSL/TLS работает иначе. Защита встроена в приложение. Когда браузер открывает HTTPS-сайт, он договаривается о шифровании напрямую с сервером. Никакие промежуточные устройства не участвуют. Маршрутизаторы даже не знают что данные зашифрованы, они просто передают пакеты дальше как обычно.
Процесс стартует с TLS handshake - процедуры установления защищённого канала между клиентом и сервером. Клиент отправляет серверу сообщение "привет, я хочу защищённое соединение, вот список алгоритмов шифрования которые я поддерживаю". Сервер отвечает "окей, выбираю вот этот алгоритм, вот мой сертификат, вот мой публичный ключ".
Сертификат - это цифровой документ, который подтверждает что сервер действительно тот, за кого себя выдаёт. Его выдаёт центр сертификации, которому доверяет клиент. Браузер проверяет подпись центра, проверяет срок действия, проверяет что домен в сертификате совпадает с доменом в адресной строке.
Если всё в порядке, клиент генерирует случайный симметричный ключ - один и тот же ключ используется для шифрования и расшифровки данных, что быстрее чем асимметричное шифрование с парой ключей. Клиент шифрует этот симметричный ключ публичным ключом сервера, отправляет обратно. Сервер расшифровывает его своим приватным ключом - вторым ключом из асимметричной пары, который известен только серверу. Теперь у обоих одинаковый секретный ключ, которым они шифруют всю дальнейшую передачу данных.
Симметричное шифрование на порядки быстрее асимметричного. Поэтому рукопожатие использует асимметричное шифрование только для обмена ключами, а саму сессию шифрует симметрично. Баланс между безопасностью и производительностью.
Весь этот механизм происходит на уровне приложения. Точнее между транспортным и прикладным уровнями. SSL/TLS встраивается в TCP-соединение, шифрует поток данных до того как его увидит приложение, расшифровывает после получения. Для приложения прозрачно. Браузер отправляет HTTP-запрос, SSL-библиотека шифрует его на лету, отправляет зашифрованный поток по сети.
На том конце SSL-библиотека сервера расшифровывает поток, передаёт чистый HTTP веб-серверу. Веб-сервер отвечает обычным HTTP, библиотека шифрует ответ, отправляет обратно. Браузер расшифровывает, показывает страницу.
Что видят промежуточные узлы? IP-адреса отправителя и получателя. Порт назначения (443 для HTTPS). Размер передаваемых данных. Периодичность обмена. Всё остальное - зашифровано. Какую именно страницу загружает браузер, какие данные отправляет в форме, что приходит в ответе - зашифрованный поток байтов.
Но домен они знают. Даже если содержимое зашифровано, начальное рукопожатие содержит запрос к конкретному домену через расширение SNI - Server Name Indication, механизм который позволяет одному серверу с одним IP-адресом обслуживать несколько доменов с разными сертификатами. Провайдер видит что ты подключаешься к example.com, но не видит к какой странице на example.com. Видит что ты отправил 500 килобайт данных, но не видит что именно.
SSL/TLS легко поднять. Купил сертификат или получил бесплатный от Let's Encrypt, настроил на сервере, готово. Клиенту вообще ничего делать не нужно, браузеры поддерживают HTTPS из коробки. Никаких политик безопасности, никаких туннелей, никаких прав администратора. Работает везде где есть TCP и возможность установить соединение.
Главное отличие от IPsec - SSL/TLS обеспечивает защиту конкретного приложения в рамках конкретной сессии. Если браузер открыл HTTPS-сайт, защищён только этот сайт. Если в это же время другое приложение отправляет данные по обычному HTTP, оно незащищено. IPsec закрыл бы оба потока, потому что работает уровнем ниже и не различает приложения.
Почему они не заменяют друг друга
Оба протокола шифруют данные. Оба защищают от перехвата. Но их никогда не проектировали как взаимозаменяемые решения. Они решают принципиально разные архитектурные задачи в разных частях сетевой инфраструктуры.
IPsec создан для защиты сети как транспортной среды. Его ставят когда нужно связать два удалённых офиса, дать сотрудникам безопасный доступ к корпоративной сети из дома, защитить обмен данными между серверами в дата-центре. Он работает ниже приложений и не различает какое именно приложение передаёт данные. Его задача - создать защищённый канал, внутри которого всё работает как в локальной сети.
SSL/TLS создан для защиты конкретного диалога между приложением и сервером. Его ставят когда нужно защитить веб-сайт, API, почтовый сервер, мессенджер. Он работает внутри приложения и не зависит от того как устроена сеть между клиентом и сервером. Его задача - убедиться что данные не перехватят и не подменят в процессе конкретной сессии.
Можно ли использовать SSL/TLS вместо IPsec для удалённого доступа? Можно. Есть SSL VPN, который создаёт туннель на основе TLS-соединения. Работает через браузер или лёгкий клиент, не требует прав администратора, проще в настройке. Корпорации используют его для сотрудников, которым нужен доступ к внутренним ресурсам с личных устройств.
Но SSL VPN - это технический компромисс, который заставляет протокол прикладного уровня выполнять функции сетевого. Приходится упаковывать IP-пакеты внутри TLS-потока, что добавляет накладные расходы на обработку, усложняет маршрутизацию внутри защищённого канала, создаёт дополнительную нагрузку на процессор. IPsec справляется с этим естественнее, потому что изначально спроектирован для работы на сетевом уровне.
Можно ли использовать IPsec вместо HTTPS? Технически да. Поднял IPsec-туннель между клиентом и сервером, весь трафик защищён, можно передавать данные по обычному HTTP. Но представь масштаб. Сколько клиентов подключается к популярному веб-сайту одновременно? Тысячи. Десятки тысяч. Каждому нужен отдельный IPsec-туннель с уникальными ключами и политиками. Сервер не выдержит такой нагрузки. IPsec не тянет на уровне отдельных пользовательских сессий.
Плюс с IPsec нет простого способа убедиться что сервер настоящий. В SSL/TLS есть сертификаты, выданные доверенными центрами. В IPsec есть механизмы аутентификации через PSK (pre-shared keys) или сертификаты, но централизованное управление ими в масштабе публичного интернета нереализуемо. Центры сертификации работают потому что их немного и им можно доверять централизованно. IPsec требует предварительной договорённости между сторонами, что нереально для публичных сервисов.
Поэтому для веб-сайтов используют SSL/TLS. Для корпоративных сетей используют IPsec. Иногда используют оба одновременно. Сотрудник подключается к корпоративной сети через IPsec VPN, а потом открывает внутренний веб-портал по HTTPS. Двойное шифрование? Да. Избыточность? Возможно. Но каждый слой защищает от своих угроз.
IPsec защищает от перехвата на уровне провайдера. Даже если кто-то контролирует маршрутизатор между домом сотрудника и офисом, он не увидит что именно передаётся. SSL/TLS защищает от внутренних угроз. Даже если кто-то в корпоративной сети снимает трафик, он не расшифрует HTTPS-сессию.
Параноя? Может быть. Но в критичных инфраструктурах многоуровневая защита - это не параноя, а базовый принцип defence in depth.
Что ещё нужно понимать
Они не защищают от всего. Они шифруют данные в пути, но не защищают конечные точки. Если на компьютере пользователя вредоносное ПО, оно увидит данные до шифрования. Если сервер скомпрометирован, шифрование канала бесполезно.
Они не защищают от атак на уровне приложения. SQL-инъекции - внедрение вредоносного кода в запросы к базе данных, XSS - межсайтовый скриптинг через внедрение JavaScript в страницы, CSRF - подделка межсайтовых запросов от имени пользователя. Всё это работает даже через HTTPS, потому что атака направлена не на канал передачи, а на логику приложения.
Они не скрывают факт передачи данных. Можно зашифровать содержимое, но сам факт что два узла обмениваются пакетами определённого размера в определённое время - открыт. Traffic analysis - анализ паттернов трафика - позволяет извлекать информацию даже из зашифрованных потоков. Когда человек смотрит видео, паттерн трафика один. Когда читает текст - другой. Когда загружает файл - третий.
SSL/TLS уязвим к компрометации инфраструктуры сертификации. Если злоумышленник получит контроль над центром сертификации, он может выдать себе сертификат для любого домена и перехватывать трафик через атаку типа man-in-the-middle - когда атакующий внедряется между клиентом и сервером, представляясь каждому из них легитимной стороной. Центры сертификации взламывали, доверие к некоторым из них отзывали. Система работает на доверии, а доверие хрупко.
IPsec уязвим к неправильной настройке. Слабые алгоритмы шифрования, короткие криптографические ключи, устаревшие версии протокола - всё это создаёт уязвимости. Администратор может развернуть IPsec и думать что всё защищено, а на деле использовать настройки десятилетней давности, которые современные атаки ломают за минуты.
Оба протокола живут в мире где постоянно находят новые уязвимости. Heartbleed в библиотеке OpenSSL показал что даже широко используемые компоненты могут содержать критические ошибки годами - эта уязвимость позволяла считывать память сервера и извлекать приватные ключи. BEAST (Browser Exploit Against SSL/TLS), POODLE (Padding Oracle On Downgraded Legacy Encryption), FREAK (Factoring RSA Export Keys) - атаки на разные версии SSL/TLS, которые заставляли обновлять протоколы, отказываться от устаревших алгоритмов, менять настройки серверов.
Безопасность - это не статичное состояние, а непрерывный процесс адаптации к эволюционирующим угрозам. Поставил защиту и забыл - не работает. Нужно следить за обновлениями, закрывать уязвимости, пересматривать конфигурации. То что было надёжно вчера, может оказаться дырой завтра.
А ещё важно понимать где защита нужна, а где избыточна. Шифровать всё подряд дорого по ресурсам и не всегда оправдано. Публичный блог с открытыми статьями не требует IPsec. Внутренний корпоративный портал с финансовыми данными - требует.
Разница между SSL/TLS и IPsec - разница между защитой содержимого письма и защитой всего почтового маршрута. Первое скрывает что написано в письме. Второе скрывает весь процесс доставки от отправителя до получателя. Иногда нужно первое. Иногда второе. Иногда оба. Выбор зависит от угроз которые ты пытаешься предотвратить.
#информационнаябезопасность #кибербезопасность #шифрование #защитаданных #безопасностьсети #криптография #технологии