Грибунин В.Г. Комплексная система защиты информации на предприятии

Подождите немного. Документ загружается.

таны на работу с поименованными субъектами и объектами АС

[28]. Напомним, что в качестве субъектов АС могут выступать как

пользователи, так и процессы, а в качестве объектов АС — ин-

формация и другие информационные ресурсы системы.

С древних времен люди использовали различные средства, чтобы

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

использовались устные пароли («то, что знаю»), различные удо-

стоверения личности с трудно подделываемыми элементами («то,

что имею»), в удостоверениях личности могли быть описаны осо-

бые приметы человека («то, чем являюсь»). Характерной чертой

этих, докомпьютерных, методов установления подлинности лич-

ности было то, что в качестве проверяющего лица обычно высту-

пал человек, а также то, что такая проверка происходила при не-

посредственном контакте.

В современных вычислительных сетях решение о подлинности

предъявленного удостоверения выносит компьютер, а непосред-

ственный контакт предъявителя и проверяющего становится все

большей редкостью. Рассмотрим и еще одно существенное отли-

чие сегодняшней ситуации от исторических времен. Если в ту

эпоху лицу, не прошедшему проверку подлинности, грозило усек-

новение головы, то сейчас любой может попробовать себя в каче-

стве «взломщика» информационной системы практически без вся-

ких для себя последствий.

Согласно ГОСТ Р ИСО

7498-2

—

99 [14], процедура проверки

подлинности предъявленного субъектом доступа идентификатора

называется аутентификацией. Как указано в этом стандарте, раз-

личается аутентификация отправителя данных — «подтверждение

того, что отправитель полученных данных соответствует заявлен-

ному», и аутентификация равноправного логического объекта —

«подтверждение того, что равноправный логический объект в ка-

кой-либо ассоциации является заявленным логическим объектом».

Задача аутентификации отправителя данных успешно решает-

ся при помощи технологии ЭЦП. Далее речь пойдет об аутенти-

фикации во втором смысле этого слова, при этом в качестве субъек-

та доступа может выступать как человек, так и программа.

Системы электронной торговли, Интернет-банкинга, платеж-

ные системы, в том числе мобильные, сайты с платным контен-

том — вот далеко неполный перечень областей, где от надежной

аутентификации субъектов зависит судьба финансов. А что уж

говорить об информационных системах, в которых обрабатывает-

ся информация, составляющая государственную тайну, и о воен-

ных системах!

Без всякого преувеличения можно сказать, что аутентифика-

ция является самым важным механизмом безопасности. И надеж-

ная аутентификация невозможна без привлечения криптографи-

ческих методов.

170

Рассмотрим элементы системы аутентификации. В любой та-

кой системе, во-первых, присутствует субъект доступа — человек

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

тор,

т. е.

какая-то характеристика, отличающая этого субъекта от

других. В-третьих, есть владелец информационной системы, не-

сущий ответственность за ее эксплуатацию и полагающийся в раз-

граничении пользователей на механизм аутентификации. От его

имени обычно действует администратор. Следовательно, в-чет-

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

верки предъявленного идентификатора. И наконец, при успеш-

ном прохождении аутентификации субъект доступа наделяется

определенными правами и полномочиями, т.е. происходит про-

цесс его авторизации.

В табл. 8.1 приведены элементы аутентификации для различ-

ных информационных систем.

В компьютерных системах механизмы аутентификации и авто-

ризации обычно реализуются раздельно.

Механизмы аутентификации в современных информационных

системах основаны на тех же факторах, что и в далеком прошлом:

• «то, что знаю» — пароли;

• «то, что имею» — смарт-карты, токены и т.п.;

• «то, чем являюсь» — биометрические технологии аутентифи-

кации.

Таблица 8.1. Элементы системы аутентификации

Элемент

аутентификации

Субъект

доступа

Идентификатор

Владелец

системы,

администратор

Механизм

аутентификации

Механизм

авторизации

Процедура

регистрации

системе

Авторизованный

пользователь

Секретный

пароль

Предприятие,

фирма

Программное

обеспечение,

проверяющее

пароль

Процесс

регистрации,

управление

доступом

Банкомат

Владелец банков-

ского счета

Банковская

карточка и

P1N

Банк

Программное

обеспечение,

проверяющее

карточку

Разрешение

на выполнение

банковской

транзакции

Web-сервер

по

отношению

к клиенту

Владелец

Web-сервера

Открытый

ключ

в сертификате

Удостоверяю-

щий центр,

выдающий

сертификаты

Программное

обеспечение,

