Well-Architected Framework セキュリティ

AWS Transfer Family

AWS Transfer Familyは、AWSストレージ上へのセキュアなファイル転送を実現するマネージドサービスです。SFTP、FTPS、FTPなどをサポートし、Amazon S3およびAmazon EFSへセキュアにファイルの転送が可能です。

Transfer FamilyでSFTPサーバーなどを作成すると、ユーザーがアクセスするための接続エンドポイントが設定されます。エンドポイントには、インターネットからアクセス可能な「パブリックエンドポイント」と、VPCでホストされる「VPCエンドポイント」があります。
そのうちの「パブリックエンドポイント」はインターネット経由でアクセスできるので、リモートのユーザーや他社からのファイル転送に適しています。また、複数のAZに自動的に配置されるので高い可用性があります。

AWS Transfer Familyは、AWSストレージ上へのセキュアなファイル転送を実現するマネージドサービスです。SFTP、FTPS、FTPなどをサポートし、Amazon S3およびAmazon EFSへセキュアにファイルの転送が可能です。Transfer Familyには独自の認証機能があり、SFTPユーザーのアカウント作成・管理ができます。

Transfer Familyでは、インターネット経由でアクセスできるSFTPサーバーを作成できます。各店舗からはTransfer FamilyのSFTPサーバーを使用して、S3バケットに販売データと在庫情報を送信します。

複数のAWSアカウントをまとめて管理する機能にAWS Organizationsがあります。Organizationsでは、管理するAWSアカウントに対して権限を設定したり、管理するAWSアカウントへの請求情報をひとまとめにすることができます。

Organizationsでは組織を階層構造で管理します。

組織に属しているOU（Organizational Unit）またはAWSアカウントに対して、利用できるAWSサービスやアクションを制限する「サービスコントロールポリシー（Service Control Policy：SCP）」を設定することもできます。SCPを用いると、例えばテスト用のアカウント（群）は特定のサービスにしかアクセスできないようにしたり、全てのアカウントに対してMFA（多要素認証）を強制するように設定することなどができます。
SCPを組織（Root）やOUに対して設定すると、その配下の要素に対してもSCPが適用（継承）されます。なお、SCPによる制限は組織の管理アカウントに対しても有効です。

AWS Systems Manager Run Command

AWS Systems Manager Run Commandは、AWSのEC2インスタンスやオンプレミスのサーバーに対してリモートでコマンドやスクリプトを安全に実行する機能です。サーバーにログインしなくても安全でセキュアに大規模なサーバー群をリモートで管理できるため、踏み台サーバー、手動でのSSH接続などが不要になります。
パッチ管理に限定されずリモートから任意のコマンドやスクリプトの実行ができるため、多様なタスクの自動化や一斉実行が可能です。
既存の多数のEC2インスタンスにCloudWatchエージェントをリモートで安全にインストールするのに適した方法です。

AWS WAF（Web Application Firewall）は、脆弱性を突く攻撃（クロスサイトスクリプティングやSQLインジェクションなど）から、Webアプリケーションを保護するサービスです。「Web ACL」というアクセスコントロールリストで、IPアドレス、HTTPヘッダー、HTTP本文、URI文字列などに対してフィルタリングの条件を設定できます。また、Web ACLには接続元のIPアドレスから国別にアクセスを制限できる機能（地理的一致ルール）や、特定の時間内にリクエスト数が設定値を超えたIPアドレスをブロックする機能（レートベースのルール）もあります。

AWS WAFは、Amazon CloudFront、Application Load Balancer、Amazon API Gatewayなどに割り当てて利用します。

AWS IAM Identity Center

AWS IAM Identity Center（旧: AWS Single Sign-on）は、複数のAWSアカウントやアプリケーションへのアクセスを効率的に一元管理するためのサービスです。Identity Centerを使用すると、一度の認証処理で複数のAWSアカウントやアプリケーションへのアクセスが可能になるシングルサインオンの環境を容易に実現することができます。
Identity CenterはAWS Organizationsと組み合わせて使用することが推奨されています。Organizationsで一元管理されているAWSアカウントに対するシングルサインオンを、Identity Centerを使用して実現することができます。
また、Identity Centerは、他の認証システム（例: Microsoft Active Directory）と連携させることが可能です。これにより、例えば、既存のDirectory Serviceの認証情報でログインするだけで、複数のAWSアカウントやアプリケーションへのアクセスが可能になります。

[Identity Centerを用いたシングルサインオンのイメージ]

・AWSアカウントの認証を既存のDirectory Serviceで行えるように、サービスコントロールポリシー（SCP）を構成する→SCPに、Directory Serviceなどの認証基盤と連携する機能はない

認証基盤として既存のDirectory Serviceを使用できるように、AWS Organizationsの設定で直接連携させる
→AWS Organizations自体に、既存のDirectory Serviceと直接連携して認証処理を一元化する機能はない

・AWS Secrets Managerを構成し、既存のDirectory ServiceとAWSアカウントを連携させて認証処理を一元化する
→AWS Secrets Managerは、データベースなどにアクセスする際のシークレット（ログイン時の認証情報など）を管理するサービスです。AWSアカウントの認証情報の管理には使用できない

AWS IAM

AWS IAMとは、AWSにおいて「どのユーザーが」「どのAWSリソースに対して」「どのような操作ができるか（できないか）」を定義する、「認証」「認可」の仕組みを提供するサービスです。
IAMロールは、AWSサービスやアプリケーション、他のAWSアカウントに対してAWSリソースへのアクセス権限を付与する際に利用します。

例えば、EC2インスタンス上で動作するアプリケーションがS3バケットを利用する場合、アプリケーションはアクセスキー及びシークレットキーを使用して認証したのちにS3バケットへアクセスします。しかし、アプリケーションプログラムに認証情報を埋め込むのはセキュリティリスクが高く危険です。
IAMロールを使用すると、このようなリスクを回避できます。IAMロールでは一時的なアクセスキーを生成・使用することにより認証します。生成したアクセスキーは短時間で使用できなくなるため、漏洩してもリスクは高くありません。

また、IAMロールに対して信頼ポリシーを設定することで、他のAWSアカウントやAWSサービスがそのロールに割り当てられた権限を一時的に使用できる（ロールを引き受ける）ようになります。これにより、資格情報を共有することなく、他のアカウントからの安全なアクセスを実現できます。このようなアクセスの仕組みをクロスアカウントアクセスと呼び、引き受けられるIAMロールはクロスアカウントIAMロールとも呼ばれます。

