Безопасность пространства объектов

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

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

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

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

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

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

Второй уровень обеспечения безопасности - собственно системы, поверх которых работают сервисы пространства объектов. Эти системы могут иметь собственные механизмы аутентификации и проверки полномочий (авторизации) - как правило, в случае использования СУБД. Пространство объектов должно предоставлять возможность использовать эти механизмы при необходимости в качестве дополнительного уровня защиты.

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

И последний уровень обеспечения безопасности - сетевой. Допустим, что организация считает необходимым построить некоторое решение как часть единого пространства объектов, чтобы изнутри можно было ссылаться и использовать внешние объекты, опубликованные глобально. Но при этом внутренние объекты должны быть доступны либо только в рамках локальной сети, либо в рамках некоторой VPN, например, в связи с финансовым характером системы. В этом случае доступ к локальному сервису может быть ограничен не только на уровне пространства объектов или СУБД, но и на сетевом уровне путем запрета любых внешних подключений к сервису пространства объектов. В результате локальный сервис будет функционировать как часть глобального пространства объектов, но он не будет доступен извне.