Комментарии 30
Не в курсе, кстати, скоро ли в реализации сервера на Rust появится поддержка аналога AWS Secrets?
Что имеется в виду под аналогами AWS Secrets?
Видимо, AWS SM - Secret Manager - который прекрасно умеет хранить и ротировать пароли, или оркестрировать ротацию паролей и, в общем-то, делает все эти усилия выше немного излишними
https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html
Прикольно,
$0.40 per secret per month
$0.05 per 10,000 API calls
У меня 480 паролей (и примерно столько же в корзине) в 1password за 39 баксов в год.
Только у меня еще и кредитки, ssh ключи и cli для автоматизации.
Рабочий vaultwarden (отличный кстати форк битвардена) тоже использую, но у него похуже с интеграциями с браузерами, не везде работает так, как надо
1password - это не конкурент, просто продукт, реализацию которого никто толком не сертифицировал. 4 компании, возможно, посмотрели исходники и написали отчеты. Про репутацию этих компаний - мне ничего не известно. А вам? Если взглянуть на CVE-2022-29868 - и это во время этих репортов. Нормально.
AWS SM - вполне себе отстроенный сервис, прошедший High FedRAMP сертификацию. Его правительства могут использовать. Его спецслужбы могут использовать. А этот 1password? Но всё определяется целями и средствами.
https://aws.amazon.com/about-aws/whats-new/2021/06/aws-systems-manager-is-now-fedramp-high-compliant/
ну во-первых, нативная поддержка от apple хоть чего-то да стоит. вряд ли бы они такое к себе затащили.
во-вторых, я физик и использую ее давно и в личных целях, я - не правительство, у меня запросы проще.
все, что помню, что за годы использования (а это уже лет 10 точно) я ни разу не слышал, чтоб их ломали, а про другие аналоги слышал. мне этого достаточно.
а вот отдавать по 240 баксов в месяц я пока не готов. тем более что эти продукты действительно не конкуренты даже близко. разные задачи решают.
Всё логично, кроме одного. Если вы сохранили 480 паролей - это не означает, что вы создали 480 записей. Всё определяется количеством учетных записей, через которые вы получаете эти пароли. Если, как следует из названия 1password, у вас 1учетная запись, то это и есть 1 запись с 480 полями. Иными словами, тот кто сломает вашу учетную запись получит всё 480 оптом. Тогда соответствующий подсчет для SM будет тоже 1 запись. Сериализуйте пароли в json или что-то подобное и храните там. Разумеется, в SM есть ограничения на длину, если упретесь придется разбить на 2, например. Ок, но всё равно это будет $0.5 или $1, но не $240.
По поводу "не слышали"... Ну я привел выше CVE. А если реально - ну вот Октябрь 2023, достаточно свежее?
После тщательного расследования мы пришли к выводу, что доступ к данным пользователей 1Password не был получен
Но суть не в этом.
То есть автор со своими скриптами немного излишнее делает, а пароли заворачивать в json - это норм ))
На сим предлагаю и закончить.
доступ к данным пользователей 1Password не был получен
да, только токеном админа Okta воспользовались через пол месяца и cloudflare об этом писала и которая тоже пострадала от этого же проникновения. Т.е. дальше вопрос к Okta что на самом деле утекло, а не к 1password. И судя по обтекаемой формулировке - 1password не знают. Они просто пришли к выводу.
про json - это просто моя попытка продемонстрировать вам эквивалент для сравнения. Да, вы этого не делаете в случае 1password, но в сущности за вас это делает этот ваш сервис. А SM - каждая запись имеет отдельный ARN и доступ к ней разделен и регулируется правами IAM. Т.е. утечка 1 учетной записи (юзера или роли в IAM) не компроментирует все пароли сразу, а только те, к которым вы, как пользователь SM настроили доступ у этой учетной записи (IAM user или role). Т.о. функционал разный, поэтому цену сравнивать некорректно. Корректно сравнивать 1 запись в SM с N записей в 1password к которым имеет доступ 1 учетная запись.
Даже если спереть всю базу пользователей парольного менеджера со всеми их зашифрованными данными, это не даст доступ к самим данным. Нужны еще и пользовательские ключи, а они в базе не хранятся.
А SM - каждая запись имеет отдельный ARN и доступ к ней разделен и регулируется правами IAM. Т.е. утечка 1 учетной записи (юзера или роли в IAM) не компроментирует все пароли сразу, а только те, к которым вы, как пользователь SM настроили доступ у этой учетной записи (IAM user или role).
Утечка админской учетки даст доступ ко всем секретам SM. Никакой IAM от этого не спасет.
А как у AWS Secrets Manager с интеграцией с браузерами и мобильными приложениями? Как он мне поможет логиниться в ту же AWS Console, не вводя каждый раз пароли руками?
SM - это всего лишь хранение и ротация паролей или секретов с доступом после аутентификации. Сервис, к которому получаете доступ так же, как к S3 или EC2 или Lambda, т.е. из console, cli, sdk, etc.
Если нужно облегчить аутентификацию - есть AWS SSO (внутри это тот же IAM) и, если надо, федерация с Azure ID (AD) или Okta. Т.е. токены полученные там могут аутентифицировать здесь. Это доступ к AWS сервисам.
https://docs.aws.amazon.com/cli/latest/userguide/sso-configure-profile-token.html
Если вам нужно что-то похожее для доступа к вашему приложению, которое вы запускаете в AWS - то добро пожаловать в AWS Cognito. Там тоже есть федерация с внешней аутентификацией или OAuth2.
SM - это всего лишь хранение и ротация паролей или секретов с доступом после аутентификации. Сервис, к которому получаете доступ так же, как к S3 или EC2 или Lambda, т.е. из console, cli, sdk, etc.
Я в курсе как работает AWS SM, спасибо. Все это никак не заменяет обычной задачи логиниться в тот же AWS, вводя пароли. И нет - AWS SSO от этого никак не избавляет, т.к. в для логина в SSO ВНЕЗАПНО пароль тоже нужно вводить. И этот же пароль тоже периодически нужно менять и где-то хранить. И если вы работаете с десятком совершенно разных клиентов из разных стран, наличие даже у каждого из них AWS SSO никак не облегчит вам жизнь. Вам точно также придется логиниться в десять разных SSO вместо консоли амазона. И менять пароли в десяти разных местах с разными политиками безопасности и временами жизни пароля.
Я в курсе как работает AWS SM, спасибо
отлично, тогда в чем вопрос?
AWS SSO от этого никак не избавляет, т.к. в для логина в SSO ВНЕЗАПНО пароль тоже нужно вводить.
нет конечно. Еще раз - вы можете подключить федерацию. Что такое надо объяснять или вы снова внезапно знаете?
На всякий случай намекну - без чего не пустят - это без токена аутентификации. Но его не обязательно вводить в виде пароля и не обязательно вводить на сайте консоли.
https://aws.amazon.com/blogs/contact-center/enabling-federation-with-aws-single-sign-on-and-amazon-connect/
И если вы работаете с десятком совершенно разных клиентов из разных стран, наличие даже у каждого из них AWS SSO никак не облегчит вам жизнь. Вам точно также придется логиниться в десять разных SSO вместо консоли амазон
понятно. Начинайте изучать что такое SINGLE SIGN ON.
Слово SINGLE ни о чем не намекает?
https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html
нет конечно. Еще раз - вы можете подключить федерацию. Что такое надо объяснять или вы снова внезапно знаете?
Знаю, конечно. Чего не знаю - так это того, каким образом это позволит вам использовать секреты, хранящиеся внутри AWS, для входа в сам AWS.
На всякий случай намекну - без чего не пустят - это без токена аутентификации. Но его не обязательно вводить в виде пароля и не обязательно вводить на сайте консоли.
Обычно аутентификация в SSO происходит как раз в виде пароля. Который так или иначе нужно вводить. Можно, конечно использовать всякие аппаратные ключи, но это по большей части экзотика.
понятно. Начинайте изучать что такое SINGLE SIGN ON.
Слово SINGLE ни о чем не намекает?
Слово SINGLE намекает на то, что в рамках одной конкретной инфраструктуры (если точнее - в рамках одного IdP провайдера) это дает возможность не логиниться отдельно на каждый ресурс, а залогиниться один раз и сразу получить доступ ко всем ресурсам, имеющим интеграцию с этой SSO. В какой удивительной вселенной вы видели, чтобы большинство обычных организаций, владеющих серьезной инфраструктурой, соглашались пускать к себе пользователей, авторизованных непонятно где, непонятно как?
Двухфакторная авторизация и TOTP: Наличие поддержки двухфакторной авторизации и TOTP представляет собой важную функцию, позволяющую генерировать временные одноразовые пароли (TOTP) прямо внутри приложения. Это значительно упрощает процесс двухфакторной аутентификации, позволяя хранить и быстро использовать TOTP для различных веб-сайтов и приложений. В частности, Bitwarden можно использовать как Virtual MFA для авторизации в AWS.
2ФА для этого и придумали чтобы разнести пароль + еще "пароль" на разные устройства. Украсть оба сразу гораздо сложнее чем один. А хранить TOTP рядом с паролем такое себе удовольствие. При хранении TOTP отдельно кража bitwarden базы хоть и омрачит действительность, но сильно страшной не будет, потому как 2ФА спасет.
В данном случае просто кража базы Bitwarden совершенно бессмысленна. Т.к. это просто залоченный набор зашифрованных байт. Доступ к расшифрованным данным появляется лишь в рамках конкретного сеанса на конкретном устройстве после ряда специальных процедур.
Т.е. да - теоретически хранение TOTP в парольном менеджере более уязвимо, чем в отдельном приложении. Но практически с хорошим менеджером и надежной защитой эта конструкция гораздо более надежна, чем просто пароли без использования менеджера, но с отдельным TOTP.
Если интересует прям максимальная секьюрность, этот функционал использовать никто не заставляет. Можно использовать Bitwarden как хранилище пароля, а для TOTP использовать другое устройство. Либо наоборот - пароли хранить в другом сервисе, а в качестве TOTP использовать Bitwarden. Тут уже выбор исключительно за пользователем.
Все это конечно хорошо, только вот у вас вообще все пароли, включая мастер в переменных окружения. Выглядит мега не секьюрно.
Можно конечно отдельную учетку для aws завести в битвардене и в отдельную организацию добавить, но так логиниться в aws будет сложнее, чем в ручную обновить два поля.
Все эти переменные окружения нужны лишь на этапе анлока хранилища для вытаскивания нужного ключа и его обновления. Ничто не мешает руками их передавать тем же командам любым удобным способом, а потом тут же лочить Bitwarden и ансетать эти переменные. Собственно, достаточно убрать переменную с паролем и залочить сессию - и все. Никакая секьюрность не страдает.
Условно говоря, тот же bw unlock можно сделать руками, передав пароль на вход вручную любым способом. А после обновления пароля учетки и записи в хранилище, сразу залочить обратно. И все.
2FA - это не про разные устройства, а про разные факторы. Знание + владение. По большому счёту, любой парольный менеджер, даже без TOTP-токенов, уже ломает 2FA, т.к. вместо знание + владение получается владение (доступ к менеджеру) + владение (доступ к 2FA) + сильно ослабленное знание (только одного мастер-пароля). Улучшает картину доступ к парольному менеджеру через отдельную 2FA. Ухудшает картину хранение TOTP-токенов в парольном менеджере. Сильно улучшает картину доступ к парольному менеджеру только через VPN со своей 2FA. И т.д. и т.п. В общем, тут каждый в зависимости от своей модели угроз выбирает баланс между безопасностью и удобством, тут вряд ли уместно какие-то жёсткие критерии применять.
Есть хорошая статья на эту тему от 1password:
https://blog.1password.com/1password-2fa-passwords-codes-together/
Если коротко, суть в том, что если вы используете TOTP и пароль из разных приложений, но на одном устройстве (смартфоне, например), то это примерно тот же самый уровень безопасности, что и хранить все вместе в одном парольном менеджере.
Они умалчивают о факте взлома самого 1password. Вон lastpass уже ни раз и ни два ломали, и если бы там хранились ключи 2FA, то было бы вообще все плохо и грустно. Таким образом хранение 2FA ключей в отдельном приложении защищает от ситуации взлома провайдера хранения паролей или же хранения ключей. 2 сервиса взломать сложнее чем 1. А если уж у злоумышленника появился доступ к вашему устройству, нууу, тут мало что поможет в принципе кроме как иметь 2 устройства. Ну и тд. Все зависит от степени надежности сервисов.
Если парольный менеджер спроектирован нормально, то взлом и кража самого хранилища паролей никак не компрометирует сохраненные там данные. Они все равно бесполезны без пользовательских ключей, которые в этой базе не хранятся. Если же украдены ключи доступа пользователя к базе парольного менеджера, то тут никакая кража базы уже не нужна.
Я б еще старый пароль сохранял в поле Bitwarden, так на всякий…
Он сам автоматически хранит историю паролей для каждой записи. Ничего специально сохранять не нужно. В примере со структурой записи секрета выше можно увидеть поле passwordHistory. В нашем примере оно пустое, т.к. в тестовом примере не было предыдущих значений. Но при обновлении значении пароля в этом поле появляется список из старых значений пароля.
Не надо так делать. Надо AWS IAM Identity Center, который каждому юзер выдаст временный ключ. Для смены паролей установить password policy.
Bitwarden в действии: Автоматизация смены ключей и паролей для AWS