AWS ソリューションアーキテクト アソシエイト セキュアな設計 問題

正解は「ルートユーザーに MFA を設定し、アクセスキーは作らず、日常の作業は別の ID で行う」です。ルートユーザーはアカウントのすべての操作ができるため、IAM のベストプラクティスでは MFA を加えてサインインを守り、ルートユーザーのアクセスキーは作らないことを勧めています。日常の作業は IAM ロールなど権限を絞った ID で行い、ルートユーザーは本当に必要な作業だけに使います。ルートユーザーのアクセスキーを作ってスクリプトに埋め込む案は、漏れたときの被害が最も大きい長期の認証情報を増やすので要件に合いません。パスワードを全員で共有する案は、必要な人以外に渡さないという原則に反し、乗っ取りの危険を上げます。ルートユーザーで日常の作業を続ける案は、2 つ目の要件にそのまま反します。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/root-⁠user-⁠best-⁠practices.html

正解は「本番アカウントにツールアカウントを信頼するデプロイ用ロールを作り、パイプラインが AssumeRole で引き受ける」です。アカウントをまたぐアクセスでは、使われる側 (本番) にロールを作り、信頼ポリシーで使う側 (ツールアカウント) を信頼されたエンティティに指定します。パイプラインは STS の AssumeRole で一時的な認証情報を受け取るので、本番の長期の鍵をほかのアカウントに置かずに済み、ロールの権限もデプロイに要る範囲に絞れます。アクセスキーを 3⁠0 日ごとに作り直す案は、長期の鍵をツールアカウントに置き続けるので指摘を解消しません。IAM グループに入れられるのは同じアカウントの IAM ユーザーだけなので、ほかのアカウントのユーザーを入れる案は成り立ちません。ルートユーザーのアクセスキーを保存する案は、最も強い長期の鍵を外に置くことになるので要件に合いません。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-⁠account-⁠with-⁠roles.html

正解は「SCP は管理アカウントに効かないため、そのワークロードをメンバーアカウントへ移す」です。SCP はメンバーアカウントの IAM ユーザーとロールだけに効き、管理アカウントのユーザーやロールには効きません。そのため Organizations のベストプラクティスでも、管理アカウントにはワークロードを置かず、そこで管理しなければならないリソースだけに絞るよう勧めています。検証用の EC2 をメンバーアカウントへ移せば、組織のルートに付けた SCP の統制の中に入ります。同じ SCP を管理アカウントに直接付け直しても、管理アカウントには効かないので結果は変わりません。反映を待つ案は、効かない理由が時間ではないので解決しません。ルートユーザーに MFA を設定する案は、サインインを守る対策で、リージョンの制限とは関係がありません。出典 https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-⁠practices_mgmt-⁠acct.html

正解は「IAM Identity Center に既存の IdP をつなぎ、職務ごとの許可セットを作ってアカウントに割り当てる」です。IAM Identity Center は既存の IdP をつないでユーザーとグループを取り込めるので、職員の ID を AWS 側で作り直さずに済みます。さらに許可セットを使うと、管理者などの職務ごとの権限を一か所で定義し、組織の複数のアカウントに配ってユーザーやグループに割り当てられます。各アカウントに IAM ユーザーを作る案は、2⁠5 のアカウントで ID を二重に持つことになり、1 つ目の要件に反します。1 つのアカウントの IAM ユーザーからアクセスキーで入る案も ID を二重に持ち、長期の鍵まで増やします。Cognito ユーザープールはアプリの利用者向けの仕組みで、職員が AWS アカウントを使うための入口ではなく、ID も二重になります。出典 https://docs.aws.amazon.com/singlesignon/latest/userguide/what-⁠is.html

正解は「S3 と DynamoDB に絞った管理ポリシーを権限境界とし、その境界を付けたロールだけ作れるよう許可する」です。権限境界は、IAM のユーザーやロールが持てる最大の権限を決める仕組みで、それ自体は権限を与えません。開発チームに、この境界を付けたときだけロールを作れる条件付きの権限を渡し、境界のポリシー自体は変えられないようにすれば、審査なしで作らせても S3 と DynamoDB を超える権限は持てません。IAM のすべての操作を許可して毎週点検する案は、作った時点では何も止められず、自分の権限も広げられるので要件に合いません。IAM の操作を一切許可しない案は、ロールを自分で作るという前提が成り立ちません。SCP で組織全体を絞る案は、ほかのチームやアカウントまで巻き込み、目的に対して影響が大きすぎます。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

