保存データのセキュリティのタイトルバナー。データベースを盾で囲み鍵を重ねたモチーフと、レイヤ・鍵・バックアップ・アクセス制御の4アイコンで、保存データの守りが複数判断の重なりであることを示す。

この記事の要点

  1. 核心: 保存データの守りは「ディスクを暗号化すれば安全」という一枚岩ではありません。どのレイヤで暗号化するか・鍵をどこに置くか・バックアップをどう守るか・誰にアクセスを許すか、という複数の判断が重なってできています。手段の名前を覚えるのではなく「どの脅威に・何で備えるか」で捉えると、自分の構成のどこに穴があるかに気づけます。
  2. 対象読者: クラウドの (データベース)や (Software as a Service。ネット経由で使うソフトのサービス)に自社・客先のデータを置く前に、保存時のセキュリティを点検・設計する立場になった企業の実務担当(製造業 IT 部門など、セキュリティ専任ではない方)を想定しています。前提知識は不要です。
  3. 得られる成果: ①どのレイヤ(アプリ / DB / ディスク)で暗号化すべきか選べる ②暗号鍵をコードに直書きせず、どこに置くか(環境変数 → KMS → エンベロープ暗号化)の次の一手を選べる ③バックアップを暗号化し、復元テストまで運用に落とせる、の 3 点を持ち帰れます。
  4. 扱わないこと(専門家・公式情報、または別の記事へ): 転送時の暗号化は 通信の守り方 へ / 認証・認可そのものの詳細は 認証と認可の基礎 へ / 個人情報保護法の逐条解説 / 各クラウド製品の優劣比較や、個別環境の設計・監査の代替。

Key Points (for international readers)

  1. Core — Protecting data at rest is not a single switch. It is several decisions layered together: which layer you encrypt at, where you keep the keys, how you protect backups, and who is allowed to read the data. Reading it by "which threat, defended by what" — rather than memorizing tool names — shows you where the gaps in your own setup are.
  2. Who this is for — practitioners who place company or client data into a managed database or SaaS and need to review or design at-rest security, without being security specialists (e.g., manufacturing IT). No prior knowledge required.
  3. Portable takeaway — the layer model (application / database-TDE / disk), envelope encryption and key ownership, and "encrypt backups and test the restore" hold regardless of jurisdiction. Where regions diverge is the regulatory driver: this Japanese edition leans on Japan's context, while the English edition frames the same decisions against US drivers (state breach-notification laws, HIPAA/PCI-DSS) and the EU's GDPR Art. 32. Read it against your own region.
  4. What's out of scope (a specialist, the official docs, or the related pieces) — encryption in transit (see communication security) / the details of authentication and authorization (see auth basics) / clause-by-clause legal reading / vendor product comparisons or audits of a specific environment.

執筆時点: 2026-06 / 対象: 技術は法域に中立・規制の文脈のみ日本国内向け / last_updated: 2026-06-27 更新履歴: 2026-06-27 初版公開

本記事は教材であり、特定環境の設計助言ではない

本記事は 保存データのセキュリティを地図として整理するための一般的な解説 であり、特定のシステム・組織に対する設計助言やセキュリティ監査の代替ではありません。内容の正確性・完全性・最新性を保証するものではなく、製品名・サービス名・規格・規制は改称や改正で変わります。とくにクラウドの鍵管理サービス(KMS)の名称・画面・手順は更新されやすいため、実際の設計・実装・調達の判断は、必ず 社内のセキュリティ / インフラ部門・専門家・各製品の公式ドキュメント・一次情報 にご確認ください。本記事の情報は「現状有姿(AS IS)」で提供され、これを利用または信頼した結果生じたいかなる損害・損失についても、執筆者および YATA-NODE は一切の責任を負いません。ご利用は自己責任でお願いします。

本シリーズの位置づけ: 本記事は「仕組みを理解するシリーズ」の保存データ編です。通信の守り方 が「やり取りの最中(転送時)をどう守るか」を扱ったのに対し、本記事は「置いてあるデータ(保存時)をどう守るか」を 1 本で俯瞰します。転送時と保存時は守備範囲が対になっており、両方そろって初めて穴がふさがります。アクセス権限の設計が気になる場合は 認証と認可の基礎 も参照してください。

用語ミニ解説(はじめての方へ): 本記事で繰り返し出る言葉の最小限の説明です。

  • 保存時 / 転送時(at rest / in transit): 保存時はディスクや DB に「置いてある」状態、転送時は通信で「動いている」状態。守る手段が別なので分けて考えます。
  • (Transparent Data Encryption。透過的データ暗号化。DB が保存ファイルを自動で暗号化し、アプリ側はコード変更なしで使える仕組み)。
  • (Key Management Service。暗号鍵を安全に保管・払い出し・監査するマネージドサービス。(Amazon Web Services)KMS / Azure Key Vault / Google Cloud KMS など)。
  • エンベロープ暗号化(envelope encryption): データを暗号化する鍵を、さらに別の鍵で暗号化して守る入れ子の方式。鍵そのものを平文で置かずに済みます。
  • (Full-Disk Encryption。ディスク全体を暗号化し、盗難・紛失時もデータを読めなくする)。
  • (Hardware Security Module。鍵の生成・保管を専用ハードウェアで行い、鍵を外に取り出させない装置)。

「データは暗号化しておくべき」とはよく聞きますが、いざ自分のシステムで手を動かそうとすると、どこに・何で暗号化を掛ければよいのか迷います。クラウドの DB や SaaS に自社や客先のデータを置く前にセキュリティを点検する立場の方ほど、この迷いは切実です。本記事は専門用語を噛み砕き、「どの脅威に・何で備えるか」という 1 つの見方に揃えて保存データの守りを地図にします。まず①保存時と転送時の守備範囲を切り分け、②暗号化のレイヤを選び、③鍵の置き場所を決め、④バックアップを守り、⑤アクセスを絞る、と順にたどります。読み終えると、暗記ではなく「何から手を付けるか」を自分で判断できる土台ができます。

保存時と転送時 ― 暗号化の守備範囲を整理する

最初につまずきやすいのが、「通信を HTTPS にしているから、データはもう安全では?」という思い込みです。HTTPS が守るのは、ブラウザとサーバーの間を データが流れている最中(転送時、in transit)だけです。データがサーバーに届いてディスクや DB に書き込まれ、置いてある状態(保存時、at rest)になった後は、別の守りが必要になります。転送時の暗号化は「運んでいる荷物に封をする」、保存時の暗号化は「届いた荷物を金庫にしまう」イメージです。封がしっかりしていても、金庫がなければ届いた先で中身を見られます。

