本文へスキップ

セキュリティ・運用

暗号化とは

あんごうか

データを鍵で変換し、鍵を保有する者だけが内容を復元できるようにする処理です。通信と保存データの区別、暗号化で防止できない被害、鍵の管理、漏えい時の報告との関係を解説します。

成熟度定番広く使われ、普通に選ばれる。
公開
2026.11.02
更新
2026.11.02
暗号化

暗号化とは

暗号化は、鍵と呼ぶ値でデータを変換し、鍵を保有しない人には判読できない形にする処理です。元の内容を平文、変換後の内容を暗号文と呼び、暗号化は平文を暗号文に変換する処理です。鍵を利用して元の内容に復元する処理を復号といいます。

たとえば顧客名簿を保存したノートPCを紛失しても、ディスク全体を暗号化して起動時の認証を設定していれば、電源の切れた状態で拾得した人は、通常は名簿を判読できません。暗号化していなければ、記憶装置を取り出して別のPCに接続すれば閲覧できることがあります。金庫で説明すると、データを金庫に保管するのが暗号化で、鍵は金庫の鍵に相当します。金庫と鍵を一緒に盗難されれば中身は保護できません。鍵を紛失した場合は、持ち主も開錠できません。

目的は、紛失、盗難、盗聴でデータが流出しても、鍵が一緒に流出していなければ内容を判読させないことです。

認証やアクセス制御は閲覧を許可する相手を決定する仕組みで、暗号化は流出した後の判読を防止する仕組みです。ハッシュ化は元の値を復元できない一方向の変換で、復号を前提とする暗号化とは異なります。

平文を鍵で暗号化すると暗号文になり、鍵で復号すると平文に復元される。流出した暗号文は鍵を保有しない人には判読できない

通信の暗号化と保存データの暗号化

暗号化はデータの所在で2種類に区分でき、防止する被害と設定する箇所が異なります。

通信の暗号化は、送受信の途中での盗聴を防止します。HTTPS(Hypertext Transfer Protocol Secure)は、ブラウザとサーバーの通信をTLS(Transport Layer Security)で暗号化します。TLSでは、通信の途中で改ざんされたデータを受信側が検出できます。社外から社内に接続するリモートアクセスのVPN(Virtual Private Network)は、社外の端末と社内ネットワークの間の通信を暗号化します。

保存データの暗号化は、媒体や複製の流出への対策です。

  • ディスク全体の暗号化: ノートPCやスマートフォンの紛失・盗難
  • データベースの暗号化: 記憶装置やデータベースの複製の流出
  • ファイルの暗号化: 記憶媒体の紛失や、復号の手段を渡していない相手への誤送信
  • バックアップの暗号化: 社外やクラウドに保管する複製の流出

通信を暗号化しても、受信側の保存の暗号化はサービスや設定によって異なるため、両者は個別に確認します。

通信の暗号化は端末とサーバーの間の双方向の送受信を保護し、保存データの暗号化は端末とサーバーに保存したディスク、ファイル、データベース、バックアップを保護する

暗号化で防止できない被害

暗号化が防止するのは、紛失・盗難した媒体や流出した複製のデータ、盗聴した通信の内容を判読される被害です。正規の手続きで復号された後のデータは保護できません。

これらには認証情報の管理と多要素認証、権限の限定、バックアップで対策します。

暗号化で防げるのは、流出したデータや盗聴した通信を判読される被害で、正規の認証情報でのログイン、起動中の端末、ランサムウェア、権限者による削除は防げません

鍵を誰が管理するか

暗号化の効果は、鍵の保管場所と保管方法に左右されます。

クラウドの標準の暗号化と自社で管理する鍵

Google Cloudは利用者の操作なしに、保存されたすべての顧客コンテンツを暗号化し、AWSのS3は2023年1月5日以降、新たに保存するすべてのオブジェクトを自動で暗号化しています。一方、AWSの仮想サーバーのディスクであるEBSは、アカウントの設定で新規のディスクの暗号化を強制する方式で、設定しなければ暗号化されないことがあります。

