データ保護と暗号化の基本

クラウドでは、データをストレージへ保存し、アプリケーションやAWSサービス、利用者の端末との間で通信します。データの機密性を保つには、ストレージに置かれている間とネットワークを移動している間の両方を保護する必要があります。暗号化はそのための重要な手段ですが、アクセス制御や鍵管理、通信相手の検証を置き換えるものではありません。

本ページでは暗号化の基本原理と代表的な方式を整理します。S3・RDSなどのサービスごとの具体的な暗号化オプションやKMSの詳細な運用は、それぞれのサービス要件に沿って別途設計します。

保存時と転送時の暗号化

保存時暗号化（encryption at rest）

**保存時のデータ（data at rest）**は、ディスク、オブジェクトストレージ、データベース、バックアップ、アーカイブなど、永続ストレージに保持されているデータを指します。保存時暗号化では、ストレージ上のデータを暗号化し、ストレージ媒体やバックアップへの不正なアクセスだけでは内容を読めない状態にします。

AWSのストレージやデータベースサービスでは、サービス側で暗号化を実行する方式や、アプリケーション側で保存前に暗号化する方式などを選べます。方式によって、暗号化が行われる場所、鍵を管理する主体、運用者が平文にアクセスできる範囲が異なります。利用するサービスが提供する保存時暗号化の設定、鍵へのアクセス許可、バックアップやスナップショットへの適用範囲を確認してください。

保存時暗号化は、データベースの認可やIAMポリシーを不要にはしません。正規のアプリケーションや権限を持つ主体が復号を許可されていれば、保存データを読み取れることがあります。暗号化に加え、誰がデータや鍵を利用できるかを制限し、鍵の使用を監査する必要があります。

転送時暗号化（encryption in transit）

**転送中のデータ（data in transit）**は、クライアントとアプリケーション、AWSサービス間、VPC間、AWSとオンプレミス環境間など、ネットワーク上を移動しているデータです。転送時暗号化では、通信経路上で第三者に内容を読まれたり、改ざんされたりするリスクを低減します。

Web通信やAPI接続ではTLSを使ったHTTPSが一般的です。TLSは通信内容を暗号化するだけでなく、証明書などを使って接続先サーバーの身元を検証し、通信内容の完全性も保護します。構成によってはクライアント証明書を用いる相互TLSで、クライアント側の身元も確認します。TLSを利用する場合は、証明書の検証を無効にしないこと、古いプロトコルや弱い暗号スイートを避けること、証明書の有効期限・更新を管理することが重要です。

転送時暗号化を有効にしても、通信相手が正しいことを確認しなければ、中間者攻撃などに対して十分な保護になりません。また、通信の両端のアプリケーションや端末でデータが平文として処理される場合があります。TLSはネットワーク区間を保護するもので、エンドポイント上のアクセス制御や保存時暗号化まで自動的に提供するものではありません。

二つの保護を組み合わせる

保存時暗号化と転送時暗号化は異なる状況に対応します。たとえば、暗号化済みストレージにデータを保管していても、HTTPなど暗号化されていない経路で送信すれば、その転送経路で内容を読まれる可能性があります。反対に、TLSで安全にデータベースへ送信しても、保存先のストレージやバックアップが暗号化されていなければ、媒体への不正アクセスに対する保護は別途必要です。

観点	保存時暗号化	転送時暗号化
保護する状態	永続ストレージに保存されているデータ	ネットワークを通過しているデータ
代表的な手段	ストレージ／データベースの暗号化、アプリケーション側暗号化	TLS、HTTPS、必要に応じた相互TLS
主な検討事項	鍵の管理とアクセス許可、バックアップへの適用、復号できる主体	証明書検証、TLS設定、通信相手の認証、証明書更新
それだけでは解決しない問題	アプリケーション認可や正規権限による読み出し	保存先の保護、端末・サーバー内の平文データ管理

平文・暗号文・鍵・アルゴリズム

暗号化は、読み取り可能な元データを平文（plaintext）、暗号化によって変換されたデータを**暗号文（ciphertext）**として扱い、暗号鍵と暗号アルゴリズムを使って平文から暗号文を生成する処理です。権限のある主体は対応する鍵と復号アルゴリズムを用い、暗号文から元の平文を取り戻します。

