1 / 22

デバイス承認

SSOクラウドのデバイス承認システム

概要

デバイス承認はSSO Connect Cloudプラットフォームで必須となる要素です。承認は、ユーザーまたは管理者が実行することも、Keeperオートメーターサービスを使用して自動的に実行することもできます。

KeeperクラウドSSOコネクトで認証するカスタマーの場合、デバイスの承認によりキー転送が実行され、ユーザーの暗号化されたデータキーがデバイスに届けられてから楕円曲線秘密キーを使用してローカルで復号化されます。

技術的詳細

KeeperクラウドSSOコネクトでは、どのSAML 2.0IDプロバイダを使用しても簡潔なログイン処理を維持しつつゼロ知識暗号化を実現できます。

過去に使用したことのないデバイスでログインしようとすると、楕円曲線暗号の秘密鍵と公開鍵のペアが新しいデバイスで生成されます。 IDプロバイダの認証に成功すると、ユーザーが新しいデバイスでボルトを復号化できるように鍵交換を実行する必要があります。これを「デバイス承認」と呼びます。

ブラウザでゲストモード、プライベートモード、またはシークレットモードを使用すると、ブラウザを起動するたびに新しいデバイスとしてKeeperに識別されるため、デバイス承認が新たに必要になります。

ゼロ知識を維持し、Keeperのサーバーが暗号鍵に一切アクセスできないようにするために、ユーザーまたは指定された管理者が実行できるプッシュ通知による承認方式を開発しました。また、Keeperを使用するとデバイス承認と鍵交換を自動的に実行するサービスをホストできるため、ユーザーの操作は一切不要となります。

承認方式

デバイス承認方式には以下が含まれます。

既存のユーザーデバイスへKeeperプッシュ (プッシュ通知)
管理コンソールからの管理者承認
Keeperオートメーターサービスを使用した自動承認 (推奨)
コマンダーCLIを介した半自動の管理者承認

Keeperプッシュ通知

既存のデバイスを使用するSSOデバイス承認方法

概要

ユーザーは以前に承認されたデバイスを使用して追加のデバイスを承認できます。たとえば、すでにコンピュータでウェブボルトにログインしている状態で初めて携帯電話アプリにログインする場合、ウェブボルトにデバイス承認プロンプトが表示され、その携帯デバイスを承認したり拒否したりできます。デバイス承認により暗号化キーの交換を実行して新しいデバイスでボルトを復号化できるようにします。

Keeperプッシュ通知方式

Keeperプッシュ通知は、ユーザーが自ら処理する承認方式です。[Keeper プッシュ通知]を選択すると、ユーザーの承認済みデバイスに通知が送信されます。携帯アプリおよびデスクトップアプリの場合、プッシュ通知はポップアップとして表示され、簡単にデバイスを承認できます。

以下は、携帯電話を承認用デバイスとして使用したKeeperプッシュ通知承認の例となります。

手順

[Keeperプッシュ通知]を選択します。

ログイン済みのデバイスにプッシュ通知による承認が表示されるのを待ちます。

ユーザーが通知を受信するには、以前に承認済みの別のデバイスにすでにログインしている状態でなければなりません。

管理者承認

管理者によるエンドユーザーのSSOクラウドデバイス承認

管理者管理コンソールからの管理者承認方法

[管理者の承認]を選択すると、[デバイスの承認]の権限を持つKeeper管理者にリクエストが送信されます。管理者は、管理コンソールの[承認待ち]画面から、またはリクエスト時に管理コンソールにログインして承認できます。

ユーザーが[管理者承認]を選択します

承認を待つか、後ほど戻ります。

管理者が管理コンソールにログインし、[承認待ち]にアクセスします。

管理者が情報を確認し、デバイスを承認します。

承認するデバイスを選択し、[承認]をクリックします。ユーザーが待機している場合は、即座にログインが許可されます。そうでない場合、ユーザーは承認なしで後ほどログインできます (ウェブブラウザのキャッシュをクリアしたりアプリをリセットしたりしない場合)。

デバイスの役割許可を承認する

管理者は、「デバイスの承認」と呼ばれる特別な役割権限によりデバイスを承認できます。

ルートノードまたはSSOノード内の[ロール]へ移動します。

歯車アイコンを選択して、選択した役割の管理者権限を制御します。

[デバイス承認]権限を割り当てます。

これで、この役割に追加されたユーザーは誰でも管理コンソールにログインしてデバイスを承認できるようになります。

他の管理権限と同様に、権限は最小限にするようにしてください

Keeperオートメーターサービス

クラウドSSOコネクト環境を使用した認証に基づく、自動デバイス承認サービス

概要

Keeperオートメーターはセルフホスト型のサービスで、デバイスの承認、チームの承認、およびチームユーザーの割り当てなどの暗号化処理を実行します。

オートメーターが実行されると、ユーザーはIDプロバイダによる認証に成功した後、それ以上の承認手順を踏まずに、新しい (まだ承認されていない) デバイス上のKeeperにそのままアクセスできます。オートメーターサービスが設定されていない場合でも、ユーザーと管理者はプッシュ承認を通じて手動でデバイスを承認できます。

Keeperオートメーターは、さまざまな方法でクラウドまたはオンプレミス環境に展開できる軽量のサービスです。

オートメーターが必要とされる理由

KeeperクラウドSSOコネクトは、IDプロバイダを使用してKeeperボルトへそのまま認証します。通常、新しいデバイスはユーザー自身が承認するか、管理者がユーザーの代わりに新しいデバイスを承認する必要があります。オートメーターサービスはデバイスの承認に関連する煩わしい操作をすべて解消したいと考える管理者のために作成された任意で選択できるサービスとなります。

ゼロ知識を維持し、暗号化されたデータキー (EDK) のユーザーデバイスへの転送を自動化するには、サービスをKeeper側でホストするのではなく、企業側で運用するサービスとして実行する必要があります。このサービスには様々な実行方法があり、クラウドでもセルフホストでも実行可能です。

SSOコネクトの暗号化モデルの詳細な説明については、こちらのページをご参照ください。

インストール方法

ご利用の環境に応じて以下のインストール方法からお選びください。Azure Container App、Azure App Services、AWS Elastic Containerサービス、Google Cloud (GCP Cloud Run)は、これらのクラウドサービスをご利用の場合に最適です。

オートメーターのセキュリティ

オートメーターサービスを使用するとユーザー体験は向上しますが、IDプロバイダは完全に保護されている必要があります。

Keeper環境を保護するための推奨セキュリティ設定ガイドをご参照ください。

バージョン17.0の概要

オートメーターをv17.0にアップグレードする手順

概要

バージョン17.0以降では以下の新機能がご利用になれます。

チームの承認 (チーム作成)
チームユーザーの承認 (ユーザーをチームに割り当てる)
すべての設定が環境変数として構成可能
簡素化されたAzure Container App展開に対応
簡素化されたAWS ECSサービス展開に対応
HTTPSセキュリティを向上させるHSTSが有効
デバイス承認用とチーム承認用のIPアドレスフィルタリング
すべてのAPIに対して任意でレート制限
メールドメインによる任意のフィルタリング
任意で特定のネットワークIPへのバインド

チームユーザー承認

チームとユーザーは、SCIMを通じてプロビジョニングされ、チームに追加されたユーザーについては、管理者がコンソールにログインするのを待つことなくオートメーターサービスによって即座に処理できることを意味します。

この新機能を有効にするには以下を行います。

オートメーターコンテナまたは.zipファイルを最新バージョンに更新します。
Keeperコマンダーからautomator editコマンドを使用してデバイスの承認およびチームユーザーの承認を行います。

例

automator edit --skill=team --skill=team_for_user --skill=device "My Automator"
automator setup "My Automator"
automator init "My Automator"
automator enable "My Automator"

スキルを有効にした状態では、ユーザーがボルトにログインする際にオートメーターが発動してチームユーザーが承認されます。

チームの承認

IDプロバイダからSCIMメッセージングでチームの作成がリクエストされた際、誰かが (ゼロ知識を保持するために) 暗号化キーを生成するまで、リクエストが完全に処理されることはありません。通常は、管理者がKeeper管理コンソールにログインするときに処理されます。

Keeperオートメーターサービスでチーム承認が有効化されている場合、チームに割り当てられたユーザーのいずれかがKeeperボルトに正常にログインすると、自動的にチームが作成されます。そのため少なくとも1人のユーザーがそのチームのボルトにログインするまでチームは表示されません。

チームは、チームのユーザー少なくとも1人がボルトにログインするまで環境には表示されません。

すべての設定が環境変数として設定可能

これにより、設定ファイルへのアクセスが難しいAzureコンテナーまたは他のDockerのようなコンテナーにオートメーターをインストールする場合の構成が簡単になります。

docker-compose.yml ファイルを使用するDockerやAzureコンテナーなどの環境では、以下のようにdocker composeファイルに環境変数を設定できます。

services:
  automator:
    container_name: "az-autodock"
    environment:
      - AUTOMATOR_PORT=8090
      - AUTOMATOR_HOST=10.0.0.4
      - DISABLE_SNI_CHECK=true

docker-compose.ymlファイルの編集後に環境変数が変更されている場合、コンテナを再構築する必要があります。コンテナを再起動しただけでは変更は反映されません。

その他の機能

オートメーターサービスの詳細については、こちらのページをご参照ください。

イングレス要件

Keeperオートメーター向けイングレス設定

Keeperオートメーターは、オンプレミス、クラウド、サーバーレスなど、さまざまな方法で導入できます。

データフロー

ネットワークファイアウォールのセットアップ

ファイアウォールの受信トラフィックルールで以下のいずれかのルールセットを設定します。

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アドレスごとにルールを作成してください。

Azure Container Apps

Azureコンテナーアプリでのデプロイ

概要

本ページでは、KeeperオートメーターをAzure Container Appsサービスに公開するための手順を解説します。これにより、オートメーターサービスを簡単にクラウドでホストしていただけます。

Azure Government、GCC High、DoDなどの環境では、Azure Container Appsサービスがこれらのリージョンで利用できない可能性があるため、Azure App Services方式を使用します。

1. オートメーターConfigキーの作成

コマンドラインを開き、オペレーティングシステムに応じて次のいずれかの方法を使用してURLエンコード形式で256ビットAESキーを生成します。

キーの生成

openssl rand -base64 32

[Byte[]]$key = New-Object Byte[] 32; [System.Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($key); [System.Convert]::ToBase64String($key)

このコマンドによって生成される値を手順 3のために保存します。

2. コンテナーアプリの作成

Azureから新しいコンテナーアプリを作成します。

新しいリソースグループを選択または作成します。
コンテナアプリ名を「keeperautator」または任意の名前に設定します。
デプロイメントソースとして「コンテナイメージ」を選択します。
サービスをホストしたい地域を選択します。
新しいアプリ環境を作成するか、既存の環境を選択します。
[次へ]: [コンテナ] >をクリックします。

3. コンテナの詳細のセットアップ

「コンテナ」の手順では以下のように設定します。

[クイックスタートイメージを使用する]のチェックを外します
[Docker Hub または他のレジストリ]を選択します
[パブリック]を選択します
レジストリログインサーバーにdocker.ioを選択します
イメージを設定し、keeper/automator:latestとしてタグを付けます
「Container resource allocation (コンテナリソース割り当て)」に進みます
CPUとメモリについては、0.5 CPUコアと1Gi メモリで十分ですが、新しいデバイスのログイン量に基づいて変更できます
上記の手順1の値を使用してAUTOMATOR_CONFIG_KEYという環境変数を作成します
8089の値を使用してAUTOMATOR_PORTという環境変数を作成します
noneの値でSSL_MODEという環境変数を作成します
[次へ]: イングレス > をクリックします

4. イングレスのセットアップ

イングレスセットアップ画面で以下を選択します。

イングレスを有効 (Enable)にします
イングレスのトラフィックをAccepting traffic from anywhere にします（後ほど変更します）
イングレスタイプをHTTPにします
ターゲットポートを8089に設定します

5. コンテナアプリの作成

[Review + Create]をクリックしてから[Create]をクリックします。

数分後、コンテナアプリが作成され自動的に起動します。

[Go to Resource (リソースに移動)]をクリックするとコンテナ環境に移動します。

6. イングレス設定のカスタマイズ

Keeperオートメーターサービスへの通信を制限するには、画面左側の[設定]セクションにある[Ingress]のリンクをクリックします。

[Ingress]をクリックします。
[Allow traffic from IPs configured below, deny all other traffic]を選択します。
[Add]をクリックしてKeeperの2つのIPとテストに必要なIPをどれか追加します。
[Save]をクリックします。

Keeperテナント地域

IP1

IP2

54.208.20.102/32

34.203.159.189/32

US GovCloud

18.252.135.74/32

18.253.212.59/32

52.210.163.45/32

54.246.185.95/32

3.106.40.41/32

54.206.208.132/32

35.182.216.11/32

15.223.136.134/32

54.150.11.204/32

52.68.53.105/32

ヘルスチェックの実行をご希望の場合は、ご自身のIPアドレスを追加します。ご自身のIPアドレスについては、https://checkip.amazonaws.comにてご確認になれます。

7. スケーリング、ヘルスプローブ、ボリュームマウントのセットアップ

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]をクリックして新しい設定を作成します。
数分後に新しいコンテナーが起動します。

8. アプリケーションURLの取得

コンテナーアプリの概要の右側に、割り当てられた「アプリケーションURL」が表示されます。このURLをコピーして次の手順で使用します。

(例: https://craigautomator1.xyx-1234.azurecontainerapps.io)

9. Keeperコマンダーにログイン

オートメーター設定の最後の手順を行うのに、Keeperコマンダーが必要となります。どこからでも実行でき、サーバーにインストールする必要はありません。

ご利用のワークステーションまたはサーバーにKeeperコマンダーCLIをインストールします。バイナリインストーラーを含むインストール手順についてはこちらのページをご覧ください。コマンダーをインストールした後、コマンダーを起動するか既存の端末からkeeper shellと入力してセッションを開いてから、loginコマンドを使用してログインします。オートメーターをセットアップするには、Keeper管理者として、または SSOノードを管理する権限を持つ管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com

  _  __  
 | |/ /___ ___ _ __  ___ _ _ 
 | ' </ -_) -_) '_ \/ -_) '_|
 |_|\_\___\___| .__/\___|_|
 v16.x.xxx    |_|

 password manager & digital vault

Logging in to Keeper Commander
Enter password for admin@company.com
Password: ********************
Successfully authenticated with Master Password
Syncing...
Decrypted [58] record(s)

My Vault>

10. オートメーターの作成

automator createで始まる一連のコマンドを使用してオートメーターを作成します。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。

コマンドの出力には、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: 1477468749950
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

URLはまだ入力されていないことにご留意ください。手順8のアプリケーションURLとなります。

以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます（team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

サービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

外部ヘルスチェックには以下のURLをご使用になれます。

https://<server>/health

以下はcurlコマンドを使用した例です。

$ curl https://craigautomator1.xyz.azurecontainerapps.io/health
OK

ユーザー体験のテスト

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と入力します。

高度な設定

環境変数をコンテナに渡してランタイム環境の機能を有効にしたり無効にしたりできます。変数およびその説明については、高度な設定ページをご覧ください。

Azure App Services

Azure App Servicesでデプロイ

概要

本ページでは、Azure App Services内でKeeperオートメーターをウェブアプリとしてインスタンス化する手順を解説します。GCC HighやDoDなどの環境では、オートメーターをホストするのにこのサービスを利用いただけます。

1. オートメーターConfigキーを作成

コマンドラインを開き、オペレーティングシステムに応じて次のいずれかの方法を使用してURLエンコード形式で256ビットAESキーを生成します。

キーの作成

openssl rand -base64 32

