- •Информационная безопасность.
- •Определение безопасности как процесса.
- •Категории атак.
- •Атаки хакеров.
- •Конфиденциальность.
- •Идентифицируемость.
- •Необходимость и важность политики.
- •Информационная политика.
- •Политика безопасности.
- •Процедуры управления пользователями.
- •Межсетевые экраны.
- •Межсетевые экраны прикладного уровня.
- •Межсетевые экраны с пакетной фильтрацией.
- •Гибридные межсетевые экраны.
- •Ответные действия ids (03.10.11)
- •Понятие трансляции сетевых адресов
- •Что такое трансляция сетевых адресов?
- •Примечание
- •Частные адреса
- •Примечание
- •Статическая nat
- •Динамическая nat
- •Трансляция сетевых адресов
- •Вопросы безопасности беспроводных соединений:
- •Какие службы следует предоставлять
- •Примечание
- •Шифрованная электронная почта
- •Примечание
- •Интернет
- •Внутренний доступ в интернет
- •Примечание
- •Внешний доступ к внутренним системам
- •Внимание!
- •Службы контроля
- •Примечание
- •Какие службы не следует предоставлять
- •Разработка архитектуры соединений
- •Доступ через один канал
- •Многоканальный доступ к одному провайдеру
- •Доступ с одной точкой присутствия
- •Доступ с несколькими точками присутствия
- •Вопрос к эксперту
- •Многоканальный доступ к нескольким провайдерам
- •Выбор провайдеров
- •Примечание
- •Адресация
- •Вопросы для самопроверки
- •Проектирование демилитаризованной зоны
- •Определение демилитаризованной зоны
- •Системы, размещаемые в dmz
- •Примечание
- •Примечание
- •Системы, доступные из внешней среды
- •Системы контроля
- •Подходящие архитектуры dmz
- •Примечание
- •Маршрутизатор и межсетевой экран
- •Один межсетевой экран
- •Два межсетевых экрана
- •Примечание
- •Разработка партнерских сетей
- •Работа с партнерскими сетями
- •Настройка
- •Службы электронной коммерции
- •Различия между службами электронной коммерции и обычными службами dmz
- •Примеры служб электронной коммерции
- •Продажа товаров
- •Предоставление конфиденциальной информации
- •Важность доступности
- •Вопросы взаимоотношений "компания-клиент"
- •"Компания-компания"
- •Примечание
- •Всемирное время
- •Удобство клиента
- •Убытки вследствие простоя
- •Решение проблемы доступности
- •Реализация безопасности клиентской стороны
- •Безопасность соединений
- •Хранение информации на компьютере клиента
- •Вопрос к эксперту
- •Отказ от выполненной операции
- •Вопросы для самопроверки
- •Реализация безопасности серверной части
- •Информация, хранимая на сервере
- •Защита сервера от атак
- •Расположение сервера
- •Примечание
- •Конфигурация операционной системы
- •Конфигурация веб-сервера
- •Реализация безопасности приложений
- •Правила разработки приложения
- •Правильные методы программирования
- •Общедоступность исходного кода
- •Управление конфигурацией
- •Примечание
- •Реализация безопасности сервера базы данных
- •Расположение базы данных
- •Примечание
- •Соединение с сервером электронной коммерции
- •Защита внутреннего доступа
- •Примечание
- •Разработка архитектуры электронной коммерции
- •Расположение сервера и соединения
- •Примечание
- •Сканирование уязвимостей
- •Данные аудита и обнаружение проблем
- •Разработка архитектуры сайта электронной коммерции
- •Практика
Реализация безопасности приложений
Безопасность приложения электронной коммерции является, возможно, наиболее важным компонентом системы безопасности. Приложение предусматривает процедуры по проведению операций, таких как изменение страниц и обновление программного обеспечения.
Правила разработки приложения
Начнем обсуждение безопасности приложения с разработки самого приложения. При разработке приложения электронной коммерции организация должна выполнить те же шаги проектирования, что и при разработке любой крупномасштабной и комплексной системы, а именно:
определение требований;
системное проектирование;
разработка;
тестирование;
реализация
Все эти шаги должны быть изложены в руководстве по разработке, имеющемся в организации.
Требования безопасности следует включить в этап определения требований проекта. Эти требования включают в себя следующее:
определение секретной информации;
защита требований для секретной информации;
требования аутентификации для доступа или выполнения операций;
требования к аудиту;
требования доступности.
Если эти требования определены, то при проектировании системы можно будет выявить потенциальные проблемы. Вся секретная информация должна определенным образом защищаться. Это обуславливает наличие компонентов приложения, требующих HTTPS вместо HTTP. Для секретной информации требуется не только шифрования при передаче. Некоторые данные, например частные сведения о клиенте, требуют защиты при записи на компьютер клиента в элементах сookie. При проектировании необходимо принимать это в расчет, и в данном случае использовать шифрование элементов cookie.
Необходимо также упомянуть еще один вопрос, связанный с секретной информацией. Информация может стать секретной из-за метода, посредством которого она используется в приложении. Например, некоторые приложения передают информацию между программами с использованием URL (универсального указателя ресурсов, представляющего собой адрес веб-сайта в адресной строке браузера). Если отображается длинный URL со знаком вопроса "?", отделяющим различные значения, то приложение передает параметры другим сценариям или программам. Клиент может поменять эти параметры и изменить функционирование программ. Некоторые сайты электронной коммерции записывают выбранные покупателями товары в адресах URL. Эта информация содержит код товара, количество и стоимость. Если бы в базе данных не осуществляется проверка данных, клиенты могут изменять цену товаров. Был случай, когда клиент заметно уменьшил цену, и организация фактически продала товар по очень низкой цене. Принимая во внимание этот пример, становится ясно, что стоимость товаров является очень важной информацией. Если для передачи этой информации между сценариями или программами используется URL, значения стоимости (по крайней мере) должны проверяться в базе данных перед обработкой заказа.
В информационных системах может храниться такая секретная информация, как номера кредитных карт. Как уже говорилось ранее, ни в коем случае не рекомендуется хранить столь значимую информацию на самом веб-сервере. При проектировании системы необходимо разработать механизм отдельного сохранения этой информации: либо сохранять эти данные на сервере базы данных, либо удалять их после использования. При принятии решения о том, сохранять или не сохранять информацию о кредитных картах, следует руководствоваться мнением на этот счет клиентов компании. Некоторые специалисты по маркетингу говорят, что клиент предпочитает, чтобы процедуры электронной коммерции были как можно более простыми и быстрыми, и что повторный ввод номеров кредитных карт может заставить клиентов обратиться к другому сайту. По этой причине данный аспект превращается в требование. Если так и есть, номера кредитных карт должны сохраняться в том месте, в котором риск успешного проведения атаки невелик.
Организация может предотвратить данную проблему посредством привлечения внешней партнерской организации для обработки транзакций с кредитными картами. При этом информация о покупке должна передаваться партнеру. Необходимо тщательно обеспечить корректность передачи информации.