Vault это что: Храним секреты приложения в Vault

Содержание

Храним секреты приложения в Vault

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

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

Что такое Vault

Vault — это утилита командной строки в комплекте с RESTful сервисом, которая отвечает за управление секретами — логинами, паролями, ключами, сертификатами и прочими таинствами. «Управление» включает в себя как хранение, так и выдачу секретов конкретным приложениям с пометкой у себя в журнале, кому и когда это произошло.

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

Установка

Практически всё, что делает HashiCorp, можно скачать в виде архива и просто запустить. Вот бы все так делали. Свой vault я скачал на Mac, так что все примеры будут с лёгким ароматом линуксовой командной строки. Тем, кто любит виндовые ароматы, расстраиваться на стоит, потому что vault поддерживает и их. Морально и платформенно.

«Hello world!»

Для начала создадим что-нибудь простое, рабочее и бесполезное. Чтобы просто посмотреть, как vault работает. Так как в него входит и утилита, и RESTful сервер, то последний нужно как-то запустить. Для игр и экспериментов это можно сделать вот такой командой:

vault server -dev
#==> Vault server configuration:
#. ..
#The only step you need to take is to set the following environment variables:
#
# export VAULT_ADDR=’http://127.0.0.1:8200′
#…
#Unseal Key: JMe7A0cECXKLnSP8pQmKIrku3if1NWzgrTiLSeRQcPA=
#Root Token: 18924580-71bd-f5e0-a218-50bfada86741
#
#==> Vault server started! Log data will stream in below:
#…



vault server -dev

#==> Vault server configuration:

#…

#The only step you need to take is to set the following environment variables:

#

#    export VAULT_ADDR=’http://127.0.0.1:8200′

#…

#Unseal Key: JMe7A0cECXKLnSP8pQmKIrku3if1NWzgrTiLSeRQcPA=

#Root Token: 18924580-71bd-f5e0-a218-50bfada86741

#

#==> Vault server started! Log data will stream in below:

#…

В dev режиме сервер работает по HTTP, что обязательно приведёт в ступор vault клиента. Но его можно успокоить, разъяснив через переменную среды (
VAULT_ADDR ), что HTTPS на сегодня отменяется. Что самое приятное, vault server –dev даже вывел команду, которая может это сделать. Так что CTRL+C, CTRL+V — и всё работает:

export VAULT_ADDR=’http://127.0.0.1:8200′
# writes nothing



export VAULT_ADDR=’http://127.0.0.1:8200′

# writes nothing

Теперь мы можем посохранять какие-нибудь секретные данные. Например, представим, что у нас есть staging база данных, логин и пароль к которой (“sa”, “1”) нельзя показывать посторонним. Сохранить эти параметры можно под ключом secret/db-staging (как путь в файловой системе):

vault write secret/db-staging name=sa password=1



vault write secret/db-staging name=sa password=1

Вообще просто. Прочитать их назад ещё проще:

vault read secret/db-staging
#Key Value
#. ..
#name sa
#password 1



vault read secret/db-staging

#Key             Value

#…

#name             sa

#password           1

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

curl http://127.0.0.1:8200/v1/secret/db-staging
# {«errors»:[«missing client token»]}



curl http://127.0.0.1:8200/v1/secret/db-staging

# {«errors»:[«missing client token»]}

Для авторизации vault использует секретные токены и у нас даже есть один такой — для root. Его выводила всё та же команда запуска сервера (vault server –dev output). Им и воспользуемся:

curl -s \
—header «X-Vault-Token: 18924580-71bd-f5e0-a218-50bfada86741» \
http://127.0.0.1:8200/v1/secret/db-staging \
| jq ‘.data’

#{
# «name»: «sa»,
# «password»: «1»
#}



curl -s \

—header «X-Vault-Token: 18924580-71bd-f5e0-a218-50bfada86741» \

http://127.0.0.1:8200/v1/secret/db-staging \

| jq ‘.data’

 

#{

# «name»: «sa»,

# «password»: «1»

#}

В жизни примерно так всё и будет происходить. Кто-то, например администратор, разложит в хранилище секреты и раздаст приложениям токены, а они уже будут запрашивать данные по HTTP(S).

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

Более реалистичный пример

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

Запускаем сервер

Как говорил дружище Боромир,

Для начала нужно сводить его на ужин скормить ему конфигурацию, а в минимальном файле конфигурации хотя бы указать, где физически хранить секреты, и по какому IP и порту из выпрашивать. Хотя перманентных хранилищ для Vault хоть пруд-пруди (Consul, S3, PostgreSQL, Azure и остальные), мой vault будет хранить данные прямо в файловой системе. IP и порт же я сделаю как и в —dev режиме.

storage «file» {
path = «./secrets»
}

listener «tcp» {
address = «127.0.0.1:8200»
tls_disable = 1
}



storage «file» {

path = «./secrets»

}

 

listener «tcp» {

address = «127. 0.0.1:8200″

tls_disable = 1

}

Кстати, HashiCorp изобрела свой собственный язык для конфигурации, который вы только что увидели, и назвала его HCL (HashiCorp Configuration Language). HCL немного похож на плод неудавшейся любви JSON и YAML, но с юридической точки зрения является надмножеством JSON. В мире действительно катастрофически не хватает языков программирования и форматов, так что я рад, что HashiCorp включилась в его спасение. Следующим шагом, я надеюсь, они создадут свой текстовый редактор и какой-нибудь JavaScript-овый фреймуорк. Клон Ангуляра, например.

Но я отвлёкся. Запустим-ка сервер и двинемся дальше:

vault server -config config.hcl



vault server -config config.hcl

Распечатываем хранилище

Идея с распечатыванием просто прекрасна. По-умолчанию vault всегда запечатан (sealed). Как сейф в банке. Все секреты лежат в зашифрованном хранилище (у нас — с файле), и даже vault не знает, что с ними делать. Но есть ещё одно состояние — распечатанное (unsealed). В нём vault получает ключ для расшифровки, загружает секреты себе в память, и готовится общаться со шпионами. То, как происходит процесс распечатывания, впечатляет меня до сих пор.

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

Вот, как это выглядит. Сейчас я инициализирую хранилище, разобью мастер-ключ на 3 части, и как минимум две из них потребуются назад, чтобы восстановить ключ и хранилище распечатать:

vault init -key-shares 3 -key-threshold 2
#. ..
#Unseal Key 1: tQatbtCzOeX5f2mL4Mbd30drim5/CdIOODdBlZ0TxLQ/
#Unseal Key 2: cHCFu9rvz6vwk9jH6dtg+7Ct0EvjN02FRFCPI/dFVFlO
#Unseal Key 3: r3jt+sDaW1UYg1psAQcHdoOAGmEEPlikVmHt+YRqVu4e
#Initial Root Token: 5565017e-4b50-bb5f-073e-3def713ba4f1
#…



vault init -key-shares 3  -key-threshold 2

#…

#Unseal Key 1: tQatbtCzOeX5f2mL4Mbd30drim5/CdIOODdBlZ0TxLQ/

#Unseal Key 2: cHCFu9rvz6vwk9jH6dtg+7Ct0EvjN02FRFCPI/dFVFlO

#Unseal Key 3: r3jt+sDaW1UYg1psAQcHdoOAGmEEPlikVmHt+YRqVu4e

#Initial Root Token: 5565017e-4b50-bb5f-073e-3def713ba4f1

#…

Теперь, имея на руках три ключа, мне нужно вызвать vault unseal хотя бы два раза (с разными ключами, есс-на):

vault unseal
#Key (will be hidden):
#Sealed: true
#Key Shares: 3
#Key Threshold: 2
#Unseal Progress: 1
#Unseal Nonce: 4fd58cbe-222a-2b05-57f3-5b3736676540

vault unseal
#. ..



vault unseal

#Key (will be hidden):

#Sealed: true

#Key Shares: 3

#Key Threshold: 2

#Unseal Progress: 1

#Unseal Nonce: 4fd58cbe-222a-2b05-57f3-5b3736676540

 

vault unseal

#…

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

Аутентификация

Разумеется, без паспорта секреты нам никто не покажет. Роль идентификатора в vault играют токены, и как минимум один у нас уже есть — для root (сгенерирован во время vault init). Попробуем представиться.

vault auth 18924580-71bd-f5e0-a218-50bfada86741
#Successfully authenticated! You are now logged in.



vault auth 18924580-71bd-f5e0-a218-50bfada86741

#Successfully authenticated! You are now logged in.

vault нас узнал, так что можно добавить ему важных секретов (потом пригодятся).

vault write secret/db-production login=»1″ password=»1″
vault write secret/db-staging login=»dev» password=»pass»



vault write secret/db-production login=»1″ password=»1″

vault write secret/db-staging login=»dev» password=»pass»

Создаём полиси и новый токен

Использовать root токен в vault — точно такой же плохой тон, как и логиниться под root в Убунту. Но вот какая проблема: если создать не-root токен будучи рутом (других-то ведь нет ещё), мы сделаем дочерний токен, который унаследует все права батюшки и.. тоже станет рутом. Генетика-с. Чтобы этого избежать, потомству вместе с генами нужно передать полиси с ограниченными правами.

Полиси — это ещё один HCL файл, который просто указывает, из каких ключей можно читать, в какие ключи можно записывать, а от каких стоит держаться подальше. Если бы я хотел дать чайлдовому токену право на чтение из secret/db-staging и запретить трогать всё остальное, то сотворил бы что-нибудь вроде такого:

path «secret/db-staging» {
capabilities = [«read»]
}



path «secret/db-staging» {

  capabilities = [«read»]

}

Сохраняем шедевр в файл dev-policy.hcl, скармливаем в vault через vault policy-write development dev-policy.hcl, и можно приступать к созданию нового, ограниченного во всех смыслах токена:

vault token-create -policy development
#Key Value
#— ——
#token 77ab8047-34e2-34ac-1245-ce98c00d9c12
#…
#token_policies [default development]



vault token-create -policy development

#Key             Value

#—             ——

#token           77ab8047-34e2-34ac-1245-ce98c00d9c12

#. ..

#token_policies [default development]

Токен готов, и проверить, что он ограничен в правах, проще простого:

vault auth 77ab8047-34e2-34ac-1245-ce98c00d9c12

vault read secret/db-staging
#Key Value
#…
#login dev
#password pass

vault read secret/db-production
#Error reading secret/db-production: Error making API request.
#…
#* permission denied



vault auth 77ab8047-34e2-34ac-1245-ce98c00d9c12

 

vault read secret/db-staging

#Key             Value

#…

#login           dev

#password           pass

 

vault read secret/db-production

#Error reading secret/db-production: Error making API request.

#…

#* permission denied

Используем кастомный провайдер секретов (secret backend)

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

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

Раз уж мы начали с примера про базы данных и их пароли, то можно подключить встроенный бэкэнд секретов под названием database и начать генерировать логины-пароли к, например, MySQL базе на лету. Чтобы совсем весело было, пусть сгенерированные аккаунты будут иметь право только на чтение. Обзовём их ролью viewer, и будет нам счастье.

Но прежде, чем счастье произойдёт, надо переключиться обратно на root токен.

vault auth 18924580-71bd-f5e0-a218-50bfada86741



vault auth 18924580-71bd-f5e0-a218-50bfada86741

Теперь примонтируем database:

vault mount database
# Successfully mounted ‘database’ at ‘database’!



vault mount database

# Successfully mounted ‘database’ at ‘database’!

А вот теперь нам нужен какой-нибудь MySQL для экспериментов. Так как у меня на машине есть Docker,  то заполучить рабочий MySQL сервер можно за считанные секунды:

docker run —rm -d \
-p3306:3306 \
-e MYSQL_ROOT_PASSWORD=rootpwd \
mysql



docker run —rm -d \

-p3306:3306 \

-e MYSQL_ROOT_PASSWORD=rootpwd \

mysql

Эта команда так же откроет порт
3306 и задаст рутовый MySQL пароль — 
rootpwd. И то, и другое нам потребуется для дружбы с vault.

Теперь можно настроить database провайдера и рассказать ему, как создавать viewer аккаунты:

vault write database/config/mysql \
plugin_name=mysql-database-plugin \
connection_url=»root:[email protected](127.0.0.1:3306)/» \
allowed_roles=viewer

vault write database/roles/viewer \
db_name=mysql \
creation_statements=»CREATE USER ‘{{name}}’@’%’ IDENTIFIED BY ‘{{password}}’;GRANT SELECT ON *. * TO ‘{{name}}’@’%’;»



vault write database/config/mysql \

  plugin_name=mysql-database-plugin \

  connection_url=»root:[email protected](127.0.0.1:3306)/» \

  allowed_roles=viewer

 

vault write database/roles/viewer \

  db_name=mysql \

  creation_statements=»CREATE USER ‘{{name}}’@’%’ IDENTIFIED BY ‘{{password}}’;GRANT SELECT ON *.* TO ‘{{name}}’@’%’;»

По сути обращение к vault за логином и паролем сводится к CREATE USER запросу, в котором явно прописано, что кроме “SELECT” viewer роль уметь ничего не должна. Можно было бы ещё указать, через сколько времени этот аккаунт самоуничтожится, но vault и так поставит какой-нибудь ограничитель.

Ну что, попробуем запросить пароль к базе:

vault read database/creds/viewer
#Key Value
#— ——
#lease_id database/creds/viewer/d9ec67ae-07c9-c6ba-ae5a-9e49f74a8c78
#lease_duration 768h0m0s
#lease_renewable true
#password A1a-9xstpvu59txsx6qw
#username v-root-viewer-pxutp8uzw7t1z53w97



vault read database/creds/viewer

#Key             Value

#—             ——

