Amazon Web Services ブログ

新しい Amazon Aurora クラスターに対する保管時のデフォルト暗号化の使用

本記事は 2026 年 2 月 17 日 に公開された「Use default encryption at rest for new Amazon Aurora clusters」を翻訳したものです。

データセキュリティはあらゆる規模の組織にとって最優先事項であり、保存データの暗号化は組織のセキュリティ戦略の重要な要素です。保存データの暗号化はストレージレベルでデータを不正アクセスから保護し、誰かが物理的にストレージメディアにアクセスしたとしても、適切な暗号化キーがなければ機密情報を読み取れないようにします。これにより、メディアの盗難や物理ストレージデバイスの不適切な廃棄によるリスクも軽減できます。

GDPR, HIPAA, PCI DSS, SOC 2 などの規制フレームワークでは、機密データの暗号化が求められています。デフォルトの暗号化によりコンプライアンスが簡素化され、コンプライアンス違反によるペナルティのリスクも低減します。Amazon Aurora の保管時の暗号化により、すべての新しい Aurora クラスターは追加の操作なしにこれらの規制要件を満たせます。

本記事では、Amazon Aurora が、AWS 所有キーを使用してすべての新規データベースクラスターに対しデフォルトで保管時の暗号化を提供するようになったことを学びます。StorageEncryptionType フィールドによる暗号化ステータスの確認方法、新規および既存クラスターへの影響、暗号化されていないデータベースの移行オプションについても解説します。

Amazon Aurora における保管時暗号化

以前は、保管時の暗号化は Aurora クラスター作成時に明示的に選択できるオプション機能でした。create API ではデフォルトで暗号化が無効になっており、--storage-encrypted パラメータを指定せずに、または --no-storage-encrypted パラメータを指定してクラスターを作成すると、データベースは暗号化されていない状態でした。

今後、すべての新しい Aurora クラスターは AWS 所有キーを使用してデフォルトで暗号化が有効になり、すべての新しいデータベースの顧客データは物理メディア上で常に暗号化されます。暗号化はアプリケーションに対して透過的で、パフォーマンスへの影響はありません。AWS 所有キーによる暗号化 (またはデフォルトの保管時の暗号化) には追加料金は発生しません。

Amazon Aurora での暗号化タイプ

キーのタイプは以下のとおりです。

  1. AWS 所有キー (SSE-RDS) – AWS が完全に管理する暗号化キーで、ユーザーは表示や管理ができません。Aurora でのデフォルト暗号化に自動的に使用されます。
  2. AWS マネージドキー (AMK) – AWS が作成・管理するキーで、アカウントで表示できますがカスタマイズはできません。月額料金はかかりませんが、AWS KMS API の料金が適用されます。
  3. カスタマーマネージドキー (CMK) – アカウント内に保存され、ユーザーが作成、所有、管理するキーです。AWS KMS キーを完全に制御できます (AWS KMS の料金が適用されます)。

StorageEncryptionType 出力フィールド

データが保管時に暗号化されているかどうかをより明確に把握できるようにするために、Amazon Aurora はすべての describe API で StorageEncryptionType という追加の出力フィールドを公開するようになりました。このフィールドで設定される値は以下です。

  • sse-rds (サーバーサイド暗号化): インスタンスやクラスターが AWS 所有キーで暗号化されていることを示します。
  • sse-kms (AWS マネージドキーまたはカスタマーマネージドキー): インスタンスやクラスターが AWS マネージドキーまたはカスタマーマネージドキーで暗号化されていることを示します。
  • none: インスタンスやクラスターがデフォルトでは暗号化が無効だった時期に作成され、暗号化されていないことを示します。

AWS 所有キーで新しいクラスターを作成すると、StorageEncrypted フィールドは false と表示され、StorageEncryptionType フィールドは sse-rds と表示されます。これは、データベースの暗号化を明示的に選択しなかったものの、AWS 所有キーでデータは保管時に暗号化されていることを示します。

この変更は Aurora クラスターにどのような影響を与えるか

