Платная информация, такая как новости, периодические издания, доступ к базам данных и т. д. Использование Интернета для предоставления этих сервисов гораздо дешевле, чем использование факса, телефона или обычной почты. Потенциальные клиенты могут искать и получать информацию в нужном им темпе, и это не будет требовать дополнительных затрат на службу технического сопровождения. Обычно такие информационные сервисы используют WWW как базовый механизм для предоставления информации. Целостность и доступность предоставляемой информации - главные проблемы обеспечения безопасности, требующие применения средств безопасности и создания политики безопасности. 4. 11. Финансовые транзакции
Так или иначе, но компьютеры и сети давно используются для обработки финансовых транзакций. Перевод денег со счета на счет в электронном виде используется для транзакций банк-банк, а банкоматы используются для операций клиент-банк. Авторизация покупателя с помощью кредитных карт выполняется с помощью телефонных линий и сетей передачи данных. Для поддержания безопасности этих транзакций они выполняются с помощью частных сетей или шифруются. Использование частных глобальных сетей (как и для EDI) ограничивало возможности взаимодействия. И только Интернет дал дешевую возможность осуществлять финансовые транзакции. Существует три основных класса финансовых транзакций и пять основных типов механизмов платежа: Таблица 4. 3. Платежи и финансовые транзакции
Наличные
Чек
Дебит
Кредит
Электронный перевод фондов
Компания-компания
Основной
Вспомогательный
Компания-клиент
Основной
Вспомогательный
Вспомогательный
Вспомогательный
Клиент-клиент
Основной
Вспомогательный
Использование Интернета для выполнения этих типов транзакций позволяет заменить представление или показ наличных, чеков, кредитных карт их электронными эквивалентами: Наличные - сейчас существует ряд конкурирующих подходов для реализации электронных денег, реализация которых еще находится на стадии разработки. Все эти методы используют криптографию для создания безопасных цифровых "бумажников", в которых хранится цифровая наличность. Передача электронных денег необязательно требует участия финансовых учреждений в качестве промежуточной стадии. Чеки - банковская индустрия разрабатывает стандарт для электронных чеков, определяющий как информация, содержащаяся в физических чеках, должна представляться в электронном сообщении. Электронные чеки всегда требуют участия финансовых учреждений при их передаче. Дебитовые карты - смарт-карты и карты с памятью могут хранить электронные деньги рядом способов. Каждая транзакция дебитует определенное количество, пока карта не опустеет. Карты с памятью не требуют использования финансовых учреждений. Кредитные карты - основные игроки в индустрии кредитных карт(Visa, Master Card, и American Express) разработали стандарт для выполнения транзакций с кредитными картами по глобальным сетям. Известный под названием Безопасные Электронные Транзакции (Secure Electronic Transactions), этот стандарт определяет трехэтапные транзакции между клиентом, продавцом и владельцем дебита кредитной карты, обычно банком. Транзакции электронных кредитных карт, использующие SET, всегда требуют участия финансового учреждения. Электронный перевод фондов(EFT) - он использует криптографию для обеспечения безопасности перевода фондов между банками и другими финансовыми учреждениями. Клиенты могут авторизовать банки на посылку и прием платежей с помощью EFT для клиента. Каждая из этих форм электронных финансовых транзакций включает использование криптографии для обеспечения целостности, конфиденциальности, аутентификации и контроля участников взаимодействия. 4. 12. Постоянная доступность для взаимодействия
По мере того, как Интернет становится более важным для выполнения повседневной деловой деятельности, к средствам обеспечения безопасности соединения с Интернетом все чаще предъявляются требования непрерывности работы. Эти требования часто оказывают большое влияние на политику безопасности, требуя компромиссных решений между стоимостью дублирующих комплектов и стоимостью временной работы без средств обеспечения безопасности. Простым примером является брандмауэр. Брандмауэр может оказаться критическим местом - если он выйдет из строя, все связь с Интернетом может оказаться невозможной на время устранения аварии. Если временная потеря связи с Интернетом не оказывает большого влияния на деятельность организации, политика может просто определять, что работа с Интернетом прекращается до тех пор, пока не будет восстановлен брандмауэр. Для организаций с низким уровнем риска политика может позволять отключать брандмауэр и работать с Интернетом без него на время аварии. Тем не менее, если связь с Интернетом важна, или организация имеет высокий уровень риска, политика может требовать использования брандмауэра с горячим или холодным резервом. Задачи организации определяют, какое решение будет принято. Для очень больших организаций производительность может также диктовать использование нескольких средств безопасности, таких как брандмауэры и сервера аутентификации. Например, организации, обеспечивающей деятельность нескольких тысяч внешних пользователей в Интернете, может потребоваться несколько соединений с Интернетом класса T1, что в свою очередь потребует использования нескольких брандмауэров. Организации с несколькими тысячами внутренних пользователей, имеющих тенденцию соединяться с системой в одно и то же время (утром, вечером и т. д. ) может потребоваться несколько серверов аутентификации для того, чтобы время подключения было в допустимых пределах. Основными способами удовлетворения требований постоянной доступности являются: Планирование ресурсов. Замечен интересный феномен - как только брандмауэр установлен, пользователи начинают жаловаться, что соединение с Интернетом стало медленнее. Правильно выбранные средства безопасности, такие как брандмауэр, обычно не являются самым узким местом в системе. Но важно детальное планирование выделения ресурсов, так как средства безопасности, сильно уменьшающие производительность работы, будут быстро отключаться. Данные из спецификаций брандмауэров должны делиться пополам при моделировании нужной производительности, а производительность критических средств обеспечения безопасности должна проверяться и настраиваться в тестовой сети. Избыточность - для всех организаций, кроме тех, что имеют низкий уровень риска, необходим резервный брандмауэр в горячем резерве. Аналогично, использование серверов аутентификации или серверов безопасного удаленного доступа обычно требует наличия возможности быстро переключаться на резервный сервер. Синхронизация - вот главный вопрос при использовании резервных серверов безопасности - все обновления, резервные копии и модификации должны производиться на обоих системах. Восстановление - когда вышедший из строя блок восстановлен и принесен назад, должен осуществляться тщательный контроль его конфигурации. Должна быть проанализирована конфигурация программ и оборудования, чтобы гарантировать, что работают все необходимые продукты, их версии актуальны, и к ним применены все модификации и исправления, и что не добавлены или включены ненужные сервисы в ходе восстановления. Любые отладочные возможности, использовавшиеся для тестирования, должны быть удалены или отключены. 4. 13. Легкость использования
Состав пользователей многих систем, подключенных к Интернету, может быть весьма разнообразным - от секретарей до ученых, от новичков до опытных пользователей. Частым бизнес-требованием является требование, чтобы все приложения можно было легко использовать среднему пользователю. Это требование трудно оценить, но с точки зрения безопасности часто оно переводится так: "если средство безопасности становится помехой людям при выполнении ими своей работы, вы должны отключить такое средство". Двумя составными элементами легкости использования являются уменьшение числа раз, когда пользователь должен аутентифицироваться в системе и разработка интерфейса пользователей со средствами безопасности таким, чтобы он соответствовал уровню или предпочтениям пользователей системы. Эти вопросы обсуждаются в следующих разделах. 4. 14. Единовременная регистрация
Для выполнения своих повседневных задач пользователю может понадобиться зарегистрироваться на большом числе компьютеров и сетей. Часто каждая система требует от пользователя ввода имени и пароля. Так как запоминание большого числа паролей для пользователей является трудным, это ведет к тому, что пароли пишутся на бумаге (и часто на мониторах ПЭВМ) или забываются. Другой реакцией пользователя является использование одного и того же пароля на всех компьютерах. Тем не менее, разные системы могут иметь различные правила для паролей или иметь различные периоды проверки корректности пароля, что может снова привести пользователей к записыванию нескольких паролей на бумаге. Системы с одной аутентификацией в начале работы делают использование нескольких паролей прозрачным для пользователя. Это реализуется несколькими способами: Некоторые системы просто создают скрипты, содержащие пары имя-пароль и команды входа в удаленные системы. Это освобождает пользователя от хлопот, но переносит их на обслуживающий персонал, которому требуется поддержание скриптов. Такие скрипты часто требуют безопасного хранения, и их неавторизованное использование может дать доступ ко всем системам, на которых зарегистрирован пользователь. Другой подход базируется на Kerberos и использует криптографию для передачи привилегий пользователя сети или серверу, к которому пользователю нужен доступ. Эти системы требуют создания и работы серверов привилегий, а также интеграции этой технологии в каждую систему, к которой должен иметь доступ пользователь. 4. 15. Разработка пользовательского интерфейса
Разработка пользовательского интерфейса для средств обеспечения безопасности в Интернете должна быть согласована с интерфейсом других приложений, которые регулярно используются пользователями. Когда средства безопасности приобретаются, или встроены в приобретаемые приложения, пользовательский интерфейс находится вне зоны контроля организации. Но для средств, разработанных в организации, важно, чтобы интерфейс был удобен для пользователя, а не для сотрудника службы безопасности. 5. Примеры областей, для которых нужны политики
Ряд вопросов возникает после того, как вы прочитали в предыдущей главе про необходимость обеспечения той или иной комбинации бизнес-требований для работы в Интернете. Какие программно-аппаратные средства и организационные меры должны быть реализованы, чтобы удовлетворить потребности организации? Каков наш профиль риска? Каковы должны быть наши этические нормы для того, чтобы организация могла решать свои задачи с помощью Интернета? Кто за что должен отвечать? Основа ответов на подобные вопросы - это концептуальная политика безопасности для организации. Следующие разделы содержат фрагменты гипотетических политик безопасности в отношении безопасной работы в Интернете. Эти фрагменты были разработаны на основе анализа основных типов средств безопасности (например, контроля за импортом, шифрования, архитектуры системы). Приводятся обоснования выбора именно таких политик, за которыми следуют сами тексты абзацев политики, выделенные в отдельный абзац с курсивом. Каждая часть содержит несколько политик для использования при различных профилях риска, рассмотренных в главе 3. Для некоторых областей приводится несколько примеров для одного уровня риска, чтобы показать различные способы реализации безопасности. Политики безопасности можно разделить на две категории - технические политики, реализуемые с помощью оборудования и программ, и административные политики - выполняемые людьми, использующими систему и людьми, управляющими ей. 5. 1. Идентификация и аутентификация
Идентификация и аутентификация (ИдиА) - это процесс распознавания и проверки подлинности заявлений о себе пользователей и процессов. ИдиА обычно используется при принятии решения, можно ли разрешить доступ к системным ресурсам пользователю или процессу. Определение того, кто может иметь доступ к тем или иным данным, должно быть составной частью процесса классификации данных, описанной в разделе 5. 6. Эта глава предполагает, что было принято решение о том, что можно устанавливать соединения с внутренними машинами из Интернета. Если такие соединения запрещены, то в ИдиА нет необходимости. Многие организации отделяют системы, доступные из Интернета, от внутренних систем с помощью брандмауэров или маршрутизаторов. Аутентификация через Интернет имеет ряд проблем. Достаточно легко можно перехватить данные идентификации и аутентификации (или вообще любые данные) и повторить их, чтобы выдать себя за пользователя. При аутентификации вообще пользователи часто выражают недовольство ею и часто совершают ошибки, что делает возможным получение данных ИдиА с помощью социальной инженерии. Наличие дополнительной ИдиА при использовании Интернета делает необходимым распространение среди пользователей данных для ИдиА , что будет лишь усложнять им работу. Другой проблемой является возможность вклиниться в сеанс пользователя после выполнения им аутентификации. Существует три основных вида аутентификации - статическая, устойчивая и постоянная. Статическая аутентификация использует пароли и другие технологии, которые могут быть скомпрометированы с помощью повтора этой информации атакующим. Часто эти пароли называются повторно используемыми паролями. Устойчивая аутентификация использует криптографию или другие способы для создания одноразовых паролей, которые используются при проведении сеансов работы. Этот способ может быть скомпрометирован с помощью вставки сообщений атакующим в соединение. Постоянная аутентификация предохраняет от вставки сообщений атакующим. 1. Статическая аутентификация
Статическая аутентификация обеспечивает защиту только от атак, в ходе которых атакующий не может видеть, вставить или изменить информацию, передаваемую между аутентифицируемым и аутентифицирующим в ходе аутентификации и последующего сеанса. В этом случае атакующий может только попытаться определить данные для аутентификации пользователя с помощью инициации процесса аутентификации (что может сделать законный пользователь) и совершения ряда попыток угадать эти данные. Традиционные схемы с использованием паролей обеспечивают такой вид защиты, но сила аутентификации в основном зависит от сложности угадывания паролей и того, насколько хорошо они защищены. 2. Устойчивая аутентификация
Этот класс аутентификации использует динамические данные аутентификации, меняющиеся с каждым сеансом аутентификации. Атакующий, который может перехватить информацию, передаваемую между аутентифицируемым и аутентифицирующим , может попытаться инициировать новый сеанс аутентификации с аутентифицирующим, и повторить записанные им данные аутентификации в надежде замаскироваться под легального пользователя. Усиленная аутентификация 1 уровня защищает от таких атак, так как данные аутентификации, записанные в ходе предыдущего сеанса аутентификации, не смогут быть использованы для аутентификации в последующих сеансах. Тем не менее устойчивая аутентификация не защищает от активных атак, в ходе которых атакующий может изменить данные или команды, передаваемые пользователем серверу после аутентификации. Так как сервер связывает на время сеанса данного аутентифицировавшегося пользователя с данным логическим соединением, он полагает, что именно он является источником всех принятых им команд по этому соединению. Традиционные пароли не смогут обеспечить устойчивую аутентификацию, так как пароль пользователя можно перехватить и использовать в дальнейшем. А одноразовые пароли и электронные подписи могут обеспечить такой уровень защиты 3. Постоянная аутентификация
Этот тип аутентификации обеспечивает защиту от атакующих, которые могут перехватить, изменить и вставить информацию в поток данных, передаваемых между аутентифицирующим и аутентифицируемым даже после аутентификации. Такие атаки обычно называются активными атаками, так как подразумевается, что атакующий может активно воздействовать на соединение между пользователем и сервером. Одним из способов реализации этого является обработка с помощью алгоритма генерации электронных подписей каждого бита данных, посылаемых от пользователя к серверу. Возможны и другие комбинации на основе криптографии, которые могут позволить реализовать данную форму аутентификации, но текущие стратегии используют криптографию для обработки каждого бита данных. Иначе незащищенные части потока данных могут показаться подозрительными. 5. 1. 1. Общие политики аутентификации в Интернете
Хотя пароли легко скомпрометировать, организация может посчитать, что угроза маловероятна, что восстановление после инцидента будет несложным и что инцидент не затронет критические системы (на которых могут иметься другие механизмы защиты) . Низкий риск
Требуется аутентификация для доступа к системам организации из Интернета. Минимальным стандартом для аутентификации является использование паролей, как описано в ***. Средний риск
Доступ к информации класса ХХХ и ее обработка из Интернета (при ее несанкционированной модификации, раскрытии или уничтожении имеет место небольшой ущерб) требует использования паролей, а доступ ко всем остальным видам ресурсов требует использования устойчивой аутентификации. Доступ в режиме telnet к корпоративным ресурсам из Интернета требует использования устойчивой аутентификации. Высокий риск
Доступ из Интернета ко всем системам за брандмауэром требует использования устойчивой аутентификации. Доступ к информации ХХХ и ее обработка (при нарушении ее безопасности организация понесет большой ущерб) требует использования постоянной аутентификации. 5. 1. 2. Политика администрирования паролей
Ниже приведены общие правила работы с паролями, полезные для использования в Интернете: Идентификаторы пользователей и их пароли должны быть уникальными для каждого пользователя. Пароли должны состоять как минимум из 6 символов (не должны быть именами или известными фразами). Должно производиться периодическое тестирование специальными программами на предмет выявления угадываемых паролей (в этих программах должен быть набор правил по генерации угадываемых паролей) . Пароли должны держаться в тайне, то есть не должны сообщаться другим людям, не должны вставляться в тексты программ, и не должны записываться на бумагу. Пароли должны меняться каждый 90 дней(ил через другой период). Большинство систем могут заставить принудительно поменять пароль через определенное время и предотвратить использование того же самого или угадываемого пароля. Бюджеты пользователей должны быть заморожены после 3 неудачных попыток входа в систему. Все случаи неверно введенных паролей должны быть записаны в системный журнал, чтобы потом можно было предпринять действия. Сеансы пользователей с сервером должны блокироваться после 15-минутной неактивности (или другого указанного периода). Для возобновления сеанса должен снова требоваться ввод пароля. При успешном входе в систему должны отображаться дата и время последнего входа в систему. Бюджеты пользователей должны блокироваться после определенного времени неиспользования. Для систем с высоким уровнем риска:
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
