Неконтролируемый рост API может привести к негативным последствиям, которые могут усугубить небезопасную практику кодирования, пишет на портале The New Stack независимый эксперт в области API Билл Доррфельд.

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

Все больше и больше микросервисов создается для того, что Gartner называет «композитным предприятием». Например, в отчете Rapid «2022 State of APIs» говорится, что крупные компании с 10 000 и более сотрудников, как правило, имеют более 250 внутренних API. Эти интерфейсы также играют ключевую роль в создании новых SaaS-продуктов и партнерских экосистем. Однако не все эти точки интеграции тщательно контролируются.

Недавно в основополагающий список 10 главных рисков безопасности API, составленный OWASP, были добавлены два новых — неправильное управление инвентаризацией и небезопасное использование API. Это отражает растущие проблемы с получением точной картины API-объектов организации и растущие риски, связанные со слепой интеграцией сторонних API. И без должного управления внезапный рост числа инструментов и API, связанных с генеративным ИИ, может усугубить существующий технический долг.

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

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

Определение понятия «разрастание API»

EON Consulting описывает разрастание технологий как «неконтролируемое распространение в организации различных технологий — будь то ПО, оборудование или облачные сервисы». В определенной степени технический долг неизбежен в связи с растущей зависимостью от цифровых технологий. Но когда рост действительно выходит из-под контроля, вы начинаете сталкиваться с негативными последствиями. Это и есть «разрастание».

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

Основной причиной разрастания является огромное количество разрабатываемых API — по оценкам F5, сегодня существует около 200 млн. API. Другим фактором является то, что не все API документированы. По данным отчета Enterprise Management Associates за 2023 г., только 10% организаций полностью документируют свои API. Это означает, что цеховые знания часто уходят за дверь вместе с уволившимися разработчиками.

Негативные последствия разрастания API

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

Снижение уровня опыта разработчиков. Несоответствия между API могут негативно сказаться на опыте разработчиков в области интеграции. Например, в современной разработке API используется множество различных парадигм проектирования, включая SOAP, REST, gRPC и более асинхронные форматы, такие как webhooks или потоки Kafka. Организация может использовать разные стили одновременно.

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

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

Разрастание API также может привести к небезопасной практике кодирования. Исследователи безопасности из Escape недавно обнаружили 18 000 секретов и токенов, связанных с API, после сканирования Интернета. Если оставить такие учетные данные незащищенными, они могут быть использованы для целенаправленных атак на корпоративные системы, что может привести к утечкам, снижающим доверие потребителей, и дорогостоящим штрафам.

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

В целом, разрастание API может привести к более хаотичной культуре разработки. И это касается не только ИТ-отдела. Разрастание API также может навредить бизнесу. Например, поспешно приобретенные теневые API могут не вписываться в более широкую ИТ-стратегию. Могут быть скрытые затраты на неэффективные разработки или потери ресурсов при дублировании работы. Сломанные клиенты могут означать потерю функциональности для конечных пользователей, что приведет к снижению доходов.

Идеи по управлению разрастанием API

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

  • Поддерживайте документацию в актуальном состоянии. Подчеркните важность документации по API. Все API, разработанные внутри компании, должны быть полностью документированы. В идеале эта документация должна включать человекочитаемые описания и примеры кода, чтобы помочь другим понять их внутреннюю работу.
  • Проводите инвентаризацию всех ваших API. Помимо документирования каждого API по отдельности, проведите ревизию и создайте каталог всех API, которые ваша организация создала или получила от третьих лиц. Эта информация может быть добавлена, например, в уже существующую внутреннюю платформу для разработчиков (IDP).
  • Объединитесь вокруг спецификации OpenAPI. Спецификация OpenAPI (ранее Swagger) стала де-факто отраслевым стандартом для описания веб-интерфейсов API. Принятие разработки API на основе спецификаций может помочь решить многие из упомянутых выше проблем.
  • Разработайте внутреннее руководство по стилю разработки API. Подобно тому, как редакционная команда имеет руководство по стилю для написания текстов, разработка ПО выиграла бы от создания руководства по стилю, описывающего внутренние соглашения относительно API. Установление защитных ограждений для внутренних стандартов разработки может избавить от необходимости гадать при проектировании API и облегчить процесс использования API. Ознакомьтесь со справочником стилей API, чтобы найти конкретные примеры.
  • Следуйте лучшим практикам безопасности. С самого первого дня разработки API заложите в нее надлежащие средства контроля безопасности. Сюда входят такие передовые методы обеспечения безопасности API, как использование API-шлюза, внедрение OAuth и OpenID Connect, применение многофакторной аутентификации и безопасная работа с токенами. Также полезно принять модель нулевого доверия и следовать правилу наименьших привилегий при назначении диапазонов доступа к API.
  • Автоматизируйте администрирование, когда это возможно. Проверка дизайна очень обременительна, а администрирование ИТ не должно мешать инновациям. Автоматизация тестирования может сместить его на более ранние этапы, позволяя получить лучшее из двух миров. Например, поставщики средств управления API создали множество бесплатных инструментов для оценки дизайна и безопасности спецификаций API, таких как RateMyOpenAPI, API Insights и OpenAPI.security. Spectral также является уникальным инструментом с открытым исходным кодом, который может проверить файл определения OpenAPI на соответствие пользовательским правилам.
  • Рассмотрите другие машиночитаемые спецификации. OpenAPI полезна для таких областей, как создание документации и SDK. Однако она оставляет за рамками некоторые ценные бизнес-данные. APIs.json — интересный развивающийся стандарт, который может помочь улучшить обнаруживаемость API-операций и метаданных.

Долгосрочный взгляд на платформу API

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

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

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