Terraform CI/CDに潜む権限昇格リスクと対策 〜金融システムにおける権限分離と制御事例〜 / SRE NEXT 2026

2026年7月10日-11日開催「SRE NEXT 2026」における株式会社Datachain SRE 荒引 健による発表スライドです。

------------------
Website：https://www.datachain.jp/ja
採用情報：https://careers.datachain.jp/
GitHub：https://github.com/datachainlab
X：@datachain_jp, @datachain_en
Medium：日本語, English
note：https://note.datachain.jp/
募集職種一覧：https://herp.careers/v1/datachain
カジュアル面談お申し込み：https://herp.careers/v1/datachain/yobfg8YOkk4g

Transcript

1. Copyright © 2026 Datachain, Inc. All Rights Reserved. Datachain, Inc. Takeshi Arabiki (@a_bicky) Terraform CI/CDに潜む権限昇格リスクと対策 〜金融システムにおける権限分離と制御事例〜 SRE NEXT 2026 (2026-07-10)
2. Copyright © 2026 Datachain, Inc. All Rights Reserved. 自己紹介 2 Takeshi Arabiki X/GitHub @a_bicky/abicky ブログ あらびき日記 経歴 2011-2013 株式会社ディー・エヌ・エー 2013-2017 クックパッド株式会社 2017-2025 Repro株式会社 2026-current: 株式会社Datachain 現在 法人向けWeb3ウォレット「Datachain Wallet」 の SRE リードとして金融システム水準のセキュアな インフラ構築・運用に取り組む
3. Copyright © 2026 Datachain, Inc. All Rights Reserved. 3
4. Copyright © 2026 Datachain, Inc. All Rights Reserved. 4
5. Copyright © 2026 Datachain, Inc. All Rights Reserved. 5
6. 6 Terraform CI/CDに潜む権限昇格リスクと対策
7. Copyright © 2026 Datachain, Inc. All Rights Reserved. 何故Terraform CI/CDが必要なのか？ • トイル撲滅 ◦ PRに手動実行したplan結果を貼り付けなくて良い ◦ レビュー後に手動applyしなくて良い • 作業ミスの軽減 ◦ 誤って他のbranchの内容をapplyすることがない • 作業証跡の保全 ◦ 他の人でもapply結果を閲覧できる • 最小権限の実現 ◦ 強い権限のない開発者でもインフラに手を入れられる 7
8. Copyright © 2026 Datachain, Inc. All Rights Reserved. 8 最小権限の原則の重要性 • システム安定性の向上 ◦ オペミスの被害最小化 • システムセキュリティの向上 ◦ 不正アクセス時の被害最小化
9. Copyright © 2026 Datachain, Inc. All Rights Reserved. 9 最小権限の原則の重要性 • システム安定性の向上 ◦ オペミスの被害最小化 • システムセキュリティの向上 ◦ 不正アクセス時の被害最小化 サプライチェーン攻撃の激化によってますます重要に
10. 10 そのTerraform CI/CDは安全か？
11. Copyright © 2026 Datachain, Inc. All Rights Reserved. 11 よくあるAWSのTerraform CI/CD • PRが作成されるとGitHub Actions (GHA)でterraform planが走る ◦ pull_requestイベントを使用 • PRをmain branchにマージするとGHAでterraform applyが走る ◦ pushイベントを使用 • main branchへは1名のapproveがないとマージできない • secretはparameter store resourceをTerraformで管理 ◦ 真の値はTerraform外でセットし、lifecycleのignore_changesを使用 • terraform planにもapplyにも同じIAMロールを使用 ◦ OIDCで短命なtokenを発行 • 全ての開発者はIaCのリポジトリのwrite権限を持っている
12. Copyright © 2026 Datachain, Inc. All Rights Reserved. 12 よくあるAWSのTerraform CI/CD（GHA workflow 前半） name: Terraform on: pull_request: push: branches: [main] permissions: contents: read id-token: write env: TF_IN_AUTOMATION: "true" TF_INPUT: "false"
13. Copyright © 2026 Datachain, Inc. All Rights Reserved. 13 よくあるAWSのTerraform CI/CD（GHA workflow 後半） jobs: terraform: name: Terraform runs-on: ubuntu-latest steps: - uses: actions/checkout@9c091bb21b7c11d1991bb908d89e… # v7.0.0 - uses: aws-actions/configure-aws-credentials@254c19b… # v6.2.1 with: aws-region: ap-northeast-1 role-session-name: terraform-${{ github.run_id }} role-to-assume: ${{ vars.AWS_ROLE_TO_ASSUME }} - uses: hashicorp/setup-terraform@dfe3c3f87815947d99a… # v4.0.1 - run: terraform init - if: github.event_name == 'pull_request' run: terraform plan -no-color - if: github.event_name == 'push' run: terraform apply -auto-approve -no-color
14. 14 何が問題か？
15. Copyright © 2026 Datachain, Inc. All Rights Reserved. 15 [再掲] よくあるAWSのTerraform CI/CD • PRが作成されるとGitHub Actions (GHA)でterraform planが走る ◦ pull_requestイベントを使用 • PRをmain branchにマージするとGHAでterraform applyが走る ◦ pushイベントを使用 • main branchへは1名のapproveがないとマージできない • secretはparameter store resourceをTerraformで管理 ◦ 真の値はTerraform外でセットし、lifecycleのignore_changesを使用 • terraform planにもapplyにも同じIAMロールを使用 ◦ OIDCで短命なtokenを発行 • 全ての開発者はIaCのリポジトリのwrite権限を持っている
16. Copyright © 2026 Datachain, Inc. All Rights Reserved. 16 全開発者がapply権限を容易に奪取可能 • pull_requestイベントはPR branchのGHAの定義で動く ◦ GHA workflowを容易に改変可能 • write権限があればGHAでAWS roleのtokenを発行可能 ◦ forked repositoryからのPRであれば発行不可能
17. Copyright © 2026 Datachain, Inc. All Rights Reserved. 17 全開発者がapply権限を容易に奪取可能 workflowを変更することで誰でも apply権限のある tokenを取得可能 • pull_requestイベントはPR branchのGHAの定義で動く ◦ GHA workflowを容易に改変可能 • write権限があればGHAでAWS roleのtokenを発行可能 ◦ forked repositoryからのPRであれば発行不可能
18. Copyright © 2026 Datachain, Inc. All Rights Reserved. 18 [再掲] よくあるAWSのTerraform CI/CD（GHA workflow 後半） jobs: terraform: name: Terraform runs-on: ubuntu-latest steps: - uses: actions/checkout@9c091bb21b7c11d1991bb908d89e… # v7.0.0 - uses: aws-actions/configure-aws-credentials@254c19b… # v6.2.1 with: aws-region: ap-northeast-1 role-session-name: terraform-${{ github.run_id }} role-to-assume: ${{ vars.AWS_ROLE_TO_ASSUME }} - uses: hashicorp/setup-terraform@dfe3c3f87815947d99a… # v4.0.1 - run: terraform init - if: github.event_name == 'pull_request' run: terraform plan -no-color - if: github.event_name == 'push' run: terraform apply -auto-approve -no-color
19. Copyright © 2026 Datachain, Inc. All Rights Reserved. 19 任意の処理を実行可能 • 通常のterraform initは任意のproviderをダウンロードする ◦ 攻撃者が用意したproviderがplan時に任意の処理を行う可能性あり • external data sourceはplan時に任意のコマンドを実行可能 ◦ GitHub-hosted runnerのimageには “便利な” コマンドがたくさん
20. Copyright © 2026 Datachain, Inc. All Rights Reserved. 20 よくあるAWSのTerraform CI/CD（再掲） • PRが作成されるとGitHub Actions (GHA)でterraform planが走る ◦ pull_requestイベントを使用 • PRをmain branchにマージするとGHAでterraform applyが走る ◦ pushイベントを使用 • main branchへは1名のapproveがないとマージできない • secretはparameter store resourceをTerraformで管理 ◦ 真の値はTerraform外でセットし、lifecycleのignore_changesを使用 • terraform planにもapplyにも同じIAMロールを使用 ◦ OIDCで短命なtokenを発行 • 全ての開発者はIaCのリポジトリのwrite権限を持っている
21. Copyright © 2026 Datachain, Inc. All Rights Reserved. 21 全開発者がsecretを容易に奪取可能 • ignore_changesがあってもstateの値は更新される ◦ 詳細は[Terraform] 誤解されがちなignore_changesの動き・機密情報はstateに保持されるのか？ | DevelopersIO • stateに入っている値は容易に取り出せる ◦ plan時に悪意のある処理が実行される ◦ 開発者にはread-only権限を広めに付与していて stateファイルをダウンロード可能 ◦ etc.
22. 22 対策
23. Copyright © 2026 Datachain, Inc. All Rights Reserved. 23 Terraform CI/CDで考え得る対策 • workflowを改変不可能にする ◦ GHAなら例えば pull_request_target で GitHub Actions の改竄を防ぐ ◦ Atlantisならcustom workflowの上書きを許可しない • terraform initでproviderをダウンロードしないようにする ◦ 予めproviderをダウンロードしておいたディレクトリを -plugin-dirで指定 • terraform planの実行前にexternal data sourceがないことを確認する • secretにはwrite-only argumentsを使う • plan/applyの権限を分離する
24. 24 Datachain Walletにおける実践
25. Copyright © 2026 Datachain, Inc. All Rights Reserved. 25 2台のAtlantisによるTerraform CI/CD • Terraform CI/CDにAtlantisを採用 ◦ plan用とapply用で別のvirtual machineを用意して別の権限を付与 • PRが作成されるとplan用Atlantisがterraform planを実行 • PRのマージには1名以上のapproveが必要 • PRがmergeableだとPR上でapply用Atlantisに対してterraform applyを命令可能 • secretはAzure Key Vault secret resourceをTerraformで管理 ◦ 真の値はTerraform外でセットし、write-only argumentsを使用 • stateに重要な秘匿値を保存するTerraform resourceの利用は避ける ◦ 必要に応じてHashiCorp公式Azure providerではなくazapiというAzure公式providerを利用
26. Copyright © 2026 Datachain, Inc. All Rights Reserved. 26 2台のAtlantisによるTerraform CI/CD plan用の権限は奪取されても大丈夫にするという方針 • Terraform CI/CDにAtlantisを採用 ◦ plan用とapply用で別のvirtual machineを用意して別の権限を付与 • PRが作成されるとplan用Atlantisがterraform planを実行 • PRのマージには1名以上のapproveが必要 • PRがmergeableだとPR上でapply用Atlantisに対してterraform applyを命令可能 • secretはAzure Key Vault secret resourceをTerraformで管理 ◦ 真の値はTerraform外でセットし、write-only argumentsを使用 • stateに重要な秘匿値を保存するTerraform resourceの利用は避ける ◦ 必要に応じてHashiCorp公式Azure providerではなくazapiというAzure公式providerを利用
27. Copyright © 2026 Datachain, Inc. All Rights Reserved. 27 2台のAtlantisによるTerraform CI/CD Azure Atlantis for plan Atlantis for apply Author Reviewer GitHub
28. Copyright © 2026 Datachain, Inc. All Rights Reserved. 28 2台のAtlantisによるTerraform CI/CD 1. Create a pull request 2. webhook 3. terraform plan Azure Atlantis for plan Atlantis for apply Author GitHub Reviewer 4. Fetch state & resources 6. Comment plan results 5. Update plan file
29. Copyright © 2026 Datachain, Inc. All Rights Reserved. 29 2台のAtlantisによるTerraform CI/CD Azure Atlantis for plan Atlantis for apply Author Reviewer GitHub 7. Approve 8. Comment “atlantis-apply apply” 9. webhook 12. Create/update/delete resources 11. terraform apply 13. Comment apply results 10. Fetch plan file
30. Copyright © 2026 Datachain, Inc. All Rights Reserved. 30 2台のAtlantisによるTerraform CI/CD 1. Create a pull request 2. webhook 3. terraform plan Azure Atlantis for plan Atlantis for apply Author Reviewer GitHub 4. Fetch state & resources 6. Comment plan results 7. Approve 8. Comment “atlantis-apply apply” 9. webhook 12. Create/update/delete resources 11. terraform apply 13. Comment apply results 5. Update plan file 10. Fetch plan file
31. Copyright © 2026 Datachain, Inc. All Rights Reserved. 31 [再掲] 2台のAtlantisによるTerraform CI/CD • Terraform CI/CDにAtlantisを採用 ◦ plan用とapply用で別のvirtual machineを用意して別の権限を付与 • PRが作成されるとplan用Atlantisがterraform planを実行 • PRのマージには1名以上のapproveが必要 • PRがmergeableだとPR上でapply用Atlantisに対してterraform applyを命令可能 • secretはAzure Key Vault secret resourceをTerraformで管理 ◦ 真の値はTerraform外でセットし、write-only argumentsを使用 • stateに重要な秘匿値を保存するTerraform resourceの利用は避ける ◦ 必要に応じてHashiCorp公式Azure providerではなくazapiというAzure公式providerを利用
32. Copyright © 2026 Datachain, Inc. All Rights Reserved. 32 Secret管理の問題点 • terraform planには通常secretのread権限が必要 ◦ AWSのparameter storeもAzureのKey Vault secretも同様 • plan用のAtlantisにはsecretのread権限は付与したくない ◦ plan実行時にsecretを抜かれる可能性がある
33. Copyright © 2026 Datachain, Inc. All Rights Reserved. 33 自作Terraform providerの利用 • secretのmeta dataを取得する権限があればterraform plan可能なprovider ◦ 詳細は Terraform Provider for Azure Key Vault を作った - あらびき日記
34. Copyright © 2026 Datachain, Inc. All Rights Reserved. 34 手動オペレーションには PIMを利用 • PIM (Microsoft Entra privileged identity management) は特権IDを管理する仕組み ◦ 一部のroleを利用する資格のあるユーザを予め登録 ◦ ユーザは手動オペレーションが必要な際に roleの利用申請を行う ◦ ユーザは申請が承認されると時限付きで roleの権限を得る • PIMで管理しているroleの例 ◦ secret (Key Vault secret) の更新のみできるrole (PIM for Azure resources) ◦ Azure Database for PostgreSQLのadmin role (PIM for Groups)
35. 35 まとめ
36. Copyright © 2026 Datachain, Inc. All Rights Reserved. 36 まとめ • Terraform CI/CDはworkflowの改変などで容易にtokenやsecretが抜かれる ◦ 任意の処理をさせない工夫や planとapplyで権限を分けて被害を抑えることが重要 • Datachain Walletではplan用とapply用でAtlantisを分離 ◦ plan用の権限が奪取されても被害がないように徹底 ◦ SREにさえ常時強い権限を与えるのではなく PIMによるjust-in-timeの権限昇格 より詳細な話が聞きたい方はブースや懇親会でお話ししましょう！
37. 37 ※本資料に記載されている会社名、商品名、サービス名およびロゴは、各社の商標又は登録商標です。