4.3. Ролевое управление доступом

Модель ролевого управления доступом (RBAC – Role-based Access Control), также называемая недискреционным управлением доступом (Nondiscretionary Access Control), использует централизованно администрируемый набор контролей, предназначенных для определения порядка взаимодействия субъекта с объектом. Этот тип модели разрешает доступ к ресурсам, основываясь на роли пользователя в компании. Это называют недискреционным подходом, поскольку назначение пользователю роли является неизбежным. Это означает, что если вам в компании назначена роль «Подрядчик», вы ничего с этим сделать не можете. Вы не определяете самостоятельно, какая роль вам будет назначена.

Более традиционное администрирование прав доступа основано на модели DAC, в которой управление доступом происходит на уровне объекта с использованием ACL. Этот подход более сложен, т.к. администратор должен перевести организационную политику компании в разрешения при настройке ACL. С ростом количества объектов и пользователей в компании у многих пользователей появляются (или остаются после изменения обязанностей) права доступа к некоторым ресурсам, которые им не требуются для работы. Это нарушает принцип минимальных привилегий и увеличивает риски компании. Подход RBAC позволяет избежать этого, так как разрешения управляются на уровне должностных ролей. В модели RBAC роль определяется в терминах операций и задач, которые она выполняет, тогда как в модели DAC описывается, какие субъекты могут иметь доступ к каким объектам.

Например, нам нужна роль аналитика. Мы разрабатываем эту роль, позволяя ей иметь доступ ко всем видам продукции и данным тестирования, а также, что более важно, определяем задачи и операции, которые эта роль может выполнять с этими данными. Когда пользователь, которому присвоена эта роль «Аналитик», делает запрос на доступ к новым результатам тестирования на файловом сервере, операционная система в фоновом режиме просматривает уровень доступа роли, прежде чем эта операция будет разрешена.

ПРИМЕЧАНИЕ. Введение ролей показывает разницу между правами, назначенными явно и неявно. В явном виде права и разрешения назначаются непосредственно конкретному пользователю. В неявном виде они назначаются роли или группе, а пользователь просто наследует эти полномочия.

Модель RBAC лучше всего подходит для компаний с большой «текучестью» кадров. Если увольняется сотрудник, которому была назначена определенная роль, то новому сотруднику, который займет его место, просто назначается та же роль. Таким образом, администратору не нужно постоянно вносить изменения в ACL отдельных объектов. Ему достаточно создать определенные роли, настроить необходимые этим ролям права и разрешения, а затем назначить пользователям эти роли.

Ядро RBAC

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

Имеются отношения «многие-ко-многим» между отдельными пользователями и привилегиями.

Сессия является соответствием между пользователем и подмножеством назначенных ему ролей.

Применяется традиционное, но более надежное управление доступом на основе групп.

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

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

Иерархический RBAC

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

1. Ролевые отношения определяют членство пользователя в группах и наследование привилегий. Например, роль «Медсестра» может получить доступ к одному набору файлов, а роль «Лаборант» – к другому. Роль «Доктор» наследует разрешения и права доступа из обеих этих ролей и имеет дополнительные права, назначенные непосредственно роли «Доктор». Таким образом, иерархия накапливает права и разрешения различных ролей.

2. Отражает организационную структуру и функциональные разграничения.

3. Существует два типа иерархий:

Ограниченные иерархии. Доступен только один уровень иерархии (например, Роль 1 наследует права Роли 2, но не других ролей).

Обычные иерархии. Доступно много уровней иерархии (например, Роль 1 наследует права Роли 2 и Роли 3).

Иерархии позволяют структурировать роли, естественным образом отражая разграничение полномочий и обязанностей в компании. Иерархии ролей определяют порядок наследования между ролями. Эта модель позволяет организовать разделение обязанностей (separation of duties).

Статическое разделение обязанностей (SSD – Static Separation of Duty) посредством RBAC. Это может использоваться для предотвращения мошенничества, предоставляя постоянный ограниченный набор привилегий (например, пользователь не может быть одновременно членом групп «Кассир» и «Контролер»).

Динамическое разделение обязанностей (DSD – Dynamic Separation of Duties) посредством RBAC. Это может использоваться для предотвращения мошенничества, предоставляя ограничение набора возможных привилегий в рамках одной сессии (например, пользователь не может в рамках одной сессии использовать права «Кассира» и «Контролера», хотя он может быть одновременно членом обеих этих групп). Это немного сложнее. Рассмотрим пример: пользователь является одновременно членом групп «Кассир» и «Контролер», однако, если он входит в систему в качестве кассира, ему недоступны права контролера и наоборот.

Управление доступом в модели RBAC может происходить следующими способами:

• Не-RBAC. Назначение прав пользователям производится напрямую в приложениях, роли не используются.

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

