tslogで実現するセキュアなメタデータ管理とロギング

Transcript

1. tslogで実現するセキュアな メタデータ管理とロギング 2024/11/16 TSKaigi Kansai @sugar235711
2. 2 sugar cat(@sugar235711) 仕事: SRE(オブザーバビリティ、インフラ構築) 興味: セキュリティ、パフォーマンスチューニング 登壇者情報 @sugar235711 @sugar-cat7
3. 3 この発表ではアプリケーションログを扱います。 ※アクセスログや監査ログ、システムログのようなものは扱いません。 この発表で扱うログ
4. 4 構造化ロギングを行うためのロギングライブラリ • Node.js/ブラウザどちらも対応 • 外部ライブラリへの依存なし • コードベースがTypeScript tslog概要
5. 5 構造化ロギングを行うためのロギングライブラリ • Node.js/ブラウザどちらも対応 • 外部ライブラリへの依存なし • コードベースがTypeScript tslog概要
6. 6 tslogでは2種類のログの形式での出力が可能 tslogと構造化ロギング Pretty JSON
7. 7 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について
8. 8 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について
9. 9 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について
10. 10 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について 内部関数
11. 11 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について 内部関数
12. 12 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について 内部関数
13. 13 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について これらのメソッドは オーバーライド可能
14. 14 デフォルトの設定のままシンプルにJSON形式でログを出力する tslogの内部実装について これらのメソッドは オーバーライド可能
15. 15 意図せず個人情報がログに含まれストレージに保存されているというのは よくある 一度保存されたログを削除したり、アーカイブ済みのものを操作するには コストや時間がかかる ログに含まれる秘匿情報について
16. 16 意図せず個人情報がログに含まれストレージに保存されているというのは よくある 一度保存されたログを削除したり、アーカイブ済みのものを操作するには コストや時間がかかる ログに含まれる秘匿情報について 出力前にマスキング or 意図しないフィールドであれば 削除する
17. 17 デフォルトでマスクキングを行える機構が 備わっている tslogでマスキングをする
18. 18 デフォルトでマスクキングを行える機構が 備わっている 再帰的にネストされたオブジェクトを探索 し、文字列の場合にreplaceを挟む あらゆる型、正規表現に対応するために重 そうな実装をしている tslogでマスキングをする
19. 19 デフォルトでマスクキングを行える機構が備わっている 再帰的にネストされたオブジェクトを探索し、文字列の場 合にreplaceを挟む あらゆる型、正規表現に対応するために重そうな実装をし ている tslogでマスキングをする
20. 20 あらかじめキーが分かっている場合であれば有用だが、意図せず混入した フィールドをマスキングするのは難しい 不要なフィールドを取り除く
21. 21 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 ユーザー入力を Parse 標準出力前に挟む文字列化するタ イミングでフィルタリング
22. 22 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 ユーザー入力を Parse →ZodでParse 標準出力前に挟む文字列化するタ イミングでフィルタリング
23. 23 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 ユーザー入力を Parse →ZodでParse 標準出力前に挟む文字列化するタ イミングでフィルタリング →JSON.stringifyの第二引数 (replacerでフィルタリング )
24. 24 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 標準出力前に挟む文字列化するタ イミングでフィルタリング →JSON.stringifyの第二引数 (replacerでフィルタリング ) ログ内部で付加される暗黙的 なメタデータについても最終 的な出力の型が決まっていれ ばフィルタリングができそう
25. 25 あらかじめキーが分かっている場合であれば有用だが、意図せず混入したフィールドをマスキングす るのは難しい 不要なフィールドを取り除く ログ出力時の型を定義し制御できないか🤔 標準出力前に挟む文字列化するタ イミングでフィルタリング →JSON.stringifyの第二引数 (replacerでフィルタリング ) ログ内部で付加される暗黙的 なメタデータについても最終 的な出力の型が決まっていれ ばフィルタリングができそう →出力の型から特定のフィー ルドを含まない含むのバリ デーションを自動生成できな いだろうか？
26. 26 TypeScriptの型情報を元にコンパイル時にValidationを生成することがで きるライブラリ Typia
27. 27 tscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする
28. 28 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする コンパイル後
29. 29 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする コンパイル後 バリデーションの ロジックが生成さ れている
30. 30 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする transportの処理を オーバライド
31. 31 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする transportの処理を オーバライド stringifyはrequiredな フィールドが欠けている 場合errorが投げられる のでisで安全に処理
32. 32 型を決めtscでコンパイルするとバリデーションされたstringifyが使える 型情報からフィルタリングをする 余分なフィールドが 除去されログが出力される (secret: “password”)
33. 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. 34 A.transportJSONをJSON.stringifyにした場合 B.transportJSONをJSON.stringify + loggerに渡すObjectをzodでパースした場合 C.transportJSONをtypiaを使用したstringifyにした場合 各手法の実行速度比較結果
35. 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. 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. 37 tslogとTypiaを組み合わせセキュアでハイパフォーマンスな構造化ロ ギングを行おう まとめ