正解は「Control Tower でランディングゾーンを作り、コントロールを有効にしてアカウントファクトリーで払い出す」です。Control Tower は、ベストプラクティスに沿った複数アカウントの環境 (ランディングゾーン) を用意し、Organizations などのサービスをまとめて組み立てます。予防や検出のコントロールで決まりを守らせ、アカウントファクトリーで作ったアカウントにはそれらが自動で適用されます。Organizations だけを作ってスクリプトで整える案は、仕組みを自作することになり 3 つ目の要件に反します。1 つのアカウントを VPC で分ける案は、部門ごとにアカウントを分けるという方針に合いません。各部門が自分で作って月に 1 度点検する案は、新しいアカウントに決まりが自動で効かず、2 つ目の要件を満たしません。出典 https://docs.aws.amazon.com/controltower/latest/userguide/what-⁠is-⁠control-⁠tower.html

正解は「職務ごとに IAM グループを作って権限のポリシーを付け、職員をグループに入れる」です。IAM のユーザーグループは IAM ユーザーの集まりで、グループに付けた権限はそこに入っているユーザー全員に効きます。職員が異動したときは、ユーザーの権限を書き換える代わりに、前のグループから外して新しいグループに入れるだけで権限が切り替わります。全員に管理者の権限を付ける案は、最小権限の原則に反し、職務ごとの権限という要件も満たしません。手順書で手作業の書き換えを続ける案は、今の漏れの原因をそのまま残します。グループを上位のグループに入れる案は、IAM のグループは入れ子にできず、ユーザーしか入れられないので成り立ちません。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html

正解は「条件キー PrincipalOrgID に自社の組織 ID を指定して読み取りを許可する」です。グローバル条件キーの PrincipalOrgID は、リソースベースのポリシーで組織のすべてのアカウント ID を並べる代わりに使える仕組みで、組織 ID を指定すると、その組織に属するアカウントのプリンシパルだけが条件に合います。アカウントが増えても組織に入れば自動で対象になるので、バケットポリシーを書き換えずに済みます。アカウント ID を並べる案は、増えるたびに書き換えが要るので 1 つ目の要件に反します。パブリックにする案は、URL を知った組織の外の人も読めるので 2 つ目の要件に反します。SCP は権限の上限を決めるだけで、それ自体は何も許可しないため、読み取りを許可する手段になりません。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-⁠keys.html

正解は「ロールとリソースに同じ project タグを付け、タグが一致するときだけ許可するポリシーを作る」です。これは属性ベースのアクセス制御 (ABAC) で、プリンシパルのタグとリソースのタグが一致するときに許可する少数のポリシーで済みます。新しいプロジェクトでは、ロールとリソースに新しいタグの値を付けるだけで権限が効くので、既存のポリシーを書き換えずに済み、開発者は自分のプロジェクトのタグが付いたリソースだけを操作できます。プロジェクトごとにグループとポリシーを作る案は、増えるたびにポリシーを足す今の運用と同じで 1 つ目の要件に反します。広い権限を付けて事後に確かめる案は、ほかのプロジェクトへの操作を止められず 2 つ目の要件に反します。アカウントを分ける案は、アカウントを 1 つのまま運用するという条件に反します。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-⁠based-⁠access-⁠control.html

正解は「EC2 のゲスト OS と MySQL に、セキュリティパッチを当てて更新する」です。責任共有モデルでは、AWS はホストの OS と仮想化のレイヤーから施設の物理的なセキュリティまでを運用し、管理します。一方で EC2 は IaaS に当たるため、利用者がゲスト OS (更新とセキュリティパッチを含む) と、その上のアプリやデータベースの管理を受け持ちます。物理ホストの OS と仮想化のレイヤーへのパッチは、AWS が受け持つクラウドそのもののセキュリティなので、病院の作業ではありません。データセンターの入退室の管理も、施設の物理的なセキュリティとして AWS の責任です。リージョンをつなぐネットワーク機器の設定も AWS の基盤の一部で、利用者は触れません。出典 https://aws.amazon.com/compliance/shared-⁠responsibility-⁠model/

