У нас есть разные пароли, которые должны быть известны более чем одному человеку в нашей компании. Например, пароль администратора для наших интернет-маршрутизаторов, пароль для нашего веб-хоста, а также несколько паролей, не относящихся к ИТ, например, безопасные коды.
В настоящее время мы используем для этого случая система «стандартных паролей» для малоценных систем и словесное обмен паролями для более важных / потенциально опасных систем. Думаю, большинство людей согласятся, что это плохая система.
Что нам нужно, так это программное решение для хранения «общих» паролей, доступ к каждому из которых будет ограничен людьми, которые действительно в нем нуждаются. В идеале, это будет требовать периодической смены пароля. Он также должен иметь возможность указывать, у кого есть доступ к определенному паролю (например, кто знает пароль root для сервера XYZ?)
Можете ли вы предложить какие-либо программные решения для хранения и обмен пароли? Есть ли что-то особенное, чего следует опасаться?
Какова практика этого в малых и средних компаниях?
Я сталкиваюсь с этой проблемой каждый раз, когда иду в новый стартап. Первое, что я делаю, это создаю пару «сейфов паролей» с помощью такой программы (или одной из ее производных):
http://passwordsafe.sourceforge.net/
Создавайте сильные комбинации и размещайте их на сетевом ресурсе. Сегмент по сферам ответственности ... центральная инфраструктура, производственные серверы, разработка / контроль качества и т. Д.
Как только наберется достаточный импульс и при условии, что у меня есть правильные зависимости среды Windows, мне нравится перемещать всех к этому:
http://www.clickstudios.com.au/passwordstate.html
Он имеет функции как для общих, так и для личных учетных данных.
Не следует забывать о необходимости уметь отозвать пароли на случай увольнения / увольнения сотрудника. В популярных СМИ было отмечено несколько случаев увольнения сотрудников и их «возвращения» в свою компанию с использованием паролей, которые оставались активными после их увольнения.
Обычно это 2 части:
Еще один важный фактор - обеспечение соблюдения политики паролей при внесении изменений, например как узнать, что один и тот же пароль не использовался для нескольких учетных записей или что не использовался слабый пароль?
Я работаю в небольшом ИТ-магазине, и мы использовали Секретный сервер за последний год для управления нашими паролями для наших сетевых устройств и потребностей клиентов.
Они предлагают «установочную версию» или онлайн-версию / размещенную версию. Мы используем размещенную версию менее чем за 100 долларов в год (5 пользователей) и можем безопасно получить доступ к этой информации о пароле через веб-браузер в любом месте. Если вы действительно беспокоитесь о безопасности, установите его на свой собственный сервер и получайте доступ только через локальную сеть или VPN.
Кроме того, мой любимый "личный" веб-менеджер паролей теперь предлагает "бизнес-версию" - PassPack.
Я не уверен, как он работает в этом сценарии по сравнению с секретным сервером, но любое решение должно быть гораздо более универсальным и безопасным, чем клочки бумаги, настольные приложения или (задыхаться) вспоминая вещи в своей голове. Что касается проблемы «единой точки отказа», любой из этих продуктов позволяет легко экспортировать в CSV.
Я использовал LastPass какое-то время и люблю это. В прошлом году я потратил немного времени на изучение этого вопроса, и мне понравилось, как LastPass сделал это.
Я повторяю рекомендацию Адама по PasswordSafe с данными в сетевой папке. У меня есть два соображения в этой области. У одного есть одна версия, так что все, кому нужны данные, получают текущие данные.
1- PasswordSafe использует стандартизированный формат файла, поэтому есть другие решения, которые могут его прочитать, включая KeePass.
2- Поместите файл паролей в безопасный общий ресурс и создайте ночной сценарий, который копирует его в несколько мест в сети. Возможно, скопируйте его в общий ресурс на другом сервере (если возможно, вне сайта) и на USB-накопитель, оставленный на сервере. Вам нужно, чтобы файл был по крайней мере в одном месте, где он не защищен паролем, который он хранит!
3- Сохраните установщик (или исполняемую версию программы) в тех же местах, что и ключевой файл, чтобы вы могли быстро получить к нему при необходимости.
4- Пусть люди открывают файл ТОЛЬКО ДЛЯ ЧТЕНИЯ, если им не нужно вносить изменения.
5- При необходимости вы можете создать несколько файлов паролей, один для учетных данных, необходимых каждому члену команды, и один для учетных данных для действительно важных вещей.
я буду не рекомендую перейти на веб-решение. Решение с внутренним размещением может быть нормальным, но, похоже, это создает много проблем. Я также обеспокоен тем, что это единственная точка отказа.
Для редко используемых паролей, таких как учетные записи локального администратора на серверах, пароли маршрутизатора и брандмауэра и т. Д. На моей последней работе, в магазине около 50 человек, только системный администратор действительно знал пароли. Они были записаны на листке бумаги в конверте. Я полагаю, что было три конверта, которые были запечатаны и подписаны начальником, системным администратором и главным программистом. У каждого человека была копия документов. В случае использования паролей мы их меняли и делали новые конверты.
В моей текущей работе в гораздо более крупной организации у нас есть только 15 системных администраторов и пара тысяч пользователей, у нас есть метод расчета паролей на основе имени сервера. Это включает известный префикс и метод хеширования, который достаточно просто сделать на бумаге. Когда пароли нужно сменить из-за того, что кто-то уходит или еще что-то, мы меняем префикс, хеш или и то, и другое. Таким образом, хотя я не знаю пароля для каждой машины или устройства вокруг меня, я мог бы вычислить его, если бы он мне по какой-то причине понадобился.
Распространенная практика в малых и средних компаниях:
Три места, где я работал, использовали отдельные документы для детализации паролей для разных систем. Один документ для маршрутизаторов и брандмауэров, другой для доступа к серверам и один для разработчиков (например, данные для входа в систему для соединений с базой данных). Доступ к приложениям, как правило, не документируется (я предполагаю, потому что в большинстве случаев вы входите в систему как вы с правами администратора).
Сетевой администратор видит только документ с паролем маршрутизатора, а лица, имеющие доступ к этому документу, перечислены в этом файле. В их условиях найма указано, что логины и пароли, к которым у них есть доступ, являются личными и не подлежат передаче другим лицам. Аналогично системному администратору и разработчикам.
Реальность иногда заключается в том, что пароль передается, но вы можете определить, кому нужно знать (и почему), и изменить то, что нужно изменить. Он хорошо себя зарекомендовал в (программной) компании с 50 сотрудниками.
Я разделяю ответственность за несколько систем с сотрудниками одного из моих клиентов. Мы договорились использовать схему паролей для наиболее часто используемых учетных записей. Другие пароли хранятся в бумажном списке пар (номер, пароль), который ведет руководитель ИТ-отдела клиента. Имена пользователей и хосты хранятся в легко доступной базе данных. Пароли выдаются по служебной необходимости.
Для доступа к серверам:
Предоставьте доступ к одному серверу и используйте его как панель перехода и управляйте учетными записями на поле перехода. Любой, кто считается доверенным для jumpbox, считается доверенным для удаленного ресурса. Таким образом, у каждого будет свой пароль, а пароль на сервере для конкретной учетной записи может храниться в секрете.
Для доступа к другим ресурсам:
Ограничьте доступ только основным персоналом. Обязательно ведите список доверенных пользователей. Меняйте пароль каждые 90 дней и обновляйте список доверенных пользователей. Сообщите людям о предстоящих изменениях за 15, 7 и 1 день. Раздайте пароль только менеджерам и позвольте им определять, кому нужен доступ. Используйте служебные программы для регистрации доступа и регулярно сообщайте пользователям, что они находятся под пристальным наблюдением системы. Любой забавный бизнес на серверах должен рассматриваться как преступление, которое может быть прекращено.
Вау, хорошая ветка! Никто не упомянул мое предпочтительное решение (кроме как мимоходом), поэтому я передам привет KeePass. Хорошо расширяемый, с аутентификацией на основе пароля, ключа или AD. Хорошо делает эту работу для нас.
Centrify работает на меня.
Используйте GPG с параметром «Симметричный», чтобы зашифровать текстовый файл со всеми содержащимися в нем паролями. Затем все, что вам нужно сделать, это предоставить один пароль другим администраторам. Когда администратор покидает компанию, просто повторно зашифруйте текстовый файл с помощью новой парольной фразы.
У меня раньше была такая же проблема. В итоге я создал систему, которая справится с этим самостоятельно. Он хранит имя пользователя и пароль в хорошо зашифрованной форме в базе данных с веб-интерфейсом, который позволит вам вводить информацию об учетной записи и устанавливать для нее безопасность, чтобы только правильные люди или группы могли получить доступ к данным.
Он не запрашивал, когда пришло время менять пароли, поскольку службы на десятках серверов использовали один и тот же логин, а изменения паролей нужно было настраивать заранее.
Я построил его с полной функцией аудита, чтобы каждый раз, когда сотрудник просматривал вход в систему, он регистрировался, чтобы мы могли выгружать журнал аудита в Excel для аудиторов SOX.
У нас есть такая система, как «Президент и бомба» - по два человека знают половину пароля. Таким образом, вы никогда не получите ситуацию, когда один-единственный администратор-мошенник уйдет и внесет неутвержденные изменения самостоятельно.
Возможно, вы захотите использовать какое-то программное обеспечение для хранения паролей - таким образом вы можете предоставить авторизованным пользователям их собственный доступ к нему и убедиться, что информация не просачивается людьми, оставляющими заметки. Хороший, вероятно, даже не отображает пароль, просто помещает его в буфер обмена для вырезания и вставки.
Я знаю, что это не совсем тот ответ, который вам нужен, но на моем рабочем месте он точно такой же, доверенные сотрудники получают соответствующие пароли, пароли не передаются между устройствами и не записываются. Система имеет тенденцию работать достаточно хорошо, поскольку администрирование устройств обычно является обязанностью только пары сотрудников. У нас также очень хорошее удержание персонала, поэтому доверие можно укреплять в течение длительного периода времени.
Я работаю в IT-компании, у нас много клиентов, обычно мы решаем проблему удаленно. Мы используем ssh для входа в систему для устранения неполадок. Мы добавили один ssh-ключ для всех наших клиентских машин, так что это будет полезно для других для входа в систему и устранения проблем, если меня там нет. Но машина, которую мы используем для входа в систему для клиентов, очень сильно обеспечен. Если вы хотите иметь хорошие пароли, лучше используйте цифры и дополнительные символы.
Чтобы добавить ключи ssh, выполните следующие действия:
1. ssh-keygen -t dsa (чтобы получить ssh-ключи на .ssh / id_dsa.pub
scp .ssh / id_dsa.pub корень @ удаленный: ~ / tmp
На удаленной машине
кошка >> /tmp/id_dsa.pub .ssh / authorized_keys2
Попробуй авторизоваться, чтобы удалить macine, с другой консоли ... :) happy sshhhhhh
Откажитесь от использования систем, требующих пароля. Любой сервер должен аутентифицироваться с помощью ключей SSH, любой веб-сайт с OpenID. Запустите провайдер OpenID внутри брандмауэра.
Очевидно, этот сценарий подразумевает, что все ваши системы доступны через SSH или HTTP, но он работает для нас.