この変更による影響は以下です。

  • 新しいクラスター: 設定不要で、AWS 所有キー (sse-rds) により自動的に暗号化されます。
  • 既存のクラスター: 現在の暗号化状態が維持されます。既存のデータベースは自動的に変更されません。
  • 既存の暗号化されていないクラスターの自動バックアップ、スナップショット、クローンは暗号化されないままです。
  • 暗号化されていないクラスターをスナップショットから復元すると、AWS 所有キーで暗号化されます。AWS 所有キーを使用することで、AWS サービスはデータを透過的に暗号化し、キーの共有を気にすることなくクロスアカウントやクロスリージョンでのクラスター共有を容易に実現します。
  • コンプライアンスやキー管理の目的で KMS ベースの暗号化が必要な場合は、Aurora クラスター作成時にカスタマーマネージドキー (CMK) または AWS マネージドキーを明示的に指定できます。一般的に、リソースを保護する暗号化キーの監査や制御が必要でない限り、AWS 所有キーが適切な選択肢です。

ユースケースと例

Aurora クラスターの保管時暗号化の例とユースケースを紹介します。

ユースケース 1: 新しい Aurora クラスターの作成

シナリオ: --storage-encrypted パラメータを指定せずに、または明示的に --no-storage-encrypted を使用して、新しい Aurora PostgreSQL クラスターを作成します。
結果: AWS 所有キーを用いたサーバーサイド暗号化 (SSE) がデフォルトで有効な状態でクラスターが作成されます。

--storage-encrypted パラメータを指定しない CLI の例:

aws rds create-db-cluster \
--db-cluster-identifier apgtest1 \
--engine aurora-postgresql \
--master-username postgres \
--master-user-password xxxxxxx

出力:

{
    "DBCluster": {
        "DBClusterIdentifier": "apgtest1",
        "Engine": "aurora-postgresql",
        "StorageEncrypted": false,
        "StorageEncryptionType": "sse-rds"
    }
}

明示的に --no-storage-encrypted パラメータを指定した CLI の例:

aws rds create-db-cluster \
--db-cluster-identifier apgtest1 \
--engine aurora-postgresql \
--master-username postgres \
--master-user-password xxxxxxx \
--no-storage-encrypted

出力:

{
    "DBCluster": {
        "DBClusterIdentifier": "apgtest1",
        "Engine": "aurora-postgresql",
        "StorageEncrypted": false,
        "StorageEncryptionType": "sse-rds"
    }
}

ユースケース 2: スナップショットからの復元

シナリオ: KMS キーを指定せずに、暗号化されていないクラスターのスナップショットを復元して Aurora クラスターを作成します。
結果: 復元されたクラスターは、AWS 所有キーを使用したサーバーサイド暗号化 (SSE) が有効な状態で作成されます。

CLI の例:

aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier restored-cluster \
--snapshot-identifier unencrypted-cluster-snapshot \
--engine aurora-postgresql

出力:

{
    "DBCluster": {
        "DBClusterIdentifier": "restored-cluster",
        "Engine": "aurora-postgresql",
        "StorageEncrypted": false,
        "StorageEncryptionType": "sse-rds"
    }
}

ユースケース 3: クラスターの確認

シナリオ: ユースケース 1 またはユースケース 2 で作成した Aurora クラスターの暗号化ステータスとタイプを確認します。
結果: 出力に暗号化ステータスが反映されます。ユースケース 1 およびユースケース 2 ではクラスター作成時に --storage-encrypted オプションを指定しなかったため、StorageEncrypted は false と表示されます。StorageEncryptionTypesse-rds と表示され、データが AWS 所有キーで暗号化されていることが確認できます。

CLI の例:

aws rds describe-db-clusters --db-cluster-identifier apgtest1

出力:

{
    "DBClusters": [
        {
            "DBClusterIdentifier": "apgtest1",
            "Engine": "aurora-postgresql",
            "StorageEncrypted": false,
            "StorageEncryptionType": "sse-rds"
        }
    ]
}

ユースケース 4: スナップショットの作成

シナリオ A: SSE で暗号化された Aurora クラスターからスナップショットを作成します。
結果: ソースクラスターと同じ暗号化状態 (SSE) でスナップショットが作成されます。

CLI の例:

aws rds create-db-cluster-snapshot \
--db-snapshot-identifier apgtest1-snapshot \
--db-instance-identifier apgtest1

SSE 暗号化スナップショットの出力:

{
    "DBClusterSnapshot": {
        "DBClusterSnapshotIdentifier": "apgtest1-snapshot",
        "DBClusterIdentifier": "apgtest1",
        "Engine": "aurora-postgresql",
        "StorageEncrypted": false,
        "StorageEncryptionType": "sse-rds"
    }
}

シナリオ B: 暗号化されていない Aurora クラスターからスナップショットを作成します。
暗号化されていないスナップショットの出力 (既存のインスタンス):

