Ваша проблема
Я разработал API в точечной сети.Этот API используется другим приложением.Я должен генерировать разные ключи для каждого приложения, которое используется этим API.
При создании API, независимо от того, используется ли оно одним или несколькими приложениями, вам необходимо учитывать тот факт, что ЧТО обращается к API, а иногда вам также нужно заботиться о КТО обращается к нему.
Имея это в виду, давайте выясним распространенное среди разработчиков заблуждение относительно ВОЗ и ЧТО обращается к серверу API.
Разница между ВОЗ и ЧТО обеспечивает доступ к серверу API
Я не знаю, являются ли приложения, использующие API, мобильными или сетевыми, но я проведу аналогию с помощью мобильного приложения.и для веб-приложения разница между WHO и WHAT не будет иметь значения.
Чтобы лучше понять различия между WHO и ЧТО обращаются к мобильному приложению, давайте используем эту картинку:
Предполагаемый канал связи представляет мобильное приложение, используемое, как вы ожидали,леGit-пользователь без каких-либо злонамеренных намерений, использующий версию мобильного приложения без изменений и общающийся напрямую с сервером API, не подвергаясь атаке человека посередине.
Фактический канал может представлять несколько различных сценариев, например, законный пользовательсо злонамеренными намерениями, которые могут использовать переупакованную версию мобильного приложения, хакер использует подлинную версию мобильного приложения, а посредник атакует его, чтобы понять, как осуществляется связь между мобильным приложением и сервером APIчтобы иметь возможность автоматизировать атаки на ваш API.Возможны многие другие сценарии, но мы не будем перечислять здесь каждый.
Я надеюсь, что к настоящему времени у вас уже может быть подсказка, почему WHO и WHAT не одно и то же, но если нет, то это станет ясно через мгновение.
WHO является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, напримериспользуя OpenID Connect или потоки OAUTH2.
OAUTH
Обычно OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса.,Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных.Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса.Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID Connect
OpenID Connect 1.0 представляет собой простой слой идентификации поверхпротокол OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Хотя аутентификация пользователя может сообщить серверу API WHO использует API, она не может гарантировать, что запросы исходили из ожидаемой WHAT исходной версии мобильного приложения..
Теперь нам нужен способ определить ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. WHAT - это то, что делает запрос к серверу API.Действительно ли это подлинный экземпляр мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется в сервере API с помощью такого инструмента, как Postman?
К вашему удивлению, вы можете обнаружить, что это может быть один из законных пользователей, использующих переупакованную версию мобильного приложения или автоматизированный скрипт, который пытается геймифицировать и воспользоваться службой, предоставляемой приложением.
Что ж, для определения ЧТО разработчики склонны прибегать к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения.Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в мобильном приложении, таким образом, он становится секретом времени выполнения в отличие от предыдущего подхода, когда в код встроен статический секрет.
Запись выше-up была извлечена из статьи, которую я написал, под названием ПОЧЕМУ ВАШЕ МОБИЛЬНОЕ ПРИЛОЖЕНИЕ НУЖНО КЛЮЧ API? , и которую вы можете прочитать полностью здесь , то есть первая статья всерия статей о ключах API.
Защита сервера API
Может кто-нибудь поделиться своими идеями.
Мобильное приложение или веб-приложение должносвязываться только с сервером API, который находится под вашим контролем, и любой доступ к службам API третьей части должен осуществляться тем же сервером API, которым вы управляете.
Таким образом вы ограничиваете поверхность атаки только одним местом, где выбудет использовать столько уровней защиты, сколько стоит ваша защита.
Для API, обслуживающего веб-приложение, вы можете использовать несколько плотных уровней, начиная с reCaptcha V3 , за которым следует Брандмауэр веб-приложений (WAF) и, наконец, если вы можете себе это позволить, решение Поведение пользователя (UBA).
Google reCAPTCHA V3 :
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений.reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте.Он делает это, позволяя вашим действительным пользователям легко проходить через них.
... помогает вам обнаруживать оскорбительный трафик на вашем сайте без каких-либо проблем со стороны пользователей.Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам большую гибкость для принятия соответствующих действий.
WAF - брандмауэр веб-приложений :
Брандмауэр веб-приложений (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него.WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами.Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильная конфигурация безопасности.
UBA -Аналитика поведения пользователя :
Аналитика поведения пользователя (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества.Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы.Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.Платформы больших данных, такие как Apache Hadoop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.
Все эти решения работают на основе модели отрицательной идентификации, другимислова, которые они стараются отличить плохое от хорошего, определяя, что плохо, а не что хорошо, поэтому они склонны к ложным срабатываниям, несмотря на передовые технологии, используемые некоторыми из них, такие как машинное обучение и искусственный интеллект.
Таким образом, вам может понадобиться чаще, чем вам расслабляться, блокировать доступ к API-серверу, чтобы не влиять на хороших пользователей. Это также означает, что этим решениям требуется постоянный мониторинг для проверки того, что ложные срабатывания не блокируют ваших законных пользователей и в то же время они должным образом защищают неавторизованных пользователей.
В отношении API, обслуживающих мобильные приложения, модель положительной идентификации можно использовать с помощью решения для аттестации мобильных приложений, которое гарантирует серверу API, что запросы можно доверять без возможности ложных срабатываний.
Аттестация мобильного приложения
Роль службы аттестации мобильных приложений заключается в том, чтобы гарантировать во время выполнения, что ваше мобильное приложение не было взломано или не запущено на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке. чтобы подтвердить целостность мобильного приложения и работающего устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке. В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно восстановить его во время выполнения, даже когда приложение подделано, работает на корневом устройстве или связывается по соединению, которое является целью человека в средней атаке.
Служба аттестации мобильных приложений уже существует в качестве решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
Краткое описание
Я думаю, к настоящему времени должно быть совершенно ясно, что вам нужно будет использовать ключ API для каждого приложения для идентификации ЧТО , и если вам небезразлично WHO , вам следует используйте решение OAUTH, а затем выберите, какие уровни защиты вы хотите разместить на сервере API, чтобы гарантировать, что вы действительно знаете, что WHAT и WHO обращаются к API сервер действительно те, которые вы ожидаете.
В конце концов, решение, которое будет использоваться для защиты вашего API-сервера, должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, такими как нормативы GDPR в Европе.
Таким образом, использование ключей API может звучать как запирание двери вашего дома и оставление ключа под ковриком, но не использовать их - все равно, что оставить машину на стоянке с закрытой дверью, но ключ в замке зажигания.
Пройдя лишнюю милю
Впервые я делаю такие задачи.
Так что я настоятельно рекомендую вам прочитать некоторые ссылки ...
Веб-приложения
Топ 10 рисков OWASP Web
OWASP Top 10 - мощный информационный документ по безопасности веб-приложений. Он представляет широкий консенсус в отношении наиболее критических угроз безопасности для веб-приложений. Участники проекта включают в себя множество экспертов по безопасности со всего мира, которые поделились своим опытом для составления этого списка.
Мобильные приложения
Проект мобильной безопасности OWASP - 10 основных рисков
OWASP Mobile Security Project - это централизованный ресурс, предназначенный для того, чтобы предоставить разработчикам и командам безопасности ресурсы, необходимые для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски мобильной безопасности и обеспечить средства контроля развития, чтобы уменьшить их влияние или вероятность эксплуатации.