Информационные сети как класс открытых информационных систем

Для правильного взаимодействия узлов информационной сети ее архитектура должна быть открытой.

Понятие открытая система – это система, построенная на основе открытых спецификаций. Для реальный систем полная открытость – это недостижимый идеал, как правило, только часть информационной системы поддерживающая внешние интерфейсы открыта.

 

Преимущества открытости для сетей:

- возможность построить сеть на базе аппаратных и программных средств различных производителей;

- возможность замены отдельных компонентов сети другими, более современными;

- возможность легкого сопряжения одной сети с другой;

- простота освоения и обслуживания.

 

Стандарт (спецификация) – формализованное описание программных и аппаратных компонентов, их функций, способов взаимодействия, условий эксплуатации и некоторых особых характеристик.

Открытая спецификация – легко доступна и была принята после всеобщего открытого утверждения.

Типы стандартов:

- стандарт отдельной фирмы

- стандарт отдельных объединений

- отраслевые стандарты

- национальные стандарты

- международные стандарты

Стандарты образуются:

· В мин.обороны США

· В IEEE (институт инженеров эл.-тех. и радиоэлектроники)

· В ANSI (американский нац.институт стандартов)

 

 

2. SSH является протоколом для удаленного безопасного входа и других сетевых сервисов безопасности в недостаточно надежно защищенной сети.

SSH состоит из трех компонентов.

1) Протокол транспортного уровня (SSH-TRANS) обеспечивает аутентификацию сервера, конфиденциальность и целостность соединения. Также может дополнительно обеспечивать сжатие данных. Протокол транспортного уровня обычно выполняется поверх соединения TCP, но может использоваться и поверх любого другого надежного соединения.

2) Протокол аутентификации пользователя (SSH-USERAUTH) аутентифицирует клиента для сервера. Он выполняется поверх протокола транспортного уровня.

3) Протокол соединения (SSH-CONN), мультиплексирует несколько логических каналов в один зашифрованный туннель. Протокол выполняется поверх протокола аутентификации пользователя.

Клиент посылает запрос на сервис всякий раз, когда устанавливается безопасное соединение на транспортном уровне. Второй запрос сервиса посылается после выполнения аутентификации пользователя.

Каждый сервер должен иметь ключ хоста. Серверы могут иметь несколько ключей хоста, используемых различными алгоритмами. Несколько серверов могут разделять один ключ хоста. Каждый сервер должен иметь, по крайней мере, один ключ для каждого обязательного алгоритма открытого ключа. В настоящее время требуется поддерживать алгоритм DSS.

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

Могут использоваться две различные модели:

1) Клиент имеет локальную базу данных, связывающую каждое имя сервера с соответствующим открытым ключом. Этот метод не требует централизованной административной инфраструктуры и трехсторонней координации. В то же время, такую базу данных тяжело поддерживать при большом количестве клиентов и серверов, с которыми они должны взаимодействовать.

2) Взаимосвязь имя сервера – ключ проверяется некоторым доверенным сертификационным органом – СА. Клиент знает только ключ корневого CA и может проверить достоверность всех ключей серверов, сертифицированных этими СА.

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

В протоколе существует опция, которая позволяет не проверять связывание имя сервера – открытый ключ при первом соединении клиента с сервером. Это обеспечивает возможность взаимодействия без предварительного знания ключа сервера. В этом случае соединение также обеспечивает защиту от пассивного прослушивания; тем не менее, оно уязвимо для активных атак типа встреча посередине. Реализации не должны допускать такие соединения по умолчанию, если они допускают возможность активных атак. Однако, так как инфраструктура открытого ключа еще недостаточно широко распространена, данная опция делает протокол более приемлемым для взаимодействия сторон, обеспечивая более высокий уровень безопасности, чем такие предыдущие решения как telnet или rlogin.

Реализации протокола должны пытаться обеспечивать проверку ключей сервера.

Реализации могут предоставлять дополнительные способы проверки корректности ключей сервера.

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

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

Возможности дальнейшего развития SSH

Разработчики надеются, что протокол будет развиваться, и некоторые организации захотят использовать собственные методы шифрования, аутентификации или обмена ключей. Централизованная регистрация всех расширений затруднена, особенно для обеспечения экспериментальных или классифицированных методов. С другой стороны, отсутствие централизованной регистрации приводит к конфликтам в методах идентификации, затрудняя интероперабельность.

Для идентификации алгоритмов, методов, форматов и протоколов расширения были выбраны текстовые имена определенного формата. Имена DNS используются для создания локального пространства имен, в котором могут быть определены экспериментальные или классифицированные расширения без риска конфликта с другими реализациями.

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