Как стать автором
Обновить

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

Для решения этих задач есть корпоративный менеджер паролей Пассворк — о нём расскажем в этой статье. Загляните под кат, чтобы понять, в каких кейсах Пассворк полезен, а в каких — очень полезен. Ну и, разумеется, узнать всё о его многочисленных возможностях.

Читать далее
Всего голосов 20: ↑19 и ↓1 +18
Комментарии 39

Комментарии 39

Где ссылка на сайт?

А отпечаток пальца можно использовать в качестве второго фактора в 2FA?

Надо прикрутить Webauthn - и хоть отпечаток, хоть Windows hello, хоть FIDO-ключ.

Была бы ещё однопользовательская лицензия тысячи за 2, для энтузиастов :)

Vaultwarden - open source. Разворачивается спокойно в докере. Web интерфейс, аддоны для браузеров, мобильное приложение, автозаполнение.

Пробовал, не понравился

Чем?

Пассворк штука хорошая но страдает общим для всех менеджером паролей концептуальным недостатком: обособленность. Для администрирования как правило в каком-то виде существует база данных IT-инфраструктуры предприятия. Если это набор файлов в виде электронных таблиц, схем и текстовых описаний, проблем нет (кроме проблемы поддерживать эту разрозненную базу в актуальном состоянии в ручном режиме), одним хранилищем больше, одним меньше. А если это централизованная база на какой-то платформе, то включение в процесс пассворка, дублирование структуры удвоит работы по администрированию. Целесообразнее интегрировать менеджер паролей в единую базу, а пассворк, насколько мне известно, такого не умеет.

не храни в одном месте, его взломают обязательно

Если данные при хранении зашифрованы AES-256, а учетки под стойкой к фишингу 2фа через физические ключи, то нужно иметь уж очень высокую ценность БД, чтобы оправдать затраты на подобную атаку.

Заметил, что функция автозаполнения в пассворке работает странно.

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

Еще у меня есть один ресурс, где если passwork сам заполняет логин и пароль и нажимает свой виртуальный Enter -- я получаю пустую страницу и никуда не авторизовываюсь, в то время, как если я туда ручками скопирую логин и пароль из passwork и сам нажму "Войти" -- все сработает.
Это на servicedesk.softlinegroup.com, ну так, для сведения

Еще у меня есть один ресурс, где если passwork сам заполняет логин и пароль и нажимает свой виртуальный Enter -- я получаю пустую страницу и никуда не авторизовываюсь, в то время, как если я туда ручками скопирую логин и пароль из passwork и сам нажму "Войти" -- все сработает.

Вероятнее всего на той странице переопределн клик на кнопку как button, а не как submit
Сталкивался с таким когда делал controlled формы

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

Открыть на телефоне?

Я с keepass именно так делаю и перебиваю пароль ручками

Как я понял архитектуру приложения то пароли храняться только на сервере и если к серверу нет доступа, то пароли недоступны.

ИМХО, менеджер паролей может быть только оупенсорсным. Без вариантов.

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

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

Но тогда и пароль не нужен. Зачем усложнять систему и поддержку системы???

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

Вместе с паролем логично хранить логин, а также URL сервиса, для которого он предназначен.

Серьезно? Может все таки отображать, а не хранить в одном месте? Вроде же давно придумали соль и прочие радости.

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

Расскажите это парням из Mikrotik например, где на SwOS есть только один пользователь и ему можно задать только один пароль. Куча всяких железяк, на которых нет пользователей (или он один - admin), а просто пароль.
А если тому единственному знающему эти пароли "снег башка попадёт" ?

Бэкап шамира для мастер пароля.

Я вполне понимаю, что раз есть такая практика, то есть и причины. Но это никак не делает эту практику правильной. Я не знаю как исправить конкретно Mikrotik, но убежден, что это возможно.

«Парни из Микротика» как и другие вендоры это предусмотрели и завезли нормальных пользователей в небюджетные модели. Боитесь всё потерять на ключевом устройстве? Возьмите для ключевого места устройство классом повыше.

