Защита каналов связи

Защита информации в каналах связи - важнейший вопрос организации безопасности на предприятии. На сегодняшний день используют много способов успешно защитить информацию, передаваемую по каналам связи внутри корпорации или во внешний мир.

Защита каналов связи и ее основные методы

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

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

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

В первом случае шифрование данных осуществляется непосредственно на аппаратуре, которая является отправителем информации, а расшифровка - на приемнике. Данный вариант наиболее эффективно защитит передаваемые данные, однако для его реализации необходимо постороннее программное обеспечение, которое работало бы на прикладном уровне.

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

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

Устройства защиты каналов связи

К таким устройствам относятся:

• всевозможные глушители,
• подавители связи,
• антижучки,
• детекторы,

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

14.09.2006 Марк Джозеф Эдвардс

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

Какой метод оптимален для ваших условий?

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

В пути и по прибытии

Если ваши намерения ограничиваются защитой файлов в процессе их передачи по каналам Internet, вам необходима технология безопасной транспортировки. Один из вариантов состоит в использовании Web-узла, способного принимать пересылаемые на него файлы и обеспечивающего возможность безопасной загрузки таких файлов. Для организации защищенной транспортировки файлов на Web-узел можно создать Web-страницу, оснащенную средствами Secure Sockets Layer (SSL), на которой размещается элемент управления ActiveX или сценарий Javascript. К примеру, можно воспользоваться элементом управления AspUpload от компании Persitis Software; разработчики утверждают, что это «самое современное из имеющихся на рынке средств управления транспортировкой файлов на центральные узлы». Еще один вариант - использовать сценарий Free ASP Upload, который не требует применения бинарного компонента. Для обеспечения дополнительной защиты можно даже защитить паролями как Web-страницу, так и ассоциированный с ней каталог для размещения поступивших на узел материалов. Что же касается загрузки файлов с Web-узла, то достаточно позаботиться о том, чтобы соответствующий Web-сервер обеспечивал соединение с применением средств SSL, по крайней мере для URL, который используется для загрузки файлов.

Альтернативный вариант - использование сервера FTP, обеспечивающего передачу данных по протоколу FTP Secure. В сущности, FTPS - это протокол FTP, выполняемый по защищенному соединению SSL. Возможность использования протокола FTPS предусмотрена во многих популярных клиентах FTP, но, к сожалению, она не реализована в службе FTP Service корпорации Microsoft. Поэтому вам придется задействовать обеспечивающее такую возможность приложение сервера FTP (например, популярный продукт WFTPD). Не путайте FTPS с протоколом SSH File Transfer Protocol. SFTP - это протокол для передачи файлов, выполняемый поверх оболочки Secure Shell (SSH); кроме того, его можно использовать для передачи файлов. Впрочем, нужно иметь в виду, что SFTP несовместим с традиционным протоколом FTP, так что наряду с защищенным сервером оболочки (скажем, с сервером, предоставляемым SSH Communications Security), понадобится специальный клиент SFTP (это может быть клиент, входящий в пакет PuTTY Telnet/Secure Shell или WinSCP с графическим интерфейсом).

Кроме того, безопасную передачу файлов можно организовать на базе виртуальных частных сетей VPN. Платформы Windows Server обеспечивают совместимость с технологией VPN посредством RRAS. Однако это не гарантирует совместимости с VPN-решениями ваших партнеров. Если такой совместимости нет, можно воспользоваться одним из широко распространенных решений, например средством Open-VPN с открытым исходным кодом. Оно распространяется бесплатно и выполняется на целом ряде платформ, включая Windows, Linux, BSD и Macintosh OS X. Дополнительные сведения об интеграции OpenVPN можно найти в статье «Работаем с OpenVPN» ( ).

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

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