正解は「ALB のセキュリティグループをソースに指定して 8⁠0 番を許可する」です。セキュリティグループのルールでは、ソースに別のセキュリティグループを指定できます。そうすると、そのセキュリティグループが付いたリソースのプライベート IP アドレスからの通信だけが許可されるため、ALB のノードや EC2 の IP アドレスが変わってもルールを書き換えずに済みます。0.0.0.0/0 を許可する案は、ALB を通らない通信も受け付けるので 1 つ目の要件に反します。ALB の IP アドレスを調べて登録する案は、アドレスが変わるたびに書き換えが要り 2 つ目の要件に反します。ALB のサブネットの CIDR を許可する案は、同じサブネットにある別のサーバーからの通信も通してしまいます。出典 https://docs.aws.amazon.com/vpc/latest/userguide/security-⁠group-⁠rules.html

正解は「AWS WAF のウェブ ACL に SQL データベース用のマネージドルールグループを入れ、ALB に付ける」です。AWS のマネージドルールの SQL データベース用ルールグループは、SQL インジェクションに使われるリクエストのパターンをブロックするルールの集まりで、クエリの値や本文を検査します。ウェブ ACL を ALB に付ければ、アプリを改修せず、ルールを自分で書かずに手前で止められます。Shield Standard は DDoS 攻撃から守る仕組みで、SQL インジェクションのようなリクエストの中身の検査はしません。セキュリティグループには拒否のルールが無く、許可だけを書く仕組みなので、この案は成り立ちません。GuardDuty は脅威を検出して知らせるサービスで、リクエストを手前で止める役目は持ちません。出典 https://docs.aws.amazon.com/waf/latest/developerguide/aws-⁠managed-⁠rule-⁠groups-⁠use-⁠case.html

正解は「ALB をパブリックサブネットに、EC2 をプライベートサブネットに置き、通信は ALB 経由で受ける」です。本番向けの VPC の例では、ロードバランサーのノードをパブリックサブネットに、サーバーをプライベートサブネットに置き、サーバーはロードバランサーを通してリクエストを受けます。こうすると EC2 はインターネットから直接たどり着けないまま、利用者の HTTPS は ALB で受け付けられます。EC2 をパブリックサブネットに置いてパブリック IP を付ける案は、インターネットから直接つながるので 1 つ目の要件に反します。プライベートサブネットにインターネットゲートウェイへのルートを足す案は、そのサブネットを実質パブリックにしてしまいます。両方をプライベートサブネットに置く案は、利用者の通信を受ける入口がなくなります。出典 https://docs.aws.amazon.com/vpc/latest/userguide/vpc-⁠example-⁠private-⁠subnets-⁠nat.html

正解は「ネットワーク ACL はステートレスなので、アウトバウンドにエフェメラルポートへの許可を足す」です。ネットワーク ACL では、足したルールごとに、その応答の通信を許すルールが反対の向きに必要です。利用者からの 4⁠4⁠3 への要求に対する応答は、利用者のクライアントが選んだエフェメラルポート (例として 1⁠0⁠2⁠4〜6⁠5⁠5⁠3⁠5) あてに出ていくため、アウトバウンドが 4⁠4⁠3 だけでは応答が止まります。セキュリティグループは戻りの通信を自動で許すので、そこに 4⁠4⁠3 を足しても解決しません。ネットワーク ACL はステートフルではないので、インバウンドのルールを作り直しても応答は通りません。ACL を付けるまでは開けていたので、ルートテーブルは原因ではありません。出典 https://docs.aws.amazon.com/vpc/latest/userguide/custom-⁠network-⁠acl.html

正解は「AWS WAF のレートベースのルールを作り、IP アドレスごとに上限を超えたリクエストを止める」です。レートベースのルールは、届いたリクエストを決めた基準 (たとえば送信元の IP アドレス) ごとにまとめて数え、評価の時間枠の中で上限を超えた送信元のリクエストを抑えます。送信元を事前に知らなくても自動で働くので、要件に合います。攻撃元を見つけるたびにネットワーク ACL へ足す案は、人の作業が要り、送信元が毎回変わる攻撃に追いつけません。Auto Scaling の最大数を増やす案は、大量のリクエストを抑えるのではなく受け止めるだけで、要件の「抑える」を満たしません。SQL データベース用のルールグループは攻撃のパターンを検査するもので、リクエストの量は数えません。出典 https://docs.aws.amazon.com/waf/latest/developerguide/waf-⁠rule-⁠statement-⁠type-⁠rate-⁠based.html

