管理者権限を、きちんと扱う。
デバイスごとに3つのローカル管理者アカウントを用意し、自社テナント専用のKey Vaultにエスクローします。サポート用のアクセスは自動で期限切れになります。回復キーはデバイスページで表示し、そこからローテーションできます。そしてロールは、それぞれの担当者に仕事に必要な分だけを与え、すべての操作が自社の監査ログに残ります。
- デバイスごとに3つの管理者アカウント
- エスクローを1時間ごとチェック
- 178種類の細かいアクセス許可
- すべての閲覧を監査
Example data. Last check of escrow: 23 minutes ago.
3つのアカウント、3つの役割
共有のローカル管理者アカウントが一つしかないと、パスワードは付箋に書かれることになります。RealmJoin Agentはデバイスごとに3つのアカウントを保持し、それぞれに対象者と有効期間があります。
| アカウント | 使える人 | 有効期間 | 想定される用途 |
|---|---|---|---|
| 緊急用 | SupporterとAdvanced Supporter | 常に存在し、パスワードがない場合は警告されます | 他に手がなくなった瞬間 |
| サポート用 | 依頼を受けたヘルプデスク、チケットトークン、SelfLAPSを持つ所有者 | 自動で期限切れになり、既定は12時間 | リモートセッション、インストール、トラブルシューティング |
| 特権 | Advanced Supporter | 必要に応じて更新 | 計画された管理作業 |
デバイス所有者グループごとに、誰が何を見られるかを制限できます。Restrict.LAPSを使えば、役員のデバイスのパスワードを、他の誰がどのロールを持っていてもVIPサポートグループだけに限定できます。ポータルはすべての判断を説明します。デバイスを開けば、そのパスワードを誰が見てよいのか、そしてその理由が表示されます。チェックを試す
エスクローのしくみ
- エージェントがデバイス上でパスワードを設定するエージェントがデバイス上でパスワードを設定するパスワードプリセットが形式を決めます。電話越しでも実際に伝えられる、単語リストによるパスフレーズも選べます。
- 送信される前に暗号化される送信される前に暗号化されるデバイスが、自社テナントのRealmJoin証明書でパスワードを暗号化します。
- 自社テナントのKey Vaultに保存される自社テナントのKey Vaultに保存されるRealmJoinは自社テナント専用のKey Vaultにシークレットとして保存し、他のVaultの鍵は受け付けません。
- 閲覧はすべて確認され、記録される閲覧はすべて確認され、記録されるロール、制限、SelfLAPSのルールが、誰がどのアカウントを見てよいかを決めます。閲覧のたびに、誰が、いつ、どのデバイスについて行ったかが監査ログに書き込まれます。
- エスクローは1時間ごと検証されるエスクローは1時間ごと検証されるRealmJoinは稼働中のすべてのデバイスを確認し、必要になる前に、欠けているパスワードと孤立したシークレットを警告します。
SelfLAPSとチケット
POST /laps/request # support account, expiry per tenantPOST /laps/retrieve # password once it's escrowed
IntuneのWindows LAPSも、同じページに
すでにIntune経由でWindows LAPSを運用している場合、RealmJoinはIntuneが管理するパスワードを、WindowsとApple Business Manager経由で登録したMacについて表示し、ローテーションできます。エージェントは不要で、これは必要な場合にだけ付与する任意のアクセス許可です。
- ユーザー名、パスワード、最終更新日、有効期限
- デバイスページからのローテーション
- 独立したカテゴリとして監査
Entraの管理者へチケットを回さずに済む回復キー
07:30にロックされたノートパソコンは、エスカレーションではなくヘルプデスクの仕事です。SupporterはデバイスページでBitLockerとFileVaultの回復キーを確認でき、そのあとローテーションすることで、読み上げたキーの価値をなくせます。閲覧もローテーションも、すべて監査されます。
- ドライブごとのBitLockerキー、MacのFileVaultキー
- どちらもデバイスページからそのままローテーション
- 任意のアクセス許可で、使う場合にだけ付与
9つのロールを、すでにあるグループに対応づける
各ロールをEntraのセキュリティグループまたはディレクトリロールに割り当てます。グローバル管理者はそれとして認識され、アプリロールのAdminとAuditorも使えます。
設定の「アクセス許可」での対応づけの例です。
- sec - realmjoin - admins
- Admin
- sec - it - internal audit
- Auditor
- sec - support - first level
- Supporter
- sec - support - second level
- Advanced Supporter
- sec - automation - operators
- Runbook Runner
- sec - apps - packaging
- Software Agent
- sec - apps - requesters
- Software Requester
- sec - apps - organic upload
- Organic Requester
- sec - comms - it announcements
- Notification Agent
178種類のアクセス許可から作るカスタムロール
組み込みロールに当てはまらない業務があれば、自分で組み立てます。カスタムロールは、設定内のJSONエディターで、名前付きのアクセス許可をユーザーまたはグループに付与します。デバイス一覧の閲覧から、Runbook実行の承認までが対象です。パートナー専用のアクセス許可は、パートナーテナントでのみ有効です。
178種類のアクセス許可名のうちのいくつかです。強調表示しているのは、デバイスを閲覧して回復キーをローテーションすることだけができる「夜勤」ロールです。
RealmJoin自身の及ぶ範囲を限定する
最小権限はツール自身にも当てはまります。RealmJoinがテナントのどこまで触れてよいかを決め、後から考えを変えることもできます。
管理単位によるスコープ設定
RealmJoinをEntraの管理単位一つに限定します。グループへの書き込みはそこだけで行われます。
読み取り専用のコア
読み取り専用のアクセス許可で接続し、準備ができたら広げられます。
付与、縮小、取り消し
すべてのアプリ登録のすべてのアクセス許可を、機能ページから個別に操作できます。
分離されたアプリ登録
コア、読み取り専用、セキュリティ、クライアントのアクセス許可は、別々のアプリに分かれています。
任意の機能
Intune LAPS、サインイン、BitLockerキーなどはオプトインです。
監査されたアクセス
パスワードの閲覧とサポート用アカウントの要求は、誰が、いつ、どこから行ったかが記録されます。
セキュリティと信頼性
ホスティング、データの流れ、そしてRealmJoinが要求するアクセス許可。
Runbookのアクセス許可
どのRunbookを誰が実行してよいかを、対象グループの単位まで。
監査ログ
自社のLog Analyticsワークスペースに30のカテゴリ。
管理者パスワードの共有をやめる。
3つのアカウントによるモデルを、自社のデバイスで、パスワードを自社のKey Vaultに置いたまま確かめてください。