Азбука контроля доступа и что лучше для облачных сервисов

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

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

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

Если вы думаете, что это начинает напоминать озера данных на базе Hadoop, вы правы. Излишне говорить, что это возлагает очень тяжелое бремя на администраторов, которым приходится обеспечивать широкий доступ к данным в организации и соблюдать законы о конфиденциальности и отрасли, такие как Закон штата Калифорния о конфиденциальности потребителей (CCPA), Общий регламент по защите данных (GDPR) и Закон о здравоохранении. Одновременно действует Закон о переносимости и подотчетности страхования (HIPAA).

Основы двух популярных подходов: RBAC и ABAC.

Механизмы контроля доступа были частью ИТ-среды предприятия с момента появления компьютерных систем, и существует два ключевых аспекта контроля доступа к данным. Первый касается аутентификации личности пользователя и установления того, действительно ли человек или система являются теми, за кого себя выдают. Второе связано с обеспечением того, чтобы у пользователя было соответствующее разрешение на доступ к системе данных. Этот процесс известен как авторизация. Эти принципы также применимы к данным, хранящимся в облаке. Сегодня управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC) являются двумя наиболее распространенными подходами к управлению доступом к данным на предприятии. Цель этих подходов — помочь определить и обеспечить соблюдение политик и привилегий, которые предоставляют авторизованным пользователям доступ к необходимым данным.

RBAC основан на концепциях пользователей, ролей, групп и привилегий в организации. Администраторы предоставляют привилегии или разрешения заранее определенным ролям организации — ролям, которые назначаются субъектам или пользователям в зависимости от их ответственности или области знаний. Например, пользователь, которому назначена роль менеджера, может иметь доступ к другому набору объектов и/или иметь разрешение выполнять над ними более широкий набор действий по сравнению с пользователем с назначенной ролью аналитика. Когда пользователь генерирует запрос на доступ к объекту данных, механизм управления доступом оценивает роль, назначенную пользователю, и набор операций, которые эта роль имеет право выполнять над объектом, прежде чем принять решение о разрешении или отклонении запроса.

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

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

ABAC действует путем присвоения атрибутов субъектам и объектам и разработки политик, регулирующих правила доступа к данным. Каждому компоненту информационной системы присвоены атрибуты, специфичные для объекта. Например, файл можно классифицировать как интеллектуальную собственность (ИС). Аналогично, каждому пользователю или субъекту в системе могут быть назначены атрибуты, которые могут включать местоположение и часовой пояс пользователя. На основе этих атрибутов администратор может создать политику доступа, которая определяет, что любой документ, классифицированный как IP, не может быть доступен пользователю, находящемуся за пределами США, или что доступ к нему могут получить только пользователи, связанные с подразделением компании. юридический отдел в 8:00 и 17:00 по тихоокеанскому стандартному времени. Теперь вы можете увидеть, как ABAC расширяет концепцию роли, пользователей и привилегий, включая атрибуты.

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

Делаем правильный выбор

Важно отметить, что различие между подходами RBAC и ABAC все больше стирается из-за платформ контроля доступа, таких как Apache Ranger, структуры управления данными, первоначально разработанной для управления большими данными в озерах данных Hadoop.

Сегодня Apache Ranger — ведущий проект с открытым исходным кодом для управления доступом к данным в средах больших данных, включая Apache Spark. Он используется на сотнях предприятий по всему миру для определения и обеспечения соблюдения политик контроля доступа к данным для управления конфиденциальными данными в соответствии с такими правилами, как GDPR и CCPA.

Apache Ranger был создан для централизованного управления доступом к данным, используемым различными механизмами, входящими в состав платформ Hadoop. По своей сути он спроектирован так, чтобы справляться с разнообразием сред хранения данных и вычислительных сред, представленных множеством облачных сервисов, используемых сегодня на предприятиях.

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

Лучшая стратегия для организаций, переходящих в облако, — это выбрать платформу контроля доступа к данным, которая обеспечивает баланс между предоставлением администраторам возможности предоставлять больше данных большему количеству потребителей данных и соблюдением отраслевых норм и правил конфиденциальности. Что еще более важно, это должно происходить без негативного влияния на производительность платформы данных или поведение пользователей.