{
    "DBClusterSnapshot": {
        "DBClusterSnapshotIdentifier": "old-cluster-snapshot",
        "DBClusterIdentifier": "old-unencrypted-cluster",
        "Engine": "aurora-postgresql",
        "StorageEncrypted": false,
        "StorageEncryptionType": "none"
    }
}

AWS コンソールの変更

AWS マネジメントコンソールにも新しいデフォルト暗号化の動作が反映され、より詳細な Aurora クラスターの暗号化ステータスが表示されます。

SSE 暗号化を使用しているインスタンスの場合、コンソールの暗号化セクションに AWS 所有 KMS キー と表示されます。これにより、どのタイプの暗号化が使われているかが明確になります。KMS ベースの暗号化を使用しているインスタンスの場合は、AWS マネージド KMS キー または カスタマーマネージド KMS キー と表示されます。以下のスクリーンショットは、デフォルトキー (AWS 所有キー) で暗号化されたクラスターの設定を示しています。

暗号化オプションを指定したインスタンスの作成

新しいインスタンスやクラスターを作成する際、Aurora コンソールに 3 つの暗号化キーオプションのドロップダウンメニューが表示されるようになりました。

  1. AWS 所有 キー (SSE-RDS)
  2. AWS マネージドキー (SSE-KMS)
  3. カスタマーマネージドキー (SSE-KMS)

同様に、コンソールでスナップショットを復元する際にも同じ 3 つのオプションが表示され、ユースケースに適した暗号化タイプを選択できます。

暗号化されていない既存のクラスターをどのように SSE または KMS 暗号化に移行するか

暗号化されていない既存データベース (StorageEncryptionType が none) がある場合、SSE または KMS ベースの暗号化を使用するように移行できます。

オプション 1: SSE (AWS 所有キー) を使用してクラスターを暗号化する

  1. 暗号化されていないデータベースのスナップショットを作成します
  2. 暗号化されていないスナップショットから復元して新しいクラスターを作成します
  3. アプリケーションの接続先を新しいクラスターのエンドポイントに更新します
  4. クラスターがデフォルト (AWS 所有) キーで暗号化されていることを確認します
  5. 元の暗号化されていないクラスターを削除します
# Create cluster snapshot
aws rds create-db-cluster-snapshot \
--db-cluster-identifier original-cluster \
--db-cluster-snapshot-identifier original-cluster-snapshot

# Restore from unencrypted snapshot
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier new-encrypted-cluster \
--snapshot-identifier original-cluster-snapshot 

# Verify your cluster is encrypted with default (AWS owned) keys
aws rds describe-db-clusters \
--db-cluster-identifier new-encrypted-cluster \
--query "DBClusters[0].{StorageEncrypted:StorageEncrypted,KmsKeyId:KmsKeyId, StorageEncryptionType:StorageEncryptionType}" \
--output table

オプション 2: KMS ベースの暗号化 (CMK または AWS マネージドキー) に移行する

オプション 1 と同じ手順で、スナップショット復元時に --kms-key-id を指定します。

# Restore with KMS encryption
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier new-encrypted-cluster \
--snapshot-identifier original-cluster-snapshot \
--kms-key-id arn:aws:kms:us-east-1:123456789012:key/your-kms-key-id

まとめ

本記事では、すべての新規 Aurora クラスターで保管時の暗号化がデフォルトで有効になり、追加コストや設定作業無しでセキュリティ強化と簡素化されたコンプライアンスを実現できることを紹介しました。既存データベースの暗号化ステータスを確認し、暗号化されていないデータベースを移行してこの強化されたセキュリティ機能を活用することを推奨します。


著者について

Pratibha Shivnani

Pratibha Shivnani

Pratibha は、Amazon Web Services (AWS) の Amazon Aurora チームで Senior Product Manager (テクニカル – 外部サービス) を務めています。彼女は顧客のデータベース体験の簡素化と、強力なデータソリューションを誰もが使いやすくスケーラブルにすることに情熱を注いでいます。

Sukhpreet Kaur Bedi

Sukhpreet Kaur Bedi

Sukhpreet は、AWS の Senior PostgreSQL Specialist Solutions Architect として、Amazon RDS for PostgreSQL と Aurora PostgreSQL エンジンを担当しています。彼女は、高可用性でスケーラブル、セキュアなデータベースアーキテクチャの構築を支援しています。


翻訳は Technical Account Manager の石渡が担当しました。