え？管理用のログインIDって共通じゃダメなの？

# はじめに
あなたの企業は、顧客向けにサービスを開始しました。
このサービスでは、ユーザはログイン用のIDをサインアップしてから利用します。
サインアップ時にはユーザの特定の為、<b>一定の個人情報(PII)</b>の入力が必要です。

![qiita_20240403_01.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/52e17ebe-d271-37c4-b0d8-083269b103a9.png)


あなたのサービスにはユーザを管理するUIが別途存在していて、
その管理画面には社内の特定のメンバがアクセス出来る様にし、
複数人で管理出来る様な状態にしています。

![qiita_20240403_02.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/c99704a9-d3cd-9716-5c37-f5c2990ca0c6.png)



しかしながら、ユーザを管理する社内のメンバというのは十数人いて、
彼らに対して**ログインユーザIDとPWを個別に付与するのは面倒だな**、と感じました。

だがこの時、気付いたのです。
<font color=red>**ログインIDとPW、共通にしてしまえばいいんじゃね！？**</font>

![qiita_20240403_03.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/93d0df83-38a4-4f08-11f5-3d266aef4cbb.png)

なんと、この手法ならパスワードは個人で管理する必要が無いのです。
社内のみで共有されるドキュメント等に、IDとPWを記載しておき、
それを配置しておく事だけで十分になります。

しかしながら、**この方法は不適切です**。
管理用のユーザIDであっても、適切に管理ユーザ別に分ける必要があります。
次項から説明に入ります。

# 管理用IDをユーザ別に分ける理由
ここからは、管理用のユーザIDを、管理ユーザ別に分ける必要性について記載します。

## 管理権限を個別に設定する為

![qiita_20240403_04.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/9d96f32e-b6fc-e818-f64c-3c10e709f269.png)


管理用ユーザIDが個別に付与されていない場合、
管理ユーザ別に権限を個別に割り振る事が出来ません。

管理IDが単一だった場合、対象のIDの権限は最大の範囲を持たせる必要があります。
これは**管理用ユーザが誰であっても、全ての操作を行える**という事です。
例えば、Aさんはユーザの情報を確認出来るが、Bさんは確認出来ない、
といった事を実現出来ません。

特定の人物に対して本人であるかどうかを確かめる事を「<font color=red>**認証**</font>」、
認証された人物に対してどういう操作を認めるかという事を「<font color=red>**認可**</font>」と言います。

個人情報を取り扱う認可の範囲は最小限に留めておくべきです。
しかしながら、個人情報以外を取り扱う管理ユーザが存在する場合もあるので、
別々の認可を行わなければなりません。
そういった面から、管理ユーザを分ける事は非常に重要です。

単一IDで認証する運用をした時に、ビジネスルールとしてBさんに対し
「**あなたはユーザの情報を見てはいけない**」と明言したとして、
技術的に見る事が出来てしまうのだから、
そう伝えて作業範囲を縛る事自体の価値は特にありません。
フールプルーフの考えに則り、**そもそも出来ないようにする**事は重要なのです。

::: note
適切な「**認可**」を行うには、メンバ別の「**認証**」が必要です。
この為に、それぞれのIDを分ける必要があります。
:::

## 管理ID/PWの漏洩リスクの減少の為
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzwzHy5v2JBHlFD-qVP3Fzv4DBZNGJ-zOpzy7BwX11a4xmYLv2q-ZTg279yeoALEYpz7vSNeQOHU2-v_ivRg-xhmR18DE6tavkfdQRAEPCxjXl_RM7TllbWmbG-pfc5u2esg37h5FR9zk/s400/dorobou_hokkamuri.png" width=200>

上記内容に通じる事ですが、
認証ユーザのIDとPWという物は、**漏洩する事を一定考慮する必要があります**。

これは<font color=red>**ゼロトラストネットワーク**</font>という考え方に基づきます。
近年ではテレワークで業務に従事する人が増えた関係もあり、
自宅回線や自宅PCを利用するケースも考えられますが、
それらのセキュリティは企業側から見ると管理出来ない、保証されていないのです。
なら全ての通信は攻撃されたり、盗聴されたりする前提でいるべきです。

:::note warn
ゼロトラストネットワークの考えに基づき、
**攻撃、または漏洩は起こる事を前提にした設計**を行うべきである。
:::

また、IDとPWが漏洩しない様取り扱う様に、教育を行う事は必要な事です。
しかしながら、人間はミスを起こしてしまうので、
例えば、パスワードを管理しているファイルが入ったPCが盗難に合ってしまった、
もしくは当人のリテラシーが低く、
**IDとPWを書いた付箋を机に貼りっぱなしだった**、という事例も無い訳ではありません。

:::note warn
人的問題によるリスクは、教育等により極小化しておくべきである。
:::

適切な認可により権限を最小化していれば、
漏洩した後のリスクを最小限に留める事が出来ます。

漏洩したIDの権限で顧客情報にアクセス出来る場合であれば、
顧客情報が漏れた可能性を追う必要性が出てきます。
一方で、もし顧客情報にアクセス出来る可能性が無いのであれば、
個人情報の安全性は保たれている事を保証出来るのです。

## 操作ログを管理ID別に管理する為

![qiita_20240403_05.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/2274bb42-48e3-3e53-a426-679aef7a9c39.png)


管理画面での操作ログというのは、
管理ユーザが不適切な操作をしていないかを監査する為に重要な物です。

勿論管理ユーザが誤った操作をした時には役に立つものですが、
実際に漏洩が発生した時に、その影響範囲を特定するのに必要不可欠な物です。

前項で管理IDとPWが漏洩した時の事を考慮しましたが、
例えば担当者からの報告などで漏洩が発生した事に気付いた時に、
対象の管理IDの操作ログが何も残っていないのであれば、
（適切に全操作において操作ログが取れているという前提の下に）
個人情報や不適切な操作はまだ行われていなかった、と推定する事が出来ます。

::: note info
操作ログを確認する事態にならない事がそもそも重要だが、
いざという時に確認出来る状態にしておく事も重要である。
:::


# 個人情報の保護に関する法律

https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

こちらの情報が分かり易いと思いますが、
上記項目で書いた内容というのは、主にここに記載されてある事を
少しばかり具体的に説明したものばかりです。
上記で説明した事に関して言えば、以下の様な形でまとめる事が出来ます。

- **「管理権限を個別に設定する」**
    - 組織的安全管理措置の組織体制の整備
    - 技術的安全管理措置のアクセス制御
- **「管理ID/PWの漏洩リスクの減少」**
    - 人的安全管理措置
    - 技術的安全管理措置のアクセス制御
- **「操作ログを管理ID別に管理する」**
    - 組織的安全管理措置の個人データの取扱いに係る規律に従った運用

に該当します。

他にもIDを分ける適切な理由というものは存在すると思いますが、
いずれにしても個人情報を保護する上で、
「管理IDが共通であっても良い」と言う事は出来ません。

BCPの観点から言っても、リスクを最小限に抑える様に、
かつ法律に遵守する様な形で運用するべきだと考えます。


# おわりに
個人情報を取り扱うのは、非常にきめ細やかな配慮が必要です。
それだけ大切な情報を取り扱っている、という意識や責任の下、
適切な管理体制を敷いて、個人情報を安全に保護して運用しましょう。