サーバーとCMSの推奨設定 :: Concrete CMS マニュアルサイト

サイト構築と具体的なCMSのハード化

インフラ

考えるべきポイント

本番前には必ずテストすること！

Concrete CMS を構築する方向けの推奨設定の紹介ページです。
Concrete CMS公式サイト（英語）より翻訳しています。
この情報はバージョン8、バージョン9共通です。

サイト構築と具体的なCMSのハード化

あなたのサイトのために書いたコードも安全であることを確認するために時間を費やしてください。
※ 開発者は https://documentation.concretecms.org/developers/security/overview をチェックしてください。

ここでは、サイトを公開する際に役立つチェックリストをご紹介します。
これらの推奨事項のほとんどは、セキュリティ強化のための推奨事項ですが、いくつかの「常識的な」指摘も含まれています。
ウェブサーバー自体の設定方法に関する提案は、包括的なものではないことに注意してください。
私たちはConcrete CMSの専門家であり、お客様のウェブサーバーの専門家ではありません。
お使いのウェブサーバのベストプラクティスに従うことをお勧めします。

インフラ

TLS 1.2以上を使用していることを確認します。
http を https にリダイレクトします。
HSTSを設定します（HTTPSをサポートしないサブドメインがある場合、HSTSヘッダで矯正されるので、"includeSubDomains"ディレクティブを省略する必要があります)
サイトの前にCDNがあること、キャッシュが最適化されていることを確認します。
あなたが持っているモニタリングツールにサイトを追加します。
ウェブサーバ（Nginxなど）でxframeセキュリティ・オプションが適切に設定されていることを確認します。
ウェブサーバ（Nginxなど）のポリシーに、/application/files ディレクトリからのコード実行を防止するよう設定します。つまり、/application/files および Concrete で設定したその他のパブリックストレージの場所からのファイルのみを静的に提供するようにウェブサーバを設定します。
ウェブサーバ（Nginxなど）のポリシーで、index.phpという名前のファイルは、Webルート以外では実行されないように設定します。
ウェブサーバ（Nginxなど）のポリシーで、index.php以外のphpファイルを実行できないように設定します。
ウェブサーバー（例：Nginx、apache）のディレクトリブラウジングが無効になっていることを確認します。
ウェブサイトからメールを送信する場合、SMTPプロバイダを設定し、サイトが指すドメインからメールを送信できるようにします。(例 no-reply@ [あなたのサイトのドメイン])
該当する場合は、レート制限を有効にします。
Concrete ログは、デフォルトでデータベースに入ります。ウェブサイトのホストとして使用しているサーバーの別の場所にも書き込みたい場合は、それを設定することができます。
ログを記録する対象を設定します。
- フォームのデータをログに記録しますか？
- デフォルトでは、メールのメタデータとメール本文の両方がログに含まれます。メールのメタデータだけログに記録するかどうかは、次の管理画面ににアクセスして設定することができます。
```
/dashboard/system/mail/logging
```
Webルートにテストファイル、バックアップ、その他の非本稼働コードが含まれていないことを確認してください。
Web Application Firewall (WAF)を導入していることを確認してください。
Concrete CMS のバージョンが 9.0.0 未満の場合、Cross-Origin-Resource-Policy ヘッダーの設定を same-origin または same-site に設定してください。
- どちらを適用するか不明な場合は、https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP) を参照してください。
- Nginxの場合：ロケーションブロック内に - add_header Cross-Origin-Resource-Policy "same-origin" を記述してください。
- Apacheの場合： .htaccessまたはそれに相当する部分に - Header set Cross-Origin-Resource-Policy "same-origin" を記述してください。
管理者がファイルをアップロードすることを懸念している場合、アップロードされたファイルディレクトリ /application/files/*　に対して、画像は画像として、それ以外はプレーンテキストとして提供するようにウェブサーバを設定します。
- 例：htmlファイルについては、.htmlファイルをtext/plain（使用している任意のウェブサーバの文書を参照）として提供するようにウェブサーバを設定するか、あるいは下記のCMSセクションで説明するようにhtmlアップロードができないようサイトを構成することをお勧めします。
Concrete CMSはアップロードされたファイルディレクトリにキャッシュを保存します。もしこれが気になるなら、次の管理画面へのアクセスを無効にしてください。
```
/application/files/cache/expensive
```

CMS

サポートされている最新バージョンの Concrete CMS をダウンロードしていることを確認してください。
https://www.concretecms.org/download
- これには、ウェブサイトからダウンロードしたzipファイル、全く別の方法で更新されるコンポーザーベースのインストール、または管理画面からの更新が含まれます。
- 以下はその手順です。https://documentation.concretecms.org/developers/introduction/installing-concrete-cms
お使いのConcrete CMSのバージョンでサポートされている最新バージョンのPHPを使用してください。
あなたのサイトが開発されたとき、Webアプリケーションを保護するための推奨事項が守られていましたか？そうでない場合、あなたのサイトを開発した人に https://documentation.concretecms.org/developers/security/overview を確認してもらいましょう。
Concrete CMS の管理画面で、
- 本番サイトの開発デバッグ出力をオフにします。
```
/dashboard/system/environment/debug
```
- カノニカルURLを適切なurlに設定します。(そうしないと、あなたのサイトは、ハッカーがパスワードリセットのリクエストを自分の選んだサーバーにリダイレクトする「パスワードリセットポイズニング」を起こす可能性があります)。
- リダイレクト先がカノニカルURLであることを確認してください。
- TLS/HTTPSでのみレンダリングするようにサイトを設定します。
- アップロードしたファイルに一般にアクセスできるようにするかどうかを決定します。
  そうでない場合は、サイトルート外のディレクトリに正しいパーミッションを設定し、プライベートな保存場所を設定します。ファイルへのアクセスを許可するユーザーを制御するために、具体的なパーミッションを使用します。
  ファイルを保護するために、ファイルのパスワードに依存しないでください。ファイルのパスワードはプレーンテキストで保存されます。
  新しいディレクトリは、Concrete CMSの管理画面の設定の「保管場所」を使用して指定する必要があります。管理画面 > システムと設定 > ファイル > ファイルの保存場所から、「Protected Storage」という名前の新しい保存場所を追加し、それを「Local」タイプにして、Webルート外のディレクトリの場所を指定します。また、新しくアップロードされたすべてのファイルのデフォルトの場所となるように設定します。
- デフォルトのパスワードのセキュリティ設定を確認し、必要であれば変更してください。
```
/dashboard/system/registration/password_requirements
```
- 管理者用パスワードが長く、複雑であることを確認してください。
- 訪問者を既知のIPアドレスのリストにロックダウンするかどうかを検討します。その場合は、IPアドレスのブラックリスト/ホワイトリストを設定します。
- 管理者と編集者が持つ役割の種類に応じて特定のユーザーグループを設定し、そのグループにユーザーを割り当ててアクセス権を付与します。
  可能な限り、必要最小限の権限を持つグループを設定します。例えば、コンテンツ編集者は、管理画面のすべてにアクセスできる管理者として設定するべきではありません。
- セキュリティ要件を満たすように、閲覧権限と編集アクセスを設定します。
- 許容されるファイルの種類を必要最低限に設定します。
```
/dashboard/system/files/filetypes
```
- 自動ログアウトの設定がセキュリティ要件を満たしていることを確認します：サイトで許可したい最大ログイン試行回数を設定します。
```
/dashboard/system/registration/automated_logout
```
- 推奨されるアカウントオプション
```
/dashboard/system/registration/open
```
  - 管理者のみが管理画面からアカウントを作成できるようにします。「訪問者がサイトメンバーとして登録できるようにする」でオフを選択します。
  - ユーザー名ではなく、メールアドレスでログインするように設定します（「ログインフォーム」で「メールアドレスとパスワードを要求する」を選択）
  - reCaptchaが設定されていることを確認します。登録フォームで「CAPTCHAが必要」を選択し、/dashboard/system/permissions/captcha に移動します。
- 管理者が特定の種類のファイルをアップロードすることを懸念している場合、
  - htmlのアップロードを防ぐようにConcreteサイトを設定することができます。同じように、許可されたファイルの種類から除外することで、アップロードを拒否するようにConcreteサイトを設定することができます。
    https://documentation.concretecms.org/user-guide/editors-reference/dashboard/system-and-maintenance/files/allowed-file-type
  - 管理者が許可する拡張子のリストをカスタマイズできないようにしたい場合は、application/config ディレクトリに concrete.php というファイルを作成し、許可するファイルの種類を指定することができます。
XフレームセキュリティオプションをNginxなどのWebサーバーで処理している場合、Concrete CMSでXフレームセキュリティオプションを無効にする必要があります（下記のコマンドを実行します)
```
./vendor/bin/concrete5 c5:config set -g concrete.security.misc.x_frame_options null 
```
Concrete CMSのバージョン番号が非表示になっていることを確認します。ジェネレータタグがConcrete CMSのバージョン番号を隠すように設定されていることを確認します。(Concrete CMS バージョン 8.5.6+ および 9.0+ では、この設定はハードコーディングされています）
- WebサイトのヘッダーレスポンスにConcrete CMSのバージョン番号が表示されないことを確認します。
  - ブラウザの開発者ツールのネットワークセクションを見て、CCM_IMAGE_PATHを検索することで確認できます。
  - 管理画面からアップグレードすると、新しいコアが /updates ディレクトリにダウンロードされ、そこからコアを参照するように Concrete 自体が構成されます。このため、/concrete ディレクトリを新しいバージョンと入れ替え、/updates ディレクトリにダウンロードしない Composer のインストールとデプロイを推奨します。
  - composerを使用せず、ヘッダレスポンスのCCM_IMAGE_PATH変数からConcreteのバージョン番号を削除する必要がある場合、
    - CCM_IMAGE_PATH のバージョン番号を削除するためにフォルダをリネームしてください。
    - 次のファイルで、古いフォルダ名の代わりに新しいフォルダ名を参照します:
      applicationconfig.php
WebサイトとConcrete CMSを社内のシステムリストとRole Based Access Controlに追加します。具体的なパーミッションとアクセスレベルの変更要求を、会社の手順を使用して慎重に検討します。

考えるべきポイント

Concrete CMSのログインを社内のSSOに統合することを検討してください。ConcreteはデフォルトでGoogle認証に対応しています。
ユーザーが設定可能な日数ログインしていない場合、または設定可能な回数ログインに失敗した場合、自動的にユーザーを無効化することを検討してください。
```
/dashboard/system/registration/deactivation
```

本番前には必ずテストすること！

あなたのサイトが思い通りに機能することを確認しましょう。特にConcrete CMSのバージョンアップの際には、このことが言えます。
お気に入りの負荷テストツールを使って、本番環境の負荷を事前にテストしてください。
ウェブアプリケーションスキャナーがあれば、それを実行します。
サポート対象のブラウザ（Firefox、Chrome、Safari、Edgeなど）でコンソールエラーが発生していないことを確認します。
デフォルトの「from」メールが「no-reply@ [ サイトドメイン ]」になっていることを確認しましょう。そうしないと、この機能をテストした人がスパムメールを受け取ることになります。
あなたのウェブサイトにはファビコンがありますか？
トラッキングコードを配置しましたか？
CNAMEとAレコードの両方をチェックしてください。
サイトは両方に応答し、1つにリダイレクトする必要があります。