Требование изоляции
Подрядчики обороны, государственные разведывательные агентства и операторы критической инфраструктуры управляют сетями, где внешнее интернет-соединение физически невозможно, а не просто запрещено политикой. SCIF (Sensitive Compartmented Information Facility) — это комната или объект, предназначенный для предотвращения электронной прослушки и сбора разведывательной информации — он находится в клетке Фарадея, без беспроводных сигналов, входящих или выходящих. Классифицированная правительственная сеть под контролем ITAR (International Traffic in Arms Regulations) не может передавать защищенные технические данные неутвержденным сторонам — к этой категории относятся облачные сервисы, не прошедшие проверку по ITAR.
Для организаций в этих средах "облачный SaaS" не является риском, который нужно управлять — это техническая невозможность. Любой инструмент анонимизации, который требует активного сетевого соединения, не может быть развернут. Любой инструмент, который связывается с сервером для проверки лицензии, является неприемлемым. Любой инструмент, модели обнаружения которого требуют вызовов API облака для вывода, не может функционировать.
Сообщество Ollama специально указывает на развертывание в изолированных условиях как основное обоснование для локальных инструментов ИИ: "Все данные остаются на вашем устройстве с Ollama, никакая информация не отправляется на внешние серверы — это особенно важно для чувствительной работы, такой как врачи, работающие с записями пациентов, или юристы, рассматривающие дела." То же самое обоснование применимо на организационном уровне для классифицированных и контролируемых ITAR сред.
Случай использования ITAR
Специалист по данным в оборонном подрядчике, обрабатывающий персональные записи в соответствии с требованиями ITAR, должен деидентифицировать файлы перед их передачей журналисту, запрашивающему информацию по FOIA. Сеть подрядчика изолирована. Обработка должна происходить на изолированной машине и должна производить выходные данные, подходящие для публичного раскрытия.
Этот случай использования не имеет облачного решения. Единственный путь — это инструмент, который работает полностью на локальной машине, применяет модели обнаружения, хранящиеся локально, и производит анонимизированные выходные данные без какого-либо внешнего общения. Приложение Desktop на базе Tauri 2.0 работает именно в этой конфигурации: после загрузки и установки во время обработки документа не выполняются сетевые вызовы. Модели NER spaCy, шаблоны regex и вывод трансформеров работают локально. Выходные данные обработки никогда не покидают машину, если только пользователь не экспортирует их явно.
Обратимая псевдонимизация для классифицированных операций
Связанное требование в классифицированных и государственных контекстах: обратимая псевдонимизация, которая сохраняет аналитическую полезность, защищая реальные идентичности. Статья 4(5) GDPR формально признает псевдонимизацию как меру защиты данных, которая снижает риск соблюдения — псевдонимизированные данные подлежат сниженным обязательствам по сравнению с полностью идентифицируемыми данными, при условии, что ключи псевдонимизации хранятся отдельно от псевдонимизированного набора данных.
Исследование IAPP (2024) показало, что только 23% инструментов анонимизации предлагают истинную обратимость — возможность расшифровать псевдонимизированные данные обратно в оригинальные значения с использованием ключа, который хранится отдельно от вывода. Большинство инструментов реализуют постоянную замену (оригинальные данные перезаписываются и не могут быть восстановлены) или маскировку (частичное отображение оригинального значения).
Для государственных операций, где псевдонимизированные наборы данных должны быть совместимы между отделами — одна команда получает псевдонимизированный набор данных для аналитической работы, другая команда хранит ключ расшифровки для повторной идентификации, когда это требуется по закону — обратимое шифрование с разделением ключей является единственной соответствующей архитектурой.
Подход с нулевыми знаниями расширяет это дальше: ключ шифрования генерируется на стороне клиента и никогда не передается. Даже если поставщика инструмента анонимизации вызовут в суд, он не сможет предоставить ключ расшифровки, потому что никогда его не получал. Для классифицированных сред, где цепочка хранения ключей шифрования сама по себе является требованием безопасности, эта архитектура обеспечивает необходимую уверенность.
Соответствие рекомендациям EDPB
Рекомендации EDPB 05/2022 по псевдонимизации требуют разделения ключей: ключ псевдонимизации должен храниться другой стороной, чем сторона, получающая псевдонимизированный набор данных, или храниться с техническими контролями, которые предотвращают одновременный доступ получающей стороны как к данным, так и к ключу.
Сочетание генерации ключей на стороне клиента (ключ никогда не покидает устройство пользователя), локальной обработки (данные никогда не покидают изолированную среду) и отдельного экспорта псевдонимизированных выходных данных и ключей расшифровки удовлетворяет требованию EDPB о разделении ключей, одновременно соответствуя операционному ограничению изоляции.
Источники: