セキュリティ | SQAT®.jp

2025年8月28日2025年9月28日

連載記事：企業の「攻め」と「守り」を支えるIoT活用とIoTセキュリティ
第１回：今さら聞けないIoTとは？─IoTデバイスの仕組みと活用例で学ぶ基礎知識―

Security NEWS TOPに戻る
バックナンバー TOPに戻る

はじめに：連載の背景

新聞やビジネス誌を開くと「IoTとは」という見出しを見かける日も多くなりました。しかし、IT部門や経営層の会議で実際に自社では何をどう活用するのかと議論が始まると、抽象論のまま立ち往生してしまう例が多いのも事実です。本連載では「IoTデバイスの基本」「IoTセキュリティの脅威」「企業が実践すべき対策」を三回にわたって解説します。最後まで読むことで、読者の皆様が社内で議論を前に進めるための土台が整えられることを願っています。

「Internet of Things」誕生の背景

IoTという造語は 1999年、英 Auto-ID Center（現MIT Auto-ID Lab）でRFID研究に携わっていたケビン・アシュトン氏が提唱したのが始まりとされています。当時はネットワークに常時接続するセンサーは高価で、実用化は一部の製造ラインに限られていました。ところが2010年代に入り、3G／4G回線の広域整備とWi-Fiチップの低価格化が進んだことで導入コストが急速に低下し、クラウドが解析基盤を提供する現在の「IoT構造」が定着しました。総務省『情報通信白書令和5年版』によれば、世界のIoT機器（以降、本記事内ではIoTデバイスまたはIoT機器と表記します）の稼働台数は2022年時点で約147億台、2025年には270億台超へ倍増すると見込まれています。

IoT機器の台数推移（2022-2025年）

参考：IoT Analytics「IoT 2022: Connected Devices Growing 18% to 14.4 Billion Globally」,「State of IoT 2024: Number of connected IoT devices growing 13% to 18.8 billion globally」(PDF)

IoTアーキテクチャの四層モデル

多くの国際標準では「デバイス層・ネットワーク層・プラットフォーム層・アプリケーション層」という四つの階層で IoTシステムを整理します。デバイス層では温度や振動を“測る”センサーと、モーターやリレーを“動かす”アクチュエータが中心的な役割を担います。ネットワーク層ではWi-Fi、Bluetooth Low Energy、LoRaWAN、NB-IoT、5Gなど目的に応じた通信技術が選択され、プラットフォーム層ではAWS IoT CoreやMicrosoft Azure IoT Hub、NTT Communications Things Cloud^®などがデータの収集・蓄積・分析をつかさどります。最上位のアプリケーション層が可視化ダッシュボードや制御アプリを提供し、ユーザ企業はそこから意思決定を行うという構造です。

参考：NIST SP 800-213「IoT Device Cybersecurity Guidance for the Federal Governent: Establishing IoT Device Cybersecurity Requirements」,GeeksforGeek「Architecture of Internet of Things (IoT)」,Zipit Wireless Blog「4 Layers of IoT Architecture Explained」

身近に増えるIoTデバイスの実像

今や一般家庭にも浸透するスマートスピーカーは、音声認識マイクと温湿度センサーを内蔵し、クラウド側で音声コマンドを解析してエアコンや照明を制御します。オフィス向けではネットワークカメラがクラウド映像分析サービスと連携し、不審者や深夜の残業者を自動検知します。製造現場で稼働する振動センサーは0.1秒単位でモーターの揺れを測定し、閾値しきいちを超える振幅を捉えると、PLC（Programmable Logic Controller）へ緊急停止信号を返します。農業分野では土壌水分センサーと気象APIを組み合わせ、最適な潅水量を算定してポンプを自動起動するスマート農業システムが普及し始めました。医療分野のウェアラブル端末は心拍・SpO₂・体温をクラウドに送信し、医師が専用アプリで異常を見逃さない仕組みを構築しています。

IoT例から見えるビジネスインパクト

製造業の典型的なIoT事例は予知保全です。独Bosch Rexroth社はラインに5,000個のセンサーを実装し、振動データと過去の故障ログをAIが突き合わせることでダウンタイムを25％削減したと発表しています。小売業では米WalmarがRFIDと重量センサーを併用してリアルタイム在庫を可視化し、欠品率を16％下げたことで年間10億ドル規模の機会損失を回避したと報告しました。日本国内でも関西電力がスマートメーター経由で収集した使用電力データを解析し、節電インセンティブのプログラムを顧客へ提示することでピークカットに成功した事例が公表されています。

導入メリットの裏に潜む注意点

リアルタイムデータに基づく迅速な意思決定、業務の自動化、新規サービス創出という恩恵は大きいものの、IoTセキュリティが後手に回るとその利点は一瞬で吹き飛びます。総務省『IoT セキュリティガイドライン ver 1.0』では、「初期パスワードのまま運用」「ファームウェアの自動更新機能が無効」といった“ありがちな設定”を放置すると、攻撃者にネットワークの踏み台として悪用される危険性が高いと明示しています。次回以降、脅威と対策を深掘りしますが、まずは“便利さとリスクは表裏一体”であると認識することが企業リーダーへの第一歩です。

―第2回へ続く―

【連載一覧】

―第1回「今さら聞けないIoTとは？─IoTデバイスの仕組みと活用例で学ぶ基礎知識」―
―第2回「身近に潜むIoTセキュリティの脅威とは？─リスクと被害事例から学ぶ必要性」―
―第3回「企業が取り組むべき IoT セキュリティ対策とは？─実践例に学ぶ安全確保のポイント」―

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月3日（水）13:00～14:00
「止まらないサイバー被害、その“対応の遅れ”はなぜ起こる？～サイバー防衛の未来を拓く次世代XDR：大規模組織のセキュリティ運用を最適化する戦略的アプローチ～」

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年8月22日2025年9月28日

AIコーディング入門
第3回：AIエージェント時代のコーディング：MCPとA2Aとは

Security NEWS TOPに戻る
バックナンバー TOPに戻る

生成AIを活用したコーディングの現場で、いま最も注目されているトピックのひとつが「AIエージェント」です。エージェントは人間の最小限の指示をもとに計画・推論・実行を繰り返す自律的な仕組みであり、シングルエージェントからマルチエージェントまで多様なアーキテクチャが登場しています。さらに通信の標準化を担うMCP（Model Context Protocol）やA2A（Agent-to-Agent）といったプロトコルの整備が進み、エコシステム全体に大きな影響を与えています。本記事では、AIエージェントの基本構造、利点とリスク、新しい標準プロトコルの動向について解説します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

AIエージェントとは何か

生成AIを使用したコーディングのなかでも昨今注目を浴びているのがAIエージェント（Agentic AI）を用いたAgenticコーディングです。Agenticコーディングの前にまずはAIエージェントの動きを見てみましょう。AIエージェントは人間による最低限の指示や監督をもとに計画・推論・実行を繰り返す、自律的処理を行うAIです。

シングルエージェントの仕組み

まずはわかりやすい、単一のエージェントのみが動くシングルエージェントのアーキテクチャを見てみましょう。下図はシングルエージェントのアーキテクチャを示したものです。

図1:シングルエージェントのアーキテクチャ

シングルエージェントのアーキテクチャの図 — 参考：OWASP LLM Applications & Generative AI Top 10（https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/）, p.8より弊社翻訳

シングルエージェントモデルではアプリケーションからの入出力（人間による指示）をもとに単一のエージェントが自律的にルーチンを実行し、LLMモデルや関連サービスとの間の連携を図り、出力を行います。人による監督はHuman in the loop（HITL）という形で行われます。この図の中でいうAIアプリケーション（及びエージェント）が各種サービスやデータベースなどと通信する際、昨今ではMCP (Model Context Protocol)を用いた標準化された通信プロトコルが用いられていることが増えています。MCPについては後程解説します。

マルチエージェントの仕組み

一方マルチエージェントのアーキテクチャは下図のとおりです。

図2:マルチエージェントのアーキテクチャ

マルチエージェントのアーキテクチャの図 — 参考：OWASP LLM Applications & Generative AI Top 10（https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/）, p.10より弊社翻訳

マルチエージェントの場合はAIアプリケーション（及びエージェント）と各種サービス、DBなどとのMCPでの通信に加えて、エージェント間の通信（図中のマルチエージェント通信）が必要となります。エージェント間の通信を標準化したものがA2A（Agent2Agent）プロトコルになります。こちらも後程解説します。

AIエージェントの利点とリスク

AIエージェントを利用する場合、人間の監督・指示が最低限で済む一方で、以下のような利点と課題・リスクが存在します。

図3:AIエージェントの利点と課題・リスク

上記に挙げたAIエージェントのリスクのうち、「誤行動・報酬設計の欠陥」と「倫理・説明責任」を取り上げて解説します。

誤行動・報酬設計の欠陥

報酬のミススペックによりエージェントが意図しない行動をとることを指します*1。最近の報告ではエージェントが自身の地位を脅かされる場合や、目標の対立が発生した場合に内通者のような不正行動を低率ながら遂行する可能性が指摘されています*2。

倫理・説明責任

AIエージェントの自律判断の責任を負うのは誰かという問題。倫理的な問題に加えて著作権に代表されるような法的な問題に加えて、信頼性・公平性といった問題についての課題も指摘されています*3https://arxiv.org/pdf/2502.00289v3。

新しい標準プロトコル：MCPとA2A

ここ最近、「MCP」や「A2A」といったキーワードを目にする機会が増えているのではないでしょうか。ここでは簡単にMCPとA2Aについてご紹介します。

MCP（Model Context Protocol）とは

MCPとはAIアプリケーションがLLMにコンテキストを提供する方法を標準化するプロトコルで、Anthropicによって仕様が策定され、現在はオープンソース化されています。現在C#、Java、Kotlin、Python、Ruby、Swift、TypeScript向けのSDKが提供されており、幅広い言語環境で利用できること、AIアプリケーションのUSB-Cポートとして標準化されていること、そして認証認可にOAuth2.1を用いることが必須要件となっている点など、順次仕様が変更されており、新しいプロトコルとして注目を浴びています。またオープンソースであることやそのコンセプトから多くの実装例がすでに存在しています。一方でセキュリティ上の問題点も指摘されています。

図4:MCP関連の主なセキュリティ課題

MCP関連のセキュリティ課題（仕様レベル・実装上の問題、AI・MCA独特の脆弱性、一般的な問題）

A2A（Agent-to-Agent）とは