проверяющее

сертификат

Метки браузе-

ра, говорящие

о «защищен-

ном» статусе

страницы

171

Аутентификация может быть однофакторной (как правило,

основанной на паролях) и многофакторной (сочетание вышепри-

веденных факторов).

В настоящее время считается, что парольная защита не обеспе-

чивает безопасности распределенных систем, поэтому применя-

ются многофакторные механизмы аутентификации. Кроме того,

реализуются усиленные (криптографические) протоколы аутен-

тификации, используемые в распределенных системах.

Рассмотрим основные типы механизмов аутентификации. К ним

относятся: локальная аутентификация; прямая аутентификация;

непрямая аутентификация; автономная аутентификация.

Локальная аутентификация характерна для автономных ком-

пьютеров. Здесь вся система, включая механизмы аутентифика-

ции и авторизации, находится в пределах защищаемого организа-

ционными и техническими мерами периметра безопасности.

Пользователь находится вне этого периметра. Если к надежности

периметра безопасности имеется высокое доверие, то в качестве

паролей могут использоваться запоминающиеся слова, PIN-коды.

Пароли могут храниться в системе в открытом виде. Ведь все, что

может сделать нарушитель — это подбирать пароль в интерактив-

ном режиме. Конечно, если периметр безопасности «взломан», то

нарушитель сможет внедрить закладку, например записывающую

последовательность нажатий клавиш.

Общим недостатком локальных механизмов аутентификации

являются трудности администрирования систем, где они реализо-

ваны, которые возрастают при увеличении рабочих мест.

При прямой аутентификации имеется сервер, на котором раз-

мещены и механизмы аутентификации, и объекты доступа, т.е.

данные. К этому серверу имеют удаленный доступ несколько

пользователей. Как и при локальной аутентификации, механиз-

мы аутентификации и управления доступом находятся внутри

одного физического периметра безопасности.

Аутентификация называется прямой, так как решение о досту-

пе принимается в той же точке, к которой и осуществляется до-

ступ. Такая система хорошо работает при небольшом количестве

пользователей: администратор знает своих пользователей, поддер-

живает базу данных аутентификации. В случае надобности вопро-

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

максимально оперативно и просто.

Как и обычно, за преимущества и удобства централизации надо

платить, так как при этом снижается устойчивость к сбоям: до-

статочно нарушить работу одного сервера. Ввиду того, что пользо-

вательские станции находятся вне пределов периметра безопас-

ности, к каналу связи между ними и сервером безопасности воз-

можен несанкционированный доступ. Поэтому становится невоз-

можным использование «обычных», многоразовых паролей, а также

172

биометрических средств аутентификации: противник всегда мо-

жет перехватить информацию и использовать ее впоследствии.

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

пароли либо одноразовые пароли, а также схемы «запрос-ответ».

В современных протоколах аутентификации типа RADIUS,

Kerberos, а также протоколов, реализованных в домене

Windows,

используется непрямая аутентификация, при которой имеется

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

База данных аутентификации — единая, что облегчает админист-

рирование. В системе непрямой аутентификации имеется отдель-

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

точки управления доступом. Отсюда и название «непрямая», так

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

целиком полагаются на сервер аутентификации. В системах с не-

прямой аутентификацией не обойтись без применения протоко-

лов аутентификации.

Опишем наиболее общий протокол непрямой аутентифика-

ции.

1. Субъект доступа обращается к точке доступа, передавая ей

свой идентификатор и пароль.

2. Точка доступа передает эти данные серверу аутентифика-

ции.

3. Сервер аутентификации принимает решение о разрешении/

запрете доступа и сообщает его точке доступа.

4. Точка доступа доводит решение до субъекта доступа.

У нарушителя в данном протоколе имеется возможность не

только повторно использовать перехваченный пароль пользовате-

ля, но и подделать ответ сервера аутентификации, вследствие чего

в этом канале связи также должно применяться шифрование.

Системы непрямой аутентификации хорошо масштабируемы,

кроме того, могут обладать высокой устойчивостью к сбоям. Для

достижения этого свойства применяются механизмы репликации

баз данных аутентификации на различные территориально разне-

сенные серверы.

В системах с открытым ключом применяется автономная

аутентификация. В подобных системах аутентификация выпол-

няется максимально распределенным образом, так как считается,

что субъекты доступа

не

имеют связи в реальном времени с серве-

ром аутентификации. Этот тип аутентификации объединяет осо-

бенности первых трех типов. Как и в случае локальной аутенти-

фикации, автономная аутентификация может выполняться на не