[Byte[]]$key = New-Object Byte[] 32; [System.Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($key); [System.Convert]::ToBase64String($key)

このコマンドによって生成される値を手順 6のために保存します。

2. App Servicesウェブアプリを作成

Azureポータルから、検索バーで「App Services」を選択し、「+Create」から「+ Web App」を選択して新しいウェブアプリを作成します。

新しい「Resource Group」を作成します。
「Instance」に名前を付けます。
Publishに「Docker Container」を選択します。
Operating Systemに「Linux」を選択します。
サービスをホストする地域を選択します。
ご利用のLinux Planを選択するか新しいプランを作成します。最も低価格の料金プランは「Premium V3 P0V3」ですが、エンドユーザー環境にもよります。
Docker の箇所へ進みます。

3. Dockerコンテナの詳細をセットアップ

Dockerでは以下のように設定します。

Options: Single Container
Image Service: Docker Hub
Access Type: Public
Image and tag: keeper/automator:latest
Monitoringの箇所へ進みます。

4. WebAppモニタリングをセットアップ

「Enable Application Insights」には「Yes」を選択します。
「Application Insights」を選択するか、新規で作成します。
「Review + create」の箇所へ進みます。

5. WebAppを作成

「Review + Create」、「Create」の順にクリックします。

数分後、WebAppが作成され、自動的に起動します。

「Go to Resource」をクリックしてコンテナ環境へ移動します。

デフォルトのドメイン値をメモしておきます。これはオートメーターサービスのセットアップと初期化の際に必要になります。

6. WebAppを構成

Configurationへ移動し、「New application setting」を選択します。

環境変数の設定は、以下のように左側メニューの「Environment variables」の箇所で行う場合があります。

以下のアプリケーション設定を追加します。

以下の環境変数を作成し、それぞれの値に設定します。
- AUTOMATOR_CONFIG_KEY: 手順1からの値
- AUTOMATOR_PORT: 8089
- SSL_MODE: none
- WEBSITES_PORT: 8089

[Apply]をクリックします。

7. Diagnosticsをセットアップ

[Diagnostic settings]を選択し、「+ Add diagnostic setting」をクリックします。

診断設定に名前を付けます。
[App Service Console logs]を選択します。
[App Service Application logs]を選択します。
[Send to Log Analytics workspace]を選択します。
- Log Analyticsを選択するか、新規で作成します。

8. ログをセットアップ

メインメニューから[Logs]を選択します。[X]をクリックしてクエリウィンドウを閉じます。

以下は、Dockerデプロイメントと起動ログを見る手順となります。

AppServicePlatformLogs

project TimeGen=substring(TimeGenerated, 0, 19), Message
sort by TimeGen desc

以下は、アプリケーションエラーログを見る手順となります。

AppServiceConsoleLogs

project TimeGen=substring(TimeGenerated, 0, 19), ResultDescription
sort by TimeGen desc

9. App Serviceログのセットアップ

メインメニューの「Monitoring」の箇所から[App Service Logs]を選択します。次に、「Application logging」の[File System]を選択し、任意の保持期間を設定します。

[Save]をクリックします。

10. Log Streamを見る

メインメニューの「Overview」から[Log Stream]を選択し、オートメーターサービスが接続され、正しくログが記録されていることを確認します。

11. Health Checkの構成

メインメニューの「Monitoring」から[Health check]を選択します。次に、ヘルスチェック機能を有効にし、パスの値を「/health」に設定します。[Save]をクリックして設定を保存し、もう一度[Save] をクリックして変更を確定します。

12. アクセス制限を構成

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」 (ルールの追加) で、受信ファイアウォールルールを追加します。以下のページをご参照の上、それぞれの地域で「Network Firewall Setup」 (ネットワークファイアウォールのセットアップ) となっているKeeper公開IPアドレスへのトラフィックを制限する必要があります。

イングレス要件

[Add rule]をクリックします。

[Save]をクリックして構成を保存します。

13. Keeperコマンダーへログイン

オートメーター構成の最終ステップを実行するには、Keeperコマンダーが必要です。これはどこからでも実行できます。サーバーにインストールする必要はありません。ワークステーションまたはサーバーに、KeeperコマンダーCLI をインストールします。バイナリインストーラーを含むインストール手順については、こちらのページをご参照ください。

インストール後、Keeperコマンダーを起動するか、既存のターミナルからkeeper shellと入力してセッションを開き、loginコマンドを使用してログインします。オートメーターを設定するには、Keeper管理者またはSSOノードを管理できる管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com

  _  __  
 | |/ /___ ___ _ __  ___ _ _ 
 | ' </ -_) -_) '_ \/ -_) '_|
 |_|\_\___\___| .__/\___|_|
 v16.x.xxx    |_|

 password manager & digital vault

Logging in to Keeper Commander
Enter password for admin@company.com
Password: ********************
Successfully authenticated with Master Password
Syncing...
Decrypted [58] record(s)

My Vault>

14. オートメーターを作成

automator createから始まる一連のコマンドを使用してオートメーターを作成します。

My Vault> automator create --name "My Automator" --node "Azure Cloud"

ノード名 (この場合は「Azure Cloud」) は、以下のように管理コンソールUIから取得します。

コマンドを実行すると、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: 1477468749950
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

「URL」はまだ入力されていないことにご留意ください。これは、手順5のDefault Domainの値です。

以下のように、「automator edit」コマンドを実行します。これにより、URL が設定され、スキル (team、team_for_user、device) も設定されます。

automator edit --url https://<Default domain> --skill=team --skill=team_for_user --skill=device "My Automator"

次に、キーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい構成でオートメーターを初期化します。

automator init "My Automator"

サービスを有効にします。

automator enable "My Automator"

この時点で構成は完了となります。

外部のヘルスチェックについては以下のURLをご使用ください。

https://<server>/health

以下は curl コマンドの例となります。

