クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか
誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。
運用代行会社がクライアントに示すアカウントの取り決めは、読む人の違う 3 つの文書に分けると書きやすくなります。誰でも読める基本方針、社内で守る規程(社内のルールを書いた文書)、クライアントごとに渡す説明書です。チェックシートへの回答も契約の条項も、この 3 つに決まりが書いてあれば、そこから写せます。
3 つの文書に分ける理由
IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、情報セキュリティ基本方針を、関係者に取り組みを表明する文書と位置づけています。簡潔に書き、従業員や顧客などに知らせるよう勧めています。IPA の SECURITY ACTION(中小企業が対策を自ら宣言する制度)でも、「二つ星」には基本方針の外部への公開が含まれます。
同じガイドラインの付録 5 は、規程のサンプル(以下、サンプル)です。委託先を評価する基準の候補の一つに、「情報セキュリティに関する方針を公開している」を挙げています。このサンプルで規程を作ったクライアントは、委託先の公開した方針を確かめることがあります。
一方で、アカウントの細かな扱いは公開しないのが無難です。目安は個人情報保護委員会のガイドライン(通則編)3-8-1 です。対象は、会社が自分で開示や訂正に応じる個人データ(保有個人データ)です。その守り方を、データで特定される人(本人)が知れる状態にしておくよう求めています。ただし、知られると守りに支障が出るおそれのあるものは除いてよいとし、例に「アクセス制御の範囲、アクセス者の認証手法等」を挙げています。アクセス制御で担当者と扱う範囲を限っていることは、知らせる内容の例に入っています。
預かったアカウントに、この項がそのままかかるとは限りません。委託された個人データが誰の保有個人データに当たるかは、契約などの実態で決まるからです。それでも、仕組みがあることは示し、誰がどこに入れるかと、入る人をどう確かめるかは伏せる、という線は使えます。細かな決まりは規程に置き、クライアントにはそのクライアントの分だけを説明書で渡します。
| 文書 | 読む人 | アカウントについて書くこと |
|---|---|---|
| 基本方針 | 誰でも | 預かった情報を守ることと、担当者を限って使わせていること |
| 規程 | 従業員と社外の作業者 | 預かったアカウントを誰にどう使わせるかの決まり |
| 説明書 | そのクライアントだけ | そのクライアントのアカウントごとの扱い |
基本方針に書くこと
IPA の基本方針のサンプル(付録 2)は、守る対象を「お客様からお預かりした」情報資産と「当社の」情報資産から選ぶ形です。運用代行会社なら、「お客様からお預かりした」を残すのが実態に合います。
個人情報保護委員会のガイドライン(通則編)の別添は、個人データの扱いについての基本方針を定めることを「重要である」としています。定める項目の例として、「事業者の名称」「関係法令・ガイドライン等の遵守」「安全管理措置に関する事項」「質問及び苦情処理の窓口」などを挙げています。媒体(広告や SNS などのサービス)の名前や担当者の人数は、どちらの基本方針にも書かないのが無難です。
規程のサンプルを、預かったアカウント向けに書き換える
サンプルは、色をつけた部分を自社の事情に合わせて直して使う文書です。アカウントの項目全体は別の記事にまとめています。ただし、どれも自社で ID を出して消せる前提です。預かったアカウントは持ち主がクライアントなので、そのままでは守れない決まりが主に 4 か所あります。
1 人 1 アカウントと共有の禁止(組織的対策 6.2.1)
サンプルは、アカウントを利用者 1 名につき 1 つ出し、複数人での共有を禁じています。そのうえで括弧書きで「やむを得ず共有IDが必要な場合は、共有IDを利用したユーザーを特定できるようにする」としています。預かったアカウントには、権限付与の仕組みがない媒体や、所有者の ID でしかできない操作があります。そこで、この括弧書きを本文の決まりにして、条件を書き足します。権限付与がある媒体ではそれを使い、共有で預かるのはそれ以外に限ります。共有の ID は、アカウントごとに使える人を名簿に書き、誰がいつ使ったかを記録します。媒体の規約やヘルプが共有を避けるよう求めていないかを、預かる前に確かめることも加えます。
不要になったアカウントの削除(組織的対策 6.4)
サンプルは、アカウントが不要になったら、その翌日までに削除か無効化をするとしています(期限は自社で決める部分です)。預かったアカウントでは、運用代行会社が自分では止められない場合があります。クライアントしか削除できない媒体での権限の削除や、共有の ID のパスワード変更は、クライアントに頼むことになるからです。アクセス管理ツールなら、利用の停止は自社でできます。書き換えでは、自社が行うこと(社内での利用をやめ、クライアントに依頼する)と期限を書きます。クライアントの作業が終わった日も記録します。
退職のときの返還(人的対策 3)
サンプルは、退職する従業員に、資料や機器と並べて「アクセス権(ID及び鍵)」も返させ、チェックリストで漏れを確かめるとしています。共有の ID のパスワードはその人が覚えているので、返してもらえません。退職のチェックリストには、その人が使えたクライアントのアカウントを並べます。そのうえで、預かり方ごとに止める作業(権限の削除、パスワード変更の依頼、アクセス管理ツールでの利用停止)を項目にします。担当を外れる異動でも同じ一覧を使います。
従業員以外の作業者(組織的対策 6.6)
サンプルは、従業員以外の人にアカウントを出すときは、承認を得たうえで秘密保持契約を結ぶとしています。在宅のフリーランスなどに使わせると、クライアントから見て再委託に当たることがあります。再委託とは、任された仕事をさらに別の人に任せることです。サンプルの委託管理の章(8.5)も、再委託には事前に書面で報告を受け、責任者が承認してから認めるとしています。規程には、秘密保持契約に加えて、クライアントに知らせて承諾を得る手続きを書き足します。
クライアントごとに渡す説明書に書くこと
説明書は、規程の決まりと契約の条項を、そのクライアントのアカウント 1 つずつに当てはめた結果を書く文書です。アカウント 1 つごとに、次の 5 つを書きます。
- 媒体とアカウントの名前、預かり方(権限付与・共有の ID・アクセス管理ツールのどれか)。預かり方で、残る記録と交代時の作業が変わります。
- 使える人。共有の ID なら、パスワードを知っている人の範囲も書きます。媒体の画面からは、誰が知っているかが分からないからです。
- 誰がいつ使ったかの残し方(媒体の履歴か、社内の作業記録か)。誤投稿などのときに出せるものがここで決まります。
- 担当交代と契約終了のときに、自社が行うことと、クライアントに頼むことと、その期限。クライアントの作業が抜けると、辞めた人が入れる状態が残るからです。
- 不正な利用に気づいたときの連絡先。
各行には、もとにした規程の項目を添えます。あとで確かめるときに、その行がどの決まりに基づくかを、クライアントが自分で追えるようにするためです。
サンプルどおりに規程を作ったクライアントは、委託先を年 1 回以上評価します。契約終了時には、渡した情報とアクセス権(アカウントを使える状態)の回収か破棄を確かめます。確認リストには、ユーザー ID の発行・変更・削除の手続、パスワードの管理のルール、アクセス権の管理のルールを定めているかを問う項目もあります。答えは規程の項目で示し、説明書の 2 と 4 の行は、その規程どおりに運用している例として添えられます。
説明書は、担当者が替わったときと、預かり方を変えたときに、改訂日を入れて直します。ほかのクライアントの行は入れません。
この記事は法的助言ではありません。規程や説明書の文言は、必要に応じて弁護士の確認を受けてください。
よくある質問
基本方針にアカウントの扱いを書くべきですか
預かった情報を守ることと、担当者を限って使わせていることまでにとどめます。誰がどのアカウントに入れ、入る人をどう確かめているかは、知られると守りが弱くなるおそれがあるので、社内の規程とクライアントごとの説明書に書きます。
IPA の規程のサンプルはそのまま使えますか
自社で ID を出して消せる前提の決まりがあり、預かったアカウントには合いません。共有の禁止、不要になったときの削除、退職時の返還、従業員以外の作業者の 4 か所を、クライアントに頼む作業を含めて書き換えます。
共有の ID は規程で禁止すべきですか
サンプルも、やむを得ない場合は使った人を特定できるようにすることを条件に認めています。権限付与がある媒体はそれを使い、残る共有の ID は使える人の名簿と利用の記録を条件にします。
クライアントに渡す説明書はいつ直しますか
担当者が替わったときと、預かり方を変えたときです。クライアントは委託の後も対策を確かめることがあるので、改訂日と、規程のどの項目に基づくかを書き添えておきます。
Junify の場合
- 人手で続けると
- クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。
- Junify なら
- 規程に書いた停止の期限は、共有の ID で預かるアカウントでは自社だけでは守れません。クライアントがパスワードを変えるまで、外れた人も入れるからです。導入時にクライアントと相談してパスワードを変え、Junify だけが持てば、担当者は知らないまま入ります。外れる人は割り当て(使ってよい人の指定)を自社で外した時点で入れなくなり、説明書の担当交代の行も自社の作業と期限で書けます。
参考資料
- IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版
- IPA「中小企業の情報セキュリティ対策ガイドライン」付録 2 情報セキュリティ基本方針(サンプル)
- IPA「中小企業の情報セキュリティ対策ガイドライン」付録 5 情報セキュリティ関連規程(サンプル)
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)
同じテーマの記事
-
Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント
Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。
-
SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの
連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。
-
運用代行会社がクライアントとの契約に入れておくアカウントの条項
入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。