Quantcast
Channel: レンタルサーバーのCPIスタッフブログ
Viewing all 131 articles
Browse latest View live

CSSが適用されない、読み込めない場合がある事象について

$
0
0

昨日まで正常に表示されていたWebサイトが、突然CSSが適用されなくなり、何度かブラウザをリロードすると正常に表示される。
このような事象にお困りの方はいないでしょうか。

実はCPIスタッフブログも、先日なりました。
ある端末では正常に表示され、ある端末では正常に表示がされない....... 現象が再現したり、しなかったり........
しかも適用されないのは一部のCSSという、本当に謎現象が起こりました。

 

CSSが読み込めない解決策

 

キャッシュが壊れていないかや、Viewportの設定が悪いのかなど、色々試したのですが改善できませんでした。
色々考えているうちに、もしや!?と気がつきました。

それはCDN経由(クラウドから)で取得しているBootstrap CSSの取得が、不安定だったためでした。

CDN経由からの取得(改修前)

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css">

 

CSSファイルを自社のWebサーバーに設置し、コードをサーバーからの取得に変更し解決です。

<link rel="stylesheet" href="/css/bootstrap.min.css">

 

さいごに

 

CDN経由のCSS読み込みは、手軽なことや、読み込み速度も早いことなどから、多用されるようになりました。(私も使っていました)
しかし、今回のように読み込みが不安定になることも考えると、自社のWebサーバーにCSSや、JSファイルは設置しておいた方が良いかもしれませんね。

 

関連タグ: 

レンタルサーバーを選定比較する際に、考えておきたいリスク低減について

$
0
0

レンタルサーバーを選定比較する際に皆さんは、何を基準に比較検討していますでしょうか。
価格、サーバースペック、マルチドメインの数など様々かと思いますが、リスク低減も重要な要素の一つです。

レンタルサーバー選定比較項目

下記はレンタルサーバーを選定比較時に検討しておきたい項目です。選定比較を行う方は是非参考にしてみてください。

 

リスク低減とは

レンタルサーバーは少なからず障害やメンテナンスによるサーバー停止が度々起こります。このサーバー停止中はウェブサイトが閲覧できない状態です。

各社によって年間のサーバー停止時間は異なりますが、サーバー稼働率99.99%から、99.97%程度で稼働していることが多いのではないでしょうか。
仮にサーバー稼働率が99.99%だとすると、サーバーは年間で99.99%稼働していたという事になります。残りの0.01%は年間で約53分停止していたということになります。(99.9%の場合は年間で約8時間45分停止)

絶対に落ちないサーバーはありませんので、サーバーの障害が起きたときに、リスクをどれだけ低減できるかというのもサーバーの比較項目には重要な要素になります。

 

サーバー比較時のリスク低減項目

レンタルサーバーを比較する上で、考えておきたいリスク低減項目は下記の通りです。

  • バックアップの取得先
  • サーバー構成
  • サポート体制
  • 過去の障害状況

 

バックアップの取得先

レンタルサーバーに限らず、ウェブサーバーは、いつ障害が起こるか分かりません。
障害の種類や大きさにもよりますが、ウェブサーバーに保存していたデータが全て消えるということも少なからず起きています。
全てのデータが消えてしまった場合や、データを改ざんされてしまった場合など、バックアップを取得していることで、素早く復旧することができます。

バックアップの取得で気をつけること

バックアップ取得ですが、1つ気をつけたいことがあります。それは稼働しているウェブサーバーとは別のサーバーにバックアップを取得するということです。

ウェブサーバーにバックアップを取得している場合

ウェブサーバーにバックアップを取得している場合、ウェブサーバーが障害により停止すると、バックアップデータを取得することもできなくなります。緊急時にバックアップが取得できないことの他に、万が一ウェブサーバーのディスクが故障した場合は全てのデータを失ってしまいます。

 

ウェブサーバー以外にバックアップを取得している場合

ウェブサーバー以外にバックアップを取得している場合は、ウェブサーバーが障害により停止をしても、バックアップを取得することができますので、緊急時にバックアップを使う事ができます。

上記の通り、ウェブサーバーとは別のサーバーにバックアップを取得することは選定比較の重要項目です。

 

サーバー構成について

多くのレンタルサーバーは、ウェブサーバーと、メールサーバーが同じサーバーで稼働していることが多いです。
バックアップサーバー同様にウェブサーバーとメールサーバーは分離していることが望ましいでしょう。

理由は、ウェブサーバーの障害時にメールサーバーがダウンする。メールサーバーの高負荷時に、合わせてウェブサーバーも高負荷になる。
どちらか片方が障害になると、合わせてもう一つ落ちるよりも、原因のどちらかのサーバーだけが落ちるほうが、リスクを最小限にすることができます。

マルチドメイン

マルチドメインについても少しだけ注意です。
注意したいポイントは、マルチドメイン登録時に、同一のウェブサーバーにウェブサイトがが搭載されるのかどうかです。(マルチドメインとは、1契約でウェブサイトを複数設置すること)

同一のウェブサーバーに集約される場合、マルチドメインで100サイトのウェブサイトを構築していると、1度の障害で100サイトがダウンします。
搭載されるウェブサーバーが分散される構成ですと、障害時の対応を軽減することができます。

確認方法

Macの場合:コマンドプロンプトを起動し下記のコマンドを実行

dig example.com

結果

;; ANSWER SECZTION:
shared-blog.kddi-web.com. 300 IN A 158.***. ***.***

 

Windowsの場合:コマンドプロンプトを起動し下記のコマンドを実行

nslookup example.com

結果

名前: shared-blog.kddi-web.com
Adress: 158.***.********

表示されたIPアドレス(158.***.***.***)が、ウェブサイトごとに違う場合は、マルチドメインは別サーバーに搭載されています。

 

 

サポート体制

万全な体制をとっていても障害は起きるものです。絶対に落ちないサーバーはありません。
この障害になったとき、メールでしか連絡できないのか、電話連絡できるのかでは大きな違いがあります。

ウェブサイトの運用を請け負っているウェブ制作会社の担当者は、サーバー障害時にサイトオーナーから、いつ復旧するの?障害の影響範囲は?と問い詰められることでしょう。

その連絡でレンスポンスの悪いメールよりも、電話で連絡できた方が、クライアントへの対応も早くなります。
また、各社によって電話サポートできる時間帯が違います。24時間365日電話対応していただける会社はさらに安心ですね。

 

過去の障害状況

個人的にはここが一番重要な要素だと考えています。
初めてウェブサーバーを借りる場合で、どこも信頼できない方は、その会社の障害情報を確認してみてください。
障害情報を確認すると、どの程度の期間で、どれくらいサーバーがダウンしていたかの情報を確認することができます。

できるだけ障害が少ない会社を選ぶことで、リスクが起きる確率を下げることができます。

CPIの障害情報

障害メンテナンス情報

 

まとめ

上記のことから、リスク低減を考慮したレンタルサーバー選定比較には下記の要件を満たすことが重要だと言えます。

  • バックアップは、ウェブサーバーとは別のサーバーに取得していること
  • ウェブサーバーとメールサーバーは分離していること
  • 障害時などサポートに電話連絡ができること
  • 過去の障害状況を確認すること

レンタルサーバーCPIでは、これらのリスク低減を考慮したサーバー構成です。また、ウェブ制作者をラクにするためのサーバーツール(SmartReleas)
を標準で利用することができます。ぜひサーバー選定比較時に参考にしてください。

レンタルサーバーCPIのサーバー構成

ACE01のマルチドメインは、サーバーを申し込むタイミングによって分散される構成となっています。
(必ず別サーバーに搭載されるわけではございません)

 

関連記事

レンタルサーバだけでもできる、サーバトラブルのリスク分散(外部サイト)

 

関連タグ: 

今さら聞けない常時SSL化の必要性、費用、導入方法について

$
0
0

昨今IT/ウェブ業界では、常時SSL化が話題になっており、対応を求められることも多くなってきたのではないでしょうか。
当記事では、常時SSLの必要性や、常時SSLを導入するための方法をご紹介いたします。

 

目次

 

常時SSLとは

常時SSLとは、ウェブサイトの閲覧を常にSSLで通信を行うことです。
SSL通信とは、インターネット上の通信を暗号化するため仕組みです。通信を暗号化することで端末とサーバー間の盗聴や、改ざんができなくなります。

少し前のWebでは、個人情報や、クレジットカード番号を入れるようなサイトに対してSSLを導入していました。
しかし昨今では、個人情報を取り扱わないようなサイトでもSSLを導入する、通称「常時SSL」化が進んでいます。

 

常時SSLの必要性

 

SSL通信は元々、クレジットカード番号や個人情報などの重要な情報を、やり取りするページに利用されていました。
しかし非SSL通信でのインターネット利用は下記の危険性があります、

  • 盗聴
  • 改ざん
  • なりすまし

インターネットをより安全に、安心して利用できるように、個人情報などを送受信するサイトはもちろんのこと、情報を発信しているだけのサイトも常時SSLが求められるようになりました。

これらの時代背景から、各ウェブブラウザベンダーでは、2017年から徐々に非SSLサイトに対して、警告を出すようになってきました。
そしてChromeブラウザは、2018年7月より、全てのhttpサイト(非SSL)に対して警告がでるようになり、さらに2018年9月より警告がより目立つように赤色で警告されるようになります。

非SSLサイトの場合

非SSLサイトの場合、Chromeブラウザでは下記の通りアドレスバーに警告がでます。

 

関連記事(外部サイト)

「Google Chrome 62」が正式版に ~HTTP接続のフォームはすべて“非セキュア”扱いへ

「Chrome 68」から全HTTPサイトに警告表示へ--7月リリース

安全性を示すHTTPSのラベルとアイコンがGoogle Chrome 69から削除、一方で非HTTPSページでは赤色反転で危険性を強調

 

常時SSLの必要性の次は、実際にウェブサイトを常時SSLに対応する方法をご紹介いたします。

 

(導入方法)サーバー証明書と価格について

 

常時SSLを利用するには、まずウェブサーバーにSSLサーバー証明書を導入する必要があります。
多くのレンタルサーバーは、無料から20万円くらいまでの証明書が用意されているので、申し込みをしてください。

Let's Encrypt : 無料(手数料などかかる場合あり)
DV、OV、EV証明書 : 3,000円 〜 20万円程度

価格の違いによる、暗号化強度の違いはありませんが、証明書の種類により証明できる種類がことなります。
詳しくは「今さら聞けないSSL証明書とは、DV、OV、EVとは、常時SSLについて」を参照ください。

 

(導入方法)httpから、httpsにリダイレクト

 

サーバー証明書を取得したら、https://~ から始まるURLで、ウェブサイトにアクセスすることができるようになります。
今後 https://~ にサイトのURLを変更しますので、 http://~ に来たユーザーを、 https://~ に転送します。

転送は、サイトのURLが変わったことを検索エンジンに伝えるため、301リダイレクト転送を行います。

手順

* この作業はウェブサイトが表示できなくなる可能性がありますので、必ずテスト環境で検証してから、本番環境に設置してください。
 

  1. ウェブサーバーの直下に「.htaccess」ファイルを追加します。
    すでに「.htaccess」が存在する場合は、ファイルを編集してください。
     
  2. .htaccessファイルに下記のコードを追加します。
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*$) https://example.com/$1 [R=301,L]
    </IfModule>

    2行目(RewriteEngine on):リダレクト処理を有効にします。
    3行目(RewriteCond %{HTTPS} off):http通信でアクセスしてきたら次の処理を実行
    4行目:https:// に301転送します。「example.com」を、ウェブサイトのURLに変更してください。
    すでに「RewriteEngine on」の記述がある場合は、その直下に追記をしてください。

 

(導入方法)内部リンクの変更

 

ページ遷移や、画像パス、CSS・JSパスなどの内部リンクに http:// ~  の記述がある場合、全て https:// ~ に変更してください。

(例)

<a href="http://example.com">
 ↓ ↓ ↓
<a href="https://example.com">

外部へのリンクの場合、その外部サイトが https:// ~ に対応していない場合もありますので、注意してください。

 

(導入方法)Facebook、はてブの引き継ぎ

 

http://~ で、押されたFacebookのいいねや、はてなのブックマークは、URL変更にともないゼロに戻ってしまいます。
これを引き継ぐ方法をご紹介します。

Facebook

Facebookの公式サイトにも掲載がありますが、og:urlを「http://~」に変更し、 http:// から、https:// のリダイレクトをFacebookクローラーの場合のみ、除外します。

HTMLのog:urlを http://~ にする

<meta property="og:url" content="http://example.com/">

 

.htaccessを編集

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1.1) [NC]
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*$) https://shared-blog.kddi-web.com/$1 [R=301,L]
  </IfModule>

3行目が、Facebookのクローラーを除外する記述で、それ以外はhttp://~ を https://~ にリダイレクトする方法です。

 

確認方法

Facebook Debugerを使い、デバッグをしてください。
下記の通り、Input URLが「https」、og:urlが「http」になっていれば設定完了です。

変更されない場合は、「Scrape Again」ボタンをクリックしてください。

 

はてなブックマーク

はてなブックマークの場合は、ボタン作成用のページから、保存するURLを「http://」のアドレスにし、サイトに設置してください。

 

 

(導入方法)Google Search Console

 

サイトをSSL化することでGoogle Search Consoleで未確認サイトになってしまいます。
Googleがより高度なクロールができるように、Google Search Consoleに追加登録します。

Google Search Consoleにログインし「プロパティの追加」から、https://~ のアドレスを追加します。

サイトマップの登録

  1. Search Console Topの「サイトマップ」をクリックします。
     
  2. サイトマップを追加します。

     
  3. サイトマップの追加完了

サイトマップとは

サイトマップとは、ウェブサイトの構造をリスト化し、検索エンジンやユーザーに分かりやすく伝えることです。
今回の場合は検索エンジンに伝えるためのXML形式のファイルのことです。

WordPressの場合は、Google XML Sitemapsプラグインを導入することにより、サイトマップを生成することができます。

 

さいごに

 

常時SSLに対応していないサイトもまだ多く存在しているのが現状ですが、ユーザーの不安要素や、SEOで不利になるなどありますので、早めの対応を行いたいところです。

レンタルサーバーのCPIでは、シマンテックや、セコムなど各社 SSLを多数取り扱っておりますので、ぜひご検討ください。

 

レンタルサーバーとは?初心者でもすぐわかるサーバーの種類と仕組み

$
0
0

本格的にホームページやブログを立ち上げるためには、サーバーを借りてドメインを取得する必要があります。ただ初心者の場合、レンタルサーバー選びの際に遭遇するサーバーやドメインなどの用語の意味や仕組みが、そもそもわからないこともあるでしょう。ここでは、ホームページやブログを開設したい初心者のために、レンタルサーバーの種類とその仕組みをわかりやすく解説していきます。

1.レンタルサーバーの種類について知ろう

Webサイトやメールシステムの機能を提供するためには、必要なソフトウェアやデータを持つためのコンピューターが必要です。これをサーバーと呼び、Webサイトにアクセスしてきた各ユーザーの要求に応じて、必要な情報を提供する機能を持っています。

サーバーを自分で立ち上げることもできますが、専用のコンピューターやOS、及びソフトウェアを適切に設定し、トラブル対策、メンテナスを行う必要があり負担が大きいです。そのため、通常はレンタルサーバーを借りてサイト運営を行います。

1-2.サーバーの種類とメリット・デメリット

1-2-1. 共用サーバー

レンタルサーバーの中でも最もポピュラーなタイプであり、初心者が利用しやすいサービスです。1台のサーバーをユーザー複数で共用しますので、比較的安い費用で利用できます。OSや利用環境もあらかじめ設定されているので、ゼロからサーバーを構築するよりも手間や時間を節約できるメリットがあります。

一方、同じサーバーの共用グループに属する利用者の中にヘビーユーザーがいると、回線の帯域(簡単に言えば、通信速度のこと)やハードウェアリソースの大半を占有されてしまいます。その場合、動作が重くなったり、通信回線がタイムアウトになってしまったりといったデメリットがあります。

1-2-2. VPS

VPSは1台のサーバーを複数のユーザーで共有する点で、共用サーバーと同様ですが、ユーザーごとに仮想専用サーバーが割り当てられる点で異なります。インストールされているソフトやOSが独立しており、ユーザー間の干渉がないため、専用サーバーと同じような使い方ができる点で自由度があります。

しかも、専用サーバーを使うよりも安い費用で利用可能です。ただし自由度がある反面、必要なソフトウェアのインストールや設定を自分で行う必要があるので、共用サーバーと比較して導入の難易度が高くなります。

1-2-3. 専用サーバー(サーバー管理者権限あり)

専用サーバーは、1台の物理サーバーをユーザーが独占して使うことができる契約であり、高速大容量、高い自由度などハイスペックな環境が提供されます。したがって、共用サーバーやVPSよりも拡張性や性能の面で有利です。しかも、他のユーザーの影響を全く受けない環境に魅力があります。ただし費用が高いことや、正確な運用をするために専門的な知識が必要なので、初心者にはハードルが高いと言えます。

1-2-4. 専用サーバー(サーバー管理者権限なし)

専用サーバー(サーバー管理者権限なし)は、1台の物理サーバーをユーザーが独占して使うことができ、共用サーバーと同様に、OSや利用環境もあらかじめ設定され、サーバー事業者が運用管理を行います。共用サーバーの使い勝手で、1台の物理サーバーをユーザーが独占して使うことができる分、共用サーバーに比べ費用がかかります。

 

種類/項目メリットデメリット
共用サーバー利用環境があらかじめ設定されている。サーバーを構築・運用する手間や時間を節約できる。ユーザー複数で共有するので、影響を受ける場合がある。
VPS仮想化技術により、各ユーザーにCPUやメモリが割り当てられ、独立している。必要なソフトウェアのインストールや設定を自分で行う必要がある。
専用サーバー(管理者権限あり)1台の物理サーバーを独占して使うことができる。他のユーザーの影響を受けない環境。必要なソフトウェアのインストールや設定を自分で行う必要がある。
専用サーバー(管理者権限あり)1台の物理サーバーを独占して使うことができる。サーバーを構築・運用する手間や時間を節約できる。共用サーバーに比べ費用がかかる。

詳しくはこちらの記事もご覧ください。

2.サーバー選びのポイントと注意点をチェック!

レンタルサーバーを選定する上で、必須とも言えるドメインや転送量の意味とチェックすべきポイントをまとめました。

2-1.ドメインとレンタルサーバーの関係

サーバーは、ページの閲覧やメールを利用するためにシステムファイルやデータを配置するための領域です。また、複数のユーザーが訪問した際にリクエストに応じて、必要な情報の提供や処理を行う役目を担っています。

ドメインは、レンタルサーバーを契約するのとは別に、ドメイン業者から独自ドメインを取得する契約をします。サーバーがファイルやデータの置き場所だとするなら、ドメインはその場所を特定するための住所の役割を果たします。たとえば、Webサイトを表示するために、「http://○○.○○」のように記述したURLを指定する場合、○○.○○の部分がドメインに相当します。

ドメインとサーバーを関連づけるためにDNS(Domain Name System)があります。「http://○○.○○」のサーバーは「△△△」にあると示す住所録のようなものです。共用サーバーの場合、ドメインの取得や維持管理もレンタルサーバー事業者と契約すれば、DNSの設定を代行してくれるので安心です。

2-2.マルチドメインのメリットとデメリット

レンタルしているサーバーが1契約であっても、複数のドメインを設定してそれぞれ別個のWebサイトを作ることができます。これをマルチドメインと称しますが、サーバーの契約によっては、作れるドメイン数に上限が設けられるケースと無制限のものがあります。

2-2-1. マルチドメインのメリット

1ドメインに1契約でサーバーを借りるよりも、1契約で複数のドメイン(サイト)が運営できるため費用が安く済みます。また、複数サイトを一括管理できますので、散漫にならず便利です。

2-2-2. マルチドメインのデメリット

1つの物理サーバーに依存していますので、もしサーバーにトラブルが生じて動作が不安定になると、契約に紐付く全てのマルチドメインサイトの運営に影響が及ぶ恐れがあります。さらに、物理サーバーは1台なので、大量のマルチドメインサイトを運営している場合にサイトの表示速度が遅くなる可能性があります(ただ、レンタルサーバー業者によっては、ドメインごとに利用するサーバー領域を区切る仕組みが構築されているケースもあります)。

2-3.転送量について理解を深めよう

Webサイトを運営する際、サーバーがユーザーに提供できるデータ量の上限(転送量)も確認しておきましょう。ここで言う転送量とは、ユーザーがWebサイトを閲覧、もしくはメールを送受信した際に、ユーザーに転送した全てのデータ量を指します。そして1ヶ月あたりどの程度の転送量が上限となるかは、GB(ギガバイト)などで表現します。

日々のサイトへの訪問者が多く、アクセス数が多い場合は、転送量も大きくなります。マルチドメインで複数サイトを運営する場合も、合計の転送量が対象になる場合があります。もし契約しているサーバーの転送量を超える場合は警告を受けますので、その際はサーバーのプランを変更するか、サイトの運営方法の見直しを迫られることになります。さらに転送量超過の状況が改善されず繰り返し警告を受けるようになると、利用停止などのペナルティが科せられる場合があり注意が必要です。

また、転送量が超過するような場合は、ユーザーがサイトを閲覧する際の表示が重くなってしまい、表示不可の状態に陥る可能性があり適切な配信が維持できなくなる場合があります。したがって、大量のアクセスを集めるようなサイトを運営する場合は、サーバーの転送量の上限に注意を払う必要があります。

まとめ

サイト運営をする際に必要となるレンタルサーバーの種類と仕組みについて解説してきました。スペックと費用のトレードオフがありますので、利用形態をよく吟味して最適なサーバーを選択することが大切です。

 

CPIは法人利用率90%、20年以上のサーバー運用実績を誇るビジネス・レンタルサーバーです。大容量・高速回線を実現し、マルチドメイン無制限。ドメイン数が増えても快適さを維持します。メールアカウント数、メールボックス容量が無制限。WordPressはもちろん、コーポレートサイトやネットショップ向けのCMSもインストーラー付きで簡単導入可能です。また、電話やオンラインヘルプなどのサポートも充実で初心者も安心。お見積りやお申込みなど、レンタルサーバーCPIへお気軽にお問い合わせください。

関連タグ: 

法人向け!失敗しないレンタルサーバーの選び方6つのポイント

$
0
0

コーポレートサイトやECサイト、キャンペーンサイトなど、企業がWebサイトを運営するうえで必要になるのがレンタルサーバー。Webでビジネスを行う際の土台になる重要な部分だからこそ、利用するサービスは慎重に選びたいものです。ここでは、レンタルサーバー選びで失敗しないために押さえておきたい、6つのポイントをご説明します。

レンタルサーバーは価格の安さだけで選ぶものではありません。ぜひ、複数の観点からレンタルサーバー会社を比較して、納得のいくサーバーを選びましょう。

1.レンタルサーバーの基礎知識

レンタルサーバーの基礎的な知識を理解しておきましょう。Webサイトが表示される仕組みや、レンタルサーバーを使うメリットをわかりやすく解説します。

1-1.レンタルサーバーの仕組み

最初に、そもそもサーバーとは何か? ということをご説明します。サーバーとは、簡単に言えば、Webサイトのデータが格納されている場所のことです。サーバーは、クライアント(PCやスマホなどのデバイス)からの、「このページが見たい!」 というリクエストに対して、該当のWebサイトのデータを送り返します。そうすることで、私たちはページを閲覧できるという仕組みです。

ここまではサーバーの一般的な仕組みです。サーバーにはいくつか種類がありますが、レンタルサーバーとは、サーバーの機器の保有や管理、メンテナンスをサーバー会社が私たちに代わって行ってくれるサービスのこと。ホスティングサービスとも呼ばれ、Webサイトを公開するための手段としては、最も手軽でポピュラーな選択肢です。

1-2.レンタルサーバーを使うメリット

サーバーの機器の管理やメンテナンスは、レンタルサーバー会社がすべて行ってくれるので、サーバーに関する専門知識がなくてもWebサイトを公開・運用可能です。もし自社でサーバーを保有・管理しようとすれば、社内にサーバーの運用・保守を行う管理者が必要になります(それも、高い専門知識が要求されます)。また、サーバーにトラブルが発生した場合、夜間や休日問わず、早急に復旧作業を行わなくてはいけません。

サーバーの運用・管理には手間と時間がかかります。サーバーの運用・管理業務で、本来行うべきビジネス活動に集中できない状況は好ましくありません。企業のWeb担当者にとって、レンタルサーバーは手間と時間を大きく削減してくれるというメリットがあるのです。

2.法人向けのレンタルサーバーの選び方6つのポイント

では、具体的にどのような機能に注目してレンタルサーバーを選べばいいのでしょうか?ここでは、法人向けのレンタルサーバーの選び方を、6つのポイントに絞って解説していきます。

2-1.セキュリティ対策機能が豊富かどうか

Webサイトを外部の悪質な攻撃から守るセキュリティ機能は、特に注目したいポイントです。具体的には、以下の機能が搭載されているかをチェックしましょう。

・WAF(ウェブ・アプリケーション・ファイアウォール)
・Web改ざん検知

WAF(ウェブ・アプリケーション・ファイアウォール)とは、その名前の通り、ウェブアプリケーションを対象としたサイバー攻撃をブロックする機能です。通常のファイアウォールでは防げないHTTPやHTTPS通信の攻撃を防御することが可能になります。PHPなどのWebアプリケーションを使ったWebサイトでは、必須のセキュリティです。

Web改ざん検知は、Webサイトが悪意ある第三者に改ざんされた場合に、その改ざんを検出して通知をしてくれる機能です。改ざんを人力で検出するのは現実的ではないので、自動的にWebサイトのページを解析してアラートを上げてくれるWeb改ざん検知が必要になります。

2-2.SSLサーバー証明書が利用できるかどうか

SSL(Secure Socket Layer)とは、インターネット上のデータ通信を暗号化する手法の一つです。暗号化通信を行うことで、データの送信時に第三者に盗み見されるリスクを減らすことができます。SSLに対応しているWebサイトのURLは「https://」 が用いられます(SSL非対応のサイトは「http://」)。

 

SSL対応を行う目的は通信データを暗号化し、盗聴や改ざんを防ぐのが第一ですが、それ以外にも、Webサイトに訪問してくれたユーザーに、信頼や安心を感じてもらうという視点からも重要です。逆に言えば、SSL非対応のWebサイトはユーザーに疑念や不信感を与えてしまう可能性があります。特に、Chrome 68以降のブラウザでは、HTTPS化されていないとアドレスバーに「保護されていない通信」という警告が表示されます。今後、サイト全体で常時SSL化を行うことが一般化していくため、SSL対応は必須です。

 

レンタルサーバー会社によって、SSL証明書の利用可否や種類は異なります。レンタルサーバーを契約する際は、SSL証明書に関する説明をチェックしておきましょう。

2-3.SLA(品質保証制度)や返金制度があるかどうか

どれだけ料金が安いレンタルサーバーでも、稼働率が安定しなければ意味がありません。通信が安定しない、すぐにサーバーが落ちるといったトラブルが多発していては、Webサイトの運営に支障が出ます。そこで注目したいのが、SLA(品質保証制度)や返金制度です。

もし何らかのトラブルで定めた稼働率を維持できなくなった場合は、一定の割合でサーバー料金が返金されます。返金額はレンタルサーバー会社によって異なりますが、稼働率がどの程度下回ったかによって返金額を決めているケースが多いようです。

2-4.表示速度に定評がある高速サーバーかどうか

サイトの表示速度は、ユーザーの利便性を追求するために重要な要素です。また、モバイル検索におけるサイトの表示速度は、検索順位にも関わってくることがGoogleから正式にアナウンスされています。

レンタルサーバーを比較する際は、大容量の高速ネットワークを保有している会社を選びましょう。利用するドメイン数が多くなる予定がある場合は特に重要な要素です。レンタルサーバー会社によっては、利用するドメインごとにサーバー領域を割り当てる仕組みが構築されているケースもあるので、そのような会社を選ぶといいでしょう。

2-5.バックアップ・データを自動取得可能かどうか

Webサイトの運用をしていると、不測の事態は起こり得るものです。

・誤って重要なデータを削除してしまった
・ファイルの操作を誤って、急にサイトが表示されなくなった
・アップロードするファイルを間違った

そんな時でも、サーバーに自動バックアップ機能が備わっていれば慌てることはありません。サイト公開時や毎日一定の時間帯にデータを自動バックアップしてくれる機能が備わっていれば、バックアップの問題に頭を抱えることはなくなります。

2-6.サポートが充実しているかどうか

契約前の不明点や導入後のトラブルに対するサポートの充実度も、チェックしておきたいポイントです。選任のアドバイザーが技術的な悩みにも答えてくれれば、非常に心強いでしょう。

通常、レンタルサーバー会社のサポート時間は、その会社の営業時間内の対応に限られるのが一般的です。ただ、有料オプションとして24時間365日サポート対応を付与できる場合もあります。夜間や休日対応が希望するなら、そのようなオプションの有無をチェックしておきましょう。

3.法人サイトの運営で使うレンタルサーバーはCPIがおすすめ!

3-1.CPIとは

CPIは、KDDIグループのレンタルサーバーブランドです。20年以上の運用実績があり、法人利用率は90%。コーポレートサイトはもちろん、ECサイトやキャンペーンサイト、官公庁や教育機関のサイトなど、数多くのWebサイトがCPIで運用されています。20年以上の運用によるノウハウの蓄積と、KDDIグループだからできる堅実なサービスは、多くの法人様から信頼をいただいています。

3-2.CPIがおすすめの理由

3-2-1. 豊富なセキュリティ機能で不正な攻撃をブロック

WAFやWeb改ざん検知、マルウェア診断といったセキュリティ機能をご用意。悪意ある不正な攻撃からWebサイトを守ります。

3-2-2. 様々な種類のSSLサーバー証明書

SSLサーバー証明書も、DV(ドメイン認証型)、OV(実在証明型)、EV(実在証明拡張型)や様々なブランドのSSLサーバー証明書をご利用いただけます。

SSLの詳細についてはこちらの記事もご覧ください。

3-2-3. 安心の返金保証

稼働率が100%を下回った場合には一定の割合で利用料金を返金する制度と、初回ご契約開始日から20日間以内であればレンタルサーバー料金を全額返金する20日間返金保証があり、安心してご契約いただけます。

3-2-4. 大容量・高速回線で快適なWebサイト表示が可能

CPIでは、大容量・高速ネットワーク回線による接続を実現し、大規模ビジネスサイトの運用にも耐えうる安定性を誇ります。ネットワーク回線は定期的に増強しており、サービスの強化を継続しています。

3-2-5. 自動バックアップ機能で万が一の時にも安心

CPIのレンタルサーバーは、自動バックアップサービスを搭載しています。重要なデータを削除したり、誤ったファイルをアップしたりした場合でも安心です。

3-2-6. 充実の体制でサーバー導入・運用をサポート

電話やオンラインヘルプなどのサポート体制も充実しています。また、有料オプションで、24時間365日の電話&メールサポートをご利用可能。夜間や休日のトラブルの際も、お任せください。

この機会にぜひ、CPIのレンタルサーバーをご利用を検討されてはいかがでしょうか?お見積もりやお申し込みなど、お気軽にお問い合わせください。

関連タグ: 

【Web】レンタルサーバーのセキュリティ6つの対策

$
0
0

レンタルサーバーを利用するときに気になるのが、セキュリティ対策ではないでしょうか?ここでは、レンタルサーバーの主要なセキュリティ対策機能の紹介と、そのなかでも特に重視すべき機能について解説します。ぜひ、レンタルサーバー選びの参考にしてください。

1. レンタルサーバーの主要なセキュリティ対策とは?

 

1-1.Webサイト暗号化(SSL)

SSLは通信データを暗号化し、悪意のある第三者からの盗聴を防止するために有効です。一般的なサーバーとWebサイトの通信は、「http://」で始まるアドレスが使われますが、安全で信頼性の高いSSLを導入する場合は「https://」が使われます。

現在は、問い合わせフォームなどの一部のページだけでなく、サイト全体で常時SSL化を行うことが一般化しています。Chrome 68以降のブラウザでは、SSL非対応のサイトのアドレスバーに「保護されていない通信」という警告が出ますし、将来的にその他のブラウザでも同様の措置が取られることが予想されます。もはや常時SSLは「やったほうがいい」対応ではなく「やらなければいけない」対応です。

詳しくはこちらの記事もご覧ください。

1-2.WAF

ファイアウォールは外部からの攻撃や不正な通信をブロックすることができますが、WebサイトやWebサービスを狙ったサイバー攻撃を防ぐことはできません。

そこで、Webアプリケーションの脆弱性を攻撃する悪意のある第三者からサイトを守るために、WAF(ウエブ・アプリケーション・ファイアウォール)が適用されます。HTTPの経路に怪しい通信が見つかればこれを遮断し、問題ない通信だけを許可するのがWAFの主な機能です。

詳しくはこちらの記事もご覧ください。

1-3.ウェブ改ざん検知

Webサイトが悪意のある第三者に改ざんされた場合、管理者はいち早くWebサイトの異常を検知して、適切な処理を施し被害の拡大を最小化する必要があります。

しかし、異常状態の検出を人間が逐次行う方法には限界がありますので、セキュリティ対策の一環として、ウェブ改ざんの検出を自動化し、Webサイトの管理者にただちに通知することが可能となります。

1-4.マルウェア診断

マルウェアとは、有害な働きかけを行う不正なソフトウェアやコードの総称です。マルウェアがWebサイトに埋め込まれると、サイト訪問者が被害を受ける恐れがあります。

マルウェア診断サービスを利用すれば、不正なマルウェアがWebサイトから検出された際にメールで通知を受け取ることが可能。異常にすぐに気付き、対策を打つことができます。Webサイトを安全に運用するためには必須の機能です。

1-5.IDSとADS

IDSは外部からの不正侵入を検出するシステムです。ADSはIDSよりもさらに進んで、不正侵入の検出と通信のブロックまでを自動的に行うため、迅速な対処が可能です。

1-6. メールシステムのセキュリティ

メールシステムを使う上で、情報漏えいやシステム本体への攻撃など様々な種類の脅威があります。一般的なレンタルサーバーが装備しているメールのセキュリティ対策の機能には、迷惑メールに対処するスパムフィルター、怪しい添付ファイルをブロックするウィスルチェック、およびメールを暗号化する手法などがあります。それぞれ、詳細を解説します。

1-6-1. ウィルスチェック

メールに添付された実行ファイルやその他の偽装ファイルを事前に検知し、マルウェアやウイルスの感染など有害な攻撃からコンピューターを保護します。

1-6-2. スパムフィルター

迷惑メールを判定・抽出するために、どんなルールでフィルタするかが重要です。たとえば検知ルールを自動学習するものや、データベースを逐次更新するタイプなどがあります。

1-6-3.メールの暗号化

POP over SSLやSMTP over SSL、IMAP over SSLといったメール暗号化技術を利用できるかどうかは重要です。悪意ある第三者による盗み見を防げるからです。これらのメール暗号化技術は、メールクライアント(電子メールを送受信するためのソフト)とメールサーバー間の通信経路を暗号化する技術です。

2.レンタルサーバーのセキュリティで特に重視すべきポイント

2-1.レンタルサーバーの標準セキュリティは十分か?

レンタルサーバー会社が標準で用意しているセキュリティ機能を、まずはチェックしましょう。特に、Webサイトやメールのセキュリティは、サイト運営において特に重視したいポイント。WAF機能やメールのスパム・ウィルスチェック機能が標準搭載されているかどうかを、一つの判断基準にするといいでしょう。

2-2.WAF(ウエブ・アプリケーション・ファイアウォール)が搭載されているかどうか

WAFはファイアウォールでは防ぐことができない攻撃を検知したり、通信を遮断したりするなどの対処ができますので、セキュリティを確保するためにも導入を検討する必要があります。

WAFが導入されていないレンタルサーバーの場合、別途WAFのサービスを導入しなければならず時間と手間がかかります。したがって、セキュリティやコストパフォーマンスを重視するなら、WAFも対応しているレンタルサーバーを候補として検討する必要があるでしょう。

2-3.Web改ざん検知・マルウェア診断を利用できるかどうか

万が一、Webサイトが改ざんされた場合、サイト内の被害にとどまらずサイト訪問者に迷惑をかけてしまう恐れがあります。Web改ざん検知・マルウェアの診断ツールがあれば、Webサイトの異変を自動でチェックできますので、管理者が素早く被害を検知し対策を講じることが可能です。

サーバーを選ぶ際には、この有用な機能が利用できるのか確認すべきでしょう。

2-4.SSLサーバー証明書を利用できるかどうか

セキュリティの主要機能の一つであるSSLを適用するためには、SSLサーバー証明書が必要になりますが、他社で購入したSSLを利用できないケースがありますので注意が必要です。特にサーバーの乗り換えの際に問題となるかもしれません。もちろん標準機能で無料SSLが利用できる場合は、この限りではありません。

レンタルサーバーを契約した会社が提供するSSLサーバー証明書しか適用できない場合は、費用がどれくらいになるかまで検討すべきです。

まとめ

ここまで、代表的なセキュリティ対策の機能をピックアップして、その内容を紹介してきました。レンタルサーバーを選定する上で、どんなセキュリティ対策がサポートされているのかは重要な条件です。

CPIのレンタルサーバーは豊富なセキュリティ機能を搭載しており、外部からの攻撃に対する備えは万全。今回ご紹介してきたSSLサーバー証明書やWAF、マルウェア診断、Web改ざん検知など、必須となる機能を網羅して強固なセキュリティを実現しています。お見積りやお申込みなど、お気軽にお問い合わせください。

関連タグ: 

IoT、AI化が進むことによりWebデザインはどう変わるのか

$
0
0

Webを取り巻く環境は目まぐるしく変化しています。
2017年はスマートスピーカーの発売や、AIを搭載したプロダクトのローチンチなど、この業界を賑わせました。

このAI化と、IoTデバイス(スマートスピーカー)の普及は2018年、2019年年と、さらに進んで行くと予想できます。
そこで私は一つの疑問を感じました。

それは、AI化、IoTデバイスが普及していくことでWebデザインがどう変わっていくか、これから何を意識して仕事をしていったら良いかです。
考えていても仕方がないので、この業界で著名な長谷川恭久氏をお招きして、聞いてみました。

 

Part1 動画の趣旨

長谷川恭久氏、自己紹介(サイト:could
2017年の振り返り
- 第四次産業革命の期待
- 2017年のインターネットトラフィックについて
 

 

Part2 Webデザインについて

IoTとAI化が進むことにより変化するWebデザインについて
IoTデバイスは一般世帯に普及するのか?

 

Part3 AI搭載のプロダクト紹介

AIとは
BRAND MARK
Firedrop

 

Part4 まとめ

 

 

さいごに

 

長谷川恭久氏は、今後日本でも2〜3年後にIoTデバイスは普及していくのではないかと予想しており、それに向けた準備がこれからのWeb制作に必要だと語っています。

個人的にもこの意見は大変納得がいく事項で、今後もCPIスタッフブログではIoTや、AIをウオッチしていきます。

 

 

 

関連タグ: 

CPI20周年サンクスキャラバン in 大阪

$
0
0

サンクスキャラバン福岡のレポートでCPIの都道府県別シェアを発表しましたが、大阪は東京に次いで2番目にご契約者さまの多い地域です。いつもお世話になっております!

KDDIウェブコミュニケーションズは東京以外にも大阪と宮古島にオフィスを構えており、今回は大阪の同ビル3階にオフィスを構える「中央会計株式会社」さまのセミナールームをお借りして開催いたしました。

このセミナールームは昨年9月にリニューアルしたばかり。あまりのオシャレさと綺麗さに驚くばかりでした。 こんなに素敵な場所を無料で提供いただき、代表の小松さん、いつもありがとうございます。 リンクも貼らせていただきます。もちろんサーバーはCPIです!

 

Webのこれから。CPIスタッフとエバンジェリストによる各セッション

 

ここから各セッションのご紹介に移ります。

まずはクラウドホスティング事業本部 本部長 西村よりCPIの取り組みについてご紹介。

先ほど弊社の大阪オフィスについて触れましたが、西村は大阪オフィスを立上げた当時の責任者でもあります。今年でオフィス開設5周年であることも紹介されました。

もしかしたらオフィス開設5周年パーティーが今年どこかで開催されるかもしれませんね。

 

 

 

続いては大阪だけの特別講演。フィールドマーケティング部の宋より「ウェブサイトの構築&運⽤の効率化」と題して、エンジニア目線でCPIに触れるとともに、電話APIであるTwilioや他外部サービスとの連携によるビジネスの可用性を実例を交えてご紹介しました。

ここからCPIエバンジェリスト達のセッションへ移ります。

 

 

トップバッターは谷口さんから「人工知能(AI)時代におさえておきたい、データベースの基礎知識」について講演いただきました。

企業におけるデータ保有の重要性と、Kintoneを用いたデータベース化する可用性について、最近よく耳にするAIやスマートスピーカーと組み合わせたビジネス活用事例などをご紹介。

セッション中に構築から連携までおこない、Google homeと組み合わせたデモを披露した際には会場から感嘆の声があがっていました。

 

 

 

続いては東京以来の登壇で、菱川さんによる「エンジニアのための営業入門」についての講演です。

エンジニアが身につけたいスキルは沢山あって、何を学んだらよいのかわからなくなるケースは多々ありますが、そんな中でも営業の心構えはエンジニアにとっても必要であることを実際の体験談をもとに紹介いただきました。

今回お話いただいた内容の本質は、エンジニアに限らず常に心がけておかないといけない内容だと感じました。

 

 

次は各地のキャラバンにおいて毎回アンケートで高い評価を誇るセッション。

「Webクリエイターのための情報交換所スペシャル」を後藤さん、菱川さん、前川さんの3人による共同登壇でお送りしました。

毎回ここだけの話が満載で笑いの絶えないセッションですが、もちろん内容についても改めて振り返る事の重要性を感じる方が多いようです。

 

 

最後は江頭さんによる「CMSを利⽤した次世代ワークフローを考える」です。

カスタマージャーニー、コンテンツマーケティング。。。など目まぐるしく変わるトレンドを捉え、各種CMSの紹介とともに最適な制作フローを江頭さんの視点でご紹介いただきました。

BaserCMSのご紹介もあり、近々では英語版対応などのアップデート予定もあるそうです。 もちろんCPIはBaserCMSのオフィシャルスポンサーです!

 

懇親会&プレゼント大会!

 

今回も全セッション終了後は、懇親会とプレゼント大会にて参加者との交流を深めました。

じゃんけん大会では全国のどの会場よりも熱気があり、非常に盛り上がりました。

いつもTwitter投稿キャンペーンでプレゼントさせていただくTシャツが 当選者の方によって大きすぎたり小さすぎたりと、ご要望に合うサイズを提供できず恐縮です。。 次回までの改善点とさせてください。

中にはご夫婦で参加され、お二人ともTシャツをゲットされた参加者さんもいらっしゃいました。素敵です。

さて、サンクスキャラバンと題して全国を回ってきたこの企画も、いよいよ次回(3月3日)の名古屋で最後です。
スタッフ一同、最後まで頑張りますので、どうぞ宜しくお願い致します。

 

 


httpからhttpsにリダイレクト、www有無のリダイレクト方法(mod_rewrite)

$
0
0

Webサイトは常時SSLが当たり前の時代になりました。
今回の記事では、これまで

http://example.com」や、「http://www.example.com」で運用してきたWebサイトを、「https://example.com」に転送する方法をご紹介します。

サイトをSSL化した場合に対策をしておかないと、ブックマークや、Googleの検索エンジンからの流入などから古いURLにアクセスされる可能性があります。
古いURLにアクセスが残ったままですと様々なデメリットがありますので、常時SSL化後には設定しておきたい項目です。

常時SSLとは

Webサイトを閲覧する端末と、Webサイト間の通信を常にSSL/TLSで暗号化をし、第三者に情報を読み取られないようにすることです。

WebサイトのURLは下記の通りです。

(非SSL)http://example.com

(SSL)https://example.com

 

転送方法

 

http:// もしくは、www 有り無しの転送はApache(Webサーバー)の、mod_rewriteという機能を使い転送を行います。
今回は下記の通り、3つのURLの場合に、https://example.comに転送を行います。

転送するURL:

http://www.example.com
http://example.com
https://www.example.com

転送先URL:

https://example.com

 

  1. Webサーバーにログインし「.htaccess」ファイルを作成します。
    すでに.httaccessファイルが存在する場合は、手順2の項目を追記してください。

    * .htaccessの記述を間違えますと、サーバーが動作しなくなりますので、必ずテストサイトで検証してから、本番環境にアップロードしてください。
     

  2. .htaccessファイルを下記の通り編集します。
    ##
    # SymlinksはCPIサーバーをご利用の場合記述が必要です。
    # CPIサーバー以外でも、mod_rewriteを有効にし、エラーがでる場合は、
    # どちらかのオプションを有効にしてください。
    ##
    # CPIサーバーでACE01_2015以降のサーバー
    Options +SymLinksIfOwnerMatch
    # CPIサーバーでACE01_2011以前のサーバー
    Options +FollowSymLinks
    
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    
    # httpからの通信を、httpsにリダイレクト(www有り無し)
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*$) https://example.com/$1 [R=301,L]
    
    # httpsからの通信でwww有りの場合、www無しにリダイレクト
    RewriteCond %{HTTPS} on
    RewriteCond %{HTTP_HOST} ^www.example.com$
    RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
    </IfModule>
    

    example.comを設定するURLに変更してください。

 

以上で転送設定が完了です。

 

証明書エラーが出る場合

 

「安全な接続ができませんでした」などのエラーが出る場合は下記を確認ください。

 

SSL証明書が正しく設定されているか。
Chromeブラウザの場合サイトにアクセスすると「鍵」マークのアイコンが出ます。アイコンが出ない場合は証明書が失効している可能性がありますので、Webサーバーの管理会社に問い合わせください。

 

https://www有りから、https://www無しへの転送の場合、www有りと無しの2つのURLに対してSSL設定が必要です。
1つのSSL証明書で、2つのURLにSSLを設定する場合は、SSL証明書がSANs対応している必要があります。

CPIサーバーの場合ですと、シマンテックジオトラストの証明書がSANs対応しています。CPI SSLは対応していませんのでご注意ください。

 

 

 

関連タグ: 

CPIのSmartReleaseでWordPressの開発と運用

$
0
0

この記事では共用型サーバーACE01に標準装備されているSmartReleaseを使い、テスト環境で構築したWordPressのリリースと運用方法についてご紹介いたします。
ACE01を借りたけどSmartReleaseの使い方がよく分からないと言う方は参考にしてみてください。

 

目次

 

SmartReleaseとは

SmartReleaseとは、CPIのACE01を借りると標準で使えるウェブ制作をラクにするサーバーツールです。

SmartReleaseの特徴

  • テスト環境標準装備
  • テストから公開にファイル転送機能
  • 自動バックアップ機能(ウェブ、データベース)

 

SmartReleaseの利点

ACE01は下記のサーバー構成で、SmartReleaseと呼んでいるのはテスト環境から、公開環境にファイル転送をしたり、バックアップからデータを戻したりするための機能のことです。

それではSmartReleaseの利点について詳しく見ていきます。

テスト環境標準装備

一度ウェブサイトが本番稼働すると、公開環境下で追加開発や、システムアップデートテストなどをすることが難しくなります。
追加改修などの場合は、テスト環境を用意して作業を行い本番に反映します。
SmartReleaseでは、このテスト環境が標準で装備しているため、追加改修などの場合、新たにサーバーを準備せずに始めることができます。

テストから公開にファイル転送機能

テスト環境から、公開環境にファイルを転送する場合、ひと昔前まではFTPでテスト環境からファイルをダウンロードし、公開環境にアップロードしていました。
昨今ではバージョン管理システム(Gitなど)を使いアップロードすることもあります。
手動でのファイルアップロードは間違えのもとですし、Gitはデザイナーやディレクターには少し敷居の高いツールです。

SmartReleaseは、テスト環境で追加改修したファイルやデータベースをコントロールパネルからボタン1つで転送することができます。

自動バックアップ機能(ウェブ、データベース)

万が一のために、バックアップの重要性は皆さんご存知かと思います。
しかし、定期的なバックアップの取得や、バックアップの世代管理は面倒です。

SmartReleaseでは、ウェブとデータベースそれぞれ自動でバックアップが取得されており、万が一の時にボタン1つで過去の状態に戻すことができます。

 

テスト環境にWordPressをインストール

それではSmartRelease環境にWordPressを導入していきます。
テスト環境へのインストールは、CPIが用意している簡単インストーラーを利用します。

  1. ユーザーポータルにログインし、ウェブコントロールパネルを開きます。
  2. ウェブコントロールパネルの「テストサイト用設定 > ソフトライブラリ」と進みます。

     
  3. あとは、流れにそってテスト環境にWordPressをインストールします。

    インストール手順書はCPIのオンラインヘルプを参照ください。「WordPressのインストール

 

テスト環境にWordPressをインストールすることができましたので、この環境で開発作業を進めます。

 

公開環境にWordPressをインストール

 

開発環境でWordPressの構築が終わったら、WordPressを公開環境にリリースします。
公開環境へのリリースは、今後のサイト運用を考え、テスト環境と公開環境でデータベースを分ける設定とします。
まずは一旦、公開環境にWordPressをインストールします。

  1. ユーザーポータル にログインし、ウェブコントロールパネルを開きます。
  2. ウェブコントロールパネルの「公開サイト用設定 > ソフトライブラリ」と進みます。
  3. あとは、流れにそってテスト環境にWordPressをインストールします。

    手順書はCPIのオンラインヘルプを参照ください。「WordPressのインストール

公開環境にWordPressのインストールが完了いたしました。

 

設定ファイル(wp-config.php)の調整

 

テスト環境と、公開環境のデータベースをコピーして運用しますが、テスト環境にはテスト環境用のURLがありますし、公開環境には公開環境用のURLがあります。

WordPressがそれぞれの環境で誤動作を行わないように下記の設定を行います。

  1. WordPressをインストールした直下の「wp-config.php」を編集します。
  2. 下記のコードを追加

    テスト環境(テスト環境のURLを指定)

    define('WP_HOME', 'http://USER_ID.smartrelease.jp/');
    define('WP_SITEURL', 'http://USER_ID.smartrelease.jp/');
    

    公開環境(公開環境のURLを指定)

    define('WP_HOME', 'https://example.com/');
    define('WP_SITEURL', 'https://example.com/');

SmartReleaseでwp-configファイルの同期を除外設定

上記で作成したWordPressの設定ファイルが、テスト環境と公開環境で同期しないように除外設定をします。

  1. SmartReleaseのコントールパネルにログインし、「リリース、ファイル転送」の除外設定に、「wp-config.php」ファイルを追加します。

 

以上で、環境の準備が整いました。

 

WordPressを公開環境へ移行

 

プラグインインストール

WordPressのリリース作業後にURLの書き換えが必要です。URL書き換え用にプラグイン「Search & Replace」をインストールしておきます。

  1. テスト環境のWordPress管理画面より「プラグイン > 新規追加」から「Search & Replace」を追加し、「有効化」します。

ファイル転送

続いて、開発環境に設置したWordPressを公開環境に移行します。

  1. SmartReleaseコントールパネルから「リリース > すべてリリース」から、ファイルを全て、公開環境に置き換えます。
    (注意)「すべてリリース」を行うと、公開環境にだけに設置したファイルが消えますのでご注意ください。

 

データベースのコピー

次にデータベースをコピーします。

  1. SmartReleaseのコントロールパネルから「バックアップ > お使いのデータベース > バックアップ」をクリックし、データベースのバックアップを取得します。

     
  2. しばらくすると「手動」バックアップが表示されるので「リストア」をクリックします。

     
  3. 上部の選択欄からテスト環境のデータベースファイルを選択し、下部の選択欄に公開環境のデータベースを選択し、リストアをクリックします。

 

しばらくすると、テスト環境のデータベースが、公開環境にコピーされます。

 

データベース情報の書き換え

データーベースがコピーされましたが、公開環境のデータベースにテスト環境のURLもコピーされました。
このままですとWordPressが誤動作を起こすので、テスト環境のURLを全て、公開環境のURLに書き換えます。

  1. 公開環境のWordPress管理画面にログインし、Search & Replaceプラグインにアクセスし、Search & Replaceタブを開きます。
    下記の通り設定を行い「Do & Search Replace」をクリックします。
    Search for : テスト環境のURLを入力
    Replace with : 公開環境のURLを入力

     

以上で、テスト環境のURLが書き換わり移行が完了しました。

 

サイト運用が始まったら

 

サイト運用が始まり、テストで開発したものを公開にあげる場合、上記手順の作業中に、サイト表示が不安定になります。
(ファイルコピー後に、データベースをコピーしているため)

ファイルとデータベースをコピーしている間の15分程度ですが、サイト表示が不安定になりますので、メンテナンス中画面を出すと良いでしょう。
メンテナンス画面を表示するには、プラグインを使い表示します。

メンテナンスモードプラグインは「Maintenance Mode」で検索をすると、プラグインが沢山でてきます。
インストール数や、星の数を参考にプラグインを選定すると良いでしょう。

 

 

さいごに

 

WordPressのアップデートは、デフォルトではコアのマイナーアップデート及び、翻訳ファイルが自動で実施されます。
WordPress Codexの情報より)

コアのメジャーアップデートは自動で実施されませんので、安全のために一旦テスト環境でアップデートしてから、公開環境で適用することをオススメします。

CPIのACE01は、標準でテスト環境と、公開環境が使えるのでWordPressを運用するサーバーとして最適だと考えています。

 

関連タグ: 

WordPress + WAF + Site Guard Pluginで安全なサイトを構築する方法

$
0
0

WordPressを導入したが、セキュリティ対策について不安という方も多いのではないでしょうか。
近年WordPressを狙ったハッキングが増えてきていますので、しっかりとセキュリティ対策を実施し、皆様のウェブサイトを守ってください。

今回の記事ではWordPressを悪意ある攻撃から守るために必要なWAFと、Site Guardについてご紹介します。

 

目次

 

WAFについて

 

WAF(ウェブアプリケーションンファイアウォール)は、Webサイトの脆弱制をついた攻撃からサイトを守ります。

動的コンテンツを設置したウェブサイトの場合、XSS対策、SQLインジェクション対策、CSRF対策など様々な脆弱性を考慮しながらサイト構築をする必要があります。
人が作るプログラムには、脆弱性ゼロの完璧なプログラムはできないでしょうし、運用上セキュリティアップデートが出てから、本番に適用するまで数日かかる場合もあります。

脆弱性が無いプログラム作成を心がけることに加えて、WAFを導入することで、安全なウェブサイトを構築することができます。

(*) WAFの読み方は「ワフ」です。

 

WAFの利用料

 

WAFの利用はレンタルサーバーに標準装備されている場合は無料で使うことができます。ついていない場合はクラウド型のWAFを契約したり、サーバーにWAFをインストールしたりすることで利用することができます。

昨今のレンタルサーバーにはWAFが標準装備されており、基本無料で使えますので、案件の必須要件に入れても良いのかなと思っています。

 

 

WordPressにWAFを導入

 

ここからはCPIのACE01にWordPressを導入し、WAFを設定する方法をご紹介します。
WordPressのバージョンは2019年1月時点の最新版 5.0.3を使います。

利用する環境

  • WordPress5.0.3
  • サーバー:ACE01

WordPressインストール

WordPressの導入はCPIオンラインヘルプの、WordPressのインストールを参照ください。
CMSインストーラーを利用しますので、簡単にインストールすることができます。

 

WAFの利用

WAFの利用は、CPIのACE01を利用している場合は、デフォルトでOnになっています。
WordPressをインストール後、カスタマイズし、表示確認や、記事投稿が正常にできる場合は設定完了です。

 

Forbidden accessが表示される場合

WordPressのカスタマイズをしていると、導入するPluginの種類によって、Forbidden accessが表示されることがあります。

WAFが原因でページが表示できないという理由でWAFを無効にしてしまう方がいますが、WAFを無効にするのではなく、除外設定を実施してください。

 

WAF除外設定

ACE01のウェブコントロールパネルにログインし「制作ツール > WAF」から、ログの表示を行います。

上記のサンプルでは、URL「******.smartrelease.jp/wp/」で、「s=%3Cscript%3Ealert%28%27hoge%27%29%3C%2Fscript%3E」 に 対して、「xss-tag-1」 というシグネチャでブロックされているのがわかります。

シグネチャとは、不正な攻撃パターンの種類です。

クエリを指定して除外設定

SiteGuard_User_ExcludeSig_With_ParamName [ シグネチャ ID|シグネチャ名|urldecode|all|clear] [パラメータ名 ]

記述例

SiteGuard_User_ExcludeSig_With_ParamName xss-tag-1 s

上記の例の場合「s」クエリのみ、xss-tag-1 を除外することができます。

 

下記ログのようにクエリが付いていない場合は、2つの除外方法があります。

 

ファイルを指定する場合

<Files ~ "sample\.php$">
  SiteGuard_User_ExcludeSig xss-tag-1
</Files>

sample.php の xss-tag-1 は除外になります。

 

今回の場合は「/ckeditor/xss」ディレクトリですので上記方法での除外はできません。
Apacheの設定ファイル、httpd.conf が操作できるのであれば、ディレクトリを指定して除外することも可能です。

<Directory "/var/www/html/ckeditor/xss">
  SiteGuard_ExcludeSig xss-tag-1
</Directory>

しかしCPIのACE01はhttpd.conf の設定を変更ができないので、次のように除外します。

 

「/ckeditor/xss」フォルダを作成します。その中に「.htaccess」を設置し、WAFの除外設定を記述します。

SiteGuard_ExcludeSig xss-tag-1

面倒ですが、この設定作業を行うことで、特定の箇所でのみWAFの除外設定を実施することができ、その他はWAFを有効に保てます。

 

SiteGuard WP Plugin

 

WAFの設定に加えて「SiteGuard WP Plugin」を有効にすることで、さらにセキュリティを強化することができます。

WordPressの管理画面にログインし、プラグインからSiteGuard WP Pluginを「有効化」します。

有効化するだけで、ログインURLが変更になったり、ログイン画面に入力項目が増えたりして、不特定多数を狙った攻撃に、かなり有効に作用します。

 

 

さいごに

 

WordPressにWAF、SiteGuard WP Pluginを導入し、サイトを安全に運営する方法でした。

WAFはオフにしないで除外設定を利用する。SiteGuard WP Pluginは有効にする。
と、いうことを実施することで、簡単に安全なサイトを構築することができ、不特定多数を狙った攻撃からは、かなり有効に作用します。

WordPressがハッキングされるケースが多発していますので、実施を心がけてください。

 

 

 

あってよかったSmartRelease!!~バックアップ編~

$
0
0

SmartReleaseは2012年5月に「ウェブ制作を超ラクにする」をコンセプトに、CPIの共用レンタルサーバーACE01の標準機能としてリリースされた、ウェブ制作時のトラブルを未然に防ぐサーバーツールです。

-SmartReleaseの詳細はこちら:https://www.cpi.ad.jp/shared/smartrelease/

 

SmartReleaseの機能

  • 本番環境と同一環境のステージング環境の提供
  • クリック操作だけで本番環境とステージング環境のデータ転送可能
  • Web30世代、DB10世代、毎日の自動バックアップ、リストア機能

 

2019年5月に7周年を迎えるSmartReleaseですが、お客様から「SmartReleaseがあって助かった!」という声を数多くいただいています。特に多いのが「間違って消してしまったデータをかんたんに復元できた」などの、バックアップ、リストア機能に関することです。

そこでみなさまに質問です。

 

バックアップは重要ですか?

 

おそらくこの問いに「NO」と答える人はいないでしょう。

 

バックアップを定期的に取得し、なおかつリストアの手順を把握していますか?

 

では、この問いに対してはどうでしょうか?ドキッとしたひともいるのではないでしょうか。だれしもが重要性を理解しているはずなのに、「いざという時」の備えというものはついつい忘れがちになるものです。

忘れいても忘れていなくても、あなたにかわって毎日バックアップを取得し、いざというときのリストアもかんたん。それがSmartReleaseです。

 

そこで今回、とある企業と、制作会社とのバックアップに関するやりとりを簡単な物語にしてみました。この物語はフィクションですが、実際にいただいた声をもとに作成しています。

どうぞ、おたのしみください。

 

A社とWeb制作会社B社のケース

 

A社は自社で企画、開発、製造までを行う雑貨のメーカーだ。

直販は行っておらず、これまでWebによる情報発信に力を入れてこなかったが、3年ほど前に制作会社の提案を受けコーポレートサイトをリニューアルし、続けてブログによる情報発信を開始した。

当初アクセスは思うように伸びなかったが、担当者がブログの記事に工夫を重ねた結果、今やWeb系メディアやSNSなどでしばしば取り上げられるまでになり、社内からのブログへの評価と期待は日に日に増しつつあった。

 

ある日、A社のWeb専任担当者である阿部は、先日公開したばかりのブログ記事に商品価格が誤記されていることに気が付いた。

 

阿部:「しまった、さすがに価格の間違いはまずい。」

 

時計をみて時間を確認する。16:00開始の企画会議まで、あと10分しかない。阿部は慌てて修正に着手する。企画会議は数時間に及ぶこともあり、いったん会議に入ると修正が大幅に遅れてしまう。阿部はどうしても会議前の修正を完了させたかった。

 

阿部:「よし!修正できた。すぐに保存だ!」

 

慌てながら「保存」をクリックしたつもりの阿部。しかし、実際にクリックしたのは「保存」ではなく「削除」だった。

 

 

「削除します。よろしいですか?」のメッセージもむなしく、阿部の瞳には「はい」しか映っていない。阿部はマウスのカーソルを最短距離で「はい」に合わせ、マウスの左クリックを小刻みに連打する。そして、ついに「はい」が押され、記事は削除されてしまった。

 

阿部:「よし、できた。おっと時間だ。会議室へ急がなきゃ」

 

サイトを目視確認することなく、ノートパソコンの上に資料を重ね、左わきに抱えながら慌てて会議室に急ぐ阿部だった。

 

数時間後.....

 

満足気な顔でデスクに戻って来た阿部。新企画についての反応は概ね好評であり、大きな手ごたえを感じていた。

 

時計に目をやると、時間はすでに18:00をまわっている。一息つき、何気なくブログを開いた阿部は異変に気付いた。先ほど修正したはずの記事が丸ごと消えているのだ。

 

阿部:「嘘だろ??」

 

何かの間違いかと思いブラウザをリロードするも、やはり記事は消えたままだ。焦った阿部はスマートフォンの充電ケーブルをやや乱暴に抜き取り、発信履歴を辿って制作会社B社の担当者山田宛に電話を入れる。

 

制作会社B社はA社のコーポレートサイト、ブログサイトを制作した会社だ。納品後もWebマーケティング支援から、バックアップなどを含めた運用・保守契約を締結している。

 

阿部:「山田さんですか?遅い時間にすみません。実はなにもしていないのにブログの記事が消えてしまったのです。もとに戻せないでしょうか?」

 

電話を受けた山田は、阿部とは対照的に落ち着いた声で回答する。

 

山田:「ちょっと見てみますね、対処できそうならすぐに着手します。少々お時間ください」

 

山田は電話を切り、即座にA社のウェブサイトを確認する。確かに最近アップロードされていたはずの記事が消えていた。A社と締結している保守契約はデータのバックアップ、緊急時のリストアも含まれており、ただちに対応する必要がある。

 

だが「データが消える」という事は極めて重大な出来事だ、対応には非常に神経を使う。なぜなら、

「誰かがバックアップを取っているだろうと全員思っていたが、実は誰も取っていなかった」

「バックアップを保存している外付HDDの故障に誰も気づいていなかった」

「バックアップはあるのにリストアの手順書が無く、だれもリストアできない」

 

など、バックアップに関するトラブルには枚挙にいとまがないからだ。

特に制作会社Bはデザイナーやプログラマーが中心であり、このような対応は本来得意分野ではない領域だ。しかし、山田は慌てることなくA社のSmartReleaseのコントロールパネルにログインし、バックアップデータを確認する。

 

山田:「よし、今日の昼頃までは記事があったことはこの目で確認している。昨日の夜に取得された最新のバックアップファイルでリストアしてみるか。」

 

山田はリストア作業に着手する。SmartReleaseなら難しいコマンドラインの操作も必要なく、クリック操作だけリストアが可能だ。

リストア開始を確認後、山田は引き出しからコーヒー豆をおもむろに取り出し、ケトルのスイッチを入れ、コーヒーミルにコーヒー豆を投入する。 

 

山田:「昼からコードの書きっぱなしだ、このタイミングで一息入れるか」 

 

挽き立てのコーヒー豆の香りが味わいながら、フィルタにコーヒー豆を入れるころ、ケトルから暖かい蒸気がゆらゆらと顔を出し始めた。山田は蒸気をじっと見つめていると、その直線上にあるディスプレイのわずかな動きにふと気付いた。目線をディスプレイにやると、リストア完了のメッセージが表示されていた。

 

山田:「おっと、もうリストアできたのか。コーヒーを入れる時間もないな」

 

山田はただちにサイトのチェックにとりかかる。A社のブログサイトを開くと、削除された記事が無事復元されていた。

 

山田:「よかった。記事が戻ってる。阿部さんも心配しているだろうから、すぐに連絡しなきゃな」

 

山田はスマートフォンの充電ケーブルをやさしく抜き取り、着信履歴を辿って阿部へ電話を入れる。

 

山田:「阿部さんですか??データが復元できましたので、確認お願いします。」

 

阿部:「たった今確認したところでした!!ところで価格が間違ったままなのですが??今日の昼過ぎに修正したはずなのに?」

 

山田:「申し訳ありませんが、その時点までしか戻せませんでした。お手数ですが、ご自身で修正していただけますか??」

 

阿部:「わかりました!ありがとうございました!すぐに修正します!」

 

というが早いか、すぐに電話を切る阿部。

 

山田:「なるほど、記事を修正しようとして間違って削除したのかな?そういや、俺も新人の時にデータ消しちゃったことがあったな。あの時もしSmartReleaseがあったら、あんなに冷や汗かくことはなかったのに。」

 

そうつぶやき、山田は再び席を立つ。

 

コーヒーをいれようと手に取ったマグカップにふと目をやると、山田は何かに気づいたように動きを止めた。懐かしそうなまなざしの先には、マグカップにプリントされた、長年使っているせいか少し消えかかっているA社のロゴがあった。

毎日のようにコーヒーを飲むために使っているそのお気に入りのマグカップは、取引開始直後に阿部からもらったA社のノベルティだったことを思いだす。

 

山田:「考えたら、A社との付き合いも丸3年か。取引開始直後はいろいろ大変だったけど、あれからA社の売り上げも順調だし、うちも従業員はずいぶん増えたよな。これからも一緒になって事業を伸ばしていけたらいいな。」

 

しばらく想い出にふけった後「おっと、ゆっくりしている場合じゃないな。早いところこっちの仕事も片づけなきゃ」とマグカップをデスクに置き、中断していた仕事を再開する。

すでに蒸気を出さなくなったケトルと、挽き立てでなくなったコーヒー豆を置き去りにして。

 

 

いかがでしたでしょうか

 

繰り返しとなりますが、この物語はフィクションです。

ただし、実際のお客様のお声をもとにしていますので、

同じようなことを経験された方は多いのではないでしょうか?

 

今回はSmartReleaseのステージングサーバーを利用していないケースでしたが、もしステージングサーバーを利用し、本番公開前に社内の関係者でサイトをチェックするというフローがあれば、公開前に価格の誤記に気づくことができたかもしれません。

 

ACE01を利用しているけど、SmartReleaseをあまり積極的に使ったことが無いという

お客様も、これを機に活用をご検討されてはいかがでしょうか。

そして、ACE01を使ったことがないという方も、この記事がきっかけとなりACE01に興味を持っていただければ、とてもうれしいです。

 

関連タグ: 

Bootstrap4のNavbarお手軽カスタマイズ方法

$
0
0

Bootstrap4の特設サイトにNavbar(ナビゲーションメニュー)のカスタマイズに関する記事を4点追加しました。

追加記事

Bootstrap 4のNavbarクリック時にメニューを閉じる方法

Bootstrap 4のNavbarの高さを調整する方法

Bootstrap 4のNavbarをフルスクリーンにする方法

Bootstrap 4のバーガーメニューアイコンを変更・調整する方法
 

 

Bootstrap 4のNavbar(ナビゲーションメニュー)は、とても便利ですが、デフォルトのままですと、少しだけカッコ悪いですよね。

私がBootstrapを使い、サイト構築するときに、よく改修する点にを主にピックアップしました。

 

 

関連タグ: 

httpからhttpsリダイレクト時のFacebook、はてブの引き継ぎ方法

$
0
0

常時SSL導入時に、httpから、httpsへのリダイレクトを行うと、Facebookのいいねや、はてなのブックマークは、URL変更にともないゼロに戻ってしまいます。
これを引き継ぐ方法をご紹介します。

 

Facebook

Facebookの公式サイトにも掲載がありますが、og:urlを「http://~」に変更し、 http:// から、https:// のリダイレクトをFacebookクローラーの場合のみ、除外します。

HTMLのog:urlを http://~ にする

<meta property="og:url" content="http://example.com/">

 

.htaccessを編集

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1.1) [NC]
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*$) https://shared-blog.kddi-web.com/$1 [R=301,L]
  </IfModule>

3行目が、Facebookのクローラーを除外する記述で、それ以外はhttp://~ を https://~ にリダイレクトする方法です。

 

確認方法

Facebook Debugerを使い、デバッグをしてください。
下記の通り、Input URLが「https」、og:urlが「http」になっていれば設定完了です。

変更されない場合は、「Scrape Again」ボタンをクリックしてください。

 

はてなブックマーク

はてなブックマークの場合は、ボタン作成用のページから、保存するURLを「http://」のアドレスにし、サイトに設置してください。

 

以上で、Facebookのいいねや、はてなのブックマークを引き継ぐことができます。

 

 

 

関連タグ: 

WordPressのマルウェアを削除する方法

$
0
0

WordPressは利用者数が多いことから、WordPressを狙った攻撃が多く、ハッキングされる件数も多いのが現状です。
WordPressセキュリティ対策強化の基本にWordPressのハッキング件数や、対策方法を掲載していますので、合わせてお読みください。

ですので、WordPressを使っている場合は、定期的なマルウェアのスキャンや、脆弱性診断を行うと良いでしょう。
自社サイト経由から被害が出ないか、不安に思っているサイトオーナーや、制作者は一度お試しください。

 

目次

 

 

WordPressのスキャン

 

Securiのサイトチェックにアクセスし、WordPressサイトのスキャンをしてください、

スキャンが完了すると、下記の通りメッセージが出力されます。
少し分かりにくいですが「Our scanner did'nt detect any malware」が表記されていれば、マルウェアーは検出されませんでした。

 

マルウェアが検出されると下記の通り警告が出ますので、指示に従いマルウェアーを削除してください。

引用:https://sucuri.net/guides/how-to-clean-hacked-wordpress

 

Google セーフブラウジングのサイト

https://transparencyreport.google.com/safe-browsing/search」からサイトをスキャンし確認、サイトをチェックしてください。

 

マルウェアを削除する

 

SmartReleaseのバックアップから戻す

まずは最も簡単な方法で、SmartReleaseのバックアップから過去の状態に戻す方法です。

(ご注意)この操作を行うとサイト全体が過去の状態に全て戻ります。

  1. SmartReleaseのコントロールパネルにログインし、バックアップを開きます。
     
  2. 公開サイトタブから、ウェブデータをリストアし、データベースタブ(MySQL5.5や、5.6)から、データベースをリストアします。

    ファイルやフォルダが全て削除されます。とメッセージが表示されていますが、マルウェアも同時に削除されます。

 

手動で削除

  1. まずはSmartReleaseからバックアップを取得してください。
  2. SSHを利用して、サーバーのコンソールにログインします。
    SSHの利用方法はCPIのオンラインヘルプを参照ください。

    下記のコマンドを実行し、最近書き換えられたファイルが無いかを確認します。
    下記では過去15日以内に更新されたファイルを抽出します。

    find ./ -type f -mtime -15
    


     

  3. 抽出されたファイルに心当たりが無い場合は、ファイルを削除するか、ファイルを確認します。
    ファイルの確認はWordPressのコアファイルと、diffを実行し、どの行が書き換わっているかを確認すると良いでしょう。

    疑わしいファイルが見つかれば、そのファイルをWordPressの公式からダウンロードした、ファイルで上書きを行います。
     

  4. ファイル修正後、サイトの動作確認を行います。

 

WordPreesのユーザー

WordPressの管理画面にログインし、疑わしいユーザーが登録されていないか確認をしてください。
確認し、登録した覚えが無い場合は削除を行い、WordPressの管理者パスワードを念のため変更をしてください。

 

 

さいごに

 

WordPressのマルゥエアを削除するには、バックアップから戻すのが一番手取り早いです。
何か更新する前にバックアップを取得する、更新後にバックアップを取得することで、すぐに戻すことができます。

また、マルウェアが入ってこないための対策も重要ですので、合わせて「WordPressセキュリティ対策強化の基本」を参照ください。

 

関連タグ: 

Internal Server Error HTTP500 解決方法

$
0
0

ウェブサイトを閲覧中に「Internal Server Error HTTP 500」が表示されたことはありますでしょうか。
急にこんなエラーがでてきたら、何か悪いことをしたかと、ドキドキしてしまいますよね。

今回の記事では、「Internal Server Error HTTP 500」とは何か、HTTP500の解決方法をご紹介いたします。

 

Internal Server Error HTTP 500 とは

 

Internal Server Error HTTP 500 とは、閲覧しているウェブサーバー上でエラーが起きており、ウェブサイトが正しく表示できない状態のエラーコードです。

サイトの閲覧者は何もすることができないので、しばらくたってから接続し直してください。

 

PHP エラー時の解決方法

 

PHPが原因で、HTTP500エラーが出力される場合は、PHPのエラー出力をOnに設定変更し、どこでエラーが出ているかを確認します。
(注意)この設定変更は記述を間違えると、全てのページでエラーになりますので、必ずテストサーバーで検証してください。

CPIサーバーの場合

php.iniファイルを、ウェブサーバーに設置し、下記コードを変更します。
(php.ini設置方法はCPIオンラインヘルプ「PHPの設定変更方法」を参照ください)

display_errors = Off 
↓↓↓下記に変更
display_errors = On

.htaccessに記述する場合

* CPIサーバーの場合動作いたしません。

.htaccessに下記のコードを追記します。

php_flag display_errors on

 

上記コードを追加するとPHPのエラー原因、ファイル名、行数が表示されます。
このエラーをヒントにプログラムを修正してください。

エラー解除後はPHPのエラー出力をオフに戻してください。

 

その他でエラーがある場合

 

その他でエラーがある場合は、サーバーのログを確認すると良いでしょう。
CPIサーバーの場合は「/log/ssl-error_log」か、「/log/httpd-error_log」を確認ください。

[日時] [alert] [client 60.***.***.***] /usr/home/****/html/test/.htaccess: Invalid command 'php_flag'

上記のようにエラーが確認できましたら、ログをヒントにソースコードを修正してください。
今回の場合は「.htaccess」にエラーがあるようです。

 

さいごに

 

HTTP500エラーが出力される場合は、プログラムのどこかに記述ミスがあることがほとんどです。
エラー出力や、ログ確認を行うか、最近修正したファイルを確認すると良いでしょう。

最近修正したファイルは、サーバーコンソールにログインし下記コマンド実行すると、確認することができます。

find ./ -type f -mtime -15

サーバーコンソールへのログインはCPIオンラインヘルプを参照ください。

 

関連タグ: 

Not found 404 エラーの原因と対策と確認方法

$
0
0

ウェブサイトを閲覧中に表示される「Not found 404 エラー」が表示されたことはないでしょうか。
今回の記事では「Not found 404 エラー」とは何かと、解決方法をご紹介いたします。

 

Not found 404 エラー とは

 

Not found 404 エラーとは、アクセスしたURL(ウェブサイトのアドレス)に、表示するページが無い場合に、エラーが出力されます。
一般的にはリンク切れや、URLの打ち間違え、間違ったリダイレクト処理をしている時に起こります。

CPIスタッフブログの場合下記ページが表示されます。

ウェブサイト閲覧者は、アクセスしたURLに間違えがないか確認をしてください。
確認したURLに間違えがない場合は、しばらく経ってから、サイトにアクセスし直してください。

 

自社サイトのNot found 404 エラー確認方法

 

自社サイトで「Not found 404 エラー」がどれくらい出力されているかの確認はGoogle Analyticsを使うと確認することができます。

  1. Google Analyticsにアクセスします。
  2. 「行動 > サイトコンテンツ > ランディングページ」にアクセスします。
  3. セカンダリディメンションに「ページタイトル」を追加します。

     
  4. セカンダリ ディメンション欄の「アドバンス」をクリックし、ページタイトルで絞り込みを行います。

    ページタイトルは、実際にNot found 404 エラーページを表示させ、そのタイトルを入力してください。
     

  5. 実際にユーザーがNot found 404 エラーになっているURLを確認することができます。

 

解決方法

 

Not found 404 エラーの解決方法は、リンク切れを無くすことが重要ですので、上記でエラーページを確認し、そのリンクを修正するだけです。

リンクを修正してもURLの打ち間違えなどで「Not found 404 エラー」が出力されることもあります。
そのような場合のために「Not found 404 エラー」ページを用意し、サイト内のコンテンツ一覧を表示することで離脱率を軽減することができます。

Not found 404 エラーページの用意

.htaccessを設置し、下記のコードを追加します。

ErrorDocument 404 https://example.com/404.html

上記コードを追記することで、サーバー内部でページが見つからない場合に、404.htmlを表示します。

 

 

関連タグ: 

CPIサーバー + CDNで、お手軽高機能、セキュアサーバー構築方法

$
0
0


共用型サーバーを借りているが急なトラフィックが心配だったり、セキュリティに対して不安を感じたりする方も多いのではないでしょうか。
今回の記事ではCPIの共用型レンタルサーバーACE01 + CDNを導入し、急なトラフィックの対策や、セキュリティを強化できる構成の紹介と、導入方法をご紹介いたします。

CPIのお客様でも、ACE01とCDNを組み合わせ、サイトを運用している方も多く存在します。

 

目次

 

CDNとは

 

CDNとはContent Delivery Networkの略で、コンテンツを効率よく配信するための仕組みです。

ユーザー(Webサイトの閲覧者)が、https://example.com」にアクセスをすると、そのユーザーから近いCDNからコンテンツが配信されます

CDNは世界に複数台配置されており、アクセスが負荷分散され、急なトラフィックでも、Webサーバー(オリジン)への負荷を最小限にすることができます。

またユーザー(Webの閲覧)からのリクエストにはCDNが返答をしますので、Webサーバー(オリジン)の存在を隠すことができます。そのためCDNを導入することで、不特定多数からの攻撃を効果的に遮断することができます。

CDN導入で得られる効果

  • 急なトラフィックに対応できる
  • セキュアな構成が構築できる

その他、高可用性(対障害性)など、様々な効果がありますが、全て書いていると長くなるので、これ以上の情報は、その他のサイトを参照ください。

 

CDN導入方法

 

まずはCDN事業者を選定します。CDN業者は数多くあり、よく使われているのは下記ではないでしょうか。

 

今回はこれら事業者の中からレッドボックスとCPIの共用型サーバーACE01を使い、導入方法をご紹介いたします。
なぜレッドボックスをご紹介するかというと、レッドボックスは国内ベンダーで、面倒な設定はレッドボックスが行います。

さらに、料金が定額で、毎月固定の利用料を支払います。日本の商習慣上、利用した分だけ利用料を払うというより、固定金額の方が楽ですよね。

 

CDN導入手順

それでは実際に、テストURL「cdn-test.mochiya.co」に対してCDNを導入します。
(CPIサーバーは契約していて、cdn-test.mochiya.coにサイトがある想定です。)

  1. レッドボックスに申し込みをします。
    レッドボックスは申し込みからサービス利用開始まで最短で2営業日。そこからキャッシュの設定などを合わせると4営業日くらいでサイトに組み込むことができます。
     
  2. 申し込みが完了すると、CDNのURLと、レッドボックスのコントロールパネルのIDとPWが発行されます。
    [CDN URL例] user0004.cdnw.net
     
  3. DNS変更

    CDNのURLが発行されたら、
    cdn-test.mochiya.co のAレコードを削除し、CDNのURL( [例]user0004.cdnw.net )をCNAMEに登録します。

     

  4. CMSの管理画面がキャッシュされないよう設定を申し込みます。

    CMSの管理画面をキャッシュしなようにする理由は、管理者がサイト管理するために開いたページがキャッシュされ、一般のユーザーにも閲覧できてしまうためです。
    そのために、WordPressの場合「/wp-admin」、Drupalの場合「/admin」などが管理画面のURLになりますので、キャッシュされないように設定します。
    設定は、レッドボックスにWordPressを使うので、管理画面をキャッシュしないでと、お問い合わせフォームなどから依頼するだけです。
    (なんて楽なんでしょう)

    本来であれば、「/wp-admin」以外にも、RSSや、記事のプレビュー画面など、管理画面で使う箇所を除外する必要があります。

以上で、CDNの設定は完了です。

 

Webサーバー(オリジン)と、管理画面のアクセス制限

CDNを導入すると、Webの閲覧にはCDNがコンテンツを返答をします。ですのでWeb閲覧者は、Webサーバー(オリジン)へのアクセスは不要になります。
まずはWebサーバー(オリジン)へアクセスできるユーザーをCDNのみに制限します。

  1. Webサーバーの「/.htaccess」を編集し下記のコードを追加します。
    	SetEnvIf X-redbox-Auth KEY-NUMBER allow-cdn # レッドボックスを許可
    	order deny,allow
    	deny  from all
    	allow from env=allow-cdn

X-redbox-Authは、レッドボックスが独自に発行するヘッダー情報です。KEY-NUMBERは、レッドボックスを契約後に設定していただきます。
この設定で、WebサーバーにはCDNからしかアクセスができなくなります。

 

管理画面にアクセスできるユーザーを特定のIPのみに制限をかけます。

例として「/admin」ディレクトリに制限をかけます。

  1. 「/admin/.htaccess」ファイルを作成します。
  2. 下記のコードを追加します。
    SetEnvIf X-Forwarded-For 127.XXX.XXX.XXX allowip
    SetEnvIf X-Forwarded-For 157.XXX.XXX.XXX allowip
    order deny,allow
    deny  from all
    allow from env=allowip

    通常のIP制限は、allow from 127.XXX.XXX.XXX のように記述をしますが、CDNなどを経由した場合のユーザーのIPは「X-Forwarded-For」で判定ができます。

特定のIP以外はWebサーバー(オリジン)にアクセスができなくなります。

 

 

負荷検証

 

負荷検証はApache Benchや、JMeterを使うことで、サーバーの性能を評価することができます。
(実際に負荷検証を行う場合は、レットボックスに一声かけてくださいとのこと)

では、実際にどれくらいのリクエスト数に対応できるようになるかと言いますと、こちらもレッドボックスに相談すると、想定のリクエスト数や、アクセスのシミュレーションから、適切にチューニングをしてくれます。

ではジャブ程度に、2000リクエスト投げてみます。

ab -n 2000 -c 200 http://cdn-test.mochiya.co/

Failed request : 0
Requests per second : 426.14 [#/sec]
Time per request : 469.325 [ms]

同時に2000リクエストなげて、エラーが0でした。
2000リクエストを処理するのにかかった時間は、Time per request: 469.325[ms] (mean) でした。1秒は1000msですので、1秒以内に2000リクエストに応答しています。

これを単純に計算すると下記のとおり、リクエストを処理することができます。

1分:12万リクエスト
1時間:720万リクエスト
1日:1億7千万リクエスト

なかなか良い結果であることが分かるかと思います。

ご注意

上記数値はあくまでも単純に計算した数値で、数値を保証するものではございません。
サイトの性質や、導入するプランにより応答可能なリクエストが変わってきますので、導入前に一度ご相談ください。

 

レッドボックスの管理画面から、リアルタイムで現在のキャッシュヒット率や、リクエスト数を確認することができます。
約2000リクエストで、キャッシュヒット率が100%ですので、Webサーバー(オリジン)に負荷がかかっていないことが分かります。

 

さいごに

 

今回の記事では、CPIの共用型レンタルサーバーACE01と、レッドボックスの組み合わせをご紹介させていただきました。
共用型レンタルサーバーでも組み合わせ方次第では、急なトラフィック対応や、セキュアな環境構築を行うことができます。

お手軽に、高トラフィックに耐えられて、セキュアな環境が構築できるのはウェブ担当者にとって魅力的ですよね。
ぜひ、今回の構成を参考にしていただけると幸いです。

 

関連リンク

使用したWebサーバ : CPI ACE01
使用したCDN : レッドボックス

 

関連タグ: 

あってよかったSmartRelease!!~バックアップ編~

$
0
0

SmartReleaseは2012年5月に「ウェブ制作を超ラクにする」をコンセプトに、CPIの共用レンタルサーバーACE01の標準機能としてリリースされた、ウェブ制作時のトラブルを未然に防ぐサーバーツールです。

-SmartReleaseの詳細はこちら:https://www.cpi.ad.jp/shared/smartrelease/

 

SmartReleaseの機能

  • 本番環境と同一環境のステージング環境の提供
  • クリック操作だけで本番環境とステージング環境のデータ転送可能
  • Web30世代、DB10世代、毎日の自動バックアップ、リストア機能

 

2019年5月に7周年を迎えるSmartReleaseですが、お客様から「SmartReleaseがあって助かった!」という声を数多くいただいています。特に多いのが「間違って消してしまったデータをかんたんに復元できた」などの、バックアップ、リストア機能に関することです。

そこでみなさまに質問です。

 

バックアップは重要ですか?

 

おそらくこの問いに「NO」と答える人はいないでしょう。

 

バックアップを定期的に取得し、なおかつリストアの手順を把握していますか?

 

では、この問いに対してはどうでしょうか?ドキッとしたひともいるのではないでしょうか。だれしもが重要性を理解しているはずなのに、「いざという時」の備えというものはついつい忘れがちになるものです。

忘れいても忘れていなくても、あなたにかわって毎日バックアップを取得し、いざというときのリストアもかんたん。それがSmartReleaseです。

 

そこで今回、とある企業と、制作会社とのバックアップに関するやりとりを簡単な物語にしてみました。この物語はフィクションですが、実際にいただいた声をもとに作成しています。

どうぞ、おたのしみください。

 

A社とWeb制作会社B社のケース

 

A社は自社で企画、開発、製造までを行う雑貨のメーカーだ。

直販は行っておらず、これまでWebによる情報発信に力を入れてこなかったが、3年ほど前に制作会社の提案を受けコーポレートサイトをリニューアルし、続けてブログによる情報発信を開始した。

当初アクセスは思うように伸びなかったが、担当者がブログの記事に工夫を重ねた結果、今やWeb系メディアやSNSなどでしばしば取り上げられるまでになり、社内からのブログへの評価と期待は日に日に増しつつあった。

 

ある日、A社のWeb専任担当者である阿部は、先日公開したばかりのブログ記事に商品価格が誤記されていることに気が付いた。

 

阿部:「しまった、さすがに価格の間違いはまずい。」

 

時計をみて時間を確認する。16:00開始の企画会議まで、あと10分しかない。阿部は慌てて修正に着手する。企画会議は数時間に及ぶこともあり、いったん会議に入ると修正が大幅に遅れてしまう。阿部はどうしても会議前の修正を完了させたかった。

 

阿部:「よし!修正できた。すぐに保存だ!」

 

慌てながら「保存」をクリックしたつもりの阿部。しかし、実際にクリックしたのは「保存」ではなく「削除」だった。

 

 

「削除します。よろしいですか?」のメッセージもむなしく、阿部の瞳には「はい」しか映っていない。阿部はマウスのカーソルを最短距離で「はい」に合わせ、マウスの左クリックを小刻みに連打する。そして、ついに「はい」が押され、記事は削除されてしまった。

 

阿部:「よし、できた。おっと時間だ。会議室へ急がなきゃ」

 

サイトを目視確認することなく、ノートパソコンの上に資料を重ね、左わきに抱えながら慌てて会議室に急ぐ阿部だった。

 

数時間後.....

 

満足気な顔でデスクに戻って来た阿部。新企画についての反応は概ね好評であり、大きな手ごたえを感じていた。

 

時計に目をやると、時間はすでに18:00をまわっている。一息つき、何気なくブログを開いた阿部は異変に気付いた。先ほど修正したはずの記事が丸ごと消えているのだ。

 

阿部:「嘘だろ??」

 

何かの間違いかと思いブラウザをリロードするも、やはり記事は消えたままだ。焦った阿部はスマートフォンの充電ケーブルをやや乱暴に抜き取り、発信履歴を辿って制作会社B社の担当者山田宛に電話を入れる。

 

制作会社B社はA社のコーポレートサイト、ブログサイトを制作した会社だ。納品後もWebマーケティング支援から、バックアップなどを含めた運用・保守契約を締結している。

 

阿部:「山田さんですか?遅い時間にすみません。実はなにもしていないのにブログの記事が消えてしまったのです。もとに戻せないでしょうか?」

 

電話を受けた山田は、阿部とは対照的に落ち着いた声で回答する。

 

山田:「ちょっと見てみますね、対処できそうならすぐに着手します。少々お時間ください」

 

山田は電話を切り、即座にA社のウェブサイトを確認する。確かに最近アップロードされていたはずの記事が消えていた。A社と締結している保守契約はデータのバックアップ、緊急時のリストアも含まれており、ただちに対応する必要がある。

 

だが「データが消える」という事は極めて重大な出来事だ、対応には非常に神経を使う。なぜなら、

「誰かがバックアップを取っているだろうと全員思っていたが、実は誰も取っていなかった」

「バックアップを保存している外付HDDの故障に誰も気づいていなかった」

「バックアップはあるのにリストアの手順書が無く、だれもリストアできない」

 

など、バックアップに関するトラブルには枚挙にいとまがないからだ。

特に制作会社Bはデザイナーやプログラマーが中心であり、このような対応は本来得意分野ではない領域だ。しかし、山田は慌てることなくA社のSmartReleaseのコントロールパネルにログインし、バックアップデータを確認する。

 

山田:「よし、今日の昼頃までは記事があったことはこの目で確認している。昨日の夜に取得された最新のバックアップファイルでリストアしてみるか。」

 

山田はリストア作業に着手する。SmartReleaseなら難しいコマンドラインの操作も必要なく、クリック操作だけリストアが可能だ。

リストア開始を確認後、山田は引き出しからコーヒー豆をおもむろに取り出し、ケトルのスイッチを入れ、コーヒーミルにコーヒー豆を投入する。 

 

山田:「昼からコードの書きっぱなしだ、このタイミングで一息入れるか」 

 

挽き立てのコーヒー豆の香りが味わいながら、フィルタにコーヒー豆を入れるころ、ケトルから暖かい蒸気がゆらゆらと顔を出し始めた。山田は蒸気をじっと見つめていると、その直線上にあるディスプレイのわずかな動きにふと気付いた。目線をディスプレイにやると、リストア完了のメッセージが表示されていた。

 

山田:「おっと、もうリストアできたのか。コーヒーを入れる時間もないな」

 

山田はただちにサイトのチェックにとりかかる。A社のブログサイトを開くと、削除された記事が無事復元されていた。

 

山田:「よかった。記事が戻ってる。阿部さんも心配しているだろうから、すぐに連絡しなきゃな」

 

山田はスマートフォンの充電ケーブルをやさしく抜き取り、着信履歴を辿って阿部へ電話を入れる。

 

山田:「阿部さんですか??データが復元できましたので、確認お願いします。」

 

阿部:「たった今確認したところでした!!ところで価格が間違ったままなのですが??今日の昼過ぎに修正したはずなのに?」

 

山田:「申し訳ありませんが、その時点までしか戻せませんでした。お手数ですが、ご自身で修正していただけますか??」

 

阿部:「わかりました!ありがとうございました!すぐに修正します!」

 

というが早いか、すぐに電話を切る阿部。

 

山田:「なるほど、記事を修正しようとして間違って削除したのかな?そういや、俺も新人の時にデータ消しちゃったことがあったな。あの時もしSmartReleaseがあったら、あんなに冷や汗かくことはなかったのに。」

 

そうつぶやき、山田は再び席を立つ。

 

コーヒーをいれようと手に取ったマグカップにふと目をやると、山田は何かに気づいたように動きを止めた。懐かしそうなまなざしの先には、マグカップにプリントされた、長年使っているせいか少し消えかかっているA社のロゴがあった。

毎日のようにコーヒーを飲むために使っているそのお気に入りのマグカップは、取引開始直後に阿部からもらったA社のノベルティだったことを思いだす。

 

山田:「考えたら、A社との付き合いも丸3年か。取引開始直後はいろいろ大変だったけど、あれからA社の売り上げも順調だし、うちも従業員はずいぶん増えたよな。これからも一緒になって事業を伸ばしていけたらいいな。」

 

しばらく想い出にふけった後「おっと、ゆっくりしている場合じゃないな。早いところこっちの仕事も片づけなきゃ」とマグカップをデスクに置き、中断していた仕事を再開する。

すでに蒸気を出さなくなったケトルと、挽き立てでなくなったコーヒー豆を置き去りにして。

 

 

いかがでしたでしょうか

 

繰り返しとなりますが、この物語はフィクションです。

ただし、実際のお客様のお声をもとにしていますので、

同じようなことを経験された方は多いのではないでしょうか?

 

今回はSmartReleaseのステージングサーバーを利用していないケースでしたが、もしステージングサーバーを利用し、本番公開前に社内の関係者でサイトをチェックするというフローがあれば、公開前に価格の誤記に気づくことができたかもしれません。

 

ACE01を利用しているけど、SmartReleaseをあまり積極的に使ったことが無いという

お客様も、これを機に活用をご検討されてはいかがでしょうか。

そして、ACE01を使ったことがないという方も、この記事がきっかけとなりACE01に興味を持っていただければ、とてもうれしいです。

 

Navbarの高さを調整する方法:Bootstrap 4

$
0
0

 

Bootstrapの構築を行うと、Navbar(ナビゲーションバー)の高さを、高くしてほしいと言われることが多いです。
今回はお手軽にできるNavbarの高さを変更します。

サンプル

 

高さ調整

最もお手軽に高さを調整するには、BootstrapのSpacingクラスを利用します。

Spacing プロパティ

  • m : margin(マージン)をセット
  • p : padding(パディング)をセット

場所

  • t : margin-top or padding-top
  • b : margin-bottom or padding-bottom
  • l : margin-left or padding-left
  • r : margin-right or padding-right
  • x : both *-left and *-right
  • y : both *-top and *-bottom
  • blank : 全ての場所

サイズ

  • 0 : 0
  • 1 : デフォルト の 0.25倍
  • 2 : デフォルト の 0.5倍
  • 3 : デフォルト
  • 4 : デフォルト の 1.5倍
  • 5 : デフォルト の 3倍
  • auto : auto

利用例

mt-4 : margin-topをデフォルトの1.5倍に指定
p-5 : paddingをデフォルトの3倍に指定

挿入箇所は、「nav」タグに対して、padding(p-*)を入れます。

<nav class="navbar navbar-expand-lg navbar-light bg-light p-4">
サンプル画像

今回は手軽にNavbarの高さを高く調整しましたが、低くする場合は、p-1、p-2を指定ください。

 

Viewing all 131 articles
Browse latest View live