標準の暗号化では鍵をクラウドの事業者が管理します。自社で管理する場合は、KMS(Key Management Service)と呼ぶ鍵の管理サービスで鍵を作成し、鍵を利用できる人を設定します。AWSのS3では、自社の鍵で暗号化したデータの取得に、データへのアクセス権とは別に鍵の利用権限が必要です。共有の設定の誤りでデータを公開しても、鍵の権限がない人は復号できず、鍵の利用履歴も記録されます。

自社で鍵を管理する方式は、次のいずれかに該当する場合に採用します。

  • 業界の規制や、顧客、業界団体との契約で、自社による鍵の管理を求められている
  • 重要なデータについて、鍵の権限でもう一段の制限をかけ、利用を記録したい

鍵の権限の設定と利用状況の監視の手間は増加します。該当しないデータは、標準の暗号化を基本にします。

標準の暗号化ではアクセス権だけでデータを取得できます。AWSのS3で自社の鍵を利用すると、鍵の利用権限も必要です

鍵を喪失すると持ち主もデータを復号できない

AWSのKMSでは、削除した鍵で暗号化したデータは復号できません。削除には誤削除防止のための7日から30日の待機期間があり、その間は取り消しが可能です。利用を継続するか未定の鍵は、削除せずに無効化すれば後から再度有効にできます。

WindowsのBitLockerは、修理などで回復キーの入力を求めることがあります。回復キーを組織の管理サービスに自動で保管すれば、利用者が紛失しても復旧できます。NIST(National Institute of Standards and Technology)は保存データの暗号化について、導入前に鍵の生成から保管、復旧、破棄までを計画するよう勧めています。

漏えい時の報告と高度な暗号化

個人情報保護法では、個人データの漏えい等が、要配慮個人情報を含む場合や本人の数が1,000人を超える場合などに該当すると、個人情報保護委員会への報告が必要です。要配慮個人情報は、病歴や犯罪の経歴など取り扱いに特に配慮が必要な個人情報です。ただし、漏えい等した個人データに高度な暗号化等の秘匿化がされている場合などは、報告は不要です。規則は、高度な暗号化を、個人の権利利益を保護するために必要な措置の1つとして、報告の対象から除いています。

個人情報保護委員会のガイドラインに関するQ&AのQ6-19は、高度な暗号化の条件として次の2つを示しています。

  • 漏えい等の時点の技術水準で、第三者が判読しにくい暗号化をしている。電子政府推奨暗号リストなどに掲載された暗号技術を適切に実装することが例示されている
  • 復号の手段を適切に管理している

復号の手段の適切な管理には、同じQ&Aが挙げる次の3つのいずれかが必要です。

  • 暗号化した情報と復号鍵の分離と、鍵の漏えいの防止
  • 遠隔操作で情報または鍵を削除する機能
  • 第三者が鍵を行使できない設計

鍵をデータと同じ端末に保存していた場合は、この条件を満たさないおそれがあります。

技術水準を満たす暗号化と、3つのいずれかによる復号の手段の管理の両方を満たせば、報告は不要です

端末の紛失や漏えいが発生したときに確認する暗号化と鍵の状態

端末の紛失やデータの流出が判明したら、次の順に確認します。

  1. 流出した媒体やデータが暗号化されていたか。社用PCなら端末の管理サービスで暗号化の状態を確認する
  2. 鍵、回復キー、パスワードが一緒に流出していないか
  3. 遠隔操作で端末のデータや鍵を削除するリモートワイプができるか。端末を回収できる見込みがなく、端末内に復元が必要なデータが残っていなければ即時に実行する。削除が完了したかは、端末の管理サービスで確認する
  4. 含まれていた個人データの種類と本人の数

