Нулевое доверие для финансовых данных

Финансовые данные не похожи на прочие данные. Утёкший маркетинговый список рассылки — это конфуз; утёкшая главная книга — это карта каждого поставщика, зарплаты, маржи и банковских отношений компании. Она раскрывает, кому вы платите, сколько зарабатываете, где лежат деньги и когда они движутся. Для финансовой функции, которой управляют ИИ-агенты, эти данные к тому же должны быть читаемы программой, чтобы приносить пользу, — а это поднимает очевидный вопрос, который финансовый директор или специалист по безопасности задаёт первым: кто именно может их видеть.

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

Нулевое доверие: никогда не доверяй, всегда проверяй

Старые системы выдавали доверие по местоположению. Если запрос приходил изнутри корпоративной сети или от сервиса за межсетевым экраном, он считался безопасным. Это допущение рушится в тот момент, когда скомпрометирован хотя бы один компонент, ведь всё внутри периметра становится достижимым.

Нулевое доверие полностью убирает неявное доверие. Ни один запрос не считается доверенным из-за того, откуда он исходит. Каждый доступ — от пользователя, агента или внутреннего сервиса — проходит аутентификацию, авторизуется под конкретную область и сверяется с политикой при каждом вызове. Привилегированного «внутри» не существует. Это важно для автономного финансового отдела, потому что агенты действуют непрерывно и через множество сервисов; каждое из этих действий проверяется, а не пропускается на основании сетевого положения.

Шифрование по арендаторам: изолированная граница на каждую компанию

Мультиарендные платформы часто используют один ключ шифрования для всех клиентов и полагаются на код приложения, чтобы разделять данные. Это единая точка отказа: одна логическая ошибка — и границы между арендаторами размываются.

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

Собственные ключи клиента: ключи держит клиент

Шифрование отвечает на вопрос «кто может это прочитать» только если вы также контролируете, кто держит ключ. Собственные ключи клиента (BYOK) передают этот контроль клиенту.

• Ключи живут в вашем KMS. Мастер-ключ происходит из вашей собственной службы управления ключами и остаётся в ней. Платформа выполняет криптографические операции с обращением к нему, а не хранит его.
• Вы ротируете и отзываете. Ротация и отзыв ключей — ваше решение. Отзыв ключа — это жёсткий аварийный выключатель: данные становятся нечитаемыми, в том числе для оператора.
• Оператор не может читать в открытом виде. Поскольку оператор никогда не владеет вашим мастер-ключом, он по замыслу не способен самостоятельно расшифровать ваши финансовые данные.

BYOK превращает заявление о доверии в контроль, который вы можете продемонстрировать. Специалисту по безопасности не нужно верить на слово «мы не будем смотреть»; он может убедиться, что ключ никогда не покидает его юрисдикцию и что отзыв работает.

Конфиденциальные вычисления: агенты работают над данными, которых оператор не видит

Шифрование в покое и при передаче — это стандарт. Более сложная задача — данные в использовании: чтобы классифицировать операцию или подготовить декларацию, агенту в какой-то момент приходится работать с открытым текстом. На обычной инфраструктуре этот открытый текст доступен хосту во время обработки.

FINMOZG спроектирован так, чтобы ИИ-агенты выполнялись внутри сред конфиденциальных вычислений — аппаратно защищённых анклавов, где данные расшифровываются и обрабатываются в памяти, которую окружающая операционная система, гипервизор и оператор прочитать не могут. Удалённая аттестация позволяет рабочей нагрузке доказать, что она выполняет ожидаемый, неизменённый код внутри подлинного анклава, прежде чем ей будут выданы какие-либо ключи. Цель — цепочка, в которой открытые финансовые данные никогда не попадают в инфраструктуру оператора, даже во время вычислений.

Цепочка движения данных

Вместе эти слои образуют единый путь, который проходят данные, при этом контроль остаётся у клиента в начале, а подотчётность фиксируется в конце:

