Лучшие практики и решения для обмена паролями [закрыто]

У нас есть различные пароли, которые должны быть известны нескольким сотрудникам нашей компании. Например, пароль администратора для наших интернет-роутеров, пароль для нашего веб-хоста, а также несколько «не-IT» паролей, таких как безопасные коды.

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

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

Можете ли вы предложить какие-либо программные решения для хранения и обмена паролями? Есть ли что-то особенное, о чем следует опасаться?

Какова распространенная практика в малых и средних компаниях для этого?

Я сталкиваюсь с этой проблемой каждый раз, когда захожу в новый стартап. Первое, что я делаю, это делаю пару «сейфов паролей» с помощью такой программы (или одной из ее производных):

http://passwordsafe.sourceforge.net/

Установите сильные комбинации и подбросьте их на сетевом ресурсе. Сегментация по областям ответственности ... центральная инфраструктура, производственные серверы, dev / QA и т. Д.

Как только наберется обороты, и если у меня есть соответствующие зависимости от среды Windows, я бы хотел перевести всех к этому

http://www.clickstudios.com.au/passwordstate.html

Он имеет функции для общих и личных учетных данных.

Не следует забывать о необходимости отмены паролей, если сотрудник уходит / увольняется. В популярных средствах массовой информации было отмечено несколько случаев увольнения сотрудников и «возвращения» в их компанию с использованием паролей, которые оставались активными после их ухода.

Обычно это 2 части:

1. Зная все пароли, которые необходимо изменить (в противном случае вы по умолчанию используете все, что утомительно)
2. Изменение их вручную или автоматизация процесса с помощью инструмента или сценария.

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

Я работаю в небольшом IT-магазине, и в течение прошлого года мы использовали Secret Server для управления нашими паролями для сетевых устройств и потребностей клиентов.

Они предлагают «установить версию» или онлайн / размещенную версию. Мы используем размещенную версию менее чем за $ 100 / год (5 пользователей) и можем получить безопасный доступ к этой информации о пароле через веб-браузер, куда бы мы ни пошли. Если вы действительно беспокоитесь о безопасности, установите его на свой сервер и получите доступ к нему только через локальную сеть или VPN.

Кроме того, мой любимый «персональный» веб-менеджер паролей теперь предлагает «бизнес-версию» - PassPack .

Я не уверен, как он работает в этом сценарии по сравнению с Secret Server, но любое решение должно быть гораздо более универсальным и безопасным, чем клочки бумаги, настольные приложения или ( задыхаясь ) запоминание вещей в вашей голове. Что касается «единой точки отказа», любой из этих продуктов позволяет легко экспортировать в CSV.

Я давно пользуюсь LastPass и мне это нравится. В прошлом году я потратил немного времени на изучение этого вопроса, и мне понравилось, как это сделал LastPass.

• Вся информация хранится на их сайте (и в локальной копии) в зашифрованном виде, и только у вас есть пароль для расшифровки
• Все пароли доступны для совместного использования и могут быть отозваны, вы даже можете поделиться ими, не предоставляя доступ к самому паролю (для веб-входа)
• Плагины для основных браузеров
• Множество других функций

Вторая рекомендация Адама о PasswordSafe с данными в сетевой папке. У меня есть два соображения в этой области. Один имеет единственную версию, так что все, кому нужны данные, получают текущие данные.

1- PasswordSafe использует стандартизированный формат для файла, поэтому есть другие решения, которые могут его прочитать, включая KeePass.

2- Поместите файл паролей на защищенный общий ресурс и создайте ночной сценарий, который копирует его в несколько мест в сети. Возможно, скопируйте его в общий ресурс на другом сервере (если это возможно, вне сайта) и на USB-накопитель, оставленный на сервере. Вам нужен файл хотя бы в одном месте, где он не защищен паролем, который он хранит!

3- Храните установщик (или исполняемую версию программы) в тех же местах, что и файл ключа, чтобы вы могли быстро найти его при необходимости.

4. Попросите людей открыть файл только для чтения, если только им не нужно вносить изменения.

5- При необходимости вы можете создать несколько файлов паролей, один для учетных данных, которые нужны всем в команде, и один для учетных данных для действительно чувствительных вещей.

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

