🔐

AWSにおけるデータの暗号化

2024/07/15に公開

はじめに

コンプライアンス要件を達成するためには、データの適切な保存と暗号化を行う必要があります。
AWSでは暗号化に関する様々なサービスや機能があるので解説していきます。

データの暗号化について

まず、AWSでの暗号化に関連するサービス説明の前にデータの暗号化についておさらいしていきます。
データの暗号化とは、平文(読み取り可能な形式のデータ)を符号化された形式変換し、復号化しないと読み取りや処理ができないようにするセキュリティ技術のことです。

暗号化はデータセキュリティの基本要素で、コンピューターシステムの情報の盗難、閲覧、悪用を確実に防止する上で最も簡単で重要な方法のため、インターネットではブラウザーとサーバー間でやりとりされるあらゆるユーザー情報の秘匿性を保障するために個人や大企業を含め幅広く使用されています。

データの暗号化の方式

暗号化と複合

暗号化とは、平文(読み取り可能な形式のデータ)を暗号化鍵と呼ばれる情報を用いて変換し、符号化された形式変換し、第三者が見ても中身がわからない状態(暗号文)にするプロセスを指します。
一方で、複合とは、暗号化されたデータはを複合鍵と呼ばれる情報を用いて元のデータに復元するプロセスを指します。

暗号化と複合の方式は、大きく以下の2つに分かれます。

1. 共通鍵暗号方式
2. 公開鍵暗号方式

それぞれの違いについて解説します。

共通鍵暗号方式

共通鍵暗号方式とは、データの暗号化と復号に同じ鍵(共通鍵)を使用する方式です。

  • 仕組み
    • 送信者が共通鍵で平文を暗号化する
    • 受信者が同じ共通鍵を使って暗号文を復号する
  • メリット
    • 暗号化・復号の演算が比較的単純で高速
    • 効率的に大量のデータを処理することが可能
  • デメリット
    • 共通鍵が漏洩すると、暗号化された内容が解読されてしまう

公開鍵暗号方式

公開鍵暗号方式とは、データの暗号化と復号に異なる2つの鍵(公開鍵秘密鍵)を使用する方式です。
(公開鍵暗号方式で用いる公開鍵(暗号鍵)と複合鍵のペアのことをキーペアといいます。)

公開鍵は誰でも入手可能な公開された鍵で、データの暗号化に使用します。
一方で、秘密鍵は所有者のみが保持し、暗号文の復号に使用します。

2つの鍵を使ったデータの送信の流れを見てみます。

1. データの受信者が秘密鍵を使って公開鍵を作成する
2. データの送信者は受信者の公開鍵を取得する
3. 平文を送信者が公開鍵を使い暗号化し送付する
4. 受信者が暗号文を受け取る
5. 受信者は暗号文を秘密鍵で平文に復号化する

このように、受信者(秘密鍵を持っている人)のみが暗号を解くことができる仕組みになっています。

  • メリット
    • 秘密鍵(複合鍵)の共有が不要なため、安全性が高くなる
  • デメリット
    • 共通鍵暗号化に比べて暗号化/複合の処理時間が長い

AWSでの蓄積データの保護について

AWSの多くのサービスは蓄積データの暗号化に対応していますが、すべてのサービスで最初から暗号化が有効になっているわけではありません。
一部のサービスでは暗号化がオプションであり、利用者が設定を行う必要があります。

また、サーバーに保存するデータを暗号化する方法には以下の2つの方法があります。

  1. クライアントから送られたデータをサーバー側で暗号化して保存する方法
  2. クライアント側でデータを暗号化してからサーバーに保存する方法

それぞれの違いについて解説します。

サーバサイド暗号化

AWSのサービスには、データセンター内に保存されているデータを自動的に暗号化してくれるものがあります。
例として以下のサービスがあります。

  • Amazon DynamoDB

↑ データをサーバーに保存するだけで暗号化と複合化が行われるため、利用者は意識することなくデータの保存と読み込みが可能です。

一方で、自動的に暗号化が行われないサービスもあります。
例として以下のサービスがあります。

  • Amazon S3、EBS (ストレージサービス)
  • Amazon EDS(リレーショナルデータベースのマネージドサービス)

↑ コンプライアンス要件に基づいて適切にサーバーサイド複合化を設定する必要があります。

※それぞれのサービス内容については、別記事で解説します。

クライアントサイド暗号化

