Использование API Gateway для обеспечения суверенитета данных и соответствия требованиям

Предыстория и вызовы

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

Все больше законодательных органов разных стран осознают серьезность и срочность этой проблемы. Они ввели множество законов и нормативных актов для регулирования сбора данных и их трансграничной передачи. Общий регламент по защите данных (GDPR) в Европе и Закон о переносимости и подотчетности медицинского страхования (HIPAA) в США являются пионерами в этой области. Многие развивающиеся страны также активизируются:

Малайзия: Закон о защите персональных данных 2010 года (PDPA), вступил в силу в ноябре 2013 года.
Китай: Закон о кибербезопасности Китайской Народной Республики, Закон о безопасности данных Китайской Народной Республики и Закон о защите персональной информации Китайской Народной Республики были приняты последовательно с 2017 по 2021 год.
Бразилия: Общий закон о защите данных Бразилии (BGDP), вступил в силу в сентябре 2020 года.
Таиланд: Закон о защите персональных данных Таиланда (PDPA), вступил в силу в июне 2022 года.

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

- Какие данные можно собирать? Какие нельзя?

- Как и где хранятся данные?

- Можно ли передавать данные через границы?

Разработка решений для всех этих вопросов станет масштабным проектом. Здесь мы сосредоточимся на одной проблеме:

Для клиентских данных, передаваемых через API, как определить суверенитет данных на уровне API-шлюза, чтобы обеспечить законную обработку и хранение данных?

Например, американский пользователь, находящийся в командировке в Европе, использует свой мобильный телефон для перевода денег. В этом случае данные транзакции должны обрабатываться и храниться на сервере в США, а не на более близком европейском сервере.

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

Что такое суверенитет данных и соответствие требованиям?

Суверенитет данных

Страна имеет суверенитет не только над физическим пространством, таким как территория, воздушное пространство и территориальные воды, но и над своими данными и национальным киберпространством.

Возьмем, к примеру, Общий регламент по защите данных (GDPR), который является европейским регламентом по защите персональных данных. В GDPR есть одно из самых базовых требований. "Все действия по сбору данных пользователей требуют согласия пользователя, и пользователь имеет право в любой момент удалить свои персональные данные."

Таким образом, если компания хочет передавать европейские данные в другие регионы, она должна убедиться, что требования к суверенитету данных третьей страны соответствуют требованиям ЕС. В связи с необходимостью соответствия данных местным законам, в транснациональных бизнесах действительно возникает множество вопросов.

Еще один вопрос связан с американским Законом PATRIOT, который требует, чтобы все данные, хранящиеся в США, или данные, хранящиеся американскими компаниями, находились под надзором США. Министерство юстиции США и Центральное разведывательное управление (ЦРУ) имеют право требовать от компаний предоставления данных. В 2013 году Министерство юстиции США потребовало от Microsoft раскрыть некоторую информацию из электронной почты, хранящейся на серверах в Ирландии. Microsoft отклонила запрос Министерства юстиции США, так как это нарушило бы требования европейских регуляторов. Затем Министерство юстиции США подало в суд на Microsoft, но Microsoft выиграла дело. Позже, чтобы избежать рисков, связанных с суверенитетом данных, многие компании в США разместили свои центры обработки данных непосредственно в Европе, считая, что это будет безопасно. Тем не менее, в последнее время были случаи, когда судьи постановляли, что США имеют право запрашивать данные у американских компаний в Европе. Это так называемая длинная рука юрисдикции США.

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

Соответствие требованиям данных

Для транснациональных компаний синхронизация данных относительно проста, если нет требований к суверенитету данных. Данные пользователя в США могут легко синхронизироваться с серверами в Азии и Великобритании, как показано на диаграмме ниже. Таким образом, когда американец путешествует по Азии, он также может получить доступ к различным данным, сгенерированным, когда он был в США.

Синхронизация данных между ЦОД

С учетом требований соответствия суверенитету данных, многие данные не могут быть синхронизированы и доступны через границы. Предприятиям необходимо различать пользователей и изолировать связанные с ними данные. Стандартный метод — разделение пользователей по регионам.

Возьмем, к примеру, Amazon Kindle: электронные книги, купленные пользователями в США, не могут быть загружены на их Kindle с китайским аккаунтом. Это связано с тем, что данные между разными странами (регионами) полностью изолированы. Архитектура системы выглядит следующим образом:

Доступ только к своему ЦОД

Итак, что следует сделать технически, если пользователь из Великобритании хочет получить доступ к Amazon UK с американским аккаунтом? Давайте рассмотрим архитектурную диаграмму ниже. Большинство существующих продуктов API-шлюзов предлагают аналогичные решения.

Существующее решение на уровне API-шлюза

Решение API-шлюза для соответствия данным

Мы можем сформулировать суть этого решения в одном предложении:

API-шлюз в Великобритании идентифицирует пользователя. Если API-шлюз определяет, что пользователь зарегистрирован в США, запрос будет перенаправлен на серверы в США для обработки.

Тем не менее, за этим скрываются некоторые технические проблемы, а также скрытые риски соответствия:

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

Есть ли способ решить эти проблемы?

Многослойная сеть: решение Apache APISIX для обеспечения соответствия передачи данных через API

Здесь мы вводим концепцию "многослойной сети" в APISIX для обеспечения соответствия и безопасности данных, передаваемых через API, на уровне API-шлюза. Многослойная сеть, как следует из названия, разделяет API-шлюз на два уровня, Уровень 1 и Уровень 2, как показано на следующем рисунке:

API-шлюз с многослойной сетью для соответствия данным

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

Возвращаясь к вопросу, заданному в начале статьи: как пользователь, зарегистрированный в США, может обеспечить соответствие данных API, независимо от места проведения транзакции?

Сначала запрос API будет отправлен на API-шлюз Уровня 1, который по сути является Apache APISIX, но с добавлением объекта multi-layer network, на котором можно привязывать пользовательские плагины:

API-шлюз Уровня 1 определяет адрес, вес и другую информацию о кластерах API-шлюзов Уровня 2. Здесь мы настраиваем кластер США и кластер Великобритании:

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-US
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-UK
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}

Определяем правила маршрутизации в многослойной сети и привязываем их к плагину bar:

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/routes/bank-foo
{
  "desc": "bank API",
  "hosts": ["foo.com"],
  "uris": ["/*"],
  "plugin_id": "bar"
}

Определяем пользовательские плагины:

http://***/apisix/admin/multilayer_network/plugins/bar
{
  "desc": "plugin",
  "plugins": {
    "jwt-auth": {
      ... ...
    },
    "foo-upstream-selector": {
      "scheme": "HTTPS"
      ... ...
    },
    ... ...
  }
}

Здесь мы привязали два плагина. Плагин jwt-auth используется для завершения аутентификации запроса. Плагин foo-upstream-selector используется для чтения информации, такой как идентификатор пользователя, страна/регион и кластер, к которому принадлежит пользователь, из базы данных, и указывает, на какой кластер API-шлюза Уровня 2 он должен маршрутизироваться.

Эта многослойная архитектура обеспечивает соответствие данных в разных странах.

Заключение

Короче говоря, тонкая настройка маршрутизации, обеспечиваемая многослойной архитектурой API-шлюза, помогает предприятиям быстро и безопасно обрабатывать данные API, одновременно обеспечивая соответствие требованиям данных. Мы предоставляем эту функциональность "из коробки" в API7 Cloud и API7 Enterprise. Пожалуйста, заполните форму, чтобы связаться с нами.