Мифы и реальности электронной коммерции

Миф 1
Системы можно сделать защищенными

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

 

Миф 2
Безопасность сайтов - это исключительно технический вопрос

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

 

Миф 3
СМИ регулярно сообщают обо всех слабых местах и рисках в области безопасности

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

 

Миф 4
Информация по кредитным карточкам в Интернет не защищена

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

 

Миф 5
Пароли идентифицируют людей

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

 

Миф 6
Однажды сконфигурированное и установленное решение по безопасности остается надежным с течением времени

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

 

Миф 7
Брандмауэры непроницаемы. Реализовав брандмауэр, можно почивать на лаврах в уверенности, что злоумышленники никогда не проникнут через него

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

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

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

 

Миф 8
Вирусы больше не являются проблемой

Реальность - Вирусы до сих пор представляют серьезную опасность. Последнее увлечение создателей вирусов - вложенные в письма файлы, при открытии выполняющие макрос, производящий несанкционированные получателем действия. Но разрабатываются и другие средства распространения вирусов - например, через HTML web-страниц.
Необходимо убедиться, что ваши антивирусные продукты сохраняют актуальность. Если они были предназначены для поиска вирусов, может оказаться, что они способны только выявлять вирусы, но не устранять их.
PKI (Public Key Infrastructure, инфраструктура открытых ключей, поддерживающая использование пар соответствующих друг другу ключей, открытого и закрытого) обычно рассматривается как панацея от всех проблем безопасности электронной коммерции. Это не так. Действительно, эта технология может создать ложное чувство защищенности. Сегодня она уже является составной частью множества электронно-коммерческих приложений - в основном в среде B2B. Но движется ли развитие PKI в том же направлении, неизвестно.

 

Миф 9
Компания, имеющая сертификат на открытый ключ от уважаемого Certification Authority (CA), сама по себе уже заслуживает доверия

Реальность - Сертификат просто подразумевает нечто вроде:

"На момент запроса сертификата, я, CA, произвел известные действия для проверки идентичности этой компании. Вас это может удовлетворить, а может и нет. Я не знаком с этой компанией и не знаю, можно ли ей доверять, и даже - в чем именно состоит ее бизнес. До тех пор, пока меня не известят, что открытый ключ дискредитирован, я даже не узнаю, что он, например, украден или передан кому-то еще, и это ваше дело - проверять, не аннулирован ли он. Моя ответственность ограничивается положениями документа, описывающего политику моей компании (Policy Statement), которое вам следует прочитать прежде, чем использовать ключи, связанные с данной компанией".

 

Миф 10
Цифровые подписи являются электронным эквивалентом рукописных

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

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

 

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

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

 

Миф 12
Продукты в области безопасности легко устанавливаются

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

 

Миф 13
PKI-продукты защищают электронную коммерцию без дополнительной настройки

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

 

Миф 14
Консультанты по безопасности заслуживают абсолютного доверия

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

Выводы

Таким образом, прежде чем листать самые современные брошюры по вопросам безопасности, разложите по полочкам основное:

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

 

 

Приложения

Защита Java и ActiveX

Любой пользователь браузера Web - будь то Netscape Navigator или Internet Explorer корпорации Microsoft - становится рядовым растущей армии пользователей Java. При этом неважно даже, что такой пользователь может вовсе не уметь программировать и не претендует на звание разработчика ПО, знающего алгоритмические языки вдоль и поперек и способного с закрытыми глазами найти ошибку в коде C или C++. Стоит только человеку запустить один из самых популярных браузеров - и он уже пользователь Java, нравится ему это или нет.

Нет ничего проще, чем заглянуть в волшебный мир Java - каждый, кто хоть раз видел какое-нибудь переливающееся всеми цветами радуги, вращающееся название в окне браузера, может считать, что уже побывал там. Корпорация Microsoft, не желая отстать от Sun Microsystems, предложила свой собственный исполняемый код, известный как ActiveX. Эта среда позволяет разработчикам создавать элементы управления, основанные на программной архитектуре Component Object Model (COM). Последняя служит для поддержки создания приложений на таких языках, как C и C++. Апплеты Java широко применяются сейчас на узлах Web, при этом пока только немногие используют ActiveX.

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

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

