Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Безопасное исполнение Java-программ

Элайас Леви

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

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

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

Разработчики Java создали систему программирования, сильную в одних отношениях, но слабую в других.

Разработка безопасной программы

До появления языка Java, разработка безопасной программы, как правило, сводилась к написанию привилегированной программы, устойчивой к злонамеренным попыткам использовать ее права доступа. Привилегированная программа—это программа, которая взаимодействует с другими программами, не имеющими те же самые права доступа. К таким программам относятся, прежде всего, сетевые службы, программы SUID/SGID и сетевые клиенты. Атаки на эти программы обычно являются результатом дефектов программного обеспечения, хотя ошибки конфигурирования ПО или неквалифицированное программирование также могут стать их причиной. К числу распространенных атак такого рода можно отнести атаки посредством переполнения буфера, атаки, обусловленные конфликтами между файлами и атаки, связанные с проверкой достоверности входных данных.

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

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

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

Та же самая проблема одолевает Java и в том случае, когда дело доходит до взаимодействия с другими службами безопасности базовой платформы. Так например, Java-программы не имеют понятия о полномочиях доступа к файлам или списках контроля доступа (Access Control List—ACL). Java-программа, которая собирается воспользоваться средствами безопасности и службами базовой ОС, должна прибегнуть к использованию непереносимого кода, такого как код NMI (Native Method Invocation) языка Java.

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

Безопасное выполнение программ

Все дискуссии, предметом которых является безопасность Java, разворачиваются главным образом вокруг способности среды Java к безопасному выполнению программ (в первую очередь неавторизованного подозрительного кода). Столь сложная для среды программирования Java задача закулисно осуществляется рядом компонентов виртуальной Java-машины (Java Virtual Machine—JVM): загрузчиком классов, верификатором, диспетчером безопасности и контроллером доступа. Эти компоненты образуют так называемую “песочницу” Java. Компоненты песочницы позволяют Java исполнять неавторизованную часть кода, но при этом предотвращают выполнение ею опасных действий и нарушение целостности среды программирования Java.

Такие средства языка Java, как строгий контроль типов данных и контроль границ массивов, становятся реальной необходимостью, если среда исполнения должна сохранять свою целостность и блокировать действия враждебного кода по ее разрушению. По умолчанию полномочия неавторизованной программы существенно ограничены. Например, она лишена прав доступа к файловой системе. Совершенно очевидно, что такая программа уже не столь полезна. В версии Java 2 диспетчер безопасности (Security Manager) был изменен в связи с добавлением нового компонента - контроллера доступа (Access Controller). Начиная с версии Java 2, у нас появилась возможность создавать политику безопасности, позволяющую выборочно назначать Java-программам полномочия по выполнению определенных операций. Эта политика выполняет контроль безопасности всех Java-кодов (как локальных программ, так и аплетов), за исключением тех классов, которые встречаются в пути классов.

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

Вы можете создать файл политики безопасности как вручную, используя текстовый редактор, так и с помощью утилиты Policy Tool, имеющейся в наборе инструментальных средств разработки Java-программ (Java Development Kit—JDK). Назначение полномочий в рамках политики безопасности производится на основе исходного, кода подписанного определенным ключом, или того и другого одновременно. Базовая система Java определяет полномочия по отношению к средствам защиты системы, к файловой системе и к интерфейсам socket.

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

Что касается программистов, то они могут сами расширить набор доступных полномочий для создаваемых ими программ. Дополнительную информацию по вопросам настройки политики безопасности Java можно найти в работе “Security in Java SDK 1.2” по адресу java.sun.com/docs/books/tutorial/security1.2/.

Дополнительные API

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

Фирма Sun также предоставляет криптографический пакет расширений для Java (Java Cryptographic Extensions—JCE), который добавляет к уже имеющимся базовым Java-интерфейсам API интерфейсы для шифрования, обмена ключами, генерации симметричных ключей и кода аутентификации сообщений (см. java.sun.com/products/jce/). Сервер Java Authentication and Authorization Server (JASS) добавляет интерфейсы API, реализующие аутентификацию, основанную на пользователях и механизм контроля доступом, а также основанное на Java “перевоплощение” пользователей и их единую регистрацию (см. developer.java.sun.com/developer/earlyAccess/jaas/). И наконец, пакет Java Secure Socket Extensions (JSSE) обеспечивает поддержку сетевых протоколов безопасной передачи данных на транспортном уровне SSL и TLS.

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





  
11 '2000
СОДЕРЖАНИЕ

колонка редактора

• Реальное общение для виртуальной экономики

локальные сети

• Беспроводные сети стандарта 802.11 - в массы

• С появлением новых стандартов меняются и требования к тестированию кабельных систем

• Знание стандартов облегчает спецификацию оптоволоконных кабелей

• В поисках идеальной сетевой ОС

услуги сетей связи

• Соглашения об уровне обслуживания при аренде цифровых каналов

• Анатомия пакетной передачи речи. Часть I. Пропускная способность

• Взгляд в будущее

только на сервере

• Управление трафиком Интернет: нет - хаосу, да - порядку!

• Электронная почта Интернет

• Безопасное исполнение Java-программ

• Тестер NetTool: мал, да удал

корпоративные сети

• ПО резервного копирования в корпоративных сетях

• Увидеть слона целиком. Часть II

• Персонализируемые порталы

защита данных

• Внедрение технологий VPN в корпоративных сетях

электронная коммерция

• "Театр Кабуки"

системы учрежденческой связи

• Внутренние радиотелефонные системы

новые продукты

• Сервер телематических служб от "КБ Кроникс", Tizona v2.0 - биллинг для Интернет-провайдеров, Плинты "Элграф" - эволюция при модернизации оконечных кабельных устройств


• КАЛЕЙДОСКОП



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх