Ctrlk
HomepageSystem Status
For the complete documentation index, see llms.txt. This page is also available as Markdown.

セキュリティと暗号化モデル

Keeperシークレットマネージャーのセキュリティと暗号化モデル

概要

Keeperシークレットマネージャーは、ゼロ知識プラットフォームです。シークレットの暗号化と復号は、ksm アプリケーション、CI/CDプラグイン、開発者向けSDKを実行しているクライアントデバイス上でローカルに行われます。

ワンタイムアクセストークン

ワンタイムアクセストークンは、運用時の認証情報ではなく、デバイスをプロビジョニングするための認証情報です。新しいクライアントデバイスとシークレットマネージャーアプリケーションの間で信頼関係を確立するためだけに使う、32バイトのランダム値です。クライアントはトークンのHMAC-SHA512ハッシュで認証し、トークンの生の値自体をAPIの認証情報として送ることはありません。トークンはクライアントの最初のAPI呼び出しで引き換えられ、サーバー側で消費済みとして記録され、クライアント側の構成からも削除されます。2回目の引き換えは失敗します。トークンには有効期限があり、作成時に送信元IPへロックすることもできるため、引き換え前のトークンが露出する期間を抑えられます。

ワンタイムアクセストークンにより、クライアントデバイスはKSMアプリケーションへの初回かつ単回の認証を得られます。トークンの秘密値は32バイトのランダム値で、パディングなしのURLセーフBase64としてエンコードされ、常にアルファベット [A-Za-z0-9_-] からなるちょうど43文字になります。

トークンには、Keeperのリージョン略称とコロンが接頭辞として付きます。

<REGION>:<43-char URL-safe Base64 secret>

例:

US:Vn2tFX0c8xtpBElBiBbzFyDkk8-3zZX90tLal0jzN0U

既知のリージョン接頭辞: US、EU、AU、CA、JP、GOV、US_GOV。

pencil-line

トークンは単回使用です。クライアントの最初のAPI呼び出しで引き換え (消費) された後、構成から削除されます。

構成

トークンを引き換えると構成が生成されます。構成は、単一のクライアントデバイスの永続的な識別情報です。初回認証時、クライアントはECC secp256r1鍵ペアをローカルで生成し、公開鍵のみをKeeperに登録します。以降のすべてのリクエストはクライアントデバイスの秘密鍵で署名され、サーバー側でECDSAにより検証されます。初回設定の完了後、認証経路に共有秘密は残りません。秘密鍵はデバイスから離れることがなく、Keeperにも知られないため、サーバー側のデータを再生してクライアントになりすますことはできません。

各構成はクライアントデバイスと1対1で対応します。構成が漏洩した場合、含まれる clientId から取り消すべきデバイスを正確に特定でき、アプリケーションのローテーションやレコード鍵の再生成なしに、アクセスを直ちに切断できます。

すべてのKSM SDKおよびインテグレーションは、共通の構成フォーマットを使用します。構成の実体はJSONオブジェクトであり、一部のインテグレーションでは同じJSONをBase64でラップした形式も受け付けます。

例:

ゼロ知識による復号

構成には、復号の起点となるアプリケーションキー (AES-256) も含まれます。シークレットは階層化された鍵構造で保護されます。アプリケーションキーで共有フォルダ鍵およびレコード鍵が復号され、それらで個々のレコード内容が復号されます。すべての復号はクライアントデバイス上でローカルに行われます。Keeperクラウドは暗号文のみを保存・送信し、配信するシークレットを読み取るために必要な鍵を保持しません。アプリケーションキー自体はラップされた状態で配信され、ワンタイムトークンから導出された鍵材料でのみアンラップされます。

構成の保護

Keeperシークレットマネージャー構成の保護は、環境全体のセキュリティ体制において重要です。

シークレットマネージャーCLI では、デフォルトでオペレーティングシステムのネイティブなセキュアストレージに構成を安全に保存します。平文ファイルに認証情報を保存する場合と比べて、セキュリティが強化されます。

仕組み

オペレーティングシステム
セキュアストレージ

macOS

Keychain

Windows

Windows資格情報マネージャー

Linux

Secret Service (GNOME Keyring、KWallet)

ユーザーがシークレットマネージャーのプロファイルを初期化すると、認証情報はOSネイティブのセキュアストレージに自動保存されます。オプションとして、ファイルベースの保存を使う場合は、keeper.ini ファイルに構成を保存することもできます。

ローカルファイル保存オプションを有効にした場合、keeper.ini ファイルは以下の形式になります。

Keeperの開発者向けSDKを利用する場合、サードパーティのシークレット保管ソリューションとの連携により構成ファイルを保護するさまざまな方法があります。

構成パラメータ

各構成パラメータの説明は以下のとおりです。

構成名
説明

clientkey

ワンタイムアクセストークン。初回使用後に削除 (32バイトのランダム値)

clientid

クライアントデバイスの一意の識別子 (ワンタイムアクセストークンのHMAC_SHA512ハッシュ)

privatekey

クライアントデバイスの秘密鍵 (ECC secp256r1)

appkey

アプリケーションの秘密鍵 (AES-256)

hostname

宛先エンドポイント。US、EU、AU、JP、またはUS_GOV

serverpublickeyid

伝送ラッパー用のKeeper API公開鍵の識別子

認証と暗号化

クライアントデバイスは、ハッシュ化されたワンタイムアクセストークンで1回だけ認証します。クライアントはペイロードに署名し、初回認証時にクライアントデバイスの公開鍵をサーバーに登録します。初回認証以降のリクエストは、クライアントデバイスの秘密鍵で署名されます。

KeeperクラウドへのAPIリクエストは、クライアントデバイス識別子と、クライアントデバイスの秘密鍵で署名されたリクエストボディとともに送信されます。サーバーは、そのデバイスのクライアント公開鍵を使用して、指定されたクライアントデバイス識別子に対するリクエストのECDSA署名を検証します。

クライアントデバイスは、アプリケーションの秘密鍵を使用してサーバーからの暗号文レスポンスを復号し、レコード鍵と共有フォルダ鍵を復号します。共有フォルダ鍵でレコード鍵が復号され、レコード鍵で個々のレコードのシークレットが復号されます。

IP制限によるアクセスの保護

デフォルトでは、クライアントデバイスのプロファイルを作成するとIP制限が有効になります。

例:

このトークンで初期化したクライアントは、IPが固定されます。IP制限を無効にするには、以下のパラメータを追加で指定します。

動的WAN IPの環境にデプロイする場合を除き、IP制限を有効にすることを推奨します。

アクセスの取り消し

構成が漏洩した場合、または直ちに取り消す必要がある場合は、コマンダーCLIから以下を実行します。

その他の情報

Keeperはゼロ知識セキュリティアーキテクチャとゼロトラストフレームワークを活用した、業界最高水準のセキュリティを採用しています。Keeperのゼロ知識暗号化モデルに関する技術資料については、以下のリンクをご参照ください。

Keeperの暗号化モデル

シークレットマネージャー暗号化モデル

セキュリティ情報開示ページ

KeeperはSOC 2 Type 2、ISO27001の認証を取得しており、FedRAMP HighおよびStateRAMP Highの認可も受けています。各種認証レポートや技術アーキテクチャに関するドキュメントへのアクセスは、Keeperトラストセンターから申請できます。

脆弱性情報開示プログラム

KeeperはBugcrowdと提携して、脆弱性情報開示プログラムを運営しています。https://bugcrowd.com/keepersecurity からレポートを送信するか、security@keepersecurity.comにメールでご連絡ください。

前へ用語次へワンタイムアクセストークン

最終更新