見出し画像

情シスと特権管理者にまつわる諸問題アレコレ

good-sun（a03）

本記事は【初心者優先枠】corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2 Advent Calendar 2022 の12/17の記事です！

https://adventar.org/calendars/7757


主人公「くそっ、俺に力があれば……！」
？？？「……力が……欲しいか……？」

様々な組織やチームで見聞きしてきた事や、最近思うところを整理したくつらつらと書いています。いや〜それはこうなんじゃない？とか、あ〜そうそう、といったコメントをお寄せいただけましたら嬉しいです。

このnoteに記載している事柄は特定の組織、団体、人物などを表現したものではありません。また、記載内容は所属する組織、団体とは無関係であり、個人の思うところです。

というお約束で以下本編。

全員admin問題

全員admin
それは強引
それが原因
そしてFall in

このように韻を踏めます。

全員admin問題には大きく2系統あります。
そのシステムを使っているユーザ全員にadmin権限を持たせているパターンと、共有アカウントにadmin権限を持たせて、その共有アカウントをチーム内で使い回しているパターンです。

システムを入れた直後やスタートアップでは、メンバ全員adminとして、まずは皆で使えるようにする、というのはありがちな話かと思います。

共有アカウントについては、悪気なくハックとして使われていることが多い気がします。共有アカウントは様々な問題を孕みますので非推奨です。

共有アカウントについては、世界の吉田さんのnoteを読みましょう。


偉い人特権持ちがち問題

組織内での職位とシステム上の権限の持たせ方を同一にすると、実際的にはそのシステムのことをよく理解していない偉い人が特権を持っているという状態があります。

これと似たような問題として
「創業者が特権持ちがち問題」
「古参が特権持ちがち問題」
があります。

スタートアップでは創業者自らがゴリゴリに初期のシステムを導入し、その際の特権を持ち続けていることもよくあるようです。

また、総務や人事、経理を全て一人あるいは一つのチームで担っていた少人数組織などでは、古参メンバがあらゆるシステムの特権を持っていることもよくあるようです。

現在は古参メンバが既にそのシステムを使った仕事を行っていないが、権限整理が行われていなかったが故にadminとして君臨しつづけていることがあったりします。

組織が大きくなり、情シスを配置するとこういった状況が明らかになり、情シスはその権限整理をすることになったりします。

状況にもよりますが、多くの場合、事情を説明しながら権限を剥がしたり、整理していくのが良いと考えています。

最小権限（最小特権、PoLP）の原則

最小権限の原則【最小特権の原則】PoLP / Principle of Least Privilege

最小権限の原則とは、情報システム上のアクセス権限の運用についての原則の一つで、本来の目的に必要な最低限の権限しか与えないようにすること。障害や不正による被害を最小限に抑えることができる。

IT用語辞典e-Wordsより
https://e-words.jp/w/%E6%9C%80%E5%B0%8F%E6%A8%A9%E9%99%90%E3%81%AE%E5%8E%9F%E5%89%87.html

力には責任が伴う。
不必要にユーザがあらゆる権限を持っていると、うっかりミスでデータを削除したり、変えてはいけない設定を変更してしまったり、実行可能であるが故に問題が起こりかねません。

信頼や信用といった人情の話ではなく、情報管理上の問題として、権限を適切に設定する必要があります。


業務委託に特権を持たせるかどうか


情シスが1人もいなくて実質的なことは業務委託の方が担っている場合、特権管理権限をどうするのか？

組織のポリシーと契約次第ってのがアンサーにはなるとは思うんですが、組織の基幹を業務委託に預けて良いのか？という疑問符は拭えない。

決めと信頼関係の問題とは思いつつ、基本的にはその組織の者のうち、情シスに近い正社員が特権を持つのが健全な気もする。

ここで、組織内に情シス的なポジションが無い場合、全員adminや代表者が特権を持つ事態になりがちなところがある気がする。


日本語訳としての「管理者」

manager  もadminも、日本語では同じ管理者と訳されることが多い。
でも、それぞれの意味合いは異なる。

システムによっても、ownerと言ったり、manager と言ったり、adminだったり、命名とその内容、意味範囲が異なることはままある。


GWSにおける特権管理者のベストプラクティス

まずは管理者ヘルプをよく読んでみる

特権管理者は、アカウントに少なくとも 1 人必要ですが、2 人以上にすることをおすすめします。

Google Workspace　管理者ヘルプ
https://support.google.com/a/answer/2405986?hl=ja

複数の特権管理者アカウントを設定する
組織では複数の特権管理者アカウントを用意して、それぞれを別のユーザーが管理することをおすすめします（管理者アカウントの共有は避けてください）。1 つのアカウントが失われたり不正に使用されたりした場合でも、他のアカウントを復元する間に別の特権管理者が重要な業務を行うことができます。

Google Workspace　管理者ヘルプ
https://support.google.com/a/answer/9011373?hl=ja&ref_topic=4514292


日常業務に特権管理者アカウントを使用しない
特権管理者にはそれぞれ 2 つのアカウント（専用の特権管理者アカウントと、日常業務に使用する別のアカウント）を付与してください。2 段階認証プロセスの設定、請求の管理とユーザー ライセンスの管理、別の管理者アカウントの復元のサポートなど、特権管理者業務を行う必要がある場合にのみ特権管理者アカウントにログインします。

特権管理者が日常業務を行う際には、管理者以外のアカウントを使用します。

たとえば、Maria と James が特権管理者である場合、2 人には以下のような管理者アカウントとユーザー アカウントをそれぞれ用意することをおすすめします。

admin-maria@example.com、maria@example.com
admin-james@example.com、james@example.com

Google Workspace　管理者ヘルプ
https://support.google.com/a/answer/9011373?hl=ja&ref_topic=4514292


というわけで、情シスとしては、費用の問題はあれど、それは必要経費と割り切って、GWSのアカウントとしては日常用のhoge@hoge.comと特権用のadmin-hoge@hoge.comを運用する形が良いと考えています。

特権管理アカウントの共有利用は論外です。やめましょう。
不必要に特権を持っていると、非公開のカレンダの予定が見えてしまったり、うっかり他人のカレンダを削除や変更したり、様々な危険が危ないです。


GCPは基本的にはGWSの設定を継承する

GCPよくわかんない。

GCPにおける特権管理者アカウントのベスト プラクティスは下記に示されている。

うーん、これは今後の課題。


ありがとうございます！
いずれ理解して使いこなせるようになりたひ……！


Slackにおけるワークスペースのプライマリオーナー

個人に持たせるか、システム上のやむを得ない共用アカウントを仕立ててそれにオーナーを持たせるかは意見の分かれるところかもしれない。

個人的には、システム管理者のアカウントにオーナーを持たせて、その管理者が変更や退職の時にまた別のユーザに引き継げば良いと考えている。色々な設定があったとしても、式年遷宮的にそこでまた継承し、整理すれば良いと思っている。下手にシステム的な共用アカウントを君臨させると、そこに様々な過去の遺産が溜まって頭を抱えることになる未来が予感されて悪寒がします。


以上、まとまりもなく、つらつらと失礼しました！
「それはこうなんじゃ！」
「これはこう思う！」
と言ったコメントをお寄せいただけると嬉しいです〜！

次はPやまさんです！

コメントいただいて嬉しいからメモしておくます

#ポエム
#情シス
#情報システム
#コーポレートIT
#コーポレートエンジニア
#特権管理者


いただいたサポートで、書籍代や勉強費用にしたり、美味しいもの食べたりします！