$ [rainer@iradar keeper]$ curl -vk https://keeperapprovalautomator.azurewebsites.net/health
* About to connect() to keeperapprovalautomator.azurewebsites.net port 443 (#0)
*   Trying 40.112.243.106...
* Connected to keeperapprovalautomator.azurewebsites.net (40.112.243.106) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*       subject: CN=*.azurewebsites.net,O=Microsoft Corporation,L=Redmond,ST=WA,C=US
*       start date: Oct 31 23:08:36 2023 GMT
*       expire date: Jun 27 23:59:59 2024 GMT
*       common name: *.azurewebsites.net
*       issuer: CN=Microsoft Azure TLS Issuing CA 01,O=Microsoft Corporation,C=US
> GET /health HTTP/1.1
> User-Agent: curl/7.29.0
> Host: keeperapprovalautomator.azurewebsites.net
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 2
< Content-Type: text/plain
< Date: Sat, 23 Mar 2024 05:08:13 GMT
< Server: Jetty(11.0.20)
< Strict-Transport-Security: max-age=31622400; includeSubDomains
<
* Connection #0 to host keeperapprovalautomator.azurewebsites.net left intact

ユーザー体験のテスト

Azure App Gateway (高度な設定)

Azure App Gatewayサービスを使用してKeeperオートメーターをAzure Container Instancesにデプロイ

概要

本ガイドでは、Azure Application Gatewayを使用して安全なVNetでKeeperオートメーターを公開するための手順を解説します。この方式は、Azureコンテナーアプリの設定よりも高度となりますので、Azure App Gatewayや暗号化されたSAMLリクエストを使用する必要がない場合は、Azureコンテナーアプリ方式をご使用ください。

この方式では、すでにSSL証明書をお持ちであることを確かにしてください。お持ちでない場合は、カスタムSSL証明書ページの手順をご参照ください。

手順

Azureクラウドシェルを開く

portal.azure.comにログインし、クラウドシェルのアイコンをクリックします。

ご希望の地域でリソースグループを作成

Azureにリソースグループがまだ存在しない場合は作成します。こちらの例ではeastusの地域を使用していますが、必ずお客様の地域をご使用ください。

az group create --name keeper_automator_rg --location eastus

ストレージアカウントの作成

ストレージアカウントがまだ存在しない場合は作成します。正しい地域 (useeast) と上のリソースグループ名を使用するようにします。keeperautomatotorstorageを置き換えるのに選択する名前は、azureではグローバルで他に存在しないものである必要があります。

az storage account create -n -g keeper_automator_rg -l eastus --sku Standard_LRS

ファイルシェアの作成

ファイルシェアが存在しない場合は作成します。

az storage share create --account-name --name keeperautomatorfileshare

現在のシェアを表示します。

az storage share list --account-name

コンテナー用にバーチャルネットワーク (VNet) と１件のSubnetを作成

az network vnet create --address-prefixes 10.100.0.0/16 --name keeper_automator_vnet --resource-group keeper_automator_rg --subnet-name keeper_automator_subnet --subnet-prefixes 10.100.2.0/24

バーチャルネットワークをサービスエンドポイントで更新

az network vnet subnet update -g keeper_automator_rg -n keeper_automator_subnet --vnet-name keeper_automator_vnet --service-endpoints Microsoft.Storage --delegations Microsoft.ContainerInstance/containerGroups

ストレージキーの取得

アカウントのストレージキーを見つけるには以下のコマンドを使用します。ストレージアカウント名は実際の名前に置き換えます。

az storage account keys list --resource-group keeper_automator_rg --account-name

以下のようなkey1の値をコピーします。

"value": "zuVgm9xnQNnxCQzY=5n4Ec6kxhDn2xMZSfpwZnTeqsyGaHd5Abn584mpAP3xamg3rGns4=Fd7FeFsaR6AgtnqW=="

サブネットIDの取得

サブネットIDを見つけるには以下のコマンドを実行します。

az network vnet subnet list --resource-group keeper_automator_rg --vnet-name keeper_automator_vnet | grep "id"

サブネットIDのパスを _subnetで終わるところまで全部コピーします。以下はその例です。

"id": "/subscriptions/abc123-abc123-abc-123/resourceGroups/keeper_automator_rg/providers/Microsoft.Network/virtualNetworks/keeper_automator_vnet/subnets/keeperautomator_appgw_subnet"

YAMLコンテナーファイルの作成

ローカルで、automatorなどの名前でフォルダを作成します。

任意のエディタを使用して、そのフォルダー内に以下の内容を含むautomator.ymlというファイルを作成します。

automator.yml

apiVersion: '2021-07-01'
location: eastus
name: keeperautomatorcontainer
properties:
  containers:
  - name: keeperautomatorcontainer
    properties:
      image: keeper/automator:latest
      ports:
      - port: 443
        protocol: TCP
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
      volumeMounts:
        - name: automatorvolume
          mountPath: /usr/mybin/config
  osType: Linux
  restartPolicy: Always
  sku: Standard
  volumes:
  - name: automatorvolume
    azureFile:
      shareName: keeperautomatorfileshare
      readOnly: false
      storageAccountName: 
      storageAccountKey: 
  subnetids:
    - id: /subscriptions//path/to/subnets/keeper_automator_subnet
      name: keeper_automator_subnet
tags: null
type: Microsoft.ContainerInstance/containerGroups

前の手順の設定に基づいて文字列の値を変更する必要がある箇所が複数あります。

サブネットIDは、手順8で取得したIDのフルパスと一致する必要があります。
storageAccountNameは手順3の値と一致する必要があります。
storageAccountKeyは手順7の値と一致する必要があります。

SSL証明書とSSLパスワードファイルのアップロード

Azureインターフェイスから、[リソースグループ] > [ストレージアカウント] > [ファイルシェア]に移動し、作成したオートメーターファイルシェアに移動します。ここから、automator.ymlファイル、SSL証明書ファイル、SSL証明書パスワードファイルをアップロードします。

ファイルの名前が automator.yml ssl-certificate.pfx および ssl-certificate-password.txt であることを確認してください。

3つのファイルをローカルのCLIワークスペースにコピーします

az storage copy -s https://keeperautomatorstorage.file.core.windows.net/keeperautomatorfileshare/automator.yml -d .

az storage copy -s https://keeperautomatorstorage.file.core.windows.net/keeperautomatorfileshare/ssl-certificate.pfx -d .

az storage copy -s https://keeperautomatorstorage.file.core.windows.net/keeperautomatorfileshare/ssl-certificate-password.txt -d .

コンテナーインスタンスの作成

automator.ymlの設定を使用してコンテナーを作成します。

az container create -g keeper_automator_rg -f automator.yml

応答でコンテナの内部IPを取得します。

az container show --name keeperautomatorcontainer --resource-group keeper_automator_rg --query ipAddress.ip --output tsv

後で使用するために、このIPの変数を設定します。以下はその例となります。

$aciPrivateIp=10.100.2.4

aciPrivateIp=10.100.2.4

アプリケーションゲートウェイサブネットの作成

az network vnet subnet create --name keeperautomator_appgw_subnet --resource-group keeper_automator_rg --vnet-name keeper_automator_vnet --address-prefix 10.100.1.0/24

アプリケーションゲートウェイの作成

az network application-gateway create --name KeeperAutomatorAppGateway --location eastus --resource-group keeper_automator_rg --sku Standard_v2 --public-ip-address AGPublicIPAddress --cert-file ssl-certificate.pfx --cert-password --vnet-name keeper_automator_vnet --subnet keeperautomator_appgw_subnet --frontend-port 443 --http-settings-port 443 --http-settings-protocol Https --servers 10.100.2.4 --priority 100

XXXXXXの箇所でSSL証明書のパスワードが置き換えられていることを確かにします。

パブリックIPを見つける

Azure portalのインターフェイスで、[リソースグループ] > [アプリゲートウェイ]に移動し、パブリックIPアドレスをメモします。

DNSのルーティング

オートメーターサービスのDNS (例: automator.company.com) が、Azureコンテナーサービスが手順 15で生成したIPアドレスを指していることを確かにします。

DNS名はSSL証明書のサブジェクト名と一致する必要があります。一致しない場合、リクエストは失敗します。

正常性プローブの作成

正常性プローブは、オートメーターサービスが実行されていることをApp Gatewayに通知します。Azure portalのインターフェイスからAutomator App Gatewayを開き、左側のメニューから[正常性プローブ]をクリックします。

次に、以下のスクリーンショットに見られる設定で新しい正常性プローブを作成します。必ずホストを手順16で設定したFQDNに置き換えます。

[テスト]をクリックしてプローブを追加します。コンテナIPがホスト名に適切にアドレス指定されていれば、テストは成功します。

ウェブアプリケーションファイアウォールの設定

Azure portalのインターフェイスからAutomator App Gatewayを開き、左側の[ウェブアプリケーションファイアウォール] をクリックします。 WAF V2を有効にして以下の画面のように設定します。

[ルール]タブをクリックし、[OWASP 3.2]に設定されたルールを選択して、[有効]および[保存]をクリックします (重要な手順となります）。

🎉 Azure内でのインストールは完了です。

最後にKeeperコマンダーを使ってオートメーターの設定を行います。

Keeperコマンダーのインストール

この時点では、サービスは実行されていますがまだKeeperとは通信ができません。

ワークステーション、サーバー、コンピューターのどれかにKeeperコマンダーCLIをインストールします。初期設定にのみ使用します。バイナリインストーラーを含むインストール手順についてはこちらのページをご参照ください。コマンダーを開いた後、loginコマンドでログインします。オートメーターをセットアップするにはKeeper管理者、またはSSOノードを管理する権限を持つ管理者としてログインする必要があります。

My Vault> login admin@company.com

コマンダーでの初期設定

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効にします。

automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールのUIから取得します。

コマンドの出力には、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: 1477468749950
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

URLはまだ入力されていません。選択したFQDNを使用してURLを編集します。

automator edit --url=https://automator.lurey.com --skill=team --skill=team_for_user --skill=device "My Automator"

次に、キーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

サービスを有効にします。

automator enable "My Automator"

この時点で設定は完了です。

自動ヘルスチェックには以下のURLをご使用になれます。

https://<server>/health

以下はcurlコマンドを使用した例です。

$ curl https://automator.lurey.com/health
OK

当URLはウェブブラウザでは開きません。

AD FSを使用した環境の場合

IDプロバイダとしてAD FSを使用してKeeperオートメーターを有効にする場合、以下の手順に従ってKeeper証明書を更新するまでログインできません。

Keeper管理コンソールへログインします。
[管理] > [SSOノード] > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[Export SP Cert]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。

セットアップは完了です。

これでオートメーターサービスが実行された状態になりました。

Azure Portal

Azure Portalの「コンテナーインスタンス」システムで、コンテナーが実行されているのを確認できます。 /bin/shを使用してコンテナーに接続し、実行ログを表示することもできます。

コンテナーの再起動時にIPを更新

この設定に基づいてコンテナーを再起動すると、/24サブネットから新しい IP アドレスが割り当てられることがあります。新しいIPをすばやく見つけて、正しいIPでApplication Gatewayバックエンドプールを更新するには、Azure CLIから以下のスクリプトを実行します。

# change these 3 variables according to your setup
RESOURCE_GROUP="keeper_automator_rg"
GATEWAY_NAME="KeeperAutomatorAppGateway"
CONTAINER_NAME="keeperautomatorcontainer"

BACKEND_POOL_NAME="appGatewayBackendPool"

CONTAINER_IP=$(az container show --resource-group $RESOURCE_GROUP --name $CONTAINER_NAME --query 'ipAddress.ip' --output tsv)

az network application-gateway address-pool update --resource-group $RESOURCE_GROUP --gateway-name $GATEWAY_NAME --name $BACKEND_POOL_NAME --servers $CONTAINER_IP

オートメーターサービスのテスト

Keeperオートメーターがデプロイされましたので、エンドユーザー体験のテストが可能です。ユーザーが SSO IDプロバイダーで認証した後は、承認を求めるプロンプトは必要ありません。

最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトが表示されない場合、オートメーターが正常に機能しています。

AWS Elastic Containerサービス

AWS ECS (Fargate)サービスでKeeperオートメーターを使う

概要

この例では、必要最小限の依存関係で最も簡単な方法でAmazon ECSでKeeperオートメーターサービスを起動する方法について解説します。

要件

AWSを介したマネージドSSL証明書

1. Automator Configキーの作成

オペレーティングシステムに応じて以下のいずれかの方法を使用してURL エンコード形式で256ビットAESキーを生成します。

Mac/Linux

openssl rand -base64 32

Windows

[Byte[]]$key = New-Object Byte[] 32; [System.Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($key); [System.Convert]::ToBase64String($key)

タスク定義に設定された環境変数としてこの値を保存します。

2. VPCの作成

VPCが存在しない場合は、複数のサブネット、ルートテーブル、インターネットゲートウェイを持つ基本的なVPCをセットアップする必要があります。こちらの例では、以下のリソースマップに見られるようにインターネットゲートウェイを備えたVPC内に3つのサブネットがあります。

3. CloudWatchロググループの作成

ログをキャプチャしたい場合 (推奨)、[CloudWatch] > [ロググループの作成]に移動します。

ロググループにautomator-logsという名前を付けます。

4. タスク実行IAMロールの作成

[IAM] > [ロールの作成]へ行きます。

[AWSサービス]を選択します。

次に、Elastic Container Serviceを検索して選択します。

[Elastic Container Serviceタスク]を選択し、[次へ]をクリックします。

[AmazonECSTaskExecution]ポリシーをロールに追加し、[次へ]をクリックします。

ECSTaskWritetoLogsという名前を割り当てて、ロールを作成します。

次の手順で使用するため、このロールのARNをメモしておきます。

本事例ではarn:aws:iam::373699066757:role/ECSTaskWritetoLogsとなります。

5. ECSのセキュリティグループを作成

[EC2] > [セキュリティグループ]に移動し、[セキュリティグループの作成]をクリックします。

Keeperテナントがホストされている地域に応じて、Keeperクラウドからのhttpsポート443を許可する受信ルールを作成する必要があります。各テナントの場所のIPのリストについては以下をご覧ください。以下の例では米国データセンターとなります。

また、テストとトラブルシューティングのためにワークステーションの外部IPアドレスを追加することを推奨します。

MyAutomatorServiceなどの名前を割り当て、[作成]をクリックします。

Keeperテナント地域

IP1

IP2

54.208.20.102/32

34.203.159.189/32

US GovCloud

18.252.135.74/32

18.253.212.59/32

52.210.163.45/32

54.246.185.95/32

3.106.40.41/32

54.206.208.132/32

35.182.216.11/32

15.223.136.134/32

54.150.11.204/32

52.68.53.105/32

以下のURLから見つけられるご自身のIPを忘れずに追加してください。

https://checkip.amazonaws.com

6. セキュリティグループをインバウンドルールのリストに追加

セキュリティグループを保存した後、受信ルールを再度編集します。今回は以下の内容を追加します。

ソースがセキュリティグループに設定された状態のHTTPポート8089 を追加します。これにより、ALBからネットワーク内のコンテナへのトラフィックとヘルスチェック処理が可能となります。

7. Elastic Container Serviceクラスターの作成

Amazon Elastic Container Serviceへ進みます。

[クラスターの作成]を選択し、クラスター名とVPCを割り当てます。こちらの例では、デフォルトの[AWS Fargate (サーバーレス)]インフラストラクチャを使用しています。

デフォルトの名前空間はautomatorで問題ありません
[インフラストラクチャ]は AWS Fargate (サーバーレス) に設定します
[作成]をクリックします

8. ECSタスク定義の作成

任意のテキストエディタで、以下のJSONタスク定義ファイルをコピーして保存します。

重要 JSONファイルに以下の変更を加えます。

24行目の XXX (REPLACE THIS) XXX を上記の手順1で作成した秘密キーに変更します。
37行～39行を手順3のロググループの名前と場所に置き換えます。
44行目のXXXをAWSロールに固有のロールIDに変更します（手順4の373699066757）。

{
    "family": "automator",
    "containerDefinitions": [
        {
            "name": "automator",
            "image": "keeper/automator:latest",
            "cpu": 1024,
            "portMappings": [
                {
                    "containerPort": 8089,
                    "hostPort": 8089,
                    "protocol": "tcp",
                    "appProtocol": "http"
                }
            ],
            "essential": true,
            "environment": [
                {
                    "name": "SSL_MODE",
                    "value": "none"
                },
                {
                    "name": "AUTOMATOR_CONFIG_KEY",
                    "value": "XXX (REPLACE THIS) XXX"
                },
                {
                    "name": "AUTOMATOR_PORT",
                    "value": "8089"
                }
            ],
            "mountPoints": [],
            "volumesFrom": [],
            "readonlyRootFilesystem": false,
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "automator-logs",
                    "awslogs-region": "eu-west-1",
                    "awslogs-stream-prefix": "container-2"
                }
            }
        }
    ],
    "executionRoleArn": "arn:aws:iam::XXX:role/ecsTaskExecutionRole",
    "networkMode": "awsvpc",
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "cpu": "1024",
    "memory": "3072",
    "runtimePlatform": {
        "cpuArchitecture": "X86_64",
        "operatingSystemFamily": "LINUX"
    }
}

次に、[Elastic Container Service] > [タスク定義] > [JSONからタスクを作成]に移動します。

既存のJSONを削除し、変更したJSONファイルをボックスにコピーして貼り付け、[作成] をクリックします。

このタスク定義は、インスタンスのCPU/メモリ要件に応じて変更できます。

9. SSL証明書をAWS Certificate Managerにアップロード

AWSのアプリケーションロードバランサーがオートメーターのクエストに対応するには、SSL証明書が AWS Certificate Managerによって管理されている必要があります。AWSが管理する証明書をインポートするか作成します。

AWSコンソールから[Certificate Manager]を開きます。
[リクエスト]をクリックします。
パブリック証明書をリクエストし、[次へ]をクリックします。
automator.lurey.comなど、オートメーターサービスのドメイン名を入力します。
任意の検証方式とキーアルゴリズムを選択します。
[リクエスト]をクリックします。
証明書の一覧から証明書リクエストをクリックします。

Route53を使用してドメインを管理している場合は証明書をクリックし、[Route53でレコードを作成]を選択するとドメインが即座に検証され証明書が作成されます。別のDNSプロバイダーを使用する場合は、画面に見られるようにCNAMEレコードを作成する必要があります。

CNAMEレコードを作成すると、ドメインは数分以内に有効となります。

この証明書は、手順11でアプリケーションロードバランサーを作成する際に参照されます。

10. ターゲットグループの作成

[EC2] > [ターゲットグループ]に移動し、[ターゲットグループの作成] をクリックします。

ターゲットの種類として[IPアドレス]を選択します。
ターゲットグループ名にautomatortargetgroupまたは任意の名前を入力します。
ポート8089のHTTPプロトコルを選択します。
ECSクラスターを含むVPCを選択します。
HTTP1を選択します。
[ヘルスチェック] で、ヘルスチェックプロトコルとして[HTTP]を選択します。
ヘルスチェックのパスとして/healthと入力します。
[ヘルスチェックの詳細設定]を展開します。
[オーバーライド]を選択し、ポート8089を入力します。
[次へ]をクリックします。
まだターゲットを選択せずに[ターゲットグループの作成]をクリックします。

11. アプリケーションロードバランサー (ALB) の作成

[EC2] > [ロードバランサー] > [ロードバランサーの作成]に移動します。

[Application Load Balancer] > [作成]を選択します。

automarnalbなどの任意の名前を割り当てます。
スキームはInternet-facingとなります。
IPアドレスの種類: IPv4
[ネットワークマッピング]の箇所で、ECSサービスをホストするVPCとサブネットを選択します。
セキュリティグループで、手順4で作成したMyAutomatorServiceを選択します。
[リスナーとルーティング]の箇所でHTTPSポート443を選択し、ターゲットグループで前の手順で作成したターゲットグループ (automatortargetgroup) を選択します。
[セキュアリスナー設定]で、手順9でAWS Certificate ManagerにアップロードしたACMからのSSL証明書を選択します。
[ロードバランサーの作成]をクリックします。

12. ECSサービスの作成

[Elastic Container Service] > [タスク定義] > 手順8で作成したタスクを選択します。

このタスク定義から、[デプロイ] > [サービスの作成]をクリックします。

automatorの既存のクラスターを選択します。
サービス名にautomatorserviceまたは任意の名前を割り当てます。
必要なタスクの数については、とりあえず1に設定します。設定が完了後に実行したいタスクの数を増やせます。
[ネットワーク]でVPCとサブネットを選択し、既存のセキュリティグループを手順4で作成した ECSセキュリティグループに置き換えます。この場合はMyAutomatorServiceとなります。
パブリックIPをONにします。
[ロードバランシング]で、ロードバランサーの種類として[Application Load Balancer]を選択します。
既存のロードバランサーを使用し、手順11で作成したautomatralbを選択します。
既存のリスナーを使用し、443:HTTPSリスナーを選択します。
既存のターゲットグループを使用し、手順10のターゲットグループを選択します。
ヘルスチェックのパスを/healthに設定します。
ヘルスチェックプロトコルをHTTPに設定します。
[作成]をクリックします。

数分後にサービスが起動します。

13. DNSの更新

DNS名がRoute53によってホストおよび管理されていると仮定します。

Route53 > レコードの作成または編集に移動します。

Aレコードを作成します。
エイリアスとして設定します。
トラフィックを[アプリケーションおよびクラシックロードバランサーへのエイリアス]にルーティングします。
AWS地域を選択します。
automaticalbアプリケーションロードバランサーを選択します
[シンプルルーティング]を選択します。
[保存]を選択します。

次の手順では、タスクを1件だけ実行した状態でKeeperコマンダーを使用してオートメーターを設定します。

14. Keeperコマンダーのインストール

この時点ではサービスは実行されていますが、まだKeeperと通信できない状態です。

ご利用のワークステーション、サーバー、コンピューターのどれかにKeeperコマンダーCLIをインストールします。初期設定にのみ使用します。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。

コマンダーをインストールした後、keeper shellと入力してセッションを開いてからloginコマンドを使用してログインします。オートメーターをセットアップするには、Keeper管理者またはSSOノードを管理する権限を持つ管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com
.
.
My Vault>

15. コマンダーでの初期設定

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効にします。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。

コマンドの出力には、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: 1477468749950
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

サービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

自動ヘルスチェックには以下のURLをご使用になれます。

https://<server>/health

以下はcurlコマンドを使用した例です。

$ curl https://automator.lurey.com/health
OK

本セットアップ例では、ロードバランサーはHTTP ポート8089経由でターゲットインスタンスにヘルスチェックを転送します。

16. ユーザー体験のテスト

Keeperオートメーターが1件のタスクを実行した状態でデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。

最も簡単なテスト方法は、ブラウザでシークレットモードのウィンドウを開いてKeeperウェブボルトへアクセスし、SSOクラウドでログインすることとなります。デバイスの承認を求めるプロンプトは表示されなくなります。

承認が機能しましたので、実行するタスクの数を増やせます。

17. タスク定義の更新 (任意)

Keeperオートメーターサービスは、処理するリクエストの数が少ないため単一のコンテナ上で問題なく快適に実行できます。ただし、複数のコンテナを実行したい場合は以下の手順に従ってください。

ECSサービス画面からautomatorserviceをクリックします。
[サービスを更新]をクリックします。
[新規デプロイメントを強制]するのチェックボックスを選択します。
最新のタスクリビジョンが選択されていることを確かにします。
[必要なタスク]を実行したいコンテナの数に設定します。
[更新]をクリックします。
数分後、新しいコンテナがデプロイされます。すべてのコンテナがアクティブになるまで待ちます。
Keeperコマンダーを起動します (あるいはまだ開いたままである可能性があります）。

各コンテナーに対して、オートメーターセットアップ、初期化、有効化を実行する必要があります。

以下は3つのコンテナが実行されている場合となります。

automator setup "My Automator"
automator setup "My Automator"
automator setup "My Automator"

automator init "My Automator"
automator init "My Automator"
automator init "My Automator"

automator enable "My Automator"
automator enable "My Automator"
automator enable "My Automator"

ログとモニター

オートメーターログは、ECSサービスの[ログ]タブまたはCloudWatchで検索およびモニターできます。

KSMを使用したAWS Elastic Container サービス (高度な設定)

ECS (Fargate)サービスを使用してKeeperオートメーターを実行し、機密情報のストレージとして Keeperシークレットマネージャーを実行

概要

本ガイドでは、Fargateを使用してAmazon ECSでKeeperオートメーターサービスを起動する方法について解説しながら、公開されたDockerコンテナのシークレット設定を取得するためにKeeperシークレットマネージャーを使用する方法を解説します。

Keeperのセットアップ

本デプロイでは、Keeperシークレットマネージャーを使用する必要があるため、オートメーターサービスを公開するためにKeeperボルトおよびSSL証明書を設定するために必要な手順を確認します。

1. SSL証明書

こちらのページの説明に従ってSSL証明書を作成します。

この手順が完了すると、ssl-certificate.pfxとssl-certificate-password.txtの2つのファイルが作成されます。

2. 共有フォルダの作成

ボルト内に共有フォルダを作成します。このフォルダーは、シークレットマネージャーアプリケーション以外の誰にも共有されません。

3. 添付ファイルの追加

共有フォルダにレコードを作成し、レコードUIDをメモします。SSL証明書とSSL証明書パスワードファイルを共有フォルダのレコードにアップロードします。

4. オートメータープロパティファイルの追加

以下の内容のkeeper.propertiesという新しいファイルをアップロードします。

ssl_mode=certificate
ssl_certificate_file=/config/ssl-certificate.pfx
ssl_certificate_file_password=
ssl_certificate_key_password=
automator_host=localhost
automator_port=443
disable_sni_check=true
persist_state=true

disable_sni_check=trueは、マネージドロードバランサーでオートメーターサービスを実行する場合に必要になります。

共有フォルダとレコードは以下のようになります。

5. KSMアプリケーションの作成

コンテナー内にKeeperシークレットマネージャー (KSM) アプリケーションを作成します。シークレットマネージャーをご使用でない場合は、こちらのガイドをご参照ください。アプリケーションの名前はオートメーターですが問題ありません。

6. KSMアプリケーションを共有フォルダに添付

共有フォルダを編集し、オートメーターアプリケーションをこのフォルダに追加します。

7. KSMデバイス設定の作成

シークレットマネージャーアプリケーションを開き、[デバイス]タブをクリックして、[デバイスの追加]をクリックします。Base64設定を選択します。この設定をダウンロードして保存し、ECSタスク定義で使用できるようにします。

AWSのセットアップ

1. VPCの作成

VPCが存在しない場合は、複数のサブネット、ルートテーブル、インターネットゲートウェイを持つ基本的なVPCをセットアップする必要があります。こちらの例では、以下のリソースマップに見られるように、インターネットゲートウェイを備えたVPC内に3つのサブネットが含まれています。

2. CloudWatchロググループの作成

[CloudWatch] > [ロググループの作成]に移動します。

ロググループをautomator-logsと名付けます。

3. タスク実行IAMロールの作成

[IAM] > [ロールの作成]へ行きます。

[AWSサービス]を選択します。

次に、Elastic Container Serviceを検索して選択します。

[Elastic Container Serviceタスク]を選択し、[次へ]をクリックします。

[AmazonECSTaskExecution]ポリシーをロールに追加し、[次へ]をクリックします。

ECSTaskWritetoLogsという名前を割り当てて、ロールを作成します。

このロールのARNをメモして次の手順で使用できるようにします。

本事例ではarn:aws:iam::373699066757:role/ECSTaskWritetoLogsとなります。

4. ECSのセキュリティグループを作成

[EC2] > [セキュリティグループ]に移動し、[セキュリティグループの作成]をクリックします。

また、テストとトラブルシューティングのためにご使用のワークステーションの外部IPアドレスを追加することを推奨します。

MyAutomatorServiceなどの名前を割り当て、[作成]をクリックします。

Keeperテナント地域

IP1

IP2

54.208.20.102/32

34.203.159.189/32

US GovCloud

18.252.135.74/32

18.253.212.59/32

52.210.163.45/32

54.246.185.95/32

3.106.40.41/32

54.206.208.132/32

35.182.216.11/32

15.223.136.134/32

54.150.11.204/32

52.68.53.105/32

セキュリティグループを保存した後、受信ルールを再度編集します。今回はHTTPSポート443を追加し、ドロップダウンでセキュリティグループを選択します。これにより、ロードバランサーは状況を監視してトラフィックを分散できるようになります。

5. EFS用セキュリティグループの作成

クラスターからEFSへのNFSアクセスを制御する別のセキュリティグループを作成します。

[EC2] > [セキュリティグループ]に移動し、[セキュリティグループの作成]をクリックします。

MyAutomatorEFSのように名前を設定します。

NFSのタイプを選択してカスタムを選択してから、ECSクラスターの前の手順で作成したセキュリティグループを選択します。

[セキュリティグループの作成]をクリックします。

次の手順のためにセキュリティグループIDをメモしておきます。この場合はsgr-089fea5e4738f3898となります。

6. 2つのElastic File Systemボリュームを作成

現在、オートメーターサービスは2つの異なるフォルダにアクセスする必要があります。本セットアップ例では、SSL証明書とSSLパスフレーズファイルを保存するために1つのボリュームを作成しています。2つ目のボリュームには、オートメーターサービスのプロパティファイルが保存されます。これら3つのファイルはKeeperのレコードに含まれています。

[AWS] > [Elastic File System]に移動し、[ファイルシステムの作成]をクリックします。

automator_configと名付けて、[作成]をクリックします。

再び[Elastic File System]に移動し、[Create file system]をクリックします。automator_settingsと名付けて[作成]をクリックします。

表示されるファイルシステムID (fs-xxxなど) は、ECSタスク定義で使用されます。

1 分後、2 つのファイルシステムが使用可能になります。それぞれをクリックしてから[ネットワーク]タブを選択し、[管理]をクリックします。

各サブネットのセキュリティグループを上記の手順で作成したもの (MyAutomatorEFSなど) に変更し、[保存]をクリックします。作成された両方のファイルシステムに同じネットワーク変更を加えます。

7. Elastic Container Serviceクラスターの作成

Amazon Elastic Container Serviceへ進みます。

[クラスターの作成]を選択し、クラスター名とVPCを割り当てます。こちらの例では、デフォルトの[AWS Fargate (サーバーレス）]インフラストラクチャを使用しています。

デフォルトの名前空間はautomatorで問題ありません
[インフラストラクチャ]は AWS Fargate (サーバーレス) に設定します
[作成]をクリックします

8. ECSタスク定義の作成

任意のテキストエディタで、以下のJSONタスク定義ファイルをコピーして保存します。

JSONファイルに以下の変更を加えます。

本ガイドの冒頭で作成したKeeperシークレットマネージャーのXXXCONFIGXXX値をBase64設定に変更します。
3箇所あるXXXXXを、KSMがアクセスしているボルトの共有フォルダ内のSSL証明書、SSL証明書パスワード、設定ファイルが含間れるレコードUIDに変更します。
2つのファイルシステム ID (fs-XXX) を、上記の手順からのものに変更します。
ロールIDのXXXをAWSロールに固有のものに変更します。
2箇所のeu-west-1値を、ECSサービスの地域に変更します。

{
    "family": "automator",
    "containerDefinitions": [
        {
            "name": "init",
            "image": "keeper/keeper-secrets-manager-writer:latest",
            "cpu": 1024,
            "memory": 1024,
            "portMappings": [],
            "essential": false,
            "environment": [
                {
                    "name": "KSM_CONFIG",
                    "value": "XXXCONFIGXXX"
                },
                {
                    "name": "SECRETS",
                    "value": "XXXXX/file/ssl-certificate.pfx > file:/usr/mybin/config/ssl-certificate.pfx\nXXXXX/file/ssl-certificate-password.txt > file:/usr/mybin/config/ssl-certificate-password.txt\nXXXXX/file/keeper.properties > file:/usr/mybin/settings/keeper.properties"
                }
            ],
            "mountPoints": [
                {
                    "sourceVolume": "automatorconfig",
                    "containerPath": "/usr/mybin/config"
                },
                {
                    "sourceVolume": "automatorsettings",
                    "containerPath": "/usr/mybin/settings"
                }
            ],
            "volumesFrom": [],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "automator-logs",
                    "awslogs-region": "eu-west-1",
                    "awslogs-stream-prefix": "container-1"
                }
            }
        },
        {
            "name": "main",
            "image": "keeper/automator:latest",
            "cpu": 1024,
            "memory": 4096,
            "portMappings": [
                {
                    "containerPort": 443,
                    "hostPort": 443,
                    "protocol": "tcp"
                }
            ],
            "essential": true,
            "environment": [],
            "mountPoints": [
                {
                    "sourceVolume": "automatorconfig",
                    "containerPath": "/usr/mybin/config"
                },
                {
                    "sourceVolume": "automatorsettings",
                    "containerPath": "/usr/mybin/settings"
                }
            ],
            "volumesFrom": [],
            "dependsOn": [
                {
                    "containerName": "init",
                    "condition": "SUCCESS"
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "automator-logs",
                    "awslogs-region": "eu-west-1",
                    "awslogs-stream-prefix": "container-2"
                }
            }
        }
    ],
    "executionRoleArn": "arn:aws:iam::XXX:role/ECSTaskWritetoLogs",
    "networkMode": "awsvpc",
    "volumes": [
        {
            "name": "automatorconfig",
            "efsVolumeConfiguration": {
                "fileSystemId": "fs-XXX",
                "rootDirectory": "/",
                "transitEncryption": "ENABLED"
            }
        },
        {
            "name": "automatorsettings",
            "efsVolumeConfiguration": {
                "fileSystemId": "fs-XXX",
                "rootDirectory": "/",
                "transitEncryption": "ENABLED"
            }
        }
    ],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "cpu": "2048",
    "memory": "5120"
}

次に、[Elastic Container Service] > [タスク定義] > [JSONからタスクを作成]に移動します。

既存のJSONを削除し、変更したJSONファイルをボックスにコピーして貼り付けてから[作成]をクリックします。

このタスク定義は、インスタンスのCPU/メモリ要件に応じて変更できます。

9. SSL証明書をAWS Certificate Managerにアップロード

AWSのアプリケーションロードバランサーがオートメーターのリクエストに対応するには、SSL証明書が AWS Certificate Managerによって管理されている必要があります。

AWS Certificate Managerへ移動し、[インポート]をクリックします。

ご利用のワークステーション上でSSL証明書 (.pfx) ファイルを、 PEMエンコードされた証明書本体、PEMエンコードされた秘密キー、PEMエンコードされた証明書チェーンに変換する必要があります。

.pfxファイルはすでに存在するので以下のopensslコマンドを使用します。ssl-certificate.pfxファイルと証明書パスワードをワークステーションへダウンロードし、以下のコマンドを入力します。

PEMエンコードされた証明書本体の生成

openssl pkcs12 -in ssl-certificate.pfx -out automator-certificate.pem -nodes
openssl x509 -in automator-certificate.pem -out certificate_body.crt

PEMエンコードされた秘密キーの生成

openssl pkey -in automator-certificate.pem -out private_key.key

PEMエンコードされた証明書チェーンの生成

openssl crl2pkcs7 -nocrl -certfile automator-certificate.pem | openssl pkcs7 -print_certs -out certificate_chain.crt

3つのファイルの内容を画面へコピーします。

cat certificate_body.crt | pbcopy
   (証明書本体の箇所へ貼り付け)
   
cat private_key.key | pbcopy
   (証明書秘密キーの箇所へ貼り付け)
   
cat certificate_chain.crt | pbcopy
   (証明書チェーンの箇所へ貼り付け)

10. ターゲットグループの作成

[EC2] > [ターゲットグループ]に移動し、[ターゲットグループの作成] をクリックします。

ターゲットの種類として[IPアドレス]を選択します。
ターゲットグループ名にautomatortargetgroupまたは任意の名前を入力します。
ポート443のHTTPプロトコルを選択します。
ECSクラスターを含むVPC を選択します。
HTTP1を選択します。
[ヘルスチェック] で、ヘルスチェックプロトコルとして[HTTPS]を選択します。
ヘルスチェックのパスとして/healthと入力します。
[次へ]をクリックします。
まだターゲットを選択せずに[ターゲットグループの作成]をクリックします。

11. アプリケーションロードバランサー (ALB) の作成

[EC2] > [ロードバランサー] > [ロードバランサーの作成]に移動します。

[Application Load Balancer] > [作成]を選択します。

automarnalbなどの任意の名前を割り当てます。
スキームはInternet-facingとなります。
IPアドレスの種類: IPv4
[ネットワークマッピング]の箇所で、ECSサービスをホストするVPCとサブネットを選択します。
セキュリティグループで、手順4で作成したMyAutomatorServiceを選択します。
[リスナーとルーティング]の箇所でHTTPSポート443を選択し、ターゲットグループで前の手順で作成したターゲットグループ (automatortargetgroup) を選択します。
[セキュアリスナー設定]で、手順9でAWS Certificate ManagerにアップロードしたACMからのSSL証明書を選択します。
[ロードバランサーの作成]をクリックします。

12. ECSサービスの作成

[Elastic Container Service] > [タスク定義] > 手順8で作成したタスクを選択します。

このタスク定義から、[デプロイ] > [サービスの作成]をクリックします。

automatorの既存のクラスターを選択します。
サービス名にautomatorserviceまたは任意の名前を割り当てます。
必要なタスクの数については、とりあえず1に設定します。設定が完了後に実行したいタスクの数を増やせます。
[ネットワーク]でVPCとサブネットを選択し、既存のセキュリティグループを手順4で作成した ECSセキュリティグループに置き換えます。この場合はMyAutomatorServiceとなります。
パブリックIPはONにします。
[ロードバランシング]で、ロードバランサーの種類として[Application Load Balancer]を選択します。
既存のロードバランサーを使用し、手順11で作成したautomatralbを選択します。
既存のリスナーを使用し、443:HTTPSリスナーを選択します。
既存のターゲットグループを使用し、手順10のターゲットグループを選択します。
[作成]をクリックします。

数分後にサービスが起動します。

13. DNSの更新

DNS名がRoute53によってホストおよび管理されていると仮定します。

Route53 > レコードの作成または編集に移動します。

Aレコードを作成します。
エイリアスとして設定します。
トラフィックを[アプリケーションおよびクラシックロードバランサーへのエイリアス]にルーティングします。
AWS地域を選択します。
automaticalbアプリケーションロードバランサーを選択します。
[シンプルルーティング]を選択します。
[保存]を選択します。

次の手順では、タスクを1件だけ実行した状態でKeeperコマンダーを使用してオートメーターを設定します。

14. Keeperコマンダーのインストール

この時点ではサービスは実行されていますが、まだKeeperと通信できない状態です。

ご利用のワークステーション、サーバー、コンピューターのどれかにKeeperコマンダーCLIをインストールします。初期設定にのみ使用します。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。コマンダーをインストールした後、keeper shellと入力してセッションを開いてからloginコマンドを使用してログインします。オートメーターをセットアップするには、Keeper管理者またはSSOノードを管理する権限を持つ管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com
.
.
My Vault>

15. コマンダーでの初期設定

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効にします。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。

コマンドの出力には、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: 1477468749950
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

サービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

自動ヘルスチェックには以下のURLをご使用になれます。

https://<server>/health

以下はcurlコマンドを使用した例です。

$ curl https://automator.lurey.com/health
OK

本セットアップ例では、ロードバランサーがターゲットインスタンスにヘルスチェックを転送します。

16. ユーザー体験のテスト

Keeperオートメーターが1件のタスクを実行した状態でデプロイされましたので、エンドユーザーの体験をテストできます。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。

承認が機能しましたので、実行するタスクの数を増やせます。

17. タスク定義の更新

ECS画面からオートメーターサービスを開き、[サービスの更新]をクリックします。次に、実行するタスクの数を設定します。

ログとモニター

オートメーターログは、ECSサービスの[ログ]タブまたはCloudWatchで検索およびモニターできます。

LinuxでJavaを使用

スタンドアロンJavaサービスを使用したKeeperオートメーターの実装例

本ガイドでは、Dockerを実行できるLinuxインスタンスでKeeperオートメーターを実行するための手順を解説します。

SSL証明書がすでに用意できていることをご確認ください。用意できていない場合は、SSL証明書作成のページの手順に従ってください。

スタンドアロンJavaサービス

Javaをインストールします

サービスの準備としてJava 17以上がインストールされていることを確かにします。標準のAmazon AWS Linux 2インスタンスでは、以下のコマンドを使用してJava 17 SDKをインストールできます。

[ec2-user@xxx ~]$ sudo amazon-linux-extras install java-openjdk17

どのバージョンが実行中かを確認するには、以下のように入力します。

[ec2-user@xxx ~]$ java --version

サービスをインストールします

オートメーターインスタンスから、Keeperオートメーターサービスをダウンロードして解凍します。

mkdir automator
cd automator/
wget https://keepersecurity.com/automator/keeper-automator.zip
unzip keeper-automator.zip

configフォルダを作成します

このフォルダが存在しない場合は、解凍先にconfigフォルダを作成します。

mkdir keeper-automator/config

.pfxファイルとパスワードファイルをコピーします

SSL証明書作成のページで作成した.pfxファイルをオートメーターのconfig/フォルダにアップロードし、ファイル名がssl-certificate.pfxになっていることを確認します。

以下は、scpを使用した例です。

scp -i xxx.pem ssl-certificate.pfx \
  ec2-user@xxx:/home/ec2-user/automator/keeper-automator/config/

ssl-certificate.pfxファイルがパスフレーズで保護されている場合は、ssl-certificate-password.txtという名前のファイルも作成して、dockerコンテナにコピーする必要があります。

以下に例を示します。

echo "my_pfx_password..." > ssl-certificate-password.txt

scp -i xxx.pem ssl-certificate-password.txt \
  ec2-user@xxx:/home/ec2-user/automator/keeper-automator/config/

サービスを開始します

オートメーターインスタンスから、java -jarを使用してサービスを開始します。以下の例では、nohupを使用してバックグラウンドで実行します。

cd automator/
nohup java -jar keeper-automator.jar &

Windowsのコマンドラインまたはpowershellでは、コマンドは以下の記載通りに実行する必要があります。

start "" /B javaw -jar "keeper-automator.jar"

サービスのステータスを確認します

サービスが実行中であることをウェブブラウザで確認します (テストしているデバイスからポート 443を開く必要があります）。この場合、URLはhttps://<server>/healthとなります。

このURLは自動ヘルスチェックにもご使用になれます。

以下に例を示します。

curl https://automator.lurey.com/health
OK

サービスは実行中となりましたので、Keeperコマンダーを使用してオートメーターをご利用の環境に統合します。

コマンダーでの最後の設定

Keeperコマンダーでオートメーター設定の最後の手順を実行する必要があります。これはどこからでも実行可能で、サーバーにインストールする必要はありません。

ご利用のワークステーション、サーバー、コンピュータなどにKeeperコマンダーCLIをインストールします。バイナリインストーラーを含むインストール手順についてはこちらのページをご参照ください。コマンダーをインストールしたら、keeper shellと入力してセッションを開き、loginコマンドを使用してログインできます。オートメーターを設定するには、Keeper管理者、またはSSOノードを管理できる管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com

  _  __  
 | |/ /___ ___ _ __  ___ _ _ 
 | ' </ -_) -_) '_ \/ -_) '_|
 |_|\_\___\___| .__/\___|_|
 v16.1.10     |_|

 password manager & digital vault

Logging in to Keeper Commander

SSO user detected.Attempting to authenticate with a master password.
(Note:SSO users can create a Master Password in Web Vault > Settings)

Enter password for admin@company.com
Password:
Successfully authenticated with Master Password
Syncing...
Decrypted [58] record(s)

My Vault>

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効化します。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合は、「Azure Cloud」) は、以下に示すように管理コンソールのUIに表示されます。

