APIのセキュリティ脅威とは

Share

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

APIとは、ソフトウェアが相互に機能やデータを利用しあうための仕組みで、機能や開発効率を向上させるなどのメリットがあります。しかしAPIにもセキュリティ上のリスクがあり、セキュリティ対策を怠ったことによる被害も報告されています。今回は、APIの安全な利活用について解説します。

「API」とは

「API」とは「Application Programming Interface」の略で、複数のソフトウェアが相互に機能を利用しあうために設けられたインターフェースを意味します。コンピュータプログラムやWebサービスなどをつないで連携させ、さまざまな機能やデータを共有可能にすることで、従来にない価値を生み出せるという点が大きなメリットといわれています。例えば、あるアプリが、特定の機能を持つAPIを利用することで、それまでなかったサービスをユーザに提供できるようになります。

APIのなかでも広く利用されているのがWebに公開されている「Web API」で、多数のWebサービスやプラットフォーマーが各社のWeb APIを公開しています。身近な例としては、位置情報ゲームで地図情報サービスが提供するAPIを利用するケースなどがあります。

APIの積極的な活用は、IoTや企業のDX(デジタルトランスフォーメーション)の実践に不可欠と言っても大げさではありません。さまざまなアプリやWebサービスがAPIを通じて相互接続することで、利用者の利便性の向上、経済の活性化など、単独では実現できなかった価値を生み出せるようになります。こうした仕組みのことを「APIエコノミー」と呼ぶこともあります。

あなたの身近にあるAPIの活用例

Webサービスなどを利用しているときに「Facebookでログイン」「Googleでログイン」などのボタンを見たことはありませんか? Facebook、Google、Twitterなどで設定したアカウントを使って、別のECサイトなどにログインする「ソーシャルログイン」は、各サービスが公開するAPIを使って実現されています。また、企業などのWebサイトで地図情報がGoogle Mapから呼び出されて掲載されている、あの仕組みもAPIによるものです。

API活用のメリット

APIを活用すれば、個別の機能を各サービスで一から開発する必要がなくなるため、開発効率が上がり、コストを抑えることができます。機能を提供する側も、機能を使ってもらうことで自社のブランド力の向上、広告収入といった経済的利益を得られます。また、前出の「ソーシャルログイン」などでは、独自のログイン用プログラムを各企業がそれぞれ開発する場合に比べ、一定のセキュリティ水準を確保できるという効果も期待できます。

Web APIはWebアプリケーションでどう使われるか

ここで、「Web API」はいわゆる「Webアプリケーション」でどう使われるのか、少し補足しておきましょう。

WebアプリケーションがAPIを用いて地図情報だけを外部の地図サーバから取得しているケースについて考えてみます。Webサーバはブラウザからのリクエストを受け、WebアプリケーションからAPIを経由して地図情報を地図サーバにリクエストします。地図サーバはAPIを介して地図情報をWebアプリケーションへ送り返します。それを受けたWebサーバが、地図情報を含めたページ全体をユーザに返します。ユーザから見たときにはAPIを使っているかどうかはわかりませんが、このように、APIは、特定の機能のため、特定の情報のやり取りのために利用されているのです。

APIのセキュリティの重要性

Webサービスを利用するユーザ側から見れば、そこでAPIが使われているかどうかは何ら重要なことではありません。しかしサービス提供側から考えた場合、APIにもWebアプリケーション同様、脆弱性をはじめとするさまざまなセキュリティリスクが存在することを忘れてはなりません。また、近年のスマートフォンの普及により、スマートフォンのアプリケーションがAPIを直接利用するケースも増えており、今までサーバ側での利用が主流だったAPIがユーザの手元から直接利用される時代になっている点にも注意が必要です。

適切なセキュリティ対策を怠った場合のリスクは、むしろWebアプリケーションよりも深刻かもしれません。さまざまなソフトウェアと連携するというAPIの特質から、被害が自社のコントロールの及ぶ範囲を超えて広がる可能性が想定されるためです。

APIが原因で起こったサイバー攻撃被害

2018年、米大手SNSが開発者向けに公開していたAPIのバグが悪用され、ログインを行う際のカギとなるデータが盗まれる事件が発生しました。2019年には、大手配車マッチングアプリで、APIが降車時の支払い方法の検証をしないことで、無賃乗車ができてしまうバグが報告されています。

米大手SNSの事件は、多数のAPIが組み合わされることによって、バグの検出やセキュリティ上の問題の発見が遅れたり困難になったりするという問題をあらわにしたものでした。また、配車マッチングアプリのバグは、APIの入力値を検証することの重要性を改めて気づかせるものでした。

その利便性から急速に普及が進んでいるAPIですが、「事故やサイバー攻撃被害の発生によって初めて、リスクの存在を認識する」という昨今の状況を踏まえると、セキュリティに関してはまだまだ未成熟な領域であるといえるでしょう。

「OWASP API Security Top 10」などのリソースを活用して対策を立てる

こうしたサイバー攻撃被害や事故を受け、今、APIのセキュリティは最重要事項の1つとして取り組まれるようになっています。その大きな成果の1つとして、「API Security Top 10」をご紹介しましょう。これは、Webアプリケーションセキュリティに関する国際的コミュニティOWASP(Open Web Application Security Project )がAPIセキュリティに関する10大リスクを選定・解説したもので、2019年末に公開されました。API固有のセキュリティリスクを把握し、対策を講じるために役立ちます。


OWASPによるAPIセキュリティ10大リスク

1.オブジェクトレベルでの許可の不備(Broken Object Level Authorization)
2.認証の不備(Broken User Authentication)
3.データの過度な露出(Excessive Data Exposure)
4.リソースの制限、頻度の制限の不足(Lack of Resources & Rate Limiting)
5.機能レベルの認可の不備(Broken Function Level Authorization)
6.一括での割り当て(Mass Assignment)
7.不適切なセキュリティ設定(Security Misconfiguration)
8.インジェクション(Injection)
9.不適切なアセット管理(Improper Assets Management)
10.不充分なロギングとモニタリング(Insufficient Logging & Monitoring)

(翻訳:SQAT.jp 編集部)


上記のような資料は、自組織のAPIセキュリティを点検する際のガイドラインとしてぜひ活用したいものです。さらに、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。

まとめ

・APIとはアプリやWebサービスなどが相互に機能やデータを利用しあうための仕組みです。
・API活用には、開発のスピードアップやコスト削減などのメリットがあります。
・近年はスマートフォンからAPIを直接利用できるケースも増えており、利用の機会が増えています。
・APIにもセキュリティ上のリスクがありますが、様々なサービスとつながるために利用するという性質から、ひとたび事故や攻撃が起こった場合、より広い範囲に影響が及ぶ可能性があります。
・APIのセキュリティ対策を怠ったことによるサイバー攻撃被害や事故が報告されています。
・OWASP「API Security Top 10 2019」などを参考にAPIのセキュリティ強化に取り組みましょう。

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


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

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

Webアプリ脆弱性の代表格「クロスサイトスクリプティング」の攻撃事例と対策

Share

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

クロスサイトスクリプティング(XSS:Cross Site Scripting)とは、サイバー攻撃に悪用される脆弱性のひとつです。

この脆弱性を悪用した攻撃の多くが、Webサイトを横断(Cross Site)して行われたためこの名称がつけられました。現在では攻撃類型が増えたことから、必ずしもサイト横断的な攻撃でなくても、クロスサイトスクリプティングと呼ばれることがあります。

今回は、クロスサイトスクリプティングを悪用したサイバー攻撃の事例やその対策について説明します。

クロスサイトスクリプティングの種類

クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる(できる)事象を指します。

クロスサイトスクリプティングの脆弱性には、大きく分けて下記の3種類があります。

1.反射型
攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの

2.蓄積型
攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの

3.DOMベース
Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

クロスサイトスクリプティング脆弱性が悪用された事件による騒動

クロスサイトスクリプティングの脆弱性が悪用された被害が多数報告されています。なかでも有名なのは、過去に二つの大手ITサービスで発生した事件です。

2010年、YouTubeとTwitterで、クロスサイトスクリプティングの脆弱性を悪用した攻撃が相次いで発生、虚偽情報を知らせるポップアップが表示されたり、ユーザが意図しない投稿が繰り返されたりするなど、世界中で騒動となりました。

Twitterへの攻撃は、ユーザが意図しない投稿を行うもので、見つけた脆弱性がどう動くのか実験したいというちょっとした出来心が攻撃意図に含まれていたと言われています。YouTubeについてはフェイクニュースをポップアップで表示するなどのいたずらに近い内容でした。いずれも被害は軽微で、すぐに気づくことができた点は幸運だったといえるでしょう。

クロスサイトスクリプティングを悪用した攻撃の本当の危険性と恐ろしさ

クロスサイトスクリプティング攻撃の危険性

一方、上記のようないたずら目的ではない攻撃では、正規サイトと全く見分けがつかないフィッシングサイト等へ誘導されたり、ログイン状態の維持のために利用しているCookieなどのセッション情報を盗まれたり、入力した情報(例えばパスワードやクレジットカードの番号やセキュリティコード)が盗まれるといったことが行われます。この結果、アカウントへの不正アクセス、クレジットカード情報・個人情報の漏えい、あるいはクレジットカードの不正利用などが行われることがあります。またスクリプトの実行による任意コードの実行やマルウェア感染といった問題も存在します。このようにクロスサイトスクリプティング脆弱性は悪用された場合に甚大な被害が発生する可能性が高いという点に危険性があるといえます。

ユーザに被害が出てから発覚することのリスク

Webアプリケーションを利用するユーザの側では、身に覚えのないクレジットカードへの課金など、具体的な被害が発生するまで攻撃を受けたことにすら気づかないこともあるでしょう。一方のWebアプリケーション開発側・運用側でも、実際にユーザやクレジットカード会社から被害発生を知らされるまで気づかないというケースもあります。

ユーザ側の視点でみると、「自分が被害に遭ったのに、サイトの運営者が気付いていないなんて」と憤る可能性もありますし、「こんな不完全なサイトを運営するなんて」と不信感を抱く可能性もあるでしょう。クロスサイトスクリプティング脆弱性のあるサイトを運用することはともすればユーザの信頼を損なう結果に結びつく可能性があるのです。

クロスサイトスクリプティングの発見報告状況

SQAT.jp を運営する株式会社ブロードバンドセキュリティが行ったWebアプリケーション脆弱性診断の2020年上半期の統計によれば、クロスサイトスクリプティングは、検出される全脆弱性の約5%を占めています。

冒頭で「Webアプリ脆弱性の代表格」と述べている割にあまり比率が多くない、と感じるかもしれませんが、むしろ古くから警鐘が鳴らされ、対策も公表されているにもかかわらず、新たに作られたWebサービスにも(ステージング環境の診断を含むとはいえ)一定割合存在する点に注目すべきでしょう。

クロスサイトスクリプティングは入出力制御に関する問題です。したがって金融・保険業界、情報通信産業やECサイト関連等の、「オンラインでの商取引を厳格に行う必要がある業界」「個人情報や決済情報を厳密に扱う必要がある業界」では、クロスサイトスクリプティングを含む入出力制御に関する問題への対策が厳格に行われています。これらの業界では開発段階でのソースコード診断やステージング環境での脆弱性診断などを行って必要な修正を施したうえで本番環境へ移行しているケースが多いのです。

このように、シフトレフトの考えに基づいて開発中にソースコード診断を行う、開発の最終段階やWebサイトの改修などの都度こまめに脆弱性診断を行うことで、クロスサイトスクリプティングの脆弱性をより早い段階で解消する効果は見逃せないものではないでしょうか。

クロスサイトスクリプティングの脆弱性を発見し対処する必要性

以前の記事で紹介した裁判事例では、WebアプリケーションにSQLインジェクション脆弱性を発生させた開発会社に対して、実際に損害を被った企業向けに約2,200万円の損害賠償支払いを命じる判決が2014年に下されています。

また、2020年6月に公布された改正個人情報保護法においては、サイバー攻撃によって個人情報漏えいが発生した場合でも、被害者個人(本人)と個人情報保護委員会への通知が義務付けられました。違反には最高で1億円の罰金が科され、悪質な場合は社名も公表されます。2022年の施行に先立ち、具体的な運用方法について年内に政令や規則がまとめられる見通しですが、今後、Webサイトを運営する企業の義務と万が一の場合の責任は重くなることが予想されます。

先にみたように、クロスサイトスクリプティングの脆弱性に気づかず放置することで、フィッシングに悪用されるケースや、不正アクセス、情報漏えいなどさまざまな被害が生じる可能性があります。

本稿執筆時点の2020年、クレジットカード情報をWebサイト上で盗むためにクロスサイトスクリプティングの脆弱性を悪用する攻撃が問題となっており、現在もクロスサイトスクリプティングが脆弱性の代表格であることに変わりはありません。

クロスサイトスクリプティングの対策方法

クロスサイトスクリプティングの脆弱性を生み出さないための対策としては、以下の方法が挙げられます。

1.JavaScript実行のために埋め込まれる特殊文字を変換して処理(エスケープ処理)することや入力文字種を制限して特殊文字を許容しないといった対策を行う

2.正規のスクリプトが悪用されないようにするため、処理中に文字列が意図しないスクリプトとして解釈されないようにホワイトリストなどによる検証を行う

3.DOMベースXSS対策として、DOM操作用のメソッドやプロパティを使用する

4.Webアプリケーション開発にあたって信頼性の高いライブラリを利用する

また、Webアプリケーションへの入力値のチェックなどを行うWAF(Webアプリケーションファイアウォール)を用いた防御なども考えられるでしょう。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決をはかることができない点に注意が必要です。

クロスサイトスクリプティングを脆弱性診断で発見し、適切に対応して利用者の安全を守り、組織の顔であるWebサイトやWebアプリケーションの健全性を維持することは、WebサイトやWebアプリケーションを運営する企業や組織にとって必ず行わなければならない義務といえるかもしれません。

まとめ

・クロスサイトスクリプティングはサイバー攻撃に悪用されるWebアプリケーション等の脆弱性のひとつです。
・蓄積型や反射型、DOMベースなどの種類があります。
・Webサイト等に悪意のあるスクリプトを混入させることで攻撃を行い、ユーザの情報を盗み出すなどの被害が発生します。
・「特殊文字の変換処理」「入力文字種の制限」などの対策実施によって防ぐことができます。
・クロスサイトスクリプティングに限らずWebアプリケーションの脆弱性を積極的に発見し対処することは運営者の社会的義務です。

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


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

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

テレワーク環境下における営業秘密の保護

Share

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

緊急事態宣言が解除されて1か月余り。通常勤務に戻る企業もあれば、テレワークを存続させる企業もあり、対応はさまざまです。不動産業界の調べによれば、東京都心のオフィスビルの空き室率は2020年3月以来微増しており、テレワークを今後も継続する企業は少なくないようです。

もともと欧州ではワークライフバランスの立場から在宅勤務(テレワーク)を推進してきました。オランダでは2016年に労働者が自宅を含む好きな場所で働く権利を認める法律が施行されています。フィンランドでも今年1月に同様の法律が施行されました。コロナ禍によってこうした動きは一層加速されており、米国は民間企業主体ではあるものの、やはり大手IT企業を中心に在宅勤務を義務化・恒久化する動きがあります。

しかしながら、日本においてはテレワークが欧米ほど浸透していません。国土交通省が今年3月に実施した「令和元年度テレワーク人口実態調査」では「会社でないと閲覧・参照できない資料やデータがあった」のは26.8%、また、セキュリティ対策に不安があったのは3.4%とありました。情報へのアクセス整備やセキュリティ対策不備に伴う漏えいへの不安がテレワーク推進の妨げになっていると考えられます。

テレワークにおける情報漏えいの不安

テレワークの場合、自宅での「在宅勤務」、出先や移動中に行う「モバイルワーク」、シェアオフィスなどを利用する「サテライトオフィス」のいずれにしても、インターネットを通じて業務データを社外で利用することに変わりありません。また、作業者が使用しているPCに重要なデータをダウンロードして作業する場合、セキュアゾーンで実施されないことも多いでしょう。そこにセキュリティ上の不安があるものと思われます。

総務省「テレワークセキュリティガイドライン第4版」においても、起こりうる事故として「情報漏えい」「重要情報の消失」を挙げています。確かに、企業が保有する設計図・製造ノウハウ・調査研究データなどの技術的な情報、取引内容・顧客リスト・財務データなどの営業上の情報は、事業存続および競争力強化にとって重要な情報資産であり、漏えいすることによるリスクははかりしれません。こうした懸念から、テレワークへの切り替えを躊躇する向きもあるでしょう。

そこで、適切にセキュリティを確保して情報流出の不安を解消しながらテレワークを実施できるよう、経済産業省は5月7日、「テレワーク時における秘密情報管理のポイント (Q&A解説)」を公表しています。以下に、そのポイントをみていきましょう。

「不正競争防止法」により保護される営業秘密(機密情報)

セキュリティ対策によって保護すべき、企業が保持する「営業秘密」は、一定の要件を満たすことで不正競争防止法の下で保護されます。法的保護を受けることにより、例えば電子データで取り扱われている機密情報がセキュリティの脆弱性を突かれて漏洩した場合でも、差止請求や損害賠償請求などが可能です。このため、事業における金銭的被害や信用失墜といったリスクを軽減できます。

ただし、営業秘密として法的に認められるためには、対象となるデータに対して以下の条件が整っていることが必要です。

1.秘密管理性:その情報が秘密であるとわかるように管理されていること
2.有用性:事業活動に役立つ情報であること
3.非公知性:世間一般に知られていないこと

「秘密管理性」の趣旨は、「企業が秘密として管理しようとする対象(情報の範囲)が、従業員等に対して明確化されることによって、従業員等の予見可能性、ひいては経済活動の安定性を確保する」ことにあるとされています。つまり、情報が営業秘密として保護されるためには、「秘密である」こと自体をはっきり示す必要があります。

「非公知性」は、営業秘密保有者の管理下以外では一般的に入手することができない状態とされています。このため、営業秘密としての条件を満たすには、容易に人に見られたり、聞かれたりしないようにしなければなりません。

テレワーク環境で営業秘密を保護する対策

テレワーク環境下で、秘密管理性と非公知性の要件を満たして情報を保護しつつ、情報漏えいを防止するには、状況に応じて以下のような対策が挙げられます。

状況別 対策の例
テレワーク対応導入の第一歩 ●営業秘密管理規程、情報取扱規定等をテレワークに即した内容に改訂
●諸規程の従業員に対する周知徹底
●情報に応じたアクセス権者の設定 等
業務における情報持ち出しおよび
社外からのアクセス
●データのファイル名や当該データ上に「㊙」(マル秘)・「社内限り」等の秘密であることの表示を付す*1
●情報のコピー・持ち出しにおける上長等の事前許可/返却・破棄ルールの周知・徹底と持ち出し記録の整備
●紙の資料・PC等を机上等に放置しないといった取扱いルールの徹底
●ID・パスワードによるアクセス制限の実施
●チャットツールで営業秘密についてやりとりするスレッドと参加者を限定 等
社外作業 ●PCにのぞき見防止フィルム等貼付の徹底
●音声が漏れない場所でのオンライン会議実施徹底
●公共無線LANの使用禁止、従業員のポケットWi-Fi・テザリングの禁止、業務使用Wi-Fiの貸与 等
情報漏えい、不正持ち出しの防止 ●メールの転送・添付制限、送信前の上長承認、上長のCC追加設定
●遠隔操作でPC内データを削除できるツールの利用
●PCに対するUSB、スマホ接続不可設定
コピーガード付き記録媒体の利用 等

営業秘密として秘密管理性要件を満たすと認められる技術的要素

テレワークにおける情報流出対策として規程を整備し、徹底した従業員教育を行ったとしても、所詮は人間が実施することであるため、悪意の有無にかかわらず、すべてが絶対確実に守られるとは言い切れません。そのため、前述の対策の例にも、技術的に強制するような仕組みがいくつか含まれています。

アクセス制御と権限管理の徹底

データ管理における秘密管理性要件については、通常、アクセス制御が実施されていることをもって、「秘密である」ことを示すと見なされています。これは、アクセス制御の基本的な考え方が、当該情報を知るべき者だけが情報にアクセス可能であるべきという「Need to Know」の原則に基づいていることと関係があります。アクセス制御とは、正規に承認されたユーザにのみコンテンツへのアクセスを許可するセキュリティ対策だからです。

このため、秘密管理性の要件を満たすためには、アクセス制御自体が適正に実施されている必要があります。例えば、同じアカウントを複数の従業員が使い回しているような状態や、パスワードに社員番号をそのまま当てはめていて他人が容易に推測可能な状況の場合、秘密管理措置を講じていないと判断される恐れがあります。

