データ暗号化: 開発者が知っておくべき重要な用語

世界がますますデータドリブンになるにつれ、ユーザーデータの安全な取り扱いがこれまで以上に重要になっています。

開発者としての私たちの仕事は、すでに十分に難しいものです。人間のちらちらとした願いを UI やバックエンドに変換しながら、複数の障害点がある非常に複雑で脆弱なシステムに対処する必要があります。この課題に加えて、データ セキュリティという重要な考慮事項が新たに加わります。それには十分な理由があります。データが悪用されたら顧客である私たちは激怒しますし (したがって、ユーザーに安全で楽しいエクスペリエンスを提供するのは当然です)、政府や企業はデータのコンプライアンスを要求します。

見返りとしてのデータセキュリティ

セキュリティを難しくしているのは、セキュリティが複数の層に分かれており、誰もが責任を負うのではなく、誰の責任でもないということです。最新のクラウド チームでは、開発者、データベース管理者、システム管理者 (DevOps 担当者)、特権を持つバックオフィス ユーザーなど、複数のチームがデータの出入りを直接制御します。これらの役割/チームはすぐに目を閉じて、データ セキュリティを他人の問題として考えることがあります。それでも現実には、データベース管理者はアプリ側のセキュリティを制御できず、DevOps 担当者はバック オフィス アクセスについてはまったく何もできないなど、独自の対応が必要です。

開発者とデータセキュリティ

そうは言っても、データに関しては開発者が最も大きなアクセス領域を持っています。開発者はアプリのあらゆる部分を構築します。さまざまなバックエンド サービスに接続します。往復のフェリーアクセストークン。彼らは、自分の命令で読み取り/書き込みできるデータベース クラスター全体を持っています。彼らが作成したアプリは、システムのすべての部分に疑いなくアクセスできます (たとえば、運用中の Django アプリには、過去 10 年間の S3 コレクション全体をダンプまたはワイプするすべての権限があります) などです。その結果、セキュリティに関してずさんまたは見落としが発生する可能性が最も高いのはソース コード レベルであり、開発者の直接の責任となります。

現在、データ セキュリティは底なしのウサギの穴であり、1 回の投稿で表面をなぞることさえできません。ただし、アプリの安全性を保つために開発者が知っておく必要がある重要な用語については説明したいと思います。これを App Data Security 101 と考えてください。

始めましょう！

ハッシュ化

非常に厳密な定義が必要な場合は、いつでもWikipedia を参照してください。しかし、簡単に言えば、ハッシュとは、情報を読み取ることができない、データを別の形式に変換するプロセスです。たとえば、 Base64 エンコードのよく知られた (そして非常に安全ではない) プロセスを使用すると、「私の秘密は安全ですか?」という文字列が生成されます。 「SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/」に変換（「ハッシュ」）できます。たとえば、個人の日記を Base64 形式で書き始めた場合、家族があなたの秘密を読むことはできません (Base64 からデコードする方法を知らない限り)。

データをスクランブルするというこのアイデアは、Web アプリでパスワードやクレジット カード番号などを保存するときに使用されます (実際には、すべての種類のアプリで使用する必要があります)。もちろん、その考えは、データ侵害が発生した場合に、攻撃者が実際の損害を与えるためにパスワードやクレジット カード番号などを使用できないようにするということです。このハッシュ化の実行には、非常に堅牢で洗練されたアルゴリズムが使用されます。 Base64 のようなものは冗談であり、攻撃者によって即座に破られてしまいます。

パスワード ハッシュでは、一方向ハッシュとして知られる暗号化技術が使用されます。つまり、データをスクランブル化することは可能ですが、スクランブルを解除することは不可能です。では、アプリはログイン時にそれがパスワードであることをどのようにして認識するのでしょうか?同じプロセスを使用して、パスワードとして入力したスクランブル化された形式とデータベースに保存されているスクランブル化された形式を比較します。一致する場合は、ログインが許可されます。

ハッシュの話題ですが、興味深いことがあります。インターネットからソフトウェアやファイルをダウンロードしたことがある場合は、使用する前にファイルを検証するように指示されたことがあるかもしれません。たとえば、Ubuntu Linux ISO をダウンロードする場合、ダウンロード ページにダウンロードを確認するオプションが表示されます。それをクリックすると、ポップアップが開きます。

