Система аудиту дій користувачів: реалізація та впровадження

Уявіть: клієнт повідомляє, що хтось змінив ціни на сайті, а хто і коли — невідомо. Без системи аудиту ви витрачаєте години на копання в логах сервера, але не знаходите винуватця. Або гірше — регулятор запитує журнал змін за два роки, а його просто немає. Ми стикалися з цим не раз. Тому впроваджуємо систему аудиту дій користувачів, яка фіксує кожну значущу подію: хто, що, коли і з якого IP.

Без такої системи відновлення ланцюжка подій перетворюється на археологію, а кожен запит регулятора загрожує штрафом до 4% річного обороту. Наша система не лише фіксує події, але й дозволяє швидко фільтрувати журнал за десятком параметрів, економлячи години роботи адміністратора. Наприклад, у великого e-commerce проекту щодня генерується до 50 000 записів аудиту, і без автофільтрації пошук інциденту займав би дні.

Які проблеми вирішує аудит користувачів?

Система аудиту дій користувачів вирішує проблему відсутності прозорості: без журналу неможливо зрозуміти, хто змінив важливі дані або видалив запис. Аудит дає повну картину.

• Регуляторні ризики. 152-ФЗ та GDPR вимагають відстежувати доступ до персональних даних. Порушення — штрафи до 4% обороту.
• Продуктивність. Синхронний запис у кожен запит вбиває БД. Ми використовуємо черги та пакетну вставку — це знижує навантаження на 80%.
• Довгий пошук інцидентів. Без фільтрації за користувачем, подією і датою знайти потрібний запис — голка в копиці сіна.

Що і як логувати

Обов'язкові події

Структура таблиці аудиту

CREATE TABLE audit_logs (
    id          BIGSERIAL PRIMARY KEY,
    user_id     BIGINT REFERENCES users(id) ON DELETE SET NULL,
    event       VARCHAR(100) NOT NULL,          -- 'user.password_changed'
    subject_type VARCHAR(100),                  -- 'App\\Models\\User'
    subject_id   BIGINT,                        -- ID зміненої сутності
    old_values   JSONB,                         -- стан до
    new_values   JSONB,                         -- стан після
    ip_address   INET,
    user_agent   TEXT,
    session_id   VARCHAR(100),
    created_at   TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

CREATE INDEX idx_audit_user ON audit_logs(user_id);
CREATE INDEX idx_audit_event ON audit_logs(event);
CREATE INDEX idx_audit_subject ON audit_logs(subject_type, subject_id);
CREATE INDEX idx_audit_created ON audit_logs(created_at DESC);

Оскільки таблиця аудиту може зростати до сотень гігабайт, важливо правильно індексувати поля. Ми використовуємо індекси на user_id, event, subject_type+subject_id та created_at DESC — це прискорює типові запити в 20 разів.

Як швидко знайти потрібну подію в журналі?

З правильно налаштованими індексами та фільтрацією пошук запису займає секунди. Додайте інтерфейс з вибором дат, користувача і типу події — і адміністратор перестане витрачати години на ручний перегляд логів. Ми реалізуємо таку панель за пару днів.

Як реалізувати систему аудиту

Використання готового пакету

Пакет owen-it/laravel-auditing — найпоширеніший вибір. Підходить для 80% проектів. Налаштування займає годину.

// composer require owen-it/laravel-auditing

// В моделі
use OwenIt\\Auditing\\Contracts\\Auditable;

class User extends Model implements Auditable
{
    use \\OwenIt\\Auditing\\Auditable;

    // Виключити з аудиту чутливі поля
    protected $auditExclude = ['password', 'remember_token'];

    // Тільки при певних подіях
    protected $auditEvents = ['created', 'updated', 'deleted'];
}

Пакет прискорює впровадження в 4 рази порівняно з кастомною реалізацією. Однак для нестандартних сценаріїв (логування невдалих входів, API-запитів) краще підходить Observer.

Кастомний Observer

// app/Observers/AuditObserver.php
class AuditObserver
{
    public function updated(Model $model): void
    {
        if (!$model->wasChanged()) return;

        AuditLog::create([
            'user_id'      => auth()->id(),
            'event'        => strtolower(class_basename($model)) . '.updated',
            'subject_type' => get_class($model),
            'subject_id'   => $model->getKey(),
            'old_values'   => $model->getOriginal(),
            'new_values'   => $model->getChanges(),
            'ip_address'   => request()->ip(),
            'user_agent'   => request()->userAgent(),
        ]);
    }
}

// Реєстрація в AppServiceProvider
User::observe(AuditObserver::class);
Order::observe(AuditObserver::class);

Middleware та події автентифікації

// app/Http/Middleware/AuditRequests.php
class AuditRequests
{
    private array $auditedRoutes = [
        'admin.*',
        'api.users.*',
        'api.settings.*',
    ];

    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        if ($this->shouldAudit($request)) {
            AuditLog::create([
                'user_id'    => auth()->id(),
                'event'      => 'http.' . strtolower($request->method()),
                'new_values' => [
                    'url'    => $request->url(),
                    'method' => $request->method(),
                    'status' => $response->status(),
                ],
                'ip_address' => $request->ip(),
            ]);
        }

        return $response;
    }
}

