Keeperコネクションマネージャー

リモートブラウザ分離

HTTP/HTTPSでのリモートブラウザ分離接続タイプの構成

この機能は、KCMバージョン2.19.0で公開済みです。

概要

HTTP/HTTPS (リモートブラウザ分離) 接続タイプを使用すると、レンダリングされた隔離ブラウザを通してウェブベースのアプリケーションに安全にアクセスできるようになります。ウェブサイトのコードやDOMがユーザーのデバイス上で実行されるわけではないため、ユーザーはさまざまな攻撃ベクトルに対して免疫を獲得します。ウェブブラウザセッションがローカル環境で実行されないため大きなセキュリティ上の利点があり、ローカルデバイスへの攻撃からアセットを守ることが可能となります。

VPN、ZTNAなど暫定的なネットワークソリューションの必要性を排除

Keeperコネクションマネージャーコンテナーを任意のターゲット環境に公開するだけで、ウェブベースのリソースへのアクセスを制限、監視、制御できます。

ゼロ知識アーキテクチャ

お客様は、ユーザーのデバイスと対象の Web サイトおよびアプリケーション間のすべてのネットワーク通信を完全に制御できます。Chromium エンジンを搭載した Keeper リモート ブラウザー分離は、機密データやセンシティブなデータを送信することなく、Keeper 接続マネージャー コンテナーからユーザーのデバイスを介して最新バージョンの Chromium ブラウザーの仮想インスタンスを投影します。

セッションの録画

他の Keeperコネクションマネージャープロトコルと同様に、コンプライアンスとセキュリティ上の理由から、ブラウザー分離セッションを共有、記録、監視できます。

ログイン情報の自動入力

Keeperのリモートブラウザ分離プロトコルにより、ログイン情報をユーザーのデバイスに送信することなくログイン情報の自動入力、フォームの送信し、対象のウェブアプリケーションの制御が可能となります。

パラメータ

HTTP/HTTPSプロトコル対応は数個のパラメータの使用を介してコントロールします。MySQLやPostgreSQLのようなデータベースを使用する際には、これらのパラメータは便利なウェブインターフェースで表示されます。暗号化されたJSONやLDAPスキーマの変更など、別の方法で接続を定義する場合は、内部パラメータ名を使用してパラメータを指定します。

このページでは、サポートされているすべてのパラメータを網羅することを目的としており、パラメータはウェブインターフェース内と同じようにグループ化されています。各パラメータについて、ウェブインターフェースに表示されるフィールドヘッダ、パラメータの内部名、動作と取りうる値に関する詳細な情報をまとめました。

Keeperシークレットマネージャー用パラメータ

この設定により、資格情報の自動入力のためにKeeperシークレットマネージャーアプリケーションを統合できます。

フィールドヘッダパラメータ名説明

Allow user-provided KSM configuration: (ユーザー提供のKSM構成を許可)

ksm-user-config-enabled

設定が「true」の場合、どの接続に対しても各KeeperコネクションマネージャーユーザープロファイルをKeeperシークレットマネージャー構成に割り当てられます。詳細については、「複数のボルト連携」ページをご参照ください。

ブラウザ設定用パラメータ

HTTP/HTTPS接続はレンダリングされたChromiumブラウザを通じて確立されます。一般的に、各接続は特定のウェブアプリケーションに関連付けられていますが、広範なウェブブラウジングも許可するように構成することもできます。

デフォルトでは、新規のリモートブラウザ分離セッションはローカルストレージがクリアされた状態の「シークレットウィンドウ」と同等です。これにより、データの保持せずに複数のユーザーが同時にリモートブラウザ分離セッションを実行できます。

「Browser Profile Storage Directory」 (ブラウザプロファイルストレージディレクトリ) 値を指定すると、ブラウザセッションデータがKCM guacamoleコンテナ内に保持されます。例えば、以下のように構築されたパスを使用すると、ユーザーごとにブラウザセッションが保持されます:

/var/lib/guacamole/rbi-profiles/some-website-${GUAC_USERNAME}

注: 複数のセッションで同じブラウザプロファイルストレージディレクトリを同時に使用することはできません。

フィールドヘッダパラメータ名説明

Allow navigation via direct URL manipulation (直接のURL操作でのナビゲーションを許可)

allow-url-manipulation

ユーザーが通常のブラウザで行うように、現在のURLを編集したり、前後にナビゲートしたりすることを許可するかどうかを設定します。チェックを入れる (trueに設定) と、ユーザーが接続を開く際にナビゲーションバーが表示されます。 デフォルトでは、ユーザーは現在のURLを手動で編集できず、現在のページとのインタラクションのみが可能となります。

URL

url

ユーザーが接続したときに最初にロードされるページのURL。

Allowed URL Patterns (許可されたURLのパターン)

allowed-url-patterns

