Slide 1

Slide 1 text

© LayerX Inc. コンパウンドスタートアップのための スケーラブルでセキュアな Infrastructure as Codeパイプラインを考える 2024/04/16 at AWS知見共有会 - 運用のスケーラビリティとセキュリティ

Slide 2

Slide 2 text

© LayerX Inc. 2 はじめに ● 本日の発表では、Infrastructure as Codeは全てIaCと省略します ● IaCパイプラインは「Infrastructure as CodeツールのためのCI/CDパイプ ライン」を意味します ● 本資料中に出てくるGitHubリポジトリ名は、いずれも仮称です はじめに

Slide 3

Slide 3 text

© LayerX Inc. 3 想定する聞き手 LayerXにおけるIaCパイプライン概要 ● IaCパイプラインを利用・構築したことがある・運用している ● Terraform/AWS IAM/GitHub Actionsについて多少知っている

Slide 4

Slide 4 text

© LayerX Inc. 4 自己紹介 竹山雄也 (@yuya-takeyama) ● 株式会社LayerX ● コーポレートエンジニアリング室 ● 2023年9月入社 ● 前職はSRE ● 浅草在住 ● 趣味: メタル、麻雀、飲み歩き、散歩、ランニング

Slide 5

Slide 5 text

© LayerX Inc. 5 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 事業紹介 バクラク事業 企業活動のインフラとなる法人支出 管理(BSM)SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン

Slide 6

Slide 6 text

© LayerX Inc. 6 コンパウンドスタートアップとは コンパウンドスタートアップとは CEO福島による記事「コンパウンドスタートアップというLayerXの挑戦」より引用 https://comemo.nikkei.com/n/n7332c93f50c7

Slide 7

Slide 7 text

目次 Agenda ● LayerXにおけるIaCパイプライン概要 ● コーポレートエンジニアリング室におけるIaCパ イプライン ○ 運用のスケーラビリティ ○ セキュリティ

Slide 8

Slide 8 text

LayerXにおける IaCパイプライン概要 全社的なものと個別事業部のもの

Slide 9

Slide 9 text

© LayerX Inc. 9 IaCパイプラインによって目指したい状態 LayerXにおけるIaCパイプライン概要 ● チーム間での依頼という形をなるべく避けて、必要なリソースの調達や設定の変 更を自分たちで行えるようにする (セルフサービス化) ○ サイクルタイムの向上 ○ ノウハウを持つべき人に蓄積 ● リソースに応じて、適切な形でのレビュー、ガバナンスの適用 ○ 統一性の高いワークフローにより、アジリティとセキュリティを両立し、バランスを取る ○ 「適切な形」は絶えず変化するので、適応できるようにする

Slide 10

Slide 10 text

© LayerX Inc. 10 ● corp-infra ○ コーポレートエンジニアリング室が管理するmonorepo ○ 会社全体の共通部分に関わるAWS、Google Cloud、Microsoft Entra ID、Datadog等 ○ GitHub Actions上でTerraformを利用 ● bakuraku-infra ○ バクラク事業部DevOpsチームが管理するmonorepo ○ バクラク事業部に紐づくAWS、GCPリソース ○ AWS CodeBuild上でTerraformを利用 ● その他事業部の管理するパイプラインもいくつか存在 LayerXにおけるIaCパイプライン (リポジトリ) LayerXにおけるIaCパイプライン概要

Slide 11

Slide 11 text

© LayerX Inc. 11 LayerXにおけるIaCパイプラインのポイント LayerXにおけるIaCパイプライン概要 ● 全社的なリソースはコーポレートエンジニアリング室が管理 (corp-infra) ● 個別の事業・プロダクトに閉じたアカウント・リソースは各事業部に委譲 ○ そのためのパイプラインも専任のチームがオーナーシップを持つ ○ いずれもTerraformを使いつつも、細かい使用技術は異なる ● それぞれのリポジトリはmonorepoになっており、同一事業内でプロダクトが 増えても、リポジトリやIaCパイプラインは増えない ○ 効率的に事業の拡大を支えることができる