A2AはGoogleが立ち上げたエージェント間の通信プロトコルで、2025年6月にLinux財団に寄付され、Linux財団を中心に開発が進められています。こちらはGoogleのVertexなどを皮切りに実装が始まっています。A2Aプロトコルはマルチエージェントでの処理のニーズの増大、クラウドでのベンダーロックイン問題の影響でベンダーロックインの回避への強い要求があったことや、AIエージェントに対するコンプライアンスやガバナンス要求（EUのAI法など）の高まりといったところにうまくマッチしたものとも言えます。

AIエージェントは今後の開発を大きく変える存在ですが、その基盤を支えるのがMCPやA2Aといった標準プロトコルです。次回第4回では、これらの仕組みをより詳しく掘り下げ、エンジニアが知っておくべき活用ポイントを解説します。

―第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」へ続く―

【参考情報】

【連載一覧】

―第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」―
―第2回「プロンプト以外で効率化！開発体験の改善手法」―
―第3回「AIエージェント時代のコーディング：MCPとA2Aとは」―
第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」
第5回「AIとセキュリティ：Non‑Human Identity とAIエージェントの課題」
第6回「AIエージェントのセキュリティ対策と今後の展望」

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年8月14日2025年9月28日

狙われる医療業界2025 医療機関を標的とするサイバー攻撃

Security NEWS TOPに戻る
バックナンバー TOPに戻る

前回の記事の公開から約5年が経ちましたが、医療機関を標的とするサイバー攻撃の脅威はむしろ増加しています。特にランサムウェアによる被害は国内外問わず深刻化し、患者の命が危険に晒されてしまう可能性も出てきています。いまやインシデントを“他人事”とせず、「命を守るもの」という認識で組織一丸となってセキュリティ対策の見直しをすることが重要です。本記事では医療機関へのサイバー攻撃の脅威とセキュリティ対策の見直しのためのポイントをご紹介します。

2020年12月公開の記事「狙われる医療業界―「医療を止めない」ために、巧妙化するランサムウェアに万全の備えを」をまだご覧になっていない方はぜひ、この機会にご一読ください。

世界的に高まる医療分野へのサイバー攻撃

ランサムウェアによる被害は世界中で後を絶たず、いまや医療分野は重要な標的の一つとされています。米国のセキュリティ監視サイトRansomware.liveの統計によれば、2025年時点でランサムウェア被害を受けた業種の中で、医療・ヘルスケア関連は第3位に位置しています。医療業界が金融や行政に並ぶほどの標的となっている現実は、決して無視できません。

Ransomware.live統計円グラフ（ランサムウェア被害を受けた業界） — 出典：Ransomware.live「Ransomware Statistics for 2025」（https://www.ransomware.live/stats）

国内でも相次ぐ深刻な被害事例

日本国内でも、深刻な被害事例が相次いで報告されています。たとえば2024年3月、鹿児島県の国分生協病院では、ランサムウェアによるサイバー攻撃により、電子カルテをはじめとする複数のシステムが使用できなくなり、患者の診療に支障が出るという被害が発生*4しました。また、同年の5月に起きた岡山県精神科医療センターでは、外来診療の一部を中止せざるを得ない事態に追い込まれました*2。このように、サイバー攻撃は単に業務の一時停止を招くだけでなく、医療提供そのものに影響を与え、患者の命を危険に晒す恐れがあるという点で、他業種におけるサイバー被害とはその意味において一線を画します。

サイバー攻撃は“日常の医療”を止めうる

Silobreaker社がまとめた医療業界に関する分析レポートでも、ヘルスケア分野に対するサイバー脅威の増加は顕著であり、医療情報の価値の高さとシステムの脆弱性が攻撃を呼び込んでいると指摘されています。国内外でのこうした事例は、「サイバー攻撃が日常の医療を止め得る存在である」という現実を強く物語っています。特に日本では、「まさかうちが」という意識が依然として根強く残っているのが現状ですが、医療機関はすでに、攻撃者にとって“おいしいターゲット”であることを自覚すべき時期に来ています。

攻撃者はなぜ医療機関を狙うのか

攻撃側の論理①わきの甘さ＝「機会要因」の存在

医療機関がサイバー攻撃の標的になる。―これはもはや偶発的なものではなく、確かな傾向として定着しつつあります。過去の記事でも言及しましたが、2025年現在ではその背景にある“攻撃側の論理”がより鮮明になってきています。

多くの人が誤解しがちなのは、「医療機関は狙われている」という表現があたかも特定の施設に対して意図的な攻撃が行われている、という印象を与えてしまう点です。確かに、一部には病院のネットワークやデータに照準を合わせた標的型攻撃も存在します。しかし実態としては、多くの場合、攻撃者は最初から「病院を狙って」いるわけではありません。攻撃者は、不特定多数の組織や端末に対して無差別にスキャンをかけ、リモートアクセスサービスやVPN機器、ファイル共有サーバといった、公開された情報から侵入経路を探しています。そしてその中で、意図せず医療機関が引っかかるのです。つまり、標的にされたのではなく、“侵入可能だったから侵入された”というのが現実なのです。

医療機関では古いシステムが更新されずに残っている、または、ネットワークの分離が不完全なまま稼働していることがあります。また、パスワードの使い回し、脆弱性が放置されたソフトウェア、機器の寿命サイクルの見落としなど、基本的なセキュリティ対策に隙があることが少なくありません。そして、攻撃者にとっては、それこそが格好の「入り口」になるのです。

攻撃側の論理②「動機」金になる標的としての医療機関

ランサムウェア攻撃を実行するサイバー攻撃者の目的は、金銭的な利益です。医療機関には、個人情報（診療記録、保険情報、連絡先など）や経営上の内部資料、研究データといった売買可能な資産が豊富にあります。また、医療機関は儲かっているように思われており、そのうえで業務の中断が患者の生命に直結するため、身代金の支払いに応じやすいに違いない、と見られているわけです。つまり、医療機関が狙われるのは、「わきが甘いから侵入しやすい」＋「金銭的利益を得やすい重要なデータの宝庫である」＝“コストパフォーマンスに優れた良い標的”と見なされているからと考えられます。

2020年以降医療サイバーセキュリティはどう変わったのか

制度とガイドラインの整備が進む

前回の記事からの5年間で、医療分野のサイバーセキュリティを取り巻く制度やガイドラインも着実に充実してきています。例えば2025年5月に、厚生労働省から「医療機関等におけるサイバーセキュリティ対策チェックリスト（令和7年5月版）」が公開され、以前に比べて具体的かつ実践的な内容になっています。クラウド環境やBCP（事業継続計画）への配慮、IoT・BYODといった新たなリスクへの言及も盛り込まれています。

また、CSIRT（Computer Security Incident Response Team）を設けたり、EDR（Endpoint Detection and Response）などの対策製品を導入したりする医療機関も増えてきました。CSIRTを中心とした地域単位の訓練や、院内外のネットワーク構成の共有と点検を含む取り組みが、学術会議や業界団体の枠組みとして増加しています*3。サイバー攻撃に備える土台作りは、着実に進みつつあるといえるでしょう。

2025年いまだ残る基本的な課題

一方で、5年前と変わらぬ問題を目にする場面も少なくありません。その一つが、「パスワード管理」です。初期設定のまま放置されたアカウント、業務上の利便性から生まれる使い回し。こうしたわきの甘さが、攻撃者の入り口になることは以前から分かっていたはずですが、2024年の岡山県精神科医療センターの事例などを見ると、なおも同様の傾向が残っていることがうかがえます。また、電子カルテやシステムのクラウド化に対しても、依然として現場では極端な見方が交錯しているように思えます。「クラウドだから安全」と根拠のない安心感を持つ一方で、「クラウドだから怖い」「電子カルテという形式そのものが危ない」といった漠然とした不安も根強く見受けられます。

どちらにしても共通するのは、仕組みやリスクを正しく理解しないまま思い込んでいるケースが少なくないということです。実際には、クラウドの活用は有効な手段のひとつでありつつも、アクセス制御や端末管理、ネットワーク構成など、設定次第でその安全性は大きく変化します。こういった基本的な理解の重要性や注意点は、5年前から現在も変わらずに示され続けてきたものですが、いまだに“本質的な理解”が広がり切っていないように見受けられます。

基本的な課題の根底には、インシデントを“自分事”として捉えづらい空気があるのかもしれません。実際に深刻な被害を受けた他機関の事例を目にしても、「うちには関係ない」とどこかで思ってしまう感覚。それは、ごく自然な反応である一方で、取り返しのつかないインシデントに繋がりかねません。

自組織のセキュリティ対策の見直しを

医療機関向けチェックリストやガイドラインの活用

ここまで見てきたように、医療機関に対するサイバー攻撃は後を絶たず、その影響は診療の継続性や患者の安全、そして組織の信頼性にまで及びます。「自分たちは大丈夫だろう。」「人命最優先で、他を考えている余裕はない。」―そのように考えがちですが、日々の業務に追われている医療現場こそ、今一度立ち止まって、対策の棚卸しを行うことが求められています。対策の見直しにあたっては、厚生労働省が公開している「医療機関等におけるサイバーセキュリティ対策チェックリスト（令和7年5月版）」の活用が効果的です。

厚生労働省「医療機関等におけるサイバーセキュリティ対策チェックリスト（令和７年５月）」https://www.mhlw.go.jp/content/10808000/001253950.pdf

本チェックリストは、技術的な対策だけでなく、組織体制や訓練、業者選定の観点まで網羅されており、現場レベルでも活用しやすい実践的な内容となっています。また、業界全体で参照される基準として、次のようなガイドラインも押さえておくとよいでしょう。

厚生労働省「医療情報システムの安全管理に関するガイドライン　第6.0版（令和5年5月）」
経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」

これらの資料には、医療の特殊性を踏まえた対応策が具体的に記載されており、ベンダや関係業者との連携の際にも参考となります。

現場の声と経営的視点をつなげる「可視化」

セキュリティ対策は単なる技術的作業にとどまらず、組織全体で「守るべきもの」を共通認識することが大切です。そのためにも、経営層が積極的に関与し、現場の声を聴きながら継続的な投資と改善を進めていくことが求められます。医療機関にとって、セキュリティはコストではなく、患者の信頼と組織の生命線であることを改めて認識すべきです。その助けになるのが、リスクの「可視化」です。

