セキュリティの
学び場

今回の解説ニュース

約半年にわたる複合的な不正アクセスにより、個人情報やクレジットカード情報などが流出してしまったということです。実際に行われたサイバー攻撃の内容や、PCI DSSの基準を満たしていたにも関わらず、情報漏えいに至った背景について説明します。

今回のインシデントは、同社決済データセンターサーバ内に配置された一部のアプリケーションの脆弱性を利用した不正アクセスにより、個人情報を含む情報の外部流出が判明したということです。原因として、社内管理システムへの不正ログイン、 一部アプリケーションへのSQLインジェクション、バックドアの設置が複合的に行われたことが挙げられています。

対策として、ログイン認証方式の強化と、SQLインジェクション対策として接続元の限定と脆弱性の修正を実施、バックドアの削除を完了しています。また、警察に被害申告を行っており、その他、経済産業省、関東財務局、個人情報保護委員会、JIPDECと情報連携を行っています。再発防止策として、専門のアドバイザーも含めた再発防止委員会を設置するということです。

半年間に渡り行われた複合的な攻撃とは

今回のインシデントでは「社内管理システムへの不正ログイン」「SQLインジェクション」「バックドアの設置」が行われました。脆弱性の詳細については発表されていないので、あくまでも一般論として説明します。

社内管理システムへの不正ログイン

本来は不特定多数のアクセスを前提としていないシステムであるため、セキュリティ対策が十分ではない可能性があります。また、社内管理システムへの接続元を制限していたとしても、メール経由のマルウェア感染などで社内の端末が踏み台にされてしまう可能性があります。今回のインシデントでは、対策としてログイン認証方式の強化や、同一環境下への影響を防止するため、システム環境の分離が行われています。

SQLインジェクション

Webアプリケーションのソースコードに脆弱性が存在していた可能性があります。具体的には、データベースを操作する検索などの機能にSQL文が使われていることが考えられ、外部からの入力値をそのままSQL文の一部に連結してしまっていることが考えられます。今回のインシデントでは、対策として接続元の限定や、脆弱性の修正が行われています。

バックドアの設置

これは先に説明した2つの脆弱性をつかれた結果、不正なファイルをサーバ上に置かれた可能性があります。バックドアの主な目的は、侵入するために悪用できる直接的な脆弱性が修正された後も、侵入を続けられるようにすることです。今回のインシデントでは、対策としてバックドアの削除を行っています。

これら脆弱性がつかれた結果、決済情報等が格納されている3つのデータベースに対し不正アクセスが発生したということです。

セキュリティ基準を満たしていてもインシデントが発生してしまう背景

PCI DSSはクレジットカード情報を取り扱う事業者のセキュリティ基準として満たすべき要件は定められていますが、実施されたセキュリティ対策の内容が適切であるかは確認していないため、認定を受けた事業者でインシデントが発生する場合もあります。セキュリティ対策の品質を担保するためには、属人性の排除が必要です。

セキュリティ基準を満たしているかの実態は別途確認を要する

PCI DSSを含む多くのセキュリティ基準は、満たすべき要件について定められていますが、実態が伴っているかどうかについては別途確認する必要があります。PCI DSSの場合、アンケート形式による自己問診か、認定された審査機関による訪問審査によって、セキュリティ要件がすべて満たされていることを確認します。

確認担当者が判断を誤る事も

いずれの場合も、属人的な確認を行っていた場合は、担当者が判断を誤ってしてしまうことを完全には否めません。その結果、今回のような認定を受けた事業者のWebアプリケーションにSQLインジェクションが発見され、インシデントにつながってしまう現状が考えられます。

属人性を排除する為の標準化、仕組化を目指すことが必要

対策として、セキュリティ対策の属人性を排除するために標準化や仕組化を目指すことが必要です。どれだけ優秀なホワイトハッカーでも人間である以上はミスを犯します。この現実と向き合い、持続可能なセキュリティ体制の構築が求められます。

今回は、セキュリティ基準を満たしていてもインシデントが発生してしまう背景についてお届けしました。PCI DSSやISMSなど様々なセキュリティ基準を満たすことはあくまでも手段であり、本来の目的であるセキュリティ対策が形骸化してしまわないように心がけましょう。