コマンドの出力には、IDプロバイダから取得したメタデータを含むオートメーターの設定が表示されます。

                    Automator ID:1477468749950
                            Name:My Automator
                             URL:
                         Enabled:No
                     Initialized:No
                          Skills:Device Approval

以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

次に、他のIdPメタデータをオートメーターに送信します。

automator init "My Automator"

オートメーターサービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

AD FSを使用した環境の場合

IDプロバイダとしてAD FSを使用してKeeperオートメーターを有効にする場合、以下の手順に従ってKeeper証明書を更新するまでログインできません。

Keeper管理コンソールへログインします。
[管理者] > SSOノード > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[SP証明書をエクスポート]をクリックします。
AD FS管理コンソールで、Keeper Cloud SSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。

サービスの確保

Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、こちらのページをご参照ください。

ユーザー体験のテスト

Keeperオートメーターがデプロイされましたので、エンドユーザー体験のテストが可能となります。ユーザーがSSO IDプロバイダで認証した後は、承認を求めるプロンプトは必要なくなります。

サービスの更新

Keeperオートメーターサービスを停止/開始する場合、あるいはサーバーを再起動する場合は、Keeperコマンダーを使用してサービスエンドポイントを再初期化する必要がある場合があります。

automator setup "My Automator"
automator init "My Automator"
automator enable "My Automator"

