Microsoft 365 アイテム保持ポリシーの変更を監視する方法
保持ポリシーに目を光らせる
閲覧者は、監査目的で変更が強調表示されるように、アイテム保持ポリシーの設定を監視する方法を尋ねました。保持ポリシーが Exchange Online、SharePoint Online、ビジネス用 OneDrive、およびチームに保存されているコンテンツに与える影響を考えると、誰が何をしたかを知るだけなら、ポリシーの更新に目を光らせておくことをお勧めします。 保持ポリシーの更新が無効になった場合.保存ポリシーの性質は、実装後に更新する必要がめったにないためです。保持ポリシーを更新する有効な理由としては、保存期間の変更 (たとえば、5 年から 7 年) や保存場所の追加などがあります。
アラートポリシー (Microsoft 365 コンプライアンス センターで管理) は、管理者が構成の変更を監視する必要がある自然な出発点であり、アラート ポリシーが非常に柔軟性がなく、限られた一連のアクティビティのみをチェックできることが分かるまでです (図 1)。アイテム保持ポリシーの更新は、一覧に含まれません。

アイテム保持ポリシーの種類
サポートされるアクションのセットにアラート ポリシーに保持ポリシーが含まれていない理由の 1 つは、保持ポリシーがいくつかのシナリオをカバーしていることです。
- すべての SharePoint Online サイトのように、ワークロードのすべてのターゲットの場所に保持設定を適用する組織全体の保持ポリシー。アイテム保持ポリシー チーム 又は ヤマー は、それらのワークロードに属するコンプライアンス・レコードのみを処理できます。
- 対象の場所に保持設定を適用する組織以外のアイテム保持ポリシー。
- アイテムの一致条件に保持ラベルを適用するアイテム保持ポリシーを自動適用する 自動ラベル ポリシーを使用して、チーム会議のレコーディングを検索して保持ラベルを適用します).
幸い、ユーザーが保持ポリシーを作成、更新、または削除すると、コンプライアンス センターは Office 365 監査ログに監査イベントをキャプチャします。このデータは、監査ログ検索、アラート ポリシー、および Microsoft 365 クラウド アプリ セキュリティ ( Office 365 クラウド アプリ のセキュリティのバリエーション Office 365 E5 に含まれているので、監査ログを検索しても何も失われたり見落とされたりしません。ただし、説明するとおり、保持ポリシーの更新のために記録される監査イベントは、必要に合った情報や有用性を備えています。
監査ログの検索
監査ログを検索する場合は、常に、何を探しているのかを知ることが重要です。私は陳腐に聞こえることを知っていますが、キャプチャされた監査レコードの数と合理的なサイズのテナントで処理されるデータの量を考えると、特定のアクションのレコードを探することは、しばしば干し草の山でことわざの針を探すようなものです。通常のアプローチでは、監視するアクションを実行して、ワークロードが監査イベントを生成し、30 分ほど待ってから、アクションを実行した期間の監査ログ検索を実行します。これにより、Office 365 は監査レコードをログに取り込む時間を与えます。その後、検索で見つかったレコードを見て、実行されたアクションに関連するレコードを見つけることができます。イベントには、次の値が含まれます。 オペレーションズ 分析するイベントを見つけるために、後続の監査ログ検索で使用する監査レコードのプロパティ。
保持ポリシーは、ポリシー (基本設定) とルール (アクション) で構成される親子構造を使用するため、2 つの操作は保持ポリシーに対する変更を記録するため、2 つの操作は、保持ポリシー、および ポリシーを設定します。 イベントはポリシーに対する変更をキャプチャします。 保持コンプライアンスルールを設定します。 イベントは、ポリシーに属するルールに対する変更を記録します。
アイテム保持監査ポリシー レコードの処理
表面的には、タスクは簡単に思えます。
- 監査ログ検索の日付範囲を設定します。
- 監査ログで、日付範囲内で発生する目的のタイプのイベントを検索します。
- 返された監査レコードを処理して、データを抽出およびレポートします。
最初の 2 つの手順は簡単です。3 つ目は、Microsoft が Base64 エンコードを使用して監査レコードの保持ポリシー名をあいまいにするため、より困難です。なぜこれが必要なのか分かりません。監査レコードを参照する可能性が高いのは管理者のみで、コンプライアンス センターで保持ポリシーの名前を確認できます。それでも、監査ログデータは次のように処理する必要があります。
CreationTime : 2021-07-23T11:16:28 Id : 14ed1f37-8c48-4980-7fbf-08d94dcb5122 Operation : SetRetentionCompliancePolicy OrganizationId : b662313f-14fc-43a2-9a7a-d2e27f4f3478 RecordType : DataGovernance UserKey : eff4cd58-1bb8-4899-94de-795f656b4a18 UserType : Regular Version : 1 Workload : SecurityComplianceCenter UserId : Tony.Redmond@office365itpros.com ExtendedProperties : {@{Name=Workload; Value=Exchange, SharePoint, OneDriveForBusiness, Skype, ModernGroup}, @{Name=CreatedBy; Value=Tony Redmond}, @{Name=CreatedDateUTC; Value=28/04/2017 19:12:30}, @{Name=LastModifiedDateUTC; Value=29/04/2017 02:07:40}...} ObjectType : CompliancePolicy Parameters : {@{Name=CmdletOptions; Value=-Identity "OTk2ZjI2MDMtZTE2NC00MGRkLWEwNTAtYzUzZDdjYTQzOWU30" -Comment "This retention policy removes old items from Office 365 Groups that use a connector to fetch content from an external data source like Twitter. Updated 23 July 2021"}, @{Name=Cmdlet; Value=Set-RetentionCompliancePolicy}}
アイデンティティを与える OTk2ZI2MDMtZTE2NC00MGRkLWWNtatYzuzZDdjTQzOWU30 into アン オンライン Base64 デコーダ 996f2603-e164-40dd-a050-c53d7ca439e7であることを明らかにする。つまり、GUID です。その後、一連のアイテム保持ポリシーを確認して、その GUID を持つポリシーの名前を見つけることができます。このすべては非常に可能ですが、必要以上の作業です。特に激怒しているのは、監査レコードが 保持コンプライアンスルールを設定します。 イベントはクリア テキストでポリシー名を報告します。
私が遭遇したもう一つの問題は、 保持コンプライアンスポリシーの取得 コマンドレットは、テナント内のポリシーの完全なセットを返しません。このコマンドレットは、Teams プライベート チャネルまたは Yammer コミュニティを処理するために作成されたアイテム保持ポリシーの詳細を返しません。これらのポリシーを見つけるには、 取得-アプリ保持コンプライアンスポリシー.マイクロソフトでは、アプリ固有のアイテム保持ポリシーと、より一般的に使用される保持ポリシーを区別しているようです。この理論は、チーム (通常の) チャネル メッセージとチャットの保持ポリシーが 保持コンプライアンスポリシーの取得.保持ポリシーの PowerShell コマンドレットの動作に一貫性があるとよいでしょう。
最終的なコード
私が書いたコードの流れは、このように終わりました:
- テナントの保持ポリシーの GUID と名前を含むハッシュ テーブルを作成します。個別の呼び出しが 保持コンプライアンスポリシーの取得 そして 取得-アプリ保持コンプライアンスポリシー ハッシュ テーブルにすべてのポリシーの GUID が含まれていることを確認します。その後、ハッシュ テーブルを検索して、GUID をポリシー名に解決します。
- アイテム保持ポリシーの更新の監査レコードを検索します。私は30日前に戻ることを選びました。Office 365 E3 テナントは 90 日前に戻ることができますが、Office 365 E5 テナントは 365 日前に戻ることができます。
- レコードを保持ポリシーの更新と保持ルールの更新に分割します。
- レポートを作成するには、保持ルールの更新を処理します。
- レポートを作成するには、アイテム保持ポリシーの更新を処理します。ここでは、Base64 の値を変換し、保持ポリシーの名前を知るためにハッシュ テーブルでルックアップを行う必要があります。
- CSV 形式で出力ファイルを生成し、保持ポリシーの更新を画面に表示する アウトグリッドビュー コマンドレット (図 2)。

監査レコードを処理するメイン ループを以下に示します。ポリシー名の Base64 バージョンがどのように抽出されているかを確認できます。 監査データ GUID に変換された後、ポリシー名で終わるハッシュ テーブルに対して解決された、監査レコードのプロパティ:
$AuditReport = [System.Collections.Generic.List[Object]]::new() ForEach ($AuditRecord in $AuditRecords) { $AuditData = $AuditRecord.AuditData | ConvertFrom-Json $PolicyDetails = $AuditData.Parameters | ?{$_.Name -eq "CmdletOptions"} | Select -ExpandProperty Value $PolicyName = $Null; $PolicyGuid = $Null; $Encodedtext = $Null If ($PolicyDetails -Like "*RetryDistribution*") { # The change is to restart distributions to target locations $Start = $PolicyDetails.IndexOf('"')+1 $End = $PolicyDetails.IndexOf("-Retry")-13 $PolicyName = $PolicyName = $PolicyDetails.SubString($Start,$End) } Else { # Update made to the policy $Start = $PolicyDetails.IndexOf('"')+1 $EncodedText = $PolicyDetails.SubString($Start,48) $PolicyGuid = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($EncodedText)) $PolicyName = $RetentionPolicies.Item($PolicyGuid) # See if we can find the retention policy name } $DataLine = [PSCustomObject] @{ Date = $AuditRecord.CreationDate User = $AuditData.UserId Policy = $PolicyName PolicyGuid = $PolicyGuid DetailsLogged = $PolicyDetails EC = $EncodedText } $AuditReport.Add($DataLine) }
できます GitHub からスクリプトのコピーをダウンロードする.情報の配布方法 (電子メール、Teams チャネルへの投稿、または印刷レポート) と、各監査レコードに対して抽出された詳細情報から詳細情報を抽出する場合は、お任せします。たとえば、この情報は、アイテム保持ポリシーの更新は、パブリック フォルダーをターゲットの場所として追加し、ビジネス用 OneDrive を削除することを示します。
-Identity "ZDNiYmIyY2ItMzRjMC00ZWMxLWE0MTgtMzRmZWY2YzU2MzNi0" -AddPublicFolderLocation ("All") -RemoveOneDriveLocation ("All")
この情報は、ポリシーの説明の更新と、選択した Microsoft 365 グループを場所として追加する内容を示しています。
-Identity "NmE5ZjdiZjAtNTA3Yi00YTQ5LTgzYzMtMDFhNzAxOTU4ZDEx0" -Comment "Make sure that Office 365 for IT Pros source documents are not deleted." -AddModernGroupLocation ("Office365ITPros@Office365ITPros.com")
本来あるべき以上に難しい
2 日間のうち、何が起こっているのかを把握し、ソリューションをコーディングした後、Office 365 監査ログを使用してアイテム保持ポリシーの更新を報告することは、本来よりも複雑で難しい作業であると言っても過言ではないと思います。特定のポリシーに対する新しいコマンドレットの導入、ポリシー名をあいまいにするための Base64 コーディングの使用、監査レコードに含まれる情報の一般的な書式設定は、すべて問題を引き起こします。監査データの形式と内容を簡素化して改善する方法について少し考えると、この作業を簡単に行うには長い道のりが見えます。
このような洞察は簡単には得られない。あなたは技術を知り、舞台裏を見る方法を理解する必要があります。の知識と経験から利益を得る IT 担当者向け Office 365 Office 365 およびより広範な Microsoft 365 エコシステムをカバーする最高の電子ブックを購読してチームを編成します。
関連
ディスカッション
コメント一覧
まだ、コメントがありません