タグ「Keeper Enterprise」の検索結果が42件
タグ：Keeper Enterprise タグ条件を解除
Keeper / ユーザー・組織・権限管理
masaruyokoi 更新
Keeper Enterpriseではユーザの組織部門を区別するために、ノード構造を採用しております。ノードの間での記録や共有フォルダーの共有を制限するために、分離ノードの機能があります。分離ノードを設定すると他のノードのユーザやチームに共有ができなくなります。 分離ノードからの共有先 分離ノードの機能を説明するために、上図のようなノード構成となったKeeperのEntepriseがあるとします。ここの「分離ノード（C)」に分離ノードを設定した場合、各ノードのユーザからどこまで共有を設定できるのかをご説明します。 「分離ノード(C)」とその子ノードは、親ノードである「Rootノード(A)」と「分離ノード(C)」と子ノードに共有できます。分離ノードではない「通常ノード(B)」とその子ノードのユーザは、すべてのノードに共有できます。これらの関係を図にすると、下記のようになります。共有するユーザが所在するノード共有先ABB1B2CC1C2Rootノード(A)○○○○○○○通常ノード(B)○○○○○○○子ノード(B1)○○○○○○○子ノード(B2)○○○○○○○分離ノード(C)○×××○○○子ノード(C1)○×××○○○子ノード(C2)○×××○○○分離ノード内に作ったチームには、分離ノード外のユーザをチームメンバーとして登録できます。(分離ノード外のユーザをチームメンバーが含まれる)分離ノード内のチームに共有フォルダを共有設定した場合、その分離ノード外のユーザにも共有フォルダと中身のレコード(記録)は共有されます。抜け道的な使い方ですが、分離ノード外のユーザに共有する方法は存在します。 分離ノードの設定方法分離ノードの設定では2段階あります。1つは共有先として表示させない状態で、もう1つは分離ノード外に共有自体を拒否する設定の2種類です。 共有先として表示させない分離Keeper Commander 分離ノードを設定した場合、分離されたノードのユーザは、レコード(記録)や共有フォルダの共有先に、兄弟ノードのユーザやチームを共有先として選択できなくなります。分離ノードを設定する場合には、Keeper Commander (CLI) にて、下記のコマンドを実行してください。 # 分離するノードのIDをしらべるために enterprise-info (ei) を実行
enterprise-info -n
# 上記結果から分離するノードのIDを探して、enterprise-node コマンドで分離を設定
enterprise-node --toggle-isolated (分離するノードのID)分離の設定を行うと、管理画面のノード選択で、分離ノードを示すアイコンが表示されるようになります。 分離ノード外への共有を拒否する設定先ほどの設定では分離ノード外のユーザやチームが共有候補に出てこない設定でした。次に設定するのが共有そのものの操作を拒否する設定です。分離ノード外への共有を拒否するには、先ほどのKeeper Commander (CLI)での enterprise-node --toggle-isolated コマンドを行った後に、ロールの強制適用ポリシーの、「作成と共有の権限設定」にある「分離ノード外の共有」をOffにしてください。分離ノード外への共有を拒否する設定は、ロールでの設定となります。ロールはユーザやチームに割り当てできるので、分離ノード内のユーザごとで拒否される・されない の違いを作ることも可能です。
Keeper / ユーザー・組織・権限管理
hanae 更新
Keeper では、ユーザーを招待する際に送付するメールをカスタマイズすることが可能です。その設定方法を説明します。 事前準備設定する前に、ドメインの予約を実施する必要があります。ドメインの予約方法は、SCIM プロビジョニングにドメイン予約の申請が必要になりました (2025年4月8日〜) の対応内容をご確認ください。 注意点ドメイン予約で申請したドメイン以外のメールアドレスで招待した場合は、カスタマイズした招待メールは届きません。gmail.com などのフリーアカウントへの招待メールも無効です。 招待メールの設定管理コンソールにログインし、左のメニューバーの「カスタムブランディング」を選択します。招待メールの編集を選択すると、招待メールの編集画面が表示されます。以下のように設定し、最後に「保存」を押してください。カスタム招待メールを送信: 有効(ON)件名: ご自由にご記入ください。メールの件名になります。メッセージの見出し: ご自由にご記入ください。メール本文の見出し(一番上に太字で記載される)になります。メッセージ: ご自由にご記入ください。メール本文になります。アカウント設定ボタン:ご自由にご記入ください。このボタンを押すと、アカウントを作成する画面へ移動します。 ユーザーには、実際にこのようにメールが届きます。 以上です。
Keeper / ユーザー・組織・権限管理
hanae 更新
会社のドメイン変更等で、Keeper を利用しているアカウントのメールアドレスを変更する方法を紹介します。なお、こちらの方法は、以下のプランのお客様向けのご案内となります。Keeper BusinessKeeper Business PlusKeeper Base Plan User Licenses※Keeper へのログインが、SAML ログインの場合や、管理者が一括でユーザーのメールアドレスを変更にする場合は Keeper Enterpriseでのインターネットドメイン変更の方法 の記事を参照ください。 注意点こちらで紹介する方法は、ユーザ自らメールアドレスを変更する方法になります。管理者が、メールアドレスの変更を強制できるわけではございません。また、ユーザーによるアドレスの変更履歴については、レポート等をご確認ください。管理者は、強制適用ポリシーにて、ユーザーによるメールアドレスの変更を許可(有効)する必要があります。この機能は通常、無効にすることを推奨しております。メールアドレスの変更が終了したら、速やかに無効に変更してください。変更後のメールアドレスで、既に Keeper のアカウントが存在する(無料トライアルを過去に実施していた場合も該当します)場合は、メールアドレスの変更ができません。変更後のメールアドレスの送受信が可能である必要があります。 メールアドレスの変更方法Keeper のボルトにログインします。右上の自身のアイコン > 設定マーク > 全般 > メールアドレスの変更へ進みます。 現在利用のマスターパスワードと、変更後のメールアドレスを入力し、保存をクリックしてください。※このとき、変更後のメールアドレスでは、メールを受信できるようにしてください。 変更後のメールアドレスに、メールが届きます。「メールアドレスの変更を承認する」をクリックします。 メールアドレスの変更に成功すると、「成功」と記載された画面に遷移します。なお、過去に作成したことのあるアカウント等の場合、エラーとなります。 作業は以上です。 アドレス変更後のログインについてメールアドレス変更後、Keeper へのログインを実施し、メールアドレス変更前に保有していたレコードやフォルダが存在しているか確認してください。また、デスクトップ版やモバイル版の Keeper を利用していた場合、変更前のアカウントを選択すると「アカウントリセットしてください」をポップアップが表示されます。※キャプチャ参照そのユーザーアカウントを削除し、変更後のメールアドレスのアカウントでログインを実施してください。
Keeper / 重要な変更・障害のお知らせ
shao 更新
※こちらの情報は、Keeper社からの情報に基づき、随時更新されております。2025年4月8日以降、Keeper 管理コンソールで SCIM (System for Cross-Domain Identity Management) を用いたユーザープロビジョニングを設定されている場合に「ドメイン予約」の申請が必要になりました。ドメインの予約が行われていない場合、IdPからのプロビジョニング実施時に以下のエラーメッセージを返してユーザーの作成に失敗します: Use a different email domainこの仕様変更は、同日以前から SCIM 設定を引き続きご利用の場合でも影響します。後述のドメイン予約のチケットを送信したことがないお客様は、下記の手順に沿って申請手続 (チケットの送信) を実施してください。 対応内容契約形態により、対応方法がことなります。契約形態の確認は Keeper managed by ZUNDA と Keeper (カスタムプラン) の違いは何ですか？ をご確認ください。Keeper managed by ZUNDA (MSP)の場合ドメインの予約希望であることを、以下のURLより申請してください。https://help.zunda.co.jp/hc/ja/requests/new入力は、次のようにお願いいたします。以下の中から該当する問題を選択してください:技術サポート件名:Keeper ドメイン予約の依頼カテゴリ:オンラインサービス製品:Keeper トピック:設定変更のリクエスト本文:Keeper のドメイン予約の申請を希望します。ドメイン: [貴社ドメイン]初期管理者アドレス: [Keeper の初期管理者のメールアドレスを記入。初期管理者が不明の場合は、Keeper Administrator 権限をお持ちのユーザーのメールアドレス] Keeper カスタムプランの場合Keeper ビジネスサポートポータル (keepersecurity.servicenowservices.com) にログインし、ドメイン予約に関するサポートチケットを送信してください。サポートチケットの発行は、servicenow のアカウントの作成は不要です。また、ドメイン予約を依頼したユーザーが、初期管理者(Keeper のテナントを発行した際に、最初にログインしたユーザー)ではない場合、verification code が求められる可能性があります。 チケットの作成Keeper ビジネスサポートポータル (keepersecurity.servicenowservices.com) にログインし、「登録ボタン」をクリックしてください。既に servicenow のアカウントをお持ちの場合は、ログインしてチケットを新規作成してください。 チケットの内容名・姓・メールアドレス・会社名など必要事項を入力します。それ以降の入力内容は、以下のサンプルをもとに記載してください。Please select an issue type:[Technical Issues with Keeper] を選択してください件名「Domain Reservation Request」とお書きくださいHow many users are affected?貴社で Keeper をご利用いただいている、およその人数をご記入ください。(正確でなくても構いません)What Keeper platform and operating system?:「Admin Console」とお書きください。Description of the issue:次のようにお書きください。 Can you please reserve the domain [example.com] for the account associated with the e-mail address [admin@example.com]?[example.com] は SCIM で同期するユーザーのメールドメイン (通常はメールアドレス)に置き換えます[admin@example.com] は貴社テナントの管理者 (Keeper Administrator ロールをもつユーザー) のメールアドレスに置き換えますYou accept Keeper's Terms of Useチェックを入れます。 上記の内容を記載後、画面右上にあります「送信」をクリックしてください。 参考情報過去に、Keeper 社のサポートチームへ直接ご連絡、もしくは弊社経由でドメイン予約に関するご連絡(申請)をいただいている場合は、既に登録済みですので上記対応は不要です。なお、誤ってドメイン予約の申請を重複して実施した場合でも特段問題ございません。※2025年4月15日17時現在、過去にドメイン予約を実施したお客様であっても、改めてドメイン予約の申請が必要なケースが散見されております。この変更は、Keeper 社のBackend API Version 17.4における変更点(KA-6239)に基づくものです。詳細につきましては、Keeper 社リリースノート (docs.keeper.io) をご参照ください。
Keeper / 契約・ライセンス・サポート
hanae 更新
Keeper をご契約いただいている皆様にお送りする各書類(更新見積書・納品書・請求書)と、Keeper の管理コンソールに表示されているライセンス数が異なる理由について説明します。 Keeper 管理コンソールに表示されるユーザー数は、Keeper を利用しているユーザー数です。 これは、必ずしもご契約いただいているライセンス数と一致するものではございません。正確なご契約ライセンス数につきましては、大変お手数をおかけいたしますが、過去にお送りいたしましたお見積書、納品書、ご請求書をご確認いただくか、弊社までお問い合わせくださいますようお願い申し上げます。なお、課金対象となるユーザーのステータスについて をご確認ください。
Keeper / ユーザー・組織・権限管理
hanae 更新
管理者権限の設定方法を紹介します。管理機能管理者ロールは、右下の「管理権限」タブをクリックします。設定マークから付与したい権限を選択します。割り当て可能な権限については、下段をご確認ください。割り当て可能な管理機能管理者に割り当てることのできる機能はこちらをご確認ください。管理項目内容ノード管理ノードを追加、削除、編集する権限ユーザー管理ユーザーを追加、削除、編集する権限ロール管理ロールを追加、削除、編集する権限チーム管理チームへメンバーを追加、削除、追加する権限レポートとアラートレポートとアラートの作成、削除、編集する権限※対象プラン: Business Plus、Enterprise Plusブリッジ／SSOを管理Enterprise Bridge または SSO を追加、削除、環境設定する権限デバイス承認を実行SSO クラウドユーザーの場合、デバイスを承認する権限ボルト内の記録タイプを管理カスタムされた記録タイプの作成、編集、削除を行う管理者権限の権限ボルト内のレコートタイプを管理記録タイプの作成、編集、削除を行う権限共有管理Share Admin をご確認ください。コンプライアンスレポートの実行コンプライアンスレポート機能の作成、編集、削除を行う権限※対象: コンプライアンスレポートを追加オーダーしている場合アカウント移管ユーザーのボルトを移転する機能（ユーザーのロールがこれを許可するように設定されている場合。 ※ロールのメンバーである管理者のみが、「アカウント移転」をチェックできます※権限を下位ノードに適用とは、作成した管理権限を下位のノードにまで適用させたい場合にチェックをいれます。※管理権限ロールは、チームに割り当てることはできません。
Keeper / ユーザー・組織・権限管理
hanae 更新
ロールの割り当て方について、ユーザーロール、管理者ロールそれぞれ紹介します。 ユーザーロールの割り当て該当のユーザーロールを選択し、右下の「ユーザー」「チーム」タブをクリックし、実際に割り当てたいユーザーもしくはチームにチェックを入れて追加します。また、デフォルトロールにする場合は「ノードとサブノードのデフォルトロールとして設定」にチェックを入れてください。チェックを入れると、ユーザー作成されたタイミングで自動で割り当てられます。ユーザーの追加 チームの追加 管理者ロールの割り当て該当のロールを選択し、右下の「管理者権限」タブをクリックし、対象となるノードを追加し、設定マークから付与したい権限を選択してください管理権限ロールは、チームに割り当てることはできません
Keeper / ユーザー・組織・権限管理
hanae 更新
必ず以下の3つの特徴をおさえたうえで、ロールの作成を行なってください。ユーザーロールと管理者ロールが存在Keeper のロールは、ユーザーにポリシーを割り当てるためのロール(ユーザーロール)、管理者権限を付与するためのロール(管理者ロール)が存在します。ユーザーロールは、全ユーザーに割り当てる「デフォルトロール」と、限られたユーザーにのみ割り当てる「ロール」が存在します。管理者ロールは、初期管理者に「Keeper Administrator」が付与されます。限られた管理権限だけ(代理管理ロール)をユーザーに割り当てることも可能です。ロールの種類機能ユーザーロールデフォルトロール全ユーザーに、Keeper 利用時の基本機能やセキュリティを割り当てるロール。初めからルートノード(親ノード)に「All User」というロールが存在します。このロールの強制適用ポリシーを設定します。ロールデフォルトロールとは別に、限られたユーザーにのみ割り当てたいポリシーがある場合は設定します。例)業務委託従業員はマスタードパスワードログインにしたい、共有を不可としたい等管理者ロールKeeper AdministratorKeeper テナントを管理する(ノード・ロールの作成、ユーザー作成など)管理権限です。初めからルートノードに「Keeper Administrator」というロールが存在します。代理管理ロールKeeper Administrator とは別で、特定の権限(ユーザー作成のみなど)に絞って、管理権限を付与したい場合に作成します。 設定できる強制適用ポリシーの種類が豊富ロールで設定できる強制適用ポリシーの種類が豊富です。弊社ではログイン方式別に推奨設定一覧をご案内しています。詳細はこちらを参照してください。💡 ログイン方法別 ロール推奨設定 https://docs.google.com/spreadsheets/d/155UovWRcInDskza5FAMzKhug7LpjWeZZZyJXZb9nj44/edit#gid=2003596019※こちらはあくまでも弊社の推奨設定のため、社内のセキュリティポリシーにあわせて設定を実施してください。詳細: ロール、RBAC、およびユーザーへの許可 ポリシーが傾く方向性についてKeeper が元々提供しているデフォルトのロール設定から変更した部分がある場合は、該当項目については変更後のポリシーが適用。ポリシーはより制限が厳しい方が優先される。デフォルトのロール設定から設定を変更しており、その変更が異なる方向を向いている場合は、どちらの設定が適用されるか保証されない。異なる方向性のロールが付与されている場合については、異なるロールが付与されている場合の設定項目の優先度について を確認してください。これらのロールの特徴を踏まえた上、ロールの作成 に進んでください。
Keeper / ユーザー・組織・権限管理
hanae 更新
ノードとはKeeper へのログイン方式の違い(SSO, マスターパスワード)など、大きなセキュリティレベルでユーザーを個別のグループに分類する方法の一つです。ビルのようなアイコンがあるノードがルートノード(親ノード)、その配下に子ノードを設定します。※ユースケース下段のキャプチャ参照ノードごとに管理者権限を設定できるため、組織の構造に合わせた柔軟な権限管理が可能です。詳細: ノードと組織構造ユースケースノードを作成する、おもなユースケースは以下の通りです。ユーザーの Keeper へのログインがSSOログイン。ユーザーの Keeper へのログインをSSOとマスターパスワードログインを共存させたい。複数のIdPを利用している。管理権限を委任したい(グループ会社含め全ユーザーを一つの Keeper テナントで管理しているが、グループ会社ごとに管理者を立てたい等)。構成イメージ図 ノードの設定は、ノードの作成 の記事をご確認ください。ノードに関するよくある質問は、ノードに関する注意事項 の記事をご確認ください。
Keeper / 重要な変更・障害のお知らせ
hanae 更新
Keeper パスワードマネージャーにおいて、ユーザーステータスの表示と挙動の不一致、およびアカウント移管の同意について仕様変更がありました。SSOログインのユーザーを作成する場合、これらの影響を考慮する必要があります。以下、ご確認お願いいたします。 ユーザーステータスの表示と挙動の不一致概要以下の条件においてユーザーを作成した場合、管理コンソール上で確認できるユーザーステータスと、実際の挙動が一致しないという不具合が発生しています。【条件】SSOログインを想定かつ、アカウント移管が有効になっているロールが割り当たっている対象製品Keeper Managerd by ZUNDAKeeper EnterpriseKeeper Enterprise PlusKeeperKeeper Gold PackageKeeper Enterprise Base Plun (Keeper Enterprise)不具合発生前の仕様上に記載の条件において、ユーザーを作成した場合、ユーザーがログインを実施するまで、そのユーザーのステータスは「招待済み」と表示されていました。また、そのユーザーがログインを実施すると、アカウント移管同意のポップアップが表示され、同意(承認)をスルーすると、7日後にそのユーザーはブロックされ、ユーザーステータスは「ブロック済み」となりました(アカウント移管の同意の期限が7日ということ)。なお、「ブロック済み」になったユーザーは、管理者により「アカウント同意の延長」を実施いただくことで、再度ログインが可能になります。現在の仕様(不具合箇所)上に記載の条件において、ユーザーを作成した場合、作成後7日以内にログインを実施しないと、そのユーザーのステータスは「招待済み」「ブロック済み」となります。ただし、「ブロック済み」ステータスであっても、ログインは実施可能です。つまり、管理コンソール上で確認できるユーザーステータスと、実際の挙動が一致しておりません。こちらは、Keeper 社に報告済みとなります。解消まで少々お待ちください。なお、アカウント移管の同意の期日が変更になっているので、下段をご確認ください。 アカウント移管の同意の仕様変更概要アカウント移管の同意期日が、7日から1日に変更になりました。 対象製品全プラン今後の対応初めてのログイン時に、アカウント移管同意のポップアップが表示されますので、同意ボタンをクリックするようにユーザーに周知してください。 その他なお、これらの不具合については Keeper 社から公式な情報が公開されていません。弊社は Keeper 社との対応履歴およびお客様とのやり取りに基づき、開示可能な情報のみを共有させていただいております。
Keeper / ユーザー・組織・権限管理
hanae 更新
ロールの作成と、強制適用ポリシー(ロールの内容)の設定について説明します。ロールの作成管理コンソール > 管理者 > 作成するノードを選択 > ロール > ロールを追加 > ロール名を入力してください、ロール名を入力する際に、どのノードの中に設定するのか、ノードを選択することも可能です。ユーザーロールも管理者ロールも作成方法は同じです。ロールの内容の設定においては、設定箇所がことなります。下段を確認して進めてください。ロールの編集編集したいロールを選択 > 右に表示される画面の、ロールのしたのバーの中を編集してください。該当ロールを設定したいノードを変更した場合は、ノードの選択欄で、変更先のノードを指定してください。オプションから、ロールの複製も可能です。 強制適用ポリシー(ロールの内容)の設定ユーザーロールユーザーロールの場合、ロールの内容は「強制適用ポリシー」から設定を進めていただきます。なお、その内容については 強制適用ポリシーの設定 をご確認ください。管理者ロール管理者ロールの場合、該当ロールの右下の「管理権限」タブをクリックし、設定マークから付与したい権限を選択します。詳細は 管理者権限の設定 をご確認ください。 各ロールの内容を設定したら、そのロールをユーザーやチームに割り当てます。ロールの割り当ては、ロールの割り当て をご確認ください。
Keeper / ユーザー・組織・権限管理
hanae 更新
ノードに関する注意事項や、よくある質問をまとめています。管理者アカウントを置くノードについてテナント全体を管理する Keeper Administrator の権限を付与するアカウント(Keeper におけるスーパーアドミン)は、ルートノード(親ノード)に置いてください。IdP とのセッションが切れてしまったなどの場合に、復旧作業を実施するにはルートノードに置いておく必要があります。また、そのアカウントはマスターパスワードでログインするように設定してください。なお、2025年2月以降、ルートノードの Keeper Administrator の権限を付与しているアカウントのみ、全てのノードの編集(作成・削除含む)が可能です。子ノードに Keeper Administrator の権限ロールを作成した場合は、該当ノードとその配下のノードのみ編集可能です。仮に、IdPと Keeper の連携がうまく行かず、すべてのユーザーがログインできなくなっても、状況を復旧することができるようにするためです。IdP連携SAML連携する場合、IdPは1つのノードに紐づきます(IdPとノードは1対1の関係)。複数のノードに対してSAML連携したい場合は、いくつか注意点がありますので事前にご相談ください。ノードの移動ユーザー・チームのノード移動は、ノードが親子関係にある場合は可能です。ただし、兄弟関係にある場合は、マスターパスワードをセットする必要があります。ユーザー・チームを一括で移動することはできません。共有におけるノードの横断・分離共有等の設定における、ノードの横断・分離どちらも設定することが可能です(兄ノードと弟ノード間で Keeper に登録している記録を共有するのか、させないのかの設定)。その他SAML対応のプランは、Enterprise、Enterprise Plus、Keeper Enterprise Base Plun、Keeper Gold Package です。
Keeper / ユーザー・組織・権限管理
masaruyokoi 更新
Keeper Enterprise をご利用されている企業のインターネットドメインを変更する場合は、Keeper Enterpriseでの変更も必要です。変更に際しては、このような手順を進めます。弊社の Keeper サポートまでインターネットドメイン変更についてご連絡ください。Keeper にて、新しいドメインの登録を行います。Keeper Commander の enterprise-user コマンドで、各ユーザの新しいインターネットドメインでのユーザIDを alias として設定してください。ユーザが新しいインターネットドメインでのユーザIDでログインしてください。弊社 Keeper サポートへのご連絡弊社より Keeper Enterprise をご購入されているお客様は、弊社に本件をご依頼ください。ご連絡いただく際には、現在ご利用のドメインと、新しく利用されるドメインをお知らせください。この内容を Keeper に伝えて設定を依頼します。Keeper での設定が完了しましたら、ご返答いたします。弊社へのご連絡は以下よりお願いいたします。https://help.zunda.co.jp/hc/ja/requests/new Keeper Commander でのエイリアス設定Keeper Enterprise のユーザに、新しいドメインでのユーザアカウントをエイリアスとして設定します。エイリアスの設定には Keeper Commander による操作が必要です。Keeper Commander は Keeper Password Manager をCLI(コマンド)で操作するための環境です。インストールや利用方法は Keeper による Commander CLIの説明を御覧ください。Keeper Commander は Keeper Administrator ロールを持ったユーザアカウントにて実行してください。例えば、ドメインを example.com から example.jp に変更され、ユーザアカウントの user1@example.com を user1@example.jpに変える場合には、下記のように enterprise-user --add-alias (eu --add-alias) コマンドを実行します。eu --add-alias user1@example.com user1@example.jpeu --add-aliasコマンドは、ドメイン変更するユーザ全員分を実行してください例えば、Keeper Enterpriseでのユーザがalice, bob, charlieの3人がいる場合には、eu --add-aliasコマンドは3回実行することとなります。eu --add-alias alice@example.com alice@example.jp
eu --add-alias bob@example.com bob@example.jp
eu --add-alias charlie@example.com charlie@example.jp大量のユーザーを変更する場合は、上記のコマンドをまとめたテキストファイルを作成し、run-batch コマンドで一括実行できます。(実行間隔 -dは5秒以上としてください)run-batch -d 5 "/Users/your-name/Desktop/batch.txt"新しいドメインでのログイン上記のCommanderによる エイリアス追加ができましたら、ユーザは新しいドメイン名でのユーザアカウントでもログインできるようになります。新しいドメイン名でのユーザアカウントで Keeper にログインするまでは、ユーザは古いドメイン名でも新しいドメイン名でも、どちらでもログインできます。新しいドメイン名でユーザアカウントでログインされましたら、そのユーザは古いドメイン名でのユーザアカウントではログインできなくなります。古いドメイン名でのユーザアカウントでログインできなくなることで、このユーザのドメイン移行が完了します。新しいドメイン名でのログインは、Keeper Enterprise の各々のユーザで行ってください。
Keeper / 共有・所有権・引き継ぎ
hanae 更新
共有フォルダには、レコード同様に「所有者(所有権)」が存在します。共有フォルダの所有者(所有権)の変更について説明します。 前提共有フォルダの所有者＝共有フォルダの作成者となります。チームに所有権を付与することはできません。 共有フォルダの所有者(所有権)は変更可能？共有フォルダの所有権について、ボルト上で他のユーザーに権限を変更することはできません(記録単体であれば、事前の所有権の譲渡が可能)。しかし、所有者のアカウントを削除する前に「アカウント移管」を実行することで、アカウント移管先のユーザーに、所有権を変更することが可能です。アカウント移管を有効化する アカウントを移管せずに、共有フォルダの所有者を削除した場合はどうなる？共有フォルダは引き続き利用可能。ただしその共有フォルダは、所有者がいない共有フォルダとなります。共有フォルダがゾンビ化されたとしても、共有フォルダは引き続き利用できます。共有フォルダ内のレコードの権限は、基本的に編集できません。レコードの権限は、共有管理権限が付与されているユーザーであれば変更可能です。Share Admin(共有管理権限)の詳細は下段に記載。共有フォルダのユーザーの権限は、共有先ユーザー・チーム全てに「共有先とレコードの管理」が自動で割りあたります。共有フォルダが共有されているユーザーおよびチームの権限が「管理権限」だったとしても、共有フォルダの所有者を削除した場合は、全ての共有先ユーザーおよびチームの権限は「共有先とレコードの管理」に昇格します。意図せず、上位の権限が付与されてしまうので、ご留意ください。なお、共有フォルダ情報このように表示されます(フォルダのiマークから確認可能)。 Share Admin(共有管理権限)でできることKeeper には、Share Admin(共有管理権限)という機能があります。所有者が不在の共有フォルダに対して、Share Admin権限を付与されているユーザーは、以下のような権限を持ちます。共有フォルダ内のレコードの管理権限「編集と共有設定」と同等の権限共有フォルダのユーザー管理権限「共有先とレコードの管理」と同等の権限フォルダのデフォルトの権限の変更共有フォルダの削除なお、Share Admin権限を持っていたとしても、共有フォルダを共有されない限りは、該当の共有フォルダにアクセスできません。 フォルダを正しく運用するためにはフォルダの所有者のアカウントが削除され場合は、所有者がいないフォルダとなります。引き続き、フォルダは利用可能ですが、共有先ユーザーおよびチームに、最上位のユーザー管理権限が付与されてしまう可能性があります。そういった事態を回避するためにも、必ずアカウント移管を実行してください。
Keeper / 共有・所有権・引き継ぎ
hanae 更新
録・フォルダの作成権限と、それらの共有権限のコントロールについて、管理コンソル 16.16.0 (2024年1月16日リリース)前後で、大きく仕様が変更しました。アップデート前後の、運用の違いについて以下まとめます。 アップデート後2024年1月16日の Keeper Admin Consle 16.16.0 のアップデート以降、「記録とフォルダの作成」と「共有」それぞれ細かく設定可能です。 記録とフォルダの作成「記録」「マイフォルダ」「共有フォルダ」の作成権限を細かく分けることが可能です。さらに、フォルダ内でのみ作成を許可するということもできます。 共有「共有」というアクティビティの「受信」「送信」の可否が設定でき、かつ、ワンタイム共有や社外との共有に関しても細かく設定できるようできるようになりました。おおまかに、以下の4段階で、共有アクティビティをコントロール可能です。記録・フォルダの共有(受信・送信ともに)可能フォルダを経由してのみ共有(フォルダへの記録の追加)可能記録・フォルダの共有は受信のみ可能記録・フォルダの共有(受信・送信ともに)不可また、オプション選択では、以下のコントロールができます。ワンタイム共有リンクを生成可ファイルを添付して記録を共有可社外のユーザーと共有可エンタープライズ外のユーザーからアイテムを受信可 アップデート前共有フォルダの作成できるユーザーを限定したい場合、ロール＞ポリシーの設定から、「記録とフォルダの共有禁止」の設定を行っていました。ただし、このポリシーを有効にすると、共有フォルダだけではなく、マイフォルダの作成まで禁止されてしまいました。以下、詳細です。 「記録とフォルダの共有禁止」とはユーザーによる記録やフォルダの共有に制限をかける機能です。デフォルトでは無効（グレー）になっています。ポリシー＞共有＆アップロードから設定します。「記録とフォルダの共有禁止：有効（緑）」になっている場合は、以下の権限も禁止となります。記録を共有する権限共有フォルダを作成・共有する権限共有フォルダに記録を追加できる権限記録・フォルダを受け取る権限 設定①強制ポリシーが「記録とフォルダの共有禁止：無効」のロールを作成しチームに割り当てる②強制ポリシーが「記録とフォルダの共有禁止：有効」のロールを作成し、受取だけのユーザー個人に割り当てる③共有する際は、フォルダ経由かつチーム単位で共有する。※次セクションに詳細 解説①強制ポリシーが「記録とフォルダの共有禁止：無効」のロールを作成しチームに割り当てる該当のロールを作成し、ポリシーが「記録とフォルダの共有禁止：無効」になっていることを確認し、チームを割り当てます（Teamから該当チームを選択）。 ②強制ポリシーが「記録とフォルダの共有禁止：有効」のロールを作成し、受取だけのユーザー個人に割り当てる該当のロールを作成し、ポリシーが「記録とフォルダの共有禁止：無効」になっていることを確認し、ユーザー個人に割り当てます（ユーザーから該当ユーザーを選択）。 ③共有する際は、フォルダ経由かつチーム単位で共有する。所属しているチームに「記録とフォルダの共有禁止：有効」のロールが割当たっている場合、チーム経由でしかフォルダを受け取れません。そのロールがチームに当たっていても、ユーザー個別に共有しようとすると、以下のように共有エラーになります。 ポイント「記録とフォルダの共有の禁止：有効」になっていると、共有する権限だけではなく、受け取る権限も無効となり、Keeper の特徴である「コラボレーション」が促進されません。該当ロールを有効にするユーザーが、「記録の閲覧のみ」の権限で業務上問題ない場合は有用な設定になりますが、コラボレーションという観点では、基本的にはロールで制限をかけるのではなく、ボルト上で、記録の権限・ユーザー権限を設定するのがベストです。
Keeper / ユーザー・組織・権限管理
hanae 更新
Entra ID のグループと Keeper のチームを同期する際の、よくある質問をまとめます。 前提Entra ID のグループ(ピンク点線枠)を Keeper のチームとして同期することが可能です。 設定の詳細：Azure／O365 Q1: 事前に Keeper にチームを作成し、それと同じ名前で Entra ID のグループを作成した場合、同期されますか？同期されます。さらに、Keeper のチームに存在しないが、Entra ID のグループに存在するユーザーは、自動で Keeper に追加されます。なお、Keeper のチーム名と、Entra ID のグループ名が一致しない場合は、Keeper 上に違うチームが作成されます。大文字・小文字含め一致させてください。Q2: Keeper のチーム名と、Entra ID のグループ名が別の場合、サービス間でそれらをマッピングする機能があるか現状ありません。既に、Keeper 上にチームを作成してしまった場合は、Keeper のチーム名と Entra ID ののグループ名を一致させるか、Keeper のチームを一度削除した後、プロビジョニングを実施してください。Q3: Entra ID のグループ名を変更した場合、それが Keeper のチーム名にも同期されますか？されます。Q4：Entra ID の Keeper のユーザーグループををネストして利用することはできますか？できません。詳しくはこちらをご確認ください。https://learn.microsoft.com/ja-jp/entra/identity/app-provisioning/how-provisioning-works#scoping
Keeper / ユーザー・組織・権限管理
hanae 更新
特定の管理権限のみを付与する方法を説明します。 設定方法(特定の管理権限を付与するための)管理者ロールを作成します。そのロールを選択 > 管理権限 > 管理ノードを追加で、対象のノードを選択します。どの管理権限を付与するのか、チェックを入れてください。 管理権限管理項目内容ノード管理ノードを追加、削除、編集する権限ユーザー管理ユーザーを追加、削除、編集する権限ロール管理ロールを追加、削除、編集する権限チーム管理チームへメンバーを追加、削除、追加する権限レポートとアラートレポートとアラートの作成、削除、編集する権限※対象プラン: Business Plus、Enterprise Plusブリッジ／SSOを管理Enterprise Bridge または SSO を追加、削除、環境設定する権限デバイス承認を実行SSO クラウドユーザーの場合、デバイスを承認する権限ボルト内の記録タイプを管理カスタムされた記録タイプの作成、編集、削除を行う管理者権限の権限ボルト内のレコートタイプを管理記録タイプの作成、編集、削除を行う権限共有管理Share Admin をご確認ください。コンプライアンスレポートの実行コンプライアンスレポート機能の作成、編集、削除を行う権限※対象: コンプライアンスレポートを追加オーダーしている場合アカウント移管ユーザーのボルトを移転する機能（ユーザーのロールがこれを許可するように設定されている場合。 ※ロールのメンバーである管理者のみが、「アカウント移転」をチェックできます 権限を下位ノードに適用とは、作成した管理権限を下位のノードにまで適用させたい場合にチェックをいれます。
Keeper / ユーザー・組織・権限管理
hanae 更新
初期管理者として、管理コンソールにログインできるようになったら、他のユーザーやアカウントに Keeper Administrator の権限を付与してください。 権限付与の方法管理コンソールに入り、タブ「管理者」 > 対象のノードを選択 > ユーザーを選択します。ロールの右側に＋マークが表示されるので、「Keeper Administrator」のロールを付与してください。※なお、ロール名は自由に設定可能です。分かりやすいよう設定変更してください。
Keeper / 導入・利用開始・アプリ配布
hanae 更新
Keeper の納品時(トライアル含む)に行うことを確認してください。 初回ログイン【必須】初期管理者様に、Keeper 社からのアカウント招待メールが届きます。案内に従い、初回ログインを実施してください。その後、弊社が管理権限を付与します。管理権限が付与された後、管理コンソールが利用可能になります。 拡張機能のインストール【推奨】こちらから、ブラウザ拡張機能をインストールしてください。Password Autofill Browser Extensions - Keeper Securityブラウザの拡張機能を利用すると、新規のIDやパスワードの作成時や、入力時にサポート(自動入力など)の支援機能が提供されます。 その他Keeper の利用時によく確認するドキュメント等、ブックマーク登録することをお勧めします。ドキュメントURLKeeper 使い方ガイドhttps://zundainc.notion.site/Keeper-895c2709287a4869a42409e18ade2737Keeper 管理者向けスタートガイドhttps://zundainc.notion.site/Keeper-239a60992b7a4abd8781149bf376466cKeeper 利用者向けスタートガイドhttps://zundainc.notion.site/Keeper-7255f6ce2caf47a89117d4fafe029291Zendeskhttps://help.zunda.co.jp/hc/jaKeeper 公式ドキュメントhttps://docs.keeper.io/enterprise/
Keeper / 導入・利用開始・アプリ配布
hanae 更新
Keeper の利用開始までに行うことを確認してください。 契約内容の決定以下の契約内容を決め、営業担当までご連絡ください。Keeper のプランコンプライアンレポートの有無ライセンス数サポートプラン利用開始予定日契約期間（月額契約 or 年額契約）契約締結1. 事前に以下のページより Keeper の利用規約の確認をご確認ください。Terms of Use※日本語は参考訳で、正文は英語版です。ページ最下部より “English (US)” に切り替えてご確認ください。2. 発注のご連絡お見積もりをお送りしたメールに「発注します」と記載のうえ、ご返信いただくことで発注確定となります。手続き上、追加の書類(発注書や発注請書など)が必要な場合は、発注書・発注請書の発行について をご確認ください。3. お得意様情報のご入力 (初回の契約時のみ)ZUNDAとの取引がはじめての場合は、所定のWebフォームにご記入いただきます。ご連絡先や反社会組織でないことの表明など、簡単に記入できる内容です。ご発注いただくタイミングで営業担当よりご案内いたします。 契約後に送付するものいずれもメールでお送りしております。サービス開通通知 (月額契約) または 納品書 (年間契約)月額契約の場合は、サービスプランを記載した開通通知をお送りしております(従量課金のためライセンス数は記載しておりません)。年間契約の場合は、サービスプラン、数量、金額、契約基幹を記載した納品書をお送りしております。 請求書月額契約の場合は、前月利用されたライセンス数は請求書にてご確認ください。年間契約で利用超過があった場合も請求書と納品書をお送りしておりますのでご確認ください。
Keeper / セキュリティポリシー・監査
hanae 更新
Keeper 管理コンソールの「レポートとアラート」タブの説明です。レポートとアラートは、全プラン対象の機能と、対象プランが限定されている機能があります。下段のプランごとの機能を確認してください。 レポートいつ・誰が・どのようなアクティビティがあったのかを確認することができます。過去2カ月間・最大1000件までのアクティビティを保存することができます。また、ユーザー別、イベントタイプでレポートを絞り込んで表示することも可能です。 カスタムレポートユーザー別、イベントタイプでレポートを絞り込んだレポートを保存することが可能です。カスタムレポート追加を選択しレポート名を入力した後、作成したいレポートの内容に沿って各フィルター内の項目を選択してください。最後に保存を押してください。 アラート特定のイベントタイプに基づいて、電子メール、SMS、Webhook 通知を送信できるアラートトリガーを設定することが可能です。レポートとアラート＞アラートタブ＞アラートを追加し、イベントタイプと属性をそれぞれ選択します。受取人を追加で、受取方法を選択し保存します。※Webhookを利用する場合は、Keeper 公式ドキュメント Webhooks (Slack & Teams) を参考に設定してください。 SIEM連携(外部ログへの接続)Keeper 上のアクティビティを、外部ログに接続することが可能です。 ※詳細は、Keeper 公式ドキュメント レポート、アラート、SIEM をご確認ください。 注意点Keeper の記録にはそれぞれ固有のUIDが付与されます。管理者側で、UIDがどのサイトの記録情報であるかを把握するには、該当の記録が管理者のマイボルトにある（管理者に共有されている）必要があります。もし、共有されていないUID情報を特定したい場合は、記録を保有しているユーザーに確認をとるか、コンプライアンスレポートの機能を追加（オプションになります）する必要があります。
Keeper / セキュリティポリシー・監査
hanae 更新
Keeper 管理コンソールの「セキュリティ監査」タブの説明です。セキュリティ監査タブでは、保管されているパスワードの安全性を確認することができます。 上段部分で、テナント全体のセキュリティスコアが表示されています。 下段部分では、ユーザー個別にセキュリティスコアを確認することができます。使い回しが多かったり、パスワードの強度が弱いユーザーがいる場合は、個別にパスワードの変更を促してください。※ただし、それに該当するパスワードがどのサイトで利用されているかまでは特定できません。ユーザー自身が確認することは可能です。 脆弱なパスワードの利用や、使い回しがないか、定期的に観察する際に利用してください。なお、ユーザーのボルトの「セキュリティ監査」タブにて、ユーザー自身が保有している記録のセキュリティレベルを確認することが可能です。
Keeper / ユーザー・組織・権限管理
hanae 更新
Keeper 管理コンソールの「管理者」タブの説明です。 初期設定時、この管理者タブからノード・ユーザー・ロール・チームの作成で使います。詳しい内容や推奨設定については下段のドキュメントを確認してください。ノードとはロールとはチームとは・チームの作成ユーザーの作成
Keeper / 共有・所有権・引き継ぎ
hanae 更新
共有レコードや共有フォルダに対して、レコードの所有者や共有フォルダの作成者と同等の権限（編集や共有）を持たせることのできる管理権限です。 Share Admin ができること共有レコードに対してレコードの編集レコードの共有レコードの所有者の譲渡共有フォルダに対して共有フォルダにあるレコードの編集共有フォルダへのレコードやユーザーの追加や削除共有フォルダのデフォルト権限の変更 設定方法Share Admin の権限を利用するには、以下のような設定が必要です。Share Admin 権限用のロールを作成する。許可する管理項目の「共有管理」にチェックを入れてください。Share Admin の権限を利用させたいユーザーに付与する。該当のレコードや共有フォルダを、そのユーザーに共有する。※共有されているレコードやフォルダに対してのみ、ShareAdmin の権限が有効となります Share Admin を設定するメリットこれまで、共有先のユーザーにレコードの編集権限や、ユーザーの管理権限を付与していない場合、レコードの所有者や共有フォルダの作成者が、都度設定変更する必要がありました。Share Admin の権限を持っているユーザーに対してレコードや共有フォルダを共有することで、所有者・作成者の代わりに権限変更が可能です。共有フォルダの作成者が Keeper にログインできなくなった時などに便利な機能です。 参照Keeper 社の公式ページも参照ください。https://docs.keeper.io/jp/enterprise-guide/sharing/share-admin
Keeper / 共有・所有権・引き継ぎ
hanae 更新
所有権の譲渡レコードの権限設定を引き継いだまま、他のユーザーに所有権(オーナー権限)を移転する機能です。例えば、退職が決まっているため、所有しているレコードを事前に他のユーザーに変更したいときなどに利用します。所有権の譲渡は、レコードのオーナー自らが行う方法と、管理者が行う方法があります。 設定方法オーナー自らが行う方法移転を実行するには、レコードを表示 ＞ オプション＞「所有権の譲渡」を選択し、譲渡先ユーザーのメールアドレスを入力します。 管理者が行う方法管理者が行う場合は、アカウント移管を実施します。アカウント移管については、こちらを確認してください。アカウント移管を有効化する 注意点レコードの所有権を移転すると、前所有者は自分のボルトからはアクセスできなくなります。
Keeper / 導入・利用開始・アプリ配布
hanae 更新
Keeper 管理コンソールの基本的な機能を簡単に紹介します。管理コンソールへのログイン以下のリンクより Keeper 管理コンソールへアクセスしてください。また、Webボルトの左下の「管理コンソール」からもアクセス可能です。USリージョンhttps://keepersecurity.com/consoleJPリージョンhttps://keepersecurity.jp/console※2023年春以降にご契約した場合は、JPリージョンです。※Keeper の管理コンソールにログインするには、管理権限が必要です。 管理コンソールで行うこと管理コンソールでは、Keeper の設定(ノード・ロール・ユーザー作成、ポリシーの設定)を実施します。また、レポート機能や、監査機能などをご利用いただけます。 管理コンソールの概要プランにより利用できる機能に制限があります。詳しくは、次の表と詳細リンクを確認してください。プロパティ名内容対象プラン詳細リンクダッシュボードユーザーのアクティビティやステータス、総合セキュリティスコアの確認全プランドキュメントなし管理者ノード・ユーザー・ロール・チーム・2FA・ユーザープロビジョニングの設定全プラン管理者リスク管理管理者による設定の推奨事項が表示全プランドキュメントなしセキュリティ監査パスワードのセキュリティ強度や使い回しに関するレポート情報を確認全プランセキュリティ監査コンプライアンスレポートSOX法やその他のアクセス管理に関する監査の規制で求められる定期的な監査レポートの作成オプション(追加オーダーが必要)コンプライアンスレポートBreachWatchダークウェブの漏洩データをスキャンし、危険度の高いパスワードを通知Business PlusEnterprise PlusBreachWatchSecrets Managerシークレットを管理するソフトウェアプラットフォームオプション(追加オーダーが必要)ドキュメントなし詳細は、sales@zunda.co.jpまでご連絡くださいConnection Managerウェブブラウザを介して、システムへ安全にリモートアクセスするためのツールオプション(追加オーダーが必要)レポートとアラートイベントログの監査・外部ログへの転送と、アラート通知の設定一部の機能が次のプランのみ対象Business PlusEnterprise Plusレポートとアラートサブスクリプション契約内容(プランやライセンス数等)の確認全プランドキュメントなしカスタムブランディング会社ロゴの設定、Keeperへの招待メールのカスタマイズ設定全プランドキュメントなし入門ガイド各種動画コンテンツ全プランドキュメントなし
Keeper / ユーザー・組織・権限管理
hanae 更新
Keeper のチームについて説明します。 チームとはチームは、ユーザーをグループ化する方法です。フォルダや記録の共有、ロールの付与の際に活用します。設定方法設定する方法は、手動(管理コンソール内で作成)と自動(プロビジョニング)で作成する方法があります。手動作成管理コンソール > 管理者 > チーム > チームを追加どのノードにチームを追加するのかを選択チームを作成後、メンバーを追加してください。詳細は、Keeper 公式ドキュメント チーム（グループ ） を確認してください。 自動作成SCIM (System for Cross-domain Identity Management) に対応した IdP を利用してユーザー情報を同期させることにより、ユーザーの削除やチームの所属情報も同期できます。SCIMを用いた連携について、以下の Keeper の公式ドキュメントをご確認ください。 参考ユーザーとチームのプロビジョニング - Enterprise 管理者ガイド (keeper.io)SCIM による Azure AD プロビジョニングSCIM による Okta プロビジョニングSCIM による Google Workspace プロビジョニングSSO - JIT（ジャストインタイム）プロビジョニングと認証 そのほかのIdPとの連携などは以下のドキュメント中からご確認をお願いいたします。ユーザーとチームのプロビジョニング - Enterprise 管理者ガイド (keeper.io) 詳細は、ユーザーの作成方法 をご確認ください。
Keeper / ユーザー・組織・権限管理
hanae 更新
ノードについて説明します。ロールとはユーザーやチームに、Keeper のセキュリティポリシーや利用機能をひとまとめにして、割り当てる機能です。例えば、Keeper へのログイン方式(SSO ログイン or マスターパスワードログイン)により、割り当てるロールが異なります。各ロールにパスワードの複雑さやアクセス権限などをまとめて設定することで、セキュリティ管理を効率化し、組織全体の安全性を高めます。ロールの利用Keeper の仕様上、必ずユーザーにロールを割り当てる必要があります。ロール未割り当ての場合、ログインできません。ログイン時に、割り当てるロールについては、「ノードとサブノードのデフォルトロールに設定」にチェックを入れてください。Keeper のロールは、ユーザーにポリシーを割り当てるためのロール(ユーザーロール)、管理者権限を付与するためのロール(管理者ロール)が存在します。一般ユーザーにはユーザーロールを、管理者には、ユーザーロールに追加で管理者ロールを割り当ててください。ユーザーロールは、強制適用ポリシーという設定項目から、Keeper のセキュリティポリシーや利用機能を設定します。Keeper へのログイン方式の違い(SSO ログイン or マスターパスワードログイン)や、職位や雇用形態の違い(社員は記録の共有が可能、業務委託は共有不可など)により、割り当てるセキュリティポリシーや利用機能を規定できます。管理者ロールは、管理権限のタブから設定してください。ロールについては、一度 ロールの特徴 をご確認ください。その他ロールは複製可能です。複製する際に、ノードを選択できます。ロールは、ノードを横断して設定可能(所属しているノード以外のロールについても付与可能)です。ノード・ロールの構成についてお悩みの場合は、sales@zunda.co.jpもしくはコネクトしているコミュニケーションチャネルよりご連絡ください。ロールの作成等については、ロールの作成 をご確認ください。
Keeper / ユーザー・組織・権限管理
hanae 更新
ノードの作成方法について、説明します。なお、事前に ノードとは をご確認ください。 ノードの作成管理コンソール >「管理者」タブ > ルートノード(親ノード)の右の3つの点 > ノード追加から作成できます。ビルのようなアイコンがあるノードがルートノード(親ノード)です。作成時は、どのノードの配下に作成するのかを選択してください。複数階層のノード設定が可能です。詳細は、Keeper 公式ドキュメント ノード構造と社内構造 を確認してください。 ノードの編集編集したいノードを選択した後、ノードの右の3つの点をクリックしてください。ルートノード(親ノード)は編集できません。編集希望の場合は、弊社までご連絡ください。 ノードに関するよくある質問は、ノードに関する注意事項 の記事をご確認ください。
Keeper / ユーザー・組織・権限管理
daichi 更新
Entra ID(旧: Azure Active Directory)や Okta などの IdP を活用してのユーザー・プロビジョニングには SCIM とジャストインタイム(以下、JIT)の2つの設定が Keeper にはあります。 SCIM と JIT の設定ですが、Keeper においては、「両方」ともに設定して頂くことをおすすめしております。SCIM のみを設定している場合、IdP と同期されたタイミングで自動で Keeper にユーザーが作成されますが、同期には時間がかかる場合があります(例えば、Entra ID の場合 SCIM では40分に1回同期されるようになっています)。そのため、アカウントを作成した直後のユーザーで、次回の同期タイミングが到来する前に Keeper にログインしようとした場合、SCIM だけではログインに失敗します。JIT と併用することで、こういったケースでもログインに成功します。一方、JIT による同期はアカウント作成時にしか行われません。SCIM と連携しておくことで、退職など Entra ID 側で外れたユーザーについて、Keeper 側でも自動的に凍結状態になります。またグループ(チーム)の所属情報も SCIM でしか同期できません。ぜひ、両方とも設定してください。注意点Keeper には、ノード(セキュリティ単位でユーザーをグループ化する方法)が存在します。SAML ログインとする場合は、最上位ノードの配下に、SSOログイン用のノードを作成してください。IdP の乗り換えを検討する場合や、IdP の構築についてご相談ある場合は、弊社までお問い合わせください。
Keeper / 契約・ライセンス・サポート
daichi 更新
Keeper のライセンス課金対象となるユーザーのステータスに関する説明です。 ユーザーステータスについてKeeperの管理コンソールにおいて、ユーザーのステータスは以下の4種類で表現されます。ユーザーステータスについては、こちらのリンクをご参照ください。招待済みKeeper へ招待済み。アクティブKeeper へログイン済み。IdPによりロックActive Directory, Entra ID をIdPとして利用しており、IdPにおいてユーザーを無効化。ロック中Keeper 上で手動でユーザーをロック。また、Active Directory, Entra ID 以外のIdPを利用し、IdPにおいてユーザーを無効化。※なお、2025年04月より、ユーザーステータスの表記が変更になりました。さらに、アカウント移管同意に関するステータスの表記がなくなりました。現状、アカウント同意の有無について確認するためには、ユーザーをクリックし、「移管ポリシー」をご確認ください。 課金対象となるユーザーステータス課金対象となるユーザーのステータスは、ユーザー作成方法により異なります。 手動作成プロビジョング招待済み対象外対象アクティブ対象IdPによりロックロック中※SCIM を利用して Entra ID や Okta などからユーザー情報を同期している場合、同期されてユーザーが作成された時点で(未ログインであっても) 課金対象のライセンス数として計算されます。 管理コンソールのサブスクリプションページにおける表記について管理コンソールの「サブスクリプション」ページの「ライセンス」に表示されている数字は、アクティブ = 有効招待済み = 招待となっております。
Keeper / 契約・ライセンス・サポート
daichi 更新
Keeper は管理者であっても、いちユーザーとして Keeper のライセンスが必要になります。一方で、管理者に対して、管理業務だけを行うような権限付与をロールなど通じて行うことは可能です。
Keeper / 契約・ライセンス・サポート
daichi 更新
現在ご契約しているライセンス数について、利用していないアカウントがある等で、ライセンスを減数したい場合のご案内になります。 年間契約の場合年間契約をご契約の場合は、次回更新時にのみ、契約ライセンス数を減らすことが可能です。事前に更新前に弊社より更新のご案内をお送りいたします。その際に、契約ライセンス数を減らしたい旨、営業担当者にお伝えください。 月額契約の場合月額契約でご利用の場合、特にライセンス数を減らす場合に弊社にご連絡を頂かなくても、問題ございません。月額契約は毎月の請求が月間平均ライセンス数を基に作成されております。そのため、不要になったユーザーを削除していただくだけで、自動的に当該月の請求からは除かれます（日割計算のうえ、1ライセンス未満は切り上げ）。
Keeper / ユーザー・組織・権限管理
daichi 更新
この記事では、Keeper にユーザーを作成する方法をご紹介します。その方法として、以下の2つが挙げられます。手動で追加する方法IdP (IDプロバイダ) と連携しプロビジョニングを行う方法 手動で追加する方法手動で追加する場合、以下の2つの追加方法があります。個別追加CSVファイルを利用して複数を追加する方法個別追加1. まず、ユーザーを追加したいノードを選択します。その後、「ユーザーを追加」を選択します。2. 以下のようなポップアップが表示されます。3. 個別に追加する場合は、「フルネーム」、「メールアドレス」「役職(任意)」を記入し、追加をクリックします。ユーザーが追加されているのを確認して、終了です。 CSVファイルを利用して複数を追加する方法インポートできる情報は、「メールアドレス」「名前」「ロール」「役職」です。チームは、ユーザーをインポートした後に手動で設定が必要です。Keeper 上で、先にロールを作成(ポリシー設定含め)してからインポートすることをおすすめします。追加方法以下の手順に沿って、設定してください。1. まずは、Keeper 上でロールを作成します。ロールのついては、ロールとは を確認してください。2. 作成したロールが、全ユーザーに適用させたいロールの場合(例: defaultロール)は、「ノードとサブノードのデフォルト・ロールとして設定」にチェックを入れます。3. CSVファイルを用意しますファイル内にヘッダー行を含めず、以下の並びでデータを作成してください。これ以外の情報はインポートできません。ユーザーアドレス名前ロール※参照役職※ロールのインポートは以下の点に注意してください。ロールは一つしか選択できません。ユーザーロールのみインポート可能です。管理権限を持つロール(Keeper Administrator や、代理管理権限を保有するロール)を選択していた場合、そのユーザーはインポートされません。管理権限を持つユーザーをインポートする場合は、インポート後に Keeper上で管理権限ロールに追加してください。 4. 管理コンソール＞管理＞ユーザー＞ユーザーを追加をクリック＞追加するノードを選択。5. CSVファイルをアップロードします。6. ユーザー欄に追加されいてるのを確認します。追加されると、メールで招待が送られます。 IdPと連携しプロビジョニングを行う方法IdP と連携している場合、初回ログイン時にユーザーが自動的に追加されます。SCIM (System for Cross-domain Identity Management) に対応した IdP を利用してユーザー情報を同期させることにより、ユーザーの削除やチームの所属情報も同期できます。IdP と連携しユーザーを作成する場合は、事前に SCIM と JIT の設定について をご確認ください。 設定方法実際に、SCIM 連携を設定する場合、以下の Keeper の公式ドキュメントをご確認ください。ユーザーとチームのプロビジョニング - Enterprise 管理者ガイド (keeper.io)SCIM による Azure AD プロビジョニングSCIM による Okta プロビジョニングSCIM による Google Workspace プロビジョニングSSO - JIT（ジャストインタイム）プロビジョニングと認証 そのほかの IdP との連携などは以下のドキュメント中からご確認をお願いいたします。ユーザーとチームのプロビジョニング - Enterprise 管理者ガイド (keeper.io)
Keeper / ユーザー・組織・権限管理
daichi 更新
Keeper のロールにおけるポリシー設定は非常に細かい設定ができる反面、整理して理解するのが難しい部分ではあります。この記事では、異なるポリシー設定になっているロールを同時に割り当てられている場合における、それぞれの設定の適用ルールについて解説します。 基本的なルール複数の設定項目が異なるロールが適用されている場合、基本的には以下のルールにのっとて権限が付与されます。Keeper が元々提供しているデフォルトのロール設定から変更した部分がある場合は、該当項目については変更後のポリシーが適用される。ポリシーはより制限が厳しい方が優先される。デフォルトのロール設定から設定を変更しており、その変更が異なる方向を向いている場合は、どちらの設定が適用されるか保証されない。 例1：共有フォルダの禁止「記録とフォルダの共有を禁止」は初期設定では、「OFF」になっています。（上記の図を参照）ここで、ロールAとロールBを考えてみます。 ロールAスタッフ向けロールで「共有フォルダ」の作成不可「記録とフォルダの共有を禁止」は「ON(有効)」ロールBマネージャー向けで「共有フォルダ」の作成化。「記録とフォルダの共有を禁止」は「OFF(無効)」 このとき、両方のロールを付与されているユーザーがいた場合、「記録とフォルダの共有を禁止」は「ON」になります。これは、初期設定が「OFF」だったものに対して、変更後である「ON」が優先されるためです。 例2：パスワードの文字数の強制Keeperではロールに適用するポリシーで特定のウェブサイトで利用するパスワードの生成ルールを強制することが可能です。例えば、以下の画像の例だと、google.comで利用するパスワードはそれぞれ、24文字と32文字というふうに設定されています。 この場合、両方のロールを付与された場合、ロールBの方がより強い設定になっているため、採用されます。 例3：パスワードの文字数と種類の組み合わせ例2では、文字数のみが違っており、他の条件は一緒でした。では、文字の種類を含めて比較された場合はどうでしょうか。 この例だと、文字数としては、ロールBの方が長いですが、種類が少なくなっています。そのため、ロールAとロールBのどちらが明確に強い制限かを判別することができません。この場合、Keeperではどちらの条件を採用するかはランダムに決まります。まとめ複数のロールを付与されており、設定が競合している場合の設定の採用について解説しました。Keeperでは、細かい設定が可能な一方で複雑になりがちでもあります。まずは、シンプルな設定を持っているデフォルトロールを採用し、その上で、制限をかけていくのが良いのではと弊社では考えています。
Keeper / 共有・所有権・引き継ぎ
daichi 更新
共有フォルダは、Keeper においてチームでパスワードを共有するために非常に便利な機能です。 しかし、ユーザー管理とパスワード管理に関する設定について、日本語訳の問題もあり、少々分かりにくいのが現状です。この記事では、ここの設定の内容について解説します。なお、元となる情報は、Keeper公式のガイド（英語版）をご覧ください。 設定箇所主なの設定箇所としては、共有フォルダの新規作成時の「デフォルトのフォルダ設定」、もしくは、共有フォルダの編集タブから設定することが可能です。 共有フォルダの新規作成時の設定共有フォルダの作成時に、デフォルトの権限設定を行います。権限の具体的な中身は下段を確認してください。ここで設定した権限は、レコードおよびユーザー・チーム単位で上書きすることも可能です。 「レコード」の権限設定編集可この権限を付与されたユーザーはレコードの編集が可能です。パスワードにプライバシー画面を適用している場合でも、編集権限が付与されている場合は、閲覧可能です。共有可 この権限を付与されたユーザーは、このレコードを他のユーザーやチームに共有できます。編集と共有設定が可能上記の二つの権限が付与されます。閲覧のみ閲覧のみ可能です。 「ユーザー」の権限設定チームに共有することが可能です。共有先の管理このフォルダを、共有するユーザーの追加と削除が可能です。記録の追加と削除を許可このフォルダに、記録の追加あるいは削除が可能です。共有先と記録の管理上記の二つの権限が付与されます。※この権限を持っている場合、共有フォルダの削除ができます。フォルダを削除すると、保管されていた記録は、各記録の所有者のボルトにある「削除したアイテム」セクションに移動します。管理権限なしフォルダへのアクセスのみ可能です。 共有フォルダの権限の上書き共有フォルダにあるレコード、および共有しているユーザー・チームへの権限を上書きすることが可能です。該当の共有フォルダの編集画面から、それぞれのタブで権限の上書きを行ってください。 注意点フォルダ内のレコードの権限は所有者もしくは「編集と共有設定が可能」の権限を保有しているユーザーしかしか変更することができません。
Keeper / ログイン・認証連携
shao 更新
Keeper では 2022年 8月 7日にシングルサインオンに利用している証明書の更新を行いました。後述の通り、Azure Active Directory, Google Cloud Identity, Okta などを利用されている一般的な構成では影響がありませんが、一部の IdP (ADFS, Ping Identity) やシングルログアウト (SLO) 機能を利用されている場合は新しい証明書を IdP に登録する必要があります。対象以下にあてはまる環境でご利用いただいているお客様は、SAML SP シングルサインオン証明書 (以下SSO 証明書) の更新が必要です。 (A) 以下のすべてに該当するケースADFS (Active Directory Federation Service) または Ping Identity を IdP として連携しているKeeper Automator を利用していないSSO Connect® Cloud を利用している (オンプレミス版の SSO Connect は該当しません)(B) 以下のいずれかに該当するケースOkta でシングルログアウト (SLO) の構成をしているOkta の管理ポータルで、Keeper の "Sign On" タブを開き、 "Enable Single Logout" が有効になっている場合は該当しますSP-initiated SLO の構成をしている 事象と対応対象 (A) の場合: シングルサインオン構成でのログインができなくなります対象 (B) の場合: Keeper からログアウトした際に IdP ではログイン状態が持続します証明書の更新ができていない場合は、【sales@zunda.co.jp】までご連絡ください。該当するお客様への対応「対象」のセクションをご確認いただき、影響が見込まれるお客様は弊社までご連絡ください。(アドバンスドサポートを契約されている場合は Slack 等のチャットでも構いません)事前に SSO を必要としない管理者アカウントで管理コンソールにログインできることを確認してください。また IdP の管理画面にログインできることも確認してください。新しい証明書は 2022年 8月 8日 に利用可能となる予定ですが、時差等の都合で正確な日時がわかっておりません。利用可能になったタイミングで弊社より連絡いたしますのでお待ちください。管理コンソールの「管理者」セクションから、SSO設定を行っているノードを選択し、[プロビジョニング] タブから SSO Connect Cloud の設定を「表示」させます「SP認証エクスポート」を選択します入手した証明書の新しい期限は openssl コマンドで確認できます。openssl x509 -noout -text -in (ファイル名)新しい証明書を IdP に登録します。次回の更新次回の Keeper SSO 証明書の更新は、2032年 8月26日を予定しています。 関連文章SSO Certificate Renewal 2022 - Release Notes
Keeper / ユーザー・組織・権限管理
daichi 更新
Keeper 全体の管理権限は持たないものの、あるノードにおいてチームを作成・運用する為の管理者(以下、チーム管理者)を作成したい場合の手順をご紹介します。 設定方法まずは、チーム権限だけを付与するロールの作成を行なってください。作成方法は、ロールの作成 をご確認ください。該当のロールに割り当てる、管理権限を設定します。管理権限の設定は、管理者権限の設定 をご確認ください。付与する権限についてチームを作成・運用に関連する権限は以下の2つを付与してください。チーム管理: あるノードにチームを作成し、編集する権限ユーザー管理: あるノードおいてユーザーの追加・削除、及びそのユーザーの属性を編集する権限組織内すべてのチームとユーザーを管理対象とする場合は、🏢マークのついた親ノードに対して上記2つの権限を付与してください。 管理権限を一部のノードのみに制限する場合管理権限を一部のノードのみに制限する場合は、以下の点に注意してください。チームを追加したいノードにおける「チーム管理」権限をロールに付与する。チームに追加したいメンバーが所属しているノードの「ユーザー管理」権限をロールに付与する。---------例: 「業務委託」ノードに所属するユーザーを「スタッフ」ノードに定義されたチームに追加する権限ノード「スタッフ」における「チーム管理」の権限を付与ノード「業務委託」における「ユーザー管理」の権限を付与---------
Keeper / アプリ・ブラウザの利用設定
shao 更新
本来編集できるはずの記録が編集できないなど、Keeper のボルト(パスワード保管庫)で権限まわりに予期しない事象が発生した場合は、次の手順で権限管理データベースの修復を試みてください。手順ブラウザで Keeper が利用できる状態にしてください(拡張機能をインストールし、緑色のインジケーターを確認する)以下のリンクをクリックし、Keeper のボルトを診断モードで起動してください。USリージョンの場合：https://keepersecurity.com/vault/#diagnosticsJPリージョンの場合：https://keepersecurity.jp/vault/#diagnostics右上のメニューから「設定」をクリックしますDiagnostic メニュー内の「Sync Security Data」にある Sync ボタンをクリックします※ Diagnositics が表示されない場合は、いちどKeeperの画面を閉じてから再度手順2のリンクをクリックしてください右下に「成功」のメッセージが表示されることを確認してください。ブラウザをすべて終了させます。あるいはブラウザを確実に終了するためパソコンを再起動してください。ブラウザを開き、Keeperのボルトに再びアクセスして問題が解決したか確認してください。問題が解決しない場合は、ZUNDAサポートチームまでお問い合わせください。
Keeper / セキュリティポリシー・監査
shao 更新
ユーザーロールを作成したら、該当のロールの強制適用ポリシーから、実際に割り当てたいセキュリティポリシーや利用機能を設定します。 設定箇所該当のロールの、「強制適用ポリシー」から設定を進めていただきます。設定内容の一覧ZUNDAでは、Keeper へのログイン方法毎に、ユーザーに適用する推奨ポリシーをご案内しております。ここでいうログイン方法別とは、「SAML ログイン」または「マスターパスワードログイン」になります。Keeper 初期設定ガイド_ログイン方法別 ロール推奨設定 注意事項以下の点にご注意の上、ご活用ください。実際の設定値は組織のセキュリティ方針や運用と対比して慎重に決定してください。Keeper 初期設定ガイド_ログイン方法別 ロール推奨設定 は必ずコピーしてご利用ください。
Keeper / 共有・所有権・引き継ぎ
shao 更新
この機能はインシデントに先立ち事前設定が必要です(Keeper アカウント配布前に設定を行ってください)。 概要アカウント移管は、あるユーザーのボルトのレコードを他のユーザーに引き継がせることができる機能です。ユーザーの退職、マスターパスワードを忘れログインできなくなった際に備え、設定してください。 以下のような順で設定します。「アカウント移管」の管理権限を持つロールを作成し、アカウントの受取人に割り当てる「アカウント移管を有効化」する強制ポリシーを持つロールを作成し、アカウントの移管元のユーザー、チーム、ノードに割り当てる 設定手順1.「アカウント移管」の管理権限を持つロールの作成Keeper Admin 以外に、アカウント移管のみを実行する管理者を作成する場合は、その管理者ロール(例: Account Transfer Destinations) を作成します。Keeper Admin がアカウント移管を実行する場合は、追加のロール作成は不要です。作成したロールに、アカウント移管を実行するユーザーを追加します。※チーム は追加できませんそのロールの「管理上の許可」をクリックし、どのノードに適用するのかを選択します。続いて、付与する権限の選択画面が表示されるので、「アカウント移管」にチェックを入れ、保存を押します。 2. 「アカウント移管」を適用するロールの設定基本的には、デフォルトのロールの「アカウント移管を有効化」を有効化してください。該当ロールの強制ポリシー＞アカウント移管へと進み、ドグルを有効にしてください。すると、実際にアカウント移管を実行するロールの選択画面が表示されます。ここで、1で作成したロールを割り当ててください。 アカウント移管有効化後の挙動アカウント移管を有効にしておくと、ユーザーが初めて Keeper にログインする際に「アカウント移管への同意」が求められます。ユーザーがこの同意をスキップすることが可能なため、ユーザー様に同意するボタンをクリックするよう事前にアナウンスを実施してください。Keeper のアカウント配布後にアカウント移管有効化をした場合は、アカウント移管有効化した後の、初めてのログイン時に上のようなポップアップが表示されます。ユーザーはこの同意ボタンをクリックする必要があります。 アカウント移管の注意点アカウント移管の同意期間は、初めてログインしてから7日間です。7日間を過ぎると、アカウントがロック状態になります。これが理由でロックがかかった場合、管理者が該当ユーザーに対して「アカウント同意の延長」を実施することで、ロック解除できます。ロック解除後の初めてのログイン時に、同様のポップアップが表示されるので、必ず「同意する」をクリックしてください。 参考記事Account Transfer Policy - Keeper Enterprise Guide (英語)
Keeper / ユーザー・組織・権限管理
shao 更新
利用中のユーザー数を確認したり、ユーザーの一覧をエクスポートするには、以下の手順で行います。 手順管理コンソールにログインしますダッシュボードの「ユーザーのステータス」セクションにユーザー数が表示されます。消費ライセンス数は、一覧に表示されている値の合計値です。一覧をエクスポートするには「ダウンロード」を選びます参考ダウンロードされたCSVファイルはUTF-8形式です。Windows版のExcelで開くと文字化けすることがありますので、データの読み込みでご対応ください。参考(外部サイト): Excel2016(Excel2019)で文字化けするUTF-8のCSVファイルを開く：エクセルの使い方