подключенном к сети устройстве. Как и в случае локальной и

прямой аутентификации механизм аутентификации расположен

там же, где и механизм управления доступом. Как и при непря-

мой аутентификации, владелец поддерживает централизованный

список авторизованных пользователей.

173

Такие системы характерны для электронной коммерции, когда

клиенты (точки обслуживания) пытаются аутентифицировать сер-

вер, а не наоборот. Владелец представляет собой независимую

сторону (Удостоверяющий центр), который обеспечивает единую

среду доверия для серверов и клиентов. Аутентификация осуще-

ствляется в два этапа. На первом этапе Удостоверяющий центр

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

сервера. Клиент проверяет подлинность подписи и далее исполь-

зует этот ключ в криптопротоколах типа SSL для безопасного со-

единения с сервером.

Особенностью аутентификации автономного типа является то,

что формирование и подпись сертификатов для участников ин-

формационного обмена владелец осуществляет в изолированной

системе, поэтому нарушитель не имеет доступа к механизму реги-

страции пользователей.

Автономный тип аутентификации является отказоустойчивым,

так как устройство может аутентифицировать любой объект, осу-

ществляя поиск нужных сертификатов в своей базе данных или

извлекая из того объекта, который аутентифицируется (именно

так сделано в SSL). Каталоги открытых ключей могут также быть

реплицированы на многие устройства системы.

Основным недостатком автономного типа аутентификации яв-

ляется сложность лишения полномочий ранее авторизованного

пользователя.

Как указано в ГОСТ Р ИСО

7498-2-99

[14], под паролем по-

нимается «конфиденциальная информация аутентификации, обыч-

но состоящая из строки знаков».

Пароли бывают одноразовые и многоразовые. Вначале будем

считать (по умолчанию), что все пароли — многоразовые.

На безопасность применения паролей для аутентификации важ-

ное влияние оказывают следующие моменты:

• генерация паролей;

• выдача паролей пользователям и их хранение ими;

• хранение паролей в системе;

• ввод пароля пользователем и его проверка;

• периодичность смены паролей;

• вывод паролей из действия.

Еще лет 20 назад вопросам генерации паролей не уделялось

особого внимания. Так, в Руководстве Министерства обороны

США, изданном в 1985 г., единственными требованиями была

хорошая запоминаемость и отличие текущего выбранного пароля

от предыдущего. Кроме того, рекомендовалось проектировать си-

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

применения до величины

-6

Для этого длина пароля должна

была составлять 9 буквенных или 8 буквенно-цифровых симво-

лов. Кстати, именно последнее требование к паролям встречается

174

РД

Гостехкомиссии для автоматизированных систем высоких

классов

защищенности.

Однако разрешать пользователям выбирать себе пароль само-

стоятельно было не очень хорошей идеей, так как чаще всего они

выбирали в качестве них какие-нибудь значимые слова. Посколь-

ку средний размер активного словаря человека — порядка 5 тыс.

слов, вероятность угадывания составляет всего лишь 5

•

10~

с пер-

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

словарных атак с заранее подготовленными словарями, то подбор

пароля может быть осуществлен моментально. Поэтому в руко-

водствах по безопасности обычно указывается на необходимость

выбора буквенно-цифрового пароля из символов верхнего и ниж-

него регистров, что существенно увеличивает пространство атаки.

Как запомнить такой пароль? Ведь требование хорошей запо-

минаемости паролей возникло не от хорошей жизни: оно необхо-

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

попало. Хрестоматийным нарицательным примером является за-

писанный на хранящейся под ковриком мышки или приклеенной

с обратной стороны клавиатуры бумажке пароль. Это лишний раз

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

ционными. В соответствии с современными воззрениями, гриф

секретности паролей должен быть не ниже грифа секретности за-

щищаемых данных. Значит, он должен быть либо записанным на

учтенный лист бумаги (в рабочую тетрадь), либо на носитель со-

ответствующего уровня конфиденциальности. В настоящее время

на рынке имеются достаточно удобные (и, что немаловажно, сер-

тифицированные для обработки информации с самыми высоки-

ми грифами) устройства памяти для хранения паролей.

Итак, проблему надежного хранения паролей можно решить,

затратив небольшие деньги, а то и вообще бесплатно. Но как осу-

ществлять их автоматическую генерацию? Казалось бы, какая раз-

ница? Используем вызовы функции rand(), приведем получивши-

еся числа по нужному модулю — пароль готов. Однако во многих

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

чайных чисел порождает вполне детерминированную последова-

тельность.

