Войти
 
 
   
 
  
Новости 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

Средства защиты информации в Notes


Николай Норкин, CLP R5
Вятские Информационные Технологии
nickanor@mail.ru


Средства защиты информации в Notes
Часть 1 2 3
Аутентификация пользователя в системе. Личный и публичный ключи. Меры по сохранению и обеспечению безопасности учётной (ID) записи
В системе Lotus Notes/Domino аутентификация пользователя, работающего в клиентской среде Lotus Notes, производится на основе сверки выданных пользователю сертификатов, а также личного ключа шифрования пользователя с имеющимся в системе публичным ключом. Сама процедура аутентификации будет рассмотрена несколько ниже, сейчас же рассмотрим механизмы создания, хранения ключей и меры по обеспечению безопасности личного шифровального ключа
Итак, пара личный/публичный ключ создается в процессе регистрации пользователя администратором (или лицом, уполномоченным на это и имеющим доступ к учётной записи сертификатора) на основе ключа, находящегося в учётной записи сертификатора. Точнее, генерятся две пары ключей - основной (североамериканский) ключ и международный (International). До версии Domino/Notes 5.0.4, когда существовавший в США экспортный запрет ограничивал длину ключей шифрования, существовали две различные лицензионные версии продукта. Для стран Северной Америки использовались ключи длиной 630 бит, для лицензии International (не-североамериканских стран) длина ключа составляла 512 бит. С версии 5.0.4 ограничения на длину ключа с International-лицензии снято
Публичный ключ помещается в учётную запись пользователя (id-файл) и созданный одновременно в процессе регистрации документ пользователя в Корпоративной (общей) Адресной Книге (Domino Directory)

PERSON: Nick A Norkin/VIT/RU
Nick A Norkin/VIT/RU @ VIT
Public Keys
Certified public key:03003B02 ECCCFFB1 0AG0161B G002F0A9
31204D03 G0030200 01208800 992B2900
8F6425G0 024FG002 0BA65600 3B682500
20A25600 166B25C3 01A07C00 992B2900
8F6425G0 024FG002 0BA65600 3B682500
20A25600 166B25C3 4F3D5649 542F433D
5255434E 3D4E6963 6B204120 4E6F726B
696E2F4F 3D564954 2F433D52 55425604
00312E30 00424301 00034241 01003042
4C020076 024E4E50 001D4E22 380F7BDE
ACADE560 BA38FBC1 0170567E 8866B56E
21837355 E4863DCD 0A803302 F2084C43
02542F72 5F4286ED 4BF06E81 DA1A805D
B7415728 F9478BAD 2EFE01B5 E4EB8986
0702F147 CEB4702E 00454E04 009556G0
014D4108 0090D41E EC569F84 FC800050
55525341 464A89EB BD6098CE E30F3C97
F9676C2C C2829397 88F277AC BD2B2A99
07B6E995 1161A1B7 39DB58DA C56DD574
89CC7E60 3C87811D C91090C2 5B0B2253
CE95AEA7 E8A55D1D 758D0D3B B64C05A5
1E7D3824 42560400 312E3000 42430100
03424101 0030424C 02G00102 4E4E4400
AD693BB8 6F5FE428 5F6413FB 7F3819EC
B04730FB 9A33FF47 AC7AF8C6 DD2DE700
88992AD7 CEAA7865 796C9317 8FAC75B2
F3DAD07B 7A39A30C 16533828 2964F1BC
G003454E 04008352 G0014D41 08004D67
878AE2F7 E03B7400 50555253 414685EB
18753E4A 0DB83DEF E7BD49F8 8D6F9C6F
65CF0656 CD66B3F6 D36B7BE5 A19551F2
429E7008 79FB7AC9 AC38022A 7C7CBCC7
0FDC3055 ACE1AB40 76220402 1142D1BE
7FF6985D 2E12087B 48079719 22
X.509 certificateNot Available

Этот ключ будет использоваться сервером в процессе аутентификации пользователя. Другие корпоративные пользователи будут использовать его при отправке шифрованных сообщений на адрес этого пользователя и для проверки его электронной подписи на документах и элементах дизайна баз Notes. При повреждении документа Адресной Книги или ключа необходимо будет восстановить документ, экспортировав публичный ключ из учётной записи. Для этого откройте диалоговое окно User Security (через пункт Главного меню File -> Security -> User Security...) и на закладке Your Certificates выберите действие Mail, Copy Certificate (Public key)... Скопируйте ключ в буфер обмена, нажав кнопку Copy Certificate