手動ナビゲーション (URL バー) 経由か現在のページとのiインタラクションかに関係なく、ユーザーがアクセスできるすべてのURLのパターン。改行することで複数のパターンを指定できます。指定した場合、リスト内のパターンに一致するページのみが許可されます。 デフォルトでは、すべてのURLが許可されています。

Allowed Resource URL Patterns (許可されたリソースURLのパターン)

allowed-resource-url-patterns

画像、スクリプト、スタイルシート、フォントなど、ページがリソースとして読み込むことが許可されるすべての URL のパターン。改行することで複数のパターンを指定できます。指定した場合、リスト内のパターンに一致するリソースのみがロードされます。 デフォルトでは、ページによってロードされるリソースには制限がありません。

Browser Profile Storage Directory (ブラウザプロファイルストレージディレクトリ)

profile-storage-directory

ブラウザのセッションデータが保持されるGuacamoleコンテナ内の場所。

Automatically Create Profile Directory (自動的にプロファイルディレクトリを作成)

create-profile-directory

値は「false」 (デフォルト)、「true」、「recursive」となります。

URLのパターン

「Allowed URL Patterns」 (許可されたURLのパターン) と「Allowed Resource URL Patterns」 (許可されたリソースURLのパターン) の各パラメータが受け入れるURLパターンの形式はURLと同一で、どのURLが許可されるかを正確に指定します。パラメータは以下の基準に従って適用されます。

  • URLパターンから省略されたURL要素は無視されます (要件として適用されません)。ただし、標準ポート番号は、スキームが指定されている場合に指定されたものと見なされます。

  • ドメイン名には、「特定ドメインの任意のサブドメイン」を示すためのワイルドカード接頭辞 (*.) が使用できます。

  • パスの代わりにワイルドカード (*) を使用することで、どの値も許可されていることをより明示的に示すことができます。

  • ワイルドカード (*) をパスの末尾に使用することで、そのパスのサブパスがどれも許可されていることを示すことができます。

  • ワイルドカード (*) をポート番号の代わりに使用することで、どのポートも許可されていることを示すことができます。

以下は例となります。

パターン

意味

accounts.google.com

あらゆるプロトコルとパスを含むドメイン accounts.google.comへのリクエストを許可します。リクエストは、関係するプロトコルに関係なく、標準ポートに対して行う必要があります。

*.youtube.com

あらゆるプロトコルとパスを含む youtube.comのあらゆるサブドメインへのリクエストを許可します。リクエストは、関係するプロトコルに関係なく、標準ポートに対して行う必要があります。

http://10.10.10.10:8080

厳密にHTTP (HTTPS ではない) と任意のパスを使用して、ポート 8080の10.10.10.10へのリクエストを許可します。

10.10.10.10:*

任意のプロトコルと任意のパスを使用して、任意のポートで10.10.10.10へのリクエストを許可します。

https://example.net/foo

厳密にHTTPS (HTTP ではない) とパス「/foo」を使用したexample.netへのリクエストを許可します。リクエストはHTTPSの標準ポートに対して行う必要があります。

https://example.net/foo/*

厳密にHTTPS (HTTP ではない) と「/foo」の下の任意のパスを使用したexample.netへのリクエストを許可します。リクエストは HTTPS の標準ポートに対して行う必要があります。

google.com

google.comルートドメインからのあらゆるプロトコルまたはパスが許可されますが、サブドメインは許可されません。

ブラウザ自動入力用パラメータ

Keeperコネクションマネージャーには、ユーザー名とパスワードを対象のウェブサイトのログイン画面に自動入力する機能が備わっています。ユーザーインターフェースで直接ユーザー名とパスワードを入力するか、Keeperボルト (保管庫) 内の記録への参照を使用します。

シークレット自動入力構成

Keeperコネクションマネージャーで使用される自動入力ルールは、JSON/YAML形式のオブジェクトの配列であり、各オブジェクトで少なくとも以下のプロパティを指定します。

  • page - 自動入力ルールが適用されるページのURLパターンです。ここで利用できるパターンは、ナビゲーション/リソースルールで受け入れられるパターンと同一となります。

加えて以下のプロパティのどれか、または両方を指定します。

  • username-field - 自動入力するユーザー名が入るフィールドを一致させるCSSセレクタです。接続のusernameパラメーターの値が入力されます。

  • password-field - 自動入力するパスワードが入るフィールドを一致させるCSSセレクタです。接続のpasswordパラメーターの値が入力されます。

  • submit - 該当するすべてのユーザー名/パスワードフィールドが入力された後、クリックを必要とする要素向けのCSS セレクタです。ログインページで適切なHTML <form> タグが使用されていない場合など、必要な場合にのみ指定します。省略すると、ユーザーが「Enter」を押したかのようにログインフォームを送信しようとします。

