誤投稿・誤設定のあとに原因を追える運用と追えない運用
報告に要るのは「誰が・いつ・何を」の 3 つです。共有 ID では媒体の記録が ID 単位で担当者まで絞れず、権限付与かアクセス管理ツールなら人単位で残ります。記録がなければ作業記録から推定するほかありません。
誤投稿や誤設定が起きたあと、クライアントへの報告で問われるのは、何が起きたかに加えて、誰がいつ操作したかです。これに答えられるかどうかは、預かり方で事前に決まっています。預かり方の全体像は運用代行のクライアントアカウント管理にまとめています。
報告に必要な 3 つの情報
クライアントへの報告に要るのは、誰が・いつ・何を、の 3 つです。「何を」は事故の内容そのもので、投稿の削除や設定の戻しに要ります。「いつ」は影響の範囲を決めます。投稿が公開されていた時間や、誤った予算で配信された期間です。「誰が」は、再発防止策を原因の種類に向けるために要ります。
個人データの漏えい(外部への流出)を伴う事案では、この 3 つはガイドラインが定める手順と重なります。個人情報保護委員会のガイドライン(通則編)3-5-2 は、漏えい等事案(情報漏れなどの事故)が発覚した場合に行うべき 5 つの措置を定めています。そのうち (2) 事実関係の調査及び原因の究明(何が起きたかを調べ、原因を突き止める)、(3) 影響範囲の特定、(4) 再発防止策の検討及び実施が、この 3 つの情報に対応します。漏えいの事例としては、個人データを含むメールを第三者に誤送信した場合が挙げられています。設定ミスで、インターネット上で個人データを閲覧できる状態になっていた場合も同じです(3-5-1-2)。誤投稿・誤設定のように個人データを伴わない事故でも、報告の組み立ては同じです。
共有 ID では担当者まで絞れない理由
共有 ID で担当者を絞れないのは、媒体の記録がログインしたユーザーの単位で残るためです。媒体は「どのユーザーがログインし、何を変更したか」を記録します。しかし、ここでいうユーザーは ID のことで、その ID を使っている人ではありません。3 人が同じ ID で入っていれば、媒体の記録上は操作者は 1 人です。記録からは、3 人のうち誰かとしか言えません。
時刻や接続元(どこから入ったかの情報)が残る媒体もあります。しかし、同じオフィスから同じ時間帯に働く担当者を、これで分けることはできません。在宅勤務で接続元が分かれていても、それは本人を特定する記録ではなく、状況証拠にとどまります。媒体が何をどの期間残すかは媒体ごとに違い、この記事では扱いません。
権限付与とアクセス管理ツールで残るもの
預かり方ごとに、3 つの情報のどこまでが記録として残るかを並べます。
| 預かり方 | 誰が | いつ | 何を |
|---|---|---|---|
| 権限付与 | 招待された担当者のユーザー単位で媒体に残る | 媒体のログイン・変更の履歴に残る | 媒体が変更履歴を残す範囲 |
| ID とパスワードの共有 | 共有した ID 1 つとしてしか残らない | 時刻は残るが、誰の操作か分からない | 媒体が変更履歴を残す範囲 |
| アクセス管理ツール | ツールにログインした担当者単位で、いつどのアカウントを開いたかが残る | ツール側の記録に残る | 媒体が変更履歴を残す範囲 |
権限付与では、記録を残すのは媒体側です。担当者ごとの招待が成立している限り、「誰が」は媒体に残ります。権限付与(アカウントを共有しないアクセス)とはで述べた「担当者ごとに招待を受ける」が守られず、1 つのユーザーを複数人で使っていれば、記録の残り方は共有 ID と変わりません。
アクセス管理ツールでは、媒体の記録は共有 ID のまま(ID 単位)です。しかし、その前段でツールが「誰がいつどのアカウントを開いたか」を担当者単位で残します。媒体側の変更履歴と、ツール側の「そのとき誰が開いていたか」を時刻で突き合わせると、担当者まで絞れます。同じ時刻に同じアカウントを複数人が開いていた場合には、この突き合わせでも 1 人に絞れません。
記録がないときの代わりの方法と限界
共有 ID で人単位の記録がない場合、代わりになるのは、作業記録(投稿カレンダー、入稿依頼のやり取りの記録、承認の履歴)、勤務時間、本人への聞き取りです。誤投稿の時刻に投稿の担当だった人と、その時間に勤務していた人を照らし合わせ、本人に確認します。
この方法には 3 つの限界があります。第一に、結果は推定であり、本人が心当たりを否定すれば確定できません。第二に、同じ時間帯に複数人が同じアカウントで作業していれば、勤務時間では絞れません。第三に、聞き取りは記憶に頼るので、事故から日が経つほど確かさが落ちます。クライアントへ報告するときは、推定であること、確定できない範囲を明記します。推定を確定のように報告し、後で覆ると、事故そのものより報告の信頼が失われます。
再発防止で記録が果たす役割
記録が再発防止に要るのは、原因の種類を分けるためです。誤設定の原因は、担当者の見落としか、確認の手順がなかったことか、その担当者に本来要らない操作の権限があったことかで、対策が違います。見落としなら二重確認、手順の抜けなら承認の追加、権限の広さなら権限の絞り込みです。
誰が操作したかが分からないと、この区別ができません。原因が分からないままの対策は、向ける先を決められず、全員への注意喚起にとどまります。事故を生んだ条件はそのまま残ります。記録は、対策をどの原因に向けるかを決めるために要ります。
事故が起きたあとに記録を増やすことはできません。であれば、預かる時点で、アカウントごとに「誰が」がどこに残るかを、預かっているアカウントの一覧に書いておきます。それが、原因を追える運用の出発点になります。
よくある質問
共有 ID でも媒体の記録を見れば誰が操作したか分かりますか
分かりません。媒体はログインしたユーザーを見分けて記録するので、同じ ID で入った複数人は記録上 1 人です。時刻や接続元が残っても、同じ場所から同じ時間帯に働く人は絞れません。
記録がないとき、報告はどう書きますか
作業記録・勤務時間・本人への聞き取りから推定した結果を、推定であると明記して報告します。確定できない範囲を隠さないほうが、後で覆ったときの信頼の損失が小さくなります。
権限付与にすれば操作内容まで分かりますか
誰がいつ入ったかは人単位で残りますが、何をしたかは媒体が変更履歴を残す範囲に限られます。媒体ごとに違うので、預かる前に確認します。
記録は再発防止にどう関係しますか
原因が人の誤りか、手順の抜けか、権限の広さかを分けるのに要ります。分けられないと、対策は全員への注意喚起にとどまり、同じ条件が残ります。
Junify の場合
- 人手で続けると
- クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。
- Junify なら
- Junify では、共有 ID のままでも担当者はパスワードを見ずにログインし、誰がいつどのアカウントを開いたかが担当者ごとに残ります。誤投稿の報告に要る「誰が・いつ」を、開いていた人が一人なら、勤務時間からの推定ではなく記録で示せます。
参考資料
同じテーマの記事
-
クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか
誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。
-
Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント
Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。
-
SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの
連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。