Личный ключ попадает в генерируемый в процессе регистрации пользователя файл учётной записи и защищается паролем, вводимым при регистрации. Во время регистрации администратору предлагается задать место размещения файла учётной записи пользователя. Существуют два варианта размещения: в документе пользователя в Корпоративной Адресной Книге и в файловой системе рабочего места администратора. Рекомендуется сохранять файл учётной записи на диск, а не в Адресной Книге, и сразу передавать его пользователю, предварительно показав как сменить пароль и заставив его сменить пароль доступа к файлу. В таком случае у администратора не остаётся доступа к учетной записи пользователя. Обеспечение возможности восстановления доступа к учётной записи в случае утраты пользователем пароля (но не файла учётной записи!) при помощи задействования специального механизма (id recovery) будет рассмотрено в одной из следущих глав
Теперь несколько слов о размещении файла учётной записи в Корпоративной Адресной Книге. С точки зрения безопасности этот вариант проигрывает тем, что Корпоративная Адресная Книга находится в общем пользовании и получить этот файл может множество пользователей. При плохом выборе пароля администратором злоумышленник может получить доступ к учётной записи и использовать привилегии и ресурсы, предоставляемые данному пользователю
Однако в некоторых случаях размещение файла учётной записи в Адресной Книге - единственный вариант, при помощи которого пользователь может получить файл учётной записи и начать работу в системе. В этом случае желательно, чтобы пользователь получал файл учётной записи в процессе инсталяции клиента Notes. Тогда при подключении пользователя к серверу и передачи ему учётной записи этот файл удаляется из документа Адресной книги
После регистрации учётная запись пользователя содержит:
  • имя пользователя и лицензию Notes
  • две пары (североамериканский и международный вариант) личных и публичных ключей
  • два сертификата пользователя
  • сертификат от каждого сертификатора в иерархической системе имени пользователя
В процессе работы в файл учётной записи могут быть добавлены пользовательские ключи шифрования, генерируемые для поддержки разграничения доступа к информации в приложениях. Личный ключ и пользовательские ключи в учётной записи зашифрованы, используя ключ, генерируемый на основе пароля, вводимого пользователем. Имя пользователя и общий (публичный) ключ шифрования хранятся в открытом виде
Просмотреть или изменить содержимое учётной записи можно из пользовательского интерфейса, выбрав команду Главного меню File -> Security -> User Security...
С точки зрения безопасности учётных записей от случайного разглашения пользователем пароля администратору предоставляется возможность организации проверки пароля и периодической смены пароля пользователями
Для использования первой возможности нужно включить флажок Check passwords on Notes IDs: в документе сервера (секция Security) Корпоративной Адресной Книги и установить значение поля Check password в соответствующее значение в документе пользователя (секция Administration). В этом случае последний пароль, с которым зашёл пользователь, сохраняется сервером и если пользователь опасается за девственность своего пароля, он просто выполняет процедуру смены пароля. Другое дело, если злоумышленник первым сменил пароль к скопированному файлу учётной записи. Но тогда факт взлома будет очевиден пользователю (потому, что его не пускают в систему), о чём ему незамедлительно следует сообщить администратору.
Действенным средством профилактики безопасности учётной записи служит периодическая смена пароля пользователем. Для проведения систематических мероприятий по смене пароля пользователями достаточно к двум описанным выше настройкам документов Адресной Книги заполнить содержимое полей Required change interval: соответствующим количеством дней, по прошествии которых с момента последней смены пароля пользователю будет предложено сменить пароль и Grace period: - количеством дней, отведенных на смену пароля (Оба эти параметра находятся в секции Administration документа пользователя). Административный клиент предоставляет администратору возможность заполнить эти поля из закладки Пользователи и группы. Отметьте документы пользователей, выберите пункт Главного меню Actions -> Set Password Fields и заполните параметры в диалоговом окне

Часть 1 2 3

Материалы на Notesnet.ru:
Шифрование и электронная подпись документа >>>

Также рекомендуется к прочтению:
Lotus: Руководство по безопасности >>>
 
  Опубликовано — 08/01/2007 |    



Добавить комментарий
Имя * :
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