AWS Secrets Manager

AWS Secrets Managerは、データベースなどにアクセスする際のシークレット（ログイン時の認証情報など）を管理するサービスです。アプリケーションなどからAWSリソースへアクセスする際にSecrets Managerからシークレットを取得することにより、ログイン情報をアプリケーションにハードコーディングしたり平文で入力しておく必要がありません。

アプリケーションはSecrets ManagerのAPIを利用して、Secrets Managerに保存されたデータベースのシークレットを取得します。このとき、アプリケーション側には「secretsmanager:GetSecretValue」権限を付与する必要があります。

Lambda関数からSecrets Managerのシークレットを取得する場合も同様に、「secretsmanager:GetSecretValue」権限を付与したIAMロールを設定します。

IAMポリシー

IAMのポリシーのうちリソースベースのポリシーは、AWSリソース（S3バケットやSQSキューなど）に対してアタッチするポリシーです。設問の場合は、Lambda関数に対してポリシーをアタッチして、EventBridgeのイベントルールからのアクセスを許可します。ポリシーについての詳細な説明は、当設問の参考にある【ポリシー】に記載されています。

下記の画像は、EventBridgeのイベントルール「DailyReportEvent」からLambda関数「DailyReportFunction」を呼び出すための、JSON形式の定義例です。

ポリシーには下記の定義をしています。
・Action: Lambda関数の呼び出し「”lambda:InvokeFunction”」
・Resource: Action対象となるLambda関数のARN「”arn:aws:lambda:::function:DailyReportFunction”」
・Principal（プリンシパル）: EventBridgeを表す「”Service”: “events.amazonaws.com”」
・Condition: アクセス権限を付与するEventBridgeのARN「”AWS:SourceArn”: “arn:aws:events:::rule/DailyReportEvent”」

KMS（Key Management Service）

あるAWSアカウントで暗号化されたリソースを別のAWSアカウントで復号したい場合、KMS（Key Management Service）の暗号化鍵を複数のAWSアカウントで使用できます（クロスアカウント）。暗号化されたAMIやデータベースのスナップショットなどを他のAWSアカウントと共有する際に利用します。
鍵を共有するには、共有する対象のAWSアカウントIDを鍵の使用者として追加します。共有できる鍵はカスタマーマネージド型のKMSキーのみです。AWSマネージド型のKMSキーはキーポリシーを編集できないため他のAWSアカウントと共有できません。

また、EC2インスタンスを他のAWSアカウントで利用したりコピーが必要な場合は、AMI（Amazon マシンイメージ）を共有します。プライベートなAMIであっても、共有対象のAWSアカウントIDを入力することで共有できます。

OU（Organizational Unit）

KMSで暗号化されたAMIを共有して利用するためには、次の2つの手順が必要です。
(1)経理OUに属しているアカウントでAMIにアクセスできるようにする
(2)経理OUに属しているアカウントでAMIを復号化できるようにする

(1)経理OUに属しているアカウントでAMIにアクセスできるようにする
AMIは、指定した別のAWSアカウント、組織、特定のOU全体と共有することができます。特定のOU全体と共有する場合、AMIの共有設定に経理OUのAmazonリソースネーム（ARN）を追加することで可能です。

(2)経理OUに属しているアカウントでAMIを復号化できるようにする
共有されたAMIの復号化には、暗号化に使用されたKMSキーが必要です。KMSキーはアカウント単位で管理されているため、直接OU単位で共有することはできません。そのため、経理OUに属する各アカウントに対して、このKMSキーへのアクセス権を設定する必要があります。具体的には、KMSキーポリシーに経理OUの特定アカウントIDのAmazonリソースネーム（ARN）を追加することで共有できます。

この2つの手順により、経理OUに属しているユーザーはAMIにアクセスでき、KMSキーで復号化ができるため、AMIを利用できるようになります。

VPC内のAWSリソースから、S3やDynamoDBなどインターネットから直接利用できるVPC外のAWSサービスへアクセスは、通常インターネットゲートウェイを経由して通信します。「VPCエンドポイント」は、セキュリティ上の制約でインターネットとの通信が制限されているプライベートサブネット内のAWSリソースから、インターネットゲートウェイを経由せずにVPC外のAWSサービスへアクセス可能にする機能です。

VPCエンドポイントにはゲートウェイ型とAWS PrivateLink（インターフェイス型）があり、S3はゲートウェイ型とAWS PrivateLink（インターフェイス型）の両方で利用できます。

[VPCエンドポイント（ゲートウェイ型）でS3やDynamoDBにアクセスする時のイメージ]

[PrivateLinkでCloudWatch LogsやS3にアクセスする時のイメージ]

AWS Organizations

AWS Organizationsでは、組織に対して権限を設定したり、管理するAWSアカウントへの請求情報をひとまとめにすることができます。

組織に属しているOU（Organizational Unit）またはAWSアカウントに対して、利用できるAWSサービスやアクションを制限する「サービスコントロールポリシー（Service Control Policy：SCP）」を設定することもできます。SCPを用いると、例えばテスト用のアカウント（群）は特定のサービスにしかアクセスできないようにしたり、全てのアカウントに対してMFA（多要素認証）を強制するように設定することなどができます。また、SCPを適用する条件(Condition)を設定することで、特定のIAMユーザーまたはIAMロールに対してのみ制限を適用するといった制御も可能です。

AWS Transfer Familyは、AWSストレージ上へのセキュアなファイル転送を実現するマネージドサービスです。SFTP、FTPS、FTPなどをサポートし、Amazon S3およびAmazon EFSへセキュアにファイルの転送が可能です。

Transfer Familyのマネージドワークフローは、ファイルのアップロードやダウンロードをトリガーとして、処理を自動実行できる機能です。実行可能な処理には、ファイルのコピーやタグ付けなど基本的な処理に加えて、Lambda関数の呼び出しがあります。Lambda関数でカスタマイズ可能なアクションを定義し、ファイルをダウンロードしたあとにデータの変換、分析、データベースへの転送などの処理を自動化できます。