アクセス制御が「対象へのアクセスそのものを制御する」のに対し、「行為の実行権限を管理する」のが権限管理です。権限管理とは、ログインによってWebシステムやファイルサーバへアクセスするためのユーザを認証するシステムにおいて、各ユーザアカウントの役割を定義し、データに対する閲覧・編集等、実行できる処理についての権限を付与・管理することを言い、当該ユーザに対して必要最低限の権限を付与する「最小権限の原則(Least Privilege)」を適用します。データの重要性や種類に応じて、特定のグループだけが編集権限を持ち、他の従業員には閲覧のみを許可するといった設定です。

適正なアクセス制御・権限管理のどちらが欠けても「脆弱なシステム」であると言わざるを得ません。

認証機構の堅牢化

アクセス制御に欠かせない認証機構ですが、IDとパスワードによる単要素認証は、リスト型ハッキング攻撃等の標的となりやすいため、テレワーク導入・継続に備え、パスワード強度に対するポリシーの見直しをお勧めします。現在、セキュリティの各種基準・仕様においては8文字未満のパスワードは脆弱であるとみなされており、14文字以上のパスワードが推奨されています。流出したパスワードや汎用的で推測容易なパスワードを排除する実装の導入も有効です。

しかしながら、ユーザにとっては長いパスワードを複数覚えておくのは至難の業であるため、パスワードの使いまわしもなくならないでしょう。これを防ぐには、ID/パスワード以外に、認証要素(指紋や顔等の生体認証、またはワンタイムパスワードトークンやSMS等の所有物認証)を1つ以上追加した、多要素認証の導入をお勧めします。

この他、データの管理についても注意が必要です。データをUSBやDVDに記録できないようにする、プロジェクト終了後のデータ消去について確認する手段を講じるなどです。

テレワーク導入・継続における技術的要素について、詳しくはこちらもご参照ください

法的要件の確認にも有効なセキュリティ診断

営業秘密として保護されるべき法的要件を技術的な側面で満たしているかどうか確認する有効な手段に、セキュリティ診断があります。営業秘密に当たる情報を扱っているWebアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT機器等に対し、第三者であるセキュリティ専門企業による診断を受けることをお勧めします。

先に述べた、アクセス制御や権限管理が適切に導入・運用されているかも、セキュリティ診断によって確認できます。

自らは気づいていない脆弱性を洗い出して悪用された場合のインパクトを事前に調査し、技術的に対応できること、対応が難しければ法的保護を受けるために講じるべき回避策や代替手段として何を整備しておくべきかを検討するなど、リスク対応策を検討しておくことが事業継続の肝となります。


参考情報

・テレワーク時における秘密情報管理のポイント (Q&A解説)
https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/teleworkqa_20200507.pdf

・逐条解説 不正競争防止法
https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/20190701Chikujyou.pdf


まとめ

・テレワークは緊急事態宣言後も一定の割合で継続される見込み
・テレワーク導入・継続における情報流出の不安には、経済産業省による「テレワーク時における 秘密情報管理のポイント (Q&A解説)」が対策のヒントになる
・テレワーク環境下でも、会社の重要情報を「不正競争防止法」による法的保護の対象である「営業秘密」として管理することが肝要
・適正なアクセス制御と権限管理は営業秘密の秘密管理性要件を満たす技術的なセキュリティ対策である
・機密情報を扱うシステムに対するセキュリティ診断の実施は、リスク対策における技術的な対応策と法的保護策の切り分けにも活用できる

関連情報

●<インタビュー>上野 宣 氏 / ScanNetSecurity 編集長

●<コラム>「ゼロトラストアーキテクチャ」とは?

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


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

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

情報漏えいの原因と予防するための対策

Share

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

サイバー攻撃の被害を受け、システムの機密情報等が漏えいする事故の件数は年々増加しています。実際に企業がデータ侵害などの被害を受けてしまい、機密情報等の漏洩が発生してしまうと、システムの復旧作業に莫大なコストがかかることになり、企業にとって大きなビジネス損失につなる恐れもあります。では、未然に事故を防ぐ対策はどのような方法があるのでしょうか。本記事では、情報漏えいの原因と予防策について解説します。

情報漏えいとは

情報漏えいとは、サイバー攻撃などによる不正アクセスや、ノートPCの紛失などによって、企業や組織の保有する外部に出てはいけない情報が漏れてしまうことです。個人情報漏えいが特に注目されますが、企業の営業情報や知的財産、機密情報など、漏えいする情報は多岐にわたります。

個人情報漏えい

インターネットの普及に伴い、Webサービスへの会員登録などで個人情報が大量に蓄積され、同時にノートPC・スマホ・USBメモリ等の記憶媒体の容量が増加、情報漏えいも大規模化しました。こうした社会の変化に対応し、2005年(平成17年)、「個人情報の保護に関する法律(個人情報保護法)」が施行されました。

個人情報保護法では、個人情報漏えいが発生した組織は、事実関係と再発防止策に関して、政府の個人情報保護委員会等に「速やかに報告するよう努める」とされており、業種によっては監督官庁への報告義務が課される場合もあります。

情報漏えいの重大度の違い