トラブルシューティング

サービスが始まらない

Keeperオートメーターのログを確認してください。通常これで問題がわかります。Linuxではログはインストールディレクトリにあります。

常に承認のプロンプトが表示される

Keeperオートメーターサービスを再設定する際、Keeperコマンダーを使用してサービスエンドポイントを再初期化する必要がある場合があります。Keeperコマンダーについてはこちらのページをご参照ください。

Keeperコマンダーでオートメーターインスタンスを再初期化するのに必要なコマンドは以下のとおりです。

$ keeper shell

My Vault> automator list
288797895952179 My Automator True https://something.company.com 

(find the Name corresponding to your Automator)

My Vault> automator setup "My Automator"
My Vault> automator init "My Automator"
My Vault> automator enable "My Automator"

LinuxベースのDocker

Keeperオートメーターをシンプルなdocker環境にデプロイする方法

LinuxベースのDocker

本ガイドでは、Dockerを実行できるLinuxインスタンスでKeeperオートメーターを実行するための手順を解説します。

SSL証明書が必要となりますので、お持ちでない場合はカスタムSSL証明書の作成ページをご参照ください。SSL証明書の秘密鍵や.pfxファイルは、Keeperボルトに保存してください。

セットアップ

Dockerのインストール

Dockerをインストールしていない場合は、ご利用のプラットフォームの手順に従ってセットアップします。たとえば、yumパッケージインストーラーを使用する場合、以下のようになります。

sudo yum install docker

Dockerサービスが実行されていない場合は、Dockerサービスを開始します。

sudo service docker start

次に、サービスが自動的に開始するように設定します。

sudo systemctl enable docker.service

