まえがき
ACCESSアドベントカレンダー2020の3日目はアドベントカレンダー初投稿な@ten_takanoが担当します．
今回はデータの保存について，セキュリティの観点を交えて私なりの考察や設定を書いていきます．データの保存と言っても「Webサービスとしてどうあるべきか」とか，「どのように顧客のデータを保護するか」というものではなく，個人のデータをどうやって機器の故障や事故から守るかというものです．
データのバックアップはどこに置くべきか？
データを機器の故障から守る方法として誰しもまず考えつくのは外付けHDDなどに保存してデータを冗長化することだと思います．これはストレージを余分に用意して定期的にコピーをするだけなので簡単にできますし，データが2箇所に保存されるのでデータが完全に失われる可能性を大きく下げることができ有効です．(データを完全にロストするためには，ストレージが同時に故障する必要があります．もちろんコピーの戦略によってはユーザーの操作ミスによって失われることもあるわけですが，それは本質的には別の話なので割愛します)
これで完璧．安心！
であれば記事を書いたりはしませんｗ
ではこの方法の問題点は何でしょうか？
タイトルが答えを言っているようなものですが，バックアップ用のストレージを同じ場所に置いておけば，災害でロストしてしまう可能性があります．火事や水害，電源の故障，etc...
これらの対策として，ここ数年でクラウドに保存するという方法が一般的になってきましたね．クラウドサービスは言うまでもなくデータを保管することに関するプロが取り扱っているので，通常は個人が対策をするよりもよっぽど安全に保管をすることができます．
そう・・・機器の故障に対しては・・・
クラウド利用の懸念点
クラウドにデータを置いてしまうと，データの漏洩リスクがつきまといます．各社心血を注いでセキュリティ対策をしているのは言うまでも無いですが，セキュリティに100％はありません．そもそもセキュリティの歴史は破られて対策してのイタチごっこなのです．GoogleやAmazonやAppleといった名だたる最先端の企業であってもそのリスクが低いだけでリスクがあることには変わりないのです．
そのため，最近では「もし万が一漏れてしまっても大丈夫」なように対策が取られつつあります．
（例：Googleドライブに暗号化サービス導入――Virtruと提携発表）
これは「End to End Encryption」と呼ばれるもので，ファイルを保存する前に暗号化しておいて取り出すときに復号するというものです．こうしておけば（暗号アルゴリズムに脆弱性が無い限り）ファイルが流出してしまっても第三者はファイルを復号できないので意味の無いファイルしか手に入らないと言うことになります．（それでもファイルサイズから何のファイルが漏れたのか何となく想像することはできるでしょうが・・・）
では本当にこれで十分なのでしょうか？
私はそうは思えません．何故かというと，クラウドサービスの提供者が攻撃者となるリスクに対してまだ対策がされていないからです．（End to Endの復号鍵を利用者だけから持っているかどうかを証明する方法はありません．オープンソースを自分でビルドしているわけではないので，復号鍵をクラウド提供者が持っている可能性はあります．というよりその可能性が高いです）
そんなことはあり得ないと笑われるかも知れませんが，あながち嘘ではありません．
例えば，Googleは保存された画像を利用者の確認無しに機械学習のデータとして利用しています（利用規約に明記されています）．他のデータについては私は聞いたことがありませんが，聞いたことがないだけでされていないとは思えませんし，むしろされていると考えるべきでしょう．（でなければGoogleが無料で膨大なストレージを提供するメリットがありません）
また，クラウドサービスは裁判所からの命令があれば利用者の許可無くデータを提供してしまいます．これはサービスを提供する側としては当然の行いですが，利用する側としてはそれによって何かしらの不利益を被ってしまう可能性があるわけです．（理想的には罪を犯さなければ不利益を被るはずがありませんが，現実問題そうでないことは多々あります）
さらに，クラウドサービス提供者が意図的に公開や利用をする以外にもリスクが存在しています．1年ほど前，Googleドライブで家族写真を児童ポルノと誤って削除してしまうという事件がありました．Googleの立場になって考えてみると，その写真が家族写真であるのか児童ポルノであるのか判別するのは非常に難しいと思います．何故なら，その写真がユーザーの身内の物である立証ができないからです．また，このようなファイルを一つ一つ手作業で吟味しているととんでもない時間がかかってしまうのでAIで自動化するのも頷けるかと思います．
しかし，これもまたユーザーの立場になって考えると，自分の大切なデータがある日突然消えてしまうわけですから，納得できる物ではありません．例えば，ある日ハードディスクが壊れてしまったのでGoogleドライブからデータを復旧しようとしたらデータの一部がAIによって自動的に削除されていたことを考えれば，少なくとも良い気分にはならないと思います．
機器の故障と政治的な対処両方からデータを守る方法
機器の故障から守るにはクラウドの利用，しかしクラウドの利用も政治的な理由から安全ではないと言うことがこれまでの説明でおわかりになったかと思います．ここからはその両方からデータを守る方法について説明していきます．
前の章でEnd to End暗号化について少し触れました．このEnd to End暗号化をすると，復号鍵を持っている人しかそのファイルを復号して利用することができない（ただし暗号化アルゴリズムに脆弱性がないことが前提）という点を思い出してください．
前節でのEnd to End暗号化はクラウド提供者が復号鍵を持っていることが問題点でした．
では，復号化の鍵をユーザーしか持っていなければどうでしょう？
サービス提供者であってもファイルを復号できないので，よくわからない0と1の羅列しか見えないわけです．このファイルをユーザー以外が復号するためには，
- 暗号化アルゴリズムの特定
- ブルートフォースアタックで解読or暗号化の脆弱性をついて解読
をする必要があるわけです．もちろん鍵長が極端に短ければブルートフォースアタックが容易に成立するわけですが，十分に長い鍵を用意しておけば大丈夫です．（ゼロデイの可能性は無視してます）
具体的には，End to End暗号化をして，暗号化されたファイルをクラウドにアップしておけば良いのです．利用する際には暗号化されたファイルをダウンロードして復号するだけなので比較的簡単に行うことができます．
End to End暗号を行うツール
私はCryptomatorというソフトを使っています．なぜこのソフトを使っているかというと，
- オープンソースである
- ファイル毎に暗号化できる
という点からです．重要なのは1点目のオープンソースである事です．（ファイル毎に暗号化できる点については，使用方法によっては特に気にしなくて良いと思います．）オープンソースである事は暗号化において何よりも重要です．何故なら，ここまでの説明で何となくわかるかと思いますが，セキュリティでは誰も信用してはいけないからです．オープンソースであれば，身の潔白を自らチェックしてもらえるよう公開されているので，問題があれば誰かが指摘しますし，それでも心配であれば自分でソースコードをチェックすることもできます．しかし，オープンでない場合は公開している団体or個人を信用するしかありません．その人がどこかに復号キーをコッソリ送信するコードを仕込んでいないことは証明できません．そこを信用してしまうのはクラウドサービスを全面的に信用してしまうのと何ら変わりません．
Cryptomatorの使い方
最後に，Cryptomatorの使い方を簡単に説明します．既にインストールは完了してある状態から説明します．
Cryptomatorを起動するとこんな画面が出てきます．Cryptomatorではドライブや特定のディレクトリに暗号化領域をマウントし，その中に保存された物を書き込みor読み込み時に自動で暗号化・復号してくれます．その領域は「金庫」と呼ばれて管理されます．上の画像は私が常用している設定が反映されていて，E:\Encryptedというディレクトリに暗号化されたファイルが書き出されています．
金庫を追加を押すと，「新しい金庫を作成」と「既存の金庫を開く」があるので，「新しい金庫を作成」をクリックします．「既存の金庫を開く」は別のマシンで復号したい時に使います．
金庫の名前を入力すると暗号化済みファイルの保存先が聞かれます．OneDriveを使うのであればOneDriveに直接送り込むことも可能です．私はとある理由からMicrosoftのwebサービスを使わないと心に決めているので適当なディレクトリを指定します．
パスワードは適切な長さで設定します．リカバリーキーはどちらでも良いと思います．私は「いいえ」を選んでいます．（リカバリーキーはとても長いランダムな文字列なので，パスワードを書き留めるのと変わらないなという判断からです）
完了すると解錠するか聞かれて，はいを押すとマウントが完了します．
マウントが完了するとディレクトリが自動で表示されるので，そこにファイルを書き込めば暗号化されています．
暗号化されたディレクトリはこんな感じになっていて，元がどんな形だったのか全く想像ができません．
ちなみに，このディレクトリ構成自体には意味があるようなので，直接暗号化済みのファイルを操作すると金庫が壊れて二度と生データを触れなくなってしまいます．
Onedriveを保存先として選んでいないのであれば，暗号化されたディレクトリのルートをGoogleドライブなりAWS S3なりに保存すれば完了です．
さいごに
個人用データにいささかやりすぎなのではないかという思われる方もいらっしゃるかとは思いますが，失われたデータは取り戻すことができません．なので，少しやり過ぎぐらいで良いのでは無いかと個人的には考えています．
私の環境ではさらに踏み込んで自動バックアップ・自動アップロードまでやっているのですが，そちらはまだ不安定なので，安定化出来たらどこかで記事にするかと思います．
明日は@illypongさんの投稿です．お楽しみに！！