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

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

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

3.3.1 Средства идентификации и аутентификации объектов базы данных

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

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

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

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

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

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

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

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

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

SQL Server поддерживает два режима аутентификации: режим безопасности NT и смешанный режим. Если выбрать режим NT и установить соответствие между процедурами пользовательской регистрации в NT и SQL Server, то пользователи, зарегистрировавшись в NT, могут установить соединение и с SQL Server. В этом режиме пользователи, не опознанные NT, не могут обращаться к SQL Server. В смешанном режиме пользователи, прошедшие регистрацию в NT, соединяются с NT и SQL Server так же, как и в режиме NT, а пользователи, не опознанные NT, могут предъявить имя и пароль для доступа к SQL Server. Альтернативный вариант - аутентификация в SQL Server зарегистрированных пользователей NT с указанием отдельного имени и пароля в SQL Server, а не Windows NT[24, c.132].

Исследовав специфику работы на предприятии, и проанализировав потребности, можно заключить, что использование SQL Server аутентификацию будет эффективнее, так как:

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

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

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

· логины SQL Server будут работать и тогда, когда домен Windows NT/2000/2003 есть, и когда его нет.

3.3.2 Ролевой доступ

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

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

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

1. администраторы задачи;

2. системные администраторы;

3. сотрудники БТО;

4. руководители службы АСУП;

5. администратор базы данных;

6. программисты.

Размещено на http://www.allbest.ru/

Рисунок 3.2 - Группы пользователей базы данных

Полный список ролей и их привилегий описан в приложении В.

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

CREATE ROLE user1;

GRANT SELECT, INSERT, UPDATE, DELETE ON devices TO user1;

GRANT SELECT, INSERT, UPDATE, DELETE ON devicemodel TO user1;

GRANT SELECT, INSERT, UPDATE, DELETE ON devicename TO user1;

GRANT SELECT, UPDATE ON ARM user1.

Стоит тщательно избегать привилегий dbo (исключая задачи администратора БД) в промышленной базе данных, ни при определении её объектов средствами Data Definition Language (DDL), ни для внесения изменений, ни в каких запросах или хранимых процедурах.

Права, предоставляемые роли public, особенно в базе данных master, в последнее время очень часто использовались хакерами для проведения успешных атак на сервера баз данных.

По умолчанию, пользователи получают доступ к базе master через её роль public. Они могут видеть все объекты информационной схемы, которыми владеют, представления, большинство функций, выполнять хранимые процедуры и даже некоторые расширенные хранимые процедуры. В пользовательской базе данных, через эту роль будут видны практически все системные таблицы, кроме, разве что: sysfile1, sysfulltextnofity и sysproperties. Желательно, что бы в базе master не было никого из пользователей, кроме dbo (sa). Если же всё-таки потребуется пустить другого пользователя в эту базу данных, нужно ограничить ему доступ к критическим таблицам, которые могут использовать хакеры.

3.3.3 Привилегии

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

* создавать таблицы в соответствующей схеме, не имея системной привилегии CREATE TABLE (создать таблицу)

* удалять строки из какой-либо таблицы другой схемы, не имея объектной привилегии DELETE (удалить) для этой таблицы

· право на вставку новых данных - INSERT

· явный запрет (DENY) на выполнение действия, определенного данным разрешением

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

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

Управляя какой-либо системой и привилегиями пользователей необходимо помнить, что:

* предоставить системную привилегию может лишь пользователь, имеющий системную привилегию с правами администратора на предоставление привилегий другим пользователям;

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

3.3.4 Языковые средства разграничения доступа

Дать пользователю системную или объектную привилегию можно с помощью SQL-команды GRANT (предоставить), а лишить привилегии можно с помощью SQL-команды REVOKE (отменить). Предоставлять и отменять привилегии пользователей могут только конкретные лица.

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

Оператор GRANT применяется при присвоении привилегии, оператор REVOKE применяется для отмены привилегии. Команды GRANT и REVOKE указывают, каким пользователям можно выполнять определенные операции в отношении определенных таблиц, курсоров и столбцов. Операции, выполнение которых контролируется с помощью GRANT и REVOKE, включают SELECT, UPDATE, INSERT, DELETE.

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

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

Дискреционный принцип обладает большой гибкостью по настройке системы разграничения доступа на особенности предметной области базы данных и потребности пользователей, но не обеспечивает эффективной управляемости и затрудняет проведение какой-либо целенаправленной политики безопасности в системе. Преодоление этого недостатка достигается двумя путями -- использованием техники «представлений» и специальными расширениями языка SQL.