仮に端末のひとつがマルウェアに感染したとき、その端末が院内のどの機器と通信しているのか、そこから電子カルテや予約システムにアクセスされたりしないか、バックアップはきちんと機能するかなどなど…。こうした攻撃時の経路や起きうる事象をあらかじめ可視化し、把握しておくことは、被害拡大の防止やインシデント対応の迅速化に大きな効果をもたらすのみならず、経営層の理解を得ることにもつながります。可視化によって得られる「想定していなかった侵入経路」「明らかになる不十分なセキュリティ対策」「攻撃発生時に起きうる具体的な被害」といった情報が、経営層や多くの医療従事者に理解してもらい、組織全体で防御力を高めるための重要な意思決定のための正しい判断材料となりえるでしょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。詳細・お見積りについてのご相談は、以下のフォームよりお気軽にお問い合わせください。後ほど、担当者よりご連絡いたします。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

また費用の問題から十分な初動対応ができないといった問題が発生しかねない状況を憂え、SQAT^® 脆弱性診断サービスのすべてに、サイバー保険を付帯させていただいています。

サイバー保険付帯の脆弱性診断サービス

BBSecのSQAT^® 脆弱性診断サービスすべてが対象となります。また、複数回脆弱性診断を実施した場合、最新の診断結果の報告日から1年間有効となります。詳細はこちら。
https://www.bbsec.co.jp/service/vulnerability-diagnosis/cyberinsurance.html
※外部サイトにリンクします。

エンドポイントセキュリティ

組織の端末を24時間365日体制で監視し、インシデント発生時には初動対応を実施します。
https://www.bbsec.co.jp/service/mss/edr-mss.html
※外部サイトにリンクします。

インシデント初動対応準備支援

体制整備や初動フロー策定を支援します。
https://www.bbsec.co.jp/service/evaluation_consulting/incident_initial_response.html
※外部サイトにリンクします。

ウェビナー開催のお知らせ

2025年8月20日（水）13:00～13:30
「EC加盟店・PSP必見！クレジットカード・セキュリティガイドライン6.0版対応ウェビナー」

2025年8月27日（水）13:00～14:00
「【最短7営業日で診断＆報告】サイバー保険付帯脆弱性診断「SQAT® with Swift Delivery」のご紹介」

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2025年2月17日2025年8月12日

記録破りのDDoS攻撃！サイバー脅威の拡大と企業が取るべき対策とは？

Security NEWS TOPに戻る
バックナンバー TOPに戻る

近年、DDoS攻撃の規模と頻度が急激に増加しており、企業や組織にとって無視できない脅威となっています。特に、2024年第4四半期には、過去最大規模となる5.6テラビット毎秒（Tbps）のDDoS攻撃が確認され、サイバー攻撃の新たな段階へと突入したことがわかりました。この攻撃は、わずか80秒間で1万3,000台以上のIoTデバイスを利用して実行され、Cloudflare社のDDoS防御システムによって自動的に検出・ブロックされました。

お問い合わせ

お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

DDos攻撃の事例として、SQAT.jpでは日本航空へのサイバー攻撃の実態についても解説しています。こちらもあわせてぜひご覧ください。
「【徹底解説】日本航空のDDoS攻撃被害の実態と復旧プロセス」
「Dos攻撃とは？DDos攻撃との違い、すぐにできる3つの基本的な対策」

DDoS攻撃の増加と進化する手口

2024年第4四半期には、Cloudflare社が軽減したDDoS攻撃の件数が690万件にのぼり、前四半期比16%、前年比83%の増加を記録しました。さらに、1Tbpsを超える大規模攻撃の件数は前四半期比で1,885%も増加し、これまで以上に大規模な攻撃が常態化しつつあります。

HTTP DDoS攻撃では、既知のボットネットによる攻撃が全体の73%を占め、11%は正規のブラウザを装った攻撃、10%は疑わしいHTTPリクエストによる攻撃でした。ネットワーク層（L3/L4）攻撃では、SYNフラッド（38%）、DNSフラッド（16%）、UDPフラッド（14%）が主要な手法として確認されています。また、Miraiボットネットの亜種による攻撃が特に顕著であり、2024年第4四半期には、この攻撃手法の使用頻度が131%も増加しました。

企業が直面するDDoS攻撃のリスクとは？

DDoS攻撃がもたらす影響は多岐にわたります。最も直接的な被害は、システムのダウンによる業務停止であり、企業の信用低下や顧客離れにつながる可能性があります。また、近年増加している「ランサムDDoS攻撃（Ransom DDoS）」では、攻撃を受けた企業が身代金の支払いを要求されるケースが増えています。2024年第4四半期には、Cloudflare社の顧客でDDoS攻撃を受けた顧客のうち、12%が身代金の支払いを求められ、前年同期比で78%の増加を記録しました。

業界別にみると、通信業界が最も多くの攻撃を受け、次いでインターネット関連業界、マーケティング・広告業界が標的となっています。特に、金融業界は依然としてサイバー犯罪者にとって魅力的なターゲットとなっており、資金詐取を目的とした攻撃が増加しています。

DDoS攻撃から企業を守るための対策

DDoS攻撃の脅威が拡大するなか、企業は効果的な防御策を講じる必要があります。特に、以下のような対策が推奨されます。

常時オンのDDoS防御システムの導入
DDoS攻撃の多くは短時間で発生するため、人間の対応では間に合わないケースが多いです。自動検知・防御機能を備えたDDoS対策ソリューションを導入することで、攻撃を迅速に無力化できます。

ネットワーク層とアプリケーション層の両方を保護
DDoS攻撃には、L3/L4（ネットワーク層）攻撃とL7（アプリケーション層）攻撃があります。両方の層に対する防御対策を講じ、ファイアウォールやWAF（Web Application Firewall）を活用することが重要です。

ゼロトラストアーキテクチャの採用
攻撃者の侵入を最小限に抑えるために、ゼロトラストモデルを導入することも有効です。認証・認可プロセスを強化し、アクセス制御を厳格化することで、不正なトラフィックを遮断できます。

クラウドベースのDDoS対策の活用
オンプレミスのDDoS対策はコストが高く、攻撃の規模が拡大するにつれて対応が難しくなります。クラウドベースのDDoS防御サービスを活用することで、スケーラブルなセキュリティ対策を実現できます。

定期的な脆弱性診断とインシデント対応計画の策定
攻撃のリスクを最小限に抑えるために、定期的なセキュリティ監査を実施し、DDoS攻撃を想定したインシデント対応計画を策定することが不可欠です。特に、SLA（サービスレベルアグリーメント）を明確にし、攻撃発生時の対応フローを事前に決めておくことが重要です。

今後のDDoS攻撃トレンドと企業が取るべきアクション

DDoS攻撃は今後さらに巧妙化し、大規模化すると予想されています。特に、AIを活用したボットネット攻撃や、IoTデバイスを悪用した攻撃が増加する見込みです。さらに、特定の企業や業界を標的とした「高度な標的型攻撃（APT）」の手法がDDoS攻撃にも応用される可能性があります。

企業は、単に防御するだけでなく、プロアクティブなセキュリティ戦略を採用し、攻撃を未然に防ぐ体制を構築する必要があります。DDoS攻撃はもはや一部の企業だけの問題ではなく、あらゆる業界にとって喫緊の課題となっています。

常に最新の脅威情報を把握し、効果的な防御策を講じることで、企業のシステムとデータを守ることができます。DDoS攻撃のリスクを最小限に抑えるためには、今すぐ適切な対策を実施することが求められるでしょう。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

サイバーインシデント緊急対応

ウェビナー開催のお知らせ

2025年2月19日（水）14:00～15:00
「Web担当者に求められる役割とは？Webサイトのガバナンス強化とセキュリティ対策を解説」

2025年2月26日（水）13:00～14:00
「AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク」

2025年3月5日（水）13:00～14:00
「ランサムウェア対策の要！ペネトレーションテストとは？-ペネトレーションテストの効果、脆弱性診断との違い-」

2025年3月12日（水）14:00～15:00
「サイバー攻撃に備えるために定期的な脆弱性診断の実施を！-ツール診断と手動診断の比較-」

最新情報はこちら

2024年12月9日2025年8月12日

2038年問題とは？-2000年問題の再来？2038年問題の影響と解決方法-

Security NEWS TOPに戻る
バックナンバー TOPに戻る

本記事では最近話題の「2038年問題」について解説します。2038年問題は狭義のサイバーセキュリティと関連するものではありませんが、そのまま放置してしまうとサイバーインシデントを引き起こす可能性がある問題となります。対応に準備に時間を要する問題であることから、読者の皆さまに早い段階から関心を持っていただければと考えています。

2000年問題を振り返る

初期のプログラミング言語（FORTRANやCOBOL注 1) など）はデータ型に日付型がなかったため、文字列を割り当てて日付として処理をしていました。

この時、日付を文字列で処理する際、1960年代～80年代の人類は自分が作ったプログラムがその後長く使われるなどと思わず、「とりあえずYY-MM-DDで表示すればデータ量削減にもなるし、いいだろう」と考え、慣例として西暦年を下２桁で処理していました。

図1：2000年問題の原因となった表示方法

何しろ今とは異なりCPUもメモリも、貧弱でも超高価な時代です。資源の節約は必要な限り実行しなければならない課題だったといえます。しかし、1990年代に入ったところで人類はふと気づきます。「これはもしや、西暦年の下２桁だけだと2000年になった時、処理上1900年に戻ってしまうのでは？」と。

図2：2000年問題

そうして、1990年代半ばからプログラムの書き換えが行われ、それまで下２桁だった西暦年を4桁に変更し、万が一の時のために1999年12月31日から2000年1月2日までの間、一部のIT業界の人たちが正月返上で出勤して不測の事態に備えたのが2000年問題です。

2000年問題では実際、2000年1月1日当日、特に何かが起こることはありませんでした。その背景は以下の通りです。

2000年問題が2000年1月1日に何も問題とならなかった背景

COBOLやFORTRANなどのレガシー言語で古くに書かれたアプリケーションやマイコンなど対象が限定されていたこと
（※C言語などの比較的新しい言語は日付型をデータ型に持っていたため関係がなかった。）
発生日が明確だったこと
対策が西暦年の2桁を4桁表示に変更するという方法に集約されていたこと
数年間にわたって事前の対策がとられていたこと

限定的な対象に対し、事前に入念な準備を行ったことが功を奏し、インシデントが発生しなかったことが2000年問題の結果です。

計算機とデータ型：2038年問題の技術的背景

さて2024年現在、コンピューター・タブレット端末・スマートフォンなど、見た目などから計算機であることがわかりづらいようになっていますが、やはりコンピューターは計算機です。実際アプリケーションを動かすにしてもプログラムがされていて、プログラムの実行には必ず計算が伴います。そして、プログラム上でデータを処理するためにはデータの種類を定めるデータ型というものがあります。

