Требования к защите конфиденциальной информации

 

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

1. Идентифицировать и проверять подлинность субъектов доступа при входе в систему. Причем это должно осуществ-

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

волов.

2. Идентифицировать терминалы, ЭВМ, узлы компьютерной сети, каналы связи, внешние устройства ЭВМ по их логи-

ческим адресам (номерам).

3. По именам идентифицировать программы, тома, каталоги, файлы, записи и поля записей.

4. Осуществлять контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа.

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

1. Регистрировать вход (выход) субъектов доступа в систему (из системы), либо регистрировать загрузку и инициали-

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

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

• результат попытки входа – успешная или неуспешная (при НСД);

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

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

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

2. Регистрировать выдачу печатных (графических) документов на "твердую" копию. При этом в параметрах регистра-

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

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

• краткое содержание документа (наименование, вид, код, шифр) и уровень его конфиденциальности;

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

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

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

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

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

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

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

• результат запуска (успешный, неуспешный – несанкционированный).

4. Регистрировать попытки доступа программных средств (программ, процессов, задач, заданий) к защищаемым фай-

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

• дата и время попытки доступа к защищаемому файлу с указанием ее результата (успешная, неуспешная – несанк-

ционированная);

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

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

5. Регистрировать попытки доступа программных средств к следующим дополнительным защищаемым объектам дос-

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

гам, файлам, записям, полям записей. При этом в параметрах регистрации указывается:

• дата и время попытки доступа к защищаемому файлу с указанием ее результата: успешная, неуспешная, несанкцио-

нированная;

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

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

6. Проводить учет всех защищаемых носителей информации с помощью их маркировки и с занесением учетных дан-

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

7. Регистрировать выдачу (приемку) защищаемых носителей.

8. Осуществлять очистку (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних

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

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

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

1. Обеспечивать целостность программных средств системы защиты информации от НСД (СЗИ НСД), обрабатываемой

информации, а также неизменность программной среды. При этом:

• целостность СЗИ НСД проверяется при загрузке системы по контрольным суммам компонент СЗИ;

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

вием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации.

2. Осуществлять физическую охрану СВТ (устройств и носителей информации). При этом должны предусматриваться

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

проникновения в помещение АС и хранилище носителей информации. Особенно в нерабочее время.

3. Проводить периодическое тестирование функций СЗИ НСД при изменении программной среды и персонала АС с

помощью тест программ, имитирующих попытки НСД.

4. Иметь в наличии средства восстановления СЗИ НСД. При этом предусматривается ведение двух копий программ-

ных средств СЗИ НСД, а также их периодическое обновление и контроль работоспособности.

 

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

Понятие добавочной защиты информации. Способы комплексирования механизмов защиты

 

Понятие встроенной и добавочной защиты

 

По способу реализации системы защиты компьютерной информации от НСД принято подразделять на встроенные и добавочные.

 

 

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

 

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

 

Изначально средства добавочной защиты появились для незащищенных ОС, не обладающих втроенными механизмами защиты.

 

 

Понятие идентификации и аутентификации. Процедура авторизации

Идентификация призвана каждому пользователю (группе пользователей) сопоставить соответствующую ему разграничительную политику доступа на защищаемом объекте. Для этого пользователь должен себя идентифици­ровать — указать свое «имя» (идентификатор). Таким образом проверяет­ся, относится ли регистрирующийся пользователь к пользователям, иден­тифицируемым системой. В соответствии с введенным идентификатором пользователю будут сопоставлены соответствующие права доступа.

Аутентификация предназначена для контроля процедуры идентификации. Для этого пользователь должен ввести секретное слово — пароль. Правиль­ность вводимого пароля подтверждает однозначное соответствие между ре­гистрирующимся пользователем и идентифицированным пользователем.

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

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

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

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

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

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

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

Требования к идентификации и аутентификации

Формализованные требования

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

• Должны осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю условно-постоянного действия длиной не менее шести бук­венно-цифровых символов (для классов защищенности 1Г и 1В по классификации АС) [1].

» Система защиты должна требовать от пользователей идентифициро­вать себя при запросах на доступ.

• Система защиты должна подвергать проверке подлинность иденти­фикации — осуществлять аутентификацию. Для этого она должна

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

Система защиты должна препятствовать доступу к защищаемым ре­сурсам неидентифицированных пользователей и пользователей, под­линность идентификации которых при аутентификации не подтвер­дилась (для 5 класса защищенности по классификации СВТ) [2] Для 3 класса защищенности по классификации СВТ вводится дополни­тельное требование: система запгдты должна обладать способностью надежно связывать полученную идентификацию со всеми действиями данного пользователя.

Очевидно, что кроме ограничения «...паролю условно-постоянного дей­ствия длиной не менее шести буквенно-цифровых символов...» данные

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

Дополнительные требования

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

к информации, а значит, следует рассматривать возможные варианты их резервирования (как «горячего», так и «холодного»).

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

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

 

 

дискреционнАя(матричная) модель доступа

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

в терминах матричной модели состояниЕ защиты описывается след тройкой: СОМ

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

М- матрица доступа. Значение элементов в матрице(С,О) определяет права доступа С к объекту О.

Права доустпа регламентиРуют способы обращения субъекта С К различным типам обеЪетам досТупа. В частности права доступа к файловым объектам обычно опредяются как чтением R запись W выполнение Е. D удаление A добавление

Основы реализации управления доступом составляет анализ строки матрицы доступа при обращении субъекта к объекту при этом проверяется строка матрицы соотв объекту и анализируется есть ли разрешенные права доступа для объекта.

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

 

 

1В

 

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

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

 

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

Основу реализации управления доступом составляют:

1. Формальное сравнение метки субъекта, запросившего доступ, и метки объекта, к которому запрошен доступ.

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

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

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

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

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

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

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

мандатная секреТная