1から4の結果を材料に、漏えい等報告の要件とQ&AのQ6-19に基づいて報告の要否を判断し、判断できない場合は個人情報保護委員会に相談します。

紛失や流出の判明後は4つの項目を順に確認して報告の要否を検討し、リモートワイプは回収の見込みがなく復元が必要なデータがない場合に実行します

暗号化の運用の負担

  • 鍵と回復キーの保管: 利用者の異動・退職時の引き継ぎが継続的に発生する
  • Webサイトの証明書の更新: CA/Browser Forumの決定で、公開サイトの証明書の最長有効期間は2026年3月から段階的に短縮され、2029年3月には47日になる。有効期間が短くなるほど年間の更新回数が増え、手作業では更新の失念による期限切れのおそれが高まる。証明書の発行と配置を自動化する仕組みの導入と、その監視が必要になる
  • 暗号化せずに作成したデータベース: サービスによっては後から暗号化を設定できず、暗号化した複製への移行作業が必要になる

証明書の最長有効期間が2029年3月に47日まで短縮されるため、更新を自動化します

どのデータをどこまで暗号化するかの目安

  • 社外で利用するPC、スマートフォン、外部の記憶媒体: ディスク全体の暗号化を必須にし、回復キーを組織で保管する
  • Webサイト、外部サービスとの連携、社外からの接続: 通信をすべてHTTPSやVPNで暗号化し、証明書の更新を自動化する
  • 漏えい時の影響が大きい個人データを保存するデータベースとバックアップ: 保存データを暗号化し、鍵をデータと別に管理する。法令で報告の対象になる、要配慮個人情報を含むものや本人の数が1,000人を超えるものを目安にする
  • クレジットカード番号: 暗号化して保存せず、まずカード情報を保持しない非保持化にする
  • クラウドに保存するその他のデータ: 標準の暗号化を前提とし、サービスごとに有効になっているかを確認する

クレジットカード番号を保持しなければ、自社のシステムからは保存したカード情報が漏えいしません。ただし、非保持化を実現したEC加盟店でも、Webサイトの脆弱性などを原因としてカード情報を窃取される事例が発生しています。

クレジット取引セキュリティ対策協議会のガイドラインは加盟店に、カード情報を保持しない非保持化か、保持する場合はPCI DSSへの準拠を求め、EC加盟店には保持の有無にかかわらずWebサイトの脆弱性対策も求めています。PCI DSS(Payment Card Industry Data Security Standard)は、カード情報を保存、処理、伝送する事業者向けの国際的なセキュリティ基準です。

公開済みの情報や社外秘でない資料には、個別のファイル暗号化を追加しなくてよいと考えます。手間に対して保護する対象が少ないためです。

データの種類と所在で区分した5項目と、公開済みや社外秘でない資料の計6通りで暗号化の対応が分かれます

よくある誤解

暗号化とハッシュ化は同じ処理

ログインのパスワードは元の文字列を復元する必要がないため、ハッシュ化して保存します。NISTのガイドラインは、ソルトと呼ぶ値を付加してハッシュ化した形で保存するよう求めています。復号できる形では、鍵と一緒に漏えいしたときにすべてのパスワードが判読されます。

クラウドは標準で暗号化されているので権限や共有の設定は不要

標準の暗号化は事業者の記憶装置の流出などへの対策で、利用者のアカウントからのアクセスは防止しません。事業者が鍵を管理する方式では、共有の設定の誤りで公開したファイルは、その公開範囲の人に復号された状態で表示されます。権限と共有の設定の確認は、クラウドでも利用者の作業です。

社外で利用する端末のディスクと外部との通信から、優先して暗号化を導入します。同時に、鍵と回復キーの保管者と保管場所を決定しておきます。鍵を必要なときに利用できなければ、暗号化したデータは持ち主にも復元できないためです。

ほか1語をすべて見る

用語集の一覧へ

お問合せ

事業の課題や技術的な悩みなどどんなことでもお聞かせください

お問合せ