Transfer FamilyでSFTPサーバーなどを作成すると、ユーザーがアクセスするための接続エンドポイントが設定されます。エンドポイントには、インターネットからアクセス可能な「パブリックエンドポイント」と、VPCでホストされる「VPCエンドポイント」があります。
VPCエンドポイントは指定したVPC内からアクセス可能なエンドポイントで、「インターネット向け」と「内部向け」があります。パブリックエンドポイントとは異なり、セキュリティグループを使用して接続元を制限することが可能です。また、複数のAZにENIを設定することで、可用性を高めることができます。

この製造企業はすでに各工場からAWSへのVPN接続を確立しています。工場からAWS VPCへのプライベート接続が可能となり、パブリックネットワークを経由せずにVPC内のリソースにアクセスできます。「内部向けVPCエンドポイント」を使用したTransfer FamilyのインターナルSFTPサーバーを利用することで、インターネットを経由せずデータを転送できるためセキュリティを確保できます。また、高い冗長性が求められているため、2つのAZにENIを設定する必要があります。
製造データの保存先としては、耐久性や可用性の点で優れておりコスト効率もよいAmazon S3ストレージが最適です。さらに、製造データの分析処理が必要とされているため、AWS Lambda関数を作成し、Transfer Familyのマネージドワークフローを使用してLambda関数を呼び出すことで、データ分析の自動化を実現できます。

Amazon AppFlow

Amazon AppFlowは、様々なSaaSアプリケーション（例：Salesforce、ServiceNow、Slackなど）と、AWSサービス（例：Amazon S3、Redshift、DynamoDBなど）間でデータを安全に転送できるフルマネージドサービスです。

[AppFlowのフロー設定の流れ]

このサービスは直感的なユーザーインターフェースを提供し、数クリックでデータフローを設定できるため、技術的な専門知識が少ないユーザーでも簡単にデータ転送を実行できます。デフォルトでAWSのKey Management Service（KMS）が有効になっており、データは保存時および転送中に暗号化されます。さらに、AWS PrivateLinkをサポートするSaaSアプリケーションでは、インターネットを介さずにAWSインフラストラクチャを経由したプライベートなデータ転送も可能です。

AWS Lake Formation

AWS Lake Formationは、安全なデータレイクを簡単かつ迅速に構築し、分析に利用できるようにするためのマネージドサービスです。
データレイクとは、データが構造化されているかどうかに関係なく、さまざまな形式の大量のデータを一元的に保存・管理する場所のことを指します。データレイクの構築には、様々なデータソースからのデータの取り込み、標準化およびカタログ化、適切なアクセス権限の設定など、考慮しなければならない事項が多く存在します。AWSでは従来、これらの考慮事項に対応した個別のサービス（Amazon S3、AWS Glue、IAMなど）を手動で組み合わせて実現していましたが、Lake Formationを使用することで、これらを一元的に管理することが可能になります。
Lake Formationでは、IAMの権限設定に加えて、Lake Formation独自の権限管理モデルを持っており、これによりテーブル単位や列単位といった、きめ細かなアクセス制御を行うことができます。

AWS Config

AWS Configは、AWSリソースの設定を管理し、記録・評価するサービスです。AWSリソースの設定がいつ変更されたかを記録し、変更がルールに準拠したものでない場合には「非準拠」として記録されます。

ルールに準拠していないリソースは以下のように列挙されます。

AWS Configを有効化することにより、例えばセキュリティグループの設定が変更された場合や、S3バケットを新たに作成した場合にバージョン管理が有効化されているかなど、様々なリソースの設定状況を監査します。なお、変更があったタイミングでSNSによる通知を受け取ることもできます。

Amazon RDSでは、データベースを所有しているAWSアカウントとは別のAWSアカウントと、データベースのスナップショットを共有できます。
例えば、AWSアカウントを別に持つ部署でデータベースのコピーが必要だったり、新たに作成するAWSアカウントへデータベースを移行したいような場合は、スナップショットを共有し、共有したAWSアカウントでスナップショットからデータベースを復元するといった運用が可能です。

なお、スナップショットが暗号化されている場合は、共有先のアカウントへKMS暗号化キーの使用を許可する必要があります。

AWS WAF（Web Application Firewall）は、脆弱性を突く攻撃（クロスサイトスクリプティングやSQLインジェクションなど）から、Webアプリケーションを保護するサービスです。「Web ACL」というアクセスコントロールリストで、IPアドレス、HTTPヘッダー、HTTP本文、URI文字列などに対してフィルタリングの条件を設定できます。また、Web ACLには接続元のIPアドレスから国別にアクセスを制限できる機能（地理的一致ルール）や、特定の時間内にリクエスト数が設定値を超えたIPアドレスをブロックする機能（レートベースのルール）もあります。

AWS WAFは、Amazon CloudFront、Application Load Balancer、Amazon API Gatewayなどに割り当てて利用します。

ネットワークACLは、VPC内のサブネットレベルでトラフィックを制御します。特定のIPアドレスやIPアドレスの範囲からのトラフィックを許可または拒否するルールを設定できますが、頻繁にIPアドレスが変更されるリクエストに対して、効果的にブロックすることは難しい。

Amazon Macieは、S3バケット内のデータ保護に特化したセキュリティサービスです。機械学習とパターンマッチングを用いて、自動的にS3バケット内のオブジェクトを分析し、個人情報（PII）や秘匿技術などの機密データを識別・分類します。S3バケット内のセキュリティとアクセス制御を継続的に評価し、機密データの未暗号化や不適切な共有、漏洩などの問題について、検知した結果をマネジメントコンソール上に反映します。Macieには、検知結果を直接ユーザへ通知する機能は実装されていないため、ユーザ側での確認が必要です。ユーザ側での確認作業には、運用上のオーバーヘッドの増加や人為的ミス（確認忘れなど）のリスクがあるため、他のAWSサービスと連携することで、ユーザへの通知を自動化することが推奨されています。

通知を設定する一般的なフローは以下の通りです。

 

EBSでは、ボリュームやスナップショットを暗号化することで機密性を高めることができます。暗号化する際はAWS KMS（Key Management Service：暗号化に使用するキーを作成・管理するサービス）を利用します。
暗号化の設定はEBSボリューム作成時に指定します。作成したボリュームの暗号化ステータスは後から変更できません。
暗号化を行うには、事前にKMSにおいて暗号化に使用するキーを作成し「マスターキー」欄へ入力します。

なお、作成済みのEBSボリュームの暗号化ステータスは変更できませんが、スナップショットからEBSボリュームを作り直すことで、既存のデータを保持したまま暗号化ステータスの異なるEBSボリュームを作成できます。

