Требование ЦБ: 5 лет хранения логов для процессингового центра на 200 устройств

Задача клиента: процессинговый центр и требования регулятора

В марте 2026 года к нам обратился процессинговый центр ФинПроцесс из Москвы. Компания обрабатывает платёжные транзакции для 15 банков-партнёров и проводит около 2 миллионов операций в сутки. Инфраструктура — более 200 устройств: серверы, сетевое оборудование, системы безопасности, HSM-модули и платёжные шлюзы.

Причиной обращения стала плановая проверка Банка России. Регулятор предъявляет жёсткие требования к хранению логов: согласно Положению ЦБ РФ № 683-П и стандарту ГОСТ Р 57580.1, все события информационной безопасности должны храниться не менее 5 лет в неизменяемом виде с возможностью оперативного поиска.

«На проверке нас попросили показать логи входа администраторов за январь 2023 года. Мы искали два часа и нашли только часть — остальное было перезаписано ротацией. Нам выписали предписание с дедлайном в 90 дней» — начальник службы ИБ ФинПроцесс.

На момент обращения логи хранились локально на каждом сервере с ротацией через logrotate (обычно 4 недели), без централизации и без шифрования при передаче. Это не соответствовало ни требованиям ЦБ, ни PCI DSS (стандарт для процессинга карт).

Аудит текущей системы логирования

Мы обследовали инфраструктуру и составили карту устройств:

Тип устройствКол-воОС / ПлатформаОбъём логов/сутки
Linux-серверы (приложения)65RHEL 8/9, Ubuntu 22.04~50 ГБ
Windows-серверы (AD, SQL)20Windows Server 2019/2022~15 ГБ
Сетевое оборудование45Cisco IOS, Juniper JunOS~10 ГБ
Межсетевые экраны8Cisco ASA, FortiGate~30 ГБ
HSM / платёжные шлюзы12Специализированные~5 ГБ
Системы контроля доступа15Linux embedded~2 ГБ
Баз данных (PostgreSQL, MS SQL)10Linux / Windows~20 ГБ
Прочие (DNS, NTP, backup)25+Разные~8 ГБ

Итого: ~140 ГБ логов в сутки, или около 50 ТБ в год. За 5 лет — ~250 ТБ. Это серьёзный объём, требующий продуманной архитектуры хранения с разделением на «горячий» (быстрый поиск) и «холодный» (долгосрочный архив) уровни.

Дополнительная сложность — разнородность источников. Linux-серверы отправляют syslog, Windows — Event Log, сетевое оборудование Cisco и Juniper — свои форматы syslog, межсетевые экраны FortiGate — CEF (Common Event Format). Все эти форматы нужно было привести к единому виду для поиска и корреляции событий.

Проектирование архитектуры

Мы спроектировали трёхуровневую систему:

# Архитектура централизованного сбора логов

┌──────────────────────────────────────────────────────┐
│                    200+ устройств                     │
│  [Linux] [Windows] [Network] [Firewall] [HSM] [DB]   │
│     │        │         │         │        │      │    │
│     └────────┴────┬────┴─────────┴────────┴──────┘    │
│                   │ Rsyslog / Syslog (TLS)            │
│                   ▼                                    │
│  ┌─────────────────────────────────┐                  │
│  │    Rsyslog Relay (2 ноды, HA)   │  ← Уровень 1    │
│  │    Буферизация, фильтрация      │    Приём         │
│  └────────────────┬────────────────┘                  │
│                   │ RELP (TCP, reliable)               │
│                   ▼                                    │
│  ┌─────────────────────────────────┐                  │
│  │        Graylog Cluster          │  ← Уровень 2    │
│  │   (3 ноды: Graylog+ES+Mongo)   │    Обработка     │
│  │   Streams, Pipelines, Alerts    │                  │
│  └────────────────┬────────────────┘                  │
│                   │                                    │
│                   ▼                                    │
│  ┌─────────────────────────────────┐                  │
│  │    Холодное хранилище (NAS)     │  ← Уровень 3    │
│  │    S3-compatible (MinIO)        │    Архив 5 лет   │
│  │    WORM (Write Once Read Many)  │                  │
│  └─────────────────────────────────┘                  │
└──────────────────────────────────────────────────────┘

