カメラのセットアップ
ベストプラクティス
ユーザーガイド
一般的なオーバーview
各 Verkada カメラは、次の目的で、安全な双方向通信チャネルを介して Verkada クラウドに自動的に接続するように設計されています。
- アップロードするtage、アーカイブ、スクリーンショット、サムネイル、および特定のイベント基準に関するアラート (カメラのオフライン/オンライン、注目人物、モーション、tampええと、群衆）、
- コマンドからファームウェアをダウンロードし、設定を更新します (光学ズームやセキュリティ強化など)。
デフォルトでは、Verkada カメラはオンプレミスのサードパーティに接続しません
NVR を使用したり、安全でないプロトコル (HTTP や RTSP など) を使用したりします。 もし必要なら、
foo のストリーミング用に RTSP を有効にできますtage を既存のインフラストラクチャまたはサード パーティの分析アプリケーションに統合し、SIEM との統合を Verkada クラウド経由でセットアップできます (3 ページを参照)。
インストールとセットアップ
カメラの電源と接続
Verkada カメラは、LAN 経由の電力と通信に Power over Ethernet (PoE) を利用します。 ほとんどの場合、カメラは 802.3af PoE 規格をサポートするアクセス スイッチに直接接続します。 寒い気候で屋外の Verkada カメラを使用していて、内蔵ヒーターが必要な場合は、より高出力の 802.3at PoE+ 標準をサポートする PoE インジェクターまたはスイッチが必要です。 スイッチポートはアクセス ポートとして設定する必要があり、すべてのカメラは全二重でネゴシエートします (すべてのモデル
10/100/80 を持つ D81 と CF10 を除いて、100/1000Mbps NIC があります)。
ヒント
スイッチの PoE バジェットを超えていないことを常に確認してください。 そうである場合、カメラの電源が入らないか、オレンジ色の LED ライトが点灯したままになります。
イーサネット スイッチで PoE を使用できない場合は、追加の PoE インジェクターを注文して、カメラとスイッチの間に挿入することをお勧めします。
同軸ケーブルを使用する既存の展開では、イーサネットでケーブルを再接続することは現実的ではない可能性があります。その場合、以下に詳述するようにコンバーターを使用することをお勧めします。
https://help.verkada.com/en/articles/3152569-powering-a-verkada-camera-over-coax
次のリンクでは、いくつかの特定の使用例について詳しく説明しています。
LTE での動作:
https://help.verkada.com/en/articles/3062805-using-a-verkada-cameraon-a-cradlepoint-connection
ワイヤレス ブリッジの使用:
https://help.verkada.com/en/articles/3168378-connecting-a-verkadacamera-via-a-wireless-bridge-point-to-point-connection
光ファイバーをバックホールとして使用する:
https://help.verkada.com/en/articles/3558954-using-verkada-over-fiber
INJ–PoE–Plus インジェクタ:
https://cdn.verkada.com/image/upload/v1641842491/docs/PoE-injectordatasheet.pdf
PoE のしくみ:
https://cdn.verkada.com/image/upload/v1641842491/docs/PoE-injectoroverview.pdf
IP アドレッシングとサブネット化
カメラの電源がオンになると、DHCP を使用してローカル IP アドレスを要求します。 現在、静的アドレス指定はサポートされていません。これは、カメラに直接接続してセットアップする必要があり、セキュリティ上の理由から許可されていない動作です。 固定 IP アドレスが必要な場合は、DHCP 予約を使用して DHCP サーバーでこれを行うことができます。これは、予約された IP アドレスをカメラの MAC アドレスと照合するプロセスです。 Verkada は、要求に応じてセールス オーダーから MAC アドレスのリストを提供できます。
ヒント
カメラを独自の VLAN で分離し、ACL を使用して VLAN 間通信を無効にすることを強くお勧めします。 これにより、セキュリティ レイヤーが追加され、同じブロードキャスト ドメインを共有するデバイスが多すぎる場合に発生するパフォーマンスの問題が軽減されます。 ローカル ストリーミングをサポートするには、双方向の TCP 4100 を許可するように ACL を構成する必要があります (詳細については、ローカル ストリーミング/オフライン モードのセクションを参照してください)。 VLAN を使用すると、QoS の観点からトラフィックを適切にマークして、バルク トラフィックを優先して優先順位を付けることができます (推奨されるマーキング: DSCP 40、CS5 – ブロードキャスト ビデオ)。
カメラは既存の 802.1x RADIUS インフラストラクチャで動作し、ユーザー名とパスワードではなく MAC アドレスを使用する MAC ベースの認証を設定することをお勧めします。 すべての Verkada カメラは、E0:A7:00 で始まる固有の MAC OUI (Organizationally Unique Identifier) で始まります。 完全な MAC アドレスは viewマウントが取り外されたときに Verkada カメラの下部と [デバイス] ページを見てください。
ファイアウォール設定
Verkada カメラはネットワーク内から Verkada クラウドへの通信を開始するため、ポート転送を設定する必要はありません。 さらに、クラウドが VMS として機能しているため、クライアント VPN を使用して LAN に接続する必要はありません。 viewふーんtagリモートで。 ただし、LAN とインターネット間のファイアウォールは、HTTPS (TCP ポート 443) および NTP (UDP ポート 123) を介した通信を許可する必要があります。 HTTPS または NTP のいずれかがブロックされている場合、カメラは正しく起動しません。 これは、カメラの LED ライトがオレンジ色に点灯するか、青色に点滅することで示されます。
ヒント
ポートが開いているかどうかを確認する最も簡単な方法は、ファイアウォールがサード パーティによって管理されている場合に特に便利で、ラップトップをスイッチポートに接続することです。
- 任意の HTTPS に移動 webサイト (Google など)
- 「time.control.verkada.com」への NTP を確認します (以下を参照)。
ベスト プラクティスとして、すべての TCP 443 および UDP 123 トラフィックを許可するのではなく、使用する Verkada ドメインをホワイトリストに登録する特定のルールを設定することをお勧めします。 包括的なリストは、次の場所にあります。 https://help.verkada.com/en/articles/4132169-required-network-settings
以下に、予想される VLAN 分離とトラフィック フローの概要を示します。
ポート 443 経由の HTTPS
- TLS 1.2 経由で転送中に暗号化されたすべてのトラフィック
- 通信先: *.control.verkada.com
UDP ポート 123 経由の NTP
- 通信先: *time.control.verkada.com
Verkada Cloud ストア:
- ユーザー名とパスワード情報
- 設定データ
Verkada クラウド ハンドル:
- ユーザー認証
- クライアント接続の仲介
ストリーミング時の帯域幅使用率:
- 1～3Mbps
ストリーミングしていないときの帯域幅使用率:
- 20～50Kbps
すべての Verkada カメラは AWS PKI を使用して、Verkada クラウドとのみ通信するようにしているため、Verkada トラフィックを検査するときは SSL 復号化をオフにする必要があります。 有効にしようとすると、通信が切断されます。 元ampレスベロー：
ゼットスケーラー:
https://help.verkada.com/en/articles/4316383-using-zscaler-with-verkada
パロアルト：
https://help.verkada.com/en/articles/4048220-verkada-cameras-with-ssldecryption
帯域幅に関する考慮事項
Verkada システムは少量の帯域幅しか使用しませんが (通常、静止時は 20 ～ 50 kbps)、次のことをお勧めします。view カメラがすでにオーバーサブスクライブされた環境に展開されるシナリオを回避するために、ISP リンクの現在の使用率。 これにより、リモート ストリーミングが正常に動作しない、カメラがファームウェアをダウンロードして適切な動作を維持する際に問題が発生するなど、さまざまな問題が発生する可能性があります。
ファイアウォール設定セクションで説明されているように、カメラは Verkada クラウドにルーティングして到達できる必要があり、DIA (ダイレクト インターネット アクセス) を使用しているか、リモートのメイン サイトから集中型ブレイクアウトを使用しているかに関係なく機能することに注意してください ( MPLS を使用して接続します)。 サイトに直接のインターネット リンクと MPLS の両方がある場合は、前者を優先し、後者をバックアップとして使用するようにルーティング ポリシーを設定することをお勧めします (インターネット ブレイクアウトが可能な場合)。
カメラの帯域幅要件を計算しようとするときは、次のことを考慮する必要があります。
- 静止時に消費される帯域幅 (誰もいないとき) viewふーんtage); これは 20 ～ 50 kbps の間である傾向があり、高度な分析 (顔検索、人物/車両特性検索) をオンにすると、特に多くのアクティビティがあるシーンでは 100 kbps 以上になる可能性があります。
- foo 時に必要な帯域幅tageは viewエド; これは、SD で約 600 kbps、HD で 1.5 Mbps、2K で 3 ～ 4 Mbps です。
考慮すべきいくつかの重要事項:
- 複数のユーザーがライブ フィードをリモートで視聴する場合、AWS がビデオを多重化するため、XNUMX つのストリームのみが生成されます。
- 過去のビデオを視聴する場合、使用される帯域幅は再生速度に比例して増加します (再生速度が 2 倍になると、ストリーム帯域幅が 2 倍になります)。
- クラウド バックアップ帯域幅は、常時アップロード用に設定されている場合、通常のストリーム帯域幅と同じです。
帯域幅を節約するためのヒント (必要な場合):
- 使用しない場合は、高度な分析を無効にします (カメラは引き続き人や車両を識別しますが、Person of Interest や、衣服や車両の色による検索は利用できません)。
- Cloud Backup スケジュールを使用して foo をアップロードしますtage 営業時間外 (クラウド バックアップが必要な場合)。
- ローカル ストリーミングを有効にして、カメラがローカル デバイスに直接ストリーミングできるようにします。
- デフォルトのすべてのストリーム view[管理者] タブの [カメラ] セクションから画質を SD に変更します (ユーザーは必要に応じて HD に変更できます)。
ローカル ストリーミング/オフライン モード
カメラのライブ ストリームにアクセスすると、アクセスするデバイスは LAN 経由のストリーミングを優先します。 カメラのプライベート IP アドレスがコンピューターから到達可能であり、適切なドメインがネットワークで許可されている場合、コンピューターはカメラとの HTTPS 接続を確立して、ライブ フィードを直接取得します。 これは、カメラが同じ場所に戻るためだけにデータを AWS にアップロードする必要がないことを意味します。 これにより、ISP の帯域幅が過度に使用されず、遅延が最小限に抑えられます。
ローカル ストリーミングの要件:
- アクセスするデバイスは、カメラのプライベート IP に到達できる必要があります。
- TCP ポート 4100 は、クライアントとカメラの間で双方向に開いている必要があります。
- クライアントとカメラの間にプロキシはありません。
- 次の場所で見つかったドメインをホワイトリストに登録します。 https://help.verkada.com/en/articles/3712294-local-stream-onverkada-cameras
ヒント
カメラは、アクセスするためにデバイスと同じ VLAN にある必要はありませんが、VLAN 間のルーティングが可能である必要があります。
カメラ フィードの左下に「SD – LOCAL」、「HD – LOCAL」、または「4K – LOCAL」という言葉、または緑色の点が表示されている場合は、ライブ ビデオをカメラから直接ストリーミングしているかどうかを判断できます。 timest の横に白い枠線が表示されますamp. ストリームに「SD」、「HD」、または「4K」しか表示されない場合、ビデオは Verkada Cloud 経由で中継されています。
ライブ ストリームがサーバー経由で中継される場合でも、カメラから直接送信される場合でも、暗号化された TLS 接続を使用することでセキュリティが同等に維持されることに注意してください。 以下の図を参照して、企業デバイスとカメラの間でトラフィックがどのように直接流れるかを確認してください。
ポート 443 経由の HTTPS
- TLS 1.2 経由で転送中に暗号化されたすべてのトラフィック
- 通信先: *.control.verkada.com
UDP ポート 123 経由の NTP - 通信先: *time.control.verkada.com
TCP ポート 4100 経由のローカル ストリーミング (オプション) Verkada Cloud ストア:
- ユーザー名とパスワード情報
- 設定データ
Verkada クラウド ハンドル:
- ユーザー認証
- クライアント接続の仲介
ストリーミング時の帯域幅使用率:
- 1～3Mbps
ストリーミングしていないときの帯域幅使用率:
- 20～50Kbps
オフラインモード ローカル ストリーミングの上に構築され、インターネット ou の場合でもライブ ビデオを継続できます。tagエス。 デバイスが ou の前にコマンドにすでに正常にログインしている場合に機能します。tage が発生し、適切な証明書がインストールされています (そして信頼されています)。 これらの証明書をダウンロードしてプロビジョニングする方法を示すガイドは、次の場所にあります。 https://help.verkada.com/en/articles/2937989-offline-mode-in-command
ヒント
特定の場所でオフライン モードを使用する場合は、ISP リンクを一時的に切断してテストすることをお勧めします。 これは、変更管理手順に従って、勤務時間外に行う必要があります。 成功すると、Command にバナーが表示され、オフライン モードであることを通知し、live foo にしかアクセスできなくなります。tagエンドデバイスからまだ到達可能なカメラから e。
オフライン モードを使用する場合は、DHCP サーバーを介して静的 IP アドレスを割り当てることをお勧めします。 viewing デバイスは、それが変更されたことを学習できません。
時刻同期
Verkada は独自のサーバーを使用して、UDP 123 経由でカメラの時刻を同期します。現在、独自の NTP サーバーを使用することはできません。 特定のカメラのタイム ゾーン設定を変更する場合は、そのアドレスを変更する必要があります (これは、任意のカメラの [情報] タブから行うことができます)。
ファームウェアの更新
すべての Verkada ファームウェア更新は、無線 (OTA) で配信されます。 ファームウェアの更新を容易にするために管理者が必要とする操作はありません。 押すと、各カメラは動作を継続しながら新しいファームウェアをダウンロードし、適用するためにしばらく再起動します。 フェールセーフ アップデートを確実にするために、各 Verkada カメラにはデュアルパーティション ファームウェア バンクが装備されています。 ファームウェアの更新が失敗するという異常なイベントでは、カメラは自動的に以前のバージョンのファームウェアにフェールオーバーします。 さらに、特定の場所にあるカメラがすべて同時に再起動しないようにするために、ランダム変数がプロセスに導入されます。
ヒント
[デバイス] タブに移動してクリックし、[ファームウェア] セクションを調べて、カメラが最新かどうかを確認できます。
システム アラートの設定
各コマンド管理者は、次のようなさまざまな種類のアラートをサブスクライブできます。
- カメラの状態: カメラがオフラインになるか、オンラインに戻ります。
- Tampえー： 誰かがネジを外そうとしたり、カメラに接触したりした場合に備えて、オンボードの加速度計によってトリガーされます。
- モーション： 24 時間 7 日または特定の時間 (スケジュールを介して) のいずれかで、一般的な動き、またはフレームの特定の領域内の人および/または車両について警告するように構成できます。
- 要注意人物: 特定の個人がプロの後、組織内のカメラで発見されたときfile [人物] タブでフラグが立てられます。
- 群衆： 特定の時間に特定の数を超える個人がフレーム内に発見された場合。
Verkada クラウドにアラートをプッシュするようにカメラに指示するには、まずカメラごとにモーション通知と群衆通知を構成する必要があることに注意してください。 これが設定されていない場合、それらのカメラはアラートを提供しません。 各カメラはステータスとtを通知しますampデフォルトで送信されるので、アラートにサブスクライブするだけです。
現在、システムは SMS と電子メールを使用してアラートを提供しています。 さらに、Verkada モバイル アプリが Android/iOS デバイスにインストールされている場合、Verkada は通知もネイティブに送信します (ログインしていること、および OS が通知をブロックしていないことを確認してください)。 セットアップの詳細については、次を参照してください。
https://help.verkada.com/en/articles/3822777-notifications-page
発券/アラートにサードパーティのシステムを使用している場合は、一般的な電子メール アドレスを使用して電子メールを送信するか、API を利用して web以下に概説するように、フック機能：
https://www.verkada.com/uk/integrations/
ヒント
アカウントに使用する電子メールと電話番号が確認されていることを確認してください。確認されていない場合、アラートは受信されません。 これを行うには、画面の左上にある自分の名前の横にあるドロップダウン矢印をクリックします。
コマンド、Pro をクリックします。file タブを開き、メールアドレスと電話番号の横に「確認済み」と表示されていることを確認します。 カメラ ステータス アラートについては、必ずしもカメラが機能していないことを示すものではなく、クラウドとの通信が長時間中断されたことを示すものではないことに注意してください。 これは、ISP ou などによってトリガーされる可能性があります。tages、誤って構成されたファイアウォール ルール、またはルーティングの問題さえあります。 カメラの電源が入っている場合は、記録を継続し、関連情報と foo をオフロードします。tage 接続が再確立されたら。 カメラ、そのケーブル、または接続先のスイッチ ポートに障害が発生したことをすぐに通知したい場合は、スイッチで SNMP トラップを構成してください (またはベンダーが提供するその他のアラーム メカニズム)。
ユーザーID
コマンドから、管理者は組織にアクセスできるユーザーを簡単に管理できます。 以下に、ベスト プラクティスと考慮事項の概要を示します。
組織は最新かつ安全です。
ID セキュリティへの堅牢なアプローチは、Command プラットフォームへのアクセスを管理するための不可欠なコンポーネントです。 Verkada Command へのユーザー アクセスを管理するには、主に XNUMX つのアプローチを検討してください。
- Command プラットフォームにネイティブな機能を採用。
- Azure AD や Okta などの外部 ID プロバイダーを利用する。
外部 ID プロバイダーは、組織に ID セキュリティへの徹底的なアプローチを提供する目的で構築されています。 そのため、外部 ID プロバイダーを使用して、それらが提供する一連の制御を活用することをお勧めします。
ID セキュリティの制御
大まかに言うと、Command で ID セキュリティを管理するために使用できるいくつかの異なるノブがあります。ユーザーがプラットフォームにアクセスする方法、ユーザーがプラットフォームに追加される方法、および
多要素認証。 これらの各コントロールについて、コマンド ネイティブのアプローチと外部 ID プロバイダーのアプローチを対比します。
アカウントアクセス
Verkada Command 内のネイティブ ユーザーは、プラットフォームへのアクセスに使用する専用のユーザー アカウント (ユーザー名とパスワード) を持っています。 アカウント作成時、以下
パスワードの複雑さの要件が存在します。
- 8文字以上
- 少なくとも XNUMX つの特殊文字
作成されたネイティブ ユーザー アカウントは期限切れになりません。 その結果、ユーザーがパスワード管理に関する既存の組織のガイドラインに従うようにすることをお勧めします。一般にシングル サインオン (SSO) と呼ばれるアカウント アクセスに外部 ID プロバイダーを使用すると、多くの利点が得られます。 SSO ソリューションの主な利点は、単一のアカウントを使用して、ID プロバイダーがサポートする任意のサービスにログインできることです。 例えばampつまり、同じアカウントを使用して Office 365 とその電子メールにアクセスできます。
XNUMX つのユーザー名とパスワードを覚えるだけでよいため、パスワードの再利用やパスワード疲労の可能性が減少します。 SSO は、パスワードの長さ、有効期限、複雑さをきめ細かく制御することもできるため、これらのパラメーターを組織のポリシーに合わせることができます。 さらに、Verkada Command を使用すると、組織は選択したドメインで SSO のみのログインを強制できるため、ネイティブ ユーザー アカウントは使用できません。
Verkada Command は、多くの SSO プロバイダー、特に SAML 2.0 をサポートする SSO プロバイダーと統合されています。 プロバイダーのリストは、Verkada の統合ページで、指定子 SSO で見つけることができます。 https://www.verkada.com/integrations/. さらに、サポートされているプロバイダーを介して Command 組織の SSO をセットアップする方法に関するドキュメントを提供します。 https://help.verkada.com/en/collections/2452528-verkadacommand#saml-sso.
ユーザープロビジョニング
Verkada Command 組織内では、ネイティブ ユーザーはユーザー セクション (管理者 → ユーザー → ユーザーの追加) で作成されます。 前に説明したように、ネイティブ ユーザーは期限切れにならないため、アカウントのプロビジョニングを解除する必要がある場合は、手動で削除する必要があります。
SCIM をサポートする外部 ID プロバイダーは、より堅牢なソリューションを提供します。ユーザーは、ユーザーがアクセスできるすべてのサービスに対して、ID プロバイダーを介して自動的にプロビジョニング/プロビジョニング解除できます。 Verkada Command では、これは、外部で管理されているユーザーが、プロビジョニングされると Command 内で自動的に作成され、プロビジョニングが解除されると Command から自動的に削除されることを意味します。 同様に、ユーザー グループも同じメカニズムで管理できます。
どちらの場合でも、Verkada Command 内のユーザーの定期的な監査を強くお勧めします。 誰がアクセス権を持っていて、誰がアクセスする必要がなくなったか (つまり、組織を去るユーザー) を認識し、そのアクセス権を取り消すことが重要です。 プロビジョニング/プロビジョニング解除が容易で、複数のサービス間で一貫性があるため、可能な場合は SCIM 統合を強くお勧めします。 このアプローチにより、ユーザーが長時間アクセスして削除されない可能性が大幅に減少します。 サポートされているプロバイダーのリストは、Verkada の統合ページで、指定子 SCIM で見つけることができます。 https://www.verkada.com/integrations/.
2要素認証
多要素認証 (MFA) は、ユーザーが物理的に所有するオブジェクトなど、セキュリティの他の「要素」を要求することにより、ユーザー名/パスワードを超えた追加のログイン セキュリティを提供します。 2 要素認証 (XNUMXFA) は通常、ユーザーがユーザー名/パスワードを入力し (第 XNUMX 要素)、ログインを完了するためにユーザーのモバイル デバイスからのコードを要求すること (第 XNUMX 要素) を指します。
Verkada コマンドにアクセスするすべてのユーザー アカウントには、XNUMX 要素認証を強くお勧めします。
二要素認証は、次の手順で Command でネイティブに有効にすることができます。
- コマンドの左上に移動し、組織の名前をクリックします。
- [アカウント] セクションで [アカウント設定] を選択します。
- XNUMX 要素認証の [有効にする] をクリックします。
- アカウントのパスワードを再入力し、手順に従って構成を完了します。
Command は、モバイル デバイス用の SMS テキスト アプリと認証アプリの両方をサポートしています。 PCI コンプライアンスの理由で 2FA を追加する場合は、最新の標準を確認してください。モバイル認証アプリが望ましいオプションになる可能性があります。
組織管理者は、組織内のすべてのユーザーに 2FA を適用することもできます。 2FA が必要な場合、ユーザーは招待を受け入れる過程で 2FA を設定します。 組織が設定された後に有効化された場合、すべてのユーザーはログイン フロー中に設定するように求められます。
さらに、SSO プロバイダーを通じて管理されるすべてのアカウントに 2FA を適用できます。 例えばampつまり、Azure AD では、すべてのログインに MFA を適用できる条件付きアクセス ポリシーを作成できます。
外部 ID プロバイダーからの高度な制御
上記の標準機能以外にも、多くの外部 ID プロバイダーが、より詳細なアクセス ポリシーを可能にする高度な機能を提供しています。 これらの高度な機能には、多くの場合、IP アドレスに基づくログイン場所の制限、ユーザーを特定のデバイスに制限すること、堅牢なパスワード要件を適用することが含まれます。 より一般的な高度な機能の一部に関するドキュメントを提供しています。 https://help.verkada.com/en/articles/3858814-advanced-identity-security.
追加の質問？
Verkadaの営業担当者または電子メールでお問い合わせください support@verkada.com.
ベルカダについて
Verkada は、消費者向けセキュリティ ソリューションが提供する使いやすさを、企業や組織が必要とする規模と保護のレベルにもたらします。
直感的なクラウドベースのソフトウェア プラットフォーム上にハイエンド ハードウェアを構築することにより、現代の企業は、より安全でスマートな建物をすべての場所で運用できます。
| アメリカ本社 405 E4thアベニュー San Mateo、CA 94401、USA ローカル: +1 650-514-2500 フリーダイヤル: 888-829-0668 一般的な： sales@verkada.com |
英国本社 91-93 グレート イースタン ストリート スイート 3、 ハックニー、ロンドン EC2A 3HZ、英国 ローカル：+44（20）3048-6050 フリーダイヤル: 0808-196-2600 一般的な： sales@verkada.com |
Verkada Inc. 405 E 4th Ave、San Mateo、CA、94401
sales@verkada.com
ドキュメント / リソース
 |
Verkada カメラ設定のベスト プラクティス [pdf] ユーザーガイド カメラ セットアップのベスト プラクティス, セットアップのベスト プラクティス, カメラのベスト プラクティス, ベスト プラクティス, プラクティス |