AWS Lake Formation

AWS Lake Formationは、安全なデータレイクを簡単に構築・運用するためのマネージドサービスです。データレイクとは、データが構造化されているかどうかに関係なく、さまざまな形式の大量のデータを一元的に保存・管理する場所のことを指します。データレイクの構築には、様々なデータソースからのデータの取り込み、標準化およびカタログ化、適切なアクセス権限の設定など、考慮しなければならない事項が多く存在します。AWSでは従来、これらの考慮事項に対応した個別のサービス（Amazon S3、AWS Glue、IAMなど）を手動で組み合わせて実現していましたが、Lake Formationを使用することで、これらを一元的に管理することが可能になります。Lake Formationで管理されるデータレイクは、クロスアカウント共有の設定を行うことで、異なるAWSアカウントと簡単かつ安全に共有することができます。Lake Formationでは、テーブル単位や列単位といった、きめ細かなアクセス制御を行うことができます。これにより、異なるアカウントに対して見せたいデータだけを共有することができます。Lake Formationでのアクセス制御の方法には「名前付きリソースでのアクセスコントロール」と「タグ（LFタグ）ベースのアクセスコントロール」の2種類があります。タグベースの方法を使用することで、管理する権限の数を抑えることができます。また、制御対象のリソースが増えた場合でも、リソースに対してタグを付与するだけで済むため、特に、管理するリソースが多い環境において有効な方法として、AWS公式にも推奨されています。

Amazon GuardDuty
AWS全環境内の脅威を自動的に検出し評価するセキュリティサービスです。

Amazon Macieは、S3バケット内のデータ保護に特化したセキュリティサービスです。機械学習とパターンマッチングを用いて、自動的にS3バケット内のオブジェクトを分析し、個人情報（PII）や秘匿技術などの機密データを識別・分類します。S3バケット内のセキュリティとアクセス制御を継続的に評価し、機密データの未暗号化や不適切な共有、漏洩などの問題について、検知した結果をマネジメントコンソール上に反映します。

AWS Secrets Manager

AWS Secrets Managerは、データベースなどにアクセスする際のシークレット（ログイン時の認証情報など）を管理するサービスです。アプリケーションなどからAWSリソースへアクセスする際にSecrets Managerからシークレットを取得することにより、ログイン情報をアプリケーションにハードコーディングしたり平文で入力しておく必要がありません。認証情報をハードコーディング（埋め込み）すると、例えばアプリケーションのソースコードから認証情報を参照できてしまったり、認証情報を更新した際にアプリケーション側の更新漏れが発生するなどのリスクがありました。管理者はSecrets Managerを利用することにより、アプリケーションの安全な認証を実現できるようになります。

Secrets Managerには、シークレットを安全に管理するために、定期的にシークレットを更新する「ローテーション」機能があります。スケジュールに従って、Secrets Managerはローテーション用のLambda関数を自動的に呼び出します。アプリケーションは、更新されたシークレットでその後の認証を行います。
なお、Amazon RDS、Amazon Redshiftなど一部のサービスはSecrets Managerがローテーション用のテンプレートを用意しています。これら以外のサービス向けには、独自でローテーション関数を作成する必要があります。

ローテーションのタイミングは、日・週・月など任意に選択できます。

また、パラメータストア（Parameter Store）はAWS Systems Managerの機能で、複数のサービスのパスワードや運用データを一元管理します。Secrets Managerと同様に、シークレットを外部で管理する用途に利用できます。ただし、パラメータストアにはシークレットの自動ローテーション機能は存在しないため、セキュリティポリシーやシークレットを運用する際の要件に応じて使い分ける必要があります。

AWS WAFは、Amazon CloudFront、Application Load Balancer、Amazon API Gateway、AWS AppSyncに対応しています。Amazon S3では直接AWS WAFを有効にできないので、AWS WAFのWeb ACLを適用するには静的WebサイトホスティングのWebコンテンツへのアクセスをCloudFront経由にします。
CloudFrontのOAI（Origin Access Identity）は、S3バケット内のコンテンツへのアクセスをCloudFront経由でのアクセスに限定し、クライアントからS3バケットへ直接アクセスされないようにする機能です。クライアントからオリジナルコンテンツへの直接アクセスを制限することにより、オリジンサーバーのデータを保護できます。

CloudFrontでWebコンテンツのあるS3バケットにOAIを設定すると、Webコンテンツへのトラフィックが全てCloudFront経由になります。そしてAWS WAFを有効にすることで、全トラフィックにAWS WAFのWeb ACLを適用できます。

AWS Site-to-Site VPN（サイト間VPN）は、カスタマーゲートウェイ（オンプレミスのルーター）とVPCの仮想プライベートゲートウェイ（VGW）を、インターネットVPNで接続するサービスです。Site-to-Site VPNはインターネット上に仮想の専用線であるVPNトンネルを張り、IPsecという暗号技術を使って通信を保護します。

Lambda関数は、Lambda専用のセキュアなVPCに配置されています。このLambda専用のVPCからは、インターネットや、インターネットを経由してパブリックサブネット内のAWSリソースにはアクセスできますが、パブリックに公開されていないAWSリソースへはアクセスできません。

Lambda関数からAWS Site-to-Site VPN経由でオンプレミスのデータベースにアクセスするには、Lambda関数をVGWが接続されているVPCに関連付ける「VPCアクセス」の設定をします。VPCアクセスを設定すると、Lambda関数に関連付けたVPCのサブネットに接続用のENI（Elastic Network Interface）を作成してサブネットへアクセスできるようになります。VPCアクセスを設定したLambda関数は、ENIを作成したサブネットへアクセスできるようになる代わりに、インターネットへアクセスできなくなります。

アクセス先のVPCにはデフォルトルートがVGWに設定されているので、Lambda関数はVGWを介してAWS Site-to-Site VPNを経由し、オンプレミスのデータベースに接続できます。また、VPCアクセス設定で、Lambda関数がオンプレミスのデータベースと通信できるように、セキュリティグループに適切な設定をします。

[Lambda関数のVPCアクセス設定画面]
VPCアクセスでは、アクセス先のVPCとサブネット、Lambda関数のセキュリティグループを設定します。

WAFはAPI Gatewayを保護できますが、NLBはサポートしていません

