Еще больше усложняет ситуацию то, что аннулированный сертификат иногда требуется восстанавливать. Например, если причиной отзыва была неуплата каких-нибудь взносов, после внесения необходимой суммы не остается никаких причин, которые не позволяли бы восстановить сертификат. Обработка ситуаций аннулирования и восстановления сводит на нет такое ценное свойство сертификатов, как возможность их использования без помощи УС.
Где хранить списки аннулированных сертификатов? Было бы здорово хранить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что УС периодически выпускает черные списки и заставляет вносить обновления в каталоги (удаляя отозванные сертификаты). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных местах в сети. Поскольку черный список сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.
Если сертификаты имеют большие сроки годности, списки аннулированных сертификатов также будут довольно длинными. Например, количество отозванных кредитных карточек со сроком годности 5 лет будет гораздо больше списка отозванных трехмесячных карточек. Стандартным способом борьбы с длинными списками является достаточно редкий выпуск самих списков и частый — обновлений к ним. Кроме всего прочего, это помогает снизить необходимую для распространения списков пропускную способность.
8.6. Защита соединений
Мы закончили изучение прикладных инструментов. Было описано большинство применяемых методов и протоколов. Оставшаяся часть главы будет посвящена применению этих методов на практике для обеспечения безопасности сетей. Кроме того, будут высказаны некоторые мысли относительно социального аспекта этого вопроса.
Следующие четыре раздела посвящены безопасности соединений, то есть тому, как секретно и без риска подмены данных передавать биты от пункта отправления до пункта назначения, а также тому, как не пускать на линию посторонние биты. Это ни в коем случае не полный список проблем сетевой безопасности, однако перечисленные вопросы являются одними из самых важных.
8.6.1. IPsec
Проблемная группа IETF в течение многих лет мирилась с отсутствием безопасности в Интернете. Обеспечить ее было действительно непросто и прежде всего потому, что разгорелись жаркие споры вокруг того, какую часть Интернета следует, собственно, защищать. Большинство экспертов по вопросам безопасности уверены в том, что по-настоящему надежная система должна выполнять сквозную шифрацию и сквозное обеспечение целостности данных (то есть все это должно быть сделано на прикладном уровне). Это означает, что процесс-источник шифрует и/или ставит защиту целостности данных и отправляет их процессу-приемнику, который, соответственно, дешифрует данные и проверяет их целостность. Тогда можно будет заметить любые попытки взлома (даже на уровне операционной системы на любой из сторон). Беда такого подхода в том, что для обеспечения безопасности требуется вносить изменения во все приложения. Это означает, что необходимо «спустить» шифрацию на транспортный уровень или организовать новый специализированный подуровень между прикладным и транспортным. Он должен быть сквозным, но в то же время не требующим внесения изменений в приложения.
Противоположная точка зрения состоит в том, что пользователи все равно не осознают необходимости применения мер безопасности и просто не способны корректно использовать все предоставленные возможности. При этом никто не захочет каким-либо образом изменять существующие программы, поэтому сетевой уровень должен выполнять проверку подлинности и/или шифровать сообщения незаметно для пользователя. Долгие годы сражений привели к победе этой точки зрения: был разработан стандарт безопасности, ориентированный на сетевой уровень. Одним из аргументов было то, что шифрация на сетевом уровне, с одной стороны, не помешает тем пользователям, которые серьезно относятся к безопасности, а с другой — в некоторой степени убережет беспечных пользователей.
Результатом всех этих дискуссий было создание стандарта IPsec (IP security — IP-безопасность), описанного в RFC 2401, 2402, 2406 и др. Не всем пользователям требуется шифрование соединений (выполнение соответствующих процедур может занимать существенную часть вычислительных ресурсов). Однако, вместо того чтобы делать шифрование необязятельным, пользователю предлагается в случае необходимости выбирать пустой алгоритм. В RFC 2410 расписываются такие достоинства пустого алгоритма, как простота, легкость реализации и высокая скорость.
IPsec служит основой для множества услуг, алгоритмов и модулей. Причиной наличия множества услуг является то, что далеко не все хотят постоянно платить за все возможные услуги, поэтому нужные сервисы предоставляются порционно. Основные услуги таковы: секретность, целостность данных, защита от взлома методом повторения сообщений (когда жулик повторяет подслушанный разговор). Все это основано на криптографии с симметричными ключами, поскольку здесь критична высокая производительность.
Для чего нужен целый набор алгоритмов? Дело в том, что считающийся сегодня надежным алгоритм завтра может быть сломан. Если сделать IPsec независимым от конкретного алгоритма, стандарт выживет даже в случае взлома одного из алгоритмов.
Для чего нужны разные модули? Для того чтобы можно было защищать и одно TCP-соединение, и весь трафик между парой хостов, и весь трафик между парой защищенных маршрутизаторов и т. д.
Несколько удивительно, что IPsec ориентирован на соединение, несмотря на его присутствие на уровне IP. На самом деле, это не так странно, как кажется. Ведь безопасность можно обеспечить только созданием ключа и использованием его в течение какого-то времени. А это, по сути дела, разновидность соединения. К тому же все соединения погашают расходы на их установление за счет передачи большого количества пакетов. «Соединение» в контексте IPsec называется защищающей связью (Security Aconnection — SA). Защищающая связь — это симплексное соединение между двумя конечными точками, с которым связан специальный идентификатор защиты. Если требуется передача защищенных данных в обоих направлениях, понадобятся две защищающие связи. Идентификаторы защиты передаются в пакетах, следующих по этим надежным соединениям, и используются по прибытии защищенных пакетов для поиска ключей и другой важной информации.
Технически IPsec состоит из двух основных частей. Первая описывает два новых заголовка, которые можно добавлять к пакету для передачи идентификатора защиты, данных контроля целостности и другой информации. Вторая часть, ISAKMP (Internet Security and Key Management Protocol — интернет-безопасность и протокол управления ключами), предназначена для создания ключей. ISAKMP является средой. Основным протоколом для выполнения работы является IKE (Internet Key Exchange — обмен ключами в Интернете). Должна использоваться версия 2 IKE, так как более ранняя версия имела серьезные недостатки, как указали Perlman и Kaufmn, (2000).
IPsec может работать в двух режимах. В транспортном режиме заголовок IPsec вставляется сразу за заголовком IP. Поле Protocol заголовка IP изменяется таким образом, чтобы было понятно, что далее следует заголовок IPsec (перед заголовком TCP). В заголовке IPsec содержится информация, касающаяся безопасности, — в частности, идентификатор защищающей связи, новый порядковый номер и, возможно, проверка целостности поля полезной нагрузки.
В режиме туннелирования весь IP-пакет вместе с заголовком вставляется внутрь нового IP-пакета с совершенно новым заголовком. Этот режим хорош тогда, когда туннель заканчивается где-нибудь вне конечного пункта. В некоторых случаях концом туннеля является шлюз, обеспечивающий безопасность, например, корпоративный межсетевой экран. Он обычно используется для VPN (Virtual Private Network — виртуальная частная сеть). В этом режиме межсетевой экран вставляет и извлекает пакеты, проходящие через него в разные стороны. При такой организации машины ЛВС компании гарантированно будут обслужены по стандарту IPsec. Об этом совершенно не приходится беспокоиться: все заботы берет на себя межсетевой экран.
