データ保護とコンプライアンスのためのAmazon ECSワークロードのアーキテクチャ

Pulisher : Cloud Technology Center キョン・ギョンソン
Description : ECSベースのHIPAAワークロードに関する紹介セッション

はじめに

以前、HIPPAコンプライアンスを遵守するためのワークロードについてコンサルティングをした経験があります。2～3年前なので、当時はECSに関する資料も、HIPPAに関する資料も不足しており、事例を探すのに苦労したことを思い出しました。AWSで直接小規模に進行するBuilder sessionを通じて、ある程度時間が経った今、ECSベースのHIPAAワークロードに対する多くの事例についての内容を聞いて、いくつかのテストと議論をすることができたセッションでした。

セッションの概要紹介

詳細に入る前に、HIPPAという言葉をご存知でしょうか？

個人健康情報(PHI)を保護するために、個人情報保護およびセキュリティに関するコンプライアンスです。個人の健康データは非常に重要であり、韓国ではまだ該当規定まではありませんが、米国など欧米圏ではヘルスケア、病院など該当情報があるワークロードについては多く守らなければならない規定事項です。

転送中、転送後、保存中のデータに対してすべて暗号化しなければならず、非常に厳しい規定ですが、AWS ECSを通じてPHIとPIIを含むデータを守る方法について説明する予定です。

このセッションで事前に配布されたAWSサービスアーキテクチャです。
・簡単なPublic alb – fargate構造
・セキュリティ監査のためのVPC Flow log、Cloudwatch、Cloudtrail
・該当監査ログをS3に集中化
・アラーム通知のためのSNS

実践に入る前に、

AWSのセキュリティである共同責任モデルにより、セキュリティとコンプライアンスはAWSとお客様の共同責任です。 そのため、AWSが努力して築いた土台の上に、私たちもセキュリティに対する取り組みを行い、アプリケーションを完璧なセキュリティの形で構築する必要があります。これに合わせた数多くのセキュリティコンプライアンスが存在しますが、主にISMSを多く聞いたことがあるかと思います。 このセッションでは、HIPPAというコンプライアンスを扱う予定です。

さらに、責任共有モデルについて、もう少し深く掘り下げて説明します、

AWSはサービスをinfrastructure、container、abstractedの3つに分類します。 それぞれの分類ごとに少しずつ異なるセキュリティが提供され、顧客の責任及び構成しなければならない作業の量も異なります。

[infrastructure]
この分類は、EC2、VPCのようなサービスを指し、必要なセキュリティの構成と管理作業を直接行う必要があります。 EC2インスタンスを展開する場合、ゲストオペレーティングシステムのアップデートやセキュリティパッチ、インスタンスにインストールしたアプリケーションソフトウェアやユーティリティを管理する必要があります。

[container]の場合
RDS、EMR、Elastic Beanstalkなどのサービスは、通常はEC2やその他のインフラストラクチャのインスタンスで個別に実行されますが、オペレーティングシステムやプラットフォーム層を管理する必要はありません。 これは、アプリケーション「コンテナ」に対してマネージドサービスを提供するため、ファイアウォールルールなどのネットワーク制御を設定・管理し、IAMとは別にプラットフォームレベルのIDやアクセス管理を行う程度までしか管理する必要がありません。

[abstracted]
S3、Glacier、DynamoDB、SQS、SESなどのストレージデータベースメッセージングサービスです。これらのサービスは、クラウドアプリケーションを構築・運営できるプラットフォームまたは管理層を抽象化し、APIを使用してこれらの抽象化されたサービスのエンドポイントにアクセスし、AWSは基本的なサービスコンポーネントを管理します。

AWS Artifactです。

AWS Business Associate Addendum(AWS BAA) : 1996年健康保険移動性及び責任法(HIPAA)の要求通り、個人健康情報(PHI)と関連したAWSサービスの使用に関する契約です。
該当コンソールで、HIPAAを入力した後、契約書のダウンロード、契約書の承諾ボタンを押して活性化します。

HIPAAコンプライアンスについて大きく4つに分けることができます。

１．アクセス管理部分
２．Detective
３．Protect
４．Audit, Backup, DR

このBuilders Sessionでは、熱心な議論により、残念ながら１，２項目についてのみ話していたら時間が過ぎてしまい、簡単に2つの部分だけ紹介させていただきます。

１．アクセス管理部分
一番基本的なAWS IAMユーザー管理に関する部分でした。

参考リンク : https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction_access-management.html

・AWSマネージドポリシーの使用と最小権限の原則
・最小権限適用
・IAMポリシーの条件を使用してアクセスを追加的に制限する
・IAM Access Analyzを通じたIAM Policy検証
・MFA

AWS IAMユーザー管理に続き、Amazon ECSへのアクセスも制御する必要があります。
・ECS Task definitionsのRoleに対する最小権限を守ります。

特定のECSクラスターの名前を指定して最小権限を維持します。
しかし、範囲が狭すぎるポリシーは良いことばかりではありません。 タイトなポリシーは拡散を招き、管理オーバーヘッドを増加させる可能性があります。 そのため、特定のタスクやサービスのみに範囲が指定されるRoleを作成する代わりに、HIPAAワークロードを実行するクラスターに範囲が指定されるRoleを作成して使用することをお勧めします。

２．Detective

AWS Configを活性化させ、HIPAA Packを適用して現在のインフラストラクチャのコンプライアンスを知ることができます。

AWS Configの有効化

AWS ConfigのコンプライアンスパックからHIPAAセキュリティテンプレートの運用ベストプラクティスであるhipaa-conformance-packを選択して配布します。

ダッシュボードを通じて、現在の規制に準拠したコンプライアンスと非準拠のリソースに関する情報を確認することができます。

CloudTrailを通じてコンプライアンスを確認する方法です。

この実習アカウントでは、あらかじめCloudtrailトレースが生成されているので、確認だけしました。

CloudTrailを通じて、コンソール作業及びAPI呼び出しを記録して、今後の否認防止に役立てることができます。AWSサービスを呼び出したユーザー及びAWSアカウント、呼び出しが生成されたソースIPアドレス、呼び出しのタイミングまで全て知ることができます。

また、当該Cloudtrailでは設定されていませんが、機密データが存在する可能性があり、保存データを保護するためにCloudtrail追跡に対して暗号化も有効にします。

Cloudtrailログに対して整合性を確認するために、追跡に対するログファイルの検証機能まですることをお勧めします。

セッションを終えて

以前にHIPAAワークロードに対するコンサルティングを行った時は、今のように多くのサービスがなかったので、その当時は最適な条件をサポートしてくれました。 今、そのワークロードに対するコンサルティングの機会があれば、今回のre:Inventに出た多くの新技術だけでなく、多くのソリューションを通じて本当に個人情報に対する保護を守ることができそうです。

特に、レポートには書きませんでしたが、今回のre:Inventでリリースされた機能の一つであるAmazon Inspectorを通じたAWS CI/CDツールであるCode pipelineサービスと結合してBuild時にコンテナイメージに対する脆弱性検討をする方法もとても良いのではないかと思いました。