Slide 1

Slide 1 text

1
 freee 株式会社
 Kubernetes に Security をねじこむ!
 - マイクロサービス基盤における多層防御システム構築の軌跡


Slide 2

Slide 2 text

2
 freee 株式会社 SRE チームに所属
 ○ 2019 年 2 月入社
 ○ 以前はミドルウェア開発に従事
 ○ EC2 環境の canary release 導入 / インフラリソースの最適化 / 新規サービスのインフラ構築 など
 山本 佳代子
 2 freee 株式会社
 Kayoko Yamamoto

Slide 3

Slide 3 text

3
 K8s 上でサービスをセキュアに運用するために行っている取り組みについて
 ● 世の中にあるセキュリティソフトウェアの導入
 ○ 導入時の課題や工夫点
 ● 自製している仕組み
 ○ 妥当なツールが見つからなかったもの
 ○ もっとよいやり方があるよ!というアイディアお持ちの方大募集
 
 お話ししないこと
 ● EKS を選定した経緯や理由
 ● 導入したソフトウェアの詳細な技術
 本日お話しすること


Slide 4

Slide 4 text

4
 Overview
 01 freee について
 03 EKS へ Security をねじ込む方法 1 - 外部から受ける攻撃の対策
 05 まとめ 
 02 freee のマイクロサービス基盤に Security をねじ込むには
 04 EKS へ Security をねじ込む方法 2 - 内部を経由した攻撃への対策


Slide 5

Slide 5 text

5
 5
 freee について
 01 Section

Slide 6

Slide 6 text

6
 6
 スモールビジネスを、
 世界の主役に。
 MISSION
 生産年齢人口が劇的に減少し、慢性的な人手不足となる日本で 労働生産性向上は緊急の課題となっています freeeは「人工知能」と「統合基幹業務システム」をクラウド技術を 活用し、業務効率化のサポートを続けることで、中堅中小企業の バックオフィス業務効率化を目指しています

Slide 7

Slide 7 text

7
 
 PRODUCTS

Slide 8

Slide 8 text

8
 金融機関との連携
 31の金融機関と戦略的業務提携
 90の銀行、920のその他金融機関(信金、労金、信組、JAバンク等)とAPI接続
 契約数ベースでは118の銀行、947のその他金融機関とAPI契約締結済み
 ※2020年6月1日時点


Slide 9

Slide 9 text

9
 上場企業・IPO準備企業もfreeeで経営基盤を刷新
 上場企業・IPO準備フェーズの企業様への導入も加速 上場半年前に会計ソフトをfreeeに変更 スマートなバックオフィス体制を構築 ソウルドアウト株式会社様 GMOペパボ株式会社様 野村ホールディングス株式会社様 グループ全体の経理業務の刷新を freeeを用い実現していく freee導入により経理部門を立て直し 月間で約70時間削減

Slide 10

Slide 10 text

10
 受託業務に係る内部統制の保証報告書 
 (SOC1 Type2 報告書)を受領
 SOC保証とは
 ● 上場企業が自社の財務報告がきちんとしていることを保証するもの 
 ● 利用している情報システム(会計ソフト) も監査の対象
 → システムベンダーも監査を受ける
 SOC1 Type2 報告書とは
 ● システムベンダーが別途監査法人に監査を依頼し、その結果受けた報告書
 ● ユーザー企業が監査を受けた際にはこの報告書を提出


Slide 11

Slide 11 text

11
    EC2 ベース
 
 創業時〜2年前くらいまでにリ リースされたサービス
    EKS ベース
 
 2年程前にリリースされたマイクロサービスをきっかけに K8s でサービスをリリースするように
 
 基本的に AWS 上で稼働
 freee のインフラ
 運用負荷軽減を目的に EC2 から EKS への移行を絶賛取り組み中
    その他
 
 Lambda や ECS でなど動いているサービスもある


Slide 12

Slide 12 text

12
 SRE と PSIRT の JOINT Project として活動を実施
 メンバー紹介
 kawamura
 yamamoto
 liva
 Taichi
 eiji
 杉浦 英史
 SRE PSIRT