オンプレミスなどのユーザー環境からAWSへ接続する場合、通常はインターネット回線を経由します。しかし、インターネット回線は不特定多数の利用者と回線を共用するため、通信内容の傍受やデータの改ざんなどのリスクがあります。AWS Direct Connect（DX）はオンプレミスなどのユーザー環境からAWSへ、専用回線を使ってセキュアに接続するサービスです。インターネット回線ではなく専用回線を敷設して使用するので、安定した高速なネットワークで接続できます。

AWS DataSyncは、オンプレミスとAWS間、またはAWSストレージ間のデータ転送サービスです。対応するAWSのストレージにはAmazon S3やAmazon EFS、Amazon FSxなどがあります。オンプレミスとAWS間で通信するためには、オンプレミスにDataSyncエージェントを導入します。

ECSにおける「タスク」「サービス」「クラスター」

Amazon ECSの主要要素に「クラスター」「タスク」「サービス」があります。そのうちの「タスク」はECSで管理するコンテナの実行単位です。タスク内のコンテナは、実行するコンテナイメージ、CPUやメモリのスペック、タスクロールなどを定義した「タスク定義」に基づいて起動します。なお、タスクロール（taskRoleArn）とは、コンテナが他のAWSサービスを利用する際に設定するアクセス権限（IAMロール）のことです。

[ECSにおける「タスク」「サービス」「クラスター」の関連図]

設問のケースでは、ECSのコンテナからRDSデータベースのデータを読み取りたいので、RDSデータベースへの読み取り権限があるIAMロールを作成し、タスク定義のタスクロール（taskRoleArn）に指定します。

[タスク定義の設定画面]

Amazon S3にはバケットに保存している静的コンテンツ（HTMLやJPGなど）をWebサイトとして公開できる「静的Webサイトホスティング」機能があります。サーバーレスでWebサイトを公開できるので、運用負荷が低くなります。S3バケットにはAWS CLIやAWS マネージメントコンソールなどを使用してコンテンツを更新できます。
下記の例は、AWS CLIの「s3 cp コマンド」を使用して、S3バケット（pingt-aws-test）に新しいファイル（newfile.html）をアップロードしています。

Amazon CloudFrontのOAI（Origin Access Identity）は、S3バケット内のコンテンツへのアクセスをCloudFront経由でのアクセスに限定し、ユーザーからS3バケットへ直接アクセスされないようにする機能です。CloudFrontのOAIに設定されたS3バケットは、プライベートS3バケットであってもCloudFront経由に限りインターネットからアクセスできるようになります。プライベートS3バケットを作成し、OAIを設定することで、S3バケットのデータを保護しながらインターネットにWebサイトを公開できます。

API Gatewayで作成したAPIへアクセスするためのURLに、独自ドメイン名を設定することができます。独自ドメイン名を使用する場合、API Gateway側で独自ドメイン名の作成時に、AWS Certificate Manager（ACM）で管理されるSSL/TLS証明書を選択します。この時に使用する証明書は、APIのエンドポイントタイプによって異なる場合があります。リージョン別のエンドポイントを使用している場合には、同じリージョンのACMで発行またはインポートされた証明書を使用します。

また、APIへアクセスするためのURLにワイルドカードを含んだ独自ドメイン名を使用することもできます。これにより、1つの独自ドメイン名を作成するだけで、「aaa.example.com」や「bbb.example.com」のようにサブドメインの異なる複数の独自ドメイン名をサポートすることが可能になります。この場合、指定する証明書も、ドメイン名にアスタリスクを含むワイルドカード証明書である必要があります。また、DNSサーバ（本設問ではRoute 53）側のDNSレコードも、ワイルドカードを用いた独自ドメイン名を登録します。

[独自ドメイン名の設定画面]

S3のアクセス制御方法には「バケットポリシー」「ユーザーポリシー」「ACL」がありますが、S3バケットへのアクセス元をVPCエンドポイントに限定するには「バケットポリシー」を利用します。バケットポリシーはバケット単位でアクセス権限を設定する機能です。
特定のVPCエンドポイントからの通信のみを許可するには、「VPCエンドポイントID」を指定して通信を許可します。

上記の設定では、S3バケットの「A-bucket」に対して、VPCエンドポイントの「vpce-A」からの通信を許可しています。

次に、VPCエンドポイントが特定のS3バケットへのアクセスのみ許可する方法について考えます。
VPCエンドポイントを作成すると、VPC内のリソースはVPCエンドポイントからVPC外のAWSサービスへアクセスできるようになります。VPCエンドポイントの接続先を制限するには「VPCエンドポイントポリシー」を使用します。VPCエンドポイントポリシーは、VPCエンドポイントのゲートウェイ型とAWS PrivateLink（インターフェイス型）の両方で利用できます。
特定のS3バケットへの通信のみを許可するには、S3バケットのAmazonリソース名（ARN）を指定します。

上記の設定では、S3バケットの「A-bucket」への通信を許可しています。

AWS Security Token Service（STS）は、AWSリソースへのアクセスを必要とするユーザーやアプリケーションに対して、一時的なセキュリティ認証情報を提供するサービスです。この認証情報は、最短15分から最長36時間の有効期限が設定されており、期限が切れると自動的に無効化されます。

STSは、企業の既存の認証システム（例：LDAP、Active Directoryなど）と連携して、AWS IDを新たに作成することなく、既存のユーザーに対してAWSリソースへのアクセスを許可できます。この機能は、ユーザーが複数のシステム間でシングルサインオン（SSO）を実現する際に特に有用で、ユーザーはさまざまなシステムに対して一貫したアクセスが可能です。

一般的に、既存の認証システムを利用してSSOを実現する場合、SAML（Security Assertion Markup Language）がよく使われます。SAMLは、セキュリティ認証情報を交換するためのXMLベースの標準フォーマットであり、異なるセキュリティドメイン間でユーザー認証と承認データを安全に交換するために使用されます。AWSでは、AWS IAM Identity CenterがSAMLを使用したフェデレーション（SSOを実現する技術）をサポートしています。
しかし、本設問では、使用されているADがSAMLと互換性がないため、代替手段としてカスタムIDブローカーアプリケーションの開発が必要です。カスタムIDブローカーは、異なる認証システム間で橋渡しを行い、STSを利用して一時的なAWS認証情報を取得することで、AWSへのセキュアなアクセスを実現します。

[カスタムIDブローカーアプリケーションを使用した場合の図]

Service Control Policy