この 2 つは守る脅威が違います。転送時の暗号化(〔Transport Layer Security〕。https:// を支える仕組み)は、経路上での盗聴や改ざんを防ぎます。保存時の暗号化は、ディスクや記憶媒体の盗難・紛失、サーバーに侵入してディスクや DB ファイルを丸ごと持ち出す行為、バックアップ媒体の流出といった、媒体やファイルごとデータを持ち出される脅威を防ぎます(どのレイヤの暗号化がどの脅威まで防ぐかには差があり、次の節の表で整理します)。逆に、正規のログインや DB 接続権限を奪って中身を読み取る侵入は、暗号化だけでは防げません(これは後述⑤のアクセス制御で締めます)。どちらか一方では穴が残るため、両方そろえるのが基本です。転送時の詳しい仕組みは 通信の守り方 に譲り、本記事は保存時に集中します。

なお、ネットワークをファイアウォールやゼロトラストで固めることと、保存データを暗号化することも別の話です。ネットワーク境界は「誰を中に入れるか」を制御しますが、いったん中に入った権限者や、媒体ごと持ち出された場合までは守りません。境界の設計が気になる場合は 企業ネットワークの仕組み もあわせてご覧ください。本記事は、境界をすり抜けられても なおデータ自体を守る最後の層 として保存時セキュリティを扱います。

どのレイヤで暗号化するか ― アプリ・DB(TDE)・ディスクの選び方

保存時の暗号化は、掛ける場所(レイヤ)が代表的に 3 つあります。下から順に、ディスク全体を暗号化する FDE、DB が保存ファイルを自動で暗号化する TDE、アプリが特定のデータ項目(カラム)だけを暗号化してから保存する アプリ層暗号化 です。多くの入門記事はこの 3 つを「種類」として並べて終わりますが、本当に知りたいのは「自分はどれを選ぶべきか」です。選ぶ鍵は、各レイヤが どの脅威を防ぎ、どの脅威には無力か を知ることです。

暗号化レイヤの深さの図。下からディスク全体(FDE=ディスク・媒体の盗難を防ぐ)/データベース(TDE=稼働中サーバーの DB ファイル奪取も防ぐ)/アプリ層(カラム=DB 管理者にも暗号文しか見えない)の3バンドを、広く浅い→狭く深いの深さ軸で示す。
暗号化のレイヤディスク・媒体の盗難 / 紛失稼働中サーバーからの DB ファイル奪取DB 接続権限の悪用(内部の直接 SQL)アプリの脆弱性経由の流出
ディスク全体(FDE)○×(稼働中は復号済み)××
DB(TDE)○○××
アプリ層(カラム暗号化)○○○(暗号化した項目のみ)△

※ この表は「暗号鍵そのものや、稼働中サーバーの実行権限までは奪われていない」ことを前提にした整理です。鍵やルート権限ごと奪われれば、どの層も突破され得ます。各レイヤの防御範囲は、AWS / Microsoft の公式の保存データ暗号化ドキュメント(References 参照)を踏まえ、筆者が脅威別に再構成した概念モデルであり、特定製品の保証ではありません。

表の見方はシンプルです。下のレイヤほど 掛けるのが簡単で守備範囲は広いが浅く、上のレイヤほど 手間はかかるが深い脅威まで届きます。FDE はディスクごと盗まれたときには有効ですが、サーバーが動いている間はディスクが復号された状態なので、侵入されてファイルをコピーされると無力です。TDE は保存ファイルが暗号化されたままなので、サーバーが稼働中でも DB ファイルを持ち出されたデータは読めません。ただし TDE には落とし穴があります。正規の DB 接続権限を持つ相手(権限を奪われた内部アカウントや、SQL を直接叩ける攻撃者)には、DB が復号して結果を返すため無力です。「TDE を有効にしたから安全」という誤解は、ここで生まれます。

最も深いところまで届くのが アプリ層暗号化 です。アプリが保存前に暗号化するので、DB 管理者や DB に直接つなげる相手にも、その項目は暗号文にしか見えません。代わりに、暗号化する項目を自分で選ぶ手間と、アプリ自身が鍵を持つため アプリが乗っ取られると突破される という限界があります。なお、これは鍵を DB の外に分離して持つ実装が前提です。鍵を DB 内に置いたり、DB 側の復号関数に鍵を渡す実装では、DB 接続権限から鍵や平文に届くため、この利点は失われます。

選び方の目安はこうです。まず土台として FDE か TDE のどちらか(クラウドのマネージド DB なら既定で有効なことも多い)を効かせ、ディスク盗難と DB ファイル奪取に備えます。そのうえで、個人情報・認証情報・決済情報のような とくに見られたくない項目だけ をアプリ層暗号化で重ねます。全カラムをアプリ層で暗号化すると検索や運用が一気に重くなるため、守る対象を絞るのが実務的です。「広く浅く」を下のレイヤで、「狭く深く」を上のレイヤで、と覚えると迷いません。

暗号鍵をどこに置くか ― ハードコード回避から KMS・エンベロープまで

暗号化はそれ自体より、鍵をどう守るかで強さが決まります。金庫が頑丈でも、鍵を扉に貼っておけば意味がないのと同じです。そして最もよくある事故が、鍵や接続パスワードをコードに直書き(ハードコード)し、それをそのまま git にコミットして公開してしまうことです。鍵の管理は、規模に応じて段階的に引き上げるのが現実的です。

第 1 段(まず誰でもやる)。鍵や秘密情報を コードに書かないようにします。環境変数に逃がし、値を書いた .env ファイルは .gitignore で追跡対象から外し、リポジトリには値を伏せた .env.example(キー名だけのひな形)を置いてチームで共有します。これだけで、最もよくある「鍵を git に上げてしまう」事故を大きく減らせます。

第 2 段(チームや本番が見えてきたら)。環境変数は手軽ですが、誰が・いつ鍵にアクセスしたかの記録や、鍵の差し替えには向きません。そこで KMS(クラウドの鍵管理サービス)に鍵を預け、アプリは自分の権限(IAM など)で必要なときだけ、KMS に暗号化・復号やデータ鍵の払い出しを依頼する形にします(マスター鍵そのものは KMS / HSM の中から取り出しません)。鍵そのものをアプリの設定ファイルに平文で置かずに済み、アクセス記録も残ります。

エンベロープ暗号化の入れ子図。KMS / HSM(マスター鍵は平文で外に出さない)の中に KEK(マスター鍵)、その中に DEK(データ鍵)、最内にデータを置き、脇に『一緒に保存:暗号化データ + 暗号化した DEK』のタグを示す。

第 3 段(鍵をきれいに回したくなったら)。ここで エンベロープ暗号化 が効きます。仕組みは入れ子です。まずデータを データ暗号鍵(DEK、Data Encryption Key)で暗号化し、その DEK を さらに上位の 鍵暗号鍵(KEK、Key Encryption Key。KMS が握るマスター鍵)で暗号化して、暗号化済みの DEK だけをデータの隣に保存します。こうすると、平文の鍵をディスク上(設定ファイルやデータの隣)に裸で置かずに済みます。復号のときだけ一時的に鍵を使い、上位の KEK は KMS / HSM の中から平文では取り出しません(裸の鍵を永続保存しない、という意味です)。鍵の定期的な差し替え(ローテーション)も楽になります。上位の KEK を交換し、暗号化済み DEK を新しい KEK で再ラップ(re-wrap)するだけで済み、DEK 自体やデータ本体は再暗号化せずに鍵を回せるからです。ただしこの再ラップは設計・運用側が行う操作です。クラウドの鍵管理サービス(KMS)の「自動ローテーション」は新しい鍵を用意するだけで、既存のデータや暗号化済み DEK を自動で再暗号化・再ラップするわけではありません(過去のデータは古い鍵で復号され続けます)。

鍵を誰が握るかも論点です。多くの KMS は、プロバイダが管理する鍵のほか、自分で用意した鍵を持ち込む方式(BYOK、Bring Your Own Key)を選べます。規制対応やデータの所在地が気になる場合の選択肢になりますが、鍵を自分で管理する責任も増えます。まずはマネージドな鍵で運用を固め、必要が出てから持ち込み鍵を検討する、で十分です。なお具体的なサービス名・画面・手順はクラウド各社で更新されやすいため、実装時は各社の公式ドキュメントで最新を確認してください。

バックアップも暗号化する ― 復元テストまでがセット

見落とされがちなのがバックアップです。本番の DB は暗号化していても、その バックアップが平文のまま別のストレージに置かれていれば、守りはそこから崩れます。攻撃者にとっては、固い本番より、ゆるいバックアップを狙うほうが楽だからです。スナップショット、ダンプ、定期エクスポート、外部ストレージへの転送先まで、本番と同じ基準で暗号化の対象に含めてください。

置き場所の目安として広く知られているのが「3-2-1」の考え方です。データを(原本を含め)3 つ持ち、2 種類の異なる媒体に保存し、そのうち 1 つは別の場所(オフサイト)に置く、というものです。1 か所の障害やランサムウェアで全滅しないための分散です。本記事の主題に引きつければ、この複製のどれもが暗号化されていること、が前提になります。

そして、暗号化したバックアップで最も大切なのが 復元テスト です。暗号化されたバックアップは、復号できなければ ただの読めないファイルです。鍵を失えば、自分でも二度と戻せません。バックアップは「取れていること」ではなく「戻せること」がゴールなので、定期的に 実際に復元してみる 手順までを運用に含めます。あわせて、バックアップを復号する鍵を、バックアップ本体と同じ場所に置かない(鍵を失っても、バックアップを盗まれても破綻しないよう分けておく)ことも確認しておきましょう。

誰に何を見せないか ― 保存データのアクセス制御

暗号化は「媒体やファイルを持ち出されても読めない」ための層でした。しかし、正規のログインや正規の DB 接続から 中身を見られることは、暗号化では防げません。ここを締めるのがアクセス制御で、暗号化を補完する最後のピースです。

基本は 最小権限です。アプリやスタッフが使う DB アカウントに、必要な範囲だけを与えます。参照しかしないアカウントは読み取り専用に、特定の業務しか触らないなら対象のテーブルだけに絞る、といった具合です。さらに、同じテーブルでも 行や列の単位で見える範囲を制限する 仕組み(行レベルセキュリティ、RLS〔Row Level Security〕など)を使えば、「自分が担当する取引先の行だけ見える」といった制御もできます。

見落としやすいのが、正規機能からの漏れ です。管理画面の一覧、CSV エクスポート、エラー時のログやスタックトレースに個人情報がそのまま出ていないかを確認します。暗号化したカラムを、管理者だけは平文で読めてしまう設計になっていないかも見直しましょう。こうした「誰に何を見せるか」の線引きは、認証・認可の設計そのものです。深掘りは 認証と認可の基礎 に譲りますが、保存データの守りは アクセス制御まで含めて初めて閉じる、と覚えておいてください。

まとめ

保存データの守りは、ひとつの設定で完結するものではなく、5 つの判断が重なってできています。①保存時と転送時の守備範囲を切り分け、②どのレイヤ(アプリ / DB / ディスク)で暗号化するかを脅威に応じて選び、③鍵をコードに直書きせず段階的に KMS・エンベロープへ引き上げ、④バックアップも暗号化して復元テストまで回し、⑤アクセス制御で正規経路からの漏れを締める。この地図を持っていれば、新しい製品名や手法に出会っても「これはどの層の話か」と位置づけられます。

最後に、いま自分の構成を点検するための確認リストを置きます。コピーして、それぞれ説明できるか・できているかを確かめてみてください。

text
【保存データの守り 確認リスト】
□ 転送時(TLS)だけでなく、保存時も暗号化しているか
□ どのレイヤ(アプリ / DB / ディスク)で暗号化しているか説明できるか
□ TDE だけに頼り、内部の DB 接続権限からの閲覧を見落としていないか
□ とくに見られたくない項目(個人情報・認証情報など)をアプリ層で重ねているか
□ 暗号鍵や接続情報をコードに直書きしていないか(.env は .gitignore 済みか)
□ 鍵を KMS など管理された場所に預け、平文で設定ファイルに置いていないか
□ 本番だけでなく、バックアップも暗号化されているか
□ 暗号化したバックアップを、実際に復元してみたことがあるか
□ DB アカウントは最小権限か。エクスポートやログから個人情報が漏れていないか

ひとつでも「説明できない / できていない」があれば、そこが次に手を付ける場所です。すべてを一度に完璧にする必要はありません。土台の暗号化から始め、鍵の管理、バックアップ、アクセス制御へと、一段ずつ穴をふさいでいきましょう。

References

公的・一次情報(本文の技術的な整理の裏付け。製品名・手順は更新されるため、利用前に各公式で最新をご確認ください):