Ключевые принципы:

  • TLS-шифрование — все логи передаются по зашифрованному каналу (требование ЦБ)
  • Надёжная доставка — RELP протокол с подтверждением приёма (нет потерь сообщений)
  • Горячее хранилище — 90 дней в Elasticsearch (быстрый поиск)
  • Холодное хранилище — 5 лет в MinIO с WORM-политикой (неизменяемость)

Настройка Rsyslog: клиенты и relay-серверы

Rsyslog — стандартный syslog-демон в большинстве Linux-дистрибутивов. Мы настроили его на всех устройствах для отправки логов на центральные relay-серверы.

Генерация TLS-сертификатов

Первым шагом мы создали внутренний CA для подписи сертификатов syslog:

# Создание корневого CA
mkdir -p /etc/pki/rsyslog && cd /etc/pki/rsyslog

# Генерация ключа CA
openssl genrsa -out ca-key.pem 4096

# Самоподписанный сертификат CA (10 лет)
openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem \
  -subj "/C=RU/ST=Moscow/O=FinProcess/CN=Syslog CA"

# Генерация ключа и CSR для relay-сервера
openssl genrsa -out relay-key.pem 2048
openssl req -new -key relay-key.pem -out relay.csr \
  -subj "/C=RU/ST=Moscow/O=FinProcess/CN=syslog-relay.finprocess.local"

# Подпись сертификата relay-сервера
openssl x509 -req -days 1825 -in relay.csr \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out relay-cert.pem

# Генерация клиентских сертификатов (скрипт для массового выпуска)
for host in app-srv-{01..65} db-srv-{01..10} mon-srv-{01..03}; do
    openssl genrsa -out "${host}-key.pem" 2048
    openssl req -new -key "${host}-key.pem" -out "${host}.csr" \
      -subj "/C=RU/ST=Moscow/O=FinProcess/CN=${host}.finprocess.local"
    openssl x509 -req -days 1825 -in "${host}.csr" \
      -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
      -out "${host}-cert.pem"
    rm "${host}.csr"
done

Конфигурация Rsyslog relay-сервера

Relay-серверы принимают логи от всех устройств, буферизуют их и надёжно передают в Graylog:

# /etc/rsyslog.d/10-relay.conf (на обоих relay-нодах)

# Модули
module(load="imtcp")
module(load="imudp")     # Для устройств без TLS (коммутаторы)
module(load="omrelp")    # Reliable Event Logging Protocol

# TLS-параметры
global(
    defaultNetstreamDriverCAFile="/etc/pki/rsyslog/ca-cert.pem"
    defaultNetstreamDriverCertFile="/etc/pki/rsyslog/relay-cert.pem"
    defaultNetstreamDriverKeyFile="/etc/pki/rsyslog/relay-key.pem"
)

# Приём по TCP с TLS (порт 6514)
input(type="imtcp"
    port="6514"
    StreamDriver.Name="gtls"
    StreamDriver.Mode="1"
    StreamDriver.AuthMode="x509/name"
    PermittedPeer=["*.finprocess.local"]
)

# Приём по UDP (514) для сетевого оборудования без TLS
input(type="imudp" port="514")

# Дисковая очередь (буфер при недоступности Graylog)
$WorkDirectory /var/spool/rsyslog

# Пересылка в Graylog через RELP
action(
    type="omrelp"
    target="graylog-input.finprocess.local"
    port="5140"
    tls="on"
    tls.caCert="/etc/pki/rsyslog/ca-cert.pem"
    tls.myCert="/etc/pki/rsyslog/relay-cert.pem"
    tls.myPrivKey="/etc/pki/rsyslog/relay-key.pem"
    tls.authMode="name"
    tls.permittedPeer=["graylog-input.finprocess.local"]
    queue.type="LinkedList"
    queue.filename="relay-to-graylog"
    queue.maxDiskSpace="10g"
    queue.saveOnShutdown="on"
    action.resumeRetryCount="-1"
    action.resumeInterval="10"
)

Дисковая очередь queue.maxDiskSpace="10g" — страховка: если Graylog недоступен, relay накопит до 10 ГБ логов на диске и автоматически доставит их при восстановлении связи. При 140 ГБ/сутки это примерно 1,5 часа буферизации.