どんな情報が漏えいしたかによって漏えい事故の深刻度は異なります。「顧客の個人情報が○○件漏えい」といった報道の見出しを見かけますが、漏えいの件数以外にも、情報漏えい事故の重さ、深刻さを左右するポイントを挙げます。

・クレジットカード情報
被害に遭ったユーザーに金銭被害をもたらす可能性の有無という点で、漏えいした情報にクレジットカード情報が含まれていたかどうかは重要なポイントです。損害賠償等が発生した場合、クレジットカード情報が含まれていると被害者への賠償額がアップします。

・セキュリティコード
クレジットカード情報の名義人・カード番号・有効期限だけでなく、3桁のセキュリティコードを含むかどうかが事故の深刻さを左右します。被害に遭ったユーザーに金銭被害をもたらす可能性がより高くなるからです。

・パスワード
たとえばメールアドレスとセットでそれに紐付くパスワードも漏えいしていたとしたら事態はより深刻です。オンラインサービスなどに悪意の第三者が不正ログインできてしまうからです。

・平文パスワード
一般的にパスワードは、もしパスワードを記載したファイルが漏えいしても、第三者が内容を閲覧できないように暗号化して管理するのが常識です。しかし、稀に暗号化されていない平文(ひらぶん)のパスワードが流出する場合があります。こうなった場合、申し開きが全くできない最悪の管理不備のひとつとして、厳しい批判と鋭い糾弾の対象となります。擁護する人は誰もいなくなります。

・機微情報
信条(宗教、思想)や門地、犯罪歴等、さまざまな社会的差別の要因となる可能性がある情報を機微情報といいます。特に、各種成人病やその他疾病など、保健医療に関わる機微情報は医薬品のスパムメールや、フィッシングメールなどに悪用されることがあり、その成功確率を上げるといわれています。


以上のように、ひとくちに個人情報漏えいといっても、その重大さの度合いは異なり、社会やユーザーからの受け取られ方にも差があります。

弁解の余地もない真っ黒な管理状態ではなく、「不幸にも事故は起こってしまったが、打つべき予防対策は事前にしっかり打たれていた」と、ステークホルダーに理解されれば、ビジネスインパクトは限定的なものになる可能性もあります。

情報漏えいの原因

「ハッカーによるサイバー攻撃」「従業員による内部犯行」。情報漏えいが起こる原因としてすぐにこれらが思い浮かびますが、そういった悪意に基づく攻撃ばかりが情報漏えいの原因ではありません。

冒頭で挙げたPC・スマホ・USBメモリの不注意による紛失はいまも漏えい原因の多くを占めていますし、Webサイトのアクセス制限設定ミスで個人情報が見える状態になっていたり、開発中の会員管理システムのテストデータとして、うっかり誤って実在する個人の情報を使ったり等々、必ずしも悪意によるものではなく、管理不備やケアレスミスでも情報漏えいは発生します。

近年、クラウドコンピューティングが普及したことで、影響の大きい設定変更等の操作をブラウザからワンクリックで行うことが可能になりました。こうしたクラウドサービスの設定ミスによる情報漏えいも増加しています。

上場企業での情報漏洩件数は2年連続で過去最多を更新

サイバー攻撃や組織における管理またはシステムの設定不備・不足等が原因となり、機密情報等の漏洩事故および事件が相次いで発生しています。東京商工リサーチの調べによれば、上場企業とその子会社で起きた個人情報漏洩または紛失事故・事件件数は、2022年で165件となり、2021年から連続で過去最多を更新しました。

不正アクセスによる情報漏えい事故

もちろん、悪意ある攻撃も猛威を振るっています。ハッカーによるサイバー攻撃など、以前はアニメと映画の中だけのお話でした。しかし、不正アクセスによる情報漏えいが2010年以降増加し始めました。

特定非営利活動法人日本ネットワークセキュリティ協会(JNSA)が毎年行っている調査「情報セキュリティインシデントに関する調査報告書」によれば、それまでの攻撃と質が異なる攻撃、「標的型攻撃」が観測されはじめた2010年頃から、不正アクセスが原因となるサイバー攻撃は8年で20倍という伸びを見せています。ケアレスミスや管理不備への対策とは別の手を打つ必要があります。

漏えい原因における不正アクセスの比率

2010年 1.0 %
2011年 1.2 %
2012年 1.5 %
2013年 4.7 %
2014年 2.4 %
2015年 not available
2016年 14.5 %
2017年 17.4 %
2018年 20.3 %

情報漏えい事故が起こった後の対応方法

事故が起こった後の対応の善し悪しも、ユーザーや社会の受け取り方を大きく変えます。独立行政法人情報処理推進機構(IPA)は、情報漏えい事故が起こった企業や組織に向けて「情報漏えい発生時の対応ポイント集」を公開していますが、過去に個人情報漏えい事案に対処した経験がある練度の高いCSIRTチームが社内に存在でもしない限り、被害実態調査やその後の対策などは、専門セキュリティ企業に相談するのがもっとも安全で一般的な方法です。

セキュリティ業界では、セキュリティ緊急対応サービスに相談が来る曜日や時間に傾向があると言われています。それは、「金曜日の午後」「連休前の午後」です。つまり、事故は週前半または半ばに発生していたが、なんとか自分たちで解決できないかもがき苦しんだ後、最後の最後であきらめて、「休日を挟む前に」セキュリティ企業へ連絡をするからです。自分たちで精一杯手を尽くした努力も空しく諦めざるを得ないとは、身につまされる話です。

