クラウドセキュリティのベストプラクティスと実装例 /cloudsec-bestpractice-example

Transcript

1. クラウドセキュリティのベストプラクティスと実装例 2025 / 03 / 10 Ubie株式会社 水谷正慶 Cloud Security Night #1
2. 2 本日の発表 • クラウドセキュリティのベストプラクティスをUbieでどのように実装して いるのかを紹介したいと思います • あくまで一例です ◦ 組織ごとの都合やアーキテクチャの都合によって正解は異なります ◦ 皆さんの事例もあればぜひ教えて下さい
3. 3 自己紹介 • 水谷正慶（Ph.D） • 職域：セキュリティエンジニア & バックエンドエンジニア • 経歴：Ubie (2021~), Cookpad(2017~), IBM(2011~) • クラウドとの関わり ◦ IBM東京基礎研究所でクラウド関連の研究開発 ◦ CookpadにてAWSを活用し、セキュリティ監視基盤を構築 ◦ UbieではGoogle Cloudを活用しており、プロダクト開発やクラウ ドセキュリティ全般を対応
4. 4 Ubieについて
5. 5 クラウドセキュリティの ベストプラクティスと その実践
6. 6 クラウドセキュリティのベストプラクティス • クラウドプラットフォーム（Google Cloud, Amazon Web Serviceなど）を利 用するうえでのガイドライン ◦ Google Cloud ▪ Enterprise foundations blueprint ▪ Cloud Architecture Center: Security and IAM resources ◦ Amazon Web Service ▪ AWS Well-Architected Framework: Security Pillar ◦ Public Guidelines ▪ NIST Special Publication 800-144 ▪ CIS ( Center for Internet Security) Benchmarks
7. 7 ベストプラクティスの実装方法は必ずしも一律ではない • ガイドライン上明確化しにくい、あるいは組織の状況に依存する内容 ◦ あつかうサービス・プロダクトの種類に依存 ◦ 全体のアーキテクチャにも依存 ◦ リスクの状況や想定する脅威にもよる • 今回の発表では Ubie での実装例を共有・紹介します ◦ あくまで一例です ◦ Ubie内でも様々な変遷を辿ってきた＆これからも変わる可能性はあります ◦ 皆さんの事例も教えて下さい（懇親会でぜひ）
8. 8 今回取り扱うベストプラクティス • [BP1] プロジェクト・アカウントの分割 • [BP2] 長期的に利用する認証情報の非推奨 • [BP3] クラウド環境のログの収集・保全
9. 9 プロジェクト・アカウント の分割
10. 10 [BP1] プロジェクト・アカウントの分割 リソースを分割することによって侵害が発生しても被害を極小化される • プロジェクト・アカウント全体への権限があっても影響範囲が限定 • 別のプロジェクト・アカウントへの権限範囲がわかりにくくなる • ガイドライン等 ◦ Google Cloud: ビジネスワークロードを分割することを推奨 ◦ AWS: アカウントを本番環境と開発・テストで分離することを推奨 ◦ NIST CSF PR.DS-7: テスト環境は本番環境と分離すること ◦ CIS Control 3 (Data Protection): データの種類や機密性に基づいてセグメント化
11. 11 [BP1] Ubieでの実装（マルチクラスタ化） 取り扱うデータの性質に応じて分割 • Shared: 共通的な機能 • General Privacy: 一般的なインターネットユーザ向けデータ • HCP: 医療機関向けデータ • その他目的にあわせてプロジェクトを作成
12. 12 [BP1] Ubieでの実装（「その他目的」の例） • データ基盤関連プロジェクト ◦ data lake (source) と DWH でもプロジェクトを分離 • 特殊なデータを扱うプロジェクト ◦ 認証情報、個人識別情報、要配慮個人情報など • 特殊なワークロードを持つプロジェクト ◦ セキュリティ監視基盤 ◦ コンテナのビルド・イメージの保管・デプロイ
13. 13 [BP1] Ubieでの実装（環境の分離化） • 各プロジェクトに原則 dev, qa, stg, prd を作成 ◦ qa, dev: 開発用、テスト・QAプロセスで利用 ◦ stg: 本番とほぼ同等に構成された環境。トラブル対応・脆弱性診断などに利用 ◦ prd: 本番環境 • 機能ごとにもプロジェクトを分離 ◦ compute: クラスタやCloud Run, Functionsなどを配置 ◦ db: データベース含むデータストアを配置 ◦ secrets: クレデンシャルなど秘匿情報を配置 ◦ assets: 配信用の静的データを配置 • 地域によっても分離 ◦ 地域ごとのレギュレーション、ガイドライン対応 (jp, us, gl, etc.)
14. 14 [BP1] Ubieでの実装（プロジェクトの管理） • 約1,500プロジェクトを運用中 ◦ 全てterraformで管理 ▪ 独立自治をしているわけではなく、統一リポジトリでSRE中心に管理 ◦ moduleを活用して共通リソースなどを一括管理 • 変更などをするうえでエンジニアの認知負荷は低くない ◦ 専用のサービステンプレートツール・サービスカタログで対応 ▪ マルチクラスタの認知負荷に立ち向かう！ Ubieのプラットフォームエ ンジニアリング ◦ 生成AIベースのサポートツールを実装中
15. 15 [BP1] Ubieでの実装（IAMの管理） • 細かくプロジェクト分割することでIAMの制御がしやすい ◦ 必要に応じてProject wideのロールを割り当てられる ◦ 誤って強い権限を付けてもそのプロジェクト内で影響範囲が閉じられる • クロスプロジェクトのIAM制御 ◦ terraform上で管理（ただしリソース参照はアカウント名の直接指定） ◦ Service Accountそのものが危殆化しただけの場合、別プロジェクトの権限 を知るのが難しく、攻撃の遅滞が期待できる
16. 16 長期的に利用する認証情報 の非推奨
17. 17 [BP2] 長期的に利用する認証情報の非推奨 パスワード、APIキー・トークンといった長期間利用される認証情報は、漏 洩した場合の影響が大きいため非推奨 • 別サービスとの統合におけるサプライチェーンリスクへの低減 • ローテーションなど緩和策実施のコスト低減 • ガイドラインなど ◦ Google Cloud: 代替手段がある場合はサービスアカウントキーの利用は避ける ◦ AWS: 可能なら長期的な認証情報ではなく、一時的な認証情報を使うよう推奨
18. 18 [BP2] Ubieでの実装（ベストプラクティスの適用） • パスワードレスDBの利用 ◦ AlloyDB, CloudSQLのIAM based認証 • OIDCの活用 ◦ Workload Identity Federationの活用したGitHub Actionsの認証 ◦ GitHub Actions → Cloud RunへのアクセスもJWT検証によって認証 ◦ PubSub Subscriptionを受けるときもIAM認証が使えないときはJWT検証 • そもそもGoogle Cloud内で完結するようにする ◦ プロダクトのイメージビルド：GitHub Actions → Cloud Build それでも一部ではサービスアカウントキーの利用を強いられる…
19. 19 [BP2] Ubieでの実装（サービスアカウントキーの利用監視） 監査ログからサービスアカウントキーを使ったアクションを監視 • サービスアカウントキーを要求する一部の外部サービスへの対応 • 監査ログをBigQueryに保存、日毎にログを自動チェックする ◦ AuthenticationInfo.ServiceAccountKeyName フィールドからキー利用有無が分かる ◦ アクセスしたAPI、リソース、アクセス元IPアドレスも取得可能 ◦ 事前に想定するAPI、リソース、アクセス元IPアドレス • Q: 最初から権限・条件を絞っておけばいいのでは？ ◦ まれにしか実行されないAPIもあるので完全なAllowListを作るのは困難 ◦ 外部サービスが突然仕様を変える場合もある ◦ 即座にワークロードを止めるより、ゆるやかに検知して対応するアプローチ
20. 20 [BP2] Ubieでの実装（サービスアカウントキーの利用監視ルール） BigQueryからSQLでログを抽出しRegoで評価する仕組みを運用 BigQueryから直近のログを抽出＆グループ化 アカウント毎のアクセス元の指定 GoogleのIPレンジかチェック アカウント毎に許可メソッド一覧を 作成してチェック
21. 21 クラウド環境のログの 収集・保全
22. 22 [BP3] クラウド環境のログの収集・保全 クラウド環境で発生するログ収集し監査やセキュリティ分析、インシデン ト対応に利用できるようにする • アプリだけでなくインフラのログ取得・管理・利用を整備する必要がある • ガイドラインなど ◦ Google Cloud: （各ログ管理のベストプラクティスはあるが全体方針は無し） ◦ AWS: ログを中央集権的に集め、インシデント発生時に全体的な範囲とタイムライン を記録し理解できるようにする ◦ NIST SP 800-92: セキュリティ監視やインシデント対応にどの程度有用であるかを 評価し収集する
23. 23 [BP3] Ubieでの実装（ログの収集と中央管理） クラウドインフラ、アプリ、外部サービスのログも含めて全てBigQueryに 集約し、管理・分析できる体制を運用 • クラウド関連ログは必要に応じて収集 ◦ Audit Logs: 書き込み(Activity) および読み込み (Data Access) を全プロ ジェクトから収集 ◦ VPC Flow Logs, DNS Logs: 一部の重要プロジェクトから収集 ◦ Cloud Assets Inventory: 全てのプロジェクトから収集 • アプリ監査ログも Cloud Logging -> BigQueryに集約する作業中
24. 24 [BP3] Ubieでの実装（ BigQueryを中心としたセキュリティ監視基盤を構築・運用）
25. 25 [BP3] Ubieでの実装（ BigQueryを中心としたセキュリティ監視基盤を構築・運用） • ログの管理・分析のワークロードを一元化 ◦ 複数のログやデータを組み合わせた分析や監視ができる ◦ 新しいワークロードを入れ込むのも容易 • BigQueryの機能によりログ保全コストも最適化 ◦ SIEM製品などを使うのに比べて1/10〜1/100のランニングコスト ◦ Storage Billing Models（主にPhysical Modelを利用）やLong-term storageを活用することでよりお安く • 課題：Google Cloud Audit Logsのスキーマをよりよく管理したい ◦ 現状 1500弱のフィールドが存在している
26. 26 おわりに
27. 27 まとめ • （再掲）本日紹介したのはあくまで一例です ◦ 正解でもないし、今後も変化していくと思われます ◦ 皆さんの事例を懇親会でも話させてください • 本日紹介したのは全体のごく一部です ◦ まだまだできていないこともたくさんあります ◦ ということで
28. 28 採用情報 Ubieでは積極的に採用を行っています。あ なたの応募をお待ちしています。 https://recruit.ubie.life/ We Are Hiring! https://x.com/UbieCorp_JP https://www.facebook.com/ubie.inc https://www.linkedin.com/company/ubie-inc Ubie公式 採用サイト