脆弱性管理とIT資産管理
-サイバー攻撃から組織を守る取り組み-

Share

日々報告される脆弱性に対してサイバー攻撃から自組織を守るために、「脆弱性管理」と「IT資産管理」を適切に実施することが重要です。本記事では、その脆弱性管理とIT資産の目的や必要性またどのように取り組んでいくのかについて解説します。

増え続ける脆弱性

脆弱性は、攻撃者によって利用され、システム侵害の足掛かりとされる可能性がありますので、これに対処することは組織のセキュリティ強化に不可欠です。

システムやソフトウェアに存在するセキュリティ上の弱点である脆弱性は、日々新しく発見・公表されており、その数は増える一方です(下グラフ参照)。脆弱性が報告される製品は、OS、ミドルウェア、アプリケーション、プログラム言語、ライブラリなど多岐にわたり、商用かオープンソースかを問いません。

また、新たな脆弱性ばかりでなく、VPN機器のような広く利用されている製品がアップデートされないまま放置されている、という実情に目をつけられて、古い脆弱性を悪用した攻撃活動による被害が報告される、といったことも少なくありません。

脆弱性管理とその目的

情報資産を守るためには、サイバー攻撃からシステムやソフトウェアを保護する必要があります。そのために重要となるのが脆弱性管理です。脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、適切な対策を講じることで、セキュリティ上のリスクを低減するための取り組みです。

脆弱性が放置されたままであれば、それを悪用したサイバー攻撃による情報漏洩や改竄、システム停止といった被害が発生し、企業・組織の信用失墜や業務中断による損失、取引先や顧客からの損害賠償請求、個人情報保護法等による罰則などの事態を招きかねません。脆弱性管理は、これらのリスクに適切に対処するための重要な手段となります。

脆弱性管理の必要性

しかしながら、脆弱性対策の予算・人員・時間などのリソースは有限であり、やみくもにすべての脆弱性に対処する、というのは現実的ではありません。無秩序に脆弱性対策をしていては、不必要なコストがかかるばかりでなく、十分な対策を講じられない恐れがあるでしょう。

脆弱性対策は、限られたリソースで的確かつ効率的に行わなければなりません。自組織に存在する脆弱性を的確に把握し、実態に即したリスクごとに優先度をつけて対応する必要があるのです。「脆弱性管理」は、こうした適切な脆弱性対策を実現するための一連のプロセスと言えます。

脆弱性管理のライフサイクル

脆弱性管理の標準的な流れは以下の4つのプロセスになります。

脆弱性管理のライフサイクル画像

各プロセスの概要とポイント

プロセス概要ポイント・留意点
資産の把握・管理IPアドレス、OS/ソフトウェアとバージョン、稼働中のサービスとその状況などを漏れなく記録。・機器・ソフトウェア単体だけでなく、製品に含まれるOSS、プラグインなど、相互の依存関係にも注意。
・常にアップデートできていること、管理外の資産(シャドーIT)がないこと。
脆弱性情報の収集資産管理情報をもとに、自組織に関係する脆弱性情報を収集。・必要に応じて適切なタイミングで実施。
・政府機関や製品ベンダといった信頼できるソースから収集。
脆弱性のリスク評価脆弱性の危険度を確認した上で、自組織への影響を分析し、対応の難易度やコストも勘案して、対応要否・優先度を決定。・まずはCVEなどの脆弱性に関する標準的な指標で各脆弱性の危険度を確認。
・自組織に即した評価としては、①攻撃を受けやすい状況か、②攻撃された場合はどの程度影響があるか、③脆弱性解消に要するリソースはどれくらいか、といった要素をなるべく定量的に分析・評価。
解消策の実行実行計画を策定し、検証環境に適用して問題がなければ、本番環境に適用。・必要な期間の確保、環境の整備、関係者との調整、事業状況の加味などにより、安全・確実に実行できるよう計画。
・適用にあたって発生したトラブルなども含め、作業内容は必ず記録。