データの暗号化と複合をクライアント側に保存されている暗号鍵と複合鍵を利用して行います。
利用者側で鍵の管理や暗号化と複合を行う必要があるため、管理・運用コストは上がりますが、全てを使用者側で制御可能な点がクライアント暗号化の特徴です。

AWSでの暗号鍵の管理

データの暗号処理においては、暗号鍵を安全に保管し、アクセス管理を厳格に行うことが重要です。
クライアントサイド暗号化では、利用者が自分で暗号鍵を管理する必要がありますが、サーバーサイド暗号化で利用する暗号鍵については、AWSのマネージメントサービスを利用できます。

AWS Key Managament Service(AWS KMS)


AWS Key Managament Service(AWS KMS)はマルチテナント方式のマネージド暗号鍵管理サービスです。
利用者は自身で暗号鍵を作成することもできますが、AWSのサービスが利用者の代わりに作成することも可能です。
また、AWSのサービスが所有する暗号鍵を利用できる場合もあります。AWS KMSは、これらのキーを集中管理します。
作成された暗号鍵は、サーバーサイド暗号化をサポートするほぼすべてのAWSサービスで利用でき、アクセス制限によって暗号鍵を利用できる利用者を制限することができます。

AWS KMSで作成・管理する暗号鍵には、次のような種類があります

  • カスタマーマネジメントキー
  • AWSマネージドキー
  • AWS所有のキー

AWS CloudHSM


AWS KMSよりも高いセキュリティレベル(FIPS 140-2 レベル3)で暗号鍵を管理できるシングルテナント方式のマネージド暗号鍵管理サービス。
AWS KMSと連携させると、AWS KMSのカスタマーマネージドキーを、AWS CloudHSMに保存することもできます。

AWSでの転送データの保護

AWSを利用する場合、データが主にインターネットを通じて送受信されることから、データ盗聴のリスクがあります。そのため、転送中のデータを暗号化することも重要になってきます。

AWSのサービスとの通信については、SSL/TLSによる暗号化が利用されており、AWS責任共有モデルにおいても、AWSの責任範囲となるため、利用者が意識する必要はありません。
一方で、利用者自身が構築したWebサーバーなどとの通信については、利用者側の責任で暗号化を行う必要があります。

※AWS責任共有モデルとは:
AWS側と利用者との間で、セキュリティとコンプライアンスに関する責任を分担する考え方のこと。


※引用: Amazon Web Services 「責任共有モデル」https://aws.amazon.com/jp/compliance/shared-responsibility-model/ (参照2024-07-15)

AWS Certificate Manager(ACM)

AWS Certificate Manager(ACM)は、保有するドメインに対するパブリックサーバー証明書を発行できるサービスです。
発行された証明書は自動的に更新されるため、証明書の有効期限切れを意識する必要がありません。
※ただし、ACMでは拡張検証証明書(EV証明書)や組織検証証明書(OV証明書)には対応していません。

発行された証明書は一般的に、Elastic Load Balancing(ELB)やAmazon CloudFrontなどのAWSサービスで利用されます。

また、ACMではプライベートCA(認証局)を構築し、開発環境や社内システムなどの組織内部での利用に限定したプライベート証明書を発行するプライベートCA(認証局)を構築することもできます。

まとめ

AWSにおけるデータの暗号化について解説させていただきました。

  • AWSでは様々なデータ暗号化に関するサービスや機能を提供しており、これらを活用することでコンプライアンス要件を達成することができる
  • AWSにおけるデータの暗号化では、データをサーバー側で自動的に暗号化する サーバーサイド暗号化 と、クライアント側で暗号化を行う クライアントサイド暗号化 の2つの方式が利用できる
  • 暗号鍵の管理においては、AWS Key Management Service (KMS)AWS CloudHSMなどのサービスを使って、安全に鍵を管理することができる
  • AWSサービス間の通信はAWSが暗号化を担当するが、ユーザー構築のシステムとの通信はユーザー側での暗号化が必要になる。その際、 AWS Certificate Manager (ACM) を使ってサーバー証明書を発行・管理することができる

このように、AWSは豊富なデータ保護機能を提供しており、自社のニーズに合わせて適切に活用することで、データのセキュリティを確保しつつコンプライアンスへの対応も可能になります。

次回はAWS Key Management Service (KMS)やAWS CloudHSM等深掘って解説していきます!

Discussion