Использование техники представлений является распространенным технологическим приемом формирования для конкретного пользователя своего «видения» базы данных (виртуальной БД) и осуществления на этой основе разграничения доступа к данным в реляционных СУБД. «Представлением» называется глобальный авторизованный запрос на выборку данных, формирующий для пользователя «свое» представление определенного объекта (объектов), совокупность которых формирует некую виртуальную базу данных, со своей схемой (объектами) и данными (отобранными или специально преобразованными). При входе пользователя в систему в процессе его идентификации и аутентификации ядро безопасности отыскивает для пользователя соответствующие представления-запросы и передает запрос основному ядру СУБД для выполнения. В результате выполнения запроса пользователь «видит» и имеет доступ только к тем объектам, которые соответствуют его полномочиям и функциям[39, c.164].

Такой подход является более грубым по сравнению с применением инструкции GRANT непосредственно к объектам базы данных, т.к. не обеспечивает расщепления установок доступа к объектам на уровне отдельных операций (SELECT, INSERT, UPDAТЕ, DELETE).

Поэтому другим подходом являются специальные расширения языка SQL, основанные на событийно-процедурной идеологии с введением специальных правил (RULE) безопасности.

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

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

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

3.3.5 Блокировки учетных сведений пользователей

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

В СУБД Oracle и MS SQL Server можно управлять доступом к базам данных, блокируя и разблокируя в любое удобное время учетные сведения пользователей. Когда учетные сведения пользователя заблокированы, он не может соединиться с СУБД. Чтобы затем разрешить пользователю обращаться к базам данных посредством своих учетных сведений, необходимо их разблокировать[22, c.10]. Блокировки применяют:

* когда пользователь временно отсутствует на работе;

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

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

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

В SQL Server предусмотрено пять основных видов блокировок[2,c.24]:

· уровня базы данных (DB);

· уровня объекта (например, TAB);

· уровня экстента (EXT);

· уровня страницы (PAG);

· уровня записи/ключа (RID/KEY).

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

3.3.6 Шифрование

Если все-таки произошла кража базы данных или ее резервной копии, то наилучшим способом защиты здесь будет шифрование, причем, чем серьезнее и устойчивее будет алгоритм шифрования, тем, соответственно, лучше. В качестве алгоритма может быть применен алгоритм ГОСТ 28147-89.

В SQL Server шифрование используется в разных ситуациях.

1) шифрование данных, передаваемых между клиентом и сервером. Для этого используется технология SSL. Описано в главе 3.3.7.

2) шифрование данных в таблицах баз данных.

В SQL Server версий ниже 2005 никаких встроенных средств для шифрования данных в базах данных не было (кроме специальных ситуаций, например, шифрование определений объектов или паролей пользователей SQL Server). В SQL Server 2005 такие возможности появились.

Для шифрования данных в SQL Server предусмотрено четыре способ[24, c.168]:

· шифрование при помощи сертификатов. Сертификат при этом должен присутствовать в виде объекта в базе данных;

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

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

· простое шифрование при помощи паролей.

При этом совсем необязательно ограничиваться только встроенными средствами SQL Server 2005. Он также позволяет использовать в коде Transact-SQL вызовы к сборкам .NET. Поэтому для шифрования данных можно использовать классы из пространства имен System.Security.Cryptography в .NET Framework или свои собственные сборки.

Сам MS SQL предлагает использовать встроенные алгоритмы шифрования, но эту меру защиты целесообразнее использовать в случае если есть необходимость защитить данные от привилегированных пользователей.

Всё таки MS SQL - это серверная платформа. И защитить его можно только защитив среду выполнения от доступа с других машин. В том числе можно использовать EFS, потеряв при этом 5% производительности, но надежно (опять же сомнительно, т.к. есть недорогие утилиты для расшифровки зашифрованных дисковых ресурсов) защитит БД от копирования.

3.3.7 Защита сетевого трафика

Большая проблема, связанная с безопасностью при работе с SQL Server, заключается в том, что данные запросов пользователей и ответов на них сервера возвращаются в абсолютно открытом виде формата пакета TDS (Tabular Data Stream -- поток табличных данных) по протоколу http. Это говорит о том, что, перехватив пакеты в локальной сети, можно получить доступ к информации, которой обмениваются с SQL Server пользователи. Хотя пароли пользователей SQL Server изначально передаются в защищенном виде, но если пользователь решит поменять свой пароль командой ALTER USER или запуском процедуры sp_password, то такой пароль будет передан по сети открытым текстом. Стоит отметить также, что сейчас достаточно много открытых ресурсов, где можно найти программы, которые умеют собирать данные и парольные хэши SQL Server и расшифровывать их. Поэтому вопрос о надобности использования защиты сетевого трафика отпадает, но возникает новая задача - как именно это реализовать.