Slide 13

Slide 13 text

13
 13
 freee のマイクロサービス基盤に
 Security をねじ込むには
 02 Section

Slide 14

Slide 14 text

14
 Kubernetes に Security をねじ込む要件
 ● 外部から受ける攻撃 - 多層防御
 ○ internet facing
 ○ 常に攻撃はされている,,,
 ○ 攻撃を検知して、対処を早めに始めたい
 
 ● 内部を経由した攻撃 - 監査対応
 ○ restricted access path
 ○ もしもの事態に備えて、
 ○ 変更 / 操作の証跡を残したい


Slide 15

Slide 15 text

15
 ロッキードマーチンが提唱するフレームワーク
 攻撃は7つの段階で行われる
 多層防御 - Cyber Kill Chain
 Weaponization 
 Instration 
 Delivery 
 Command & Control
 Actions on Objectives
 Recoinnaissance 
 Exploitation 
 偵察
 武器調達
 輸送
 攻略
 潜入
 遠隔操作
 奪取
 SNS, URL, Wi-Fi, 
 メール 収集
 SNS, web, 
 メール
 アクセス
 人 + 物の
 脆弱性を
 突く
 投稿文面, botnet,
 脆弱性... 
 常駐
 プロセス
 確保
 通信路 確保
 探索
 目的達成
 証拠隠滅


Slide 16

Slide 16 text

16
 全ての段階でログを取り、アラートをあげて、対処する
 多層防御 - Cyber Kill Chain
 Instration 
 Delivery 
 Command & Control
 Actions on Objectives
 Exploitation 
 HTTP query log
 packet log
 api audit log
 middleware/OS version
 
 process log
 file access
 DNS query log
 packet log
 
 inter-cluster session log
 application log
 Amazon GuardDuty

Slide 17

Slide 17 text

17
 ① CI/CD Users
 request
 EKS
 ECR
 ALB
 外部から受ける攻撃を防ぐ
 ② Service Providing

Slide 18

Slide 18 text

18
 ① CI/CD Users
 request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する 外部から受ける攻撃を防ぐ
 ② Service Providing

Slide 19

Slide 19 text

19
 ① CI/CD Users
 request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する 外部から受ける攻撃を防ぐ
 ② Service Providing

Slide 20

Slide 20 text

20
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する request
 EKS
 ECR
 ALB
 外部から受ける攻撃を防ぐ


Slide 21

Slide 21 text

21
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する request
 EKS
 ECR
 ALB
 AWS WAF
 Amazon GuardDuty 
 外部から受ける攻撃を防ぐ


Slide 22

Slide 22 text

22
 主な監査ポイント
 ● 開発に関わる重要なアカウントの管理運用の統制が取れていること
 ○ github アカウント、本番サーバーアクセスアカウント、admin アカウント
 ● 統制が取れた運用の元にソースコードの改変が行われていること
 ○ 思いつきや悪意による改変が行われないか
 ● 本番サーバーのアクセス統制が取られていること
 ○ 勝手に会計情報を改竄できない仕組みになっている
 ○ 証跡を追うことができる
 ● etc...
 内部を経由した攻撃 - 監査対応


Slide 23

Slide 23 text

23
 内部を経由した攻撃を防ぐ
 ① CI/CD Users
 ② Service Providing request
 EKS
 ECR
 ALB
 ③ Operation Operators


Slide 24

Slide 24 text

24
 内部を経由した攻撃を防ぐ
 ① CI/CD Users
 ② Service Providing request
 EKS
 ECR
 ALB
 操作権限をしぼって操 作証跡を取る ③ Operation Operators


Slide 25

Slide 25 text

25
 ① CI/CD Users
 ② Service Providing request
 EKS
 ECR
 ALB
 操作権限をしぼって操 作証跡を取る step ③ Operation Operators
 内部を経由した攻撃を防ぐ


Slide 26

Slide 26 text

