18 октября, четверг 11:51
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Не пора ли БИСквиту ещё немного повзрослеть...

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Не пора ли БИСквиту ещё немного повзрослеть...

    В общем, с появлением функций автоматического обновления и участившимся выходом патчей стало весьма актуально пересмотреть совершенно детскую схему распределения прав доступа к объектам базы, поскольку существующие правила и алгоритмы просто засоряют базу неактуальной информацией, и в ворохе оной теряется актуальная. Я рад, что в фирме БИС это понимают. Я совершенно не рад, - КАК понимают. Это, если вкратце.

    На (абстрактное) обсуждение выносится предложение. Сделать схему предоставления прав доступа двухуровневой. А именно, индивидуальный пользователь имеет необходимый минимум настоек (практически, на мой взгляд, достаточно того, что имеется в "дополнительных реквизитах", - впрочем, права на статусы документов я бы оттуда убрал). Сделать объект типа "роль", причём несколько стандартных ролей числом до 10-15 (как пример: "администратор", "бухгалтер", "операционист", "казначей", "кассир", "кредит", "депозит", "налоги", "внутренний контроль"...) сделать штатными ("стандартными") и поддерживать в обновлениях. Пользователям в качестве средства доступа к объектам базы назначать ("отнимать") эти самые "роли".

    Понятно, что сие потребует серьёзных изменений. Но мне кажется, они не только что назрели, а уже даже перезрели.
    /kiv

  • #2
    Илюха Судя по некоторым намёкам в патчах (заявка 0010558 в 16 патче) , в ожидаемой со дня на день версии 4.1D00 будет изменение в системе проверки прав доступа. Цитирую описание заявки:
    "Провести унификацию системы проверки прав доступа.
    1) Создать и использовать единый инструментарий для проверки прав доступа к классам метасхемы, таблицам Progress, классам отчетных данных, меню процедур и стандартным транзакциям. Заменить все обращения к таблице _file и к полям типа can-* для проверки доступа на вызов инструментария. Указанные модификации необходимо произвести в связи с планируемым в новом релизе 4.1D удалением полей вида can-* из всех таблиц (за исключением системных таблиц Progress).
    ... "
    По крайней мере с новой системой проверки предлагаемая схема распределения прав становится технически возможной.
    PS. Как называется предложенная схема доступа среди безопасников-теоретиков?
    Последний раз редактировалось Andry; 12.05.2004, 12:09.

    Комментарий


    • #3
      Сейчас предлагается создавать "стандартных пользователей", которым необходимо выдавать стандартные права, и в дальнейшем копировать (аддитивно к существующим) их права реальным пользователям.
      Одна из проблема состоит в том, что сейчас реальные пользователи не привязаны к "ролям" в виде "стандартных пользователей", и нет процедуры контроля различий в правах между "стандартным пользователем" и реальным пользователем.
      Создания процедуры печати различий в правах между двумя пользователями (а-ля diff) могло бы хоть как-то помочь.

      Комментарий


      • #4
        Сообщение от Andry
        нет процедуры контроля различий в правах между "стандартным пользователем" и реальным пользователем.
        Создания процедуры печати различий в правах между двумя пользователями (а-ля diff) могло бы хоть как-то помочь.
        Ой. Ну только вот этого не надо. Предположим, у меня "реальный пользователь" выполняет функции двух-трёх "стандартных" одновременно. С чем тут diff-ать и что как исправлять?

        Далее. Проблема-то глубже. Сейчас при импорте *.d обновлений импортируется уйма уймищная совершенно мусорных прав доступа к процедурам и строкам меню (всякие там "VVV,KMY,NICK,GAL,DASU,SELENA,ILVI,OM,KSV, PODM,ILVI2,PVV,GUNK,ALVEL,K009,VTEB,SEMA,IVAL, SHSV,FD,OKSANA,KROK,KOSI,KAVI,OLENKA,MRR,AVAL, RYOL,MAAN,RYZHOV,AEK,KOAG,ZAOL,CHNV,DEMA,PESV, KROK1,KROK2,MESC,SHVK,KUVB,GROM,NIKI,KRAW,007, VARZ,MALA,PODM_TST,KOAG-TST,BLIS,KOLAL,VLAD, GSA,LAAV,LIGP,MIOA,FEPA,SHSV1,FEPA1,CHEB,OKS" - список взят совершенно реальный, из первой же строки первой же *.d 17-го фикса). Наоборот, локальные права доступа тоже создаются по схеме "пан или пропал": ну то есть, я, конечно, понимаю, что "при импорте обновления нужно списки прав вручную корректировать под конкретный банк", но при трёх десятках пользователей это уже вручную просто нереально: ошибок насажаешь столько, что проще махнуть рукой и ставить * всюду.

        В итоге, полномочия на объекты базы разлезаются просто по швам,
        о чём и речь.

        Вообще, такое впечатление, что тема никому не интересна.

        Ау, таки живущим тут нужна нормальная схема прав доступа или в больших банках на бисквите только "песочницы" сделаны, а работа где-то "слева" идёт?
        /kiv

        Комментарий


        • #5
          Сообщение от Илюха
          Ой. Ну только вот этого не надо. Предположим, у меня "реальный пользователь" выполняет функции двух-трёх "стандартных" одновременно.
          Подождите! Если мы говорим о ролях, считаем ли мы, что один пользователь всегда выступает в одной и только одной роли,
          или пользователь может одновременно "играть" несколько ролей?

          Комментарий


          • #6
            Сообщение от Andry
            Если мы говорим о ролях, считаем ли мы, что один пользователь всегда выступает в одной и только одной роли,
            или пользователь может одновременно "играть" несколько ролей?
            Конечно, в общем случае - несколько: иначе опять та же петрушка и получится, только абстрактнее по форме.
            /kiv

            Комментарий


            • #7
              Сообщение от Илюха
              Ой. Ну только вот этого не надо. Предположим, у меня "реальный пользователь" выполняет функции двух-трёх "стандартных" одновременно. С чем тут diff-ать и что как исправлять?
              Тогда сравнивать права пользователя надо с объединением
              прав "стандартных" пользователей, чьи "роли" он выполняет.

              Как исправлять:
              1) Если у реального есть, а ни у одной из его стандартных ролей конкректного права на конкретном обьекте нет - убрать.

              2) Если у реального нет, а у одного из его стандартные ролей есть - добавить.

              Я понимаю конечно что это .... костыль, а не нормальное и правильное решение, но всё же.

              Комментарий


              • #8
                Илюха Опять же. Если одна из ролей пользователя категорически не должна иметь доступа к какому-то действию, а другая роль это право имеет? Вот тут уже заморочки получаются и вряд ли это кому-то нужно.

                Комментарий


                • #9
                  Сообщение от Andry
                  Я понимаю конечно что это .... костыль, а не нормальное и правильное решение, но всё же.
                  Ну почему, - "костыль"? Если его снабдить инструментами - то вполне может быть жизнеспособное решение. Не хуже прочих.

                  Ну, раздуются не процедуры, а база. Главное, чтобы синхронизация была.

                  Другими словами, конкретная реализация в плане набора функций не так интересна, как результат: схема разрешений, соответствующая как внутренней политике банка (назначение ролей пользователям) так и логике СУБД (назначение ролям прав и разрешений), а не текущее "неизвестно что".

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

                  Сообщение от Andry
                  Если одна из ролей пользователя категорически не должна иметь доступа к какому-то действию
                  Это Вы policy editora насмотрелись. Тогда, если вводить в policy не только характеристику "есть доступ"/"нет доступа", как сделано в прочих местах,(каковые характеристики объединяются простым логическим "или"), а ещё дополнительно добавить операцию "отнять доступ", то вот тут мозголом и получится.

                  Но, в любом случае, - это уже следующий этап. Нам бы с предыдущим разобраться. Хотя, вижу, вряд ли сие кому нужно.
                  /kiv

                  Комментарий


                  • #10
                    Сообщение от Илюха
                    Но, в любом случае, - это уже следующий этап. Нам бы с предыдущим разобраться. Хотя, вижу, вряд ли сие кому нужно.
                    Ну, не надо так категорично. Нужно. Очень даже нужно, только просить об этом устала.
                    Чем больше связей, тем меньше степеней свободы.

                    Комментарий


                    • #11
                      Чернушка На семинар по поводу выхода версии 4.1D идёте? Предлагаю именно там задать вопрос публично.
                      А так как представители фирмы БИС, я уверен, этот форум по партизански читают, то есть все шансы получить на семинаре развёрнутый ответ.

                      Комментарий


                      • #12
                        Сообщение от Andry
                        Чернушка На семинар по поводу выхода версии 4.1D идёте?
                        Идем, идем И еще человек пять со мной
                        Чем больше связей, тем меньше степеней свободы.

                        Комментарий


                        • #13
                          Получили программу семинара Бис настроен хвалить новые модули, а не отвечать по старым
                          Чем больше связей, тем меньше степеней свободы.

                          Комментарий


                          • #14
                            Эх давно пора сделать такое с правами, но увы пока не реализовано :-(

                            Комментарий


                            • #15
                              Как показал вчерашний семинар - взрослеть в этом направлении Бисквит пока не готов. Сначала пошла отговорка на тему, что такого не может Прогресс, затем просто - пока не дошли руки.
                              Хотя, на мой взгляд, Прогресс здесь непричем. Мы не требуем (пока) глобальной переделки идеологии проверки прав, мы просто просим удобный инструмент администратора по назначению этих прав.
                              Чем больше связей, тем меньше степеней свободы.

                              Комментарий

                              Пользователи, просматривающие эту тему

                              Свернуть

                              Присутствует 1. Участников: 0, гостей: 1.

                              Обработка...
                              X