Кроме всего прочего, для встроенной функции типа rand() очень

мало пространство атаки. Под пространством атаки понимает-

ся среднее количество бит, которые должен «угадать» противник

для подбора пароля. Например, чтобы подобрать пароль, состоя-

щий из одного шестнадцатиричного символа, противнику нужно

угадать 4 бита, значит, пространство атаки составляет 4 бита, т.е.,

по сути, пространство атаки есть не что иное, как энтропия паро-

ля. В случае использования встроенной функции пространство

атаки будет определяться не длиной и алфавитом сгенерирован-

ных паролей, а энтропией начального заполнения линейного кон-

175

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

такового используются показания системного таймера,

который

имеет дискретность 1/12 с. Если противнику известно время ге-

нерации пароля с точностью, например, до минуты, то неопреде-

ленность составляет всего лишь

log

(60

•

12)

9,5 бит, что пример-

но эквивалентно паролю из трех цифр. Таким образом, стойкость

«случайного» пароля, порожденного встроенной функцией гене-

рации случайных чисел, не зависит от алфавита и размера пароля.

Для создания паролей в идеале следует использовать крипто-

графически безопасные генераторы случайных чисел (ГСЧ) — ге-

нераторы гаммы. Инициализация этих генераторов должна про-

изводиться от различных источников случайности, а не только от

системного времени.

8.3.2.

Разграничение доступа

После выполнения идентификации и аутентификации необхо-

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

последующего контроля санкционированного использования вы-

числительных ресурсов, доступных в АС. Такой процесс называ-

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

Обычно полномочия субъекта представляются списком ресур-

сов, доступных пользователю, и правами по доступу к каждому

ресурсу из списка. Альтернативой является присвоение пользова-

телю и ресурсам определенных уровней конфиденциальности и

построение системы разграничения доступа на этой основе. Пер-

вый метод называется дискреционным, а метод, основанный на

метках конфиденциальности, — мандатным.

При дискреционном методе разграничения доступа составля-

ется таблица, строками которой являются пользователи системы,

а столбцами — ресурсы. В ячейках таблицы указываются права

доступа (чтение, запись и др.), как это показано в табл. 8.2.

При мандатном принципе разграничения доступа выделяют

несколько уровней, например: общий доступ, конфиденциально,

секретно, совершенно секретно. Полномочия каждого пользова-

теля задаются в соответствии с максимальным уровнем

секретно-

Таблица 8.2. Фрагмент таблицы установления полномочий

Субъект

Пользователь 1

Пользователь 2

Каталог

c:\wavelet

cdrw

Программа

jpegtran

Принтер

^с9:00

до 17:00

Обозначения: с — создание, d — удаление,

— чтение, w — запись, е

выполнение.

176

стй,

к которому он допущен. Пользователь имеет доступ по чте-

ние

ко всем данным, имеющим уровень (гриф) секретности не

вьппе,

чем он имеет. По записи он, наоборот, имеет доступ толь-

ко к своему и более высоким грифам секретности.

Итак, разрешено чтение «вниз», запись «вверх». Отметим, что

это справедливо для мандатной модели обеспечения конфиден-

циальности. Для мандатной модели обеспечения целостности —

все наоборот.

На практике обычно сочетают различные методы разграниче-

ния доступа.

8.3.3.

Регистрация и аудит

Подсистема регистрации должна обеспечить: подотчетность

пользователей и администраторов; возможность реконструкции

последовательности событий; обнаружение попыток нарушений

информационной безопасности; предоставление информации для

выявления и анализа проблем.

Так, согласно РД Гостехкомиссии, в АС класса

1Г

(она пред-

назначена для обработки служебной информации) должна быть

реализована регистрация входа (выхода) субъектов доступа в си-

стему (из системы) либо загрузки и инициализации операцион-

ной системы и ее программной остановки (программного остано-

ва). Регистрация выхода из системы или останова не проводится в

моменты аппаратурного отключения АС.

При этом в параметрах регистрации указываются:

• дата и время входа (выхода) субъекта доступа в систему (из

системы) или загрузки (останова) системы;

• результат попытки входа: успешная или неуспешная — не-

санкционированная;

• идентификатор (код или фамилия) субъекта, предъявленный

при попытке доступа;

• код или пароль, предъявленный при неуспешной попытке.

Кроме того, должна осуществляться регистрация выдачи пе-

чатных (графических) документов на «твердую» копию. В па-

раметрах регистрации указываются:

• дата и время выдачи (обращения к подсистеме вывода);

• спецификация устройства выдачи [логическое имя (номер)

внешнего устройства];