• Гибридное RBAC. Пользователям назначены роли, связанные с различными приложениями. Этим ролям назначены только выбранные права.

• Полное RBAC. Пользователям назначены корпоративные роли.

RBAC, MAC, DAC. Много путаницы возникает в отношении того, является ли RBAC разновидностью модели DAC или MAC. Различные источники содержат разную информацию на этот счет, но фактически RBAC является самостоятельной моделью. В 1960-х – 1970-х годах американские военные и NSA проводили много исследований модели MAC. Появившаяся в то же время модель DAC имеет свои корни в академических и коммерческих лабораториях. Модель RBAC, которая начала набирать популярность в 1990-е годы, может использоваться в комбинации с системами MAC и DAC. Получить наиболее актуальную информацию о модели RBAC можно по адресу: http://csrc.nist.gov/rbac, где размещены документы с описанием стандарта RBAC и независимой модели, с целью прояснить прояснения этой постоянной путаницы.

Модели управления доступом. Важно понимать основные характеристики трех моделей управления доступом:

• DAC – владельцы данных решают, кто имеет доступ к ресурсам. Политика безопасности реализуется с помощью ACL.

• MAC – политика безопасности реализуется операционной системой посредством меток безопасности.

• RBAC – решения о предоставлении доступа принимаются системой на основании ролей и/или должностей субъектов.

ПРИМЕЧАНИЕ. В наше время, конфиденциальность многих типов данных нуждается в защите, поэтому многие компании имеют в штате офицеров безопасности конфиденциальных данных и разрабатывают политики конфиденциальности. Современные модели управления доступом (MAC, DAC, RBAC) сами по себе не обеспечивают защиту критичных данных, вместо этого они ограничивают функции, которые пользователи могут выполнять с этими данными. Например, всем менеджерам может быть предоставлен доступ к папке, содержащей конфиденциальную информацию, но более детальные права доступа могут указывать, что они могут читать информацию о домашнем адресе клиента, но не видят его паспортные данные. Это называется ролевым управлением доступом с учетом конфиденциальности (Privacy Aware Role Based Access Control).

(19 вопрос) Orange Book

Критерии оценки надежных компьютерных систем ("Оранжевая книга" Министерства обороны США)

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

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

Основные понятия

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

Степень доверия, или надежность систем, оценивается по двум основным критериям:

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

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

Гарантированность показывает, насколько корректны механизмы, отвечающие за проведение в жизнь политики безопасности. Гарантированность можно считать пассивным компонентом защиты, надзирающим за самими защитниками.

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

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

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

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

От монитора обращений требуется выполнение трех свойств:

Изолированность. Монитор должен быть защищен от отслеживания своей работы;

Полнота. Монитор должен вызываться при каждом обращении, не должно быть способов его обхода;

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

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

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

Основные элементы политики безопасности

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

Произвольное управление доступом;.

Безопасность повторного использования объектов;

Метки безопасности;

Принудительное управление доступом.

Ниже следует подробное рассмотрение перечисленных элементов.

Произвольное управление доступом

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

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

Очевидно, прямолинейное представление подобной матрицы невозможно (поскольку она очень велика), да и не нужно (поскольку она разрежена, то есть большинство клеток в ней пусты). В операционных системах более компактное представление матрицы доступа основывается или на структурировании совокупности субъектов (владелец/группа/прочие в ОС UNIX), или на механизме списков управления доступом, то есть на представлении матрицы по столбцам, когда для каждого объекта перечисляются субъекты вместе с их правами доступа. За счет использования метасимволов можно компактно описывать группы субъектов, удерживая тем самым размеры списков управления доступом в разумных рамках.

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

Безопасность повторного использования объектов

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

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

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

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

Метки безопасности

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

Согласно "Оранжевой книге", метки безопасности состоят из двух частей — уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:

совершенно секретно;

секретно;

конфиденциально;

несекретно.

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

Категории образуют неупорядоченный набор. Их назначение — описать предметную область, к которой относятся данные. В военном окружении каждая категория может соответствовать, например, определенному виду вооружений. Механизм категорий позволяет разделить информацию по отсекам, что способствует лучшей защищенности. В Разд. Принудительное управление доступом мы подробно рассмотрим правила принудительного управления доступом, здесь же отметим, что субъект не может получить доступ к "чужим" категориям, даже если его уровень благонадежности — "совершенно секретно". Специалист по танкам не узнает тактико-технические данные самолетов.

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

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

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

Принудительное управление доступом

Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта.

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

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

Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение "разрешить доступ к объекту X еще и для пользователя Y". Конечно, можно изменить метку безопасности пользователя Y, но тогда он скорее всего, получит доступ ко многим дополнительным объектам, а не только к X.

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

Подотчетность

Если понимать политику безопасности узко, то есть как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности — в каждый момент времени знать, кто работает в системе и что он делает. Средства подотчетности делятся на три категории:

