Mac の「管理者権限をください」は、大半がアプリ配布の穴だった

Mac の利用者から管理者権限を外した。すると「このアプリを入れたいので、管理者権限をください」という依頼が情シスに届くようになる。そのたびに手作業で付けて、外して。

開発部門を持つある会社(Mac 約30台、MDM は JumpCloud)で、この依頼を自動化してほしいと頼まれた。Slack で承認したら1時間だけ管理者権限が付く仕組みを考えていた。だが、作る前に過去の依頼を1件ずつ分類してみると、ほとんどの依頼は、そもそも管理者権限を渡さずに済むものだった。

この記事でわかること

  • ▶ 管理者権限の依頼を「原因」で分けると何が見えるか
  • ▶ 依頼ごとの、管理者権限なしで済ませる手(カタログ・プロファイル・スクリプト)
  • ▶ それでも残る依頼のための「承認制・時間限定」の設計
  • ▶ 自動化が止まっていた本当の理由

▼自動化が止まっていた理由は、技術ではなかった

この自動化は、前にも一度検討されて止まっていた。理由を聞くと、開発の SRE チームから「何でもかんでも権限を付けないでくれ」と言われ、「では付けてよいアプリの一覧をください」と返したところで止まっていた。

つまり、「どのアプリなら入れてよいか」が誰にも決められていなかった。仕組みを作っても、承認の判断基準がなければ回らない。だから先に、依頼の実態を見ることにした。

▼過去の依頼を原因で分けた

Slack の依頼チャンネルに残っていた、約10件の依頼を分類した(数か月分)。

依頼 管理者権限が要った原因 管理者なしで済ませる手
ブラウザのインストール その人のグループがアプリカタログの対象外だった カタログを全グループに出す
会議ツールの画面共有の設定 画面収録の許可の変更に管理者が要る プライバシー設定のプロファイル(PPPC)で、画面収録を標準ユーザーが自分で許可できるようにする
Xcode のライセンスへの同意 同意のコマンドに管理者が要る Xcode の配布・更新のあとに、MDM のコマンドで同意を自動実行する
開発ツールの更新 本人が管理者権限で入れたアプリで、持ち主が管理者になっていた カタログに移す。なければ、アプリの持ち主を利用者に変えるスクリプト
Homebrew と各種 CLI Homebrew の初回の導入に管理者が要る Homebrew を MDM から「本人の持ち物」として入れておけば、以後の CLI は管理者なしで入る
日本語入力・プリンタードライバー インストーラー(pkg)が管理者を求める 承認済みなら MDM から配る
まだ承認されていないアプリ 会社として入れてよいか決まっていない セキュリティ責任者の判断が先。OK なら配る、だめなら断る

並べてみると、本当に「その場で管理者権限が要る」依頼は、まだ承認されていないアプリを試すときと、仕組み上どうしても要るものだけだった。残りは、配る仕組みが足りないか、設定が足りないことが原因だった。依頼者の多くは、アプリカタログの対象外のグループにいた。カタログを全グループに広げるだけでも、依頼は減る。

※ 表の「済ませる手」は推定で、これから1つずつ検証する。

管理者権限を外すなら、更新の仕組みを先に

管理者権限を外した Mac は、アプリの更新のたびに管理者のパスワードを求められる。利用者が自分で入れて自分で更新できるアプリカタログ(セルフサービス)を先に用意しないと、依頼が情シスに集中する。権限を外すことと、配る仕組みを作ることは、セットで進める。

▼インストール済みアプリを棚卸しして「一覧」を作る

止まっていた「付けてよいアプリの一覧」は、ゼロから考えずに実際に入っているアプリから作り直すことにした。MDM のソフトウェア一覧から全 Mac(約30台)のインストール済みアプリを出し、製品ごとに台数と、直近90日に開かれた台数を集計した。

  • ▶ 全員に自動で配っているのに、ほとんど開かれていないアプリがまとまって見つかった(20台以上に入っていて、開いたのは0〜1台)。配布をやめる候補
  • ▶ 同じアプリが2つの仕組みで配られていて、二重に更新されている可能性があるものもあった
  • ▶ 遠隔操作ツール・VPN・方針外のパスワード管理ツール・AI ツールなど、セキュリティの担当に判断してもらう候補を抜き出した

この表を SRE とセキュリティ責任者に見てもらい、「承認済み」「要判断」「やめる」に分けてもらう。判断する人が見る材料を、情シスが先に用意するのが役目だと考えている。

▼それでも残る依頼は「承認制・時間限定」に

カタログやプロファイルで減らしても、未承認のアプリを試すときなど、管理者権限が要る場面は残る。そこは Slack のワークフローにする設計にした(案)。

STEP1 申請者がフォームで「どのアプリを、何のために、どの端末で」を出す

STEP2 承認済みのアプリでカタログにあるなら「カタログから入れてください」と返して終わり

STEP3 承認済みでカタログにないなら、作業者がボタンを押す → その人の Mac に管理者権限が付き、1時間後に自動で外れる

STEP4 一覧にないアプリなら、SRE に判断を回す。OK なら一覧に足して STEP3 へ

STEP5 申請者・承認者・付与と解除の時刻を、監査用に自動で記録する

注意点が2つある。1つは、MDM の API キーを誰のアカウントで発行するか。外部の作業者の個人アカウントで作ると、その人がいなくなったときに止まる。会社の情シス用の管理者アカウントで発行し、仕組みも会社の持ち物にする。もう1つは、過去に付けた管理者権限が外れたまま残っていないかの確認だ。外し忘れがあれば、時間限定にした意味がなくなる。

▼まとめ

  • ▶ 自動化の前に、過去の依頼を原因で分ける
  • ▶ 多くは、カタログ・プロファイル・スクリプトで管理者権限なしにできる
  • ▶ 「付けてよいアプリの一覧」は、インストール済みアプリの棚卸しから作る
  • ▶ 残る依頼だけ、承認制・時間限定・記録つきにする
  • ▶ 最終形は、配る仕組みで管理者権限そのものを要らなくすること
📄 Mac の端末管理をどこから始めるかはこちらの記事で書いています。
📄 アカウントや権限の棚卸しの全体設計はこちらの記事で解説しています。

📅 30分無料相談、受け付けています

「管理者権限を外したら、依頼が情シスに集中して回らない」——そういった段階からお気軽にどうぞ。依頼の棚卸しから、アプリ配布の仕組みづくりまで対応しています。

📅 30分無料相談を予約する →