Для отказоустойчивости мы развернули два relay-сервера в конфигурации active-active. Каждый клиент отправляет логи на оба relay через два action-блока с разными приоритетами. Если основной relay недоступен, rsyslog автоматически переключается на резервный благодаря параметру action.resumeRetryCount. При восстановлении основного relay — переключение обратно.

Мы также настроили фильтрацию на уровне relay: логи уровня DEBUG от приложений не пересылались в Graylog (только в локальные файлы), что снизило нагрузку на центральное хранилище на 15–20%.

Конфигурация Rsyslog-клиентов

На каждом Linux-сервере мы развернули единую клиентскую конфигурацию через Ansible:

# /etc/rsyslog.d/50-remote.conf (клиентская конфигурация)

module(load="imfile")

# TLS-параметры
global(
    defaultNetstreamDriverCAFile="/etc/pki/rsyslog/ca-cert.pem"
    defaultNetstreamDriverCertFile="/etc/pki/rsyslog/client-cert.pem"
    defaultNetstreamDriverKeyFile="/etc/pki/rsyslog/client-key.pem"
)

# Системные логи → relay (TLS)
*.* action(
    type="omfwd"
    target="syslog-relay-01.finprocess.local"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="syslog-relay-01.finprocess.local"
    queue.type="LinkedList"
    queue.filename="fwd-to-relay"
    queue.maxDiskSpace="1g"
    queue.saveOnShutdown="on"
    action.resumeRetryCount="-1"
)

# Логи приложений (файловые)
input(type="imfile"
    File="/var/log/finprocess/transaction.log"
    Tag="finprocess-tx"
    Severity="info"
    Facility="local0"
    PersistStateInterval="100"
)

input(type="imfile"
    File="/var/log/finprocess/auth.log"
    Tag="finprocess-auth"
    Severity="info"
    Facility="local1"
)

Для Windows-серверов мы использовали NXLog — syslog-агент для Windows, который отправляет Windows Event Log по TLS:

# nxlog.conf (на Windows-серверах)

    Module    im_msvistalog
    Query     \
              \
              \
              \
              



    Module    om_ssl
    Host      syslog-relay-01.finprocess.local
    Port      6514
    CAFile    C:\certs\ca-cert.pem
    CertFile  C:\certs\client-cert.pem
    CertKeyFile C:\certs\client-key.pem
    OutputType Syslog_TLS

Graylog: установка кластера и обработка логов

Graylog — платформа для централизованного управления логами, построенная на MongoDB (конфигурация) и Elasticsearch/OpenSearch (индексирование и поиск). Мы развернули кластер из трёх нод для отказоустойчивости.

Развёртывание Graylog кластера

Каждая нода содержала все три компонента для простоты администрирования:

# Установка OpenSearch 2.x (замена Elasticsearch) на каждой ноде
# OpenSearch — форк Elasticsearch от Amazon, полностью совместим с Graylog

sudo apt install -y openjdk-17-jre-headless

# Добавление репозитория OpenSearch
curl -o- https://artifacts.opensearch.org/publickeys/opensearch.pgp | sudo gpg --dearmor -o /usr/share/keyrings/opensearch.gpg
echo "deb [signed-by=/usr/share/keyrings/opensearch.gpg] https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch.list
sudo apt update && sudo apt install -y opensearch

# Конфигурация OpenSearch кластера
# /etc/opensearch/opensearch.yml (нода 1)
cluster.name: graylog-cluster
node.name: graylog-node-1
network.host: 10.0.5.31
discovery.seed_hosts:
  - 10.0.5.31
  - 10.0.5.32
  - 10.0.5.33
cluster.initial_master_nodes:
  - graylog-node-1
  - graylog-node-2
  - graylog-node-3
path.data: /data/opensearch
path.logs: /var/log/opensearch
plugins.security.disabled: true  # Безопасность на уровне Graylog

# Установка MongoDB 7.0
curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg
echo "deb [signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
sudo apt update && sudo apt install -y mongodb-org

# Установка Graylog 6.0
wget https://packages.graylog2.org/repo/packages/graylog-6.0-repository_latest.deb
sudo dpkg -i graylog-6.0-repository_latest.deb
sudo apt update && sudo apt install -y graylog-server

Streams и маршрутизация логов

Streams в Graylog — это правила маршрутизации, которые направляют сообщения в разные категории с разными политиками хранения:

# Streams в Graylog (настраиваем через веб-интерфейс или API)

