Использую HashiCorp Vault для хранения секретов. Приложение аутентифицируется в Vault с помощью токена и получает необходимые секреты.
Интересует практический и архитектурный подход к безопасному хранению токена Vault на стороне приложения.
Предположим, что:
токен уже необходим приложению для работы;
злоумышленник получил доступ к хосту, на котором работает приложение;
запросы к Vault могут выполняться с того же хоста и от имени того же процесса/пользователя, поэтому ограничения по IP, сетевому расположению и аналогичные меры не рассматриваются как решение задачи;
вопрос не про настройку политик доступа Vault, а именно про защиту самого токена.
Какие существуют способы хранения и использования Vault-токена, чтобы максимально снизить риск его компрометации? Какие подходы считаются лучшей практикой: аппаратные модули безопасности (HSM/TPM), динамическая аутентификация, AppRole, Kubernetes Auth, облачные IAM-механизмы, получение краткоживущих токенов и т.д.?
Где проходит граница, после которой защита токена становится невозможной, поскольку приложение в любом случае должно иметь возможность предъявить его Vault для получения секретов?
Существует ли вообще способ надежно защитить Vault-токен от извлечения злоумышленником, если приложение способно использовать этот токен для получения секретов, а злоумышленник имеет доступ к тому же хосту и может выполнять код в том же контексте безопасности? Если нет, то какие механизмы используются на практике для минимизации ущерба от компрометации такого токена?
А вот если у меня множество форков одного процесса и напротив каждого форка указано в поле MEM% одно и тоже число(25,5), это как понимать? Это потребление всех процессов в сумме или каждого по отдельности?
Что то не увидел веб-интерфейса proxmox, процесс установки на alt - полезен, спасибо автору, а вот зачем мне gui (lxde) на сервере - я не понял, у нас же в сервак только пачкорд воткнут и кабель питания? Как тачки создать я тоже пока не понял, думаю в следующей статье будет описано? Спасибо!
Прикрутите уже оплату по QR-кодам? Сколько можно это терпеть?
Контейнеризация - это изоляция процесса или процессов, виртуализация - это эмуляция физического железа.
Использую HashiCorp Vault для хранения секретов. Приложение аутентифицируется в Vault с помощью токена и получает необходимые секреты.
Интересует практический и архитектурный подход к безопасному хранению токена Vault на стороне приложения.
Предположим, что:
токен уже необходим приложению для работы;
злоумышленник получил доступ к хосту, на котором работает приложение;
запросы к Vault могут выполняться с того же хоста и от имени того же процесса/пользователя, поэтому ограничения по IP, сетевому расположению и аналогичные меры не рассматриваются как решение задачи;
вопрос не про настройку политик доступа Vault, а именно про защиту самого токена.
Какие существуют способы хранения и использования Vault-токена, чтобы максимально снизить риск его компрометации? Какие подходы считаются лучшей практикой: аппаратные модули безопасности (HSM/TPM), динамическая аутентификация, AppRole, Kubernetes Auth, облачные IAM-механизмы, получение краткоживущих токенов и т.д.?
Где проходит граница, после которой защита токена становится невозможной, поскольку приложение в любом случае должно иметь возможность предъявить его Vault для получения секретов?
Существует ли вообще способ надежно защитить Vault-токен от извлечения злоумышленником, если приложение способно использовать этот токен для получения секретов, а злоумышленник имеет доступ к тому же хосту и может выполнять код в том же контексте безопасности? Если нет, то какие механизмы используются на практике для минимизации ущерба от компрометации такого токена?
Тебе Яндыкс какую нибудь доставку накинет и будет все 1400)
А подскажите, когда ожидать электронную версию Go на практике. 2-е изд.?
Нафига, а главное зачем?
А с правовой т.з. если случится ДТП на перекрестке, можно будет 2ГИС привлечь за ложные данные в навигаторе?)
А кто нибудь разбирал данное устройство, можно где то увидеть внутренности?
А в PPEM есть мененджер РК, могу я создавать РК и восстанавливать БД из РК?
Кстати repo.saltproject.io переехал на packages.broadcom.com 31.10.2024.
А вот если у меня множество форков одного процесса и напротив каждого форка указано в поле MEM% одно и тоже число(25,5), это как понимать? Это потребление всех процессов в сумме или каждого по отдельности?
Что то не увидел веб-интерфейса proxmox, процесс установки на alt - полезен, спасибо автору, а вот зачем мне gui (lxde) на сервере - я не понял, у нас же в сервак только пачкорд воткнут и кабель питания? Как тачки создать я тоже пока не понял, думаю в следующей статье будет описано? Спасибо!
Нам нужно развивать свои компитенции, и свое производство.
А UI какой-то есть, нигде не видел скринов интерфейса.
Потому что разработчики пишут на эльфийском языке(разработчики пишут для разработчиков).
ну ломанут их разочек, утекут в сеть исходники и вся эта модель пойдет по одному месту... а сколько убытков будет...
Не используйте технику "бережливого производства", она не работает в России и СНГ - совсем.
Возьми и сделай.
Кто то же должен заработать на производстве этой маркировки)
Солнечные панели нужны будут для подсветки обозначений пожарной эвакуации?