データ型の例

データ型	例
文字列（str）	今ご覧になっているいわゆる文字列のこと
整数型（int）	1, 2, 50, 1065, -5などの整数（負の数も含む）
浮動小数点型（float）	3.14, -0.001, 356.25などの小数点を含む数（負の数も含む）
ブーリアン型（bool）	真（True）か偽（False）のいずれかで表わされる
日付型（date）	世界標準時（UTC）を基準として、1970年1月1日からの経過秒数を表すタイムスタンプデータ。整数型データで表わされる

2000年問題のときはFORTRANやCOBOLに日付型が存在せず、文字型で処理していたこと、また限られた資源を節約するために下2桁で年を表していたことが原因でした。一方、2038年問題は日付型のタイムスタンプデータを格納する整数型のデータ長（ビット幅）の実装が原因となるものです。

SQAT.jpでは以下の記事で2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介しています。こちらもあわせてご覧ください。
「【続】プログラミング言語の脆弱性対策を考える：2024」

2038年問題の技術的課題

符号付32ビット整数型から符号付64ビット整数型への移行の壁

前述したデータ型の例の表にもあるように日付型は絶対的な日付を表すものではなく、1970年1月1日午前0時0分を基準日時（エポックタイム）としてそこからの経過秒数をタイムスタンプデータとしてあらわすものです。C言語ではtime_tと呼ばれるこのデータでは、タイムスタンプデータを格納するのは符号付32bitの整数型となっています。符号付整数型は最初の1bitを正負符号のために使用します。符号の1ビットがあるため、実際に日付データ用に利用できるのは正負を表す最初の１ビットを除く31ビットで、利用できるビット長は（2³¹-1）=2,147,483,647秒となります。よって基準日時からおよそ68年を上限として演算・表示ができるものとなります。

図3：符号付32bitであらわした2038年1月19日3時14分7秒

図3は1970年1月1日午前0時0分から2,147,483,647秒が経過した、2038年1月19日3時14分7秒（※うるう秒は考慮しておりません）の符号付32bit整数型でのtime_tの状態です。一番左側の符号0は正の値を表しており、1970年1月1日午前０時０分から2,147,483,647秒、正の方向に経過したことを示します。

さて、二進法の常で右側の31bitがすべて1になった場合、通常一番左側の1ビット目が1になります（二進法の繰り上がり）。

図4：符号付32bitのままで2038年1月19日3時14分8秒になった場合

1970年1月1日午前0時0分から2,147,483,648秒経過すると図4のようになります。符号付の場合、一番左側の符号1は負の値を表すため、1970年1月1日午前0時0分から2,147,483,647秒、負の方向に遡った1901年12月13日20時45分52秒を示します。つまり放置しておくと日付データが大きく誤ることとなります。この問題が最も深刻になるのは符号付32bitのtime_tを何らかの形で参照し、それを正しいものという前提で処理しているプログラムが、2038年1月19日の時点（または2038年1月19日以降の日付を参照する時点）で未改修のまま残ってしまうことで影響を及ぼしてしまうことなのです。

ウェビナー開催のお知らせ

2024年12月18日（水）14:00～15:00
「脆弱性診断の新提案！スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー」

最新情報はこちら

2038年問題を回避する3つの対応策

対策として考えられる方法はいくつかありますが、根本的な対策は以下の3つになります。

time_tを符号付64bit整数型に変更する
time_tを符号なし32bit整数型に変更する
time_tの基準日時を1970年1月1日午前0時0分から別の日時に移動する

主要OS・アプリケーションの2038年問題対応状況

2038年問題の影響が一番大きく出ると当初予想されていたのが各種OSです。以下に各OSの対応状況を記載します。

各OSの対応状況

OS
Linux	64bitアーキテクチャ向けには当初より64bitのtime_tを提供。 32bitアーキテクチャについてはLinux Kernel 5.6で64bit化対応済み。5.4/5.5についてもバックポートで対応済み。*4
FreeBSD	原則として64bit対応済みだが、i386アーキテクチャの32bitアーキテクチャのみ非対応。I386アーキテクチャについては符号なしの32bit整数型 time_tを提供*2
Windows	64bitで1601年1月1日0時からの100n sec単位の差分計算をしていることから2038年問題は対象外といわれている*3
macOS	macOS10.0(Cheetah)で基準時を2001年1月1日0時に変更しており、2038年問題は対象外。また、32bitアプリケーションはmacOS 10.15(Catalina)以降では使用できない*4

表にもある通り、最新のOSであればほぼ問題なく2038年問題をクリアできることがわかります。問題はOSの機能を補完する各種ドライバやライブラリ群、また、そのうえで動くアプリケーションでしょう。それぞれ確認は必要となりますが、代表的なものの対応状況は以下の通りです。

ライブラリ/アプリケーション名	対応状況
GNU C Library (glibc)	バージョン2.34でx86アーキテクチャ上での64bit整数型time-tに対応。ただしx86アーキテクチャ上のglibcのtime_t自体は32bitのままで、_TIME＿BITSプリプロセッサマクロが64に設定されていて、かつLFSが有効な場合にのみ利用可能などの制限あり*5
NFS	NFSv4（RFC7530）秒単位のデータは符号付64bitであることが定義されている*6（※2.2.1 nfstime4の項を参照）
XFS	Linux 5.10でオプションとしてナノ秒単位を64bitで計算・表示する「big timestamps」を追加し、2486年まで対応できるように修正。ただしデフォルトで追加が反映されるものではなく有効に設定する必要がある*7
MySQL	8.0.28でFROM_UNIXTIME(), UNIX_TIMESTAMP(), CONVERT_TZ() の64bit対応。ただしOS側が64bit対応である必要あり（いずれの関数もOSの日付型データを参照するため）*8
MariaDB	11.5.1でタイムスタンプを2106年02月07日6時28分15秒まで拡張*9
Visual C++	32bitであえて指定されていない限りは64bitがデフォルト値*10

上記はごく一部の対応状況ですが、仮に対応していても制限事項がつくものが存在する点に注意が必要です。ここまで記載した内容で何となくお気づきの方もいらっしゃるかもしれませんが、2038年問題は発生する可能性がある箇所が2020年問題に対して格段に多いため、時間がかかることが予想されます。

2000年問題と2038年問題の違い

対象がOS/ライブラリからアプリケーション、機器類まで非常に幅が広い
2000年当時に比べて格段にデジタル化が進んでいる
対策方法が一様ではないものや、現在動いているシステムに対して即時変更をかけられないものがある

企業が取るべき2038年問題対策：自社システムの診断方法

自社のプログラムの調査は?

さて、「PCやサーバなんかを買ってきたものの、自社で作ったものはどうすればいいの？」というケースもあるでしょう。自社で作ったものは…そうです。自分たちで調べるしかないのです。実際に調査をして対応をした事例がまとめられた論文が公開されています。

組込み機器開発における2038年問題への対応事例

https://www.ipsj.or.jp/dp/contents/publication/39/S1003-1809.html

この事例では製品のライフサイクルがもともと20年前後を想定していることから、まずは2038年を最低限クリアすることを要件として調査を開始しています。このケースは組み込み機器になりますが、その単体の機器でもOS部分を含む総行数330万行のコードから符号付32bit整数型のtime_tを明示的に使用する箇所およそ3500か所が発見されています。

この事例でとられたステップを簡単にまとめます。

この事例では3500か所に対して5.8人月で実行された修正作業もさることながら、そのレベルの工数で抑制するために事前の洗い出しや対策案の立案、修正作業の手順策定といったところの重要さが感じられます。特に対策案を選定するにあたって要件が明確だったことが対策案の選定を容易にしたことがわかることから、作業開始前（せめて対策案の選定前）に要件を明確にしておくことの重要さを実感させられます。

さて、2038年問題に該当するコードを検出するためのツールは日本の研究者も含め、いくつかのGitHubレポジトリからリリースされています。最近では立命館大学のサイバーセキュリティ研究室によるY2k38チェッカーがリリースされています。

Y2k38チェッカーチェッカー作者によるプレゼン資料

こういったチェッカーは自社開発のプログラム資産のざっとしたチェックに使えるでしょう。また、チェッカー以前の問題として、まずは自社のプログラム資産が2038年問題の影響を受けないか、そろそろ確認を行い、準備を始める期間に入ってきたといえるかもしれません。

組み込み機器とは？：2038年問題の最大の影響

実はここまでにあまり触れていない、最大の2038年問題があります。それは、先ほどの論文の事例にもある組み込み機器の問題です。

組み込み機器といわれてもピンとこない方もいらっしゃるかもしれません。身近な例でいうと家電製品を制御するために組み込まれているコンピューターになります。一番パソコンに近いものであれば最近のハードディスク内蔵か外付け対応のテレビが挙げられます。このほかにも例えば電車に乗るときの自動改札機、切符販売機、水道や電気ガスなどのメーター類や街中で見かけるデジタルサイネージなども組み込み機器です。ほかにも工場のセンサー類やオートメーション用の機器類、配電設備や浄水・配水設備などのインフラ設備、病院の検査機器などにも組み込み機器が用いられています。

先ほどの事例のようにライフサイクルが決まっていて、そのライフサイクルの間のみ使用するというのが利用者（消費者）側に正しく認識されていれば問題ないのですが、実際のところ、組み込み機器こそライフサイクルを超えて、転売などをされて使い続けられるケースが多く、販売業者も製造業者もすべての出荷品の現状をトレースできないケースがあるといわれています。特に償却期間が5年を超えるような固定資産については入れ替えの検討なども含めて対応する必要が出てくることから、そろそろ取りまとめを始めなければならないでしょう。また、個人向けのIoT機器や家電のように、長期間の利用は想定されていない（売り切りに近い）製品については直前になって買い替えが必要といったアナウンスが出てくる可能性もあるでしょう。

サイバーインシデント緊急対応

まとめ

2038年問題は日付データが誤ることで社会的に大きな影響を与える可能性があります。本記事公開日（2024年12月）時点ではまだまだ先の問題と思っている方が多いと思いますが、そろそろロードマップを書き始めないと対策に取る時間が足りなくなる可能性があります。これを念頭に置き、早めの対策方法を考えておく必要があるでしょう。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

注：
1)FORTRAN
・数学分析用を目的としたプログラミング言語
・データ型は整数、実数、複素数、文字、論理の５種類
　COBOL
・1950年代終わりに開発されたプログラミング言語
・データ型は文字、数字、数字編集の３種類

