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

公開: 2021-09-27

世界がますますデータ主導になるにつれて、ユーザーデータの安全な処理がこれまで以上に重要になっています。

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

バックス・ザ・バックとしてのデータセキュリティ

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

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

とはいえ、開発者はデータに関して最大のアクセス領域を持っています。アプリのすべての部分を構築します。さまざまなバックエンドサービスに接続します。フェリーアクセストークンを前後に。コマンドで読み取り/書き込みを行うデータベースクラスター全体があります。彼らが作成したアプリは、システムのすべての部分に問題なくアクセスできます（たとえば、本番環境のDjangoアプリには、過去10年間のS3コレクション全体をダンプまたはワイプするすべての権限があります）。その結果、セキュリティの観点から見落としや見落としが発生する可能性が最も高いのはソースコードレベルであり、開発者の直接の責任です。

さて、データセキュリティは底なしのうさぎの穴であり、1つの投稿で表面を傷つけることさえできない方法があります。ただし、アプリを安全に保つために開発者が知っておく必要のある重要な用語について説明したいと思います。 App Data Security101と考えてください。

始めましょう！

ハッシュ

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

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

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

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

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

小切手で生成されたハッシュが異なる場合、これは誰かがあなたのダウンロードに干渉し、代わりに侵害されたファイルを提供したことを意味します。

パスワードハッシュのドメインでよく耳にする名前には、MD5（安全ではなく、現在は機能していない）、SHA-1、SHA-2（SHA-256とSHA-512がメンバーであるアルゴリズムのファミリ）があります。 SCRYPT、BCRYPTなど。

塩漬け

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

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

ハッシュとソルティングはどちらも非常に複雑なドメインであり、絶えず進化しています。したがって、アプリケーション開発者として、私たちはそれらに直接対処することは決してありません。しかし、私たちがこれらを知っていて、より良い決定を下すことができれば、それは私たちに大いに役立ちます。たとえば、古いPHPフレームワークを維持していて、パスワードにMD5ハッシュを使用していることがわかった場合は、ユーザーアカウントの作成プロセスに別のパスワードライブラリを挿入する必要があります。

キー

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

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

回転キー

キーは暗号化を可能にし、信頼性を高めますが、パスワードが持つリスクを伴います。誰かがキーを知ったら、ゲーム全体が終了します。誰かがGitHubのようなサービスの一部をハッキングして（たとえ数秒であっても）、20年前のコードを入手できるシナリオを想像してみてください。コードの中には、会社のデータを暗号化するために使用される暗号化キーもあります（ソースコードと一緒にキーを保存するという恐ろしい慣習ですが、これが頻繁に発生することに驚かれることでしょう！）。会社が（パスワードのように）キーを変更する必要がない場合は、同じキーを使用して大混乱を引き起こす可能性があります。

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

たとえば、AWSには、AWS Key Management Service（KMS）と呼ばれる専用のサービスがあります。自動化されたサービスにより、すべてのサーバー間でキーを変更して配布する手間が省け、大規模な展開に関しては、最近は簡単です。

公開鍵暗号

暗号化とキーについてのこれまでのすべての話で、それが非常に面倒だと思われる場合は、その通りです。キーを安全に保ち、受信者だけがデータを確認できるようにキーを渡すと、今日の安全な通信を成功させることができなかったロジスティックの問題が発生します。しかし、公開鍵暗号のおかげで、オンラインで安全に通信したり購入したりできます。

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

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

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

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

トランスポート層セキュリティ（TLS）

これで、公開鍵暗号がどのように機能するかがわかりました。このメカニズム（受信者の公開鍵を認識し、それを使用して暗号化されたデータを送信する）は、すべてのHTTPSの人気の背後にあり、Chromeに「このサイトは安全です」と言わせる原因です。何が起こっているのかというと、サーバーとブラウザーが相互の公開鍵を使用してHTTPトラフィック（Webページはブラウザーが解釈できる非常に長いテキスト文字列であることに注意してください）を暗号化しているため、Secure HTTP（HTTPS）が生成されます。

画像クレジット：Mozillaトランスポート層自体では暗号化が行われないことに注意してください。 OSIモデルは、データの暗号化については何も述べていません。データがトランスポート層に渡される前に、アプリケーション（この場合はブラウザー）によって暗号化されるだけです。トランスポート層は、後でデータを宛先にドロップし、そこで復号化されます。ただし、このプロセスにはトランスポート層が含まれ、結局のところ、データの安全な転送がすべて行われるため、「トランスポート」層のセキュリティという緩い用語が定着しています。

場合によっては、Secure Socket Layer（SSL）という用語に出くわすこともあります。これはTLSと同じ概念ですが、SSLはかなり前に作成され、現在はTLSを優先して廃止されている点が異なります。

フルディスク暗号化

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

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

エンドツーエンド暗号化

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

フルディスク暗号化が究極の防弾戦略を提供する方法を以前に見ましたが、日常のユーザーにとっては便利ではありません。つまり、Facebookは、生成して電話に保存する電話データを安全にしたいと考えていますが、電話全体を暗号化し、その過程で他のすべてをロックアウトすることはできません。

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

エンドツーエンド（E2E）暗号化は、公開鍵暗号化のように数学的な保証がないことに注意してください。これは、キーがビジネスとともに保存される標準的な暗号化であり、メッセージはビジネスが決定するのと同じくらい安全です。

結論

これらの用語のほとんどはすでに聞いたことがあるでしょう。多分それらのすべて。もしそうなら、これらの概念の理解を再検討し、それらをどれだけ真剣に受け止めているかを評価することをお勧めします。アプリのデータセキュリティは、業界全体、キャリア、さらには生命さえも破壊するのに1回の違反でも十分であるため、毎回（1回だけではなく）勝つ必要がある戦争であることを忘れないでください。