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

Доброго дня. На сервер проник вірус blackfl та зашифрував файли. Потрібно його видалити та нормалізувати роботу сервера.

Необхідно розгорнути 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, щоб переглянути нашу поточну налаштування проекту з боку оптимізації soc та безпеки.

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

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