Если же вам тем не менее требуются дополнительные средства защиты данных в процессе их передачи по каналам электронной почты, рассмотрите возможность использования протоколов SMTP Secure (SMTPS) и POP3 Secure (POP3S). В сущности, SMTPS и POP3S - это обычные протоколы SMTP и POP3, выполняемые с использованием защищенного соединения SSL. Microsoft Exchange Server, как и большинство почтовых клиентов, включая Microsoft Outlook, обеспечивает возможность использования протоколов SMTPS и POP3S. Нужно иметь в виду, что даже в тех случаях, когда для обмена файлами между почтовым клиентом и почтовым сервером используется протокол SMTPS, сохраняется возможность того, что почтовый сервер будет доставлять почту конечному адресату через обычное незащищенное соединение SMTP.

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

Средства сжатия файлов

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

Один из наиболее популярных методов создания архивов сжатых файлов - метод zip-компрессии; его поддерживают практически все архиваторы. И одно из самых распространенных на сегодня средств zip-компрессии - приложение WinZip. Его можно использовать как автономную программу, встроить в Windows Explorer для облегчения доступа, а также с помощью модуля WinZip Companion for Outlook интегрировать этот продукт с клиентом Outlook. WinZip, как и многие другие оснащенные средствами zip архиваторы, обеспечивает возможность шифрования по методу Zip 2.0 Encryption. Но надо сказать, что защита файлов с помощью этого метода недостаточно надежна. Более приемлемый вариант шифрования реализован в продукте WinZip 9.0. Как показано на экране 1, ныне WinZip поддерживает спецификацию Advanced Encryption Standard (AES), где используются 128-разрядные или 256-разрядные ключи шифрования. AES - относительно новая технология, но ее уже считают промышленным стандартом.

Экран 1. WinZip поддерживает спецификацию AES

Я не могу сказать точно, какое количество архиваторов обеспечивает применение стойких алгоритмов шифрования средствами AES, и ограничусь упоминанием одного такого приложения; это разработанное компанией BAxBEx Software изделие bxAutoZip. Оно способно взаимодействовать с программой шифрования CryptoMite фирмы BAxBEx и может встраиваться в Outlook. Если WinZip позволяет шифровать данные только средствами Zip 2.0 и AES, CryptoMite обеспечивает возможность использования ряда других средств шифрования, включая популярные алгоритмы Twofish и Blowfish, Cast 256, Gost, Mars и SCOP.

Средствами распаковки zip-файлов оснащены уже практически все компьютерные системы, однако не все zip-приложения обеспечивают совместимость с различными алгоритмами шифрования. Поэтому, перед тем как отправлять зашифрованные файлы, надо убедиться в том, что zip-приложение получателя «понимает» избранный алгоритм.

При шифровании файлов с помощью zip-приложений используются защитные пароли. Для дешифрации архивного файла его получатель тоже должен воспользоваться соответствующим паролем. Необходимо проявлять осторожность при выборе метода доставки пароля. Вероятно, самые безопасные методы доставки пароля - по телефону, по факсу или через курьера. Можно выбрать любой из них, но ни в коем случае не следует передавать пароль по электронной почте в виде обычного текста; в этом случае резко возрастает опасность того, что доступ к зашифрованному файлу получит не имеющий на то полномочий пользователь.

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

Pretty Good Privacy

Еще один чрезвычайно популярный метод шифрования можно реализовать с помощью программы Pretty Good Privacy. PGP произвела настоящий фурор, когда Фил Циммерман впервые бесплатно опубликовал ее в Internet в 1991 г. В 1996 г. PGP стала коммерческим продуктом, а затем в 1997 г. права на нее были куплены фирмой Network Associates (NAI). В 2002 г. эту технологию приобрела у NAI молодая компания PGP Corporation.

После этого PGP Corporation продала коммерческую версию PGP, которая функционирует в средах Windows и Mac OS X. Текущая версия PGP 9.0, в которой реализованы средства шифрования отдельных файлов и шифрования всего содержимого диска, может быть встроена в AOL Instant Messenger (AIM). Кроме того, PGP 9.0 интегрируется с такими изделиями, как Outlook, Microsoft Entourage, Lotus Notes, Qualcomm Eudora, Mozilla Thunderbird и Apple Mail.

