【ブログ要約版】2分で読める生成AIのいま Vol.70 タイトル：AWSで医療情報を守る ― TLS・KMS・S3暗号化の具体的な設定

マガジン「クラウドで医療情報を守る」の第2回です。前回の"概念"を、今回はAWSの具体的な設定に落とし込みます（Microsoft Azure・Google Cloudでも考え方は共通です）。

‍ ‍

（※2026年7月時点の情報です。ガイドラインやAWSの仕様は改定・更新されることがあります。）

‍ ‍

前回、暗号通信の基本と「高セキュリティ型」の要件を整理しました。 ではクラウド上で、具体的にどう設定すればいいのか？ 今回はAWSを例に、通信の暗号化（TLS設定）と保存データの暗号化（S3・KMS）の実装ポイントを見ていきます。 Microsoft Azure AI FoundryやGoogle Cloudでも構造は似ているので、考え方はそのまま応用できます。

‍ ‍

────────── ▶ この記事は要約版です。医療田さん・機械屋さんの会話形式による全文（約2分）はnoteでどうぞ。 https://note.com/41machida_ai/n/nc66a33b5304f ──────────

‍‍ ‍

■ この記事のポイント ・通信の暗号化はALB/CloudFrontのTLSセキュリティポリシーで設定する。高セキュリティ型にはTLS 1.3対応ポリシーが必要 ・保存データの暗号化はS3のデフォルト（SSE-S3）でも有効だが、医療情報にはSSE-KMSが推奨。監査証跡と鍵のアクセス制御が可能になる ・鍵管理はKMSが担う。FIPS 140-2レベル3のHSMに保管され、AWS従業員もアクセスできない ・データの保管場所は東京/大阪リージョンを指定して国内に限定 ・AWSの「責任共有モデル」を理解し、利用者側の責任範囲を把握する。NECなどのAWSパートナーが公開するリファレンスが出発点として有用

‍ ‍

■ よくある質問（FAQ） Q. AWSのALBでTLS 1.3に対応するにはどうすればいいですか？ A. ALBのリスナー設定で、セキュリティポリシーを「ELBSecurityPolicy-TLS13-1-2-2021-06」（TLS 1.3 + 1.2）または「ELBSecurityPolicy-TLS13-1-3-2021-06」（TLS 1.3限定）に設定します。高セキュリティ型への対応を目指す場合、まずは前者で運用しながら段階的に後者への移行を検討してください。

‍ ‍

Q. S3のSSE-S3とSSE-KMSの違いは何ですか？ A. SSE-S3はAWSが鍵の生成・管理をすべて自動で行う方式で、設定不要ですが監査ログは限定的です。SSE-KMSはAWS KMSの鍵を使い、鍵ごとのアクセス権限設定とCloudTrailによる詳細な操作ログが取得可能です。医療情報のように監査証跡が求められるデータにはSSE-KMSが推奨されます。

‍ ‍

Q. AWS KMSの暗号鍵はAWSの従業員がアクセスできますか？ A. いいえ。KMSの鍵はFIPS 140-2レベル3認証を受けたHSM（Hardware Security Module）内で処理され、鍵がHSM外に出ることはありません。AWSの責任共有モデルにより、鍵の利用権限は利用者が管理します。

‍ ‍

Q. 医療データは海外のデータセンターに保管されませんか？ A. AWSでは利用者がリージョンを選択できます。東京リージョン（ap-northeast-1）または大阪リージョン（ap-northeast-3）を指定すれば、データは日本国内のデータセンターに保管され、利用者が明示的に設定しない限り他のリージョンにコピーされることはありません。

‍ ‍

Q. このAWS固有の話は、他のクラウドにも応用できますか？ A. はい。Microsoft Azure AI FoundryやGoogle Cloudでも、TLS設定、保存データの暗号化、鍵管理サービス、リージョン選択という基本構造は共通しています。Azure Key VaultやGoogle Cloud KMSなど、対応するサービス名は異なりますが、考え方と確認すべきポイントは同じです。

‍ ‍

────────── ▼この記事が入っているマガジン：クラウドで医療情報を守る ― 暗号化とAWS実装 https://note.com/41machida_ai/m/m61e73e9efaea