Performance Hub ロゴPerformance Hub
サイトのセクション: ドキュメント

アクセス判定の仕組み

このページの内容

このページでは、すべての解錠の背後にあるモデルを説明します。誰がドアを通れるか、確認がどの順序で実行されるか、Access Policies、付与、安全の確認がどのように関係するかです。最初にこのページをお読みください。他のすべてのページは、ここで説明する概念に基づいています。

加算的な許可の経路

ユーザーは、いずれかのポリシーまたは付与の経路によってドアの通行を許可されます。1 つの経路に合格すれば十分であり、ある経路が別の経路で与えられたアクセス権を差し引くことはありません。

経路内容設定場所
Access Policies名前付きの、許可のみを定義する複数のポリシーです。各ポリシーで Who、Where、When を定義します。Settings → Access Policies
恒久的な付与1 人に対する明示的な権限です。施設全体、選択したドア、または選択した Access Scopes が対象で、任意で独自の時間を設定できます。Users → ユーザーを開く → Access Control → Additional permanent access
Access Time Windows1 人と、選択した施設、ドア、スコープを対象とする、管理者が所有する一時的なアクセス権です。Users → ユーザーを開く → Access Time Windows
連携サービスの Access Time Windows同期した人に対する読み取り専用の連携元の時間枠で、連携元の論理スコープキーからマッピングされます。連携元のデータと Settings → Sync settings のマッピング

ポリシーは、Who かつ Where かつ When が一致した場合にのみ一致します。ポリシー同士は OR で結合されます。Who では、人の種類と状態の条件、およびタグはいずれかを満たせばよく、When では、Weekly と One-time の時間枠はいずれかを満たせばよい条件です。Where には、施設のすべてのドア、Access Scopes、個々のドア、除外を含めることができます。

例："Active members" ポリシーで Front entrances スコープを Anytime で対象にし、別の "Staff" ポリシーで Plant room を除く施設のすべてのドアを対象にできます。どちらにも一致しない清掃スタッフにも、Service entries スコープへの恒久的な付与を与えることができます。

恒久的な付与と、管理者や連携サービスによる時間枠は、別々に加算的に働きます。ポリシーの編集や自動インポートによって、これらが吸収されたり削除されたりすることはありません。

Users に同期された Performance Hub のスタッフは、他のポリシーと同様に、編集可能な Performance Hub staff ポリシーによってドアへのアクセス権を得ます。同期と連携 を参照してください。

判定の全手順

ユーザーがモバイルアプリで アンロック をタップすると、サーバーは次の項目を順番に確認します。最初に不合格になった確認で解錠が拒否され、その理由が アクセスログ に記録されます。

  1. ユーザーのアクセスが有効になっているか？ Users のユーザーの行にある Access enabled スイッチは、管理者用のキルスイッチです。削除、無効化、または同期によってブロックされたユーザーは、ポリシーや付与にかかわらず解錠できません。（例：access_disabled）
  2. ドアがブロックされているか、メンテナンス中か？ 明示的な blockAllAccess は、メンバーのすべての経路を拒否します。メンテナンスの Force closed はドアを施錠したままにし、メンバーには使用停止中とします。強制開放 はドアを解錠したままにします。管理者はドアをリモートで解錠でき、管理者による解錠はすべてアクセスログに記録されます。
  3. 加算的な許可の経路のいずれかに合格するか？
    • ポリシーの経路： Who、Where、When がすべて一致する有効な名前付きポリシーがあれば、アクセスが許可されます。
    • 恒久的な付与の経路： 施設、ドア、またはそのドアを含む Access Scope に対する付与は、任意の時間が一致する場合にアクセスを許可します。
    • ユーザーの時間枠の経路： 管理者が所有する Access Time Window が有効で、このドア、施設、またはこのドアを含む Access Scope を対象にしています。
    • 連携サービスの時間枠の経路： 最新の連携元の時間枠が有効で、設定された scope_key のマッピングがこのドアを対象にしています。古い、またはマッピングされていない連携元の時間枠は、安全側に失敗します。
    • いずれにも合格しない場合 → 拒否されます （no_matching_policy_or_grant）
  4. ジオフェンスの確認（有効な場合）。 スマートフォンが報告する位置を使用します。
    • スマートフォンが位置を提供できなかった場合 → 拒否されます （location_unavailable）
    • GPS の測定値の精度が Require GPS accuracy better than の設定より低い場合 → 拒否されます （gps_too_imprecise）
    • ジオフェンスの中心からユーザーまでの距離が 半径 + GPS の精度 + 精度のバッファー を超える場合 → 拒否されます （outside_geofence）
    • 判定するのはサーバーです。スマートフォンで偽装された位置情報も、サーバー側で拒否されます。
  5. ドアコントローラーがオンラインか？ コントローラーが通信していない場合（過去 5 分以内のハートビート）、解錠の指示を届けることができません （device_offline）。指示は送信されたもののコントローラーが確認しない場合、イベントは Timed out として記録されます。
  6. 解錠。 リレーがドアの Hold time（1～30 秒、デフォルトは 10 秒）の間解放され、その後自動的に再施錠されます。コントローラーが確認すると、イベントは Confirmed unlocked として記録されます。

One-time の時間枠と期間が限定された Weekly の時間枠は、整数の Unix 秒の境界と半開区間 [from, to) を使用します。開始時刻は対象に含まれ、終了時刻は含まれません。Weekly のブロックは、宣言された IANA タイムゾーンと、現地の時刻および夏時間のルールを使用します。Access Policy のスケジュール を参照してください。

