Администрирование ресурсов 1С Предприятия 7.7 (dbf-версия) c помощью технологий Windows 2000

Введение

Странные противоречивые чувства оделвали меня, когда я перебрал материалы об администрировании 1С. Интересной мне показалась статья "Администрирование" (сайт mista.ru) как показатель администрирования с точки зрения "самого 1С Предприятия". Но как то нет пересечения с материалами об администрировании Windows-сетей. Этот пробельчик и хочу попробовать заполнить...

В этой статье речь пойдет о таких вещах как:

- администрирование ресурсов информационных баз 1С в домене Windows 2000 (и только в нем)
- доменная структура, базовые понятия и значение для 1С
- вариант примерной модели обозначений и схемы управления доступом к базам

Пару слов о домене

Наш домен songi.local (.local - подчеркивает отсутствие выхода в интеренет) отражает название фирмы (Сонги и ко) являясь одним из самых простых вариантов развертывания службы каталогов Active Directory (см. статью Active Directory для осваивающих ). Почему? Ну хотя бы только потому, что он является единственным доменом в лесу службы каталогов. Нет доступа через интернет. Мы сосредоточемся на наших "внутренних проблемах".

Внутренние проблемы - создание безопасности

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

можно сказать, что вообщем-то в нашем случае не имеет значения, какой именно ресурс будем "охранять", а важно - КАК, но обо всем по порядку.

Итак наша фирма имеет относительно небольшие размеры, и будем это учитывать при формировании структуры каталога Active Directory. Основная часть структурной схемы фирмы примерно такая:

...из документов компании "Сонги и Ко":

На практике у нас пусть будет вот такая схема сети:

В качестве коментария к рисунку скажу, что имена компьютерам раздадим исходя из правила, делающего имя компьютера по типу операционной системы, например Windows 2000 будет выглядеть как "W2K...", а Windows XP как WXP. Других клиентских машин мы не рассматриваем, но по аналогии Windows 95 - W95, Windows 98 - W98, Windows NT- WNT можно так назвать. Вторую часть имени дополняем именем учетной записи пользователя - владельца машины. Сервера называть будем по функциональному назначение, а именно файловый сервер "file", котроллер домена "dc", также в качестве аналогии можно назвать ДНС-сервер как "ns", терминальный - "trm", прокси - "prx" и т.д. Поскольку тот же контроллер домена выгодно иметь не в одном экземпляре, не лишеным смысла на мой вгляд будет в конце имени сервера ставить цифру - многие сервера держат в качестве резервирования, отказоустойчивости, распределения нагрузки, т.е. дублируют функции на несколько машин.

Надо сказать несколько слов о самом домене.

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

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

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

После повышения простого сервера до контроллера в оснастке администрирования (пуск-программы-администрирование-Active Directory-Пользователи и компьютеры) пользователей (называю сокращенно) увидим структуру каталога, которую и будем затем очень часто использовать. Такую оснастку, как и многие другие, не установленные на простом сервере, можно развернуть, запустив файл с путем похожим на C:\WINNT\system32\adminpak.msi :-)

Сформируем для начала Организационные единицы (Подразделения)

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

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

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

Глобальные группы

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

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

причиной этого является режим совместимости с предыдущими версиями Windows

выбрав "свойства" корня оснастки "songi.local" на закладке "общие" мы увидим кнопку смены режима и надпись, подтверждающую, что сейчас домен в смешанном режиме (это всегда так при установке домена в целях режима совместимости предыдущими версиями (Windows NT)).

Меняем режим...

обратите внимание, что эта операция необратима!!!

в результате мы увидим примерно такую картинку:

Локальные группы

Локальные группы мы будем использовать для предоставления доступа к ресурсам, т.е. это принтеры, папки, сетевые ресурсы, каталоги. И только локальные группы. Почему? Да потому что предоставив доступ сотруднику, который затем уволится, в списке ACL (контроля доступа) у нас останется запись о несуществующем пользователе. А в случае предоставления ему доступа через группу доступа к ресурсу нам будет достаточно просто исключить его из этой группы.