# Stream 1: Безопасность (хранение 5 лет — требование ЦБ)
curl -X POST http://localhost:9000/api/streams \
  -H 'Content-Type: application/json' \
  -u admin:password \
  -d '{
    "title": "Security Events",
    "description": "События ИБ — хранение 5 лет (ЦБ РФ 683-П)",
    "rules": [
      {"field": "facility", "value": "auth", "type": 1, "inverted": false},
      {"field": "facility", "value": "authpriv", "type": 1, "inverted": false},
      {"field": "tag", "value": "finprocess-auth", "type": 6, "inverted": false}
    ],
    "matching_type": "OR",
    "index_set_id": "security-5y-index-set"
  }'

# Stream 2: Транзакции (хранение 5 лет — PCI DSS)
# → Все сообщения с tag=finprocess-tx

# Stream 3: Сетевое оборудование (хранение 1 год)
# → Все сообщения от source=10.0.0.0/24 (сетевой сегмент)

# Stream 4: Приложения (хранение 90 дней)
# → Все остальные сообщения

Pipelines для обогащения данных

Graylog Pipelines позволяют трансформировать и обогащать логи «на лету»:

# Pipeline: Обогащение Security Events

# Stage 0: Парсинг
rule "parse sshd logs"
when
  has_field("message") AND contains(to_string($message.message), "sshd")
then
  let parsed = grok(
    pattern: "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:src_host} sshd\[%{INT:pid}\]: %{DATA:action} %{DATA:auth_method} for %{USER:username} from %{IP:src_ip} port %{INT:src_port}",
    value: to_string($message.message)
  );
  set_fields(parsed);
end

# Stage 1: Обогащение GeoIP
rule "geoip enrichment"
when
  has_field("src_ip")
then
  let geo = lookup("geoip-db", to_string($message.src_ip));
  set_field("src_country", geo["country"]);
  set_field("src_city", geo["city"]);
end

# Stage 2: Классификация критичности
rule "severity classification"
when
  has_field("action") AND to_string($message.action) == "Failed"
then
  set_field("security_event", "AUTH_FAILURE");
  set_field("risk_level", "MEDIUM");
  
  # Если 5+ неудачных попыток за 5 минут — HIGH
  let count = lookup("rate-limiter", concat(to_string($message.src_ip), "-auth-fail"));
  set_field("fail_count", count);
  
  route_to_stream(name: "Security Events");
end

Политика хранения и архивирование

Главное требование регулятора — 5 лет хранения с возможностью поиска. Мы реализовали двухуровневую систему: горячее хранение в OpenSearch и холодный архив в MinIO.

Index Sets и ротация в Graylog

Для каждого типа данных мы создали отдельный Index Set с настроенной ротацией:

# Index Set: security-5y (через Graylog API)
curl -X POST http://localhost:9000/api/system/indices/index_sets \
  -H 'Content-Type: application/json' \
  -u admin:password \
  -d '{
    "title": "Security Events — 5 лет",
    "description": "События ИБ, compliance ЦБ РФ",
    "index_prefix": "security",
    "shards": 3,
    "replicas": 1,
    "rotation_strategy_class": "org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy",
    "rotation_strategy": {
      "type": "org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategyConfig",
      "rotation_period": "P1M"
    },
    "retention_strategy_class": "org.graylog2.indexer.retention.strategies.NoopRetentionStrategy",
    "retention_strategy": {
      "type": "org.graylog2.indexer.retention.strategies.NoopRetentionStrategyConfig",
      "max_number_of_indices": 60
    },
    "index_analyzer": "standard",
    "field_type_refresh_interval": 5000
  }'

Стратегия хранения:

Index SetРотацияГорячее (OpenSearch)Холодное (MinIO)
security-5yЕжемесячно12 месяцев5 лет (WORM)
transactions-5yЕженедельно6 месяцев5 лет (WORM)
network-1yЕжедневно90 дней1 год
application-90dЕжедневно90 дней

Архивирование в MinIO с WORM-политикой

Для долгосрочного хранения мы развернули MinIO — S3-совместимое объектное хранилище с поддержкой Object Lock (WORM):

# Установка MinIO на NAS-сервере (120 ТБ)
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
sudo mv minio /usr/local/bin/

