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

1. Моя философия безопасности: Крепость с нулевым доверием

Данная Политика кибербезопасности представляет собой прозрачную техническую спецификацию системы безопасности веб-сайта david-osipov.vision. Модель безопасности проекта основана на философии нулевого доверия (Zero Trust) и реализуется через разработку, управляемую «Конституцией» (Constitution-Driven Development). Каждый компонент функционирует исходя из предположения, что другие части системы могут быть скомпрометированы. Безопасность — это не дополнительная функция, а неотъемлемая основа проекта, регулируемая формальным внутренним документом: Официальная конституция безопасности и инженерии.

Мои ключевые принципы:

• Безопасность по умолчанию: Изначальное состояние приложения является его самым безопасным состоянием.
• Эшелонированная оборона (Defense in Depth): Применяется многоуровневая система независимых и верифицируемых средств контроля безопасности.
• Производительность как элемент безопасности: Высокопроизводительный, неблокирующий интерфейс предотвращает атаки по времени отклика (timing attacks) и улучшает пользовательский опыт, что, в свою очередь, способствует безопасному поведению пользователя.
• Проверяемая безопасность: Средство контроля безопасности считается недействующим до тех пор, пока его эффективность не будет подтверждена автоматизированным состязательным тестированием в конвейере CI/CD.

2. Архитектурная безопасность: Изначально безопасная основа

2.1. Архитектура статического сайта

david-osipov.vision — это полностью статический веб-сайт. Такой архитектурный выбор по своей природе исключает целые классы уязвимостей, включая удаленное выполнение кода (RCE) и SQL-инъекции (SQLi), благодаря отсутствию серверных интерпретаторов и подключений к базам данных.

2.2. Усиление инфраструктуры с помощью Cloudflare

Веб-сайт размещен на Cloudflare Pages, что обеспечивает критически важную безопасность на периметре сети:

• Глобальная защита от DDoS-атак и WAF: Вредоносный трафик фильтруется на периметре сети с помощью WAF от Cloudflare.
• Управляемый и безопасный TLS: Весь контент доставляется исключительно по HTTPS. Управление TLS-сертификатами осуществляется Cloudflare с приоритетом на современные и безопасные шифры, такие как TLS 1.3.

2.3. Безопасность на уровне домена и DNS

• DNSSEC (Domain Name System Security Extensions): Домен david-osipov.vision защищен с помощью DNSSEC. Эта технология обеспечивает криптографическую подпись DNS-записей, предотвращая DNS-спуфинг и атаки типа «отравление кэша».
• CAA (Certification Authority Authorization): Через DNS-записи применяется строгая политика CAA, которая явно указывает, каким центрам сертификации разрешено выдавать SSL/TLS-сертификаты для домена, что предотвращает их несанкционированную выдачу.

3. Безопасность на уровне приложения: Защита, реализуемая браузером

3.1. Автоматизированная Content Security Policy (CSP) на основе хешей

В качестве основной защиты от межсайтового скриптинга (XSS) применяется строгая политика CSP на основе хешей. Эта система полностью автоматизирована, чтобы исключить использование 'unsafe-inline' и гарантировать постоянную синхронизацию политики с развернутым кодом.

• Механизм: Во время сборки специальная интеграция для Astro (csp-hash-collector.mjs) сканирует все сгенерированные HTML-файлы, вычисляет криптографические хеши (sha-384 для блоков скриптов/стилей, sha-256 для встроенных атрибутов style) всех легитимных встроенных ресурсов и записывает их в канонический файл отчета (dist/csp-hashes.json).
• Применение: Отдельный скрипт (apply-csp-hashes.mjs) использует этот отчет для обновления заголовка Content-Security-Policy в конфигурации развертывания (public/_headers).
• Проверка: Конвейер CI/CD запускает верификационный скрипт (verify-csp-hashes.mjs), который прерывает сборку в случае расхождения заголовков с отчетом, обеспечивая тем самым актуальность политики.

3.2. Обязательное использование Trusted Types

Чтобы сделать политику CSP невозможной для обхода и предотвратить DOM-based XSS, принудительно используются Trusted Types через директиву require-trusted-types-for 'script'.

• Механизм: Эта мера запрещает опасным DOM-приемникам (DOM sinks), таким как .innerHTML, принимать обычные строки. Вместо этого они требуют специальный объект TrustedHTML.
• Реализация: Единственным разрешенным механизмом для создания таких объектов является внутренняя политика app-policy. Она использует тщательно настроенный экземпляр isomorphic-dompurify со строгими белыми списками тегов и атрибутов, явно блокируя опасные элементы и все обработчики событий on*.

3.3. Усиленные HTTP-заголовки и междоменная изоляция

