Система управления паролями для нескольких SysAdmins?
Charles Proxy с плагином Firefox намного лучше, чем статистика сети Firebug.
Мы используем это: http://sourceforge.net/projects/phppassmanager/ (немного изменило/настроило),
Это установлено на веб-сервере HTTPS с Аутентификацией Active Directory для ограничения извлечения пароля нашей командой. Каждый член команды знает, что основной пароль раньше шифровал все пароли, сохраненные в phppassmanager. Они используют его, когда они хотят добавлять/изменять/читать пароль. Пароли хранятся зашифрованные в mysql базе данных.
У них потенциально есть доступ ко всем паролям, но каждое дешифрование пароля является loggued, и журналы показывают целой команде на основной странице. Эта система самоконтролируется и самоуправляется.
Я использую KeePass, и я очень доволен им. Это - простой в использовании менеджер паролей с открытым исходным кодом.
-
1It' s окна и только позволяет единственный вход в систему. Мне нужно решение нескольких-входов-в-систему, таким образом, каждый системный администратор может войти в систему отдельно, который является единственным управляемым и безопасным способом обработать это. I' m потряс это существует not' t тонны продуктов там, которые делают это. – Aaron Brown 16 June 2009 в 23:25
-
2
-
3
Что точно Вы защищаете с этой системой? Системы Вы управляете, или системы, выполненные третьими лицами?
Для внутренней аутентификации системы как Kerberos, LDAP или даже просто sudo и PKI могут обработать это.
Для внешней аутентификации скажите веб-сайту программной поддержки, Вы в основном зажаты в тиски любой системой, которую они реализуют. Инструменты как KeePass (2,0 вида работ с моно) или PasswordGorilla могут сохранить Ваши пароли. Я не думаю, что любой из них поддерживает любое понятие нескольких отдельных паролей дешифрования; я не уверен, как это могло работать математически.
-
1LDAP и kerberos являются системами аутентификации, не системами управления паролями. Мне нужен способ сохранить пароли root, пароли маршрутизатора, Пароли менеджера LDAP - любой из 8 миллиардов паролей, которыми должен манипулировать системный администратор. – Aaron Brown 16 June 2009 в 22:57
-
2Да, да, они - системы аутентификации. Вы используете их для реализации Единой точки входа без фальшивой электронной таблицы Excel. – jldugger 17 June 2009 в 04:27
-
3I' m не уверенный Вы понимаете. Не все может быть сцеплено до единственного LDAP или kerberos сервера, ни если это. Пароли root сервера, например, никогда не должны храниться в LDAP, и при этом маршрутизатор не должен включать пароли. – Aaron Brown 18 June 2009 в 00:11
-
4Сделайте его правильно, и Вы don' t нужен инструмент для оптимизации доступа к тем паролям. Да, если сеть снижается, Вашим системам, вероятно, нужна некоторая внутренняя аутентификация. Но в случае серверов, почему не только используют sudo и PKI? Никакая корневая учетная запись, четкий аудит и не сетевой зависимый. – jldugger 18 June 2009 в 09:40
-
5Мы делаем использование LDAP и sudo с модулем PAM, где мы можем. Существует все еще дюжина других учетных записей для контакта с. Кроме того, должна быть документация корневых паролей учетной записи, и не все может быть сцеплен в систему LDAP. Также существуют учетные записи, которые должны быть вокруг, если LDAP недоступен, и мы должны войти в системы. Я ценю, что Вы думаете, что у Вас есть лучший путь, но мы уже используем централизованную аутентификацию, где это практично и возможно. Существует все еще несколько системных администраторов, которые должны иногда мочь к паролям доступа. – Aaron Brown 18 June 2009 в 14:17
Поскольку, что я считал до сих пор, любая система Wiki с бэкендом базы данных (даже с бэкендом хранилища файлов, но я предпочту дб) должен решить Вашу проблему. При установке надлежащих ограничений на учетные записи пользователей, и только люди, которым Вы доверяете (администраторы), смогут читать/изменять списки пароля (в простом документе HTML :)).
Поместите это позади SSL включило сервер, и ограничьте доступ к базе данных.
-
1Это сделало бы прекрасный, если бы был устойчивый журнал аудита и создание отчетов о механизме. когда кто-то покидает организацию, я хочу выполнить отчет, который показывает мне все пароли, которые должны быть изменены. Что-то как защищенная от SSL Wiki - хорошая идея, но она должна иметь что-то вроде определенной для пароля схемы, по моему мнению, так, чтобы она могла легко упростить создание отчетов. – Evan Anderson 17 June 2009 в 01:19
-
2@Evan, возможно, необходимо обновить вопрос включать это требование. – Zoredache 17 June 2009 в 03:40
-
3
PowerBroker является продуктом поставщика, специально разработанным для управления/аудита доступом к общим учетным записям; однако, существует значительная стоимость на серверную лицензию.
Я работал в очень сознательной безопасность компании, и в моей команде 5 мы использовали KeePass, потому что шифрование является устойчивым, это является кросс-платформенным и поддержки, импортирующие несколько баз данных в Ваше собственное. Мы сохранили его в системе, которая была только доступна через внутреннюю сеть посредством логинов SSH, которые потребовали ключевой аутентификации (никакие пароли, Спасибо!).
-
1
-
2Открытый ключ был единственной вещью, выставленной к системам. Закрытые ключи остались на individuals' рабочие станции. – jtimberman 18 June 2009 в 19:03
Я ищу ту же самую вещь, и я нашел 2, который мог бы соответствовать Вашим потребностям.
Сеть-KeePass - Это кажется, что она сделала бы то, что необходимо, но я все еще пытаюсь выяснить все опции.
corporatevault - Это является очень простым и на ранних стадиях. Интерфейс не закончен, но мне было легко довольно выяснить.
Я не абсолютно уверен, что это - то, в чем Вы нуждаетесь, но это работает на нас: мы сохраняем в нашем SVN gpg-зашифрованный текстовый файл со всеми учетными данными, зашифрованными с общим ключом, который все мы совместно используем. Основные преимущества для этого подхода вместо keepassx или подобных инструментов: 1) можно поместить информацию о свободной форме там и 2) gpg - дешифруют, может отправляться в канал и использоваться в терминале.
Несомненно, это только работает на группу из ~10 человек, но с небольшим количеством делегации может быть увеличен немного. Кроме того, у нас на самом деле есть два ключа и два зашифрованных файла для различных уровней доступа, но это не изменяется очень.
О, и мы склонны избегать обработки паролей как можно больше (главным образом с персональными ключами SSH).
Thycotic Secret Server.
Мы уже много лет используем его в моей компании. Он имеет множество полезных функций, таких как автоматическая смена паролей, отправка сообщений электронной почты при доступе к определенным паролям и т. Д.
Они также предоставляют регулярные обновления и добавляют функции.