Slide 12

Slide 12 text

コーポレートエンジニアリング室における IaCパイプライン 運用のスケーラビリティ編

Slide 13

Slide 13 text

© LayerX Inc. 13 運用のスケーラビリティのために目指していること ● 適切な単位(VPC、DNS、SSO等)や環境でtfstateを分割する ○ drift等により、後続Pull Requestのマージができない状況を減らす ○ Terraform等のツール類のアップデートを段階的に行えるようにする ○ matrix buildによる動的なパイプラインでの並列実行が必要 ● 各種ツールやTerraform Providerの自動アップデート ○ 常にセキュリティ上望ましい状態を最小の労力で維持 ○ Renovateを活用 ● かつ、これらの仕組みをOSSを活用して最小のコストで実現 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ)

Slide 14

Slide 14 text

© LayerX Inc. 14 tfactionの導入・移行 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ) ● 当初は独自のMakefileを利用したパイプラインだった ○ Terraform、tfcmt、tfsec、secretlint等 ● かつ、全てのクラウドプロバイダー・それぞれの環境が一つのtfstateに全部入 りになっていた ● tfactionというOSSを導入し、段階的に移行を進めている

Slide 15

Slide 15 text

© LayerX Inc. 15 tfactionの紹介 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ) ● GitHub ActionsでTerraformのIaCパイプラインを構築するためのAction 群 ● 作者: @suzuki-shunsukeさん ● build matrixによる動的なパイプライン ● Pull Requestへのコメントによりplanをわかりやすく表示 (tfcmt) ● aqua、trivy、tflint、conftest等のツールの統合 ● Renovateとの統合による自動アップデートの支援 ● などなど...

Slide 16

Slide 16 text

© LayerX Inc. 16 ● 前職でも利用していた ○ 中身もある程度把握している ● 作者の @suzuki-shunsuke さんとは前職で同じチームで働いていた ○ そもそも前職における課題を解決するために作られたものであり、 その背景や過程にも関わっていた ○ お互いの転職後も困ったら相談できるぐらいの距離感 ● IssueやPull Requestを通じてのcontributionの経験 ● 以上から、何か問題が起きても最悪自分で何とかできるだろうという自負 tfaction導入の背景 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ)

Slide 17

Slide 17 text

コーポレートエンジニアリング室における IaCパイプライン セキュリティ編

Slide 18

Slide 18 text

© LayerX Inc. 18 tfactionで実現されるセキュリティ コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) ● 作者のこの資料がとても詳しいです!! ○ CI/CD Test Night #7 で登壇しました https://zenn.dev/shunsuke_suzuki/articles/ci-cd-test-night-2024-03-26

Slide 19

Slide 19 text

© LayerX Inc. 19 IaCパイプラインのセキュリティとは? CI/CD パイプラインは重要であると同時にリスク の高いシステム・コンポーネントである。 コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) デジタル庁による「CI/CD パイプラインにおけるセキュリティの留意点に関する技術レポート」より引用 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/504 c3218-1eb0-4287-ba16-01641fdc038c/d377749c/20240329_policies_developmen t_management_outline_08.pdf

Slide 20

Slide 20 text

© LayerX Inc. 20 IaCパイプラインが抱えるセキュリティリスク ● IaCパイプラインはクラウドアカウントや各種リソースへの破壊的権限を持つ ○ 攻撃者に悪用されれば、サービス復旧不可能な状態への破壊も可能 ○ マルウェアの配布等、エンドユーザーに直接的に影響を与えることも可能 ● 重要度の高いクレデンシャルへのアクセスが可能・持っていることが一般的 ○ 攻撃者に悪用されれば、更なる侵入(ラテラルムーブメント)や情報漏洩に繋がることも ● CI/CDプラットフォームや関連ツール自体が攻撃される可能性 ○ ツール・プラットフォームへの依存はそれ自体がセキュリティ上のリスクに繋がる (サプライチェー ンリスク) コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ)

Slide 21

