Консультация по поводу стабильной архитектуры веб-приложения (DevOps)

Необходимо развернуть open-source платформу банковского учета Apache Fineract на VPS (AWS Free Tier, Ubuntu OS) через Docker-compose, настроить базу данных и провести демонстрацию базовых функций.Основные задачи:Установить Docker и Docker Compose на предоставленный сервер AWS (Ubuntu).Развернуть официальный образ Apache Fineract и СУБД (MySQL/MariaDB).Настроить перенаправление портов и проверить работу REST API и веб-интерфейса (Community App).Создать учетную запись Суперадминистратора.Предоставить короткий текстовый мануал или провести короткий созвон/видео с демонстрацией выполнения следующих сценариев в системе:Создание клиента, открытие счета, депозит и снятие средств;Механизм внутренних P2P переводов и межбанковских транзакций;Навигация по бухгалтерскому модулю (General Ledger) и плану счетов;Просмотр аудит-логов (списания/потери средств) и процедура возврата (chargeback/refund).Результат работы:Работающая система с доступом по SSH и Admin-панели, короткий мануал/видео с демонстрацией 6 бизнес-сценариев.

Мы ищем специалиста по DEVOPS / OPSEC, чтобы оценить нашу текущую настройку проекта с точки зрения оптимизации софта и безопасности.

Кто может помочь настроить такой сетап: Планирую развернуть сервер, который будет параллельно работать с 4–5 разными AI-моделями для задач по программированию. Ключевое требование — многопользовательский доступ: несколько разработчиков смогут пользоваться сервером одновременно, каждый в изолированной сессии и со своими агентами. Модели Claude / GPT / Kimi k3

В рамках повышения уровня кибербезопасности нашей инфраструктуры нам необходимо отказаться от практики хранения «вечных» и статичных API-ключей, паролей и токенов интеграций в конфигурационных файлах (.env, appsettings.json, config.yaml) наших микросервисов. Бизнес-цель: Создать единую защищенную точку хранения конфиденциальных данных (секретов) с механизмом их автоматического обновления (ротации) во внешних системах по расписанию. Другие наши сервисы будут запрашивать актуальные токены «на лету» через API, что сведет к минимуму ущерб в случае компрометации любого из компонентов системы.Модель безопасности и шифрование (Crypto Core) В базе данных ни один секрет не должен храниться в открытом виде. При старте приложения в переменные окружения передается Мастер-ключ (Master Key). Если ключ отсутствует или имеет невалидную длину, сервис должен падать на этапе инициализации с понятной ошибкой в логах. Каждый секрет шифруется перед записью в БД с использованием этого Мастер-ключа. При запросе — расшифровывается в памяти и отдается в теле ответа.Аудит-логирование (Audit Trail) Любое действие с секретами (создание, чтение сервисом, успешная или неуспешная ротация) должно записываться в отдельный лог-файл audit.log (или отдельную таблицу в БД). Строгое табу: В аудит-лог категорически запрещено записывать сами значения секретов (ни в открытом, ни в зашифрованном виде).