Ээта статья представляет собой перевод моей английской статьи, которую вы можете прочитать Здесь .
Заранее прошу прощения за возможные неточности в компьютерной терминологии на русском языке.
Интерфейсы прикладного программирования, или API, отвечают за большую часть системной интеграции и функциональных компонентов современной вычислительной среды как в потребительской, так и в корпоративной среде.
Правильно спроектированные и безопасные API-интерфейсы обеспечивают значительные преимущества при создании новой системы, интеграции с другими системами и на протяжении всего жизненного цикла приложения.
Судя по опыту автора по внедрению API для различных клиентов в финансовом, страховом, телекоммуникационном и государственном секторах, безопасность часто упускается из виду в пользу упрощенной реализации для конкретного поставщика/продукта, что затрудняет интеграцию и приводит к дополнительным затратам на поддержку и реализовать новые функции.
В этой статье рассматриваются методы проектирования безопасности API, не зависящие от продукта, чтобы помочь архитекторам планировать и создавать простые в использовании и безопасные API. Рекомендуемый подход — отделить безопасность API от его бизнес-функций и позволить разработчикам серверной части сосредоточиться только на бизнес-функциях.
Как только бизнес-логика API будет готова, ее можно опубликовать с использованием общих компонентов безопасности, описанных в этой статье.
В этой статье не приводятся какие-либо рекомендации для конкретного продукта, но любая современная платформа безопасности/управления API сможет удовлетворить большинство предлагаемых требований, используя доступные стандартные функции.
API-трафик
Типичный поток трафика для API показан на диаграмме ниже:
Клиент (обычно приложение) отправляет запрос определенной конечной функции API с требуемым типом аутентификации/авторизации, который затем перенаправляется в бизнес-службу, где происходит фактическая обработка запроса.
Как показано на схеме, функции безопасности и дополнительной обработки запросов/ответов находятся за пределами бизнес-функций.
Рекомендуемый подход — иметь набор стандартных функций, которые улучшат безопасность API, удобство использования и лучшую защиту серверных бизнес-сервисов.
Безопасность API обеспечивается следующими стандартными компонентами: 
Рассмотрим предлагаемые функции более подробно: 
Описание API Эта функция дает клиенту возможность запрашивать описания API в машиночитаемом (YAML, XML, JSON) или человекочитаемом (HTML) форматах с помощью простого вызова HTTP GET. Технически это не компонент безопасности API, но это очень полезная функция, которая может значительно упростить использование API и сократить усилия по интеграции.
Наличие как человеко-, так и машиночитаемой документации внутри самого API является полезным ресурсом для тех, кто ищет техническую информацию об API, примеры запросов/ответов, схемы JSON и XML, а также другую информацию.
Клиент может запросить описание API в различных форматах для автоматической настройки кода или для проверки функциональности разработчиком.
В следующей таблице показаны возможные форматы запросов и соответствующие ответы:
| Формат запроса (HTTP-запрос) | Формат ответа |
| Эямл | Описание OpenAPI в YAML |
| Эjson | Описание OpenAPI в формате JSON |
| Эwsdl | Веб-сервис API WSDL в формате XML |
| Эвадл | Служба отдыха API WADL в формате XML |
| Эhtml | Описание OpenAPI в формате HTML |
| Эмыло | Описание WSDL в формате HTML |
| Эотдых | Описание WADL в формате HTML |
Например, существует несколько бесплатных шаблонов XSL, которые можно использовать для автоматического преобразования документов WSDL или WADL в удобочитаемые версии HTML. Описания OpenAPI JSON или YAML также можно представить в удобочитаемом формате HTML с помощью различных инструментов, таких как редактор Swagger. В некоторых случаях эту функциональность можно обеспечить за счет интеграции API с порталом, но для целей данного документа мы оставим ее на уровне API, не привлекая внешние системы или дополнительные компоненты.
Проверка типа контента запроса Проверка типа контента запроса — это первый шаг в тестировании безопасности.
Это необходимо для того, чтобы сообщения с запросами в неправильном формате не дошли до бизнес-сервиса.
Это также позволяет другим проверкам безопасности определить, какой формат сообщения об ошибке потребуется в ответе, если какая-либо из проверок запроса завершится неудачно.
Для типичного API допустимым типом содержимого запроса является application/json для REST JSON, application/xml для REST/XML и text/xml для SOAP. 
Установление TLS-соединения Рекомендуется шифровать трафик запросов и ответов API, чтобы защитить конфиденциальность информации при передаче по незащищенным сетям.
Обычной практикой является использование протокола шифрования SSL/TLS. Обеспечение безопасности должно включать следующие этапы:
- Проверка того, что трафик проходит через туннель TLS, и использование последней версии протокола.
- Туннель TLS использует безопасный набор шифров, цифровых подписей и хэш-функций.
Это требование зависит от технологии и потребует тщательного выбора наиболее безопасных параметров, поддерживаемых сервером и всеми клиентами, которым потребуется подключение к API.
- При необходимости проверку сертификата клиента можно использовать для двусторонних TLS-туннелей.
Запросить авторизацию Эта функция будет аутентифицировать и авторизовать входящие запросы API, используя соответствующие методы аутентификации или их комбинацию:
- Идентификатор пользователя/пароль (напрямую или через системы безопасности, такие как WS-Security)
- API-ключ
- Сертификат клиента
- Федеративный документ (SAML, JWT OIDC)
- OAuth
Следует полагаться на внешнюю службу аутентификации, в которой должны быть установлены соответствующие функции для хранения информации о клиентах, их паролей и других функций безопасности.
Проверка содержимого запроса Эта функция проверяет, что содержимое запроса не содержит компонентов, опасных с точки зрения безопасности, прежде чем передать его бизнес-сервису.
Типы выполняемых здесь проверок будут зависеть от формата запроса (XML или JSON) и могут включать в себя следующие элементы:
- Проверка структуры документа JSON (длина объекта, количество записей объекта, количество записей массива, длина имени записи)
- Структура документа XML (длина непрерывного текста, длина значения атрибута, длина имени атрибута, глубина вложенности элементов)
- Распространенные атаки с использованием SQL-инъекций в теле сообщения запроса, URL-адресе запроса и строке запроса URL-адреса запроса.
- Обнаружение в теле запроса другой информации, которую можно использовать для внедрения команд ОС, LDAP и т. д.
- Проверка безопасности полезной нагрузки для конкретного приложения Эти проверки необходимы для защиты бизнес-сервисов и данных от атак, использующих содержимое запроса.
Проверка HTTP-метода Эта функция проверит, что запрос API получен с использованием правильного метода HTTP (GET, POST, PUT и т. д.).
Один и тот же API может поддерживать несколько методов и операций, поэтому при этой проверке может потребоваться учитывать другие параметры запроса, такие как URL-адрес запроса и строку запроса HTTP. 
Проверка скорости запроса Эта функция проверит глобальную скорость запросов API или конкретную скорость запрошенной операции API. Эта проверка защищает бизнес-сервис от атак типа «отказ в обслуживании» или просто ограничивает частоту запросов, чтобы защитить их от перегрузки.
Скорость сообщений можно настроить как количество одновременных сообщений в секунду или за указанный период времени для поддержки квот API на каждого клиента.
Проверка размера запроса Эта функция проверит, что размер полезных данных запроса не превышает предел для запрошенной операции API. Очень важно предотвратить попадание некорректных (больших) запросов в бизнес-сервис, так как это может привести к множеству нежелательных проблем.
В большинстве случаев типичная полезная нагрузка запроса должна быть меньше нескольких килобайт, если только по определенным причинам не требуется большая полезная нагрузка.
Проверка схемы запроса Эта функция проверяет полезные данные запроса на соответствие соответствующему документу схемы XML или JSON, чтобы убедиться, что запрос семантически корректен для запрошенной операции API. Поскольку проверка схемы запроса может требовать большого количества ресурсов ЦП, проверка здесь может удалить эти операции из бизнес-службы и гарантировать, что данные в запросе построены правильно, прежде чем они достигнут бизнес-службы.
Очевидно, что в случаях, когда принимаются несколько форматов запросов, API должен быть настроен на использование правильной схемы в зависимости от типа полезных данных запроса (XML или JSON).
Преобразование запроса Эта дополнительная функция поддерживает случаи использования, когда полезные данные запроса необходимо преобразовать в формат, требуемый бизнес-службой.
Например, когда клиент отправляет запрос JSON из браузерного приложения AJAX или мобильного приложения, и его необходимо преобразовать в XML-запрос в формате SOAP, поддерживаемый бизнес-службой.
Подключение к бизнес-сервису Эта функция поддерживает подключение и обмен данными с бизнес-сервисом на уровне сети и приложения.
Это необходимо для информирования клиента о любых проблемах с подключением, возникающих во время соединений сетевого или прикладного уровня.
Мы обсудим более подробную информацию при обсуждении конфигураций тайм-аута соединения далее в этом документе.
Обычно эта функция отвечает клиенту сообщением об ошибке и кодом ошибки HTTP 503, указывая на то, что соединение с внутренней системой не удалось.
Проверка ответа бизнес-службы Эта дополнительная функция позволяет проверить реакцию бизнес-службы.
В большинстве случаев ответ может быть немедленно отправлен обратно клиенту, если только перед возвратом его не требуется каким-либо образом проверить.
Преобразование ответа Эта дополнительная функция требуется, когда внутренний формат ответа необходимо преобразовать в другой формат сообщения, понятный клиенту.
Подобно преобразованию запроса, эту функцию можно использовать для преобразования ответа XML SOAP в JSON перед его отправкой клиенту.
Проверка дополнительных условий Это дополнительная функция, которая может проверять любое дополнительное условие, если вам нужно применить дополнительную логику в дополнение к стандартным функциям.
Конфигурация тайм-аута
Правильно настроенные таймауты обслуживания очень важны для правильной обработки ошибок и устранения неполадок.
Их очень часто игнорируют или неправильно настраивают, что приводит к многочисленным проблемам и сбоям в работе API. Правильная конфигурация системного таймаута не должна допускать истечения времени ожидания клиентского соединения до истечения времени ожидания системы, к которой он пытается подключиться: 
В этой конфигурации значение тайм-аута чтения системы API безопасности должно быть как минимум на одну секунду выше, чем значение тайм-аута бизнес-службы, а значение тайм-аута чтения клиента должно быть как минимум на две секунды больше, чем тайм-аут бизнес-службы.
Если таймауты настроены неправильно, то в некоторых случаях правильные ответы от бизнес-сервиса и/или системы безопасности API будут потеряны, что приведет к сбою клиентского приложения.
Обработка ошибок
Большая часть логики безопасности API предназначена для правильной обработки ошибок, что помогает интегрировать клиентские приложения и быстро устранять неполадки.Коды ошибок для безопасности API настраиваются с использованием соответствующих кодов ошибок HTTP 400 и 500, как показано на блок-схеме выше.
Очевидно, что ответы об ошибках должны иметь формат, соответствующий полученному запросу.
Для запроса SOAP потребуется формат ошибок SOAP, для REST/XML и REST/JSON потребуются ошибки XML и JSON соответственно.
Реакции на ошибки должны быть информативными и предоставлять достаточно информации для устранения неполадок, но не раскрывать конфиденциальную информацию клиентам, не имеющим авторизованного доступа.
Как минимум, каждый ответ об ошибке должен содержать следующую информацию:
- Описание API и вызываемой операции
- Код ошибки
- Происхождение ошибки и описание с соответствующими подробностями.
- Время ошибки в удобочитаемом формате
- Уникальный идентификатор транзакции сообщения
Во многих случаях система безопасности API успешно обрабатывает запрос, но бизнес-сервис возвращает ошибку.
Один из рекомендуемых способов отделить ошибки безопасности API от внутренних ошибок бизнес-службы — использовать отдельные пространства имен в XML и JSON для системы безопасности API и бизнес-службы.
Таким образом, будет очевидно, какая система отвечает ошибкой.
Ниже приведены примеры сообщений об ошибках в формате XML и JSON, четко указывающие, что они исходят от API Security (APISEC):
<Эxml version="1.0" encoding="UTF-8"?> <APISEC> <Status> <code>401</code> <message>Unauthorized – client failed to present valid api key</message> <api>Get Customer Detail</api> <id>0000015e5892aaa3-23a3</id> <time>Wed Sep 13 04:44:01 2017</time> </Status> </APISEC>
{
"APISEC":{
"Status":{
"code":"401",
"message":"Unauthorized – client failed to present valid api key using SSL/TLS connection",
"api":"Get Customer Detail",
"id":"0000015e5892aaa3-23a5",
"time":"Wed Sep 13 04:45:18 2017"
}
}
}Регистрация событий безопасности API
Ведение журнала событий безопасности API — важный компонент поддержки, необходимый для устранения неполадок системы, анализа производительности API и отслеживания исторических тенденций.Каждая платформа безопасности API имеет свой собственный набор событий безопасности и производительности, но следующие минимальные параметры являются общими и должны записываться для каждой транзакции:
- Идентификатор сообщения (успех/ошибка)
- Временная метка в формате ISO8601 (для взаимодействия с внешними системами)
- URL-адрес запроса
- URL-адрес бизнес-услуги
- Метод HTTP-запроса
- Тип контента HTTP-запроса
- Код ответа HTTP для сообщения, отправленного клиенту
- Описание сообщения об ошибке/успехе
- Имя API/операция
- Идентификатор аутентифицированного пользователя
- Время между запросом и ответом
- IP-адрес клиента
- Уникальный идентификатор транзакции (безопасность API обычно генерирует его автоматически для каждого сообщения)
- Текущее ограничение скорости API
- Запросить размер сообщения
- Размер ответного сообщения
- Могут быть включены дополнительные параметры, специфичные для используемой технологии безопасности API.
Системы безопасности API
Современные платформы безопасности API включают локальные системы, такие как MuleSoft Anypoint, IBM DataPower SOA Gateway, Broadcom Layer7 API Gateway, OKTA Kong API Gateway и другие, предназначенные для реализации всех функций, описанных в этом документе.Для развертывания облачных API все основные поставщики облачных услуг (Azure, AWS, GCP) имеют компоненты управления облачными API, которые также могут поддерживать большинство необходимых функций.
Рекомендуется использовать только готовые функции вышеперечисленных платформ, избегая запуска собственного кода, поскольку это противоречит цели создания автономной системы, основанной на безопасности API, с низкими затратами на установку и поддержку.
Антипаттерны безопасности API
В заключение хотелось бы привести примеры плохих практик, связанных с реализацией безопасности API. В рамках безопасности API следует избегать использования следующих технологий:- Управление сеансами приложений, требующее создания и хранения постоянных сеансов в системе безопасности API.
- Обработка сообщений с сохранением состояния.
Любая обработка сообщений с отслеживанием состояния на шлюзе безопасности API потребует хранения и получения атрибутов сообщений на платформе шлюза API, что может поставить под угрозу его производительность и управляемость.
В некоторых особых случаях шлюз может использоваться для защиты от повтора сообщений с использованием кэш-памяти.
- Асинхронная обработка сообщений.
Асинхронный поток сообщений требует, чтобы шлюз API генерировал постоянные идентификаторы сообщений и обрабатывал асинхронные ответы, что не является естественной функцией платформы шлюза API и должно быть доступно служебной шине для обработки.
-
Хорошо Ли Спамерам Живётся На Руси...
19 Oct, 24 -
Какую Периодику Ты Читаешь, %Username%?
19 Oct, 24 -
Поздравляем Дорогих Дам
19 Oct, 24 -
Microsoft Купила Биржу Онлайн-Рекламы
19 Oct, 24