AWS Organizationsのサービスコントロールポリシー（Service Control Policy：SCP）を用いることで、組織に属しているOU（Organizational Unit）またはAWSアカウントに対して、利用できるAWSサービスやアクションを制限することができます。SCPを用いることで、本設問の要件を満たす設定を行うことができます。

また、AWS Control Towerで提供されているガードレール（コントロールとも呼ばれます）を用いても、本設問の要件を満たす設定を行うことができます。
ガードレールとは、AWSにおけるベストプラクティスに基づいた構成や設定、ルールの組み合わせが事前定義されたものです。管理者は、セキュリティやコンプライアンスの要件にあわせてこれらを選択し適用することで、各アカウントに対する設定や適用するルールにばらつきが生じることを防ぎ、統制のとれたマルチアカウント環境を容易に展開することができます。

本設問の要件を満たすために適切なガードレールは、データレジデンシーガードレールです。データレジデンシーガードレールは、データの保存場所や処理場所に関する制限をかけることを主な目的としたガードレールです。このガードレールを用いることで、特定のリージョン以外の使用を禁止したり、VPCをインターネットから隔離するといった設定が可能です。

ルートテーブルの設定によりネットワークトラフィックの制御を行うことはできますが、リージョン全体のアクセス制御を行うことはできません。

AWS Systems Managerは、複数のAWSリソースをグループ化し、グループ内リソースの運用データの一元化や運用タスクの自動化などができる運用管理サービスです。使用できるリージョンの制限やVPCのインターネットアクセス制御とは直接関係がない。

AWS Network Firewall

 AWS Network Firewallは、VPC向けのファイアウォール機能を提供するマネージドサービスです。侵入防止システム（IPS）やドメイン名によるトラフィックのフィルタリングなど、セキュリティグループやネットワークACLよりもさらに高度な機能を備えています。Network Firewallは、VPC上のアウトバウンド及びインバウンド両方のトラフィックを検査できます。インターネット上の特定のドメイン名を含むURLへのアクセスのみを許可したり、特定の送信元からのトラフィック以外は全てブロックするなど、きめ細かな通信の制御が可能です。

プライベートサブネットのルートテーブルでファイアウォールエンドポイントにルーティングし、ファイアウォールサブネットのルートテーブルでNATゲートウェイにルーティングすることで、プライベートサブネットとインターネット間の通信をNetwork Firewallで制御できます。

AWS Organizationsを使用して複数のAWSアカウントを管理する企業が、特定の組織に属するユーザーのみAmazon EC2インスタンスにアクセスできるようにする方法を求めています。また、運用の負担を最小限に抑えることも重要な要素です。

条件キーは、特定の条件に基づいてアクセス制御を行うためにポリシーのCondition要素の中で使用されます。条件キーを使用することで、ポリシーの許可や拒否を具体的な条件で細かく制御し、アクセス権を詳細に管理できます。条件キーのうち、グローバル条件キーは”aws:”で始まり、すべてのAWSサービスに対して共通して使用できます。一方、サービス固有の条件キーは、サービス固有の名前（例”s3:”）で始まります。
グローバル条件キーには、組織全体にわたるアクセスを制御する組織ID(aws:PrincipalOrgID)、組織ユニットの階層を指定し特定の部門やグループに対する細かいアクセスを制御する組織パス(aws:PrincipalOrgPaths)、タグに基づいてアクセスを制御するプリンシパルタグ(aws:PrincipalTag)などがあります。

この設問の場合、グローバル条件キーのaws:PrincipalOrgID（組織ID）を指定することで、特定の組織IDを持つプリンシパル（IAMユーザー、グループ、ロール、またはAWSサービス）のみにリソースへのアクセスを許可することができます。OU（Organizational Unit）やタグを使った細かな制御と比較して、ポリシー管理がシンプルであり、大規模な組織での運用負担を軽減します。組織全体を対象とした

一括のアクセス制限を実施するため、個々のアカウントやユーザーに対する個別のアクセス設定を行う必要がなくなり、管理が容易になります。

IAMロールのアクセスポリシーに組織IDを指定したaws:PrincipalOrgIDグローバル条件キーを追加する。これをEC2インスタンスにアタッチする

[aws:PrincipalOrgIDグローバル条件キーの使用例]

Lambda関数からサーバーやデータベースへアクセスする際、認証が必要になるケースがあります。このとき、ユーザーIDやパスワードなどの認証情報はソースコードに埋め込む（ハードコーディング）するべきではありません。ソースコードが漏洩した場合にユーザーが乗っ取られたり、認証情報を更新した際にいくつものソースコードを更新する手間が発生するなど、セキュリティ上のリスクが高くなるためです。

Lambda関数で安全に認証を行う手段として、KMSを利用する方法があります：
– Lambda関数にKMSで暗号化した認証情報を埋め込む
– 関数呼び出し時に、認証情報を復号する

なお、Lambda関数にはKMSで復号するためのポリシー「kms:decrypt」をアタッチする必要があります。

IAM（Identity and Access Management）では、IAMユーザーやIAMロールに対して「ここまでの範囲内であれば自由に操作を行える」という境界を設定できます。これを「Permissions Boundary（アクセス許可境界）」と呼びます。アクセス許可境界が設定されたユーザーは、境界で許可された範囲とIAMポリシーの両方で許可されている範囲でアクションを行えます。

アクセス許可境界は、例えばLambda関数の作成をしている開発者に対して、必要なリソースへのアクセス権は都度自由に設定できるようにしておきたいが、開発者自身のアクセス権を操作させたくないようなケースで有用です。開発者にある程度の権限を与えておくことにより、アクセス権が必要になった際にいちいち管理者が対応する必要がなくなります。一方、権限を超えた操作をしないようにアクセス許可境界を設定しておけば、セキュリティリスクも抑えられます。

本設問は、自分のIAMユーザーに対して想定以上の権限を付与することが可能であることに気付いたケースです。IAMユーザーには必要以上の権限を与えるべきではありません。Well-Architected Frameworkの「セキュリティ」の設計原則の1つに以下があります：
　強力なアイデンティティ基盤を実装する … 最小権限の原則を実装し、AWSリソースの使用に適切な認証をします。最小権限の原則とは、ユーザーやプログラムが作業を完遂するために必要な最低限の権限で操作を行うことです。
例えばユーザーの認証情報が漏洩し乗っ取られた場合、この設計原則が徹底されていれば、被害の範囲を最小限に留めることができます。
本設問のケースでは、Lambda関数の開発においてIAMのアクセス権限の操作権は必要です。自分のIAMユーザーのIAMポリシーを設定できないように、セキュリティ管理者にアクセス許可境界を設定してもらうのがよいでしょう。セキュリティ管理者にIAMのアクセス許可境界（Permissions Boundary）の設定を依頼します。