しかし、時間が経過すればするほど、調査に必要なエビデンスが失われることもあります。情報漏えい事故が起きたら、信頼できる専門企業にすぐ相談してください。

情報漏えい事故の報告書と収束までの流れ

専門セキュリティ企業の協力の元、デジタルフォレンジックによる原因や被害範囲などの調査が行われ、一定の社会的インパクトがある情報漏えいであれば、報告書を公開します。場合によっては記者会見を行い、調査分析のための第三者委員会が組織される場合もあります。

インシデントの全容を解明した報告書作成には数か月かかるかもしれませんが、その前にまず事件の概要、情報漏えい対象者の範囲や救済措置などについては、なるべく早く情報公開することが大事です。

速報第一報に限らず、情報漏えい事故の調査報告書に必要な項目は下記のとおりです。


・漏えいした情報の内容

・漏えい件数

・原因

・現在の状況

・今後の対策


重要なのは、速報公表まであまり時間をかけないことです。時間がかかるほど、どんなにその調査が合理的で必要なものであっても、SNSなどで「事故を隠そうとしたに違いない」といった、批判の対象となることがあります。

また、第一報につづく第二報では、内容の大きな修正があってはなりません。特に第二報で漏えい件数が大幅に増えていたりすると、「事故を小さく見せかけようとした」「初動対応に失敗した」などの誤ったイメージすら与えかねません。速報では、論理的に最大の漏えい可能性がある件数を、必ず記載してください。詳細な調査を待たずとも、速報で最大値推定を出すのは難しくありません。

企業側は、組織の透明性を確保しながら、とにかく誠意を見せることが重要です。たとえば報告書の「今後の対策」の欄に、どんな対策を実施するかという詳細を公表する必要はありません。しかし、大まかな予定であっても「いつまでに何々という対策を実施する」とマイルストーンを設置して計画を可視化することで、ステークホルダーやユーザーの心証は好転します。

情報漏えいを予防する対策

これまで述べてきたように、情報漏えいには性質の異なる複数の原因があり、原因毎に予防対策は異なります。

まずは従業員によるノートPCやUSBメモリの紛失などを減らすために、セキュリティリテラシーを向上させるアウェアネストレーニングが有効です。IPAが刊行する「情報漏えい対策のしおり」など、無料の教材や動画も多数公開されています。同時に、ノートPCやUSBメモリの管理規定も定めましょう。

また、近年増加しているAWSのようなクラウドサービスの設定不備による事故の対策として、設定ミスや、現在の設定のリスクを網羅的に検知するサービスも提供されるようになっています。

先に挙げた通り、不正アクセスによる情報漏えいは過去約10年で20倍という驚くべき増加を見せています。サイバー攻撃の侵入を許す穴がないかどうかを探す脆弱性診断や、脆弱性を利用してひとたび侵入された場合、何がどこまでできてしまうのかを検証するペネトレーションテストも、不正アクセスに対する極めて有効な対策方法です。

新しい社員の入社や退職など、組織は日々変化し、業務やシステム構成・Webアプリケーションも進化を続けます。昨日までは安全だったWebアプリケーションに、今日新しい脆弱性が見つかることもあります。上記に挙げた対策はいずれも一度実施したら終わりではありません。定期的に継続することで真の効果を発揮します。

そもそも事故が起きないことが一番素晴らしいことですが、せめて「事故は起こったものの打てる手はちゃんと打っていた」と言えるようにしておくべきです。

まとめ

・個人情報保護法では、個人情報の漏えいを起こした組織が講ずるべき措置が定められている。
・情報漏えい事故の深刻度は、漏洩した件数だけでなく、漏えいした情報の内容にも大きく左右される。
・情報漏えいは、悪意に基づく不正アクセスのほか、設定不備や管理上の不注意が原因で発生することもある。
・情報漏えい事故が発生したら、速やかに信頼できる専門セキュリティ企業に依頼するのが有効。
・情報漏えい事故に関する事実の公表は、組織の透明性を確保しながら誠意をもって臨むことが重要。
・情報漏えいの予防には、従業員のセキュリティリテラシー向上教育、クラウド設定不備の検査、脆弱性診断やペネトレーションテスト等の対策がある。

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


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

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

ソースコード診断の必要性とは?目的とメリットを紹介

Share

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

WEBアプリケーションは、プログラムの集合体であり、 ソースコードとはシステムやWebアプリを動かすコンピュータプログラムのことです。 このプログラムの集合体は現在では人間から読み書きしやすい言語で書かれていることが多くWebアプリケーションは人間にも読みやすいプログラムのテキスト、ソースコードの集合体と言い換えることができるようになっています。

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことですが、その中でも診断対象によりさまざまなサービスがあります。この記事では、その中の「ソースコード診断」を取り上げて、その定義、特徴、メリット、目的などを紹介します。

ソースコード診断とは?

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことを指します。
診断対象により、さまざまな脆弱性診断サービスがあります。

まず、企業が開発したWebアプリケーションが挙げられます。
問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。
次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査するネットワーク診断があります。
そのほか、近年増加の一途をたどる スマホアプリケーションや IoT機器を対象とした脆弱性診断もあります。

