3つは「元に戻せるか」「鍵が要るか」で区別できる

エンコードは誰でも元に戻せます。暗号化は鍵を持つ人だけが元に戻せます。ハッシュ化は誰も元に戻せません。違いはこの2点に集約されます。3つとも「データを別の文字列に変える処理」なので、見た目は似ています。しかし目的がまったく異なります。取り違えると、守ったつもりのデータが実は誰でも読める状態になります。

項目エンコード暗号化ハッシュ化
元に戻せるか誰でも戻せる鍵があれば戻せる戻せない（一方向）
鍵不要必要不要
目的データ形式の変換内容の秘匿同一性の確認
代表例Base64、URLエンコードAES、RSASHA-256、bcrypt、Argon2

エンコード：形式を変えるだけで、秘密は守らない

エンコードは、データを別の表現形式に変える処理です。たとえばBase64は、画像などのバイナリデータを英数字と記号だけの文字列にします。メールやJSONのように文字しか扱えない場所でデータを運ぶために使われます。変換の規則は公開されているため、誰でもすぐに元へ戻せます。

Base64を暗号化と勘違いする典型例

現場でよく起きるのが、Base64の文字列を「暗号化済み」と思い込む誤解です。見た目が意味不明な文字列なので、安全に見えてしまいます。

代表例はKubernetesのSecretです。Secretの値はBase64でエンコードされて保存されますが、これは暗号化ではありません。Kubernetesの公式ドキュメントも、既定ではetcd（Kubernetesの設定保存先のデータベース）に暗号化されずに保存されると説明しています。保存時の暗号化やアクセス権限は、別途設定しなければなりません。

HTTPのBasic認証も同じです。ユーザー名とパスワードはBase64で送られるだけです。通信をHTTPSで暗号化していなければ、途中で読み取られます。設定ファイルにBase64化したパスワードを書いて「平文ではない」と扱う運用も、実質的には平文での保存と変わりません。

暗号化：鍵を持つ人だけが元に戻せる

暗号化は、鍵を使ってデータを第三者に読めない形にする処理です。同じ鍵（または対になる鍵）があれば復号、つまり元に戻せます。暗号化と復号に同じ鍵を使う方式を共通鍵暗号（AESなど）と呼びます。公開する鍵と秘密にする鍵のペアを使う方式を公開鍵暗号（RSAや楕円曲線暗号など）と呼びます。

暗号化の安全性は、アルゴリズムの強さだけでは決まりません。鍵をどこに、誰が使える状態で保管しているかに大きく左右されます。データベースを暗号化していても、鍵が同じサーバーの設定ファイルに置かれていれば、サーバーへ侵入した攻撃者は鍵も手に入れられます。暗号化を導入するときは、鍵管理サービス（KMS）やハードウェアセキュリティモジュール（HSM）での分離保管、アクセス権限、鍵の更新手順まで含めて設計します。

ハッシュ化：元に戻さずに「同じかどうか」を確かめる

ハッシュ化は、任意の長さのデータから固定長の値（ハッシュ値）を計算する処理です。同じ入力からは必ず同じ値が出ます。入力が1文字でも違えば、値は大きく変わります。ハッシュ値から元のデータを計算で復元することはできません。この性質は、元データを持たずに一致を確認したい場面で役立ちます。

パスワード保存にソルト付きのbcryptやArgon2を使う理由

ログイン時に必要なのは「入力されたパスワードが登録時と同じかどうか」だけです。元のパスワードを知る必要はありません。そのため、パスワードはハッシュ値で保存し、ログイン時の入力をハッシュ化して比較します。暗号化で保存すると、鍵が漏れた時点で全員のパスワードが復元されます。

ただし、SHA-256のような汎用ハッシュをそのまま使うのは不適切です。汎用ハッシュは高速に計算できるよう設計されています。漏えいしたハッシュ値に対して候補のパスワードを大量に試す攻撃が、短時間で進んでしまいます。また、同じパスワードからは同じハッシュ値が出るため、事前に計算した対応表で一括照合されるおそれもあります。

bcryptやArgon2（RFC 9106）はパスワード保存専用の方式です。ユーザーごとにランダムな値（ソルト）を加えて計算するため、同じパスワードでも保存される値が異なります。さらに、計算コストを意図的に高く設定できます。正規のログイン1回では気にならない負荷でも、大量の試行には大きな時間がかかります。推奨パラメータはOWASP Password Storage Cheat Sheetで確認できます。執筆時点ではArgon2idが第一候補とされています。

ファイルの改ざんチェックでハッシュ値を照合する

OSのインストールイメージやソフトウェアの配布ページには、SHA-256などのハッシュ値が掲載されていることがあります。ダウンロードしたファイルのハッシュ値を自分で計算し、掲載値と一致すれば、ファイルが途中で壊れたり差し替えられたりしていないと確認できます。計算にはLinuxならsha256sum、macOSならshasum -a 256、Windowsなら PowerShell の Get-FileHash を使います。

注意点が2つあります。1つは、MD5やSHA-1を改ざん検知に使わないことです。これらは異なるデータから同じハッシュ値を作り出す手法が知られているため、意図的な改ざんを見逃す可能性があります。もう1つは、配布サイト自体が改ざんされると、ファイルと掲載ハッシュ値の両方が差し替えられる点です。配布元が電子署名（GPG署名やコード署名）を提供していれば、署名の検証も行います。

漏えい報道の「暗号化されていた」「ハッシュ化されていた」の読み方

報道や企業の発表で「暗号化されていた」とあっても、それだけで安全とは判断できません。確認すべきは、鍵がデータと一緒に漏えいしたかどうかです。鍵が同じ環境にあり侵害された可能性があるなら、データは読まれうる前提で考えます。なお、個人情報保護法の漏えい等報告では、高度な暗号化などの措置が講じられている場合の扱いが定められています。判断の基準は個人情報保護委員会のガイドラインやQ&Aで示されているので、自社の対応を検討する際は一次情報を確認してください。

「ハッシュ化されていた」の場合は、アルゴリズムとソルトの有無が重要です。ソルトなしのMD5やSHA-1であれば、多くのパスワードが推測されうると考えます。bcryptやArgon2で適切に保存されていても、「password123」のような推測しやすいパスワードは見破られる可能性が残ります。利用者の立場では、該当サービスと、同じパスワードを使い回している他サービスのパスワードを変更するのが妥当な対応です。

自社の環境で確認すべきこと

判断の基準は「その値を手に入れた第三者が、鍵なしで元の情報にたどり着けるか」です。最初に、設定ファイル、環境変数、KubernetesのSecretなどで、Base64化しただけの認証情報を「保護済み」と扱っていないか洗い出してください。次に、自社システムのパスワード保存方式を確認します。汎用ハッシュやソルトなしの方式が残っていれば、次回ログイン時にbcryptやArgon2idへ再ハッシュする移行計画を立てます。暗号化を使っている箇所では、鍵の保管場所とアクセスできる人を棚卸しします。外部から取得するソフトウェアについては、ハッシュ値と署名の照合を導入手順に明記しておくと、担当者が替わっても確認が抜けません。