Белый список IP-адресов
Белый список IP-адресов на входе в API (наименее безопасный, но самый простой в использовании)
Я считаю его наименее безопасным, если выявляются IP-адресами из белого списка, которые не являются эксклюзивными для офиса вашей компании и / или этот IP-адрес предназначен исключительно для вашей компании, но используется общедоступным WI-fis в вашей компании.
Также в случае, если вам нужен доступ к удаленному белому спискуразработчики и тестировщики, которые могут находиться или не находиться в общедоступных IP-адресах, это решение будет рискованным, потому что люди всегда ставят удобство перед безопасностью и могут попросить внести в белый список IP-адреса из кафе, с которым им нравится работать, в торговом центредом подруги и т. д.
Так что я бы отказался от этой опции, если вы не находитесь в небольшом офисе, где у вас есть общедоступный Wi-Fi (тот, который используют ваши клиенты) на другом IPот вашего основного подключения к Интернету.
VPN-шлюз
VPN-шлюз к среде хостинга с соответствующей конфигурацией DEV / test deviceрацион
Этот подход кажется более разумным, и только те, кому был предоставлен доступ к VPN, смогут использовать скрытые за ним ресурсы, а виртуальные частные сети могут даже использоваться в общедоступных WI-сетях.fi.
Взаимная аутентификация TLS
Взаимная аутентификация TLS (сложнее всего реализовать и использовать)
Хотя их сложно реализовать и использовать, они также страдаютпроблемы пиннинга сертификата можно обойти.
В этой статье о закреплении в мобильных приложениях мы можем прочитать, как легко реализовать закрепление сертификата:
// simplified android example
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.add("bikewise.org", "sha256/x9SZw6TwIqfmvrLZ/kz1o0Ossjmn728BnBKpUFqGNVM=")
.build();
OkHttpClient client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();
В этой же статье мы также можем увидетькак пиннинг может быть кошмаром ... как вы сказали, трудно управлять !!!
Основная сложность пиннинга не техническая, а эксплуатационная.Встраивая фиксированную информацию о сервере (сертификате) в приложение, вы создаете зависимость между ними, как подразумевает термин «закрепление».Это означает, что всякий раз, когда вы (или ваша рабочая группа) планируете изменить сертификат на сервере, вы должны:
- Заранее сгенерировать сертификат
- Создать, протестировать и опубликовать новыйверсия приложения с новым и старым сертификатом.
- Подождите, пока большинство пользователей (80%, 90%, 99%?) обновятся до новой версии
- Изменитьсертификат на сервере
- Сборка, тестирование и публикация новой версии приложения с удаленным старым сертификатом.
Как будто этого было недостаточно, закрепление сертификата можетбыть пропущенным с помощью фреймворков самоанализа, как указано в той же статье, на которую я ссылался выше:
Даже если вы успешно справитесь с трудностями, связанными с реализацией пиннинга, в комнате все еще остается гигантский розовый слонэто открепление.Разработка перехватчиков, таких как Xposed, достигла такого уровня сложности, что существует богатая экосистема модулей, предназначенных для различных аспектов приложений Android, включая функциональность закрепления библиотек HTTP.Использовать их очень просто.
Другой подход - пройти лишнюю милю
Тем не менее, проект также включает в себя мобильные приложения, которые разрабатываются вместе с облачным APIlayer.
В контексте мобильных приложений вы можете использовать метод, разработанный как аттестация мобильных приложений, который можно использовать во всех средах для защиты сервера API, для мобильных приложений, от ответа назапросы, которые не исходят из подлинного двоичного файла мобильного приложения, которое вы выпустили, подписали и зарегистрировали для этой конкретной среды.
Аттестация мобильного приложения
Роль службы аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано или не запущено на корневом устройстве.Он состоит из SDK, встроенного в мобильное приложение, которое работает в фоновом режиме, не влияя на работу пользователя, и взаимодействует со службой, работающей в облаке, для подтверждения целостности мобильного приложения и работающего устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Мобильное приложение должно отправить токен JWT в заголовках запроса для самого вызова API.это делает.Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить подпись и время истечения срока действия в токене JWT и отклонить их в случае неудачной проверки.
Любой, кто пытается проверить во время выполнения, выдан ли токен JWTАттестация мобильного приложения действительна или недействительна, не удастся, потому что единственное различие между ними - это секрет, используемый для его подписи, и этот секрет в любое время известен только службе аттестации мобильных приложений и серверу API.Это означает, что даже мобильное приложение не обладает секретом, поэтому не знает, отправляет ли действительный или недействительный токен JWT на сервер API.
Заключение
Из ваших трех решенийЯ бы остановился на подходе VPN, и если вы хотите пройти лишнюю милю, вам следует подумать о внедрении собственной службы аттестации мобильных приложений, чтобы гарантировать, что мобильные API-интерфейсы для любой среды взаимодействуют только с мобильными приложениями для этой конкретной среды / этапа и отклонять запросы отлюбой другой источник.Это решение даже позволяет размещать ваш мобильный API в общедоступном домене, не рискуя потерять какие-либо данные, и, следовательно, не требует VPN-подключения перед ним.