Aikido Community Japan
464 posts
Aikido Community Japan
@AikidoCommJP
Aikido Securityの日本のコミュニティです。Aikido Securityのブログを日々日本語に要約して掲載してます。また、セキュリティについて、日本語で発信していきます。
Japan Katılım Şubat 2026
43 Takip Edilen341 Takipçiler
Aikido Securityが「Aikido Supply」開店。
中身は自社ノベルティ。
購入は現金不可。専用コインのみ。
コインをもらうには招待コードが必要。持ってない人は「ください」と申請する仕組み。
なぜか本気のルックブック動画付き
Aikido Security@AikidoSecurity
Aikido Supply is here 🥋💜 From Anti Magic Quadrant Club to Infinite, every campaign we've ever shipped now has a home.
日本語
同じ漏えい、違う通知 — 村田製作所インシデントに見る日米開示格差
ニチレイの影で、村田製作所の事件が静かに進行しています。2026年7月10日、グループ従業員向けの保険を扱う機関代理店・村田土地建物が、自動車保険契約者の情報漏えいを公表しましたが、世間の関心は大規模障害の方に向いたままです。
しかしこの事件、日本の発表を米国の公的記録と突き合わせると様子が変わります。日本では公表されていない情報が、米国では法定通知で開示されていました。
なぜか。
答えは村田の姿勢ではなく、制度にあります。
■日本の発表に「無い」もの
村田製作所は2026年2月28日に不正アクセスの可能性を認識し、3月6日に第一報、4月27日の第三報で、約8.8万件の個人情報が不正取得されたおそれがあると公表しました。銀行口座情報や健康情報を含む重い内容です。
しかし、どこにも書かれていないことがあります。
攻撃者が、いつから社内にいたのかです。
■米国の届出に「有る」もの
この事案では、村田製作所本体のIT環境への不正アクセスが、米州地域統括会社Murata Electronics North America（本社アトランタ）の従業員情報にも及びました。
同社は米国の州法に基づき、ニューハンプシャー州司法長官へ法定届出を行っています。2026年4月30日付の届出には、次の内容が明記されています。
・不正アクセスは2025年3月から2026年2月28日まで発生。期間は約12か月
・HRシステムは無傷。漏えいしたのは、従業員本人がMurataアカウントに保存していた個人ファイル
・SSN、パスポート情報、医療情報、金融口座番号などを具体的に列挙
・対応はアクセス制限、強制パスワードリセット、パスワード管理の改善
・全対象者にKroll社の24か月クレジットモニタリングを提供
もちろん、この通知は米国法人の対象者向けであり、日本で公表された約8.8万件と対象範囲が完全に同じではありません。
それでも、同じ不正アクセス事案について開示された情報の粒度には、明確な差があります。
侵入期間：日本は記載なし／米国は明記
通知の単位：日本は全体向けに類型を公表／米国は本人宛レターで個別に通知
救済措置：日本は問い合わせ窓口／米国は24か月の監視サービス
当局届出：日本は非公開／米国は州司法長官サイトで公開
日本で公表された約8.8万件については、「いつから侵害されていたのか」は公開情報からは分かりません。
■なぜ差が出るのか
① 通知内容の法定化
米国では、多くの州が通知文の記載事項を法定しています。発生時期、影響した情報、講じた対策などを書かなければ、通知として成立しません。
日本でも本人通知義務はありますが、侵入期間や影響システムまで一律に記載を求める制度にはなっておらず、具体的な開示の深さには企業判断が残ります。
② 届出の公開性
米国では、州司法長官への届出が公開データベースに掲載され、誰でも一次資料を閲覧できます。本稿の根拠もそこにあります。
一方、日本の個人情報保護委員会への確報は非公開です。
その結果、日本では企業のプレスリリースが、事実上唯一の公開情報となります。
③ 訴訟圧力
米国では、届出とほぼ同時に集団訴訟の調査が始まります。詳細な開示と救済措置を先に示すことが、訴訟リスクの低減にもつながります。
日本には、この圧力は構造的に存在しません。
つまり、この格差は村田が日本の顧客を軽視した結果ではありません。
開示せざるを得ない制度では開示し、裁量が残る制度ではその範囲で開示する。
企業として合理的に行動した結果です。
問うべきは、制度設計です。
■日本は何をすべきか
・本人通知の最低記載事項を法定する。侵入期間、影響システム、漏えい項目。この3点がなければ、対象者は自分のリスクを評価できません。
・確報の要旨を公開する。個人情報保護委員会に集まる確報は、日本のインシデントを体系的に把握できる貴重な一次資料です。現状、この知見は委員会の中に留まっています。
・要配慮情報や金融情報の漏えいには、救済措置を標準化する。
そして企業側にも、制度を待たずにできることがあります。
最も厳しい法域の開示基準に、全世界の通知を合わせることです。
グループは米国では侵入期間を書けました。
書けた情報が、日本の対象者には届いていません。制度上求められていないことも、その背景の一つでしょう。
equalize downではなく、equalize up。
それが、信頼を取り戻す最短の道ではないでしょうか。
#村田製作所 #サイバーセキュリティ #個人情報漏えい #情報開示
piyokango@piyokango
村田製作所IT環境への不正アクセスによる個人情報漏えいに関するお知らせとお詫び 2026年7月10日 村田土地建物株式会社 murata-mlb.co.jp/2026/07/10/%E6… 『既に村田製作所ホームページのコーポレートプレスリリースに掲載されていますが、この度村田製作所IT環境への不正アクセスにより、ムラタメイクのお客様に関する個人情報の一部も外部に漏えいしたことが判明いたしました。 当社のIT環境への不正アクセスに関するお知らせ（第三報） 今回の漏えいによる二次被害・情報の不正利用は現段階では確認されていませんが、お客様には多大なご心配とご迷惑をおかけしておりますこと、心よりお詫び申し上げます。 １．漏えいしたお客様に関する情報 2015年3月末時点･2020年1月末時点･2021年7月末時点の自動車保険のご契約に関する 氏名、証券番号、車両番号、契約保険会社、保険始期日、保険満期日 ※2015年3月末時点･2020年1月末時点･2021年7月末時点の情報が対象で、直近の契約情報は漏洩対象ではありません。 ※住所・電話番号・メールアドレス等の連絡先及び口座情報やクレジットカード情報等は漏えいしておりません。 ２．本件に関する村田製作所の対応 2026年2月28日に村田製作所IT環境への不正アクセスの可能性を認識し初動調査を開始、3月1日より本格的な調査を開始しました。その結果、不正なアクセスが行われ、データが不正に取得されたことが判明しました。不正アクセスの可能性を認識後、直ちに社内に危機対策本部を設置するとともに、外部のサイバーセキュリティ専門機関と連携し、影響範囲の調査および被害拡大防止のための対応を進めて参りました。 現時点までの調査により、社外関係者に関する情報および当社に関する情報が不正に読み出された可能性があることを確認しました。不正アクセスについては即時対応を完了しており、以下の対策を実施いたしました。 ・不正アクセス経路の遮断 ・外部アクセス制限の強化 ・セキュリティ設定の見直し 現時点で村田製作所の認識している限りでは、漏えい情報が悪用された事実は確認されておりません。 ３．再発防止策 村田製作所は、事業活動を継続し、社会から信頼される企業であり続けるためには、情報セキュリティの確保が重要であると認識しています。当社ではサイバー攻撃の高度化・巧妙化や情報漏えいリスクの増大を経営上の重要リスクとして位置づけ、国際的な標準や最新の脅威動向を踏まえた情報セキュリティマネジメントの構築・運用に継続的に取り組んでいます。 今回の事案を厳粛に受け止め、村田製作所は、これまで進めてきた情報セキュリティ管理の考え方および体制について改めて検証し、必要な見直しと強化を行います。 以下に、本事案を踏まえて既に実施している再発防止策についてご説明いたします。 ・今回不正アクセスを受けた特定システムに対する不審通信元からのアクセス遮断、監視強化 ・社内ネットワークへの不正侵入を防止するためのアクセス制限強化 ・主要なクラウド環境への不正侵入を防止するためのアクセス制限の段階的実施 ・不正ログインやなりすましの防止を目的とした認証方式の強化、権限管理強化 ・サイバー攻撃の早期発見と迅速な対応のためのセキュリティ監視の対象範囲と検知ルールの拡充 ・安定したセキュリティ運用の実現のためのセキュリティ管理に関する運用プロセスの強化 また、今後は、技術面・運用面の両面からシステム全体に対する対策の高度化やセキュリティ監視強化と継続的な改善として以下の対策を推進してまいります。 ・不正ログインやなりすまし防止のための認証方式や権限管理の徹底と強化継続 ・更なる高度な攻撃に備えるための検知能力の高度化や監視範囲拡大の継続 ・被害の早期発見のための自社関連情報の外部流通監視の強化 ・継続的なセキュリティ改善サイクル実現のための定期的な外部監査・第三者機関アセスメントの拡充 4．本件に関するお問合せ窓口 本件に関して、お客さまにご対応いただくような保険契約に関する手続きやムラタメイクへご通知いただく必要がある事項等はございません。万が一、当件に関して心当たりのない連絡があった場合には、ムラタメイクまでご相談ください。』 （一部抜粋）#incident
日本語
フード視点からの的確な整理。ここに一つ、セキュリティ実務者として一番気になっている点を足します。
「7月17日から業務を順次開始」——この一文の裏で、いま何が行われているのか。
まず事実です。ニチレイが7月15日の第2報で公表しているのは、主に3点です。
・7月13日、個人情報・顧客データの保護を最優先にグループシステムを遮断
・外部セキュリティ専門会社と安全対策を実施中
・7月17日から業務を順次開始予定
「復旧」ではなく「業務の開始」。
「一斉」ではなく「順次」。
この言葉から読み取れるのは、安全を確認できた範囲から段階的に戻す方針です。
この4日間を、3つの段階に分けて考えてみます。
① どこまで止めたのか
第2報で明確になったのは、業務停止を拡大させた直接の要因が、攻撃によるシステム破壊ではなく、ニチレイ自身が講じた遮断措置だったことです。
攻撃者にすべてを止められたのではなく、被害拡大を防ぐために自ら止めた。
個人情報・顧客データの保護を最優先に、グループで使用するシステムを遮断したとしています。
② 止めている間に何をしたのか
公表・報道を見る限り、7月13日から16日までの遮断期間中に、手作業による代替出荷が行われた形跡は確認できません。
2025年10月のアスクル事案では、FAXと手運用による限定出荷という縮退運転が選ばれました。
一方、ニチレイは取引先約5,000社を支える低温物流網について、手作業で動かすよりも、停止状態を維持する判断をしたように見えます。
ここからは推測です。
この選択は、再開を速めるという観点では合理的だった可能性があります。
手作業による入出庫を始めると、紙の記録、システム上の在庫、倉庫内の実在庫が少しずつ乖離します。
復旧時には、その差分を突合し、再入力しなければなりません。
停止を維持すれば、システムと実在庫の状態を7月13日時点で固定できます。
その間、復旧チームはフォレンジック、侵害範囲の確認、認証基盤の安全確認、バックアップの検証に集中できる。
4日間での業務再開予定は、この割り切りとセットだった可能性があります。
③ 何を根拠に戻すのか
再開の中身は、公表情報だけでは分かりません。
もし物流を支える統合データベースやWMSまで侵害されていたなら、クリーンなバックアップからの復元、または整合性を確保した別環境への切り替えが必要だったはずです。
一方、中核システムが無傷だったのであれば、侵害された領域を隔離し、安全を確認できたシステムから接続を戻す方法も考えられます。
ただし、どちらの場合でも、認証基盤や特権IDが侵害されたままでは、システムを戻した瞬間に再侵害されかねません。
認証情報の変更、攻撃経路の遮断、EDRやログによる監視強化などを先に行い、安全を確認できた範囲から戻すのであれば、「順次」という表現とも整合します。
17日に本当に知りたいのは、単に「業務を再開した」という事実ではありません。
何を根拠に、安全だと判断したのか。
攻撃経路を塞いだのか。
認証情報をリセットしたのか。
バックアップの健全性を確認したのか。
侵害範囲をどこまで特定できたのか。
何をまだ止めたままにし、どこを監視しながら動かすのか。
セキュリティ実務では、「復旧した」という結果以上に、「安全に復旧できると判断した根拠」が重要です。
この事案を見るポイントは3つです。
13日に、どこまで止めたのか。
止めていた4日間に、何を調査し、何を直し、何を確認したのか。
そして17日、何を根拠に、どのシステムから業務へ戻すのか。
重要なのは、早く再開したかどうかだけではありません。
止め方。止めている間の調査。そして、戻す根拠。
この3つが明らかになって初めて、今回の対応を評価できると思います。
#サイバーセキュリティ #サプライチェーン #BCP #インシデント対応 #ニチレイ
news.yahoo.co.jp/expert/article…
日本語
2026年7月のSAP Patch Day。
見出しはCVSS 9.9のNetWeaver脆弱性（CVE-2026-44747）に集中した。
だが実務者が見るべきは、もう一つの方だ。
SAP Commerce CloudのCVE-2026-44761（CVSS 9.1）。
原因は、認証情報の窃取でも、利用者が決めた安易なパスワードでもない。
SAP Help Portalが公式に提供していた、サンプル設定スクリプトだった。
このスクリプトは、誰でも知り得るクレデンシャルを持つOAuthクライアントを作る。
そして旧版のドキュメントには、「本番に持ち込むな」という警告がなかった。
結果、サンプルのまま本番導入した環境では、未認証の攻撃者がトークンを取得し、API経由でデータを読み書きできる。
システムは止まらない。
データだけが、静かに読まれ、静かに書き換えられる。
成立条件は3つの重なりだった。
① 警告のないサンプルスクリプト
② 周知クレデンシャルという設計
③ シークレット未変更のまま本番投入
どれか1つ欠ければ、発火しなかった。
ドキュメント自体が攻撃されるわけではない。
安全でない設定が、公式ドキュメントを通じて多数の顧客環境へ複製される。それが共通の攻撃面になる。
ドキュメントはSBOMにも、脆弱性スキャンにも載らない。
だが、顧客環境を同じパターンで規定する。事実上のサプライチェーン構成要素だ。
これはSAPだけの話ではない。
AWS、Azure、GitHub、Kubernetes、Terraform。
私たちは毎日、「公式ドキュメント」を信頼して構築している。
コードだけでなく、導入手順そのものをレビュー対象にする時代が来ている。
やることは明快だ。
本番環境に、サンプル由来のOAuthクライアント、APIキー、デモユーザー、テスト用証明書が残っていないか棚卸しする。あれば削除する。
#SAPSecurity #脆弱性 #サプライチェーン #サイバーセキュリティ
The Hacker News@TheHackersNews
SAP patched a CVSS 9.9 NetWeaver ABAP flaw that could let an authenticated attacker access or modify data, or knock systems offline. The same update fixes a Commerce Cloud issue tied to publicly documented sample OAuth credentials left unchanged in production. Read : thehackernews.com/2026/07/sap-pa…
日本語
ニチレイの障害。約5,000社の荷主の入出庫を支えるシステムに何が起きたのか、公開情報から構図を整理した。
このシステムには長い道のりがある。東日本大震災を受けて「災害に強いシステム」を目標に基幹刷新を中計に掲げ、2018年S/4HANA再構築、2023年AWS移行、2024年フロント系まで完了。DR切替の自動化まで実装し、悲願は完成した。
完成後の体制がそれを物語る。有価証券報告書の情報セキュリティ開示は、少なくとも2022年提出分から5期連続で一字一句同文。IT実務は2003年から日立51%出資の合弁会社に委託され、監督する情報戦略部長も日立出身。2026年4月には取締役のIT管掌も見直された。全体として、作る段階から運用を中心とする体制へ移っていたように見える。
もう完成した——そう考えていた矢先の出来事だった。
ここからは疑問として書く。新しい技術に寄せて一元化されたシステムは、運用者にとって俯瞰しやすい。それは攻撃者にとっても同じではないか。旧構成は西日本本番・東日本DRが物理的に分かれていたが、クラウド集約後は管理権限がひとつの平面に乗る。もし本番もバックアップも同じ権限管理の配下にあれば、ひとつ破られた時点で全部が落ちる。権限の分離はコストの問題ではなく、設計の問題だ。
災害への強さとセキュリティの強さは、別の設計である。8月の1Q決算で何が語られるかを見たい。
ニチレイ公式リリース：
nichirei.co.jp/news/2026/512.…
日本経済新聞 電子版（日経電子版）@nikkei
ニチレイ不正アクセス、低温物流網が混乱 スーパーなど取引先5000社 nikkei.com/article/DGXZQO…
日本語
Aikidoの心臓部はここです。
CVEが付く前の脆弱性、公開直後のマルウェアを自前で観測して蓄積するIntelデータベース。スキャナーもSafe Chainも、すべてこの上に載っています。
このDBを使ってIntel日次レポートを毎日書いています。どう料理するのが正解かはまだ試行錯誤中ですが、触れば触るほど分かる。ここは間違いなくデータの宝庫です。
その仕組みを解説した記事です。
Aikido Community Japan@AikidoCommJP
🦠 新着記事 Aikido Intelがマルウェアと脆弱性をいち早く検出する仕組み オープンソースのサプライチェーン攻撃は年々巧妙化しており、既存のCVEデータベースやレジストリ管理者の対応だけでは検出が遅れるケースが多い。Aikido Intelはnpm・PyPI・GitHub Actionsなど20以上のエコシステムを対象に、マルウェアと未開示脆弱性の両方をリアルタイムで監視する唯一に近い統合フィードであり、日本のエンジニアやセキュリティ担当者が依存パッケージのリスクを迅速に把握するうえで重要な情報源となる。 aikido-community.jp/blog/aikido-in… #マルウェア #マルウェア #Aikido #セキュリティ
日本語
詳細なインシデント報告。ここまで技術的な原因を書く日本企業は珍しい。
開発者の自宅端末が、標的型攻撃ではなく通常の探索スキャンでやられた事例。
OSそのものへ侵入されたのではない。端末上のDockerで動いていたMySQLとRedisへ、インターネットから直接接続された。
原因は、二つの設定が重なったこと。
DockerのDBポートが、ローカル限定の127.0.0.1ではなく、外部からも接続できる0.0.0.0で待ち受けていた。
さらに、自宅ルーターの設定とファームウェアの不具合により、そのポートがインターネットへ転送されていた。
探索ボットがこれを発見し、データ窃取、削除、ランサムメッセージの残置まで実行。Redisには暗号資産マイニングを目的とした不正な設定も書き込まれた。
リモートワーク時代、会社が開発者の自宅ルーターまで完全に統制するのは難しい。
だからこそ、端末側とルーター側の両方で閉じる必要がある。
■ 自宅ルーターを確認しよう
① ブラウザで192.168.1.1を開く
機種によっては192.168.0.1など。分からなければルーター本体のラベルや説明書を確認する。
② UPnPを確認する
開発端末を置く環境では、必要性がなければ無効にする。UPnPはアプリや機器がルーターへポート開放を要求できる機能。
③ ポート転送を確認する
「ポート転送」「ポートマッピング」「ポート開放」「静的NAT」などの一覧を見る。身に覚えのない設定や、昔のゲーム機・監視カメラ用の設定が残っていれば削除する。DMZ設定も確認する。
④ ファームウェアを更新する
自動更新が利用できるなら有効にする。サポートが終了した古いルーターは交換も検討する。
⑤ 外部から実測する
スマートフォンのWi-Fiを切り、モバイル回線など自宅外のネットワークから、ポートチェックサイトやncコマンドを使って、3306や6379など不要なポートが公開されていないか確認する。
■ Dockerのポートは必要な範囲だけに公開する
docker-composeの
ports:
- “3306:3306”
は、通常すべてのネットワークインターフェースで待ち受ける。
ローカル端末からしか使わないなら、
ports:
- “127.0.0.1:3306:3306”
と明示する。
コンテナ間の通信だけでよいなら、ports自体が不要な場合もある。
■ クラウドでも同じ
EC2などではセキュリティグループが外部からの入口を制限する。
ただし、セキュリティグループの設定ミスに備え、Docker側も必要以上に0.0.0.0へ公開しない。LinuxではDockerが独自にiptablesルールを追加するため、ufwで閉じたつもりでも公開ポートへ到達できる構成がある。
「自分のPCで動かしている」と「インターネットから閉じている」は別の話。
ローカルだと思い込まず、実際に外から確認する。
wasabi-inc.biz/help/news/2026…
#サイバーセキュリティ #Docker #リモートワーク
piyokango@piyokango
【重要】開発環境への不正アクセスによるセキュリティインシデントに関するご報告とお詫び 2026年7月6日 株式会社ワサビ wasabi-inc.biz/help/news/2026… 『この度、弊社の開発環境端末におきまして、外部からの不正アクセスによるセキュリティインシデントが発生いたしました。 お客様には多大なるご心配とご迷惑をおかけしておりますこと、深くお詫び申し上げます。 なお、詳細な調査の結果、実在するお客様の個人情報および機密情報の漏えいは一切ないことが確認されております。 なお、本件に関する最新の状況、および今後の各モール再認証スケジュール等につきましては、新たな進捗があり次第、本ページを随時更新してご報告申し上げてまいります。 上の「最終更新日時」をご確認のうえ、最新の情報をご参照いただけますようお願い申し上げます。 本件に関する経緯、原因、影響範囲、および今後の再発防止策につきまして、下記の通りご報告申し上げます。 記 インシデントの概要 2026年7月4日（土）、弊社の開発環境端末上のデータベース（MySQL）およびキャッシュサーバ（Redis）に対して外部からの不正アクセスが発生いたしました。 データベース内の情報が外部へ送信され、その後データが削除される被害を確認しております。 影響範囲と被害状況について ① お客様の個人情報・機密情報について 流出したデータベース内の注文および顧客データは、すべてテスト用に作成された架空データ（ダミーデータ）であり、実在するお客様の個人情報は一切含まれておりません。 ② 窃取された情報について 一部のAPIキー、アプリケーションID、テストデータ、および「ワサビ管理者アカウント」の情報が窃取されました。 管理者アカウントのパスワードは強固な暗号化（ソルト付きSHA-256でハッシュ化）が施されており、平文ではございませんが、二次被害防止のため、速やかに全てのアカウントを停止し、パスワードの変更を実施いたしました。 ③ 本番環境への影響について 窃取された情報の中に、一部本番環境でも使用されているAPIキーとアプリケーションIDが含まれておりました。 APIキー： 速やかに再発行および旧キーの無効化を完了しており、不正利用は確認されておりません。 アプリケーションID： OAuth認証が必要な仕様のため、機密情報が直接漏えいすることはございませんが、念のため現在再発行の手続きを進めております。 対象となるAPI：Luxclusif、ヤフーショッピング、併売ヤフオク、競りナビ、UPS、Shopify、Walmart 不明なサイト等で上記のOAuth認証（連携許可）を行わない限り、これによって注文情報や商品情報、その他個人情報が流出することはありません。 ④ キャッシュサーバ（Redis）について 暗号資産マイニングを目的とした不正な設定の書き込みを確認しましたが、コンテナ内に隔離された環境であり、実行プログラムが存在しなかったため、システムへの被害は発生しておりません。 お客様へのお願い 前述の通り、現在アプリケーションIDの再発行手続きを行っております。 再発行が完了した折には、誠にお手数ではございますが、各モールの設定画面にて再認証を行っていただく必要がございます。 具体的な手順や実施時期につきましては、確定次第、改めてご案内申し上げます。 発生原因 以下の要因が重なり、開発用データベースがインターネットから直接接続可能な状態になっていたことが原因です。 ・開発環境のDockerコンテナのデータベースポートが、ローカル環境のみ（127.0.0.1）ではなく、外部からも接続可能（0.0.0.0）な設定になっていたこと。 ・当該端末を接続していた自宅ルーターの設定およびファームウェアの不具合により、該当ポートが外部へ転送（パブリックに公開）される状態になっていたこと。 これにより、探索ボットが公開ポートを発見し、侵入に至りました。 発生から対応までの経緯 2026年7月4日（土） ・08:56：開発環境端末へ不正アクセスが発生。 ・10:48：データ窃取および削除、ランサムメッセージの残置を確認。 ・11:52：攻撃元の特定、被害状況の確認を開始。 ・14:52：二次被害防止のため、全WASABISWITCHのワサビ管理者アカウントを全停止し、セッションを強制削除。 ・17:13：根本原因を確定。 ・18:28：該当社員から社内へインシデント発生を報告。 ・19:47：情報の流出状況を改めて詳細に確認。 ・20:35：緊急性の高いクレデンシャル情報（APIキー等）を再発行し、全WASABI SWITCHへ反映の上、流出した情報を無効化。 ・22:42：恒久対策としてソースコードを修正 2026年7月5日（日） ・10:00：クレデンシャル情報（アプリケーションID）の再発行手続きを開始。 2026年7月6日（月） ・11:00：全WASABISWITCHのワサビ管理者アカウントのパスワードを変更した上で、アカウントの稼働を再開。 再発防止策 弊社では本事態を重く受け止め、以下の対策を講じ、セキュリティ体制の強化を徹底いたします。 ・アクセス制御の徹底： Dockerの公開ポートを「127.0.0.1（ローカル）」に限定し、外部からの直接接続を遮断（MySQL・Redis等すべての公開ポートに適用）。 ・認証情報の強化： MySQL、Redis等すべてのシステムにおけるパスワードおよび認証情報の定期的なローテーション（変更）を実施。 ・開発データの無害化（サニタイズ）： 開発環境で使用するデータに含まれるパスワードハッシュや認証情報をダミー値へ置き換え、本番データへの紐付きを完全に排除。 ・アカウントの保護： 影響を受けた全スタッフのパスワード再設定。 ・ネットワーク設定の是正： 対象ルーターのUPnP機能の無効化およびポート転送設定の削除。 ・社内セキュリティ診断の実施： 開発担当者全員の端末・環境に対するペネトレーションテスト（侵入テスト）を実施し、脆弱性がないことを確認。 ・第三者機関による監査： 外部のセキュリティ専門企業へコンサルティングを依頼し、総合的なセキュリティ監査および体制の見直しを実施。 本件に関しまして、ご不明な点やご不安な点がございましたら、弊社担当者またはサポート窓口までお問い合わせくださいますようお願い申し上げます。 改めまして、この度は多大なるご迷惑とご心配をおかけいたしましたこと、重ねて深くお詫び申し上げます。』 （一部抜粋）#incident
日本語
🦠 新着記事
Aikido Intelがマルウェアと脆弱性をいち早く検出する仕組み
オープンソースのサプライチェーン攻撃は年々巧妙化しており、既存のCVEデータベースやレジストリ管理者の対応だけでは検出が遅れるケースが多い。Aikido Intelはnpm・PyPI・GitHub Actionsなど20以上のエコシステムを対象に、マルウェアと未開示脆弱性の両方をリアルタイムで監視する唯一に近い統合フィードであり、日本のエンジニアやセキュリティ担当者が依存パッケージのリスクを迅速に把握するうえで重要な情報源となる。
aikido-community.jp/blog/aikido-in…
#マルウェア #マルウェア #Aikido #セキュリティ
日本語
✅ 新着記事
GitHub Actionsの脆弱性を悪用：AsyncAPI npmパッケージ5件にバックドアが埋め込まれた事案の詳細分析
週間ダウンロード数が合計約290万件（うち@asyncapi/specsだけで約270万件）に上るAsyncAPI関連のnpmパッケージ5件が、2025年7月14日にトロイの木馬化されたことが判明した。攻撃者はGitHub Actionsのpull_request_targetワークフローの既知の脆弱性を悪用してnpm公開トークンを窃取し、通常の実行モジュール内に難読化されたダウンローダーを埋め込んだ。影響を受けるパッケージをrequire()するだけでインプラントが起動するため、パッケージをインストールしたホストだけでなく、実際にimportしたすべてのホストが対象となる。
aikido-community.jp/blog/asyncapi-…
#ベストプラクティス #npm #Aikido #セキュリティ
日本語
「上げれば壊れる。だから古いまま使い続けるしかない」。この制約を正面から崩そうとしている動きがある。
Aikidoは先月、イスラエルのRoot（root.io）という会社を買収した。会社を一つ丸ごと買ってまで手に入れようとしたのは、「検知」の先にある「修復」の能力だ。脆弱性を見つけて終わりにせず、壊さずに直すところまでを、一つの流れにする。
その技術が Aikido Libraries として形になっている。発想はこうだ。いま動いているバージョンを据え置いたまま、脆弱性にだけパッチを適用して使い続けられるようにする。Aikido公式によれば、新しいCVEが公開されると、その環境で利用しているバージョン向けのパッチを生成し、アップグレードや破壊的変更を伴わず利用できるライブラリとして提供するという（出所：Aikido公式ブログ「Aikido acquires Root」、CEO Willem Delbareの説明）。
まだ全ユーザーに開放された段階ではない。限定的に提供が始まったところだ。だが、重要なのはそこではない。問うべきは、「依存のせいで古いものを手放せない」という現実の問題に対する回答が、存在するのかしないのか——その一点だ。
そして、ある。もう動いている。
前の投稿で書いた宿命に対する、一つの答えだと思う。上げられないなら、上げずに直し続ける。強制アップグレードでもロック型の代替でもない、第三の道。検知から修復まで、そしてライブラリにパッチを当てて延命させる。それを実現しようとして、会社ごと買った。
この方向に賭ける企業が、混迷に悩む日本企業を救える一つの解なのかもしれない。
#サプライチェーンセキュリティ #Aikido #DevSecOps #サイバーレジリエンス
日本語
もう一つ、考えさせられたことがある。新しく作った環境なのに、古いものに引きずられる、という現象だ。
外から見えた範囲でも、片方は新しいクラウド基盤の上で動き、もう片方はサポート切れ世代の土台で動いている、という混在が見えた。だが、これを「新しくできなかった」と読むのは、たぶん間違っている。
新しく作る力は、ある。現にクラウド基盤を構築できているのだから。それでも古い層が残るのは、能力ではなく依存関係の問題ではないか——ここから先は推測だが、外れていない気がする。
わかりやすい例がFAXだ。多くの現場が、いまだにFAX発注を手放せない。自社が遅れているからではない。取引先や末端の倉庫が、FAXでしか対応できないからだ。相手がそこにいる限り、自社だけ新しくしても、合わせる層を残すしかない。
システムの依存も、これと同じ構造をしている。連携先が古い方式しか受け付けない。特定バージョンでしか動作保証されない業務パッケージがある。止められない外部連携がある。依存の鎖が一本でもあれば、土台を上げた瞬間にどこかが壊れる。だから、上げられない。使い続けるしかない。
新しいものを作れないのではない。古いものを、依存のせいで手放せないのだ。これは怠慢ではなく、複雑な組織が背負う構造的な宿命に近い。
問題は、その古い層が相対的に攻撃対象になりやすいこと。そして「上げれば壊れる」という制約が、それを塩漬けにし続けること。ここをどう解くかが、次の主題になる。
#技術的負債 #レガシー #EOL #依存関係
日本語
ニチレイの件、公開情報を追っていて考えさせられた。確認できたことだけ書く。
7月13日、ニチレイは「不正アクセスによるシステム障害」を公表した。影響を受けたのは、ニチレイロジ各社の冷蔵倉庫入出庫業務と、ニチレイフーズの冷凍食品出荷業務。別事業会社の二つの業務系統が同時に止まっている。
影響は国内に限定され、個人情報の流出は現時点で未確認。侵入経路や攻撃手法は公表されていない。
気になったのはDRの設計だ。
ニチレイロジの物流基幹システム「Lixxi」は、西日本をメインサイト、東日本をDRサイトとして両拠点を同時稼働させ、データを常時同期する構成を導入している。西日本側が停止した場合、DR発動からオンライン再開まで約1時間。免震データセンター、異なる通信キャリアの冗長化、クラウド上のDRサイトなど、大規模災害や設備障害への備えとしては非常に強い構成だ。
一方、今回は不正アクセスによる障害だった。
もちろん、Lixxi自体が侵害されたのか、DRへの切り替えを試みたのか、安全確認のために関連システムを停止したのかは公表されていない。
ただ、災害とサイバー攻撃では復旧の前提が違う。
設備障害なら、壊れた設備を正常な設備へ切り替えればよい。
しかしサイバー攻撃では、データ、認証、管理権限、運用端末、ネットワークなど、環境そのものの信頼性が失われる可能性がある。DRサイトが存在していても、それだけで安全に切り替えられるとは限らない。
さらに、外部から公開面を確認すると、業務システムには世代差が見える。物流系の一部はAWSのロードバランサーを利用し、比較的新しいTLS構成で公開されている。一方、社内ポータルにはCentOS 7世代を示すApache、OpenSSL、PHPの構成や、TLS 1.3に対応していないシステムも確認できた。
これが今回の侵入口だったという意味ではない。原因との関係は全く分からない。
むしろ、大規模組織では長年使われてきたシステムと、新しく構築したシステムが共存することは珍しくない。
問題は、新旧が混在することではない。
古いシステムは、更新の難しさや依存関係、保守期限、認証方式などの制約から、相対的に攻撃対象になりやすい面を持つ。
だからこそ重要なのは、そこから侵入されたとしても、他の事業会社や新しい基盤まで到達できない設計にしておくことだ。
ネットワーク、認証、管理権限、運用端末、バックアップ——どこまでを共有し、どこで境界を引くのか。
今回止まったのは、ニチレイロジの冷蔵倉庫入出庫と、ニチレイフーズの冷凍食品出荷という二つの業務系統だった。
どこが共通依存点だったのかは現時点では分からない。認証基盤だったのか、ネットワークだったのか、EDIや統合マスタだったのか、それとも安全確認のために広範囲を停止したのか。
ただ一つ言えるのは、サイバー攻撃では「侵入されないこと」だけを前提にした設計では足りないということだ。
災害では、壊れた設備を切り替える。
サイバー攻撃では、信頼できなくなった環境を切り離し、クリーンな環境へ業務を戻す。
同じ「復旧」でも、設計思想はまったく違う。
これから問われるのは、防御だけではない。
侵入されても事業を止めないために、どこまでを切り離して復旧できるよう設計しておくのか。
サイバーリカバリーを前提としたシステム設計へ、発想そのものを変える時代なのだと思う。
（本稿は公開情報および公開されたシステム情報への通常アクセスによる調査に基づくものです。侵入経路や攻撃手法、影響範囲の詳細は現時点で公表されておらず、原因を特定するものではありません。）
#サイバーセキュリティ #サイバーレジリエンス #BCP #ランサムウェア #物流DX
日本経済新聞 電子版（日経電子版）@nikkei
ニチレイ、不正アクセスでシステム障害 冷凍食品の出荷業務に影響 nikkei.com/article/DGXZQO…
日本語
✅ 新着記事
依存関係ファイアウォールとは何か？
オープンソースのサプライチェーン攻撃は急増しており、Aikido Intelは現在1日最大10万件の悪意あるパッケージを検知している（1年前は約2万件）。攻撃はインストールコマンド実行の瞬間に発動し、事後スキャンでは手遅れになる。AIコーディングエージェントやMCPサーバーが人間を介さずにパッケージをインストールするようになった今、インストール時点での防御が不可欠になっている。
aikido-community.jp/blog/what-is-a…
#ベストプラクティス #Aikido #セキュリティ
日本語
✅ 新着記事
AIコーディング時代におけるコード品質基準の維持方法
AIによるコード生成（バイブコーディング含む）の普及により、開発速度は飛躍的に向上した一方で、レビューを省略したまま技術的負債が積み重なり、数ヶ月後に開発速度が急激に低下するリスクが顕在化している。人手によるレビューはAIの生成速度に追いつけず、汎用LLMへの丸投げレビューも精度に限界がある。チームが早期かつ効率的にコード品質を管理する仕組みを持つことが、今や不可欠な課題となっている。
aikido-community.jp/blog/code-qual…
#ベストプラクティス #Aikido #セキュリティ
日本語
同日、冷凍・冷蔵食品の輸入商社トップ・トレーディングも、「提携倉庫の大規模なシステム障害」により、すべての出荷作業と配送手配が停止したと公表している。
同社の会社案内には、ニチレイ・ロジスティクス北海道の物流センター内に拠点を置く記載があり、ニチレイロジグループとの実務上の接点も確認できる。
提携倉庫名や利用システムは公表されていないため、同一事案と断定はできない。だが、公表日と影響内容はニチレイの障害と一致しており、波及先である可能性は高い。
もし同一事案なら、今回止まったのはニチレイ社内の二つの業務系統だけではない。倉庫を利用する外部荷主の出荷作業と配送手配まで止まったことになる。
これは「ニチレイ社内のシステム障害」ではなく、荷主企業の事業継続まで左右する物流インフラ障害として見る必要がある。
Autumn Good@autumn_good_35
『提携倉庫におきまして、大規模なシステム障害が発生しております。 この影響により、現在すべてのお荷物の出荷作業および配送手配が一時的に停止』😲 2026-07-13 トツプ・トレーディング株式会社 【お詫び】提携倉庫のシステム障害による商品発送遅延について toptrading.co.jp/pages/93/detai…
日本語
技術的に見ると、ここが興味深い。
陣痛タクシーの登録フォームも、GOも、遮断された日本交通の社内ネットワークの外にある。前者は外部ホスティング、後者はGO側クラウド。どちらもインフラ上は本丸の外だ。
それなのに、陣痛タクシーは止まり、GOは動いている。
この差は、日本交通の社内にある予約・登録・配車基幹への依存度で説明できる。
GOは、GO側クラウドと車載端末を中心に配車が成立し、日本交通の社内基幹へのリアルタイム依存が小さい。いわば疎結合だ。だから日本交通側を遮断しても、GO経由の配車は回る。
一方、陣痛タクシーは、登録した電話番号、迎車先住所、出産予定日、搬送先病院などを受付時に参照して配車する。
フォーム自体が外部で動いていても、その先の登録DB、受付画面、電話配車、車両手配のどこかが社内側に依存していれば、サービスは成立しない。
この二つを並べると、現在使えなくなっている中心が、日本交通側の予約・登録・配車基盤に近いことが見えてくる。
ただし、線引きは必要だ。
外から言えるのは、社内側の基盤が現在利用できない状態にあることまで。それ自体が侵害されたのか、安全確保のため予防的に遮断されたのかは、まだ分からない。
分かっているのは、疎結合だったGOは生き残り、社内基幹への依存が強いサービスから止まったということ。
障害の形が、システム境界と本丸の位置を照らし出している。
日本語
日本交通の不正アクセス。
「配車アプリGOは通常どおり」と聞けば、利用者への影響は限定的に見える。
だが、本当に確認すべきはGOではない。
今、陣痛が来た妊婦さんは、陣痛タクシーを呼べるのか。
侵入は7月11日未明。日本交通は社内ネットワークを遮断し、電話によるタクシー配車、ハイヤーのWeb受注・予約管理、一部社内システムが停止。一方、GO経由の配車は動いている。
この差は、システムの結合関係で説明できる。
GOは日本交通の社内基幹へのリアルタイム依存が薄く、GO側のクラウドから車両へ配車できる。日本交通側を遮断しても、GOは回る。
一方、陣痛タクシーは違う。
登録した電話番号から専用回線へ電話し、オペレーターが事前登録された自宅住所、出産予定日、搬送先病院を参照して車両を配車する。
日本交通の内部システムにリアルタイムで依存するサービスだ。
現在、陣痛タクシーの新規登録フォームは停止している。
しかし、会社の案内には、新規登録だけができないのか、すでに登録済みの妊婦さんは専用回線から通常どおり配車を受けられるのかが書かれていない。
本体の発表では、「お電話によるタクシー配車サービス」は利用できないとされている。
では、陣痛タクシーの専用回線は動いているのか。
登録情報を参照できるのか。
迎車先と病院を確認し、実際に車両を配車できるのか。
これは単なるWebフォーム停止の話ではない。
陣痛時に頼る前提で登録していた妊婦さんにとっては、まさに今夜の可用性の問題だ。
「GOは通常どおり」だけでは足りない。
日本交通には、陣痛タクシーについて、
・登録済み利用者は現在も利用できるのか
・専用回線は正常に接続できるのか
・利用できない場合の代替手段は何か
を明確に案内してほしい。
情報漏えいの有無も重要だ。
だが、まず確認すべきは、今まさに陣痛が来た妊婦さんが、病院へ行くための車を呼べるのか。
そこだ。
#日本交通 #陣痛タクシー #サイバーセキュリティ #不正アクセス #事業継続
ITmedia NEWS@itmedia_news
日本交通に不正アクセス、電話でタクシー配車不能に 「GO」経由は無事 itmedia.co.jp/news/articles/…
日本語