Я несу ответственность за несколько систем с сотрудниками одного из моих клиентов. Мы согласились использовать схему паролей для наиболее часто используемых учетных записей. Другие пароли хранятся в бумажном списке пар (номер, пароль), который ведет начальник отдела ИТ клиента. Имена пользователей и хосты хранятся в легко доступной базе данных. Пароли выдаются по мере необходимости.

Обычная практика в малых и средних компаниях:

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

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

В реальности иногда пароль передается, но вы можете определить, кому нужно знать (и почему), и изменить то, что нужно изменить. Это хорошо работало в (программной) компании из 50 человек.

Для редко используемых паролей, таких как учетные записи локальных администраторов на серверах, пароли маршрутизатора и брандмауэра и т. П. На моей последней работе, в магазине, где-то около 50, только пароль действительно знал системный администратор. Они были записаны на листе бумаги в конверте. Я полагаю, что были три конверта, которые были запечатаны и подписаны Боссом, Сисадмином и Главным Программистом. У каждого человека была копия документов. В случае использования паролей мы меняли их и делали новые конверты.

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

Там в Lifehacker пост с сегодняшнего дня о Passpack , это может быть стоит посмотреть.

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

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

Я построил его с полной функцией аудита, чтобы каждый раз, когда сотрудник просматривал вход в систему, он регистрировался, чтобы мы могли выгрузить журнал аудита в Excel для аудиторов SOX.

Используйте GPG с параметром Symmetric для шифрования текстового файла со всеми паролями в нем. Тогда все, что вам нужно сделать, это предоставить одну парольную фразу другим администраторам. Когда администратор покидает компанию, просто зашифруйте текстовый файл с новой парольной фразой.

Центрифия работает на меня.

Вау, хорошая тема! Никто не упомянул о моем предпочтительном решении (кроме как мимоходом), поэтому я дам привет KeePass. Приятно расширяемый, с аутентификацией на основе пароля, ключа или AD. Делает работу хорошо для нас.

Для доступа к серверам:

Предоставьте доступ к одному серверу и используйте его в качестве переключателя и управляйте учетными записями в переключателе. Любой, кто считается доверенным для Jumpbox, является доверенным для удаленного ресурса. Таким образом, у каждого есть свой собственный пароль, и пароль на сервере для конкретной учетной записи может храниться в секрете.

Для доступа к другим ресурсам:

Ограничьте доступ только к необходимому персоналу. Обязательно управляйте списком доверенных пользователей. Меняйте пароль каждые 90 дней и обновляйте список доверенных пользователей. Сообщите людям о предстоящих изменениях за 15, 7 и 1 день. Раздайте пароль только менеджерам и дайте им возможность определить, кому нужен доступ. Используйте утилиты для регистрации доступа и регулярно информируйте пользователей о том, что они находятся под пристальным наблюдением систем. Любое смешное дело на серверах должно быть известным преступлением.

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

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

У нас есть система, такая как «Президент» и «Бомба» - два человека каждый знает половину пароля. Таким образом, вы никогда не получите ситуацию, когда один мошеннический администратор отключается и вносит несанкционированные изменения самостоятельно.

Я работаю в ИТ-компании, у нас много клиентов, обычно мы решаем проблему удаленно. Мы используем SSH для входа в систему для устранения неполадок. Мы добавили ssh-ключ одной машины ко всем нашим клиентским машинам, чтобы другим было полезно войти в систему и устранить проблемы, если меня там нет. Но машина, которую мы используем для входа в систему клиентов, очень хорошо ее обрабатывает. обеспечено. Если вы хотите иметь хорошие пароли, лучше используйте цифры и дополнительные символы.

Для добавления ключей ssh ​​выполните следующее:

1.ssh-keygen -t dsa (чтобы получить ключи ssh на .ssh / id_dsa.pub

2. scp .ssh / id_dsa.pub root @ remote: ~ / tmp

3. На удаленной машине

cat >> /tmp/id_dsa.pub .ssh / authorized_keys2

Попробуйте войти, чтобы удалить Macine, с другой консоли ... :) happy sshhhhhh

Отказаться от использования систем, требующих пароль. Любой сервер должен проходить аутентификацию с использованием ключей SSH, любой веб-сайт - с использованием OpenID. Запустите провайдера OpenID внутри брандмауэра.

Очевидно, этот сценарий подразумевает, что все ваши системы доступны через SSH или HTTP, но он работает для нас.