パブリックサブネットにはインターネットから直接アクセスされるAWSリソースを配置し、プライベートサブネットにはインターネットから直接アクセスされないAWSリソースを配置します。サブネットの設定にパブリックサブネットやプライベートサブネットという選択はなく、インターネットゲートウェイへのルーティング設定があるサブネットは、パブリックサブネットの役割を持ちます。

ALBはAWSが提供する負荷分散（ロードバランシング）のサービスです。ALB配下にアプリケーションサーバー（設問の場合はEC2インスタンス）がある場合は、ALBをパブリックサブネットに配置しアプリケーションサーバーをプライベートサブネットに配置することで、アプリケーションサーバーのセキュリティを高めることができます。また、DBサーバーであるRDSインスタンスは基本的にプライベートサブネットに配置します。

設問のようなALB、EC2インスタンス、RDSインスタンスの3階層で構成されているシステムは、パブリックサブネットにALB、プライベートサブネットにEC2インスタンスとRDSインスタンスを配置することで、セキュリティを高められます。

Amazon CloudFrontには、「地理的制限」というクライアントからのアクセスを国別に制限できる機能があります。クライアントの接続情報から接続元の国を判別して、ホワイトリストに設定した国からのアクセスは許可、ブラックリストに設定した国からのアクセスは拒否します。例えば、特定の国に対して法律上の理由でコンテンツの配信ができない場合などに利用します。

また、AWS WAF（Web Application Firewall）の「Web ACL」にも地理的制限と同等の機能があります。AWS WAFは、脆弱性を突く攻撃（クロスサイトスクリプティングやSQLインジェクションなど）から、Webアプリケーションを保護するサービスです。Amazon CloudFront、Application Load Balancer、Amazon API Gateway、AWS AppSyncに割り当てて利用します。

Lambda関数には実行ログを出力するために、CloudWatch Logsへのアクセス権限が割り当てられています。デフォルトではCloudWatch Logs以外へのアクセス権限はないので、Lambda関数から他のAWSサービスへアクセスさせたい場合はアクセス権限の設定が必要です。Lambda関数のアクセス権限は、他のAWSサービスへのアクセス権限を持つIAMロールによって付与します。その際、Well-Architected Frameworkの「最小権限の原則」に基づき、コード実行に必要な最低限の権限のみ割り当てることが推奨されています。

[Lambda関数に他のAWSサービスへのアクセス権限を割り当てる時のイメージ]

AWSサービスが使用するIAMロールには、そのAWSサービスに対する信頼関係が設定されている必要があります。本設問であれば、IAMロールの作成時に信頼されたエンティティとしてLambdaを指定することで、LambdaはそのIAMロールを引き受けて使用することが可能になり、必要なアクセス権限（DynamoDB及びS3へのアクセス権限）を得ることができます。

[マネージメントコンソールからIAMロールを作成する場合の例（信頼されたエンティティの種類を選択）]

Amazon EKSでは、コントロールプレーン内のKubernetes APIサーバが、データプレーン内のノードや管理ツール(kubectl)からの通信を受け付け、クラスター全体の管理や制御を行います。このAPIサーバへの通信は、EKSクラスタの構成時に作成されるクラスターエンドポイントを介して行われますが、このエンドポイントは、デフォルトでインターネットからアクセスが可能な状態です。
コントロールプレーンとのやりとりをVPC内のプライベートな通信に限定し、インターネットを経由した通信（パブリックアクセス）を制限することで、セキュリティを向上させることができます。

このエンドポイントアクセスをプライベートに設定した環境で、プライベートサブネット内のノードからコントロールプレーンにプライベートネットワーク経由で通信を行うためには、AWS PrivateLink(インターフェース型のVPCエンドポイント)が必要です。

EKSクラスタ内の設定情報や各リソースの状態情報、シークレット(例:ログイン認証情報)などの情報は、コントロールプレーン内の専用のデータストア(etcd)に格納されます。etcdのデータはデフォルトでAWSによってディスクレベルで暗号化されますが、さらに強力なセキュリティの確保が求められる場合には、「シークレットの暗号化」オプションを有効にすることで、機密情報に対する追加の暗号化を行うことができます。

・EKSクラスタ作成時に、シークレットの暗号化オプションを有効にする

 AWS Firewall Managerは、複数のAWSアカウントやサービスを対象に、firewallのルールを一元的に設定・管理するセキュリティ管理サービスです。セキュリティルールを中央で一元的に管理することにより、セキュリティ対策の手間とコストを削減します。

不特定多数のユーザーがアクセスするWebサービスには、インターネットからの攻撃に対して保護が必要です。AWSではAWSリソースを保護するためのサービスとして「AWS WAF」と「AWS Shield」が提供されています。
そのうちのAWS Shieldは、DDoS攻撃からの保護に特化したサービスです。AWS Shieldには、すべてのAWSユーザーが無償で利用できる「AWS Shield Standard」と、有償版の「AWS Shield Advanced」があります。

○AWS Shield Standard
ネットワーク層およびトランスポート層への一般的なDDoS攻撃からAWSリソースを保護します。デフォルトで有効になっています。

○AWS Shield Advanced
EC2インスタンス、Elastic Load Balancing、Amazon CloudFrontなどを標的としたDDoS攻撃に対して、高度な保護サービスを利用できます。例えば、高度化された大規模な攻撃からの保護、DDoS攻撃発生時のモニタリングやレポート、AWSのDDoS対応チームによるサポート、攻撃によって増加したAWS利用料金の補填などがあります。

本ケースでは、高度で大規模なDDoS攻撃から保護したいと考えているので、Shield Advancedを使用する方法が最もセキュリティ効果が高いです。 Shield AdvancedはELB（ALB、NLB、CLB）を保護の対象にできます。

Shield AdvancedはAPI Gatewayをサポートしていません。

暗号化されたEBSスナップショットによってバックアップされたAMIを共有する場合、AMIの共有設定（launchPermission）と、スナップショットの暗号化に使用したKMSキーの使用の許可設定が必要です。