# Запуск MinIO с Object Lock
MINIO_ROOT_USER=admin MINIO_ROOT_PASSWORD=S3cur3_St0rage! \
  minio server /data/minio --address :9000 --console-address :9001

# Создание bucket с Object Lock (WORM)
mc alias set archive http://localhost:9000 admin S3cur3_St0rage!
mc mb archive/graylog-archive --with-lock

# Установка политики Governance Lock на 5 лет
mc retention set --default GOVERNANCE 1825d archive/graylog-archive

Скрипт архивирования, запускаемый по cron ежемесячно:

#!/bin/bash
# /opt/scripts/graylog-archive.sh
# Архивирование индексов старше 12 месяцев в MinIO

set -euo pipefail

ES_HOST="http://localhost:9200"
MINIO_BUCKET="archive/graylog-archive"
DATE=$(date +%Y-%m-%d)

# Список индексов старше 12 месяцев
CUTOFF=$(date -d '12 months ago' +%Y%m)

for index in $(curl -s "${ES_HOST}/_cat/indices/security-*" | awk '{print $3}'); do
    INDEX_DATE=$(echo "$index" | grep -oP '\d{6}')
    if [[ "$INDEX_DATE" -lt "$CUTOFF" ]]; then
        echo "[$(date)] Архивирование: $index"

        # Создание снапшота OpenSearch
        curl -X PUT "${ES_HOST}/_snapshot/minio_repo/${index}_${DATE}" \
          -H 'Content-Type: application/json' \
          -d "{\"indices\": \"${index}\", \"ignore_unavailable\": true}"

        # Ожидание завершения
        while true; do
            STATUS=$(curl -s "${ES_HOST}/_snapshot/minio_repo/${index}_${DATE}" | jq -r '.snapshots[0].state')
            [[ "$STATUS" == "SUCCESS" ]] && break
            sleep 10
        done

        # Удаление из OpenSearch
        curl -X DELETE "${ES_HOST}/${index}"
        echo "[$(date)] Удалён из OpenSearch: $index"
    fi
done

Дашборды, алерты и compliance-отчёты

Для службы ИБ мы создали набор дашбордов и автоматических отчётов, которые упрощают compliance-проверки.

Дашборды безопасности

Ключевые дашборды в Graylog:

  • Security Overview — общая картина: количество событий ИБ за 24 часа, топ-10 источников, географическая карта атак, тренд аномалий
  • Authentication Monitor — все попытки входа: успешные/неудачные, по пользователям, по серверам, по IP-адресам
  • Firewall Activity — заблокированные соединения, правила срабатывания, аномальный трафик
  • Transaction Audit — логи транзакций: объём, ошибки, подозрительные операции
  • Compliance Dashboard — статус compliance: покрытие устройств, объём хранения, результаты проверок целостности

Пример виджета для дашборда Authentication Monitor:

# Graylog Search Query: неудачные SSH-попытки за 24 часа
source:"sshd" AND action:"Failed" AND _exists_:src_ip

# Агрегация: топ-10 IP по количеству неудачных попыток
# Quick Values → field: src_ip → top 10

# Агрегация: временной график по 15-минутным интервалам
# Statistical → count() → interval: 15 minutes

Алерты и интеграция с SIEM

Мы настроили автоматические оповещения для критичных событий:

# Alert: Brute Force Detection
# Условие: > 10 неудачных попыток входа от одного IP за 5 минут

curl -X POST http://localhost:9000/api/events/definitions \
  -H 'Content-Type: application/json' \
  -u admin:password \
  -d '{
    "title": "Brute Force Detected",
    "description": "Более 10 неудачных попыток входа от одного IP за 5 минут",
    "priority": 3,
    "config": {
      "type": "aggregation-v1",
      "query": "action:Failed AND _exists_:src_ip",
      "streams": [""],
      "group_by": ["src_ip"],
      "series": [{"id": "count", "function": "count"}],
      "conditions": {
        "expression": {"expr": ">", "left": {"ref": "count"}, "right": {"value": 10}}
      },
      "search_within_ms": 300000,
      "execute_every_ms": 60000
    },
    "notifications": [
      {"notification_id": ""},
      {"notification_id": ""}
    ]
  }'

Полный список настроенных алертов:

АлертУсловиеSeverityДействие
Brute Force>10 auth fail / 5 мин от одного IPHighTelegram + Email + auto-block IP
Privilege Escalationsudo/su от нестандартного пользователяCriticalTelegram + SMS + Email
Firewall Drop Spike>1000 dropped / мин (аномалия)MediumTelegram
Transaction Error Rate>1% ошибок транзакций / 15 минHighTelegram + Email дежурному
Log Source DownНет логов от устройства > 15 минMediumTelegram

Результаты внедрения

Проект был выполнен за 4 недели: 1 неделя — проектирование и развёртывание серверной части, 2 недели — подключение 200+ устройств через Ansible, 1 неделя — настройка дашбордов, алертов и тестирование.

МетрикаДо внедренияПосле внедрения
Централизация логовНет (локально на каждом сервере)200+ устройств в Graylog
Хранение4 недели (logrotate)5 лет (требование ЦБ)
Шифрование передачиНетTLS 1.2+ на всех каналах
Целостность архиваНе гарантированаWORM (MinIO Object Lock)
Время поиска событияЧасы (ручной grep по серверам)Секунды (Graylog)
АлертыНет5 типов с Telegram/Email
Compliance ЦБ 683-ПНе соответствуетПолное соответствие

Ключевые результаты:

  • Предписание ЦБ закрыто через 45 дней (из 90 дней дедлайна)
  • 200+ устройств подключены к централизованному сбору логов
  • 140 ГБ/сутки обрабатывается и индексируется
  • Время реагирования на инцидент сократилось с часов до минут
  • 5 лет гарантированного хранения с неизменяемым архивом
«На повторной проверке ЦБ мы показали логи входа за любую дату за последние 3 года за 15 секунд. Инспектор был впечатлён. Предписание снято без замечаний» — начальник службы ИБ ФинПроцесс.

Помимо закрытия предписания, система принесла неожиданный бонус: через две недели после запуска Graylog обнаружил аномальную активность — один из серверов отправлял DNS-запросы к подозрительным доменам каждые 30 секунд. Расследование показало, что на сервере был установлен скомпрометированный npm-пакет с бэкдором. Без централизованного сбора логов эта активность осталась бы незамеченной месяцами.

Дополнительно мы подготовили для ФинПроцесс документацию:

  • Регламент администрирования Graylog — управление пользователями, streams, pipelines
  • Инструкция по восстановлению из архива — как найти и восстановить логи из MinIO
  • Шаблон compliance-отчёта — для предоставления регулятору при проверках
  • Runbook инцидентов — пошаговые инструкции расследования типичных событий ИБ

Часто задаваемые вопросы

Graylog проще в администрировании для задач централизованного сбора логов: встроенные Streams, Pipelines, алерты и управление пользователями. ELK Stack мощнее для аналитики и визуализации, но требует больше настройки. Для compliance-задач (хранение, аудит, отчёты) Graylog подходит лучше «из коробки».

В нашем случае — около 250 ТБ «сырых» данных. Со сжатием OpenSearch (30–40%) и архивным сжатием — около 100–120 ТБ. Мы рекомендуем закладывать рост 20–30% в год, поэтому для нового проекта стоит рассчитывать на 200 ТБ хранилища с возможностью расширения.

Для организаций, подпадающих под регулирование ЦБ РФ (683-П, ГОСТ Р 57580.1) — да, шифрование каналов передачи информации ИБ обязательно. Для остальных — настоятельно рекомендуется: логи содержат IP-адреса, имена пользователей и другую чувствительную информацию, которая не должна передаваться в открытом виде.

Мы используем MinIO с Object Lock в режиме GOVERNANCE — объекты не могут быть удалены или изменены до истечения retention-периода. Для максимальной защиты можно использовать режим COMPLIANCE — даже root-администратор не сможет удалить объект. Дополнительно рекомендуем хранить контрольные суммы (SHA-256) архивов в отдельной защищённой системе.

На Cisco IOS: logging host 10.0.5.20 (IP relay-сервера), logging trap informational, logging facility local0. К сожалению, большинство сетевого оборудования не поддерживает TLS для syslog, поэтому мы принимаем их логи по UDP/514 на relay-сервере и уже оттуда передаём в Graylog по TLS.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#централизованный сбор логов#Rsyslog настройка#Graylog установка#syslog TLS шифрование#хранение логов 5 лет#compliance ЦБ РФ логи#Graylog Elasticsearch#Graylog pipelines