Во многих книгах рекомендуют обозначать группы суффиксом, обозначающим доступ. Например? доступ в режиме чтение-запись-исполнение можно обозначить как МОД (ификация), доступ чтение-исполнение как ЧТ (ение), а полный доступ как ПОЛН (ый). Тогда группы доступа к каталогу "Статистика" будут иметь примерно такой вид:

- Статистика_ПОЛН;
- Статистика_МОД;
- Статистика_ЧТ.

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

"расшаривая", т.е. делая доступ в сети ресурс нам остается лишь занести туда наши группы доступа.

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

очищаем флажок переноса разрешений на объект, и тут же получаем запрос о следующем действии:

конечно для наших целей проще "удалить", однако подобные надписи лучше читать, поначалу хотя бы :-)

указываем наши группы по кнопке добавить (можно выбирать сразу несколько групп или пользователей):

осталось привести список разрешений (ACL)

нажмем "дополнительно", чтобы перейти к более детальному разделению прав...

выберем "показать/изменить":

за разнообразием :-) действий как то "теряется" выпадающий список "Применять" - обязательно поможет при выборе распространения наследования разрешений,

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

Об особых группах (есть и такие :-)

Everyone (Все) - тут трудно комментировать, по сути все.
Authenticated Users (Прошедшие проверку) - тоже самое, что и ВСЕ, но только без анонимных пользователей (гостей)
Network Users (Сеть)- пользователи, осуществляющие доступ к ресурсу по сети
Interactive Users (Интерактивные)- пользователи, получающие доступ к ресурсу на том компьютере, за которым они непосредственно работают.

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

Например, если к ресурсу имеют доступ все сотрудники, имеющие учетные записи для домена, достаточно включить доступ для "Прошедшие проверку".

Регламентирование членства в группах осуществляется с помощью Restricted Groups - правила, ограничивающего членство в указанных группах. Если кто-то добавит себя в группу с ограниченным доступом, то по истечении срока обновления правил (для DC это 5 минут) он будет исключен из этой группы.

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

в этой чистой оснастке мы можем выбирать любые оснастки в любом удобном для нас сочетании

нажимаем кнопку "добавить" и видим:

выбираем оснастки Active Directory-пользователи и компьютеры, групповую политику, где выберем для нашего примера:

т.е. политику всего домена, и также оснастку управления компьютером

теперь мы увидим:

нажимаем ок и выбираем нужный раздел политики:

нам надо определиться с безопасностью :-)

ограничим полный доступ группой администраторов домена (обратите внимание, именно к группе, а не к тем ресурсам, к которым у этой группы есть допуск):

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

Сформируем группы нашей организации согласно структуре:

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

Возможности NTFS

Итак, что же мы имеем в NTFS:

- Возможность шифрования (encrypt) файлов и папок, которые находятся на разделе NTFS с применением EFS (Encrypting File System - шифрующая файловая система)
- Возможность сжатия файлов и папок (отметаем эту функцию в данном случаи за ненадобностью)
- Возможность устанавливать разрешения (security permissions) для файлов и папок при помощи списков управления доступом (access control lists)
- Возможность смены владельца (take ownership) файлов или папок для пользователя или администратора с соответствующими разрешениями
- Возможность аудита доступа к файлам и папкам.

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

Разрешения доступа (security permissions) для файлов и папок при помощи списков управления доступом (access control lists)

А вот разрешения доступа имеют прямую практическую ценность.

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

Запретить "удаление" (Оно разрешает или запрещает удаление файла или папки. Если для файла или папки отсутствует разрешение «Удаление», объект все же можно удалить при наличии разрешения «Удаление подпапок и файлов» для родительской папки) для бухов я оставляю на ваше усмотрение, а вот возможность удаления подпапок и файлов на первое время можно и запретить (Разрешает или запрещает удаление подпапок и файлов даже при отсутствии разрешения «Удаление» (применимо только к папкам) ). Конечно это стоит делать очень индивидуально и не для больших по количеству объектов ресурсов - можно запутаться. Запомните эту возможность еще и потому что в следующей статье речь пойдет о подмене файлов :-). Но если запретить нельзя в конкретном случае, тогда нам поможет....