Идентификация и аутентификация;

Предоставление надежного пути;

Анализ регистрационной информации.

Рассмотрим эти категории подробнее.

Идентификация и аутентификация

Каждый пользователь, прежде чем получить право совершать какие-либо действия в системе, должен идентифицировать себя. Обычный способ идентификации — ввод имени пользователя при входе в систему. В свою очередь, система должна проверить подлинность личности пользователя, то есть что он является именно тем, за кого себя выдает. Стандартное средство проверки подлинности (аутентификации) — пароль, хотя в принципе могут использоваться также разного рода личные карточки, биометрические устройства (сканирование роговицы или отпечатков пальцев) или их комбинация.

Идентификация и аутентификация — первый и важнейший программно-технический рубеж информационной безопасности. Если не составляет проблемы получить доступ к системе под любым именем, то другие механизмы безопасности, например, управление доступом, очевидно, теряют смысл. Очевидно и то, что без идентификации пользователей невозможно протоколирование их действий. В силу перечисленных причин проверке подлинности должно придаваться первостепенное значение. Существует целая серия публикаций правительственных ведомств США, разъясняющих вопросы аутентификации и, в частности, проблемы, связанные с паролями. Например, декларируется, что пользователю должно быть позволено менять свой пароль, что пароли, как правило, должны быть машинно-сгенерированными (а не выбранными "вручную"), что пользователю должна предоставляться некоторая регистрационная информация (дата и время последнего входа в систему и т.п.).

Предоставление надежного пути

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

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

Анализ регистрационной информации

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

Вход в систему (успешный или нет);

Выход из системы;

Обращение к удаленной системе;

Операции с файлами (открыть, закрыть, переименовать, удалить);

Смена привилегий или иных атрибутов безопасности (режима доступа, уровня благонадежности пользователя и т.п.).

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

Если фиксировать все события, объем регистрационной информации, скорее всего, будет расти слишком быстро, а ее эффективный анализ станет невозможным. "Оранжевая книга" предусматривает наличие средств выборочного протоколирования, как в отношении пользователей (внимательно следить только за подозрительными), так и в отношении событий.

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

При протоколировании события записывается по крайней мере следующая информация:

Дата и время события;

Уникальный идентификатор пользователя — инициатора действия;

Тип события;

Результат действия (успех или неудача);

Источник запроса (например, имя терминала);

Имена затронутых объектов (например, открываемых или удаляемых файлов);

Описание изменений, внесенных в базы данных защиты (например, новая метка безопасности объекта);

Метки безопасности субъектов и объектов события.

Необходимо подчеркнуть важность не только сбора информации, но и ее регулярного и целенаправленного анализа. В плане анализа выгодное положение занимают средства аудита СУБД, поскольку к регистрационной информации могут естественным образом применяться произвольные SQL-запросы. Следовательно, появляется возможность для выявления подозрительных действий применять сложные эвристики.

Гарантированность

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

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

Операционная гарантированность

Операционная гарантированность включает в себя проверку следующих элементов:

Архитектура системы.

Целостность системы.

Анализ тайных каналов передачи информации.

Надежное администрирование.

Надежное восстановление после сбоев.

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

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

В принципе меры безопасности не обязательно должны быть заранее встроены в систему — достаточно принципиальной возможности дополнительной установки защитных продуктов. Так, сугубо ненадежная система MS-DOS может быть улучшена за счет средств проверки паролей доступа к компьютеру и/или жесткому диску, за счет борьбы с вирусами путем отслеживания попыток записи в загрузочный сектор CMOS-средствами и т.п. Тем не менее, по-настоящему надежная система должна изначально проектироваться с упором на механизмы безопасности.

Среди архитектурных решений, предусматриваемых "Оранжевой книгой", упомянем следующие:

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

Защита различных процессов от взаимного влияния за счет механизма виртуальной памяти.

Наличие средств управления доступом.

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

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

Сегментация (в частности, сегментация адресного пространства процессов) как средство повышения надежности компонентов.

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

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

Различают тайные каналы с памятью и временные (ударение на "ы"). Тайные каналы с памятью используют изменения хранимых объектов. Тайным знаком может быть размер файла, имя файла (составленное, например, из входного имени и пароля атакуемого субъекта), число пробелов между словами и т.д. Тайный канал считается быстрым, если с его помощью можно передавать 100 или более бит в секунду.

Временные каналы передают информацию за счет изменения временных характеристик процессов — времени обработки запроса, например. Когда-то давно мой товарищ, Андрей Ходулев, написал программу, угадывавшую мысли. Точнее, она отгадывала задуманное число (от 1 до 4). Человеку предлагалось в уме проделать определенные вычисления, естественно, не сообщая программе ответ. "Соль" программы состояла в том, что для разных чисел некоторые вычисления проделать легко, а для других — трудно. Анализируя распределение времени, затраченного на вычисления, программа угадывала задуманное число. Человек, сам того не ведая, передавал программе информацию по тайному временному каналу.

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

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

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

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

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