• краткое содержание (наименование, вид, шифр, код) и уро-

вень конфиденциальности документа;

• идентификатор субъекта доступа, запросившего документ.

Должна осуществляться регистрация запуска (завершения)

программ и процессов (заданий, задач), предназначенных для

обработки защищаемых файлов. В параметрах регистрации ука-

зываются:

177

• дата и время запуска;

• имя (идентификатор) программы (процесса, задания);

• идентификатор субъекта доступа, запросившего программу

(процесс, задание);

• результат запуска (успешный, неуспешный —

несанкциони-

рованный).

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

граммных средств {программ, процессов, задач, заданий) к за-

щищаемым файлам. В параметрах регистрации указываются:

•

дата и время попытки доступа к защищаемому файлу с указа-

нием ее результата: успешная, неуспешная — несанкционирован-

ная;

• идентификатор субъекта доступа;

• спецификация защищаемого файла.

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

граммных средств к дополнительным защищаемым объектам

доступа: терминалам, ЭВМ, узлам сети ЭВМ, линиям (каналам)

связи, внешним устройствам ЭВМ, программам, томам, катало-

гам, файлам, записям, полям записей. В параметрах регистрации

указываются:

•

дата и время попытки доступа к защищаемому объекту с ука-

занием ее результата: успешная, неуспешная — несанкциониро-

ванная;

• идентификатор субъекта доступа;

• спецификация защищаемого объекта [логическое имя (но-

мер)].

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

формации с помощью их маркировки и с занесением учетных

данных в журнал (учетную карточку).

Учет защищаемых носителей проводится в журнале (картоте-

ке) с регистрацией их выдачи (приема).

Должна осуществляться очистка (обнуление, обезличивание)

освобождаемых областей оперативной памяти ЭВМ и внешних

накопителей. Очистка осуществляется однократной произволь-

ной записью в освобождаемую область памяти, ранее использо-

ванную для хранения защищаемых данных (файлов).

Эффективность системы безопасности принципиально повы-

шается в случае дополнения механизма регистрации механизмом

аудита. Это позволяет оперативно выявлять нарушения, опреде-

лять слабые места в системе защиты, анализировать закономер-

ности системы, оценивать работу пользователей и т.д.

Аудит — это анализ накопленной информации, проводимый

оперативно в реальном времени или периодически (например,

один раз в день) [43]. Оперативный аудит с автоматическим ре-

агированием на выявленные нештатные ситуации называется

активным.

178

Реализация механизмов регистрации и аудита позволяет ре-

шать

следующие задачи обеспечения информационной безопас-

ности:

• обеспечение подотчетности пользователей и администрато-

ров;

• обеспечение возможности реконструкции последовательно-

сти событий;

•

обнаружение попыток нарушений информационной безопас-

ности;

• предоставление информации для выявления и анализа про-

блем.

Практическими средствами регистрации и аудита являются:

различные системные утилиты и прикладные программы; регист-

рационный (системный или контрольный) журнал.

Первое средство обычно дополняет мониторинг, осуществляе-

мый администратором системы. Комплексный подход к протоко-

лированию и аудиту обеспечивается при использовании регистра-

ционного журнала.

Регистрационный журнал — это хронологически упорядочен-

ная совокупность записей результатов деятельности субъектов

системы, достаточная для восстановления, просмотра и анализа

последовательности действий, сопровождающих операции и про-

цедуры, или приводящих к их выполнению, либо к совершению

событий при транзакции с целью контроля конечного результата.

Обнаружение попыток нарушений информационной безопас-

ности входит в функции активного аудита, задачами которого яв-

ляется оперативное выявление подозрительной активности и пре-

доставление средств для автоматического реагирования на нее.

Под подозрительной активностью понимается поведение пользо-

вателя или компонента информационной системы, являющееся

злоумышленным (в соответствии с заранее определенной полити-

кой безопасности) или нетипичным (согласно принятым крите-

риям). Например, подсистема аудита, отслеживая процедуру вхо-

да (регистрации) пользователя в систему, подсчитывает количе-

ство неудачных попыток входа. В случае превышения установ-

ленного порога таких попыток подсистема аудита формирует сиг-

нал о блокировке учетной записи данного пользователя.

8.3.4.

Криптографическая подсистема

Криптографические методы защиты данных считаются наибо-

лее надежными. Необходимо отметить, что все основные задачи

защиты информации от НСД решаются с применением крипто-

графии. В некоторых случаях они могут быть решены и другими

путями, но, как правило, использование криптографии повышает

179