正解は「Shield Advanced に申し込み、CloudFront のディストリビューションと ALB を保護の対象にする」です。Shield Advanced では、DDoS 攻撃でアプリの可用性に影響が出たときに、AWS Shield Response Team (SRT) にいつでも助けを求められます。また、保護しているリソースへの攻撃で利用料が急に増えた場合に、Shield Advanced のクレジットとして補てんを申請できる仕組みがあります。Shield Standard はすべての利用者に自動で付く基本の保護で、SRT への相談や利用料の補てんはありません。AWS WAF のレートベースのルールは大量のリクエストを抑える手段の 1 つですが、専門チームへの相談や補てんの仕組みは持ちません。GuardDuty は脅威を検出するサービスで、どちらの要件も満たしません。出典 https://docs.aws.amazon.com/waf/latest/developerguide/ddos-⁠advanced-⁠summary-⁠capabilities.html

正解は「すべての利用者に自動で適用される Shield Standard の保護をそのまま使う」です。Shield Standard は、すべての AWS の利用者に追加の料金なしで自動で適用される保護で、Web サイトやアプリを狙うネットワーク層とトランスポート層のよくある DDoS 攻撃を防ぎます。Route 5⁠3 のホストゾーンや CloudFront のディストリビューションでは特に効果を得やすいとされています。Shield Advanced は申し込みと利用料が要る上位の保護なので、2 つ目の要件に反します。AWS WAF はウェブ ACL やルールごとに料金がかかり、主にアプリの層のリクエストを扱います。GuardDuty は脅威を検出して知らせるサービスで、DDoS 攻撃そのものを防ぐ役目は持ちません。出典 https://docs.aws.amazon.com/waf/latest/developerguide/ddos-⁠standard-⁠summary.html

正解は「RDS でマスターユーザーのパスワードを Secrets Manager に管理させる設定を有効にする」です。RDS は Secrets Manager と連携してマスターユーザーのパスワードを管理できます。この設定では RDS が認証情報を自動で作って Secrets Manager に保管し、アプリの変更なしに定期的にローテーションします。Secrets Manager は認証情報を人の目や平文の表示から守り、取り出しは IAM で細かく制御できます。暗号化した圧縮ファイルで共有する案は、人がパスワードを目にするうえ入れ替えも手作業です。アプリの設定ファイルに書く案も、人が読める場所に置くことになり 1 つ目の要件に反します。ローテーション用の Lambda 関数を自作する案は、2 つ目の要件に反します。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-⁠secrets-⁠manager.html

正解は「Network Firewall を VPC に置き、許可するドメインのリストを持つステートフルなルールで絞る」です。Network Firewall のステートフルなドメインリストのルールグループでは、ドメイン名の許可リストや拒否リストを作れます。ルールのエンジンは TLS の SNI や HTTP の Host ヘッダーにあるドメインを見て判定するので、相手の IP アドレスが変わってもドメインの単位で外への通信を絞れます。セキュリティグループはプロトコル、ポート、IP アドレスの範囲などで判定し、ドメイン名は見ないため、IP アドレスが変わるたびに登録し直す必要があり要件に合いません。ネットワーク ACL で 4⁠4⁠3 番だけを許す案は、どのドメインあての HTTPS も通してしまいます。パブリック IP を付けて直接出す案は、外への出口を増やすだけで、あて先のドメインを絞れません。出典 https://docs.aws.amazon.com/network-⁠firewall/latest/developerguide/stateful-⁠rule-⁠groups-⁠domain-⁠names.html

