Анализ правил безопасности
Преимущества:
- Сокращение времени вычисления правил безопасности (повышение производительности)
- Обеспечение читабельности/масштабируемости правил.
Цель
В центре этого поста – анализ правил безопасности на предмет качества, что в конечном итоге повышает удобочитаемость, производительность и масштабируемость. В этой статье будут рассмотрены два варианта: первый – с помощью QMC (руководство), второй – используя приложение qs-security-rules-analyzer.
Для аудита см. раздел «Аудит доступа пользователей»
При написании правил безопасности важно подумать о том, как они будут масштабироваться и насколько легко другим их будет читать и понимать. Конечно, бывают случаи, когда правила должны быть довольно сложными и их будет довольно трудно читать, но в целом это должны быть отдельные специальные сценарии для очень детальных требований.
Удобочитаемость
При написании правил безопасности постарайтесь разбить форматирование на несколько строк, чтобы правило можно было легче усвоить человеку. Например, вот совершенно правильное правило:
(resource.resourcetype = "App" and resource.stream.HasPrivilege("read") and resource.@AppLevelMgmt.empty()) or ((resource.resourcetype = "App.Object" and resource.published = "true" and resource.objectType != "app_appscript") and resource.app.stream.HasPrivilege("read"))
Вот то же правило, но в другом формате:
(
resource.resourcetype = "App"
and resource.stream.HasPrivilege("read")
and resource.@AppLevelMgmt.empty()
)
or
(
(
resource.resourcetype = "App.Object"
and resource.published = "true"
and resource.objectType != "app_appscript"
)
and resource.app.stream.HasPrivilege("read")
)
Второе, безусловно, легче читать.
И наконец, сделайте качественное описание (поле «Description») правила безопасности. Обычно просто записывают псевдокод.
Масштабируемость
При написании правила нужно убедиться, что оно может масштабироваться. Хотя ((user.name="Rodion Romanovich Raskolnikov") или (user.name="Sofya Semyonovna Marmeladov")) работает для пары пользователей, по мере того, как все больше и больше пользователей входят в систему, этот стиль правила 1:1 быстро становится очень трудно поддерживать. Кроме того, представьте, что г-н Раскольников теперь меняет роли и больше не должен видеть ресурс, к которому применяется правило безопасности. Во-первых, нужно знать, что он сменил роли, а во-вторых, удалить его из этого правила безопасности. Такие правила не просто поддерживать. Вместо этого следует использовать группы, будь то user.group или user.environment.group или user.@SomeCustomGroup. Это правило стиля 1 ко многим хорошо масштабируется и, как правило, не требует вмешательства, особенно при использовании первых двух параметров, поскольку они являются динамическими и поступают из источника, а не жестко заданными в качестве настраиваемого свойства (custom property).
Подводя итог, вместо того, чтобы писать это:
((user.name="Rodion Romanovich Raskolnikov") or (user.name="Sofya Semyonovna Marmeladov"))
напишите что-то вроде этого, где ресурсу присвоено жестко заданное значение настраиваемого свойства, которое совпадает с динамическим значением из свойства группы, скажем, из Active Directory. Затем это правило полностью отключается и динамически масштабируется для многих пользователей.
((resource.@Department=user.group))
Производительность
Еще одна область, к которой следует очень внимательно относиться – это выполнение вычисления правил безопасности. Однозначно, вычисление правил со многими и/или условиями займет больше времени. Здесь особенно стоит обратить внимание на количество значений в поле настраиваемых свойств, по которым будет вычисляться правило безопасности. Если в поле настраиваемого свойства есть тысячи потенциальных значений, это значительно увеличит время оценки.
Следующие рекомендации могут быть использованы для оптимизации, если это необходимо:
- Будьте как можно более конкретными – лучше отфильтрованные результаты будут работать лучше (чем ниже гранулярность, тем лучше).
|
Фильтр ресурса |
Объяснение |
Эффективность |
|---|---|---|
|
* |
Доступ ко всему в Qlik Sense |
Наименее эффективный |
|
App* |
Доступ ко всем приложениям и объектам App.Object |
Эффективнее, чем указано выше |
|
App_* |
Доступ ко всем приложениям |
Эффективнее, чем указано выше |
|
App_d1309075-86e8-4784-a9fd-2658ab47018e |
Получите доступ к приложению с идентификатором d1309075-86e8-4784-a9fd-2658ab47018e |
Эффективнее, чем указано выше |
-
Используйте только требуемый Контекст
- У правил безопасности есть варианты контекста Хаб, QMC или Оба. Будьте как можно более конкретными.
- Избегайте доступа к ресурсу через цепочку ссылок.
- Примером этого может быть user.@customproperty=resource.app.stream.@customproperty. В этом примере настраиваемое свойство пользователя сравнивается с ресурсом (объектом), принадлежащим приложению, которое принадлежит потоку, имеющему настраиваемое свойство.
- Сведите к минимуму количество значений настраиваемых свойств.
- Например, resource.app.stream.owner.@a = "b" or user.name = "user1". В этом примере все владельцы потока должны оцениваться на предмет наличия настраиваемого свойства, и только после этого оценивается имя пользователя. Указывайте в правиле наиболее ограничивающие условия в начале. Например: user.group="rare" and user.group="common"). Это сводит к минимуму количество пользователей, для которых необходимо оценить 2-е условие правила.
- Пример: App.Stream.HasPrivilege("read"). Эта функция требует дополнительного механизма правил для проверки прав на чтение в потоке приложения.
- Настраиваемые свойства с сотнями значений ресурсоемки в обработке.
- Порядок исполнения имеет значение.
- Избегайте использования HasPrivilege
Антипаттерны в правилах безопасности
Чтобы гарантировать качество правил безопасности, следует обратить внимание на следующие моменты: вручную через QMC или программно с помощью прилагаемого приложения.
Не создавать
-
Правила стиля 1:1, например
- Правила, содержащие .name
- Правила, содержащие .id
- Правила, содержащие *
- Правила, содержащие много операторов and or .
- Правила, которые ссылаются на настраиваемое свойство, имеющее много возможных значений (сотни или тысячи).
QMC – Правила безопасности
Чтобы вручную просмотреть правила безопасности, перейдите в QMC, а затем выберите вкладку «Security Rules» («Правила безопасности»).
Щелкните «Column Selector» («Выбор столбцов») и добавьте столбец «Conditions» («Условия»).
Выберите фильтр в столбце «Conditions» («Условия»), а затем найдите любые недопустимые методы, например name, .id, *, и т. д.
В качестве дополнительного шага отфильтруйте столбец «Disabled» («Отключено») на «No» («Нет»), чтобы просматривать только активные правила безопасности.
Это, конечно, очень ручной процесс, который может оказаться довольно сложным для использования. Для автоматизированного процесса, который собирает все отмеченные недопустимыми методы и позволяет провести более глубокий анализ, пожалуйста, изучите приложение ниже.
Анализатор правил безопасности
Приложение «qs-security-rule-analyzer» – это приложение, поддерживаемое командой «Americas Enterprise Architecture» из Qlik. Это очень простое приложение, которое обращается к QRS (базе данных репозитория), которая извлекает метаданные о настраиваемых свойствах и всю информацию о правилах безопасности. Само приложение использует преимущества существующего подключения к данным monitor_apps_REST_app, поэтому нет установщика, и оно работает по принципу plug and play, выполните настройку пары переменных и убедитесь, что пользователь, выполняющий перезагрузку, имеет права RootAdmin и доступ к подключению к данным. Полные инструкции по установке можно найти в скрипте.
Загрузите приложение можно здесь: qs-security-rule-analyzer