脆弱性管理におけるIT資産管理

脆弱性管理プロセスは、資産の把握と管理から始まりますが、ここで、IT資産管理について考えてみましょう。IT資産管理の主な目的は、ライセンス管理やデータ保護によるコンプライアンスの遵守、資産を正確に把握・追跡することによるセキュリティ事故の防止、資産の効率的な使用を管理することによるコスト削減などとなります。

IT資産管理では、組織が所有するすべてのIT資産について、以下のような項目を可視化して管理する取り組みです。

・ハードウェア : PC、サーバ、ネットワーク機器 等
・ソフトウェア : OS、ミドルウェア、アプリケーション 等
・ライセンス情報、購入・保守情報、廃棄情報
・利用者(利用部門)、利用状況

IT資産の把握は、システム担当者より資産情報を取得するというのが一般的でしょう。また、システム構築を委託している場合は委託先に資産情報を確認する必要があります。

方法としては、IT資産管理ツールによって自動化するのがよいでしょう。アプリケーションやクラウドサービスなど、様々なIT資産管理ツールがリリースされていますので、予算や機能に応じて自組織に合うものを選択してください。

脆弱性管理とIT資産管理の連携

IT資産管理を整備・強化すると、先に挙げた脆弱性管理の管理プロセスにおいて、以下のようにIT資産管理を有効に連携させることができるでしょう。

脆弱性管理とIT資産管理の連携画像

両者を連携することで、セキュリティの確保がより確実に行えるようになることがわかります。

適切な脆弱性管理のためのポイント

前段まで脆弱性管理の目的や必要性、プロセス、そしてIT資産管理との連携について確認してきましたが、ここで、適切な脆弱性管理を実現するために必要なポイントについてまとめます。

漏れなく適時に一元管理実態に即した評価と対応プロセスの標準化と見直し
脆弱性管理を統括する部門に情報が集約されていること
資産管理、脆弱性情報に漏れがないこと
資産管理、脆弱性、対応状況といった各情報が常にアップデートされていること 等
脆弱性情報とその解消策が信頼できる内容であること
自組織への影響評価と解消策の要否・優先度の決定が適正に行われること
解消策の実施が安全・確実な方法で行われること 等
脆弱性管理の各プロセスに一貫性があり、組織内で標準化されていること
各プロセスでのトラブル発生時には適宜協議できる状態であること
定期的、あるいは必要に応じて適宜手順の見直しを行うこと 等

“漏れなく”管理するには

ここからは、上記で挙げたポイントのうち、「漏れなく」に焦点を当てていきます。資産情報や脆弱性情報に漏れがあると、どんなにリスク評価や解消策の実施体制を整えていても、結局は非効率かつ不十分な対応結果になりかねません。そのため、IT資産を漏れなく管理することは、脆弱性管理のベースとなる重要なポイントと考えられます。脆弱性管理のライフサイクルでいうと、「資産の把握・管理」プロセスで漏れなく資産情報が収集できているか、「脆弱性情報の収集」プロセスでも漏れなく関連する脆弱性情報が収集できているか、といった点です。

資産の把握・管理:ソフトウェアコンポーネントの管理

見落としがちな資産として、様々な製品に組み込まれているコンポーネントがあります。

■組み込みソフトウェアに起因する脆弱性が問題となった例:

2021年12月 Javaのログ出力ライブラリApache Log4jにおける脆弱性「Log4Shell」公開された*1
悪用されるとリモートコード実行の恐れがあるとして、注意喚起された。
Apache Log4jは国内でも広く利用されているが、様々な製品に組み込まれていることから、国内大手電機メーカーのOT/IoT製品でも影響があることが確認される*2など、脆弱性の影響を受けるシステムの特定が困難だった。
2023年12月Sierra Wireless社の「AirLink」にバンドルされているALEOSや一部のオープンソースコンポーネントについて計21件の脆弱性が特定された*3
リモートコード実行、クロスサイトスクリプティング、DoS、認証バイパスなど深刻度の高い脆弱性が含まれているとのこと。
世界中の政府やインフラなど、ミッションクリティカルな産業で多く利用されているOT/IoTルータであるため、対応不備による影響が懸念される。