AMIの共有設定では、共有アカウントに対象のAWSアカウントを追加します。

KMSキーの使用許可設定では、「キーポリシー」で対象のAWSアカウントに許可設定を追加します。下記の画像はAWSアカウント[123456789000]のルートユーザーにKMSキーの使用を許可しています。

CloudWatchのダッシュボードは「ダッシュボードの共有」機能を使用することで、AWSアカウントを持たない相手と共有することが可能です。これにより、新規にAWSアカウントやIAMユーザーを作成することなく、共有先のEメールアドレスを指定して、普段AWSを利用していないメンバーや社外の関係者とダッシュボード上の情報を簡単に共有することができます。

また、「ダッシュボードの共有」機能を使用した場合、共有を受けたメンバーにはそのダッシュボードの情報を参照するために必要な最小限の権限のみが自動的に付与されます。CloudWatchダッシュボード以外のリソース（ログやアラームの定義など）に対するアクセス権限は付与されないため、最小権限の原則に則った安全な共有を実現することができます。

AWS Secrets Managerは、データベースなどにアクセスする際のシークレット（ログイン時の認証情報など）を管理するサービスです。アプリケーションなどからAWSリソースへアクセスする際にSecrets Managerからシークレットを取得することにより、ログイン情報をアプリケーションにハードコーディングしたり平文で入力しておく必要がありません。
認証情報をハードコーディングすると、例えばアプリケーションのソースコードから認証情報を参照できてしまったり、認証情報を更新した際にアプリケーション側の更新漏れが発生するなどのリスクがありました。管理者はSecrets Managerを利用することにより、アプリケーションの安全な認証を実現できるようになります。

Secrets Managerには、シークレットを安全に保存するための「ローテーション」機能があります。
ローテーションを有効にすると、Secrets Managerはスケジュールに基づいてLambda関数を内部的に呼び出し、シークレットを定期的に更新します。これにより、万一シークレットが漏洩してしまった際の被害を低減することができます。

Amazon Cognitoは、モバイルアプリケーションやWebアプリケーション向けのユーザー認証機能を提供するサービスです。新たにユーザー登録を行ったり、外部のIDプロバイダ(Facebook、Google等)と連携したユーザー認証、およびユーザーの管理を行えます。

Amazon Cognitoを構成する主なコンポーネントに「ユーザープール」と「IDプール」があります。

ユーザープールは、ユーザーの認証と管理を行うコンポーネントで、ユーザーのサインアップやサインイン、パスワードリセットなどの基本的な機能を提供します。
IDプールは、認証済みのユーザーに対する認可を行います。認証時の属性情報に応じて、事前に定義したIAMロールが割り当てられ、このIAMロールに付与された権限に基づいて、AWSの各種サービスにアクセスできる一時的な認証情報が発行されます。

Amazon Cognitoは、モバイルアプリケーションやWebアプリケーション向けのユーザー認証機能を提供するサービスです。新たにユーザー登録を行ったり、外部のIDプロバイダ(Facebook、Google等)と連携したユーザー認証、およびユーザーの管理を行えます。

Amazon Cognitoを構成する主なコンポーネントに「ユーザープール」と「IDプール」があります。

ユーザープールは、ユーザーの認証と管理を行うコンポーネントで、ユーザーのサインアップやサインイン、パスワードリセットなどの基本的な機能を提供します。
IDプールは、認証済みのユーザーに対する認可を行います。認証時の属性情報に応じて、事前に定義したIAMロールが割り当てられ、このIAMロールに付与された権限に基づいて、AWSの各種サービスにアクセスできる一時的な認証情報が発行されます。

本設問では、ログインには成功しているがDynamoDBにアクセスできていないということから、IDプールから発行された一時的な認証情報に適切な権限が含まれていない可能性が考えられます。

AWS Transfer Familyは、AWSストレージ上へのセキュアなファイル転送を実現するマネージドサービスです。SFTP、FTPS、FTPなどをサポートし、Amazon S3およびAmazon EFSへセキュアにファイルの転送が可能です。Transfer Familyには独自の認証機能があり、SFTPユーザーのアカウント作成・管理ができます。

Transfer FamilyでSFTPサーバーなどを作成すると、ユーザーがアクセスするための接続エンドポイントが設定されます。エンドポイントには、インターネットからアクセス可能な「パブリックエンドポイント」と、VPCでホストされる「VPCエンドポイント」があります。
「インターネット向けVPCエンドポイント」は、Elastic IPアドレスをVPCエンドポイントに関連付けることで、インターネットからパブリックサブネットを経由してアクセスします。パブリックエンドポイントとは異なり、セキュリティグループを使用して接続元を制限することが可能です。

API Gatewayのオーソライザーを使用すると、APIへのアクセス制御を実装することができます。オーソライザーには、Amazon Cognitoのユーザープールを使用する方法と、Lambda関数を使用する方法があります。
前者は、Amazon Cognitoが提供するマネージド型の認証機能を使用するため、開発者は認証プロセスについて自身で管理する必要がありません。
後者は、開発者自身が認証プロセスをLambda関数で作成する必要があります。独自のロジックでAPIへのアクセス制御を実装できるため柔軟性は高くなりますが、セキュリティ対策など管理の複雑さが増加します。

Amazon Cognitoは、モバイルアプリケーションやWebアプリケーション向けのユーザー認証機能を提供するサービスです。新たにユーザー登録を行ったり、外部のIDプロバイダ（Facebook、Google等）と連携したユーザー認証、およびユーザーの管理を行えます。
ユーザープールは、Cognitoユーザーの認証と管理を行うコンポーネントです。認証が完了するとトークンが発行され、アプリケーション側でのユーザーの識別や、Amazon API Gatewayへのアクセス制御などに使用することができます。

[Cognitoユーザープールを使用したオーソライザーでのアクセス制御のイメージ]

VPCピアリング

VPCピアリングとは、VPC間のルーティングを可能にする機能です。他のAWSアカウントのVPCや異なるリージョンのVPC、同一アカウントの異なるVPCでも、同一のプライベートネットワーク内に存在しているかのように、相互に通信できます。

なお、異なるリージョンのVPC間におけるセキュリティグループの設定には、一部、制限があります。別リージョンのVPCのセキュリティグループをインバウンドルール内で指定することはできないため、代わりに、VPCのCIDRブロックを指定する必要があります。