Суверенная цифровая инфраструктура должна быть безопасной по архитектуре, а не только по настройкам
Безопасность по умолчанию (Security by Default) означает, что защита не добавляется после запуска системы, а закладывается в саму архитектуру: в домены, IP-адреса, сетевые зоны, доверенные шлюзы, идентификацию, криптографию, маршрутизацию, журналы, DLT-доказательства, архивную сохранность и мониторинг.
В суверенной цифровой инфраструктуре безопасность должна быть встроена в каждый уровень: от центра обработки данных (datacenter) и сетевого маршрута до цифрового документа, события, хэша, DLT-квитанции и архивной квитанции.
Коротко за 30 секунд
Security by Default — это принцип, при котором инфраструктура изначально проектируется как защищенная, управляемая, наблюдаемая и проверяемая среда.
Каждый участник имеет цифровую идентичность. Каждый доступ проходит проверку. Каждый маршрут контролируется. Каждый шлюз журналируется. Каждое критическое событие получает trace_id, route_id и доказательство. Криптографически значимые события могут фиксироваться в DLT, а документы и доказательства — сохраняться в Арбитражном Архиве.
Итог: безопасность становится не отдельным модулем, а свойством всей цифровой инфраструктуры.
Что такое безопасность по умолчанию
Безопасность по умолчанию — это архитектурный подход, при котором система считается небезопасной до тех пор, пока каждый уровень не получил проверяемые правила защиты: кто имеет доступ, к чему имеет доступ, через какой шлюз, по какому маршруту, с каким полномочием, с каким журналом действий и с каким доказательством события.
В такой модели недостаточно просто поставить firewall или пароль. Необходимо, чтобы вся инфраструктура поддерживала контролируемый обмен, криптографическую проверку, сегментацию, мониторинг и восстановление после сбоев.
Основные принципы Security by Default
• Нулевое доверие (Zero Trust): ни пользователь, ни устройство, ни сервис не считаются доверенными автоматически.
• Минимальные права (Least Privilege): участник получает только те права, которые необходимы для конкретного действия.
• Проверяемая идентичность (Verifiable Identity): доступ основан на цифровой идентичности, домене, учетной записи, устройстве, ключе и полномочии.
• Контролируемый маршрут (Controlled Routing): юридически значимое событие проходит через известные домены, IP-контуры, сетевые зоны и шлюзы.
• Наблюдаемость (Observability): каждое критическое действие должно быть записано в журнал, связано с trace_id и доступно для аудита.
• Криптографическая целостность (Cryptographic Integrity): документ, событие и доказательство получают хэш, подпись, временную метку и проверяемый статус.
• Разделение зон (Network Segmentation): внешние сервисы, шлюзы, прикладные системы, данные, ключи, архив и управление размещаются в разных зонах.
• Устойчивость (Resilience): сбой одного узла или зоны не должен останавливать всю инфраструктуру.
• Доказательность (Evidence-based Security): критические события могут фиксироваться в DLT и связываться с архивными квитанциями.
• Безопасность жизненного цикла (Lifecycle Security): защита действует не только в момент входа, но на всем пути документа и события.
Архитектура безопасности
В sovereign digital infrastructure безопасность строится как система взаимосвязанных уровней.
| Уровень | Назначение | Что защищает |
| Identity Layer | Идентификация и проверка прав участника | Пользователи, организации, устройства, сервисы, узлы |
| Access Layer | Управление доступом и сессиями | Вход, роли, полномочия, MFA, WebAuthn |
| Gateway Layer | Контролируемый вход и обмен между системами | API, Trust Gateway, Archive Gateway, Verification Gateway |
| Network Layer | Сетевые зоны и маршрутизация | Домены, IP, маршруты, DMZ, внутренние зоны |
| Crypto Layer | Криптографическое доказательство | Хэш, подпись, timestamp, ключи, HSM/PKI |
| DLT Layer | Неизменяемая фиксация критических событий | DLT-квитанции, proof, подтверждение узлов |
| Archive Layer | Долговременная правовая сохранность | Архивные пакеты, archive receipt, журналы доступа |
| Monitoring Layer | Выявление инцидентов и аномалий | SIEM/SOC, события, логи, корреляция |
| Recovery Layer | Непрерывность работы и восстановление | Резервирование, DR, backup, отказоустойчивость |
Сетевые зоны
Суверенная инфраструктура не должна быть одной плоской сетью. Для защиты используется разделение на зоны с разными правилами доступа.
| Зона | Роль | Пример компонентов |
| Public Zone | Публичный доступ к открытым страницам и сервисам проверки | Сайты, публичные verification pages, статические материалы |
| DMZ | Промежуточная защищенная зона между внешним миром и внутренними системами | WAF, reverse proxy, API edge, rate limiting |
| Gateway Zone | Контролируемый обмен между участниками | API Gateway, Trust Gateway, Archive Gateway, Verification Gateway |
| Application Zone | Прикладные сервисы и бизнес-логика | Документы, процессы, реестры, сервисы участников |
| Data Zone | Хранение рабочих данных и баз | Базы данных, хранилища, индексы, репозитории |
| Crypto Zone | Операции с ключами и доказательствами | HSM, PKI, signing service, timestamping |
| DLT Zone | Узлы распределенного реестра | DLT nodes, consensus components, node logs |
| Archive Zone | Долговременное хранение и архивные квитанции | Арбитражный Архив, immutable storage, archive registry |
| Management Zone | Администрирование и мониторинг | SIEM, SOC, bastion host, admin access, observability |
Шлюзы как точки безопасности
Шлюзы (gateways) — это не просто технические прокси. В архитектуре доверия они являются контролируемыми точками, через которые проходят юридически значимые события.
• API Gateway управляет входящими API-запросами, политиками доступа, лимитами и маршрутизацией.
• Trust Gateway проверяет участника, полномочия, формат события, контекст действия и готовность события к фиксации в DLT.
• Archive Gateway формирует архивный пакет, передает его в Арбитражный Архив и получает архивную квитанцию.
• Verification Gateway обеспечивает проверку документа, хэша, DLT-квитанции, archive receipt и статуса события.
• Routing Gateway контролирует движение событий между сетевыми зонами и участниками инфраструктуры.
Каждый шлюз должен выполнять не только передачу данных, но и проверку, журналирование, трассировку и защиту от несанкционированных действий.
Идентичность и доступ
Безопасность начинается с ответа на вопрос: кто действует, от имени кого, с каким правом и в каком контексте.
• Пользователь должен быть идентифицирован.
• Организация или сервис должны иметь цифровую идентичность.
• Домен может использоваться как человекочитаемый идентификатор субъекта или сервиса.
• DID и Verifiable Credentials могут применяться для машинно-проверяемой идентичности и полномочий.
• MFA, WebAuthn, passkeys, Face ID или иные механизмы могут усиливать подтверждение действия.
• Устройство, сессия, IP, маршрут и контекст действия должны учитываться при оценке риска.
• Полномочия должны проверяться до совершения юридически значимого действия.
Криптографическая безопасность
Криптография используется не как декоративный элемент, а как основа доказательности и целостности.
• Хэш показывает, что документ или событие не были изменены.
• Цифровая подпись связывает доказательство с системой, субъектом или доверенным сервисом.
• Временная метка фиксирует момент создания доказательства.
• HSM/PKI защищают ключи и операции подписи.
• Канонизация данных помогает получать стабильный хэш для структурированных данных.
• Критические доказательства могут передаваться в DLT и связываться с архивными квитанциями.
Связь безопасности с DLT и Арбитражным Архивом
DLT и Арбитражный Архив усиливают безопасность, потому что позволяют не только защищать систему, но и доказывать факт события после его совершения.
| Компонент | Роль в безопасности |
| DLT | Фиксирует доказательство события в распределенной сети, снижая риск скрытого изменения или удаления записи. |
| DLT-квитанция | Подтверждает, что конкретное событие было зафиксировано с определенным хэшем, временем и идентификатором. |
| Арбитражный Архив | Сохраняет архивный пакет, метаданные, квитанции и доказательства для долговременной проверки. |
| Архивная квитанция | Подтверждает прием и статус архивного пакета. |
| Verification-сервис | Позволяет проверить подлинность доказательства без раскрытия лишних данных. |
Мониторинг, SIEM и SOC
Суверенная инфраструктура должна быть наблюдаемой. Если событие нельзя увидеть, связать с участником и проверить по журналам, оно не должно считаться полноценным доверенным событием.
• SIEM собирает события безопасности из шлюзов, приложений, сетевых устройств, узлов DLT, архивных систем и сервисов доступа.
• SOC анализирует инциденты, аномалии, попытки обхода правил, подозрительные маршруты и нарушения политик.
• Журналы должны содержать идентификаторы участников, trace_id, route_id, время события, статус проверки и результат действия.
• Критические административные действия должны журналироваться отдельно и быть доступны для аудита.
• Аномалии должны формировать уведомления для ответственных операторов.
Защита данных и минимизация раскрытия
Безопасность по умолчанию требует не собирать и не раскрывать больше данных, чем необходимо для конкретного действия.
• DLT не должен хранить полный текст документов и персональные данные.
• Проверка должна по возможности работать через хэши, квитанции, статусы и метаданные.
• Доступ к архивному пакету должен предоставляться только по правовому или договорному основанию.
• Публичная проверка не должна раскрывать коммерческую тайну или персональные данные.
• Для внешних интеграций должны применяться ограниченные API и политики доступа.
Доступность и восстановление
Защищенная инфраструктура должна не только предотвращать атаки, но и сохранять работу при сбоях.
• Критические сервисы должны иметь резервирование.
• ЦОДы и узлы должны поддерживать аварийное восстановление (Disaster Recovery).
• DLT-сеть должна сохранять доказательства даже при недоступности части узлов.
• Архивные данные должны иметь резервные копии и контроль целостности.
• Сетевые маршруты должны иметь основные и резервные контуры.
• План восстановления должен проверяться регулярными учениями.
Контролируемый обмен как элемент безопасности
Контролируемый обмен означает, что цифровое событие движется не случайным путем, а по официальному маршруту.
• У каждого события есть trace_id.
• У каждого маршрута есть route_id.
• Известен источник события.
• Известен получатель события.
• Известен шлюз, через который событие прошло.
• Известно время передачи и получения.
• Известен результат проверки.
• Критические события могут быть связаны с DLT-квитанцией и архивной квитанцией.
От каких рисков защищает такая архитектура
• скрытое изменение документа;
• подмена маршрута;
• несанкционированный доступ;
• подделка цифрового события;
• потеря доказательства;
• неконтролируемый обмен между системами;
• разрозненные журналы без единой трассировки;
• серые сетевые зоны и неучтенные маршруты;
• зависимость от одной базы данных;
• невозможность доказать, кто, когда и что совершил.
Связь с другими разделами sovereign.satcom.kg
| Раздел | Связь со страницей Security |
| Sovereign Network | Определяет домены, IP, маршруты и сетевые зоны, на которых строится безопасность. |
| Datacenters | Обеспечивает физическую, инфраструктурную и эксплуатационную основу защиты. |
| Trust Nodes | Распределяет доверие между узлами и снижает зависимость от одной точки контроля. |
| Routing | Описывает trace_id, route_id, шлюзы и контролируемый обмен. |
| Availability | Обеспечивает устойчивость и восстановление после сбоев. |
| Integrity | Подтверждает неизменность данных, документов, событий и доказательств. |
Связь с trust.asiainfo.kg
Сайт trust.asiainfo.kg объясняет, как создается цифровое доверие: идентичность, документ, доказательство, DLT, Арбитражный Архив и проверка. Сайт sovereign.satcom.kg объясняет, на какой инфраструктуре это доверие работает. Страница Security связывает эти два уровня: безопасность инфраструктуры обеспечивает проверяемость доверенных цифровых событий.
Карточки для страницы
| Карточка | Краткий текст |
| Zero Trust | Доступ не предоставляется автоматически. Каждый участник, сервис и устройство проходят проверку. |
| Сетевые зоны | Инфраструктура разделена на зоны: public, DMZ, gateway, application, data, crypto, DLT, archive и management. |
| Доверенные шлюзы | Юридически значимые события проходят через контролируемые шлюзы с проверкой, журналированием и трассировкой. |
| Криптография | Хэш, подпись, timestamp, HSM/PKI и канонизация данных формируют доказательство целостности. |
| DLT-доказательства | Критические события могут фиксироваться в распределенном реестре как неизменяемое доказательство факта. |
| Архивная сохранность | Арбитражный Архив обеспечивает долговременное хранение доказательств и архивные квитанции. |
| SIEM/SOC | События безопасности собираются, коррелируются и анализируются для выявления инцидентов и аномалий. |
| Резервирование | Доступность поддерживается резервными маршрутами, узлами, ЦОДами и планами восстановления. |
Заключение
Security by Default означает, что безопасность не является отдельной надстройкой. Она встроена в домены, IP, маршруты, сетевые зоны, шлюзы, идентичность, криптографию, DLT-доказательства, Арбитражный Архив, мониторинг и восстановление. В такой архитектуре каждое критическое цифровое событие становится не только защищенным, но и проверяемым.
