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


83

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



11
Кстати, сотни - очень тревожное число. Что происходит, когда один из членов команды уволен? Обновление сотен паролей будет болезненным.
Zoredache

2
Рассказ о «сотнях - очень тревожный номер». Я думаю, что вам, возможно, нужно сделать резервную копию и пересмотреть, как вы в первую очередь управляете всей системой безопасности, а не пытаться нанести клейкую штукатурку на то, что у вас сейчас есть.
Максимус Минимус

1
В некоторой степени связано: serverfault.com/questions/119892 В частности, этот ответ: serverfault.com/questions/119892/company-password-management/…
Натан Хартли

Ответы:


14

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

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

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


50
ИМО Построение собственной системы безопасности / шифрования почти никогда не является правильным подходом к проблеме.
Zoredache

2
@ Zoredache, это куча дерьма. Хотя я думаю, что веб-решение для хостинга паролей глупо, но он сказал, что Мсэнфорд сказал интранет. Все еще рискованно, хотя. То же самое для всех других сетевых решений.
d -_- b

2
@Zoredache, ОП не создает собственную систему шифрования, похоже, все, что ему нужно, - это безопасная база данных. @sims Я не вижу ничего плохого в хорошо разработанном веб-решении. Ответ с повышенным голосом говорит именно об этом (через Интернет! = Http; через Интернет = хранится в Интернете). По общему признанию, как только я прочитал этот вопрос во второй раз, я согласен с тем, что базовая модель совместного использования тонн паролей, вероятно, окажется ненужной, и что может быть найдено лучшее решение. Но ОП не предоставил мне достаточно информации, чтобы принять такое решение ...
Мсэнфорд

2
> @Zoredache, это куча дерьма. <Хм, Симс, вы в значительной степени летите перед лицом большинства людей, занятых шифрованием, сразу же. Спроектировать шифрование сложно, а сделать шифрование стоит еще сложнее. schneier.com/essay-037.html Иногда меньшее зло - то, которое вы знаете - является лучшим выбором, когда сталкивается со злом, которого вы не знаете (т. е. дизайн, который не проверен, не рецензирован, может иметь ошибки, могут быть дыры в безопасности и т. д.)
Avery Payne

1
@Avery - разработка криптографической системы сложна и должна быть оставлена ​​экспертам, да. Использование проверенных и проверенных инструментов, таких как GPG для общего текстового файла или Keepass (который использует реализации .NET для AES и SHA-256), не является разработкой вашей собственной системы.
mfinni

38

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

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

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


+1 для непривилегированных учетных записей пользователей для администраторов с возможным повышением привилегий, на * nix серверах я бы советовал использовать только сертификацию dsa / rsa для sshd. Если вы работаете с графическими инструментами под Linux, вы также можете использовать настроенную конфигурацию policykit.
Аарон Тейт

12
Этот. Отмена доступа для пользователей, когда они используют общие учетные данные, является абсолютным кошмаром. По возможности делегируйте доступ через уникальную учетную запись пользователя. Всегда есть несколько ситуаций, когда общий пароль неизбежен, но «сотни» общих паролей критикуют критический недостаток дизайна.
Крис Торп

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

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

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

11

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


Похоже, что KeePass поддерживает несколько платформ, что является большой победой (я работаю в среде со смешанными платформами). Функция «авто-тип» также выглядит полезной.
Эйвери Пейн

2
Глупая идея хранить пароли в сети.
d -_- b

1
@Sims - тогда как ты им поделишься? KeePass использует зашифрованный файл для магазина. Это просто более удобная версия текстового файла с шифрованием GPG на сервере Unix, к которому у всех есть доступ.
mfinni

1
@Sims - я бы обычно с тобой согласился, но это ситуация безопасности против производительности. Я бы не хотел помещать пароль root сервера в нечто подобное, но пароль администратора коммутатора уровня 2, который имеет только один логин, является хорошим кандидатом для этого. Есть момент, когда требуется больше работы, чтобы сделать вещи более безопасным способом, чем это было бы для очистки после взлома системы безопасности. Кроме того, в дополнение ко всему шифрованию у вас будет безопасность AD / NTFS для файла и немного неясности, если файл (который может быть назван как угодно) в случайном месте.
Пол Крон

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

5

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

Это просто в двух вариантах:

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

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

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

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

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

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

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


2

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

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

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

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

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


2

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


1

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


1

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

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



0

SPB Wallet - это хороший инструмент, который мы использовали, чтобы использовать PW safe by ghost, но SPB Wallet позволяет синхронизировать с сетевым ресурсом, а также синхронизировать с вашим iphone, если вы получаете приложение. Он также имеет встроенный генератор паролей, и вы можете генерировать их от простых паролей до чрезвычайно сложных паролей. Вы также можете скопировать пароль, пока он все еще отмечен звездочкой, поэтому, если кто-то ищет, вы можете скопировать и вставить его, чтобы никто не увидел пароль. Приложение для ПК автоматически блокируется при отсутствии активности в течение определенного периода времени.


0

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


0

Наша лучшая практика - делиться как можно меньшим количеством паролей.

Поэтому мы, например: - используем my.cnf в корневом домашнем каталоге для паролей к базе данных - используем ssh-ключи для входа на серверы и имеем один корневой пароль, который разрешен только через консоль (поэтому вы должны иметь физический / BMC-доступ к серверу ) - используйте ldap везде, где это возможно (ssh, bmc, переключатели, redmine, ....)

Однако есть несколько ситуаций, когда мы не можем использовать этот подход (например, пароль root). Затем мы используем keepass в нашем общем хранилище, но храним там всего 10 паролей.


-1

Очень хороший вопрос Я был бы заинтересован в других ответах.

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

Поскольку количество паролей должно быть небольшим (вы, по возможности, используете ключи), я использую простой текстовый файл, зашифрованный с помощью gpg, в системе, в которой нет NIC. Итак (1) вам нужен физический доступ и (2) пароль.

отредактировано для ясности


Ключи? Как в USB-ключах? Физические ключи, которые открывают замки? Ключи смарт-карты? Ключи GPG? Ключи с парольными фразами, которые существуют только в программном обеспечении в вашей голове? Сочетания вышеперечисленного?
Эйвери Пейн

Ключи от машины! JK. Чтобы уточнить, я имею в виду ключи SSH. Вот почему я сказал, что может быть невозможно использовать предварительно общие ключи с окнами.
d -_- b
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.