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

Slide 1

Slide 1 text

インフラ観点で見るセキュリティ　　　　　〜4Cモデルに倣って〜古屋啓介 2024年09月12日

Slide 2

Slide 2 text

自己紹介 2 ● 古屋啓介 ○ 株式会社kubell SRE部 ○ JAWS-UG SRE支部運営 ○ AWS Community Builder(2023〜) ○ ドラム叩きます

Slide 3

Slide 3 text

2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる日本最大級のビジネスチャット「Chatwork」を運営しています。また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる「Chatwork アシスタント」などのBPaaSサービスを幅広く展開。ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。

Slide 4

Slide 4 text

「Chatwork」とは ※※Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。効率的に情報共有できるグループチャット仕事の見える化ができるタスク管理見落としがなくなるファイル管理いつでも会議ができるビデオ/音声通話

Slide 5

Slide 5 text

「Chatwork」の構成（めちゃくちゃ古いですが） 5

Slide 6

Slide 6 text

本セッションのテーマ 6 クラウドやKubernetesをフル活用している「Chatwork」における、インフラ観点のセキュリティ

Slide 7

Slide 7 text

前置き 7 ● 本セッションで触れないこと ○ 専門的なおはなし ○ セキュリティのトレンド ○ 具体的な攻撃やそれに対する防御 ● そのほか ○ CNDT 2022の発表内容がベースです ■ KubernetesとTerraformのセキュリティ/ガバナンス向上委員会 with OPA

Slide 8

Slide 8 text

Slide 9

Slide 9 text

01 | セキュリティのはじめかた

Slide 10

Slide 10 text

クラウドネイティブセキュリティ

Slide 11

Slide 11 text

クラウドネイティブセキュリティ？

Slide 12

Slide 12 text

クラウドネイティブセキュリティって？ 12 ● イメージ ○ なにかツールを入れる or SaaSを利用する ○ プロダクトセキュリティチームを組成する ○ 脆弱性診断してもらう

Slide 13

Slide 13 text

も、ダイジだけど 13 ● インフラ（アプリ）観点でできる基本的なことはやっておきたい ○ S3バケット、全世界に公開してないですか？ ○ IAMユーザ（ACCESSKEY）使ってないですか？ ○ コンテナイメージにヘンなの入ってないですか？

Slide 14

Slide 14 text

基本的なこと、をどこから見ていくか 14 ● クラウドネイティブセキュリティの4C ○ クラウド ○ クラスター ○ コンテナ ○ コード https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 15

Slide 15 text

たとえば、クラウドのセキュリティ 15 ● 各クラウドの推奨事項 ○ AWS: Well-Architected Framework ○ Google Cloud: Architecture Framework ○ Azure: Well-Architected Framework

Slide 16

Slide 16 text

AWSのWell-Architected Framework（1/3） 16 ● フレームワークの概要 ○ AWS Well-Architected Framework では、クラウド上でワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明しています。 ○ 6つの柱 ■ オペレーショナルエクセレンス ■ セキュリティ ■ 信頼性 ■ パフォーマンス ■ コスト最適化 ■ 持続可能性 ○ イメージとしてはプロダクトの健康診断表 ■ 定期的に見直して、悪いところをあぶり出す https://aws.amazon.com/jp/architecture/well-architected/

Slide 17

Slide 17 text

AWSのWell-Architected Framework（2/3） 17 ● セキュリティの柱（Pillar） ○ このホワイトペーパーを読むことで、セキュリティを念頭に置いてクラウドアーキテクチャを設計するための AWS の最新の推奨事項と戦略を理解できます。 ○ 全60項目以上 ■ セキュリティの基礎 ■ IDとアクセス管理 ■ 検知 ■ インフラストラクチャ保護 ■ データ保護 ■ インシデント対応 ■ アプリケーションのセキュリティ https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html

Slide 18

Slide 18 text

AWSのWell-Architected Framework（3/3） 18 ● たとえば ○ IDとアクセス管理 ■ SEC02-BP01 強力なサインインメカニズムを使用する ○ インシデント対応 ■ SEC10-BP03 フォレンジック機能を備える ○ ワークロードを安全に運用する ■ SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装するわかるわ、わかるわかるけどむずない？

Slide 19

Slide 19 text

AWSのWell-Architected Framework（3/3） 19 ● たとえば ○ IDとアクセス管理 ■ SEC02-BP01 強力なサインインメカニズムを使用する ○ インシデント対応 ■ SEC10-BP03 フォレンジック機能を備える ○ ワークロードを安全に運用する ■ SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装するわかるわ、わかるわかるけどむずない？リスク踏まえてやるやらは都度判断でOK

