AI時代の備え
このタグの記事 13 件
Linuxカーネル脆弱性 CVE-2026-98432：ネットワーク越しに突かれうるTCPの欠陥（CVSS 9.8）。修正版を入れて再起動し、MPTCPも確認
CVE-2026-98432は、LinuxカーネルのIPv4 TCP処理にある解放後使用（use-after-free）の脆弱性で、2026年10月15日に公表されました。カーネル開発チームの採番機関はCVSS v3.1で9.8（ネットワーク越し、権限不要、利用者の操作不要）と評価しています。AI企業の研究チームが、Multipath TCP（MPTCP）で待ち受けるサーバーに対し、実験環境でroot権限のリモートコード実行を実演したと報じられています（同社自身の報告にもとづき、報道機関は検証していません）。BleepingComputerは、MPTCPを使わないTCPサーバーでのリモートコード実行は公には示されておらず、実際の攻撃も確認されていないと伝えています。当サイトは11月1日時点で、米CISAのKEVにこのCVEが載っていないことを確認しました。上流の修正は5.10.272・5.15.223・6.1.190・6.6.159・6.12.113・6.18.56・7.2.10以降で、11月1日時点でDebianは修正版を出し、SUSEは一部を出し、UbuntuとRed Hatは修正を準備中としています。MPTCPを止めるだけでは完全な対策になりません。当サイトの結論：インターネットに公開したLinuxサーバーから、修正版が出た順に更新して再起動し、それまでは配布元の一時しのぎを使ってください。
AI時代のセキュリティ対策｜個人開発者がいま固めるべき基本（優先順チェックリスト）
AIは“新しい弱点”より“既存の弱点を自動で・大量に突く”側を強くする。だから特別な新対策より、基本を正しい順で固めるのが最善の備え。CVE即パッチ＋依存監視、使い回しの解消＋MFA、露出した秘密の除去、最小権限、公開面の縮小、ログ/IOCの備え、バックアップ——優先順チェックリストで。
AI時代に効くセキュリティ対策と効かない対策：小規模サイトでも狙われる理由
AI時代の4つの誤解を正す。①小さいから狙われない→自動化された攻撃は人間が標的を選ばない ②特別な新対策が要る→基本対策が最も効く ③製品を入れれば安心→検知より事故を起こさない設計が先 ④AI生成コードは速くて安全→脆弱性を含んだまま公開されることがあり、公開前レビューが必須。効くのは地味な基本対策を正しい順で進めること。
自分のドメインを名乗るなりすましメールが届いたとき：乗っ取りとの見分け方とSPF・DKIM・DMARCでの止め方
自分のドメインを名乗る不審メールが届いても、多くは“サーバー侵害”ではなく“差出人(From)の詐称”。SMTPはFromを自由に書けるため。ヘッダのAuthentication-Results・Received・Reply-Toを読めば侵害か詐称か見分けられる。受信箱まで届く主因はDMARC未設定。SPF→DKIM→DMARC(p=none→reject)の段階導入で止める。
バックアップの基本：3-2-1ルールとランサムウェアに耐える復元計画
バックアップは『取ってある』では不十分で、『復元できると確認済み』のものだけが役に立つ。基本＝3-2-1ルール(3コピー・2種類のメディア・1つはオフサイト)。さらにランサム対策には、常時接続でない『オフライン/不変(immutable)』のコピーが少なくとも1つ要る——常時繋がったバックアップは本体ごと暗号化される。クラウド同期はバックアップではない(誤削除や暗号化も同期する)。世代管理と定期的な復元テストまでが運用。
多要素認証(MFA)の選び方：SMS・認証アプリ・パスキーの違い
MFAは異なる種類の要素を2つ以上使う認証で、2FAはそのうち2種類を使うもの。手順が二段階あるだけではMFAとは限らない。手入力のコードはフィッシング耐性がなく、SMSではSIMスワップにも注意する。重要なアカウントはフィッシング耐性のある方式を優先し、パスキーのPIN・生体認証による利用者確認、同期・復旧の条件も確かめる。
脆弱性(CVE)対応の実務：直しきって、再発を監視し続ける手順
脆弱性対応は『直した』で終わらない。完了＝①スキャン②修正③隔離/引き継ぎ④監視の4点が揃って初めて。特に監視（日次の変化検知）を載せるまでは未完——依存は明日また脆弱になるから。修正の中身が100点でも、次のデプロイで消える運用なら0点。小さな現場でも、自動の変化検知と『local→push→deploy』の規律で十分に守れる。
osv-scannerの導入と使い方：依存パッケージのCVEを自動で見つける
osv-scannerはロックファイルやコンテナを走査して依存のCVEを洗い出す無料ツール。導入・実行・CI組込みを手順化し、npm/pnpm audit・Dependabotとの使い分けまで整理する。当サイトの考え：どのツールが合うかは自分の構成で決まる。複数言語混在やGitHub非依存ならosv-scanner、単一npmなら同梱のpnpm auditで十分。
パスワードマネージャーは安全？仕組みとクラウド・ローカルの違い、選び方
パスワードマネージャーは、サービスごとに強い別パスワードを使うための道具です。ゼロ知識暗号は提供元から暗号化データが漏れた際にも内容を守る設計ですが、安全はマスターパスワードの強さや暗号化設定、端末の安全性にも左右されます。MFAで不正ログインも防ぎ、クラウド型とローカル型を用途で選びます。
公開ディレクトリに秘密ファイルを置き忘れていないか：webrootの棚卸し
webroot（公開ディレクトリ）に置いたファイルは、URLを叩けば誰でも取得できる。トークンや認証情報のJSON・.env・バックアップを置き忘れると即・実害。さらに共通テンプレート由来なら、全サイトの同じ場所に同じファイルがある。対策＝公開ディレクトリには公開してよい物だけ、秘密はwebroot外＋権限600、そして自分のサーバーを棚卸しして1か所見つけたら全台点検。
個人開発・小規模運営のセキュリティ最低限：業界標準の対策と優先順位
最低限の対策は『全部同じ重さ』ではない。当サイトの優先順位＝①管理者アカウント・ドメイン・メール（多要素認証）②秘密とコード③アプリ本体④パッチ・検知・復元。リソースが有限な個人は、この順で上から埋めるのが正解。多くの事故は新種の攻撃ではなく、これら基本対策の抜けから起きる。
SSH鍵の最小権限：侵害されるおそれのある一時環境に本番のroot鍵を置かない
一時的で侵害され得る環境（GPU pod・CIランナー・使い捨てVM）から本番へroot鍵を登録すると、その環境が侵害された時点で本番にroot権限で入られる。対策＝一時環境にroot鍵を置かない／使わなくなったら消す／再度必要なら非rootユーザー＋command制限鍵（command="..." restrict）で操作を1つに限定。使い回している鍵は最も重要な資産として扱い、1つ漏れたら全サーバーに入られる構成を作らない。
AIで書いたコードからAPIキーが漏れ、不正課金された事例：原因は未修正のCVSS 10.0の脆弱性
急増した請求は症状にすぎず、原因は修正せずに放置した公開済みCVSS 10.0のRCEだった。固有名詞を伏せた事例から、防御の教訓を抽出します。