#lease_id       database/creds/viewer/d9ec67ae-07c9-c6ba-ae5a-9e49f74a8c78

#lease_duration 768h0m0s

#lease_renewable true

#password       A1a-9xstpvu59txsx6qw

#username       v-root-viewer-pxutp8uzw7t1z53w97

А теперь протестируем этот логин и пароль на самом MySQL:

mysql -u v-root-viewer-pxutp8uzw7t1z53w97 -pA1a-9xstpvu59txsx6qw
#mysql: [Warning] Using a password on the command line interface can be insecure.
#Welcome to the MySQL monitor. Commands end with ; or \g.
#Your MySQL connection id is 6
#Server version: 5.7.19 MySQL Community Server (GPL)
#
mysql >



mysql -u v-root-viewer-pxutp8uzw7t1z53w97 -pA1a-9xstpvu59txsx6qw

#mysql: [Warning] Using a password on the command line interface can be insecure.

#Welcome to the MySQL monitor.  Commands end with ; or \g.

#Your MySQL connection id is 6

#Server version: 5.7.19 MySQL Community Server (GPL)

#

mysql >

Всё работает! Ну не здорово ли? Теперь каждое приложение, каждый процесс будет получать свой собственный логин и пароль, которые нет смысла воровать (они же временные), и которые всегда можно отследить из-за вездесущего логгинга и мониторинга.

Практически заключение

К vault можно подключать и других провайдеров: для генерации секретов, аутентификации (например, AWS или github) и даже для аудита.

Чем я впечатлён до сих пор, так это как много можно узнать, просто изучив новый инструмент. Алгоритмы, концепции, идеи, пример грамотного разделения приложения на базовую логику и систему плагинов. Даже если бы сегодня был последний день, когда я использовал vault, время, потраченное на его изучение, того стоило. И день явно ведь был не последний. В общем, я доволен.

Поделиться ссылкой:

Что такое App Vault на Xiaomi и как его удалить

Китайская компания Xiaomi не перестаёт удивлять постоянными обновлениями. Производитель и вправду «заморачивается», придумывая новые, более полезные программы, тем самым расширяя функционал смартфона. Обновление прошивки MIUI принесло приложение, мимо которого нельзя пройти – App Vault. Разработчики говорят о том, что подобный софт облегчит жизнь юзерам. Давайте разберёмся в этом вопросе более детально.

Что такое App Vault

App Vault (также его называют Mi помощник) – это особая папка, где отображаются некоторые системные виджеты и программы, наиболее нужные пользователю. Это так называемый «второй рабочий стол», куда можно перенести важный софт.

Взяв во внимание модель телефона и установленную прошивку, можно добавить определённый перечень интересных приложений. К примеру, мессенджеры, заметки, шагомер, быстрый поиск и т. д. В определённых версиях можно даже вызывать такси Ola. Не нужно тратить лишнее время для поиска, Mi помощник упорядочит нужный софт в необходимом порядке.

Впервые Xiaomi представила улиту App Vault в 2017 году с релизом MIUI 9. Сегодня для использования доступны более 40 сервисов в 14 категориях.

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

Программа имеет три отдельных блока, где пользователь может разместить программы в нужном порядке. К примеру, в одном блоке отмечать все особые даты и мероприятия. Во втором – добавить заметки или записи, нужные в ближайшее время (список запланированных дел, покупок и т. д). Для пользователей, следящих за физической активностью, удобно использовать шагомер в третьем блоке.

Как настроить App Vault

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

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

Основные функции и особенности

Среди главных функциональных возможностей программы стоит выделить:

  1. Возможность создавать быстрые заметки: не нужно тратить время для поиска очередного блокнота, достаточно отметить информацию, и она всегда будет у вас перед глазами.
  2. Запуск приложений за считанные секунды.
  3. Возможность кастомизировать виджеты, опираясь на предпочтения пользователя: самостоятельно определяете необходимые приложения (мессенджеры, заметки и т. д.), имея возможность запустить их без лишней траты времени.
  4. Помощник не даст забыть о важных делах и событиях: достаточно открыть функцию «Мероприятия», выбрать дату события, расположение или другую необходимую информацию.
  5. Улита абсолютно бесплатная для всех устройств от Xiaomi, имеющих программное обеспечение MIUI.

Как отключить App Vault

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

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

Если вы хотите удалить App Vault, вынуждены вас огорчить: поскольку это системная утилита, избавиться от неё невозможно.

В версиях MIUI 9 и 10 при попытке отключить программу, переключая ползунок на «Выкл.» в меню «Настройки», ничего не происходит.

Имея девелоперскую прошивку можно попробовать отключить софт следующим образом: зайдите в «Настройки», найдите «Рабочий стол…» и кликните «Выключить ленту виджетов». Но удаление невозможно ни в одном из вариантов.

Mi-помощник – это попытка Xiaomi сделать что-то схожее с голосовым помощником Google. Сказать однозначно, нужен ли App Vault, нельзя. Каждый пользователь лично для себя должен определить важность софта. Кому-то удобно и быстро, другим, наоборот — проще зайти в меню и полистать календарь или написать заметки. Удалось ли Сяоми сделать полезное приложение? Делитесь своим мнением в комментариях.

Как не хранить секреты где придётся, или зачем нам Hashicorp Vault / Хабр

 

Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В репозитории приложения? В системе деплоя (Jenkins, Teamcity, etc)? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов?

Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры.

Начнём исследование вопроса с определения требований к хранению секретов.

Требования к способу хранения секретов инфраструктуры:

  • Тонкая настройка правил доступа к секретам. Даём доступы только к тем секретам, которые необходимы и достаточны для выполнения работ.
  • Управление жизненным циклом доступов. Возможность выдавать, отзывать, устанавливать срок жизни и перевыпускать или продлять доступы.
  • Аудит доступа к секретам. Каждый акт доступа записан и будет проверен третьей стороной.
  • Минимальный периметр атаки. Чем меньше «размазанность» по системе, тем лучше.
  • Отказоустойчивость. Отсутствие единой точки отказа.
  • Удобная работа с секретами для людей и автоматических систем. Минимум времени на обучение и внедрение новых инструментов.

Примерим наши требования к возможным решениям:

  • Хранение в репозитории (любом):
    • Нет гибкой настройки доступов к секретам. Доступ бинарен — либо есть, либо нет. Есть решения этой проблемы: для файлов используют gpg. Для систем управления конфигурациями используют Ansible vault, Puppet gpg-hiera, Chef encrypted data bags и так далее. Проблемы начинаются там, где появляется автоматизация. Злоумышленник, получивший доступ на сервер, где хранятся ключи для расшифровки (мастер-сервер для Puppet\Chef, хост для автоматического запуска плейбуков Ansible, хост для автоматических запусков задач, которым нужны шифрованные данные из репозитория), получает доступ к секретам.
    • Нет поддержки полного жизненного цикла доступа. Вы не можете дать временный доступ. Вы не можете отозвать доступ к секретам (можете только сменить доступы к репозиторию и сами секреты в нём). Отсутствие регулярного процесса обновления доступов уменьшает прозрачность.
    • Нет аудита.
    • Непредсказуемая «размазанность» по системе. Каждое появление этого репозитория в инфраструктуре добавляет вам точек атаки. Будь то Jenkins, разные chef\puppet-сервера для prod/dev/test/uat окружений или необходимость запускать по крону с одного сервера маленький скриптик, который хранится в этом репозитории — вы получаете риски в обмен на ‘удобство’ и возможность не думать о безопасности.
  • Хранение в системе деплоя:
    • Нет гибкой настройки доступов к секретам. Человек, обладающий доступом к системе деплоя, может использовать секреты в своей задаче — и таким образом получить к ним доступ. Если вы используете Jenkins, то секреты можно вытащить на уровне сервера.
    • Нет поддержки полного жизненного цикла доступа.
  • Ручное подкладывание секретов на сервера:
    • Нет поддержки полного жизненного цикла доступа.
    • Нет аудита. Вы не знаете, кто и когда получил доступ к секретам.
    • Нет отказоустойчивости. Если секрет хранится только на одном сервере — потеря сервера грозит потерей секрета.
    • Нет удобства работы. Но этот способ можно использовать, когда у вас немного серверов и сервисов. С ростом инфраструктуры вас ждёт удорожание обслуживания процесса управления секретами.

Почему Vault?

Vault — хранилище секретов от признанных «решателей» проблем современной инфраструктуры — Hashicorp, авторов Vagrant, Consul, Terraform, Otto, etc. Секреты хранятся в key-value виде. Доступ к хранилищу осуществляется исключительно через API.

Основные фичи Vault:

  • Все данные хранятся в зашифрованном контейнере. Получение самого контейнера не раскрывает данные.
  • Гибкие политики доступа. Вы можете создать столько токенов для доступа и управления секретами, сколько вам нужно. И дать им те разрешения, которые необходимы и достаточны для выполнения работ.
  • Возможность аудирования доступа к секретам. Каждый запрос к Vault будет записан в лог для последующего аудита.
  • Поддерживается автоматическая генерация секретов для нескольких популярных баз данных (postgresql, mysql, mssql, cassandra), для rabbitmq, ssh и для aws.
  • Поддержка шифрования-дешифрования данных без их сохранения. Это может быть удобно для передачи данных в зашифрованном виде по незащищённым каналам связи.
  • Поддержка полного жизненного цикла секрета: создание/отзыв/завершение срока хранения/продление.
  • Уберфича, значимость которой сложно переоценить, это возможность создания собственного CA (Certificate Authority) для управления самоподписанными сертификатами внутри своей инфраструктуры.
  • Бэкенд /cubbyhole, который позволяет создать собственное хранилище секретов, не доступное даже другим root-токенам.
  • Готовые модули и плагины для популярных систем управления конфигурацией.

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

Начало работы

Не буду переводить официальную документацию, поэтому вот несколько ссылок:

  • Getting started можно пройти вот тут.
  • Тут интерактивная обучалка.
  • Вот ещё одна прекрасная статья.

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

  1. Для каждого сервиса создаём отдельный мастер-токен. Этот токен умеет управлять секретами в контейнере /secret/service_name/ и умеет создавать другие токены.
  2. Переключаемся на этот токен и создаём секрет.
  3. Выпускаем новый токен для чтения этого секрета.
  4. Скармливаем этот токен нашей системе автоматизации
  5. PROFIT!!!

    Дальше начинаются нюансы. Разберу их подробнее.

О мастер-токене для каждого сервиса

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

Из-за особенности управления политиками доступа (подробнее ниже) выросли накладные расходы на первичное внедрение Vault в рабочий процесс сервиса.

Про особенности управления политиками доступа

Они описываются в формате JSON или HCL и записываются в Vault с помощью запроса к API или через cli. Например, так:

$ vault policy-write policy_name policy_file. hcl

Чтобы созданный вами мастер-токен мог создавать новые токены, он должен иметь политику:

path "auth/token/create" {
  policy = "write"
}

Мастер-токен может создавать токены только с теми политиками, которыми он обладает.

Это означает, что вам недостаточно выдать токену политику service_name_prod_root:

path "secret/service_name/prod/*" {  
  policy = "write"  
}

