Безопасность API для многосторонних вычислений в федеративной идентификации (RU)

Архитектура нулевого доверияВнедряйте модель нулевого доверия для всех взаимодействий API, предполагая, что ни одна сущность не является надежной по умолчанию, особенно в федеративных средах.

Специфические проблемы MPCРешайте уникальные проблемы безопасности, возникающие при многосторонних вычислениях, такие как защита криптографических долей ключей и управление целостностью распределенных вычислений.

Надежная аутентификация и авторизацияИспользуйте сильные, контекстно-зависимые механизмы аутентификации и детальную авторизацию для контроля доступа к конфиденциальным функциям MPC.

Данные в пути и в состоянии покояОбеспечьте сквозное шифрование для данных в пути и в состоянии покоя, даже для промежуточных долей MPC, для поддержания конфиденциальности и целостности.

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

Понимание федеративной идентификации и MPC

Решения API федеративной идентификации позволяют пользователям один раз пройти аутентификацию у поставщика удостоверений (IdP) и получить доступ к нескольким поставщикам услуг (SP) без повторной аутентификации. Стандарты, такие как OAuth 2.0 и OpenID Connect (OIDC), являются основой этих систем. При федеративной идентификации атрибуты пользователя управляются IdP, а SP получают только необходимую информацию, часто в виде токенов или утверждений.

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

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

Внедрение API-шлюза нулевого доверия для MPC

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

Для MPC в федеративной идентификации API-шлюз нулевого доверия должен:

1. Сильная аутентификация и авторизация: Внедрить взаимный TLS (mTLS) для связи API-API, гарантируя, что как клиент, так и сервер проверяют личности друг друга. Использовать OAuth 2.0 с JWT для аутентификации пользователей и приложений, включая детальные области для ограничения доступа к конкретным функциям MPC. Например, токен может предоставлять доступ только к POST /mpc/compute/average-score, но не к GET /mpc/data/raw-shares.
2. Политики доступа с учетом контекста: Помимо базового управления доступом на основе ролей (RBAC), использовать управление доступом на основе атрибутов (ABAC) или управление доступом на основе политик (PBAC), которое учитывает контекст в реальном времени (например, исходный IP, время суток, состояние устройства, поведенческие аномалии) перед предоставлением доступа к операциям MPC.
3. Ограничение скорости и регулирование: Защита от атак типа «отказ в обслуживании» (DoS) и атак методом перебора, направленных на конечные точки MPC, которые могут быть ресурсоемкими.
4. Проверка и очистка входных данных: Все входные данные для функций MPC через API должны быть строго проверены для предотвращения атак внедрения или некорректных данных, которые могут скомпрометировать целостность вычислений или привести к утечке информации.

Рассмотрим пример, когда федеративная система идентификации использует MPC для проверки возраста пользователя без раскрытия его даты рождения. Вызов API для инициации этого процесса MPC будет проходить через шлюз нулевого доверия. Шлюз сначала проверит сертификат mTLS вызывающего сервиса, затем проверит область действия токена OAuth (age_verification_mpc_initiate), проверит исходный IP-адрес на наличие в известных списках вредоносных IP-адресов и, наконец, перешлет запрос в API оркестратора MPC.

Защита данных и криптографических долей в API MPC

Суть разработки API с сохранением конфиденциальности для MPC заключается в том, как обрабатываются криптографические доли. В отличие от традиционных данных, доли MPC сами по себе бессмысленны, но становятся конфиденциальными при объединении. Поэтому они требуют чрезвычайной защиты:

1. Сквозное шифрование: Все коммуникации, связанные с долями MPC, будь то между клиентом и API-шлюзом или между узлами MPC, должны быть зашифрованы с использованием сильных протоколов, таких как TLS 1.3. Для данных в состоянии покоя (например, временное хранение долей во время вычислений) используйте шифрование AES-256 с надежным управлением ключами.
2. Безопасное управление ключами: MPC опирается на криптографические ключи для генерации и восстановления долей. Эти ключи должны генерироваться безопасно, храниться в аппаратных модулях безопасности (HSM) или эквивалентных защищенных анклавах и регулярно ротироваться. API, отвечающие за управление ключами, должны быть наиболее строго защищенными конечными точками.
3. Минимизация раскрытия данных: Сильная сторона MPC заключается в том, что необработанные данные никогда не раскрываются. Убедитесь, что ответы API возвращают только вычисленный результат (например, true для возраста старше 18 лет или агрегированный кредитный рейтинг), а не промежуточные доли или необработанные входные данные.
4. Интеграция гомоморфного шифрования: Для определенных вычислений гомоморфное шифрование может дополнять MPC, позволяя выполнять вычисления непосредственно над зашифрованными данными, что еще больше снижает риски раскрытия на уровне API.

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