Можете немного подробней про микротик, потому что насколько я помню, там есть и возможность создавать создавать пользователей, создавать группы пользователей с разными правами, авторизовывать пользователя по ssh ключу или использовать radius сервер для авторизации

Не совсем корректно сказать "облегченная" - скорее сильно другая и менее "фичастая". Но зато интерфейс "коммутаторный" и понятен тем, кто до этого работал с веб-гуями коммутаторов, но не работал с микротами.

абсолютно верно. для каждого пользователя свой аккаунт

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

и вообще, доверять хранение паролей черному ящику от кого-то не очень верное решение. админ должен сам придумать решение, которое будет проще, надёжнее и удобнее. а то смахивает на "ключик положите под коврик"

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

Есть еще хороший вариант: vaultwarden (opensource). Делегирование доступа к паролям, личные хранилища, генератор паролей, дополнительные поля. Для меня есть, все что необходимо.

Некоторыми возможностями сабжа обладает бесплатная версия passbolt.

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

Время от времени, команда passbolt из коммерческой версии в бесплатную переносят часть функционала.

а где хранятся пароли для входа в сам пассворк ?:-)

да это бизнес идея! менеджер пароль для менеджеров паролей!!

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

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

Так что я бы тоже спросил - а как там дела с безопасностью у самих "расширений для всех основных браузеров"?

*любой* [корпоративный] менеджер паролей - это костыль, который создаёт ложную иллюзию "безопасности" и (самое главное) "контролируемости ситуации".

Проблема 1: пользователь 1 имеет доступ к логину, паролю, url/другому адресу для ввода пароля. Пароль - в пассворк или другом менеджере, всё остальное - неважно где, главное, что он это знает/имеет доступ. Он создаёт на рабочем столе текстовый файлик и туда всё это записывает (ну лень ему каждый раз авторизовываться в менеджере паролей и пароль не каждый день меняют). И работает с этим файликом по необходимости.

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

Проходит время, пользователь 1 либо видит сообщение о необходимости изменить пароль, (либо по злому умыслу) самостоятельно его изменяет и не заносит в менеджер паролей.

Проблема 1.1: Начинаются разборки "Кто менял пароль?", все (1,2,3) говорят "не я". Кого будем наказывать? (это конкретнейший пистон авторам статьи за "можно выяснить кто сменил пароль").

Проблема 1.2: "Авторизованный" пользователь (владелец) перед увольнением (например) удалил "свою" учётку на внешнем ресурсе. Получил уведомление на корпоративную почту, подтвердил. Поскольку последние полгода-год заходил по паролю из блокнотика - подставил 2 и 3.

Проблема 1.3: Если а) хранение не облачное, а корпоративное и б) работник работает из дома/в командировке, то вероятность такого сценария ненамного (!) ниже 100%. Ибо чтобы зарегистрироваться на нужном ресурсе работнику надо поднимать VPN до работы, авторизоваться в менеджере паролей, идти на нужный ресурс (ладно если со своей машины, а не через VPN). Или "пойти куда надо (на ресурс), скопировать/вставить имя/пароль, работать" - 3 копи-пасты. А если запомнено в браузере - вообще два клика мышкой (ярлык на рабочем столе и "ОК/submit" на уже введённом логине/пароле).

Проблема 2: 2FA/Одноразовые пароли по SMS/Push (по номеру телефона).

Проблема 3: Пользователь на ресурсе нажал кнопку "забыл пароль", получил одноразовую ссылку (на корпоративную почту), сменил пароль, не внёс в менеджер паролей. Выясниться может через полгода, когда уйдёт в отпуск. Ибо до этого никто кроме него ресурс не использовал (не надо было), а у него "всё работало". Получение доступа к ресурсу - пляски с бубном с привлечением админа для просмотра почты работника.