ポップアップは、コマンドを実行するように指示します。これは基本的に、ダウンロードしたファイル全体をハッシュし、その結果をダウンロード ページに表示されるハッシュ文字列と比較します: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 。この変換はSHA256 アルゴリズムを使用して実行されます。このアルゴリズムについては、コマンドの最後の部分 ( shasum -a 256 --checkで確認できます。

チェックによって生成されたハッシュが異なる場合、これは誰かがあなたのダウンロードに干渉し、代わりに侵害されたファイルを提供したことを意味するという考えです。

パスワード ハッシュの分野でよく知られている名前には、MD5 (安全ではなく、現在は廃止されています)、SHA-1、SHA-2 (SHA-512 と同様に SHA-256 がメンバーであるアルゴリズム ファミリ) などがあります。スクリプト、ブクリプトなど

塩漬け

あらゆる種類のセキュリティはいたちごっこです。泥棒は現在のシステムを学習し、新しい亀裂を思いつき、それが注目され、錠前メーカーはゲームを改良する、という具合です。暗号化も例外ではありません。ハッシュをパスワードに変換することは不可能になりましたが、攻撃者は時間をかけて、インテリジェントな推測と純粋な計算能力を組み合わせた高度な技術を開発してきました。その結果、ハッシュだけが与えられれば、10 回中 9 回正しいパスワードを予測できます。

その結果、塩漬けの技術が発展しました。これが意味するのは、パスワード (または任意のデータ) のハッシュ計算が、データ自体と、攻撃者が推測できない新しいランダムな文字列の 2 つの組み合わせに基づいて行われるということです。したがって、ソルティングを使用して、パスワードsuperman009をハッシュしたい場合は、まずランダムな文字列を「ソルト」として選択し、たとえばbCQC6Z2LlbAsqj77 、次にsuperman009-bCQC6Z2LlbAsqj77に対してハッシュ計算を実行します。結果として得られるハッシュは、アルゴリズムによって生成される通常の構造から逸脱し、インテリジェントなリバース エンジニアリングや推測の余地を大幅に減らします。

ハッシュとソルティングはどちらも信じられないほど複雑な領域であり、常に進化しています。したがって、アプリケーション開発者として、私たちは彼らと直接取引することはありません。しかし、これらのことを知って、より良い意思決定を行うことができれば、非常に役立ちます。たとえば、古い PHP フレームワークを管理していて、パスワードに MD5 ハッシュが使用されていることに気付いた場合は、ユーザー アカウント作成プロセスに別のパスワード ライブラリを挿入する時期が来たことがわかります。

キー

暗号化の文脈で「キー」という用語によく遭遇します。これまで、データを不可逆的に変換して元の形式を破壊するパスワード ハッシュまたは一方向暗号化について説明してきました。これは、日常的に実際に使用する場合には悪い考えです。文書を安全に作成して電子メールで送信しても、決して読み取られることはありません。したがって、送信者と受信者に情報が公開されるようにデータを暗号化する必要がありますが、転送中または保存中は読み取り不可能である必要があります。

このため、暗号化には「キー」という概念が存在します。まさにその名の通り、鍵の鍵です。情報の所有者は、キーと呼ばれる何らかの秘密を使用して情報をスクランブルします。受信者/攻撃者がこのキーを持っていない限り、アルゴリズムがどれほど高度であっても、データのスクランブルを解除することは不可能です。

回転キー

キーは暗号化を可能にし信頼性を高めますが、パスワードにはリスクが伴います。誰かがキーを知ってしまえば、すべてが終わってしまいます。誰かが GitHub などのサービスの一部を (たとえ数秒間であっても) ハッキングし、20 年前のコードを入手できるシナリオを想像してください。コード内では、会社のデータの暗号化に使用された暗号キーも見つかります (キーをソース コードと一緒に保存するという恐ろしい行為ですが、これがどれほど頻繁に行われるかに驚かれるでしょう!)。企業がキーを (パスワードと同様に) わざわざ変更していない場合、同じキーが大混乱を引き起こすために使用される可能性があります。

その結果、キーを頻繁に変更する習慣が進化しました。これはキー ローテーションと呼ばれ、信頼できるクラウド PaaS プロバイダーを使用している場合は、自動化されたサービスとして利用できるはずです。

たとえば、AWS には AWS Key Management Service (KMS)と呼ばれるこれ専用のサービスがあります。自動化されたサービスにより、すべてのサーバー間でキーを変更したり配布したりする手間が省け、大規模な導入に関しては今日では簡単に行えます。

公開鍵暗号化

暗号化とキーに関するこれまでの説明を聞いて、非常に面倒なものだと思われたのなら、その通りです。キーを安全に保管し、受信者だけがデータを確認できるようにキーを渡すと、今日の安全な通信の成功を不可能にする物流上の問題が発生します。しかし、公開キー暗号化のおかげで、私たちはオンラインで安全に通信したり、購入したりすることができます。

このタイプの暗号化は数学上の大きな進歩であり、インターネットが恐怖と不信で崩壊しない唯一の理由です。 アルゴリズムの詳細は複雑で高度に数学的であるため、ここでは概念的に説明することしかできません。

公開キー暗号化は、情報を処理するために 2 つのキーの使用に依存します。キーの 1 つは秘密キーと呼ばれ、ユーザーに対して秘密のままであり、誰とも共有されることはありません。もう 1 つは公開キー (メソッド名の由来) と呼ばれ、公開されることになっています。あなたにデータを送信する場合は、まず公開鍵を取得し、データを暗号化して送信する必要があります。最後に、秘密キーと公開キーの組み合わせを使用してデータを復号化できます。あなたが誤って秘密鍵を公開しない限り、あなただけが開ける暗号化されたデータをあなたに送信できます。

このシステムの利点は、あなたの秘密鍵を知る必要がないことです。メッセージを傍受した人は、たとえあなたの公開鍵を持っていたとしても、それを読むために何もできないことです。これがどのようにして可能なのか疑問に思っている場合、最も短く、技術的ではない答えは、素数の乗算の性質から得られます。

コンピューターにとって大きな素数を因数分解するのは困難です。したがって、元のキーが非常に大きい場合、メッセージは数千年経っても復号化できないと確信できます。

トランスポート層セキュリティ (TLS)

公開キー暗号化がどのように機能するかがわかりました。このメカニズム (受信者の公開キーを知っていて、それを使用して暗号化されたデータを送信する) が HTTPS の普及の背後にあるものであり、Chrome に「このサイトは安全です」と認識させる原因となっています。何が起こっているかというと、サーバーとブラウザーが互いの公開キーを使用して HTTP トラフィック (Web ページはブラウザーが解釈できる非常に長いテキスト文字列であることを思い出してください) を暗号化し、その結果、セキュア HTTP (HTTPS) が実現されます。

画像クレジット: Mozilla 興味深いのは、暗号化がトランスポート層自体では行われないということです。 OSI モデルはデータの暗号化については何も述べていません。データはトランスポート層に渡される前にアプリケーション (この場合はブラウザー) によって暗号化され、その後トランスポート層で宛先にドロップされ、そこで復号化されます。ただし、このプロセスにはトランスポート層が関与しており、最終的にはデータの安全な転送が行われるため、「トランスポート」層セキュリティという漠然とした用語が定着しています。

場合によっては、Secure Socket Layer (SSL) という用語に遭遇することもあります。これは TLS と同じ概念ですが、SSL はずっと前に誕生し、現在は TLS に代わって廃止されています。

フルディスク暗号化

場合によっては、セキュリティのニーズが非常に高く、何も任せることはできません。たとえば、国のすべての生体認証データが保存されている政府サーバーは、リスクが高すぎるため、通常のアプリケーション サーバーのようにプロビジョニングして実行することはできません。データを転送時にのみ暗号化するだけでは、このようなニーズには十分ではありません。保存時も暗号化する必要があります。このため、フルディスク暗号化を使用してハードディスク全体を暗号化し、物理的に侵害された場合でもデータの安全性を確保します。

フルディスク暗号化はハードウェア レベルで実行する必要があることに注意することが重要です。これは、ディスク全体を暗号化すると、オペレーティング システムも暗号化され、マシンの起動時に実行できなくなるためです。したがって、ハードウェアはディスクの内容が暗号化されていることを理解し、要求されたディスク ブロックをオペレーティング システムに渡すときにオンザフライで復号化を実行する必要があります。この余分な作業が行われるため、フルディスク暗号化では読み取り/書き込みが遅くなり、そのようなシステムの開発者はこの点に留意する必要があります。

エンドツーエンドの暗号化

昨今、大規模なソーシャル ネットワークではプライバシーとセキュリティの悪夢が続いているため、アプリの作成や保守に関係がない場合でも、「エンドツーエンド暗号化」という用語を知らない人はいません。

先ほど、フルディスク暗号化が究極の防弾戦略を提供する方法を説明しましたが、日常のユーザーにとっては便利ではありません。つまり、Facebook が生成して携帯電話に保存する電話データの安全性を望んでいるが、携帯電話全体を暗号化し、その過程で他のすべてをロックアウトすることにアクセスすることはできないと想像してください。

このため、これらの企業はエンドツーエンドの暗号化を開始しました。これは、データがアプリによって作成、保存、または転送されるときに暗号化されることを意味します。言い換えれば、データが受信者に届いたとしても、データは完全に暗号化されており、受信者の電話機からのみアクセスできます。

エンドツーエンド (E2E) 暗号化には、公開キー暗号化のような数学的保証がないことに注意してください。これは、キーが企業とともに保存される標準的な暗号化であり、メッセージは企業の判断どおりに安全です。

結論👩‍🏫

これらの用語のほとんどはすでに聞いたことがあるでしょう。もしかしたら全部かも知れません。もしそうなら、これらの概念についての理解を再確認し、それらをどの程度真剣に受け止めているかを評価することをお勧めします。アプリ データのセキュリティは、(一度だけではなく) 毎回勝利する必要がある戦争であることを忘れないでください。たった 1 回の侵害でも、業界全体、キャリア、さらには生命を破壊するのに十分であるためです。