知っておきたいwebセキュリティの基礎と代表的な攻撃パターン【2024年最新版】

webサーバーは、メールサーバー、FTPサーバー、ファイルサーバーなどの数あるインターネットのサーバーの中で、最もセキュリティ攻撃に関する報告や報道が多いサーバーとなっています。
これはインターネットの商用利用解禁以来、webが手軽で便利な情報伝達のインフラとして広く受け入れられてきたことが背景にあります。

このため、webサイトは提供情報の書き換えや、個人情報の流出の舞台として頻繁に取り上げられています。
テレビなどのマスメディアでwebサイトの攻撃を受けた大企業の責任者が記者会見の席で深々と頭を下げている光景をご覧になった方も多いでしょう。

こうしたwebサイト上のセキュリティ攻撃は、知名度の高い大企業だから狙われるというものではありません。
愉快犯の多くはサイトをランダムに標的にしますし、セキュリティ対策が未整備な中小企業を攻撃したほうが、クラッキングの成功率も高い傾向にあります。
また、いったん被害にあってしまった場合の信用の失墜からの回復も困難な場合が多いのです。

そんななか、中小企業がセキュリティ対策を行うときに多くは外部のアウトソーシングサービスを使いますが、自社のシステムの現状も把握せずにセキュリティ業者に丸投げしてしまうのはあまりおすすめできません。
セキュリティ対策は100社あれば100社に合わせた最適な対策方法があります。
自社にとって最適な対策方法を見つけるためには、発注者側でもwebセキュリティの基礎と代表的な攻撃パターンを理解して、自社にとって最適な防御方法を納得の上で導入することが必要です。

webサイトの多くは、自社の顧客との窓口として使われています。
コーポレートサイトの顧客対応窓口であったり、ECサイトで物販をしていたりなど、顧客がwebサイトにアクセスして入力した個人情報は、ブラウザのフォームを通じてデータベースに格納されます。
もし、そのwebブラウザで提供しているwebサーバーにセキュリティ上の欠陥があれば、ブラウザ経由でデータベースに不正アクセスが可能です。
webサーバーに不正アクセスされ、格納されている個人情報を取得されれば、顧客の「個人情報漏えい」などの重大事件となってしまいます。

いったん個人情報が外部に流出してしまうと、フルネームや連絡先、さらにクレジットカードなどの極めて重要な個人情報が悪用されてしまいます。
個人情報は不正アクセスをしたグループが悪用するだけでなく、高値で売買されることも多いので、そうなった場合には実行グループを突き止めたとしても被害の拡大を防ぐ方法はありません。

いったん、クレジットカードの流出を含む個人情報漏えい事件を起こしてしまうと、顧客への謝罪を含めて事態の収拾が一段落した後でも、サイトの決済手段としてクレジットカードを使うことができなくなる場合があります。
これは個人顧客がクレジットカードの支払いなどが不可能になった場合に、カードの利用を止められるなどのペナルティを受けるのと同じです。
いったん「個人情報流出」といった事件を起こしてしまうと、クレジットカード会社からサイトでクレジットカード決済を提供するサービスを展開するために必要な信用力が十分でない、と判断されてしまうためです。

会社の規模や社会的信用の度合いによってこのペナルティは解除されますが、中には、数年経ってもクレジットカード決済を行うための審査に通らないというケースもあります。
残念ながらいったん事件を起こしてしまった後、中小企業は大手企業に比べて再審査に通らないケースが多いので、十分に注意しましょう。

セキュリティ攻撃を受けてしまった場合、サイトの運営者はもちろん被害者であるわけですが、同時に事件の調査報告などでさまざまな関係者に説明責任が発生します。
通常、こうした非日常的な業務は企業にとって大きな負担となります。

webサイトのセキュリティ被害は、運営側としては風評被害を拡大したくないという思いもあり、できれば内密に処理したいという意向が働きます。
しかし、個人情報が流出した場合などは、盗難事件に相当しますので警察に連絡をする義務があります。

相談レベルで住む場合には「警視庁サイバー犯罪対策課」などの専門窓口に連絡を取ればよいわけですが、事件となった場合には110番通報し、捜査員による事情聴取などに対応していく必要があります。

単なる愉快犯ではなく、怨恨など事件性が高いと判断された場合には、サイトの運営情報や漏えいした顧客情報を開示する必要なども出てきます。