2024年10月15日2025年8月12日

APIとは何か（2）～APIの脅威とリスク～

Security NEWS TOPに戻る
バックナンバー TOPに戻る

APIセキュリティは、現代のビジネスにおいて不可欠な課題です。シリーズ第2回の今回は、APIを悪用した攻撃手法や、OWASP（Open Web Application Security Project）よりリリースされている「OWASP API Security Top 10」で取り上げられるリスクの詳細を解説します。インジェクション攻撃やDDoS攻撃、APIキーの悪用、アクセス制御に関する脆弱性など、主要な脅威を紹介しながら、APIが悪用された場合の影響について解説します。

前回記事（シリーズ第1回）「APIとは何か～基本概念とセキュリティの重要性～」はこちら。

APIとは～前回からの振り返り

日頃からインターネットなどのネットワークを使用することが多い今日、現代における多くの企業はAPIに大きく依存しており、今やAPIは不可欠なものとなっています。Akamai社のレポート「The API Security Disconnect」によると、調査対象となった企業の約8割以上が2023年に行った調査において、「過去12か月以内にAPIセキュリティをより重視した」と回答しています。しかし、2022年～2024年で調査した回答者のうち、半数以上が、APIのセキュリティインシデントの影響により顧客の信頼を失い、さらにそこからほぼ半数は生産性の低下や従業員の信頼の低下にもつながったといいます。

また、SNS事業者が提供するAndroid版アプリに存在した脆弱性が悪用された結果、膨大な量のアカウント情報が漏洩した事例*11も報告されています。これは攻撃者が大量の偽アカウントを使用し、様々な場所から大量のリクエストを送信し、個人情報（ユーザ名・電話番号）を照合するというものでした。

APIが悪用されるとどうなるか

APIが悪用された場合、多岐にわたる深刻な影響が生じます。特に、認証や認可の不備は深刻なセキュリティホールとなり得ます。攻撃者はこれらの脆弱性を悪用して不正アクセスを行い、機密データや個人情報を盗み出す恐れがあります。また、認可が適切に設定されていないと、本来は外部からアクセスできないはずのデータにまで侵入され、第三者からデータの改ざんや不正操作が可能となってしまいます。さらに、APIを標的にしたDDoS攻撃によりサービスがダウンし、正規ユーザが利用できなくなることで、企業の信用失墜や業務の中断といったダメージを引き起こします。これらの影響は、経済的損失だけでなく、法的問題やブランドイメージの毀損など、長期的な悪影響をもたらすため、APIのセキュリティ強化が不可欠です。

APIを悪用した攻撃の事例はいくつか報告されていますが、いずれの攻撃も、「OWASP API Security Top 10」で挙げられている問題と関連性があります。

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASPが、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したものです。

https://owasp.org/API-Security/editions/2023/en/0x11-t10/ より当社作成

「OWASP API Security Top 10」上位のリスク

特に上位5つの項目については、以下のような重大なリスクにつながるため、リリース前に十分な対策が施されていることを確認すべきです。

不正アクセス
なりすまし
情報漏洩
サービス運用妨害（DoS）

主なセキュリティ脅威

インジェクション攻撃

インジェクション攻撃は、悪意のあるコードをAPIに挿入し、不正な操作を行う攻撃です。APIの入力データを検証せずに処理している場合、攻撃者にデータベースへのアクセスを許すリスクが生じます。特にSQLインジェクションやコマンドインジェクション攻撃が多く、攻撃を受けてしまった場合、データベースの情報漏洩やシステムの制御不備などの被害があります。

認証およびセッション管理の不備の脆弱性を悪用

APIの認証とセッション管理の不備を悪用することで、攻撃者は不正アクセスやなりすましを行います。パスワード強度が不十分な場合やトークンの管理が適切に行われていない場合、セッションハイジャックや不正に重要な情報を閲覧されることによってデータの漏洩が発生するリスクがあります。適切な認証管理およびセッション管理を行うことが重要です。

DDoS攻撃

DDoS攻撃は、複数のPCからアクセスされることによる膨大な量のリクエストをAPIに一斉に送り込むことで、システムのリソースを枯渇させ、サービスの提供を妨害する攻撃です。APIの特性上、処理を高速に行うために外部からのリクエストを許容する必要がありますが、その柔軟性が悪用されます。攻撃者はボットネットを利用し、大量のトラフィックを発生させてサーバのリソースを消費させます。これにより、顧客はサービスが利用できず、自組織においても業務に多大な影響を及ぼします。APIを保護するためには、トラフィックの監視やレート制限、WAF（Webアプリケーションファイアウォール）などのセキュリティ対策が重要です。

APIキーの悪用

APIキーは、APIへのアクセスを制御するために利用されますが、攻撃者に奪われると不正利用のリスクが生じます。盗まれたAPIキーは無制限のアクセスやサービスの悪用に使われる恐れがあります。安全な管理や無制限にアクセスができないように適切なアクセス制御を実施すること等が重要です。

アクセス制御の不備による影響

APIのアクセス制御の不備の脆弱性を悪用することで、攻撃者は許可されていないデータや機能にアクセスできます。適切な権限設定がされていない場合、データの漏洩や不正な操作の実行のリスクがあります。権限の設定など適切なアクセス制御が求められます。

思わぬデータの公開や改ざん

APIの設計や実装の不備により、データが意図せず公開・改ざんされるリスクがあります。適切な認証・認可がないと、攻撃者が内部の機密情報にアクセスすることが可能になります。例えば、本来ならシステム管理者のみがアクセスできる設定画面または顧客情報やシステムに関する情報などの重要情報が格納されている場所に攻撃者がアクセスできてしまった場合、システムの設定を変更されたり重要情報が奪取されたりする恐れがあります。また、過剰に情報を提供するAPIレスポンスや暗号化されていないデータ転送も、情報漏洩や改ざんの危険性を高めます。データ保護には、適切なアクセス制御と暗号化の実装が不可欠です。

アカウント乗っ取り

不正アクセスによってユーザアカウントが乗っ取られ、APIを悪用される可能性があります。一度アカウントが乗っ取られると、攻撃者は個人情報の閲覧や不正操作、さらには他のシステムへの攻撃拡大を図る可能性があります。多要素認証（MFA）の導入やAPIキーの適切な管理、ログイン試行の監視など、セキュリティ対策の強化が必要です。

まとめ

現代の企業にとってAPIによるアプリケーション連携は不可欠ですが、その悪用によるセキュリティリスクも増加しています。APIを悪用した攻撃の事例は、「OWASP API Security Top 10」に関連しています。主なセキュリティ脅威には、インジェクション攻撃、認証やセッション管理の不備、DDoS攻撃、APIキーの悪用、アクセス制御の脆弱性、不適切なデータ公開や改ざん、アカウント乗っ取りなどがあります。これらは重大なリスクを孕んでいるため不正アクセス、なりすまし、機密データの盗難を含む情報漏洩、データ改ざん、サービスのダウンによるサービス低下や業務への影響、ひいては企業の信用失墜といった深刻な結果を招きます。こうした被害を防ぐため、APIの設計段階から適切なセキュリティ対策を行い、監視やアクセス制御の強化が不可欠です。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2024年10月10日2025年9月3日

あなたの情報は大丈夫？
人気コーヒーショップのオンラインストアで約9万件の個人情報流出！事件から学ぶ情報セキュリティの重要性

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2024年5月、大手コーヒーショップの公式オンラインストアで大規模な個人情報漏洩事件が発生しました。この事件により、約9万2685件の個人情報と5万2958件のクレジットカード情報が漏洩した可能性が明らかになりました。本記事では、事件の内容と顧客への影響、そして企業がとるべきセキュリティ対策についてご紹介します。

事件の概要

2024年5月、大手コーヒーショップの公式オンラインストアで大規模な個人情報漏洩事件が発生しました。この事件により、約9万2685件の個人情報と5万2958件のクレジットカード情報が漏洩した可能性が明らかになりました。

事件の経緯

2024年5月20日：警視庁からの連絡により事態を認識、オンラインストアでのクレジットカード決済を停止
5月23日：オンラインストアを一時閉鎖
5月30日：不正アクセスによるシステム侵害を公表

この事件は、2020年10月1日から2024年5月23日までの期間に会員登録したユーザーに影響を及ぼしました。特に、2021年7月20日から2024年5月20日までの間にクレジットカード決済を利用した顧客のカード情報が漏洩の対象となっています。重要なのは、この漏洩が公式オンラインストアに限定されており、楽天市場や公式アプリでの購入には影響がないことです。

漏洩した情報の詳細

今回の事件で漏洩した可能性のある情報は、以下の通りです。

個人情報

氏名
住所
電話番号
性別
生年月日
メールアドレス
ログインID
ログインパスワード
配送先情報

クレジットカード情報

クレジットカード番号
カード名義人名
有効期限
セキュリティコード（CVV/CVC）

特に注目すべきは、クレジットカードのセキュリティコードが漏洩している点です。セキュリティコードは通常、オンライン決済の際に使用される3桁または4桁の数字で、カード裏面に記載されています。この情報が漏洩すると、不正利用のリスクが大幅に高まります。一般的に、PCI DSS（Payment Card Industry Data Security Standard）という国際的なセキュリティ基準では、セキュリティコードを保存することは禁止されています。そのため、公式オンラインストアがこの情報を保存していた事実自体が、セキュリティ管理の甘さを示しているといえるでしょう。

影響を受けた顧客数

この事件で影響を受けた顧客数は以下の通りです。

個人情報漏洩

約9万2685人対象期間：2020年10月1日～2024年5月23日に会員登録した顧客

クレジットカード情報漏洩

約5万2958人対象期間：2021年7月20日～2024年5月20日にクレジットカード決済を利用した顧客

この数字は、公式オンラインストアの利用者の大部分を占めると考えられます。特に、クレジットカード情報の漏洩は深刻な問題で、不正利用による金銭的被害のリスクが高まっています。

漏洩の原因と手口

今回の情報漏洩の主な原因は、公式オンラインストアのシステムに対する不正アクセスです。攻撃者はシステムの脆弱性を突き、特にペイメントアプリケーションを改ざんすることで情報を盗み取りました。使用された手口は「Webスキミング」と呼ばれるもので、以下のような手順で実行されます。

攻撃者がウェブサイトのコードに不正なスクリプトを埋め込む
ユーザーがフォームに入力した情報（クレジットカード情報など）が攻撃者のサーバーに送信される
正規の決済処理と並行して、情報が盗まれる

この手法の危険性は、ユーザー側では異常を検知しにくい点にあります。正規のウェブサイトを利用しているように見えるため、被害に気付くのが遅れる可能性が高くなります。

Webスキミング攻撃は近年増加傾向にあり、2018年から2019年にかけて大手通販サイトBritish Airwaysが同様の攻撃を受け、約38万人の顧客情報が漏洩する事件が発生しています。このような攻撃を防ぐためには、以下のようなセキュリティ対策を実施することが必要になります。

定期的なセキュリティ監査の実施
ウェブアプリケーションファイアウォール（WAF）の導入
コンテンツセキュリティポリシー（CSP）の適切な設定
従業員に対するセキュリティ教育の徹底

今回の事件のケースでは、これらの対策が十分でなかった可能性が高いといえるでしょう。

対応と今後の対策

事態の発覚後、企業は迅速な対応をとりました。

オンラインストアの一時閉鎖
クレジットカード決済の停止
影響を受けた顧客への個別連絡
クレジットカード会社との連携による不正利用の監視
第三者調査機関によるフォレンジック調査の実施

また今後の対策として、以下の取り組みを行う方針を示しています。

システムの脆弱性の完全修正
定期的なセキュリティ監査の実施
リアルタイム監視システムの導入
従業員に対するセキュリティ教育の強化
外部専門家によるセキュリティ診断の定期実施

特に重要なのは、PCI DSSへの準拠です。これにより、クレジットカード情報の取り扱いに関する国際的な基準を満たすことができます。また、今回の事件について、企業は顧客とのコミュニケーションを重視し、説明動画の公開や定期的な情報更新を行っています。この透明性の高い対応は、信頼回復に向けた重要なステップといえるでしょう。

SQAT.jpではPCI DSS準拠について、以下の記事で紹介しています。ぜひあわせてご覧ください。
「PCI DSSとは ―12の要件一覧とPCI DSS準拠―」

顧客がとるべき対策

公式オンラインストアを利用した顧客は、以下の対策をとることが推奨されます。

クレジットカードの利用明細を定期的に確認し、不審な取引がないか注意する
不審な取引を発見した場合は、直ちにクレジットカード会社に連絡する
公式オンラインストアで使用したパスワードを他のサービスでも使用している場合は、速やかに変更する
不審なメールや電話に注意し、個人情報の追加提供を求められても応じない
クレジットカード会社が提供する不正利用補償サービスの内容を確認し、必要に応じて利用する

また今後、オンラインショッピングを利用する上では以下の点に注意することが重要です。

信頼できるサイトでのみ買い物をする
クレジットカード情報を入力する際は、URLが「https」で始まっていることを確認する（=暗号化通信の導入）
公共のWi-Fiでのオンラインショッピングは避ける
異なるサービスごとに別々のパスワードを使用する
二段階認証が利用可能な場合は積極的に活用する

情報セキュリティの重要性

今回の事例は、企業における情報セキュリティの重要性を改めて浮き彫りにしました。今後企業は以下のような点を考慮し、常にセキュリティ対策を見直し、強化していく必要があるでしょう。

継続的なセキュリティ対策の実施

一度だけの対策では不十分で、常に最新の脅威に対応できる体制が必要です。

従業員教育の徹底

技術的対策だけでなく、人的要因によるセキュリティリスクも軽減する必要があります。

インシデント対応計画の策定

事件発生時に迅速かつ適切に対応できるよう、事前に計画を立てておくことが重要です。
外部専門家の活用自社だけでなく、専門知識を持つ外部の目を通してセキュリティを評価することが有効です。

法令遵守の徹底

個人情報保護法やPCI DSSなど、関連する法令や基準を厳守する必要があります。

まとめ

今回の大手コーヒーショップの公式オンラインストアにおける個人情報漏洩事件は、現代のデジタル社会が直面するセキュリティリスクを如実に示しています。約9万人以上の顧客情報が漏洩し、そのうち5万人以上のクレジットカード情報も危険にさらされました。事件の主な原因は、Webスキミングと呼ばれる攻撃手法によるものでした。企業はシステムの脆弱性を突かれ、ペイメントアプリケーションが改ざんされる結果となりました。事態発覚後、企業は迅速な対応を取り、オンラインストアの一時閉鎖やクレジットカード決済の停止、影響を受けた顧客への個別連絡などを行いました。今後は、システムの脆弱性修正や定期的なセキュリティ監査など、再発防止に向けた取り組みを強化する方針です。顧客側も、クレジットカードの利用明細の確認や不審な取引への警戒など、自己防衛策を講じる必要があります。また、オンラインショッピング全般において、セキュリティ意識を高めることが重要です。この事件は、企業における情報セキュリティの重要性を改めて認識させるものとなりました。継続的なセキュリティ対策の実施、従業員教育の徹底、インシデント対応計画の策定など、包括的なアプローチが求められています。デジタル化が進む現代社会において、個人情報の保護は企業の重要な責務です。今回の事例を教訓に、企業はセキュリティ対策を強化し、顧客の信頼を守り続けることが求められています。同時に、利用者側もセキュリティ意識を高め、自己防衛策を講じることが大切です。官民一体となったサイバーセキュリティの向上が、安全なデジタル社会の実現につながります。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

BBSecでは

サイバーインシデント緊急対応

突然の大規模攻撃や情報漏えいの懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

SQAT^® 脆弱性診断サービス

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

2024年9月27日2025年5月12日

【続】プログラミング言語の脆弱性対策を考える：2024

Security NEWS TOPに戻る
バックナンバー TOPに戻る

本記事は2020年9月公開の記事「プログラミング言語の脆弱性対策を考える」の続編となります。前回の記事をまだご覧になっていない方はぜひ、この機会にご一読ください。

いま「C言語の脆弱性対策について簡単に教えて」と生成AIに尋ねてみると、弊社SQAT.jpの記事が引用記事として出てきます。前回の記事を公開してからそろそろ５年ぐらいの月日がたつということで、今回は2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介します。

2020年から2024年で変わったこと

生成AIの汎用化

2024年の夏、最初の会社の同期20人で5年ぶりに集まりました。その中でコードを業務で書いているメンバーが同じテーブルに集まったとき、最初に出た話題は「生成AIって何使っている？」でした。所属する会社も違い、使っている言語はバラバラ、コードを書く目的や環境、書く頻度もまちまち、利用する生成AIもバラバラなのですが、全員が生成AIを使っていることに少々驚きました。この友人が全員口をそろえて生成AIについて評価していた点は、コードを作るときに最初にかかる時間と手間が圧倒的に削減されるという点です。

これまでは「こういうことを処理するコードを作ろう」と思うと、わかるところは先に大まかに書いたうえで、わからないところや怪しい部分はプログラミング言語のリファレンスをひっくり返し、Webで検索し、情報を集めたうえでコードスニペットを起こし、実際のコードとして動かし…という順で作業していました。一方、生成AIを使う場合はこういったことをやろうと思った時点で足りない部分を生成AIに質問すればスニペットが返ってくる（場合によってはコードブロックが返ってくる）ので、コードづくりの前半部分の悪戦苦闘がかなり軽減されます。

ところが、短所もいくつかあります。まず生成AIサービスが免責事項として常に掲げるように、必ずしも正しい答えが返ってくるわけではない点には理解が必要とされるところです。
引用元をよくみると、古いバージョンの言語に基づいたQ&Aサイトの回答を参照していることもよくありますし、プロンプトに対して素直に答えるという性質上、プロンプトに入れていない前段処理に対して不整合が発生する内容のスニペットが回答される、といったことはわりと日常茶飯事です。

学習データやプロンプトの入れ方次第では返答されるコードスニペット自体にエラーや脆弱性が含まれる場合もあります。プロンプトに関係のない前後の処理との不整合でエラーが発生したり、他のコードブロックとの兼ね合いでエラーが発生したり、そのエラーが結局脆弱性につながるものだったりという可能性は十分にあります。

また、一般的な商用サービスの生成AIでは入力が学習データに使用されます。つまり自身が入力したデータが流用されるという前提でサービスを利用することになります。このため、自社の知的所有権への配慮や、個人情報や機微情報、場合によっては非公開情報全般への配慮が必要となる点にも注意が必要です。エンタープライズサービスとしてこういったことを回避するサービスもありますが、それ相応の費用が必要となります。

ただ、自前で大規模言語モデル（LLM：Large language Models）をつくるよりも人件費や設備費用などが圧倒的に安価で手軽であるという点では規模の経済性を実感するところはあります。そういった観点から、将来、どの企業でも自社でAIを全く使わないという選択肢はあまりないかと思います。プログラミングに限らずですが、AIとほどよく付き合って効率的に仕事を進めつつ、エラーや脆弱性をきちんと見逃さない仕組みをもって問題を回避していく、
そういう仕事法になっていくかもしれません。

ノーコードとローコード

以前からどちらも存在はしますが、2020年代に入ってからノーコードやローコードといった選択肢が増えてきています。

ノーコード
プログラミングの知識がなくてもアプリケーションを開発できる手法です。専門的なコードを書くことなく、ドラッグ＆ドロップなどのビジュアル操作で簡単にアプリケーション開発ができます。ITの専門スキルがない人でもアイディアをデジタル化できる点が特徴です。小規模なプロジェクトの開発に適しています。
ローコード
最小限のプログラミングでアプリケーションを開発する手法です。基本はビジュアル操作ですが、必要に応じて一部コードを書きます。柔軟性とスピードのバランスが特徴です。

最近だとAWSがローコード構築サービスをリリースした*2のが一例となるでしょう。ノーコードやローコードを使用するメリットとしては、各業務の定義やフロー、プロセスが明確であれば定型業務やバックヤード業務の一部を合理化できることです。効率化することで時間短縮ができ、別のより生産性の高い仕事に人を割り振れるといった副次的な効果も期待できます。ただ、業務の内容が不明確な場合や、業務が日々恣意しい的な運用をされている場合には大きなメリットを得ることは難しいかもしれません。

ここで脆弱性の話です。実際ノーコードといっても実は補助的にパラメータの入力が必要な場合があります。また、外部とのAPI連携をノーコードの画面から実行するといった構成のノーコード機能を持っているSaaS(Software as a Service)もあります。そして誤ったパラメータの入力で入出力の脆弱性を発生させる可能性がある、APIとのやりとりの詳細はユーザでは見えない（SaaSのサポート担当者は見えるケースが多いようです）ため、誤った接続先に接続していた場合や連携しているAPIになんらかの脆弱性があった場合に切り分けが煩雑になるといったところは懸念材料として頭の片隅に置いたほうが良いでしょう。