Технологическая гарантированность

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

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

Верификация описания архитектуры — это выполненное автоматически формальное доказательство того, что архитектура системы соответствует сформулированной политике безопасности. Национальный центр компьютерной безопасности США располагает двумя системами для проведения подобных формальных доказательств — Gypsy Verification Environment (GVE) компании Computational Logic, Inc. и Formal Development Methodology (FDM) корпорации UNISYS.

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

Конфигурационное управление давно и широко используется разработчиками программного обеспечения отнюдь не только (и не столько) по соображениям безопасности. Специфика подхода "Оранжевой книги" — в тотальном контроле за изменениями и в строгой дисциплине их проведения.

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

Проверочные меры применяются клиентом, чтобы убедиться, что он получил именно то, что заказал, и что система не подверглась нелегальным изменениям. Клиент должен убедиться, что полученный им продукт — точная копия эталонного варианта, имеющегося у поставщика. Для этого существует целый спектр методов, начиная от проверок серийных номеров аппаратных компонентов и кончая верификацией контрольных сумм программ и данных. Следует отметить, что современная практика поставки программного обеспечения на CD-ROM'ах существенно затрудняет (по сравнению с дискеточным вариантом) внесение нелегальных изменений.

Документация

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

Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома:

Руководство пользователя по средствам безопасности.

Руководство администратора по средствам безопасности.

Тестовая документация.

Описание архитектуры.

Разумеется, на практике требуется еще по крайней мере одна книга — письменное изложение политики безопасности данной организации.

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

Как входить в систему? Как вводить имя и пароль? Как менять пароль? Как часто это нужно делать? Как выбирать новый пароль?

Как защищать файлы и другую информацию? Как задавать права доступа к файлам? Из каких соображений это нужно делать?

Как импортировать и экспортировать информацию, не нарушая правил безопасности?

Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?

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

Типичное оглавление Руководства администратора включает в себя следующие пункты:

Каковы основные защитные механизмы?

Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?

Как администрировать средства произвольного управления доступом? Как защищать системную информацию? Как обнаруживать слабые места?

Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?

Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности?

Как генерировать новую, переконфигурированную надежную вычислительную базу?

Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?

Как разделить обязанности системного администратора и оператора?

Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того (вернее, перед тем), тестовая документация должна содержать план тестирования и условия, налагаемые на тестовое окружение.

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

Классы безопасности

"Критерии" Министерства обороны США открыли путь к ранжированию информационных систем по степени надежности. В "Оранжевой книге" определяется четыре уровня безопасности (надежности) — D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он содержит две подсистемы управления доступом для ПК. По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности — C1, C2, B1, B2, B3, A1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, мы, следуя [26] , будем выписывать лишь то новое, что присуще данному классу, группируя требования в согласии с предшествующим изложением.

(20 вопрос) ISO 27000

Семейство Международных Стандартов на Системы Управления Информационной Безопасностью 27000 разрабатывается ISO/IEC JTC 1/SC 27. Это семейство включает в себя Международные стандарты, определяющие требования к системам управления информационной безопасностью, управление рисками, метрики и измерения, а также руководство по внедрению.

Для этого семейства стандартов используется последовательная схема нумерации, начиная с 27000 и далее.ISO27000

ISO/IEC 27000:2009 Information technology. Security techniques. Information security management systems. Overview and vocabulary - Определения и основные принципы. Выпущен в июле 2009 г.

ISO27001

ISO/IEC 27001:2005/BS 7799-2:2005 Information technology. Security techniques. Information security management systems. Requirements - Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования. Выпущен в октябре 2005 г.

ISO27002 ISO/IEC 27002:2005, BS 7799-1:2005,BS ISO/IEC 17799:2005 Information technology. Security techniques. Code of practice for information security management - Информационные технологии. Методы обеспечения безопасности. Практические правила управления информационной безопасностью. Выпущен в июне 2005 г.

ISO27003 ISO/IEC 27003:2010 Information Technology. Security Techniques. Information Security Management Systems Implementation Guidance - Руководство по внедрению системы управления информационной безопасностью. Выпущен в январе 2010 г.

ISO27004 ISO/IEC 27004:2009 Information technology. Security techniques. Information security management. Measurement - Измерение эффективности системы управления информационной безопасностью. Выпущен в январе 2010 г.

ISO27005 ISO/IEC 27005:2008 Information technology. Security techniques. Information security risk management - Информационные технологии. Методы обеспечения безопасности. Управление рисками информационной безопасности. Выпущен в июне 2008 г.

ISO27006 ISO/IEC 27006:2007 Information technology. Security techniques. Requirements for bodies providing audit and certification of information security management systems - Информационные технологии. Методы обеспечения безопасности. Требования к органам аудита и сертификации систем управления информационной безопасностью. Выпущен в марте 2007 г.

