Аутентификация и безопасность сети
Безопасность сети охватывает не только Internet, но и любое сетевое подключение или интерфейс. Насколько строго обеспечивается защита любых интерфейсов, зависит от требований, предъявляемых к ним, их функционального назначения и степени доверия между обеими сторонами подсоединения. Правила защиты всей сети и внутрисетевых подключений являются частью программы безопасности сети, которая охватывает такие вопросы, как адресация сети, подсети и средства управления подключениями к сети.
Доверительные взаимоотношения устанавливаются путем четкого определения того, какую информацию можно передавать через внутренние соединения. Что касается доступа к информационным ресурсам, то стержнем проблемы управления доступом является обеспечение доступа к системе и ко всей сети. Аутентификация используется для подтверждения этого права доступа. В данной главе обсуждаются вопросы, как формировать политику, которая бы рассматривала архитектуру сети в качестве механизма защиты. Мы обсудим различные аспекты аутентификации и управления доступом к сети, а также все, что необходимо для защиты удаленных точек доступа.
Адресация сети и архитектура
Довольно сложно понять, как можно использовать в программе безопасности сетевую архитектуру и схемы адресации. Стедует помнить, что целью обеспечения живучести сети является обеспечение передачи информации даже в случае сбоев, атак и других происшествий. Правильно выбранная сетевая адресация и архитектура сети поможет в достижении этих целей с помощью правил, требующих тщательного планирования, и особого внимания к элементам адресации сети, а также к возможности расширения сети.
Планирование сети
Уровень планирования сети зависит от размера организации. Организация с небольшим количеством узлов может работать в объединенной сети с простыми сетевыми технологиями. Они основываются на доверительных отношениях, базирующихся на непосредственных контактах. Однако даже небольшим организациям имеет смысл использовать архитектуру сети, базирующуюся на управлении доступом.
Другой подход к этому вопросу называется "управлением трафиком". Сетевые планировщики могут помочь в ограничении доступа к секретным и важным данным, изолируя системы поддержки и сети от основного сетевого трафика. Для этого существует множество технологий, в том числе ограничительные шлюзы, брандмауэры и воздушные зазоры (air gaps). Тем не менее, независимо от используемой технологии, можно разработать правила, предписания которых будут гарантировать, что в планировании сети будет рассматриваться использование архитектуры в качестве механизма защиты информации.
Например, можно строить политику безопасности, используя определенную архитектуру сети в небольшой компании, в которой меньше 50 пользователей, очень немногочисленный персонал и маленький отдел бухгалтерии. Системы в таких компаниях содержат важную информацию, которая, по крайней мере, в отношении трудовых ресурсов, должна быть защищена законом. Изначально администраторы размещали такие системы в сети и полагались на создание подсети, используя адреса и сетевые маски. Входящий и исходящий трафик связывал такие системы с единой сетью, в которой были расположены другие системы офиса. Компания хочет обеспечить более высокий уровень управления потоками информации между этими системами. Это решается путем отделения административных систем от остальных систем организации и использования шлюза для управления трафиком. На рис. 5.1 изображена сеть и предлагаемые изменения в ней. Чтобы они были осуществлены, необходимо дополнить правила безопасности формулировкой, наподобие следующей:
Отдел кадров, бухгалтерия и другие административные системы должны быть физически отделены от основной сети, чтобы таким образом управлять входящими и исходящими потоками информации в этих системах.
Рис. 5.1. Сеть, включающая подсети, реконфигурированная для отделения административных систем. Обратите внимание, что реконфигурированная сеть не требует специфических адресов
Отметим, что в формулировке правил ничего не говорится о том, каким образом должно быть осуществлено это отделение. Это позволяет использовать новые технологии или оригинальные подходы без необходимости изменений в документах политики. Кроме того, ничего не говорится о том, каким образом будет осуществляться управление информацией. Автор в практической своей работе столкнулся со случаями, когда некоторые люди предлагали составить формулировку правил, которая устанавливала бы определенные требования к типу фильтрации или маршрутизации. Не стоит вводить такие требования, поскольку они могут измениться вместе с технологией, и придется обновлять документы политики.
Адресация сети
Никаких магических формул использования адресации сети для зашиты информации нет. Существует определенная защита, которая скрывает или маскирует адреса сети. Одним из ключевых элементов информации, который могут использовать для определения слабых мест сети, является доступ к списку задействованных адресов. Задействованные адреса могут существенно облегчить задачу по выяснению того, какие системы могут быть активными и подходящими для атаки. Существует два способа решения этой проблемы: конфигурация службы именования доменов и преобразование адресов сети.
Конфигурация службы именования доменов
Служба имен доменов (DNS— Domain Name Service) используется для преобразования системных имен в цифровые адреса. Ее также можно использовать для обратного преобразования цифровых адресов в системные имена. Тот, кто сумеет узнать имена или адреса, сможет использовать DNS для преобразования их во что-то более понятное. Несмотря на то, что многие люди представляют себе это как довольно неопасную форму атаки, однако имена могут дать атакующему огромное количество информации. Например, если кто-то имеет сетевые адреса организации и все точки отображения системных адресов, именуемые кадры (hr) или расчет (acct), он может попытаться проникнуть в эти системы в целях поиска информации. Кроме того, у взломщиков появится возможность определить архитектуру сети. Эта информация, полученная внешними пользователями, может помочь им определить структуру организации независимо от ее размеров и сферы деятельности. Когда автор работал с компанией, в которой было не более 100 пользователей, свободно обменивающихся информацией, было обнаружено, что в главную систему было осуществлено несколько вторжений пользователями Internet. Эта система являлась "главным сервером" компании и содержала много информации о компании. Даже после того как система была отделена от сети, поставлен маршрутизатор и написаны правила, разрешающие доступ к ресурсам только внутренним пользователям, попытки взлома этой системы продолжались. Посте проведенной в компании работы по преобразованию системных имен и изменению адресов для многих серверов была создана система 2-DNS.
Главная причина создания системы 2-DNS заключалась в организации службы преобразования имен внутренних пользователей в осмысленные имена, и в то же время в обеспечении преобразования имен в "обезличенные" имена для Internet в соответствии со стандартом DNS. В этом двойном подходе DNS внутренний сервер имен становился недоступен из Internet, и в то же время устанавливались системные имена, которые были понятны пользователям организации. При конфигурировании систем организации следовало учитывать, что они должны пользоваться сервером имен для преобразования адресов. Вторая часть системы была установлена так, чтобы быть доступной из Internet, но содержала другой набор имен для внешних пользователей. На рис. 5.2 показано, как это может быть реализовано.
Некоторые более мелкие организации пользуются услугами сторонних организаций для связи с Internet, и не имеют прямого доступа к собственным входам DNS. Это не является проблемой, пока администратор может запрашивать, какие были сделаны изменения. В любом случае было бы лучше разработать политику, которая предусмотрела бы создание в системе открытой части, в которой предоставлялось бы информации не больше, чем это необходимо. Можно включить в политику следующую формулировку.
Для обеспечения групповыми именами доступных внутренних систем необходимо следующее: служба сетевых имен должна обеспечить пользователей Internet условными именами, понятными для внутренних систем, а достоверные имена присвоить пользователям для работы во внутренней сети организации.
Рис. 5.2. Использование двухсистемной DNS для сокрытия внутренних имен
Перед осуществлением таких изменений организация должна рассмотреть множество вопросов. Некоторые из них касаются того, как внутренняя DNS будет преобразовывать адреса, размещенные в Internet, для внутренних пользователей, а также соглашений о присваивании имен и доступности к каждой системе DNS. Есть и другие вопросы. Необходимо рассмотреть последствия проведения такой политики - как это отразится на внедрении мер безопасности. Несколько разделов было посвящено именно этой теме. Возможно, это не самый лучший подход для вашей организации, поэтому нужно удостовериться, что это имеет смысл именно для ваших условий.
Преобразование сетевых адресов
Другой способ скрыть конфигурацию внутренней сети заключается в использовании одних адресов для внутренних систем и преобразовании их при связи с Internet или другими внешними сетями. Такой механизм называется преобразованием сетевых адресов (NAT— Network Address Translation). Основная функция NAT заключается в использовании особого алгоритма формирования адресов при работе во внутренней сети организации, которые перед посылкой их в Internet должны быть преобразованы в другие адреса.
Почему необходимо преобразование сетевых
адресов
Когда в начале 90 годов началось повсеместное использование Internet,
стало очевидным, что такой бурный рост числа пользователей приведет к
нехватке адресов доступа. Пытаясь замедлить этот процесс, рабочая группа
инженеров Internet (IETF - Internet Engineering Task Force) опубликовала
RFC 1631, Преобразователь сетевых адресов протокола IP (NAT- The IP Network
Address Translator). В этом документе объяснялось, как создавать сеть,
в которой используется отдельный список адресов для незарегистрированных
систем, которые могут быть преобразованы в зарегистрированные или "реальные"
адреса, маршрутизированные в Internet. После аннонсирования этого RFC
профессионалы безопасности стали призывать использовать NАТ, чтобы прятать
сетевую конфигурацию и масштаб работ организации, не изменяя открытой
информации об организации или открытых сведений о ее инфраструктуре.
Один из распространенных способов использования NAT заключается в назначении сетевых адресов для систем организации, не пользующихся Internet, из отдельного блока, установленного для скрытых сетей, которые будут преобразовываться в легальные адреса. Адресами скрытых сетей являются:
10.0.0.0-10.255.255.255. Отдельный блок адресов класса А. 172.16.0.0-172.31.255.255. 16 смежных блоков адресов класса В. 192.168.0.0-192.168.255.255. 255 смежных блоков адресов класса С.При использовании NАТ пользователь получает стандартный доступ в Internet, но адрес скрытой сети перед передачей должен быть преобразован системой, которая обеспечивает подключение и модификацию адреса перед отправкой (рис. 5.3). Устройства системы NАТ не являются посредником в сеансах. Однако представлять NАТ в качестве промежуточного звена довольно удобно.
Рис. 5.3. Преобразование адресов с помощью NАТ
Не в каждой организации есть смысл применять NAT. Одна из проблем заключается в том, что если сеть разрастается, то может оказаться недостаточно легальных адресов для доступа в Internet. Администраторы сети должны провести тщательный анализ и решить, нужно ли использовать NAT. Но в том случае, если NAT будет использоваться, необходимо составить формулировку для документа политики в наиболее обобщенном виде, чтобы обеспечить архитекторам и администраторам сети максимальную свободу выбора. Формулировка может выглядеть следующим образом.
Адреса внутренней сети организации должны оставаться скрытыми. Когда системы запрашивают доступ к другим сетям, скрытые адреса перед передачей должны быть преобразованы в легальные зарегистрированные адреса.
Другие проблемы адресации
Некоторых людей шокирует количество вопросов, которые им необходимо рассмотреть, чтобы постичь то, что на первый взгляд кажется довольно простым. Но если иметь четкие правила адресации каждого важного элемента сети, можно избавить администраторов сети от необходимости управлять различными схемами. Правила адресации должны учитывать способ назначения адресов. Ниже перечислено, что должно быть учтено при назначении адресов.
1. Будет ли адрес постоянным и заранее присвоенным системе или сетевому устройству? 2. Будет ли адрес постоянным и загружаться с помощью протокола выбора адреса, такого как протокол динамического выбора конфигурации хост-машины (DHCP— Dynamic Ноst Configuration Protocol) или протокол начальной загрузки (ВООТР — Bootstrap Protocol)? 3. Будет ли адрес присваиваться динамически, когда система подключается к сети?Все эти схемы имеют свои преимущества, но общепринято использовать постоянные или предписанные адреса даже в том случае, если они получены с помощью DHCP. Обновляя карту адресов сети, сетевые диспетчеры (люди или автоматизированные системы) смогут легко определить, кто отвечает за сетевой трафик. Чтобы пользоваться такой схемой, в правила может быть включена следующая формулировка.
Адреса сети должны быть предварительно определены для каждой системы и сетевого устройства и могут загружаться заранее или быть сформированными перед подключением к сети.
Те же выводы могут быть сделаны относительно адресации сети, не использующей IP-адреса. Например, IPX-адреса в среде Novell Netware или сформированные с помощью WINS (Windows Internet Naming Service— служба межсетевых адресов в среде Windows) для сети Microsoft также имеют подобные свойства и должны подчиняться тем же правилам.
Кроме того, в правила формирования адресов можно добавить строку, дающую право защищать адреса и серверы от тех, кто не имеет права доступа к ним. Эти правила могут быть написаны так, чтобы они подходили и для других адресных серверов и контроллеров, таких как устройство NAT или DNS. Формулировка правил может быть следующей.
Серверы сетевых адресов и серверы, которые используются для формирования адресов, должны быть защищены всеми доступными для этих устройств способами.
Правила расширения сети
Поскольку технологии становятся все более гибкими и всеобъемлющими, расширение сети неизбежно. При расширении сети было бы неплохо ввести инструкции для гарантии того, что не только расширение сети проходит, как следует, но и сохраняется оборудование сети. В главе 1 "Что собой представляет политика информационной безопасности" говорилось, что все это может быть сделано во время оценки степени риска. Кроме того, в других случаях эти знания могут существенно помочь в поддержании работоспособности сети и обеспечении администраторов схемой сети, позволяющей отслеживать сетевой трафик.
Правила расширения сети должны быть записаны обобщающей формулировкой, например, такой.
Необходимо разработать методики, позволяяющие реконфигурировать сеть организации. В этих методиках должны быть отражены все изменения, касающиеся непосредственно всех внутренних и внешних точек доступа.
Несмотря на то, что желательно не детализировать излишне методики, так как это ограничит область их применения, все-таки есть смысл привести список предлагаемых методик. Если вы сочтете нужным включить в документы политики такой список, то он может выглядеть так.
Добавление или удаление систем и других компонентов сети к существующей сети. Создание или удаление подсети. Подключение или отключение экстрасети. Подключение к Internet или отключение от Internet. Разрешение или прекращение доступа к сети сторонних пользователей.Управление доступом к сети
Перед обсуждением аутентификации пользователей сети необходимо разработать правила управления доступом к сети. Сети уже не являются монолитными объектами. В большинстве случаев имеется одна внешняя точка доступа — подключение к Internet посредством ISP (Internet Service Provider — поставщик услуг Internet). Правила упраатения доступом к сети будут определять, какую защиту необходимо установить на входных точках в сеть.
Шлюзы
Шлюзы являются пунктами, в которых сетевой трафик передастся из сети организации в другую сеть. В отношении шлюзовых пунктов правила управления доступом должны учитывать природу сети, в которой устанавливается мост.
Правила управления доступом для входящие и исходящих телефонных звонков (Dial-in и Dial-out). Охватывают требования по аутентификации. Скрыть точку телефонного доступа в сеть довольно сложно. Поэтому важно определить средства управления этим доступом. Существует множество соображений относительно правил доступа, таких как создание модемов исключительно для обработки исходящих сигналов (out-bound-only) для доступа dial-out. Необходимо написать пункт правил, который будет предписывать применение соответствующих средств управления.Весь телефонный доступ в сеть должен быть защищен с помощью средств строгого контроля аутентификации. Модемы необходимо сконфигурировать для одного из доступов dial-in или dial-out, но ни в коем случае не для обоих. Администратор сети должен обеспечить процедуры гарантированного доступа к модемным системам. Пользователи не должны устанавливать модемы в других точках сети бел соответствующих санкций. Прочие внешние подключения. Возможны различные подключения к сети извне организации. Правилами можно оговорить прямой доступ клиентов в сеть через виртуальную частную сеть VPN (Virtual Private Network) и через расширения сети организации, известные как экстрасети. Подключение к Internet. Отличается от других подключений, поскольку люди хотят иметь открытый доступ в Internet, в то время как разрешение доступа обеспечивается службами организации. Правила, регламентирующие эти подключения, обсуждаются в главе 6 "Правила безопасности Internet".
Как и для любых правил, нужно ожидать, что будут появляться запросы на изменение правил управления доступом. Независимо от причин, требующих корректировки правил, следует предусмотреть возможность вносить исключения в правила с помощью механизма пересмотра правил. Если согласно предписаниям политики был создан комитет управления безопасностью (см. главу 3 "Обязанности в области информационной безопасности"), то можно потребовать, чтобы комитет пересматривал правила.
Любой шлюз, предлагаемый для установки ь сети компании, если он может нарушить правила или процедуры, предписанные этими правилами, не должен устанавливаться без предварительного утверждения комитетом управления безопасностью.
Виртуальные частные сети и экстрасети
Увеличение количества сетей в организации вынуждает искать новые варианты подключения удаленных офисов, клиентов и упрощения доступа обслуживающих контрагентов или потенциальных контрагентов. Этот рост породил два типа внешних соединений: виртуальные частные сети (VPN — Virtual Private Network) и экстрасети. VPN представляют собой недорогой способ установить информационную связь между двумя и более подразделениями организации, расположенными на разных территориях. Организации создают VPN путем подключения всех подразделений к Internet и установки устройств, которые будут осуществлять шифрование и дешифрование информации в обоих связывающихся между собой подразделениях. Для пользователей работа через VPN будет выглядеть так, как будто оба подразделения находятся на одной территории и работают в единой сети.
Проверка полномочий вспомогательных систем
Перед тем как продолжить, важно вспомнить, что каждый из шлюзов или каждая вспомогательная система является точкой входа в сеть организации. В любой точке входа должны каким-то способом проверяться полномочия потока данных, входящих и исходящих из сети. Один из вопросов, которые необходимо рассмотреть, заключается в требовании санкционирования внешних подключений к вспомогательным системам сети. Это может оказаться проблемой для вспомогательных систем, которые подключены к сети постоянно. Для таких вспомогательных систем необходимо определить, каким образом будет осуществляться санкционирование их присутствия в сети. В действительности, даже временные подключения к сети, такие как подключения входящих модемов, могут иметь строгие требования по аутентификации.
В этом разделе правила требования по аутентификации не должны описываться— они обсуждаются в следующем разделе
Безопасность регистрации
Итак, к сети применены все меры предосторожности, архитектура поддерживает бизнес-план компании и политику безопасности, а оборудование защищено физически. В конечном счете, мы находимся у места регистрации, где пользователь или служба идентифицирует себя и предъявляет какой-то тип мандата для вхождения в систему. Отсутствие четких правил регистрации подобно строительству наилучшей атомной подводной лодки с использованием ширмы в качестве люка.
Требования к регистрации и процедуры регистрации
Первой информацией в любой регистрационной последовательности должна быть посылка, идентифицирующая того, кто запрашивает разрешение на доступ в сеть. Независимо от используемых протоколов необходимо знать, кто пытается получить доступ к сетевым системам или, в некоторых случаях, в качестве кого они хотят представиться сетевым службам.
Итак, что собой представляют ключи идентификации пользователей, которые используются для регистрации в системе или сети? В некоторых хорошо защищенных системах, таких как военные ведомства, идентификация пользователей производится на основе случайной последовательности символов. В других организациях предпочитают использовать методы, которые позволяют однозначно идентифицировать пользователя, не обращая внимание на то, каким образом созданы имена пользователей.
Если имена пользователей могут предоставить информацию об организации, то хорошей идеей могут быть произвольные имена. Однако использование случайной последовательности символов может привести к тому, что пользователи станут записывать эти имена на клочках бумаги. Если они записывают имена, то они вполне могут записывать и пароли. Чтобы предотвратить это, можно разрешить использовать имена пользователей, которые легко запоминаются.
Несмотря на то, что сама организация назначает имена пользователей, правилами должен определяться их вид. Например, в одной из компаний, с которой автору книги пришлось сотрудничать, для создания имен пользователей использовали табельный номер служащего, перед которым ставилась дополнительная буква. Правила, которые были разработаны в этой компании, гласили.
Идентификационные имена пользователей должны состоять из пятизначного табельного номера служащего, присвоенного отделом кадров, перед которым нужно поставить одну дополнительную букву.
Возникают и другие вопросы, связанные с правилами назначения имен пользователей. Правилами должно быть предусмотрено наличие системных имен и обработка имен пользователей, назначенных по умолчанию. Эти вопросы возникли тогда, когда появились новые операционные системы, в которые поставщик для удобства включил множество имен для различных вспомогательных систем. Если не удалить эти имена, то есть вероятность, что они при случае могут создать проблемы с безопасностью. Несмотря на то, что большинство поставщиков решили эту проблему, введение соответствующего пункта в правила поможет администраторам учитывать эти моменты еще до того, как что-нибудь случится. Ниже представлен пример формулировки правил, регламентирующей использование имен пользователей в системе.
Системным именам и именам пользователей, присвоенным по
умолчанию, назначенньм самой операционной системой, должен быть присвоен
пароль, отличный от того, который был назначен при загрузке операционной
системы.
Имена пользователей, назначенные вспомогательным системам без учета требований
регистрации, должны быть сконфигурированы так, чтобы не позволять им регистрироваться
в системе. Имена пользователей вспомогательных систем, которые не используются
должны быть удалены из системы.
Приглашенные и прочие пользователи
Необходимо назначить имена для приглашенных пользователей и прочих, таких как подрядчики и обслуживающий персонал, чтобы они тоже могли получить доступ в сеть. Несмотря на то, что они обслуживают организацию, они все равно являются аутсайдерами. В правила назначения пользовательских имен для этих сторонних пользователей можно включить предписание, с которыми пользователи должны ознакомиться и следовать им. Также нужно включить в правила требования контроля, предназначенные для поручителя этих аутсайдеров.
Одно общее требование правил заключается в определении условий присваивания пользовательских имен приглашенным пользователям. Одно простое требование, общее для всех правил, в разработке которых приходилось участвовать автору книги, заключается в разрешении поручителю организации запрашивать доступ к администратору. Поручитель и администратор будут вместе отвечать за обследование объекта и его соответствие установленным правилам. Проведение такой политики делает процесс обследования объекта более коротким, чем тогда, когда в правилах записано, что для осуществления обследования требуется создание специальной комиссии. Это намного выгодней потому, что для обслуживающего персонала требуется срочный доступ к системе.
Если принято решение использовать эти рекомендации, то можно записать в правила набор формулировок следующего характера.
Приглашенные noльзователи и прочие пользователи, не являющиеся
сотрудниками организации, получают доступ к сети и ее ресурсам у поручителя
организации и назначенного системного или сетевого администратора. Администратор
разрабатывает процедуры для предоставления, отмены и пересмотра права
доступа приглашенньм пользователям и прочим пользователям, не являющимся
сотрудниками организации.
Поручитель предоставляет пользователям право доступа к пpaвилам безопасности
организации и процедурам и разъясняет им, что они обязаны соблюдать эти
правила. Поручитель и администратор отвечают за контроль соблюдения правил
приглашенными пользователями.
Пользовательские имена должны присваиваться приглашенным пользователям
только на то время, пока им необходим доступ в систему. Имена пользователей
должны быть аннулированы, как только доступ им станет ненужным.
Регистрационные баннеры
После назначения имен пользователей в правила безопасности можно включить условия и инструкции для регистрации и аутентификации пользователей. Во-первых, в рабочих инструкциях полезно иметь регистрационные баннеры. Регистрационные баннеры представляют собой важнейшую часть информации, которая сопровождает на экране появление предложения зарегистрироваться. Баннеры могут содержать информацию о системе, включая тип операционной системы, или информацию о компании. Независимо от того, какая информация содержится в баннере, кто-нибудь, желающий взломать систему, может использовать эти сведения. Информация о типе операционной среды может помочь квакеру найти уязвимые места в системе. Если система или сеть является внутренней или для организации это не имеет значения, то нет и необходимости регламентировать правилами использование регистрационных баннеров. В противном случае формулировка правил может быть следующей.
Все регистрационные экранные сообщения, отображения данных и другие экранные формы, появляющиеся во время регистрации или аутентификации и сопровождаемые баннерами, не должны содержать никакой информации об операционной среде.
Баннеры существуют не только для регистрации
Тем, кто разрабатывает правила применения регистрационных баннеров, важно
помнить, что баннеры применяются не только при регистрации. Солидный баннер
может быть строкой приветствия при отправлении электронной почты с помощью
протокола SMTP (Simple Mai! Transfer Protocol - упрощенный протокол электронной
почты). Большинство программ, отвечающих на запросы SMTP, выводят регистрационные
баннеры, которые идентифицирует систему и даже версию используемого программного
обеспечения. Хакер может использовать эту информацию, чтобы найти способ
"протестировать" конфигурацию на предмет уязвимых мест. Несмотря
на то, что какая-нибудь рабочая программа может быть предметом вашей гордости
(особенно та, которая упаковала и отправила электронную почту), все-таки
лучше ее спрятать от широкой публики.
Одним из видов информации, который можно включить в регистрационный баннер, является сообщение о том, кто может использовать систему. Это простые неразглашаемые формулировки о том, кому' разрешено пользоваться системой. Они могут варьироваться от полноэкранных формулировок до простой одиночной строки, наподобие следующей.
Использование этой системы разрешено при условии соблюдения правил и методик компании.
Если одно из нечасто выполняемых действий выходит за рамки предписаний, то будет нелишне отразить это соответствующим пунктом правил. Обязательно нужно рассмотреть, желательно с привлечением юриста, возможные изменения существующих правил. Таким образом, мы можем модернизировать предыдущую формулировку правил, включив в нее предписание о неразглашении:
Баннеры, которые выводятся на экран при регистрации и аутентификации, должны содержать следующее сообщение: "Использование этой системы разрешено при условии соблюдения правил и методик компании."
Соглашение о неразглашении в баннерах
Использование баннеров неразглашения не является необходимостью, несмотря
на то, что многие организации используют их для информирования потенциальных
пользователей о том, что система ограничена для использования, и их действия
могут контролироваться и записываться. Однако некоторые суды в Соединенных
Штатах выносили решения, в которых говорилось, что, поскольку при регистрации
на экране отсутствовало предупреждающее сообщение, нельзя считать, что
злоумышленники проникали незаконно в систему, а следует считать, что они
были туда приглашены. Эти вердикты выносились на основании законов, применяемых
в привычном мире. Несмотря на то, что существуют новые законы, которые
обеспечивают использование в подобных случаях более совершенного инструмента
для обвинителей, наличие прецедентов, в которых выносились противоположные
решения, вынуждает судей, не знакомых с киберпространством, принимать
во внимание эти прецеденты. Нужно поинтересоваться у юриста, нужно ли
создавать подобные баннеры для вашей правовой защиты в случае возникших
проблем.
Средства регистрации
Средства регистрации способствуют процессу аутентификации. Они обеспечивают выполнение инструкций для обеспечения положительного результата аутентификации (биометрия, PKI, Kerberos и т.д.), а также выбор многократных или однократных сеансов. В правилах положительной аутентификации не нужно конкретно определять протокол или тип сервиса, а только требования их наличия. Если не конкретизировать правила, разработчики и администраторы получают возможность использовать наилучший сервис для организации. Простая формулировка правил может выглядеть следующим образом.
Службы регистрации должны обеспечивать положительную аутентификацию. Это даст гарантию того, что законный пользователь получит доступ к системе или сетевому окружению.
Для некоторых организаций выбор однократных или многократных сеансов аутентификации не представляет особых проблем. В операционной среде сервера, обслуживающего типовые рабочие станции, система с сетевой структурой может инициировать многократные сеансы так, как требует операционное программное обеспечение. Однако, при использовании универсальной машины или любого другого сервера с разделением времени/монопольным сервером может возникнуть желание ограничить количество сеансов, которые может инициировать пользователь.
Пользователям с правом доступа к производственной сфере нельзя разрешать инициировать многократные сеансы аутентификации.
Отчетность при регистрации
Существует два типа требований по отчетности, которые рекомендуется добавлять в документы, составляющие политику безопасности. Первый заключается в протоколировании в системном журнале каждой попытки войти в систему. Обычное протоколирование или специальные средства обнаружения вторжений могут использоваться администратором, чтобы следить за выполняемыми операциями. Их также используют для наблюдения за работой системы и для разработки шаблонов применения средств обнаружения. Эти шаблоны могут использоваться более сложными средствами для обнаружения уязвимых мест системы.
Другое требование заключается в том, чтобы пользователь имел возможность определить, когда и откуда была сделана последняя попытка войти в систему. Несмотря на то, что многие пользователи игнорируют эту информацию, есть шанс, что необычные попытки получения доступа будут отмечены. Один из администраторов, с которым пришлось сотрудничать автору, пытался помочь пользователю, у которой были проблемы с рабочей станцией. Когда он стал протоколировать каждую регистрацию пользователя в системе, в сообщении о "последней регистрации" было обнаружено, что пользователь была зарегистрирована в 4 часа утра, в воскресенье. Это выглядело довольно странно, поскольку в это время она отсутствовала в городе, так как выезжала в горы кататься на лыжах. Администратор смог на основе этой информации определить, что кто-то взломал сеть. В документах политики безопасности этот момент не был учтен, поэтому, когда выяснилось, насколько легко пробить защиту, этот момент добавили в соответствующие правила.
Ограничение количества регистрации
После того, как пользователь зарегистрировался в системе, может возникнуть необходимость ввести определенные ограничения на его или ее сеанс работы в системе. Если пользователь работает с важной информацией, то может появиться необходимость ввести в правила предписание, требующее блокирование доступа этого пользователя к информации других пользователей, или же выход из сети одновременно с другими пользователями. Те, кто имеет доступ к важным данным, должны понимать, какие возможны последствия, если зарегистрированную рабочую станцию оставить без присмотра при просмотре документов. В дополнение к правилам необходимо проводить инструктаж пользователей, чтобы они ни при каких обстоятельствах не нарушали секретность своего сеанса работы в системе.
Другим хорошим инструментом ограничения сеанса является ограничение времени работы пользователя в системе (например, только в течение рабочего времени) или же автоматический выход из системы посте истечения определенного времени бездействия станции, или выход в определенное время дня. Зачастую правила ограничения времени холостой работы рабочей станции или времени сеанса могут оказаться бесполезными. Во многих случаях они комбинируются с другими ограничениями сеансов работы в системе, чтобы создать основательную формулировку правил.
Пользователи обязаны разрегистрировать свою рабочую станцию, когда не работают на ней. Администраторы должны разработать процедуры, гарантирующие безопасность неиспользуемых рабочих станций путем их автоматической разрегистрации или другими способами, ecли они не являются активными в течение определенного периода времени, установленного во время обследования объекта.
Управление пользовательским доступом
Наряду с созданием пользовательских имен необходимо разработать директивы совокупного управления пользовательскими именами. Управление пользовательскими именами состоит из директив, которые предписывают, как создавать и аннулировать эти имена. Кроме того, в задачи управления входят следующие.
Обработка неиспользуемых имен пользователей. Инструкции, касающиеся уволенных служащих или служащих, которые временно не работают. Удаление или защита пользовательских имен, присвоенных "по умолчанию". Разрешение или запрет анонимных пользовательских имен (таких как анонимный ftp). Требование распределения пользователей по группам или выполняемым функциям.Несмотря на то, что эти задачи в правилах не определяются, можно включить список, наподобие представленного выше, в виде рекомендаций введения всех или некоторых этих требований в административные инструкции. Независимо от того, как разрабатываются правила, следует расписать эти моменты таким образом, чтобы административные инструкции не были сведены лишь к этим рекомендациям.
Привилегированный режим работы
Труднее всего разработать правила, в которых описываются скорее исключения, чем правила. Особые привилегии являются исключениями из правил, и такие предписания требуют особого подхода к работе и специальных инструкций, потому что они не должны нарушать другие правила и инструкции безопасности. Правила привилегированного режима работы должны быть написаны таким образом, чтобы не только разрешить работу в привилегированном режиме, но и в общих чертах описать, какие должны быть разработаны инструкции, и какими способами они должны внедряться. При разработке правил необходимо учесть, какими методами будет поддерживаться привилегированный режим. Нужно быть очень осторожным, разрабатывая правила такого рода. Ниже приведена очень простая формулировка, но вам необходимо учесть конкретные требования вашей организации и привести эту формулировку в соответствие с этими требованиями.
Для привилегированного режима работы должны быть написаны соответствующие инструкции, гарантирующие их четкое выполнение техническим персоалом организации. В этих инструкциях должны быть определены условия контроля выполнения, управления и пересмотра требований доступа.
Пароли
После имен пользователей пароли становятся второй линией защиты против незваных гостей. Можно тщательно назначать и поддерживать пользовательские имена, но в один прекрасный день неудачно выбранный пароль может позволить кому-нибудь войти в сеть. Правила назначения паролей делятся на две категории: какую структуру имеют действующие пароли и способы хранения этих паролей.
Правила назначения действующих паролей
Хорошие правила назначения действующих паролей предусматривают генерацию паролей, которые разгадать непросто. Несмотря на то, что концепция сложности разгадывания выглядит несколько абстрактно, общепринятая установка заключается в том, что пароль должен представлять собой смесь букв, цифр или особых символов, а не просто слово, которое можно найти в словаре. Другой способ предотвращения разгадывания паролей заключается в хранении так называемых "социальных словесных конструкций" для каждого пользователя. Эти конструкции можно применять в качестве шаблона при сопоставлении с ними вводимых паролей, и пользователям не будет позволено использовать эти данные в своих паролях. Эта информация может содержать имена супругов, детей, домашних животных, место рождения, юбилей, день рождения и т.д.
В некоторых организациях, например, связанных с оборонным комплексом, может предъявляться требование генерировать автоматически пароль для каких-либо пользователей. Обычно при генерации таких паролей используется разное количество печатных знаков. После генерации такой пароль передается пользователю. К сожалению, такой пароль нелегко запомнить. Пользователи имеют тенденцию записывать эти пароли на клочках бумаги, которые могут быть утеряны или похищены. Если вами используются дополнительные методы контроля за назначением паролей, то стоит попытаться разработать правила, позволяющие генерировать более читабельные пароли для пользователей.
Другая важная особенность заключается в сроке действия пароля. Если срок действия пароля не определен, то похищенный пароль может использоваться постоянно. Но если пароль имеет определенный срок действия, то в случае компрометации пароля, остается шанс, что проблема разрешится сама собой после изменения пароля в назначенный срок.Несмотря на то, что это звучит несколько наивно, данная методика похожа на периодическое изменение комбинации цифр на замке, чтобы выяснить, кто знает эту комбинацию.
Можно ли повторно использовать пароли, которые были изменены? Одна из компаний, с которой сотрудничал автор книги, поддерживала базу данных с последними 24 паролями, чтобы пользователь имел возможность посмотреть, не назначает ли он старый пароль при очередной замене пароля. Несмотря на то, что правилами вроде бы было предусмотрено, что пароль не сможет быть использован повторно в течение двух лет, ошибкой создателей этой базы данных было то, что они рассчитывали на изменение пароля ежемесячно согласно истечению его срока действия. Однако, поскольку автор книги использовал свое присутствие в системе и, соответственно, пароль для тестирования, он в течение трех месяцев заполнил базу назначенных паролей, чем продемонстрировал несостоятельность таких допущений.
Независимо от используемого критерия, необходимо, чтобы действие его было обеспечено для всех пользователей одинаково.
На основе всех этих соображений можно составить образец формулировки правил наподобие следующей.
В учетной записи каждого пользователя должен содержаться его собственный пароль. Действующий пароль должен состоять из комбинации букв, цифр или специальных символов; состоять, не менее чем из восьми символов, и оставаться действующим в течение 90 дней после последнего изменения. Пароль нельзя использовать повторно, по крайней мере, в течение 24 месяцев после его последнего использования.
Хранение паролей
Основное правило заключается в том, что пароли нельзя хранить так, чтобы каждый имел возможность их прочитать. Правилами в этом деле оговаривается шифрование паролей с применением сгенерированных ключей или даже способы хранения паролей систем или сетей, где они могут быть считаны с использованием основных методов доступа.
Это — формальное определение. В большинстве случаев вам не удастся управлять хранением или пересылками паролей. Пока не разработано собственное прикладное программное обеспечение, управление паролями обычно возлагается на операционную систему или на используемое программное обеспечение. В таком случае нет необходимости включать в правила формулировку, касающуюся хранения паролей. Однако для полноты картины стоит все-таки привести следующую формулировку.
Хранить пароли нужно, исходя из требовании системы, сети или используемого программного обеспечения. В эти требования должно быть включено условие неизменяемости приемов сохранения паролей в тайне.
Специальные пароли
В конце 70 - начале 80 годов многим заказчикам поставлялся очень популярный мини-компьютер, в котором для обслуживающего персонала были назначены пользовательское имя FIELD и пароль SERVICE. Этому пользовательскому имени был разрешен доступ к различным диагностическим пакетам, многие из которых могли нанести ущерб при неправильном обращении. Разъезжая по командировкам в качестве консультанта, автор книги был потрясен количеством систем, к которым он мог получить доступ, используя пароль по умолчанию. На это следует обратить внимание, поэтому мы снова и снова подчеркиваем необходимость установить правилами требование к администраторам изменять пароли, установленные по умолчанию для стандартных системных пользователей.
Однажды вечером автор вместе с другом находился в крупной брокерской фирме, когда устройства звуковой сигнализации (beeper) стали подавать сигналы тревоги. Через считанные секунды друг и несколько вооруженных охранников вошли в помещение, где обнаружили человека, лежащего на рабочей станции. У несчастного был сердечный приступ. Для вызова скорой помощи он зарегистрировался в системе и ввел специальный пароль, и этим подал сигнал системе наблюдения за сетью о том, что кто-то принудил его ввести пароль.
Поскольку брокерская контора ворочает ежедневно ценными бумагами на миллиарды долларов, было установлено правило принудительного пароля, на тот случай, если кто-то вздумает ворваться в здание и будет принуждать брокера войти в систему. Если введен принудительный пароль, тут же активируется служба физической безопасности конторы. В данном случае офицер смог оказать первую помощь, пока не прибыла служба скорой помощи.
Принудительные пароли довольно сложны, поскольку они должны разрешать пользователю входить с систему, при этом вызывая неслышный сигнал тревоги, показывающий место, где возникли проблемы. Формулировка правил для такого случая должна просто говорить о необходимости иметь принудительные пароли, или же просто описывать, что из себя представляют принудительные пароли, не описывая сути их функционирования.
Пользовательский интерфейс
Обычно пользовательский интерфейс зависит от алгоритмов, заложенных в базовой операционной системе или в программном обеспечении. За некоторыми исключениями, когда есть серьезные основания для изменения интерфейса, правила безопасности могут требовать, чтобы интерфейс пользователя оставался неизменным. Однако системы, построенные на основе расширенных интерфейсов, например, некоторые сетевые операционные системы или системы с инфраструктурой открытого ключа (PKI — public key infrastructure) позволяют делать замены или дополнения к алгоритмам операционных систем, благодаря чему они воспринимаются как более безопасные версии интерфейса.
В зависимости от конкретных условий в формулировке правил управления интерфейсом может быть написано, что интерфейс, предоставленный разработчиком системы аутентификации, изменять нельзя. Альтернатива заключается в том, чтобы алгоритм, используемый для аутентификации, строился на основе других правил.
Областью, в которой ограничения могут быть довольно эффективными, является определение процесса ввода паролей. Чтобы были гарантии того, что во время ввода нельзя перехватить пароли, правилами можно ограничить отображение паролей во время ввода, требовать, чтобы пароль был введен за определенный промежуток времени, разрешать ограниченное количество сбоев при вводе, а также требовать, чтобы пароли не пересылались в читабельной форме.
Интересный вопрос заключается в том, что отображать при введении пользователем пароля. Некоторые виды программного обеспечения выводят звездочки или другие символы при каждом нажатии клавиши. Однако если кто-то заглянет через плечо пользователя, пытаясь увидеть пароль, то он сможет увидеть длину введенного пароля. Зная, какое количество клавиш было нажато, т.е. ограниченный набор комбинаций, кто-то может попытаться определить пароль. Давайте рассмотрим этот вопрос с математической точки зрения. Если пароль состоит из любых печатаемых символов набора ASCII (American Standard Code for Information Interchange — Американский стандартный код для обмена информацией), то существует 96 возможностей для каждой позиции символа. Если пароль не короче 6 символов и не длиннее 10 символов, то количество возможных комбинаций символов будет следующим: 966+967+968+969+9610.
Это составляет более 6.7x1019 возможных комбинаций. Теперь, если нам известно, что пользователь ввел только семь символов, то количество комбинаций уменьшится до 7.5x1013. Однако, если мы видели, что пользователь в качестве первого символа нажимает клавишу "S", то количество комбинаций уменьшится до 2(7,8x1011).
В большинстве случаев мы не можем контролировать методы, применяемые программным обеспечением или операционной системой при вводе пароля. Однако можно разработать правила, предписания которых требуют, чтобы интерфейс не отображал количество символов пароля.
И, наконец, интерфейс должен быть таким, чтобы после ввода пароля он не передавался в систему в читабельной форме. Одна из проблем аутентификации по умолчанию, используемой в интерфейсах всемирной "паутины" (Wold Wide Web), заключается в том, что они передают пароль через Internet в форме, которую легко расшифровать. Эти пароли могут быть перехвачены и тайком использованы. Если это возможно, правила не должны разрешать ввод паролей такого типа, особенно для производственных систем. Один из способов, применение которого можно оговорить в правилах, заключается в применении одностороннего криптографического хэша (hash). По этому методу хэш-функция преобразовывала бы пароль в числовое значение фиксированной длины на базе введенной пользователем информации. Это значение фиксированной длины передавалось бы затем на сервер, где подвергалось другому хэш-пересчету, а потом сопоставлялось с информацией, хранящейся в системе. Таким образом, передается и хранится на сервере только хэш, а не сам пароль.
Использование одностороннего криптографического хэша является лишь одной из деталей реализации. Можно к этому добавить и другие концепции, чтобы формулировка правил имела, приблизительно, такую форму.
Пользовательский интерфейс при вводе паролей должен позволять пользователям вводить свои пароли без показа каких бы то ни было характеристик ввода. Эти пароли не должны передаваться в сеть в читабельной форме.
Средства управления доступом
Средства управления доступом сводятся не только к аутентификации, но с их помощью определяется, кто имеет доступ к ресурсам организации. Средства управления доступом предусматривают несколько способов реализации. Наиболее распространенные алгоритмы привязаны к тем, что предлагаются операционными системами или программным обеспечением, поддерживающим работу предприятия. Это значит, что правила управления доступом привязаны к технологии, используемой для поддержки бизнеса.
Правила управления доступом должны быть сфокусированы на том, где использовать управление доступом, а не декларировать его использование. Специфика разработки правил управления доступом заключается в том, чтобы широкая формулировка правил не могла быть приложена к тому, что не требует управления доступом. Например, правила управления доступом, которые ограничивают доступ к информации организации, хранящейся в базе данных, не должны быть приложимы по отношению к документам, доступным через Intranet.
Таким образом, первым шагом в определении того, где требуются правила управления доступом, заключается в выяснении областей, в которых необходимо использовать компьютерные системы управления доступом, или требуется управление доступом на базе пользовательских имен/паролей. Чтобы это осуществить, необходимо вернуться к этапу инвентаризации ваших систем и отметить, где и как они используются. На основе такой информации можно разработать правила, соответствующие используемым вспомогательным системам.
Одной из проблем такого подхода является то, что между разработкой правила и его последующим пересмотром может появиться какая-нибудь новая система или новое требование ведения бизнеса, которые требуют введения новых правил управления доступом. Вместо пассивного ожидания последующего пересмотра правил лучше создать для каждого средства управления доступом свои правила в виде отдельного документа и добавить еще один документ, в котором говорится о следующем.
Ответственные за информацию лица, желающие установить новые системы или программное обеспечение для поддержки новых или уже существующих требований ведения бизнеса, для которых требуются собственные средства управления доступом, должны еще до инсталляции этих средств разработать правила управления доступом для этих систем. Эти правила должны пересматриваться таким же образом, что и уже существующие.
После рецензирования новых правил они добавляются к другим документам политики и становятся частью общей программы безопасности.
Телекоммуникации и удаленный доступ
С каждым годом количество людей, пользующихся средствами телекоммуникации, растет. Независимо от того, служат они одиноким родителям, потерявшим трудоспособность служащим или в качестве случайно подвернувшегося средства, использование телекоммуникаций требует четкой стратегии для гарантии того, что время связи полезно используется, и деятельность служащего так же продуктивна вне офиса, как и во время его работы в офисе.
Иной аспект правил удаленного доступа заключается в том, что они должны обеспечивать доступ в сеть служащим и клиентам, находящимся вне месторасположения их организации. Обычно эти правила определяют доступ к сети извне по телефонным каналам. Но новые технологии могут вынудить вас разработать иные правила, обеспечивающие доступ в сеть с помощью новых средств.
Руководящие принципы эксплуатации оборудования
Некоторые организации не вводят ограничения на оборудование, используемое для телекоммуникаций или удаленного доступа. Правила эксплуатации оборудования требуют от служащих использовать оборудование, предоставленное организацией. В иных случаях организация не устанавливает свои правила в этой области, а предоставляют сетевым администраторам самим определять руководящие принципы в виде рабочих инструкций. Организации, которые поставляют компьютеры и оборудование, должны устанавливать правила, требующие использовать системы в том виде, в каком они поставлены, и запрещающие пользователю вносить изменения в программы или конфигурационные установки.
Руководящие принципы защиты информации при удаленном доступе
Одной из проблем, которые приходится решать при выдаче разрешения служащим работать вне офиса, является защита как самого компьютера, так и данных на дополнительных рабочих узлах. Поэтому, в принципе, не мешало бы разработать правила, определяющие безопасность работы вне офиса. Эти правила могут быть разработаны, исходя из тех же соображений, что и правила для пользователей в офисе.
В некоторых организациях необходимо провести предварительное обследование территорий, где будут расположены удаленные рабочие места. Несмотря на то, что сам автор не сталкивался с подобными правилами, но слышал, что такие требования выставляются со стороны федерального правительства к подрядчикам, чтобы обеспечить выполнение требований национальной безопасности.
Помимо собственно вопросов безопасности существуют проблемы с правами на интеллектуальную собственность, созданную в организации. Для защиты прав организации на эти информационные активы будет неплохо добавить правило владения этой собственностью в программу развития интеллектуальной базы организации?
Ответственность служащих
Если бы мы жили в идеальном мире, то можно бы было верить в то, что все служащие будут выполнять свою работу правильно и честно. Но поскольку мы живем в мире, далеком от совершенства, приходится заботиться о том, чтобы служащие, работая вне офиса, выполняли все правила и инструкции компании. Чтобы это было узаконено, добавьте приблизительно такую формулировку в правила информационной безопасности.
Служащие, которым предоставлен удаленный доступ к сети организации, должны руководствоваться в работе правилами и инструкциями защиты оборудования, данных и сетевого доступа так же, как если бы они работали на основной площадке организации.
Однако, этого может оказаться недостаточно. Работающие вне офиса должны также быть ознакомлены с инструкциями по удаленному контролю, с правилами лицензирования программного обеспечения, с правилами создания резервных копий и прочими инструкциями, действующими в организации. Чтобы усилить формулировку правил, можно добавить следующее.
При работе вне офиса пользователи должны использовать только лицензионное программное обеспечение, исполнять все инструкции по созданию резервных копий, а также руководствоваться в своей работе существующими в организации инструкциями.
Телекоммуникации и средства удаленного доступа
И, наконец, в правилах должно быть отражено, каким образом организация желает защитить свои активы, используемые удаленными пользователями, имеющими доступ к сети организации. Как правило, это правила эксплуатации модемов и телефонных линий, к которым подключены модемы. Однако, с появлением новых технологий в организации может быть разрешен доступ с использованием Internet.
Безопасность связи по телефонным каналам
Когда речь идет об информационной безопасности, модем ничем не отличается от других точек доступа к сети. Модемы являются точками входа в сеть и, несмотря на то, что правилами может быть не разрешено, но входящий звонок может быть набран необязательно законным пользователем, в общей программе безопасности это должно быть обязательно учтено.
В первую очередь необходимо рассмотреть управление телефонными номерами. Как правило, большинство компаний не публикуют номера, закрепленные за модемами. Однако одна из компаний, с которой сотрудничал автор, опубликовала эти номера, поскольку хотела, чтобы в любое время клиенты имели возможность установить контакт с ее представителями. В результате, была опубликована телефонная книга с перечнем "МОДЕМ 1", "МОДЕМ 2" и т.д. Вскоре после публикации на эти модемные линии стало поступать необычное количество звонков. Поэтому, с точки зрения здравого смысла, стоит включить в правила следующую формулировку.
Телефонные номера, используемые для входящих модемных линий, не должны публиковаться ни в каких каталогах, которые могут быть доступны каждому, кто не имеет права доступа.
Другой пункт правил защиты модемов устанавливает требование периодической замены телефонных номеров. Есть компании со строгим доступом и жесткими требованиями службы безопасности менять телефонные номера доступа всякий раз после реорганизации штата служащих или завершения проектов. Однако, проведение такой политики требует очень напряженной работы руководства. Ведь помимо изменения номеров нужно информировать и тех, кому необходимо знать об этих изменениях. Кроме того, надо позаботиться о том, чтобы номера были выбраны из списка незадействованных номеров. Да и материально-техническое обеспечение процедур данного типа может бьпь настолько сложным, что проведение такой политики неприемлемо для большинства предприятий.
В дополнение к стандартным средствам управления доступом, можно рассмотреть возможность расширения системы аутентификации, необходимость в которой появляется при подключении к сети посредством модемов. В качестве примера можно привести использование одноразового пароля или алгоритма защиты с применением ключей для защиты пользователей модемов. Однако, это не единственный способ, позволяющий обеспечить доступ в сеть только разрешенному удаленному пользователю. Прежде, чем зафиксировать это в правилах, необходимо познакомиться с технологиями, которые применяются в вашей организации. Обычно с ними знакомятся в процессе обследования объекта. Даже если еще не установлены расширенные системы аутентификации, в правилах должно быть отражено только то, что уже есть в наличии, или просто нужно составлять формулировки правил доступа в общем виде, оставляя подробности на усмотрение администратора.
Получение доступа к сети посредством модемов, подключенных к телефонным каналам, должно сопровождаться дополнительным этапом аутентификации, чтобы гарантировать законность этого доступа.
Туннелирование через Internet
Несмотря на то, что выбор доступа в сеть с использованием средств зашиты Internet имеет много преимуществ, во многих организациях побаиваются использовать Internet до тех пор, пока протоколы и технические средства не станут достаточно защищенными. Но если использование Internet является частью бизнес-плана вашей организации, то в документы политики следует включить минимальные требования к безопасности подключений. Например, можно потребовать, чтобы информация, пересылаемая между пользователями и сетью, шифровалась. Можно также потребовать аутентификацию пользователей Internet наподобие аутентификации внешних пользователей, получающих доступ по телефонным каналам. Не важно сколько требований будет включено в правила, важно, чтобы они не мешали администраторам изменять инструкции при введении новых технологий безопасного туннелирования через Internet.
Сетевая безопасность имеет отношение не
Сетевая безопасность имеет отношение не только к безопасности Internet, но и к защите каждого сетевого подключения и интерфейса. Это означает установление определенных взаимоотношений между информацией и теми, кто ее запрашивает. Основой управления доступом является аутентификация. Аутентификация представляет собой передний рубеж защиты для любой системы или сети, где реквестор на основании предъявленных полномочий получает разрешение на вход в систему. Мы пытаемся решить проблемы защиты информации, опираясь на знание архитектуры сети и применяя различные способы аутентификации.1. Адресация сети и архитектура. Руководствуясь правилами, предписывающими проектировать сеть с учетом требований безопасности, проектировщики отделяют системы с секретными или важными данными для того, чтобы легче было управлять доступом. В правилах сетевой адресации определяется, какую информацию о конфигурации сети можно публиковать вне организации. Необходимо сконфигурировать DNS для сокрытия имен от внешнего окружения и систему преобразования
сетевых адресов (NАТ), чтобы спрятать адресацию. Правила должны определять процедуры расширения сети. Такие возможности, как статическая и динамическая адресация, а также другие типы адресных решений, тоже должны быть включены в правила адресации сети. 2. Управление доступом к сети. Шлюзы определяются как места, где входящий и исходящий трафик сети организации, передается в другую сеть. Несмотря на то, что в правилах предполагается иметь только общие формулировки, все-таки можно разработать правила подключения к Internet, доступа к входящим/исходящим телефонным каналам, а также других внешних подключений. В правилах использования виртуальных частных сетей (VPN) и экстрасетей определено, каким образом сеть организации использует общедоступную сеть. Эти правила создают впечатление, что приняты все надлежащие меры по защите
информации. Можно записать в правилах требования того, чтобы все вспомогательные шлюзовые системы были аутентифицированы в сети, либо вся информация от вспомогательных систем при прохождении через шлюз была аутентифицирована. Правила должны определять особые соображения для вспомогательных систем, для которых отсутствуют требования по аутентификации либо эти требования недостаточно жесткие. 3. Безопасность регистрации. Имена пользователей С помощью имен пользователей определяется, кто или что получает доступ к сети или пытается получить доступ. Пользовательские имена могут являться источником информации, поэтому благоразумней использовать пользовательские имена, привязанные к фамилии, имени, отчеству пользователя, а не к его функциональным обязанностям. В правилах должно быть отражено, что
делать с пользовательскими именами, назначенными операционной системой при ее установке. Имена приглашенных пользователей и пользователей, не являющихся сотрудниками организации, должны особо тщательно контролироваться. В правила присвоения таких имен необходимо включить требования по контролю за ними и их аннулированию. Регистрационные баннеры могут выглядеть вполне безобидными, но они могут нести информацию об операционной среде, которая может быть использована теми, кто захочет попытаться взломать систему и сеть. Можно записать в правила требование ограничить информацию, выводимую в баннере, или записать просто формулировку о неразглашении. В правила необходимо включить соображения о многократных/однократных сеансах идентификации, а также требования, касающиеся систем положительной идентификации. Протоколирование как успешных, так и безуспешных попыток зарегистрироваться в системе может быть использовано средствами обнаружения вторжений. Добавление примечания о времени и дате последней регистрации в системе, которое сможет просматривать пользователь, создаст новый уровень
отчетности о нарушениях безопасности. В правила ограничения числа сеансов регистрации необходимо добавить требование автоматического выхода из системы (по истечении промежутка времени, по времени суток и т.п.), при этом важная информация должна оставаться доступной без разрегистрации. Кроме того, необходимо ввести предписания тем, кто имеет доступ к важной информации, выходить из системы при оставлении рабочих станций без присмотра. Правила администрирования пользовательского доступа могут предписывать минимальный уровень требований для управления назначением и распределением пользовательских имен. Сведение к минимуму требований, включенных в правила, дает возможность разрабатывать дополнительные инструкции в том случае, если необходимо расширить круг требований, но при этом разрешает администраторам
при необходимости расширять список пользовательских имен. Правила работы в привилегированном режиме - это тщательно расписанные требования, на основании которых разрабатываются инструкции, определяющие требования к доступу в систему, а также требования контроля за предоставлением привилегий. 4. Пароли. Правила, относящиеся к действующим паролям, следят за структурой пароля и сроком его действия. Эти правила также запрещают использовать повторно старые пароли. Правило хранения паролей устанавливает, что пароли должны храниться таким образом, чтобы обычные пользователи не могли их считывать. Хранение паролей осуществляется операционной системой; также можно записать в правила, что защита, устанавливаемая системой по умолчанию, не может быть ослаблена. Правила назначения специальных паролей требуют менять или удалять пароли, установленные поставщиком по умолчанию, а также назначать и использовать принудительные пароли — когда кого-то принудили ввести пароль, включается сигнализация для правоохранительных органов. 5. В пользовательском интерфейсе для введения паролей необходимо учитывать использование алгоритмов, предоставляемых системой или системным программным обеспечением. Можно разработать правила, определяющие, что должно отображаться на экране, а также, как защитить пароли во время пересылки их в сеть. 6. Правила управления доступом определяют системы или ресурсы, доступ к которым должен контролироваться или ограничиваться. Поскольку эти правила довольно разнообразны, предлагается разработать отдельный документ для каждой части системы, которая имеет свой специфический доступ. Чтобы новые системы располагали соответствующими правилами управления доступом, необходимо записать в отдельное правило, что хранители информации обязаны разработать правила управления доступом к новой системе до ее инсталляции. 7. Средства телекоммуникации и удаленного доступа управляют удаленным доступом к сети служащих организации и другого, имеющего право доступа, персонала. В некоторых организациях вводят необязательные правила, регламентирующие использование разрешенного в данной операционной среде оборудования по выбору сотрудника организации. В других организациях компьютеры и оборудование предоставляются служащим компанией. Эти организации могут ввести правила, согласно которым поставляемое оборудование должно использоваться без изменени1 так, как оно было установлено. Пользователь не может вносить изменения. В правила управления защитой данных при удаленном доступе должно быть записано требование, что удаленный пользователь обеспечивает надлежащую защиту компьютерного оборудования и данных на дополнительных рабочих узлах. В этих же правилах должно быть записано, что организация является владельцем всей интеллектуальной собственности, используемой или созданной в среде удаленного доступа. Чтобы придать правилам удаленного доступа больше веса, можно включить в них конкретное предписание, чтобы служащие несли ответственность за поддержание структурированной рабочей среды, а также исполняли все инструкции, касающиеся безопасности удаленных систем (лицензирование программного обеспечения, создание резервных копий и т.д.). Правила эксплуатации средств телекоммуникации и удаленного доступа определяют режим работы модемов и, если используется, туннелирования Internet. Этими же правилами регламентируется распределение телефонных номеров для телефонных линий, а также расширенная аутентификация для доступа любого типа.