В PGP применяется система шифрования с открытым ключом, предусматривающая генерирование пары ключей шифрования - открытого ключа и секретного ключа. Эти два ключа математически взаимосвязаны таким образом, что зашифрованные с помощью открытого ключа данные могут быть дешифрованы только с помощью секретного ключа. Пользователь PGP генерирует пару «открытый ключ - секретный ключ», после чего публикует открытый ключ в общедоступном каталоге ключей или на Web-узле. Секретный ключ, разумеется, нигде не публикуется и хранится в секрете; им пользуется только его владелец. При расшифровке данных с помощью секретного ключа требуется пароль, но при шифровании данных с помощью открытого ключа это не предусмотрено, поскольку открытыми ключами могут пользоваться все желающие.

Для простоты применения системы PGP ее разработчики реализовали функцию автоматического опроса общедоступных каталогов ключей. Эта функция позволяет, введя в строку поиска почтовый адрес того или иного пользователя, находить его открытый ключ. PGP предоставляет возможность автоматического считывания открытых ключей, которые можно для простоты доступа хранить локально на своей системе в специальной «связке ключей» (keyring) на базе файлов. Опрашивая каталог открытых ключей, PGP позволяет всегда держать в «связке» их самые последние версии. Если пользователь изменяет свой открытый ключ, вы можете получить доступ к обновленному ключу в любой момент, когда он вам потребуется.

Для обеспечения более надежных гарантий аутентичности открытых ключей можно использовать цифровые подписи с помощью ключей других пользователей. Подпись ключа другим пользователем служит дополнительным подтверждением того, что ключ действительно принадлежит человеку, называющему себя его владельцем. Чтобы подтвердить достоверность ключа с помощью цифровой подписи, PGP выполняет некую математическую операцию и добавляет к ключу ее уникальный результат. Затем подпись можно проверить, сравнив ее с подписывающим ключом, который применялся для создания подписи. Этот процесс напоминает процесс подтверждения одним человеком идентичности другого.

Системе PGP доверяют многие, поскольку она давно уже завоевала в отрасли репутацию надежной технологии для защиты информации. Но как бы то ни было, если вы решили использовать PGP или другой метод шифрования данных с помощью открытых ключей, помните, что получатели ваших файлов тоже должны располагать совместимой системой шифрования. Одно из преимуществ системы PGP при использовании электронной почты в качестве канала передачи данных состоит в том, что она поддерживает собственную модель шифрования, а также технологии X.509 и S/MIME, о которых я расскажу далее.

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

PKI

Инфраструктура открытых ключей (Public Key Infrastructure, PKI) уникальна, однако принцип ее действия в чем-то напоминает принцип действия PGP. PKI предполагает использование пары ключей - открытого и секретного. Для зашифровки данных, направляемых получателю, отправители применяют его открытый ключ; после того как данные доставляются получателю, он расшифровывает их с помощью своего секретного ключа.

Экран 2. Просмотр содержимого сертификата

Одно существенное отличие состоит в том, что в PKI открытый ключ обычно хранится в формате данных, известном как сертификат. Сертификаты могут содержать намного больше информации, нежели обычные ключи. К примеру, сертификаты обычно содержат дату истечения срока действия, так что мы знаем, когда сертификат и ассоциированный с ним ключ уже не будут действительны. Кроме того, сертификат может включать имя, адрес, номер телефона владельца ключа и другие данные. На экране 2 представлено содержимое сертификата в том виде, в каком оно отображается в окне программы Microsoft Internet Explorer (IE) или Outlook. В определенной степени содержимое сертификата зависит от того, какие именно данные желает разместить в нем владелец.

Как и PGP, PKI позволяет формировать «цепочки доверия», в которых сертификаты могут быть подписаны с помощью сертификатов других пользователей. Более того, появились удостоверяющие центры Certificate Authorities (CA). Это облеченные доверием независимые организации, которые не только выдают собственные сертификаты, но и подписывают другие сертификаты, гарантируя тем самым их подлинность. Как и в случае с PGP и связанными с этой системой серверами ключей, сертификаты могут публиковаться на общедоступных или частных серверах сертификатов либо на серверах LDAP, пересылаться по электронной почте и даже размещаться на Web-узлах или на файловом сервере.

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