OT/IoT機器には、ファームウェア等のソフトウェアコンポーネントが含まれます。これらの機器の脆弱性管理には「ソフトウェア部品表(SBOM)」の活用が有効です。

SBOM (Software Bill of Materials)
特定の製品に含まれるソフトウェアコンポーネントや相互の依存関係の情報などを機械処理できるリストとして一覧化したもの。導入することで、脆弱性対応期間の短縮、ライセンス管理にかかるコストの低減や開発生産性向上などのメリットがある。
参考情報:https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

SBOMの導入にあたっては、経済産業省より「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver. 1.0」(令和5年7月28日)が発行されていますので、参考にしていただくとよいでしょう。

資産の把握・管理:シャドーITの撲滅

先ほど述べた「”漏れなく”管理する」を実現するためには、管理外の資産、すなわち「シャドーIT」がないようにすることが重要です。

組織が認識していないサーバやアプリケーションが稼働していると、その製品自体が組織のセキュリティポリシーの対象外である可能性があり、パッチ適用などのセキュリティ対応が行き届かず、サイバー攻撃の足掛かりとされる恐れが高まります。そもそもその存在を認識していないため、対策の取りようがない、というところが脅威につながります。

■シャドーITに起因する脆弱性が問題となった例:

2024年 2月著名ブランドや組織のサブドメインを乗っ取る大規模な攻撃キャンペーン「SubdoMailing」が報告*4された。
8,000以上の正規ドメインと13,000以上のサブドメインを使用して、一日あたり最大500万件のスパムメールが送信され、詐欺やマルバタイジングによる攻撃者の収益源に。
根本的な原因は、自組織で管理すべきCNAMEレコード(ドメインの別名を定義する情報)が、放棄されたドメインを指定したまま放置されていたこと。

シャドーITを発見するには、ASM(Attack Surface Management)が有効です(下イメージ)。インターネット上に意図せず公開されている資産がないか確認する手段として活用できます。

一般的なASMの特徴とイメージ

インターネットから直接アクセス可能なIT資産の調査—アタックサーフェス調査を実施するには、各種ASMツールもリリースされていますし、専門家によるサービスも提供されているので、自組織に合った方法でシャドーITの存在有無を検査できる方法を検討することをおすすめします。

脆弱性情報の収集:脆弱性診断で補完

資産の把握・管理が漏れなく適切に実施できたとしても、関連する脆弱性情報の収集に漏れがあっては意味がありません。シャドーITの場合と同様、そもそもそこに脆弱性が存在することを認識できていなかった、ということがないようにする必要があります。とはいえ、脆弱性診断にはそれなりのリソースがかかるため、サイバー攻撃を受けた場合の影響が特に大きいと考えられるシステム(下記例)に関しては、脆弱性管理プロセスの一環として脆弱性診断を実施することを推奨します。

・外部に公開されているネットワークセグメント
・個人情報の取り扱いや決済機能といった重要な処理に係るシステム
・主力業務に直結するミッションクリティカルなシステム 等

ASMや脆弱性診断の実施頻度

漏れのない脆弱性管理を行い、サイバー攻撃から組織を守るためには、ASMや脆弱性診断をできるだけ高頻度で実施するのが理想です。しかし、負荷やコストがかかるため、自組織のセキュリティポリシーやサイバー攻撃の流行、システムの状況などに応じて決めることがおすすめです。業務への支障とリスク低減効果を考慮した上で、自組織にとって現実的な実施頻度を検討しましょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

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

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

詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

SQAT脆弱性診断サービス

自ステムの状態を知る

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

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

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

ゼロトラストセキュリティ
-今、必須のセキュリティモデルとそのポイント-

