信頼できる開発プラットフォームをどう作るか？-Governance as Codeと継続的監視／フィードバックが導くPlatform Engineeringの進め方

信頼できる開発プラットフォームをどう作るか？ - Governance as Codeと継続的監視／フィードバックが導くPlatform Engineeringの進め方- 2025.08.20 Yurie Mori,
Yutaka Osada

INTRODUCTION

このセッションで学べる事 GitHub Enterprise のような開発プラットフォームのガバナンスのためのリポジトリ作成/運用 01 ガバナンスのためにどのようなことをコード化すれば
よいのか 02 管理者だけでなくプラットフォームユーザー（開発者）も含めてプラットフォームを育てていくためのプロセス 03 セキュリティリスクや不審なユーザーアクティビティを人力に頼らず継続的に監視、即時フィードバックするための仕組み 04

Agenda 01 背景とアプローチ 02 Governance as Codeによる開発プラットフォームの構成のコード化とインナーソース 03 継続的監視とセキュリティフィードバック
04 まとめ

Yurie Mori（森友梨映） • Sr.Consultant(DevOps Engineering)@Avanade • Microsoft MVP for
Developer Technologies(DevOps) 2024～ • Microsoft MVP for DevOps & Cloud Security 2025~ • Zennでの記事執筆（Azure DevOpsを使ったAgile/DevOpsの実践, エンタープライズでGitHubを使うとか） • TFSUGでの登壇 • 書籍執筆(AZ-400の試験対策本) • お仕事 • Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise）の導入・構築 • DevOps/DevSecOps Transformationの技術アドバイザリ • 技術スタック • Azure DevOps, GitHub, Azure, .NET, C# • Please follow me

Yutaka Osada（長田豊） • Manager (DevOps Engineering) @Avanade Japan •
Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise）の導入・構築 • Azure PaaS × GitHub Enterpriseのオファリング開発 • 個人活動 • Zennでの記事投稿（IaC、CI/CD Pipelines Azure DevOps Rest API等） • 登壇（DevOps Days Tokyo 2025、各種Azure系ユーザコミュニティ） • 書籍執筆(AZ-400の試験対策本) • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me

背景とアプローチ

開発プラットフォームの運用に関する背景と課題 • 開発プラットフォームとしてGitHub Enterpriseを、クラウドはAzureを使用 • ベストプラクティスに基づいたGitHub Enterpriseのガバナンス、構成の横展開が必要になった • Excelでパラメーターシートを書くとかだと時間が取られすぎ&メンテしにくい •
Enterprise ownerだけでなく開発プラットフォームを使うすべての人にガバナンスや設定を公開して透明性を担保し、できればプラットフォーム運用に貢献して欲しい（リクエストを出すなど） • GitHub Enterpriseの環境、その配下で作成されるOrganizationやReposの監査可能性やセキュリティ的に安全であるということを可視化したい • 監査ログはGitHubの機能で取得できるけど、なかなかログを見に行ってログを読んで不審なアクティビティがないかを確認して。。。というのはあまり現実的でない • システムで継続的に監視/なにか異常があったときには即座に検知されるようにしたい

開発プラットフォームに対する「信頼性」をどう担保するか？ Governance as Code • 開発プラットフォームのガバナンスの方針や設定・構成をコードとして管理することで、再現性と透明性を確保 • ルール・ガイドラインをInnerSource化し、誰でも参照・改善可能に • 設計意図（なぜその構成なのか）もADR(Architecture
Decision Record)としてGOVERNANCE.mdに記録し、属人化を排除継続的監視/セキュリティフィードバック • 開発プラットフォームを継続的に監視して、プラットフォーム上の不審なアクティビティやセキュリティ的な脆弱性を即検知し、運用にフィードバック • セキュアで拡張性が高く、かつ開発者にとって“使いやすい”状態を維持し続ける仕組みを目指す

GitHub Enterprise ガバナンスの方針、設定をコードで管理インナーソースとして公開監査ログ Resource Group Event Hubs Container
Apps Cosmos DB Enterpriseデータ受信 [Backend endpoint using Dapr] Enterpriseデータ登録 Enterpriseデータ Key Vault Log Analytics Application Insights Near realtime Storage account Container Registry CI /C D Log Analytics Defender for Cloud Sentinel Logic Apps Playbooks 推奨事項/アラート Analytics Rules / UEBA / Hunting GitHubAudit_CL 等通知/自動化 Enterprise owner セキュリティ監視・フィードバック監査ログの永続保存不審なユーザーアクティビティやGitHub上のセキュリティリスクをチケット登録 Enterprise ownerに通知 GitHub Issues ソリューション全体像