В основе PKI лежит спецификация X.509 (являющаяся производной от спецификации LDAP X). Поэтому сертификаты, выданные одним центром (включая сертификаты, которые вы генерируете для себя), обычно можно использовать на целом ряде платформ. Нужно только, чтобы эти платформы были совместимы со стандартом X.509. Вы можете и сами генерировать сертификаты с помощью любого из имеющихся инструментальных средств, таких как OpenSSL.

Если ваша организация использует службу Microsoft Certificate Services, вы можете запросить сертификат через эту службу. В средах Windows Server 2003 и Windows 2000 Server данный процесс должен протекать примерно одинаково. Следует открыть Web-страницу сервера сертификатов (как правило, она располагается по адресу http://servername/CertSrv ), затем выбрать пункт Request a Certificate. На следующей странице нужно выбрать элемент User certificate request и следовать указаниям Web-мастера до завершения процесса. Если служба сертификатов настроена таким образом, что для выдачи сертификата требуется санкция администратора, система известит вас об этом специальным сообщением, и вам придется дожидаться решения администратора. В иных случаях вы в итоге увидите гиперссылку, которая позволит установить сертификат.

Некоторые независимые центры сертификации, такие как Thwate и InstantSSL компании Comodo Group, предлагают пользователям бесплатные персональные почтовые сертификаты; это простой способ получения сертификатов. Кроме того, такие сертификаты уже будут подписаны выдавшей их инстанцией, что облегчит проверку их подлинности.

Когда дело доходит до использования PKI с целью отправки зашифрованных данных с помощью программы обработки электронной почты, в дело вступает спецификация Secure MIME (S/MIME). Outlook, Mozilla Thunderbird и Apple Mail - вот лишь несколько примеров почтовых приложений, позволяющих задействовать этот протокол. Чтобы отправить адресату зашифрованное почтовое сообщение (включающее или не включающее присоединенные файлы), необходимо иметь доступ к открытому ключу адресата.

Для получения открытого ключа другого пользователя можно просмотреть данные о ключах на сервере LDAP (если только ключ публикуется с использованием протокола LDAP). Другой вариант: можно попросить этого человека направить вам сообщение с цифровой подписью; как правило, при доставке адресату подписанного сообщения оснащенные средствами S/MIME почтовые клиенты присоединяют копию открытого ключа. А можно просто попросить интересующее вас лицо прислать вам сообщение с присоединенным к нему открытым ключом. Впоследствии можно будет хранить этот открытый ключ в интерфейсе управления ключами, который входит в состав вашего почтового клиента. Программа Outlook интегрируется со встроенным в Windows хранилищем сертификатов Certificate Store. При необходимости воспользоваться открытым ключом он всегда будет под рукой.

Шифрование на основе данных об отправителе

Фирма Voltage Security разработала новую технологию - шифрование на основе данных об отправителе (identity-based encryption, IBE). В целом она аналогична технологии PKI, но имеет любопытную особенность. Для дешифации сообщений в IBE используется секретный ключ, но в процессе шифрования обычный открытый ключ не применяется. В качестве такого ключа IBE предусматривает использование почтового адреса отправителя. Таким образом, при отправке получателю зашифрованного сообщения проблемы получения его открытого ключа не возникает. Достаточно иметь адрес электронной почты этого человека.

Технология IBE предполагает хранение секретного ключа получателя на сервере ключей. Получатель подтверждает свои права доступа к серверу ключей и получает секретный ключ, с помощью которого осуществляет дешифрацию содержимого сообщения. Технологию IBE могут применять пользователи Outlook, Outlook Express, Lotus Notes, Pocket PC, а также Research in Motion (RIM) BlackBerry. По словам представителей Voltage Security, IBE выполняется также на любых почтовых системах на базе браузеров под управлением практически любой операционной системы. Вполне вероятно, что такие универсальные решения Voltage Security - именно то, что вам нужно.

Примечательно, что технология IBE применяется в продуктах компании FrontBridge Technologies как средство, облегчающее безопасный обмен зашифрованными почтовыми сообщениями. Вам, наверное, уже известно, что в июле 2005 г. компания FrontBridge была приобретена корпорацией Microsoft, которая планирует интегрировать решения FrontBridge с Exchange; возможно, уже довольно скоро комбинация этих технологий будет предложена потребителям в виде управляемой службы. Если системы обработки электронной почты в вашей организации и у ваших партнеров базируются на Exchange, следите за развитием событий на этом участке.

С учетом всех обстоятельств

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

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

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

Марк Джозеф Эдвардс - старший редактор Windows IT Pro и автор еженедельного почтового бюллетеня Security UPDATE (http://www.windowsitpro.com/email ). [email protected]

Создание защищенного канала передачи данных между распределенными информационными ресурсами предприятия

А. А. Теренин, к. т. н.,

специалист по обеспечению качества ИТ и ПО

«Дойче Банк Москва»

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

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

К данным, которыми обмениваются филиалы, выдвигаются строгие требования по их достоверности и целостности. В дополнение к этому, данные, представляющие коммерческую тайну, должны носить конфиденциальный характер. Для полноценной параллельной работы всех офисов обмен информацией должен происходить в режиме он-лайн (в режиме реального времени). Другими словами, между филиалами предприятия и головным офисом должен быть установлен постоянный канал передачи данных. Для обеспечения бесперебойной работы такого канала выдвигается требование по сохранению доступности к каждому источнику информации.

Резюмируем требования, которым должны соответствовать каналы передачи данных между филиалами предприятия для высококачественного выполнения задачи обеспечения постоянной связи:

канал передачи данных должен быть постоянным,

данные, передаваемые по такому каналу, должны сохранять целостность, достоверность и конфиденциальность.

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

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

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

Под требованием достоверности подразумевается обеспечение авторизованного доступа, аутентификации сторон взаимодействия и обеспечение недопустимости отказа от авторства и факта передачи данных.

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

Как обеспечить подобную защиту канала передачи данных?

Можно соединить физическим каналом передачи данных каждый филиал с каждым (или только все филиалы с центром) и обеспечить невозможность доступа к физической среде передачи информационных сигналов. Да, такое решение может оказаться приемлемым для реализации в пределах одного охраняемого объекта, но речь идет о распределенных корпоративных системах, где расстояние между объектами взаимодействия может измеряться тысячами километров. Стоимость реализации подобного плана настолько высока, что никогда не будет экономически эффективной.

Другой вариант: арендовать имеющиеся, уже проложенные каналы связи или спутниковые каналы у операторов связи. Подобное решение также входит в разряд дорогостоящих, к тому же защита данных каналов потребует реализации или установки специального программного обеспечения (ПО) у каждой из взаимодействующих сторон.

Весьма распространенным, недорогим и эффективным решением является организация защищенных каналов связи поверх всемирной вычислительной сети Интернет.

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

Рассмотрим подробно, как можно создавать защищенные каналы передачи данных через Интернет.

Проблемы защищенной передачи данных по открытым сетям широко обсуждаются в популярной и массовой литературе:

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

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

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

Для защиты информации, передаваемой по общедоступным каналам связи, применяется множество средств защиты: данные шифруются, пакеты снабжаются дополнительной управляющей информацией, используется протокол обмена данными с повышенной степенью защищенности .

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

Из дополнительных требований к реализуемому защитному каналу передачи данных можно выделить:

идентификацию и аутентификацию взаимодействующих сторон;

процедуру защиты от подмены одной из сторон (использование криптоалгоритмов с открытым ключом);

контроль за целостностью передаваемых данных, маршрутом передачи информации и уровнем защиты канала связи;

конфигурирование и проверку качества канала связи;

компрессию передаваемой информации;

обнаружение и коррекцию ошибок при передаче данных по каналам связи;

аудит и регистрацию событий;

автоматическое восстановление работоспособности.

Построим модель нарушителя и модель объекта защиты (рис. 1).

Алгоритм установления соединения

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

Рассматриваются две стороны: сервер и клиент – рабочая станция, которая хочет установить соединение с сервером для дальнейшей работы с ним.

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

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

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

Необходимо предусмотреть возможность подсоединения злоумышленника в любой момент времени и повторять процедуру «рукопожатия» (handshake) через определенные временные интервалы, продолжительность которых необходимо установить минимальной от допустимой.

Исходя из предположения, что ЗКС и ОКС уже созданы, причем ОКС известен всем, а ЗКС – только серверу, мы получаем следующий алгоритм:

1. Клиент посылает серверу запрос на соединение.

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

3. Клиент генерирует свои ключи (открытый и закрытый) для работы с сервером (ОКК и ЗКК ).

4. Клиент генерирует ключ сессии (КС ) (симметричный ключ шифрования сообщений).

5. Клиент передает серверу следующие компоненты:

открытый ключ клиента (ОКК );

ключ сессии;

случайное сообщение (назовем его Х ), зашифрованное открытым ключом сервера по алгоритму RSA .

6. Сервер обрабатывает полученное сообщение и посылает в ответ сообщение Х , зашифрованное ключом сессии (симметричное шифрование) + зашифрованное открытым ключом клиента (асимметричное шифрование, например алгоритм RSA ) + подписанное закрытым ключом сервера (RSA, DSA, ГОСТ ) (то есть если мы на стороне клиента после дешифрования получим опять Х, то это значит, что:

сообщение пришло от сервера (подпись – ЗКС );

сервер принял наш ОКК (и зашифровал нашим ключом);

сервер принял КС (зашифровал этим ключом сообщение).

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

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

Схема алгоритма установления соединения приведена на рис. 2.

Алгоритм подготовки сообщения к отправке в защищенный канал

Постановка задачи звучит следующим образом: на вход алгоритма поступает исходный (открытый) текст, на выходе путем криптографических преобразований мы получаем закрытый и подписанный файл. Главная задача, поставленная перед этим алгоритмом, состоит в обеспечении безопасной передачи текста, обеспечении защиты в незащищенном канале.

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

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

Существует также вероятность того, что на другом конце канала (на приемной стороне) оказался злоумышленник, подменивший собой легального представителя. Благодаря этому алгоритму сообщение, которое беспрепятственно попадет в руки такого злоумышленника, тоже окажется «нечитабельным», поскольку подменившему неизвестны открытый и закрытый ключи подмененной им стороны, а также ключ сессии.

Алгоритм может быть реализован следующим образом (рис. 3):

исходный текст сжимается с помощью алгоритма ZIP;

параллельно этому процессу происходит подпись исходного текста открытым ключом получателя;

сжатый текст шифруется симметричным ключом сессии, этот ключ тоже есть на приемной стороне;

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

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

Алгоритм обработки сообщения при приеме из защищенного канала

На вход алгоритма поступает зашифрованный, сжатый и подписанный текст, который мы принимаем по каналу связи. Задача алгоритма состоит в получении с использованием обратных криптографических преобразований исходного открытого текста, проверки подлинности сообщения и его авторства.

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

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

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

Алгоритм обработки сообщения при приеме из защищенного канала (рис. 4):

из полученного зашифрованного, сжатого и подписанного сообщения выделяется цифровая подпись;

текст без цифровой подписи дешифруется ключом сессии;

декодированный текст проходит процедуру разархивирования с использованием, например, алгоритма ZIP;

полученный в результате двух предыдущих операций текст используется для проверки цифровой подписи сообщения;

на выходе алгоритма мы имеем исходное открытое сообщение и результат проверки подписи.

Алгоритм подписи сообщения

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

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

Для нахождения значения хэшфункции можно применять известные алгоритмы хэширования (SHA, MD4, MD5, ГОСТ и др.), которые позволяют получить на выходе блок данных фиксированной длины. Именно с этим блоком и будет работать алгоритм цифровой подписи. В качестве алгоритма электронной цифровой подписи можно использовать алгоритмы DSA, RSA, Эль-Гамаля и др.

Опишем алгоритм подписи сообщения по пунктам (рис. 5):

на вход общего алгоритма поступает исходный текст любой длины;

вычисляется значение хэш-функции для данного текста;

ЭЦП ;

используя поступившие данные, вычисляется значение ЭЦП всего текста;

на выходе алгоритма мы имеем цифровую подпись сообщения, которая поступает дальше для присоединения к отправляемому в канал обмена данными пакету информации.

Алгоритм проверки подписи

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

На выходе алгоритма мы имеем результат проверки цифровой подписи, который может иметь только два значения: «подпись соответствует оригиналу, текст подлинный» либо «подпись текста некорректна, целостность, подлинность или авторство сообщения вызывает подозрение». Значение на выходе данного алгоритма можно затем использовать дальше в системе поддержки защищенного канала.

Опишем алгоритм проверки подписи сообщения по пунктам (рис. 6):

на вход общего алгоритма поступает исходный текст любой длины и цифровая подпись этого текста фиксированной длины;

вычисляется значение хэш-функции от данного текста;

полученное отображение текста фиксированной длины поступает в следующий блок алгоритмической обработки;

в этот же блок направляется цифровая подпись, которая пришла на вход общего алгоритма;

также на вход этого блока (вычисление цифровой подписи) поступает секретный (закрытый) ключ, который используется для нахождения ЭЦП ;

с использованием поступивших данных вычисляется значение электронной цифровой подписи всего текста;

мы получили цифровую подпись сообщения, сравнивая которую с ЭЦП , поступившей на вход общего алгоритма, мы можем делать выводы о достоверности текста;

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

Возможные атаки на предложенную схему реализации защищенного канала связи

Рассмотрим наиболее распространенные примеры возможных атак на защищенный канал передачи данных .

Во-первых, необходимо решить чему и кому можно доверять, потому что если не доверять никому и ничему, то нет смысла писать подобные программы поддержки обмена данными по глобальной сети.

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

При использовании для установления связи с сервером браузера (Internet Explorer или Netscape Navigator) мы доверяем этому браузеру и доверяем его проверке сертификатов посещаемых сайтов.

После проверки подписи на апплете можно доверять ОКС , который вшит в загружаемые с сервера данные или программы (апплеты).

Обладая ОКС , которому мы доверяем, можно приступить к дальнейшей работе с сервером.

Если система строится с применением клиентских приложений, то необходимо доверять установленному клиентскому ПО. После чего по подобной, приведенной выше цепочке мы можем доверять серверу, с которым установлено соединение.

Возможные атаки.

1. При передаче ОКС . Он, в принципе, доступен всем, поэтому злоумышленнику перехватить его не составит труда. Обладая ОКС , теоретически можно вычислить ЗКС . Необходимо использовать криптографические ключи, достаточной для заданного времени сохранения конфиденциальности длины.

2. После передачи с сервера ОКС и перед отправлением клиентом в ответ своих ОКК и КС . В случае если при их генерации (ОКК , ЗКК и КС ) используется слабый генератор случайных чисел, можно попытаться предсказать все три указанных параметра или какой-нибудь один из них.

Для отражения данной атаки необходимо генерировать случайные числа, отвечающие ряду требований. Нельзя, например, использовать для генерации случайных чисел таймер, так как злоумышленник, перехватив первое сообщение (ОКС от сервера), может установить время отправления пакета с точностью до секунд. Если таймер срабатывает каждую миллисекунду, то для вскрытия необходим полный перебор всего лишь 60 000 значений (60 с _ 1000 мс).

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

3. При передаче от клиента к серверу пакета, содержащего ОКК , КС , Х , зашифрованного ОКС . Чтобы вскрыть перехваченную информацию, необходимо обладать ЗКС . Данная атака сводится к атаке, рассмотренной выше (подбор ЗКС ). Сама по себе закрытая информация, передаваемая серверу, бесполезна для злоумышленника.

4. При передаче от сервера к клиенту некоторого тестового сообщения Х , зашифрованного КС и ОКК и подписанного ЗКС . Чтобы расшифровать перехваченное сообщение, надо знать и ОКК , и КС , которые будут известны в случае реализации одной из приведенных выше атак после того, как противнику стал известен ЗКС .

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

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

Итак, мы рассмотрели атаки, возможные на этапе реализации процедуры «рукопожатия» (HandShake). Опишем атаки, которые могут осуществляться в процессе передачи данных по нашему каналу.

При перехвате информации злоумышленник может читать открытый текст только в том случае, если ему известен КС . Злоумышленник может предсказать или подобрать его, полностью перебрав все его возможные значения. Даже если противнику известно сообщение (то есть он знает в точности, как выглядит открытый текст, соответствующий тому коду, который он перехватил), он не сможет однозначно установить ключ шифрования, поскольку данный текст подвергался алгоритму сжатия.

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

Из описанного следует, что в любом случае злоумышленник может применить только атаку на основе полного перебора всех возможных значений ключа. Для усиления устойчивости к данному типу атак необходимо расширять диапазон значений КС . При использовании ключа длиной 1024 бита диапазон возможных значений возрастает до 2 1024 .

Чтобы писать или подменять сообщения, передаваемые по каналу связи, злоумышленнику необходимо знать закрытые ключи обеих сторон-участников обмена либо знать один из двух закрытых ключей (ЗК ). Но в этом случае он сможет подделывать сообщения только в одну сторону, в зависимости от того, чей ЗК он знает. Он может выступать в качестве отправителя.

При попытке подмены какой-либо из сторон, то есть при попытке выдать себя за легального участника обмена после установления сеанса связи, ему необходимо знать КС и ЗК (см. случаи, рассмотренные ранее). Если ни КС , ни ЗК того, вместо кого он хочет подсоединиться к каналу связи, злоумышленнику неизвестны, то система тут же узнает об этом, и дальнейшая работа с компрометированным источником прекратится.

В самом начале работы, при подсоединении к серверу, возможна тривиальная атака: подмена DNS-сервера. Защититься от нее не представляется возможным. Решение данной проблемы возложено на администраторов DNS-серверов, находящихся в ведении интернет-провайдеров. Единственное, что может спасти, – это уже описанная выше процедура проверки сертификата сайта браузером, подтверждающая, что произошло подключение именно к нужному серверу.

Заключение

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

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

Подобную технологию организации защищенных соединений организует протокол сетевого взаимодействия SSL. Кроме этого, на основе предложенных принципов строятся виртуальные частные сети (Virtual Private Networks – VPN).

ЛИТЕРАТУРА

1. Медведовский И. Д., Семьянов П. В., Платонов В. В. Атака на Интернет. – СПб.: Изд-во «ДМК» 1999. – 336 с.

2. Карве А. Инфраструктура с открытыми ключами. LAN/Журнал сетевых решений (Russian edition), 8, 1997.

3. Мельников Ю. Н. Электронная цифровая подпись. Возможности защиты. Конфидент № 4 (6), 1995, с. 35–47.

4. Теренин А. А., Мельников Ю. Н. Создание защищенного канала в сети. Материалы семинара «Информационная безопасность – юг России», Таганрог, 28–30 июня 2000.

5. Теренин А. А. Разработка алгоритмов для создания защищенного канала в открытой сети. Автоматизация и современные технологии. – Изд-во «Машиностроение», № 6, 2001, с. 5–12.

6. Теренин А. А. Анализ возможных атак на защищенный канал в открытой сети, созданный программным способом. Материалы XXII Конференции молодых ученых механико-математического факультета МГУ, М, 17–22 апреля 2000.

Организация защищенного канала связи