cndt2020 - Speaker Deck

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