ISO27007 ISO/IEC 27007 Information technology. Security techniques. Guidelines for Information Security Management Systems auditing (FCD) - Руководство для аудитора СУИБ. Проект находится в финальной стадии. Выпуск запланирован на 2011 год.

ISO27008 ISO/IEC 27008 Information technology. Security techniques. Guidance for auditors on ISMS controls (DRAFT) - Руководство по аудиту механизмов контроля СУИБ. Будет служить дополнением к стандарту ISO 27007. Выпуск запланирован в конце 2011 года.

ISO27010 ISO/IEC 27010 Information technology. Security techniques. Information security management for inter-sector communications (DRAFT) - Управление информационной безопасностью при коммуникациях между секторами. Стандарт будет состоять из нескольких частей, предоставляющих руководство по совместному использованию информации о рисках информационной безопасности, механизмах контроля, проблемах и/или инцидентах, выходящей за границы отдельных секторов экономики и государств, особенно в части, касающейся "критичных инфраструктур".

ISO27011 ISO/IEC 27011:2008 Information technology. Security techniques. Information security management guidelines for telecommunications organizations based on ISO/IEC 27002 - Руководство по управлению информационной безопасностью для телекоммуникаций. Выпущен в мае 2009 г.

ISO27013 ISO/IEC 27013 IT Security. Security techniques. Guideline on the integrated implementation of ISO/IEC 20000-1 and ISO/IEC 27001 (DRAFT) - Руководство по интегрированному внедрению ISO 20000 и ISO 27001. Выпуск запланирован в 2011 году.

ISO27014 ISO/IEC 27014 Information technology. Security techniques. Information security governance framework (DRAFT) - Базовая структура управления информационной безопасностью. Проект находится в разработке.

ISO27015 ISO/IEC 27015 Information technology. Security techniques. Information security management systems guidelines for financial and insurance sectors (DRAFT) - Руководство по внедрению систем управления информационной безопасностью в финансовом и страховом секторе. Проект проходит начальную стадию обсуждения.

ISO27031 ISO/IEC 27031 Information technology. Security techniques. Guidelines for information and communications technology readiness for business continuity (FDIS) - Руководство по обеспечению готовности информационных и коммуникационных технологий к их использованию для управления непрерывностью бизнеса. Проект находится в финальной стадии. Выпуск запланирован в начале 2011 года.

ISO27032 ISO/IEC 27032 Information technology. Security techniques. Guidelines for cybersecurity (2nd CD) - Руководство по обеспечению кибербезопасности. Проект находится в начальной стадии разработки.

ISO27033

ISO 27033 заменит известный международный стандарт сетевой безопасности ISO 18028, состоящий из пяти частей. Новый стандарт возможно будет включать в себя более 7 частей. Проекты частей 2-7 ISO 27033 надятся в разной стадии готовности.

ISO/IEC 27033-1:2009 Information technology. Security techniques. Network security. Overview and concept - Основные концепции управления сетевой безопасностью. Выпущен в январе 2010 года.

ISO/IEC 27033-2 Guidelines for the design and implementation of network security (CD) - Руководство по проектированию и внедрению системы обеспечения сетевой безопасности.

ISO/IEC 27033-3 Reference networking scenarios - threats, design techniques and control issues (CD, revised title) - Базовые сетевые сценарии - угрозы, методы проектирования и механизмы контроля.

ISO/IEC 27033-4 Securing communications between networks using security gateways - threats, design techniques and control issues (NP, revised title) - Обеспечение безопасности межсетевых взаимодействий при помощи шлюзов безопасности - угрозы, методы проектирования и механизмы контроля.

ISO/IEC 27033-5 Securing Virtual Private Networks - threats, design techniques and control issues (WD) - Обеспечение безопасности Виртуальных Частных Сетей - угрозы, методы проектирования и механизмы контроля.

ISO/IEC 27033-6 IP convergence (NP) - Конвергенция в IP сетях (Определение угроз, методов проектирования и механизмов контроля в IP сетях с конвергенцией данных, голоса и видео).

ISO/IEC 27033-7 Guidelines for securing wireless networking - Risks, design techniques and control issues (NP) - Руководство по обеспечению безопасности беспроводных сетей - Риски, методы проектирования и механизмы контроля.

ISO/IEC 27033-8+ Guidelines for securing [insert other network security aspects] - Risks, design techniques and control issues (возможно будут разработаны дополнительные части).

ISO27034

ISO/IEC 27034 Information technology. Security techniques. Application security (DRAFT) - Безопасность приложений. Проекты различных частей стандарта ISO 27034 находятся в различной стадии разработки.