ノーコードもローコードも非常に便利です。そのノーコードフロー自体の仕組みやパラメータの動きや連携先のAPIの信頼性などを理解したうえで使えば、劇的に効率化が図れるため、API同様にうまく付き合っていくということが重要になるのではないでしょうか。

プログラミング言語

専門家たちがどのプログラミング言語を使っているかというデータが、毎年Stack Overflowから発表されます。2020年と2024年でどの程度変わったか、比較をしてみましょう。


言語	2024年	2020年
JavaScript	64.60%	69.70%
HTML/CSS	54.10%	62.40%
Python	53%	41.60%
SQL	47%	56.90%
TypeScript	43.40%	28.30%
Bash/Shell	34.20%	34.80%
Java	30.00%	38.40%
C#	28.80%	32.30%
C++	20%	20.50%
C	18.70%	18.20%
PHP	16.90%	25.80%
PowerShell	14.40%	注 1)
Go	14.00%	9.40%
Rust	11.70%	4.80%
Kotlin	9.90%	8.00%
Dart	6.00%	3.70%
Ruby	5.80%	7.50%
Lua	5.30%	ランク外
Swift	4.90%	6.10%
Visual Basic	4.10%	ランク外

出典：Stack Overflow Developer Survey2020年版/2024年版より弊社作成
2020年版：https://survey.stackoverflow.co/2020#technology-programming-scripting-and-markup-languages-professional-developers
2024年版：https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof

ここからは2020年と2024年の脆弱性診断結果の比較で目についた点を深堀りしてみたいと思います。

プログラミング言語と適材適所

前述した「専門家たちはどのプログラミング言語を使っているか」というデータの表からもわかるとおり、このWeb大全盛の時代に「PHPを使う」と回答したエンジニアの比率は下がっています。また、BBSecのシステム脆弱性診断結果からもPHPの脆弱性報告件数が減っていることがわかります。米国の脆弱性情報データベースNVDによるとPHPの脆弱性自体の数が減っている*2（2019年が34件に対して2023年は6件）ということも関連があるかと思いますが、診断結果のエビデンスで見かける機会も減っています。

脆弱性の存在するバージョンの使用の検出内訳

（上図：2020年上半期、下図：2024年上半期）

当社が発行するセキュリティレポートでは、半期（6か月）毎にBBsec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。
最新号のダウンロードはこちら。

GitHubでのプルリクエスト（機能追加や改修など、作業内容をレビュー・マージ担当者やその他関係者に通知する機能）の数も2013年をピークにここ数年は5％台半ばでの微増微減を繰り返している状態になっています*3。けれど、現在稼働しているWebサイトのうち75.8％がPHPを使用している*4といわれていることも事実です。また、CMSの代名詞ともいえるWordPressはPHPで開発されているのですが、WordPress 注 2)が全Webサイトの実に43.4％で使用されています*5。つまり、WebサイトのうちPHPを使っているサイトは76％ぐらいあるけれど、半分以上はWordPressとその派生のパッケージが市場シェアを支えているという構造になっています。そのため、実際に動いているサイトのほとんどがPHPであることは間違いないですが、その大半はWordPressで、それ以外のサイトは少数派というのが現状です。

PHPの強みはWeb開発に特化した、可読性が高く学習しやすい言語である点です。小中規模でセキュリティ要件があまり高くないWebサービスやCMSであればPHPで開発するのが一番便利であり、保守性も高いでしょう。一方で、大量のデータの処理・分析が必要なケース、セキュリティへの配慮からバックエンドとフロントエンドを切り離して開発・運用する必要があるケース、パフォーマンスが重視されるケース、マルチデバイス対応が必要なケースなど、PHPでは要件を満たさないケースが出てきていることも事実です。

PHPの市場をけん引しているCMSでも、「ヘッドレスCMS」と呼ばれるタイプなど、これまでとは異なるCMSへの需要が伸びているといわれています。今後は、旧来のCMSや中小規模のWebサイトはそのままPHP、マルチデバイスやパフォーマンス、バックエンドへの特殊な処理要件やセキュリティ要件などがある場合は別の言語といった形で、さらにすみわけが進んでいくのかもしれません。そういった意味でも “WebならPHP” という時代から、”適材適所でWeb開発も言語を選ぶ” 時代になってきたといえるでしょう。

2024年のC言語

C言語系統で開発というと「2024年でもまだ？」という声が上がりそうなところですが、実際C言語系統はOSまわりでいまだに健在です注 3)。また古いプログラム（コード、ドライバなど）で互換性が保証される場合はそのまま利用されているケースもあるといわれています。つまりは、C言語系統の言語が抱える根本的な問題、メモリハンドリング（メモリの使い方の変化に伴うメモリエラーを適切に処理する能力）関連の問題もいまだにそこかしこで健在しています。この問題が特に注目を集めたのが、昨今のCrowdStrike Falconのエラーを含んだパターンファイルの配布によるBSOD（Blue Screen of Death）の大量発生です。

脆弱性診断は受けたけれど～脆弱性管理入門

Security NEWS TOPに戻る
バックナンバー TOPに戻る

contents

～とある会社Aと脆弱性診断の結果を受け取った関係者とのやり取り～

脆弱性診断を受けたA社では入社3年目のセキュリティ担当・Bさんが結果に頭を抱えています。なぜなら、社内ネットワークに使っているスイッチにCVSSスコア9.8の脆弱性、リモートアクセスに使用しているVPNゲートウェイにCVSSスコア8.8、オンラインショップ用の受発注管理に利用しているデータベースにCVSSスコア7.5の脆弱性が見つかってしまったからです。リスクはどれも「高」レベルとして報告されたため、Bさんは上司に相談し、すべてに修正パッチを当てるようスイッチとVPNゲートウェイについてはインフラチームの担当者に、データベースについては開発部に連絡することにしました。

インフラチームのCさんとSlackでやり取りをしていたBさんはCさんからこんなことを伝えられます。

インフラチームCさん「修正パッチを適用するとなると、インフラチームは基本みんなリモートだから、誰かを土日のどこかで休日出勤させるか、急ぎだったら平日の夜間に勤務させて、パッチを当てることになるけど、どれぐらい急ぎなの？」

「あと、VPNとスイッチ、どっちを先に作業したほうがいいの？パッチの情報を調べてみたら、VPNのほうは一度途中のバージョンまで上げてから最新バージョンまで上げないといけないみたいで、作業時間がすごくかかりそうだから、別日で作業しないとだめかもしれないんだよね」

Bさんは答えに詰まってしまいました。リスクレベルは高だといわれているけれども、どれぐらい急ぐのかは誰も教えてくれないからです。

答えに詰まって「確認してから折り返し連絡します」と返したところ、「セキュリティ担当はいいなあ。土日とか夜間に作業しなくていいし、すぐに答えなくてもいいんだから」と嫌味までいわれてしまいました。

Bさんは脆弱性診断の結果が返ってきてから1週間後、開発部門のD部長にセキュリティ担当と開発部門の定例会議の際に報告事項としてパッチ適用の件を報告しました。するとD部長はこういいました。

開発部D部長「この件、1週間ほど報告に時間を要したようですが、脆弱性診断の結果以外に何か追加の情報はありますか？あと、この脆弱性診断の結果によるとリスクレベル高とありますが、社内の規定としてどの程度急ぐかといった判断はされましたか？」

開発部のほかの人にもこんなことをいわれてしまいます。

開発部担当者「パッチを適用する場合、ステージング環境で影響を調査したうえで必要であればコードや設定の修正などを行う必要がありますが、その時間や工数は考慮されていないですよね。通常の開発業務とどちらを優先すべきかといった判断はどうなっているんですか？」

Bさんはまたもや言葉に詰まってしまいます。セキュリティ担当は自分と上司の2人だけ、上司は別の業務との兼務でパッチの適用の優先順位付けまで考えている時間はありません。自分もEDRやファイアウォールの運用をしながら脆弱性診断の依頼や結果を受け取るだけで、とても他の部門の業務内容や環境のことまで把握しきる余裕がないのです。

ここまで、架空の会社A社と脆弱性診断の結果を受け取った関係者の反応を物語形式でお送りいたしました。現在、弊社の脆弱性診断サービスでは脆弱性単体のリスクの度合いの結果をご提供させていただくことはあっても、その脆弱性をどういった優先度で修正しなければならないかといった情報はご提供しておりません。なぜならば、パッチを適用するにあたって優先順位をつけるためにはお客様しか知りえない、以下の要素が必要になるためです。

パッチ適用の優先順位をつけるための3つの要素

脆弱性を持つアセットが置かれている環境
・インターネット上で公開された状態か、IPSやFWなどで制御されたネットワーク内か、もしくはローカル環境依存といった非常に限定的な環境かといった分類
・CVSSでいう環境スコア（CVSS-E）の攻撃区分（MAV）にあたる、実際の環境依存の要素
アセットが攻撃を受けた場合に事業継続性に与える影響
アセットが攻撃を受けた場合に社会や社内（運用保守・人材）に与える影響

冒頭のA社のケースでは以下のように整理できるでしょう。

アセットが置かれている環境

VPN：インターネット上で公開された状態
データベース：設定を間違っていなければIPSやFWなどで制御されたネットワーク配下だが、公開ネットワーク寄り
スイッチ：設置環境によって制御されたネットワーク内かローカル環境になる。

アセットが公開されている場合、攻撃者からよりアクセスしやすいことからより緊急度が高いといえるので、VPN＝データベース＞スイッチの順になると考えられるでしょう。

アセットが攻撃を受けた場合に事業継続性に与える影響

アセットが攻撃を受けた場合に自社の事業継続にどの程度影響が出るかといった要素です。
仮にランサムウェア攻撃によって影響を受けた場合、それぞれのアセットの停止でどの程度の影響が出るかを想定してください。A社の場合事業継続性への影響度順でいうと、データベース＞VPN＞スイッチの順になると考えられます。

今回の場合はデータベースが事業に直結しており、顧客情報を含むデータを持っているため、継続性への影響度が高いという想定です。アセットの利用目的や環境によってはこの順番が入れ替わることもあります。

アセットが攻撃を受けた場合に社会や社内に対して与える影響

A社がランサムウェア攻撃を受けた場合はオンラインショッピングサイトのデータベース関連で以下の影響が見込まれます。

顧客情報の漏洩
運用およびシステムの復旧にかかる費用と工数

