Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Всё о задаче AdminP. Часть вторая   Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть
О Notes Читать статью
 
Всё о задаче AdminP. Proxy-действия в R5 и Domino 6   Приложение к статье об административном процессе
О Notes Читать статью
 
Всё о задаче AdminP. Часть первая   Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Азы аудита безопасности

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

Статья опубликована в ноябре 2001 года в Advisor Expert: Lotus Domino Administration, издания Advisor Media, Inc.
Статья знакомит читателей с простейшими приемами проведения аудита сервера Domino. Использование этих приемов посильно начинающему администратору без привлечения сторонней помощи

Мэт Холт (Matt Holthe)
mattholthe@breakingpar.com
Защита информационных систем - одна из самых актуальных тем наших дней. Что может противопоставить администратор Domino вирусам и хакерам? Ниже подробно излагают некоторые детали, специфичные для Domino. Здесь опущены проблемы защиты на уровне сети и межсетевых экранов. И, конечно же, материал статьи не сможет заменить аудита, проведенного профессионалами. Служба поддержки Lotus (Lotus Field Support Services) проведет аудит ваших серверов Domino, войдя в мельчайшие подробности и уделив внимание вещам вроде настройки производительности серверов. Подробнее об услугах службы поддержки можно узнать >>>
Описываемые возможности собственного (внутреннего) аудита должны выполняться периодически, лучше всего ежеквартально, но не реже, чем раз в год. Автор рекомендовал бы в качестве регламента выполнение одного-двух шагов аудита в месяц. Таким образом работы не займут много времени, как если бы они выполнялись все сразу, но Вы достигнете результата. Подобный распорядок будет удобен также в случае введения в курс нового администратора, которому будет предоставлена возможность лучше ознакомиться с системой
Нет никакого определенного порядка выполнения описываемых работ относительно друг друга, каждая работа может быть выполнена независимо от других. Работы, о которых пойдет речь, не сложны, но позволят обеспечить безопасность системы. Несколько рассматриваемых моментов затрагивают также вопросы производительности. Но, как было сказано ранее, описываемые простейшие приемы не могут гарантировать на все 100% защиту от взлома и оптимальную производительность. Это только верхушка айсберга, но выполнение этих работ позволит избежать начисления штрафных очков при стороннем аудите системы профессионалами.