• Ключевые заголовки безопасности: Strict-Transport-Security (с директивой preload), X-Content-Type-Options: nosniff, Referrer-Policy и ограничительная Permissions-Policy.
• Междоменная изоляция (Cross-Origin Isolation): Для защиты от атак по побочным каналам (side-channel attacks), таких как Spectre, создается междоменно изолированная среда с помощью заголовков Cross-Origin-Opener-Policy (COOP): same-origin и Cross-Origin-Embedder-Policy (COEP): credentialless.

3.4. Изоляция стороннего кода и SVG

• Конвейер аналитики: Код сторонних систем аналитики (например, Google Analytics) никогда не выполняется непосредственно на странице. Вместо этого он работает в изолированном Web Worker, что изолирует его сетевые запросы и предотвращает доступ к основному DOM, следуя Принципу наименьших привилегий.
• Безопасность SVG: В проекте используется двухуровневая стратегия безопасности для SVG:
  1. Локальные иконки: Все локальные иконки проходят через конвейер санитарной обработки на этапе сборки, который использует DOMPurify для удаления всех скриптов, обработчиков событий и небезопасных тегов, гарантируя рендеринг только безопасных статических векторных данных.
  2. Динамические значки: Динамические SVG (например, с shields.io) направляются через усиленный серверный прокси (/api/safe-svg), который проверяет, очищает и кэширует контент перед его отправкой, снижая риски, связанные с цепочкой поставок.

3.5. Система зашифрованной контактной формы (клиентское E2E-шифрование)

В качестве практического примера инженерного подхода, ориентированного на безопасность, проект использует зашифрованную контактную форму, в которой тело сообщения шифруется полностью на стороне клиента перед отправкой. Эта система демонстрирует несколько ключевых защитных приёмов архитектуры (эшелонированная оборона, Trusted Types и строгая CSP) и интегрируется с внешними сервисами при сохранении приватности.

Ключевые свойства:

• Клиентское шифрование: Тело сообщения шифруется в браузере с использованием OpenPGP (OpenPGP.js) и публичного ключа получателя. На сервер отправляется только шифротекст.
• Примечание: OpenPGP.js распространяется под лицензией GNU Lesser General Public License v3 (LGPL-3.0). Подробности лицензии: https://www.gnu.org/licenses/lgpl-3.0.html.
• Выборочное открытое метаданные: Для совместимости с электронной почтой метаданные отправителя (имя, email, тема) остаются в открытом виде для маршрутизации; только содержимое сообщения шифруется.
• Поиск и проверка публичного ключа: Публичный PGP-ключ получателя извлекается из Web Key Directory (WKD) на openpgpkey.david-osipov.vision. Клиент проверяет отпечаток ключа (fingerprint) и вычисляет SHA-512 от ARMOR-ключа как вторичную проверку целостности.
• Интеграция hCaptcha: На стороне клиента используется hCaptcha для предотвращения автоматических отправок; серверная проверка выполняется поставщиком форм (Web3Forms) в рамках эшелонированной защиты.
• Транспорт и доставка: Зашифрованные данные отправляются POST-запросом в Web3Forms (ключ доступа управляется конфигурацией сайта). Web3Forms проверяет капчу и пересылает письмо с шифротекстом на почтовый ящик получателя — расшифровать его может только владелец приватного ключа.
• Безопасный интерфейс и санитаризация: Все обновления DOM, сообщения об ошибках и уведомления о шифровании используют Trusted Types и textContent для исключения XSS-векторов; публичные строки проходят валидацию через схему контента и систему i18n.

Значения для проверки безопасности (для ручных и автоматизированных аудитов):

Отпечаток PGP-ключа: D3FC4983E500AC3F7F136EB80E55C4A47454E82E

SHA-512 (ARMOR-ключ): E63AE1C82DA6C6022A6362CEAA6FE8AE6EE094A8F4A56F92069973DB290E885640D645CA6D796411830724B42BBE11D889EBB6BDBCB4A82999752EE69AF9A877

Операционные замечания:

• Клиент принудительно завершает операцию (fatal failure), если проверка отпечатка не проходит, предотвращая шифрование с неподтверждённым ключом. Несоответствие SHA-512 считается уведомлением (логируется) и не блокирует операцию, обеспечивая дополнительную защиту без ложных срабатываний.
• Публичный ключ предварительно загружается при загрузке страницы и кешируется в памяти для снижения задержки при отправке. Для всех сетевых операций используется AbortController, чтобы навигация или уничтожение компонента всегда отменяли ожидающие запросы.
• Система соответствует требованиям Security Constitution: не используется Math.random(), все DOM-операции проходят через Trusted Types, сторонние скрипты загружаются с nonce и CSP, и предусмотрена явная очистка через методы destroy().

4. Безопасный жизненный цикл разработки ПО (SDLC)

Безопасность интегрирована в каждый этап процесса разработки, регулируется внутренней «Конституцией» и обеспечивается конвейером CI/CD (.github/workflows/bastion-gates.yml).

4.1. Безопасность и усиление на этапе сборки