DoS攻撃などでwebサーバーを故意につながりにくくするなどの被害を受けた場合だけでなく、個人情報の漏えいなどが発生した場合には、いったんサイトの公開をやめて安全性が確認されるまでサイトのセキュリティ調査を実施する必要があります。
その結果は、被害にあった顧客はもちろんのこと、そのとき直接的に被害にあわなかった顧客に対しても再発の可能性の有無などについて納得の行く説明をする必要があります。

自社で手に負えない場合には、セキュリティ対策専門会社に調査してもらい、その会社と連名で安全性などについての発表をすることが適切な場合もあるでしょう。
事件が起きた場合には、こうした調査を速やかに行い抜本的な対策を公表する以前に、現在の状況と二次災害の有無などについてwebサイトや記者会見などで積極的に情報を公開することが大切です。
公開が遅れれば遅れるほどユーザーの不信感は高まり、サービスの再開の道が険しくなってきますので注意しましょう。

個人情報漏えいなどの重大なwebセキュリティ問題では、社会的な信用失墜などにとどまらず、顧客から損害賠償の請求を起こされることもあります。
弁護士がユーザーの代表者の窓口となって集団訴訟を起こすというケースもあり、そうした場合の賠償金の金額はかなりの高額になることは避けられません。

例えば １人３万円の補償を行うとして１万人の顧客情報が流出してしまった場合には、30,000円×10,000人＝３億円という金額が必要になってきます。
もちろん対象ユーザーへの賠償額だけでなく、事務手続きをすすめるための費用やこちら側の弁護士費用などを考えるとその金額を遥かに上回る額が必要になります。

被害を受けたユーザーや関係者への責任ある対応が終了し、サービスを再開したいとしても、いったんネットに広がってしまったマイナスのイメージはなかなか払拭できません。
マイナスのイメージは、既存会員の減少や、新規会員獲得の伸び悩みなどに顕著に現れます。
いくら営業的な努力を行い、サイトのサービスを充実させてもいったんwebセキュリティ絡みで大きなマイナスイメージがついてしまうと、数年に渡ってこうした影響が続く場合があります。

SNSなどで話題になってしまう期間というのは比較的短期に過ぎ去ります。
問題なのは検索エンジンで社名やサービス名を検索したときに、上位表示されるのがサイトそのものの情報ではなく、個人情報漏えいなどの大きなwebセキュリティ絡みの事件になってしまうことです。

これについては、地道にユーザーの信頼の回復するのを待ちながら、より良いサービスを継続していくという以外に対策方法はないと言えます。

いったん大きなwebセキュリティ上の問題を起こしてしまうと、その対応にかかる時間や金額なども莫大ですし、失ったユーザーの信用を回復するまでにはかなりの時間もかかるということがお分かりいただけたと思います。
こうした事態に陥らないためには、webサイトへの攻撃を未然に防ぐ努力が欠かせません。

まずはwebサイトを運営する担当者自身が、「ある日突然寝耳に水」という状態にならないように、定番のweb攻撃パターンを知っておく必要があります。

webサイトのフォームから文字を入力すると、多くの場合そのデータはwebサーバーと連動しているデータベースサーバーに伝えられます。
例えば「スマホケース」と入力してiPhoneなどのスマホのケースが画像付きで表示されるのは、「スマホケース」という文字列をデータベースに照合して詳細データを引っ張ってきているからです。
この命令を伝えるのがSQL（Structured Query Language）です。

この命令文に悪意のあるコマンド、例えば、「スマホケース　の詳細データを表示せよ」ではなくて「スマホケース　という文字列を含むデータをすべて消去せよ」などの命令を紛れ込ませると、データベースに重大な障害を与えることになります。
これをSQLに悪意ある命令を挿入（インジェクション）する「SQLインジェクション」と言います。

SQL インジェクション攻撃により発生し得る被害としては「データベースに蓄積された非公開情報の閲覧」「個人情報の漏えい」「データベースに蓄積された情報の改ざん、消去」「webページの改ざん」「パスワード変更」「システム停止」「システムの乗っ取り」「ほかへの攻撃の踏み台としての悪用」などがあります。

webサイトと連動してデータベースを稼働させている場合に標的となります。
現在はコーポレートサイトもWordPressなどのCMSなどで構築している場合が多いので、「うちは、ECサイトなどは展開していないから関係ないかな…」と思い込まないようにしましょう。
少なくともWordPressを使っていれば「SQLインジェクション」の標的になります。

その他、ECサイト、会員制サイトなど、データ利用にリレーショナルデータベースを使っている場合にはSQLを使用してデータを活用しますので、標的対象となります。

「OSコマンド・インジェクション」は、webサーバーを動かしているオペレーションシステムである、UNIX（リナックスなどの各種ディストリビューションを含む）やWindowsサーバーなどに、悪意あるコマンドを送信して被害を引き起こします。
今見てきた「SQLインジェクション」が、webサイトと連動したデータベースサーバーを攻撃する手法であったのと似ています。
「SQLインジェクション」がwebサイトを経由して、連動しているデータベースサーバーを攻撃したのに対して、「OSコマンド・インジェクション」では、webサイトを経由してwebサイトやデータベースサーバーを動かしているインフラの大元であるオペレーションシステムを攻撃するので被害も甚大になります。

OSコマンド・インジェクション攻撃により、発生し得る被害としては、「サーバー内ファイルの閲覧、改ざん、削除」「重要情報の漏えい」「設定ファイルの改ざん」「不正なシステム操作」「意図しないOSのシャットダウン」「不正ユーザーアカウントの追加」「不正なプログラムのダウンロード、実行」「ウイルス、ワーム、ボット等への感染」「バックドアの設置」「他のシステムへの攻撃の踏み台」「サービス不能攻撃」「迷惑メールの送信」があります。

運営主体やwebサイトの性質を問わず、オペレーションシステムレベルの操作をwebサイト経由で実施しているサービスで狙われます。

例えば、WordPressなどの標準的なCMSのようにwebサイト内でPHPなどの言語を使ってファイルを更新している場合には、ファイル操作で「OSコマンド・インジェクション」は生じませんが、何らかの理由で、ファイルの更新をwebサイトからオペレーションシステムに渡してOSレベルで行っているような仕様になっている場合にはその部分に悪意のある「OSコマンド・インジェクション」を行うことが可能な場合があります。

webアプリケーションを実行するために、外部からのコマンドのパラメータに、webサーバー内部のディレクトリ名を直接記述している場合があります。
通常の場合ですとファイル名の指定は、「今アクセスしているwebページと同じ場所の○○ファイル」とか「今アクセスしているwebページから一つ上の階層の○○ファイル」などの相対的な場所を指定しているので、危険度は高くありません。これは家の場所を説明するときに「「○○駅の北側に住んでいます」というようなものです。
これに対してディレクトリを直接記述するというのは、具体的に「〇×町△□番地」という住所を伝えた状態に相当します。
ですから、このディレクトリ（番地）に脆弱性がある場合には攻撃者に任意のファイルを指定され、webアプリケーションが意図しない処理を行ってしまう可能性があります。
このようなディレクトリ情報を悪用した攻撃手法が「ディレクトリ・トラバーサル攻撃」です。

この脆弱性を悪用した攻撃により、発生し得る被害には「サーバー内ファイルの閲覧、改ざん、削除」「重要情報の漏えい」「設定ファイル、データファイル、プログラムのソースコード等の改ざん、削除」があります。

何らかの理由で、外部からのパラメータにwebサーバー内のファイル名を相対的場所ではなく、直接指定しているwebアプリケーションで生じる可能性があります。

セッションとはユーザーがwebサイトに訪問したときにwebサイトから離脱するまで同一ユーザーであることを情報としてサーバーが保持しておくことです。
webブラウザでは最初のページでIDとログイン情報を打ち込んでも、技術的にはページが遷移するとログアウト状態になってしまいます。
ページが変わるたびに認証してもらうのは大変な手間になりますので、最初のページで打ち込んだ情報と同一ユーザーであることをサイトから離脱するまでサーバー側で追跡するのですが、この同一性の追跡に割り込んで悪意ある攻撃をするのが「セッション管理の不備攻撃」です。
割り込んだあと、悪意あるユーザーがあたかも自分が正規のユーザーであるように「なりすまし」することができてしまします。

セッション管理の不備を狙った攻撃が成功した場合の被害は、「なりすまし」で想定されるあらゆる被害となります。
具体的には「クレジットカード情報を悪用して無駄なショッピングを際限なく行う」「メッセージ機能を利用して正規のユーザーに不利益になるようなメッセージを撒き散らす」などです。

会員制サイトなど、最初の画面でログイン機能を持つwebサイト全般が狙われる危険性があります。
セッション管理では個人情報を乗っ取られるという被害につながりますので、次のようなサイトでは特に注意が必要です。
「ネットバンキング」「ネット証券」「ショッピング、オークション」 「転職サイト」「コミュニティサイト」「webメール」「結婚相談所サイト」。

クロスサイト・スクリプティングとは、悪意のあるスクリプトを公開されているwebサイトに埋め込んでしまう手法です。
例えば、検索結果の表示画面や個人情報登録時の確認画面、掲示板など、webページに何らかの出力を行うときに、出力を行う直前にスクリプトを忍び込ませ悪意あるコマンドを実行することを「クロスサイト・スクリプティング」と言います。

クロスサイト・スクリプティング攻撃により、発生し得る被害は「表示画面で偽情報が出てくる」「偽情報の流布」「偽情報表示ページでのフィッシングサイトなどへの悪意ある誘導」「ユーザーのCookie の不正取得」「Cookie情報を利用したなりすまし」「Cookieに保存された個人情報流出」などがあります。

Cookie を利用してログインのセッション管理を行っているサイトや、ログイン画面、個人情報の入力を促す画面、掲示板などを持っているサイトで、例えば次のようなページに注意が必要です。
「会員登録、アンケートなどの入力内容を確認させる表示画面」「誤入力時の再入力を要求する画面」「検索結果の表示」「エラー表示」「ブログ、掲示板などのコメントの反映」。

webサイトに正規ログインしたユーザーは、サイトに対してさまざまなリクエストを実行します。
通常ですとそのリクエストは、検索結果の表示であったり、申し込みボタンからのメッセージの送信であったりします。
しかし、利用者が意図した検索結果の表示やメッセージの送信などの正常なリクエストであるかどうかを識別する仕組みを持たない場合、そこから悪意のあるリクエストを受け入れてしまう場合があります。

このようなユーザーが予期しない処理を実行させられてしまうことを利用した攻撃を、「CSRF攻撃」と呼びます。

CSRF 攻撃により次のような被害が生じる可能性があります。
「ログイン後ユーザーのリクエスト悪用」「不正送金」「ユーザーが意図しない商品購入」「ユーザーが意図しない退会処理」「情報の改ざん、新規登録」「管理者画面、パスワードの不正な変更」「掲示板への不適切な書き込み」など。

セッション管理で、Cookie、SSLクライアント認証などを用いているサイト全般。
特に、ネットバンキング、ネット証券、ショッピング、オークションなどの金銭処理が発生するサイトは要注意です。

webブラウザを利用した通信には、アドレスバーの最初のところに「http」とあるようにHTTPというプロトコル（通信の約束事）を使っています。
このとき送信されるHTTP情報には、ユーザーからのコマンドやwebサーバー側で必要とされる情報を記載したヘッダ部分と、通常のホームページの画面に出てくるような画像やテキストなどのボディ部分があります。

つまり、HTTPのヘッダ部分には、webサーバーが情報を処理するための重要なデータがたくさん詰まっているのですが、この部分に不正なコマンドなどを忍び込ませる攻撃手法を「HTTP ヘッダ・インジェクション攻撃」と呼びます。

「HTTP ヘッダ・インジェクション攻撃」により、発生し得る被害は、「表示画面で偽情報が出てくる」「偽情報の流布」「偽情報表示ページでのフィッシングサイトなどへの悪意ある誘導」「ユーザーのCookieの不正取得」「Cookie情報を利用したなりすまし」「Cookieに保存された個人情報流出」などがあります。

Cookie を利用してログインのセッション管理を行っているサイトや、サイト内にリバースプロキシとしてキャッシュサーバーを構築しているwebサイトでは「HTTP ヘッダ・インジェクション攻撃」に注意する必要があります。

webアプリケーションの中には、フォームからのデータ入力をデータベースサーバーに引き渡す以外に、ユーザーが入力した商品申し込みやアンケート等の内容を、特定のメールアドレスに送信するものがあります。
このアドレスはwebアプリケーションのプログラムの中に設定されていますので、通常は外部のユーザーが変更することはできませんが、この部分に不備があると、実装によっては、悪意あるユーザーがメールの送信先を自由に指定できてしまう場合があります。
このような攻撃を、「メールヘッダ・インジェクション攻撃」と呼びます。

メールヘッダ・インジェクション攻撃が行われた場合、発生し得る被害としては、「重要なメール情報の抜き取り」「迷惑メールの送信」などがあります。

「問い合わせページ」や「アンケート」などでユーザーが入力した内容を管理者宛にメールにて送信する場合に「メールヘッダ・インジェクション攻撃」が生じる可能性があります。

「クリックジャッキング」とはその名の通り、クリック時のイベントをジャックします。
具体的にはwebサイトの正常なリンクやボタンなどのマウスクリックの対象となるオブジェクトを隠蔽・偽装してユーザーの不正なクリックを誘います。

クリックジャッキング攻撃により、発生し得る被害には「ログイン後ユーザーのリクエスト悪用」「不正送金」「ユーザーが意図しない商品購入」「ユーザーが意図しない退会処理」「情報の改ざん、新規登録」「管理者画面、パスワードの不正な変更」「掲示板への不適切な書き込み」などがあります。

ユーザーがログインした後の各種リクエストの送信などがマウス操作で行われる場合にクリックジャッキング攻撃による影響を受ける可能性があります。
もちろんマウス操作をしないでwebブラウザをユーザーに使ってもらうというインタフェースは現実的ではありませんが、特にマウス操作のみで実行可能な処理が、金銭的な処理であったりユーザー情報の変更であったりする場合にはクリックジャッキングに注意して実装する必要があります。

「バッファオーバーフロー」の「バッファ」とは、コンピュータでデータを一時的に記憶する場所を指します。
この場所では本来必要なデータを必要な容量だけ確保して処理しますが、意図的にこの場所を「オーバーフロー」＝あふれさせることで、プログラムに誤動作を引き起こさせます。

プログラムはメモリ容量があふれた場合、正常化した直後にその以上が起こった場所から元の想定されていた処理の続きを行おうとします。

このとき、意図的にオーバーフローを引き起こすことを仕組んだ場所に悪意あるプログラムを仕込んでおく攻撃を「バッファオーバーフロー攻撃」と呼びます。

バッファオーバーフローにより、発生し得る被害としては「プログラムの異常終了」「意図しないサービス停止」「悪意あるコード実行」「ウイルス、ワーム、ボット等への感染」「バックドアの設置」「バッファオーバーフローを引き起こした地点から他のシステムへの攻撃」「重要情報の漏えい」などがあります。

バッファオーバーフローは C、C++、アセンブラなどの直接メモリを操作できる言語でwebサイトのプログラムを作成している場合に起こります。

webセキュリティ問題で求められる対策は、ブラウザを中心にしたインタフェースの部分の対策だけではありません。
確かにwebブラウザは、セキュリティ的な脅威を「水際対策」で防ぐ重要なポイントです。
しかし、海外からの密入国や密輸入などの水際対策にしても、そうした対策だけでは不十分でより抜本的な対策が常に行われています。

webセキュリティ問題も同様で、ブラウザレベルでの対策と同時並行で、下記のようにwebサイトやネットワークそのものをもっとセキュアに設定・運用・防衛していくことが求められています。

DNSとは、ドメインネームサーバーの略で、webサーバーそのものではありませんが、http://XXXX.jp/ などのローマ字や日本語などを使ってwebサイトにアクセスできるようにする働きをしています。
企業のwebサイトに必ず表示してある代表のメールアドレスも webmaster@XXXX.jpなどのように、名前が付いていますがこの仕組みを管理しているのもDNSです。

つまり、DNSはインターネットの住所管理という重要な役割を果たしているわけですが、このDNSが悪意あるユーザーに乗っ取られてしまうと、利用者が本物のwebサイトの URL を指定しても、そのドメイン名を乗っ取った悪意あるユーザーが用意したwebサイトに接続されてしまいます。

いったんそうした状態になってしまうと、偽情報を入力させて個人情報を取得したり、サイト管理者を装ったメールを送りつけてユーザーの個人情報を提供させたりなどがやりたい放題になってしまいます。

webサイトにアクセスしてきたユーザーは、自分の個人情報を入力して会員専用の有料サービスを享受したり、web通販サイトで商品を購入したりします。
通常そうしたサイトで個人情報を入力するときには、SSL（Secure Socket Layer）や TLS（Transport Layer Security）と呼ばれる暗号化通信を利用します。

こうしたシステムを使用すれば、ユーザーが入力したフルネームなどの個人情報が万が一盗まれてしまった場合でも、情報を盗んだ悪意あるユーザーは、そこに書いてあるデータを解読できません。

ネットワーク上の盗聴は、webサイトそのもので行われるわけでなく、webサイトに至るネットワーク経路上で生じますので、いくら自社サイト側のセキュリティを万全にしていても防ぎきれません。
その前提の下に、個人情報を入力してもらうときには、万が一情報が盗まれてしまった場合でも何が書いてあるか分からない状態にしておくことが大切です。

フィッシング（phishing）詐欺とは、悪意あるユーザーがECサイトなどの本物そっくりの偽サイトを用意して、利用者に認証情報やクレジットカード情報を入力させて情報を詐取するものです。

フィッシング詐欺対策では基本的前提として、webサイトの利用者が「自分が今アクセスしているサイトは本物かどうか」を意識することが必要になってきます。
いわゆる本物サイトのサービス提供者のあずかり知らないところで偽サイトが作られてしまうので、サイト提供者ができることとしては、自社サイトが本物であるということをより明確にアピールすることに限られます。

その中で最も有効だとされるのが、電子証明書で最高ランクの「EVSSL証明書」を採用することです。
運営するサイトにEVSSL証明書をインストールして有効化すると、サイトにアクセスしたときにブラウザのアドレスバーに組織名が緑色で表示されます。
「EVSSL証明書」以外ですと、クリックを何回か重ねて組織情報を確かめる必要がありますが、「EVSSL証明書」を利用すれば最高度に取得の厳格な証明書を使っていることがひと目でユーザーに認識してもらえます。

ここまでwebサイトやネットワークそのものをもっとセキュアに設定・運用・防衛していくことが大切であることを解説し、その具体的な方法を挙げてきました。
事前にこうした根本的な対策を立てることによってwebセキュリティの脅威はかなり減らすことができますが、サイトの公開が住んでしまった後に、サイトで使用しているwebアプリケーションに脆弱性が発見される場合もあります。

こうした運用局面においてwebセキュリティ対策を立てる方法もありますので、しっかりと理解しておきましょう。

webアプリケーションの脆弱性を保護する仕組みとして「WAF」（Web Application Firewall）があります。
WAFはその名の通り、webアプリケーションに関するファイアウォール（防火壁）です。
まず、webサイトとユーザーとの間のブラウザを介するネットワーク通信（HTTP/HTTPS通信）を検証し、悪意ある攻撃や不正な通信を検知した時点で通信を自動的に遮断します。

WAFのように、自動的にネットワークを遮断することでwebアプリケーションの脆弱性からユーザーを守るというワンストップのツールではありませんが、自社サイトに脆弱性があるかどうかを手軽に診断できるツールも公開されています。

「skipfish」はGoogleが無償で公開している、オープンソースのセキュリティスキャナーです。
スキャン対象はwebアプリケーションとなりますので、すでにwebサイトを公開している場合にはこのツールを使えば、webアプリケーションの脆弱性を自動的に検出してくれます。
webアプリケーションに特有のセキュリティホール情報を内部に持っていますので、「SQLインジェクション」や「コマンド・インジェクション」といった、外部からの不正侵入の原因となり得るwebアプリケーションの脆弱性を自動的に検査してレポートしてくれます。

「クロスサイト・スクリプティング」やクロスサイト・リクエスト・フォージェリなどの脆弱性を「skipfish」は単体では検知できないのですが、同じくGoogleがオープンソースで公開している、プロキシサーバー型の脆弱性検査ツール「Ratproxy」を併用することで検出可能です。

「iLogScanner」は、情報処理推進機構（IPA）が提供している不正アクセス検知ツールで、webサーバーのアクセスログから攻撃を検出することができます。
無償で公開され、より精度を増しながら検出対象を広げてバージョンアップが繰り返されています。

最新の「iLogScanner V4.0」では、ネットワークに接続しなくても不正アクセスのチェックが可能となるオフライン版iLogScannerが追加されたほか、不正アクセスの痕跡だけでなく不正アクセスの兆候の有無を検知できる機能も追加されています。

