はてなブックマーク

本書では情報セキュリティ対策の一環であるセキュリティ監視を実現するための方法として、セキュリティ監視の基盤を自分で構築するために必要となる実践的な設計・実装方法について紹介します。セキュリティ監視基盤を内製する方だけでなく、既製ソフトウェア・サービスを利用して基盤構築しようとしている方にも参考になれば幸いです。

この記事はアドベントカレンダー「実践セキュリティ監視基盤構築」の24日目の記事です。これまでに、セキュリティ監視基盤の構築と実装について詳しく解説してきました。今回は、視点を変えて、セキュリティ監視に関する新しい概念やアイデアについてお話しします。 情報技術に関連する多様なソフトウェア、サービス、手法が進化する中で、それに対応するための概念も進化しています。わかりやすい例としてはDevOpsやSREがありますが、セキュリティ監視においても新たな取り組みが行われています。 従来のセキュリティ監視業務と課題 新しい概念について話す前に、従来のセキュリティ監視業務を振り返ってみましょう。これらは筆者が経験したり、伝聞した内容に基づくもので、古く偏った視点である可能性があります。 アラートの検知は、SIEMやIDSで提供されるデフォルトルールを使うことが多く、チューニングはルールのON/OFF程度

この記事は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です。まだ提案の段階ではありますが、現状で使える実装を触ってみたところかなり実用的な段階だなと感じたので、自分用の備忘録を兼ねてメモを残してみます。 サンプルコードはここにも置いてあります。 基本的な使い方 まず基本的な使い方を見てみます。ログ出力用に

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

前回のあらすじ 3年ほど前にAWS上にハニーポット環境を作成しました。 大雑把に説明すると、(主に)AWSのEC2インスタンスあてにどのようなexploitが飛んでくるのか?というのを知るために、 EC2インスタンスに管理用、および観測用のElastic IP addressを設定し、そこでハニーポットを動かす ハニーポットで取得した生データ(pcap)をS3に保存し、Lambdaで分析する 分析結果は CloudWatch Logs Insights で閲覧できるようにする という構成にしていました。これはこれでマネージドサービスを使った面白い構成だったと当時は思っていたのですが、実際に動かしてみるといくつかの課題があり、最終的には運用を止めてしまいました。 前回の課題 1) Elastic IP addressの制限でスケールしにくい EC2は自前で2つ以上のネットワークインターフェー

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

この記事はOPA/Regoアドベントカレンダーの2日目です。 今回はOPA/Regoそのもののではありませんが、前提となる考え方の Policy as Code の考え方について見ていきたいと思います。 Policy as Code とは 多くのプロダクトやサービスではポリシー(発生した事象や調査結果などに対して深刻度や対応方法を判断するルール)をリッチなGUIで設定したり、設定ファイル上で記述する、というのが一般的かと思います。またそもそも何かの判断はソフトウェア側でやるのではなく、人間が実施する、というケースも多くあるかと思います。これをわざわざRegoという言語で記述する理由については Policy as Code という考え方が参考になるかと思います。下記はOPAと直接関係ありませんが、terraformなどを開発するHashiCorpのプロダクトの一つ、Sentielのドキュメン

情報セキュリティの分野で注目されている汎用的なポリシーエンジンOPAと、OPAで利用するポリシー記述言語Regoについて解説します

この記事はOPA/Regoアドベントカレンダーの1日目です。 このアドベントカレンダーでは、最近セキュリティエンジニア界隈で注目されつつある汎用的なポリシーエンジンOPA(読み:オーパ)と、OPAで利用するポリシー記述言語Rego(読み:レゴ)について解説していきます。 初日はOPA/Regoについてのざっくりどういうものかを理解してもらうための概論になります。 OPA/Regoとは OPAはサービスやソフトウェアの意思決定機能を本体と分離するために作られたエンジンです。ここで言う「意思決定」とはいわゆる認可の話だけではなく、様々なことに応用できます。 Infrastructure as Code で記述された設定に危険な構成(例えばアクセス制御が適切でない)のチェック デプロイされたリソースがポリシーに準拠した設定・構成になっているかのチェック セキュリティスキャンで検出された結果に対し

TL; DR Goで秘匿値をログに出力しないようにする zlog というロガーを作りました。 以下、経緯や使い方の説明です。 背景:サーバーサイドにおけるロギングと秘匿値の問題 Webサービスを含む多くのサーバーサイドのサービスでは、サービスの挙動に関するログを出力・記録しておくのが一般的です。継続的にログを出力しておくことで、トラブルシューティングやデバッグ、セキュリティインシデントの対応や監査、性能改善の手がかりなどに活用することができます。ログに含まれる情報が多いほど問題を解決するための手がかりが増えるため、(限度はあるものの)なるべく多くの情報を掲載する、あるいは設定によって情報量を増やせるようにしておくと便利です。 しかし一方で、サーバーサイドで出力するのは望ましくない情報もあります。 認証に利用される情報:パスワード、APIトークン、セッショントークンなど、それを使うことで別の