root以外のユーザーにDockerの実行を許可するには (セキュリティ要件を満たしている場合）、以下のコマンドを実行します。

sudo chmod 666 /var/run/docker.sock

オートメーターイメージの取得

docker pullコマンドを使用して、最新のKeeperオートメーターイメージを取得します。

docker pull keeper/automator

サービスの開始

以下のコマンドを使用してサービスを開始します。以下の例では、ポート443をリッスンしています。

docker run -d -p443:443/tcp \
  --name "Keeper-Automator" \
 --restart on-failure:3 \
 keeper/automator

証明書の更新

dockerコンテナ内にconfigフォルダを作成します。

docker exec -it Keeper-Automator mkdir /usr/mybin/config

証明書ガイドで作成したssl-certificate.pfxファイルをコンテナにコピーします。

docker cp ssl-certificate.pfx \
  Keeper-Automator:/usr/mybin/config/ssl-certificate.pfx

.pfxファイルがパスフレーズで保護されている場合は、ssl-certificate-password.txtという名前のファイルを作成します。

echo "my_pfx_password..." > ssl-certificate-password.txt

そのファイルをdockerコンテナに配置します。

docker cp ssl-certificate-password.txt \
 Keeper-Automator:/usr/mybin/config/ssl-certificate-password.txt

コンテナ内のkeeper.propertiesファイルで、ssl_modeパラメータがcertificateに設定されていることを確認してください。

docker exec -it Keeper-Automator sed -i 's/^ssl_mode=.*/ssl_mode=certificate/' settings/keeper.properties

SSL証明書を使用してコンテナを再起動

証明書がインストールされましたので、Dockerコンテナを再起動します。

docker restart "Keeper-Automator"

Keeperコマンダーをインストール

この時点でサービスは実行中ですが、Keeperとはまだ通信でない状態です。

ご利用のワークステーション、サーバー、コンピュータなどにKeeperコマンダーCLIをインストールします。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。コマンダーをインストールした後、keeper shellと入力してセッションを開いてからloginコマンドを使用してログインします。オートメーターをセットアップするには、Keeper管理者、またはSSOノードを管理できる管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com
.
.
My Vault>

コマンダーで初期化

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効化します。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールのUIに表示されます。

コマンドの出力には、IDプロバイダから取得したメタデータを含むオートメーターの設定が表示されます。

                    Automator ID:1477468749950
                            Name:My Automator
                             URL:
                         Enabled:No
                     Initialized:No
                          Skills:Device Approval

以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

オートメーターサービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

自動ヘルスチェックには以下のURLをご使用になれます。

https://<server>/health

以下はその例です。

$ curl https://automator.lurey.com/health
OK

AD FSを使用した環境の場合

IDプロバイダとしてAD FSを使用してKeeperオートメーターを有効にする場合、以下の手順に従ってKeeper証明書を更新するまでログインできません。

Keeper管理コンソールへログインします。
[管理者] > SSOノード > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[SP証明書をエクスポート]をクリックします。
AD FS管理コンソールで、KeeperクラウドSSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。

サービスの確保

Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、イングレス要件をご参照ください。

ユーザー体験のテスト

サービスの再起動

Keeperオートメーターサービスを停止/開始する際、Dockerサービスは自動的に状態を保持します。

docker restart "Keeper-Automator"

コンテナの更新

Keeperオートメーターの新しいバージョンが利用できるようになった際には、上記の手順2〜7 繰り返すことでオートメーターサービスを更新できます。以下は例です。

docker pull keeper/automator
docker stop Keeper-Automator
docker rm Keeper-Automator

docker run -d -p443:443/tcp \
  --name "Keeper-Automator" \
 --restart on-failure:3 \
 keeper/automator

docker exec -it Keeper-Automator mkdir /usr/mybin/config

docker cp ssl-certificate.pfx \
  Keeper-Automator:/usr/mybin/config/ssl-certificate.pfx

docker cp ssl-certificate-password.txt \
 Keeper-Automator:/usr/mybin/config/ssl-certificate-password.txt

docker exec -it Keeper-Automator \
  sed -i 's/^ssl_mode=.*/ssl_mode=certificate/' settings/keeper.properties
  
docker restart "Keeper-Automator"

Keeperコマンダーのコマンドを実行します。

automator setup "My Automator"
automator init "My Automator"
automator enable "My Automator"

トラブルシューティング

サービスが始まらない

Keeperオートメーターのログを確認してください。通常これで問題がわかります。Docker環境では、以下のコマンドを使用してログファイルを追跡できます。

docker logs -f "Keeper-Automator"

以下のコマンドを使用して、コンテナに接続してログファイルを確認できます。

docker exec -it "Keeper-Automator" /bin/sh

Docker Compose

Docker Composeメソッドを使用したKeeperオートメーターのインストール

本ページでは、DockerまたはDocker Composeを実行できるLinuxインスタンスでKeeperオートメーターを実行するための手順を解説します。

SSL証明書が必要となりますので、お持ちでない場合はカスタムSSL証明書の作成ページをご参照ください。

Docker Composeには、標準のDockerよりも利点が多くあります。

コンテナの更新間でデータが保持されます
将来の更新のインストールと保守が簡単です

Docker Composeメソッドを使用したオートメーターのインストール手順は以下のとおりです。

DockerとDocker Composeのインストール

DockerとDocker Composeのインストール手順はプラットフォームによって異なります。以下の公式ドキュメントをご参照ください。

https://docs.docker.com/compose/install/

LinuxにDockerおよびDocker Composeインストール手順をご参照ください。

DockerをLinuxにインストール

備考: Linuxではdocker composeの代わりにdocker-composeを使用できます。

インストール後にDockerサービスが動作していない場合は、Dockerサービスの起動が必要になる場合があります。

sudo service docker start

次に、サービスが自動的に開始するように設定します。

sudo systemctl enable docker.service

root以外のユーザーにDockerの実行を許可するには (セキュリティ要件を満たしている場合）、以下のコマンドを実行します。

sudo chmod 666 /var/run/docker.sock

docker-compose.ymlファイルを作成します

以下のコードをdocker-compose.ymlファイルとして、サーバーのdocker composeコマンドを実行する場所に保存します。

name: keeper-automator
services:
  automator:
    container_name: "automator"
    environment:
      - AUTOMATOR_PORT=443
      - AUTOMATOR_HOST=localhost
      - SSL_MODE=certificate
    restart: on-failure
    image: "keeper/automator:latest"
    ports:
      - 8089:443
    volumes:
      - automatordata:/usr/mybin/config
volumes:
  automatordata:

コンテナをインストールして起動

docker compose pull
docker compose up -d

SSL証明書作成のページで作成したSSL証明書とパスワードファイルをコピー

docker cp ssl-certificate.pfx automator:/usr/mybin/config/
docker cp ssl-certificate-password.txt automator:/usr/mybin/config/

新しい証明書でサービスを再起動

docker compose restart

Keeperコマンダーをインストール

この時点でサービスは実行中ですが、Keeperとはまだ通信できない状態です。

ご利用のワークステーション、サーバー、コンピュータなどにKeeperコマンダーCLIをインストールします。初期設定に使用のみとなります。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。コマンダーをインストールした後、keeper shellと入力してセッションを開いてからloginコマンドを使用してログインします。オートメーターをセットアップするには、Keeper管理者、またはSSOノードを管理できる管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com
.
.
My Vault>

コマンダーで初期化します

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効化します。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合は、Azure Cloud) は、以下に示すように管理コンソールのUIに表示されます。

コマンドの出力には、IDプロバイダから取得したメタデータを含むオートメーターの設定が表示されます。

                    Automator ID:1477468749950
                            Name:My Automator
                             URL:
                         Enabled:No
                     Initialized:No
                          Skills:Device Approval

URLはまだ設定されていないませんので、選択したFQDNを使用してURLを編集します。

以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

オートメーターサービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

自動ヘルスチェックには以下のURLをご使用になれます。

https://<server>/health

以下はその例です。

$ curl https://automator.lurey.com/health
OK

ログのモニタリング

Docker Compose コマンドを使用してオートメーターログをモニターできます。

docker compose logs -f

AD FSを使用した環境の場合

IDプロバイダとしてAD FSを使用してKeeperオートメーターを有効にする場合、以下の手順に従ってKeeper 証明書を更新するまでログインできません。

Keeper管理コンソールへログインします。
[管理者] > SSOノード > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[SP証明書をエクスポート]をクリックします。
AD FS管理コンソールで、KeeperクラウドSSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。

サービスの確保

Keeperのサーバーおよびご利用のワークステーションからサービスへのネットワークアクセスを制限することを推奨します。許可するKeeper IPアドレスのリストについては、イングレス要件のページをご参照ください。

アップデート

オートメーターの新バージョンが利用できるようになった際には、コンテナのアップデートするだけでご利用になれます。

docker compose pull
docker compose up -d

ユーザー体験のテスト

Google Cloud (GCP Cloud Run)

Cloud Runを使用してGoogle Cloudプラットフォーム上でKeeperオートメーターサービスを実行

概要

本ガイドでは、特にGCP Cloud Runサービスを使用してGoogle CloudでKeeperオートメーターサービスを実行する手順について取り扱います。オートメーターは、KeeperのインフラストラクチャIPへのアクセスを制限するために、Google Armorサービスによっても保護されています。

1. プロジェクトを作成する

Google Cloudコンソール (https://console.cloud.google.com) から新しいプロジェクトを作成します。

次に、この新しいプロジェクトで[プロジェクトを選択]をクリックします。

2. クラウドシェルを起動する

本ページでは、ウェブインターフェースからGoogle Cloud Shellを使用します。クリックしてCloud Shellを有効にするか、ローカルマシンにインストールしてください。

Project IDをメモしておきます。この場合はkeeper-automator-439714となります。このプロジェクトIDは後続のコマンドで使用されます。

3. 請求先アカウントをリンクする

まだお済みでない場合は、有効な請求先アカウントをプロジェクトにリンクする必要があります。これは、Google Cloudユーザーインターフェースの[お支払い]メニューから実行します。

4. オートメーターConfigキーを作成する

Cloud Shellから、URLエンコード形式で256ビットのAESキーを生成します。

openssl rand -base64 32

キーの例:6C45ibUhoYqkTD4XNFqoZoZmslvklwyjQO4ZqLdUECs=

結果のキーをKeeperに保存します。これは、コンテナをデプロイするときに環境変数として使用されます。このキーにより、起動時に一時的なコンテナが構成されるようになります。

5. アーティファクトレジストリを有効にする

gcloud services enable run.googleapis.com artifactregistry.googleapis.com

6. 地域を選択

サービスを実行するには、地域を選択する必要があります。使用可能な地域コードは、以下のコマンドを使用して確認できます。

gcloud run regions list

この例では、us-east1を使用します。

7. オートメーターサービス用のArtifact Registryを作成する

以下の 2 つのコマンドを実行し、「us-east1」を手順6の値に置き換えます。

gcloud artifacts repositories create keeper-automator-repo \
    --repository-format=docker \
    --location=us-east1 \
    --description="Artifact registry for Keeper Automator service"

gcloud auth configure-docker us-east1-docker.pkg.dev

8. オートメーターコンテナをArtifact Registryにアップロードする

次の内容を含むcloudbuild.yamlというファイルを作成し、文字列us-east1を手順6の地域に置き換えます。その他の内容はすべてそのままにします。

Cloudbuild.yaml

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['pull', 'keeper/automator:latest']
  - name: 'gcr.io/cloud-builders/docker'
    args: [
      'tag',
      'keeper/automator:latest',  
      'us-east1-docker.pkg.dev/$PROJECT_ID/keeper-automator-repo/keeper-automator:latest'
    ]
  - name: 'gcr.io/cloud-builders/docker'
    args: [
      'push',
      'us-east1-docker.pkg.dev/$PROJECT_ID/keeper-automator-repo/keeper-automator:latest'
    ]
images:
  - 'us-east1-docker.pkg.dev/$PROJECT_ID/keeper-automator-repo/keeper-automator:latest'

us-east1を手順6の地域に置き換えます

このファイルをCloud Shellユーザーインターフェースからアップロードするか、Cloud Shellでテキストファイルを作成します。

Cloud Shellから、以下を実行します。

gcloud services enable cloudbuild.googleapis.com

次にビルドを実行します。

gcloud builds submit --config cloudbuild.yaml

これにより、最新のオートメーターコンテナがGoogle Artifact Registryに同期されます。

9. オートメーターサービスをデプロイする

以下のコマンドで、Artifact RegistryからKeeperオートメーターサービスをGoogle Cloud Runにデプロイします。このサービスは、内部アクセスとロードバランサのみに制限されています。

gcloud run deploy keeper-automator \
    --image us-east1-docker.pkg.dev/[PROJECT ID]/keeper-automator-repo/keeper-automator:latest \
    --platform managed \
    --region us-east1 \
    --allow-unauthenticated \
    --ingress internal-and-cloud-load-balancing \
    --min-instances 1 \
    --max-instances 2 \
    --set-env-vars "AUTOMATOR_CONFIG_KEY=XXX,AUTOMATOR_PORT=8080,DISABLE_SNI_CHECK=true,SSL_MODE=none"

以下の点にご注意ください。

[PROJECT_ID]は手順2のProject IDに置き換えます。
XXXを上記の手順 3 で作成した構成キーに置き換えます。
AUTOMATOR_PORTがコンテナにポート8080をリッスンするように指示します。
SSL_MODEでSSL接続をロードバランサで終了できるようになります。
DISABLE_SNI_CHECKでロードバランサーの背後でリクエストを完了できるようになります。
インスタンスの最小数は 1 であり、これはほとんどの環境で許容されます。
最小/最大が設定されていない場合、サービスはインスタンスをゼロに減らし、最初のリクエストで起動します。

10. マネージド証明書の作成

Keeperシステムは、パブリックにルーティング可能なDNS名を介してオートメーターサービスと通信します。この例では、gcpautomator.lurey.comを使用しています。設定には、まずマネージドSSL証明書を作成する必要があります。以下はそのためのコマンドとなります。

gcloud compute ssl-certificates create automator-compute-certificate \
    --domains gcpautomator.lurey.com \
    --global

gcpautomator.lurey.comを任意の名前に置き換えてください。

11. サーバーレスネットワークエンドポイントグループを作成する

次のコマンドで、Cloud RunサービスをGoogle Cloud Load Balancerにリンクします。

gcloud compute network-endpoint-groups create keeper-automator-neg \
    --region us-east1 \
    --network-endpoint-type=serverless \
    --cloud-run-service keeper-automator

us-east1を手順6のCloud Runサービスのリージョンに置き換えます。

12. NEGを使用するバックエンドサービスを作成する

これにより、Cloud Runサービスにリンクするバックエンドサービスが作成されます。

gcloud compute backend-services create keeper-automator-backend \
    --global \
    --protocol HTTP

13. バックエンドサービスにNEGをアタッチする

これにより、NEGがバックエンドサービスに接続されます。

gcloud compute backend-services add-backend keeper-automator-backend \
    --global \
    --network-endpoint-group keeper-automator-neg \
    --network-endpoint-group-region us-east1

us-east1を手順6で指定した場所に置き換えます。

14. 受信トラフィックをバックエンドサービスに誘導するURLマップを作成する

gcloud compute url-maps create keeper-automator-url-map \
    --default-service keeper-automator-backend

15. HTTPSターゲットプロキシを作成し、オートメーター証明書をマップする

gcloud compute target-https-proxies create keeper-automator-target-proxy \
    --url-map keeper-automator-url-map \
    --ssl-certificates automator-compute-certificate

16. 静的IPアドレスを予約し、DNSエントリを割り当てる

gcloud compute addresses create keeper-automator-ip --global

IPアドレスを取得して、後で使用するためにメモしておきます。

gcloud compute addresses list

IPアドレスは有効な DNSにマッピングする必要があります。

DNSプロバイダで、IPを指すA-recordを設定します。

A-Record構成の例

タイプ

名前

値

TTL

gcpautomator.lurey.com

xx.xx.xx.xx

この手順は重要です。目的のドメイン名が指定されたIP アドレスを指していることを確かにしてください。この手順はDNSプロバイダで直接実行する必要があります。

17. グローバル転送ルールを作成する

受信リクエストをターゲットプロキシに転送するためのグローバル転送ルールを作成します。

gcloud compute forwarding-rules create keeper-automator-forwarding-rule \
    --global \
    --target-https-proxy keeper-automator-target-proxy \
    --ports 443 \
    --address keeper-automator-ip

18. 特定のIPへのアクセスをロックダウンする

Keeperオートメーターサービスは、イングレス要件のページに記載の通り、必要なIPのみに制限する必要があります。

特定のIPアドレスへのアクセスを制限するCloud Armorセキュリティポリシーを作成しましょう。

gcloud compute security-policies create allow-specific-ips-policy --description "Allow specific IPs"

この手順では、こちらのページに記載のKeeperの米国データセンターのIPを接続します。必要に応じて追加のルールを作成してください。

gcloud compute security-policies rules create 1000 \
    --security-policy allow-specific-ips-policy \
    --src-ip-ranges 54.208.20.102,34.203.159.189 \
    --action allow

オートメーターサービスをテストできるように、外部IPをこのリストに追加することをお勧めします。

他のトラフィックを制限するために、デフォルトの「拒否」ルールも追加します。

gcloud compute security-policies rules create 2000 \
    --security-policy allow-specific-ips-policy \
    --action deny-404 \
    --src-ip-ranges '*'

最後に、Cloud Armorセキュリティポリシーをバックエンドサービスにアタッチします。

gcloud compute backend-services update keeper-automator-backend \
    --global \
    --security-policy allow-specific-ips-policy

この時点で、オートメーターサービスが実行され、サービスはKeeperインフラストラクチャにのみ公開されます。

次の手順では、Keeperコマンダーのユーティリティを使用して構成を完了します。

オートメーター設定の最終手順を実行するには、Keeperコマンダーが必要となります。コマンダーはどこからでも実行でき、サーバーにインストールする必要はありません。

ワークステーションまたはサーバーに、KeeperコマンダーCLI をインストールします。バイナリインストーラーを含むインストール手順については、こちらのページをご参照ください。

コマンダーをインストールした後、Keeperコマンダーを起動するか、既存のターミナルからkeeper shellと入力してセッションを開いてから、loginコマンドを使用してログインします。オートメーターを設定するには、Keeper管理者かSSOノードを管理する権限を持つ管理者としてログインする必要があります。

$ keeper shell

My Vault> login admin@company.com

  _  __  
 | |/ /___ ___ _ __  ___ _ _ 
 | ' </ -_) -_) '_ \/ -_) '_|
 |_|\_\___\___| .__/\___|_|
 v16.x.xxx    |_|

 password manager & digital vault

Logging in to Keeper Commander
Enter password for admin@company.com
Password: ********************
Successfully authenticated with Master Password
Syncing...
Decrypted [58] record(s)

My Vault>

20. オートメーターを作成する

automator createで始まる一連のコマンドを使用してオートメーターを作成します。

My Vault> automator create --name "My Automator" --node "Azure Cloud"

ノード名 (この場合は「Azure Cloud」) は、以下に見られるように管理コンソールから取得します。

コマンドの出力には、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: XXXX
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

「URL」はまだ入力されていないことに注意してください。これは、オートメーターURLが入力されます。

以下のように、automator editコマンドを実行します。これにより、URLが設定され、スキル ( team、team_for_user、device) も設定されます。

automator edit --url https://gcpautomator.lurey.com --skill=team --skill=team_for_user --skill=device "My Automator"

注: gcpautomator.lurey.comを手順16で作成したドメイン名に置き換えます。

次に、キーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

新しい設定でオートメーターを初期化します。

automator init "My Automator"

サービスを有効にします。

automator enable "My Automator"

ユーザー体験のテスト

Keeperオートメーターがデプロイされましたので、エンドユーザー体験をテストできます。ユーザーが SSOのIDプロバイダで認証した後は、承認を求めるポップアップが表示されなくなります。

最も簡単にテストするには、Keeperウェブボルトをシークレットモードのウィンドウで開いて、クラウドSSOでログインします。デバイスの承認は求められなくなっています。

コンテナの更新

Keeperから新しいバージョンが利用可能になる際にGoogleのコンテナを更新するには、以下のコマンドを実行します。

手順8を繰り返す。
手順9を繰り返す。

サポートが必要な場合

サポートが必要な場合は、commander@keepersecurity.comまでメールでお問い合わせいただくか、サポートチケットを提出ください。

Kubernetesサービス

KubernetesサービスとしてKeeperオートメーターをインストール

本ガイドでは、KeeperオートメーターをKubernetesサービスとして実行するための手順を解説します。

SSL証明書が必要となりますので、お持ちでない場合はカスタムSSL証明書の作成ページをご参照ください。

1. Kubernetesのセットアップ

Kubernetesのインストールとデプロイについては詳しく触れませんが、デモの目的でプラットフォームに依存しない2つのEC2インスタンス（マスターとワーカー）を使用する、非常に基本的な単一ノード環境について記載しました。K8環境がすでに整っている場合には手順2へお進みください。

Dockerのセットアップ

Kubernetesはコンテナランタイムを要しますのでDockerを使用します。

sudo yum update -y
sudo yum install -y docker
sudo systemctl enable docker
sudo systemctl start docker

kubeadm、kubelet、kubectlのインストール

これらのパッケージは、マスターノードとワーカーノードの両方にインストールする必要があります。今回の例ではAWS Amazon Linux 2インスタンスタイプを使用しています。

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

sudo systemctl enable --now kubelet

マスターノードの初期化

マスターノードとして使用をご希望のマシンで以下を実行します。

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

--pod-network-cidr 引数は、特定のネットワークプロバイダーで必要となります。ポッドに設定するIP範囲を置き換えます。

kubeadm initが完了後、ワーカーノードをマスターに参加させるために使用できるコマンドが表示されます。レスポンスと初期化コードをメモして次の手順で使えるようにします。

ローカルのkubeconfigをセットアップします。

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

ポッドネットワークのインストール

クラスターが機能する前にポッドネットワークをインストールする必要があります。簡単にflannelを使用できます。

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

ワーカーノードを参加させる

ワーカーノードとして追加する各マシンで、初期化コードを含む以下のコマンドを実行します。

sudo kubeadm join [your code from kubeadm init command]

セキュリティグループ内のワーカーノードとマスターノードの間でポート6443 が開いている必要があリます。

ワーカーが参加した後、Kubernetesクラスターが稼働します。マスター上でkubectl get nodesを実行すると、ノードのステータスを確認できます。

2. Kubernetes Secretの作成

KeeperオートメーターのSSL証明書がSecretとしてKubernetesサービスに提供されます。SSL証明書とSSL証明書パスワード (SSL 証明書ガイドから作成) を保存するには、以下のコマンドを実行します。

kubectl create secret generic certificate-secret --from-file=ssl-certificate.pfx --from-file=ssl-certificate-password.txt

3. マニフェストの作成

以下は、automator-deployment.yamlとして保存できるマニフェストファイルです。デプロイメントリソースとサービスリソースの両方の設定が含まれています。

デプロイメントリソースはKeeperオートメーターDockerコンテナを実行します。
SSL証明書と証明書パスワードファイルは、マウントされたSecretとして参照されます。
Secretは初期化コンテナ内のポッドにコピーされます。
オートメーターサービスはポート30000でリスンしてから、コンテナーのポート443にルーティングします。
本手順では、単一のコンテナ (replicas: 1) のみをデプロイしてコンテナを設定できるようにします。最後の手順でreplicasの数を増やします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: automator-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: automator
  template:
    metadata:
      labels:
        app: automator
    spec:
      initContainers:
        - name: init-container
          image: busybox
          command: ['sh', '-c', 'cp /secrets/* /usr/mybin/config']
          volumeMounts:
            - name: secret-volume
              mountPath: /secrets
            - name: config-volume
              mountPath: /usr/mybin/config
      containers:
        - name: automator
          image: keeper/automator:latest
          ports:
            - containerPort: 443
          volumeMounts:
            - name: config-volume
              mountPath: /usr/mybin/config
      volumes:
        - name: config-volume
          emptyDir: {}
        - name: secret-volume
          secret:
            secretName: certificate-secret
            items:
              - key: ssl-certificate.pfx
                path: ssl-certificate.pfx
              - key: ssl-certificate-password.txt
                path: ssl-certificate-password.txt
---
apiVersion: v1
kind: Service
metadata:
  name: automator-service
spec:
  type: NodePort
  ports:
  - port: 443
    targetPort: 443
    protocol: TCP
    nodePort: 30000
  selector:
    app: automator

4. サービスのデプロイ

kubectl apply -f automator-deployment.yaml

30秒以内にサービスが起動します。

5. サービスステータスのチェック

ウェブブラウザでサービスが実行されていることを確認します (テストしているデバイスからポート 30000を開く必要があります)。今回の場合、URLはhttps://automator2.lurey.com:30000/api/rest/statusとなります。

自動ヘルスチェックには以下のURLもご利用になれます。

https://<server>/health

例

$ curl https://automator2.lurey.com:30000/health
OK

これで単一ポッドのサービスが実行されていますので、Keeperコマンダーを使用してオートメーターをご利用の環境に統合します。

6. コマンダーでポッドを設定

ポッドを設定してオートメーター機能を使うには、Keeperコマンダーが必要となります。Keeperコマンダーはどこからでも実行できます。

ご利用のワークステーションにKeeperコマンダーCLIをインストールします。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。

$ keeper shell

My Vault> login admin@company.com

  _  __  
 | |/ /___ ___ _ __  ___ _ _ 
 | ' </ -_) -_) '_ \/ -_) '_|
 |_|\_\___\___| .__/\___|_|
 vxx.x.xx     |_|

