年末年始に長い休みを取得できたので、2024年に会社で取り組もうとしている Detection Engineering の取り組みを自宅で素振りしてみました。短い期間だったのでツール自体やドキュメントの整備など至らぬ点はいろいろありますが、ひとまずこの記事ではその内容についてご紹介します。 モチベーション 今年取り組もうとしているDetection Engineeringを小さく試してみたかったという他にも、以下のようなモチベーションがありました。 1. 多数のデバイスがつながる自宅ネットワーク内の監視をしたい その昔、自宅のネットワークに接続しているものといえばたかだかパソコン程度のものでした。どのようなデバイスが繋がっているかも把握しやすく、セキュリティの観点からも管理しやすい状況でした。しかし今では自宅にはスマートフォンやタブレット、IoTデバイスなどありとあらゆるデバイスが接続され

この記事はUbie Engineering Advent Calendar 2023の2日目の投稿になります。UbieではこれからDetection Engineeringに対して取り組もうとしており、どのような課題があってどのように進めようとしているのか、についてご紹介したいと思います。 背景：セキュリティ監視の課題 サイバー攻撃の対策の一つにサイバー攻撃の検知や検知後調査のためのログ収集をする「セキュリティ監視」があります。セキュリティ監視は未然にインシデントを防ぐのはやや困難ですが、早期検知によるインシデントが発生した場合の被害の極小化、そして調査によって影響範囲の特定ができます。他の防御策と組み合わせて運用することで、ユーザの利便性を損なわずに高い安全性を提供することもできます。 Ubieではいまだに事業や組織が成長の段階にあり、様々な変化が日々起きています。そのような状況の中でセ

Go言語ではながらく公式のログ出力にlogパッケージが使われてきました。しかし昨今のクラウド環境などでのロギングでは構造化ログがほぼ必須であり、そのような流れを受けて公式の構造化ログパッケージ slog が提案されています。2023年8月にリリース見込みの Go 1.21 のリリースノートにはすでに掲載されており、1.21 で公式に取り込まれるのはほぼ確実かと考えられます。 背景：絶対にログに秘匿値を出力したくない オンラインサービスで出力されるログは様々な目的で利用されます。例えば、サービスの運用監視のためにログを集約してアラートを発生させたり、サービスの改善のためにログを集約して分析したり、サービスのセキュリティ監視のためにログを集約して不正アクセスを検知したり、などなど。また、ログは監査に利用されることもあり、原則として保管期間中は削除しない、できないということが前提として様々なログ

Go言語ではながらく公式のログ出力にlogパッケージが使われてきました。しかし昨今のクラウド環境などでのロギングでは構造化ログがほぼ必須であり、そのような流れを受けて公式の構造化ログパッケージ slog が提案されています。 この記事執筆時点で slog は正式に公式に取り込まれたわけではないですが、 1.21 のマイルストーンにはリストされており、それなりの確度で導入されると思われます。これを受けて自分が開発しているプロダクトでも徐々に slog の導入を進めています。 構造化ロギングのインターフェースが公式で定義されているのは良いことですし、JSONで出力する上でslogの利用は現状特に困ったことはありません。しかし同僚と slog の利用について話していたとき「開発時、コンソールに出力されるログが見づらい」という指摘がありました。確かに言われてみると（近代的なロガーと比べて）ちょっと

TL; DR GoのGenericsを活用したテストユーティリティを試験的に作ってみました。 こんな感じにテストを記述できます。 colors := ["red", "blue"] // NG: colors が配列なのに、文字型と比較しようとしてコンパイルエラーになる // gt.Array(t, colors).Equal("red") // NG: 配列同士だが、colorsは []string なのに対して []int を比較しようとしているのでコンパイルエラーになる // gt.Array(t, colors).Equal([]int{1, 2}) // ↓はOKでコンパイルはできる gt.Array(t, colors).Equal([]string{"red", "blue"}) // <- Pass gt.Array(t, colors).Have("orange") //

今や情報セキュリティはあらゆる分野で重要視されるようになっていますが、自分がしばらく働いているWebサービス関連の業界では「どの段階から情報セキュリティに取り組めばよいか？」という疑問がしばしば話題になります。昨今のWebサービスの多くは昔からのソフトウェアプロダクト開発における設計→開発→納品というフローで完結するものではなく、高速にプロトタイプを作成して価値検証を繰り返しながら、徐々にサービスとして成熟していくというモデルが多いと思います。その場合、最初から制約を厳しくしてしまうことでプロダクト開発のスピードが鈍化しProduct Market Fit（PMF）に至らない、というリスクが起こりえます。さらに厳しい制約を設けすぎることで逆に対策を無視する、という悪い文化が根付いてしまう恐れもあります。 この記事では自分がもし今から「自分でスタートアップを立ち上げ、あるいは立ち上げ直後のス

Go言語ではながらく公式のロガーとして log パッケージがありました。これは非常にシンプルなもので構造データをうまく表現できなかったりログレベルを分けるということができません。CLIで使うシンプルなインタラクションであればこれで十分なのですが、クラウド上のバックエンドで動かすサービスにとっては構造化ロギングやログレベルの出し分けは事実上必須であり、そのための機能は十分と言えませんでした。 これに対して様々なロガーが3rd party packageとして公開されてきましたが、一方で公式に導入されようとしているロガーもあります。それがslogです。まだ提案の段階ではありますが、現状で使える実装を触ってみたところかなり実用的な段階だなと感じたので、自分用の備忘録を兼ねてメモを残してみます。 サンプルコードはここにも置いてあります。 基本的な使い方 まず基本的な使い方を見てみます。ログ出力用に

これまでのあらすじ 前回執筆した記事がなかなかの好評をいただけたようなので、今回はより実践的な内容の説明をしたいと思います。前回の記事では全体イメージのわかりやすさ優先で細かい説明を端折っていました。今回は実際にどのようにASTを評価するのか、どのようなルールが書けるのか、テストはどうするのか、などについて説明します。 goastによるソースコード検査の仕組み まずはじめにgoastがどのような仕組みでGoのソースコードを検査するかの仕組みについて簡単に説明します。Goはastパッケージによってソースコードをparseすることで、Abstract Syntax Treeを作成します。非常に大雑把ではありますが、イメージとしては下図のようになります。 いろいろと省略していますが、基点となる構造体が ast.File というファイル全体を示すノード（ast.Node interface）となっ

TL; DR Go言語は様々な静的解析ツールがあるが、独自ルールのチェックなどをするには都度ツールを自作する必要がある 1つのツールでより汎用的なチェックができるように、汎用ポリシー言語のRegoでGo言語のAST（抽象構文木）を検査できるようにした 「第一引数に必ずcontext.Contextをとる」というルールをCIでチェックした様子 背景 Go言語では様々な静的解析ツールが提供されており、一般的なベストプラクティスが正しく記述されているか？については既存の静的解析ツールを利用することで概ね必要なチェックをすることができます。例えばセキュアなGoのコーディングをするためのツールとして gosec などがあり、自分も愛用させてもらっています。しかし、ソフトウェア開発におけるコーディング上のルールはベストプラクティスによるものだけでなく、そのソフトウェアやチームに依存したルールというのも

というのを作りました。 モチベーション The Twelve Factor App の設定でも推奨されている通り、昨今のCommand Line Interface (CLI) で利用するアプリケーションやCLIでの開発では環境変数を多用します。これによって多くの環境変数を扱ったり、環境変数に秘匿値を扱ったり、文字数の多い環境変数を扱ったり、という機会も増えました。 環境変数を使うためにはシェルに設定したり、昔ながらの env コマンドを使ったり、dotenvを使ったり、秘匿値を扱うenvchainなどといった便利なツールが用意されています。しかし、 それぞれを個別に使えるよりは統合的に環境変数を管理したい さらに高度な環境変数の設定機能を使いたい という2つの観点から新しいツールを実装しました。 基本的な使い方 zenvの機能は大きく分けると、 CLI上で環境変数を設定 .env ファイ