このうち、ソースコード診断とは、アプリケーションのソースコード(開発者が書いたプログラム)を解析して、セキュリティ上および品質上の問題をコーディングレベルで検査する診断のことをいいます。

ソースコード診断

ソースコード診断には、ツールを用いて自動的に処理するツール診断(自動診断)と、セキュリティエンジニアが目視で確認する手動診断があります。

効率的に網羅性を確保できる自動診断ツールの支援は欠かせません。

一方手動診断は、機械的に検出できず、人間による判断が必要な脆弱性を発見します。手動のみで行う場合もありますが、多くはツール診断と組み合わせて網羅性と精度を上げていきます。

ソースコードを開示するため、ソースコード診断はホワイトボックステストと呼ばれます。これに対して、ソースコードや設計書を見ずに、システムの外部からアクセスして脆弱性や動作を検証する方法をブラックボックステストと呼びます。

ソースコード診断の特徴とメリット

ブラックボックステストでは検出が難しい脆弱性がソースコード診断なら検知できる場合があります。具体的には 「ソースコード診断で検出できる脆弱性」で後述します。

ブラックボックステストは、すでにソフトウェアあるいはシステムが機能していることを前提とした、リリース前あるいはリリース後に実施します。これに対して、ソースコード診断はその前段である開発プロセスから実施できるため、テスト結果を受けてプログラムを修正することが可能です。

開発の手戻りを減らすことでコストや工数削減につながります。詳細は「ソースコード診断の有効性」を参照してください。

ソースコード診断を実施する目的

ソースコード診断の目的は、プログラムに作りこんでしまった脆弱性を網羅的に検出することです。開発時に繰り返し実施し、開発者が修正していく運用が想定されています。

ソースコード診断の有効性

ソースコード診断は開発段階初期から実施可能です。リリース直前やリリース後に脆弱性が発見される可能性を抑えることで、より効率的で信頼性の高いシステム開発が可能になります。

CPE-Coreとはソースコード内の脆弱性と品質面の問題を検査する当社の自動静的解析ツールです。

システムのセキュリティを確保する方法

開発(Dev)、運用(Ops)、セキュリティ(Sec)を一体にしてシステムライフサイクルを回すDevSecOpsという考え方が注目を集めています。DevSecOpsとは、開発の全工程において、開発チームと運用チームが相互協力し、その一環にセキュリティを組みこむことで、アプリケーション開発のセキュリティを確保していく考え方のことをいいます。ここでは、開発プロセスのどこで、セキュリティを確保するための施策を実施するか説明します。

DevSecOpsにおけるセキュリティ対策

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。
セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

一般的なセキュリティ対策として多くイメージされている「Webアプリケーション脆弱性診断」は「テスト」「リリース」工程におけるセキュリティ対策の一つ。
その一つ手前工程の「製造」工程におけるセキュリティ対策の一つが「ソースコード診断」です。

セキュアプログラミング

ソースコード診断の前に、そもそもシステムの設計・開発段階で、開発者が脆弱性を作りこまないようにする手法があります。これをセキュアプログラミングと呼びます。セキュアプログラミングで開発し、本当に脆弱性を作りこんでいないかどうかソースコード診断でチェックします。

ソースコード診断で検出できる脆弱性

一般的なWebアプリケーション脆弱性診断(ブラックボックステスト)では検出しにくい脆弱性も、ソースコード診断(ホワイトボックステスト)では発見できる場合があります。
たとえば未使用のコード、ログファイルによる情報の露出、エラーメッセージによる情報の露出などは、ソースコードを直接確認することで検知可能になります。

以下はWebアプリケーション診断とソースコード診断の両方の観点で検出可能な脆弱性です。
ここでは代表的な脆弱性(セキュリティバグ)について説明します。これらのバグを突く攻撃の名称としても用いられています。

バッファオーバーフロー

プログラムを実行する際に確保するメモリ上のバッファ領域に対して、このサイズを超過するデータを書き込めるようになっているバグです。攻撃者は超過する部分に不正なプログラムを書いて実行します。

フォーマットストリング

プログラム中の、書式設定用の関数(フォーマットストリング)の引数の処理に関するセキュリティバグです。正しくは、引数として不正な値が入力された場合には、処理を止めてエラーメッセージを返さなければなりません。

SQLインジェクション/コマンドインジェクション

SQL(データベースを定義、操作する言語)文や、その他のコマンドが入力された場合でも、エラーにせずに処理してしまうバグです。攻撃者の観点からは、コマンドを注入(インジェクション)する形になるため、この名が付いています。攻撃の入り口はアプリケーション上の通常の入力欄で、ここに不正な値を入力することで攻撃を開始します。

クロスサイトスクリプティング

悪意のあるスクリプト(プログラム)をユーザのコンピュータに注入して、複数のWebサイトをまたいで(クロスサイト)行う攻撃や、その攻撃で利用される脆弱性を指します。

まとめ

・ソースコード診断はソースコード(開発者が書いたプログラム)を解析し、セキュリティ上の問題点を発見する
・開発フェーズの初期から実施することで、リリース直前に脆弱性が発見されるようなスケジュールに影響するトラブルを防止する
・一般的なWebアプリケーション脆弱性診断では検出しにくい脆弱性も、ソースコード診断を実施することで開発段階から検出ができる

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


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

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