小規模な制作会社を運営している場合は、ユーザー権限の管理も「運用ルール」ではなく、その場の対応で済ませてしまいがちです。管理者アカウントを共有した方が早い、MyKinstaでもサイト単位ではなく企業単位で権限を付与した方が管理しやすい、すでに業務を終えた外部委託先のアカウントも「後で削除すればいい」と、そのまま残してしまうこともあるかもしれません。
このような対応は、次第にすべての案件で繰り返される運用の「標準」になってしまいます。そして、クライアントから「この設定を変更したのは誰ですか」と問い合わせを受けたり、すでに契約が終了した委託先が本番サイトにアクセスできる状態のままだと判明したりしたときには、その問題がすべての管理サイトに広がっていることも少なくありません。
クライアントのアクセス管理は、事業の拡大とともに少しずつ複雑になる一方で、問題が表面化するまで見過ごされやすいものです。そして、気づいたときには大きなリスクにつながっていることがあります。
Kinstaでは、柔軟な権限管理機能により、アクセス権の付与や管理を制作会社の運用フローの一部として適切に管理できます。今回は、クライアントのアクセス管理の課題とポイントを掘り下げながら、MyKinstaの権限管理の仕組みをご紹介していきます。
制作会社の成長とともに広がる「アクセス権の管理漏れ」
アクセス権の管理漏れは、多くの場合、そのときは合理的だった判断が見直されないまま繰り返されることで発生します。最初は、プロジェクトのレビュー時にクライアントへ管理者アカウントを共有したり、個別のアカウントを作成する時間がなく、そのままログイン情報を渡したりといった小さな判断から始まります。
Kinstaをご利用の場合は、MyKinstaで外部委託先に権限を付与する場合にも同様のことが起こります。サイト単位でユーザーを作成する代わりに、手間を省くため企業単位の開発者の権限を付与してしまうこともあるでしょう。どちらもその場では合理的な判断ですが、制作会社の成長を見据えた運用とは言えません。
こうした判断は、その後の案件でも繰り返され、やがて運用の標準になっていきます。1年も経てば、20件ほどのクライアントサイトを管理する制作会社では、本来想定していなかったアクセス権が数多く残っていることは珍しくありません。
- 退職後もアカウントが削除されていない元従業員
- 数か月前に終了した案件の権限が残ったままの外部委託先
- 本来は必要のない会社レベルの情報まで閲覧できる状態になっているクライアント
制作会社が理解しておくべき2つの権限管理
Kinstaでは、権限管理が2つの階層に分かれています。1つはMyKinstaでサーバー環境へのアクセスを管理する権限、もう1つはWordPressでサイト内の操作権限を管理するユーザー権限です。
この2つはそれぞれ独立して機能するため、違いを理解せずに運用すると、アクセス権の設定ミスや不要な権限付与につながる可能性があります。
MyKinstaの権限と管理範囲
MyKinstaは、2つの管理レベルに分かれた6種類のユーザー権限に対応しています。それぞれの権限がどこまでアクセス・操作できるのかを理解することが、適切な権限管理の第一歩です。
MyKinstaには、以下の4つの会社単位の権限があります。
- 企業の所有者：アカウントごとに1名のみ付与できる権限。プランの解約や企業の所有権移行を実行できるのはこの権限のみ。日常的な管理機能は企業の管理者とほぼ同じだが、制作会社の代表者や責任者が持つことを想定。
- 企業の管理者：企業全体のデータやすべてのサイトに対する管理権限を持つ。サイト移行リクエストの作成に加え、請求情報の確認やプラン変更もでき、こうした業務を任せる管理者向けの権限。
- 企業の開発者：アカウント内のすべてのサイトやDNS、サイト単位のユーザーを管理できる。企業のユーザー一覧（メールアドレスや権限を含む）は確認できるが、企業単位の権限変更や請求情報の閲覧はできない。社内の開発担当者に付与する標準的な権限として適している。
- 企業の経理係：請求情報のみを確認できる権限です。請求書や会社名、住所などの情報にアクセスできるが、サイト管理は行えない。経理担当者など、請求情報だけが必要なユーザー向けの権限。
クライアントや外部委託先には、以下のサイト単位の権限を利用できます。
- サイトの管理者：指定したサイトと、そのすべての環境（本番・ステージングなど）を管理でき、対象サイトのDNS管理も可能。サイトを企業アカウントから削除したり、サイト移行を依頼したり、プレミアムステージング環境を作成したりすることはできない。
- サイトの開発者：ステージング環境のみにアクセスできる権限。本番環境へのアクセスや、ステージング環境から本番環境への反映、企業単位の情報の閲覧はできない。
サイト単位の権限は、適切なアクセス管理を実現するうえで重要な役割を果たします。ユーザーがアクセスできる範囲は1つのサイトに限定され、サイトの開発者であれば、さらにステージング環境のみに制限されるため、必要最小限の権限だけを付与しながら、安全にクライアントや外部委託先と共同作業を進めることができます。
WordPressのユーザー権限との違い
WordPressのユーザー権限は、サイト内で実行できる操作を管理するためのものであり、MyKinstaの権限とは完全に独立しています。そのため、MyKinstaへのアクセス権を持たずにWordPressだけを利用することも、またその逆も可能です。
よくある設定ミスのひとつが、同じユーザーにMyKinstaではサイトの管理者、WordPressでは管理者権限を付与してしまうことです。この場合、サーバー設定を管理できるだけでなく、WordPressではプラグインのインストールやユーザー管理、テーマの変更まで行えるようになり、必要以上の権限を与えてしまいます。
実際の役割に応じて、適切な権限を付与することが重要です。
- コンテンツを管理するクライアント → WordPressで編集者権限を付与し、MyKinstaへのアクセスは不要。
- ステージング環境で開発を行う開発者 → MyKinstaでサイトの管理者権限を付与し、必要に応じてステージング環境のWordPressで管理者権限を付与。本番公開前に権限を見直すのがおすすめ。
- 引き渡し後にサイトの管理を引き継ぐクライアント → 運用体制や必要な作業内容に応じて、MyKinstaではサイトの管理者、WordPressで管理者権限を付与。
MyKinstaとWordPressのどちらにも共通して言えることは、必要最小限の権限のみを付与することです。説明や設定の手間を省くために過剰な権限を与えてしまうと、問題が発生するまで気づかれないリスクを抱えることになります。
クライアントのアクセス管理で制作会社が陥りやすいミス
制作会社でアクセス管理の問題が発生するのは、運用方法が正しくないからではなく、その場では合理的だった判断が積み重なり、気付かないうちにリスクが生まれてしまうためです。以下、よくある誤った判断をいくつかご紹介します。
「アクセス管理は都度対応すれば問題ない」
管理サイト数が少なく、チーム構成も変わらないうちは、アクセス権を都度管理する運用でも大きな問題は起こらないかもしれませんが、案件数や関係者が増えるにつれて、この方法では管理しきれなくなります。
例えば、クライアントをサイト単位ではなく企業単位で招待し、誤って企業の開発者のような権限を付与すると、クライアントは、アカウント内のすべてのユーザーのメールアドレスや権限を閲覧できてしまいます。
また、案件用のWordPressサイトで外部委託先に管理者権限を付与すると、WordPressに登録されているユーザー情報やクライアントの連絡先を含むデータをエクスポートできる可能性があります。
どちらも重大なセキュリティインシデントとは言えないかもしれませんが、本来アクセスする必要のない情報に触れられる状態であることに変わりはありません。このようなリスクは、あらかじめプロジェクトごとの役割に応じて、MyKinstaとWordPressの権限を定義したアクセス管理ルールを用意しておくことで防ぐことができます。
| プロジェクトの役割 | MyKinstaの役割 | WordPressの役割 | 備考 |
| 制作会社の代表者・責任者 | 企業の所有者 | 管理者 | アカウントごとに1名のみ。プランの解約や企業オーナー権限の譲渡を実行できる唯一の役割 |
| シニア開発者・プロジェクト責任者 | 企業の管理者、または企業の開発者 | 管理者 | 請求情報を閲覧する必要がある場合は「企業管理者」、不要な場合は「企業開発者」を割り当て |
| 外部委託の開発者 | サイトの開発者 | 管理者（ステージング環境のみ） | ステージング環境のみにアクセス可能。本番環境への反映やステージング環境の削除は不可 |
| クライアント（コンテンツ管理担当） | なし | 編集者 | コンテンツ管理のみであれば、サーバー管理画面へのアクセスは不要 |
| クライアント（納品後のサイト管理者） | サイトの管理者 | 管理者 | 運用体制や担当範囲を踏まえ、両方の権限が必要な場合のみ付与 |
あらかじめ役割ごとの権限を決めておけば、新規案件が始まった際も、そのルールに従って権限を付与するだけで済みます。時間に追われながら「どこまで権限を与えるべきか」を毎回判断する必要はありません。
「クライアントにはできるだけ権限を与えない」
クライアントの権限を制限することは、一見するとリスク管理のように思えます。しかし、必要な作業まで制作会社が対応することになり、かえって運用負荷が高まるケースも少なくありません。
例えば、スタッフ紹介の更新やメインビジュアルの差し替え、ブログ記事の公開といった作業には、サーバーへのアクセスは不要です。
それにもかかわらず、WordPressで必要な権限を付与していない場合、こうした作業のたびに問い合わせや作業依頼が発生します。一方で、WordPressの編集者権限を付与しておけば、クライアント自身でコンテンツを更新でき、サーバー環境へアクセスされる心配もありません。
例えば、Kinstaでクライアントサイトを管理するデジタルマーケティング会社Organic Media Groupは、適切な権限管理によって運用を効率化しており、「新たにチームに加わったメンバーでも、すぐに複数のクライアントアカウントを問題なく管理できます」と述べています。
同じ考え方は、クライアントにも当てはまります。MyKinstaは技術的な知識がなくても使いやすい管理画面を備えており、役割に応じた権限を付与することで、必要な範囲だけにアクセスを制限しながら、安全に運用を任せることができます。
「これまで問題が起きていないから大丈夫」
アクセス権に関する問題は、権限を付与した直後に表面化することもあれば、数か月後に条件が重なって初めて明らかになることもあります。
例えば、半年前に終了した案件の外部委託先が、今もステージング環境へアクセスできる状態だったとしても、その担当者が変更を加えるまでは問題にならないかもしれません。また、権限を付与してから次に見直すまでの期間が長くなるほど、何がいつ起きたのかを後から把握することは難しくなります。
手動でアクセス権を削除する運用では、見落としが発生することもあります。例えば、MyKinstaからユーザーを削除しても、そのユーザーが作成したAPIキーは自動的に無効にならず、SSH/SFTP認証情報もリセットされません。
これには別途対応が必要です。APIキーを無効にするには、「企業の設定」＞「APIキー」で対象ユーザーが作成したキーを確認し、削除します。また、SSH/SFTP認証情報は、対象サイトの「情報」画面から再生成できます。いずれもユーザーを削除しただけでは処理されないため、オフボーディング時のチェック項目として運用に組み込んでおくことをおすすめします。
また、オフボーディング時には、アクティビティログを確認することも重要です。企業の管理者と企業の開発者は、ユーザー名やサイトごとにログを絞り込んで確認でき、各ログをクリックすると実行された操作の詳細を確認できます。
ユーザーを削除する前に、そのユーザー名でアクティビティログを確認しておくと、直近でどのような操作を行ったのかを把握できます。また、削除前に確認や差し戻しが必要な変更がないかをチェックする際にも役立ちます。
制作会社の成長に合わせたアクセス管理のポイント
まずは、チーム内の役割に応じた権限設計を見直しましょう。MyKinstaの「企業の設定」＞「ユーザー管理」＞「ユーザーを招待」から、新規ユーザーを追加できます。招待画面では、メールアドレスをカンマ区切りで入力することで、一度に最大10名まで招待可能です。この画面で企業単位の権限を付与するか、サイト単位の権限を付与するかを選択します。
制作会社で一般的なチーム構成であれば、以下のような権限設定がおすすめです。
- 制作会社の代表者・責任者：企業の所有者を付与
- シニア開発者やプロジェクトマネージャー：請求情報の確認が必要な場合は企業の管理者、それ以外は企業の開発者を付与（社内の技術担当者には、企業の開発者を基本とする運用がおすすめ）
- 案件ごとの外部委託先：対象サイトのステージング環境に対して、サイトの開発者を付与
- コンテンツ更新を担当するクライアント：WordPressでは編集者権限を付与（サーバー管理まで担当する契約でない限り、MyKinstaへのアクセスは不要）
サイト単位の権限（サイトの開発者など）を付与する場合は、ユーザー招待画面で「企業」ではなく「サイト」を選択します。その後、対象サイトを指定し、適切な権限を設定してください。
また、サイト運営をクライアントへ引き継ぐ場合は、運用体制や必要な権限に応じて、MyKinstaではサイトの管理者、WordPressでは管理者権限を付与します。
あわせて、アカウント全体で二要素認証（2FA）を利用することも重要です。Kinstaでは、すべてのユーザーに対して二要素認証がデフォルトで有効になり、メール認証または認証アプリによる認証を利用できます。各ユーザーが設定している認証方式は、「企業の設定」＞「ユーザー管理」の「二要素認証」欄で確認できます。複数のクライアントサイトを管理する制作会社では、適切な権限管理とあわせて、すべてのユーザーが二要素認証を利用することが、安全な運用の基本となります。
クライアントへのサイトの引き渡し
プロジェクト完了後にクライアントへサイトの所有権を引き渡す場合は、権限を変更して同じアカウント内で管理を続けるのではなく、MyKinstaアカウント間でサイトを移行することができます。
サイトを移行するには、MyKinstaの「サイト」画面で対象サイトの横にある3つの点をクリックし、「サイトの譲渡」を選択します。
次に表示される画面で、移行先のメールアドレスまたは企業IDを入力します。また、サイトとあわせて移行するDNSドメインを選択したり、クライアントにおすすめのKinstaプランを指定したりすることもできます。設定が完了したら、「サイトを譲渡する」をクリックして移行リクエストを送信します。
その後、クライアントがMyKinstaにログインすると、「サイト」画面に受け取ったサイト移行リクエストが表示されます。対象サイトを選択し、「譲渡の確定」＞「譲渡を受け入れる」をクリックすると、サイトの引き渡しが完了します。
四半期ごとのアクセス権の見直し
日々の運用では見落としがちな不要な権限を整理するためにも、アクセス権は四半期ごとに見直すのが理想的です。まずは、MyKinstaの「企業の設定」＞「ユーザー管理」を開き、登録されているユーザーを確認します。サイトごとに絞り込むことで、それぞれのクライアントサイトにアクセスできるユーザーを確認できます。
次に、現在進行中の案件と照らし合わせ、すでに終了した案件にもかかわらず権限が残っているユーザーがいないか確認しましょう。不要なユーザーは、ゴミ箱アイコンをクリックして削除できます。また、複数のユーザーをまとめて選択し、一括で削除することも可能です。
ユーザーを削除する際は、あわせて対象ユーザーが作成したAPIキーを削除し、最近担当者の変更があったサイトではSSH/SFTP認証情報も再生成されていることを確認しましょう。
アクセス管理はクライアントとの信頼関係を支える基盤
アクセス権の管理は、単なるセキュリティ対策ではありません。どのように権限を設計・運用しているかは、クライアントに対して、制作会社が明確な運用ルールのもとでサイトを管理しているかどうかを示す重要な要素でもあります。
まずは今回ご紹介した役割ごとの権限設定をもとに、自社のアクセス管理ルールを文書化し、現在管理しているサイトの権限を一度見直してみてください。不要な権限や管理漏れを洗い出すことで、将来的なトラブルを未然に防ぐことができます。
適切なアクセス管理を行うことで、外部委託先にはステージング環境だけを安全に共有し、クライアントには必要な機能だけを提供しながら、案件終了時には不要な権限を確実に削除できるようになります。このような仕組みを整えることが、制作会社の成長に合わせても安全で効率的な運用につながります。
複数のクライアントサイトを管理する制作会社には、Kinstaのエージェンシーパートナープログラムがおすすめです。専任サポートや共同販促の支援、制作会社向けに設計された各種ツールをご活用いただけます。
