Поделиться через

Пакет SDK Microsoft Information Protection — основные понятия объектов Profile and Engine

  • Статья

Профили

MipContext Где используется класс для хранения параметров пакета SDK, профиль является корневым классом для всех операций с метками MIP и операций защиты в пакете SDK для MIP. Прежде чем использовать любой из трех наборов API, клиентское приложение должно создать профиль. Будущие операции выполняются профилем или другими объектами , добавленными в профиль. Рекомендуется использовать только один объект профиля для каждого процесса. Создание нескольких из них может привести к неожиданному поведению.

В пакете SDK для MIP существует три типа профилей:

  • PolicyProfile: класс профиля для пакета SDK политики MIP.
  • ProtectionProfile: класс профиля для пакета SDK для защиты MIP.
  • FileProfile: класс профиля для пакета SDK для файлов MIP.

API, используемый в используемом приложении, определяет, какой класс профиля следует использовать.

Сам профиль предоставляет следующие функции:

  • Определяет, следует ли загружать состояние в памяти или сохраняться на диске, а при сохранении на диске должно быть зашифровано.
  • Определяет mip::ConsentDelegate , что следует использовать для операций согласия.
  • Определяет реализацию mip::FileProfile::Observer , которая будет использоваться для асинхронных обратных вызовов для операций профиля.

Параметры профиля

  • MipContextMipContext: объект, инициализированный для хранения сведений о приложении, пути к состоянию и т. д.
  • CacheStorageType: определяет, как хранить состояние: в памяти, на диске или на диске и зашифрованном.
  • consentDelegate: общий указатель класса mip::ConsentDelegate.
  • observer: общий указатель на реализацию профиля Observer (в PolicyProfile, ProtectionProfileи FileProfile).
  • applicationInfomip::ApplicationInfo: объект. Сведения о приложении, использующее пакет SDK, который соответствует идентификатору регистрации приложения Microsoft Entra и имени.

Подсистемы

Подсистемы sdk для файлов, профилей и защиты предоставляют интерфейс для операций, выполняемых определенным удостоверением. Один обработчик добавляется в объект Profile для каждого пользователя или субъекта-службы, который входит в приложение. Можно выполнять делегированные операции с помощью mip::ProtectionSettings файла или обработчика защиты. Дополнительные сведения см . в разделе параметров защиты в концепциях FileHandler.

В пакете SDK есть три класса подсистемы, по одному для каждого API. В следующем списке показаны классы подсистемы и несколько функций, связанных с каждым из них:

  • mip::ProtectionEngine
  • mip::PolicyEngine
    • ListSensitivityLabels(): получает список меток для загруженного обработчика.
    • GetSensitivityLabel(): получает метку из существующего содержимого.
    • ComputeActions(): предоставляется идентификатор метки и необязательные метаданные, возвращает список действий, которые должны выполняться для определенного элемента.
  • mip::FileEngine
    • ListSensitivityLabels(): получает список меток для загруженного обработчика.
    • CreateFileHandler(): создает определенный mip::FileHandler файл или поток.

Для создания обработчика требуется передать определенный объект параметров ядра, содержащий параметры для создаваемого типа обработчика. Объект параметров позволяет разработчику указать сведения об идентификаторе ядра, реализации, mip::AuthDelegate языковом стандарте и пользовательских параметрах, а также других сведений о API.

Состояния подсистемы

Подсистема может иметь одно из двух состояний:

  • CREATED: Создано указывает, что пакет SDK имеет достаточно сведений о локальном состоянии после вызова необходимых внутренних служб.
  • LOADED: пакет SDK создал необходимые структуры данных для работы подсистемы.

Обработчик должен быть создан и загружен для выполнения любых операций. Класс Profile предоставляет несколько методов управления подсистемами: AddEngineAsync, DeleteEngineAsyncи UnloadEngineAsync.

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

Состояние подсистемы NONE СОЗДАНО НАГРУЖЕННЫЙ
NONE AddEngineAsync
СОЗДАНО DeleteEngineAsync AddEngineAsync
НАГРУЖЕННЫЙ DeleteEngineAsync ВыгрузкаEngineAsync

Идентификатор ядра

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

Внимание

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

// Create the FileEngineSettings object
FileEngine::Settings engineSettings(mip::Identity(mUsername), // This will be the engine ID. UPN, email address, or other unique user identifiers are recommended. 
													          mAuthDelegate,            // authDelegate implementation 
													          "",                       // ClientData
													          "en-US",                  // Client Locale
                                    false);                   // Load Sensitive Information Types

Методы управления обработчиками

Как упоминалось ранее, в пакете SDK есть три метода управления обработчиками: AddEngineAsyncи UnloadEngineAsyncDeleteEngineAsync.

AddEngineAsync

Этот метод загружает существующий модуль или создает его, если он еще не существует в локальном состоянии.

Если приложение не предоставляет вход id FileEngineSettings, AddEngineAsync создает новый idобъект. Затем проверяет, существует ли подсистема id в локальном кэше хранилища. Если это так, он загружает этот механизм. Если подсистема не существует в локальном кэше, создается новый модуль путем вызова необходимых API и внутренних служб.

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

DeleteEngineAsync

Удаляет модуль с заданным id. Все трассировки обработчика удаляются из локального кэша.

ВыгрузкаEngineAsync

Выгружает структуры данных в памяти для подсистемы с заданным id. Локальное состояние этого модуля по-прежнему остается неизменным и может быть перезагружено с AddEngineAsyncпомощью .

Этот метод позволяет приложению быть разумным в отношении использования памяти, выгрузив подсистемы, которые, как ожидается, не будут использоваться в ближайшее время.

Next Steps