Microsoft Entra ID、Intune、Jamf Pro、HENNGE One、Okta――社員1人を入社させるだけで情シスは何をしているのか
4月1日。
新入社員が会社へ来る。
机にはPCが置いてある。
Microsoft 365へログインできる。
Teamsが使える。
Slackにも入れる。
Salesforceも使える。
Boxも見られる。
社内Wi-Fiにも接続できる。
本人からすると、
「会社がアカウントを作ってくれた」
だけです。
しかし社員数が数千人、数万人になると、情シス側ではそんな簡単な話ではありません。
Microsoft Entra ID。
Active Directory。
Microsoft Intune。
Jamf Pro。
Apple Business Manager。
HENNGE One。
Okta。
SAML。
SCIM。
IdP。
SSO。
MFA。
Conditional Access。
RBAC。
MDM。
ゼロタッチキッティング。
プロビジョニング。
デプロビジョニング。
こういう言葉が大量に出てきます。
しかも本当に怖いのは入社より、
退社した社員のアカウントを消し忘れること
だったりします。
昔は「Active Directoryに社員を作る」だった
Windows中心の企業では長年、
Active Directory
が企業ITの中心にありました。
社員が入社したら、
ユーザーを作る。
所属OUへ入れる。
グループを付ける。
ファイルサーバーへの権限を付ける。
メールアドレスを作る。
PCをドメイン参加させる。
という世界です。
ところが現在は、会社で使うサービスが社内サーバーだけではありません。
Microsoft 365。
Google Workspace。
Slack。
Box。
Salesforce。
Zoom。
ServiceNow。
Concur。
Notion。
GitHub。
Adobe。
Dropbox。
その他大量のSaaS。
社員一人が10個、20個、場合によってはそれ以上のクラウドサービスを使います。
すると、
「Active Directoryに社員を一人作った」
だけでは終わりません。
そこでID管理そのものが一つの巨大な業務になります。
Microsoft Entra IDが会社の「デジタル社員証」になる
Microsoft系の環境では、
Microsoft Entra ID
が重要になります。
以前のAzure Active Directory、Azure ADです。
ここに、
という社員のIdentityがある。
このIdentityを使って、
Microsoft 365。
Teams。
SharePoint。
OneDrive。
各種SaaS。
へアクセスさせる。
さらにMicrosoft Entra IDには、外部アプリケーションへユーザーを作成・更新・削除するプロビジョニング機能があり、SCIM 2.0に対応するSaaSへユーザー情報を連携できます。Microsoftは、人事システムを起点としてデジタルIDを作るHR-driven provisioningも提供しています。
つまり、
人事に社員が登録される。
↓
Entra IDにIdentityが作られる。
↓
各SaaSへアカウントが作られる。
という流れを自動化できる。
これが、
Provisioning
です。
SAMLとSCIMは似ているようで全然違う
ここは情シス以外にはかなり分かりにくいところです。
例えば会社がSalesforceを使っている。
HENNGE OneやOktaから、
Salesforceへログインできるようにする。
ここでよく使われるのが、
SAML
です。
ざっくり言えば、
「この人は本人ですよ」
という認証結果を、
IdPからSalesforceなどのService Providerへ渡す。
これによって、
Microsoft 365へログインした社員が、
同じ会社Identityで別のSaaSにも入れる。
いわゆる、
SSO、Single Sign-On
です。
HENNGE Access ControlもSAMLやOpenID ConnectによるSSO連携を提供しています。
しかしSAMLは、
ログインの話
です。
一方、
SCIM
は、
アカウント管理の話
です。
社員が入社した。
Salesforceにユーザーを作る。
部署が変わった。
属性を更新する。
退社した。
ユーザーを無効化する。
こうしたIdentity LifecycleをAPIで自動化する。
OktaもSCIMを使い、外部アプリとの間でユーザーやグループ等の作成・更新・削除を自動化する仕組みを提供しています。
だから、
SAMLが入っている。
SSOできる。
でも、
退職者のSaaSアカウントは情シスが手で消している
という会社も普通に成立します。
SSOとProvisioningは別問題だからです。
「入社しました」から20個のSaaSアカウントを作る
例えば営業部へ田中さんが入社したとします。
人事システムには、
氏名。
社員番号。
部署。
役職。
勤務地。
入社日。
上司。
などが入る。
そこからIdentity管理側で、
Microsoft Entra ID。
Microsoft 365。
Teams。
Box。
Slack。
Salesforce。
Zoom。
Concur。
勤怠。
経費精算。
社内ポータル。
などへユーザーを展開する。
しかし全社員へ同じものを配るわけではありません。
営業ならSalesforce。
エンジニアならGitHub。
デザイナーならAdobe Creative Cloud。
経理ならSAP。
人事なら人事システム。
役職者なら特定フォルダ。
つまり、
誰に何の権限を与えるか
を設計する必要があります。
ここで、
RBAC。
Role-Based Access Control。
という考え方が出てきます。
個人単位で、
田中さんにはこれ。
鈴木さんにはこれ。
佐藤さんにはこれ。
とやると管理不能になります。
そこで、
営業。
営業マネージャー。
経理。
経理管理者。
エンジニア。
などのRoleを作り、
Roleに権限を結び付ける。
社員にはRoleを割り当てる。
社員数が増えるほど、
人ではなく役割を管理する
ようになります。
異動が意外と一番怖い
入社ならゼロから作ればいい。
退社なら全部消せばいい。
しかし異動は難しい。
営業部の田中さんが経営企画へ異動した。
新しい権限を付ける。
これは簡単です。
問題は、
昔の営業権限を外すこと
です。
Salesforceの顧客情報。
営業部SharePoint。
営業部Box。
売上資料。
価格表。
顧客契約。
こういう古い権限が残る。
転属を繰り返すと、
3年前の部署。
2年前の部署。
現在の部署。
全部見られる人が出来上がる。
これを、
Privilege Creep
などと呼びます。
権限は人間の荷物と似ていて、
放っておくと増える一方です。
だからIdentity Governanceでは、
付与だけでなく、
不要になった権限を剥奪する
ことが重要になります。
退職者のアカウントが残ると何がまずいのか
例えば社員が3月31日退職。
Microsoft 365は止めた。
しかし、
GitHubは残った。
Dropboxは残った。
Adobeも残った。
あるSaaSは個別ID/PWなので残った。
退職者が会社のデータへアクセスできる。
それだけではありません。
会社は使っていないアカウントのSaaS料金を払い続けることになります。
社員5000人。
SaaS20種類。
異動・入退社が年間1000人。
こうなると、
「情シスの担当者がExcelでチェック」
では限界があります。
だからEntra ID GovernanceのLifecycle Workflowsのように、社員のJoiner・Mover・LeaverをIdentity Lifecycleとして扱い、入社・異動・退社に伴うアクセス管理を自動化する仕組みが存在します。
企業ITでは、
Joiner。
Mover。
Leaver。
という三つのイベントが非常に重要です。
人事イベントが、
そのままセキュリティイベントになるからです。
HENNGE Oneが日本企業で出てくる理由
日本企業でよく名前を見るのが、
HENNGE One
です。
HENNGE Access Controlを使い、
Microsoft 365やGoogle Workspace、各種SaaSへのSSOやアクセス制御を行う。
会社の中では、
「HENNGE通してください」
「HENNGEの証明書更新」
「SAML設定」
「SP追加」
などという会話が出てきます。
HENNGEの公式サポートにも、SAMLのService Provider設定、IdP Metadata、証明書、Google WorkspaceとのSAML署名証明書更新など、かなり実務的な設定手順が並んでいます。
一般社員からすると、
Microsoft 365へログインしたら、
途中でHENNGEっぽい画面が出た。
くらいです。
しかし裏では、
誰が、
どの端末から、
どの条件で、
どのクラウドサービスへ入ってよいのか、
というアクセス制御が動いています。
PCを一台渡すだけでもIntuneがいる
アカウントができた。
次はPCです。
Windows企業なら、
Microsoft Intune
などのMDM、Endpoint Managementを使う会社があります。
会社PCに、
セキュリティ設定。
Wi-Fi。
VPN。
アプリ。
証明書。
暗号化。
パスコードポリシー。
各種Restriction。
を配る。
さらに、
この端末は会社管理下か。
OSは古くないか。
ディスク暗号化されているか。
危険な端末ではないか。
といったDevice情報をアクセス制御と組み合わせる。
つまり、
「正しいパスワードを知っている」
だけでは会社システムへ入れないようにする。
ユーザーIdentityとDevice Identityを組み合わせるわけです。
Macが増えるとJamf ProとApple Business Managerが出てくる
エンジニアやクリエイティブ企業ではMacが大量にあります。
ここで、
Jamf Pro
Apple Business Manager
が出てきます。
昔なら情シスがMacを箱から出す。
電源を入れる。
初期設定。
アプリインストール。
セキュリティ設定。
ユーザー設定。
一台ずつキッティング。
100台なら100台やる。
しかしApple Business ManagerとJamf Proなどを組み合わせると、
Automated Device Enrollment
を使えます。
Jamfはこれをzero-touch deploymentとも説明しており、会社所有デバイスを、社員が箱から出して起動した段階から自動的にMDMへ登録して設定できます。AppleもAutomated Device Enrollmentを、組織所有デバイスを箱から出した時点から構成・管理できる仕組みとして提供しています。
つまり社員の自宅へ、
未開封MacBook
を直接配送する。
社員が箱を開ける。
Wi-Fiへ接続。
すると会社管理端末として自動登録される。
Jamfから設定が降ってくる。
必要なアプリが入る。
会社アカウントでログイン。
仕事開始。
情シス担当者がPCに一度も触っていない。
これが、
Zero-touch
です。
リモートワーク企業ではかなり意味があります。
「PCキッティング」という仕事自体が変わる
昔の情シス。
机の上にPC100台。
USBメモリ。
Windows Update。
Officeインストール。
ウイルス対策ソフト。
プリンター設定。
ラベル貼付。
資産管理番号。
これを延々やる。
現在のEndpoint Managementでは、
設定を人間が端末へ入れるのではなく、
Policyとしてクラウドから配る
方向へ変わっています。
一台設定する。
ではなく、
営業PC Policy。
開発PC Policy。
管理職Policy。
という形で管理する。
ここでも、
「社員一人を管理する」
から、
「RoleやPolicyを管理する」
へ抽象度が上がります。
大企業のITは大体この方向です。
人間一人ずつを手作業で管理していたらスケールしないからです。
SSOは便利なだけではない
社員からすると、
SSOは、
「パスワードを何個も覚えなくていい便利機能」
です。
しかし会社から見るともっと重要です。
例えばSaaSを20個使っていて、
20個全部に個別ID・PWがある。
社員が退職した。
20サービス全部へログインして、
1個ずつ停止しなければならない。
どれか1個忘れる。
アクセスが残る。
一方、IdPを入口に集約すれば、
中央のIdentityを止めることでアクセスを遮断しやすくなります。
つまりSSOは、
ログインを楽にする仕組み
であると同時に、
会社がアクセス権を集中管理する仕組み
です。
便利さは副産物に近い場合があります。
MFAも「面倒な6桁コード」ではない
ここで、
MFA。
Multi-Factor Authentication。
が出てきます。
パスワード。
Authenticator。
生体認証。
セキュリティキー。
などを組み合わせる。
社員からすると、
「また認証か、面倒だな」
となる。
会社からすると、
パスワードが漏れても、
それだけでは侵入できない状態を作る。
さらに、
普段は東京からアクセス。
突然深夜に海外からアクセス。
未管理端末。
危険なIP。
管理者権限。
こういう条件に応じて認証を強くする。
ここまで行くと、
Identity管理は単なるアカウント発行ではありません。
会社の入口そのもの
になります。
一人の退社から会社のシステム構造が全部見える
社員が辞める。
人事側では、
退職日を登録する。
それだけに見えます。
しかしその瞬間から、
Entra ID停止。
Microsoft 365停止。
HENNGE停止。
Okta停止。
Salesforce停止。
Slack停止。
Box停止。
GitHub停止。
Google Workspace停止。
PCロック。
IntuneからRemote Wipe。
Jamfから管理処理。
VPN証明書失効。
入館証停止。
共有メール引継ぎ。
OneDriveデータ移管。
メール転送。
ライセンス回収。
などが動く。
つまり、
「社員」という一人の人間が、会社の中では数十個のデジタルIdentityに分解されている
わけです。
そして情シスの仕事の一つは、
その数十個を、
一人の社員として再び束ねて管理することです。
人事情報は、実はITシステムの最上流データになる
この構造を考えると面白い。
普通は、
人事システムは、
給与。
勤怠。
評価。
社員名簿。
のためのものだと思います。
しかしIdentity管理では、
人事システムが、
誰が会社の人間なのかを決めるSource of Truth
になり得ます。
MicrosoftもHR-driven provisioningにおいて、人事システムを新しいデジタルIDのauthoritative sourceとして位置付けています。
人事に、
4月1日入社
と入れる。
Identityが作られる。
権限が付く。
PCが配られる。
逆に、
3月31日退社
と入れる。
アクセスが消える。
こうなると、
人事データの入力ミスが、
ITセキュリティ事故になる可能性すらあります。
部署コードが違えば、
間違った権限が付く。
退職日が違えば、
アカウント停止日もずれる。
会社のシステムは、意外なところでつながっています。
情シスは「パソコンに詳しい人」ではない
一般社員から見る情シスは、
「PCが動かないときに呼ぶ人」
になりがちです。
プリンターが出ない。
Wi-Fiにつながらない。
Teamsがおかしい。
パスワード忘れた。
PC交換して。
もちろんそれも仕事です。
しかし数千、数万ユーザーを管理する世界では、
本質的な仕事はもっとシステム寄りになります。
Microsoft Entra ID。
Intune。
Jamf Pro。
Apple Business Manager。
HENNGE One。
Okta。
Active Directory。
SAML。
SCIM。
SSO。
MFA。
RBAC。
MDM。
Conditional Access。
Lifecycle Management。
こういう仕組みを組み合わせて、
社員という人間のライフサイクルと、会社の情報システムのライフサイクルを同期させる。
社員が入ればアクセスできる。
異動すれば権限が変わる。
辞めれば入れなくなる。
PCを失えば止められる。
危険なアクセスなら弾く。
これを数万人分、自動的に成立させる。
会社の情報システム部門は、かなりの部分、
「会社というデジタル都市の戸籍・鍵・門番を管理する部署」
になっています。
社員は毎朝、
自分のメールアドレスとPCで普通にログインします。
その「普通」を成立させるために、
裏側ではかなり巨大な仕組みが動いています。
＝＝＝
 |
 |
 |
"make you feel, make you think."
SGT&BD
(Saionji General Trading & Business Development)
説明しよう！西園寺貴文とは、常識と大衆に反逆する「社会不適合者」である！平日の昼間っからスタバでゴロゴロするかと思えば、そのまま軽いノリでソー◯をお風呂代わりに利用。挙句の果てには気分で空港に向かい、当日券でそのままどこかへ飛んでしまうという自由を履き違えたピーターパンである！「働かざること山の如し」。彼がただのニートと違う点はたった１つだけ！そう。それは「圧倒的な書く力」である。ペンは剣よりも強し。ペンを握った男の「逆転」ヒップホッパー的反逆人生。そして「ここ」は、そんな西園寺貴文の生き方を後続の者たちへと伝承する、極めてアンダーグラウンドな世界である。 U-18、厳禁。低脳、厳禁。情弱、厳禁。