Slide 20

Slide 20 text

AWSのWell-Architected Framework（3/3） 20 ● たとえば ○ IDとアクセス管理 ■ SEC02-BP01 強力なサインインメカニズムを使用する ○ インシデント対応 ■ SEC10-BP03 フォレンジック機能を備える ○ ワークロードを安全に運用する ■ SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装するわかるわ、わかるわかるけどむずない？リスク踏まえてやるやらは都度判断でOK でもそもそも項目数が多すぎる...

Slide 21

Slide 21 text

● W-Aのセキュリティの柱をキュッとした版 ○ アカウントの保護 ○ ワークロードのセキュリティ保護 ● 全27項目 ○ たとえば... ■ ACCT.08 — プライベート S3 バケットへのパブリックアクセスを阻止する ■ WKLD.01 — コンピューティング環境へのアクセス許可に IAM ロールを使用するそんなあなたに、AWS Startup Security Baseline 21

Slide 22

Slide 22 text

Slide 23

Slide 23 text

詳しくはSAはまーんさんの資料で 23 https://speakerdeck.com/track3jyo/aligning-agility-and-aws-governance-controls

Slide 24

Slide 24 text

● Well-Architected Framework ○ 活用できてない... ■ = 健康診断できてない... ● AWS Startup Security Baseline ○ いけてそう ■ = とりあえず最低ラインはOK ● （セキュリティ室によるSecurity Hub運用） ○ W-Aをフォロー「Chatwork」では... 24

Slide 25

Slide 25 text

● クラウドネイティブ”インフラ”セキュリティのはじめかた ○ モデルやフレームワークを使う ■ 4Cモデル ■ Well-Architected Framework ■ AWS Startup Security Baseline ○ リスクを踏まえてやるやらないを判断して無理なくここまでのまとめ 25

Slide 26

Slide 26 text

02 | Kubernetesのセキュリティ向上施策

Slide 27

Slide 27 text

再掲 27 ● クラウドネイティブセキュリティの4C ○ クラウド ○ クラスター ○ コンテナ ○ コード https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 28

Slide 28 text

「Chatwork」のKubernetesクラスター無法地帯問題（言い過ぎ） 28 ● 悪意のあるコンテナがデプロイされる危険性があった ○ 起動するコンテナイメージを検査できていなかったうわっ...弊社のKubernetes、無法地帯すぎ...？

Slide 29

Slide 29 text

「Chatwork」のアプリデプロイの流れ 29 ● Argo CDによるGitOps ○ アプリリポジトリでmasterマージされれば自動でビルド＆マニフェスト更新 ○ Argo CDが差分を検知するのでSyncすればリリース開発者 Application Manifest (helmﬁle) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop

Slide 30

Slide 30 text

デプロイ可能なイメージの制約をかけたい 30 ● いつどこで？ ○ マニフェストファイルのCI時 ○ Kubernetes内部（kubectl apply時、apply以外のリソース生成時）開発者 Application Manifest (helmﬁle) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop

Slide 31

Slide 31 text

Open Policy Agent（OPA）を採用 31 ● 先述の両方のタイミングで対応可能なツール ○ ConftestでCI時の検査 ○ GateKeeperでKubernetes内部から検査

Slide 32

Slide 32 text

OPAとは 32 ● CNCFでホストされるオープンソースで汎用的なポリシーエンジン ○ Regoという言語でポリシーを表現 ○ Input(JSON)をPolicy(Rego)で検査するAPIを提供する

Slide 33

Slide 33 text

Regoとは 33 ● OPAで利用するポリシー記述言語 ● 普段使ってない脳みそが使われる感じがする ○ 独特の書き味があって学習ハードルは高め ○ Masayoshi MIZUTANIさんのZenn記事にお世話になりました ■ https://zenn.dev/mizutani/books/d2f1440cfbba94

Slide 34

Slide 34 text

Conftest、Gatekeeperについて 34 ● いずれもOPA/Regoの仕組みを使ったツール ● Conftest ○ Regoを利用して以下のようなコードを検査できる ■ Kubernetesのマニフェスト ■ TerraformコードなどのHCL ● Gatekeeper ○ Kubernetes内でOPAのポリシーチェックを回す ■ Validating Admission Webhookを利用

Slide 35

Slide 35 text