暗号文は見た目が判読できないデータになりますが、単に文字列を別の文字列に置き換えることが安全性を生むわけではありません。現代の暗号では、暗号アルゴリズムの詳細が知られていても、適切な鍵がなければ内容を現実的な時間で復元できないことが前提です。秘密にすべき中心は鍵であり、鍵の生成・配布・保存・利用許可・ローテーション・失効・バックアップといったライフサイクルを管理します。

暗号化と復号の両方ができる変換は可逆です。ただし、鍵を失えば暗号化データを復号できなくなり、鍵が漏えいすれば第三者が復号できる可能性があります。鍵管理は暗号化の安全性とデータ可用性の両方に関わります。

暗号化とハッシュは目的が違う

暗号学的ハッシュ関数は、入力データから一定長のダイジェスト（ハッシュ値）を計算します。通常のハッシュには、暗号文のように元の入力を復号するための鍵はありません。そのため、ハッシュはパスワード保管方式の一要素、データの同一性・改ざん検知、電子署名の入力などに使われます。

ハッシュ値を知っていても元データを安全に復元できるわけではありませんが、ハッシュが必ず元データを一意に表すとも限りません。出力長が有限なので異なる入力が同じハッシュ値になる衝突は理論上存在します。データ完全性を確認するときは、信頼できる経路で得た期待値と比較し、攻撃者がデータとハッシュの両方を置き換えられる場合には、HMACやデジタル署名など認証付きの仕組みを検討します。

電子署名では、送信者がメッセージのハッシュ値などを秘密鍵で署名し、受信者は送信者の公開鍵で署名を検証します。これにより、署名対象の完全性と、公開鍵が正しい送信者に結び付いている場合の送信者認証を確認できます。電子署名は「秘密鍵で暗号化したデータを誰でも復号する」という単純な暗号化方式ではなく、機密性のための暗号化とは別の目的を持ちます。

処理	元に戻す操作	鍵の役割	主な目的
暗号化	復号する	秘密鍵または鍵ペアを使う	内容の機密性
ハッシュ	一般に復号しない	ハッシュ自体に復号鍵はない	データの指紋、完全性検証の材料
電子署名	公開鍵で署名を検証する	署名者の秘密鍵で署名し、公開鍵で検証	完全性、署名者の確認、否認防止に関する証拠

共通鍵暗号（対称鍵暗号）

共通鍵暗号（symmetric-key cryptography）は、暗号化と復号に同じ秘密鍵を使います。鍵を持つ送信側と受信側がその鍵を共有し、暗号化データを受け取った側は同じ鍵で元データに戻します。AESは代表的な共通鍵暗号アルゴリズムです。

項目	内容
暗号化に使う鍵	送信側と受信側で共有する共通の秘密鍵
復号に使う鍵	暗号化に使ったものと同じ鍵
強み	計算効率が高く、大きなデータを暗号化しやすい
主な課題	暗号化を始める前に、鍵を安全に共有し、漏えい・複製・廃棄を管理する必要がある

共通鍵をメール本文と一緒に同じ経路で送れば、通信を傍受した相手がデータと鍵の両方を取得するおそれがあります。鍵を共有するための安全な経路や鍵管理基盤が必要です。また、複数の送信者・受信者の組み合わせごとに別々の鍵を使う設計では、利用者が増えるにつれて鍵の配布と棚卸しが複雑になります。

大容量データを扱う場合、共通鍵暗号はデータ本体の暗号化に適しています。実際のクラウドサービスでは、利用者がすべての暗号処理を自作するのではなく、AWSサービスやKMS、AWS SDKが提供する仕組みを利用することがあります。

公開鍵暗号（非対称鍵暗号）

公開鍵暗号（asymmetric-key cryptography）は、数学的に対応する公開鍵と秘密鍵のペアを使います。鍵ペアの一方を公開しても、もう一方の秘密鍵を現実的な時間で導き出せないように設計されています。

受信者へ機密データを送る場合、送信者は受信者の公開鍵で暗号化し、受信者は対応する自分の秘密鍵で復号します。公開鍵は配布できますが、偽の公開鍵を受信者のものだと信じて暗号化すると、攻撃者が秘密鍵を持つ相手にデータを送ることになりかねません。証明書と認証局、信頼済みの鍵配布経路、フィンガープリントの照合などで、公開鍵の所有者と用途を確認します。

項目	内容
暗号化に使う鍵	宛先である受信者の公開鍵
復号に使う鍵	受信者だけが保持する対応する秘密鍵
強み	事前に共通の秘密鍵を直接共有せずに、鍵ペアを使った仕組みを構成できる
主な課題	鍵ペアと証明書の管理が必要で、大量データの暗号化には共通鍵方式より計算負荷が高い

