Как безопасно использовать ConnectionString в клиентском (мобильном) коде

Question

Мы используем строку подключения Notification Hub (статический код на данный момент) в качестве входа в метод регистрации NotificationHubSDK. Строка подключения состоит из двух параметров: общий ключ доступа URI конечной точки служебной шины

Постановка проблемы. Мы используем указанные выше параметры в строке подключения, которая предоставляет URI + общий ключ доступа в нашей кодовой базе с использованием response-native-azurenotificationhub. следовательно, если кто-то увидит кодовую базу, сможет получить доступ к концентратору уведомлений через эту информацию. И это может привести к следующей угрозе. Несанкционированный запрос на регистрацию может быть отправлен в центр уведомлений, если кто-то сможет получить доступ к коду.

Возможные решения -

Microsoft рекомендует использовать систему безопасности для созданияПолитику доступа просто слушать, и рекомендую не использовать ключ полного доступа для регистрации на стороне клиента. (Это должно настроить d в центре уведомлений, о котором я говорил) https://docs.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-security

Официальные документы Рекомендовать использовать строку подключения с доступом Listen только в базе кода. https://docs.microsoft.com/en-us/azure/notification-hubs/notification-hubs-android-push-notification-google-fcm-get-started

Обработайте процесс регистрации из внутреннего кода (нашего собственного API), который с помощью Notification Hub Rest Api, Device вызовет службу Platform (FCM или APS) и получит маркер устройства, а затем передасттокен устройства для внутреннего API,

   For achieving above, we need to write our own code, and we cannot utilize the Azure SDK. 

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

   We have discussed and finalized this solution as a workaround, and we are implementing the Web API part.  However, this also has below downside - 
   a. Need one extra API call in order to perform the device registration to notification hub
   b. At this point of time, our API is also not secure so anyone having access to the codebase can still access the final connection string. So the problem statement in the first place still not resolved.

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

Пожалуйста, дайте мне знать, какое будет наилучшее возможное решение,

Answer 1

Оформить заказ в следующем сообщении Установка и управление регистрацией .

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

Теперь, несмотря на это, добавление слоя разделения путем обработки регистраций в бэкэнде все еще может быть хорошимидея. Это даст вам гибкость в случае, если вам нужно обновить строку подключения. Когда учетные данные встроены в приложение, вам придется заставлять своих пользователей обновлять свое приложение, если вам когда-либо понадобится его изменить. Представьте, что у вас есть нарушение безопасности, и вам нужно изменить учетные данные. Если у вас есть бэкэнд, вы просто меняете конфигурацию на стороне сервера и продолжаете двигаться. Если вы этого не сделаете, ваши пользователи больше не будут получать уведомления до обновления. Очевидно, что между этими двумя вариантами пользователи получат больше опыта.