個人情報と健康データを、どのように守っているのか
Do&Do. 株式会社
この記事の要点
- データの保管場所、利用者の確認、通信と保存の各段階で対策を重ねています。
- 保存場所の暗号化と、記録の内容を個別に暗号化する仕組みは役割が異なります。
- 現在の対策と追加対応を分け、ログインや決済情報の扱いも説明します。
健康の記録を預ける前に、知っておいていただきたいこと
体重や食事、運動の記録。健康づくりのために入力した情報だからこそ、「誰かに見られないだろうか」と気になる方もいると思います。
私たちDo&Do. 株式会社は、健康づくりを支えるサービス「エアトレ」の運営会社です。お預かりする個人情報や健康データを守るため、保管場所への接続制限、利用者の確認、通信や保存の方法を組み合わせて対策しています。一つの仕組みに頼らず、いくつかの段階で守る考え方です。
このコラムでは、私たちが行っている対策と、追加対応として準備している仕組みを分けてご紹介します。
データの保管場所へ、外から直接つながせない
アプリで入力した情報は、サービスの処理を経てデータベースに保存されます。データベースとは、記録を整理して保管する場所のことです。
当社のデータベースは、インターネットから直接接続できる形では公開していません。アプリの画面がインターネットにつながっていても、保管場所まで誰でも自由に入れるわけではありません。
管理作業でも、接続する人を確認する専用の経路を使っています。利用者向けの入口と、管理のための入口を分けて扱うためです。
ログインした人を、サーバー側でも確かめる
ログイン画面を設けるだけでは、情報を十分に守れません。アプリから情報を求める通信が届いたときにも、サーバー側で確認する必要があります。
エアトレでは、Firebaseの認証を利用しています。サーバーでも、ログインした利用者を示す電子的な証明を確認します。その確認を経て、情報を扱う処理へ進む仕組みです。アプリから送られた会員番号だけを、そのまま本人の証明として扱う仕組みではありません。
また、「誰がログインしたか」と「どの情報を扱えるか」は別の確認です。管理機能では、所属する企業や担当範囲などに応じてアクセスを判定する処理を設けています。
図は確認の流れを表したイメージです。左から「通信中の内容を守る」「誰からの依頼か確かめる」「扱える情報を確かめる」という、別々の確認を示しています。
App Checkは、別の角度から通信を確かめる仕組み
App Checkは、想定したアプリや端末環境からの通信かどうかを確かめるための仕組みです。本人確認を補う役割があり、不正なアクセスへの追加対策になります。
当社でも、この確認を行う仕組みを準備しています。通信の状態を記録する「監視」と、条件に合わない通信を「拒否すること」は別の段階です。現時点では、すべての機能でApp Checkによる拒否まで行っているとはご案内していません。
App Checkだけで、通信や操作のすべてが安全だと保証できるわけでもありません。ログインの確認やアクセス権の判定と組み合わせて使うものです。
通信中の情報と、保存した情報をそれぞれ守る
暗号化とは、必要な鍵を持たない人には、内容を読み取れない形に変えることです。ただし、何をどの段階で暗号化するかによって、守れる範囲は変わります。
通信中の情報を守る
アプリとサービスの間では、HTTPSによる暗号化通信を使います。その通信を保護する仕組みがTLSです。データベースへの接続にも暗号化通信を使い、情報のやり取りを保護しています。
TLSでは、接続先の証明書を確認し、通信に使う鍵を安全に共有する処理を行います。使う暗号の組み合わせは、接続先と端末が対応する方式によって決まります。後で説明する記録の暗号化は、追加で準備している保存方式についての説明です。通信のすべてで同じ暗号方式を使う、という意味ではありません。
これは、通信の途中で内容を読み取られたり、書き換えられたりするリスクを抑える対策です。端末そのものの紛失や、ログイン情報の不正利用への対策とは役割が異なります。
保存場所を暗号化する
当社が利用するGoogle CloudのCloud SQLでは、保存データが基盤側で暗号化されます。データベースを保存する媒体などを保護する仕組みです。
一方で、正当な権限でデータベースへ接続したサービスは、処理に必要な内容を読み取れます。「保存場所が暗号化されている」ことと、「データベース内の各項目が個別に暗号化されている」ことは同じではありません。
記録の内容には、どのような暗号を使うのか
ここからは、追加の対策として開発と検証を進めている仕組みをご紹介します。すべての個人情報や健康データへの本番適用、過去データの移行が完了したという意味ではありません。
保存場所の暗号化に加え、入力された回答や相談内容そのものを、アプリ側で暗号化してから保存する仕組みを準備しています。保管庫に鍵をかけることに加え、中の書類を封じるような考え方です。
左は保存場所を守る対策、右は記録の内容を個別に守る対策のイメージです。右側の追加対策は、対象ごとに実装・検証・適用を進めるもので、全データへの導入済みを示す図ではありません。
内容を隠し、書き換えられていないかも確かめる
私たちが準備している仕組みには、二つの役割があります。記録を読めない形に変えることと、書き換えられていないかを確かめることです。
記録を読めない形に変えるときと、元に戻すときには、同じ鍵を使います。このように、暗号化と復号に共通の鍵を使うものを「共通鍵暗号」と呼びます。ここでいう鍵は、利用者が覚えるパスワードではなく、プログラムがランダムに作るデータです。
使う鍵は、0と1を256個並べたデータです。候補の数は2の256乗あります。候補を一つずつ試して当てることが現実的に難しい長さです。ただし、鍵を盗まれたり、使い方を誤ったりする問題は、長さだけでは防げません。
内容を暗号化するときには、書き換えられていないかを後で確認できる情報も付けます。封筒の中身を隠すだけでなく、開封や書き換えを確かめる封印も付ける、と考えてください。この封印にあたる情報を「認証タグ」と呼びます。
復号するときに確認が合わなければ、その内容を正しい記録として返さない設計です。これは、入力した健康情報が医学的に正しいことや、本人が実際に運動したことを証明する仕組みではありません。
保存するたびに、新しい鍵と目印を用意する
この仕組みでは、回答やメッセージなど、暗号化する記録のまとまりごとに新しい鍵を作ります。すべての利用者の記録に、同じ一つの鍵を使い続ける設計ではありません。
暗号化の際には、nonceと呼ばれるランダムな目印も用意します。実装では96ビットの値です。同じ鍵と目印の組み合わせを繰り返さないことが、この方式を安全に使うための条件です。目印は秘密の鍵ではないので、暗号文と一緒に保存できます。
さらに、「誰の、何の記録か」という情報も、暗号化の確認に結び付けます。この付加情報がAADです。宛名の異なる封筒をそのまま取り替えても、正しい組み合わせとして開けられないようにする考え方です。記録の内容そのものを公開するための情報ではありません。
データを開ける鍵も、別の鍵で保護する
記録を暗号化しても、開けるための鍵をそのまま隣に置けば、十分な対策になりません。そこで採用しているのが「エンベロープ暗号化」です。エンベロープは「封筒」という意味です。
役割の違う二つの鍵を使います。記録を暗号化する鍵が「データ鍵」で、DEKとも呼びます。そのデータ鍵を保護する「親鍵」がKEKです。
- 保存する記録のために、データ鍵を新しく作ります。
- データ鍵を使って記録を暗号化し、書き換えを確認するための情報も付けます。
- データ鍵そのものも、親鍵で暗号化して保護します。
- データベースには、暗号化した記録と、保護済みのデータ鍵などを保存します。
図は上から順に見てください。青い鍵は記録を開けるための鍵です。その青い鍵も、黄色い親鍵で保護します。最後に、暗号化した記録と保護済みの青い鍵を一緒に保存し、黄色い親鍵は別に管理します。
箱の中の青い鍵は、仕組みが伝わるように透かして描いています。実際には、データ用の鍵もそのまま読める形では保存しません。追加対策として準備している設計のイメージです。
データ用の鍵を小さな封筒に入れ、その封筒にも別の鍵をかけるような仕組みです。二人の担当者が毎回一本ずつ鍵を持ち寄る、という意味ではありません。また、記録そのものを二回続けて暗号化する方式とも異なります。
親鍵は、鍵管理サービスで扱う設計
本番向けには、Google CloudのCloud KMSを使う設計です。Cloud KMSは、暗号の鍵を管理し、権限を持つサービスからの依頼に応じて暗号化や復号を行うためのサービスです。
この設計では、回答や相談の本文を丸ごとCloud KMSへ送り、暗号化してもらうわけではありません。本文はアプリ側で暗号化し、Cloud KMSにはデータ鍵の保護・取り出しを依頼します。親鍵そのものを会員データベースに置かないようにします。
記録を読むときは、まず利用者とアクセス権を確認します。そのうえで、許可されたサービスがデータ鍵を取り出し、記録を元の読める形に戻す流れです。Cloud KMSを使える権限の制限も必要です。鍵管理の設定を用意したことと、実際のサービスで稼働していることは分けて確認しています。
暗号化で守れる範囲と、別に必要な対策
この追加対策は、データベースの内容が取り出されても、鍵を使う権限がなければ記録を読み取りにくくするためのものです。一方、処理を行うサービスは、必要な場面で記録を復号します。運営側も一切読めなくなる「エンドツーエンド暗号化」とは異なります。
利用者の端末、復号した後の表示、サービスのアクセス権、バックアップなどには、それぞれの対策が必要です。暗号化した記録を丸ごと過去の状態に戻す操作まで、この仕組みだけですべて検知できるわけでもありません。
対象の保存処理を変えるだけでは、以前に保存した記録やバックアップが自動で暗号化されることもありません。私たちは、対象の確認、新しい保存への適用、過去データの移行を分けて確認しています。どの記録を、どこまで保護できているかを確かめたうえで、お伝えする方針です。
ログインや決済の情報は、役割を分けて扱う
ログインに用いるのはFirebaseなどの認証サービスです。当社の会員データベースに、ログイン用パスワードの保存欄は設けていません。
カード決済では、決済サービスを利用します。当社のデータベースにはカード番号の全桁やセキュリティコードを保存しません。決済の管理に必要な識別情報や、カードを見分けるための末尾4桁、有効期限などは扱います。
また、基本プロフィールには自宅住所の入力欄を設けていません。ただし、法人の住所や請求先住所など、別の用途で扱う情報はあります。相談文などの自由記入欄には、必要のない住所やカード番号を書かないようお願いします。
障害や誤操作への備えも行う
情報を見られないようにすることと同じく、記録を失わないための備えも大切です。
当社ではデータベースの自動バックアップを有効にし、誤ってデータベース全体を削除することを防ぐ設定も使っています。基盤の更新時には、バックアップと更新後の接続を確認しています。
バックアップがあっても、どの時点まで戻せるか、復旧にどのくらいかかるかは状況によって異なります。すべての障害で即座に元どおりになるという意味ではありません。
安心して使うために、気になることはお尋ねください
個人情報や健康データの扱いは、技術の名前を並べるだけでは伝わりにくいものです。私たちは、エアトレに情報を預けてくださる方へ、どこを守る対策なのか、どこまで対応しているのかを分けてお伝えします。
情報の扱いについて気になることがあれば、お問い合わせ窓口からご連絡ください。ログインや決済情報の扱いは、個人情報とセキュリティのページでもご案内しています。
利用者の方にも、端末の画面ロックやOS・アプリの更新をお願いします。ログイン情報や確認コードを第三者に渡さないことも、アカウントを守るために役立ちます。
参考情報
各サービスの一般的な仕組みについての資料です。当社での適用範囲は、本文の説明をご確認ください。