Журнал "Директор по безопасности" Январь 2020

ЕСТЬ РЕШЕНИЕ Управление доступом к проектам ОЛЕГ ГУБКА, директор по развитию бизнеса Аванпост М одель управления доступом в современных информаци- онных системах в большин- стве случаев основывается на прин- ципе RBAC (Role-Based Access Control). Можно сказать, что сейчас эта модель является классикой в управлении до- ступом. Она имеет ряд безусловных преимуществ. Такой подход позволяет определить функциональное назна- чение доступа в контексте организа- ционных ролей и бизнес-процессов. То есть создать роли в системе с опре- деленным доступом к операциям и объектам, характерным для конкрет- ных должностей или бизнес-задач. На- пример, выделить роль менеджер по продажам в системе CRM, которая бу- дет иметь полномочия по доступу на чтение и редактирование к данным по клиентам и формированию пер- вичной бухгалтерской документации. Как результат, это сокращает влияние изменений в ИТ-инфраструктуре на ролевой профиль пользователей. То есть, если произойдут изменения в базе данных по клиентам, например добавятся новые поля, то для этого не- обходимо будет только поменять со- став роли менеджер по продажам, без назначения дополнительных ролей пользователю. Также это позволяет обеспечить процессы согласования до- ступом на уровне бизнеса. Для запро- са доступа в CRM на нового сотрудни- ка отдела продаж достаточно указать одну роль менеджер по продажам и не перечислять весь набор данных и операций в системе, которые не зна- ет бизнес-пользователь. Согласующие лица тоже понимают, какой доступ за- прашивается и могут оперативно его согласовать без дополнительного изу- чения набора полномочий.Чаще всего реализации RBAC в информационных системах соответствуют плоской роле- вой модели, но есть ситуации, когда одного измерения в модели авториза- ции недостаточно и требуется двумер- ная модель. Одним из интересных и актуальных примеров области приме- нения двумерной модели управления доступом является проектное управ- ление, где каждый проект рассматри- вается как объект, на доступ к которо- му предоставляются отдельные роли. В целом можно сказать, что одномер- ная ролевая модель лучше всего под- ходит для классических процессов, когда пользователи выполняют по- вторяющиеся операции, для которых нужны постоянные полномочия. Но в сути проектного управления заложены принципы индивидуального подхода к каждому проекту в условиях вре- менных и ресурсных ограничений. Это несомненно влияет на модель управ- ления доступом. Например, проект имеет жизненный цикл, начиная от старта до завершения, поэтому доступ должен предоставляться и отзываться с учетом сроков проекта. У проекта есть организационные роли, но назна- чаются они в каждом проекте незави- симо. Например, сотрудник на долж- ности руководитель проектов может управлять ограниченным перечнем проектов и соответственно иметь до- ступ к данным только этих проектов. Поэтому, несмотря на возможность использования ролевого принципа при управлении доступом к проектам, применяется он в отношении каждо- го проекта в отдельности. В контексте функционала IDM системы это приво- дит к тому, что поддержки классиче- ской RBAC уже недостаточно и необхо- димо учитывать специфику проектной деятельности. Давайте рассмотрим ка- ким требованиям должна соответство- вать современная IDM-система, чтобы это обеспечить. Как мы уже выяснили выше, у про- екта есть определенный перечень организационных ролей. Для при- мера приведем стандартный состав проектной команды из ИТ-проектов. Как правило, в него входят руководи- тель проекта, архитектор, аналитик/ технический писатель и инженер. В целом данные проектные роли соот- ветствуют должностям, но назначение на эти роли сотрудников происходит независимо в каждом проекте. В ре- зультате получается параллельная ор- ганизационная структура, сформиро- ванная под проектную деятельность. Появление проектной команды как организационной единицы позволя- ет нам связать с ней доступ к проек- там в соответствующей системе и ав- томатизировать его назначение уже при включении сотрудника в состав проекта. При этом проект имеет вре- менные ограничения и при его завер- шении сотрудник исключается из про- ектной команды и доступ к данным проекта тоже будет отозван. Также появление такой виртуальной структу- ры позволяет ограничить видимость полномочий по доступу при создании заявки. То есть, руководитель проек- та 1 может запросить доступ на ин- женера, назначенного на проект 1, и только к данным проекта 1. Помимо штатных сотрудников в проект могут быть включены внешние участники, например от организации-заказчи- ка, поэтому в IDM должна быть пред- усмотрена возможность заведения карточки пользователя вручную че- рез интерфейс администратора или бизнес-пользователя. Таким обра- зом, можно сформировать следующее требование к функционалу IDM. Это возможность создания виртуальных организационных структур с виртуаль- ными должностями (организацион- ными ролями) и заведения карточек внешних пользователей. Для обеспечения возможности управления доступом к динамическим объектам, таким как проекты, необхо- димо, чтобы в IDM была соответству- ющая объектная модель, а коннектор к целевой системе поддерживал ее на интеграционном уровне. То есть кроме плоской ролевой модели долж- на быть возможность добавления в IDM из интегрируемой системы новых объектов со своей моделью доступа в виде ACL или списка ролей. При этом IDM-система должна поддерживать иерархию и комбинацию ролей, что позволяло бы включать в них как про- сто роли целевой системы, так и объ- екты с определенными полномочия- ми. Также роли в IDM должны иметь возможность назначения организа- ционным единицам, включая вирту- альным, по контексту. Например, мы можем создать в IDM для всех проек- тов одну роль «архитектор», которая будет автоматически предоставляться пользователю, назначенному на эту организационную роль в любом про- екте. Но при этом IDM понимает, в ка- ком проекте он работает и будет на- значать доступ в системе управления проектами только к соответствующему объекту с необходимыми полномочи- ями. Это позволяет сократить количе- ство ролей и сделать ролевую модель более простой и управляемой. Чтобы управление доступом стало возможным бизнес-пользователями, необходимо иметь уровень абстрак- ции, который бы позволял представ- лять техническую модель данных в по- нятных бизнесу терминах. В контексте управления проектами это означает, что формирование ролевой модели для конкретного проекта может осу- ществляться, например, руководите- лем данного проекта. То есть при по- явлении проекта на него назначается руководитель, который формирует команду проекта, а также необходи- мые высокоуровневые роли на основе существующих полномочий и назна- чает их участникам проекта. Эта воз- можность должна быть предоставлена через интерфейс бизнес-пользовате- ля, реализованного в виде личного ка- бинета с необходимой авторизацией. Также изменения в доступе к проек- там могут проходить соответствующие согласование, например, с куратором проекта, владельцем системы и под- разделением информационной безо- пасности. Для этого в IDM должен быть предусмотрен механизм workflow, позволяющий создавать и согласовы- вать заявки, с гибким графическим конструктором, отвечающим совре- менным нотациям по моделированию бизнес-процессов. Методики проектного управления все больше внедряются в нашу корпо- ративную жизнь. Поэтому представ- ленная модель управления доступом к проектам, реализованная в IDM, ста- новится все более востребованной. Но такая модель авторизации огра- ничена двумя измерениями, где в од- ном – находятся объекты (проекты), в другом – роли или полномочия. Поэ- тому следующей ступенью эволюции уже становится атрибутивная модель доступа ABAC (attribute-based access control), которая позволяет реализо- вать многомерную модель доступа, отвечающую максимальным требо- вания по информационной безопас- ности. Пока к ее реализации делают робкие шаги даже западные произ- водители, но будущее не за горами и скоро, я думаю, мы сможем увидеть практическое пересечение интересов заказчиков и возможностей современ- ных технологий. Изменения в доступе к проектам могут проходить соответствующие согласование, например, с куратором проекта, владельцем системы и подразделением информационной безопасности

Журнал "Директор по безопасности" Январь 2020 | Page 13