公開鍵暗号と電子署名では鍵の使い方が異なります。機密性を目的に受信者へ送るデータを暗号化するなら受信者の公開鍵を使います。一方、送信者が作成した署名の真正性を確かめる場合は送信者の公開鍵で署名を検証します。送信者の秘密鍵で署名する処理を「受信者向け暗号化」と取り違えないようにしてください。

ハイブリッド暗号とエンベロープ暗号化

公開鍵暗号だけで大きなファイル全体を暗号化するのは効率的ではありません。一方、共通鍵暗号だけでは共通鍵を相手と安全に共有する課題が残ります。ハイブリッド暗号は、データ本体に効率のよい共通鍵暗号を使い、その共通鍵を公開鍵暗号などで安全に受け渡す方式です。

公開鍵を使うハイブリッド暗号の流れ

受信者の鍵ペアがあらかじめ安全に準備されているとします。

1. 送信者は、対象データの暗号化用に新しいランダムな共通鍵（セッション鍵）を生成する。
2. 送信者は、その共通鍵を使ってデータ本体を共通鍵暗号で暗号化する。
3. 送信者は、受信者の公開鍵を使って共通鍵を暗号化する、または安全な鍵カプセル化処理で保護する。
4. 送信者は、暗号化されたデータと保護された共通鍵を受信者へ送る。
5. 受信者は、自分の秘密鍵で保護された共通鍵を復元する。
6. 受信者は、その共通鍵を使ってデータ本体を復号する。

ここで公開鍵を使って暗号化する対象は大きなデータ全体ではなく、通常はデータ暗号化に使う短い共通鍵です。データ本体は効率のよい共通鍵暗号で処理します。逆に、送信者が自分の秘密鍵でデータを暗号化して受信者に送る、という説明は機密性を実現する正しい流れではありません。それは電子署名の考え方とも混同されています。

AWSでのエンベロープ暗号化

クラウドでは、共通鍵を別の鍵で包んで管理するエンベロープ暗号化が広く使われます。たとえばAWS KMSとアプリケーションを組み合わせると、KMSがデータキーを生成し、アプリケーションはそのデータキーでデータを暗号化します。暗号化済みデータキーをKMSキーで保護した状態で暗号化データと一緒に保存し、復号時には暗号化済みデータキーをKMSに渡して平文のデータキーを取得します。

この方式では、データ本体の暗号化をアプリケーション側で効率よく行いながら、鍵暗号化キー（KMSキー）をアプリケーションへ直接渡さずに保護できます。平文のデータキーは必要な時間だけメモリ上で扱い、暗号処理後に可能な限り速やかに破棄します。KMSキーの使用許可やキーポリシー、アプリケーションのIAMロール、暗号化データキーの保管方法を正しく設定しなければなりません。

ハイブリッド暗号は公開鍵暗号と共通鍵暗号を組み合わせる一般的な考え方であり、エンベロープ暗号化はデータキーを別の鍵で暗号化して扱う具体的な設計パターンです。AWS KMSを使うエンベロープ暗号化では、必ずしも受信者の公開鍵でデータキーを暗号化するとは限りません。KMSキーの種類とAPIに応じた保護方式を確認してください。

鍵とアルゴリズムを安全に運用する

暗号方式が強くても、秘密鍵が漏えいしたり、公開鍵の持ち主を誤認したり、古い暗号設定を使い続けたりすれば、保護は損なわれます。実システムでは少なくとも次の観点を管理します。

• 用途を分ける：データ暗号化、鍵の暗号化、署名、TLS証明書など、鍵を用途に応じて分離する。
• 鍵へのアクセスを最小化する：復号や署名が必要なIAMロールやアプリケーションだけに利用を認める。
• 鍵の所在と所有者を把握する：共通鍵・秘密鍵をコード、ログ、公開リポジトリ、平文設定ファイルへ置かない。
• 鍵のライフサイクルを計画する：生成、配布、バックアップ、ローテーション、無効化、失効、削除と、既存データを復号できる期間を定める。
• 公開鍵の真正性を検証する：公開鍵が本当に想定する利用者・サービスに属するか、証明書チェーンや信頼済みの情報で確認する。
• 暗号化だけでなく完全性も考える：改ざん検出が必要な場合は、認証付き暗号（AEAD）やMAC、電子署名など適切な仕組みを使う。暗号化アルゴリズム・モードの選定とノンス／IVの扱いは公式仕様に従う。
• 利用記録を監査する：鍵の使用履歴やアクセス拒否を記録し、想定外の復号・署名要求を調査できるようにする。