Governance as Codeによる開発プラットフォームの構成のコード化とインナーソース

Governance as Code(GaC) • 開発プラットフォームに関わる構成、ルール・権限をコード化してバージョン管理することで再現性と透明性を確保 • ガバナンス構成は .md/.json などで管理
• GitHub Enterpriseの設定をコードベースで管理可能に（ブランチ保護、ロール設計等） • 管理者だけでなく開発者にも可視化され、理解される基盤へ

GitHub Enterpriseのガバナンス設定のコード化 • GitHub Well Architected Frameworkを参照し、ガバナンスの為にドキュメント化すべきものを識別 • ロール設計やアクセス制御、セキュリティルールをすべてコードで定義
• 変更プロセス（Pull Request）自体もGitHub上で管理 • コンプライアンス要件やポリシーを構成ファイルとしてリポジトリに保存 • ブランチ保護ルールセット/pushルールセット/Tagテンプレートルールセットはjson でバージョン管理 • 組織全体で参照できるようにInnerSource化

ガバナンスのためにコード化すべきもの • ブランチ戦略 • GitHubのロールと各ロールがどのような権利と責務を持っているか • インシデント発生時のレスポンス計画 • ガバナンスのポリシー（ステークホルダーもガバナンスポリシーの更新にコミットできるようにする） •
トレーニングの資料 • 構成管理のポリシー • エンタープライズの設定 • データレジデンシーのポリシー • サポートとメンテナンスのプラン • 意思決定のプロセス • プラットフォーム内で発生する変更の適用プロセス（コードのマージやGitHub Enterprise内の設定の変更）出典：https://wellarchitected.github.com/library/governance/checklist/ 出典：https://wellarchitected.github.com/library/governance/design-principles/

コミュニティ正常性のために作成が推奨されているドキュメント • CODE_OF_CONDUCT.md • CONTRIBUTING.md • ディスカッションのテンプレート • GOVERNANCE.md
• イシューと pull request のテンプレートおよび config.yml • SECURITY.md • SUPPORT.md • CODEOWNERS.md 出典：https://docs.github.com/ja/enterprise-cloud@latest/communities/setting-up-your-project-for-healthy-contributions/creating-a- default-community-health-file

ガバナンス用Reposでのドキュメンテーション(1/2) ガバナンス専用のRepos、enterprise-governanceを作成し、GitHub WAFのGovernanceで作成を推奨されているドキュメントとコミュニティ正常性のためのドキュメント群を管理。ドキュメントの種類記載内容 GOVERNANCE.md エンタープライズレベルのガバナンスポリシー（Enterpriseのルール、ユーザー管理方針、ポリシー策定プロセス） organization/ORGANIZATIONNAME-GOVERNANCE.md
各Organizationごとのポリシー（Org固有の設定方針） SECURITY.md インシデント対応計画、セキュリティポリシー、報告フロー COMPLIANCE.md 社内で定められているコンプライアンス ACCESS_MANAGEMENT.md ロールと権限の管理、意図しないアクセスの監視ポリシー CHANGE_MANAGEMENT.md プラットフォーム内の変更適用プロセス（コードのマージ、ガバナンスルール変更管理） enterprise-settings/ Enterpriseレイヤーの設定値（codeのrulesetなどエクスポート/インポートできるものは設定内容をjson形式でエクスポートして保存） organization/organization-settings/ 各Organizationレイヤーの設定値（codeのrulesetなどエクスポート/インポートできるものは設定内容をjson形式でエクスポートして保存 policies/data-residency.md データレジデンシーポリシーデータの保存場所、転送ポリシーを定義 ※2025/8時点、日本ではまだdata residencyはavailableではない policies/security-audit.md GitHubの監査ログ・セキュリティイベントをどのように監視・分析するか

ガバナンス用Reposでのドキュメンテーション(2/2) ガバナンス専用のRepos、enterprise-governanceを作成し、GitHub WAFのGovernanceで作成を推奨されているドキュメントとコミュニティ正常性のためのドキュメント群を管理。ドキュメントの種類概要 CODE_OF_CONDUCT.md コミュニティ行動規範 CONTRIBUTING.md 開発者向けのコントリビューションガイドライン（ブランチ戦略、コーディング規約、
コードレビュー方針） SUPPORT.md トレーニング資料やサポートリソースへのリンク CODEOWNERS.md リポジトリごとのオーナー設定 .github/ISSUE_TEMPLATE/ Issueテンプレートの格納 .github/PULL_REQUEST_TEMPLATE.md PRの標準テンプレート .github/DISCUSSION_TEMPLATE.md GitHub Discussions用のテンプレート ReadMe.md Onboardingの際に最初に読まれるドキュメントとして、各種ドキュメントの説明

