
情シスと権限管理について
強い権限で気軽に作業しがち
本当に「いまさら言うな」ですけどね。
事務作業なのにadmin権限で作業しているとか、ベンダーさんでも、作業用に与えたアカウントでファイル更新していたりとか、目を離すとルール外のことをしているケース、いろいろあります。
しかもそれが、Gsuiteになったら、アイコンでアクセスしている人がわかってしまうという。。。おそろしい世界!
手違いや勘違いが重大インシデントに
弊社で一番ひどい事例でいうと、ユーザ部門から異動してきたばかりの人が社員のメールボックスを削除してしまった、というのがあります。
教わっていた作業の中に「退職者のメールボックスを削除する」というのがあったらしく、「退職者」の部分が抜け落ち、社員のメールボックスを上から順に順番に削除していったという。。。
途中で「メールが消えた!」という通報が入って発覚し、復旧を試みるも数名は完全には復旧できなかったらしい。
それ以外にも、コマンド一つで環境を吹き飛ばしたとかもありますね。熟練の作業者が「このコマンドを打ったらどうなるのかな?」と試したら吹き飛んだというのがありました。
構築中の環境でしたので大きな影響はありませんでしたが、めっちゃ怒られていました。
こういったところは、教育不足やリスク認識不足で、とくに前者については、自分の仕事をきちんとわかっていない人に一人で作業させるなとか突っ込みどころはいろいろとあるのですが、のどかだった時代の話だと思っていただければ。
作業にあわせた権限で削除する
そもそもの話として、いわゆるadmin権限でいろいろな作業をするなということですね。そういった意味では、いわゆる管理者についても、一番強い権限を持つ人と、いわゆる作業者として保守管理を行う人の権限は分けておくべき。
アプリケーションの開発でも権限設計ってわりと大事な部分なんですけど、こういったバックヤードの機能って、もれたり落ちがち。しっかり作りたいんですけどねえ。。。
運用部門が保守管理をできる世界にできるのが理想
弊社のサポートデスクで結構あるのが「〇〇を使えるようにしてください」っていうやつですが、システム側はその人が適切かどうかの判断ってできないですからね。本来的にこれは好ましくなくて、オーナー部門があって、その部署で権限管理まで完結できるのが理想です。
しかしこれ、絶対的にこれが正しいという教科書的なものがないので、困っちゃう。アクセス許可の考え方を絵にすることは難しくないんですけど、ユーザ側のリテラシーによっては、必要性の意識が薄いですからねえ。。。
権限の棚卸について
これ、ときどきやっていますが、めっちゃ大変です。何が大変って、利益にも何にもならないのに、一定間隔でやらなきゃいけないというのが大変。
手順としてはこんな感じです。
・システムごとに権限を一覧で書き出す
・一覧の権限をADとつきあわせて存在しない人を削除する
→これをやらないと攻撃の温床にされかねないので、これはやる。
・ユーザに確認する
最後が実は大変で、基本ユーザって、権限が欲しい時はすぐ言ってくれるんですけど、異動したりとか、不要になった時って基本言ってくれないんです。。。!
ひどいケースになると「私そんな権限持ってましたっけ?」なんていうのもある。
セキュリティ管理も厳しくなってきているので、このあたり「やるべき」から「当然やらないとダメ」の世界になってきています。
そろそろ、セキュリティの専門家とかほしいな。。。
しかし、最近管理者向けの本もいろいろと出てますね。
こういう「先輩がやさしく教える」というhowtoものは結構好き。
担当者のリテラシー教育も必要。結構技術よりの人がリテラシーがかけているケースもある。残念ながら。
最近、ひとり情シス系の本も多いですねえ。。。
おしまい。