自動運転研究用データセットをAWSで分析する #6

はじめに

#1〜#5にわたってA2D2データセットの分析基盤を構築してきました。
各回は「まず動かす」を優先したため、セキュリティ上の問題が残っています。
#6では#1〜#5を振り返り、本番環境に持ち込む前に対処すべきセキュリティTODOを整理します。

アーキテクチャ全体図（#1〜#5）

現状の問題点

IAM（最小権限の原則）

#	リソース	現状	問題
1	GlueAdasEtlRole	AmazonS3FullAccess	全バケットへの読み書き権限
2	RedshiftS3Role	AmazonS3ReadOnlyAccess	全バケットへの読み込み権限
3	BedrockKBロール	AmazonS3FullAccess	全バケットへの読み書き権限
4	GitHub Actions	AdministratorAccessのIAMユーザー	全AWSリソースへの権限
5	Lambdaロール	AmazonRedshiftFullAccess + SecretsManagerReadWrite	過剰な権限

ネットワーク

#	リソース	現状	問題
6	Redshift	パブリックアクセス有効	インターネットから直接到達可能
7	Redshift	セキュリティグループがIP直指定	動的IPのたびに手動更新が必要

シークレット管理

#	リソース	現状	問題
8	Redash docker-compose.yml	REDASH_SECRET_KEYをハードコード	リポジトリに含めると漏洩リスク

CI/CD

#	リソース	現状	問題
9	GitHub Actions	長期クレデンシャルをSecretsに登録	クレデンシャルが漏洩すると全権限を取得される

セキュリティTODO

優先度：高

① GitHub ActionsをOIDCに移行する

長期クレデンシャル（Access Key）をGitHub Secretsに登録する方式は、漏洩時のリスクが高いです。GitHub Actions OIDC（OpenID Connect）を使うことで、一時クレデンシャルのみ発行する方式に切り替えられます。

# .github/workflows/ci.yml
permissions:
  id-token: write
  contents: read

steps:
  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::<ACCOUNT_ID>:role/GitHubActionsRole
      aws-region: ap-northeast-1

② Redshiftをパブリックアクセス無効にする

本番環境ではRedshiftをVPC内に閉じてパブリックアクセスを無効化します。

aws redshift modify-cluster \
  --cluster-identifier adas-portfolio \
  --no-publicly-accessible \
  --region ap-northeast-1

※ 現在RedashはローカルのDockerで動いているため、パブリックアクセスを無効化するとそのままでは接続できなくなります。本番化する場合はRedashをEC2またはECS（Fargate）上にデプロイして同一VPC内に配置し、RedshiftのセキュリティグループでRedashのセキュリティグループからのインバウンド（ポート5439）を許可する構成にします。

③ Secrets Managerのシークレットローテーションを設定する

Redshiftの認証情報はSecrets Managerで管理していますが、ローテーションは設定していません。定期的な自動更新を設定することで、漏洩時のリスクを低減できます。

優先度：中

④ IAMロールを最小権限に絞る

GlueAdasEtlRoleは特定のバケットのみに権限を絞ります：

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
  "Resource": [
    "arn:aws:s3:::your-adas-portfolio",
    "arn:aws:s3:::your-adas-portfolio/*"
  ]
}

※ S3バケットをKMSカスタマー管理キー（CMK）で暗号化している場合は、kms:Decrypt・kms:GenerateDataKeyの権限も追加が必要です。

⑤ GitHub ActionsのIAMロールを専用ロールに絞る

CDKにはcdk bootstrapで事前作成されるデプロイ用ロール（cfn-exec-role等）があります。GitHub Actions（OIDC）が引き受けるロールの権限は、これらCDKのbootstrapロールを引き受けるsts:AssumeRoleと、CloudFormationやSSMパラメータストアの読み取り権限のみに絞るのがベストプラクティスです。AdministratorAccessは不要です。

⑥ BedrockKBロールのS3権限を絞る

AmazonS3FullAccessをyour-adas-portfolio-kbバケットのみへの読み書きに限定します。

優先度：低

⑦ Redashのシークレットキーを環境変数で管理する

REDASH_SECRET_KEYをdocker-compose.ymlにハードコードせず、.envファイルで管理してGitの管理対象から外します：

# .env
REDASH_SECRET_KEY=<ランダム文字列>
REDASH_COOKIE_SECRET=<ランダム文字列>

# docker-compose.yml
env_file:
  - .env

⑧ RedshiftのセキュリティグループをVPCエンドポイント経由に変更

IP直指定のセキュリティグループルールをVPCエンドポイントのセキュリティグループに変更することで、IP変更のたびの手動更新が不要になります。

まとめ

優先度	TODO	対象
高	GitHub ActionsをOIDCに移行	CI/CD
高	Redshiftパブリックアクセス無効化	ネットワーク
高	Secrets Managerローテーション設定	シークレット管理
中	IAMロールを最小権限に	IAM
中	GitHub Actions専用ロール作成	CI/CD
中	BedrockKBロールのS3権限を絞る	IAM
低	Redashシークレットを環境変数管理	シークレット管理
低	RedshiftセキュリティグループをVPC化	ネットワーク

今回はデータ分析基盤の構築・検証を優先したため、セキュリティ対応を後回しにしています。AD/ADAS領域では走行データという機密性の高いデータを扱うため、本番環境への適用前には上記のTODOを対処することが必要です。