Проблема 4: нужен root-доступ к серверу (не надо мне рассказывать про sudo, а то я вам расскажу что в случае сбоя и невозможности смонтировать корневую файловую систему в у вас-таки будут спрашивать пароль рута. в single-user. и без сети.). Затем пользователь "для удобства, однозначно" кладёт свой ssh public-key "куда следует" (необязательно руту). И/или копирует в /sbin статический bash с новым именем и ставит на него suid. Или ... Да собственно всё - контроля над системой у вас (повелителей менеджеров паролей) уже нет. Можете менять пароль рута ежеминутно. Варианты решения - полнейший security-аудит. Но я бы предложил переустановку системы.

----

Это то, что лежит на поверхности. Можно сейчас устроить пляски с воплями "запретить", "заставить", "обязать", "наказать" и т.д., но люди есть люди. И если есть возможность сделать проще - они сделают проще. Есть возможность ошибиться - они ошибутся. И рассчитывать на вечную лояльность работников не стоит - она может измениться одномоментно.

Вывод я написал в первых строках:

*любой* [корпоративный] менеджер паролей - это костыль, который создаёт ложную иллюзию "безопасности" и (самое главное) "контролируемости ситуации".

Решение [корпоративное] - оно сильно в другой области. Это решения класса PAM - Privilege Access Management (тоже не без проблем). "Но это уже совсем другая история".

P.S. это я ещё не сел на своего любимого конька "внедрение системы" - про обучение пользователей/владельцев (создание контейнеров, предоставление прав/...), отслеживание скомпроментированных учётных записей, периодическая смена, ...

Банальное создание учётных записей на сторонних ресурсах. Это либо форма на сайте, либо сообщение по e-mail с корпоративной почты "прошу меня зарегистрировать". У некоторых ИБ-вендоров - с корпоративного e-mail + s/n оборудования (или номер сертификата тех. поддержки).

И после этих пары пунктов задача перестаёт быть технической.

Просто поверьте опыту - банальный совместный доступ к почтовому ящику info@ или sales@ на решениях MS Exchange/Outlook становится сильно нетривиальной организационной и технической задачей.

P.P.S. я не против менеджеров паролей как таковых, я против их использования в корпоративной среде - ибо это 1) вопрос доверия, 2) ответственности, 3) [разгильдяйства, 1]. Дома/лично пользуюсь - я себе доверяю (не всегда) и "виноват только я". В менеджер паролей дополнительно вношу логины, url, "секретные вопросы для восстановления пароля", номера телефонов, которые указывал при регистрации. Иногда - пароли шифрования больших/критичных архивов.

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

Судя по всему описанному у вас один пароль на всех пользователей включая админов и он еще и пароль root от сервака и меняет его у вас кто угодно?

Где вы у меня такой бред прочитали? В PPS где я пишу про личное использование? Так там я действительно один пользователь. Ресурсов много, они разные, пароли разные, меняю я сам.

Если у меня внутренняя корпоративная среда - у меня практически нет ресурсов где есть только один "суперадмин" - все работают под своими учётками и со своими (иногда админскими) правами.

Но у меня дофига внешних ресурсов - включая хостинги, VPS'ы и прочее. И если (когда) у меня пользователь имеет доступ к внешнему ресурсу - я не властен запретить ему изменить там пароль.

И в своём комментарии я написал ровно то что написал (повторюсь ещё раз, чтобы искать не пришлось) - *любой* [корпоративный] менеджер паролей - это костыль, который создаёт ложную иллюзию "безопасности" и (самое главное) "контролируемости ситуации"

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

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

У меня (в компании где я работаю) пользователь действительно может удалять данные, к которым имеет доступ. Ну работа у него (у 100% пользователей) такая - где-то что-то править, где-то вносить, где-то удалять. И отключить запись на внешнем ресурсе (даже если он зарегистрирован с корпоративного e-mail'а) он тоже обычно может. И пароль сменить. Свой. На внешнем ресурсе.

О, хранилище паролей, одобренное тов. майором.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий