cndt2020

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

View Slide

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

View Slide

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

View Slide

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

View Slide

5 
5 
freee について 
01
Section

View Slide

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

View Slide

7 
 
PRODUCTS

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

18 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
image から脆弱性を
排除する

View Slide

19 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
排除する

View Slide

20 
① CI/CD
Users 
攻撃を検知 / 遮断する
request 
EKS 
ECR 
ALB 

View Slide

21 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
AWS WAF 
Amazon GuardDuty  

View Slide

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

View Slide

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

View Slide

24 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
操作権限をしぼって操
作証跡を取る
③ Operation
Operators 

View Slide

25 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
作証跡を取る
step
③ Operation
Operators 

View Slide

26 
Kubernetes に Security をねじ込んだ全体像 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
排除する
作証跡を取る
AWS WAF 
step
③ Operation
Operators 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

31 
Image 作成
ECR 
APP  
Engineers 
image push
脆弱性が検知されたこ
とを通知 
CI Pipeline 
commit 
脆弱性を確認 / 修正 

View Slide

32 
Image 作成
ECR 
APP  
Engineers 
image push
脆弱性が検知されたこ
とを通知 
CI Pipeline 
commit 
脆弱性を確認 / 修正 

View Slide

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

View Slide

34 
① CI/CD
Users 
request 
EKS 
ECR 
ALB 
AWS WAF 
外部から受ける攻撃の対策 = 多層防御システムの構築 

View Slide

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

View Slide

36 
Firehose
audit-bridge
system call
audit log
default rule
.....
custom rule
.....
filtering
rule と照合
CloudWatch
system call は直接収集 / audit log は audit-bridge を活用 

View Slide

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

View Slide

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

View Slide

39 
node へのインストールは kube-node-init を活用 
node の install 時だけ起動するように nodeAffinity で制御 
node-init
node の初期化処理をする daemonset で
DeepSecurity を install

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

56 
56 
まとめ 
05
Section

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

cndt2020

cndt2020

yamamo

Other Decks in Technology

Featured

Transcript