Вопрос: Как команда системных администраторов безопасно делится паролями?


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


81
2018-06-02 23:50


Источник


См. serverfault.com/questions/3696/...  serverfault.com/questions/2186/...  serverfault.com/questions/10285/...  serverfault.com/questions/21374/... - Zoredache
BTW сотни - очень тревожное число. Что происходит, когда один из членов команды уволен? Обновление сотен паролей будет болезненным. - Zoredache
Прикомандировано к тому, что «сотни - это очень тревожное число». Я думаю, вам, возможно, понадобится создать резервную копию и пересмотреть, как вы управляете всей безопасностью, в первую очередь, вместо того, чтобы пытаться наклеить гипсокартон на то, что у вас есть. - Maximus Minimus
Немного связано: serverfault.com/questions/119892  В частности, этот ответ: serverfault.com/questions/119892/company-password-management/... - Nathan Hartley


Ответы:


Я бы, вероятно, написал специальное веб-решение, размещенное в корпоративной интрасети. (Взгляни на http://lastpass.com для вдохновения или для его использования. Совместное использование паролей является одной из его функций, хотя это может не работать для вашего тома.)

РЕДАКТИРОВАТЬ: Конечно, лучшее решение, не разделяйте их. Сохранение открытых паролей на любом носителе является опасным, особенно если целью их хранения является их совместное использование. Существует почти бесконечное количество решений, каждый из которых связан с опасностью. Почему бы не поставить их на зашифрованный образ диска, записать это изображение на один компакт-диск, поставить компакт-диск в сейф, который может открыть только один вооруженный охранник, и разрешить людям показывать идентификатор фотографии, чтобы он был разблокирован?

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


14
2018-06-02 23:58



ИМО Построение собственной системы безопасности / шифрования практически никогда не является правильным решением проблемы. - Zoredache
@Zoredache, Это нагрузка дерьма. Хотя, я думаю, что веб-решение для размещения паролей является глупым - но он сделал, что msanford действительно сказал интрасеть. Тем не менее рискованно. То же самое для всех других сетевых решений. - d-_-b
@Zoredache, OP не создает пользовательскую систему шифрования, похоже, что все, что ему нужно, это безопасная база данных. @sims Я не вижу ничего плохого в хорошо разработанном веб-решении. Проголосовавший ответ предполагает именно то, что (веб-интерфейс! = Http; веб-based = хранится в Интернете). Разумеется, как только я прочитаю этот вопрос во второй раз, я согласен с тем, что базовая модель обмена тоннами паролей, по-видимому, не нужна, и что может быть достигнуто лучшее решение. Но ОП не предоставил мне достаточно информации, чтобы сделать это решение ... - msanford
> @Zoredache, это нагрузка дерьма. <Um, Sims, вы довольно много летаете перед лицом большинства людей, занимающихся шифрованием, с самого начала. Проектирование шифрования затруднено, что делает целесообразным шифрование еще сложнее. schneier.com/essay-037.html  Иногда меньшее зло - то, что вы знаете, - лучший выбор, когда вы сталкиваетесь со злом, которого вы не знаете (т. Е. Непроверенный дизайн, может иметь ошибки, может иметь дыры в безопасности и т. Д. ) - Avery Payne
@Avery - проектирование криптографической системы сложно и должно быть предоставлено экспертам, да. Использование проверенных и проверенных инструментов, таких как GPG в общем текстовом файле, или Keepass (который использует .NET-реализации AES и SHA-256) не разрабатывает вашу собственную систему. - mfinni


Лучше всего не делиться паролями. Используйте инструменты, такие как sudo, чтобы пользователи могли получить доступ, который им нужен, из собственной учетной записи. Если у вас есть несколько пользователей, каждый из них должен иметь свои собственные учетные записи там, где это необходимо. LDAP (Unix / Linux) и Active Directory являются хорошим решением для предоставления доступа к нескольким серверам из общей базы данных.

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

Для паролей, которые действительно нужно использовать совместно, используйте один из таких инструментов пароля, как Keepass, который может иметь свою базу данных в сети. Инструменты с клиентами для нескольких платформ лучше. Подумайте, вам нужно больше одной базы данных. Помните, что вам действительно нужно доверять всем, кто имеет доступ к этим данным.


38
2018-06-03 00:04



+1 для непривилегированных учетных записей пользователей для администраторов с возможной эскалацией привилегий, на серверах * nix я бы совмещал это с использованием только сертификата dsa / rsa для sshd. Если вы работаете с графическими инструментами в Linux, вы также можете использовать настроенную конфигурацию политики. - Aaron Tate
Эта. Отмена доступа для пользователей, когда они используют общие учетные данные, является абсолютным кошмаром. По возможности делегируйте доступ через уникальную учетную запись пользователей. Всегда есть несколько ситуаций, когда общий пароль неизбежен, но «сотни» общих паролей кричат ​​критический недостаток дизайна. - Chris Thorpe
Я согласен с тем, что обычно не использую пароли, но есть множество ситуаций, когда это необходимо, например, сетевые устройства с одним сайтом входа в систему, поставщики, в которых все системные администраторы используют один и тот же логин для заказа, а также пользователей SQL sa или локальные пароли администратора, необходимо. Вот почему я думаю, что KeePass лучше всего подходит для этого: он работает на нескольких платформах, обеспечивает большую безопасность и легко организует сотни паролей. - Paul Kroon
У нас есть вариация на этом, где у нас есть корневые пароли, записанные, но заблокированные в сейфе, что только у системной команды есть ключи для открытия. Наши корневые пароли имеют длительность 16 символов и генерируются таким образом, чтобы их можно было запомнить практически невозможно. Да, там есть какая-то неуверенность, но если кто-то ворвался в сейф, я подозреваю, что у нас большие проблемы. - Frenchie
Вот сценарий реального использования для нашей команды: совместное использование паролей для веб-приложений, где они не поддерживают несколько логинов для одной учетной записи. Поэтому, если более одного человека в команде должны иметь доступ к этой учетной записи, должен быть способ совместного использования паролей для этой учетной записи. - Jordan Reiter


Мы пошли с KeePass для этой цели. Это отличная небольшая программа, которая хранит все ваши пароли в зашифрованном файле базы данных. Существуют дополнительные функции безопасности, такие как необходимость использования ключевого файла вместе с основным паролем для доступа к паролям. Это позволяет использовать несколько уровней безопасности (отделить файл ключей и базу данных), сохраняя при этом удобство для работы со всеми различными паролями. Например, вы можете запустить приложение и файл ключей с USB-накопителя, но где-то хранить базу данных в своей сети. Для этого потребуются учетные данные для сетевого ресурса, основного пароля и физического USB-накопителя с ключевым файлом.


10
2018-06-02 23:59



KeePass, похоже, поддерживает несколько платформ, большая победа в моих глазах (я работаю в среде смешанной платформы). Функция авто-типа также полезна. - Avery Payne
Глупо идея хранить пароли в сети. - d-_-b
@Sims - тогда как вы делитесь ими? KeePass использует зашифрованный файл для магазина. Это просто более удобная версия текстового файла с зашифрованным GPG на сервере Unix, к которому у всех есть доступ. - mfinni
@Sims - я бы с тобой согласился, но это будет ситуация безопасности и производительности. Я бы не захотел поместить пароль root на сервер в чем-то подобном, но пароль администратора коммутатора уровня 2, который имеет только один логин, является хорошим кандидатом для этого. Есть момент, когда требуется больше работы, делая вещи более безопасным способом, чем при очистке после нарушения безопасности. Кроме того, помимо всего шифрования, вы должны иметь безопасность AD / NTFS в файле и небольшую неизвестность, помещая файл (который можно назвать любым) в случайном месте. - Paul Kroon
Я не думал о машине Windows. Но да, если у вас может быть только один пользователь для этого переключателя, тогда, я думаю, это будет иметь смысл. В противном случае, как говорит Билл, скажите «нет» для общих паролей, что также было моей точкой зрения на ключи. - d-_-b


Каковы наилучшие методы совместного использования сотен паролей среди нескольких человек?

Легко, это происходит в двух вариантах:

  1. Вы этого не делаете, просто и просто. Если вы решите сделать это, вы отложите аутентификацию паролем на внешний доверенный орган и проверите аутентификацию оттуда.

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

Эти пароли защищают критически важные данные и не могут быть заметны за пределами небольшой команды.

Вам следует серьезно подумать о службе безопасной проверки подлинности, которая интегрируется с службой каталогов для решения этой проблемы. Комбинация DS / AS создает доверенный «авторитет», который может выступать в качестве арбитра для всех ваших пользователей и устройств. Учетные записи пользователей могут абстрагироваться от фактического пароля, используемого при аутентификации, что упрощает «отключение» паролей от политики доступа. Контроль паролей - это деактивация учетной записи пользователя; поэтому, если администратор уходит, вы просто отключите свою учетную запись, и их доступ ушел (поскольку пароль этого человека предоставляет только доступ на основании действительности DS / AS, подтверждающей действительность учетной записи).

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

  • Active Directory.  Вероятно, самая известная из группы, дает вам Kerberos в качестве опции аутентификации и предоставляет LDAP для базовых DS.
  • Samba / Winbind.  Думайте об этом как о «Active Directory Light», вы не получаете все функции AD, а скорее старую модель, основанную на NT4 (думаю, хэш LANMAN). Это будет заменено интеграцией AD Samba 4 и, вероятно, «исчезнет».
  • Novell Directory Services.  Я не знаю достаточно об этом, чтобы рекомендовать его, но я знаю, что он все еще существует. Многие правительственные организации по-прежнему используют NDS, поэтому, если вы работаете в этом секторе, это будет интересно для вас. Недавно Novell портировал NDS для работы в качестве службы Linux, но я не знаю, является ли это еще активным продуктом (около 2005 года).
  • LDAP + Kerberos.  Это в основном «домашний рост» Active Directory, минус все «приятные функции». Тем не менее, они также являются известными компонентами со стабильной, зрелой базой кода, поэтому интеграция этих сервисов обычно представляет собой «настройку», необходимую для работы.
  • SSH Keys + (вставьте программу администрирования системы здесь, возможно, марионетку).Только полезно, когда у вас есть SSH по всей доске, и все устройства получают доступ таким образом. Ключи могут быть разданы и отменены по мере необходимости, а пароли становятся «неуместными», поскольку ключ SSH предоставляет доступ. Использование такой системы, как кукла, позволяет вам обновлять сотни машин, выдавая команды en-masse для добавления / отзыва SSH-ключей.
  • Некоторая комбинация из вышеперечисленного.

Существует также вопрос о том, сколько средств вам необходимо. Вы не указали, означает ли вы, что «критически важными для вас» ядерные боеголовки могут опускаться на города, или если «критическая миссия» означает, что последняя партия Furbies не попадет в город. Это действительно помогло бы, если бы было что-то, что описывало оценку риска / угрозы.


5
2018-06-03 20:37





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


2
2017-12-16 00:31





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


1
2018-06-03 02:57





Несколько вещей:

  • Как говорили другие, это плохая идея. Используйте LDAP и т. Д.
  • Если вы намерены делать это по любой причине, по крайней мере, консолидируйте пароли. 100 неуправляемых паролей означает, что вы не обновляете пароли.
  • Держите их на бумаге. Требовать, чтобы сотрудники подписывали бумагу в разных цветных чернилах, чтобы было легче определить, был ли скопирован лист.
  • Если вы используете Unix, используйте S / KEY для генерации одноразовых паролей. Храните это где-то в безопасности.

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

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

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


1
2018-06-03 15:06





https://pypi.python.org/pypi/django-pstore/ использует шифрование GPG для каждого пользователя для общих паролей (и любые другие данные, которые вы хотели бы поделиться). Сервер никогда не знает о каких-либо паролях, он содержит только зашифрованные данные. Каждый использует свой закрытый ключ для дешифрования разделяемых секретов.

Система включает в себя управление правами: не каждый получает полный доступ.


1
2018-03-11 14:39





Мы используем https://passwork.me как самостоятельное решение. Но вы также можете хранить пароли в своем облаке.


1
2018-05-21 13:13



Это ваш продукт Илия, но он выглядит хорошо. - Foliovision