Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
В идеале, пользователь может имеет доступ ко всем и любым... 16.11.05 20:18 Число просмотров: 4078
Автор: Anty Статус: Незарегистрированный пользователь
|
> Есть такая проблема: сотрудникам по должностным > обязанностям положено писать конфиденциальную инфу на > болванки, которые они после записи должны регистрировать.
В идеале, пользователь может имеет доступ ко всем и любым данным БД через запросчик в виде интерфейса пользователя. Но в виде файлов для прожига полная БД должна быть доступна ему только в зашифрованном виде. А при получении файлов с сервера - только через утилиту подписывания и/или унифицирования), чтобы, соответственно - обеспечить авторство копии и/или локализовать момент утечки. Тогда даже фокусы с подменой "запоротых" болванок на "левые" не имеют смысла.
Хотя возможен и сговор, и "подстава" чужих ключей, но это - другой аспект защиты.
> Но разумеется гарантии, что они зарегистрируют все диски, > которые пишут, нет. Поставить резаки только в 1 месте и > пускать на него "по пропускам" невозможно по многим > причинам. > Отсюда вопрос, как бы организовать ведение >пофайловоголога всего того, что пишется на CD (имя файла
> с полным путем, размер, дата и т.п.). Кроме того не > отказался бы от такой же возможности касательно > использования LPT, COM и USB.
Попробуйте использовать встроенный системный аудит NT, он годится для копирования любым способом:
1. Выделить файловые области, которые должны аудироваться (не только исходные данные, но и рабочие области прожигалки, например, для создаваемых образов - это поможет понять, что и сколько раз пытались прожечь и т.п.).
2. Назначить уровни аудита для пользователей и/или групп.
3. Включить аудит процессов - станет понятно, какой ид у прожигалки, и какие события вызваны именно процессом прожига.
4. Ограничить права доступа исполнителей на чтение к файлу журнала аудита.
5. Прогнать процесс прожига и проанализировать журнал аудита. Вопрос формализации критериев поиска вполне решаем.
Для организации распределенного аудита (допустим, БД на сервере, а резаки на нескольких РС) можно использовать групповые политики. Вопросы автоматизации распределенной обработки журналов аудита тоже вполне решаемы.
> Проверять целостность > ведущегося лога- это уже ерунда:) Главное, чтобы не затерли. Хотя при возможности альтернативной загрузки это вполне возможно, но скрыть не удастся.
|
|
|