cndt2020

C744faee2ae82c1c4378e84d56daf5a8?s=47 yamamo
September 09, 2020

 cndt2020

C744faee2ae82c1c4378e84d56daf5a8?s=128

yamamo

September 09, 2020
Tweet

Transcript

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


  2. 2
 freee 株式会社 SRE チームに所属
 ◦ 2019 年 2 月入社


    ◦ 以前はミドルウェア開発に従事
 ◦ EC2 環境の canary release 導入 / インフラリソースの最適化 / 新規サービスのインフラ構築 など
 山本 佳代子
 2 freee 株式会社
 Kayoko Yamamoto
  3. 3
 K8s 上でサービスをセキュアに運用するために行っている取り組みについて
 • 世の中にあるセキュリティソフトウェアの導入
 ◦ 導入時の課題や工夫点
 • 自製している仕組み
 ◦

    妥当なツールが見つからなかったもの
 ◦ もっとよいやり方があるよ!というアイディアお持ちの方大募集
 
 お話ししないこと
 • EKS を選定した経緯や理由
 • 導入したソフトウェアの詳細な技術
 本日お話しすること

  4. 4
 Overview
 01 freee について
 03 EKS へ Security をねじ込む方法

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

  5. 5
 5
 freee について
 01 Section

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

  7. 7
 
 PRODUCTS

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


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

    freee導入により経理部門を立て直し 月間で約70時間削減
  10. 10
 受託業務に係る内部統制の保証報告書 
 (SOC1 Type2 報告書)を受領
 SOC保証とは
 • 上場企業が自社の財務報告がきちんとしていることを保証するもの 


    • 利用している情報システム(会計ソフト) も監査の対象
 → システムベンダーも監査を受ける
 SOC1 Type2 報告書とは
 • システムベンダーが別途監査法人に監査を依頼し、その結果受けた報告書
 • ユーザー企業が監査を受けた際にはこの報告書を提出

  11. 11
    EC2 ベース
 
 創業時〜2年前くらいまでにリ リースされたサービス
    EKS ベース


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

  12. 12
 SRE と PSIRT の JOINT Project として活動を実施
 メンバー紹介
 kawamura


    yamamoto
 liva
 Taichi
 eiji
 杉浦 英史
 SRE PSIRT
  13. 13
 13
 freee のマイクロサービス基盤に
 Security をねじ込むには
 02 Section

  14. 14
 Kubernetes に Security をねじ込む要件
 • 外部から受ける攻撃 - 多層防御
 ◦

    internet facing
 ◦ 常に攻撃はされている,,,
 ◦ 攻撃を検知して、対処を早めに始めたい
 
 • 内部を経由した攻撃 - 監査対応
 ◦ restricted access path
 ◦ もしもの事態に備えて、
 ◦ 変更 / 操作の証跡を残したい

  15. 15
 ロッキードマーチンが提唱するフレームワーク
 攻撃は7つの段階で行われる
 多層防御 - Cyber Kill Chain
 Weaponization 
 Instration 


    Delivery 
 Command & Control
 Actions on Objectives
 Recoinnaissance 
 Exploitation 
 偵察
 武器調達
 輸送
 攻略
 潜入
 遠隔操作
 奪取
 SNS, URL, Wi-Fi, 
 メール 収集
 SNS, web, 
 メール
 アクセス
 人 + 物の
 脆弱性を
 突く
 投稿文面, botnet,
 脆弱性... 
 常駐
 プロセス
 確保
 通信路 確保
 探索
 目的達成
 証拠隠滅

  16. 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. 17
 ① CI/CD Users
 request
 EKS
 ECR
 ALB
 外部から受ける攻撃を防ぐ
 ②

    Service Providing
  18. 18
 ① CI/CD Users
 request
 EKS
 ECR
 ALB
 image から脆弱性を

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

    排除する 外部から受ける攻撃を防ぐ
 ② Service Providing
  20. 20
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する

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

  21. 21
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する

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

  22. 22
 主な監査ポイント
 • 開発に関わる重要なアカウントの管理運用の統制が取れていること
 ◦ github アカウント、本番サーバーアクセスアカウント、admin アカウント
 • 統制が取れた運用の元にソースコードの改変が行われていること


    ◦ 思いつきや悪意による改変が行われないか
 • 本番サーバーのアクセス統制が取られていること
 ◦ 勝手に会計情報を改竄できない仕組みになっている
 ◦ 証跡を追うことができる
 • etc...
 内部を経由した攻撃 - 監査対応

  23. 23
 内部を経由した攻撃を防ぐ
 ① CI/CD Users
 ② Service Providing request
 EKS


    ECR
 ALB
 ③ Operation Operators

  24. 24
 内部を経由した攻撃を防ぐ
 ① CI/CD Users
 ② Service Providing request
 EKS


    ECR
 ALB
 操作権限をしぼって操 作証跡を取る ③ Operation Operators

  25. 25
 ① CI/CD Users
 ② Service Providing request
 EKS
 ECR


    ALB
 操作権限をしぼって操 作証跡を取る step ③ Operation Operators
 内部を経由した攻撃を防ぐ

  26. 26
 Kubernetes に Security をねじ込んだ全体像
 ① CI/CD Users
 ② Service

    Providing 攻撃を検知 / 遮断する request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する 操作権限をしぼって操 作証跡を取る AWS WAF
 step Amazon GuardDuty 
 ③ Operation Operators

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

    Section
  28. 28
 外部から受ける攻撃の対策 = 多層防御システムの構築
 ① CI/CD Users
 ② Service Providing

    request
 EKS
 ECR
 ALB
 image から脆弱性を 排除する
  29. 29
 trivy - コンテナの脆弱性排除
 攻略
 OSS の image 脆弱性スキャンツール
 •

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

  30. 30
 trivy で脆弱性が見つかったら CI を落とす trivy - コンテナの脆弱性排除
 Image 作成

    ECR
 脆弱性スキャン APP 
 Engineers
 image push CI Pipeline
 commit

  31. 31
 trivy で脆弱性が見つかったら CI を落とす trivy - コンテナの脆弱性排除
 Image 作成

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

  32. 32
 trivy で脆弱性が見つかったら CI を落とす trivy - コンテナの脆弱性排除
 Image 作成

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

  33. 33
 trivy - コンテナの脆弱性排除
 攻略
 OSS の image 脆弱性スキャンツール
 •

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

  34. 34
 ① CI/CD Users
 ② Service Providing 攻撃を検知 / 遮断する

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

  35. 35
 falco - pod の振る舞い / K8s api 監視
 攻略


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

  36. 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. 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. 38
 潜入
 EKS の node 全体のセキュリティリスクを検知する
 TrendMicro 社が提供する all-in-one security

    sensor
 • 悪意ある通信を screening する IPS 機能
 • file access 時に signature match を行う AntiMalware 機能
 
 
 DeepSecurity - node 内のセキュリティリスク検知

  39. 39
 node へのインストールは kube-node-init を活用
 node の install 時だけ起動するように nodeAffinity

    で制御
 node-init node の初期化処理をする daemonset で DeepSecurity を install DeepSecurity - node 内のセキュリティリスク検知

  40. 40
 潜入
 DeepSecurity - node 内のセキュリティリスク検知
 EKS の node 全体のセキュリティリスクを検知する


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

  41. 41
 奪取
 cilium - firewall in cluster
 K8s cluster 内のネットワークをコンテナレベルで監視

    / 制御する
 eBPF 上に構築された Open Source の CNI
 • L3 / L4 / L7 でネットワークポリシーの制御が可能
 • namespace / tag によるネットワークポリシーの制御が可能

  42. 42
 Security group cilium - firewall in cluster
 security group

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

    の場合、lateral movement に気づけない
 service A kube-system service B
  44. 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. 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. 46
 奪取
 cilium - firewall in cluster
 コンテナ間の不審な通信を検知し、遮断
 K8s cluster

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

  47. 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
 48
 EKS へ Security をねじ込む方法 2
 - 内部を経由した攻撃への対策
 04

    Section
  49. 49
 内部を経由した攻撃への対策 = SOC1 Type2 監査対応
 ① CI/CD ③ Operation

    Operators
 Users
 ② Service Providing EKS
 ECR
 ALB
 step 操作権限をしぼって操 作証跡を取る request

  50. 50
 踏み台 (step pod) - 権限管理・運用監視
 • 背景・課題
 ◦ K8s

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

  51. 51
 踏み台 (step pod) - 権限管理・運用監視
 operators ID/key service namespace

    IAM user で認証 cluster admin に mapping 行使する user の制限
 IAM user を aws-auth configmap で K8s の group と対応付ける
 課題:IAM 認証情報が漏れると revoke されるまで任意の操作が可能

  52. 52
 踏み台 (step pod) - 権限管理・運用監視
 operators AWS STS temporal

    service namespace RBAC で認証 service adminにmapping 行使する user の制限
 対策: IAM user の発行をせず、Onelogin 連携で MFA + 一時的に有効な credential をつかう

  53. 53
 踏み台 (step pod) - 権限管理・運用監視
 operators temporal service namespace

    local から K8s api endpoint に 向けて kubectl を実行 実行経路の制限 + 実施した内容の監視
 Onelogin 連携で MFA + 一時的に有効な credential をつかう
 課題:権限取得後は任意の経路で api アクセスできる & pod 内での活動の log が取れない

  54. 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. 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
 56
 まとめ
 05 Section

  57. 57
 • Kubernetes に security をねじ込む要件
 ◦ 外部から受ける攻撃 - 多層防御


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

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


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


  60. 60
 現状
 • セキュリティリスクを検知するために log を出力し alert を飛ばす仕組みを整えた
 ◦ alert

    は大量に飛んでくる
 • とはいえ、検知漏れは絶対にある
 ◦ 新しい攻撃手法
 ◦ 考慮漏れ
 
 
 TODO
 • SIEM
 ◦ 相関分析 → 障害予測、侵入検知
 ◦ drill down → alert の原因切り分けの迅速化
 • SOAR
 ◦ 定型的な alert への対処の自動化
 ◦ 開発を伴う対処の tracking
 future work

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


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