Рекомендации по хранению рабочих паролей для небольших групп

Это не технический вопрос. Как небольшие организации обеспечивают безопасность конфиденциальной информации, которой должны делиться несколько человек, например паролей root для рабочих серверов? Не все люди, которым необходим доступ, работают в одном и том же месте. Новые пароли можно раздавать по телефону, но какие правила следует соблюдать для членов команды при хранении паролей?

ОБНОВЛЕНИЕ: этот вопрос не о правильном использовании паролей root - это просто пример. Возможно, лучшим примером будет парольная фраза SSL или любой другой пароль, которым должны делиться люди, выполняющие административные задачи. Дело в том, что пароли root и тому подобное необходимо генерировать и хранить, и обычно доступ должен иметь более одного человека, иногда эти люди работают в разных местах. Вопрос в протоколах хранения. Спасибо.


person scotts    schedule 03.04.2009    source источник


Ответы (6)


Вы не должны раздавать (или использовать) пароли root каким-либо серверам, производственным или иным. Вы не должны делиться паролями.

Люди должны входить в систему как они сами (аутентификация) со своими собственными паролями идентификаторов пользователей; это половина картины.

При правильном входе в систему им должны быть предоставлены соответствующие права (сторона авторизации изображения). Вы можете использовать такие вещи, как sudo для общих целей ОС, а также механизмы прав внутри баз данных и т. д.

Это два отдельных вопроса. Не пересекайте ручьи!

person MarkusQ    schedule 03.04.2009

Я лично рекомендую людям, столкнувшимся с подобными проблемами, использовать что-то вроде Keepass или roboform для хранения паролей. Эти программы шифруют ваши пароли на флэш-накопителе с помощью мастер-пароля, который человек помнит, так что ему нужно запомнить только мастер-пароль. В случае, если кто-то потеряет свой флэш-накопитель, у него будет время, в течение которого он может сообщить о скомпрометированном флэш-накопителе и разрешить вам сменить пароль. Потребуется некоторое время, в зависимости от надежности мастер-пароля, прежде чем человек, укравший флэш-накопитель, сможет подобрать мастер-пароль, чтобы получить все остальные сохраненные пароли.

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

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

Редактировать: Oh Roboform также имеет онлайн-сервис синхронизации паролей через SSL. Таким образом, вы можете просто попросить людей восстанавливать пароли с помощью синхронизации. Это круто, когда привыкаешь.

person AaronLS    schedule 03.04.2009

С появлением sudo нам редко приходится использовать пароль root. В моем старом магазине пароль root был написан на карточке, запечатан в конверт и заперт в ящике стола в зоне для системных администраторов. У тех, кому нужно было знать, были ключи от ящика.

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

Эта система, вероятно, действительно плохая профессиональная практика, но в маленьком магазине, где все всех знали, она работала хорошо.

person Norman Ramsey    schedule 03.04.2009

В лаборатории прототипов и исследований и разработок, где я раньше работал, были «стандартные» лабораторные пароли для таких вещей, как root, административный доступ к консолям, коммутаторам и т. д. Они просты, легко запоминаются и сообщаются в устной форме всем, кто в них нуждается. В общем, если вы могли физически попасть в лабораторию, вы имели право на эти пароли.

На заводе были построены и настроены новые системы для клиентов. Заказчик должен был выбрать все пароли, и они были напечатаны на наборе бланков, прикрепленных к стойке с системами. При необходимости был предоставлен удаленный доступ, а пароли были отправлены по электронной почте или переданы по телефону. Было вполне ожидаемо, что заказчик изменит эти пароли, как только система будет доставлена ​​ему.

Что касается ИТ- и производственных лабораторий, почти ни у кого не было root-доступа. Почти у всех был доступ к sudo где-то между отсутствием ограничений и только возможностью монтировать виртуальные файловые системы... в зависимости от человека и системы. Очень редко можно было получить доступ sudo для запуска оболочки с правами root. Это оставило очень четкий журнал всех команд, которые вы запускали как root. Это бревно использовалось для смолы и перьев более чем одного человека на протяжении многих лет.

В службе поддержки/службе поддержки, которую я выполнял много лет назад, каждый эксперт по инструментам выбирал свои административные пароли. Они были записаны в конверте, который был заперт в сейфе в машинном зале. Если кому-то нужен доступ администратора, он может открыть конверт, прочитать пароль и отметить в журнале, что он знает пароль, а затем повторно запечатать пароль в конверте. Владелец инструмента должен был решить, нужно ли менять пароль. Эта система использовалась более 5 лет... и в одном случае действительно помогла проекту пережить "автобусное испытание" (сердечный приступ) для одного члена команды.

Различные стандарты для различных систем и лабораторий. Это разумно. Я считаю, что когда пароли должны быть разделены, лучше всего, если пароль будет простым, коротким и сообщен устно (либо лично, либо по телефону). Я обнаружил, что единственный пароль, которым нельзя делиться, — это пароль от моей личной учетной записи. Любые пароли root/admin/tool ​​должны быть сохранены как минимум в одной другой голове... если они не записаны каким-либо образом.

person Stan Graves    schedule 01.07.2009

вы можете использовать такую ​​программу, как anypasswordpro, для обмена паролями. Он зашифрован и имеет уровни доступа :)

person Community    schedule 03.04.2009

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

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

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

Например:

Пароль: VMacp@ss1

Обфускация: один 2 es df es 23 at sd pee fd см. dfs см. fxz ay df EM sd VEE

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

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

person Matias Nino    schedule 03.04.2009