Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
tslogで実現するセキュアなメタデータ管理とロギング
Search
sugar-cat
November 16, 2024
4
1.1k
tslogで実現するセキュアなメタデータ管理とロギング
sugar-cat
November 16, 2024
Tweet
Share
More Decks by sugar-cat
See All by sugar-cat
ErrorTrackingとOrchestrion
sugarcat7
0
180
DiscordとCloudflare
sugarcat7
1
170
Cloudflare Workflowsを使いたい倒したい
sugarcat7
6
1.2k
最近個人開発が熱い ~モニタリング強化編v0.1.0~
sugarcat7
3
360
Honoで実現するバックエンド開発のイマ
sugarcat7
22
5k
GoとWASI~超入門~
sugarcat7
2
230
最近個人開発が熱い ~多言語対応編~
sugarcat7
2
260
ボイラープレート自動生成ツールを使わなくなった話.pdf
sugarcat7
4
600
Using_Hono_in__B2B_SaaS_Application.pdf
sugarcat7
6
460
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
How to Ace a Technical Interview
jacobian
276
23k
The World Runs on Bad Software
bkeepers
PRO
67
11k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
102
18k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
KATA
mclloyd
29
14k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
Done Done
chrislema
183
16k
Transcript
tslogで実現するセキュアな メタデータ管理とロギング 2024/11/16 TSKaigi Kansai @sugar235711
2 sugar cat(@sugar235711) 仕事: SRE(オブザーバビリティ、インフラ構築) 興味: セキュリティ、パフォーマンスチューニング 登壇者情報 @sugar235711 @sugar-cat7
3 この発表ではアプリケーションログを扱います。 ※アクセスログや監査ログ、システムログのようなものは扱いません。 この発表で扱うログ
4 構造化ロギングを行うためのロギングライブラリ • Node.js/ブラウザどちらも対応 • 外部ライブラリへの依存なし • コードベースがTypeScript tslog概要
5 構造化ロギングを行うためのロギングライブラリ • Node.js/ブラウザどちらも対応 • 外部ライブラリへの依存なし • コードベースがTypeScript tslog概要
6 tslogでは2種類のログの形式での出力が可能 tslogと構造化ロギング Pretty JSON
7 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について
8 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について
9 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について
10 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について 内部関数
11 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について 内部関数
12 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について 内部関数
13 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について これらのメソッドは オーバーライド可能
14 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について これらのメソッドは オーバーライド可能
15 意図せず個人情報がログに含まれストレージに保存されているというのは よくある 一度保存されたログを削除したり、アーカイブ済みのものを操作するには コストや時間がかかる ログに含まれる秘匿情報について
16 意図せず個人情報がログに含まれストレージに保存されているというのは よくある 一度保存されたログを削除したり、アーカイブ済みのものを操作するには コストや時間がかかる ログに含まれる秘匿情報について 出力前にマスキング or 意図しないフィールドであれば 削除する
17 デフォルトでマスクキングを行える機構が 備わっている tslogでマスキングをする
18 デフォルトでマスクキングを行える機構が 備わっている 再帰的にネストされたオブジェクトを探索 し、文字列の場合にreplaceを挟む あらゆる型、正規表現に対応するために重 そうな実装をしている tslogでマスキングをする
19 デフォルトでマスクキングを行える機構が備わっている 再帰的にネストされたオブジェクトを探索し、文字列の場 合にreplaceを挟む あらゆる型、正規表現に対応するために重そうな実装をし ている tslogでマスキングをする
20 あらかじめキーが分かっている場合であれば有用だが、意図せず混入した フィールドをマスキングするのは難しい 不要なフィールドを取り除く
21 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 ユーザー入力を Parse 標準出力前に挟む文字列化するタ イミングでフィルタリング
22 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 ユーザー入力を Parse →ZodでParse 標準出力前に挟む文字列化するタ イミングでフィルタリング
23 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 ユーザー入力を Parse →ZodでParse 標準出力前に挟む文字列化するタ イミングでフィルタリング
→JSON.stringifyの第二引数 (replacerでフィルタリング )
24 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 標準出力前に挟む文字列化するタ イミングでフィルタリング →JSON.stringifyの第二引数 (replacerでフィルタリング )
ログ内部で付加される暗黙的 なメタデータについても最終 的な出力の型が決まっていれ ばフィルタリングができそう
25 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 標準出力前に挟む文字列化するタ イミングでフィルタリング →JSON.stringifyの第二引数 (replacerでフィルタリング )
ログ内部で付加される暗黙的 なメタデータについても最終 的な出力の型が決まっていれ ばフィルタリングができそう →出力の型から特定のフィー ルドを含まない含むのバリ デーションを自動生成できな いだろうか?
26 TypeScriptの型情報を元にコンパイル時にValidationを生成することがで きるライブラリ Typia
27 tscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする
28 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする コンパイル後
29 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする コンパイル後 バリデーションの ロジックが生成さ れている
30 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする transportの処理を オーバライド
31 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする transportの処理を オーバライド stringifyはrequiredな フィールドが欠けている 場合errorが投げられる のでisで安全に処理
32 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする 余分なフィールドが 除去されログが出力される (secret: “password”)
33 A.transportJSONをJSON.stringifyにした場合 B.transportJSONをJSON.stringify + loggerに渡すObjectをzodでパースした場合 C.transportJSONをtypiaを使用したstringifyにした場合 [条件] 実行環境 アプリケーションサーバー(Node.js)が動くコンテナ(CPU 1、Memory
512MB)とリクエストを送るコン テナを用意し、autocannonで負荷をかける 負荷のかけ方 最初の3秒間でウォームアップを行い、その後30秒間にわたり、100同時接続しつつ10リクエストをパイプ ライン化して送信。コンテナを作り直し5回繰り返す 比較の仕方 30秒間で得た総処理数からrpsを計算 各手法の実行速度比較
34 A.transportJSONをJSON.stringifyにした場合 B.transportJSONをJSON.stringify + loggerに渡すObjectをzodでパースした場合 C.transportJSONをtypiaを使用したstringifyにした場合 各手法の実行速度比較結果
35 A.transportJSONをJSON.stringifyにした場合 B.transportJSONをJSON.stringify + loggerに渡すObjectをzodでパースした場合 C.transportJSONをtypiaを使用したstringifyにした場合 各手法の実行速度比較結果 ・BのZodを挟む場合は明らかに処理性能が落ちている ・A、Cのパターンではほぼ変わらない →渡されたオブジェクトが小さい、別の処理がボトル
ネックとなり、stringifyの性能の差ではあまり影響が なかった (Profileの結果console.logやstream関連の内部関数の 実行が支配的だった)
36 A.transportJSONをJSON.stringifyにした場合 B.transportJSONをJSON.stringify + loggerに渡すObjectをzodでパースした場合 C.transportJSONをtypiaを使用したstringifyにした場合 各手法の実行速度比較結果 ・BのZodを挟む場合は明らかに処理性能が落ちている ・A、Cのパターンではほぼ変わらない →渡されたオブジェクトが小さい、別の処理がボトル
ネックとなり、stringifyの性能の差ではあまり影響が なかった (Profileの結果console.logやstream関連の内部関数の 実行が支配的だった) →Typiaを使用する方法がセキュリティ、パフォーマン ス共に良い結果となった
37 tslogとTypiaを組み合わせセキュアでハイパフォーマンスな構造化ロ ギングを行おう まとめ