Парольная защита - Форум по вопросам информационной безопасности

Давайте я поясню свою реплику про "созидательную" деятельность, а выводы делайте сами. Итак, вы решили записывать пароли в журнал (файлик, тетрадку и т.п.).

1. Нарушена конфиденциальность пароля, и чыеловек, ведущий журнал, получает неограниченные права на действия в защищаемой системе. Вы же не будете утверждать, что безопасник не является потенциальным нарушителем?

2. В силу п. 1 нарушен принцип неотказуемости от действий. Пользовтель никаму ничего доказывать не должен, это вам придется доказывать, что именно этот человек совершил данное нарушение. Доказательная сила логов основана на том, что "кроме него никто этого сделать не мог - пароль-то никто больше не знает". В вашем случае этот принцип нарушен, и придется искать дополнительные доказательства того, что нарушение совершгшил именно пользователь.

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

4. Вследствие этого пароли пользователей в вашей системе меняются крайне редко. Правда? А это мегакосяк.

Это минусы. Плюсов не наблюдаю, если видите - расскажите (вариант "по инструкции положено" не рассматривается).

Единственное, ради чего стоит хранить НЕКОТОРЫЕ пароли - это аварийный доступ в систему в экстренной ситуации в отсутствии специалистов, которые должны штатным образом выполнить нужную операцию. Но для этого заводится отдельный "пожарный" пользователь, пароль которого хранится в сейфе в запечатанном конверте и используется только в случае крайней необходимости.

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

У каждой системы есть и свои плюсы и минусы.
1.Если система важная то для генерации выделяется несетевой АРМ с выполняемыми требованиями ФСБ.
2. Используется сертифицированный генератор (псевдо) случайной последовательности
3. Можно оператором 1,2 назначить отдельное лицо - не админа
4. Т.Н. журнал учета содержит n п\п , дата, ФИО получателя, Роспись получателя, Роспись выдавшего, если журнал грифованный только тогда в нем можно указывать и сам пароль для контроля (но я бы не стал)
5. Оператор генерит массив, режет его на нужные куски, конвертует и выдает админу.
6. Админ раздает конверты под роспись не видя содержимого (как ПИН у пластиков) можно выдавать не конверты а девайсы (выбирайте какой Вас устроит) их много и разные от PFID до банальной флешки
7. Эти простые меры отменят угрозу указанную Малотавром как 1
8 Пункт 6 закрывает угрозу 3 Малотавра
9 Пароли меняются по графику - хощь на сеанс - хошь на день
10 КТ - это кастрированный вариант для ГТ.
Нет желания усложнять - и не надо!
Пользуйтесь виндовыми (OS) ну или там какие у вас...средствами хоть мышкой со сканером пальчика.
11 Практика-критерий истины!
Жизнь подскажет как лучше

А это в каком то документе прописано?где это можно прочиать?реквизиты документа.

2Алекс
Книжек на эту тему прорва.
Есть и нормы - больше буржуйские.
Вам зачем реквизиты от филипин или от шведов?
Почитать можно в интернете - надо просто точно сформулировать поисковый запрос.
Ссылаться на грифованные не стану - НЕ Комильфо, да и не нужно оно Вам.
Почитайте и используя великое правило ППП (thumb) напишите свою нетленку.
Не открывая ваших системных особенностей (они - таки есть) и привычек руководства - каких советов со стороны Вы ждете?

Да я как бы просто общую суть организации парольной защиты понять пытался...

> 11 Практика-критерий истины!

В подтверждение давнного пункта. На аттестованном компе с установленны сертифицированным SecretNet и таким же Аккордом (или Соболем, не помню), заблокированная ввиду забытости пароля учетка админа была взломана за 15 минут без нарушения пломбировки корпуса. Наблюдал собственными глазами, очень повеселился. Отсюда и обоснованные сомнения в целесообразности п. 1-10.

Требования ФСБ - веский и правильный аргумент, область действия которого ограничивается защитой гос. тайны. Но перенос решений с гос. тайны на коммерческие системы - дело неблагодарное, а с учетом п. 11 - просто вредное :)

а как же орг.-распорядительная документация? пишешь инструкции админа ЛВС или безопасности, а так же пользователя! там указываешь ответственность каждого за то или иное действие! + политика безопасности - там должно быть все расписано. И будет тебе счастье! =)

Уважаемые, на мой взгляд Вы смешали в кучу модели нарушителя ФСТЭК и ФСБ. Требование РД АС от НСД идентификации субъекта доступа не может быть выполнено, если его пароль известен кому-то помимо субъекта. В модели ФСБ субъект владеющий ключами (секретом) обычно нарушителем не является. Думаю, что ведение книги паролей пользователей на доступ для объекта ВТ, возможно, только при исключение администратора безопасности из числа возможных нарушителей и в общем случае добавит еще одну уязвимость.

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

Насчёт secret net то эт интересно при правильной настройке secret net и соболь (аккорд не настраивал) мы так и не смогли его сломать как ни пытались))