Copyright © 2026 Datachain, Inc. All Rights Reserved. Datachain, Inc. Takeshi Arabiki (@a_bicky) Terraform CI/CDに潜む権限昇格リスクと対策 〜金融システムにおける権限分離と制御事例〜 SRE NEXT 2026 (2026-07-10) 

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 リードとして金融システム水準のセキュアな インフラ構築・運用に取り組む 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 3 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 4 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 5 

6 Terraform CI/CDに潜む権限昇格リスクと対策 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 何故Terraform CI/CDが必要なのか？ ● トイル撲滅 ○ PRに手動実行したplan結果を貼り付けなくて良い ○ レビュー後に手動applyしなくて良い ● 作業ミスの軽減 ○ 誤って他のbranchの内容をapplyすることがない ● 作業証跡の保全 ○ 他の人でもapply結果を閲覧できる ● 最小権限の実現 ○ 強い権限のない開発者でもインフラに手を入れられる 7 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 8 最小権限の原則の重要性 ● システム安定性の向上 ○ オペミスの被害最小化 ● システムセキュリティの向上 ○ 不正アクセス時の被害最小化 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 9 最小権限の原則の重要性 ● システム安定性の向上 ○ オペミスの被害最小化 ● システムセキュリティの向上 ○ 不正アクセス時の被害最小化 サプライチェーン攻撃の激化によってますます重要に 

10 そのTerraform CI/CDは安全か？ 

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権限を持っている 

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" 

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 何が問題か？ 

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権限を持っている 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 16 全開発者がapply権限を容易に奪取可能 ● pull_requestイベントはPR branchのGHAの定義で動く ○ GHA workflowを容易に改変可能 ● write権限があればGHAでAWS roleのtokenを発行可能 ○ forked repositoryからのPRであれば発行不可能 

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であれば発行不可能 

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 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 19 任意の処理を実行可能 ● 通常のterraform initは任意のproviderをダウンロードする ○ 攻撃者が用意したproviderがplan時に任意の処理を行う可能性あり ● external data sourceはplan時に任意のコマンドを実行可能 ○ GitHub-hosted runnerのimageには “便利な” コマンドがたくさん 

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権限を持っている 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 21 全開発者がsecretを容易に奪取可能 ● ignore_changesがあってもstateの値は更新される ○ 詳細は[Terraform] 誤解されがちなignore_changesの動き・機密情報はstateに保持されるのか？ | DevelopersIO ● stateに入っている値は容易に取り出せる ○ plan時に悪意のある処理が実行される ○ 開発者にはread-only権限を広めに付与していて stateファイルをダウンロード可能 ○ etc. 

22 対策 

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 Datachain Walletにおける実践 

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を利用 

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を利用 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 27 2台のAtlantisによるTerraform CI/CD Azure Atlantis for plan Atlantis for apply Author Reviewer GitHub 

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 

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 

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 

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を利用 

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を抜かれる可能性がある 

Copyright © 2026 Datachain, Inc. All Rights Reserved. 33 自作Terraform providerの利用 ● secretのmeta dataを取得する権限があればterraform plan可能なprovider ○ 詳細は Terraform Provider for Azure Key Vault を作った - あらびき日記 

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 まとめ 

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 ※本資料に記載されている会社名、商品名、サービス名およびロゴは、各社の商標又は登録商標です。