03 / SECURITY

Zoho Vaultのセキュリティ対策
「預けても大丈夫」と言える技術的な理由

大切なパスワードをクラウドに預けることに、不安を感じるのは自然なことです。しかしZoho Vaultは、「サービス提供者であるZoho自身にも中身が読めない」という設計になっています。このページでは、その仕組みを支える暗号化方式・鍵の管理・認証方法を、専門用語をかみ砕きながら具体的に説明します。

1. ゼロ知識アーキテクチャとホストプルーフホスティング

Zoho Vaultのセキュリティを理解するうえで、まず押さえるべき最重要の考え方がこれです。Zoho Vaultはゼロ知識アーキテクチャの原則にもとづいて動作し、ホストプルーフホスティング(Host-Proof Hosting)という方式でユーザーのデータを保護しています。

用語ゼロ知識(Zero-Knowledge)とは、サービス提供者が利用者のデータの中身を一切知らない(知り得ない)状態を指します。
用語ホストプルーフホスティングは、データを預かるサーバー(ホスト)側では復号できない形でデータを保管する設計手法です。「ホストに対して証明済み=ホストからは読めない」という意味合いです。

暗号化と復号はどこで行われるのか

ホストプルーフホスティングでは、データはユーザーのマスターパスワードを使い、クライアント側(利用者のブラウザやアプリ)でAES-256により暗号化・復号されます。そのため、Zohoのサーバーへ送信されるのは暗号化されたデータだけです。

これが何を意味するのか、順を追って確認しましょう。あなたがZoho Vaultに「AWSのパスワードは XyZ7#kL9 です」と登録したとします。この文字列は、あなたのブラウザの中で暗号化され、意味を持たないランダムな文字列に変換されてからインターネットを通ってZohoのサーバーへ送られます。Zohoのサーバーに保存されるのは、この変換後の文字列です。あなたが後日それを見るときは、暗号化された文字列がブラウザまで届き、ブラウザの中で元に戻されて画面に表示されます。

マスターパスワードはどこにも保存されない

ここで決定的に重要なのが、マスターパスワードがVault内のどこにも保存されないという点です。暗号を解く鍵はマスターパスワードから導かれますが、そのマスターパスワード自体はサーバーに送られず、保存もされません。つまり、Zohoのサーバーには「暗号化されたデータ」はあっても「それを解く鍵」が存在しません。

結果として、Zoho社であってもユーザーのデータにアクセスできないという状態が成立します。これは「アクセスしない約束をしている」のではなく、「技術的にアクセスできない」ということです。約束は破られる可能性がありますが、鍵が存在しないという事実は破りようがありません。この差が、徹底した情報セキュリティとプライバシーの根拠になっています。

利用者側(ブラウザ/アプリ) マスターパスワード ※ 本人しか知らない 保存したい情報 ID・パスワード・メモ AES-256 で暗号化 この処理はすべて手元の端末内で完結 8f3a…(意味をなさない暗号文) TLS Zoho のサーバー 保管されるもの 暗号化されたデータのみ (復号する鍵は存在しない) 保管されないもの マスターパスワード サーバーへ送信すらされない Zohoにも中身は読めない
図4:ホストプルーフホスティングの仕組み。暗号化・復号は利用者の端末内で完結し、サーバーには暗号文だけが渡ります。鍵がサーバーに存在しないため、仮にサーバーのデータが流出しても中身は読み取れません。
この設計がもたらす安心

仮にZohoのサーバーが攻撃を受け、保存されているデータがすべて盗まれたとしても、盗まれるのは暗号化された無意味な文字列だけです。中身を復元するには各利用者のマスターパスワードが必要ですが、それはサーバー上に存在しません。「クラウドに預けるのが怖い」という懸念に対する、最も本質的な回答がこの設計です。

2. 暗号化方式:AES-256とは何か

Zoho Vaultでは、すべてのパスワードと機密データがAES-256で暗号化されます。これは現在、世界で最も広く使われ、最も信頼されている暗号化方式のひとつです。

AESという方式について

AES(Advanced Encryption Standard)は、アメリカ国立標準技術研究所(NIST)が標準として選定した暗号方式で、政府機関から金融機関まで幅広く採用されています。暗号化と復号に同じ鍵を使う「共通鍵暗号」に分類され、処理が高速なため、大量のデータを扱うのに適しています。

「256」が意味すること

末尾の256は鍵の長さがビット数で256であることを示します。鍵のパターン数は2の256乗、つまり約1.15×10の77乗通りです。この数字は、観測可能な宇宙に存在する原子の数とほぼ同じオーダーだと言われます。総当たりで鍵を探す攻撃を行った場合、現在のコンピューターでは宇宙の年齢をはるかに超える時間が必要になり、現実的に破ることは不可能とされています。

2256鍵のパターン数
NIST米国標準として採用
クライアント側暗号化・復号の実行場所
保存されないマスターパスワード
暗号は「破られる」より「盗まれる」

AES-256そのものが計算によって破られる心配は、実務上ほぼ考えなくて構いません。現実の事故のほとんどは、暗号アルゴリズムの弱さではなく、鍵(=マスターパスワード)が人から漏れることで起きます。だからこそ、後述する多要素認証やマスターパスワードの管理が決定的に重要になります。

3. 鍵の仕組み:マスターパスワード・組織キー・RSA鍵ペア

「サーバーに鍵がないのに、どうやってチームでパスワードを共有できるのか」——これはZoho Vaultの設計を理解するうえで最も面白く、そして重要な部分です。答えは、複数種類の鍵を組み合わせることにあります。

3-1. 組織の管理者が登録したときに起きること

組織の管理者がZoho Vaultに登録すると、次のものが生成されます。

  • RSA公開鍵・秘密鍵のペア:公開鍵は「誰でも使える南京錠」、秘密鍵は「その錠を開けられる唯一の鍵」に相当します。
  • 組織キー(Org Key):その組織に固有の、AES 256ビットの鍵です。組織内で共有されるデータを暗号化するために使われます。

そして、管理者の秘密鍵は、管理者のマスターパスワードで暗号化されたうえでZoho Vaultのデータベースに保存されます。ここでもホストプルーフホスティングの原則が働き、管理者のマスターパスワードはサーバーのどこにも保存されず、管理者本人の手元にのみ存在します

3-2. なぜこの3層構造なのか

整理すると、鍵は次のような入れ子構造になっています。

鍵の種類役割保管場所
第1層マスターパスワードすべての起点。ここから暗号鍵が導かれる。利用者本人の記憶のみ(サーバーに保存されない)
第2層RSA秘密鍵組織キーを取り出すために使う。マスターパスワードで暗号化されてサーバーに保存
第3層組織キー(AES-256)組織で共有するシークレットを暗号化する。各ユーザーのRSA公開鍵で暗号化して配布
データシークレット本体実際のID・パスワード・メモなど。暗号化された状態でサーバーに保存

この構造により、「共有はできるが、サーバーは中身を読めない」という一見矛盾する要求が両立します。新しいメンバーに共有するときは、その人の公開鍵で組織キーを暗号化して渡します。受け取った本人だけが、自分のマスターパスワードで秘密鍵を解き、その秘密鍵で組織キーを取り出し、組織キーでデータを復号できます。この一連の処理はすべて利用者の端末内で行われ、サーバーは暗号化されたものを右から左へ受け渡しているだけです。

3-3. マスターパスワードを忘れるとどうなるか

重要:マスターパスワードの再発行はできません

マスターパスワードがサーバーに保存されていないということは、Zoho側で「あなたのパスワードはこれです」と教えることも、リセットして中身を復元することもできないということです。これはセキュリティ設計の必然的な裏返しです。
そのため、Zoho Vaultには緊急時に備えた仕組み(緊急アクセスの指定、リカバリー手段の事前設定など)が用意されています。導入直後に必ずこれらを設定しておいてください。設定していない状態でマスターパスワードを失うと、保管したデータへアクセスする手段が失われます。

4. 通信の保護

保存時の暗号化に加えて、データが移動している間の保護も行われます。Zoho Vaultとのすべての通信はSSL/TLSによって暗号化されます。

