Exchange 2019 のクライアント アクセス規則
クライアント アクセス規則は、Exchange 管理センター (EAC) で Exchange 2019 組織へのアクセスを制御し、クライアントのプロパティまたはクライアント アクセス要求に基づいてリモート PowerShell を制御するのに役立ちます。 クライアント アクセス 規則は、EAC と Exchange 組織へのリモート PowerShell 接続のメール フロー ルール (トランスポート ルールとも呼ばれます) に似ています。 EAC およびリモートの PowerShell クライアントが、IP アドレス (IPv4 と IPv6)、認証の種類、およびユーザー プロパティの値に基づいて Exchange に接続できないようにすることができます。 以下に例を示します。
- リモート PowerShell (Exchange 管理シェルも含む) を使用してクライアント アクセスを禁止します。
- 特定の国または地域のユーザーの EAC へのアクセスをブロックします。
クライアント アクセス規則の手順については、「Exchange Serverのクライアント アクセス規則の手順」を参照してください。
クライアント アクセス規則の構成要素
規則は、条件、例外、アクション、および優先順位の値で構成されます。
条件: アクションを適用するクライアント接続を識別します。 条件の完全な一覧については、後述する「クライアント アクセス規則の条件と例外」セクションを参照してください。 クライアント接続がルールの条件と一致すると、アクションがクライアント接続に適用され、ルールの評価が停止します (これ以上ルールは接続に適用されません)。
例外: アクションが適用されないクライアント接続を識別します (オプション)。 例外は、条件より優先され、接続が構成されたすべての条件を満たしている場合でも、規則のアクションが接続に適用されないようにします。 例外によって許可されたクライアント接続に対する規則の評価は継続されますが、それ以降の規則が接続に影響を与える可能性があります。
アクション: 規則内の条件を満たし、どの例外にも該当しないクライアント接続に対するアクションを指定します。 有効なアクションは次のとおりです。
接続を許可します (
AllowAccessAction パラメーターの値)。接続をブロックします (
DenyAccessAction パラメーターの値)。注:特定のプロトコルの接続をブロックすると、同じプロトコルを使用している他のアプリケーションも影響を受ける可能性があります。
優先順位: クライアント接続に規則を適用する順番を示します (数値が小さいほど、優先順位が高いことを示す)。 既定の優先順位は規則の作成時期に基づき (古い規則の方が新しい規則より優先順位が高い)、優先順位の高い規則が優先順位の低い規則よりも先に処理されます。 クライアント接続が規則内の条件を満たした段階で規則の処理が停止することを覚えておいてください。
規則の優先順位の値の設定の詳細については、「 Exchange 管理シェルを使用してクライアント アクセス 規則の優先順位を設定する」を参照してください。
クライアント アクセス規則の評価方法
同じ条件を含む複数の規則の評価方法と、複数の条件、条件の値、および例外を含む規則の評価方法について、次の表で説明します。
| コンポーネント | ロジック | Comments |
|---|---|---|
| 同じ条件を含む複数の規則 | 最初の規則が適用され、それ以降の規則は無視されます。 | たとえば、最も優先度の高い規則がリモート PowerShell 接続をブロックし、特定の IP アドレス範囲に対してリモート PowerShell 接続を許可する別のルールを作成した場合、すべてのリモート PowerShell 接続は最初の規則によってブロックされます。 リモート PowerShell 用の別の規則を作成する代わりに、指定した IP アドレス範囲からの接続を許可するために、既存のリモート PowerShell 規則に例外を追加する必要があります。 |
| 1 つの規則内の複数の条件 | AND | クライアント接続は、規則内のすべての条件を満たす必要があります。 たとえば、会計部門のユーザーからの EAC 接続などです。 |
| 1 つの規則内に複数の値を持つ 1 つの条件 | OR | 複数の値を許可する条件の場合は、接続が指定された条件のいずれか (すべてではない) を満たす必要があります。 たとえば、EAC 接続やリモート PowerShell 接続などです。 |
| 1 つの規則内の複数の例外 | OR | クライアント接続が例外のいずれかと一致する場合は、アクションがそのクライアント接続に適用されません。 接続は、すべての例外と一致する必要がありません。 たとえば、IP アドレスの 19.2.168.1.1 または基本認証です。 |
特定のクライアント接続がクライアント アクセス規則から受ける影響 (どの規則が一致して接続に影響するか) をテストすることができます。 詳細については、「 Exchange 管理シェルを使用してクライアント アクセス規則をテストする」を参照してください。
重要事項
内部ネットワークからのクライアント接続
ローカル ネットワークからの接続も、クライアント アクセス規則を自動的にバイパスできるわけではありません。 そのため、Exchange へのクライアント接続をブロックするクライアント アクセス規則を作成する場合は、内部ネットワークからの接続がどのように影響を受けるかを考慮する必要があります。 内部クライアント接続にクライアント アクセス規則をバイパスさせるための推奨される方法は、内部ネットワーク (すべてのまたは特定の IP アドレス) からのクライアント接続を許可する最高優先順位規則を作成することです。 これにより、将来作成される他のブロッキング規則に関係なく、クライアント接続は常に許可されます。
クライアント アクセス規則と中間層アプリケーション
Exchange にアクセスする多くのアプリケーションでは、中間層アーキテクチャが使用されます (クライアントは中間層アプリケーションと通信し、中間層アプリケーションは Exchange と通信します)。 ローカル ネットワークからのアクセスのみを許可するクライアント アクセス規則は、中間層アプリケーションをブロックする可能性があります。 そのため、規則では中間層アプリケーションの IP アドレスを許可する必要があります。
Microsoft によって所有される中間層アプリケーション (たとえば、iOS および Android 用の Outlook) は、クライアント アクセス規則によるブロックをバイパスし、常に許可されます。 これらのアプリケーションに対してさらに高度な制御を提供するには、アプリケーションで使用可能な制御機能を使用する必要があります。
規則変更のタイミング
全体的なパフォーマンスを向上させるために、クライアント アクセス 規則ではキャッシュが使用されます。つまり、ルールの変更はすぐには有効になりません。 組織で作成する最初のルールは、有効になるまでに最大 24 時間かかることがあります。 その後、ルールの変更、追加、または削除が有効になるまでに最大 1 時間かかることがあります。
管理
Exchange 管理シェル (リモート PowerShell) のみを使用してクライアント アクセス規則を管理できるため、リモート PowerShell へのアクセスをブロックする規則に注意する必要があります。
ベスト プラクティスは、リモート PowerShell へのアクセスを保持するための、最高の優先度のクライアント アクセス規則を作成することです。 例:
New-ClientAccessRule -Name "Always Allow Remote PowerShell" -Action Allow -AnyOfProtocols RemotePowerShell -Priority 1
認証の種類とプロトコル
すべての認証の種類がすべてのプロトコルでサポートされているわけではありません。 Exchange Serverでプロトコルごとにサポートされる認証の種類については、次の表を参照してください。
| プロトコル | AdfsAuthentication | BasicAuthentication | CertificateBasedAuthentication | NonBasicAuthentication | OAuthAuthentication |
|---|---|---|---|---|---|
ExchangeAdminCenter |
サポートされる | サポートされる | 該当なし | 該当なし | 該当なし |
RemotePowerShell |
該当なし | サポートされる | 該当なし | サポートされる | 該当なし |
クライアント アクセス規則の条件と例外
クライアント アクセス規則内の条件と例外は、規則が適用されるクライアント接続と、規則が適用されないクライアント接続を識別します。 たとえば、規則がリモート PowerShell クライアントによるアクセスをブロックする場合は、特定の IP アドレス範囲からのリモート PowerShell 接続を許可するように規則を構成できます。 構文は条件と対応する例外で同じです。 唯一の違いは、条件は含めるクライアント接続を指定するのに対して、例外は除外するクライアント接続を指定することです。
次の表で、クライアント アクセス規則で使用可能な条件と例外について説明します。
| Exchange 管理シェルの Condition パラメーター | Exchange 管理シェルの例外パラメーター | 説明 |
|---|---|---|
| AnyOfAuthenticationTypes | ExceptAnyOfAuthenticationTypes | Exchange Serverの有効な値は次のとおりです。
複数の値をコンマで区切って指定できます。 引用符は、すべての値を囲むのではなく ("value1,value2" とはしない)、個々の値を囲むように使用できます ("value1"、"value2")。 |
| AnyOfClientIPAddressesOrRanges | ExceptAnyOfClientIPAddressesOrRanges | IPv4 アドレスと IPv6 アドレスがサポートされています。 有効な値は次のとおりです。
複数の値をコンマで区切って指定できます。 IPv6 アドレスと構文の詳細については、Exchange 2013 トピック「 IPv6 アドレスの基本」を参照してください。 |
| AnyOfProtocols | ExceptAnyOfProtocols | Exchange Serverの有効な値は次のとおりです。
複数の値をコンマで区切って指定できます。 個々の値 ("value1","value2") を引用符で囲むことができますが、すべての値を囲むわけではありません ("value1,value2" を使用しないでください)。 注: ルールでこの条件を使用しない場合、ルールは両方のプロトコルに適用されます。 |
| スコープ | 該当なし | 規則を適用する接続の種類を指定します。 有効な値は次のとおりです。
|
| UsernameMatchesAnyOfPatterns | ExceptUsernameMatchesAnyOfPatterns | テキストとワイルドカード文字 (*) を受け入れて、ユーザーのアカウント名を形式 <Domain>\<UserName> で識別します (たとえば、 contoso.com\jeff または *jeff*ではなく jeff*)。 英数字以外の文字にエスケープ文字は必要ありません。 複数の値をコンマで区切って指定できます。 |
| UserRecipientFilter | 該当なし | OPath フィルター構文を使用して、規則を適用するユーザーを識別します。 たとえば、「 "City -eq 'Redmond'" 」のように入力します。 フィルター処理可能な属性は次のとおりです。
検索条件は構文
論理演算子 |