Чому асинхронний запис аудиту критичний?

Синхронний запис у кожному запиті — навантаження на БД. Рішення:

• Асинхронний запис через черги — відправка задачі WriteAuditLog на чергу audit.
• Пакетна вставка — накопичувати записи в Redis, скидати раз на хвилину.
• Окрема БД для аудиту — ізолює навантаження.

// Асинхронний запис через черги
dispatch(new WriteAuditLog($data))->onQueue('audit');

// Пакетна вставка — накопичувати в Redis, скидати раз на хвилину
Redis::rpush('audit_queue', json_encode($data));

// Окрема БД для аудиту
// config/database.php
'audit' => [
    'driver'   => 'pgsql',
    'database' => 'audit_db',
    // ...
]

Порівняння підходів: пакет vs кастом

Для типового проекту обираємо пакет. Якщо потрібна нестандартна логіка — зв'яжіться з нами для консультації.

Процес і терміни впровадження

Що входить у роботу

• Проектування схеми аудиту під ваші сутності
• Реалізація логування (пакет або кастом)
• Налаштування асинхронного запису через черги
• Інтерфейс перегляду з фільтрацією за користувачем, подією, часовим діапазоном, сутністю
• Ротація логів (Artisan-команда)
• Документація та міграції
• Навчання адміністраторів
• Гарантія 6 місяців

Терміни реалізації

• Базова модель + Observer для ключових сутностей — від 2 до 3 днів
• Повноцінна система з чергами, ротацією та UI — від 5 до 7 днів

Точний термін залежить від кількості моделей та складності бізнес-логіки. Ми оцінимо ваш проект безкоштовно — просто зв'яжіться з нами. Досвід роботи з Laravel понад 5 років, реалізували аудит для 20+ проектів. Гарантуємо відповідність вимогам 152-ФЗ та GDPR.

Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Замовте впровадження системи аудиту вже сьогодні.

Безпека веб-додатків: що приховує «тихий» злом

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.

Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 2–4 тижні.

HTTPS та правильна конфігурація TLS

HTTPS — мінімальний обов'язковий рівень. Але «є SSL-сертифікат» і «правильно налаштований TLS» — різні речі.

В конфігурації Nginx/Apache перевіряємо:

• Протоколи: тільки TLS 1.2 та TLS 1.3, SSLv3 та TLS 1.0/1.1 — вимкнено
• Cipher suites: віддавати перевагу ECDHE (Forward Secrecy), прибрати NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security з includeSubDomains; preload) — браузер більше не робить незахищених запитів
• OCSP Stapling — прискорює перевірку відкликання сертифіката
• Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)

Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.

Let's Encrypt + Certbot для продакшену — стандарт. Автоматичне оновлення через certbot renew в cron. Wildcard-сертифікат для піддоменів через DNS-01 challenge.

Content Security Policy: як він закриває XSS на 99%?

CSP — HTTP-заголовок, який говорить браузеру, звідки дозволено завантажувати ресурси. Правильно налаштований CSP повністю блокує більшість XSS-атак, навіть якщо вразливість є в коді.

Проблема: зламати сайт неправильним CSP простіше простого. default-src 'none' — і перестають працювати шрифти, картинки, JS. Тому починаємо з Content-Security-Policy-Report-Only — CSP логує порушення, але нічого не блокує. Дивимося репорти 2–4 тижні, доопрацьовуємо політику, потім перемикаємо на бойовий режим.

Приклад реальної політики для сайту з Google Analytics, Google Fonts та Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — випадковий рядок, генерується на сервері для кожного запиту. Inline-скрипти з правильним nonce дозволені, без nonce — заблоковані. Це ламає XSS через <script>alert(1)</script> повністю.

