Безопасность

Раздел описывает правила защиты Energoskan Development Portal: управление доступом, хранение секретов, сетевую безопасность, изоляцию проектов, резервное копирование, аудит и действия при инцидентах.

Основные принципы

1. Предоставлять только минимально необходимые права.
2. Разделять пользовательские и административные функции.
3. Не хранить секреты в исходном коде.
4. Не открывать внутренние службы во внешнюю сеть без необходимости.
5. Создавать резервную копию перед критическими изменениями.
6. Проверять журналы после каждого изменения.
7. Документировать доступы, интеграции и инциденты.

Роли пользователей

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

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

Административный доступ

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

Необходимо контролировать:

• создание и удаление пользователей;
• изменение ролей;
• выдачу доступа к проектам;
• настройку AI-провайдеров;
• изменение системной конфигурации;
• доступ к журналам и резервным копиям.

Пароли и сессии

• Пароли не должны храниться в открытом виде.
• Для хранения паролей необходимо использовать стойкое хеширование.
• Сессии должны иметь ограниченный срок действия.
• После смены пароля старые сессии рекомендуется завершать.
• Cookie авторизации должны использовать параметры HttpOnly и Secure.
• Для изменяющих запросов необходима защита от CSRF.

Секреты и токены

К секретам относятся:

• пароли;
• ключи API;
• OAuth-токены;
• SSH-ключи;
• ключи приложений Bitrix24;
• токены AI-провайдеров;
• закрытые ключи сертификатов.

Секреты запрещено размещать:

• в Git-репозитории;
• в HTML и клиентском JavaScript;
• в публичных журналах;
• в документации портала;
• в сообщениях и скриншотах без маскирования.

Проверка исключения файлов:

git check-ignore .env
git status --short
find /opt/dev-portal -maxdepth 3 -name '.env*' -ls

Права файлов

Конфигурации с секретами должны быть доступны только владельцу или системной службе, которой они необходимы.

chmod 600 /путь/к/секретному-файлу
chown root:root /путь/к/секретному-файлу
stat /путь/к/секретному-файлу

Не следует массово назначать права 777 каталогам или файлам портала.

HTTPS

Внешний доступ к порталу должен выполняться только по HTTPS. HTTP используется только для перенаправления на защищённый адрес.

curl -I http://energoskandev.ru/
curl -I https://energoskandev.ru/
certbot certificates

Сетевая безопасность

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

Панель: 127.0.0.1:3020
Nginx:  80 и 443
Shim:   внутренний адрес и порт
Privoxy: 127.0.0.1:8118

Проверка портов:

ss -lntp
docker ps --format 'table {{.Names}}\t{{.Ports}}'

Docker-изоляция

• Проекты разных пользователей должны храниться раздельно.
• Контейнеру следует выдавать только необходимые каталоги.
• Не следует монтировать весь серверный корень в пользовательский контейнер.
• Не следует передавать контейнеру Docker socket без обоснованной необходимости.
• В контейнерах не должны находиться общие секреты портала.
• Открытые порты контейнера должны быть ограничены.

Безопасность AI-интеграций

Пользовательские расширения и проекты не должны получать реальные токены AI-провайдеров. Запросы следует передавать через контролируемый серверный шлюз.

Пользовательский инструмент
        ↓
Anthropic Shim
        ↓
Прокси и контроль доступа
        ↓
AI-провайдер

Шлюз должен контролировать:

• авторизацию пользователя;
• разрешённого провайдера и модель;
• лимиты запросов;
• тайм-ауты;
• ошибки провайдера;
• безопасное журналирование без токенов.

Резервное копирование

Критически важные объекты:

• /opt/dev-portal;
• /data/vibe-students;
• /data/config;
• конфигурации Nginx и systemd;
• данные авторизации;
• рабочие проекты;
• закрытые конфигурации интеграций.

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

Журналирование и аудит

Следует фиксировать:

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

Пароли, ключи и полные токены в журналы записывать запрещено.

Проверка безопасности

systemctl --failed
ss -lntp
docker ps -a
git status --short
journalctl -p err -n 100 --no-pager
find /opt/dev-portal -type f -perm -0002 -ls

Действия при инциденте

1. Ограничить или отключить скомпрометированный доступ.
2. Сохранить журналы и текущее состояние системы.
3. Не удалять следы инцидента до завершения анализа.
4. Определить затронутые аккаунты, проекты и интеграции.
5. Отозвать токены и сменить пароли.
6. Устранить причину инцидента.
7. Проверить восстановление из резервной копии.
8. Зафиксировать причины, действия и результат.

Правила администратора

1. Не передавать административный аккаунт другим пользователям.
2. Не публиковать секреты в Git, чатах и документации.
3. Не выдавать права шире, чем требуется для задачи.
4. Не отключать HTTPS и проверку авторизации.
5. Не изменять безопасность без резервной копии.
6. После изменения проверять доступы, порты и журналы.
7. При подозрении на компрометацию немедленно отзывать токены.