С технических позиций
Новые инструменты делают старые проблемы защиты серьезнее и повышают нагрузку на информационные системы
Несмотря на громкие заявления, что язык Java - самый безопасный способ перемещения в киберпространстве, специалисты по информационным системам опасаются, что этот мощный вездеход слишком быстр, чтобы на нем можно было без опасений носиться по диким дорогам Internet.
На самом деле все и хуже, и лучше, чем могло бы показаться. С одной стороны, многие потенциальные проблемы Java, касающиеся корпоративных пользователей, - отнюдь не новость, а просто старые тревоги в новом контексте.
С другой стороны, несмотря на частые указания на "врожденную" безопасность Java по сравнению с другими технологиями, язык сам по себе не в состоянии решить многие из проблем, уже давно мешающих осуществлению транзакций на корпоративном уровне.
Неверный фокус
Несмотря на то что количество сообщений в прессе о защите в среде Internet резко увеличилось, по сути ничего не изменилось. Во многих дискуссиях указывается на такие типы угроз, которые в реальности редко приводят к серьезным проблемам.
Например утверждается, что язык Java фирмы Sun Microsystems безопасен по определению, поскольку Java-приложения (то есть приложения на Java, возможности которых ограничены средой систем просмотра World-Wide Web) не могут считывать или изменять файлы на клиентской машине.
Однако в одном из самых печальных эпизодов вандализма в Internet (распространение вируса в ноябре 1988 года) ни один файл на клиентской машине не был уничтожен или модифицирован. Проблема состояла в быстром размножении копий программы, пожирающих машинные ресурсы и сетевой диапазон до тех пор, пока системы не переставали работать.
В среде, где распределенная обработка - норма, практически неважно, защищена ли информация, если к ней есть доступ. Отказ в предоставлении услуг - надежная форма нападения, а просто сделав ресурс доступным всей Internet, можно добиться того, чтобы информация распространилась настолько, что законные пользователи не смогли бы до нее добраться.
При работе в кооперативных сетях невозможно предсказать, во сколько обойдется предоставление доступа к удаленным данным в реальном времени.
В сущности, проблема перенасыщения ресурсами уже превращается в самую серьезную угрозу коммерческой жизнеспособности Internet. В апрельском номере журнала Wired предложен сценарий развития ситуации (слишком, к сожалению, реальный), написанный в форме статьи в Time от января 1997 года и озаглавленный "Оглушительное падение Web". В статью включен пародийный "отчет", согласно которому всего 10% обращений на Web-страницы были сделаны индивидуальными пользователями, которым действительно нужно было просмотреть информацию, а 90% - механизмами индексации Web.
Такие программы индексации, разработанные для исследования Web и создания каталогов ее ресурсов, демонстрируют потрясающее сочетание скорости и тупости. Они могут, например, встретив на Web-странице кнопку создания новой страницы, имитировать щелчок на ней и повторять то же самое бесконечно, продолжая пробираться через бессчетные одинаковые страницы.
Еще проще - бесконечный цикл, который возникает, если программа индексации оказывается не в состоянии определить циркулярные взаимоотношения между страницами, связи на которых на самом деле отправляют в начало поиска. Такую ситуацию легко представить, учитывая, что страницы Web должны помогать пользователям в поиске взаимосвязанной информации из любой отправной точки.
Появление в Web языка такой мощности, как Java, никак не поможет избежать подобной растраты возможностей сети. В принципе, эти проблемы существуют по крайней мере с тех пор, как в LISP возникли потенциально замкнутые структуры данных. Абстракции Java, хотя во многих случаях и оказываются мощными, не включают ничего, что помогло бы программистам создавать более интеллектуальные агенты.
Игроки и игры
Сами интеллектуальные агенты, даже если бы их было легко писать, скорее всего, создали бы больше проблем, чем решили. Один интеллектуальный агент - это перерыв, два могут превратиться в охотника и жертву, а сотня или больше стали бы настоящей экосистемой, в которой бы существовало множество конкурирующих видов и шли процессы естественного отбора.
Исследователи Джеффри Розеншайн из Еврейского университета Иерусалима и Джилад Злоткин из Школы менеджмента Слоуна при Массачусетском технологическом институте изучали использование методов теории игр для исследования и прогнозирования результатов.
В своей книге "Законы борьбы" (Rules of Encounter, MIT Press) ученые отметили два аспекта, возникающих при любом взаимодействии агентов. Первый из них - общие правила игры, аналог стандартов Internet типа Common Gateway Interface и языка Java.
Второй - личная стратегия партнеров. В этом случае Java ни больше ни меньше чем обоюдоострый меч в арсенале любой технологии, потенциально ровно настолько полезный или опасный, насколько опасны или полезны намерения тех, кто его использует.
Приложение на Java, чтобы получить приоритет в транзакции, может применять нечестные методы, которые при этом сами по себе не будут незаконны. Люди участвуют в транзакции, имея независимые цели, а инструменты типа Java просто предоставляют программистам шанс достигать их не совсем обычными способами.
Программные агенты будут не более безобидны, чем те, кто их создал. "Они не будут дружественны по определению, не станут делиться информацией или отступать в интересах дела, - предупреждают Розеншайн и Злоткин. - Мы не можем искать решений, которые потребуют великодушных агентов, если не только мы создаем все агенты для работы в конкретной области".
Тихая работа
Еще одна проблема, привлекшая большое внимание, - вопрос защиты принципиально важных данных, например номеров кредитных карт. Было предложено много вариантов, один из которых - использование алгоритмов, подтверждающих право собственности на информацию без разглашения самой информации.
Один из этих методов напоминает тот, когда на карте изменяются цвета, а потом задается вопрос о взамоотношении между областями на ней: только тот, у кого есть настоящая карта, может выполнить указания по ее изменению, а затем правильно ответить на вопросы. Однако в процессе аутентификации сама карта не передается.
К сожалению, такой метод защищает только от злонамеренного использования информации теми, кто не входит в число участников транзакции. Менеджеры по защите сетей, считающие такой метод достаточным, даже при идеальном стечении обстоятельств игнорируют огромное количество подделок кредитных карт, где все начинается с продавца, уже принимающего участие в операциях.
Например, когда отдел выплат компании обрабатывает номера кредитных карт или другие личные данные, его сотрудникам доверяют ту информацию, которую некоторые схемы сетевой защиты гордо скрывают от третьих сторон. Ирония в том, что такие сотрудники могут угрожать защите куда больше, чем обычный администратор или представитель Internet-узла.
Само по себе участие в транзакции не делает человека достойным доверия. Хороший вариант защиты спасает от угрозы изнутри так же, как и от угрозы извне.
Другие потенциальные проблемы можно назвать внешними и по отношению к самому Java, поскольку они возникают при его взаимодействии с инструментами поддержки типа систем просмотра Web. Эти системы могут использовать, например, механизмы кэширования и задерживать информацию, подлежащую защите, в форме, которая ее не обеспечивает.
Как и любая другая технология обработки информации, Java обладает ограниченными знаниями об окружающей его системе. Приложения на Java сами по себе не обладают способностью выяснять, какое сообщение будет интересно конкретным участникам, или предпринять какие-то действия, чтобы ограничить их доступ.
Если клиентская операционная система пользователя позволяет одному процессу "подглядывать" за событиями другого, Java здесь не поможет. Он не сможет помешать пользователю поддаться обману и запустить утилиту, которая будет периодически паковать собранную информацию и отправлять ее по электронной почте.
Не рвите цепь
Корпоративные покупатели хотят четко увидеть различия между защищенными и незащищенными методами, но в цепочке системной защиты много звеньев.
Цепь таких взаимоотношений можно создавать, начиная с любой стороны и даже с середины. Любой компонент, даже использующий "незащищенную" технологию, можно защитить, создав вокруг него безопасное решение (хотя это может потребовать недопустимо больших затрат).
И наоборот, даже защищенная технология в одном элементе цепи может потерять смысл из-за неправильных решений в любой другой точке пути, ведущего от вычислений или информации к пользователю.
Питер Коффи
JAVA НЕ МОЖЕТ СДЕЛАТЬ ВСЕГО
Слабые звенья в защищенных транзакциях
Защита на уровне продавца: Java-приложение заслуживает доверия настолько же, насколько и те, кто его использует.
Защита связи: Замещение или изменение передаваемого кода на Java могут стать средством нападения.
Защита при аутентификации: "Цифровые сертификаты" и другие методы идентификации приложений на Java сами по себе могут стать предметом подделки или других махинаций.
Защита на уровне инструментария: Утилиты типа систем просмотра, кэша или программируемых пользователем сокращенных команд могут захватывать самый важный код и данные в форматах, не поддающихся формальному контролю.
Защита на уровне клиента: Клиентские терминалы могут превратиться в западни, где программы-шпионы будут захватывать пароли и другие принципиально важные данные.
НОВОЕ В JAVA, ЗАЩИТЕ И INTERNET
Источник: БД Computer Library на 26 марта; результаты поиска
по ключевому слову на (java or internet or web) and (secur*
or priva* or confidenti*)