以下は、ログインとユーザー名とパスワードの各フィールドがある単一ページのウェブアプリケーションの例となります。

- page: "http://172.31.8.134:8080/login"
  username-field: "input[name='j_username']"
  password-field: "input[name='j_password']"

Microsoft Azure Portalのログインフローなど、一部のログインフローでは複数のルールが必要になる場合があります。

以下は、Microsoft Azureに必要な自動入力ルールのYAMLの例です。

- page: "login.microsoftonline.com"
  username-field: "input[autocomplete='username']"

- page: "login.live.com"
  password-field: "input[autocomplete='current-password']"

以下はJSON形式での例です。

[
    {
        "page": "login.microsoftonline.com",
        "username-field": "input[autocomplete='username']"
    },
    {
        "page": "login.live.com",
        "password-field": "input[autocomplete='current-password']"
    }
]

Keeperによる自動送信を望まない場合の一般的な例としては、ページにキャプチャがある際が挙げられます。以下はその例となります。

- page: "https://dash.cloudflare.com/login"
  username-field: "input[id='email']"
  password-field: "input[id='password']"
  cannot-submit: "div[data-testid=challenge-widget-container]"

CSSでは不十分な、非常に複雑なページでは、代わりにXPath式を使用できます。このような XPath式は、先頭に / を付けて作成します。

フィールドの識別

リモートブラウザ分離は、JSONまたはYAMLコードで定義された特定のフィールド要素に基づいて認証情報を入力します。フォームフィールドセレクタは、ページのコンテンツを調べて特定のフィールド要素を特定することで発見できます。

  1. ページを検証: ウェブページを右クリックして[検証]を選択してデベロッパーツールを開きます。

  2. フィールドを選択: 要素セレクター ツールを使用して、識別するフォームフィールドをクリックします。

  3. 属性を読み取る: 強調表示されたHTMLコードを見て、autocomplete、type、name、idなどの識別子の属性を見つけます。

例 1: autocompleteを使用

  • HTMLコード: <input type="password" autocomplete="current-password" ...>

  • 説明: パスワードフィールドは、autocomplete属性をcurrent-passwordに設定することで識別できます。

例 2: typeを使用

  • HTML コード: <input type="password" ...>

  • 説明: パスワードフィールドは、type属性をpasswordに設定することで識別できます。

例 3: nameを使用

  • HTML コード: <input type="password" name="some_name_xyz" ...>

  • 説明: パスワードフィールドは、name属性をsome_name_xyzに設定することで識別できます。

例 4: idを使用

  • HTMLコード: <input type="password" id="some_id_1234" ...>

  • 説明: パスワードフィールドは、id属性をsome_id_1234に設定することで識別できます。

フィールド識別のテスト

Chrome ブラウザからデベロッパーツールを開き、[コンソール]タブに移動します。

フォームフィールドの識別をテストするには、document.querySelector() javascriptコマンドを使用します。

たとえば、以下を入力して「Enter」キーを押します。

document.querySelector("input[type='password']")

フィールドが見つかった場合は、DOM要素が表示されます。見つからない場合は、エラーが表示されます。

Keeperシークレットマネージャーとの統合

Keeperシークレットマネージャーとの統合機能を使用すると、ユーザー名とパスワード情報をKeepeボルト (保管庫) から直接取得することもできます。たとえば、Keeperボルトからユーザー名とパスワードを使用してJenkinsにログインする際には、「Hostname」というカスタムフィールドに基づいて検索を行います。

以下は、Keeperボルトの記録の形式となります。

オーディオ設定用パラメータ

フィールドヘッダ　 (ウェブインターフェース)

パラメータ名

デフォルト値

説明

Disable Audio (オーディオを無効にする)

disable-audio

false

チェックされている場合 (trueに設定されている場合)、リモートブラウザ分離セッション内でオーディオが転送されません。ページはオーディオを再生しますが、オーディオは無視されます。

Channels (チャンネル)

audio-channels

2

KCMを介して送信されるオーディオデータに使用されるオーディオチャンネルの数。有効な値は、 1（センターチャンネルのみのモノラルオーディオ、一般的には「モノ」と呼ばれる) と2 (左右のチャンネルを持つステレオオーディオ、一般的には「ステレオ」と呼ばれる)。

Bit Depth (ビット深度)

audio-bps

16

有効な値は、8 (8ビットオーディオ、比較的低品質) と16 (16ビットオーディオ、標準的な品質レベル)

Sample Rate (サンプルレート)

audio-sample-rate

44100

KCMを介して送信されるオーディオデータのサンプルレート (Hz単位)。

自己署名またはカスタムCA証明書

対象のウェブアプリケーションで自己署名またはカスタムCA証明書が使用されている場合は、Docker ComposeでCA_CERTIFICATES環境変数を設定して証明書を許可します。例については、guacdパラメータのページをご参照ください。

