COLUMN
CMSの権限設定｜デモ用アカウントで書き込みを止めたのは16画面だけだった
コンテナのデモ環境では、申し込んだ方に本物の管理画面へログインしてもらっています。
そのアカウントで書き込みを止めたのは、管理画面のうち16画面だけです。
記事の作成・編集・画像のアップロード・固定ページの組み立てといった、ふだんの更新作業はすべて実際に試せます。
「全部見せたい。でも壊されたくない」。
この2つを両立させるために、どの画面を止め、どの操作を許すかを1つずつ決めました。
このコラムでは、その線引きの中身と、途中で見つけた落とし穴を書きます。
CMSの権限設定で「誰に何を触らせるか」を考えている運営者の方の参考になればと思います。
デモ用の管理画面アカウントに、何を許して何を止めるか
デモ環境は、製品サイトとは別のデータベースで動く、同じCMSの写しです。
画面も機能も本番と同じなので、触ってもらえば使い心地はそのまま伝わります。
そのぶん、設定を1つ変えられただけで、次に申し込んだ方の画面まで崩れてしまいます。
最初に決めたのは、「見るのは全部よい。確定させる操作だけ止める」という考え方です。
一覧や詳細、編集フォームを開くところまでは、どの画面でも許しました。
止めるのは、保存・削除・実行のように、データが変わる操作です。
フォームを開けないと、その機能で何が設定できるのかが分からないからです。
止める・止めないの判断は、「その操作が、他の人の画面に影響するか」で分けました。
記事を1本書き換えても、困るのは書いた本人だけです。
ユーザーやメニュー、サイト全体の設定を変えると、次にログインした全員の画面が変わります。
この差が、そのまま線を引く場所になりました。
書き込みを止めたのは、ユーザー・権限と設定・システムの16画面
止めた16画面は、大きく3つのまとまりです。
- ユーザー・権限まわりの6画面（ユーザー、グループ、パスワード変更、関係者、マイページ、ログイン履歴）
- 設定・システムまわりの8画面（環境設定、メニュー、リダイレクト、システム管理、データ初期化、SCSS、プラグイン、サーバー情報）
- デモを使ったお客さまの声で、あとから止めた2画面（お知らせ・マニュアル、ショートコード）
3つめの2画面は、最初は書き込みを許していました。
デモを使ったお客さまから、お知らせとショートコードも止めてほしいという声をいただき、7月6日に止めました。
お知らせは管理画面のトップに出るので、誰かが書き換えると、次の方のデモの第一印象が変わってしまいます。
ショートコードは、サイトのあちこちに同じ部品を差し込む仕組みなので、1か所変えると多くのページに響きます。
どちらも「他の人の画面に影響する」側だったのに、最初の線引きで見落としていました。
画面だけでなく、画面の裏で動く7つのAPIも同じように止めました。
画面の保存ボタンを止めても、裏の通り道が開いたままだと、同じ書き込みができてしまうからです。
ユーザー登録・プラグイン・SCSS・管理画面の配色・プッシュ通知などが、ここに入ります。
もう1つ気をつけたのが、URLを開くだけで実行される操作です。
管理画面には、リンクを押すと削除や並べ替えが走るものがあります。
そこで、URLの中に「削除」「実行」「バックアップ」「取り込み」など27種類の操作名が入っていたら、保存と同じように止めることにしました。
「編集フォームを開く」「新規作成のフォームを開く」は、見るだけの操作なので、この27種類には入れていません。
見ることも止めたのは、サーバー情報の1画面だけ
「見るのは全部よい」の例外が、サーバー情報の画面です。
この画面は、PHPの設定を一覧で出します。
その中には、データベースへの接続に使う情報のような、サーバーの環境変数も含まれます。
表示するだけでも、外の人に見せてはいけない値が画面に出てしまいます。
そのため、この1画面だけは、開くこと自体を止めました。
デモの目的はCMSの使い心地を知ってもらうことなので、サーバーの中身が見えなくても困ることはありません。
同じ理由で、環境設定の画面に並ぶ値のうち、APIキー・トークン・パスワードのような秘密の値は、伏せ字で表示しています。
項目の名前に「key」「token」「secret」「password」などが含まれるものを、まとめて伏せる作りです。
ユーザー一覧のログインIDも、同じように伏せています。
画面の形は見せて、値だけを隠すという分け方です。
削除は「自分が追加したものだけ」にした
記事や固定ページのようなコンテンツは、書き込みを許しています。
ここで悩んだのが削除です。
削除まで自由にすると、用意しておいたサンプル記事が消され、次の方が見るものが無くなります。
削除を全部止めると、「消したらどうなるか」を試せません。
そこで、削除できるのは、そのアカウントが自分で追加した記事や画像だけにしました。
データには「誰が登録したか」が残っているので、削除のときにその条件を自動で足しています。
自分で書いた記事は、作って、直して、消すところまで一通り試せます。
最初から入っているサンプルは、何度デモをしても残ります。
押せないボタンは灰色にして、理由を画面の下に出した
止めた操作のボタンが、押してから「できません」と返ってくるのは、使う側にとって不親切です。
そこで、止めている画面では、保存・削除・実行のボタンを最初から灰色にして、押せないようにしました。
画面の下には、ゲストとしてログインしていることを示す帯を出しています。
それでも止めた操作に届いた場合は、元の画面へ戻します。
画面の裏の通り道から届いたときは、「ゲストモードのため、この操作は制限されています。」と返します。
ボタンを灰色にするのは見た目の工夫で、本当に止めているのはサーバー側です。
見た目だけで止めると、ボタンを使わずに直接送られたときに書き込めてしまうからです。
権限を印1つで切り替える作りにしたら、順番の落とし穴があった
最初は、「guest」という名前のアカウントだけを制限する作りでした。
7月13日に、ユーザー管理の画面でチェックを1つ付けたユーザーを制限する作りに変えています。
これで、名前に関係なく、アカウントごとに制限をかけたり外したりできるようになりました。
このとき、最初の管理者アカウントだけは、チェックを付けられないようにしました。
画面からチェック欄を消し、サーバー側でも必ず外す作りです。
管理者まで制限されると、制限を外す人がいなくなるからです。
切り替えの準備で、もう1つ落とし穴が見つかりました。
チェックを覚えておく欄をデータベースに足す前に、新しいプログラムを置くと、全員がログインできなくなります。
欄を足しても、今の「guest」アカウントにチェックを付け忘れると、そのアカウントの制限が外れます。
そのため、欄を足す、今のアカウントに印を付ける、プログラムを置く、の順番を切り替えの手順に書きました。
権限の仕組みを変えるときは、新しい作りそのものより、切り替えの順番で事故が起きやすいと私は思います。
社内でCMSの権限設定をするときに、私たちが勧める分け方
ここまで書いたゲスト用の制限は、デモ環境のために足したものです。
ふだんの運用では、コアに入っているユーザー・グループの権限で同じ考え方ができます。
グループごとに「使えるメニュー」と「編集できるフォルダ」を決め、ユーザーをそのグループに入れる作りです。
デモで線を引いた経験から、私たちが勧めるのは次の3段の分け方です。
- 書く人：記事と固定ページの編集だけ。担当する部署のフォルダに絞る
- 公開する人：書く人の記事を確かめて公開する。公開申請の承認を持つ
- 設定を触る人：ユーザー・メニュー・環境設定・プラグイン。社内で1〜2人に絞る
判断の軸は、デモのときと同じで「その操作が、他の人の画面に影響するか」です。
迷ったら、まず止めておき、困ったという声が出たら開けるほうが安全だと思います。
7月6日に2画面を止めたのも、使った方の声がきっかけでした。
コンテナでは、権限はユーザー・グループ・権限管理で、グループ単位に設定できます。
書く人と公開する人を分けるときは同時編集防止・公開申請フロー、誰がいつ何を変えたかを後から追うときは操作監査ログとログイン履歴が使えます。
退職や異動のときに、ログインしたままの端末を締め出すにはログインセッション管理を使います。
セキュリティ全体の考え方は、セキュリティのページにまとめています。