1Passwordに保存したデータは、社員の端末の中で暗号化されてからサーバーに送られます。復号に要る鍵は社員の側にだけあり、1Password社はデータを読めません。この性質をゼロナレッジと呼びます。ただし、サーバーが何も知らないわけではありません。誰が組織にいて、どの端末からサインインしたかといった情報は、サービスを動かすためにサーバーが持っています。社内や顧客に説明するときは、守られているものと守られていないものを分けて伝える必要があります。このページでは、暗号と認証の役割分担、鍵の階層と共有の仕組み、1Password社に見えるものと見えないもの、サーバー側で鍵を扱う処理、暗号では守れないもの、社内説明での言い方を説明します。
認証ではなく暗号で守る設計
多くのクラウドサービスは認証でデータを守ります。サーバーが本人かどうかを確かめ、正しければデータを見せる方式です。この方式では、門番に当たるサーバーが乗っ取られたり、パスワードのリセットの仕組みを悪用されたりすると、中身に届いてしまいます。データそのものは暗号化されていないか、サーバーが鍵を持っているためです。
1Passwordは、データを読めるかどうかを暗号で決めています。読むには正しい鍵が要り、その鍵はサーバーにありません。サーバーの認証が完全に破られても、攻撃者の手に入るのは暗号化されたデータだけです。
一方で、認証が要らないわけではありません。端末の間の同期、保管庫ごとの書き込みや管理の制限、アクセス権の取り消しは、サーバーが認証の結果をもとに行います。役割を分けると次の通りです。
| 仕組み | 担うこと |
|---|---|
| 暗号 | 中身を読めるかどうか |
| サーバーの認証とポリシー | 同期、書き込みや管理の制限、アクセス権の取り消し |
| アプリの制御 | エクスポートや印刷など画面上の操作の制限 |
どのパーミッションがどの仕組みで守られているかは、権限が強制される仕組みで扱います。
鍵の階層と共有の仕組み
保管庫とアカウントの鍵は全て社員の端末で、暗号学的に安全な乱数から作られます。サーバーがこれらの鍵を作ることはありません。鍵は階層になっていて、下の鍵を上の鍵で包む形で守られています。
アイテムと保管庫の鍵
保管庫ごとに固有の鍵があり、その保管庫のアイテムはこの鍵で暗号化されます。方式はAES-GCMの256ビットで、改ざんを検知できる暗号です。暗号化されるのはパスワードの欄だけではありません。アイテムの名前、URL、タグ、カスタムアイコンも暗号化されます。
本人のキーセット
社員は1人ずつ、公開鍵と秘密鍵の組を持っています。保管庫の鍵は、その保管庫を使える人の公開鍵で1つずつ暗号化して配られます。秘密鍵を持つ本人だけが保管庫の鍵を取り出せます。秘密鍵そのものは、アカウントパスワードとSecret Keyから作る鍵で暗号化されています。この仕組みは認証と鍵の設計で扱います。
グループへの共有
グループにも公開鍵と秘密鍵の組があります。保管庫をグループに共有すると、保管庫の鍵はグループの公開鍵で暗号化されます。グループの秘密鍵は、メンバーだけが取り出せる形で渡されます。メンバーを増やしても、保管庫ごとに鍵を配り直す必要はありません。
復旧を担うグループには、保管庫の鍵の写しが渡っています。社員がアカウントパスワードを忘れても組織の中で復旧できるのはこのためです。裏返すと、復旧のパーミッションは、暗号の上では全ての保管庫に届きます。
1Password社に見えるもの、見えないもの
1Password社が復号できないのは、保管庫とアイテムの中身です。アカウントパスワード、Secret Key、暗号の鍵も受け取りません。社員がサポートに送る診断の情報にも、これらは入りません。
サービスを動かすために、サーバーが暗号化せずに持っている情報もあります。利用の量は、1Password社がサービスとサポートのために集めている情報です。
| 区分 | 1Password社が持つ情報 |
|---|---|
| 組織 | 組織名、サインインアドレスのドメイン、アイコン |
| 人 | 氏名、メールアドレス、プロフィール画像 |
| グループ | グループの名前、説明、アイコン |
| 端末 | サインインしたIPアドレス、端末の機種、OSとバージョン |
| 認証 | 2要素認証のシークレット、公開鍵 |
| 利用の量 | サインインした日時、保管庫とアイテムの数、使っている容量 |
グループの名前と説明が暗号化されない点は、設計で見落とされがちです。プロジェクトのコード名や取引先の名前をグループの説明に書くと、その文字列は暗号で守られません。機密に当たる情報は保管庫の中に置き、グループには役割の名前だけを付けてください。
【注意】 保管庫の名前は暗号化されますが、グループの名前と説明は暗号化されません。M＆Aの案件名のように名前そのものが機密になる場合は、グループの名前を一般的なものにしてください。
サーバー側で鍵を扱う処理
ゼロナレッジの設計では、サーバーは鍵を持てません。そのため、サーバーが代わりに鍵を扱う処理は作りにくくなります。自動プロビジョニングはその例外で、IDプロバイダーから届いた指示をもとに、1Passwordの基盤の中で人をグループに加えます。
この処理は、AWS Nitro Enclavesを使ったコンフィデンシャルコンピューティングの環境で動きます。エンクレーブと呼ばれる隔離された環境で、1Password社の運用者もクラウド事業者の運用者も、中のコードとデータに触れられません。この隔離は運用の規則ではなく、ハードウェアで強制されています。
アプリは、エンクレーブで動いているコードが1Password社の署名した既知のものかを確かめてから通信します。配備したコードの版は、第三者が運営する公開の記録に全て載ります。さらに、処理の前に全ての公開鍵が本物かをAccount Trust Logの役割で扱う仕組みで検証します。
暗号では守れないもの
暗号が守るのは、鍵を持たない人からのデータです。次の場面は暗号の外にあります。
| 場面 | 起きること |
|---|---|
| 端末がマルウェアに侵害された | ロックを解除している間は、メモリーから中身を読み取られうる |
| 保管庫から人を外した | 暗号の鍵は変わらない。以前に鍵を控えていた人は、暗号化されたコピーを入手できれば後から加えた中身も読める |
| 招待と復旧のメール | メールの受信箱を乗っ取られると、復旧の手続きを悪用されうる |
| ブラウザーの拡張機能 | 他の拡張機能が、入力欄に自動入力した値を読みうる |
保管庫から外した人に後から加えた中身を見せたくない場合は、新しい保管庫を作ってアイテムを移してください。新しい保管庫には新しい鍵が作られます。メールを使う手続きの守り方は復旧の設計（誰が復旧できるか）で扱います。
社内説明での言い方
社内の説明では、「1Password社も中身を読めない」と「1Password社は誰がいつ使ったかを知っている」を一緒に伝えてください。前者だけを伝えると、利用の記録も残らないと受け取られます。後者を伏せると、後で監査ログを見せたときに説明が食い違います。
技術部門から鍵の長さや計算の手順まで問われた場合は、<a href="https://1pw.ca/whitepaper/" target="_blank">1Passwordのセキュリティー設計のホワイトペーパー</a>を示してください。暗号の方式と鍵の扱いが仕様の水準で公開されています。
【運用のポイント】 審査の回答書では、「暗号化しています」ではなく「端末の中で暗号化し、鍵はサーバーに渡りません」と書いてください。暗号化の有無ではなく鍵の置き場所が問われているためです。回答書の組み立て方はセキュリティー審査への回答の作り方で扱います。