Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ГОС_2.docx
Скачиваний:
82
Добавлен:
05.06.2015
Размер:
932.79 Кб
Скачать
  1. Защита классов связи в сети Интернет.

Способы и средства обеспечения ИБ должны встраиваться только в те Internet-протоколы, функционирование которых должно быть защищенным. Многие проблемы ИБ могут возникнуть в результате некорректной реализации способов обеспечения ИБ (ошибки при встраивании). Однако даже когда способ обеспечения ИБ функционирует (реализован) корректно, все равно будут иметь место проблемы ИБ, так как фундаментальный протокол сам по себе требует корректной реализации на практике. Точно также и способ обеспечения ИБ, который необходимо реализовать в защищаемом протоколе, может быть различным, так как защищаемый протокол имеет свою собственную внутреннюю структуру. Тем не менее, существует множество протоколов, для которых уже существуют стандартизованные в Internet способы обеспечения ИБ, вполне приемлемые для реализации. Конкретный выбор способа может быть различным, так как все зависит от определенной ситуации.

Обеспечение ИБ искусство. Варианты компрометации ИБ в Internet могут быть разделены на несколько классов (групп), во всем диапазоне от отказа в обслуживании до компрометации IP-узла. Атаки типа отказ в обслуживании основаны на том, что транслируемый трафик является открытым. Необходимо заметить, что многие такие атаки весьма трудно реализуемы, так как в настоящее время накоплен достаточно большой опыт по защите от них. Компрометация IP-узла (наиболее общим случаем является не обнаруживаемая перегрузка буферных устройств памяти) скорее всего, есть следствие недостатков при определенной реализации способов обеспечения ИБ в программном модуле IP-узла, нежели следствием недостатков в самих протоколах, реализованных в IP-узле. Тем не менее, тщательно проработанные протоколы могут иметь гораздо меньше таких недостатков брешей, чем их может быть, и могут быть менее трудоемки при эксплуатации.

Однако существуют варианты компрометации ИБ, которые усугубляются самими же протоколами, используемыми в Internet-сети. Если проблема обеспечения ИБ свойственна протоколу, то тогда не существует метода по реализации того или иного способа обеспечения ИБ, который бы мог исключить данную проблему.

И поэтому жизненно важно, чтобы все протоколы, создаваемые для Internet-сети, обладали функциональными свойствами, обеспечивающими ИБ. Точно также как и способ обеспечения ИБ, который должен быть внедрен в протокол, защищает последний, так и сам защищаемый протокол должен обеспечивать свою функциональную защищенность на основе своей внутренней структуры. Во многих случаях корректное применение стандартизованных IETF способов обеспечения ИБ вполне может обеспечить необходимый уровень защищенности протокола.

Для обеспечения ИБ в Internet-сети могут использоваться все возможные способы. А вот какой способ необходимо использовать, будет зависеть от многих различных факторов.

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

Таким образом, способы обеспечения ИБ не являются каким-то “волшебством”, с помощью которого можно полностью защитить протоколы. Маловероятно, чтобы способ обеспечения ИБ встраивался надолго. Хорошие (т.е., безопасные, прозрачные и эффективные) проекты получаются тогда, когда способы обеспечения ИБ разрабатываются вместе с протоколом. Криптография не сможет защитить протокол с явными семантическими изъянами.

ОСНОВНОЙ ТЕКСТ, Способы обеспечения ИБ могут встраиваться на любом уровне Internet-архитектуры. В целом, если встраивать способ на более низком уровне архитектуры, то тогда он способен защитить широкий спектр высокоуровневых протоколов, но с другой стороны, эта защита может быть недостаточно надежной. Шифратор канального уровня (“link layer”) способен защитить не только IP-пакеты, но и ARP-пакеты. Однако он защищает только один канал связи. И наоборот, подписанное с помощью ЭЦП почтовое сообщение, которое может транслироваться через несколько почтовых серверов-ретрансляторов (в режиме “хранение-передача”), способно идентифицировать реального отправителя, а сама ЭЦП может быть проверена гораздо позже после доставки сообщения. Тем не менее, в данном случае защищается только один тип сообщений. Сообщения простых форматов, например, сетевые новости, не защищаются, пока один из способов безопасности не будет адаптирован для таких сообщений и не встроен в программы их рассылки.

Системы с одноразовыми паролями. Такие системы (RFC-2289) являются гораздо более надежными, по сравнению с обычными парольными системами. В таких системах IP-узел не должен хранить копию пароля пользователя и, тем более, передавать ее через сеть. Однако существуют определенные риски. Так как передавае. мая последовательность (одноразовый пароль) формируется из пароля пользователя, то можно предположить, что атаки по-прежнему вполне реальны и осуществимы.

IPsec-архитектура. Протоколы аутентификации и шифрования на IP-уровне (сетевом уровне), составляющие основу IPsec-архитектуры, представлены в стандартах RFC-4301, RFC-4302, RFC-4303, RFC-4306 и RFC-4307. По сути, данная архитектура безопасности защищает протоколы верхних уровней, включая ТСР- и UDP-протоколы. Она обеспечивает нормальное (однородное) распределение защиты, т.е. “IP-узел-IP-узел”, “IP-узел-шлюз безопасности” и “шлюз безопасности-шлюз безопасности”. Функциональные свойства IPsec-архитектуры позволяет пользователю самому распределять защиту, но это бывает сравнительно редко. По существу, применение IPsec-архитектуры теряет всякий смысл, если распределение защиты на самом IP-узле слишком неоднородно.

Сетевые экраны и топология. Сетевые экраны (“firewall”) представляют собой топологические (заградительные) способы обеспечения ИБ, т.е. они зависят от четко определенной границы между “хорошим” сетевым сегментом (внутренняя часть корпоративной сети) и “плохой” внешней сетью, с которой соединен сегмент, а сам сетевой экран (СЭ) служит связующим звеном между ними, через которое транслируется информация. Несмотря на то, что СЭ могут быть весьма полезны, если, конечно же, они используются надлежащим образом, существуют определенные границы их возможностей по защите сетей.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]