あるシステム開発で、どうしてもQuickSightの標準のビジュアルでは実現できない要件がありカスタムビジュアルコンテンツで実現することになりました。
カスタムビジュアルコンテンツは簡単に言うと、QuickSight分析の中に別のWebページを埋め込むものです。
今回作成するカスタムビジュアルコンテンツとして埋め込むWebページ（以降、「Webページ」）は、動的にデータを表示するのですが、そのままでは誰からでもデータにアクセスできる状態になってしまいます。そのため、可能な限りWebページを保護することにしました。
何を以て「保護されている」と判断するかですが、今回は以下の通り定めました。
Webページ単体ではデータにアクセス出来ない。
QuickSight経由でWebページにアクセスした場合にはシームレスにデータにアクセスできる。
ちなみに、表示するデータはWebページのバックエンドにAPIを立てて、そのAPIが表示用のデータを返すようになっています。
何をどうやって守るか？
案１：WebページでQuickSightからのアクセスであることを検証する 【不採用】
QuickSightからWebページにiframeでアクセスするときに、検証可能なセッショントークン的なものを渡すことができればWebページ側でこれを検証することで、「QuickSightからのアクセスであればデータにアクセスする」という仕組みを作ることができるはずです。
しかし、残念ながら「セッショントークン的なもの」をパラメータとして渡す機能はQuickSightに存在していないので、この案は不採用。
案２：Cognitoの未認証ユーザーをうまく使う 【不採用】
Cognitoには未認証ユーザーに対して一定期間有効なCredentials/Roleを発行する機能があります。
このRoleにAPIGatewayにアクセス可能なPolicyを設定することで、APIGateway自体は保護されます。
しかしながら、CognitoからAssumeRoleするための情報自体はWebページに持つため、QuickSightからのアクセスかどうかに関係なくデータにアクセスできてしまうのでこれは不採用。
案３：Webページから情報を奪う 【採用】
今回のアーキテクチャでデータの保護を考えたとき
APIのエンドポイントURL
APIへのアクセス許可情報（APIキー）
これらをWebページ自身に持たせなければ、Webページ単体ではデータにアクセスする方法を知りえないので「保護できている」と言えそうです。
具体的には、QuickSight分析のカスタムビジュアルで設定するURLにパラメータ（クエリストリング）としてこれらの情報を埋め込みます。
QuickSight分析に埋め込まれているということは、QuickSightにアクセスできる人でなければAPIキーなどを知り得ないので、一定のセキュリティも担保できていると言って良さそうです。
まとめ
何のアクセス制限もかけていないWebページからデータにアクセスするための情報を取り除き、これらを外部から注入することで間接的にデータを保護する事ができました。
今回やっていないけどやったらより強くなるかもしれないもの
以下を実施すると更に強化できると思います。
Webページ側（ページまたはWebサーバー）でHTTPリファラを見てQuickSightから呼ばれているかをチェックする
APIキーを定期的にローテーションしてQuickSight分析も更新する
豆知識
パラメータで渡す値（この例では $targetDate）が日付型の場合、URLに展開されると `Tue Aug 29 2023 00:00:00 GMT+0000` という形式です。Webページ側でクエリストリングで受け取ってからパースするならdayjsなどを使うのが無難です。
今回は使っていませんが、時刻をパラメータにするときはQuickSightはUTCで時が流れているのでそのへんは気をつけてください。
実装的にはQuickSightのページの中にiframeでWebページが埋め込まれています。Webページ側のConsole出力やデバッグなどはそのまま使えます。
iframeからWebページのURLが直接呼ばれています。一旦QuickSightのバックエンド経由するとかはしていないので、Webページ側のアクセスログにはクライアントの情報が記録されます。
おまけ：APIキーによる認証の是非
AWSのドキュメントなどによるとAPIキーで認証することはあまり勧められていません。理由を調べてみると、
Cognito未認証ユーザーによる認可と比較した場合、APIKeyではアクセスできるリソースを細かく設定できない。
Cognito未認証ユーザーの場合は一定期間で認証情報が無効化されるので漏洩リスクが低い
ということのようです。
本システムではデータのエンドポイントには単一のリソース・メソッドしか定義せずリソースの制限は不要であることと、API Key自体がある程度保護されているためAPI Keyによるアクセス許可で十分と判断しました。