ISO/IEC 27034-1 Information technology. Security techniques. Application security overview and concepts (FCD) - Обзор и основные концепции в области обеспечения безопасности приложений.

ISO/IEC 27034-2 Organization Normative Framework (draft) - Нормативная база организации.

ISO/IEC 27034-3 Application Security Management Process (pre-draft) - Процесс управления безопасностью приложений.

ISO/IEC 27034-4 Application security validation (pre-draft) - Оценка безопасности приложений.

ISO/IEC 27034-5 Protocols and application security control data structure (pre-draft) - Протоколы и структура управляющей информации для обеспечения безопасности приложений (XML схема).

ISO/IEC 27034-6 Security guidance for specific applications (pre-draft) - Руководство по обеспечению безопасности конктретных приложений.

ISO27035 ISO/IEC 27035 Information technology. Security techniques. Security incident management (DRAFT) - Управление инцидентами безопасности. Проект находится в разработке и, после выпуска, заменит технический отчет ISO TR 18044.

ISO27036 ISO/IEC 27036 IT Security. Security techniques. Guidelines for security of outsourcing (DRAFT) - Руководство по аутсорсингу безопасности. Выпуск запланирован на 2012 год.

ISO27037 ISO/IEC 27037 IT Security. Security techniques. Guidelines for identification, collection and/or acquisition and preservation of digital evidence (DRAFT) - Руководство по идентификации, сбору и/или получению и обеспечению сохранности цифровых свидетельств. Проект разрабатывается на базе британского стандарта BS 10008:2008 Evidential weight and legal admissibility of electronic information. Specification.

ISO27799 ISO 27799:2008 Health informatics. Information security management in health using ISO/IEC 27002 - Управление информационной безопасностью в сфере здравоохранения. Опубликован в 2008 году.

Разработчики международных стандартов

ISO (Международная Организация по Стандартизации) и IEC (Международная Электротехническая Комиссия) формируют специализированную систему всемирной стандартизации. Государственные органы, являющиеся членами ISO или IEC, участвуют в разработке Международных Стандартов через технические комитеты, созданные соответствующей организацией для стандартизации отдельных областей технической деятельности. Технические комитеты ISO и IEC сотрудничают в областях взаимных интересов. Другие международные организации, правительственные и не правительственные, совместно с ISO и IEC также принимают участие в этой работе. В области информационных технологий, ISO и IEC организован совместный технический комитет, ISO/IEC JTC 1. Основной задачей совместного технического комитета является подготовка Международных Стандартов. Проекты Международных Стандартов принятые совместным техническим комитетом передаются в государственные органы для голосования. Публикация в качестве Международного Стандарта требует одобрения не менее 75 процентов проголосовавших государственных органов. Международные Стандарты проектируются в соответствии с правилами, установленными Директивами ISO/IEC, Часть 2.

(21 вопрос) Аудит ИБ

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

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

Необходимость в этом может возникнуть в разных ситуациях:

если меняется стратегия компании;

при слиянии или поглощении;

когда происходят значительные изменения в организационной структуре или смена руководства;

при появлении новых внутренних или внешних требований в области информационной безопасности;

в случае значительных изменений бизнес-процессов или ИТ-инфраструктуры.

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

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

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

В процессе аудита проводятся:

• анализ организационно-распорядительных документов организации;

• интервью с сотрудниками организации: представителями бизнес-подразделений, администраторами и разработчиками информационных систем, специалистами по информационной безопасности;

• осмотр технологических и офисных помещений с точки зрения обеспечения физической безопасности ИТ-инфраструктуры;

• анализ конфигурационных настроек оборудования и ПО;

• аудит с использованием специальных технических средств (сканеров анализа защищенности, средств контроля утечек информации и т.п.);

• тестирование на проникновение;

• оценка знаний сотрудников организации в области информационной безопасности.

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

Результаты аудита:

• анализ угроз, которые могут быть реализованы, через обнаруженные уязвимости;

• качественная или количественная оценка рисков ИБ;

• оценка соответствия актуальным требованиям;

• оценка соответствия лучшим практикам и стандартам в области ИБ;

• стратегия обеспечения ИБ;

• рекомендации, которые должны быть выполнены для повышения уровня защищенности организации;

• план реализации разработанных рекомендаций с бюджетной оценкой;

• техническое задание на внедрение рекомендуемых мер по обеспечению информационной безопасности.

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

(22 вопрос) Аутентификация и Авторизация

Основные понятия

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

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

(Заметим в скобках, что происхождение русскоязычного термина "аутентификация" не совсем понятно. Английское "authentication" скорее можно прочитать как "аутентикация"; трудно сказать, откуда в середине взялось еще "фи" - может, из идентификации? Тем не менее, термин устоялся, он закреплен в Руководящих документах Гостехкомиссии России, использован в многочисленных публикациях, поэтому исправить его уже невозможно.)

Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней (взаимной). Пример односторонней аутентификации - процедура входа пользователя в систему.

