  |
はてなキーワード:不正アクセスとは
【衝撃速報】熊本県警の“鉄壁の城”が崩壊！ 国外ハッカーの魔の手、日本の治安を嘲笑！
熊本県警のメールサーバーが、2025年10月6日、国外からの不正アクセスを受けた。
その結果、約12万通ものメールが“県警の名をかたって”世界中へ放たれた！
目を疑うのは、その到達件数 およそ1万9千件。
もしその中にウイルスが潜んでいたら？ もし、県警内部の情報が混入していたら？
「被害は確認されていない」との発表は、まるで嵐の中で“雨は降っていない”と言い張るようなものだ
「警察の情報インフラが破られたということは、行政の“デジタル主権”そのものが揺らいでいる」 情報セキュリティ研究者の声。
熊本が破られたということは、次に狙われるのは
まるでドミノ倒しのように、次の攻撃対象が静かに並べられているのではないか。
だが、専門家の分析によれば、内部情報を熟知した者でなければ突破は不可能だという。
果たして真の敵は外にいるのか？
私は叫ぶ。
世界中のゲーム開発者に広く利用されているゲームエンジン「Unity」。その柔軟性や開発のしやすさから、多くのインディーゲームから大規模タイトルまで採用されてきました。しかし、そんなUnityに深刻なセキュリティ脆弱性が発見され、業界に大きな波紋を広げています。
Unityはマルチプラットフォーム対応に優れており、PC、家庭用ゲーム機、モバイルと幅広い展開が可能です。しかし、今回報告された脆弱性は、ゲームデータやユーザー情報に不正アクセスされる危険性を孕んでおり、多くのスタジオが対応を迫られました。
ObsidianEntertainmentの決断
『TheOuter Worlds』『Fallout: New Vegas』『Grounded』などで知られる大手スタジオ ObsidianEntertainment は、今回のUnityの脆弱性を受け、複数のデジタルストアから自社のゲームを削除すると発表しました。
公式声明はTwitter/Xアカウントを通じて発表され、「Unityエンジンに起因するセキュリティ問題が確認されたため、ユーザーの安全を最優先し、修正対応が行われるまで販売を一時停止する」としています。
今回の出来事は、Unityに依存している多くのゲーム開発者やスタジオにとって大きな衝撃です。セキュリティ上のリスクは、ゲームの販売停止や信頼低下に直結するため、今後のUnityエンジンの改善対応が注目されています。
まとめ
Unityエンジンのセキュリティ脆弱性は、ただの技術的問題にとどまらず、ゲーム開発者とプレイヤー双方に深刻な影響を与えています。ObsidianEntertainmentが示したように「ユーザーの安全を最優先する姿勢」は評価されますが、業界全体にとっても早急な解決が求められる課題です。
https://laylo.com/gfdjtz1/ccV1kUZe
https://laylo.com/laylo-nosg8jo/5mtwCH9a
https://laylo.com/laylo-fult2sb/XvWAETIz
https://laylo.com/laylo-3osrile/163nGQJ1
https://laylo.com/laylo-lv9r23k/Hy6VLYQT
VISAは駿河屋を含む色んなサイトで何年も使用してるが一度も不正使用(の通知)は無かった。
駿河屋でVISAが使えなくなったので、仕方なく去年に作ったJCBのカードを駿河屋のマケプレでの
支払いに使用したら、初めての不正利用。海外からの購入で、引き落とされた金額が足りなかった
おかげで、結果的に不正使用はされず。海外からの使用出来ないように設定(アマゾンプライムなど
国内で運営する外国企業への支払いが利用できなくなる)した十数分後に、又、海外からの不正使用が
あったが、「海外からの利用禁止」に再設定した後だったので、引き落とされずに助かった。
一応、IDとパスワードも再設定したけど、これで大丈夫なんだろうか。今年に入ってからJCBを使ったのは
駿河屋のマケプレでの購入のみ。それ以外の支払いはすべてVISAを使用。VISAには何も問題は無し。
※追記。8月8日に駿河屋から重大発表があったらしい。全く知らなかった。登録してるのに通知されてない。
第三者不正アクセスによる個人情報漏えいとクレジットカード決済停止に関するお詫びとお知らせ _中古・新品通販の駿河屋
不正アクセスによる情報漏えいの可能性のある期間は、2025年7月24日（木）午前1時頃から2025年8月4日（月）午後4時頃までに、当サイトでクレジット番号を入力されたお客様の情報です。
www.suruga-ya.jp/feature/osirase/2025_08_09.html
駿河屋で上記期間にクレジットカード情報を入力して買い物をした人の情報が抜かれているらしい
人によってはセキュリティコードも抜かれてるとか
⸻
脆弱性が明らかに：イスラエルの企業、ChatGPTアカウントをリモートでハッキングする方法を公開
イスラエルのサイバーセキュリティ企業Zenityは、OpenAIのChatGPTサービスにおける「ゼロクリック」脆弱性を公開しました。この脆弱性により、ユーザーがリンクをクリックしたり、ファイルを開いたり、意図的なアクションを取ったりすることなく、ChatGPTアカウントを制御し、機密情報を抽出することが可能であると説明しています。
このデモンストレーションは、Zenityの共同創設者でCTOのミハイル・バーゴリ氏によって、今週アメリカで開催されたBlack Hat 2025カンファレンスで行われました。
バーゴリ氏は、ハッカーがユーザーのメールアドレスだけを利用して、ChatGPTのアカウントを完全に制御し、過去と未来の会話にアクセスしたり、会話の目的を変更したり、ハッカーの代わりにチャットを操作させる方法を示しました。
講演中には、攻撃を受けたChatGPTがユーザーに対して悪意あるエージェントとして密かに動作する様子が示されました。研究者たちは、ハッカーがチャットにウイルスをダウンロードさせるように促したり、誤ったビジネスアドバイスを薦めたり、Googleドライブに保存されているファイルにアクセスするように指示したりする方法を説明しました。これらはすべて、ユーザーが何かがおかしいと気づかないままで行うことができました。
この脆弱性は、ZenityがOpenAIに報告した後に完全に修正されました。
ChatGPTへの攻撃だけではなかった
カンファレンス中、Zenityの研究者たちは、他の人気AIエージェントサービスにも侵入した方法を紹介しました。マイクロソフトのCopilotStudioでは、CRMデータベース全体を漏洩させる方法が公開されました。
SalesforceEinsteinの場合、ハッカーは偽のサービスリクエストを作成し、すべての顧客との通信を自分の管理するメールアドレスに転送する方法を示しました。
Google GeminiやMicrosoft 365 Copilotシステムは、ユーザーに対してソーシャルエンジニアリングを行い、機密の会話をメールやカレンダーイベントで漏洩させるように悪用されました。
開発ツールCursorは、JiraMCPと統合された際に、悪意のあるチケットを使用して開発者のログイン資格情報を盗み出す攻撃に利用されました。
Zenityは、OpenAIやMicrosoftのような企業がレポート後に迅速にパッチをリリースしたと指摘しましたが、一部の企業は脆弱性に対処せず、それがシステムの意図された動作であり、セキュリティの欠陥ではないと主張しました。
ミハイル・バーゴリ氏によれば、現在の課題は、エージェントが単なるタスクを実行する補助ツールではなく、ユーザーに代わってフォルダを開いたり、ファイルを送信したり、メールにアクセスしたりするデジタル存在となっている点にあります。彼は、これはハッカーにとって「天国」のような状況だと指摘し、無数の潜在的な侵入ポイントが存在すると述べました。
Zenityの共同創設者兼CEOであるベン・カリガー氏は、Zenityの研究が現在のセキュリティアプローチがエージェントの実際の運用方法には適していないことを明確に示しており、組織はそのアプローチを変え、これらのエージェントの活動を制御および監視するための専用のソリューションを求めるべきだと強調しました。
Zenityは2021年にベン・カリガー氏とミハイル・バーゴリ氏によって設立され、現在は世界中で約110人を雇用しており、そのうち70人はテルアビブのオフィスで働いています。顧客にはFortune 100企業やFortune 5企業も含まれています。
⸻
この記事で言及されている**「ゼロクリック脆弱性」**に対する具体的な対策については、以下のポイントが挙げられます：
• OpenAIやMicrosoftのような企業は、脆弱性が報告されるとすぐにパッチをリリースしました。これにより、セキュリティ問題は修正されました。ですので、システムやアプリケーションの定期的な更新とパッチの適用が最も基本的で重要な対策です。
• Zenityの研究者は、AIエージェントがユーザーの代わりにフォルダを開いたり、ファイルを送信したりするような動きをする現在のセキュリティアプローチには限界があると指摘しています。そのため、AIエージェントの活動を常に監視し、異常な動きを検出するシステムを導入することが必要です。
3. 多要素認証 (MFA) の導入
•メールアドレスだけでアカウントを操作できる脆弱性が示されているため、**多要素認証 (MFA)**を導入することで、ハッカーが一度侵入してもアクセスを制限することができます。これにより、アカウントの不正アクセスを防ぎやすくなります。
•AIツールやエージェントに与えるアクセス権限は、必要最低限に抑えるべきです。もしエージェントが機密情報にアクセスできる権限を持っている場合、それが攻撃者に悪用されるリスクを高めます。最小権限の原則に基づき、AIがアクセスするデータや機能を制限することが重要です。
•ユーザーに対して、怪しいリンクやファイルを開かないこと、セキュリティに関する意識を高めることが有効です。ゼロクリック攻撃のように、ユーザーが何もしなくても攻撃されることがあるため、定期的なセキュリティトレーニングと啓蒙活動が求められます。
•AIツールやエージェントがどのように動作しているかを監査し、予期しない動作や異常を検出するシステムを導入することが重要です。特に、ファイルやメールを無断で送信したり、ユーザーの意図しない行動を取る場合、その挙動を警告する仕組みを持つことが推奨されます。
• Zenityのようなセキュリティ企業と連携し、最新の脅威に対する検出能力を強化することも有効です。脆弱性を早期に発見し、対応するための専門家のサポートを受けることで、セキュリティレベルを向上させることができます。
• 機密データを暗号化して保護し、万が一攻撃を受けてもバックアップから復旧できる体制を整えることが重要です。これにより、重要な情報が漏洩した場合でも、被害を最小限に抑えることができます。
⸻
総括
ゼロクリック脆弱性は、ユーザーの行動に依存せずに攻撃が可能なため、より強固なセキュリティ対策が求められます。パッチ適用だけでなく、エージェントの監視、アクセス制限、教育など、複合的なアプローチが必要です。これからはAIツールやエージェントが進化し、さらに複雑なセキュリティの問題が発生する可能性があるため、進化したセキュリティ戦略を持つことが不可欠となるでしょう。
証券会社なんて基本は嫌いだけど、バッシングは狂ってる。金融庁も狂ってる。
客が、パスワードをちゃんと管理し、証券会社のドメインをちゃんと確認して入力していれば起こらなかったわけで。
例えば特殊詐欺のうちオレオレ詐欺で、カネ盗られたとして、そのカネがもともと入っていたみずほ銀行にバッシングが行くか？みずほ銀行は補償をすべきか？
例えば家の鍵を閉めず泥棒に金塊を盗まれたとして、金塊の製造会社とか、家の建築会社は補償をすべきか？
フィッシングについては、例えば三井住友銀行に口座を持ってるやつが、預金のつもりで「三ゥ゙井ずミトめ銀行」って書かれた銀行風の建物に行って、カネをみすみす犯罪者に渡すようなもん。
（フィッシングはドメインを見分けて基本的には対処できることからのたとえ）
職場の同僚がその「三ゥ゙井ずミトめ銀行」エピソードを話してきたとき、心の底からかわいそうにと思えるか、同情できるか？俺なら成年後見制度を真剣に勧めるよ
証券会社なんて基本は嫌いだけど、バッシングは狂ってる。金融庁も狂ってる。
客が、パスワードをちゃんと管理し、証券会社のドメインをちゃんと確認して入力していれば起こらなかったわけで。
例えば特殊詐欺のうちオレオレ詐欺で、カネ盗られたとして、そのカネがもともと入っていたみずほ銀行にバッシングが行くか？みずほ銀行は補償をすべきか？
例えば家の鍵を閉めず泥棒に金塊を盗まれたとして、金塊の製造会社とか、家の建築会社は補償をすべきか？
フィッシングについては、例えば三井住友銀行に口座を持ってるやつが、預金のつもりで「三ゥ゙井ずミトめ銀行」って書かれた銀行風の建物に行って、カネをみすみす犯罪者に渡すようなもん。
職場の同僚がその「三ゥ゙井ずミトめ銀行」エピソードを話してきたとき、心の底からかわいそうにと思えるか、同情できるか？俺なら成年後見制度を真剣に勧めるよ
まぁ実際Googleのアカウント管理は厄介ですよ。個人的にはとっととマイナンバーカードで認証できるようにして欲しい
…と、言っていてもしょうがないし、
Googleからしたら、アカウント乗っ取りから利用者を守る必要があるわけで
未登録の情報でリカバリできるとしたら、それは他人がアカウント乗っ取れることとほぼ同義ですから
銀行口座のように事前の本人確認をちゃんとしてるわけでもないし
自分で自分の情報を登録して自分で最新化していくしかないんですよ。自衛のために
本当にリカバリしたい利用者だって星の数ほどいるわけで、個々のリクエストに人間が対応するわけにもいかない
とはいえ、たかがアカウント管理にそんなにコストもかけてられないし
Googleが完璧な案内をしてくれれば…と理想論をいったところで、期待できません
大本の増田にも書いてありますが、紙に印刷して安全な場所に保存しておくのが結局一番コスパがよさそうだというのが現状の私の考え方です
パスキー等は印刷できませんから、パスワードとバックアップコードが対象です(2FAを有効化していなければパスワードだけ)
これでリカバリ(というか普通にログイン)できるので、パスキーはいくら失っても構いません。再発行すればよいだけです
パスキーが使いにくいと感じる人が多くいるのは否定しませんが、フィッシング対策としてはかなりの効果が期待できます。使い勝手との兼ね合いでご自由に
なお、リカバリ用の連絡先は、電話もメアドも気付かないうちに使えなくなる可能性があるのでそこまで信用できません(と、あなたには言うまでもありませんね)
無論、全てのアカウントをそうする必要などありません(そんなことできません)
Google、Apple、MS、1Passwordなどの『PW管理ツール自体のパスワード』あたりの絶対に失いたくないアカウントだけは少し手間がかかることを受け入れざるを得ないでしょう。急がば回れ、転ばぬ先の杖です
(理屈で言えば『PW管理ツール自体のパスワード』だけがそうなっていれば事足りるのですが、リスクヘッジしておいたほうがいいでしょう)
余談ですが、
私はGoogleやMSの締め出されたくないアカウントには認証方法(≒本人確認手段)を10以上設定しています
いま確認したら、Googleのパスキーは7つもありました(Android端末数台、PC数台、iCloudキーチェーン、…etc)
もちろん、これは万人にお勧めできるやり方ではありません
弊社の調査により、お客様の口座が不正アクセスの影響を受けた可能性があることが確認されました。
このままご対応いただけない場合、補償申請が無効となり、関連口座に出金制限や取引停止などの措置が取られる可能性がございます。
本メールは、損失補償の対象と判断されたお客様のみにお送りしております。
■ ご対応内容
お客様には「ログインによる本人確認」のみお願いしております。
ログイン後、弊社にて過去の取引内容を自動で確認し、補償の可否を判定いたします。
{url_var}
■対応期限
この日時を過ぎた場合、補償の対象外となる可能性がございますので、必ず期限内にご対応ください。
平素よりSBI証券をご利用いただき、誠にありがとうございます。
弊社では、近年の不正アクセス増加および個人情報漏洩事案を受け、お客様の大切な資産ならびに個人情報を保護する取り組みを強化しております。その一環として、2025 年 6 月31 日（土）より 多要素認証 の適用をすべてのお客様に対して義務化いたしました。
特に、FIDO（スマートフォン認証）をご登録いただいていないお客様に対しては、セキュリティ確保の観点から、電話番号認証によるログイン確認を強制適用させていただいております。この認証は、実際にお客様が使用されている端末・環境からのアクセスであることを当社が正しく判定するために不可欠なプロセスです。
現時点で、お客様のアカウントは電話番号認証を介したアクセスが必要な状態ですが、認証プロセスの一部に未完了の項目がございます。つきましては、下記リンクよりご本人確認の最終ステップを完了いただきますようお願い申し上げます。
2025 年 6 月31 日（土）
パスワードの再設定であれば、電話番号かメールアドレスを複数登録できます[訂正]「再設定用の電話番号またはメールアドレス」に直接複数登録することはできませんでした。すみません。他の方法で登録した連絡先が本人確認の際に使われるみたいです。[/訂正]
再設定用の電話番号またはメールアドレスを設定する - パソコン - Google アカウント ヘルプ
なので、一般論で言えば、
というのが正攻法です
※これはGoogleに限らず、一般的なサービスは大概そうするしかないと思います
とはいえ、フリーメールや他人の電話番号等を紐付けたくない場合(多数派だと思う)、
というのが、比較的楽なんじゃないでしょうか(当然、人によるので一概には言えませんが)
安易なパスワードや使い回しは論外(不正アクセスされたら元も子もない)として、
というのであれば、Google使うなとまでは言いませんが、スマホを無くしたら「詰み」の可能性が高いので、初めから使わない方が賢明だとは思います
というか、Googleの仕様如何に関わらず、この条件でスマホを無くした状況からリカバリできる方法が思いつきません
パスキーに対する批判は首肯できるものが殆どですが、「詰みやすくなる」というのは誤解であることが多いです
(パスキーを有効化したら他の認証方法が無効化されるサービスも希にあるので、必ずしも間違っているわけではないです)
パスキーとは、端的に言ってしまえば、使い方が統一された"パスワードマネージャー"に過ぎません
Googleアカウントが特殊なのは、大本の増田にもあるとおり、その"パスワードマネージャー"自体のアカウントとなる点であり、こればかりは多少管理の手間がかかるのは受け入れざるを得ないと思います
これは『1Password自身のパスワードをどう管理するべきか』という課題と近いと思っています
--
[追記]
まだご覧になっているかわかりませんが、一応以下補足しておきます
ご提示されている手順は、
2FAの認証より手前の、パスワードでの認証に失敗している状態です
なので、単純に「パスワードの再設定に必要な手順」をGoogleが提示しているわけです
(途中で「TOTPかデバイスコード」を求められるのは、2FAではなく、パスワード忘却に対する"救済措置"のようなものと思われます)
いうまでもありませんが、
「パスワード」自体と「パスワード再設定用の連絡先」の2つを同時に失うと、パスワード再設定は恐らくできません
##企業の約款ファイルにおけるプロンプトインジェクションと不正アクセスの関係
企業がサービス利用時に同意を求める約款ファイルに、AIによる要約を妨害する目的でプロンプトインジェクション的な文言（例：毒薬条項の隠蔽）が埋め込まれている場合、それが「不正アクセス」に該当するかどうかについて解説します。
中略〜
### 今回のケースへの適用
先ほど、NHKで損保ジャパンの情報漏洩事故について報道が出た。
1750万件というのは、国内の漏洩事例のなかでは5指に入るくらい、かなり大きい規模だ。
もっとも、マイナンバーやクレカ・口座情報は漏洩しなかったようなので、影響度で考えるとそこまで大きくないと見ることもできる。
この事例を眺めていて面白いと感じたポイントが2つあったのでずらずらと書いた。
不正アクセス自体は4/17～4/21にかけて発生したようだ。その後、4/25に損保ジャパンが第一報を出している。
（https://www.sompo-japan.co.jp/-/media/SJNK/files/news/2025/20250425_1.pdf）
おそらく、第一報の後に調査やら金融庁への報告を行い、再発防止をとりまとめ、金融庁に再度報告、それから今回のリリースといった流れだろう。
流出情報の特定に時間がかかりそうなことを踏まえると、大企業にしてはそれなりにスピード感のある対応のように思える。
※筆者は損保での経験はないが、銀行や生保のシステムに携わった経験があり、金融システムの複雑性についてある程度勘所がある。そのため、今回のような事例で被害件数や他システムへの影響などを調べるのにかなり手間がかかりそうで、1か月ちょっとで正式発表まで持って行けたのはかなり汗をかいただろうと想像している。
気になったのはこのポイント。「指標管理を主としたサブシステム」とは、データ分析やBIを行うためのシステムのように見える。
こんなシステムに生の個人情報を大量に入れるわけはないので、おそらくこのサブシステムへの侵入を土台に、他システムやDBへアクセスされた（水平移動）と見るのが妥当ではないか。
「損保ジャパン 指標管理 システム」でGoogle検索するとそれらしきシステムの紹介が2つ出てくる。
こちらは今年3月に日経に載った、営業社員の活動管理システムだ。システムの内容はよくある行動管理系のもので目新しさはない。
営業管理系のシステムというのは基本的に社内で完結するため、情報漏洩のリスクは低い。社内NWからしかアクセスできないよう設計するのが一般的だからだ。
今回のケースはこちらのシステムではないか。ページ右下に「「SOMPO Report」の提供開始」とあり、”保険代理店自身が指標やアンケート結果を管理・確認できるツール「SOMPO Report」の提供を開始しました。複数の指標の総合的な分析に加え、お客さまアンケート結果をタイムリーに確認できることで、お客さまの声に基づく保険代理店の業務改善・品質向上を支援しています。”と書かれている。
SOMPO reportで検索すると代理店が画面をアップロードしてくれている。俺が心配することじゃないけどこれってWebにアップして大丈夫なのか？
https://lifesupport.agency/download/kpi-kanri.pdf
これを見るに、お客様アンケートの結果を集計して代理店活動にフィードバックするようなシステムに見える。
生の個人情報をこのシステムに保管しているかは不明だが、アンケートの集計に当たり契約者情報を参照しているのだろう。今回は、このシステムへの不正アクセスが行われ、その後にこのシステム自体の参照権限を用いるなどして個人情報が抜かれたのではないだろうか（現時点で公表されている情報は何もないため、これは妄想だ。不正アクセスの手段というのは非常に多岐にわたるので、これ以外の手法である可能性も全然ある）。
保険になじみのない人向けに説明すると、日本の大手損害保険は代理店方式で商売をしている。保険の提供や保険金の支払元は保険会社だが、保険を消費者（業界では契約者と呼ぶ）に販売するのは代理店だ。
損害保険と言えば自動車保険が最も有名だが、自賠責でも任意でも、保険の加入はディーラーや中古車販売業者で行う人がほとんどだろう。この場合、ディーラーや中古車業者が「保険代理店」として保険を売る資格を有しており、販売を代行しているという図式だ。
保険会社と代理店は全く別の会社なので、上記のSOMPO Reportのようなシステムを保険会社から代理店に提供する場合、インターネット経由でアクセスさせることが多い。このとき、セキュリティ対策をきちんとしないと不正アクセスされてしまうリスクが多いというわけだ。
余談だが、普通は代理店向けに保険会社が総合窓口的なシステムを提供し、その中の1メニューとして各システムが存在するという方式が一般的だ。ただし、保険というのは非常に情報システムが多く、1人のユーザーに対していくつもの異なるWebページを異なるユーザー情報で利用させるような仕組みがまだまだ残っている。SSOは一部分だけ導入済みというのが実情だ。更に脱線するが、保険代理店というのは複数の保険を扱うことが一般的だ。東京海上、損保ジャパン、三井住友海上、あいおい同和の大手4社に加えていくつか扱っているというケースが多い。それぞれの保険会社が複数のシステムに個別のIDを設定するため、代理店が業務全体で管理するユーザー情報が膨大になって業務を圧迫している。早く何とかしてほしい。
2024年10月に金融庁が「金融分野におけるサイバーセキュリティに関するガイドライン」（https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf）をリリースしたのは業界関係者なら記憶に新しいだろう。保険業界を含む金融分野の情報システムについて、実施するべきサイバーセキュリティ対策や管理方針をまとめたものだ。
メガバンクや証券会社、カード会社、保険会社はこのガイドラインへの対応でそれなりに手間をかけている。今回のインシデントを受け、ガイドラインが更新・加筆されるようなら追加の作業が発生して現場としてはかなり面倒なことになりそうだ。ベンダの立場からすると追加の発注をもらえるのでありがたいところだが……
個社の事故を受けてガイドラインに手を加えるようなことを金融庁がするか？と言われるとそんなことはなさそうな気もする。ただ、今回は件数が大きく、事故の詳細な内容によっては監督官庁として手綱を強める必要を感じるかもしれない。面倒なことにならないといいのだが……
損保ジャパンをはじめとするSOMPOグループの中には、セキュリティベンダも存在する。
「ＳＯＭＰＯリスクマネジメント株式会社」という名前で、脆弱性診断からセミナー、各種セキュリティ製品導入まで手広くやっているようだ。
従業員数は560名。セキュリティ会社としては大きめだろう。参考までに、ラックが2,295名、エムオーテックスが472名、GMOイエラエが302名。
外販事業で知名度が高い印象はないのでグループ会社向けにもセキュリティ診断等を提供しているものだと思うが、今回のシステムの診断とかはやっていたんだろうか。
正直なところAIの登場でマルウェア製作とかゼロデイ攻撃とかが簡単になってるし、侵入されてない/侵入され得ない大企業ってほとんど存在しないのでは？
