FIDO2/パスキー認証

概要 パスワード認証は秘密そのものをネットワーク送信するため本質的に脆弱。FIDO2 は秘密鍵をデバイス内(TPM・Secure Enclave)に保管し、署名のみ送信。チャレンジ・レスポンス方式でリプレイ攻撃不可能。 3層フィッシング防御 ブラウザがオリジン情報を認証器に伝達 認証器がドメイン一致を検証 サーバーがオリジン情報を最終検証 普及状況 Google 8億+アカウント、Amazon 1.75億人が利用。日本証券業協会が OTP を非推奨化しパスキー推奨。楽天証券・SMBC 日興証券が導入。 関連ページ メール認証(SPF/DKIM/DMARC) — 別のなりすまし防止技術

2026年4月6日 · 1 分

GitHub Actions スクリプトインジェクション対策

概要 ${{ }} テンプレート式はシェル起動前に展開されるため、攻撃者制御のコンテキスト(PR タイトル・ブランチ名・Issue 本文)をそのまま run に埋め込むとコマンドインジェクション成立。 対策 env で環境変数に渡して ${VAR} で参照 actionlint・zizmor で自動検出 サードパーティ Actions はコミットハッシュでピン留め

2026年4月6日 · 1 分

メール認証(SPF/DKIM/DMARC)

概要 SPF: 送信元 IP アドレス検証 DKIM: 電子署名で改ざん検知 DMARC: 両者の結果に基づきポリシー実行(none/quarantine/reject) 日本の現状 上場企業 3,745 社調査で DMARC 未設定 34.5%、p=none(監視のみ)52.0%。実効的な reject+quarantine はわずか 13.4%。18か国中最下位。

2026年4月6日 · 1 分

プロンプトインジェクション

概要 ユーザー入力を指示として実行する設計の脆弱性。検索入力やファイル内容に「今後の指示を無視して○○をしろ」と埋め込まれる。エージェント普及で更に深刻化。 対策 CLAUDE.md のルール記述は「お願い」に過ぎず、プロンプトインジェクションで回避可能 実効的防御はシステムレベルの制約(サンドボックス、deny ルール、PreToolUse フック) devcontainer での完全隔離が最も堅牢 関連ページ AI エージェント — 攻撃対象となるシステム Claude Code — セキュリティ機能の実装 ソース記事 Vibe Hacking — 2026-03 Claude Code セキュリティシアター — 2026-03

2026年4月6日 · 1 分

NemoClaw触ってみた:OpenClawのセキュリティ問題を解消できるのか?

NVIDIAがGTC 2026(2026年3月16日)で発表した「NemoClaw」は、OpenClawのセキュリティ・プライバシー層を強化するオープンソーススタックです。OpenClawの競合ではなく、OpenClawを包み込む構造になっており、企業や業務利用での安全なAIエージェント運用を実現することを目指しています。 本記事では、NemoClawとは何か、OpenClawとの関係、ポリシーファイルの設定方法、導入フロー、実際に触れてみての所感をまとめます。 NemoClawとは NemoClawはNVIDIAが発表したOpenClaw専用のセキュリティプラグインです。内部では OpenShell というサンドボックスランタイムを使い、AIエージェントをLinuxコンテナで隔離します。ファイルシステム・ネットワーク・プロセスをポリシーで制御し、OpenClaw単体では防ぎきれなかったセキュリティ上の問題に対処します。 構成は以下の3層です: OpenShell: 汎用サンドボックスランタイム。AIエージェントをLinuxコンテナで隔離 NemoClaw: OpenClaw専用プラグイン(セキュリティ・プライバシー層) OpenClaw: サンドボックス内で動作するエージェント本体 OpenClawのセキュリティ問題とは OpenClawには tools.deny による制限機能がありますが、アプリケーション層での制御であるため、バグや迂回経路が発見されると突破されてしまうリスクがあります。プロンプトインジェクション攻撃によるデータ漏洩や、意図しないシステムコールの実行が代表的な懸念点です。 セキュリティの4層防御 NemoClawは以下の4層でセキュリティを確保します: 層 技術 ファイルシステム Landlock LSM(カーネルモジュール) ネットワーク egress proxy + アプリケーション単位制御 プロセス seccomp + コンテナ隔離 推論 ゲートウェイ経由ルーティング 最大の特徴は「アプリ層ではなくカーネル層で強制される」点です。OpenClawの tools.deny と異なり、バグや迂回方法が発見されても突破できません。 ネットワーク制御の仕組み NemoClawのネットワーク制御は Deny by default が原則で、全通信がデフォルトでブロックされます。許可は「アプリケーション×ホスト」の組み合わせで明示的に指定します。 例えば: git → GitHub接続を許可 curl → ブロック このような細粒度の制御により、仮にエージェントが悪意あるプロンプトインジェクションを受けても、データの外部流出が不可能になります。 ポリシーファイル ポリシーはYAML形式で宣言的に記述します。読み書き可能なパス、ネットワーク接続先、許可するバイナリを定義でき、GitOpsでの運用も可能です。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # ポリシーファイルの例(概念的な構成) filesystem: read: - /workspace - /home/agent write: - /workspace/output network: allow: - binary: git hosts: - github.com - api.github.com process: allow_binaries: - git - python3 - pip このようなポリシーファイルをリポジトリで管理することで、セキュリティ要件の変更履歴を追跡し、レビュープロセスを通じて変更を管理できます。 ...

2026年3月17日 · 1 分