開発プラットフォーム構成とガバナンスのインナーソース化ガバナンスの方針、設定をコードで管理 GitHub Discussionsで構成に関する変更リクエストやQ&Aを受け付け Enterprise owner • CODEOWNERとしてガバナンス用Reposを管理
• レビュー/merge完了後に設定を適用 Enterprise member インナーソースとして公開 • Discussionsで設定変更をリクエスト（新機能有効化など） • リクエストがEnterprise ownerからOKされたらPRで変更を提案

開発プラットフォーム構成とガバナンスのインナーソース化プラットフォームを“共創”する文化基盤 • 管理者だけでなくプラットフォームのユーザー（開発者）もプラットフォームのガバナンスや運用にPull Requestで貢献 • プラットフォームが一方的な「提供物」ではなく、組織全体で育てる“プロダクト”になる •
「一度設定して終わり」ではなく、プラットフォームのユーザーも巻き込んでプラットフォームを運用できるようになった。ガバナンス設計や構成などの知見がコードとして残り、組織知として継承可能に • ガードレールの透明化と納得感の向上 • 「管理者に聞かないとわからない」状態を回避 • 設定値だけでなくガバナンスの方針や背景の横展開が可能になった

継続的監視とセキュリティフィードバック

継続監視と証跡の蓄積 “使われ続ける” プラットフォームへ不審・誤設定は“起きる前提”。監視は運用、証跡は資産となる。 Azure Resource Group GitHub Event Hubs
Container Apps Cosmos DB Enterpriseデータ受信 [Backend endpoint using Dapr] Enterpriseデータ登録 Enterpriseデータ Key Vault Log Analytics Application Insights Enterprise 認証・認可 Enterprise監査ログ Near realtime GitHubに対して何らかの操作を実行監査ログ入力 Storage account Container Registry CI /C D { "@timestamp": 1740509280410, "_document_id": "PESjbtR5IpEtCVRIcfdKzQ", "action": "audit_log_streaming.check", "business": “xxxxx-nfr", "business_id": 277532, "created_at": 1740509280410, "operation_type": "access“ ・・・ } 利用ユーザー Account 蓄積部のアーキ構成（例 • 開発プラットフォームで起きた操作の記録（監査ログ）をすべて残し、一か所に集約 • 記録はだれ・いつ・どこ・何をが分かる形に整え、あとから探しやすく。 Point 01 何を「残す」のか Enterprise／Org。例外ゼロ（新規や削除にも自動追従するのか。）操作ログ・権限変更・設定変更、構成スナップショット、ワークフロー実行記録など Point 02 どのくらい「残す」のかどれくらい残すかを先に決める（例：1年／3年／7年）変更できない保管（一定期間は削除・上書き不可） Point 03 後から「使える」ように整える標準スキーマ（日時／だれが／どこで／何を）：検索しやすいメタデータと索引

GitHub Azure 監査ログを“気づき”に変える (Microsoft Sentinel × Defenderで分析と通知を自動化) 溜めるだけで終わらせない。ルール化 → 検知
→ 通知 → 対応を標準化。利用ユーザー Log Analytics Defender for Cloud Sentinel Logic Apps Playbooks アラート通知 Enterprise owner 推奨事項/アラート Analytics Rules / UEBA / Hunting GitHubAudit_CL 等通知/自動化 • 事前に決めたルールに沿って、いつもと違う動き（例：権限の急な変更や公開設定の変更）を自動で検知。 • 検知したら通知。通知からワンクリックで対応手順（Runbook）を開き、対応内容がわかるように。分析・通知部のアーキ構成（例ガバナンスの方針、設定をコードで管理インナーソースとして公開監査ログ GitHub Issues