Пожалуй, всякий "ходивший по Сети" хоть раз да читал сообщения о мобильных программах, делающих на настольных компьютерах всякие пакости. (Более подробно они описаны во врезке "Хороший, плохой, злой".) Правда в том, что большинство представителей прессы, равно как и разработчиков, не имеет целостной картины возможной опасности, которую несут Java и ActiveX.

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

ОБРАТИМСЯ К JAVA

Когда в начале 1995 года Sun представила Java, разработчикам и производителям показалось, что у них в руках очутилась волшебная палочка. У них были все основания радоваться: Java обещал сделать Web реально пригодным для коммерции и давал хорошие шансы вырваться вперед и победить конкурентов. Апплеты Java - маленькие порции переносимого исполняемого кода, работающего на всех имеющих доступ к Web машинах, давали преимущество тем компаниям, которые хотели бы выйти на необъятный интерактивный рынок.

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

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

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

общее представление о том, как Java работает и как среда Java реализована

в Web. Прежде всего разработчики пишут исходный код на языке программирования Java. Компилятор преобразует этот код в байт-код Java. Байт-код в форме апплета размещается на странице Web, доступ к которой осуществляется при помощи браузера, рассчитанного на работу с Java. Браузер проверяет код, после чего виртуальная машина Java (Java Virtual Machine, JVM) осуществляет выполнение апплета на клиентской машине.

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

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

"Бреши в защите - сейчас они ликвидированы - имели различное происхождение: некоторые возникли из-за простых ошибок реализации, другие имели принципиальный характер", - пояснил Гэри Макгрей, исследователь из Reliable Software Technologies, изучающий вопросы безопасности Java с первых дней существования технологии.

Он добавил, что каждая новая реализация JDK (в начале 1998 года начнутся массовые поставки версии 1.2) порождала новые проблемы с безопасностью, однако найденные ошибки неизменно быстро устранялись. "Чем больше сложность, тем больше вероятность ошибки, - признал исследователь. - Я уверен, найдется еще масса недочетов". По мнению Макгрея, из-за ажиотажного спроса компании Кремниевой долины торопятся с выпуском кода, так что безопасность отходит на второй план.

ВЕСЬ МИР В ПЕСОЧНИЦЕ

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

Вся система безопасности Java строится вокруг так называемой модели безопасности Sandbox (этот термин можно примерно перевести как "пожарный ящик с песком"). Эта идея реализована уже в ранних версиях JDK 1.0.x. Sandbox предусматривает ограниченную среду для выполнения апплетов Java, неблагонадежных удаленных кодов. Суть принципа Sandbox состоит в том, что локальные коды считаются надежными, и в их распоряжение предоставляются файлы и другие системные ресурсы, а загружаемые удаленные коды - нет. Им открывается доступ только к определенным ресурсам в пределах Sandbox.

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

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

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

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

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

МИР ЗА ПЕСОЧНИЦЕЙ

JavaSoft постоянно работает над JDK, и, конечно, эта работа состоит не только в латании дыр, но и в совершенствовании самой технологии.

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

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

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

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

В модели защиты JDK 1.1.x только код, чей сертификат признается клиентом, может рассматриваться как локальный; в соответствии с принятой политикой в отношении подписей. Все остальные "попадают" в Sandbox с весьма ограниченными правами доступа.

В JDK 1.2 разработчики вышли за рамки традиционной модели Sandbox и предложили более гибкую схему. В новой версии, по мнению Ли Гонга, специалиста по архитектуре защиты в JavaSoft, инструментарий JDK дает пользователю более совершенные методы контроля доступа. "В JDK 1.2 система не загоняет все апплеты в Sandbox, а предоставляет пользователю возможность выбора", - пояснил он.

