А. Н. Андрончик, В. В. Богданов, Н. А. Домуховский, А. С. Коллеров, Н. И. Синадский, Д. А. Хорьков
 Скачать 9.2 Mb.
|
|
7.4. Создание единого пространства безопасности на базе Active Directory Рассмотренные выше технологии позволяют создать распределенную систему с единой базой аутентификационных и авторизующих данных. Ау- тентификационные данные — это сущности Kerberos, которые связаны с объ- ектами LDAP, хранящими авторизующую информацию (идентификаторы пользователей, членство в группах и т. п.). 194 Операционные системы семейства Windows встраиваются в среду Ac- tive Directory при помощи стандартного инструментария, при этом на рабочей станции запускаются необходимые сервисы, которые переадресуют запросы к локальной базе SAM на контроллеры домена (так же активизируется SSPI- модуль, отвечающий за аутентификацию по протоколу Kerberos). Для того чтобы увидеть этот процесс более подробно, рассмотрим интеграцию рабочей станции под управлением ОС Linux в среду Active Directory. 7.4.1. Технология PAM В первую очередь необходимо сменить режим аутентификации рабочей станции с традиционного (через файл «/etc/shadow»), на аутентификацию по протоколу Kerberos. Для решения подобных задач уже довольно долгое время в Linux (и не- которых других Unix-системах) система аутентификации отделена от утилит, которым необходимо производить аутентификацию. Каждая такая утилита (например, login) запрашивает специальную библиотеку libpam для проведе- ния аутентификации пользователя. Все, что должен обеспечить сервис, — это обратную связь между пользователем и библиотекой (для запроса пароля при необходимости, вывода служебных сообщений, например с просьбой прило- жить специальное устройство к считывателю и т. п.). Сама библиотека libpam тоже не содержит конкретного функционала по аутентификации, весь функ- ционал содержится в модулях PAM 1 . О том, какие модули необходимо загру- жать, библиотека узнает из файлов конфигурации, расположенных в каталоге «/etc/pam.d» (по файлу конфигурации на каждый сервис). Файл конфигурации может содержать 4 типа записей: − auth — отвечают за процесс аутентификации; − account — отвечают за то, что учетная запись актуальна (не заблокиро- вана, не истек срок действия пароля и т. п.); − password — отвечают за манипуляции с аутентификационными данны- ми (например, смена пароля); − session — выполняют некоторые действия, связанные с сеансом пользо- вателя (установка переменных окружения, удаление кэша при выходе пользо- вателя и т. п.). Модуль аутентификации по протоколу Kerberos должен присутствовать в разделах auth и session (для создания кэша билетов и его удаления). Для того чтобы не было необходимости переписывать конфигурационные файлы для каждого из сервисов, в любом дистрибутиве Linux предусмотрены общие на- стройки PAM для всех сервисов. В дистрибутиве Debian — это файлы comon- auth, common-password, common-account и common-session, в каждом описаны умолчания для соответствующих разделов. Именно сюда и необходимо доба- вить модуль «pam_krb5.so». 1 PAM (Pluggable Authentication Modules) – подключаемые модули аутентификации. 195 ВЫПОЛНИТЬ! 28. На виртуальной машине WS-Linux обязательно произвести вход от имени суперпользователя в две или более виртуальных консоли. 29. Открыть в текстовом редакторе файл «/etc/pam.d/common-auth». 30. Поставить символ «#» в начале строки, подключающей модуль pam_unix.so (традиционный механизм, основанный на файлах «/etc/passwd» и «/etc/shadow»). 31. Добавить строку «auth required pam_krb5.so». 32. На виртуальной машине DC создать пользователя «ws-linux_host» при по- мощи оснастки «Active Directory Users and Computers». 33. Создать keytab-файл при помощи следующей команды: ktpass –princ host/ws-linux.example.com@EXAMPLE.COM –crypto des-cbc-md5 +desOnly –ptype KRB5_NT_PRINCIPAL –out c:\http.keytab +rndPass –mapuser ws-linux_host@example.com –mapop set 34. Скопировать keytab-файл на виртуальную машину WS-Linux под именем «/etc/krb5.keytab». 35. Сменить права доступа на keytab-файл командой: chmod 400 /etc/krb5.keytab. 36. На одной из виртуальных консолей произвести выход из системы и вход в нее. Убедиться при помощи команды klist, что пользователь получил TGT. После того как модуль pam_krb5 был подключен к системе аутентифи- кации, получилось следующее: − пользователь root способен осуществить вход в систему; − пользователь student не способен войти в систему, поскольку он не об- ладает учетной записью Kerberos; − пользователь Administrator способен пройти аутентификацию, но он от- вергается нижележащими модулями, которые не могут получить про него ав- торизующую информацию (членство в группах, идентификатор, домашний каталог, login shell). Для того чтобы обеспечить вход для пользователя student достаточно создать для него соответствующую учетную запись в Active Directory. Чтобы разрешить вход администратору, надо каким-то образом перенаправить ос- тальные модули на получение информации о пользователе не из файла «/etc/passwd», а из LDAP каталога Active Directory. 7.4.2. Технология NSS С целью универсального изменения источников различных данных для приложений (информация о пользователях, группах, компьютерах и т. п.) в Unix-системах используется технология Name Service Switch (NSS). Техноло- 196 гия эта похожа на PAM, т.е. при выполнении определенных стандартных функций специальная библиотека (здесь это библиотека языка C) переадресо- вывает вызов некоторому специальному модулю, который указывается в кон- фигурационном файле. Настройка системы NSS производится через файл «/etc/nsswitch.conf», который содержит информацию об объектах и источниках данных о них. На- пример, в файле содержится строка hosts, которая задает поведение функции gethostbyname. В качестве источника данных для этой функции указаны file и dns, т. е. сначала будет произведен поиск в файле «/etc/hosts», а потом при по- мощи системы DNS. Для того чтобы обеспечить получение авторизующей информации из Active Directory, необходимо изменить настройки для объектов users и groups, указав в качестве источника ldap. Однако соответствующая библиотека также требует определенной настройки, а именно ей необходимо указать, как интер- претировать объекты в нашей схеме LDAP. ВЫПОЛНИТЬ! 37. Настройка модуля nss_ldap на виртуальной машине ws-linux a. Открыть в текстовом редакторе файл «/etc/libnss-ldap.conf» b. Указать следующие параметры # адрес ldap сервера host 192.168.0.1 # база поиска base dc=example,dc=com # версия протокола ldap_version 3 # учетная запись для соединения с сервером binddn cn=proxyuser,cn=users,dc=example,dc=com # пароль учетной записи bindpw P@ssw0rd # глубина поиска scope sub # Настройки схемы: # контейнер с объектами с информацией о пользователе nss_base_passwd CN=users,DC=example,DC=com # контейнер с информацией о группах nss_base_group CN=users,DC=example,DC=com # указать аналог класса posixAccount # (класс posixAccount содержится в стандартной схеме, # определенной в RFC 2307) nss_map_objectclass posixAccount user # аналог атрибута uid nss_map_attribute uid sAMAccountName 197 # аналог атрибута homeDirectory nss_map_attribute homeDirectory msSFUHomeDirectory # указать аналог класса posixGroup nss_map_objectclass posixGroup group # аналог атрибута uniqueMember nss_map_attribute uniqueMember member Остальные параметры оставить по умолчанию. c. Открыть текстовым редактором файл «/etc/nsswitch.conf». Доба- вить метод ldap в строках passwd и group. 38. Задать атрибуты для Unix систем пользователя root. a. Запустить оснастку ADSI Edit. b. Открыть редактор атрибутов для группы Domain Users. Задать ат- рибуту gidNumber значение 2000. c. Открыть редактор атрибутов для пользователя root. Задать сле- дующие значения атрибутов: uid — 0, gidNumber — 2000, login- Shell — «/bin/bash», msSFUHomeDirectory — «/root». 39. С помощью текстового редактора удалить запись о пользователе root из файла «/etc/passwd». 40. Проверить получение авторизующей информации из каталога AD. a. Выполнить команду getent passwd и убедиться, что пользователь root присутствует в выводе. b. Выполнить команду getent group и убедиться, что в выводе при- сутствует группа Domain Users. c. Выполнить команду id root и убедиться, что такой пользователь существует, его uid — 0, основная группа — Domain Users. 41. Конфигурация PAM. a. Открыть в текстовом редакторе файл «/etc/pam.d/common-auth» и поставить символ «#» в начале строки, описывающей модуль pam_unix. b. Перейти в новую виртуальную консоль и убедиться, что пользова- тель root по-прежнему способен войти в систему. 42. Сделать также учетные записи student и Administrator Unix- пользователями (учтите, что пользователю Administrator необходимо соз- дать домашний каталог). 198 8. АУДИТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ КОМПЬЮТЕРНЫХ СИСТЕМ 8.1. Понятие аудита информационной безопасности Аудит информационной безопасности (ИБ) представляет собой одно из наиболее актуальных и динамично развивающихся направлений стратегиче- ского и оперативного менеджмента в области безопасности КС и вызывает постоянный интерес специалистов. Его основная задача — объективно оце- нить текущее состояние ИБ организации, а также ее адекватность поставлен- ным целям и задачам бизнеса. Под аудитом ИБ понимается системный процесс получения объектив- ных качественных и количественных оценок текущего состояния ИБ органи- зации в соответствии с определенными критериями и показателями на всех основных уровнях обеспечения безопасности: нормативно-методологическом, организационно-управленческом, процедурном и программно-техническом [19]. Результаты квалифицированно выполненного аудита ИБ организации позволяют построить оптимальную по эффективности и затратам систему обеспечения информационной безопасности (СОИБ), представляющую собой комплекс технических средств, а также процедурных, организационных и правовых мер, объединенных на основе модели управления ИБ. В результате проведения аудита могут быть получены как качествен- ные, так и количественные оценки. При качественном оценивании, например, может быть приведен перечень уязвимостей в программно-аппаратном обес- печении с их классификацией по трехуровневой шкале опасности: высокая, средняя и низкая. Количественные оценки чаще всего применяются при оцен- ке риска для активов организации, создаваемого угрозами безопасности. В ка- честве количественных оценок могут выступать, например, цена риска, веро- ятность риска, размер риска и т. п. Объективность аудита обеспечивается, в частности, тем, что оценка со- стояния ИБ производится специалистами на основе определенной методики, позволяющей объективно проанализировать все составляющие СОИБ. Аудит ИБ может представлять собой услугу, которую предлагают спе- циализированные фирмы, тем не менее в организации должен проводиться внутренний аудит ИБ, выполняемый, например, администраторами безопас- ности. Традиционно выделяют три типа аудита ИБ, которые различаются пе- речнем анализируемых компонентов СОИБ и получаемыми результатами: − активный аудит; − экспертный аудит; − аудит на соответствие стандартам ИБ. 199 8.1.1. Активный аудит Активный аудит представляет собой обследование состояния защищен- ности определенных подсистем информационной безопасности (ПИБ), отно- сящихся к программно-техническому уровню. Например, вариант активного аудита, называемый тестом на проникновение (Penetration test), предполагает обследование подсистемы защиты сетевых взаимодействий. Активный аудит включает: − анализ текущей архитектуры и настроек элементов ПИБ; − интервьюирование ответственных и заинтересованных лиц; − проведение инструментальных проверок, охватывающих определенные ПИБ. Анализ архитектуры и настроек элементов ПИБ проводится специали- стами, обладающими знаниями по конкретным подсистемам, представленным в обследуемой системе (например, могут требоваться специалисты по актив- ному сетевому оборудованию фирмы Cisco или по ОС семейства Microsoft), а также системными аналитиками, которые выявляют возможные изъяны в ор- ганизации подсистем. Результатом этого анализа является набор опросных листов и инструментальных тестов. Опросные листы используются в процессе интервьюирования лиц, от- вечающих за администрирование АИС, для получения субъективных характе- ристик АИС, для уточнения полученных исходных данных и для идентифика- ции некоторых мер, реализованных в рамках СОИБ. Например, опросные лис- ты могут включать вопросы, связанные с политикой смены и назначения па- ролей, жизненным циклом АИС и степенью критичности отдельных ее под- систем для АИС и бизнес-процессов организации в целом. Параллельно с интервьюированием проводятся инструментальные про- верки (тесты), которые могут включать следующие мероприятия: − визуальный осмотр помещений, обследование системы контроля досту- па в помещения; − получение конфигураций и версий устройств и ПО; − проверка соответствия реальных конфигураций предоставленным ис- ходным данным; − получение карты сети специализированным ПО; − использование сканеров защищенности (как универсальных, так и спе- циализированных); − моделирование атак, использующих уязвимости системы; − проверка наличия реакции на действия, выявляемые механизмами обна- ружения и реагирования на атаки. Аудитор может исходить из следующих моделей, описывающих степень его знания исследуемой АИС (модель знания): − модель «черного ящика» – аудитор не обладает никакими априорными знаниями об исследуемой АИС. Например, при проведении внешнего актив- 200 ного аудита (то есть в ситуации, когда моделируются действия злоумышлен- ника, находящегося вне исследуемой сети), аудитор может, зная только имя или IP-адрес web-сервера, пытаться найти уязвимости в его защите; − модель «белого ящика» – аудитор обладает полным знанием о структуре исследуемой сети. Например, аудитор может обладать картами и диаграмма- ми сегментов исследуемой сети, списками ОС и приложений. Применение данной модели не в полной мере имитирует реальные действия злоумышлен- ника, но позволяет, тем не менее, представить «худший» сценарий, когда ата- кующий обладает полным знанием о сети. Кроме того, это позволяет постро- ить сценарий активного аудита таким образом, чтобы инструментальные тес- ты имели минимальные последствия для АИС и не нарушали ее нормальной работы; − модель «серого ящика» или «хрустального ящика» – аудитор имитирует действия внутреннего пользователя АИС, обладающего учетной записью дос- тупа в сеть с определенным уровнем полномочий. Данная модель позволяет оценить риски, связанные с внутренними угрозами, например от неблагона- дежных сотрудников компании. Аудиторы должны согласовывать каждый тест, модель знания, приме- няемую в тесте, и возможные негативные последствия теста с лицами, заинте- ресованными в непрерывной работе АИС (руководителями, администратора- ми системы и др.). По результатам инструментальной проверки проводится пересмотр ре- зультатов предварительного анализа и, возможно, организуется дополнитель- ное обследование (рис. 8.1). Анализ исходных данных A. Инструменталь- ная проверка B. Интервьюиро- вание Анализ данных A и B Набор тестов Набор вопросни- ков Формирова- ние результата Дополнительное обследование Рис. 8.1. Схема проведения активного аудита ИБ По результатам активного аудита создается аналитический отчет, со- стоящий из описания текущего состояния технической части СОИБ, списка найденных уязвимостей АИС со степенью их критичности и результатов уп- рощенной оценки рисков, включающей модель нарушителя и модель угроз. 201 Дополнительно может быть разработан план работ по модернизации техниче- ской части СОИБ, состоящий из перечня рекомендаций пообработке рисков. 8.1.2. Экспертный аудит Экспертный аудит предназначен для оценивания текущего состояния ИБ на нормативно-методологическом, организационно-управленческом и процедурном уровнях. Экспертный аудит проводится преимущественно внешними аудиторами, его выполняют силами специалистов по системному управлению. Сотрудники организации-аудитора совместно с представителями заказчика проводят следующие виды работ: − сбор исходных данных об АИС, ее функциях и особенностях, исполь- зуемых технологиях автоматизированной обработки и передачи информации (с учетом ближайших перспектив развития); − сбор информации об имеющихся организационно-распорядительных документах по обеспечению ИБ и их анализ; − определение защищаемых активов, ролей и процессов СОИБ. Важнейшим инструментом экспертной оценки является сбор данных об АИС путем интервьюирования технических специалистов и руководства за- казчика. Основные цели интервьюирования руководящего состава организации: − определение политики и стратегии руководства в вопросах обеспечения ИБ; − выявление целей, которые ставятся перед СОИБ; − выяснение требований, которые предъявляются к СОИБ; − получение оценок критичности тех или иных подсистем обработки ин- формации, оценок финансовых потерь при возникновении тех или иных ин- цидентов. Основные цели интервьюирования технических специалистов: − сбор информации о функционировании АИС; − получение схемы информационных потоков в АИС; − получение информации о технической части СОИБ; − оценка эффективности работы СОИБ. В рамках экспертного аудита проводится анализ организационно- распорядительных документов, таких как политика безопасности, план защи- ты, различного рода положения и инструкции. Организационно- распорядительные документы оцениваются на предмет достаточности и не- противоречивости декларируемым целям и мерам ИБ, а также на предмет со- ответствия стратегической политике руководства в вопросах ИБ. Результаты экспертного аудита могут содержать рекомендации по со- вершенствованию нормативно-методологических, организационно- управленческих и процедурных компонентов СОИБ. 202 8.1.3. Аудит на соответствие стандартам ИБ В ряде случаев проводится аудит на соответствие стандартам ИБ. Спе- циально уполномоченные организации-аудиторы по результатам аудита при- нимают решение и выдают документальное подтверждение о соответствии СОИБ тому или иному эталонному стандарту (проводят сертификацию). Сер- тификация является показателем качества СОИБ и поднимает престиж и уро- вень доверия к организации. Аудит на соответствие стандартам чаще всего подразумевает проведе- ние активного и экспертного аудита. По результатам могут быть подготовле- ны отчеты, содержащие следующую информацию: − степень соответствия проверяемой ИС выбранным стандартам; − количество и категории полученных несоответствий и замечаний; − рекомендации по построению или модификации СОИБ, позволяющие привести ее в соответствие с требованиями рассматриваемого стандарта. |