{
  "endpoint": "/api/v1/mpc/shares/generate",
  "method": "POST",
  "security": {
    "auth": "mTLS + OAuth2 (scope: mpc.share.generate)",
    "encryption": "End-to-end TLS 1.3",
    "payload_validation": "Strict schema validation for user attributes"
  },
  "description": "Generates cryptographic shares for user identity attributes."
}

Аудит, мониторинг и реагирование на инциденты

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

1. Комплексное ведение журнала: Регистрируйте все запросы и ответы API, уделяя особое внимание попыткам доступа, сбоям аутентификации, отказам в авторизации и любым аномалиям, связанным с вычислениями MPC. Убедитесь, что журналы неизменяемы и надежно хранятся.
2. Мониторинг и оповещение в реальном времени: Внедрите системы управления информацией и событиями безопасности (SIEM) для агрегирования журналов и обнаружения подозрительных паттернов в реальном времени. Оповещения должны срабатывать при необычных всплесках вызовов API, неудачных попытках аутентификации с новых IP-адресов или отклонениях во времени вычислений MPC.
3. Регулярные аудиты безопасности и тестирование на проникновение: Проводите периодические аудиты безопасности, включая проверку кода реализации API и тестирование на проникновение, с особым акцентом на уязвимости MPC (например, атаки по сторонним каналам, восстановление долей из частичной информации).
4. План реагирования на инциденты: Разработайте четкий план реагирования на инциденты, адаптированный для MPC и федеративной идентификации. Этот план должен определять роли, протоколы связи и шаги по локализации, устранению и восстановлению после нарушений безопасности, особенно тех, которые связаны с компрометацией криптографических долей.

Как Didit помогает

Didit предоставляет комплексную платформу идентификации, которая изначально поддерживает безопасную проверку личности с сохранением конфиденциальности. Наша архитектура, созданная для эпохи ИИ, по умолчанию включает в себя надежные принципы безопасности API. Фокус Didit на многоразовом KYC и биометрической повторной аутентификации идеально соответствует модели федеративной идентификации, позволяя пользователям проходить проверку один раз и безопасно делиться своей личностью на различных платформах. Хотя основные предложения Didit не предоставляют напрямую API MPC клиентам, наша базовая инфраструктура использует передовые криптографические методы и безопасные анклавы для обработки конфиденциальных данных, обеспечивая сохранение конфиденциальности на каждом этапе жизненного цикла проверки. Наша платформа разработана с учетом принципа нулевого доверия, предлагая надежную аутентификацию, детальную авторизацию и постоянный мониторинг для защиты всех взаимодействий API и обеспечения целостности данных идентификации.

Готовы начать?

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

• Посетите веб-сайт Didit
• Прочитайте нашу техническую документацию
• Получите доступ к консоли для бизнеса

FAQ

В: В чем заключается основная проблема безопасности API в федеративной идентификации MPC?

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

В: Как API-шлюз нулевого доверия повышает безопасность MPC?

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

В: Можно ли использовать MPC для проверки личности без раскрытия персональных данных?

О: Да, MPC можно использовать для проверки личности без раскрытия необработанных персональных данных. Стороны могут совместно вычислять функцию (например, проверять возраст, подтверждать совпадение личности) на основе своих зашифрованных входных данных, раскрывая только результат вычисления, а не базовые конфиденциальные данные.

В: Какую роль играет шифрование в обеспечении безопасности API MPC?

О: Шифрование играет решающую роль, защищая доли MPC и данные как при передаче (с использованием TLS), так и в состоянии покоя (с использованием AES-256). Это гарантирует, что даже если канал связи API или место хранения будут скомпрометированы, конфиденциальные криптографические доли останутся нечитаемыми и непригодными для использования злоумышленниками.