26
 Kubernetes に Security をねじ込んだ全体像
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する 操作権限をしぼって操 作証跡を取る AWS WAF
 step Amazon GuardDuty 
 ③ Operation Operators


Slide 27

Slide 27 text

27
 27
 EKS へ Security をねじ込む方法 1
 - 外部から受ける攻撃の対策
 03 Section

Slide 28

Slide 28 text

28
 外部から受ける攻撃の対策 = 多層防御システムの構築
 ① CI/CD Users
 ② Service Providing request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する

Slide 29

Slide 29 text

29
 trivy - コンテナの脆弱性排除
 攻略
 OSS の image 脆弱性スキャンツール
 ● OS パッケージや App 依存ライブラリの脆弱性を検査
 ● install や 使い方がとてもシンプル
 
 
 コンテナに残された脆弱性をつかれたセキュリティインシデントを未然に 防ぐ


Slide 30

Slide 30 text

30
 trivy で脆弱性が見つかったら CI を落とす trivy - コンテナの脆弱性排除
 Image 作成 ECR
 脆弱性スキャン APP 
 Engineers
 image push CI Pipeline
 commit


Slide 31

Slide 31 text

31
 trivy で脆弱性が見つかったら CI を落とす trivy - コンテナの脆弱性排除
 Image 作成 ECR
 脆弱性スキャン APP 
 Engineers
 image push 脆弱性が検知されたこ とを通知
 CI Pipeline
 commit
 脆弱性を確認 / 修正


Slide 32

Slide 32 text

32
 trivy で脆弱性が見つかったら CI を落とす trivy - コンテナの脆弱性排除
 Image 作成 ECR
 脆弱性スキャン APP 
 Engineers
 image push 脆弱性が検知されたこ とを通知
 CI Pipeline
 commit
 脆弱性を確認 / 修正


Slide 33

Slide 33 text

33
 trivy - コンテナの脆弱性排除
 攻略
 OSS の image 脆弱性スキャンツール
 ● OS パッケージや App 依存ライブラリの脆弱性を検査
 ● install や 使い方もとてもシンプル
 
 
 脆弱性が検知された image の deploy を弾くことで
 本番環境で動作するコンテナの脆弱性を低下させることが可能
 コンテナに残された脆弱性をつかれたセキュリティインシデントを未然に 防ぐ


Slide 34

Slide 34 text

34
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する request
 EKS
 ECR
 ALB
 AWS WAF
 Amazon GuardDuty 
 外部から受ける攻撃の対策 = 多層防御システムの構築


Slide 35

Slide 35 text

35
 falco - pod の振る舞い / K8s api 監視
 攻略
 ● pod の挙動 / pod 上での作業を監視する
 ● kubectl 含む K8s apiの実行内容を監視する
 Sysdig 社が開発を主導する open source security 監視ツール
 ● node 上で実行される system call を監視
 ● K8s audit log を解析
 → rule と照合してマッチすると通知


Slide 36

Slide 36 text

36
 falco - pod の振る舞い / K8s api 監視
 Firehose audit-bridge system call audit log default rule ..... custom rule ..... filtering rule と照合 CloudWatch system call は直接収集 / audit log は audit-bridge を活用


Slide 37

Slide 37 text

37
 falco - pod の振る舞い / K8s api 監視
 攻略
 ● pod の挙動 / pod 上での作業を監視する
 ● kubectl 含む K8s apiの実行内容を監視する
 Sysdig 社が開発を主導する Open source security 監視ツール
 ● node 上で実行される system call を監視
 ● K8s audit log を解析
 → rule と照合してマッチすると通知
 pod の不審な挙動や予期せぬ K8s api 実行を検知し
 速やかに対処可能


Slide 38

Slide 38 text

38
 潜入
 EKS の node 全体のセキュリティリスクを検知する
 TrendMicro 社が提供する all-in-one security sensor
 ● 悪意ある通信を screening する IPS 機能
 ● file access 時に signature match を行う AntiMalware 機能
 
 
 DeepSecurity - node 内のセキュリティリスク検知


Slide 39

Slide 39 text

39
 node へのインストールは kube-node-init を活用
 node の install 時だけ起動するように nodeAffinity で制御
 node-init node の初期化処理をする daemonset で DeepSecurity を install DeepSecurity - node 内のセキュリティリスク検知


Slide 40

Slide 40 text

40
 潜入
 DeepSecurity - node 内のセキュリティリスク検知
 EKS の node 全体のセキュリティリスクを検知する
 TrendMicro 社が提供する all-in-one security sensor
 ● 悪意ある通信を screening する IPS 機能
 ● file access 時に signature match を行う AntiMalware 機能
 
 
 worker node 全体の不審な通信とファイルアクセスを検知し
 速やかに対処可能


Slide 41

Slide 41 text

41
 奪取
 cilium - firewall in cluster
 K8s cluster 内のネットワークをコンテナレベルで監視 / 制御する
 eBPF 上に構築された Open Source の CNI
 ● L3 / L4 / L7 でネットワークポリシーの制御が可能
 ● namespace / tag によるネットワークポリシーの制御が可能


Slide 42

Slide 42 text

42
 Security group cilium - firewall in cluster
 security group ≒ K8s network policy service namespace single tenant の場合、security group で代替できる
 kube-system

Slide 43

Slide 43 text

43
 Security group cilium - firewall in cluster
 multi tenant の場合、lateral movement に気づけない
 service A kube-system service B

Slide 44

Slide 44 text

44
 cilium - firewall in cluster
 namespace / role を理解する cilium で rule を定義する
 Security group service A kube-system service B ● Service B だけ S3 に アクセス可能 ● Service B だけRDS に アクセス可能 ● namespace 間の通信 禁止

Slide 45

Slide 45 text

45
 Security group service A kube-system service B ● Service B だけ S3 に アクセス可能 ● Service B だけRDS に アクセス可能 ● namespace 間の通信 禁止 cilium - firewall in cluster
 rule に反する通信を検知したら drop log を上げる
 
 drop log を 上げる

Slide 46

Slide 46 text

46
 奪取
 cilium - firewall in cluster
 コンテナ間の不審な通信を検知し、遮断
 K8s cluster 内のネットワークをコンテナレベルで監視 / 制御する
 eBPF 上に構築された Open Source の CNI
 ● L3 / L4 / L7 でネットワークポリシーの制御が可能
 ● namespace / tag によるネットワークポリシーの制御が可能


Slide 47

Slide 47 text

47
 AWS Managed Service の活用
 Users request ALB
 正規表現 + ratelimit AWS WAF
 Amazon
 GuardDuty 
 Machine Learning Anomaly Detection CloudTrail, VPC flow logs, DNS resolver query EC2 / EKS 関係なく使えるので、EC2 → EKS の移行時に漏れていた
 セキュリティ対策の発見にもつながる
 
 輸送
 遠隔操作


Slide 48

Slide 48 text

48
 48
 EKS へ Security をねじ込む方法 2
 - 内部を経由した攻撃への対策
 04 Section

Slide 49

Slide 49 text

49
 内部を経由した攻撃への対策 = SOC1 Type2 監査対応
 ① CI/CD ③ Operation Operators
 Users
 ② Service Providing EKS
 ECR
 ALB
 step 操作権限をしぼって操 作証跡を取る request


Slide 50

Slide 50 text

50
 踏み台 (step pod) - 権限管理・運用監視
 ● 背景・課題
 ○ K8s cluster は kubectl をつかうことで様々な操作が可能
 ○ 実行できる条件を適切に制御しなければ重大なセキュリティリスクとなる
 
 ● 要件
 ○ 行使する user の制限
 ■ cluster にアクセス可能な user を制限
 ■ cluster の操作権限を user ごとに適正化
 ○ 実行経路の制限
 ■ K8s api endpoint の公開範囲を適正化
 ■ kubectl のフル権限の行使を特定の経路に限定
 ○ 実施した内容の監視
 ■ api log を取得 -> eks の logging 機能で実現
 ■ pod 上での操作 log を保存


Slide 51

Slide 51 text

51
 踏み台 (step pod) - 権限管理・運用監視
 operators ID/key service namespace IAM user で認証 cluster admin に mapping 行使する user の制限
 IAM user を aws-auth configmap で K8s の group と対応付ける
 課題:IAM 認証情報が漏れると revoke されるまで任意の操作が可能


Slide 52

Slide 52 text

52
 踏み台 (step pod) - 権限管理・運用監視
 operators AWS STS temporal service namespace RBAC で認証 service adminにmapping 行使する user の制限
 対策: IAM user の発行をせず、Onelogin 連携で MFA + 一時的に有効な credential をつかう


Slide 53

Slide 53 text

53
 踏み台 (step pod) - 権限管理・運用監視
 operators temporal service namespace local から K8s api endpoint に 向けて kubectl を実行 実行経路の制限 + 実施した内容の監視
 Onelogin 連携で MFA + 一時的に有効な credential をつかう
 課題:権限取得後は任意の経路で api アクセスできる & pod 内での活動の log が取れない


Slide 54

Slide 54 text

54
 踏み台 (step pod) - 権限管理・運用監視
 operators temporal step SSM ssh over SSM で step に接続 user 毎に許可された role に 昇格して kubectl を実行する 実行経路の制限 + 実施した内容の監視
 対策:cluster 内に踏み台 (step pod) をおき、ssh over ssm で aws credential + 
 ssh credential で踏み台に入る
 → ログインを ssh に強制することで console log の取得と権限制御が容易に
 console log を S3 に保存

Slide 55

Slide 55 text

55
 踏み台 (step pod) - 権限管理・運用監視
 ● 背景・課題
 ○ K8s cluster は kubectl をつかうことで様々な操作が可能
 ○ 実行できる条件を適切に制御しなければ重大なセキュリティリスクとなる
 
 ● 要件
 ○ [OK] 行使する user の制限
 ■ cluster にアクセス可能な user を制限
 ■ cluster の操作権限を user ごとに適正化
 ○ [OK] 実行経路の制限
 ■ api endpoint の公開範囲を適正化
 ■ kubectl のフル権限の行使を特定の経路に限定
 ○ [OK] 実施した内容の監視
 ■ api log を取りたい -> eksのlogging 機能で実現
 ■ pod 上での操作logを保存


Slide 56

Slide 56 text

56
 56
 まとめ
 05 Section

Slide 57

Slide 57 text

57
 ● Kubernetes に security をねじ込む要件
 ○ 外部から受ける攻撃 - 多層防御
 ○ 内部を経由した攻撃 - 監査対応
 ● Kubernetes に security をねじ込んだ全体像
 
 まとめ
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する 操作権限をしぼって 操作証跡を取る AWS WAF
 step Amazon GuardDuty 
 ③ Operation Operators


Slide 58

Slide 58 text

58
 freee のサイトへのアクセス


Slide 59

Slide 59 text

59
 K8s に移行したからといって、攻撃傾向に変化はない
 freee への攻撃


Slide 60

Slide 60 text

60
 現状
 ● セキュリティリスクを検知するために log を出力し alert を飛ばす仕組みを整えた
 ○ alert は大量に飛んでくる
 ● とはいえ、検知漏れは絶対にある
 ○ 新しい攻撃手法
 ○ 考慮漏れ
 
 
 TODO
 ● SIEM
 ○ 相関分析 → 障害予測、侵入検知
 ○ drill down → alert の原因切り分けの迅速化
 ● SOAR
 ○ 定型的な alert への対処の自動化
 ○ 開発を伴う対処の tracking
 future work


Slide 61

Slide 61 text

61
 freee のマイクロサービス基盤のセキュリティ強化に
 貢献してくれる方をお待ちしています!!!


Slide 62

Slide 62 text

62
 アイデアやパッションやスキルがあればだれでも、
 ビジネスを強くスマートに育てられるプラットフォーム スモールビジネスを、世界の主役に。