Разграничение прав в WebSphere MQ

Рано или поздно, но наступает момент, когда администратор задумывается о наведении порядка в системе авторизации и предоставления прав на объекты менеджера MQ. Хорошо, если это происходит раньше, чем кто-то случайно, или имея злой умысел разрушит топологию MQ, или получит доступ к “чужой” информации. В данной статье рассмотрим основы построения системы разграничения доступа для Websphere MQ на распределённых средах (Windows, Linux, Unix).

Система разграничения прав строится на предоставлении определённому кругу пользователей доступа к некоторому набору объектов, при этом, к одному и тому же объекту могут быть предоставлены разные права для групп и пользователей в рамках группы. Для того, чтобы предоставленный далее материал был понятен, необходимо выработать общий язык в терминах и определениях, используемых в статье. Давайте рассмотрим их:

  • пользователь – ключевое понятие для организации всей системы доступа, ассоциированное с учётной записью, которая идентифицирует субъекта при прохождении процедуры авторизации (например, ввод системного имени и пароля);
  • группа – логическое объединение нескольких пользователей для предоставления доступа к объектам. Один пользователь может быть привязан к нескольким группам. В Posix системах (Linux, Unix) пользователь всегда связан с группой (это основная группа, по умолчанию её имя совпадает с именем пользователя);
  • объект – под объектом понимаются все типы объектов менеджера (очереди, каналы, сервисы и т.д.) и сам менеджер;

Для работы с системой разграничения прав используются команды: setmqaut и dspmqaut, также задать права доступа к объектам можно с использованием графического интерфейса MQExplorer.

Команда setmqaut предназначена для установки и удаления прав на объекты.

Команда dspmqaut предназначена для просмотра существующих прав установленных для пользователя или группы на определённый объект.

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

Для предоставления прав на посылку сообщения в очередь необходимо выдать команду:

Для предоставления прав на получение сообщения из очереди необходимо выдать команду:

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

Хочу обратить внимание, что есть определённые тонкости в работе с разными версиями WebSphere MQ на распределённых средах. Так, например, для MQ под Linux только с версии 8.0 появилась возможность работать на уровне пользователя. До этого права раздавались на уровне груповой политики, причём, если администратор, по незнанию выполнил бы команду setmqaut с ключом ‘-p’, то ошибки бы он не получил. Данная команда была бы преобразована в команду с ключом ‘-g’, где в качестве имени группы была бы подставлена основная группа пользователя.

Для проверки прав доступа к объекту необходимо выдать команду:

