Где хранить доступы

Скачать файл - Где хранить доступы

Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В системе деплоя Jenkins, Teamcity, etc? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов? Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры. Начнём исследование вопроса с определения требований к хранению секретов. Доступ к хранилищу осуществляется исключительно через API. Для нас Vault решает проблемы передачи секретов по незащищённым каналам, проблемы отказоустойчивого хранения секретов, а также проблемы гибкого разделения и аудита доступов. В планах использовать Vault как собственный CA. Итак, вы запустили Vault. Официальный процесс работы выглядит так:. Оказалось неудобным постоянно переключать токены, если ты отвечаешь за несколько сервисов. Из-за особенности управления политиками доступа подробнее ниже выросли накладные расходы на первичное внедрение Vault в рабочий процесс сервиса. Они описываются в формате JSON или HCL и записываются в Vault с помощью запроса к API или через cli. Мастер-токен может создавать токены только с теми политиками, которыми он обладает. И тут есть нюанс: Это означает, что если вы сделаете root политику вида:. Вам придётся уравновесить каждую детализированную политику на чтение, чтобы этого не случилось. Это не делает жизнь операторов легче, поэтому мы отказались от этого подхода и работаем с секретами только из под root-ключей. В документации к Vault зря не сказано о важности учёта выпущенных токенов. Если вы создали токен и забыли о нём, не записав никакой информации, то вам придётся дожидаться, пока у него закончится срок жизни. У root-токенов нет срока жизни, поэтому они будут оставаться в вашей системе бесконечно. Это позволит спокойно работать и не бояться бесконтрольно увеличить количество токенов. Также есть риск не уследить за истечением срока жизни токена и узнать об этом, например, во время деплоя. Эту проблему можно решить, записывая токены и мониторя срок жизни. Но записывать токены куда-то в одно место — небезопасно. Поэтому с версии Vault 0. Ведение данных о выданных токенах позволяет проводить быстрый аудит активных доступов в системе и настроить мониторинг на истечение срока жизни токена. Если токен был родительским для других токенов, то по умолчанию при отзыве этого токена все токены и секреты, созданные отзываемым токеном, отзываются рекурсивно. Если вы будете использовать consul-template для автоматической перегенерации конфигов при изменении секретов, имейте в виду и этого вы не найдёте в документации , что consul-template опрашивает изменение секрета в двух случаях:. Тут надо оговориться, что я по умолчанию считаю рабочую станцию админа защищённой зашифрованные диски, отсутствие гостевого входа, автоблокирование через минуту неактивности. Если это не так — то стоит отказаться от этой идеи. Нам не подошёл официальный процесс работы с Vault по причине излишней трудоёмкости внедрения Vault в эксплуатацию сервиса. Поделюсь нашими решениями и ответами на возникающие вопросы в процессе внедрения Vault. Мы используем первую схему. Мы установили и запустили Vault, получили root-токен. По последней версии процесса, принятого в моей компании, это будет выглядеть так: Проверим, что есть доступ на чтение:. Всё работает, мы готовы использовать наш токен в системах автоматизации. Приведу примеры для популярных систем. Это удобно и позволяет не искать переменные по роли. Hashicorp в своём блоге описали несколько путей использования секретов из Vault в своих chef-кукбуках — https: Для puppet существует прекрасный модуль https: Я не понимаю, как ваши слова противоречат статье и паттерну использования Vault. Vault не запрещает гибко управлять доступами к секретам. Вы можете и должны делать токены для доступа только к тем секретам, которые необходимы и достаточны для выполнения работ. Так эти хранилища решают другие проблемы: Аудит Настраиваемая гибкость доступа к секретам Обслуживание жизненного цикла секретов и доступов Безопасность — это вообще сложная тема, тут нет серебряных пуль, которые сделают вашу систему безопасной. Только работа с рисками, только хардкор: Можно ли из этого построить корпоративную базу паролей наподобие teampass или привязать teampass к такой базе? Мне лично удобнее standalone-приложения после keepass, который очищает буфер обмена как-то непривычно знать, что сайт не очистит пароль , но приходится пользоваться общими тулзами. Так мы не от админа с рут-доступом защищаемся. Мы защищаемся от некоего злоумышленника, который мог получить доступ к хранилищу. Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Требования к способу хранения секретов инфраструктуры: Тонкая настройка правил доступа к секретам. Управление жизненным циклом доступов. Возможность выдавать, отзывать, устанавливать срок жизни и перевыпускать или продлять доступы. Аудит доступа к секретам. Чем меньше 'размазанность' по системе, тем лучше. Отсутствие единой точки отказа. Удобная работа с секретами для людей и автоматических систем. Минимум времени на обучение и внедрение новых инструментов. Примерим наши требования к возможным решениям: Хранение в репозитории любом: Нет гибкой настройки доступов к секретам. Доступ бинарен — либо есть, либо нет. Есть решения этой проблемы: Проблемы начинаются там, где появляется автоматизация. Нет поддержки полного жизненного цикла доступа. Вы не можете дать временный доступ. Вы не можете отозвать доступ к секретам можете только сменить доступы к репозиторию и сами секреты в нём. Отсутствие регулярного процесса обновления доступов уменьшает прозрачность. Хранение в системе деплоя: Если вы используете Jenkins, то секреты можно вытащить на уровне сервера. Ручное подкладывание секретов на сервера: Если секрет хранится только на одном сервере — потеря сервера грозит потерей секрета. Но этот способ можно использовать, когда у вас немного серверов и сервисов. С ростом инфраструктуры вас ждёт удорожание обслуживания процесса управления секретами. Все данные хранятся в зашифрованном контейнере. Получение самого контейнера не раскрывает данные. Вы можете создать столько токенов для доступа и управления секретами, сколько вам нужно. Возможность аудирования доступа к секретам. Поддерживается автоматическая генерация секретов для нескольких популярных баз данных postgresql, mysql, mssql, cassandra , для rabbitmq, ssh и для aws. Поддержка шифрования-дешифрования данных без их сохранения. Это может быть удобно для передачи данных в зашифрованном виде по незащищённым каналам связи. Поддержка полного жизненного цикла секрета: Уберфича, значимость которой сложно переоценить, это возможность создания собственного CA Certificate Authority для управления самоподписанными сертификатами внутри своей инфраструктуры. Начало работы Не буду переводить официальную документацию, поэтому вот несколько ссылок: Getting started можно пройти вот тут. Вот ещё одна прекрасная статья. Официальный процесс работы выглядит так: Для каждого сервиса создаём отдельный мастер-токен. Переключаемся на этот токен и создаём секрет. Выпускаем новый токен для чтения этого секрета. Скармливаем этот токен нашей системе автоматизации … PROFIT!!! О мастер-токене для каждого сервиса Оказалось неудобным постоянно переключать токены, если ты отвечаешь за несколько сервисов. Про особенности управления политиками доступа Они описываются в формате JSON или HCL и записываются в Vault с помощью запроса к API или через cli. Это означает, что если вы сделаете root политику вида: Error making API request. Об учёте и обновлении токенов В документации к Vault зря не сказано о важности учёта выпущенных токенов. Это означает, что если вы создали токен со сроком жизни в 30 дней и максимальный срок жизни тоже 30 дней, то обновить вы его не сможете. Список политик изменить невозможно, возможно только отозвать токен и пересоздать заново. Неочевидности и полезности Если токен был родительским для других токенов, то по умолчанию при отзыве этого токена все токены и секреты, созданные отзываемым токеном, отзываются рекурсивно. Более подробно vault token-revoke -h Если вы будете использовать consul-template для автоматической перегенерации конфигов при изменении секретов, имейте в виду и этого вы не найдёте в документации , что consul-template опрашивает изменение секрета в двух случаях: Старт или рестарт самого consul-template. Количество ключей для распечатки хранилища: Дать возможность распечатать хранилище одному человеку — риск, потому что при компрометации этого ключа или ключей злоумышленники получат доступ к хранилищу но пока не к секретам. Надо понимать, что если вы не наберёте необходимый минимум ключей для распечатывания хранилища, доступ к данным будет утерян. Мы решили, что нам достаточно 4 владельцев ключей и 2 ключей для расшифровки. Root токены и их роль в системе: Официальная позиция Hashicorp — использовать эти токены только для управления политиками, ролями, настройками системы и для выдачи токенов для сервисов. Но чем меньше таких ключей в системе, тем больше всё завязывается на определённых людей, которые болеют, ходят в отпуск, в общем — бывают недоступны. Мы начали с 4 root-ключей на группу из 7 человек. Это было неудобно, поэтому мы в первый раз отступили от официального процесса — выдали root-токены всем инженерам эксплуатации и перестали создавать мастер-токены для управления секретами сервиса. Все операции производятся под root-токенами. Создаются только read-only токены. Учёт ключей и мониторинг их времени жизни: По-умолчанию максимальный срок жизни НЕ root токена равен 30 дням. Мы ведём учёт accessor-ключей для токенов с помощью репозитория — и это неудобно. Зато позволило настроить мониторинг, который сообщает об истечении срока жизни ключей за 5 дней. В планах завести небольшой сервис для учёта ключей и написать небольшую обёртку для автоматизации некоторых действий с токенами например, автоматическую запись вновь созданного токена в сервис. Вернёмся к хранению секрета от базы данных Мы установили и запустили Vault, получили root-токен. Проверим, что есть доступ на чтение: Необходимо либо иметь токен и адрес Vault в переменных окружения: Готов ответить на ваши вопросы. Системное администрирование 1,1k авторов , 2,2k публикаций. IT-инфраструктура авторов , 1,2k публикаций. Серверное администрирование авторов , публикаций. Резервное копирование 84 автора , публикаций. Настройка Linux 1,4k авторов , 2,7k публикаций. Восстановление данных 88 авторов , публикаций. Виртуализация автора , публикаций. Серверная оптимизация 87 авторов , публикаций. Администрирование доменных имен автора , публикаций. Лог файлы Linux по порядку 6,8k Добавить в закладки Дмитрий Зайцев bhavenger карма. Сутки Неделя Месяц WI-FI в метро: C, PetrWrap или PetyaCry? ИМХО для столь серьёзного подхода сама идея иметь общие секреты порочна. Более правильно — индивидуальные учетки и централизованная система управления ими. Ну и RBAC разумеется для каждого сервиса. Сколько не смотрел в сторону разных хранилищ секретов для доступа к сервисам, всё равно клиенту нужен секрет для доступа к хранилищу секретов, который надо хранить рядом с клиентгм. Чего я не понимаю? Без gui можно построить, используя Pass обертка на строчек вокруг GPG и Git. Автор, спасибо за материал! Недавно слышал положительные отзывы знакомых о данном продукте, а сейчас ваша статья освещает общие детали его использования. Мало смысла делать отличным от 1. Админ с root доступом к машине на которой крутится unsealed vault может легко вытащить master key. Если кто-то получил доступ к данным хранилища, то без распечатывающего ключа они ничего с ними не сделают. Метки лучше разделять запятой. Сейчас Вчера Неделя Резервное копирование томов LVM2 с защитой от перегрузок IO с использованием сигналов SIGSTOP, SIGCONT 1k 8. Снимаем и вносим наличные в банкомате с помощью смартфона. Впервые в мире 11k Три дня как все кассы в стране должны стать онлайн на самом деле нет 40,4k Интересные публикации Хабрахабр Geektimes. Астробиологи из Эдинбургского университета считают, что жизни на Марсе нет из-за токсичных химических соединений GT. Нейросети диагностируют проблемы с сердцем более точно, чем врачи GT. За какие заслуги Kingston любят центры обработки данных? Вещи, которые мне надо было знать прежде, чем создавать систему с очередью. Обработка многократно возникающих SIGSEGV-подобных ошибок. Выбор алгоритма вычисления квантилей для распределённой системы. Как у Словакии украли национальный домен верхнего уровня. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.