現在、web上にあるサイトの4分の1はWordPressで作られています。
この記事をご覧の方のなかにも、自社サイトはWordPressをベースにしているという方が多数いることでしょう。
WordPressのシェアの浸透は今後も加速すると思われますので、WordPressをベースにしたwebサイト運営のセキュリティの基礎と対策をまとめておきます。

WordPressが世界中で広く受け入れられている大きな理由のひとつが、デザインの充実（テーマ）や機能の拡張（プラグイン）のための部品（ソフトウェア）を、WordPressを提供している団体以外のサードパーティや個人が自由に提供できるということです。
サードパーティや個人が提供するテーマやプラグインは無償で公開されることも多く、実際に有料でコーポレートサイトを外注した場合でも、こうした無料のテーマやプラグインが部品として使われているケースが数多くあります。

WordPressの特徴であるこうした部品は、残念ながらセキュリティホールを持っていることがしばしばあります。
したがって、WordPressを利用するときにはこうした脆弱性対策として、下記の点に留意することが大切です。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、webサイトのセキュリティの基礎と攻撃パターンの例、その対策について解説してきました。
webサイトの攻撃は現在公開しているサービスに深刻なダメージを与え、個人情報流出などが起きてしまえばサイトを閉鎖したり、ユーザーへの損害賠償が必要になったりといった事態にもつながります。

webサイトを公開している運営者としては、この記事で解説してきたような脆弱性を自社のサイトが持っているかもしれない…という意識を常に持つことが必要です。

発注側としては「開発会社はwebサイトをきちんとと作ってくれたのだから、セキュリティに関しても問題はないはず」という思い込みもあるのですが、システムの開発とセキュリティ対策は基本的には別物です。

現在稼働中のwebサイトのセキュリティ対策を何もしていない…という場合にはぜひ下記のような対策を早急に取ってください。


【セキュリティ診断を利用する】
本文中でも無料で実施できるセキュリティソフトをご紹介しましたが、より確実に安全にセキュリティ状態を把握するためには、やはり外部の専門家の知見を参考にしたほうがよいでしょう。

診断期間は約１～２週間で完了し、現在のwebサイトについての診断報告書という形で結果がレポートされます。

【個人情報漏えい保険】
必要なセキュリティ対策を行ったあとでも万が一に備えて保険に加入するケースも増えています。
例えばAIU保険会社の 「個人情報漏えい保険」では個人情報漏えいが発生してしまった場合に、「危機管理コンサルティング補償」「危機管理実行費用補償（オプション）」「賠償金・争訟費用補償」などを補償してくれます。
AIU保険会社「個人情報漏洩保険」

ほかには東京海上日動火災保険の 「個人情報漏えい保険」という商品もあり、個人情報の漏えいに伴う、損害賠償にかかる費用や謝罪広告・見舞品購入などの対策費用を補償してくれます。
東京海上日動火災保険「個人情報漏えい保険」

【Pマークなどの取得コンサル】
国内で代表的なセキュリティ認証には、「プライバシーマーク制度」や「ISMS（情報セキュリティマネジメントシステム「ISO27001」）」などがあります。
こうした信頼のある認定を受けた場合には、もちろん認定にふさわしいセキュリティを完備したwebサイトとしてリニューアルされたわけですし、webサイトにステッカーのようなロゴを張ることができますので、サイトの信頼性も向上します。

こうしたセキュリティ対策は、冒頭にも注意点としてお伝えしたように、開発会社、セキュリティ診断サービス提供会社、セキュリティコンサル会社などに丸投げして済む話ではありません。
実際に自社サイト、自社サービスについて最も詳細を把握している発注側企業担当者が、webセキュリティについて、アウトソーシング先と十分にコミュニケーションを取りながら現状を把握し、最適な対策を施した後、それを維持・運営していくことが求められます

とはいえ、webサイトの運営担当者が通常の業務でセキュリティに関する必要な知識を十分に身に付けていく機会も限られているのが事実です。
「アイミツ」にご相談いただければ、そうしたセキュリティに関するベーシックな部分からの相談も可能な業者を紹介することが可能です。

自社が展開しているwebサービス、公開しているwebサイトのセキュリティ対策を具体化していきたいというご要望をお持ちの場合は、業界の評判などの情報にも精通した「アイミツ」にぜひご相談ください。