インフラ観点で見るセキュリティ〜4Cモデルに倣って〜

@IT Cloud Native Week 2024夏特別編集版
https://members06.live.itmedia.co.jp/library/NzM4NzE%253D

Transcript

1. インフラ観点で見るセキュリティ 　　　　　〜4Cモデルに倣って〜 古屋 啓介 2024年09月12日
2. 自己紹介 2 • 古屋 啓介 ◦ 株式会社kubell SRE部 ◦ JAWS-UG SRE支部運営 ◦ AWS Community Builder(2023〜) ◦ ドラム叩きます
3. 2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。 株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる 日本最大級のビジネスチャット「Chatwork」を運営しています。 また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる 「Chatwork アシスタント」などのBPaaSサービスを幅広く展開。 ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。
4. 「Chatwork」とは ※※Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
5. 「Chatwork」の構成（めちゃくちゃ古いですが） 5
6. 本セッションのテーマ 6 クラウドやKubernetesをフル活用している 「Chatwork」における、インフラ観点のセキュリティ
7. 前置き 7 • 本セッションで触れないこと ◦ 専門的なおはなし ◦ セキュリティのトレンド ◦ 具体的な攻撃やそれに対する防御 • そのほか ◦ CNDT 2022の発表内容がベースです ▪ KubernetesとTerraformのセキュリティ/ガバナンス向上委員会 with OPA
8. 目次 CONTENTS 01 | セキュリティのはじめかた 02 | Kubernetesのセキュリティ向上施策 03 | Terraformの安全な運用 04 | 今後やりたいこと 05 | まとめ
9. 01 | セキュリティのはじめかた
10. クラウドネイティブセキュリティ
11. クラウドネイティブセキュリティ？
12. クラウドネイティブセキュリティって？ 12 • イメージ ◦ なにかツールを入れる or SaaSを利用する ◦ プロダクトセキュリティチームを組成する ◦ 脆弱性診断してもらう
13. も、ダイジだけど 13 • インフラ（アプリ）観点でできる基本的なことはやっておきたい ◦ S3バケット、全世界に公開してないですか？ ◦ IAMユーザ（ACCESSKEY）使ってないですか？ ◦ コンテナイメージにヘンなの入ってないですか？
14. 基本的なこと、をどこから見ていくか 14 • クラウドネイティブセキュリティの4C ◦ クラウド ◦ クラスター ◦ コンテナ ◦ コード https://kubernetes.io/ja/docs/concepts/security/overview/
15. たとえば、クラウドのセキュリティ 15 • 各クラウドの推奨事項 ◦ AWS: Well-Architected Framework ◦ Google Cloud: Architecture Framework ◦ Azure: Well-Architected Framework
16. AWSのWell-Architected Framework（1/3） 16 • フレームワークの概要 ◦ AWS Well-Architected Framework では、クラウド上でワークロードを設計および実行 するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明し ています。 ◦ 6つの柱 ▪ オペレーショナルエクセレンス ▪ セキュリティ ▪ 信頼性 ▪ パフォーマンス ▪ コスト最適化 ▪ 持続可能性 ◦ イメージとしてはプロダクトの健康診断表 ▪ 定期的に見直して、悪いところをあぶり出す https://aws.amazon.com/jp/architecture/well-architected/
17. AWSのWell-Architected Framework（2/3） 17 • セキュリティの柱（Pillar） ◦ このホワイトペーパーを読むことで、セキュリティを念頭に置いてクラウドアーキテク チャを設計するための AWS の最新の推奨事項と戦略を理解できます。 ◦ 全60項目以上 ▪ セキュリティの基礎 ▪ IDとアクセス管理 ▪ 検知 ▪ インフラストラクチャ保護 ▪ データ保護 ▪ インシデント対応 ▪ アプリケーションのセキュリティ https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html
18. AWSのWell-Architected Framework（3/3） 18 • たとえば ◦ IDとアクセス管理 ▪ SEC02-BP01 強力なサインインメカニズムを使用する ◦ インシデント対応 ▪ SEC10-BP03 フォレンジック機能を備える ◦ ワークロードを安全に運用する ▪ SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する わかる わ、わかる わかるけどむずない？
19. AWSのWell-Architected Framework（3/3） 19 • たとえば ◦ IDとアクセス管理 ▪ SEC02-BP01 強力なサインインメカニズムを使用する ◦ インシデント対応 ▪ SEC10-BP03 フォレンジック機能を備える ◦ ワークロードを安全に運用する ▪ SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する わかる わ、わかる わかるけどむずない？ リスク踏まえてやるやらは都度判断でOK
20. AWSのWell-Architected Framework（3/3） 20 • たとえば ◦ IDとアクセス管理 ▪ SEC02-BP01 強力なサインインメカニズムを使用する ◦ インシデント対応 ▪ SEC10-BP03 フォレンジック機能を備える ◦ ワークロードを安全に運用する ▪ SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する わかる わ、わかる わかるけどむずない？ リスク踏まえてやるやらは都度判断でOK でもそもそも項目数が多すぎる...
21. • W-Aのセキュリティの柱をキュッとした版 ◦ アカウントの保護 ◦ ワークロードのセキュリティ保護 • 全27項目 ◦ たとえば... ▪ ACCT.08 — プライベート S3 バケットへのパブリックアクセスを阻止する ▪ WKLD.01 — コンピューティング環境へのアクセス許可に IAM ロールを使用する そんなあなたに、AWS Startup Security Baseline 21
22. • W-Aのセキュリティの柱をキュッとした版 ◦ アカウントの保護 ◦ ワークロードのセキュリティ保護 • 全27項目 ◦ たとえば... ▪ ACCT.08 — プライベート S3 バケットへのパブリックアクセスを阻止する ▪ WKLD.01 — コンピューティング環境へのアクセス許可に IAM ロールを使用する そんなあなたに、AWS Startup Security Baseline 22 これくらいならサッと見直せそう！
23. 詳しくはSAはまーんさんの資料で 23 https://speakerdeck.com/track3jyo/aligning-agility-and-aws-governance-controls
24. • Well-Architected Framework ◦ 活用できてない... ▪ = 健康診断できてない... • AWS Startup Security Baseline ◦ いけてそう ▪ = とりあえず最低ラインはOK • （セキュリティ室によるSecurity Hub運用） ◦ W-Aをフォロー 「Chatwork」では... 24
25. • クラウドネイティブ”インフラ”セキュリティのはじめかた ◦ モデルやフレームワークを使う ▪ 4Cモデル ▪ Well-Architected Framework ▪ AWS Startup Security Baseline ◦ リスクを踏まえてやるやらないを判断して無理なく ここまでのまとめ 25
26. 02 | Kubernetesのセキュリティ向上施策
27. 再掲 27 • クラウドネイティブセキュリティの4C ◦ クラウド ◦ クラスター ◦ コンテナ ◦ コード https://kubernetes.io/ja/docs/concepts/security/overview/
28. 「Chatwork」のKubernetesクラスター無法地帯問題（言い過ぎ） 28 • 悪意のあるコンテナがデプロイされる危険性があった ◦ 起動するコンテナイメージを検査できていなかった うわっ...弊社のKubernetes、無法地帯すぎ...？
29. 「Chatwork」のアプリデプロイの流れ 29 • Argo CDによるGitOps ◦ アプリリポジトリでmasterマージされれば自動でビルド＆マニフェスト更新 ◦ Argo CDが差分を検知するのでSyncすればリリース 開発者 Application Manifest (helmfile) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop
30. デプロイ可能なイメージの制約をかけたい 30 • いつどこで？ ◦ マニフェストファイルのCI時 ◦ Kubernetes内部（kubectl apply時、apply以外のリソース生成時） 開発者 Application Manifest (helmfile) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop
31. Open Policy Agent（OPA）を採用 31 • 先述の両方のタイミングで対応可能なツール ◦ ConftestでCI時の検査 ◦ GateKeeperでKubernetes内部から検査
32. OPAとは 32 • CNCFでホストされるオープンソースで汎用的なポリシーエンジン ◦ Regoという言語でポリシーを表現 ◦ Input(JSON)をPolicy(Rego)で検査するAPIを提供する
33. Regoとは 33 • OPAで利用するポリシー記述言語 • 普段使ってない脳みそが使われる感じがする ◦ 独特の書き味があって学習ハードルは高め ◦ Masayoshi MIZUTANIさんのZenn記事にお世話になりました ▪ https://zenn.dev/mizutani/books/d2f1440cfbba94
34. Conftest、Gatekeeperについて 34 • いずれもOPA/Regoの仕組みを使ったツール • Conftest ◦ Regoを利用して以下のようなコードを検査できる ▪ Kubernetesのマニフェスト ▪ TerraformコードなどのHCL • Gatekeeper ◦ Kubernetes内でOPAのポリシーチェックを回す ▪ Validating Admission Webhookを利用
35. 他社さんの事例 35 • Conftest + Gatekeeperは（k8sでは）あるあるな構成 • LIFULLさんの事例 ◦ Pod Security Policyの代替として採用 ▪ https://www.lifull.blog/entry/2021/07/07/200000 • NIKKEIさんの記事 ◦ ハンズオンつき！ ▪ https://hack.nikkei.com/blog/advent20201224/
36. 運用戦略 36 • ポリシー専用のリポジトリを用意 ◦ ポリシーと検査の仕組みを密結合にしたくない • ポリシーの適用を自動化 ◦ ポリシーが更新されればCIとGatekeeperそれぞれに反映
37. 実装 37 開発者 Policy(Rego) Gatekeeper Manifests Application Manifests EKS Push Admission Webhook Update CRD (Konstraint) Sync Pull CI
38. 検査（ポリシー）内容 38 • 前回発表時点 ◦ コンテナイメージ名チェック ▪ 特定の命名規則に則っているイメージ名のみ起動を許可 • 追加で ◦ cluster-admin Roleのチェック ▪ 意図したリソース以外に強い権限が割り当てられないか ◦ hostNetwork, hostPortの制限 ▪ 非推奨の機能が使われていないか
39. やってみて 39 • 課題が解決 ◦ 悪意のあるコンテナがデプロイされる危険性がなくなった ▪ 今までもなかったけど、より安全に ◦ その他明確にダメなところを塞ぐことができた ▪ cluster-admin Role, hostNetwork, hostPort • 2重チェックしているので安心（感がある） ◦ 実際に検知されたパターンもあり、機能している • Regoがやはり難しい ◦ ちょっと間が空くと書き方から忘れる...
40. ここまでのまとめ 40 • 確実なk8sマニフェスト検査ができるOPAの仕組みを採用 ◦ 意図しないコンテナの起動を防ぐなど • 自動かつ柔軟な検査が可能 ◦ CIとapply時のWチェック、ポリシーの分離 • 手をかけれるかどうかがOPA採用の見極めポイントかも ◦ 作り込みとRegoの習得が必要な点に要注意 ◦ Kyvernoとかが対抗馬か
41. 参考文献 41 PairsにおけるEKSセキュリティの取り組み OPAの話も含め広範囲のセキュリティ対策について触れら れていてすごく参考になります OPA/Rego入門 再掲
42. 03 | Terraformの安全な運用について
43. 再掲 43 • クラウドネイティブセキュリティの4C ◦ クラウド ◦ クラスター ◦ コンテナ ◦ コード https://kubernetes.io/ja/docs/concepts/security/overview/
44. Terraform、どうやって運用してますか？
45. Terraform、どうやって運用してますか？ 45
46. 以前の「Chatwork」では 46 SQSが欲しいな... 開発チーム
47. 以前の「Chatwork」では 47 SQSが欲しいな... SQS 1つお願いします！ 開発チーム
48. 以前の「Chatwork」では 48 SQS 1つ入りまーす SRE部
49. 以前の「Chatwork」では 49 SQS 1つ入りまーす SRE部 .tf書いてpush
50. 以前の「Chatwork」では 50 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして
51. 以前の「Chatwork」では 51 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして plan結果をPRに添付
52. 以前の「Chatwork」では 52 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして plan結果をPRに添付
53. 以前の「Chatwork」では 53 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply plan結果をPRに添付
54. 以前の「Chatwork」では 54 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply apply結果を... plan結果をPRに添付
55. 以前の「Chatwork」 Terraform事情 55 • 開発者主体でAWSリソースを作成できなかった ◦ AWSリソース作成は権限を持つSRE部が実施する必要あり • レビューおよび実行記録の保存がしんどい ◦ SRE各個人のmacからterraform apply！→GitHubにぺたぺた • Terraformのバージョン管理がつらい ◦ みんなのバージョン一生揃わない（providerも）
56. セキュリティ、という観点では • 各自ローカルから本番環境ポチポチ、は避けたい ◦ 強い権限が必要 ◦ 証跡が残らない ▪ 手動ぺたぺたの運用カバー ◦ Terraformのバージョンが揃わない ▪ 古いバージョン使われたり 56
57. 新天地を求めて 57 • 要件 ◦ 開発者がセルフサービスで利用できる ▪ PR上で実行できるとレビュー記録も残って嬉しい ◦ tfstateをリモートで一元管理できる ▪ バージョンバラバラ問題にも対処できる ◦ IAMロールで運用できる ▪ セキュリティ推奨事項に則る
58. 紆余曲折 58 • HCP Terraform(Terraform Cloud) ◦ 第一候補だったが当時はIAMキー必須のためNG • GitHub Actions / Self-Hosted Runner ◦ 当時はプランの都合で選択できず...
59. 新天地、Atlantis 59 • GitHub PR上でコメント駆動terraform applyできるOSS ◦ PRのコメントでplan、レビュー後apply、みたいな • Pros ◦ 要件はすべて満たす（PR運用、tfstate、IAMロール） • Cons ◦ 運用コスト（インフラ費、人件費）
60. The Atlantis Workflow 60 https://www.runatlantis.io/
61. The Atlantis Workflow 61 https://www.runatlantis.io/
62. The Atlantis Workflow 62 https://www.runatlantis.io/
63. The Atlantis Workflow 63 https://www.runatlantis.io/
64. 運用 64 EKS terraform apply terraform apply 開発者 Terraform atlantis apply pull
65. 導入してみて 65 • 開発者体験の向上 ◦ SRE部に依頼しなくてもAWSリソースが作れる • セキュリティの向上 ◦ 権限はAtlantisさんだけが持てばよい（Atlantisさんつよつよ問題はある） • ガバナンス（※）の向上 ◦ GitHubでplan見て、レビューしてもらって、applyできる ※ここでいうガバナンスが効いている状態とは、みんなが同じやり方・同じルール下でTerraform運用できる状態を指します
66. 導入してみて 66 • 開発者体験の向上 ◦ SRE部に依頼しなくてもAWSリソースが作れる • セキュリティの向上 ◦ 権限はAtlantisさんだけが持てばよい（Atlantisさんつよつよ問題はある） • ガバナンス（※）の向上 ◦ GitHubでplan見て、レビューしてもらって、applyできる ※ここでいうガバナンスが効いている状態とは、みんなが同じやり方・同じルール下でTerraform運用できる状態を指します
67. とはいえSRE部でレビューしたいところもある... 67 • GitHub CODEOWNERSの活用 ◦ 特定teamメンバーのapproveを強制できる • 制限をかける例 ◦ ネットワーク系 ◦ DNS系 ◦ SRE管理してるもの（EKS moduleなど） ◦ SSOのポリシー
68. ここまでのまとめ 68 • 新天地、Atlantis ◦ Terraform運用のつらみ解消 • Terraform運用の開発者体験 / セキュリティ / ガバナンス向上に貢献 ◦ 誰でもapplyできて、セキュアで、記録が残る • Atlantisさんのお守りは考える必要アリ ◦ 良くも悪くもself-hosted ◦ 今だとHCP Terraformでも全然いいかもしれない
69. 04 | 今後やりたいこと
70. 再掲 70 • クラウドネイティブセキュリティの4C ◦ クラウド ◦ クラスター ◦ コンテナ ◦ コード https://kubernetes.io/ja/docs/concepts/security/overview/
71. コンテナのセキュリティ 71 • 課題感 ◦ 診断ツールを入れているが、活用しきれていない ▪ 侵入や異常検知はしているものの... • やりたいこと ◦ ちゃんと運用を回す or 乗り換える ▪ 最近だとAWSのGuard Dutyでも結構イケそうな気がする
72. 05 | まとめ
73. インフラ観点で見るセキュリティ〜4Cモデルに倣って〜 73 • モデルやフレームワークをまず見てみよう ◦ 4Cモデル、Well-Architected Framework • 4Cモデルに沿った具体的な施策 ◦ Kubernetes: OPA ◦ Terraform: Atlantis • インフラ観点でもやれるセキュリティ施策はたくさんある！
74. 働くをもっと楽しく、創造的に