保管庫を人やグループに共有するとき、1Passwordは保管庫の鍵を相手の公開鍵で暗号化します。この公開鍵が本当に相手のものかどうかを、以前のアプリは確かめる手段を持っていませんでした。Account Trust Logは、アカウントで信頼する公開鍵を署名付きで記録していく台帳です。これがあると、1Passwordのサーバーが乗っ取られて偽の鍵を返されても、アプリがそれに気付けます。自動プロビジョニングを初めて設定したときに有効になり、その後は無効にできません。このページでは、Account Trust Logが解決する問題、有効になる時点と記録される内容、記録の連なりと検証の仕組み、サーバーが書き込める記録、監査ログとの違い、自動プロビジョニングの前に確かめることを説明します。
公開鍵をすり替えられる問題
エンドツーエンド暗号化には、昔から知られた弱点があります。暗号化に使う相手の公開鍵をサーバーから受け取る以上、サーバーが偽の公開鍵を返すと、データは攻撃者が読める形で暗号化されてしまいます。いわゆる中間者攻撃です。
SCIM Bridgeを含む従来のアプリは、サーバーから受け取った公開鍵とキーセットをそのまま信用していました。サーバーが乗っ取られ、本物のキーセットの代わりに攻撃者のキーセットを返されても、見分けられません。自動プロビジョニングは1Passwordの基盤の中で人をグループに加えるため、この問題を放置できませんでした。Account Trust Logは、その解決として作られた仕組みです。
有効になる時点と記録される内容
Account Trust Logは、組織の管理者が自動プロビジョニングを初めて設定したときに有効になります。そのとき、全員のキーセットと全グループの鍵が、設定した管理者の署名で台帳に記録されます。これ以降、台帳を書き換えるには、既に台帳に載っている管理者の署名が要ります。
一度有効にすると無効にできません。台帳に書いた記録は、1Password社を含めて誰も消したり書き換えたりできません。台帳に個人のデータは入りません。記録されるのは、どの鍵を信頼するかという情報です。
有効になった後は背後で動きます。不正な動きが検知されない限り、社員や管理者の操作は要りません。
記録の連なりと検証
台帳は記録を1本の鎖のようにつないだものです。記録ごとに4つの要素を持ちます。
| 要素 | 内容 |
|---|---|
| 操作 | 人やグループの追加など、信頼する鍵をどう変えるか |
| 直前の記録のハッシュ | 1つ前の記録と結びつける値 |
| 署名 | 記録を作った人の秘密鍵による署名 |
| 付帯情報 | 記録の補足 |
各記録が直前の記録のハッシュを含むため、途中の1件を書き換えると、それ以降の全ての記録と整合が取れなくなります。改ざんは必ず検知されます。
台帳とあわせて、ある時点で信頼している鍵の一覧も作られます。これをWorld Stateと呼び、記録1件ごとに1つのWorld Stateが決まります。共有の鍵を暗号化するような処理では、アプリはこの一覧から相手の公開鍵を引きます。

新しい記録を足すときは、最新の記録とWorld Stateを起点に、操作を当てはめて新しいWorld Stateを計算します。

新しい記録は署名してサーバーに送られ、台帳の末尾に加わってアカウントの全員に配られます。

各アプリは、受け取った記録を順に確かめます。署名が台帳に載っている鍵のものか、直前の記録のハッシュが正しいか、番号が1つずつ増えているかの3点です。全てを満たすまで、新しい状態を信頼しません。確かめ終えた位置は目印として署名付きで残るため、別の端末で同じ範囲を確かめ直す必要はありません。
サーバーが書き込める記録
台帳の目的はサーバーの介入を抑えることですが、利用者の署名なしにサーバーが状態を変えなければならない機能もあります。一時停止ユーザーを一定の日数で自動的に削除するポリシーがその例です。
このためにサーバーが書ける記録が用意されています。使える操作は少数に固定されていて、利用者の鍵を新しく加えることはできません。サーバーが不正な記録を書いても台帳に残って見えるうえ、最悪でもサービスを止めるだけで、偽の鍵を信頼させることはできません。自動削除の設定は参加から削除までのアカウントポリシーで扱います。
監査ログとの違い
どちらも組織の中の操作の記録ですが、目的が違います。
| 観点 | 監査ログ | Account Trust Log |
|---|---|---|
| 目的 | 管理者が操作を調べる | アプリが公開鍵を検証する |
| 記録の範囲 | 管理の操作全般 | 信頼する鍵を変える操作 |
| 操作した人の署名 | 付かない | 本人の秘密鍵で署名する |
| 読む人 | 管理者が画面で読む | アプリが自動で確かめる |
Account Trust Logの記録は、操作した本人の秘密鍵で署名されています。秘密鍵は本人のAUKで守られているため、誰の操作かを後から否定できません。一方で、管理者が画面で読んで調査に使うのは監査ログです。調査の手順は監査ログの読み方で扱います。
自動プロビジョニングの前に確かめること
Account Trust Logは、有効にした時点のアカウントの状態を正しいとみなします。それ以降の改ざんは検知できますが、有効にする前から紛れ込んでいた鍵は正しいものとして台帳に載ります。有効にした後は取り消せないため、自動プロビジョニングを設定する前に次の3点を確かめてください。
メンバーの一覧
招待したまま放置している人、退職したのに削除していない人、見覚えのない人がいないかを確かめます。不要な人は設定の前に削除します。
所有者と管理者の顔ぶれ
最初に台帳へ記録を書くのは、自動プロビジョニングを設定した管理者です。以後の記録は台帳に載った管理者の署名で積み上がります。所有者と管理者を必要な人数に絞り、設定する人を決めてから作業に入ってください。設計は所有者と管理者の設計で扱います。
設定する端末
設定する管理者の端末がマルウェアに侵されていれば、最初の記録そのものが信用できなくなります。設定は、管理者が日常的に使っている業務の端末で行い、共用端末や私物の端末は避けてください。
【運用のポイント】 Account Trust Logは、自動プロビジョニングを選ぶ理由の1つになります。SCIM Bridgeの自己ホスト型は公開鍵も許可ドメインも検証しません。セキュリティー審査で鍵の検証を問われたときは、自動プロビジョニングの構成で答えてください。比較は自動プロビジョニングの仕組みと前提で扱います。