Web・メールの所有

この状態なら読む

次のような会社を対象にします。

• ホームページ制作会社へドメイン取得から任せた
• DNS、Webサーバー、メール設定も同じ業者が管理している
• ドメインをどのレジストラで契約しているか分からない
• 登録名義、管理者ID、MFA、復旧先メールアドレスを自社で把握していない
• 更新費用は制作会社からまとめて請求されている
• 業者を変更したいが、Webやメールが止まりそうで触れない

制作会社へ運用を委託すること自体が問題なのではありません。

問題は、制作作業を任せている状態と、事業継続に必要な契約・管理権限まで自社から見えなくなっている状態が混ざることです。

このページでは、制作会社との関係を維持したまま、最低限どこを自社で把握すればよいかを整理します。

最初に「ドメイン・DNS・Web・メール」を分ける

「ホームページを全部制作会社に任せている」と一括りにすると、何を移管すべきか判断できません。

まず次の単位へ分けます。

同じ制作会社が全部を担当していても、契約や管理画面は別サービスである場合があります。

したがって、最初から「全部自社へ移す」と考えるより、対象ごとに現状を記録します。

「所有者」ではなく、まずドメインの登録者と契約主体を見る

ドメインについては、日常会話で「所有者」という表現が使われます。

ただし実務上は、誰がレジストラとの登録契約の主体になっているか、誰が管理画面へ入り、更新や移管を行えるかを確認した方が具体的です。

ICANNは、ドメイン名の登録者をドメイン名を登録する個人または組織とし、その登録者がレジストラとの契約主体になると説明しています。

そのため、自社サイトのドメインであっても、制作会社や担当者個人が登録者になっている場合は、次を確認します。

• 登録者は誰か
• レジストラはどこか
• 登録者や管理連絡先のメールアドレスは誰が受信するか
• 管理画面へ誰がログインできるか
• MFAは誰の端末にあるか
• 更新費用は誰が支払うか
• 更新期限はいつか
• 移管に必要な操作を誰ができるか

「自社の名前がWebサイトに表示されている」ことと、「ドメイン登録を自社で管理できる」ことは別に確認します。

更新期限は請求書だけで管理しない

ICANNは、ドメインを使い続け、関連するWebサイトやメール等のサービスを継続するには、期限前にレジストラで更新する必要があると説明しています。

制作会社から年1回請求が届く運用でも、最低限、自社側でも次を記録します。

• ドメイン名
• レジストラ
• 更新期限
• 自動更新の有無
• 支払方法
• 更新通知の送信先
• 請求担当者

制作会社への支払いが止まった、担当者が退職した、メールアドレスが廃止された、といった出来事が、そのままドメイン更新漏れへつながらないようにします。

制作会社へ作業権限を渡すことと、管理主体を任せ切ることを分ける

制作会社には、日常運用のために十分な権限が必要な場合があります。

たとえば、

• DNSレコードを変更する
• Webサーバーへデプロイする
• CMSを更新する
• SSL/TLS証明書の設定を行う
• メール設定を変更する

といった作業です。

ここでの改善方向は、制作会社の権限を一律に取り上げることではありません。

自社側に最低限の管理経路を残したうえで、制作会社へ必要な作業権限を付与します。

たとえば、

• 契約名義と請求先は自社
• 自社の管理者アカウントを1つ以上確保
• 制作会社には担当者用アカウントを発行
• 共有パスワードではなく個別アカウントが使えるなら分ける
• MFAや復旧先を制作会社担当者1人だけへ集中させない

という形です。

サービスによって権限分離の機能は異なるため、実際に使っているサービスの仕様に合わせます。

ドメインを移せるかは平常時に確認する

ICANNは、ドメイン移管を開始するには登録者または管理連絡先であることが必要と説明しています。

そのため、制作会社との契約終了を決めてから初めて移管方法を調べると、必要なメールアドレスや管理画面へ入れないことがあります。

平常時に次だけ確認しておきます。

• レジストラの管理画面へ入れるか
• 登録者・管理連絡先を確認できるか
• 自社が受信できる連絡先が登録されているか
• ドメインロック等の状態を確認できるか
• 移管手続きの開始方法を把握しているか

実際に移管する必要がなくても、「必要になれば誰がどの画面から始められるか」まで分かれば、外部依存をかなり可視化できます。

DNSを先に触らない