Logging in to Keeper Commander

SSO user detected. Attempting to authenticate with a master password.
(Note: SSO users can create a Master Password in Web Vault > Settings)

Enter password for admin@company.com
Password: 
Successfully authenticated with Master Password
Syncing...
Decrypted [58] record(s)

My Vault>

Keeperコマンダーにログインし、automator createで始まる一連のコマンドを使用してオートメーターを有効にします。

My Vault> automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合はAzure Cloud) は、以下のように管理コンソールUIから取得します。

コマンドの出力には、IDプロバイダからのメタデータを含むオートメーター設定が表示されます。

                    Automator ID: 1477468749950
                            Name: My Automator
                             URL: 
                         Enabled: No
                     Initialized: No
                          Skills: Device Approval

URLはまだ入力されていませんので、以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://automator2.lurey.com:30000 --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

次に、他のIdPメタデータをオートメーターに送信します。

automator init "My Automator"

オートメーターサービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

7. サービスの確保

8. オートメーターサービスのテスト

単一のポッドでオートメーターサービスが適切に動作していることを確認するには、以下の手順を行います。

ブラウザのシークレットモードでウィンドウを開きます。
SSOユーザーアカウントを使用してKeeperウェブボルトにログインします。
SSOログインの成功後にデバイスの承認が必要ないことを確認します。

9. ポッド設定の更新

この時点では、単一のポッド設定を実行しています。最初のポッドにオートメーターサービスがセットアップされKeeperクラウドに設定されましたので、ポッドの数を増やせます。以下のように、YAMLファイル内のreplicasステートメントを実行したいポッドの数に更新します。

replicas: 3

次に変更を適用します。

kubectl apply -f automator-deployment.yaml

複数のポッドが実行されている場合、コンテナはラウンドロビン方式のセットアップで負荷が分散されます。最初の承認リクエスト時に構成設定がKeeperクラウドからオートメーターポッドへ自動的かつ安全にロードされます。

オートメーターサービスのトラブルシューティング

オートメーターサービスを実行しているログファイルでエラーを監視できます。ポッドのリストを取得するには以下を実行します。

kubectl get pods

以下のコマンドを使用して、ターミナル経由でオートメーターコンテナに接続します。

kubectl exec -it automator-deployment-<POD> --container automator -- /bin/sh

ログファイルはlogs/フォルダにあります。ターミナルに接続する代わりに、以下のコマンドからコンテナのログファイルを追跡することもできます。

kubectl exec -it automator-deployment-<POD> --container automator -- tail -f /usr/mybin/logs/keeper-automator.log

Windowsサービス

KeeperオートメーターのWindowsサーバーでの実装例

本ガイドでは、Dockerを使用せずにオートメーターサービスをWindowsサーバーで実行するための手順を解説します。

SSL証明書が必要となりますので、お持ちでない場合はカスタムSSL証明書の作成ページをご参照ください。

1. オートメーターサービスをインストール

オートメーターインスタンスで、以下のURLからKeeperオートメーターのインストーラーをダウンロードし、解凍して実行します。

https://keepersecurity.com/automator/keeper-automator-windows.zip

設定画面でJavaのチェックボックスをオンにして、Javaランタイムをインストールに含めます。現在はJava 17ランタイムが同梱されており、新バージョンのリリースに合わせて更新されます。

これにより、Keeperオートメーターが以下のフォルダにインストールされます。

C:\Program Files\Keeper Security\Keeper Automator\

設定は以下のフォルダに保存されます。

C:\ProgramData\Keeper Automator\

2. configフォルダを作成

C:\ProgramData\Keeper Automatorフォルダにconfigというフォルダを作成します。

3. 証明書ファイルとパスワードファイルをコピー

ssl-certificate.pfxファイル (SSL証明書作成のページで保存) をC:\ProgramData\Keeper Automator\Configに配置します。

ssl-certificate.pfxファイルがパスフレーズで保護されている場合は、ssl-certificate-password.txtという名前のファイルもC:\ProgramData\Keeper Automator\Configに作成する必要があります。

4. サービスの再起動

サービス画面でKeeperオートメーターを選択し、サービスを再起動します。