Подробнее тема авторизации в WebSphere MQ рассмотрена в статье: Mission:Messaging: Understanding WebSphere MQ authorization and the setmqaut command

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Метки: , , ,
Опубликовано в WebSphere MQ, Основы
7 комментариев на “Разграничение прав в WebSphere MQ
  1. Александр:

    Авторизация в MQ – вещь интересная, но бесполезная, так как в MQ нет механизма аутентификации (во всяком случае, до версии 7.5 на AIX). При подключении можно указать любой ID пользователя и работать под ним, получив все его права.

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • Sergey Kirsanov Sergey Kirsanov:

      Александр, не соглашусь с Вами.
      Да, в MQ до версии 7.5 (включительно) не используется связка “логин-пароль”, но есть записи идентификации канала (сhannel authentication records), которые вместе с авторизацией при грамотной настройке обеспечивают достаточную защиту менеджера.
      В том числе от приведенного Вами случая. Планируем написать о них отдельный пост.
      В WebSphere MQ V8 появилась аутентификация с использованием LDAP.

      VN:F [1.9.22_1171]
      Rating: 0 (from 0 votes)
      • Александр:

        Поэкспериментировав с настройкой CHLAUTH в MQ 7.5, удалось выяснить два интересных момента. Было создано правило, разрешающее доступ к каналу для администрирования MQ только пользователю с определённой учётной записью myadmuser:

        SET CHLAUTH(ADM.CHANNEL) TYPE(USERMAP) CLNTUSER(‘myadmuser’) USERSRC(CHANNEL)

        Результат:

        DISPLAY CHLAUTH(*)
        30 : DISPLAY CHLAUTH(*)
        AMQ8878: Display channel authentication record details.
        CHLAUTH(ADM.CHANNEL) TYPE(USERMAP)
        CLNTUSER(myadmuser) USERSRC(CHANNEL)

        Если не заключать имя пользователя в одинарные кавычки, то будет создано правило такого вида:

        AMQ8878: Display channel authentication record details.
        CHLAUTH(ADM.CHANNEL) TYPE(USERMAP)
        CLNTUSER(MYADMUSER) USERSRC(CHANNEL)

        При подключении к каналу учитывается регистр имени пользователя, под которым он вошёл в Windows. Например, если он вошёл как myadmuser, а правило создано для MYADMUSER, он не сможет подключиться к каналу. Если создано оба варианта правила (для верхнего и нижнего регистра), то он всё равно не сможет подключиться, если он вошёл в систему как Myadmuser или myAdmUser или как-то ещё.

        И теперь, самое интересное. Если прописать в настройках подключения нужное имя пользователя (например, в MQ Explorer в Connection Properties на вкладке Userid), то правило CHLAUTH сработает, и разрешит доступ, даже если этот пользователь вошёл в Windows под другим именем.

        Вывод: в MQ 7.5 нет аутентификации, и правила CHLAUTH для аутентификации по имени пользователя не имеют практического применения, а только лишь создают видимость защиты MQ.

        VA:F [1.9.22_1171]
        Rating: 0 (from 0 votes)
        • Michael Golubkov Michael Golubkov:

          Александр, в MQ никогда не было полноценной системы аутентификации и думаю никогда не будет. До версии 5.3 была встроена система аутентификации на основе связки пользователь/пароль, передаваемой с клиента на сервер. На основе этой системы с использованием канальных выходов безопасности можно было реализовать видимость надёжной системы. Однако, IBM отказалась от данного механизма, в пользу доменной аутентификации, что намного надёжней, поскольку до этого имя и пароль хранились в переменных окружения и передавались по сети в открытом виде. Сейчас, как правильно заметил Сергей, появилась возможность использовать LDAP, что в купе с записями идентификации канала позволяет построить надёжную систему. Для любителей хардкора никто не отменял канальные выходы безопасности и SSL.

          VN:F [1.9.22_1171]
          Rating: 0 (from 0 votes)
        • Michael Golubkov Michael Golubkov:

          “И теперь, самое интересное. Если прописать в настройках подключения нужное имя пользователя (например, в MQ Explorer в Connection Properties на вкладке Userid), то правило CHLAUTH сработает, и разрешит доступ, даже если этот пользователь вошёл в Windows под другим именем”

          Это фича очень полезна администратору, поскольку даёт возможность сразу же проверить правильность созданной им политики для конкретного пользователя.

          А если администратор активировал записи идентификации канала, то подобная подстановка для взлома не имеет смысла, поскольку будет отказ ещё на уровне соединения с менеджером.

          VN:F [1.9.22_1171]
          Rating: 0 (from 0 votes)
        • Sergey Kirsanov Sergey Kirsanov:

          Вывод правильный лишь наполовину. То что, в MQ нет аутентификации – это да, но мы и не утверждаем обратного. В посте идет речь об разграничении прав доступа к объектам менеджера для разных пользователей – и это имеет практическое применение.
          Например, есть две внешние по отношению к MQ системы. Каждая из них работает со своим набором очередей. Для разграничения прав доступа этих систем создаются два канала и два пользователя, которым устанавливаются права на соответствующие наборы очередей. Вот о чем этот пост.
          Как организовать административный доступ к MQ это отдельная тема.

          VN:F [1.9.22_1171]
          Rating: 0 (from 0 votes)
  2. LordHydra:

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

    VA:F [1.9.22_1171]
    Rating: +1 (from 1 vote)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: