cndt2020

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

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

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

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

5  5  freee について  01 Section

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

7    PRODUCTS

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

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

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

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

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

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

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

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

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

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

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

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

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

request  EKS  ECR  ALB  AWS WAF  Amazon GuardDuty   外部から受ける攻撃を防ぐ 

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

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

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

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

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

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

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

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

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

ECR  脆弱性スキャン APP   Engineers  image push 脆弱性が検知されたことを通知  CI Pipeline  commit  脆弱性を確認 / 修正 

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

request  EKS  ECR  ALB  AWS WAF  Amazon GuardDuty   外部から受ける攻撃の対策 = 多層防御システムの構築 

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

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 を活用 

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

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

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

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

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

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

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

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

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 を上げる

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

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 の移行時に漏れていた  セキュリティ対策の発見にもつながる    輸送  遠隔操作 

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

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

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

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

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

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

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 に保存

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

56  56  まとめ  05 Section

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

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

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

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

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

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

cndt2020

cndt2020

Other Decks in Technology

Featured

Transcript