ウェブブラウザでサービスが実行中であることを確認します (テストしているデバイスからポート443が解放されている必要があります）。この場合のURLは、https://automator.company.com/api/rest/statusとなります。

自動ヘルスチェックには以下のURLもご使用になれます。

https://automator.company.com/health

Windowsファイアウォール

Defenderファイアウォールが実行されているWindowsでデプロイしている場合は、Windows Defenderファイアウォールでポート443 (または任意の指定ポート) を開く必要がありますので、以下の手順に従います。

[スタート]メニューを開き、[Windows Defenderファイアウォール]と入力して、結果の一覧から選択します。横のナビゲーションメニューで[詳細設定]を選択し、[受信の規則]を選択します。ポートを開くには、[新しい規則]を選択して手順を完了します。

コマンダーを使用した最後の設定

サービスが実行中となりましたので、Keeperコマンダーを使用してオートメーターをご利用のKeeperの環境に統合します。

5. Keeperコマンダーをインストールします

ご利用のワークステーション、サーバー、コンピュータなどにKeeper Commander CLIをインストールします。バイナリインストーラーを含むインストール手順についてはこちらをご覧ください。

6. Keeperコマンダーにログインし、`automator create`で始まる一連のコマンドを使用してオートメーターを有効化し、オートメーターに任意の名前を付けます。

automator create --name="My Automator" --node="Azure Cloud"

ノード名 (この場合は、Azure Cloud) は、以下に示すように管理コンソールのUIに表示されます。

コマンドの出力には、IDプロバイダから取得したメタデータを含むオートメーターの設定が表示されます。

                    Automator ID:1477468749950
                            Name:My Automator
                             URL:
                         Enabled:No
                     Initialized:No
                          Skills:Device Approval

URLがまだ入力されいませんので、以下のようにautomator editコマンドを実行します。これによりURLとスキルが設定されます (team、 team_for_user、device）。

automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

次にキーを交換します。オートメーター公開キーで暗号化されたエンタープライズ秘密キーがオートメーターに提供されます。

automator setup "My Automator"

この手順でエラーが発生した場合は、Windows サービスを停止してから開始し、ポートが使用可能であることを確かにします。

次に、以下のコマンドを使用して新しい設定でオートメーターを初期化します。

automator init "My Automator"

最後に、以下のコマンドでオートメーターサービスを有効にします。

automator enable "My Automator"

この時点で設定は完了となります。

AD FSを使用した環境の場合

IDプロバイダとしてAD FSを使用してKeeperオートメーターを有効にする場合、以下の手順に従ってKeeper証明書を更新するまでログインできません。

Keeper管理コンソールへログインします。
[管理者] > SSOノード > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[SP証明書をエクスポート]をクリックします。
AD FS管理コンソールで、KeeperクラウドSSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。

ユーザー体験のテスト

サービスの更新

Keeperオートメーターサービスを再設定する際は、Keeperコマンダーを使用してサービスエンドポイントを再初期化する必要があります。

automator setup "My Automator"
automator init "My Automator"
automator enable "My Automator"

トラブルシューティング

サービスが始まらない

Keeperオートメーターのログを確認してください。通常これで問題がわかります。Windowsの場合、ログはC:\ProgramData\Keeper Automator\logsにあります。

常に承認のプロンプトが表示される

Keeperオートメーターサービスを再インストールする際、Keeperコマンダーを使用してサービスエンドポイントを再初期化する必要がある場合があります。Keeperコマンダーについてはこちらをご覧ください。

Keeperコマンダーでオートメーターインスタンスを再初期化するのに必要なコマンドは以下のとおりです。

$ keeper shell

My Vault> automator list
288797895952179 My Automator True https://something.company.com 

(find the Name corresponding to your Automator)

My Vault> automator setup "My Automator"
My Vault> automator init "My Automator"
My Vault> automator enable "My Automator"

マルチテナントモード

単一オートメーターインスタンスに複数のテナントをセットアップ

概要

Keeperオートメーターではマルチテナントがサポートされていますので、一度のデプロイで複数のKeeperエンタープライズ環境を自動化できます。

MSP環境では、単一のKeeperオートメーターインスタンスを使用して複数の企業に対応できます。
エンタープライズユーザーの場合、単一のインスタンスで様々なIDプロバイダの承認を処理できます。

サーバーが実行中となると、企業が異なっても複数のSSOノードに使用できます。

MSPによる複数企業の管理

単一のオートメーターインスタンスを発動して複数の企業を管理する手順は以下のとおりです。

MSP管理者としてコマンダーにログインします

My Vault> login my_msp_admin@company.com

コンテキストを管理対象企業に切り替えます

My Vault> msp-info

MSP Plans and Licenses
-----------------------
  #  Plan Id           Available Licenses    Total Licenses    Stash
---  --------------  --------------------  ----------------  -------
  1  business                          83               100        0
  2  businessPlus                      50               100        0
  3  enterprise                        80               100        0
  4  enterprisePlus                    85               100        0

  #      ID  Name                     Plan              Allocated    Active
---  ------  -----------------------  --------------  -----------  --------
  1   81386  Demo Managed Co. LLC     enterprisePlus            5         0
  2   81344  Elite Auto Works         business                  5         4
  3  114391  John's Garage            enterprisePlus            5         0
  4  114392  John's Garages           enterprisePlus            5         0
  5   81345  Perfect Teeth Dental     businessPlus             50         4
  6  114281  Test                     business                 12         0
  7   81346  Troy Financial Services  enterprise               20         0

設定したい企業を見つけてIDを選択し、以下のように入力します。

switch-to-mc <ID>

オートメーターインスタンスを作成します

以下のように、editの手順では共通のオートメーターURLを使用します。

My Vault> automator create --name="Tenant1" --node="SSO Node"
My Vault> automator edit --url=https://my.company.com:8089 <Automator ID>
My Vault> automator setup <Automator ID>
My Vault> automator init <Automator ID>
My Vault> automator enable <Automator ID>

MSPに戻ります

MSP管理者コンテキストに戻ります

My Vault> switch-to-msp

管理対象の企業ごとに、上記の4つの手順を繰り返します。

マルチテナント企業

同じ企業テナントの複数のノードで、単一のオートメーターインスタンスを有効化する手順は以下のとおりです。

管理者としてコマンダーにログインします

My Vault> login admin@company.com

オートメーターインスタンスを作成します

以下のように、各ノードでeditには同じURLを使用します。

My Vault> automator create --name="Tenant A" --node="<node_name>"
My Vault> automator edit --url=https://my.company.com:8089 <Automator ID>
My Vault> automator setup <Automator ID>
My Vault> automator init <Automator ID>
My Vault> automator enable <Automator ID>

同一のURLエンドポイントを持つ別のインスタンスを設定します。

My Vault> automator create --name="Tenant B" --node="Azure"
My Vault> automator edit --url=https://my.company.com:8089 <Automator ID>
My Vault> automator setup <Automator ID>
My Vault> automator init <Automator ID>
My Vault> automator enable <Automator ID>

新たに作成したインスタンスは、名前とIDが異なり、割り当てられたノードも異なりますが、同じURLを使用します。

各ノードで手順2を繰り返し、同じオートメーターインスタンスに複数のテナントをセットアップします。

カスタムSSL証明書

カスタムSSL証明書でKeeperオートメーターを設定

概要

KeeperオートメーターによりKeeperバックエンドとお客様の環境で実行されているオートメーターサービスの間の通信を暗号化されます。

カスタム証明書を使用しない場合、Keeperオートメーターがデフォルトで自己署名証明書を生成します。

SAMLが署名だけでなくリクエストを暗号化するように設定されている場合は、カスタム SSL証明書が必要となります。

ZeroSSLで簡単に無料でSSL証明書を取得できます。あるいはプロセスの各過程をより詳細に制御したい場合は、以下の手順にお進みください。

SSL証明書の生成と準備

Keeperオートメーターには、公的認証局によって署名された有効な署名付きSSL証明書が必要です。SSL 証明書を生成するプロセスはプロバイダによって異なりますが、ここでは一般的なフローについて記載します。

以下の手順に従ってオートメーターの実行に必要な2つの証明書ファイルを作成します。これらのファイルにはssl-certificate.pfxおよびssl-certificate-password.txtという名前を付けます。

opensslコマンドプロンプトを使用して秘密キーを生成します。

openssl genrsa -out automator.key

オートメーターに使用する予定のホスト名を使用してCSRを生成します。この場合、automator.lurey.comを使用します。Common Nameはドメインと完全に一致します。

openssl req -new -key automator.key -out automator.csr

Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Illinois
Locality Name (eg, city) [Default City]:Chicago
Organization Name (eg, company) [Default Company Ltd]:Company, LLC
Organizational Unit Name (eg, section) []:Engineering
Common Name []:automator.yourcompany.com
Email Address []:webmaster@yourcompany.com

SSL証明書を購入するか90日間の無料証明書を取得し、CSRをSSL証明書プロバイダに送信します。

オートメーターインスタンス用に作成したSSL証明書はこの目的にのみ使用するようにしてください。他のサービスと共有されているワイルドカード証明書は使用しないでください。

まだプロバイダをお持ちでない場合は、https://www.ssls.com/をご利用になれます。1つのドメインに対して最も安価なSSL証明書で問題ありません。

automator.company.comなどのURLを選択し、オートメーターに限定したドメインの証明書を作成します。

SSL証明書プロバイダが署名付き証明書 (.crt ファイル) と中間CA証明書を含むzipファイルを配信します。バンドルのファイル拡張子は .crt または .ca-bundleのいずれかとなります。このファイルを、前に作成した.keyファイルと同じ場所に解凍します。

証明書が発行された後、OpenSSL を使用して完全な証明書チェーン (ルート、中間、CA 証明書) を含む.pfx形式に変換する必要があります。

Windowsでは、必ずOpenSSLコマンドプロンプトを起動し、ファイルが存在するフォルダへ移動してください。

openssl pkcs12 -export -out ssl-certificate.pfx -inkey automator.key -in automator.yourcompany.com.crt -certfile automator.yourcompany.com.ca-bundle

エクスポートパスワードを設定してから、ssl-certificate-password.txtという名前の新しいテキストファイルを作成し、そのファイルにエクスポートパスワードを入力して保存します。

automator.keyは手順1で生成された秘密キーです。
automator.yourcompany.com.crtは手順3で配信された署名付き証明書です。
automator.yourcompany.com.ca-bundleはCAバンドルです。
ssl-certificate.pfxは、オートメーターによって使用されるパスワードで暗号化済みの出力ファイルです。
ssl-certificate-password.txtには、.pfxファイルの暗号化に使用されるパスワードが含まれています。

5つのファイルすべてをKeeperボルトに保存することを推奨します。

.pfxファイルに、発行した証明書とプロバイダからの完全な証明書チェーンが含まれていることを確かにしてください。完全な証明書チェーンを提供しない場合は通信が失敗し、オートメーターがURLに接続できません。 .pfxを確認するにはopensslを使用します。 openssl pkcs12 -in ssl-certificate.pfx -info .pfxが正しい場合は、3つの証明書が表示されます。

証明書が1つしか表示されない場合、4つまたは5つの証明書が表示される場合は.pfxが間違っているため、プロセスを繰り返す必要があります。

ssl-certificate.pfxとssl-certificate-password.txtを保存し、後述のデプロイ手順で使用できるようにします。

また、後でサービスを更新したり証明書を再入力したりするときに参照できるように、Keeperコンテナ内のファイルは必ずバックアップしておいてください。

以下に記載されている年次証明書更新プロセスを確認してください。

Windows

SSL証明書の生成と準備

Keeperオートメーターには、公的認証局によって署名された有効な署名付き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証明書の更新が必要となりますが、ほとんどの証明書プロバイダーで新しい証明書を生成してくれます。証明書の更新後、オートメーターインスタンス内の.pfx証明書ファイルを置き換えてからサービスを再起動します。ファイルの更新とサービスの再起動の正確なプロセスについては、特定のオートメーターインストール方法のドキュメントをご参照ください。

AD FSを使用した環境の場合

IDプロバイダーとしてAD FSを使用してKeeperオートメーターを使用している場合、以下の手順に従って Keeper証明書を更新するまでログインできません。

Keeper管理コンソールへログインします。
[管理者] > SSOノード > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[SP証明書をエクスポート]をクリックします。
AD FS管理コンソールで、KeeperクラウドSSO証明書利用者信頼プロパティを選択します。
[暗号化]タブで、古い証明書をこの新しい証明書に置き換えます。
[署名]タブで、新しいSP証明書をこの新しい証明書に置き換えます。

証明書の更新後にログインの問題が発生した場合

証明書の更新後、IDプロバイダで新しいSP証明書を発行する必要がある場合があります。以下がその手順となります。

Keeper管理コンソールへログインします。
[管理者] > SSOノード > [プロビジョニング]に移動し、SSOクラウド設定を見ます。
[SP証明書をエクスポート]をクリックして証明書ファイルを保存します。
[メタデータのエクスポート]をクリックして証明書が含まれるメタデータファイルを保存します。
IDプロバイダポータルにログインし、KeeperのSSO設定を見ます。
サービスプロバイダーの証明書更新の指示に従って、KeeperのSP証明書ファイル (または必要に応じてメタデータ) をアップロードし、保存します。

オートメーターサービスが本質的にサービスプロバイダーになるのが理由となります。署名プロセスには、お客様が生成したSSL証明書が使用されます。

AzureおよびAWSでのデプロイ

SSLを終了するカスタムドメインを持つアプリケーションゲートウェイまたはロードバランサーを利用する環境でSSL証明書を更新する場合は、そのデバイス上の証明書も更新する必要があります。

App Gatewayを使用したAzureデプロイの場合、ゲートウェイのhttpsリスナーで.pfx証明書も更新する必要があります。[Azure] > [リソースグループ] > [アプリゲートウェイ] > [リスナー]に移動し、新しい証明書をアップロードします。

高度な設定

オートメーターの設定と機能

概要

本ドキュメントの設定でオートメーターサービスの機能と安全性を制御します。

設定: `automator_debug`

Env変数: AUTOMATOR_DEBUG

説明: オートメーターで簡単にデバッグログをオン/オフします。

設定: `automator_config_key`

Env変数: AUTOMATOR_CONFIG_KEY

初期値: Empty

説明: Base64 URLエンコードされた256ビットAES キーで、通常環境変数としてのみ使用されます (v3.1.0以降)。この設定は、コンテナインスタンス間で共有される/usr/mybin/configファイルストレージがない場合に、暗号化された設定をKeeperクラウドからロードするために必要となります。

設定: `automator_host`

Env変数: AUTOMATOR_HOST

初期値: localhost

説明: オートメーターサービスがローカルでリッスンしているホスト名または IP アドレスです。SSLが有効になっている場合 (ssl_modeパラメータ)、automator_hostの値がSSL証明書のサブジェクト名に一致する必要があります。サブジェクト名が一致しない場合、disable_sni_check設定をfalseに設定できます。

サービスが複数のネットワークIPを持つマシンで実行されている場合、この設定によりオートメーターサービスが指定されたIPにバインドされます。

設定: `automator_port`

Env変数: AUTOMATOR_PORT

初期値: 8089

説明: オートメーターがリッスンするポートです。Dockerで実行している場合は、デフォルトの8089を使用します。

設定: `disable_sni_check`

Env変数: DISABLE_SNI_CHECK

初期値: false

説明: SSLが使用中である場合は、証明書のサブジェクト名に対するSNIチェックを無効にします。

設定: `email_domains`

Env変数: EMAIL_DOMAINS

初期値: null

説明: オートメーターがデバイスまたはチームを承認するための、ユーザーのメールドメインのカンマ区切りのリストで、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

説明: オートメーターが有効か無効かを決定します。

設定: `enable_rate_limits`

Env変数: ENABLE_RATE_LIMITS

初期値: false

説明: trueの場合、オートメーターは以下のスケジュールに従って受信するコールのレート制限を行います。

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制限フィルターによって受け入れられたユーザーも、オートメーターによる通常の方法で承認される必要があります。IP制限フィルターで拒否されたユーザーは自動承認されません。

ip_allowが空の場合、ip_denyリストに記載されているものを除くすべてのIPアドレスが許可されます。この設定を使用した場合、許可範囲外のIPアドレスにあるデバイスはオートメーターによって承認されなくなります。値は、単一の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

説明: オートメーターの名前です。エンタープライズ内で固有である必要があります。オートメーターは名前またはIDで参照できます。

設定: `persist_state`

Env変数: N/A

初期値: true

説明: trueの場合、オートメーターの状態がシャットダウン後も保持されます。オンのままにしておきます。

設定: `skill`

Env変数: N/A

初期値: device_approval

説明: device_approvalはデバイスの承認を意味します。team_for_user_approvalはチームの承認を意味します。オートメーターは複数のスキルを持つことができます。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

説明: オートメーターサービスでの通信方式です。certificate、self_signed、noneのいずれかになります。 noneの場合、オートメーターサーバーはHTTPSの代わりにHTTPを使用します。オートメーターがSSLトラフィックを復号化するロードバランサーの下でホストされている場合はそれでも良いかもしれません。

設定: `url`

Env変数: N/A

初期値: ""

説明: オートメーターに接続できるURLです。

トラブルシューティング

オートメーターサービスによくある問題とトラブルシューティング

リモートのオートメーターサービスと通信できない

Keeperコマンダーがオートメーターサービスと通信できない理由はいくつかあります。

オートメーターサービスがKeeperのIPアドレスに対して解放されていることを確かにします。解放が必要なIPのリストについては、イングレス要件のページをご参照くださす。接続の問題が発生した場合に解決できるよう、ご自身のIPアドレスも追加することを推奨します。
カスタムSSL証明書をご使用の場合は、SSL証明書がロードされていることを確かにします。オートメーターのログファイルを確認すれば、サービスの再起動によって証明書がロードされたかどうかが確認できます。そのIPアドレスにアクセスできる場合は、以下のようにコマンドラインでcurlを使用することで正常性チェックを実行できます。 curl https://automator.mycompany.com/health
証明書のサブジェクト名がFQDNと一致することを確認します。
SSL証明書にCA中間証明書チェーンが含まれていることを確認します。中間証明書チェーンが欠落している場合、Keeperはオートメーターへの接続を拒否します。以下のようにopensslコマンドを使用してご確認ください。

openssl s_client -showcerts -servername automator.company.com -connect automator.company.com

このコマンドで、チェーン内の証明書の数が表示されます。証明書が1つしか表示されない場合は、証明書チェーンがすべてはロードされていないということになります。この問題を解決するには、証明書作成の手順ページの手順4をご参照ください。

ヘルスチェックでの400エラー

当エラーは、ヘルスチェックのリクエストURIがSSL証明書ドメインと一致しない場合に発生する可能性があります。ヘルスチェックを完了させるにはサービスでSNIチェックを無効にする必要がありますので、オートメーター設定でdisable_sni_check=trueを設定するか、環境変数 DISABLE_SNI_CHECKにtrueの値を渡します。

CLIを使用した承認

コマンダーを使用した承認

コマンダー方式による自動承認

KeeperのCLI/SDKプラットフォームであるコマンダーを使用すると、管理コンソールにログインしなくとも自動で管理者によるデバイス承認を実行できます。また、Keeperコマンダーが実行可能であればどのコンピュータ (Mac、PC、Linux) でも設定できます。

この方法はKeeperクラウドからの着信接続を必要としないため、入力ポートが開けない環境に適しています。この方法ではポーリングメカニズムが使用されます (送信接続のみ)。

Keeperコマンダーをインストール

インストール手順についてはこちらをご参照ください。 Mac/PC/Linux用のバイナリバージョンをインストールするか、pip3を使用します。

CLIを使用してデバイスを承認

keeper shellコマンドを使用してコマンダーCLIを起動します。コマンダーのバイナリをインストールした場合はそのファイルを実行します。

$ keeper shell
  _  __
 | |/ /___ ___ _ __  ___ _ _
 | ' </ -_) -_) '_ \/ -_) '_|
 |_|\_\___\___| .__/\___|_|
              |_|

 password manager & digital vault

loginコマンドを使用して、デバイスの承認権限を持つKeeper管理者としてログインします。コマンダーでは、マスターパスワードと2FAがサポートされています。自動化を目的として、デバイスの承認専用のKeeper管理アカウントを作成することを推奨します。これにより、ユーザーアカウントへの何らかの変更 (強制適用ポリシーなど) によって、コマンダーの処理が中断されることがなくなります。

My Vault> login admin@acme-demo.com
Password: *******

すべてのデバイスを表示するには、device-approveと入力します。

My Vault> device-approve
Email               Device ID           Device Name       Client Version
------------------  ------------------  ----------------  ----------------
demo@acme-demo.com  f68de375aacdff3846  Web Vault Chrome  w15.0.4
demo@acme-demo.com  41sffcb44187222bcc  Web Vault Chrome  w15.0.4

特定のデバイスを手動で承認するには、以下のコマンドを使用します。

My Vault> device-approve --approve <デバイスID>

過去に正常なログインが認識されたIPからのデバイスをすべて承認するには、以下のコマンドを使用します。

My Vault> device-approve --approve --trusted-ip

IPアドレスに関係なくすべてのデバイスを承認するには、以下のコマンドを使用します。

My Vault> device-approve --approve

特定のデバイス承認リクエストを拒否するには、denyコマンドを使用します。

My Vault> device-approve --deny <デバイスID>

すべての承認リクエストを拒否するには、デバイスIDパラメータを削除します。

My Vault> device-approve --deny

シェルを終了せずに最新のデバイス承認をリロードするには、reloadコマンドを使用します。

My Vault> device-approve --reload

X秒ごとにデバイスを自動承認

コマンダーでは、X秒ごとに承認を実行する自動化モードがサポートされています。設定するには、自動作成されたconfig.jsonファイルを変更します。このファイルは、ユーザーフォルダの.keeperフォルダ内 (WindowsではC:\Users\Administrator.keeper\config.json、Mac/Linuxでは/home/user/.keeper/config.json) にあります。

既存のデータは変更せずに以下の行を追加します。

"commands":["device-approve --reload","device-approve --approve"],
"timedelay":30

JSONファイルでは、最後の行を除くすべての行の後にコンマが必要となります。

これでコマンダーを開く (またはkeeper shellを実行する) と、以下のように指定した時間ごとにコマンダーがコマンドを実行するようになります。

$ keeper shell
Executing [device-approve --reload]...
Password:
Logging in...
Syncing...

Executing [device-approve --reload]...

Email               Device ID           Device Name       Client Version
------------------  ------------------  ----------------  ----------------
demo@acme-demo.com  f68de375aacdff3846  Web Vault Chrome  w15.0.4

Executing [device-approve --trusted-ip --approve]...
2020/09/20 21:59:47 Waiting for 30 seconds
Executing [device-approve --reload]...
There are no pending devices to approve
.
.
.

チームとユーザーの自動承認

上記の例と同様に、コマンダーを使用してAzure、Okta、JumpCloudなどのSCIMプロバイダによって作成されたチームおよびユーザー割り当てを自動的に承認できます。

設定するには、team-approveというコマンドをJSON設定ファイルに追加します。

{
    "user": "admin@acme-demo.com",
    "commands": [
        "debug",
        "device-approve --reload",
        "device-approve --approve",
        "team-approve"
    ],
    "timedelay":60
}

セッションの持続

Keeperコマンダーでは持続的ログインセッションがサポートされていますので、実行中はマスターパスワードでログインしたりconfigrationファイルにマスターパスワードをハードコードしたりする必要はありません。

以下はデバイス上で30日間 (最大) 持続的ログインを有効にするコマンドとなります。

My Vault> this-device register
My Vault> this-device persistent-login on
My Vault> this-device ip-auto-approve on
My Vault> this-device timeout 30d
My Vault> quit

値には秒数 (例えば60秒の場合は60)、または数字と文字の組み合わせ (例えば1分の場合は1m、5時間の場合は5h、7日間の場合は7d) を使用できます。

「logout」と入力するとセッションが無効になりますのでご留意ください。コマンダーセッション終了するには「quit」します。

デバイスで持続的ログインが設定されると、ローカルフォルダ内のconfig.jsonは以下のようになります。

{
    "private_key": "8n0OqFi9o80xGh06bPzxTV1yLeKa5BdWc7f7CffZRQ",
    "device_token": "R2O5wkajo5UjVmbTmvWnwzf7DK1g_Yf-zZ3dWIbKPOng",
    "clone_code": "retObD9F0-WDABaUUGhP0Q",
    "user": "my_service_user@acme-demo.com",
    "server": "keepersecurity.com"
}

永続的ログインについてはコマンダーの資料の設定ページをご参照ください。

Keeperコマンダーを使用して自動化コマンドをカスタマイズする方法は数多くありますので、詳細についてはコマンダーの資料をご参照ください。

デバイス承認

概要

技術的詳細

承認方式

Keeperプッシュ通知

概要

Keeperプッシュ通知方式

手順

管理者承認

管理者管理コンソールからの管理者承認方法

デバイスの役割許可を承認する

Keeperオートメーターサービス

概要

オートメーターが必要とされる理由

インストール方法

Azure Container App

Azure App Service

Azure App Gateway

AWS Elastic Containerサービス

KSMを使用したAWS Elastic Containerサービス

Google Cloud (GCP Cloud Run)

スタンドアロンJava

Docker

Docker Compose

Kubernatesサービス

Windowsサービス

オートメーターのセキュリティ

バージョン17.0の概要

概要

チームユーザー承認

チームの承認

すべての設定が環境変数として設定可能

その他の機能

イングレス要件

データフロー

ネットワークファイアウォールのセットアップ

Azure Container Apps

概要

1. オートメーターConfigキーの作成

キーの生成

2. コンテナーアプリの作成

3. コンテナの詳細のセットアップ

4. イングレスのセットアップ

5. コンテナアプリの作成

6. イングレス設定のカスタマイズ

7. スケーリング、ヘルスプローブ、ボリュームマウントのセットアップ

8. アプリケーションURLの取得

9. Keeperコマンダーにログイン

10. オートメーターの作成

ユーザー体験のテスト

高度な機能

複数のコンテナーでのスケーリング

ログ作成

高度な設定

Azure App Services

概要

1. オートメーターConfigキーを作成

キーの作成

2. App Servicesウェブアプリを作成

3. Dockerコンテナの詳細をセットアップ

4. WebAppモニタリングをセットアップ

5. WebAppを作成

6. WebAppを構成

7. Diagnosticsをセットアップ

8. ログをセットアップ

9. App Serviceログのセットアップ

10. Log Streamを見る

11. Health Checkの構成

12. アクセス制限を構成

13. Keeperコマンダーへログイン

14. オートメーターを作成

ユーザー体験のテスト

Azure App Gateway (高度な設定)

概要

手順

セットアップは完了です。

Azure Portal

コンテナーの再起動時にIPを更新

オートメーターサービスのテスト

AWS Elastic Containerサービス