他社さんの事例 35 ● Conftest + Gatekeeperは（k8sでは）あるあるな構成 ● LIFULLさんの事例 ○ Pod Security Policyの代替として採用 ■ https://www.lifull.blog/entry/2021/07/07/200000 ● NIKKEIさんの記事 ○ ハンズオンつき！ ■ https://hack.nikkei.com/blog/advent20201224/

Slide 36

Slide 36 text

運用戦略 36 ● ポリシー専用のリポジトリを用意 ○ ポリシーと検査の仕組みを密結合にしたくない ● ポリシーの適用を自動化 ○ ポリシーが更新されればCIとGatekeeperそれぞれに反映

Slide 37

Slide 37 text

実装 37 開発者 Policy(Rego) Gatekeeper Manifests Application Manifests EKS Push Admission Webhook Update CRD (Konstraint) Sync Pull CI

Slide 38

Slide 38 text

検査（ポリシー）内容 38 ● 前回発表時点 ○ コンテナイメージ名チェック ■ 特定の命名規則に則っているイメージ名のみ起動を許可 ● 追加で ○ cluster-admin Roleのチェック ■ 意図したリソース以外に強い権限が割り当てられないか ○ hostNetwork, hostPortの制限 ■ 非推奨の機能が使われていないか

Slide 39

Slide 39 text

やってみて 39 ● 課題が解決 ○ 悪意のあるコンテナがデプロイされる危険性がなくなった ■ 今までもなかったけど、より安全に ○ その他明確にダメなところを塞ぐことができた ■ cluster-admin Role, hostNetwork, hostPort ● 2重チェックしているので安心（感がある） ○ 実際に検知されたパターンもあり、機能している ● Regoがやはり難しい ○ ちょっと間が空くと書き方から忘れる...

Slide 40

Slide 40 text

ここまでのまとめ 40 ● 確実なk8sマニフェスト検査ができるOPAの仕組みを採用 ○ 意図しないコンテナの起動を防ぐなど ● 自動かつ柔軟な検査が可能 ○ CIとapply時のWチェック、ポリシーの分離 ● 手をかけれるかどうかがOPA採用の見極めポイントかも ○ 作り込みとRegoの習得が必要な点に要注意 ○ Kyvernoとかが対抗馬か

Slide 41

Slide 41 text

参考文献 41 PairsにおけるEKSセキュリティの取り組み OPAの話も含め広範囲のセキュリティ対策について触れられていてすごく参考になります OPA/Rego入門再掲

Slide 42

Slide 42 text

03 | Terraformの安全な運用について

Slide 43

Slide 43 text

再掲 43 ● クラウドネイティブセキュリティの4C ○ クラウド ○ クラスター ○ コンテナ ○ コード https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 44

Slide 44 text

Terraform、どうやって運用してますか？

Slide 45

Slide 45 text

Terraform、どうやって運用してますか？ 45

Slide 46

Slide 46 text

以前の「Chatwork」では 46 SQSが欲しいな... 開発チーム

Slide 47

Slide 47 text

以前の「Chatwork」では 47 SQSが欲しいな... SQS 1つお願いします！開発チーム

Slide 48

Slide 48 text

以前の「Chatwork」では 48 SQS 1つ入りまーす SRE部

Slide 49

Slide 49 text

以前の「Chatwork」では 49 SQS 1つ入りまーす SRE部 .tf書いてpush

Slide 50

Slide 50 text

以前の「Chatwork」では 50 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして

Slide 51

Slide 51 text

以前の「Chatwork」では 51 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして plan結果をPRに添付

Slide 52

Slide 52 text

以前の「Chatwork」では 52 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして plan結果をPRに添付

Slide 53

Slide 53 text

以前の「Chatwork」では 53 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply plan結果をPRに添付

Slide 54

Slide 54 text

以前の「Chatwork」では 54 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply apply結果を... plan結果をPRに添付

Slide 55

Slide 55 text

以前の「Chatwork」 Terraform事情 55 ● 開発者主体でAWSリソースを作成できなかった ○ AWSリソース作成は権限を持つSRE部が実施する必要あり ● レビューおよび実行記録の保存がしんどい ○ SRE各個人のmacからterraform apply！→GitHubにぺたぺた ● Terraformのバージョン管理がつらい ○ みんなのバージョン一生揃わない（providerも）

Slide 56

Slide 56 text

セキュリティ、という観点では ● 各自ローカルから本番環境ポチポチ、は避けたい ○ 強い権限が必要 ○ 証跡が残らない ■ 手動ぺたぺたの運用カバー ○ Terraformのバージョンが揃わない ■ 古いバージョン使われたり 56

Slide 57

Slide 57 text

新天地を求めて 57 ● 要件 ○ 開発者がセルフサービスで利用できる ■ PR上で実行できるとレビュー記録も残って嬉しい ○ tfstateをリモートで一元管理できる ■ バージョンバラバラ問題にも対処できる ○ IAMロールで運用できる ■ セキュリティ推奨事項に則る

Slide 58

Slide 58 text

紆余曲折 58 ● HCP Terraform(Terraform Cloud) ○ 第一候補だったが当時はIAMキー必須のためNG ● GitHub Actions / Self-Hosted Runner ○ 当時はプランの都合で選択できず...

Slide 59

Slide 59 text

新天地、Atlantis 59 ● GitHub PR上でコメント駆動terraform applyできるOSS ○ PRのコメントでplan、レビュー後apply、みたいな ● Pros ○ 要件はすべて満たす（PR運用、tfstate、IAMロール） ● Cons ○ 運用コスト（インフラ費、人件費）

Slide 60

Slide 60 text

The Atlantis Workﬂow 60 https://www.runatlantis.io/

Slide 61

Slide 61 text

The Atlantis Workﬂow 61 https://www.runatlantis.io/

Slide 62

Slide 62 text

The Atlantis Workﬂow 62 https://www.runatlantis.io/

Slide 63

Slide 63 text

The Atlantis Workﬂow 63 https://www.runatlantis.io/

Slide 64

Slide 64 text

運用 64 EKS terraform apply terraform apply 開発者 Terraform atlantis apply pull

Slide 65

Slide 65 text

導入してみて 65 ● 開発者体験の向上 ○ SRE部に依頼しなくてもAWSリソースが作れる ● セキュリティの向上 ○ 権限はAtlantisさんだけが持てばよい（Atlantisさんつよつよ問題はある） ● ガバナンス（※）の向上 ○ GitHubでplan見て、レビューしてもらって、applyできる ※ここでいうガバナンスが効いている状態とは、みんなが同じやり方・同じルール下でTerraform運用できる状態を指します

Slide 66

Slide 66 text

導入してみて 66 ● 開発者体験の向上 ○ SRE部に依頼しなくてもAWSリソースが作れる ● セキュリティの向上 ○ 権限はAtlantisさんだけが持てばよい（Atlantisさんつよつよ問題はある） ● ガバナンス（※）の向上 ○ GitHubでplan見て、レビューしてもらって、applyできる ※ここでいうガバナンスが効いている状態とは、みんなが同じやり方・同じルール下でTerraform運用できる状態を指します

Slide 67

Slide 67 text

とはいえSRE部でレビューしたいところもある... 67 ● GitHub CODEOWNERSの活用 ○ 特定teamメンバーのapproveを強制できる ● 制限をかける例 ○ ネットワーク系 ○ DNS系 ○ SRE管理してるもの（EKS moduleなど） ○ SSOのポリシー

Slide 68

Slide 68 text

ここまでのまとめ 68 ● 新天地、Atlantis ○ Terraform運用のつらみ解消 ● Terraform運用の開発者体験 / セキュリティ / ガバナンス向上に貢献 ○ 誰でもapplyできて、セキュアで、記録が残る ● Atlantisさんのお守りは考える必要アリ ○ 良くも悪くもself-hosted ○ 今だとHCP Terraformでも全然いいかもしれない

Slide 69

Slide 69 text

04 | 今後やりたいこと

Slide 70

Slide 70 text

再掲 70 ● クラウドネイティブセキュリティの4C ○ クラウド ○ クラスター ○ コンテナ ○ コード https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 71

Slide 71 text

コンテナのセキュリティ 71 ● 課題感 ○ 診断ツールを入れているが、活用しきれていない ■ 侵入や異常検知はしているものの... ● やりたいこと ○ ちゃんと運用を回す or 乗り換える ■ 最近だとAWSのGuard Dutyでも結構イケそうな気がする

Slide 72

Slide 72 text

05 | まとめ

Slide 73

Slide 73 text

インフラ観点で見るセキュリティ〜4Cモデルに倣って〜 73 ● モデルやフレームワークをまず見てみよう ○ 4Cモデル、Well-Architected Framework ● 4Cモデルに沿った具体的な施策 ○ Kubernetes: OPA ○ Terraform: Atlantis ● インフラ観点でもやれるセキュリティ施策はたくさんある！

Slide 74

Slide 74 text

働くをもっと楽しく、創造的に