Глава 6
Правила безопасности Internet |
С развитием технологий Internet каждая организация стремится подключить к Internet свои системы и инфраструктуры. Эта книга полезна для тех, чья организация вошла в мир пользователей системы реального времени, и, поэтому, необходимо позаботиться о ее защите от вмешательства извне. Проблема в том, что многие разработчики политики безопасности организации рассматривают правила безопасности Internet как руководство по всеобщей защите сетей организации. Те, кто прочитал предыдущие главы, уже знают, что предпочтительней разрабатывать несколько документов правил, которые охватывают различные аспекты программы защиты информации. Правила безопасности Internet являются всего лишь частью этой программы.
Общепринятая точка зрения на разработку правил безопасности Internet заключается в том, что их довольно легко написать, поскольку об Internet знает каждый. В ряде случаев это действительно так. Тем не менее, поскольку технологии меняются очень быстро, а в некоторых организациях сильна тенденция бросаться внедрять все "сенсационные" открытия, довольно сложно написать правила, охватывающие все нововведения. Несмотря на то, что охватить все аспекты безопасности Internet довольно сложно, можно использовать прагматичный подход, чтобы быть уверенным, что правилами охвачены все необходимые вопросы. Также, как было сделано с политикой безопасности вообще, правила безопасности Internet можно разбить на логические группы в соответствии с различными технологиями Internet. В этой главе описаны логические группы, на которые разбиваются технологии Internet, а также дается объяснение, каким образом технологии отражаются в разрабатываемых правилах.
Подход к Internet |
Логично начинать писать правила, подходя к теме с парадного входа. Ваш подход к Internet может основываться на одной из нескольких технологий и требовать особой конфигурации аппаратных средств. После подключения к Internet этот подход станет основным для всех вспомогательных служб и сделает доступным для внешнего мира некоторые или все сети организации, а также предоставит сотрудникам вашей организации доступ к внешним сетям. Когда автор книги сотрудничал с различными компаниями по разработке правил безопасности Internet, он выделял два основных вопроса в этой работе.
Правила, регламентирующие создание интерфейса с Internet
Каким службам будет дозволено пользоваться этим интерфейсом
Вопросы архитектуры
Правил безопасности интерфейса с Internet может быть разработано столько же, сколько существует различных технологий для подключения организации к миру Internet. Независимо от используемых технологий неизменным остается то, что интерфейсные протоколы не предоставляют никакой защиты. Существуют и дополнительные вопросы, касающиеся протоколов туннелирования, но их мы обсудим позже в разделе "Виртуальные частные сети, экстрасети, интерсети и другие туннели". Целью разработки правил определения архитектуры является обеспечение безопасности интерфейса во время связи через Internet, и, в то же время, чтобы безопасность не являлась препятствием нормальному доступу к Internet.
Одна из проблем, с которыми можно столкнуться при разработке правил работы в Internet для вашей организации, заключается в необходимости учитывать уже существующую архитектуру вместо того, чтобы создать ее по "лучшему образцу". Если вы захотите существенно модернизировать архитектуру, вполне вероятно, что возникнет очень сильное противодействие вашим предложениям. Следует помнить, что правила и процедуры претворения их в жизнь представляют собой эволюционный процесс, и легче достигнуть своей цели путем пошаговых изменений, которые можно было бы предлагать во время каждой очередной модернизации системы.
Правила управления входящим трафиком
Первое, о чем думают люди при обсуждении управления поступающим от Internet информационным потоком, — это брандмауэр. Брандмауэр представляет собой устройство, которое помогает управлять трафиком, обеспечивая реализацию жестких правил, устанавливающих, что допускается к поступлению в сеть и что может выходить из сети. Средствами управления сетевым трафиком являются не только брандмауэры. При разработке правил управления трафиком необходимо учитывать размещение брандмауэра в сети и режим его работы.
Несмотря на то, что существует множество способов сконфигурировать подключение к Internet, я предлагаю любой организации рассмотреть только два типа архитектуры, позволяющих разделить трафик Internet и сеть организации. Они изображены на рис. 6.1 и рис. 6.2. Оба эти метода основываются на создании сегмента сети, который обеспечивает защиту от Internet и является дополнительным элементом защиты сети организации. Архитектура такого типа подразумевает создание так называемой демилитаризованной зоны (DMZ— DeMilitarized Zone) или защищенной локальной сети (LAN — Local Area Network), которая является одним из типов изолированного сегмента сети. На рис. 6.1 изображена общепринятая архитектура, в которой для изоляции сегмента сети создается DMZ с помощью двух брандмауэров. В данной архитектуре брандмауэр Internet используется в качестве фильтра для ограничения трафика из Internet, а внутренний брандмауэр обеспечивает дополнительную защиту локальной сети организации.
Другой способ обезопасить сетевой трафик — создать сегмент DMZ, который направляет трафик Internet в отдельную часть сети (рис. 6.2). Преимуществом такой архитектуры является то, что требуется только один брандмауэр, который направляет трафик так, что он не попадает в сеть организации. Какую бы архитектуру вы ни выбрали, важно создать участок сети, обслуживающий запросы Internet, который защитит внутреннюю сеть организации от нежелательного трафика, но при этом позволяет пользователям организации получать доступ к Internet.
Рис. 6.1. Архитектура сети, в которой DMZ создается с помощью двух брандмауэров, чтобы изолировать системы, обслуживающие пользователей Internet
Рис. 6.2. Архитектура сети, в которой DMZ создается с помощью одного брандмауэра, чтобы создать изолированную сеть, обслуживающую пользователей Internet
Варианты архитектурных решений Вариант с использованием DMZ подразумевает, что в организации имеется своя собственная служба internet, использующая один из типов постоянного подключения. В действительности могут использоваться различные типы вспомогательных систем, для которых должны быть разработаны свои собственные варианты правил. Например, если в вашей организации имеется хост-система, то необязательно разрабатывать правила архитектурных решений. Прежде, чем формулировать правила для конкретной организации, необходимо удостовериться, что они могут быть претворены в жизнь, особенно в том случае, если у вас не получится внедрить архитектурные решения, принятые вашим Internet-провайдером (ISP) (Internet Service Provider — Internet-провайдер, или поставщик услуг Internet).
Защита шлюза
Большинство людей, размышляя о безопасности Internet, концентрируют внимание на брандмауэре. Брандмауэры, независимо от того, являются ли они специализированными устройствами или всего лишь маршрутизаторами отдельных пакетов информации, представляют собой первую линию обороны в системе безопасности Internet. Они размещаются на различных шлюзах сети, чтобы управлять сетевым трафиком. Как уже говорилось в предыдущем разделе, брандмауэры можно использовать для создания сегментов сети, которые будут обеспечивать работу систем открытого доступа и в то же время защищать внутреннюю закрытую сеть организации от пользователей Internet.
Существует тенденция привязывать правила построения брандмауэров к особенностям их функционирования (см. "Типы брандмауэров"). Например, организация, использующая возможности маршрутизатора фильтровать трафик Internet, старается внедрить правила, предписывающие установку фильтрующих брандмауэров. Возможно, это не самый лучший подход к разработке правил, поскольку в этом случае в организации будут вынуждены использовать только определенный вид аппаратных средств. Лучше не поддаваться соблазну создавать правила, привязываясь к определенным аппаратным средствам, а разрабатывать правила, которые будут поддерживать программу безопасности, предусматривающую предоставление определенных услуг (см. "Разрешенные вспомогательные процедуры"). Если проанализировать предоставляемые услуги, можно пересмотреть общий план системы безопасности таким образом, чтобы не быть привязанным к устаревшим аппаратным средствам.
Типы брандмауэров Как правило, брандмауэры выполняют свою работу, следуя определенным правилам или, как говорят, следуя определенной политике; с помощью фильтрации трафика по признаку принадлежности информации определенному источнику или распознаванию адресов отправителя или портов получателя, извлеченных из содержимого пакетов, или же действуя как промежуточное звено, которое обеспечивает более качественное управление некоторыми вспомогательными системами. Очень распространено использование возможностей маршрутизатора, соединяющего организацию с Internet, фильтровать информацию. Фильтрующие брандмауэры устанавливаются для разрешения или ограничения входящего и исходящего трафика сети. Брандмауэры, являющиеся промежуточным звеном, — это системы, которые запускают программы, помогающие пользователю или серверу получить доступ к вспомогательным системам сети. Промежуточные системы обычно используются в том случае, когда брандмауэру необходимо просмотреть данные, передающиеся через Internet, чтобы определить, каким образом их фильтровать. Промежуточные звенья можно также использовать для кэширования часто используемых данных, а также для уменьшения потока данных, посылаемого в Internet. Другой распространенный метод называется проверкой сохраняемых адресов пакетов (stateful packet inspection). Проверка сохраняемых адресов пакетов используется как часть алгоритма фильтрации пакетов за исключением того, что брандмауэр проверяет содержимое пакетов по определенным характеристикам, чтобы предотвратить нанесение ущерба сети искаженными пакетами.
Преобразование сетевых адресов
В главе 5 "Аутентификация и безопасность сети" обсуждалось использование преобразования сетевых адресов (NАТ— Network Address Translation) в качестве инструмента системы безопасности, обеспечивающего сокрытие внутренней структуры сети организации от внешних пользователей. Если организация приняла решение, что NАТ должно стать частью программы информационной безопасности, то можно заново вставить формулировку в правила безопасности Internet, например, такую.
Адреса внутренней сети организации должны оставаться скрытыми. Когда системам необходим доступ к другим сетям, то перед передачей скрытый адрес может быть преобразован в открытый, зарегистрированный адрес.
Разрешенные вспомогательные процедуры
Вместо того, чтобы привязывать разрабатываемые правила к определенным аппаратным средствам или типам брандмауэров, лучше разработать правила, в которых обозначены вспомогательные процедуры, которые разрешены брандмауэрам. Определение в правилах вспомогательных процедур или даже вариантов предполагаемого трафика не ограничивает организацию в выборе решений.
Существует два способа составления правил, определяющих доступные вспомогательные процедуры. Один из них заключается в написании правила, в котором говорится, что вспомогательные процедуры определяются как часть процедур администратора сети, предназначенные для управления брандмауэрами. Такая трактовка правила дает возможность определять в организации вспомогательные процедуры, поддерживающие бизнес-процесс, и которые могут быть при случае пересмотрены внутри организации. Такое правило также позволит организации добавлять при необходимости новые вспомогательные процедуры, не внося изменений в документ правил. Если организация приняла для себя правила такого типа, то можно написать формулировку наподобие следующей.
Вспомогательные процедуры, поддерживаемые шлюзом Internet, должны назначаться комиссией, ответственной за использование необходимых вспомогательных процедур на шлюзе, соответствующих требованиям технологии.
Другой способ определения того, работу каких вспомогательных процедур разрешать на шлюзе, заключается в регламентации их в документе правил. Многие организации предпочитают определять вспомогательные процедуры в правилах, чтобы придать им больший вес. При разработке правил использования специальных вспомогательных процедур необходимо определить назначение вспомогательных систем протоколом, а также, распространяется ли действие правил на входящую информацию (например, поступающую из Internet) или на исходящую (из организации в Internet). В табл. 6.1 приведены общепринятые вспомогательные системы, которые могут быть учтены в правилах.
Таблица 6.1. Вспомогательные системы, рассматриваемые при разработке правил
Вспомогательные системы для работы с входной информацией |
Вспомогательные системы для работы с исходящей информацией |
Типы ICMP |
Службы именования доменов (DNS) |
Службы именования доменов (DNS) |
Отображение |
HTTP/HTTPS |
HTTP/HTTPS |
Time Exceeded In-Transit |
SMTP, POP, IMAP |
SMTP |
Недоступный хост (Host Unreachable) |
FTP |
FTP, NTP |
Необходимое разбиение (Need to frag) |
LDAP |
Telnet/SSH |
|
Виртуальная частная сеть и терминальные системы |
NNTP |
|
Потоковое аудио (Реальное аудио) |
Разработка правил такого типа сводится к тому, что вам необходимо понять вспомогательные процедуры и их воздействие на процессы, прежде чем начинать разбираться, в каком виде они должны быть отражены в правилах. Например, появляется искушение ограничить доступ к процедурам протокола пользовательских дейтаграмм (UDP— User Datagram Protocol) в сети. Многие организации это делают, поскольку UDP является протоколом, не требующим установления соединения, который сложно контролировать и тем более управлять им. Однако, если сервер, обслуживающий службы именования доменов, размещен после брандмауэра, то нужно подкорректировать правила так, чтобы был разрешен доступ пользователям Internet к порту 53 UDP для распознавания адресов имен доменов вашей организации. Формулировка правила может выглядеть следующим образом.
Шлюз Internet должен предотвращать пропуск UDP-пакетов из Internet в сеть организации ЗА ИСКЛЮЧЕНИЕМ UDP-пакетов, запрашивающих общедоступные службы именования доменов, доступных на порте 53.
Отметим, что такая формулировка правил предназначена для "входящих" процедур, поскольку в ней сказано "из Internet в сеть организации". Она не накладывает ограничений на исходящие процедуры. Как правило, в организации стараются не обращать внимание на то, каким образом их пользователи получают доступ к исходящим процедурам. Однако, при такой формулировке правил ответы внешних UDP-систем, направленные пользователям организации, будут блокироваться. Это не всегда плохо, но если работа организации с клиентами зависит от таких служб, как сетевая файловая система (NFS — Network File System), или других служб, обслуживающих сетевые имена, то придется откорректировать правила, чтобы обеспечить работу этих служб.
Для некоторых организаций разрешение исходящих процедур UDP выглядит вполне безобидно. В процессе поисков в Internet можно найти программу, которую следует использовать для замены служб на основе UDP. Но природа UDP. не ориентированная на установление соединения, все еще представляет собой проблему, поскольку реально не существует целостности соединения для защиты передачи информации. У многих таких систем имеются известные уязвимые места, которые представляют угрозу целостности сетевых данных.
Другая проблематичная область политики заключается в разработке правил использования протокола управления сообщениями в сети Internet (ICMP — Internet Control Message Protocol). ICMP используется для передачи сообщений об ошибках между компонентами сети. ICMP передается на уровне IP и используется только между компонентами сети. Можно зафиксировать работу ICMP с помощью программ типа ping и traceroute (или tracert). Однако, эти сообщения об ошибках можно использовать для составления карты сети, определения того, работает ли система и доступна ли она из сети, а также они могут представлять и другие интересные сведения для потенциального взломщика (см. "ICMP-вторжения").
Проблема, связанная с использованием ICMP, заключается в том, что после того, как вы узнали о проблеме, появляется желание написать правило блокирования ICMP на брандмауэре. При осуществлении данного желания теряется возможность получения ICMP-сообщений host unreachable (недоступный хост) и need to frag (необходимо разбиение). Для управления исходящим трафиком организации необходимо иметь возможность получать эти сообщения. Ввиду сложности таких решений рекомендуется не включать эти вопросы в документы, определяющие политику. Однако, если есть желание упомянуть об этом, то можно составить следующую формулировку.
Инструкции для систем, базирующихся на использовании ICMP, должны определять, каким образом можно манипулировать процедурами ICMP для создания злоумышленного трафика, который может пройти незамеченно. В этих инструкциях должны быть учтены типы процедур ICMP, необходимые для управления трафиком между сетью организации и Internet.
ICMP-вторжения Рассмотрение всех проблем, связанных с применением ICMP, выходит за рамки этой книги. Но можно получить информацию об опасностях применения ICMP в книге Стивена Норткатта (Stephen Northcutt) и Джуди Новак (Judy Novak) Network Intrusion Detection: An Analyst's Handbook, Second Edition (New Riders Publishing, 2000, ISBN 0-7357-1008-2). Там же можно найти информацию о технических аспектах обнаружения вторжений.
Сетевые конференции Usenet
Автор всегда избегал обсуждения специфических правил для систем специального назначения. Если они не описывались в других разделах, то всегда возникало сомнение, стоит ли включать их в документы, определяющие политику. Включение этих деталей в документы политики не позволит быстро вносить изменения в систему, необходимые для поддержания соответствующей среды. В большинстве случаев процедуры можно обновить за несколько минут, но изменение и экспертиза правил безопасности потребуют длительного времени.
Однако, для сетевых конференций можно сделать исключение. Созданная в 1979 году студентами-выпускниками университета в Северной Каролине и королевского университета Usenet превратилась из инструмента Internet, предназначенного для распределения информации, в то, чем она является сегодня. Для некоторых из нас, кто пользовался Usenet с самого начала, эта эволюция не является предметом особой гордости. Несмотря на то, что существует множество производственных сетевых конференций, которые предоставляют полезную информацию, Usenet стала катализатором множества проблем, с которыми мы сталкиваемся в Internet.
Usenet не является только службой, относящейся к определенной категории, но именно это больше всего бросается в глаза. Сетевые конференции Usenet требуют от организации поддержки множества ресурсов. Даже если для Usenet выделен отдельный сервер, дисковое пространство, требуемое для поддержки необходимых архивов, может оказаться большим, чем то, с которым оперирует небольшая или средних размеров организация. Так что при анализе информации, которой обмениваются, можно сделать вывод, что для большинства организаций большая часть трафика не обеспечивает функционирование их бизнеса.
После такой информации большинство организаций хотят ввести в правила предписания, запрещающие доступ пользователей к сетевым конференциям Usenet. Однако, полный запрет использования Usenet может лишить организацию доступа к некоторым очень полезным ресурсам. Система информационной безопасности и штат системного администратора могли бы извлечь выгоду из доступа к сетевым конференциям, где могли бы обмениваться информацией с коллегами, а также пользоваться другими ценными источниками.
Найти золотую середину довольно непросто. Если у организации есть желание разрешить доступ пользователям к Usenet, то необходимо прежде оценить свои возможности. Организация может содержать собственный хост или иметь доступ к серверам провайдера услуг, или же использовать внешний сервис так, чтобы трафик Usenet не влиял на сеть организации. В любом случае в правилах должно быть отражено, что приемлемо для использования сетевых конференции Usenet.
В качестве примера предположим, что организация разрешила ограниченный доступ к новостям Usenet без ограничений на то, каким образом будет обеспечен доступ к конференциям. Предписания политики разрешат сетевые конференции, которые будут полезны для бизнеса, а также позволят вносить в любое время поправки в список пользователей, кому предоставляются эти услуги. Можно написать формулировку правил наподобие следующей.
Организация поддерживает ограниченный доступ к сетевым конференциям Usenet. Эта поддержка распространяется на подсписок конференций, которые могут быть использованы для обеспечения деловой деятельности организации. Список конференций, к которым пользователи могут иметь доступ, регламентируется администраторами сети. Этот список может быть изменен только по письменному заявлению. В заявлении должна быть указана причина, по которой деловая деятельность заявителя требует доступа к конференциям. Запросы не будут удовлетворены, если не будет аргументирована производственная необходимость доступа к конференциям. Наблюдательная комиссия периодически корректирует этот список.
И, наконец, если разрешен доступ к новостям Usenet, может возникнуть желание проинструктировать своих пользователей. Так же. как и при работе с электронной почтой и в других сферах деятельности, где пользователи могут не только получать информацию, но и вносить свою лепту, их замечания могут отражаться на имидже организации. В данной книге описываются правила инструктирования тех, кто работает в других областях. Но здесь можно включить общую формулировку.
Пользователи, имеющие доступ к конференциям Usenet, должны пройти предварительный инструктаж и записать, в чем состоит польза от их участия в конференциях Usenet. В инструктаж необходимо включить описание того, каким образом организация предоставляет доступ пользователям к сетевым конференциям. Кроме того, пользователей необходимо проинструктировать об использовании запантентованной в организации информации и интеллектуальной собственности.
Административные обязанности |
После того, как разработаны правила подсоединения к Internet, самое время сконцентрироваться на специфических областях, которые влияют на использование этого подключения. Начнем с правил администрирования. За исключением самых простых правил, о правилах администрирования забывают, поскольку разработчики правил полагают, что все эти вопросы рассматривались в других областях. Это может быть и так, но все же имеет смысл их здесь описать.
Профилактическое обслуживание
Первая обязанность, о которой нужно поговорить, — это профилактическое обслуживание. В правилах должно быть требование к системным администраторам проводить регулярное обслуживание для поддержания порядка в общедоступных данных. Хоть и звучит это довольно обыденно, есть организации, которые не проводят обслуживание Web-серверов, ftp-архивов и других, требующих обслуживания систем. Не выдвигая такого жесткого требования, в некоторых организациях просто игнорируют общедоступные в информационном плане части системы. Друг автора книги работал в компании с небольшим Web-сервером, чья загрузочная область стала местом хранения средств хакеров. Сервер никогда не проверялся, и Web-сервер был взломан для того, чтобы на нем можно было хранить файлы.
Эти проблемы касаются не только организаций, имеющих собственные серверы. Организации, получающие услуги Internet со стороны, должны иметь правила с требованиями о том, чтобы в договоры на услуги были включены соглашения об обслуживании или профилактических работах, которые позволят администраторам организации проводить такой тип обслуживания. В любом случае следует записать в правилах, что обслуживание должно проводиться, но не должно быть записано, как это обслуживание будет проводиться. Это относится к процедурам, а не к правилам.
Соглашения с внешними источниками
Соглашения с внешними источниками представляют собой довольно интересную проблему, поскольку организации вообще могут не управлять серверами. Это также становится проблемой для организаций, которые могут поддерживать собственные серверы, но управление отдельными их функциями передать внешним источникам. В таком случае достаточно иметь инструкции, но в правила следует включить требование того, чтобы обслуживание входило в условия контракта. Некоторые организации используют формулировку правил, подобную следующей.
Администраторы несут ответственность за процедуры обслуживания серверов, предоставляющих информацию или усгуги пользователям Internet. Совместно используемые серверы или принадлежащие внешним провайдерам также должны обслуживаться по инструкциям, согласованным в контрактах на предоставление услуг.
Внедрение
Администраторы также могут нести ответственность за внедрение. Даже в тех организациях, которые содержат собственный штат, ответственный за безопасность, администраторы находятся на передовой линии обороны. Они знают все о системах, сетях, а также им известны нормативы и те недостатки в сети, на которые нужно обратить внимание. Даже в более мелких организациях, где администраторы выполняют всю работу, они все равно находятся на передней линии внедрения. Несмотря на то, что в других правилах должны полностью определяться роли по внедрению, имеет смысл составить правило с формулировкой требований по внедрению наподобие следующей.
Администраторы должны внедрять правила в соответствии с утвержденными инструкциями. Инструкции администрирования должны регламентировать контроль информации, а также защиту информации путем применения соответствующих санкций. Помимо всего прочего в эти инструкции необходимо включить требования по сохранению фактов нарушения служащими дисциплины, а также требование по применению юридических санкций в отношении внешних нарушителей правил безопасности.
Обязанности пользователей |
Правила, устанавливающие обязанности пользователей, служат в организации для того, чтобы пользователи знали, каким образом разрешено им работать в Internet. В некоторых организациях из тех, с которыми сотрудничал автор, данный раздел служил для определения характера и стиля правил, особенно касающихся тех аспектов, которыми больше всего интересуются пользователи.
Обучение
Пользователи могут полагать, что им не нужен инструктаж для получения доступа к Internet, но здесь имеется в виду инструктаж не о том, как им получить доступ в Internet, a об их ответственности за работу в Internet. Организации должны быть осторожными при разрешении какого-то типа трафика, потому что посредством его можно со стороны получить представление об организации. Очень важно, как воспринимается организация внешней средой, и это должно быть поставлено во главу утла в вашей программе обучения.
Все организации могут проводить тот или иной инструктаж. Самые мелкие организации могут использовать простую программу обучения наподобие собеседования, когда кто-нибудь непосредственно беседует с пользователем. Есть такие организации, в которых инструктаж является элементом программы набора новых служащих, а также есть организации, которые составляют в расширенной форме правила безопасности для ознакомления с ними пользователей. Как вы организуете инструктаж, от этого зависит восприятие его пользователями. Но в первую очередь необходимо зафиксировать это в правилах.
Пользователи, имеющие доступ к Internet, должны предварительно пройти программу обучения, где будет разъяснена политика компании в сфере безопасности и ответственность пользователей за представление компании в мировой сети. Пользователи не должны пользоваться Internet до тех пор, пока полностью не пройдут установленную программу обучения.
Понимание возможностей, предоставляемых Internet
Когда автор помогал организациям разрабатывать правила безопасности, он старался удержать их от попыток включить в правила формулировки, которые являются частью программы инструктажа. Одним из таких понятий, которые не должны попасть в правила, является разъяснение того, что значит для организации соблюдение правил безопасности. В организации хотели, чтобы это понятие было записано в правилах, потому что этот документ утверждается высшим руководством. Такую логику, конечно, трудно оспорить.
В процессе тщательного анализа выявляются два пункта, которые должны присутствовать в данном разделе. Во-первых, формулировка должна разъяснять, что, получив доступ к ресурсам Internet, сотрудники для окружающего мира являются уже представителями организации. Независимо от того, приходит запрос с IP-адреса или в письменном виде, трафик пользователей, их слова и действия отражаются на деятельности организации.
Другой вопрос заключается в том, какая информация организации становится доступной при работе пользователей в Internet. В предыдущих главах описывалось, каким образом с помощью протоколов может разглашаться информация о сети организации. Все, что сделано для защиты сети, может стать бесполезным, если пользователь пересылает информацию, которая не должна разглашаться. Кроме того, пользователи вообще должны быть осторожны при распространении информации, причем речь идет не только об информации организации, но и о личной информации.
Эти формулировки правил необязательно конкретизировать, но они должны очень четко разъяснять, какой информацией организация может быть представлена в сети. Ниже представлена формулировка, которая была написана для одной организации.
Пользователи должны помнить, что, поскольку они имеют доступ к ресурсам Internet, они будут представлять организацию через TCP/IP протоколы. Поэтому, пользователям следует получать доступ к ресурсам в соответствии с их должностными инструкциями. Пользователи могут получать доступ к узлам в личных целях, но этот доступ нужно свести к минимуму. Пользователи не должны обращаться к узлам, которые содержат запрещенную, сексуальную и прочую информацию, получение которой противоречит данному и другим правилам, принятым в организации. Работая в онлайновом режиме пользователи должны быть осторожны в вопросах предоставления информации. Им следует помнить, что посланная по электронной почте информация не является приватной, и все, что они отсылают, может быть прочитано по пути прохождения информации. Кроме того, пользователи не должны пересылать никакой информации, которая может нанести ущерб репутации организации или их личной. Конфиденциальная информация, как это сказано и в других правилах, не должна пересылаться без соответствующих мер предосторожности. Пользователям следует принимать такие же меры предосторожности и при пересылке личной информации.
Стоит также отметить формулировку из первого абзаца ограничений. Хотя ограничение доступа к определенным узлам будет описано в этой главе позже, данные формулировки служат в качестве еще одного подтверждения тому, что можно ожидать от пользователей. Остальные формулировки относятся к другим правилам.
Пересылка важной информации
В последнем разделе в правилах говорилось о том, чтобы не пересылать конфиденциальную информацию "без соответствующих мер предосторожности". Определение соответствующих мер предосторожности зависит от того, как составлены правила, и от требований организации. Требования организации зависят от многих факторов, включая договорные обязательства. Например, подрядчики федерального правительства вводят ограничения на информацию, которую могут пересылать, даже внутри своих локальных сетей.
Другой вопрос, на который необходимо обратить внимание, это непреднамеренное раскрытие информации. Пользователи, которые "бегают" по сети, заходят на узлы, на которых для получения информации требуется заполнить онлайновые формы. Эти формы могут запрашивать некоторую информацию. Поэтому, если много людей посетит этот узел, совокупная информация, которую они все вместе дают, может предоставить кому-то сведения об организации.
В идеале, можно написать правило, следуя которому при запросе пользователя группа безопасности организации заполняет онлайновые формы или сама осуществляет онлайновые запросы, полностью контролируя сообщения. Но на деле все происходит иначе. Можно с уверенностью сказать, что если кому-то потребуется отправить официальный документ компании, сомнительный с точки зрения службы безопасности, вряд ли он захочет представить свой запрос на утверждение. Что же касается правил, то в них необходимо внести такую формулировку, которая будет исполняться, и рассчитывать на то, что обучение персонала, наблюдение и контроль за сетью обеспечат неразглашение важной информации.
Некоторые люди видят два пути решения данной проблемы. Наиболее распространенный способ заключается в обновлении учебных программ, в которых предусмотрена более тщательная проработка этих вопросов. Другое популярное правило требует установить фильтры, которые будут просматривать содержание всей корреспонденции, которая отправляется в Internet. В отношении таких фильтров существуют технические проблемы, которые в этой книге не рассматриваются. Но для некоторых организаций решение настоящей задачи является важным делом. Учитывая это, формулировка правил может выглядеть следующим образом.
Пользователи не должны передавать никакой информации, которая раскрывает сведения об интеллектуальной собственности или деловой активности организации. Пользователи не должны преднамеренно пересылать документы или другие данные клиентам или сторонним лицам без соответствующих мер предосторожности. В меры предосторожности, помимо всего прочего, необходимо включитъ шифрование, пересылку по выделенному каналy и санкционирование лица, ответственного за эту информацию.
Надежность загружаемой информации
Из истории известно, что департамент безопасности финансировал исследовательские работы ARPANET (Advanced Research Project Agency network — сеть Агентства перспективных исследовательских разработок) с целью создания способа распределения информации. Открытость ARPANET новым идеям и способность распределять информацию делают эту организацию популярной среди технологов, которые пользуются ее услугами.
С развитием Internet положение не изменилось. Множество узлов Internet хранят миллионы гигабайт программного обеспечения различной степени полезности для каждого. Проблема заключается в том, что существуют узлы, на которых выставлены "более чем опасные" программы, замаскированные под что-то полезное. Среди них попадаются и полезные программы, но содержащие дефекты, которые могут причинить ущерб системе и сети. И, наконец, существуют узлы, которые предлагают программное обеспечение, предназначенное для преднамеренного повреждения системы или сети.
С учетом всего этого существует тенденция разрабатывать правила, запрещающие использование всего загружаемого из Internet программного обеспечения. Однако, если это сделать, то пользователи не смогут загружать последние обновления Web-броузеров. Поиск способа избежать проблем с загружаемым программным обеспечением путем создания действенных правил является, в некотором смысле, вызовом. Можно не хотеть допускать вседозволенность, но и можно было бы написать такую формулировку, которая бы предотвратила проблемы.
Пользователи могут загружать программное обеспечение из Internet, которое поможет им выполнять свои функции в организации. Пользователи, которые загружают программное обеспечение, должны делать это в системе, которая защищена постоянно обновляющимися антивирусными программами. Пользователи не должны отключатъ антивирусное программное обеспечение при запуске загружаемого из Internet в систему пользователя программного обеспечения. Если для инсталляции программного обеспечения необходимо отключить антивирусные программы, то пользователь должен провести полное антивирусное сканирование системы после завершения инсталляции.
Правила работы в сети интернет |
Здесь речь идет о сфере деятельности настолько знакомой, что это приводит к упущениям в правилах. О Web знают все. Каждый использует Web и имеет свой собственный взгляд на правила работы с ней. Web может быть мощным помощником, а также источником проблем. Целью разработки правил работы в Web является обеспечение информационной безопасности организации во время работы в Web и, в то же время, не перегрузить правила ненужными для пользователей и невыполнимыми запретами и ограничениями.
Доступ из Web к сети и инфраструктуре
Основная цель службы информационной безопасности — следить за тем, как организация обслуживает свои Web-серверы и системы, которые обеспечивают работу в Web. Постоянно появляются новые критерии безопасности, новые уязвимые места и хакерские средства. Web-узлы повреждаются, похищается информация, и организация рискует из-за этих инцидентов получить негативное паблисити.
Помимо искажения информации существуют проблемы, связанные с воровством информации наподобие тех, которые случаются с содержимым кредитной карточки. Это говорит о том, что существуют слабые места в обслуживании таких записей или в доступе к инфраструктуре, где хранятся эти записи. Тот, чьи узлы были взломаны, знаком с данными проблемами.
Существует столько же способов зашиты данных и сетевой инфраструктуры организации, сколько вариантов реализации Web. В ракурсе разработки правил довольно сложно предложить формулировку, которая удовлетворяла бы конкретной системе. Однако, если не обращать внимания на особенности реализации, то можно найти что-то общее во всех реализациях и изложить это в правилах.
Например, один из способов защиты данных заключается в установке серверов после внутреннего брандмауэра (см. рис. 6.1) и применении специальных методов обеспечения более качественной связи между системами. Несмотря на то, что детали такой схемы должны быть изложены в инструкциях, в качестве руководства для тех, кто внедряет эту систему, нужно разработать правило. Формулировка правила может быть следующей.
Все системы с собственными и клиентскими данными, которые поддерживают Web-сервер, не должны устанавливаться на том же сегменте сети, на котором установлены Web-серверы. Эти вспомогательные серверы должны устанавливаться таким образом, чтобы доступ был возможен только к Web-серверам. Организации следует установить надлежащие средства контроля для обеспечения гарантий того, что вспомогательные серверы могут быть доступны только таким способом, который согласуется с функциями, на которые они запрограммированы.
Другая проблема заключается в выполнении программ, сценариев или иных вспомогательных процедур на Web-сервере. Некоторые организации не испытывают таких проблем и разрешают запускать сценарии, которые работают как часть общего шлюзового интерфейса сервера (CGI — Common Gateway Interface). В других организациях испытывают беспокойство при разрешении запуска всего, что отличается от тестовых страничек сервера. Необходимо быть очень осторожным при утверждении таких правил, поскольку они будут сильно влиять на архитектуру вспомогательных систем Internet вашей организации. Чрезмерная жесткость правил будет неприемлема для организаций, которые пользуются услугами внешних вспомогательных систем.
На Web-серверах должны запускаться только проверенные программы и сценарии, которые функционируют как часть общего со вспомогательными Web-системами шлюзового интерфейса (CGI). Все другие программы должны выполняться на иных системах, не связанных с Web-системами, на которых эти сценарии работают как посредники для такого выполнения.
Сервлеты, аплеты и динамическое содержание Требования к Web-серверам по выдаче более содержательной информации все увеличиваются: по мере появления новых технологий, создаваемых для распространения этой информации. CGI является всего лишь верхушкой айсберга. В настоящее время, с появлением языка программирования Java, небольшие приложения, называемые аплетами, помогают обеспечить доступ к содержимому на Web-узлах. Но и это не все. Появляются технологии, которые позволяют динамически генерировать содержимое по запросам пользователя. Кроме того, начинают появляться небольшие приложения, размещенные на сервере или сервлеты, а также страницы со встроенными командами, которые выполняются на сервере. Несмотря на то, что эти технологии расширяют возможности Web-серверов, они создают дополнительные проблемы с безопасностью. Во-первых, новые технологии работают в той же системе, что и Web-сервер. Сбои или другие помехи могут вызвать много различных проблем с защитой сервера. Во-вторых, эти размещенные на сервере программы не имеют отдельного интерфейса, безопасность которого можно было бы оговорить в правилах, ограничивающих доступ к вспомогательным системам. Организация должна оценить целесообразность применения таких новшеств в соответствии с создаваемыми ими потенциальными проблемами, а также разработать правила их применения. Конечно, вы можете решить, что модель производственной деятельности вашей организации не может обойтись без их применения. В таком случае необходимо обеспечить разработку таких правил безопасности, которые обеспечивали бы соблюдение норм безопасности теми, кто внедряет вспомогательные системы, обеспечивающие безопасный интерфейс для конфиденциальных данных.
Защита и обслуживание CGI и других сервисных программ
Мы говорим о производительности, которой располагает Web-сервер для пересылки динамической информации через различные интерфейсы. Эти интерфейсы запрограммированы с использованием сценариев, встроенных команд или языков программирования, которые создают определенные проблемы при защите серверов. Наибольшая опасность заключается в том, что в таких программах могут быть случайные ошибки, алгоритмические ошибки или другие проблемы, связанные с языком программирования. Языки сценариев имеют команды, выполняющиеся внешними программами, в которых могут быть свои ошибки, бреши в защите или незадокументированные особенности, которые тоже могут привести к нарушениям безопасности.
В наше время, когда цикл разработки системы происходит в "эпоху Internet", возникает множество неожиданных проблем в программах в связи с тем, что они эксплуатируются пользователями, а поставляются разработчиками. Не вдаваясь в тонкости развития программного обеспечения, правила должны учитывать современную практику с требованиями присутствия программного обеспечения "вчерашнего дня". Эти правила также не должны быть связаны с правилами разработки программного обеспечения.
При разработке правил для этих вспомогательных программ необходимо рассмотреть два аспекта.
Ревизию всего установленного программного обеспечения на предмет возникновения любых потенциальных проблем.
Безопасную эксплуатацию этих средств.
Ревизия программ на предмет выявления ошибок и брешей в защите обычно представляет собой важный этап процесса разработки программного обеспечения, но существует тенденция сдавать в эксплуатацию программное обеспечение, не проведя надлежащего тестирования. Разработав правило, требующее провести такую ревизию, можно надеяться, что разработчики потратят немного дополнительного времени на обеспечение гарантий того, что с этими программами не будет проблем. Формулировка правил может выглядеть следующим образом.
Вспомогательные программы для Web-cepвepoв должны подвергаться тщательной проверке всех компонентов. Во время ревизии проверяются рабочие характеристики этих программ на предмет непредвиденных результатов по причине сбоев в работе. Кроме того, в процессе ревизии необходимо рассмотреть возникшие проблемы безопасности системы и сети.
Теперь необходимо сосредоточиться непосредственно на элементах программного обеспечения. Существуют два аспекта, по поводу которых стоит беспокоиться. Во-первых, если какой-либо элемент программного обеспечения не используется, то он не должен загружаться или нужно выбрать такую конфигурацию, чтобы сервер его не использовал. Другая проблема состоит в том, что когда эти элементы используются, то следует позаботиться о проблемах безопасности, выявленных исследовательскими группами безопасности, поставщиками и взломщиками. Иногда создается впечатление, что предостережения касательно брешей в защите серверов или программ, генерирующих содержимое, появляются сами еженедельно.
Правила в этих областях довольно сложно трактовать. Если ваша организация использует внешние WеЬ-серверы, то определить их потенциальные проблемы довольно сложно. Можно попробовать заключить соглашение при подписании контракта, которое согласовывалось бы с вашими правилами, но все равно это будет намного сложнее, чем если бы ваша организация имела собственные Web-серверы. Ваши администраторы не могут просто проводить новые патчи или менять конфигурацию, так как не могут быть уверены в том, что эти обновления не приведут к неправильной работе или к выходу из строя сервера или программного обеспечения.
Существует слишком много вариантов, поэтому невозможно решить эти проблемы, составив всего лишь одну формулировку правил. В следующем примере из нескольких различных правил извлечены общие положения и составлена одна общая формулировка. Предлагается в вашей организации использовать нижеследующий пример в качестве руководства по разработке собственного правила, а не в качестве образца, который можно вставить в правила.
Web-серверы должны быть установлены и сконфигурированы так, чтобы обеспечить функционирование только тех вспомогательных систем, которые необходимы для поддержки операционной среды. Администраторы должны отслеживать сообщения систем оповещения о нарушениях безопасности на предмет обнаружения уязвимых мест в установленных компонентах системы. Для тестирования и проведения патчей в установленных компонентах системы администраторы должны работать совместно с программистами и ответственными за информацию лицами.
Корректировщики содержимого
Корректировщики содержимого представляют собой языки программирования и языки подготовки сценариев, называемые run anywhere enhancers. Сценарии и аплеты загружаются с сервера для корректировки содержимого при интерактивном взаимодействии с пользователем. Проблема заключается в том, что в броузерах, обеспечивающих соответствующий сервис, найдены уязвимые места в защите. Проблемы приводят к тому, что некоторые организации вынуждены отказаться от использования серверов Internet.
Можно найти технические решения, чтобы программы корректировки содержимого не включать в сеть. К сожалению, пользователи могут и не иметь возможности пользоваться узлами, которые оснащены этими корректировщиками. Несмотря на развитие технологии и уменьшение количества проблем с защитой, организация должна рассмотреть общее влияние на безопасность при включении таких корректировщиков в сеть.
Фильтрующие аплеты Настоящая индустриальная война ведется между Java и ActiveX за право распространения своего программного обеспечения для аплетов, создающих содержимое серверов. Java говорит о безопасности, a ActiveX говорит о том, что может создавать гибкое динамичное содержимое. Несмотря на то, что обе фирмы серьезно озабочены вопросами безопасности, они обе предоставляют провайдерам информации слишком большую гибкость во взаимоотношениях с пользователями. Обе технологии нацелены на поддержку потребителя, создавая чаты, а также проявляя инициативу на рынке электронных услуг. Эти вопросы необходимо рассмотреть до принятия решения, использовать или нет фильтрующие аплеты.
Управление содержимым
В предыдущих главах говорилось о праве на информацию. Концепция заключалась в том, что одно лицо или ведомство назначается ответственным за информацию, относящуюся к определенному бизнес-процессу. Таким образом, создается система защиты данных и устанавливается ответственность за ее целостность и безопасность. В отношении Web-серверов все должно быть точно так же. Даже в том случае, если организация заключает договор о Web-услугах, кто-то из организации должен отвечать за содержимое.
В каждой Web-системе имеется несколько способов управлять содержимым. Поэтому довольно сложно составить правила, в которых в достаточной мере будут учтены все способы управления данными. Проблема заключается в том, что правила должны определять не только ответственных за содержимое, но также и то, каким образом это содержимое изменять и управлять им.
Правило конфиденциальности
Наиболее спорный аспект, касающийся Web-серверов, заключается в том, как распоряжаются информацией ответственные за нее лица после ее получения из соответствующих вспомогательных систем. Эксперты в области безопасности обеспокоены тем, что мы выдаем стишком много личной информации при поисках нужного содержимого и удобства пользования. Создается впечатление, что каждый беспокоится о конфиденциальности и занимается поиском собственников Web-серверов, чтобы продемонстрировать свое добропорядочное гражданство, а также раскрыть, каким образом он использует собираемую информацию. Это раскрытие определяется правилом конфиденциальности.
Следование правилу конфиденциальности несколько отличается от следования правилу раскрытия информации. Правило конфиденциальности представляет собой общедоступную формулировку и разъясняет пользователям, какую личную информацию можно собирать, и как организация собирается распорядиться этими данными. По причине непостоянства правила конфиденциальности не рекомендуется включать его в документы правил информационной безопасности. Однако, необходима рекомендация, как создать документ, доступный каждому для прочтения. Формулировка правила могла бы выглядеть следующим образом.
На Web-cepвepax должно находиться общедоступное правило конфиденциальности, разъясняющее, какую информацию можно собирать, и что организация может делать с этими данными. Правило конфиденциальности должно быть общедоступным на основе подключения к обслуживаемым, страницам.
Доступ пользователей к Web
Правило номер один при создании правил доступа пользователей заключается в том, что пользователям доверять нельзя. Других правил, собственно, и не существует. При отсутствии правил и ограничивающих инструкций организации столкнутся с большими сложностями, потому что пользователи будут посещать любой сайт, загружать любые программы, будут иметь доступ к аплетам и заполнять любую форму, какую пожелают.
Во многих организациях принято работать по правилам, которые включают фильтрацию содержимого. Фильтры содержимого обычно не допускают посещения пользователями сайтов, которые компания считает незаконными или, в каком-то смысле, аморальными. Кроме того, они предоставляют кэши содержимого на шлюзах Internet, чтобы ускорить загрузку информации. Другие возможные фильтры содержимого могут не допускать использование аплетов корректировки содержимого.
Независимо от сферы деятельности организации правила должны четко разъяснять, каким образом управлять трафиком в Internet. Пользователям необходимо давать разъяснения скорее с точки зрения законности действий, чем с каких-то других. Нужно сказать о том, что организация контролирует трафик или может даже проводить аудит, чтобы определить, какая информация передается через интерфейс Internet. Если не сообщить об этом, а также не предупредить о дисциплинарных взысканиях, утвержденных правилами, то организация может оказаться втянутой в судебные процессы, инициированные служащими. Ниже следует примерная формулировка правил.
Пользователи, имеющие доступ к Internet, не должны посещать сайты, которые созданы с нарушениями закона или содержат оскорбительную информацию о пользователях. Организация должна сохранить за собой право блокирования доступа ко всем сайтам, которые считаются неприемлемьми, а также делать регистрационные записи о посещении сайтов всеми пользователями, на основании которых в любое время можно провести аудиторскую проверку. В качестве этапа процесса фильтрации содержимого организации должно быть разрешено установить систему кэширования.
Когда автор книги помогал одной организации, являющейся провайдером внешних услуг, разрабатывать правила безопасности, ее представители выразили беспокойство, не будут ли правила ограничивать их пользователей в создании Web-страниц. Они утверждали, что это является расширением их творческой активности, и, по этой причине, не хотели останавливать такую практику. У автора книги данная, так называемая, практика вызвала некоторые подозрения. Почему провайдеры были так уверены, что кто-то не злоупотребляет своими привилегиями?
Позже автор начал исследовать сеть организации извне. Во-первых, используя некоторые стандартные средства, удалось обнаружить все серверы, обслуживающие WеЬ-системы. В результате тестирования были обнаружены серверы на нестандартных портах. На основе этой информации были преобразованы адреса поиска, чтобы установить, какому имени какой адрес соответствует. Обнаружилось, что один из адресов имеет резервное имя, зарегистрированное в InterNIC (Internet Network Information Center— информационный центр сети Internet). Используя новое имя и броузер, автор получил доступ к сайту. То, что удалось обнаружить на этом сайте, шокировало людей, с которыми он сотрудничал. Информация совершенно не соответствовала целям организации и могла считаться запрещенной.
Поскольку мы пребывали только на этапе разработки правил, не было никакой возможности наложить дисциплинарное взыскание на конкретного служащего. Конечно, можно было бы применить некоторые санкции, но не столь серьезные, как хотелось бы. Это подтолкнуло к разработке правила, которое выглядит так.
Служащим организации нужно разрешить создавать неофициальные сайты в сети организации. Эти Web-сайты должны быть доступны только внутри организации. Пользователи, которые хотят, чтобы содержимое их сайтов было доступно из Internet, должны, прежде чем сделать свои страницы доступными, предоставить их для просмотра комиссии, возглавленной арт-директором. Арт-директор должен использовать правила в качестве руководства, по которому производится ревизия сайта, он также отвечает за решения об отказе в праве доступа к сайту или разрешении.
Это правило было сформулировано для организации, в которой насчитывалось меньше 75 пользователей, чьи Web-серверы размещены у ближайшего провайдера услуг. Внедрение данного правила в дальнейшем избавило организацию от проблем с генерируемым пользователями содержимым.
Ответственность за приложения |
По большей части, ответственные за данные и процессы лица не столь осведомлены в тонкостях технологии, как программисты или администраторы. Даже те, кто начал свою карьеру как "технарь", сейчас обнаруживают себя во власти приложений, которые развертывают и с которыми работают в системе информационной безопасности организации.
Правила работы в Internet, касающиеся приложений, должны касаться только защиты данных и пересылки файлов, а также аутентификации во время этих пересылок. Прочие аспекты безопасности приложений следует включить в правила, относящиеся к другим сферам деятельности, таким как разработка программного обеспечения организации собственными силами (см. главу 10 "Правила разработки программного обеспечения"). Если не усложнять эти вопросы, то можно будет сфокусировать свое внимание в пределах сферы своих интересов.
Пересылка данных и файлов
Каждый протокол обеспечивает определенный способ пересылки данных между пользователями с различной степенью защищенности. Несмотря на то, что все протоколы служат всего лишь для пересылки данных, некоторые протоколы не гарантируют, что данные дойдут по назначению. Мы используем их для того, чтобы быть уверенными в достоверности пересылаемых данных. На самом деле, это вовсе не так. Надежное завершение передачи данных и файлов зависит от протоколов верхних уровней, взаимодействия программ, а также вмешательства людей.
Ситуация с безопасностью усложняется еще и тем, что есть вероятность, что кто-нибудь (человек или программа) может перехватить пересылаемую в Internet информацию и прочитать ее. Данные организации могут быть считаны любым, кто имеет доступ к инфраструктуре Internet во время передачи. Обычно его называют человеком в центре атаки.
Прочитав последние два абзаца, кто-нибудь, возможно, задастся вопросом: "А где здесь, собственно, говорится о правилах безопасности?" Суть заключается не в создании правил, регламентирующих защиту. Правила должны рекомендовать ответственным за информацию осознать, какую роль играют приложения при пересылке файлов, а также обеспечить защиту этих данных. Это довольно просто сделать, написав формулировку правил, подобную следующей.
Ответственные за информацию и процессы лица должны оценивать все приложения с точки зрения того, обеспечивается ли безопасность пересылки данных и файлов в соответствии с требованиями, выдвигаемыми бизнесом. Помимо всего прочего, в защиту пересылаемых данных необходимо включить обеспечение гарантий, что данные доходят по назначению и не могут никем быть считаны в процессе их пересылки.
Эта формулировка правил написана в самом обобщенном виде и подразумевает применение для обеспечения безопасности пересылки только шифрования. Тем не менее, этого вполне достаточно, чтобы ответственные за развертывание приложений и за распространение данных организации лица учитывали последствия от принятых ими решений.
Аутентификация транзакций Internet
С нарастанием популярности Web-технологий мы сталкиваемся со старыми проблемами в новой форме. При предоставлении услуг посредством Web используется модель, в которой применяется так называемый обмен блоками (block mode transfer). Широко применяемый в старых вычислительных системах обмен блоками функционирует следующим образом: пакуется блок данных с экрана, передается на удаленную систему, а затем блок данных принимается взамен. Однако, в среде Web соединение между сервером и клиентом прерывается после завершения передачи данных.
Аутентификация представляет собой идентификацию пользователя в системе, на сервере или в программном обеспечении, разрешающую ему использовать эти средства. Аутентификация осуществляется многими способами, но общепринято требовать, чтобы пользователь вводил идентификационные данные и пароль. Сущность блочной передачи данных при работе в Web представляет интересные проблемы не только в отношении аутентификации транзакций, но и при создании среды, где пользователь не должен каждый раз идентифицироваться при подключении к серверу.
В правилах аутентификации должно быть записано, что ответственные за данные и процессы лица обеспечивают определение личности тех, кто обращается к данным. Речь идет не только о пользователях Internet, но и о партнерах, которые могут иметь доступ через виртуальные частные сети. В правилах также должны быть учтены все транзакции Internet, включая пересылки Web, подключения к базам данных и терминальным службам. Типичная формулировка правил выглядит следующим образом.
Ответственные за данные и процессы лица должны гарантировать, что реквизиты всех пользователей патентованных данных проверяются и принадлежат этим пользователям. Ответственные за данные и процессы лица должны разработать процедуры подтверждения и отмены права на выполнение этих операций.
Виртуальные частные сети, экстрасети, внутренние сети и другие туннели |
В результате расширения Internet, а также Internet-технологий появились новые возможности расширения сетевой инфраструктуры организации за счет подключения удаленных офисов, покупателей и даже для связи служащих друг с другом через общедоступные сети. Мы осуществляем эти дополнительные услуги путем создания туннеля между локальной сетью и удаленным узлом.
В сетевой терминологии туннель использует Internet в качестве отдельной частной защищенной сети, определяемой возможным прохождением трафика. Обычно, для предотвращения прослушивания, эти туннели шифруются, но шифрование не является обязательным требованием. В конце концов, протокол двухточечной связи РРР (point-to-point protocol) является протоколом туннелирования. Однако, если организации собираются расширить свои сети на множество офисов или для предоставления доступа клиентам, то шифрование предназначается для создания виртуальных частных сетей (VPN — Virtual Private Network).
Туннелирование нужно не всем организациям. Если же организации это необходимо, то можно написать очень простую формулировку правил, в которой будут определены основы того, что хочет использовать данная организация. Формулировка может быть следующей.
Администраторы данных и процессов, которые используют туннелирование, должны гарантировать, что, применяя шифрование, пересылаемая информация не будет прочитана нигде, кроме удаленной системы.
Модемы и прочие лазейки |
Еще один способ расширить доступ к своим сетям заключается в использовании модемов. Некоторые организации эксплуатируют модемные накопители, управляемые отдельными серверами, которые защищают и поддерживают соединения с внешними пользователями. Другие устанавливают модемы на специальных серверах, которые предоставляют доступ минимальному количеству пользователей. Независимо от применяемого метода, общим является то, что администраторы контролируют модемный доступ централизовано.
Профессионалы в области безопасности считают, что централизованное управление модемами является ключевым моментом в управлении устройствами, обеспечивающими временный доступ. Таким образом, они могут контролировать и управлять процессом, не прерывая предоставление услуг. Чего они не желают позволить, так это установки модемов в разных местах сети. Модем, установленный в системе пользователя, которая сконфигурирована для ответов на входящие звонки, является потенциальной точкой доступа для тех. кто хочет взломать сеть.
Пользователи часто подмечают, что они могут установить модемы в своих системах, в которых работают программы, которые могут обеспечить удаленный доступ к их файлам. Эти программы представляют хорошо известные проблемы для информационной защиты, позволяющие любому, кто подключается к модему, получить доступ в систему и к сети, к которой эта система подключена. Более того, поскольку эти модемы не контролируются, администраторы никогда не смогут остановить взломщика до нанесения ущерба.
Помимо атак на отказы в обслуживании (denial of service attacks) существует проблема, которая может вынудить администраторов не спать по ночам - это модем, установленный в сети, которая неправильно сконфигурирована. Если требуется пользователям разрешение для подключения к сети, то администраторы предпочтут иметь правила, позволяющие им управлять доступом. Они потребуют внести в правила запрет на установку модемов без их разрешения. В таком случае в правила можно включить следующее предложение.
Пользователи не должны устанавливать модемы в своих системах или в любом месте сети без соответствующих санкций.
Отметим, что эта формулировка допускает исключения, но они должны быть санкционированы. В данных правилах не уточняется, что представляют собой "соответствующие санкции". Остается руководствоваться принятыми в организации инструкциями по проведению контроля (см. главу 3 "Обязанности в области информационной безопасности").
Не каждой организации нужен модемный доступ к сети. Некоторые организации могут установить всего несколько модемов и разработать правила, обеспечивающие требуемую конфигурацию и соответствие стандартам безопасности. Другие организации поддерживают большое количество модемов, позволяющих пользователям наборный доступ, соединение с сервером и аутентификацию непосредственно в сети. Независимо от требований организации правила безопасности должны поддерживать роль администраторов в контролировании и обслуживании вспомогательных систем.
Если в организации используется модемный накопитель, подключенный к централизованно управляемому серверу, который обеспечивает строгую аутентификацию, формулировка правил может быть следующей.
Системы коммутации должны устанавливаться и управляться системными администраторами. Пользователи, желающие получитъ доступ в сеть посредством модема, должны при подключении проходить аутентификацию. В эту аутентификацию необходимо включитъ компонент безотказности.
В формулировке не указывается, насколько строгим должен быть подход к аутентификации. Вводя лишь "компонент безотказности", вы не связываете внедрение аутентификации только с одним ее типом. Это предполагает, что будет использован некий строгий алгоритм привязки процесса к определенному пользователю. Он может быть каким угодно, начиная с алгоритма PKI и заканчивая аутентификацией с использованием устройств идентификации. Гибкость заключается также в том, что когда биометрия станет доступным средством, то может быть использована технология на ее основе, и не будет необходимости изменять правила.
Применение PKI и других средств контроля |
Может быть, читатель слышал об инфраструктуре открытого ключа (PKI— public key infrastructure), которую называют "чашей Грааля" в идентификации и аутентификации пользователей. В PKI используются технологии криптографии с открытым ключом для аутентификации пользователей и защищенного обмена данными. В PKI используются цифровые сертификаты для идентификации пользователей, предъявляющих такие сертификаты.
Что такое криптография с открытым ключом? Криптография является наукой, разрабатывающей алгоритмы, использующие зашифрованные данные для хранения или пересылки информации. В шифровании эти алгоритмы используются для преобразования данных в непонятную форму. Выражаясь общими терминами, в шифровании используется секретный ключ, то есть секретные величины для выполнения математических действий с данными, чтобы сделать их непонятными для постороннего наблюдателя. По традиции, для шифрования и дешифрования данных требуется один и тот же ключ. Этот метод называется симметричным шифрованием. Криптография с открытым ключом отличается только тем, что математические функции могут использовать два различных, но математически связанных ключа. С помощью математических функций генерируется два ключа: один хранится в секрете, а другой может передаваться открыто. Если кто-то захочет отправить вам зашифрованный файл, он зашифрует его с помощью вашего открытого ключа. Для дешифрования сообщения нужно использовать только свой секретный ключ. Этот метод называется асимметричным шифрованием.
PKI использует криптографию с открытым ключом, используя цифровые сертификаты, которые создаются для подключения секретного ключа. Секретный ключ может быть сверен только вместе с открытым ключом.
Создать сетевые компоненты проверки РК1 довольно непросто. Существует множество коммерческих пакетов, которые могут помочь в этом, но ни один из них не обеспечивает целостный процесс. Кроме того, для работы с PKI нет единого стандарта.
В настоящее время наиболее распространенный способ использования компонентов PKI основан на электронных коммерческих инициативах, доступных через броузеры. Поскольку при этом не рассматривается "реальное" PKI, мы не учитываем такой способ при разработке правил работы с PKI.
Так как стандарты для PKI и технологии постоянно меняются, довольно сложно разработать единое правило, касающееся PKI. Если организация развертывает PKI, то рекомендуется писать отдельный документ правил и процедур PKI. Это позволит учесть то, что может оказаться полезным для программы безопасности организации.
Тем. кто хочет больше узнать о PKI, рекомендуем найти книгу Understanding PKI, написанную Карлайлом Адамсом (Carlisle Adams) и Стивом Ллойдом (Steve Llovd) (Macmillan Technical Publishing, 1999. ISBN: 1-57870-166-X).
Электронная торговля |
При бурном развитии Internet наиболее распространенной формой электронной торговли стала покупка и продажа товаров через Internet. Однако, задумывался ли читатель о правилах и практических шагах, которые необходимы для обеспечения безопасности систем электронной торговли? Проблема многих организаций состоит в том, что, желая как можно быстрее установить узел электронной торговли, они не включают в свою стратегию вопросы обеспечения безопасности этих процессов. Поэтому правила и технология могут не соответствовать планам электронной торговли.
Электронная торговля до Internet До Internet в бизнесе проводились поиски способов автоматизации закупки товаров и услуг. Раньше такие службы, как CompuServe, предлагали потребителям способы проведения торговых операций в онлайновом режиме, поскольку для заключения соглашений и сделок был создан электронный обмен данными (EDI — electronic data interchange). Несмотря на существование и этих и других форм электронной торговли, мы будем концентрировать свое внимание на тех формах, которые используются в настоящее время в Internet. Их можно применить также в качестве образца при разработке правил для других форм электронной торговли.
Сведения о проблемах регулярно документируются в серийно выпускаемых изданиях. Истории о похищении кредитных карточек, переводе денег на офшорные счета или даже похищение товаров и услуг являются всего лишь частью проблем. Руководство организации может прочитать эти истории и ужаснуться: а сможет ли оно справиться с этими проблемами!
В последнее время, когда пришлось помочь одной организации в разработке правил электронной торговли, мы приняли решение, что наилучшим подходом будет создание отдельного документа правил и руководств. У этой организации были те же проблемы, что и у других: они усиленно инициировали введение электронной торговли и игнорировали необходимые меры защиты. Фактически, в то время, пока мы разрабатывали эти правила, группа разработчиков системы электронной торговли руководствовалась правилами, в которых предлагалось разработать план модернизации их служб, чтобы привести их в соответствие с требованиями безопасности, записанными в старых правилах.
Независимо от выбранного подхода к правилам электронной торговли существует несколько принципов, которые необходимо рассмотреть.
Хранение данных. Это касается не только того, где хранить информацию о кредитной карточке, но и где держать каталог, ценники и другую важную информацию. Можно ли размещать ее позади брандмауэра? Можно ли разместить ее в защищенной системе? Можно ли получать доступ к этой информации через защищенные (зашифрованные) каналы? До разработки правил необходимо ответить на все указанные вопросы.
Идентификация и аутентификация. Для каждого приложения электронной торговли существует отдельный метод идентификации пользователя и его полномочий по использованию приложения. Предпочтительней рассматривать, какие методы более всего соответствуют технологической модели вашей организации, а не лучшим известным образцам технологии.
Защита пересылки данных. Обычно защита сделок в электронной торговле подразумевает установку мощного Web-узла или коммуникаций, базирующихся на протоколе безопасных соединений (SSL— Secure Sockets Layer). Если вы придерживаетесь такой идеи, то стоит ли использовать системы строгого шифрования или все же позволить узлу подключаться к броузерам, которые понимают шифрование, называемое "экспорт силы" ("export strength"), которое не такое уж строгое? Собирается ли организация приобретать собственный цифровой сертификат? Будет ли организация позволять пользователям подключаться к узлу и использовать временные сертификаты, которые подходят для универсальных приложений, или же она будет требовать, чтобы клиент подключался со своим собственным сертификатом?
Обработка заказа. Где будет происходить обработка заказа? Может быть, на Web-сервере? После брандмауэра? Или на отдельном сервере? А как насчет обработки платежей по кредитной карточке? Будут ли они выполняться через Internet? Или подключение будет проходить через виртуальные частные сети на сервер центра обмена информацией? Решение этих проблем окажет большое влияние на архитектуру серверов электронной торговли.
Если организация при ведении электронной торговли пользуется внешними источниками, то управление узлом будет не столь сложным, как это предлагается выше в списке. Однако, для обеспечения защиты своего сервиса можно работать с провайдером услуг. Необходимо проверить соглашение между организацией и провайдером услуг. В нем должно быть предусмотрено, что вы имеете право проводить аудит этого узла, чтобы убедиться в надлежащей защите сервера, работающего с вашей организацией.
Резюме |
Правила безопасности Internet довольно сложно разрабатывать из-за быстрого изменения технологий. Вместо того, чтобы разрабатывать одно общее правило, разработчик может подойти к разработке правил безопасности Internet, разбив известные технологии на логические группы и создавая правило для каждой области применения.