Share

クラウドサービスを導入して業務に活用する企業が約7割となった現代、自組織の情報資産を守るために、これまでのセキュリティモデルとは異なる考え方として、ゼロトラストモデルが注目されています。ゼロトラストでは「すべてを疑う」とし、境界内外問わず、すべての情報資産に対してのセキュリティの確保が求められます。本記事では、ゼロトラストとは何か? どのような考え方か? なぜ必要なのか? そして、実装のためのポイントとして現状把握の重要性について解説します。

ゼロトラストとは

「ゼロトラスト」は、「守るべき情報資産に対するあらゆるアクセスを信頼せず、すべて検証する」という原則に基づくセキュリティモデルです。

従来のセキュリティモデルである「境界型セキュリティ」とは異なり、ネットワーク境界(ネットワークの内側と外側)における信頼度を前提にしません。境界型セキュリティではネットワーク内部を信頼し、外部との境界を守ることが主眼としますが、ゼロトラストではすべてのアクセスに対して徹底的な検証を行います。ユーザやデバイスがネットワークに接続しようとする際に、その正当性を継続的かつ厳格に確認するのです。これにより、内部ネットワークへの侵入や権限の乱用を最小限に抑え、セキュリティを向上させることが期待できます。

境界型セキュリティの限界

ゼロトラストの根底にあるのは、境界の内側が必ずしも安全ではないという認識です。ゼロトラストという概念が生まれた背景として、以下のような事情による、境界型セキュリティの限界があります。

クラウド利用/テレワークの普及

国内企業におけるクラウド利用は7割超、テレワークの普及率は約5割とのことです(下図)。従来の境界型セキュリティの考え方では、社内ネットワークの内側は信頼できる領域であり、従業員もその領域内にいるものとされてきました。しかし、クラウドサービスは社外からアクセスでき、テレワークでは社外にいる従業員が企業・組織のシステムやデータにアクセスできるため、「ユーザは社内におり、社内の環境はセキュリティが確保されているから安全である」という前提が崩れてきています。

企業におけるクラウドサービスの利用状況
総務省「情報通信白書令和5年版 データ集」より
テレワーク導入率の推移
総務省「情報通信白書令和5年版 データ集」より

サイバー攻撃の高度化

攻撃者は、標的型攻撃やゼロデイ攻撃など、様々なやり方で境界防御の突破を狙ってきます。そして、その手法はどんどん高度化・巧妙化しています。これに対して、境界型セキュリティでは、侵入させないためにファイアウォールを実装して、IPS(侵入防御システム)も実装して…と境界の壁を強固にすることを考えますが、技術が進歩してくなかで壁を強固にする側とそれを破ろうとする側のいたちごっこになるばかりで、結局のところ、無敵の壁をつくることは不可能といえます。

媒体経由感染/内部犯行等のリスク

攻撃者はネットワークへの不正アクセスに成功した場合、社内ネットワーク内を移動してマルウェア感染を広げるなど侵害を拡大させますが、境界型セキュリティではこれを防ぐことはできません。そもそも、外部からの侵入者に限らず、USBメモリ等の物理媒体を経由したマルウェア感染や内部犯行による情報窃取のリスクに対して、従来の境界型セキュリティでは、十分な対策を講じることは困難です。

VPN利用に係るリスク

先に触れたテレワークの普及に伴い、そのセキュリティ対策としてVPNの利用が拡大しました。しかし、VPN機器における脆弱性の放置がIPAやJPCERT/CC等からもたびたび注意喚起されており、これらの脆弱性を悪用した攻撃は境界型セキュリティで防御することが困難です。また、VPNを介した通信量の急増により、帯域不足やパフォーマンスの低下が発生する可能性があり、セキュリティを維持しながら利便性を享受することがしづらいケースもみられます。

進むゼロトラストの普及

日本も含め、世界中でゼロトラストの実装が進んでいることがうかがえる調査結果があります(下図)。