将来の時間枠しかないドアについて、新しいクライアントは outside_access_time_window の詳細と、次に利用可能になる時間の構造化された情報を受け取ります。互換性を保つための移行期間中、古いクライアントは引き続き主な理由として outside_access_hours を受け取るため、ドアは安全に無効化された状態で表示され続けます。

既存の設定

既存のアクセス設定は、自動的に Access Policies にインポートされます。インポートでは、誰がアクセスできたか、その人が使用できたドアまたは Access Scopes、適用される時間が、ポリシーの Who、Where、When の値として保持されます。管理者は、作成されたポリシーを直接管理します。展開モードや手動での変換作業はありません。

ジオフェンスの継承は、Access Policies とは独立しています。ポリシーに一致した場合も、実際に適用されるジオフェンスと、その他すべての安全とデバイスの確認を通過する必要があります。

OTP サインインでできること、できないこと

モバイルアプリへのサインイン（SMS またはメールによるワンタイムコード）は 認証のみ を行い、ユーザーが誰であるかを証明します。それ自体でドアへのアクセス権を与えることは ありません。すべての解錠は、上記の判定手順を使って個別に認可されます。ユーザーがアプリにサインインしていても、"You don't have access to this door." と表示される場合があります。

用語集

用語定義
ドアコントローラードアやゲートとペアリングされ、ロックのリレーを作動させるハードウェアデバイスです。このモジュールでは「ドア」として、デバイス管理ではデバイスとして表示されます。
ドア施設に登録されたドアコントローラーで、名前、場所ラベル、アイコン、設定を持ちます。
ユーザーの行Users タブにある、この施設での個人のレコードです。手動、CSV インポート、または同期によって作成されます。連絡先の識別子、種類、状態、タグ、付与、アプリの状態を保持します。
ソースユーザーの行の作成元です：Manually added、External Integration、CCTV/Computer Vision、Performance Hub staff。
Access PolicyWho、Where、When を含む、名前付きの許可のみを定義するポリシーです。3 つすべてが一致する必要があり、ポリシー同士は OR で結合されます。
人の種類の条件人の種類と任意の会員状態を含む、ポリシーの Who の条件です。状態が空の場合は、どの状態でも一致します。
タグユーザーに付けるラベルです。同期したタグ は連携サービスから取得され、同期のたびに上書きされます。カスタムタグ は管理者が所有し、上書きされることはありません。どちらもポリシーの Who の条件を満たすことができます。
営業時間 / 時間ブロック曜日ごとの時間枠（例：月 06:00～22:00）で、ポリシーや付与がアクセスを許可する時間を制限します。空の場合は常に許可されます。時刻は施設のタイムゾーンを使用します。
Access Time Windowポリシーのスケジュールで、または管理者や連携サービスによる別の付与の経路で使用される、Weekly または One-time の期間です。
ユーザーごとの付与1 人のユーザーに与える明示的なアクセス権です。施設全体（すべてのドア）、特定の ドア、または特定の Access Scopes が対象で、任意で独自の営業時間を設定できます。
アクセス範囲名前付きのドアのまとまり（例："Main entrances"、"Staff-only"）で、ポリシーや付与の対象として、またスコープ単位のジオフェンス設定に使用されます。内部的には door group とも呼ばれます。
ポリシーの除外1 つのポリシーの Where の一致から除かれたドアまたは Access Scope です。他のポリシーや付与の経路を拒否するものではありません。
ジオフェンス施設の周囲の円（中心 + 半径）です。有効にすると、解錠するにはユーザーが実際にその内側にいる必要があります（GPS の精度とバッファーを考慮します）。
精度のバッファー通常の GPS の誤差を許容するために、ジオフェンスの半径に加算する追加のメートル数です。デフォルトは 25 m です。
メンテナンスモードドアを通常の運用から外す、ドアごとの設定です：Normal、強制開放（解錠したまま）、Force closed（施錠したまま、メンバーには使用停止中）。
Block all accessメンテナンスモードを使わずに、そのドアでのポリシーとユーザーごとの付与よりも優先される、ドアごとの安全のためのブロックです。管理者による解錠は引き続き使用できます。
保持時間解錠後、再施錠されるまでリレーが解放されている時間です。範囲は 1～30 秒、デフォルトは 10 秒です。
自動解錠スケジュール施設のスタッフ常駐時間中、またはカスタムスケジュールの間、ドアを解錠したままにするドアごとのスケジュールです。Access Policies とは独立しています。
今すぐ施錠自動解錠スケジュールによって開いているドアを、スケジュールが次に切り替わるまで施錠します。Resume schedule で元に戻します。
Access enabledユーザーごとのキルスイッチです。オフにすると、そのユーザーは何も解錠できません。
切り離しTrack source updates スイッチがオフになっている同期したユーザーです。同期処理はその行をスキップするため、管理者による編集が保持されます。
招待モバイルアプリをダウンロードするためのリンクをユーザーに送信するメールです。ユーザーごとに追跡されます（Not invited / Invited / Send failed）。
OTP サインインモバイルアプリのパスワードなしのログインです。ユーザーの電話またはメールにワンタイムコードが送信されます。
管理者による上書き / 管理者による解錠管理者が Performance Hub から実行する解錠です（ドアタブ → Open、またはドアパネルの Unlock door）。管理者による解錠はすべて、その管理者のアカウントでアクセスログに記録されます。
アプリロックアプリを使用する前に、施設が必須にするデバイスでの再認証（Face ID / Touch ID / Android の生体認証 / パスコード）です。
アプリのメッセージアプリのダッシュボードに表示されるお知らせカードです。施設全体、ユーザーごと、または App Messaging のルールによって自動的に設定されるものがあります。
アクセスイベントアクセスログの 1 件のレコードで、解錠の試行とその結果です。