Microsoft Purviewで文書やメールを暗号化したい場合、最初に確認すべきは「Azure Rights Management サービスがテナントで有効かどうか」です。多くの対象テナントでは自動的に有効化されていますが、無効化されている場合や古い構成を引き継いでいる場合は、管理者がPowerShellで状態確認と有効化を行う必要があります。現在は管理ポータルから有効化・無効化するのではなく、AIPService PowerShellモジュールを使う点が重要です。(Microsoft Learn)
特に注意すべきなのは、Azure Rights Managementを有効化すると、条件によっては組織全体のユーザーが文書やメールに暗号化を適用できるようになることです。段階展開をしたい場合は、あらかじめオンボーディング制御で対象ユーザーを絞り込みます。また、オンプレミスのAD RMSを利用している組織では、安易に有効化せず、移行計画を先に確認する必要があります。(Microsoft Learn)
Microsoft PurviewにおけるAzure Rights Managementとは
Azure Rights Managementは、Microsoft Purview Information Protectionで文書、メール、会議出席依頼などに暗号化とアクセス制御を適用するための基盤サービスです。秘密度ラベルで暗号化を設定する場合、OutlookのS/MIMEを使うケースを除き、文書・メール・会議出席依頼への暗号化にはAzure Rights Managementが使われます。(Microsoft Learn)
管理者の視点では、Azure Rights Managementは「ユーザーが押す暗号化ボタン」ではなく、Purviewの情報保護機能、秘密度ラベル、Microsoft Purview Message Encryptionなどが利用するテナント単位の暗号化基盤と考えると分かりやすいです。
たとえば、次のような場面で関係します。
| 利用シーン | Azure Rights Managementとの関係 |
|---|---|
| WordやExcelファイルに秘密度ラベルで暗号化をかける | ラベルのアクセス制御に基づき、閲覧・編集・印刷などの権限を制御する |
| Outlookのメールに暗号化ラベルを適用する | 受信者のIDや権限に基づいてメール本文や添付ファイルへのアクセスを制御する |
| Microsoft Purview Message Encryptionを使う | 前提条件として、テナントでAzure Rights Managementが有効である必要がある |
| 開発したアプリで保護ファイルを扱う | Microsoft Purview Information Protection SDKなどで権限チェックを実装する必要がある |
一方、Teams会議の音声や映像ストリームに適用される暗号化は、文書やメールで使うAzure Rights Managementとは別方式です。秘密度ラベルという名称だけで同じ仕組みだと判断しないようにしましょう。(Microsoft Learn)
今回の公式情報で管理者が押さえるべき変更点
今回のポイントは、新しい暗号化方式が追加されたというより、Microsoft Purview Information ProtectionからAzure Rights Management暗号化サービスを安全に有効化・確認するための運用手順が明確化されている点です。
特に実務上の影響が大きいのは、次の4点です。
| 確認ポイント | 管理者が見るべき内容 | 対応の方向性 |
|---|---|---|
| 有効化方法 | 管理ポータルからではなく、PowerShellで有効化・確認する | AIPServiceモジュールを準備し、Get-AipServiceとEnable-AipServiceを使う |
| 自動有効化の有無 | 2018年2月末以降に対象サービスプランを取得したテナントでは自動有効化される場合がある | まず状態確認を行い、不要な再設定を避ける |
| AD RMSの利用状況 | AD RMSを展開済みの組織ではAzure Rights Managementを有効化しない | 先にAD RMSからAzure Rights Managementへの移行計画を確認する |
| 展開範囲 | 有効化後は組織内ユーザーが暗号化を適用できる可能性がある | オンボーディング制御でパイロット展開する |
Microsoftの公式情報では、Azure Rights Managementサービスを含むサブスクリプションを2018年2月末以降に取得した場合、サービスは自動的に有効化されると説明されています。2018年2月以前の契約でも、Exchange Onlineを利用しているテナントでは自動有効化される場合がありますが、Get-IRMConfigurationでAutomaticServiceUpdateEnabledがfalseになっている場合は例外です。(Microsoft Learn)
つまり、管理者が最初に行うべきことは「有効化コマンドをすぐ実行すること」ではありません。まず現在の状態、契約、AD RMSの有無、展開対象を確認することが安全です。
Azure Rights Management有効化の影響範囲
Azure Rights Managementはテナント全体に関わるサービスです。特定の部署だけに影響する小さな設定ではないため、展開前に影響範囲を整理しておく必要があります。
ユーザーへの影響
Azure Rights Managementが有効化されると、組織内のユーザーは文書やメールなどに暗号化を適用でき、このサービスで暗号化されたアイテムを開けるようになります。ただし、すべてのユーザーにすぐ暗号化の適用を許可したくない場合は、オンボーディング制御で適用できるユーザーを制限できます。(Microsoft Learn)
ここで重要なのは、「暗号化されたコンテンツを開くこと」と「自分で暗号化を適用すること」は分けて考える点です。オンボーディング制御を使っても、組織内ユーザーは許可されたユーザーが保護したコンテンツを利用できますが、自分でクライアントアプリから暗号化を適用することは制限されます。(Microsoft Learn)
Exchange Onlineとメール暗号化への影響
Microsoft Purview Message Encryptionを使う場合、Azure Rights Managementがテナントで有効になっていることが前提です。Azure Rights Managementが有効であれば、Microsoft 365側でメッセージ暗号化が自動的に有効化されると説明されています。(Microsoft Learn)
ただし、Exchange側の構成も確認が必要です。ExchangeがAzure Rights Management用に構成されていない場合、Outlook on the webやモバイルで暗号化メールや暗号化された会議出席依頼を表示できない、暗号化メールを検索用にインデックス化できない、Exchange Online DLPでRights Management保護を構成できない、といった制限が発生します。(Microsoft Learn)
オンプレミスAD RMS利用組織への影響
AD RMSを利用している組織では、Azure Rights Managementをそのまま有効化しないことが重要です。Microsoftの公式情報でも、組織にAD RMSが展開されている場合はAzure Rights Managementサービスを有効化しないよう明記されています。(Microsoft Learn)
AD RMSから移行する場合は、キー、テンプレート、URLなどの構成データをエクスポートし、Azure Rights Management側へ取り込む手順が関係します。公式の移行手順では、可能であればインポート処理の後にAzure Rights Managementを有効化することが推奨されており、先に有効化している場合は追加手順が必要になるとされています。(Microsoft Learn)
有効化前に確認すべきチェックリスト
本番テナントで作業する前に、次の項目を確認しておきましょう。
| チェック項目 | 確認内容 | 不備がある場合のリスク |
|---|---|---|
| サービスプラン | Azure Rights Managementを含むMicrosoft Purview Information Protectionのサービスプランがあるか | 有効化や暗号化機能の利用ができない |
| AD RMS | オンプレミスAD RMSを利用中か | 既存の保護環境と衝突し、移行作業が複雑になる |
| 管理者ロール | 作業者に必要な権限があるか | Connect-AipService後の操作に失敗する |
| PowerShell環境 | AIPServiceモジュールを使えるWindows PowerShell環境か | PowerShell 7など非対応環境で作業して失敗する |
| 展開対象 | 全社展開か、パイロット展開か | 意図せず全ユーザーが暗号化を適用できる |
| ユーザー・グループ同期 | オンプレミスユーザーやグループがMicrosoft Entra IDに同期されているか | 権限付与やグループ指定が正しく機能しない |
| Exchange構成 | IRM構成やMessage Encryptionの利用要件を満たすか | 暗号化メールの閲覧、検索、DLP連携に制限が出る |
AIPServiceモジュールはWindows PowerShellのみをサポートし、PowerShell 7はサポートされていません。また、前提条件としてWindows PowerShell 3.0以上、Microsoft .NET Framework 4.8以上が示されています。(Microsoft Learn)
管理者権限については、Connect-AipServiceの公式情報で、Microsoft 365テナントのグローバル管理者、Azure ADテナントのグローバル管理者、Azure Information Protection管理者、コンプライアンス管理者、コンプライアンス データ管理者などが例示されています。(Microsoft Learn)
PowerShellで状態確認と有効化を行う手順
本番環境で作業する場合は、まず状態確認を行い、必要な場合のみ有効化します。手順の基本形は次のとおりです。
AIPServiceモジュールを準備する
Install-Module -Name AIPService
Import-Module AIPServicePowerShellギャラリーからAIPServiceモジュールをインストールする場合は、管理者としてPowerShellを起動してInstall-Module -Name AIPServiceを実行します。既存環境で古いAADRMモジュールを使っている場合、AIPServiceが後継モジュールであるため、旧モジュールの扱いも確認しておきましょう。(Microsoft Learn)
Azure Rights Managementの状態を確認する
Connect-AipService
Get-AipServiceGet-AipServiceは、テナントの保護サービスが有効化されているかを確認するコマンドレットです。結果がEnabledであれば有効、Disabledであれば無効です。(Microsoft Learn)
状態確認だけで済む場合は、ここで作業を止めても構いません。不要なEnable-AipServiceの実行は避け、変更管理の記録に「確認のみ」と残しておくと監査対応がしやすくなります。
必要な場合のみ有効化する
Enable-AipService
Get-AipService
Disconnect-AipServiceEnable-AipServiceは、Azure Information Protectionの保護サービスを有効化し、テナント内のユーザーが文書やメールを保護できるようにするコマンドレットです。(Microsoft Learn)
作業後はGet-AipServiceで状態を再確認し、Disconnect-AipServiceで切断します。AIPServiceモジュールの公式手順でも、構成コマンドの実行後はベストプラクティスとして切断することが説明されています。(Microsoft Learn)
段階展開にはオンボーディング制御を使う
全社一斉に暗号化機能を解放すると、ユーザーが誤って共有範囲を狭めたり、業務アプリや外部共有フローで想定外のアクセス拒否が発生したりすることがあります。最初はIT部門、情報システム部門、法務・人事などの限定グループで検証し、その後に部門単位で広げるのが安全です。
オンボーディング制御では、指定したセキュリティグループやライセンス状態に基づいて、Azure Information Protectionでコンテンツを保護できるユーザーを制御できます。この設定は管理ポータルではなくPowerShellで行います。(Microsoft Learn)
セキュリティグループで限定する例
Set-AipServiceOnboardingControlPolicy `
-UseRmsUserLicense $False `
-SecurityGroupObjectId "<security-group-object-id>"この方法では個別ユーザーではなく、グループを指定します。公式情報でも、オンボーディング制御でグループを使う場合はセキュリティグループのオブジェクトIDを指定する必要があると説明されています。(Microsoft Learn)
ライセンスを持つユーザーに限定する例
Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $True正しくライセンスが割り当てられているユーザーだけに保護機能を使わせたい場合は、この設定を検討します。ライセンス割り当てと実際の展開対象が一致している組織では、運用しやすい方法です。
オンボーディング制御を外す例
Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $Falseパイロットが完了し、制御が不要になった場合は、オンボーディング制御を解除して全体展開へ移行します。ただし、いきなり解除するのではなく、ヘルプデスクへの問い合わせ増加、ラベルポリシーの反映状況、外部共有の業務影響を確認してから進めましょう。
秘密度ラベルとの関係を整理する
Azure Rights Managementを有効化しただけでは、運用設計は完了しません。実際にユーザーが文書やメールへ暗号化を適用する場面では、Microsoft Purview Information Protectionの秘密度ラベルを使うのが基本です。公式情報でも、暗号化を適用する最も簡単で推奨される方法として秘密度ラベルが案内されています。(Microsoft Learn)
秘密度ラベルで暗号化を構成する際は、ラベル作成・編集時にアクセス制御を設定します。管理者は、あらかじめ権限を割り当てる方法と、ユーザーがラベル適用時に権限を指定できる方法を選べます。(Microsoft Learn)
実務では、次のようにラベルを分けると運用しやすくなります。
| ラベル例 | 暗号化の考え方 | 向いている用途 |
|---|---|---|
| 社外秘 | 社内ユーザーのみ閲覧・編集可能 | 経営資料、社内規程、部門資料 |
| 極秘 | 特定グループだけ閲覧可能、印刷や転送を制限 | 人事情報、M&A、役員会資料 |
| 取引先共有可 | 指定した外部ドメインや受信者に限定 | 契約書、見積書、共同プロジェクト資料 |
| 暗号化なしの分類ラベル | 分類のみ行い、アクセス制御はしない | 一般資料、公開予定資料 |
最初からすべてのラベルに暗号化を付けると、ユーザーが混乱しやすくなります。まずは機密度が高く、誤共有時のリスクが大きいデータから暗号化ラベルを設計するのが現実的です。
管理者が失敗しやすいポイント
管理ポータルで有効化ボタンを探してしまう
現在の公式手順では、Azure Rights Managementサービスの有効化・無効化は管理ポータルからではなくPowerShellで行います。ポータル上のラベル設定や暗号化設定を見ているだけでは、サービス自体の状態確認が抜ける可能性があります。(Microsoft Learn)
切り分けの最初にGet-AipServiceを実行する運用にしておくと、「ラベルが反映されない」「暗号化メールが使えない」といった問い合わせの原因を早く絞り込めます。
AD RMS移行前に有効化してしまう
AD RMSを利用している環境では、Azure Rights Managementの有効化が移行計画に影響します。公式の移行手順では、可能であれば構成データのインポート後にAzure Rights Managementを有効化することが示されています。(Microsoft Learn)
既存のAD RMSテンプレート、保護済みファイル、ExchangeやSharePointとの連携がある場合は、単純な「クラウド版へ切り替え」と考えず、移行プロジェクトとして扱うべきです。
グループ変更がすぐ反映されると思い込む
Azure Rights Managementでは、パフォーマンス上の理由でグループメンバーシップがキャッシュされます。Microsoftの公式情報では、Microsoft Entra ID上のグループメンバーシップ変更がAzure Rights Managementで有効になるまで最大3時間かかる場合があると説明されています。(Microsoft Learn)
パイロットテストでは、グループにユーザーを追加してすぐに「使えない」と判断しないようにしましょう。テスト計画には、反映待ち時間を含める必要があります。
既存ラベルへの暗号化追加を軽く見てしまう
既存の秘密度ラベルに後から暗号化を追加する場合、すでにラベルが付いたアイテムへの影響を確認する必要があります。Microsoftの公式情報では、ラベルの暗号化設定変更は新しくラベル付けされたアイテムに適用されるケースや、ユーザーの再認証タイミングで反映されるケースが説明されています。(Microsoft Learn)
特に、ユーザーが権限を指定するラベルと、管理者が権限を固定するラベルでは、既存アイテムへの影響が異なります。重要文書が多いラベルを変更する前に、テストファイルで挙動を確認しましょう。
開発者・自動化担当者が確認すべき点
社内アプリやバッチ処理で保護ファイルを扱う場合は、Azure Rights Managementを有効化するだけでは不十分です。アプリケーション側で、ユーザーに付与された権限を確認し、許可されていない操作を実行できないように制御する必要があります。
Microsoft Purview Information Protection SDKの公式情報では、Information Rights Managementの権限をチェックして強制する責任はアプリケーション開発者にあると説明されています。権限チェックを怠ると、データ損失につながる可能性があります。(GitHub)
たとえば、保護ファイルを別形式に出力する機能を持つアプリでは、ユーザーにEXTRACTやOWNER相当の権限があるかを確認する必要があります。画面を持つアプリでは、印刷、コピー、エクスポート、編集などのUI操作を権限に応じて無効化する設計が必要です。(GitHub)
また、運用自動化でConnect-AipServiceを使う場合、サービスプリンシパル認証も選択肢になります。公式情報では、証明書またはクライアントシークレットを使ったサービスプリンシパル接続例が示されており、必要なAPI権限としてApplication.Read.Allが説明されています。(Microsoft Learn)
本番自動化では、管理者パスワードをスクリプトに直書きしないこと、証明書やシークレットの有効期限を監視すること、実行ログにトークンや資格情報を出さないことが基本です。
展開後の検証方法
Azure Rights Managementを有効化したら、コマンドの成功だけで完了にしないことが大切です。Microsoftの公式情報では、簡単な検証方法として、あるユーザーで暗号化を適用した文書またはメールを作成し、別のコンピューター上の別ユーザーで開いて利用できるか確認する方法が示されています。(Microsoft Learn)
検証では、次の観点を確認しましょう。
| 検証項目 | 確認内容 |
|---|---|
| ラベル表示 | 対象ユーザーに暗号化ラベルが表示されるか |
| 暗号化適用 | Word、Excel、Outlookなどでラベルを適用できるか |
| 権限制御 | 許可されたユーザーだけが開けるか |
| 禁止操作 | 印刷、転送、コピー、エクスポートなどが想定どおり制限されるか |
| 外部共有 | 外部受信者が必要な認証を経て開けるか |
| Exchange連携 | Outlook on the web、モバイル、検索、DLPで支障がないか |
| 監査・運用 | 問い合わせ時に誰が何を確認するか決まっているか |
テストは「管理者アカウントで開けた」だけでは不十分です。一般ユーザー、対象外ユーザー、外部ユーザー、モバイル利用者など、実際の業務パターンに近いアカウントで確認しましょう。
管理者が次に取るべき行動
Microsoft PurviewでAzure Rights Managementを扱う場合、最初の一歩はサービスの状態確認です。Get-AipServiceで有効・無効を確認し、AD RMSの利用状況、ライセンス、PowerShell環境、展開対象を整理してから有効化を判断します。
本番展開では、いきなり全社展開するよりも、セキュリティグループを使ったオンボーディング制御でパイロットを行う方が安全です。その後、秘密度ラベルの設計、Exchange構成、外部共有、開発アプリの権限チェックまで含めて検証すれば、暗号化による業務停止リスクを抑えながら情報保護を強化できます。
まずは、現在のテナントで次の3つを確認してください。
Connect-AipService
Get-AipService
Disconnect-AipService結果がEnabledなら、次は秘密度ラベルと展開範囲の見直しに進みます。Disabledなら、AD RMSの有無とライセンスを確認したうえで、パイロット展開の計画を作成してからEnable-AipServiceを実行するのが安全です。
コメント