Принципы безопасности смещены на ранние этапы (Shift Left) и интегрированы непосредственно в процесс сборки Astro:

• Строго типизированные коллекции контента: С помощью схем Zod в src/content/config.ts обеспечивается строгая структура данных для всего контента. Это предотвращает нарушение целостности данных и снижает риск уязвимостей на уровне их источника.
• Обработка контента во время сборки: Пользовательские плагины Remark, такие как remark-figure-captions и remark-toc-data.mjs, обрабатывают контент во время сборки. Это переносит сложный парсинг с клиента (runtime) в доверенную среду сборки (build-time), уменьшая поверхность атаки на стороне клиента и повышая производительность.
• Санитарная обработка статического вывода: В качестве последней меры эшелонированной обороны, конвейер CI/CD запускает верификационный скрипт (scripts/verify-sanitize-dist), который сканирует конечный HTML-код на наличие высокорисковых элементов, таких как встроенные обработчики событий или javascript: URL. Обнаружение таких элементов приведет к блокировке развертывания.

4.2. Реализация кода по принципу «Безопасность по умолчанию»

Кодовая база является прямым отражением моих принципов безопасности:

• Криптографическая целостность: Модуль security-kit.ts использует исключительно Web Crypto API (crypto.getRandomValues) и явно генерирует исключение CryptoUnavailableError вместо того, чтобы переключаться на небезопасный Math.random(). Для генерации несмещенных случайных чисел и строк применяется выборка с отклонением (rejection sampling) (вдохновленная nanoid) для гарантии равномерного распределения.
• Безопасное взаимодействие с DOM: Используется централизованный класс SecureDOMValidator для проверки всех динамических DOM-селекторов по строгому белому списку, чтобы предотвратить инъекцию селекторов (Selector Injection). Кроме того, он подтверждает, что результат запроса является instanceof Element, что служит ключевой защитой от атак DOM Clobbering.
• Безопасная обработка URL: Проект запрещает прямое использование нативных функций, таких как encodeURIComponent. Вместо этого предписывается использование пользовательских хелперов из security-kit.ts (например, createSecureURL), которые задействуют усиленные API браузера URL и URLSearchParams для предотвращения распространенных уязвимостей кодирования URL.
• Управление состоянием и отказоустойчивость: Обеспечивается истинная инкапсуляция с помощью приватных полей классов (#), а для неизменяемых конфигураций используется Object.freeze(). Все обработчики событий управляются через AbortController для корректной очистки ресурсов в средах SPA.

4.3. Производительность как элемент безопасности

Высокопроизводительное приложение — более безопасное приложение. Поэтому применяются современные и эффективные подходы:

• Плавные анимации (WAAPI): Для выполнения анимаций в отдельном потоке композиции используется Web Animations API (element.animate).
• Эффективное наблюдение: Для отслеживания прокрутки и изменений макета используются IntersectionObserver и ResizeObserver, что устраняет издержки производительности устаревших обработчиков событий.
• Вынесение на слой GPU: Браузеру явно даются указания выносить анимированные элементы на собственный композитный слой с помощью transform: translateZ(0) и will-change.

4.4. Автоматизированная проверка и контроль в CI/CD

Конвейер CI/CD является главным гарантом соблюдения политик безопасности. Pull-запрос не будет принят, пока не пройдут все проверки в рабочем процессе bastion-gates.yml.

• Статический анализ безопасности (SAST): Задача Analyze в конвейере CI/CD интегрирует ESLint с плагинами безопасности (eslint-plugin-security, eslint-plugin-no-unsanitized) и CodeQL от GitHub для глубокого семантического анализа кода. Такая настройка SAST автоматически обнаруживает и блокирует небезопасные паттерны.
• Автоматизированное управление зависимостями: Используется бот Renovate (renovate.json) для автоматического создания pull-запросов на обновление зависимостей, что гарантирует своевременное применение патчей безопасности. Моя философия: доверие не транзитивно, и каждая зависимость — потенциальный вектор атаки.
• Аудит зависимостей: Конвейер выполняет npm audit --audit-level=high. Сборка будет прервана, а развертывание — заблокировано, если в производственных зависимостях будут найдены уязвимости высокого или критического уровня.

5. Раскрытие и сообщение об уязвимостях

Я стремлюсь оперативно и ответственно устранять уязвимости в системе безопасности. Для раскрытия информации об уязвимостях принят стандартизированный протокол security.txt (RFC 9116).

Официальные инструкции по сообщению об уязвимостях безопасности находятся по следующему стандартному адресу:

https://david-osipov.vision/.well-known/security.txt

Этот файл содержит необходимую контактную информацию, мой публичный PGP-ключ для шифрования сообщений и область действия данной политики. Просьба следовать процедурам, изложенным в этом файле, и не раскрывать публично информацию о найденных уязвимостях до тех пор, пока не будет предоставлено разумное время на их изучение и устранение.