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
200
tslogで実現するセキュアなメタデータ管理とロギング
sugar-cat
November 16, 2024
Tweet
Share
More Decks by sugar-cat
See All by sugar-cat
最近個人開発が熱い ~モニタリング強化編v0.1.0~
sugarcat7
3
300
Honoで実現するバックエンド開発のイマ
sugarcat7
17
2.3k
GoとWASI~超入門~
sugarcat7
2
210
最近個人開発が熱い ~多言語対応編~
sugarcat7
1
230
ボイラープレート自動生成ツールを使わなくなった話.pdf
sugarcat7
4
490
Using_Hono_in__B2B_SaaS_Application.pdf
sugarcat7
6
350
Introduction to Database Connection Management Patterns in TypeScript.pdf
sugarcat7
1
350
Azure Container AppsのSecret管理とIaC
sugarcat7
1
190
最近個人開発が熱い
sugarcat7
15
14k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Agile that works and the tools we love
rasmusluckow
327
21k
Done Done
chrislema
181
16k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
400
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Designing Experiences People Love
moore
138
23k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
We Have a Design System, Now What?
morganepeng
50
7.2k
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を組み合わせセキュアでハイパフォーマンスな構造化ロ ギングを行おう まとめ