В сетевой среде, когда стороны идентификации/аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта:

что служит аутентификатором (то есть используется для подтверждения подлинности субъекта);

как организован (и защищен) обмен данными идентификации/аутентификации.

Субъект может подтвердить свою подлинность, предъявив по крайней мере одну из следующих сущностей:

нечто, что он знает (пароль, личный идентификационный номер, криптографический ключ и т.п.);

нечто, чем он владеет (личную карточку или иное устройство аналогичного назначения);

нечто, что есть часть его самого (голос, отпечатки пальцев и т.п., то есть свои биометрические характеристики).

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

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

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

Таким образом, необходимо искать компромисс между надежностью, доступностью по цене и удобством использования и администрирования средств идентификации и аутентификации.

Любопытно отметить, что сервис идентификации / аутентификации может стать объектом атак на доступность. Если система сконфигурирована так, что после определенного числа неудачных попыток устройство ввода идентификационной информации (такое, например, как терминал) блокируется, то злоумышленник может остановить работу легального пользователя буквально несколькими нажатиями клавиш.

Парольная аутентификация

Главное достоинство парольной аутентификации - простота и привычность. Пароли давно встроены в операционные системы и иные сервисы. При правильном использовании пароли могут обеспечить приемлемый для многих организаций уровень безопасности. Тем не менее, по совокупности характеристик их следует признать самым слабым средством проверки подлинности.

Чтобы пароль был запоминающимся, его зачастую делают простым (имя подруги, название спортивной команды и т.п.). Однако простой пароль нетрудно угадать, особенно если знать пристрастия данного пользователя. Известна классическая история про советского разведчика Рихарда Зорге, объект внимания которого через слово говорил "карамба"; разумеется, этим же словом открывался сверхсекретный сейф.

Иногда пароли с самого начала не хранятся в тайне, так как имеют стандартные значения, указанные в документации, и далеко не всегда после установки системы производится их смена.

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

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

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

Тем не менее, следующие меры позволяют значительно повысить надежность парольной защиты:

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

управление сроком действия паролей, их периодическая смена;

ограничение доступа к файлу паролей;

ограничение числа неудачных попыток входа в систему (это затруднит применение "метода грубой силы");

обучение пользователей;

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

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

Одноразовые пароли

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

Наиболее известным программным генератором одноразовых паролей является система S/KEY компании Bellcore. Идея этой системы состоит в следующем. Пусть имеется односторонняя функция f (то есть функция, вычислить обратную которой за приемлемое время не представляется возможным). Эта функция известна и пользователю, и серверу аутентификации. Пусть, далее, имеется секретный ключ K, известный только пользователю.

На этапе начального администрирования пользователя функция f применяется к ключу K n раз, после чего результат сохраняется на сервере. После этого процедура проверки подлинности пользователя выглядит следующим образом:

сервер присылает на пользовательскую систему число (n-1);

пользователь применяет функцию f к секретному ключу K (n-1) раз и отправляет результат по сети на сервер аутентификации;

сервер применяет функцию f к полученному от пользователя значению и сравнивает результат с ранее сохраненной величиной. В случае совпадения подлинность пользователя считается установленной, сервер запоминает новое значение (присланное пользователем) и уменьшает на единицу счетчик (n).

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

Система S/KEY имеет статус Internet-стандарта (RFC 1938).

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

Сервер аутентификации Kerberos

Kerberos - это программный продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем.

Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты - пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.

Система Kerberos представляет собой доверенную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности.

Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило - клиент) посылает Kerberos запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание секретного ключа. Значит, клиент - именно тот, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) - они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи - вопрос отдельный.

Идентификация/аутентификация с помощью биометрических данных

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

Биометрией во всем мире занимаются очень давно, однако долгое время все, что было связано с ней, отличалось сложностью и дороговизной. В последнее время спрос на биометрические продукты, в первую очередь в связи с развитием электронной коммерции, постоянно и весьма интенсивно растет. Это понятно, поскольку с точки зрения пользователя гораздо удобнее предъявить себя самого, чем что-то запоминать. Спрос рождает предложение, и на рынке появились относительно недорогие аппаратно-программные продукты, ориентированные в основном на распознавание отпечатков пальцев.

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

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

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

