DEA-4.1認証メカニズムを適用する。

ヒントボタン

PCI-DSSでは平文パスワードの保管を禁じ、短時間で失効する動的資格情報を推奨しています。Amazon RDS for Aurora MySQL には IAM データベース認証があり、Amazon ECS Fargate のタスクロールに rds-db:connect 権限を付けるだけで、SigV4 署名トークンを生成し 15 分間有効の接続を行えるためアプリはパスワードを保持しません。
AWS CloudTrail は rds-db:connect アクションを含む IAM 認証ベースのデータベース接続を記録でき、FinBank のような金融監査要件に対し「誰がいつどのクラスターへ接続したか」を一元的に証跡化できます。さらに VPC Flow Logs や Aurora MySQL の監査ログと組み合わせることでネットワーク経路も含めた完全な追跡が可能になります。
平文を残さず自動的に 15 分で失効する認証情報、CloudTrail での操作追跡、追加サーバーや自作スクリプトを不要とする運用簡素化という複数要件を俯瞰すると、Aurora MySQL が備える IAM データベース認証を ECS Fargate のタスクロールで利用する方式が総合的に最適な選択と判断できます。

ヒントボタン

Amazon Aurora PostgreSQL で IAM データベース認証を有効にすると、db.r6g.large 側にはユーザー名と一時トークンが渡るだけで、固定の DB パスワードは不要になります。トークンは AWS SDK が発行するので Glue ETL から見ると毎回接続前に資格情報を更新している状態となり、30 日という制約を自然にクリアします。変更箇所は Glue の接続種別とジョブロールに rds-db:connect ポリシーを付ける程度で済み、ジョブコードには触れずに停止時間もほぼゼロに抑えられます。

権限周りを IAM に統一すると、AWS CloudTrail は AddRolePolicy、ModifyDBCluster、CreateDBUser などの API 呼び出しを自動記録します。トークン生成は署名処理のため記録対象外ですが、パスワード変更イベントがそもそも無くなるので監査ログはシンプルになります。費用は CloudTrail 標準料金と IAM 利用のみで、月額予算を圧迫しませんし、Glue ワークフローを止める必要もほぼありません。

Secrets Manager や Systems Manager Parameter Store でパスワードを定期回転する構成は Lambda や EventBridge のセットアップ、Glue 側の get-secret-value 取得コードの追加、API 呼び出し課金などが付きまといます。IAM データベース認証なら余計なサービスを増やさず、Glue 接続のプロパティとロールだけで要件を全て満たせるうえ、30 日更新・停止 5 分・100 USD 以下・CloudTrail 監査という複数要件を俯瞰しても最も運用負荷が低いと判断できます。

ヒントボタン

まず、ECS Fargate が配置された VPC をインターネットに晒さず複数アカウントから安全に呼び出すには、PrivateLink を利用する Interface VPC エンドポイント経由で API Gateway のプライベート REST API を公開し、リソースポリシーに各パートナーのアカウント ID を列挙してアクセスを絞る構成が自然で、TLS 終端やスケーリングをサービス側に任せられるため運用負荷も低いです。
長期キーを配らず 12 時間以内に失効する認証が要件なら、IAM にクロスアカウントロールを用意したうえで STS AssumeRole により一時的なアクセスキーを発行し、SigV4 署名で API Gateway を呼ぶ方法がベストプラクティスとなり、会社単位で分離された短期クレデンシャルを自動提供できるうえ更新作業も不要です。
マネージドで多 AZ 冗長を持つ API Gateway Private REST API と PrivateLink による閉域網接続に、一時資格情報を発行する STS と組み合わせた構成は、パブリック IP・VPN・固定パスワードを排しながら RTO 15 分と低コストを同時に実現できるため、全要件を俯瞰して最もバランスの取れた選択と言えます。

ヒントボタン

Amazon RDS for PostgreSQL は Directory Service の AWS Managed Microsoft AD と信頼関係を結び Kerberos 認証を有効にすると、EC2 でドメイン参加した Windows サーバ上のアナリストは既存 Active Directory のチケットをそのまま利用して SSPI 経由のシングルサインオンが可能になり、長期パスワードを扱わず自動更新作業もほぼ不要となり、Secrets Manager やパラメータストアでのローテーション設定が不要という利点まで得られます。

Secrets Manager や Systems Manager にパスワードを保持する方式はローテーションや手動更新プロセスが残り、取得した資格情報をアプリケーションが一時でも保持する可能性があるため「保存しない」という条件と齟齬が生じやすい一方、AWS Managed Microsoft AD による Kerberos 認証はチケットの期限管理が自動で行われるため長期保管リスクがなく、月次メンテナンス以外の運用タスクをほぼ発生させません。

既存 Active Directory のシームレス統合、一時的資格情報のみでのアクセス、1,200 名規模でも追加ユーザやスクリプトによるパスワードローテーションが不要という複数要件を俯瞰すると、Directory Service と RDS の Kerberos 連携が認証・運用両面で最も合理的な選択と判断できます。