正解は「Direct Connect のパブリック仮想インターフェイスの上に Site-⁠to-⁠Site VPN を張って暗号化する」です。Direct Connect は既定では通信の途中を暗号化しません。Direct Connect と Site-⁠to-⁠Site VPN を組み合わせると、パブリック仮想インターフェイスで AWS の VPN の終端に届き、その上に IPsec で暗号化した接続を作れます。Direct Connect の帯域と安定した通信を活かしたまま、アプリには手を入れずに暗号化できます。既定で暗号化されているという案は事実と違い、監査の指摘に応えられません。インターネット越しの VPN だけに切り替える案は、Direct Connect の帯域と遅延を使い続けるという要件に反します。アプリの通信を TLS に替える案は、アプリの改修をしないという要件に反します。出典 https://docs.aws.amazon.com/directconnect/latest/UserGuide/encryption-⁠in-⁠transit.html

正解は「キーポリシーで、セキュリティ担当を鍵の管理者、アプリのロールを鍵の利用者として分ける」です。KMS の既定のキーポリシーには、鍵の管理者の文と鍵の利用者の文があります。鍵の管理者は鍵を管理する権限を持ちますが、暗号の操作に鍵を使う権限は持ちません。鍵の利用者には暗号化や復号などの暗号の操作だけを許します。この 2 つにセキュリティ担当とアプリのロールを分けて入れれば、職務を分ける要件を満たせます。両方にすべての操作を許す案は、管理者も復号でき、アプリも鍵を管理できるので両方の要件に反します。AWS マネージドキーはキーポリシーを利用者が決められず、職務の分け方を設計できません。アプリのロールに KMS の権限を付けない案では、アプリが暗号化も復号もできません。出典 https://docs.aws.amazon.com/kms/latest/developerguide/key-⁠policy-⁠default.html

正解は「証跡で、対象のバケットについて S3 のデータイベントの記録を有効にする」です。CloudTrail の証跡は、既定ではデータイベントを記録しません。S3 のオブジェクトに対する GetObject、PutObject、DeleteObject などの操作はデータイベントに当たるため、対象のバケットについてデータイベントの記録を有効にすると、誰がいつどのオブジェクトを読み出したかが残ります。既定の証跡の管理イベントには、オブジェクトの読み出しは含まれないので要件に合いません。Macie の検出結果は機密データがどこにあるかを示すもので、誰が読んだかの記録ではありません。バージョニングは書き換えの前の版を残す仕組みで、読み出しの記録は残しません。出典 https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-⁠data-⁠events-⁠with-⁠cloudtrail.html

正解は「独自の DB パラメータグループで rds.force_ssl を 1 にし、DB インスタンスに適用する」です。RDS for PostgreSQL では、rds.force_ssl のパラメータを 1 にすると、SSL を使わない接続をデータベースの側で拒否できます。バージョン 1⁠4 以前では既定が 0 (無効) なので、独自の DB パラメータグループを作って値を 1 に変え、DB インスタンスに適用します。保存の暗号化を有効にする案は、保存されたデータを守るもので、通信の途中の暗号化は強制しません。セキュリティグループで送信元を絞る案は、接続できる相手を限るだけで、暗号化されていない接続は通ります。各部署に依頼する案は、クライアントの設定に頼るので要件に反します。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html

正解は「組織のレベルで S3 Block Public Access を有効にし、各アカウントに広げる」です。S3 Block Public Access は、リソースがどのように作られたかに関係なく公開を制限する一元的な仕組みで、組織、アカウント、バケットの各レベルで設定できます。Organizations を使った組織のレベルのポリシーは、選んだメンバーアカウントに自動で広がり、アカウントのレベルの設定より優先されるので、各アカウントの管理者が外すことはできません。毎月点検する案は、点検までの間に公開されたままになり、強制にもなりません。Macie で見つけて手で直す案も事後の対応で、設定ミスそのものを防げません。手順書に書く案は人の注意に頼るだけで、組織としての強制になりません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-⁠control-⁠block-⁠public-⁠access.html

正解は「Object Lock のガバナンスモードで 5 年の保持を設定し、保持を外す権限を担当者だけに与える」です。ガバナンスモードでは、ふつうの利用者は保持期間中のオブジェクトの版を上書きも削除もできません。ただし BypassGovernanceRetention の権限を持ち、ガバナンスモードを越える指定をリクエストに付けた人だけは、期間中でも保持を外して削除できます。コンプライアンスモードは、ルートユーザーを含めて誰も期間中に削除できず、保持期間も短くできないため、2 つ目の要件に反します。バージョニングとバケットポリシーの組み合わせは、ポリシーを書き換えられる管理者なら誰でも削除できてしまいます。リーガルホールドには期限が無く、明示的に外すまで続くので、5 年という期限を設定する案は成り立ちません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-⁠lock.html