Активность в области биометрии очень велика. Организован соответствующий консорциум (см. http://www.biometrics.org/), активно ведутся работы по стандартизации разных аспектов технологии (формата обмена данными, прикладного программного интерфейса и т.п.), публикуется масса рекламных статей, в которых биометрия преподносится как средство обеспечения сверхбезопасности, ставшее доступным широким массам.

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

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

(23 вопрос) Угрозы безопасности

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

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

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

Угроза нарушения конфиденциальности

Кража информации и ее распространение с помощью штатных средств связи либо скрытых каналов передачи: Email-Worm.Win32.Sircam — рассылал вместе с вирусными копиями произвольные документы, найденные на зараженном компьютере

Кража паролей доступа, ключей шифрования и пр.: любые трояны, крадущие пароли, Trojan-PSW.Win32.LdPinch.gen

Удаленное управление: Backdoor.Win32.NetBus, Email-Worm.Win32.Bagle (backdoor-функциональность)

Угроза нарушения целостности

Модификация без уничтожения (изменение информации): любой паразитирующий вирус

Модификация посредством уничтожения либо шифрации (удаление некоторых типов документов): Virus.DOS.OneHalf — шифрование содержимого диска, Virus.Win32.Gpcode.f — шифрует файлы с определенными расширениями, после чего самоуничтожается, оставляя рядом с зашифрованными файлами координаты для связи по вопросам расшифровки файлов

модификация путем низкоуровневого уничтожения носителя (форматирование носителя, уничтожение таблиц распределения файлов): Virus.MSWord.Melissa.w — 25 декабря форматирует диск C:

Угроза нарушения доступности

Загрузка каналов передачи данных большим числом пакетов: Net-Worm.Win32.Slammer — непрерывная рассылка инфицированных пакетов в бесконечном цикле

Любая деятельность, результатом которой является невозможность доступа к информации; различные звуковые и визуальные эффекты: Email-Worm.Win32.Bagle.p — блокирование доступа к сайтам антивирусных компаний

Вывод компьютера из строя путем уничтожения либо порчи критических составляющих (уничтожение Flash BIOS): Virus.Win9x.CIH — порча Flash BIOS

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

Заключение

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

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

(24,25 вопрос) Шифрование

Шифрова́ние — способ преобразования открытой информации в закрытую и обратно. Применяется для хранения важной информации в ненадёжных источниках или передачи её по незащищённым каналам связи. Шифрование подразделяется на процесс зашифровывания и расшифровывания.

В зависимости от алгоритма преобразования данных, методы шифрования подразделяются на гарантированной или временной криптостойкости.

В зависимости от структуры используемых ключей методы шифрования подразделяются на

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

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

Существуют следующие криптографические примитивы:

Симметричные схемы

• Шифры (блочные,потоковые)

• Хеш-функции

• ЭЦП

• Генераторы псевдослучайных чисел

• Примитивы идентификации

Асимметричные схемы

• Шифры

• ЭЦП

• Примитивы идентификации

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

Распространенные алгоритмы

AES (англ. Advanced Encryption Standard) - американский стандарт шифрования

ГОСТ 28147-89 — отечественный стандарт шифрования данных

DES (англ. Data Encryption Standard) - стандарт шифрования данных в США до AES

3DES (Triple-DES, тройной DES)

RC6 (Шифр Ривеста )

Twofish

IDEA (англ. International Data Encryption Algorithm)

SEED - корейский стандарт шифрования данных

Camellia - сертифицированный для использовании в Японии шифр

CAST (по инициалам разработчиков Carlisle Adams и Stafford Tavares)

XTEA - наиболее простой в реализации алгоритм

Сравнение с асимметричными криптосистемами

Достоинства

скорость (по данным Applied Cryptography — на 3 порядка выше)

простота реализации (за счёт более простых операций)

меньшая требуемая длина ключа для сопоставимой стойкости

изученность (за счёт большего возраста)

Недостатки

сложность управления ключами в большой сети. Означает квадратичное возрастание числа пар ключей, которые надо генерировать, передавать, хранить и уничтожать в сети. Для сети в 10 абонентов требуется 45 ключей, для 100 уже 4950, для 1000 — 499500 и т. д.

сложность обмена ключами. Для применения необходимо решить проблему надёжной передачи ключей каждому абоненту, так как нужен секретный канал для передачи каждого ключа обеим сторонам.

Криптографическая система с открытым ключом (или Асимметричное шифрование, Асимметричный шифр) — система шифрования и/или электронной цифровой подписи (ЭЦП), при которой открытый ключ передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу, и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифровки сообщения используется секретный ключ.[1] Криптографические системы с открытым ключом в настоящее время широко применяются в различных сетевых протоколах, в частности, в протоколах TLS и его предшественнике SSL (лежащих в основе HTTPS), в SSH. Также используется в PGP, S/MIME.

Виды асимметричных шифров

RSA (Rivest-Shamir-Adleman, Ривест — Шамир — Адлеман)

DSA (Digital Signature Algorithm)

Elgamal (Шифросистема Эль-Гамаля)

Diffie-Hellman (Обмен ключами Диффи — Хелмана)

ECDSA (Elliptic Curve Digital Signature Algorithm) — алгоритм с открытым ключом для создания цифровой подписи.

ГОСТ Р 34.10-2001

McEliece

Williams System (Криптосистема Уильямса)