サブドメインの高度な認証
サブドメインの高度な認証は、ログインを必須にする が有効な HTTP / HTTPS サービス用 Host に、条件付きの許可ルールを追加する機能です。リクエストが初めてルールに一致すると、そのリクエストは 1 回限り許可され、Cookie に対応するクライアントには短時間有効な機能確認用 Probe が返されます。後続リクエストが Probe を返したときにだけ、現在の Host 用の永続的な一時アクセス許可が作成されます。一致しない場合は、通常どおりログイン、セッション、サービススコープに基づいて処理されます。
一時アクセス許可はシステムへのログインではありません。ログインセッションや IP 許可は作成されず、ポータルも表示されず、他の Host にはアクセスできません。高度な認証は独立した許可経路であり、既存のログインルールにもう 1 段階の検証を追加する機能ではありません。
利用条件
- マッピングが通常のサービス用 Host であり、認証サービスではない。
- Target が HTTP または HTTPS を使用している。
- マッピングで
ログインを必須にするが有効になっている。 - 送信元 IP または地域をルールに使う場合、ゲートウェイが実クライアント IP を識別できる。
サブドメインマッピング の一覧で、サービス用 Host の右側にあるメニューを開き、高度な認証 を選びます。認証用 Host、認証なしのマッピング、TCP / UDP マッピングには、この項目は表示されません。
一時アクセス許可の範囲
Cookie に対応するクライアントが Probe を完了して永続的な一時アクセス許可を取得すると、有効期間内に現在の Host の別のパスや HTTP メソッドへアクセスしても、元の条件を毎回満たす必要はありません。このため、パス、Header、Query の条件を、リクエストごとに継続して適用されるアクセス制御として使うことはできません。
Cookie を返さないアプリ、スクリプト、その他のクライアントでは永続状態を作成しません。各リクエストは毎回ルールに一致する必要があり、そのリクエストだけが許可されます。WebSocket Upgrade も現在のハンドシェイクだけを許可します。101 Switching Protocols では Cookie を確実に配布できないため、再接続時にルールを再評価します。リクエストログの 1 回限りのリクエスト許可 がこの状態を示します。
たとえば、/health だけに一致するルールを作っても、永続的な一時アクセス許可が /health だけに限定されるわけではありません。ブラウザーが Probe を完了した後は、一時アクセス許可の有効期間中、現在の Host 全体へのアクセスが許可されます。少数の固定パスだけを公開したい場合は、パス別応答を使う、独立した Host に分ける、またはアップストリームアプリでも権限チェックを続ける方法を選んでください。
共通ブラックリスト、WAF、従来の厳格な許可リストなど、保護を目的とした拒否ルールは引き続き優先されます。高度な認証でこれらのセキュリティ境界を迂回することはできません。
有効期間の設定
| 設定 | デフォルト値 | 設定可能範囲 | 動作 |
|---|---|---|---|
アクセスがない場合の失効時間 | 24 時間 | 5 分～30 日 | 有効なアクセスのたびに無アクセス時間を再計算 |
アクセス許可の最長有効期間 | 30 日 | 5 分～365 日 | 最初の発行時点から計算し、継続的にアクセスしても延長しない |
この 2 つの期間は、Cookie Probe の後に作成された永続的な一時アクセス許可だけに適用されます。1 回限りの許可は次のリクエストへ引き継がれません。最長有効期間を、無アクセス時の失効時間より短くすることはできません。ルール、有効期間、有効状態のいずれかを変更して保存すると、システムがポリシーバージョンを更新し、既存の一時アクセス許可は直ちに失効します。高度な認証を無効にしてもルールの下書きは残るため、後から再度有効にできます。
ルールグループの構成
ルールは「グループ間が OR、グループ内が AND」で評価されます。
ルールグループ 1：条件 A AND 条件 B
OR
ルールグループ 2：条件 C AND 条件 Dいずれか 1 つのルールグループの全条件に一致すると、一時アクセス許可が発行されます。各 Host には最大 16 個のルールグループを設定でき、各グループには最大 16 個の条件を追加できます。有効にするには、空でないルールグループが少なくとも 1 つ必要です。
次のような範囲の広いルールは、保存時に再確認を求められます。
- グループ内の全条件が「等しくない」「含まれない」などの否定条件である。
- HTTP メソッドだけで許可する。
- パスルールがルートパス
/を対象に含む。 - 送信元ネットワークに
0.0.0.0/0または::/0が含まれる。
再確認はルールの対象が広いことを示すだけで、設定の安全性を保証するものではありません。保存後は、条件に一致する外部ネットワークと一致しない外部ネットワークの両方から、直ちに検証してください。
規模と発行レート制限
1 つの Host のルールには、次の上限もあります。
| 項目 | 上限 |
|---|---|
| 各条件の照合値または地域選択 | 256 件 |
| 全条件の照合値の合計 | 4096 件 |
| 正規表現の合計 | 256 個 |
| 1 つの正規表現 | 512 バイト |
| 地域条件とネットワーク条件から解決された CIDR の合計 | 100000 件 |
| 高度な認証の設定リクエスト | 8 MiB |
永続的な一時アクセス許可は、クライアントが有効な Probe を返し、再利用できる許可がない場合にだけ作成されます。同じ Host、同じクライアント IP では 60 秒あたり最大 10 件、1 つの Host 全体では 60 秒あたり最大 1000 件まで作成でき、1 つの Host が保持できる有効な許可は最大 100000 件です。作成頻度や容量の上限に達した場合、または永続ストレージが一時的に利用できない場合でも、ルールに一致した現在のリクエストは拒否されず 1 回限りのリクエスト許可 へフォールバックします。次のリクエストは再度ルールに一致する必要があります。共有プロキシの出口では複数のクライアントが同じ送信元として数えられるため、前段にプロキシがある構成では、先に実クライアント IP が正しく識別されていることを確認してください。
照合対象
| 対象 | 使用できる演算子 | 設定の要点 |
|---|---|---|
| 送信元 IP | 等しい、等しくない、CIDR に含まれる、CIDR に含まれない | IPv4 と IPv6 に対応。1 行に 1 つのアドレスまたはネットワークを入力 |
| 送信元地域 | 地域に含まれる、地域に含まれない | 都道府県、市区、全域、通信事業者の範囲を選択し、保存時に固定 CIDR へ解決 |
| URL パス | 等しい、等しくない、パスプレフィックス、プレフィックスでない、含む、含まない、RE2 正規表現、RE2 正規表現でない | ドメインを除くリクエストパスを照合 |
| リクエストヘッダー | 存在する、存在しない、等しい、等しくない、含む、で始まる、で終わる、および各否定条件、RE2 正規表現 | 一般的な名前から選ぶか、カスタム Header を直接入力。値はデフォルトで大文字と小文字を区別 |
| クエリパラメータ | 存在する、存在しない、等しい、等しくない、含む、で始まる、で終わる、および各否定条件、RE2 正規表現 | パラメータ名と値は設定バックアップに含まれる |
| HTTP メソッド | 指定メソッドのいずれか、指定メソッド以外 | GET、HEAD など、1 行に 1 つのメソッドを入力 |
条件に複数の照合値を入力できる場合、肯定条件はいずれか 1 つに一致すれば成立します。否定条件では、リクエスト値が設定したすべての値に一致しないことが必要です。たとえば 等しくない に 2 つの値を指定した場合、「どちらか一方と異なれば許可」ではなく、両方と異なる必要があります。
地域範囲は保存時に展開され、CIDR として固定されます。その後 CIDR データソースが変わっても、保存済みルールの範囲は自動的に拡大または縮小しません。設定を開き直して保存したときに、現在の地域データを使って再コンパイルされます。
Header 名には、Host、Cookie、Authorization、X-Forwarded-*、X-Real-IP、X-Reauth-* など、認証情報、転送、クライアント IP に関係するヘッダーを使用できません。前段にプロキシがある場合は、外部クライアントが偽装できる Header をプロキシ側で削除または上書きしてください。
Header、Query、パスの照合内容は、設定とバックアップに平文で保存されます。ただし、システムがこれらの設定値を高度な認証の診断情報としてログ、メトリクス、エラー詳細へ書き込むことはありません。リクエストログに記録されるのは、一致したルールグループ ID と一時アクセス許可の状態だけで、設定値は表示されません。長期間使える重要な秘密情報を Query に直接含めないでください。エクスポートしたバックアップも機密ファイルとして保管してください。
ルールの例
信頼できる社内ネットワーク上の管理対象端末から nas.example.com へ直接アクセスさせる場合は、同じルールグループに次の条件を設定できます。
送信元 IP → CIDR に含まれる → 203.0.113.0/24リクエストヘッダー → 等しい → X-Device-ID → 端末識別子
両方の条件を満たした場合にだけ、現在の Host の一時アクセス許可が発行されます。Header 自体はクライアントが作成できるため、信頼できる送信元ネットワークと組み合わせずに、単独で強力な本人確認手段として使うことはできません。アップストリームサービスでも、引き続き独自の権限管理を行ってください。
検証とトラブルシューティング
- 実際の外部ネットワークから、ルールに一致するリクエストを送信します。
リクエストログで、認証結果がサブドメインルールで許可になっていることを確認します。サブドメインルールグループ IDが想定したグループであり、一時アクセス許可の状態が1 回限りのリクエスト許可、発行済み、更新済み、再利用のいずれかになっていることを確認します。ブラウザーの初回リクエストは通常 1 回限りの許可となり、Probe Cookie を返した後に発行済みへ変わります。- 次に、条件に一致しない送信元からテストし、通常のログインフローへ戻ることを確認します。
- Cookie を保存しないクライアントから 2 回続けてリクエストし、毎回ルールが再評価されて 1 回限りの許可になることを確認します。その後ブラウザーで、Probe が永続的な許可へ変わることを確認します。
- ルールを変更して保存し、以前のブラウザーにある一時アクセス許可が直ちに失効することを確認します。
送信元 IP または地域ルールが想定どおり動作しない場合は、まずログのクライアント IP と接続元 IP を確認します。ルールを保存できない場合は、条件値、CIDR のアドレスファミリー、RE2 正規表現、地域データソース、ゲートウェイのバージョンが一致しているか確認してください。