Кроме того, в JDK 1.2 все локальные коды не считаются заведомо заслуживающими доверия, все они - удаленные или локальные - подвергаются одинаковой проверке. Какие действия разрешены тому или иному фрагменту кода, определяет политика конечного пользователя в отношении защиты. Так, некоторые типы кодов будут помещены в Sandbox, в то время как другие получат более широкие возможности доступа (см. Рисунок 2).

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

"Выработать действенную и непротиворечивую стратегию непросто, - предупреждает Макгрей. - Нечто подобное происходит и с брандмауэрами. Многие покупают их, исходя из прейскуранта, и пребывают в полной уверенности, что теперь надежно защищены. Главной же всегда остается выработка правил и корректная их настройка".

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

ПРИГЛЯДИМСЯ К ACTIVEX

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

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

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

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

ActiveX поддерживает некое средство под названием Authenticode, позволяющее разработчику визировать компоненты ActiveX посредством цифровой подписи. Так что при встрече с таким элементом в Web пользователь имеет возможность получить представление об авторе и решить, насколько он заслуживает доверия. Большинство компаний, которые допускают ActiveX до своих сетей, пользуются исключительно подписанными компонентами. Житейская мудрость гласит, что неподписанных элементов надо сторониться, как черт ладана. В случае с неподписанными апплетами Java, какие бы подозрения они ни вызывали у пользователей, модель защиты Sandbox и средство проверки байт-кода значительно снижают риск злонамеренных действий при выполнении программ.

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

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

БДИ!

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

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

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

Одной из первых продукт такого рода на рынок поставила Finjan. Компания предлагает системы, которые анализируют информационное наполнение, содержащее Java и ActiveX, на уровне шлюза Internet и на настольном компьютере (подробнее см. в статье Александра Авдуевского "Серфинг за щитом" в декабрьском номере журнала LAN за прошлый год).

Компания Digitivity разработала AppRouter, который распознает приходящие апплеты и затем загружает фиктивный апплет взамен оригинального. Этот апплет связывается с производимым этой же компанией сервером CageServer, на котором и исполняются оригинальные апплеты Java. Таким

образом, какой бы апплет пользователь ни загрузил с Web, код направляется на специальный сервер, а не к пользователю. Апплет выполняется на этом сервере-посреднике, а результат отображается в браузере. Таким образом, код не взаимодействует ни с одним сетевым ресурсом, кроме специального сервера.

Еще одна компания, Security-7 Software, поставляет продукт под названием SafeGate, осуществляющий анализ Java и ActiveX в режиме реального времени.

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

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

НЕХОРОШИЕ АППЛЕТЫ

Хороший, плохой, злой

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

Так называемые враждебные апплеты могут иметь несколько разновидностей. Первая, способная принести максимальный вред, называется иногда "атакующим апплетом". Создатели таких программ используют "дыры" в защите Java, предупреждает Гэри Макгрей, исследователь компании Reliable Software Technologies, долгое время изучавший технологию Java.

К счастью, атакующих апплетов до сих пор не зарегистрировано в сети, но они действительно существуют. "Им не удалось покинуть лаборатории; исследователи обнаружили их существование раньше злоумышленников", - говорит Макгрей.

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

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

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

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

"По нашему глубокому убеждению, 99,5% пользователей Internet - порядочные люди, и злонамеренные коды фабрикует маленькая горстка изгоев, - уверен Энди Бруно, директор по маркетингу компании Digitivity, занимающейся разработкой продуктов для защиты корпоративных сетей от враждебных кодов. - Злонамеренные коды встречаются пока нечасто, тем не менее пользователю следует регулярно просматривать журналы событий и результаты аудита, чтобы иметь представление о том, что же, собственно, происходит в сети".

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

⇐ Предыдущая53545556575859606162Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: