暗号化について
企業はなぜ、クラウドに移行するのでしょうか?一般的にクラウド環境には拡張性と信頼性があり、また可用性が高いからです。しかし、それだけではありません。何よりもクラウドが優先的に考慮される理由は、セキュリティ面です。
クラウドプロバイダは包括的なセキュリティ戦略を擁する必要があります。Zohoのセキュリティ戦略は様々な側面をカバーしていますが、なかでも暗号化は、その重要な要素です。
このページでは、Zohoの暗号化に関する戦略と、当社がその戦略によってお客さまのデータを安全に保つ方法について説明します。
概要
- 暗号化とは?
- 転送時の暗号化
- 保存時の暗号化
- アプリケーションレベルの暗号化
- 鍵の管理
- 当社サービスで暗号化するデータの種類
- ディスク全体の暗号化
暗号化とは?
暗号化は主にメールの内容の保護に利用され、受信者だけがメールを読めるようにするために使用されています。つまり、宛先とされる受信者のみが閲覧でき、他の人には識別できないデータとして内容を置き換えます。このように暗号化はデータを盗もうとする人からデータを守る手段として使われます。
暗号化とは、データが識別不能(暗号化された状態)になるように特別なエンコードプロセスでデータを変換することです。その後、特別なデコードプロセスを適用することで元の識別可能なデータ形式に戻されます(復号化)。デコードプロセスは秘密にされるため、誰にも暗号化された公開データを元に戻すことはできません。
エンコードプロセスは、AES 256のような公開されている暗号化アルゴリズムに従います。しかし、プロセス自体はそのデータを暗号化したり復号化したりする鍵に依存しています。
その鍵は非公開であるため、暗号化されたデータへのアクセスに成功したとしても、その鍵がなければ、実質的に意味のない「暗号文」としてしか見ることができません。データはこのようにして保護されています。
お客さまのデータを暗号化する理由
保護の最後の砦:包括的なセキュリティ戦略によって組織的にハッカーからデータを保護することができますが、データを盗もうとする試みに対する最終的な砦となるのは暗号化です。セキュリティ侵害が発生しても、データはダメージを受けずまた盗み取られないため、データ保護をすることができます。
プライバシー- 暗号化により、安心してインターネットを取り巻くプライバシー問題に対応することができます。暗号化は、その情報を必要とする当事者宛として、個人情報を「親展」データに変えることでプライバシーを保護します。当社とのやり取りや当社のサーバーに保存されるデータは暗号化により確実に保護されます。
「データ」の定義
当社が取り扱うデータには2種類あります。
顧客データ- お客さまがZoho サービスを介して当社に保存するデータ通常、こうしたデータは当社IAM(IDおよびアクセス管理)データベースにより識別されたお客さまのアカウントを通じて処理されます。顧客データを暗号化するか否かは、データの機密度とユーザーの要件に依存します。機密データとは、公開されると関係する個人や組織に被害が発生する可能性のある情報です。
派生データ- お客さまから直接提供されたデータではなく、提供されたデータから派生したデータのことであり、例えば、認証トークン、固有ID、URL、レポートなどが当社のデータベースに保管されています。派生データを暗号化するか否かは、データの秘密度に依存します。
以後、「データ」は暗号化されたデータを意味します。
転送時の暗号化
Zoho サービスを使用すると、お客さまのデータはお使いのブラウザからインターネットを経由して当社のデータセンターまたはその他第三者サービス(外部サービス連携を使用している場合)に移動します。転送中のデータは、暗号化することで中間者攻撃から保護されます。
転送中のデータが以下2つに該当する場合に暗号化されます。
- データがご利用中のブラウザから当社のサーバーに移動するとき
- データが当社サーバーからZoho以外(第三者)のサーバーに移動する
とき
お客さまとZohoサーバー間の安全な接続の確立
Zohoは、すべての接続にトランスポート層セキュリティ(TLS)を適用する厳しい規定を設けています。TLSは、その接続に関連する両当事者の認証を求め、転送するデータを暗号化することで、お客さまとZohoサーバー間に安全な接続を確立します。TLSプロトコルにより、お客さまとZohoサーバー間での通信に、第三者による盗聴や改ざんが起こらないようにします。
当社は、最新のTLSプロトコルバージョン1.2/1.3に従って、SHA 256が発行する証明書と暗号(暗号化にはAES_CBC/AES_GCMの256ビット/128ビット鍵、メッセージ認証にはSHA2、鍵交換メカニズムとしてECDHE_RSA)を使用しています。また、PFS(Perfect Forward Secrecy)を実装し、すべてのサイトにHSTS(HTTP Strict Transport Security)を実行しています。
Zohoと第三者との間
当社は、HTTPSプロトコルに従い第三者との通信を行っています。機密データやユースケースなどのトランザクションに対しては、データの暗号化と復号化に公開鍵と秘密鍵のシステムを利用する、非対称暗号化のシステムを用いています。
この方法では、KMS(鍵管理サービス)で公開鍵と秘密鍵のペアを生成します。これにより、すべてのサービスで鍵が作成、保存、管理されます。この鍵のペアは、マスター鍵を使用して暗号化されKMSに保管されます。また、マスター鍵自体は、別のサーバーに保管されます。
秘密鍵をKMSに保管したまま、証明書を通じて公開鍵を第三者が利用できるようにし、認証後に暗号化されたデータがKMSで復号化されます。
保存データの暗号化
暗号化には、主に以下の2つレベルがあります。
- アプリケーションレベルでの暗号化
- ディスク全体に対するハードウェアベースの暗号化
アプリケーションレベルでのデータ暗号化は、データの保管場所と保管方法により異なります。
- データベース(DB) - テーブルとして保管されます
- 分散ファイルシステム(DFS) - ファイルとして保管されます
- URLの暗号化
- バックアップ
- ログ
- キャッシュ
下の図は、当社の暗号化の流れを表しています。
アプリケーションレベルの暗号化
Zoho サービス(またはアプリケーション)には、お客さまから提供されるデータと当社がサービスの一環としてお客さまに代わって保管するデータが保管されます。データは、1つのファイルまたは複数のデータ項目として受信され、そのカテゴリーはそれぞれ異なる暗号化がされます。
ここでは、アプリケーションレベルでの保存データの暗号化について説明します。
データベース暗号化
お客さまがアプリケーションに入力した機密データやサービスデータは、テーブルとしてデータベースに保管されます。
テーブルデータは、AES 256に従いAES/CBC/PKCS5Padding方式で暗号化されます。保存時に暗号化されるデータは、選択するサービスによって異なります。サービスで暗号化するデータの詳細はこちらを参照ください。ただし、データ項目の機密度、ユーザーの指定や要件により、暗号化のレベルは異なります。
データベースの暗号化には以下の2つのレベルがあります。
- データの機密度との依存関係
- 検索機能との依存関係
注:以降、Zoho サービスを利用している一定数のユーザーアカウントを持っているお客さま、または組織を「組織」と呼びます。
データの機密度との依存関係
レベル1- すべての組織から受け取るデータに対して行われる規定レベルの暗号化です。このレベルでは、当社のKMSは各組織に1つの鍵を割り当てます。その組織のデータはこの鍵を使用して暗号化されます。鍵はマスター鍵を使用して暗号化され、別のサーバーに保管されます。
レベル2- 機密情報や個人識別情報(PII)に対して行われる暗号化レベルです。銀行口座番号、ID番号、生体認証データなどの項目がこれに該当します。
このレベルでは、KMSによってテーブルの各列に固有の鍵が生成されます。特定の列にあるすべてのデータが、その列用に生成された鍵を使用して暗号化されます。これらの鍵は、マスター鍵を使用して再び暗号化され、別のサーバーに保管されます。
検索機能との依存関係
初期化ベクトル(IV)は、暗号化プロセスを開始するランダムな値です。このランダム値により、各データブロック/単位に異なる暗号化が行われます。これはまた、同じデータを2回暗号化すると異なる暗号文が生まれることを意味しています。
初期化ベクトルが重要な理由
初期化ベクトルを利用せず、自社の鍵だけで暗号ブロックチェーン(CBC)方式を使用すると、同一のデータで始まるデータセットには、同一の先頭ブロックが生成されます。初期化ベクトルは、2つの異なるデータの暗号化(ブロック暗号レベルで同じ鍵を使用)を行った場合に、一方のデータがもう一方のデータと一定の関連性がある(同じ先頭ブロックで開始される、などが含まれるがこれに限定されない)としても、同じ入力/出力ペアが生成される可能性を引き下げます。
暗号化をリクエストするたびに1つのランダム初期化ベクトルが生成されるようにすると、先頭ブロックが異なったものになります。攻撃者は、暗号化されたデータを復号化する手がかりを何も見つけることができません。
等値保持暗号化(Equality Preserving Encryption): テーブル全体に対する既定レベルの暗号化です。このレベルでは、データテーブル全体で1つの初期化ベクトルを取得します。これは、暗号文の全ブロックをテーブルの検索クエリで使用できることを意味します。初期化ベクトルは、テーブル内のすべてのデータに同様に利用できるため、検索すればそのデータが取得できます。
標準暗号化: このレベルでは、各データエントリーが、固有の初期化ベクトルを有します。1つの鍵でテーブル全体を暗号化したとしても、暗号化された各データエントリーは固有の暗号文を生成します。また、初期化ベクトルはデータごとにランダムかつ固有に生成されるため、検索してもそのデータを取得できないため、等値保持(Equality Preserving)バリエーションよりも、安全なオプションです。
各バリエーションの利用シチュエーション
特定のバリエーションを使用するか否かは通常、要件によって決定されます。データを最も高いレベルで保護する必要がある場合は、標準暗号化のレベル-2を使用します。最も高い保護を必要とするのは一部の項目だけで、すべてのデータ項目ではない場合でも、標準のレベル2の保護バージョンであれば十分でしょう。
しかし、要件は常に保護に関するものだけとは限りません。ユーザーが「メールアドレス」などの項目を検索してデータを取得したい場合は、標準オプションは意味をなさないので「等値保持」バリエーションが適しています。
分散ファイルシステム暗号化
作成したり、添付したファイルは、当社の分散ファイルシステム(DFS)に保存されます。保存時に暗号化されるファイルは、選択するサービスによって異なります。サービスで暗号化するファイルの詳細はこちらを参照ください。
暗号化は標準のAES 256アルゴリズムに基づいて行われ、暗号化はCTRモード、もしくはGCMモードのいずれかで行われます。AES 256では、暗号化する必要のある平文がデータまたはブロックのパケットに分散されます。ここでファイルの内容を暗号化しているので、アルゴリズムによりブロックごとの暗号化が確実に他から独立して実行されるようにする必要があります。そのため、ブロックの暗号文が侵害されたとしても、攻撃者がファイルに関する情報を取得することはできません。この要件にはCTRモードが最適です。
データベースの暗号化と同様に、ファイルの暗号化にも以下の2つのレベルがあります。
レベル1- このレベルでは、各組織に1つの鍵が与えられます。その組織の各ファイルは、この鍵を使用して暗号化されますが、各ファイルと共に固有のランダム初期化ベクトルが保存されます。この鍵は、マスター鍵を使用して再び暗号化され、KMSに保管されます。
レベル2 -このレベルでは各ファイルに固有の鍵が与えられ、ファイルはその鍵を使用して暗号化されます。ファイルの暗号化に使用されたそれぞれの鍵はマスター鍵を使用して再び暗号化され、暗号化された鍵はそのファイルと共に分散ファイルシステムに保存されます。このマスター鍵は、そのサービスやアプリケーションに固有のもので、KMSに保管されます。
URLの暗号化
招待リンクなど、お客さまと当社間での通信内容にはURLとして渡される機密情報が含まれる可能性があります。この通信内容を保護するため、URLの一部は暗号化されます。URLの中にドキュメントのIDなど識別可能なものがあれば、その部分が暗号化されます。
この暗号化には2つのレベルがあり、組織ごとに1つの鍵、もしくはURLごとに1つの鍵になります。これもURLに含まれるデータの機密度により決定されます。
バックアップ暗号化
当社は2つのスケジュール(毎日、毎週)に基づきバックアップを作成します。バックアップサーバーには、メインサーバーと同一レベルの保護機能が搭載されています。当社がバックアップとして保存するデータは、すべて暗号化されます。暗号化にはAES 256アルゴリズムを使用し、その鍵を別のサーバーに保管しています。また、高い可用性を保証するため、データセンターには冗長性をもたせています。これらのデータセンターも暗号化されたお客さまのデータのコピーが保管されており、メインのデータセンターと同じようにバックアップが作成されます。
ログの暗号化
Zoho Logsは、ログを保存し管理するためにHDFS(Hadoop Distributed File System)を使用しています。当社は、Hadoop社の暗号化技術を使用してデータを暗号化し、当社KMSで鍵の管理を行っています。
キャッシュの暗号化
当社では、キャッシュデータの保存と管理にRedisオープンソースソフトウェアを使用しています。キャッシュには、そのサービスの稼働に繰り返し使用され、一定の時間保管が必要なデータが含まれています。お客さまのデータは、サービスの向上やトラブルシューティングのためにキャッシュが生成される可能性があります。データに機密性の高い個人情報が含まれている場合は、それを暗号化しています。
鍵の管理
当社内の鍵管理サービス(KMS)は、すべてのサービスにおける鍵の作成、保管および管理をしています。当社は、KMSを使って鍵を所有および管理し、現在、お客さまが所有されている鍵でデータを暗号化する機能はありません。
暗号化の様々な段階で用いられる鍵には、以下の異なるタイプがあります。
データ暗号化鍵(DEK):この鍵は、平文から暗号文に、データを変換するため、またはデータを暗号化するために使用されます。
鍵暗号化鍵(KEK):この鍵は、DEKの暗号化に使用されるサービス固有の鍵で、セキュリティに追加のレイヤーを提供します。
マスター鍵:この鍵はKEKの暗号化に使用され、隔離されたサーバーで安全に保管されます。
KMSの役割りとは?
すべてのタイプの暗号化はAES 256アルゴリズムに従っています。このアルゴリズムによって暗号化されるデータは「ブロック」として取り扱われます。データベースの項目であるかDFSのファイルであるかを問わず、データのブロックがDEKを使用して暗号化された時から暗号化が開始されます。
このDEKはKEKでさらに暗号化されます。KEKは、別のサーバーに保管されているマスター鍵を使用して再び暗号化されます。下記、管理が必要とされる要素です。
- 暗号化されたデータ
- DEK
- 暗号化されたDEK
- KEK
- 暗号化されたKEK
- マスター鍵
KMSはこれらの要素を以下のように管理します。
リクエストを開始する
Zoho サービスに認証されたデータをリクエストするユーザー
転送中の暗号化
TLSベースの暗号化
アプリケーションフロントエンド
トラフィックをアプリケーションサーバーに転送します
アプリケーション・サーバー
暗号化プロセスを開始します
鍵管理サービス
データ暗号化鍵(DEK)を生成/取得します
マスターサーバー
鍵暗号化(KEK)を生成/取得します
KMSデータベース
暗号化されたDEKを保存します
鍵管理サービス
暗号化のためにDEKを返します
暗号化エージェント
DEKを使用してデータを暗号化します
ストレージ
暗号化されたデータを保存します
鍵の生成方法
KMSは、初期化ベクトル(IV)と共に、AES 256プロトコルに準拠した256ビット鍵を生成します。先に説明したとおり、初期化ベクトルは暗号化されたデータの先頭ブロックがランダムであることを保証します。このため、同じプレーンテキストであっても、初期化ベクトルにより異なる暗号文に暗号化されます。
KMSは、Javaセキュアライブラリと安全な乱数ジェネレータを使用し、これらの鍵と初期化ベクトルを生成します。
鍵の保管場所
KMSで生成されたDEKは、KEKを使用して暗号化され、これによりセキュリティレイヤーが追加されます。暗号化されたDEKは、KMSデータベースに保管されます。
鍵を物理的に分離(異なる場所に保管)するため、攻撃者は1つの鍵を入手しても他の関連鍵を入手することができません。マスター鍵を使ってKEKを暗号化し、別のサーバーに保管します。
Zoho WorkDriveでは、保存されたドキュメントに追加のセキュリティレイヤーを提供します。
攻撃者は、KMS単体を標的とするだけでは、データを侵害できません。
鍵の安全性
物理的分離- 先の説明のとおり、マスター鍵は物理的に分離された安全なサーバーに保管されます。そのため、攻撃者がDEKとKEKの両方を侵害するのは困難です。
アクセス管理- アクセス管理により、鍵の不正使用や先例のないアクセスを防止することができます。アクセス管理リスト(ACL)により、特定の鍵だけが特定のサービスにアクセスすることができます。鍵がアクセスされるときは、必ず認証を行い処理を記録します。これらの記録を定期的に監査することで、プロセスを監視することができます。
鍵管理サーバーへのアクセスはデフォルトで制限されており、Zoho社の限られた社員のみがアクセスを認められています。その他のアクセスは問い合わせのチケットとされ、管理者に承認された場合にのみアクセスが許可されます。
鍵のローテーション- より強固なセキュリティを確保するため、ルートマスター鍵を定期的に変更する、鍵のローテーションシステムを使用しています。マスター鍵と初期化ベクトルが新規に生成された場合、データベースの中の鍵も訂正が必要ということを意味します。そのため、最初にデータベースにあるすべての鍵を取得し、古いマスター鍵を使って復号化し、新しいマスター鍵を使って再び暗号化し、データベースの中で更新する処理が行われます。
発生しうる重大な状況に対処するため、手動で鍵のローテーションを実行する機能も用意しています。
鍵の可用性- 1つのデータセンターにあるディスクのプライマリストレージに障害が発生した場合は、マスターデータセンターと同じデータを保持するバックアップ用のスレーブとセカンダリスレーブがあります。マスター同様、スレーブおよびセカンダリスレーブの両方に暗号化されたDEKが存在します。
当社サービスで暗号化するデータの種類
保存時に暗号化されるデータは、選択するサービスによって異なります。特定のデータエントリーに対する暗号化のオプションとレベルは、お客さまか当社、もしくは両当事者の同意により決定されます。
以下の表に、主要なZoho サービスで暗号化されるデータを説明します。
サービス | 暗号化される項目 |
---|---|
CRM | カスタム項目、CRMを通じて送受信されたすべてのファイルとメール 詳細はこちら |
WorkDrive | すべてのファイル 詳細はこちら |
Creator | 項目 詳細はこちら |
Campaigns | 個人情報を含む項目、ユーザーがアップロードしたファイル |
Cliq | ChatTranscript(チャット内容)と個人情報 |
People | カスタム項目、すべてのファイル 詳細はこちら |
Connect | タイトル、フィードのURLとその内容、フォーラム投稿、記事、質疑応答、グループ、お知らせ、タスクとコメント、ビデオファイルと添付ファイル |
Desk | チケットスレッドコンテンツ、添付ファイルおよびトークン 詳細はこちら |
Finance | 銀行口座情報、個人情報を含むカスタム項目、個人情報を含む従業員情報、渡航書類、銀行取引明細書、添付書類 |
Projects | 添付書類、個人情報を含む項目、トークン 詳細はこちら |
Notebook | メモカードおよび添付書類 |
Sign | ドキュメント、署名画像およびトークン 詳細はこちら |
Reports | カスタム項目、ユーザーがアップロードしたファイル、カスタムクエリ |
すべてのメールコンテンツ、添付書類および個人情報を含む項目 | |
Recruit | カスタム項目、ユーザーがインポートしたドキュメント |
Social | トークン、個人情報を含む項目 |
Service Desk Plus Cloud | トークン、メールサーバーパスワードとカスタム項目 詳細はこちら |
SalesIQ | ファイル、添付ファイル、トークン、個人情報とチャットの記録 |
ディスク全体の暗号化
当社は、自己暗号化ドライブ(SED)を採用し、ハードウェアベースでディスク全体の暗号化をサポートしています。
SEDは、暗号化回路がドライブに内蔵されたハードディスクドライブ(HDD)またはソリッドステートドライブ(SSD)です。自己暗号化とは、記憶媒体に書き込まれるすべてのデータが書き込み前にディスクドライブにより暗号化され、読み込みの時はディスクドライブにより復号化されることを意味します。
SEDドライブは、FIPS 140-2準拠またはTCG準拠のドライブです。SED向けに設定された暗号化アルゴリズムは、AESアルゴリズムです。暗号化および復号化に使用される鍵の長さは256です。
SEDで使用される鍵には、データ暗号化鍵(DEK)と、認証鍵(AK)の2種類があります。
データ暗号化鍵 - ドライブ内のデータを暗号化/復号化するのに使用される鍵です。この鍵は、製造プロセスにおいてベンダーが生成します。当社がSEDドライブを搭載した新しいサーバーを入手したときは、セキュリティ上の理由から鍵を再び生成します。
認証鍵 - DEKを暗号化する鍵で、ドライブのロックとロック解除に使用されます。認証鍵は強力なポリシーで生成され、当社の鍵管理システムに保管されます。サーバーで暗号化を有効にした場合は、各サーバーに同じ鍵が安全な方法で転送されます。当社では、認証鍵の管理にローカル鍵管理(LKM)を使用しています。
注:現在、ハードウェアベースのディスク全体の暗号化は、インド(IN)とオーストラリア(AU)のデータセンターのみで採用されています。
最後に
当社は、機密性の高い顧客データの保存時、インターネット経由での転送時、当社のデータセンター間での移動時に暗号化を行います。しかし、暗号化は当社のセキュリティ戦略の一部にすぎません。当社は、最新のプロトコルと技術を導入するなど改善を続けることでデータ保護の強化に取り組んでいます。当社のセキュリティ戦略の全文は、 https://www.zoho.com/jp/security.html を確認ください。
お客さまと弊社の契約関係には、本文書の英語版が適用されます。本文書はお客さまの利便性の向上を目的として提供されており、本文書の英語版が規定する契約関係には影響を与えません。本文書の英語版については Encryption Whitepaper をご覧ください。