運用が楽になる権限のつけ方

まさか、こんな運用をしてませんか？

アプリサーバの権限をインフラ管理メンバーのいる組織グループで付けている

ユーザーアカウントで直接権限を付けている（運用が大変だけどアシスタントの子が頑張ってるよ！）

何かに権限付与をする場合、例えばアプリサーバに対し権限を付ける場合はなるべく

サーバなどのローカル管理者グループ　← 権限用のドメイングループ　←　組織用のドメイングループ　←　ドメインユーザー

という形で付けましょう。

ポイントは「権限用のドメイングループ」を作る事にあります。

まずユーザー単位での権限付与は特段の理由がない限りはやめるべきです。

労力がかさむばかりでなく、運用上・セキュリティ上のリスクがあります。

＜リスクの例＞

・管理を任せていたユーザーが体調を崩してやめてしまった際に、システムに対する権限を持った人が誰もいない状態になり誰もアクセスが出来なくなってしまった

・別の組織に移動した人の権限メンテナンスが追い付かず、いつまでも本来権限のないべき人からサーバの中身を覗かれてしまう

オンプレミスのファイルサーバの、管理者権限を設定する場合の例です。

めんどくさそうですが、ファイルサーバ上のAdministratorsは元々ありますし、AチームBチームのグループも組織グループなら普通にAD運用をしている会社ならすでにある筈です。意識してつくるのはファイルサーバ用権限グループのみです。

組織グループを直接サーバのAdministratorsに含めるケースもありますが、そこそこの大きな会社だと大掛かりな組織変更がちょくちょくあったりしますよね。

そんな時、Administratorsに設定していた組織グループの組織が管理者でなくなる場合もあります。結果、一時的に本来の管理者がアクセス出来なくなる、なんて事も。

これは権限グループを設定している際にも同じ状況なのですが、メンテナンスの手軽さ、身軽に大きな差が出ます。

もし権限グループを作らず、ファイルサーバ上のAdministrators上に直接組織グループを入れていた場合、ファイルサーバにログオンしてグループメンバを変更する手間が発生します。

手間でよければいいものですが、上記の例で言う組織グループＡ TeamとB Teamが人事側の調整などですでになくなってしまっているケースが最悪で、気が付いたらサーバに入れる人が誰もいなくなっていた。。。なんて惨事も。

権限グループを作るメリットは

・サーバ管理者の変更はAD側の作業だけOK

・管理者が不在になりサーバにアクセスできなくなるリスクを防ぐ

どうでしょう。権限グループの重要性をご理解いただけたでしょうか。

今回の話は以上となります。