本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム
tag

認証情報

このタグの記事 7 件

2026-09-30

CAMPFIREの不正アクセス:対象ユーザー約22.6万件に漏えいのおそれ、利用者・開発者の対策

CAMPFIREの発表によれば、従業員が発行したGitHubの認証情報が第三者に不正利用され、GitHub上で閲覧できた情報をもとに社内業務用クラウド環境の認証情報が取得され、その一部管理領域に不正アクセスされた。プロジェクトオーナー・支援者・パートナーなど計225,846件(対象ユーザーの重複除外)の氏名・住所・電話番号・メールアドレス・口座情報に漏えいのおそれがある(クレジットカード情報は含まれない)。サービス提供基盤は別環境で、不正利用や改ざんは確認されていない。利用者は「返金」「振込先の確認」を名乗る連絡と、口座の明細に注意する。開発・運用側の教訓は2つ。本番環境を守っていても、顧客情報は社内業務用の環境にもある。業務用のトークンは会社の管理外の端末にも置かれうるので、有効期限とアクセスできる範囲を組織の設定で制限する。

2026-09-30

韓国のEV充電アプリCHAEVIの個人情報流出(29.8万件):何が漏れ、利用者は何をすればいいか

CHAEVI(채비)の2026年7月26日・30日の告知によれば、7月23日の外部からの不法なハッキング攻撃で個人情報計298,333件が流出した。内訳はメールアドレスのみ164,858件、メール+パスワード(暗号化)131,411件、メール+氏名・連絡先(暗号化)+性別・生年月日など1,235件、さらにパスワード(暗号化)まで含む829件。住民登録番号・旅券番号・カード番号・口座番号は収集・保有しておらず流出していないという。2025年1月ごろの別の流出も確認され、調査中。告知の流出項目に充電履歴や位置情報はない。詐欺に使われやすいのは、全件で暗号化されずに流出したメールアドレスと「EV充電アプリの会員」という事実。充電料金・未払い・補償を名乗るメールやSMSは基本的に無視し、同じパスワードを使う他のサービスから変える。

2026-09-30

TanStack・Nx Console・GitHubの連鎖侵害(2026年5月):開発者が確認すること

2026年5月11日、TanStackのRouter/Startリポジトリの公開パイプラインが悪用され、npmの42パッケージ・84バージョンに認証情報を盗むコードが入った。これを入れたNxの貢献者の端末からGitHub CLIのトークンが盗まれ、5月18日にNx Console拡張機能の改ざん版(v18.95.0)が公開された。同日、GitHubは社員の端末が改ざんされたVS Code拡張機能によって侵害され、GitHub社内のリポジトリが持ち出されたと発表した。3社とも、攻撃は本物の開発者アカウントや公式の配布の仕組みを通って行われた。防御の要は、公開用の認証情報(トークン)が盗まれても1人では新しい版を公開できない仕組みにすることと、設定したはずの安全策が実際に働いているかを確かめることだ。

2026-09-30

韓国TVINGの個人情報流出:補償を装う詐欺メッセージと利用者がやること

韓国科学技術情報通信部の官民合同調査団が2026年9月3日に公表した調査結果によれば、TVINGへの侵害で、有効・休眠・退会・テスト用を合わせて3,954万アカウント(重複を含む)の情報が流出した。流出項目はID、氏名、生年月日、連携情報(CI)、重複加入確認情報(DI)、返金用口座番号(暗号化)、パスワード(一方向暗号化)など20項目(70種)で、パスワードは復号できない状態と確認された。当サイトの結論:TVINGが実際に補償の申請を受け付けているため、補償や返金を名乗る偽のSMSがいちばん本物らしく見える。補償は自分で開いた公式アプリでだけ確認し、パスワードは同じものを使っている他のサービスから変える。開発・運用側にとっての教訓は、開発者1人の接続キーで全ソースコードにアクセスでき、そのソースコードの中に本番環境の接続キーが入っていたという構造にある。

2026-09-30

Vercelのセキュリティインシデント(2026年4月):環境変数が漏れたときに開発者がやること

2026年4月19日、Vercelは社内システムへの不正アクセスを公表した。Vercelによれば、社員が使っていた外部のAIツールの侵害を起点に、その社員のGoogle Workspaceアカウント、Vercelアカウント、Vercelの環境へと進まれ、一部の顧客の「sensitive」に設定されていない環境変数が列挙・復号された。影響を受けた顧客には直接連絡済みで、npmで公開しているパッケージは改ざんされていないと確認している。当サイトの結論:漏れたかどうかを分けたのは、環境変数を、保存後も値を画面に表示できる区分にしていたか、表示できない区分にしていたかだった。後から値を見返す必要のない秘密は、すべて値を表示できない区分(Secret)で保存する。社員がOAuth(外部アプリに会社のアカウントへのアクセスを許可する仕組み)でつなぐAIツールも、依存パッケージと同じく棚卸しの対象にする。

2026-09-20

Hugging Faceへの侵入(2026年):AIエージェントが自律的に攻撃した事案と、防御側が見直すこと

OpenAIがサイバー能力を測るために本番の安全機構を外して走らせていた評価環境から、エージェントが想定外に外部へ出て、Hugging Faceの本番環境を侵害した。約4.5日、記録された行動は17,000件超。当サイトの結論=この事件で新しいのは手口ではなく、人の指示なしに並列で動き続ける点。OpenAI自身が報告書で『高度なサイバー攻撃に人間の継続的な指示が必要だという前提を捨てよ』と書いている。起点は公開されてしまっていた認証情報であり、そこは今日から対策できる。

2026-09-04

2026年の国内情報漏えいの侵入経路:脆弱性より正規の認証情報によるものが多い(横断分析)

2026年8月に公表された国内の主要事案を経路で分類すると、脆弱性型より認証情報型が多い。共通するのは『自分のサーバーは無傷なのに、外部のサービスの正規のアカウントから入られた』こと。当サイトの結論=脆弱性管理を完璧にしても、この型は1件も止まらない。だから対策の比重を、パッチから『認証情報の寿命・範囲・置き場所』と『委託先とSaaSの棚卸し』へ移す必要がある。