クラウド利用やテレワークの普及、DXの推進といった業務効率化・利便性を阻害せず、セキュリティを向上させる仕組みが必要とされる昨今、ゼロトラストの導入は待ったなしであり、今後もあらゆる業種において進んでいくと考えられます。

進むゼロトラストの普及
Okta「ゼロトラストセキュリティの現状 2023」より

ゼロトラストの基本原則

ゼロトラストの考え方の基本原則は、2020年にNIST(米国立標準技術研究所)より発行された「NIST SP 800-207 Zero Trust Architecture」で定義されています。以下に7つの基本原則をご紹介します。

ゼロトラストの基本原則
出典:「NIST SP 800-207 Zero Trust Architecture」(2020/8/11) https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdfより当社和訳・要約

ゼロトラストの適用方針

ゼロトラストアーキテクチャをどのように適用していくか、という点については、デジタル庁発行の「ゼロトラストアーキテクチャ適用方針」も参考になります。同文書では、以下のような6つの適用方針が示されています。

ゼロトラストの適用方針
出典:デジタル庁「ゼロトラストアーキテクチャ適用方針」(2022年(令和4年)6月30日)https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/5efa5c3b/20220630_resources_standard_guidelines_guidelines_04.pdfより当社要約

ゼロトラストを実現するためのポイント

ゼロトラストの考え方について述べてきましたが、実際にゼロトラストアーキテクチャを構築・運用するにあたってはどういった要素があるのでしょうか。ここでは実現するためのポイントとして、5つの例をご紹介します。

ゼロトラストを実現するためのポイント
※表内に挙げた技術はゼロトラストの複数の要素に当てはまるものも含まれます。選別・適用にあたっては、組織の状況に応じてご検討ください。

まずはセキュリティ状況の可視化と有効性の確認を

境界型セキュリティは、機器やシステム、アプリケーションといった単位でセキュリティ対策を講じる発想でした。つまり、各リソースを単一点(シングルポイント)としてとらえて保護する形です。しかし、これでは様々な形態のアクセスを想定したIT環境において、十分なセキュリティ対策を講じることは困難です。もし、境界型セキュリティのみに依存している場合は、これまでの脆弱性対策やセキュリティポリシーの内容および運用の見直しが求められそうです。

とはいえ、ゼロトラスト導入にはそれなりのコストがかかることは間違いありません。また、これまでのセキュリティ対策とは根本的に考え方が異なるセキュリティモデルを実装するため、導入するには課題もあります。そこで、まず取り組めることとして、以下のようなセキュリティ対策の基本から始めることが重要です。

・セキュリティ状態の可視化
セキュリティコンサルや各種脆弱性診断などにより、自組織の状態を明確に把握する
・実装済みのセキュリティ対策の有効性評価
ペネトレーションテストやログ分析などにより、実装したセキュリティ対策が有効に機能しているか確認する

こうして自組織内の情報資産の状態を把握することで、万が一サイバー攻撃を受けてしまっても、被害を最小限に抑えることが可能になります。組織の状況に応じて、適切な対策を実施していくことが、セキュリティ向上への第一歩となるでしょう。

BBSecでは

SQAT脆弱性診断

自システムの状態を知る

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

ペネトレーションテスト

攻撃を受けてしまった場合の対策の有効性を確認

完全に防ぎきることは難しくても、「攻撃・侵入される前提の取り組み」を行うことで、攻撃を受けてしまった場合にも被害を最小化する対策をする、「多層防御」が重要です。SQATペネトレーションテストでは実際に攻撃者が侵入できるかどうかの確認を行うことができます。

【コラム】
ゼロトラストに対する疑問

ゼロトラストについて、様々な疑問を持っておられる方もいらっしゃるでしょう。ここでは、ゼロトラストへの理解を進めるために、そういった疑問の例と、それに対する回答をピックアップしました。


ゼロトラストとはどのようのツールや技術?
ゼロトラストは特定の技術やツール、ソリューションを指す言葉ではありません。ゼロトラストは、セキュリティのアプローチや考え方を表す概念です。

ゼロトラストモデルか境界型セキュリティのどちらがいい?
ゼロトラストは境界型セキュリティを否定するものではありません。システムの特性や業務上の要件によって、両者を使い分けるとよいでしょう。境界型セキュリティが有効な場面として、ゼロトラストモデルへの移行が困難なレガシーシステムや特定の業界標準要件への対応、セキュリティ対策の構築・運用コストとの兼ね合いなどの事情が考えられます。

何を実装すればゼロトラストを達成できたと言える?
これを行えばゼロトラストを実現できている、という絶対的な答えがあるわけではありません。組織の実情に応じて異なるアプローチが必要です。ゼロトラストは単一の技術や手法ではなく、包括的なセキュリティモデルを指すためです。ゼロトラストモデルの具体的な適用ポイントについては先に述べた「ゼロトラストの適用方針」をご参照ください。

ゼロトラストの導入でシステムの利便性が落ちるのでは?
むしろ利便性を損なわずにセキュアな環境を提供することを目指すのが、ゼロトラストです。適切な設計・実装により、境界型セキュリティの制約から解放され、柔軟かつ安全なリモートアクセス環境を築くことが可能です。


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

APIのセキュリティ
―Webアプリでもスマホアプリでも安全なAPI活用を―

Share

APIはAI、IoT、モバイル、クラウド利用において今や必要不可欠です。利便性があり、利用者も増える一方で、APIを狙ったサイバー攻撃の数も増加傾向にあります。本記事では、APIとは?API連携の仕組みやスマホアプリとの関連、活用のメリットについて触れつつ、APIのセキュリティ対策の一つとして、脆弱性対応の方法ついて解説します。

APIとは

APIとは「Application Programming Interface」の略です。プログラムの機能をその他のプログラムでも利用できるようにするための仕組みです。

ソフトウェアやアプリ、プログラム同士を、APIを介して機能連携させるのが「API連携」です。あるソフトウェアに他のソフトウェアの機能を埋め込むイメージです。API連携によってソフトウェア同士が相互にデータと機能を共有できるようになります。

APIとはの概要図

【APIの活用例】

社内業務システム : チャットAPIを活用してコミュニケーション
会員サービスサイト : SNSアカウント認証APIでログイン
ネットショップ : クレジットカード・認証APIで決済
飲食店サイト : 地図情報APIで店舗位置情報表示 × 予約受付APIで予約対応

API活用のメリット

APIには、以下のようなメリットが考えられます。

API活用のメリットの概要図

Web API

「Web API」は、HTTPやHTTPSといったWeb技術により実現される、インターネットを介して情報をやりとりするAPIです。連携するAPI同士が異なるプログラミング言語で構築されていても通信でき、Webブラウザ上でも稼働するWeb APIは汎用性が高く、最も多く活用されているAPIです。

複数のWeb APIを組み合わせて新しいサービスを生み出す”マッシュアップ”が多く行われており、多くの人々が、日々その恩恵を受けていると言えるでしょう。インターネット上には膨大な数のWeb APIが公開されており、今後もマッシュアップは続くものと考えられます。

スマホアプリとAPI

Web APIは、Webアプリケーションばかりでなく、スマートフォンアプリ(スマホアプリ)でも多く活用されています。

例えば、経路案内アプリでは交通機関・運賃・時刻等の情報を的確に検索してくれるAPIが、家計簿アプリでは電子マネーによる決済やクレジットカード決済などの情報を取得して計算してくれるAPIが使用されています。

スマホアプリは、外部との通信をせずにスマホ端末単体で動作するものよりも、インターネットに接続しながら使用するものが圧倒的に多く、ユーザが利用している画面の裏でインターネットを介してサーバとのやりとりが行われており、そこでWeb APIが稼働しているのです。

