Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
管理者によるエンドユーザーのSSOクラウドデバイス承認
管理者管理コンソールからの管理者承認方法
[管理者の承認]を選択すると、[デバイスの承認]の権限を持つKeeper管理者にリクエストが送信されます。 管理者は、管理コンソールの[承認待ち]画面から、またはリクエスト時に管理コンソールにログインして承認できます。
(1) ユーザーが[管理者承認]を選択します
(2) 承認を待つか、後ほど戻ります。
(3) 管理者が管理コンソールにログインし、[承認待ち]にアクセスします。
(4) 管理者が情報を確認し、デバイスを承認します。
承認するデバイスを選択し、[承認]をクリックします。 ユーザーが待機している場合は、即座にログインが許可されます。そうでない場合、ユーザーは承認なしで後ほどログインできます (ウェブブラウザのキャッシュをクリアしたりアプリをリセットしたりしない場合)。
管理者は、「デバイスの承認」と呼ばれる特別な役割権限によりデバイスを承認できます。
(1) ルートノードまたはSSOノード内の[役割]へ移動します。
(2) 歯車アイコンを選択して、選択した役割の管理者権限を制御します。
(3) 「デバイスの承認」権限を割り当てます。
これで、この役割に追加されたユーザーは誰でも管理コンソールにログインしてデバイスを承認できるようになります。
他の管理権限と同様に、権限は最小限にするようにしてください
SSOクラウドのデバイス承認システム
デバイス承認はSSO Connect Cloudプラットフォームで必須となる要素です。 承認は、ユーザーまたは管理者が実行することも、Keeper Automator サービスを使用して自動的に実行することもできます。
Keeper SSO Connect Cloudで認証するカスタマーの場合、デバイスの承認によりキー転送が実行され、ユーザーの暗号化されたデータキーがデバイスに届けられてから楕円曲線秘密キーを使用してローカルで復号化されます。
Keeper SSO Connect Cloudでは、どのSAML 2.0IDプロバイダを使用しても簡潔なログイン処理を維持しつつゼロ知識暗号化を実現できます。
過去に使用したことのないデバイスでログインしようとすると、楕円曲線暗号の秘密鍵と公開鍵のペアが新しいデバイスで生成されます。 IDプロバイダの認証に成功すると、ユーザーが新しいデバイスでボルトを復号化できるように鍵交換を実行する必要があります。これを「デバイス承認」と呼びます。
ブラウザでゲストモード、プライベートモード、またはシークレットモードを使用すると、ブラウザを起動するたびに新しいデバイスとしてKeeperに識別されるため、デバイス承認が新たに必要になります。
ゼロ知識を維持し、Keeperのサーバーが暗号鍵に一切アクセスできないようにするために、ユーザーまたは指定された管理者が実行できるプッシュ通知による承認方式を開発しました。また、Keeperを使用するとデバイス承認と鍵交換を自動的に実行するサービスをホストできるため、ユーザーの操作は一切不要となります。
デバイス承認方式には以下が含まれます。
既存のユーザーデバイスへKeeper Push(プッシュ通知)
管理コンソールからの管理者承認
Keeper Automatorサービスを使用した自動承認(推奨)
Commander CLIを介した半自動の管理者承認
既存のデバイスを使用するSSOデバイス承認方法
ユーザーは以前に承認されたデバイスを使用して追加のデバイスを承認できます。たとえば、すでにコンピュータでウェブボルトにログインしている状態で初めて携帯電話アプリにログインする場合、ウェブボルトにデバイス承認プロンプトが表示され、その携帯デバイスを承認したり拒否したりできます。デバイス承認により暗号化キーの交換を実行して新しいデバイスでボルトを復号化できるようにします。
Keeperプッシュ通知は、ユーザーが自ら処理する承認方式です。[Keeper プッシュ通知]を選択すると、ユーザーの承認済みデバイスに通知が送信されます。携帯アプリおよびデスクトップアプリの場合、プッシュ通知はポップアップとして表示され、簡単にデバイスを承認できます。
以下は、携帯電話を承認用デバイスとして使用したKeeperプッシュ通知承認の例となります。
[Keeperプッシュ通知]を選択します。
ログイン済みのデバイスにプッシュ通知による承認が表示されるのを待ちます。
ユーザーが通知を受信するには、以前に承認済みの別のデバイスにすでにログインしている状態でなければなりません。
Keeper Auatomator向けイングレス設定
Keeper Automatorは、オンプレミス、クラウド、サーバーレスなど、さまざまな方法で導入できます。
ファイアウォールの受信トラフィックルールで以下のいずれかのルールセットを設定します。
USデータセンターをご利用のお客様
54.208.20.102/32
からインバウンドTCPポート443
34.203.159.189/32
からインバウンドTCPポート443
US / GovCloudデータセンターをご利用のお客様
18.252.135.74/32
からインバウンドTCPポート443
18.253.212.59/32
からインバウンドTCPポート443
EU / ダブリンデータセンターをご利用のお客様
52.210.163.45/32
からインバウンドTCPポート443
54.246.185.95/32
からインバウンドTCPポート443
AU / シドニーデータセンターをご利用のお客様
3.106.40.41/32
からインバウンドTCPポート443
54.206.208.132/32
からインバウンドTCPポート443
CA / カナダデータセンターをご利用のお客様
35.182.216.11/32
からインバウンドTCPポート443
15.223.136.134/32
からインバウンドTCPポート443
JP / 東京データセンターをご利用のお客様
54.150.11.204/32
からインバウンドTCPポート443
52.68.53.105/32
からインバウンドTCPポート443
加えて、テストやヘルスチェックの目的でオフィスネットワークからのトラフィックを許可しても良いでしょう。
Keeperのデータセンター地域に基づいて、記載のIPアドレスごとにルールを作成してください。
SSO Connect Cloud環境を使用した認証に基づく、自動デバイス承認サービス
Keeper Automatorは任意で選択できるサービスで、SSO IDプロバイダーからのログイン成功時に即時デバイスの承認、チームの承認、およびチーム ユーザーの割り当てを実行します。
Automatorが実行されると、ユーザーは ID プロバイダーによる認証に成功した後それ以上の承認手順を踏まずに、新しい (まだ承認されていない) デバイス上のKeeperにそのままアクセスできます。
Automatorサービスが設定されていない場合でも、ユーザーと管理者はプッシュ承認を通じてデバイスの承認実行できます。
Keeper Automatorは、さまざまな方法でクラウドまたはオンプレミス環境に展開できる軽量のサービスです。
Keeper SSO Connectは、IDプロバイダを使用してKeeperボルトへそのまま認証します。通常、新しいデバイスはユーザー自身が承認するか、管理者がユーザーの代わりに新しいデバイスを承認する必要があります。Automatorサービスはデバイスの承認に関連する煩わしい操作をすべて解消したいと考える管理者のために作成された任意で選択できるサービスとなります。
ゼロ知識を維持し、暗号化されたデータキー(EDK)のユーザーデバイスへの転送を自動化するには、サービスをKeeper側でホストするのではなく、 企業側で運用するサービスとして実行する必要があります。このサービスには様々な実行方法があり、クラウドでもセルフホストでも実行可能です。
ご利用の環境に応じて以下のインストール方法からお選びください。Azure Container AppとAWS Elastic Container Serviceのどちらかをご利用の場合はそちらの方法が最善となります。
Automatorをv3.2にアップグレードする手順
バージョン3.2以降では以下の新機能がご利用になれます。
チームの承認(チーム作成)
チームユーザーの承認(ユーザーをチームに割り当てる)
すべての設定が環境変数として構成可能
HTTPSセキュリティを向上させるHSTSが有効
デバイス承認用とチーム承認用のIPアドレスフィルタリング
すべてのAPIに対して任意でレート制限
メールドメインによる任意のフィルタリング
任意で特定のネットワークIPへのバインド
バージョン 3.2 では、チームの承認とチームユーザーの承認が導入されました。これは、SCIM を通じてプロビジョニングされ、チームに追加されたユーザーについては、管理者がコンソールにログインするのを待つことなくAutomatorサービスによって即座に処理できることを意味します。
この新機能を有効にするには以下を行います。
Automator コンテナを最新バージョンに更新します
Keeper Commanderからautomator edit
コマンドを使用してデバイスの承認およびチーム ユーザーの承認を行います
例:
スキルを有効にした状態では、ユーザーがボルトにログインする際にAutomatorが発動してチームユーザーが承認されます。
IDプロバイダからSCIMメッセージングでチームの作成がリクエストされた際、誰かが (ゼロ知識を保持するために) 暗号化キーを生成するまで、リクエストが完全に処理されることはありません。通常は、管理者がKeeper 管理コンソールにログインするときに処理されます。
チームは、チームのユーザー少なくとも 1 人がボルトにログインするまで環境には表示されません。
これにより、設定ファイルへのアクセスが難しい Azure コンテナーまたは他の Docker のようなコンテナーに Automator をインストールする場合の構成が簡単になります。
docker-compose.yml
ファイルを使用するDockerやAzure Containersなどの環境では、以下のようにdocker composeファイルに環境変数を設定できます。
docker-compose.yml
ファイルの編集後に環境変数が変更されている場合、コンテナを再構築する必要があります。 コンテナを再起動しただけでは変更は反映されません。
SSO Connect暗号化モデルの詳細な説明は、されています。
Automatorサービスを使用するとユーザー体験は向上しますが、IDプロバイダーは完全に保護されている必要があります。Keeper環境を保護するためのをご参照ください。
簡素化された展開に対応
簡素化された展開に対応
Automatorサービスの詳細については、をご参照ください。
Azure App Servicesでデプロイ
本ページでは、Azure App Services内でKeeperオートメーターをウェブアプリとしてインスタンス化する手順を解説します。GCC HighやDoDなどの環境では、オートメーターをホストするのにこのサービスを利用いただけます。
コマンドラインを開き、オペレーティングシステムに応じて次のいずれかの方法を使用してURLエンコード形式で256ビットAESキーを生成します。
このコマンドによって生成される値を手順 6のために保存します。
Azureポータルから、検索バーで「App Services」を選択し、「+Create」から「+ Web App」を選択して新しいウェブアプリを作成します。
新しい「Resource Group」を作成します。
「Instance」に名前を付けます。
Publishに「Docker Container」を選択します。
Operating Systemに「Linux」を選択します。
サービスをホストする地域を選択します。
ご利用のLinux Planを選択するか新しいプランを作成します。最も低価格の料金プランは「Premium V3 P0V3」ですが、エンドユーザー環境にもよります。
Docker の箇所へ進みます。
Dockerでは以下のように設定します。
Options: Single Container
Image Service: Docker Hub
Access Type: Public
Image and tag: keeper/automator:latest
Monitoringの箇所へ進みます。
「Enable Application Insights」には「Yes」を選択します。
「Application Insights」を選択するか、新規で作成します。
「Review + create」の箇所へ進みます。
「Review + Create」、「Create」の順にクリックします。
数分後、WebAppが作成され、自動的に起動します。
「Go to Resource」をクリックしてコンテナ環境へ移動します。
デフォルトのドメイン値をメモしておきます。これはオートメーターサービスのセットアップと初期化の際に必要になります。
Configurationへ移動し、「New application setting」を選択します。
環境変数の設定は、以下のように左側メニューの「Environment variables」の箇所で行う場合があります。
以下のアプリケーション設定を追加します。
以下の環境変数を作成し、それぞれの値に設定します。
AUTOMATOR_CONFIG_KEY: 手順1からの値
AUTOMATOR_PORT: 8089
SSL_MODE: none
WEBSITES_PORT: 8089
[Apply]をクリックします。
[Diagnostic settings]を選択し、「+ Add diagnostic setting」をクリックします。
診断設定に名前を付けます。
[App Service Console logs]を選択します。
[App Service Application logs]を選択します。
[Send to Log Analytics workspace]を選択します。
Log Analyticsを選択するか、新規で作成します。
メイン メニューから[Logs]を選択します。[X]をクリックしてクエリウィンドウを閉じます。
以下は、Dockerデプロイメントと起動ログを見る手順となります。
AppServicePlatformLogs
以下は、アプリケーションエラーログを見る手順となります。
AppServiceConsoleLogs
メインメニューの「Monitoring」の箇所から[App Service Logs]を選択します。次に、「Application logging」の[File System]を選択し、任意の保持期間を設定します。
[Save]をクリックします。
メインメニューの「Overview」から[Log Stream]を選択し、オートメーターサービスが接続され、正しくログが記録されていることを確認します。
メイン メニューの「Monitoring」から[Health check]を選択します。次に、ヘルス チェック機能を有効にし、パスの値を「/health」に設定します。[Save]をクリックして設定を保存し、もう一度[Save] をクリックして変更を確定します。
Networkingの箇所で簡単なアクセスルールを設定したり、Azure Front Doorを構成したりできます。 メインメニューか[Networking]を選択し、[Enable with no access restrictions] (アクセス制限なしで有効にする) をクリックします。
[Access Restrictions]で、[Enabled from select virtual networks and IP addresses] (選択した仮想ネットワークとIPアドレスを有効にする) を選択し、[Unmatched rule action] (一致しないルールアクション)を[Allow]にします。[+ Add]をクリックして、受信アクセスルールを追加します。
「Add rule」 (ルールの追加) で、受信ファイアウォールルールを追加します。以下のページをご参照の上、それぞれの地域で「Connection verification only」 (接続検証のみ) となっているKeeper公開IPアドレスへのトラフィックを制限する必要があります。
[Add rule]をクリックします。
[Save]をクリックして構成を保存します。
インストール後、Keeperコマンダーを起動するか、既存のターミナルからkeeper shellと入力してセッションを開き、login
コマンドを使用してログインします。オートメーターを設定するには、Keeper管理者またはSSOノードを管理できる管理者としてログインする必要があります。
automator create
から始まる一連のコマンドを使用してオートメーターを作成します。
ノード名 (この場合は「Azure Cloud」) は、以下のように管理コンソールUIから取得します。
コマンドを実行すると、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。
「URL」はまだ入力されていないことにご留意ください。これは、手順5のDefault Domainの値です。
以下のように、「automator edit」コマンドを実行します。これにより、URL が設定され、スキル (team
、team_for_user
、device
) も設定されます。
次に、キーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーが オートメーターに提供されます。
新しい構成でオートメーターを初期化します。
サービスを有効にします。
この時点で構成は完了となります。
外部のヘルスチェックについては以下のURLをご使用ください。
https://<server>/health
以下は curl
コマンドの例となります。
Keeperオートメーターがデプロイされましたので、ユーザー体験をテストできます。ユーザーが SSO IDプロバイダで認証した後は、承認を求めるプロンプトが表示されなくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されません。
Azure App Gatewayサービスを使用してKeeper AutomatorをAzure Container Instancesにデプロイ
本ガイドでは、Azure Application Gatewayを使用して安全なVNetでKeeper Automatorを公開するための手順を解説します。この方式は、Azureコンテナーアプリの設定よりも高度となりますので、Azure App Gatewayや暗号化されたSAMLリクエストを使用する必要がない場合は、Azureコンテナーアプリ方式をご使用ください。
この方式では、すでにSSL証明書をお持ちであることを確かにしてください。お持ちでない場合は、カスタムSSL証明書ページの手順をご参照ください。
(1) Azureクラウドシェルを開く
portal.azure.comにログインし、クラウドシェルのアイコンをクリックします。
(2) ご希望の地域でリソースグループを作成
Azureにリソースグループがまだ存在しない場合は作成します。こちらの例ではeastusの地域を使用していますが、必ずお客様の地域をご使用ください。
ストレージアカウントがまだ存在しない場合は作成します。正しい地域(useeast)と上のリソースグループ名を使用するようにします。注: keeperautomatotorstorageを置き換えるのに選択する名前は、azureではグローバルで他に存在しないものである必要があります。
ファイルシェアが存在しない場合は作成します。
現在のシェアを表示します。
(5) コンテナー用にバーチャルネットワーク(VNet)と1件のSubnetを作成
(6) バーチャルネットワークをサービスエンドポイントで更新
アカウントのストレージキーを見つけるには以下のコマンドを使用します。 ストレージアカウント名は実際の名前に置き換えます。
以下のようなkey1の値をコピーします。
(8) サブネットIDの取得
サブネットIDを見つけるには以下のコマンドを実行します。
サブネットIDのパスを _subnetで終わるところまで全部コピーします。以下はその例です。
ローカルで、automator
などの名前でフォルダを作成します。
任意のエディタを使用して、そのフォルダー内に以下の内容を含むautomator.ymlというファイルを作成します。
前の手順の設定に基づいて文字列の値を変更する必要がある箇所が複数あります。
サブネットID は、手順8で取得したIDのフルパスと一致する必要があります。
storageAccountNameは手順3の値と一致する必要があります。
storageAccountKeyは手順7の値と一致する必要があります。
(10) SSL証明書とSSLパスワードファイルのアップロード
Azureインターフェイスから、[リソース グループ] > [ストレージ アカウント] > [ファイルシェア]に移動し、作成したAutomatorファイルシェアに移動します。ここから、automator.ymlファイル、SSL証明書ファイル、SSL証明書パスワードファイルをアップロードします。
ファイルの名前が automator.yml ssl-certificate.pfx および ssl-certificate-password.txt であることを確認してください。
(11) 3つのファイルをローカルのCLIワークスペースにコピーします
(12) コンテナーインスタンスの作成
automator.ymlの設定を使用してコンテナーを作成します。
応答でコンテナの内部IPを取得します。
後で使用するために、このIPの変数を設定します。以下はその例となります。
(13) アプリケーションゲートウェイサブネットの作成
(14) アプリケーションゲートウェイの作成
XXXXXXの箇所でSSL証明書のパスワードが置き換えられていることを確かにします。
(15) パブリックIPを見つける
Azure portalのインターフェイスで、[リソースグループ] > [アプリゲートウェイ]に移動し、パブリックIP アドレスをメモします。
(16) DNSのルーティング
AutomatorサービスのDNS(例: automator.company.com)が、Azureコンテナーサービスが手順 15で生成したIPアドレスを指していることを確かにします。
DNS名は SSL 証明書のサブジェクト名と一致する必要があります。一致しない場合、リクエストは失敗します。
(17) 正常性プローブの作成
正常性プローブは、Automatorサービスが実行されていることをApp Gatewayに通知します。Azure portalのインターフェイスからAutomator App Gatewayを開き、左側のメニューから[正常性プローブ]をクリックします。
次に、以下のスクリーンショットに見られる設定で新しい正常性プローブを作成します。必ずホストを手順 6で設定したFQDNに置き換えます。
[テスト]をクリックしてプローブを追加します。コンテナIPがホスト名に適切にアドレス指定されていれば、テストは成功します。
(18) ウェブアプリケーションファイアウォールの設定
Azure portalのインターフェイスからAutomator App Gatewayを開き、左側の[ウェブアプリケーションファイアウォール] をクリックします。 WAF V2を有効にして以下の画面のように設定します。
[ルール]タブをクリックし、[OWASP 3.2]に設定されたルールを選択して、[有効]および[保存]をクリックします(重要な手順となります)。
最後にKeeper Commenderを使ってAutomatorの設定を行います。
(19) Keeper Commanderのインストール
この時点では、サービスは実行されていますがまだKeeperとは通信ができません。
ワークステーション、サーバー、コンピューターのどれかにKeeper Commander CLIをインストールします。初期設定にのみ使用します。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。 Commanderを開いた後、loginコマンドでログインします。AutomatorをセットアップするにはKeeper 管理者、またはSSOノードを管理する権限を持つ管理者としてログインする必要があります。
(20) Commanderでの初期設定
Keeper Commanderにログインし、automator createで始まる一連のコマンドを使用してAutomatorを有効にします。
ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールのUIから取得します。
コマンドの出力には、IDプロバイダからのメタデータを含むAutomator設定が表示されます。
URLはまだ入力されていません。選択したFQDNを使用してURLを編集します。
次に、キーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
新しい設定でAutomatorを初期化します。
サービスを有効にします。
この時点で設定は完了です。
自動ヘルスチェックには以下のURLをご使用になれます。
https://<server>/health
以下はcurl
コマンドを使用した例です。
当URLはWebブラウザでは開きません。
IDプロバイダとしてAD FSを使用してKeeper Automatorを有効にする場合、以下の手順に従ってKeeper 証明書を更新するまでログインできません。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。
これでAutomatorサービスが実行された状態になりました。
Azure Portalの「コンテナーインスタンス」システムで、コンテナーが実行されているのを確認できます。 /bin/shを使用してコンテナーに接続し、実行ログを表示することもできます。
この設定に基づいてコンテナーを再起動すると、/24サブネットから新しい IP アドレスが割り当てられることがあります。新しいIPをすばやく見つけて、正しいIPでApplication Gatewayバックエンドプールを更新するには、Azure CLIから以下のスクリプトを実行します。
Keeper Automatorがデプロイされましたので、エンドユーザー体験のテストが可能です。ユーザーが SSO IDプロバイダーで認証した後は、承認を求めるプロンプトは必要ありません。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトが表示されない場合、Automatorが正常に機能しています。
Azureコンテナーアプリでのデプロイ
本ページでは、KeeperオートメーターをAzure Container Appsサービスに公開するための手順を解説します。これにより、オートメーターサービスを簡単にクラウドでホストしていただけます。
Azure Government、GCC High、DoDなどの環境では、Azure Container Appsサービスがこれらのリージョンで利用できない可能性があるため、Azure App Services方式を使用します。
コマンドラインを開き、オペレーティングシステムに応じて次のいずれかの方法を使用してURLエンコード形式で256ビットAESキーを生成します。
このコマンドによって生成される値を手順 3のために保存します。
Azureから新しいコンテナーアプリを作成します。
新しいリソースグループを選択または作成します。
コンテナアプリ名をkeeperautatorまたは任意の名前に設定します。
サービスをホストしたい地域を選択します。
新しいアプリ環境を作成するか、既存の環境を選択します。
[次へ]: [コンテナ] >をクリックします。
コンテナーの手順では以下のように設定します。
[クイックスタートイメージを使用する]のチェックを外します
[Docker Hub または他のレジストリ]を選択します
[パブリック]を選択します
レジストリログインサーバーにdocker.io
を選択します
イメージを設定し、keeper/automator:latest
としてタグを付けます
CPUとメモリについては、0.5 CPUコアと1Gi メモリで十分ですが、新しいデバイスのログイン量に基づいて変更できます
上記の手順1の値を使用してAUTOMATOR_CONFIG_KEY
という環境変数を作成します
8089の値を使用してAUTOMATOR_PORT
という環境変数を作成します
noneの値でSSL_MODE
という環境変数を作成します
[次へ]: バインド >をクリックします
[次へ]: イングレス > をクリックします
イングレスセットアップ画面で以下を選択します。
イングレスを有効(
Enable
)
にします
イングレスのトラフィックをAccepting traffic from anywhere
にします(後ほど変更します)
イングレスタイプをHTTP
にします
ターゲットポートを8089
に設定します
[Review + Create]をクリックしてから[Create]をクリックします。
数分後、コンテナーアプリが作成され自動的に起動します。
[リソースに移動]をクリックするとコンテナー環境に移動します。
Keeperオートメーターサービスへの通信を制限するには、画面左側の[Ingress]リンクをクリックします。
[Ingress]をクリックします。
[Allow traffic from IPs configured below, deny all other traffic]を選択します。
[Add]をクリックしてKeeperの2つのIPとテストに必要なIPをどれか追加します。
[Save]をクリックします。
ヘルスチェックの実行をご希望の場合は、ご自身のIPアドレスを追加します。ご自身のIPアドレスについては、https://checkip.amazonaws.comにてご確認になれます。
Azureがゼロインスタンスにダウンスケールしないようにするには、インスタンスの最小数を1に設定することが重要となります。
[Application]の下の[コンテナー]セクションへ進みます。
上部の[Scale]セクションをクリックし、「Min replicas」と「Max replicas」を1に設定します。
[Container]タブをクリックします。
下部の「keeperautomator」リンクをクリックします。
[Liveness probes]の箇所で以下のように設定します。
Enable liveness probesをチェック
Transport: HTTP
Path: /health
Port: 8089
Initial delay seconds: 5
Period seconds: 30
[Startup probes]の箇所で以下のように設定します。
Enable startup probesをチェック
Transport: HTTP
Path: /health
Port: 8089
Initial delay seconds: 5
Period seconds: 30
[Volume Mounts]のタブで以下のように設定します。
[Create new volume]をクリックします。
「Ephemeral Storage」を選択します。
Volume nameをautomatordata
にします。
Mount Pathを/usr/mybin/config
にします。
設定を完了します。
[保存]をクリックします。
[Create]をクリックして新しい設定を作成します。
数分後に新しいコンテナーが起動します。
コンテナーアプリの概要の右側に、割り当てられた「アプリケーションURL」が表示されます。このURLをコピーして次の手順で使用します。
(例: https://craigautomator1.xyx-1234.azurecontainerapps.io)
オートメーター設定の最後の手順を行うのに、Keeperコマンダーが必要となります。どこからでも実行でき、サーバーにインストールする必要はありません。
automator create
で始まる一連のコマンドを使用してオートメーターを作成します。
ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。
コマンドの出力には、IDプロバイダからのメタデータを含むAutomator設定が表示されます。
URLはまだ入力されていないことにご留意ください。手順8のアプリケーションURLとなります。
以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。
新しい設定でオートメーターを初期化します。
サービスを有効にします。
この時点で設定は完了となります。
外部ヘルスチェックには以下のURLをご使用になれます。
https://<server>/health
以下はcurl
コマンドを使用した例です。
Keeperオートメーターがデプロイされましたので、ユーザー体験をテストできます。ユーザーが SSO IDプロバイダで認証した後は、承認を求めるプロンプトが表示されなくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されません。
Azureコンテナーアプリにはこの資料には含まれていない多くの高度な機能があります。以下はその一部となります。
複数のコンテナでKeeperオートメーターサービスを実行したい場合は以下を行います。
[Scale and replicas]をクリックします。
[Edit and deploy]をクリックします。
[Scale]タブをクリックします。
コンテナーの最小数および最大数を選択します。最小数は少なくとも1にします。
[Create]をクリックします。
1分後に新しいバージョンがデプロイされます。
コンテナーの数に応じて何度かautomator setup xxx
を実行します (コンテナーにつき1回)。
コンテナーの数に応じて何度かautomator init xxx
を実行します (コンテナーにつき1回)。
Keeperオートメーターのログは、「コンソール」または「ログストリーム」を使用して表示および監視できます。
たとえば、実行中のオートメーターサービスのログファイルを追跡するには以下のようにします。
コンソールをクリックします。
「/bin/sh」を選択します。
Connectをクリックします。
プロンプトが表示されるとtail -f logs/keeper-automator.log
と入力します。
環境変数をコンテナに渡してランタイム環境の機能を有効にしたり無効にしたりできます。変数およびその説明については、高度な設定ページをご覧ください。
スタンドアロンJavaサービスを使用したKeeper Automatorの実装例
本ガイドでは、Dockerを実行できるLinuxインスタンスでKeeper Automatorを実行するための手順を解説します。
サービスの準備としてJava 17以上がインストールされていることを確かにします。標準のAmazon AWS Linux 2インスタンスでは、以下のコマンドを使用してJava 17 SDKをインストールできます。
どのバージョンが実行中かを確認するには、以下のように入力します。
Automatorインスタンスから、Keeper Automatorサービスをダウンロードして解凍します。
このフォルダが存在しない場合は、解凍先にconfigフォルダを作成します。
以下は、scpを使用した例です。
ssl-certificate.pfx
ファイルがパスフレーズで保護されている場合は、ssl-certificate-password.txt
という名前のファイルも作成して、dockerコンテナにコピーする必要があります。
以下に例を示します。
Automatorインスタンスから、java -jar
を使用してサービスを開始します。以下の例では、nohup
を使用してバックグラウンドで実行します。
Windowsのコマンドラインまたはpowershellでは、コマンドは以下の記載通りに実行する必要があります。
サービスが実行中であることをウェブブラウザで確認します(テストしているデバイスからポート 443を開く必要があります)。 この場合、URLはhttps://<server>/healthとなります。
このURLは自動ヘルスチェックにもご使用になれます。
以下に例を示します。
サービスは実行中となりましたので、Keeper Commanderを使用してAutomatorをご利用の環境に統合します。
Keeper CommanderでAutomator設定の最後の手順を実行する必要があります。これはどこからでも実行可能で、サーバーにインストールする必要はありません。
Keeper Commanderにログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効化します。
ノード名(この場合は、「Azure Cloud」)は、以下に示すように管理コンソールのUIに表示されます。
コマンドの出力には、IDプロバイダから取得したメタデータを含むAutomatorの設定が表示されます。
以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
次に、他のIdPメタデータをAutomatorに送信します。
Automatorサービスを有効にします。
この時点で設定は完了となります。
IDプロバイダとしてAD FSを使用してKeeper Automatorを有効にする場合、以下の手順に従ってKeeper 証明書を更新するまでログインできません。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。
Keeper Automatorがデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。
Keeper Automatorサービスを停止/開始する場合、あるいはサーバーを再起動する場合は、Keeper Commanderを使用してサービスエンドポイントを再初期化する必要がある場合があります。
Keeper Automatorのログを確認してください。通常これで問題がわかります。Linuxではログはインストールディレクトリにあります。
Keeper CommanderでAutomatorインスタンスを再初期化するのに必要なコマンドは以下のとおりです。
AWS ECS (Fargate)サービスでKeeper Automatorを使う
この例では、必要最小限の依存関係で最も簡単な方法でAmazon ECSでKeeper Automatorサービスを起動する方法について解説します。
要件:
AWSを介したマネージドSSL証明書
オペレーティングシステムに応じて以下のいずれかの方法を使用してURL エンコード形式で256ビットAESキーを生成します。
タスク定義に設定された環境変数としてこの値を保存します。
VPCが存在しない場合は、複数のサブネット、ルートテーブル、インターネットゲートウェイを持つ基本的なVPCをセットアップする必要があります。こちらの例では、以下のリソースマップに見られるようにインターネットゲートウェイを備えたVPC内に3つのサブネットがあります。
ログをキャプチャしたい場合 (推奨)、[CloudWatch] > [ロググループの作成]に移動します。
ロググループにautomator-logsという名前を付けます。
[IAM] > [ロールの作成]へ行きます。
[AWSサービス]を選択します。
次に、Elastic Container Serviceを検索して選択します。
[Elastic Container Serviceタスク]を選択し、[次へ]をクリックします。
[AmazonECSTaskExecution]ポリシーをロールに追加し、[次へ]をクリックします。
ECSTaskWritetoLogsという名前を割り当てて、ロールを作成します。
次の手順で使用するため、このロールのARNをメモしておきます。
本事例ではarn:aws:iam::373699066757:role/ECSTaskWritetoLogs
となります。
[EC2] > [セキュリティ グループ]に移動し、[セキュリティグループの作成]をクリックします。
Keeperテナントがホストされている地域に応じて、Keeperクラウドからのhttpsポート443を許可する受信ルールを作成する必要があります。各テナントの場所のIPのリストについては以下をご覧ください。以下の例では米国データセンターとなります。
また、テストとトラブルシューティングのためにワークステーションの外部IPアドレスを追加することを推奨します。
MyAutomatorServiceなどの名前を割り当て、[作成]をクリックします。
以下のURLから見つけられるご自身のIPを忘れずに追加してください。
セキュリティグループを保存した後、受信ルールを再度編集します。 今回は以下の内容を追加します。
ソースがセキュリティ グループに設定された状態のHTTPポート8089 を追加します。これにより、ALBからネットワーク内のコンテナへのトラフィックとヘルスチェック処理が可能となります。
Amazon Elastic Container Serviceへ進みます。
[クラスターの作成]を選択し、クラスター名とVPCを割り当てます。 こちらの例では、デフォルトの[AWS Fargate (サーバーレス)]インフラストラクチャを使用しています。
デフォルトの名前空間はautomatorで問題ありません
[インフラストラクチャ]は AWS Fargate(サーバーレス)に設定します
[作成]をクリックします
任意のテキストエディタで、以下のJSONタスク定義ファイルをコピーして保存します。
重要: JSONファイルに以下の変更を加えます。
24行目の XXX (REPLACE THIS) XXX を上記の手順1で作成した秘密キーに変更します。
37行~39行を手順3のロググループの名前と場所に置き換えます。
44行目のXXXをAWSロールに固有のロールIDに変更します(手順4の373699066757)。
次に、[Elastic Container Service] > [タスク定義] > [JSONからタスクを作成]に移動します。
既存のJSONを削除し、変更したJSONファイルをボックスにコピーして貼り付け、[作成] をクリックします。
このタスク定義は、インスタンスのCPU/メモリ要件に応じて変更できます。
AWSのアプリケーションロードバランサーが Automatorのクエストに対応するには、SSL 証明書が AWS Certificate Managerによって管理されている必要があります。AWSが管理する証明書をインポートするか作成します。
AWSコンソールから[Certificate Manager]を開きます。
[リクエスト]をクリックします。
パブリック証明書をリクエストし、[次へ]をクリックします。
automator.lurey.comなど、Automatorサービスのドメイン名を入力します。
任意の検証方式とキーアルゴリズムを選択します。
[リクエスト]をクリックします。
証明書の一覧から証明書リクエストをクリックします。
Route53を使用してドメインを管理している場合は証明書をクリックし、[Route53でレコードを作成]を選択するとドメインが即座に検証され証明書が作成されます。別のDNSプロバイダーを使用する場合は、画面に見られるようにCNAMEレコードを作成する必要があります。
CNAMEレコードを作成すると、ドメインは数分以内に有効となります。
この証明書は、手順11でアプリケーションロードバランサーを作成する際に参照されます。
[EC2] > [ターゲットグループ]に移動し、[ターゲットグループの作成] をクリックします。
ターゲットの種類として[IPアドレス]を選択します。
ターゲットグループ名にautomatortargetgroupまたは任意の名前を入力します。
ポート8089のHTTPプロトコルを選択します。
ECSクラスターを含むVPC を選択します。
HTTP1を選択します。
[ヘルス チェック] で、ヘルスチェックプロトコルとして[HTTP]を選択します。
ヘルスチェックのパスとして/health
と入力します。
[ヘルスチェックの詳細設定]を展開します。
[オーバーライド]を選択し、ポート8089を入力します。
[次へ]をクリックします。
まだターゲットを選択せずに[ターゲットグループの作成]をクリックします。
[EC2] > [ロードバランサー] > [ロードバランサーの作成]に移動します。
[Application Load Balancer] > [作成]を選択します。
automarnalbなどの任意の名前を割り当てます。
スキームはInternet-facingとなります。
IPアドレスの種類: IPv4
[ネットワークマッピング]の箇所で、ECSサービスをホストするVPCとサブネットを選択します。
セキュリティグループで、手順4で作成したMyAutomatorServiceを選択します。
[リスナーとルーティング]の箇所でHTTPSポート443を選択し、ターゲットグループで前の手順で作成したターゲットグループ(automatortargetgroup)を選択します。
[セキュアリスナー設定]で、手順9でAWS Certificate ManagerにアップロードしたACMからのSSL証明書を選択します。
[ロードバランサーの作成]をクリックします。
[Elastic Container Service] > [タスク定義] > 手順8で作成したタスクを選択します。
このタスク定義から、[デプロイ] > [サービスの作成]をクリックします。
automatorの既存のクラスターを選択します。
サービス名にautomatorserviceまたは任意の名前を割り当てます。
必要なタスクの数については、とりあえず1に設定します。設定が完了後に実行したいタスクの数を増やせます。
[ネットワーク]でVPCとサブネットを選択し、既存のセキュリティグループを手順4で作成した ECSセキュリティグループに置き換えます。この場合はMyAutomatorServiceとなります。
パブリックIPONにします。
[ロードバランシング]で、ロード バランサーの種類として[Application Load Balancer]を選択します。
既存のロードバランサーを使用し、手順11で作成したautomatralbを選択します。
既存のリスナーを使用し、443:HTTPSリスナーを選択します。
既存のターゲットグループを使用し、手順10のターゲットグループを選択します。
ヘルスチェックのパスを/healthに設定します。
ヘルスチェックプロトコルをHTTPに設定します。
[作成]をクリックします。
数分後にサービスが起動します。
DNS名がRoute53によってホストおよび管理されていると仮定します。
Route53 > レコードの作成または編集に移動します。
Aレコードを作成します。
エイリアスとして設定します。
トラフィックを[アプリケーションおよびクラシックロードバランサーへのエイリアス]にルーティングします。
AWS地域を選択します。
automaticalbアプリケーションロードバランサーを選択します
[シンプルルーティング]を選択します。
[保存]を選択します。
次の手順では、タスクを1件だけ実行した状態でKeeper Commanderを使用してAutomatorを設定します。
この時点ではサービスは実行されていますが、まだKeeperと通信できない状態です。
Commanderをインストールした後、keeper shell
と入力してセッションを開いてからlogin
コマンドを使用してログインします。Automatorをセットアップするには、Keeper管理者またはSSO ノードを管理する権限を持つ管理者としてログインする必要があります。
ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。
コマンドの出力には、IDプロバイダからのメタデータを含むAutomator設定が表示されます。
以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
新しい設定でAutomatorを初期化します。
サービスを有効にします。
この時点で設定は完了となります。
自動ヘルスチェックには以下のURLをご使用になれます。
https://<server>/health
以下はcurl
コマンドを使用した例です。
本セットアップ例では、ロードバランサーはHTTP ポート8089経由でターゲットインスタンスにヘルスチェックを転送します。
Keeper Automatorが1件のタスクを実行した状態でデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。
承認が機能しましたので、実行するタスクの数を増やせます。
Keeper Automatorサービスは、処理するリクエストの数が少ないため単一のコンテナ上で問題なく快適に実行できます。ただし、複数のコンテナを実行したい場合は以下の手順に従ってください。
ECSサービス画面からautomatorserviceをクリックします。
[サービスを更新]をクリックします。
[新規デプロイメントを強制]するのチェックボックスを選択します。
最新のタスクリビジョンが選択されていることを確かにします。
[必要なタスク]を実行したいコンテナの数に設定します。
[更新]をクリックします。
数分後、新しいコンテナがデプロイされます。すべてのコンテナがアクティブになるまで待ちます。
Keeper Commanderを起動します(あるいはまだ開いたままである可能性があります)。
各コンテナーに対して、Automatorセットアップ、初期化、有効化を実行する必要があります。
以下は3つのコンテナが実行されている場合となります。
Automatorログは、ECSサービスの[ログ]タブまたはCloudWatchで検索およびモニターできます。
ECS (Fargate)サービスを使用してKeeper Automatorを実行し、機密情報のストレージとして Keeper Secrets Managerを実行
本ガイドでは、Fargateを使用してAmazon ECSでKeeper Automatorサービスを起動する方法について解説しながら、公開されたDockerコンテナのシークレット設定を取得するためにKeeper Secrets Managerを使用する方法を解説します。
本デプロイでは、Keeper Secrets Managerを使用する必要があるため、Automatorサービスを公開するためにKeeperボルトおよびSSL証明書を設定するために必要な手順を確認します。
この手順が完了すると、ssl-certificate.pfx
とssl-certificate-password.txt
の2つのファイルが作成されます。
ボルト内に共有フォルダを作成します。このフォルダーは、シークレットマネージャーアプリケーション以外の誰にも共有されません。
共有フォルダに記録を作成し、記録UIDをメモします。SSL証明書とSSL証明書パスワードファイルを共有フォルダの記録にアップロードします。
以下の内容のkeeper.propertiesという新しいファイルをアップロードします。
disable_sni_check=trueは、マネージドロードバランサーでAutomatorサービスを実行する場合に必要になります。
共有フォルダと記録は以下のようになります。
共有フォルダを編集し、Automatorアプリケーションをこのフォルダに追加します。
Secrets Managerアプリケーションを開き、[デバイス]タブをクリックして、[デバイスの追加]をクリックします。Base64設定を選択します。この設定をダウンロードして保存し、ECSタスク定義で使用できるようにします。
VPCが存在しない場合は、複数のサブネット、ルートテーブル、インターネットゲートウェイを持つ基本的なVPCをセットアップする必要があります。こちらの例では、以下のリソースマップに見られるように、インターネットゲートウェイを備えたVPC内に3つのサブネットが含まれています。
[CloudWatch] > [ロググループの作成]に移動します。
ロググループをautomator-logsと名付けます。
[IAM] > [ロールの作成]へ行きます。
[AWSサービス]を選択します。
次に、Elastic Container Serviceを検索して選択します。
[Elastic Container Serviceタスク]を選択し、[次へ]をクリックします。
[AmazonECSTaskExecution]ポリシーをロールに追加し、[次へ]をクリックします。
ECSTaskWritetoLogsという名前を割り当てて、ロールを作成します。
このロールのARNをメモして次の手順で使用できるようにします。
本事例ではarn:aws:iam::373699066757:role/ECSTaskWritetoLogs
となります。
[EC2] > [セキュリティ グループ]に移動し、[セキュリティグループの作成]をクリックします。
Keeperテナントがホストされている地域に応じて、Keeperクラウドからのhttpsポート443を許可する受信ルールを作成する必要があります。各テナントの場所のIPのリストについては以下をご覧ください。以下の例では米国データセンターとなります。
また、テストとトラブルシューティングのためにご使用のワークステーションの外部IPアドレスを追加することを推奨します。
MyAutomatorServiceなどの名前を割り当て、[作成]をクリックします。
セキュリティグループを保存した後、受信ルールを再度編集します。今回はHTTPSポート443を追加し、ドロップダウンでセキュリティグループを選択します。これにより、ロードバランサーは状況を監視してトラフィックを分散できるようになります。
クラスターからEFSへのNFSアクセスを制御する別のセキュリティグループを作成します。
[EC2] > [セキュリティ グループ]に移動し、[セキュリティグループの作成]をクリックします。
MyAutomatorEFSのように名前を設定します。
NFSのタイプを選択してカスタムを選択してから、ECSクラスターの前の手順で作成したセキュリティ グループを選択します。
[セキュリティグループの作成]をクリックします。
次の手順のためにセキュリティグループIDをメモしておきます。この場合はsgr-089fea5e4738f3898
となります。
現在、Automatorサービスは2つの異なるフォルダにアクセスする必要があります。本セットアップ例では、SSL証明書とSSLパスフレーズファイルを保存するために1つのボリュームを作成しています。2つ目のボリュームには、Automatorサービスのプロパティファイルが保存されます。これら3つのファイルはKeeperの記録に含まれています。
[AWS] > [Elastic File System]に移動し、[ファイルシステムの作成]をクリックします。
automator_configと名付けて、[作成]をクリックします。
再び[Elastic File System]に移動し、[Create file system]をクリックします。automator_settingsと名付けて[作成]をクリックします。
表示されるファイルシステムID(fs-xxxなど)は、ECSタスク定義で使用されます。
1 分後、2 つのファイルシステムが使用可能になります。それぞれをクリックしてから[ネットワーク]タブを選択し、[管理]をクリックします。
各サブネットのセキュリティグループを上記の手順で作成したもの(MyAutomatorEFSなど)に変更し、[保存]をクリックします。作成された両方のファイルシステムに同じネットワーク変更を加えます。
Amazon Elastic Container Serviceへ進みます。
[クラスターの作成]を選択し、クラスター名とVPCを割り当てます。 こちらの例では、デフォルトの[AWS Fargate(サーバーレス)]インフラストラクチャを使用しています。
デフォルトの名前空間はautomatorで問題ありません
[インフラストラクチャ]は AWS Fargate(サーバーレス)に設定します
[作成]をクリックします
任意のテキストエディタで、以下のJSONタスク定義ファイルをコピーして保存します。
JSONファイルに以下の変更を加えます。
本ガイドの冒頭で作成したKeeper Secrets ManagerのXXXCONFIGXXX値をBase64設定に変更します。
3箇所あるXXXXXを、KSMがアクセスしているボルトの共有フォルダ内のSSL証明書、SSL証明書パスワード、設定ファイルが含間れる記録UIDに変更します。
2つのファイルシステム ID(fs-XXX)を、上記の手順からのものに変更します。
ロールIDのXXXをAWSロールに固有のものに変更します。
2箇所のeu-west-1値を、ECSサービスの地域に変更します。
次に、[Elastic Container Service] > [タスク定義] > [JSONからタスクを作成]に移動します。
既存のJSONを削除し、変更したJSONファイルをボックスにコピーして貼り付けてから[作成]をクリックします。
このタスク定義は、インスタンスのCPU/メモリ要件に応じて変更できます。
AWSのアプリケーションロードバランサーが Automatorのリクエストに対応するには、SSL証明書が AWS Certificate Managerによって管理されている必要があります。
AWS Certificate Managerへ移動し、[インポート]をクリックします。
ご利用のワークステーション上でSSL証明書(.pfx)ファイルを、 PEMエンコードされた証明書本体、PEMエンコードされた秘密キー、PEMエンコードされた証明書チェーンに変換する必要があります。
.pfxファイルはすでに存在するので以下のopensslコマンドを使用します。ssl-certificate.pfxファイルと証明書パスワードをワークステーションへダウンロードし、以下のコマンドを入力します。
PEMエンコードされた証明書本体の生成
PEMエンコードされた秘密キーの生成
PEMエンコードされた証明書チェーンの生成
3つのファイルの内容を画面へコピーします。
[EC2] > [ターゲットグループ]に移動し、[ターゲットグループの作成] をクリックします。
ターゲットの種類として[IPアドレス]を選択します。
ターゲットグループ名にautomatortargetgroupまたは任意の名前を入力します。
ポート443のHTTPプロトコルを選択します。
ECSクラスターを含むVPC を選択します。
HTTP1を選択します。
[ヘルス チェック] で、ヘルスチェックプロトコルとして[HTTPS]を選択します。
ヘルスチェックのパスとして/health
と入力します。
[次へ]をクリックします。
まだターゲットを選択せずに[ターゲットグループの作成]をクリックします。
[EC2] > [ロードバランサー] > [ロードバランサーの作成]に移動します。
[Application Load Balancer] > [作成]を選択します。
automarnalbなどの任意の名前を割り当てます。
スキームはInternet-facingとなります。
IPアドレスの種類: IPv4
[ネットワークマッピング]の箇所で、ECSサービスをホストするVPCとサブネットを選択します。
セキュリティグループで、手順4で作成したMyAutomatorServiceを選択します。
[リスナーとルーティング]の箇所でHTTPSポート443を選択し、ターゲットグループで前の手順で作成したターゲットグループ(automatortargetgroup)を選択します。
[セキュアリスナー設定]で、手順9でAWS Certificate ManagerにアップロードしたACMからのSSL証明書を選択します。
[ロードバランサーの作成]をクリックします。
[Elastic Container Service] > [タスク定義] > 手順8で作成したタスクを選択します。
このタスク定義から、[デプロイ] > [サービスの作成]をクリックします。
automatorの既存のクラスターを選択します。
サービス名にautomatorserviceまたは任意の名前を割り当てます。
必要なタスクの数については、とりあえず1に設定します。設定が完了後に実行したいタスクの数を増やせます。
[ネットワーク]でVPCとサブネットを選択し、既存のセキュリティグループを手順4で作成した ECSセキュリティグループに置き換えます。この場合はMyAutomatorServiceとなります。
パブリックIPはONにします。
[ロードバランシング]で、ロード バランサーの種類として[Application Load Balancer]を選択します。
既存のロードバランサーを使用し、手順11で作成したautomatralbを選択します。
既存のリスナーを使用し、443:HTTPSリスナーを選択します。
既存のターゲットグループを使用し、手順10のターゲットグループを選択します。
[作成]をクリックします。
数分後にサービスが起動します。
DNS名がRoute53によってホストおよび管理されていると仮定します。
Route53 > レコードの作成または編集に移動します。
Aレコードを作成します。
エイリアスとして設定します。
トラフィックを[アプリケーションおよびクラシックロードバランサーへのエイリアス]にルーティングします。
AWS地域を選択します。
automaticalbアプリケーションロードバランサーを選択します。
[シンプルルーティング]を選択します。
[保存]を選択します。
次の手順では、タスクを1件だけ実行した状態でKeeper Commanderを使用してAutomatorを設定します。
この時点ではサービスは実行されていますが、まだKeeperと通信できない状態です。
ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。
コマンドの出力には、IDプロバイダからのメタデータを含むAutomator設定が表示されます。
以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
新しい設定でAutomatorを初期化します。
サービスを有効にします。
この時点で設定は完了となります。
自動ヘルスチェックには以下のURLをご使用になれます。
https://<server>/health
以下はcurl
コマンドを使用した例です。
本セットアップ例では、ロードバランサーがターゲットインスタンスにヘルスチェックを転送します。
Keeper Automatorが1件のタスクを実行した状態でデプロイされましたので、エンドユーザーの体験をテストできます。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。
承認が機能しましたので、実行するタスクの数を増やせます。
ECS画面からAutomatorサービスを開き、[サービスの更新]をクリックします。 次に、実行するタスクの数を設定します。
Automatorログは、ECSサービスの[ログ]タブまたはCloudWatchで検索およびモニターできます。
Keeper Automatorをシンプルなdocker環境にデプロイする方法
本ガイドでは、Dockerを実行できるLinux インスタンスでKeeper Automatorを実行するための手順を解説します。
(1) Dockerのインストール
Dockerをインストールしていない場合は、ご利用のプラットフォームの手順に従ってセットアップします。たとえば、yumパッケージインストーラーを使用する場合、以下のようになります。
Dockerサービスが実行されていない場合は、Dockerサービスを開始します。
次に、サービスが自動的に開始するように設定します。
root以外のユーザーにDockerの実行を許可するには(セキュリティ要件を満たしている場合)、以下のコマンドを実行します。
(2) Automatorイメージの取得
docker pull
コマンドを使用して、最新のKeeper Automatorイメージを取得します。
(3) サービスの開始
以下のコマンドを使用してサービスを開始します。以下の例では、ポート443をリッスンしています。
(4) 証明書の更新
dockerコンテナ内にconfigフォルダを作成します。
.pfxファイルがパスフレーズで保護されている場合は、ssl-certificate-password.txt
という名前のファイルも作成して、dockerコンテナにコピーする必要があります。
(5) SSL証明書を使用してコンテナを再起動
証明書がインストールされましたので、Dockerコンテナを再起動します。
(6) Keeper Commanderをインストール
この時点でサービスは実行中ですが、Keeperとはまだ通信でない状態です。
(7) Commanderで初期化
Keeper Commanderにログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効化します。
ノード名(この場合はAzure Cloud)は、以下のように管理コンソールのUIに表示されます。
コマンドの出力には、IDプロバイダから取得したメタデータを含むAutomatorの設定が表示されます。
以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
新しい設定でAutomatorを初期化します。
Automatorサービスを有効にします。
この時点で設定は完了となります。
自動ヘルスチェックには以下のURLをご使用になれます。
https://<server>/health
以下はその例です。
IDプロバイダとしてAD FSを使用してKeeper Automatorを有効にする場合、以下の手順に従ってKeeper 証明書を更新するまでログインできません。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。
Keeper Automatorがデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。
Keeper Automatorサービスを停止/開始する際、Dockerサービスは自動的に状態を保持します。
Keeper Automatorのログを確認してください。通常これで問題がわかります。Docker環境では、以下のコマンドを使用してログファイルを追跡できます。
以下のコマンドを使用して、コンテナに接続してログファイルを確認できます。
Docker Composeメソッドを使用したKeeper Automatorのインストール
本ガイドでは、Dockerを実行できるLinuxインスタンスでKeeper Automatorを実行するための手順を解説します。
コンテナの更新間でデータが保持されます
将来の更新のインストールと保守が簡単です
Docker Composeメソッドを使用したAutomatorのインストール手順は以下のとおりです。
DockerとDocker Composeのインストール手順はプラットフォームによって異なります。以下の公式ドキュメントをご参照ください。
Amazon Linux 2インスタンスの場合、こちらのdocker-composeのインストールのチュートリアルをご参照ください。
注: 新バージョンのDocker Composeは以下のコマンドを使用して実行します。
docker compose
旧バージョンでは以下のようにダッシュを使用します。
docker-compose
インストール後にDockerサービスが動作していない場合は、Dockerサービスの起動が必要になる場合があります。
次に、サービスが自動的に開始するように設定します。
root以外のユーザーにDockerの実行を許可するには(セキュリティ要件を満たしている場合)、以下のコマンドを実行します。
以下のスニペットをdocker-compose.yml
ファイルとして、サーバーのdocker composeコマンドを実行する場所に保存します。
この時点でサービスは実行中ですが、Keeperとはまだ通信できない状態です。
(7) Commanderで初期化します
Keeper Commanderにログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効化します。
ノード名(この場合は、Azure Cloud)は、以下に示すように管理コンソールのUIに表示されます。
コマンドの出力には、IDプロバイダから取得したメタデータを含むAutomatorの設定が表示されます。
URLはまだ設定されていないませんので、選択したFQDNを使用してURLを編集します。
以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
新しい設定でAutomatorを初期化します。
Automatorサービスを有効にします。
この時点で設定は完了となります。
自動ヘルスチェックには以下のURLをご使用になれます。
https://<server>/health
以下はその例です。
Docker Compose コマンドを使用してAutomator ログをモニターできます。
IDプロバイダとしてAD FSを使用してKeeper Automatorを有効にする場合、以下の手順に従ってKeeper 証明書を更新するまでログインできません。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。
Keeper Automatorがデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。
KubernetesサービスとしてKeeper Automatorをインストール
本ガイドでは、Keeper AutomatorをKubernetesサービスとして実行するための手順を解説します。
Kubernetesのインストールとデプロイについては詳しく触れませんが、デモの目的でプラットフォームに依存しない2つのEC2インスタンス(マスターとワーカー)を使用する、非常に基本的な単一ノード環境について記載しました。K8環境がすでに整っている場合には手順2へお進みください。
Kubernetesはコンテナランタイムを要しますのでDockerを使用します。
これらのパッケージは、マスターノードとワーカーノードの両方にインストールする必要があります。 今回の例ではAWS Amazon Linux 2インスタンスタイプを使用しています。
マスターノードとして使用をご希望のマシンで以下を実行します。
--pod-network-cidr
引数は、特定のネットワークプロバイダーで必要となります。ポッドに設定するIP範囲を置き換えます。
kubeadm init
が完了後、ワーカーノードをマスターに参加させるために使用できるコマンドが表示されます。レスポンスと初期化コードをメモして次の手順で使えるようにします。
ローカルのkubeconfigをセットアップします。
クラスターが機能する前にポッドネットワークをインストールする必要があります。簡単にflannel
を使用できます。
ワーカーノードとして追加する各マシンで、初期化コードを含む以下のコマンドを実行します。
セキュリティグループ内のワーカーノードとマスターノードの間でポート6443 が開いている必要があリます。
ワーカーが参加した後、Kubernetesクラスターが稼働します。マスター上でkubectl get nodes
を実行すると、ノードのステータスを確認できます。
Keeper AutomatorのSSL証明書がSecretとしてKubernetesサービスに提供されます。SSL証明書とSSL証明書パスワード(SSL 証明書ガイドから作成)を保存するには、以下のコマンドを実行します。
以下は、automator-deployment.yamlとして保存できるマニフェストファイルです。デプロイメントリソースとサービスリソースの両方の設定が含まれています。
デプロイメントリソースはKeeper Automator Dockerコンテナを実行します。
SSL証明書と証明書パスワードファイルは、マウントされたSecretとして参照されます。
Secretは初期化コンテナ内のポッドにコピーされます。
Automatorサービスはポート30000でリスンしてから、コンテナーのポート443にルーティングします。
本手順では、単一のコンテナ(replicas: 1)のみをデプロイしてコンテナを設定できるようにします。最後の手順でreplicasの数を増やします。
30秒以内にサービスが起動します。
ウェブブラウザでサービスが実行されていることを確認します(テストしているデバイスからポート 30000を開く必要があります)。 今回の場合、URLはhttps://automator2.lurey.com:30000/api/rest/statusとなります。
自動ヘルスチェックには以下のURLもご利用になれます。
https://<server>/health
例:
これで単一ポッドのサービスが実行されていますので、Keeper Commanderを使用してAutomatorをご利用の環境に統合します。
ポッドを設定してAutomator機能を使うには、Keeper Commanderが必要となります。Keeper Commanderはどこからでも実行できます。
Commanderをインストールした後、keeper shell
と入力してセッションを開いてからlogin
コマンドを使用してログインします。Automatorをセットアップするには、Keeper管理者またはSSO ノードを管理する権限を持つ管理者としてログインする必要があります。
Keeper Commanderにログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効にします。
ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。
コマンドの出力には、IDプロバイダからのメタデータを含むAutomator設定が表示されます。
URLはまだ入力されていませんので、以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomatorに提供されます。
次に、他のIdPメタデータをAutomatorに送信します。
Automatorサービスを有効にします。
この時点で設定は完了となります。
単一のポッドでAutomatorサービスが適切に動作していることを確認するには、以下の手順を行います。
ブラウザのシークレットモードでウィンドウを開きます。
SSOユーザーアカウントを使用してKeeperウェブボルトにログインします。
SSOログインの成功後にデバイスの承認が必要ないことを確認します。
この時点では、単一のポッド設定を実行しています。最初のポッドにAutomatorサービスがセットアップされKeeper クラウドに設定されましたので、ポッドの数を増やせます。以下のように、YAMLファイル内のreplicasステートメントを実行したいポッドの数に更新します。
次に変更を適用します。
複数のポッドが実行されている場合、コンテナはラウンドロビン方式のセットアップで負荷が分散されます。最初の承認リクエスト時に構成設定がKeeperクラウドからAutomatorポッドへ自動的かつ安全にロードされます。
Automatorサービスを実行しているログファイルでエラーを監視できます。ポッドのリストを取得するには以下を実行します。
以下のコマンドを使用して、ターミナル経由でAutomatorコンテナに接続します。
ログファイルはlogs/フォルダにあります。ターミナルに接続する代わりに、以下のコマンドからコンテナのログファイルを追跡することもできます。
オートメーター構成の最終ステップを実行するには、Keeperコマンダーが必要です。これはどこからでも実行できます。サーバーにインストールする必要はありません。 ワークステーションまたはサーバーに、KeeperコマンダーCLI をインストールします。バイナリインストーラーを含むインストール手順については、をご参照ください。
Azure内でのインストールは完了です。
Keeperテナント地域 | IP1 | IP2 |
---|---|---|
ご利用のワークステーションまたはサーバーにKeeperコマンダーCLIをインストールします。 バイナリインストーラーを含むインストール手順についてはをご覧ください。
コマンダーをインストールした後、コマンダーを起動するか既存の端末からkeeper shell
と入力してセッションを開いてから、login
コマンドを使用してログインします。オートメーターをセットアップするには、Keeper管理者として、または SSOノードを管理する権限を持つ管理者としてログインする必要があります。
SSL証明書がすでに用意できていることをご確認ください。用意できていない場合は、のページの手順に従ってください。
のページで作成した.pfxファイルをAutomatorのconfig/
フォルダにアップロードし、ファイル名がssl-certificate.pfx
になっていることを確認します。
ご利用のワークステーション、サーバー、コンピュータなどにKeeper Commander CLIをインストールします。バイナリインストーラーを含むインストール手順についてはをご覧ください。
Commanderをインストールしたら、keeper shell
と入力してセッションを開き、login
コマンドを使用してログインできます。Automatorを設定するには、Keeper管理者、またはSSOノードを管理できる管理者としてログインする必要があります。
Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、をご参照ください。
Keeper Automatorサービスを再設定する際、Keeper Commanderを使用してサービスエンドポイントを再初期化する必要がある場合があります。Keeper Commanderについてはをご覧ください。
Keeperテナント地域 | IP1 | IP2 |
---|
ご利用のワークステーション、サーバー、コンピューターのどれかにKeeper Commander CLIをインストールします。初期設定にのみ使用します。バイナリインストーラーを含むインストール手順についてはをご覧ください。
にログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効にします。
の説明に従ってSSL 証明書を作成します。
コンテナー内にKeeper Secrets Manager(KSM)アプリケーションを作成します。Secrets Manager をご使用でない場合は、をご参照ください。アプリケーションの名前はAutomatorですが問題ありません。
Keeperテナント地域 | IP1 | IP2 |
---|
ご利用のワークステーション、サーバー、コンピューターのどれかにKeeper Commander CLIをインストールします。初期設定にのみ使用します。バイナリインストーラーを含むインストール手順についてはをご覧ください。
Commanderをインストールした後、keeper shell
と入力してセッションを開いてからlogin
コマンドを使用してログインします。Automatorをセットアップするには、Keeper管理者またはSSO ノードを管理する権限を持つ管理者としてログインする必要があります。
にログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効にします。
SSL証明書が必要となりますので、お持ちでない場合はページをご参照ください。
で作成したssl-certificate.pfx
ファイルをコンテナにコピーします。
ご利用のワークステーション、サーバー、コンピュータなどにKeeper Commander CLIをインストールします。バイナリインストーラーを含むインストール手順についてはをご覧ください。
Commanderをインストールした後、keeper shell
と入力してセッションを開いてからlogin
コマンドを使用してログインします。Automatorをセットアップするには、Keeper管理者、またはSSOノードを管理できる管理者としてログインする必要があります。
Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、をご参照ください。
SSL証明書が必要となりますので、お持ちでない場合はページをご参照ください。
ご利用のワークステーション、サーバー、コンピュータなどにKeeper Commander CLIをインストールします。初期設定に使用のみとなります。バイナリインストーラーを含むインストール手順についてはをご覧ください。
Commanderをインストールした後、keeper shell
と入力してセッションを開いてからlogin
コマンドを使用してログインします。Automatorをセットアップするには、Keeper管理者、またはSSOノードを管理できる管理者としてログインする必要があります。
Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、をご参照ください。
SSL証明書が必要となりますので、お持ちでない場合はページをご参照ください。
ご利用のワークステーションにKeeper Commander CLIをインストールします。バイナリインストーラーを含むインストール手順についてはをご覧ください。
Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、をご参照ください。
US
54.208.20.102/32
34.203.159.189/32
US GovCloud
18.252.135.74/32
18.253.212.59/32
EU
52.210.163.45/32
54.246.185.95/32
AU
3.106.40.41/32
54.206.208.132/32
CA
35.182.216.11/32
15.223.136.134/32
JP
54.150.11.204/32
52.68.53.105/32
US | 54.208.20.102/32 | 34.203.159.189/32 |
US GovCloud | 18.252.135.74/32 | 18.253.212.59/32 |
EU | 52.210.163.45/32 | 54.246.185.95/32 |
AU | 3.106.40.41/32 | 54.206.208.132/32 |
CA | 35.182.216.11/32 | 15.223.136.134/32 |
JP | 54.150.11.204/32 | 52.68.53.105/32 |
US | 54.208.20.102/32 | 34.203.159.189/32 |
US GovCloud | 18.252.135.74/32 | 18.253.212.59/32 |
EU | 52.210.163.45/32 | 54.246.185.95/32 |
AU | 3.106.40.41/32 | 54.206.208.132/32 |
CA | 35.182.216.11/32 | 15.223.136.134/32 |
JP | 54.150.11.204/32 | 52.68.53.105/32 |
Automatorの設定と機能
本ドキュメントの設定でAutomatorサービスの機能と安全性を制御します。
automator_debug
Env変数: AUTOMATOR_DEBUG
説明: Automatorで簡単にデバッグログをオン/オフします。
automator_config_key
Env変数: AUTOMATOR_CONFIG_KEY
初期値: Empty
説明: Base64 URLエンコードされた256ビットAES キーで、通常環境変数としてのみ使用されます (v3.1.0以降)。この設定は、コンテナインスタンス間で共有される/usr/mybin/configファイルストレージがない場合に、暗号化された設定をKeeperクラウドからロードするために必要となります。
automator_host
Env変数: AUTOMATOR_HOST
初期値: "unknown"
説明: Automator サービスがローカルでリッスンしているホスト名または IP アドレスです。SSLが有効になっている場合 (ssl_mode
パラメータ)、automator_hostの値がSSL証明書のサブジェクト名に一致する必要があります。サブジェクト名が一致しない場合、disable_sni_check
設定をfalse
に設定できます。
サービスが複数のネットワークIPを持つマシンで実行されている場合、この設定によりAutomatorサービスが指定されたIPにバインドされます。
automator_port
Env変数: AUTOMATOR_PORT
初期値: 8089
説明: Automator がリッスンするポートです。Dockerで実行している場合は、デフォルトの8089を使用します。
disable_sni_check
Env変数: DISABLE_SNI_CHECK
初期値: false
説明: SSLが使用中である場合は、証明書のサブジェクト名に対するSNIチェックを無効にします。
email_domains
Env変数: EMAIL_DOMAINS
初期値: null
説明: Automatorがデバイスまたはチームを承認するための、ユーザーのメールドメインのカンマ区切りのリストで、example.com、test.com、mydomain.comなど。filter_by_email_domains設定が有効になっているかどうかにも依存します。
filter_by_email_domains
Env変数: FILTER_BY_EMAIL_DOMAINS
説明: trueの場合、Keeperがemail_domainsリストを参照します。falseの場合、email_domainsリストは無視されます。
enabled
Env変数: N/A
初期値: false
説明: Automatorが有効か無効かを決定します。
enable_rate_limits
Env変数: ENABLE_RATE_LIMITS
初期値: false
説明: trueの場合、Automatorは以下のスケジュールに従って受信するコールのレート制限を行います。
approve_device
: 100コール/分(バースト最大 200)
approve_teams_for_user
: 100コール/分(バースト最大 200)
full_reset
: 1 分に4回、バーストは6回まで
health
: 1 分に4回
initialize
: 1 分に4回、バーストは6回まで
setup
: 1 分に4回、バーストは6回まで
status
: 1 分に5回
ip_allow
and ip_deny
Env変数: IP_ALLOW
and IP_DENY
初期値: ""
説明: この制限によりユーザーは自動承認を利用できるようになります。IP制限フィルターによって受け入れられたユーザーも、Automatorによる通常の方法で承認される必要があります。IP制限フィルターで拒否されたユーザーは自動承認されません。
ip_allowが空の場合、ip_denyリストに記載されているものを除くすべてのIPアドレスが許可されます。この設定を使用した場合、許可範囲外のIPアドレスにあるデバイスはAutomatorによって承認されなくなります。 値は、単一のIPアドレスまたはIP範囲のカンマ区切りのリストとなります。 最初にip_allowリストがチェックされ、次にip_denyリストがチェックされます。
例1: ip_allow=
ip_deny=
例2:
ip_allow=10.10.1.1-10.10.1.255, 172.58.31.3, 175.200.1.10-175.200.1.20
ip_deny=10.10.1.25
name
Env変数: N/A
初期値: Automator-1
説明: Automatorの名前です。エンタープライズ内で固有である必要があります。Automatorは名前またはIDで参照できます。
persist_state
Env変数: N/A
初期値: true
説明: trueの場合、Automatorの状態がシャットダウン後も保持されます。オンのままにしておきます。
skill
Env変数: N/A
初期値: device_approval
説明: device_approvalはデバイスの承認を意味します。team_for_user_approvalはチームの承認を意味します。Automatorは複数のスキルを持つことができます。device_approvalがデフォルト値となります。
ssl_certificate
Env変数: SSL_CERTIFICATE
初期値: null
説明: SSL証明書に使用されるPFXファイルの内容を含んだBase64でエンコードされた文字列です。たとえば、UNIXでは、base64 -i my-certificate.pfx
によって必要な値が生成されます。
この環境変数を使用すると、ssl_certificate_filename
設定が上書きされます。
ssl_certificate_file_password
Env変数: SSL_CERTIFICATE_PASSWORD
初期値: ""
説明: SSLファイルのパスワードです。使用する場合、キーのパスワードは空であるか同じである必要があります。使用するライブラリでは異なるパスワードは使用できません。
ssl_certificate_key_password
Env変数: SSL_CERTIFICATE_KEY_PASSWORD
初期値: ""
説明: SSLファイル内の秘密キーのパスワードです。空かファイルのパスワードと同じである必要があります。
ssl_mode
Env変数: SSL_MODE
初期値: certificate
説明: Automatorサービスでの通信方式です。certificate
、self_signed
、none
のいずれかになります。 none
の場合、AutomatorサーバーはHTTPSの代わりにHTTPを使用します。 AutomatorがSSLトラフィックを復号化するロードバランサーの下でホストされている場合はそれでも良いかもしれません。
url
Env変数: N/A
初期値: ""
説明: Automatorに接続できるURLです。
単一Automatorインスタンスに複数のテナントをセットアップ定
Keeper Automatorではマルチテナントがサポートされていますので、一度のデプロイで複数のKeeper Enterprise環境を自動化できます。
MSP環境では、単一のKeeper Automatorインスタンスを使用して複数の企業に対応できます。
Enterpriseユーザーの場合、単一のインスタンスで様々なIDプロバイダの承認を処理できます。
サーバーが実行中となると、企業が異なっても複数のSSOノードに使用できます。
単一のAutomatorインスタンスを発動して複数の企業を管理する手順は以下のとおりです。
(1) MSP管理者としてCommanderにログインします
(2) コンテキストを管理対象企業に切り替えます
設定したい企業を見つけてIDを選択し、以下のように入力します。
(3) Automatorインスタンスを作成します
以下のように、editの手順では共通のAutomator URLを使用します。
(4) MSPに戻ります
MSP管理者コンテキストに戻ります
管理対象の企業ごとに、上記の4つの手順を繰り返します。
同じ企業テナントの複数のノードで、単一のAutomatorインスタンスを有効化する手順は以下のとおりです。
(1) 管理者としてCommanderにログインします
(2) Automatorインスタンスを作成します
以下のように、各ノードでeditには同じURLを使用します。
同一のURLエンドポイントを持つ別のインスタンスを設定します。
新たに作成したインスタンスは、名前とIDが異なり、割り当てられたノードも異なりますが、同じURLを使用します。
各ノードで手順(2)を繰り返し、同じAutomatorインスタンスに複数のテナントをセットアップします。
Keeper AutomatorのWindowsサーバーでの実装例
本ガイドでは、Dockerを使用せずにAutomatorサービスをWindowsサーバーで実行するための手順を解説します。
SSL証明書が必要となりますので、お持ちでない場合はカスタムSSL証明書の作成ページをご参照ください。
Automatorインスタンスで、以下のURLからKeeper Automatorのインストーラーをダウンロードし、解凍して実行します。
https://keepersecurity.com/automator/keeper-automator-windows.zip
設定画面でJavaのチェックボックスをオンにして、Javaランタイムをインストールに含めます。現在はJava 17ランタイムが同梱されており、新バージョンのリリースに合わせて更新されます。
これにより、Keeper Automatorが以下のフォルダにインストールされます。
C:\Program Files\Keeper Security\Keeper Automator\
設定は以下のフォルダに保存されます。
C:\ProgramData\Keeper Automator\
C:\ProgramData\Keeper Automatorフォルダにconfigというフォルダを作成します。
ssl-certificate.pfx
ファイル(SSL証明書作成のページで保存)をC:\ProgramData\Keeper Automator\Configに配置します。
ssl-certificate.pfx
ファイルがパスフレーズで保護されている場合は、ssl-certificate-password.txt
という名前のファイルもC:\ProgramData\Keeper Automator\Configに作成する必要があります。
サービス画面でKeeper Automatorを選択し、サービスを再起動します。
ウェブブラウザでサービスが実行中であることを確認します(テストしているデバイスからポート443が解放されている必要があります)。 この場合のURLは、https://automator.company.com/api/rest/statusとなります。
自動ヘルスチェックには以下のURLもご使用になれます。
https://automator.company.com/health
Defenderファイアウォールが実行されているWindowsでデプロイしている場合は、Windows Defenderファイアウォールでポート443(または任意の指定ポート)を開く必要がありますので、 以下の手順に従います。
[スタート]メニューを開き、[Windows Defenderファイアウォール]と入力して、結果の一覧から選択します。横のナビゲーションメニューで[詳細設定]を選択し、[受信の規則]を選択します。ポートを開くには、[新しい規則]を選択して手順を完了します。
サービスが実行中となりましたので、Keeper Commanderを使用してAutomatorをご利用のKeeperの環境に統合します。
(5) Keeper Commanderをインストールします
ご利用のワークステーション、サーバー、コンピュータなどにKeeper Commander CLIをインストールします。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。
(6) Keeper Commanderにログインし、automator create
で始まる一連のコマンドを使用してAutomatorを有効化し、Automatorに任意の名前を付けます。
ノード名(この場合は、Azure Cloud)は、以下に示すように管理コンソールのUIに表示されます。
コマンドの出力には、IDプロバイダから取得したメタデータを含むAutomatorの設定が表示されます。
URLがまだ入力されいませんので、以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます(team
、 team_for_user
、device
)。
次にキーを交換します。Automator公開キーで暗号化されたエンタープライズ秘密キーがAutomator に提供されます。
この手順でエラーが発生した場合は、Windows サービスを停止してから開始し、ポートが使用可能であることを確かにします。
次に、以下のコマンドを使用して新しい設定でAutomatorを初期化します。
最後に、以下のコマンドでAutomatorサービスを有効にします。
この時点で設定は完了となります。
IDプロバイダとしてAD FSを使用してKeeper Automatorを有効にする場合、以下の手順に従ってKeeper 証明書を更新するまでログインできません。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。
Keeper Automatorがデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。
最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。
Keeper Automatorサービスを再設定する際は、Keeper Commanderを使用してサービスエンドポイントを再初期化する必要があります。
Keeper Automatorのログを確認してください。通常これで問題がわかります。Windowsの場合、ログはC:\ProgramData\Keeper Automator\logsにあります。
Keeper Automatorサービスを再インストールする際、Keeper Commanderを使用してサービスエンドポイントを再初期化する必要がある場合があります。Keeper Commanderについてはこちらをご覧ください。
Keeper CommanderでAutomatorインスタンスを再初期化するのに必要なコマンドは以下のとおりです。
カスタムSSL証明書でKeeper Automatorを設定
Keeper AutomatorによりKeeperバックエンドとお客様の環境で実行されているAutomatorサービスの間の通信を暗号化されます。
カスタム証明書を使用しない場合、Keeper Automatorがデフォルトで自己署名証明書を生成します。
SAMLが署名だけでなくリクエストを暗号化するように設定されている場合は、カスタム SSL証明書が必要となります。
ZeroSSLで簡単に無料でSSL証明書を取得できます。あるいはプロセスの各過程をより詳細に制御したい場合は、以下の手順にお進みください。
Keeper Automatorには、公的認証局によって署名された有効な署名付きSSL証明書が必要です。SSL 証明書を生成するプロセスはプロバイダによって異なりますが、ここでは一般的なフローについて記載します。
以下の手順に従ってAutomatorの実行に必要な2つの証明書ファイルを作成します。これらのファイルにはssl-certificate.pfx
およびssl-certificate-password.txt
という名前を付けます。
(1) opensslコマンド プロンプトを使用して秘密キーを生成します。
(2) Automatorに使用する予定のホスト名を使用してCSRを生成します。この場合、automator.lurey.comを使用します。Common Nameはドメインと完全に一致します。
(3) SSL証明書を購入するか 90日間の無料証明書を取得し、CSRをSSL証明書プロバイダに送信します。
Automatorインスタンス用に作成したSSL証明書はこの目的にのみ使用するようにしてください。他のサービスと共有されているワイルドカード証明書は使用しないでください。
まだプロバイダをお持ちでない場合は、https://www.ssls.com/をご利用になれます。1つのドメインに対して最も安価なSSL証明書で問題ありません。
automator.company.comなどのURLを選択し、Automatorに限定したドメインの証明書を作成します。
SSL証明書プロバイダが署名付き証明書(.crt ファイル)と中間CA証明書を含むzipファイルを配信します。バンドルのファイル拡張子は .crt または .ca-bundleのいずれかとなります。このファイルを、前に作成した.keyファイルと同じ場所に解凍します。
(4) 証明書が発行された後、OpenSSL を使用して完全な証明書チェーン(ルート、中間、CA 証明書)を含む.pfx形式に変換する必要があります。
Windows では、必ずOpenSSLコマンドプロンプトを起動し、ファイルが存在するフォルダへ移動してください。
特殊文字を含まないエクスポートパスワードを設定します。
重要: エクスポートパスワードには特殊文字を使用しないようにしてください。
次に、ssl-certificate-password.txtという名前の新しいテキストファイルを作成し、そのファイルにエクスポートパスワードを入力して保存します。
automator.key
は手順1で生成された秘密キーです。
automator.yourcompany.com.crt
は手順3で配信された署名付き証明書です。
automator.yourcompany.com.ca-bundle
はCAバンドルです。
ssl-certificate.pfx
は、Automatorによって使用されるパスワードで暗号化済みの出力ファイルです。
ssl-certificate-password.txt
には、.pfxファイルの暗号化に使用されるパスワードが含まれています。
5つのファイルすべてをKeeperボルトに保存することを推奨します。
.pfx ファイルに、発行した証明書とプロバイダからの完全な証明書チェーンが含まれていることを確かにしてください。完全な証明書チェーンを提供しない場合は通信が失敗し、AutomatorがURLに接続できません。
.pfxを確認するにはopensslを使用します。
openssl pkcs12 -in ssl-certificate.pfx -info
.pfx が正しい場合は、3 つの証明書が表示されます。
証明書が1つしか表示されない場合、4つまたは5つの証明書が表示される場合は.pfxが間違っているため、プロセスを繰り返す必要があります。
(5) ssl-certificate.pfx
とssl-certificate-password.txt
を保存し、後述のデプロイ手順で使用できるようにします。
また、後でサービスを更新したり証明書を再入力したりするときに参照できるように、Keeperコンテナ内のファイルは必ずバックアップしておいてください。
(6) 以下に記載されている年次証明書更新プロセスを確認してください。
Keeper Automatorには、公的認証局によって署名された有効な署名付きSSL証明書が必要です。自己署名証明書はサポートされていません。SSL 証明書を生成するプロセスはプロバイダによって異なりますが、ここでは一般的なフローについて記載します。
OpenSSLをダウンロードしてインストールします。サードパーティ(slproweb.com)がバイナリインストーラーを作成しています。一般的なバイナリインストーラーについては以下をご参照ください。
https://slproweb.com/products/Win32OpenSSL.html 下部にあるWin32 OpenSSL vX.X.X Lightというバージョンをインストールします。
インストール中にデフォルトのオプションを選択できます。Microsoft Visual Studio拡張機能もインストールするように求められる場合がありますので、OpenSSLのセットアップを完了する前にこの拡張機能をインストールしてください。
OpenSSLコマンドプロンプトを実行します。
スタートメニューにOpenSSLフォルダがありますので、[Win32 OpenSSLコマンドプロンプト]をクリックします。
毎年SSL証明書の更新が必要となりますが、ほとんどの証明書プロバイダーで新しい証明書を生成してくれます。証明書の更新後、Automatorインスタンス内の.pfx証明書ファイルを置き換えてからサービスを再起動します。ファイルの更新とサービスの再起動の正確なプロセスについては、特定のAutomatorインストール方法のドキュメントをご参照ください。
ID プロバイダーとしてAD FSを使用してKeeper Automatorを使用している場合、以下の手順に従って Keeper証明書を更新するまでログインできません。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。
証明書の更新後、IDプロバイダで新しいSP証明書を発行する必要がある場合があります。以下がその手順となります。
Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックして証明書ファイルを保存します。
[メタデータのエクスポート]をクリックして証明書が含まれるメタデータファイルを保存します。
IDプロバイダポータルにログインし、KeeperのSSO設定を見ます。
サービスプロバイダーの証明書更新の指示に従って、KeeperのSP証明書ファイル(または必要に応じてメタデータ)をアップロードし、保存します。
Automatorサービスが本質的にサービスプロバイダーになるのが理由となります。署名プロセスには、お客様が生成したSSL証明書が使用されます。
SSLを終了するカスタムドメインを持つアプリケーションゲートウェイまたはロードバランサーを利用する環境でSSL証明書を更新する場合は、そのデバイス上の証明書も更新する必要があります。
App Gatewayを使用したAzureデプロイの場合、ゲートウェイのhttpsリスナーで.pfx 証明書も更新する必要があります。[Azure] > [リソースグループ] > [アプリゲートウェイ] > [リスナー]に移動し、新しい証明書をアップロードします。
Automatorサービスによくある問題とトラブルシューティング
Keeper CommanderがAutomatorサービスと通信できない理由はいくつかあります。
カスタムSSL証明書をご使用の場合は、SSL証明書がロードされていることを確かにします。 Automatorのログファイルを確認すれば、サービスの再起動によって証明書がロードされたかどうかが確認できます。そのIPアドレスにアクセスできる場合は、以下のようにコマンドラインでcurlを使用することで正常性チェックを実行できます。
curl https://automator.mycompany.com/health
証明書のサブジェクト名がFQDNと一致することを確認します。
SSL証明書にCA中間証明書チェーンが含まれていることを確認します。中間証明書チェーンが欠落している場合、KeeperはAutomatorへの接続を拒否します。以下のようにopensslコマンドを使用してご確認ください。
当エラーは、ヘルスチェックのリクエストURIがSSL証明書ドメインと一致しない場合に発生する可能性があります。ヘルスチェックを完了させるにはサービスでSNIチェックを無効にする必要がありますので、Automator設定でdisable_sni_check=trueを設定するか、環境変数 DISABLE_SNI_CHECKにtrueの値を渡します。
Commanderを使用した承認
KeeperのCLI/SDKプラットフォームであるCommanderを使用すると、管理コンソールにログインしなくとも自動で管理者によるデバイス承認を実行できます。また、Keeper Commanderが実行可能であればどのコンピュータ (Mac、PC、Linux) でも設定できます。
この方法はKeeperクラウドからの着信接続を必要としないため、入力ポートが開けない環境に適しています。この方法ではポーリングメカニズムが使用されます (送信接続のみ)。
keeper shellコマンドを使用してCommander CLIを起動します。Commanderのバイナリをインストールした場合はそのファイルを実行します。
loginコマンドを使用して、デバイスの承認権限を持つKeeper管理者としてログインします。 Commanderでは、マスターパスワードと2FAがサポートされています。自動化を目的として、デバイスの承認専用のKeeper管理アカウントを作成することを推奨します。 これにより、ユーザーアカウントへの何らかの変更 (強制ポリシーなど) によって、Commanderの処理が中断されることがなくなります。
すべてのデバイスを表示するには、device-approveと入力します。
特定のデバイスを手動で承認するには、以下のコマンドを使用します。
過去に正常なログインが認識されたIPからのデバイスをすべて承認するには、以下のコマンドを使用します。
IPアドレスに関係なくすべてのデバイスを承認するには、以下のコマンドを使用します。
特定のデバイス承認リクエストを拒否するには、denyコマンドを使用します。
すべての承認リクエストを拒否するには、デバイスIDパラメータを削除します。
シェルを終了せずに最新のデバイス承認をリロードするには、reloadコマンドを使用します。
Commanderでは、X秒ごとに承認を実行する自動化モードがサポートされています。設定するには、自動作成されたconfig.jsonファイルを変更します。このファイルは、ユーザーフォルダの.keeperフォルダ内(WindowsではC:\Users\Administrator.keeper\config.json
、Mac/Linuxでは/home/user/.keeper/config.json
)にあります。
既存のデータは変更せずに以下の行を追加します。
JSONファイルでは、最後の行を除くすべての行の後にコンマが必要となります。
これでCommanderを開く(またはkeeper shellを実行する)と、以下のように指定した時間ごとにCommanderがコマンドを実行するようになります。
上記の例と同様に、Commanderを使用してAzure、Okta、JumpCloudなどのSCIMプロバイダによって作成されたチームおよびユーザー割り当てを自動的に承認できます。
設定するには、team-approve
というコマンドをJSON設定ファイルに追加します。
Keeper Commanderでは持続的ログインセッションがサポートされていますので、実行中はマスターパスワードでログインしたりconfigrationファイルにマスターパスワードをハードコードしたりする必要はありません。
以下はデバイス上で30日間 (最大) 持続的ログインを有効にするコマンドとなります。
値には秒数 (例えば60秒の場合は60)、または数字と文字の組み合わせ (例えbば1分の場合は1m、5時間の場合は5h、7日間の場合は7d) を使用できます。
「logout」と入力するとセッションが無効になりますのでご留意ください。 Commander セッション終了するには「quit」します。
デバイスで持続的ログインが設定されると、ローカルフォルダ内のconfig.jsonは以下のようになります。
AutomatorサービスがKeeperのIPアドレスに対して解放されていることを確かにします。解放が必要なIPのリストについては、のページをご参照くださす。接続の問題が発生した場合に解決できるよう、ご自身のIPアドレスも追加することを推奨します。
このコマンドで、チェーン内の証明書の数が表示されます。証明書が1つしか表示されない場合は、証明書チェーンがすべてはロードされていないということになります。この問題を解決するには、ページの手順4をご参照ください。
インストール手順についてはをご参照ください。
Mac/PC/Linux用のバイナリバージョンをインストールするか、pip3
を使用します。
永続的ログインについてはCommanderの資料のをご参照ください。
Keeper Commanderを使用して自動化コマンドをカスタマイズする方法は数多くありますので、詳細についてはをご参照ください。