ブラウザ分離に関するよくある質問

リモートブラウザ分離機能はKeeperコネクションマネージャー専用ですか?

はい、リモートブラウザ分離はKeeperコネクションマネージャーのアドオンとなります。

Keeperコネクションマネージャーの一部であるということは、リモートブラウザ分離機能は一般ユーザーを対象としていないということですか?

いいえ、リモートブラウザ分離機能はさまざまな使用例が考慮されています。エンドユーザーは、VPNやZTNA製品を必要とせずに、社内のウェブベースアプリケーションにアクセスできるようになります。リモートブラウザ分離はデバイス上のローカル エージェントも必要としません。

リモートブラウザ分離機能はLinux 専用ですか?

いいえ、リモートブラウザ分離機能はWindows、Mac、Linux、Android、iOSで動作します。

リモートブラウザ分離機能はDockerコンテナでのみ動作しますか、あるいはKubernetesでも​​動作しますか?

KeeperコネクションマネージャーはDockerコンテナとしてデプロイされ、Kubernetesデプロイメントでのランタイムとして使用できます。

RDP (リモートデスクトッププロトコル) は1つの画面に制限されていますか?

Keeperコネクションマネージャーは複数の画面にまたがって拡張でき、ユーザーが各モニターで個別のウィンドウを使用したい場合は、KCMを開いた状態で追加のブラウザを使用できます。

リモートブラウザ分離機能はCentrifyなどのPAMソリューションで動作しますか?

はい、ユーザーはリモートブラウザ分離機能を介して任意のウェブアプリケーションやウェブサイトにログインして、安全にセッションを実行、録画できます。

ローカルデバイスからブラウザコネクションにコピーアンドペーストできますか?

はい、管理者によって無効にされていない限り可能です。一部ブラウザではクリップボード統合がサポートされていない場合があります。

リモートブラウザ分離機能により、米国外のリモートチームメンバーがVPNを使う必要性がなくなりますか?

はい、Keeperコネクションマネージャーのリモートブラウザ分離機能により、VPNを使用して内部ウェブアプリケーションや特定のクラウドベースのアプリケーションにアクセスする必要がなくなります。

コネクションマネージャーからスキャナなどのローカルUSBデバイスにアクセスできますか?

現在はアクセスできません。この機能については検討中です。

リモートブラウザ分離機能により、フィッシングや悪意のあるウェブサイトからローカルデバイスに何かを挿入するのを防止できますか?

はい、すべてのアクティビティはリモートブラウザ分離サンドボックス内で行われるため、フィッシングや悪意のある行為者がローカルデバイスを攻撃するのを防止できます。

プロキシ経由でトラフィックをルーティングすることは可能ですか?

リモートブラウザ分離セッションでは、KeeperコネクションマネージャーコンテナをホストしているマシンがDNSを照会し、対象のウェブサイトやアプリケーションにウェブリクエストを送信できることが要件となります。Keeperコネクションマネージャーインスタンスからターゲットにアクセスできない場合は、サポートチームにお問い合わせの上構成をご確認ください。

録画は通常どのくらいのストレージを占有しますか? また、録画に関連するストレージに対してコストは発生しますか?

録画はKeeperコネクションマネージャーコンテナに保存されるため、Keeper側からのコストは発生しません。録画のサイズはUI操作の長さと量によって異なります。

リモートブラウザ分離機能はローカルマシンへのダウンロードにどのような影響を与えますか?

現時点ではファイルのダウンロードとアップロードはブロックされています。Keeperコネクションマネージャーの今後のアップデートで、ファイルのアップロードとファイルのダウンロードの両方を制御する機能が接続設定で利用できるようになる予定です。

リモートブラウザ分離機能はCyber​​Arkの代替品になり得ますか?

はい、KeeperPAM (特権アクセスマネージャー) ではパスワードとパスキーの管理、シークレットの管理、接続の管理が可能となり、特権アクセスの管理に完全なゼロトラストアプローチをご利用になれます。KeeperとCyber​​Arkなどの競合他社製品との比較に関しては、こちらのページをご覧ください。

リモートブラウザ分離機能はFIPS認定を受けているため、CUIにアクセスできますか?

Keeperでは、厳格な政府および公共部門のセキュリティ要件に対応するために、FIPS 140-2検証済みの暗号化モジュールを使用しています。 Keeperの暗号化技術は、NIST暗号化モジュール検証プログラム (CMVP) によって認定されており、認定されたサードパーティの研究機関によってFIPS 140 標準を満たすことが検証されています。Keeperへは、NIST CMVPから証明書#3976が発行されています。Keeper のセキュリティ、暗号化、コンプライアンスの詳細については、こちらのページをご覧ください。

Previous接続プロトコルNextVNC

Last updated