スマホアプリとAPIの概要図

スマホアプリのセキュリティについて、SQAT.jpでは以下の記事で解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ瓦版「攻撃者が狙う重要情報の宝庫! ―スマホアプリのセキュリティ―

増え続けるAPI活用

国をあげてDXの取り組みが推進されている昨今、AI、IoT、モバイル、クラウド利用において、APIの積極的な活用は不可欠です。

クラウド環境上で動作するアプリ、クラウドネイティブアプリケーションを例にとると、APIを使用している割合は高く、今後さらに増大することが予想されるとの調査結果があります(下図)。

APIに対するセキュリティ脅威

利便性が高いAPIですが、利用が増えれば、そこに存在する様々なデータを攻撃者が狙ってきます。APIに対するセキュリティ脅威の例は以下のとおりです。

APIに対するセキュリティ脅威の概要図

APIによって機能や取り扱う情報はそれぞれですが、金融情報のような資産に紐づくデータ、医療情報のような機微情報に関するデータなど、流出して悪用されると深刻な被害につながりかねません。APIを開発・利用する上で、セキュリティは必ず考慮する必要があるということです。

APIのセキュリティ脅威について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ玉手箱「APIのセキュリティ脅威とは

APIを狙ったサイバー攻撃の増加

APIに対する攻撃は増加傾向にあるとの観測結果が報告されています(下グラフ)。

APIを狙ったサイバー攻撃の増加の概要図

なお、このグラフで多くの割合を占めている「ローカルファイルインクルージョン」は、攻撃者が対象システムのローカル上のファイルを読み込ませることで、領域外のファイルやディレクトリにアクセスできるようにしてしまう脆弱性です。情報漏洩、任意のコード実行、認証回避、DoS(サービス運用妨害)などの被害につながる恐れがあります。攻撃されたAPIサーバを「踏み台」とした内部/外部ネットワークへのさらなる攻撃やマルウェア感染などが想定されるため、危険度の高い脆弱性と言えます。

また、100ヶ国を対象にしたアンケート調査では、API攻撃による情報漏洩を経験している組織が90%以上にのぼるとの結果も報告されています(下グラフ)。

APIを狙ったサイバー攻撃の増加の概要図(アンケート調査)

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASP(Open Web Application Security Project)が、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したもので、今回は2019年の初版リリースから4年ぶりの第二版となります。

APIのセキュリティ対策

ここまで見てきたAPIセキュリティ脅威を踏まえると、以下のようなポイントにおいて脆弱でないことが重要と考えられます。

APIのセキュリティ対策のポイント図

開発中、リリース後、更新時といったいかなる状況においても、適切な脆弱性管理・対応ができているかどうかが、鍵となります。

APIのセキュリティ対策の概要図

APIの開発にあたっては、DevSecOpsを適用して脆弱性を作り込まないようにすること、APIリリース後も、新たな脆弱性が生まれていないか、APIセキュリティ診断などを通じて確認を継続することが重要です。

また前段の「スマホアプリとAPI」でも述べたように、APIはスマホアプリでも多く活用されています。誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。スマホアプリのセキュリティ対策の一つとしては、信頼できる第三者機関による脆弱性診断の実施があげられます。第三者の専門家からの診断を受けることで、網羅的な確認ができるため、早急に効率よく対策を実施するのに役立つでしょう。

BBSecでは

スマホアプリ脆弱性診断

悪意ある第三者の視点で、対象アプリに影響を及ぼす恐れのある脅威と関連リスクをあぶり出します。実機を使った動的解析とAPK(Android)・IPA(iOS)ファイルの静的解析を実施します。

スマホアプリ脆弱性診断バナー

Webアプリケーション脆弱性診断

また、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。弊社診断エンジニアによる、より広範囲で網羅的な診断を検討している方は、手動で診断する、「Webアプリケーション脆弱性診断」がおすすめです。

Webアプリケーション脆弱性診断バナー

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