Slide 21 text

© LayerX Inc. 21 安全なIaCパイプラインとは コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) ● セキュアなクレデンシャルを利用、またはセキュアにクレデンシャルを保管する ● レビューを通っていない変更をマージさせない ● レビューを通っていない処理を実行させない ● 必要以上のツール類を利用しない ● 安全なインストール手順を利用する

Slide 22

Slide 22 text

© LayerX Inc. 22 ● OpenID Connectによる動的なクレデンシャルの利用が望ましい ○ 静的なAPI Key・API Tokenの利用を極力避ける ○ terraform planとterraform applyとで権限の分離は必須 ○ terraform apply用の権限はprotected branchで保護されたmainブランチ等のみに許可 ● OpenID Connectが利用できなければAWS Secretes Managerを利用 ○ GitHub ActionsのOrganization Secret/Repository Secretは利用しない ○ planとapplyとで権限・API Keyの分離は必須 ○ KMS key policyやresource-based policyにより、特定のIAM Roleのみにアクセスを制限 セキュアなクレデンシャルを利用、またはセキュアにクレデンシャルを保管する コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) ここができていないと、IaCパイプラインにPull Requestを作れる 社員1名のアカウント奪取で攻撃が成立する可能性!!

Slide 23

Slide 23 text

© LayerX Inc. 23 レビューを通っていない変更をマージさせない コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) ● レビューなしでのマージ (≒terraform apply) を許可することは、インフラへ の変更を何でも許可することを意味する ● Protected branchの以下の設定を有効にする (または検討する) ○ Require a pull request before merging ○ Require approvals ○ Require review from Code Owners ○ Require approval of the most recent reviewable push ○ Require status checks to pass before merging ○ Require branches to be up to date before merging ○ Require signed commits ○ などなど

Slide 24

Slide 24 text

© LayerX Inc. 24 レビューを通っていない処理を実行させない ● on: pull_requestでterraform planを実行するWorkflowを作らない ○ Workflowを変更してPull Requestを作成するだけで、任意の処理が実行できてしまう ● 代わりにon: pull_request_targetを利用する ○ レビュー済みのdefault branch上のWorkflowが実行される ○ sts:AssumeRoleWithWebIdentityのConditionでもpull_request_targetのみに絞る ● ブランチ内のスクリプトを実行してはならない ○ pull_request_targetを利用しても、スクリプトはブランチ内の未レビューのものが実行される ○ どうしてもやる場合は、default branchから取得したり、別repoのレビュー済みブランチから コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) 参考: GitHub Actions でスクリプト等の改竄を防ぐ https://zenn.dev/shunsuke_suzuki/articles/prevent-tamper

Slide 25

Slide 25 text

© LayerX Inc. 25 ● ツール類の利用はそれ自体がセキュリティリスクを持つ ○ 参考: CodecovのBash Uploader scriptへのポイズニング https://about.codecov.io/security-update/ ● 信頼できない開発者のsetup-*-action等を雑に利用しない ○ aquaでのchecksumの検証を有効にしてインストールする ● ただし、それでも完璧ではないことは理解しておく ○ 攻撃の意図を持つ者が信頼され、正当な手続きにより不正なソフトウェアがリリースされたら? ○ 参考: XZ Utilsの脆弱性 CVE-2024-3094 についてまとめてみた https://piyolog.hatenadiary.jp/entry/2024/04/01/035321 必要以上のツール類を利用しない/安全なインストール手順を利用する コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ)

Slide 26

Slide 26 text

© LayerX Inc. 26 ● コンパウンドスタートアップであるLayerXのIaCパイプラインは、全社的なリソー スを管理するものと、事業部内の特定用途に閉じたものとに分かれており、それぞ れに明確な管理者が存在する ● LayerXコーポレートエンジニアリング室においては、tfactionを利用することで IaCパイプラインの運用のスケーラビリティの向上を目指している ● IaCパイプラインはセキュリティ上重要なコンポーネントであり、多層的な防御を行 う必要がある まとめ まとめ