Таблицы управления доступом (Access Control Lists, ACL's) баз данных
Проверьте таблицы управления доступом всех баз данных на ваших серверах. На Notes.net Вы сможете найти утилиту (перейти >>>), которая облегчит Вам этот аудит. Она обрабатывает все базы, расположенные на сервере, и формирует в своей базе документ для каждой записи в ACL каждой базы. Вы можете использовать для анализа содержащиеся в этой базе представления или дополнить их собственными. Вот каким моментам Вы должны уделить внимание:

  • В любой таблице управления доступом (ACL) запись для пользователя -Default- должна быть установлена в NoAccess (Нет доступа), как показано на рис. 1. Это должно быть положено в основу вашей корпоративной политики, что доступ предоставляется пользователям / группам вместо разрешения доступа кому угодно

Рис.1. Запись для -Default- устанавливается в NoAccess

  • Каждая база должна содержать запись Anonymous для управления доступом не прошедших аутентификацию web-пользователей. Доступ для этой категории пользователей устанавливается исходя из предназначения базы (Так, Anonymous не должен получить доступ к базам names.nsf и log.nsf - уровень доступа следует установить в NoAccess - Нет доступа, в то время как к заглавной странице корпоративного сайта должен быть предоставлен некоторый уровень доступа)
  • Для баз данных, которые должны быть открыты для всех пользователей компании (таких как Корпоративная Адресная Книга), используйте маски с подстановочными символами как то */Company Name с соответствующим уровнем доступа
  • Ограничивайте число индивидуальных записей в таблице управления доступом. Другими словами, используйте группы, когда это возможно. Это намного упростит процесс изменения (предоставления/отзыва) прав доступа в большом масштабе (в случае приема на работу, увольнения сотрудника или перевода в другой отдел), поскольку будет необходимо внести правку в несколько групп, а не во все базы данных
  • Проверьте уровень доступа в поле Maximum internet name & password (Предельный уровень доступа через Интернет) для каждой базы данных (см. рис.2). Это свойство находится на закладке Advanced (Дополнительно) Таблицы управления доступом базы. Вышеописанная утилита не контролирует этот уровень доступа, но Вы можете внести изменения в ее код, чтобы учитывать в своем аудите и этот параметр. Даже для тех web-пользователей, кто прошел аутентификацию, этот уровень доступа ограничивает права доступа к базе из браузера. Включите также в Вашу политику безопасности установку соответствующего предельного уровня доступа web-пользователей. В тех базах, к которым не нужен доступ пользователей из Internet/Intranet, ограничивайте его NoAccess (Нет доступа)

Рис.2. Ограничение доступа из Intranet/Internet

  • Ищите записи, которых не должно быть в ACL баз. Например, группа, которая уже не используется. Или прежний сотрудник мог быть перечислен индивидуально. Исключайте группы и индивидуальные записи, которые больше не используются. Следование этому правилу снизит уязвимость системы от хакеров, сокращая число возможных входов
  • Ищите избыточные записи групп и пользователей. Например, Вы можете найти две группы с совершенно идентичным доступом к базе данных. Выясните, имеется ли причина, по которой необходимо использовать две группы вместо одной объединенной. Или другой пример, пользователь имеет индивидуальную запись с тем же самым уровнем доступа, что и группа. Тогда неплохо бы включить его в состав группы

Настройки серверного документа
Есть множество настроек, которые необходимо проверить в серверном документе. Доступ к серверным документам можно получить через представление Server\Servers Корпоративной Адресной Книги
Откройте серверный документ, закладку Security (Безопасность) - см. рис. 3

Рис.3. Закладка Security серверного документа

  • Убедитесь в наличии группы Отказа в доступе (Deny Access group) и в ее своевременном обновлении. Это первая линия обороны, даже если кто-либо имеет доступ Управляющего (Manager) к базе данных, он не получит возможность работать с сервером, если входит в эту группу
  • Проверьте, какие пользователи/группы уполномочены создавать новые базы данных и реплики на сервере. Это полномочие должно быть ограничено в максимально возможной степени. Вы должны также проверить всех членов этих групп, чтобы исключить лишних людей. Возможно, кто-то перешел на новую должность и вместе с этим утратил право создавать новые базы и реплики
  • Проверьте список пользователей, которые могут администрировать сервер из web-браузера. Эта настройка разграничивает, доступно или нет пользователю открыть базу webadmin.nsf из браузера. На серверах, обслуживаемых автором, этот доступ не был предоставлен никому, а используется самопальная утилита (расположение и имя которой известно только администраторам), которая поддерживает некоторые из функций базы webadmin.nsf. Использование такой утилитки и ее размещение в "скрытом" месте предотвращают попытки хакеров получить доступ к webadmin.nsf, в то время как доверенные администраторы имеют возможность администрировать сервер из браузера
  • Проверьте списки тех, кто уполномочен на выполнение агентов (поля секций Agent Restrictions и Java/COM Restrictions). Хорошей политикой в этом случае является использование специально сгенерированной учетной записи, доступной только тем, кто проверяет и подписывает код фоновых агентов. В этом случае, даже если автор агента уволился, агент (если он подписан специальной учетной записью) будет продолжать работать. Не раздавайте эту учетную запись разработчикам, а постройте процесс через запрос, так, чтобы администраторы сами проверяли и подписывали агентов этой учетной записью
В серверном документе на закладке Internet Protocols (Интернет) -> HTTP (см. рис.4 и 5)

Рис.4. Закладка Internet Protocols -> HTTP серверного документа

  • Установите значение поля Allow HTTP clients to browse databases (Разрешить клиентам HTTP просматривать базы данных) как No (Нет) - рис.4. Это предотвращает показ списка всех расположенных на сервере баз в отклик на URL-запрос http://<server>/?Open. В противном случае (значение поля - Да) этот URL-запрос возвратит список баз. Если Вам требуется эта возможность, то лучше использовать "самописного" агента, который формирует и показывает список баз данных, но при этом находится в базе, и его местоположение оказывается "скрыто". На Notes.Net Вы можете найти статью, опубликованную недавно и содержащую описание, как разработать такого агента. Статью можно найти >>>.
  • Включите журнал URL-запросов к серверу в отдельный log-файл (что автор рекомендует) или в базу Domino Log (рис.5). По возможности, разместите этот журнал на выделенном физическом диске. Использование выделенного диска рекомендуется в качестве уровня защиты от отказа диска. Ведение журнала поможет Вам проследить такую информацию, как IP-адреса пользователей и базы данных, на которые была осуществлена попытка взлома

Рис.5. Закладка Internet Protocols -> HTTP. Секции настройки протоколирования, тайм-аутов и работы web-агентов

  • Установки Времени ожидания (секция Timeouts) оказывают большее влияние на производительность, чем на защиту, поэтому лишь бегло будет рассмотрено, к чему эти настройки относятся:
- Input timeout (Время ожидания ввода). Время [в минутах], за которое клиент должен послать запрос после того, как соединился с сервером. Значение из этого поля сервер использует, когда клиент после соединения с сервером не посылает команду с заголовком keep alive на сервер в течение указанного времени. Большинство текущих версий браузеров посылают заголовки keep alive и не нуждаются в использовании этой настройки
- Output timeout (Время ожидания вывода). Максимальное время [в минутах], в течение которого сервер должен послать ответ клиенту. Частая причина ошибки времени ожидания ответа - недостаточный размер кэша или нехватка оперативной памяти для обработки запросов. Ошибки времени ожидания могут также возникать на медленных модемных каналах при загрузке файлов большого размера
- CGI timeout (Время ожидания CGI) - максимальное время [в минутах], в течение которого CGI-программа (запустившаяся на сервере) должна завершить работу. Удостоверьтесь, что знаете, как долго выполняются Ваши CGI-скрипты, прежде чем установить это значение
- Idle thread timeout (Время ожидания неактивных запросов) никак не влияет на серверы R5 (и используется для обратной совместимости на серверах более ранних версий)
Также в серверном документе на закладке Transactional Logging (Журнал транзакций) - см. рис.6:

Рис.4. Закладка Transactional Logging серверного документа

  • Включите Transactional logging. Это позволит Вам быстрее загрузить сервер после падения сервера. По возможности, разместите файл журналирования на выделенном физическом диске (это позволит быстрее восстановить работоспособность сервера в случае падения диска с данными вашего сервера). Также по возможности используйте отдельный контроллер диска. В этом случае Вы повысите производительность системы. Лучшим решением (если Вы можете себе позволить) будет установка файла журналирования на зеркалируемом диске, так чтобы он мог быть восстановлен в случае отказа жесткого диска
  • Размер области жесткого диска, отводимый для log-файла, по умолчанию 92 Mb. Если места недостаточно, уменьшите это значение
  • Автоматическое восстановление поврежденной базы установлено по умолчанию. В случае, если база не может быть восстановлена на основании журнала транзакций, сервер автоматически запускает задачу Fixup для этой базы. По этой причине для перезагрузки сервера требуется больше времени в случае, когда журнал транзакций не помогает. Отключение автоматического запуска задачи Fixup приведет к тому, что восстановление базы придется запускать вручную, для того чтобы можно было работать с ней
  • Что касается выбора значения Метода записи в журнал (Logging style), используйте Circular (Циклический) на сервере, не загруженном изменениями. Используйте установку Archive (Архив) на сервере с большой загрузкой. Установка этой опции включает необходимость ожидания, когда журнал транзакций станет неактивным (все записанные в него транзакции будут завершены), после чего его можно заархивировать и использовать файловое имя вновь

Прочие установки Адресной Книги (Domino Directory)
Также требуют проверки некоторые другие настройки Корпоративной Адресной Книги (Domino Directory)
В представлении Server\Web Configurations (Сервер\Настройки Web):
  • Удостоверьтесь, что созданы File Protection документы (документы Защиты файлов) на всех серверах для всех каталогов. Для того, чтобы получить доступ к файлам в этих каталогах, пользователь должен быть прописан в настройках документов
  • Может иметься лазейка, когда кто-либо (допустим, хакер) может написать HTML-страницу и размещать данные на Вашем web-сервере. File Protection документы предотвращают подобное. Например, Вы хотите закрыть все базы данных каталога от любых операций. Но на уровне ACL пользователям Notes разрешены эти операции. При соответствующей установке в документе File Protection никакая операция не может быть выполнена над файлом в защищенном каталоге, независимо от того, аутентифицирован пользователь или нет
В представлении Server\Programs (Сервер\Программы):
  • Удостоверьтесь, что Вы знаете все программы, назначенные к выполнению - что они из себя представляют и т.д. Могло быть, что поставленный в расписание еженедельный процесс сейчас, в связи с изменившимися обстоятельствами, перестал быть нужен
  • Проверьте время работы назначенных задач [на перекрытие]. Например, могут иметься три задачи, стартующие одновременно. Разнесение времени старта этих задач может снизить серверную загрузку и способствовать повышению производительности сервера
  • Проверьте, насколько часто назначены к выполнению периодические регламентные задачи. Возможно, Вы еженедельно производите сжатие всех баз, в то время как нуждаются в этом лишь некоторые из них. Было бы лучше выполнять сжатие этих немногих раз в неделю, а для всех остальных запускать задачу Compact вручную раз в месяц или в два
В представлении Server\Connections (Сервер\Подключения):
  • Убедитесь, что все подключения до сих пор необходимы, и Вы знаете, для каких целей они предназначены. Возможно, документы подключения были необходимы несколько месяцев назад для поддержки совместного проекта с партнером. По окончании проекта документ уже не нужен (и сторонняя компания не должна иметь доступа к вашему серверу)
  • Проверьте частоту сеансов репликации и маршрутизации почты. Возможно, во время осуществления совместного проекта была нужда реплицироваться каждый час. В теперешней фазе проекта, когда он постепенно сходит на нет (но совместные работы еще ведутся, и подключение необходимо), возможно, окажется достаточным расписание сеансов репликаций с интервалом 4 или 6 часов
В представлении Server\Configurations (Сервер\Конфигурации):
  • Проверьте, нет ли избыточных документов Configuration. Так, два различных документа могут содержать один и тот же набор установок. В статье, опубликованной в Iris Today в августе 2001 года (перейти >>>) имеется обсуждение, какие параметры когда будут использоваться при подобном дублировании. Но во избежании ошибок и для уменьшения беспорядка было бы уместно по возможности избавиться от дублирующего набора настроек
  • Поищите в файле настроек notes.ini определение переменной View_Rebuild_Dir (View_Rebuild_Dir=<drive>\pathname\). Это переменная может в значительной мере улучшить производительность вашего сервера. Когда сервер Domino R5 (задачи Update и Updall) перестраивает индекс представления, он использует запись информации во временный каталог (обычно, c:\temp). Это повышает производительность серверов по сравнению с версией R4 при построении индексов представлений. При назначении для этой цели выделенного диска (чем больше дискового пространства будет на диске, тем лучше) процесс займет еще меньше времени.Обратите внимание, что дисковое пространство, необходимое для перестроения индекса представления, может быть намного больше, чем фактический размер представления (отображаемый в Свойствах представления). В зависимости от того, насколько велики индексы представлений, Вы можете оценить, сколько дискового пространства необходимо

Резюме / ссылки
Есть надежда, что изложенный выше материал позволит Вам подвергнуть Вашу систему внутреннему аудиту. Помните, что хорошее правило - производить эти проверки ежеквартально, только так Вы можете опередить злоумышленников
Если Вы нуждаетесь в подробной информации по обеспечению безопасности в Domino, вот некоторые рекомендации:
В документе Overview of Notes/Domino security можно найти хороший обзор по безопасности в среде Lotus Domino (перейти >>>)
A Guide to Developing Secure Domino Applications - White Paper по разработке безопасных приложений Domino (перейти >>>)
Статья Securing the Domino Environment по обеспечению безопасности среды Domino (перейти >>>)

Читайте также на Notesnet.ru
Доступ к ADMIN.NTF (перейти >>>)
Десять заповедей администратора Domino (перейти >>>)

Примечания переводчика
1. В основном, эта утилита дублирует функциональность серверной задачи Catalog
2. Исключение могут составлять ресурсы типа базы mail.box. В этих ресурсах может потребоваться установка значений по умолчанию (-Default-) в Depositor (Корреспондент) при обязательной установке в этом случае поля Maximum internet name & password (Предельный уровень доступа через Интернет), - см. дальше по тексту - в NoAccess
3. К этому совету следует относиться с большой осторожностью. И, по крайней мере, решать ее придется на уровне всего домена, на который распространяется действие документа Group Адресной книги, а не на уровне одной базы Notes, как это может быть понято из контекста
4. Список, содержащийся в поле Administer the server from a browser (Администрирование сервера через браузер) с закладки Security, расширяется списком, содержащимся в поле Administrators (Администраторы) с закладки Basics (Основные)

Перевод: Николай Норкин
 
  Опубликовано — 06/11/2004 |    



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :

Мероприятия
Пресс-релизы
Биржа труда
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU