インフラ・セキュリティのコスト最適化と安心の大規模Webサイト運用を実現!
大規模CMSセキュリティ強化
大規模なWebサイト・CMSのセキュリティでこんな課題はありませんか?
大規模なWebサイト・CMSの主なセキュリティリスクと影響

リスク1
個人情報や機密情報の漏洩
セキュリティの脆弱性を突かれ、ユーザーの個人情報や企業の機密情報が不正に取得されるリスクがあります。また、社内や関連会社など内部不正による情報漏洩響や不注意による情報漏洩にも注意が必要です。 影響として、情報の悪用や詐欺、企業のブランドイメージの低下、法的責任・賠償責任などが考えられます。

リスク2
ランサムウェアによる身代金の要求
ランサムウェアはサイトやシステムを暗号化し、復元のための身代金を要求するものです。支払わない場合、データの損失や長時間のWebサイトの停止が起こり得ます。

リスク3
ウィルス・マルウェアの感染やサイトの改ざん
不正なスクリプトやコードがサイトに埋め込まれることで、訪問者の情報を盗んだり、他のサイトへのリダイレクトなどの被害が発生します。これにより、サイト利用者や企業のサービスを利用しようとする人からの信頼が失われ、企業への評価が低下します。

リスク4
DDoS攻撃等によるサイトの停止
大量の不正なトラフィックでサイトを過負荷にさせるDDoS攻撃は、サイトの一時的な停止や長時間の停止を引き起こす可能性があります。これにより、ビジネスの損失やサイト利用者の不満が生じる可能性があります。
大規模Webサイトでありがちな、CMSのセキュリティで考慮するべきチェックポイント
Point1
つくりっぱなしの状態になっていないか
初期にCMSでWebサイトを構築したままの状態になっていませんか。CMSや関連するソフトウェアなどはサポートされる期間などが定まっているため、中長期的な計画を立ててバージョンアップなど最新化の対応が必要です。対応していない場合、既知の脆弱性が存在した状態となり、サイトの改ざんなどの攻撃を受ける可能性が高くなります。
Point2
管理画面が一般公開できるエリアにないか
CMSの管理画面のログイン画面が誰でもアクセス可能な状態となっていませんか。ログイン時にアカウント、パスワードを入力するとしても推測されたりテストで用意していたアカウントでログインされるリスクが大幅に高くなります。 例えばWordpressであれば、/wp-admin/ は IP制限を行うまたは、2段階認証を必須とするなどしなるべく利用できる個人を特定した上で制限する必要があります。 また、オープンソースの場合であれば公開用のサイトのドメインと管理画面のドメインを分けるなどし、よりセキュリティ強化する(攻撃者に推測されにくくする)必要があります。
Point3
運営体制、チェック体制が明確になっているか
会社組織としてセキュリティに関する責任・担当などが明確になっていますか。技術的なことはもちろんですが、運営体制を明確にしておくことも重要です。体制が整っていない場合責任の所在が曖昧となり結果としてトラブルにつながることがあります。
Point4
ヒューマンエラーの対策がされているか
まだ公開してはいけない情報をサイトに掲載してしまったり、サイトでは本来必要のない個人情報を含むファイルを誤ってアップロードしてしまうと、場合によっては損害賠償や大きな機会損失や生む可能性があります。 うっかりミスは完全になくすことは難しいため、二重チェックして初めて公開を許可する、複数がチェックする体制をつくるなど、ミスがあっても安全が確保される対策をとっておくことが重要となります。
Point5
CMSを利用するユーザのPCセキュリティが保護されているか
CMSやWebサイトのセキュリティ対策だけでなく、サーバに接続したりCMSを利用するすべてのユーザのセキュリティ対策は行われていますか。利用者のPCがマルウェアなどに感染している場合、CMSの管理画面やFTPなどから感染ファイルをWebサイトにアップロードしてしまう可能性があるためです。運用更新を外部委託している場合は外部委託先の利用者のPCのセキュリティ保護が問題ないかも確認が必要となります。
Point6
個人情報や機密情報の利用がされているか
そもそも個人情報の保持や機密情報の利用がされているか把握していますか。Webサイト上での利用が不要なものであれば、個人情報や機密情報がWebサイトやサーバ上にアップロードされない運用・仕組みとしておくことが重要です。 問い合わせフォームなども古い仕組みではCSVファイルをサーバ内に書き出すような場合もあるため、設定によっては個人情報が誰からでも取得されてしまう可能性があります。
Point7
定期的なセキュリティチェックを行っているか
定期的なセキュリティチェック(脆弱性試験など)を行っていますか。1度脆弱性試験を実施済みで問題なかったとしても、新しい攻撃手法や新しく見つかるセキュリティホールなどにより、問題が発生する可能性があります。 Webサイトでのリスクに応じて1か月に1回から、少なくとも1年に1回は脆弱性試験を実施する必要があります。
『大規模CMSセキュリティ強化』で解決できること
01:セキュリティ対策に関する知識が少なくても網羅的に考慮・対策ができる
たんにWAF単体を導入するというものではなく、セキュリティリスクを最小化するために実施するべき対策ポイントを網羅したパッケージ化して提供していますので、 対策の不足の心配がありません。
02:都度依頼をしなくても継続的なチェック・バージョンアップが行われる
インフラ環境やCMSを含め継続的に安心して利用できるために、バージョンアップや定期的な脆弱性チェックの対応を含んでいます。
03:自社のリスクに合わせてカスタマイズすることで費用を最適化できる
すべてを網羅する対策も可能ですが、サイトの内容によってはオーバースペックとなり費用だけが高くなってしまう場合があります。リスクと費用の判断から、カスタマイズにより必要なセキュリティ対策のみを有効化することが可能です。
04:自社のセキュリティチェックやエビデンス提出に対応してもらえる
社内ルールとしてWebサイト等システムを構築のセキュリティチェックやエビデンス提出が必要な場合があるかと思います。個別での対応となりますが、チェックシートへの回答やエビデンスの提出を行うことも可能です。
05:インフラからソフトウェア・Webサイトまでサービスとしてもらえる
本パッケージは複数のインフラやサービス・ソフトウェアを組み合わせて提供するものです。個別に各サービス等との契約・更新等の手続きは不要であるため、管理や請求等のやり取りが煩雑になりません。
事例から見る標準構成パターン
A. 全体静的サイト用パッケージ(企業サイト等)
B. 部分動的サイト用パッケージ(製品検索を含むサイト等)
C. 全体動的サイト用パッケージ(ログイン機能を含むサイト等)
A.全体静的サイトパッケージ構成例
