アクセス制御
このタグの記事 20 件
トイポアプリへの不正アクセス（69万7,209名が対象と公表）：電話番号・氏名・住所などが漏えい、店舗のアプリ利用者がやること
株式会社トイポは、同社の顧客管理アプリ「トイポアプリ」への第三者による不正アクセスを2026年10月4日に確認し、10月14日付の「お詫びとお知らせ」で、対象ユーザーを697,209名と公表した（情報が漏えいした可能性があるとしている。同社の別のお知らせページは「漏えいしました」と書き、日付と人数の記載はない）。10月13日から、アプリ内のPush通知などで対象の人に個別に連絡している。同社によれば、一部のシステムで、認証されたユーザーが本来権限のない他のユーザーの情報を取得できるアクセス制御上の脆弱性があり、第三者がこれを利用してユーザー情報を取得した記録を確認した。脆弱性は修正済み。漏えいした情報は、電話番号、ユーザーID等の識別情報と、登録している場合の氏名・氏名カナ・メールアドレス・生年月日・性別・住所。パスワード等の認証情報、クレジットカード番号などの決済情報、ポイント情報、来店履歴、購買・利用履歴は含まれず、パスワード変更などの操作は必要ないとしている。具体的な二次被害は確認されていない。個人情報保護委員会へ報告済み。第三者機関によるセキュリティ評価・診断は実施に向けて調整中。利用店舗のお知らせでは、JR九州フードサービスが約61,500名のうち約26,900名、萬野屋の「杵屋萬野」公式アプリが212名のうち12名が対象。トイポの窓口は0120-546-030（平日9〜18時、コールセンターは10月30日18:00まで、以降はアプリ内の窓口）。当サイトの結論：電話番号と氏名が合う連絡でも本物とは限らない。リンクや番号を使わず、アプリ内の窓口か発表の窓口で確かめる。
コミューン「Commune」に不正アクセス（延べ16万6,505人）：企業コミュニティの会員情報が漏えい、会員と運営者がやること
コミューン株式会社は2026年10月9日、同社が運営する企業向けコミュニティサービス「Commune」「Commune for Work」が外部の第三者による不正アクセスを受け、一部のコミュニティで会員情報が漏えいしたと発表した。漏えいは10月5日18時ごろ〜6日21時ごろと、10月7日13時17分〜14時36分に起きた。第一報では、漏えいした会員を最大で約30.7万人（重複を除いた実人数の推計）としていたが、10月21日の続報で、詳しい調査の結果、漏えいの対象となった会員は16万6,505人（会員IDの単位でコミュニティごとに数えた延べ人数。同社が運営するコミュニティや検証用・デモ用のコミュニティを含み、攻撃者が作ったアカウントは含まない）、うちメールアドレスを含む情報が漏えいした会員は12万5,601人と確認した。それ以外の会員で漏れたのは、表示名・自己紹介・非公開グループの所属など。144人はパスワードが本人の操作によらず仮パスワードに変更された。パスワードそのもの、ダイレクトメッセージの漏えいは確認されておらず、決済情報は同社では保持していない。原因は、非公開コミュニティの招待リンクの不正な取得と、管理者へのなりすましと説明している。コミュニティを運営する利用企業も各自のお知らせを出しており、日本能率協会マネジメントセンターの「時間〈とき〉ラボ」ではプロフィール欄の氏名・住所・年齢・電話番号も漏えいした。コミューンは流出したメールアドレスの悪用を防ぐため10月10日0時50分から全コミュニティを止めて臨時メンテナンスを行い、管理者アカウントの二要素認証の必須化などの対策をとった。10月16日、希望した利用企業から順次、Webブラウザ版に限り一部の機能を制限して再開すると発表した（アプリ版、メールアドレスを使った新規登録、パスワードを忘れた場合の再設定は停止中）。臨時メンテナンスや検証で、新たな不正アクセスや漏えいは確認されていないとしている。10月21日の続報では、10月9日に総務省（関東総合通信局）へ速報を出したこと、警察署へ相談を始めたこと、ログの全件解析で攻撃者が残したプログラム・アカウント・設定などは確認されていないこと、第三者機関によるフォレンジック調査の準備を進めていることも公表した。当サイトの結論：参加しているコミュニティの運営企業のお知らせで対象かを確かめ、コミュニティ名を名乗るメールのリンクは開かない。
不正アクセスの注意喚起（2026年10月・国家サイバー統括室／IPA／JPCERT/CC）：今週やる点検と、異常が見つかったときの順番
2026年9〜10月に国内で不正アクセスによる情報漏えいの公表が相次ぎ、10月9日に内閣官房 国家サイバー統括室とIPAが、10月8日にJPCERT/CCが注意喚起を出した。IPAは原因を特定の製品の脆弱性とは断定しておらず、外部公開アプリ・サービスやアカウントの侵害が起点とみられるとしている。今週やることは、①外部公開アプリの洗い出しとログ確認（直近1か月→その後3か月）②クラウド・VPNなど外部サービスのログイン失敗・接続元・身に覚えのないアカウントの確認③保有データの再点検と最小化。異常があればセキュリティインシデントと判定し、ログを残して専門家に調査を頼み、個人情報保護委員会へ報告する。当サイトの視点＝点検でログが1か月分しか残っていないと分かったら、それ自体が直すべき結果。
ローソンIDに不正アクセス（215万5,345件）：メールアドレス・氏名などが漏えい、会員とアプリ予約の利用者がやること
株式会社ローソンは2026年10月8日、アカウントサービス「ローソンID」と、季節の催事商品をアプリから予約・決済できる「ローソンアプリ予約」に第三者による不正アクセスがあり、個人情報が漏えいしたと発表した。10月7日の調査で、9月12日〜14日にローソンID、9月17日にアプリ予約が不正アクセスを受けていたことが分かった。漏えいを確認した情報は、ローソンIDが215万5,345件（メールアドレス、氏名。ローソンIDを使ったプレゼントの応募などで入力されている場合は性別・電話番号・住所・メルマガ取得情報も）、アプリ予約が26件（氏名、電話番号、クレジットカード番号の一部）。同社は、アプリに関連するシステムが不正に利用され、アプリ上で利用者本人に情報を表示するためのセキュリティ機構が不正アクセスを受けたと説明している。発表の項目にパスワードは含まれていない。10月8日時点で不正利用や二次被害は確認されておらず、10月13日には、個別の案内メールの送信元アドレスに「lawson_id@id.lawson.jp」を追加した。当サイトの結論：ローソンIDを持つ人は、ローソンやポイント・クーポンを名乗るメールやSMSのリンクを開かず、確認は自分で開いた公式アプリで行う。
NewsPicksの個人情報漏えいのおそれ（カード名義・下4桁など最大36.2万件）：管理ツールへの不正アクセスで何が漏れたかと、利用者がやること
株式会社ユーザベースは2026年10月8日、同社が運営する「NewsPicks」で業務に使う管理ツールが第三者による不正アクセスを受け、利用者の個人情報の一部が外部へ漏えいした可能性があると発表した。10月9日の第二報では、管理ツールの脆弱性を突かれたものとし、最大想定件数として、ウェブ決済に関わるカード情報の一部（カード名義・番号の下3桁または下4桁など）36.2万件、メールアドレス32.3万件、所属先の役職の分類27.3万件、所属6.5万件、氏名5.9万件などを公表した。カード番号の全体とセキュリティコードは同社のシステムに保存しておらず漏えいしていない、パスワードの漏えいも確認されていないとしている。二次被害は確認されていない。当サイトの結論：カードの末尾の数字や勤務先を知っている連絡でも、それだけで本物と判断しない。リンクは開かず、確認は自分で開いた公式アプリやサイトで行い、カードの利用明細を見ておく。
skyticket（アドベンチャー）への不正アクセス（約1,464万件）：パスワードや返金先の口座情報、一部の利用者のカード情報が流出、利用者が今日やること
株式会社アドベンチャーは2026年10月9日、同社が運営する比較予約サイト「skyticket」で、それぞれ経路の異なる3件の不正アクセスがあったと発表した。1件目は管理機能の不正な操作を起点に、他のサーバーとクラウド上のデータへ不正にアクセスされたもので、約1,464万件の氏名（パスポート表記を含む）・生年月日・メールアドレス・電話番号・住所・振込時の依頼人名義が流出し、このうち約413万件はハッシュ化した会員パスワードを含む。2件目は業務管理システムの脆弱性の悪用で、返金先の口座情報などを含む17,780件（重複を含み、ほかに件数を調査中のものがある）が流出した、または流出したおそれがある。3件目はバスの予約完了ページがログインなしで表示できる状態になっていたもので、約12,000件の予約情報が閲覧された、または閲覧されたおそれがある。同社は当初、カード番号は流出した情報に含まれないとしていたが、10月16日の第2報でこれを訂正し、2017年2月〜2018年6月に「skyticketプレミアム」の会費の支払いにクレジットカードを登録・利用した最大6,140名のカード番号・名義人名・有効期限（一部は番号のみ、セキュリティコードは含まない）が、1件目の不正アクセスで流出したと発表した。会員特典の福利厚生サービスの会員ID・氏名・パスワードも流出した。パスポートの画像は流出しておらず、10月9日の発表時点で確認された二次被害は会員1名のアカウントへの不正ログインのみとしている（第2報は、流出したカード情報の不正利用の有無に触れていない）。当サイトの結論：会員は公式サイトかアプリからパスワードを変え、同じパスワードを使っていた他のサービスも変える。対象期間にskyticketプレミアムの会費の支払いにカードを登録・利用した人は、10月以降のカードの利用明細を確かめる。返金・補償・予約変更を名目にした連絡には応じず、口座の暗証番号や認証コードは誰にも伝えない。
国税庁e-Taxで他人の贈与税申告書が閲覧可能に（79人分）：見えた情報と、e-Tax利用者・開発者がやること
国税庁は2026年10月2日、e-Tax（国税電子申告・納税システム）のマイページで、79人分の贈与税申告書などが本人以外の利用者から閲覧できる状態だったと発表した。報道によれば、期間は9月24日8時30分〜25日0時と、25日4時〜15時58分。実際に他人の申告書を閲覧した可能性があるのは19人で、申告書に記載された贈与者や税理士を含め、計203人分の個人情報が見られた可能性がある。原因は9月24日に行ったマイページの「贈与税関係情報」の機能を充実させる改修で生じた不具合で、不具合は解消済み。国税局や税務署の職員が対象者に個別に連絡し、閲覧した可能性のある19人には秘密の保持と削除を依頼した。保存の形跡や二次被害は確認されていない。同時期の新しい基幹システム（KSK2）の不具合とは関連がないとしている。当サイトの結論：対象者には税務署側から個別に連絡が行っている。この件をきっかけにした電話やSMSには、国税庁の案内どおり、一度切って自分で調べた税務署の番号にかけ直す。開発者は、利用者Aとして利用者Bのデータを要求したら拒否されることを、改修のたびに自動テストで確かめる。
Companies House WebFiling不具合（2026）｜役員情報の露出と確認
英国の会社登記所Companies Houseは2026年3月13日、WebFilingにログインした登録利用者が、特定の操作をすると他社の情報を見たり変更したりできる可能性がある問題を把握し、同日13時30分にサービスを停止、3月16日9時に再開した。同機関によれば、原因は2025年10月11日の大規模なシステム更新で入った不具合（defect）で、外部からのサイバー攻撃ではない。見えた可能性があるのは、取締役と重要な支配権を持つ者（PSC）の生年月日の『日』、自宅住所、会社の登録メールアドレスで、同意のない届け出（新しい決算書や取締役の変更など）も技術的には可能だった。パスワード、本人確認のデータ、既存の届け出書類は影響を受けていない。4月8日の更新では、ごく少数の不正アクセスや変更の試みを確認したとしている。これは外部からの侵入ではなく、認可（アクセス権の確認）の不具合だ。ログインの確認は機能していたが、その利用者がこの会社の情報を扱ってよいかの確認が抜けていた。取締役は届け出履歴を確かめ、届け出があるたびにメールが届くFollowに登録する。開発者は、他人のデータを要求したら拒否されることを、更新のたびにテストで確かめる。
クラウドストレージの公開設定ミス：パブリックアクセスのブロックを有効にしても漏れる場合
バケットからの漏えいは攻撃ではなく設定で起きる。公式ドキュメントの要点は『パブリックアクセスブロックは既存のポリシーやACLを変更しない』——つまりブロックを有効にしても公開設定は残り、外せば公開が戻る。だから目標は『ブロックが有効』ではなく『ブロックを外しても公開されない状態』。ブロックはバケット単位でなくアカウント単位で掛ける（バケットポリシーはバケット側の設定を無効化できるため）。そして『公開』の定義は直感より広い。
ファイルアップロードの脆弱性とは — Webシェル/RCEを防ぐ設計と設定
アップロードの脆弱性で問題になるのは『受け取ること』ではなく『どこに置き、実行させてしまうか』。認証なしの投稿口＋型検証なし＋Web公開領域に保存＋そこでスクリプトが実行できる、が揃うとWebシェル→RCEで乗っ取られる。守りは多層：①エンドポイントに認証/権限＋CSRF②サーバー側で許可リスト＋中身検査③保存先はWeb公開領域の外（or実行無効化）④ファイル名を乱数化しパスは信用しない。1つの対策に頼らず、各段階で止められる対策を複数持つ。
OWASP Top 10 とは：Webアプリで最も重大な10のリスクをまとめたリスト
OWASP Top 10 は、非営利団体 OWASP が数年ごとに公開する『Webアプリで最も重大な10大リスク』のリスト。開発者・運営者の共通言語として広く使われる。最新の2025年版(2025年11月発表)でも筆頭は『アクセス制御の不備(Broken Access Control)』で、設定ミスが2位に上がり、ソフトウェアのサプライチェーンの不備と、例外状態の不適切な処理が新たに加わった。SSRF は1位のアクセス制御の不備に統合された。個別の攻撃手法ではなく“リスクのカテゴリ”なので、自分のアプリを点検する観点として使うのが正しい。
PCI DSS とは：クレジットカード情報を扱うためのセキュリティ基準
PCI DSS(Payment Card Industry Data Security Standard)は、カード情報を保存・処理・伝送する事業者が満たすべき国際的なセキュリティ基準。カード国際ブランドが策定し、ネットワーク保護・保存データの暗号化・アクセス制御(必要最小限)・監視/ログ・脆弱性管理などを要求する。実務で最も安全なのは『自前でカード番号を保持せず、準拠済みの決済代行(トークン化)に任せて適用範囲を最小化する』こと。
ASP.NET Coreのセキュリティ対策 — 本番ハードニング実務リファレンス
ASP.NET Coreは成熟して安定したフレームワークだが、事故は設定から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝本番で詳細エラー/開発者例外ページを露出しない・秘密の外部化(User Secrets/環境/Key Vault)・NuGet依存CVE・認可([Authorize]・フォールバックで既定拒否・リソースベース/所有者)・over-posting(DTO/[Bind])・安全でないデシリアライズ(BinaryFormatter回避)・HTTPS/ヘッダ/antiforgery・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Djangoのセキュリティ対策 — 本番ハードニング実務リファレンス
Djangoは標準で多くの安全な既定(ORM・CSRF・自動エスケープ・認証)を備えるが、事故は設定から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝本番DEBUG=False＋ALLOWED_HOSTS・SECRET_KEYの外部化・pip依存CVE・本番セキュリティ設定(SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE等)・認可(所有者スコープ)・インジェクションと出力(raw/extra・mark_safe)・CSRF/セッション/管理画面・SSRF/アップロード (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Express（Node.js）のセキュリティ対策 — 本番ハードニング実務リファレンス
Expressは最小構成で、既定ではほとんどセキュリティ対策をしない。対策は開発者が自分で追加する。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝セキュリティヘッダ(helmet)＋x-powered-by無効化・依存(npm)CVE・入力検証とインジェクション(SQL/NoSQL演算子)・認証と所有者スコープの認可・レート制限とサイズ上限・セッション/Cookie/CSRF・SSRF・本番のエラー処理(スタック非露出)・NODE_ENV (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Laravelのセキュリティ対策 — 本番ハードニング実務リファレンス
Laravelの既定は安全寄りだが、本番事故は設定・運用から起きる。本ページは実務リファレンス。(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)危険な既定設定の一覧表 (3)領域別の具体対策＝秘密/APP_KEY・本番設定(APP_DEBUG/キャッシュ)・認可(Policy/Gate・Mass Assignment)・インジェクション/出力(Eloquentバインド・Blade)・セッション/CSRF/Cookie・アップロード・HTTPS/ヘッダ/レート制限・依存(Composer)CVE (4)自己検証チェック。攻撃手順は扱わず、防御と点検に限定。
Next.jsのセキュリティ対策 — 本番ハードニング実務リファレンス
Next.jsの既定は安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝境界と環境変数(NEXT_PUBLIC_)・依存CVE(本体RCE含む)・Server Actions/Route Handlersの認可＋入力検証・SSRF(サーバー側fetch)・セキュリティヘッダ/CSP・認証/セッション/Cookie・レート制限 (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Ruby on Railsのセキュリティ対策 — 本番ハードニング実務リファレンス
Railsは規約と安全な既定(CSRF保護・Strong Parameters・ORM)を備えるが、本番事故は運用から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝秘密とcredentials(master key/secret_key_base)・本番設定(force_ssl・例外非露出)・gem CVE・Strong Parameters/Mass Assignment・認可(Pundit等・所有者スコープ)・インジェクションと危険メソッド(where連結/send/constantize)・セッション/Cookie/CSRF・SSRF/アップロード (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
認証と認可の違い：ログイン機能だけでは他人のデータは守れない
認証＝『誰か』を確かめること、認可＝『その人が何をしてよいか』を決めること。両者は別物で、ログインを付けただけでは認可にならない。データに所有者（user_id）でのスコープが無いと『ログイン＝全データ閲覧』になる（OWASP最上位の Broken Access Control）。さらに認証スキャフォールドの登録開放が重なると、第三者が登録して中に入れる。守りは、全クエリを所有者で絞る／不要な登録を閉じる／多層防御／監査・アクセスログを事故の前から残す／新規登録を検知。
IDORとは：IDを書き換えるだけで他人のデータが見えてしまう脆弱性
IDORは、?id=124 を 125 に書き換えるだけで他人の請求書・個人情報が見える、アクセス制御不備の脆弱性。基本の防御は『サーバー側で“このログイン中の利用者が、この対象を見てよいか”を毎回チェックする』。推測されにくいIDは対策にならない。