• Устройство пользователя. Данные и инструкции исходят от аутентифицированного пользователя или системы и проверяются при каждом запросе по принципу нулевого доверия.
• Ключ клиента / KMS. Шифрование и расшифровка управляются ключами, которые клиент контролирует в собственном KMS, — платформа запрашивает операции, а не владеет мастер-ключом.
• Хранилище зашифрованных данных. Данные каждого арендатора лежат в покое внутри собственной границы шифрования, без общих ключей между компаниями.
• Среда конфиденциальных вычислений. Агенты обрабатывают открытый текст только внутри аттестованных, аппаратно защищённых анклавов, спроектированных так, чтобы держать его вне досягаемости оператора.
• Неизменяемый журнал аудита. Каждое действие, касающееся данных, записывается в журнал только на добавление, связанный цепочкой хешей.

Неизменяемый журнал аудита

Автономия допустима в финансах лишь тогда, когда каждое действие подотчётно постфактум. FINMOZG записывает каждое действие агента и человека в журнал только на добавление, связанный цепочкой хешей. Каждая запись криптографически связана с предыдущей, поэтому удаление или правка прошлой записи разрывает цепочку и становится обнаружимой, а не остаётся незаметной.

Каждая запись спроектирована так, чтобы отвечать на вопросы, которые аудитор задаёт на самом деле:

• Кто выполнил действие — названный пользователь или конкретный агент.
• Когда это произошло — с точностью до отметки времени.
• Что изменилось — конкретная проводка, декларация или платёж.
• Какой агент был задействован и при какой настройке автономии.
• Какие доказательства это подкрепляли — первичный документ и обоснование.
• Кто утвердил — для любого действия, потребовавшего согласования человеком.

Управление доступом по принципу наименьших привилегий

Нулевому доверию в сети соответствуют наименьшие привилегии в доступе. Каждый человек видит и делает только то, что требует его роль, и ничего сверх этого. Модель отображается на реальных людей вокруг бухгалтерии компании:

• Владелец — полный административный контроль над субъектом и его настройками.
• Бухгалтер — повседневный учёт, классификация и сверка.
• Финансовый директор — аналитика, утверждения и казначейские решения.
• Аудитор — ограниченный доступ преимущественно на чтение к записям и журналу аудита.
• Внешний консультант — ограниченный по времени и узко очерченный доступ для конкретного проекта.
• Инвестор с доступом только на чтение — видимость отчётов без возможности что-либо изменить.

Что это значит для проверки безопасности или банка

Проверки безопасности и партнёрства сводятся к короткому списку вопросов, и эта архитектура построена так, чтобы давать конкретный ответ на каждый:

• Может ли поставщик читать наши данные? BYOK и конфиденциальные вычисления спроектированы так, чтобы ответ был «нет, в открытом виде», — а отзыв ключа это механизм контроля, который держите вы, а не заявка, которую вы подаёте.
• Как изолированы арендаторы? Шифрованием по арендаторам без общих ключей, так что изоляция не зависит от того, свободен ли код приложения от ошибок.
• Может ли кто-то переписать историю? Журнал только на добавление, связанный цепочкой хешей, делает подделку обнаружимой.
• Кто к чему может прикоснуться? Ролевые наименьшие привилегии ограничивают каждого участника, внутреннего или внешнего, определённой областью.

Чтобы быть точными в утверждениях: эта статья описывает архитектуру и принципы проектирования платформы. Там, где возможность является целью проектирования, а не завершённым и независимо проверенным механизмом контроля, об этом так и сказано. FINMOZG не заявляет, что обладает какой-либо конкретной внешней сертификацией, и любой статус аудита или аттестации сообщается отдельно на странице безопасности, а не утверждается здесь.

Нулевое доверие — это не функция, которую включают; это допущение, на котором построена вся система, — что ни один компонент, сеть или оператор не должны по умолчанию пользоваться доверием в отношении самых чувствительных цифр компании. О том, как сами агенты работают под этими механизмами контроля, читайте в материалах агенты, как работает ИИ-бухгалтерия, и что такое автономный финансовый отдел. Если вы проводите проверку поставщика, свяжитесь с нами за деталями.