Желательно отключить через роль или изъять права на исполнение у public msdb следующие задачи преобразования данных:

1. sp_add_dtspackage сохраняет TDS в sysdtspackages;

2. sp_enum_dtspackages открывает TDS пакет;

3. sp_add_job добавляет новое задание;

4. sp_add_jobstep добавляет новый шаг для задания.

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

· прозрачных для приложений средств IPSec на основе Active Directory; безопасность протокола IP (IPSec) является моделью общих стандартов для обеспечения безопасных конфиденциальных подключений через IP-сети с помощью криптографических служб безопасности;

· выделение критически важных пользователей вместе с SQL Server в отдельный сетевой сегмент, отгороженный от остальной сети маршрутизатором;

· применение сервиса безопасности, реализуемая средствами Kerberos: аутентификация, авторизация и шифрование;

· технология SSL.

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

· защита пересылаемых данных только при установлении соединения клиента с сервером;

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

· подтверждение подлинности источника данных. Проверяется, что все поступающие на сервер данные получены от определенного клиента;

· подтверждение подлинности источника и целостности данных. Проверяется, что отправленные данные не были изменены;

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

Протокол SSL (Secure Socket Layer) был разработан как протокол, обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, FTP) и транспортными протоколами (TCP/IP). Протокол SSL предназначен для решения традиционных задач обеспечения защиты информационного взаимодействия, которые в среде клиент-сервер интерпретируются следующим образом[24, c.159]:

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

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

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

Конфиденциальность информации, передаваемой по установленному защищенному соединению, обеспечивается путем шифрования потока данных на сформированном общем ключе с использованием симметричных криптографических алгоритмов (например, RC4_128, RC4_40, RC2_128, RC2_40, DES40). Контроль целостности передаваемых блоков данных производится за счет использования так называемых кодов аутентификации сообщений (MAC), вычисляемых с помощью хэш-функций (например, MD5)[24, c.160].

Протокол SSL включает два этапа взаимодействия сторон защищаемого соединения:

· установление SSL-сессии;

· защита потока данных.

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

В SSL используется криптография с открытым (публичным) ключом, также известная как асимметричная криптография. Она использует два ключа: один - для шифрования, другой - для расшифровывания сообщения. Два ключа математически связаны таким образом, что данные, зашифрованные с использованием одного ключа, могут быть расшифрованы только с использованием другого, парного первому. Каждый пользователь имеет два ключа открытый и секретный. Пользователь делает доступным открытый ключ любому корреспонденту сети. Пользователь и любой корреспондент, имеющий открытый ключ, могут быть уверены, что данные, зашифрованные с помощью открытого ключа, могут быть расшифрованы только с использованием секретного ключа. Если два пользователя хотят быть уверенными, что информацию, которой они обмениваются, не получит третий, то каждый из них, должен передать открытый ключ другому и хранить секретный ключ. Сообщения шифруются с помощью открытого, расшифровываются только с использованием секретного ключа. Именно так сообщения могут быть переданы по открытой сети без опасения, что кто-либо сможет прочитать их [24, c.161].

В SSL же для защиты передаваемых между клиентом и сервером данных обязательно используются сертификаты, которые бывают двух типов:

· автоматически генерируемый и подписываемый SQL Server 2005 (самоподписанный). В этом случае возможны атаки типа «man-in-the-middle», когда злоумышленник представляется сервером SQL, принимает клиентские пакеты от имени сервера и перенаправляет их на сервер, возвращая затем полученные с сервера данные пользователям. В результате такой операции у злоумышленника будет на руках копия всех данных, которыми обменивались клиенты и сервер. Причина подобной атаки - сертификат, передаваемый сервером клиенту, никем не проверяется.

· от внешнего центра сертификации, которому должны доверять сервер SQL и клиент. Использование такого сертификата будет решением вышеуказанной проблемы. Вариантов реализации два: купить сертификат у центра сертификации, которым Windows доверяет автоматически за немалые деньги, либо создать свой собственный центр сертификации, что можно сделать, используя поставляемые вместе с дистрибутивами Windows 2000 Server и Windows Server 2003, но настройку необходимо выполнять очень тщательно, в противном случае ничего работать не будет.

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

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

Достаточно двух-трех показательных увольнений и это даст положительный эффект.

3.4 Обеспечение целостности данных