которая обладает полным доступом к secret/service_name/prod/*, но также нужно озаботиться, политикой service_name_prod_read:

path "secret/service_name/prod/*" {  
  policy = "read"  
}

и тогда вы сможете создавать токены для read-only доступа с помощью команды:

$ vault token-create -policy=service_name_prod_read

И тут есть нюанс: политики применяются по степени детализации. Это означает, что если вы сделаете root политику вида:

path "secret/service_name/prod/*" {  
  policy = "write"  
}

и захотите дать доступ на чтение политике service_name_prod_database_read:

path "secret/service_name/prod/database/*" {  
  policy = "read"  
}

то вам нужно будет назначить токену, управляющему этим сервисом обе этих политики. Когда вы это сделаете, вы не сможете писать в secret/service_name/prod/database/*:

$ vault write secret/service_name/prod/database/replicas \
secret_key=sha1blabla
Error writing data to secret/service_name/prod/database/replicas: Error making API request.

URL: PUT https://vault.service.consul:8200/v1/secret/service_name/prod/database/replicas
Code: 400. Errors:

* permission denied

Вам придётся уравновесить каждую детализированную политику на чтение, чтобы этого не случилось. Например, видоизменить политику service_name_prod_root:

path "secret/service_name/prod/*" {  
  policy = "write"  
}

path "secret/service_name/prod/database/*" {  
  policy = "write"  
}

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

Об учёте и обновлении токенов

В документации к Vault зря не сказано о важности учёта выпущенных токенов.

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

У root-токенов нет срока жизни, поэтому они будут оставаться в вашей системе бесконечно. Чтобы избежать этой ситуации, для создания нового токена в целях тестирования и проверки, укажите прекрасный флаг -ttl=»1h», который устанавливает время жизни.

Это позволит спокойно работать и не бояться бесконтрольно увеличить количество токенов.

Также есть риск не уследить за истечением срока жизни токена и узнать об этом, например, во время деплоя.

Эту проблему можно решить, записывая токены и мониторя срок жизни. Но записывать токены куда-то в одно место — небезопасно. Поэтому с версии Vault 0.5.2 каждый токен после создания возвращает параметр accessor, зная который, можно взаимодействовать с токеном, не зная его самого (отзывать, обновлять, добавлять политики), например

$ vault token-revoke --accessor b30ee2a3-ea4b-9da0-3e5c-4189d375cad9

Подробности тут.

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

О параметрах токена
$ vault token-create -policy=service_name_prod_root -policy=service_name_prod_read
Key             Value
---             -----
token           82c5fb97-da1b-1d2c-cfd5-23fa1dca7c85
token_accessor  dd256e17-b9d9-172d-981b-a70422e12cb8
token_duration  2592000
token_renewable true
token_policies  [default, service_name_prod_root, service_name_prod_read ]

Пройдём по возвращённым параметрам:

token - тот самый ключ доступа к Vault.
token_accessor - ключ, по которому можно производить действия с ключом, не имея самого ключа. Разрешены следующие действия: посмотреть на метаданные токена, отозвать токен.
token_duration - время жизни токена в секундах.
token_renewable - если true, то время жизни токена может быть обновлено, но не более чем на срок от времени создания до параметра max-lease-ttl, который по умолчанию также 30d.  Это означает, что если вы создали токен со сроком жизни в 30 дней и максимальный срок жизни тоже 30 дней, то обновить вы его не сможете.
token_policies - политики, которые назначены токену. Список политик изменить невозможно, возможно только отозвать токен и пересоздать заново.

Неочевидности и полезности

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

vault token-revoke -h

Если вы будете использовать consul-template для автоматической перегенерации конфигов при изменении секретов, имейте в виду (и этого вы не найдёте в документации), что consul-template опрашивает изменение секрета в двух случаях:

  • Старт или рестарт самого consul-template.
  • Каждые (TimeToLive секрета/2) секунд после старта consul-template.

Чтобы не вводить свой рабочий токен постоянно, его можно положить в $HOME/. vault-token или в переменную окружения VAULT_TOKEN. Тут надо оговориться, что я по умолчанию считаю рабочую станцию админа защищённой (зашифрованные диски, отсутствие гостевого входа, автоблокирование через минуту неактивности). Если это не так — то стоит отказаться от этой идеи.

Наш процесс работы:

Нам не подошёл официальный процесс работы с Vault по причине излишней трудоёмкости внедрения Vault в эксплуатацию сервиса. Поделюсь нашими решениями и ответами на возникающие вопросы в процессе внедрения Vault.

  • Отказоустойчивость:

    Мы используем Consul в инфраструктуре, поэтому выбрали его как отказоустойчивый бэкенд для Vault.
  • Количество ключей для распечатки хранилища:

    Распечатывание — исключительно ручной процесс, во время которого зашифрованный контейнер с секретами помещается в память и восстанавливается мастер-ключ для расшифровки. Подробности тут. Дать возможность распечатать хранилище одному человеку — риск, потому что при компрометации этого ключа или ключей злоумышленники получат доступ к хранилищу (но пока не к секретам). Надо понимать, что если вы не наберёте необходимый минимум ключей для распечатывания хранилища, доступ к данным будет утерян. Мы решили, что нам достаточно 4 владельцев ключей и 2 ключей для расшифровки.
  • Root токены и их роль в системе:

    Официальная позиция Hashicorp — использовать эти токены только для управления политиками, ролями, настройками системы и для выдачи токенов для сервисов. Чем меньше root ключей в системе, тем меньше вероятности компрометации ключей. Но чем меньше таких ключей в системе, тем больше всё завязывается на определённых людей, которые болеют, ходят в отпуск, в общем — бывают недоступны. Мы начали с 4 root-ключей на группу из 7 человек. Это было неудобно, поэтому мы в первый раз отступили от официального процесса — выдали root-токены всем инженерам эксплуатации и перестали создавать мастер-токены для управления секретами сервиса. Все операции производятся под root-токенами. Создаются только read-only токены.
  • Схема хранения секретов:

    Для нас я выбрал следующую схему — храним секреты сервисов в /secret/service_name/env. А обще-инфраструктурные ключи (например, api-token для jenkins или реквизиты для доступа к пакетному репозиторию) храним в /secret/infra/*.
  • Именование секретов:

    $ vault write secret/service_name/prod/database \
    base=appname \
    login=appname \
    password=difficult_password

    или, например,

    $ vault write secret/service_name/prod/database/base value=appname
    $ vault write secret/service_name/prod/database/login value=appname
    $ vault write secret/service_name/prod/database/password value=difficult_password

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

  • Учёт ключей и мониторинг их времени жизни:

    По-умолчанию максимальный срок жизни НЕ root токена равен 30 дням. Мы ведём учёт accessor-ключей для токенов с помощью репозитория — и это неудобно. Зато позволило настроить мониторинг, который сообщает об истечении срока жизни ключей за 5 дней.

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

Вернёмся к хранению секрета от базы данных

Мы установили и запустили Vault, получили root-токен. Что дальше?

По последней версии процесса, принятого в моей компании, это будет выглядеть так:
Установим vault.

Укажем расположение Vault:

$ export VAULT_ADDR='https://vault.service.consul:8200'

Авторизуемся под root токеном:

$ vault auth 82c5fb97-da1b-1d2c-cfd5-23fa1dca7c85

Запишем наш секрет:

$ vault write secret/service_name/prod/database base=appname login=appname password=difficult_password

Запишем политику для чтения в файл service_name_prod_read.hcl:

path "secret/service_name/prod/database*" {  
  policy = "read"  
}

Создадим политику в Vault:

$ vault policy-write service_name_prod_read service_prod_read. hcl

Сгенерируем токен для чтения:

$ vault token-create -policy=service_name_prod_read
Key             Value
---             -----
token           cb347ae0-9eb4-85d1-c556-df43e82be4b0
token_accessor  c8996492-17e3-16a7-2af1-d58598ae10d8
token_duration  2592000
token_renewable true
token_policies  [default, service_name_prod_read ]

Запишем token_accessor для последующего аудита и мониторинга.

Проверим, что есть доступ на чтение:

$ vault auth cb347ae0-9eb4-85d1-c556-df43e82be4b0
$ vault read secret/service_name/prod/database
Key             Value
lease_duration  2592000
base            appname
login           appname
password        difficult_password

Всё работает, мы готовы использовать наш токен в системах автоматизации. Приведу примеры для популярных систем.

Просто curl:
$ curl \
    -H "X-Vault-Token:cb347ae0-9eb4-85d1-c556-df43e82be4b0" \
    https://vault.service.consul:8200/v1/secret/service_name/prod/database

Ansible (мы используем https://github.

com/jhaals/ansible-vault):

Настраиваем окружение:

$ export VAULT_ADDR=https://vault.service.consul:8200
$ export VAULT_TOKEN=cb347ae0-9eb4-85d1-c556-df43e82be4b0

Используем переменные из Vault в роли:

database_password: "{{ lookup('vault', 'secret/service_name/prod/database', 'password') }}"

Мы делаем запросы к vault только на уровне group_vars/group_name. Это удобно и позволяет не искать переменные по роли.

Chef:

Hashicorp в своём блоге описали несколько путей использования секретов из Vault в своих chef-кукбуках — https://www.hashicorp.com/blog/using-hashicorp-vault-with-chef.html

Puppet:

Для puppet существует прекрасный модуль https://github.com/jsok/hiera-vault, из документации к которому понятен процесс использования секретов из Vault.

Consul-template:

Необходимо либо иметь токен и адрес Vault в переменных окружения:

$ export VAULT_ADDR=https://vault. service.consul:8200
$ export VAULT_TOKEN=cb347ae0-9eb4-85d1-c556-df43e82be4b0

или добавить в конфиг строчки:

vault {
  address = "https://vault.service.consul:8200"
  token = "cb347ae0-9eb4-85d1-c556-df43e82be4b0"
  renew = true
}

и использовать секреты в своих шаблонах:

{{with secret "secret/service_name/prod/database"}}{{.Data.password}}{{end}}

Более подробно — в readme

Спасибо за потраченное время, надеюсь, это было полезно.

Готов ответить на ваши вопросы.

Не удается найти страницу | Autodesk Knowledge Network

(* {{l10n_strings.REQUIRED_FIELD}})

{{l10n_strings.CREATE_NEW_COLLECTION}}*

{{l10n_strings.ADD_COLLECTION_DESCRIPTION}}

{{l10n_strings.COLLECTION_DESCRIPTION}}
{{addToCollection.description. length}}/500

{{l10n_strings.TAGS}}
{{$item}}

{{l10n_strings.PRODUCTS}}

{{l10n_strings.DRAG_TEXT}}

 

{{l10n_strings.DRAG_TEXT_HELP}}

{{l10n_strings.LANGUAGE}}
{{$select.selected.display}}

{{article.content_lang.display}}

{{l10n_strings. AUTHOR}}

 

{{l10n_strings.AUTHOR_TOOLTIP_TEXT}}

{{$select.selected.display}}

{{l10n_strings.CREATE_AND_ADD_TO_COLLECTION_MODAL_BUTTON}}
{{l10n_strings.CREATE_A_COLLECTION_ERROR}}

Vault вирус шифрует файлы, ставит расширение .vault

Здравствуйте, уважаемые читатели. Довелось мне познакомиться с одним очень неприятным и опасным шифровальщиком, который шифрует пользовательские данные, заменяя им стандартное расширение. После заражения вирусом шифровальщиком vault сразу же возникает главный вопрос — как восстановить поврежденные файлы и провести расшифровку информации. К сожалению, простого решения данной задачи не существует в силу особенностей механизма работы зловреда и находчивости злоумышленников.

Описание вируса шифровальщика vault

Все начинается с того, что у вас внезапно открывается текстовый файл в блокноте следующего содержания:

Ваши рабочие документы и базы данных были заблокированы и помечены форматом .vаult
Для их восстановления необходимо получить уникальный ключ

ПРОЦЕДУРА ПОЛУЧЕНИЯ КЛЮЧА:

КРАТКО
1. Зайдите на наш веб-ресурс
2. Гарантированно получите Ваш ключ
3. Восстановите файлы в прежний вид

ДЕТАЛЬНО
Шаг 1:
Скачайте Tor браузер с официального сайта: https://www.torproject.org
Шаг 2:
Используя Tor браузер посетите сайт: http://restoredz4xpmuqr.onion
Шаг 3:
Найдите Ваш уникальный VAULT.KEY на компьютере — это Ваш ключ к личной клиент-панели. Не удалите его
Авторизируйтесь на сайте используя ключ VAULT.KEY
Перейдите в раздел FAQ и ознакомьтесь с дальнейшей процедурой
STEP 4:
После получения ключа, Вы можете восстановить файлы используя наше ПО с открытым исходным кодом или же безопасно использовать своё ПО

ДОПОЛНИТЕЛЬНО
a) Вы не сможете восстановить файлы без уникального ключа (который безопасно хранится на нашем сервере)
b) Если Вы не можете найти Ваш VAULT. KEY, поищите во временной папке TEMP
c) Ваша стоимость восстановления не окончательная, пишите в чат

Дата блокировки: 08.04.2015 (11:14)

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

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

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

В качестве шифровальщика vault выступает бесплатная утилита для шифрования gpg и популярный алгоритм шифрования — RSA-1024. Так как по своей сути эта утилита много где используется, не является вирусом сама по себе, антивирусы пропускают и не блокируют ее работу. Формируется открытый и закрытый ключ для шифрования файлов. Закрытый ключ остается на сервере хакеров, открытый на компьютере пользователя.

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

Конкретно мне попалась модификация вируса vault, которая работала только на 32 битных системах. Причем на Windows 7 с включенным UAC выскакивает запрос на ввод пароля администратора. Без ввода пароля вирус ничего сделать не сможет. На Windows XP он начинает работу сразу после открытия файла из почты, никаких вопросов не задает.

Вирус ставит расширение vault на doc, jpg, xls и других файлах

Что же конкретно делает с файлами вирус? На первый взгляд кажется, что он просто меняет расширение со стандартного на .vault. Когда я первый раз увидел работу этого virus-шифровальщика, я так и подумал, что это детская разводка. Переименовал обратно файл и очень удивился, когда он не открылся как полагается, а вместо положенного содержания открылась каша из непонятных символов. Тут я понял, то все не так просто, начал разбираться и искать информацию.

Вирус прошелся по всем популярным типам файлов — doc, docx, xls, xlsx, jpeg, pdf и другим. К стандартному имени файла прибавилось новое расширение .vault. Некоторым он шифрует и файлы с локальными базами 1С. У меня таких не было, так что сам лично я это не наблюдал. Простое переименовывание файла обратно, как вы понимаете, тут не помогает.

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

Расскажу, что скрывается за сменой расширения. После шифрования, к примеру, файла file.doc рядом с ним вирус vault создает зашифрованный файл file.doc.gpg, затем зашифрованный file. & rename «%%i» «%%~nxi.vault»>> «%temp%\cryptlist.lst»
echo %%i>> «%temp%\conf.list»
)

Как удалить вирус vault и вылечить компьютер

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

Само тело вируса находится во временной папке temp пользователя, который его запустил. Вирус состоит из следующих файлов. Названия могут меняться, но структура будет примерно такой же:

  • 3c21b8d9.cmd
  • 04fba9ba_VAULT.KEY
  • CONFIRMATION.KEY
  • fabac41c.js
  • Sdc0.bat
  • VAULT.KEY
  • VAULT.txt

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

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

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

Как восстановить и расшифровать файлы после вируса vault

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

Так что к великому сожалению, вариантов тут не очень много:

  1. Вам очень повезло, если у вас включена защита системы. Она включается для каждого диска отдельно. Если это было сделано, то вы можете воспользоваться инструментом восстановления предыдущих версий файлов и папок. Находится он в свойствах файла. Подробнее можно поискать в интернете, статей по поводу этого инструмента восстановления остаточно.
  2. Если у вас оказались зашифрованы файлы на сетевых дисках, ищите архивные копии, проверяйте, не включена ли на этих дисках корзина, там будут ваши исходные файлы. Хотя стандартно на сетевых дисках ее нет, но можно настроить отдельно. Я чаще всего это делаю, когда настраиваю сетевые шары. Вспомните, нет ли у вас архивных копий ваших локальных данных.
  3. Если у вас пострадали данные в папках, которые подключены к хранилищам данных в интернете типа Яндекс. Диск, Dropbox, Google disk, загляните к ним в корзину, там должны остаться оригинальные файлы до шифрования.
  4. Попробуйте найти файл secring.gpg. Файл этот должен быть создан на вашей машине (как правило в %TEMP% юзера) в момент запуска процесса шифрования. К сожалению, вероятность успешного поиска secring.gpg невелика, поскольку шифратор тщательно затирает данный ключ с помощью утилиты sdelete.exe:
    "%temp%\sdelete.exe" /accepteula -p 4 -q "%temp%\secring.gpg"

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

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

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

Какую цену назначат вам за расшифровку зависит от количества зашифрованных файлов и от вашего умения найти общий язык с шифраторами. С хакерами возможно живое общение в чате. Информация о ваших зашифрованных файлах хранится в CONFIRMATION.KEY, о котором я упоминал ранее. Так же для расшифровки вам понадобится VAULT.KEY. Как связаться с хакерами рассказано непосредственно в информационном сообщении, которое вы получаете после заражения. Сервер хакеров работает не круглосуточно, а примерно 12 часов в сутки. Вам придется сидеть и проверять время от времени его доступность.

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

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

Касперский, drweb и другие антивирусы в борьбе с шифровальщиком vault

А что же антивирусы нам могут предложить в борьбе с этой зашифрованной напастью? Лично я был свидетелем заражения вирусом на компьютерах с установленной и полностью обновленной лицензионной версией eset nod32. Он никак не отреагировал на запуск шифровальщика. Возможно уже сейчас что-то изменилось, но на момент моего поиска информации по данному вопросу, ни один из вирусов не гарантировал защиту пользователя от подобных угроз. Я читал форумы популярных антивирусов — Kaspersky, DrWeb и другие. Везде разводят руками — помочь с дешифровкой мы не можем, это технически невозможно.

Один раз в новостях Касперского проскочила инфа, что правоохранительные органы Голландии арестовали злоумышленников и конфисковали их сервер с закрытыми ключами шифрования. С помощью добытой информации умельцы из Kaspersky сварганили дешифратор, с помощью которого можно было восстановить зашифрованные файлы. Но, к сожалению, это были не те хакеры, с которыми столкнулся я и мне тот дешифровщик ничем не помог. Возможно, когда-нибудь и этих поймают, но достаточно велик шанс, что к этому времени зашифрованные файлы уже будут не актуальны.

Ответ Службы Технической Поддержки ЗАО «Лаборатория Касперского»:
Здравствуйте!В последнее время мы часто получаем запросы, связанные с действиями программ-шифровальщиков.
Некоторые вредоносные программы-шифровальщики используют технологии шифрования с помощью открытого ключа. Сама по себе эта технология является надежным способом защищенного обмена важными сведениями, однако злоумышленники используют её во вред. Они создают программы, которые, попав в компьютер, шифруют данные таким образом, что расшифровать их можно только имея специальный «приватный» ключ шифрования. Его злоумышленники, как правило, оставляют у себя и требуют деньги в обмен на ключ. К сожалению, в данной ситуации информацию практически невозможно расшифровать за приемлемое время, не имея «приватного» ключа шифрования.Лаборатория Касперского ведёт постоянную работу по борьбе с подобными программами. В частности, иногда, принцип шифрования, используемый злоумышленниками, удается выяснить благодаря изучению кода вредоносной программы и создать утилиту для дешифровки данных. Тем не менее, существуют образцы вредоносного ПО, анализ которых не дает подобной ценной информации.Для расшифровки файлов воспользуйтесь нашими утилитами (Rector Decryptor, RakhniDecryptor, RannohDecryptor, ScatterDecryptor или Xorist Decryptor). Каждая утилита содержит краткое описание, небольшую информацию о признаках заражения и инструкцию по работе. Пожалуйста, попробуйте выполнить расшифровку, выбрав соответствующую по описанию утилиту. Если расшифровать файлы не удалось, необходимо дождаться очередного обновления утилиты. Дата обновления для каждой утилиты указана в явном виде.
К сожалению, это всё, что можно сделать в данном случае.
Ответ Drweb:
Здравствуйте.К сожалению, в данном случае расшифровка не в наших силах.
Собственно шифрование файлов выполнено общедоступным легитимным криптографическим ПО GPG (GnuPG) Криптосхема на базе RSA-1024. Подбор ключа расшифровки, к сожалению, невозможен.
Основная рекомендация:
обратитесь с заявлением в территориальное управление «К» МВД РФ по факту несанкционированного доступа к компьютеру, распространения вредоносных программ и вымогательства. Образцы заявлений, а также ссылка на госпортал («Порядок приема сообщений о происшествии в органах внутренних дел РФ») есть на нашем сайте.
Поскольку это RSA-1024, без содействия со стороны автора/хозяина троянца — вольного или невольного (арест соотв. людей правоохранительными органами) — расшифровка не представляется практически возможной.

Методы защиты от vault вируса

Какого-то надежного и 100%-го способа защиты от подобных вирусов не существует. Можно лишь повторить стандартные рекомендации, которые актуальны для любых вирусов в интернете:

  1. Не запускайте незнакомые приложения, ни в почте, ни скачанные из интернета. Старайтесь вообще из интернета ничего не качать и не запускать. Там сейчас столько всякой гадости валяется на файлопомойках, что защититься от них без должного понимания практически невозможно. Попросите лучше компетентного знакомого вам что-то найти в интернете и отблагодарите его за это.
  2. Всегда имейте резервную копию важных данных. Причем хранить ее нужно отключенной от компьютера или сети. Храните отдельную флешку или внешний жесткий диск для архивных копий. Подключайте их раз в неделю к компьютеру, копируйте файлы, отключайте и больше не пользуйтесь. Для повседневных нужд приобретайте отдельные устройства, сейчас они очень доступны, не экономьте. В современный век информационных технологий информация — самый ценный ресурс, важнее носителей. Лучше купить лишнюю флешку, чем потерять важные данные.
  3. Повысьте меру своего понимания происходящих в компьютере процессах. Сейчас компьютеры, планшеты, ноутбуки, смартфоны настолько плотно вошли в нашу жизнь, что не уметь в них разбираться значит отставать от современного ритма жизни. Никакой антивирус и специалист не сможет защитить ваши данные, если вы сами не научитесь это делать. Уделите время, почитайте тематические статьи на тему информационной безопасности, сходите на соответствующие курсы, повысьте свою компьютерную грамотность. Это в современной жизни обязательно пригодится.

Некоторое время назад я столкнулся с еще одним вирусом шифровальщиком enigma. Написал об этом статью, посмотрите, может вам она чем-то поможет. Некоторые антивирусные компании сообщают, что могут помочь в расшифровке того вируса, если у вас есть лицензионная копия антивируса. В некоторых случаях есть вероятность, что и с вирусом vault это сработает. Можно попробовать приобрести Kaspersky, на мой взгляд это лучший антивирус на сегодняшний день. Сам им пользуюсь на домашних компьютерах и в корпоративной среде. Попробуйте приобрести лицензию, даже если с расшифровкой вируса не поможет, все равно пригодится.

На этом у меня все. Желаю вам не терять свою информацию.

Дешифратор vault на видео

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

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Рекомендую полезные материалы по схожей тематике:

  • Взлом веб сервера с помощью уязвимости Bash Shellshock.

App vault — что это на Xiaomi, нужно ли это приложение и как можно удалить

Разработчики периодически обновляют систему, что позволяет расширить функционал смартфона. С новым обновлением прошивки MIUI появилось новое приложение App Vault на девайсах от Xiaomi. Производитель считает, что новая программа облегчит жизнь пользователям, и позволит настроить быстрый доступ к необходимым виджетам.

Что такое App Vault

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

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

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

Как настроить App Vault

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

  • Войти в настройки.
  • Пролистать до пункта «Рабочий стол и недавние».
  • Нажать кнопку «Включить ленту виджетов».

Основные функции и особенности

  • Быстрый доступ к просмотру оповещений.
  • Мгновенный запуск приложений.
  • Блоки можно сортировать и менять в зависимости от предпочтений.
  • Можно распланировать личное время при помощи заметок и календаря.
  • Отображаются дни недели и текущая дата.
  • Софт совместим только со свежей версией Андроид.
  • Программа распространяется бесплатно.
  • Работа возможна только на устройства от Xiaomi с собственной программной оболочкой MIUI.

Как отключить App Vault

Некоторые пользователи считают, что программа бесполезная. В таком случае ее можно отключить? Все очень просто. Понадобится войти в настройки, и выполнить обратное действие, нажать на кнопку «Отключить ленту виджетов».

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

Заключение

Приложение App Vault для Xiaomi является вполне полезным. Благодаря этому софту пользователь не забудет о предстоящих событиях, и сможет быстро воспользоваться необходимыми функциями смартфона. Помимо размещения блоков программ, вы можете воспользоваться строкой поиска, которая располагается в самом верху.

Обзор The Vault. Безопасное хранение информации на Mac и iOS

Недавно я задался вопросом о безопасном хранении чувствительной информации на «яблочных» устройствах. Google предложил мне множество вариантов разной степени сомнительности, пока я не остановился на The Vault.

The Vault — приложение для безопасного хранения информации и файлов с возможностью синхронизации между устройствами.

Настройка

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

Для синхронизации между Mac-устройствами этого достаточно. Для синхронизации с iOS на смартфоне нужно будет включить «Vault Secure Sync».

Затем вы задаёте пароль доступа к приложению, и оно тут же запускается в трее в заблокированном состоянии.

Вместо пароля на всех устройствах можно использовать авторизацию с помощью биометрии.

Ещё одна крутая фишка приложения — защита от принудительного открытия данных. Это когда дядечка силой хочет заставить вас авторизоваться в приложении с помощью биометрии. Потрясите устройство или во время авторизации нажмите «Cancel». Теперь войти в приложение можно только с паролем.

А при нажатии кнопки питания приложение блокируется мгновенно.

Все данные в приложении защищены ключом шифрования 256-bit AES и не уходят с устройства в открытом виде.

Исходный код системы шифрования The Vault находится в открытом доступе, и вы сами можете убедиться в его надёжности по этой ссылке.

Работа с данными

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

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

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

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

Папки с заметками можно скрыть в системе, и догадаться об их существовании будет невозможно. Автоскрытие происходит сразу же при блокировке или выходе из The Vault.

Что можно хранить

The Vault в первую очередь нужен для безопасного хранения текстовой информации. Но в пустую заметку можно перенести любой файл, и он будет добавлен.

Нативно The Vault поддерживает хранение изображений с возможностью импорта их из других приложений. Для удобного просмотра изображений есть своя галерея.

Для текстовых документов поддерживается встроенный сканер. Можно сфотографировать визитку, и распознать её прямо в приложении. Файлы форматов Word, PowerPoint, Excel, Pages, KeyNote, Numbers можно просматривать в The Vault без установки дополнительных утилит.

Также в теле заметки есть так называемый HotContent. С помощью этой настройки можно автоматически скрывать чувствительные данные в тексте. Например, пароли, данные кредитных карт и тому подобное.

При тапе или клике на такой контент он будет скопирован в защищённый буфер обмена и доступен для вставки. Для ещё большей безопасности можно воспользоваться встроенным браузером.

На iOS поддерживается функция AutoFill, что позволяет использовать The Vault как полноценный менеджер паролей. Для корректной работы рекомендуется использовать соответствующий шаблон заметки.

Чтобы создать такой контент, не нужно ничего делать. Просто пишите «Password: ваш пароль», и приложение автоматически скроет нужные данные.

Заметки можно линковать друг с другом для более удобной навигации.

Мобильная версия The Vault по возможностям ничем не отличается от десктопной.

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

Для данных в приложении поддерживается автоматический бэкап. Удалённые данные можно восстановить частично или полностью в любой момент.

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

В самом приложении есть генератор паролей с настраиваемыми параметрами будущего пароля.

Заметки в The Vault можно импортировать и экспортировать. В обоих случаях данные содержатся в .csv файле, кроме вложений. При экспорте они будут доступы в виде обычных файлов.

Настройки

В The Vault можно тонко настроить практически каждый параметр приложения. Среди настроек есть параметры вёрстки заметок, параметры папок, статистика сохранённых данных и параметры внешнего вида приложения.

Цены

Мобильная версия The Vault доступна бесплатно. При этом за каждую функцию придётся платить отдельно по мере их использования. Стоимость: от $1 до $9.

Десктопная версия обойдётся в $25, и вам будут доступны все возможности.


The Vault недешёвое приложение, но из доступных аналогов оно мне показалось наиболее подходящим для безопасного хранения данных. Аналоги выглядят как поделки, и не понятно, насколько защищена информация.

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

Если не считать цены, единственный минус — всё та же система заметок. Для удобной работы с ними придётся ознакомиться с обучением в приложении и привыкнуть работать с текстом.

Скачать The Vault

Введение | Vault от HashiCorp

Добро пожаловать в вводное руководство по HashiCorp Vault! Это руководство — лучшее
место, чтобы начать работу с Vault. В этом руководстве рассказывается, что такое Vault, с какими проблемами
он может решить, как он сравнивается с существующим программным обеспечением, и содержит быстрый старт
для использования Vault.

Если вы уже знакомы с основами Vault,
документация предоставляет лучшее справочное руководство для всех
доступные функции, а также внутренние компоненты.

»Что такое Vault?

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

Современная система требует доступа к множеству секретов: учетным данным базы данных,
Ключи API для внешних сервисов, учетные данные для сервис-ориентированной архитектуры
общение и т. д. Понимание того, кто к каким секретам имеет доступ, уже очень
сложный и зависящий от платформы.Добавление ключей, безопасное хранение и
подробные журналы аудита практически невозможны без специального решения. Это
где появляется Vault.

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

Ключевые особенности Vault:

  • Безопасное хранилище секретов : можно хранить произвольные секреты ключей / значений
    в Убежище. Vault шифрует эти секреты перед записью в постоянный
    хранилище, поэтому доступа к необработанному хранилищу недостаточно для доступа
    твои секреты.Хранилище может записывать на диск, Консул,
    и больше.

  • Dynamic Secrets : Vault может генерировать секреты по запросу для некоторых
    системы, такие как базы данных AWS или SQL. Например, когда приложение
    требуется доступ к корзине S3, он запрашивает учетные данные Vault, а Vault
    по запросу сгенерирует пару ключей AWS с действующими разрешениями. После
    создавая эти динамические секреты, Vault также автоматически аннулирует их
    после истечения срока аренды.

  • Шифрование данных : Vault может шифровать и расшифровывать данные без сохранения
    Это.Это позволяет службам безопасности определять параметры шифрования и
    разработчикам хранить зашифрованные данные в таком месте, как SQL, без
    приходится разрабатывать свои собственные методы шифрования.

  • Аренда и продление : Все секреты в Vault связаны с арендой
    с ними. По окончании срока аренды Сейф автоматически аннулирует это
    секрет. Клиенты могут продлевать аренду с помощью встроенных API продления.

  • Отзыв : Vault имеет встроенную поддержку секретного отзыва.Свод
    может отозвать не только отдельные секреты, но и целое дерево секретов, например
    все секреты, прочитанные определенным пользователем, или все секреты определенного типа.
    Отзыв помогает в смене ключей, а также в блокировке систем в
    случай вторжения.

»Следующие шаги

См. Страницу с вариантами использования Vault, чтобы увидеть несколько способов
Хранилище можно использовать. Затем продолжайте с самого начала
руководство по использованию Vault
читать, писать, создавать настоящие секреты и видеть, как это работает на практике.

Безопасное использование секретов: шаблон для использования HashiCorp Vault

Согласно недавнему исследованию исследователей из Университета штата Северная Каролина, более 100 000 общедоступных репозиториев GitHub содержат открытые секреты приложений непосредственно в исходном коде. Это исследование — от частных токенов API до криптографических ключей — просканировало только около 13% общедоступных репозиториев GitHub — показывает, что надлежащая защита секретов приложений является одним из наиболее часто игнорируемых методов защиты информации в программном обеспечении.

Хотя масштабы воздействия удивительны, важно отметить, что эта проблема затрагивает не только проекты с открытым исходным кодом. Даже частные репозитории исходного кода могут раскрывать секреты, если они не защищены должным образом. Возьмем, к примеру, нарушение безопасности в Buffer Inc. в 2013 году. То, что начиналось как незаконный доступ к собственному исходному коду Buffer, привело к утечке учетных данных Twitter API компании, что в конечном итоге привело к рассылке спама в учетных записях Twitter бесчисленных клиентов.

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

Войдите в HashiCorp Vault

Я большой поклонник HashiCorp. Их подход к инструментарию DevOps, не зависящему от поставщика, обеспечивает отличные портативные решения, которые абстрагируются от отдельных поставщиков облачных вычислений и фокусируются на решении реальных проблем .Их инструмент управления секретами, Vault, не исключение.

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

Установка Vault

Загрузить Vault — Vault от HashiCorp

Прежде чем мы сможем начать работу с Vault, нам сначала нужно его установить.Как и все продукты HashiCorp, Vault впечатляюще кроссплатформенный, с поддержкой macOS, Windows, Linux, Solaris и даже BSD. Черт, вы даже можете запустить его на Raspberry Pi.

Запуск сервера

После установки Vault нам нужно запустить наш сервер. В этой статье я буду работать только с сервером разработки Vault. Однако важно отметить, что сервер разработки невероятно небезопасен, и хранит все данные в памяти , а это означает, что при его перезапуске все будет потеряно.По словам самих HashiCorp:

«Сервер разработки должен использоваться для экспериментов с функциями Vault, такими как различные методы аутентификации, механизмы секретов, устройства аудита и т. Д.»

Чтобы запустить сервер разработки, просто запустите команду vault server -dev ( -dev указывает, что мы должны запускать сервер разработки, а не производственный сервер):

  $ vault server -dev
==> Конфигурация сервера Vault:

     Адрес API: http: // 127.0.0.1: 8200
             Cgo: отключено
 Адрес кластера: https://127. 0.0.1:8201
      Слушатель 1: tcp (адрес: «127.0.0.1:8200», адрес кластера: «127.0.0.1:8201», max_request_duration: «1m30s», max_request_size: «33554432», tls: «disabled»)
       Уровень журнала: информация
           Mlock: поддерживается: false, включено: false
         Хранение: inmem
         Версия: Vault v1.2.1

ПРЕДУПРЕЖДЕНИЕ! режим разработчика включен! В этом режиме Vault работает полностью в памяти.
и начинается вскрытие одним ключом. Корневой токен уже
аутентифицированы в интерфейсе командной строки, поэтому вы можете сразу начать использовать Vault.Возможно, вам потребуется установить следующую переменную среды:

    $ export VAULT_ADDR = 'http: //127.0.0.1: 8200'

Ключ распечатки и корневой токен отображаются ниже на случай, если вы хотите запечатать / распечатать Хранилище или повторно пройти аутентификацию.

Ключ распечатки: p8MumXfy57bh3T1FxdvZSmHhxqr7aQAByPpfE4PLujk =
Корневой токен: s.aSQmpEYEi5MKelf5TDLPC6r9

Режим разработки НЕ следует использовать в производственных установках!

==> Сервер хранилища запущен! Данные журнала будут передаваться ниже:
  

Как видите, на экран выводится много данных, с которыми вы можете поиграть. Прежде всего следует отметить, что сервер разработки по умолчанию не запускается как демон (и для целей тестирования никогда не должен запускаться как демон). Следовательно, если вы хотите взаимодействовать с сервером, вы должны сначала открыть второе окно терминала и экспортировать предоставленную переменную среды VAULT_ADDR , чтобы команда vault знала, с каким сервером она должна взаимодействовать.

Значения Unseal Key и Root Token также важны.Хотя мы коснемся того, что делать с корневым токеном в следующем разделе, понимание запечатывания / распечатывания Vault имеет решающее значение для правильного развертывания Vault в производственной среде.

Расшифровка и аутентификация

В производственной среде сервер Vault запускается в состоянии запечатано . Это означает, что Vault знает, где находятся данные, но не знает , как их расшифровать. На сервере разработки хранилище по умолчанию — незапечатанное . Однако, если вы решите запечатать его, вам будет предоставлен ключ Unseal Key , который поможет распечатать его. Незапечатанное хранилище остается в этом состоянии до тех пор, пока оно не будет повторно запечатано или сам сервер не будет перезапущен.

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

  $ vault operator init

Распечатать ключ 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq / JgOm
Распечатать ключ 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiS
Распечатать ключ 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chA
Распечатать ключ 4: 0cZE0C / gEk3YHaKjIWxhyyfs8REhqkRW / CSXTnmTilv +
Распечатать ключ 5: fYhZOseRgzxmJCmIqUdxEm9C3jB5Q27AowER9w4FC2Ck

Начальный корневой токен: s.KkNJYWF5g0pomcCLEmDdOVCW

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

Vault не хранит сгенерированный мастер-ключ. Без как минимум 3-х ключей для восстановления главного ключа Хранилище останется навсегда запечатанным!

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

Вход в систему

Когда сервер работает, следующее, что нам нужно сделать, это войти в него. Это можно сделать с помощью команды vault login , которая запросит токен аутентификации. При первоначальной настройке вы можете пройти аутентификацию с помощью корневого токена (см. Выше). Однако в производственной среде базовые методы аутентификации можно изменить, чтобы обеспечить более детальный контроль над тем, кто имеет доступ и почему:

  $ вход в хранилище
Токен (будет скрыт):
Успех! Теперь вы аутентифицированы. Информация о токене, отображаемая ниже, уже хранится в помощнике по токенам. Вам НЕ нужно снова запускать «вход в хранилище». Будущие запросы Vault будут автоматически использовать этот токен.

Ключевое значение
--- -----
токен s.aSQmpEYEi5MKelf5TDLPC6r9
token_accessor MaJhao2R54EdV9fDq7sL11d4
token_duration ∞
token_renewable ложь
token_policies ["корень"]
identity_policies []
политики ["корень"]
  

Хранение секретов

Хотя HashiCorp’s Vault можно использовать для безопасного хранения практически любых данных, наиболее распространенный вариант использования Vault — это хранилище ключей и значений для секретов приложений.После аутентификации хранение секретов составляет невероятно просто благодаря vault команде kv put :

  $ vault kv put secret / foo bar = baz
Ключевое значение
--- -----
created_time 2019-08-09T16: 43: 10.604124Z
Deletion_time нет данных
уничтожен ложный
версия 1
  

Чтобы немного разбить приведенную выше команду и ответ, мы создали новый секрет с именем foo в пространстве имен secret со значением bar = baz. , ответ дает нам некоторые базовые метаданные о нашем новом секрете. Хотя ключи created_time , deletion_time и destroy не требуют пояснений, вам следует обратить особое внимание на ключ версии , поскольку он подразумевает, что для секретов можно управлять версиями.

Например, давайте посмотрим, что произойдет, если мы поместим новое значение для того же секрета:

  $ vault kv put secret / foo bat = ball
Ключевое значение
--- -----
created_time 2019-08-09T16: 43: 32.638788Z
Deletion_time нет данных
уничтожен ложный
версия 2
  

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

Рассказывать секреты

Теперь хранить секреты — это только половина дела. Другая половина на самом деле извлекает эти секреты. В нашем примере выше давайте сначала посмотрим, как получить весь наш список секретов:

  $ vault kv list secret
Ключи
----
фу
  

Как видите, в то время как мы технически помещаем два секрета, отслеживается только один ключ, потому что эти два секрета на самом деле являются лишь двумя версиями одного секрета.Чтобы получить его, выполните команду vault kv get с секретным пространством имен и ключом:

  $ vault kv get secret / foo
====== Метаданные ======
Ключевое значение
--- -----
created_time 2019-08-09T16: 43: 32.638788Z
Deletion_time нет данных
уничтожен ложный
версия 2

=== Данные ===
Ключевое значение
--- -----
мяч летучая мышь
  

По умолчанию Vault будет извлекать последних версий секрета, но если мы хотим получить предыдущую версию , можно использовать директиву -version :

  $ vault kv get -version = 1 секрет / foo
====== Метаданные ======
Ключевое значение
--- -----
created_time 2019-08-09T16: 43: 10. 604124Z
Deletion_time нет данных
уничтожен ложный
версия 1

=== Данные ===
Ключевое значение
--- -----
бар баз
  

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

Забыть секреты

Теперь, несмотря на преимущества контроля версий, может быстро стать необходимым фактическое удаление секрета (или его версии).Это можно сделать двумя способами, в зависимости от того, насколько «удален» секрет: удалить и удалить . Для иллюстрации давайте сначала рассмотрим удаление версии нашего foo secret:

  $ vault kv delete -versions = 1 secret / foo
Успех! Данные удалены (если они существовали) по адресу: secret / foo
  

Это помечает данные как удалено и предотвращает их извлечение в обычных запросах GET, но на самом деле не удаляет данные:

  $ vault kv get -version = 1 secret / foo
====== Метаданные ======
Ключевое значение
--- -----
created_time 2019-08-09T16: 43: 10. 604124Z
deletion_time 2019-08-09T16: 45: 39.664577Z
уничтожен ложный
версия 1
  

Для фактического удаления данных без возможности восстановления необходимо использовать команду destroy :

  $ vault kv destroy -versions = 1 secret / foo
Успех! Данные, записанные в: secret / destroy / foo
  

Вместо того, чтобы просто пометить данные как удаленные и ограничить доступ к ним, команда destroy удалит их полностью, что сделает последующее извлечение невозможным:

  $ vault kv get -version = 1 secret / foo
====== Метаданные ======
Ключевое значение
--- -----
created_time 2019-08-09T16: 43: 10.604124Z
deletion_time 2019-08-09T16: 45: 39.664577Z
уничтожено правда
версия 1
  

Углубиться в HashiCorp Vault

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

Секретные механизмы

  $ секреты хранилища включить базу данных
Успех! Включен механизм секретов базы данных по адресу: database /
  

Хранилище ключей и значений по умолчанию в Vault является примером механизма секретов (в частности, механизма под названием кв ).По своей сути алгоритм секретов — это абстрактный механизм хранения секретных данных. Это означает, что вместо механизма хранения на основе ключа-значения можно использовать более целевые механизмы хранения. Например, механизм секретов базы данных может использоваться для динамической генерации учетных данных базы данных на основе настроенных ролей для MySQL и MariaDB, что позволяет автоматизировать ротацию учетных данных root или даже временные учетные данные для доступа по запросу.

Методы аутентификации

  $ vault auth enable github
Успех! Включен метод аутентификации github по адресу: github /
  

В дополнение к стандартному методу аутентификации на основе токенов, Vault поддерживает ряд дополнительных методов аутентификации для лучшей поддержки ваших вариантов использования. Отличным примером этого является метод проверки подлинности GitHub, который можно использовать для автоматического предоставления доступа к Vault разработчикам, принадлежащим к определенной организации GitHub — и даже к определенной группе внутри организации GitHub — с использованием только токена личного доступа. Для более крупных организаций решения единого входа на уровне предприятия, такие как LDAP или Okta, могут использоваться для аутентификации пользователей в Vault.

Авторизация

  $ vault write auth / userpass / users / test policy = "dev-readonly, logs"
  

Авторизация всегда идет рука об руку с аутентификацией.Хотя предоставить глобальный доступ с помощью GitHub или аутентификации на основе токенов несложно, это почти никогда не бывает полным решением. Благодаря политикам Vault может быть реализован метод авторизации в стиле RBAC, предоставляющий разным пользователям и группам CRUD-подобный доступ к различным аспектам самого хранилища. В сочетании с одним из более продвинутых методов аутентификации это может стать невероятно мощным инструментом для детального контроля доступа в большой организации.

Beyond Vault

Каким бы мощным ни было Vault, сделать его правильно может быть сложно.Хотя размер и объем различных методов аутентификации и механизмов секретов ясно показывают, насколько много вы можете сделать с Vault, может быть сложно осмыслить основы управления секретами в контексте информационной безопасности исходного кода. Благодаря впечатляюще большому количеству как официальных, так и общественных библиотек API, получение секретов безопасным способом невероятно просто, и если вы стремитесь стать опытным пользователем Vault, собственная учебная программа Vault Vault от HashiCorp — это отличное место для начала .

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


Об авторе

Захари Флауэр (@zachflower) — участник Fixate IO, главный инженер Automox — компании по управлению исправлениями в Боулдере — и писатель-фрилансер.Обладая страстью к простоте и удобству использования в конвейере разработки, Зак уделяет особое внимание важности документации, производительности разработчиков и стратегиям тестирования с левым переключением.

Что такое HashiCorp Vault и как оно работает?

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

Развертывание такого продукта, как HashiCorp Vault, дает вам лучший контроль над конфиденциальными учетными данными и помогает соответствовать стандартам облачной безопасности.

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

Что такое HashiCorp Vault?

HashiCorp Vault разработан, чтобы помочь организациям управлять доступом к секретам и безопасно передавать их внутри организации. Секреты определяются как любая форма конфиденциальных учетных данных, которые необходимо строго контролировать и отслеживать, и которые могут использоваться для разблокировки конфиденциальной информации.Секреты могут быть в форме паролей, ключей API, ключей SSH, токенов RSA или OTP.

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

Как работает HashiCorp Vault?

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

Аутентификация может осуществляться либо с помощью паролей, либо с использованием динамических значений для генерации временных токенов, которые позволяют вам получить доступ к определенному пути. Политики, написанные с использованием HashiCorp Configuration Language (HCL), используются для определения того, кто и к какому доступу имеет доступ.

Теперь, когда мы изучили, что такое HashiCorp Vault, давайте рассмотрим некоторые вещи, для которых оно используется.

Для чего используется HashiCorp Vault?

HashiCorp Vault можно использовать по-разному; мы выделили некоторые из основных вариантов использования ниже.

Секретное управление

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

С HashiCorp Vault вы можете быть уверены, что ваши учетные данные в безопасности, по сравнению с хранением файлов с открытым текстом в вашем управлении конфигурацией (например).

Вместо того, чтобы хранить файлы с открытым текстом для всеобщего обозрения, вы можете прочитать хранилище запросов приложения или использовать HashiCorp API, который защищает версии этих файлов с открытым текстом.

Секреты также легко вращать и отзывать; если сотрудник покидает вашу организацию, вы можете легко и безопасно отозвать его доступ.

Доступ на основе идентификации

HashiCorp Vault использует доступ на основе идентификации для доступа брокера к системам и секретам. Когда дело доходит до аутентификации через идентификацию, есть два основных участника: люди и машины.

Управление доступом для людей осуществляется посредством управления доступом на основе ролей (RBAC), предоставления разрешений и ограничений доступа для создания и управления секретами или управления доступом других пользователей на основе секретного значения, с которым они вошли в систему.

Управление доступом для машин, с другой стороны, включает предоставление доступа к различным серверам или секретам. Благодаря динамическому характеру HashiCorp Vault вы можете создавать секреты, которые работают временно и отменять доступ в случае нарушения. Вы можете создавать секреты по запросу для конкретной системы, такой как Sensu, AWS или Consul, и генерировать пару ключей с действующим разрешением. После использования сгенерированные динамические секреты будут автоматически аннулированы.

Шифрование данных

Vault предоставляет «шифрование как услугу», шифрование данных при передаче (с помощью TLS) и в состоянии покоя (с использованием 256-битного шифрования AES CBC).Это защищает конфиденциальные данные от несанкционированного доступа двумя основными способами: при передаче по сети, а также в хранилище в вашем облаке и центрах обработки данных.

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

Следующие шаги + дальнейшее обучение

Развертывание HashiCorp Vault — отличный способ упростить управление секретами, повысить безопасность, не мешая рабочим процессам CI / CD. Для дальнейшего изучения Vault вы можете посетить документацию и руководства HashiCorp.Чтобы узнать больше об инструментах управления секретами (например, HashiCorp Vault) для улучшения мониторинга и видимости, ознакомьтесь с нашим руководством по HashiCorp Vault, в котором освещается интеграция с Sensu Vault, а также с этим сообщением генерального директора Sensu Калеба Хейли:

Часто задаваемые вопросы + ресурсы

Сколько стоит HashiCorp Vault?

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

Как мне настроить Hashicorp Vault?

Вот шаги по установке и настройке HashiCorp Vault, как указано в их руководстве по развертыванию:

  1. Скачать Vault
  2. Установить Vault
  3. Настроить systemd
  4. Настроить Consul
  5. Настроить Vault
  6. Запустить хранилище
Как получить доступ к пользовательскому интерфейсу Vault?

Вы можете получить доступ к веб-интерфейсу Hashicorp Vault, запустив сервер Vault в режиме разработки с помощью команды vault server -dev и перейдя по адресу http: // 127.0.0.1: 8200 / ui в вашем браузере. Ознакомьтесь с их документацией, чтобы получить дополнительные советы по началу работы.

Безопасно ли HashiCorp Vault?

Использование HashiCorp Vault для управления секретами, безусловно, более безопасно, чем размещение секретов в открытом виде в ваших конфигурациях. В соответствии с лучшими отраслевыми практиками шифрования данных, HashiCorp Vault использует как TLS для передачи данных, так и 256-битное шифрование AES для данных в состоянии покоя.

HashiCorp Vault и MariaDB — База знаний MariaDB

Vault — это программное обеспечение с открытым исходным кодом для управления секретами, предоставляемое HashiCorp.Он разработан, чтобы избежать разглашения секретов различных типов, таких как пароли и закрытые ключи. При построении автоматизации Vault — хорошее решение, позволяющее избежать хранения секретов в виде обычного текста в репозитории.

MariaDB и Vault могут связывать друг друга несколькими способами:

  • Секреты MariaDB можно хранить в Vault. Обычно сюда входят пароли пользователей и закрытые ключи для доступа по SSH.
  • MariaDB (и MySQL) может использоваться как секретный механизм, компонент, который хранит, генерирует или шифрует данные.
  • MariaDB (и MySQL) можно использовать в качестве внутреннего хранилища, обеспечивая надежность данных Vault.

Для получения информации об установке Vault см. Установка Vault.

Особенности хранилища

Vault используется через HTTP / HTTPS API.

Vault является личным. Пользователи входят в систему, и Сейф отправляет им токен, действительный в течение определенного времени или до тех пор, пока не возникнут определенные условия. Пользователи с действующим токеном могут запросить получение секретов, для которых у них есть соответствующие разрешения.

Vault шифрует хранимые в нем секреты.

Vault может дополнительно контролировать изменения секретов и секретные запросы пользователей.

Архитектура хранилища

Vault — это сервер. Это позволяет отделить логику управления секретами от клиентов, которым нужно только войти в систему и хранить токен до истечения срока его действия.

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

Основные компоненты Vault:

  • Storage Backed : Здесь хранятся секреты.Сейф отправляет только зашифрованные данные в внутреннее хранилище.
  • HTTP API : этот API используется клиентами и обеспечивает доступ к серверу Vault.
  • Барьер : Как и настоящий барьер, он защищает все внутренние компоненты Убежища. HTTP API и серверная часть хранилища находятся за пределами барьера и могут быть доступны любому. Все коммуникации от этих компонентов и к этим компонентам должны проходить через барьер. Барьер проверяет данные и шифрует их. Шлагбаум может иметь два состояния: опломбировано или открыто .Данные могут проходить только тогда, когда барьер снят. Все следующие компоненты расположены внутри барьера.
  • Метод аутентификации : обрабатывает попытки входа в систему от клиентов. При успешном входе в систему метод auth возвращает в ядро ​​Vault список политик безопасности.
  • Хранилище токенов : Здесь хранятся токены, созданные в результате успешного входа в систему.
  • Secrets Engines : Эти компоненты управляют секретами. Они могут иметь разный уровень сложности.Некоторые из них просто ожидают получить ключ и вернут соответствующий секрет. Другие могут создавать секреты, в том числе одноразовые пароли.
  • Устройства аудита : Эти компоненты регистрируют запросы, полученные Vault, и ответы, отправленные обратно клиентам. Может быть несколько устройств, и в этом случае Audit Broker отправляет запрос или ответ на соответствующее устройство.

Режим разработки

Можно запустить Vault в режиме разработки:

 сервер хранилища -dev
 

Режим разработчика полезен для изучения Vault или проведения экспериментов с некоторыми конкретными функциями.Это крайне небезопасно, потому что режим разработки эквивалентен запуску Vault с несколькими небезопасными параметрами. Это означает, что Vault никогда не должен запускаться в производственной среде в режиме разработки. Однако это также означает, что все обычные функции Vault доступны в режиме разработки.

Dev mode упрощает все операции. На самом деле, для запуска Vault в режиме разработки не требуется никакой настройки. Это позволяет общаться с Vault API из оболочки без какой-либо аутентификации. По умолчанию данные хранятся в памяти.Хранилище по умолчанию не запечатано, и если оно явно запечатано, его можно распечатать, используя только один ключ.

Дополнительные сведения см. В разделе «Режим сервера для разработчиков» документации Vault.

Ресурсы и справочная информация по Vault


Контент, изначально предоставленный Vettabase Ltd.

Как хранилище используется в гражданском строительстве?

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

Один из них — «склеп», история которого насчитывает тысячи лет.

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

Ниже мы объясним эту концепцию более подробно.

Что такое хранилище в строительстве?

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

Хранилище — это просто серия арок, соединенных в линию. Они обычно используются при строительстве внутреннего потолка здания или используются как средство создания внешних проходов.

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

Как хранилище используется в гражданском строительстве?

Термин «свод» является довольно общим, так как он охватывает множество различных типов, включая цилиндрические своды, своды монастыря, сводчатые своды, ребристые своды, паховые своды и веерные своды.

Хранилище ствола также может называться «хранилище колыбели» или «хранилище туннеля» и выглядит как непрерывная арка. С точки зрения непрофессионала, это похоже на потолок туннеля с арками, выстроенными рядом друг с другом.

Монастырский свод , или «купольный свод», как следует из названия, имеет куполообразную форму. Арки простираются к центральной точке.

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

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

Паховые своды образуются, когда два цилиндрических свода пересекаются под прямым углом. Точка, в которой пересекаются своды ствола, называется «пах».

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

Что такое римский склеп?

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

Как Vault применяется в гражданском строительстве

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

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

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

Какая цивилизация связана с развитием Убежища?

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

Знакомство с Убежищем | Baeldung

1. Обзор

В этом руководстве мы рассмотрим Hashicorp Vault — , популярный инструмент, используемый для безопасного управления конфиденциальной информацией в современных архитектурах приложений .

Основные темы, которые мы рассмотрим, включают:

  • Какую проблему пытается решить Vault
  • Архитектура и основные концепции Убежища
  • Настройка простой тестовой среды
  • Взаимодействие с Vault с помощью инструмента командной строки

2.Проблема с конфиденциальной информацией

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

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

Учетные данные базы данных

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

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

Мы можем немного усложнить задачу, зашифровав эти файлы.Однако этот подход не принесет много пользы с точки зрения общей безопасности. В основном потому, что у нашего приложения должен быть доступ к мастер-ключу. Шифрование при таком использовании приведет лишь к «ложному» чувству безопасности.

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

Итак, что мы можем сделать? Давайте сделаем это!

3.Что такое Vault?

Hashicorp Vault решает проблему управления конфиденциальной информацией — секретом на языке Vault. «Управление» в этом контексте означает, что Vault контролирует все аспекты конфиденциальной информации : ее создание, хранение, использование и, наконец, что не менее важно, ее отзыв.

Hashicorp предлагает две версии Vault. Версия с открытым исходным кодом, использованная в этой статье, бесплатна для использования даже в коммерческих средах. Также доступна платная версия, которая включает техническую поддержку по различным SLA и дополнительные функции, такие как поддержка HSM (Hardware Security Module).

3.1. Архитектура и основные характеристики

Архитектура

Vault обманчиво проста. Его основные компоненты:

  • Постоянный сервер — хранилище для всех секретов
  • Сервер API, который обрабатывает запросы клиентов и выполняет операции с секретами
  • Количество из секретных машин, по одному для каждого типа поддерживаемого секретного типа

Делегируя всю обработку секретов Vault, мы можем смягчить некоторые проблемы безопасности:

  • Нашим приложениям больше не нужно их хранить — просто спросите Vault, когда это необходимо, и откажитесь от него
  • Мы можем использовать кратковременные секреты, тем самым ограничивая «окно возможностей», когда злоумышленник может использовать украденный секрет

Vault шифрует все данные с помощью ключа шифрования перед их записью в хранилище.Этот ключ шифрования зашифрован еще одним ключом — главным ключом, используемым только при запуске.

Ключевым моментом в реализации Vault является то, что он не хранит главный ключ на сервере. Это означает, что даже Vault не может получить доступ к своим сохраненным данным после запуска. На этом этапе считается, что экземпляр Vault находится в «запечатанном» состоянии.

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

После распечатки Vault будет готов принимать запросы API.Эти запросы, конечно, требуют аутентификации, что подводит нас к тому, как Vault аутентифицирует клиентов и решает, что они могут или не могут делать.

3.2. Аутентификация

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

При первоначальной установке Vault автоматически генерирует «корневой токен». Этот токен является эквивалентом суперпользователя root в системах Linux, поэтому его использование должно быть ограничено до минимума.Лучше всего использовать этот корневой токен только для создания других токенов с меньшими привилегиями, а затем отозвать его. Однако это не проблема, поскольку позже мы можем сгенерировать еще один корневой токен, используя незапечатанные ключи.

Vault также поддерживает другие механизмы аутентификации, такие как сертификаты LDAP, JWT, TLS и другие. Все эти механизмы основаны на базовом механизме токенов: как только Vault проверит нашего клиента, он предоставит токен, который мы затем можем использовать для доступа к другим API.

У токенов

есть несколько связанных с ними свойств.Основные свойства:

  • Набор связанных политик (см. Следующий раздел)
  • Срок службы
  • Можно ли продлить
  • Максимальное количество использований

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

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

3.3. Политики

Политики точно определяют, к каким секретам клиент может получить доступ и какие операции он может выполнять с ними. . Посмотрим, как выглядит простая политика:

  путь "секрет / учет" {
    возможности = ["читать"]
}  

Здесь мы использовали синтаксис HCL (язык конфигурации Hashicorp) для определения нашей политики. Vault также поддерживает JSON для этой цели, но в наших примерах мы будем придерживаться HCL, поскольку его легче читать.

Политики в Vault запрещены по умолчанию . Маркер, прикрепленный к этому образцу политики, получит доступ к секретам, хранящимся в secret / account , и ни к чему другому. Во время создания токен можно привязать к нескольким политикам. Это очень полезно, потому что позволяет нам создавать и тестировать более мелкие политики, а затем применять их по мере необходимости.

Еще одним важным аспектом политик является то, что они используют ленивую оценку. Это означает, что мы можем обновить данную политику, и все токены будут затронуты немедленно.

Политики, описанные до сих пор, также называются политиками списков управления доступом или политиками ACL. Vault также поддерживает два дополнительных типа политик: политики EGP и RGP. Они доступны только в платных версиях и расширяют базовый синтаксис политики с поддержкой Sentinel.

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

Более подробную информацию о синтаксисе политики можно найти в документации Vault.

4. Секретные типы

Vault поддерживает ряд различных типов секретов, которые предназначены для разных случаев использования:

  • пара «ключ-значение»: простых статических пар «ключ-значение»
  • Динамически генерируемые учетные данные : генерируются Vault по запросу клиента
  • Криптографические ключи : используются для выполнения криптографических функций с данными клиента

Каждый секретный тип определяется следующими атрибутами:

  • mount point, , которая определяет его префикс REST API
  • Набор операций, предоставляемых через соответствующий API
  • Набор параметров конфигурации

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

Например, строка secret / my-application соответствует пути, по которому мы можем найти пары ключ-значение для my-application .

4.1. Секреты ключевой ценности

Секреты «ключ-значение», как следует из названия, представляют собой простые пары, доступные по заданному пути . Например, мы можем сохранить пару foo = bar по пути / secret / my-application.

Позже мы используем один и тот же путь для получения одной и той же пары или пар — несколько пар могут храниться по одному и тому же пути.

Vault поддерживает три типа секретов ключа и значения:

  • Пары ключей без версий , где обновления заменяют существующие значения
  • Пары ключей с поддержкой версий, , которые поддерживают до настраиваемого количества старых версий
  • Cubbyhole , особый тип пар ключей без версий, значения которых привязаны к заданному токену доступа (подробнее об этом позже).

Секреты «ключ-значение» статичны по своей природе, поэтому нет никакой концепции связанного с ними срока действия. Основной вариант использования такого рода секретов — хранение учетных данных для доступа к внешним системам, например ключей API.

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

4.2. Динамически генерируемые секреты

Динамические секреты генерируются Vault «на лету» по запросу приложения .Vault поддерживает несколько типов динамических секретов, в том числе следующие:

  • Учетные данные базы данных
  • Пары ключей SSH
  • Сертификаты X.509
  • Учетные данные AWS
  • Аккаунтов сервиса Google Cloud
  • Аккаунты Active Directory

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

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

Затем мы создаем одну или несколько ролей (роли Vault, а не роли базы данных), содержащие фактические операторы SQL, используемые для создания нового пользователя. Они обычно включают не только оператор создания пользователя, но и все необходимые операторы grant , необходимые для доступа к объектам схемы (таблицам, представлениям и т. Д.).

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

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

4.3. Криптографические ключи

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

Связанный API позволяет клиентам отправлять данные Vault в виде обычного текста и получать их зашифрованную версию.Возможно и обратное: мы можем отправить зашифрованные данные и вернуть исходный текст.

В настоящее время существует только один двигатель этого типа: двигатель Transit . Этот механизм поддерживает популярные типы ключей, такие как RSA и ECDSA, а также поддерживает конвергентное шифрование . При использовании этого режима заданное значение открытого текста всегда приводит к одному и тому же результату зашифрованного текста — свойство, которое очень полезно в некоторых приложениях.

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

5. Настройка хранилища

В этом разделе мы создадим локальную тестовую среду, чтобы протестировать возможности Vault.

Развернуть

Vault просто: просто скачайте пакет, соответствующий нашей операционной системе, и извлеките его исполняемый файл ( vault или vault.exe в Windows) в какой-нибудь каталог на нашем пути. Этот исполняемый файл содержит сервер и также является стандартным клиентом . Также доступен официальный образ Docker, но мы не будем его здесь рассматривать.

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

Вместо этого мы будем использовать постоянное хранилище на основе файлов и настроим HTTPS, чтобы мы могли исследовать некоторые реальные детали конфигурации, которые могут быть источником проблем.

5.1. Запуск Vault Server

Vault использует файл конфигурации в формате HCL или JSON. Следующий файл определяет всю конфигурацию, необходимую для запуска нашего сервера с использованием файлового хранилища и самозаверяющего сертификата:

  хранилище "файл" {
  путь = "./vault-data"
}
listener "tcp" {
  адрес = "127.0.0.1:8200"
  tls_cert_file = "./src/test/vault-config/localhost.cert"
  tls_key_file = "./src/test/vault-config/localhost.key"
}  

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

  $ сервер хранилища -config ./vault-test.hcl  

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

5.2. Инициализация хранилища

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

Давайте откроем новую оболочку и выполним для этого следующие команды:

  $ экспорт VAULT_ADDR = https: // localhost: 8200
$ экспорт VAULT_CACERT =. / SRC / test / vault-config / localhost.cert
$ vault operator init  

Здесь мы определили несколько переменных среды, поэтому нам не нужно каждый раз передавать их в Vault в качестве параметров:

  • VAULT_ADDR : базовый URI, по которому наш сервер API будет обслуживать запросы
  • VAULT_CACERT : Путь к открытому ключу сертификата нашего сервера

В нашем случае мы используем VAULT_CACERT , поэтому мы можем использовать HTTPS для доступа к API Vault.Нам это нужно, потому что мы используем самозаверяющие сертификаты. В этом нет необходимости для производственных сред, где у нас обычно есть доступ к сертификатам, подписанным CA.

После выполнения указанной выше команды мы должны увидеть такое сообщение:

  Распечатать ключ 1: <значение ключевой доли 1>
Распечатать ключ 2: <значение ключевой доли 2>
Распечатать ключ 3: <значение доли ключа 3>
Распечатать ключ 4: <значение ключевой доли 4>
Распечатать ключ 5: <значение ключевой доли 5>

Начальный корневой токен: <значение корневого токена>

... больше сообщений пропущено  

Пять первых строк — это общие общие ключи, которые мы позже будем использовать для вскрытия хранилища Vault. Обратите внимание, что Vault отображает только общие главные ключи во время инициализации — и никогда больше. Примите к сведению и храните их в надежном месте, иначе мы потеряем доступ к нашим секретам после перезапуска сервера!

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

  $ export VAULT_TOKEN = <значение корневого токена> (Unix / Linux)  

Давайте посмотрим на статус нашего сервера теперь, когда мы его инициализировали, с помощью следующей команды:

  $ статус хранилища
Ключевое значение
--- -----
Тип уплотнения шамир
Запечатанная правда
Всего акций 5
Порог 3
Распечатать прогресс 0/3
Unseal Nonce нет
Версия 0.10,4
HA Enabled false  

Мы видим, что Убежище все еще закрыто. Мы также можем следить за процессом распечатки: «0/3» означает, что Vault нужно три акции, но пока нет ни одной. Пойдем дальше и обеспечим его своими акциями.

5.3. Vault Unseal

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

  $ vault operator unseal <значение ключевой доли 1>
$ vault operator unseal <значение ключевой доли 2>
$ vault operator unseal <значение доли ключа 3>  

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

  Ключевое значение
--- -----
Тип уплотнения шамир
Запечатанный ложный
... другие свойства опущены  

Свойство «Запечатано» в этом случае имеет значение «false», что означает, что Vault готов принимать команды.

6. Тестирование Убежища

В этом разделе мы протестируем нашу настройку Vault с использованием двух поддерживаемых типов секретов: ключ / значение и база данных. Мы также покажем, как создавать новые токены с привязанными к ним определенными политиками.

6.1. Использование секретов ключа / значения

Во-первых, давайте сохраним секретные пары ключ-значение и прочитаем их обратно. Предполагая, что командная оболочка, используемая для инициализации Vault, все еще открыта, мы используем следующую команду для сохранения этих пар по пути secret / fakebank :

  $ vault kv put secret / fakebank api_key = abc1234 api_secret = 1a2b3c4d  

Теперь мы можем восстановить эти пары в любое время с помощью следующей команды:

  $ хранилище кв получить секрет / фейкбанк
======= Данные =======
Ключевое значение
--- -----
api_key abc1234
api_secret 1a2b3c4d

  

Этот простой тест показывает, что Vault работает должным образом.Теперь мы можем протестировать некоторые дополнительные функции.

6.2. Создание новых токенов

До сих пор мы использовали корневой токен для аутентификации наших запросов. Поскольку корневой токен на слишком мощный, рекомендуется использовать токены с меньшими привилегиями и меньшим временем жизни.

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

  $ токен хранилища создать -ttl 1m
Ключевое значение
--- -----
токен <значение токена>
token_accessor <значение доступа к токену>
token_duration 1 мес.
token_renewable истина
token_policies ["корень"]
identity_policies []
политики ["корень"]  

Давайте протестируем этот токен, используя его для чтения пар ключ / значение, которые мы создали ранее:

  $ export VAULT_TOKEN = <значение токена>
$ vault kv получить секрет / fakebank
======= Данные =======
Ключевое значение
--- -----
api_key abc1234
api_secret 1a2b3c4d  

Если мы подождем минуту и ​​попробуем повторить эту команду, мы получим сообщение об ошибке:

  $ хранилище кв получить секрет / фейкбанк
Ошибка при запросе API.URL: ПОЛУЧИТЬ https: // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank
Код: 403. Ошибки:

* в разрешении отказано  

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

6.3. Политика тестирования

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

Например, давайте определим политику, которая разрешает доступ только для чтения к пути secret / fakebank , который мы использовали раньше:

  $ cat> sample-policy.hcl << EOF
path "secret / fakebank" {
    возможности = ["читать"]
}
EOF
$ export VAULT_TOKEN = <корневой токен>
$ vault policy написать fakebank-ro ./sample-policy.hcl
Успех! Загружен полис: fakebank-ro  

Теперь мы создаем токен с этой политикой с помощью следующей команды:

  $ export VAULT_TOKEN = <корневой токен>
$ vault token create -policy = fakebank-ro
Ключевое значение
--- -----
токен <значение токена>
token_accessor <значение доступа к токену>
token_duration 768h
token_renewable истина
token_policies ["по умолчанию" "fakebank-ro"]
identity_policies []
политики ["по умолчанию" "fakebank-ro"]  

Как и раньше, давайте прочитаем наши секретные значения, используя этот токен:

  $ export VAULT_TOKEN = <значение токена>
$ vault kv получить секрет / fakebank
======= Данные =======
Ключевое значение
--- -----
api_key abc1234
api_secret 1a2b3c4d  

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

  $ vault kv put secret / fakebank api_key = foo api_secret = bar
Ошибка записи данных в secret / fakebank: ошибка при запросе API.

URL: PUT https://127.0.0.1:8200/v1/secret/fakebank
Код: 403. Ошибки:

* в разрешении отказано  

Поскольку наша политика явно не разрешает запись, Vault возвращает код состояния 403 — Доступ запрещен.

6.4. Использование динамических учетных данных базы данных

В качестве последнего примера в этой статье давайте воспользуемся секретным механизмом базы данных Vault для создания динамических учетных данных.Здесь мы предполагаем, что у нас есть сервер MySQL, доступный локально, и что мы можем получить к нему доступ с правами «root». Мы также будем использовать очень простую схему, состоящую из одной таблицы — account .

Сценарий SQL, использованный для создания этой схемы и привилегированного пользователя, доступен здесь.

Теперь давайте настроим Vault для использования этой базы данных. Механизм секретов базы данных не включен по умолчанию, поэтому мы должны исправить это, прежде чем продолжить:

  $ секреты хранилища включают базу данных
Успех! Включен механизм секретов базы данных по адресу: database /  

Теперь мы создаем ресурс конфигурации базы данных:

  $ база данных записи хранилища / config / mysql-fakebank \
  plugin_name = mysql-legacy-база-плагин \
  connection_url = "{{username}}: {{password}} @ tcp (127.0.0.1: 3306) / fakebank "\
  allowed_roles = "*" \
  username = "fakebank-admin" \
  пароль = "Sup & rSecre7!"  

Префикс пути database / config — это место, где должны храниться все конфигурации базы данных. Мы выбираем имя mysql-fakebank , чтобы мы могли легко выяснить, к какой базе данных относится эта конфигурация. Что касается ключей конфигурации:

  • plugin_name: Определяет, какой подключаемый модуль базы данных будет использоваться. Доступные названия плагинов описаны в документации Vault
  • .

  • connection_url : это шаблон, используемый плагином при подключении к базе данных.Обратите внимание на заполнители шаблонов {{username}} и {{password}}. При подключении к базе данных Vault заменит эти заполнители фактическими значениями
  • allowed_roles : Определите, какие роли Vault (обсуждаются далее) могут использовать эту конфигурацию. В нашем случае мы используем «*», поэтому он доступен для всех ролей
  • имя пользователя и пароль: Это учетная запись, которую Vault будет использовать для выполнения операций с базой данных, таких как создание нового пользователя и отмена его привилегий

Настройка роли базы данных Vault

Последняя задача настройки — создать ресурс роли базы данных Vault, содержащий команды SQL, необходимые для создания пользователя.Мы можем создать столько ролей, сколько необходимо, в соответствии с нашими требованиями безопасности.

Здесь мы создаем роль, которая предоставляет доступ только для чтения ко всем таблицам схемы fakebank :

  $ хранилище записывает базу данных / роли / fakebank-accounts-ro \
    db_name = mysql-fakebank \
    creation_statements = "CREATE USER '{{name}}' @ '%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON fakebank. * TO '{{name}}' @ '%';"
  

Ядро базы данных определяет префикс пути база данных / роли как расположение для хранения ролей. fakebank-accounts-ro — это имя роли, которое мы позже будем использовать при создании динамических учетных данных. Также мы поставляем следующие ключи:

  • db_name : имя существующей конфигурации базы данных. Соответствует последней части пути, который мы использовали при создании ресурса конфигурации
  • creation_statements: Список шаблонов операторов SQL, которые Vault будет использовать для создания нового пользователя

Создание динамических учетных данных

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

  $ хранилище для чтения базы данных / creds / fakebank-accounts-ro
Ключевое значение
--- -----
lease_id база данных / creds / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4
lease_duration 1ч
lease_renewable true
пароль <пароль>
имя пользователя <имя пользователя>
  

Префикс database / creds используется для создания учетных данных для доступных ролей.Поскольку мы использовали роль fakebank-accounts-ro , возвращаемое имя пользователя / пароль будет ограничено операциями выбора .

Мы можем проверить это, подключившись к базе данных, используя предоставленные учетные данные, а затем выполнив несколько команд SQL:

  $ mysql -h 127.0.0.1 -u <имя пользователя> -p fakebank
Введите пароль:
MySQL [fakebank]> выберите * из аккаунта;
... опущено для краткости
2 ряда в наборе (0,00 сек)
MySQL [fakebank]> удалить из аккаунта;
ОШИБКА 1142 (42000): команда DELETE отклонена пользователю v-fake-9xoSKPkj1 @ localhost для таблицы account
  

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

7. Заключение

В этой статье были изучены основы Hashicorp’s Vault, включая некоторую справочную информацию о проблеме, которую он пытается решить, его архитектуре и базовом использовании.

Попутно мы создали простую, но функциональную среду тестирования, которую мы будем использовать в следующих статьях.

В следующей статье будет рассмотрен очень конкретный вариант использования Vault: Использование его в контексте приложения Spring Boot . Будьте на связи!

Безопасность внизу

Я только что анонсировал новый курс Learn Spring Security , включающий полный материал о новом стеке OAuth3 в Spring Security 5:

>> ПРОВЕРИТЬ КУРС

Убежище Диснея реально. Вот как это выглядит внутри

Фрагмент концепт-арта Пиноккио, найденный в Убежище Диснея.Фото: Disney Enterprises Inc.

В 1944 году Дисней повторно выпустил Белоснежка и семь гномов в кинотеатрах по всей стране. Во время своего первого выхода в 1937 году фильм был сенсацией — помимо того, что он был виртуозным техническим достижением в качестве первого полнометражного анимационного фильма, он также произвел фурор критиков и произвел коммерческий успех. И хотя переиздание фильма было скорее маркетинговым решением, чем творческим (студия была практически парализована в творческом и финансовом плане из-за участия Америки во Второй мировой войне, и ни одна из его последующих работ не охватила дух времени так, как Snow White ), это стало прецедентом для студии, которая вскоре стандартизировала практику как выпуска, так и отказа от классических анимационных фильмов.Философия заключалась в том, чтобы вывести каждый фильм из обращения примерно на семь лет, что, по мнению руководителей студии, создавало ощущение срочности и волнения и создавало дополнительную загадочность. Когда Майкл Эйснер и Фрэнк Уэллс возглавили Disney в другой неспокойный период для компании, 1980-е, они решили выпустить многие из самых популярных анимационных фильмов на видеокассетах, что было спорным шагом в то время. Но в итоге дуэт пошел по стопам тех оригинальных театральных выставок — фильмы появлялись на видео в течение ограниченного времени, а затем исчезали из магазинов.Только на этот раз у них было название того места, где проходили фильмы, когда их больше не было: Убежище Диснея.

Для большинства Хранилище Диснея кажется чем-то неосязаемым — маркетинговым трюком и источником неуместной ярости (есть несколько видеороликов на YouTube, осуждающих Убежище и все, что оно означает). Дисней, со своей стороны, много сделал для того, чтобы увековечить непонятное представление о Диснеевском Убежище как о чем-то реальном, но невидимом, существующем, как и многие другие фантастические миры Диснея, в вашем воображении больше, чем в реальной жизни.Но он существует. И я был внутри.

В анонимном квартале Глендейла, Калифорния, находится невзрачное бежевое здание без вывесок и знаков различия. Единственное, что могло бы даже предупредить вас о том, что это диснеевский эквивалент Форт-Нокса, — это обилие безумных процедур безопасности, размещенных вокруг здания. Даже для сотрудников компании здание остается труднодоступным и труднодоступным. (Полное раскрытие: я проработал в компании почти два года и ни разу не ушел.В отличие от основных архивов студии на улице, которые размещены в привлекательном стеклянном здании с обильными вывесками — именно это место появляется на камерах, когда компания снимает документальные фильмы о Убежище Диснея — это место похоже на мираж.

Когда вы входите в холл, вас предупреждают о том, что это единственное место на всем объекте, где можно делать фотографии. Высокий мужчина по имени Том говорит, что, если вы все-таки фотографируете, ради Бога не помечайте свое местоположение гео.По сути, это здание отключено от электросети. Это Зона 51 Диснея. Добро пожаловать в Библиотеку исследований анимации.

Осмотрев вестибюль, вы уже можете почувствовать историю — на потолке светильники, похожие на фонари, которые раньше висели в здании студии анимации Уолта Диснея в Бербанке до недавней реконструкции; в углу стоит пианино, которое раньше было в так называемой «музыкальной комнате» Анимационной студии; у стены — анимационный стол, которым пользовался Пре Романильос, аниматор, который вырезал своих персонажей на деревянной раме стола (Пре умер в 2010 году в возрасте 47 лет).Само здание — что-то вроде потерянного сокровища Диснея. Это место, где снимались такие фильмы, как Русалочка и Аладдин , после того, как анимационная группа была запущена на территории Диснея и до того, как на улице в Бербанке было построено «здание для шляп». Когда землетрясение в Нортридже произошло во время производства Король Лев , некоторые аниматоры жили в этом здании. И мы еще даже не попали в хранилище.

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

С точки зрения размера хранилище просто безумное — здесь 12 хранилищ, каждое из которых организовано по проектам. Это включает в себя все, от оригинальных эскизов для Белоснежки и семи гномов до более крупных предметов, таких как все марионетки из Кошмар перед Рождеством и Frankenweenie .В каждой комнате установлен климат-контроль, она тщательно каталогизирована и оснащена самыми современными системами безопасности и пожаротушения. По собственным оценкам библиотеки, в коллекции около 65 миллионов произведений искусства, что делает ее крупнейшей коллекцией анимационных произведений во всем мире. Хранилища выглядят так, как вы могли подумать: ряды вещей расположены в шкафах, которые можно перемещать с помощью большой вращающейся ручки (например, хранилища), так что вы можете легко добраться до них.Что касается иллюстраций, то они хранятся так, как должны, с ячейками или производственными изображениями, сложенными горизонтально, в то время как другие, менее важные элементы хранятся вертикально в папках в стиле гармошки. Крупногабаритные предметы, например большие фоновые рисунки, помещаются в отдельные плоские файлы. Ощущение, что войти в одно из хранилищ, похоже на то, как наткнуться на склад в конце В поисках утраченного ковчега , за исключением того, что вместо деликатных правительственных и исторических секретов есть куча эскизов Мулан, а также какой-то парень по имени Том кричит тебе, чтобы ты оставался за желтой линией.

Я был там в составе небольшой группы журналистов, которых привели в здание якобы, чтобы отпраздновать выход Пиноккио из Убежища Диснея с цифровым переизданием. Находясь там, мне удалось поболтать с Фоксом Карни, менеджером библиотеки исследований анимации, и он сказал мне, что в архивах содержится «более миллиона» произведений искусства только для Пиноккио .

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

«Многие из этих произведений искусства могут и не существовать», — признал Карни. Мы стояли на большом участке в задней части здания, который назывался «Черный стол», который, как и следовало ожидать, представляет собой огромный черный стол, на котором предметы исследуются либо для любопытных глаз приезжих журналистов, либо для служебного пользования, прежде чем их классифицируют , отсортированы и каталогизированы.Возможно, они не держались за это произведение искусства. Но если бы мы создали вымышленную историю в стиле « Индиана Джонс, », то где-то в Северном Голливуде было бы складское помещение, которое сдавалось в аренду с 1938 года, и в нем были бы все эти произведения искусства. Но это граничит с фантазией.

Помимо хранения, главное назначение Убежища — кураторское. Здесь собирают и распространяют произведения искусства для таких вещей, как передвижные выставки, будь то галерея произведений искусства Диснея, недавно открывшаяся в материковом Китае, или прохождение выставки D23 Expo, двухгодичной диснеевской версии Comic Con.Другая функция — образовательная. Карни говорит, что большую часть своего дня он проводит, отвечая на запросы из других частей более крупной империи Диснея — Consumer Products, Imagineering — с просьбой взглянуть на предметы из библиотеки для их собственных проектов, будь то аттракцион нового тематического парка или товар, относящийся к фильму. Для этого переиздания Pinocchio , Карни сказал мне, что команда из пяти архивистов почти год работала над сбором материала.

Хранилище также может быть полезно тем, кто пишет об этих анимационных шедеврах.Я поговорил с Дж. Б. Кауфманом, чья книга «Пиноккио: создание диснеевского эпоса » является исчерпывающим отчетом о создании фильма. «Многое из того, что я смотрю, — это листы экспозиции», — сказал мне Кауфман. «Экспозиционные листы расскажут вам много информации, которой больше нигде нет. И когда они действительно принимали заказы [инструкция реанимировать заданную последовательность], они отправляются вместе с листами разоблачения. Я исследовал сцену, в которой Синяя фея приходит в мастерскую Джеппетто, и есть сцена, которая служит Розеттским камнем, где они устанавливают, как этот персонаж был анимирован.Для этой сцены было 11 заказов на пересдачу ». Кауфман добавил: «Для меня это было одним из величайших открытий — увидеть, насколько дотошно они подошли к этому аспекту».

Это захватывающие ощущения от посещения Убежища Диснея — вы буквально можете наткнуться на то, чего никто не видел десятилетиями. «В любой день вы можете открыть коробку и увидеть искусство, на которое люди, возможно, не смотрели 20, 30, 40 лет», — сказал мне Карни.

Как и большинство библиотек, Библиотека исследований анимации постепенно переходит в цифровую эпоху.В какой-то момент во время экскурсии мы вошли в комнату, где небольшая группа технических специалистов работала над оцифровкой огромного количества контента. Они говорят, что задача — превратить «физическое в цифровое», и что отдача не поддается подсчету. Это не только файлы с высоким разрешением, для захвата и загрузки которых может потребоваться до двух минут. Запечатлено все, от ожогов от сигарет и пятен от кофе до заметок аниматоров. Для таких вещей, как произведение искусства из Sleeping Beauty , которое было снято на 70 мм и требовало от аниматоров работы на листах бумаги размером с простыню, они используют особый процесс, при котором вакуумная система засасывает произведение искусства на стол, а затем перемещается, как на конвейерной ленте, чтобы его можно было полностью захватить.После того, как произведение оцифровано, оно перемещается в систему под названием GEMS, доступ к которой имеют сотрудники Walt Disney Animation Studio, Pixar и Disney Toon Studio (создатели фильмов Planes ). После того, как произведение искусства оцифровано, вы можете наблюдать, как целые последовательности разыгрываются в их приблизительной форме, и увеличивать масштаб, чтобы увидеть детали фона, которые художники помещают в мастерскую Джеппетто с пугающей четкостью.

Процесс пугающий. На данный момент было снято чуть более миллиона изображений, и предстоит еще долгий путь.Но с обратной стороны преимущества будут огромными. «Эта компания действительно много инвестирует в это, — сказал Карни. «Это выше чистой прибыли. Это больше всего на свете «.

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

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *