поиска на warning.dp.ua
  

 

Справочник по безопасности сетевого узла

Зам. зав. кафедры "Телекоммуникационные сети и системы" МФТИ
Зам.зав. кафедры Информатики ФНТИ МФТИ
Нач. лаб. Инфокоммуникационных технологий
Института Теоретической и Экспериментальной Физики (semenov@itep.ru)

(RFC-2196, B. Fraser, сентябрь 1997)

1. Введение

Этот документ предоставляет собой руководство для системных и сетевых администраторов в сфере определения безопасной работы в условиях подключения к Интернет. Он построен на основе RFC-1244 и является результатом коллективного труда большого коллектива авторов. Среди них: Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus-Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone (lorna@staff.singnet.com.sg), Edward.P.Lewis (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com), Russ Mundy (mundy@tis.com), Philip J. Nesser (pjnesser@martigny.ai.mit.edu), и Michael S. Ramsey (msr@interpath.net).

В дополнения к авторам документа следует упомянуть несколько его рецензентов предоставивших ценные комментарии. В этот список входят: Eric Luiijf (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl).

1.1. Цель данной работы

Данный справочник является руководством по определению процедур и политики безопасности для узлов, которые имеют связи с Интернет (однако, предлагаемая информация может оказаться полезной и для узлов, которые пока не соединены с Интернет). Данное руководство перечисляет моменты и факторы, которые следует рассмотреть, при определении своей собственной политики.

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

1.2 Аудитория

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

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

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

1.3. Определения

В данном руководстве под "узлом" подразумевается любая организация, которая имеет ЭВМ или сетевые ресурсы. Эти ресурсы могут включать в себя машины, используемые обычными клиентами, маршрутизаторы, терминальные серверы, персональные ЭВМ или другие устройства, которые имею доступ к Интернет. Узел может быть конечным пользователем Интернет-услуг или сервис провайдером, таким как промежуточная сеть. Однако основное внимание в этом руководстве уделено конечным пользователям Интернет-услуг. Мы предполагаем, что узел имеет возможность определять политику и процедуры для себя с согласия и при поддержке владельцев ресурсов. "Интернет" объединение тысяч сетей, связанных друг с другом посредством общего набора технических протоколов, которые делают возможным для пользователей любой сети взаимодействие друг с другом, или использование услуг каких-то удаленных сетей (FYI 4, RFC 1594).

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

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

Термин "decision maker" относится к людям в узле, кто определяет или утверждает политику. Это часто (но не всегда) люди, владеющие ресурсами.

1.4. Смежные обстоятельства

Рабочая группа справочника по сетевой безопасности работает над справочником по Интернет безопасности. Он представляет собой практическое руководство для помощи пользователям в защите их информации и ресурсов.

1.5. Базовый подход

Это руководство написано, чтобы создать базовое руководство для разработки системы безопасности для вашего узла. Одним из общих подходов сформулирован Файтесом и др. [Fites 1989] и включает в себя следующие шаги:

  1. Определение того, что вы пытаетесь защитить.
  2. Выявление того, от чего вы пытаетесь защититься.
  3. Выявление того, откуда и какие исходят угрозы.
  4. Осуществление мер, которые должны защитить ваши данные и систему эффективным образом.
  5. Постоянное отслеживание процесса и внесение улучшений всякий раз, когда обнаруживаются слабости.

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

1.6. Оценка риска

1.6.1. Общее обсуждение

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

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

Полный анализ рисков находится за пределами задач данного документа. [Fites 1989] и [Pfleeger 1989] рассмотрели некоторые подходы к данной теме. Однако имеется два пункта анализа риска, которые будут кратко рассмотрены в последующих секциях:

  1. Идентификация защищаемых объектов
  2. Идентификация угроз

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

1.6.2. Идентификация защищаемых объектов

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

Список общих категорий был предложен Пфлегером [Pfleeger 1989]:

(1) Оборудование: CPU, карты, клавиатуры, терминалы, рабочие станции, персональные ЭВМ, принтеры, дисковые драйвы, коммуникационные линии, терминальные серверы, маршрутизаторы.
(2) Программы: тексты программ, объектные модули, утилиты, диагностические программы, операционные системы, коммуникационные программы.
(3) Данные: во время исполнения, записанные в реальном времени, архивированные off-line, резервные копии, журнальные записи, базы данных, при передаче через транспортную среду.
(4) Люди: пользователи, администраторы, группа поддержки оборудования.
(5) Документация: на программы, оборудование, системы, локальные административные процедуры.
(6) Материалы: бумага, формы, ленты, магнитные носители.

1.6.3. Идентификация угроз

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

(1) Неавторизованный доступ к ресурсам и/или информации
(2) Непреднамеренное и/или неавторизованное раскрытие информации
(3) Отказ в обслуживании (Denial of service)

2. Политики безопасности

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

2.1. Что такое политика безопасности и зачем она нужна?

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

(1) предлагаемые услуги против предоставляемой безопасности - каждая услуга, предлагаемая пользователям, несет в себе определенные риски безопасности. Для некоторых услуг риск перевешивает привлекательные их стороны, и администратор может принять решение их запретить, а не защищать.
(2) простота использования против безопасности - Простейшая система использования позволит доступ любому пользователю и не потребует пароля; то есть, лишена какой-либо безопасности. Требование пароля делает систему менее удобной, но более безопасной. Требование одноразового пароля, формируемого аппаратно еще менее удобно для использования, но много безопаснее.
(3) стоимость безопасности против риска потери - существует много различных издержек безопасности: денежные (т.e., цену покупки оборудования и программ, обеспечивающих безопасность, например, firewall и генератора одноразовых паролей), рабочие характеристики (т.e., время необходимое для шифрования и дешифрования), а также простота использования (как упомянуто выше). Существует также много уровней риска: потеря конфиденциальности (т.e., чтение информации неавторизованными лицами), потеря данных (т.e., искажение или стирание информации), и потеря услуги (например, заполнение памяти, использование вычислительных ресурсов, и отказ в доступе к сети). Каждый тип издержек должен быть оценен и сопоставлен каждым типом потерь.

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