管理者を偽装したユーザーからの保護
(この記事は 2014 年 9 月 12 日に The Exchange Team Blog に投稿された記事 Protecting against Rogue Administrators の翻訳です。最新情報については、翻訳元の記事をご参照ください。)
「管理者を偽装したユーザーからメッセージング環境を保護するにはどのようにすればよいか」という質問が届くことがあります。この場合、基本的には次の 2 つのことについて検討する必要があります。
- 管理者を偽装したユーザーからデータを削除されないようにする方法
- 管理者を偽装したユーザーからデータにアクセスされたり、データを改ざんされたりしないようにする方法
この問題について議論すると、バックアップ アーキテクチャの話題のみに終始してしまうことがあります。しかし、Exchange ネイティブ データ保護やその他のサードパーティ製バックアップ ソリューションを実装しても、考えられる損害を軽減できるだけで、バックアップだけでは管理者を偽装したユーザーからシステムを保護することはできません。メッセージング データ (ライブ データまたはバックアップ データ、およびその両方) への特権アクセスを持つ管理者は、システムを混乱させることができます。このため、企業内で何らかの運用上の対策を取り、管理者を偽装したユーザーから攻撃を受けるリスクを軽減する必要があります。
重要 : この記事は、管理者権限を制限する手順を包括的に説明するものではなく、有効な指針や技術を紹介するものですのでご注意ください。
セキュリティに関する 10 の鉄則
Microsoft Security Response Center は、セキュリティに関する 10 の鉄則 (英語) を公開しました。内容は次のとおりです。
> 鉄則 1: 悪意のある攻撃者の誘いに乗り、攻撃者のプログラムをあなたのコンピューターで実行した場合、もはやそれはあなたのコンピューターではない
> 鉄則 2: 悪意のある攻撃者があなたのコンピューターのオペレーティング システムを改ざんした場合、もはやそれはあなたのコンピューターではない
> 鉄則 3: 悪意のある攻撃者があなたのコンピューターに対して物理的なアクセスを無制限に行える場合、もはやそれはあなたのコンピューターではない
> 鉄則 4: 悪意のある攻撃者があなたの Web サイトに対して自由にプログラムをアップロードできてしまうのなら、もはやそれはあなたの Web サイトではない
> 鉄則 5: セキュリティが強力であっても、パスワードが弱ければ台無しである
> 鉄則 6: コンピューターのセキュリティが守られているかどうかは、その管理者が信頼できるかどうかにかかっている
> 鉄則 7: 暗号化されたデータのセキュリティが守られているかどうかは、解読キーのセキュリティにかかっている
> 鉄則 8: 古いウイルス検出プログラム (ウイルス定義ファイル) はウイルス検出プログラムがないも同然である
> 鉄則 9: 現実の生活でも Web 上でも完全な匿名などあり得ない
> 鉄則 10: テクノロジは万能ではない
この指針はマイクロソフトが Office 365 のセキュリティ保護の基礎としているもので、オンプレミス環境にも同様に適用できる内容となっています。
Active Directory
Exchange は Active Directory に依存していて、構成パーティション内に構成データ、ドメイン パーティション内に受信者データが保存されています。エンタープライズ管理者グループまたはルート ドメイン管理者グループのいずれかのメンバーであるフォレスト管理者は、ディレクトリのあらゆる領域やディレクトリに保存されているデータを制御可能です (このとき、特定のアクセス許可を他のユーザーに委任し、通常はフォレスト内で指定された狭い範囲の、非常に限定された特定の操作を実行できるようにしている場合があります)。同様に、各ドメイン パーティションのドメイン管理者も、それぞれの受信者データを所有しています。通常、フォレスト内またはドメイン内に限定されている操作は、フォレスト管理者のみが排他的に実行できるように制限します。これは、構成変更の影響が広範囲に副次的な影響を与えることを防止するためです。
現在、多くの企業では、アクセス許可の付与を最小限に抑える形で Active Directory を運用しています。まだこの運用モデルを採用していない場合は、最優先課題として対応してください。ここで、エンタープライズ管理者グループまたはドメイン管理者グループのメンバーは、Exchange 管理ツールを使用しなくても受信者のメッセージング環境の構成設定や Exchange の構成を変更できることに注意する必要があります。詳細については、「Active Directory のセキュリティ対策のベスト プラクティス (英語)」を参照してください。
Active Directory のアクセス許可の付与を最小限に抑えることに加え、管理者の素性のチェックなど、管理者自身の信頼性を確認する各種のプロセスを実装し、鉄則 6 に関するリスクを軽減する必要があります。さらに、Forefront Identity Manager などの ID 管理ソリューションの導入による、管理アクセス許可の要求および承認の管理や監査も検討します。
アクセス許可
Exchange 管理者は、メッセージング環境の管理にさまざまな種類のツールを使用できますが、その中でも特に推奨されるツールがリモート PowerShell です。Exchange がアクセスの認証を行い、実行されるすべての操作を監査することができます。一方、Exchange 管理者に Active Directory での追加のアクセス許可 (ユーザーの任意の属性を変更する権限など) が付与されている場合、管理者が LDP、ADSIEdit、ローカルの PowerShell、スクリプトなどのツールを使用して受信者データや構成データを変更したり、システムに組み込まれている認証や監査チェックを省略したりできるという危険があります。
リモート PowerShell フレームワークの外部で何らかの変更が行われる可能性を効果的に軽減するには、先にも述べたとおり、Active Directory のセキュリティ対策のベスト プラクティス (英語) に喫緊に取り組むことが必要です。Exchange 管理者は Active Directory 管理者ほど厳密な評価を受けない場合が多いですが、このため、Exchange 管理者にはリモート PowerShell を回避できるような Active Directory のアクセス許可 (受信者の変更など) を付与しないようにする必要があります。
Active Directory のアクセス許可が正確に狭い範囲に制限されていれば、管理者を偽装したユーザーは、どのようなツールを使用したとしても不正な変更を加えることは難しくなります。
PowerShell
Exchange では PowerShell 内の機能であるリモート PowerShell が使用されているため、管理者がリモート システムからコマンドを実行できます。リモート PowerShell とは Exchange で使用可能な機能で、コマンドレットの実行の監視、および役割ベースのアクセス制御 (RBAC) による認証の強制適用が可能です。
管理者がリモート PowerShell を使用した場合のみメッセージング環境を管理できるようにする方法の 1 つとして、管理者ワークステーションで Exchange 管理ツールのインストールを禁止するというものがあります。この方法を採用すると、管理者は Exchange 管理センターを使用する、またはリモート シェルを使用して Exchange に接続しなければ管理できなくなります。
さらに、PowerShell 3.0 以降では、モジュールのログ記録 (英語) を有効にすると堅牢な監査機能を使用できます。PowerShell モジュールのログでは、特定のモジュールでのパイプライン実行イベントを取得し、そのデータを Windows PowerShell のイベント ログに記録します。ログに記録されたイベントのうち、イベント ID 800 ( パイプライン実行の詳細 ) では、コマンド ラインで実行されたコマンド、およびスクリプトが実行された場合はスクリプト名を確認できます。スクリプトが実行された場合、 ScriptName の値に実行されたスクリプトのファイル名が代入され、スクリプトの各行のイベントがログに記録されます。このイベントには、それぞれ該当する行で実行されたコマンドが含まれます。イベント ログに記録されたデータは収集および解析が可能で、またそこから得られる監査データにより企業はどのような PowerShell 操作が環境内で実行されたかを把握できます。
データ破壊のリスクを軽減する
Exchange 管理者は、Exchange データにアクセスし、それを破壊することが可能なアクセス許可を所有しています。管理者からメッセージング データを保護するための最適な方法は、次のとおりです。
- 管理者が悪意のある操作を実行する機会を制限します。これには、ローカル管理者のアクセス許可の取り消し、Applocker の導入、破壊的な操作が可能なコマンドレットへのアクセス許可の取り消し、時間差データベース コピーの導入などの手段があります。
- 管理者の操作をすべてログに記録し、そのログを監視して警告やレポートの生成を実行します。
- アクセス許可の付与を最小限に抑える運用モデルを実装し、意図された操作のみにアクセス許可を与える形で昇格させます。このとき、ほとんどまたはすべての管理者の操作が「制御平面」経由で実行されるアクセス制御モデルを実装すると、より効果的です。これは管理者が Exchange で何らかの操作を実行するように要求する場合に使用されるもので、この要求を実際に実行するかどうかを決定するためのビジネス ロジックを実装することができます。このビジネス ロジックには、この操作に対して他のユーザーの確認と承認を要求したり、従業員のスケジュールをシステムで確認して要求元のユーザーが休暇中でないかなどを確認したりするものなどがあります。
ローカルの管理者アクセスを取り消す
Exchange の管理タスクの大半はリモート PowerShell から実行可能なので、 Exchange 管理者が Exchange サーバーにローカル管理者としてアクセスする必要があるのは、システムの更新時 (ドライバーの更新プログラムのインストール、 Exchange の累積更新プログラムのインストール、 OS の更新など) のみです。このため、ローカル管理者としてのアクセスを制限し、必要なときに指定した期間だけアクセス許可を付与して、その後は再度取り消すことができます。
ローカル管理者としてアクセスしないと、環境を適切に管理するために必要な Exchange サーバーの正常性に関する特定の情報を取得できません。このため、管理者は下記のアクセス許可を所有している必要があります。
ファイル共有の作成 (適切なセキュリティ グループからの読み取り専用アクセスのみを許可してセキュリティを確保します)。Exchange の診断ログ (既定の場所は %Program Files%\ Exchange Server\V15\Logging および %SystemDrive%\inetpub\logs) へのアクセスに必要です。
イベント ログの読み取り専用アクセス。適切なセキュリティ グループをメンバーのサーバーのローカルに存在する Event Log Readers セキュリティ グループに追加してアクセス許可を付与します。
カウンターを実行するアクセス許可。適切なセキュリティ グループをメンバーのサーバーのローカルに存在する Performance Monitor Users セキュリティ グループに追加してアクセス許可を付与します。
管理者がパフォーマンス カウンターのログをスケジュール設定して、トレースを有効化および収集するためのアクセス許可。適切なセキュリティ グループをメンバーのサーバーのローカルに存在する Performance Log Users セキュリティ グループに追加してアクセス許可を付与します。
この他に、管理者のワークステーションで所有しているローカル管理者としてのアクセス許可を取り消します。これにより、管理者は承認されたアプリケーション以外は実行できず、また管理者の操作の監査および監視を目的として設置されたあらゆるセキュリティ機構を回避できないようになります。アクセス許可の付与を最小限に抑えた状態で Windows を実行する場合についての詳細は、「Windows でユーザー アカウントに付与するアクセス許可を最小限に抑える指針の適用 (英語)」を参照してください。
ローカル管理者としてのアクセス許可を取り消すと、鉄則 2 および鉄則 3 に関するリスクが軽減されます。
AppLocker
AppLocker は、悪意のあるソフトウェアや不正なアプリケーションから企業のサーバー環境への攻撃を防ぐ、強力な保護機能を提供します。AppLocker では Exchange ユーザーが使用するアプリケーションを制限することができるため、 AppLocker のポリシーが適用されているサーバーでは、承認リストに入っているアプリケーション (Exchange 管理ツールや承認済みの PowerShell スクリプトなど) のみが実行されます。詳細については、 TechNet の AppLocker に関する記事をご覧ください。
AppLocker を使用すると、鉄則 1 に関するリスクを軽減できます。
破壊的な操作が可能なコマンドレットへのアクセス許可を取り消す
Exchange 2010 と Exchange 2013 のどちらでも、管理者が特定の管理タスクを実行するための機構である役割ベースのアクセス制御 (RBAC) を使用できます。 RBAC では、特定のコマンドレットや、コマンドレットの特定のプロパティに対するアクセス許可を制限するなど、メッセージング環境の管理を非常にきめ細かく制御できます。
RBAC の詳細については、次の記事を参照してください。
管理者監査ログの機能では、管理者が実行した操作が記録されますが、破壊的な操作が認証された場合にその実行を防止することはできません。しかし、RBAC を使用すると、破壊的な操作が可能なコマンドレットへのアクセス許可を取り消して、攻撃範囲を縮小することができます。「破壊的な操作が可能なコマンドレット」とは、メッセージング データへのアクセス、変更、削除が可能なコマンドレットを指します。
次の表は、破壊的な操作が可能なコマンドレット (Remove-Mailbox など) とパラメーターの一覧です。ここに示すコマンドレットについては、日常的に使用する中で、お客様の環境でどのように使用されているかを把握し、アクセス許可を取り消す必要があるかどうかを評価してください。
コマンドレット |
パラメーター |
役割 |
Add-ResubmitRequest |
|
データベース |
Disable-Mailbox |
|
メール受信者 |
Move-ActiveMailboxDatabase |
MountDialOverrride |
データベース |
Mount-Database |
Force |
データベース |
Remove-AcceptedDomain |
|
リモートおよび承認済みドメイン |
Remove-ActiveSyncDeviceAccessRule |
|
組織クライアント アクセス |
Remove-ActiveSyncDeviceClass |
|
組織クライアント アクセス |
Remove-ActiveSyncMailboxPolicy |
|
受信者ポリシー |
Remove-ActiveSyncVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-AddressBookPolicy |
|
アドレス一覧 |
Remove-AddressList |
|
アドレス一覧 |
Remove-ADPermission |
|
Active Directory アクセス許可 |
Remove-AuthRedirect |
|
組織クライアント アクセス、組織の構成 |
Remove-AuthServer |
|
組織クライアント アクセス |
Remove-AutodiscoverVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-AvailabilityAddressSpace |
|
フェデレーションの共有、メール ヒント、メッセージ追跡、組織の構成 |
Remove-ClassificationRuleCollection |
|
データ損失防止 |
Remove-ClientAccessArray |
|
組織クライアント アクセス |
Remove-ClientAccessRule |
|
組織クライアント アクセス |
Remove-CompliancePolicySyncNotification |
|
データ損失防止 |
Remove-ContentFilterPhrase |
|
Exchange サーバー、トランスポート検疫 |
Remove-DatabaseAvailabilityGroup |
|
データベース可用性グループ |
Remove-DatabaseAvailabilityGroupConfiguration |
|
データベース可用性グループ |
Remove-DatabaseAvailabilityGroupNetwork |
|
データベース可用性グループ |
Remove-DatabaseAvailabilityGroupServer |
|
データベース可用性グループ、Exchange サーバー |
Remove-DataClassification |
|
データ損失防止 |
Remove-DeliveryAgentConnector |
|
Exchange コネクタ |
Remove-DistributionGroup |
|
配布グループ、セキュリティ グループの作成とメンバーシップ、ExchangeCrossServiceIntegration |
Remove-DlpPolicy |
|
データ損失防止 |
Remove-DlpPolicyTemplate |
|
データ損失防止 |
Remove-DynamicDistributionGroup |
|
配布グループ |
Remove-EcpVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-EdgeSubscription |
|
エッジ サブスクリプション |
Remove-EmailAddressPolicy |
|
電子メール アドレス ポリシー |
Remove-ExchangeCertificate |
|
Exchange Server 証明書 |
Remove-FederatedDomain |
|
フェデレーションの共有 |
Remove-FederationTrust |
|
フェデレーションの共有 |
Remove-ForeignConnector |
|
フェデレーションの共有 |
Remove-GlobalAddressList |
|
アドレス一覧 |
Remove-GlobalMonitoringOverride |
|
組織の構成、表示専用構成 |
Remove-GroupMailbox |
|
ExchangeCrossServiceIntegration |
Remove-HybridConfiguration |
|
データベース コピー、フェデレーションの共有、メール受信者 |
Remove-IntraOrganizationConnector |
|
フェデレーションの共有 |
Remove-JournalRule |
|
ジャーナリング |
Remove-Mailbox |
|
受信者の作成 |
Remove-MailboxDatabase |
|
データベース |
Remove-MailboxDatabaseCopy |
|
データベース コピー |
Remove-MailContact |
|
メール受信者の作成、ExchangeCrossServiceIntegration |
Remove-MailUser |
|
受信者の作成、ExchangeCrossServiceIntegration |
Remove-MalwareFilterPolicy |
|
トランスポート検疫 |
Remove-MalwareFilterRule |
|
トランスポート検疫 |
Remove-ManagedContentSettings |
|
保有管理 |
Remove-ManagedFolder |
|
保有管理 |
Remove-ManagedFolderMailboxPolicy |
|
保有管理 |
Remove-ManagementRole |
|
役割管理、スコープ外役割管理 |
Remove-ManagementRoleAssignment |
|
役割管理、スコープ外役割管理 |
Remove-ManagementRoleEntry |
|
役割管理、スコープ外役割管理 |
Remove-ManagementScope |
|
役割管理 |
Remove-MapiVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-Message |
|
トランスポート キュー |
Remove-MessageClassification |
|
トランスポート ルール |
Remove-MigrationEndpoint |
|
移行 |
Remove-MigrationUser |
|
移行 |
Remove-MobileDeviceMailboxPolicy |
|
受信者ポリシー |
Remove-OabVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-OfflineAddressBook |
|
アドレス一覧 |
Remove-OrganizationRelationship |
|
フェデレーションの共有 |
Remove-OutlookProtectionRule |
|
Information Rights Management |
Remove-OutlookProvider |
|
組織クライアント アクセス |
Remove-OwaMailboxPolicy |
|
受信者ポリシー、メール受信者 |
Remove-OwaVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-PolicyTipConfig |
|
データ損失防止 |
Remove-PowerShellVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-PublicFolder |
|
パブリック フォルダー |
Remove-PublicFolderDatabase |
|
データベース |
Remove-ReceiveConnector |
|
受信コネクタ |
Remove-RemoteDomain |
|
リモートおよび承認済みドメイン |
Remove-RemoteMailbox |
|
メール受信者の作成 |
Remove-ResourcePolicy |
|
WorkloadManagement |
Remove-ResubmitRequest |
|
データベース |
Remove-RetentionPolicy |
|
保有管理 |
Remove-RetentionPolicyTag |
|
保有管理 |
Remove-RoleAssignmentPolicy |
|
役割管理 |
Remove-RoleGroup |
|
役割管理 |
Remove-RoleGroupMember |
|
役割管理 |
Remove-RoutingGroupConnector |
|
Exchange コネクタ |
Remove-RpcClientAccess |
|
組織クライアント アクセス |
Remove-SendConnector |
|
送信コネクタ |
Remove-ServerMonitoringOverride |
|
Exchange サーバー、表示専用構成 |
Remove-SettingOverride |
|
組織の構成 |
Remove-SharingPolicy |
|
フェデレーションの共有 |
Remove-SiteMailboxProvisioningPolicy |
|
チーム メールボックス |
Remove-StoreMailbox |
|
データベース |
Remove-ThrottlingPolicy |
|
受信者ポリシー、WorkloadManagement |
Remove-TransportRule |
|
トランスポート ルール、データ損失防止 |
Remove-UMAutoAttendant |
|
ユニファイド メッセージング |
Remove-UMCallAnsweringRule |
|
UM メールボックス |
Remove-UMDialPlan |
|
ユニファイド メッセージング |
Remove-UMHuntGroup |
|
ユニファイド メッセージング |
Remove-UMIPGateway |
|
ユニファイド メッセージング |
Remove-UMMailboxPolicy |
|
データベース コピー、ユニファイド メッセージング |
Remove-WebServicesVirtualDirectory |
|
Exchange 仮想ディレクトリ |
Remove-WorkloadManagementPolicy |
|
WorkloadManagement |
Remove-WorkloadPolicy |
|
WorkloadManagement |
Remove-X400AuthoritativeDomain |
|
リモートおよび承認済みドメイン |
Set-Mailbox |
Database、ArchiveDatabase |
障害復旧 |
Set-MailboxDatabaseCopy |
ReplayLagTime |
データベース コピー |
Set-TransportConfig |
|
ジャーナリング、組織トランスポート設定 |
Search-Mailbox |
DeleteContent |
メールボックス検索、メールボックスのインポート エクスポート |
Set-ResubmitRequest |
|
データベース |
Update-HybridConfiguration |
|
データベース コピー、フェデレーションの共有、メール受信者 |
Update-MailboxDatabaseCopy |
|
データベース コピー、データベース |
メモ : 上記の表には、後述の「データ アクセス コマンドレットへのアクセス許可を取り消す」の項で取り扱っているコマンドレットの一覧は含まれていません。しかし、こちらのコマンドレットも、メッセージング データにアクセス可能なものとして扱う必要があります。
たとえば、管理者がデータベース コピーを削除したり時間差データベース コピーの構成を操作したりできないようにするには、RBAC を使用して次の手順でこれらのコマンドレットへのアクセス許可を取り消します。
- 新しい役割グループを 2 つ ("Protected Organization Management" と "Protected Server Management") 作成します。
$ORoleGroup = Get-RoleGroup “Organization Management"
New-RoleGroup "Protected Organization Management" -Roles $ORoleGroup.Roles
$SRoleGroup = Get-RoleGroup “Server Management"
New-RoleGroup "Protected Server Management" -Roles $SRoleGroup.Roles
- 保護されている役割グループから "Database Copies" 役割を削除します。
Get-ManagementRoleAssignment -RoleAssignee "Protected Organization Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment
Get-ManagementRoleAssignment -RoleAssignee "Protected Server Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment
- "Protected Database Copies" 役割を作成します。
New-ManagementRole –Parent "Database Copies" –Name "Protected Database Copies"
- "Protected Database Copies" 役割から "Remove-MailboxDatabaseCopy" 役割のエントリを削除します。
Remove-ManagementRoleEntry "Protected Database Copies\Remove-MailboxDatabaseCopy"
さらに、"Protected Database Copies" 役割から ReplayLagTime パラメーターも削除して、管理者が時間差データベース コピーを無効化できないようにすることもできます。
Set-ManagementRoleEntry "Protected Database Copies\Set-MailboxDatabaseCopy" –Parameters ReplayLagTime -RemoveParameter
- 保護されている役割グループに "Protected Database Copies" 役割を追加します。
New-ManagementRoleAssignment –SecurityGroup "Protected Organization Management” –Role “Protected Database Copies"
New-ManagementRoleAssignment –SecurityGroup "Protected Server Management” –Role “Protected Database Copies"
- 保護されている役割グループにユーザーを追加します。
$OrgAdmins = Get-RoleGroupMember "Organization Management"
$SrvAdmins = Get-RoleGroupMember "Server Management"
$OrgAdmins | ForEach {Add-RoleGroupMember "Protected Organization Management" –Member $_.Name}
$SrvAdmins | ForEach {Add-RoleGroupMember "Protected Server Management" –Member $_.Name}
- "Organization Management" および "Server Management" の各役割グループから指定したユーザーを削除します。
上記の操作は、破壊的な操作が可能なそれぞれのコマンドレットについて、必要に応じて適宜繰り返します。指定したコマンドレットがどの役割に含まれているかを確認するには、次のコマンドレットを実行します。
Get-ManagementRoleEntry "*\<cmdlet>" | fl name,role
時間差データベース コピー
時間差データベース コピーとは、14 日以内の特定時点のデータベース コピーを展開するものです。 Exchange 2007 で初めて導入され、それ以来大幅に進化してきました。 推奨されるアーキテクチャにも含まれます。時間差データベース コピーを実装する主な理由は、まれに発生する重大な論理的破損から保護することですが、他に、管理者を偽装したユーザーにより削除されたメールボックスやアイテムの復元に使用することもできます。先に説明したアクセス制御機構を実装すると、時間差データベース コピーが管理者を偽装したユーザーによる破壊から保護されます。
データ アクセスによるリスクを軽減する
メッセージング環境で不正なデータ アクセスによるリスクを軽減することを目的として実装できる方法は、いくつかあります。たとえば、監査、Bitlocker によるディスク ドライブの暗号化、およびユーザー データへの管理者のアクセスを許可する特定のコマンドレットへのアクセス許可の取り消しなどがあります。
監査
メッセージング環境に実装可能な監査には複数の方法があります。Exchange では、管理者監査ログを有効化できます。管理者監査ログは、Exchange 管理シェル (EMS) または Exchange 管理センター (EAC) で実行されたすべての操作を取得します。
既定では、Get- および Search- 以外のすべてのコマンドレットが監査ログに記録されます。たとえば Search-Mailbox はコンテンツを削除できるため、リストへの追加が必要になる場合もあります。このときは、Set-AdminAuditLogConfig でコマンドレットのログ構成設定を変更できます。監査ログは調停メールボックスに保存されます。また、レポートには Search-AdminAuditLog コマンドレット、New-AdminAuditLogSearch コマンドレット、または EAC からアクセスできます。
サービスを管理している Exchange 管理者による操作の監査の他に、サーバー操作イベント (ログイン イベントなど) の監査も必要になる場合があります。この詳細については、Windows Server のセキュリティ監査の概要 (英語) に関する記事、および Active Directory のセキュリティ保護を目的とした監査ポリシーに関する推奨事項 (英語) の記事を参照してください。
Bitlocker
攻撃範囲を縮小するもう 1 つの方法として、 Bitlocker を使用することにより、サーバーに物理的にアクセス可能な管理者がディスク ドライブを取り外してその中に保存されているデータにアクセスすることを防止するという方法もあります。
先に述べたとおり、役割の分離は鉄則 7 のリスクを軽減するために早急に実施する必要があります。 Bitlocker の復元情報は Active Directory (その中の特に msFVE-RecoveryInformation 属性) に格納されているため、 Exchange 管理者にこのデータを 委任 (英語) することは絶対に避けてください。
データ アクセス コマンドレットへのアクセス許可を取り消す
RBAC を使用すると、メールボックスのデータへのアクセスが可能なコマンドレットへのアクセス許可を取り消して、攻撃範囲を縮小することができます。下記の表は、データへのアクセス許可を付与するコマンドレット、または管理者に対する追跡を無効化するコマンドレットの一覧です。ここに示すコマンドレットについては、日常的に使用する中で、お客様の環境でどのように使用されているかを把握し、アクセス許可を取り消す必要があるかどうかを評価してください。
コマンドレット |
役割 |
Add-ADPermission |
Active Directory アクセス許可 |
Add-MailboxFolderPermission |
メール受信者 |
Add-MailboxPermission |
メール受信者 |
Add-PublicFolderClientPermission |
パブリック フォルダー |
Export-Mailbox |
パブリック フォルダー |
Export-Message |
トランスポート キュー |
New-MailboxExportRequest |
メールボックス検索、メールボックスのインポート エクスポート |
New-MailboxSearch |
メールボックス検索、法的情報保留 |
New-MoveRequest |
メールボックスの移動 |
New-InboxRule |
メール受信者 |
Search-Mailbox |
メールボックス検索、メールボックスのインポート エクスポート |
Set-AdminAuditLogConfig |
監査ログ |
Set-InboxRule |
メール受信者 |
Set-JournalRule |
ジャーナリング |
Set-MailboxExportRequest |
メールボックス検索、メールボックスのインポート エクスポート |
Set-MailboxFolderPermission |
メール受信者の作成 |
Set-MailboxSearch |
|
New-TransportRule |
トランスポート ルール、データ損失防止 |
New-JournalRule |
ジャーナリング |
New-MailboxRestoreRequest |
メールボックス検索、法的情報保留 |
上記のコマンドレットへのアクセス許可を取り消すには、「破壊的な操作が可能なコマンドレットへのアクセス許可を取り消す」の項の手順 1 ～ 7 を実施します。
昇格を要求する
時間が経過するにつれ、管理者は必要な操作 (メールボックスの無効化、不要なトランスポート ルールの削除など) を実行するために、制限されているコマンドレットへのアクセス許可を少しずつ要求するようになります。この要求にはさまざまな方法で対応できます。たとえば、制限している各コマンドレット (および各プロパティ) に対して昇格が必要になった際に RBAC 役割を構築し、管理者を適切な役割グループに追加してアクセス許可を付与する方法があります。この場合、タスクの完了後には役割グループから管理者を削除します。また、次に示す内容を含む、手順やワークフローを開発することもできます。
- 管理者がアクセス許可の昇格を要求する方法。この要求では、要求対象のコマンドレット、対象のサーバーやユーザー、アクセス許可を昇格する期間などを指定する必要があります。
- この要求は、操作の要求時に黙示的に承認を受けることも、または手動での承認を要求することも可能です。
- アクセス許可が昇格された後は、すべての操作のログを記録する必要があります。
- アクセス許可の昇格は、有効期限終了後 (要求時に指定された期間またはアクセス許可昇格の既定の有効期限のいずれかが経過した場合)、またはタスク完了後、必ず取り消します。
Office 365 での対策
Exchange Online には、管理者を偽装したユーザーがデータにアクセスしたり、データを破壊したりすることを防ぐメカニズムが多数実装されています。
先日、Perry Clarke と Vivek Sharma が、「クラウドの内部からの話題: Office 365 内のお客様のデータにアクセス可能な人員」という記事で、常時アクセスを強制的に禁止するロックボックスというメカニズムをご紹介しました。これは、具体的には Exchange Online ユーザーにサービスやサーバーに対する永続的なアクセス許可を付与せず、素性の審査を済ませた管理者が特定のサーバーやコマンドレットなどへのアクセス許可を要求し、指定された時間内で要求されたタスクのみを実行できるというしくみになっています。さらに、顧客データへのアクセスが可能な役割への昇格を要求したときには、他のユーザーによる手動での承認が必要となり、また、この要求を承認できるユーザーは、さらに上位のごくわずかな人員に限定されます。
マイクロソフトでは、サービスのデータおよび顧客データを保護するために、顧客データが格納されているディスク ドライブを Bitlocker で暗号化するなど、他のメカニズムも併用しています。ディスクが寿命を迎えた時は、これを破壊すると、データへのアクセスは確実に不可能になります。
まとめ
この記事では基本的な事項を説明しましたが、メッセージング環境の攻撃範囲を縮小するために実装できるメカニズムは他にも多数存在しています。オンプレミス環境にも適用可能な、Exchange Online を保護するセキュリティ機構についての詳細は、 MEC の「Exchange Online サービスのセキュリティ機能: 各企業でも実施可能な必須項目 (英語)」のセッションを参照してください。
Ross Smith IV
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー