«Роль» по определению это описание (и ограничение) деятельностей. SCRUD или BREAD это именно вектор ролей.
«Субъекта» дело аутентифицироваться и авторизоваться для исполнения некого множества «ролей» в контексте некоторых ортогональных множеств интервалов времени, локаций мест, контекстов данных.
О месте business rules в архитектуре предприНятия (англ. business) лучше всего сказали Zahmann, Sowa в 1988-1992 и как развитие их идей — David C. Hay в работах 2006-2013 годов.
Мы с вами ведем беседу совершенно по существу, просто несколько разными семантиками.
Я утверждаю, что вся задача ИБ и управления access and authorization в любой системе (даже если в ней нет ни одного компьютера в принципе) состоит в
1) определении субъекта (как минимум это идентификация, но обычно аутентификация)
2) определения объекта — (под)множества данных или tangibles в отношении которых субъекту что-то «можно»
3) определения времени (момента)
4) определения места (тут есть интересно, но об этом далее)
5) определения действий, допустимых в контексте ранее определенных субъекта, объекта, времени и места
RBAC это просто акроним и маркетинговая трескотня, одна из упрощенных интертрепаций вышесказанного для неподготовленного слушателя. На самом деле, это просто п.5 но «сферический в вакууме» в отвязке от пп.2, 4 и особенно 3.
ABAC это тоже акроним и маркетинговая трескотня, но по сравнению с RBAC в ней хотя бы появляется упоминание места и времени, уже достижение, несомненно.
Но интересен другой вопрос, которого избегают продавцы snake oil и прочих «решений» — А НА… ЗАЧЕМ?
Приходит ко мне вот такой шаман из высших нематериальных ИБ-небесных-сфер и говорит — «дай мне денег, а я тебе за них сделаю ABAC и будет тебе щаззтье». Как нормальный рациональный человек, который считает СВОИ деньги, я начинаю прикидывать: а шо за «щаззтье» он мне предлагает?
Мне нахрен не нужно контролировать действия сотрудника в сложном контексте одновременно места и времени. Если он находится на рабочем месте, в рабочее время, ему разрешено работать в системе. Если место «не то» или время «не то» — то не разрешено. Всё.
Вариант «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик» занятен, но это отдает такими казенно-чиновными представлениями о человеческой и предпринимательской деятельности, что лично я за такое и копейки не заплачу.
Потому что все такого рода правила востребованы исключительно в контексте определенных деловых процессов (business process). В рамках одного процесса у меня одни правила (business rules) в рамках другого — другие. Для этого используется инструментарий Business Rules Engine который кроме желтых штанов «атрибутов» учитывает еще и время, и место (причем с учетом того, что в современном мире субъект и объект деятельности могут находиться каждый в совершенно своем географическом месте), и массу прочих привходящих факторов вроде «политики продаж» итд.
Ваш ABAC купят ФСБ РФ и прочие такого рода структуры. Там и бабла навалом, и делать нечего, а чем занимается сторожевая собака на цепи в свободное от несения вахты время, известно из народного фольклора.
средствами одной ролевой модели решить все проблемы доступа невозможно
кто бы спорил, лично я даже не попробую пытаться
мне вот интересно другое, «все проблемы доступа» лично вы сформулируете? (подсказка: слово «доступ» вы употребили несколько поспешно)
ну и продолжая разбор вопроса; наука о моделировании бизнеса четко структурирует: есть субъект, и есть контексты
* места (гео)
* времени
* объектов (данных)
* мотиваций (правил)
лучше всего об этом писали Zachmann & Sowa в 1992 а еще лучше — David C. Hay в 2006-2009 (книга издана).
Я к тому, что опыт измыслов сложной хрени, он в истории есть многократно. Сравним простую и легкую логику UNIX-систем с монстроидальной пирамидой Хеопса имени VAX VMS, которую команда Каттлера потом перенесла в Windows NT в виде системы ACL.
И кто из администраторов реальных Windows Server систем в течении следующих 20 лет хотя бы ПОНЯЛ, как работают эти ACL и зачем они нужны? Человек 20 на всю планету?
Вообще говоря, еще до появления очередной пачки модных маркетинговых акронимов этот вопрос решался (и решается) следующим образом.
Доступ пользователя в системе разделяется на 2 независимых «измерения»:
1. Деятельность: какие действия ему разрешены. Для этого вводятся хорошо нам знакомые роли. Обычный и привычный инструмент управления ролями — матрица, где строки соответствуют пользователям, столбцы — ролям, а ячейки — чекбоксы. Роли в нулевом приближении можно рассматривать как типовой набор SCRUD (aka BREAD) actions.
2. Доступность: какие данные в системе ему доступны. Для этого дополнительно вводятся — как это сделано, например, в платных версиях SugarCRM — teams (или нечто аналогичное по сути). Заметим, что роли в SugarCRM тоже есть.
teams обычно это дерево, в котором каждый узел «видит» только данные, видимые ему непосредственно плюс видимые всем его поддеревьям до листьев включительно.
Таким образом, мы получаем для каждого отдельного пользователя отдельную матрицу (обычно подразумеваемую, так как роли управляются в одном месте, а teams в другом) где в воображаемых строках — teams, в которые может быть включен пользователь, в столбцах — разрешенные действия. Таким образом можно включить пользователя одновременно в team «склад» и «продажи», но в рамках team склада разрешить только R (смотреть остатки) а в рамках team продаж — открывать сделки и выписывать счета, но не видеть при этом счета, выписанные коллегами.
Сами данные, несомненно, конфигурируются так, что система знает, какие записи какой таблицы каким teams видимы.
Эта модель давно не нова и вполне достаточна для реальных применений (с учетом того, что пользователь может быть и включен в несколько teams и иметь несколько ролей), главное — вот та самая «вторая матрица», которая определяет действительность каждой выданной ему роли только в контексте четко ограниченного подмножества данных.
Так что новизны в описанном я лично не усматриваю, дело пахнет скорее очередной порцией криптических акронимов для заморачивания покупателю мозгов маркетинговыми квази-фичами. (На покупателей, поведенных на ИБ, особенно действует, это факт).
Отдельно замечу, что дерево связей подчиненности «у много сотрудников есть один общий непосредственный начальник» это не team, это еще одна совершенно отдельная структура. teams это кроссфункциональные «горизонтальные» команды, связи подчиненности — это вертикали функциональной оргструктуры, и просьба не путать.
А я вот только через 5 лет до civ5 добрался (купил на стиме BNW) чего-то через столько лет после civ3 вдруг пробила ностальгия. Так даже со всеми патчами на ноуте с 4Gb по мере открытия карты оно дико тупит. И некому полечить…
«Субъекта» дело аутентифицироваться и авторизоваться для исполнения некого множества «ролей» в контексте некоторых ортогональных множеств интервалов времени, локаций мест, контекстов данных.
Я утверждаю, что вся задача ИБ и управления access and authorization в любой системе (даже если в ней нет ни одного компьютера в принципе) состоит в
1) определении субъекта (как минимум это идентификация, но обычно аутентификация)
2) определения объекта — (под)множества данных или tangibles в отношении которых субъекту что-то «можно»
3) определения времени (момента)
4) определения места (тут есть интересно, но об этом далее)
5) определения действий, допустимых в контексте ранее определенных субъекта, объекта, времени и места
RBAC это просто акроним и маркетинговая трескотня, одна из упрощенных интертрепаций вышесказанного для неподготовленного слушателя. На самом деле, это просто п.5 но «сферический в вакууме» в отвязке от пп.2, 4 и особенно 3.
ABAC это тоже акроним и маркетинговая трескотня, но по сравнению с RBAC в ней хотя бы появляется упоминание места и времени, уже достижение, несомненно.
Но интересен другой вопрос, которого избегают продавцы snake oil и прочих «решений» — А НА… ЗАЧЕМ?
Приходит ко мне вот такой шаман из высших нематериальных ИБ-небесных-сфер и говорит — «дай мне денег, а я тебе за них сделаю ABAC и будет тебе щаззтье». Как нормальный рациональный человек, который считает СВОИ деньги, я начинаю прикидывать: а шо за «щаззтье» он мне предлагает?
Мне нахрен не нужно контролировать действия сотрудника в сложном контексте одновременно места и времени. Если он находится на рабочем месте, в рабочее время, ему разрешено работать в системе. Если место «не то» или время «не то» — то не разрешено. Всё.
Вариант «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик» занятен, но это отдает такими казенно-чиновными представлениями о человеческой и предпринимательской деятельности, что лично я за такое и копейки не заплачу.
Потому что все такого рода правила востребованы исключительно в контексте определенных деловых процессов (business process). В рамках одного процесса у меня одни правила (business rules) в рамках другого — другие. Для этого используется инструментарий Business Rules Engine который кроме желтых штанов «атрибутов» учитывает еще и время, и место (причем с учетом того, что в современном мире субъект и объект деятельности могут находиться каждый в совершенно своем географическом месте), и массу прочих привходящих факторов вроде «политики продаж» итд.
Ваш ABAC купят ФСБ РФ и прочие такого рода структуры. Там и бабла навалом, и делать нечего, а чем занимается сторожевая собака на цепи в свободное от несения вахты время, известно из народного фольклора.
Бизнес этого не купит.
кто бы спорил, лично я даже не попробую пытаться
мне вот интересно другое, «все проблемы доступа» лично вы сформулируете? (подсказка: слово «доступ» вы употребили несколько поспешно)
ну и продолжая разбор вопроса; наука о моделировании бизнеса четко структурирует: есть субъект, и есть контексты
* места (гео)
* времени
* объектов (данных)
* мотиваций (правил)
лучше всего об этом писали Zachmann & Sowa в 1992 а еще лучше — David C. Hay в 2006-2009 (книга издана).
Я к тому, что опыт измыслов сложной хрени, он в истории есть многократно. Сравним простую и легкую логику UNIX-систем с монстроидальной пирамидой Хеопса имени VAX VMS, которую команда Каттлера потом перенесла в Windows NT в виде системы ACL.
И кто из администраторов реальных Windows Server систем в течении следующих 20 лет хотя бы ПОНЯЛ, как работают эти ACL и зачем они нужны? Человек 20 на всю планету?
Доступ пользователя в системе разделяется на 2 независимых «измерения»:
1. Деятельность: какие действия ему разрешены. Для этого вводятся хорошо нам знакомые роли. Обычный и привычный инструмент управления ролями — матрица, где строки соответствуют пользователям, столбцы — ролям, а ячейки — чекбоксы. Роли в нулевом приближении можно рассматривать как типовой набор SCRUD (aka BREAD) actions.
2. Доступность: какие данные в системе ему доступны. Для этого дополнительно вводятся — как это сделано, например, в платных версиях SugarCRM — teams (или нечто аналогичное по сути). Заметим, что роли в SugarCRM тоже есть.
teams обычно это дерево, в котором каждый узел «видит» только данные, видимые ему непосредственно плюс видимые всем его поддеревьям до листьев включительно.
Таким образом, мы получаем для каждого отдельного пользователя отдельную матрицу (обычно подразумеваемую, так как роли управляются в одном месте, а teams в другом) где в воображаемых строках — teams, в которые может быть включен пользователь, в столбцах — разрешенные действия. Таким образом можно включить пользователя одновременно в team «склад» и «продажи», но в рамках team склада разрешить только R (смотреть остатки) а в рамках team продаж — открывать сделки и выписывать счета, но не видеть при этом счета, выписанные коллегами.
Сами данные, несомненно, конфигурируются так, что система знает, какие записи какой таблицы каким teams видимы.
Эта модель давно не нова и вполне достаточна для реальных применений (с учетом того, что пользователь может быть и включен в несколько teams и иметь несколько ролей), главное — вот та самая «вторая матрица», которая определяет действительность каждой выданной ему роли только в контексте четко ограниченного подмножества данных.
Так что новизны в описанном я лично не усматриваю, дело пахнет скорее очередной порцией криптических акронимов для заморачивания покупателю мозгов маркетинговыми квази-фичами. (На покупателей, поведенных на ИБ, особенно действует, это факт).
Отдельно замечу, что дерево связей подчиненности «у много сотрудников есть один общий непосредственный начальник» это не team, это еще одна совершенно отдельная структура. teams это кроссфункциональные «горизонтальные» команды, связи подчиненности — это вертикали функциональной оргструктуры, и просьба не путать.
Fast C/C++ prime number generator — и код самой primesieve; реализация шикарная, полированная, ибо человек лет 15 серьезно этим вопросом занимается. Работает primesieve с сумасшедшей производительностью даже на настольном скромном тазике, а подробности реализации сегментированного решета и wheel факторизации полностью документированы. Однако, он явным образом пишет, что «primesieve can generate primes and prime k-tuplets up to 2^64» и всё, край географии. Интересно, почему. Наверное он просто такой задачи себе не ставил, сделать больше.
IBMicrosoft p.1
IBMicrosoft p.2
IBMicrosoft p.3
IBMicrosoft p.4
IBMicrosoft p.5
IBMicrosoft p.6 — история OS/2
IBMicrosoft p.7 — Who Killed Gary Kildall?
IBMicrosoft p.8 — IBMicrosoft vs. DR
IBMicrosoft против акционеров IBM p.9
Также весьма поучительны истории с Microsoft Xenix (позже SCO), откуда и как взялся компилятор Microsoft C и прочие истории «сотрудничества» MS со стартапами, которое для стартапов всегда заканчивалось одинаково (поеданием, не выплевывая костей).