Ничего не найдено

Где хранятся мои логины?

Цветаева стихи о море

Miss them перевод

Где лучше хранить доступы клиентов?

Для хранения криптовалюты используется биткоин-клиент например, Armory , Electrum , обеспечивающий качественную шифровку и защиту кошелька паролем. Дополнительно на компьютер устанавливается обновленное программное обеспечение, в том числе хороший антивирус. Однако хранение валюты на компьютере не удобно ввиду громоздкости программного обеспечения системы Bitcoin и ее сложности для понимания неопытным пользователем. А при создании виртуальной машины не исключается риск потери жесткого диска в результате перепадов напряжения, например. Безопасность кошелька, содержащего большое число криптовалюты ВТС , значительно повышается при условии, что:. Надежный оффлайн — кошелек можно выбрать на официальном сайте Bitcoin. Копии кошелька размещаются на различных носителях съемного типа, включая флеш-накопители CD-R, DVD и USB, которые помещаются в сейф или банковскую ячейку, например. В результате легко восстановить содержимое кошелька и необходимые настройки в случае повреждения системы или выхода из строя самого компьютера. Но у пользователей, не разбирающихся в тонкостях программного обеспечения системы биткоин, могут возникать сложности с нахождением файла wallet. Содержащая его папка обычно скрыта при использовании Windows, а для ее восстановления требуется опыт работы с командной строкой. Сторонние онлайн ресурсы используются в основном для хранения небольшого числа виртуальных монет, доступ к которым прост и оперативен. Чтобы воспользоваться кошельком достаточно наличия мобильного устройства. Нет необходимости в сложном программном обеспечении системы биткоин. Коды и пароли к хранилищам средств подбираются с использованием генераторов паролей, чтобы последние были, как можно сложнее. Выбрать биржу для выполнения операций и хранения биткоинов можно выбрать среди крупнейших бирж. Наиболее крупными считаются следующие биржи: Gox , Bitstamp , BTC-E , Kraken , BTCChina. Однако с личной анонимностью пользователям придется расстаться ввиду требований законодательства: Желательно использовать не одно хранилище, держа монеты в нескольких корзинах. Биткоин не имеет статуса валюты в РФ, поэтому ее нельзя вернуть в судебном порядке. Она представляется в виде QR-кода , считывая который, ключи и адреса можно импортировать в биткоин-клиент на компьютер и получить доступ к виртуальным средствам. Хранить кошелек на бумаге безопасно и надежно, если поместить ее в банковскую ячейку, например. Однако процедура импорта ключей и адресов достаточно сложна для неопытных пользователей. В случае неудачи можно лишиться денег. Они содержат QR-код на лицевой стороне и Bitcoin-адрес — на тыльной. QR-код наносится на карту при использовании данных кошелька, зашифрованного на компьютере пользователя, и физически не может быть доступен изготовителю карты. Пространства имён Статья Обсуждение. Просмотры Читать Просмотр История. Навигация Заглавная страница Свежие правки Случайная статья. Инструменты Ссылки сюда Связанные правки Спецстраницы Версия для печати Постоянная ссылка Сведения о странице. Последнее изменение этой страницы: Политика конфиденциальности Описание Bitcoin Wiki Отказ от ответственности.

Схема обвязки арматуры для ленточного фундамента

Rechnung перевод с немецкого