正解は「S3 ライフサイクルの有効期限のアクションで、保存から 1⁠0⁠9⁠5 日後にログを消させる」です。S3 ライフサイクルの設定に有効期限 (Expiration) のアクションを足すと、オブジェクトが決めた寿命に達したときに S3 が自動で削除します。バージョニングを無効にしたバケットでは、期限を迎えたオブジェクトはそのまま削除されるので、人やプログラムに頼らず条例の決まりを守れます。Intelligent-⁠Tiering はアクセスの頻度に応じて保存の層を移す仕組みで、オブジェクトを消しません。コンプライアンスモードの Object Lock は期間中の削除を防ぐ仕組みで、期間が過ぎても自動では消えません。Lambda 関数で消す案は、自作のプログラムに頼らないという要件に反します。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-⁠expire-⁠general-⁠considerations.html

正解は「そのリージョンで、アカウントの EBS のデフォルトの暗号化を有効にする」です。EBS のデフォルトの暗号化を有効にすると、そのアカウントでこれから作る EBS ボリュームとスナップショットのコピーが必ず暗号化されます。インスタンスの起動で作られるボリュームも対象で、担当者が指定を忘れても暗号化されます。この設定はリージョンごとで、有効にしたリージョンでは個々のボリュームで外せません。既存のボリュームやスナップショットには効かないため、既存分は別の計画で扱う前提とも合います。手順書で周知する案は、担当者の注意に頼るので要件に反します。スナップショットをコピーし直す案は既存分の対応で、今後作るボリュームは暗号化されません。インスタンスストアだけを使う案は、ボリュームを暗号化するという要件の答えになりません。出典 https://docs.aws.amazon.com/ebs/latest/userguide/encryption-⁠by-⁠default.html

正解は「注文テーブルで、ポイントインタイムリカバリ (PITR) を有効にしておく」です。PITR は DynamoDB が自動で取り続けるバックアップで、最大 3⁠5 日分の復旧点を秒の単位で持ちます。バックアップの作成や日程の管理は要らず、誤った書き込みの直前の時点を指定して新しいテーブルに戻せます。毎晩オンデマンドバックアップを取る案は、日程を組む運用が要るうえ、戻せるのは取った時点だけで、秒の単位の要件を満たしません。DynamoDB Streams は変更を後続の処理に渡す仕組みで、テーブルを過去の時点に戻す機能ではありません。グローバルテーブルは書き込みをほかのリージョンにも複製するため、誤った値もそのまま複製され、過去の時点には戻せません。出典 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Point-⁠in-⁠time-⁠recovery.html

正解は「米国東部 (バージニア北部) リージョンで ACM の証明書をリクエストし、CloudFront に付ける」です。利用者と CloudFront の間の HTTPS に ACM の証明書を使うには、その証明書を米国東部 (バージニア北部) リージョン (us-⁠east-⁠1) でリクエストするか、そこにインポートする必要があります。CloudFront はこのリージョンの証明書だけを選べるため、東京で発行した証明書は表示されません。東京でリクエストし直す案は、同じ理由でやはり選べません。ALB にだけ付ける案は、CloudFront と ALB の間は守れても、利用者と CloudFront の間を独自ドメインで HTTPS にするという要件を満たしません。証明書を S3 に置いて読ませる仕組みは CloudFront にはなく、証明書の設定になりません。出典 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-⁠and-⁠https-⁠requirements.html

正解は「カスタマーマネージドキーを作って分析用アカウントに使用を許可し、そのキーでコピーしてから共有する」です。RDS では、共有元のアカウントの既定の KMS キーで暗号化したスナップショットは共有できません。回避の手順は、カスタマーマネージドキーを作って相手のアカウントにそのキーの使用を許可し、そのキーでスナップショットをコピーしてから、コピーを相手のアカウントに共有するというものです。暗号化されたスナップショットはパブリックに共有できず、相手を限る要件にも反します。既定のキーのまま共有先を足し直しても、既定のキーで暗号化されている限り共有はできません。暗号化せずにダンプを置く案は、暗号化したまま共有するという要件に反します。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/share-⁠encrypted-⁠snapshot.html