Upgrade to Pro — share decks privately, control downloads, hide ads and more …

cndt2020

yamamo
September 09, 2020

 cndt2020

yamamo

September 09, 2020
Tweet

Other Decks in Technology

Transcript

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


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

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

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

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

  4. 10
 受託業務に係る内部統制の保証報告書 
 (SOC1 Type2 報告書)を受領
 SOC保証とは
 • 上場企業が自社の財務報告がきちんとしていることを保証するもの 


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

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


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

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


    yamamoto
 liva
 Taichi
 eiji
 杉浦 英史
 SRE PSIRT
  7. 14
 Kubernetes に Security をねじ込む要件
 • 外部から受ける攻撃 - 多層防御
 ◦

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

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


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

  9. 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
  10. 18
 ① CI/CD Users
 request
 EKS
 ECR
 ALB
 image から脆弱性を

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

  27. 38
 潜入
 EKS の node 全体のセキュリティリスクを検知する
 TrendMicro 社が提供する all-in-one security

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

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

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

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


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

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

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

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

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

    の場合、lateral movement に気づけない
 service A kube-system service B
  33. 44
 cilium - firewall in cluster
 namespace / role を理解する

    cilium で rule を定義する
 Security group service A kube-system service B • Service B だけ S3 に アクセス可能 • Service B だけRDS に アクセス可能 • namespace 間の通信 禁止
  34. 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 を 上げる
  35. 46
 奪取
 cilium - firewall in cluster
 コンテナ間の不審な通信を検知し、遮断
 K8s cluster

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

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

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

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

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

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

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

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

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

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

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

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

  42. 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 に保存
  43. 55
 踏み台 (step pod) - 権限管理・運用監視
 • 背景・課題
 ◦ K8s

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

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


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

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

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