鍵の削除や無効化は、暗号化されたデータを利用不能にする場合があります。鍵のローテーションや廃止を行う前に、バックアップ、復旧手順、保持期間、法的保全要件に照らして影響を確認します。

AWSの暗号化サービスとコンプライアンス

AWSは、サービスに統合された暗号化機能、AWS Key Management Service（KMS）などの鍵管理機能、TLS証明書の利用、暗号 API を提供しています。AWSの各種サービスは、データの保存場所や通信経路に応じた暗号化オプションを提供します。どのデータがどの設定で保護されるかはサービスごとに異なるため、「AWS上に置いたので自動的にすべてのデータが意図した方法で暗号化される」と仮定せず、サービスのデフォルト動作とアカウント設定を確認してください。

暗号アルゴリズムや実装方式は、計算機性能や暗号解析技術の進歩に応じて更新されます。過去に十分とされた鍵長・アルゴリズム・プロトコルが将来も適切とは限らないため、暗号方式の選択は現在の標準・AWSの推奨・組織のポリシーに従い、古い方式を固定して使い続けないようにします。

AWSは規制・標準への対応を支援する仕組みや、FIPS検証済み暗号モジュールを利用する選択肢を提供しています。FIPS 140は暗号モジュールの検証に関する標準であり、「FIPS準拠のモジュールを利用した」ことだけで、アプリケーション全体や組織のシステムがあらゆる規制要件を満たすと保証されるわけではありません。対象サービス・FIPSエンドポイント・リージョン・暗号モジュール・設定を確認し、組織が求めるコンプライアンス範囲に合っているかを別途評価します。FIPSエンドポイントの利用は通信先のAPIエンドポイント選択に関する要件であり、保存データの暗号化設定まで自動的に有効にするものではありません。

また、通信経路の暗号化や保存時暗号化を選ぶ責任、どの利用者に鍵を使わせるかを定める責任、データ分類や保持期間を決める責任は、ワークロードの利用者側にも残ります。AWSのコンプライアンス資料や監査レポートは統制の評価に役立ちますが、自組織の構成と運用が要件に合うかは自ら確認する必要があります。

DVA試験での比較・判断ポイント

• 保存中のデータか、通信中のデータかを先に見分ける。保存時はストレージ暗号化、転送時はTLSなどが主要な対策であり、通常は両方を検討する。
• 共通鍵暗号は同じ秘密鍵で暗号化・復号する。大量データを効率よく処理できるが、鍵を安全に共有・保管する必要がある。
• 公開鍵暗号で受信者に秘密のデータを届ける場合は、受信者の公開鍵で暗号化し、受信者の秘密鍵で復号する。公開鍵の真正性も確認する。
• ハイブリッド暗号はデータを共通鍵で暗号化し、共通鍵を受信者の公開鍵などで保護する。大きなデータの効率と鍵配布上の利点を組み合わせる。
• 電子署名は送信者の秘密鍵で作成し、対応する公開鍵で検証する。秘密鍵で暗号化して相手に秘密の内容を送ることとは異なる。
• ハッシュは暗号化ではない。ハッシュ値から平文を復号する操作はなく、完全性確認や署名の材料などに使う。
• 暗号文が読めないことと、通信相手やデータの完全性が確認できていることは別である。TLS証明書検証、認証付き暗号、MAC、署名など目的に合う機能を選ぶ。
• 暗号化はIAM、データベース権限、アプリケーション認可の代わりにならない。鍵を利用できる主体も最小権限にする。
• FIPSや各種コンプライアンスへの対応は、暗号モジュールだけでなく対象サービス・エンドポイント・設定・運用を含めて評価する。

AWS公式ドキュメント

• AWS Well-Architected Security Pillar: データ保護
• AWS Well-Architected Security Pillar: 保存時データの保護
• AWS Well-Architected Security Pillar: 転送中データの保護
• AWS KMSの概念とKMSキー
• AWS KMSの対称鍵暗号と非対称鍵暗号
• AWS KMSによるエンベロープ暗号化
• AWS FIPS 140-3準拠サービスとエンドポイント