クラウド業務システムの脅威分析・IaCレビュー・リリース判定

R社は，経費精算システム（以下，Eシステムという）を開発している。開発はJ主任のチームが担当し，情報処理安全確保支援士のKさんが支援している。

インフラはAWS上にTerraformのテンプレート（以下，IaCテンプレートという）で構築する。ソースコード等はGitHubのプライベートリポジトリ（以下，Eリポジトリという）で管理し，GitHub Actionsでデプロイする。

〔Eシステムの概要〕

• 社員は，社内外からインターネット経由でWebアプリケーション（以下，Eアプリという）にログインして経費を申請する。承認できるのは申請者の上長だけである。
• 領収書画像はAmazon S3のバケット（以下，領収書バケットという）に保存し，Eアプリが取り出して表示する。申請データはAmazon RDSのデータベース（以下，DBという）に保存する。

〔脅威分析〕

Kさんは，設計段階でデータフロー図（DFD）を作成し，STRIDEを用いて脅威を洗い出した（表1）。

表1　脅威分析の結果（抜粋）

〔IaCテンプレートのレビュー〕

表2　インフラのセキュリティ要件

Kさんは，IaCテンプレート（図1）をレビューした。

# ① 領収書バケット
resource "aws_s3_bucket_public_access_block" "rcpt" {
  block_public_acls       = true
  ignore_public_acls      = true
  block_public_policy     = false
  restrict_public_buckets = false
}
resource "aws_s3_bucket_policy" "rcpt" {
  policy = jsonencode({ Statement = [{ Effect = "Allow",
    Principal = "*", Action = "s3:GetObject",
    Resource = "arn:aws:s3:::r-rcpt/*" }] })
}
# ② EアプリのIAMロール
resource "aws_iam_role_policy" "app" {
  policy = jsonencode({ Statement = [{ Effect = "Allow",
    Action = "s3:*", Resource = "*" }] })
}
# ③ DB
resource "aws_db_instance" "db" {
  publicly_accessible = false
}
resource "aws_security_group_rule" "db_in" {
  from_port                = 5432
  to_port                  = 5432
  source_security_group_id = aws_security_group.app.id
}
# ④ 操作の記録
resource "aws_cloudtrail" "trail" {
  enable_log_file_validation = true
}
# ⑤ ロードバランサ
resource "aws_security_group_rule" "alb_in" {
  from_port   = 443
  to_port     = 443
  cidr_blocks = ["0.0.0.0/0"]
}

図1　IaCテンプレート（抜粋）

注記1　一部の引数は省略している。aws_security_group.appはEアプリのサーバ用である。

注記2　各設定の意味は次のとおり。

• パブリックアクセスブロックの4項目は互いに独立している。block_public_aclsとignore_public_aclsはACLによる公開だけに作用する。block_public_policyをtrueにすると公開を許すバケットポリシーの設定が拒否され，restrict_public_bucketsをtrueにすると公開を許すポリシーをもつバケットへのアクセスがAWSサービスプリンシパルと，バケット所有アカウント内の許可された利用者に限られる。アカウント単位のパブリックアクセスブロックは設定していない。
• ポリシー中の"*"は，全ての主体，操作又はリソースを表す。
• publicly_accessibleがfalseのDBはパブリックIPアドレスをもたない。source_security_group_idを指定した規則は，そのセキュリティグループのサーバからの通信だけを許可する。
• enable_log_file_validationをtrueにすると，ハッシュ値を含む署名付きのダイジェストファイルが作成され，ログファイルの変更・削除を検証できる。

〔CI/CDとリリース判定〕

J主任のチームは当初，デプロイ用のIAMユーザー（管理者権限をもつ）のアクセスキーをワークフロー定義ファイルに直接記述してコミットしていた。J主任は，最新のコミットでその記述を削除し，GitHubのシークレットから参照する方式に変えた。アクセスキーそのものは変更していない。Eリポジトリには委託先2社を含む約30名がアクセスでき，多くが手元に複製している。

なお，GitHub ActionsはOpenID Connect（OIDC）に対応しており，AWS側で信頼関係を設定すると，ジョブがGitHubから受け取ったトークンを提示してAWSの認証情報を取得できる。

表3　リリース判定基準

表4　検査結果（静的解析の指摘は全て解消済み）

リリース判定会議で，Kさんは表3に照らして，【 c 】と意見を述べた。