Аудит файлов

Для чего нужен аудит? Для обеспечения контроля за предоставленным доступом к информации (нашим базам) и возможности определения несанкционированного доступа.

Аудит настраивается для каждого файла или папки при помощи Auditing tab (вкладки Аудит). Аудит, однако, не установлен в Win 2000 Pro по умолчанию и если вы хотите осуществлять аудит файлов и папок, вы должны сначала создать Audit Policy (Политику аудита). В Win 2000 Pro, это осуществляется через Local Security Settings console (Консоль Установки Локальной Безопасность) (которая также может быть запущена из Group Policy tool (инструмент Групповая Политика). Audit Policy настраивается как показано на рисунке ниже:

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

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

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

ой, что это за надпись?

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

Аудит доступа к объектам

чтобы было понятней, расшифрую:

Аудит доступа к объектам Определяет, подлежит ли аудиту событие доступа пользователя к объекту — например, к файлу, папке, разделу реестра, принтеру и т.п., — для которого задана собственная системная таблица управления доступом (SACL).

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

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

заодно можно и остальные типы аудита сразу проставить :-), но это не рекомендации, так как многое зависит от конкретных задач, описание аудитов есть в справке Windows:

а как проверить, кто удалил файл? смотрим журнал безопасности в логах событий (в данном случаи это "успех" выполнения)

однако лог не говорит, ЧТО удалено!

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

Право владения

Несколько слов надо сказать о «владельцах ресурсов». Тут есть опасность по забывчивости оставить дыру. Дело в концепции ownerships (прав владения) , которая контролируются через Owner tab (вкладку Владелец) advanced security settings (Дополнительных настроек безопасности) файла или папки. Однако тот, кто имеет право Full Control или дополнительное разрешение Take Ownership (Смена владельца), может стать владельцем файла или папки. Расширение правил состоит в том, что пользователь с правами администратора может всегда стать владельцем, даже если не имеет NTFS-прав доступа к файлу или папке. Права владения могут быть только взяты, но не даны.
Таким образом, мы должны помнить, что давая права администратора, пусть даже локального, мы тем самым позволяем ему доступ ко всем локальным файловым ресурсам!

Интересным моментом для понимания концепции защиты является назначение прав через групповые политики, так как мы можем, имея всего лишь привилегию “Restore files and objects” (Восстановление файлов и объектов), стать такими же владельцами файлов, как администраторы :-)

Но и это еще не все. Утилита subinacl из W2k reskit это позволяет сделатьиз командной строки, а 2003 сервер – и вовсе через GUI

Автономные файлы

Offline Files (файлы, доступные автономно) - свойство Windows 2000, дающее компьютерам-клиентам кэшировать файлы и затем работать с ними автономно. Так как это в данном случае является отрицательным свойством, т.е.мы не хотим кэшировать папку, просто очищаем окошко 'Allow caching of files in this shared folder' (Позволить кэширование файлов в этом общем ресурсе), как показано ниже

NTFS - создаем группы - еще раз коротко...

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

Так для чего нам группы?

Пожалуй, довольно разумным шагом будет защита всего каталога базы данных - пользователь, имеющий доступ к каталогу, автоматически становится владельцем ВСЕЙ ИНФОРМАЦИИ в этой базе (хотя и не очень очевидно на первый взгляд, почему всей, но это факт).

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

На этом пока все. Отдельную ссылку хочу дать для тех, кто задается вопросом, а как происходит Авторизация в Windows 2000/XP со службой каталогов.

Конечно посмотрите Администрирование ресурсов в Windows 2000 (Часть 1) и (Часть 2)

В следующей статье я расскажу о сетевых ресурсах, протоколе IP/Sec и защите с помощью средств 1С.

Принимаются любые предложения по улучшению и точности изложения на gilev_slava собачка mail.ru.

Хочу выразить признательность Дмитрию Королеву за помощь в вопросах консультации.

С уважением, Гилев Вячеслав aka Demiurg