用語SSL/TLSは、インターネット上の通信を暗号化する仕組みです。ブラウザのアドレスバーに表示される鍵マークと「https://」がその証です。通信経路の途中(公衆Wi-Fiなど)で盗聴されても、内容は読み取れません。

ここで押さえておきたいのは、Zoho Vaultでは暗号化が二重にかかっている点です。通信経路はTLSで守られ、その中を流れるデータ自体もすでにAES-256で暗号化されています。つまり、仮にTLSが破られたとしても、そこから取り出せるのは暗号化されたデータだけです。多くのWebサービスは「通信はTLSで守るが、サーバー上では平文またはサーバー側の鍵で復号可能」という構成ですが、Zoho Vaultはこの点で一段厳しい設計になっています。

また、社内ネットワークからActive Directoryと連携する場合も、暗号化されたLDAPS通信を使うことが推奨されます(AD連携の詳細はこちら)。

5. 認証方法:多要素認証とアクセス制御

暗号がどれだけ強くても、正規の利用者になりすまされたら意味がありません。そこで重要になるのが「本当に本人か」を確かめる認証です。

多要素認証(MFA / 二要素認証)

Zoho Vaultは多要素認証に対応しています。パスワードという「知識」に加えて、別の要素を組み合わせることで、パスワードが漏れた場合でも不正ログインを防ぎます。

要素の種類具体例特徴
知識
(知っているもの)
マスターパスワード、PINコード基本の要素。ただし単独では漏えいリスクがある。
所持
(持っているもの)
スマートフォンの認証アプリが生成するワンタイムコード(TOTP)、SMSで届くコード、プッシュ通知による承認、ハードウェアセキュリティキー物理的にその端末を持っていないと突破できない。TOTPは30秒程度で切り替わる使い捨てコード。
生体
(本人であること)
指紋認証、顔認証(モバイルアプリ)スマートフォンでの解錠に利用。素早くかつ安全に開けられる。

Zohoが提供する認証アプリのほか、Google Authenticatorなど一般的なTOTP対応アプリ、YubiKeyのようなハードウェアセキュリティキーにも対応しています。組織としては、全ユーザーに多要素認証を必須化する設定を強く推奨します。これはコストをかけずに実施できる、最も効果の高いセキュリティ対策のひとつです。

MFAは「あれば良い」ではなく「必須」

フィッシングやパスワードリスト攻撃による不正ログインの大半は、多要素認証を有効にしていれば防げます。パスワード管理ツールは組織の機密情報が集約される場所であり、ここが破られると被害は全社に及びます。導入初日から全員必須で運用してください。

アクセス元・デバイスの制御

  • IPアドレス制限:社内ネットワークやVPN経由など、許可したIPアドレスからのみアクセスを認める設定ができます。
  • デバイスの管理:どの端末からログインされているかを一覧で確認し、不要になった端末や紛失した端末のアクセスを個別に遮断できます。
  • セッションの自動ロック:一定時間操作がないと自動的にVaultがロックされます。離席時の覗き見や、共有端末での放置を防ぎます。
  • ログイン試行の制限:連続して認証に失敗した場合にアカウントをロックし、総当たり攻撃を防ぎます。

6. 組織として設定できる防御策

Zoho Vaultは、管理者が組織全体に対してセキュリティの基準を強制できます。個々の利用者の判断に任せず、仕組みとして守らせる点が企業向けサービスの重要な性質です。

パスワードポリシーの強制

最低文字数、必要な文字種(大文字・小文字・数字・記号)、有効期間、過去に使ったパスワードの再利用禁止などを定義し、組織全体に適用できます。ポリシーに違反しているシークレットは一覧で洗い出せるため、「弱いパスワードがまだ何件残っているか」を数値で管理し、計画的に解消していけます。

役割ベースのアクセス制御

スーパー管理者、管理者、一般ユーザーといった役割を設定し、権限を分離します。最小権限の原則——業務に必要な最小限の権限だけを与える——を徹底することで、万一アカウントが乗っ取られたときの被害範囲を限定できます。特に管理者権限を持つ人数は、必要最小限に絞ってください。

侵害されたパスワードの検出

外部で発生した情報漏えいによって流出したパスワードを検出し、該当するものがVault内にないかを確認できる機能が提供されています(提供範囲はプランによって異なります)。「他社サービスから漏れたパスワードを自社でも使っていた」という危険な状態を、事故が起きる前に発見できます。

監査ログによる継続的な監視

誰がいつパスワードを閲覧・変更・共有したかがすべて記録され、内部統制や監査対応に活用できます。SIEM製品と連携すれば、他システムのログと組み合わせた高度な異常検知も可能です。詳細は主な機能のページを参照してください。「見られている」という前提が、内部不正に対する強い抑止力になる点も見逃せない効果です。

7. データセンターと準拠規格

Zohoは自社でデータセンターを運用しており、物理的なセキュリティ対策も講じられています。入退室管理、監視カメラ、生体認証による区画管理、電源・空調の冗長化、災害に備えたバックアップと複数拠点でのデータ保全などが実施されています。

また、Zohoは国際的なセキュリティ・プライバシー関連の認証や規格への準拠を公表しています。代表的なものとして、情報セキュリティマネジメントの国際規格であるISO/IEC 27001、クラウドサービスの内部統制に関する報告書であるSOC 2 Type II、EUの個人データ保護規則であるGDPRへの対応などが挙げられます。

確認をおすすめする項目

自社のセキュリティ基準や業界規制に照らして導入可否を判断する際は、以下を公式情報で確認してください。取得状況や対応範囲は時期によって変わるため、必ず最新の公表内容にあたることが重要です。

  • 取得している認証の種類と、その対象範囲(Zoho Vaultが対象に含まれるか)
  • データが保存されるリージョン(国・地域)と、リージョンの選択可否
  • バックアップの取得頻度と保持期間、災害時の復旧目標
  • サービス稼働率(SLA)と障害時の連絡体制
  • サブプロセッサー(再委託先)の一覧と所在地

特に、官公庁・金融・医療といった規制の厳しい業界では、データの保存場所(データレジデンシー)が導入判断の分かれ目になることがあります。契約前に、自社の要件を満たすリージョンが選択できるかを確認しておくことをおすすめします。

8. 利用者側で必ず守るべきこと

どれほど堅牢な金庫でも、鍵の扱いが甘ければ意味がありません。Zoho Vaultのセキュリティは、利用する側の運用と組み合わせて初めて完成します。以下は、導入時に必ず徹底すべき事項です。

  1. マスターパスワードを他のどこでも使わない

    マスターパスワードは、他のサービスと絶対に使い回さないでください。他社サービスから漏えいした場合、Vault全体が危険にさらされます。長さは最低でも16文字以上、意味のある単語を複数つないだ「パスフレーズ」形式が、覚えやすさと強度を両立できます。

  2. 多要素認証を全ユーザーで有効にする

    例外を作らないことが重要です。「役員は面倒だから免除」といった運用は、最も価値の高いアカウントを最も弱く守ることになり、本末転倒です。

  3. 復旧手段を事前に設定しておく

    マスターパスワードは再発行できません。緊急アクセスの指定やリカバリー手段を、導入直後に必ず設定してください。「必要になってから」では手遅れです。

  4. 端末そのものを守る

    Vaultを解錠した状態のパソコンを放置すれば、金庫の扉を開けたまま席を立つのと同じです。画面ロックの自動設定、ディスクの暗号化、OSとブラウザの更新、マルウェア対策を併せて実施してください。

  5. 権限を定期的に見直す

    半年に一度は、誰がどのシークレットにアクセスできるかを棚卸ししてください。プロジェクトが終わったのに共有が残っている、といった状態を放置しないことが重要です。監査ログのレポート機能が役立ちます。

  6. 退職・異動のプロセスに組み込む

    退職手続きのチェックリストに「Vaultのアクセス停止」と「個人フォルダの引き継ぎ」を明記してください。AD連携を導入していれば多くは自動化できますが、手順として明文化しておくことに意味があります。

セキュリティは「製品」ではなく「運用」で決まる

Zoho Vaultが提供するのは、強固な暗号化と柔軟なアクセス制御という「土台」です。その上にどのようなルールを敷き、どう定着させるかは導入する組織次第です。技術と運用の両輪がそろって初めて、パスワード管理は本当に安全になります。