現状が不明な会社では、いきなりDNSを移管したり設定変更したりしない方が安全です。

DNSには、Webだけでなくメールや各種クラウドサービスの設定が含まれている場合があります。

先に現在の状態を記録します。

最低限、

• DNSを管理しているサービス
• 管理者
• 現在のレコード
• Webサイトの接続先
• メールの接続先
• サービス所有確認等に使っているレコード

を控えます。

そのうえで、移管対象と残す対象を決めます。

Webホスティングは「ログインできる」だけでは足りない

WebサーバーやCMSについては、管理画面へ入れるだけでなく、別の業者へ引き継げる材料があるかを確認します。

たとえば、

• HTML、CSS、JavaScript等の制作物
• CMSのデータ
• 画像や添付ファイル
• データベース
• テーマやプラグイン
• 独自設定
• ビルド・デプロイ方法
• バックアップ
• ライセンス

です。

制作会社独自の仕組みで、その会社以外では動かせない場合もあります。

それ自体を直ちに否定する必要はありませんが、契約終了時に何を受け取れるかは確認しておきます。

メールはドメインと別に管理主体を確認する

メールアドレスが自社ドメインでも、メールサービスの契約や管理者が制作会社側にある場合があります。

確認したいのは、

• メールサービス名
• 契約主体
• 全体管理者
• 各利用者アカウント
• MFA
• パスワード・アカウント復旧経路
• DNS設定を変更できる主体
• 契約終了時のメールデータ取得方法

です。

ドメインだけ自社へ移しても、メールサービスの管理者が不明なままなら、問題は残ります。

逆に、メール環境が自社管理でも、DNS変更を制作会社しかできないなら、メール設定変更時に外部依存が残ります。

一気に移管せず、支配点から戻す

関係が良好な制作会社に対して、突然すべてのアカウント移管を求める必要はありません。

次の順序で進めると、変更範囲を抑えやすくなります。

1. 現状を聞く

まず一覧を作ります。

• ドメイン
• レジストラ
• DNS
• Webホスティング
• メール
• SSL/TLS証明書
• CMS
• 分析・広告等の周辺サービス

それぞれについて、契約主体、管理者、請求先、更新期限を記録します。

2. 自社の連絡先を入れる

可能なら、更新通知、請求、管理者復旧等へ自社が受信できるメールアドレスを追加します。

制作会社の担当者メールだけに依存しない状態にします。

3. 自社管理者を確保する

サービスが複数管理者に対応しているなら、自社側にも管理者を作ります。

日常作業は制作会社へ任せたままでも構いません。

4. ドメイン登録の主体を確認する

制作会社名義や担当者個人名義になっている場合は、契約関係と今後の運用を確認したうえで、自社を登録主体にする必要があるか判断します。

5. 必要なものだけ移管する

DNSやホスティングまで自社へ移す必要があるとは限りません。

自社が保持すべき支配点と、外部業者へ委託した方が合理的な運用作業を分けます。

最低限の引継ぎ表を作る

次のような表が1枚あれば、担当者変更時の確認がかなり容易になります。

パスワードそのものをこの表へ書く必要はありません。

「どの資格情報をどこで管理しているか」を示せれば十分です。

制作会社へ確認するときの聞き方

「全部のパスワードをください」だけでは、必要な情報が抜けます。

たとえば次を確認します。

• 弊社ドメインのレジストラと登録者を教えてください
• 更新期限と更新方法を教えてください
• DNSを管理しているサービスを教えてください
• 弊社側の管理者アカウントを追加できますか
• Webホスティングの契約主体とバックアップ方法を教えてください
• メールサービスの全体管理者は誰ですか
• 担当変更や契約終了時の引継ぎ手順を教えてください

これは制作会社を疑うためではなく、担当者交代や災害、廃業等でも継続できるようにするための確認です。

会社側で持つべき最低ライン

小規模な会社でも、少なくとも次が説明できる状態を目指します。

• 自社ドメインのレジストラ
• ドメインの登録主体
• 更新期限と支払経路
• DNSを変更できる主体
• Webホスティングの契約主体
• メールの全体管理者
• 自社側の管理者または復旧経路
• 制作会社との契約終了時に必要な引継ぎ物

すべてを自社だけで操作できる必要はありません。

重要なのは、外部業者へ運用を委託していても、自社が何を契約し、誰がどの管理権限を持ち、必要ならどう引き継ぐかを説明できることです。