еще раз об Id

[phantom76]

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

 

[collection]

<!--QuoteBegin-phantom76+9:08:2007, 07:58 -->
<span class="vbquote">(phantom76 @ 9:08:2007, 07:58 )</span><!--QuoteEBegin-->есть ли способ сгенеривать новый id

[snapback]74819" rel="nofollow" target="_blank[/snapback]​

[/quote]
равнозначный потерянному без использования опции восстановления нельзя
<!--QuoteBegin-phantom76+9:08:2007, 07:58 -->
<span class="vbquote">(phantom76 @ 9:08:2007, 07:58 )</span><!--QuoteEBegin-->правильно я все понимаю

[snapback]74819" rel="nofollow" target="_blank[/snapback]​

[/quote]
все зависит от того привильно ли Вы понимаете где включать проверку паролей

 

[phantom76]

в основном конфигурационном документе на сервере...

 

[Constantin A Chervonenko]

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

Не правильно.
1.Пароль меняется "У-НУТРЕ" конкретного id-шника (т.е. другие пароли к нему уже не подходят)
2.На сервер с включенной проверкой теперь пускают только владельца этого подновленного id-шника
НО:
id cо старыми паролями продолжают действовать там, где пароль не проверяется:
3.На других серверах/доменах (эта проверка м.б. и выключена)
4.На клиенте (в локале)

Т.е. смена пароля не помешает злоумышленнику (предварительно укравшему ваш id) подделать док-т с вашей подписью, расшифровать вашу базу

Вывод: при компроментации ключей надо менять ЭТИ КЛЮЧИ, а не пароль к ним

 

[phantom76]

а чего не так? пункты 1 и 2 ,я так и понимал...

3.4. - тоже мне были ясны... было сомнение, о том что отваляться ли старые id

про ключи согласен... самый надежный способ.

спасибо!

 

[Constantin A Chervonenko]

Ради НО и написАл уточнение. У тебя было "старые копии не действуют, если на сервере ...". А сервера-то может и не быть (в нужный момент)!

 

[phantom76]

окей, как в таком случае будет работать "защита" на локале?
с чем будут сравниваться ключи id-шки ?
насколько я знаю, в случае даже если БД перетянули на локал, даже если стоит опция Enforce ACL, если конечно база не зашифрована.
все равно можно, при условии, что знаешь точное имя управляющего БД, создать аналогичного пользователи и получить доступ к данным к локальной копии.
во всяком случае в 5-ке это прокатывало.

 

[collection]

к слову, не помешает:
To prevent users whose access levels are Depositor or No Access from using the operating system to copy the database, encrypt the database with the server ID through the local Encryption option. This ensures that the database, even when copied, is illegible to anyone who doesn't have access to the server I
<!--QuoteBegin-phantom76+9:08:2007, 15:23 -->
<span class="vbquote">(phantom76 @ 9:08:2007, 15:23 )</span><!--QuoteEBegin-->как в таком случае будет работать "защита" на локале

[snapback]74915" rel="nofollow" target="_blank[/snapback]​

[/quote]
-снимем шифрование
-меняем ключи
-устанавливаем шифрование

 

[Constantin A Chervonenko]

окей, как в таком случае будет работать "защита" на локале?
с чем будут сравниваться ключи id-шки ?
насколько я знаю, в случае даже если БД перетянули на локал, даже если стоит опция Enforce ACL, если
все равно можно, при условии, что знаешь точное имя управляющего БД, создать аналогичного пользователи и получить доступ к данным к локальной копии.

Все так. id-шки ни с кем не сравниваются. По определению: при наличии ФИЗИЧЕСКОГО доступа к базе (мимо сервера) защита по ACL бессмысленна и потому отключается (Consist.ACL - отладочный бантик).

конечно база не зашифрована.

Вот именно! Я о том и талдычу. Зашифрованную базу хрен откроешь, если предварительно не украл id-шник. Но к краденому id подойдет старый пароль

 

[phantom76]

проделайте батенька эксперимент:
- скопируйте любую базу на локал с сервера, удалите себя с ACL,
далее: - управление ACL, - закладка дополительно - установливаем опцию - enforce ....... ACL.

закройте базу, а потом попробуйте получить контроль над ней? в 5-ке да можно было открыть любую базу, а в 7-ке не получиться... попробуйте и расскажите, что получилось.

 

[puks]

<!--QuoteBegin-phantom76+10:08:2007, 11:05 -->
<span class="vbquote">(phantom76 @ 10:08:2007, 11:05 )</span><!--QuoteEBegin-->закройте базу, а потом попробуйте получить контроль над ней? в 5-ке да можно было открыть любую базу, а в 7-ке не получиться... попробуйте и расскажите, что получилось.

[snapback]75055" rel="nofollow" target="_blank[/snapback]​

[/quote]

А если ее потом на любой сервер и под Full Admin?

 

[Kee_Keekkenen]

Для: phantom76
к тому же на локале включить менеджеские права на нешифрованной бд (на шифрованной не пробовал), даже если вообще никаких прав на базу не имеешь, раз плюнуть..

 

[phantom76]

вы правы коллеги

 

[phantom76]

хотелось бы еще обсудить вопросы безопасности id-файлов: способы передачи id - пользователю (через адресную книгу, через сетвой ресурс) , безопасные хранилища id,
расположение id на стороне клиента (локал, сетевой ресурс). Как безопаснее хранить id-файлы (сейчас хроню в базе и копии на сетке) и как противодействовать хищению id с клиентского места?

на текущий момент - хранилище бд mail-in + сеть
на клиентах - локал, стоит ли уносить их на сетевой диск?
как лучше хранить администраторские id и cert ?

 

[puks]

Я не сохраняю в адресной книге (но это зависит от конфигурации). Есть копии на диске, архиве, болванках и тп. Кроме того, если используешь восстановление, то они есть еще и в базе, которая шифрована, как и любая база имеет права доступа. Особенно внимательно к хранению cert.id, ou и серверных. Конфигурации с работой с сеткой мне не нравятся, так как очень чувствительны к сети и не поддерживаются IBM. Но все это дело вкуса. За все время работы никто у меня не жаловался на хищение id.

 

[collection]

храню id пользователей на сетевом диске,потоиу как вопрос безопастности в организации так остро не стоит, а вот восстанавливать, менять пароли, обеспечивать доступ нескольких пользователей под одним id без использвания механизма rouming users очень удобно