アノマリ検知と運用へのフィードバックループ（1/2）普段を覚える（Baselineモデルの自動学習）普段のパターンを学習 1. 過去３週間分の監査ログを読み込む 2. 「誰が・いつ・どこから・何回操作したか」の”平均値”を作成
異常を見つける（アノマリ検知）異常を検知（例） 1. repo.delete が普段 0→1 日 10 件 2. 日本の開発者が深夜に米国 IP から admin:org トークン作成 3. 1 時間で 300 コミット（通常の ×8）などの通常と異なるaction すぐ知らせる（通知）異常レベルで出し分け 1. Info (軽微) → 開発者個人にメール送付 2. Warning (中) → SecOps チャネルに Slack 投稿 3. Critical (重) → Teams チャネルへ全体メンション Solution＆Tool Microsoft Sentinel の UEBA（行動分析）機能を活用ログアナリティクスでKQLを関数化し、Sentinel の「異常アラート」を構成 Logic Apps (no-code フロー)で各種通知サービスへ連携 • GitHub監査ログの傾向を学習し、“普段”を理解するベースラインモデルを構築 • 異常な操作（例：深夜のトークン生成、大量削除など）を自動検知 • 異常レベルに応じた通知チャネルを使い分け（Teams, Slack, Mail 等） No テンプレート名説明 1 GitHub Two Factor Auth Disable 二要素認証の無効化イベントを検知するルール、デフォルトでは 1 日ごとにクエリを実行 2 GitHub Activites from a New Country 新しい国からのアクティビティを検知するルール、デフォルトでは過去 7 日分を学習データに利用して 1 日ごとにクエリを実行 3 Brute Force Attack against GitHub Account GitHub アカウントへのブルートフォース攻撃を検知するルール、デフォルトでは 1 日ごとにクエリを実行 4 GitHub Signin Burst from Multiple Locations 複数の異なるロケーションからのサインインバーストを検知するルール、デフォルトでは 1 時間ごとにクエリを実行 5 TI map IP entity to GitHub_CL TI インジケータに登録した IP アドレスからのアクセスを検知するルール、デフォルトでは 1 時間ごとにクエリを実行 6 GitHub Security Vulnerability in Repository リポジトリ内にセキュリティ脆弱性が含まれていることを検知するルール、デフォルトでは 1 時間ごとにクエリを実行 Microsoft Sentinel の GitHub 固有の脅威に対する分析ルールのテンプレートの活用 https://github.com/Azure/Azure-Sentinel/tree/master/DataConnectors/GithubFunction#configuration-steps-to-deploy-function-app

アノマリ検知と運用へのフィードバックループ（2/2）もう一歩踏み込んだ脅威分析を行うには・・・ • リポジトリに対する異常数のクローン操作 • リポジトリの一括削除 • リポジトリをプライベートからパブリックに変更 • リポジトリに対する部外者からのフォーク操作
• GitHub Organization へのユーザ招待およびユーザ追加 • ユーザへのアクセス許可の追加付与などなどなど

まとめ

Platform Engineeringの視点で見た意義それがもたらす３つの価値民主的なガバナンスインナーソース • 共通ガードレールをGovernance as Codeとしてコード化 •
“設定どこ？”がゼロになる • ユーザーがセルフサービスでプラットフォームのガバナンスにコミットできる環境の整備 • チームや部署間を越えて、コードとナレッジを共有・活用 • Pull Requestを通じて誰でも改善提案できる“建設的な透明性” • 「誰かが作ったもの」から「みんなで育てる資産」へ 3本柱で“信頼と速度”を両立する継続的監視とフィードバック • いつもと違う“動き”を自動検知して、リアルタイムに通知・対応 • ログと可視化により、ボトルネックや改善ポイントが見える化

まとめ • 開発プラットフォームのガバナンスや設定はコードとしてバージョン管理することで、「いつ/誰が/なぜ/どのように変更したのか」を追跡可能に • インナーソース化することで、Enterprise ownerなどの限られた人だけでなく多くの人が開発プラットフォームの改善に貢献することができる • Defender
for CloudやSentinelとGitHubを連携することで、セキュリティ状況や不審なアクティビティを継続的に監視 • 異常が発生した場合は、重要度に応じて即時フィードバックされる仕組みにより、安心して開発プラットフォームの展開と運用が可能に構成の透明化/継続的なセキュリティ監視により、開発プラットフォームの信頼性を担保する

THANK YOU ☺

信頼できる開発プラットフォームをどう作るか？-Governance as Codeと継続的監視...

信頼できる開発プラットフォームをどう作るか？-Governance as Codeと継続的監視／フィードバックが導くPlatform Engineeringの進め方

yuriemori

More Decks by yuriemori

Other Decks in Technology

Featured

Transcript