このほかにVPNやスイッチもフォレンジック調査の対象となって業務が行えなくなる可能性が高いと考えられます。VPNに関しては利用できない期間、社員の出社が必須になるなどワークスタイルへの影響も出る可能性もあります。こういったことから、社会および社内に対して与える影響でA社の例を考えると影響度は、データベース＞VPN＝スイッチと考えられるでしょう。

SSVCとは

こうした情報があったうえで利用ができようになる優先順位付けの方法があります。それが「SSVC（Stakeholder-Specific Vulnerability Categorization）」です。SSVCは脆弱性管理プロセスに関与する利害関係者のニーズに基づいて脆弱性に優先順位を付けるための方法論とされており、経営・マネジメント層、システム開発者、システム運用者といったステークホルダーと一緒に脆弱性に対処していくための方法論といえます。SSVCは脆弱性そのものの技術的評価ではなく、脆弱性にどのように対処するかという観点での評価を行うフレームワークになります。

SSVCの3つのモデル

ソフトウェアやハードウェアの供給者、すなわちパッチを開発する人が用いる「Supplier Decision Model」
ソフトウェアやハードウェアを利用する側、つまりパッチを適用する人が用いる「Deployer Decision Model」
CSIRTやPSIRT、セキュリティ研究者やBug Bounty Programなど、脆弱性に対して何らかの調整やコミュニケーションのハブとなりうる人、コーディネーターが用いる「Coordinator Decision Model」

このうち、「Deployer Decision Model」と「Supplier Decision Model」ではプライオリティ（対応優先度）付けの結果を4つにわけています。

SSVCで得られるプライオリティ付けの結果

	Deployer Model	Supplier Model
Immediate	すべてのリソースを投入し、通常業務を止めてでもパッチの適用を直ちに行うべきである	全社的にすべてのリソースを投入して修正パッチを開発し、リリース
Out-of-cycle	定期的なメンテナンスウィンドウより前に、やむを得ない場合は残業を伴う形で緩和策または解消策を適用	緩和策または解消策を他のプロジェクトからリソースを借りてでも開発し、完成次第セキュリティパッチとして修正パッチをリリース
Scheduled	定期的なメンテナンスウィンドウで適用	通常のリソース内で定期的な修正パッチのリリースタイミングでパッチをリリース
Defer	現時点で特に行うことはない	現時点で特に行うことはない

ここではDeployer Decision ModelをもとにA社がどのようにパッチを適用すべきか検討してみましょう。

まず、Bさんは上司に相談したうえで、前述した3つの要素、「脆弱性を持つアセットが置かれている環境」、「事業継続性への影響」、「社会や社内への影響度」を定義していく必要があります。また、この定義に当たっては実際の環境や利用用途、部門内のリソースなどをよく知っているインフラチームや開発部といった当事者、つまりステークホルダーの関与（少なくとも承認）が必要となってきます。このほかに優先順位付けの結果、”Immediate”や”Out-of-Cycle”が出た場合の対応プロセスも用意しておく必要があります。Bさん１人で何かできることはそれほど多くはなく、社内のステークホルダーへの聞き取りや経営層への説明、必要なプロセスの準備と合意形成など、上司や部門全体も含めて組織的に取り組まなければならないといえます。さらに、Bさんは脆弱性自体が持つ以下の要素を調べる必要があります。

脆弱性が持つ要素

自動化の可能性

攻撃者がツール化して脆弱性を悪用するかどうかを判定するものとなります。これは攻撃者がツール化した場合、攻撃者間でツールの売買が行われるなど汎用的に悪用される可能性があるため、把握が必要な要素となります。一部の脆弱性はCISA VulnrichmentやCVSS4.0のSupplement MetricsのAutomatableの値が参照できますが、情報の参照先がないものについてはPoCの有無やPoCの内容から自動化の可否を判断する必要があります。この点はSSVC利用の難点として挙げられることもあります。

悪用の状況

実際に攻撃されていることを示すActive、PoCのみを示すPoC、悪用されていないことを表すNoneの3つに分類されます。この情報は時間の経過とともに変化する可能性が最も高く、逐次状況を確認する必要があります。情報の参照先は、KEVカタログ、CISA VulnrichmentのExploitationの値、CVSS4.0のThreat MetricsやNVDのReferenceのPoCの有無といったものが利用できます。唯一難点があるとすれば、日本国内でシェアの高い国内メーカー機器の情報がKEVカタログやCISA Vulnrichmentなどにあまり反映されない点にあります。

まとめ　～CVSSとSSVCの活用～

これまではCVSSが高い値のものだけ対処していた、という組織も多いでしょう。CVSSは脆弱性の単体評価ができ、脆弱性が広く悪用された場合の深刻度を測るための評価システムです。ただし、その脆弱性が存在するアセットがどのように利用されているか、そのアセットが業務継続性や運用保守、ひいては社会全体に対してどのような影響を与えるかといった観点が欠けていることが長らく問題視されてきたのも事実です。

脆弱性管理は手間がかかる、登場人物が多い、意見がまとまらないといったこともあるでしょうし、「自動化の可能性とかわからないし、攻撃の状況をずっと見ているほどの時間の余裕はない！」といった様々なお声があるかと思います。しかし、今この瞬間どの企業がいつサイバー攻撃を受けるのか全く見当もつかない状況の中、少しでもリスクを回避したい、どこにリスクがあるのか手がかりをはっきりしておきたいという企業の皆さまもいらっしゃるかもしれません。本記事を通じて、こういった脆弱性管理手法があることを知っていただき、活用することでリスク回避ができるようになるための役立つ情報提供となれば幸いです。

参考情報：

独立行政法人情報処理推進機構（IPA）「共通脆弱性評価システムCVSS v3概説」
https://www.ipa.go.jp/security/vuln/scap/cvssv3.html
カーネギー・メロン大学「SSVC: Stakeholder-Specific Vulnerability Categorization」
https://certcc.github.io/SSVC/

Security NEWS TOPに戻る
バックナンバー TOPに戻る

サイバーインシデント緊急対応

ウェビナー開催のお知らせ

2024年9月18日（水）13:00～14:00
【好評アンコール配信】
「ランサムウェアの脅威を知る-脅威に備えるためのランサムウェア対策-」

2024年9月25日（水）13:00～14:00
【好評アンコール配信】
「ランサムウェア対策の要～ペネトレーションテストの効果、脆弱性診断との違いを解説～」

2024年10月2日（水）13:00～14:00
【好評アンコール配信】
「サイバー攻撃に備えるために定期的な脆弱性診断の実施を！
　- ツール診断と手動診断の比較 –」

2024年10月9日（水）13:00～14:00
【好評アンコール配信】
「システム開発のセキュリティ強化の鍵とは?
　-ソースコード診断で手戻りリスクとサイバー攻撃を未然に防ぐ-」

最新情報はこちら

Youtubeチャンネルのご案内

SQATチャンネル（@sqatchannel9896）では毎月、アナリストが語る「セキュリティトピック」解説動画やウェビナー動画を更新しています。ぜひチャンネル登録をして、チェックしてみてください。

2024年8月19日2025年5月12日

長期休暇明けのサイバーセキュリティ対策
企業が実施するべき7つの重要ステップ

Security NEWS TOPに戻る
バックナンバー TOPに戻る

長期休暇明けは、企業にとってサイバーセキュリティリスクが高まる時期です。休暇中に発生した脆弱性や新たな脅威に対応するため、適切な対策を講じることが重要です。本記事では、企業が実施するべきセキュリティ対策について、7つご紹介します。

修正プログラムの適用

休暇中に公開されたOSやソフトウェアの修正プログラムを確認し、適用することが最初のステップです。システム管理者の指示に従って修正プログラムを適用することで、既知の脆弱性を修正し、セキュリティを強化できます。

定義ファイルの更新

セキュリティソフトの定義ファイルを最新の状態に更新することも重要です。電子メールの送受信やウェブサイトの閲覧を行う前に定義ファイルを更新することで、最新のウイルスやマルウェアに対する防御力を強化できます。

サーバ等のログ確認

サーバ等の機器に対する不審なアクセスが発生していないか、各種ログを確認します。不審なログが記録されていた場合は、早急に詳細な調査等の対応を行うことが必要です。ログ確認により、潜在的なセキュリティインシデントを早期に発見し、対処することができます。

不審なメールへの警戒

長期休暇明けはメールがたまっているため、不審なメールの添付ファイルやURLには特に注意が必要です。不審なメールを受信した場合は、添付ファイルを開かず、本文中のURLにもアクセスしないようにしましょう。また、システム管理者に報告し、指示に従うことが重要です。

持ち出し機器のウイルスチェック

長期休暇中に持ち出していたパソコンや外部記憶媒体のウイルススキャンを行うことも忘れずに。このステップにより、持ち出した機器がウイルスに感染していないかを確認し、組織内でのウイルス拡散を防止します。

緊急連絡体制の確認

不測の事態に備えて、緊急連絡体制や対応手順を確認しておくことも重要です。連絡フローが現在の組織体制に沿っているか、各担当者の連絡先に変更がないかなどを確認しておきましょう。

データのバックアップ

最後に、重要データのバックアップを行い、ランサムウェア攻撃に備えることが大切です。バックアップデータは安全な場所に保管し、定期的に更新することで、データの消失や改ざんに対するリスクを軽減できます。

まとめ

これらの対策を適切に実施することで、長期休暇明けのサイバーセキュリティリスクを大幅に軽減します。企業は常に最新のセキュリティ脅威に対する警戒を怠らず、従業員の意識向上と技術的対策の両面からセキュリティ体制を強化していくことが重要です。サイバー攻撃の手法は日々進化しており、一度の対策で安心することはできません。定期的なセキュリティ評価と対策の見直しを行い、常に最新の脅威に対応できる体制を整えていくことが、企業の重要な責務となっています。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

またサービスのデモンストレーション動画を公開中です。こちらも併せてご覧ください。

サイバーインシデント緊急対応

ウェビナー開催のお知らせ

2024年8月21日（水）14:00～15:00
「ランサムウェア対策の要～ペネトレーションテストの効果、脆弱性診断との違いを解説～」

2024年8月28日（水）12:50～14:00
【好評アンコール配信】「知っておきたいIPA『情報セキュリティ10大脅威 2024』～セキュリティ診断による予防的コントロール～」

2024年9月4日（水）14:00～15:00
「インシデント発生の事前準備・事後対応 -拡大するサイバー攻撃への対策方法とは- 」

2024年9月11日（水）14:00～14:30
「CVSSとSSVCで実践する次世代脆弱性管理：サイバー攻撃対策セミナー2024」

最新情報はこちら