В мире, где каждая учетная запись требует от нас еще одного пароля, и каждый облачный сервис, такой как AWS, зависит от надежности этих ключей, менеджеры паролей вроде Bitwarden выступают как спасители. Они не просто хранят наши ключи и пароли, но и делают их управление значительно удобнее. Однако, даже с таким мощным инструментом, как Bitwarden, мы сталкиваемся с ограничением: он не способен автоматически обновлять и менять используемые в облачных сервисах ключи и пароли. Итак, что делать, когда ручное обновление ключей и паролей становится скучной и малоэффективной задачей? В этой статье мы исследуем, как можно объединить удобство использования Bitwarden с эффективными методами автоматизации для управления учетными данными AWS. Представьте себе – больше нет монотонного ввода паролей и обновлений ключей вручную. Но для этого придется немного постараться. Что ж, начнем...
А почему, собственно, Bitwarden?
Выбирать инструмент для управления паролями и ключами AWS – это всегда непросто. Но после некоторых раздумий я остановился на Bitwarden, и вот почему он стал моим выбором:
Поддержка любых устройств: Bitwarden работает на всех платформах, которые я использую – это делает его идеальным решением для моих целей. У него есть нативные десктопные клиенты под Windows, Linux и MacOS. Есть родные мобильные приложения под iOS и Android. Есть отдельное приложение для Apple Watch. Есть command-line клиенты под любые платформы. Есть браузерные расширения для Chrome, Safari, Firefox и кучи других браузеров. И наконец есть просто веб-версия, доступная с любого устройства, где есть интернет и доступ к любому браузеру.
Простота и удобство использования: Несмотря на высокий уровень безопасности, Bitwarden остается интуитивно понятным и легким в использовании, что делает его доступным для всех. Особенно приятно наличие почти мгновенной безопасной синхронизации данных с централизованным облачным хранилищем. Так, что секрет, добавленный на одном клиенте, почти моментально становится доступен и на остальных. Для параноиков - можно не использовать родное облачное хранилище от самого сервиса Bitwarden, а использовать self-hosted установку, храня все секреты там, где хочется лично вам. Хоть на том же самом устройстве.
Двухфакторная авторизация и TOTP: Наличие поддержки двухфакторной авторизации и TOTP представляет собой важную функцию, позволяющую генерировать временные одноразовые пароли (TOTP) прямо внутри приложения. Это значительно упрощает процесс двухфакторной аутентификации, позволяя хранить и быстро использовать TOTP для различных веб-сайтов и приложений. В частности, Bitwarden можно использовать как Virtual MFA для авторизации в AWS.
Открытое API и открытый исходный код: Наличие открытого API и командного интерфейса в Bitwarden позволяет мне интегрировать данный сервис в различные сценарии и автоматизировать процессы управления паролями и ключами. Открытый исходный код облегчает аудит безопасности и позволяет легче расширять и улучшать сервис, реализуя новые возможности, в том числе альтернативные клиенты и даже сервер. Например, есть полностью переписанная на Rust серверная часть с полной поддержкой родного API и даже фич, которые в родном приложении доступны лишь для обладателей Premium-подписки.
Из недостатков, наверное, стоит отметить разве что отсутствие встроенной возможности обновлять пароли и ключи для заданных сервисов. Этот недостаток мы и попробуем исправить.
Добавляем данные IAM пользователя AWS в Bitwarden
Давайте для примера предположим, что вы используете облако AWS для ваших задач. При этом вы работаете с одним или несколькими разными аккаунтами AWS, в каждом из которых у вас есть личная учетная запись для которой нужно регулярно менять пароль. Для этого у вас должны быть настроены соответствующие права.
Для начала убедимся, что все необходимые данные для логина в AWS уже занесены в Bitwarden. При входе в консоль AWS обычно требуется ввести имя пользователя IAM и его пароль. Также важно сохранить в Bitwarden номер вашего AWS аккаунта или его псевдоним (alias), который необходим для доступа. Это обеспечит, что у вас всегда под рукой будут все данные для быстрого и безопасного доступа к вашему AWS аккаунту.
Давайте добавим соответствующие данные в Bitwarden, используя мобильный или десктопный клиент. При использовании браузерного расширения Bitwarden сам предлагает сохранить заполненные данные логина, создав новую запись, но мы не будем полагаться на это и попробуем для начала все настроить вручную.
Задаем имя пользователя в поле Username, а пароль - в поле Password. Поле Name служит просто названием карточки логина и может быть использовано для быстрого поиска среди других логинов. Если у вас в аккаунте AWS включена многофакторная аутентификация и Bitwarden добавлен в качестве соответствующего устройства Virtual MFA для вашей учетной записи, то в графе TOTP появится соответствующее значение вида otpauth://totp/Amazon%20Web%20Services:...
Добавить соответствующие данные в карточку логина можно с помощью мобильного приложения Bitwarden, отсканировав QR-код, который создает сам Amazon при добавлении соответствующего устройства MFA.
Также весьма полезно будет добавить дополнительное поле account
с идентификатором AWS аккаунта в графе CUSTOM FIELDS
, если мы не хотим каждый раз вводить или копировать его в форму логина вручную.
В поле Website можно добавить соответствующий адрес URL, тогда при использовании клиента или браузерного расширения Bitwarden сможет автоматически заполнять форму логина нужными данными:
Настраиваем CLI
Итак, у нас уже есть сохраненные данные IAM пользователя для логина в AWS Console. Но мы не хотим каждый раз вручную проделывать эту операцию, после чего также вручную обновлять сохраненные данные в Bitwarden. Для автоматизации данного процесса нам понадобятся следующие инструменты:
POSIX Shell (Bash, Zsh и т.п.) Для Windows тоже можно сделать вариант под cmd или powershell, но при наличии работающего WSL мне это представляется излишним.
Не буду детально останавливаться на установке и настройке данных инструментов, обозначу лишь наиболее значимые моменты.
Для автоматизации действий с помощью Bitwarden CLI нам понадобится настроить авторизацию. Это можно делать различными способами. Наиболее удобный для обычного пользователя - использование персонального ключа API, который можно создать в профиле Bitwarden. После чего нужно в консоли выполнить команду
bw login --apikey
и ввести в ответ на запрос соответствующие данные client_id
и client_secret
. Либо можно задать соответствующие переменные окружения BW_CLIENTID
и BW_CLIENTSECRET
.
Для работы с данными нам нужен не только успешный логин, но и unlock хранилища секретов. Это можно сделать вручную с помощью команды
bw unlock
Для разблокировки потребуется также ввести мастер-пароль, дающий доступ к зашифрованным данным. Это стоит делать только непосредственно при работе с данными. По окончании работы следует выполнить команду bw lock
.
При успешном выполнении процедуры unlock будет создан временный сессионный ключ, который нам нужно будет использовать при выполнении любых операций с данными. Нам нужно задать его в виде переменной окружения для выполнения дальнейших команд:
export BW_SESSION="5PBYGU+5yt3RHcCjoeJKx/wByU34vokGRZjXpSH7Ylo8w=="
Если нам нужно выполнить полностью автоматическую процедуру логина и анлока, то это тоже можно сделать, задав соответствующие переменные окружения. Помимо упомянутых выше BW_CLIENTID
и BW_CLIENTSECRET
нам нужна будет еще и переменная BW_PASSWORD
, которой мы присвоим значение нашего мастер-пароля, который мы используем для разблокировки хранилища секретов.
Тогда выполнить автоматическую разблокировку можно простым выполнением команды
bw unlock --passwordenv BW_PASSWORD
После выполнения Bitwarden вернет нам в стандартном выводе значение переменной BW_SESSION
в виде готовой для исполнения команды. Если мы хотим полностью автоматизировать этот процесс, можно выполнить разблокировку следующим образом:
$(bw unlock --passwordenv BW_PASSWORD | awk '/export/ {print $2, $3}')
Так мы сразу разблокируем хранилище секретов и назначим правильное значение переменной BW_SESSION
без дополнительных ручных действий. После этого можно выполнить команду
bw sync
чтобы синхронизировать локальные данные хранилища с удаленным. При этом выполняется операция pull для получения всех последних изменений в хранилище секретов. Например, если вы создали какой-то секрет в Bitwarden с помощью другого приложения, клиента или вообще с другого устройства, то после выполнения этой команды вам станут доступны все последние изменения в хранилище ваших секретов.
Теперь можно заняться автоматизацией конкретных задач.
Меняем пароль IAM пользователя AWS
Возьмем для примера созданную нами чуть ранее запись с логином и паролем для пользователя john.doe и попробуем реализовать механизм изменения его пароля с автоматическим обновлением соответствующей записи в Bitwarden.
Для начала попробуем найти, как выглядит структура данных внутри записи при обращении к ней с помощью Bitwarden CLI. Чтобы вывести на экран данные записи для нашего логина с именем my_aws_account, используем следующую команду:
> bw get item my_aws_account --pretty
{
"passwordHistory": null,
"revisionDate": "2024-01-01T00:01:29.890Z",
"creationDate": "2024-01-01T00:01:29.890Z",
"deletedDate": null,
"object": "item",
"id": "32d1547c-5d14-37f2-7c2a-a0ef315dca6f",
"organizationId": null,
"folderId": "3f0a8c4a-9b5c-4f4d-9f9c-9c6a00a8f9e5",
"type": 1,
"reprompt": 0,
"name": "my_aws_account",
"notes": null,
"favorite": false,
"fields": [
{
"name": "account",
"value": "123412341234",
"type": 0,
"linkedId": null
}
],
"login": {
"fido2Credentials": [],
"uris": [
{
"match": null,
"uri": "https://eu-north-1.signin.aws.amazon.com/"
}
],
"username": "john.doe",
"password": "My_R@nd0m_$tr1ng",
"totp": null,
"passwordRevisionDate": null
},
"collectionIds": []
}
Мы видим, что у записи есть множество разных атрибутов. Но нас интересуют самые основные. Это id, login.username и login.password. Для поиска записей можно использовать значение поля name
, но этот параметр не обязательно будет уникальным, поэтому поиск может вернуть несколько разных записей. Чтобы обратиться к одной конкретной записи, лучше использовать ее уникальный идентификатор из поля id. Присвоим его значение конкретной переменной для удобства:
BW_ITEM_ID="32d1547c-5d14-37f2-7c2a-a0ef315dca6f"
Теперь получим старый пароль из записи Bitwarden, используя ее ID:
OLD_PASSWORD=$(bw get password "$BW_ITEM_ID")
Сгенерируем новый случайный с помощью команды bw generate:
NEW_PASSWORD=$(bw generate --length 16 --uppercase --lowercase --number --special)
Здесь в качестве параметров для генерации нового пароля мы указываем его длину (16 символов), обязательное наличие символов в верхнем регистре (uppercase), символов в нижнем регистре (lowercase), наличие цифр (number) и спецсимволов (special). В итоге в качестве значений переменной NEW_PASSWORD
мы получим случайную строку вида 9@8NfuGZ!&5pJoy%
.
Теперь, используя старый пароль, мы можем задать нашей учетной записи новый с помощью команды aws iam change-password
. Для выполнения данной команды нам потребуется также настроенный и работающий AWS CLI. Не будем здесь останавливаться подробно на деталях настройки данного инструмента. Нужно только отметить, что если вы используете различные аккаунты AWS, то скорее всего у вас настроены разные профили для доступа к командной строке с разными ключами для соответствующих аккаунтов. Поэтому при вызове команды нам также понадобится указать соответствующий профиль AWS в виде переменной AWS_PROFILE
. Если у вас нет разных профилей в настройках AWS CLI, либо вы используете другой источник ключей для доступа к AWS (например, переменные окружения), можете не указывать этот параметр. У нас получилось следующая команда:
aws iam change-password \
--old-password "$OLD_PASSWORD" \
--new-password "$NEW_PASSWORD" \
--profile "$AWS_PROFILE" && \
echo "Password changed successfully for profile '$AWS_PROFILE'." || {
echo "Failed to change password for profile '$AWS_PROFILE'."
return 1
}
Если доступ к AWS CLI настроен правильно, переменная OLD_PASSWORD
соответствует значению старого пароля, а значение переменной NEW_PASSWORD
соответствует требованиям к паролю для учетной записи AWS, то команда выполнится успешно и на экран выведется соответствующее сообщение. Если же по какой-то причине команда не завершится успешно, об этом тоже появится соответствующее сообщение.
Если все прошло успешно, то значит, новый пароль успешно задан и нам осталось лишь отредактировать нашу запись для учетной записи john.doe в Bitwarden, чтобы обновить значение пароля для данной записи. Чтобы сделать это из командной строки, нам придется воспользоваться также утилитой jq для работы с JSON. Итоговая команда по обновлению пароля в соответствующей записи Bitwarden будет выглядеть так:
bw get item "$BW_ITEM_ID" | jq --arg password "$NEW_PASSWORD" '.login.password = $password' | bw encode | bw edit item "$BW_ITEM_ID" >/dev/null
Если не перенаправить вывод итоговой команды в /dev/null, то на экран будет выведен итоговый JSON для нашей записи со всеми секретами, что не всегда полезно при работе в консоли. Поэтому для автоматизированных задач лучше отключить данный вывод.
В итоге мы с помощью Bitwarden CLI, AWS CLI и jq смогли сгенерировать новый пароль для выбранной нами учетной записи пользователя в AWS, а также смогли обновить соответствующую запись в нашем хранилище секретов Bitwarden.
Давайте теперь объединим данные команды в рамках одной общей функции, которую мы сможем вызывать одной командой из консоли. Получим примерно следующее:
rotate_aws_password() {
local AWS_PROFILE=my_profile
local BW_ITEM_ID="32d1547c-5d14-37f2-7c2a-a0ef315dca6f"
# Fetch the old AWS console password from Bitwarden
OLD_PASSWORD=$(bw get password "$BW_ITEM_ID")
# Generate new random password using Bitwarden CLI
NEW_PASSWORD=$(bw generate --length 16 --uppercase --lowercase --number --special)
# Use AWS CLI to change the password with the specified profile
aws iam change-password \
--old-password "$OLD_PASSWORD" \
--new-password "$NEW_PASSWORD" \
--profile "$AWS_PROFILE" && \
echo "Password changed successfully for profile '$AWS_PROFILE'." || {
echo "Failed to change password for profile '$AWS_PROFILE'."
return 1
}
# Update the password in Bitwarden
bw get item "$BW_ITEM_ID" | jq --arg password "$NEW_PASSWORD" '.login.password = $password' | bw encode | bw edit item "$BW_ITEM_ID" >/dev/null
# Clear the entered passwords from the shell environment for security
unset OLD_PASSWORD NEW_PASSWORD
}
Если добавить данный код в профиль вашего окружения для командного интерпретатора (.bashrc для Bash, .zshrc для Zsh и т.п.), то всю последовательность описанных выше действий можно запустить всего лишь одной командой:
> rotate_aws_password
Password changed successfully for profile 'my_profile'.
Можно проверить запись в соответствующей карточке Bitwarden и убедиться, что пароль для учетной записи john.doe действительно обновился.
Заключение
Мы рассмотрели пример автоматизации смены пароля для учетной записи AWS с использованием простых шелл-скриптов, а также с автоматическим обновлением сохраненных паролей в хранилище Bitwarden. Аналогичным образом можно автоматизировать ротацию ключей доступа к AWS CLI, получение временных токенов для доступа к AWS с использованием MFA и т.п. Если будет соответствующий запрос, попробую осветить данные моменты в следующих статьях.
Надеюсь, эта статья окажется полезной для упрощения вашей работы с AWS и Bitwarden. Я буду рад обсудить ваши идеи и предложения по дальнейшему улучшению автоматизации управления паролями. Буду рад любым отзывам в комментариях. Всего доброго.
Комментарии (29)
Tamerlan666 Автор
03.01.2024 14:22Что имеется в виду под аналогами AWS Secrets?
Dmitri-D
03.01.2024 14:22Видимо, AWS SM - Secret Manager - который прекрасно умеет хранить и ротировать пароли, или оркестрировать ротацию паролей и, в общем-то, делает все эти усилия выше немного излишними
https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.htmlvasyakrg
03.01.2024 14:22Прикольно,
$0.40 per secret per month
$0.05 per 10,000 API calls
У меня 480 паролей (и примерно столько же в корзине) в 1password за 39 баксов в год.
Только у меня еще и кредитки, ssh ключи и cli для автоматизации.
Рабочий vaultwarden (отличный кстати форк битвардена) тоже использую, но у него похуже с интеграциями с браузерами, не везде работает так, как надо
Dmitri-D
03.01.2024 14:22+11password - это не конкурент, просто продукт, реализацию которого никто толком не сертифицировал. 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/vasyakrg
03.01.2024 14:22ну во-первых, нативная поддержка от apple хоть чего-то да стоит. вряд ли бы они такое к себе затащили.
во-вторых, я физик и использую ее давно и в личных целях, я - не правительство, у меня запросы проще.
все, что помню, что за годы использования (а это уже лет 10 точно) я ни разу не слышал, чтоб их ломали, а про другие аналоги слышал. мне этого достаточно.
а вот отдавать по 240 баксов в месяц я пока не готов. тем более что эти продукты действительно не конкуренты даже близко. разные задачи решают.
Dmitri-D
03.01.2024 14:22Всё логично, кроме одного. Если вы сохранили 480 паролей - это не означает, что вы создали 480 записей. Всё определяется количеством учетных записей, через которые вы получаете эти пароли. Если, как следует из названия 1password, у вас 1учетная запись, то это и есть 1 запись с 480 полями. Иными словами, тот кто сломает вашу учетную запись получит всё 480 оптом. Тогда соответствующий подсчет для SM будет тоже 1 запись. Сериализуйте пароли в json или что-то подобное и храните там. Разумеется, в SM есть ограничения на длину, если упретесь придется разбить на 2, например. Ок, но всё равно это будет $0.5 или $1, но не $240.
По поводу "не слышали"... Ну я привел выше CVE. А если реально - ну вот Октябрь 2023, достаточно свежее?vasyakrg
03.01.2024 14:22После тщательного расследования мы пришли к выводу, что доступ к данным пользователей 1Password не был получен
Но суть не в этом.
То есть автор со своими скриптами немного излишнее делает, а пароли заворачивать в json - это норм ))
На сим предлагаю и закончить.
Dmitri-D
03.01.2024 14:22доступ к данным пользователей 1Password не был получен
да, только токеном админа Okta воспользовались через пол месяца и cloudflare об этом писала и которая тоже пострадала от этого же проникновения. Т.е. дальше вопрос к Okta что на самом деле утекло, а не к 1password. И судя по обтекаемой формулировке - 1password не знают. Они просто пришли к выводу.
про json - это просто моя попытка продемонстрировать вам эквивалент для сравнения. Да, вы этого не делаете в случае 1password, но в сущности за вас это делает этот ваш сервис. А SM - каждая запись имеет отдельный ARN и доступ к ней разделен и регулируется правами IAM. Т.е. утечка 1 учетной записи (юзера или роли в IAM) не компроментирует все пароли сразу, а только те, к которым вы, как пользователь SM настроили доступ у этой учетной записи (IAM user или role). Т.о. функционал разный, поэтому цену сравнивать некорректно. Корректно сравнивать 1 запись в SM с N записей в 1password к которым имеет доступ 1 учетная запись.
Tamerlan666 Автор
03.01.2024 14:22Даже если спереть всю базу пользователей парольного менеджера со всеми их зашифрованными данными, это не даст доступ к самим данным. Нужны еще и пользовательские ключи, а они в базе не хранятся.
Tamerlan666 Автор
03.01.2024 14:22А SM - каждая запись имеет отдельный ARN и доступ к ней разделен и регулируется правами IAM. Т.е. утечка 1 учетной записи (юзера или роли в IAM) не компроментирует все пароли сразу, а только те, к которым вы, как пользователь SM настроили доступ у этой учетной записи (IAM user или role).
Утечка админской учетки даст доступ ко всем секретам SM. Никакой IAM от этого не спасет.
Tamerlan666 Автор
03.01.2024 14:22А как у AWS Secrets Manager с интеграцией с браузерами и мобильными приложениями? Как он мне поможет логиниться в ту же AWS Console, не вводя каждый раз пароли руками?
Dmitri-D
03.01.2024 14:22SM - это всего лишь хранение и ротация паролей или секретов с доступом после аутентификации. Сервис, к которому получаете доступ так же, как к 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.
Tamerlan666 Автор
03.01.2024 14:22SM - это всего лишь хранение и ротация паролей или секретов с доступом после аутентификации. Сервис, к которому получаете доступ так же, как к S3 или EC2 или Lambda, т.е. из console, cli, sdk, etc.
Я в курсе как работает AWS SM, спасибо. Все это никак не заменяет обычной задачи логиниться в тот же AWS, вводя пароли. И нет - AWS SSO от этого никак не избавляет, т.к. в для логина в SSO ВНЕЗАПНО пароль тоже нужно вводить. И этот же пароль тоже периодически нужно менять и где-то хранить. И если вы работаете с десятком совершенно разных клиентов из разных стран, наличие даже у каждого из них AWS SSO никак не облегчит вам жизнь. Вам точно также придется логиниться в десять разных SSO вместо консоли амазона. И менять пароли в десяти разных местах с разными политиками безопасности и временами жизни пароля.
Dmitri-D
03.01.2024 14:22Я в курсе как работает 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
Joka
03.01.2024 14:22Двухфакторная авторизация и TOTP: Наличие поддержки двухфакторной авторизации и TOTP представляет собой важную функцию, позволяющую генерировать временные одноразовые пароли (TOTP) прямо внутри приложения. Это значительно упрощает процесс двухфакторной аутентификации, позволяя хранить и быстро использовать TOTP для различных веб-сайтов и приложений. В частности, Bitwarden можно использовать как Virtual MFA для авторизации в AWS.
2ФА для этого и придумали чтобы разнести пароль + еще "пароль" на разные устройства. Украсть оба сразу гораздо сложнее чем один. А хранить TOTP рядом с паролем такое себе удовольствие. При хранении TOTP отдельно кража bitwarden базы хоть и омрачит действительность, но сильно страшной не будет, потому как 2ФА спасет.
Tamerlan666 Автор
03.01.2024 14:22+1В данном случае просто кража базы Bitwarden совершенно бессмысленна. Т.к. это просто залоченный набор зашифрованных байт. Доступ к расшифрованным данным появляется лишь в рамках конкретного сеанса на конкретном устройстве после ряда специальных процедур.
Т.е. да - теоретически хранение TOTP в парольном менеджере более уязвимо, чем в отдельном приложении. Но практически с хорошим менеджером и надежной защитой эта конструкция гораздо более надежна, чем просто пароли без использования менеджера, но с отдельным TOTP.
Если интересует прям максимальная секьюрность, этот функционал использовать никто не заставляет. Можно использовать Bitwarden как хранилище пароля, а для TOTP использовать другое устройство. Либо наоборот - пароли хранить в другом сервисе, а в качестве TOTP использовать Bitwarden. Тут уже выбор исключительно за пользователем.
vasyakrg
03.01.2024 14:22Все это конечно хорошо, только вот у вас вообще все пароли, включая мастер в переменных окружения. Выглядит мега не секьюрно.
Можно конечно отдельную учетку для aws завести в битвардене и в отдельную организацию добавить, но так логиниться в aws будет сложнее, чем в ручную обновить два поля.
Tamerlan666 Автор
03.01.2024 14:22Все эти переменные окружения нужны лишь на этапе анлока хранилища для вытаскивания нужного ключа и его обновления. Ничто не мешает руками их передавать тем же командам любым удобным способом, а потом тут же лочить Bitwarden и ансетать эти переменные. Собственно, достаточно убрать переменную с паролем и залочить сессию - и все. Никакая секьюрность не страдает.
Tamerlan666 Автор
03.01.2024 14:22Условно говоря, тот же bw unlock можно сделать руками, передав пароль на вход вручную любым способом. А после обновления пароля учетки и записи в хранилище, сразу залочить обратно. И все.
aborouhin
03.01.2024 14:222FA - это не про разные устройства, а про разные факторы. Знание + владение. По большому счёту, любой парольный менеджер, даже без TOTP-токенов, уже ломает 2FA, т.к. вместо знание + владение получается владение (доступ к менеджеру) + владение (доступ к 2FA) + сильно ослабленное знание (только одного мастер-пароля). Улучшает картину доступ к парольному менеджеру через отдельную 2FA. Ухудшает картину хранение TOTP-токенов в парольном менеджере. Сильно улучшает картину доступ к парольному менеджеру только через VPN со своей 2FA. И т.д. и т.п. В общем, тут каждый в зависимости от своей модели угроз выбирает баланс между безопасностью и удобством, тут вряд ли уместно какие-то жёсткие критерии применять.
Tamerlan666 Автор
03.01.2024 14:22Есть хорошая статья на эту тему от 1password:
https://blog.1password.com/1password-2fa-passwords-codes-together/
Если коротко, суть в том, что если вы используете TOTP и пароль из разных приложений, но на одном устройстве (смартфоне, например), то это примерно тот же самый уровень безопасности, что и хранить все вместе в одном парольном менеджере.Joka
03.01.2024 14:22Они умалчивают о факте взлома самого 1password. Вон lastpass уже ни раз и ни два ломали, и если бы там хранились ключи 2FA, то было бы вообще все плохо и грустно. Таким образом хранение 2FA ключей в отдельном приложении защищает от ситуации взлома провайдера хранения паролей или же хранения ключей. 2 сервиса взломать сложнее чем 1. А если уж у злоумышленника появился доступ к вашему устройству, нууу, тут мало что поможет в принципе кроме как иметь 2 устройства. Ну и тд. Все зависит от степени надежности сервисов.
Tamerlan666 Автор
03.01.2024 14:22Если парольный менеджер спроектирован нормально, то взлом и кража самого хранилища паролей никак не компрометирует сохраненные там данные. Они все равно бесполезны без пользовательских ключей, которые в этой базе не хранятся. Если же украдены ключи доступа пользователя к базе парольного менеджера, то тут никакая кража базы уже не нужна.
savostin
03.01.2024 14:22Я б еще старый пароль сохранял в поле Bitwarden, так на всякий…
Tamerlan666 Автор
03.01.2024 14:22+2Он сам автоматически хранит историю паролей для каждой записи. Ничего специально сохранять не нужно. В примере со структурой записи секрета выше можно увидеть поле passwordHistory. В нашем примере оно пустое, т.к. в тестовом примере не было предыдущих значений. Но при обновлении значении пароля в этом поле появляется список из старых значений пароля.
andreyverbin
03.01.2024 14:22Не надо так делать. Надо AWS IAM Identity Center, который каждому юзер выдаст временный ключ. Для смены паролей установить password policy.
Tamerlan666 Автор
03.01.2024 14:22+1И как AWS IAM Identity Center спасет от необходимости помнить пароль от своей учетной записи и вводить ее? Password policy просто заставляет вас менять пароль в определенное время, но никак не помогает его сохранить.
Ryav
Не в курсе, кстати, скоро ли в реализации сервера на Rust появится поддержка аналога AWS Secrets?