'unsafe-inline' в style-src — компроміс для inline-стилів. Краще прибрати, перенісши всі стилі в CSS-файли, але це вимагає рефакторингу.

CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.

Чому XSS залишається найпоширенішою вразливістю?

XSS (Cross-Site Scripting) — ін'єкція JS-коду через користувацький ввід. За статистикою OWASP, XSS входить до топ-3 вразливостей веб-додатків. Три типи:

Захист: ніколи не вставляти користувацький ввід в HTML без екранування. В PHP — htmlspecialchars() з ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безпечний, {!! $var !!} — небезпечний. В React — {variable} безпечний, dangerouslySetInnerHTML — небезпечний. Для Rich Text — htmlpurifier на PHP або DOMPurify в браузері.

Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.

CSRF: захист форм та API

CSRF (Cross-Site Request Forgery) — зловмисник змушує браузер жертви відправити запит від її імені. Приклад: користувач авторизований в банку, відкриває шкідливу сторінку, вона робить fetch('https://bank.ru/transfer?to=evil&amount=50000') — якщо банк не захищений, гроші йдуть.

CSRF-токени — стандартний захист для форм: сервер генерує випадковий токен, зберігає в сесії, вставляє в форму як hidden field. При POST-запиті токен звіряється. Зловмисник не знає токен. Laravel робить це автоматично через @csrf.

SameSite cookies — сучасний захист: SameSite=Strict або SameSite=Lax забороняє браузеру відправляти cookie в cross-site запитах. Працює у всіх сучасних браузерах.

API без сесій (JWT, Bearer tokens) — CSRF неактуальний, якщо токен не зберігається в cookie (а в Authorization header або localStorage). Але localStorage вразливий до XSS — тому для чутливих даних кращі HttpOnly cookies з SameSite.

WAF та захист від DDoS

WAF (Web Application Firewall) — фільтрує HTTP-трафік на предмет атак: SQL injection, XSS, path traversal, відомі exploit patterns. Варіанти:

• Cloudflare WAF — хмарний, правила OWASP Top 10 з коробки, кастомні правила через вирази. Managed Rules автоматично блокують нові загрози.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гнучко, але вимагає налаштування та моніторингу хибних спрацьовувань.
• AWS WAF — для інфраструктури на AWS, інтегрується з CloudFront та ALB.

DDoS-захист. Cloudflare на рівні L3/L4/L7 — де-факто стандарт для більшості сайтів. Автоматичне пом'якшення volumetric атак, Under Attack Mode при активній атаці. Для критичної інфраструктури — Cloudflare Magic Transit або спеціалізовані рішення (Qrator, StormWall).

Rate Limiting на рівні додатку — додатковий шар. Laravel ThrottleRequests middleware: 60 запитів на хвилину на IP для загальних endpoint, 5 — для /login та /password/reset. Redis як сховище лічильників — обов'язково для горизонтально масштабованих систем (інакше ліміти не синхронізуються між серверами).

Інші обов'язкові заходи

Заголовки безпеки. Окрім CSP: X-Frame-Options: DENY (захист від clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (обмеження доступу до API браузера: камера, мікрофон, геолокація).

SQL injection. Prepared statements всюди. Жодних конкатенацій користувацького вводу в SQL-рядки. ORM (Eloquent, Doctrine) захищає за замовчуванням. $wpdb->prepare() в WordPress — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.

Оновлення залежностей. composer audit та npm audit — в CI/CD пайплайн. Dependabot або Renovate для автоматичних PR з оновленнями. Критичні CVE — патчити протягом 24 годин.

Секрети та конфігурація. .env — ніколи в Git. Секрети в production — через змінні оточення CI/CD (GitHub Secrets, GitLab CI Variables) або HashiCorp Vault. Перевірка на витоки: git-secrets, truffleHog в pre-commit hooks.

Як ми працюємо?

1. Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
2. Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
3. Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
4. Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
5. Деплой та моніторинг — включення бойового CSP, налаштування алертів, навчання команди.

Що входить в роботу?

• Звіт зі знайденими вразливостями та рекомендаціями (PDF + code snippets)
• Готова конфігурація TLS (Nginx/Apache)
• Політика CSP з режимом Report-Only та бойовою версією
• Налаштування WAF та Rate Limiting
• План оновлень залежностей
• Доступи до інструментів моніторингу (Sentry, Datadog)
• 30 днів постаудит-підтримки (консультації, правки)

Терміни та вартість

Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.