Смекни!
smekni.com

Политика информационной безопасности для системы "Учет ремонта и ТО автотранспорта" (стр. 5 из 6)

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

Транспортный уровень

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

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

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

– перечень узлов, их символьные имена;

– соответствующие этим узлам сетевые адреса;

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

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

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

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

[Разрешить адресу IP - 1 сервиса Service - 1

к адресу IP - 4 сервиса Service - 1]

[Разрешить адресу IP - 2 сервиса Service - 1

к адресу IP - 5 сервиса Service -1]

[Разрешить адресу IP-3 сервиса Service - 1

к адресу IP - 5 сервиса Service - 1]

[Остальное запретить]

Такие списки доступа можно настроить на серверах.

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

Уровень приложения

Это уровень сетевой модели, отвечающий за взаимодействие пользовательского приложения c сетью. На данном уровне необходимо осуществлять идентификацию (проверку наличия данного пользователя в списке activedirectory) и аутентификацию Windows (проверку достоверности имени и пароля с помощью сервера — контроллера домена) пользователей. При этом необходимо следить за тем, чтобы пользователи периодически осуществляли смену пароля, причём новый пароль должен значительно отличаться. Беспарольных пользователей в системе быть не должно.

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

Сюда так же можно отнести поддержку такого механизма как Аудит. Под Аудитом в классе 1Г требований по защите АИС понимается регистрация и учет:

–входа/выхода субъектов в/из системы (узла сети);

–выдачи печатных (графических) выходных документов;

–запуска/завершения программ и процессов (заданий, задач);

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

Необходим так же, учет носителей информации, а так же очистка (обнуление) освобождаемых областей ОП ЭВМ и внешних накопителей.


Организационные мероприятия

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

1. Контроль доступа к СВТ:

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

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

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

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

– должна быть утверждена типовая аппаратная конфигурация СВТ;

– должен быть утвержден регламент приобретения оборудования.

3. Комплект документов, устанавливающий настройки системного и общесистемного ПО:

– должен быть утвержден регламент запущенных сервисов на серверном оборудовании и рабочих местах;

– должна осуществляться регистрация следующих событий:

– использование идентификационного и аутентификационного механизма;

– создание и уничтожение объекта;

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

– должно проводиться периодическое тестирование функций СЗИ НСД при изменении программной среды и персонала с помощью тест-программ, имитирующих попытки НСД;

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

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

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

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

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

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

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

4. Контроль доступа к объектам системы:

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

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

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

– должен быть утвержден перечень критически важного оборудования, находящегося в резерве;

– инструкция на инсталляцию СУБД;

– регламент импорта данных;

– очередность подключения рабочих мест;

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

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

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

– сведения о том, кто является главным ответственным лицом и как можно установить с ним контакт;

– информация о том, кто и на каком основании принимает решение о возникновении необычной ситуации;

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

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

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

6. Контроль за персоналом включает следующие мероприятия:

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