セキュリティ対策
パスワード・MFA・端末・公共Wi-Fi・サーバー・依存関係・Git・公開環境。今日から手を動かせる「守り方」を、目的別の実務ガイドで。
ファイルアップロードの脆弱性とは — Webシェル/RCEを防ぐ設計と設定
アップロードの穴の本質は『受け取ること』ではなく『どこに置き、実行させてしまうか』。認証なしの投稿口＋型検証なし＋Web公開領域に保存＋そこでスクリプトが実行できる、が揃うとWebシェル→RCEで乗っ取られる。守りは多層：①エンドポイントに認証/権限＋CSRF②サーバー側で許可リスト＋中身検査③保存先はWeb公開領域の外（or実行無効化）④ファイル名を乱数化しパスは信用しない。1枚の壁でなく、各段の止め所を複数持つ。
ログインを付けただけで安心していないか — 認証と認可の違い
認証＝『誰か』を確かめること、認可＝『その人が何をしてよいか』を決めること。両者は別物で、ログインを付けただけでは認可にならない。データに所有者（user_id）でのスコープが無いと『ログイン＝全データ閲覧』になる（OWASP最上位の Broken Access Control）。さらに認証スキャフォールドの登録開放が重なると、第三者が登録して中に入れる。守りは、全クエリを所有者で絞る／不要な登録を閉じる／多層防御／監査・アクセスログを事故る前に／新規登録を検知。
パスワードの保管、みんなどうしてる？データで見る実態と安全な方法
代表的な調査では、約54%が記憶頼み・約33%が紙にメモ・パスワードマネージャー利用は約36%にとどまる。使い回しも約25%。一方 Verizon DBIR では漏洩の約38%に認証情報の侵害が関与し、漏洩DB内パスワードの約74%が使い回しだった。つまり“定番の保管法”ほど攻撃者に効く。安全な土台は、マネージャーで全部を別パスワードにし、重要アカウントはパスキー/MFAで守ること。
パスワードの安全な保存方法 — ハッシュ化とソルトの正しいやり方
サービス側でパスワードを安全に保存する実践ガイド。平文・暗号化・素のハッシュがなぜダメかを理解し、『ユーザーごとのソルト＋わざと遅い専用ハッシュ（Argon2id推奨、次点bcrypt/scrypt）』に集約する。自前実装せず標準関数を使い、コストは定期的に見直し、既存の弱いハッシュはログイン時に再ハッシュして移行する。
AI時代のセキュリティ対策｜個人開発者がいま固めるべき基本（優先順チェックリスト）
AIは“新しい弱点”より“既存の弱点を自動で・大量に突く”側を強くする。だから特別な新対策より、基本を正しい順で固めるのが最善の備え。CVE即パッチ＋依存監視、使い回し撲滅＋MFA、露出した秘密の除去、最小権限、公開面の縮小、ログ/IOCの備え、バックアップ——優先順チェックリストで。
AI時代に効くセキュリティ対策と“効かない”もの｜小規模でも狙われる理由
AI時代の4つの神話を正す。①小さいから狙われない→自動化が『人間が選ぶ』を消す②特別な新対策が要る→基本が最強③製品を入れれば安心→検知より起こさない設計が先④AI生成コードは速くて安全→脆弱性ごと出荷・公開前レビュー必須。効くのは地味な基本を正しい順で。
自分のドメインからの“なりすましメール”が届いた——乗っ取りとの違いと止め方
自分のドメインを名乗る不審メールが届いても、多くは“サーバー侵害”ではなく“差出人(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つ要る——常時繋がったバックアップは本体ごと暗号化される。クラウド同期はバックアップではない(誤削除や暗号化も同期する)。世代管理と定期的な復元テストまでが運用。
gitleaksでコミット前に秘密を止める：APIキー漏洩をpushの前で食い止める
秘密は『漏れてから消す』では遅い。一度コミットされた秘密はGit履歴に残り、pushされたら漏れた前提で鍵の失効・ローテートが要る。gitleaksはリポジトリ全体とコミット履歴を正規表現/エントロピーでスキャンし、APIキー・秘密鍵・トークンを検出する無料ツール。守りの要は二段の止め所＝①pre-commitフックでローカルのpush前に止める②CI/cronですり抜けを定期的に捕まえる。.gitignoreは新規追跡を防ぐだけで検出はできない＝検出器が別途要る。
二要素認証(MFA)の正しい選び方：SMSより強い「フィッシング耐性」とは
MFAは『パスワードが漏れても入られない』ための二重ロックだが、何を付けたかで強さが3段違う。SMS/メールはフィッシング中継・SIMスワップで破られる弱い方式、認証アプリ(TOTP)は中、パスキー/物理キー(FIDO2)は偽サイトに出せない『フィッシング耐性』で別格。最優先は王国の鍵（メール・ドメイン・決済）にフィッシング耐性MFAをかけること。リカバリーコードの保管とバックアップ手段の用意までが正しい運用。
Windows 10をまだ使っている人へ：サポート終了後のセキュリティリスク
Windows 10は2025年10月14日でサポート終了済み。使い続ける最大のリスクは『見つかっても二度と直らない穴（forever-day）』が積み上がり、攻撃者に狙われやすくなること。個人向けESU延長は2026年10月13日までの1年だけ・セキュリティ修正のみの時間稼ぎ（無料の登録ルートあり、ただしEEA初年度無料は日本対象外）。本筋はWindows 11への移行か機器更新で、ESUはその移行を終わらせるまでの橋として使う。
BitLockerと『デバイスの暗号化』の違い — 同じ技術の、フル版と自動・簡易版
BitLockerとデバイスの暗号化は同じ暗号エンジン。デバイスの暗号化＝Homeでも使える自動・簡易版（MSアカウントで自動ON・回復キーも自動退避・設定最小）。BitLocker＝Pro以上のフル版（起動PIN・外付け暗号化(To Go)・細かい管理）。個人なら自動暗号化＋回復キーの所在把握で十分なことが多い。製品名より“暗号化されている状態”が本質。
脆弱性(CVE)対応の実務：直しきって、再発を監視し続ける手順
脆弱性対応は『直した』で終わらない。完了＝①スキャン②修正③隔離/引き継ぎ④監視の4点が揃って初めて。特に監視（日次の変化検知）を載せるまでは未完——依存は明日また脆弱になるから。修正の中身が100点でも、次のデプロイで消える運用なら0点。小さな現場こそ、自動の変化検知と『local→push→deploy』の規律で驚くほど守れる。
ノートパソコンを持ち歩くときのセキュリティ対策 — 盗難・紛失・覗き見への備え
ノートPC持ち歩きの前提は『いつか失くす・盗まれる』。本命は“失くしても中身が漏れない”設計＝①ディスク暗号化(BitLocker/FileVault) ②強いログイン+短い自動ロック ③遠隔ワイプ/位置追跡。公共Wi-FiはHTTPS普及で盗聴リスクが下がり、本当の脅威は偽AP・覗き見・離席。VPNを過信せず、暗号化とロックを最優先に。
osv-scannerの導入と使い方：依存パッケージのCVEを機械で見つける
osv-scannerはロックファイルやコンテナを走査して依存のCVEを洗い出す無料ツール。導入・実行・CI組込みを手順化し、npm/pnpm audit・Dependabotとの使い分けまで整理する。当サイトの視点＝ツール選びの正解は『あなたの構成』で決まる。複数言語混在やGitHub非依存ならosv-scanner、単一npmなら同梱のpnpm auditで十分。
パスワードマネージャーは安全？仕組みとクラウド・ローカルの違い、選び方
パスワードマネージャーは、使い回し・平文保存より確実に安全。鍵はゼロ知識暗号＝マスターパスワードで端末側だけが復号でき、提供元は暗号文しか持たないので、提供元が破られても中身は出ない。本当の単一障害点はマスターパスワードと金庫のMFA。クラウド型(Bitwarden/1Password)とローカル型(KeePass)を用途で選ぶ。
公共Wi-Fiの危険性 — 本当に怖いのは『盗聴』ではなく、偽APと証明書警告の無視
公共Wi-Fiの『盗聴』はHTTPS普及で大半が暗号化され、優先度は下がった。本当のリスクは①偽AP(evil twin)に自分から繋ぐ②証明書警告を無視する③同じネットワークに端末を晒す。最強の対策は意外とシンプル＝スマホのテザリングを使う・HTTPSと証明書警告を信じる・知らないSSIDに自動接続しない。VPNはその次の追加策。
公開ディレクトリに秘密ファイルを置き忘れていないか：webrootの棚卸し
webroot（公開ディレクトリ）に置いたファイルは、URLを叩けば誰でも取得できる。トークンや認証情報のJSON・.env・バックアップを置き忘れると即・実害。さらに共通テンプレート由来なら全サイトに同じ穴が横展開する。対策＝公開ディレクトリには公開してよい物だけ、秘密はwebroot外＋権限600、そして自分のサーバーを棚卸しして1か所見つけたら全台点検。
個人開発・小規模運営のセキュリティ最低限：業界標準の対策を全部セットで
最低限の対策は『全部同じ重さ』ではない。当サイトの優先順位＝①王国の鍵（多要素認証・ドメイン・メール）②秘密とコード③アプリ本体④パッチ・検知・復元。リソースが有限な個人は、この順で上から埋めるのが正解。多くの事故は新種の攻撃ではなく、この土台の抜けから起きる。
中規模〜大規模組織のセキュリティ最低限：チームで守る標準の土台
規模が上がると最低限は『チェックリスト』から『オーナーのいるプログラム』に変わる。優先順位は個人版と同じ＝①アイデンティティ②秘密とサプライチェーン③アプリと基盤④検知と対応＋横断の人とガバナンス。最大の変化は、事故の主因が『うっかり』から『人・プロセス・退職者の権限・第三者』へ移ること。
セキュリティの棚卸し — 複数サーバーを個人運用する人が見落とす点検7項目
複数サーバーを個人運用する人の事故は「足りない対策」より「把握していない状態」が原因になりがち。守る境界は鍵を置いたPC。2FAは信頼の連鎖でティア化、SSH鍵はマトリクス化して重複・未使用・孤児を消す、平文パスワードはクラウドから消す、是正は可逆に1つずつ、台帳に機密は書かない。派手な新ツールより棚卸しが先。
自前のGitサーバーとGitHub、セキュリティ的にどっちが安全か
自前Gitは『安全になる』のではなく『リスクを移し替える』。誤公開という事故クラスは消えるが、サーバのパッチ・バックアップ・コミット前の秘密検出という責任が自分に移る。条件を満たせば良い選択、放置すればGitHubより危険。当サイトの視点＝自前運用は代償とセットでなければ成立しない。
スマホを安全に使う基本 — 守るべきは『鍵束・金庫・身分証』が1台に詰まった端末
スマホは二要素・メール・銀行・身分証が1台に集中した単一障害点。守りの本命はセキュリティアプリでなく、①強いロック＋短い自動ロック（パスコードが暗号化の鍵）②OS/アプリ自動更新 ③公式ストア＋権限見直し ④紛失時の遠隔ロック/ワイプを事前設定 ⑤二要素の“予備”（紙のバックアップコード）。OSは標準で暗号化・サンドボックス済み。
侵害され得る環境にroot鍵を渡さない：SSH鍵の最小権限
一時的で侵害され得る環境（GPU pod・CIランナー・使い捨てVM）から本番へroot鍵を登録すると、その環境が侵害された瞬間に本番がroot権限で抜かれる。対策＝一時環境にroot鍵を置かない／使わなくなったら消す／再度必要なら非rootユーザー＋command制限鍵（command="..." restrict）で操作を1つに限定。使い回し鍵は最重要資産で、1つ漏れたら全部、という構成を作らない。
パスワードをGoogleドライブに保存するのは安全？正しい保管方法
平文のGoogleドキュメント/スプレッドシートにパスワードを一覧保存するのは危険。理由＝Googleアカウント1つが全パスワードの単一障害点になり、乗っ取り・不正連携アプリ・フィッシングで一気に全部漏れる。正解は専用パスワードマネージャ（端末間でも中身は暗号化）。どうしてもDriveを使うなら暗号化済みの管理ファイルだけ＋アカウントにフィッシング耐性MFA。
OpenAIアカウントBANの理由と対処——盗まれたAPIキーが『蒸留』違反に問われるとき
盗用されたAPIキーが『蒸留』に悪用されると、被害者のアカウントまで自動凍結されることがある。仕組み・予防・異議申し立ての筋道を、固有の事例情報を伏せて整理します。
X-Forwarded-For（XFF）偽装とは — 信頼するプロキシ設定の落とし穴と防御
XFFはクライアントが詐称できるヘッダ。偽XFFにインジェクション探索を仕込む無差別スキャンの典型と、『全プロキシ信頼（ワイルドカード）』の危うさ。対症療法＝IPヘッダのサニタイズ、根本＝信頼するプロキシの適正化。実害ゼロでも直すべき設定がある。
AIで書いたコードからAPIキーが漏れ、不正課金された——本当の原因は放置したCVSS 10.0だった
請求の暴騰は氷山の一角。真因は放置した公開済みCVSS 10.0のRCEだった。固有名詞を伏せた事例から、防御の教訓を抽出します。
セキュリティ超入門：.env と APIキーは何が危なくて、どう守るのか
最初の一歩。.env と APIキーが漏れると何が起きるか（合鍵→なりすまし→不正課金）を理解し、『公開しない・コミットしない・漏れたら全部替える・自己点検する』の4つを今日から始める。
Laravelアプリの .env が全世界に公開されていた——共用レンタルサーバーで一番ありがちな配置ミス
原因は『アプリ本体をpublic_html直下に置いた』こと。public/ だけを見せるべきだった。応急処置→鍵ローテ→構造改修の三段で直し、再発を仕組みで防ぐ。
Next.js を安全に運用する：公開済みCVEに後れを取らないしくみ
フレームワークの最大リスクは公開済みCVEの放置。実稼働版で判定し、Dependabot/osv-scannerで機械監視、迅速更新、最小権限の4本柱で守る。当サイトの視点＝個人開発者が負けるのは知識でなく『運用の継続性』。速さより見落とさない仕組みで勝つ。
レンタルサーバーで .env を公開しないための配置と設定
本命は『アプリ本体をdocrootの外、public/ だけ公開』。まず .htaccess で止血し、構造改修で恒久化、最後に自己点検。当サイトの視点＝これは個人のミスでなく業界的な“悪手の標準化”。だから注意力でなく仕組みで防ぐ。symlinkより bootstrap-redirect が堅い。