Управление версиями API без утечек данных: совместимость, «мягкое» снятие старых полей и контроль клиентов
В современном мире API заняли лидирующую роль в создании и развитии онлайн-сервисов. Использование этой технологии позволяет быстро добавлять новые возможности, осуществлять интеграции различных систем, гибко масштабировать сервисы при росте клиентской базы. Обратной стороной является необходимость поддержки большого количества микросервисов и их версий.
Например, для мобильных клиентов сложно обеспечить одновременное обновление приложений на всех телефонах, иногда этот процесс растягивается на месяцы и даже годы. И все это время необходимо думать об обратной совместимости, что создает предпосылки к появлению забытых API. Под «забытыми» обычно понимают старые версии сервисов, которые уже не поддерживаются, но доступны онлайн. Отсутствие поддержки означает отсутствие обновлений, а среди них всегда присутствуют обновления безопасности. Таким образом, рано или поздно в забытом API появится критическая уязвимость, через которую хакер сможет похитить данные или скомпрометировать сервер.
Высокая скорость разработки и разнообразие сервисов также приводит к возникновению теневых API. Под «теневыми» подразумевает любые неуправляемые и недокументированные API. Это могут быть внутренние API для межсервисной интеграции, мониторинговые или административные API, которые не должны быть доступны из сети Интернет. Каждый случай утечки данных через такие API, как правило, приводит к существенным потерям: как репутационным, так и финансовым.
Еще одним негативным эффектом быстрого развития API являются случаи, когда разработчик забывает добавить аутентификацию или авторизацию. Такие сценарии почти всегда приводят к утечкам, так как пользователь получает доступ к тем данным, к которым у него не должно быть доступа.
Основной мерой защиты от описанных сценариев является инвентаризация, которая позволяет в любой момент времени получить информацию о «живых» API и о том, как и кем они используются. Инвентаризация должна содержать как минимум следующую информацию:
- Список эндпойнтов
- Методы и параметры, которые используются для взаимодействия с эндпойнтами
- Наличие и тип аутентификации
- IP-адреса и User-Agent-ы клиентов API
- Статистика по взаимодействию с API
В User-Agent-е обычно содержится информация о клиентском ПО и окружении. Статистика по этим данным полезна для понимания, какой процент клиентов совместим с вашими версиями API, особенно когда принимается решение об отказе от старых версий.
Дополнительной защитой от утечек является использование спецификации OpenAPI и валидация запросов и ответов на соответствие этой спецификации. Спецификация OpenAPI — это стандарт, который используется для описания API как разработчиками на этапе проектирования сервиса, так и средствами защиты при инспектировании трафика. При таком подходе обычно считается, что неописанные взаимодействия несут угрозу и их блокировка значительно снижает вероятность утечки. Если используется несколько версий одного и того же API, то их обычно располагают по различным url, а версию указывают в части этого url:
- https://api.example.com/shop-api/v1/products
- https://api.example.com/shop-api/v2/operations
Это позволяет валидировать обе спецификации – для старого и нового API.
Еще одним преимуществом использования спецификации OpenAPI является то, что в ней можно отмечать поля, которые планируется удалить в ближайшее время. Вместе с этим рекомендуется делать соответствующие уведомления в ответе от API. Такой подход обеспечивает «мягкий» отказ от старых полей.
Таким образом, инвентаризация и спецификация OpenAPI помогают развивать API, не забывая о совместимости и поддерживая должный уровень защищенности.
