Может ли Quicksight поддерживать многопользовательскую аренду с использованием разных баз данных с одинаковыми наборами данных и панелями мониторинга?

#multi-tenant #amazon-quicksight

Вопрос:

Мы храним уникальные данные о клиентах в отдельной базе данных Redshift и хотим, чтобы каждый из этих клиентов использовал общий набор информационных панелей в Amazon Quicksight для нашего встроенного приложения SAAS. Если бы это сработало, мы бы хотели изменить имя базы данных для каждой группы пользователей-клиентов, чтобы они видели только свои данные.

Кто-нибудь знает, возможно ли это?

Комментарии:

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

2. Драйвер базы данных является родным для Redshift. У нас уже есть весь контент в уникальных базах данных, поэтому нелегко или целесообразно говорить об изменении иерархии баз данных

3. Я не имею в виду драйвер базы данных — я имею в виду, в чем причина? это безопасность? это производительность? это для того, чтобы разрешить обратную зарядку? — мне нужно это знать, чтобы построить ответ

4. Безопасность, многие из наших клиентов являются конкурентами друг друга

Ответ №1:

Я также в настоящее время исследую эту тему. Из того, что я понял, это то, что этого можно достичь, проверьте сообщение в блоге с AWS и здесь

Что мы могли бы сделать, так это создать шаблон на основе анализа и создать панель мониторинга с различными фильтрами/наборами данных для каждого клиента. Затем мы присваиваем идентификатор панели мониторинга клиенту. Когда клиент получит доступ к нашей платформе и захочет проверить встроенную панель мониторинга, наш интерфейс запросит URL-адрес панели мониторинга у нашего сервиса. Эта служба знает, какой пользователь и, следовательно, какой арендатор запросил URL-адрес, и будет искать назначенный идентификатор панели мониторинга. С помощью идентификатора панели мониторинга наш сервис будет использовать пакет sdk aws для получения подписанного URL-адреса панели мониторинга встраивания. Этот URL-адрес будет передан обратно в наш интерфейс. Затем интерфейс будет использовать javascript sdk quicksight с встроенным URL-адресом для отображения конкретной панели мониторинга.

Что нам нужно сделать, так это:

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

Не уверен, что это правильный путь … но сейчас мы находимся именно здесь. Преимущества заключаются в том, что нам не нужно использовать пользователей quicksight или федеративных пользователей IAM.

Комментарии:

1. Мы пришли к тому же выводу при поддержке AWS и завершили создание среды в пилотном режиме. Пользователи передаются на различные информационные панели на основе их аутентификации и сопоставления, которое мы создали, чтобы сопоставить их с соответствующими базовыми базами данных redshift. Не самая простая вещь для реализации, но она логична с помощью API.

Ответ №2:

В рамках QuickSight, если у вас есть несколько подключений к разным кластерам красного смещения, единственный способ изменить подключение, используемое в анализе или панели мониторинга, — это вручную.

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

Вместо этого вам следует подумать :

  • Самое лучшее и безопасное : используйте несколько учетных записей AWS, по одной для каждого клиента, у каждого из которых есть собственный экземпляр QuickSight.
  • Гораздо менее безопасно, но дешевле: в рамках одной учетной записи quicksight создавайте отдельные аналитические и информационные панели для каждого клиента