午前2時のモーニングコール
火曜日の午前2時。ナイトスタンドに置かれたスマートフォンが、SIEMからの相次ぐアラートで振動します。別のタイムゾーンの不明なIPアドレスから「ログイン成功」の通知。心臓が跳ね上がります。MFA(多要素認証)やWAFを導入し、OSSECですべてのログを監視していても、侵入者は内部にいます。彼らは派手で自動化されたエクスプロイトを実行しているわけではありません。代わりに、ファイル共有を静かに閲覧し、「重要資産(Crown Jewels)」を探しています。これはシステム管理者にとって最悪のシナリオ、すなわち「沈黙の侵入」です。
Suricataのような従来のツールは、既知攻撃パターンを特定するのに優れています。しかし、攻撃者が有効な資格情報を手に入れると、正当なユーザーと全く同じように見えます。彼らを捕まえるには、受動的な対応をやめ、欺瞞(デセプション)を取り入れる必要があります。そこで登場するのがCanarytokensです。これらはデジタルの地雷であり、触れられた瞬間にアラートを発する、目立たない小さな罠です。
欺瞞 vs 従来の検知:ノイズの問題
ほとんどのセキュリティスタックは、シグネチャ(既知の「悪意ある」ファイルの検索)またはアノマリ(「奇妙な」動作のフラグ立て)に依存しています。その結果、SOCチームは毎日5,000件のアラートに溺れ、その99%はノイズです。最終的に、誰もアラートを見なくなります。
Canarytokensは異なります。これらは**デセプション・テクノロジー(欺瞞技術)**のファミリーに属します。銀行の金庫に隠されたインクパックのようなものだと考えてください。これらには業務上の目的はありません。正当な従業員が、サーバーの /tmp フォルダに隠された salaries_2024.xlsx という名前のファイルを開くことはまずありません。もしそのファイルにアクセスがあれば、それは「アノマリ(異常)」ではなく「確定したインシデント」です。このアプローチにより、誤検知率を極めて低く抑え、セキュリティチームが本当に必要とする高精度の信号を提供できます。
「カナリア」を導入するメリットとデメリット
インフラ中に罠を仕掛ける前に、トレードオフを理解しておく必要があります。欺瞞は強力ですが、戦略的な思考が求められます。
メリット
- 高精度のアラート: 正当な用途がないため、トリガーされたら即座に「レッドアラート」となります。データのフィルタリングに大規模なチームは必要ありません。
- パフォーマンスへの影響ゼロ: ほとんどのトークンは静的なファイル、URL、またはDNSエントリです。本番環境のデータベースを遅くしたり、重いエージェントを必要としたりすることはありません。
- 境界を越えた検知: 攻撃者が盗んだデータを自分のマシンに持ち帰り、オフラインで開いたとしてもアラートを発するトークンもあります。
現実的な課題
- 一度限りの罠: トークンが一度トリガーされると、罠の存在が露呈します。同じレベルのセキュリティを維持するには、交換する必要があります。
- 警戒される可能性: 洗練された攻撃者がハニートークンの使用に気づくと、より慎重に動くようになるかもしれません。これは時間を稼ぐことにはなりますが、追い出すのが難しくなる可能性もあります。
- 自動化が鍵: 500台以上のサーバーがある環境では、スクリプトなしでこれらの「ハニーファイル」を手動で管理するのは困難です。
視認性を最大化するための戦略的配置
トークンをランダムにばらまいてはいけません。新しい環境を要塞化する際、私は以下の価値の高いターゲットを優先します:
1. 「管理者」のデコイ
Webサーバーにデコイの設定ファイルを配置します。偽の資格情報を含む db_backup.sh という名前のファイルは絶好の餌です。これらを本物らしく見せるために、私は toolcraft.app/ja/tools/security/password-generator のパスワードジェネレーターを使用しています。ブラウザ上で完全に動作するため、機密性の高い文字列がネットワークに流れることはありません。これにより、熟練の攻撃者が本番スクリプトに期待するような、複雑で現実的なパスワードを生成できます。
2. 「機密」ドキュメント
Officeドキュメント(Word/Excel)やPDFを共有フォルダに置きます。侵入者がこれらを開くと、ドキュメントが固有のURLに「実家連絡(コールホーム)」します。これにより、攻撃者のIPアドレスとユーザーエージェント文字列を即座に取得できます。
3. クラウドの資格情報
~/.aws/credentials に偽のAWS APIキーを挿入します。攻撃者がこれらをAWS CLIで使用しようとすると、コマンドの実行が完了する前にCanarytokensサーバーがその試行をログに記録します。
実装ガイド:最初の罠を仕掛ける
canarytokens.org の無料サービスを利用するか、独自のインスタンスをホストしてメタデータのプライバシーを保つことができます。
ステップ1:Webバグ(URLトークン)
これは最もシンプルな罠です。固有のURLを生成し、誰かがそこを訪れるとアラートを受け取ります。「README」ファイルや社内Wikiページの中で使用してください。
# 偽の本番環境ファイルにCanary URLを追加する
echo "DEBUG_ENDPOINT=http://canarytokens.com/about/tags/your-unique-token/post.jsp" >> .env.production
ステップ2:魅力的なWordドキュメント
1. Canarytokenコンソールを開きます。
2. 「MS Word Document」を選択します。
3. メモ(例:「財務共有フォルダで発見」)と通知先メールアドレスを入力します。
4. ファイルをダウンロードし、Q3_Payroll_Unredacted.docx(第3四半期給与未編集版)のような、抗いがたい名前に変更します。
5. 監視対象のユーザーグループがアクセス可能なネットワーク共有に配置します。
ステップ3:Linuxの「設定」罠
複雑なフォルダトリガーの代わりに、偽のSSH秘密キーを /home/user/.ssh/id_rsa_backup に配置します。キーのコメントフィールドや、近くの config ファイルに、固有のDNSトークンを含めます。攻撃者がそのキーに関連付けられた「内部」ホスト名を解決しようとすると、DNSルックアップによってアラームが作動します。
ステップ4:SQL Serverトリガー
データベースに、決してクエリを投げてはいけない「Sensitive」テーブルを作成します。誰かが SELECT 文を実行すると、UNCパスを介して強制的にDNSルックアップを行うトリガーを付与します。これは、不正なDBAやSQLインジェクション攻撃を捕まえる素晴らしい方法です。
-- UNCパスを介したSQL Serverの強制DNSルックアップ
CREATE TRIGGER [Trp_SensitiveTable_Access]
ON [SensitiveTable]
FOR SELECT
AS
BEGIN
-- CanarytokenサーバーへのDNSリクエストを強制する
EXEC master..xp_getfiledetails '\\your-token-id.canarytokens.com\a.txt';
END;
トリガーへの対応
午前2時にアラートが届いても、パニックにならないでください。Canarytokensのトリガーは高精度ですが、それは調査の始まりであり、終わりではありません。これでタイムスタンプとIPアドレスが手に入りました。
すぐにこのデータをVPNログやEDRツールと比較してください。トークンがトリガーされたため、攻撃者がどのセグメントを探索しているかが正確に分かります。この情報を利用して、影響を受けるサブネットを隔離したり、攻撃者がさらに移動(ピボット)する前に侵害された資格情報を変更したりしてください。欺瞞はMFAの代わりにはなりませんが、セキュリティにおいて最も価値のある資産である「時間」を稼いでくれます。

